JP2000316133A - 情報処理装置および方法、並びに記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 ダブルブッキングを防止する。 【解決手段】 コントローラ１１は、所定の時刻にチュ
ーナサブユニット１２で、所定のチャンネルの放送を受
信させ、IEEE１３９４シリアルデータバス２を介して、
DVCR３のVCRサブユニット３３に記録させる場合、IRD１
のBBS（BulletinBoard Subunit）１４に内蔵されるRSB
（Resource Schedule Board）５１に予約情報を書き
込むとともに、DVCR３のBBS３４に内蔵されているRSB６
１にVCRサブユニット３３の予約情報を書き込む。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、情報処理装置およ
び方法、並びに記録媒体に関し、特に、IEEE1394シリア
ルデータバスを介して他の情報処理装置と接続される情
報処理装置において、内蔵するサブユニットを重複する
ことなく、確実に制御することができるようにした情報
処理装置および方法、並びに記録媒体に関する。

【０００２】

【従来の技術】IEEE1394シリアルデータバスを用いたネ
ットワークを介して、相互に情報を伝達することができ
るAV機器が開発されている。このネットワークにおいて
は、所定のコマンド(AV/C Command Transaction Set)を
用いることにより、ネットワークに接続されているAV機
器を制御することが可能である。例えば、図１に示すよ
うに、デジタル衛星放送を受信するIRD(Integrated Rec
eiver Decoder)７１で受信した映像信号を、IEEE（Inst
itute of Electical and Electronic Engineers）
1394シリアルデータバス２（以下、単に、バス２と記述
する）を介して接続されているDVCR(Digital Video Cas
sette 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８１に、I
RD７１のコントローラ７２による制御だけに従い、録画
待機状態となるCSモードというモードが設けられてお
り、IRD７１に録画予約Ａを入力した後、DVCR８１をCS
モードに設定することでダブルブッキングの発生を防止
していた。

【０００８】

【発明が解決しようとする課題】しかしながら、CSモー
ドに設定されたDVCR８１は、予約待機状態となってしま
うので、例えば、映像信号の再生等の処理を実行でき
ず、操作性が悪い課題があった。

【０００９】また、複数のAV機器が、他のAV機器が管理
する情報（録画開始時刻等）を知らないことに起因し
て、同時にバス２に情報を出力した場合、出力された情
報量がバス２の帯域を越えて、伝送エラーが発生する可
能性がある課題があった。

【００１０】本発明はこのような状況に鑑みてなされた
ものであり、バスに接続されている各AV機器が、管理し
ている情報を相互に知ることができるようにすることに
より、録画予約時の操作性を向上させるとともに、ダブ
ルブッキングの発生を抑止することができるようにする
ものである。

【００１１】

【課題を解決するための手段】請求項１に記載の情報処
理装置は、サブユニットの予約に関する予約情報を入力
する入力手段と、サブユニットの予約に関する予約情報
を記憶する記憶手段と、他の情報処理装置から要求があ
った場合、記憶手段に記憶されている予約情報を読み出
して、他の情報処理装置に供給する供給手段とを備える
ことを特徴とする。

【００１２】自己のサブユニットと、他の情報処理装置
のサブユニットの両方を同時刻に関連して使用するため
に予約する場合、自己のサブユニットの予約情報を記憶
手段に書き込むとともに、他の情報処理装置のサブユニ
ットの予約情報を、他の情報処理装置の記憶手段に書き
込む書き込み手段をさらに設けることができる。

【００１３】自己の記憶手段に記憶されている予約情報
と、関連して同時刻に使用されるサブユニットを有する
他の情報処理装置の記憶手段に記憶されている予約情報
を、入力手段より入力された予約情報と比較する比較手
段をさらに設け、書き込み手段に、比較手段の比較結果
に対応して、予約情報の書き込みを行わせるようにする
ことができる。

【００１４】前記書き込み手段には、自己の記憶手段に
書き込みを行う場合、他の情報処理装置からの予約情報
の自己の記憶手段への書き込みを制限させるようにする
ことができる。

【００１５】前記書き込み手段には、自己の記憶手段に
書き込みを行う場合、他の情報処理装置からの予約情報
の自己の記憶手段からの読み出しが行われているとき、
その読み出しを中止させるようにすることができる。

【００１６】前記記憶手段には、そこに記憶される予約
情報の制限に関する制限情報も記憶させ、前記供給手段
には、他の情報処理装置から要求があった場合、制限情
報も他の情報処理装置に供給させるようにすることがで
きる。

【００１７】前記記憶手段には、予め定められた特定の
アドレス位置に、予約情報を記憶させるようにすること
ができる。

【００１８】前記予約情報には、サブユニットの使用を
開始する開始時刻と、サブユニットを使用する使用時間
を含ませるようにすることができる。

【００１９】前記使用時間は、不定として設定可能であ
るようにすることができる。

【００２０】前記予約情報には、サブユニットを予約す
る情報処理装置に関する装置情報を含ませ、装置情報
は、開始時刻および使用時間より後のアドレス位置に記
憶させるようにすることができる。

【００２１】前記開始時刻は、BCDで表されるようにす
ることができる。

【００２２】前記記憶手段には、記憶された予約情報を
識別する識別情報をさらに記憶させるようにすることが
できる。

【００２３】前記識別情報には、サブユニットを予約し
た情報処理装置に固有な値と、情報処理装置内で設定さ
れた予約に固有な値とを含ませるようにすることができ
る。

【００２４】前記サブユニットを予約した情報処理装置
に固有な値は、グローバルユニークIDとして、情報処理
装置内で設定された予約に固有な値は、レコードIDとす
ることができる。

【００２５】前記予約情報には、サブユニットを、曜日
を指定して毎週繰り返し予約する週間予約情報を含ませ
るようにすることができる。

【００２６】前記予約情報には、サブユニットを、所定
の間隔で繰り返し予約する間隔予約情報を含ませるよう
にすることができる。

【００２７】前記記憶手段は、サブユニットの１つであ
るようにすることができる。

【００２８】前記ネットワークは、IEEE1394シリアルデ
ータバスを用いて構成されるようにすることができる。

【００２９】請求項１９に記載の情報処理方法は、サブ
ユニットの予約に関する予約情報を入力する入力ステッ
プと、サブユニットの予約に関する予約情報の記憶を制
御する記憶制御ステップと、他の情報処理装置から要求
があった場合、記憶ステップの処理により記憶された予
約情報を読み出して、他の情報処理装置に供給する供給
ステップと を含むことを特徴とする。

【００３０】請求項２０に記載の記録媒体のプログラム
は、サブユニットの予約に関する予約情報を入力する入
力ステップと、サブユニットの予約に関する予約情報の
記憶を制御する記憶制御ステップと、他の情報処理装置
から要求があった場合、記憶制御ステップの処理により
記憶された予約情報を読み出して、他の情報処理装置に
供給する供給ステップとを含むことを特徴とする。

【００３１】請求項１に記載の情報処理装置、請求項１
９に記載の情報処理方法、および請求項２０に記載の記
録媒体においては、サブニットの予約に関する予約情報
が記憶されるとともに、記憶された予約情報は、他の情
報処理装置から要求があった場合、他の情報処理装置に
供給される。

【００３２】

【発明の実施の形態】本発明を適用したネットワークシ
ステムの構成例について、図２を参照して説明する。な
お、本明細書においてシステムの用語は、複数の装置、
手段などにより構成される全体的な装置を意味するもの
である。

【００３３】このネットワークシステムは、バス２を介
して接続されているIRD１およびDVCR３から構成されて
いる。当然、このバス２にはIRD１およびDVCR３以外
に、例えば、パーソナルコンピュータ、ハードディスク
ドライブ、CDプレーヤ、モニタ、デジタルビデオカメ
ラ、またはMD（商標）プレーヤ等のIEEE1394端子を備え
る電子機器を接続することが可能である。

【００３４】なお、バス２に接続されているIRD１およ
びDVCR３のような電子機器は、ユニットと呼ばれてお
り、ユニット間においては、AV/C Command Transaction
SetのAV/C Digital Interface Command Set General S
pecification（以下、AV/C Generalと記述する）で規定
されているディスクリプタ(Descriptor)を用いて、各ユ
ニットに記憶されている情報を相互に読み書きすること
が可能である。AV/C Generalの詳細については、http:/
/cxn02.net.arch.sony.co.jp/Doc/に公開されている。
また、ユニットが有する機能はサブユニットと呼ばれて
いる。

【００３５】IRD１のコントローラ１１は、ユーザから
の選局操作や録画予約操作等を受け付けて、IRD１の全
体を制御する。また、コントローラ１１は、所定のコマ
ンド(AV/C Command Transaction Set)を用いてDVCR３を
制御する。CSアンテナ１３は、図示せぬ通信衛星を介し
て送信されてくるデジタル衛星放送のデジタル信号を受
信して、チューナサブユニット１２に出力する。チュー
ナサブユニット１２は、コントローラ１１の制御に基づ
いて、CSアンテナ１３から入力されたデジタル信号から
所定のチャンネルの信号を抽出し、バス２を介してDVCR
３のVCRサブユニット３３に出力する。さらに、コント
ローラ１１は、DVCR３のBBS（BulletinBoard Subuni
t）３４が記憶している情報を検索する。

【００３６】IRD１のサブユニットであるBBS１４は、コ
ントローラ１１が受け付けて、確定した録画予約の情報
（詳細は、図２０を参照して後述する）を記憶する。

【００３７】DVCR３のコントローラ３１は、ユーザから
の再生指示の操作や録画予約操作等を受け付けて、DVCR
３の全体を制御する。アナログチューナブロック３２
は、コントローラ３１の制御に基づいて、入力されるア
ナログ信号から所定のチャンネルの信号を抽出し、VCR
サブユニット３３に出力する。

【００３８】VCRサブユニット３３は、アナログチュー
ナブロック３２から入力された映像信号、またはバス２
を介して入力されるIRD１のチューナサブユニット１２
からの映像信号を図示せぬ磁気テープに記録する。

【００３９】BBS３４は、DVCR３に関わる録画予約の情
報を管理する。

【００４０】なお、チューナサブユニット１２とBBS１
４は、IRD１のサブユニットであり、VCRサブユニット３
３とBBS３４は、DVCR３のサブユニットである。アナロ
グチューナブロック３２は、DVCR３の１つの機能を実行
するものではあるが、バス２を介して他のユニットから
制御されるものではないので、サブユニットではない。

【００４１】このネットワークシステムにおいて、デジ
タル衛星放送の録画予約を行う場合、ユーザはIRD１に
対して録画予約の設定（チャンネル、および録画開始時
刻等の設定）を入力する。そして、その録画予約がダブ
ルブッキングではない場合、入力された録画予約が認め
られて、その情報がIRD１のBBS１４に書き込まれる。

【００４２】BBS１４は、図３に示すように、RSB（Reso
urce Schedule Board）５１およびSAB（Schedule Ac
tion Board）５２から構成される。SAB５２は、IRD１
のコントローラ１１または他のユニットのコントローラ
（例えば、DVCR３のコントローラ３１）から入力された
録画予約に関する全ての情報を記憶する。すなわち、SA
B５２は、所定の時刻において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３
のコントローラ３１に、録画予約（１０月１６日、２０
時００分から２１時００分までアナログチューナブロッ
ク３２に第３チャンネルを受信させ、受信した映像をVC
Rサブユニット３３に録画させる予約）が入力された場
合、コントローラ３１は、RSB６１を参照し、入力され
た録画予約の情報と、既に録画予約が承認されてRSB６
１に公開されている情報が重複するか否かを判定する。
いまの例の場合、録画時刻１０月１６日、２０時００分
から２１時００分までが重複するので、入力された録画
予約は承認されない。なお、入力された録画予約の情報
と、既に録画予約が承認されてRSB６１に公開（登録）
されている情報が重複しないと判定された場合、入力さ
れた録画予約は承認され、その情報の全てがSAB６２に
記録され、全ての情報のうちのVCRサブユニット３３に
関する予約情報は、RSB６１に記録される。

【００４８】次に図７乃至図９のフローチャートを参照
して、以上の予約処理（競合ユニット検索処理）の詳細
について説明する。

【００４９】最初にステップＳ１１において、ユーザ
は、IRD１のコントローラ１１に対して、予約設定処理
を行う。すなわち図５の例の場合、１０月１６日の２０
時００分から２１時００分まで、第４８チャンネルをチ
ューナサブユニット１２に受信させ、これをDVCR３のVC
Rサブユニット３３に転送し、記録させることが入力さ
れる。この時コントローラ１１は、ステップＳ１２にお
いて、使用するサブユニットの存在する機器内のRSBをW
RITE OPENさせる処理を実行する。図５の例の場合、使
用するサブユニットは、IRD１のチューナサブユニット
１２とDVCR３のVCRサブユニット３３であるから、最初
にそのうちの１つの、例えば、チューナサブユニット１
２が選択され、コントローラ１１は、チューナサブユニ
ット１２を有する機器としてのIRD１のRSB５１をWRITE
OPENする（書き込み可能な状態にする）ために、WRIT
E OPENコマンドを出力する。

【００５０】但し実際には、RSB５１とコントローラ１
１とはIRD１内に保持されているものであり、その間に
は、バス２は存在していない。そこで、コントローラ１
１は、RSB５１に対して、バス２を介してWRITE OPENコ
マンドが供給されてきた場合と同様の状態となるよう
に、RSB５１を制御する。

【００５１】例えば、関連して使用されるサブユニット
のうち、チューナサブユニット１２が存在する機器とし
てのIRD１におけるRSB５１に対するWRITE OPENの処理
が完了した後、次に残りの関連するサブユニットとして
のVCRサブユニット３３が存在する機器としてのDVCR３
におけるRSB６１をWRITE OPENする処理が同様に行われ
るのであるが、その場合には、コントローラ１１は、バ
ス２を介して、図１０に示すようなフォーマットのWRIT
E OPENコマンドをDVCR３のRSB６１（コントローラ３
１）に出力する。

【００５２】このWRITE OPENコマンドは、ターゲット
の所定のアドレス空間にアクセスするために使用され
る、OPEN DESCRIPTORコマンドの一種であり、図１０に
示すようなフォーマットとされる。そのopcodeには、OP
EN DESCRIPTORであることを表す値”０８₁₆”が記述さ
れる。operand０には、WRITE OPENするdescriptorの種
類を表すdescriptor_typeとして、リストIDにより規定
されるObject List Descriptorであることを表す値”
１０₁₆”が記述される。operand１とoperand２には、ア
クセス先の（WRITE OPENする）RSBのリストID（この例
においては、”００”と”０１”）が記述される。

【００５３】さらにoperand３には、subfunctionとし
て、descriptorを、読み出しまたは書き込みアクセスの
ためにオープンするWRITE OPENであることを表す値”
０３₁₆”が記述される。operand４は、リザーブのため
の値”００”とされている。

【００５４】次にステップＳ１３に進み、コントローラ
１１は、BBS１４内のRSB５１のdescrptior_lengthと、l
ist_specific_information field（図２２）を読み出
す。この読み出しは、例えば図１１に示すREADコマンド
を利用して行われる。但しこの場合においても、コント
ローラ１１とRSB５１は、バス２を介して接続されてい
る訳ではないので、コントローラ１１からRSB５１に対
する読み出しは、直接的に行われる。ただし、コントロ
ーラ１１がDVCR３のRSB６１からデータを読み出す場合
には、図１１に示すようなREADコマンドが、バス２を介
して、RSB６１（コントローラ３１）に出力される。

【００５５】図１１に示すように、READコマンドの先頭
のopcodeとしては、read descriptorであることを表す
値、”０９₁₆”が記述されている。続くoperand０に
は、読み出すdescriptorを識別するためのdescriptor
identifierが、記述される。このステップＳ１３におけ
る読み出しの処理の場合は、リストIDでdescriptor id
entifierが記述される。具体的には後述する図２３のRS
Bのwrite enabled list_specific_information fiel
dのAddress_offsetの”００₁₆”乃至”０Ｄ₁₆”が記述
される。

【００５６】read_result_statusには、READコマンドを
送出するときは、FFが記述され、ターゲットからリスポ
ンスとして返される場合には、読み取り結果が記述され
る。data_lengthには、ターゲットから読み出されるべ
きデータのバイト数が記述される。この値が”０”に設
定された時、全てのリストが読み出される。addressに
は、読み出しを開始すべきアドレスが記述される。その
値が”００”とされた場合、先頭から読み出しが開始さ
れる。

【００５７】ステップＳ１４において、コントローラ１
１はターゲットとしてのRSB５１に対するリストの最大
長の制限（図２３におけるobject_list_maximum_siz
e）、リストのエントリ数の制限（図２３におけるobjec
t_entries_maximum_number）、および各エントリの最大
バイト長の制限（図２３におけるobject_entry_maximum
_size）を抽出する。

【００５８】そしてステップＳ１５において、コントロ
ーラ１１は、これからRSB５１にデータ（予約情報）を
記録しても、ステップＳ１４で抽出されたリストの最大
長（object_list_maximum_size）を越えないか否かを判
定する。この制限が守られる場合には、ステップＳ１６
に進み、コントローラ１１は、ステップＳ１４で抽出さ
れたリストのエントリ数の制限（最大エントリ数）（ob
ject_entries_maximum_number）から、現在のエントリ
数を引いた値が”０”より大きいか否か、すなわち、ま
だ記録可能なエントリが残っているか否かを判定する。
この条件が満足される場合には、さらにステップＳ１７
に進み、コントローラ１１は、ステップＳ１４で抽出さ
れた最大エントリ長（object_entry_maximum_size）か
ら、これから書き込もうとしている予約情報のエントリ
長を引いた値が”０”より大きいか否か、すなわち、書
き込むべきエントリ長に、まだ余裕があるか否かを判定
する。

【００５９】ステップＳ１５乃至ステップＳ１７におけ
る条件のいずれか１つが満足されない場合には、ステッ
プＳ１８に進み、コントローラ１１は、例えば「予約が
一杯です」のような警告表示をユーザに対して行う。ユ
ーザはこれにより、予約が一杯で、それ以上予約をする
ことができないことを知ることができる。

【００６０】ステップＳ１５乃至ステップＳ１７の条件
のいずれもが満足される場合には、RSB５１に予約情報
を書き込む余裕はあるので、ステップＳ１９乃至ステッ
プＳ２５において、重複する時刻の予約がすでになされ
ているか否かの判定処理が行われる。

【００６１】すなわちステップＳ１９において、変数ｉ
に”０”が初期設定され、ステップＳ２０において、RS
B５１に記録されているエントリの数number_of_entries
から変数ｉを減算した値が”０”より大きいか否か、す
なわちRSB５１に記録されている全てのエントリについ
て検索が行われたか否かが判定される。number_of_entr
iesから変数ｉを減算した値が”０”より大きい場合に
は、まだ検索していないエントリが存在するので、ステ
ップＳ２１に進み、コントローラ１１は、RSB５１に掲
示されているobject_entry［ｉ］（図２５）を読み出す
（今の場合、object_entry［０］を読み出す）。

【００６２】なお、ステップＳ２１における読み出し
も、図１１に示すREADコマンドで行われるが、この場合
におけるdescriptor identifierの記述はobject posi
tionで行われる。この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_entr
iesから変数ｉを減算した値が”０”より大きくないと
判定された場合（全てのobject entry［ｉ］の検索が
終了した場合）、ステップＳ２６に進み、コントローラ
１１は、RSB５１にCREATEコマンドを出力し、object e
ntryをRSB５１においてcreateする。ただし、この場合
においても、CREATEコマンドは実際には出力されず（RS
B６１に対してobjectentryをcreateする場合は出力され
るが）、出力された場合と同様の処理が行われるだけで
ある。

【００６６】なお、上述したステップＳ１５乃至ステッ
プＳ１８の処理は、ステップＳ２０の処理において、NO
の判定が行われた場合に実行するようにすることも可能
である。

【００６７】ここでCREATEコマンドについて説明する。
図１２はAV/C CREATEコマンドのフォーマットを示す。
また図１３は、図１２内のsubfunction_１で指定できる
値を示し、本実施の形態では”０１”（create a new
object and its childlist）が使用される。また
図１４は、図１２内のsubfunction_１_specification
for subfunction_１＝０１のフォーマットを示す。さ
らに図１５は、図１４内の各フィールド値を示した図で
ある。図１４のdescriptor_identifier_where，descrip
tor_identifier_what_１，_２の各フィールドに、図１
５に示すように、”２０”，”２２”，”１１”をそれ
ぞれ設定すると、”create a newobject and its
child list”の意味となる。

【００６８】これらのAV/C CREATEコマンドについての
詳細は、IEEE１３９４（インターネットホームページht
tp://www.１３９４TA.org参照）に記述されているもの
であり、本実施の形態中の各図は、その文献(Enhanceme
nt to the AV/C GeneralSpecification ３．０Ver
sion １．０ FC２や、TA Document １９９９００５
AV/C Bulletion Board Subunit General Specif
ication １．０ Draft ０．９９：１４９）中のもの
を記載してある。また、ボードを構成するインフォメー
ションディスクリプタ（Information List Descripto
r）にも書き込み可能なものと読み出し可能なものがあ
り、これらの区別には、リストタイプが使用される。

【００６９】ところで、外部からAV/Cディスクリプタ
（AV/C Descriptor）に新規に情報を書き込む方法の１
つとして、例えばコントローラがターゲットに対して前
述したCREATEコマンドを発行し、当該ターゲットが情報
を書き込む雛形を作った後、再度、コントローラが具体
的な内容を書き込む制御を行うような方法が一般的な方
法として考えられる。例えば、初めて情報を書き込む場
合、コントローラは所望のリストを指定して、AV/Cディ
スクリプタクリエイトコマンド（AV/C Descriptor CR
EATE command）を発行する。このコマンドを受けたタ
ーゲットでは、AV/C Generalで指定されたデータ構造
の雛形に基づいたオブジェクトをターゲットの内部に作
ることになる。また、AV/C Generalで決められたデー
タ構造の雛形には、オブジェクトIDを示すフィールドが
ある。AV/Cディスクリプタ(AV/C Descriptor）を用い
たリストでは、オブジェクトIDはターゲットが管理する
ことになる。つまり、オブジェクトをクリエイト(CREAT
E）した段階で、ターゲットがそのオブジェクトを一意
に指定できるIDを付け、そのIDを管理する機能をターゲ
ットが所有することになる。

【００７０】ここで、オブジェクトIDとは、リスト内で
そのオブジェクトを一意に指定するための識別番号であ
り、このため当該オブジェクトIDを重複しないようにす
る機能が管理する側に必要になる。BBS自体は情報を提
供する場所であり、オブジェクトIDの管理はコントロー
ラが持つことになる。

【００７１】ところが、サブユニットに対してクリエイ
トコマンド(CREATE command）が発行された時、矛盾が
生ずる虞がある。すなわち、オブジェクトをCREATEした
際には、コントローラが管理すべきオブジェクトIDを、
ターゲットが割り振ることになるからである。また、ク
リエイトコマンド（CREATE command）の発行後は、ラ
イト制御を続けて行う必要がある。このように、処理が
複数ステップにわかれていることにより、コントローラ
が書き込み途中に例えばバスから外されたような場合に
は、不完全なオブジェクトが作成されてしまう可能性が
ある。

【００７２】したがって、上記のような状況に置いて
は、その不完全なオブジェクトを特定し、そのようなオ
ブジェクトができたときに、当該オブジェクトを良好に
削除できるシステムが必要になる。

【００７３】そこで、本発明の実施の形態では、BBSへ
の書き込み手段を規格で規定し、不完全なオブジェクト
を特定できる仕組みを用意している。

【００７４】すなわち、先ず、ターゲット（本実施の形
態の場合はDVCR３）は、オブジェクトをクリエイト(CRE
ATE）した時、オブジェクトID（グローバルユニークID
(Grobal Unique ID：GUID)とrecord IDとで構成され
る）のうちのGUIDの部分に、一時的に管理する番号（例
えば、全て”０”）を割り振るようにする。コントロー
ラは、先にオブジェクト内部に情報を書き込み、正常に
書き込みが終了したならば、最後にGUIDを書き換える。

【００７５】上記の手順を決めることにより、正常に書
き込み作業が終了したときには、GUIDが全て”０”とな
っているオブジェクトはできないことになり、したがっ
て、GUIDが全て”０”のオブジェクトは、書き込み途中
で不完全となったオブジェクトと特定できることにな
る。

【００７６】これにより、書き込み途中のオブジェクト
を一意に特定することができ、また、正常に書き込まれ
たオブジェクトと不完全なオブジェクトとを区別でき、
さらに不完全なオブジェクト（無効なオブジェクト）を
簡単に削除することが可能となる。このことにより、電
子機器に設けられている有限なメモリを有効活用できる
ようになる。また、書き込み途中のオブジェクトの特定
方法は、オブジェクトIDのGUID部分を全て”０”にする
ような簡単な方法なので、不完全なオブジェクトを削除
するためのソフトウェアの作成も容易となる。

【００７７】なお、図９のステップＳ２６において、CR
EATEコマンドを利用する代わりに、INSERTコマンドを使
用することも可能である。

【００７８】次に、ステップＳ２７に進み、コントロー
ラ１１は、RSB５１のentry_specific_information fie
ldsの部分（図２６乃至図３２）に予約内容を書き込
む。すなわち、これにより、start_time，Duration，re
peat_information,使用するサブユニット（subunit_typ
e_and_ID）などが書き込まれる。

【００７９】図１６は、このような場合にコントローラ
１１が出力するWRITE DESCRIPTORコマンドのフォーマ
ットを表している。ただしこの場合においても、コント
ローラ１１とRSB５１は、バス２を介して接続されてい
る訳ではないので、書き込みは直接行われるが、コント
ローラ１１がDVCR３のRSB６１に書き込みを行う場合に
は、コントローラ１１は、このWRITE DESCRIPTORコマ
ンドを発行する。

【００８０】先頭のopcodeには、WRITE DESCRIPTORで
あることを表す値”０Ａ₁₆”が記述される。operand０
には、書き込み対象となるディスクリプタを識別させる
ためのdescriptor indentifierが記述される。この記
述は、object positionで行われる。

【００８１】以下、subfunctionとして、partial_repla
ceであることを表す値、”５０₁₆”が記述される。これ
によりpartial insertまたは、partial delateが実行
される。insertでは、descriptor_identifierで指定さ
れるoperandにより規定される１つ前に新しいdescripti
orが挿入される。deleteではdescriptior_identifierに
より規定されるdescriptorが削除される。

【００８２】group_tagは、WRITE DESCRIPTORコマンド
が発行される必要があるdescriptior上において、分割
できない更新の処理を行うために利用される。この例に
おいては、データをdescriptorに迅速に書き込むことを
表す値”００₁₆”（immediate）が記述されている。rep
lacement_data_lengthは、replacement_dataのoperand
におけるバイト数、すなわち、書き込みたいデータの長
さを表している。addressは、処理が行われるべき位置
を表している。replacement_data_lengthの”０”は、p
artial deleteを意味し、その場合、replacement_data
のoperandは存在しない。この場合、original_data_len
gthは”０”より大きい値となり、それが削除されるべ
きバイトの数を表す。original_data_lengthが”０”で
ある場合、partial insert処理が行われる。この場
合、replacement_data_lengthは、”０”より大きい値
とされ、挿入されるべきバイトの数を表している。

【００８３】次にステップＳ２８に進み、コントローラ
１１は、リスト、すなわちRSB５１をクローズする。こ
の時コントローラ１１は、RSB５１に対して、図１７に
示すCLOSEコマンドを出力する。ただしこの場合におい
ても、コントローラ１１とRSB５１は、バス２を介して
接続されている訳ではないので、クローズ処理は直接的
に行われるが、コントローラ１１がDVCR３のRSB６１を
クローズする場合には、このCLOSEコマンドが出力され
る。

【００８４】図１７に示すCLOSEコマンドのフォーマッ
トは、基本的に図１０に示した、WRITE OPENコマンド
と同様のフォーマットであり、subfunctionが、図１０
においては、WRITE OPENを表す”０３₁₆”とされてい
るのに対して、図１７のCLOSEコマンドにおいては、CLO
SEであることを表す値、”００₁₆”とされている点が異
なっている。その他の構成は図１０における場合と同様
である。

【００８５】次にステップＳ２９に進み、コントローラ
１１は、予約に関連する他のリソースが存在するか否か
を判定する。今の場合、これまでの処理によりチューナ
サブユニット１２を予約するための処理が終了したの
で、まだ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 Un
ique ID）とされ、LSB側の８ビットは、その機器内で
設定される固有の値とされ、具体的には、record IDと
される。このようにObject IDをGUIDとrecord IDとで
構成することにより、Eventを識別するためのObject I
Dを設定すると、ID設定の処理が容易となる。

【００９０】すなわちこのObject IDは、バス２に接続
されている各機器の間において、識別可能である必要が
ある。そうでなければ、この例においては、１つのユニ
ット（機器）のRSBの内容を他のユニット（機器）が読
み込み可能であり、複数のユニットのサブユニットにお
いて、共同して（関連して）処理が実行されることがあ
るので、関連する処理があるか否かを、他のユニットが
識別できる必要があるからである。

【００９１】バス２に接続されている、ユニット間にお
いて、識別可能なものであれば、例えば、Object IDを
Eventが発生する毎に、番号１から順番に順次設定する
ようにすることも可能である。しかしながらそのように
すると、所定のユニットが、所定のEventに関して、Obj
ect 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 I
Dが一致しないと判定された場合、ステップＳ４４にお
いて、コントローラ１１は、関連するサブユニットに関
するRSB５１に公開されている全てのEventを抽出したか
否かを判定し、まだ抽出していないEventが残っている
場合はステップＳ４２に戻り、全ての Eventを読み出し
たと判定するまで、ステップＳ４２乃至Ｓ４４の処理を
繰り返す。全てのEventを読み出したと判定された場
合、ステップＳ４５において、コントローラ１１は、IR
D１の機器ID(GUID)に、ステップＳ４１で発生した仮ID
（record ID）を付加して、Object IDを生成し、RSB５
１等に記述する。

【００９５】このように、Object IDは、関連するサブ
ユニットに関するRSBをチェックするだけで（関連しな
いサブユニットを有するユニットのRSBをチェックする
ことなく）設定することができる。これは、上述したよ
うに、他のユニットのRSBにおけるObject IDは、その
ユニットのGUIDが含まれているため、他のユニットが設
定したObject IDは、自分自身が設定したObject IDと
一致することが有り得ないからである。したがって、Ob
ject IDを簡単に設定することが可能となる。

【００９６】次に、BBSの詳細について説明する。図２
０は、BBSを構成するSubunit identifier Descriptor
のフォーマットを表している。descriptor_lengthは、
このDescriptorの長さを表す。generation_IDは、このB
BSにおいて、どのAV/C descriptorフォーマットが使用
されるかを表し、通常”００₁₆”とされる。

【００９７】size_of_list_IDは、list IDのバイト数
を表す。size_of_object_IDは、このobject IDのバイ
ト数を表す。

【００９８】size_of_object_posionは、list内のobjec
tの位置が参照されるときに使用されるバイト数を表
す。number_of_root_object_listsは、このBBSが直接関
連するroot object listsの数を表す。

【００９９】root_object_list_id_x（ｘ＝０，１，
２，・・・ｎ−１）は、このBBSが関連するroot objec
t listsのそれぞれのIDを表す。subunit_dependent_in
formation_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）suppo
rted_board_type_specific_of_length［０］の他、supp
orted_board_type_specific_info［０］乃至supported_
board_type_specific_info［ｎ−１］と、それらの長さ
を表すsupported_board_type_specific_of_length
［０］乃至supported_board_type_specific_of_length
［ｎ−１］が含まれている。

【０１０１】さらに、BBSには、manufacturer_dependen
t_informatinの長さを表す、manufacturer_dependent_l
engthと製造者に依存する情報を含むmanufacturer_depe
ndent_informationが記述される。

【０１０２】root_object_list_idの値は、それがRSBを
表すものである場合、図２１に示すように、所定の値”
１００１₁₆”とされる。このように、RSB（図２１ではR
esource Schedule Listと記述されている）を表すID
を、所定の値に固定しておくことにより、RSBを読み出
す処理が容易となる。

【０１０３】図２２は、RSBのフォーマットを表してい
る。descriptor_lengthはRSBの長さを表す。list_type
には、RSBがRead Onlyであるのか、またはWrite Enab
ledであるのかが記述される。Read Only listは、読
み出しのみが可能とされ、Write Enabled listには、
書き込みが可能とされる。

【０１０４】size_list_specific_informationは、list
_specific_informationの長さを表し、list_specific_i
nformationは、list_typeによって異なるものとなる。W
rite Enabled list_specific_infomationの場合、図
２３により詳細に示す情報が記述される。

【０１０５】non_info_block_fileds_lengthは、non i
nfo block fieldsのバイト数を表す。board_typeは、
図２４に示すように、Resource Schedule Boardの場
合、”０１₁₆”とされる。

【０１０６】object_list_maximum_sizeは、object li
stの最大の大きさを表す。object_entry_maximum_numbe
rは、listにおけるobject entriesの最大の数を表す。
object_entry_maximum_sizeは、object entryの最大の
大きさを表す。以上のobject_list_maximum_size，obje
ct_entries_maximum_number，object_entry_maximum_si
zeは、それぞれ制限が設けられていない場合には、”０
０００₁₆”とされる。

【０１０７】これらの３つのフィールドは、コントロー
ラがobject listまたは、objectentryの容量を知る上
において、有意義である。

【０１０８】board_type_dependent_information_lengt
hは、board_type_dependent_informationの長さを表
し、board_type_dependent_informationは、board typ
eに固有の情報を表す。

【０１０９】object_entryは、より詳細には、図２５に
示すように構成される。descriptor_lengthは、このdes
criptorの長さを表し、entry_typeは、Board entry D
escriptorの場合、Board を表す値”８０₁₆”とされ
る。

【０１１０】object_IDは、posting_device_GUIDとreco
rd_IDとにより構成される。posting_deviceは、BBSに対
して情報を記入（post）したコントローラを意味し、従
ってposting_device_GUIDは、そのGUIDを表す。record_
IDは、ユニット内においてEventに対して割当てられたI
Dを表す。

【０１１１】size_of_entry_specific_imformationは、
entry_specific_imformationの大きさを表す。

【０１１２】図２６は、entry_specific_imformationの
フォーマットを表している。non_info_block_length
は、repeat_informationまでのnon-info block field
sのバイト数を表す。start_timeは、詳細には、図２７
に示すように、eventが開始する年月日時分秒を表す。
年は、１６ビットで、４つの数字がそれぞれ４ビットの
BCDで表される。月は、８ビットで、２つの数字がそれ
ぞれ４ビットのBCDで表される。日は、８ビットで、２
つの数字がそれぞれ４ビットのBCDで表される。時間
は、８ビットで、２つの数字が、それぞれ４ビットのBC
Dで表される。分は、８ビットで、２つの数字がそれぞ
れ４ビットのBCDで表される。秒は、８ビットで、２つ
の数字が、それぞれ４ビットのBCDで表される。

【０１１３】このようにBCDで表すことにより、識別が
容易となる。またこの時刻は、ローカルタイムで表され
る。

【０１１４】eventの長さを表すDurationは、詳細には
図２８に示すように、時分秒で表される。時間は、３つ
の数字がそれぞれ４ビットのBCDで表され、合計１２ビ
ットとされる。分は，２つの数字がそれぞれ４ビットの
BCDとされ、合計８ビットで表される。秒は２つの数字
がそれぞれ４ビットのBCDで表され、合計８ビットとさ
れる。

【０１１５】start_timeにDurationを加算することで、
evntの終了時刻が表される。終了時刻を直接的に表現せ
ずに、Durationとしてeventの長さを表すようにするこ
とで、eventのstart_timeが変更されたような場合にお
いても、その終了時刻は変更する必要がなくなり、変更
処理が容易となる。

【０１１６】repeat_information_lengthは、repeat_in
formationの長さを表している。 repeat_information
は、いつどのようにしてscheduleが繰り返されるかを表
す。Scheduled Actionが繰り返されない場合、repeat_
infomation_lengthは、”００ ₁₆”とされる。

【０１１７】repeat_informationは、選択されたrepeat
typeによって内容が異なる。repeat typeには、図２
９に示すように、Weekly schedule”００₁₆”と、Inte
rvalschedule”１０₁₆”とがある。

【０１１８】scheduleが、週毎に繰り返される場合、Po
sting Deviceは、その曜日および繰り返されるべきeve
ntの数を図３０に示すように表示する。

【０１１９】repeat_typeには、図２９に示す値、”０
０₁₆”が記述される。number_of_eventsには、eventの
数が記述される。日曜日から土曜日までのWeekly flag
sは、繰り返されるeventが開始する週の日を表す。例え
ば、１３時００分から３時間のeventが、毎週月曜日と
水曜日に開始される場合、月曜日と水曜日のフラグに”
１”が設定され、その他のフラグには”０”が設定され
る。

【０１２０】このように週毎に繰り返されるeventが記
録できるので、例えば月曜日と水曜日の絶対的な日時を
放送日に対応する分だけ記憶させるような場合に比べ
て、記憶容量は小さくて済ませることが可能ととなる。

【０１２１】Posting Deviceは、Scheduled Actionが
所定のintervalsで繰り返される場合、図３１に示すよ
うなフォーマットでeventを記述する。

【０１２２】repeat_typeには、この例の場合、図２９
に示す値”１０₁₆”が記述される。number_of_eventsに
は、eventの数が記述される。

【０１２３】interval（間隔）は、現在のeventのstart
_timeから次のeventのstart_timeまでの間隔を表す。こ
の間隔は、時分秒で表される。時間は、３つの数字がそ
れぞれ４ビットのBCDで表され、合計１２ビットで表現
される。分と秒は、それぞれ２つの数字が４ビットのBC
Dとされ、合計８ビットで表現される。

【０１２４】このように周期的に繰り返されるeventが
記憶できるので、それぞれが開始される絶対時刻（日
時）を別に記憶させる場合に比べて、記憶容量が少なく
て済む。

【０１２５】図２６に示すように、info blocksは図３
２に示すようなフォーマットとされる。conpound_lengt
hは、info blockのバイト長を表す。ただしlengthフィ
ールド自身は、この長さに含まれていない。info_block
_typeは”８９００₁₆”にセットされる。primary_field
s_lengthは、number_of_subunitsとsubunit_type_and_I
D fieldのバイト数を表す。

【０１２６】number_of_subunitsは、posting Device
が使用するsubunitsの数を表す。 subunit_type_and_I
Dは、posting Deviceが使用するsubunitsを指定する。

【０１２７】このようにstart_timeとDurationが固定の
アドレスにおける固定の長さで表される。それに対し
て、subunitと、それを使用するPosting Deviceを識別
する識別情報は、Info blocksとして、start_time，Du
rationなどより後の所定のアドレスに記憶される。これ
によりPosting Deviceの数が増加としても、対応が容
易となる。

【０１２８】図２０のsupported_board_type_specific_
informationフィールドは、図３３に示すようなフォー
マットとされる。supported_board_typeには、図２４に
示すRSBであることを表す値”０１₁₆”が記述される。s
upported_board_type_versionは、bulletin Bond Typ
e Specificationのバージョンの番号を表す。inplemen
tation_profile_IDはこのboard typeのためのprofile
IDバージョンを表す。

【０１２９】supported_board_type_dependend_informa
tion_lengthは、supported_type_dependent_informatio
nのバイト数を表す。supported_board_type_dependent_
informationには、各board type specificationに固
有の情報が記述される。

【０１３０】上述した一連の処理は、ハードウエアによ
り実行させることもできるが、ソフトウエアにより実行
させることもできる。一連の処理をソフトウエアにより
実行させる場合には、そのソフトウエアを構成するプロ
グラムが、専用のハードウエアとしてのコントローラに
組み込まれているコンピュータ、または、各種のプログ
ラムをインストールすることで、各種の機能を実行する
ことが可能な、例えば汎用のパーソナルコンピュータな
どにインストールされる。

【０１３１】汎用のパーソナルコンピュータ１０１は、
例えば、図３４に示すように、CPU（Central Processi
ng Unit）１１１を内蔵している。CPU１１１には、バ
ス１１５を介して入出力インターフェース１１６が接続
されており、CPU１１１は、入出力インターフェース１
１６を介して、ユーザから、キーボード、マウスなどよ
りなる入力部１１８から指令が入力されると、それに対
応して、ROM（Read Only Memory）１１２あるいはハ
ードディスク１１４などの記録媒体、または、ドライブ
１２０に装着された磁気ディスク１３１，光ディスク１
３２、光磁気ディスク１３３などの記録媒体から、それ
らに記録されている、上述した一連の処理を実行するプ
ログラムを読み出し、RAM(Ramdom Access Memory)１
１３にインストールし、実行する。なお、ハードディス
ク１１４に格納されているプログラムには、予め格納さ
れてユーザに配布されるものだけでなく、衛星もしく
は、ネットワークから転送され、通信部１１９により受
信され、インストールされたプログラムも含まれる。

【０１３２】また、CPU１１１は、プログラムの処理結
果のうち、画像信号を、入出力インターフェース１１６
を介して、LCD（Liquid Crystal Display），CRT（Ca
thode 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_in
formationのフォーマットを説明する図である。

【図２４】図２３のboard_typeのフォーマットを説明す
る図である。

【図２５】図２２のobject_entryのフォーマットを説明
する図である。

【図２６】図２５のResource Schedule Entryのフォ
ーマットを説明する図である。

【図２７】図２６のstart_timeのフォーマットを説明す
る図である。

【図２８】図２６のDurationのフォーマットを説明する
図である。

【図２９】図３０のrepeat_typeのフォーマットを説明
する図である。

【図３０】図２６のrepeat_informationのフォーマット
を説明する図である。

【図３１】図２６のrepeat_informationのフォーマット
を説明する図である。

【図３２】図２６のInfo blocksのフォーマットを説明
する図である。

【図３３】図２０のsupported_board_type_specific_in
formationのフォーマットを説明する図である。

【図３４】コンピュータの構成例を示すブロック図であ
る。

【符号の説明】

１ IRD， ２ IEEE1394シリアルデータバス， ３ D
VCR， １１ コントローラ， １２ チューナサブユ
ニット， １４ ＢＢＳ， ３１ コントローラ， ３
２ アナログチューナブロック， ３３ VCRサブユニ
ット， ３４ BBS， ５１ RSB， ５２ SAB， ６
１ RSB， ６２ SAB

Claims (20)

【特許請求の範囲】
1. 【請求項１】 ネットワークを介して他の情報処理装置
   と接続されるとともに、所定の機能を実行する１以上の
   サブユニットを有する情報処理装置において、 前記サブユニットの予約に関する予約情報を入力する入
   力手段と、 前記サブユニットの予約に関する前記予約情報を記憶す
   る記憶手段と、 前記他の情報処理装置から要求があった場合、前記記憶
   手段に記憶されている前記予約情報を読み出して、前記
   他の情報処理装置に供給する供給手段とを備えることを
   特徴とする情報処理装置。
2. 【請求項２】 自己の前記サブユニットと、前記他の情
   報処理装置のサブユニットの両方を同時刻に関連して使
   用するために予約する場合、自己の前記サブユニットの
   前記予約情報を前記記憶手段に書き込むとともに、前記
   他の情報処理装置のサブユニットの予約情報を、前記他
   の情報処理装置の前記記憶手段に書き込む書き込み手段
   をさらに備えることを特徴とする請求項１に記載の情報
   処理装置。
3. 【請求項３】 自己の前記記憶手段に記憶されている前
   記予約情報と、関連して同時刻に使用される前記サブユ
   ニットを有する前記他の情報処理装置の前記記憶手段に
   記憶されている前記予約情報を、前記入力手段より入力
   された前記予約情報と比較する比較手段をさらに備え、 前記書き込み手段は、前記比較手段の比較結果に対応し
   て、前記予約情報の書き込みを行うことを特徴とする請
   求項２に記載の情報処理装置。
4. 【請求項４】 前記書き込み手段は、自己の前記記憶手
   段に書き込みを行う場合、前記他の情報処理装置からの
   前記予約情報の自己の前記記憶手段への書き込みを制限
   することを特徴とする請求項２に記載の情報処理装置。
5. 【請求項５】 前記書き込み手段は、自己の前記記憶手
   段に書き込みを行う場合、前記他の情報処理装置からの
   前記予約情報の自己の前記記憶手段からの読み出しが行
   われているとき、その読み出しを中止させることを特徴
   とする請求項４に記載の情報処理装置。
6. 【請求項６】 前記記憶手段は、そこに記憶される前記
   予約情報の制限に関する制限情報も記憶し、 前記供給手段は、前記他の情報処理装置から要求があっ
   た場合、前記制限情報も前記他の情報処理装置に供給す
   ることを特徴とする請求項１に記載の情報処理装置。
7. 【請求項７】 前記記憶手段は、予め定められた特定の
   アドレス位置に、前記予約情報を記憶することを特徴と
   する請求項１に記載の情報処理装置。
8. 【請求項８】 前記予約情報は、前記サブユニットの使
   用を開始する開始時刻と、前記サブユニットを使用する
   使用時間を含むことを特徴とする請求項１に記載の情報
   処理装置。
9. 【請求項９】 前記使用時間は、不定として設定可能で
   あることを特徴とする請求項８に記載の情報処理装置。
10. 【請求項１０】 前記予約情報は、前記サブユニットを
    予約する情報処理装置に関する装置情報を含み、前記装
    置情報は、前記開始時刻および使用時間より後のアドレ
    ス位置に記憶されることを特徴とする請求項８に記載の
    情報処理装置。
11. 【請求項１１】 前記開始時刻は、BCDで表されること
    を特徴とする請求項８に記載の情報処理装置。
12. 【請求項１２】 前記記憶手段は、記憶された前記予約
    情報を識別する識別情報をさらに記憶することを特徴と
    する請求項１に記載の情報処理装置。
13. 【請求項１３】 前記識別情報は、前記サブユニットを
    予約した情報処理装置に固有な値と、前記情報処理装置
    内で設定された前記予約に固有な値とを含むことを特徴
    とする請求項１２に記載の情報処理装置。
14. 【請求項１４】 前記サブユニットを予約した情報処理
    装置に固有な値は、グローバルユニークIDであり、前記
    情報処理装置内で設定された予約に固有な値は、レコー
    ドIDであることを特徴とする請求項１３に記載の情報処
    理装置。
15. 【請求項１５】 前記予約情報は、前記サブユニット
    を、曜日を指定して毎週繰り返し予約する週間予約情報
    を含むことを特徴とする請求項１に記載の情報処理装
    置。
16. 【請求項１６】 前記予約情報は、前記サブユニット
    を、所定の間隔で繰り返し予約する間隔予約情報を含む
    ことを特徴とする請求項１に記載の情報処理装置。
17. 【請求項１７】 前記記憶手段は、前記サブユニットの
    １つであることを特徴とする請求項１に記載の情報処理
    装置。
18. 【請求項１８】 前記ネットワークは、IEEE1394シリア
    ルデータバスを用いて構成されることを特徴とする請求
    項１に記載の情報処理装置。
19. 【請求項１９】 ネットワークを介して他の情報処理装
    置と接続されるとともに、所定の機能を実行する１以上
    のサブユニットを有する情報処理装置の情報処理方法に
    おいて、 前記サブユニットの予約に関する予約情報を入力する入
    力ステップと、 前記サブユニットの予約に関する前記予約情報の記憶を
    制御する記憶制御ステップと、 前記他の情報処理装置から要求があった場合、前記記憶
    ステップの処理により記憶された前記予約情報を読み出
    して、前記他の情報処理装置に供給する供給ステップと
    を含むことを特徴とする情報処理方法。
20. 【請求項２０】 ネットワークを介して他の情報処理装
    置と接続されるとともに、所定の機能を実行する１以上
    のサブユニットを有する情報処理装置を制御するプログ
    ラムにおいて、 前記サブユニットの予約に関する予約情報を入力する入
    力ステップと、 前記サブユニットの予約に関する前記予約情報の記憶を
    制御する記憶制御ステップと、 前記他の情報処理装置から要求があった場合、前記記憶
    制御ステップの処理により記憶された前記予約情報を読
    み出して、前記他の情報処理装置に供給する供給ステッ
    プとを含むことを特徴とするコンピュータが実行可能な
    プログラムが記録されている記録媒体。