JP4251248B2

JP4251248B2 - Reception device, information processing method, and recording medium

Info

Publication number: JP4251248B2
Application number: JP24963699A
Authority: JP
Inventors: 麻里堀口; 晴美川村; 和夫山本
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1998-09-14
Filing date: 1999-09-03
Publication date: 2009-04-08
Anticipated expiration: 2019-09-03
Also published as: JP2000196632A

Description

【０００１】
【発明の属する技術分野】
本発明は、情報処理装置および方法、並びに記録媒体に関し、特に、IEEE１３９４シリアルデータバスを介して他の情報処理装置と接続された情報処理装置において、内蔵するサブユニットを重複することなく、確実に制御することができるようにした情報処理装置および方法、並びに記録媒体に関する。
【０００２】
【従来の技術】
IEEE１３９４シリアルデータバスを用いたネットワークを介して、相互に情報を伝達することができるAV機器が開発されている。このネットワークにおいては、所定のコマンド(AV/C Command Transaction Set)を用いることにより、ネットワークに接続されているAV機器を制御することが可能である。例えば、図１に示すように、デジタル衛星放送を受信するIRD(Integrated Receiver Decoder)７１で受信した映像を、IEEE１３９４シリアルデータバス２（以下、バス２と記述する）を介して接続されている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機器が管理する予約情報等を入手できないことに起因している。
【０００７】
上述した不都合を解決するため、従来においては、DVCR８１に、IRD７１のコントローラ７２による制御だけに従い、録画待機状態となるCSモードというモードが設けられており、IRD７１に録画予約Ａを入力した後、DVCR８１をCSモードに設定することでダブルブッキングの発生を防止していた。
【０００８】
【発明が解決しようとする課題】
しかしながら、CSモードに設定されたDVCR８１は、予約待機状態となってしまうので、例えば、映像信号の再生等の処理を実行できず、操作性が悪い課題があった。
【０００９】
また、バス２に伝送される録画予約等のイベント（event）を一意に特定する方法がないため、例えば、イベントを修正する場合、そのイベントに関連するAV機器毎に個別にコマンドを発生する必要があり、操作性が悪い課題があった。
【００１０】
さらに、複数のAV機器が、他のAV機器が管理する情報（録画開始時刻等）を知らないことに起因して、同時にバス２に情報を出力した場合、出力された情報量がバス２の帯域を越えて、伝送エラーが発生する可能性がある課題があった。
【００１１】
本発明はこのような状況に鑑みてなされたものであり、バスに接続されている各AV機器が、管理している情報を相互に検索することにより、録画予約時の操作性を向上させるとともに、ダブルブッキングの発生を抑止することができるようにするものである。
【００１８】
【課題を解決するための手段】
本発明の受信装置は、ユニットとしての受信装置自身が有する機能ブロックであるチューナサブユニットと、ネットワークを介して接続される記録装置が有する機能ブロックであるVCRサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記受信装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定する設定手段と、前記設定手段により設定された前記オブジェクトIDとともに、前記チューナサブユニットの予約に関する情報を記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開する第１の記憶手段と、前記チューナサブユニットと前記VCRサブユニットを関連させた一連の動作を制御するための情報を記憶する第２の記憶手段と、前記記録装置が有する、前記VCRサブユニットの予約に関する情報を記憶する記憶手段に、前記設定手段により設定された前記オブジェクトIDとともに、前記VCRサブユニットの予約に関する情報を記憶させる制御手段とを備え、前記記録装置においては、前記VCRサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。また、前記一連の動作として、前記チューナサブユニットは、アンテナから入力された信号から所定のチャンネルの信号を抽出して前記ネットワークを介して前記VCRサブユニットに供給し、前記VCRサブユニットは、前記チューナサブユニットから供給された信号を記録媒体に記録させる。
【００２０】
前記ネットワークは、IEEE１３９４シリアルデータバスを用いて構成することができる。
【００２２】
本発明の情報処理方法は、ユニットとしての受信装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される記録装置が有する機能ブロックであるVCRサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記受信装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、前記サブユニットと前記VCRサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、前記記録装置が有する、前記VCRサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記VCRサブユニットの予約に関する情報を記憶させるステップを含み、前記記録装置においては、前記VCRサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。また、前記一連の動作として、前記チューナサブユニットにより、アンテナから入力された信号から所定のチャンネルの信号が抽出されて前記ネットワークを介して前記VCRサブユニットに供給され、前記VCRサブユニットにより、前記チューナサブユニットから供給された信号が記録媒体に記録される。
【００２３】
本発明の記録媒体のプログラムは、ユニットとしての受信装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される記録装置が有する機能ブロックであるVCRサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記受信装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDを設定し、設定した前記オブジェクトIDとともに、前記サブユニットの予約に関する情報を第１の記憶手段に記憶し、記憶している情報を、前記ネットワークを介して接続される装置からの要求に対応して公開し、前記サブユニットと前記VCRサブユニットを関連させた一連の動作を制御するための情報を第２の記憶手段に記憶し、前記記録装置が有する、前記VCRサブユニットの予約に関する情報を記憶する記憶手段に、設定した前記オブジェクトIDとともに、前記VCRサブユニットの予約に関する情報を記憶させるステップを含む処理をコンピュータに実行させる。前記記録装置においては、前記VCRサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後、前記固有のIDで前記仮番号を書き換えることが行われる。また、前記一連の動作として、前記チューナサブユニットにより、アンテナから入力された信号から所定のチャンネルの信号が抽出されて前記ネットワークを介して前記VCRサブユニットに供給され、前記VCRサブユニットにより、前記チューナサブユニットから供給された信号が記録媒体に記録される。
【００２４】
本発明においては、ユニットとしての受信装置自身が有する機能ブロックであるサブユニットと、ネットワークを介して接続される記録装置が有する機能ブロックであるVCRサブユニットとを関連して動作させることの予約が設定された場合、設定された予約に対して、前記受信装置自身の固有のIDと、自分自身の内部で競合しないIDとからなるオブジェクトIDが設定され、設定された前記オブジェクトIDとともに、前記サブユニットの予約に関する情報が第１の記憶手段に記憶され、記憶されている情報が、前記ネットワークを介して接続される装置からの要求に対応して公開される。また、前記サブユニットと前記VCRサブユニットを関連させた一連の動作を制御するための情報が第２の記憶手段に記憶され、前記記録装置が有する、前記VCRサブユニットの予約に関する情報を記憶する記憶手段に、設定された前記オブジェクトIDとともに、前記VCRサブユニットの予約に関する情報を記憶させることが行われる。前記記録装置においては、前記VCRサブユニットの予約に関する情報を記憶させるとき、前記オブジェクトIDのうちの前記固有のIDの部分を一時的な仮番号として予約に関する情報を記憶させた後前記固有のIDで前記仮番号を書き換えることが行われる。また、前記一連の動作として、前記チューナサブユニットにより、アンテナから入力された信号から所定のチャンネルの信号が抽出されて前記ネットワークを介して前記VCRサブユニットに供給され、前記VCRサブユニットにより、前記チューナサブユニットから供給された信号が記録媒体に記録される。
【００３８】
【発明の実施の形態】
本発明を適用したネットワークシステムの構成例について、図２を参照して説明する。なお、本明細書においてシステムの用語は、複数の装置、手段などにより構成される全体的な装置を意味するものである。
【００３９】
このネットワークシステムは、バス２を介して接続されているIRD１およびDVCR３から構成されている。当然、このバス２にはIRD１およびDVCR３以外に、例えば、パーソナルコンピュータ、ハードディスクドライブ、CDプレーヤ、モニタ、デジタルビデオカメラ、またはMD（商標）プレーヤ等のIEEE１３９４端子を備える電子機器を接続することが可能である。
【００４０】
なお、バス２に接続されている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であることを表す値（０８₁₆）が記述される。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と、list_specific_information field（図２６）を読み出す。この読み出しは、例えば図１１に示すREADコマンドを利用して行われる。但しこの場合においても、コントローラ１１とRSB５１は、バス２を介して接続されている訳ではないので、コントローラ１１からRSB５１に対する読み出しは、直接的に行われる。ただし、コントローラ１１がDVCR３のRSB６１からデータを読み出す場合には、図１１に示すようなREADコマンドが、バス２を介して、RSB６１（コントローラ３１）に出力される。
【００６１】
図１１に示すように、READコマンドの先頭のopcodeとしては、read descriptorであることを表す値、０９₁₆が記述されている。続くoperand０には、読み出すdescriptorを識別するためのdescriptor identifierが、記述される。このステップＳ１３における読み出しの処理の場合は、リストIDでdescriptor identifierが記述される。具体的には後述する図２７のRSBのwrite enabled list_specific_information fieldのAddress_offsetの００₁₆乃至０Ｄ₁₆が記述される。
【００６２】
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であることを表す値０Ａ₁₆が記述される。operand０には、書き込み対象となるディスクリプタを識別させるためのdescriptor indentifierが記述される。この記述は、object positionで行われる。
【００８７】
以下、subfunctionとして、partial_replaceであることを表す値、５０₁₆が記述される。これによりpartial insertまたは、partial delateが実行される。insertでは、descriptor_identifierで指定されるoperandにより規定される１つ前に新しいdescriptiorが挿入される。deleteではdescriptior_identifierにより規定されるdescriptorが削除される。
【００８８】
group_tagは、WRITE DESCRIPTORコマンドが発行される必要があるdescriptior上において、分割できない更新の処理を行うために利用される。この例においては、データをdescriptorに迅速に書き込むことを表す値００₁₆（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を表す”０３₁₆”とされているのに対して、図１７のCLOSEコマンドにおいては、CLOSEであることを表す値、”００₁₆”とされている点が異なっている。その他の構成は図１０における場合と同様である。
【００９１】
次にステップＳ２９に進み、コントローラ１１は、予約に関連する他のリソースが存在するか否かを判定する。今の場合、これまでの処理によりチューナサブユニット１２を予約するための処理が終了したので、まだ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６１に記憶される。
【００９４】
このように、各ユニットにおいて、独立に予約を行う場合においても、図７乃至図９のフローチャートに示した場合と同様の処理により、予約処理を行うことができる。ただし、このように、サブユニットを共同して使用する場合において、それぞれの予約を独立して行うと、ダブルブッキングが発生するか否かは、ユーザが管理する必要がある。
【００９５】
また、図１９に示すように、IRD１が、BBS１４を有しない場合においても、本発明は適用が可能である。この場合、例えば、IRD１のコントローラ１１から、１０月１６日、２０時００分から２１時００分まで、DVCR３のVCRサブユニット３３を予約することが入力されると、この予約が、バス２を介して、DVCR３のBBS３４のRSB６１に書き込まれる。
【００９６】
次に、Object ID設定処理について、図２０のフローチャートを参照して説明する。この処理は、ユーザがIRD１に対して、DVCR３を用いる録画予約の操作を入力し、その操作がコントローラ１１に検知され、上述した図７乃至図９の予約処理（競合ユニット検索処理）が実行されて、その録画予約が認められた後、開始される。この例においては、所定の時刻から所定の時間の間、実行される予約処理（Event）に関し、それを識別するために、Object IDが対応される。このObject IDは、７２ビットで構成され、そのうちのMSB側の６４ビットは、その予約に関する全ての情報を持っている機器の固有のID、具体的にはその機器のGUID（Global Unique ID）とされ、例えば、IEEE EUI−６４が用いられる。LSB側の８ビットは、その機器内で設定される固有の値とされ、具体的には、record IDとされる。このようにObject IDをGUIDとrecord IDとで構成することにより、固有なID設定の処理が容易となるとともに、書き込んだオーナを特定できる有益な情報を含ませることができる。
【００９７】
すなわちこのObject IDは、バス２に接続されている各機器の間において、識別可能である必要がある。そうでなければ、この例においては、１つのユニット（機器）のRSBの内容を他のユニット（機器）が読み込み可能であり、複数のユニットのサブユニットにおいて、共同して（関連して）処理が実行されることがあるので、関連する処理があるか否かを、他のユニットが識別できる必要があるからである。
【００９８】
ステップＳ４１において、コントローラ１１は、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を簡単に設定することが可能となる。
【０１０２】
なお、Object IDの代わりに、バス２内において固有の所定のID（以下、このIDを、SA Event IDとする）を利用することも可能である。図２１は、この場合の処理を表している。この処理は、ユーザがIRD１に対して、DVCR３を用いる録画予約の操作を入力し、その操作がコントローラ１１に検知され、図７乃至図９の予約（競合ユニット検索）処理が実行されて、その録画予約が認められた後、開始される。
【０１０３】
ステップＳ５１において、コントローラ１１は、バス２内において、その予約情報を一意に識別できる仮IDを発生する。ステップＳ５２において、コントローラ１１は、バス２内の１つのユニット（または、予約動作上関連するユニット）のRSB５１に記憶されているEventを読み出して、その中のSA Event IDを抽出する。ステップＳ５３において、コントローラ１１は、ステップＳ５１で発生した仮IDと、ステップＳ５２で抽出したSA Event IDが一致するか否かを判定し、一致しないと判定するまで、ステップＳ５１乃至Ｓ５３の処理を繰り返す。
【０１０４】
ステップＳ５１で発生した仮IDとステップＳ５２で抽出したSA Event IDが一致しないと判定された場合、ステップＳ５４において、コントローラ１１は、バス２内のユニット（または関連するユニット）の全てのSA Eventを読み出したか否かを判定し、全てのSA Eventを読み出したと判定するまで、ステップＳ５２乃至Ｓ５４の処理を繰り返す。全てのSA Eventを読み出したと判定された場合、ステップＳ５５において、コントローラ１１は、ステップＳ５１で発生した仮IDを、SA Event IDとして、RSB５１に記録する。
【０１０５】
図２１に示す処理の場合、バス２に接続されている全てのユニットが有するRSBをチェックする必要がある。これに対して、図２０に示す処理の場合、自分自身と関連するユニットのRSBだけをチェックすればよいので、処理を迅速に完了させることができる。
【０１０６】
以上のように、Object IDをRSBに記憶させておく他、SABにも記憶させるようにすることができる。これにより、ダブルブッキングが発生する場合、それを容易に確認することが可能となる。例えば、図２２に示すように、バス２にIRD１とDVCR３が接続されているとともに、IRD９１が接続されているものとする。IRD１は、BBS１４にRSB５１とSAB５２を有する他、SID（Subunit Identifier Descriptor）１００を有している。このSID１００には、このSID１００が所属するBBS１４内にどのようなボードタイプ（この例の場合、RSB５１とSAB５２）がサポートされているかを認知する情報が記憶されている。
【０１０７】
DVCR３のBBS３４には、RSB６１以外に、SID８１が設けられている。また、IRD９１は、コントローラ９２と表示部９３を有している。
【０１０８】
次に、図２２のシステムにおける処理例について説明する。ユーザは、IRD１のコントローラ１１に予約情報を入力する。図２２の例においては、８月１２日２０時００分から２１時００分までＸチャンネルを選局し、選曲された番組のデータをDVCR３に記録するという予約内容が入力される。コントローラ１１は、この予約内容を内蔵するメモリに書き込むとともに、自分自身のBBS１４のRSB５１とSAB５２にその予約情報を書き込むとともに、ターゲットとしてのDVCR３のBBS３４のRSB６１にも使用予定を書き込む。この時、コントローラ１１は、RSB５１，SAB５２，RSB６１の各エントリに記憶するObject IDを同一の値に設定しておく。
【０１０９】
このような場合において、IRD９１が、IRD１が予約した時刻と重複する時刻にDVCR３を予約しようとした場合における処理例について図２３のフローチャートを参照して説明する。
【０１１０】
ステップＳ６１において、IRD９１のコントローラ９２は、ターゲットとしてのDVCR３のRSB６１をチェックし、使用したい時間帯に重なって他のコントローラの予定が記録されているか否かを判定する。重複する時間帯に予定が書き込まれていない場合には、ステップＳ６５に進み、コントローラ９２は、上述した場合と同様に予約処理を実行する。すなわちコントローラ９２は、DVCR３のRSB６１に使用時間帯を書き込む。
【０１１１】
ステップＳ６１において、DVCR３のVCRサブユニット３３がすでに他のコントローラにより重なる時間帯に予約されていると判定された場合、ステップＳ６２に進み、コントローラ９２は、その予約に使用されているエントリのObject IDを読み出し、その上位８バイト（６４ビット）のGUIDから、そのエントリを書き込んだ機器のノードIDを割り出す。すなわちGUIDは、各機器に固有のものであり、ノードIDと異なり、バスリセット毎に変化するものではない。したがって、コントローラ９２は、バス２に接続されている各機器のGUIDとノードIDを調べ、その対応表を予め作成しておく。そしてその対応表を参照することで、GUIDからノードIDを割り出すことが可能となる。
【０１１２】
次にステップＳ６３に進み、コントローラ９２は、ステップＳ６２の処理で割り出した機器のSABから（今の場合、IRD１のSAB５２から）、多重予約エントリと同一のObject IDを指定し、そのエントリの内容を読み出す。そしてステップＳ６４において、コントローラ９２は、ステップＳ６３の処理で読み出した重複予約の内容を表示部９３に出力し、表示させる。これにより、IRD９１のユーザは、先に予約されている内容を確認することができる。
【０１１３】
次に、BBSの詳細について説明する。図２４は、BBSを構成するSubunit identifier Descriptorのフォーマットを表している。descriptor_lengthは、このDescriptorの長さを表す。generation_IDは、このBBSにおいて、どのAV/C descriptorフォーマットが使用されるかを表し、通常”００₁₆”とされる。
【０１１４】
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を表すものである場合、図２５に示すように、所定の値”１００１₁₆”とされる。このように、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の場合、”０１₁₆”とされる。
【０１２３】
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は、それぞれ制限が設けられていない場合には、”００００₁₆”とされる。
【０１２４】
これらの３つのフィールドは、コントローラがobject listまたは、object entryの容量を知る上において、有意義である。
【０１２５】
board_type_dependent_information_lengthは、board_type_dependent_information_lengthの長さを表し、board_type_dependent_information_lengthは、board typeに固有の情報を表す。
【０１２６】
object_entryは、より詳細には、図２９に示すように構成される。descriptor_lengthは、このdescriptorの長さを表し、entry_typeは、Board entry Descriptorの場合、Board を表す値”８０₁₆”とされる。
【０１２７】
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は、”００₁₆”とされる。
【０１３４】
repeat_informationは、選択されたrepeat typeによって内容が異なる。repeat typeには、図３３に示すように、Weekly schedule”００₁₆”と、Interval schedule”１０₁₆”とがある。
【０１３５】
scheduleが、週毎に繰り返される場合、Posting Deviceは、その曜日および繰り返されるべきeventの数を図３４に示すように表示する。
【０１３６】
repeat_typeには、図３３に示す値、”００₁₆”が記述される。number_of_eventsには、eventの数が記述される。日曜日から土曜日までのWeekly flagsは、繰り返されるeventが開始する週の日を表す。例えば、１３時００分から３時間のeventが、毎週月曜日と水曜日に開始される場合、月曜日と水曜日のフラグに”１”が設定され、その他のフラグには”０”が設定される。
【０１３７】
このように週毎に繰り返されるeventが記録できるので、例えば月曜日と水曜日の絶対的な日時を放送日に対応する分だけ記憶させるような場合に比べて、記憶容量は小さくて済ませることが可能ととなる。
【０１３８】
Posting Deviceは、Scheduled Actionが所定のintervalsで繰り返される場合、図３５に示すようなフォーマットでeventを記述する。
【０１３９】
repeat_typeには、この例の場合、図３３に示す値”１０₁₆”が記述される。number_of_eventsには、eventの数が記述される。
【０１４０】
interval（間隔）は、現在のeventのstart_timeから次のeventのstart_timeまでの間隔を表す。この間隔は、時分秒で表される。時間は、３つの数字がそれぞれ４ビットのBCDで表され、合計１２ビットで表現される。分と秒は、それぞれ２つの数字が４ビットのBCDとされ、合計８ビットで表現される。
【０１４１】
このように周期的に繰り返されるeventが記憶できるので、それぞれが開始される絶対時刻（日時）を別に記憶させる場合に比べて、記憶容量が少なくて済む。
【０１４２】
図３０に示すように、info blocksは図３６に示すようなフォーマットとされる。conpound_lengthは、info blockのバイト長を表す。ただしlengthフィールド自身は、この長さに含まれていない。info_block_typeは”８９００₁₆”にセットされる。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であることを表す値”０１₁₆”が記述される。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設定処理を説明するフローチャートである。
【図２１】 SA Event 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，２ IEEE１３９４シリアルデータバス，３ DVCR，１１コントローラ，１２チューナサブユニット，１４ BBS，３１コントローラ，３２アナログチューナブロック，３３ VCRサブユニット，３４ BBS，５１ RSB，５２ SAB，６１ RSB，６２ SAB[0001]
BACKGROUND OF THE INVENTION
The present invention relates to an information processing apparatus and method, and a recording medium. In particular, in an information processing apparatus connected to another information processing apparatus via an IEEE 1394 serial data bus, it is ensured without duplicating built-in subunits. The present invention relates to an information processing apparatus and method that can be controlled, and a recording medium.
[0002]
[Prior art]
AV devices capable of transmitting information to each other via a network using an IEEE 1394 serial data bus have been developed. In this network, it is possible to control AV devices connected to the network by using a predetermined command (AV / C Command Transaction Set). For example, as shown in FIG. 1, a DVCR connected to an image received by an IRD (Integrated Receiver Decoder) 71 that receives a digital satellite broadcast via an IEEE 1394 serial data bus 2 (hereinafter referred to as a bus 2). (Digital Video Cassette Recorder) 81 can be used for recording. Furthermore, so-called recording reservation can be performed using the IRD 71 and the DVCR 81.
[0003]
In the recording reservation process, the controller 72 of the IRD 71 controls the IRD 71 and the DVCR 81. That is, the recording reservation setting (channel, recording start time, etc.) is performed on the IRD 71. When the set recording start time is reached, the controller 72 of the IRD 71 is reserved in the tuner subunit 73 (setting). Channel) and the received video signal is output to the DVCR 81 via the bus 2. At the same time, the controller 72 transmits a recording start command to the VCR subunit 84 of the DVCR 81 via the bus 2. In response to the recording start command transmitted from the controller 72, the VCR subunit 84 of the DVCR 81 records the video signal from the tuner subunit 73 on the magnetic tape.
[0004]
By the way, as described above, when the operation of the DVCR 81 can be controlled from another device (IRD 71 in this example) connected via the bus 2, there is a possibility that so-called double booking may occur. is there.
[0005]
For example, when a digital satellite broadcast recording reservation (recording reservation A) is input to the IRD 71, the reservation information is stored in the controller 72 of the IRD 71. Thereafter, when a recording reservation for analog terrestrial broadcasting (referred to as recording reservation B) broadcast at a time overlapping with the recording time of recording reservation A is input to DVCR 81, controller 82 of DVCR 81 receives the recording reservation input to IRD 71. Since the information about A is not obtained, the recording reservation B is accepted and stored. Therefore, when the recording reservation A and the recording reservation B overlap, the video signal is supplied to the VCR subunit 84 of the DVCR 81 from both the tuner subunit 73 of the IRD 71 and the analog tuner block 83 of the DVCR 81. It will occur.
[0006]
This inconvenience is caused by the fact that AV equipment connected via the bus 2 cannot obtain reservation information and the like managed by other AV equipment.
[0007]
In order to solve the inconvenience described above, in the past, the DVCR 81 is provided with a mode called CS mode which is in a recording standby state only in accordance with the control of the controller 72 of the IRD 71. After inputting the recording reservation A to the IRD 71, the DVCR 81 Setting CS to CS mode prevented the occurrence of double booking.
[0008]
[Problems to be solved by the invention]
However, since the DVCR 81 set in the CS mode is in a reservation standby state, for example, processing such as reproduction of a video signal cannot be executed, and there is a problem that operability is poor.
[0009]
In addition, since there is no method for uniquely specifying an event such as a recording reservation transmitted to the bus 2, for example, when correcting an event, it is necessary to generate a command for each AV device related to the event. There was a problem with poor operability.
[0010]
Furthermore, when a plurality of AV devices output information to the bus 2 at the same time due to the fact that information (recording start time, etc.) managed by other AV devices is not known, the amount of information output is the bus 2 There is a problem that transmission errors may occur beyond the bandwidth.
[0011]
The present invention has been made in view of such a situation, and each AV device connected to the bus improves the operability at the time of recording reservation by searching information managed by each AV device. It is intended to prevent the occurrence of double booking.
[0018]
[Means for Solving the Problems]
  The receiving device of the present invention operates a tuner subunit, which is a functional block of the receiving device itself as a unit, and a VCR subunit, which is a functional block of a recording device connected via a network. Setting means for setting an object ID consisting of a unique ID of the receiving device itself and an ID that does not conflict within itself for the set reservation, and the setting means First storage means for storing information related to the reservation of the tuner subunit together with the set object ID, and disclosing the stored information in response to a request from a device connected via the network And storing information for controlling a series of operations relating the tuner subunit and the VCR subunit. And storage means for storing information relating to the reservation of the VCR subunit in the recording device, and control means for storing information relating to the reservation of the VCR subunit together with the object ID set by the setting means. In the recording device, when storing information related to the reservation of the VCR subunit, after storing information related to the reservation using the unique ID portion of the object ID as a temporary temporary number The temporary number is rewritten with the unique ID. Further, as the series of operations, the tuner subunit extracts a signal of a predetermined channel from a signal input from an antenna and supplies the signal to the VCR subunit via the network, and the VCR subunit The signal supplied from the tuner subunit is recorded on the recording medium.
[0020]
The network can be configured using an IEEE 1394 serial data bus.
[0022]
  The information processing method according to the present invention operates a subunit, which is a functional block of a receiving apparatus itself as a unit, and a VCR subunit, which is a functional block of a recording apparatus connected via a network. If the reservation is set, for the set reservation, set an object ID consisting of the unique ID of the receiving device itself and an ID that does not conflict within itself, along with the set object ID, Information relating to the reservation of the subunit is stored in the first storage means, and the stored information is disclosed in response to a request from a device connected via the network, and the subunit and the VCR sub-unit are disclosed. Information for controlling a series of operations associated with the unit is stored in the second storage means, and the pre-recording of the VCR subunit that the recording apparatus has is stored. Storing information related to the reservation of the VCR subunit together with the set object ID in the storage means for storing information related to the recording device, in the recording apparatus, when storing the information related to the reservation of the VCR subunit, After storing information related to reservation using the unique ID portion of the object ID as a temporary temporary number, the temporary number is rewritten with the unique ID. Further, as the series of operations, a signal of a predetermined channel is extracted from a signal input from an antenna by the tuner subunit and supplied to the VCR subunit via the network, and the VCR subunit The signal supplied from the tuner subunit is recorded on the recording medium.
[0023]
  The recording medium program of the present invention operates in association with a subunit, which is a functional block of a receiving apparatus itself as a unit, and a VCR subunit, which is a functional block of a recording apparatus connected via a network. If the reservation is to be set, an object ID consisting of a unique ID of the receiving device itself and an ID that does not compete with itself is set for the set reservation, together with the set object ID , Storing information relating to the reservation of the subunit in the first storage means, and releasing the stored information in response to a request from a device connected via the network, the subunit and the VCR Information for controlling a series of operations associated with the sub-unit is stored in the second storage means, and the VCR sub-unit possessed by the recording apparatus is stored. A storage means for storing information on the feeding of the reservation, together with the object ID set, to execute processing comprising the step of storing information on reserved the VCR sub-unit to the computer. In the recording device, when storing the information related to the reservation of the VCR subunit, after storing the information related to the reservation using the unique ID portion of the object ID as a temporary temporary number, the unique ID is stored. The temporary number is rewritten with the ID. Further, as the series of operations, a signal of a predetermined channel is extracted from a signal input from an antenna by the tuner subunit and supplied to the VCR subunit via the network, and the VCR subunit The signal supplied from the tuner subunit is recorded on the recording medium.
[0024]
  In the present invention, there is a reservation for operating a subunit, which is a functional block of the receiving device itself as a unit, and a VCR subunit, which is a functional block of a recording device connected via a network. If set, an object ID consisting of a unique ID of the receiving device itself and an ID that does not conflict within itself is set for the set reservation, and the sub-object is set together with the set object ID. Information relating to the unit reservation is stored in the first storage means, and the stored information is released in response to a request from a device connected via the network. Further, information for controlling a series of operations relating the subunit and the VCR subunit is stored in a second storage means, and information relating to the reservation of the VCR subunit that the recording apparatus has is stored. The storage unit stores information related to the reservation of the VCR subunit together with the set object ID. In the recording device, when storing information related to the reservation of the VCR subunit, the unique ID is stored after storing information related to the reservation using the unique ID portion of the object ID as a temporary temporary number. Then, the temporary number is rewritten. Further, as the series of operations, a signal of a predetermined channel is extracted from a signal input from an antenna by the tuner subunit and supplied to the VCR subunit via the network, and the VCR subunit The signal supplied from the tuner subunit is recorded on the recording medium.
[0038]
DETAILED DESCRIPTION OF THE INVENTION
A configuration example of a network system to which the present invention is applied will be described with reference to FIG. In this specification, the term “system” means an overall apparatus constituted by a plurality of apparatuses and means.
[0039]
This network system includes IRD 1 and DVCR 3 connected via a bus 2. Of course, in addition to IRD1 and DVCR3, an electronic device having an IEEE1394 terminal such as a personal computer, a hard disk drive, a CD player, a monitor, a digital video camera, or an MD (trademark) player can be connected to the bus 2. It is.
[0040]
  Note that electronic devices such as IRD1 and DVCR3 connected to the bus 2 are called units, and AV / C Digital Interface Command Set General Specification (hereinafter referred to as AV / C Command Transaction Set) between the units. It is possible to read and write information stored in each unit mutually using a descriptor defined by AV / C General. For more information on AV / C General,See http://www.1394ta.org/Technology/Specifications/.The function of the unit is called a subunit.
[0041]
The controller 11 of the IRD 1 receives a channel selection operation or a recording reservation operation from the user, and controls the entire IRD 1. The controller 11 controls the DVCR 3 using a predetermined command (AV / C Command Transaction Set). The CS antenna 13 receives a digital satellite broadcast digital signal transmitted via a communication satellite (not shown) and outputs it to the tuner subunit 12. Based on the control of the controller 11, the tuner subunit 12 extracts a signal of a predetermined channel from the digital signal input from the CS antenna 13 and outputs it to the VCR subunit 33 of the DVCR 3 via the bus 2. Further, the controller 11 searches for information stored in a BBS (Bulletin Board Subunit) 34 of the DVCR 3.
[0042]
The BBS 14 that is a subunit of the IRD 1 stores information of the recording reservation that has been accepted and confirmed by the controller 11 (details will be described later with reference to FIG. 24).
[0043]
The DVCR 3 controller 31 accepts a playback instruction operation or a recording reservation operation from the user, and controls the entire DVCR 3. Based on the control of the controller 31, the analog tuner block 32 extracts a predetermined channel signal from the input analog signal and outputs it to the VCR subunit 33.
[0044]
The VCR subunit 33 records the video signal input from the analog tuner block 32 or the video signal from the tuner subunit 12 of the IRD 1 input via the bus 2 on a magnetic tape (not shown).
[0045]
The BBS 34 manages recording reservation information related to the DVCR 3.
[0046]
The tuner subunit 12 and the BBS 14 are IRD 1 subunits, and the VCR subunit 33 and the BBS 34 are DVCR 3 subunits. The analog tuner block 32 performs one function of the DVCR 3, but is not a subunit because it is not controlled from another unit via the bus 2.
[0047]
In this network system, when making a recording reservation for digital satellite broadcasting, the user inputs recording reservation settings (settings such as a channel and a recording start time) to the IRD 1. If the recording reservation is not double booking, the input recording reservation is accepted and the information is written in the BBS 14 of the IRD 1.
[0048]
As shown in FIG. 3, the BBS 14 includes an RSB (Resource Schedule Board) 51 and an SAB (Schedule Action Board) 52. The SAB 52 stores all information related to the recording reservation input from the controller 11 of the IRD 1 or the controller of another unit (for example, the controller 31 of the DVCR 3). That is, the SAB 52 stores all information for controlling a series of operations of causing the tuner subunit 12 of the IRD 1 to receive at a predetermined time and recording the received information to the VCR subunit 33 of the DVCR 3.
[0049]
On the other hand, the RSB 51 stores only information related to the reservation of the tuner subunit 12 that is a subunit of the IRD 1 out of all the information related to the recording reservation (including the recording reservation set by other units) ( Even when the operation is related, the reservation information of the VCR subunit 33 is not stored), and the stored information is not only the controller 11 in the same unit but also the controller of another unit (for example, the controller 31 of the DVCR 3). Publish in response to requests from
[0050]
Similarly, the BBS 34 of the DVCR 3 includes an RSB 61 and an SAB 62 as shown in FIG. The SAB 62 stores all information related to the recording reservation input from the controller 31 of the DVCR 3 or the controller of another unit (for example, the controller 11 of the IRD 1). On the other hand, the RSB 61 reserves the VCR subunit 33, which is a subunit of DVCR3, of the recording reservation input to the controller 31 of DVCR3 and all the information related to the recording reservation input to the controller 11 of IRD1. (Even if the operation is related, the reservation information of the tuner subunit 12 is not stored), and the stored information is not limited to the controller 31 in the same unit, but the controllers of other units (for example, It is disclosed in response to a request from the controller 11) of IRD1.
[0051]
Details of the information stored and disclosed in the RSBs 51 and 61 will be described in detail with reference to FIG.
[0052]
Next, operations related to the RSBs 51 and 61 will be described with reference to FIG. For example, as shown in FIG. 5, the controller 11 of the IRD 1 makes the recording reservation (October 16, from 20:00 to 21:00, the tuner subunit 12 receives the 48th channel and receives the received video signal. Is input to the VCR subunit 33 of the DVCR 3), the controller 11 sets a unique ID (BB Object ID) (ID_X in this example) for the recording reservation and stores it in the SAB 52. In addition to storing all information related to the recording reservation, the ID (ID_X), date and time (October 16, 20:00 to 21:00) set in RSB51, and related IRD1 subunits (currently In this example, information (identification information) for specifying the tuner subunit 12) is stored. Further, the controller 11 sets the set ID (ID_X), date and time (October 16, 20:00 to 21:00), and related DVCR3 subunits (in this example, Information for identifying the VCR subunit 33) (identification information) is stored.
[0053]
Thereafter, for example, as shown in FIG. 6, the controller 31 of the DVCR 3 makes the recording reservation (October 16, 20:00 to 21:00 to the analog tuner block 32 to receive the third channel, and the received video is transmitted to the VCR. When the reservation for recording to the subunit 33 is input, the controller 31 refers to the RSB 61, and whether the input recording reservation information overlaps with the information that the recording reservation has already been approved and published to the RSB 61 Determine whether or not. In the case of this example, since the recording time of October 16th, from 20:00 to 21:00 overlaps, the input recording reservation is not approved. If it is determined that the recording reservation information that has been input and the information that the recording reservation has already been approved and published (registered) in RSB 61 do not overlap, the input recording reservation is approved and all of the information Is recorded in the SAB 62, and the reservation information related to the VCR subunit 33 among all the information is recorded in the RSB 61.
[0054]
Next, the details of the above reservation process (contention unit search process) will be described with reference to the flowcharts of FIGS.
[0055]
First, in step S <b> 11, the user performs reservation setting processing for the controller 11 of the IRD 1. That is, in the example of FIG. 5, from 20:00 to 21:00 on October 16, the 48th channel is received by the tuner subunit 12, and this is transferred to the VCR subunit 33 of DVCR3 and recorded. Is entered. At this time, in step S12, the controller 11 executes processing for WRITE OPENing the RSB in the device in which the subunit to be used exists. In the example of FIG. 5, the subunits to be used are the tuner subunit 12 of the IRD1 and the VCR subunit 33 of the DVCR3. Therefore, one of the subunits, for example, the tuner subunit 12 is selected first, and the controller 11 In order to WRITE OPEN the RSB 51 of the IRD 1 as a device having the tuner subunit 12 (to make it writable), a WRITE OPEN command is output.
[0056]
However, actually, the RSB 51 and the controller 11 are held in the IRD 1, and the bus 2 does not exist between them. Therefore, the controller 11 controls the RSB 51 so as to be in the same state as when the WRITE OPEN command is supplied to the RSB 51 via the bus 2.
[0057]
For example, after the processing of WRITE OPEN for the RSB 51 in the IRD 1 as the device in which the tuner subunit 12 is present among the subunits used in association, the VCR subunit 33 as the remaining related subunit is next. In this case, the controller 11 performs a WRITE OPEN command having a format as shown in FIG. 10 via the bus 2. Output to the RSB 61 (controller 31) of DVCR3.
[0058]
This WRITE OPEN command is a kind of OPEN DESCRIPTOR command used to access a predetermined address space of a target, and has a format as shown in FIG. The opcode has a value (08 indicating OPEN DESCRIPTOR)₁₆) Is described. Operand 0 has a value 10 indicating that it is an Object List Descriptor defined by the list ID as descriptor_type indicating the type of descriptor to be WRITE OPEN.₁₆Is described. In operand1 and operand2, list IDs (in this example, “00” and “01”) of RSBs to be accessed (WRITE OPEN) are described.
[0059]
Further, operand3 has a value 03 indicating that the descriptor is a WRITE OPEN that opens a descriptor for read or write access.₁₆Is described. Operand 4 has a value “00” for reservation.
[0060]
In step S13, the controller 11 reads the descrptior_length of RSB 51 in the BBS 14 and the list_specific_information field (FIG. 26). This reading is performed using, for example, a READ command shown in FIG. However, even in this case, the controller 11 and the RSB 51 are not connected via the bus 2, so that the controller 11 reads the RSB 51 directly. However, when the controller 11 reads data from the RSB 61 of the DVCR 3, a READ command as shown in FIG. 11 is output to the RSB 61 (controller 31) via the bus 2.
[0061]
As shown in FIG. 11, the opcode at the head of the READ command has a value indicating a read descriptor, 09₁₆Is described. In the following operand0, a descriptor identifier for identifying the descriptor to be read is described. In the case of the reading process in step S13, the descriptor identifier is described by the list ID. Specifically, 00 of Address_offset of write enabled list_specific_information field of RSB of FIG.₁₆To 0D₁₆Is described.
[0062]
In read_result_status, FF is described when a READ command is sent, and a read result is described when returned as a response from the target. In data_length, the number of bytes of data to be read from the target is described. When this value is set to “0”, all lists are read. In address, an address at which reading is to be started is described. When the value is “00”, reading is started from the top.
[0063]
In step S14, the controller 11 limits the maximum length of the list (object_list_maximum_size in FIG. 27), the limit on the number of entries in the list (object_entries_maximum_number in FIG. 27), and the limit on the maximum byte length of each entry (FIG. 27). Object_entry_maximum_size) is extracted.
[0064]
In step S15, the controller 11 determines whether the maximum length (object_list_maximum_size) of the list extracted in step S14 does not exceed even if data (reservation information) is recorded in the RSB 51 from now on. If this limit is observed, the process proceeds to step S16, and the controller 11 obtains a value obtained by subtracting the current entry number from the limit (maximum number of entries) (object_entries_maximum_number) of the list entries extracted in step S14. It is determined whether or not it is larger than 0 ″, that is, whether or not there are still recordable entries. When this condition is satisfied, the process further proceeds to step S17, where the controller 11 has a value obtained by subtracting the entry length to be written from the maximum entry length (object_entry_maximum_size) extracted in step S14 from “0”. It is determined whether it is large, that is, whether the entry length to be written still has room.
[0065]
If any one of the conditions in steps S15 to S17 is not satisfied, the process proceeds to step S18, and the controller 11 displays a warning display such as “Reservation is full” to the user. This allows the user to know that the reservation is full and no further reservations can be made.
[0066]
If any of the conditions of Steps S15 to S17 is satisfied, there is room for writing the reservation information in the RSB 51. Therefore, in Steps S19 to S25, it is determined whether or not reservations for overlapping times have already been made. Processing is performed.
[0067]
That is, in step S19, “0” is initially set in the variable i. In step S20, whether or not the value obtained by subtracting the variable i from the number of entries number_of_entries recorded in the RSB 51 is greater than “0”, that is, in the RSB 51. It is determined whether or not all the recorded entries have been searched. If the value obtained by subtracting the variable i from number_of_entries is greater than “0”, there is an entry that has not yet been searched, and therefore the controller 11 proceeds to step S21, and the controller 11 displays object_entry [i] (shown in FIG. 29) is read (in this case, object_entry [0] is read).
[0068]
The reading in step S21 is also performed by the READ command shown in FIG. 11. In this case, the descriptor identifier is described by the object position. In this object entry [i], as will be described later, reservation time information that has already been registered (start_time, Duration in FIG. 30) and identification information of a subunit to be used in the reservation (subunit_type_and_ID [in FIG. 36] 0]) and the like are stored.
[0069]
In step S22, the controller 11 determines whether the time information (start_time, Duration) input by the user in step S11 overlaps with the time information (start_time, Duration) read in step S21. . If the times are duplicated, the process proceeds to step S23, and the controller 11 reserves the subunit (subunit_type_and_ID) read out in step S21 by the subunit reserved in step S11 (in this case, the tuner subunit 12). It is determined whether or not they match. If the subunits match, eventually both the time and the subunit match, so the process proceeds to step S25, and the controller 11 warns, for example, “reservations are overlapping”. Display. This prevents double booking.
[0070]
If it is determined in step S22 that the times do not overlap, or if it is determined in step S23 that the subunits do not match even if the times match, double booking may occur. There is no. Therefore, in step S24, only the variable i is incremented by 1, and the process returns to step S20, and the same processing is repeatedly executed until it is determined that the value obtained by subtracting the variable i from number_of_entries is not greater than 0. That is, for all object entries [i] stored in the RSB 51, a search is performed as to whether or not reservations for overlapping times have been made.
[0071]
If it is determined in step S20 that the value obtained by subtracting the variable i from number_of_entries is not greater than “0” (when the search for all object entries [i] is completed), the process proceeds to step S26, and the controller 11 determines that the RSB 51 The CREATE command is output to, and an object entry is created in RSB51. In this case, however, the CREATE command is not actually output (although it is output when an object entry is created for the RSB 61), and only the same processing as when it is output is performed.
[0072]
It should be noted that the processing from step S15 to step S18 described above can be executed when NO is determined in the processing of step S20.
[0073]
Here, the CREATE command will be described. FIG. 12 shows the format of the AV / C CREATE command. FIG. 13 shows values that can be specified by subfunction_1 in FIG. 12, and “01” (create a new object and its child list) is used in this embodiment. FIG. 14 shows a format of subfunction_1_specification for subfunction_1 = 01 in FIG. Further, FIG. 15 is a diagram showing each field value in FIG. As shown in FIG. 15, when “20”, “22”, and “11” are set in the fields of descriptor_identifier_where, descriptor_identifier_what_1, and _2, respectively, in FIG. 14, this means “create a new object and its child list”. .
[0074]
Details of these AV / C CREATE commands are described in IEEE 1394 (refer to the Internet homepage http://www.1394TA.org), and each figure in the present embodiment is described in the literature (Enhancement). to the AV / C General Specification 3.0 Version 1.0 FC2 and TA Document 1999005 AV / C Bulletion Board Subunit General Specification 1.0 Draft 0.99: 149). In addition, there are information writable and readable information descriptors (Information List Descriptors) constituting the board, and a list type is used for the distinction between them.
[0075]
By the way, as one method of writing information to the AV / C descriptor (AV / C Descriptor) from the outside, for example, the controller issues the above-mentioned CREATE command to the target, and the target creates a template for writing the information. Then, a method in which the controller performs control to write specific contents again is considered as a general method. For example, when information is written for the first time, the controller designates a desired list and issues an AV / C descriptor create command. In the target that receives this command, an object based on the data structure template specified in AV / C General is created inside the target. In addition, the data structure model determined by AV / C General includes a field indicating an object ID. In the list using the AV / C descriptor (AV / C Descriptor), the object ID is managed by the target. That is, when an object is created (CREATE), the target assigns an ID that can uniquely specify the object, and the target has a function of managing the ID.
[0076]
Here, the object ID is an identification number for uniquely specifying the object in the list. Therefore, a function for preventing the object ID from being duplicated is required on the management side. The BBS itself is a place for providing information, and the controller manages the object ID.
[0077]
However, when a create command is issued to a subunit, there is a risk of inconsistency. That is, when an object is created, the target allocates an object ID to be managed by the controller. Further, after issuing a create command, it is necessary to continue the write control. As described above, since the process is divided into a plurality of steps, an incomplete object may be created when the controller is removed from the bus during writing, for example.
[0078]
Therefore, in the situation as described above, there is a need for a system that can identify an incomplete object and delete the object when such an object is created.
[0079]
Therefore, in the embodiment of the present invention, a mechanism for specifying an incomplete object is prepared by defining a writing means to the BBS by the standard.
[0080]
That is, first, the target (DVCR3 in the case of this embodiment) is the object ID (consisting of a global unique ID (GUID) and a record ID) when the object is created (CREATE). A number to be temporarily managed (for example, all “0”) is assigned to the GUID part. The controller writes information in the object first, and if the writing is completed normally, it rewrites the GUID at the end.
[0081]
By deciding the above procedure, when writing is completed normally, an object whose GUID is all “0” cannot be created. Therefore, an object whose GUID is all “0” cannot be created during writing. It can be identified as a complete object.
[0082]
This makes it possible to uniquely identify the object that is being written, distinguish between a normally written object and an incomplete object, and easily delete incomplete objects (invalid objects). Is possible. As a result, a finite memory provided in the electronic device can be effectively used. In addition, since the method for specifying an object in the middle of writing is a simple method in which all GUID portions of the object ID are set to “0”, it is easy to create software for deleting an incomplete object.
[0083]
In step S26 in FIG. 9, an INSERT command can be used instead of using the CREATE command.
[0084]
Next, proceeding to step S27, the controller 11 writes the reservation content in the entry_specific_information fields portion (FIGS. 30 to 36) of the RSB 51. That is, by this, start_time, Duration, repeat_information, and the subunit to be used (subunit_type_and_ID) are written.
[0085]
FIG. 16 shows the format of the WRITE DESCRIPTOR command output by the controller 11 in such a case. However, even in this case, since the controller 11 and the RSB 51 are not connected via the bus 2, writing is performed directly. However, when the controller 11 writes to the RSB 61 of the DVCR 3, the controller 11 Issue this WRITE DESCRIPTOR command.
[0086]
The first opcode has a value 0A indicating that it is a WRITE DESCRIPTOR₁₆Is described. In operand0, a descriptor indentifier for identifying a descriptor to be written is described. This description is made at the object position.
[0087]
Hereinafter, as a subfunction, a value indicating partial_replace, 50₁₆Is described. As a result, partial insert or partial delate is executed. In insert, a new descriptor is inserted immediately before the one specified by the operand specified by descriptor_identifier. In delete, the descriptor specified by descriptor_identifier is deleted.
[0088]
The group_tag is used to perform update processing that cannot be divided on the descriptor where the WRITE DESCRIPTOR command needs to be issued. In this example, the value 00 represents quickly writing data to the descriptor.₁₆(Immediate) is described. replacement_data_length represents the number of bytes in the operand of replacement_data, that is, the length of data to be written. address represents a position where processing is to be performed. “0” of replacement_data_length means partial delete. In this case, there is no operand of replacement_data. In this case, original_data_length is a value larger than “0”, which represents the number of bytes to be deleted. When original_data_length is “0”, partial insert processing is performed. In this case, replacement_data_length is a value larger than “0” and represents the number of bytes to be inserted.
[0089]
In step S28, the controller 11 closes the list, that is, the RSB 51. At this time, the controller 11 outputs a CLOSE command shown in FIG. 17 to the RSB 51. However, in this case as well, the controller 11 and the RSB 51 are not connected via the bus 2, so the close process is performed directly. However, when the controller 11 closes the RSB 61 of the DVCR 3, A CLOSE command is output.
[0090]
The format of the CLOSE command shown in FIG. 17 is basically the same format as the WRITE OPEN command shown in FIG. 10, and the subfunction is “03” indicating WRITE OPEN in FIG.₁₆In contrast, in the CLOSE command in FIG. 17, a value indicating CLOSE, “00”₁₆The other points are the same as those in FIG.
[0091]
Next, proceeding to step S29, the controller 11 determines whether there are other resources related to the reservation. In this case, since the processing for reserving the tuner subunit 12 has been completed by the processing so far, processing for reserving the VCR subunit 33 of the DVCR 3 is still necessary. Therefore, in this case, the process returns to step S12, and the same processing as that performed for the RSB 51 described above is also performed for the RSD 61 of the DVCR 3.
[0092]
When it is determined in step S29 that there are no other resources related to the reservation, the process is terminated.
[0093]
Incidentally, for example, as shown in FIG. 18, a series of recording reservations for recording the video signal received by the tuner subunit 12 in the VCR subunit 33 of the DVCR 3 is independent of the IRD 1 for reception and independent of the DVCR 3 for recording. In other words, the controller 11 of the IRD 1 receives the predetermined channel (the 48th channel) at the predetermined time (October 16, 20:00 to 21:00) to the tuner subunit 12. When a reservation for starting recording at a predetermined time (October 16, from 20:00 to 21:00) is input to the controller 31 of the DVCR 3, The input of two reservations is one recording reservation for the user, but independent reservations for IRD1 and DVCR3. Since it is an input, a different ID (BB Object ID_Y, BB Object ID_Z) is set for each reservation and stored in the corresponding RSB 51 or RSB 61.
[0094]
As described above, even when each unit makes a reservation independently, the reservation process can be performed by the same process as that shown in the flowcharts of FIGS. However, when the subunits are used jointly in this way, it is necessary for the user to manage whether or not double booking occurs if each reservation is made independently.
[0095]
As shown in FIG. 19, the present invention can be applied even when the IRD 1 does not have the BBS 14. In this case, for example, when the reservation of the VCR subunit 33 of the DVCR 3 is input from the controller 11 of the IRD 1 from 20:00 to 21:00 on October 16, this reservation is made via the bus 2. Is written to the RSB 61 of the BBS 34 of the DVCR 3.
[0096]
Next, the Object ID setting process will be described with reference to the flowchart of FIG. In this process, the user inputs a recording reservation operation using DVCR3 to the IRD 1, the operation is detected by the controller 11, and the above-described reservation processing (competitive unit search processing) shown in FIGS. 7 to 9 is executed. After the recording reservation is approved, it starts. In this example, an Object ID is associated with a reservation process (Event) that is executed from a predetermined time to a predetermined time in order to identify it. This Object ID is composed of 72 bits, of which 64 bits on the MSB side are the unique ID of the device having all the information related to the reservation, specifically the GUID (Global Unique ID) of the device. For example, IEEE EUI-64 is used. The 8 bits on the LSB side are a unique value set in the device, and specifically, a record ID. By configuring the Object ID with the GUID and the record ID in this way, unique ID setting processing can be facilitated, and useful information that can identify the written owner can be included.
[0097]
That is, this Object ID needs to be identifiable among the devices connected to the bus 2. Otherwise, in this example, the contents of the RSB of one unit (device) can be read by other units (devices) and processed jointly (related) in the sub-units of multiple units. This is because it is necessary for other units to be able to identify whether there is an associated process.
[0098]
In step S41, the controller 11 generates a temporary ID for uniquely identifying the reservation information in the IRD 1 as the record ID of the Object ID (= Global Unique ID + record ID).
[0099]
In step S42, the controller 11 extracts one Event from the Events registered in the RSB 51, and extracts the record ID in the Object ID corresponding to the Event. In step S43, the controller 11 determines whether or not the temporary ID generated in step S41 matches the record ID extracted in step S42. If they match, the controller 11 returns to step S41, changes the temporary ID, and matches. Steps S41 to S43 are repeated until a temporary ID is generated.
[0100]
When it is determined that the temporary ID and the record ID extracted in step S42 do not match, in step S44, the controller 11 determines whether or not all the events disclosed in the RSB 51 related to the related subunit have been extracted. If an event that has not yet been extracted remains, the process returns to step S42, and the processes of steps S42 to S44 are repeated until it is determined that all the events have been read. When it is determined that all the events have been read, in step S45, the controller 11 adds the temporary ID (record ID) generated in step S41 to the device ID (GUID) of the IRD 1 to generate an Object ID. Describe in RSB51 etc.
[0101]
In this way, the Object ID can be set only by checking the RSB for related subunits (without checking the RSB of units having unrelated subunits). As described above, the Object ID in the RSB of another unit contains the GUID of that unit, so the Object ID set by the other unit matches the Object ID set by itself. This is because there is no possibility. Therefore, it is possible to easily set the Object ID.
[0102]
It should be noted that, instead of the Object ID, a specific ID unique within the bus 2 (hereinafter, this ID is referred to as SA Event ID) can be used. FIG. 21 shows processing in this case. In this process, the user inputs a recording reservation operation using DVCR3 to the IRD 1, the operation is detected by the controller 11, and the reservation (competitive unit search) process of FIGS. 7 to 9 is executed. It starts after the recording reservation is approved.
[0103]
In step S51, the controller 11 generates a temporary ID that can uniquely identify the reservation information in the bus 2. In step S52, the controller 11 reads an event stored in the RSB 51 of one unit (or a unit related in the reservation operation) in the bus 2 and extracts the SA event ID therein. In step S53, the controller 11 determines whether or not the temporary ID generated in step S51 matches the SA Event ID extracted in step S52, and repeats the processes in steps S51 to S53 until it is determined that they do not match. .
[0104]
If it is determined that the temporary ID generated in step S51 and the SA Event ID extracted in step S52 do not match, in step S54, the controller 11 stores all SA Events of the units (or related units) in the bus 2. It is determined whether or not it has been read, and the processes in steps S52 to S54 are repeated until it is determined that all SA Events have been read. If it is determined that all SA Events have been read, the controller 11 records the temporary ID generated in Step S51 in the RSB 51 as the SA Event ID in Step S55.
[0105]
In the case of the processing shown in FIG. 21, it is necessary to check the RSBs of all the units connected to the bus 2. On the other hand, in the case of the process shown in FIG. 20, only the RSB of the unit related to itself needs to be checked, so that the process can be completed quickly.
[0106]
As described above, the Object ID can be stored not only in the RSB but also in the SAB. Thereby, when double booking occurs, it can be easily confirmed. For example, as shown in FIG. 22, it is assumed that IRD 1 and DVCR 3 are connected to bus 2 and IRD 91 is connected. The IRD 1 has an RSB 51 and SAB 52 in the BBS 14 and a SID (Subunit Identifier Descriptor) 100. The SID 100 stores information for recognizing what board types (RSB 51 and SAB 52 in this example) are supported in the BBS 14 to which the SID 100 belongs.
[0107]
In addition to RSB 61, SID 81 is provided in BBS 34 of DVCR3. The IRD 91 includes a controller 92 and a display unit 93.
[0108]
Next, a processing example in the system of FIG. 22 will be described. The user inputs reservation information to the controller 11 of the IRD 1. In the example of FIG. 22, the reservation content is input in which the X channel is selected from 20:00 to 21:00 on August 12, and the data of the selected program is recorded in DVCR3. The controller 11 writes this reservation content in the built-in memory, writes the reservation information in the RSB 51 and SAB 52 of its own BBS 14, and also writes the use schedule in the RSB 61 of the BBS 34 of the DVCR 3 as a target. At this time, the controller 11 sets the Object ID stored in each entry of RSB 51, SAB 52, and RSB 61 to the same value.
[0109]
In such a case, an example of processing when the IRD 91 attempts to reserve the DVCR 3 at a time overlapping with the time reserved by the IRD 1 will be described with reference to the flowchart of FIG.
[0110]
In step S61, the controller 92 of the IRD 91 checks the RSB 61 of the DVCR 3 as a target, and determines whether or not the schedule of another controller is recorded in the time zone to be used. When the schedule is not written in the overlapping time zone, the process proceeds to step S65, and the controller 92 executes the reservation process in the same manner as described above. That is, the controller 92 writes the usage time zone in the RSB 61 of the DVCR 3.
[0111]
If it is determined in step S61 that the VCR subunit 33 of the DVCR 3 has already been reserved in the overlapping time zone by another controller, the process proceeds to step S62, and the controller 92 determines the Object ID of the entry used for the reservation. And the node ID of the device to which the entry is written is determined from the upper 8 bytes (64 bits) of the GUID. That is, the GUID is unique to each device and does not change at every bus reset unlike the node ID. Therefore, the controller 92 checks the GUID and node ID of each device connected to the bus 2 and creates a correspondence table in advance. By referring to the correspondence table, the node ID can be determined from the GUID.
[0112]
Next, proceeding to step S63, the controller 92 designates the same Object ID as the multiple reservation entry from the SAB of the device determined in the process of step S62 (in this case, from the SAB 52 of IRD1), and the contents of the entry are designated. read out. In step S64, the controller 92 outputs the contents of the duplicate reservation read out in step S63 to the display unit 93 for display. Thereby, the user of IRD91 can confirm the contents reserved previously.
[0113]
Next, details of the BBS will be described. FIG. 24 shows the format of the Subunit identifier Descriptor that constitutes the BBS. descriptor_length represents the length of this Descriptor. The generation_ID indicates which AV / C descriptor format is used in this BBS.₁₆"
[0114]
size_of_list_ID represents the number of bytes of list ID. size_of_object_ID represents the number of bytes of this object ID.
[0115]
size_of_object_posion represents the number of bytes used when the position of the object in list is referenced. number_of_root_object_lists represents the number of root object lists with which this BBS is directly related.
[0116]
root_object_list_id_x (x = 0, 1, 2,..., n−1) represents each ID of root object lists related to this BBS. subunit_dependent_information_length represents the length of subunit_dependent_information, and information related to the format and content on which this BBS depends is described in subunit_dependent_information.
[0117]
In subunit_dependent_information, non_info_block_fiedlds_length, bulletin_board_subunit_version, number_of_supported_board_type (n) supported_board_type_specific_of_length [0], supported_board_type_specific_info [0] to supported_board_type_specific_info_n_supported_board include.
[0118]
Further, the BBS describes manufacturer_dependent_length indicating the length of the manufacturer_dependent_informatin and manufacturer_dependent_information including information dependent on the manufacturer.
[0119]
When the value of root_object_list_id represents RSB, as shown in FIG. 25, a predetermined value “1001” is used.₁₆In this way, by fixing the ID representing the RSB (described as Resource Schedule List in FIG. 25) to a predetermined value, the process of reading the RSB becomes easy.
[0120]
FIG. 26 shows the RSB format. descriptor_length represents the length of the RSB. The list_type describes whether the RSB is Read Only or Write Enabled. In the Read Only list, only reading is possible, and in the Write Enabled list, writing is possible.
[0121]
The size_list_specific_information represents the length of the list_specific_information, and the list_specific_information differs depending on the list_type. In the case of Write Enabled list_specific_infomation, information shown in detail in FIG. 27 is described.
[0122]
non_info_block_fileds_length is “01” in the case of a Resource Schedule Board as shown in FIG.₁₆"
[0123]
object_list_maximum_size represents the maximum size of the object list. object_entry_maximum_number represents the maximum number of object entries in the list. object_entry_maximum_size represents the maximum size of the object entry. The above object_list_maximum_size, object_entries_maximum_number, and object_entry_maximum_size are “0000” if no limit is provided.₁₆"
[0124]
These three fields are meaningful for the controller to know the capacity of the object list or object entry.
[0125]
board_type_dependent_information_length represents the length of board_type_dependent_information_length, and board_type_dependent_information_length represents information specific to the board type.
[0126]
More specifically, the object_entry is configured as shown in FIG. descriptor_length represents the length of this descriptor, and entry_type is “80” representing the Board in the case of the Board entry Descriptor.₁₆"
[0127]
The object_ID is composed of posting_device_GUID and record_ID. posting_device means a controller that has posted (posted) information to the BBS, and therefore posting_device_GUID represents the GUID. record_ID represents the ID assigned to the Event within the unit.
[0128]
size_of_entry_specific_imformation represents the size of entry_specific_imformation.
[0129]
FIG. 30 shows the format of entry_specific_imformation. non_info_block_length represents the number of bytes of non-info block fields up to repeat_information. In detail, as shown in FIG. 31, start_time represents the year, month, day, hour, minute, and second when the event starts. The year is 16 bits, and four numbers are each represented by a 4-bit BCD. The month is 8 bits, and two numbers are each represented by a 4-bit BCD. A day is 8 bits, and two numbers are each represented by a 4-bit BCD. The time is 8 bits, and two numbers are each represented by a 4-bit BCD. The minute is 8 bits, and two numbers are each represented by a 4-bit BCD. The second is 8 bits, and two numbers are each represented by a 4-bit BCD.
[0130]
In this way, identification by BCD becomes easy. This time is expressed in local time.
[0131]
The duration representing the length of the event is represented in hours, minutes and seconds as shown in detail in FIG. The time is represented by 4 bits of BCD, each of which has a total of 12 bits. The minute is represented by a total of 8 bits, with 2 numbers being each a 4-bit BCD. The second is represented by a 4-bit BCD with 2 numbers each, for a total of 8 bits.
[0132]
The end time of evnt is expressed by adding Duration to start_time. By expressing the length of the event as a Duration instead of directly expressing the end time, even if the start_time of the event is changed, it is not necessary to change the end time, and the change process Becomes easy.
[0133]
repeat_information_length represents the length of repeat_information. repeat_information represents when and how the schedule is repeated. If Scheduled Action is not repeated, repeat_infomation_length is “00”₁₆"
[0134]
The content of repeat_information differs depending on the selected repeat type. The repeat type includes Weekly schedule “00” as shown in FIG.₁₆”And Interval schedule” 10₁₆"
[0135]
When the schedule is repeated every week, the Posting Device displays the day of the week and the number of events to be repeated as shown in FIG.
[0136]
In repeat_type, the value shown in FIG.₁₆"Number_of_events" describes the number of events. Weekly flags from Sunday to Saturday represent the day of the week when the repeated event starts. For example, an event of 3 hours from 13:00 is displayed. When starting every Monday and Wednesday, “1” is set in the flags of Monday and Wednesday, and “0” is set in the other flags.
[0137]
Since events that are repeated every week can be recorded in this way, it is possible to reduce the storage capacity compared to, for example, storing the absolute date and time of Monday and Wednesday by the amount corresponding to the broadcast date. It becomes.
[0138]
The Posting Device describes an event in a format as shown in FIG. 35 when the scheduled action is repeated at predetermined intervals.
[0139]
In this example, repeat_type has a value “10” shown in FIG.₁₆"Is described. In number_of_events, the number of events is described.
[0140]
The interval (interval) represents the interval from the start_time of the current event to the start_time of the next event. This interval is expressed in hours, minutes and seconds. The time is represented by a total of 12 bits, with three numbers each represented by a 4-bit BCD. The minutes and seconds are expressed by a total of 8 bits, with two numbers each being a 4-bit BCD.
[0141]
Since events that are repeated periodically can be stored in this way, the storage capacity can be reduced compared to the case where the absolute time (date and time) at which each event is started is stored separately.
[0142]
As shown in FIG. 30, the info blocks have a format as shown in FIG. conpound_length represents the byte length of the info block. However, the length field itself is not included in this length. info_block_type is "8900₁₆“_Primary_fields_length” represents the number of bytes in the number_of_subunits and subunit_type_and_ID fields.
[0143]
number_of_subunits represents the number of subunits used by the posting device. subunit_type_and_ID specifies subunits used by posting Device.
[0144]
In this way, start_time and Duration are represented by a fixed length at a fixed address. On the other hand, the identification information for identifying the subunit and the Posting Device using the subunit is stored as Info blocks at a predetermined address after start_time, Duration, and the like. Thereby, even if the number of Posting Devices increases, it becomes easy to cope.
[0145]
The supported_board_type_specific_information field in FIG. 24 has a format as shown in FIG. In supported_board_type, a value “01” indicating that the RSB is shown in FIG.₁₆Is described. The supported_board_type_version represents the version number of the bulletin Bond Type Specification. The implementation_profile_ID represents the profile ID version for this board type.
[0146]
supported_board_type_dependend_information_length represents the number of bytes of supported_type_dependent_information. Supported_board_type_dependent_information describes information specific to each board type specification.
[0147]
The series of processes described above can be executed by hardware, but can also be executed by software. When a series of processing is executed by software, the program that configures the software has various functions by installing a computer built into the controller as dedicated hardware or various programs. For example, a general-purpose personal computer.
[0148]
The general-purpose personal computer 101 includes a CPU (Central Processing Unit) 111 as shown in FIG. An input / output interface 116 is connected to the CPU 111 via the bus 115, and the CPU 111 receives a command from the input unit 118 including a keyboard and a mouse via the input / output interface 116. Correspondingly, it is recorded on a recording medium such as a ROM (Read Only Memory) 112 or a hard disk 114 or a recording medium such as a magnetic disk 131, an optical disk 132, or a magneto-optical disk 133 mounted on the drive 120. A program for executing the above-described series of processing is read, installed in a RAM (Ramdom Access Memory) 113, and executed. Note that the programs stored in the hard disk 114 include not only programs stored in advance and distributed to users, but also programs transferred from a satellite or network, received by the communication unit 119, and installed.
[0149]
Further, the CPU 111 outputs an image signal of the processing result of the program to the display unit 117 including an LCD (Liquid Crystal Display), a CRT (Cathode Ray Tube) or the like via the input / output interface 116.
[0151]
【The invention's effect】
  According to the present invention,Double booking in the network can be prevented.
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a conventional network system.
FIG. 2 is a block diagram showing a configuration example of a network system to which the present invention is applied.
FIG. 3 is a block diagram showing a configuration example of a BBS 14 of FIG.
4 is a block diagram illustrating a configuration example of a BBS 34 of FIG.
FIG. 5 is a diagram for explaining the operation of the network system of FIG. 2;
6 is a diagram for explaining the operation of the network system of FIG. 2;
7 is a flowchart for explaining the operation of the network system of FIG. 5; .
FIG. 8 is a flowchart for explaining the operation of the network system of FIG. 5; .
FIG. 9 is a flowchart for explaining the operation of the network system of FIG. 5; .
FIG. 10 is a diagram for explaining the format of a WRITE OPEN command.
FIG. 11 is a diagram illustrating a format of a READ command.
FIG. 12 is a diagram illustrating a format of a CREATE command.
13 is a diagram for explaining subfunction_1 in FIG. 12; FIG.
FIG. 14 is a diagram for explaining the details of subfunction_1 in FIG. 13;
FIG. 15 is a diagram illustrating an example of field values in FIG. 14;
FIG. 16 is a diagram illustrating the format of a WRITE DESCRITOR command. .
FIG. 17 is a diagram illustrating a format of a CLOSE command.
FIG. 18 is a diagram for explaining another operation of the network system of FIG. 2;
FIG. 19 is a block diagram showing a configuration example of a network system to which the present invention is applied.
FIG. 20 is a flowchart for explaining Object ID setting processing;
FIG. 21 is a flowchart for describing SA Event ID setting processing;
FIG. 22 is a block diagram illustrating another configuration example of the network system.
FIG. 23 is a flowchart for explaining the operation of the network system of FIG. 22;
FIG. 24 is a diagram illustrating a BBS format.
FIG. 25 is a diagram for explaining root_object_list_ID in FIG. 24;
FIG. 26 is a diagram for explaining an RSB format.
27 is a diagram for explaining the format of Write Enabled list_specific_information in FIG. 26;
28 is a diagram for explaining the format of board_type in FIG. 27;
FIG. 29 is a diagram for explaining the format of object_entry in FIG. 26;
30 is a diagram for explaining the format of Resource Schedule Entry in FIG. 29. FIG.
FIG. 31 is a diagram for explaining the format of start_time in FIG. 30;
32 is a diagram for explaining the format of Duration in FIG. 30;
33 is a diagram for describing the format of the repeat_type in FIG. 34;
34 is a diagram for explaining the format of repeat_information in FIG. 30. FIG.
FIG. 35 is a diagram for explaining the format of repeat_information in FIG. 30;
36 is a diagram for explaining the format of Info blocks in FIG. 30;
FIG. 37 is a diagram for explaining the format of supported_board_type_specific_information in FIG. 24;
FIG. 38 is a block diagram illustrating a configuration example of a computer.
[Explanation of symbols]
1 IRD, 2 IEEE1394 serial data bus, 3 DVCR, 11 controller, 12 tuner subunit, 14 BBS, 31 controller, 32 analog tuner block, 33 VCR subunit, 34 BBS, 51 RSB, 52 SAB, 61 RSB, 62 SAB

Claims

  When a reservation is made to operate the tuner subunit, which is a functional block of the receiving device itself as a unit, and the VCR subunit, which is a functional block of a recording device connected via a network, Setting means for setting an object ID composed of a unique ID of the receiving device itself and an ID that does not compete with itself for the set reservation;
  Along with the object ID set by the setting means, information related to the reservation of the tuner subunit is stored, and the stored information is disclosed in response to a request from a device connected via the network. 1 storage means;
  Second storage means for storing information for controlling a series of operations relating the tuner subunit and the VCR subunit;
  Control means for storing information relating to reservation of the VCR subunit together with the object ID set by the setting means, in storage means for storing information relating to the reservation of the VCR subunit, which the recording apparatus has
  With
  In the recording device, when storing the information related to the reservation of the VCR subunit, after storing the information related to the reservation using the unique ID portion of the object ID as a temporary temporary number, the unique ID is stored. The temporary number is rewritten with the ID,
  As the series of operations, the tuner subunit extracts a signal of a predetermined channel from a signal input from an antenna and supplies the signal to the VCR subunit via the network, and the VCR subunit includes the tuner subunit. Record the signal supplied from the unit on the recording medium
  Receiver device.

The receiving device according to claim 1, wherein the network is configured using an IEEE1394 serial data bus.

  When a reservation is made to operate the tuner subunit, which is a functional block of the receiving device itself as a unit, and the VCR subunit, which is a functional block of a recording device connected via a network, , For the set reservation, set an object ID consisting of the unique ID of the receiving device itself and an ID that does not conflict within itself,
  Along with the set object ID, information related to the reservation of the tuner subunit is stored in the first storage means, and the stored information is made public in response to a request from a device connected via the network. ,
  Storing information for controlling a series of operations relating the tuner subunit and the VCR subunit in a second storage means;
  The storage unit that stores information related to the reservation of the VCR subunit included in the recording apparatus stores information related to the reservation of the VCR subunit together with the set object ID.
  Including steps,
  In the recording device, when storing the information related to the reservation of the VCR subunit, after storing the information related to the reservation using the unique ID portion of the object ID as a temporary temporary number, the unique ID is stored. The temporary number is rewritten with the ID,
  As the series of operations, a signal of a predetermined channel is extracted from a signal input from an antenna by the tuner subunit and is supplied to the VCR subunit via the network. The signal supplied from the unit is recorded on the recording medium
  Information processing method.

  When a reservation is made to operate the tuner subunit, which is a functional block of the receiving device itself as a unit, and the VCR subunit, which is a functional block of a recording device connected via a network, , For the set reservation, set an object ID consisting of the unique ID of the receiving device itself and an ID that does not conflict within itself,
  Along with the set object ID, information related to the reservation of the tuner subunit is stored in the first storage means, and the stored information is made public in response to a request from a device connected via the network. ,
  Storing information for controlling a series of operations relating the tuner subunit and the VCR subunit in a second storage means;
  The storage unit that stores information related to the reservation of the VCR subunit included in the recording apparatus stores information related to the reservation of the VCR subunit together with the set object ID.
  A program that causes a computer to execute processing including steps is recorded,
  In the recording device, when storing the information related to the reservation of the VCR subunit, after storing the information related to the reservation using the unique ID portion of the object ID as a temporary temporary number, the unique ID is stored. The temporary number is rewritten with the ID,
  As the series of operations, a signal of a predetermined channel is extracted from a signal input from an antenna by the tuner subunit and is supplied to the VCR subunit via the network. The signal supplied from the unit is recorded on the recording medium
  recoding media.