1. JP2008537217 - ポータブル・ポートレットを選択および配信する方法ならびに装置

本発明は、一般にハイパーテキスト・ポータルおよびポートレットに関する。詳細には、本発明は、ポートレットとポータルとの間でデータを共有する際の柔軟性および再使用可能性の向上を可能にするポートレット・データ共用システム、方法、ならびにプログラム製品を提供する。

ポータルまたはポータル・プログラムは、パーソナライゼーション、様々なソースからのコンテンツ集約を提供し、フォーマッティングおよびその他のプレゼンテーション層機能を提供し、任意選択で、異種のウェブ・サービスにアクセスするのに必要なシングル・サインオンを提供することのできるウェブ・ベースまたはハイパーテキスト・ベースのアプリケーションである。ポータル・サーバは、ユーザにデータを配信する、組み合わされたソフトウェア、ハードウェア、およびクライアント・データであってもよい。

インターネットの使用がよりパーベイシブとなるにつれて、ウェブ・コンテンツを表示するためのよりよい技術が常に開発されている。この範囲で、ポータル・サーバは、ユーザにウェブ・コンテンツを配信する際に好まれる技術となった。通常、ポータル・サーバは、ポータル・プログラム（例えばニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションのＷＥＢＳＰＨＥＲＥ（Ｒ））を含み、ポータル・プログラムは、１つまたは複数のポートレットを含むポータル・ページとしてウェブ・コンテンツを配置する。

ポートレットは、コンテンツおよび機能のカプセル化である。ポートレットは、ウェブ・ベースのコンテンツ、アプリケーション機能、および資源へのアクセスを組み合わせる再使用可能コンポーネントである。ポートレットはポータル・ページとして組み立てられ、ポータル・ページはポータル実装を構成する。ポートレットは、そのコンテンツをポータル・ページ上のウィンドウ・ライクなディスプレイ内に提示する点でＷｉｎｄｏｗｓ (登録商標）（Ｒ）アプリケーションと似ている。Ｗｉｎｄｏｗｓ (登録商標）（Ｒ）アプリケーションと同様に、ポートレット・ウィンドウは、コントロールを含むタイトル・バーを有し、ユーザがアプリケーションを拡大（最大化）および縮小（最小化）することを可能にする。

各ポートレットは、ユーザのプリファレンスに従って指定されたウェブ・コンテンツのセクションを含む。例えば、ユーザは、ニュース、天気、およびスポーツに関するポートレットを有するユーザ自身のポータル・ページを確立することができる。したがって、ポートレット・ウィンドウは、ポートレット・プログラムの外面的発現（outward manifestation）である。ポートレット・プログラムは、適切なコンテンツ・プロバイダから所望のウェブ・コンテンツを得て、ウェブ・コンテンツを集約することができる。各ポートレットは、ウェブ・コンテンツが適切なポートレット・ウィンドウまたはサブウィンドウ内に表示されるように、ポータルと連係してマークアップ（例えばＨＴＭＬ）を生成する。このポータル技術により、個々のウェブ・ユーザ向けにパーソナライズされた「ホームページ」が爆発的に増加した。

開発者は、市販のアプリケーションのためのポートレット技術を適用し始めている。例えば、ポータル・ページを使用して、従業員、顧客、サプライヤなどのためのページをカスタマイズすることができる。こうしたアプリケーションでは、各ポートレットで提示されるデータがしばしば関係付けられる。例えば、旅行ポートレットの「行先都市」フィールドのデータを、天気ポートレットの「対象都市」フィールドと共用することができる。現在の実装では、ポートレットは、パラメータをメッセージングし、または渡すことにより、別の既知のポートレットとデータを共用することができる。しかし、ポートレット開発者は、データ共用を実装するために、すべての関与するポートレットの詳細な知識を有さなければならない。さらに、データを共用するかどうか、およびどのデータを共用するかの判定は、ポートレットが開発されるときに固定される。こうした制限により、ポートレットの再使用可能性および相互運用性が制限される。

情報を共用し、ポータルに集約する従来技術の方法は、とりわけシンプル・オブジェクト・アクセス・プロトコル（ＳＯＡＰ）を含んでいた。ＳＯＡＰは、好ましくはハイパーテキスト転送プロトコル（ＨＴＴＰ）およびその拡張可能なマーク付け言語（ＸＭＬ）を情報交換のための機構として使用することにより、ある種類のオペレーティング・システムで動作するプログラムが同じ種類または別の種類のオペレーティング・システムでのプログラムと通信するための方式である。ＳＯＡＰは、あるコンピュータ内のプログラムが別のコンピュータ内のプログラムを呼び出し、それに情報を渡すことができるように、ＨＴＴＰヘッダおよびＸＭＬファイルをどのように符号化するかを指定する。ＳＯＡＰはまた、呼び出されたプログラムがどのように応答を返すことができるかも指定する。
patcit 1 : 米国公開特許出願２００２／０１６９８５２Ａ１

コンテンツを追加する旧来の方式は、統合開発環境（ＩＤＥ）、すなわち通常はコード・エディタ、コンパイラ、デバッガ、およびグラフィカル・ユーザ・インターフェース（ＧＵＩ）ビルダからなるアプリケーション・プログラムとしてパッケージ化されたプログラミング環境を使用することを含むことがあった。その前でさえ、異種のソースからのコンテンツを統合することはしばしば、ＨＴＭＬを編集し、ＣＧＩ機能を追加する労力を要するプロセスである可能性があった。いずれの場合も、労力を要し、時間がかかり、難解な言語のセマンティクスおよびフォーマッティングの特別な知識が求められた。これは確かに、情報を求めてウェブをサーフィンする大多数の人々が行うべき作業ではなかった。

米国公開特許出願２００２／０１６９８５２Ａ１、SYSTEMAND METHOD FOR DYNAMICALLY INTEGRATING REMOTE PORTLETS INTO PORTALS、IBMにおいて、ある程度の進歩がなされた。従来技術の発明は、ポータルでリモート・ポートレットをインストールし、それにアクセスし、それを使用する単純化された手続きを提供するための、称賛に値する目標を有していた。従来技術は、ＳＯＡＰおよびその他のプロトコルがメニュー形式のインターフェースからポートレットを選び、不特定の順序でそのようなポートレットをポータルに追加することをサポートすることのできる方式を示したが、従来技術は、アクティブにレンダリングされたポートレットを親ページでアドホックに選択し、そのようなポートレットを、ユーザが望んだポータル・ウィンドウ・リアル・エステートの厳密な区域内に次々に配置するという現代的概念に対処することを怠っていた。

第１の態様によれば、ポートレット状態を有するポートレットを選択する方法であって、装飾およびイベント・トリガを有するポートレットをレンダリングするステップと、イベント・トリガに対応するユーザ・イベントをサーバで受信するステップと、ユーザ・イベントに基づいてポートレット状態を直列化するステップと、ポートレット状態をキーに格納するステップと、ポートレット状態を有するキーをクライアントに送るステップとを含む方法が提供される。

第２の態様によれば、持続ポータル・セッションを確立する方法であって、サーバでハイパーテキスト転送プロトコル要求を受信するステップと、ポータル・ウィンドウ上のエリアに対応する第１イベント・トリガを有するポータル・ウィンドウをレンダリングするステップと、イベント・トリガを受信するステップと、ポートレットを有するポートレット・リファレンスを有するキーを受信するステップと、キーをオリジン・サーバに送信するステップと、キーに従ってポートレットをレンダリングするステップとを含む方法が提供される。

第３の態様によれば、ポートレット状態を有するポートレットを選択するサーバであって、装飾およびイベント・トリガを有するポートレットをレンダリングするプロセッサと、プロセッサに結合され、イベント・トリガに対応するユーザ・イベントをサーバで受信するネットワーク・アダプタと、プロセッサに結合され、ユーザ・イベントに基づいてポートレット状態を直列化する手段手段と、ポートレット状態をキーに格納するメモリと、ポートレット状態を有するキーをクライアントに送るＬＡＮアダプタとを備えるサーバが提供される。

第４の態様によれば、持続ポータル・セッションを確立するシステムであって、サーバでハイパーテキスト転送プロトコル要求を受信する手段と、ポータル・ウィンドウ上のエリアに対応する第１イベント・トリガを有するポータル・ウィンドウをレンダリングする手段と、イベント・トリガを受信する手段と、ポートレットを有するポートレット・リファレンスを有するキーを受信する手段と、キーをオリジン・サーバに送信する手段と、キーに従ってポートレットをレンダリングする手段とを備えるシステムが提供される。

本発明は、コンピュータ・ソフトウェアとして実装することができる。

ポートレット・データを共用するシステム、方法、およびプログラム製品が提供される。具体的には、別個のサーバと共用することができ、かつ分離サーバ（disjoint server）を介して共用することのできるポートレット内のデータへのアクセスを開発者が定義することを可能にするシステム、方法、およびプログラム製品が提供されることが好ましい。さらに、ユーザまたは開発者がポートレット間のデータ共用を定義することを可能にするポートレットを用いた解決策が提供されることが好ましい。こうした特徴は、より柔軟であり、様々なアプリケーションで再使用可能なポートレットを提供する。

本発明は、ポートレットを選択する方法、装置、およびコンピュータ・プログラム製品を提供する。最初に、好ましくは、オリジン・サーバは、ユーザまたはクライアントのｈｔｔｐ（ハイパーテキスト転送プロトコル）要求に応答してポートレットをレンダリングする。ポートレットは、好ましくはポートレット・ウィンドウとして表示され、好ましくは、ポインタ・アクションまたはイベントに応答するボタンまたはグラブ可能フレームを有する。ユーザはボタンをクリックし、好ましくは、オリジン・サーバはポートレットの状態を直列化する。好ましくは、オリジン・サーバはポートレット状態をキーに格納し、キーをクライアントに送る。

後で、ユーザのお気に入りのポータルで、本発明の一実施形態は、ｈｔｔｐ要求を受信し、ポータル・ウィンドウの一部に対応するイベント・トリガを少なくとも有するポータル・ウィンドウをレンダリングする。ポータルは、付随するポートレット状態のキーを受信する。キーは、クライアントとオリジン・サーバとの間のセッションを持続させるための手段として働くが、キーをオリジン・サーバに通信するためにポータル・サーバ（分離サーバと呼ばれることもある）をプロキシとして使用する。分離サーバは、キーに従ってポートレットをレンダリングする。

次に、単なる例として、添付の図面を参照しながら本発明の好ましい実施形態を説明する。

当技術分野で周知の通り、「ポートレット」という用語は、ポータル・ページの可視セクションと、可視セクションでの表示のためにポータル・ページ内のコンテンツを取得および集約するのに使用されるプログラム・コードの両方を指すことを理解されたい。したがって、ポートレットは、（１）ポータル・ページの一部として表示される可視ポートレット、および（２）可視ポートレットで表示されるコンテンツを得るためのプログラム・コードを含むポートレット・プログラムという少なくとも２つの面を有すると理解されたい。

集約は、ウェブ・ページ内の様々なソースからコンテンツを統合するプロセスである。

本発明の実施形態の一利点は、コンテンツをポータルとして構築および集約するユーザ・アクションが単純化されることである。単純化は、２つのブラウザ・ウィンドウが表示された状態で、ユーザがブラウザ・ウィンドウから（受信サーバでホストされる）第２のブラウザ・ウィンドウにポートレットをドラッグし、そのようなブラウザ・ウィンドウをレンダリングする新しいサーバ、恐らくは分離サーバが、別のサーバ（恐らくは分離サーバ）でホストすることのできるポートレットへ繰り返しアクセスすることを保証することが可能となる形で達成可能である。実質的に、単純なドラッグ・アンド・ドロップ・アクションで比較的永続的な追加を行うことができる。

次に各図、特に図１を参照すると、本発明を実装することのできるデータ処理システムの絵画表現が、本発明の好ましい実施形態に従って示されている。システム・ユニット１０２と、ビデオ・ディスプレイ端末１０４と、キーボード１０６と、フレキシブル・ディスク・ドライブおよびその他のタイプの永続的かつ取外し可能な記憶媒体を含むことのできる記憶装置１０８と、マウス１１０とを含むコンピュータ１００が示されている。例えばジョイスティック、タッチパッド、タッチ・スクリーン、トラックボール、マイクロフォンなどの追加の入力装置をパーソナル・コンピュータ１００に含めることができる。コンピュータ１００は、ニューヨーク州アーモンクのインターナショナル・ビジネス・マシーンズ・コーポレーションの製品であるＩＢＭ（Ｒ）ｅＳｅｒｖｅｒ（Ｒ）コンピュータやＩｎｔｅｌｌｉＳｔａｔｉｏｎ（Ｒ）コンピュータなどの任意の適切なコンピュータを使用して実装することができる（ＩＢＭ、ｅＳｅｒｖｅｒ、およびＩｎｔｅｌｌｉＳｔａｔｉｏｎは、インターナショナル・ビジネス・マシーンズ・コーポレーションの米国およびその他の国における商標）。図示される表現はコンピュータを示すが、本発明の他の実施形態は、ネットワーク・コンピュータなどの他のタイプのデータ処理システムとして実装することができる。好ましくは、コンピュータ１００は、コンピュータ１００内での動作の際にコンピュータ可読媒体内にあるシステムソフトウェアによって実装することのできるグラフィカル・ユーザ・インターフェース（ＧＵＩ）も含む。

次に図２を参照すると、一実施形態に従って本発明を実装することのできるデータ処理システムのブロック図が示されている。データ処理システム２００は、本発明のプロセスを実装するコードまたは命令を配置することのできる、図１のコンピュータ１００などのコンピュータの一例である。データ処理システム２００は、ＰＣＩローカル・バス・アーキテクチャを使用する。図示される例はＰＣＩバスを使用するが、ＡＧＰやＩＳＡなどの他のバス・アーキテクチャも使用することができる。プロセッサ２０２およびメイン・メモリ２０４は、ＰＣＩブリッジ２０８を介してＰＣＩローカル・バス２０６に接続される。ＰＣＩブリッジ２０８はまた、プロセッサ２０２用の統合メモリ・コントローラ／キャッシュ・メモリも含むことができる。直接構成要素相互接続またはアドイン・コネクタを介してＰＣＩローカル・バス２０６への追加の接続を行うことができる。図示する例では、ローカル・エリア・ネットワーク（ＬＡＮ）アダプタ２１０、ＳＣＳＩホスト・バス・アダプタ２１２、および拡張バス・インターフェース２１４が、直接構成要素接続によってＰＣＩローカル・バス２０６に接続される。一方、オーディオ・アダプタ２１６、グラフィックス・アダプタ２１８、およびオーディオ／ビデオ・アダプタ２１９は、拡張スロットに挿入されたアドイン・ボードによってＰＣＩローカル・バス２０６に接続される。拡張バス・インターフェース２１４は、キーボード／マウス・アダプタ２２０、モデム２２２、および追加のメモリ２２４に対する接続を提供する。ＳＣＳＩホスト・バス・アダプタ２１２は、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭドライブ２３０に対する接続を提供する。典型的なＰＣＩローカル・バス実装は、３つまたは４つのＰＣＩ拡張スロットまたはアドイン・コネクタをサポートする。

オペレーティング・システムがプロセッサ２０２上で動作し、図２のデータ処理システム２００内の様々な構成要素の制御を調整および提供するのに使用される。オペレーティング・システムは、Ｍｉｃｒｏｓｏｆｔ（Ｒ） Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＷｉｎｄｏｗｓ (登録商標）（Ｒ）ＸＰなどの市販のオペレーティング・システムでもよい（ＭｉｃｒｏｓｏｆｔおよびＷｉｎｄｏｗｓ (登録商標）は、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎの米国およびその他の国における商標）。Ｊａｖａ（登録商標）（Ｒ）などのオブジェクト指向プログラミング・システムがオペレーティング・システムと共に動作することができ、データ処理システム２００上で実行中のＪａｖａ（登録商標）（Ｒ）プログラムまたはアプリケーションからオペレーティング・システムへの呼出しを実現する。「Ｊａｖａ（登録商標）（Ｒ）」は、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．の米国およびその他の国における商標である。オペレーティング・システム、オブジェクト指向プログラミング・システム、およびアプリケーションまたはプログラムに対する命令は、ハード・ディスク・ドライブ２２６などの記憶装置上に配置され、メイン・メモリ２０４にロードしてプロセッサ２０２で実行することができる。

図２のハードウェアは実装に応じて変化することがあることを当業者は理解されよう。フラッシュ読取り専用メモリ（ＲＯＭ）、同等の不揮発性メモリ、光ディスク・ドライブなどのその他の内部ハードウェアまたは周辺装置を、図２に示すハードウェアに加えて、またはその代わりに使用することができる。さらに、本発明の実施形態のプロセスをマルチプロセッサ・データ処理システムに適用することができる。

例えば、データ処理システム２００が任意選択でネットワーク・コンピュータとして構成された場合、データ処理システム２００は、ＳＣＳＩホスト・バス・アダプタ２１２、ハード・ディスク・ドライブ２２６、テープ・ドライブ２２８、およびＣＤ−ＲＯＭ２３０を含まないことがある。その場合、コンピュータ、正確に言えばクライアント・コンピュータは、ＬＡＮアダプタ２１０、モデム２２２などの何らかのタイプのネットワーク通信インターフェースを含む。別の例として、データ処理システム２００は、データ処理システム２００が何らかのタイプのネットワーク通信インターフェースを備えるか否かにかかわらず、何らかのタイプのネットワーク通信インターフェースに依拠することなくブート可能であるように構成されたスタンド・アロン・システムでもよい。別の例として、データ処理システム２００は、オペレーティング・システム・ファイルまたはユーザ生成データあるいはその両方を格納する不揮発性記憶を提供するためにＲＯＭまたはフラッシュＲＯＭあるいはその両方と共に構成された携帯情報端末（ＰＤＡ）装置でもよい。

図２に示す例および上述の例は、アーキテクチャ上の制限を示唆するものではない。例えば、データ処理システム２００は、ＰＤＡの形態を取ることに加えて、ノートブック・コンピュータまたはハンドヘルド・コンピュータでもよい。データ処理システム２００はキオスクまたはウェブ・アプライアンスでもよい。

本発明の実施形態のプロセスは、コンピュータで実装される命令を使用してプロセッサ２０２で実行され、コンピュータで実装される命令は、例えばメイン・メモリ２０４、メモリ２２４、１つまたは複数の周辺装置２２６〜２３０などのメモリ内に配置することができる。

次に図３を参照すると、ブロック図が、好ましい実施形態に従って本発明を実装することのできる１つまたは複数のサーバとクライアントの関係を示す。図３には、マークアップまたはその他のファイルを提供することのできるオリジン・サーバ（発信サーバと呼ばれることもある）３０１が示されている。マークアップ言語を含むファイルを取り出して送信すること、オンザフライで作成して送信すること、またはファイルの取り出しとオンザフライで作成したマークアップの追加を何らかの形で組み合わせることにより、マークアップを「レンダリング」することができる。レンダリングは、完全な十分に形成されたマークアップ・ファイルまたはストリームがプロセスの終わりに生成されるように、または十分に形成されたマークアップ・ファイルまたはストリームのフラグメントが生成されるように行うことができる。レンダリングは一般に要求、例えばクライアント３０５からのハイパーテキスト転送プロトコル（ＨＴＴＰ）要求の受信時に行われる。レンダリングされたファイルまたはストリームの多くの要素はブラウザ上に表示することができるが、コメントや時々実行されるプログラム命令などの一部の要素は表示されないことがある。レンダリングの多くの態様は、図２のプロセッサ２０２のプログラム制御下にある。

オリジン・サーバ３０１、クライアント３０５、および分離サーバ３０３は、図１の１つまたは複数のデータ処理システムの多くの部分、さらにはすべての部分を実装することができる。オリジン・サーバ３０１、クライアント３０５、および分離サーバ３０３はネットワークによって相互接続することができ、ネットワークは、話を簡単にするために図示されていない。そのようなネットワークは、例えばプライベートＬＡＮを介して、堅固で一定の接続サービスを提供することができる。そのようなネットワークは、Ｗｉ−Ｆｉまたは他のワイヤレス環境の場合のように、一時的かつ断続的なこともある。

一般に、オリジン・サーバ３０１は、クライアント３０５にポートレットの初期レンダリングを提供し、クライアント３０５は、自信が選択したポータル、例えば分離サーバ３０３（受信サーバと呼ばれることもある）において後で使用したい少なくとも１つのポートレットをオリジン・サーバ３０１に示す。オリジン・サーバ３０１は、ファイルと考えることができ、ストレージに不揮発性式に格納することのできる共用セッション３０７を作成することができる。共用セッション３０７はより一時性（ephemeral）でよいが、含むことができるのはサーバ３０１から出力されたデータ・ストリームにすぎず、伝送中に占有する位置に応じて様々な形を取ること、すなわち、ネットワークにわたってフラグメントとして存在するようにパケット化し、パケット交換することができる。

さらに、オリジン・サーバは、同じ管理ドメイン内のサーバのクラスタでもよい。したがって、各サーバは、共通データベースを共用すること、またはサーバ間でそのようなデータを分散させることができる。クラスタ内のサーバの１つと確立されたトランザクションまたはプロトコルをクラスタ全体とのトランザクションまたはプロトコルと見なすことができる。同様に、分離サーバは、それ自体の共通管理ドメイン内の処理を複数のサーバに調整させることによってスケーリングすることができる。

共用セッション３０７は、ポートレットに関する状態情報に加えて、クライアントと、分離サーバと、オリジン・サーバ内のポートレットの組合せを一意に定義するキーまたは固有文字列として存在することができ、ポートレットに関する状態情報は、キーが参照するオブジェクトでもよい。

図４に、図３のオリジン・サーバ３０１が本発明の一実施形態に従って実行することのできるステップを示す。クライアント３０５は、オリジン・サーバ３０１にＨＴＴＰ要求を行うことができる。オリジン・サーバは、例えば図２のネットワーク・アダプタ２０１を介してそのような要求を受信し（ステップ４０１）、マークアップ・ファイルおよび恐らくは何らかのコードを送信することによって第１ポートレットをレンダリングすることができる（ステップ４０３）。マークアップは、オリジン・サーバで全体的または部分的にオンザフライで生成することができる。オリジン・サーバ３０１とクライアント３０５との間のセッションでは、オリジン・サーバは、第１ポートレットに適用可能である第１装飾も提供し（ステップ４０５）、装飾は、ボタン制御、ウィンドウ・グラブ・バー、またはその他の任意のアクティブな装飾である。装飾は、イベント・トリガに基づいてポートレットの脱水（dehydration）（以下で説明する）を実施するサーブレットまたはその他のプログラムに結合することができる。そのようなイベント・トリガは、ポートレット・ウィンドウ内またはその周りに関して座標で示される位置でのポインタ、例えばマウスのクリックを含むことができる。

オリジン・サーバは、第２ポートレットをレンダリングし（ステップ４０７）、続いて第２装飾をレンダリングする（ステップ４０９）。第１ポートレットと同様に第２ポートレット（ステップ４０７）は、マウス・クリックなどのポインティング・デバイス・ユーザ・イベントで与えられるイベント・トリガを待つ、それに関連するコードを有することができる。

オリジン・サーバは、クライアントをソースとするユーザ・イベントを受信することができる（ステップ４１１）。ユーザ・イベントがポートレット装飾の１つに関連するイベント・トリガに対応する場合（ステップ４１３）、オリジン・サーバはポートレットのコードを起動することができる。そうでない場合、オリジン・サーバは、ユーザ・イベントの受信（ステップ４１１）を待ち続ける。ポートレットのコードが起動された場合、そのようなコードは、例えば対応するポートレットを直列化して、共用セッションに格納することのできるオブジェクトまたはその他のエンティティを生成することにより、ポートレットを脱水する（ステップ４１５）。直列化は、後の何らかの使用のために格納する目的でオブジェクトの状態がＸＭＬやバイナリフォーマットなどの何らかの直列データ・フォーマットに変換されるプロセスである。言い換えれば、オブジェクト、例えばポートレットは、再び必要とされるまで、「脱水」され、取って置かれる。

脱水されたオブジェクトは、単に状態データ、例えばポートレット状態を含むことができる。ポートレット状態および何らかのリファレンス、例えば完全修飾ＵＲＩ（Uniform Resource Identifier）を、例えば図２のメイン・メモリ２０４内のキーに格納することができる。次いで、ＬＡＮアダプタを介してキーをクライアントに送ることができる（ステップ４１７）。ＬＡＮアダプタは図２のネットワーク・アダプタ２１０でもよい。

図３のオリジン・サーバは、状態データを使用して、装置から一時ｈｔｔｐ要求を後で受信することができ、そのような状態データは、恐らくはセッションの固有識別子を含む。オリジン・サーバがセッションを認証することができる範囲で、オリジン・サーバは、セッションのユーザ、または分離サーバなどの任意の仲介に課金することができる。そのような課金は、１日の使用ごとに、１時間の使用ごとに、またはｈｔｔｐ要求ごとに行うことができる。そのような使用は、オリジン・サーバへのｈｔｔｐ要求を行う動作を含むことができ、ｈｔｔｐ要求は固有識別子を伴う。

クライアント自体にはユーザが手動で指示することができる。ローカルにキーを有するユーザは、次に何を行うかに関して高い柔軟性を有する。キーを後の使用のためにメモリに格納すること、キーをクライアント内部のウェブ・ページに配置すること、またはＸＭＬ ＨＴＴＰセッションを介してキーをユーザのお気に入りのポータルに送ることができる。この第３のケースを次に検討する。

図５に、第１オリジン・サーバとは異なるものでもよい、本発明の一実施形態による第２サーバで実施することのできるステップを示す。実際には、第２サーバは、第１サーバとは異なる管理ドメイン内にあってもよく、したがって分離サーバでもよい。この実施形態では、このサーバを分離サーバと呼ぶが、第２サーバはオリジン・サーバと同じサーバであってもよいことを理解されたい。

分離サーバは、クライアントからＨＴＴＰ要求を受信することができる（ステップ５０１）。分離サーバは、ユーザ・プリファレンスと、クライアントに対して既に確立された構成とを伴うアカウントを有することができる。認証に関しては、特に新しいアカウントが分離サーバで生成中であるときは、任意選択でよい。分離サーバは、通常はポータルと見なされるものを提供することができる。分離サーバは、例えばユーザが最初にアカウントを確立したときに、まばらであり、ほとんど装飾なしにレンダリングされるポータルを提供またはレンダリングすることができる（ステップ５０３）。ポータルは、ユーザ・イベントと、ポータル・ウィンドウであるレンダリングされたウィンドウ内のその相対位置とを検出するための何らかの方式を提供することを除き、非常にわずかなコンテンツからなることができる。この最小限のビューにおいて、第１イベント・トリガを有する第１装飾をレンダリングすることができ（ステップ５０５）、第２ユーザ・イベント・トリガを有する第２装飾をレンダリングすることができる（ステップ５０７）。そのような装飾は、ポータル・ウィンドウ内の異なるエリアを占有することができ、したがって、ポータル・ウィンドウ内で特定のポートレットがどこに現れるように構成されるべきかに関するプリファレンスをユーザが伝える手段を提供する。

第１装飾は、表示されるポータルのエリア内のマウス・クリックに応答することができる。エリアは仮想エリアであり、ディスプレイ・サイズの小ささのために、ディスプレイ、ウィンドウ、またはその両方の縁部を超えて延びることができることを理解されたい。

分離サーバは、ユーザ・イベントを受信することができる（ステップ５０９）。場合によっては、ユーザ・イベントは第１装飾または第２装飾に関連するユーザ・イベント・トリガに関係せず（ステップ５１１）、したがって、フロー中で、イベントを待ち続けるループが行われる。そうでない場合、ユーザ・イベントは装飾のユーザ・イベント・トリガに対応する（ステップ５１１）。

次いで、イベント・トリガは、分離ポータル内のコードに、以前に得られたキーを検査または受信させ（ステップ５１３）、それを再水和（rehydrate）させ、すなわち、オリジン・サーバにおけるその位置からポートレット・オブジェクトを取得させ、キーの状態をそれに適用させる。キーの状態をポートレットに適用するステップは、ポートレットに格納された方法またはステップのうちの少なくとも１つを実行することを含む。キーは、ユーザの認証、必要なウェブ資源の可用性（ＩＳＰに障害が発生するか、またはオリジン・ホストが何らかの種類のＤＯＳアタックを受けた場合に、ウェブ資源が利用可能でない可能性があるため）などの何らかの妥当性検査を通過することができる（ステップ５１５）。妥当性検査のｙｅｓ分岐（ステップ５１５）が生じた場合、分離サーバは、ユーザ・イベントのターゲットであった装飾の位置に一致するポータル・ウィンドウの相対位置のキーに対応するポートレットをレンダリングする（ステップ５１９）。

（例えばマウスのクリックまたはリリースの時のマウスの座標で与えられる）相対位置のポートレットのレンダリングに続いて、分離サーバは、ポートレット状態、およびポータル・ウィンドウ内のポートレットの相対座標を再呼出しするデータ構造内にキーを格納することができる（ステップ５２１）。ポータルは、カラー、フォント、その他の美的選択肢など、ユーザによって先に選択されたプリファレンスによってポートレット・ウィンドウの表示を修正することができ、それによってポートレットが、ポータル（ＵＲＩ）への後続のＨＴＴＰ要求で同一の一般的方式で永続的に示される。

（どんな理由であれ）妥当性検査でキーが有効でなければ（ステップ５１５）、分離サーバがユーザ・イベントを待ち続けるようにすることができる（ステップ５０９）。ＸＭＬ ＨＴＴＰを介してキーを受信するステップ（ステップ５１３）は、ポータルがキーを要求するステップも含むことができる。

分離サーバは、ユーザに関するポートレットの集まりを集約する特権に関して課金することができる。課金は、ユーザが分離サーバ上に配置するポートレットごとに確立することができる。

本発明の一実施形態は、Ｊａｖａ（登録商標）（Ｒ）および関連するプログラミング言語に依拠することができ、いくつかの機能を実施するのにＪＶＭに依拠することができる。

本発明を完全に機能するデータ処理システムの状況で説明したが、本発明のプロセスをコンピュータ可読媒体の形態の命令および様々な形態として配布することができ、その配布を実施するのに実際に使用される特定のタイプの信号担持媒体の如何にかかわらず、本発明が等しく当てはまることを当業者なら理解するであろうことに留意されたい。コンピュータ可読媒体の例には、フレキシブル・ディスク、ハード・ディスク・ドライブ、ＲＡＭ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの記録可能型媒体や、デジタル／アナログ通信リンク、例えば無線周波数／光波伝送などの伝送形式を使用する有線／無線通信リンクなどの伝送型媒体が含まれる。コンピュータ可読媒体は、特定のデータ処理システムで実際に使用するために復号化されるコード化フォーマットの形態を取ることができる。

例示および説明の目的で本発明の説明を提示したが、本発明の説明は網羅的なものではなく、開示の形態の発明に限定されない。多数の修正形態および変形形態が当業者には明らかであろう。本発明の原理、実際的な応用例を最もよく説明するため、および企図される特定の使用法に適する様々な修正を有する様々な実施形態に関して本発明を当業者が理解できるように実施形態を選び、説明した。

[fig. 1] 本発明の好ましい実施形態による汎用コンピュータ・システムである。
[fig. 2] 本発明の一実施形態による発信サーバ上で実施されるステップを示すフロー・チャートである。
[fig. 3] 本発明の好ましい実施形態によるネットワークで仲介されるクライアント、オリジン・サーバ、および分離サーバのアーキテクチャである。
[fig. 4] 本発明の一実施形態によるオリジン・サーバ上で実施されるステップを示すフロー・チャートである。
[fig. 5] 本発明の一実施形態による分離サーバ上で実施されるステップを示すフロー・チャートである。