JPH0991143A - データ処理方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 クライアントの構成を簡略化し、低コスト化
を可能にする。 【解決手段】 サーバ１とクライアント２−１，２−２
をネットワーク３を介して接続する。サーバ１には、ク
ライアント２−１，２−２が有する実行環境２２−１，
２２−２に対応する実行環境１２−１，１２−２を予め
用意するようにする。クライアント２−１，２−２のア
プリケーションプログラム２１−１，２１−２におい
て、所定のオブジェクト２４−１，２４−２が必要にな
ったとき、サーバ１のアプリケーションプログラム１１
−１，１１−２のオブジェクト１４−１，１４−２をダ
ウンロードする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はデータ処理方法およ
び装置に関し、特に構成を簡略化し、低コスト化するこ
とができるようにした、データ処理方法および装置に関
する。

【０００２】

【従来の技術】最近、パーソナルコンピュータが普及し
てきた。このパーソナルコンピュータでネットワークを
介して所定のサーバにアクセスし、所定の情報を得るこ
とができる。

【０００３】このようなパーソナルコンピュータにおい
て各種の処理を行うには、アプリケーションプログラム
が必要となる。そこで、各ユーザは、そのパーソナルコ
ンピュータのＯＳに合ったアプリケーションプログラム
を購入し、インストールして用いるようにしている。

【０００４】

【発明が解決しようとする課題】このように、ＯＳが異
なると、アプリケーションプログラムも異なるものとな
るため、各ユーザは、自分のＯＳに合ったアプリケーシ
ョンプログラムを選択して購入する必要がある。また、
アプリケーションプログラムを提供する側（アプリケー
ションプログラムを設計する側）においても、実質的に
同一の処理を行うアプリケーションプログラムを複数
（ＯＳの数だけ）設計し、用意しなければならず、多く
の労力が必要になると同時に、コスト高となる課題があ
った。

【０００５】また、同様のことが、同一のＯＳにおける
各アプリケーションプログラムにおいても発生してい
た。すなわち、１つのアプリケーションプログラムと、
それとは異なる他のアプリケーションプログラムとが、
同一のＯＳ上において動作するものであったとしても、
２つのアプリケーションプログラムはそれぞれ別個に設
計しなければならず、結果的に、１つのアプリケーショ
ンプログラムを提供するのに必要な労力とコストが高く
なる課題があった。

【０００６】本発明はこのような状況に鑑みてなされた
ものであり、１つのアプリケーションプログラムを、簡
単かつ低コストで提供できるようにするものである。

【０００７】

【課題を解決するための手段】請求項１に記載のデータ
処理方法は、サーバが、クライアントにアプリケーショ
ンプログラムをダウンロードするとき、クライアント
が、ダウンロードするアプリケーションプログラムの実
行環境を有するか否かを検査し、その検査結果に対応し
てアプリケーションプログラムをクライアントにダウン
ロードすることを特徴とする。

【０００８】請求項９に記載のデータ処理装置は、クラ
イアントにアプリケーションプログラムをダウンロード
するとき、クライアントが、ダウンロードするアプリケ
ーションプログラムの実行環境を有するか否かを検査す
る検査手段と、検査手段の検査結果に対応してアプリケ
ーションプログラムをクライアントにダウンロードする
ダウンロード手段とを備えることを特徴とする。

【０００９】請求項１０に記載のデータ処理装置は、サ
ーバからアプリケーションプログラムをダウンロードす
るとき、ダウンロードするアプリケーションプログラム
の実行環境に関する告知を行う告知手段と、告知手段の
告知に対応してサーバからアプリケーションプログラム
をダウンロードするダウンロード手段とを備えることを
特徴とする。

【００１０】請求項１１に記載のデータ処理装置は、中
間コードに変換されたアプリケーションプログラムを解
釈し、実行する第１の実行手段と、中間コードを動的に
コンパイルし、バイナリコードを生成するバイナリコー
ド生成手段と、バイナリコードおよびシステムオブジェ
クトを実行する第２の実行手段とを備えることを特徴と
する。

【００１１】請求項１５に記載のデータ処理方法は、中
間コードに変換されたアプリケーションプログラムを解
釈し、実行する第１の方法と、中間コードを動的にコン
パイルし、生成されたバイナリコードを実行する第２の
方法とにより、アプリケーションプログラムを実行する
ことを特徴とする。

【００１２】請求項１に記載のデータ処理方法において
は、クライアントにアプリケーションプログラムをダウ
ンロードするとき、クライアントが、ダウンロードする
アプリケーションプログラムの実行環境を有するか否か
をクライアントとサーバ間で検査し、その検査結果に対
応してアプリケーションプログラムをクライアントにダ
ウンロードする。

【００１３】請求項９に記載のデータ処理装置において
は、検査手段が、クライアントにアプリケーションプロ
グラムをダウンロードするとき、クライアントが、ダウ
ンロードするアプリケーションプログラムの実行環境を
有するか否かを検査し、ダウンロード手段が、検査手段
の検査結果に対応してアプリケーションプログラムをク
ライアントにダウンロードする。

【００１４】請求項１０に記載のデータ処理装置におい
ては、告知手段が、サーバからアプリケーションプログ
ラムをダウンロードするとき、ダウンロードするアプリ
ケーションプログラムの実行環境に関する告知を行い、
ダウンロード手段が、告知手段の告知に対応してサーバ
からアプリケーションプログラムをダウンロードする。

【００１５】請求項１１に記載のデータ処理装置におい
ては、第１の実行手段が、中間コードに変換されたプロ
グラムを解釈し、実行し、バイナリコード生成手段が、
中間コードを動的にコンパイルし、バイナリコードを生
成し、第２の実行手段が、バイナリコードを実行する。
例えば、動的コンパイルが困難な場合、中間コードを逐
次解釈し、実行することができる。

【００１６】請求項１５に記載のデータ処理方法におい
ては、中間コードに変換されたプログラムを解釈し、実
行する第１の方法と、中間コードを動的にコンパイル
し、生成されたバイナリコードを実行する第２の方法と
により、アプリケーションプログラムを実行する。例え
ば、動的コンパイルが困難な場合、中間コードを逐次解
釈し、実行することができる。

【００１７】

【発明の実施の形態】本発明のデータ処理方法を適用す
るシステム構成例を図１に示す。システムはサーバ１
（データ処理装置）、クライアント２（データ処理装
置）、ネットワーク３から構成されている。

【００１８】すなわち、この実施例においては、サーバ
１は２つのアプリケーションプログラムを有し、一方の
アプリケーションプログラム１１−１は、それを実行す
る環境を規定する実行環境１２−１と、アプリケーショ
ンプログラム１１−１と実行環境１２−１との間のイン
タフェースを構成するアプリケーションプログラムイン
タフェース（ＡＰＩ）１３−１を有している。

【００１９】アプリケーションプログラム１１−１は、
複数のオブジェクト１４−１により構成され、また、実
行環境１２−１も、複数のオブジェクト１５−１により
構成されている。

【００２０】同様に、アプリケーションプログラム１１
−２は、その環境を規定する実行環境１２−２と、アプ
リケーションプログラム１１−２と実行環境１２−２と
の間のインタフェースとして機能するＡＰＩ１３−２を
有している。

【００２１】このアプリケーションプログラム１１−２
も、複数のオブジェクト１４−２により構成され、ま
た、実行環境１２−２も複数のオブジェクト１５−２に
より構成されている。

【００２２】同様に、クライアント２も２つのアプリケ
ーションプログラムを有し、一方のアプリケーションプ
ログラム２１−１は、その環境を規定する実行環境２２
−１と、アプリケーションプログラム２１−１と実行環
境２２−１との間のインタフェースであるＡＰＩ２３−
１を有している。アプリケーションプログラム２１−１
と実行環境２２−１は、それぞれ複数のオブジェクト２
４−１と２５−１により構成されている。

【００２３】同様に、アプリケーションプログラム２１
−２も、その環境を規定する実行環境２２−２とＡＰＩ
２３−２とを有し、アプリケーションプログラム２１−
２と実行環境２２−２は、それぞれ複数のオブジェクト
２４−２と２５−２により構成されている。

【００２４】ここで、各オブジェクトはすべて、他のオ
ブジェクトと並行して処理を実行する並行オブジェクト
として定義されている。１つのＡＰＩの集合は１つの実
行環境によって与えられるので、サーバ１、クライアン
ト２中には、複数のＡＰＩが存在することになる。

【００２５】図１に示すように、また図２に拡大して示
すように、アプリケーションプログラム１１を複数のオ
ブジェクト１４の集まりで構成する。また、オブジェク
ト１４を並行オブジェクトとして構成することにより、
アプリケーションプログラム１１は並行処理されること
になり、実行速度の向上に貢献する。また、オブジェク
ト１４は置き換えの単位でもあるので、動作にバグのあ
るオブジェクト、性能上問題のあるオブジェクトなど
を、誤りのないオブジェクトで置き換えることによっ
て、アプリケーションプログラム１１全体を作り替える
ことなく、問題点を解決できる。さらに、オブジェクト
１４を部品とし、既存のアプリケーションプログラムの
部品としてのオブジェクトを組み合わせることによっ
て、簡単に新しいアプリケーションプログラムを作るこ
とができる。

【００２６】ここで、アプリケーションプログラムと
は、１つのサービス単位である。例えば、サーバ１から
の映像データを単に表示しているアプリケーションプロ
グラム、ＶＣＲ機能を用いて映像データを検索している
アプリケーションプログラム、メニューによってサービ
スを選択しているアプリケーションプログラム、ホーム
ショッピングのアプリケーションプログラム、ホームシ
ョッピングと連結した家計簿アプリケーションプログラ
ム、税金計算アプリケーションプログラム等である。

【００２７】アプリケーションプログラム間でオブジェ
クトを共有することによって、操作性に共通点を持たせ
ることができる。例えば、家計簿でデータを入力してい
るエディタと、ホームショッピングでのデータ入力エデ
ィタを共通化することができる。

【００２８】次に並行オブジェクト（ｃｏｎｃｕｒｒｅ
ｎｔ ｏｂｊｅｃｔ）について説明する。並行オブジェ
クトの構成を図３に示す。並行オブジェクトであるオブ
ジェクト１４は、外部に公開されたメソッドエントリの
テーブル１４Ａ、メソッドの本体１４Ｂ、オブジェクト
の状態を保持するメモリ領域１４Ｃ、メソッドを実行す
る単一のスレッド１４Ｄを有している。並行オブジェク
トには１つの実行コンテキスト（スレッドと呼んでも良
い）のみが存在する。従って並行オブジェクトは、１つ
のメッセージを受信して、その処理中には、新たに到着
したメッセージの処理は、現在の実行が終了するまで行
わない。

【００２９】このように、オブジェクト内にスレッドを
１個だけ配置するようにすると、次の利点が得られる。

【００３０】（１）複数のアクティビティ間の同期を気
にする必要がない。すなわち、共有データが存在する場
合に、セマフォア等の同期のための命令を用いて、共有
データに対するアクセスを順序付けるといったことを行
う必要がなくなる。換言すれば、オブジェクトへのメッ
セージ送信が、その順序付けを含んでいることになる。

【００３１】（２）そのため、同期の取り方のミスによ
るプログラム誤りが生じなくなると同時に、そのオブジ
ェクトの再利用可能性が高まる。

【００３２】（３）例えばデバイスドライバを本方式で
作成することによって、多くの場合に生じる、同期誤り
を防ぐことができる。

【００３３】（４）また、デバイスドライバの置き換え
による同期誤りを防ぐことができるので、安全にデバイ
スドライバを置き換えることができる。

【００３４】（５）デバイスドライバの、実際にハード
ウェアを制御する部分以外の部分を、ＯＳと独立に作成
することができる。これによって、従来から開発のかな
りの時間を占めていたデバイスドライバを、共通に開発
することが可能になるので、開発期間の短縮につなが
る。

【００３５】（６）オブジェクト間の実行制御に関する
記述をアプリケーションプログラムの記述から除くこと
ができる。例えば、マルチスレッドを用いた手法では
（複数のスレッドを用いる場合には）、スレッドの実行
制御をアプリケーションプログラム中にプログラムする
必要があるために、スレッドのプログラミング環境が変
更になると、アプリケーションプログラムを書き換える
必要がある。しかしながら、スレッドが１個の場合に
は、アプリケーションプログラムにこの部分を記述する
必要がないので、実行制御方法が変わってもアプリケー
ションプログラムを書き直す必要がない。並行オブジェ
クトのその実行環境への最適な実行制御方法は、システ
ムが、後述するオブジェクトの動的拡張の原理を用いて
提供する。

【００３６】（７）従って、アプリケーションプログラ
ムを記述する場合には、並列処理を考える必要がない。
並行オブジェクトが並列処理の単位であるので、並行オ
ブジェクトをプログラムしていけば、後はシステムが自
動的にそのハードウェアに最適な実行制御を行って並列
処理が行われる。従来の手法では、いくつプロセスを生
成するか、いくつスレッドを生成するか、といったこと
をプログラミング時に指定しなければならず、この指定
は、ハードウェアの性能を考慮しないと、そのアプリケ
ーションプログラムは特定のハードウェア専用のものに
なってしまうが、本方式によれば、そのようなことはな
い。

【００３７】本システムにおいては、オブジェクトは必
要に応じてダウンロードされる。複数ベンダのクライア
ント２に対してサーバ１からオブジェクトをダウンロー
ドする場合のシステム例を図４に示す。サーバ１上に
は、それぞれのベンダ用のクライアントＡＰＩ１３（１
３−１，１３−２）が、実行環境１２（１２−１，１２
−２）によって実現されている。

【００３８】オブジェクトをクライアント２（２−１，
２−２）にダウンロードするとき、クライアント２上
に、サーバ１上の実行環境１２と同じ実行環境２２（２
２−１，２２−２）が存在するか否かを調べ、存在する
場合には、オブジェクトをダウンロードする。存在しな
い場合には、クライアント２上にサーバ１上の実行環境
と同一の実行環境を構築した後、ダウンロードする。

【００３９】例えば、図４において、サーバ１のアプリ
ケーションプログラム１１−１のオブジェクト１４−１
を、クライアント２−１のアプリケーションプログラム
２１−１のオブジェクト２４−１としてダウンロードす
る場合、クライアント２−１の実行環境２２−１に、サ
ーバ１の実行環境１２−１のオブジェクト１５−１Ａに
対応するオブジェクト２５−１Ａが必要であるとき、例
えば、実行環境１２−１のオブジェクト１５−１Ｂ（検
査手段）は、実行環境２２−１のオブジェクト２５−１
Ｂ（告知手段）にフィーチャストラクチャ（後述する）
を問い合わせる。そして、その回答に対応して、実行環
境１２−１のオブジェクト１５−１Ｃ（ダウンロード手
段）と実行環境２２−１のオブジェクト２５−１Ｃ（ダ
ウンロード手段）は、実行環境１２−１のオブジェクト
１５−１Ａと１５−１Ｂを、実行環境２２−１のオブジ
ェクト２５−１Ａと２５−１Ｂとしてダウンロードさせ
る。

【００４０】従来の手法では、ダウンロードするオブジ
ェクトは、クライアントのＡＰＩに合わせて作成する必
要があった。例えば、クライアントがＵＮＩＸシステム
の場合には、サーバ上では同じＵＮＩＸシステムを用い
るか、あるいは何らかのクロス開発環境を構築してオブ
ジェクトを作成する必要がある。もし、サーバとクライ
アントが同じ実行環境を備えなければいけない場合に
は、クライアント装置は一般に高価な計算資源を備える
必要がある。例えば、専用の実行環境を備える場合と比
べて、より多くのメモリを備える必要がある。また、十
分な実行速度を保証するために、高速のＣＰＵ（Centra
l Processing Unit）を備える必要がある。これは、装
置のコスト増につながる。

【００４１】これに対して、本システムでは、アプリケ
ーションのダウンロードと同時に、その実行環境をもダ
ウンロードすることで、この問題を解決する。すなわ
ち、クライアント２で現在必要とする実行環境２２のみ
をクライアント２に構築することによって、不必要な資
源をクライアント２に用意しなくてもすむようになる。
例えば、クライアント２が３Ｄのグラフィックスを必要
としない場合には、そのライブラリは必要なくなる。

【００４２】また、クライアント２がＶＯＤ（Ｖｉｄｅ
ｏ Ｏｎ Ｄｅｍａｎｄ）で映画を見ている場合には、
ユーザとのインタラクションのためのサービス（映画を
見るときは不要となるサービス）をクライアントから一
時削除することによって、その分の計算資源を他の仕事
に割り振ることができる。例えば、その資源を、サーバ
１からの映像データのプリフェッチ用のバッファに使う
ことができる。インタラクションのためのサービスは、
それが必要になった時点でサーバ１からダウンロードさ
れる。

【００４３】本システムでダウンロードされるオブジェ
クトとしては次のものが考えられる。

【００４４】（１）すべてのアプリケーションプログラ
ム

【００４５】（２）クライアントが備えるハードウェア
資源を制御するためのデバイスドライバ群（例えば、Ｍ
ＰＥＧドライバ、ＡＴＭドライバ、画像制御ドライバ
等）

【００４６】（３）アプリケーションプログラムに対し
てシステムサービスを提供するオブジェクト群（例え
ば、ＶＣＲコマンド管理、ストリーム管理、実時間スケ
ジューラ、メモリ管理、ウィンドウ管理、ダウンロード
制御、通信プロトコル管理、実行管理等）

【００４７】これらを組み合わせて、アプリケーション
プログラムに対して最適な実行環境をクライアント上に
構築する。

【００４８】サーバ１は、映像データやアプリケーショ
ンプログラムを送出する装置であったり、クライアント
２にネットワーク３を通して情報を送出する装置であ
る。一方クライアント２は、サーバ１からの情報を処理
する装置であり、常にネットワーク３と接続されている
必要はない。実行環境はアプリケーションプログラム毎
に与えることができるので、アプリケーションプログラ
ム毎に最適な実行環境を用意することができる。

【００４９】従来の手法では、システム構築時にアプリ
ケーションの特性をあらかじめ見積もっておく必要があ
った。例えば、アプリケーションプログラムが映像デー
タを扱う必要があるときには、そのためのシステムサー
ビス、例えば、実時間スケジューリングや映像データを
扱うためのＶＣＲのようなユーザインタフェースを備え
ている必要がある。また、アプリケーションが３Ｄグラ
フィックスを用いているならば、そのためのライブラリ
を備えている必要がある。そのため、システムは肥大に
なる傾向があった。ＵＮＩＸやＷｉｎｄｏｗｓ（商標）
がこの典型例であり、バージョンがあがるごとにシステ
ムが必要とするメモリ量は多くなっていった。本システ
ムでは、アプリケーションの実行のために必要最小限の
機能のみを備えていればよく、従来システムのこの問題
点を解決する。

【００５０】アプリケーションプログラム１１を複数の
オブジェクトの集まりとして構成することにより、ま
た、そのオブジェクトを並行オブジェクトとして実装す
ることにより、オブジェクト単位で並行実行が可能にな
り、アプリケーションプログラムの実行と同時にオブジ
ェクトをダウンロードすることができる。この時、図５
に示すように、アプリケーションプログラムの実行に必
要なオブジェクトをインクリメンタルにダウンロードす
ることにより、ユーザからは、単一のアプリケーション
プログラムのロードにかかる時間を隠すことができる。

【００５１】例えば、図５に示すように、サーバ１のア
プリケーションプログラム１１のオブジェクト１４−１
−１乃至１４−１−１１を、クライアント２のアプリケ
ーションプログラム２１のオブジェクト２４−１−１乃
至２４−１−１１としてダウンロードする必要がある場
合、ランダムに各オブジェクトをダウンロードするので
はなく、アプリケーションプログラム２１を実行する上
において、最初に必要なオブジェクト１４−１−１乃至
１４−１−３を、オブジェクト２４−１−１乃至２４−
１−３として先にダウンロードする。

【００５２】アプリケーションプログラム２１は、さし
あたって、この３つのオブジェクトが存在すれば、起動
可能であるため、その処理を開始する。そして、その処
理が実行されている間に、残りのオブジェクト１４−１
−４乃至１４−１−１１をアプリケーションプログラム
２１のオブジェクト２４−１−４乃至２４−１−１１と
して、第２乃至第４のダウンロードで順次ダウンロード
する。この第２乃至第４のダウンロードにおいても、処
理上、先に必要となるオブジェクトから順番にダウンロ
ードする。

【００５３】ユーザは、アプリケーションプログラム２
１がオブジェクト２４−１−１乃至２４−１−３がダウ
ンロードされ、その処理が開始された時点において、既
にアプリケーションプログラム２１の処理が開始されて
いるため、あたかもすべてのオブジェクトのダウンロー
ドが完了したものと認識することができる。すなわち、
ユーザは、１１個のオブジェクトをダウンロードするの
に必要な時間より短い、３個のオブジェクトをダウンロ
ードするのに必要な時間だけを意識することになる。換
言すれば、ユーザに対して、８個のオブジェクトをダウ
ンロードするための時間を実質的に隠す（意識させない
ようにする）ことができる。

【００５４】このことは、図４を参照して説明した（ま
た、図１０を参照して後述する）実行環境２２の構築を
クライアント２上に行う場合にも当てはまる。この場合
は、実行環境２２を構成するオブジェクトのうち、アプ
リケーションプログラムの実行に必要な部分のみのオブ
ジェクトを先にダウンロードすることによって、実行環
境のすべてのオブジェクトをダウンロードする時間をユ
ーザから隠すことができる。この手法は、システムのブ
ートにも応用できる。

【００５５】ここで、インクリメンタルダウンロードと
は、アプリケーションプログラムや実行環境を一度にダ
ウンロードしないで、それを構成するオブジェクト単
位、あるいは、その一部を必要に応じてダウンロードす
ることを意味する。従来のパソコン通信におけるアプリ
ケーションプログラムのダウンロードの場合には、圧縮
されたアプリケーションプログラムを一気にダウンロー
ドするので、ダウンロードがすべて終わらないと、その
アプリケーションプログラムは利用することができな
い。また、例えば、今までのシステムのブートでは、シ
ステム全体を全部メモリに読み込んでから立ち上がる。
ＵＮＩＸのディスクレスワークステーションの場合に
は、サーバからすべてのＯＳをメモリに読み込んでから
システムが起動するので、読み込みがすべて終了するま
で、システムを利用できない。しかしながらインクリメ
ンタルダウンロードすれば、そのようなことがなくな
る。

【００５６】この手法は、サーバ１とクライアント２と
してのＳＴＢ（Ｓｅｔ Ｔｏｐ Ｂｏｘ）に応用して次
のような効果がある。まず、ＳＴＢの電源を入れるとす
ぐに利用できるようになる。現在のパーソナルコンピュ
ータのように、システムが立ち上がるまでいらいらして
待つ必要が無くなる。ＳＴＢは家庭用電気製品としての
性格が強いので、システムが立ち上がるまでユーザを待
たせるのは好ましくない。

【００５７】ＳＴＢの電源が入れられると、ＳＴＢは最
初に必要なオブジェクトをダウンロードして実行を始め
ようとする。ユーザの待ち時間は最初のこのオブジェク
トのダウンロード時間のみである。典型的なオブジェク
トのダウンロード時間は数ミリ秒から数十ミリ秒である
ので、適当なユーザインタフェースを備えることによ
り、この時間は十分ユーザにとって無視できる時間とな
る。以降は、システムの立ち上げプロセスの進行に従っ
て、必要なオブジェクトがシステムの立ち上げプロセス
と並行にダウンロードされる。

【００５８】また、ＳＴＢは、そのコストの観点から、
サーバのような豊富な計算資源が用意されていないの
で、複数のアプリケーションを同時に実行する場合にも
制約が生じる。例えば、ナビゲーションアプリケーショ
ンによって、ＶＯＤサービスを選択して、１つの映画を
鑑賞することを考えた場合、映画の鑑賞が始まったら、
ナビゲーションアプリケーションが占有していた資源
（メモリ）を解放して、映画鑑賞アプリケーションのた
めに使うことができる。そして、再び、ナビゲーション
アプリケーションが必要になった時点で、その資源（メ
モリを管理するオブジェクト）をダウンロードする。

【００５９】ここで、「必要になった時点」とは、オブ
ジェクトに対して何らかのメッセージが送られた時点と
する。すなわち、一番最初にダウンロードしたオブジェ
クトが、別のオブジェクトにメッセージを送った時点
で、その受信オブジェクトをダウンロードする。オブジ
ェクトの依存、参照関係を利用することによって、次の
メッセージを送るオブジェクトをあらかじめダウンロー
ドしておくことができる。これを、アプリケーションの
実行と並行に行うことにより、メッセージ通信時におけ
るダウンロードによる遅延を少なくすることができる。
これにより、インクリメンタルダウンローディングの有
効性を高めることができる。

【００６０】また、実行環境１２，２２もオブジェクト
１５，２５の集合体であり、アプリケーションプログラ
ム１１，２１のオブジェクト１４，２４と同等に操作可
能であるので、アプリケーションプログラム１１，２１
に特化したダウンロードの順序を制御するメタオブジェ
クトをオブジェクト１５，２５の１つとして用意する
（例えば図４のオブジェクト２５−１Ｃをメタオブジェ
クトとする）ことができる。これによって、特定のアプ
リケーションに適した、そのオブジェクトが利用するオ
ブジェクトのダウンロード順を指定することができ、イ
ンクリメンタルダウンローディングによるユーザの待ち
時間を最小にすることができる。

【００６１】サーバ１からクライアント２へのオブジェ
クトのダウンロードの機能、それに伴うオブジェクトの
実行環境の互換性の検査機能、および実行環境の構築機
能は、本システムを実現する上で重要なものであり、本
システムを構成するすべての装置（クライアント２）が
最低限有すべき機能とする。本明細書ではこの機能をメ
タ標準と呼ぶ。このメタ標準により、ＯＳ等の実行環境
のＡＰＩは自由に拡張することができるようになり、最
小限の標準化とその拡張によって、今後のあらゆるタイ
プのアプリケーションに対応することができるようにな
る。

【００６２】例えば、図６に示すシステムでは、各サー
バ１−１，１−２、各クライアント２−１，２−２で
は、独自のＡＰＩを持ったＯＳが稼働している。すなわ
ちクライアント２−１においては、実行環境２２−１に
対応して、アプリケーションプログラム２１−１のため
のＡＰＩ２３−１（ＡＰＩ＃１）が構成されている。ま
た、クライアント２−２においては、実行環境２２−２
によりアプリケーションプログラム２１−２のためのＡ
ＰＩ２３−２（ＡＰＩ＃３）が形成されている。

【００６３】このため、これらのクライアント２−１，
２−２に対してプログラムをダウンロードするサーバに
は、これらのＡＰＩに対応するＡＰＩが予め用意されて
いる。この実施例においては、サーバ１−１において、
実行環境１２−１によりアプリケーションプログラム１
１−１のためのＡＰＩ１３−１が形成されており、この
ＡＰＩ１３−１は、クライアント２−１におけるＡＰＩ
２３−１（ＡＰＩ＃１）に対応するＡＰＩ（ＡＰＩ＃
１）とされている。

【００６４】同様にサーバ１−２において、実行環境１
２−３によりアプリケーションプログラム１１−３に対
応するＡＰＩ１３−３（ＡＰＩ＃３）が形成されてお
り、このＡＰＩ１３−３がクライアント２−２のＡＰＩ
２３−２（ＡＰＩ＃３）に対応している。

【００６５】従って、サーバ１−１，１−２と、クライ
アント２−１，２−２に、このメタ標準に対応するオブ
ジェクトとして、オブジェクト１５−１Ａ乃至１５−１
Ｃ，１５−３Ａ乃至１５−３Ｃ，２５−１Ａ乃至２５−
１Ｃおよび２５−２Ａ乃至２５−２Ｃを設けている。そ
の結果、クライアント２−１または２−２に対しては、
サーバ１−１または１−２から、メタ標準プロトコルに
従って必要なオブジェクトを適宜ダウンロードさせるこ
とができる。

【００６６】各クライアントにおけるＯＳを１つのＯＳ
に標準化しようとするのがこれまでのこの分野における
傾向であった。しかしながら、このようなメタ標準を規
定し、サーバ側においてのみ、各クライアントのＡＰＩ
に対応するＡＰＩを具備させることで、標準を決定する
必要がなくなる。

【００６７】ＯＳの標準を１つに規定していないことに
よって、アプリケーションを始め、システムサービスを
実現しているオブジェクトは、ＯＳとは独立に構成する
ことが可能になる。すなわち、ある実行環境用に書かれ
たソフトウェアを、マイグレーションによって別の実行
環境用に自動的に再構成すればよいことになる。従来の
システムには、この機能は存在しない。例えば、ＵＮＩ
Ｘ用に書かれたソフトウェアはＷｉｎｄｏｗｓ上では、
書き直さないと動作しない。アプリケーションレベルの
ソフトウェアで、この機能を実現するには、ＯＳ依存性
を吸収するソフトウェアを導入する必要がある。しか
し、デバイスドライバを始めとする、システムサービス
を実現するオブジェクトのＯＳの独立性は、本手法を用
いて可能になる。

【００６８】このように、オブジェクトをダウンロード
するようにすると、クライアント２のオブジェクトは、
図７に示すように、動的に変更することができる。すな
わち、既存のオブジェクトをクライアントから削除し
て、新しいオブジェクトをサーバからダウンロードす
る。

【００６９】例えば、図７の実施例においては、クライ
アント２のアプリケーションプログラム２１におけるオ
ブジェクト２４Ａが不要となったので、これを削除して
いる。そして新たに必要になったオブジェクト１４Ａを
サーバ１からクライアント２に対してダウンロードす
る。

【００７０】これにより、次のことが可能になる。

【００７１】（１）ソフトウェアをアップデートするこ
とができる。例えば、ハードウェア制御ソフトにバグが
見つかった場合に、そのオブジェクトを削除して、新し
いオブジェクトに置き換える。家庭電化製品は、コンピ
ュータの専門家ではない、一般消費者が利用するものな
ので、一部のコンピュータに見られるようなインストー
ラによるソフトウェアのアップデートは適切ではない。

【００７２】（２）製品のサイクルを長くすることがで
きる。例えば、テレビジョン受像機は毎年のようにモデ
ルチェンジが繰り返されるが、一般消費者は、テレビジ
ョン受像機を毎年買い換るようなことはしない。しか
し、本システムにより、ソフトウェアの問題はすべて最
新の機能をユーザに提供できることになるので、ソフト
ウェアの機能拡張によるモデルチェンジをなくすことが
できる。これは、ＳＴＢの場合にも当てはまる。

【００７３】（３）ユーザインタフェースの好みの変化
に対応できる。例えば、初めてその装置を使い始めたユ
ーザには、親切なメニュー形式を提供するが、ユーザが
その装置の使い方を習熟するにつれて、直接所望の操作
ができるようなダイレクト操作のユーザインタフェース
に変更することができる。この場合も、両方の手順をク
ライアント側に持たせるのではなく、そのときのユーザ
の熟練度に応じたユーザインタフェースをクライアント
側に持たせることができる。これにより、限りあるクラ
イアントの資源を有効に利用することができる。

【００７４】また、オブジェクトをダウンロードすれ
ば、図８に示すようにクライアント２のオブジェクトを
動的に拡張することができる。図８の実施例において
は、クライアント２におけるアプリケーションプログラ
ム２１−１のオブジェクト２４−１Ｂに対して新たなサ
ービスを受けられるようにするために、実行環境２２−
２が生成されている。そして実行環境２２−１から必要
なオブジェクト２５−１Ａ，２５−１Ｂが実行環境２２
−２にオブジェクト２５−２Ａ，２５−２Ｂとなるよう
に、マイグレート（移転）する。さらに必要なその他の
オブジェクト２５−１Ｃ，２５−１Ｄも実行環境２２−
２にマイグレートされる。

【００７５】そしてアプリケーションプログラム２１−
２には、アプリケーションプログラム２１−１のオブジ
ェクト２４−１Ｂが、オブジェクト２４−２Ｂとなるよ
うにマイグレートされる。

【００７６】このようにして、例えば、実時間スケジュ
ーリングの拡張が必要になった場合には、その為の新し
い実行環境をクライアントに生成し、必要なオブジェク
トをその新しい環境に移動する。オブジェクトには何も
変更を加える必要がなく、オブジェクトは実時間スケジ
ューリングのサービスを受けられるようになる。

【００７７】これにより次の効果が得られる。

【００７８】（１）アプリケーションプログラムのオブ
ジェクトに変更を加えないで、新しい機能に対処するこ
とが可能になるので、アプリケーションプログラムの寿
命が長くなり、再利用可能性が増す。従来の手法では、
アプリケーションプログラムにその実行環境に対する依
存コードが含まれていたために、実行環境が変わること
は、アプリケーションプログラムの書き換えを意味して
いた。

【００７９】（２）組み込み機器のアプリケーションプ
ログラムの場合には、ユーザインタフェースをはじめと
する機器の高機能制御ソフトの部分は、モデルが大きく
変わらない限り再利用したい部分であり、また、既存の
コードを利用して機能拡張するのみで開発期間を短縮し
たい部分であるが、この部分に、実行環境への依存コー
ドが含まれていると、再利用のための作業は複雑にな
る。今までの手法は、この部分に対して何の戦略もなか
ったが、本方式によって、この作業は自動化、あるい
は、最小化できる。

【００８０】本システムは、具体的には次のように応用
できる。

【００８１】（１）アプリケーションの信頼性が低い場
合に、メモリ保護機能をダウンロードすることによって
システム全体の停止を防ぐことができる。

【００８２】（２）ＳＴＢのベンダ毎に、サービスプロ
バイダは提供サービスを変えることができる。例えば、
映画会社Ａの映画を提供するサービスプロバイダは、そ
の映画を受信するＢ社のＳＴＢとＣ社のＳＴＢとで、画
像の質を変えることができる。

【００８３】（３）ＳＴＢに送られてくるＡ／Ｖデータ
の圧縮方式やユーザの画質の好みに応じて、システムの
処理方式を変更する。例えば、ＭＰＥＧデータの場合と
ＪＰＥＧデータでは画質を調整するときの仕方が異なる
ので、システムの処理方式を変更する必要があるが、本
システムでは、データ形式に従って動的に処理方式を選
択できる。

【００８４】このように、システムのほとんどの機能は
サーバ１からダウンロードすることができるので、あら
かじめクライアント２に様々の機能を持たせる必要が無
く、最小限の機能を持たせればよい。図９に本システム
におけるクライアント２が有する最小限の機能を示す。
すなわち、クライアント２には、デバイスドライバのた
めの実行環境２２−１、システムオブジェクトのための
実行環境２２−２、実行環境の為の実行環境２２−３
を、最低限形成する。

【００８５】あらかじめ存在させる必要のあるデバイス
ドライバは、入力を処理するｉｎｐｕｔ ｄｒｉｖｅ
ｒ、時間を管理するｔｉｍｅｒ ｄｒｉｖｅｒ、表示を
制御するｓｃｒｅｅｎ ｄｒｉｖｅｒの各オブジェクト
２４−１Ａ，２４−１Ｂ，２４−１Ｃであり、システム
オブジェクトは、入力を管理するｉｎｐｕｔ ｈａｎｄ
ｌｅｒ、起動を管理するｂｏｏｔ ｐｒｏｔｏｃｏｌ、
記憶を管理するｍｅｍｏｒｙ ｍａｎａｇｅｒの各オブ
ジェクト２４−２Ａ，２４−２Ｂ，２４−２Ｃである。
より高機能のデバイスドライバ、システムオブジェクト
はサーバ１からダウンロードされる。

【００８６】図１０は、サーバの送り出すアプリケーシ
ョンプログラム（ビデオ、ゲーム、ショッピング等）に
適したクライアント環境を動的に構成する実施例を表し
ている。図１０では、ショッピングのアプリケーション
プログラム１１−２をサーバ１からダウンロードするた
めに、ショッピング用の実行環境２２−４がクライアン
ト２−２に構成されている。また、ショッピングアプリ
ケーションプログラムから映画アプリケーションプログ
ラムに、クライアント２−２がアプリケーションプログ
ラムを切り替えた場合には、映画アプリケーションプロ
グラム２１−３の実行環境２２−３がクライアント２−
２に構成され、サーバ１から映画アプリケーションプロ
グラム１１−１がダウンロードされる。

【００８７】例えば、次のような処理が考えられる。

【００８８】（１）ユーザが映画を選択しているとき この時には、所望の映画を選択することができるよう
に、ナビゲーションアプリケーション１１−３が、例え
ばクライアント２−１の実行環境２２−１にダウンロー
ドされ、それに対する必要な環境として、ウィンドウ管
理、ユーザからの入力管理等のオブジェクト１５−３が
オブジェクト２５−１としてダウンロードされる。

【００８９】（２）ユーザが映画を鑑賞しているとき この時には、サーバ１−１の実行処理１２−１から、ビ
デオストリーム管理、データ先読みバッファ管理、ＶＣ
Ｒ機能等のオブジェクト１５−１が、例えばクライアン
ト２−２の実行環境２２−３にオブジェクト２５−３と
してダウンロードされる。

【００９０】以上のように、クライアントの実行環境を
ダウンロードにより実現するために、本システムでは図
１１に示すフィーチャストラクチャ（ｆｅａｔｕｒｅ
ｓｔｒｕｃｔｕｒｅ）を導入する。オブジェクトがサー
バ１からクライアント２にダウンロードされる時、この
ｆｅａｔｕｒｅ ｓｔｒｕｃｔｕｒｅが検査されて、必
要な実行環境がダウンロード先に構成される。

【００９１】すなわち、サーバ１は、クライアント２と
の間において、第１のフェーズ（ネゴシエーションフェ
ーズ）で、サーバ１側のメタオブジェクト空間とクライ
アント２側のメタオブジェクト空間との間におけるオブ
ジェクトマイグレーションの可能性に関するネゴシエー
ションを行う。そして第２のフェーズ（移動フェーズ）
において、実際にオブジェクトの転送を行う。

【００９２】オブジェクトマイグレーションはメタレベ
ルのプロセスであり、オブジェクトの内部情報と、必要
ならばそれに関連したオブジェクトによって使用中の計
算資源を転送するものである。オブジェクトの内部情報
は、ディスクリプタ（ｄｅｓｃｒｉｐｔｏｒ）と呼ばれ
るメタレベルオブジェクトによって表現されている。デ
ィスクリプタは、実際には、オブジェクトを管理してい
るメタオブジェクトの名前を保持している。一般的なデ
ィスクリプタは、オブジェクトのメモリセグメントを管
理しているメタオブジェクトの名前、２つ以上のオブジ
ェクトの実行制御をしているメタオブジェクト（スケジ
ューラ）の名前、オブジェクトの名前付けを管理してい
るメタオブジェクトの名前、等を保持している。

【００９３】第１のフェーズ（ネゴシエーションフェー
ズ）においては、オブジェクトの移動の可能性が検査さ
れる。すなわち、メタオブジェクト空間によっては、オ
ブジェクトマイグレーションが望ましくない場合があ
る。例えば、デバイスドライバを管理しているメタオブ
ジェクト空間が、オブジェクト（デバイスドライバ）を
移動する場合には、クライアント２側にハードウエアデ
バイスが実際に存在していなければ、その移動を行って
も意味が無くなってしまう。また仮想記憶管理機構を利
用して、オブジェクトのメモリセグメントを管理してい
るメタオブジェクトも、移動先に仮想記憶管理機構が存
在しなければ、移動を行ったとしてもメモリセグメント
を管理することができない。そこで、マイグレーション
プロトコルにおいては、次のメソッドが用意されてい
る。

【００９４】Ｆｅａｔｕｒｅ＊ Ｄｅｓｃｒｉｐｔｏ
ｒ：：ＣａｎＳｐｅａｋ（Ｆｅａｔｕｒｅ＊ ｐＦｅａ
ｔｕｒｅ）

【００９５】このメソッドは、クライアント２側のメタ
オブジェクト空間内のｄｅｓｃｒｉｐｔｏｒに対して、
ＣａｎＳｐｅａｋオペレーションを実行する。

【００９６】この時、フィーチャストラクチャが引数と
して渡され、結果としてクライアント２は、サーバ１に
対して自分自身（クライアント２）が受け入れ可能なフ
ィーチャストラクチャを返す。サーバ１側においては、
クライアント２側から返されたフィーチャストラクチャ
を検査することで、そのメタオブジェット空間の互換性
を知ることができる。

【００９７】互換性は、完全互換、半互換、および非互
換の３つのカテゴリに分類される。

【００９８】完全互換は、オブジェクトが移動後も完全
に実行を続けることができる場合を意味する。半互換
は、移動後のオブジェクトの実行には、ある制限が加え
られることを意味する。そして、非互換は、オブジェク
トは移動後には実行を続けることができないことを意味
する。

【００９９】非互換の場合には、オブジェクトマイグレ
ーションは行われない。半互換の場合にはマイグレーシ
ョンを行うか、行わないかをユーザが判断する。実際に
は、例外がユーザに返されるので、例外処理ルーチンに
よって、マイグレーションの判断がなされる。完全互換
の場合、または半互換の場合であって、オブジェクトマ
イグレーションが行われるときには、先に返されたフィ
ーチャストラクチャの内容に従って、マイグレーション
が行われる。

【０１００】なお、ネゴシエーションフェーズに先だっ
て、次のオペレーションによって空のｄｅｓｃｒｉｐｔ
ｏｒがクライアント２側のメタオブジェクト空間に生成
される。

【０１０１】 Ｄｅｓｃｒｉｐｔｏｒ：：Ｄｅｓｃｒｉｐｔｏｒ（）

【０１０２】先のＣａｎＳｐｅａｋメソッドは、このｄ
ｅｓｃｒｉｐｔｏｒに対して送られる。この時、フィー
チャストラクチャの情報を元に必要なメタオブジェクト
の生成、参照の生成、必要情報の登録が行われる。

【０１０３】第２のフェーズにおけるメタレベルでのプ
ロセスは、転送オブジェクトに対応したメタオブジェク
トの移動、あるは転送になる。ここで、メタオブジェク
トの移動とは、そのメタオブジェクトがクライアント２
側のメタオブジェクト空間に入ること、すなわち、ディ
スクリプタ（ｄｅｓｃｒｉｐｔｏｒ）から参照されるよ
うになることを意味し、また、メタオブジェクトの転送
とは、クライアント２側のメタオブジェクト空間にある
メタオブジェクト（これはｄｅｓｃｒｉｐｔｏｒから参
照されている）に対して、メタオブジェクト内のデータ
をメッセージとして送ることを意味する。

【０１０４】メタオブジェクトの移動および転送に関す
る実際のオペレーションが、ネゴシエーションフェーズ
によって得られたフィーチャストラクチャを利用して、
この第２のフェーズ（移動フェーズ）において実行され
る。

【０１０５】移動フェーズにおける実際のメタオブジェ
クトの移動および転送は、次のメソッドによって起動さ
れる。

【０１０６】Ｄｅｓｃｒｉｐｔｏｒ＆ Ｄｅｓｃｒｉｐ
ｔｏｒ：：ｏｐｅｒａｔｏｒ＝（Ｄｅｓｃｒｉｐｔｏｒ
＆ ｓｏｕｒｃｅ）

【０１０７】Ｄｅｓｃｒｉｐｔｏｒクラスは抽象クラス
であり、メタオブジェクトの移動、転送に関する共通の
プロトコルを定義している。ｓｏｕｒｃｅで参照される
ｄｅｓｃｒｉｐｔｏｒの内容が、このディスクリプタに
コピーされる。

【０１０８】実際の手続きは、Ｄｅｓｃｒｉｐｔｏｒク
ラスのサブクラスとして定義される。

【０１０９】次のメソッドは、メタオブジェクトの転送
に関するメソッドである。これらのプロトコルは主にｍ
ｉｇｒａｔｏｒ（メタオブジェクト空間内に含まれる、
オブジェクトマイグレーションを担当するメタオブジェ
クト）によって使用される。 ・ＣａｎｏｎｉｃａｌＣｏｎｔｅｘｔ＆ Ｃｏｎｔｅｘ
ｔ：：ａｓＣａｎｏｎｉｃａｌ（） 機械依存のＣｏｎｔｅｘｔ構造体を、機械非依存の形式
に変換する。このプロトコルは、ｆｅａｔｕｒｅ ｓｔ
ｒｕｃｔｕｒｅによってＣｏｎｔｅｘｔの直接変換が不
可能である、と示されたときに実行される。 ・Ｃｏｎｔｅｘｔ＆ Ｃｏｎｔｅｘｔ：：ｏｐｅｒａｔ
ｏｒ＝（Ｃｏｎｔｅｘｔ＆ ｓｏｕｒｃｅ） ・Ｃｏｎｔｅｘｔ＆ Ｃｏｎｔｅｘｔ：：ｏｐｅｒａｔ
ｏｒ＝（ＣａｎｏｎｉｃａｌＣｏｎｔｅｘｔ＆ ｓｏｕ
ｒｃｅ） 現在（ｔｈｉｓが参照する）Ｃｏｎｔｅｘｔをｓｏｕｒ
ｃｅが参照するＣｏｎｔｅｘｔで初期化する。 ・ＣａｎｏｎｉｃａｌＳｅｇｍｅｎｔ＆ Ｓｅｇｍｅｎ
ｔ：：ａｓＣａｎｏｎｉｃａｌ（） 機械依存のＳｅｇｍｅｎｔ構造体を、機械非依存の形式
に変換する。このプロトコルは、ｆｅａｔｕｒｅ ｓｔ
ｒｕｃｔｕｒｅによってＣｏｎｔｅｘｔの直接変換が不
可能である、と示されたときに実行される。 ・Ｓｅｇｍｅｎｔ＆ Ｓｅｇｍｅｎｔ：：ｏｐｅｒａｔ
ｏｒ＝（Ｓｅｇｍｅｎｔ＆ ｓｏｕｒｃｅ） ・Ｓｅｇｍｅｎｔ＆ Ｓｅｇｍｅｎｔ：：ｏｐｅｒａｔ
ｏｒ＝（ＣａｎｏｎｉｃａｌＳｅｇｍｅｎｔ＆ ｓｏｕ
ｒｃｅ） 現在のｔｈｉｓ（が参照する）Ｓｅｇｍｅｎｔをｓｏｕ
ｒｃｅが参照するＳｅｇｍｅｎｔで初期化し、必要なメ
モリ領域をコピーする。

【０１１０】図１１は、フィーチャストラクチャの構造
を表している。同図に示すように、ｏｂｊｅｃｔ ｄｅ
ｓｃｒｉｐｔｉｏｎとｅｎｖｉｒｏｎｍｅｍｔ ｄｅｓ
ｃｒｉｐｔｉｏｎのポインタが、エントリーに記述され
ている。

【０１１１】ｏｂｊｅｃｔ ｄｅｓｃｒｉｐｔｉｏｎの
ポインタで指示されているストラクチャには、ｏｂｊｅ
ｃｔ ｎａｍｅが記述され、さらに、ｅｎｖｉｒｏｎｍ
ｅｎｔ ｄｅｓｃｒｉｐｔｉｏｎのポインタで指示され
ているストラクチャと同一のストラクチャのポインタが
記述されている。そしてさらに、このオブジェクトの資
源要求（ｒｅｓｏｕｒｃｅ ｒｅｑｕｉｒｅｍｎｅｎｔ
ｏｆ ｔｈｉｓ ｏｐｊｅｃｔ）が記述されている。

【０１１２】また、ｅｎｖｉｒｏｎｍｅｎｔ ｄｅｓｃ
ｒｉｐｔｉｏｎのポインタで指示されているストラクチ
ャには、ｅｎｖｉｒｏｎｍｅｎｔ ｎａｍｅが記述さ
れ、さらに、そのクライアントのハードウエアの資源情
報（ｒｅｓｏｕｒｃｅ ｉｎｆｏｒｍａｔｉｏｎ ｏｆ
ｃｌｉｅｎｔ ｈａｒｄｗａｒｅ）、この実行環境の
資源要求（ｒｅｓｏｕｒｃｅ ｒｅｑｕｉｒｅｍｅｎｔ
ｏｆ ｔｈｉｓ ｅｎｖｉｒｏｎｍｅｎｔ）、および
この実行環境を構成するメタオブジェクトのリスト（ｌ
ｉｓｔ ｏｆ ｍｅｔａｏｂｊｅｃｔｓ ｃｏｎｓｔｉ
ｔｕｔｉｎｇ ｅｎｖｉｒｏｎｍｅｎｔ）が記述されて
いる。

【０１１３】フィーチャストラクチャの内容の具体例を
あげると、次のようになる。

【０１１４】（１）オブジェクトに関する情報 実時間性 必要プロセッサ量

【０１１５】（２）メタオブジェクトに関する情報 ハードウェアメタオブジェクト ＊プロセッサの種類 ＊データ表現形式 セグメントメタオブジェクト ＊大きさ ＊拡大、縮小可能性 ＊管理方針 ＊レイアウト コンテキストメタオブジェクト ＊レジスタ情報 ＊一時変数量 ＊プロセッサ状態 メイラメタオブジェクト ＊メッセージキュー長 ＊未処理メッセージ数 ＊外部メイラの必要性 ＊メッセージの転送方式 外部メイラメタオブジェクト ＊メッセージキュー長 ＊未処理メッセージ数 ＊プロトコル スケジューラメタオブジェクト ＊オブジェクト状態 ＊スケジューリング方針 依存管理メタオブジェクト ＊保有する外部名数

【０１１６】上述したように、各クライアントが異なる
ＯＳを有するような場合、このフィーチャストラクチャ
から各クライアントのＯＳが判定され、サーバは、その
ＯＳに対応するオブジェクトをダウンロードさせること
になる。

【０１１７】図１２は、本発明のデータ処理システムを
応用したＡｐｅｒｔｏｓ（商標）システムの構成例を示
している。このＡｐｅｒｔｏｓシステムにおいては、Ａ
ｐｅｒｔｏｓ Ｍｉｃｒｏ Ｖｉｒｔｕａｌ Ｍａｃｈ
ｉｎｅ（ＭＶＭ）３１ａ（第１の実行手段）は、Ａｐｅ
ｒｔｏｓ Ｍｉｃｒｏ Ｋｅｒｎｅｌ（ＭＫ）３１ｂ
（第２の実行手段）とともにあり、Ａｐｅｒｔｏｓシス
テムの核３１を構成している。核３１を構成するＭＶＭ
３１ａは後述する中間コード（Ｉ−ｃｏｄｅ）を解釈実
行するが、必要に応じて、ＭＫ３１ｂの機能を用いてｐ
ｅｒｓｏｎａｌｉｔｙオブジェクト（システムオブジェ
クト）を呼び出すようになされている。

【０１１８】図１２に示した核３１以外の部分は、上述
した方法により、例えば、サーバ１よりダウンロードす
ることができる。

【０１１９】このシステムは、必要に応じてＩ−ｃｏｄ
ｅをｎａｔｉｖｅ ｃｏｄｅ（バイナリコード、マシン
コード）に動的にコンパイルする。また、予めｎａｔｉ
ｖｅｃｏｄｅにコンパイルされているオブジェクトを実
行するが、その場合、ＭＫ３１ｂの機能によってＰｅｒ
ｓｏｎａｌｉｔｙオブジェクト３３（バイナリコード生
成手段）が呼び出され、アプリケーション（Ａｐｐｌｉ
ｃａｔｉｏｎｓ）３５にサービスを提供する。

【０１２０】図１２に示した核３１を構成するＭＶＭ３
１ａおよびＭＫ３１ｂは、その外側がデバイスドライバ
オブジェクト（Ｄｅｖｉｃｅ ｄｒｉｖｅｒｓ）３２と
Ｐｅｒｓｏｎａｌｉｔｙオブジェクト（Ｐｅｒｓｏｎａ
ｌｉｔｙ ｃｏｍｐｏｎｅｎｔ ｏｂｊｅｃｔｓ）３３
によって取り囲まれており、さらに外側には、アプリケ
ーションプログラミングのためのクラスシステム（Ｃｌ
ａｓｓ Ｌｉｂｒａｒｉｅｓ）３４が用意されており、
さらにその外側にはアプリケーション３５が用意されて
いる。

【０１２１】Ｐｅｒｓｏｎａｌｉｔｙオブジェクト３３
の層により、Ａｐｅｒｔｏｓシステムは様々なＯＳ（オ
ペレーティングシステム）やＶｉｒｔｕａｌ Ｍａｃｈ
ｉｎｅ（仮想計算機）を提供することができる。例え
ば、ｊａｖａプログラムの実行は、ｊａｖａプログラム
用のＰｅｒｓｏｎａｌｉｔｙオブジェクトによって、ｊ
ａｖａプログラムがコンパイルされて得られた中間コー
ドであるｊａｖａ ｂｙｔｅｃｏｄｅが実行されること
により行われる。

【０１２２】Ａｐｅｒｔｏｓシステムは、高度のｐｏｒ
ｔａｂｉｌｉｔｙを実現するために、プログラムをＩ−
ｃｏｄｅ（中間コード）にコンパイルし、オブジェクト
のメソッドを管理している。しかしながら、Ｉ−ｃｏｄ
ｅは、解釈実行（プログラムを解釈しながら実行するこ
と）を前提に設計されているのではなく、動的コンパイ
ラによってｎａｔｉｖｅ ｃｏｄｅにコンパイルするよ
うに設計されている。しかし、様々な制約により、動的
コンパイルが困難である場合、ＭＶＭ３１ａがＩ−ｃｏ
ｄｅを解釈実行する。

【０１２３】しかしながら、ほとんどの場合、Ｉ−ｃｏ
ｄｅは、ｎａｔｉｖｅ ｃｏｄｅにコンパイルされ、シ
ステムを構成するＣＰＵにより直接実行される。従っ
て、Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅによる実行に伴っ
て、実時間性が欠如したり、処理スピードが犠牲になる
ということはほとんどない。

【０１２４】上記Ｉ−ｃｏｄｅは、高度のＩｎｔｅｒ−
Ｏｐｅｒａｂｉｌｉｔｙを実現するため、図２２を参照
して後述するように、十分に抽象度の高い２つの命令セ
ット（ＯＰ＿Ｍ，ＯＰ＿Ｒ）から構成されており、その
セマンティクス（意味構造）は、ＭＫ３１ｂのインタフ
ェースと強く関連づけられている。即ち、図１２に示し
たＡｐｅｒｔｏｓシステムの構造に強く影響を受けた命
令セットとされている。これにより、Ａｐｅｒｔｏｓシ
ステムにおいては、ｎａｔｉｖｅ ｃｏｄｅを前提とし
ていながら、高度のＰｏｒｔａｂｉｌｉｔｙとＩｎｔｅ
ｒ−Ｏｐｅｒａｂｉｌｉｔｙを実現することができる。

【０１２５】次に、ＭＶＭ３１ａとＭＫ３１ｂの仕様に
ついて説明する。最初に、ＭＶＭ３１ａが仮定している
データ構造体と、Ｉ−ｃｏｄｅフォーマットを規定す
る。

【０１２６】図１３は、図１２に示したＭＶＭ３１ａと
ＭＫ３１ｂの論理構造を示している。基本的に両者の論
理構造は同一であり、ａｃｔｉｖｅ ｃｏｎｔｅｘｔ４
１、ｍｅｓｓａｇｅ ｆｒａｍｅ４２、およびｅｘｅｃ
ｕｔｉｏｎ ｅｎｇｉｎｅ４３により構成されている
が、ＭＶＭ３１ａは、Ｉ−ｃｏｄｅによる実行をサポー
トし、ＭＫ３１ｂはｎａｔｉｖｅ ｃｏｄｅによる実行
をサポートしている。

【０１２７】図１３において、ａｃｔｉｖｅ ｃｏｎｔ
ｅｘｔ４１は、現在実行中のＣｏｎｔｅｘｔ（図１４を
参照して後述する）を指しており、ｍｅｓｓａｇｅ ｆ
ｒａｍｅ４２は、核３１を構成するＭＶＭ３１ａおよび
ＭＫ３１ｂに対するメッセージ本体を指している。

【０１２８】ＭＫ３１ｂの場合、メッセージ本体の存在
する場所は実装方法に依存し、スタックフレームとして
メモリに割り当てられる場合もあるし、ヒープ（ｈｅａ
ｐ）に割り当てられる場合もある。また、いくつかのＣ
ＰＵのレジスタが割り当てられる場合もある。一方、Ｍ
ＶＭ３１ａの場合、メッセージフレームは命令コードに
続くオペランドを指すことになる。実装によっては、こ
れら以外に内部レジスタ等を必要とするかもしれない
が、それらのレジスタは本仕様とは独立のものである。

【０１２９】図１３において、ｅｘｅｃｕｔｉｏｎ ｅ
ｎｇｉｎｅ４３は、Ｉ−ｃｏｄｅおよびｎａｔｉｖｅ
ｃｏｄｅを実行する。また、ＭＶＭ３１ａのｅｘｅｃｕ
ｔｉｏｎ ｅｎｇｉｎｅ４３には、ｐｒｉｍｉｔｉｖｅ
ｏｂｊｅｃｔｓ４４が含まれており、これは、図１８
を参照して後述するプリミティブオブジェクトを処理す
るコードである。

【０１３０】図１４は、ＣｏｎｔｅｘｔとＤｅｓｃｒｉ
ｐｔｏｒの論理構造を示している。プログラムの１つの
実行状態を示すＣｏｎｔｅｘｔ構造体５１は、ｏｂｊｅ
ｃｔ、ｃｌａｓｓ、ｍｅｔｈｏｄ、ｍｅｔａなどのフィ
ールドを有し、このうち、ｍｅｔｈｏｄには、ｉｃｏｄ
ｅとｍｉｎｆｏのフィールドがさらに設けられている。
このＣｏｎｔｅｘｔ構造体５１は、ＭＶＭ３１ａの状態
を保持し、ＣＰＵのレジスタに相当し、メモリ管理やプ
ログラム間の通信方法などとは完全に独立している。

【０１３１】Ｃｏｎｔｅｘｔ構造体５１は、Ｃｏｎｔｅ
ｘｔプリミティブオブジェクトであり、図１６を参照し
て後述するように、その各フィールドは所定の情報にリ
ンクしている。また、Ｃｏｎｔｅｘｔ構造体５１は、核
３１（ＭＶＭ３１ａおよびＭＫ３１ｂ）の実装に深く依
存しているが、図１４においては、主に依存しない部分
を示している。

【０１３２】このＣｏｎｔｅｘｔ構造体５１において重
要なフィールドは、ｍｅｔａフィールドであり、Ｄｅｓ
ｃｒｉｐｔｏｒ構造体５２を指している。Ｄｅｓｃｒｉ
ｐｔｏｒ構造体５２のエントリは、＃ｔａｇ、ｃｏｎｔ
ｅｘｔ、およびｓｅｌｅｃｔｏｒの３つの組みであり、
このＤｅｓｃｒｉｐｔｏｒ構造体５２によって、Ｐｅｒ
ｓｏｎａｌｉｔｙオブジェクト３３のＡＰＩ（アプリケ
ーションプログラミングインタフェース）が決定され
る。＃ｔａｇはＡＰＩの名称を、ｃｏｎｔｅｘｔとｓｅ
ｌｅｃｔｏｒでＡＰＩのアドレスをそれぞれ表してい
る。

【０１３３】図１５は、ＭＶＭ３１ａの全体構造を示し
ている。基本的に、全ての必要な情報は、Ｃｏｎｔｅｘ
ｔ構造体５１からリンクを辿ることにより参照すること
ができるようになされている。即ち、Ｃｏｎｔｅｘｔ構
造体５１が、ｏｂｊｅｃｔ６１にリンクされ、このｏｂ
ｊｅｃｔ６１は、ｏｂｊｅｃｔ６１に対応するクラスへ
のリンク（ｃｌａｓｓ ｐｏｉｎｔｅｒ）とインスタン
ス領域（ｏｂｊｅｃｔｄｅｐｅｎｄｅｎｔ ｆｉｅｌ
ｄ）より構成される。インスタンス領域にどのような情
報が格納されるか、あるいはそのレイアウトは、オブジ
ェクトの実装に依存する。

【０１３４】ｃｌａｓｓ６２は、主としてメソッドを保
持する。ｃｌａｓｓ６２はその名称（ｃｌａｓｓ ｎａ
ｍｅ）、その実装に依存する部分（ｃｌａｓｓ ｄｅｐ
ｅｎｄｅｎｔ ｆｉｅｌｄ）、およびＩ−ｍｅｔｈｏｄ
構造体６３へのリンクテーブル（ｍｅｔｈｏｄ ｔａｂ
ｌｅ）により構成される。Ｉ−ｍｅｔｈｏｄ構造体６３
は、Ｂｌｏｃｋプリミティブオブジェクトであり、ヘッ
ダ（Ｈｅａｄｅｒ）、Ｉ−ｃｏｄｅ部、および変数テー
ブル（Ｖａｒｉａｂｌｅ ｔａｂｌｅ）からなる。ｍａ
ｇｉｃ＃は、ＭＶＭ３１ａの管理番号（ＩＤ）である。
基本的に、Ｉ−ｃｏｄｅ命令のオペランドは、この変数
テーブルエントリを介して目的オブジェクトを参照す
る。

【０１３５】図１５において、グレーの部分（Ｃｏｎｔ
ｅｘｔ５１、Ｉ−ｍｅｔｈｏｄ６３）はＭＶＭ３１ａに
依存する部分であり、ＭＶＭ３１ａがＩ−ｃｏｄｅを解
釈実行する場合に必要とする構造体である。

【０１３６】図１６は、Ｃｏｎｔｅｘｔ構造体５１を中
心に、そこからリンクされている構造体を図示したもの
である。Ｃｏｎｔｅｘｔ構造体５１のオブジェクトフィ
ールドは、ｏｂｊｅｃｔ６１を指し、ｃｌａｓｓフィー
ルドは、ｃｌａｓｓ６２のｃｌａｓｓ ｄｅｐｅｎｄｅ
ｎｔ ｆｉｅｌｄを指している。また、ｍｅｔｈｏｄフ
ィールドはＩ−ｍｅｔｈｏｄ６３を指しており、ｍｅｔ
ｈｏｄフィールドのｉｃｏｄｅは、Ｉ−ｍｅｔｈｏｄ６
３のＩ−ｃｏｄｅを指している。ｉｃｏｄｅは、プログ
ラムカウンタに相当し、実行中のプログラムを指す。ｍ
ｅｔｈｏｄフィールドのｖｔａｂｌｅは、Ｉ−ｍｅｔｈ
ｏｄ６３のｖａｒｉａｂｌｅ ｔａｂｌｅを指してい
る。

【０１３７】ｔｅｍｐｏｒａｒｙフィールドは、一時デ
ータ保存領域を指し、ｍｅｔａフィールドは、上述した
ように、ｄｅｓｃｒｉｐｔｏｒ５２を指している。ま
た、オブジェクト６１のｃｌａｓｓ ｐｏｉｎｔｅｒ
は、ｃｌａｓｓ６２を指し、ｃｌａｓｓ６２のｍｅｔｈ
ｏｄ ｔａｂｌｅは、Ｉ−ｍｅｔｈｏｄ６３を指してい
る。

【０１３８】ｖａｒｉａｂｌｅ ｔａｂｌｅエントリ
は、ｔｙｐｅとｖａｌｕｅの組みであり、ｖａｌｕｅは
ｔｙｐｅに依存する。

【０１３９】ＭＶＭ３１ａは、図１７に示したタイプを
処理するようになされており、ｔｙｐｅがＴ＿ＰＲＩＭ
ＩＴＩＶＥのとき、ｖａｌｕｅ欄はプリミティブオブジ
ェクトを参照する。この場合、ｖａｌｕｅ欄には、例え
ば、＜Ｐ＿ＩＮＴＥＧＥＲ，ｉｍｍｅｄｉａｔｅ＞，＜
Ｐ＿ＳＴＲＩＮＧ，ａｄｄｒｅｓｓ ｔｏ ｈｅａｐ＞
といった、図１８に示すような＜Ｐ＿ＣＬＡＳＳ，Ｐ＿
ＢＯＤＹ＞の組が格納される。図１８は、プリミティブ
オブジェクトの一覧と、そのインタフェース名を示して
いる。図１９乃至図２１は、図１８に示したプリミティ
ブオブジェクトのインタフェースを、Ｉｎｔｅｒｆａｃ
ｅ Ｄｅｆｉｎｉｔｉｏｎ Ｌａｎｇｕａｇｅ（ＩＤ
Ｌ）法により記述した例を示している。このＩＤＬ法に
ついては、「ＣＯＲＢＡ Ｖ２．０，Ｊｕｌｙ １９９
５，Ｐ３−１乃至３−３６」に開示されている。

【０１４０】また、図１７において、ｔｙｐｅがＴ＿Ｐ
ＯＩＮＴＥＲのとき、オブジェクトを参照するためのＩ
Ｄがｖａｌｕｅ欄に格納される。このＩＤは、その位置
が独立な、システムで唯一の値であり、Ｐｅｒｓｏｎａ
ｌｉｔｙオブジェクト３３によって、そのＩＤに対応す
るオブジェクトの位置が特定される。

【０１４１】図２２は、ＭＶＭ３１ａが解釈実行する２
つの命令セットを示している。命令セットＯＰ＿Ｍは、
図１２において、外側から内側に入る命令であり、命令
セットＯＰ＿Ｒは、内側から外側に戻る命令である。

【０１４２】即ち、命令セットＯＰ＿Ｍにより、その第
１オペランドで示されたオペレーションが実行される。
このオペレーションは、Ｐｅｒｓｏｎａｌｉｔｙオブジ
ェクト３３によって処理されるか、またはプリミティブ
オブジェクトによって処理される。コンパイラは、より
効率的にアプリケーション３５を実行するために、いく
つかの処理をプリミティブオブジェクトによって処理す
るように、Ｉ−ｃｏｄｅを生成する。これにより、例え
ば、Ｉｎｔｅｇｅｒの算術演算は、図１８の先頭のプリ
ミティブオブジェクトによって処理される。

【０１４３】次に、ＭＫ３１ｂのインタフェースを規定
する。図２３は、マイクロカーネル（ＭＫ）３１ｂのイ
ンタフェースを示している。ＭＶＭ３１ａとＭＫ３１ｂ
の論理構造は、図１３に示したように同様であり、ＭＫ
３１ｂは、図２２に示した命令セットＯＰ＿ＭおよびＯ
Ｐ＿Ｒをシステムコールとして処理する。

【０１４４】上述したような構成のＡｐｅｒｔｏｓシス
テムを、例えば図４に示したクライアント２（２−１，
２−２）に適用することができる。そして、図１２に示
した核３１以外のもののうち、任意のものをサーバ１か
らダウンロードすることにより、所定のアプリケーショ
ンを実行するための最適な実行環境をクライアント２上
に構築することができる。

【０１４５】上述したように、ここでダウンロードする
オブジェクトとしては次のものが考えられる。

【０１４６】（１）すべてのアプリケーションプログラ
ム

【０１４７】（２）クライアントが備えるハードウェア
資源を制御するためのデバイスドライバ群（例えば、Ｍ
ＰＥＧドライバ、ＡＴＭドライバ、画像制御ドライバ
等）

【０１４８】（３）アプリケーションプログラムに対し
てシステムサービスを提供するオブジェクト群（ｐｅｒ
ｓｏｎａｉｔｙオブジェクト）（例えば、ＶＣＲコマン
ド管理、ストリーム管理、実時間スケジューラ、メモリ
管理、ウィンドウ管理、ダウンロード制御、通信プロト
コル管理、実行管理等）

【０１４９】これらを組み合わせて、アプリケーション
プログラムに対して最適な実行環境をクライアント上に
構築することができる。

【０１５０】例えば、ｊａｖａプログラムを実行させた
い場合、ｊａｖａ用のｐｅｒｓｏｎａｌｉｔｙオブジェ
クト３３と、ｊａｖａプログラム（アプリケーション）
３５をサーバ１よりダウンロードする。このｐｅｒｓｏ
ｎａｌｉｔｙオブジェクト３３により、Ａｐｅｒｔｏｓ
システムは、Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎ
ｅを提供することができる。ダウンロードされたｊａｖ
ａプログラムは、コンパイラにより一旦ｊａｖａ ｂｙ
ｔｅｃｏｄｅと呼ばれる中間コードにコンパイルされ、
上記ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅにより
実行される。あるいは、上述したように、ｎａｔｉｖｅ
ｃｏｄｅにコンパイルした後、実行するようにするこ
とも可能である。

【０１５１】以上の実施例においては、サーバからクラ
イアントに所定のオブジェクトをダウンロードするよう
にしたが、所定のクライアントから、所定のサーバにオ
ブジェクトをダウンロードしたり、あるいはサーバ同
士、クライアント同士でオブジェクトをダウンロードす
る場合にも、本発明を適用することが可能である。

【０１５２】また、上記実施例においては、Ｉ−ｃｏｄ
ｅを２つの命令により構成するようにしたが、これに限
定されるものではない。

【０１５３】

【発明の効果】以上の如く請求項１記載のデータ処理方
法および請求項９に記載のデータ処理装置によれば、ク
ライアントがダウンロードするアプリケーションプログ
ラムの実行環境を有するか否かを検査し、その検査結果
に対応して、アプリケーションプログラムをクライアン
トにダウンロードするようにしたので、クライアントの
構成を簡略化し、低コスト化するとともに、低コストで
アプリケーションプログラムを提供することが可能とな
る。

【０１５４】請求項１０に記載のデータ処理装置によれ
ば、サーバに対してダウンロードするアプリケーション
プログラムを実行環境に関する告知を行い、その告知に
対応して、サーバからアプリケーションプログラムをダ
ウンロードするようにしたので、構成が簡単で低コスト
の装置を実現することが可能となる。また、低コストで
アプリケーションプログラムを提供することができる。

【０１５５】請求項１１に記載のデータ処理装置、およ
び請求項１５に記載のデータ処理方法によれば、中間コ
ードに変換されたアプリケーションプログラムを解釈
し、実行するか、または、中間コードを動的にコンパイ
ルし、生成されたバイナリコードを実行することで、ア
プリケーションプログラムを実行するようにしたので、
動的コンパイルが困難な場合、中間コードを逐次解釈
し、実行することができる。また、中間コードを簡単な
構成とすることにより、ポータブルなアプリケーション
を構築することができる。

【図面の簡単な説明】

【図１】本発明のデータ処理方法を適用するシステムの
構成例を示す図である。

【図２】アプリケーションプログラムの構成を示す図で
ある。

【図３】並行オブジェクトの構成を示す図である。

【図４】サーバから複数ベンダのクライアントに対する
オブジェクトのダウンロードを説明する図である。

【図５】インクリメンタルダウンロードを説明する図で
ある。

【図６】メタ標準を説明する図である。

【図７】オブジェクトの動的変更を説明する図である。

【図８】オブジェクトの動的拡張を説明する図である。

【図９】クライアントの最小機能を説明する図である。

【図１０】アプリケーションに適したクライアント環境
の構築とその動的再構成を説明する図である。

【図１１】フィーチャストラクチャの構成を説明する図
である。

【図１２】本発明のデータ処理装置を応用したＡｐｅｒ
ｔｏｓシステムの構成例を示す図である。

【図１３】ＭＶＭとＭＫの論理構造を示す図である。

【図１４】ＣｏｎｔｅｘｔとＤｅｓｃｒｉｐｔｏｒの論
理構造を示す図である。

【図１５】ＭＶＭの全体構造を示す図である。

【図１６】Ｃｏｎｔｅｘｔとその回りのデータ構造体を
示す図である。

【図１７】Ｖａｒｉａｂｌｅ ｔａｂｌｅエントリのｔ
ｙｐｅを示す図である。

【図１８】プリミティブオブジェクトの一覧とそのイン
タフェース名を示す図である。

【図１９】プリミティブオブジェクトのインタフェース
を示す図である。

【図２０】プリミティブオブジェクトのインタフェース
を示す図である。

【図２１】プリミティブオブジェクトのインタフェース
を示す図である。

【図２２】Ｉ−ｃｏｄｅ命令セットを示す図である。

【図２３】ＭＫのインタフェースを示す図である。

【符号の説明】

１ サーバ，２ クライアント，３ ネットワーク，１
１ アプリケーションプログラム，１２ 実行環境，１
３ アプリケーションプログラムインタフェース，１
４，１５ オブジェクト，２１ アプリケーションプロ
グラム，２２ 実行環境，２３ アプリケーションプロ
グラムインタフェース，３１ 核，３１ａＭＶＭ，３１
ｂ ＭＫ，３２ Ｄｅｖｉｃｅ ｄｒｉｖｅｒｓ，３３
Ｐｅｒｓｏｎａｌｉｔｙ ｃｏｍｐｏｎｅｎｔ ｏｂ
ｊｅｃｔ，３４ Ｃｌａｓｓ ｌｉｂｒａｒｉｅｓ，３
５ Ａｐｐｌｉｃａｔｉｏｎｓ，４１ ａｃｔｉｖｅ
ｃｏｎｔｅｘｔ，４２ ｍｅｓｓａｇｅ ｆｒａｍｅ，
４３ ｅｘｅｃｕｔｉｏｎｅｎｇｉｎｅ，４４ ｐｒｉ
ｍｉｔｉｖｅ ｏｂｊｅｃｔｓ，５１ ｃｏｎｔｅｘ
ｔ，５２ Ｄｅｓｃｒｉｐｔｏｒ，６１ ｏｂｊｅｃ
ｔ，６２ ｃｌａｓｓ，６３ Ｉ−ｍｅｔｈｏｄ

Claims (15)

【特許請求の範囲】
1. 【請求項１】 複数のオブジェクトで構成されるアプリ
   ケーションプログラムと、複数のオブジェクトで構成さ
   れる、前記アプリケーションプログラムの動作を規定す
   る実行環境と、前記アプリケーションプログラムと前記
   実行環境の間のインタフェースを規定するアプリケーシ
   ョンプログラムインタフェースとを備えるサーバと、 前記サーバより前記アプリケーションプログラムをダウ
   ンロードするクライアントと、 を備えるデータ処理システムにおけるデータ処理方法に
   おいて、 前記サーバは、前記クライアントに前記アプリケーショ
   ンプログラムをダウンロードするとき、前記クライアン
   トが、ダウンロードする前記アプリケーションプログラ
   ムの実行環境を有するか否かを検査し、 その検査結果に対応して前記アプリケーションプログラ
   ムを前記クライアントにダウンロードすることを特徴と
   するデータ処理方法。
2. 【請求項２】 前記クライアントが、ダウンロードする
   前記アプリケーションプログラムの実行環境を有しない
   とき、前記サーバから前記クライアントにオブジェクト
   をダウンロードし、前記サーバにおける前記実行環境と
   同一の実行環境を前記クライアントに構築し、その後、
   前記サーバから前記クライアントに前記アプリケーショ
   ンプログラムをダウンロードすることを特徴とする請求
   項１に記載のデータ処理方法。
3. 【請求項３】 前記アプリケーションプログラムのオブ
   ジェクトは、並行オブジェクトであることを特徴とする
   請求項１に記載のデータ処理方法。
4. 【請求項４】 前記サーバは、前記アプリケーションプ
   ログラムの実行に必要な前記実行環境のオブジェクトを
   インクリメンタルにダウンロードすることを特徴とする
   請求項１に記載のデータ処理方法。
5. 【請求項５】 前記クライアントの実行環境には、最低
   限の標準的機能として、 前記サーバから前記クライアントへオブジェクトをダウ
   ンロードするダウンロード機能と、 前記実行環境の互換性を検査する検査機能と、 前記実行環境を構築する構築機能とを具備させ、 必要に応じてその他の機能をダウンロードさせることを
   特徴とする請求項２に記載のデータ処理方法。
6. 【請求項６】 前記クライアントには、最低限の標準的
   機能として、 デバイスドライバのための実行環境と、 システムオブジェクトのための実行環境と、 実行環境のための実行環境とを具備させ、 必要に応じてその他の機能をダウンロードさせることを
   特徴とする請求項２に記載のデータ処理方法。
7. 【請求項７】 前記デバイスドライバは、インプットド
   ライバ、タイマドライバ、スクリーンドライバを含み、 前記システムオブジェクトは、インプットハンドラ、ブ
   ートプロトコル、メモリマネージャの各オブジェクトを
   含むことを特徴とする請求項６に記載のデータ処理方
   法。
8. 【請求項８】 前記サーバと前記クライアントは、前記
   クライアントの前記実行環境の互換性を検査するため
   に、前記オブジェクトと前記実行環境について記述した
   デスクリプションを含むフィーチャストラクチャを授受
   することを特徴とする請求項１に記載のデータ処理方
   法。
9. 【請求項９】 複数のオブジェクトで構成されるアプリ
   ケーションプログラムと、複数のオブジェクトで構成さ
   れる、前記アプリケーションプログラムの動作環境を規
   定する実行環境と、前記アプリケーションプログラムと
   前記実行環境の間のインタフェースを規定するアプリケ
   ーションプログラムインタフェースとを備え、クライア
   ントにアプリケーションプログラムをダウンロードさせ
   るデータ処理装置において、 前記クライアントに前記アプリケーションプログラムを
   ダウンロードするとき、前記クライアントが、ダウンロ
   ードする前記アプリケーションプログラムの実行環境を
   有するか否かを検査する検査手段と、 前記検査手段の検査結果に対応して前記アプリケーショ
   ンプログラムを前記クライアントにダウンロードするダ
   ウンロード手段とを備えることを特徴とするデータ処理
   装置。
10. 【請求項１０】 複数のオブジェクトで構成されるアプ
    リケーションプログラムと、複数のオブジェクトで構成
    される、前記アプリケーションプログラムの動作環境を
    規定する実行環境と、前記アプリケーションプログラム
    と前記実行環境の間のインタフェースを規定するアプリ
    ケーションプログラムインタフェースとを備え、サーバ
    からアプリケーションプログラムをダウンロードするデ
    ータ処理装置において、 前記サーバから前記アプリケーションプログラムをダウ
    ンロードするとき、ダウンロードする前記アプリケーシ
    ョンプログラムの実行環境に関する告知を行う告知手段
    と、 前記告知手段の告知に対応して前記サーバから前記アプ
    リケーションプログラムをダウンロードするダウンロー
    ド手段とを備えることを特徴とするデータ処理装置。
11. 【請求項１１】 複数のオブジェクトで構成されるアプ
    リケーションプログラムと、複数のオブジェクトで構成
    され、前記アプリケーションプログラムに対して実行環
    境を提供するシステムオブジェクトからなるデータ処理
    装置において、 中間コードに変換された前記アプリケーションプログラ
    ムを解釈し、実行する第１の実行手段と、 前記中間コードを動的にコンパイルし、バイナリコード
    を生成するバイナリコード生成手段と、 前記バイナリコードおよび前記システムオブジェクトを
    実行する第２の実行手段とを備えることを特徴とするデ
    ータ処理装置。
12. 【請求項１２】 前記第１の実行手段は、前記第２の実
    行手段を介して前記システムオブジェクトを実行するこ
    とを特徴とする請求項１１に記載のデータ処理装置。
13. 【請求項１３】 前記アプリケーションプログラムの実
    行状態を示す第１の構造体と、 前記システムオブジェクトが提供する実行環境のアプリ
    ケーションプログラムインタフェースを決定する第２の
    構造体とをさらに備え、 前記第１の実行手段および前記第２の実行手段は、前記
    第１の構造体と前記第２の構造体に基づいて、前記アプ
    リケーションプログラムの実行を制御することを特徴と
    する請求項１１に記載のデータ処理装置。
14. 【請求項１４】 前記第１の実行手段は、前記オブジェ
    クトの所定のものにより発行され、所定のオペランドで
    指定された所定のオペレーションを実行する第１の命令
    と、前記オペレーションを実行した後、前記命令を発行
    した前記オブジェクトに制御を戻す第２の命令とを有す
    ることを特徴とする請求項１１に記載のデータ処理装
    置。
15. 【請求項１５】 複数のオブジェクトで構成されるアプ
    リケーションプログラムと、複数のオブジェクトで構成
    され、前記アプリケーションプログラムに対して実行環
    境を提供するシステムオブジェクトからなるデータ処理
    装置におけるデータ処理方法において、 中間コードに変換された前記アプリケーションプログラ
    ムを解釈し、実行する方法と、前記中間コードを動的に
    コンパイルし、生成されたバイナリコードを実行する方
    法とにより、前記アプリケーションプログラムを実行す
    ることを特徴とするデータ処理方法。