JP4211101B2

JP4211101B2 - 情報処理装置及び方法並びに記録媒体

Info

Publication number: JP4211101B2
Application number: JP32236298A
Authority: JP
Inventors: 春良鈴木
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1998-11-12
Filing date: 1998-11-12
Publication date: 2009-01-21
Anticipated expiration: 2018-11-12
Also published as: US6601139B1; JP2000148504A

Description

【０００１】
【発明の属する技術分野】
本発明は、情報を処理する情報処理装置および方法ならびに情報が記録された記録媒体に関し、詳しくは情報処理装置の本体と記録媒体がソフトウェアおよびデータ上完全に分離されて、記録媒体の交換によっていろいろなアプリケーションが可能となるようなアーキテクチャの情報処理装置および方法並びに記録媒体に関する。
【０００２】
【従来の技術】
従来、日本語ワードプロセッサ装置、いわゆるワープロ、電子手帳、小型・携帯型のパームトップ型の情報機器等が提供されている。これらの情報機器では、ハードディスクを内蔵せず、いわゆるＲＯＭマシンの形態をとるものが多い。これらＲＯＭマシンでは、ソフトウェアは簡単には交換可能ではなく、通常一定のソフトウェアのみしか動作しない専用機となっているものが多い。専用機はその操作、使い勝手において、そのシンプルさゆえに専門技術知識がない人々でも簡単に利用できる利点があるが、逆に、多くの異なったアプリケーションを動作させるのが困難であるという欠点がある。
【０００３】
そこで、パーソナルコンピュータ（personal computer;PC）、いわゆるパソコン等の汎用機が発達を始めたが、その初期の段階から、装置内部にはハードディスクのような容量の大きいデータ記録装置を配置し、それを効果的に利用する手段として、ディスクオペレーティングシステム（disk operating system; DOS）のようなファイルシステム（file system ）が開発され、それらを核としての汎用オペレーティングシステム（operating system; OS）が発達してきた。現在のパーソナルコンピュータやワークステーション、あるいは、ノートブックＰＣ、ＰＤＡと呼ばれるような、いわゆるコンピュータと総称される装置においては、その基本アーキテクチャは、本体の中に内蔵されているハードディスクのようなデータ記録装置の存在を前提に、汎用ＯＳが搭載される形で構成されている。そして、そこには複数のアプリケーションソフトウェアがインストールされて、汎用装置としてのパソコン、コンピュータが成り立っている。
【０００４】
続いて、情報処理装置におけるソフトウェアの階層について、図１２を参照して説明する。図１２は、現在の汎用パソコンのシステム階層を示している。すなわち、システム階層は、上位から下位の順に、アプリケーションプログラム（application program; APP）、アプリケーションプログラムインターフェース（application program interface; API）、オペレーティングシステム（operating system;OS）、デバイスドライバ（device driver;DD）、ハードウェア（hardware;H/W）から構成される。
【０００５】
続いて、このようなソフトウェアのシステムを構成するシステム階層の歴史的な発展を進化論的に説明する。
【０００６】
パソコン草創期には、デバイスドライバがハードウェアに内蔵されるＲＯＭにＢＩＯＳ（basic I/O interface ）という形で書かれており、全てのソフトウェアはこのＢＩＯＳを通して、ハードウェアを制御する形になっていた。ＢＩＯＳは簡単に取りはずしがきくようにはなっておらず、そのため、ＢＩＯＳがそのマシンの機能、性能の限界を定めていた。そのため、ＢＩＯＳに合致する範囲のＯＳやアプリケーションしか動作せず、その意味では、全てのソフトウェアはハードウェアに依存していたと言える。
【０００７】
次に、ハードディスク等の内蔵データ記録装置が普及するに連れて、デバイスドライバがハードディスク内に置かれるようになると、ＯＳとデバイスドライバは何時でも書き換え可能、交換可能となって、一つのハードウェアでも複数の異なるＯＳが走るようになった。逆に言えば、ＯＳが同じであれば、下位のハードウェアにはいろんなバリエーションが許されるようになり、ハードウェアに依存しないハードウェアフリーのコンセプトが一般的となった。しかし、この段階でも、アプリケーションがＯＳに依存する状況は以前と同じであった。
【０００８】
更に、昨今のいわゆるＪＡＶＡ等に代表されるように、ＯＳよりも更に上位のレベルで、アプリケーションのインターフェースを共通に定める技術が確立しつつあり、このことによって、アプリケーションがＯＳからも独立する形が普及し始めている。これは前者よりも一歩進んだ、ＯＳフリーのコンセプトである。この場合は、アプリケーションインターフェースさえ遵守していれば、下位のＯＳの如何を問わず、同じアプリケーションが動作することを保証している。これによってアプリケーションソフトウェアの汎プラットフォーム化が一段と進展しているのは事実である。
【０００９】
【発明が解決しようとする課題】
このように、パソコン等の進化は、一言で言えば、ソフトウェアやアプリケーションの独立化にあると言える。しかし現在、アプリケーションは高度なレベルでその独立性を達成しつつあるが、それはあくまでコンピュータ技術的な進化、作る側での進化であって、一歩、ユーザの視点から、また、人間工学的な側面から見れば、別の不満足な状況が見えてくる。それは、“使いやすさ”、“簡単さ”と言うような視点であるが、この点では、現状のコンピュータは相変わらず“わかりにくく”、“十分複雑”である。
【００１０】
第１に、アプリケーションはまずもって、ハードウェアにインストールする必要があり、必要ならば各種のシステムパラメーターをセットアップ（set up）して、他のアプリケーションやＯＳとの整合性を取っていかないとうまく動作させることができない。より詳しく言えば、アプリケーションソフトウェアは通常例えばいわゆるＣＤ−ＲＯＭ等の媒体で販売されるか、インターネット等からダウンロードされるのが一般的になりつつあり、ユーザはこれらのソフトウェアをまず自分のマシンのハードディスク上にインストールしなければならない。その後、自分のマシンの環境、状態に合わせて、各種のシステムパラメーター等を設定するためにセットアップという作業を行って初めて装置を使用できる状態になる。通常は、ハードディスク上にはそれぞれ異なったベンダーが開発した各種のアプリケーションや共有ファイルが存在しており、これらの相互調整、整合性などを、ユーザ自身が正確に行い得ないと、目的のアプリケーションがうまく動作しなかったり、また、動作しても、不完全であったり、スピードが遅かったり、他のアプリケーションの動作に悪影響を与えてしまうこともしばしばである。また、これらの作業の途中においては誤って必要なファイルを壊してしまったり、思いもかけないトラブルが発生するのが常である。メーカーサイドではこれらのトラブルが生じた場合の緊急的措置として、サポートセンター等を設置して解決に努力をしているものの、何が問題になっているのか、トラブルの現象はどうなっているのか、ハードかソフトウェアかどちらの問題なのか等をユーザ自身が説明できなければならず、結局、ユーザ側に、コンピュータそのものの知識が必要となり、これが、子供、主婦、老人など素人の利用を著しく制限している大きな要因となっている。
【００１１】
第２には、デバイスドライバ、ＯＳやアプリケーションソフトウェアが高機能化する度にバージョンアップを行ったり、また、周辺装置を加えた場合のデバイスドライバのコンフィグレーションやマシンの再起動等もユーザ自身の責任の下で行うことが必要とされている。この場合も、現在どのようなソフトウェアがディスク上に存在し、自分のこれまで作業してきた貴重なデータを破壊しないで、スムーズにシステムを書き換えたり、アドオン（add-on）していくためには、どのような技術的注意を払わなければならないのか、全ては、ユーザ自身の責任になっている。これらの技術的知識は暗黙のルールに基づくものや、ノウハウ的な事柄を含んでいる場合も多く、そういう意味では、ユーザは常に自分のマシンの管理を行うべき運命にあるが、このような状況下においても多くのトラブルが発生しやすく、結局、知識のないユーザはお手上げとなり、素人ユーザへのコンピュータの普及を阻害する原因になっている。
【００１２】
第３に、アプリケーションがうまく動作してからの操作方法に関して言えば、各メーカー共、簡単操作を目的としたＧＵＩ（graphic user interface ）や、簡単メニューなどの工夫を凝らして、表面的には“やさしさ”、“簡単さ”をアピールしてはいるが、一旦、操作中にエラーが生じた場合や、マシンやＯＳの動作に伴うエラーなどによって、本来の動作環境が壊れてしまった場合などでは、マシンの回復手段には相当高度の知識が必要とされるので、技術知識のないユーザは本当に困ってしまう。マシンの回復もさりながら、今まで作成した自分の固有のデータなども失われてしまう恐れにも直面することになる。このようなことも、素人がパソコン等を敬遠してしまっている要因ではないかと考えられる。
【００１３】
以上のように考えてくると、素人への普及を阻んでいる大きな要因は、アプリケーションの準備段階や、エラーやメンテナンスの段階で生じると考えられるが、それをコンピュータアーキテクチャ的に検討すると、問題の所在は、ハードディスクのような内蔵のデータ記録装置上に、ありとあらゆるソフトウェアを混在させんがために、より複雑なＯＳを搭載し、共通ライブラリのようなソフトウェアを肥大化させつつ汎用性を確保しようとする現在のＰＣのアーキテクチャの基本的な考え方にあるとの見解に到達する。
【００１４】
今後、社会生活においても、ますます、情報化、ディジタル化が重要となるが、企業内はともかく、潜在的に幅広いユーザ層がいると考えられる家庭においては、主たるユーザ層は技術者ではないため、そこで利用されるべきコンピュータは、シンプル且つ汎用性があり、技術知識不用の新しいアーキテクチャのパソコンでなければならない。かといって、初めに述べたように、ＲＯＭマシンのような専用機では、マシンそのものはシンプル化されるが、各種のアプリケーションに対してはそれぞれの専用ハードウェアが必要となり、いちいちハードウェアを分けて利用するのは不便であり、家中に物が溢れかえることになってしまう。しかし、汎用性を維持しつつ、現在のパソコンアーキテクチャの延長線上を推し進めていっても、真の問題解決になり得ないのは、今まで見てきた通りである。
【００１５】
更にもうひとつの大きな問題として、ユーザデータの取り扱いがある。昨今では、アプリケーションプログラムとともに、いわゆるコンテンツデータがますます重要となってきている。いわゆるＣＤ−ＲＯＭやいわゆるＤＶＤ−ＲＯＭなどのＲＯＭメディアに置かれるディジタルコンテンツは、それを見るだけであれば、そのメディアを携帯することで済むことが多いが、アプリケーションを実行させていく過程の中で生成されたコンテンツ関連データや、自分が作成した各種のユーザデータ、システムデータ、マシン環境データなどは、ＲＯＭメディアであるため再書き込みができず、ハードディスク内に置かれるか、あるいはフロッピーディスクやＩＣカードのような可搬型ＲＡＭメディアに分離格納されざるを得ない。ハードディスクに置かれていく場合は、作業の継続性を維持しようとすれば、そのマシンでしか、作業を進めることができなくなってしまい、作業場所に制約が生じ、家、学校、会社というように場所が違うところで作業を継続するのには不便となっている。このことは、アプリケーションがハードウェアから完全には独立していないことを意味し、依然として、マシンに従属している状況を示している。そのため、企業、学校、家などの異なる場所で作業を継続しようとすると、多くの場合は、そのマシンを携帯せざるを得ない状況に陥ることになる。また、可搬型ＲＡＭメディアに分離格納される場合は、オリジナルコンテンツの格納されたいわゆるＣＤ−ＲＯＭ等とユーザデータの格納されたＲＡＭメディアを常に一緒に管理する必要が生じ、煩雑で使い勝手も悪い。そして、これら複数のメディアを同一アプリケーション用のデータとして、はっきりした意識下のもとに管理、操作していくには、ユーザ自身にもある程度の技術知識を持っていることが要求されてくる。
【００１６】
本発明は上述の実情に鑑みて提案されるものであって、コンピュータの知識のないユーザ層においても簡単に使用できるような情報処理装置及び方法並びに情報を記録した記録媒体を提供することを目的とする。
【００１７】
【課題を解決するための手段】
上述の課題を解決するために、本発明は、ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された着脱可能な記録媒体を用いる情報処理装置において、上記記録媒体に対する情報の記録／再生を行う記録／再生手段と、情報を記憶する記憶手段と、電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、プログラムを実行する制御手段とを有し、上記制御手段は、上記記録媒体が挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムに基づいて、上記記録媒体のブート領域から上記ソフトウェアを読み込む読み込みプログラムと、上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とを読み込み、上記読み込みプログラムに従って、上記読み込み制御情報のＩＤを参照して上記記録媒体からソフトウェアをセグメント毎に上記記憶手段に読み込んで実行し、上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略し、上記ソフトウェアが終了された場合上記基本アクセスプログラムにより当該ソフトウェアで発生した情報を上記記録媒体に書き込むことを特徴としている。
【００１８】
また、本発明は、ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された着脱可能な記録媒体に対する情報の記録／再生を行う記録／再生手段と、情報を記憶する記憶手段と、電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、プログラムを実行する制御手段とを有する情報処理装置における情報処理方法において、上記制御手段は、上記記録媒体が挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムに基づいて、上記記録媒体のブート領域から上記ソフトウェアを読み込む読み込みプログラムと、上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とを読み込み、上記読み込みプログラムに従って、上記読み込み制御情報のＩＤを参照して上記記録媒体からソフトウェアをセグメント毎に上記記憶手段に読み込んで実行し、上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略し、上記ソフトウェアが終了された場合上記基本アクセスプログラムにより当該ソフトウェアで発生した情報を上記記録媒体に書き込むことを特徴としている。
【００１９】
また、本発明は、着脱可能な記録媒体に対する情報の記録／再生を行う記録／再生手段と、情報を記憶する記憶手段と、電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、プログラムを実行する制御手段とを有する情報処理装置に用いられ、ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された記録媒体であって、上記ソフトウェアを読み込む読み込みプログラムと上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とがブート領域に記録され、上記情報処理装置に挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムにより、上記読み込みプログラムと、上記読み込み制御情報とが読み込まれ、上記読み込みプログラムは、上記読み込み制御情報のＩＤを参照して上記ソフトウェアをセグメント毎に上記記憶手段に読み込む処理を実行させ、上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略させることを特徴としている。
【００２０】
【発明の実施の形態】
以下、本発明に係る情報処理装置及び方法並びに記録媒体の好適な実施の形態について図面を参照して説明する。
【００２１】
まず、本実施の形態のアーキテクチャの概念（コンセプト）を説明する。
【００２２】
従来の技術の項で説明したように、真に使いやすい、家電化、日用品（コモディティ）化された新しい形のパソコンを目指すため、シンプルで且つ複数の異なるアプリケーションが利用できるような基本ハードウェアアーキテクチャシステムを考える。本発明の基本的な概念は、ハードウェア本体には、簡単なメディアロード・アンロード機構である基本アクセスプログラム（以下、本明細書中ではではＢＭＡＰ（Basic Media Access Program）という）というプログラムしか存在せず、全てのソフトウェアおよびコンテンツは着脱可能なリムーバブルメディア（removable media）上に自己完結な形態で搭載されており、そのメディアをドライブに挿入すると、それらのソフトウェアは自動的にロードされ、アプリケーションが使える状態になる。アプリケーションを終了して、メディアをドライブから排出（イジェクト）すると、全ての操作結果やデータ等はそのメディアに記録されており、その意味では、メディアそのものがコンピュータ成立のための全ての情報を担っていると考えることができるものである。このコンセプトに基づく本アーキテクチャを単一メディア活用プラットフォーム（以下、本明細書中ではＳＭＡＰ（Single Media Activated Platform）という）アーキテクチャと呼び、このアーキテクチャに基づいて構成されるシステムをＳＭＡＰプラットフォームと呼ぶ。
【００２３】
本アーキテクチャに基づいて構成された情報処理装置の具体例について、図１を参照して説明する。
【００２４】
情報処理装置１は、文字、画像等を表示する表示画面３を主面に有し、側部にディスクを格納して記録／再生を行うドライブ１０を備えている。ドライブ１０にはリムバーブルメディア２を挿入することができ、リムーバブルメディア２としては、電子本２₁、教育ソフトウェア２₂、電子メール２₃、ワープロ２₄等の各種のソフトウェアを格納したものが提供されている。情報処理装置１には、入力装置としてキーボード４およびマウス５が接続され、出力装置としてヘッドフォン６が接続されている。また、プリンタ７に出力したり、スキャナ８によって読みとったイメージを入力することもできる。更に、表示画面３にはタッチパネルを装着することもでき、ペン型タブレットやその他の入出力装置を接続することもできる。更に、情報処理装置１は、インターネット／ネットワーク９を経由してデータの入出力をすることもできる。
【００２５】
上記ＳＭＡＰアーキテクチャに基づく情報処理装置１、すなわち上記ＳＭＡＰプラットフォームは、挿入するリムーバブルディスク２によっていろいろな装置として使用することができる。すなわち、情報処理装置は、リムーバブルディスク上のアプリケーションソフトウェアとして、例えば、ワープロを搭載しておけばワープロ専用機となり、電子メールソフトウェアの搭載されたメディアを挿入すれば、電子メール端末になる。教育ソフトウェアを搭載したメディアならば、情報処理端末は教育機器となる。また、これらのアプリケーションソフトウェアのためのＯＳも統一する必要はなく、それぞれのアプリケーションに適したＯＳを採用することもできる。本アーキテクチャは１ディスクに１アプリケーション基本概念から出発しているので、大きなアプリケーションには不向きだが、逆に、シンプルオペレーション、すなわち簡単な操作という視点を徹底追及するができたため、家庭向き、素人向きの日用品（コモディティ）化したコンピュータを実現する上で、基本的な役割を果たすことができるものである。
【００２６】
また、本発明の実施の形態の具体例としては、図２に示すような小型の情報処理装置１を挙げることができる。この情報処理装置１は、小型軽量のパームトップサイズのコンピュータ、いわゆるパームトップ型のコンピュータである。この小型の情報処理装置２も、図１に示した情報処理装置１と同じく、挿入するリムーバブルディスク２によっていろいろな装置として使用することができる。
【００２７】
続いて、情報処理装置のハードウェア構成について、図３を参照して説明する。情報処理装置１は、リムーバブルメディア２を格納するリムーバブルメディアドライブ１０と、情報処理装置１における処理を集中して実行するＣＰＵ１１と、主メモリ１２と、不揮発性のメモリであるフラッシュメモリ１３と、接続される外部装置とのインターフェースを行うインターフェース（Ｉ／Ｏ）１４とを有している。
【００２８】
本アーキテクチャでは情報処理装置１の内部には、ハードディスク等の固定型内蔵データ記録装置を一切使用せず、リムーバブルディスク２のみを唯一のデータ記録装置とし、このリムーバブルメディア２が格納されるリムーバブルメディアドライブ１０は所定のインターフェースを通して、ＣＰＵ１１と接続されている。本アーキテクチャによれば、リムーバブルメディア２としては、フロッピーディスクのようなものから、１００ＭＢから２００ＭＢ程度の大容量フロッピーディスク、いわゆるＭＯやいわゆるＭＤデータ、いわゆるＣＤ−ＲＯＭ、いわゆるＤＶＤ−ＲＯＭ、ＩＣメモリカード、いわゆるＰＣカード、いわゆるメモリスティックなどであってもよい。尚、ＭＤデータとは、音楽用で広く利用されているミニディスクのデータバージョンである。メディアの種別で言えば、ＲＯＭ型（read only）、ＲＡＭ型（re-writable）、ＲＯＭ／ＲＡＭ一体型のハイブリッド（hybrid）型があるが、本アーキテクチャはいずれにも適用可能であるが、ハイブリッド型の場合に、特にその特徴を発揮する。メディアの物理的形態で言えば、ディスク型であっても、非ディスク型、例えばＩＣメモリカードのような形態であってもよい。ＲＡＭ型メディアの場合は、生産者側がそこに搭載すべきソフトウェアやコンテンツを業務用等のコピーマシンで一枚一枚生産しなければならず、少量生産では有効だが、大量生産には不向きである。ただ、ディスクであって、一部がＲＯＭ化されているならば、ＲＯＭ部分はＣＤ−ＲＯＭ等と同じに生産は簡単であり、有利である。ここでは、ＲＯＭ／ＲＡＭ一体型のメディアをハイブリッドメディアと呼ぶことにするが、以後の説明では、小型で取り扱いが便利、ハイブリッド化も容易で、且つ安価にできるディスク型のハイブリッドメディアとしていわゆるハイブリッドＭＤデータを想定して、実施例を述べていく。尚、本文内でＲＯＭ部、ＲＯＭＩＤ等は、ＲＡＭ型のＭＤデータの場合は、ソフトウェアやコンテンツが予め記録されている部分と同義である。
【００２９】
情報処理装置１は、本体内蔵のメモリとしては、ＤＲＡＭ等の通常の半導体メモリを主記憶領域である主メモリ１２とし、別途、不揮発性の、例えば、フラッシュ（flash ）メモリ１３を内蔵している。不揮発性メモリとは、電源を切っても情報が保持されるようなメモリを指す。本アーキテクチャでは、電源投入時に自動的に動作開始する上記ＢＭＡＰという初期プログラムが必要であるが、それは、このフラッシュメモリ１３の一部に格納されていても、別途のＥＥＰＲＯＭなどのＲＯＭメモリにあってもよい。いずれの場合でも、上記ＢＭＡＰやフラッシュメモリ１３はＣＰＵのバスに直接接続されており、プログラム実行可能なメモリ空間に割当てられている。上記ＢＭＡＰはリムーバブルディスク上に搭載されているシステムソフトウェアやアプリケーションソフトウェアに全く依存しない独立固定プログラムから成っている。
【００３０】
インターフェース１４としては通常のコンピュータ周辺装置、例えばディスプレイモニタ、キーボード、マウス、ネットワーク、プリンタなどが接続されているものとするが、本アーキテクチャの構成要件として必須のものではない。
【００３１】
続いて、本実施の形態で利用するリムーバブルメディアの例としての上記ハイブリッドＭＤデータの構造と、ＵＷエリアの定義について説明する。
【００３２】
図３におけるリムーバブルディスク２は、ＲＯＭ部２ａとＲＡＭ部２ｂを有するハイブリッドメディアである。上記ハイブリッドＭＤデータの場合には、その基本構造は図４のようになる。現在普及している音楽用のＭＤにはＭＤデータというデータ版の規格があり、これはソニー株式会社により提唱されている“Rainbow Book Part２:MD DATA System”に規定されている。図４はこの規格に則った上で、本アーキテクチャが加えた仕組みを説明するためのものである。
【００３３】
図４の中で、情報領域（information area）とあるのは、ディジタルデータが記録される領域である。内周側には予めデータが記録されており、読み出しのみが可能なＲＯＭ領域となっており、その外側は、記録、読み出し可能なＲＡＭ領域である。リードイン領域（lead-in area）にはＲＯＭ部の目次部（table of contents; TOC）が固定の位置に置かれているが、例えば、このディスクが音楽用か、データ用か等を判断できる情報や、各領域の開始アドレス、長さなどの管理情報が置かれている。リードイン領域（lead-in area）の直後から１クラスター（６４ＫＢ）分はブート領域（boot area ）として定義された領域で、ここには実際のシステムローダプログラム等を置くことができる。残りのＲＯＭ部はＭＤデータ規格で定められた論理フォーマットに基づいて動作するファイルシステム（file system ）等で制御されなければならない。このファイルシステムのディレクトリー等はＶＭＡ（volume management area）に書かれている。次にＲＡＭ部であるが、ＲＡＭ部の開始からはＵＴＯＣ（５０クラスター）というＲＡＭ部をカバーする目次部が置かれ、記録可能ユーザ領域（recordable user area）が実際の使用領域となる。この領域もＲＯＭ部と同様に、ファイルシステム等で制御されなければならないし、そのためのディレクトリー等はＲＡＭ部内のＶＭＡに置かれる。ここで、上記ハイブリッドＭＤデータの場合は、ＲＯＭ部のＴＯＣやＶＭＡ領域はＲＡＭ部のＵＴＯＣ内やＶＭＡ領域にコピーされ、ＲＡＭ部を参照するだけでＲＯＭ部を含めたメディア管理情報がわかるようになっている。最後のリードアウト領域（lead-out area ）は未使用の領域で、通常のファイルシステムからの関数ではアクセス不可と定義されるが、本アーキテクチャにおいては、記録可能領域の直後から始まるこのリードアウト領域の最初の１クラスター（６４ＫＢ）分のシステム使用領域を定義し、これをＵＷ領域と呼ぶ。ドライブのフォーマットコマンド等では、ＵＴＯＣを含めた記録可能領域は再フォーマットされてしまうが、このＵＷ領域はフォーマットの対象からははずれているため、情報処理装置本体側との連携によって、半永久的なデータ保存が可能となる。尚、ＲＯＭ型のＭＤデータディスクの場合は、記録可能領域が存在せず、全て前マスタ領域（pre-mastered area ）となり、リードイン領域（lead-out area ）への書き込みはできない。ＲＡＭ型のＭＤデータディスクの場合は、前マスタ領域が存在せず、全て記録可能領域になるが、この場合は、ＴＯＣ情報からＵＴＯＣの位置がわかり、ＵＴＯＣ後の１クラスター分がブート領域として確保される。尚、通常はリードインの直後からＵＴＯＣが始まるが、交代トラック（alternate track ）をリードインとＵＴＯＣの間に置くこともできる。ＶＭＡはその後に置かれる。従って、本体側では、まず、ＴＯＣを読み出し、その情報によって、ＲＯＭ／ＲＡＭ／ハイブリッドの区別を得る。ＲＡＭ型の場合は、更にＵＴＯＣの情報から、ブート領域を見つけることができるし、ＲＯＭ／ハイブリッドの場合は、リードイン領域の直後にブート領域のあることがわかる。従って、本アーキテクチャで用いるＭＤデータディスクはＲＯＭ／ＲＡＭ／ハイブリッドのどれでも同一に扱うことができるが、ＲＯＭ型の場合は、ＵＷ領域が利用できないという制限があるがそれ以外は同じことである。尚、前マスタ（pre-mastered）と記録可能（recordable）を合せた記憶容量は凡そ１４０ＭＢとなっている。
【００３４】
本アーキテクチャは、このブート領域とＵＷ領域を本体側の上記ＢＭＡＰやフラッシュメモリとの関連において、うまく利用する仕組みを考案したものである。
【００３５】
続いて、本実施の形態に基づく、上記ハイブリッドＭＤデータ上へのソフトウェア格納方法について説明する。図５は、本アーキテクチャにおける、ソフトウェアやデータの格納方法を示したものである。リムーバブルメディア２のデータ記録領域は、ソフトウェアやコンテンツを格納するＲＯＭ部２ａと、ユーザデータを格納するＲＡＭ部２ｂとに大別される。
【００３６】
ＲＯＭ部２ａは内周側から、通常５つのセグメントに分割されており、各セグメントには図に示されたようなソフトウェアの種類が前マスタ（pre-mastered）される。すなわち、最内周から外周側へＲＯＭ部＃１（２ａ₁）ＲＯＭ部＃２（２ａ₂）ＲＯＭ部＃３（２ａ₃）ＲＯＭ部＃４（２ａ₄）ＲＯＭ部＃５（２ａ₅）がそれぞれ同心円状の領域に配置されている。各セグメントの長さや開始アドレスの情報は前マスタするときに図６に示すブート領域（boot area ）内のＳＰデータ部内に記述される。尚、カウントの単位はクラスター（６４ＫＢ）である。実際にこれらのソフトウェアを本体にロードするプログラムはブート領域内のシステムローダ（system loader; SYSLD）部としてディスクから提供される。ＲＯＭ２ａ部の内、＃１から＃４はソフトウェアプログラムを、その役割によって、分類したものである。すなわち、ＲＯＭ部＃１は共通データ、共通プログラム、フォント類、辞書などであり、ＲＯＭ部＃２はＯＳ、デバイスドライバであり、ＲＯＭ部＃３はＡＰＩ、ミドルウェアプログラムであり、ＲＯＭ部＃４はアプリケーションプログラムであり、ＲＯＭ部＃５はディジタルコンテンツである。実際の使用にあたっては、ＲＯＭ部＃１に全てのプログラムが入ってしまうものや、セグメント数を更に増加させることも可能である。ディジタルコンテンツデータはユーザ側で変更する必要のない、または、ユーザに勝手に変更されては困るデータの場合が多く、通常は、電子化された本のデータであったり、大量の静止画、音声、ビデオデータなどがこれに相当する。図５ではディジタルコンテンツデータはＲＯＭ部＃５に置かれているが、通常、これはシステムローダで初期にロードされない場合が多く、アプリケーションが立ち上がった後にアプリケーションによってアクセスされる。実際の使用にあたっては、必要に応じてコンテンツ部分も複数のセグメントに分割しておくこともでき、また、その位置もＲＯＭ部２ａ内のどこにあってもよい。アプリケーションソフトウェアが電子メールのような場合は、コンテンツは搭載されていないこともあるが、本アーキテクチャでは、コンテンツ部分が存在しても、しなくても矛盾なく動作する。ＳＰデータ内に予め記述されるセグメント情報は、一般的には、セグメント数の情報と、システムローダがロードすべきセグメント、ロードしなくてよいセグメントの情報がビットマップ形式で、前マスタ時に記録されている。本実施の形態においてはビットマップとして３２バイトを割当てたので、セグメント数の最大は２５６となる。ＲＡＭ部２ｂは書いたり消したりできる領域であり、ＯＳやアプリケーションに解放されていて、いわゆるユーザデータやシステムデータが格納されていく領域である。
【００３７】
続いて、上述の情報処理装置１およびリムーバブルディスク２における上記ＢＭＡＰ１３ａ、フラッシュメモリ１３内のデータ、システムローダ、ＳＰデータ、ＵＷデータの構成例を示す。
【００３８】
図７に示すように、上記ＢＭＡＰのプログラムは、Ａ点からＢ点のハード初期化プログラム、Ｂ点からＣ点のブート領域とＵＷ領域の読み込みプログラム、Ｃ点以降のＵＷ領域へのＵＷデータの書き込みプログラムから構成されている。そして、上記ＢＭＡＰの先頭からＡ点までの領域には、Ａ点へジャンプ、Ｂ点開始番地、Ｃ点開始番地、ＲＢＴ開始番地、ＲＵＷ開始番地、ＲＳ開始番地、保留、ハードＩＤなどの項目データが置かれている。これらＡ点、Ｂ点、Ｃ点については後述する。
【００３９】
図８に示すように、フラッシュメモリ１３内のデータは、任意サイズの上記ＢＭＡＰ領域、６４ＫＢのＲＢＴ領域、６４ＫＢのＲＵＷ領域、任意サイズのＲＳ領域から構成されている。
【００４０】
図６に示すように、ブート領域は、６０ＫＢのシステムローダ部と４ＫＢのＳＰデータ部からの６４ＫＢである。システムローダ部には、この上記ハイブリッドＭＤデータに搭載されているソフトウェアをセグメント毎に読み込むためのシステムローダ用のプログラムが格納されている。ＳＰデータ部は、ＲＯＭ部セグメント数（２バイト）、ビットマップ（３２バイト）、ＲＯＭ部＃１開始アドレスと長さ（４バイト）、・・・、ＲＯＭ部＃５開始アドレスと長さ（４バイト）、ＲＯＭ５ＩＤ（４バイト）、保留、ＵＳＥＬＩＭＩＴ（４バイト）の順で構成されている。
【００４１】
図９に示すように、ＵＷ領域は６４ＫＢであって、ＵＳＥＤＦＬＡＧ（２バイト）、ＩＤＳＴＡＭＰ（３２バイト）、ＵＳＥＣＯＵＮＴ（４バイト）、ＵＳＥＴＩＭＥ（２０バイト）、ＥＲＲＳＴＡＴＵＳ（１Ｋバイト）、保留の順に構成されている。これら各要素については後述する。
【００４２】
本アーキテクチャの最も基本的な特徴は、上記ハイブリッドＭＤデータをドライブに挿入すると、そのディスクに格納されているソフトウェアが自動的に情報処理装置の本体内にロードされ、アプリケーションが立ち上がっていくものである。従って、ハードウェア側から見れば、ＯＳやアプリケーションを特定する必要がなく、ＯＳとして携帯端末用の各種ＯＳが入っている上記ハイブリッドＭＤデータを挿入すると、そのＯＳに応じたマシンとなる。本実施の形態に基づけば、携帯端末用のＯＳに限られず、各種の組み込み型ＯＳを採用する場合にも本アーキテクチャは適用できるので、ハードウェア側で利用するＯＳを一つに定める必要がない。ある意味で、ハードウェアのＯＳからの独立であると言える。
【００４３】
従来のパソコン等では、ハードウェアは何らかの特定ＯＳを前提として製品化されてきたが、本アーキテクチャにおいてはこの制約をなくすことができ、ハードウェアの汎用性が更に高められ、逆に言えば、上記ハイブリッドＭＤデータがコンピュータそのものとなり、ハードウェアは単なるがらんどうの入れ物装置ということになる。この考えを推し進めれば、例えば、企業や学校の机にハードウェアを埋め込み、個人、個人は自分の上記ハイブリッドＭＤデータ持ち歩くだけで、何時でもどこでも自分のコンピューティング環境を１００％再現できる。すなわち、自分の専用ハードウェアという考えを持つ必要がなくなる。
【００４４】
続いて、本アーキテクチャに基づく情報処理装置がどのように動作するかについて、図１０に示すフローチャートを参照して説明する。
【００４５】
情報処理装置のハードウェアには、上記ＢＭＡＰと呼ばれる、不揮発性ＲＯＭ常駐プログラムが存在し、ステップＳ１１における電源投入（パワーオン）時には、いつでも上記ＢＭＡＰがハード初期化プログラムの開始点（Ａ点）から起動される。上記ＢＭＡＰは図７に示したように３つの部分に別れており、それぞれのプログラム開始点をＡ点、Ｂ点、Ｃ点とする。ハードウェア構成によっては、これらのプログラムサイズは一定しない可能性があるが、外部からＡ点、Ｂ点、Ｃ点を参照できるために上記ＢＭＡＰの頭の２５６バイトにこれらの開始アドレス情報を参照できる固定領域を設けておく。通常のハードウェア構成では、メモリ空間の０番地からＣＰＵが走り出すので、ここにＡ点へのジャンプ命令を置く。ステップＳ１２における、Ａ点からの動作はハードウェアの初期化動作である。初期化が完了するとＢ点に制御が移る。これに続いて、ステップＳ１３でドライブにメディアが挿入されたかを判断しする。メディアが挿入されていると次のステップＳ１４に進み、メディアが挿入されていないと挿入されるまで待ち状態となる。Ｓ１４においては、電源遮断（パワーオフ）の禁止およびメディア排出の禁止を行う。ステップＳ１５においては、Ｂ点に入ると、その中に予め組み込まれている上記ハイブリッドＭＤデータ上のデータを読み込むための最低限のドライブ制御プログラムが動作して、上記ハイブリッドＭＤデータのブート領域から１クラスターである６４ＫＢ分のデータすなわちＳＹＳＬＤ部とＳＰデータ部を主メモリにロードし、その後に、やはり、固定長の領域で、本実施の形態で新たに定義したＵＷ領域から１クラスターすなわち６４ＫＢのデータ（ＵＷデータ）をロードする。システムローダは、このディスク上に搭載されているＯＳやシステムを実際にロードできるようなシステムローディングプログラムであって、ブート領域の先頭番地から書かれている。ＳＰデータ部（４ＫＢ）は、このディスク上のソフトウェアやコンテンツがどのような種類、構成からできていて、どこに格納されているかの情報を提供するものである。ＵＷデータ部には、本体におけるディスクの使用回数や、エラー情報などの発生データが記録される。上述のように、ステップＳ１４において、上記ＢＭＡＰの動作中は、電源遮断（パワーオフ）やディスクの排出（イジェクト）がユーザの操作からできないようにソフトウェアロックがかけられ、誤動作を防止する。具体的には所定のロックコマンドを発行することで実現する。また、ディスプレイの接続されている場合は、上記ＢＭＡＰ内のハードウェア初期化時に、ハードウェア固有の初期画面を映し出すこともできる。上記ＢＭＡＰはディスク上に搭載されているＯＳやアプリケーションの如何にかかわらず、一定の動作であるので、予めハードウェア本体内に常駐しておいても、先ほど述べたハードウェアやソフトウェアの構成上のフレキシビィティに何ら制約を与えるものではない。ブート領域およびＵＷ領域をロードした後は、上記ＢＭＡＰは一旦制御をＳＹＳＬＤの先頭番地に移す。
【００４６】
システムローダの動作は、必要となるＯＳやアプリケーションソフトウェアをディスクから本体にロードすることであるが、これらの制御は読み込まれたＳＰデータ部の情報に基づく。ＳＰデータ部は、セグメントの管理情報とそれ以外のディスク管理情報とから構成される。前者は、以後のシステムローダの動作で詳しく説明するが、後者の一例として、本実施例ではＵＳＥＬＩＭＩＴを定義している。ＵＳＥＬＩＭＩＴには、ディスク販売元が前マスタ時に最大利用回数を設定しておくことができ、ディスク利用を有限回に制限するために用いることができる。尚、後述のＵＷデータ部のＵＳＥＣＯＵＮＴデータと比較することで、この機能は実現できる。さて、セグメントの管理情報であるが、各セグメントの前マスタされた開始アドレスや長さはクラスター単位で与えられており、ビットマップを参照することで、ロードすべきセグメントがどれとどれであるかもわかる。従って、通常はこれらの情報を基に、システムローダ内に含まれているディスク制御プログラムを使って、フラッシュメモリ内のＲＳ領域にソフトウェアをロードする。フラッシュメモリには、直前のディスクからロードされたソフトウェアが残存しているが、もし、今回インサートしたディスクが直前のディスクと同じものであったり、ＯＳやアプリケーションのバージョンが同じである場合には、フラッシュメモリ内のソフトウェアをそのまま利用するほうがロードにかかる時間を節約できる。そこで、システムローダでロードを開始する前に、現在のフラッシュメモリ内に存在するソフトウェアをチェックする。前回ロードされたブート領域の情報、すなわちＳＹＳＬＤ，ＳＰデータはＲＢＴ領域に、ＵＷ領域の情報はＲＵＷ領域に、ソフトウェアは全てＲＳ領域に保存されているので、ＲＯＭ部＃１から順にＲＯＭ１ＩＤ、ＲＯＭ２ＩＤ、・・・をチェックし、ＩＤが異なるセグメント以降のものをロードする方式をとる。このことによって、再ロード時間を実質的に節約することができる。また、この制御判断はユーザの操作等は一切必要なく、自動的に行われるものである。
【００４７】
すなわち、ステップＳ１６においては、システムローダのプログラムを実行する。具体的には、読み込まれたＳＰデータとＲＢＴ内のＳＰデータを比較し、必要なソフトウェアセグメントをディスクからＲＳ領域にロードする。その後、ＲＢＴ、ＲＵＷを更新する。ＲＳに存在しているソフトウェアを実行領域である主メモリに移し、実行の先頭番地に制御を移す。ステップＳ１７では、ＯＳやアプリケーション等のソフトウェアが順次立ち上がりユーザが使用できる状態になる。これに続いて、ユーザがアプリケーションで提供されている機能の操作を行っている状態がある。この状態では、ユーザはコンテンツを見たり、ユーザデータをＲＡＭ部に作成されたり、更新する。特殊なケースとして、別のメディアを入れ替えるために排出の禁止は解除される場合もある。そして、ステップＳ１８においては、ＯＳやアプリケーションの正常終了に伴い、制御は上記ＢＭＡＰのＣ点に移り、メディアの排出が禁止される。ステップＳ１９では、ＯＳやアプリケーションによって更新されたＵＷデータをＵＷ領域に書く。ステップＳ２０においては、メディアを自動排出し、電源遮断可能状態にする。上記ＢＭＡＰのＡ点に制御が移る。そして、この一連の動作を終了する。
【００４８】
続いて、ステップＳ１６における上記判断動作の動作の例を、図１１のフローチャートに示す。
【００４９】
ＲＯＭ部の各セグメント属性を表わすＩＤは、本実施例ではＲＯＭ１ＩＤ、ＲＯＭ２ＩＤ、・・・で示されているが、このＩＤによって、各セグメントのバージョン管理、履歴管理情報等を表わすことができる。本実施例ではＩＤは４バイトで構成した。ＩＤの決め方であるが、本アーキテクチャでは、異なるＯＳやいろんなミドルウェア（middleware）をも利用可能とするために、それぞれを区別していく必要がある。従って、その割り振りに関しては、インターネットのＩＰアドレスのように、発行元が一意であることが望ましく、体系的且つ一元的に管理する必要があるが、これは運用上の問題で解決される。また、ロード時のシステムローダの判断からわかるように、ＲＯＭ部の小さい数字のＩＤのほうには、より共通なソフトウェアやデータを置き、後になるほど、変り得るソフトウェアを置くのが効率的となる。例えば、フォントデータ、辞書データ等のような、いろんなソフトウェアで共通に利用するようなデータは、最初のＲＯＭ部に置くのが、効率的と言える。ロードが完了すると、主メモリ上のブート領域情報、すなわちＳＹＳＬＤ、ＳＰデータをＲＢＴに書き込み更新し、ＵＷデータも後の使用に備えて、ＲＵＷに書き込み更新しておく。この時点で、フラッシュメモリには、挿入されたディスクと同じソフトウェアおよびそれらに関する情報が格納されたと言える。
【００５０】
この後、システムローダはＲＳ領域のソフトウェアを実行領域である主記憶メモリにマップし直して、実行の先頭番地に制御を移す。ここで、ＯＳやアプリケーション等が順次立ち上がり、ユーザが使用できる状態となる。
【００５１】
すなわち、最初のステップＳ２１においては、ＲＯＭ１ＩＤが一致するか否かが判断され、一致しすると“ＹＥＳ”としてステップＳ２３に進み、一致しないと“ＮＯ”としてステップＳ２２に進む。ステップＳ２２においてはＲＯＭ部＃１セグメントを所定のＲＳ領域にロードし、ステップＳ２４に進む。ステップＳ２３においてはＲＯＭ２ＩＤが一致するか否かを判断し、一致すると“ＹＥＳ”として次の判断のステップへ進み、一致しないと“ＮＯ”としてステップＳ２４に進む。ステップＳ２４ではＲＯＭ部＃２セグメントを所定のＲＳ領域へロードし、次のセグメントをロードするステップに進む。ステップＳ２５においてはＲＯＭ４ＩＤが一致するか否かを判断し、一致すると“ＹＥＳ”としてステップＳ２７に進み、一致しないと“ＮＯ”としてステップＳ２６に進む。ステップＳ２６では、ＲＯＭ部＃４セグメントを所定のＲＳ領域へロードする。ステップＳ２７は、主メモリ内のブート領域データであるＳＹＳＬＤ、ＳＰデータでＲＢＴを更新し、ＵＷデータでＲＵＷを更新する。ステップＳ２８においては、ＲＳ領域の全てのプログラムを主メモリに移し、実行の先頭番地に制御を移し、この一連のステップＳ１６の工程を終了する。
【００５２】
アプリケーションが立ち上がると、本体はそのアプリケーションの世界一色になり、ユーザはそのアプリケーションで提供される機能を使って、コンテンツを見たり、ユーザデータを作成して、必要に応じてディスクのＲＡＭ部に記録、更新していく。アプリケーションによっては、別のディスクを入れ替えたりする場合もあるが、この場合には、アプリケーション側からのディスク排出禁止解除が適宜なされてもよい。但し、アプリケーションを終了するにあたっては、いつでも、最初のディスクが再び、本体にインサートされ、ディスク排出禁止がなされていなければならないが、これはアプリケーション側の操作・制御によって実現される。
【００５３】
アプリケーションが稼動している状態においては、本アーキテクチャがサポートする種々のメタデータ、すなわちＵＷデータとして定義されているものをフラッシュメモリ内のＲＵＷ領域に適宜記録、更新しておくことができる。例えば、ＵＳＥＣＯＵＮＴとは、本ディスクが一回利用される度に１づつカウントアップされるもので、本ディスクの利用回数を示している。ＵＳＥＣＯＵＮＴの更新は、例えば、アプリケーション開始の直後とか、正常終了の直前になされてもよい。ＵＷデータの利用方法は、アプリケーション開発側に秩序ある形で開放され、その内容の定義、解釈はアプリケーション開発元、ディスク供給元等が技術面とビジネス面の両方において運用していくことができる。ＵＷデータの内容はディスク毎に定義可能であるので、各ソフトウェア供給ベンダーが自由に定義しても矛盾はおきないが、共通項目に関しては、ある程度共通定義しておく。図９の例はその一端をしめしている。
【００５４】
すなわち、図９に示したＵＷデータにおいて、ＵＳＥＤＦＬＡＧは初めてディスクが利用された時にオンとなる。このＵＳＥＤＦＬＡＧによって、ディスクの新旧の区別が可能である。ＩＤＳＴＡＭＰは、情報処理装置の本体側にハードＩＤがある時は、そのＩＤを書き込むことで、ディスクがどの本体で利用されたかがわかる。本実施の形態では、図７のＢＭＡＰの先頭２５６バイト領域に確保している。情報処理装置のハードウェアの種類を特定するためである。情報処理装置の本体側のハードウェア上のラインアップ、メーカー別、機種別などの区別をしたい場合このデータを用いることで、ディスクとの互換性等が制御可能となる。ＵＳＥＣＯＵＮＴは、ディスクが一回利用される毎にカウントアップされる。情報処理装置の本体側で利用回数を制限することやビジネス上の課金の基礎データ等に使用できる。ＵＳＥＴＩＭＥは、年月日時分秒形式で記録され利用時間等を記録しておくことができる。ＥＲＲＳＴＡＴＵＳは、エラーが発生した場合のログデータを記録できる。ＯＳやアプリケーションが認識できるエラーが生じた場合はそのエラーのログを取ることが可能であるので、ログデータをＲＵＷ部の所定の場所に記録しておく。上記ＢＭＡＰのＣ点動作の中で、このログデータはディスクに記録されるので、エラーの原因、修理等の情報として役立つ。
【００５５】
本実施の形態のアーキテクチャでは、アプリケーションの終了に伴い、ＵＷデータを更新するため、再び上記ＢＭＡＰに制御が移ってこなければならないが、この為には、アプリケーションやＯＳにおいて、ソフトウェアの終了が明示的に意識され、正常終了、異常終了のどちらの場合も全て、制御が上記ＢＭＡＰのＣ点に戻るようにプログラミングされている必要がある。これは各アプリケーションやＯＳが終了にあたってＣ点にジャンプするような命令をプログラミングしておくことで解決する。ジャンプ先である上記ＢＭＡＰのＣ点の開始アドレスは図７のように、上記ＢＭＡＰ内の固定位置に定められるから、上記ＢＭＡＰ内のプログラム量の増減に係わらず、確実にＣ点へジャンプできる命令をプログラムすることができる。尚、プログラムの暴走という事体が生じる場合があるが、そのような場合に備えて、強制的にＣ点動作に入れるようなスイッチを本体側に設けておくこともできる。
【００５６】
Ｃ点動作に入ると、念のため、ディスク排出禁止がなされ、ＲＵＷデータをディスクのＵＷ領域に書き込む。これによって、ディスクがどのような状態で利用されたかのメタ情報がディスク自身に記録されることになる。ここで、ディスク排出は解除され、自動排出コマンドの発行、または、本体の排出ボタンを操作するかして、ディスクが取り外される。そして電源遮断（パワーオフ）可能状態となり、制御は次のアプリケーション待ちとして、上記ＢＭＡＰのＡ点に戻る。
【００５７】
以上が本実施の形態のアーキテクチャの動作説明である。本アーキテクチャに基づけば、ディスクをインサートするだけで簡単に起動し、専門家以外あるいはパソコンやコンピュータ知識のない素人ユーザが使いやすいコモディティ化された家庭用のコンピュータ（ホームコンピュータ）が実現できるものである。
【００５８】
尚、上述の本実施の形態の中で、システムローディングの部分であるが、初期のパソコンにおいて、フロッピーからシステムロードする形態があったが、ハードウェア側にＢＩＯＳというデバイス駆動プログラムの一部が搭載されており、本実施の形態のアーキテクチャのようにソフトウェアやコンテンツの全てをディスク側に置くという発想ではなかった。また、アプリケーションをＣＤ−ＲＯＭからロードするという形態はＣＤ−Ｉ、ゲーム機で採用されているが、ＯＳ等はハード側に置かれていた。いずれにしても、本アーキテクチャにおける上記ＢＭＡＰ動作のように、アプリケーション終了後に再び上記ＢＭＡＰに制御が移り、メディアをトータルにコントロールしていく形態のものはなかった。
【００５９】
次に、本発明を記録媒体に適用した実施の形態について説明する。
【００６０】
本発明に係る記録媒体の実施の形態としては、情報を記録された記録媒体であって、情報処理装置における処理に必要な全てのソフトウェアとコンテンツを記録された記録媒体を用いる情報処理装置に利用され、上記記録媒体に対する情報信号の記録／再生を行う記録／再生工程と、情報を記憶する記憶工程と、上記各工程を制御し、上記記録媒体が上記情報処理装置に挿入されると、上記記録／再生工程にて上記記録媒体から必要なソフトウェアやコンテンツを上記記憶工程に読み込んで実行し、必要な情報を上記記録媒体に記録し、上記ソフトウェアの実行を終えると上記記録媒体を排出するように制御する制御工程とによって実行される少なくともデバイスドライバが記録されてなるものを挙げることができる。
【００６１】
また、本発明に係る記録媒体の実施の形態としては、情報を記録された記録媒体であって、情報処理装置における処理に必要な全てのソフトウェアとコンテンツを記録された記録媒体を用いる情報処理装置に利用され、上記記録媒体に対する情報信号の記録／再生を行う記録／再生工程と、情報を記憶する記憶工程と、上記各工程を制御し、上記記録媒体が上記情報処理装置に挿入されると、上記記録／再生工程にて上記記録媒体から必要なソフトウェアやコンテンツを上記記憶工程に読み込んで実行し、必要な情報を上記記録媒体に記録し、上記ソフトウェアの実行を終えると上記記録媒体を排出するように制御する制御工程とによって実行される少なくともオペレーティングシステムが記録されてなるものを挙げることができる。
【００６２】
更に、本発明に係る記録媒体の実施の形態としては、情報を記録された記録媒体であって、情報処理装置における処理に必要な全てのソフトウェアとコンテンツを記録された記録媒体を用いる情報処理装置に利用され、上記記録媒体に対する情報信号の記録／再生を行う記録／再生工程と、情報を記憶する記憶工程と、上記各工程を制御し、上記記録媒体が上記情報処理装置に挿入されると、上記記録／再生工程にて上記記録媒体から必要なソフトウェアやコンテンツを上記記憶工程に読み込んで実行し、必要な情報を上記記録媒体に記録し、上記ソフトウェアの実行を終えると上記記録媒体を排出するように制御する制御工程とによって実行される少なくともアプリケーションが記録されてなるものを挙げることができる。
【００６３】
そして、本発明に係る記録媒体の実施の形態としては、情報を記録された記録媒体であって、情報処理装置における処理に必要な全てのソフトウェアとコンテンツを記録された記録媒体を用いる情報処理装置に利用され、上記記録媒体に対する情報信号の記録／再生を行う記録／再生工程と、情報を記憶する記憶工程と、上記各工程を制御し、上記記録媒体が上記情報処理装置に挿入されると、上記記録／再生工程にて上記記録媒体から必要なソフトウェアやコンテンツを上記記憶工程に読み込んで実行し、必要な情報を上記記録媒体に記録し、上記ソフトウェアの実行を終えると上記記録媒体を排出するように制御する制御工程とによって実行される少なくともコンテンツが記録されてなるものを挙げることができる。
【００６４】
また、本発明に係る記録媒体の実施の形態においては、書き換え可能または一部が書き換え可能で他の部分が書き換え不可能であるときには、ソフトウェアを終了する際に、上記記録媒体の所定の領域にシステム情報、エラー情報、利用関係、年月日の少なくとも一つを含む情報を上記記録媒体の記録するようにすることができる。
【００６５】
尚、これらの記録媒体すなわちメディアとしては、フロッピーディスクのようなものから、１００ＭＢから２００ＭＢ程度の大容量フロッピーディスク、いわゆるＭＯやいわゆるＭＤデータ、いわゆるＣＤ−ＲＯＭ、いわゆるＤＶＤ−ＲＯＭ、ＩＣメモリカード、いわゆるＰＣカード、いわゆるメモリスティックなどであってもよい。また、これらの記録媒体の内容は、通信回線を介して提供することもできる。
【００６６】
以上の説明は、本実施の形態のアーキテクチャを実現するためのリムーバブルメディアの具体例として、いわゆるハイブリッドＭＤデータを中心に述べてきたが、その中でのデータフォーマット上の変形例も幾つか考えられる。また、本実施の形態のアーキテクチャの有効性は上記ハイブリッドＭＤデータのみにとどまらず、次世代ＭＤや他のリムーバブルメディアでも実施可能である。また、情報処理装置の本体を実現する変形例も、幾つか考えられる。更に本実施の形態のアーキテクチャに基づく新しい機能、形態も考えられる。これらについて以下、順次説明する。尚、今までの説明では上記ハイブリッドＭＤデータを中心に説明したので「ディスク」という用語を用いたが、以下の説明ではより一般的な用語として「メディア」を用いて記述する。
【００６７】
まず、本実施の形態の第１の変形例について説明する。本実施の形態のアーキテクチャではリムーバブル側に全てのソフトウェアやコンテンツを搭載するが、これが可能なメディアとしては、ＲＡＭ型、ＲＯＭ型、ＲＯＭ／ＲＡＭ一体のハイブリッド型のどれでもよい。但しＲＯＭ型の場合は、ＵＷデータ部を書き込む領域が確保できないため、ＵＷデータがメディアと一体化されて初めて意味が出てくる機能は実現されないが、ＵＷデータをフラッシュメモリ内のＲＵＷには保存できるので、使用するメディアが一枚に限られるアプリケーションやメディアの区別の必要のない場合にはＲＵＷデータは同じように活用できる。ＲＯＭ型の場合は、通常データのビューイング（viewing ）だけに限定されるアプリケーションが多いが、ＲＯＭ型ＭＤデータ、いわゆるＣＤ−ＲＯＭ、いわゆるＤＶＤ−ＲＯＭ等のメディアを用いた場合がこれに該当する。尚、ＲＡＭ型とハイブリッド型はメディア製作過程が異なるのみで、本アーキテクチャから見た場合の機能上は全く同等に考えてよい。
【００６８】
続いて、本実施の形態の第２の変形例について説明する。リムーバブルメディアのの物理形態には大きくディスク型と非ディスク型があり、前者は、１００ＭＢ〜２００ＭＢ程度の大容量フロッピーディスク、いわゆるＦＤ、いわゆるＭＯ、いわゆるＣＤ、いわゆるＭＤ、いわゆるＤＶＤ、いわゆるＰＤ、リムーバブルのＨＤＤなど、次世代光ディスク／磁気ディスクがある。後者には、半導体をベースとしたいわゆるＰＣカード、各種メモリカード、ＩＣカード、メモリスティックなどがある。カード系であっても、ＲＯＭＩＣとＲＡＭＩＣを混在させることができるので、ハイブリッド型が実現できる。テープ系はＲＡＭ型であって、理論上は本実施の形態のアーキテクチャで実現可能だが、ランダムアクセスの点であまり実用的ではない。いずれにしても、今後開発されてくる全てのリムーバブルメディアに対し、本アーキテクチャにおいて、一つの物理メディアを定めれば、それに応じたドライブが定まるから、本体側の上記ＢＭＡＰは容易に作成でき、また、メディア側でのソフトウェアセグメントの配列も本説明に沿った形で容易に定義できるので、本アーキテクチャがカバーできる範囲と考えることができる。
【００６９】
続いて、本実施の形態の第３の変形例について説明する。情報処理装置の本体に唯一存在する上記ＢＭＡＰは本説明では、内蔵フラッシュメモリの一部を利用したが、上記ＢＭＡＰＲＯＭとして内蔵フラッシュメモリと分離することもできる。情報処理装置の本体を生産する場合に、上記ＢＭＡＰＲＯＭだけ別の部品のほうが取り扱いが便利なこともある。また、上記ＢＭＡＰにおいて、初期起動時間を節約するため、情報処理装置のハードウェアの初期化の後にシステムローダ等の読み込みを開始するという直列制御ではなく、適宜ドライブのインタラプト処理を組み合わせることでドライブのウエイト（wait）状態のときに他の部分のハードウェアの初期化を平行して実行するように上記ＢＭＡＰをプログラミングしておくこともできる。
【００７０】
続いて、本実施の形態の第４の変形例について説明する。上記ＢＭＡＰおよびシステムローダのプログラム内には、メディアの基本単位をＲＥＡＤ／ＷＲＩＴＥするプログラムが入っているが、これらは共通化して一つにして、ＢＭＡＰ内に置くこともできる。更に、そのルーティンの開始アドレス、引数のポインタなどを上記ＢＭＡＰの先頭２５６バイト内の保留領域を使用して、固定位置に定義しておけば、システムローダやアプリケーションからも利用することが可能となる。
【００７１】
続いて、本実施の形態の第５の変形例について説明する。内蔵のフラッシュメモリの部分は、スタティックＲＡＭ等でもよく、必ずしもフラッシュメモリでなければならないわけではない。基本的には不揮発性のメモリならなんでもよい。
【００７２】
続いて、本実施の形態の第６の変形例について説明する。本説明においては、いわゆるハイブリッドＭＤデータにＵＷデータ部を書き込むＵＷ領域として、リードアウト領域内にそれを新たに定義したが、別の場所に定義することも可能である。例えば、ＵＴＯＣ内には保留領域も残されており、そこをＵＷ領域の候補とすることもできる。その場合は、フォーマットコマンドでＵＴＯＣを書き換える前には、ＵＷデータ情報を主記憶にコピーしておき、後で更新するようにしていけばよい。記録可能ユーザ領域の一部をＵＷ領域として定義し、使用する場合も同様である。
【００７３】
続いて、本実施の形態の第７の変形例について説明する。ブート領域のサイズ、ＵＷ領域のサイズは本説明では６４ＫＢとしたが、これは上記ハイブリッドＭＤデータの読み出し書き込み単位が１クラスターが６４ＫＢのほうが都合がよいためである。異なるメディアではそのメディアのアクセス単位に沿った値で構わない。
【００７４】
続いて、本実施の形態の第８の変形例について説明する。ソフトウェアセグメントの個数は、本説明では、最大２５６個としたが、ビットマップを増やすことや、場合によってはＳＰデータ部のサイズを４ＫＢ以上にすることで、大きく取ることもできる。
【００７５】
続いて、本実施の形態の第９の変形例について説明する。上記ＢＭＡＰがブート領域からシステムローダやＳＰデータ部をロードしてくる場所は、本説明では主メモリとしたが、内蔵のフラッシュメモリであっても構わない。この場合は内蔵のフラッシュメモリ内に６４ＫＢの領域をブート領域ロード用に別途確保すればよい。
【００７６】
続いて、本実施の形態の第１０の変形例について説明する。上記ＢＭＡＰ以外には内蔵のフラッシュメモリが搭載されていない情報処理装置のハードウェア構成も考えられる。本実施の形態のアーキテクチャに沿った小型の情報処理装置を商品化する場合などは、コストの面からそのような考えも成り立つ。この場合は、内蔵のフラッシュメモリに直前のソフトウェアが残存していることがないため、メディアを情報処理装置の本体の挿入するたび毎に、必ず必要な全ソフトウェアセグメントが主メモリに直接ロードされる。この場合、ＢＭＡＰ内のＲＢＴ、ＲＵＷ、ＲＳの開始アドレス等は主メモリのアドレスに設定されていなければならないが、図１０のシステムローダのプログラムの実行時にＲＢＴ、ＲＵＷの新旧比較をする必要はなくなる。但し、ＲＢＴやＲＵＷは固定長なので、ＢＭＡＰがフラッシュメモリで構成される場合には、ＢＭＡＰの空いている場所に領域を確保することもできる。
【００７７】
続いて、本実施の形態の第１１の変形例について説明する。内蔵のフラッシュメモリのサイズは、基本的には必要なソフトウェアセグメントを全て格納できるサイズが必要である。本実施の形態のアーキテクチャで対象としているソフトウェアはそれほど重いなものではなく、一つ一つは軽快なものであるべき、と考えており、基本的には数ＭＢ程度以下と考えられるが、それはコストや本体の物理的大きさ等から、生産するメーカー判断にまかされている。もし、ハードウェアが搭載している内蔵のフラッシュメモリよりも大きなソフトウェアセグメントを搭載したメディアが挿入された場合は、オーバーした部分は、連続的に主記憶領域にロードしていけばよい。この場合は、全てのソフトウェアセグメントが不揮発性とならないので、主記憶にロードされた部分は、同じメディアが挿入されても毎回再ロードされていかなければならない。これは例えば、ロード後のＲＢＴ内の主メモリにロードされた該当セグメントのＲＯＭＩＤを一定の予約ビットパターンで書き換えておくことで、次に挿入された時、該当ＲＯＭＩＤがマッチしないようにすることで再ロードを実行させていくことができる。尚、予約ビットパターンは実際のソフトウェアセグメントには絶対に割当てられることのないビットパターンとして予め定めておくことで可能である。また、全てのＲＯＭＩＤを予約パターンに書き換えておいて、全セグメントを再ロードさせてもよい。更に、各ＲＯＭ部の長さを予めシステムローダのプログラム内において計算し、オーバーする場合には内蔵のフラッシュメモリを経由せず、直接主メモリにロードするという方法もある。この場合は内蔵のフラッシュメモリの実装されていない本体の動作と同等になる。
【００７８】
続いて、本実施の形態の第１２の変形例について説明する。上記とは逆に内蔵のフラッシュメモリのサイズが通常ロードするソフトウェアセグメントのトータルサイズの数倍になって実装されている場合は、複数個のシステムをフラッシュメモリ内に残存させておくことができる。そうすればその分だけヒット率が上がり、再ロードせずにアプリケーションを立ち上げる確率を高くすることができる。これは内蔵のフラッシュメモリ内に複数のシステムが残存できるようなＲＳ領域分割管理情報を設け、システムローダが新旧比較する時点で、これら複数のＲＳ領域をそれぞれ比較して行うことで実現できる。
【００７９】
続いて、本実施の形態の第１３の変形例について説明する。アプリケーションが立ち上がった後は、マシン全体のハードウェアリソースは、全てそのアプリケーションの制御下に置かれていくことになる。本アーキテクチャでは、原則として、ソフトウェアをロードするために最初に挿入されたメディアがそのまま書き込み可能なデータ記録装置の役目を果たすが、アプリケーション次第では、複数枚のメディアを使用したい状況も出てくる。例えば、コンテンツが一枚のメディアに入りきれない場合はアプリケーションの進行に従い、複数枚のＲＯＭメディアが順次差し替えられていくことがある。また文書ファイリングアプリケーションや文書作成の場合、あるいは、バックアップコピーやデータコピー機能を実現するためには、ブランクメディア（ＲＡＭ型）の追加が必要ともなってくる。このような状況下においては、メディアの差し替え制御は全てアプリケーションの制御にまかされるが、アプリケーションを終了する時点では、上記ＢＭＡＰのＣ点動作以降でＵＷデータを書き込み更新するために、元のメディアがドライブ差し込まれている必要がある。元のメディアが差し込まれているかどうかは、それを排出する時に、アプリケーション側で制御可能な書き込み領域に、のちに照合できるような情報を書き込んでおくかして、そこを参照することによって、違うメディアの場合は、ユーザに元のメディアを差し込むようにメッセージを出すなりして、促すことができる。もう少し、統一的に取り扱う方法としては、アプリケーション側はどのメディアが差し込まれている状態でも終了してよいことにする代わりに、元のメディアを排出する際、そのインタラプト処理において上記ＢＭＡＰへ制御を一時移し、上記ＢＭＡＰ側でＵＷデータにメディア特定情報を記録し、アプリケーションが終了して再び上記ＢＭＡＰのＣ点動作が開始した時点で、まず、ＵＷデータを再び読み込み、違うメディアが差し込まれている場合は、それを排出し、元のメディアをユーザに差し込むように促すこともできる。
【００８０】
続いて、本実施の形態の第１４の変形例について説明する。アプリケーション等の異常終了、暴走等のため、本体側に強制的に図７に示したＣ点に移行させるスイッチを設けておくことができる。一種のリセットスイッチの役割を果たす。
【００８１】
続いて、本実施の形態の第１５の変形例について説明する。一般的にメディアにはその種別を示す情報がＴＯＣ等に書かれているので、それを参照することでＲＯＭ型メディアと確認できた場合は、上記ＢＭＡＰのＣ点動作においても、ＵＷデータをメディアに書き込まないようにプログラミングしておくことができる。
【００８２】
本実施の形態のアーキテクチャの新しいメリットとして、例えば次のような機能が実現できる。
【００８３】
第１の機能としては、メディアのコピーがある。ユーザやシステムの作成するＲＡＭ部データが、そのメディアに搭載されたコンテンツに関連している場合は、同じコンテンツの搭載されているメディアへのＲＡＭ部分のコピーが有用となる。異なるコンテンツのメディアにＲＡＭ部分をコピーしてもあまり意味はない。例えば、コンテンツが教科書データであって、ＲＡＭ部が教科書データを参照する形で作成される電子ノートなどの場合が該当する。もちろん、著作権保護の立場から、ＲＯＭ部のデータをコピーするようなことは避けなければならないから、コピーできる部分はＲＡＭ部のみに限られる。このような場合は、コピー先のメディアが、コピー元のメディアと同じコンテンツを有していることを判別しなければならないが、これは、アプリケーションソフトウェアが、コピー先メディアのＳＰデータ部のＲＯＭＩＤとコピー元メディアのＳＰデータ部のＲＯＭＩＤとを比較することで実現できる。コピーするためには、そのコンテンツを搭載したメディアを用意する必要があるから、コンテンツ供給者から見れば、メディアが一枚売れることになり、よ言われるように、コンテンツがコピーされてしまうことにはならないし、ユーザ側からすれば、自分の作成した電子ノートを自由に誰かにコピーさせてあげることができる。この意味においては、本アーキテクチャに基づくメディアコピー機能は、コンテンツ供給者、ユーザ側の両方を満足させることができるものと言える。
【００８４】
２台または、それ以上のドライブが実装されている本体の場合にも、それぞれのコピー元、コピー先のドライブに入っているメディアのＳＰデータ部のＲＯＭＩＤを比較することで行える。尚、メディアコピーのように全く同じメディアを複製するのではなく、単にＲＡＭ部分を別のメディアにバックアップしておくような場合には、ＳＰデータ部の比較を行う必要がないのは言うまでもない。
【００８５】
第２の機能としては、ソフトウェア利用回数の制御がある。ＳＰデータ部の利用方法の一つとして、ＵＳＥＬＩＭＩＴがある。ここには、メディア供給元が前マスタする時に、このメディアの使用回数の最大値を書いておく。一方、メディアはそこに搭載されたアプリケーションが本体で稼動される（使用される）度に、ＵＷデータ部のＵＳＥＣＯＵＮＴを一つずつカウントアップしていく。ある時点でＵＳＥＣＯＵＮＴの値がＵＳＥＬＩＭＩＴの値を超えれば、そこでこのメディアはそれ以後使用できなくするようにアプリケーション側で制御可能となる。現行のソフトウェアにおいて「お試し版」というものがあるが、これは機能を制限したものや、本体内の時計との比較により期限限定のようなものが見受けられるが、本アーキテクチャでは、使用回数を制限することで、代わりにフル機能ソフトウェアのままの形をユーザに提供できる。ビジネス上の見地からは、同じフル機能版であっても、ＵＳＥＬＩＭＩＴの値のみを変更するだけで、販売価格を複数通りに設定することも可能となり、販売戦略に自由度ができ、供給元、ユーザの両方にとって理想的な価格設定を実現していくことも可能となる。ＵＳＥＣＯＵＮＴのデータをインターネット等を通してサーバー側で計算するような課金方式も実現できる。
【００８６】
以上説明したように、本実施の形態は、一枚のリムーバブルディスクにデバイスドライバ、ＯＳ、アプリケーション、コンテンツが全て搭載され、操作結果のデータ等もそのメディアに書き込むことによって、本体とメディアが完全に分離され、メディアの交換のみでいろいろなアプリケーションが可能となるようなコンピュータシステムアーキテクチャを提供するものであって、コンピュータの知識のない人でも容易に操作でき、具体例としてＭＤデータを用いたものを示した。
【００８７】
すなわち、本実施の形態は、ハードウェア本体にはハードディスクのような内蔵の記録装置を一切持たず、リムーバブルメディアを唯一の記録装置として、そこに全てのソフトウェア、アプリケーション、コンテンツが搭載され、本体にメディアをインサートすると自動的に必要なソフトウェアが本体内にロードされ、コンピュータとして稼動し、メディアが排出された時点でコンピュータとしての機能が消滅し、別のメディアをインサートすると、再び、そのメディアに搭載されたソフトウェアによって、別のコンピュータとして稼動できるものである。従って、一つのハードウェアで、さまざまなＯＳやアプリケーションをメディアの差し替えだけで簡単に実現できる。本コンセプトはＲＡＭ型、ＲＯＭ型、ＲＯＭ／ＲＡＭ一体のハイブリッド型のどのメディア種別にも適用でき、また、物理形態としてはディスクタイプや半導体によるＩＣメモリカード等にも適用できる。
【００８８】
また、本実施の形態は、ＲＡＭ型メディアおよびハイブリッド型メディアを使った場合には、コンピュータとして機能している間に生成されるシステムデータ、ユーザデータ類は、アプリケーションの終了と同時に、そのメディアに全てが記録され、この一枚のメディアだけを携帯することで、いつでも、どこでも、自分のコンピュータ環境が１００％再現できるものである。言い換えれば、本実施の形態によって、自分用の作業ハードウェア言う概念が必要なくなる。
【００８９】
更に、本実施の形態は、本体にはメディアに搭載されるさまざまなソフトウェアとは無関係の３つの部分に別れたプログラム群が上記ＢＭＡＰという形で搭載されており、メディアがインサートされるとまず、このメディアのソフトウェアを本体にロードするシステムローダというプログラム、及び、ローディングを制御するＳＰデータがメディア上の固定的に定められた場所からロードされる。メディア上のソフトウェアやコンテンツは複数個のセグメントに分割されており、各セグメントにバージョン等を区別するＩＤが設けられており、システムローダは、これらのＳＰデータ情報を参照しながらに所定の場所に実際のソフトウェアローディングを行う。アプリケーションの終了にあたっては、本体内の上記ＢＭＡＰに再び制御が戻ってきて、発生したシステムデータ、エラー情報、利用回数、年月日等のＵＷデータをメディア上の固定的に定められた場所に書き込むことによって、全体の動作が完了するローディング、アンローディングメカニズムに基づくものである。メディアの挿入から排出までを本体のＢＭＡＰが制御する。
【００９０】
そして、本実施の形態は、情報処理装置の本体のハードウェアにはハードＩＤが上記ＢＭＡＰの一部に予め記録されており、必要に応じて、ハードＩＤをＵＷデータ部に記録しておくことにより、本体とメディアとの互換性を認識できるものである。
【００９１】
また、本実施の形態は、情報処理装置の本体側に不揮発性メモリ、例えばフラッシュメモリが搭載されているハードウェアの場合には、ローディングの際にこのセグメントＩＤをフラッシュメモリ内のすでにロードされていたソフトウェアのＩＤと比較することで、同じソフトウェアローディングを２重に行うことを避け、起動時間を節約できる構造を持ったものである。
【００９２】
更に、本実施の形態は、メディアとして、いわゆるＭＤデータまたはいわゆるハイブリッドＭＤデータを採用し、新たにリードアウト領域、またはＵＴＯＣ領域等にＵＷ領域を設け、すでに定義されているブート領域とこのＵＷ領域を用いて、上記の機構を具体的に実現するものである。
【００９３】
そして、本実施の形態は、ＳＰデータ部のＲＯＭＩＤの情報を比較することにより、自分と同じコンテンツをすでに搭載しているメディアにしか、自分のＲＡＭ部のデータをコピーさせないことが実現できる。このことにより、コンテンツ供給者の著作権利を保護しつつ、ユーザ側で自由にメディアの複製を行うことができる。
【００９４】
更に、本実施の形態は、起動時にローディングされるＳＰデータ部には、ローディングの制御データとメディアの管理情報が定義され、メディア管理情報にメディアの利用に関するデータを予告記述しておき、実際のメディアの利用に関するデータをＵＷデータ部に記録することで、本体がそれらを比較することで、メディアの利用を制御できるコンピュータシステム。例えば、実施例では、ＵＳＥＬＩＭＩＴとＵＳＥＣＯＵＮＴによって、メディアの利用回数を制御できる。
【００９５】
尚、本実施の形態においては、メディアとしてＭＤメディアを例示したが、本実施に用いるリムーバブルメディアがＭＤデータに限定されないことは言うまでもない。
【００９６】
また、本実施の形態においては、ハードディスクを内蔵しないアーキテクチャについて説明したが、本発明はこれに限定されない。本発明の実施の形態は、ハードディスクを内蔵するアーキテクチャに適用することができることはもちろんである。
【００９７】
【発明の効果】
上述のように、本発明のアーキテクチャのシステムコンセプトに基づけば、メディアには全てのソフトウェア、データ、コンテンツが搭載されるので、通常のパソコン等で必要なインストール作業が全く要らない。また、インストール後におけるアプリケーションの初回起動準備作業としてシステムパラメーター等を設定するなどの、いわゆる、セットアップ作業も必要なく、購入したメディアをインサートするだけでマシンが稼動する。つまり、コンピュータの技術知識がない人でも簡単に管理、操作でき、家電商品のような簡単な取り扱いが実現される。
【００９８】
また、本発明によると、ソフトウェアのバージョンアップ、アップグレードが行われた場合であっても、新旧のバージョンの「差分」をユーザみずからマシンにインストールするなどの作業は必要なく、単に、新バージョンの搭載されたメディアを利用するだけでよいので、開発供給元、ユーザ側共に、簡単でわかりやすく、取り扱いやすい。
【００９９】
更に、本発明によると、一つのメディアに一つのアプリケーションに関するソフトウェア、コンテンツ、ユーザデータの全てを自己完結した（self-contained）形で搭載できるので、他のアプリケーションとの相互調整、共通ライブラリとの関連など、ややこしく且つ複雑な事項を全く気にせず、シンプル且つ安定したアプリケーション環境をユーザに提供できる。また、一つのメディアに全ての情報が記録され、本体ハードウェア側には関連した一切のデータが残らないので、メディアと本体が完全に分離され、メディアだけを携帯して、いつでも、自分のコンピューティング環境が再現できる。自分の作業用ハードウェアを特定しておく必要がないハードウェアフリーな環境を提供する。
【０１００】
そして、本発明によると、情報処理装置の本体のハードウェアとは独立に、ＯＳやアプリケーションを自由に選択して、供給メディアを開発、販売できるので、ソフトウェア開発、コンテンツ開発の自由度が大きく、ハードウェアの汎用性も高まる。
【０１０１】
また、本発明によると、メディアを変えれば、異なるアプリケーションが可能で、その意味では、専用機のような簡単さを保持したまま、多目的（ｍultiple purpose ）な適用が可能なマシンを実現できる。例えば、ワープロソフトウェアを搭載したメディアを入れれば、本体はワープロ専用機となり、電子メールソフトウェアのメディアを入れれば、電子メール端末となる。教育ソフトウェアのメディアを入れれば教育機器となり、電子本ソフトウェアを入れれば電子書籍ビューアとなる。
【０１０２】
更に、本発明によると、メディアをインサートしないと、ハードウェアは稼動しないので、通常のパソコン等で問題になるインストールコピー（install copy）ができない仕組みになっており、ソフトウェア供給側にも不正コピーに悩まされずに済むというメリットがある。
そして、本発明によると、メディアのＲＯＭ部、または、予め供給側によって記録されている部分はコピーできないが、同じＲＯＭ部、または、予め記録されている部分を同じように搭載している別のメディアに対しては、ＲＡＭ部をコピーすることができ、結果として、著作権を侵害せずにメディアのコピーが実現できる。
【０１０３】
更に、本発明によると、ソフトウェアの使用回数をカウントできるので、これによって、ソフトウェア開発側が使用回数に応じた販売価格や課金方法を科していくことができる。
【図面の簡単な説明】
【図１】本発明の実施の形態を適用した情報処理装置の概略を説明する図である。
【図２】本発明の実施の形態を適用した小型の情報処理装置およびこの情報処理装置に用いられるリムーバブルディスクの外観を示す図である。
【図３】本発明の実施の形態を適用した情報処理装置およびリムーバブルディスクの概略的な構成を示すブロック図である。
【図４】いわゆるハイブリッドＭＤデータの基本フォーマット構造を示す図である。
【図５】各ソフトウェアのセグメント配置例を示す図である。
【図６】ブート領域の構成例を示す図である。
【図７】基本メディアアクセスプログラムＢＭＡＰの構成例を示す図である。
【図８】内蔵のフラッシュメモリ内のデータ配置構成例を示す図である。
【図９】ＵＷ領域の構成例を示す図である。
【図１０】本実施の形態の基本アーキテクチャの動作例を示すフローチャートである。
【図１１】システムローダプログラムの実行例を示すフローチャートである。
【図１２】ソフトウェアの階層を説明する図である。
【符号の説明】
１情報処理装置、２リムーバブルディスク、３表示画面、４キーボード、５マウス、９インターネット／ネットワーク

Claims

ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された着脱可能な記録媒体を用いる情報処理装置において、
上記記録媒体に対する情報の記録／再生を行う記録／再生手段と、
情報を記憶する記憶手段と、
電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、
プログラムを実行する制御手段とを有し、
上記制御手段は、上記記録媒体が挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムに基づいて、上記記録媒体のブート領域から上記ソフトウェアを読み込む読み込みプログラムと、上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とを読み込み、
上記読み込みプログラムに従って、上記読み込み制御情報のＩＤを参照して上記記録媒体からソフトウェアをセグメント毎に上記記憶手段に読み込んで実行し、
上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略し、
上記ソフトウェアが終了された場合上記基本アクセスプログラムにより当該ソフトウェアで発生した情報を上記記録媒体に書き込む情報処理装置。
上記記録媒体は、書き換え可能な記録媒体、又は一部が書き換え可能で他の部分が書き換え不可能な記録媒体である請求項１記載の情報処理装置。
上記制御手段は、上記ソフトウェアを終了する際に、上記記録媒体の書き換え可能領域に、エラー情報、利用回数、年月日の少なくとも一つを含む情報を記録する請求項１記載の情報処理装置。
上記制御手段は、上記情報処理装置に記録されたハードウェアＩＤを読み出して、上記情報処理装置と上記記録媒体との互換性を判断する請求項１記載の情報処理装置。
上記制御手段は、上記記録媒体から読み出すセグメントのＩＤと、上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤとを比較し、上記不揮発性メモリに記憶されたＩＤと異なるＩＤのセグメントを上記記録媒体から読み込む請求項１記載の情報処理装置。
上記読み込み制御情報は、上記記録媒体の管理情報を含み、
上記制御手段は、上記記録媒体の利用回数を上記管理情報に記録する請求項１記載の情報処理装置。
ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された着脱可能な記録媒体に対する情報の記録／再生を行う記録／再生手段と、情報を記憶する記憶手段と、電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、プログラムを実行する制御手段とを有する情報処理装置における情報処理方法において、
上記制御手段は、上記記録媒体が挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムに基づいて、上記記録媒体のブート領域から上記ソフトウェアを読み込む読み込みプログラムと、上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とを読み込み、
上記読み込みプログラムに従って、上記読み込み制御情報のＩＤを参照して上記記録媒体からソフトウェアをセグメント毎に上記記憶手段に読み込んで実行し、
上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略し、
上記ソフトウェアが終了された場合上記基本アクセスプログラムにより当該ソフトウェアで発生した情報を上記記録媒体に書き込む情報処理方法。
着脱可能な記録媒体に対する情報の記録／再生を行う記録／再生手段と、情報を記憶する記憶手段と、電源投入時に動作開始し、上記記録媒体のブート領域を読み込む基本アクセスプログラムが記憶された不揮発性メモリと、プログラムを実行する制御手段とを有する情報処理装置に用いられ、ソフトウェアと当該ソフトウェアを読み込む読み込みプログラムとが記録された記録媒体であって、
上記ソフトウェアを読み込む読み込みプログラムと上記ソフトウェアについて各セグメントに付与されたＩＤを含む読み込み制御情報とがブート領域に記録され、上記情報処理装置に挿入された場合上記不揮発性メモリに記憶された基本アクセスプログラムにより、上記読み込みプログラムと、上記読み込み制御情報とが読み込まれ、
上記読み込みプログラムは、上記読み込み制御情報のＩＤを参照して上記ソフトウェアをセグメント毎に上記記憶手段に読み込む処理を実行させ、
上記記録媒体からソフトウェアを読み込む際に、上記不揮発性メモリにセグメント毎に読み込んで上記記憶手段に移し、上記記録媒体から読み出すセグメントのＩＤが上記不揮発性メモリに記憶されたソフトウェアのセグメントのＩＤと一致すると、当該セグメントの読み込みは省略させる記録媒体。
エラー情報、利用回数、年月日の少なくとも一つを含む情報が記録される書き換え可能領域を有する請求項８記載の記録媒体。