JP4404190B2 - 電子機器、認証使用情報更新方法 - Google Patents

電子機器、認証使用情報更新方法 Download PDF

Info

Publication number
JP4404190B2
JP4404190B2 JP2003278873A JP2003278873A JP4404190B2 JP 4404190 B2 JP4404190 B2 JP 4404190B2 JP 2003278873 A JP2003278873 A JP 2003278873A JP 2003278873 A JP2003278873 A JP 2003278873A JP 4404190 B2 JP4404190 B2 JP 4404190B2
Authority
JP
Japan
Prior art keywords
authentication
data
input
srm
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2003278873A
Other languages
English (en)
Other versions
JP2005045641A (ja
Inventor
象 村越
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2003278873A priority Critical patent/JP4404190B2/ja
Priority to US10/887,978 priority patent/US7587593B2/en
Priority to KR1020040056220A priority patent/KR101088102B1/ko
Priority to EP04017385A priority patent/EP1501255B1/en
Publication of JP2005045641A publication Critical patent/JP2005045641A/ja
Application granted granted Critical
Publication of JP4404190B2 publication Critical patent/JP4404190B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Small-Scale Networks (AREA)
  • Storage Device Security (AREA)

Description

本発明は、所定の通信フォーマットによるデータバスを介して他の機器と相互通信可能に接続することのできる電子機器、及びこの電子機器において外部電子機器との認証処理に用いる認証使用情報の更新方法に関するものである。
近年、デジタルデータインターフェイスとして、IEEE(Institute of Electrical Engineers)1394データインターフェイスが知られている。IEEE1394データインターフェイスは、例えばSCSIなどよりもデータ転送レートが高速であり、周知のように、所要のデータサイズを周期的に送受信することが保証されるIsochronous通信が可能とされる。このため、IEEE1394データインターフェイスは、AV(Audio/Video)などのストリームデータをリアルタイムで転送するのに有利とされている。
このような技術を背景として、各種デジタルAV機器やパーソナルコンピュータ装置等の電子機器を、例えばIEEE1394等のデータインターフェイス規格に従ったデータバスを介して相互に接続することで、機器間でAVデータを送受信できるようにしたAVシステムが提案されている。
上記したAVシステムとしては、例えばアンプ機器を中心として、これに例えばCDプレーヤ、DVDプレーヤのほか、ビデオ機器などの各種AVソース出力機器をデータバスを介して接続することで、例えばいわゆるコンポーネント的なシステムを構築することが考えられる。
このようなAVシステムにおけるアンプ機器の役割としては、データバスを介してAVソース出力機器から送信されるAVソース情報を入力して、最終的には音声信号としてスピーカなどに出力することになる。このために、アンプ機器としては、例えばデータバス上に存在する複数のAVソース出力機器のうちから、1つのAVソース出力機器を選択的に入力するための機能を有することになる。つまり入力ソース選択機能を有する。これは、例えばユーザがアンプ機器に対して行った入力ソースの選択操作に応じて、その選択操作により指定されるAVソース出力機器とデータバス上での論理的な相互接続関係を確立することで実現される。
特開平11−259971号公報
ところで、AV機器やデータネットワークシステムの発展により、デジタルデータの複製や伝送が容易となることに伴って、音楽や映像などのデジタルデータコンテンツについての著作権保護が大きな問題となってきている。
このためコンテンツデータの著作権保護のために、データの暗号化、機器接続時の機器間の認証、著作権保護に不適切な機器の排除方式など、多様な技術が提案、実施されている。
例えば上記特許文献1には、著作権保護のための認証を行う技術が開示されている。
上記したIEEE1394による機器間の接続の際にも、特にオーディオデータやビデオデータの伝送が行われる機器間においては、機器同士の認証処理によって互いに正当な機器(例えば正しい著作権保護機能を備えるものとしてライセンスされた機器)であることの認証が行われることを条件としてデータ伝送等が可能とされることなどが行われている。
この認証処理には所定の情報(説明上、認証使用情報という)が用いられ、この認証使用情報は、各機器が記憶保持しているものであるが、認証条件の変更や不適切機器としてのいわゆるブラックリスト情報の追加などの事情で、認証処理に用いる認証使用情報は適宜更新されるべきものである。
従って、各電子機器は適宜認証使用情報を更新する処理を行うことが必要になる。
また、各電子機器に著作権保護機能を効果的に発揮させるには、認証使用情報がなるべく迅速に最新のバージョンに更新されるようにする必要がある。このためには、各電子機器に認証使用情報が入力される機会を多くすることが好ましい。即ち多様な入力形態で認証使用情報が入力されるようにすることで、各電子機器において認証使用情報を更新できる機会を増やす。
しかしながら、入力形態を多様化すれば、例えば複数の経路で異なる認証使用情報が入力されるなどで装置内での更新処理が混乱を来したり、古いバージョンの認証使用情報が入力される場合もあるなどの事態も考えられるため、単に認証使用情報が入力されることに応じて、装置内に記憶している認証使用情報を更新していくのでは、適切な更新処理が実現できないおそれがある。
本発明はこのような事情に応じて、認証使用情報の入力機会を増加させ、電子機器がなるべく最新の認証使用情報を記憶できるようにするとともに、その更新処理として適切な動作が行われるようにすることを目的とする。
このため本発明の電子機器は、データバスを介して接続される外部電子機器と通信する通信手段と、上記通信手段で接続された上記外部電子機器との間で認証処理を行って通信状態を確立する認証手段と、上記認証処理において利用する情報である認証使用情報を記憶する認証使用情報記憶手段と、上記認証使用情報を入力する認証使用情報入力手段と、上記通信手段及び上記認証使用情報入力手段のそれぞれから入力される上記認証使用情報を、その入力経路毎に記憶するバッファメモリ手段と、上記バッファメモリ手段に入力経路毎に記憶された新たな認証使用情報について、情報内容についての正当性及びバージョン情報を判別し、その認証使用情報が正当なものと判別され、かつ、その認証使用情報が上記認証使用情報記憶手段に記憶されている認証使用情報よりも新しいバージョンであると判別されるとき、その認証使用情報を新たな認証使用情報として、上記認証使用情報記憶手段に記憶されている認証使用情報を更新する更新制御手段とを備える。
上記認証使用情報入力手段は、記録媒体に対する読出部とされ、記録媒体に対する読出動作によって読み出された上記認証使用情報を入力する。
また上記認証使用情報入力手段は、上記通信手段における所定の通信フォーマットとは異なる通信フォーマットによって接続された外部電子機器と通信可能な通信部とされ、該外部電子機器から送信される上記認証使用情報を入力する。
また上記認証使用情報入力手段は、無線信号受信部とされ、外部電子機器から無線送信されてきた上記認証使用情報を受信して入力する。
また、外部電子機器に対して送信出力を行う送信手段を更に備え、上記更新制御手段は、上記バッファメモリ手段に記憶された認証使用情報を新たな認証使用情報として上記認証使用情報記憶手段に記憶されている認証使用情報を更新する際に、その新たな認証使用情報を上記送信手段により上記外部電子機器に送信出力させる。
本発明の認証使用情報更新方法は、所定の通信フォーマットによるデータバスを介して接続される外部電子機器との間で認証処理を行って通信状態を確立する電子機器における、上記認証処理の際に用いる認証使用情報の更新方法であって、各種入力経路から入力される上記認証使用情報を、その入力経路毎にバッファリング記憶し、各入力経路毎にバッファリング記憶された上記認証使用情報の情報内容についての正当性及びバージョン情報を判別し、その認証使用情報が正当なものと判別され、かつ、その認証使用情報が所定の記憶手段に記憶されている認証使用情報よりも新しいバージョンであると判別されるとき、上記バッファリング記憶された認証使用情報を新たな認証使用情報として、上記所定の記憶手段に記憶されている認証使用情報の更新を行う。
上記入力経路の1つは、記録媒体に対する読出動作によって上記認証使用情報が読み出されて入力される入力経路である。
また上記入力経路の1つは、上記所定の通信フォーマットとは異なる通信フォーマットによって接続された外部電子機器から上記認証使用情報が送信されてくる入力経路である。
また上記入力経路の1つは、外部電子機器から無線送信されてきた上記認証使用情報を受信して入力する入力経路である。
また、上記バッファリング記憶された認証使用情報を新たな認証使用情報として、上記認証処理に用いる認証使用情報の更新を行う際に、上記新たな認証使用情報を外部電子機器に対して送信出力する。
以上のような本発明によれば、多様な入力形態(入力手段、入力経路)で認証使用情報が入力されることで、電子機器において認証使用情報を更新できる機会を増やすことができる。そしてその上で、各入力経路から入力された認証使用情報は、入力経路毎に一旦バッファリングされ、正当性やバージョンを判別された上で、更新処理に供されるため、入力データの混乱や、不必要もしくは不適切な更新は行われない。
本発明によれば、多様な入力形態(入力手段、入力経路)で、例えば後述するSRMのような認証使用情報が入力されることで、電子機器において認証使用情報を更新できる機会を増やすことができ、しかもその上で、各入力経路から入力された認証使用情報は、一旦バッファリングされ、正当性やバージョンを判別された上で、更新処理に供されるため、不必要な更新や不適切な更新は行われない。従って、電子機器においてはSRM等の認証使用情報を適切且つ早い時点でバージョンアップしていくことができ、これによって著作権保護のための認証処理も適切に実行できる。換言すれば常に適切な著作権保護機能を発揮できる電子機器とすることができる。
また、電子機器において記録媒体に対する読出動作によって読み出された認証使用情報が入力されるようにしている。すると認証使用情報の発行者側は、音楽や映像のコンテンツ等を記録したディスク等のメディアに認証使用情報を記録することで、認証使用情報の更新機会を与えることができ、また電子機器側では記録媒体の再生の際に更新機会を得ることができる。
もちろん認証使用情報の更新のための専用の記録媒体をディスクやICカード、メモリカード、その他の形態で電子機器に提供し、電子機器側で認証使用情報を読み出して更新機会を得ることも可能である。
即ち記録媒体によって認証使用情報が提供されることで更新機会を増加できる。
また認証処理を行う所定の通信フォーマットとは異なる通信フォーマットによって接続された外部電子機器から認証使用情報が入力されることも、更新機会の増加を実現する。
また、認証処理を行う所定の通信フォーマットとは異なる通信フォーマットによって認証使用情報が入力されることは、認証使用情報の提供を上記所定の通信フォーマット以外の通信系でも実行できるものとなることを意味する。例えば認証使用情報の書込装置として、電子機器に認証使用情報を送信する装置を考えた場合、その認証使用情報の書込装置の通信フォーマット形態は限定されないことになる。従って、多様な装置、例えば他の通信フォーマットによる既存の装置などを書込装置として適用でき、また書込装置の設計/製造の自由度が高くなる。
また、電子機器において、外部機器から無線送信されてきた認証使用情報を受信して入力するようにすることで、電子機器においては更新機会が増加するとともに、赤外線や電波により認証使用情報を出力する書込装置を実現できる。また放送等の手法により認証使用情報を電子機器に入力させることも可能となる。
さらに、これらのように多様な経路で認証使用情報が入力され、更新されることは、工場出荷時の認証使用情報の書込も容易となり、また効率化できる。即ちSRMデータのような認証使用情報の書き込みのために、IEEE1394バス対応のパーソナルコンピュータ等を用いることは必ずしも必要ではなくなり、従って書込装置の多様化、ひいては書込作業の効率化が実現できる。例えば無線書込装置で多量の装置に対して認証使用情報を書き込んだり、或いは認証使用情報を記録したディスク等を装填するなどの手法で更新させることで実質的に書込装置を不要としたりすることが可能となる。
また、電子機器において認証使用情報を更新する際に、その新たな認証使用情報を送信出力することで、周辺の外部機器にも新たな認証使用情報を入力させることができる。即ち当該電子機器が認証使用情報の書込装置として機能する。これによって周辺機器で一様に最新バージョンへの更新が可能となり、適切な著作権保護が実施される。
以下、本発明の実施の形態について説明する。説明は次の順序で行う。

1.AVシステム
1−1 全体構成
1−2 STR(フロントパネル)
1−3 STR対応ディスクドライブ(フロントパネル)
1−4 STR(内部)
1−5 STR対応ディスクドライブ(内部)
2.IEEE1394による本実施の形態のデータ通信
2−1 概要
2−2 スタックモデル
2−3 信号伝送形態
2−4 機器間のバス接続
2−5 パケット
2−6 トランザクションルール
2−7 アドレッシング
2−8 CIP(Common Isochronous Packet)
2−9 コネクションマネージメント
2−10 FCPにおけるコマンド及びレスポンス
2−11 AV/Cコマンドパケット
3.SRM
4.SRMの入力/更新処理
4−1 入力/更新処理系の構成
4−2 初期処理
4−3 SRM入力処理
4−4 SRM更新処理
4−5 SRM入力経路例
4−6 更新時のSRM送信処理

1.AVシステム
1−1 全体構成

図1は本発明の実施の形態の電子機器を含む電子機器システムの構成例を示している。
この電子機器システムは、複数のAV機器等をIEEE1394インターフェイスのデータバスにより相互通信可能に接続することで構築される。
図1においては、AVシステムを構成する機器として、STR(Stereo Tuner Receiver)60と、STR対応ディスクドライブ30、同一メーカ機器100、他社メーカ機器110が示される。
STR60は、図1に示すAVシステムの中心として機能するもので、主としてチューナ機能、外部ソース入力選択機能、及びアンプ機能を備えており、例えば図のようにして5チャンネルステレオ音声に対応するスピーカSP(FL)、SP(FR)、SP(SL)、SP(SR)、SP(C)を接続することができるようになっている。
スピーカSP(FL)はフロント左チャンネルスピーカ、スピーカSP(FR)はフロント右チャンネルスピーカ、スピーカSP(SL)はサラウンド左チャンネルスピーカ、スピーカSP(SR)はサラウンド右チャンネルスピーカ、スピーカSP(C)はセンターチャンネルスピーカである。
なお、例えばサブウーハスピーカを追加していわゆる5.1チャンネルスピーカシステムとするなど、他のスピーカ構成も可能である。
詳しい構成は後述するが、STR60では、内部のチューナ部で受信した放送信号と、アナログオーディオ信号入力と、デジタルオーディオ信号入力と、さらにIEEE1394バス116を介して外部から入力される複数のオーディオソースについて選択を行い、最終的には、これを音声としてスピーカSPから出力させることができるように構成されている。
また、この図には、STR60に対する操作を行うためのリモートコントローラRMも示されている。STR60は、このリモートコントローラRMに対して行われた操作に応じて送信されてくる操作コマンド信号を受信し、その操作コマンド信号の内容に応じた所要の動作を実行する。なお、この図では、STR60に対応するリモートコントローラRMのみが示されているが、実際としては、他の機器についてもリモートコントローラによる操作が可能とされていてよいものである。
また、上記STR60と共に接続することで利便性の高い各種のシステム機能を実現することのできる機種として、ここではSTR対応ディスクドライブ30が示されている。STR対応ディスクドライブ30は、例えばSTR60と同一メーカ品とされる。
STR対応ディスクドライブ30は、例えばCD(Compact Disc)、SACD(Super Audio CD)、DVD(Digital Versatile Disc)のそれぞれについて対応可能なディスクプレーヤとしての機能を有しており、装填されたディスクについての再生を行う。
そして、ディスクから再生して得られるオーディオデータを、IEEE1394バス116を介して送信出力することが可能とされる。
なお公知のように、CDから再生されるオーディオデータは、サンプリング周波数44.1KHz、16ビット量子化のリニアPCMデータである。
またDVDが再生される場合は、オーディオデータだけでなくビデオデータが再生される場合があり、従ってSTR対応ディスクドライブ30はビデオデコード機能も備えている。図1には示していないが、例えばCRT、液晶その他の表示デバイスがSTR対応ディスクドライブ30に接続されることで、DVDから再生された映像を表示出力することができる。
SACDは、ΣΔ変調を用いた1ビットデジタルオーディオ信号方式(DSD:Direct Stream Digital)を用いたメディアである。このDSD信号は、CDのサンプリング周波数fs(fs=44.1KHz)の64倍という高いサンプリング周波数による1ビット量子化のデジタルオーディオデータであり、可聴周波数帯域を越えた信号再生を可能としている。
このようなSACDに対応するために、STR対応ディスクドライブ30はDSD信号対応のデコード機能を有する。
このようなSTR対応ディスクドライブ30が、IEEE1394バス116によりSTR60と接続されることで、CD、DVD、SACDの再生出力をSTR60に接続されているスピーカシステムにより実行することが可能となる。
同一メーカ機器100は、STR60、STR対応ディスクドライブ30と同一メーカとされて、IEEE1394インターフェイスに対応した通信機能を有するデジタルAV機器である。ここでの同一メーカ機器100の実際としては、特に言及しないが、例えばCDプレーヤ、MDレコーダ/プレーヤや、デジタルVTRなどとされればよいものである。
この同一メーカ機器100としては、例えばSTR対応ディスクドライブ30、及びSTR対応MD機1などと比較した場合には、特にSTR60を中心とするシステムコンポーネント機能が与えられるようには構成されていない点が異なる。
ただし、メーカ内のみで有効となるコマンド(Vender Dependent Commandといわれる)の送受信によっては、STR60、STR対応ディスクドライブ30、STR対応MD機1と共に、そのメーカで規定した特定の機能を有するように動作することが可能とされるものである。
また、例えばSTR60に対して、この同一メーカ機器100から送信されてくるオーディオソースとしてのデータを選択して受信入力するようにマニュアル操作を行えば、これを音声としてモニタしたり、或いは録音することなどが可能である。
他社メーカ機器110もまたIEEE1394インターフェイスに対応した通信機能を有する何らかのデジタルAV機器であるが、STR60、STR対応ディスクドライブ30とは製造メーカが異なる。ここでの他社メーカ機器110の実際としても、CDプレーヤ、MDレコーダ/プレーヤや、デジタルVTRなどとされればよい。ただし、この他社メーカ機器110の場合には、原則として上記したSTR60のメーカで規定するVender Dependent Commandには対応不可となる。
なお、ここでは図示していないが、例えばこの図1に示す各AV機器としては、それぞれが商用交流電源から電力を入力するための電源コンセントが備えられる。もしくは、バッテリ駆動可能な構成であればバッテリを収納可能とされている。つまりは、各機器がそれぞれ独立して電力を得ることが可能とされているものである。
1−2 STR(フロントパネル)

続いて、上記図1に示したシステムを構成する上で主となる、STR60と、このSTR60とコンポーネント的システムを組むSTR対応ディスクドライブ30の外観構成として、各々のフロントパネル部位について説明しておく。
図2はSTR60本体のフロントパネル部位の様子を示している。
フロントパネル左下側には、電源キー120が設けられている。この電源キー120を操作することで、STR60は、電源のオン/オフが切り換わるようにされている。なお、ここでいう電源がオフの状態とは、スタンバイ電源は動作しているいわゆるスタンバイ状態を指しているもので、例えば商用交流電源(又はバッテリ)の供給が絶たれている状態とは異なる。この点では、以降説明する、STR対応ディスクドライブ30についても同様とされる。
また、ここでの詳しい説明は省略するが、STR60では、スリープ状態とするためのスリープモードも用意されていることで、省電力化が考慮されている。
また、電源キー120の左側にはヘッドフォンジャック86が設けられている。
フロントパネルのほぼ中央部には、表示部87が配置されている。
この場合の表示部87としては、主として文字表示を行うためのFL管表示部87Aが設けられており、ここでは、1行14文字分の表示が行われるようにされている。そして、その周囲にはセグメント表示部87Bが設けられており、図示してはいないが所定の決められた内容がセグメントによって表示される。
表示部87の左側にはディスプレイキー127が設けられる。
ディスプレイキー127は、基本的には表示部75における表示内容を変更するためのものとされる。
また、FL管表示部87Aの右側には、ジョグダイヤル125と、その上側にチューニングモードキー121、チューナキー122、ファンクション/メニューキー123、エンターキー124が示される。
チューニングモードキー121、チューナキー122は、STR60のチューナ機能に関連するキーであり、それぞれ、受信バンド、チューナモードの切り換えを行うときに使用する。
また、ファンクション/メニューキー123は、ファンクション選択やメニュー選択を行うためのキーとされ、エンターキー124は決定操作を行うときに使用される。
そして、ジョグダイヤル125は、所定の操作手順のもとで上記各キーと共に併用されるもので、これによりユーザは実際の各種操作を行うことができる。
一例として、ファンクション/メニューキー123を1回押圧操作するごとに、FL管表示部87Aの表示内容は、FUNCTION→SOUND→SETUPのようにしてトグルで変化する。
そして例えば、FL管表示部87AにFUNCTIONと表示させた状態でジョグダイヤル125を回転操作すると、STR60が入力してモニタ音声として出力するソースの選択を変更していくことができるようになっている。このときのFL管表示部87Aには、ジョグダイヤル125の回転操作に応じて現在選択されている入力ソース名が表示されるようになっている。この操作によっては、例えばチューナ音声、アナログ入力、光デジタル入力、及びIEEE1394バスを介して入力される各ソース(機器)を所定順序に従って順次選択していくことが可能とされる。
なお、例えばチューニングモードキー121、チューナキー122、ファンクション/メニューキー123、エンターキー124などのキーは、その背面側に装飾用のLEDが設けられており、動作状態等に応じて点灯、点滅などするようにもされている。
ボリュームジョグ126は、STR60から出力される音声信号レベル、つまり、例えばスピーカSPから出力される音量を調整するためのダイヤルキーとして備えられる。
1−3 STR対応ディスクドライブ(フロントパネル)

図3は、STR対応ディスクドライブ30のフロントパネル部位を示している。
先ず、このSTR対応ディスクドライブ30のフロントパネル左下側においても、電源オン/オフ(スタンバイ)のための電源キー150が設けられている。
また、このSTR対応ディスクドライブ30のフロントパネルの中央上部には、CD、SACD、DVDとしてのディスクを挿入/排出するためのディスク挿脱部159が設けられている。例えばディスク挿脱部159内に収納されて装填されている状態にあるCD等を排出させるためには、このディスク挿脱部159の右側に配置されるイジェクトキー151を操作する。
上記ディスク挿脱部159の下側には、例えば1行14文字分の表示が可能なFL管表示部47Aと、セグメント表示部47Bとから成る表示部47が設けられている。この場合、FL管表示部47Aに対しては、例えば現在装填されているCD等にて再生されるトラックのトラックナンバ、再生時間等の再生状況を示す情報や、CD等のディスクに記録されているテキストデータなどが文字等として表示される。また、セグメント表示部47Bには再生モードなどが示される。
FL管表示部47Aにおける表示内容の切り換えは、表示部47の左側に配置されるディスプレイキー156を操作することによって行うことができる。
また、フロントパネル上の右側には、CDの再生に関するキーとして、再生/一時停止キー152、停止キー153,頭出し・早送り/早戻しキー154,155が設けられている。
またフロントパネル上の左側には、HATSキー157が設けられる。HATSキー157は、HATS機能をオン/オフする操作キーである。
HATS(High quality digital Audio Transmission System)とは、伝送クロックのジッタの影響によるデジタルオーディオ信号品質の低下を防止する機能である。
例えばSTR対応ディスクドライブ30からSTR60に対してIEEE1394バス116によりオーディオデータを伝送する際に、伝送クロックのジッタによりSTR60側では受信したオーディオデータに時間軸方向の揺らぎが発生する。そこで、STR60側では、受信したオーディオデータを伝送クロックに基づいて一旦バッファメモリに蓄積し、それを水晶系のクロックに基づいて読み出すことにより、オーディオデータの時間軸方向の揺らぎを解消するものである。 このHATS機能がオンの場合、STR対応ディスクドライブ30とSTR60の間ではフロー制御のための信号のやりとりが行われるものとなる。
ここで、上記図2、図3に示すフロントパネルの様子からも分かるように、STR60、STR対応ディスクドライブ30は、それぞれが、自機のための表示部75,47を有している。換言すれば、例えばSTR及びSTR対応機器から成るシステムを、1つのオーディオコンポーネントシステムとして考えた場合、このコンポーネントシステムとして統合された表示部位というものは設けられてはいないことになる。これは、例えばIEEE1394を介して接続される機器としては、本来、個々に独立した存在であることに対応している。
1−4 STR(内部)

続いて、STR60、STR対応ディスクドライブ30の各内部構成について説明する。
先ず、図4のブロック図にはSTR60の内部構成例が示されている。
STR60においては、オーディオソースとして、IEEE1394バス116を介して送信されてくるオーディオ信号と、自身が備えるチューナのオーディオ信号と、光デジタル入力端子67から入力される外部デジタルオーディオ信号と、アナログ入力端子78から入力される外部アナログオーディオ信号との4種を入力可能とされる。
IEEE1394インターフェイス61は、IEEE1394バス116を介して他の外部機器とデータの送受信を行うために設けられる。これにより、STR60としては、外部とのAVデータの送受信、及び各種コマンドの送受信が可能に構成されることとなる。
IEEE1394インターフェイス61では、IEEE1394バス116を介して受信したパケットを復調し、復調したパケットに含まれるデータを抽出する。そしてこの抽出したデータを内部データ通信に適合するフォーマットのデータに変換して出力する。
例えばIEEE1394バス116を介して他のAV機器からオーディオデータが送信されてくるとする。IEEE1394インターフェイス61では、この送信されてきたオーディオデータを受信して、上記パケットに対する復調処理を行う。
そして、送信元の機器をSTR対応ディスクドライブ30として考えた場合などにおいて、CD、DVDの再生データが受信された場合には、例えばIEC60958といわれるデジタルオーディオデータインターフェイスフォーマットのオーディオデータTD1に変換して出力する。
この場合、オーディオデータTD1は復調処理部66に供給される。復調処理部66においては、入力されたオーディオデータTD1について、例えばIEC60958フォーマットに従った所要の復調処理を施して、例えばリニアPCMデータ(PCM1)としてPCMセレクタ69に出力する。
なお、光デジタル入力端子67から入力される外部デジタルオーディオ信号も例えばIEC60958フォーマットのデータとされており、この光デジタル入力端子67からの入力の場合も、復調処理部66で復調されてリニアPCMデータ(PCM1)としてPCMセレクタ69に供給される。
IEEE1394インターフェイス61において、IEEE1394バス116を介してSACDの再生データが受信された場合には、IEEE1394インターフェース61は、パケット復調処理を行って、64fs、ΣΔ変調による1ビット量子化のDSD信号TD3を出力する。
DSD信号TD3はデシメーションフィルタ65に供給され、デシメーションフィルタ65によってリニアPCMデータ(PCM3)に変換されてPCMセレクタ69に供給される。
PLL63は伝送クロックに基づいてパケット復調処理のクロックを生成する。上述したHATS機能オフの場合は、PLL63で生成されたクロックに基づくDSD信号TD3、IEC60958データTD1が出力される。
RAM62はIEEE1394インターフェース61における送受信データバッファとして機能する。
クロック発振器64は水晶系のクロックを発生させる。
上述したHATS機能がオンとされている場合において、CD,DVDの再生データがIEEE1394インターフェース61に受信された場合は、そのデータは一旦RAM62に書き込まれた後、クロック発振器64からの水晶系のクロックに基づいて読み出される。特にIEEE1394インターフェース61はIEC60958データに対する復調機能も備えており、このHATSオンの場合は、RAM62から読み出されたデータに対して復調を行い、リニアPCMデータ(PCM2)として出力し、これをPCMセレクタ69に供給する。
またHATS機能がオンとされている場合において、SACDの再生データがIEEE1394インターフェース61に受信された場合も、そのデータは一旦RAM62に書き込まれた後、クロック発振器64からの水晶系のクロックに基づいて読み出される。この場合、読み出されたDSD信号TD3はデシメーションフィルタ65に供給され、デシメーションフィルタ65によってリニアPCMデータ(PCM3)に変換されてPCMセレクタ69に供給される。
チューナ部77は、STR60内に備えられており、アンテナ76にて受信されたラジオ放送の電波について、選局及び復調処理等を行って例えばアナログ音声信号としてセレクタ79に出力する。
また、アナログオーディオ信号入力端子78を介して入力されるアナログ音声信号もまたセレクタ79に対して入力される。
セレクタ79では、例えばシステムコントローラ70の制御に応じて、チューナ部77とアナログオーディオ信号入力端子78の何れかを入力ソースとして選択して、選択したアナログオーディオ信号をA/D変換器68に対して供給する。A/D変換器68では入力されてきたアナログオーディオ信号をリニアPCMデータ(PCM4)に変換してPCMセレクタ69に供給する。
PCMセレクタ69では、システムコントローラ70の制御に応じて、PCM1,PCM2,PCM3,PCM4として示した各リニアPCMデータを選択する。即ち入力ファンクション切換となる選択である。
PCMセレクタ69で選択されたリニアPCMデータはオーディオデコーダ80に供給される。
このオーディオデコーダ80は、DSP(Digital Signal Processor)により形成され、オーディオデータに対して各種所要の信号処理やスピーカチャンネル分離などが行われる。
さらにオーディオデコーダ80の出力はストリームプロセッサにおいてイコライジング処理その他の音場処理等が行われる。そしてこれら所要の信号処理が施された、例えば5チャンネル等のオーディオデータは、D/A変換器82おいてアナログオーディオ信号とされ、パワーアンプ部83で増幅処理される。
パワーアンプ部83で処理された音声信号は、STR80におけるスピーカ接続端子84に接続されたスピーカ部SPに供給され、音声として出力される。なお、このスピーカ部SPは図1に示したスピーカSP(FL)、SP(FR)、SP(SL)、SP(SR)、SP(C)に相当し、図示は省略したがスピーカ接続端子84は、各スピーカに対応して設けられる。
またパワーアンプ部83の出力はヘッドホンジャック86にも供給され、ヘッドホン出力が可能とされる。
ところで、STR60に入力されたオーディオデータをIEEE1394バス116により外部機器に出力する場合、オーディオデコーダ80から出力されたデータがセレクタ85を介してIEEE1394インターフェース61に供給されるようになされる。或いは復調処理部66の出力がセレクタ85を介してIEEE1394インターフェース61に供給される。
この場合、IEEE1394インターフェース61に供給されるデータは、例えばIEC60958などのデジタルオーディオデータインターフェイスのフォーマットに適合する変調処理がされている形態のものとなる。
IEEE1394インターフェース61は、このように供給されたデータについて、例えばRAM62を利用して、パケット化をはじめとする所要の処理を施して、IEEE1394フォーマットに適合するフォーマットに変換する。そして、IEEE1394バス116を介して、目的の機器に対して送信出力を行う。
システムコントローラ70は、例えばCPU(Central Processing Unit)を備えて構成され、STR60の全体についての各種動作制御を実行する。
システムコントローラ70は、ユーザーの操作やユーザーに対する表示出力に対応する制御を行う。即ち受信部89及び操作部88からの情報が入力される。例えば受信部89においては、リモートコントローラRMから送信されてきた無線のコマンド信号を受信し、この受信したコマンド信号がシステムコントローラ70に供給される。
操作部88は、例えば図2のようにフロントパネルに設けられている各種キーより成るものとされ、この操作部88に対して行われた操作に応じた操作情報がシステムコントローラ70に供給される。
システムコントローラ70では、上記のようにして入力されてくるコマンド信号及び操作情報に応答した所要の動作が得られるように、各種制御処理を実行する。
また、システムコントローラ70は、例えば上記したコマンド信号及び操作情報や、現在の動作状況等に応じた所要の内容の表示が行われるように、表示部87に対する表示制御を実行する。この表示部87は、前述もしたように、例えばFL管表示部87Aとセグメント表示部87Bとを備えている。
またシステムコントローラ70は、IEEE1394インターフェース61に対する制御を行い、IEEE1394バス116による通信動作を制御する。また後述するSRM関連の処理なども行う。
プログラムメモリ73には、このSTR60における各種動作を実現するためのプログラム等が格納される。
NV−RAM(不揮発性メモリ)74は電源オフ時にもデータ保持が可能な記憶領域であることから、設定された各種制御定数や、後述するSRMデータなどが格納される。
RAM75はシステムコントローラ70が各種処理を実行するのに必要なデータなどが適宜保持されたり、ワーク領域等に使用される。
なお、NV−RAM74、RAM75、プログラムメモリ73はシステムコントローラ70としてのチップ内部の記憶領域として形成されてもよいし、別体のチップとされてもよい。
また、IEEE1394インターフェイス61では、外部装置から送信されてくるコマンドやレスポンス等のデータを受信すること、或いは外部装置に対してコマンドやレスポンスを送信することも行う。システムコントローラ70は、このコマンドやレスポンスの送受信処理についても必要な処理を実行する。
1−5 STR対応ディスクドライブ(内部)

次にSTR対応ディスクドライブ30の内部構成について図6のブロック図を参照して説明する。
CD,SACD,DVD等のディスク91は、前述した本体フロントパネルのディスク挿脱部159から挿入されることで、再生可能位置に装填される。
再生可能位置に装填されたディスク91は、CD再生動作時においてスピンドルモータ31によって一定線速度(CLV)で回転駆動される。そして光学ヘッド32によってディスク91にピット形態(エンボスピット、相変化ピット、色素変化ピット等)で記録されているデータが読み出され、RFアンプ35に供給される。光学ヘッド32において対物レンズ32aは2軸機構32bによって保持され、トラッキング及びフォーカス方向に変位可能とされる。
また光学ヘッド32はスレッド機構34によってディスク91の半径方向に移動可能とされる。
RFアンプ35では再生RF信号のほか、フォーカスエラー信号、トラッキングエラー信号を生成し、これらのエラー信号はサーボ回路36に供給される。
サーボ回路36はフォーカスエラー信号、トラッキングエラー信号から、フォーカス駆動信号、トラッキング駆動信号、スレッド駆動信号等の各種駆動信号を生成し、2軸機構32b、及びスレッド機構34の動作を制御する。つまり、フォーカスサーボ制御及びトラッキングサーボ制御を実行する。
また、RFアンプ35において二値化された再生RF信号は、タイミングジェネレータ40に対しても出力されており、タイミングジェネレータ40においては、この再生RF信号の波形タイミングに基づいて、タイミング信号を生成してCLVプロセッサ41に対して出力する。CLVプロセッサ41では、入力されたタイミング信号に基づいて、スピンドルモータ31を所要のCLV速度により回転制御するための駆動信号を生成してスピンドルモータに供給する。これにより、ディスク91をCLVにより回転駆動するためのスピンドルサーボ制御が実行される。
またサーボ回路36,タイミングジェネレータ40に対しては、スピンドル起動/停止、各サーボ整定、トラックジャンプ、アクセスその他の必要処理を行うようにシステムコントローラ50が制御を行う。
再生RF信号はDSDデコーダ37、AVデコーダ38に供給される。
CD、DVDの再生時にはAVデコーダ38が機能するように、またSACDの再生時にはDSDデコーダ37が機能するように、システムコントローラ50によって制御される。
AVデコーダ38は、CDから再生され2値化された再生信号(EFM信号)に対してEFM復調,エラー訂正デコード、デスクランブル等を行なう。またDVDから再生され2値化された再生信号(EFM+変調信号)に対してEFM+復調,エラー訂正デコード、デスクランブル等を行なう。
これらによって例えば16ビット量子化、44.1KHz サンプリングのフォーマットのオーディオデータにデコードを行い、IEEE1394インターフェース39に供給する。
また、AVデコーダ38は、ビデオデコーダとしての機能も備え、DVD再生時にはビデオ信号のデコードも行う。デコードされたビデオ信号は、ビデオ出力端子53から図示していない映像モニタ装置に供給され、映像出力される。
DSDデコーダ37は、SACDから再生され2値化された再生信号からDSD信号をデコードする。DSD信号はIEEE1394インターフェース39に供給される。
なお、SACDは記録面が2層構造のディスクとされ、一方の層はDSD方式のデータ、他方の層はCD方式のデータが記録されるものもある。CD方式のデータが記録された層が再生される場合は、そのデコード処理はAVデコーダ38において行われることになる。
またAVデコーダ38、DSDデコーダ37ではサブコード等の制御データも抽出可能な構成を採っている。
また、例えばディスク91のリードインエリアに例えばサブコード形態で記録されているTOC(Table Of Contents)情報を抽出することも行われる。これらのサブコードデータ、TOCはシステムコントローラ50に供給されることで、例えば各種制御に用いられる。
また、RFアンプ35にて二値化された再生RF信号は、PLL回路55に対しても供給される。
PLL回路55は、入力されたEFM信号のチャンネルビットに同期したクロックを出力する。このクロックは、例えばDSDデコーダ37及びAVデコーダ38以降の信号処理回路系のクロックとして利用される。
デコードされIEEE1394インターフェイス39に入力されたオーディオデータは、IEEE1394のフォーマットに適合するデータに変換され、IEEE1394バス116を介して外部機器に対して送信出力される。
なお、図示していないが、デジタルインターフェース及び光デジタル出力端子を設け、AVデコーダ38又はDSDデコーダ37から出力されるオーディオデータがデジタルデータ出力されるようにしてもよい。
また、D/A変換器、アナログ出力端子を設けて、デコードされたオーディオデータをアナログ音声信号に変換して、外部機器に出力するようにしてもよい。
システムコントローラ50は、CPUを備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
ディスク91の再生時には、ディスク91に記録されている管理情報、即ちTOCを読み出す必要がある。システムコントローラ50はこの管理情報に応じてディスク91に収録されたトラック数、各トラックのアドレスなどを判別し、再生動作制御を行うことになる。このためシステムコントローラ50はディスク91が装填された際にTOCが記録されたディスクの最内周側(リードインエリア)の再生動作を実行させることによって読み出し、前述のようにしてTOC情報を抽出する。そして、このTOCを例えば内部のRAMなどに記憶させておき、以後そのディスク91に対する再生動作の際に参照できるようにしている。
また、システムコントローラ50は、ユーザーの操作やユーザーに対する表示出力に対応する制御を行う。即ち受信部45及び操作部48からの情報が入力される。例えば受信部45においては、リモートコントローラRMから送信されてきた無線のコマンド信号を受信し、この受信したコマンド信号がシステムコントローラ50に供給される。
操作部48は、例えば図3のようにフロントパネルに設けられている各種キーより成るものとされ、この操作部48に対して行われた操作に応じた操作情報がシステムコントローラ50に供給される。
システムコントローラ50では、上記のようにして入力されてくるコマンド信号及び操作情報に応答した所要の動作が得られるように、各種制御処理を実行する。
また、システムコントローラ50は、例えば上記したコマンド信号及び操作情報や、現在の動作状況等に応じた所要の内容の表示が行われるように、表示部47に対する表示制御を実行する。
例えば表示部47にはディスクの総演奏時間、再生や録音時の進行時間などの時間情報や、トラックナンバ、ディスクネームやトラックネームなどのネーム情報、動作状態、動作モードなどの各種の表示が行なわれる。
この表示部47は、前述もしたように、例えばFL管表示部47Aとセグメント表示部47Bとを備えている。
またシステムコントローラ50は、IEEE1394インターフェース39に対する制御を行い、IEEE1394バス116による通信動作を制御する。また後述するSRM関連の処理なども行う。
プログラムメモリ42には、システムコントローラ50が、このSTR対応ディスクドライブ30における各種動作を実現するためのプログラム等が格納される。
NV−RAM(不揮発性メモリ)43は電源オフ時にもデータ保持が可能な記憶領域であることから、設定された各種制御定数やSRMデータなどが格納される。
RAM44は、システムコントローラ50が各種処理を実行するのに必要なデータやプログラム等の記憶に用いられたり、ワーク領域として使用される。
なお、NV−RAM43、RAM44、プログラムメモリ42はシステムコントローラ50としてのチップ内部の記憶領域として形成されてもよいし、別体のチップとされてもよい。
また、IEEE1394インターフェイス39では、外部装置から送信されてくるコマンドやレスポンス等のデータを受信すること、或いは外部装置に対してコマンドやレスポンスを送信することも行う。システムコントローラ50は、このコマンドやレスポンスの送受信処理についても必要な処理を実行する。
2.IEEE1394による本実施の形態のデータ通信
2−1 概要

以降、本実施の形態としてのIEEE1394規格に従ったデータ通信について説明する。
IEEE1394は、シリアルデータ通信の規格の1つとされる。
このIEEE1394によるデータ伝送方式としては、周期的に通信を行うIsochronous通信方式と、この周期と関係なく非同期で通信するAsynchronous通信方式が存在する。一般に、Isochronous通信方式はデータの送受信に用いられ、Asynchronous通信方式は各種制御コマンドの送受信に用いられる。そして、1本のケーブルを使用して、これら2種類の通信方式によって送受信を行うことが出来るようにされている。
そこで以降、上記したIEEE1394規格による本実施の形態の送信形態を前提として説明を行っていくこととする。
2−2 スタックモデル

図6は、本実施の形態が対応するIEEE1394のスタックモデルを示している。
IEEE1394フォーマットにおいては、Asynchronous系(400)とIsochronous系(500)とに大別される。
ここで、Asynchronous系(400)とIsochronous系(500)に共通な層として、最下位にPhysical Layer(301)(物理層)が設けられ、その上位にLink Layer(302)(リンク層)が設けられる。Physical Layer(301)はハードウェア的な信号伝送を司るためのレイヤであり、Link Layer(302)はIEEE1394バスを例えば、機器毎に規定された内部バスに変換するための機能を有する層とされる。
Physical Layer(301)、Link Layer(302)、及び次に説明するTransaction Layer(401)は、Event/Control/ConfigurationのラインによってSerial Bus Management303とリンクされる。
また、AV Cable/Connector304は、AVデータ伝送のための物理的なコネクタ、ケーブルを示している。
Asynchronous系(400)における上記Link Layer(302)の上位には、Transaction Layer(401)が設けられる。Transaction Layer(401)は、IEEE1394としてのデータ伝送プロトコルを規定する層とされ、基本的なAsynchronous Transactionとしては、後述するようにして、Write Transaction,Read Transaction,Lock Transactionが規定される。
そして、Transaction Layer(401)の上層に対してFCP(Function Control Protocol)(402)が規定される。FCP(402)は、AV/C Command(AV/C Digital Interface Command Set)(403)として規定された制御コマンドを利用することで、各種AV機器に対するコマンド制御を実行することが出来るようになっている。
また、Transaction Layer(401)の上層に対しては、Connection Management Procedures(505)を利用して、後述するPlug(IEEE1394における論理的な機器接続関係)を設定するためのPlug Controll Registers(404)が規定される。
Isochronous系(500)におけるLink Layer(302)の上位には、CIP Header Format(501)が規定され、このCIP Header Format(501)に管理される形態で、SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504),MPEG2−TS Realtime Transmission(505),Audio and Music Realtime Transmission(506)等の伝送プロトコルが規定されている。
SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504)は、それぞれ、デジタルVTR(Video Tape Recorder)に対応するデータ伝送プロトコルである。
SD−DVCR Realtime Transmission(502)が扱うデータは、SD−DVCR recording format(508)の規定に従って得られたデータシーケンス(SD−DVCR data sequence(507))とされる。
また、HD−DVCR Realtime Transmission(503)が扱うデータは、HD−DVCR recording format(510)の規定に従って得られたデータシーケンス(SD−DVCR data sequence(509))とされる。
SDL−DVCR Realtime Transmission(504)が扱うデータは、SDL−DVCR recording format(512)の規定に従って得られるデータシーケンス(SD−DVCR data sequence(511))となる。
MPEG2−TS Realtime Transmission(505)は、例えばデジタル衛星放送に対応するチューナ等に対応する伝送プロトコルで、これが扱うデータは、DVB recording format(514)或いはATV recording format(515)の規定に従って得られるデータシーケンス(MPEG2−TS data sequence(513))とされる。
また、Audio and Music Realtime Transmission(506)は、例えば本実施の形態のMDシステムを含むデジタルオーディオ機器全般に対応する伝送プロトコルであり、これが扱うデータは、Audio and Music recording format(517)の規定に従って得られるデータシーケンス(Audio and Music data sequence)とされる。
2−3 信号伝送形態

図7は、IEEE1394バスとして実際に用いられるケーブルの構造例を示している。
この図においては、コネクタ600Aと600Bがケーブル601を介して接続されていると共に、ここでは、コネクタ600Aと600Bのピン端子として、ピン番号1〜6の6ピンが使用される場合を示している。
コネクタ600A,600Bに設けられる各ピン端子については、ピン番号1は電源(VP)、ピン番号2はグランド(VG)、ピン番号3はTPB1、ピン番号4はTPB2、ピン番号5はTPA1、ピン番号5はTPA2とされている。
そして、コネクタ600A−600B間の各ピンの接続形態は、
ピン番号1(VP)−ピン番号1(VP)
ピン番号2(VG)−ピン番号2(VG)
ピン番号3(TPB1)−ピン番号5(TPA1)
ピン番号4(TPB2)−ピン番号6(TPA2)
ピン番号5(TPA1)−ピン番号3(TPB1)
ピン番号6(TPA2)−ピン番号3(TPB2)
のようになっている。そして、上記ピン接続の組のうち、
ピン番号3(TPB1)−ピン番号5(TPA1)
ピン番号4(TPB2)−ピン番号6(TPA2)
の2本のツイスト線の組により、差動で信号を相互伝送する信号線601Aを形成し、
ピン番号5(TPA1)−ピン番号3(TPB1)
ピン番号6(TPA2)−ピン番号3(TPB2)
の2本のツイスト線の組により、差動で信号を相互伝送する信号線601Bを形成している。
上記2組の信号線601A及び信号線601Bにより伝送される信号は、図8(a)に示すデータ信号(Data)と、図8(b)に示すストローブ信号(Strobe)である。
図8(a)に示すデータ信号は、信号線601A又は信号線601Bの一方を使用してTPB1,2から出力され、TPA1,2に入力される。
また、図8(b)に示すストローブ信号は、データ信号と、このデータ信号に同期する伝送クロックとについて所定の論理演算を行うことによって得られる信号であり、実際の伝送クロックよりは低い周波数を有する。このストローブ信号は、信号線601A又は信号線601Bのうち、データ信号伝送に使用していない他方の信号線を使用して、TPA1,2から出力され、TPB1,2に入力される。
例えば、図8(a),図8(b)に示すデータ信号及びストローブ信号が、或るIEEE1394対応の機器に対して入力されたとすると、この機器においては、入力されたデータ信号とストローブ信号とについて所定の論理演算を行って、図8(c)に示すような伝送クロック(Clock)を生成し、所要の入力データ信号処理に利用する。
IEEE1394フォーマットでは、このようなハードウェア的データ伝送形態を採ることで、高速な周期の伝送クロックをケーブルによって機器間で伝送する必要をなくし、信号伝送の信頼性を高めるようにしている。
なお、上記説明では6ピンの仕様について説明したが、IEEE1394フォーマットでは電源(VP)とグランド(VG)を省略して、2組のツイスト線である信号線601A及び信号線601Bのみからなる4ピンの仕様も存在する。例えば、本実施の形態のMDレコーダ/プレーヤ1では、実際には、この4ピン仕様のケーブルを用いることで、ユーザにとってより簡易なシステムを提供できるように配慮している。
2−4 機器間のバス接続

図9は、IEEE1394バスによる機器間接続の形態例を模式的に示している。この図では、機器A,B,C,D,Eの5台の機器(Node)がIEEE1394バス(即ちケーブルである)によって相互通信可能に接続されている場合が示されている。
IEEE1394インターフェイスでは、機器A,B,CのようにしてIEEE1394バスにより直列的に接続するいわゆる「ディージチェーン接続」が可能とされる。また、図9の場合であれば、機器Aと、機器B,D,E間の接続形態に示すように、或る機器と複数機器とが並列的に接続されるいわゆる「ブランチ接続」も可能とされる。
システム全体としては、このブランチ接続と上記ディージチェーン接続とを併用して最大63台の機器(Node)を接続可能とされる。但し、ディージチェーン接続によっては、最大で16台(16ポップ)までの接続が可能とされている。また、SCSIで必要とされるターミネータはIEEE1394インターフェイスでは不要である。
そしてIEEE1394インターフェイスでは、上記のようにしてディージチェーン接続又はブランチ接続により接続された機器間で相互通信を行うことが可能とされている。つまり、図9の場合であれば、機器A,B,C,D,E間の任意の複数機器間での相互通信が可能とされる。
また、IEEE1394バスにより複数の機器接続を行ったシステム(以降はIEEE1394システムともいう)内では、機器ごとに割与えられるNodeIDを設定する処理が実際には行われる。この処理を、図10により模式的に示す。
ここで、図10(a)に示す接続形態によるIEEE1394システムにおいて、ケーブルの抜き差し、システムにおける或る機器の電源のオン/オフ、PHY(Physical Layer Protocol)での自発発生処理等が有ったとすると、IEEE1394システム内においてはバスリセットが発生する。これにより、各機器A,B,C,D,E間においてIEEE1394バスを介して全ての機器にバスリセット通知を行う処理が実行される。
このバスリセット通知の結果、図10(b)に示すようにして、通信(Child−Notify)を行うことで隣接する機器端子間で親子関係が定義される。つまり、IEEE1394システム内における機器間のTree構造を構築する。そして、このTree構造の構築結果に従って、ルートとしての機器が定義される。ルートとは、全ての端子が子(Ch;Child)として定義された機器であり、図10(b)の場合であれば、機器Bがルートとして定義されていることになる。逆に言えば、例えばこのルートとしての機器Bと接続される機器Aの端子は親(P;Parent)として定義されているものである。
上記のようにしてIEEE1394システム内のTree構造及びルートが定義されると、続いては、図10(c)に示すようにして、各機器から、自己のNode−IDの宣言としてSelf−IDパケットが出力される。そしてルートがこのNode−IDに対して順次承認(grant)を行っていくことにより、IEEE1394システム内における各機器のアドレス、つまりNode−IDが決定される。
2−5 パケット

IEEE1394フォーマットでは、図12に示すようにしてIsochronous cycle(nominal cycle)の周期を繰り返すことによって送信を行う。この場合、1Isochronous cycleは、125μsecとされ、帯域としては100MHzに相当する。なお、Isochronous cycleの周期としては125μsec以外とされても良いことが規定されている。そして、このIsochronous cycleごとに、データをパケット化して送信する。
この図に示すように、Isochronous cycleの先頭には、1Isochronous cycleの開始を示すCycle Start Packetが配置される。
このCycle Start Packetは、ここでの詳しい説明は省略するが、Cycle Masterとして定義されたIEEE1394システム内の特定の1機器によってその発生タイミングが指示される。
Cycle Start Packetに続いては、Isochronous Packetが優先的に配置される。Isochronous Packetは、図のように、チャンネルごとにパケット化されたうえで時分割的に配列されて転送される(Isochronous subactions)。また、Isochronous subactions内においてパケット毎の区切りには、Isochronous gapといわれる休止区間(例えば0.05μsec)が設けられる。
このように、IEEE1394システムでは、1つの伝送線路によってIsochronousデータをマルチチャンネルで送受信することが可能とされている。
ここで、例えば本実施の形態のMDレコーダ/プレーヤが対応する圧縮オーディオデータ(以降はATRACデータともいう)をIsochronous方式により送信することを考えた場合、ATRACデータが1倍速の転送レート1.4Mbpsであるとすれば、125μsecである1Isochronous cycle周期ごとに、少なくともほぼ20数バイトのATRACデータをIsochronous Packetとして伝送すれば、時系列的な連続性(リアルタイム性)が確保されることになる。
例えば、或る機器がATRACデータを送信する際には、ここでの詳しい説明は省略するが、IEEE1394システム内のIRM(Isochronous Resource Manager)に対して、ATRACデータのリアルタイム送信が確保できるだけの、Isochronous パケットのサイズを要求する。IRMでは、現在のデータ伝送状況を監視して許可/不許可を与え、許可が与えられれば、指定されたチャンネルによって、ATRACデータをIsochronous Packetにパケット化して送信することが出来る。これがIEEE1394インターフェイスにおける帯域予約といわれるものである。
Isochronous cycleの帯域内においてIsochronous subactionsが使用していない残る帯域を用いて、Asynchronous subactions、即ちAsynchronousのパケット送信が行われる。
図11では、Packet A,Packet Bの2つのAsynchronous Packetが送信されている例が示されている。Asynchronous Packetの後には、ack gap(0.05μsec)の休止期間を挟んで、ACK(Acknowledge)といわれる信号が付随する。ACKは、後述するようにして、Asynchronous Transactionの過程において、何らかのAsynchronousデータの受信が有ったことを送信側(Controller)に知らせるためにハードウェア的に受信側(Target)から出力される信号である。
また、Asynchronous Packet及びこれに続くACKからなるデータ伝送単位の前後には、10μsec程度のsubaction gapといわれる休止期間が設けられる。
ここで、Isochronous PacketによりATRACデータを送信し、上記ATRACデータに付随するとされるAUXデータファイルをAsynchronous Packetにより送信するようにすれば、見かけ上、ATRACデータとAUXデータファイルとを同時に送信することが可能となるものである。
2−6 トランザクションルール

図12(a)の処理遷移図には、Asynchronous通信における基本的な通信規則(トランザクションルール)が示されている。このトランザクションルールは、FCPによって規定される。
図12(a)に示すように、先ずステップS11により、Requester(送信側)は、Responder(受信側)に対してRequestを送信する。Responderでは、このRequestを受信する(ステップS12)と、先ずAcknowledgeをRequesterに返送する(ステップS13)。送信側では、Acknowledgeを受信することで、Requestが受信側にて受信されたことを認知する(ステップS14)。
この後、Responderは先のステップS12にて受信したRequestに対する応答として、ResponseをRequesterに送信する(ステップS15)。Requesterでは、Responseを受信し(ステップS16)、これに応答してResponderに対してAcknowledgeを送信する(ステップS17)。ResponderではAcknowledgeを受信することで、Responseが送信側にて受信されたことを認知する。
上記図12(a)により送信されるRequest Transactionとしては、図12(b)の左側に示すように、Write Request、Read Request、Lock Requestの3種類に大別して定義されている。
Write Requestは、データ書き込みを要求するコマンドであり、Read Requestはデータの読み出しを要求するコマンドである。Lock Requestはここでは詳しい説明は省略するが、swap compare、マスクなどのためのコマンドである。
また、Write Requestは、後に図示して説明するAsynchronous Packet(AV/C Command Packet)に格納するコマンド(operand)のデータサイズに応じてさらに3種類が定義される。Write Request(data quadlet)は、Asynchronous Packetのヘッダサイズのみによりコマンドを送信する。Write Request(data block:data length=4byte)、Write Request(data block:data length≠4byte)は、Asynchronous Packetとしてヘッダに対してdata blockを付加してコマンド送信を行うもので、両者は、data blockに格納されるoperandのデータサイズが4バイトであるかそれ以上であるのかが異なる。
Read Requestも同様にして、Asynchronous Packetに格納するoperandのデータサイズに応じて、Read Request(data quadlet)、Read Request(data block:data length=4byte)、Read Request(data block:data length≠4byte)の3種類が定義されている。
また、Response Transactionとしては、図12(b)の右側に示されている。
上述した3種のWrite Requestに対しては、Write Response或いはNo Responseが定義される。
また、Read Request(data quadlet)に対してはRead Response(data quadlet)が定義され、Read Request(data block:data length=4byte)、又はRead Request(data block:data length≠4byte)に対しては、Read Response(data block)が定義される。
Lock Requestに対しては、Lock Responseが定義される。
2−7 アドレッシング

図13は、IEEE1394バスのアドレッシングの構造を示している。
図13(a)に示すように、IEEE1394フォーマットでは、バスアドレスのレジスタ(アドレス空間)として64ビットが用意される。
このレジスタの上位10ビットの領域は、IEEE1394バスを識別するためのバスIDを示し、図13(b)に示すようにしてバスIDとしてbus#0〜#1022の計1023のバスIDを設定可能としている。bus#1023はlocal busとして定義されている。
図13(a)においてバスアドレスに続く6ビットの領域は、上記バスIDにより示されるIEEE1394バスごとに接続されている機器のNode IDを示す。Node IDは、図13(c)に示すようにして、Node #0〜#62までの63のNode IDを識別可能としている。
上記バスID及びNode IDを示す計16ビットの領域は、後述するAV/C Command Packetのヘッダにおけるdestination IDに相当するもので、このバスID及びNode IDによって、或るバスに接続された機器がIEEE1394システム上で特定される。
図13(a)においてNode IDに続く20ビットの領域は、register spaceであり、このregister spaceに続く28ビットの領域は、register addressである。
register spaceの値は最大で[F FF FFh]とされて、図13(d)に示すregisterを示し、このregisterの内容が、図13(e)に示すようにして定義される。register addressは、図13(e)に示すレジスタのアドレスを指定している。
簡単に説明すると、図13(e)のレジスタにおいて、例えばアドレス512[0 00 02 00h]から始まるSerial Bus−dependent Registersを参照することで、Isochronous cycleのサイクルタイムや、空きチャンネルの情報が得られる。
また、アドレス1024[0 00 04 00h]から始まるConfiguration ROMには、Node Unique ID、及びsubunit ID等のNodeに関する所要の情報が格納される。
これらNode Unique ID、及びsubunit IDは、実際にそのデバイスがIEEE1394バスに接続されたときに、その接続関係を確立する際などに必要となるものである。
Node Unique IDは、デバイスごとに固有とされ、8バイトによって表現されるデバイス情報であり、たとえ同一機種間であっても、同じNode Unique IDを有している他の機器は無いものとされる。
また、subunit IDとしては、そのNodeとしての機器の製造メーカ名を示すVender Name(module_vender_ID)や、Nodeとしての機器の機種名を示すModel Name(model_ID)等の情報を有して形成される。
Node Unique IDは、デバイスごとに固有とされ、8バイトによって表現されるデバイス識別情報であり、たとえ同一機種間であっても、同じNode Unique IDを有している機器は無いものとされる。
また、Vender Nameは、そのNodeの製造メーカ名を示す情報であり、Model Nameは、そのNodeの機種を示す情報である。従って、これらVender Name及びModel Nameを共通に有する機器は存在することになる。
従って、Configuration ROMの内容を参照することで、その機種に付されているNode Unique IDを識別することができ、また、subunit IDの内容からは、そのNodeの製造メーカ、及び機種等を識別することが可能になる。なお、Node Unique IDは必須であるのに対して、Vender Name,Model Nameはオプションであり、必ずしも機器に対してセットしておく必要は無いものとされている。
2−8 CIP(Common Isochronous Packet)

図14は、CIP(Common Isochronous Packet)の構造を示している。つまり、図11に示したIsochronous Packetのデータ構造である。
前に述べたように、本実施の形態のMDレコーダ/プレーヤが対応する記録再生データの1つである、ATRACデータ(オーディオデータ)は、IEEE1394通信においては、Isochronous通信によりデータの送受信が行われる。つまり、リアルタイム性が維持されるだけのデータ量をこのIsochronous Packetに格納して、1Isochronous cycle毎に順次送信するものである。
CIPの先頭32ビット(1quadlet)は、1394パケットヘッダとされている。
1394パケットヘッダにおいて上位から順に16ビットの領域は、data_Length、続く2ビットの領域はtag、続く6ビットの領域はchannel、続く4ビットはtcode、続く4ビットは、syとされている。
そして、1394パケットヘッダに続く1quadletの領域はheader_CRCが格納される。
header_CRCに続く2quadletの領域がCIPヘッダとなる。
CIPヘッダの上位quadletの上位2ビットには、それぞれ‘0’‘0’が格納され、続く6ビットの領域はSID(送信ノード番号)を示す。SIDに続く8ビットの領域はDBS(データブロックサイズ)であり、データブロックのサイズ(パケット化の単位データ量)が示される。続いては、FN(2ビット)、QPC(3ビット)の領域が設定されており、FNにはパケット化する際に分割した数が示され、QPCには分割するために追加したquadlet数が示される。
SPH(1ビット)にはソースパケットのヘッダのフラグが示され、DBCにはパケットの欠落を検出するカウンタの値が格納される。
CIPヘッダの下位quadletの上位2ビットにはそれぞれ‘0’‘0’が格納される。そして、これに続いてFMT(6ビット)、FDF(24ビット)の領域が設けられる。FMTには信号フォーマット(伝送フォーマット)が示され、ここに示される値によって、当該CIPに格納されるデータ種類(データフォーマット)が識別可能となる。具体的には、MPEGストリームデータ、Audioストリームデータ、デジタルビデオカメラ(DV)ストリームデータ等の識別が可能になる。このFMTにより示されるデータフォーマットは、例えば図6に示した、CIP Header Format(401)に管理される、SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504),MPEG2−TS Realtime Transmission(505),Audio and Music Realtime Transmission(506)等の伝送プロトコルに対応する。
FDFは、フォーマット依存フィールドであり、上記FMTにより分類されたデータフォーマットについて更に細分化した分類を示す領域とされる。オーディオに関するデータで有れば、例えばリニアオーディオデータであるのか、MIDIデータであるのかといった識別が可能になる。
例えば本実施の形態のATRACデータであれば、先ずFMTによりAudioストリームデータの範疇にあるデータであることが示され、FDFに規定に従った特定の値が格納されることで、そのAudioストリームデータはATRACデータであることが示される。
ここで、例えばFMTによりMPEGであることが示されている場合、FDFにはTSF(タイムシフトフラグ)といわれる同期制御情報が格納される。また、FMTによりDVCR(デジタルビデオカメラ)であることが示されている場合、FDFは、図14の下に示すように定義される。ここでは、上位から順に、50/60(1ビット)により1秒間のフィールド数を規定し、STYPE(5ビット)によりビデオのフォーマットがSDとHDの何れとされているのかが示され、SYTによりフレーム同期用のタイムスタンプが示される。
上記CIPヘッダに続けては、FMT,FDFによって示されるデータが、n個のデータブロックのシーケンスによって格納される。FMT,FDFによりATRACデータであることが示される場合には、このデータブロックとしての領域にATRACデータが格納される。
そして、データブロックに続けては、最後にdata_CRCが配置される。
2−9 コネクションマネージメント

IEEE1394フォーマットにおいては、「プラグ」といわれる論理的接続概念によって、IEEE1394バスによって接続された機器間の接続関係が規定される。
図15は、プラグにより規定された接続関係例を示しており、この場合には、IEEE1394バスを介して、VTR1、VTR2、セットトップボックス(STB;デジタル衛星放送チューナ)、モニタ装置(Monitor)、及びデジタルスチルカメラ(Camera)が接続されているシステム形態が示されている。
ここで、IEEE1394のプラグによる接続形態としては、point to point−connectionと、broadcast connectionとの2つの形態が存在する。
point to point−connectionは、送信機器と受信機器との関係が特定され、かつ、特定のチャンネルを使用して送信機器と受信機器との間でデータ伝送が行われる接続形態である。
これに対して、broadcast connectionは、送信機器においては、特に受信機器及び使用チャンネルを特定せずに送信を行うものである。受信機側では、特に送信機器を識別することなく受信を行い、必要が有れば、送信されたデータの内容に応じた所要の処理を行う。
図15の場合であれば、point to point−connectionとして、STBが送信、VTR1が受信とされてチャンネル#1を使用してデータの伝送が行われるように設定されている状態と、デジタルスチルカメラが送信、VTR2が受信とされてチャンネル#2を使用してデータの伝送が行われるように設定されている状態とが示されている。
また、デジタルスチルカメラからは、broadcast connectionによってもデータ送信を行うように設定されている状態が示されており、ここでは、このbroadcast connectionによって送信したデータを、モニタ装置が受信して所要の応答処理を行う場合が示される。
上記のような接続形態(プラグ)は、各機器におけるアドレス空間に設けられるPCR(Plug Control Register)によって確立される。
図16(a)は、oPCR[n](出力用プラグコントロールレジスタ)の構造を示し、図16(b)は、iPCR[n](入力用プラグコントロールレジスタ)の構造を示している。これらoPCR[n]、iPCR[n]のサイズは共に32ビットとされている。
図16(a)のoPCRにおいては、例えば上位1ビットのon−lineに対して‘1’が格納されていると、そのプラグがIsochronousデータの送信が可能なオンラインであることが示され、続くbroadcast connection counter(1ビット)に‘1’が格納されているとbroadcast connectionによる送信であることが示される。続くpoint to point connection counter(6ビット)には、そのプラグに対して張られているpoint to point connectionの数が示される。そして、上位11ビット目から6ビットの領域のchannel numberで示されるチャンネルにより送信することが示される。
また、図16(b)のiPCRにおいても、例えば上位1ビットのon−lineに対して‘1’が格納されていれば、そのプラグがIsochronousデータの受信が可能なオンラインであることが示され、続くbroadcast connection counter(1ビット)に‘1’が格納されているとbroadcast connectionによる送信であることが示される。続くpoint to point connection counter(6ビット)には、そのプラグに対して張られているpoint to point connectionの数が示され、上位11ビット目から6ビットの領域のchannel numberで示されるチャンネルにより送信することが示される。
そして、図16(a)のoPCR、及び図16(b)のiPCRにおけるbroadcast connection counterには、broadcast connectionによる送信/受信とされる場合において、broadcast connectionを張っているノード数が格納される。
また、図16(a)のoPCR、及び図16(b)のiPCRにおけるpoint to point connection counterには、point to point connectionによる送信/受信とされる場合において、point to pointを張っているノード数が示される。
2−10 FCPにおけるコマンド及びレスポンス

Asynchronous通信によるデータの伝送は、図6に示したFCP(402)によって規定されることになる。そこで、ここでは、FCPにより規定されるトランザクションについて説明する。
FCPとしては、Asynchronous通信において規定されるWrite Transaction(図12参照)を使用する。従って、本実施の形態におけるAUXデータの伝送も、このFCPにより、Asynchronous通信の中のWrite Transactionを使用することで行われるものである。
FCPをサポートする機器は、Command/Responceレジスタを備え、次に図17により説明するようにしてCommand/Responceレジスタに対してMessageを書き込むことでトランザクションを実現する。
図17の処理遷移図においては、先ずCOMMAND送信のための処理として、ステップS21として示すように、ControllerがTransaction Requestを発生して、Write Request PacketをTargetに対して送信する処理を実行する。Targetでは、ステップS22として、このWrite Request Packetを受信して、Command/Responceレジスタに対してデータの書き込みを行う。また、この際、TargetからはControllerに対してAcknowledgを送信し、Controllerでは、このAcknowledgを受信する(S23→S24)。ここまでの一連の処理が、COMMANDの送信に対応する処理となる。
続いては、COMMANDに応答した、RESPONSEのための処理として、TargetからWrite Request Packetが送信される(S25)。Controllerではこれを受信して、Command/Responceレジスタに対してデータの書き込みを行う(S26)。また、Controllerでは、Write Request Packetの受信に応じて、Targetに対してAcknowledgを送信する(S27)。Targetでは、このAcknowledgを受信することで、Write Request PacketがControllerにて受信されたことを知る(S28)。
つまり、ControllerからTarget対するCOMMAND伝送処理と、これに応答したTargetからControllerに対するRESPONSE伝送処理が、FCPによるデータ伝送(Transaction)の基本となる。
2−11 AV/Cコマンドパケット

図6により説明したように、Asynchronous通信において、FCPは、AV/Cコマンドを用いて各種AV機器に対する通信を行うことができるようにされている。
Asynchronous通信では、Write,Read,Lockの3種のトランザクションが規定されているのは、図12にて説明した通りであり、実際には各トランザクションに応じたWrite Request/Responce Packet,Read Request/Responce Packet,Lock Request/Responce Packetが用いられる。そして、FCPでは、上述したようにWrite Transactionを使用するものである。
そこで図18に、Write Request Packet(Asynchronous Packet(Write Request for Data Block))のフォーマットを示す。本実施の形態では、このWrite Request Packetが即ち、AV/Cコマンドパケットして使用される。
このWrite Request Packetにおける上位5quadlet(第1〜第5quadlet)は、packet headerとされる。
packet headerの第1quadletにおける上位16ビットの領域はdestination_IDで、データの転送先(宛先)のNode IDを示す。続く6ビットの領域はtl(transact label)であり、パケット番号を示す。続く2ビットはrt(retry code)であり、当該パケットが初めて伝送されたパケットであるか、再送されたパケットを示す。続く4ビットの領域はtcode(transaction code)は、指令コードを示している。そして、続く4ビットの領域はpri(priority)であり、パケットの優先順位を示す。
第2quadletにおける上位16ビットの領域はsource_IDであり、データの転送元のNode_ID が示される。
また、第2quadletにおける下位16ビットと第3quadlet全体の計48ビットはdestination_offsetとされ、COMMANDレジスタ(FCP_COMMAND register)とRESPONSEレジスタ(FCP_RESPONSE register)のアドレスが示される。
上記destination_ID及びdestination_offsetが、IEEE1394フォーマットにおいて規定される64ビットのアドレス空間に相当する。
第4quadletの上位16ビットの領域は、data_lengthとされ、後述するdatafield(図18において太線により囲まれる領域)のデータサイズが示される。
続く下位16ビットの領域は、extended_tcodeの領域とされ、tcodeを拡張する場合に使用される領域である。
第5quadletとしての32ビットの領域は、header_CRCであり、Packet headerのチェックサムを行うCRC計算値が格納される。
Packet headerに続く第6quadletからdata blockが配置され、このdata block内の先頭に対してdatafieldが形成される。
datafieldとして先頭となる第6quadletの上位4ビットには、CTS(Command and Transaction Set)が記述される。これは、当該Write Request PacketのコマンドセットのIDを示すもので、例えば、このCTSの値について、図のように[0000]と設定すれば、datafieldに記述されている内容がAV/Cコマンドであると定義されることになる。つまり、このWrite Request Packetは、AV/Cコマンドパケットであることが示されるものである。従って、本実施の形態においては、FCPがAV/Cコマンドを使用するため、このCTSには[0000]が記述されることになる。
CTSに続く4ビットの領域は、ctype(Command type;コマンドの機能分類)、又はコマンドに応じた処理結果(レスポンス)を示すresponseが記述される。
図19に、上記ctype及びresponseの定義内容を示す。
ctype(Command)としては、[0000]〜[0111]を使用できるものとしており、[0000]はCONTROL、[0001]はSTATUS、[0010]はINQUIRY、[0011]はNOTIFYとして定義され、[0100]〜[0111]は、現状、未定義(reserved)とされている。
CONTROLは機能を外部から制御するコマンドであり、STATUSは外部から状態を間い合わせるコマンド、INQUIRYは、制御コマンドのサポートの有無を外部から問い合わせるコマンド、NOTIFYは状態の変化を外部に知らせることを要求するコマンドである。
また、responseとしては、[1000]〜[1111]を使用するものとしており、[1000]はNOT IMPLEMENTED、[1001]はACCEPTED、[1010]はREJECTED、[1011]はIN TRANSITION、[1100]はIMPLEMENTED/STABLE、[1101]はCHANGED、[1110]はreserved、[1111]はINTERIMとしてそれぞれ定義されている。
これらのresponseは、コマンドの種類に応じて使い分けられる。例えば、CONTOROLのコマンドに対応するresponseとしては、NOT IMPLEMENTED、ACCEPTED、REJECTED、或いはINTERIMの4つのうちの何れかがResponder側の状況等に応じて使い分けられる。
図18において、ctype/responseに続く5ビットの領域には、subunit−typeが格納される。は、subunit−typeは、COMMMANDの宛先またはRESPONSEの送信元のsubunitが何であるのか(機器)を示す。IEEE1394フォーマットでは、機器そのものをunitと称し、そのunit(機器)内において備えられる機能的機器単位の種類をsubunitと称する。例えば一般のVTRを例に採れば、VTRとしてのunitは、地上波や衛星放送を受信するチューナと、ビデオカセットレコーダ/プレーヤとの、2つのsubunitを備える。
subunit−typeとしては、例えば図20(a)に示すように定義されている。つまり、[00000]はMonitor、[00001]〜[00010]はreserved、[00011]はDisc recorder/player、[00100]はVCR、[00101]はTuner、[00111]はCamera、[01000]〜[11110]はreserved、[11111]は、subunitが存在しない場合に用いられるunitとして定義されている。
図18において、上記subunit−typeに続く3ビットには、同―種類のsubunitが複数存在する場合に、各subunitを特定するためのid(Node_ID)が格納される。
上記id(Node_ID)に続く8ビットの領域には、opcodeが格納され、続く8ビットの領域には、operandが格納される。
opcodeとは、オぺレーションコード(Operation Code)のことであって、operandには、opcodeが必要とする情報(パラメータ)が格納される。これらopcodeはsubunitごとに定義され、subunitごとに固有のopcodeのリストのテーブルを有する。例えば、subunitがVCRであれば、opcodeとしては、例えば図20(b)に示すようにして、PLAY(再生),RECORD(記録)などをはじめとする各種コマンドが定義されている。operandは、opcode毎に定義される。
図18におけるdatafieldとしては、上記第6quadletの32ビットが必須とされるが、必要が有れば、これに続けて、operandを追加することが出来る(Additional operands)。
datafieldに続けては、data_CRCが配置される。なお、必要が有れば、data_CRCの前にpaddingを配置することが可能である。
3.SRM

続いてSRMについて説明する。SRMとはSystem Renewability Messagesの略で、5C−DTCP(Digital Transmission Content Protection)対応の機器(IEEE1394、USB、MOSTなど)でFULL認証に対応している機器に用いられる著作権保護のための情報である。そして著作権保護に適合していない機器のいわゆるブラックリストとしての内容を含む。
そしてSRMは機器間の認証処理の際に用いられる(認証処理時に参照される)情報の一つであり、本実施の形態では、このSRMを認証使用情報の例として、その更新処理について後に詳述する。
SRMデータは図21に示すSRM発行機関115によって、承認された電子機器に対して発行される。
まず、ここで図21に示す機器A,B,Cは、それぞれ適正な5C−DTCP対応機器として、SRM発行機関115に承認(ライセンス)された機器であるとする。SRM発行機関115は、承認した機器に対しては、ライセンスを示す電子署名DS(Device Certificate)を発行する。機器A,B,Cは、SRM発行機関115が発行した電子署名DS(a)、DS(b)、DS(c)をそれぞれ機器内部に格納するものとなる。
一方、SRM発行機関115は、必要に応じて随時SRMを発行する。例えば著作権保護に不適切な機器が発見されることなどに応じてSRMを発行する。
SRMデータには例えば図22のように、まず、Type、Generation、Version Numberのデータが設けられ、SRMデータのヘッダとして、タイプ、世代、バージョンが示される。
また、CRL長として、CRLのデータ長が記録され、それに続いて可変長データとしてCRLが記録される。CRLとは「Certificate Revocation List」であり、即ちSRM発行機関115がライセンス取り消しを行った電子機器のリスト情報、即ちブラックリスト情報である。
また電子署名(DTLA Signature)が記録される。これは、SRM発行機関115が、当該SRMデータ自体を正当なデータとして証明する電子署名である。
例えば今、CRLとしてリストアップされている機器が存在しないとする。つまりSRMデータが発行されていないとする。そして図21のようにSRM発行機関115は機器A,B,Cをそれぞれライセンス承認したとする。
SRM発行機関115は機器A,B,Cに対してそれぞれ個別の電子署名DS(a)、DS(b)、DS(c)を付与する。
各機器A,B,Cは、付与された電子署名DS(*)を装置内に記憶することになる。
また、SRMデータは発行されていないため、例えば単に図22のようなSRMデータ形式において、実内容が含められていないSRMデータを保持している。
これは、単にSRMデータ用の領域を確保しているのみでもよいし、上記SRMデータのヘッダ部分のみが記録されたものでもよい。
なお、あくまでも説明上の都合として、仮に、実内容(CRLブラックリスト)が存在しない状態、つまりまだ実効的なSRMデータが発行されていない時点での各機器に格納されているSRMデータを、バージョン0.0のSRMデータと呼ぶこととする。
その後、仮に機器Cが著作権保護処理が不十分な機器であると認定され、SRM発行機関115が機器Cに対するライセンスを取り消すとする。このとき、SRM発行機関115は、機器Cに付与した電子署名DS(c)をCRLにリストアップしたSRMデータを発行する。
説明上、仮に、このSRMデータをバージョン1.0のSRMデータとする。
この場合、機器A,Bは、何らかの手法で記憶しているSRMデータ(バージョン0.0)を発行されたSRMデータ(バージョン1.0)に更新することになる。
もちろん、その後、SRM発行機関115は、必要に応じて、バージョン1.1、1.2、2.0・・・などというように、SRMデータの発行を行う。各電子機器A、B・・・は、その都度SRMデータの更新が必要になる。
更新を実行可能とし、また適切な認証を行って適切な著作権保護を実現するため、ライセンスされた機器には、次のことが義務づけられる。
1)機器間で認証処理を行った後、相手機器からSRMデータを受信した場合は、必要に応じ、機器内部に格納(更新)する。
2)機器間で認証処理を行った後、必要に応じて認証相手機器に対し、機器内部に記憶されているSRMデータを送信する。
3)認証途中で認証相手が機器内部のSRMデータのCRLに記載されていると判明した場合は、それ以降認証を行わない(認証処理を中止し、認証エラーとする)。
これらは、将来著作権保護が不充分と判定された製品があった場合に、その製品を穏やかに市場から排除する機能を持たせることを目的としている。
図23で例を挙げて説明する。
図23(a)は、SRM発行時期や機器の製造時期を時間軸上に示したものである。
図23(a)で或る時期において、SRMデータはバージョン0.0とされており、これはCRLとしてリストアップされる機器が存在しない時期のものであったとする。つまりSRMデータがまだ発行されていない時期である。
その後、ある時期に機器Aが製造され、SRM発行機関115によってライセンスされて電子署名DS(a)が付与されたとする。機器Aでは図23(b)のように電子署名DS(a)が記録されると共に、保持するSRMデータはバージョン0.0である。
またその後、ある時期に機器Cが製造され、SRM発行機関115によってライセンスされて電子署名DS(c)が付与されたとする。機器Cには図23(c)のように電子署名DS(c)が記録される。保持するSRMデータはバージョン0.0である。
ところが、その後、機器Cはライセンスが取り消される事態となり、SRM発行機関115は、機器CをCRLにリストアップしたバージョン1.0のSRMデータを発行することになったとする。
バージョン1.0のSRMデータ発行後、機器Bが製造され、その製造時までにバージョン1.0のSRMデータがメーカサイドに伝達されていれば、機器Bにはバージョン1.0のSRMデータが格納できるものとなる。例えば図23(b)に示すように、機器Bには機器Cの電子署名DS(c)がCRLとしてブラックリストに載せられたバージョン1.0のSRMデータが格納される。
このような状況の後、ある時、図23(b)に示すように機器A,BがIEEE1394バス116により接続され、通信確立を行う際に、相互の認証処理が行われたとする。上記のようにライセンス機器には認証後のSRMデータの送受信が義務づけられているため、認証後、機器Bは機器Aに対してバージョン1.0のSRMデータを送信することになる。機器Aは、送信されてきたバージョン1.0のSRMデータが、記憶しているバージョン0.0のSRMデータよりも新しいものであることから、記憶しているSRMデータを更新することになる。これによって図示するように、機器Aにおいても、機器Cの電子署名DS(c)がCRLとしてブラックリストに載せられたバージョン1.0のSRMデータが格納されるものとなる。
さらにその後、ある時点で図23(c)に示すように機器A,CがIEEE1394バス116により接続され、通信確立を行うことになったとする。ところが、機器Aは、相手側の機器C(DS(c))が格納しているSRMデータにCRLとして登録されている機器であることから、認証エラーとしての処理を行うことになる。つまり機器A,C間の通信は確立されず、オーディオデータ等の伝送は実行できないものとなる。
このようにして、ライセンス取り消しが行われた機器Cは、認証エラーとされ、これによって著作権保護が不十分な機器を排除することで、著作権保護機能を維持するものである。
このような状況において、適切に不適切機器を排除するためには、SRMデータは各機器内においてなるべく迅速に更新(バージョンアップ)されることが必要であることが理解される。
このため上記のように、認証時にSRMデータの送受信が行われるようにし、必要に応じてSRMデータの更新が実行できるようにしている。
またユーザーサイドでの機器において新バージョンのSRMデータを入力する手法としては、電子機器とパーソナルコンピュータをIEEE1394バス116で接続し、パーソナルコンピュータ側でアプリケーションを起動して、SRMデータを電子機器に送信するという手法がある。
例えばパーソナルコンピュータがネットワーク通信で発行されたSRMデータを受信できる場合や、CD−ROMなどによってSRMデータが提供されるようにすれば、そのパーソナルコンピュータを用いて電子機器のSRMデータ更新を実行させることができる。
4.SRMの入力/更新処理
4−1 入力/更新処理系の構成

上記のようにSRMデータは、ユーザーサイドにおいて、IEEE1394バス116によって複数機器が接続された際に、その機器の1つに最新のバージョンのSRMデータが存在すれば、他の機器でもSRMデータを更新できるようにしている。
また、製造段階で考えれば、メーカサイドでその時点で発行されている最新バージョンのSRMデータを機器に記憶させることは可能である。
しかしながら、上述のように不定期に発行されるSRMデータを迅速且つ効率よく、現存している機器に供給し、更新させるためには、より多様な入力経路で機器にSRMデータが入力できるようにし、SRMデータの更新機会をできるだけ増やすことが好ましい。
一方、入力経路が増えることで、新旧のSRMデータがそれぞれ不定期に機器に入力されたり、複数の入力経路から同時的にSRMデータが入力されることなども考えられ、それらに対する適切な対応も必要になる。
そこで、本実施の形態の電子機器では、多様なSRMデータの入力経路を実現すると共に、入力されたSRMデータによって混乱なく、適切な更新処理ができるようにするものである。
入力経路として考えられる多様な例については後述するが、まずここでは、STR対応ディスクドライブ30のようにディスク再生が可能とされる機器をモデルにして説明する。
即ち、SRMデータはIEEE1394バス116を介して他の機器から入力される他、SRMデータがディスク91に記録されており、ディスク91の再生時にSRMデータも再生データとして得られるようにする例である。
例えばSACD等のディスクには、音楽コンテンツ等が記録されるものであるが、ディスクメーカーサイドでは、これらのディスクに、その時点で発行されている最新のSRMデータを記録させて市場に供する。
すると、そのディスク91を購入したユーザーが、ディスク91を例えば自分で所有しているSTR対応ディスクドライブ30に装填した場合に、STR対応ディスクドライブ30はディスク91に記録されたSRMデータを読み出すことにより、SRMデータを入力できるものとなる。
図24は、図5に示したSTR対応ディスクドライブ30において、SRMデータに関する処理を行うブロックを抽出して示したものである。
即ちシステムコントローラ50、IEEE1394インターフェース39、NV−RAM43、RAM44、プログラムメモリ42、SACDドライブ200を示している。SACDドライブ200とは、図5に示した光学ヘッド32、サーボ回路36,RFアンプ35、DSDデコーダ37、スピンドルモータ31・・・など、SACDとしてのディスク91を再生する機構及び回路系を包括的に示したものとする。
また図24において、例えばSACDとしてのディスク91にはSRMデータが記録されていることを模式的に示している。
SRMデータは、ディスクのTOC,サブコードなどの管理情報の一部として記録されていることが考えられる。すると、図5で説明したようにDSDデコーダ37で他の管理情報とともにSRMデータが抽出され、システムコントローラ50に供給される。図24においては、このような経路として、SACDドライブ200からシステムコントローラ50にSRMデータが入力されるものとなる。
SRMデータは、ここでは一例としてNV−RAM43に記憶されるものとする。
プログラムメモリ42にはシステムコントローラ50によって実行されるプログラム、例えばSRMデータの入力/更新処理に関するプログラムが格納されている。
またRAM44は、システムコントローラ50のワーク領域などに利用されるが、特にここでは、SRMデータの入力/更新処理に関して必要になるバッファ領域を、RAM44を用いて確保する例としている。
例えばバッファB1は、IEEE1394バス116を介して入力されたSRMデータのバッファ領域とされ、バッファB2は、ディスク91から読み出されて入力されたSRMデータのバッファ領域とされる。
バッファB1、B2には、例えば図25(a)(b)のように記憶領域が用意される。
バッファB1には図25(a)のように、SRM有無フラグF1、ジェネレーションカウンタG1、ジェネレーションカウンタ前値G1oldとしての各情報領域が確保されるとともに、IEEE1394バス116を介して入力されたSRMデータのバッファリング領域が確保される。
バッファB2には図25(b)のように、SRM有無フラグF2、ジェネレーションカウンタG2、ジェネレーションカウンタ前値G2oldとしての各情報領域が確保されるとともに、ディスク91から読み出されて入力されたSRMデータのバッファリング領域が確保される。
SRM有無フラグF1、F2は、それぞれバッファB1,B2に新たにSRMデータがバッファリングされたことを示すフラグである。
ジェネレーションカウンタG1,G2は、例えば機器が電源オンとされた時点でカウント値「0」とされ、その後、SRMデータの入力が行われる毎にカウントアップされる値である。従ってSRMデータが格納されている場合に、そのSRMデータの世代(電源オン以降、何回目に入力されたデータか)を示す領域である。
ジェネレーションカウンタG1old,G2oldには、所定時点でジェネレーションカウンタG1、G2のカウント値が代入される。
4−2 初期処理

STR対応ディスクドライブ30において、SRMデータに関する初期処理を図26に示す。例えばSTR対応ディスクドライブ30が電源オンとされた際に、システムコントローラ50が実行する処理である。
まずステップF101として、SRM有無フラグF(n)をオフとし、またジェネレーションカウンタG(n)、ジェネレーションカウンタ前値G(n)oldの各値として「0」をセットする。
図24のようにSRMデータの入力経路が2つとされ、バッファB1、B2が設けられる場合、バッファB1、B2におけるSRM有無フラグF1,F2がオフとされ、またジェネレーションカウンタG1,G2、ジェネレーションカウンタ前値G1old、G2oldの各値が「0」とされる。
ステップF102では、NV−RAM43に格納されているSRMデータを読み出してRAM44に展開する。
そしてステップF103として、現在のSRMデータのバージョン情報を確保する。
以上で初期処理を終える。
4−3 SRM入力処理

図27は、SRMデータが受信される際のシステムコントローラ50の処理を示している。
SRMデータは、例えばバスの転送容量や他の通信状況などにより数回に分けられて送られてくることが多い。
システムコントローラ50は、SRMデータの入力が開始されたと判断すると、ステップF201からF202に進み、その入力元(送信元)を判別する。即ち図24の例の場合は、IEEE1394バス116を介して接続先の機器からの送信であるのか、或いはディスク91から読み出されてSACDドライブ200から送信されてきたものであるのかを判別する。そして判別結果を「n」とする。なお、この「n」とはバッファB1、B2を識別するB(n)に相当する。つまり、判別結果によってバッファB1、B2を選択する処理を意味している。本例の場合、IEEE1394バス116からのSRMデータ入力時にはバッファB1が選択され、ディスク91からのSRMデータ入力時にはバッファB2が選択される。
ステップF203では、入力されてくるSRMデータを、入力元に応じて選択したバッファB(n)に書き込んでいく。
ステップF204では、SRMデータが全てバッファリング完了したか否かを判別する。
ステップF205では、SRMデータの入力が途中で中断されるなどで、入力エラーとなり、バッファリングが完了できない事態となったか否かを判断する。例えばIEEE1394バス116としての接続ケーブルが途中で抜かれたりディスク上で読取エラーが発生して一部のSRMデータが読み出せなかったような事態である。
入力エラーとなった場合は、そのままバッファリング処理は終了する。
SRMデータのバッファリングが完了したら、ステップF206に進んでSRM有無フラグF(n)をオンとする。
またステップF207で、ジェネレーションカウンタG(n)をインクリメントする。
このような処理がSRMデータの入力が発生するたびに実行されることで、不定期に入力されるSRMデータはバッファB1又はB2に格納されるものとなる。
例えばIEEE1394バス116で接続された機器との間では、認証処理が行われ、その認証完了時点でSRMデータが送信されてくる。すると、図27の処理により、送信されてきたSRMデータがバッファB1に格納される。
また、ユーザーが、SRMデータが記録されたディスク91を装填した場合は、そのディスク91からSRMデータが読み出され、入力されてくる。その度に図27の処理が行われ、入力されたSRMデータがバッファB2に格納される。
図30,図31にSRMデータ入力の様子をタイムチャートで示す。
図30はIEEE1394バス116を介してSRMデータが入力される場合である。例えば接続された機器との間で認証処理が行われ、その直後、接続された機器からSRMデータが「1」〜「4」で示すように4回に分けて送られてきたとしている。
「1」〜「4」で示す各データは順次バッファB1に格納されていく。そしてSRMデータ全体が格納された時点で、上記ステップF206,F207の処理で、SRM有無フラグF1がオンとされ、またジェネレーションカウンタG1が「1」とされる。
なお、ジェネレーションカウンタ前値G1oldについては、後述する図29の処理によってバッファリングされたSRMデータがシステムコントローラ50に引き取られた時点でジェネレーションカウンタG1の値がコピーされる。
SRM有無フラグF1は、例えば次にSRMデータが入力される可能性が発生した時点でオフとされる。IEEE1394バス116からの入力の場合、認証処理が開始される時点などである。
例えば当該STR対応ディスクドライブ30が、更にIEEE1394バス116で接続されている他の機器と認証を開始する場合に、図示するようにSRM有無フラグF1はオフとされる。そして認証後、SRMデータが「1」〜「4」で示すように4回に分けて送られてきたとすると、図27の処理により、その「1」〜「4」で示す各データは順次バッファB1に格納されていく。そしてSRMデータ全体が格納された時点で、上記ステップF206,F207の処理で、SRM有無フラグF1がオンとされ、またジェネレーションカウンタG1が「2」にカウントアップされる。
図31はディスク91から再生されSACDドライブ200からSRMデータが入力される場合である。
例えばディスク91がSTR対応ディスクドライブ30に装填されると、まずTOC読出などが行われるが、その際にSRMデータも読み出され、システムコントローラ50に入力されるとする。このときSRMデータが「1」〜「5」で示すように5回に分けて送られてきたとしている。
「1」〜「5」で示す各データは順次バッファB2に格納されていく。そしてSRMデータ全体が格納された時点で、上記ステップF206,F207の処理で、SRM有無フラグF2がオンとされ、またジェネレーションカウンタG2が「1」とされる。
ジェネレーションカウンタ前値G2oldについては、上記同様に、後述する図29の処理によってバッファリングされたSRMデータがシステムコントローラ50に引き取られた時点でジェネレーションカウンタG2の値がコピーされる。
SRM有無フラグF2は、例えば次にSRMデータが入力される可能性が発生した時点でオフとされる。ディスク91からの入力の場合、ディスクが入れ換えられた時点、つまりディスク91がイジェクトされ、新たにディスク91が装填された時点などである。
例えばディスク入れ替えによって、図示するようにSRM有無フラグF2はオフとされる。そしてその後、新たに装填されたディスク91からSRMデータが読み出され「1」〜「5」で示すように5回に分けて送られてきたとすると、図27の処理により、その「1」〜「5」で示す各データは順次バッファB2に格納されていく。そしてSRMデータ全体が格納された時点で、上記ステップF206,F207の処理で、SRM有無フラグF2がオンとされ、またジェネレーションカウンタG2が「2」にカウントアップされる。
なお、SRM有無フラグF1、F2は、その入力経路毎に新たなSRMデータ入力が発生する可能性のある時点でオフとされるものとした。このためのシステムコントローラ50の処理は図28のようになる。
即ちステップF301でフラグオフの条件が発生したか否かを監視する。例えば他の機器との認証開始、或いはディスク91の入れ替えが当該条件となる。
フラグオフの条件が発生したらステップF302で、発生条件に応じて「n」をセットする。つまりバッファB1、B2のどちらを対象とするかを選択する。そしてステップF303でSRM有無フラグF(n)をオフとする。
従って、認証開始という条件が発生した場合であったら、バッファB1のSRM有無フラグF1がオフとされ、ディスク入れ替えという条件が発生した場合はバッファB2のSRM有無フラグF2がオフとされる。
SRM有無フラグF(n)はこのようにオフとされるが、例えば次に説明するSRM更新処理でバッファリングされたSRMデータをシステムコントローラ50が引き取る時点、或いは更新を行った時点などでオフとするようにしてもよい。
4−4 SRM更新処理

上記の図27のSRM入力処理により、SRMデータが入力されるたびに、その入力経路毎にバッファB1又はB2にSRMデータがバッファリングされる。
このようにバッファリングされるSRMデータに対しては、図29に示すSRM更新処理が実行される。
システムコントローラ50は、定期的に図29のF401からの処理を実行する。
まずステップF401では変数nを「1」とする。変数nは上記のようにバッファB(n)を選択する変数であり、図24の例の場合、バッファB1、B2の2つのバッファ領域が用意されるため、nは「1」又は「2」となる。この場合、nの最大値nMAXは「2」である。
ステップF402ではSRM有無フラグF(n)がオンであるか否かを判断する。まずn=1であるため、SRM有無フラグF1をチェックすることになる。
SRM有無フラグF(n)がオンであったら、ジェネレーションカウンタG(n)とジェネレーションカウンタ前値G(n)oldを比較する。この場合、G1>G1oldであるか否かを判断することになる。
いま、n=1の状態でステップF402でSRM有無フラグF1がオフであると判断された場合、或いはSRM有無フラグF1はオンであるがステップF403でG1>G1oldでないと判断された場合は、現在バッファB1には、当該SRM更新処理として未処理のSRMデータが格納されていないことを意味する。
この場合は、ステップF410に進んで、変数nをインクリメントし、ステップF411で変数nが最大値nMAXを越えていなければステップF402に戻る。この場合、変数n=2とされ、ステップF402に戻ることになる。そしてステップF402ではSRM有無フラグF2がオンであるか否かを判断し、またSRM有無フラグF2がオンであったら、ジェネレーションカウンタG2とジェネレーションカウンタ前値G2oldについて、G2>G2oldであるか否かを判断する。
この際に、ステップF402又はF403で否定結果となった場合は、現在バッファB2には、当該SRM更新処理として未処理のSRMデータが格納されていないことを意味する。このため、ステップF410に進んで、変数nをインクリメントし、ステップF411に進む。このとき変数n=3となり、変数nが最大値nMAXを越えるため、ステップF401に戻って変数n=1とし、ステップF402に進むことになる。つまり再びバッファB1についてのフラグ及びジェネレーションカウンタのチェックを行う。
このように図29のSRM更新処理は、バッファB1に対する処理とバッファB2に対する処理が交互に行われていくことになる。
ある時点で、ステップF402,F403で肯定結果が得られたとすると、それはバッファB(n)に未処理のSRMデータが格納されていることを意味する。そこで、システムコントローラ50はステップF404で、当該バッファB(n)に格納されるSRMデータを引き取る処理を行う。
これは図30,図31で「SRMデータ引取」として示したタイミングでの動作となる。図30,図31から、「SRMデータ引取」の直前は、SRM有無フラグF(n)がオンで、しかもG(n)>G(n)oldとなっていることがわかる。
続いてシステムコントローラ50は、ステップF405で、ジェネレーションカウンタG(n)の値をジェネレーションカウンタ前値G(n)oldにコピーする。図30,図31にその様子が示されている。
つまり上記ステップF403で判断されるG(n)>G(n)oldとは、SRMデータが新たにバッファリングされ、しかもまだシステムコントローラ50によって更新処理のために引き取られていない状態であるか否かを判断するものとなる。
続いてシステムコントローラ50は、ステップF406で、バッファB(n)から引き取ったSRMデータの正当性を判断する処理を実行する。
例えば図22で説明したようにSRMデータ内に記録されている電子署名(DTLA Signature)を確認する処理をおこなって正当なSRMデータであるか否かを判別する。
ここで、当該SRMデータの正当性が認められなかった場合は、ステップF407からF410に進み、更新を実行しない。
正当性が認められた場合は、ステップF407からF408に進み、今度は、当該SRMデータのバージョンと、現在保持しているSRMデータのバージョンを比較し、今回入力されたSRMデータが、現在保持しているSRMデータよりも新しいバージョンのものであるか否かを判断する。
もし今回入力されたSRMデータが、現在保持しているSRMデータよりも新しいバージョンでなければ、更新処理は必要ないため、ステップF408からF410に進む。
一方、今回入力されたSRMデータが、現在保持しているSRMデータよりも新しいバージョンであるなら、ステップF409に進み、システムコントローラ50は、NV−RAM43に記憶されているSRMデータを、今回入力されたSRMデータに書き換える更新処理を実行する。
上記図27の処理でバッファリングされたSRMデータが、このような図29の処理により、必要に応じて更新データとされることで、STR対応ディスクドライブ30において、次のような効果が得られ、適切且つ迅速なSRMデータの更新が実現される。
まず、SRMデータの入力経路が複数経路となることで、SRMデータの入力機会が増え、新しいバージョンのSRMデータが発行された後、早い時点でSRMデータが入力される可能性を高くできる。
また、IEEE1394バス116以外の経路でSRMデータが入力されることで、SRMデータの入力させるためにIEEE1394バス116対応の機器を用意しなくてもよい。特にこの例の場合、SRMデータを記憶したディスク91によって、新たなSRMデータを広く頒布できる。
なお、このように入力経路が複数用意されて入力機会を増やすためには、後述するように更に多様な入力経路が備えられることが好適である。もちろんSRMデータ更新の迅速性も、それによって向上される。
複数の入力経路から入力されたSRMデータは、入力経路毎にバッファリングされる。そしてシステムコントローラ50は、バッファリングされたSRMデータを図29の処理により常にチェックする。そして正当性及びバージョンチェックによって必要とされた場合のみに実際に更新処理が行われるようにするため、不適切な更新、例えば正当性が認められないSRMデータに更新されたり、古いバージョンのSRMデータに更新されたりすることはない。
また、SRMデータは図30,図31にも示したように、分割されて送信されてくることが多い。もし、複数の経路から同時的にSRMデータの入力があったような場合、データが錯綜することが考えられるが、本例のように入力経路毎にバッファ領域が確保されることで、一方の入力経路のデータが消失されたりすることなく、それぞれ正常な入力動作が可能となる。
さらに、ジェネレーションカウンタG(n)、ジェネレーションカウンタ前値G(n)oldによって、バッファリングされたSRMデータを更新処理に引き取るべきか否かが判断される。これによって、入力されバッファリングされた1つのSRMデータが、何度も更新処理の対象となるようなことはなく、処理の効率化が実現されている。
4−5 SRM入力経路例

次に、図32により、より多様な入力経路を備えた例を述べる。
図32は、上記図24のようなSTR対応ディスクドライブ30の構成において、さらに4つのSRMデータ入力経路を備えるようにしたものである。
STR対応ディスクドライブ30は図5に示したように、リモートコマンダRMからの操作コマンドを受信する受信部45を備えている。例えばこれを赤外線受信部とした場合、受信部45により図32に示すように、赤外線でSRMデータを送信出力するSRM書込装置94から、SRMデータを受信入力することができる。例えば図5の構成においてSRMデータが赤外線信号として受信部45に受信された場合、それがシステムコントローラ50に供給されることで、図32に示す赤外線受信部45によるSRMデータ入力経路が実現される。
また図32では、ICカードリーダ46を示している。これはICカード、メモリカード等のカードメディアに対して接触式或いは非接触式で情報を読み取る装置である。
例えばSRMデータがICカード92に格納されて提供される形態を考えた場合、ICカードリーダ46を備えるようにすることで、SRMデータの入力が可能となる。
また図32ではアンテナ57及びチューナ56を示している。例えばこのチューナ56は、SRM書込装置93から送信されるSRMデータを受信復調してシステムコントローラ50に供給するものとなる。
例えばチューナ56をFM/AM等のラジオチューナとして構成し、放送局がSRM書込装置93として機能して、ラジオ放送信号にSRMデータを重畳して送信するようにすることで、ラジオ放送によって広くSRMデータを提供し、電子機器は受信されたSRMデータを入力して更新することが可能となる。
もちろんラジオチューナではなく、テレビジョン放送、衛星放送等に対応するチューナとしたり、SRMデータ送受信の専用の周波数に対応するチューナとしたり、いわゆるブルートゥースなどの近距離無線通信用のチューナとしたり、多様な例が考えられる。
いずれにしても、無線通信によってSRMデータが入力される経路が実現され、またラジオ放送局などの広域放送組織がSRM書込装置93として機能する場合は、新たに発行されたSRMデータの頒布に非常に好適である。
また図32では、USBインターフェース58を示しており、USBケーブルによってSRM書込装置95としての外部機器と接続される状態を示している。
このようにIEEE1394バス接続での認証に用いるSRMデータを、USBのような他のインターフェース方式において接続された機器から入力できるようにすることも考えられる。
もちろんUSBではなく、MOST、コントロールA1など他の方式での接続も考えられる。
このように他のインターフェース方式によってSRMデータの入力を可能とすれば、SRM書込装置95としては、IEEE1394バスに対応していない機器でも実現できる。例えばパーソナルコンピュータ或いはその他の電子機器として、IEEE1394バスに対応していない機器も、SRM書込装置95として利用できるものとなる。
なおここでは外部バスとしてのUSB等を例示したが、機器内部のバスである、IIC経由で、或いはUARTやISAやPCIなどの内部バスでSRMデータを受信して更新処理に供することができるようにしてもよい。
この図32では以上のように、赤外線入力経路、カードメディアからの入力経路、電波送信による入力経路、IEEE1394バス以外のインターフェース方式の入力経路を例示した。従って上述したIEEE1394バスによる入力経路とディスク91からの入力経路と合わせて、6個の入力経路を備えた例としている。
この場合、RAM44におけるバッファ領域としては、各入力経路にそれぞれ対応してバッファB1〜B6が確保される。
そして各入力経路からのSRMデータの入力に応じて上記図27の処理により、対応するバッファB(n)にバッファリングしていくものとなる。
また、図29の処理としては、常にバッファB1〜B6を順次チェックするものとなり、それぞれにバッファリングされたSRMデータについては、正当性及びバージョンをチェックして、必要であれば、更新を実行するものとしている。
このように多様なSRMデータ入力経路が設けられることで、SRMデータの入力機会は増え、また入力されたSRMデータは混乱無くバッファリングされて必要に応じて更新データとされることで、例えばSTR対応ディスクドライブ30では、適正且つ迅速なSRMデータの更新が行われ、適切な著作権保護機能が実現されるものとなる。
なお、SRMデータの入力経路としては、更に多様に考えられる。
また、入力経路が多様化されることは、SRMデータの書込装置も多様化できることを意味する。即ち上記のように赤外線や電波の無線送信機、USB対応等の機器とできる。これはユーザーサイドでのSRMデータの更新時のみならず、電子機器製造メーカにおける、製品に対する出荷前のSRMデータの書込工程にも好適である。
即ちIEEE1394バス対応機器を用意しなくてもSRMデータ書込が可能となることで、IEEE1394バスを含めたもっとも使いやすい経路でSRMデータ書込(初期化)を行うことができ、工場でのSRM書込装置の開発も含めた形で出荷時の時間短縮に有用となる。またこれによって作業の効率化、容易化も実現される。
4−6 更新時のSRM送信処理

例えばSTR対応ディスクドライブ30を考えれば、上記のようなSRM更新処理により、各種経路で入力されたSRMデータにより、自身のNV−RAM43に記憶するSRMデータを更新できるが、さらには、外部機器に対してIEEE1394バス以外の経路でも新たなSRMデータを送信できるようにするとシステム上、好ましい。
そこで図33にSRMデータの送信系を備えた例を示す。この図33は、図24に示した構成に、電波送信部101,アンテナ102、赤外線送信部59を加えた例である。
電波送信部101は、システムコントローラ50の制御によって、SRMデータを外部機器に対してアンテナ102から電波送信する。
赤外線送信部59は、システムコントローラ50の制御によって、SRMデータを外部機器に対して赤外線変調信号として送信する。
この場合、システムコントローラ50は図34のSRM更新処理を行うようにする。なお、図34において図29と同一の処理については同一のステップ番号を付し、重複説明を避ける。
上述の通りSRM更新処理は、RAM44におけるバッファB(n)にバッファリングされたSRMデータをチェックし、必要に応じて更新する処理であるが、この図34の場合は、ステップF409でNV−RAM43におけるSRMデータの更新を行ったら、ステップF420として、そのSRMデータを送信出力するようにしているものである。
即ちシステムコントローラ50は、ステップF420として、更新データとなった新たなSRMデータを電波送信部101、及び/又は赤外線送信部59に供給し、所要の変調処理を実行させて電波又は赤外線により外部機器に送信するようにしている。
この場合、例えば図1のようにSTR対応ディスクドライブ30にIEEE1394バス116で接続された機器(或いは接続されていないが周辺に配置されている機器)において、図32に示したようにチューナ56や赤外線受信部45が設けられていることにより、それらの機器では新たなSRMデータの入力が行われることになる。
つまり、図33のSTR対応ディスクドライブ30が、図32に示したSRM書込装置93、94として機能することになる。
STR対応ディスクドライブ30は、上述したように基本的にはIEEE1394バス116で接続された機器との認証時に、IEEE1394バス116によりSRMデータを送信することとなるが、この図34のように更新時に電波や赤外線で周辺機器に送信することで、システム上の各機器はいち早くSRMデータを更新できるものとなり、著作権保護により好適である。例えば図1に示したようなシステムで認証が完了し、接続が確立されている後において、STR対応ディスクドライブ30がディスク91から新たなSRMデータを入力し、記憶するSRMデータの更新を行った場合、そのSRMデータが周辺機器に送信出力されることで、周辺機器も新たなSRMデータへの更新が可能となる。
なお、ステップF420では電波又は赤外線による送信の例を挙げたが、もちろんこの時点で、IEEE1394バス116により接続され通信状態が確立されている各機器に対して、IEEE1394バス116を介してSRMデータを送信するようにしてもよい。その場合、接続された機器が、赤外線や電波によるSRM入力経路を備えていない機器であっても対応できる。
また、図32に示したように、USBなど、他のインターフェース方式で接続された機器に対して、そのUSB等の伝送経路で送信するようにしてもよい。
以上、本発明の電子機器及び認証使用情報更新方法の実施の形態を、STR対応ディスクドライブ30、及びそれによるSRMデータ更新処理を例に挙げて説明したが、もちろん他の機器でも本発明は適用できる。
例えばSTR60でも当然に適用できる。
図4で説明したようにSTR60は、IEEE1394バスによる通信が可能とされ、またチューナ77を備えている。従って、IEEE1394バスからのSRMデータの入力経路以外に、チューナ77でSRMデータが受信されることによる入力経路が実現できる。また受信部89を入力経路とすることも可能である。
従ってシステムコントローラ70は、例えばRAM75にこれらの入力経路に対応するバッファ領域を確保し、入力に応じて図27のバッファリングを行うようにすればよい。それとともに図29のSRM更新処理を行うことで、必要に応じてNV−RAM74に格納しているSRMデータを更新することができる。
もちろんSTR60に送信機能を備えるようにし、図34で説明した処理を行うようにしてもよい。
また当然ながら、図32に例示したように、ICカードリーダやUSB等のインターフェースを備えるようにすることで、さらに多様な入力経路をSTR60において実現できる。
またSTR60に限らず、図1に示した機器100,110についても本発明は適用可能である。
本発明の実施の形態におけるAVシステムの構成例の説明図である。 STRのフロントパネルの正面図である。 STR対応ディスクドライブのフロントパネルの正面図である。 STRの内部構成例を示すブロック図である。 STR対応ディスクドライブの内部構成例を示すブロック図である。 本実施の形態に対応するIEEE1394のスタックモデルを示す説明図である。 IEEE1394に使用されるケーブル構造を示す説明図である。 IEEE1394における信号伝送形態を示す説明図である。 IEEE1394におけるバス接続規定を説明するための説明図である。 IEEE1394システム上でのNode ID設定手順の概念を示す説明図である。 IEEE1394におけるPacket送信の概要を示す説明図である。 Asynchronous通信における基本的な通信規則(トランザクションルール)を示す処理遷移図である。 IEEE1394バスのアドレッシング構造を示す説明図である。 CIPの構造図である。 プラグにより規定された接続関係例を示す説明図である。 プラグコントロールレジスタを示す説明図である。 Asynchronous通信において規定されるWrite Transactionを示す処理遷移図である。 Asynchronous Packet(AV/Cコマンドパケット)の構造図である。 Asynchronous Packetにおける、ctype/responceの定義内容を示す説明図である。 Asynchronous Packetにおける、subunit_typeと、opcodeの定義内容例を示す説明図である。 SRM発行の説明図である。 SRMのデータ内容の説明図である。 認証処理時のSRMの使用の説明図である。 実施の形態のSRMの入力及び更新の説明のためのブロック図である。 実施の形態の入力されたSRMのバッファメモリの説明図である。 実施の形態の初期処理のフローチャートである。 実施の形態のSRM受信処理のフローチャートである。 実施の形態のフラグ処理のフローチャートである。 実施の形態のSRM更新処理のフローチャートである。 実施の形態のSRM入力/更新時のタイムチャートである。 実施の形態のSRM入力/更新時のタイムチャートである。 実施の形態の多様なSRM入力経路の説明のためのブロック図である。 実施の形態のSRM出力の説明のためのブロック図である。 実施の形態のSRM出力を含むSRM更新処理のフローチャートである。
符号の説明
30 STR対応ディスクドライブ 50,70 システムコントローラ、60 STR、39,61 IEEE1394インターフェース、43,74 NV−RAM、44,75 RAM、116 IEEE1394バス、200 SACDドライブ

Claims (10)

  1. データバスを介して接続される外部電子機器と通信する通信手段と、
    上記通信手段で接続された上記外部電子機器との間で認証処理を行って通信状態を確立する認証手段と、
    上記認証処理において利用する情報である認証使用情報を記憶する認証使用情報記憶手段と、
    上記認証使用情報を入力する認証使用情報入力手段と、
    上記通信手段及び上記認証使用情報入力手段のそれぞれから入力される上記認証使用情報を、その入力経路毎に記憶するバッファメモリ手段と、
    上記バッファメモリ手段に入力経路毎に記憶された新たな認証使用情報について、情報内容についての正当性及びバージョン情報を判別し、その認証使用情報が正当なものと判別され、かつ、その認証使用情報が上記認証使用情報記憶手段に記憶されている認証使用情報よりも新しいバージョンであると判別されるとき、その認証使用情報を新たな認証使用情報として、上記認証使用情報記憶手段に記憶されている認証使用情報を更新する更新制御手段と、
    を備えていることを特徴とする電子機器。
  2. 上記認証使用情報入力手段は、記録媒体に対する読出部とされ、記録媒体に対する読出動作によって読み出された上記認証使用情報を入力することを特徴とする請求項1に記載の電子機器。
  3. 上記認証使用情報入力手段は、上記通信手段における所定の通信フォーマットとは異なる通信フォーマットによって接続された外部電子機器と通信可能な通信部とされ、該外部電子機器から送信される上記認証使用情報を入力することを特徴とする請求項1に記載の電子機器。
  4. 上記認証使用情報入力手段は、無線信号受信部とされ、外部電子機器から無線送信されてきた上記認証使用情報を受信して入力することを特徴とする請求項1に記載の電子機器。
  5. 外部電子機器に対して送信出力を行う送信手段を更に備え、
    上記更新制御手段は、上記バッファメモリ手段に記憶された認証使用情報を新たな認証使用情報として上記認証使用情報記憶手段に記憶されている認証使用情報を更新する際に、その新たな認証使用情報を上記送信手段により上記外部電子機器に送信出力させることを特徴とする請求項1に記載の電子機器。
  6. 所定の通信フォーマットによるデータバスを介して接続される外部電子機器との間で認証処理を行って通信状態を確立する電子機器における、上記認証処理の際に用いる認証使用情報の更新方法であって、
    各種入力経路から入力される上記認証使用情報を、その入力経路毎にバッファリング記憶し、
    各入力経路毎にバッファリング記憶された上記認証使用情報の情報内容についての正当性及びバージョン情報を判別し、
    その認証使用情報が正当なものと判別され、かつ、その認証使用情報が所定の記憶手段に記憶されている認証使用情報よりも新しいバージョンであると判別されるとき、上記バッファリング記憶された認証使用情報を新たな認証使用情報として、上記所定の記憶手段に記憶されている認証使用情報の更新を行うこと
    を特徴とする認証使用情報更新方法。
  7. 上記入力経路の1つは、記録媒体に対する読出動作によって上記認証使用情報が読み出されて入力される入力経路であることを特徴とする請求項に記載の認証使用情報更新方法。
  8. 上記入力経路の1つは、上記所定の通信フォーマットとは異なる通信フォーマットによって接続された外部電子機器から上記認証使用情報が送信されてくる入力経路であることを特徴とする請求項に記載の認証使用情報更新方法。
  9. 上記入力経路の1つは、外部電子機器から無線送信されてきた上記認証使用情報を受信して入力する入力経路であることを特徴とする請求項に記載の認証使用情報更新方法。
  10. 上記バッファリング記憶された認証使用情報を新たな認証使用情報として、上記認証処理に用いる認証使用情報の更新を行う際に、上記新たな認証使用情報を外部電子機器に対して送信出力することを特徴とする請求項に記載の認証使用情報更新方法。
JP2003278873A 2003-07-24 2003-07-24 電子機器、認証使用情報更新方法 Expired - Fee Related JP4404190B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2003278873A JP4404190B2 (ja) 2003-07-24 2003-07-24 電子機器、認証使用情報更新方法
US10/887,978 US7587593B2 (en) 2003-07-24 2004-07-12 Electronic device and method for updating authentication reference information
KR1020040056220A KR101088102B1 (ko) 2003-07-24 2004-07-20 전자기기와 인증 사용정보 갱신방법
EP04017385A EP1501255B1 (en) 2003-07-24 2004-07-22 Electronic device and method for updating authentication reference information

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2003278873A JP4404190B2 (ja) 2003-07-24 2003-07-24 電子機器、認証使用情報更新方法

Publications (2)

Publication Number Publication Date
JP2005045641A JP2005045641A (ja) 2005-02-17
JP4404190B2 true JP4404190B2 (ja) 2010-01-27

Family

ID=33487703

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003278873A Expired - Fee Related JP4404190B2 (ja) 2003-07-24 2003-07-24 電子機器、認証使用情報更新方法

Country Status (4)

Country Link
US (1) US7587593B2 (ja)
EP (1) EP1501255B1 (ja)
JP (1) JP4404190B2 (ja)
KR (1) KR101088102B1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090070883A1 (en) * 2004-09-17 2009-03-12 Mark Kenneth Eyer System renewability message transport
US8015613B2 (en) * 2004-09-17 2011-09-06 Sony Corporation System renewability message transport
KR101346734B1 (ko) * 2006-05-12 2014-01-03 삼성전자주식회사 디지털 저작권 관리를 위한 다중 인증서 철회 목록 지원방법 및 장치
US20080052510A1 (en) * 2006-05-12 2008-02-28 Samsung Electronics Co., Ltd. Multi certificate revocation list support method and apparatus for digital rights management
JP2008236456A (ja) * 2007-03-22 2008-10-02 Brother Ind Ltd プリンタ複合機、プリントシステム、及び、静止画像印刷プログラム
US7940553B2 (en) * 2008-12-30 2011-05-10 Stmicroelectronics S.R.L. Method of storing an indication of whether a memory location in phase change memory needs programming
JP4906005B2 (ja) * 2009-09-30 2012-03-28 Necアクセステクニカ株式会社 端末機器の管理方法、システム及びプログラム
US8516551B2 (en) * 2010-07-28 2013-08-20 Intel Corporation Providing a multi-phase lockstep integrity reporting mechanism
JP5487299B2 (ja) * 2010-09-17 2014-05-07 株式会社東芝 操作情報生成装置および操作情報生成方法
JP5620781B2 (ja) * 2010-10-14 2014-11-05 キヤノン株式会社 情報処理装置、その制御方法、及びプログラム
US9185161B2 (en) * 2012-12-31 2015-11-10 General Electric Company Systems and methods for synchronizing non-destructive testing devices
KR101528480B1 (ko) * 2014-11-19 2015-06-12 한국과학기술정보연구원 햅틱 서버와 가상현실 서버의 연계를 위한 통신구조
WO2019136675A1 (zh) * 2018-01-11 2019-07-18 华为技术有限公司 一种终端设备、dsd音频播放电路和方法
CN113556231B (zh) * 2021-06-16 2024-04-09 南京南瑞继保工程技术有限公司 基于iec61850控制模型的控制信息安全鉴别方法

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
BR8406089A (pt) * 1983-11-30 1985-09-24 Fujitsu Ltd Processo para controlar memoria intermediaria em aparelho de processamento de dados
US4916658A (en) * 1987-12-18 1990-04-10 International Business Machines Corporation Dynamic buffer control
US5761166A (en) * 1994-05-06 1998-06-02 Sedlmayr; Steven R. Method and system for simultaneous storage and/or retrieval (storval) of a plurality of data on a disk means
JPH096660A (ja) * 1995-06-21 1997-01-10 Hitachi Ltd 複数部門における共通データの相関チェック方法
US6587581B1 (en) * 1997-01-10 2003-07-01 Hitachi, Ltd. Visual inspection method and apparatus therefor
US5841695A (en) * 1997-05-29 1998-11-24 Lsi Logic Corporation Memory system using multiple storage mechanisms to enable storage and retrieval of more than two states in a memory cell
US6061449A (en) * 1997-10-10 2000-05-09 General Instrument Corporation Secure processor with external memory using block chaining and block re-ordering
JP4496440B2 (ja) 1998-01-12 2010-07-07 ソニー株式会社 暗号化コンテンツ送信装置
US6954859B1 (en) * 1999-10-08 2005-10-11 Axcess, Inc. Networked digital security system and methods
JP2002118558A (ja) 2000-10-10 2002-04-19 Sony Corp 情報処理装置および方法、並びにプログラム格納媒体
JP4224262B2 (ja) 2001-07-09 2009-02-12 パナソニック株式会社 デジタル情報保護システム、記録媒体装置、送信装置及び再生装置
JP2003037591A (ja) 2001-07-25 2003-02-07 Toshiba Corp 中継機器及び方法
US6748488B2 (en) * 2001-09-28 2004-06-08 Sun Microsystems, Inc. Storage array having multiple erasure correction and sub-stripe writing
JP4213452B2 (ja) 2001-10-30 2009-01-21 パナソニック株式会社 データ処理システム
CN1692600A (zh) * 2002-10-09 2005-11-02 松下电器产业株式会社 加密装置、解密装置和加密系统
US7263648B2 (en) * 2003-01-24 2007-08-28 Wegener Communications, Inc. Apparatus and method for accommodating loss of signal

Also Published As

Publication number Publication date
US20050050321A1 (en) 2005-03-03
KR101088102B1 (ko) 2011-11-29
EP1501255A2 (en) 2005-01-26
KR20050012136A (ko) 2005-01-31
JP2005045641A (ja) 2005-02-17
EP1501255A3 (en) 2008-01-02
EP1501255B1 (en) 2013-02-20
US7587593B2 (en) 2009-09-08

Similar Documents

Publication Publication Date Title
JP4449141B2 (ja) 電源制御装置、電源制御システム
JP4403331B2 (ja) 電子機器システム、情報処理機器
US7130945B2 (en) Controlling method for transmitting reserve commands from a controller to target devices
JP4404190B2 (ja) 電子機器、認証使用情報更新方法
JP4281201B2 (ja) 制御装置、及び制御方法
KR101165316B1 (ko) 수신장치 및 수신방법
JP4225151B2 (ja) 電子機器、フォーマット方法
JP2001006276A (ja) 外部機器の制御装置、及び外部機器の制御方法
JP4831157B2 (ja) フォーマット指示方法
JP2003289304A (ja) 信号処理装置、信号処理方法
JP4055313B2 (ja) 再生装置、及び情報伝送方法
JP2003283502A (ja) 情報通信装置、情報通信方法
JP2000357386A (ja) 編集装置及び操作装置
JP2002033751A (ja) 電子機器、電子機器管理方法
JP2001236772A (ja) 電子機器システム、電子機器
JP2001250370A (ja) 電子機器システム、及び電子機器

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061031

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20070123

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20070222

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070326

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20070402

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20070413

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20091027

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121113

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121113

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131113

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees