(57)【特許請求の範囲】
【請求項１】
ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定する設定手段と、
前記設定手段により設定された前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開する第１の記憶手段と、
前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を記憶する第２の記憶手段と、
前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、前記設定手段により設定された前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させる制御手段と
を備え、
前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる
情報処理装置。
【請求項２】
前記ネットワークは、IEEE1394シリアルデータバスを用いて構成される
請求項１に記載の情報処理装置。
【請求項３】
ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、
設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、
前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、
前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させる
ステップを含み、
前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる
情報処理方法。
【請求項４】
ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、
設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、
前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、
前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させる
ステップを含む処理をコンピュータに実行させるプログラムが記録されており、
前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる
記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、並びに記録媒体に関し、特に、IEEE1394シリアルデータバスを介して他の情報処理装置と接続される情報処理装置において、内蔵するサブユニットを重複することなく、確実に制御することができるようにした情報処理装置および方法、並びに記録媒体に関する。
【０００２】
【従来の技術】
IEEE1394シリアルデータバスを用いたネットワークを介して、相互に情報を伝達することができるAV機器が開発されている。このネットワークにおいては、所定のコマンド(AV/C Command Transaction Set)を用いることにより、ネットワークに接続されているAV機器を制御することが可能である。例えば、図１に示すように、デジタル衛星放送を受信するIRD(Integrated Receiver Decoder)７１で受信した映像信号を、IEEE（Institute  of  Electical  and  Electronic  Engineers）1394シリアルデータバス２（以下、単に、バス２と記述する）を介して接続されているDVCR(Digital Video Cassette Recorder)８１で録画することが可能である。さらに、IRD７１およびDVCR８１を用いて、いわゆる録画予約を行うことが可能である。
【０００３】
この録画予約の処理においては、IRD７１のコントローラ７２が、IRD７１およびDVCR８１を制御する。すなわち、録画予約の設定（チャンネル、および録画開始時刻等の設定）はIRD７１に対して行われ、設定された録画開始時刻になると、IRD７１のコントローラ７２は、チューナサブユニット７３に、予約されている（設定されている）チャンネルを選局させて、受信した映像信号をバス２を介してDVCR８１に出力させる。また同時に、コントローラ７２は、バス２を介してDVCR８１のVCRサブユニット８４に録画開始のコマンドを送信する。DVCR８１のVCRサブユニット８４は、コントローラ７２から送信された録画開始コマンドに対応して、チューナサブユニット７３からの映像信号を磁気テープ（図示せず）に記録する。
【０００４】
ところで上述したように、DVCR８１の動作を、バス２を介して接続されている他の機器（図１の例の場合、IRD７１）から制御することが可能である場合、いわゆるダブルブッキングが生ずる可能性がある。
【０００５】
例えば、デジタル衛星放送の録画予約（録画予約Ａとする）をIRD７１に入力すると、その予約情報は、IRD７１のコントローラ７２に記憶される。その後、録画予約Ａの録画時刻に重複する時刻において放送される地上波アナログ放送の録画予約（録画予約Ｂとする）をDVCR８１に入力した場合、DVCR８１のコントローラ８２は、IRD７１に入力された録画予約Ａに関する情報を得ていないので、時刻が重複しているか否かを知ることができず、録画予約Ｂを受け付けて記憶してしまう。したがって、録画予約Ａおよび録画予約Ｂで指定された時刻になると、DVCR８１のVCRサブユニット８４には、IRD７１のチューナサブユニット７３、およびDVCR８１のアナログチューナブロック８３の両方から映像信号が供給される不都合が生じてしまう。
【０００６】
この不都合は、バス２を介して接続されているAV機器が、他のAV機器が管理する予約情報等を入手できないことに起因している。
【０００７】
上述した不都合を解決するため、従来においては、IRD７１により予約された場合、DVCR８１に、IRD７１のコントローラ７２による制御だけに従い、録画待機状態となるCSモードというモードが設けられており、IRD７１に録画予約Ａを入力した後、DVCR８１をCSモードに設定することでダブルブッキングの発生を防止していた。
【０００８】
【発明が解決しようとする課題】
しかしながら、CSモードに設定されたDVCR８１は、予約待機状態となってしまうので、例えば、映像信号の再生等の処理を実行できず、操作性が悪い課題があった。
【０００９】
また、複数のAV機器が、他のAV機器が管理する情報（録画開始時刻等）を知らないことに起因して、同時にバス２に情報を出力した場合、出力された情報量がバス２の帯域を越えて、伝送エラーが発生する可能性がある課題があった。
【００１０】
本発明はこのような状況に鑑みてなされたものであり、バスに接続されている各AV機器が、管理している情報を相互に知ることができるようにすることにより、録画予約時の操作性を向上させるとともに、ダブルブッキングの発生を抑止することができるようにするものである。
【００１１】
【課題を解決するための手段】
本発明の情報処理装置は、ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定する設定手段と、前記設定手段により設定された前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開する第１の記憶手段と、前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を記憶する第２の記憶手段と、前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、前記設定手段により設定された前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させる制御手段とを備え、前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。
【００２８】
前記ネットワークは、IEEE1394シリアルデータバスを用いて構成されるようにすることができる。
【００２９】
本発明の情報処理方法は、ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させるステップを含み、前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。
【００３０】
本発明の記録媒体のプログラムは、ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させるステップを含む処理をコンピュータに実行させる。前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。
【００３１】
本発明においては、ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDが設定され、設定された前記オブジェクトIDとともに、前記サブユニットの予約に関する情報が第１の記憶手段に記憶され、記憶されている情報が、前記ネットワークを介して接続される装置からの要求に対応して公開される。また、前記サブユニットと前記他のサブユニットを関連させた一連の動作を制御するための情報が第２の記憶手段に記憶され、前記他の情報処理装置が有する、前記他のサブユニットの予約に関する情報を記憶する記憶手段に、設定された前記オブジェクトIDとともに、前記他のサブユニットの予約に関する情報を記憶させることが行われる。前記他の情報処理装置においては、前記他のサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。
【００３２】
【発明の実施の形態】
本発明を適用したネットワークシステムの構成例について、図２を参照して説明する。なお、本明細書においてシステムの用語は、複数の装置、手段などにより構成される全体的な装置を意味するものである。
【００３３】
このネットワークシステムは、バス２を介して接続されているIRD１およびDVCR３から構成されている。当然、このバス２にはIRD１およびDVCR３以外に、例えば、パーソナルコンピュータ、ハードディスクドライブ、CDプレーヤ、モニタ、デジタルビデオカメラ、またはMD（商標）プレーヤ等のIEEE1394端子を備える電子機器を接続することが可能である。
【００３４】
なお、バス２に接続されているIRD１およびDVCR３のような電子機器は、ユニットと呼ばれており、ユニット間においては、AV/C Command Transaction SetのAV/C Digital Interface Command Set General Specification（以下、AV/C Generalと記述する）で規定されているディスクリプタ(Descriptor)を用いて、各ユニットに記憶されている情報を相互に読み書きすることが可能である。AV/C Generalの詳細については、http://www.1394ta.org/Technology/Specifications/を参照のこと。また、ユニットが有する機能はサブユニットと呼ばれている。
【００３５】
IRD１のコントローラ１１は、ユーザからの選局操作や録画予約操作等を受け付けて、IRD１の全体を制御する。また、コントローラ１１は、所定のコマンド(AV/C Command Transaction Set)を用いてDVCR３を制御する。CSアンテナ１３は、図示せぬ通信衛星を介して送信されてくるデジタル衛星放送のデジタル信号を受信して、チューナサブユニット１２に出力する。チューナサブユニット１２は、コントローラ１１の制御に基づいて、CSアンテナ１３から入力されたデジタル信号から所定のチャンネルの信号を抽出し、バス２を介してDVCR３のVCRサブユニット３３に出力する。さらに、コントローラ１１は、DVCR３のBBS（Bulletin  Board  Subunit）３４が記憶している情報を検索する。
【００３６】
IRD１のサブユニットであるBBS１４は、コントローラ１１が受け付けて、確定した録画予約の情報（詳細は、図２０を参照して後述する）を記憶する。
【００３７】
DVCR３のコントローラ３１は、ユーザからの再生指示の操作や録画予約操作等を受け付けて、DVCR３の全体を制御する。アナログチューナブロック３２は、コントローラ３１の制御に基づいて、入力されるアナログ信号から所定のチャンネルの信号を抽出し、VCRサブユニット３３に出力する。
【００３８】
VCRサブユニット３３は、アナログチューナブロック３２から入力された映像信号、またはバス２を介して入力されるIRD１のチューナサブユニット１２からの映像信号を図示せぬ磁気テープに記録する。
【００３９】
BBS３４は、DVCR３に関わる録画予約の情報を管理する。
【００４０】
なお、チューナサブユニット１２とBBS１４は、IRD１のサブユニットであり、VCRサブユニット３３とBBS３４は、DVCR３のサブユニットである。アナログチューナブロック３２は、DVCR３の１つの機能を実行するものではあるが、バス２を介して他のユニットから制御されるものではないので、サブユニットではない。
【００４１】
このネットワークシステムにおいて、デジタル衛星放送の録画予約を行う場合、ユーザはIRD１に対して録画予約の設定（チャンネル、および録画開始時刻等の設定）を入力する。そして、その録画予約がダブルブッキングではない場合、入力された録画予約が認められて、その情報がIRD１のBBS１４に書き込まれる。
【００４２】
BBS１４は、図３に示すように、RSB（Resource  Schedule  Board）５１およびSAB（Schedule  Action  Board）５２から構成される。SAB５２は、IRD１のコントローラ１１または他のユニットのコントローラ（例えば、DVCR３のコントローラ３１）から入力された録画予約に関する全ての情報を記憶する。すなわち、SAB５２は、所定の時刻においてIRD１のチューナサブユニット１２に受信させ、受信した情報をDVCR３のVCRサブユニット３３に録画させるという一連の動作を制御するための全ての情報を記憶している。
【００４３】
これに対して、RSB５１は、録画予約に関する全ての情報（他のユニットにより設定された録画予約を含む）のうちの、IRD１のサブユニットであるチューナサブユニット１２の予約に関する情報のみを記憶し（関連して動作する場合であっても、VCRサブユニット３３の予約情報は記憶しない）、記憶した情報を同一ユニット内のコントローラ１１だけでなく、他のユニットのコントローラ（例えば、DVCR３のコントローラ３１）からの要求に対応して公開する。
【００４４】
同様に、DVCR３のBBS３４は、図４に示すように、RSB６１およびSAB６２から構成される。SAB６２は、DVCR３のコントローラ３１または他のユニットのコントローラ（例えば、IRD１のコントローラ１１）から入力された録画予約に関する全ての情報を記憶する。これに対して、RSB６１は、DVCR３のコントローラ３１に入力された録画予約、およびIRD１のコントローラ１１に入力された録画予約に関する全ての情報のうちの、DVCR３のサブユニットであるVCRサブユニット３３の予約に関する情報を記憶し（関連して動作する場合であっても、チューナサブユニット１２の予約情報は記憶しない）、記憶した情報を同一ユニット内のコントローラ３１は勿論、他のユニットのコントローラ（例えば、IRD１のコントローラ１１）からの要求に対応して公開する。
【００４５】
なお、RSB５１，６１に記憶され、公開される情報の詳細は、図２２を参照して詳述する。
【００４６】
次に、図５を参照して、RSB５１，６１が関連する動作について説明する。例えば、図５に示すように、IRD１のコントローラ１１に、録画予約（１０月１６日、２０時００分から２１時００分まで、チューナサブユニット１２に、第４８チャンネルを受信させ、受信した映像信号をDVCR３のVCRサブユニット３３に録画させる予約）が入力された場合、コントローラ１１は、その録画予約に対して固有のID(BB  Object ID)（この例の場合、ID_X）を設定し、SAB５２に、その録画予約に関する全ての情報を記憶させるとともに、RSB５１に、設定したID（ID_X）、日時（１０月１６日、２０時００分から２１時００分まで）、および関連するIRD１のサブユニット（いまの例の場合、チューナサブユニット１２）を特定する情報（識別情報）を記憶させる。さらに、コントローラ１１は、DVCR３のRSB６１に、設定したID（ID_X）、日時（１０月１６日、２０時００分から２１時００分まで）、および関連するDVCR３のサブユニット（いまの例の場合、VCRサブユニット３３）を特定する情報（識別情報）を記憶させる。
【００４７】
その後、例えば図６に示すように、DVCR３のコントローラ３１に、録画予約（１０月１６日、２０時００分から２１時００分までアナログチューナブロック３２に第３チャンネルを受信させ、受信した映像をVCRサブユニット３３に録画させる予約）が入力された場合、コントローラ３１は、RSB６１を参照し、入力された録画予約の情報と、既に録画予約が承認されてRSB６１に公開されている情報が重複するか否かを判定する。いまの例の場合、録画時刻１０月１６日、２０時００分から２１時００分までが重複するので、入力された録画予約は承認されない。なお、入力された録画予約の情報と、既に録画予約が承認されてRSB６１に公開（登録）されている情報が重複しないと判定された場合、入力された録画予約は承認され、その情報の全てがSAB６２に記録され、全ての情報のうちのVCRサブユニット３３に関する予約情報は、RSB６１に記録される。
【００４８】
次に図７乃至図９のフローチャートを参照して、以上の予約処理（競合ユニット検索処理）の詳細について説明する。
【００４９】
最初にステップＳ１１において、ユーザは、IRD１のコントローラ１１に対して、予約設定処理を行う。すなわち図５の例の場合、１０月１６日の２０時００分から２１時００分まで、第４８チャンネルをチューナサブユニット１２に受信させ、これをDVCR３のVCRサブユニット３３に転送し、記録させることが入力される。この時コントローラ１１は、ステップＳ１２において、使用するサブユニットの存在する機器内のRSBをWRITE  OPENさせる処理を実行する。図５の例の場合、使用するサブユニットは、IRD１のチューナサブユニット１２とDVCR３のVCRサブユニット３３であるから、最初にそのうちの１つの、例えば、チューナサブユニット１２が選択され、コントローラ１１は、チューナサブユニット１２を有する機器としてのIRD１のRSB５１をWRITE  OPENする（書き込み可能な状態にする）ために、WRITE  OPENコマンドを出力する。
【００５０】
但し実際には、RSB５１とコントローラ１１とはIRD１内に保持されているものであり、その間には、バス２は存在していない。そこで、コントローラ１１は、RSB５１に対して、バス２を介してWRITE  OPENコマンドが供給されてきた場合と同様の状態となるように、RSB５１を制御する。
【００５１】
例えば、関連して使用されるサブユニットのうち、チューナサブユニット１２が存在する機器としてのIRD１におけるRSB５１に対するWRITE  OPENの処理が完了した後、次に残りの関連するサブユニットとしてのVCRサブユニット３３が存在する機器としてのDVCR３におけるRSB６１をWRITE  OPENする処理が同様に行われるのであるが、その場合には、コントローラ１１は、バス２を介して、図１０に示すようなフォーマットのWRITE  OPENコマンドをDVCR３のRSB６１（コントローラ３１）に出力する。
【００５２】
このWRITE  OPENコマンドは、ターゲットの所定のアドレス空間にアクセスするために使用される、OPEN  DESCRIPTORコマンドの一種であり、図１０に示すようなフォーマットとされる。そのopcodeには、OPEN  DESCRIPTORであることを表す値”０８16”が記述される。operand０には、WRITE  OPENするdescriptorの種類を表すdescriptor_typeとして、リストIDにより規定されるObject  List  Descriptorであることを表す値”１０16”が記述される。operand１とoperand２には、アクセス先の（WRITE  OPENする）RSBのリストID（この例においては、”００”と”０１”）が記述される。
【００５３】
さらにoperand３には、subfunctionとして、descriptorを、読み出しまたは書き込みアクセスのためにオープンするWRITE  OPENであることを表す値”０３16”が記述される。operand４は、リザーブのための値”００”とされている。
【００５４】
次にステップＳ１３に進み、コントローラ１１は、BBS１４内のRSB５１のdescrptior_lengthと、list_specific_information  field（図２２）を読み出す。この読み出しは、例えば図１１に示すREADコマンドを利用して行われる。但しこの場合においても、コントローラ１１とRSB５１は、バス２を介して接続されている訳ではないので、コントローラ１１からRSB５１に対する読み出しは、直接的に行われる。ただし、コントローラ１１がDVCR３のRSB６１からデータを読み出す場合には、図１１に示すようなREADコマンドが、バス２を介して、RSB６１（コントローラ３１）に出力される。
【００５５】
図１１に示すように、READコマンドの先頭のopcodeとしては、read  descriptorであることを表す値、”０９16”が記述されている。続くoperand０には、読み出すdescriptorを識別するためのdescriptor  identifierが、記述される。このステップＳ１３における読み出しの処理の場合は、リストIDでdescriptor  identifierが記述される。具体的には後述する図２３のRSBのwrite  enabled  list_specific_information  fieldのAddress_offsetの”００16”乃至”０Ｄ16”が記述される。
【００５６】
read_result_statusには、READコマンドを送出するときは、FFが記述され、ターゲットからリスポンスとして返される場合には、読み取り結果が記述される。data_lengthには、ターゲットから読み出されるべきデータのバイト数が記述される。この値が”０”に設定された時、全てのリストが読み出される。addressには、読み出しを開始すべきアドレスが記述される。その値が”００”とされた場合、先頭から読み出しが開始される。
【００５７】
ステップＳ１４において、コントローラ１１はターゲットとしてのRSB５１に対するリストの最大長の制限（図２３におけるobject_list_maximum_size）、リストのエントリ数の制限（図２３におけるobject_entries_maximum_number）、および各エントリの最大バイト長の制限（図２３におけるobject_entry_maximum_size）を抽出する。
【００５８】
そしてステップＳ１５において、コントローラ１１は、これからRSB５１にデータ（予約情報）を記録しても、ステップＳ１４で抽出されたリストの最大長（object_list_maximum_size）を越えないか否かを判定する。この制限が守られる場合には、ステップＳ１６に進み、コントローラ１１は、ステップＳ１４で抽出されたリストのエントリ数の制限（最大エントリ数）（object_entries_maximum_number）から、現在のエントリ数を引いた値が”０”より大きいか否か、すなわち、まだ記録可能なエントリが残っているか否かを判定する。この条件が満足される場合には、さらにステップＳ１７に進み、コントローラ１１は、ステップＳ１４で抽出された最大エントリ長（object_entry_maximum_size）から、これから書き込もうとしている予約情報のエントリ長を引いた値が”０”より大きいか否か、すなわち、書き込むべきエントリ長に、まだ余裕があるか否かを判定する。
【００５９】
ステップＳ１５乃至ステップＳ１７における条件のいずれか１つが満足されない場合には、ステップＳ１８に進み、コントローラ１１は、例えば「予約が一杯です」のような警告表示をユーザに対して行う。ユーザはこれにより、予約が一杯で、それ以上予約をすることができないことを知ることができる。
【００６０】
ステップＳ１５乃至ステップＳ１７の条件のいずれもが満足される場合には、RSB５１に予約情報を書き込む余裕はあるので、ステップＳ１９乃至ステップＳ２５において、重複する時刻の予約がすでになされているか否かの判定処理が行われる。
【００６１】
すなわちステップＳ１９において、変数ｉに”０”が初期設定され、ステップＳ２０において、RSB５１に記録されているエントリの数number_of_entriesから変数ｉを減算した値が”０”より大きいか否か、すなわちRSB５１に記録されている全てのエントリについて検索が行われたか否かが判定される。number_of_entriesから変数ｉを減算した値が”０”より大きい場合には、まだ検索していないエントリが存在するので、ステップＳ２１に進み、コントローラ１１は、RSB５１に掲示されているobject_entry［ｉ］（図２５）を読み出す（今の場合、object_entry［０］を読み出す）。
【００６２】
なお、ステップＳ２１における読み出しも、図１１に示すREADコマンドで行われるが、この場合におけるdescriptor  identifierの記述はobject  positionで行われる。このobject  entry［ｉ］には、後述するように、既に登録されている予約の時刻情報（図２６におけるstart_time，Duration）や、その予約において、使用するサブユニットの識別情報（図３２におけるsubunit_type_and_ID［０］）などが記憶されている。
【００６３】
そこでステップＳ２２において、コントローラ１１は、ステップＳ１１でユーザより入力された時刻情報（start_time，Duration）が、ステップＳ２１で読み出された時刻情報（start_time，Duration）と重複しているか否かを判定する。時刻が重複している場合には、ステップＳ２３に進み、コントローラ１１は、ステップＳ１１で予約設定されたサブユニット（今の場合、チューナサブユニット１２）が、ステップＳ２１で読み出したサブユニット（subunit_type_and_ID）と一致しているか否かを判定する。サブユニットが一致している場合には、結局、時刻とサブユニットの両方が一致していることになるので、ステップＳ２５に進み、コントローラ１１は、例えば「予約が重なっています」のような警告表示を行う。これによりダブルブッキングは、防止される。
【００６４】
ステップＳ２２において、時刻が重複していないと判定された場合、または、ステップＳ２３において、時刻が一致していたとしても、サブユニットが一致していないと判定された場合、ダブルブッキングが発生する恐れはない。そこでステップＳ２４において、変数ｉが１だけがインクリメントされ、ステップＳ２０に戻り、number_of_entriesから変数ｉを減算した値が０より大きくないと判定されるまで、同様の処理が繰り返し実行される。すなわちRSB５１に記憶されている全てのobject  entry［ｉ］について、重複する時刻の予約がなされているか否かの検索が行われる。
【００６５】
ステップＳ２０において、number_of_entriesから変数ｉを減算した値が”０”より大きくないと判定された場合（全てのobject  entry［ｉ］の検索が終了した場合）、ステップＳ２６に進み、コントローラ１１は、RSB５１にCREATEコマンドを出力し、object  entryをRSB５１においてcreateする。ただし、この場合においても、CREATEコマンドは実際には出力されず（RSB６１に対してobject  entryをcreateする場合は出力されるが）、出力された場合と同様の処理が行われるだけである。
【００６６】
なお、上述したステップＳ１５乃至ステップＳ１８の処理は、ステップＳ２０の処理において、NOの判定が行われた場合に実行するようにすることも可能である。
【００６７】
ここでCREATEコマンドについて説明する。図１２はAV/C  CREATEコマンドのフォーマットを示す。また図１３は、図１２内のsubfunction_１で指定できる値を示し、本実施の形態では”０１”（create  a  new  object  and  its  child  list）が使用される。また図１４は、図１２内のsubfunction_１_specification  for  subfunction_１＝０１のフォーマットを示す。さらに図１５は、図１４内の各フィールド値を示した図である。図１４のdescriptor_identifier_where，descriptor_identifier_what_１，_２の各フィールドに、図１５に示すように、”２０”，”２２”，”１１”をそれぞれ設定すると、”create  a  new  object  and  its  child  list”の意味となる。
【００６８】
これらのAV/C  CREATEコマンドについての詳細は、IEEE１３９４（インターネットホームページhttp://www.１３９４TA.org参照）に記述されているものであり、本実施の形態中の各図は、その文献(Enhancement  to  the  AV/C  General  Specification  ３．０Version  １．０  FC２や、TA  Document  １９９９００５  AV/C  Bulletion  Board  Subunit  General  Specification  １．０  Draft  ０．９９：１４９）中のものを記載してある。また、ボードを構成するインフォメーションディスクリプタ（Information  List  Descriptor）にも書き込み可能なものと読み出し可能なものがあり、これらの区別には、リストタイプが使用される。
【００６９】
ところで、外部からAV/Cディスクリプタ（AV/C  Descriptor）に新規に情報を書き込む方法の１つとして、例えばコントローラがターゲットに対して前述したCREATEコマンドを発行し、当該ターゲットが情報を書き込む雛形を作った後、再度、コントローラが具体的な内容を書き込む制御を行うような方法が一般的な方法として考えられる。例えば、初めて情報を書き込む場合、コントローラは所望のリストを指定して、AV/Cディスクリプタクリエイトコマンド（AV/C  Descriptor  CREATE  command）を発行する。このコマンドを受けたターゲットでは、AV/C  Generalで指定されたデータ構造の雛形に基づいたオブジェクトをターゲットの内部に作ることになる。また、AV/C  Generalで決められたデータ構造の雛形には、オブジェクトIDを示すフィールドがある。AV/Cディスクリプタ(AV/C  Descriptor）を用いたリストでは、オブジェクトIDはターゲットが管理することになる。つまり、オブジェクトをクリエイト(CREATE）した段階で、ターゲットがそのオブジェクトを一意に指定できるIDを付け、そのIDを管理する機能をターゲットが所有することになる。
【００７０】
ここで、オブジェクトIDとは、リスト内でそのオブジェクトを一意に指定するための識別番号であり、このため当該オブジェクトIDを重複しないようにする機能が管理する側に必要になる。BBS自体は情報を提供する場所であり、オブジェクトIDの管理はコントローラが持つことになる。
【００７１】
ところが、サブユニットに対してクリエイトコマンド(CREATE  command）が発行された時、矛盾が生ずる虞がある。すなわち、オブジェクトをCREATEした際には、コントローラが管理すべきオブジェクトIDを、ターゲットが割り振ることになるからである。また、クリエイトコマンド（CREATE  command）の発行後は、ライト制御を続けて行う必要がある。このように、処理が複数ステップにわかれていることにより、コントローラが書き込み途中に例えばバスから外されたような場合には、不完全なオブジェクトが作成されてしまう可能性がある。
【００７２】
したがって、上記のような状況に置いては、その不完全なオブジェクトを特定し、そのようなオブジェクトができたときに、当該オブジェクトを良好に削除できるシステムが必要になる。
【００７３】
そこで、本発明の実施の形態では、BBSへの書き込み手段を規格で規定し、不完全なオブジェクトを特定できる仕組みを用意している。
【００７４】
すなわち、先ず、ターゲット（本実施の形態の場合はDVCR３）は、オブジェクトをクリエイト(CREATE）した時、オブジェクトID（グローバルユニークID(Grobal  Unique  ID：GUID)とrecord  IDとで構成される）のうちのGUIDの部分に、一時的に管理する番号（例えば、全て”０”）を割り振るようにする。コントローラは、先にオブジェクト内部に情報を書き込み、正常に書き込みが終了したならば、最後にGUIDを書き換える。
【００７５】
上記の手順を決めることにより、正常に書き込み作業が終了したときには、GUIDが全て”０”となっているオブジェクトはできないことになり、したがって、GUIDが全て”０”のオブジェクトは、書き込み途中で不完全となったオブジェクトと特定できることになる。
【００７６】
これにより、書き込み途中のオブジェクトを一意に特定することができ、また、正常に書き込まれたオブジェクトと不完全なオブジェクトとを区別でき、さらに不完全なオブジェクト（無効なオブジェクト）を簡単に削除することが可能となる。このことにより、電子機器に設けられている有限なメモリを有効活用できるようになる。また、書き込み途中のオブジェクトの特定方法は、オブジェクトIDのGUID部分を全て”０”にするような簡単な方法なので、不完全なオブジェクトを削除するためのソフトウェアの作成も容易となる。
【００７７】
なお、図９のステップＳ２６において、CREATEコマンドを利用する代わりに、INSERTコマンドを使用することも可能である。
【００７８】
次に、ステップＳ２７に進み、コントローラ１１は、RSB５１のentry_specific_information  fieldsの部分（図２６乃至図３２）に予約内容を書き込む。すなわち、これにより、start_time，Duration，repeat_information,使用するサブユニット（subunit_type_and_ID）などが書き込まれる。
【００７９】
図１６は、このような場合にコントローラ１１が出力するWRITE  DESCRIPTORコマンドのフォーマットを表している。ただしこの場合においても、コントローラ１１とRSB５１は、バス２を介して接続されている訳ではないので、書き込みは直接行われるが、コントローラ１１がDVCR３のRSB６１に書き込みを行う場合には、コントローラ１１は、このWRITE  DESCRIPTORコマンドを発行する。
【００８０】
先頭のopcodeには、WRITE  DESCRIPTORであることを表す値”０Ａ16”が記述される。operand０には、書き込み対象となるディスクリプタを識別させるためのdescriptor  indentifierが記述される。この記述は、object  positionで行われる。
【００８１】
以下、subfunctionとして、partial_replaceであることを表す値、”５０16”が記述される。これによりpartial  insertまたは、partial  delateが実行される。insertでは、descriptor_identifierで指定されるoperandにより規定される１つ前に新しいdescriptiorが挿入される。deleteではdescriptior_identifierにより規定されるdescriptorが削除される。
【００８２】
group_tagは、WRITE  DESCRIPTORコマンドが発行される必要があるdescriptior上において、分割できない更新の処理を行うために利用される。この例においては、データをdescriptorに迅速に書き込むことを表す値”００16”（immediate）が記述されている。replacement_data_lengthは、replacement_dataのoperandにおけるバイト数、すなわち、書き込みたいデータの長さを表している。addressは、処理が行われるべき位置を表している。replacement_data_lengthの”０”は、partial  deleteを意味し、その場合、replacement_dataのoperandは存在しない。この場合、original_data_lengthは”０”より大きい値となり、それが削除されるべきバイトの数を表す。original_data_lengthが”０”である場合、partial  insert処理が行われる。この場合、replacement_data_lengthは、”０”より大きい値とされ、挿入されるべきバイトの数を表している。
【００８３】
次にステップＳ２８に進み、コントローラ１１は、リスト、すなわちRSB５１をクローズする。この時コントローラ１１は、RSB５１に対して、図１７に示すCLOSEコマンドを出力する。ただしこの場合においても、コントローラ１１とRSB５１は、バス２を介して接続されている訳ではないので、クローズ処理は直接的に行われるが、コントローラ１１がDVCR３のRSB６１をクローズする場合には、このCLOSEコマンドが出力される。
【００８４】
図１７に示すCLOSEコマンドのフォーマットは、基本的に図１０に示した、WRITE  OPENコマンドと同様のフォーマットであり、subfunctionが、図１０においては、WRITE  OPENを表す”０３16”とされているのに対して、図１７のCLOSEコマンドにおいては、CLOSEであることを表す値、”００16”とされている点が異なっている。その他の構成は図１０における場合と同様である。
【００８５】
次にステップＳ２９に進み、コントローラ１１は、予約に関連する他のリソースが存在するか否かを判定する。今の場合、これまでの処理によりチューナサブユニット１２を予約するための処理が終了したので、まだDVCR３のVCRサブユニット３３を予約するための処理が必要である。そこで、この場合においては、ステップＳ１２に戻り、上述したRSB５１に対して行われた場合と同様の処理が、DVCR３のRSD６１に対しても行われる。
【００８６】
そしてステップＳ２９において、予約に関連する他のリソースが存在しないと判定された時、処理は終了される。
【００８７】
ところで、例えば図１８に示すように、チューナサブユニット１２で受信した映像信号をDVCR３のVCRサブユニット３３に録画させる一連の録画予約が、受信についてはIRD１に、録画についてはDVCR３に、それぞれ独立して行われた場合、すなわち、IRD１のコントローラ１１には、チューナサブユニット１２に所定の時刻（１０月１６日、２０時００分から２１時００分まで）において所定のチャンネル（第４８チャンネル）を受信させる予約が入力され、DVCR３のコントローラ３１には、VCRサブユニット３３に所定の時刻（１０月１６日、２０時００分から２１時００分まで）に録画を開始させる予約が入力された場合、この２つの予約の入力は、ユーザにとって、１つの録画予約ではあるが、IRD１およびDVCR３にとっては、それぞれ独立した予約入力であるので、それぞれの予約には異なるID（BB Object ID_Y，BB  Object  ID_Z）が設定されて、対応するRSB５１、またはRSB６１に記憶される。
【００８８】
このように、各ユニットにおいて、独立に予約を行う場合においても、図７乃至図９のフローチャートに示した場合と同様の処理により、予約処理を行うことができる。ただし、このように、サブユニットを共同して使用する場合において、それぞれの予約を独立して行うと、ダブルブッキングが発生するか否かは、ユーザが管理する必要がある。
【００８９】
次に、Object ID設定処理について、図１９のフローチャートを参照して説明する。この処理は、ユーザがIRD１に対して、DVCR３を用いる録画予約の操作を入力し、その操作がコントローラ１１に検知され、上述した図７乃至図９の予約処理（競合ユニット検索処理）が実行されて、その録画予約が認められた後、開始される。この例においては、所定の時刻から所定の時間の間、実行される予約処理（Event）に関し、それを識別するために、Object  IDが対応される。このObject  IDは、７２ビットで構成され、そのうちのMSB側の６４ビットは、その予約に関する全ての情報を持っている機器の固有のID、具体的にはその機器のGUID（Global  Unique  ID）とされ、LSB側の８ビットは、その機器内で設定される固有の値とされ、具体的には、record  IDとされる。このようにObject  IDをGUIDとrecord  IDとで構成することにより、Eventを識別するためのObject  IDを設定すると、ID設定の処理が容易となる。
【００９０】
すなわちこのObject  IDは、バス２に接続されている各機器の間において、識別可能である必要がある。そうでなければ、この例においては、１つのユニット（機器）のRSBの内容を他のユニット（機器）が読み込み可能であり、複数のユニットのサブユニットにおいて、共同して（関連して）処理が実行されることがあるので、関連する処理があるか否かを、他のユニットが識別できる必要があるからである。
【００９１】
バス２に接続されている、ユニット間において、識別可能なものであれば、例えば、Object  IDをEventが発生する毎に、番号１から順番に順次設定するようにすることも可能である。しかしながらそのようにすると、所定のユニットが、所定のEventに関して、Object  IDを設定しようとした場合、バス２に接続されている全てのユニットが、既に設定しているObject  IDを読み出して、競合するものがあるか否かを判定し、競合しないものに設定する必要が生じる。しかしながらこの例においては、GUIDがObject  IDに含まれており、GUIDの値は、ユニット毎に異なるものであることが保証されている。したがって各ユニットは、record  IDを自分自身の内部において、競合するものがないように設定すれば、GUIDとrecord  IDを組み合わせて得られるObject  IDは、他のユニットが設定したObject  IDと競合することはない。そこで各ユニットは、図１９のフローチャートに示すような処理を行って、RSBに登録するEventに対するObject  IDを設定する。
【００９２】
ステップＳ４１において、コントローラ１１は、Object ID(=Global Unique ID＋record ID)のうちのrecord IDとして、IRD１内において、その予約情報を一意に識別させるための仮IDを発生する。
【００９３】
ステップＳ４２において、コントローラ１１は、RSB５１に登録されているEventの中から、１つのEventを抽出して、その Eventに対応するObject  IDの中のrecord IDを抽出する。ステップＳ４３において、コントローラ１１は、ステップＳ４１で発生した仮IDと、ステップＳ４２で抽出したrecord IDが一致するか否かを判定し、一致する場合、ステップＳ４１に戻り、仮IDを変更し、一致しない仮IDが発生されるまで、ステップＳ４１乃至Ｓ４３の処理を繰り返す。
【００９４】
仮IDとステップＳ４２で抽出したrecord IDが一致しないと判定された場合、ステップＳ４４において、コントローラ１１は、関連するサブユニットに関するRSB５１に公開されている全てのEventを抽出したか否かを判定し、まだ抽出していないEventが残っている場合はステップＳ４２に戻り、全ての Eventを読み出したと判定するまで、ステップＳ４２乃至Ｓ４４の処理を繰り返す。全てのEventを読み出したと判定された場合、ステップＳ４５において、コントローラ１１は、IRD１の機器ID(GUID)に、ステップＳ４１で発生した仮ID（record  ID）を付加して、Object IDを生成し、RSB５１等に記述する。
【００９５】
このように、Object  IDは、関連するサブユニットに関するRSBをチェックするだけで（関連しないサブユニットを有するユニットのRSBをチェックすることなく）設定することができる。これは、上述したように、他のユニットのRSBにおけるObject  IDは、そのユニットのGUIDが含まれているため、他のユニットが設定したObject  IDは、自分自身が設定したObject  IDと一致することが有り得ないからである。したがって、Object  IDを簡単に設定することが可能となる。
【００９６】
次に、BBSの詳細について説明する。図２０は、BBSを構成するSubunit  identifier  Descriptorのフォーマットを表している。descriptor_lengthは、このDescriptorの長さを表す。generation_IDは、このBBSにおいて、どのAV/C  descriptorフォーマットが使用されるかを表し、通常”００16”とされる。
【００９７】
size_of_list_IDは、list  IDのバイト数を表す。size_of_object_IDは、このobject  IDのバイト数を表す。
【００９８】
size_of_object_posionは、list内のobjectの位置が参照されるときに使用されるバイト数を表す。number_of_root_object_listsは、このBBSが直接関連するroot  object  listsの数を表す。
【００９９】
root_object_list_id_x（ｘ＝０，１，２，・・・ｎ−１）は、このBBSが関連するroot  object  listsのそれぞれのIDを表す。subunit_dependent_information_lengthはsubunit_dependent_informationの長さを表し、subunit_dependent_informationには、このBBSが依存するフォーマットおよびコンテンツに関する情報が記述される。
【０１００】
subunit_dependent_informationには、non_info_block_fiedlds_length，bulletin_board_subunit_version，number_of_supported_board_type（n）supported_board_type_specific_of_length［０］の他、supported_board_type_specific_info［０］乃至supported_board_type_specific_info［ｎ−１］と、それらの長さを表すsupported_board_type_specific_of_length［０］乃至supported_board_type_specific_of_length［ｎ−１］が含まれている。
【０１０１】
さらに、BBSには、manufacturer_dependent_informatinの長さを表す、manufacturer_dependent_lengthと製造者に依存する情報を含むmanufacturer_dependent_informationが記述される。
【０１０２】
root_object_list_idの値は、それがRSBを表すものである場合、図２１に示すように、所定の値”１００１16”とされる。このように、RSB（図２１ではResource  Schedule  Listと記述されている）を表すIDを、所定の値に固定しておくことにより、RSBを読み出す処理が容易となる。
【０１０３】
図２２は、RSBのフォーマットを表している。descriptor_lengthはRSBの長さを表す。list_typeには、RSBがRead  Onlyであるのか、またはWrite  Enabledであるのかが記述される。Read  Only  listは、読み出しのみが可能とされ、Write  Enabled  listには、書き込みが可能とされる。
【０１０４】
size_list_specific_informationは、list_specific_informationの長さを表し、list_specific_informationは、list_typeによって異なるものとなる。Write  Enabled  list_specific_infomationの場合、図２３により詳細に示す情報が記述される。
【０１０５】
non_info_block_fileds_lengthは、non  info  block  fieldsのバイト数を表す。board_typeは、図２４に示すように、Resource  Schedule  Boardの場合、”０１16”とされる。
【０１０６】
object_list_maximum_sizeは、object  listの最大の大きさを表す。object_entry_maximum_numberは、listにおけるobject  entriesの最大の数を表す。object_entry_maximum_sizeは、object  entryの最大の大きさを表す。以上のobject_list_maximum_size，object_entries_maximum_number，object_entry_maximum_sizeは、それぞれ制限が設けられていない場合には、”００００16”とされる。
【０１０７】
これらの３つのフィールドは、コントローラがobject  listまたは、object  entryの容量を知る上において、有意義である。
【０１０８】
board_type_dependent_information_lengthは、board_type_dependent_informationの長さを表し、board_type_dependent_informationは、board  typeに固有の情報を表す。
【０１０９】
object_entryは、より詳細には、図２５に示すように構成される。descriptor_lengthは、このdescriptorの長さを表し、entry_typeは、Board  entry  Descriptorの場合、Board  を表す値”８０16”とされる。
【０１１０】
object_IDは、posting_device_GUIDとrecord_IDとにより構成される。posting_deviceは、BBSに対して情報を記入（post）したコントローラを意味し、従ってposting_device_GUIDは、そのGUIDを表す。record_IDは、ユニット内においてEventに対して割当てられたIDを表す。
【０１１１】
size_of_entry_specific_imformationは、entry_specific_imformationの大きさを表す。
【０１１２】
図２６は、entry_specific_imformationのフォーマットを表している。non_info_block_lengthは、repeat_informationまでのnon-info  block  fieldsのバイト数を表す。start_timeは、詳細には、図２７に示すように、eventが開始する年月日時分秒を表す。年は、１６ビットで、４つの数字がそれぞれ４ビットのBCDで表される。月は、８ビットで、２つの数字がそれぞれ４ビットのBCDで表される。日は、８ビットで、２つの数字がそれぞれ４ビットのBCDで表される。時間は、８ビットで、２つの数字が、それぞれ４ビットのBCDで表される。分は、８ビットで、２つの数字がそれぞれ４ビットのBCDで表される。秒は、８ビットで、２つの数字が、それぞれ４ビットのBCDで表される。
【０１１３】
このようにBCDで表すことにより、識別が容易となる。またこの時刻は、ローカルタイムで表される。
【０１１４】
eventの長さを表すDurationは、詳細には図２８に示すように、時分秒で表される。時間は、３つの数字がそれぞれ４ビットのBCDで表され、合計１２ビットとされる。分は，２つの数字がそれぞれ４ビットのBCDとされ、合計８ビットで表される。秒は２つの数字がそれぞれ４ビットのBCDで表され、合計８ビットとされる。
【０１１５】
start_timeにDurationを加算することで、evntの終了時刻が表される。終了時刻を直接的に表現せずに、Durationとしてeventの長さを表すようにすることで、eventのstart_timeが変更されたような場合においても、その終了時刻は変更する必要がなくなり、変更処理が容易となる。
【０１１６】
repeat_information_lengthは、repeat_informationの長さを表している。  repeat_informationは、いつどのようにしてscheduleが繰り返されるかを表す。Scheduled  Actionが繰り返されない場合、repeat_infomation_lengthは、”００16”とされる。
【０１１７】
repeat_informationは、選択されたrepeat  typeによって内容が異なる。repeat  typeには、図２９に示すように、Weekly  schedule”００16”と、Interval  schedule”１０16”とがある。
【０１１８】
scheduleが、週毎に繰り返される場合、Posting  Deviceは、その曜日および繰り返されるべきeventの数を図３０に示すように表示する。
【０１１９】
repeat_typeには、図２９に示す値、”００16”が記述される。number_of_eventsには、eventの数が記述される。日曜日から土曜日までのWeekly  flagsは、繰り返されるeventが開始する週の日を表す。例えば、１３時００分から３時間のeventが、毎週月曜日と水曜日に開始される場合、月曜日と水曜日のフラグに”１”が設定され、その他のフラグには”０”が設定される。
【０１２０】
このように週毎に繰り返されるeventが記録できるので、例えば月曜日と水曜日の絶対的な日時を放送日に対応する分だけ記憶させるような場合に比べて、記憶容量は小さくて済ませることが可能ととなる。
【０１２１】
Posting  Deviceは、Scheduled  Actionが所定のintervalsで繰り返される場合、図３１に示すようなフォーマットでeventを記述する。
【０１２２】
repeat_typeには、この例の場合、図２９に示す値”１０16”が記述される。number_of_eventsには、eventの数が記述される。
【０１２３】
interval（間隔）は、現在のeventのstart_timeから次のeventのstart_timeまでの間隔を表す。この間隔は、時分秒で表される。時間は、３つの数字がそれぞれ４ビットのBCDで表され、合計１２ビットで表現される。分と秒は、それぞれ２つの数字が４ビットのBCDとされ、合計８ビットで表現される。
【０１２４】
このように周期的に繰り返されるeventが記憶できるので、それぞれが開始される絶対時刻（日時）を別に記憶させる場合に比べて、記憶容量が少なくて済む。
【０１２５】
図２６に示すように、info  blocksは図３２に示すようなフォーマットとされる。conpound_lengthは、info  blockのバイト長を表す。ただしlengthフィールド自身は、この長さに含まれていない。info_block_typeは”８９００16”にセットされる。primary_fields_lengthは、number_of_subunitsとsubunit_type_and_ID  fieldのバイト数を表す。
【０１２６】
number_of_subunitsは、posting  Deviceが使用するsubunitsの数を表す。  subunit_type_and_IDは、posting  Deviceが使用するsubunitsを指定する。
【０１２７】
このようにstart_timeとDurationが固定のアドレスにおける固定の長さで表される。それに対して、subunitと、それを使用するPosting  Deviceを識別する識別情報は、Info  blocksとして、start_time，Durationなどより後の所定のアドレスに記憶される。これによりPosting  Deviceの数が増加としても、対応が容易となる。
【０１２８】
図２０のsupported_board_type_specific_informationフィールドは、図３３に示すようなフォーマットとされる。supported_board_typeには、図２４に示すRSBであることを表す値”０１16”が記述される。supported_board_type_versionは、bulletin  Bond  Type  Specificationのバージョンの番号を表す。inplementation_profile_IDはこのboard  typeのためのprofile  IDバージョンを表す。
【０１２９】
supported_board_type_dependend_information_lengthは、supported_type_dependent_informationのバイト数を表す。supported_board_type_dependent_informationには、各board  type  specificationに固有の情報が記述される。
【０１３０】
上述した一連の処理は、ハードウエアにより実行させることもできるが、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアとしてのコントローラに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどにインストールされる。
【０１３１】
汎用のパーソナルコンピュータ１０１は、例えば、図３４に示すように、CPU（Central  Processing  Unit）１１１を内蔵している。CPU１１１には、バス１１５を介して入出力インターフェース１１６が接続されており、CPU１１１は、入出力インターフェース１１６を介して、ユーザから、キーボード、マウスなどよりなる入力部１１８から指令が入力されると、それに対応して、ROM（Read  Only  Memory）１１２あるいはハードディスク１１４などの記録媒体、または、ドライブ１２０に装着された磁気ディスク１３１，光ディスク１３２、光磁気ディスク１３３などの記録媒体から、それらに記録されている、上述した一連の処理を実行するプログラムを読み出し、RAM(Ramdom  Access  Memory)１１３にインストールし、実行する。なお、ハードディスク１１４に格納されているプログラムには、予め格納されてユーザに配布されるものだけでなく、衛星もしくは、ネットワークから転送され、通信部１１９により受信され、インストールされたプログラムも含まれる。
【０１３２】
また、CPU１１１は、プログラムの処理結果のうち、画像信号を、入出力インターフェース１１６を介して、LCD（Liquid  Crystal  Display），CRT（Cathode  Ray  Tube）などよりなる表示部１１７に出力する。
【０１３３】
【発明の効果】
以上のように、本発明によれば、ダブルブッキングの発生を抑止することが可能となる。
【図面の簡単な説明】
【図１】従来のネットワークシステムの構成例を示すブロック図である。
【図２】本発明を適用したネットワークシステムの構成例を示すブロック図である。
【図３】図２のBBS１４の構成例を示すブロック図である。
【図４】図２のBBS３４の構成例を示すブロック図である。
【図５】図２のネットワークシステムの動作を説明する図である。
【図６】図２のネットワークシステムの動作を説明する図である。
【図７】図５のネットワークシステムの動作を説明するフローチャートである。
【図８】図５のネットワークシステムの動作を説明するフローチャートである。
【図９】図５のネットワークシステムの動作を説明するフローチャートである。
【図１０】  WRITE  OPENコマンドのフォーマットを説明する図である。
【図１１】  READコマンドのフォーマットを説明する図である。
【図１２】  CREATEコマンドのフォーマットを説明する図である。
【図１３】図１２のsubfunction_１を説明する図である。
【図１４】図１３のsubfunction_１の詳細を説明する図である。
【図１５】図１４におけるフィールドの値の例を示す図である。
【図１６】  WRITE  DESCRITORコマンドのフォーマットを説明する図である。
【図１７】  CLOSEコマンドのフォーマットを説明する図である。
【図１８】図２のネットワークシステムの他の動作を説明する図である。
【図１９】  Object  ID設定処理を説明するフローチャートである。
【図２０】  BBSのフォーマットを説明する図である。
【図２１】図２０のroot_object_list_IDを説明する図である。
【図２２】  RSBのフォーマットを説明する図である。
【図２３】図２２のWrite  Enabled  list_specific_informationのフォーマットを説明する図である。
【図２４】図２３のboard_typeのフォーマットを説明する図である。
【図２５】図２２のobject_entryのフォーマットを説明する図である。
【図２６】図２５のResource  Schedule  Entryのフォーマットを説明する図である。
【図２７】図２６のstart_timeのフォーマットを説明する図である。
【図２８】図２６のDurationのフォーマットを説明する図である。
【図２９】図３０のrepeat_typeのフォーマットを説明する図である。
【図３０】図２６のrepeat_informationのフォーマットを説明する図である。
【図３１】図２６のrepeat_informationのフォーマットを説明する図である。
【図３２】図２６のInfo  blocksのフォーマットを説明する図である。
【図３３】図２０のsupported_board_type_specific_informationのフォーマットを説明する図である。
【図３４】コンピュータの構成例を示すブロック図である。
【符号の説明】
１  IRD，  ２  IEEE1394シリアルデータバス，  ３  DVCR，  １１  コントローラ，  １２  チューナサブユニット，  １４  ＢＢＳ，  ３１  コントローラ，  ３２  アナログチューナブロック，  ３３  VCRサブユニット，  ３４  BBS，  ５１  RSB，  ５２  SAB，  ６１  RSB，  ６２  SAB
【図１】
0004186332.tif 000002
【図２】
0004186332.tif 000003
【図３】
0004186332.tif 000004
【図４】
0004186332.tif 000005
【図５】
0004186332.tif 000006
【図６】
0004186332.tif 000007
【図７】
0004186332.tif 000008
【図８】
0004186332.tif 000009
【図９】
0004186332.tif 000010
【図１０】
0004186332.tif 000011
【図１１】
0004186332.tif 000012
【図１２】
0004186332.tif 000013
【図１３】
0004186332.tif 000014
【図１４】
0004186332.tif 000015
【図１５】
0004186332.tif 000016
【図１６】
0004186332.tif 000017
【図１７】
0004186332.tif 000018
【図１８】
0004186332.tif 000019
【図１９】
0004186332.tif 000020
【図２０】
0004186332.tif 000021
【図２１】
0004186332.tif 000022
【図２２】
0004186332.tif 000023
【図２３】
0004186332.tif 000024
【図２４】
0004186332.tif 000025
【図２５】
0004186332.tif 000026
【図２６】
0004186332.tif 000027
【図２７】
0004186332.tif 000028
【図２８】
0004186332.tif 000029
【図２９】
0004186332.tif 000030
【図３０】
0004186332.tif 000031
【図３１】
0004186332.tif 000032
【図３２】
0004186332.tif 000033
【図３３】
0004186332.tif 000034
【図３４】
0004186332.tif 000035