(57)【特許請求の範囲】
【請求項１】
少なくともアプリケーションプログラムが記録された一方の記録媒体から他の記録媒体へ前記アプリケーションプログラムのインストールを行なうためのインストール動作管理方法として、
インストール実行に応じてインストール実行回数情報を前記一方の記録媒体の記録再生領域にインストール管理データとして第１のドライブ装置に記録する動作を実行させ、
前記一方の記録媒体に記録されたアプリケーションプログラムを他の記録媒体へのインストールする要求があった場合は、前記一方の記録媒体に記録されている過去のインストール実行回数情報を確認し、そのインストール実行回数情報が所定回数値未満であった場合のみに、インストールを実行するとともに、
前記一方の記録媒体からアプリケーションプログラムをインストールした先の他の記録媒体から、そのアプリケーションプログラムをアンインストールする要求があった際に、前記他の記録媒体を駆動する第２のドライブ装置を制御し、前記他の記録媒体から前記アプリケーションプログラムをアンインストールさせるとともに、前記記録再生領域に記録されている前記インストール管理データとしてのインストール実行回数情報を減算更新する動作を前記第１のドライブ装置に実行させること
を特徴とするインストール動作管理方法。
【請求項２】
前記アプリケーションプログラムを他の記録媒体へのインストール動作に伴って、前記他の記録媒体を特定するための照合情報を、前記インストール管理データとして前記記録再生領域に記録するよう前記第１のドライブ装置に実行させるとともに、
アプリケーションプログラムのアンインストール要求があった際に、前記記録再生領域に記録されている前記照合情報を参照し、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムが、当該記録媒体からインストールされたアプリケーションプログラムでないと判断した場合は、アンインストール要求に関わらず、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムについての前記第２のドライブ装置によるアンインストール動作を実行させないこと
を特徴とする請求項１に記載のインストール動作管理方法。
【請求項３】
前記照合情報は、前記アプリケーションプログラムを他の記録媒体にインストールした際の日時情報であることを特徴とする請求項２に記載のインストール動作管理方法。
【請求項４】
前記照合情報は、前記第２のドライブ装置によって前記他の記録媒体にインストールされたアプリケーションプログラムのディレクトリ情報であることを特徴とする請求項２に記載のインストール動作管理方法。
【請求項５】
前記照合情報は、前記アプリケーションプログラムの他の記録媒体へのインストールを実行した前記第２のドライブ装置及び／又は前記他の記録媒体の個体情報であることをを特徴とする請求項２に記載のインストール動作管理方法。
【請求項６】
少なくともアプリケーションプログラムが記録された一方の記録媒体から他の記録媒体へ前記アプリケーションプログラムのインストールを行なうためのインストール動作管理を行うドライブ装置として、
前記一方の記録媒体を駆動するドライブ装置は、インストール制御手段を備え、
該インストール制御手段は、インストール実行に応じてインストール実行回数情報を前記一方の記録媒体の記録再生領域にインストール管理データとして前記ドライブ装置に記録する動作を実行させ、
前記一方の記録媒体に記録されたアプリケーションプログラムを他の記録媒体へのインストールする要求があった場合は、前記一方の記録媒体に記録されている過去のインストール実行回数情報を確認し、そのインストール実行回数情報が所定回数値未満であった場合のみに、インストールを実行するとともに、
前記一方の記録媒体からアプリケーションプログラムをインストールした先の他の記録媒体から、そのアプリケーションプログラムをアンインストールする要求があった際に、前記他の記録媒体を駆動するドライブ装置のドライブ手段を制御し、前記他の記録媒体から前記アプリケーションプログラムをアンインストールさせるとともに、前記記録再生領域に記録されている前記インストール管理データとしてのインストール実行回数情報を減算更新する動作を前記ドライブ装置に実行させること
を特徴とするドライブ装置。
【請求項７】
前記インストール制御手段は、前記アプリケーションプログラムを他の記録媒体へのインストール動作に伴って、前記他の記録媒体を特定するための照合情報を、前記インストール管理データとして前記記録再生領域に記録するよう前記ドライブ装置に実行させるとともに、
アプリケーションプログラムのアンインストール要求があった際に、前記記録再生領域に記録されている前記照合情報を参照し、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムが、当該記録媒体からインストールされたアプリケーションプログラムでないと判断した場合は、アンインストール要求に関わらず、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムについての前記他の記録媒体を駆動するドライブ装置のドライブ手段によるアンインストール動作を実行させないこと
を特徴とする請求項６に記載のドライブ装置。
【請求項８】
前記照合情報は、前記アプリケーションプログラムを他の記録媒体にインストールした際の日時情報であることを特徴とする請求項７に記載のドライブ装置。
【請求項９】
前記照合情報は、前記第２のドライブ装置によって前記他の記録媒体にインストールされたアプリケーションプログラムのディレクトリ情報であることを特徴とする請求項７に記載のドライブ装置。
【請求項１０】
前記照合情報は、前記アプリケーションプログラムの他の記録媒体へのインストールを実行した前記第２のドライブ装置及び／又は前記他の記録媒体の個体情報であることをを特徴とする請求項７に記載のドライブ装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばコンピュータソフトウエア等を収録するのに適した記録媒体、及びその記録媒体に記録されるアプリケーションプログラムのハードディスク等の他の記録媒体へのインストール動作に関する管理方法に関するものである。
【０００２】
【従来の技術】
コンピュータ機器に用いる各種のソフトウエアを光ディスク、光磁気ディスク、磁気ディスク、メモリカード、磁気テープなどの記録媒体を用いて提供することが行なわれている。
このような記録媒体の一種として、近年、パーシャルＲＯＭディスクといわれるメディアが開発されており、このパーシャルＲＯＭディスクは再生専用のＲＯＭ領域と、記録／再生可能なリライタブル領域（ＲＡＭ領域）を有するものとされている。
【０００３】
【発明が解決しようとする課題】
ところで、ソフトウエアとしてのアプリケーションプログラムを提供する際には、そのアプリケーションプログラムを記録したメディアを購入した正当なユーザーのみが使用できるようにすることが好ましい。
【０００４】
ＣＤ−ＲＯＭなどの形態で提供されるソフトウエアメディアでは、通常、ユーザーはそのメディアに記録されているアプリケーションを、自分の所有するパーソナルコンピュータにおけるハードディスクにインストールして使用することになる。そして、例えば或るユーザーがアプリケーションを自分のコンピュータにインストールした後、そのメディアを他人に貸与すれば、その人のコンピュータにもアプリケーションをインストールすることができる。
つまり１枚のメディアを使用して次々とインストールすることでアプリケーション自体が無制限に不正提供されてしまうという問題がある。
【０００５】
【課題を解決するための手段】
本発明はこのような問題点に鑑みて、例えば上述したパーシャルＲＯＭディスクのように、少なくとも、記録再生領域を有するとともに、アプリケーションプログラムが記録された記録媒体に関し、無制限にインストールが行なわれてしまうことを防止することで、不正使用を解消することを目的とする。
【０００６】
このために少なくともアプリケーションプログラムが記録された一方の記録媒体から他の記録媒体へ前記アプリケーションプログラムのインストールを行なうためのインストール動作管理方法として、インストール実行に応じてインストール実行回数情報を前記一方の記録媒体の記録再生領域にインストール管理データとして第１のドライブ装置に記録する動作を実行させ、前記一方の記録媒体に記録されたアプリケーションプログラムを他の記録媒体へのインストールする要求があった場合は、前記一方の記録媒体に記録されている過去のインストール実行回数情報を確認し、そのインストール実行回数情報が所定回数値未満であった場合のみに、インストールを実行するとともに、前記一方の記録媒体からアプリケーションプログラムをインストールした先の他の記録媒体から、そのアプリケーションプログラムをアンインストールする要求があった際に、前記他の記録媒体を駆動する第２のドライブ装置を制御し、前記他の記録媒体から前記アプリケーションプログラムをアンインストールさせるとともに、前記記録再生領域に記録されている前記インストール管理データとしてのインストール実行回数情報を減算更新する動作を前記第１のドライブ装置に実行させる。
【０００７】
さらに、前記アプリケーションプログラムを他の記録媒体へのインストール動作に伴って、前記他の記録媒体を特定するための照合情報を、前記インストール管理データとして前記記録再生領域に記録するよう前記第１のドライブ装置に実行させるとともに、アプリケーションプログラムのアンインストール要求があった際に、前記記録再生領域に記録されている前記照合情報を参照し、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムが、当該記録媒体からインストールされたアプリケーションプログラムでないと判断した場合は、アンインストール要求に関わらず、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムについての前記第２のドライブ装置によるアンインストール動作を実行させないようにインストール動作管理する。
【０００８】
また、少なくともアプリケーションプログラムが記録された一方の記録媒体から他の記録媒体へ前記アプリケーションプログラムのインストールを行なうためのインストール動作管理を行うドライブ装置として、前記一方の記録媒体を駆動するドライブ装置は、インストール制御手段を備え、該インストール制御手段は、インストール実行に応じてインストール実行回数情報を前記一方の記録媒体の記録再生領域にインストール管理データとして前記ドライブ装置に記録する動作を実行させ、前記一方の記録媒体に記録されたアプリケーションプログラムを他の記録媒体へのインストールする要求があった場合は、前記一方の記録媒体に記録されている過去のインストール実行回数情報を確認し、そのインストール実行回数情報が所定回数値未満であった場合のみに、インストールを実行するとともに、前記一方の記録媒体からアプリケーションプログラムをインストールした先の他の記録媒体から、そのアプリケーションプログラムをアンインストールする要求があった際に、前記他の記録媒体を駆動するドライブ装置のドライブ手段を制御し、前記他の記録媒体から前記アプリケーションプログラムをアンインストールさせるとともに、前記記録再生領域に記録されている前記インストール管理データとしてのインストール実行回数情報を減算更新する動作を前記ドライブ装置に実行させる。
【０００９】
さらに、前記インストール制御手段は、前記アプリケーションプログラムを他の記録媒体へのインストール動作に伴って、前記他の記録媒体を特定するための照合情報を、前記インストール管理データとして前記記録再生領域に記録するよう前記ドライブ装置に実行させるとともに、アプリケーションプログラムのアンインストール要求があった際に、前記記録再生領域に記録されている前記照合情報を参照し、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムが、当該記録媒体からインストールされたアプリケーションプログラムでないと判断した場合は、アンインストール要求に関わらず、そのアンインストール対象とされた他の記録媒体のアプリケーションプログラムについての前記他の記録媒体を駆動するドライブ装置のドライブ手段によるアンインストール動作を実行させないようにする。
【００１０】
【発明の実施の形態】
以下、本発明の記録媒体及びインストール動作管理方法としての実施の形態を次の順序で説明していく。なお本例では記録媒体の例としてパーシャルＲＯＭディスクをあげる。
１．パーシャルＲＯＭディスクのエリア構造
２．フォーマット動作
３．記録再生装置の構成
４．システム動作
５．インストール時の動作
６．アンインストール時の動作
７．各種ディスク例
【００１１】
１．パーシャルＲＯＭディスクのエリア構造
図１は各種ディスクメディアを図示したものであり、図１（ａ）は主データ領域全体が例えばエンボスピットなどによる再生専用領域（ＲＯＭ領域）ＡＥとされているＲＯＭディスクである。また図１（ｂ）は主データ領域全体が例えば光磁気領域などによる記録／再生可能なリライタブル領域ＡＲＷとされているＲＡＭディスクである。
本例の記録媒体となるパーシャルＲＯＭディスクは例えば図１（ｃ）または（ｄ）のような構造を持つ。即ち１枚のディスクの主データ領域においてＲＯＭ領域ＡＥとリライタブル領域ＡＲＷが設けられているものである。
【００１２】
図２は、パーシャルＲＯＭディスクの外周側から内周側までのエリア構成を示したものである。
ディスク最外周側には７３６トラック分のＧＣＰゾーンが設けられ、内周側に向かって２トラック分のバッファゾーン、５トラック分のアウターコントロールゾーン、２トラック分のバッファゾーン、５トラック分のテストゾーンが設けられる。そしてそのテストゾーンに続いて、ユーザーが所望のデータの記録を行なうことができるリライタブル領域ＡＲＷ及び再生専用のＲＯＭ領域ＡＥから成る主データ領域としてのユーザーエリアが形成される。
【００１３】
ユーザーエリアより内周側には５トラック分のテストゾーン、２トラック分のバッファゾーン、５トラック分のインナーコントロールゾーン、２トラック分のバッファゾーン、８２０トラック分のＧＣＰゾーンが設けられる。
【００１４】
ＧＣＰゾーン、アウターコントロールゾーン、インナーコントロールゾーンは、それぞれ所定のコントロール情報が記録されるエリアとされている。
また、このパーシャルＲＯＭディスクはいわゆるゾーンＣＡＶディスクとされており、ユーザーエリアは１６バンド（１６ゾーン）に分割されている。
１６バンドのうち幾つをリライタブル領域ＡＲＷとし、幾つをＲＯＭ領域ＡＥとするかは製造者側で任意に設定できる。
【００１５】
１６バンドで形成されるユーザーエリアについて、リライタブル領域ＡＲＷの構成を詳しく示したものが図３（ａ）（ｂ）である。図３（ａ）はユーザーエリアにおけるディスク外周側にリライタブル領域ＡＲＷが設けられた場合、図３（ｂ）はディスク内周側にリライタブル領域ＡＲＷが設けられた場合をそれぞれ示している。
各図からわかるようにリライタブル領域ＡＲＷの先頭にはディフェクトマネジメントエリアＤＭＡ１，ＤＭＡ２が設けられ、またリライタブル領域ＡＲＷの終端にディフェクトマネジメントエリアＤＭＡ３，ＤＭＡ４が設けられる。またＲＯＭ領域ＡＥと隣接する領域はバッファエリアとされている。
【００１６】
そして、１バンド毎にデータエリアと、そのデータエリアに対応する交代エリアが用意される。従ってリライタブル領域ＡＲＷが１６バンドの内のｎバンド分とされる場合は、ｎ単位のデータエリアと、ｎ単位の交代エリアが設けられる。交代エリアとは、データエリア内において傷などで記録／再生不能となるディフェクト部位が存在していた場合に、そのディフェクト部位に代えて用いられる部位を提供するエリアとされる。
【００１７】
例えば図３（ａ）に『×』として示すようにデータエリア内にディフェクト部位が存在した場合、その『×』部位に代わる記録領域が矢印で示すように交代エリア内の領域に設定される。
ディフェクトマネジメントエリアＤＭＡ１〜ＤＭＡ４は、このような交代状況を管理し、ディフェクト部位を避けた記録／再生が適正に行なわれるようにする情報が記録されるものである。
【００１８】
なお、データエリア内のディフェクト部位の検索、ディフェクト部位に代わる交代エリア上の部位の指定、ディフェクトマネジメントエリアＤＭＡ１〜ＤＭＡ４としての情報の作成及びリライタブル領域ＡＲＷへの記録等は、ディスクの物理フォーマット処理において行なわれることになり、つまり物理フォーマットによって図３（ａ）又は（ｂ）の状態とされることで、リライタブル領域ＡＲＷが物理的に記録／再生可能な状態とされる。
ただし実際にリライタブル領域ＡＲＷに対してファイル書込等を行なうには、物理フォーマットされたディスクに対してさらに論理フォーマットを施し、リライタブル領域ＡＲＷでの記録／再生を管理するファイルシステムを書き込まなければならない。即ち、物理フォーマットと論理フォーマットが行なわれることで、実際にユーザーが、パーシャルＲＯＭディスクをリライタブル領域ＡＲＷを用いたソフトウエアメディアとして使用できることになる。
【００１９】
２．フォーマット動作
パーシャルＲＯＭディスクに対するフォーマット動作例を説明する。
物理フォーマットがされる前のディスク状態を図４（ａ）（ｂ）に示す。図４（ａ）はユーザーエリアにおける外周側がリライタブル領域ＡＲＷ、図４（ｂ）はユーザーエリアにおける内周側がリライタブル領域ＡＲＷとされている場合をそれぞれ示している。
【００２０】
フォーマットが行われていない段階ではリライタブル領域ＡＲＷは単に光磁気領域とされており、実際上の領域管理は行なわれていない状態であるが、例えばエンボスピットによりデータが記録されるＲＯＭ領域ＡＥは、既に必要なデータが記録された状態となっている。
【００２１】
通常、ＲＯＭ領域ＡＥに記録されるデータとしては、ＲＯＭ領域ＡＥにおけるデータ管理情報となるファイルシステムと、そのファイルシステムに基ずいて読み出すことのできるアプリケーションプログラム（以下、単にアプリケーションという）等であるが、このフォーマット動作例に対応するパーシャルＲＯＭディスクのＲＯＭ領域ＡＥには、図４（ｃ）に示すように、ＲＯＭ領域ＡＥの先頭にファイルシステムＦＳ１が記録され、続いて、そのファイルシステムＦＳ１に基づいて読み出すことのできるセットアップシステム及びアプリケーションＡＰが記録されている。
【００２２】
セットアップシステムはディスクの論理フォーマットのためのツールとされるもので、例えば図１１で後述するような記録再生装置にディスクを装填した状態でホストコンピュータからセットアップシステムを起動させることで、リライタブル領域ＡＲＷを使用可能とする論理フォーマットが実行される。
システム構成例及びシステム動作については後述するが、このパーシャルＲＯＭディスクは、ユーザーサイドではホストコンピュータに接続された記録再生装置に装填されて用いられることになり、例えばユーザーサイドには物理フォーマット済のディスクが提供される。
そして、ユーザーサイドのシステムによりディスクに対する初期動作として、論理フォーマットが行われるものである。
【００２３】
ただし、このようなパーシャルＲＯＭディスクの物理フォーマット及び論理フォーマットについて図４から図１０を用いて説明するが、各フォーマット動作を実行するシステムとしては、メーカーサイドのシステム（ホストコンピュータ及び記録再生装置）であってもユーザーサイドのシステムであっても可能である。そしてソフトウエアメディアの提供形態の１つとして、メーカーサイドで物理フォーマットが行われ、ユーザーサイドで論理フォーマットが行われる方式が考えられるものである。
また、図７から図９での動作の説明として、その説明上「記録再生装置」が実行するとしている処理は、実際にはディスクからホストコンピュータ側に読み込まれたファイルシステム及びセットアップシステムによって制御されるデバイスドライバが記録再生装置に対して所要のリード／ライトを要求することで実行される動作処理のことである。なお、このようなシステム動作形態は後に詳述する。
【００２４】
物理フォーマットが行なわれる前の状態においては、ディスク上のユーザーエリアの先頭位置がそのままアドレス０と判断されるため、図４（ａ）の場合はリライタブル領域ＡＲＷの先頭がアドレス０、図４（ｂ）の場合はＲＯＭ領域ＡＥの先頭がアドレス０、となる。
【００２５】
図４（ａ）（ｂ）のようなディスクは、物理フォーマットが行なわれてそれぞれ図５（ａ）（ｂ）に示す状態とされた上でソフトウエアメディアとして出荷される。
即ち物理フォーマットにより、リライタブル領域ＡＲＷにおける、データエリア内のディフェクト部位の検索、ディフェクト部位に代わる交代エリア上の部位の指定、ディフェクトマネジメントエリアＤＭＡ１〜ＤＭＡ４としての情報の作成が行なわれ、リライタブル領域ＡＲＷが物理的に記録／再生可能な状態とされて出荷されることになる。
【００２６】
そしてこの物理フォーマットの際の処理は、物理フォーマットを行なうドライバ（記録再生装置及びそれを制御するホストコンピュータ）によって図７のような処理で行なわれる。即ち物理フォーマット（Ｆ３００）が開始されたら、その対象となるパーシャルＲＯＭディスクに或る所定のフラグをセットし（Ｆ３０１）、その後、上述のディフェクトマネジメントのような実際のフォーマット処理が行なわれる（Ｆ３０２）。なお、ステップＦ３０１とＦ３０２の順序は逆でもよいが、いずれにしても物理フォーマットに伴ってフラグがセットされる。
【００２７】
フラグは、例えばリライタブル領域ＡＲＷの先頭セクター内のベンダーユニークと呼ばれるエリアに書き込むようにしてもよいし、ディフェクトマネージメントエリア内におけるリザーブエリアを用いてもよい。いずれれにしても予め設定した所定位置にフラグがセットされればよい。
フラグがセットされることにより、そのディスクが装填される記録再生装置では、図５（ａ）（ｂ）に示すように、ディスクに対してＲＯＭ領域ＡＥの先頭をアドレス０として認識する。
【００２８】
例えばこのように物理フォーマットが行なわれ、フラグがセットされたパーシャルＲＯＭディスクが出荷されることになるが、例えばユーザーサイドの記録再生装置（及びホストコンピュータ）ではパーシャルＲＯＭディスクが装填された場合に、まず図８の処理を行なう。即ちディスク装填（Ｆ４００）に応じて、例えばリライタブル領域ＡＲＷの先頭位置などの所定位置に記録されているフラグを読込、そのフラグ状態を保存する（Ｆ４０１）。
【００２９】
図１０のようにホストコンピュータにより何らかのリード／ライトコマンドが発生された場合は（Ｆ６００）、記録再生装置はフラグを確認し（Ｆ６０１）、フラグがオンであった場合はステップＦ６０２からＦ６０３に進む。そしてディスクのＲＯＭ領域ＡＥの先頭がアドレス０となるようにアドレス変換を行ない、ステップＦ６０５で、要求された記録又は再生動作を実行することになる。
従って、物理フォーマットが行なわれた段階でのディスクは、フラグがオンであるため、記録再生装置は図５（ａ）（ｂ）のようにＲＯＭ領域ＡＥの先頭をアドレス０として認識し、まずＲＯＭ領域ＡＥの先頭領域に対するアクセスを実行することになる。
【００３０】
上記のように物理フォーマットが行なわれたディスクに対しては、例えばユーザサイドのシステムであるホストコンピュータ及び記録再生装置が論理フォーマットを行なうことができる。
ホストコンピュータからの制御に基づく論理フォーマット処理を図９に示す。
【００３１】
論理フォーマット処理が開始されるとＦ５００、まず記録再生装置はディスクのアドレス０にアクセスする。この時点でアドレス０はＲＯＭ領域ＡＥの先頭とみなされているため、ＲＯＭ領域ＡＥの先頭に記録されているファイルシステムＦＳ１の読み出しを実行することになる。
そしてＲＯＭ領域ＡＥを管理するファイルシステムＦＳ１を読み込むことでホストコンピュータはＲＯＭ領域ＡＥに記録されているセットアップシステムを把握でき、セットアップシステムを起動させる（Ｆ５０１）。
【００３２】
ＲＯＭ領域ＡＥに記録されているセットアップシステムは、いわゆる論理フォーマットツールであり、これに基づいてホストコンピュータはリライタブル領域ＡＲＷ及びＲＯＭ領域ＡＥのアプリケーションの管理のためのファイルシステムＦＳ２をリライタブル領域ＡＲＷの先頭領域に書き込ませる（Ｆ５０２）。
なお、ファイルシステムＦＳ２を構成するデータは、あらかじめセットアップシステム内に記録されていることにより、セットアップシステムの起動によってファイルシステムＦＳ２の書込が可能となる。
【００３３】
ステップＦ５０２までの処理により、図５（ａ）のようなディスクは図６（ａ）上段のようになり、また図５（ｂ）のようなディスクは図６（ｂ）上段のようになる。つまりファイルシステムＦＳ２が書き込まれることによりリライタブル領域ＡＲＷでの記録／再生管理が可能な状態となる。
【００３４】
続いてホストコンピュータはステップＦ５０３として、物理フォーマット時にセットされたフラグをクリアする。
そしてリセットして再起動、もしくはディスクを一旦抜いてから再度装填することをユーザーに要求して処理を終える（Ｆ５０４）。
【００３５】
リセットもしくはディスク抜き差し後においては、まず図８の処理でフラグが読み込まれるため、論理フォーマットが済んだディスクであれば、フラグオフと判断される。
従って、図１０のようにそのディスクに対してホストコンピュータにより何らかのリード／ライトコマンドが発生された場合は（Ｆ６００）、記録再生装置はフラグを確認し（Ｆ６０１）、フラグがオフであるためステップＦ６０２からＦ６０４に進んで、ディスクのリライタブル領域ＡＲＷの先頭がアドレス０となるようにアドレス変換を行ない、ステップＦ６０５で、要求された記録又は再生動作を実行することになる。
【００３６】
つまり論理フォーマットが行なわれた段階でのディスクに対しては、記録再生装置からは図６（ａ）（ｂ）の各下段に示すようにリライタブル領域ＡＲＷの先頭がアドレス０として認識され、従ってリード／ライト要求発生時にはまずファイルシステムＦＳ２がアクセスされることになる。ファイルシステムＦＳ２がＲＯＭ領域ＡＥのファイル管理とリライタブル領域のファイル及び未記録領域の管理を行う管理情報であることにより、ホストコンピュータはＲＯＭ領域ＡＥからのデータファイル読出に加えて、リライタブル領域ＡＲＷでの所望のデータ記録／再生が可能となる。
【００３７】
なお、ホストコンピュータの機種によっては、一旦装填したメディアから読み込んだファイルシステムを、リセット時にも保存しておくものもある。この場合、論理フォーマット後に再起動させても、論理フォーマット前に読み込んだファイルシステムＦＳ１に基づいて起動を行なってしまう。そこで、このような機種に対応する場合は、図９のステップＦ５０５としてファイルシステムの変更を伝え、以降の再起動時には、新たにファイルシステムを読み込むようにしておく。つまりファイルシステムＦＳ２が読み込まれるようにする。
【００３８】
以上のようにこのフォーマット方式では、物理フォーマットがされた時点でフラグがセットされ、記録再生装置はこのフラグセットにより、ＲＯＭ領域ＡＥの先頭をアドレス０とみなす。従ってその時点でＲＯＭ領域ＡＥの先頭に記録されているファイルシステムＦＳ１にアクセスし、ＲＯＭ領域ＡＥ内のアプリケーションＡＰを起動させることができる。つまりセットアップシステムを起動させて論理フォーマットを行なうこと、及びこの時点でディスクをＲＯＭメディアとして使用することが可能である。
【００３９】
また論理フォーマットが行なわれた場合は、それに伴ってフラグがクリアされ、記録再生装置はこのフラグクリアにより、リライタブル領域ＡＲＷの先頭をアドレス０とみなす。従って論理フォーマット後ではリライタブル領域ＡＲＷの先頭に記録されているファイルシステムＦＳ２にアクセスでき、つまりＲＯＭ領域ＡＥに加えてリライタブル領域ＡＲＷの使用が可能となる。
【００４０】
このようなフォーマット動作により、ディスク出荷前の時点で論理フォーマットを行なう必要はなくなり、また既存のＯＳによりパーシャルＲＯＭディスクが扱えるようになる。特にＲＯＭ領域に記録しておくファイルシステムＦＳ１は、例えばＦＡＴシステムなどで記録し、殆どの種類のＯＳで読み込めるようにしておくことで、汎用性を高めることができる。
さらに、例えばファイルシステムＦＳ２が壊れてしまうような事故が発生しても、再度物理フォーマット及び論理フォーマットを行なうことで、そのディスクのリライタブル領域ＡＲＷを使用可能とすることができる。
【００４１】
３．記録再生装置の構成
図１１に記録再生装置の構成を示す。
記録再生装置１は、ＳＣＳＩインターフェース接続されたホストコンピュータ２（例えばパーソナルコンピュータ）との間で、コマンド及びデータの受け渡しが可能に構成され、ホストコンピュータ２からのコマンド及びデータの供給に応じてディスク９０に対するデータの記録を行ない、またホストコンピュータ２からのコマンドに応じてディスク９０からデータを読み出し、ホストコンピュータ２に供給する動作を行なう。ここでディスク９０とは、上述してきたパーシャルＲＯＭディスクであるとする。
【００４２】
コントローラ１１はホストコンピュータ２との間の通信及び記録再生装置の記録動作、再生動作の全体の制御を行なう。
コントローラ１１はＤＳＰ（デジタルシグナルプロセッサ）１９を介して実際の記録及び再生駆動を実行させる。ＤＳＰ１９は、いわゆるサーボドライバとしての機能を持つ。そして、コントローラ１１から供給される回転駆動指令に応じてスピンドルドライバ２１に対してスピンドル駆動制御信号を供給し、スピンドルモータ２２に駆動信号を印加させることで、ディスク９０を回転駆動させる。またこの回転駆動中は、図示しない回転速度検出機構により得られる回転速度情報と基準回転速度の比較を行い、その差分に応じた駆動信号をスピンドルモータ２２に印加していくことで、スピンドル回転動作をＣＡＶ方式（角速度一定）とする。
【００４３】
また光学ヘッド１５におけるレーザダイオード１５ａからのレーザ発光動作を実行させるためにレーザドライバ１６に駆動制御信号を出力し、レーザ発光制御を行なう。レーザダイオード１５ａからのレーザ光は図示しない光学系を通り、対物レンズ１５ｂを介してディスク９０に照射される。またディスク９０からの反射光は図示しない光学系を通ってフォトディテクタ１５ｃに照射され、電気信号として取り出される。
【００４４】
フォトディテクタ１５ｃで得られる電気信号はＩ−Ｖ／マトリクスアンプ１７に供給され、電流／電圧変換された後、マトリクス演算アンプにより各種信号が取り出される。即ち、ディスク９０のＲＯＭ領域ＡＥからの再生データとされるべきＲＦ信号、ディスク９０のリライタブル領域ＡＲＷからの再生データとされるべきＭＯ信号、フォーカスエラー信号、トラッキングエラー信号、フロントＡＰＣ信号などが抽出される。
【００４５】
サーボ情報であるフォーカスエラー信号、トラッキングエラー信号、フロントＡＰＣ信号はＡ／Ｄ変換器１８でデジタルデータ化されてＤＳＰ１９に供給される。
ＤＳＰ１９は、フォーカスエラー信号、トラッキングエラー信号に応じてサーボ駆動信号を発生させ、ＰＷＭドライバ２０に供給する。ＰＷＭドライバ２０は光学ヘッド１５内のフォーカスコイル、ガルバノモータ、スライドモータに対する駆動電力を供給する。
【００４６】
即ちフォーカスエラー信号に基づいたフォーカスサーボ駆動信号によりＰＷＭドライバ２０がフォーカスコイルに駆動電力を印加することで対物レンズがディスクに接離する方向に駆動されてフォーカス制御が行なわれ、またトラッキングエラー信号に基づいたトラッキングサーボ駆動信号、スライドサーボ駆動信号によりＰＷＭドライバ２０がトラッキング用モータ、スライドモータに駆動電力を印加することでトラッキング制御、スレッド移動制御が行なわれる。
またＤＳＰ１９はフロントＡＰＣ信号に応じてレーザドライバ１６を制御し、レーザレベルを適正に保つようにしている。
【００４７】
ディスク９０に対する再生時において読み出されるデータは、Ｉ−Ｖ／マトリクスアンプ１７からＲＦ信号もしくはＭＯ信号として得られる。Ｉ−Ｖ／マトリクスアンプ１７からの出力はゲイン／オフセットコントロール部２３で適切な電位レベルとされ、Ａ／Ｄ変換器２４でデジタルデータ化される。
そしてデジタルデータ化された信号はエンコーダ／デコーダ部１２に供給され、デジタルフィルタ処理、ビタビ復号処理、ＮＲＺ（NON RETURN TO ZERO）復号処理、デスクランブル処理等を施され、再生データとされる。
この再生データはコントローラ１１( コントローラ内部のインターフェース機能）を介してホストコンピュータ２に転送される。
【００４８】
なお、再生処理のための再生クロック及び再生信号に同期した各種タイミング生成のために、Ａ／Ｄ変換器２４の出力はＰＬＬタイミングジェネレータ２５にも供給され、いわゆるＰＬＬ動作により再生クロック及びその再生クロックに基づいた各種タイミング信号が形成される。
【００４９】
ホストコンピュータ２から記録要求コマンド及び記録すべきデータが供給された場合は、コントローラ１１はそのデータをエンコーダ／デコーダ部１２に供給し、実際にディスク９０上に記録を行なう場合のデータ形態にエンコードさせる。そしてそのエンコードされたデータは磁気ヘッドドライバ１３に供給され、磁気ヘッドドライバ１３は記録データに応じて磁気ヘッド１４からディスク９０に対する磁界印加動作を実行する。
なお、記録時にはレーザダイオード１５ａには記録用の高レベルのレーザ出力が与えられる。
【００５０】
ハードディスク４に対しての記録／再生動作を行なうハードディスクドライブ３は、ホストコンピュータ２に内蔵もしくは別体接続される。
ユーザーがパーシャルＲＯＭディスクとしてのソフトウエアを購入した場合は、そのディスク９０を記録再生装置１に装填し、ディスク９０に記録されているアプリケーションプログラムをハードディスク４にインストールする。そしてその後は、ホストコンピュータ２の操作によりハードディスクドライブ３を動作させ、ハードディスク４からアプリケーションプログラムを読み出して、そのアプリケーションプログラムの機能を使用することになる。
【００５１】
４．システム動作
ホストコンピュータ２が記録再生装置１を用いてディスク９０を利用する場合の動作状態を図１２で模式的に説明する。
本例のディスク９０には、フォーマット動作の章で説明した、ディスク９０に記録されている各種データファイルや記録状況等を管理するファイルシステム（ファイルシステムＦＳ１、ＦＳ２）が記録されている。
ディスク９０に対して記録又は再生動作を行うには、ホストコンピュータ２は、まずディスク９０からファイルシステムを読み込んでいなければならない。
【００５２】
ホストコンピュータ２のオペレーティングシステム２ａ（以下、ＯＳという）は、図１２に示すように、ディスク９０からホストコンピュータ２内の所定の記憶領域に読み込んだファイルシステム２ｄを用いて記録再生装置１に対する記録／再生指示を行う。なお、ディスク９０からのファイルシステム読込は、例えば記録再生装置１にディスク９０が装填された場合や、システムが起動された場合などに行われる。
【００５３】
ファイルシステムには、そのディスクメディアの使用状況として、ディスク９０の外周から内周までのユーザー領域における単位領域毎（例えばゾーン、クラスター、セクターなど）についての使用／未使用の状態、さらには使用不能領域の設定などが管理されている。また階層構造管理として、記録されているデータファイルのディレクトリ構造が管理され、またファイル名も管理される。
さらに読出／書込のために指定されたファイル名からのアドレス変換のための機能を備える。アドレス変換とは読出／書込のためにＯＳ２ａから指示されるファイル名を、実際のディスク９０上のアドレスに対応する論理アドレスに変換する処理である。このアドレス変換は、データファイルとしてのクラスタをディスク９０上のアドレスとしての論理アドレスに変換する処理である。
なお新しくファイルを形成するために新規なファイル名が発生された場合は、アドレス変換処理としてディスク９０の未使用の領域のアドレスに対応する論理アドレスに変換することになる。
【００５４】
ＯＳ２ａがディスク９０に対して読出又は書込を要求する場合、ＯＳ２ａはそのファイル名とコマンド（リードコマンド又はライトコマンド）をファイルシステム２ｄに供給する。
ファイルシステム２ｄは、ファイル名とコマンドに基づいてメディア使用状況、ディレクトリを確認し、ディスク９０内の構造を理解する。そしてそのファイル名を論理アドレスに変換する。
【００５５】
このようなアドレス変換処理を経て、ファイルシステム２ｄは、デバイスドライバ２ｂに対して、リード／ライトコマンドと、論理アドレス及びレングス（ファイル長）と、ホストコンピュータ２側での転送先のメモリー番地を供給する。デバイスドライバ２ｂは、例えば論理アドレスを、ディスク９０上の実アドレスとしての物理アドレスに変換する処理（なお、この処理をファイルシステム２ｄで行う動作例やもしくは記録再生装置１で行う動作例も考えられる）などを行った後、インターフェース部２ｃを介して記録再生装置１に対してコマンドと、アドレス及びレングスを供給し、記録再生装置１に所要のデータファイル又はプログラムファイルの書込又は読出を実行させる。なお、ディスク９０への書込を実行させる場合は、実際のデータもしくはデータファイルを記録再生装置１へ供給することはいうまでもない。
また、ディスク９０から読み出された各種データ（データファイルやアプリケーションプログラムなど）は、ホストコンピュータ２内の所定の記憶領域に保持されて用いられるか、もしくはハードディスク４にインストールされることになる。
【００５６】
ホストコンピュータ２においてあるアプリケーション２ｅが起動されている場合、そのアプリケーション２ｅとしてのプログラムはＯＳ２ａを基礎として動作するとともに、このアプリケーション２ｅによるディスク９０への書込又は読出要求が発生する場合は、そのアプリケーション２ｅがファイルシステム２ｄに対してその読出／書込対象となるファイル名とコマンド（リードコマンド又はライトコマンド）を供給する。
ファイルシステム２ｄはファイル名とコマンドに応じてメディア使用状況確認、ディレクトリ確認、アドレス変換等を行って、コマンド、アドレス及びレングスをデバイスドライバ２ｂに供給し、デバイスドライバ２ｂから記録再生装置１に対して読出又は書込動作を実行させる。
【００５７】
後述するインストール及びアンインストール動作に関しては、ディスク９０にインストーラとして記録されているインストールシステムが、ホストコンピュータ２側に読み込まれ、アプリケーション２ｅとして機能することで動作が行われる。
【００５８】
５．インストール時の動作
本例のパーシャルＲＯＭディスクに記録されたアプリケーションプログラムを、例えば図１１に示したハードディスク４にインストールする際の動作を説明する。
物理フォーマット及び論理フォーマットが終了されたディスク９０の状態を図１３に模式的に示す。この状態は、図６（ｂ）下段で説明した状態に相当する。ディスク９０には上述したようにＲＯＭ領域ＡＥとリライタブル領域ＡＲＷが存在しているが、エンボスピットによりデータが記録されるＲＯＭ領域ＡＥには、ファイルシステムＦＳ１、セットアップシステム、インストールシステム、アプリケーションＡＰが記録されている。
【００５９】
前述したようにファイルシステムＦＳ１は論理フォーマットが実行されるまでの間、ディスク上のＲＯＭ領域ＡＥに記録されているファイルを管理するデータである。
即ち、リライタブル領域ＡＲＷが単に光磁気領域とされて、実際上の領域管理は行なわれていない状態でも、ＲＯＭ領域ＡＥは、既にソフトウエアメディアとして必要なデータが記録された状態となっており、本例の場合、セットアップシステム、インストールシステム、及び実際のソフトウエアとして提供するアプリケーションＡＰが記録されているが、これらのプログラムデータがファイルシステムＦＳ１から管理／起動できるようにされている。
【００６０】
セットアップシステムは、フォーマット動作の章で前述したように、ディスクの論理フォーマットのためのツールとされるプログラムデータであり、例えば図１１に示したような記録再生装置１にディスク９０を装填し、図１２で説明したようにファイルシステムＦＳ１をホストコンピュータ２側に読み込んだ状態で、そのファイルシステムＦＳ１（図１２におけるファイルシステム２ｄ）からセットアップシステムを起動させることで、リライタブル領域ＡＲＷを使用可能とする論理フォーマットが実行される。即ち、論理フォーマット前の時点ではＲＯＭ領域ＡＥの先頭、即ちファイルシステムＦＳ１がアドレス０とみなされ、最初にファイルシステムＦＳ１がアクセスされることで、セットアップシステム等の起動が可能となる。
【００６１】
セットアップシステムによって論理フォーマットが行なわれると、図１３のように、リライタブル領域ＡＲＷ及びＲＯＭ領域ＡＥの各データ（アプリケーション等）の管理のためのファイルシステムＦＳ２がリライタブル領域ＡＲＷの先頭領域に書き込まれる。
そして論理フォーマット後においては、リライタブル領域ＡＲＷの先頭、即ちファイルシステムＦＳ２がアドレス０とみなされ、つまりディスク装填時などに最初にファイルシステムＦＳ２がアクセスされるようになり、これによって、ＲＯＭ領域ＡＥでのデータ読出管理とともに、リライタブル領域ＡＲＷでの記録／再生管理が可能となる。つまり図１２のファイルシステム２ｄとしてファイルシステムＦＳ２が取り込まれることになり、パーシャルＲＯＭディスクに対するリライタブル領域ＡＲＷを含んだ各種の使用が可能となる。
なお、図１３の破線斜線部はリライタブル領域ＡＲＷ内における、データの書込可能に残されている領域である。
【００６２】
ところで、本例の説明では、セットアップシステムによる論理フォーマット後においてパーシャルＲＯＭディスクの使用が可能となるようにしているが、セットアップをしない（つまりファイルシステムＦＳ２が存在しない）段階で、ファイルシステムＦＳ１からリライタブル領域ＡＲＷ内にファイルがあるように管理させることもできる。例えば後述するインストール管理ファイルをこのようなファイルに該当させることができる。この場合、ファイルシステムＦＳ１からそのインストール管理ファイルが見えないファイルとして扱われるようにしたり、再生専用ファイルとして扱うことなどが可能である。また、詳しくは後述するが、図１２に破線で示すように、ホストコンピュータ２側に読み込まれているアプリケーション（インストールシステム等）２ｅがファイルシステム２ｄ（ＦＳ１）を介さないで直接デバイスドライバ２ｂを制御し、インストール管理ファイル等の読出／書込を行うことも可能である。
つまり、論理フォーマットを行なわないままアプリケーションをインストールしたり、インストールを行わずに直接アプリケーションを立ち上げるソフトウエアとして提供することも可能である。
【００６３】
図１１のホストコンピュータ２で、このディスク９０によって提供されるアプリケーションＡＰを使用するには、通常、アプリケーションＡＰをハードディスク４にインストールすることになる。
そして本例では、図１２におけるアプリケーション２ｅとして機能するインストールシステム（ディスク９０からホストコンピュータ２側に読み込まれたインストールシステム）におけるインストール処理プログラムにより、インストールの際には図１６の処理が実行される。
【００６４】
まずユーザーが、ディスク９０を記録再生装置１に装填し、ホストコンピュータ２からインストールシステムを起動させる操作を行う。
この際ホストコンピュータ２側ではモニタ上に起動プログラムの選択を要求する表示を行い、ユーザーがこれに対してインストール処理プログラムの起動を選択すると、ＯＳ２ａに基づくインストールシステム（アプリケーション２ｅ）により、図１６の処理が開始される。
即ちディスク９０に収録されているアプリケーションＡＰのインストールを行うためにインストール処理が選択された場合、まずステップＦ１０１で、ディスク９０に記録されているインストール管理ファイルの読み込みが行われる。
【００６５】
そしてステップＦ１０２で、リライタブル領域ＡＲＷにインストール管理ファイルが記録されているか否かを確認する。
ここでインストール管理ファイルとは、過去のインストール動作の経歴情報を記録したファイルであり、例えばインストール実行回数等のデータで構成されてディスク９０のリライタブル領域ＡＲＷに記録されているものである。
【００６６】
図１５にインストール管理ファイルの構成例を示す。
インストール管理ファイルは１又は複数のセクターに形成され、先頭の２４バイトにインストール管理ファイルのヘッダとして「INSTALL MANAGEMENT SECT0」というコードが記録されている。
続いて、４バイトのエリアにインストール実行回数Ｎｉが記録される。
インストール実行回数Ｎｉに続く４バイトはリザーブとされるが、この４バイトのエリアには、括弧内に示すようにインストール許可回数Ｎｐを記録するようにしてもよい。
インストール許可回数Ｎｐは図１６の処理等で後述するように用いられる定数であるが、このインストール許可回数Ｎｐはインストールシステムがそのプログラム内に固定値として保持するものとすればよいが、図１５のインストール管理ファイル内に記録する値（この場合は可変値）としてもよく、これらはシステム設計の方針に応じていづれかもしくは両方が選択されればよい。
【００６７】
４バイトのリザーブ領域（もしくはインストール許可回数Ｎｐ）に続いて、それぞれ１２８バイトづつ、過去のインストール動作についての情報が記録される。
即ち、８バイトでインストールを行った日時情報として日時（年月日）が記録され、また３２バイトでインストール先のドライブ照合情報（インクワイリィ）としてインストール先の記録媒体を駆動するドライブの個体識別情報が記録される。さらに、６４バイトでインストール先のディレクトリ名が記録され、残りの２４バイトはリザーブとされる。
【００６８】
以上の１２８バイトで１回のインストール動作についての情報が記録され、例えば最初のセクターには第１回目のインストール動作に関する情報から第１５回目のインストール動作に関する情報が記録できるようにされる。
また、次のセクターには、ヘッダとして「INSTALL MANAGEMENT SECT1」というコードが記録され、続く８バイトはリザーブとされる。
そして続いて、前セクターと同様に１２８バイトづつのデータとして、第１６回目のインストール動作に関する情報を先頭とし、以降第１７回目、第１８回目・・・・のインストール動作に関する情報が記録できるようにされる。
【００６９】
このようなセクターが所定数確保されてインストール管理ファイルが構成される。
なお、各１２８バイトのインストール動作に関する情報の単位内にはそれぞれ２４バイトのリザーブ領域が確保されているが、例えばこの領域にＩＤナンバを入れるなどして、後述するアンインストール時に参照することも考えられる。これについては後述する。
【００７０】
このようなインストール管理ファイルの形成方式としては、一例として、ディスク９０にとってはじめてインストールが実行されるときにインストール管理ファイルが形成されるものとすればよい。従って、この場合はディスク９０を用いてはじめてインストール動作が行なわれる時点ではインストール管理ファイルは存在しない。そしてこの場合は、図１６のステップＦ１０２の時点でインストール管理ファイルのヘッダチェックはＮＧ（ヘッダが存在しない）となる。
ところがステップＦ１０５で、初めてインストールを実行する際にインストール管理ファイルが存在しないバージョンのディスクであるか否かが判断され、そのバージョンであるとすれば、インストール処理を継続するためにステップＦ１０６に進む。
【００７１】
ただし、例えば上述した論理フォーマット時にデータ内容が初期化された状態のインストール管理ファイルを生成し、それをリライタブル領域ＡＲＷに記録しておく方式も考えられる。この場合、ディスク９０にとってはじめてインストールが実行される時でも既にインストール管理ファイルは存在するものとなり、このような方式が採用される場合は、初回のインストール時であっても、通常はステップＦ１０２で肯定結果が得られる。
このようなバージョンのディスクについては、インストール管理ファイルが存在せず、ステップＦ１０２で否定結果が得られた場合とは、異常な状態である。この場合はステップＦ１０５でも肯定結果は得られないため、エラーとして処理されることになる。
【００７２】
本例のディスク９０に記録されるインストールシステムにおいて、アプリケーションＡＰを最高３回までハードディスク４等の他の記録媒体にインストールしてもよいとプログラム設定されているものとする。つまりインストール許可回数Ｎｐ＝３として、インストールシステムがそのプログラム内で保持しているとする。インストール許可回数Ｎｐの値はユーザーサイドで書き換えられることが防止されるべきデータであり、このため、インストールシステム内のプログラム上の固定値としてインストール許可回数Ｎｐの値を設定しておくことにより、ユーザーサイドでの不法書換を防止し、セキュリティを向上させることができる。
一方図１５で括弧書きで示したようにインストール管理ファイル内に書き換え可能な情報としてインストール許可回数Ｎｐを保持する方式を採用した場合は、セキュリティの面では機能が低下するが、メーカーサイドでフレキシブルにインストール許可回数Ｎｐを設定することができるという利点が得られる。
【００７３】
上記のように図１６のステップＦ１０２でヘッダチェックＮＧ（インストール管理ファイルが存在しない）と判断された場合で、インストール管理ファイルが初回のインストール時に形成されるバージョンである場合は、当然ながらインストールを実行して差し支えない（今回のインストール動作が初回のインストールである）。そこで、インストール実行回数Ｎｉの確認処理は行わずにステップＦ１０６に進んで、アプリケーションＡＰのハードディスク４に対するインストールを実行するための処理を開始する。
【００７４】
一方、ステップＦ１０２でインストール管理ファイルの存在が確認された場合は、ステップＦ１０３としてインストール管理ファイルの読み込みを行う。即ちインストールシステム（２ｅ）は、記録再生装置１を制御してディスク９０からインストール管理ファイルを読み出させ、インターフェース部２ｅ、デバイスドライバ２ｂを介してインストール管理ファイルを取り込む。
そして、図１５に示したように、そのインストール管理ファイルに記録されているインストール実行回数Ｎｉを確認する。
そしてステップＦ１０４で、インストール実行回数Ｎｉと、設定されているインストール許可回数Ｎｐを比較し、インストール実行回数Ｎｉがインストール許可回数Ｎｐ未満であったら、ステップＦ１０６に進んでアプリケーションＡＰのハードディスク４に対するインストールを実行する処理を進めていく。
例えばインストール許可回数Ｎｐ＝３であるとしたら、インストール実行回数Ｎｉが０、又は１、又は２のときのみステップＦ１０６に進む。
【００７５】
ステップＦ１０６では、ホストコンピュータ２のモニタ画面上にインストール実行のための画面表示を行って待機する。即ちユーザーに対してインストール実行先のメディアを選択させる。ユーザーがハードディスク４などのインストール先を入力したら、ステップＦ１０７でインストールを実行する。
ステップＦ１０７では、インストールシステム（２ｅ）に基づいて動作するホストコンピュータ２は記録再生装置１に対してディスク９０からアプリケーションＡＰの再生動作を実行させ、アプリケーションＡＰとしてのデータを受け取る。そして、そのデータをハードディスクドライブ３に供給し、ハードディスク４に記録させる。
なおこのインストール実行の際に、今回のインストールに関する情報であり、後述するアンインストール時の照合動作のための情報をハードディスク４に書き込む動作についても、ハードディスクドライブ３に実行させる。このハードディスク４に書き込む情報については後述する。
【００７６】
ステップＦ１０７でインストールを実行したら、ステップＦ１０８で正しくインストールが実行できたか否かを確認する。正しく実行できなかたった場合はエラーとして処理が終了される。
正しくインストールされたことが確認された場合とは、図１４に示すようにディスク９０に記録されているアプリケーションＡＰがハードディスク４にインストールされ、またハードディスク４にはインストールしたアプリケーションＡＰを管理するファイルシステムＦＳhdが形成されている場合である。
【００７７】
このようにインストールが適正に実行できた場合は、つづくインストールシステム（２ｅ）の動作としては、ステップＦ１０９でディスク９０上でのインストール管理ファイルの書込又は更新を行なうことになる。
インストール管理ファイルには上述したようにインストール実行回数Ｎｉが記録されるため、例えば初回のインストールであったのなら、そのインストール実行回数Ｎｉ＝１としてインストール管理ファイルを形成し、図１４のようにディスク９０のリライタブル領域ＡＲＷに書き込む。またステップＦ１０３で確認されたインストール実行回数Ｎｉ＝１とされていた場合は、そのインストール実行回数Ｎｉの値をインクリメントし、インストール実行回数Ｎｉ＝２とし、リライタブル領域ＡＲＷのインストール管理ファイルを更新する。
【００７８】
さらに本例の場合、インストール管理ファイルとしては各インストール動作についてインストール先を示すデータを記録しておくようにしている。これは後述するアンインストール動作の際の照合動作に用いる照合情報となる。
インストール先を示すデータ（照合情報）としては、図１５で説明したように、例えばインストールを実行した日時情報、インストール先のドライブ照合情報、インストール先のディレクトリ名の３つの情報としている。もちろんこれ以外の照合情報を採用してもよい。
【００７９】
本例の照合情報の１つであり、インストール先のドライブを識別する個体情報であるドライブ照合情報としては、相手先のドライブ（この場合ハードディスクドライブ３もしくはハードディスク４）に固有の機器ＩＤナンバが付されているような場合は、その機器ＩＤナンバを用いればよい。既存の機器ＩＤが存在しなければ、或るＩＤコードを発生させて、インストール管理ファイルと相手先記録媒体内の両方に書き込むという手法も考えられる。
このように、インストール先の記録媒体に固有の機器ＩＤナンバなどのドライブ照合情報をインストール管理ファイル内に記録しておけば、後に、或る記録媒体にインストールされているアプリケーションＡＰについて、そのドライブ照合情報を確認すれば、そのディスク９０からインストールされたものか否かを確認できる。
【００８０】
また、日時情報としては、インストール時に、例えばインストールするアプリケーションＡＰ内のデータとしてインストールを行った年月日を含めるようにする。即ちハードディスク４側で、アプリケーションＡＰ内のデータとしてインストール日時が記録されるようにしておく。
そしてディスク９０側についてはステップＦ１０９の処理時に、そのインストール日時をインストール管理ファイル内に記録しておく。
このようにしておくことにより、後に、或る記録媒体にインストールされているアプリケーションＡＰが、ディスク９０からみて、そのディスク９０からインストールされたアプリケーションＡＰであるか、もしくは同種の（＝同一アプリケーションＡＰを記録した）他のディスクからインストールされたアプリケーションＡＰであるかを判別できる。
なお、日時情報としては日付（年月日）に加えて時刻（時分秒）の情報も保持するようにしたり、もしくは日時情報として日付（年月日）に代えて時刻（時分秒）を保持するようにしてもよい。
【００８１】
また、インストール先のディレクトリ名を図１５に示した所定領域に記録しておくことで、ある記録媒体にインストールされているアプリケーションＡＰが、そのディスク９０からインストールされたアプリケーションＡＰであるか否かを確認する手段とできる。つまり、インストール元とインストール先の関係が正しければ、そのインストール先の記録媒体には、そのディレクトリが存在しているはずであるからである。
【００８２】
これらの照合情報による照合機能を実現するには、必要な情報をインストール先のハードディスク４にも書き込んでおく必要がある。このための処理が、前述したステップＦ１０６でインストール動作とともにハードディスクドライブ３に実行させる情報書込処理である。
【００８３】
ハードディスク４に書き込む、照合のためのインストール時の情報（以下、インストール照合情報という）は、例えば図１７もしくは図１８のような形態で書き込む例が考えられる。
図１７はこれらのインストール照合情報を、ハードディスク４のファイルシステムＦＳｈｄ内のデータ群ＩＮＳ１と、インフォメーションファイルＩＮＦＯというファイルで分担して保持する方式である。
図１７（ａ）は、ファイルシステムＦＳｈｄ内のデータとしてインストール照合情報のデータ部分を示している。当然ながらファイルシステムＦＳｈｄ内には、ハードディスク４に記録されているファイルの管理等のデータが記録されているが、図１７（及び図１８）では、それらの通常のデータ部分の図示は省略している。
【００８４】
この図１７（ａ）ではファイルシステムＦＳｈｄ内のデータ群ＩＮＳ１として、まずインフォメーションファイルに関するディレクトリＤＩＲ＃０、ファイル名ＩＮＦＯ、日時情報Ｄａｔｅ＃０が記録される。これはインフォメーションファイル形成時に記録される。例えば初回のインストールが行われた際に記録される。日時情報Ｄａｔｅ＃０は、インフォメーションファイル形成時の日時か、最新の更新時の日時とすればよい。
【００８５】
さらに、インストールが行われる毎に、上記ステップＦ１０６の処理で、そのインストールを行った各アプリケーションについてのディレクトリ（ＤＩＲ＃１、ＤＩＲ＃２・・・・）、アプリケーションネーム（Ｎａｐ＃１、Ｎａｐ＃２・・・・）、インストール実行日時情報（Ｄａｔｅ＃１、Ｄａｔｅ＃２・・・・）が記録されていく。
【００８６】
一方、インフォメーションファイルは、ファイルシステムＦＳｈｄとしての通常のファイル管理形態により記録位置等が管理され、ハードディスク４のユーザー領域に形成されるものとなるが、このインフォメーションファイルＩＮＦＯ内には、図１７（ｂ）に示すように、インストールされている各アプリケーションのアプリケーションネーム（Ｎａｐ＃１、Ｎａｐ＃２・・・・）とともに、バージョン情報（Ｖｅｒ＃１、Ｖｅｒ＃２・・・・）、インストール実行日時情報（Ｄａｔｅ＃１、Ｄａｔｅ＃２・・・・）、何回目のインストールであるか（つまりそのインストール実行時点でのインストール実行回数Ｎｉ＋１となる値）を示す回数情報（Ｎ＃１、Ｎ＃２・・・・）が記録される。
これらもインストールが行われる毎に、上記ステップＦ１０６の処理で、そのインストールを行ったアプリケーションについての情報として、インフォメーションファイルに書き加えられていく。
【００８７】
この図１７の形態は、ファイルシステムＦＳｈｄがそもそも有する情報を利用して、それ以外の情報をインフォメーションファイルＩＮＦＯとして補う方式である。即ちインストールされたアプリケーションとしてのプログラムファイル自体は、ファイルシステムＦＳｈｄによって管理されることになり、当然ディレクトリ、アプリケーションネーム、日時情報等はファイルシステムＦＳｈｄに記録される。従って、それらをインストール照合情報として利用するとともに、それ以外にインフォメーションファイルＩＮＦＯを設けて、インストール照合情報としてのバージョン情報や回数情報を保持するようにするものである。
【００８８】
一方図１８の例は、インストール照合情報をインフォメーションファイルＩＮＦＯ内にまとめて保持する方式である。
まず図１８（ａ）に示すようにファイルシステムＦＳｈｄではインフォメーションファイルＩＮＦＯを他のファイルと同様の形態で１つのファイルとして管理するようにする。
そして実際の各インストールされたアプリケーション毎のインストール照合情報は、図１８（ｂ）のように全てインフォメーションファイル内に保持するものである。
即ちインフォメーションファイルＩＮＦＯ内には、インストールが実行される毎に、そのインストールされたアプリケーションについてのインストール照合情報として、上記ステップＦ１０６の処理で、そのアプリケーションについてのアプリケーションネーム（Ｎａｐ＃）、バージョン情報（Ｖｅｒ＃）、インストール実行日時情報（Ｄａｔｅ＃）、回数情報（Ｎ＃）、ディレクトリ（ＤＩＲ＃）が記録されていく。
【００８９】
本例の図１６の処理では、例えば以上の図１７、図１８のような形態により、ステップＦ１０６の時点で、インストール照合情報をハードディスク４に書き込んでいくことになる。
このようなインストール照合情報をハードディスク４側にも記録することで、上記のようにディスク９０のインストール管理ファイル内の照合情報を用いた照合動作ができる。つまり、ハードディスク４等の或るアプリケーションが、或るディスク９０そのものからインストールされたアプリケーションであるか否かの照合に用いることができる。
【００９０】
ところで、ディスク９０にはリライタブル領域ＡＲＷが存在するため、同一種類のディスクであっても、ディスク個別にＩＤ番号を付すことは可能である。つまりディスク１枚ごとに異なるディスクＩＤ番号を設定し、リライタブル領域ＡＲＷ内に書き込んでおけばよい。
このようにした場合は、インストール時に、例えばインストールするアプリケーションＡＰ内のデータとしてディスクＩＤ番号を含めるようにする。即ちハードディスク４側で、アプリケーションＡＰ内のデータとしてディスクＩＤ番号が記録されるようにしておく。
【００９１】
この場合、ディスク９０にはディスクＩＤ番号が既に記録されているため、ステップＦ１０９の処理においてディスクＩＤ番号をインストール管理ファイル内に記録する必要はないが、後に、或る記録媒体にインストールされているアプリケーションＡＰについて、その中のディスクＩＤ番号を参照することにより、ディスク９０からみて、そのディスク９０からインストールされたアプリケーションＡＰであるか、もしくは同種の他のディスクからインストールされたアプリケーションＡＰであるかを判別できる。
【００９２】
これらのディスク９０からみたインストール先の照合のための手法は各種考えられるが、その手法に応じて必要なデータをインストール管理ファイル内に記録しておく。
【００９３】
これらの各種必要な情報についてインストール管理ファイルの書込又は更新が行われたら、続いて図１６のステップＦ１１０で、インストール管理ファイルの更新等が適正に行われたか否かを確認し、正しく更新できていた場合は一連のインストール動作を終了する。インストール管理ファイルの更新が適正に実行できなかった場合はエラーとして終了することになる。
【００９４】
ところが、例えば何らかの他の記録媒体に対してアプリケーションＡＰが既に３回インストールされた後、さらにインストール要求があって図１６の処理が開始されたとする。
すると処理はステップＦ１０２からＦ１０３に進んで、インストール管理ファイル内のインストール実行回数Ｎｉが確認されることになるが、このときインストール実行回数Ｎｉ＝３となっており、インストール許可回数Ｎｐ（＝３）に達している。このためステップＦ１０４で否定結果が得られ、この場合インストールを実行することなく、エラーとして処理を終了する。
【００９５】
つまり本例では、例えばインストール許可回数Ｎｐ＝３と設定しておけば、そのディスク９０からはアプリケーションＡＰは最高３回しか他の記録媒体へインストールすることはできず、これによって無制限にインストールが実行されてアプリケーションＡＰが不正提供されてしまうことが防止される。従って適正にディスク９０を購入したユーザーについてはインストールを行なって、そのアプリケーションＡＰを使用できるが、ディスク９０を貸与された、もしくはディスク９０を盗んだ他のユーザーが自分のパーソナルコンピュータ等にインストールして不正使用することを防止できる。
【００９６】
なお、この例ではインストール許可回数Ｎｐ＝３としたが、これはあくまで例であり、不正使用を厳格に防止するにはインストール許可回数Ｎｐ＝１としてもよいし、例えばインストールしたハードディスクの破損などによりアプリケーションＡＰが使用できなくなった場合などに、そのユーザーが新たなハードディスクにインストールすることができるように、インストール許可回数Ｎｐを２又は４以上としてもよい。
また前述したように、インストール許可回数Ｎｐをインストール管理ファイル内に記録しておく方式を採用する場合は、或る程度フレキシブルにインストール許可回数Ｎｐを設定できる。
【００９７】
また、ディスクに複数のアプリケーションソフトウエアを収録するような場合は、インストール管理ファイルとしては各アプリケーション毎に過去のインストール経歴（回数や時刻など）を管理するようにすることはいうまでもない。
【００９８】
ところで、図１６のステップＦ１０２，Ｆ１０９ではインストールシステム２ｅがディスク９０上でのインストール管理ファイルのアクセスを実行させ、必要な読出・書込を行うことになるが、このようなインストール管理ファイルに対するアクセスは、インストール実行回数Ｎｉの不正書換などを防止するため、ユーザー側から見えない状態（ユーザーが勝手に書き換えられない状態）で行うことが好ましい。
【００９９】
このためには、例えばインストール管理ファイルの読出／書込は、ファイルシステム２ｄ（ＦＳ２）を介さずに、インストールシステム（２ｅ）が直接デバイスドライバ２ｂに指示して行うようにすることが考えられる。
このためにディスク９０のリライタブル領域ＡＲＷ内の特定のアドレスを設定して、その領域をインストール管理ファイルの領域とする。そして図１２に破線で示すようにインストールシステム（２ｅ）が、直接デバイスドライバ２ｂに対して論理アドレス、レングス、コマンドを供給してその領域のアクセスを指示し、書込／読出が行われるようにする。
またこの場合、ファイルシステムＦＳ２からみた場合は、そのインストール管理ファイルが記録された領域は使用されない領域として管理されるようにする。例えば欠陥領域とみなすようにしてもよい。
【０１００】
つまりインストール管理ファイルの記録領域をファイルシステムＦＳ２から見ることのできない、即ちユーザーから見ることのできないファイルとしておき、その領域に対してはインストールシステム２ｅのみが管理する。このようにしておけば、ユーザーはインストール管理ファイル内を任意にみることはできず、従って不正書換等もできないことになる。
【０１０１】
またこのような方式を採用する以外に、インストール管理ファイルを、ファイルシステムＦＳ２（２ｄ）によって管理されるファイルとする方式もある。この場合は、例えばインストール管理ファイル内容としてのデータを暗号化する。
即ちインストールシステム（２ｅ）が暗号のエンコード及びデコード機能を持つようにし、ファイルシステムＦＳ２（２ｄ）を介してインストール管理ファイルの書込、更新を行う場合（つまり更新データを送信する場合）、その更新データについて暗号化エンコードを行って送信するようにする。
【０１０２】
またファイルシステムＦＳ２（２ｄ）を介してインストール管理ファイルの読み込みを行う場合（つまり読込データを受信する場合）、そのデータは暗号化されているものであるため、受信時にデコードを行ってデータ内容を解析する。
このようにファイル内容を暗号化することにより、ファイルシステムＦＳ２（２ｄ）を介して書込／読出を行うようにしても、ユーザー側からは（インストール管理ファイルの存在は確認できるが）、その内容を確認することはできず、不正書換等は防止できる。
なお、このように、インストール管理ファイルをファイルシステムＦＳ２から管理される形態で記録するようにする場合、暗号化とともに、ファイルシステムＦＳ２（２ｄ）からはリードオンリーファイルとして、ユーザーの書き換えが不可能なファイルとして管理しておくことが好適である。
【０１０３】
このような暗号化は、上記のようにインストールシステム（２ｅ）がファイルシステム（２ｄ）を介さずに直接インストール管理ファイルをアクセスする方式に採用しても有用である。そのようにしておけば例えばインターフェースライン上でデータを解析されたとしても解読できないものとなり、不正防止機能を高めることができる。
【０１０４】
ところで、本例では上述のように論理フォーマットによってファイルシステムＦＳ２を生成することでディスク９０のリライタブル領域の使用が可能となるようにしているが、アプリケーションＡＰのインストールという動作に関しては、リライタブル領域ＡＲＷの使用は、アプリケーション管理ファイルのみである。従って、あらかじめファイルシステムＦＳ１からリライタブル領域ＡＲＷ内にインストール管理ファイルが存在するように管理しておき、上記のようにインストール動作に応じてインストール管理ファイルの更新を行うようにすれば、論理フォーマットをしていない状態でそのディスクを使用できることになる。
【０１０５】
５．アンインストール時の動作
次に上述のようにアプリケーションプログラムをハードディスク４にインストールした後、ハードディスク４におけるアプリケーションプログラムを削除するアンインストール時の動作について説明する。
何らかの事情でハードディスク４などにインストールしたアプリケーションを削除する場合が生じることを考慮すると、上述のようにディスク９０からのインストール許可回数が限られていることで不都合が生じる場合がある。
【０１０６】
例えば正規にディスク９０を購入したユーザーが、そのアプリケーションを或るハードディスク４にインストールして使用していた後、例えばそのハードディスクシステムを廃棄し、新しいハードディスクシステムを購入したようなときに、ディスク９０からのアプリケーションのインストール許可回数Ｎｐを使い切っていた場合は、正規のユーザーにもかかわらず、そのディスク９０に記録されているアプリケーションをインストールできないことになる。
【０１０７】
このような不都合を解消するために、本例の場合、ハードディスクドライブ３を廃棄する前に図２０のようなアンインストール処理を行なうことで対処できるようにしている。
即ちハードディスク４のようなインストール先の記録媒体で何らかの都合でそのアプリケーションが不要になった場合、ユーザーはディスク９０を記録再生装置１に装填し、ホストコンピュータ２からアプリケーションＡＰのアンインストールを指示する。
具体的には、ユーザーが、ディスク９０を記録再生装置１に装填し、ホストコンピュータ２からインストールシステムを起動させる操作を行うことでインストールシステム（２ｅ）が読み込まれて起動される。そしてこの際、ホストコンピュータ２はモニタ上に起動プログラムの選択を要求する表示を行い、ユーザーがこれに対してアンインストール処理プログラムの起動を選択すると、ＯＳ２ａに基づくインストールシステム（２ｅ）により、図２０の処理が開始される。
【０１０８】
即ちまずステップＦ２０１で、ディスク９０の所定領域に記録されているインストール管理ファイルの読込が実行される。
ステップＦ２０２では、インストール管理ファイルのヘッダチェックの可否、つまりインストール管理ファイルの有無が確認される。過去にインストールを実行したディスク９０であれば必ずインストール管理ファイルが形成されているはずであるので、ステップＦ２０２でヘッダチェックＮＧとなる場合は、そのディスク９０はまだ１度もインストールを実行していないディスクであるか、もしくは異常状態であり、いづれにしても今回アンインストールを実行するアプリケーションの過去のインストール元として適正な状態ではない。従ってこの場合はアンインストールを実行しないでエラー終了する。
【０１０９】
ステップＦ２０２でインストール管理ファイルが確認された場合は、ステップＦ２０３で、そのファイル内に記録されているインストール実行回数Ｎｉを確認する。
インストール実行回数Ｎｉを確認した結果、ステップＦ２０４でインストール実行回数Ｎｉ＝０と判断された場合は、そのディスク９０はまだ１度もインストールを実行していないディスクであるか、もしくは実行されたインストールについては全てアンインストールされているディスクであり、今回アンインストールを実行するアプリケーションの過去のインストール元として適正なディスクではない。従ってこの場合もアンインストールを実行しないでエラー終了する。
【０１１０】
インストール実行回数Ｎｉ＝０ではなくステップＦ２０５に進んだ場合は、アンインストール元、即ちアンインストールを行う記録媒体側（ハードディスクドライブ３等）の照合情報のチェックを行う。
本例の場合、前述したように照合情報として日時情報、ドライブ照合情報、ディレクトリの３つを記録しているが、これらの全部もしくは一部について以降の処理でチェックを行う。
【０１１１】
まずステップＦ２０５では照合情報の一致チェックを行う。即ち、インストール管理ファイル内に記録されているドライブ照合情報と、現在のアンインストール対象のドライブの照合（機器ＩＤ等の照合）を行い、ステップＦ２０６で同一性のチェックを行う。つまりこの処理も、今回アンインストール要求されているアプリケーションＡＰが、当該ディスク９０からインストールされたものかの判断となり、同一性が否定された場合は、エラー終了となる。
もちろん、一致チェックの１つとして日時情報のチェックを行うようにしてもよい。即ちインストール管理ファイル内に記録されている日時情報と、ハードディスク４内に図１７、図１８のような形態で記録されているインストール照合情報における、そのアンインストール対象となっているアプリケーションについて記録されているインストール実行日時情報（Ｄａｔｅ＃）を比較し、一致チェックを行う。これが異なれば、今回アンインストール要求されているアプリケーションＡＰが、当該ディスク９０からインストールされたものではないと判断でき、エラー終了とされる。
【０１１２】
ドライブ照合情報や日時情報によるドライブの同一性が確認された場合は、さらに照合情報を用いたチェックとして、ステップＦ２０７でアンインストール先のディレクトリを確認する。そしてインストール管理ファイル内に記録されているインストール先のディレクトリ名と同一のディレクトリがアンインストール対象となっているメディア側に存在しなければステップＦ２０８からエラー終了となるが、存在した場合は、ステップＦ２０９に進む。
【０１１３】
ステップＦ２０９に進む場合とは、アンインストール要求されているアプリケーションＡＰが、現在装填されているディスク９０からインストールされたものであると確認できた場合であり、アプリケーションＡＰのハードディスク４からのアンインストールを実行する。
即ちインストールシステム（２ｅ）に基づいて動作するホストコンピュータ２はハードディスクドライブ３に対して、ハードディスク４から当該アプリケーションＡＰの削除を実行させ、ハードディスク４を図１９に示す状態とする。
【０１１４】
続いてインストールシステム（２ｅ）の動作としては図１９にも示すように、ステップＦ２１０で、ステップＦ２０９のアンインストール動作に応じて、ディスク９０のリライタブル領域ＡＲＷ内のインストール管理ファイルの更新を行なう。
この場合の更新とは、アンインストールを行なったアプリケーションＡＰについてのインストール実行回数Ｎｉの値を減算することになる。例えば、それまでインストール実行回数Ｎｉ＝３と記録されていた場合は、アンインストールの実行に伴ってインストール実行回数Ｎｉ＝２と更新する。
このような更新を行なって一連のアンインストール処理を終える。
【０１１５】
なお、上述のように各ステップにおいてエラー終了となった場合は、アンインストール要求されているアプリケーションＡＰが、例えば同一内容のアプリケーションであったとしても、当該ディスク９０からインストールされたものではないと判断された場合であり、従ってアンインストール処理及びインストール管理ファイルの更新が行なわれないことはいうまでもない。
【０１１６】
以上のようにアンインストールに応じてインストール実行回数Ｎｉの値が減算されることにより、それまでのインストール経歴としてインストール許可回数Ｎｐを使い切っていたとしても、アンインストールした場合は再度他の記録媒体にインストールすることができる。このため正規ユーザーが正規に使用する範囲においては、ディスク９０を購入した後は、そのアプリケーションＡＰが使用できなくなるということはない。
【０１１７】
また、インストール元のディスクとインストール先の記録媒体の整合性がとれない場合はアンインストール及びインストール実行回数Ｎｉの減算更新は行なわれないため、例えば或るユーザーが自分のディスク９０を用いて不正に他人のハードディスクからアプリケーションＡＰのアンインストールを実行しようとしても、それは不可能となり、またインストール実行回数Ｎｉを不正に減算させてインストール許可回数Ｎｐ以上にインストールを実行させることもできない。
また、ネットワークのサーバとして使っている場合などは、現在ファーム使用中の端末の数をリライタブル領域ＡＲＷ内のインストール管理ファイルに書き込んでおくことで、インストール／アンインストール管理が可能となる。
【０１１８】
なお、このアンインストール時にもステップＦ２０１、Ｆ２１０でインストール管理ファイルの読出／書込が行われるが、これらのインストール管理ファイルに関するアクセス動作については、上述したインストール動作時と同様に、インストールシステム（２ｅ）がファイルシステムＦＳ２（２ｄ）を介さずにダイレクトに行うか、もしくはデータ内容の暗号化手段を講じるなどの手法をとることになる。
【０１１９】
ところで、前述したインストール動作時に図１５のインストール管理ファイルにおいて、各インストール動作についてのデータ内の２４バイトのリザーブ領域に、ＩＤナンバを記録する手法が考えられる。このようにしたうえで、アンインストールの際はそのＩＤナンバの入力をユーザーに要求し、ＩＤナンバ不一致の場合はエラーとすることで、不用意にアンインストールされないようなシステムとすることができる。
【０１２０】
６．各種ディスク例
上記例では図１３のようにデータファイル等が記録されたパーシャルＲＯＭディスクが、ディスク９０として提供された場合について説明してきたが、パーシャルＲＯＭディスクを用いた場合の本発明のディスク内容例としてはさらに多様な例が考えられる。その各種例のうちの４例を図２１から図２４で説明する。
【０１２１】
図２１のディスク９０は、ＲＯＭ領域ＡＥにファイルシステムＦＳ１、インストールシステム、アプリケーションＡＰ１、ＡＰ２が記録されるとともに、リライタブル領域ＡＲＷの先頭位置にインストール管理ファイルの記録領域が確保される例である。
この例は、特にディスク９０をインストーラーディスクとして用いることに好適な例である。ファイルシステムＦＳ１によってインストールシステム、アプリケーションＡＰ１，ＡＰ２が管理される状態となっており、インストール時には、図１２のシステム動作において、ファイルシステム２ｄ（＝ＦＳ１）に基づいてインストールシステムが読み込まれて起動され、この起動されたインストールシステム２ｅによって上述したようなインストール動作が行われることで、アプリケーションＡＰ１、ＡＰ２のインストールが行われる。
【０１２２】
ファイルシステムＦＳ１はリライタブル領域ＡＲＷについては管理せず、従ってインストール管理ファイルの生成、更新等はインストールシステム（２ｅ）がファイルシステムＦＳ１を介さずにダイレクトに行う。もちろんインストール管理ファイルのデータ内容を暗号化する手法を採用してもよい。
【０１２３】
ところでこの図２１のディスク９０では、リライタブル領域ＡＲＷは、インストール管理ファイル以外には用いられない。
このようなディスクは、図２２のように作り替えることで、例えばアプリケーションのバージョンアップ等にも容易に対応できることになる。
図２２の場合、ＲＯＭ領域ＡＥ内の記憶内容は図２１と同様にファイルシステムＦＳ１、インストールシステム、アプリケーションＡＰ１、ＡＰ２としている。
【０１２４】
一方リライタブル領域ＡＲＷには、その先頭にファイルシステムＦＳ２を形成してリライタブル領域ＡＲＷ及びＲＯＭ領域ＡＥのファイル管理を可能とするとともに、アプリケーションＡＰ１、ＡＰ２のバージョンアップ分となるバージョンアップファイルＡＰ１VU、ＡＰ２VUを記録する。なお、論理フォーマットによりファイルシステムＦＳ２を形成することで、ＲＯＭ領域のファイルシステムＦＳ１は以降使用されなくなる。
またリライタブル領域ＡＲＷの先頭がファイルシステムＦＳ２に用いられることで、インストール管理ファイルが記録される領域は例えばリライタブル領域ＡＲＷの終端部分としている。
【０１２５】
このディスク９０は、図２１のようにアプリケーション提供用に形成されたディスクを、そのリライタブル領域ＡＲＷを有効利用してアプリケーションのバージョンアップにも対応できるようにしたものといえる。図２１のようなディスクはアプリケーションＡＰ等がＲＯＭ化されスタンピングにより大量生産できるが、このようなディスク９０が余っている際にアプリケーションＡＰ１、ＡＰ２のバージョンアップがあった場合、図２２のようにリライタブル領域ＡＲＷを用いてバージョンアップ分のプログラムＡＰ１VU、ＡＰ２VUを追加することで対応できる。
【０１２６】
即ちＲＯＭ領域ＡＥ及びリライタブル領域ＡＲＷの両方を管理するファイルシステムＦＳ２が形成されることで、ファイルシステムＦＳ２からみれば、アプリケーションＡＰ１、ＡＰ２及びバージョンアップ分のプログラムＡＰ１VU、ＡＰ２V の両方が記録されているため、例えばアプリケーションＡＰ１のインストール時には、アプリケーションＡＰ１とともにバージョンアップ分のプログラムＡＰ１VUもインストールできる。
【０１２７】
なお図２２ではＲＯＭ領域にセットアップシステムを記録するようにしているが、このセットアップシステムは論理フォーマットツールとしてファイルシステムＦＳ２を構築するためのものである。この図２２の場合ディスク供給元（ソフトウェアメーカー）が論理フォーマット及びバージョンアップ分のプログラムＡＰ１VU、ＡＰ２VUの書込を行うものであることを考えると、セットアップシステムは必ずしも必要ではない。つまりＲＯＭ領域ＡＥは図２１と同様の形態でよい。
【０１２８】
なお、インストール管理ファイルについては、ファイルシステムＦＳ２によって管理されるが、上述のようにインストールシステムによって暗号化されるものとしてもよいし、ファイルシステムＦＳ２に管理されず、インストールシステムが直接アクセスするものとしてもよい。
また、図２１のディスクの場合で、図２２のような将来的拡張を考える場合、インストールシステムが、インストール管理ファイルの領域をリライタブル領域ＡＲＷの最後尾などに設定するようにすることも考えられる。
【０１２９】
図２３は、ディスク９０をインストーラーディスクとして使えるとともに、そのディスク自身でアプリケーションを走らせて、データを保存できるようにするタイプである。
この場合ＲＯＭ領域ＡＥは、ファイルシステムＦＳ１、セットアップシステム、インストールシステム、アプリケーションＡＰを記憶する。
【０１３０】
一方リライタブル領域ＡＲＷは、セットアップシステムによって論理フォーマットが行われることで、その先頭にファイルシステムＦＳ２が形成されてリライタブル領域ＡＲＷ及びＲＯＭ領域ＡＥのファイル管理が可能とされる。そしてこの場合、リライタブル領域ＡＲＷはユーザー領域として用いられるようにする。なお、インストール管理ファイルの領域はリライタブル領域ＡＲＷの最後尾などに設定され、図２２の場合と同様に暗号化された上でファイルシステムＦＳ２によって管理されるか、もしくはインストールシステムによって直接アクセスされる領域とする。
【０１３１】
この図２３のディスク９０では、ファイルシステムＦＳ２からみれば、インストールシステム、アプリケーションＡＰ、ユーザー領域が管理できるため、例えばインストールを起動させることで上述のようにハードディスク４等へのアプリケーションＡＰのインストール、及びハードディスク等からのアンインストールを行うことができる。
またインストールを行わなくとも、アプリケーションＡＰをホストコンピュータ２側にロードして起動させ、そのアプリケーションプログラムを実行させることもできる。その場合、アプリケーションプログラム実行に伴う各種のデータの保存を、ユーザー領域を用いて行うことができる。
つまりこの場合、ディスク９０をインストール不要のアプリケーション提供メディアとして用いることができる。
【０１３２】
図２４は図２３と同様の機能に加えて、リライタブル領域ＡＲＷを用いてバージョンアップにも対応できるようにするものである。即ちリライタブル領域ＡＲＷを用いてバージョンアップ分のプログラムＡＰVUを追加する。これにより図２２の場合と同様の効果が得られる。
【０１３３】
なお、実施の形態はパーシャルＲＯＭディスクを例にあげたが、本発明は記録再生領域が設けられている記録媒体において広く適用できるものである。
ただし特にパーシャルＲＯＭディスクのように記録不能な例えばエンボスピットによる再生専用領域を備え、アプリケーションプログラム等については再生専用領域に記録しておくことにより、上述してきたようなインストール管理ファイルの更新等の書込動作時に何らかの動作エラーが発生しても、アプリケーションプログラム等が消去／破壊されることはなく、より好適である。
また、インストール管理ファイルのデータを暗号化するようにすれば、何らかの手段で不正にインストール管理ファイルが書き換えられようとしても、それを防止することができる。
【０１３４】
また、上記例ではファイルシステムＦＳ１とファイルシステムＦＳ２の切換機能（上述したフォーマット段階に応じたアドレス変換機能）を有するドライブ装置としての記録再生装置１で説明しているが、ファイルシステムＦＳ１のみにしか対応できないドライブ装置や、ファイルシステムＦＳ２のみにしか対応できないドライブ装置を用いるシステムでも本発明を適用できる。また、ファイルシステムを独自に作成するシステムでも適用可能である。
またパーシャルＲＯＭディスクとしての本発明の実施の形態の例を説明しているが、少なくとも記録再生領域を有するメディアであれば本発明の記録媒体を実現でき、また記録再生領域と再生専用領域の両方を備えたメディアであれば、より好適に本発明の記録媒体を実現できる。
【０１３５】
【発明の効果】
以上説明したように本発明の記録媒体は、当該記録媒体に記録されたアプリケーションプログラムを例えばハードディスクなどの他の記録媒体にインストールする際に、そのインストール動作に関する情報をインストール管理データとして記録再生領域に記録しておく動作を実行させるインストール制御手段を記録しておくため、インストール動作についての経歴等を記録媒体自体が管理できることになる。
【０１３６】
そしてインストール管理データとして、少なくともアプリケーションプログラムを他の記録媒体にインストールした回数を含むものとし、インストール制御手段には、予めアプリケーションプログラムについてのインストール許可回数を設定しておいて、インストール動作が要求された際には、インストール管理データに記録されているインストール実行回数がインストール許可回数に満たない場合のみ、インストール動作を許可させるようにすることで、インストール動作が何度も無制限に実行されることを防止できる。
【０１３７】
またインストール許可回数情報は、インストール制御手段が固定情報として保持することで、その値がむやみに書き換えられることはなく、不法インストール防止機能を高めることができる。
また、インストール許可回数情報は、インストール制御手段が更新可能情報としてインストール管理データ内の情報として保持させることで、メディア提供者側は或る程度フレキシブルにインストール許可回数情報を設定でき、多様な状況に対応できる。
インストール制御手段は、ファイルシステム情報手段に基づいて動作することで、通常のソフトウエアメディアと同様の使用態様で動作させることができる。
またインストール制御手段及びファイルシステム情報手段は、再生専用領域に記録されていることで、不用意に消去されたりすることもなく、またＲＯＭメディアとしてのプログラムファイルとして用いることができる。
【０１３８】
さらにインストール制御手段は、当該記録媒体からアプリケーションプログラムをインストールした先の他の記録媒体から、そのアプリケーションプログラムをアンインストールした場合は、インストール管理データに記録されているインストール実行回数を減ずるように更新動作を行なわせることで、正規なユーザーによる正規な使用範囲において、アプリケーションプログラムが使用できなくなるという不都合を生じさせないとともに、不正なアンインストールやインストール管理データにおけるインストール実行回数の不正な更新もできない。
【０１３９】
またインストール制御手段は、アプリケーションプログラムを他の記録媒体にインストールした際の、当該他の記録媒体やそのドライブ装置に関する情報やインストール実行時の日時情報、ディレクトリなどの照合情報を、インストール管理データとして記録再生領域に記録させることで、アンインストール時にアンインストール対象となっているアプリケーション、ドライブ、ディスク等の個体関係がインストール時の個体関係と同一であるか否かを判断でき、不適切なアンインストール動作を防止できるという効果がある。
【０１４０】
そして記録媒体からのインストール動作管理方法として、インストール実行に応じてインストール回数を記録媒体の記録再生領域に記録しておき、アプリケーションプログラムを或る他の記録媒体へのインストールする要求があった場合は、一方の記録媒体に記録されている過去のインストール回数を確認し、そのインストール回数が所定回数未満であった場合のみに、インストールを実行するようにすることで、無制限のインストールによりアプリケーションが不正に提供されてしまうことを防止することができるという効果がある。
またアプリケーションプログラムのアンインストール要求があった際に、一方の記録媒体に記録されているインストール実行回数情報及び／又は照合情報を参照し、アンインストール対象とされている他の記録媒体のアプリケーションプログラムが、一方の記録媒体からインストールされたアプリケーションプログラムであると判断された場合のみアンインストールを実行することで、正規のユーザーの正規なアンインストールのみを許可するという適切なアンインストール動作管理を実現できる。
【図面の簡単な説明】
【図１】各種ディスクの説明図である。
【図２】パーシャルＲＯＭディスクのエリア構造の説明図である。
【図３】パーシャルＲＯＭディスクのユーザーエリアの構造の説明図である。
【図４】パーシャルＲＯＭディスクの物理フォーマット前の状態の説明図である。
【図５】パーシャルＲＯＭディスクの論理フォーマット前の状態の説明図である。
【図６】パーシャルＲＯＭディスクの論理フォーマット済みの状態の説明図である。
【図７】物理フォーマット処理のフローチャートである。
【図８】パーシャルＲＯＭディスク装填時の処理のフローチャートである。
【図９】論理フォーマット処理のフローチャートである。
【図１０】リード／ライトコマンド発生時の処理のフローチャートである。
【図１１】実施の形態における記録再生装置のブロック図である。
【図１２】実施の形態のシステム動作の説明図である。
【図１３】実施の形態におけるパーシャルＲＯＭディスクの記録内容の説明図である。
【図１４】実施の形態のパーシャルＲＯＭディスクからのインストール動作の説明図である。
【図１５】実施の形態のインストール管理ファイルの説明図である。
【図１６】実施の形態におけるパーシャルＲＯＭディスクからのインストール動作のフローチャートである。
【図１７】実施の形態のインストール動作時にハードディスクに記録されるインストール照合情報の説明図である。
【図１８】実施の形態のインストール動作時にハードディスクに記録されるインストール照合情報の説明図である。
【図１９】実施の形態におけるハードディスクからのアンインストール動作の説明図である。
【図２０】実施の形態におけるパーシャルＲＯＭディスクについての他の記録媒体からのアンインストール動作のフローチャートである。
【図２１】他の実施の形態のパーシャルＲＯＭディスクの記録内容例の説明図である。
【図２２】他の実施の形態のパーシャルＲＯＭディスクの記録内容例の説明図である。
【図２３】他の実施の形態のパーシャルＲＯＭディスクの記録内容例の説明図である。
【図２４】他の実施の形態のパーシャルＲＯＭディスクの記録内容例の説明図である。
【符号の説明】
１  記録再生装置、２  ホストコンピュータ、３  ハードディスクドライバ、４  ハードディスク、１１  コントローラ、１２  エンコーダ／デコーダ、１４磁気ヘッド、１５  光学ヘッド、１９  ＤＳＰ、９０  ディスク、ＡＥ  ＲＯＭ領域、ＡＲＷ  リライタブル領域
【図１】
0003867335.tif 000002
【図２】
0003867335.tif 000003
【図３】
0003867335.tif 000004
【図４】
0003867335.tif 000005
【図５】
0003867335.tif 000006
【図６】
0003867335.tif 000007
【図７】
0003867335.tif 000008
【図８】
0003867335.tif 000009
【図９】
0003867335.tif 000010
【図１０】
0003867335.tif 000011
【図１１】
0003867335.tif 000012
【図１２】
0003867335.tif 000013
【図１３】
0003867335.tif 000014
【図１４】
0003867335.tif 000015
【図１５】
0003867335.tif 000016
【図１６】
0003867335.tif 000017
【図１７】
0003867335.tif 000018
【図１８】
0003867335.tif 000019
【図１９】
0003867335.tif 000020
【図２０】
0003867335.tif 000021
【図２１】
0003867335.tif 000022
【図２２】
0003867335.tif 000023
【図２３】
0003867335.tif 000024
【図２４】
0003867335.tif 000025