本発明のいくつかの特徴、目的および利点が図面とともに本明細書を読むことで理解されるだろう。
以下により詳細に記載されるように、IPTV番組、またはより一般的にIMSを通じてアクセスされるメディア・コンテンツにおける時間内の特定のインスタンス、例えばシーンは明確な方法でマーキングされる。ブックマークと呼ばれうるシーンのマーキング情報は好適にはネットワーク内に例えばユーザのIMSまたはIPTVのサービス・プロファイルの一部として記憶される。ローカル装置ではなくネットワーク内にマーキング情報を記憶することにより、任意の場所から任意の装置でブックマークにアクセスできる。ブックマーキングが将来において番組内のシーンへ戻ることを暗示し、それ故例えば何らかの方式で不揮発性記憶装置によって、時間の少なくとも一部の期間についてアクセス可能となるように番組が続くと仮定できることを当業者は理解するだろう。
このようなブックマークを用いて、ユーザはとりわけ同一または異なるメディア・レンダリング装置上で、ブックマークされた時点から前方に番組の視聴を再開することができ、例えばチャットまたはその他のソーシャル・ネットワーキング交流内のリンクとして他人へブックマークを送ることができ、その結果としてその他人は(当然のことながら、その他人がそのコンテンツへアクセスする権利を有することを前提として)ブックマークされたシーンからまたはその周辺の番組を視聴できる。
図1は本発明に従ってコンテンツ・オン・デマンド(CoD)のためのメディア・ブックマーキングの方法における通信ネットワーク100内のエンティティ間の典型的な信号フローを説明する。説明される方法はIMSの文脈においてIMSに適したメッセージを採用するが、一般にその他のコンテンツおよびその他のタイプのメッセージが用いられうる。
ステップ152で、ユーザは、メディア情報の集合、例えばUEやセットトップ・ボックスのような装置でIMS104を通じてユーザがアクセス可能なメディア・サーバ102上の利用可能なメディア・コンテンツを視聴する要求を示す。ユーザは多くの方法、例えばUEで実行中のブラウザ・アプリケーションのリンクまたはURIをクリックすることによって要求を示してもよい。
ステップ154〜166は要求されたコンテンツのためにIMSセッションを確立する処理に関する。ステップ154で、UE内のIPTVターミナル機能(ITF)106はIMS104へ送信されるSIP INVITEメッセージを準備し、IMS104はIMSに関連付けられたIPTV制御サーバ108へINVITEメッセージを転送する。SIP INVITEメッセージはIMSの文脈で適切であるが、その他の種類のメッセージがその他の文脈で用いられうることを当業者は理解するだろう。
ITF106はSTB、統合TV/STB、パーソナルコンピュータ、移動体電話、またはその他のユーザ装置のようなUE内の機能であり、IPTVメディア情報が選択されユーザへ表示されることを可能にする。本出願で記載されるその他の機能と同様に、ITF106は典型的に、UEとネットワーク100内のその他のエンティティとにより交換される信号によって伝えられる情報を扱うUE内のメモリを有する適切にプログラムされた電子プロセッサまたはその均等物により実装される。IPTV制御サーバ108は、ユーザに利用可能なメディア情報を決定し制御する機能を実装するプログラムされたプロセッサである。
IPTV制御サーバ108はユーザの要求をメディア・コントローラ110へ転送し、メディア・コントローラ110はステップ156で、ユーザにより要求されたコンテンツを有するメディア・サーバ102へDESCRIBEメッセージを送信する。DESCRIBEメッセージはリアルタイム・ストリーミング・プロトコル(RTSP)メッセージまたは別の適切なプロトコルに従うメッセージでありうる。ステップ158で、メディア・サーバ102はRTSPセッション識別子を含むRTSP 200 OKメッセージでメディア・コントローラ110に応答する。ステップ160で、メディア・コントローラ110はセッション識別子を含むRTSP SETUPメッセージをメディア・サーバ102へ送り、ステップ162でこのメッセージに対してメディア・サーバはRTSP 200 OKメッセージで応答する。ステップ164で、メディア・コントローラ110はRTSPセッション識別子を含むSIP 200 OKメッセージを、IMS104を用いてIPTV制御サーバ108を通じてITF106へ渡す。ステップ166で、ITF106は適切な確認メッセージで応答し、このメッセージはIMS104からIPTV制御サーバ108およびメディア・コントローラ110へ渡り、IMSセッションが確立されたことを示す。
ステップ168、170はユーザによるコンテンツの再生の処理に関する。ステップ168で、ユーザのITF106は、確立されたセッションの識別子を含むRTSP PLAYメッセージをメディア・コントローラ110へ送信し、このメッセージはメディア・サーバ102へ転送される。ステップ170で、メディア・サーバ102はセッション識別子を含むRTSP 200 OKメッセージでメディア・コントローラ110に応答し、メディア・コントローラ110はこのメッセージをITF106へ転送する。メディア・コントローラ110は、例えば適切なタイマーを開始することによって、任意のブックマークを確立するために将来用いられる、再生要求についての開始時間を記録する(ステップ172)。メディア・サーバ102からUEのITF106へのコンテンツ配信は、IMS制御プレーンを通ることなく後に続いて起きる。コンテンツがインタラクティブな場合に、双方向矢印で示されるようにメディア・サーバ102とITF106とによって適切な情報が交換される。
ステップ174で、例えばUEのディスプレイまたは特定のボタンもしくはUE、リモート・コントロールなどのブックマーキングに関連付けられたその他の制御装置をクリックすることによって、コンテンツ内の時点またはシーンをブックマークする要求をITF106へ示す。ユーザの要求に応答して、ITF106内のブックマーク機能はコンテンツのタイトルおよび/またはその他の特徴に基づきうるブックマークについての表示名を示唆しうる。ユーザは、示唆されたブックマークの表示名を、ブックマークが要求されるのと同時に変更でき、または記憶されたブックマークを変更するために適切にプログラムされた手続きを通じて後から変更できる。
ステップ176で、ITF106はSIP INFOメッセージをIMS104へ送り、このメッセージはIPTV制御サーバ108へ転送される。INFOメッセージまたはブックマーク情報を伝えるその他の適切なメッセージは、とりわけメディア・コンテンツおよび視長時間に基づく1つ以上の情報要素を含む。ステップ178で、IPTV制御サーバ108はSIP 200 OKメッセージでINFOメッセージに応答し、このSIP 200 OKメッセージはIMS108によりITF106へ転送される。
ブックマーク・メッセージの例が図2に示され、図2は番組のURI(“<entry uri=...”)、番組の開始からのタイム・オフセット、すなわちずれ(“<time-offset>...”)、およびブックマーク表示名(“<display-name...>”)を含むSIP INFOメッセージを示す。図2において、IPTV-bookmarks xmins="urn:Bokmarks:2008"という行はIPTVブックマークの定義が行われるスキーマを示し、この情報要素についての値の例を示す。SIPから英語に変換されると、この行は“IPTVブックマークとして知られる複合タイプであり、urn:Bookmarks:2008で発見されうるスキーマにより定義される要素および属性を含む”と解釈されうる。図2でsip:
[email protected]という情報要素により識別されるユーザは、事前の識別・認証手続きによりIPTV制御サーバ108に知られており、この手続きの間にユーザはITF106からネットワークに登録されることに留意されたい。例としてコンテンツ・オン・デマンドを挙げると、適切なブックマーク・メッセージは少なくとも以下の情報要素を含む。メディア・コンテンツを識別するURI、時間インジケータ、およびブックマーク表示名。上述のように、URIおよび表示名はITF106にすでに知られており、時間インジケータは以下に示されるようなフラグまたは時間値でありうる。
IPTV制御サーバ108は、番組自体の利用可能性のせいで、またはユーザによるブックマーキングの使用に関連するいくつかの検討のせいで、ブックマークされた番組が有限の期間だけ利用可能であることを決定してもよい。このような有限の期間だけブックマークが利用可能である場合に、IPTV制御サーバ108は関連のあるブックマーク情報へ<expiration>要素を付加しうる。
SIP INFOメッセージがブックマーク・メッセージの単なる例であり、その他の種類のメッセージおよびその他のプロトコルを用いうることを当業者は理解するだろう。SIP INFOメッセージのようなブックマーク・メッセージは、表示されているメディア情報の現在の状態へ戻るために必要な様々な情報要素を含みうる。例えば、コンテンツがゲームに関連付けられている場合に、ブックマーク・メッセージはブックマークが読み出される際にゲームの状態を再現するのに十分なゲームのメタデータを含むだろう。この例では、メディア情報がインタラクティブなクイズ番組を含む場合に、特定の時点のコンテンツをブックマークすることはその時点におけるユーザの点数および他の参加者の点数を記録することになるだろう。後になって、このブックマークからユーザがコンテンツを再開する際に、クイズの状態が再現されるだろう。
別の適切な仕組みのタイマーは、コンテンツの開始から、ブックマーク要求を生成する時間のようなブックマーク時間までの時間のずれを決定するために用いられる。図1に説明されるように、メディア・コントローラのタイマーはユーザの再生要求(ステップ168)を確認した際に開始される(ステップ172)。例えば、時間インジケータはITF106内の適切なタイマーにより決定される時間ずれ値でありうるし、またはステップ180で説明されるように時間インジケータはメディア・コントローラ110内の適切なタイマーを読み取らせるフラグでありうる。ブックマーク要求(ステップ176)を受けた際にステップ182で経過時間値またはその他の適切な指標が読み出される。
ブックマーキングの実用上の側面を検討すると、典型的に、ブックマークが作成されるべきであるとユーザが実感する時間とユーザが実際に“ブックマーク”ボタンを押してブックマーク要求が生成される時間との間に遅延が存在する。よって、ブックマーク時間はITFがブックマーク要求を受けた時間よりも幾分の時間早く設定されるべきである。1つのオプションは、経過時間時の読み出しにおいて適切な「反応時間」を減算するようにメディア・コントローラ110を構成することである。代替として、ITF106は、ユーザが再生のためにブックマークを選択する際にメディアにより読み出される実際の経過時間から「反応時間」を減算するように構成されうる。「反応時間」の量はユーザにより選択可能であり、ユーザ・プロファイルの別の側面として記憶されうるだろう。
ステップ184、186で、IPTV制御サーバ108は好適にはIPTV制御サーバ108により、または関連するIPTVユーザ・プロファイル・サーバ112により記憶された個々のユーザ・プロファイルの一部であるブックマークのリストを更新する。ユーザ・プロファイルの複製がユーザのITF106において維持されうる。更新は有利には拡張可能なマーク付言語(XML)構成アクセス・プロトコル(XCAP)を用い、XCAPはユーザ・プロファイルを新たなブックマークで更新するための効率的な仕組みである。ステップ184で、IPTV制御サーバ108は、ブックマーク・アドレス、コンテンツについてのURI、時間ずれ、(存在する場合に)ブックマークの有効期間の指標、およびブックマーク表示名のような関連するブックマーク情報を含むXCAP PUTメッセージをIPTVユーザ・プロファイル・サーバ112へ送信する。ステップ186で、IPTVユーザ・プロファイル・サーバ112はブックマークの作成が成功したことを示すために、ハイパーテキスト・トランスファー・プロトコル(HTTP) 200 OKメッセージのようなメッセージで応答する。
ステップ188で、ITF106上のユーザのローカル・ブックマーク・アプリケーションはIPTV制御サーバ108からITF106へ送信されたSIP NOTIFYメッセージによって、追加されたブックマークを通知される。標準SIPの用法に従って、ITF106はNOTIFYメッセージに対してSIP 200 OKメッセージで確認応答する(ステップ190)。ステップ188、190について、ユーザのITFは、ブックマーク・アプリケーションについてのxcap-diffイベント・パッケージまたは同様のものを含むSIP SUBSCRIBEメッセージを用いてプロファイルへの変更の通知を受信することを事前に要求していただろうことが理解されるだろう。このような要求に応答して、ブックマーク要求を生成するために用いられるITFへSIP NOTIFYメッセージがステップ188で送信される。
NOTIFYメッセージは、xcap-diffイベント・パッケージを用いてプロファイルへの変更を受信するように依頼するITFからSUBSCRIBEメッセージを送信することによってこのような通知を受信するように購読しているユーザに関連するその他のITFへも送信される。新たなITF、すなわちユーザのプロファイルの複製を有しないITFについて、このような購読要求はユーザのプロファイル全体がダウンロードされる結果となりうる。次いで、ネットワークからこのITFへの後続の通知は、プロファイルへの変更だけを送信する結果となる。NOTIFYメッセージは、ブックマークが期限切れとなったことをITFへ通知するためにも用いられ、その結果としてITFはブックマークを削除するか、それを使用不能にするか、それ以外の方法ではブックマークがもはや有効でないことをユーザに視覚的に示すことができる。
XCAPにより、クライアントはサーバ上にXMLフォーマットで格納されたアプリケーション構成データを読み出し、書き込み、そして変更することができる。このようなアプリケーション構成データのそれぞれは“アプリケーション用法”と呼ばれ、アプリケーション一意識別子(AUID)と呼ばれる一意な名称に関連付けられる。ユーザについてのIPTVブックマークはこのようなアプリケーション用法の個別のケースであり、このようなブックマークについてのAUIDは、ユーザのブックマーク情報が格納される論理データ・ストアにアクセスするためにユーザ名とともにXCAP要求に用いられる。
XCAPにより管理される文書に変更が生じたことを示すために用いられうる文書形式を定義するIETFドラフトにxcap-diffが関連することを当業者は理解するだろう。これは、いくつかのクライアントがサーバ上に記憶された同一のXML文書を共有し、共有された文書を変更するためにXCAPを用いる場合に有用である。クライアントはいっせいにドキュメントを変更できるため、そのメモリにクライアントがキャッシュした文書が最新のバージョンであることを確定する単純な方法は存在しない。この問題を扱うために、クライアントはXCAP文書における変更イベントを購読するために、IETF RFC 3265に定義されるようなイベント・パッケージを用いることができる。xcap-diff-eventはこのようなイベント・パッケージであり、このイベント・パッケージを購読するクライアントは対象のXML文書への任意の変更を通知されるだろう。用いられるデータ形式はXCAPディフ文書と呼ばれるXML文書形式であり、この形式は文書が変更されたことを示すことができ、自身の以前のエンティティ・タグおよび新たなエンティティ・タグを提供することができる。これはまた、オプションとして、変更前のバージョンからその後のバージョンへの文書の変換方法を示すパッチ動作の集合、例えばI-D.ietf-simple-xml-patch-opsを含みうる。XCAP文書のXMLの要素および属性のコンテンツもこの形式で配信されうる。
図3はIPTV制御サーバからIPTVユーザ・プロファイル・サーバへ送信されうるXCAP PUTメッセージの例を説明する。上述のように、XCAPは完全なシステムを形成する機能間でXML情報のフラグメントが容易に認識され交換されることを可能にするプロトコルである。XCAPを用いれば、ユーザ・プロファイルをブックマークで更新するために、ユーザ・プロファイル全体を送信する必要はない。図3に見て取れるように、XCAPメッセージはブックマーク・アドレス(“http://userprofileserver.iptvprovider.com...”)、メディア情報のURI(“<entry uri=...”)、メディア情報の開始からの時間ずれ(“<time-offset>...”)、ブックマークが利用可能でなくなる時間(“<expiration>...”)、およびブックマーク表示名(“<display-name>...”)を含む。図3で情報要素sip:
[email protected]により識別されるユーザは、ITF106からIPTV制御サーバ108にユーザが登録した以前の識別・認証手続きから、IPTV制御サーバ108およびIPTVユーザ・プロファイル・サーバ112に知られている。
図4は本発明に従うリニアTVについてのメディア・ブックマーキングの方法における別の通信ネットワーク100´内のエンティティ間の典型的な信号フローを示す。リニアTVは一般的に事前に定められたスケジュールに従って提示されるメディア情報の番組である。
ステップ402で、ユーザは、STBのようなアクセス装置により実装されたITF106を用いてユーザがアクセス可能なリニアTV番組の視聴の要求を示す。ユーザは多くの方法で、例えばUE上で稼動しているブラウザ・アプリケーション内のリンクまたはURIをクリックすることによって、要求を示しうる。
ステップ404−408はリニアTVのためのIMS制御セッションを確立する処理に関する。ステップ404で、ユーザのITF106はIMS104へ送信されるSIP INVITEメッセージを準備し、IMS104はユーザの要求をIMS104に関連付けられたIPTV制御サーバ108へ転送する。IPTV制御サーバ108はステップ406でSIP 200 OKメッセージで応答し、このメッセージはIMS104を通じてITF106へ転送される。ステップ408で、ITF106は適切な確認メッセージで応答し、このメッセージはIMSからIPTV制御サーバへ渡され、IMSセッションが確立したことを示す。
ステップ410で、ITF106は、ユーザにより要求されたリニアTVチャネルについてのマルチキャスト・アドレスに参加するために、インターネット・グループ管理プロトコル(IGMP)のJOINメッセージを発行する。JOINメッセージは、リニアTVチャネルのコンテンツがユーザのITF106へ配信されるという結果とともに、デジタル加入者線アクセス多重化器(DSLAM)114またはその他の適切なネットワーク装置へ送信される。DSLAMは一般に複数のユーザをネットワークに接続できる多重化器であり、マルチキャスト・グループは通信ネットワークを越えてリニアTVチャネルを配信するための効率的且つ現在普及している仕組みである。IGMPはIPマルチキャスト・グループを管理するためにIPホストにより用いられ、ビデオおよびその他のコンテンツをストリーミングするためのグループのメンバーを発見するために、接続されたルータにより用いられる。IGMPバージョン1はRFC1112により定義され、IGMPバージョン2はRFC2236により定義され、IGMPバージョン3はRFC3376により定義される。
ステップ412で、ユーザは例えばUEのディスプレイまたは特定のボタンもしくはUE、リモート・コントロールなどでのブックマーキングに関連付けられたその他の制御装置上でクリックすることによって、番組内の時点またはシーンをブックマークする要求をITF106へ示す。ユーザの要求に応答して、ITF106内のブックマーク機能は、番組のタイトルおよび/またはその他の特徴に基づきうるブックマークについての表示名を示唆することができるとともに、記憶されたブックマークを変更するための手続きを通じて、要求と同時に、または後で行われた場合に、ブックマークの示唆された表示名をユーザに変更させることができる。
ステップ414で、ITF106はSIP INFOメッセージをIMS104へ送信し、IMS104はこのメッセージをIPTV制御サーバ108へ転送する。リニアTV番組が記録されていないという情報をITF106が有する場合に、ITF106は典型的にSIP INFOメッセージを生成して送信することはなく、ユーザに適切に忠告するだろう。ITF106はこのような情報を番組スケジュールから取得でき、番組スケジュールは番組がブックマークされうるかを示すアイコンまたはその他の表示を含みうる。INFOメッセージまたはその他の適切なメッセージは好適には少なくとも以下の情報要素を含む。番組マルチキャスト・アドレス、要求された番組についてのコンテンツ識別子、およびユーザにより選択されたブックマーク表示名。ステップ416で、IPTV制御サーバ108は番組が利用可能かどうかを確認する。例えば、サーバはネットワーク100´に番組が記録されているかどうかを判定する。
番組が記録されていない場合に、番組が後の時間においてアクセス可能でないだろうからブックマークを生成することができず、適切なメッセージがユーザへ提供されうる。ITF106は自身のタイマーおよび番組スケジュールの複製に基づいて自身のブックマーク・メッセージに時間オフセットを含める。IPTV制御サーバ108は次いで番組の記述子についてのURIが記録されているかを判定する。ステップ416が完全に成功した場合に、IPTV制御サーバ108は動作の成功を示すためにIMS104を通じてITF106へSIP 200 OKメッセージを戻す(ステップ418)。
番組が記録されていたとしても、IPTV制御サーバは典型的に番組がいつ再生を開始したか、すなわちJOINメッセージがITF106からDSLAM114へいつ送信されたか(ステップ410)を知らないことに留意されたい。IPTV制御サーバはブックマーク時間を算出できず、よって時間オフセットがITF106により決定される。
ステップ420、422で、IPTV制御サーバ108は、好適にはIPTV制御サーバ108によりまたは関連するIPTVユーザ・プロファイル・サーバ112により記憶された個々のユーザ・プロファイルの一部であるブックマークのリストを更新する。図1、3に関連して上述されたように、新たなブックマークでユーザ・プロファイルを更新するための効率的な仕組みとして、更新は有利にはXCAPを用いる。ステップ420で、IPTV制御サーバ108は、ブックマーク・アドレス、ネットワークに記録されたコンテンツについてのURI、時間ずれ、およびブックマーク表示名のような後から番組を読み出すための関連するブックマーク情報を含むXCAP PUTメッセージをIPTVユーザ・プロファイル・サーバ112へ送信する。XCAP PUTメッセージはまた、ブックマークの有効期間を示す有効期限要素を含みうる。ステップ422で、IPTVユーザ・プロファイル・サーバ112はブックマークの作成の成功を示すためにHTTP 200 OKメッセージで応答する。
ステップ424で、ITF106上のユーザのローカル・ブックマーク・アプリケーションは、IMS104を介してIPTV制御サーバ108からITF106へ送信されたSIP NOTIFYメッセージによって、追加されたブックマークを通知される。標準SIPの用法に従って、ITF106はSIP 200 OKメッセージでNOTIFYメッセージに確認応答する(ステップ426)。ステップ424、426が発生するように、上述のようにユーザがブックマーク・アプリケーションについてのxcap-diffイベント・パッケージを事前に購読しているだろうことが理解されるだろう。
ブックマークが作成された後に、STBまたはその他のUEのような適切なアクセス装置から自身のIPTVユーザ・プロファイルに単にアクセスすることによって、ユーザは自身のブックマークのリストを読み出すことができ、このようなアクセスはブックマークが作成されたものとは異なる装置から実行されうる。ブラウザを通じてIPTVシステムにログインまたはその他のようにサインオンする際に、ユーザには典型的に選択可能なリンクのメニューが提示され、このリンクの1つは“IPTVブックマーク”へのリンクでありうる。このリンクを選択することによって、ユーザのITFは記憶されたブックマークを読み出すために、上述のようにIPTVブックマークを記憶しているIPTVユーザ・プロファイル・サーバへ要求を送信する。
図5はユーザ・プロファイルのブックマーク部分から特定のユーザのブックマークを取り出すための適切な要求メッセージであるXCAP GETメッセージを説明する。ブックマークAUIDは図5で“IPTV-Bookmark”と呼ばれる。要求メッセージはユーザを識別する情報要素(例えば“sip:
[email protected]”)とサービス・プロバイダを識別する情報要素(例えば“iptvprovider.com”)とを含む。
要求メッセージに従って動作する前に、IPTVユーザ・プロファイル・サーバ112または別のネットワーク・エンティティは典型的に適切なユーザ認証・アクセス制御手続き、例えばユーザにユーザ名およびパスワードの入力を要求することを含む。これらの手続きが正しく完了し、アクセスが許可された場合に、適切なメッセージでブックマークのリストが戻される。
図6はIPTVユーザ・プロファイル・サーバ112からITF106へ読み出されたブックマークを戻すために適しているHTTP 200 OKメッセージを説明する。図6で、ブックマークのエントリーの属性として戻されたブックマークの項目とともに、各ブックマークのURI(“<entry uri=...”)、番組の開始からの時間ずれ(“time-offset=...”)、およびブックマーク・リスト名(“<list name=...”)をメッセージが含むことが見て取れる。各ブックマーク・エントリーは、ブックマークが作成された際にこのような情報が設定されたならば、日付および時間のような有効期限情報(“expiration=...”)を含みうる。これらの結果はユーザへ表示され、ユーザは表示された結果から選択することができる。ユーザのアクセス装置内のITF106に含まれるウェブブラウザはメッセージを構文解析する。ユーザはITF106内のウェブブラウザを用いて、ブックマークのリストから選択された1つ以上のブックマークを変更または編集し、リストされたブックマークを表現するXML文書を変更するための適切なXCAPメッセージを用いてネットワークへ変更を送信できることを当業者は理解するだろう。
ブックマークのリストは実質的に同一の方法で始まる多くの方法で読み出されうることが理解されるだろう。ユーザ・プロファイル内のブックマークに関連する情報をIPTVユーザ・プロファイル・サーバ112が保存した後に、IPTVユーザ・プロファイル・サーバ112はIPTV制御サーバ108へOKメッセージを送信する(ステップ186、422)。IPTV制御サーバ108は、OKメッセージを保存成功とみなし、SIP NOTIFYメッセージを生成する(ステップ188、424)。SIP NOTIFYメッセージはブックマーク情報を記述するXML本文を含む。このようなXML本文は基本的に、ブックマークが保存されることを要求する、IPTVユーザ・プロファイル・サーバ112へIPTV制御サーバ108により送信されるPUTメッセージ内のものと同一でありうるが、time-offsetのようなネットワークにより付加された要素を含みうる。ITF106は自身のローカル・ブックマーク・リストを更新するためにこのようなSIP NOTIFYメッセージ内の情報を用いうる。
本出願で説明されたメディア・コンテンツに関連するものの、メディア・コンテンツを表示しブックマークを生成するために用いられる装置には関連しないブックマークは、ブックマークがユーザに利用可能な任意の適切な装置からアクセスされて利用可能であるので、番組再生について多くのさらなる機能をユーザに提供する。このような能力は例えばゲームの状態またはその他のインタラクティブ・コンテンツがキャプチャされ、後から再現されることを可能にするインタラクティブTVで特に有用である。さらに、IPTVブックマークのXCAPアプリケーション用法を用いて、ブックマーク要求は適切なディレクトリ内のユーザ・プロファイルにエントリーを容易に追加するXCAP要求へ変換されうる。ユーザは適切な認証の後に任意の装置からディレクトリにアクセスでき、記憶されたブックマークを読み出すことができる。
本出願で説明された方法および装置は移動体無線ネットワークのような多くの種類の電子通信ネットワークで実施可能であることを当業者は理解するだろう。
図7は本出願で説明されるメディア番組コンテンツにアクセスしてレンダリングするための移動体電話、STB、コンピュータなどのような典型的なUE700のブロック図である。UE700は図1や図4に説明された1つ以上のネットワーク・エンティティと電子信号を交換するために適している送受信器702を含む。これらの信号で伝えられる情報はプロセッサ704により扱われ、プロセッサ704は1つ以上のサブプロセッサを含んでもよく、上述のUE700の動作を実行するために例えばITF106を含む1つ以上のソフトウェア・モジュールおよびアプリケーションを実行する。UE700へのユーザ入力はキーパッド、リモート・コントロール、またはその他の装置706を通じて提供され、ユーザへ提示される情報はディスプレイ708へ提供される。ディスプレイがタッチスクリーン機能を有する場合に、ユーザ入力はディスプレイを通じて提供されうる。ソフトウェア・アプリケーションは適切なアプリケーション・メモリ710に記憶されてもよく、UEはまた、所望の情報を適切なメモリ712にダウンロードおよび/またはキャッシュしてもよい。UE700はまた、コンピュータ、マイクなどのようなその他のコンポーネントをUE700へ接続するために用いられうるインタフェース714を含んでもよい。
ブックマークの作成において、ITF106はキーパッド706またはインタフェース714を介してブックマーク要求を受け取り、この要求はプロセッサ704へ渡され、プロセッサ704は以前のセッション確立を通じてユーザへ提示されているコンテンツまたは番組のメモリ712内の情報を有する。プロセッサ704はまた、メモリ712内の番組スケジュールの自身の複製に基づいて番組への時間オフセットを知っており、この情報を用いて、プロセッサ704は適切なSIP INFOメッセージを形成し(ステップ176またはステップ414)、送受信器702を介してこのメッセージをIMS104へ送信する。送受信器702はユーザのブックマークへの更新を示すSIP NOTIFYメッセージを受信し(ステップ188またはステップ424)、プロセッサ704はメモリ712内の自身のローカルのブックマークの複製に更新を記録する。ITF106は、プロセッサ704に、送受信器702によりネットワークへ送信されるSIP 200 OKメッセージを形成させることによってSIP NOTIFYメッセージの受信について確認応答し(ステップ190またはステップ426)、プロセッサ704は次いでブックマークの表示または実際のブックマークそのものを、ディスプレイ708を介してユーザへ提示してもよい。
図8は本出願で説明された要求に従ってブックマークを記憶し読み出すための典型的なIPTVユーザ・プロファイル・サーバ112のブロック図である。IPTVユーザ・プロファイル・サーバ112は図1や図4に示された1つ以上のネットワーク・エンティティと電子信号を交換するために適している送受信器802を含む。これらの信号で伝えられる情報はプロセッサ804により扱われ、プロセッサ804は1つ以上のサブプロセッサを含んでもよく、上述のIPTVユーザ・プロファイル・サーバ112の動作を実行するために1つ以上のソフトウェア・モジュールおよびアプリケーションを実行する。特に、プロセッサ804は適切なメモリ806にユーザ・ブックマークを記憶し、受け取った要求に応答して選択されたブックマークをメモリ806から読み出す。典型的なIPTVユーザ・プロファイル・サーバ112はネットワーク内のデータベース・サーバであり、それ故ユーザ入出力のためにキーパッド/ディスプレイ808は通常、必要ではないが、このようなインタフェースは管理機能のために提供されうることが理解されるだろう。プロセッサ804により実行されるソフトウェア・アプリケーションは適切なアプリケーション・メモリ810に記憶されうる。
図9はIPTVユーザ・プロファイル・サーバ112からブックマークを読み出す方法を説明するフローチャートである。上述のように、ユーザは好適には図5で説明されたもののようなXCAP GETメッセージである要求をユーザのUEからIPTVユーザ・プロファイル・サーバ112へ送信する(ステップ902)ことによって、自身のブックマークのリストを読み出す。このような要求を送信することはIPTVシステムにログインまたはその他の方法でサインオンし、場合によってはIPTVユーザ・プロファイル・サーバ112へユーザ名およびパスワードを提供することを含みうる。アクセスが許可された場合(ステップ904でYES)に、図6に説明されるHTTP 200 OKメッセージのような適切なメッセージでIPTVユーザ・プロファイル・サーバ112によってブックマークのリストがユーザのUEへ戻される(ステップ906)。戻されたブックマークまたはブックマークのリストは、上述のように様々なUEへ戻されうる。ユーザのUEにおいて、戻されたメッセージは有利にはユーザのUEにより実施されるブラウザまたはその他の適切なアプリケーションにより構文解析され、読み出されたブックマークまたはブックマーク・リストはUEのディスプレイに提示される(ステップ908)。アクセスが許可されない場合(ステップ904でNO)に、失敗または同様のエラー・メッセージがUEのディスプレイに提示される。
本明細書に説明される発明は、コンピュータ・ベースのシステム、プロセッサ包含システム、媒体から命令をフェッチしてその命令を実行できるその他のシステムのような命令実行システム、装置、またはデバイスを用いるか、またはこれらと連動する適切な命令セットを記憶した任意の形式のコンピュータ読み取り可能な記憶媒体に全体として具現化されることが検討されうる。本明細書で用いられるように、“コンピュータ読み取り可能な媒体”は命令実行システム、装置、またはデバイスを用いるか、これらと連動するプログラムを含み、記憶し、通信し、またはトランスポートできる任意の手段でありうる。コンピュータ読み取り可能な媒体は、例えば電気、磁気、光学、電磁気、赤外線、または半導体のシステム、装置、デバイス、または媒体でありうるがこれらに限定されない。コンピュータ読み取り可能な媒体のより具体的な例(非包括的なリスト)は、1つ以上の配線を有する電子的接続、ポータブル・コンピュータ・ディスケット、RAM、ROM、および消去可能なプログラマブル・リードオンリ・メモリ(EPROMまたはフラッシュメモリ)を含む。
本発明は例えば移動体通信装置を含む多様な環境で実施されうることが予期される。上述の手続きは必要に応じて反復して実行されることが理解されるだろう。理解を容易にするために、本発明の側面は例えばプログラマブル・コンピュータ・システムの要素により実行されうる動作の列の観点で説明される。様々な動作が特殊用途回路(例えば特殊機能を実行するために相互接続された個別論理ゲートまたは特定用途向け集積回路)によって実行されてもよいし、1つ以上のプロセッサにより実行されるプログラム命令により実行されてもよいし、両者の組み合わせにより実行されてもよいことが理解されるだろう。
よって、本発明は多くの相異なる形式で具現化されてもよく、それらのすべてが上述されたわけではなく、このような形式のすべてが本発明の範囲に含まれることが意図される。本発明の様々な側面のそれぞれについて、このような任意の形式は説明された動作を実行“するように構成されたロジック”として表されてもよく、これに代えて、説明された動作を実行“するロジック”として表されてもよい。本出願で用いられる場合に、“備える”または“備えている”という用語は記載された機能、整数、ステップ、構成要素の存在を特定するが、1つ以上のその他の機能、整数、ステップ、構成要素、またはこれらのグループの存在または追加を排斥しない。
上述の特定の実施形態は単に例示であり、いかようにも制限的に解釈されるべきではない。本発明の範囲は以下の特許請求の範囲により決定され、特許請求の範囲に含まれるすべての変形および均等物がここに包含されることが意図される。