JP4186332B2 - 情報処理装置および方法、並びに記録媒体 - Google Patents
情報処理装置および方法、並びに記録媒体 Download PDFInfo
- Publication number
- JP4186332B2 JP4186332B2 JP25110399A JP25110399A JP4186332B2 JP 4186332 B2 JP4186332 B2 JP 4186332B2 JP 25110399 A JP25110399 A JP 25110399A JP 25110399 A JP25110399 A JP 25110399A JP 4186332 B2 JP4186332 B2 JP 4186332B2
- Authority
- JP
- Japan
- Prior art keywords
- reservation
- subunit
- information
- information processing
- processing apparatus
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、並びに記録媒体に関し、特に、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
【発明の属する技術分野】
本発明は、情報処理装置および方法、並びに記録媒体に関し、特に、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
Claims (4)
- ユニットとしての情報処理装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される他の情報処理装置が有する機能ブロックである他のサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記情報処理装置自身の固有の 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 で前記仮番号を書き換えることが行われる
記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP25110399A JP4186332B2 (ja) | 1998-09-14 | 1999-09-06 | 情報処理装置および方法、並びに記録媒体 |
Applications Claiming Priority (7)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP25973598 | 1998-09-14 | ||
| JP10-259735 | 1998-09-14 | ||
| JP10-296502 | 1998-10-19 | ||
| JP29650298 | 1998-10-19 | ||
| JP5365699 | 1999-03-02 | ||
| JP11-53656 | 1999-03-02 | ||
| JP25110399A JP4186332B2 (ja) | 1998-09-14 | 1999-09-06 | 情報処理装置および方法、並びに記録媒体 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2000316133A JP2000316133A (ja) | 2000-11-14 |
| JP2000316133A5 JP2000316133A5 (ja) | 2006-04-20 |
| JP4186332B2 true JP4186332B2 (ja) | 2008-11-26 |
Family
ID=27462943
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP25110399A Expired - Fee Related JP4186332B2 (ja) | 1998-09-14 | 1999-09-06 | 情報処理装置および方法、並びに記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4186332B2 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20080134270A1 (en) * | 2004-10-20 | 2008-06-05 | Kazutomo Watanabe | Programming Management System, Programming Management Apparatus, Programming Management Method, and Programming Management Program |
| EP2051522B1 (en) * | 2006-11-02 | 2019-06-26 | Panasonic Corporation | Broadcast-program recording-programming system |
-
1999
- 1999-09-06 JP JP25110399A patent/JP4186332B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000316133A (ja) | 2000-11-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7631334B2 (en) | Information processing device, information processing method and medium | |
| US7224886B2 (en) | Method of using AV devices and AV device system | |
| US6513064B1 (en) | Information processing apparatus, information processing method, and recording medium | |
| JP2002525732A (ja) | 通信方法及び通信システム | |
| US20010002846A1 (en) | Electronic device for managing removable storage medium, method and storage medium therefor | |
| EP0801488B1 (en) | Information transfer method and apparatus | |
| JP4323114B2 (ja) | ピアトゥピア配信ネットワーク環境におけるリソーススケジュールの管理方法及び装置 | |
| JPH11177919A (ja) | Ａｖ機器、機器使用方法及びａｖ機器システム | |
| JP4186332B2 (ja) | 情報処理装置および方法、並びに記録媒体 | |
| KR100575012B1 (ko) | 정보 처리 장치 및 방법, 및 기록 매체 | |
| EP1056242B1 (en) | Information processing apparatus and method, and recording medium | |
| JP4251248B2 (ja) | 受信装置、情報処理方法、並びに記録媒体 | |
| EP1093319A1 (en) | Network control system and method therefor | |
| US20020184573A1 (en) | Method and device for configuring a functional unit with a temporary character in a communication network | |
| JP3943677B2 (ja) | タイマ管理を行なう機器及び機器システム | |
| JPH10269754A (ja) | 電子機器および電子機器制御方法、情報提供装置および方法、並びに情報提供システム | |
| EP0987891A2 (en) | Timer-controlled information processing method and apparatus | |
| MXPA99008383A (en) | Information processing device, information processing method, and media de regis | |
| MXPA99008384A (en) | Information processing device, information processing method, and media de regis | |
| EP1102170A1 (en) | Information processing device and method, and information processing system | |
| JP2004336464A (ja) | Ｔｖ番組録画再生装置 | |
| JP2000187934A (ja) | 情報処理装置および方法、並びに媒体 | |
| JP2000358048A (ja) | 情報処理装置および方法、並びに記録媒体 | |
| MXPA99008385A (en) | Timer-controlled information processing method and apparatus | |
| JPH10269757A (ja) | 電子機器、電子機器制御方法、電子機器制御装置、並びに電子機器制御システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060307 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060307 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080529 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080723 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080819 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080901 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110919 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110919 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120919 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120919 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130919 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |