JP2009069968A - サービスの制御装置、及び方法 - Google Patents

Abstract

【課題】 他のネットワークに存在するサービスを利用するために、そのネットワークに接続しても、利用したいサービスが開始されていないと、サービスの提供を受けることができない。
【解決手段】 コントローラ３２は、セッション接続要求（Ｆ１０１）を受信すると、ネットワーク内に存在するサービス（ストレージサーバ３１）をデータ要求待ち状態に設定する（Ｆ１０６）。そして、そのサービスがデータ要求待ち状態に設定されたことを確認してから（Ｆ１０８）、最終応答（Ｆ１０９）を送信する。
【選択図】 図３

Description

本発明は、第１のネットワークと第２のネットワークとを接続して実行するサービスを制御する制御方法に関する。

近年、デジタルテレビ、ハードディスクレコーダ、パーソナルコンピュータなどの家電機器を家庭内等でネットワークシステム化し、それら各機器を連動させてマルチメディアデータを取り扱うことが可能となっている。このようなネットワークには、例えば、無線ＬＡＮや有線ＬＡＮがあり、ＬＡＮ上でデータをやり取りする仕様として、ＤＬＮＡ（Ｄｉｇｉｔａｌ Ｌｉｖｉｎｇ Ｎｅｔｗｏｒｋ Ａｌｌｉａｎｃｅ Ｈｏｍｅ）で仕様化されているプロトコルがある。

一方、通信装置間で確立された仮想的な通信路（セッション）に基づいて、ＩＰ網上における通信を実現する技術が普及しつつある（例えば、特許文献１）。ここで、通信装置間のセッションの確立、維持、切断を制御するためのセッション制御プロトコルとして、ＳＩＰ（Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ；ＲＦＣ３２６１）と呼ばれるプロトコルがある。その仕様はＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）により公開されている。
特開２００５−３３５２８号公報

しかしながら、他のネットワークに存在するサービスを実行する場合、以下のような問題が生じる。

即ち、ネットワーク同士を接続しても、利用したいサービスが開始されていない状態では、サービスの提供を受けることができない。

ここで、例として、セッションの確立に基づき、ＤＬＮＡで規定されているＤＭＰ機能をもったデジタルテレビと、ＤＬＮＡで規定されているＤＭＳ機能をもったストレージサーバとの間で行われるサービスを挙げる。尚、ＤＭＰはＤｉｇｉｔａｌ Ｍｅｄｉａ Ｐｌａｙｅｒであり、コンテンツを再生するクライアントである。また、ＤＭＳはＤｉｇｉｔａｌ Ｍｅｄｉａ Ｓｅｒｖｅｒであり、コンテンツを提供するサーバである。

このとき、ストレージサーバのサービスが未稼動の状態であると、デジタルテレビは、ストレージサーバからサービスを受けることができない。

また、ＳＩＰを用いると、他の機器を呼び出すことができるが、呼び出すことができるのは、ＳＩＰに対応した機器に限られる。

また、サービスを行う機器に対して、データを提供できる状態にするためのコマンドがわからない場合がある。

本発明は上記の問題点に鑑みてなされたものであり、その目的は、ネットワーク同士の接続完了前に、接続されるネットワーク内のサービスをデータが提供できる状態にすることである。

また、本発明の目的は、セッションの接続に関するプロトコルに対応していない機器のサービスを受けられるようにすることである。

上記の課題を解決するために、本発明の通信装置は、以下の構成を有する。即ち、第１のネットワークに接続された通信装置であって、第２のネットワークから送信される接続要求を受信する受信手段と、前記接続要求の受信に応じて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手段と、前記サービスがデータ要求待ち状態に設定されたことを確認してから前記接続要求に対する応答を送信する送信手段とを有する。

また、本発明の通信装置は、第２のネットワークに接続された通信装置であって、第１のネットワークへ接続要求を送信する送信手段と、前記接続要求に対する応答を受信する受信手段と、前記第２のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手段とを有し、前記送信手段は、前記サービスがデータ要求待ち状態に設定されたことを確認してから前記応答に対する応答確認を送信する。

本発明によれば、ネットワーク同士の接続完了前に、接続されるネットワーク内のサービスをデータが提供できる状態にすることができる。

また、本発明によれば、データを提供できる状態にするためのコマンドが未知のサービスを、データが提供できる状態に設定することができる。

また、本発明によれば、セッションの接続に関するプロトコルに対応していない機器のサービスを受けられるようにすることができる。

以下、図面を参照して、本発明の好適な実施形態について詳細に説明する。

＜実施形態１＞
以下、本発明の実施形態について、図面を参照して説明する。

図１は、本発明の実施形態に係るネットワークシステムの構成図である。

同図において、１及び３は、それぞれルータ１３及び３３を介してインターネット２に接続されるホームネットワークである。ホームネットワークは、無線ＬＡＮでも、有線ＬＡＮであっても良い。

１１は、ホームネットワーク１に接続され、ＤＬＮＡで規定されているＤＭＰ機能をもったデジタルテレビである。デジタルテレビ１１は、ホームネットワーク１内のサービスを提供する機器である。

３１は、ホームネットワーク３に接続され、ＤＬＮＡで規定されているＤＭＳ機能をもったストレージサーバである。ストレージサーバ３１は、ホームネットワーク３内のサービスを提供する機器である。

１２及び３２は、それぞれホームネットワーク１およびホームネットワーク３に接続され、ＤＬＮＡで規定されているＣＰ（Ｃｏｎｔｒｏｌ Ｐｏｉｎｔ）機能をもったコントローラである。ＤＬＮＡでは、ＣＰはデバイス（デジタルテレビ、ストレージサーバ）を操作する機能として定義されている。また、コントローラ１２およびコントローラ３２は、リモートのネットワークとのセッションの確立、即ち、コントローラ１２とコントローラ３２の間（ホームネットワーク１とホームネットワーク３の間）の接続を、ＳＩＰによって実行する機能を有する。コントローラ１２、３２は、ネットワーク（ホームネットワーク１、３）に接続された通信装置である。

２は、インターネットである。ただし２は、ＩＰ網であれば、例えば通信キャリア網やＮＧＮ網等であっても構わない。

１３及び３３は、インターネット２とホームネットワーク１及び３との間に位置し、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）トラバーサルや、ファイアウォールなどの通信転送機能を有するルータである。尚、コントローラ１２、３２の機能の一部を、ルータ１３、３３が行うようにしても良い。

２１は、インターネット２の中にあり、ＳＩＰによるアドレス解決やメッセージの転送など、各種セッション制御サービスを提供するセッション制御サーバである。

図２は、本実施形態におけるコントローラ１２、及び３２のハードウェア構成を示したものである。コントローラ１２、３２は、ネットワーク（ホームネットワーク１、３）に接続された通信装置である。

尚、コントローラ１２、及び３２は、ＰＣ（パーソナルコンピュータ）などのコンピュータシステムには限られない。すなわち、コンピュータシステム以外に、ワークステーション、ノートブックＰＣ、パームトップＰＣ、コンピュータを内蔵した各種家電製品、通信機能を有するゲーム機、携帯電話、ＰＤＡ、リモートコントローラ等でも実施可能である。また、コントローラ１２、及び３２は、データ受信サービス、及びデータ供給サービスを提供する装置と一体となっていても構わない。

２０１は、コンピュータシステムの制御をつかさどる中央演算装置（以下ＣＰＵと記す）である。２０２は、ランダムアクセスメモリ（以下ＲＡＭと記す）であり、ＣＰＵ２０１の主メモリとして、及び実行プログラムの領域や該プログラムの実行エリアならびにデータエリアとして機能する。

２０３は、ＣＰＵ２０１の動作処理手順を記録しているリードオンリーメモリ（以下ＲＯＭと記す）である。ＲＯＭ２０３には、コンピュータシステムの機器制御を行うシステムプログラムである基本ソフト（ＯＳ）を記録したプログラムＲＯＭとシステムを稼動するために必要な情報などが記録されたデータＲＯＭがある。ＲＯＭ２０３の代わりに後述のＨＤＤ２０９を用いる場合もある。

２０４は、ネットワークインターフェース（以下ＮＥＴＩＦと記す）であり、ネットワーク（例えば、ホームネットワーク１）を介してコンピュータシステム間のデータ転送を行うための制御や接続状況の診断を行う。コントローラ１２のＮＥＴＩＦ２０４は、ホームネットワーク１内のデジタルテレビ１１との間で信号を送受信する。すなわちコントローラ１２は、例えば本実施形態でデジタルテレビ１１との間で行われる、ＤＬＮＡに基づくサービス検索、サービス情報取得、サービス開始要求の各工程における信号の送受信を、ＮＥＴＩＦ２０４から行う。また、コントローラ１２は、サービス提供機器やコントローラ３２から送信されるデータ要求の信号の受信、及び転送を、ＮＥＴＩＦ２０４から行う。

また、コントローラ１２のＮＥＴＩＦ２０４は、ルータ１３、インターネット２、ルータ３３を介して、コントローラ３２との間の信号の送受信を行う。すなわちコントローラ１２は、例えば本実施形態でコントローラ３２との間で行われる、ＳＩＰの接続要求、最終応答、応答確認等の信号の送受信を、ＮＥＴＩＦ２０４から行う。

コントローラ３２のＮＥＴＩＦ２０４は、ホームネットワーク３内のストレージサーバ３１との間で信号を送受信する。すなわちコントローラ３２は、例えば本実施形態でストレージサーバ３１との間で行われる、ＤＬＮＡに基づくサービス検索、サービス情報取得、サービス開始要求の各工程における信号の送受信を、ＮＥＴＩＦ２０４から行う。また、コントローラ３２は、サービス提供機器やコントローラ１２から送信されるデータ要求の信号の受信、及び転送を、ＮＥＴＩＦ２０４から行う。

また、コントローラ３２のＮＥＴＩＦ２０４は、ルータ３３、インターネット２、ルータ１３を介して、コントローラ１２との間の信号の送受信を行う。すなわちコントローラ３２は、例えば本実施形態でコントローラ１２との間で行われる、ＳＩＰの接続要求、最終応答、応答確認等の信号の送受信を、ＮＥＴＩＦ２０４から行う。

２０５は、ビデオＲＡＭ（以下ＶＲＡＭと記す）であり、コンピュータシステムの稼動状態を示す後述するＣＲＴ２０６の画面に表示される画像を展開し、その表示の制御を行う。２０６は、表示装置であって、例えば、ディスプレイである。以下ＣＲＴと記す。

２０７は、後述する外部入力装置２０８からの入力信号を制御するコントローラである。２０８は、コンピュータシステムの利用者がコンピュータシステムに対して行う操作を受け付けるための外部入力装置であり、例えば、キーボードなどである。

２０９は、記憶装置を示し、例えば、ハードディスクなどである。アプリケーションプログラムや、画像情報などのデータ保存用に用いられる。本実施形態におけるアプリケーションプログラムとは、本実施形態を構成する、セッションの確立手順中にサービス開始の指示を行うソフトウェアプログラムなどである。

２１０は、外部入出力装置であって、例えばフロッピー（登録商標）ディスクドライブ、ＣＤ−ＲＯＭドライブなどのリムーバブル記憶メディアを入出力するものであり、上述したアプリケーションプログラムの媒体からの読み出しなどに用いられる。以下、ＦＤＤと記す。なお、ＨＤＤ２０９に格納するアプリケーションプログラムやデータをＦＤＤ２１０に格納して使用することも可能である。

２００は、上述した各ユニット間の接続するための入出力バス（アドレスバス、データバス、及び制御バス）である。

次に、本実施形態に関する、コントローラ１２、３２のソフトウェア構成について、説明する。図１２は、本実施形態に係るソフトウェア構成を示した図である。尚、当該ソフトウェアは、例えばＨＤＤ２０９に記憶され、ＣＰＵ２０１から必要に応じて適宜ＲＡＭ２０２に読み出され、実行される。

１２０１は、サービスの制御などを行うアプリケーション部であり、後述するサービス種別判断部１２０１ａ、サービス起動制御部１２０１ｂを含む。

サービス種別判断部１２０１ａは、サービスを提供する機器（ストレージサーバ３１、デジタルテレビ１１）のサービス種別が、データを供給するサービスかデータを受信するサービスかを判断する。

サービス起動制御部１２０１ｂは、サービス種別判断部１２０１ａの判断結果に基づいて、サービスを開始させるための指示を行う。

１２０２は、サービスを提供する機器の発見や、サービスの開始を指示するために、ＤＬＮＡで規定された各種プロトコルに従い、制御メッセージの送受信を行うＤＬＮＡ制御部である。また、ＤＬＮＡ制御部１２０２は、サービスを提供する機器からの応答を受信することにより、当該機器のサービスが開始されたことを確認する。

１２０３は、コントローラ１２、３２間でセッションを確立するために、ＳＩＰの規定に従い、制御メッセージの送受信を行うＳＩＰ制御部である。

１２０４は、通信ネットワークで標準的に使用されるＴＣＰ／ＩＰのプロトコルを用いて、ＤＬＮＡ制御部１２０２や、ＳＩＰ制御部１２０３でやり取りするメッセージの伝送を行うＴＣＰ／ＩＰである。

コントローラ１２のアプリケーション部１２０１は、ＤＬＮＡ制御部１２０２、ＴＣＰ／ＩＰ１２０４を介して、コントローラ３２との間で通信を行う。また、コントローラ１２のアプリケーション部１２０１は、ＳＩＰ制御部１２０３、ＴＣＰ／ＩＰ１２０４を介して、デジタルテレビ１１との間で通信を行う。コントローラ３２のアプリケーション部１２０１は、ＤＬＮＡ制御部１２０２、ＴＣＰ／ＩＰ１２０４を介して、コントローラ１２との間で通信を行う。また、コントローラ３２のアプリケーション部１２０１は、ＳＩＰ制御部１２０３、ＴＣＰ／ＩＰ１２０４を介して、ストレージサーバ３１との間で通信を行う。

次に、本実施形態におけるサービス開始手順について、データ供給サービスがストレージサーバ、データ受信サービスがデジタルテレビ、セッション制御プロトコルがＳＩＰである場合の手順を説明する。

まず、セッション接続の要求が、デジタルテレビ１１側ネットワークに接続されるコントローラ１２によって発信される場合のサービス開始手順について、図３を用いて説明する。図３は、ホームネットワーク１が、発信側ネットワーク（第２のネットワーク）であり、ホームネットワーク３が、着信側ネットワーク（第１のネットワーク）の場合のサービス開始手順を示す。この場合、接続要求であるＩＮＶＩＴＥリクエストはホームネットワーク１からホームネットワーク３に送信される。詳細には、ユーザが、コントローラ１２に、コントローラ３２のＳＩＰＵＲＩ（ＳＩＰ Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｓｅ Ｉｄｅｎｔｉｆｉｅｒ）を入力する。そして、呼制御サーバ２１が、ＳＩＰＵＲＩをＩＰアドレスに変換し、コントローラ１２からのメッセージをコントローラ３２に転送する。

また、ＩＮＶＩＴＥリクエストに対する応答である２００ ＯＫレスポンスは、ホームネットワーク３からホームネットワーク１に送信される。

同図のＦ１０１において、ホームネットワーク１に接続するコントローラ１２のＳＩＰ制御部１２０３は、ユーザＡの指示に基づき、ホームネットワーク３に接続するコントローラ３２に対し、ＳＩＰのＩＮＶＩＴＥリクエスト（接続要求）を送信する。すなわち、コントローラ３２のＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により、接続要求をＮＥＴＩＦ２０４から送信する。このときユーザＡは、例えば、ビデオの視聴を指示し、コントローラ１２のＳＩＰ制御部１２０３は、ユーザＡによるビデオの視聴の指示に基づいてＳＤＰ情報を生成し、ＩＮＶＩＴＥリクエストのボディに付加する。尚、ＳＤＰとは、Ｓｅｒｖｉｃｅ Ｄｉｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌであり、ＳＤＰ情報には、例えばメディア種別等のメディア情報や、データの通信方向の情報等が示される。ＩＮＶＩＴＥリクエストに付加されるＳＤＰ情報の例を図１１に示す。同図において、メディア情報が１１０１、メディア種別の情報（メディア情報の一部）が１１０２、データの通信方向が１１０３に当たる。本実施形態のようなビデオの視聴の場合は、例えば、メディア種別１１０２に「ｖｉｄｅｏ」、データの通信方向１１０３に「ｒｅｃｖｏｎｌｙ」が示される。ここで「ｒｅｃｖｏｎｌｙ」は、ＩＥＴＦが策定し公開している仕様により、主に「受信サービスである」ということを示している。

コントローラ３２のＳＩＰ制御部１２０３は、ネットワーク（ホームネットワーク１）から送信される接続要求であるＩＮＶＩＴＥリクエストを受信する。すなわち、コントローラ３２のＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により送信された接続要求をＮＥＴＩＦ２０４から受信する。そして、ＳＩＰ制御部１２０３でＩＮＶＩＴＥリクエストを受信したコントローラ３２のＤＬＮＡ制御部１２０２は、後述するＳＳＤＰの処理で得られた情報により、ホームネットワーク３上の、ストレージサーバ３１を発見する（Ｆ１０３）。尚、ＳＳＤＰは、Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌである。

そして、コントローラ３２のＤＬＮＡ制御部１２０２は、ストレージサーバ３１に対し、サービス情報の取得要求を行い、ストレージサーバ３１のサービスを制御するコマンドの情報等を取得する（Ｆ１０４）。尚、Ｆ１０３、Ｆ１０４におけるサービスの発見やサービス情報等の取得は、ＩＮＶＩＴＥリクエスト（Ｆ１０１）の受信後に行っても、受信前に予め行っていても構わない。また、Ｆ１０３、Ｆ１０４の処理の詳細に関しては後述する。

さらに、コントローラ３２のサービス種別判断部１２０１ａは、ＩＮＶＩＴＥリクエストのＳＤＰ情報に含まれるデータの通信方向の情報「ｒｅｃｖｏｎｌｙ」から、ホームネットワーク１側から要求されるサービスの種別を判断する（Ｆ１０５）。本実施形態の場合、当該サービスの種別はデータ供給サービスであると判断される。

この場合、コントローラ３２のサービス起動制御部１２０１ｂは、そのデータ供給サービスを提供するストレージサーバ３１に対し、サービスの開始を指示するコマンド（サービス開始要求）をＮＥＴＩＦ２０４から送信する（Ｆ１０６）。すなわち、コントローラ３２のサービス起動制御部１２０１ｂは、接続要求であるＩＮＶＩＴＥリクエスト（Ｆ１０１）の受信に応じて、ネットワーク（ホームネットワーク３）内に存在するサービスをデータ要求待ち状態に設定する。ここで、コントローラ３２のサービス起動制御部１２０１ｂは、ローカルネットワーク内において機器を制御するためのプロトコル（ＤＬＮＡ）を用いて、ネットワーク（ホームネットワーク３）内に存在するサービスをデータ要求待ち状態に設定する。尚、サービス開始要求のコマンドは、Ｆ１０４で取得されている。

サービス開始要求を受けたストレージサーバ３１は、自身のサービスの開始処理を行い、データ要求待ち状態に設定する（Ｆ１０７）。

ストレージサーバ３１は、サービスの開始処理を完了し、データ要求待ち状態に設定されると、コントローラ３２のＤＬＮＡ制御部１２０２に対して応答を送信する（Ｆ１０８）。ここで、ストレージサーバ３１は、ローカルネットワーク内において機器を制御するためのプロトコル（ＤＬＮＡ）を用いて、ＤＬＮＡ制御部１２０２に対して応答を送信する。

コントローラ３２のＤＬＮＡ制御部１２０２は、ＮＥＴＩＦ２０４経由で応答（Ｆ１０８）を受け取ることで、ストレージサーバ３１がデータ要求待ち状態に設定されたことを確認する。そして、コントローラ３２のＳＩＰ制御部１２０３は、コントローラ１２のＳＩＰ制御部１２０３に対し、ＩＮＶＩＴＥリクエストに対する許諾を意味するＳＩＰの２００ ＯＫレスポンス（最終応答）をＮＥＴＩＦ２０４から送信する（Ｆ１０９）。すなわち、コントローラ３２のＳＩＰ制御部１２０３は、サービスがデータ要求待ち状態に設定されたことを確認してから、ＩＮＶＩＴＥリクエスト（接続要求）に対する応答（２００ ＯＫレスポンス）を送信する。ここで、コントローラ３２のＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により、接続要求に対する応答をＮＥＴＩＦ２０４から送信する。

コントローラ３２のＳＩＰ制御部１２０３は、ＩＮＶＩＴＥリクエスト（Ｆ１０１）を受信してから、２００ ＯＫレスポンス（Ｆ１０９）を送信するまでの任意のタイミングで１ｘｘレスポンス（暫定応答）を送信する（Ｆ１０２）。このようにすることで、ストレージサーバ３１が検索中、又は、サービスの開始処理の途中であることを、接続要求を発信したネットワーク側で知ることができる。ただし、１ｘｘレスポンス（Ｆ１０２）は送信しなくても良い。

また、コントローラ３２のＳＩＰ制御部１２０３は、ストレージサーバ３１を発見できなかった場合、Ｆ１０９において、ＩＮＶＩＴＥリクエストに対する拒絶を意味する４ｘｘレスポンス（最終応答）を返す。また、ストレージサーバ３１を発見したが、サービスを提供できない状態の場合、ストレージサーバ３１のサービスを提供させない場合、また、ストレージサーバ３１がサービス開始処理に失敗した場合なども、同様である。そして、４ｘｘレスポンスを受取ったコントローラ１２のＳＩＰ制御部１２０３は、セッションの接続に失敗したと判断し、接続処理を終了する。このようにすることで、セッションの接続要求はコントローラ３２に届いたが、サービスが受けられない状態であることを、接続要求を発信したネットワーク側で知ることができる。ただし、４ｘｘレスポンスは送信しなくても良い。

ＩＮＶＩＴＥリクエストに対する２００ ＯＫレスポンスをＳＩＰ制御部１２０３で受取ったコントローラ１２のサービス起動制御部１２０１ｂは、デジタルテレビ１１に対し、サービス開始要求を行う（Ｆ１１２）。ここで、ホームネットワーク１上のデジタルテレビ１１の発見は、ＩＮＶＩＴＥリクエスト（Ｆ１０１）送信後のＦ１１０において、Ｆ１０３と同様の手順により発見する。また、デジタルテレビ１１のサービス開始要求のコマンドは、ＩＮＶＩＴＥリクエスト（Ｆ１０１）送信後のＦ１１１において、Ｆ１０４と同様の手順により、デジタルテレビ１１から取得する。ただし、Ｆ１１０、Ｆ１１１のようなサービスの発見、及びコマンドの取得は、予め行っておいても良いし、Ｆ１０９の最終応答を受信したときに行うようにしても良い。

サービス開始要求を受信したデジタルテレビ１１は、データ受信サービス開始処理を行う（Ｆ１１３）。さらに、データ受信サービスの開始処理が完了したデジタルテレビ１１は、コントローラ１２に対して応答を送信する（Ｆ１１４）。

Ｆ１１４で送信される応答をＤＬＮＡ制御部１２０２で受取ったコントローラ１２のＳＩＰ制御部１２０３は、コントローラ３２のＳＩＰ制御部１２０３へＳＩＰのＡＣＫリクエスト（応答確認）を送信する（Ｆ１１５）。

そして、デジタルテレビ１１は、Ｆ１１４において応答を送信後、ストレージサーバ３１に対してデータ要求のためのアクセスを行う（Ｆ１１６）。このとき、コントローラ１２のＳＩＰ制御部１２０３は、データ要求（Ｆ１１６）を、コントローラ３２のＳＩＰ制御部１２０３に転送し、コントローラ３２のＤＬＮＡ制御部１２０２は、そのデータ要求（Ｆ１１６）をストレージサーバ３１に転送する。尚、デジタルテレビ１１は、このデータ要求（Ｆ１１６）をマルチキャストで送信すれば良い。このように、コントローラ３２がＤＬＮＡのコマンドを利用することにより、サービスを提供する機器（ストレージサーバ３１）がセッションの接続のプロトコル（ＳＩＰ）に対応していない場合であっても、サービスを利用することができる。

また、実施形態２のＤＬＮＡ制御部１２０２は、Ｆ１０６、Ｆ１１２のサービスの開始要求の前に、ストレージサーバ３１やデジタルテレビ１１の機器に、ＮＥＴＩＦ２０４からその機器の状態を問い合わせる。そして、機器の電源がＯＦＦになっている、電源はＯＮだがサービスを提供できない等のサービスの状態を確認し、確認された状態に応じてデータ要求待ち状態に設定するためのコマンドを選択する。

このように、データ受信サービス側ネットワークからデータ供給サービス側ネットワークへセッションの接続要求を行い、サービスを開始する際に、データ受信サービスを開始する前に、データ供給サービスが開始される。このことにより、セッションの確立に基づき、データ受信サービスがデータを要求するときに、データ供給サービスがデータを提供できる状態とすることができる。

次に、セッションの接続要求が、ストレージサーバ３１側のネットワークに接続されるコントローラ３２によって発信される場合のサービス開始手順について、図４を用いて説明する。図４は、ホームネットワーク３が、発信側ネットワーク（第２のネットワーク）であり、ホームネットワーク１が、着信側ネットワーク（第１のネットワーク）の場合のサービス開始手順を示す。この場合、接続要求であるＩＮＶＩＴＥリクエストはホームネットワーク３からホームネットワーク１に送信され、ＩＮＶＩＴＥリクエストに対する応答である２００ ＯＫレスポンスはホームネットワーク１からホームネットワーク３に送信される。

同図のＦ２０１において、ホームネットワーク３に接続するコントローラ３２のＳＩＰ制御部１２０３は、ユーザＢの指示に基づき、ホームネットワーク１に接続するコントローラ１２に対し、ＳＩＰのＩＮＶＩＴＥリクエスト（接続要求）を送信する。すなわち、Ｆ２０１では、コントローラ３２のＳＩＰ制御部１２０３が、セッションを接続するためのプロトコル（ＳＩＰ）により、ホームネットワーク１に対して接続要求をＮＥＴＩＦ２０４から送信する。このときユーザＢは、例えば、ビデオの供給を指示し、コントローラ３２は、ユーザＢによるビデオの供給の指示に基づいて前述のＳＤＰ情報を生成し、ＩＮＶＩＴＥリクエストに付加する。このとき、例えばＳＤＰ情報のメディア種別は、「ｖｉｄｅｏ」、データの通信方向の情報は「ｓｎｄｏｎｌｙ」となる。ここで、「ｓｎｄｏｎｌｙ」とは、ＩＥＴＦが策定し公開している仕様により、主に「供給サービスである」ということを示している。

ＳＩＰ制御部１２０３でＩＮＶＩＴＥリクエストを受信したコントローラ１２のＤＬＮＡ制御部１２０２は、後述するＳＳＤＰの処理で得られた情報により、ホームネットワーク１上の、デジタルテレビ１１を発見する（Ｆ２０３）。

そして、コントローラ１２のＤＬＮＡ制御部１２０２は、デジタルテレビ１１に対し、サービス情報の取得要求を行い、デジタルテレビ１１のサービスを制御するコマンドの情報等を取得する（Ｆ２０４）。尚、Ｆ２０３、Ｆ２０４におけるサービスの発見やサービス情報等の取得は、ＩＮＶＩＴＥリクエスト（Ｆ２０１）の受信後に行っても、受信前に予め行っていても構わない。また、Ｆ２０３、Ｆ２０４の処理の詳細に関しては後述する。

さらに、コントローラ１２のサービス種別判断部１２０１ａは、ＩＮＶＩＴＥリクエストのＳＤＰ情報に含まれるデータの通信方向の情報「ｓｎｄｏｎｌｙ」から、ホームネットワーク１側から要求されるサービスの種別を判断する（Ｆ２０５）。本実施形態の場合、当該サービスの種別はデータ受信サービスであると判断される。

そこで、コントローラ１２のサービス起動制御部１２０１ｂは、データ受信サービスに対応するデジタルテレビ１１のサービスを開始させる前に、コントローラ３２に対し、ＩＮＶＩＴＥリクエストに対する２００ ＯＫレスポンス（最終応答）を送信する（Ｆ２０６）。

ＳＩＰ制御部１２０３で２００ ＯＫレスポンス（最終応答）を受取ったコントローラ３２のサービス起動制御部１２０１ｂは、ストレージサーバ３１に対し、サービスの開始を指示するコマンド（サービス開始要求）を送信する（Ｆ２０７）。すなわち、コントローラ３２のＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により送信された、接続要求に対する応答をＮＥＴＩＦ２０４で受信する。さらに、コントローラ３２のサービス起動制御部１２０１ｂは、ローカルネットワーク内において機器を制御するためのプロトコル（ＤＬＮＡ）を用いて、ネットワーク（ホームネットワーク３）に存在するサービスをデータ要求待ち状態に設定する。ここで、ホームネットワーク３上のストレージサーバ３１の発見は、ＩＮＶＩＴＥリクエスト（Ｆ２０１）送信後のＦ２０７において、Ｆ２０３と同様の手順により発見する。また、ストレージサーバ３１のサービス開始要求のコマンドは、ＩＮＶＩＴＥリクエスト（Ｆ２０１）送信後のＦ２０８において、Ｆ２０４と同様の手順により、ストレージサーバ３１から取得する。ただし、Ｆ２０７、Ｆ２０８のようなサービスの発見、及びコマンドの取得は、予め行っておいても良いし、Ｆ２０６で送信される最終応答を受信したときに行うようにしても良い。

サービス開始要求のコマンドを受取ったストレージサーバ３１は、サービス開始処理を行い、データ要求待ち状態に設定する（Ｆ２１０）。そして、ストレージサーバ３１はデータ要求待ち状態に設定されると、コントローラ３２に対して応答を送信する（Ｆ２１１）。

コントローラ３２のＤＬＮＡ制御部１２０２は、当該応答を受け取ることで、ストレージサーバ３１がデータ要求待ち状態に設定されたことを確認する。そして、コントローラ３２のＳＩＰ制御部１２０３は、コントローラ１２へ、ＳＩＰのＡＣＫリクエスト（応答確認）を送信する（Ｆ２１２）。すなわち、コントローラ３２のＳＩＰ制御部１２０３は、ネットワーク（ホームネットワーク３）に存在するサービスがデータ要求待ち状態になったことを確認してから、応答（２００ ＯＫレスポンス）に対する応答確認（ＡＣＫリクエスト）を送信する。ここで、コントローラ３２のＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により、応答に対する応答確認を、ＮＥＴＩＦ２０４から送信する。

コントローラ１２のサービス種別判断部１２０１ａは、Ｆ２０５において、要求されるサービスがデータ受信サービスであると判断している。この場合、ＳＩＰ制御部１２０３にてＡＣＫリクエストを受信したコントローラ１２のサービス起動制御部１２０１ｂは、デジタルテレビ１１から取得したサービスを制御するコマンドを用いてデジタルテレビ１１に対してサービス開始要求を行う（Ｆ２１３）。

サービス開始要求を受けたデジタルテレビ１１は、データ受信サービス開始処理を行う（Ｆ２１４）。

さらに、データ受信サービスの開始が完了したデジタルテレビ１１は、応答をコントローラ１２のＤＬＮＡ制御部１２０２へ送信する（Ｆ２１５）。

Ｆ２１５において応答を送信したデジタルテレビ１１は、ストレージサーバ３１に対してデータ要求のためのアクセスを行う（Ｆ２１６）。

すなわち、ネットワーク（ホームネットワーク１）で行うサービスがデータ受信サービスの場合、コントローラ１２のＳＩＰ制御部１２０３は、接続要求（ＩＮＶＩＴＥリクエスト）に対する応答（２００ ＯＫレスポンス）を送信する。さらにコントローラ１２のサービス起動制御部１２０１ｂは、応答（２００ ＯＫレスポンス）に対する応答確認（ＡＣＫリクエスト）を受信してから、データ受信サービスにデータ要求を開始させる。

このとき、コントローラ１２のＳＩＰ制御部１２０３は、このデータ要求（Ｆ２１６）を、コントローラ３２のＳＩＰ制御部１２０３に転送し、コントローラ３２のＤＬＮＡ制御部１２０２は、このデータ要求（Ｆ２１６）をストレージサーバ３１に転送する。尚、デジタルテレビ１１は、このデータ要求（Ｆ２１６）をマルチキャストで送信すれば良い。このように、コントローラ１２がＤＬＮＡのコマンドを利用することにより、サービスを提供する機器（デジタルテレビ１１）がセッションの接続のプロトコル（ＳＩＰ）に対応していない場合であっても、サービスを利用することができる。

このように、データ供給サービス側ネットワークからデータ受信サービス側ネットワークへセッションの接続要求を行い、サービスを開始する場合において、デジタルテレビ１１のデータ受信サービスを開始する前に、ストレージサーバ３１のサービスを開始させる。このことにより、データ受信サービスは、自身のサービス開始後、データ供給サービスに対してデータ要求を行うことが可能となる。

ここで、ストレージサーバ３１のサービス開始（Ｆ２１０）は、Ｆ２０６の２００ ＯＫレスポンスを受信する前に、コントローラ３２やストレージサーバ３１の操作によって行っても良い。このようにすることで、２００ ＯＫレスポンス（Ｆ２０６）を受信してからＡＣＫリクエスト（Ｆ２１２）を送信するまでの時間を短くすることができる。

また、本実施形態において、図３のデジタルテレビ１１、および図４のストレージサーバ３１は、それぞれコントローラ１２、３２のサービス起動制御部１２０１ｂからのサービス開始要求（Ｆ１１２、Ｆ２０７）を受けて、サービスを開始している。しかし、サービスのためのリソース等の確保や、スタンバイ状態に設定することは、サービス開始要求（Ｆ１１２、Ｆ２０９）が送信される前に、予め行っても良い。設定の方法として、コントローラ３２のＤＬＮＡ制御部１２０２から送信するサービス制御コマンドによる方法や、ユーザによる、デジタルテレビ１１、及びストレージサーバ３１への操作等がある。このようにすることで、２００ ＯＫレスポンスを受信してからＡＣＫリクエストを送信するまでの時間を短くすることができる。

次に、コントローラ１２、及びコントローラ３２のＤＬＮＡ制御部１２０２が、それぞれのホームネットワークに接続されているサービスの発見、及びサービスの種別やサービスを制御するためのコマンドの情報を取得する手順について図５を用いて説明する。尚、ここでは図３の場合を例にとって説明するが、図４におけるコントローラ１２、及び３２のＤＬＮＡ制御部１２０２も、以下の説明と同様の手順により、サービスの種別とサービスを制御するためのコマンドの情報を取得する。

図５において、コントローラ１２のＤＬＮＡ制御部１２０２は、ネットワーク（ホームネットワーク１）に接続されているサービスを検索するため、サービス発見プロトコルのＭ−Ｓｅａｒｃｈ（検索）メッセージをマルチキャスト送信する（Ｆ００１）。尚、サービス発見プロトコルは、ＳＳＤＰ（Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）である。そして、Ｍ−Ｓｅａｒｃｈメッセージを受信したデジタルテレビ１１は、自身のデバイス情報へアクセス可能なＵＲＬなどを記載したＮＯＴＩＦＹ（通知）メッセージをコントローラ１２のＤＬＮＡ制御部１２０２へ返信する（Ｆ００２）。

ＮＯＴＩＦＹメッセージを受信したコントローラ１２のＤＬＮＡ制御部１２０２は、デジタルテレビ１１のデバイス情報の取得を行うために、ＮＯＴＩＦＹメッセージに記載されているＵＲＬへ、ＨＴＴＰのＧＥＴコマンドを送信する（Ｆ００３）。このＵＲＬには、デジタルテレビ１１内の、デバイス情報が格納されているファイルのアドレスが示されている。ＧＥＴコマンドを受信したデジタルテレビ１１は、ＵＲＬに基づき、自身のデバイスタイプ＜ｄｅｖｉｃｅＴｙｐｅ＞や、サービスリスト＜ｓｅｒｖｉｃｅＬｉｓｔ＞等のデバイス情報を読み出す。そして、読み出されたデバイス情報を含む２００ ＯＫレスポンスをコントローラ１２のＤＬＮＡ制御部１２０２に返信する（Ｆ００４）。

コントローラ１２のＤＬＮＡ制御部１２０２は、Ｆ００４でデジタルテレビ１１から送信された２００ ＯＫレスポンスを受信することにより、デジタルテレビ１１のサービスをデータ要求待ち状態に設定するためのコマンドの入手先を取得する。

なお、サービスリストには、サービス毎のサービス種別＜ｓｅｒｖｉｃｅＴｙｐｅ＞、サービス記述ＵＲＬ＜ＳＣＰＤＵＲＬ＞、コントロールＵＲＬ＜ｃｏｎｔｒｏｌＵＲＬ＞、などが記載されている。

図８に、Ｆ００４にて返信される、２００ ＯＫレスポンスの例を示す。

同図において、８０１は、デジタルテレビ１１のデバイスの種別を示している。

８０２は、デジタルテレビ１１がサポートしているサービスの種別を示している。

８０３は、デジタルテレビ１１がサポートしているサービスの詳細情報を記述しているファイル名を含むＵＲＬを示している。８０３は、サービス記述ＵＲＬであり、コマンドの入手先を示す。

８０４は、ＳＯＡＰリクエストの送信先ＵＲＬを示している。ここで、ＳＯＡＰとは、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌである。

Ｆ００４において、コントローラ１２のＤＬＮＡ制御部１２０２は、２００ ＯＫレスポンスを受信する。そして、コントローラ１２のＤＬＮＡ制御部１２０２は、サービスの詳細情報、サービスを制御するためのコマンドに関する詳細情報等を取得するために、サービスリストの中に記載されている各ＵＲＬへ、ＨＴＴＰのＧＥＴコマンドを送信する（Ｆ００５）。ＧＥＴコマンドを受信したデジタルテレビ１１は、ＵＲＬに基づき、コントローラ１２から指定された情報を記載した２００ ＯＫレスポンスをコントローラ１２に返信する。そして、コントローラ１２のＤＬＮＡ制御部１２０２は、デジタルテレビ１１から送信された２００ ＯＫレスポンスを受信する（Ｆ００６）。

図９に、サービス記述ＵＲＬ８０３へ送信したＧＥＴコマンドに対する、デジタルテレビ１１の２００ ＯＫレスポンスの例を示す。

同図において、９０１、及び９０２は、サービスを実行するためのコマンド名を示している。

また、９０３は、コマンドを実行する際の引数名および戻り値名を示している。

以上の処理によって、コントローラ１２のＤＬＮＡ制御部１２０２は、取得されたコマンドの入手先（サービス記述ＵＲＬ８０３）から、サービスをデータ要求待ち状態に設定するためのコマンドの取得を行う。

そして、コントローラ１２のサービス起動制御部１２０１ｂは、以上の処理によって取得された、データ要求待ち状態に設定するためのコマンドにより、デジタルテレビ１１のサービスをデータ要求待ち状態に設定する。

また、コントローラ３２のＤＬＮＡ制御部１２０２は、コントローラ１２と同様の手順により、ホームネットワーク２に接続されているサービスを発見し、サービスの種別やサービスを制御するためのコマンドを取得する。

尚、図５の機器検索（Ｆ００１）、及び存在通知（Ｆ００２）の処理が、図３のＦ１１０の処理に、デバイス記述取得（Ｆ００３）から応答（Ｆ００６）までの処理がサービス情報取得（Ｆ１１１）にそれぞれ対応する。また、図５の機器検索（Ｆ００７）、及び存在通知（Ｆ００８）の処理が図３のサービス検索（Ｆ１０３）の処理に、デバイス記述取得（Ｆ００９）から応答（Ｆ０１２）までの処理がサービス情報取得（Ｆ１０４）にそれぞれ対応する。

また、サービス検索（Ｆ１０３、Ｆ１１０）、サービス情報取得（Ｆ１０４、Ｆ１１１）は、ＩＮＶＩＴＥリクエスト（Ｆ１０１）の送信前に予め行っていても良い。また、図４のサービス検索（Ｆ２０３、Ｆ２０７）、サービス情報取得（Ｆ２０４、Ｆ２０８）も同様に、ＩＮＶＩＴＥリクエスト（Ｆ２０１）の送信前に予め行うようにしても良い。

コントローラ１２、及び３２のサービス起動制御部１２０１ｂは、上述のような手順により発見したサービス提供装置から取得したコマンド情報を用いて、サービス提供装置へコマンドを送信するために使用するＳＯＡＰメッセージを作成することができる。

尚、コマンドには、ＤＬＮＡで規定されているコマンドや、サービス提供装置固有のコマンドなどがある。

次に、本実施形態における、コントローラがＩＮＶＩＴＥリクエスト（セッション接続要求）受信時に行う処理の流れについて説明する。

図６は、ＩＮＶＩＴＥリクエストを受信した図３のコントローラ３２、及び図４のコントローラ１２が行う処理（図３および図４のＳ１１部分）の流れを示したフローチャートである。図６は、コンピュータであるＣＰＵ２０１が実行するプログラムの一部を示す。このプログラムは、ＣＰＵ２０１が読み出すことができるように、記憶媒体であるＨＤＤ２０９に、記憶されている。

Ｓ１０１（受信手順）において、ＳＩＰ制御部１２０３が、セッションを接続するためのプロトコル（ＳＩＰ）により送信された接続要求であるＩＮＶＩＴＥリクエストを受信すると、Ｓ１０２に進む。

Ｓ１０２において、ＤＬＮＡ制御部１２０２は、ＩＮＶＩＴＥリクエストに含まれるＳＤＰ情報と、図５で説明したＳＳＤＰの処理で得られた情報とにより、着信対象サービスの発見、及びサービスの着信可否チェックを行う。またＳ１０２において、コントローラのサービス種別判断部１２０１ａは、着信対象サービスのサービス種別の判断を行う。ＳＤＰ情報により特定される着信対象サービスが着信可能であると判断した場合は、Ｓ１０３へ進む。一方、着信対象サービスがない場合、サービスを提供できない場合、サービスを提供しないと判断した場合は、Ｓ１０７に進む。

Ｓ１０３において、コントローラのサービス種別判断部１２０１ａは、Ｓ１０２で判断された着信対象となるサービス提供装置のサービス種別を確認する。ここで、サービス種別がデータ供給サービス（ストレージサーバ３１）であると確認された場合（図３の場合）は、Ｓ１０４へ進み、データ受信サービス（デジタルテレビ１１）であると確認された（図４の場合）はＳ１０６に進む。

Ｓ１０４（設定手順）において、サービス起動制御部１２０１ｂは、ストレージサーバ３１に対し、サービスの開始を指示するコマンド（サービス開始要求）を送信し、ネットワーク内に存在するサービスをデータ要求待ち状態に設定して、Ｓ１０５に進む。すなわち、サービス起動制御部１２０１ｂは、ローカルネットワーク内において機器を制御するためのプロトコル（ＤＬＮＡ）を用いて、ネットワーク内に存在するサービスをデータ要求待ち状態に設定する。尚、サービス開始要求のコマンドは、図３のＦ１０４でＤＬＮＡ制御部１２０２によって取得される。

Ｓ１０５において、ＤＬＮＡ制御部１２０２は、ストレージサーバ３１からの応答（Ｆ１０８）に基づき、サービス開始結果を判定する。ここで、ストレージサーバ３１のサービスが正常に開始され、データ要求待ち状態に設定されたことが確認された場合は、Ｓ１０６に進む。一方、Ｓ１０５において、サービスが正常に開始されなかった場合は、Ｓ１０７に進む。

Ｓ１０６（送信手順）では、ＳＩＰ制御部１２０３が、ＩＮＶＩＴＥリクエストに対して承諾する２００ ＯＫレスポンスを送信する。すなわち、ＳＩＰ制御部１２０３は、サービスがデータ要求待ち状態に設定されたことを確認してから、ＩＮＶＩＴＥリクエストに対する応答である２００ ＯＫレスポンスを送信する。ここで、ＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により、接続要求に対する応答を送信する。

Ｓ１０７では、ＳＩＰ制御部１２０３が、ＩＮＶＩＴＥリクエストに対して拒絶する４ｘｘレスポンスを送信する。

次に、本実施形態における、コントローラがセッションの接続要求の発信側コントローラから応答確認（ＡＣＫリクエスト）を受信したときに行う処理の流れについて説明する。図７は、コンピュータであるＣＰＵ２０１が実行するプログラムの一部を示す。このプログラムは、ＣＰＵ２０１が読み出すことができるように、記憶媒体であるＨＤＤ２０９に、記憶されている。

図７は、ＡＣＫリクエストを受信した図３のコントローラ３２、及び図４のコントローラ１２が行う処理（図３および図４のＳ１３部分）の流れを示したフローチャートである。

Ｓ２０１において、ＳＩＰ制御部１２０３がＡＣＫリクエスト（応答確認）を受信するとＳ２０２に進む。Ｓ２０２では、コントローラのサービス種別判断部１２０１ａが、着信対象サービスのサービス種別を確認する。尚、着信対象サービスのサービス種別は、ＩＮＶＩＴＥリクエスト（接続要求）受信時に、ＳＤＰ情報を参照することで、すでに判定を行っている。しかし、このタイミングで、サービス種別判断部１２０１ａが改めてＳＤＰ情報を参照してサービス種別の確認を行っても構わない。

Ｓ２０２において、サービス種別判断部１２０１ａがサービス種別をデータ供給サービス（ストレージサーバ）であると判断した場合（図３の場合）は、処理を終了する。一方、サービス種別がデータ受信サービス（デジタルテレビ）と判断した場合（図４の場合）は、Ｓ２０３へ進む。そして、Ｓ２０３では、図４のＦ２０４で取得したサービス開始要求のコマンドにより、サービス起動制御部１２０１ｂがデジタルテレビ１１のサービスを開始させる。Ｓ２０４では、ＤＬＮＡ制御部１２０２が、デジタルテレビ１１からの応答（Ｆ２１５）に基づいてサービス開始結果を判定する。ここで、デジタルテレビ１１のサービスが正常に開始された場合は処理を終了する。一方、正常に開始されなかった場合は、Ｓ２０５へ進み、ＳＩＰ制御部１２０３からＳＩＰのＢＹＥリクエスト（セッションの切断要求）をコントローラ３２に対して送信する。

尚、本実施形態のＳ１０２、Ｓ１０３、Ｓ２０２において、コントローラのサービス種別判断部１２０１ａは、サービス種別の判断をＩＮＶＩＴＥリクエストに含まれるＳＤＰ情報によって行っていた。しかし、サービス種別判断部１２０１ａは、Ｓ１０３、Ｓ２０２において、前述したＳＳＤＰの処理によって取得されるデバイス種別８０１の情報やサービスの種別８０２の情報によってサービス種別を判断しても良い。例えば、図８におけるデバイス種別８０１の情報「ＭｅｄｉａＲｅｎｄｅｒｅｒ」は、そのデバイスが提供するサービスがデータ受信サービスであることを示している。また、サービスの種別８０２の情報からサービスの種別を判断できる場合もある。

次に、本実施形態における、コントローラが接続要求に対する応答（２００ ＯＫレスポンス）受信時に行う処理の流れについて説明する。

図１０は、２００ ＯＫレスポンスを受信した図３のコントローラ１２、及び図４のコントローラ３２が行う処理（図３及び図４のＳ１２部分）の流れを示したフローチャートである。図１０は、コンピュータであるＣＰＵ２０１が実行するプログラムの一部を示す。このプログラムは、ＣＰＵ２０１が読み出すことができるように、記憶媒体であるＨＤＤ２０９に、記憶されている。なお、この図１０の処理の前には、ネットワークへ接続要求であるＩＮＶＩＴＥリクエストを送信する第１の送信手順が実行されている。

Ｓ３０１（受信手順）において、ＳＩＰ制御部１２０３が、２００ ＯＫレスポンス（接続要求に対する応答）を受信すると、Ｓ３０２に進む。すなわち、コントローラのＳＩＰ制御部１２０３は、セッションを接続するためのプロトコル（ＳＩＰ）により送信される接続要求をＮＥＴＩＦ２０４から受信する。

そして、Ｓ３０２（設定手順）において、サービス起動制御部１２０１ｂは、実行すべきサービスを開始させ、ネットワーク内に存在するサービスをデータ要求待ち状態に設定し、Ｓ３０３に進む。すなわち、コントローラのサービス起動制御部１２０１ｂは、ローカルネットワーク内において機器を制御するためのプロトコル（ＤＬＮＡ）を用いて、ネットワーク内に存在するサービスをデータ要求待ち状態に設定する。

Ｓ３０３では、ＤＬＮＡ制御部１２０２が、実行すべきサービスからの応答（Ｆ１１４、Ｆ２１１）に基づいて、サービス開始結果を判定する。ここで、サービスが正常に開始されたと判定された場合は、Ｓ３０４に進み、正常に開始されなかった場合は、Ｓ３０５に進む。

Ｓ３０４（第２の送信手順）では、ＳＩＰ制御部１２０４が２００ ＯＫレスポンスの送信元に対してＡＣＫリクエスト（応答確認）を送信し、処理を終了する。すなわち、ＳＩＰ制御部１２０４は、セッションを接続するためのプロトコル（ＳＩＰ）により応答に対する応答確認を送信する。このように、本形態では、ＤＬＮＡ制御部１２０２が、サービスがデータ要求待ち状態に設定されたことをＳ３０３で確認してから、ＳＩＰ制御部１２０３がＯＫレスポンスに対する応答確認（ＡＣＫリクエスト）を送信する。

Ｓ３０５では、ＳＩＰ制御部１２０３がＳＩＰのＢＹＥリクエスト（セッションの切断要求）を２００ ＯＫレスポンスの送信元に対して送信し、処理を終了する。

＜その他の実施形態＞
尚、本実施形態では、説明の簡単のために、１つのコントローラに接続されるサービス提供装置の数が１つであったが、２つ以上の装置を接続することも可能である。また、インターネット２に接続されるホームネットワークの数を２つとしたが、２つ以上のホームネットワークを構成することも可能である。

また、本実施形態では、データ供給サービスをストレージサーバ、データ受信サービスをデジタルテレビとしたが、これに限るものではない。データ供給サービスの例として、例えば、各種コンテンツデータを記憶したＰＣ、ワークステーション、ノートブックＰＣ、パームトップＰＣ、携帯電話、ＰＤＡ、また、デジタルカメラ、ビデオカメラ等の各種家電製品が考えられる。また、データ受信サービスの例として、例えば、コンテンツデータ等の出力が可能なＰＣ、ワークステーション、ノートブックＰＣ、パームトップＰＣ、携帯電話、ＰＤＡ、プリンタ、また、デジタルカメラ、ビデオカメラ等の各種家電製品が考えられる。

ここで、データ供給サービスを提供するデジタルカメラのネットワーク側から、データ受信サービスを提供するプリンタのネットワークに対して接続要求を送信し、セッションの確立に基づいて画像データを送信し、画像の印刷を行う場合を考える。このとき、プリンタのサービスが開始されているにも関わらず、プリンタに適切なサイズの用紙がセットされていない、インク切れ等の理由により、印刷を行うことができない場合がある。このような場合、プリンタから、接続要求送信側ネットワークにいるユーザに対して、エラーメッセージを送信するようにしても良い。このようにすることで、ユーザは、プリンタのデータ受信サービスは開始されているが、印刷を行うことができない状態であることを知ることができる。

また、データ供給サービスとしてのＨＤレコーダが接続されるネットワークから、データ受信サービスとしてのＤＶＤレコーダが接続されるネットワークに対して接続要求を送信する場合を考える。このとき、セッションの確立に基づいて、ＨＤレコーダから動画データを送信し、受信側のＤＶＤレコーダで記録を行う。このとき、ＤＶＤレコーダのサービスが開始されているにも関わらず、動画データを記憶するのに十分なサイズの記憶領域が確保できない等の理由により、記録を行うことができない場合がある。このような場合、ＤＶＤレコーダから、接続要求送信側ネットワークにいるユーザに対して、エラーメッセージを送信するようにしても良い。このようにすることで、ユーザは、ＤＶＤレコーダのデータ受信サービスは開始されているが、記録を行うことができない状態であることを知ることができる。

また、本実施形態では、ＩＮＶＩＴＥリクエスト（接続要求）を受けるコントローラと、サービスを提供する装置が別の装置である場合の例を示したが、これらが同一の機器である場合あっても本発明は実現可能である。

また、本実施形態では、ＩＮＶＩＴＥリクエスト（接続要求）に含まれるＳＤＰ情報に基づいて、着信対象となるサービスの種別を判断した。しかしながら、この方法に限らず、例えば、予め着信側のコントローラに、着番号に対応するサービス種別情報を登録しておき、判断しても良い。

また、本発明の目的は、次の形態によっても達成される。すなわち、前述した実施例の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵまたはＭＰＵ）が記録媒体に格納されたプログラムコードを読み出し実行する形態である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することとなり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

また、本発明は、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現される形態には限られない。すなわち、そのプログラムコードの指示に基づき、コンピュータ上で稼動しているＯｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれる。

さらに、本発明には、以下の形態も含まれる。すなわち、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書きこまれる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される形態である。

実施形態１におけるネットワーク構成 コントローラのハードウェア構成 セッション接続要求の発信がデータ受信サービス側の場合のサービス開始シーケンス セッション接続要求の発信がデータ供給サービス側の場合のサービス開始シーケンス ホームネットワーク内のサービスに関する情報を取得するためのシーケンス セッションの接続要求を受信した際の処理フローチャート 応答確認を受信した際の処理フローチャート Ｆ００４で送信される、デバイス情報を含んだ応答の例 サービス記述ＵＲＬ８０３へ送信したＧＥＴコマンドの応答例 最終応答を受信した際の処理フローチャート 本実施形態における、ＳＤＰ情報の例 コントローラ１２、３２のソフトウェア構成

符号の説明

１、３ ホームネットワーク
２ インターネット
１１ デジタルテレビ
１２、３２ コントローラ
１３、３３ ルータ
２１ セッション制御サーバ
３１ ストレージサーバ
８０１ デバイス種別
８０２ サービスの種別
８０３ サービスの詳細情報
８０４ ＳＯＡＰリクエストの送信先ＵＲＬ
９０１、９０２ コマンド名
９０３ コマンド実行のための引数名及び戻り値

Claims (16)

1. 第１のネットワークに接続された通信装置であって、
   第２のネットワークから送信される接続要求を受信する受信手段と、
   前記接続要求の受信に応じて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手段と、
   前記サービスがデータ要求待ち状態に設定されたことを確認してから前記接続要求に対する応答を送信する送信手段と
   を有することを特徴とする前記第１のネットワークに接続された通信装置。
2. 第２のネットワークに接続された通信装置であって、
   第１のネットワークへ接続要求を送信する送信手段と、
   前記接続要求に対する応答を受信する受信手段と、
   前記第２のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手段とを有し、
   前記送信手段は、前記サービスがデータ要求待ち状態に設定されたことを確認してから前記応答に対する応答確認を送信する
   ことを特徴とする前記第２のネットワークに接続された通信装置。
3. 前記接続要求の受信に応じて前記第１のネットワークで行うサービスがデータ受信サービスである場合、前記送信手段は前記接続要求に対する応答を送信し、前記設定手段は当該応答に対する応答確認を受信してから前記データ受信サービスにデータ要求を開始させる
   ことを特徴とする請求項１記載の通信装置。
4. 前記設定手段は、前記受信手段による受信に基づいて前記サービスを検索し、前記サービスをデータ要求待ち状態に設定するためのコマンドの入手先を取得する検索手段と、
   前記検索手段によって取得されたコマンドの入手先からコマンドを入手するコマンド入手手段を有し、
   前記設定手段におけるデータ要求待ち状態への設定は、前記コマンド入手手段で入手された前記コマンドに基づいて行われる
   ことを特徴とする請求項１乃至３のうち、いずれか１項に記載の通信装置。
5. 前記設定手段は、前記サービスの状態を確認する確認手段と、
   前記設定手段におけるデータ要求待ち状態への設定に用いるコマンドを、前記確認手段で確認された、前記サービスの状態に基づいて選択する選択手段と
   を有することを特徴とする請求項１乃至４のうち、いずれか１項に記載の通信装置。
6. 前記受信手段は、セッションを接続するためのプロトコルにより送信された前記接続要求を受信し、前記設定手段は、ローカルネットワーク内において機器を制御するためのプロトコルを用いて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定し、前記送信手段は、前記セッションを接続するためのプロトコルにより前記応答を送信することを特徴とする請求項１記載の通信装置。
7. 前記送信手段は、セッションを接続するためのプロトコルにより前記接続要求、及び前記応答に対する応答確認を送信し、前記受信手段は、前記セッションを接続するためのプロトコルにより送信された前記接続要求に対する応答を受信し、前記設定手段は、ローカルネットワーク内において機器を制御するためのプロトコルを用いて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定することを特徴とする請求項２記載の通信装置。
8. 第１のネットワークに接続された通信装置を制御する制御方法であって、
   第２のネットワークから送信される接続要求を受信する受信工程と、
   前記接続要求の受信に応じて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定工程と、
   前記サービスがデータ要求待ち状態に設定されたことを確認してから前記接続要求に対する応答を送信する送信工程と
   を有することを特徴とする制御方法。
9. 第２のネットワークに接続された通信装置を制御する制御方法であって、
   第１のネットワークへ接続要求を送信する第１の送信工程と、
   前記接続要求に対する応答を受信する受信工程と、
   前記第２のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定工程と、
   前記サービスがデータ要求待ち状態に設定されたことを確認してから前記応答に対する応答確認を送信する第２の送信工程と
   を有することを特徴とする制御方法。
10. 前記接続要求の受信に応じて前記第１のネットワークで行うサービスがデータ受信サービスである場合、前記接続要求に対する応答を送信し、当該応答に対する応答確認を受信してから前記データ受信サービスにデータ要求を開始させる
    ことを特徴とする請求項６記載の制御方法。
11. 前記設定工程は、前記受信工程における受信に基づいて前記サービスを検索し、前記サービスをデータ要求待ち状態に設定するためのコマンドの入手先を取得する検索工程と、
    前記検索工程によって取得されたコマンドの入手先からコマンドを入手するコマンド入手工程を有し、
    前記設定工程におけるデータ要求待ち状態への設定は、前記コマンド入手工程で入手された前記コマンドに基づいて行われる
    ことを特徴とする請求項６乃至８のうち、いずれか１項に記載の制御方法。
12. 前記設定工程は、前記サービスの状態を確認する確認工程と、
    前記設定工程におけるデータ要求待ち状態への設定に用いるコマンドを、前記確認工程で確認された、前記サービスの状態に基づいて選択する選択工程と
    を有することを特徴とする請求項６乃至９のうち、いずれか１項に記載の制御方法。
13. 前記受信工程は、セッションを接続するためのプロトコルにより送信された前記接続要求を受信し、前記設定工程は、ローカルネットワーク内において機器を制御するためのプロトコルを用いて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定し、前記送信工程は、前記セッションを接続するためのプロトコルにより前記応答を送信することを特徴とする請求項８記載の通信方法。
14. 前記送信工程は、セッションを接続するためのプロトコルにより前記接続要求、及び前記応答に対する応答確認を送信し、前記受信工程は、前記セッションを接続するためのプロトコルにより送信された前記接続要求に対する応答を受信し、前記設定工程は、ローカルネットワーク内において機器を制御するためのプロトコルを用いて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定することを特徴とする請求項２記載の通信方法。
15. 第１のネットワークに接続されたコンピュータに、
    第２のネットワークから送信される接続要求を受信する受信手順と、
    前記接続要求の受信に応じて、前記第１のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手順と、
    前記サービスがデータ要求待ち状態に設定されたことを確認してから前記接続要求に対する応答を送信する送信手順と
    を実行させるためのプログラム。
16. 第２のネットワークに接続されたコンピュータに、
    第１のネットワークへ接続要求を送信する第１の送信手順と、
    前記接続要求に対する応答を受信する受信手順と、
    前記第２のネットワーク内に存在するサービスをデータ要求待ち状態に設定する設定手順と、
    前記サービスがデータ要求待ち状態に設定されたことを確認してから前記応答に対する応答確認を送信する第２の送信手順と
    を実行させるためのプログラム。

Images