JP4555000B2 - アプリケーションの適応的レプリケーションをサーバサイドコードユニットを用いて実行する方法および装置 - Google Patents

Description

本発明は、複製されたサーバサイドコードユニットを動的に選択しおよび呼び出すことにより、クライアント／サーバ型のアプリケーションにおけるユーザの利便性を向上させる技術に関する。

無線によるインターネット接続の普及および移動通信技術の発達により、携帯電話機、ＰＤＡ、ＷｉＦｉ規格対応のノート型パソコン等の携帯端末から、ウェブアプリケーションを実行することが可能となっている。特に、動的なウェブページ生成技術（例えばＪａｖａサーブレット（登録商標）やＣＧＩ等）を用いて、ユーザごとに特化したウェーブページや、ユーザからの指示等の種々の状況に応じて適切サービス（いわゆるコンテクストアウェアなウェブサービス）を携帯端末のユーザへ提供することが、今日盛んに行われている。しかしながら、従来の動的ウェブコンテンツの生成・配信方法は、接続状態が不安定な無線通信環境には適しているとは言い難い。

無線端末（クライアント装置）においては、一度自発的または強制的にコネクションを切断をする場合や、接続状態の悪い無線エリアへのローミングが発生する場合がある。このような場合、静的ページ先読み（プリフェッチ）、動的なコンテンツのキャッシングデータの複製（レプリケーション）、コンテンツ適応化処理、アプリケーションオフロード等の一般的に用いられている最適化処理が行われる。しかしながら、このような処理を行ったとしても、効率的なインタラクティブ動作を維持することができない。ここでいうインタラクティブ動作とは、例えば、請求金額情報の問い合わせ、調査フォームの提出、月々のローンの支払い処理に関する処理等である。これらの処理について、無線通信環境からのアクセスを排除すべき理由はない。

上述した、ウェブキャッシングやプリフェッチといった最適化処理は、確かに、ユーザのウェブアクセス性能を向上させるための重要な技術ではある。しかしながら、このような従来技術のほとんどは、静的データであって、且つ各ユーザに特化していないデータを処理対象としている。なお、わずかな例外としては、動的データのキャッシュ処理をサポートしているＤＵＰ（Data Update Propagation）システムがある。ＤＵＰシステムとは、グラフを用いて、キャッシュされているオブジェクトと当該オブジェクトの値に影響を与える下層データとの間のデータ依存情報を保持する、というものである。具体的には、下層データに変更があると、グラフの全検索（トラバース）が行われ、影響を受けた一組のキャッシュされたオブジェクトが決定される。しかしながら、ＤＵＰシステムにおいては、多数のユーザによって使用されるデータを対象としておらず、また、ユーザ特化度の高いウェブデータに適用することには限界がある。

また、同様の技術にアクティブキャッシュシステムがある。アクティブキャッシュシステムにおいては、プロキシサーバにおいて、各ドキュメントに対するキャッシュアプレットが実行される。キャッシュアプレットは、当該ドキュメントを前要求処理するのに使用される。すなわち、ドキュメントの生成または組み立てのためのコードをキャッシュするのである。しかしながら、アクティブキャッシュシステムにおいては、キャッシュされるアプレットは、サーバサイドコードユニットではない。さらに、キャッシュされるアプレットは、プロキシサーバ内で実行されるにように設計されている。加えて、同一のキャッシュアプレットが複数のプロキシサーバにおいてレプリケーションされた場合、アプリケーション等の状態整合性が保証されないばかりか、キャッシュアプレットを動的に選択してウェブサーバまたはプロキシサーバ上にて実行することは不可能である。

このように、既存のウェブキャッシング技術やプリフェッチ技術は、サーブレット等のサーバサイドのコードユニットを用いて生成され、高度に動的化された、且つユーザごとに特化されたアプリケーションに対しては、キャッシュ処理やプリフェッチ処理をうまく実行することができない。このようなアプリケーションに共通する特徴は、一見同じにみえるタスクでも、実行される時間やユーザが異なると、異なる相互作用シーケンスが実現され得る、という点である。例えば、ウェブ上で一つのサーバコンピュータを相手にチェスゲームを行っている複数のユーザがいる場合、応手によって取得するサービス応答が異なり、また対戦相手のユーザが異なれば取得するサービス応答が異なるのは当然である。

このような類のアプリケーションをスムーズに実行する方法として、デルタ圧縮等の技術を用いることも考えられている。このようなデータ圧縮技術を用いれば、サーバからクライアントに送信されるデータの量を減らすことは可能である。しかし、この場合、携帯端末におけるアプリケーションのレスポンスが悪化してしまう。このようなサーバサイドコードユニットがサーバに高負荷をかける結果、サービス要求に対する応答が帰ってくるまでの時間（サービス時間）は長くなる。これは、無線通信網においては、RTT（往復遅延時間）が長くなる傾向にあり、また固定通信網よりも通信接続状態の変動が大きいからである。この２つの要因により、通信遅延が増大し、サービス応答時間のばらつきが大きくなり、結果的にユーザが感じるサービス品質は低下することになる。また、多数の無線データ通信サービスの利用者が集中して特定の通信帯域を利用することによって生じ得る通信のレイテンシを、各利用者に感じさせないようにするためのソフトウェアも必要とされている。

本発明は、上述した背景に鑑みてなされたものであり、コードユニットの適応的レプリケーションを実行する方法及び装置を提供することを目的とする。

本発明は、一の態様において、サーバ装置およびクライアント装置が、実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）前記サーバ装置のハードウェア環境を表すサーバ機能情報と、（ｉｉ）前記サーバ、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得する取得ステップと、前記サーバ装置が、前記クライアント装置に対し、前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報と前記属性情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションの実行を許可する旨の実行指示を送信するステップと、前記クライアント装置が、前記実行指示に基づいて、前記アプリケーションサービスオブジェクトのレプリケーションを実行する実行ステップとを有し、前記実行ステップにおいて、前記クライアント装置が、クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度を取得し、該取得された信頼度と前記属性から決定される閾値とを比較することにより、サーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定することを特徴とするレプリケーション実行方法を提供する。

クライアント装置の機能や通信環境の変動等に応じて最適なレプリケーション処理が行われる。

［Ａ．導入部］
サーバからクライアントへ、サーバサイドコードユニットの実行をその状態とともに移行させる技術について、以下、具体的に説明する。この技術により、サーバにおける負荷が少なくなり、サーバとクライアントとの間で不必要な通信を行わなくて済むようになる。本発明においては、クライアント装置の機能の多様性や、サーバの負荷および無線通信環境の時間的変動により、コードユニットをサーバまたはクライアントのどちらの側でコードユニット実行すべきかを正確に決定することが可能となり、また、この決定を、サーバ負荷や無線接続状態に応じて動的に変更することも可能である。

オン・デバイス（端末上の）サービスオブジェクトのレプリケーションについては、従来から良く知られている。例えば、オンデバイスサービスオブジェクトのレプリケーションは、クライアント側（以下、クライアンドサイドという場合がある）でのサーバ側（以下、サーバサイドという場合がある）コードユニットの実行メカニズムとして記述される（A. Datta, K. Dutta, H. Thomas, D. VanderMeer, Suresha, and K. Ramamritham, Proxy-based Acceleration of Dynamically Generated Content on the World Wide Web: An Approach and Implementation, in Proceedings of the 2002 ACM SIGMOD International Conference on Management of Data, June 2002を参照）。上記文献を本明細書において援用する。同文献において登場するマーブレット（Mervlet）とは、サーバサイドコードユニットであって、サーバとクライアント間を仮想的に移動するものである。マーブレットエンジン（ＭＥ）は、サーバとクライアントとの両方において実行され、マーブレットの実行管理を行う。

以下、マーブレットの適応レプリケーションを用いて、携帯端末のユーザ利便性を向上させるための、マーブレットの一例を使用したレプリケーション方法およびシステムについて説明する。以下、レプリケーション可能なマーブレットのことを「リプレット」と称することとする。

レプリケーションの態様には、ウェブ関連アプリケーションロジックを複製してクライアント装置へ提供するものもある。このような態様のレプリケーションにおいては、クライアント装置において利用可能なリソースが多様であっても、あるいは、各々異なるデータ共有方法やコヒーレンス要求を有する複数のアプリケーションであっても、また、アプリケーションの導入環境が複数存在している場合であっても、対応することができる。

このリプレットを用いたシステム（以下、リプレットシステムという）は、一の態様において、クライアント機能属性情報（ＣＰＩ）、サーバ機能属性情報、アプリケーション機能属性情報を用いて、サービスオブジェクトのレプリケーションをクライアント装置に指示する。なお、ＣＰＩは、レプリケーションを実行するクライアント装置の選択のために用いてもよい。また、ＣＰＩは、クライアント装置にクライアント固有データを供給するために用いてもよい。また、ＣＰＩは、要求を処理するための適切なレプリカを選択するために用いてもよい。 また、ＣＰＩは、複数のレプリカ間における所望の状態を維持するために用いてもよい。また、好適な態様において、このリプレットシステムは、レプリカの呼出しおよび同期を行うための、クライアント固有コスト指標、サーバ固有コスト指標、アプリケーション固有コスト指標を利用してオンデバイスレプリケーションを行うようにしてもよい。

本発明に係るオンデバイスサービスオブジェクトレプリケーションシステムにおいては、一または複数の多様なクライアント端末の機能、複数のアプリケーション、ユーザ、サーバの各々における要求、変動する通信環境に応じたレプリケーションが提供される。端末機能の多様性とは、具体的には、プロセッサの演算速度、利用可能なメモリ、電力、通信網の帯域幅等の要素に起因するものである。サービスオブジェクトには、ある端末においてレプリケーション可能であるが、他の端末においてはそのサービス機能の違いのためレプリケーション不可である、というものがあってもよい。これとは逆に、端末は特定のサービスオブジェクトのみをレプリケーション可能であってもよい。

なお、アプリケーション、ユーザ、サーバが異なれば、これらのニーズ（例えば、データ整合性要求および遅延許容度）も異なるのが通常である。例えば、接続自由度が異なれば、各クライアント端末が要求するデータ同一性もしくはデータ更新頻度が異なり得る。例えば、WiFi接続している端末においては、株式相場の生中継提供サービスを利用することができるが、ＧＰＲＳ接続している端末においては、パケット数に応じて課金されるため、株式情報は一日の終わりに一回のみ更新する、という場合が考えられる。

通信環境の時間的変動には、接続状態の変動とサーバ負荷の変動という要素が含まれ得る。例えば、通信環境の異なるエリアを移動する端末においては、キャッシュ方法の選択の変更を望むこともあるし、負荷状態が変動するサーバにおいては、クライアントのアクセス率を調整したい場合も想定される。

以下、アプリケーションオブジェクトを最適化して動的にクライアント装置に適応させるリプレットシステムについて説明する。このリプレットシステムは、クライアント装置、アプリケーション、およびサーバが、自身の属性と明示の実行機能とを特定するためのメカニズムを包含する。通常、異なるエンティティからの属性情報と機能情報は、競合するか、または一部のみ合致する。例えば、現在のサーバ負荷およびクライアントの挙動によっては、サービス応答に対する許容可能な遅延に関して属性が異なる場合がある。本発明のリプレットシステムにおいては、これを解決するため、異なるエンティティからの属性情報および機能情報を収集したのち統合し、競合が生じないようにする。なお、以下の記載においては、属性情報と機能情報とを一括して「機能属性情報」（またはＣＰＩ）と称する場合がある。

図１は、サーバサイドコードユニットを用いたアプリケーションの適応レプリケーション処理を例示したフロー図である。同図に示す処理は、ハードウェア（回路、専用ロジック等）またはソフトウェア（汎用のコンピュータシステムまたは専用の機器等で実行されるもの）、若しくはこれらの組み合わせから構成された処理ロジックによって実行される。

同図に示すように、この処理において、まず、処理ロジックが、アプリケーション、クライアント装置、およびサーバの各々に係る実行機能属性情報を収集する（ステップＳ１０１）。次に、処理ロジックは、サーバからクライアント装置へ、取得したクライアント実行機能属性情報とサーバ実行機能属性情報とアプリケーション実行属性情報とに基づいて、少なくとも一つのアプリケーションサービスオブジェクトのレプリケーションを指示する（ステップＳ１０２）。

属性機能サービスは、リプレットのレプリケーション処理に係るカスタマイズ度および適応度を決定するにあたっての基礎的な情報を提供する。好ましい態様において、リプレットの呼出しは、実行機能情報を用いて決定オブジェクトを起動し、各サービス要求に対し、端末においてレプリケーションされたウェブ関連アプリケーションロジックまたは当該アプリケーションロジックに対応したサーバ上のアプリケーションロジックを呼出すか否かの決定を行う決定してもよい。このような決定オブジェクトを、クライアントサイド呼出しヘルパ（ＣＩＨ）およびサーバサイド呼出しヘルバ（ＳＩＨ）と呼び、属性によって定義する。すなわち、その属性は、クライアント装置、サーバ、もしくはアプリケーションの属性に依存する。

ＣＩＨは、例えば、決定オブジェクトであって、クライアントレプリカとサーバレプリカを呼び出す時間のうちで予測応答時間が小さい方を選択する。一方、ＳＩＨは、例えば決定オブジェクトであって、サーバ負荷が閾値を越えない限度において、常にサーバレプリカを選択する。なお、クライアントレプリカおよびサーバレプリカとは、それぞれ、クライアント側およびサーバ側にあるレプリカのことである。

好ましい態様において、リプレットシステムにおけるアプリケーションデータの同期には、属性から得られた同期ヘルパ（ＳＨ）に照会して、クラインアント端末でレプリケーションされたアプリケーションデータを同期させるタイミングの決定、または連続アクセスに対応するために当該アプリケーションデータのサーバ側コピーをロックするか否かの決定、を行う処理が含まれる。ＳＨの一例としては、一定期間（例えば、一日または一週間）、アプリケーションデータの同期が行われていない場合のみデータ同期を促す動作を行うものが考えられる。

このように、リプレットおよびリプレットシステムを使用することにより、多様な機能を有する端末に対応することができる。具体的には、端末の機能情報およびアプリケーションの特性を用いて、レプリケーションを実行する端末を選択するとともに、最適化された呼出し方法および同期方法を各端末に特定させることにより、アプリケーションにおけるニーズ、サーバにおけるニーズ、およびユーザのニーズ間の競合を解決する。さらに、リプレットシステムにおいては、実行機能を解析して呼出し処理および同期処理を動的に設定することで通信環境の変化に対応する。これにより、変動する通信環境の変化に起因する問題が解決される。

［Ｂ．詳細部］
以下、システムの各部について更に詳細な説明を行う。しかしながら、本発明は以下の記載に限定されるものではない。なお、本発明の説明が茫漠となるのを避けるため、既知の構造や装置にあっては、その詳細は明示せず、ブロック図の形式で表現することとする。

また、以下では、コンピュータのメモリ内のデータビットに対する処理に関する記述があるが、これらは、アルゴリズム的およびシンボリック表記の観点から記述される場合がある。これらのアルゴリズム的な記述／表記は、データ処理技術分野に係る当業者が、その処理内容を他の当業者に最も効率的に伝えるために用いる手段である。ここでアルゴリズムとは、一般的に、所望の結果を得るための一貫した一連の処理ステップのことを指す。また、処理ステップとは、物理的な量の物理的な操作を必要とするものである。通常は、必ずしもそうではないが、この物理量は、電気的または磁気的信号の形態であって、記憶され、入出力され、比較され、加算され、その他の演算処理が行われるものをいう。このような信号は、しばしば、便宜上、主として一般的に用いられているという理由から、ビット、値、要素、シンボル、キャラクタ、ターム、数等と呼ばれる。これらの全ておよび同様の用語は、適切な物理量であって、これらの量に付される単なる便宜上のラベルにすぎない。以下、特に記載のない限り、「処理」、「コンピュータ処理」、「演算」、「決定」、「表示」等の用語は、コンピュータシステムやこれに類する電子計算装置、送信装置、あるいは表示装置における作用およびプロセスのことを指す。ここで、「これに類する電子計算装置」とは、コンピュータシステムのレジスタおよびメモリ内において物理的（電子的）な量として表されるデータを加工し、または当該コンピュータシステムのメモリ、レジスタ、その他の情報格納装置内にある物理的な量として表される他のデータに変換する装置のことを指す。

本発明は、また、適応レプリケーションを実行するための装置を提供する。本発明に係る装置は、必要な目的に応じて特別に構成される物であっても良いし、コンピュータプログラムによって選択的に起動または再構成される汎用のコンピュータから構成することも可能である。そのようなコンピュータプログラムは、コンピュータ読み取り可能な記録媒体に格納されていてもよい。例えば、磁気光学ディスク、ＣＤ−ＲＯＭ、ＲＯＭ（read-only memory）、ＲＡＭ（random access memory）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、光学カード、その他の電子的指令を格納するための媒体であって、バスを介してコンピュータシステムと接続されて使用される。

本発明に係るアルゴリズムおよび表示装置は、特定のコンピュータや他の装置に依存するものではない。種々の汎用システムに、本発明に係るレプリケーション技術に従ったプログラムを動作させることも可能である。その一方で、処理ステップを実行させるための特別の装置を構築したほうが利便性が高い場合もあり得る。以下に、種々のシステムに要求される構成を説明する。また、本発明は特定のプログラミングに依存することがない。すなわち、種々のプログラミング言語に本発明の方法を実装することが可能である。

コンピュータ読み取り可能な媒体は、コンピュータ等の電子機器が読み取ることができる形式で、情報の書込みまたは読出しを行うメカニズムを備えている。記録媒体とは、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）、磁気ディスク記録媒体、光学記録媒体、フラッシュメモリ、あるいは電気的、光学的、音響的その他の方式の伝送信号（搬送波、赤外線信号、デジタル信号等）である。

＜１．リプレットシステムの概要＞
（１）リプレットモデル
本発明に係るリプレットモデルは、サーバサイドコードユニットを用いるアプリケーションに適用可能である。リプレットモデルは、サーブレットを用いたウェブサーバ拡張技術に基づいて構成されてもよい。この場合、リプレットは、モビリティおよびレプリケーションのための拡張機能を備えたサーブレットとして捉えることもできる。リプレットとは、複製可能なオブジェクトであって、サーバに実装される複製可能なサービスの一部である。複製可能なサービスは、一または複数のリプレットから構成されるが、複製不可能なオブジェクトを含んでいても構わない。
複製可能なサービスに係るリプレットの各々は、当該複製可能なサービスの一つのサービスインタフェースを表す。リプレットは、クライアントからの要求を処理し、当該要求に応じた結果を出力する。各リプレットは、サーバに存在するレプリカ（以下、「プライマリレプリカ」または「サーバレプリカ」という）と、クライアント装置に存在するその他のレプリカ（以下、「クライアントレプリカ」という）の複数のレプリカから構成される。一見すると、リプレットはサーブレットと同じのように思えるが、クライアント装置に自身の複製を置き、要求をローカルに処理することができる点において両者は異なる。なお、サーブレット技術の詳細については、サン・マイクロシステムズ社のホームページ「 HYPERLINK "http://java.sun.com/products/servlet/" http://java.sun.com/products/servlet/」等に解説がある。

リプレットは、リプレットエンジン（ＲＥ；レプリケーションをサポートするエンジンのことを指す）上で実行される。これは、サーブレットがサーブレットコンテナ上で実行されるのと似ている。しかしながら、リプレット、またはアプリケーション（例えば、ウェブアプリケーション）を構成するリプレットグループは、当該リプレットにアクセスするアプリケーションを効率的に処理するために、一のＲＥから他のＲＥへ移動若しくは複製される点において、サーブレットとは相違する。また、各リプレットは、ホスティングサーバを有するサーブレットと同様のオーナーリプレットエンジンを有している。しかしながら、リプレットは、オーナーＲＥ以外のＲＥ上に存在して実行され得る点において、サーブレットと相違する。アプリケーションに係るクライアントは、当該アプリケーションによって使用される複数のリプレットをサーバ側から抽出し、抽出したリプレットをローカルに格納する。当該アプリケーションによって当該複数のリプレットのうちの一のリプレットが呼び出されると、サーバ側に存在する当該リプレットのオリジナルコピーの替わりに、該格納されたコピーが呼び出されるのである。

好ましい態様において、一つのリプレットは３つの要素から構成される。すなわち、クラス、読出し専用データ、および書換え可能状態である。書換え可能状態には、一時的状態と永続的状態とが含まれる。インストール時において、所望のホストにおいて利用可能なリプレットのクラスおよび読出し専用データが生成される。クラスおよびデータは、アプリケーションの実行前にロードされてもよいし、クライアントレプリカのインストール時にロードされてもよいし、あるいは必要に応じてインストールされてもよい。また、他のアプリケーションが必要とするまで、クラスおよびデータをキャッシュメモリに格納してもよい。

図２に、リプレットサーバレプリカの構成を示す。同図に示すように、リプレットレプリカ２０１は、コード２０３、書換え不可データ２０５、書換え可能データ２０２および２０４から構成されている。好ましい態様において、コード２０３はウェブ関連アプリケーションロジックを定義するクラスファイルを含んでおり、これは同一リプレットに係る他の全てのレプリカにも含まれているものである。しかしながら、書換え可能データ２０２および２０４、書換え不可データ２０５（メモリ内のオブジェクト、ファイル、および、クライアントのニーズに合わせたレコードおよび属性を備えた移動データベーステーブル、の組み合わせであってもよい）に関しては、一般に、クライアントレプリカによってデータ内容は異なり、さらに、クライアントとサーバレプリカでもデータ内容は異なる。例えば、クライアントレプリカは、フィルタリングされたデータベーステーブルの列を有し、その列はクライアントレプリカ毎に異なるものであってもよい。レプリカ内の書換え可能データ２０２および２０４は、クライアントによって書換えられることが可能なものであって、公開データ部２０２と非公開データ部２０４とにさらに分けることができる。公開データ部２０２は複数のクライアントによって共有され、従って、サーバレプリカおよび他のクライアントレプリカがアクセスすることが可能なデータである。一方、非公開データ部２０４は、クライアントに固有なデータであり、アクセスできるのは当該クライアントレプリカおよびそのサーバレプリカに限られる。

好ましい態様において、あるクライアント装置上のクライアントレプリカは、当該クライアント装置にかかる非公開書換え可能データを有している点でのみ異なっていてもよい。

図３は、サーバレプリカの状態遷移図を例示したものである。ある時刻、あるクライアントに対し、サーバレプリカは、次の３つの状態のうちの必ずいずれか一つをとる。３つの状態とは、アプリケーション同期状態３０１、クライアント同期状態３０２、および呼出し状態３０３である。

アプリケーション同期状態３０１において、サーバレプリカは最新の公開書換え可能データを有しているが、クライアントの最新の非公開書換え可能データを有していない。なお、サーバレプリカは、サービス要求に応じて、呼出し状態３０３からアプリケーション同期状態３０１へ移行する。

クライアント同期状態３０２において、サーバレプリカは、あるクライアントに対して、公開書換え可能データの複製と非公開書換え可能データの複製とを同期させる。なお、サーバレプリカは、アプリケーション同期状態３０１からクライアント同期状態３０２へ移行する。

呼出し状態３０３において、サーバレプリカは、クライアント状態３０１にあったが、クライアントからの要求にこたえるために選択され、呼出し処理が実行されている。すなわち、サーバレプリカは、サービス要求に応じて、クライアント同期状態３０２から呼出し状態３０３へ移行する。

ここで、サーバレプリカは、一のクライアントに対してはクライアント同期状態３０２にあり、他のクライアントに対してはアプリケーション同期状態３０１にある、という場合もあり得る。

一方、クライアントレプリカは、好適な態様において、上述した３つの状態に加えてもう一つの状態（以下、選択状態という）を有している。選択状態とは、当該クライアントレプリカにコードおよびデータが未だ供給されていない状態、または供給された場合であって当該コードおよび当該データが他のアプリケーションのレプリケーションを許可するために既に移動された状態である。図４は、クライアントレプリカの状態遷移図を例示したものである。同図に示すように、サーバレプリカは、呼出しが行われると、呼出し状態３０３からアプリケーション同期状態３０１へ移行する一方、クライアントレプリカは、サービス要求に応じて、呼出し状態４０３からクライアント同期状態４０２へ移行する。

同図に示すように、クライアントレプリカは、サービス要求に応じて、アプリケーション同期状態４０１から呼出し状態４０３へ移行する。そして、クライアントレプリカは、サービス要求に応じて、呼出し状態４０３からクライアント同期状態４０２へ移行する。そして、公開書換え可能データと同期すると、クライアント同期状態４０２からアプケーション同期状態４０３へ移行するのである。

クライアント同期状態４０２において、クライアントレプリカは、キャッシュフラッシュによって選択状態４０４へ移行する。このキャッシュフラッシュは、クライアントレプリカを強制的に非アクティブにさせる際に行われる。クライアントレプリカは、一度、選択状態４０４に移行すると、自身が内包しているデータに応じてクライアント同期状態４０２へ移行する。これについては後述する。

リプレット内のレプリカは、リプレットアリーナ内に存在する。図５は、リプレットアリーナを例示したものである。リプレットアリーナとは、複数の異なるアプリケーションに係るレプリカの実行環境である。リプレットアリーナに存在するレプリカは、あるアプリケーションに係るサーバレプリカか、または当該アプリケーションに係るクライアントレプリカのいずれかである。

図５に示すように、リプレットアリーナ５００は、サービスエンジンラッパ（wrapper）５０５と、属性マネージャ５０３と、機能マネージャ５０４と、レプリケーションマネージャ５０１とから構成される。

サービスエンジンラッパ５０５は、サービスエンジンインタフェースをサービスエンジン５１０（例えば、トムキャット（Tomcat）等のサーブレットサーバ）に実装し、リプレットアリーナ５００によって選択された外部サービスエンジンの代行コンポーネントである。サービスエンジンラッパ５０５のサービスエンジンインタフェースは、サービスの配置・削除方法、および特定のサービス要求のためのサービスコンテナを取得して、当該要求を処理する方法を定義する。好ましい態様において、サービスエンジンインタフェースは、全てのリプレットアリーナにおいて同じであるが、リプレットアリーナが実行するサービスエンジンが異なれば、使用するサービスエンジンラッパも異なる。例えば、デスクトップコンピュータにて実行されている一つのリプレットにはJakarta Tomcatに対応するサービスエンジンラッパを用いる一方、ＰＤＡで実行されている他のリプレットには、Jettyに対応する３００ＫＢにも満たないコンパクトなラッパを使用してもよい。なお、Jakarta TomcatおよびJettyについては、それぞれ「Apache Software Foundation. The Apache Jakarta Project. http://jakarta.apache.org/tomcat/」および「Jetty:// Web Server & Servlet Container. HYPERLINK "http://jetty.mortbay.com/jetty/index.html" http://jetty.mortbay.com/jetty/index.html」を参照されたい。

属性マネージャ５０３および機能マネージャ５０４を用いてそれぞれ行われる属性管理および機能管理においては、レプリケーションマネージャ５０１がレプリケーション処理を指示するため使用する情報が提供される。ここでレプリケーション処理とは、レプリケーションを行うクライアント装置の選択、および端末へのコードおよびデータの供給から始まって、レプリカ間の同期処理および要求を処理するための同期されたレプリカの選択処理までの一連の処理が全て含まれる。

＜２．機能属性管理＞
リプレットは、機能属性情報を用いて、レプリケーション処理を指示する。ここで機能とは、実行時に収集若しくは推定される状態情報の集合である。状態情報とは、例えば、使用可能なメモリ領域や推定応答時間である。一方、属性とはプロパティの集合である。属性情報は、アプリケーションサーバ、ユーザ、あるいはアプリケーションによって予め特定される設定項目から構成される。例えば、要求されるメモリ量、所望の応答時間である。リプレットマネージャは、属性情報と機能情報とを比較し、どのレプリカを使用するべきか、あるいはレプリカをサーバからダウンロードすべきか否かを決定する。なお、機能属性管理とは、機能管理と属性管理をまとめた概念である。

（１）属性管理
属性は、複数のパーティ（エンティティ）によって定義され使用される。好ましい態様において、３つのエンティティ（「役割」または「ロール」ともいう）、すなわちクライアント、サーバ、アプリケーションが、共同して属性を決定する。ここで「役割」とは、アクセス権に関して同一の属性を有する複数のエンティティの集合のことである。各エンティティの有する属性は、一般的には、他のエンティティのそれとは競合するか、または一部のみ整合する。例えば、あるユーザは、アプリケーションに関して１０秒以内にサービス応答を要求する一方、当該アプリケーションは許容応答時間を１５秒であると見積もっている、という場合である。この属性管理においては、属性マネージャによって実行され、異なる「役割」から、本質的に競合する一部の属性を統合して、一つのグローバル属性を生成する。なお、レプリケーションマネージャ５０１に属性マネージャの機能を持たせてもよい。

属性は、属性決定ポリシの基準における競合を解決することによって生成される。属性決定ポリシは、複数の「役割」の集合として定義され、各「役割」は「基準」と最大属性とを有している。各「役割」に係る「基準」は、属性決定ポリシが生成されるときに所定の値に設定されるが、後に変更することも可能である。

ここで「基準」とは、基準項目の集合である。基準項目とは、＜プロパティ、優先順位＞の対であって、優先順位とは番号である。具体的には、各プロパティ名Ｎに対し、各々が同一のプロパティ名を有する基準項目を含んでいる複数の「基準」が存在し得る。これら複数の基準のうち、有効優先順位の最も高いものが選択され、そのプロパティが属性に加えられるのである。ここで、基準Ｇに対する基準項目ＧＩの有効優先順位とは、基準Ｇの最大優先順位と選択されたＧＩの優先順位のうちの低い方のことである。

好ましい態様において、属性決定ポリシが生成されると、各「役割」に対して、アプリケーションが選択した秘密識別子（６４ビットの整数として実装される）が属性決定ポリシに格納される。この識別子を用いてアクセス制御が行われる。具体的には、適切な識別子が供給されたときのみ属性決定ポリシにアクセスすることが可能となる。

属性は、実行時に、属性決定ポリシにおける「役割」の「基準」を置き換えるか、あるいは、「基準」の項目を追加または置換することにより変更することができる。前者の場合は、上述した属性決定処理が新たに行われ、この結果、新たな属性が生成されることになる。後者の場合は、特定の属性項目についてのみ属性の決定が行われることになる。

他の要素については、いわば、属性の変更の聞き手として設定することが可能である。具体的には、属性が再構成されると、対象となるパーティに通知が行き、当該変更に対して反応する機会が与えられる。これにより、レプリケーションステムを再構築することが可能となる。

機能プロファイラは、プロファイル情報を交換する。適応レプリケーション属性における特別のプロパティは、ヘルパプロパティである。このヘルパプロパティの値は、自身のクラスがヘルパインタフェースを実装するオブジェクトである。ここでヘルパとは、レプリケーションシステムが実行時に行う決定を補助するオブジェクトのことである。各ヘルパは、プリファイリングデータ、ポリシ、およびリプレットをパラメータとして用いるインタフェース方式を実装し、候補情報および当該候補情報に対する信頼度を、異なる決定タイプに対して提供する。適応ヘルパは、サービス要求があると、クライアントレプリカまたはサーバレプリカを用いて、選択候補を返す。図６は、サーバ側の呼出しヘルパを実装するための、サーバ側の適応選択候補生成用コードの一例を示したものである。適応ヘルパを実装するためのクライアント側のコードの一例については、図７に示す。

図８は、適応ヘルパの実装例を示すフロ−チャートである。なお、適応ヘルパは、ハードウェア（回路、専用ロジック等）から構成される処理ロジックに実装してもよいし、ソフトウェア（汎用コンピュータシステムまたは専用コンピュータ上で動作するもの）に実装されてもよいし、若しくは両者の組み合わせであってもよい。図８に示すように、処理ロジックは、まず、待ち時間閾値（ＷＴＴ）、（ステップ８０１）、スラッシング係数（ＴＦ）（ステップ８０２）、および分散閾値（ステップ８０３）を初期化し、続いてクライアントサービスコスト（ＣＳＣ）を予測する（ステップ８０４）。続いて、処理ロジックはサーバサービスコスト（ＳＳＣ）を予測する（ステップ８０５）。次に、処理ロジックは送信コストを予測する（ステップ８０６）。

処理ロジックは、クライアントレプリカがアクティブ（起動中）であるか否かを判定する（ステップ８０７）。クライアントレプリカがアクティブである場合は、処理はステップ８０８へ移り、処理ロジックは、当該クライアントサービスコストが待ち時間閾値よりも小さいか否かを確かめる。クライアントサービスコストが待ち時間閾値よりも小さい場合、処理ロジックは、サービスコストを当該待ち時間閾値で除した値を１から減じて得られる値と同じ値の信頼度を有するクライアントレプリカを用いることを決定し（ステップ８０９）、処理は終了する。

クライアントサービスコストが待ち時間閾値以上である場合は、処理ロジックは同期コスト（ＳＹＮＣＣ）を予測し（ステップ８１０）、当該同期コストとサーバサービスコストと送信コストの加算値にスラッシング係数を乗じて得られる値が、クライアントコスト以下であるか否かを判定する（ステップ８１１）。判定結果が肯定的であった場合は、処理ロジックは、１から同期コストとサーバサービスコストと送信コストの加算値に対しスラッシング係数を乗じたものをクライアントサービスコストで除した値を１から減じて得られた値と同じ値の信頼度を持つサーバレプリカを用いることを決定し（ステップ８１２）、処理を終了する。ステップ８１１における判定結果が否定的な場合は、処理ロジックは、処理はステップ８１３へ移行し、上記値の信頼度を持つクライアントレプリカを用いることを決定し、処理を終える。

クライアントレプリカが起動されていない場合、処理ロジックはサーバサービス時間偏差を予測し（ステップ８１４）、サーバサービスコストと送信コストを加えたものが待ち時間閾値よりも小さく、且つサーバサービス時間偏差が偏差閾値よりも小さいかを判定する（ステップ８１５）。判定結果が肯定的である場合、処理ロジックはステップ８１６へ移行し、サーバサービスコストと送信コストを加えた値を待ち閾値時間で除した値を１から減じて得られた値に等しい信頼度をもつサーバレプリカを使用することを決定する。判定結果が否定的である場合、処理ロジックは処理ステップ８１７へ移行し、起動（アクティブ化）コストを予測する。

起動コストを予測した後、処理ロジックは、マーブレットがインストールされているかを確かめる（ステップ８１８）。インストールされていない場合は、処理ロジックは、予測インストールコストを予測起動コストに加え（ステップ８１９）、処理をステップ８２０へ進める。ステップ８２０において、処理ロジックは予測起動コストにクライアントサービスコストを加えた値が、待ち時間閾値よりも小さいかを判定する。この判定が肯定的である場合は、処理ロジックは起動コストとクライアントサービスコストを加えた値を待ち時間閾値で除した値を１から減じて得られる値に等しい信頼度をもつクライアントレプリカを使用することを決定し（ステップ８２１）、処理を終了する。

ステップ８２０の判定結果が否定的な場合は、送信コストとサーバサービスコストとの加算値が、予測起動コストとクライアントサービスコストの加算値をスラッシング係数で乗じて得られる値よりも小さいか否かを判定する（ステップ８２２）。この判定結果が肯定的である場合、処理ロジックはステップ８２３へ進み、送信コストとサーバサービスコストとの加算値を予測起動コストとクライアントサービスコストとの積で除した値を、１から減じて得られた値と等しい信頼度をウもつサーバレプリカを使用することを決定し、処理を終える。ステップ８２２の判定結果が否定的である場合は、処理はステップ８２４へ進み、起動コストとクライアントサービスコストとの加算値にスラッシング係数を乗じ、これを送信コストとサーバサービスコストとの加算値で除し、この値を１から減じて得られた値と等しい信頼度を有するクライアントレプリカを使用することを決定し、処理を終える。

属性管理に使用するためのコードの例を図９に示す。好ましい態様において、一のリプレットに係る各レプリカに対し、リプレットレプリケーション属性には２つのバーションが存在する。すなわち、サーバサイドバージョンとクライアントサイドバージョンである。サーバサイドバージョンは、サーバホスト基準およびアプリケーション基準を有している。これに対しクライアントサイドバージョンは、クライアントホスト基準およびユーザ基準を有している。クライアントからアプリケーションの要求があると、クライアントユーザ基準とサーバサイドアプリケーション基準との交換が行われ、サーバ側およびクライアント側の両者が、ホスト基準、アプリケーション基準およびユーザ基準を共有する状態にする。実行時のポリシは、これらの基準によって決定される。

図１０は、属性管理の動作の一例を模式的に表したものである。各エンティティは、部分属性の集合から構成される部分属性を特定する。好ましい態様において、部分属性は、＜プロパティ、優先順位＞の形で与えられる。このプロパティは通常の意味でのプロパティであり、優先順位は優先度を示す番号である。各プロパティは、＜名称、値＞の形で与えられる。名称とは文字列であり、値とは任意のオブジェクトである。例えば、端末属性６０１における＜＜応答時間、１０秒＞、８＞は、端末が希望する応答時間が１０秒以内であって、その優先順位レベルが「８」である、ということを意味している。

グローバル属性を決定するために、属性決定ポリシが用いられる。属性決定ポリシは、例えば、パフォーマンス決定テンプレートに実装される。図１０において、まず、部分プロパティ（ユーザのプロパティ、アプリケーションのプロパティ、またはサーバのプロパティが、属性決定テンプレート６０４によって評価される。属性決定テンプレート６０４は、各部分プロパティに対して最大優先度レベルを設定する。部分優先レベルが、当該テンプレートによって特定される最大優先レベルよりも大きな属性値を持っている場合は、当該部分プロパティは有効である判断される。例えば、アプリケーション属性６０２の応答時間は、その優先順位が（「６」）であり、これは最大優先順位（「５」）よりも大きいので、有効でないと判断される。

続いて、有効なプロパティをグローバル属性６０５に組み込む。プロパティ間に競合があった場合には、例えば、優先順位の高いもの値を採用してもよい。例えば、デバイス属性６０１とサーバ属性６０３とにおいて、２つの有効な応答時間属性がそれぞれ特定されることがあり得る。この場合、デバイス属性６０１の属性値（「８」）の方がサーバ属性６０３の属性値（「６」）よりも大きいので、デバイス属性６０１の属性値が採用されることになる。

好ましい態様において、属性マネージャは、端末、サーバおよびアプリケーションが共同してサービスオブジェクト実行環境を構築または再構築するためのメカニズムを提供する。これにより、端末およびサーバはアプリケーションの振る舞いを制御することが可能となり、また２つのサービス間で属性の交換を行うことが可能となる。

（２）機能管理
リプレットアリーナの機能サービスは、クライアント、サーバおよびアプリケーションの機能情報およびプロファイリング情報を保持する。機能情報は、機能プロファイラによって保持される。機能プロファイラは、デバイス機能、デバイス環境、およびアプリケーション状態（例えば、同期コスト）の検出判定手段としての役割を有し、サービス要求の処理応答時間およびトータル応答時間を予測する。

クライアント機能には、例えば、メモリ量または端末で利用可能な記憶装置、端末のＣＰＵの処理能力、利用できる必要最低限のコンパイラ、ダウンリンク／アップリンクの帯域幅、サーバまでのラウンドトリップ時間（ＲＴＴ）、が含まれる。サーバ機能には、当該サーバのＣＰＵ処理能力およびサーバの負荷が含まれる。アプリケーションプロファイリングデータには、ある種の典型的な端末における、記憶装置およびメモリの要求量、種々の典型的な端末における処理要求に対するコスト変動幅、計測した要求に対する応答時間、当該リプレットに係る現在のクライアントレプリカの数、ソフトウェア環境（例えば、特定のＪＡＲファイルを要求するのか等）に対するアプリケーションからの要求、が含まれる。

このような機能（または特徴データ）は、例えばインストールされているメモリ等であるが、これには静的なものと動的なもの（例えば、現在のサーバの負荷）とが存在する。動的な情報に対しては、機能プロファイラは、このような情報に対応する統計量、フィッティング、および予測のための多項式回帰ツールを備えている。この多項式回帰法は、フィッティングおよび予測の手段としてよく知られているものである。

機能情報は分散化されているため、クライアント側およびサーバ側のリプレットアリーナの機能管理（および属性管理）においては、互いが保有するローカル情報が交換されてグローバル機能情報が生成される。この交換の詳細は後述する。また、通知設計パターンを用いることにより、機能マネージャが、プログラムの他のコンポーネントによる個々の機能項目への書き込みを許可し、機能項目の値が変更された際に通知を受けるようにすることができる。

機能管理は、機能プロファイラによって実行される。好ましい態様において、機能プロファイラは、３種類のデータ、すなわち実行環境特性データ、レプリカ特性データ、およびユーザが知覚する応答時間のデータ（以下、単にユーザ応答時間データという場合がある）を評価する。

好ましい態様において、実行環境特性データには、サーバ側およびクライアント側におけるＣＰＵ使用率やラウンドトリップ時間が含まれ、さらに、各々にはその平均値および分散が含まれる。複数のネットワークが利用可能な場合、各ネットワークは実行環境特性データで表される。この実行環境特性データには、さらにクライアント側で使用可能な不揮発性メモリおよび揮発性メモリ、およびクライアントとサーバのＣＰＵ性能（ＯＰＳ（operations per second）、ＦＬＯＰＳ（floating operations per second）等で表される）が含まれていてもよい。

好ましい態様において、レプリカ特性データには、不揮発性メモリおよび揮発性メモリに対するレプリカの要求が含まれる。揮発メモリについては、レプリカ特性データには、その最大値、最小値、および平均値が含まれる。レプリカのＣＰＵ特性には、異なる負荷状態における、クライアント側およびサーバ側の両方において、計測されたサービス時間が含まれていてもよい。また、レプリカのデータアクセス特性は、リプレットとその背後にある永続的なデータオブジェクトとの間の相互作用を規定したものである。

好ましい態様において、ユーザ応答時間データは、要求がサーバに送信されてから応答が受信されるまでの時間に関する情報である。このデータには、クライアントレプリカが用いられる場合と、サーバレプリカが用いられる場合の２つの種類がある。

好ましい態様において、ＣＰＵ使用情報は、ＣＰＵ負荷検出手段によって、２つの連続したスレッド間の時間に基づき与えられる。このようにする理由は、Ｊａｖａスレッドは、同一の優先度をもつスレッドに対して非プリミティブだからである。スレッドがプロセッサの制御を生成する際、そのスレッドは実行準備ができているスレッドに対するキューの最後に置かれる、という事情があるからである。また、繰り返し制御を生成するだけのスレッドがある場合は、スレッドの処理が完了する（例えば、生成処理１００回）までに要した時間を測定することによって、プロセッサの負荷を定量化することができる。このスレッドスレッドが唯一のアクティブスレッドである場合、この負荷は小さい。しかしながら、優先順位を同じくする実行中のスレッドが多数ある場合が、負荷が大きくなる。従って、このような方法を用いて、効率的に、同一の優先順位のスレッドの平均待ち時間を計測することができるのである。

待ち時間およびサービス時間の予測情報は、多項式回帰法によって、ＣＰＵ使用情報と、利用回数履歴および利用時間履歴の組とに基づいて決定してもよい。

＜３．レプリケーション処理＞
リプレットの動的な移行は、当該リプレットに係る一または複数のレプリカの、インストール、アンインストール、アクティブ化若しくは非アクティブ化の時期及び場所を決定し、要求に対して呼び出すべきレプリカを決定する処理である。リプレットの適応レプリケーションは、通信接続状態が貧弱な移動端末ユーザに対しても有効であることが好ましい。このようなユーザは、サービス応答時間が長く、また応答時間ごとのばらつきも大きい。リプレットをローカルにクライアント端末へ移行することにより、応答時間および応答時間のばらつきは著しく減少し、これによりユーザの利便性が向上する。断続的な接続状態にあるクライアント端末に対し、リプレットレプリカをインストールすることができる。クライアント端末の接続が途切れたとき、ローカルなクライアントレプリカが起動されて使用される。クライアント端末がネットワークに再接続したとき、ローカルレプリカは終了し、オーナレプリカが使用される。このような処理の間、クライアント端末はネットワークへの接続が切れなかったものとして仮想的に取り扱われる。

また、リプレットの適応レプリケーションによって、サーバの高負荷に起因するサービスの低下をも防ぐことができる。サーバに高負荷が掛かっている際に、クライアントレプリカの選択・呼出しが行われた場合、およびサーバ負荷に著しい改善がみられた際に、クライアントレプリカに処理が再度引き渡された場合、サービス品質が著しく向上する。

レプリカを動的に選択するために、リプレットシステムは、環境パラメータを測定する機能プロファイラを有する。環境パラメータとは、例えば、ＣＰＵやネットワークのパフォーマンス、レプリカのメモリ特性、ＣＰＵ特性、および相互作用特性である。サーバ側機能プロファイラおよびクライアント側機能プロファイラは、プロファイリング情報を互いに交換し、クライアント側およびサーバ側の両者にて最新のグローバル情報を共有する。リプレットシステムは、また、デフォルトのポリシ取得を定義し、クライアントおよびアプリケーションのポリシを受け入れる、属性マネージャを有する。異なるパーティによって定義されたポリシは、統合されて一つの実行ポリシを生成する。なお、このように生成されたポリシは、実行中に変更することが可能である。最終的に、レプリケーションマネージャは、機能プロファイラから提供された情報と属性マネージャによって決定されたポリシとに基づき、レプリカのインストールおよび起動の時期を決定する。これにより、リプレットは、環境の変化およびアプリケーションの動作状況に逐次対応することが可能となる。

リプレットシステムにおけるレプリケーションマネージャは、リプレットのレプリケーション処理を管理する。レプリケーションマネージャは、属性マネージャおよび機能プロファイラからの情報に基づき、実行決定を行う。これにより、アプリケーションを、実行環境の変化やアプリケーション特性に適応させることが可能となる。

好ましい態様において、リプレットのレプリケーション処理は４つの段階から構成される。すなわち、（１）レプリケーションを実行する特定のクライアント装置を選択する（選択段階）、（２）選択したクライアント装置に、コードおよびデータを送信する（送信段階）、（３）レプリカを呼出す（呼出し段階）、（４）複数のレプリカ間における状態同期を確立する（同期段階）である。リプレットや典型的なレプリケーションシステムにおいては種々の態様が存在するが、その違いは、リプレットシステムにおけるレプリケーション処理が、クライアント、サーバ、およびアプリケーションの機能属性情報に依存しており、全体としての処理に自由度が存在することに起因するものである。

（１）レプリケーション端末の選択
上述した選択段階において、クライアント側およびサーバ側のリプレットアレーナに係るレプリケーションマネージャは、互いに協力して、そのクライアント端末が、サーバにインストールされたアプリケーションをレプリケ−ションすべき端末であるか否かを決定する。

クライアント側のレプリケーションマネージャは、サービスリモートサーバにおけるサービスに対するローカルクライアントからの全てのサービス要求を横取りする。ローカルにレプリケーションされていないサービスに対しては、レプリケーションマネージャは、ローカル属性（例えば、ローカルに定義された、クライアント部分属性およびデフォルトサーバ、およびアプリケーション部分属性）をチェックし、ローカルクライアントが、現在、リプレットのレプリケーションを許可しているか否かを判定する。許可されている場合、レプリケーションマネージャは、プロ−ブフラグをサーバに転送される要求に付加することができる。ここで、プローブフラグとは、クライアントがリプレットのレプリケーションを許可することを示すフラグである。

リプレットのレプリケーションに対応していないサーバは、当該リクエストに付加されたプローブフラグを無視する。これに対し、リプレットのレプリケーションをサポートしているサーバは、プローブフラグを受信すると、要求されているサービスに対するリプレットが、自身の複製の作成を許可しているか否かを判定する。許可している場合は、サーバは、サーバ部分属性、サーバ部分機能、アプリケーション部分属性、アプリケーション機能を、通常のサービス応答に付加して、当該クライアントに送り返す。さらに、この応答には、クライアントを区別するために後に用いられ、当該サーバからレプリケーションの許可を得た証拠としての機能を有する、クライアントＩＤが付加される。クライアントＩＤには、一定の有効期限が設けられていてもよい。また、この有効期限を属性に基づき決定してもよい。

クライアントにおいて、レプリケーションマネージャは、サーバＣＰＩ、アプリケーションＣＰＩ、クライアントＩＤとともに、応答を受信すると、リプレットのリソース要求（例えばメモリの使用量、ＣＰＵの使用量）と、当該リプレットがクライアント装置において利用可能なリソースとを比較し、当該クライアント装置が当該リプレットのレプリケーション用端末であるべきか否かを判定する。更に、サーバ部分属性およびアプリケーション部分属性を用いて、デフォルト値を書き換え、クライアント側における属性の決定が完了する。

（２）レプリケーション端末への送信処理
送信段階においては、まず、クライアントが、サーバに、ダウンロードしたプローブフラグを付加したサービス要求を送信する。なお、この送信段階の開始時期は、上述した選択段階の最後と、クライアントＩＤの有効期間との間の時間であるならば、任意である。クライアントは、この自由度を利用して、レプリケーションのための十分なリソースが確保された後、またはサーバに負荷がかからなくなった（レプリケーション実行可能になった）後、この送信段階を開始することができる。

サーバは、直ちに、要求されたコードおよびデータを当該クライアントに送る（通所のサービス応答とともに）か、あるいは一時的にクライアントの送信要求を拒否するか、を選択することができる。後者の場合、クライアントは、後に、再度、要求を送信することができる。送信されるコードおよびデータは、リプレット自身が指定することが可能であり、また、クライアントＩＤを用いて、更に、特定したクライアントへ送信すべきデータをカスタマイズすることも可能である。

好ましい態様において、クライアント端末が、レプリケーション端末選択プロトコルにおいてプッシュ先のエンドポイントを含ませた場合には、サーバは、サーバが適切と判断した時間において、当該要求コードおよびデータをサービス応答に付加するのではなく、要求コードおよびデータを非同期プッシュすることも可能である。プッシュ先のエンドポイントは、また、プッシュ型のデータ同期に用いられる。これについては後述する。

（３）サービス呼出し
送信段階の最後において、リプレットのクライアントレプリカが生成され、その状態はクライアント同期状態（すなわち、レプリカのクライアント固有の書換え可能データが最新である状態）に設定される。好ましい態様において、このクライアント同期状態にあるクライアントレプリカは、公開データをサーバに同期させることなく、クライアント非公開データにのみアクセスするサービス要求を処理することができる。

呼出し段階において、レプリケーションマネージャは、ローカルクライアントからのサービス要求を受け取ると、クライアント側呼出しヘルパ（ＣＩＨ）（属性マネージャが取得した属性から）を用いて、当該要求を処理するべき場所を決定する。具体的には、レプリケーションマネージャは、まず、ＣＩＨに場所決定に関する候補情報をもらう。

呼出しヘルパ（ＩＨ）が提供する候補情報には、好ましい態様において、２つのフィールドから構成されている。一つは、当該要求に対してクライアントレプリカまたはサーバレプリカのいずれかを使用するべきかに関する情報であり、もう一つは、この候補情報の信頼度である。この信頼度が属性により決定される閾値レベルよりも高い場合、この候補情報が採用される。この候補情報がクライアントレプリカの使用を指示する場合は、当該要求はローカルに処理される。クライアントレプリカの使用を指示しない場合は、レプリケーションマネージャは、当該要求をサーバに転送し、サーバからクライアントに帰ってくる応答を中継する。なお、転送要求とサーバから端末への応答とのいずれにおいても、当該クライアントの非公開データに対する同期情報が含まれていてもよい。

クライアントが自身では決定することができない場合、すなわちＣＩＨから提供された情報の信頼度が属性によって決定される閾値レベルよりも低い場合、レプリケーションマネージャは、当該要求に適応呼出しフラグを付加してサーバに転送する。この適応呼出しフラグは、当該要求を処理する場所を決定がサーバに委ねられることを表すものである。サービス要求を受信すると、サーバ側のレプリケーションマネージャは、サーバ側呼出しヘルパ（ＳＩＨ）に判断を求める。ＳＩＨの判断がサーバにおいて要求を処理することを示している場合、サーバレプリカが用いられる。それ以外の場合は、当該要求はクライアントへ送り返され、クライアントにて処理されることになる。

サービス呼出しにおいて重要なのは、呼び出すべき正しいレプリカをいかに選択するかということである。この選択は、例えば、特定のコストモデルに基づいて行ってもよい。しかしながら、コストモデルは、アプリケーション、クライアント端末、サーバによって異なるのが普通である。従って、予め最適なコストモデルを決めておくことはできない。

リプレットは、その属性管理により、自由度の高いコストモデルの枠組みを提供する。３つのエンティティの全て、すなわちクライアント端末、サーバ、アプリケーションは、その部分属性における特定のコストモデル（図６参照）を実装するＩＨクラスを特定することができる。属性管理は、部分属性をグローバル属性に組み込むことにより、どのヘルパクラスを用いるかを決定する。ＩＨは、選択されたコストモデルの実装にあたっては、レプリカ自身に加えて、属性およびプロファイルされた機能へアクセスすることができる。以下に、コストモデルの例を示す。

第１に、ユーザ応答時間に基くコストモデルがある。このモデルは、ＩＨがプロファイルされた機能を用いる場合に用いるのが好ましい。ここで、プロファイルされた機能には、クライアントレプリカとサーバレプリカを用いた場合の予測コストを比較するために必要な、過去に測定された要求処理時間、要求メッセージおよび応答メッセージのサイズ、およびネットワーク特性が含まれる。この場合、接続状態の異なるエリアを移動するクライアント端末に対し、このモデルを用いてユーザ利便性を改善することができる。

第２に、サーバ負荷に基づくコストモデルがある。このモデルは、サーバ負荷が閾値以上であって、ＳＩＨが適応呼出し要求を（更新されたサーバ負荷の推定量とともに）クライアントに返した場合に、用いるのが好ましい。この場合、対応するＣＩＨは、サーバ負荷予測手段を用いて現在のサーバの負荷を予測し、予測されたサーバ負荷が閾値よりも高い場合にクライアントレプリカを用いる。

第３に、サーバとクライアントとの間の通信トラフィック量に基づくコストモデルがある。このモデルにおいては、ＩＨが、要求メッセージおよび応答メッセージのサイズ、ＣＰＩ交換に要した時間、データ同期コストを含むプロファイルされたデータを使用する。こにれより、通信コスト削減要求に対応するレプリカが選択される。

リプレットレプリカが呼出された結果として、当該リプレットの書換え可能状態が変更されてもよい。このような変更が行われた場合、および複数の起動中のレプリカが同時に存在する場合は、整合制御メカニズムを用いて、アプリケーションが要求する整合レベルを保つように、リプレットのグローバル状態が調整される。

（４）データ同期
レプリケーション処理には、複数のレプリカ間におけるデータ同期が含まれる。レプリケーションシステムによって提供されるデフォルトの同期方法とは別に、アプリケーションに自身の同期方法を定義する許可を与えてもよい。ここでデフォルトの同期方法とは、サーバレプリカをロックし、クライアントがレプリケーション処理を終了したときに、（変更された）ＭＡＲファイルをクライアント端末へ送信する方法である。リプレットのレプリケーションによって、アプリケーションには、どのレプリカを同期処理の対象とするのか、どのレプリカを同期相手とするか、いつ同期を行うか、また、将来発生が想定される、更新に起因したレプリカ間の競合の問題をどのように取り扱うか、についての決定権が与えられる。

リプレットインタフェースは、各リプレットに、自身の書換え不可状態およびアプリケーションの書換え可能状態を指定することを許可してもよい。ここで、書換え不可状態とは、一般的には、クラスとリプレットが使用する読み出し専用データとによって指定されるものである。また、アプリケーションの書換え可能状態とは、あるレプリカのみに対し改変が許可され、その他のレプリカに対しては読み出しのみ許可される状態のことである。加えて、各レプリカは、セッション非公開状態を指定することができる。このセッション固有状態とは、特定のセッションにおいてのみ読み出し／書き込みが可能な状態のことである。セッション固有書換え可能状態をアプリケーション全体の書換え可能状態と区別することにより、リプレットのレプリケーションは、レプリカ間の同期をとる必要なく、各レプリカが自身のセッション固有書換え可能状態のみ変更する限りにおいて、複数のレプリカに対し、同時に、状態を変更することを許可する。

リプレットは、また、状態の同期を行う時期、および同期を行う相手の選択を制御する。好ましい態様においては、セッション固有状態は、一つのクライアントレプリカとこれに対応するサーバレプリカとの間でのみ共有されており、サーバレプリカのセッション状態は、クライアントレプリカのセッション状態が同期しているときは無効化されるので、クライアントレプリカが明示的な要求をしてローカルレプリカを無効化し同期情報をサーバに送信したときのみ、セッション状態の同期が起きる。どのアプリケーションのグローバル状態を同期するか、および同期相手をどうするかについて決定する際において、リプレットに複数の選択肢を与えてもよい。以下に、選択肢を例示する。

・リプレットは、クライアントレプリカがグローバル状態を読み出す必要が生じたときに、オプティミスティックレプリケーションまたはペシミスティックレプリケーションのいずれかを選択する。
・リプレットは、クライアントレプリカがグローバルアプリケーション状態に書き込むときに、高頻度更新（eager update）または低頻度更新（lazy update）のいずれかを選択する。
・リプレットのサーバレプリカは、クライアント装置への更新の通知に関し、プッシュ型もしくはプル型のいずれかを選択する。
・サーバからの更新通知においてプッシュ型が用いられた場合、クライアントレプリカは、プッシュ型同期を行うか否かを選択する。

サーバレプリカは、プッシュ型同期に参加しようとしているクライアントレプリカに更新を通知することのみ可能である。リプレットの適応レプリケーションにおいては、同期データを取得して正しいパーティへ引き渡す。同期データの解釈および潜在的競合の解決については、アプリケーション自体が担うことになる。

好ましい態様において、サービス呼出しは、レプリカの書換え可能データへ全くアクセスできないか、またはクライアント固有の書換え可能データの一部にのみアクセスできるにとどまるか、のいずれかである。この場合、複数のレプリカにおいて同一データへの同時アクセスがないので、同期および整合状態の保持が容易となる。

データ同期および整合性管理は、クライアントレプリカにおける呼出しがリプレットの公開データに対する読み込みまたは書き込みを行う際に、別々に実行してもよい。好ましい態様において、リプレットのレプリケーションの同期段階は、呼出し段階との関係において、２つの段階に分けられる。すなわち、呼出し段階前の読み出し段階と、呼出し段階後の書き込み段階である。これを図１１に示す。同図に示す処理は、ハードウェア（回路、専用ロジック等）から構成される処理ロジック、ソフトウェア（汎用コンピュータシステムまたは専用コンピュータにおいて実行されるもの）、もしくは両者の組み合わせによって実行される。

読出し段階において、クライアント側では、レプリケーションマネージャは、要求をローカルに処理することを決定すると、属性によって指定される同期ヘルパ（ＳＨ）のクライアント側の複製に対し、リプレットの公開データのうち最も最新のバーションのものをサーバレプリカから読み出すことが必要であるか否かを決定するよう命令する（ステップ１１０１）。

他方、サーバ側においては、読出し要求を受信すると、レプリケーションマネージャは、クライアント側ＳＨのサーバ側の複製に対し、同時アクセスを回避するため、当該サーバレプリカに対し書き込み制限（ロック）を適用することが必要か否かを決定する（ステップ１１０２）。ロックが必要と判断した場合は、レプリケーションマネージャは、ロックを行う（ステップ１１０３）。ロックには、所定の有効期間が設けられている。好ましい態様において、所定の有効期間とは、属性によって決定されても良い。各クライアントに対して一つの属性があるので、各クライアント装置は、それぞれ異なるＳＨを持つことができる。その後、レプリケーションマネージャは最新の状態に復帰する（ステップ１１０４）。

書き込み段階において、クライアント側では、リプレットの公開データを変更するクライアントレプリカを呼出すと（ステップ１１０５）、レプリケーションマネージャは、再度、ＳＨに対し、当該変更をサーバレプリカに直ちに送信する必要があるか否かについて確認するよう命令する（ステップ１１０６）。送信の必要がないと判定した場合は、レプリケーションマネージャは、サーバレプリカをロックするか否かを決定する（ステップ１１０９）。送信が必要であると判定した場合は、処理はステップ１１０７へ進む。

ステップ１１０７において、変更送信メッセージが受信されると、レプリケーションマネージャは，クライアントのＳＨに対し、更新による競合が起きていないかを確認し（ステップ１１０７）、起きている場合にはこの競合を解決するよう命令する（ステップ１１０８）。競合の解決においては、ＳＨとアプリケーションとに競合解決を処理するよう、要請してもよい。レプリケーションマネージャは、サーバレプリカがロックされているか否かを決定し（ステップ１１１０）、読出し段階においてクライアントがサーバレプリカを取得した場合は、レプリケーションマネージャは、サーバレプリカのロックを解除する（ステップ１１１１）。最後に、レプリケーションマネージャは、他のクライアントのＳＨに対し、当該変更をクライアント端末にプッシュする必要があるか否かを確認するよう命令する。

読出し段階および書き込み段階の開始は、呼出された方法において公開データの読み込みまたは書き込みが行われるかに依存する。当該方法において、公開データの読出しまたは書込みが行われない場合は、読出し段階または書き込み段階はそれぞれ省略される。

ＳＨは、属性の一部でもあり、クライアント、サーバ、アプリケーションのいずれかによって定義されてもよい。ＳＨを用いて実装することのできる整合性保持方法には、例えば、ペシミスティックレプリケーション、１/Ｋ同期を用いたオプティミスティックレプリケーション、プッシュ方式を採用したオプティミスティックレプリケーション等が存在する。ペシミスティックレプリケーションとは、まず、公開データの読み出をともなう呼出しの前にサーバレプリカをリフレッシュし、リフレッシュ後にサーバレプリカをロックし、更新の伝播およびロック解除ための呼出し後にサーバレプリカにアクセスする、ことを要求することによって、いわゆる単一コピー逐次化可能性（one-copy serializability）を実現するレプリケーション方法である。１／Ｋ同期によるオプティミスティックレプリケーションとは、データのリフレッシュおよび更新の伝播が、公開データにアクセスする呼出しがＫ回行われるごとに一回実行され、サーバレプリカをロックしないレプリケーション方法である。プッシュ方式のオプティミスティックレプリケーションとは、リプレットの公開データのフレッシュネスを維持するために、クライアントを、サーバからプッシュされた更新に依存させるレプリケーション方法である。

呼出し処理のごく一部が公開データへのアクセスを含む場合、あるいはデータ同期のオーバーヘッドが、要求メッセージおよび応答メッセージの送信と、サーバにおける当該要求の処理とに関連するオーバーヘッドよりも小さくなる場合、ペシミスティックレプリケーション方法は、実用的である。その他の整合性方法としては、例えば、クライアント機能と、自己再生するウェブコンテンツに対する現在のサーバ負荷と、一時的にデバイスがリロードできないようにするために、通常の高負荷の下でのサーバによって引き起こされる他の負荷とに基づいて、正しい更新レートを選択する方法がある。

＜４．変形例＞
リプレットシステムは、サービスオブジェクトとしてのサーブレットを用いたウェブアプリケーション用のJavaに実装されても良い。（アパッチ・ジャカルタプロジェクト（Apache Jakarta Project）のトムキャットサーブレットコンテナを、サービスエンジンとして用いてもよい。

また、リプレットアリーナは、スタンドアローン処理として実装しても良い。この場合、あるアプリケーションに対して、当該アプリケーションのためのサーバ側のリプレットアリーナは、サーブレット（およびリブレット）を実装するウェブサーバとして機能する。一方、クライアント側のリプレットアリーナは、ウェブブラウザのＨＴＴＰプロキシとして構成されてもよい。そして、サーバ側およびクライアント側のリプレットアリーナは、ＨＴＴＰプロトコルニ従って通信を行ってもよい。この場合、リプレットのレプリケーションプロトコルメッセージ（たとえば、種々のフラグ、ＣＰＩ、ＩＨから提供される情報情報、同期データ）のフィールドは、ＨＴＴＰ要求およびＨＴＴＰ応答におけるＨＴＴＰヘッダフィールドの形式で付加される。

好ましい態様において、リプレットは、Ｊ２ＥＥのＨＴＴＰサーブレットクラスを拡張し、リプレットインタフェースを実装する。リプレットインタフェースは、レプリケーションマネージャが、クライアント固有書換え不可および書換え可能データ（公開および非公開の両者を含む）を取得よび設定するために用いることのできる方法を指定してもよい。書換え可能データおよび書換え不可データとしては、メモリ内オブジェクト、ファイル、および（通常フィルタ処理された）データベーステーブルの組み合わせであってもよい。また、デフォルトの公開書換え可能データは、WEB-INF/classes and WEB-INF/libに属するものを除き、レプリケーション可能なサービスアプリケーションのウェブアーカイブファイル（ＷＡＲファイル）の全体を含んでいてもよい。これに対し、非公開書換え可能データは、クライアント用に生成されたＨＴＴＰセッションオブジェクトを含んでいてもよい。また、リプレットインタフェースは、同期のための更新を検出し実行してもよい。更新内容は、メモリ内オブジェクト、ファイル、テーブルを用いて表わされてもよい。また、デフォルトの実装においては、ウェブアーカイブファイル全体が更新されたものとみなしてもよい。

（１）非イントルーシブなレプリケーション
好ましい態様において、レプリケーション処理は、クライアントおよびサーバの両者に対して非イントルーシブである。介入性を生じさせる原因の一つは、送信段階にある。送信段階においては、リプレットシステムが、関連するコードおよびデータをサーバ側において収集し、これをコードおよびデータをクライアントに送信し、そのようなコードおよびデータをクライアント側で適切にインストールする必要があるからである。

既に負荷がかかっているサーバにおいて、特に、多数のクライアントから短い時間の間に送信要求が出されている場合は、上記の処理は負荷状態を悪化させることが予想される。一方、クライアント側にとっては、このような処理によって他の要求の応答性が劣化し、端末によっては、レプリカの受信およびインストールのコスト効率が低下する場合がある。これに対する解決策として、サーバに、サーバが適切な時間だと判断した場合のみ、クライアントへの送信を行う選択肢を与え、サーバにレプリカをクライアントに非同期プッシュする許可することが考えられる。これにより、２つの要求間における送信が発生した場合でも、それらを独立に（すなわち非イントルーシブに）処理することが可能となる。

（２）サーバ負荷情報
サーバ負荷を的確に予測するために用いる、変化するサーバ負荷情報の表現は、本発明に係るリプレットシステムにおいては重要である。それは、低コストでシステムのパフォーマンスを向上させることができるからである。これには、多項式回帰法を用いることができる。ここでサーバ負荷情報は、クライアントへの応答に付加することにより行うことができる。

（３）セッションの移行
セッションの移行は、クライアントセッションの途中でレプリケーションを実行するために必要であり、クライアント固有書換え可能データをクライアント端末へ送信する形態をデフォルトとする。これには、クッキーを用いたＨＴＴＰセッションを利用してもよい。セッションの移行中は、クライアント側のリプレットアリーナは、ローカルセッションクッキーおよび新たなセッションオブジェクトを生成する。この新たなセッションオブジェクトは、サーバセッションにおける元のセッションからコンテンツに提供され、当該新たに生成したクッキーはクライアントに返される。

（４）公開データへのアクセス命令
好ましい態様において、ＸＭＬ形式の外部命令を用いて、リプレットのＧＥＴメソッドおよびＰＯＳＴメソッドが、公開データの読出しおよび書き込みを行うことを示すことができる。しかしながら、リプレットは異なる種類のリクエストに対して用いられ得る。このようなリクエストには、公開データへのアクセスを要求するものもあれば要求しないものもある。このようなリクエストを区別するために、Ｊ２ＥＥサーブレットマッピングと同様な方法を採用する。各リクエストの種類は、仮想リプレットに割り当てられる。これらの仮想リプレットが、同一の実際のリプレットへマッピングしている間、公開データアクセス命令が各仮想リプレットに対して生成される。例えば、ウェブカレンダーアプリケーションにおいて、アポイントメントの閲覧中には、アポイントメントアクセス公開データは生成されない。同一のリプレットは、これらの生成処理および閲覧処理の２つの処理を行うことができるが、好ましい態様において、ＵＲＩは、異なるアクセス命令によって異なる仮想リプレットへのマッピングを行う。これにより、閲覧処理を常にクライアントレプリカ関しローカルに実行することが可能となる。

＜５．レプリケーションマネージャ＞
レプリケーションマネージャは、リプレットアリーナに存在する全てのリプレットレプリカについての、インストールおよびアンインストール、起動（アクティベーション）および終了（ディアクティベーション）、呼出しを制御する。レプリケーションマネージャは、例えば、以下のいずれかの条件が満たされたときに呼び出されてもよい。すなわち、タイムアウトが生じたとき、他のレプリケーションマネージャから送信されたメッセージを受信したとき、サービス要求を受信したとき、サービス応答を受信したとき、プロファイリングデータを収集したとき、ポリシ基準項目が更新されたとき、および状態の同期が行われたとき、である。

図１２は、サービス要求を受信した際に行われる処理を例示したフロー図である。レプリケ−ションマネージャは、呼出しがあると、正しいヘルパを特定し、当該ヘルパから候補情報を取得し、当該候補情報を後の参照のために格納する。しかしながら、ヘルパからの候補情報は、要求としてではなく参照としてのみ用いられる。換言すれば、候補情報は、アプリケーションの信頼度レベルについてのいわば助言にすぎない。

レプリケーションマネージャは、複数のアプリケーションを管理することができる。好ましい態様において、アプリケーションに対する最終決定は、グローバル履歴情報によって行われる。ここで、グローバル履歴情報とは、例えば、着目しているアプリケーションに関する現在の候補情報、候補情報履歴、決定、特性、およびこれ以外のアプリケーションに関する現在情報、候補情報履歴、決定、および特性を含む。

このように、履歴情報とグローバル情報とを統合する目的としては、例えば、同一のアプリケーションにおけるスラッシング（クライアントとサーバとの間においてレプリカが行き来すること）や、キャッシュ容量が全てのアプリケーションクライアントレプリカを維持するのに十分でない場合に発生する複数のアプリケーション間におけるスラッシングの回避、また、特定のアプリケーションに関してではなくシステム全体としての最適化の実現、が挙げられる。

図１２に示す処理は、処理ロジックによって実行される。ここで、処理ロジックは、例えば、ハードウェア（回路、専用ロジック等）、ソフトウェア（例えば、汎用コンピュータシステムまたは専用コンピュータ上で実行される処理ロジックによって実行されるもの）、若しくはこれらの組み合わせから構成される。この処理においては、まず、正しいヘルパ（例えば、マーブレットに対する適応コンサルタント）から供給された候補情報を探す（ステップＳ１２０１）。続いて、処理ロジックは、当該ヘルパの信用度を「Ｃｒ」に設定する（ステップＳ１２０２）。情報の信頼度をヘルパの信用度に乗じたものを「Ｃｆ」とする（ステップＳ１２０３）。そして、信頼度の閾値を「ＣＴ」に設定する（ステップＳ１２０４）。

続いて、処理ロジックは、信頼度Ｃｆが閾値ＣＴよりも大きいか否かを判定する（ステップＳ１２０５）。Ｃｆ＞ＣＴの場合は、当該情報がクライアントレプリカの使用を指示しているか否かを判定する（ステップＳ１２０６）。使用を指示していない場合は、処理はステップＳ１２１５へ進む。使用を指示している場合は、処理ロジックは、クライアントレプリカがアクティブになっているか否かを判定する（ステップＳ１２０８）。アクティブである場合は、処理はステップＳ１２１３へ進み、当該クライアントレプリカをローカルに実行する。

アクティブでない場合は、処理ロジックは当該クライアントレプリカがインストールされているか否かを判断する（ステップＳ１２０９）。インストールされている場合、起動要求を送信し（ステップＳ１２１１）、ステップＳ１２１２へ処理を進める。ステップＳ１２１２において、処理ロジックは当該起動が成功したかどうかを判定する。成功した場合、処理はステップＳ１２１３へ進み、当該クライアントレプリカをローカルに実行する。クライアントレプリカの実行後、処理はステップＳ１２１７へ進む。起動に失敗した場合は、処理はステップＳ１２１５へ進む。

信頼度の値が信頼度閾値よりも大きくない場合は（ステップＳ１２０５、Ｎ）、処理ロジックはステップＳ１２０７へ進み、サーバレプリカが起動されているか否かを判定する。起動されている場合は、処理ロジックは当該サーバレプリカを実行した後（ステップＳ１２１４）、ステップＳ１２１７へ処理を進める。サーバレプリカが起動されていない場合は、処理はステップＳ１２１５へ進む。

ステップＳ１２１５において、処理ロジックは、サービス要求をリモートサーバへ転送する。処理ロジックはリモートサーバからサービス応答を受信すると（ステップＳ１２１６）、サービス応答をコンテナに引き渡す（ステップＳ１２１７）。以上で処理が終了する。

＜６．レプリケーションマネージャ間のプロトコル＞
好ましい態様において、レプリケ−ションマネージャ間プロトコルは、クライアント側レプリケーションマネージャとサーバ側レプリケーションマネージャとの間の通信プロトコルを規定するものである。具体的には、このプロトコルは、下位層のトランスポートプロトコルとしてＨＴＴＰを用いる。レプリケーションマネージャ間プロトコルメッセージは、ＨＴＴＰヘッダフィールドとして送信される。図１３は、レプリケーションマネージャ間プロトコルを用いて、クライアントレプリケーションマネージャとサーバレプリケーションマネージャとの間の通信における５つのパターンを示したものである。

（１）クライアントからサーバへのサービス要求
好ましい態様において、クライアントがブラウザからの要求を受信すると、クライアントには２つの選択肢が与えられる。すなわち、その要求を直ちにローカルに処理するか、またはサービス要求メッセージをサーバに送信するか、である。クライアントは、リプレットにおいて起動されているレプリカがある場合であって、このローカルに起動されているレプリカを使用することを決定した場合にのみ、当該要求を直ちにローカルに処理することができる。これ以外の場合は全て（すなわち、クライアントがローカルに実行することを決定した場合であっても）、クライアントはサービス要求をサーバに送信する。サービス要求メッセージは、例えば、以下に示す情報を格納するフィールドを有する。

１．ブラウザからの要求（必須項目）
２．セッションＩＤ（クライアントが複数のセッションをサポートしてる場合に限る）（オプション項目）
３．クライアント側の決定およびクライアント側ヘルパの信頼度（オプション項目）
４．クライアント機能およびユーザ属性（オプション項目）
５．クライアント側レプリカの状態（オプション項目）
６．クライアントが把握している、サーバ機能、サーバ属性、およびアプリケーション属性（オプション項目）
７．アプリケーション同期データ（オプション項目）
８．セッション同期データ（オプション項目）
９．クライアントがサーバのプッシュを許可するか否かについて（オプション項目；ただし、デフォルトでは「許可しない」に設定される）

サーバは、サービス要求メッセージを受信すると、当該メッセージが上記フィールド１に格納される要求のみを含んでいる場合は、当該要求を直ちに処理する。

（２）クライアントからサーバへの同期要求
ローカルに起動しているレプリカを有するクライアントは、事前に（すなわち、要求をブラウザから受信するとともに）、そのレプリカの状態をサーバに同期させてもよい。好ましい態様において、これは以下の条件を充足した時に行われる。
・条件１：クライアントによるローカル処理が完了している
・条件２：クライアントレプリカが破棄されるようとしている（すなわち、インスタンス化状態から非インスタンス化状態へ遷移するとき）
・条件３：アプリケーションが自ら同期状態を要求したとき
・条件４：サーバが、状態同期を行うために「同期用プル」を用いたとき

（３）サービス要求に対する応答
サービス要求に対する応答とは、具体的には、サービス要求メッセージの応答として、サーバからクライアントに送信されたメッセージのことである。このメッセージの内容は、リプレットのサーバレプリカの実行結果であってもよいし、クライアントレプリカが、そのローカルレプリカを起動し要求をローカルに処理するために必要な情報を含んでいてもよい。

このメッセージは、例えば、以下の情報を格納するためのフィールドを有する。
１．このメッセージが実際のサービス応答であるか否かについて（必須項目）
２．実際のサービス応答（オプション項目）
３．サーバ機能（オプション項目）
４．アプリケーション属性およびサーバ属性（オプション項目）
５．同期データ（オプション項目）
なお、フィールド３、４、５は、フィールド２と併存可能である。

（４）サーバからクライアントへの同期用プル
サーバは、クライアントに対し、最新の状態情報を要求する。この際に用いられるメッセージは、例えば、以下の情報を格納するためのフィールドを有する。
１．サーバがアプリケーションに関する同期データに加え、セッション固有同期データを要求しているか否かを示すフラグ（必須項目）
２．サーバの動的機能（オプション項目）
３．サ−バ属性およびアプリケーション属性の更新（オプション項目）

（５）サーバからクライアントへ送信される同期用プッシュ
サーバは、同期データをクライアントへプッシュする。この際に用いるメッセージには、例えば、以下の情報を格納するためのフィールドが含まれる。
１．アプリケーションに関する同期データ
２．サーバの動的機能（オプション項目）
３．サ−バ属性およびアプリケーション属性の更新（オプション項目）

（６）機能属性情報の更新
サーバは、アクティブなレプリカを有しサーバのプッシュを許可しているクライアントに対し、新たなＣＰＩ情報をプッシュする。この際に用いられるメッセージには、例えば、以下の情報を格納するためのフィールドが含まれる。
１．サーバの動的機能（オプション項目）
２．サ−バ属性およびアプリケーション属性の更新（オプション項目）

＜７．適応コンサルタントインタフェース＞
図２２に、適応コンサルタントインタフェースの一例を示す。

＜８．システム全体＞
図１４は、移動端末、インターネット、およびサーバから構成される通信環境を示す図である。図１４に示すように、この通信環境においては、移動端末１４０１が、通信インタフェース１４２０を用いて、サーバ１４０３およびインターネット１４０２を介して接続する。他のソフトウェア１４１０、例えば、移動端末のウェブブラウザは、サービス呼出しインタフェース１４０１Ａおよびユーザ属性インタフェース１４０１Ｂを用いて、移動端末側レプリケーションシステム１４３０と情報の授受を行う。同様に、サーバ側においても、他のサーバ用ソフトウェア１４１１、例えばサーバ設定プログラムは、アプリケーションインタフェース１４０３Ａおよびサーバ属性インタフェース１４０３Ｂを介して、サーバ側レプリケーションシステム１４３１と情報の授受を行う。サーバ１４０３は、さらに、通信インタフェース１４２１を有しており、サーバ側レプリケーションシステム１４３１および他のサーバソフトウェア１４２１と情報の授受を行う。図示は省略しているが、移動端末１４０１およびサーバ１４０３は、必要なハードウェアおよびソフトウェアを備えて構成される。レプリケーションシステムに必要なハードウェア構成の一例を図２１に示しておく。

図１５は、図１４に示す移動端末側レプリケーションシステム１４３０を更に詳細に示したブロック図である。同図に示すように、移動端末には移動端末側レプリケーションマネージャ１５０１およびサービスエンジン１５０２が、移動端末レプリケーションシステムの一部として含まれる。移動端末側レプリケーションマネージャ１５０１は、呼出しインタフェース１５２１、属性インタフェース１５２２、機能インタフェース１５２３、および同期インタフェース１５２４を含む。呼出しインタフェース１５２１は、サービス呼出しインタフェース１５１１およびサービスエンジン１５０２から情報を受け取る。サービス呼出しインタフェース１５１１は、他の移動端末のソフトウェアから情報の授受を行う。同様に、属性インタフェース１５２２は、ユーザ属性インタフェース１５１２およびサービスエンジン１５０２から供給される情報を受け取る。ユーザ属性インタフェース１５１２は、他の移動端末ソフトウェアから供給される情報を受け取る。機能インタフェース１５２３および同期インタフェース１５２４は、サービスエンジン１５０２から供給される情報を受け取る。移動端末側レプリケーションマネージャ１５０１は、サービスエンジン１５０２と、サービスエンジンインタフェース１５１０を介して、情報の授受を行うとともに、ネットトワークインタフェースと通信を行う。

図１６は、図１４に示すサーバ側レプリケーションシステム１４３１を更に詳細に示した図である。図１６に示すサーバ側の構成は、図１５に示した携帯端末側レプリケーションシステムの構成と同様であるめ、説明を省略する。

図２１は、上述した移動端末１４０１およびサーバ１０４３を含む、本発明に係る一または複数の処理を実行することのできるコンピュータシステムを例示したブロック図である。コンピュータシステム２１００は、バス２１１１に接続された、情報を処理するためのプロセッサ２１１２を有する。プロセッサ２１１２は、Pentium（登録商標）プロセッサ、PowerPC（登録商標）プロセッサ、Alpha（登録商標）プロセッサ等のマイクロプロセッサから構成されるが、これらに限定されるものではない。

コンピュータシステム２１００は、更に、ＲＡＭ（random access memory）から構成される、プロセッサ２１１２に実行させるために情報および指示を格納する他の書き換え記憶装置２１０４（以下、メインメモリと称する）を有する。メインメモリ２１０４は、さらに、一時的変数または他のプロセッサによる命令の実行中に生成される暫定的な情報を格納するために用いてもよい。

コンピュータシステム２１００は、さらに、バス２１１１に接続された、ＲＯＭ（read only memory）から構成される、プロセッサ２１１２への静的な情報および命令を格納する他の書き換え不能に記憶する固定記憶装置２１０６と、情報および命令を記憶する、磁気ディスクまたは光学ディスクおよび対応するディスクドライブからなる大容量記憶装置２１０７とを有する。

コンピュータシステム２１００は、さらに、バス２１１１に接続された、ユーザに各種情報を提示するためのＣＲＴ（cathode ray tube）またはＬＣＤ（liquid crystal display）等の表示装置２１２１を有している。キーボード２１２２は、英数字キー等を備え、バス２１１１を介してプロサッセへ情報やコマンド等の供給を行う。これに加え、マウス、トラックパッド、スタイラスペン、カーソルキー等の、バス２１１１に接続された、方向情報の入力およびコマンド選択を行ってプロセッサ２１１２へ供給し、表示装置２１２１に表示されるカーソル動作を制御するための入力装置を有している。

加えて、バス２１１１には、命令、データその他の情報を、紙、フィルムその他の媒体に印刷するための印刷装置２１２４が接続されている。更に、スピーカへマイクロフォン等の音声録音／再生装置をバス２１１１に接続して、コンピュータシステム２１００と音声によるに入出力を実現することも可能である。これ以外にも、バス２１１１に、有線もしくは無線通信機能を有するモジュール２１２５を接続し、他の携帯電話やＰＤＡ等のハンドヘルドデバイスと通信を行うように構成することも可能である。

コンピュータシステム２１００の各部の全部または一部、および関連するハードウェアを本発明において用いることが可能である。しかしながら、本発明に使用するコンピュータシステムは、図２１に示すコンピュータシステム２１００に限定されるものではなく、上記以外の構成をとっても構わないし、上述した各部のうちの幾つかを含んでいてもよいことは言うまでもない。

＜９．プロトコル＞
図１７は、レプリケーション場所選択プロトコルにおける、レプリケーション場所の処理シーケンスを例示した図である。移動端末側のレプリケーションシステムにおいては、サービス要求を生成し（ステップＳ１７０１）、サーバ側レプリケーションシステムに送信される。この後、移動端末側のレプリケーションシステムは応答を待つ（ステップＳ１７１０）。サーバ側のレプリケーションシステムは、このサービス要求に応じてレプリケーションの許可を示す指示を生成し、サービス応答を移動端末側レプリケーションシステムに送信する（ステップＳ１７１１、Ｓ１７０２）。この後、移動体側のレプリケーションシステムは、当該移動端末でレプリケーションが可能サービスであることを確認し（ステップＳ１７１２）、レプリケーション要求をサーバ側のレプリケーションシステムに送信する（ステップＳ１７０３）、応答を待つ（ステップＳ１７１４）。移動端末側のレプリケーションシステムが応答を待っている間、サーバ側レプリケーションシステムは、レプリケーション場所となるべき移動端末を選択し、レプリケーション応答を生成して移動端末側のレプリケーションシステムへ送信する（ステップＳ１７０４）。

図１８は、レプリケーション提供プロトコルの一例を示したものである。同図に示すように、３つの独立した要求が移動端末側のレプリケーションシステムからサーバ側のレプリケーションシステムに送信される。この３つの要求とは、書換え不可データ要求、公開書換え可能データ要求、および非公開書換え可能データ要求である。これらの要求を各々送信すると、移動端末側レプリケーションシステムは、サーバ側のレプリケーションシステムからの応答を待つ。サーバ側のレプリケーションシステムは、書換え不可データ、公開書換え可能データ、および非公開書換え可能データを特定し、対応する応答を移動端末側プリケーションシステムに送信する。

図１９は、共同サービス呼出しプロトコルの一例を示したものである。同図に示すように、移動端末側のレプリケーションシステムは、共同サ−ビス呼出し要求をサーバ側レプリケーションシステムに送信し（ステップ１９０１）、応答を待つ。サーバ側のレプリケーションシステムは、クライアントレプリカまたはサーバレプリカのいずれかを選択し、共同呼出し結果を移動端末側のレプリケーションシステムに送信する（ステップ１９０２）。

図２０は、状態同期プロトコルの一例を示したものである。同図に示すように、移動端末側のレプリケーションシステムは、同期要求をサーバ側のレプリケーションシステムに送信し（ステップ２００１）、応答を待つ。サーバ側レプリケーションシステムは、状態を同期させ（ステップ２００５）、同期結果を移動端末側のレプリケーションシステム送信する（ステップ２００２）。

上述した各プロトコルは、図１３〜１５に示した移動端末側システムおよびサーバシステムにおいて用いてもよい。

＜１０．メッセージおよびデータ種類の定義＞
図２３に、メッセージおよびデータの種類の定義を示す。

以上、本発明の実施形態について説明したが、本発明の範囲は上述した実施形態の詳細に限定されるものではなく、本発明に対し種々の変形等を行うことが可能であることは言うまでもない。

本発明に係る、サーバサイドコードユニットを用いた適応レプリケーション処理を示すフロー図である。 リプレットサーバレプリカの概念図である。 クライアントレプリカの状態遷移図である。 サーバレプリカの状態遷移図である。 リプレットアリーナの概念図である。 適応ヘルパを実装するための、サーバ側の適応候補情報生成コードを例示した図である。 クライアント側の適応ヘルパを実装するためのコードを例示した図である。 適応ヘルパの実装処理動作を説明するための図である。 適応ヘルパの実装処理動作を説明するための図である（続き）。 属性管理の利用方法を表すコードである。 属性管理に係る処理を説明するための図である。 呼出し段階によって、呼出し前読出し段階と、呼出し後書き込み段階に分けられた同期段階における、レプレットのレプリケーションを説明するための図である。 サービス要求を受信した際に行われる処理を表した図である。 (a)〜(e)は、クライアントレプリケーションマネージャとサーバレプリケーションマネージャとの間の通信の５つのパターンを示す図である。 移動端末、インターネットおよびサーバを含む環境を表す図である。 移動端末側のレプリケーションシステムの構成図である。 サーバ側のレプリケーションシステムの構成図である。 レプリケーション場所選択プロトコルによる処理を説明するための図である。 レプリケーション提供プロトコルを説明するための図である。 共同サービス呼出しプロトコルを説明するための図である。 状態同期プロトコルを説明するための図である。 本発明に用いるコンピュータシステムの構成図である。 適応コンサルタントインタフェースを示す図である。 メッセージおよびデータの種類の定義を示す図である。 メッセージおよびデータの種類の定義を示す図である（続き）。 メッセージおよびデータの種類の定義を示す図である（続き）。

符号の説明

２０１・・・、２０２・・・公開データ部、２０３・・・コード、２０４・・・非公開データ部、２０５・・・書換え不可データ、５００・・・リプレットアリーナ、５０１、レプリケーションマネージャ、５０２・・・レプリカ、５０３・・・属性マネージャ、５０４・・・機能マネージャ、５０５・・・サービスエンジンラッパ、５１０・・・サービスエンジン、１４０１・・・携帯端末、１４０１Ａ・・・サービス呼出しインタフェース、１４０１Ｂ・・・ユーザ属性インタフェース、１４０２・・・インターネット、１４０３・・・サーバ、１４１０・・・携帯端末用ソフトウェア、１４２０・・・サーバ用ソフトウェア、１４２１・・・通信インタフェース、１４０３Ａ・・・アプリケーション属性インタフェース、１４０３Ｂ・・・サーバ属性インタフェース、１４３０・・・移動端末側レプリケーションシステム、１４３１・・・サーバ側レプリケーションシステム、２１０４・・・メインメモリ、２１０６・・・固定メモリ、２１０７・・・大容量記憶装置、２１１２・・・プロセッサ、２１２１・・・表示装置、２１２２・・・キーボード、２１２３・・・カーソル制御装置、２１２４・・・印刷装置。

Claims (14)

1. サーバ装置およびクライアント装置が、実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）前記サーバ装置のハードウェア環境を表すサーバ機能情報と、（ｉｉ）前記サーバ、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得するステップと、
   前記サーバ装置が、前記クライアント装置に対し、前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報と前記属性情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションの実行を許可する旨の実行指示を送信するステップと、
   前記クライアント装置が、前記実行指示に基づいて、前記アプリケーションサービスオブジェクトのレプリケーションを実行する実行ステップと
   を有し、
   前記実行ステップにおいて、前記クライアント装置が、クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度とを取得し、該取得された信頼度と前記属性から決定される閾値とを比較することにより、サーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定する
   ことを特徴とするレプリケーション実行方法。
2. サーバ装置のコンピュータに、
   実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）サーバ装置のハードウェア環境を表すサーバ機能情報と、（ｉｉ）前記サーバ装置、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得するステップと、
   前記クライアント装置に対し、前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報と前記属性情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションの実行を許可する旨の実行指示を送信するステップと、
   前記クライアント装置が、クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度とを取得し該取得された信頼度と前記属性から決定される閾値とを比較した結果として前記サーバ装置へ要求を送信した場合に、当該要求に基づいてサーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定するステップと
   を実行させるプログラム。
3. 一または複数のクライアント装置と通信を行うための通信インタフェースと、
   実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）サーバ装置のハードウェア環境を表すサーバ機能情報と、（ｉｉ）前記サーバ装置、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得する手段と、
   前記クライアント装置に対し、前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報と前記属性情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションの実行を許可する旨の実行指示を送信する送信手段と、
   前記クライアント装置の要求に基づき、クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度を取得し、該取得された信頼度と前記属性から決定される閾値とを比較することにより、サーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定する手段と
   を有するサーバ装置。
4. サーバ装置と通信を行うための通信インタフェースと、
   実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）サーバ装置のハードウェア環境を表すサーバ機能情報と、（ｉｉ）前記サーバ装置、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得する手段と、
   前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションについての実行許可の要求を、前記サーバ装置に送信する手段と、
   クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度とを取得し、該取得された信頼度と前記属性から決定される閾値とを比較することにより、サーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定する手段と
   を有するクライアント装置。
5. 前記サーバ装置、前記クライアント装置のユーザ、および前記アプリケーションの少なくともいずれかによって予め定められた属性情報とを取得する属性マネージャと、
   実行可能なコードで構成されるアプリケーションサービスオブジェクトに関し、（ｉ）レプリケーション実行時における、（ａ）前記アプリケーションサービスオブジェクトが要求するハードウェア構成を表すアプリケーション機能情報と、（ｂ）クライアント装置のハードウェア環境を表すクライアント機能情報と、（ｃ）前記サーバ装置のハードウェア環境を表すサーバ機能情報を取得する機能プロファイラと、
   前記クライアント機能情報と前記サーバ機能情報と前記アプリケーション機能情報と前記属性情報とに基づいて、少なくとも一のアプリケーションサービスオブジェクトのレプリケーションの実行を前記クライアント装置に指示するレプリケーションマネージャと
   を有し、
   前記レプリケーションマネージャは、前記クライアント装置に対し、前記実行指示に基づいて前記アプリケーションサービスオブジェクトのレプリケーションを実行する場合に、クライアントレプリカまたはサーバレプリカのいずれを用いるべきかを表す候補情報と当該候補情報の信頼度とを取得し、該取得された信頼度と前記属性から決定される閾値とを比較することにより、サーバレプリカまたはクライアントレプリカのうち前記レプリケーションにおいて使用する一つのレプリカを決定させる
   ことを特徴とするレプリケーションシステム。
6. 前記クライアント機能情報には、記憶容量、利用可能な記憶装置、ＣＰＵの処理能力、利用する通信網の帯域幅、および前記サーバ装置までのラウンドトリップタイムの少なくともいずれか一つが含まれ、
   前記サーバ機能情報には、前記サーバ装置のＣＰＵの処理能力または負荷状態が含まれ、
   前記アプリケーション機能情報には、メモリ要求量、前記クライアント装置におけるコスト変動幅、クライアントレプリカの数、およびソフトウェア環境に関する情報の少なくともいずれか一つが含まれる
   ことを特徴とする請求項１に記載のレプリケーション実行方法。
7. 前記属性を構成する項目のうち、前記アプリケーションサービスオブジェクト、前記サーバ装置、前記クライアント装置のいずれかによって定められた属性項目が複数存在し、各属性項目の属性値が異なる場合は、各属性項目に設けられた優先度に基づいて当該属性項目についての一つの属性値を決定する
   ことを特徴とする請求項１に記載のレプリケーション実行方法。
8. 前記クライアント装置の無線接続状態に応じて、該選択されたクライアントレプリカの起動を指示するステップを更に備える
   ことを特徴とする請求項１に記載のレプリケーション方法。
9. 前記無線接続状態が回復したとき、当該クライアントレプリカを終了してオーナレプリカを起動させる指示を行うステップを更に有する
   ことを特徴とする請求項８に記載のレプリケーション方法。
10. 前記クライアント装置の無線接続状態に応じて、該選択されたクライアントレプリカの起動を指示する
    ことを特徴とする請求項３に記載のサーバ装置。
11. 前記無線接続状態が回復したとき、当該クライアントレプリカを終了してオーナレプリカを起動させる
    ことを特徴とする請求項１０に記載のサーバ装置。
12. 当該クライアントレプリカの起動中は前記無線接続状態が切断されなかったものとみなして以後の処理を行うことを特徴とする請求項３に記載のサーバ装置。
13. 前記クライアント装置の無線接続状態に応じて、該選択されたクライアントレプリカの起動を指示するステップを更に実行させる
    ことを特徴とする請求項２に記載のプログラム。
14. 前記無線接続状態が回復したとき、当該クライアントレプリカを終了してオーナレプリカを起動させる指示を行うステップを更に実行させる
    ことを特徴とする請求項１３に記載のプログラム。

Images