JP2005535042A - クライアント・サーバ通信におけるインクリメントデータを処理する方法およびコンピュータシステム - Google Patents

Abstract

サーバ（９０１）上のサーバコントローラ（１０１−１）は、サーバ（９０１）に格納されているアプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）を変更モデル（２００−Ｔ２）に変更するための、クライアント（９００）のクライアントコントローラ（１００−２）により生成された変更リクエストを受け取る（４１０）。サーバレンダラ（１０１−２）は、オリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）との差分に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成する（４２０）。クライアントアセンブラ（１００−１）は少なくとも１つのブラウザインクリメント（３００−Ｉ）をサーバ（９０１）から受け取り、オリジナルモデル（２００−Ｔ１）に対応するオリジナルＤＯＭコンポーネント（３００−Ｔ１）を少なくとも１つのブラウザインクリメント（３００−Ｉ）を用いてクライント（９００）のところで更新し、その結果、変更モデル（２００−Ｔ２）に対応する変更されたＤＯＭコンポーネント（３００−Ｔ２）が生成される。

Description

本発明は全般的には電子データ処理に関する発明であって、さらに詳しくは、クライント・サーバ通信のための方法、コンピュータプログラム製品ならびにシステムに関する。

背景技術
いくつかのソフトウェアアプリケーションはMicrosoft Internet Explorerのような慣用のウェブブラウザを使用してアクセス可能である。典型的には、この種のアプリケーションによって複数のページが提供される。１つのページにはグラフィカルユーザインタフェース（ＧＵＩ）のための関連情報が含まれており、このページを介してユーザはアプリケーションと対話することができる。このページには複数のコンポーネントを含めることができる。

このページは典型的にはサーバにおいて生成され、その後、クライアントへ送信される。クライントサイドではブラウザによって、ユーザに対してこのページがビジュアライズされる。ページをリフレッシュするためユーザがＧＵＩを介してクライアントと対話すると、プロセス全体が繰り返される。上述の手順に対して一般的に受け入れられているプログラミングデザインパターンは、いわゆるＭＶＣ（Model-View-Controller）デザインパターンである。この場合、閲覧および操作のためのアプリケーションデータをカプセル化するモデルがコントローラによって処理されて、ビューとなるようレンダリングされる。ビューはブラウザ互換のコンテンツを含むページに対応する。その際、各モデル事に複数のビューと複数のコントローラを設けることができる。たとえば、モデルのデータをテーブルとしてビジュアライズするために一方のビューを使用しながら、同じデータをパイチャートとしてビジュアライズするために他方のビューを使用することができる。このことはすべてサーバ上で行われ、ついでビュー全体がクライアントへ送られる。したがってＭＶＣデザインパターンのためには複数のＣＰＵサイクルと、クライアント・サーバ間の通信を可能にする大きい帯域幅のコンピュータネットワークが必要とされる。それというのも、ページ全体（レイアウト情報およびデータ）がサーバ上で再生され、結果として得られたビューがネットワークを介してサーバからクライアントへ再転送されるからである。さらにユーザは、リフレッシュされたページが最終的にクライアント上で表示されるまで、待ち時間や画面のちらつきのような望ましくない作用に直面する。

Microsoft Internet Explorer IE 6.0などのようないくつかの慣用のブラウザには、ちらつきのないレンダリングを行う特徴的な機能が含まれている。変更のあったページをクライアントが受け取る場合、ページのドキュメントオブジェクトモデル（ＤＯＭ）にダイナミックＨＴＭＬを埋め込むことでブラウザはそのページにおいて変更されたコンポーネントを識別し、ページ全体ではなくそれらのコンポーネントだけを置き換える。このことにより、ユーザにとっては画面のちらつきが低減されることになるけれども、ページ生成のために依然としてＣＰＵ時間（ＣＰＵサイクル）を消費することになり、サーバからクライアントへページ全体を転送するための帯域幅が必要とされる。さらにユーザ各々がクライアントと対話するためにはサーバのラウンドトリップが必要とされ、したがってページ生成ならびに転送ゆえに高いサーバ負荷が引き起こされる。

このため、クライアント・サーバ通信においてＣＰＵ時間の消費ならびに帯域幅の要求を減らすと同時に、ユーザに対する不所望な作用も減らす必要性が常に存在している。

発明の概要
したがって本発明の課題は、ページリフレッシュにあたりクライアント・サーバ通信における帯域幅要求を減らすようにした方法、コンピュータプログラム製品ならびにコンピュータシステムを提供することにある。
この課題を解決するため本発明の１つの実施形態によれば、請求項１記載のインクリメントデータを処理するコンピュータシステムは以下のように構成されている：ａ）サーバ上のサーバコントローラはクライアントの変更リクエストを受け取り、この変更リクエストに応答して、アプリケーションコンポーネントのオリジナルモデルをこのアプリケーションコンポーネントにおける変更モデルに変更する。ｂ）サーバレンダラは、オリジナルモデルと変更モデルとの差分に対応する少なくとも１つのブラウザインクリメントを生成する。ｃ）クライアントアセンブラは少なくとも１つのブラウザインクリメントをサーバから受け取り、この少なくとも１つのブラウザインクリメントによってクライアントにおけるオリジナルＤＯＭコンポーネントを更新する。オリジナルＤＯＭコンポーネントはオリジナルモデルに対応し、更新の結果、変更モデルに対応する変更されたＤＯＭコンポーネントが生成される。ｄ）変更リクエストはクライアントコントローラによって生成される。オリジナルＤＯＭコンポーネントはオリジナルモデルに対応し、更新の結果、変更モデルに対応する変更されたＤＯＭコンポーネントが生成される。ｄ）変更リクエストはクライアントコントローラによって生成される。

本発明のさらに別の実現形態は、請求項１０記載のサーバ、請求項１１記載のクライアント、請求項１５記載のサーバ側の方法、請求項１６記載のクライアント側の方法、請求項２０記載のサーバ側のコンピュータプログラム製品、請求項２１記載のクライアント側のコンピュータプログラム製品である。モデルとビューとコントローラが記憶されサーバによって処理される従来技術のＭＶＣパターンと比較すると、本発明による方法は、ビューとコントローラがサーバ側の部分とクライアント側の部分に分割されているパターンである。ビューにおけるサーバ側の部分はサーバレンダラである。ビューにおけるクライアント側の部分はクライアントアセンブラである。コントローラにおけるサーバ側の部分はサーバコントローラであり、コントローラにおけるクライアント側の部分はクライアントコントローラである。

本発明により得られる効果として、ネットワーク通信のために必要とされる帯域幅が、サーバとクライアントとの間でブラウザインクリメントではなくページ全体が交換される従来技術のシステムよりも小さい点が挙げられる。ページの僅かな部分しか変更されないことが多い。このようなケースでは、ブラウザインクリメントの伝送によってページ全体の伝送よりも著しく僅かな帯域幅しか必要とされない。

本発明のさらに別の効果として挙げられるのは、クライアントとのインタラクションを行うユーザの目にとって心地よい作用が得られることである。なぜならばブラウザコンポーネントのＤＯＭコンポーネントをブラウザインクリメントで更新することから、グラフィカルユーザインタフェースにおいてちらつきのない変更が得られるからである。

さらに本発明によれば、サーバがアプリケーションのステータスを保持しておく必要がないという効果が得られる。それというのも、サーバは必要とする状態情報をクライアントから得るからである。

本発明の観点を、殊に特許請求の範囲に示されている要素やそれらの組み合わせによって実現し達成することができる。つまり本発明の特徴に関する既述の組み合わせは限定を意味するものではなく、すべての特徴は本発明の範囲を逸脱することなく、さらに別の配置構成において組み合わせ可能である。なお、上述の概略的な説明ならびに以下の詳細な説明は例であって、説明のためのものにすぎず、ここで述べた本発明を限定するものではない。

図面の簡単な説明
図１は、本発明の実施形態を実現する一例としてのコンピュータシステムを示すブロック概略図である。図２Ａ〜図２Ｄは、本発明の１つの実施形態によるグラフィカルユーザインタフェースの１つの実装例を示す図である。図３は、本発明の１つの実施形態に従って動作させたときのクライアントとサーバのインタラクションについて示す図である。図４Ａおよび図４Ｂは、本発明の１つの実施形態によるブラウザインクリメントに関するクライアント側の処理について示す図である。図５は、本発明による１つの実施形態において利用可能な２つの相補的なコンピュータプログラム製品およびそれらの主要な機能ブロックについて示す図である。図６は、本発明によるすなわちインクリメントデータすなわち変化分のデータを処理するためのサーバ側の方法を示す簡単なフローチャートである。図７Ａおよび図７Ｂは、本発明によるインクリメントデータを処理するクライアント側の方法を示す簡単なフローチャートである。

発明の詳細な説明
可能であるならば、同じ部分または同等の部分を指すために全図を通して同じ参照符号を用いることにする。

以降で使用する用語の定義：クライアント：クライアントとは、たとえばソフトウェアアプリケーションにより提供されるサービスにアクセスするよう構成されたコンピュータアプリケーションのことである。典型的には、ウェブアプリケーションにアクセスするクライアントはウェブブラウザを実行し、たとえばＰＣ上で実行されるNetscape Navigator、ＰＤＡ上で実行されるPocket Internet Explorer、あるいはセルラフォン上で実行されるＷＡＰブラウザなどを実行する。

サーバ：サーバとは、クライアントによりアクセスされるアプリケーションが実行されるコンピュータ装置のことである。

ページ：ページには、ウェブアプリケーション（以下の定義を参照）のグラフィカルユーザインタフェースを定義するコンテンツ（レイアウトおよびデータ）が含まれている。ページは一般に、ＨＴＭＬまたはＷＭＬのようなブラウザ互換フォーマットになるようサーバ上でレンダリングされる。

コンポーネント：
コンポーネントは１つのページの基本構成ブロックである。１つのページ内に必ずコンポーネントが存在している。１つのコンポーネントにはさらに別のコンポーネントを含めることができる。この場合、コンポーネントは「ペアレントコンポーネント」と呼ばれ、さらに別のコンポーネントは「チャイルドコンポーネント」と呼ばれる。あるページ内でペアレントコンポーネントをもたないそのページのコンポーネントをルートコンポーネントと称する。本発明によれば、「アプリケーションコンポーネント」とも呼ばれるサーバ側の部分を有している。

このアプリケーションコンポーネントは、コンポーネントデスクリプタおよびブラウザインクリメントの生成中、存在している。これによってステートレスなサーバとすることができる。それというのもアプリケーションコンポーネントは制限されたタイムインターバルだけしか存在できないからであり、クライアントから必要なステート情報を受け取ることができるからである。コンポーネントは、ブラウザコンポーネントと呼ばれることになるクライアント側の部分も有している。ブラウザコンポーネントは対応するコンポーネントのステートないしは状態を保持する。

コンポーネントデスクリプタ：
あるページがブラウザ互換フォーマットになるようレンダリングされるならば、そのページの各アプリケーションコンポーネントはブラウザ互換フォーマットになるようレンダリングされる。レンダリングされるアプリケーションコンポーネントを「コンポーネントデスクリプタ」と称する。コンポーネントデスクリプタを名前と値のペアとして実装することができる。

ウェブアプリケーション：
以下で用いられるウェブアプリケーションという用語には、複数のページの集合が含まれる。ウェブアプリケーションの１つの特別な特徴は、サーバにおけるステートを保持し続けないことである。換言すれば、リクエストをサーバが受信するたびに、サーバはアクセスされたウェブアプリケーションのステートを最初から生成する。ウェブアプリケーションが出力を生成した後、そのステートは通常、破棄される。

ドキュメントオブジェクトモデル：
対応するＷ３Ｃの定義によれば、あるページのドキュメントオブジェクトモデル（Document Object Model, DOM）により、構文解析されるＨＴＭＬコンテンツおよびＸＭＬコンテンツをアクセスし操作するメカニズムが提供される。

クラス名：あるコンポーネントのクラス名によって、コンポーネントのアプリケーションコンポーネントを実装するサーバ側のコンポーネントクラス（たとえばJavaクラス、Java Server Pagesクラス、servletクラス、Cクラス、C++クラスあるいはBusiness Server Pagesクラス）の名前が指定される。

アプリケーションコンポーネントはコンポーネントクラスのインスタンスであって、これには対応するモデル、サーバコントローラならびにサーバレンダラを含めることができる。

スクリプトクラス名：あるコンポーネントにおけるスクリプトクラス名によって、アプリケーションコンポーネントに対応するブラウザコンポーネントを実装するクライアント側のコンポーネントスクリプトクラス（たとえばJavaScript class, Java Applets class, またはVisualBasic Script class）の名前が指定される。コンポーネントスクリプトクラスとコンポーネントクラスに同一階層をもたせることができる。ブラウザコンポーネントはコンポーネントスクリプトクラスのインスタンスであり、これには対応するクライアントコントローラ、クライアントアセンブラおよび現在のページのＤＯＭコンポーネントを含めることができる。ＤＯＭコンポーネントには、対応するコンポーネントをビジュアライズするブラウザによって使用される１つまたは複数のＤＯＭノードを含めることができる。

図１には、本発明の実施形態を実現する一例としてのコンピュータシステムを示すブロック概略図が示されている。
コンピュータシステム９９９にはコンピュータ９００が含まれており、このシステムはさらに別の複数のコンピュータ９０１，９０２（または９０ｑ、ただしｑ＝ｑ〜Ｑ−１でありＱは任意の数）を有している。

コンピュータ９００は、コンピュータネットワーク９９０を介して別のコンピュータ９０１，９０２と通信を行うことができる。コンピュータ９００はプロセッサ９１０、記憶装置９２０、バス９３０を有しており、さらにオプションとして入力デバイス９４０および出力デバイス９５０（Ｉ／Ｏデバイス、ユーザインタフェース９６０）を有している。図示されているように本発明はコンピュータプログラム製品１００（ＣＰＰ）、プログラム担体９７０またはプログラム信号９８０によって実装されている。

コンピュータ９００に対しコンピュータ９０１／９０２は場合によっては「リモートコンピュータ」と呼ばれることもあり、コンピュータ９０１／９０２はたとえばサーバ、ピアデバイスまたは他の共通のネットワークノードであって、典型的にはコンピュータ９００に対し相対的に記述された要素の多くまたはすべてを有している。

コンピュータ９００はたとえば慣用のパーソナルコンピュータ（ＰＣ）、デスクトップ機器またはハンドヘルド機器、マルチプロセッサコンピュータ、ペンコンピュータ、マイクロプロセッサベースのまたはプログラミング可能なコンシューマ向けエレクトロニクスデバイス、ミニコンピュータ、メインフレームコンピュータ、パーソナルモバイルコンピューティングデバイス、モバイルフォン、ポータブルまたは据え置き型のパーソナルコンピュータ、パームトップコンピュータ等である。

プロセッサ９１０はたとえば中央処理ユニット（ＣＰＵ）、マイクロコントローラユニット（ＭＣＵ）、ディジタルシグナルプロセッサ（ＤＳＰ）等である。

記憶装置９２０によって、データおよび命令を一時的または持続的に格納する素子がシンボリックに表されている。記憶装置９２０はここではコンピュータ９００の一部分として描かれているけれども、記憶装置機能をネットワーク９９０やコンピュータ９０１／９０２に、さらにはプロセッサ９１０自体（たとえばキャッシュ、レジスタ）の中に、あるいは他のどこかにおいて実現することもできる。この場合、記憶装置９２０をリードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）または他のアクセスオプションをもつメモリとすることができる。さらに記憶装置９２０を、磁気記憶媒体、光学記憶媒体、半導体記憶媒体などのようなコンピュータで読み取り可能な媒体によって実現してもよいし、あるいはコンピュータで読み取り可能な他の何らかの記憶媒体によって実現させてもよい。

記憶装置９２０はたとえば基本入出力システム（ＢＩＯＳ）、オペレーティングシステム（ＯＳ）、プログラムライブラリ、コンパイラ、インタプリタあるいはテキスト処理ツールなどのようなサポートモジュールを記憶することができる。

ＣＰＰ１００によってプログラム命令がインプリメントされ、さらにオプションとして本発明による方法の各ステップをプロセッサに実行させるデータがインプリメントされる。換言すればＣＰＰ１００は、本発明に従って動作するようコンピュータ９００の動作を制御することができる。本発明を限定するものではないが一例としてＣＰＰ１００を、何らかのプログラミング言語で書かれたソースコードやコンパイル済みのオブジェクトコード（「バイナリコード」）として用いることができる。

また、ここではＣＰＰ１００は記憶装置９２０に格納されたものとして描かれているけれども、ＣＰＰをどこか別の場所に配置しておいてもよい。ＣＰＰ１００をプログラム担体９７０において実現することもできる。

プログラム担体９７０はコンピュータ９００の外部に描かれている。
ＣＰＰ１１００をコンピュータ９００に転送させるために好適であるのは、プログラム担体９７０を入力デバイス９４０へ挿入することである。

プログラム担体９７０を、既にたくさん挙げた媒体のようなコンピュータで読み取り可能な何らかの媒体によって実現することができる（記憶装置９２０参照）。一般にプログラム担体９７０はコンピュータで読み取り可能な媒体を実現する製品であって、これは本発明による方法をコンピュータに実施させるために使用可能であるコンピュータで読み取り可能なプログラムコードを有している。さらにプログラム信号９８０によってＣＰＰ１００を実現することもできる。入力デバイス９４０により、コンピュータ９００により処理するためのデータと命令が供給される。この入力デバイス９４０をたとえばキーボード、ポインティングデバイス（たとえばマウス、トラックボール、カーソル方向キー）、マイクロフォン、ジョイスティック、ゲームパッド、スキャナまたはディスクドライブとすることができる。これらの例は人間のインタラクションを伴うデバイスであるけれども、（たとえば衛星用パラボラアンテナまたは地上用アンテナを備えた）ワイヤレスレシーバ、センサ（たとえばサーモメータ）、カウンタ（たとえば工場内の荷物計数器）のように人間のインタラクションを伴わない動作も可能である。入力デバイス９４０を、プログラム担体２７０を読み出すために用いることができる。

出力デバイス９５０によって、処理された命令およびデータが呈示される。たとえばこのデバイスをモニタまたはディスプレイとすることができ、たとえばブラウン管（ＣＲＴ）またはフラットパネルディスプレイあるいは液晶ディスプレイ（ＬＣＤ）、スピーカ、プリンタ、プロッタまたはバイブレーションアラーム機器とすることができる。

既に述べたことと同様、出力デバイス９５０もユーザとコミュニケーションをとることができるけれども、別のコンピュータと通信することも可能である。

入力デバイス９４０および出力デバイス９５０を結合して単一のデバイスとすることができる。オプションとして何らかのデバイス９４０と９５０を設けることができる。

バス９３０およびネットワーク９９０によれば、命令およびデータの信号の搬送により論理的および物理的なコネクションが形成される。好適にはコンピュータ９００内のコネクションをバス９３０と称する一方、コンピュータ９００〜２０２間のコネクションをネットワーク９９０と称する。オプションとしてネットワーク９９０にはゲートウェイが含まれ、これはデータ伝送およびプロトコル変換に特化されたコンピュータである。

デバイス９４０および９５０は（図示されているように）バス９３０またはネットワーク９９０（オプション）によってコンピュータ９００と接続されている。

（ネットワーク９９０のような）ネットワークは、オフィスや企業間コンピュータネットワーク、イントラネットおよびインターネットにおいて一般的なものである。ネットワーク９９０を有線ネットワークとしてもよいし、あるいはワイヤレスネットワークとしてもよい。ネットワーク実装の例としてローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、公衆交換電話回線網（ＰＳＴＮ）および総合サービスディジタルネットワーク（ＩＳＤＮ）を挙げることができる。ネットワーク実装の他の例も当業者に周知である。

種々の伝送プロトコルならびにデータフォーマットが知られており、たとえば伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ハイパーテキスト転送プロトコル（ＨＴＴＰ）、セキュアＨＴＴＰ（ＨＴＴＰＳ）またはワイヤレスアプリケーションプロトコル（ＷＡＰ）などが挙げられる。

要素と要素の間に接続されているインタフェースも当業者によく知られている。わかりやすくするため、インタフェースは図示されていない。インタフェースとしてたとえばシリアルポートインタフェース、パラレルポートインタフェース、ゲームポート、汎用シリアルバス（ＵＳＢ）インタフェース、内蔵モデムまたは外付けモデム、ビデオアダプタまたはサウンドカードを挙げることができる。

コンピュータとプログラムは密接に関連している。あとで用いるように、「コンピュータにより〜が提供される」および「プログラムにより〜が提供される」というようなフレーズは、プログラムにより制御されるコンピュータによってなされるアクションを表す便宜的な簡易表現である。

図２Ａ〜図２Ｄは、本発明の１つの実施形態によるグラフィカルユーザインタフェースの実装例をそれぞれ４つの連続的な時点Ｔ１，Ｔ２，Ｔ３，Ｔ４で示した図である。

ユーザとグラフィカルユーザインタフェース９５５とのインタラクションに関する以下の例は、本明細書全体を通して本発明を説明するために用いられる。しかしながら本発明によれば、どのようなグラフィカルユーザインタフェースであっても実装することができる。たとえばＧＵＩ９５５は、クライアントコンピュータ９００の出力デバイス９５０（図１参照）においてユーザに呈示され、そのユーザは入力デバイス９４０を使用してＧＵＩ９５５とインタラクションを行う。

ＧＵＩ９５５は、ツリー９５５−１の各ノードによってビジュアライズされる階層構造データとのインタラクションをユーザが行うことができるようにするグラフィカルユーザインタフェースである。たとえばこの階層構造データはサーバコンピュータ９０１（図１参照）に格納されている。しかしこの階層構造データを、コンピュータシステム９９９（図１参照）におけるどのような記憶装置に格納してもよい。ユーザはリセット（ボタン）９５５−２を使用してツリー９５５−１をリセットすることもできる。ツリー９５５−１の各ノードのステータスはマイナス符号（−）またはプラス符号（＋）によって表されている。マイナス符号は、ノードのステータスが展開されていることを表している。たとえばあるノードをクリックすることにより、ユーザはノードのステータスを折りたたまれた状態（＋）から展開された状態（−）あるいはその逆へ変更することができる。

図２Ａの場合、時点Ｔ１においてユーザはツリー９５５−１と取り組むよう促され、その際、種々のノードの状態は以下の通りである：ルートノードＲ１：展開状態（−）；子ノードＦＬ１，ＦＬ２；第１レベルノードＦＬ１：展開された子ノード：ＳＬ１，ＳＬ２；第１レベルノードＦＬ２：折り畳まれた状態；第２レベルノードＳＬ１，ＳＬ２：折り畳まれた状態（＋）。

たとえばユーザは、展開させるため（たとえばノードをクリックすることにより）第２レベルノードＳＬ２を選択する。

ユーザの選択を受け取った後、ツリー９５５−１はそれに応じて変更される。

図２Ｂの場合、時点Ｔ２において第２レベルＳＬ２のステータスは以下のように変更される：展開された状態（−）；子ノードＴＬ１。第３階層ノードＴＬ１が第２階層ノードＳＬ２の子ノードとしてツリー９５５−１に加わる。その後でたとえば、ユーザは（ノードをクリックして）折り畳むために第２レベルノードＳＬ２を再び選択する。ユーザの選択を受け取った後、クライント９００はそれ相応にツリー９５５−１を変更する。

図２Ｃの場合、時点Ｔ３において第２レベルＳＬ２のステータスは以下のように変更されて元に戻される：折り畳まれた状態（＋）。第３階層ノードＴＬ１はツリー９５５−１において隠された状態になり、第２階層ノードＳＬ２の子ノードとして見ることができなくなる。ついでたとえば、ユーザはリセットボタン９５５ー２をクリックして、ツリー９５５−１を初期状態にリセットする。リセット要求を受け取った後、クライアント９００はそれ相応にツリー９５５−１を変更する。

図２Ｄには、時点Ｔ４におけるツリー９５５−１の初期状態の一例が示されている。ルートノードＲ１は折り曲げられた状態（＋）のステータスを有しており、その子ノードのいずれもビジュアライズされていない。ツリー９５５−１の択一的な初期状態は以下の通りである：ルートノードＲ１：展開された状態（−）；子ノード：ＦＬ１，Ｆ２が折り畳まれた状態（＋）。

さらに別の択一的な初期状態：すべてのノードが展開された状態（＋）。以下の説明では、図２Ａ〜図２Ｄを用いて説明したようなＧＵＩの挙動を、時点Ｔ１〜Ｔ４の前または後でＧＵＩ９５５のアピアランスが変化したときに、ネットワーク帯域幅要求を小さくしかつユーザに対するスクリーンのちらつきを抑えるようにして実現するために、本発明の実施形態について述べる。

図３は、本発明の１つの実施形態に従って動作させたときのクライアント９００とサーバ９０１のインタラクションについて示す図である。図１に示されているように、クライアント９００はネットワーク９９０を介してサーバ９０１と通信する。

サーバ９０１には、サーバコントローラ１０１−１、サーバレンダラ１０１ー２を有するアプリケーションコンポーネントが含まれている。この実施形態の場合、アプリケーションコンポーネントのインスタンスにはさらにオリジナルモデル２００−Ｔ１も含まれている。たとえばサーバコントローラ１０１−１およびサーバレンダラ１０１−２はＣＰＰ１０１（図１参照）の一部分であり、これはサーバ９０１のメモリ９２１に格納される。サーバコントローラ１０１−１はクライアント９００の変更要求４１０を受け取る。変更要求を受け取ると、サーバコントローラ１０１−１はオリジナルモデル２００−Ｔ１を変更されたモデル２００−Ｔ２へ変更する。複数のアプリケーションコンポーネントが存在する場合、対応するサーバコントローラは各アプリケーションコンポーネントを互いに作用させ合うようにする。換言すればたとえばサーバコントローラ１０１−１は、さらに別のサーバコントローラにさらに別のモデルの変更を行わせるイベントを引き起こすことができる。

アプリケーションコンポーネントにおけるオリジナルモデル２００−Ｔ１および変更モデル２００−Ｔ２は、同じサークルシンボルによって描かれている。図２Ａの実施例に戻ると、オリジナルモデル２００−Ｔ１は時点Ｔ１においてツリー９５５−１としてビジュアライズされている。変更要求は、第２レベルノードＳＬ２になるよう展開するユーザのインタラクションに対応する。

変更モデル２００−Ｔ２は時点Ｔにおいてツリー９５５−１としてビジュアライズされる。

本発明の１つの実施形態によれば、継承を備えたオブジェクト指向コンポーネントアーキテクチャフレームワーク（以下ではフレームワークとも称する）が利用される。

フレームワークはサーバ側の部分とクライアント側の部分を有する。フレームワークは、１つまたは複数のクラスのメソッドのセットのようなファンクションプールとしてインプリメントすることができる。たとえばコンポーネントによって標準グラフィカルユーザインタフェース要素がインプリメントされ、ボタン（たとえばリセット９５５−２）、ツリー（たとえばツリー９５５−１）、テーブル、タブストリップまたはＧＵＩ９５５のようなグラフィカルユーザインタフェースにおける他の何らかのインタフェース要素がインプリメントされる。さらにコンポーネントにプロパティおよびオファーサービスをもたせることができ、たとえばグラフィカルユーザインタフェース記述ファイルからのグラフィカルユーザインタフェース生成およびドロップインタラクションハンドリングおよびコンポーネントアドミニストレーションなどである。このフレームワークによって、ランタイムでのコンポーネントの生成および削除ならびにランタイムでのコンポーネントのすべてのプロパティへのアクセスがサポートされる。これに加えてフレームワークによって、ブロードキャストイベントメカニズム、グラフィカルユーザインタフェースの変更ならびにページの置き換えを伴わないサーバアクセスなどのような汎用サービスを提供することができる。

あるコンポーネントを、Tomcatなどのようなサーブレットエンジンにより利用される手順と同様の特別な登録手順を用いることなくインストールすることができる。換言すれば、あるコンポーネントをインストールすると自動的にそのコンポーネントをフレームワークで利用できるようになる。

たとえば１つのコンポーネントにおける１つのアプリケーションコンポーネントは、Javaクラス、Java Server Pagesクラス、servletクラス、Pascalクラス、Cクラス、C++クラスまたはBuisiness Server Pagesクラスのようなコンポーネントクラスによって定義される。コンポーネントクラスはサーバ９０１上で実行される。たとえばコンポーネントクラスによって、モデル（たとえばモデル２００−Ｔ１）ならびにサーバレンダラ（たとえばサーバレンダラ１０１−２）およびコンポーネントのサーバコントローラ（たとえばサーバコントローラ１０１−１）がインプリメントされる。

オリジナルモデル２００−Ｔ１をビジュアライズするため、サーバレンダラ１０１−２はHTML, XHTMLまたはWMLのようなブラウザ互換のコードを生成する。最初にサーバレンダラ１０１−２はオリジナルモデル２００−Ｔ１からコンポーネントデスクリプタを生成し、このコンポーネントデスクリプタをクライアント９００へ送信する。コンポーネントデスクリプタは、たとえば（時点Ｔ１における）図２Ａの例ではブラウザ互換のツリー９５５−１の記述に相応する。当業者にとって、たとえばJavaページ、Java Server Pageまたは択一的にオリジナルモデル２００−Ｔ１のサーバ側の記述をベースとして、コンポーネントデスクリプタをどのように生成するのかは周知である。たとえばJavaScriptクラス、JavaAppletクラスまたはVisualBasic Scriptクラスのようなコンポーネントスクリプトクラスは、オリジナルモデル２００−Ｔ１の対応するコンポーネントデスクリプタをベースとして、オリジナルブラウザコンポーネント２００−Ｔ１を生成する。

１つの実施形態によれば、コンポーネントには名前と値のペアのセットとしてプロパティが含まれており、この場合、プロパティは対応するコンポーネントデスクリプタの一部分である。

コンポーネントの標準プロパティは識別子、クラス名、スクリプトクラス名および親コンポーネント名である。識別子はコンポーネントを含む１つのページにおいてユニークないしは一意である。クラス名とスクリプトクラス名によって、そのコンポーネントにおけるコンポーネントクラスとコンポーネントスクリプトクラスの名前が指定される。親コンポーネント名は、コンポーネントにおける親コンポーネントの識別子である。たとえば、スクリプトクラス名をクラス名から導出することができる。コンポーネントにおけるアプリケーションコンポーネントに対応するブラウザコンポーネントを生成するために、スクリプトクラスを使用することができる。

あるページが最初にサーバ９０１において生成されると、そのページの各アプリケーションコンポーネントにおけるコンポーネントクラスはアプリケーションコンポーネントの対応するプロパティとともに呼び出される。それらのプロパティには、サーバ９０１において知られているアプリケーションコンポーネントに関するすべての情報が含まれている。

コンポーネントクラスにより、たとえばコンポーネントクラスのインタフェースにおける１つまたは複数のファンクションを利用して、アプリケーションコンポーネントのコンポーネントデスクリプタがページに書き込まれる。_{これらのファンクションの例は以下の通りである：}
・prolog (...)
・base (...)
・epilog (...)
たとえば、すべてのツリーファンクションはパラメータセットを有している。たとえばパタメータ「プロパティ」は、アプリケーションコンポーネントを記述する名前と値のペアのセットである。ページにデータを書き込むためにさらに別のパラメータ "output"が用いられ、この場合、データは出力ストリームにおいてクライアントへ送信される。出力ストリームにおいてクライアントへ送信されるページへの書き込みのことを、出力ストリームへの書き込みデータまたはレンダリングデータとも呼ぶことにする。

ファンクションprolog (...)によって、出力ストリームに対しコンポーネントデスクリプタヘッダが書き込まれる。コンポーネントデスクリプタヘッダは、アプリケーションコンポーネントを記述する名前と値のペアに関するブラウザ互換の記述である。

ファンクションbase (...)によって、出力ストリームに対しコンポーネントのベースコンテンツがレンダリングされる。ベースコンテンツは、ユーザに対して呈示されるコンポーネントの初期コンテンツとして定義される。フレームワークは、１つのページ内における複数のコンポーネントのベースコンテンツを組み合わせることができる。

その結果、ＧＵＩ９５５の記述が生じる。たとえばあるコンポーネントのベースコンテンツにはさらに、名前と値のペアたとえばコンテンツの名前と値のペアが含まれており、これはそのコンポーネントにおけるブラウザ互換の初期コンテンツの記述であり、あるいはユーザに呈示される初期コンテンツへの参照である。タイプ仕様の名前と値のペアによって、初期コンテンツに対する参照タイプを記述することができる。たとえばタイプ仕様の名前と値のペアに"HTML"が含まれているならば、対応するコンテンツの名前と値のペアにはHTML文字列のような初期コンテンツが含まれている。他の参照タイプの例として挙げられるのは"DOM"、"WML"およびリンク（他のページへのリンク）である。

タイプ仕様の名前と値のペアに参照タイプ"DOM"が含まれている場合、コンテンツの名前と値のペアにはそのページの対応するＤＯＭノードの一意の識別子が含まれている。たとえばページ生成時にサーバ９０１はページに対しHTMLコードを生成することができ、この場合、ＨＴＭＬコードはＩＤ属性を有しており、これにはＩＤ属性の値としてＤＯＭノードにおける一意の識別子が含まれている。同じことは他の参照タイプにも適用される。

ファンクションepilog (...) によって、コンポーネントをフレームワークに登録するため出力ストリームに対しクライアントサイドスクリプトが書き込まれる。

出力ストリームにコンポーネントデスクリプタを書き込むためのいくつかのファンクションを、コンポーネントクラスのスーパークラスによって扱うことができる。換言すればスーパークラスは、出力ストリームに対する複数のコンポーネント（たとえばクラスプロパティ）に対して同一であるプロパティを書くことができる。スーパークラスのサブクラスであるコンポーネントクラスによって、特定のコンポーネントのプロパティを対応する出力ストリームに加えることができる。

以下のコーディングブロックは、ツリーコンポーネントのコンポーネントデスクリプタにおける単純化されたＨＴＭＬコードの一例である：
< table id='node' >
<tr><td>id</td><td>node</td></tr>
<tr><td>parent</td><td>parentContainer</td></tr>
<tr><td>class</td><td>SPNode</td></tr>
<tr><td>positionX</td><td>0</td></tr>
<tr><td>positionY</td><td>0</td></tr>
<tr><td>Width</td><td>82</td></tr>
<tr><td>Height</td><td>25</td></tr>
<tr><td>contentType</td><td>HTML</td></tr>
<tr><td>content</td><td><HTML-string of node base content </td></tr>
. . .
</table>
<script language='JavaScript'>
SPFramework. registerComponent ('node', 'SPNode');
</script>
このコーディングブロックのテーブル部分には、たとえばファンクションprolog()により生成されるコンポーネントデスクリプタヘッダ（たとえばidentifier, parent, class, positionX, positionY, Width, Height）が含まれており、さらにたとえばファンクションbase()により生成されるコンポーネントのベースコンテンツ（たとえばcontentType, content）が含まれている。

図２Ａの実施例を再び参照すると、コンポーネントデスクリプタは時点Ｔ１においてツリー９５５−１に対応している。
このコーディングブロックのJavaScrip部分はファンクションepilog()によって生成可能である。

クライアントコントローラ１０１−１によってオリジナルモデル２００−Ｔ１が変更モデル２００−Ｔ２に変更されると（１０）、サーバレンダラ１０１−２は少なくともブラウザインクリメント３００−Ｉをブラウザ互換フォーマットで生成する（４２０）。変更１０によっては、２つ以上のブラウザインクリメントをサーバレンダラ１０１−２によって生成することもできる。たとえばブラウザインクリメント３００−Ｉは、オリジナルモデル２００−Ｔ１と変更モデル２００−Ｔ２との差分に相応する。図２Ｂを再び参照すると、ブラウザインクリメント３００−Ｉは第３レベルノードＴＬ１に相応する。その後、サーバ９０１は少なくともブラウザインクリメント３００−Ｉをクライアント９００へ送信する（４３０）。

たとえば、コンポーネントクラスのインタフェースはさらに別のインクリメント(...)を有している。ファンクションincrement()はパラメータ「プロパティ」と「アウトプット」をもつことができ、これは先に説明したインタフェースのファンクションと同様のものとすることができる。このファンクションにさらに別のパラメータ "parameter"をもたせることができ、これはパラメータ「プロパティ」と同じようにさらに別の名前と値のペアのセットである。

ファンクションincrement()が呼び出される可能性があるのは、アプリケーションコンポーネントのモデル（たとえばオリジナルモデル２００−Ｔ１）に作用するユーザのインタラクションによって（たとえばユーザが第２レベルノードＳＬ２に展開するよう指示して）対応するブラウザコンポーネントの少なくとも一部分についてそのビジュアライゼーションの変更が要求されたときである。

ファンクションincrement()は、対応するブラウザインクリメント（たとえばブラウザインクリメント３００−Ｉ）を生成し（４２０）、それを出力ストリームに書き込むタスクを有している。

パラメータ"parameter"の設けられた名前と値のペアによって、生成すべきブラウザインクリメントの厳密なフォーマットが指定される。

図２Ｂの実施例に再び戻ると、ブラウザインクリメント３００−ＩのHTMLの例には以下のステートメントを含めることができる。
< div id = '/Rl/FLl/SL2/TLl' > node label < /div > .
識別子"/R1/FL1/SL2/TL1"によりブラウザインクリメントのパスが記述され、これは時点Ｔ２において第３レベルノードＴＬ１に相応する。ノードラベルをアイコン（たとえばサークル内の"+"とすることができ、これによってノードまたはテキストまたは他の何らかのグラフィック表現がビジュアライズされる。

１つの択一的な実施形態によれば、単一のファンクション（たとえばファンクションall_inone(...)）または他の何らかの複数のファンクションを使用して、対応するデータを出力ストリームに書き込むのに必要とされる既述のタスクを実行させることができる。

以上要約すると、本発明の１つの実施形態によれば、サーバ側のコンポーネントクラスは２つのタスクを有している：
要求に応じてコンポーネントデスクリプタを出力ストリームに書き込む。この場合、コンポーネントデスクリプタはすべてのコンポーネントプロパティのリストを形成する。さらに、コンポーネントベースのコンテンツを生成し、それを出力ストリームに書き込む。

さらに、コンポーネントをフレームワークに登録するコードを出力ストリームに書き込む。

要求に応じて、パラメータにより記述されているようにブラウザインクリメントを生成する。ブラウザインクリメントを出力ストリームに書き込む。

クライアント９００にはアプリケーションコンポーネントに対応するブラウザコンポーネントが含まれており、これは相応のクライアントアセンブラ１００−１およびクライアントコントローラ１００−２を有している。たとえばクライアントコントローラ１００−２とクライアントアセンブラ１００−１はＣＰＰ１００（図１参照）の一部分であり、これはクライアント９００の記憶装置９２０内に格納されている。ブラウザコンポーネント（たとえばJavaScriptオブジェクト）のインスタンスが、対応するコンポーネントスクリプトクラスからインスタンス化される。たとえばフレームワークにおけるクライアントサイド部分は、コンポーネントデスクリプタを指すポインタを受け取るコンストラクタを使用する。ブラウザコンポーネントはコンポーネントデスクリプタからプロパティおよびプロパティ値を抽出し、それらをブラウザコンポーネントのインスタンスに付加する。ブラウザコンポーネントのインスタンスにはオリジナルのＤＯＭコンポーネント３００−Ｔ１が含まれている。

オリジナルモデル２００−Ｔ１が変更された後、クライアントアセンブラ１００−１はブラウザインクリメント３００−Ｉを受け取り（５２０）、（オリジナルモデル２００−Ｔ１に対応する）オリジナルＤＯＭコンポーネント３００−Ｔ１を少なくともブラウザインクリメント３００−Ｉによって更新する（５３０）。その結果、変更されたモデル２００−Ｔ２に対応する変更されたＤＯＭコンポーネント３００−Ｔ２が生じる。変更されたＤＯＭコンポーネント３００−Ｔ２およびオリジナルＤＯＭコンポーネント３００−Ｔ１は、同じ楕円によって描かれている。たとえば、変更されたＤＯＭコンポーネント３００−Ｔ２とオリジナルＤＯＭコンポーネント３００−Ｔ１は、対応するコンポーネントスクリプトクラスのインスタンス（たとえばJavaScriptオブジェクト）である。本発明の１つの実施形態によれば、１つのコンポーネントのコンポーネントクラスに対応するコンポーネントスクリプトクラスはクライアント９００で実行され、たとえばクライアントアセンブラ１００−１およびクライアントコントローラ１００−２をインプリメントする。たとえばクライアントアセンブラ１００−１のインタフェースにはファンクションhandleResponse (...)が含まれている。

本発明の１つの実施形態によれば、ファンクションhandleResponse()が呼び出されるのは、クライアントアセンブラ１００−１がコンポーネントクラスのファンクションincrement()からブラウザインクリメント３００−Ｉを受け取るときである（５２０）。たとえば、フレームワークはファンクションincrement()のパラメータ「アウトプット」をファンクションhandleResponse()のパラメータ「レスポンス」へ送る。ファンクションhandleResponse()のさらに別のパラメータ「ターゲット」は、受信ステップ４１０においてサーバ９０１へ送られる値である。ブラウザインクリメント３００−Ｉの受け取り（５２０）に応答してファンクションhandleResponse()が呼び出されると、パラメータ「ターゲット」によりブラウザインクリメント３００−Ｉの受取側（ブラウザコンポーネント）がクライアントに対し指示される。この受取側は最初の要求側と同じにすることができるが、最初の要求側とは異ならせてもよい。

ブラウザインクリメント３００−Ｉをサーバ９０１から取り出すための１番目の例は、スクリプトタグを使用することである。２番目の例は、隠蔽HTML iFrame要素を使用することである。

スクリプトタグ（たとえばJavaScript）を使用してブラウザインクリメントを取り出すために、フレームワークのクライアントサイド部分により以下のステップが実行される。

最初に、対応するリクエストURLが生成される。

たとえばフレームワークのクライアントサイド部分は、サーバから受け取ったページからサーバが生成した基本リクエストURLを取り出して、そのリクエスト固有のパラメータを付加する。

次にスクリプトタグ（たとえばstag）が生成され、これはSCR属性を有している。このためにたとえば、以下のようなJavaScriptステートメントを使用することができる：
var stag = createNode ("script").
次に、リクエストＵＲＬがスクリプトタグのＳＣＲ属性に割り当てられる（stag.SRC = リクエストＵＲＬ）。

その後、スクリプトタグがページのＤＯＭに加えられる。たとえばこのことは、JavaScriptステートメントdocument.body.appendChild(stag)を使用することにより達成できる。

スクリプトタグがＤＯＭに加えられると、クライアントはサーバリクエストをサーバへ送信する。サーバは、そのリクエストに対する応答を含むスクリプトステートメントを生成する。たとえば、サーバはフレームワークのサーバサイド部分に対する呼び出しを生成することができ、サーバリクエストの結果は以下のようなパラメータとして送られる：
Framework.handleResponse(result)
ファンクションhandleResponse(...)によってクライアント側における結果が解釈され、その結果はコンポーネントごとに対応するコンポーネントへ送られる。

VBスクリプトのような他のスクリプト言語も、スクリプトタグを使用したブラウザインクリメント取り出しのインプリメントに等しく使用することができる。

第２の例によれば、ブラウザインクリメント取り出しのためにスクリプトタグの代わりにiFrameが使用される。この例の場合、サーバから受け取ったページには隠蔽iFrameが含まれており、これはフレームワークのサーバサイド部分によって生成されページに組み込まれる。ついでフレームワークのクライアントサイド部分が、最初の例において挙げたような対応するリクエストURLを生成する。

その後、リクエストＵＲＬが隠蔽iFrameのＳＣＲ属性に割り当てられる。
リクエストＵＲＬがＳＣＲ属性に割り当てられると、クライアントは相応のリクエストをサーバへ送信する。サーバは１番目の例で挙げたようなスクリプトを生成することができる、あるいはクライアントにおいてどのようなアクションが要求されたのかを表す記述を生成することができる。

後者のケースであれば、クライアント側のフレームワークはその記述を解釈し、それに従って動作する。

クライアントアセンブラ１００−１が、ブラウザコンポーネントの更新が（たとえばユーザのインタラクションによって）要求されることを通知すると、クライアントコントローラ１００−２は変更リクエストを生成し、これはサーバ９０１へ送信される（５１０）。図４Ａ、図４Ｂおよび図５には、クライアントコントローラ１００−２のその他の機能について説明されている。

変更されたブラウザコンポーネント全体をサーバ９０１からクライアント９００へ送るのではなくブラウザインクリメント３００−Ｉだけを送信することによって、ネットワーク９９０を介したクライアント・サーバ通信のために僅かな帯域幅しか必要とされず、また、ページ全体を再生成するよりもブラウザインクリメント３００−Ｉを生成する方がサーバのＣＰＵ時間を消費しない。

オリジナルＤＯＭコンポーネント３００−Ｔ１がクライアントアセンブラ１００−１を介してブラウザインクリメント３００−Ｉによって更新されるならば、ページ全体を置き換えるときに頻繁に発生するスクリーンのちらつきが低減される。

図４Ａおよび図４Ｂには、本発明の１つの実施形態によるブラウザインクリメント３００−Ｉに関するクライアント側の処理について詳しく示されている。有利にはブラウザインクリメント３００−Ｉの受け取り（５２０）に応答して、クライアントコントローラ１００−２はブラウザインクリメント３００−Ｉをクライアント９００のキャッシュメモリ９２０−Ｃに格納する。

図４Ａには、ディアクティベーションリクエストＤＡＲ（deactivation-request）の受け取りに応答してブラウザインクリメント３００−Ｉを非アクティブ状態にする様子が描かれている。ディアクティベーションリクエストＤＡＲは、図２Ａまたは図２Ｂに示されているようにユーザとクライアント９００とのインタラクションによって生成することができ、あるいはコンピュータシステム９９９における他のコンピュータによって生成することができる。たとえばディアクティベーションリクエストＤＡＲはクライアントコントローラ１００−２によって受け取られる。ついでクライアントコントローラ１００−２はクライアントアセンブラ１００−１に命令して（６１０）、変更されたＤＯＭコンポーネント３００−Ｔ２におけるブラウザインクリメント３００−Ｉを非アクティブ状態し、その結果、非アクティブ状態にされたＤＯＭコンポーネント３００−Ｔ３が生じることになる。たとえばブラウザインクリメント３００−Ｉを、対応するディアクティベーションフラグのセットにより非アクティブ状態にすることができる。非アクティブＤＯＭコンポーネント３００−Ｔ３において、ブラウザインクリメント３００−Ｉが抑圧される（たとえばディアクティベーションフラグのデリートまたはセット、これは取消線によって表される）。変更ＤＯＭコンポーネント３００−Ｔ２および非アクティブＤＯＭコンポーネント３００−Ｔ３は、同じ楕円によって描かれている。図２Ｂおよび図２Ｃを再び参照すると、変更ＤＯＭコンポーネント３００−Ｔ２は時点Ｔ２におけるツリー９５５−１に対応し、ここでは第２レベルノードＳＬ２が展開されており、これには第３レベルノードＴＬ１が含まれている。

非アクティブＤＯＭコンポーネント３００−Ｔ３はＴ３におけるツリー９５５−１に対応しており、ここでは第３レベルノードＴＬ１は抑圧され、第２レベルノードＳＬ２は折り畳まれている。時点Ｔ１におけるツリー９５５−１のビジュアライゼーションは時点Ｔ３におけるビジュアライゼーションと同じであるにもかかわらず、時点Ｔ１におけるクライアント９００のステータスは時点Ｔ３におけるステータスとは異なる。なぜならばクライアントインクリメント３００−Ｉは時点Ｔ３においてキャッシュ９２０−Ｃ内で得られるが、時点Ｔ１では得られないからである。図４Ｂを参照して説明したようなリアクティベーションリクエストのケースにおいて、このことはクライアント９０の挙動に作用を及ぼす。

たとえばブラウザコンポーネントは、サーバ９０１とコンタクトをとることなくクライアント９００においてインタラクションを行うことができる。図２Ｄを再び参照すると、時点Ｔ４においてユーザはリセットボタン９５５−２を使用してリセットリクエストを生成し、ルートノードＲ１になるようツリー９５５−１を折り畳む。同様にクライアント９００において、サーバ９０１におけるリセットアプリケーションコンポーネント（図示せず）に対応するリセットブラウザコンポーネント（図示せず）は、ツリー９５５−１をビジュアライズするブラウザコンポーネントとインタラクションを行い、その結果、ブラウザコンポーネントにおけるすべての他のブラウザインクリメント（図示せず）は、対応するＤＯＭコンポーネント(たとえば非アクティブＤＯＭコンポーネント３００−Ｔ３）において、ルートノードＲ１に対応するブラウザインクリメントを除き非アクティブ状態となる。

図４Ａには、クライアントコントローラ１００−２がリアクティベーションリクエストＲＡＲを受け取ったときにブラウザインクリメント３００−Ｉが再びアクティブ状態になる様子が描かれている。クライアントコントローラ１００−２はキャッシュメモリ９２０−Ｃからブラウザインクリメント３００−Ｉを取り出し、クライアントアセンブラ１００−１に命令して、非アクティブＤＯＭコンポーネント３００−Ｔ３におけるブラウザインクリメント３００−Ｉを再びアクティブにする。リアクティベーションの結果、再びアクティブにされたＤＯＭコンポーネント３００−Ｔ３′が生じる。図２Ａの例を再び参照すると、ユーザは時点Ｔ１と同じようにクライアント９００とインタラクションを行う。とはいえこの場合には、時点Ｔ２におけるツリー９５５−１のビジュアライゼーションに相応する変更ＤＯＭコンポーネント３００−Ｔ２に到達するためにサーバ９０１にブラウザ差分ないしはブラウザインクリメント３００−Ｉを要求する代わりに、クライアント９００は単純に自分自身のキャッシュ９０２−Ｃからブラウザインクリメント３００−Ｉを取り出し、非アクティブＤＯＭコンポーネント３００−Ｔ３におけるブラウザインクリメント３００−Ｉを再びアクティブにする（５７０）。

その結果として再びアクティブにされたＤＯＭコンポーネント３００−Ｔ３′は、変更ＤＯＭコンポーネント３００−Ｔ２と同一になる。

クライアント９００におけるブラウザインクリメントのキャッシングならびにクライアント９００におけるブラウザコンポーネントのインタラクションの実現によって、クライアント９００がサーバ９０１とコンタクトをとることなく特定のイベントを処理可能であることからサーバへのリクエストの個数が減少するため、サーバ９０１の負荷が軽減される。

図５は、本発明による１つの実施形態において利用可能な２つの相補的なコンピュータプログラム製品ＣＰＰ１０１（サーバプログラム）、ＣＰＰ１００（クライアントプログラム）、ならびにそれらの主要な機能ブロックについて示す図である。たとえば、ＣＰＰ１００をブラウザとすることができる。

フレームワークは、ＣＰＰ１０１の一部分であるサーバサイド部分１００−１０およびＣＰＰ１００の一部分であるクライアントサイド部分にインプリメントされている。すでに説明したようにフレームワークによって、多数のコンポーネントに適用可能な汎用ファンクションが提供される。

ユーザに対しアプリケーションのグラフィカルユーザインタフェースを呈示するために、ＤＯＭ１００−９が使用される。この例ではＤＯＭ１００−９によって、ツリーコンポーネント９５５−１（図２Ａ参照）とリセットコンポーネント９５５−２（図２Ａ参照）を含むページが呈示される。ユーザがＣＰＰ１００と（たとえば指定したツリーノードが展開されるよう指示することで）インタラクションを行い、サーバ９０１におけるモデル２００−Ｔｎ（ｎ＝１，２〜Ｎ）に作用が及ぼされると、対応するクライアントコントローラ１００−２はユーザインタラクションに関する通知を受け取り（７０１）、サーバ９０１上で動いているＣＰＰ１０１に対し相応のリクエストを送信する（７０２）。たとえばクライアントコントローラ１００−２は特定のブラウザイベントを予約することができ、対応するブラウザイベントがユーザのインタラクションによって引き起こされたときに通知される。

ユーザインタラクションがサーバ９０１とコンタクトをとることなくクライアントコントローラ１００−２によって処理できる場合、クライアントコントローラ１００−２は対応するクライアントアセンブラ１００−１に命令して（７０２）、ユーザインタラクションに応じたＤＯＭ１００−９のビジュアライゼーションを調整するためにブラウザにより現在ビジュアライズされているページのＤＯＭ１００−９を更新させる（８０３）。

ユーザのインタラクションによってサーバ９０１の介在が要求される場合、ＣＰＰ１００は対応するリクエストをＣＰＰ１０１へ送信する（７０２）。この要求によってサーバコントローラ１０１−１は、対応するモデル２００−Ｔｎをそれ相応に変更する（７０３）。サーバレンダラ１０１−２は変更（７０３）の後、モデル２００−Ｔｎをレンダリング／生成する（８０１）。レンダリング８０１の結果は、ビジュアライゼーションのために使用可能なモデルの記述である。ついでこの記述はクライアント９００へ送られる。

本発明の１つの実施形態によれば、この記述はサーバレンダラ１０１−２からクライアントアセンブラ１００−１へ送信される（８０２）。クライアントアセンブラ１００−１はこの記述を利用して、ＤＯＭ１００−９の対応するノードを変更することによりＤＯＭ１００−９をそれ相応に更新する（８０３）。

発明の別の実施形態によれば、この記述をサーバコントローラ１０１−１からクライアントコントローラ１００−２へ送信することができ、その後、クライアントコントローラ１００−２はクライアントアセンブラ１００−１に命令して（７０２′）、ＤＯＭ１００−９をそれ相応に更新する（８０３）。

本発明のさらに別の実施形態によれば、この記述はサーバ側のフレームワーク１０１−１０からクライアント側のフレームワーク１００−１０へ送信され、そこにおいてこの記述が対応するクライアントコントローラ１００−２にディスパッチされる。

図６には、本発明によるサーバ側の観点がサーバ側の方法４００についての単純化されたフローチャートによって要約されており、これは本発明の１つの実施形態によって実施することができる。たとえば、コンピュータシステム９９９におけるサーバ９０１上のインクリメントデータを処理するための方法は、コンピュータプログラム製品１０１によって実施可能であり、そこに含まれる命令によれば、サーバ９０１のメモリ９２１にロードされると、サーバ９０１の少なくとも１つのプロセッサ９１１が方法４００を実行するようになる。方法４００には受信ステップ４１０、生成ステップ４２０ならびに送信ステップ４３０が含まれている。

受信ステップ４１０において、サーバコントローラ１０１−１はクライアントコントローラ１００−２から変更リクエストを受け取る。クライアントコントローラ１００−２は、コンピュータシステム９９９のクライアント９００において動作している。変更リクエストによってサーバ９０１はオリジナルモデル２００−Ｔ１を変更モデル２００−Ｔ２に変更し、これら双方がたとえばサーバ９０１のメモリに格納される。

生成ステップ４２０においてサーバレンダラ１０１−２は、オリジナルモデル２００−Ｔ１と変更モデル２００−Ｔ２との間の差分に相応する少なくとも１つのブラウザインクリメント３００−Ｉを生成する。

送信ステップ４３０において、サーバ９０１は少なくとも１つのブラウザインクリメント３００−Ｉをクライアント９００のクライアントアセンブラ１００−１へ送る。クライアント９００はブラウザインクリメント３００−Ｉを使用し、少なくとも１つのブラウザインクリメント３００−ＩによってオリジナルＤＯＭコンポーネント３００−Ｔ１を更新する。更新の結果、変更ＤＯＭコンポーネント３００−Ｔ２が得られ、オリジナルＤＯＭコンポーネント３００−Ｔ１はオリジナルモデル２００−Ｔ１に対応していたのに対し、これは変更モデル２００−Ｔ２に対応する。

図７Ａには、本発明によるクライアント側の観点がクライアント側の方法500についての単純化されたフローチャートによって要約されており、これは本発明の１つの実施形態によって実施することができる。たとえば、コンピュータシステム９９９におけるクライアント900上のインクリメントデータを処理するための方法は、コンピュータプログラム製品100によって実施可能であり、そこに含まれる命令によれば、クライアント９０１のメモリ920にロードされると、クライアント900の少なくとも１つのプロセッサ910が方法500を実行するようになる。方法500には送信ステップ510、受信ステップ520ならびに更新ステップ530が含まれている。

送信ステップ５１０において、クライアントコントローラ１００−２は変更リクエストをサーバコントローラ１０１−１へ送信する。サーバコントローラ１０１−１は、コンピュータシステム９９９のサーバ９０１上にインプリメントされている。

受信ステップ５２０においてクライアントアセンブラ１００−１は、少なくとも１つのブラウザインクリメント３００−Ｉをサーバ９０１から変更リクエストに対する応答として受け取る。

更新ステップ５３０において、クライアントアセンブラ１００−１はオリジナルＤＯＭコンポーネント３００−Ｔ１を少なくとも１つのブラウザインクリメント３００−Ｉによって更新し、その結果、変更されたＤＯＭコンポーネント３００−Ｔ２が生じる。オリジナルＤＯＭコンポーネント３００−Ｔ１はオリジナルモデル２００−Ｔ１に相応し、変更ＤＯＭコンポーネント３００−Ｔ２は変更モデル２００−Ｔ２に相応する。

図７Ｂには図７Ａの概略的なフローチャートが続いている。破線の矩形で表されたステップは、本発明の様々な実施形態における方法５００によって実行することができる。これらのステップにおいて、ステップ５１０〜５３０を必ずしも事前に実行しなくてもよい。インクリメントデータを処理するための１つの択一的な基本メカニズムを使用するケースにおいて、図７Ｂに示されている各ステップをクライアント側のイベント処理のためにも利用できる。

ディアクティベーションの例において、方法５００にはさらに記憶ステップ５４０とディアクティベーションステップ５５０が含まれている。

記憶ステップ５４０において、クライアント９００は少なくとも１つのブラウザインクリメント３００−Ｉを自身のキャッシュメモリ９２０−Ｃに格納する。

ディアクティベーションステップ５５０において、クライアントコントローラ１００−２はディアクティベーションリクエストＤＡＲを受け取り、その結果としてクライアントアセンブラ１００−１は、対応するＤＯＭコンポーネント内のブラウザインクリメント３００−Ｉを非アクティブ状態にする。

リアクティベーションの例において、本発明による方法５００にはさらに取り出しステップ５６０とリアクティベーションステップ５７０が含まれている。しかしディアクティベーションステップ５５０を事前に実行する必要はない。

取り出しステップ５６０においてクライアント９００は、ステップ５４０を用いて格納されていた少なくとも１つのブラウザインクリメント３００−Ｉをキャッシュメモリ９２０−Ｃから取り出す。たとえばこれを、クライアントコントローラ１００−２が受け取ったリアクティベーションリクエストＲＡＲによって開始させることができる。

その後、リアクティベーションステップ５７０においてクライアントアセンブラ１００−１は、対応するＤＯＭコンポーネントにおけるブラウザインクリメント３００−Ｉをリアクティベーションして再びアクティブな状態にする。

本発明の実施形態を実現する一例としてのコンピュータシステムを示すブロック概略図 本発明の１つの実施形態によるグラフィカルユーザインタフェースの１つの実装例を示す図 本発明の１つの実施形態によるグラフィカルユーザインタフェースの１つの実装例を示す図 本発明の１つの実施形態によるグラフィカルユーザインタフェースの１つの実装例を示す図 本発明の１つの実施形態によるグラフィカルユーザインタフェースの１つの実装例を示す図 本発明の１つの実施形態に従って動作させたときのクライアントとサーバのインタラクションについて示す図 本発明の１つの実施形態によるブラウザインクリメントに関するクライアント側の処理について示す図 本発明の１つの実施形態によるブラウザインクリメントに関するクライアント側の処理について示す図 本発明による１つの実施形態において利用可能な２つの相補的なコンピュータプログラム製品およびそれらの主要な機能ブロックについて示す図 本発明によるすなわちインクリメントデータすなわち変化分のデータを処理するためのサーバ側の方法を示す簡単なフローチャート 本発明によるインクリメントデータを処理するクライアント側の方法を示す簡単なフローチャート 本発明によるインクリメントデータを処理するクライアント側の方法を示す簡単なフローチャート

Claims (22)

1. インクリメントデータを処理するコンピュータシステム（９９９）において、
   サーバ（９０１）に格納されているアプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）を該アプリケーションコンポーネントの変更モデル（２００−Ｔ２）に変更するための変更リクエストをクライアント（９００）から受け取るサーバコントローラ（１０１−１）と、
   前記オリジナルモデル（２００−Ｔ１）と前記変更モデル（２００−Ｔ２）との差分に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成するサーバレンダラ（１０１−２）と、
   サーバ（９０１）から少なくとも１つのブラウザインクリメント（３００−Ｉ）を受け取るクライアントアセンブラ（１００−１）と、
   前記変更リクエストを生成するクライアントコントローラ（１００−２）とが設けられており、
   前記クライアントアセンブラ（１００−１）は、クライアント（９００）のところでブラウザコンポーネントのオリジナルＤＯＭコンポーネント（３００−Ｔ１）を該少なくとも１つのブラウザインクリメント（３００−Ｉ）によって更新し、前記変更モデル（２００−Ｔ２）に対応する変更ドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ２）を生じさせ、該オリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１）を前記オリジナルモデル（２００−Ｔ１）に対応させることを特徴とする、
   インクリメントデータを処理するためのコンピュータシステム（９９９）。
2. 請求項１記載のコンピュータシステム（９９９）において、
   クライアントコントローラ（１００−２）は前記少なくとも１つのブラウザインクリメント（３００−Ｉ）をクライアント（９００）のキャッシュメモリ（９２０−Ｃ）に格納し、ディアクティベーションリクエスト（ＤＡＲ）の受け取りに応答して前記クライアントアセンブラ（１００−１）に命令し、前記少なくとも１つのブラウザインクリメント（３００−Ｉ）を非アクティブ状態にすることを特徴とするコンピュータシステム。
3. 請求項２記載のコンピュータシステム（９９９）において、
   クライアントコントローラ（１００−２）は前記少なくとも１つのブラウザインクリメント（３００−Ｉ）をキャッシュメモリ（９２０−Ｃ）から取り出し、リアクティベーションリクエスト（ＲＡＲ）の受け取りに応答して前記クライアントアセンブラ（１００−１）に命令し、前記少なくとも１つのブラウザインクリメント（３００−Ｉ）を再びアクティブ状態にすることを特徴とするコンピュータシステム。
4. 請求項１から３のいずれか１項記載のコンピュータシステム（９９９）において、
   前記クライアントコントローラ（１００−２）はリセットリクエストに応答して前記クライアントアセンブラ（１００−１）に命令し、オリジナルのまたは変更されたドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１，３００−Ｔ２）をリセットすることを特徴とするコンピュータシステム。
5. 請求項１から４のいずれか１項記載のコンピュータシステム（９９９）において、
   前記のオリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）は、Javaクラス、Java Server Pagesクラス、servletクラス、Pascalクラス、Cクラス、C++クラス、Business Server Pagesクラスのグループから選択されたコンポーネントクラスによって定義されていることを特徴とするコンピュータシステム。
6. 請求項１から５のいずれか１項記載のコンピュータシステム（９９９）において、
   前記ブラウザコンポーネントは、JavaScriptクラス、JavaAppletクラス、VisualBasic Scriptクラスのグループから選択されたコンポーネントスクリプトクラスによって定義されていることを特徴とするコンピュータシステム。
7. 請求項５記載のコンピュータシステム（９９９）において、
   前記コンポーネントクラスにより、サーバコントローラ（１０１−１）とサーバレンダラ（１０１−２）の少なくとも一部分がインプリメントされることを特徴とするコンピュータシステム。
8. 請求項６記載のコンピュータシステム（９９９）において、
   前記コンポーネントスクリプトクラスにより、前記のクライアントコントローラ（１００−１）とクライアントアセンブラ（１００−２）の少なくとも一部分がインプリメントされることを特徴とするコンピュータシステム。
9. 請求項６記載のコンピュータシステム（９９９）において、
   前記コンポーネントスクリプトクラスおよび前記コンポーネントクラスは同一の階層を有することを特徴とするコンピュータシステム。
10. インクリメントデータを処理するコンピュータシステム（９９９）内のサーバ（９０１）において、
    該サーバ（９０１）に格納されているアプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）を該アプリケーションコンポーネントの変更モデル（２００−Ｔ２）に変更するための変更リクエストを、コンピュータシステム（９９９）におけるクライアント（９００）のクライアントコントローラ（１００−２）から受け取るサーバコントローラ（１０１−１）と、
    前記のオリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）との差分に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成するサーバレンダラ（１０１−２）が設けられており、
    前記少なくとも１つのブラウザインクリメント（３００−Ｉ）は、クライアント（９００）のクライアントアセンブラ（１００−１）に送信されて、オリジナルモデル（２００−Ｔ１）に対応するオリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１）が前記少なくとも１つのブラウザコンポーネント（３００−Ｉ）により更新され、変更モデル（２００−Ｔ２）に対応する変更されたドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ２）が生成されることを特徴とする、
    インクリメントデータを処理するコンピュータシステム内のサーバ。
11. インクリメントデータを処理するコンピュータシステム（９９９）内のクライアント（９００）において、
    該コンピュータシステム（９９９）内に設けられているサーバ（９０１）のサーバコントローラ（１０１−１）へ変更リクエストを送信するクライアントコントローラ（１００−２）と、
    前記サーバ（９０１）から少なくとも１つのブラウザインクリメント（３００−Ｉ）を受け取るクライアントアセンブラ（１００−１）が設けられており、該クライアントアセンブラ（１００−１）は、アプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）に対応するオリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１）を該少なくとも１つのブラウザインクリメント（３００−Ｉ）によって更新し、前記アプリケーションコンポーネントの変更モデル（２００−Ｔ２）に対応する変更ドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ２）を生じさせ、
    前記サーバコントローラ（１０１−１）は、サーバ（９０１）に格納されているオリジナルモデル（２００−Ｔ１）を変更して変更モデル（２００−Ｔ２）を形成し、
    前記サーバ（９０１）のサーバレンダラ（１０１−２）は、前記のオリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）との差分に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成することを特徴とする、
    インクリメントデータを処理するコンピュータシステム（９９９）内のクライアント。
12. 請求項１１記載のコンピュータシステム（９９９）において、
    前記クライアントコントローラ（１００−２）は、前記少なくとも１つのブラウザインクリメント（３００−Ｉ）をクライアント（９００）のキャッシュメモリ（９２０−Ｃ）に格納し、ディアクティベーションリクエスト（ＤＡＲ）の受け取りに応答して前記クライアントアセンブラ（１００−１）に命令し、前記ブラウザインクリメント（３００−Ｉ）を非アクティブ状態にすることを特徴とするコンピュータシステム。
13. 請求項１２記載のクライアント（９９９）において、
    クライアントコントローラ（１００−２）は前記少なくとも１つのブラウザインクリメント（３００−Ｉ）をキャッシュメモリ（９２０−Ｃ）から取り出し、リアクティベーションリクエスト（ＲＡＲ）の受け取りに応答して前記クライアントアセンブラ（１００−１）に命令し、前記少なくとも１つのブラウザインクリメント（３００−Ｉ）を再びアクティブ状態にすることを特徴とするコンピュータシステム。
14. 請求項１１から１３のいずれか１項記載のクライアント（９００）において、
    前記クライアントコントローラ（１００−２）はリセットリクエストに応答して前記クライアントアセンブラ（１００−１）に命令し、オリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１）をリセットすることを特徴とするコンピュータシステム。
15. コンピューターシステム（９９９）のサーバ（９０１）においてインクリメントデータを処理する方法（４００）において、
    サーバ（９０１）に格納されているアプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）を該アプリケーションコンポーネントの変更モデル（２００−Ｔ２）に変更するための変更リクエストを、コンピュータシステム（９９９）のクライアント（９００）に属するクライアントコントローラ（１００−２）からサーバコントローラ（１０１−１）が受け取るステップ（４１０）と、
    オリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）との差分に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）をサーバレンダラ（１０１−２）が生成するステップ（４２０）と、
    該少なくとも１つのブラウザインクリメント（３００−Ｉ）をクライアント（９００）のクライアントアセンブラ（１００−１）に送信するステップ（４３０）が設けられており、該ステップ（４３０）により、前記オリジナルモデル（２００−Ｔ１）に対応するオリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ１）を前記少なくとも１つのブラウザインクリメント（３００−Ｉ）によって更新し、変更モデル（２００−Ｔ２）に対応する変更ドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ２）を生成することを特徴とする、
    コンピュータシステムのサーバにおいてインクリメントデータを処理する方法。
16. コンピュータシステム（９９９）のクライアント（９００）においてインクリメントデータを処理する方法（５００）において、
    クライアントコントローラ（１００−２）からコンピュータシステム（９９９）におけるサーバ（９０１）のサーバコントローラ（１０１−１）へ変更リクエストを送信するステップ（５１０）と、
    該変更リクエストに対する応答として、少なくとも１つのブラウザインクリメント（３００−Ｉ）をサーバ（９０１）からクライアントアセンブラ（１００−１）が受け取るステップ（５２０）と、
    アプリケーションコンポーネントのオリジナルモデル（２００−Ｔ１）に対応するオリジナルドキュメントオブジェクトモデル（ＤＯＭ）コンポーネントを、該少なくとも１つのブラウザインクリメント（３００−Ｉ）によって更新するステップ（５３０）が設けられており、該更新ステップ（５３０）により、前記アプリケーションコンポーネントの変更モデル（２００−Ｔ２）に対応する変更ドキュメントオブジェクトモデル（ＤＯＭ）コンポーネント（３００−Ｔ２）を生成し、
    前記サーバコントローラ（１０１−２）は、サーバ（９０１）に格納されているオリジナルモデル（２００−Ｔ１）を変更して変更モデル（２００−Ｔ２）を形成し、
    前記サーバ（９０１）のサーバレンダラ（１０１−２）は、オリジナルモデル（２００−Ｔ１）と変更モデル（２００−Ｔ２）との差に対応する少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成することを特徴とする、
    コンピュータシステムのクライアントにおいてインクリメントデータを処理する方法。
17. 請求項１６記載の方法（５００）において、
    前記少なくとも１つのブラウザインクリメント（３００−１）をクライアント（９００）のキャッシュメモリ（９２０−Ｃ）に格納するステップ（５４０）が設けられていることを特徴とする方法。
18. 請求項１７記載の方法（５００）において、
    前記クライアントコントローラ（１００−２）がディアクティベーションリクエスト（ＤＡＲ）を受け取ったことに応答して、クライアントアセンブラ（１００−１）がブラウザインクリメント（３００−Ｉ）を非アクティブ状態にするステップ（５５０）が設けられていることを特徴とする方法。
19. 請求項１８記載の方法（５００）において、
    クライアントアセンブラ（１００−１）が前記少なくとも１つのブラウザインクリメント（３００−Ｉ）をキャッシュメモリ（９２０−Ｃ）から取り出すステップ（５６０）と、
    クライアントコントローラ（１００−２）がリアクティベーションリクエスト（ＲＡＲ）を受け取ったことに応答して、該少なくとも１つのブラウザインクリメント（３００−Ｉ）を再びアクティブ状態にするステップ（５７０）が設けられていることを特徴とする方法。
20. サーバ（９０１）のメモリ（９２１）にロードされると、該サーバ（９０１）の少なくとも１つのプロセッサ（９１１）に対し請求項１５記載のステップを実行させる命令を有することを特徴とするコンピュータプログラム製品（１０１）。
21. クライアント（９００）のメモリ（９２０）にロードされると、該クライアント（９００）の少なくとも１つのプロセッサ（９１０）に対し請求項１６から請求項１９のいずれか１項記載のステップを実行させる命令を有することを特徴とするコンピュータプログラム製品（１００）。
22. インクリメントデータを処理するコンピュータシステム（９９９）において、
    変更リクエストに対する応答として、サーバ（９０１）上のアプリケーションコンポーネントのモデル（２００−Ｔｎ）を変更（７０３）するサーバコントローラ（１０１−１）と、
    モデル（２００−Ｔｎ）が変更（７０３）された後、少なくとも１つのブラウザインクリメント（３００−Ｉ）を生成するサーバレンダラ（１０１−２）と、
    サーバ（９０１）から少なくとも１つのブラウザインクリメント（３００−Ｉ）を受け取って、クライアント（９００）におけるブラウザコンポーネントのインスタンスを該少なくとも１つのブラウザインクリメント（３００−Ｉ）により更新し、該ブラウザコンポーネントは前記アプリケーションコンポーネントに対応することを特徴とする、
    インクリメントデータを処理するコンピュータシステム。

Images