JP2002518886A - ホームネットワークで非同期データを伝送する方法 - Google Patents

Abstract

(57)【要約】 本発明は、ホーム通信ネットワークでデータを伝送する方法に関する。ネットワークは、第1の装置と第２の装置を有し、前記第１の装置はデータパケットを生成する手段を有し、且つ、前記第２の装置は前記データパケットを使用する手段を有する。本発明の方法は、−前記第1の装置と前記第２の装置間で接続をオープンするステップと、−前記接続のために、前記第２の装置は前記第１の装置とメッセージバッファサイズに関して通信し、前記第２の装置にメッセージバッファを割り当てるステップと、−前記第２の装置に対して、前記データパケットを、前記第１の装置に送信させるステップとを有し、前記データパケットは分割され、且つメッセージのペイロードとして送られ、ペイロードのサイズは前記メッセージバッファサイズより小さいか又は等しいことを特徴とする。本発明は、ホームネットワーク通信に適用する。

Description

【発明の詳細な説明】

【０００１】 ”ＨＡＶｉ”構造ともよばれる”ホームオーディオ／ビデオ共通操作構造バー
ジョン０．８”仕様が、１９９８年５月１５日に少なくとも次の会社、ソニー、
フィリップス、東芝、シャープ及び、日立のＷＥＢサイトで公開された。

【０００２】 この仕様は、民生機器及び、計算装置を有し且つ、ＩＥＥＥ１３９４ １９９
５シリアルバス及びＩＥＣ６１８８３インターフェース標準と互換性のあるホー
ムネットワークの実行を記述する。

【０００３】 ＨＡＶｉ仕様バージョン０．８はセクション３．２と５．２で”メッセージシ
ステム”と呼ばれる装置間通信システムを開示する。”メッセージ通過システム
”とも呼ばれる”メッセージシステム”は、ネットワークのある装置形式内にあ
るソフトウェアオブジェクト（ＨＡＶｉの用語では、”ソフトウェアエレメント
”）である。”メッセージシステム”は、メッセージを他のソフトウェアエレメ
ントへ送るためにあるソフトウェアエレメントによりアクセスされる幾つかの関
数を含む、アプリケーションプログラムインターフェースを有する。ソフトウェ
アエレメントは、他の装置のソフトウェアエレメントの関数を呼び、呼ばれた関
数はメッセージシステムメッセージへマップされる。

【０００４】 メッセージは、ＨＡＶｉ書類のセクション３．２．１に記述されている所定の
フォーマットを使用する。メッセージはメッセージのペイロードの長さを定義す
る２バイトを含む。最長メッセージは、６４ｋｂの少し上であり、ヘッダ情報長
が付加された最大ペイロードである。

【０００５】 ＨＡＶｉ仕様バージョン０．８のメッセージシステムは、ファンクションコー
ルに適合し且つ、ネットワーク内のソフトウェアエレメント識別子を管理する。
発明者は提案された構造に以下の問題を認識している。送信するソフトウェアエ
レメントが、メッセージを、受信するソフトウェアエレメントへ送るときには、
メッセージシステムは受信するソフトウェアエレメントのメモリ容量を考慮しな
い。受信するソフトウェアエレメントに割り当てられたバッファが適切でない場
合には、受信するソフトウェアエレメントは、大量のデータを処理する問題と出
くわす。言い換えるとＨＡＶｉ仕様バージョン０．８書類は受信するソフトウェ
アエレメントは受信するデータ量を制御できない。

【０００６】 本発明の目的は、第１の装置と第２の装置を有するホーム通信ネットワークで
データを伝送する方法であって、前記第１の装置はデータパケットを生成する手
段を有し、且つ、前記第２の装置は前記データパケットを使用する手段を有し、
前記方法は、 −前記第1の装置と前記第２の装置間で接続をオープンするステップと、 −前記接続のために、前記第２の装置は前記第１の装置とメッセージバッファサ
イズに関して通信し、前記第２の装置にメッセージバッファを割り当てるステッ
プと、 −前記第２の装置に対して、前記データパケットを、前記第１の装置に送信させ
るステップとを有し、前記データパケットは分割され、且つメッセージのペイロ
ードとして送られ、ペイロードのサイズは前記メッセージバッファサイズより小
さいか又は等しいことを特徴とする方法である。

【０００７】 受信装置は伝送の最初にメッセージバッファのサイズを規定し、送信装置は制
限されたペイロードサイズを維持するためにこの値を考慮する。

【０００８】 用語”装置”は物理装置に制限されない。装置は、他のソフトウェアオブジェ
クト及び、特にＨＡＶｉ０．８書類により定義されている”ソフトウェアエレメ
ント” を含む。

【０００９】 本発明の特定の実施例に従って、前記ペイロードは前記第１の装置と前記第２
の装置に独立の第１の最大長を有し、前記第２の装置に依存する第２の最大長は
前記メッセージバッファサイズにより構成され、最小の前記第１と第２の最大長
は、前記第２の装置へメッセージを送るために保持されている。

【００１０】 第１の最大メッセージサイズは、仕様により与えられる。例えば、ＨＡＶｉ０
．８は、最大メッセージサイズとして６４キロバイトを与える。第２の最大メッ
セージサイズは、接続内即ち、受信装置のメッセージサイズで定義される。この
メッセージサイズは特定の受信装置に送られるメッセージとの接続内そして、特
定の接続を通してのみ使用されねばならない。

【００１１】 本発明は、この書類、特にメッセージシステムとの互換性を維持しながら、Ｈ
ＡＶｉ０．８書類により提示されているネットワークに固有の問題を解決する。

【００１２】 本発明の他の特徴と優位点は図を参照して、非制限的な実施例の説明を読めば
明らかとなろう。

【００１３】 本発明は、以下の書類により定義された用語を使用する。更に詳細は、”ＨＡ
Ｖｉ構造−ホームオーディオ／ビデオ共通操作（ＨＡＶｉ）構造仕様１９９８年
５月１１日バージョン０．８”、１９９８年５月１５日に少なくとも次の会社、
ソニー、フィリップス、東芝、シャープ及び、日立のＷＥＢサイトで公開された
。

【００１４】 図１は、ＨＡＶｉ０．８仕様により定義された全ての４つの形式の装置を含む
ＨＡＶｉ準拠ホームネットワークの例を示す。ホームネットワークは、本例に従
ったＩＥＥＥ１３９４ １９９５シリアルバスである通信バスを含む。このバス
には、ディジタルテレビジョン、ディジタル受信器／復号器、モデム、ディジタ
ルビデオディスク記録器／再生器（ＤＶＤ）及び、ビデオカセットレコーダ（Ｖ
ＣＲ）が接続されている。テレビジョン受信機は、ＨＡＶｉ仕様に従って最も機
能のある装置形式であるフルオーディオ／ビデオ（ＦＡＶ）装置である。特に、
ＦＡＶ形式装置は、ＨＡＶｉのランタイムコードを実行する能力がある。テレビ
ジョン受信機は、ＨＡＶｉ機能を有するこの場合にはレガシー装置であるＶＣＲ
を制御するソフトウェアを持つことができる。レガシー装置は、バスコネクタ又
は、バスで通信するのに必要な手段を有していないので、フルオーディオ／ビデ
オ装置と直接接続される。ディジタルデコーダとモデムは、インターミディエー
トオーディオ／ビデオ（ＩＡＶ）装置であり、多くのＦＡＶ装置の特徴を有する
が、他の装置を制御するソフトウェアをダウンロードする能力はない。しかし、
そのようなソフトウェアはＩＡＶ装置に存在できる。最後にＤＶＤプレーヤはベ
ーシックオーディオ／ビデオ装置であり、ＨＡＶｉコードを実行する能力は無い
が、少なくとも通信バスに接続し、そして、ＨＡＶｉ環境とベーシックオーディ
オ／ビデオ装置自身の環境間でソフトウェアインターフェースを実行するＩＡＶ
、又は、ＦＡＶ装置と通信することができる。

【００１５】 図２は、ＨＡＶｉ機能に関連するテレビジョン受信機の要素のブロックを示す
。 テレビジョン受信機１は、マイクロプロセッサ２と、それに内部バス７を介して
接続されたＲＡＭメモリ３及びプログラム可能なＲＯＭメモリ４を含む。ＲＯＭ
は受信器のソフトウェア要素とマイクロプロセッサにより実行される装置機能を
管理する他のコードを蓄積するのに使用される。テレビジョン受信機は、また、
ＩＥＥＥ１３９４バスへの接続５も有し、接続は、フィジカル／リンク回路（及
び、非同期処理とバス管理レイヤに要求されるソフトウェア）を含む。テレビジ
ョン受信機は、図１の場合はＶＣＲの特定の装置とオーディオ／ビデオストリー
ムを制御し且つ交換するためのコネクタ６も有する。

【００１６】 図３は、テレビジョン受信機内の更に一般的には、ＦＡＶ形式装置内のソフト
ウェアオブジェクト（ＨＡＶｉによれば”ソフトウェアエレメント”）の構成を
示す。

【００１７】 テレビジョン受信機は、幾つかのアプリケーションと対応するアプリケーショ
ンソフトウェアインターフェースを介して以下のソフトウェアエレメントと対話
する装置制御アプリケーションを管理する。 −他のソフトウェアエレメントに非同期及び同期通信をＩＥＥＥ１３９４バス上
で行わせる、１３９４通信媒体マネージャ、 −他のソフトウェアエレメントとメッセージを交換するための、メッセージ通過
システム、 −オブジェクト状態変化を管理するイベントマネージャ、 −チューナと記録装置のような機能要素間でオーディオ／ビデオデータストリー
ムを管理するストリームマネージャ、 −ローカルソフトウェアエレメントのリストと識別子を保持し、遠隔レジストリ
との通信を管理するレジストリ、 −装置制御モジュール（ＤＣＭ）のロードと削除のために装置制御モジュールマ
ネージャ（ＤＣＭＭ）、 −常駐する又はアップロードされる幾つかの装置制御モジュール。

【００１８】 図３の常駐するアプリケーションは本場合には電子番組案内であり、装置制御
モジュール（ＤＣＭ）は図２のＶＣＲを制御するためにインストールされており
、且つ他のＤＣＭはＤＶＤプレーヤからダウンロードされる。

【００１９】 装置制御モジュールは、ＦＣＭと呼ばれる１つ又はそれ以上の機能制御モジュ
ールを制御する。ＦＣＭはアプリケーションプログラムインターフェース又はＡ
ＰＩと呼ばれる機能のグループを含む既知の機能の組を通して装置の特定の機能
を制御するソフトウェアエレメントである。ディジタルテレビジョン受信機／デ
コーダではＦＣＭ ＡＰＩは典型的には、チューナ及び、ビデオ／オーディオデ
コーダの制御に専用である。

【００２０】 本実施例によれば、非同期データＡＰＩが定義される。ＡＰＩ又はその一部は
、生産者と消費者間で非同期データストリームの転送を管理する能力を要するＦ
ＣＭに含まれる。

【００２１】 用語”生産者”と”消費者”は、非同期ストリームを生成し又は、そのような
ストリームを受信する装置又は機能の能力を指すのに使用される。消費者と生産
者は蓄積装置でも良いが、必要ではない。

【００２２】 サービス情報をデマルチプレックスするディジタルストリームデマルチプレク
サは、生産者である。記録装置（例えば、メモリ、光磁気ディスク、ハードディ
スク、又は、ディジタルビデオカセットレコーダ）も生産者である。データを発
生し又は、処理する１つのソフトウェアも生産者である。

【００２３】 消費者の例は、情報を再生する記録装置、プリンタ又は、ディスプレイ装置で
ある。

【００２４】 生産者と消費者の概念は排他的でなく、幾つかの装置又は、機能要素は、同じ
接続内に両機能を有してもよい。そのような装置の例は、インターネットサービ
スにアクセスする公衆切り替え電話ネットワークに接続されたモデムである。イ
ンターネットサーバからクライアントアプリケーションへデータを転送するとき
には、ＨＡＶｉネットワークから見ると、即ち、インターネットサーバへの伝送
のためにクライアントアプリケーションからデータを受けることにより、モデム
は消費者として働く。クライアントアプリケーションはこの場合は生産者と消費
者の両方である。

【００２５】 用語”非同期データストリーム”は”アイソクロノスデータストリーム”、即
ち、ＨＡＶｉ書類により定義されるストリームマネージャにより扱われるオーデ
ィオとビデオストリームとを区別するために使用される。典型的には、非同期デ
ータは画像に対応するデータ、ファイル又は、プログラムコードよりなる。以下
に詳細に説明する機能を実行するＦＣＭは、導入部で述べた欠点を補正しながら
、（ＨＡＶｉバージョン０．８書類に定義される）メッセージシステムと互換性
を維持する。

【００２６】 ＦＣＭは、１つ又はそれ以上それ以上のコンテナを管理できる。コンテナは、
生産者、消費者又は、両機能を有するエンティティを指す一般的な用語である。
ＦＣＭが１つ以上のコンテナを有する場合には、各コンテナは唯一のラベルによ
り識別される。１つのコンテナのみが存在するならば、そのようなラベルは冗長
であるが、本発明の変形に従ってシステムの均一化のために実行される。

【００２７】 非同期データＡＰＩはパラメータと以下の関数により定義される。ＦＣＭが単
に消費者であるか生産者か又は、その両方であるかにより、関数の適切なサブセ
ットが実行されねばならない。

【００２８】 関数定義内で使用する用語”ｉｎ”はファンクションコールを受信するソフト
ウェアエレメントへ、機能を呼出すソフトウェアエレメントにより渡されたパラ
メータを定義し、用語”ｏｕｔ”は、ファンクションコールを受信するソフトウ
ェアエレメントにより送り返されたパラメータを定義する。 （ａ）ＦｉｌｅＬｏｃパラメータ このパラメータは、生産者から消費者へのメッセージは最初のメッセージか、
中間メッセージか、又は、連続するメッセージの最後のメッセージか否かを示す
。 そのような連続するメッセージの使用の状態は、以後図４と６に関連して説明す
る。

【００２９】 パラメータは以下のように定義される。

【００３０】 ｅｎｕｍ ＦｉｌｅＬｏｃ｛ＳＴＲＡＴ，ＮＥＸＴ，ＭＩＤＤＬＥ｝； （ｂ）Ｃｏｎｔａｉｎｅｒパラメータ コンテンナの特徴を定義する。例えば、プログラムファイルを有するコンテナ
が、その識別子（’ｉｏｉｄ’）、ファイル名により定義され、ファイル形式と
ファイルサイズを有する。

【００３１】 パラメータは以下のように定義される。

【００３２】 ｓｔｒｕｃｔ Ｃｏｎｔａｉｎｅｒ｛ ｉｏｉｄ； ｃｈａｒａｃｔｅｒｉｓｔｉｃｓ； ｝ （ｃ）ＯｐｅｎＲｅａｄ関数 この機能は生産者のみのＦＣＭ内で実行される。コンテナから非同期ストリー
ムの転送を要求する消費者により呼ばれる。パラメータは以下のように定義され
る。

【００３３】

【表１】 ’Ｓｔａｔｕｓ’は関数戻り値の形式である。

【００３４】 以下のパラメータは、ＯｐｅｎＲｅａｄ関数により使用される。

【００３５】 −ｉｏｉｄ：これは、オープンされるべきコンテナの識別子である。関数を実
行するＦＣＭが１つのコンテナのみを有する場合には、必須ではなく、ファンク
ションコール内にある場合にはＦＣＭにより無視され得る。

【００３６】 −ｍｅｓｓａｇｅ＿ｂｕｆｆｅｒ＿ｓｉｚｅ：このパラメータは、メッセージ
システムオーバーヘッド（即ち、ヘッダとメッセージシステムレイヤに関連する
他のデータ）を除いて、消費者により受けられるメッセージの最大サイズを示す
。生産者は、消費者へのメッセージペイロードの長さを決定するためにパラメー
タを考慮する。ペイロードの長さは、消費者のメッセージバッファサイズと等し
いことが好ましい。

【００３７】 メッセージバッファサイズは、固定か又は、接続が確立されるときに利用でき
るメモリ資源に基づき呼出すソフトウェアエレメントにより動的に割り当てられ
るかのいずれかである。ＯｐｅｎＲｅａｄ関数に関しては、消費者は、接続を確
立する主導権を取り、そして、ＯｐｅｎＲｅａｄ関数にパラメータとして渡され
たメッセージバッファサイズは、消費者メッセージバッファサイズである。

【００３８】 −ｏｐＣｏｄｅ：このパラメータは、生産者が消費者へストリームを送るのに
使用するコードである。このオペレーションコードは、生産者がクライアントへ
応答を送るために呼出すべき消費者の関数を識別する。このパラメータは、消費
者により設定される。オペレーションコードはソフトウェアエレメント内の関数
を唯一に識別する。この場合、以下に定義するように”書きこみ”関数である。
ネットワーク内の関数の唯一のアドレスは’ＳＥＩＤ’識別子とオペレーション
コードを有する。

【００３９】 −ｃｉｄ：このパラメータは、接続は１つ以上であるので、生産者と消費者の
間の所定の接続を識別する。値は生産者により定義され、そして、各接続を唯一
に識別するために、所定の時点で同じ生産者により子輸される他の全ての識別子
と異なる。

【００４０】 以下の値は’ＯｐｅｎＲｅａｄ’関数呼出により戻される。

【００４１】 呼び出しが成功の場合は’０’。

【００４２】 コンテナ識別子が正しくない場合は’１’。

【００４３】 コンテナがアクセスできない場合には’２’。これは、例えば、同時に、多く
の読出しアクセスが幾つかの接続に亘って行われたときに発生する。 （ｄ）ＯｐｅｎＷｒｉｔｅ関数 この関数は、消費者のみであるＦＣＭで実行される。生産者が、消費者ＦＣＭ
のコンテナへ非同期ストリームを送ることを可能とする。

【００４４】 以下のように定義される。

【００４５】

【表２】 以上で定義したパラメータに加えて以下のパラメータが使用される。

【００４６】 −ｉｏｉｄ， ｍｅｓｓａｇｅ＿ｂｕｆｆｅｒ＿ｓｉｚｅ：は消費者により受け入れ可能なメ
ッセージペイロードの最大サイズを示す。消費者はデータを受信中に且つクロー
ズ要求までそのパラメータを考慮する。

【００４７】 ｃｉｄ：このパラメータは、接続を識別する。ＯｐｅｎＷｒｉｔｅ関数の場合
には、ｃｉｄパラメータの値を定義する呼出されたＦＣＭである。

【００４８】 この関数は、以下の値の１つを戻す。

【００４９】 呼び出しが成功の場合は’０’。

【００５０】 関数呼出し内で送られたコンテナ識別子’ｉｏｉｄ’が正しくない場合は’１
’。

【００５１】 ’ｉｏｉｄ’ 識別子により識別されたコンテナがアクセスできない場合には
’２’。 （ｅ）Ｏｐｅｎ関数 この関数は同じ接続のフレーム内で消費者と生産者の両方として働くＦＣＭ内
で実行される。

【００５２】 消費者／生産者に非同期ストリームをコンテナから／へ、受信／送信すること
を可能とする。

【００５３】 以下のように定義される。

【００５４】

【表３】 以下のパラメータが使用される。

【００５５】 −ｉｏｉｄ， −ｍｅｓａｇｅ＿ｂｕｆｆｅｒ＿ｓｉｚｅ＿ｃｌｉｅｎｔ：このパラメータは
、ＦＣＭ関数を呼ぶクライアントアプリケーションによりアクセスされるメッセ
ージの最大サイズを示す。呼ばれたＦＣＭが生産者のときには、消費者（即ち、
クライアントアプリケーション）へデータを送りために且つクローズ要求まで、
そのパラメータを考慮する。

【００５６】 −ｍｅｓｓａｇｅ＿ｂａｆｆｅｒ＿ｓｉｚｅ＿ＦＣＭ：このパラメータは、Ｄ
ＣＭにより受け入れられるメッセージの最大サイズを示す。クライアントアプリ
ケーションが生産者として動作するときには、クライアントアプリケーションは
、消費者（即ち、ＦＣＭ）へデータを送りために且つクローズ要求まで、そのパ
ラメータを考慮する。

【００５７】 −ｏｐＣｏｄｅ：このパラメータは、ＦＣＭがクライアントへ非同期ストリー
ムを送るのに使用するコードである。このオペレーションコードは、生産者がク
ライアントへ非同期データを送るために呼出すべきクライアントアプリケーショ
ンＡＰＩの機能を示す。この場合には、以下に”書きこみ”関数を示す。ネット
ワーク内の関数の唯一のアドレスは、’ＳＥＩＤ’識別子とオペレーションコー
ドを含む。

【００５８】 ｃｉｄ：このパラメータは、接続を識別する。ＦＣＭにより決定され、送られ
る。

【００５９】 この関数は、以下の値の１つを戻す。

【００６０】 呼び出しが成功の場合は’０’。

【００６１】 関数呼出し内で送られたコンテナ識別子’ｉｏｉｄ’が正しくない場合は’１
’。

【００６２】 ’ｉｏｉｄ’ 識別子により識別されたコンテナがアクセスできない場合には
’２’。 （ｅ）書きこみ関数 書きこみ関数はデータを消費者に送るために生産者により呼ばれるべき関数で
ある。生産者は、新たにこの関数を呼ぶ前に書きこみ関数の戻り値を待たねばな
らない。

【００６３】 この関数は消費者側で実行される。オペレーションコードはＦＣＭが消費者と
して動作するときは、非同期データＡＰＩの関数のオペレーションコードは予め
定められているので、既知のオペレーションコードである。消費者として働くク
ライアントアプリケーションの場合には、非同期データＡＰＩはクライアントア
プリケーションにより実行される必要がないので、オペレーションコードは、消
費者によるＯｐｅｎＲｅａｄ又はＯｐｅｎ関数コールを通してパラメータ生産者
に送られる。同様な結果を達成する専用の関数が使用できるが、ここでは、クラ
イアントアプリケーションは書きこみ関数を使用するものとする。

【００６４】 書きこみ関数は以下のように定義される。

【００６５】

【表４】 他の関数で既に定義したパラメータに加えて、書きこみ関数には以下のパラメ
ータが使用される。

【００６６】 −ｗｈｅｒｅ：このパラメータは、メッセージが、ストリームを転送するため
の連続するメッセージの、最初のメッセージか、最後のメッセージか、又は、中
間のメッセージかを消費者に示す。

【００６７】 −ｄａｔａ：これはメッセージのペイロード即ち、転送されるべきストリーム
の一部である。

【００６８】 書きこみ関数は以下の値のうちの１つを戻す。

【００６９】 消費者がさらにメッセージを要求するときには’０’である。

【００７０】 消費者が生産者に転送をアボートすべきことを通知する場合には’１’である
。 （ｆ）Ｄｉｒ関数 この関数は、ＦＣＭのコンテナの識別子のリストを戻す。ＦＣＭが１つのデフ
ォルトコンテナのみを管理する場合には、関数は実行される必要がない。

【００７１】 本実施例の変形に従って、この関数は、各コンテナの他の特徴を戻す（例えば
、蓄積要素、合計の利用できる空間、利用できる自由空間、ファイルのリスト等
）。

【００７２】 この関数は以下のように定義される。

【００７３】

【表５】 この’ｌｉｓｔ’パラメータは、ＦＣＭにより管理されるコンテナのリストで
ある。上述のように、コンテナは’ｉｏｉｄ’識別子により識別される。リスト
は空であることができる。これはＦＣＭは１つのコンテナのみを扱うことを意味
する。 （ｇ）’Ｃｌｏｓｅ’関数 この関数は、消費者又は、生産者が、前にオープンした接続をクローズするこ
とを可能とする。

【００７４】 接続はそれをオープンしたクライアントアプリケーションによってのみクロー
ズされる。

【００７５】 ソフトウェアエレメントは、ストリーム転送が達成された後は接続をクローズ
する必要はない。接続をオープンのままとしそして、接続を介してさらにストリ
ームを転送できる。

【００７６】 この関数のプロトタイプは以下のように定義される。

【００７７】

【表６】 パラメータは、この接続の識別子のみである、’ｃｉｄ’パラメータのみであ
る。

【００７８】 受信ＦＣＭは以下の状態値の１つを通知する。

【００７９】 接続が成功的にクローズされた場合には：０。

【００８０】 伝送された’ｃｉｄ’が知られていない場合には：１。

【００８１】 図４は、生産者がストリームの送信を開始したときの、消費者と生産者間のメ
ッセージフローを示す。

【００８２】 生産者は、例えば、図１のデコーダ１は、例えば、図１のディジタルテレビジ
ョン受信機のディスプレイに、デコーダがデマルチプレックスし、且つ逆圧縮し
た静止画を表示することを準備するために、メッセージシステムに、消費者のＯ
ｐｅｎＷｒｉｔｅ関数を呼出すことを要求する。デコーダはローカルレジストリ
サービスから、ネットワーク内の全表示装置のリストを要求することにより、デ
ィスプレイＦＣＭの識別子を得る。そして、ディジタルテレビジョン受信機のデ
ィスプレイを使用すると決定する。この目的のために、図１のネットワークのフ
ルオーディオ／ビデオ装置により実行されるディスプレイＦＣＭは、上述で定義
されたアプリケーションプログラムインターフェースから要求される関数、即ち
、書きこみ及び、クローズ関数を含む。

【００８３】 レジストリサービスの更なる詳細は、トムソンマルチメディアにより１９９８
年４月２３日に出願されたフランス国特許９８０５１１０に示されている。

【００８４】 消費者は値’０’を返すことにより接続をオープンする要求を通知し、そして
、対応するパラメータ値を即ち、接続識別子’ｃｉｄ’、この接続に割り当てら
れているメッセージバッファのバイトのサイズ及び、原理的には生産者により知
られている書きこみ関数のオペレーションコードを渡す。生産者は、そのデータ
の転送を進める。データは、どのメッセージも規定されたメッセージバッファサ
イズより大きくならないように、幾つかのメッセージに適切に分散される。

【００８５】 生産者は、最初に、前に消費者から受信したオペレーションコードを使用して
、’ｗｈｅｒｅ’パラメータが値ＳＴＡＲＴを有する書きこみファンクションコ
ールを行う。’ ＳＴＡＲＴ’は、メッセージが、消費者のメッセージバッファ
サイズよりも大きな１つのデータが転送される、連続するメッセージのうちの最
初のメッセージであることを示す。好適な実施例に従って、生産者は、各メッセ
ージペイロードに対して、必要な全体のメッセージ数を減少するために、消費者
のメッセージバッファサイズにより認められる最大メッセージ長を使用しようと
する。言い換えると、ペイロードサイズは、送られるべき十分なデータが残って
いるなら、特定の消費者のバッファサイズと等しい。消費者により規定されるバ
ッファサイズがＨＡＶｉ書類により定義される限界（即ち、バージョン０．８で
は６４キロバイト）よりも大きいならば、メッセージのペイロードサイズはその
サイズに制限される。

【００８６】 生産者は、最初のメッセージに転送されるべきデータの部分も有する。続くメ
ッセージは、メッセージ中の中間メッセージを示すために、’ｗｈｅｒｅ’パラ
メータに対して、値’ＮＥＸＴ’を使用する。最後のメッセージは’ＥＮＤ’値
を使用する。

【００８７】 生産者は、それを行う各書きこみファンクションコールに対する適切な受取通
知（’０’戻り値）を受信した後にのみ、メッセージを送信する。

【００８８】 全データが転送されると、生産者はクローズ関数を呼び、消費者との接続をク
ローズする。

【００８９】 図５は、生産者のＦＣＭの’ＯｐｅｎＲｅａｄ’関数を呼んで、消費者が接続
のオープンを開始する場合を示す。ＯｐｅｎＲｅａｄ関数とＯｐｅｎＷｒｉｔｅ
関数は、パラメータが異なるが、機構は図４で説明したのと同様である。

【００９０】 図６は、消費者−生産者クライアントアプリケーションが消費者−生産者ＦＣ
Ｍと完全２重接続を開始する場合を示す。本実施例によれは、ＦＣＭは、単一コ
ンテナと関連するモデムを管理する、 クライアントアプリケーションは、ＦＣＭにパラメータとして入力するメッセ
ージを扱う最大バッファサイズを提供して、接続をオープンする。応答として、
ＦＣＭはモデムを初期化し、所定の設定（電話番号、接続名、パスワード．．）
を使用して所定のサーバへ接続し、（’０’状態値伝送することにより）クライ
アントアプリケーションへの接続のオープンを確認し、そして、他のパラメータ
、その最大メッセージバッファサイズと接続の識別子（ｃｉｄ）を送信する。

【００９１】 クライアントアプリケーションは、そして、（本例に従ってＦＣＭへの１つの
メッセージペイロードに適合する）第１の要求を送る。ＦＣＭは、モデムアクセ
スを介してペイロードコンテンツを転送し、そして、クライアントアプリケーシ
ョンへ伝送を通知する。サーバは、要求を処理し、そして、応答を返す。ＦＣＭ
は応答フローを受信し、そして、クライアントアプリケーションの最大バッファ
サイズに従ってメッセージのペイロードに亘って応答を分散して、幾つかのメッ
セージを使用してクライアントアプリケーションへ転送する。データの転送はデ
ータが転送されるまで続く。クライアントアプリケーションとＦＣＭ間の通信は
クライアントアプリケーションと遠隔サーバ間の所定のプロトコルに従って続く
。

【００９２】 プロトコルによれば、クライアントアプリケーションは、そして、接続をクロ
ーズする。

【００９３】 出願人による１９９８年９月２８日に出願された欧州特許出願番号９８４０２
３８４．６とその優先権は、インターネットアクセス機能要素モジュールに関す
る。

【図面の簡単な説明】

【図１】 ホームネットワークのブロック図である。

【図２】 図１のホームネットワークの装置のブロック図である。

【図３】 図２の装置で実行されているソフトウェアオブジェクトとレイヤの例を示す図
である。

【図４】 ストリームを生成するエンティティ（生産者）が最初にストリームを送信した
場合の、ストリームを生成するエンティティ（生産者）とストリームを消費する
エンティティ（消費者）との間のメッセージの交換を示す図である。

【図５】 図４と同様であるが、消費者が生産者からストリームの要求を開始した場合の
を示す図である。

【図６】 同じ接続のフレーム内で、生産者と消費者の両方である２つのエンティティ間
での交換を示す図である。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ９８４０２７１２．８ (32)優先日 平成10年10月30日(1998．10．30) (33)優先権主張国 欧州特許庁（ＥＰ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，Ｚ Ａ，ＺＷ Ｆターム(参考） 5K033 BA01 BA15 CB01 CB06 CC01 DB13 5K034 EE11 HH38 LL02 MM39

Claims (7)

【特許請求の範囲】
1. 【請求項１】 第1の装置と第２の装置を有するホーム通信ネットワークで
   データを伝送する方法であって、前記第１の装置はデータパケットを生成する手
   段を有し、且つ、前記第２の装置は前記データパケットを使用する手段を有し、
   前記方法は、 −前記第1の装置と前記第２の装置間で接続をオープンするステップと、 −前記接続のために、前記第２の装置は前記第１の装置とメッセージバッファサ
   イズに関して通信し、前記第２の装置にメッセージバッファを割り当てるステッ
   プと、 −前記第２の装置に対して、前記データパケットを、前記第１の装置に送信させ
   るステップとを有し、前記データパケットは分割され、且つメッセージのペイロ
   ードとして送られ、ペイロードのサイズは前記メッセージバッファサイズより小
   さいか又は等しいことを特徴とする方法。
2. 【請求項２】 前記ペイロードは前記第1と前記第２の装置に独立の第１の
   最大長を有し、前記第２の装置に依存する第２の最大長は前記メッセージバッフ
   ァサイズにより構成され、最小の前記第１と第２の最大長は、前記第２の装置へ
   メッセージを送るために保持されていることを特徴とする請求項１記載の方法。
3. 【請求項３】 前記接続は、前記第２の装置へデータを書き込むために前記
   第２の装置へ送られるファンクションコールを通して前記第１の装置によりオー
   プンされることを特徴とする請求項１或は２記載の方法。
4. 【請求項４】 前記接続は、前記第１の装置からデータを読み出すために前
   記第１の装置へ送られるファンクションコールを通して前記第２の装置によりオ
   ープンされることを特徴とする請求項１或は２記載の方法。
5. 【請求項５】 前記第１の装置は、前記データパケットを蓄積するための、
   少なくとも１つのデータ蓄積要素を有することを特徴とする請求項１乃至４のう
   ちいずれか一項記載の方法。
6. 【請求項６】 前記装置は１つ以上の蓄積要素を有し、前記蓄積要素の各々
   は識別子により識別されることを特徴とする請求項５記載の方法。
7. 【請求項７】 前記第２の装置は、前記データパケットを蓄積するための、
   少なくとも１つのデータ蓄積要素を有することを特徴とする請求項１乃至６のう
   ちいずれか一項記載の方法。