(57)【要約】  複数のUpnP準拠リソース間の接続を確立することを可能にする方法が提供される。各リソースは、個別の接続マネージャサービスを持つ。その方法は、前もって決められた時間に確立される各リソース間の接続を交渉するのに、UpnP制御ポイントがその個別のサービスを使用することを可能にするよう、それぞれの接続マネージャサービスを設定することを有する。
2007510330.tif 000002
【特許請求の範囲】
【請求項１】
複数のUPnP準拠リソース間の接続を確立することを可能にする方法であって、前記リソースはそれぞれ、個別の接続マネージャサービスを持ち、前記方法は、前もって決められた時間に確立される前記それぞれのリソース間の前記接続を交渉するのに、UPnP制御ポイントが前記個別のサービスを使用することを可能にするよう、前記個別の接続マネージャサービスを設定することを有する、方法。
【請求項２】
前記リソースは、放送チャネルに同調するチューナと、放送を記録するレコーダとを有する、請求項１に記載の方法。
【請求項３】
複数のUPnP準拠リソース間の接続を確立する方法であって、前記リソースはそれぞれ、個別の接続マネージャサービスを持ち、前記方法は、前もって決められた時間に確立される前記それぞれのリソース間の前記接続を交渉するのに、UPnP制御ポイントが前記個別のサービスを使用することを可能にするよう設定された前記個別の接続マネージャサービスを用いることを有する、方法。
【請求項４】
前記リソースは、放送チャネルに同調するチューナと、放送を記録するレコーダとを有する、請求項３に記載の方法。
【請求項５】
接続マネージャサービスを備えるUPnP準拠デバイスであって、前もって決められた時間に確立される別のUPnP準拠デバイスとの接続を別の接続マネージャサービスと交渉するのに、UPnP制御ポイントが前記サービスを使用することを可能にするよう設定される、UPnP準拠デバイス。
【請求項６】
放送チャネルに同調するチューナを有する請求項５に記載のデバイス。
【請求項７】
コンテンツ情報を記録するレコーダを有する請求項５に記載のデバイス。
【請求項８】
複数のUPnP準拠リソース間の接続を確立することを可能にするための制御ソフトウェアであって、前記リソースはそれぞれ、個別の接続マネージャサービスを持ち、前記ソフトウェアは、前もって決められた時間に確立される前記それぞれのリソース間の前記接続を交渉するのに、UPnP制御ポイントが前記個別のサービスを使用することを可能にするよう、前記個別の接続マネージャサービスを設定する動作を行わせる、制御ソフトウェア。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、特に、複数のUPnP準拠リソース間の接続を確立することを可能にする方法と、接続マネージャ(ConnectionManager)サービスを備えるUPnP準拠デバイスと、複数のUPnP準拠リソース間の接続を確立することを可能にする制御ソフトウェアとに関する。
【背景技術】
【０００２】
ユニバーサル・プラグ・アンド・プレイ(UPnP)は、オープン・ネットワーク構造に向けて業界全体で取り組み中の開発仕様であり、分散型デバイスと多数のベンダから提供されるソフトウェア・アプリケーションとの間での、簡単で、アドホックな通信を可能にするようデザインされている。UPnPは、インターネット技術を利用し、非監視型ホームネットワークに対して使用できるようそれを拡張するものである。UPnPは、ホームオートメーション、音声／映像、プリンタ、スマートフォンなどを含む家庭電化製品を制御することを目的としている。UPnPは、制御ポイント(CP)と制御（対象の）デバイス(CD)とを区別する。CPは、例えば、PC上で起動するブラウザやワイヤレスパッドなど、制御デバイスにより提供される機能へのユーザによるアクセスを可能にするものを有する。
【０００３】
UPnPは、CPによるデバイスの検出及び制御のためのプロトコルを規定する。UPnPは、音声映像デバイスにより使用されるストリーミング機構を規定するものではない。検出及び制御プロトコルの中には、UPnPの仕様の一部となっているものもあるが、その一方でIETF(Internet Engineering Task Force:インターネット・エンジニアリング・タスク・フォース)により別個に標準化されたものもある。
【０００４】
CPとデバイスとの間の相互通信(interaction)は、インターネットプロトコル(IP)に基く。しかしながら、UPnPは、非IPデバイスが、IP準拠デバイスで動作するソフトウェアコンポーネントにより代理されることを可能にする。このようなコンポーネントは、制御デバイス(CD)プロキシとよばれ、代理されるデバイスに対するUPnP相互通信の翻訳(translation)及びフォワーディングに対する責任を負う。
【０００５】
UPnPデバイスは、最下層においてサービスを伴うサブデバイスの階層構造を持つ。デバイスとサービスとは共に標準化されたタイプを持つ。デバイスタイプは、サブデバイス又は含むことを許可されたサービスを決定する。サービスタイプは、含むことを許可されたサービスに関連するアクション及び状態変数を規定する。状態変数は、そのデバイスの状態をモデル化し、CPはその状態を変化させるためにアクションを呼び出すことができる。状態変数及びアクションのディスクリプション(description:記述)は、SCP(Service Control Protocol:サービス・コントロール・プロトコル)と呼ばれる。UPnPデバイスは、ディスクリプションそれ自身をXMLドキュメントの形式で提供する。このドキュメントは、特に、デバイスがサポートするサービスタイプを含む。オプションとして、デバイスはCPによる直接のUI制御のためのプレゼンテーションサーバを持つことができる。
【０００６】
UPnPは現在、DHCPサーバがなくてもIPデバイスが一意なアドレスを取得する手段を提供するAutoIP機能を利用している。UPnPは、UDP(ユーザ・データ・プロトコル)マルチキャストに基づく検出プロトコルを規定し、それはSSDP(Simple Service Discovery Protocol:シンプル・サービス・ディスカバリ・プロトコル)と呼ばれる。SSDPは、デバイスが提供するサービスの告知(announcement)をデバイスが定期的にマルチキャストすることに基づく。告知は、サービスアクションが送信されるべき、コントロールサーバのURLを含む。それに加えて、CPは、特定のデバイスタイプ若しくはサービスタイプ又はデバイスインスタンス若しくはサービスインスタンスに関してUPnPネットワークに問い合わせをする場合がある。
【０００７】
UPnPは、TCPに基づき、状態変数サブスクリプション及び変更通知機構(change notification mechanism)を規定するGENA(Generic Event Notification Architecture)を利用する(rely on)。
【０００８】
CPは(SSDPを介して)使用したいサービスを検出した後、SCPアクションをコントロールサーバのURLに送信するか、又は状態変数を問い合わせることによりサービスを制御する。アクションは、HTTP POSTメッセージを使用して送信される。このようなメッセージのボディ(body:本体)は、SOAP(Simple Object Access Protocol)標準規格で規定される。SOAPは、XMLに基づく、リモート・プロシージャ・コール機構を規定する。
【０００９】
UPnP AV(音声／映像)の仕様は、TVセット、ビデオレコーダ、DVDプレイヤ、セットトップボックス(STB)、PCなどのUPnP AVデバイスと、関連するCPとの間の相互通信に関連する。UPnP AVの仕様は、メディアサーバ(MediaServer)デバイス、メディアレンダラ(MediaRenderer)デバイス、及びそれらのサービスを規定する。ネットワーク上のメディアサーバ(MS)は、AVコンテンツを格納し、ネットワーク上の他のデバイスにそれを提供する(expose)。コンテンツアイテムは、階層的に格納され、それは例えば、PC上での電子的ファイリングシステムにおけるファイルフォルダに似ている。ネットワーク上のメディアレンダラ(MR)は、MSに格納されたAVコンテンツを再生するか、さもなければ処理する。MRは、そのコンテンツがどのように描画される(be rendered)か(例えば、ボリューム、明るさ、コントラスト等)を制御する機構を備えるCPを与えるレンダリング制御(RC)サービスを実現することができる。
【００１０】
UPnPにおける接続マネージャ(CM)は、AVデバイスのストリーミング能力をモデル化し、それらの能力をデバイス間で結びつけることを可能にするサービスタイプである。UPnP AVデバイスモデルによるストリームを送信又は受信することが可能なデバイスはそれぞれ、CMサービスのインスタンスを１つ持つ。このサービスは、CPが以下のことを行うための機構を提供する：ソース／サーバデバイスとシンク(sink)／レンダラデバイスとの間の能力マッチングを行うこと；ネットワークで現在進行中の転送に関する情報を発見すること；及びデバイス間の接続を開始(setup)し、終了(teardown)することである。CMサービスは種々の種類のストリーミング機構、例えば、HTTPベースのストリーミング、RTSP/RTPベースのストリーミング及び1394ベースのストリーミングを適切に抽出する。CMは、接続確立時にCPが物理的なメディアインターコネクト技術から抽出を行うことを可能にする。
【００１１】
UPnPにおけるAVトランスポート(AVT)サービスは、CPがコンテンツのフローを制御することを可能にするアクションを提供する。これは、例えば、再生、停止、一時停止、シーク(seek)といった操作を含む。CPは、AVTを用い、再生されるべきコンテンツを識別する。これは、所望のコンテンツ並びに選択されたプロトコル及びフォーマットに対してコンテンツディレクトリサービス(CDS)より得られるURIをフォワードすることにより達成される。コンテンツの転送用プロトコルに依存して、MS又はMRのどちらかがAVTサービスのインスタンスを提供してもよい。選択されたプロトコルが「プル(pull)」モデル(例えば、HTTP GET)であれば、MRは、コンテンツのフロー制御(例えば、再生、停止、シーク)用にAVTのインスタンスを提供することが必要とされる。選択されたプロトコルが「プッシュ(push)」モデルであれば、サーバは、AVTのインスタンスを提供しなければならない。
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本願発明の発明者は、UPnP AVフレームワークが生放送(live)又は直接の(direct)コンテンツの記録のみを許容すること、つまり、スケジュールされた(scheduled)記録を提供することは何らなされていないことに気がついた。従って、UPnPにおいて、将来における何時かに放送されるであろう特定のテレビ番組を記録するために、前もって準備することは事実上不可能である。そこで、本願発明の発明者は、スケジュールされた記録を可能にすることにより、現在のUPnP規格の拡張を提案する。この拡張は、１つのベンダ特有の拡張を追加することにより現在の規格の上に構築され、現在のUPnP標準規格の精神において存在する機能をできる限り再利用する。
【課題を解決するための手段】
【００１３】
基本的なアイデアは、遅延された(つまり、将来の)接続の概念を導入することを用いて、スケジュールされた記録を可能にすることである。UPnPにおいて、リソースの予約はCMサービスにより管理される。しかしながら、現在の標準規格では、デジタル相互接続の両端の各CMエンティティ(entity)による即時の(immediate)接続を要求することのみが可能である。スケジュールされた記録のためには、例えば、「PrepareForDelayedConnection(遅延接続準備)」と呼ばれる新しいアクションがCMに追加される。このアクションは、将来における特定の時間スロットのためにリソース(つまり、この場合チューナと記録機(recording))を予約するのに使用されることができるという意味で「PrepareForConnection(接続準備)」を拡張する。チューナ(ソース)からレコーダ(シンク)へのコンテンツの実際のストリーミングは、「ScheduledStartTime(予定開始時間)」と「ScheduledStopTime(予定終了時間)」とで限定される時間スロット内で発生することになる。この情報は、チューナ(ソース)デバイスのCDSから容易に得られることができる。
【００１４】
より詳細には、本発明は、それぞれが個別の接続マネージャ(ConnectionManager)サービスを持つ、複数のUPnP準拠リソース間の接続を確立することを可能にする方法に関する。その方法は、前もって決められた時間に確立され、かつ一定の時間期間維持されるそれぞれのリソース間の接続を交渉するのに、UPnP制御ポイント(ControlPoint)が個別のサービスを使用することを可能にするよう、その個別の接続マネージャサービスを設定することを有する。本発明の本実施形態は、例えば、電子コンテンツ情報の配達網(delivery chain)におけるエンドユーザの上流に位置し、エンドユーザのUPnPネットワークのセットアップを支援するサービス提供者又は別の団体に関連性がある。
【００１５】
本発明は、それぞれが個別の接続マネージャサービスを持つ、複数のUPnP準拠リソース間の接続を確立する方法にも関する。その方法は、前もって決められた時間に確立され、かつ一定の時間期間維持されるそれぞれのリソース間の接続を交渉するのに、UPnP制御ポイントがその個別のサービスを使用することを可能にするよう設定されるその個別の接続マネージャサービスを用いることを有する。本実施形態は、例えば、UPnPホームネットワークの操作的な使用を行う状況のエンドユーザに関連性がある。
【００１６】
リソースは、例えば、放送チャネル(例えば、インタネット、ラジオ又はテレビ)に同調(tune)するチューナ及び放送を記録するレコーダとを有する。
【００１７】
本発明は、前もって決められた時間に確立され、かつ一定の時間期間維持される別のデバイスとの接続を別の接続マネージャサービスと交渉するのに、UPnP制御ポイントがそのサービスを使用することを可能にするよう設定される接続マネージャサービスを持つUPnP準拠デバイスにも関する。そのデバイスは、例えば、放送チャネルに同調するチューナ及び／又はコンテンツ情報を記録するレコーダを有する。
【００１８】
本発明は、複数のUPnP準拠リソース間の接続を確立することを可能にする制御ソフトウェアにも関する。リソースはそれぞれ、個別の接続マネージャサービスを持つ。ソフトウェアは、前もって決められた時間に確立され、かつ一定の時間期間維持される各リソース間の接続を交渉するのに、UPnP接続ポイントがその個別のサービスを使用することを可能にするようその個別の接続マネージャを設定する動作を行わせる(operative)。
【発明を実施するための最良の形態】
【００１９】
本発明は、対応する図面を参照し、例を介して、一層詳細に説明される。
【００２０】
図面において、同じ参照番号は、類似又は対応する機能を示す。
【００２１】
以下に、将来の放送からの音声及び／又はビデオコンテンツに関するスケジュールされた(又はプログラムされた)記録をサポートするよう、知られたUPnP A/Vネットワーク構造がどのように拡張されることができるかが詳細に説明される。
【００２２】
まず、次の高レベルのネットワークエンティティが導入される。
【００２３】
チューナデバイス(即ち、ソースデバイス)は、CDSを介してチャネルと、オプションで利用可能な電子番組ガイド(EPG)とを提供(expose)するUPnP MSデバイスとしてモデル化される。CMサービスは、チューナリソースを管理するために用いられることになり、AVTサービスは、放送コンテンツをRTP等を用いてネットワーク上へプッシュ(push)するのに用いられることになる。
【００２４】
レンダリングデバイスは、生放送又は記録物を(リモートで)描画するのに使用されるUPnP MRとしてモデル化される。これは、CMサービスと、オプションでAVTサービスと、RCサービスとを伴う標準的なUPnP MRである。
【００２５】
記録デバイスは、UPnP MSとしてモデル化される。ネットワークを介してストリーミングされるコンテンツに対して、記録デバイスは、MR同様、シンク(sink)として機能する。
【００２６】
CPは、放送の記録をスケジュールし、その後MRに対して記録の再生を制御するのに使用される。
【００２７】
これらはすべて論理上のエンティティであることに留意されたい。これらのエンティティの２つ又は複数は、１つの物理的なデバイスに結合されることができる。例えば、ネットワーク対応のA/Vレコーダは、チューナチャネルと、ネットワーク向けに手元に(locally)格納されたコンテンツとを提供するMSを含むことが最も起こりやすいであろう。更に、それは、接続されたディスプレイの(アナログ)出力に対して記録済みコンテンツ又は生放送を再生するMRを含むことができる。その上、MS及びMRを制御するCPをも含むことができる。
【００２８】
図１は、本発明のシステム１００のブロック図であり、UPnPネットワークにおけるチューナ１０２、レコーダ１０４及びCP１０６の連携を示す。CP１０６は、UPnPアクション１０８を呼び出すことを介してチューナ１０２とレコーダ１０４とを制御する。レコーダ１０４は、RTSP/RTP等の適切な転送プロトコル１１０を用いてチューナ１０２からコンテンツを受信する。
【００２９】
システム１００がスケジュールされた放送と共に機能するために、以下の問題が解決されるべきである：
−  リソース(即ち、接続)のスケジュール(scheduling)と予約
−  EPGのCDSへのマッピング
−  ネットワークにおける(MPEG-2)のトランスポートストリームのストリーミング。
【００３０】
ネットワーク相互接続のいずれかの側にあるリソースのスケジュールに関して、これは、UPnP CMサービスの簡単な拡張を用いて実現されることができる。本目的のため、本願発明者は、遅延又は将来の接続の概念を導入した。これは、CMがそれぞれのリソースを予約することを可能にする。ソースデバイス、ここではチューナ１０２は、チューナチャネルを予約し、レコーダ１０４は、その格納に対する帯域幅を予約する。遅延接続の概念は、アドホックネットワークの本質を維持することに留意されたい。中央制御エンティティは必要ではない。
【００３１】
現在のスペックにおいては、CMサービスは、即時的な使用のための接続をセットアップすることのみを許容する。「PreparedForConnection」アクションコマンドの拡張が、スケジュールされた記録をなすための将来の接続をセットアップするのに必要とされる。このためには、新しく、可能であれば、ベンダ特有のアクション「PreparedForDelayedConnection」がCMに追加される。
【００３２】
図２は、「PreparedForDelayedConnection」アクションの引数(argument)をリストにした表である。本発明による追加的な引数は、ボールド文字で与えられる。
【００３３】
「PreparedForDelayedConnection」機能は、遅延された放送、つまり、レコーダ１０４がプログラムされた後に、その開始時間及び／又は終了時間が変更される放送を自動的に再調整するものではない。この状況は、記録されるべきチャネルを含むCDS(図示省略)を定期購読(subscribe)するレコーダ１０４に組み込まれたCP(図示省略)を持つことにより処理されることができる。スケジュールされた時間が変更するとき、適切なアクションを呼び出すために使用されることができるイベントがCPで引き起こされることになる。予約された接続のスケジュールされた開始／終了時間は、チューナ１０２のMSとレコーダ１０４のMSとの間の新たな(遅延)接続を再交渉することにより更新されることができる。スケジュールされた記録のキャンセルは、互いに接続の反対側にあるCMにおいて共に「ConnectionComplete(接続完了)」アクションを呼び出すだけの事である。簡便のためには、追加的なアクションがこのシナリオを実行するために追加されることができる。
【００３４】
EPGのマッピングに関しては、好ましい実施形態として、CDSを用いるネットワークへEPG情報を提供する。「object.item.videoItem.videoBroadcast」と呼ばれる特別な「upnp:class」が、「放送として解釈されるビデオの連続的なストリーム」としてオリジナルのUPnP規格において規定されている。このUPnPクラスは、チューナ１０２のチャネルと、(図示省略された)ユーザインタフェースにおいてグラフィカルにチャネルを表すアイコンとをそれぞれ示すよう規定される特殊な「channelNr」特性と「icon」特性とを持つ。こうして、CDSにおける標準オブジェクトがチューナ１０２の特有のチャネルに同調するのに用いられることができる。
【００３５】
「object.item.videoItem.movie」クラスは、特性「channelName」と「scheduledStartTime」と「scheduledStopTime」とを持つ。これらのオブジェクトは、スケジュールされた記録をなすために必要なすべての情報を含む。その規格によれば、実際の記録は、「object.item.videoItem.movie」として記述されるべきである。
【００３６】
図３は、(１つのチューナ及び２つのチャネルを備える)チューナ１０２のCDS構造の一例である。「item.videoItem.videoBroadcast」オブジェクトは、コンテナ(container)タイプではないことに留意すべきである。従って、図３の例における階層は、厳密に言えば、標準規格に準拠していない場合がある。けれども、操作的な観点又は技術的な観点からは、何ら問題はない。
【００３７】
トランスポートストリームに関しては、AVコンテンツの実際のストリーミングは、帯域外で生じる。そこで、いずれかの適切な転送プロトコルが原則は可能である。しかしながら、すべてのデジタル放送がMPEG-2トランスポートストリームに基づくものであり、チューナがプッシュモデルに従い動作するため、本目的には、RTP/RTSPインターネット・ストリーミング・プロトコルを用いると都合が良い。UPnPを用いてRTPストリームをセットアップすることは、UPnP AV規格によりカバーされ、本書において更に詳細に論じる必要はない。
【００３８】
図４は、スケジュールされた記録をなすためのシナリオにおいて、システム１００のエンティティ間での相互通信４０２−４２０のシーケンス４００を示す図である。図５−１１は、このシナリオにおいてネットワーク１００上で呼び出される様々なアクションを、擬似コード(pseudo-code)により示す。
【００３９】
まず、UPnPにおけるディスカバリ機構を用いて、CP１０６は、ネットワーク１００上の関連するMS及び／又はMR、例えば、チューナ１０２及びレコーダ１０４を発見する。次に、CP１０６は、所望のコンテンツの位置を把握する(locate)。本実施例のシナリオにおいて、所望のコンテンツは、EPGに含まれるチューナチャネルとスケジュールされた放送番組とを含む。図４のステップ４０２において、CP１０６は、チューナ１０２のMSでの、ContentDirectory::Browse()又はContentDirectory::Searchアクションを用いて所望のコンテンツの位置を把握する。図５は、Browse Request(閲覧要求)及びResponse(応答)を示す。ステップ４０４においてBrowse()/Search()によりCP１０６へ返信される情報は、チューナ１０２のMSによりサポートされる転送プロトコル及びデータフォーマットに関する情報を含む。図６は、ステップ４０８において、レコーダ１０４のMSによってサポートされる転送プロトコル及びデータフォーマットのリストをCP１０６へレコーダ１０４のMSが返信することを、ステップ４０６のConnectionManager::GetProtocolInfo()アクションが如何にしてもたらすかを擬似コードにより示す。これらは、レコーダ１０４の記憶媒体でデータを記録するのに使用されることができる転送プロトコル及びデータフォーマットである。それから、チューナ１０２におけるMSの所望のContent Item(コンテンツアイテム)用の、CDSにより返信されるプロトコル／フォーマット情報が、レコーダ１０４におけるMSのGetProtocolInfo()アクションにより返信されるプロトコル／フォーマット情報に対してマッチングが行われる。その逆もまた行われる。CP１０６は、チューナ１０２のMSと、レコーダ１０４のMSとの両方でサポートされる転送プロトコル及びデータフォーマットを選択する。ステップ４１０及び４１２において、CP１０６により開始されるConnectionManager::PrepareForDelayedConnection()アクションは、チューナ１０２とレコーダ１０４とのMSに、選択された特定の転送プロトコル及びデータフォーマットを用いて、出力／入力接続がまさにスケジュールされようとしていることを通知する。図７は、記録をスケジュールするためにCP１０６により発行される例示的なアクション呼び出しを与える。例えば、利用可能でないという理由で、リソースの１つ又は両方がこの要求を満たすことができない場合、CP１０６は、返信されるエラーメッセージにより通知される。両方のリソースが要求を満たすことを仮定する。続いて、図８に示されるように、CP１０６がレコーダ１０４のMS上でアクションを呼び出す。コンテンツデータのフローを制御するため、デバイスのAVTサービスと共にInstanceIDが使用される(つまり、そのデバイスはステップ４１４及び４１６においてAVT InstanceIDを返信する)。SetAVTransportURI４１８を呼び出すことは、選択されたソース(例えば、チューナチャネル)に関連付けられるURLが選択されることをもたらす。ここではURLは、システム１００のネットワークから調達される(be sourced)コンテンツを一意に識別するものであり、チューナ１０２で選択される。アクション４２０は、AVTサービスに関して実際の記録を開始する。スケジュールされた記録の本実施例において、scheduledStartTimeが開始するまで記録が開始しないことに留意されたい。オリジナルのUPnP規格によれば、通常、記録は直ちに開始��れることに留意されたい。
【００４０】
図９は、CP１０６がAVTサービスを用いて、転送される必要のある(即ち記録される)コンテンツアイテムを識別するアクションを呼び出すことを示す。そのInstanceIDは、チューナ１０２又はレコーダ１０４のMSのいずれか一方により返信される。AVTサービスを用いることにより、CP１０６は、図１０に説明されるように、記録アクションを呼び出す。実際の記録がscheduledStartTimeで行われることになり、scheduledStopTimeまで持続することになることに留意されたい。AVTサービスによれば、記録の対象(object)がデバイスに依存する態様で、レコーダ１０４のCDSに追加されることになる。これは、明示的なCreateObject()アクション呼び出しが何ら必要とされないことを意味する。記録セッションが終了すると、チューナ１０２及びレコーダ１０４のMSはもはやセッションの状況においては必要でない。図１１のコードに示されるように、それぞれのConnectionMgr::ConnectionComplete()アクションがステップ４２２及び４２４でMS接続を閉じるために呼び出される。
【００４１】
上述の例は、スケジュールされた放送の記録を前もって準備するシナリオにおける遅延接続の概念を説明する。UPnPフレームワークにおける遅延接続の概念は、UPnPデバイス又は機能におけるCMが前もって決められた時間に接続をセットアップすることになる、広範な様々なシナリオに適用可能である。他のシナリオの例は、本書で参照により含まれる「Eugene Shteyn」による「ACTIVITY SCHEDULE CONTROLS PEASONALIZED ELECTRONIC CONTENT GUIDE」2001年3月8日付け出願のUSシリアル番号 09/802,618(代理人文書 US 018028)、US 特許出願公開 20020133821において論じられている。この文書は、ユーザの電子カレンダにスケジュールされた活動及びユーザのプロファイル又は宣言された興味に基づき、電子コンテンツ情報及び再生(play-out)の時間スロットを選択する事に関する。この態様において、コンテンツの記録、ダウンロード及びレンダリングは、ユーザのライフスタイルに基づき自動化される。
【図面の簡単な説明】
【００４２】
【図１】本発明におけるUPnP制御システムのブロック図である。
【図２】UPnPアクションに対する新たな拡張の引数を分類する表である。
【図３】チューナデバイスのCDSの階層構造の例である。
【図４】図１のシステムにおけるエンティティ間の相互通信のシーケンスである。
【図５】図１のシステムにおけるアクションに関する擬似コードの例である。
【図６】図１のシステムにおけるアクションに関する擬似コードの例である。
【図７】図１のシステムにおけるアクションに関する擬似コードの例である。
【図８】図１のシステムにおけるアクションに関する擬似コードの例である。
【図９】図１のシステムにおけるアクションに関する擬似コードの例である。
【図１０】図１のシステムにおけるアクションに関する擬似コードの例である。
【図１１】図１のシステムにおけるアクションに関する擬似コードの例である。
【図１】
2007510330.tif 000003
【図２】
2007510330.tif 000004
【図３】
2007510330.tif 000005
【図４】
2007510330.tif 000006
【図５】
2007510330.tif 000007
【図６】
2007510330.tif 000008
【図７】
2007510330.tif 000009
【図８】
2007510330.tif 000010
【図９】
2007510330.tif 000011
【図１０】
2007510330.tif 000012
【図１１】
2007510330.tif 000013
【国際調査報告】
2007510330.tif 000014
2007510330.tif 000015
2007510330.tif 000016