(57)【要約】  説明されるのは、サーバコンピュータ及び通信チャネルによって前記サーバと接続される１つ又は複数のクライアントコンピュータで構成される情報システムであって、データの変更及び検索操作は前記サーバコンピュータによって実行され、前記クライアントコンピュータは前記サーバへの前記データ変更及び検索要求を実行し、高機能グラフィカルユーザインターフェイスを表し、クライアントコンピュータごとに動的に作成された自己完結オブジェクトの拡張可能汎用システムを使用することを特徴とする情報システムである。さらに、クライアント−サーバ情報システムのクライアントコンピュータにおいて高機能な動的に作成されたグラフィカルユーザインターフェイスを提供するために、特定のアルゴリズムに従って操作される自己完結オブジェクトの先進システム、つまりイベントハンドラを使用せずに機能するプログラムオブジェクトシステムを使用することを特徴とする方法が提案される。【特許請求の範囲】
【請求項１】
サーバコンピュータ及び通信チャネルによって前記サーバと接続される１つ又は複数のクライアントコンピュータで構成される情報システムであって、変更及びデータ検索操作は前記サーバコンピュータによって実行され、前記クライアントコンピュータは前記サーバへの前記データ変更及び検索要求を実行し、高機能グラフィカルユーザインターフェイスを提供し、クライアントコンピュータごとに動的に作成された自己完結オブジェクトの拡張可能汎用システムを使用することを特徴とする情報システム。
【請求項２】
基本プロトコルとしてネットワークプロトコルＴＣＰ／ＩＰを使用することを特徴とする請求項１に記載の情報システム。
【請求項３】
基本プロトコルとしてネットワークプロトコルＨＴＴＰ及びＨＴＴＰＳを使用することを特徴とする請求項１に記載の情報システム。
【請求項４】
基本プロトコルとしてネットワークプロトコルＨＴＴＰ及びＨＴＴＰＳでプロトコルＳＯＡＰを使用することを特徴とする請求項１に記載の情報システム。
【請求項５】
サーバ側においてセッション識別子による許可でセッションプロトコルをサポートすることを特徴とする請求項１に記載の情報システム。
【請求項６】
ダイジェスト認証タイプによるユーザ認証を使用することを特徴とする請求項１に記載の情報システム。
【請求項７】
ケルベロスプロトコルによるユーザ認証を使用することを特徴とする請求項１に記載の情報システム。
【請求項８】
自己完結オブジェクトを記述するためにキャッシング機構を使用することを特徴とする請求項１に記載の情報システム。
【請求項９】
セッション鍵を使用して要求及び応答の完全及び／又は部分暗号化を使用することを特徴とする請求項１に記載の情報システム。
【請求項１０】
通信チャネルを介して送信され、暗号化形式でクライアント機械可読媒体にキャッシュされる自己完結オブジェクトの記述を使用することを特徴とする請求項１に記載の情報システム。
【請求項１１】
クライアント−サーバ情報システムのクライアントコンピュータにおいて高機能な動的に作成されたグラフィカルユーザインターフェイスを提供する方法であって、特定のアルゴリズムに従って操作される自己完結オブジェクトの拡張可能システム、つまりイベントハンドラを使用せずに機能するプログラムオブジェクトシステムを使用することを特徴とする方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータネットワークにおけるデータ伝送に関し、分散情報システムにおいても使用されうる。
【０００２】
標準的な用語
情報クライアント−サーバシステム(Information client-server system)とは、１つのサーバコンピュータ（バックコンピュータ）及び１つ又は複数のクライアントコンピュータ（フロントコンピュータ）で構成される分散情報システムを意味し、このシステムにおいて各クライアントは通信チャネルによってサーバと結合される。現在、インターネット環境は、ほとんどの場合、通信チャネルとして使用される。クライアント−サーバシステムの主な機能は、サーバコンピュータによって実行される。情報システムのユーザは、クライアントコンピュータと対話する。
【０００３】
要求（request）とは、通信チャネルを介してクライアントコンピュータからサーバコンピュータに送信される信号シーケンスを意味する。要求信号は、サーバによって実行されるべき操作、及びクライアントによってサーバに期待されるデータの性質を定義する。
【０００４】
応答(response)とは、通信チャネルを介してサーバコンピュータからクライアントコンピュータに送信される信号シーケンスを意味する。応答は、クライアントのためのデータを構成する。
【０００５】
プログラムオブジェクト(program object)とは、コンピュータメモリ内の特定の方法で編成された信号の集合を意味する。プログラムオブジェクトは、オブジェクト指向プログラミングのアルゴリズムに従ってコンピュータ操作中に作成されて使用される。各プログラムオブジェクトは、オブジェクトメソッド（関数及び／又はプロシージャ）の特定のセットを有し、オブジェクトプロパティ値のセットによって特徴付けられる。プログラムオブジェクトは、相互のメソッドを呼び出して、相互に対話する。通常、対話は、イベントハンドラを用いて行われる。
【０００６】
オブジェクトメソッド(object method)とは、コンピュータメモリ内の特定の方法で編成された信号の集合を意味する。メソッドを呼び出す（実行する）ことで、それらの信号を始動させる。メソッドは、メソッドを実行した結果であるデータを返すことができる。
【０００７】
オブジェクトプロパティ(object property)は、あらかじめ定められた１つのタイプのデータを含むオブジェクト特性を意味する。プロパティの記録及び読み取りは、対応するオブジェクトメソッドの呼び出しを通じて実行される。
【０００８】
イベント(event)とは、ユーザのアクション又はコンピュータシステムにおけるその他の任意の変化を意味する。
【０００９】
プログラムオブジェクト構成(program object configuration)とは、このオブジェクトのプロパティの特定の値のセットを意味する。
【００１０】
プログラムオブジェクト記述(program object description)とは、プログラムオブジェクト構成を含むデータを意味する。さまざまなバイナリ又はテキストフォーマットが、プログラムオブジェクト記述に使用されうる。
【００１１】
プログラムオブジェクト記述バージョン(program object description version)とは、オブジェクト構成の変種を区別できるようにする、プログラムオブジェクト記述に関連する追加のデータを意味する。
【００１２】
（プログラム）インターフェイスとは、メソッド及びプロパティの特定のセットを意味する。プログラムインターフェイスをサポートするため、オブジェクトは、このインターフェイスに関連するすべてのメソッド及びプロパティを所有する必要がある。
【００１３】
オブジェクトの振る舞いとは、オブジェクト構成に応じた、システム内のイベントに対するオブジェクトの応答を意味する。プログラムオブジェクトは、当初は何らかの振る舞い、つまりオブジェクト構成に応じてシステム内のイベントに対するあらかじめ定められた応答を備える。
【００１４】
イベントハンドラとは、コンピュータメモリ内の特定の方法で編成された信号の集合であって、コンピュータシステム内の特定のイベントの発生に応答して実行されるものを意味する。イベントハンドラは、プログラムオブジェクトの振る舞いを大部分定義する。これらは、オブジェクトの初期の振る舞いを変更し、この振る舞いを個別化する手段であり、通常はオブジェクト間の対話を提供する。
【００１５】
スクリプトとは、プログラミング言語の１つでプログラムを含むテキストであって、Ｗｅｂページ又は他の文書に組み込まれたテキストを意味する。イベントハンドラは、スクリプトテキストを、対応するイベントハンドラの信号の集合に動的に解釈することにより実行されうる。
【００１６】
Ｗｅｂアプリケーションとは、Ｗｅｂブラウザをクライアントプログラムとして使用する情報クライアント−サーバシステムを意味する。Ｗｅｂアプリケーションクライアント部分のプログラムオブジェクトの振る舞いは、Ｗｅｂページに導入されたスクリプトを使用して割り当てられる。
【００１７】
シンクライアントアーキテクチャとは、この概念に従って、クライアントプログラム（いわゆる「シンクライアント」）がユーザインターフェイス要素のみを反映し、すべてのユーザインターフェイスのイベントがサーバにおいて処理されることを意味する。これは、（クライアント−サーバシステム内の通常の要求及び応答に加えて）追加の通信トラフィックを生じさせる。
【００１８】
キャッシングとは、再使用の目的でクライアントコンピュータの機械可読媒体（ハードドライブ）においてＷｅｂページ及びその他の文書を格納し、通信トラフィックを減少させることを意味する。Ｗｅｂアプリケーションにおいて、Ｗｅｂブラウザのキャッシング機能は通常、（不整合な格納データの誤用を招くおそれがある）更新を防ぐことができるので、オフに切り替えられる必要がある。
【００１９】
ハッシングとは、復号化の可能性のない暗号化の変形（一方向暗号化）を意味する。
【００２０】
ユーザ認証とは、ユーザが自身のユーザ権限を従来の名前及びパスワードにより証明する場合に、ユーザをシステムに接続しながら実行される手続きを意味する。
【００２１】
ユーザ認証とは、情報システム操作中にユーザ権限を確認するための手続きを意味する。
【００２２】
本発明の著者により加えられた用語
自己完結オブジェクト(self-sufficient object)とは、操作にイベントハンドラを必要としないプログラムオブジェクトを意味する。自己完結プログラムオブジェクトは、特定のシステムの一環としてのみ十分に機能することができる。
【００２３】
自己完結オブジェクトのシステムとは、特定の方法で編成されたプログラムオブジェクトのシステムであって、それらのオブジェクト間の相互関係がその構成によってのみ定義されているものを意味する。特定の方法で確立された自己完結オブジェクト間の相互関係により、システムは、スクリプトを使用せずに機能する可能性を含む、いかなる種類のイベントハンドラも使用することなく十分に機能することができる。自己完結オブジェクトのシステムの操作を規定とする機能が以下に説明される。
【背景技術】
【００２４】
現在、情報クライアント−サーバシステムは、幅広く使用されている。情報クライアント−サーバシステムのユーザである個人は、クライアントコンピュータと直接対話する。ユーザのアクション（たとえば、キーを押す、又はマウスをクリックする）に応答して、クライアントプログラムの制御の下に動作しているクライアントコンピュータは、通信チャネルを介して要求信号をサーバコンピュータに送信する。クライアントプログラムは、クライアントコンピュータにおいてユーザインターフェイスを提供し、ユーザのアクションをサーバへの要求信号に変換する。
【００２５】
サーバコンピュータは、サーバプログラムの制御の下に動作する。要求信号を受信すると、サーバは、要求に従って、機械可読媒体に格納されているデータの一部の変換を実行し、同じ機械可読媒体又は他の機械可読媒体からデータサンプルを導き出して、通信チャネルを介してそれぞれの信号の形態でそれらのデータをクライアントコンピュータに送信する。応答信号を受信すると、クライアントコンピュータは、サーバから受信したデータをユーザに都合のよい形態でユーザに提供し、必要に応じて受信データの一部又は全部をクライアントコンピュータの機械可読媒体に記録する。システムにおける要求信号及び応答信号の交換は、特定の問題を解決するためにユーザが必要とする限り続行する。クライアントの役割は、コンピュータに加えて、クライアントプログラムの制御の下に動作する携帯電話又はその他の通信装置によって実行されうる。
【００２６】
したがって、情報クライアント−サーバシステムが機能するためには、サーバプログラム及びクライアントプログラムという２つのプログラムが必要である。通常、サーバプログラムはデータベースの形態の情報リソースにアクセスすることができ、クライアント−サーバシステムの主要アクティビティを実行する。クライアントプログラムは、ユーザインターフェイスを提供し、サーバへの要求を実行して、作業の小部分を達成する。
【００２７】
多くの情報システムにおいて、Microsoft（登録商標）Internet Explorer、Mozilla、又はOperaなどのプログラムＷｅｂブラウザは、クライアントプログラムとして使用される、つまりそれらの情報システムはＷｅｂアプリケーションである。あらかじめ定められたＷｅｂページのセットをユーザに提供するＷｅｂサイトとは対照的に、Ｗｅｂアプリケーションは対話形式で動作し、ユーザ要求に従って動的に作成されたＷｅｂページを提供する。Ｗｅｂアプリケーションの長所は、汎用のプログラム（Ｗｅｂブラウザ）がすべてのＷｅｂアプリケーションでクライアントとして使用されることにある。Ｗｅｂブラウザは、多くの場合オペレーティングシステムをインストールする際に、クライアントコンピュータに１回インストールされる。するとそれは、ほとんどのさまざまなＷｅｂアプリケーションでクライアントプログラムとして使用されうる。それにより、別個のＷｅｂアプリケーションごとにカスタマイズされたクライアントプログラムをインストールする必要がなくなる。Ｗｅｂアプリケーションにおいて、情報システム操作の論理及びクライアントに情報を提供する方法は、もっぱらサーバ側によって定義される。したがって、情報を提供するこれらの論理及び方法における変更が、クライアントプログラムの変更を必要とすることはほとんどない。
【００２８】
しかし、Ｗｅｂアプリケーションの可能性は、Ｗｅｂブラウザによって提供されるユーザインターフェイスの可能性がいくぶん劣っているために制限されている。近年、XForms仕様（XForms 1.0 (W3C Recommendation) http://www.w3.org/TR/xforms/）及びWebForms 2.0（WebForms 2.0 (Working Draft) http://whatwg.org/specs/web-forms/current-work/）に基づいてＷｅｂアプリケーションのユーザインターフェイスを改善する試みが行われてきた。それにもかかわらず、新しい仕様は、Ｗｅｂアプリケーションのユーザインターフェイスと、Windows（登録商標）、MacOS、XWindow、Java（登録商標）などのシステムによって提供される改良されたグラフィカルユーザインターフェイスとを隔てるギャップの克服を（は）可能にしていない。したがって、分散情報システムが高機能グラフィカルユーザインターフェイスを必要とするような場合、開発者は、所定のクライアントプラットフォームにネイティブなカスタマイズクライアントプログラム、つまり特定のクライアントプログラムのアプリケーションプログラミングインターフェイスに基づくプログラムを作成することを余儀なくされる。この場合、すべての情報システムには、各自のクライアントプログラムが必要となり、情報システム操作の論理又はユーザに情報を提供する方法におけるあらゆる変更には、クライアントプログラムの更新（クライアントコンピュータにおけるプログラムの再インストール）が必要となる。新しいバージョンのクライアントプログラムの送信及び再インストールは、結果として追加の通信トラフィックをもたらし、ユーザに甚大な不便をかけ、追加の財務費用を生じることになる。
【非特許文献１】XForms 1.0 (W3C Recommendation) http://www.w3.org/TR/xforms/
【非特許文献２】WebForms 2.0 (Working Draft) http://whatwg.org/specs/web-forms/current-work/
【発明の開示】
【発明が解決しようとする課題】
【００２９】
本発明の目的は、情報を表すビジネス論理及び方法が完全にサーバ側にあり、クライアント部分は個別のアプリケーションごとに再インストールを必要としない汎用プログラムによって表される、高機能グラフィカルユーザインターフェイスを備える情報クライアント−サーバシステムを開発するための技術（システム及び方法）を提供することである。このようにして、グラフィカルユーザインターフェイスの操作、つまりユーザインターフェイスオブジェクトのユーザとの十分な対話及び相互の間の十分な対話が、サーバにアクセスすることなくクライアントコンピュータにおいて独占的に行われる必要がある。本発明の技術的効果は、確立するパケット及び更新バージョンのクライアントプログラムを送信することにより生じる追加の通信トラフィックを排除することにある。
【００３０】
すでに知られているのは、ＷｅｂページにActiveX又はJava（登録商標）アプレットのコンポーネントを組み込むことにより、Ｗｅｂアプリケーションの高機能グラフィカルユーザインターフェイスを提供する方法である[Internet and World Wide Web. How to Program, 3rd Edition. By Harvey M. Deitel, Paul J. Deitel, Andrew B. Goldberg. Published Nov 24, 2003 by Prentice Hall. 1296 pages]。しかし、これらの方法は、既存の組み込みコンポーネントが汎用ではなく（Ｗｅｂアプリケーションごとにカスタマイズされたコンポーネントが必要とされ）、情報システム操作の論理を更新するか又は情報を表す方法を変更することが求められるため、目的を達成しない。同様のことが、Java（登録商標）アプレットを改良することを目的とする新しいJava（登録商標）技術のWeb Start [Java（登録商標） Web Start Technology, http://java.sun.com/products/javawestart/]についても言える。
【００３１】
すでに知られているのは、シンクライアントアーキテクチャにおける情報クライアント−サーバシステムの実施形態である（米国特許出願公開第２００２／０１３０９００号明細書、米国特許出願公開第２００３／０１３５８２５号）。これらの米国特許出願によれば、ユーザインターフェイスのオブジェクトは、サーバから取得されるExtensible Markup Language (XML)の記述によって動的に作成される。そのため、クライアントプログラムの汎用特性による通信トラフィックの低減が可能になる。しかし、追加の通信トラフィックは、サーバにおいてクライアントイベントを処理するために、この利点を無効にしてしまう。
【００３２】
本発明の最も近い類似物は、国際公開第２００４／０１９１６０号パンフレットである。この出願は、マークアップ言語（ＸＭＬ、ＸＳＬ、ＤＨＴＭＬ、ＸＨＴＭＬ、ＨＴＭＬ）のいずれかでサーバから取得される記述に基づいてクライアントコンピュータにおいてユーザインターフェイスのプログラムオブジェクトを動的に作成することを提案する。ユーザインターフェイスのプログラムオブジェクトの振る舞いの個別化は、Java（登録商標）Script言語のスクリプトを使用して達成される。そのようなシステムは拡張性特性を有することができる、つまり新しいタイプのオブジェクトが必要に応じてシステムに追加されうると考えられている。しかし、スクリプトを機能させるために、オブジェクトモデル、つまりあらかじめ定められたオブジェクトタイプのセット（オブジェクト指向プログラミングでは、クラス）を割り当てることが通常は必要になり、これは拡張性の原則と相反する。これらの提案は、前述のような矛盾と、スクリプトサポートの汎用機能を実行する複雑さのために、まだ広範に行われていない。
【課題を解決するための手段】
【００３３】
クライアント側において、動的に作成された自己完結プログラムオブジェクトの汎用システムを使用して、特定のアルゴリズムに従って情報クライアント−サーバシステムを管理することにより、一連のタスクが本発明において解決される。本発明において、及び米国特許出願公開第２００２／０１３０９００号明細書、米国特許出願公開第２００３／０１３５８２５号明細書、及び国際公開第２００４／０１９１６０号パンフレットにおいて、クライアントコンピュータにおけるプログラムオブジェクトは、サーバから取得されたその記述によって動的に作成されるが、本発明では、ユーザインターフェイスのオブジェクトはＷｅｂブラウザには組み込まれず、汎用クライアントプログラムの一部として動作する。本発明は、米国特許出願公開第２００２／０１３０９００号明細書及び米国特許出願公開第２００３／０１３５８２５号明細書とは対照的に、ユーザインターフェイス操作のためにサーバにアクセスする工程を必要とはしない。国際公開第２００４／０１９１６０号パンフレットとは対照的に、本発明は、システム操作のためのスクリプト機能をサポートする工程を必要とはしない。本発明における自己完結プログラムオブジェクトのシステムの使用は、スクリプトサポートの汎用機能を実行する複雑さを排除する。自己完結オブジェクトを記述するために使用されているフォーマットは、本発明を実行するにあたってあまり重要ではない。
【００３４】
イベントハンドラによって振る舞いが著しく定義される一般に使用されるプログラムオブジェクトとは対照的に、自己完結プログラムオブジェクトの振る舞いは、その構成を指定することによって、つまりこのオブジェクトのプロパティの値セットによって完全に定義される。システム内の自己完結プログラムオブジェクトのイベント応答はオブジェクト構成に依存するが、各々特定の構成において、この応答はあらかじめ定められ、イベントハンドラを使用して変更することはできない。
【００３５】
振る舞いの変更が前提とされない場合、いかにして、非常に異なるオブジェクト間の十分な対話が確保されうるのであろうか。その目的のために、本発明におけるクライアント側のオブジェクトは、自己完結プログラムオブジェクトのシステムにクラスタ化され、そのシステム操作がクライアント−サーバシステムのフレームワーク内のオブジェクト対話の統一された特性を考慮に入れる。
【発明を実施するための最良の形態】
【００３６】
システムにおけるすべての自己完結オブジェクトは、複数のカテゴリに分類される。１つ又は別のカテゴリに属するオブジェクトは、システムにおけるその役割及び振る舞いを定義する。オブジェクトの以下のカテゴリが、自己完結オブジェクトのシステムにおいて指定される。
【００３７】
コンテナは、自己完結オブジェクトをグループにまとめることを目的とする。これらのオブジェクトは、ウィンドウフォーム及びさまざまなグループ分けパネルとしてユーザインターフェイスに表される。コンテナオブジェクトの宛先は、サーバから取得されたデータをオブジェクトに送信するため、又はサーバへの要求を形成するデータをオブジェクトから受信するために、このコンテナによってまとめられるすべての自己完結オブジェクトにアクセスできることを前提としている。コンテナ記述は、その他のコンテナを含むそこに関連するすべてのオブジェクトの記述を含む。どの自己完結オブジェクト（ウィンドウフォームを除く）も、何らかのコンテナに含まれる。ウィンドウフォームは、最上位のコンテナとして独立して存在する。
【００３８】
イニシエータは、ユーザアクション（キーを押す、又はマウスをクリックする）に基づいてサーバへの要求を開始することができるボタン、メニュー項目、及びその他のオブジェクトである。
【００３９】
受信側は、受信すること、及び場合によってはサーバから受信したデータを表示することができるラベル、テキスト入力制御、リスト、グリッド、図、及びその他のオブジェクトである。
【００４０】
要求側は、サーバ要求を形成するためにそこに含まれているデータを提供することができる単一行テキスト入力制御、テキスト領域、リスト、グリッド、及びその他のオブジェクトである。
【００４１】
装飾は、ユーザと対話することができないピクチャ及びその他のグラフィカル設計要素である。装飾は情報システム操作に影響を及ぼすことはなく、その存在又はその不在は単にウィンドウフォームのレイアウトを定義する。
【００４２】
ブローカは、その他のカテゴリのオブジェクト間のリンクである特殊な自己完結オブジェクトである。
【００４３】
一部の自己完結オブジェクトは、たとえば同時に要求側及び受信側になるなど、複数のカテゴリに同時に分類されることもある。
【００４４】
一部のカテゴリに属することは、そのカテゴリに義務付けられている属性の可用性、つまり対応するインターフェイスのサポートを必要とする。
【００４５】
自己完結オブジェクトの示されているカテゴリのインターフェイスメソッド及びプロパティの最小セットを以下に一覧する。
【００４６】
Initiatorインターフェイスにおいて、
Brokerプロパティは、このイニシエータを使用してどのブローカが開始されるかを定義する。
【００４７】
Brokerインターフェイスにおいて、
Containerプロパティは、要求の形成に関与するコンテナを定義する。
RequestTypeプロパティは、要求タイプを定義する。システム操作に最小十分なセットは、新しいコンテナ要求、既存コンテナへのデータ要求、サーバからその後データを受信してサーバにおいてデータを変更する要求、サーバからその後データを受信せずにサーバにおいてデータを変更する要求、ユーザを認証するための複数の要求の変種、などのタイプの要求を含む。
ContainerNameプロパティは、どのコンテナが要求されるか（新しいコンテナが要求される場合）、又はどのコンテナにデータが要求されるかを定義する。
ServerAddressプロパティは、情報システムを実行するサーバのネットワークアドレスを構成する。
Goメソッドはブローカを始動させる。
【００４８】
Requesterインターフェイスにおいて、
ReceiveRequestメソッドは、所定の要求側と一致する要求部分を返す。
【００４９】
Recipientインターフェイスにおいて、
SetDataメソッドは、それぞれのデータを特定の受信側に送信する。
【００５０】
Containerインターフェイスにおいて、
FormRequestメソッドは、完全な要求をサーバに返す。このメソッドを呼び出す場合、コンテナはそれに関連するすべてのオブジェクトを検索し、要求側ごとにReceiveRequestメソッドを呼び出すので、受信された部分から完全な要求を形成する。
DistributeDataメソッドは、コンテナに関連するすべてのオブジェクト受信側を検索し、オブジェクトごとにSetDataメソッドを呼び出し、それによりそれぞれデータをすべての特定の受信側に送信する。
【００５１】
Decorationインターフェイスは要求されない。
【００５２】
すべての自己完結オブジェクトは、値がオブジェクトを識別するNameプロパティを有する必要がある。
【００５３】
新しいコンテナが要求される場合、通信トラフィックのさらなる減少をもたらす特殊キャッシング機能を使用することができる。一覧されるメソッド及びプロパティのセットは、要求及び応答の完全又は選択的暗号化によりデータを保護し、暗号化フォーム（以下を参照）でオブジェクトのキャッシュされた記述を格納するために必要なプロパティを含んではいない。
【００５４】
図１において、データの変更及び受信を要求する場合（図２のブロック図）のクライアント及びサーバの対話をたどる。
【００５５】
凡例：１−サーバ、２−クライアント、３−クライアントプログラム、４−要求形成段階、５−応答処理段階
【００５６】
操作のシーケンス：
ユーザ６はイニシエータ７を始動させる（ボタン、メニュー項目など）（ブロック２１）。
【００５７】
イニシエータ７はブローカ８のGoメソッドを呼び出す（ブロック２２）。
【００５８】
ブローカ８はコンテナ９のFormRequestメソッドを呼び出す（ブロック２３）。
【００５９】
コンテナ９は、各々にReceiveRequestメソッドを呼び出すことにより（ブロック２４）それに関連する自己完結オブジェクト要求側に問い合わせを行い（ループ、ブロック２４〜２６）、要求側と一致する部分から要求を形成し（ブロック２５）、形成された要求をブローカ８に返す（ブロック２７）。（ブロック２６は、すべての要求側が処理されたかどうか、状態を確認する）。
【００６０】
ブローカ８は、ServerAddressのサーバプログラム１０に要求を送信する（ブロック２８）。
【００６１】
サーバプログラム１０は、データベース１２内のデータを変更し（ブロック２９）、データベース１２からデータを要求して受信する（ブロック３０）。
【００６２】
サーバプログラム１０は、必要なフォーマットにデータを変換し（ブロック３１）、それらをブローカ８に送信する（ブロック３２）。
【００６３】
ブローカ８は、DistributeDataメソッドを呼び出すことにより、受信したデータをすでに存在するコンテナ１３に送信する（コンテナ１３は最初のコンテナ９と同じであってもよい）（ブロック３３）。
【００６４】
コンテナ１３は、受信側ごとにSetDataメソッドを呼び出すことにより（ブロック３４）、それに関連する自己完結オブジェクト受信側間で受信データを配信する（ループ、ブロック３４〜３５）。（ブロック３５は、すべての受信側が処理されたかどうか、状態を確認する）。
【００６５】
図３において、（キャッシュせずに）新しいコンテナを要求する場合（図４のブロック図）のクライアント及びサーバの対話をたどる。
【００６６】
操作のシーケンス：
ユーザ６はイニシエータ７を始動させる（ボタン、メニュー項目などにより）（ブロック４１）。
【００６７】
イニシエータ７はブローカ８のGoメソッドを呼び出す（ブロック４２）。
【００６８】
ブローカ８はコンテナ９のFormRequestメソッドを呼び出す（ブロック４３）。
【００６９】
コンテナ９は、各々にReceiveRequestメソッドを呼び出すことにより（ブロック４４）それに関連する自己完結オブジェクト要求側に問い合わせを行い（ループ、ブロック４４〜４６）、要求側と一致する部分から要求を形成し（ブロック４５）、形成された要求をブローカ８に返す（ブロック４７）。（ブロック４６は、すべての要求側が処理されたかどうか、状態を確認する）。
【００７０】
ブローカ８は、ServerAddressのサーバプログラム１０に要求を送信する（ブロック４８）。
【００７１】
サーバプログラム１０は、サーバ機械可読媒体１１に位置する新しいコンテナ記述を探し出して読み込む（ブロック４９）。
【００７２】
サーバプログラム１０は、新しいコンテナ記述をブローカ８に送信する（ブロック５０）。
【００７３】
ブローカ８は、受信した記述に従って新しいコンテナ１４を作成する（ブロック５１）。
【００７４】
ブローカ８は、今度は新しいコンテナ１４のデータを受信するために、第２の要求をサーバに送信する（ブロック５２）。
【００７５】
サーバプログラム１０は、データベース１２からデータを要求して受信する（ブロック５３）。
【００７６】
サーバプログラム１０は、必要なフォーマットにデータを縮小し、それらをブローカ８に送信する（ブロック５４）。
【００７７】
ブローカ８は、DistributeDataメソッドを呼び出すことにより、すでに存在する新しいコンテナ１４に受信したデータを送信する（ブロック５５）。
【００７８】
コンテナ１４は、受信側ごとにSetDataメソッドを呼び出すことにより（ブロック５６）、それに関連する自己完結オブジェクト受信側間で受信データを配信する（ループ、ブロック５６〜５７）。（ブロック５７は、すべての受信側が処理されたかどうか、状態を確認する）。
【００７９】
図５において、新しいコンテナを要求する場合（図６のブロック図）のキャッシング機能をたどる。
【００８０】
最初、操作は、コンテナ９からのブローカ８によって形成された要求を受信するまで、図３（図４のブロック４１〜４７）に従って実行される。さらに、以下の操作が実行される。
【００８１】
ブローカ８は、クライアント機械可読媒体１５において新しいコンテナの記述及びこの記述のバージョンを検索する（ブロック６１）。記述及びそのバージョンがクライアントコンピュータに存在する場合（ブロック６２）、ブローカ８は記述のバージョンを要求に含める（ブロック６３）。
【００８２】
ブローカ８は、ServerAddressのサーバプログラム１０に要求を送信する（ブロック６４）。
【００８３】
サーバプログラム１０は、サーバ機械可読媒体１１に位置する新しいコンテナ記述及び記述バージョンを探し出して読み込む（ブロック６５）。
【００８４】
サーバプログラム１０は、機械可読媒体のクライアント１５及びサーバ１１からの記述バージョンを比較する（ブロック６６）。記述バージョンに相異がない場合、サーバプログラムはそれぞれフラグを応答に含める（ブロック６７）。この場合、記述及びそのバージョンは、クライアントコンピュータに送信されない。バージョンが異なる場合、又は記述バージョンが要求にない場合、サーバプログラムは記述及びそのバージョンを応答に含める（ブロック６８）。
【００８５】
サーバプログラム１０は、応答をブローカ８に送信する（ブロック６９）。
【００８６】
ブローカ８は応答を分析する。バージョン一致のフラグがない場合（ブロック７０）、ブローカは、受信した記述及びそのバージョンをクライアント機械可読媒体１５に格納し、必要に応じて既存の記述及びそのバージョンを置き換える（ブロック７１）。それ以外の場合、すでに存在する記述が使用される（ブロック７２）。
【００８７】
ブローカ８は、（おそらくは受信したばかりの）既存の記述に従って新しいコンテナ１４を作成する（ブロック７３）。
【００８８】
さらに、新しいコンテナのデータを受信するために、図３に従って操作が実行される（図４のブロック５２〜５７）。
【００８９】
情報システム操作論理又はデータ表現メソッドにおいて、次の操作セッションまで変更が発生しない場合、コンテナ記述はクライアント機械可読媒体から読み取られる。記述が変更されていないコンテナ記述のバージョン及びフラグのみが、通信チャネルを介して送信される。情報システム操作論理又はデータ表現メソッドを修正する必要が生じるので、サーバプログラム操作の修正に加えて、サーバ機械可読媒体に格納されているそれぞれのコンテナの記述を修正してそれらの記述のバージョンを変更することで十分である。この場合、サーバ機械可読媒体に格納されているそれぞれのコンテナの記述は、次の操作セッションにおいて更新される。したがって、キャッシング機能は、一方で、情報システム操作論理又はデータ表現メソッドを即座に更新できるようにし、またもう一方では、必要な場合に限り各コンテナの記述を更新することによって通信トラフィックを軽減する。
【００９０】
キャッシング機能をコンテナ記述に適用する可能性及び必要性は、これらの記述が多くの操作セッション中に不変でありえるということによってもたらされる。サーバから自己完結オブジェクト受信側へと至るデータの場合、１つの操作セッション中であってもそれらのデータが変化する可能性があるので、キャッシングは適用されない。
【００９１】
前述のように、Ｗｅｂアプリケーションの正しい操作のために、Ｗｅｂブラウザに存在するキャッシング機能を通常オフに切り替える必要がある。これは、Ｗｅｂアプリケーションに使用されるプロトコル及びＨＴＭＬマークアップ言語が、頻繁に変化するデータと稀にしか変化しないデータとの区別を可能にしていないことに関連する。したがって、Ｗｅｂブラウザのキャッシング機能は、データの更新を妨げ、結果として不整合な格納データの誤用を招く可能性もある。Ｗｅｂアプリケーションのキャッシング機能をオフに切り替えることで、すべての要求のＷｅｂページの完全な再ロードがもたらされる。これは、Ｗｅｂアプリケーションに追加の（相当数かつ根拠のない）通信トラフィックを形成する。
【００９２】
図１〜図６は、自己完結オブジェクト内の対話を示す。２つのタイプの要求について検討した。その他のタイプの要求を実行するアルゴリズムには、検討されたアルゴリズムとは根本的な区別はない。システム操作では、最大限に「要求−応答」モードを使用するが、これはいかなるクライアント−サーバシステムにも標準的である。このモードにおけるシステム操作は、汎用操作シーケンスを形成できるようにする。検討された操作シーケンスが、スクリプトに基づくイベントハンドラを含むいかなるイベントハンドラにも関与することなく実行されうることに留意することは重要である。
【００９３】
要求の実行及び応答の受信への良好な関与のためには、自己完結オブジェクトのシステムを正しく構成すること、つまりそれらのプロパティの値を正しく設定することで十分である。特に、図１の要求の場合、一連のプロパティは、以下のオブジェクトで正しく設定される必要がある。
イニシエータ７において、Brokerプロパティは要求に関与しているブローカ８を指し示す必要がある。
ブローカ８において、Containerプロパティは要求を形成するコンテナ９を指し示す必要がある。RequestTypeプロパティは、要求タイプと一致する必要がある。ContainerNameプロパティは、データが要求されるコンテナ１４の名前と一致する必要がある。ServerAddressプロパティは、それぞれのデータを含む必要がある。
コンテナ９は、正しく設定された構成で要求を形成するために必要なすべてのオブジェクトを含む必要がある。
【００９４】
構成するために必要なすべてのデータは、コンテナ９の記述に含まれうる（この場合、イニシエータ７及びブローカ８はいずれもコンテナ９に含まれる）。オブジェクトの構成は、オブジェクトを含むコンテナの記述に基づいて作成された直後、それを作成したブローカによって実行される。
【００９５】
システムに関与するために、自己完結オブジェクトはこのオブジェクトのカテゴリと一致するインターフェイスをサポートすることで必要かつ十分である。この条件の下で、提案されるシステムは、新しい自己完結オブジェクトによって容易に付加されうる。すなわち、システムは拡張可能である。システムを補足する自己完結オブジェクトは、クライアントコンピュータの機械可読媒体においてダイナミックリンクライブラリのファイルに配置されうる。クライアントコンピュータの機械可読媒体においてダイナミックリンクライブラリを記録した後、そのライブラリに含まれる自己完結オブジェクトは、さまざまな情報システムに使用されうる。したがって、自己完結オブジェクトシステムの拡張には、通信チャネルを介して小さいダイナミックリンクライブラリを一度送信する必要があるだけである。
【００９６】
これ以降、ユーザとの自己完結オブジェクトシステムの対話について検討する。本対話の技法、及びシステム内のそれらの対話の技法は、これらの自己完結オブジェクトの構成によって完全に定義される。自己完結オブジェクトは、情報システムのユーザによってグラフィックユーザインターフェイスの要素として認識される。実質上、これらは、Windows（登録商標）、MacOS、XWindow、又はJava（登録商標）など、クライアントプラットフォームに標準的な高機能グラフィカルユーザインターフェイスを提供する必要がある。したがって、これらは、特定のクライアントプラットフォームのアプリケーションプログラミングインターフェイスに基づいて作成される。ユーザインターフェイスオブジェクトの適切な振る舞いは以下の事項を前提とする。
オブジェクトの現在のユースケースと一致する必要のある情報入力制限のセット
各自の不適切なアクションをユーザに警告すること
オブジェクトの相互の一貫性を確認すること
【００９７】
単に自己完結オブジェクト構成を調整することにより、いかにしてこれらすべての機能がイベントハンドラを使用せずに実行されうるかを説明する。実施例を検討する。図７は、クレジットカードによる支払いの実行のために設計されたウィンドウフォーム１０１の概略を示す（簡単にするために、すべてのフィールドは示されていない）。ドロップダウンリスト１０２は、たとえば、VISA、American Expressなど、サポートされるクレジットカードのリストを備える特殊オブジェクトである。入力フィールド１０３〜１０７は、クレジットカードアカウント用の１０３、クレジットカード有効期限の月及び年用の１０４及び１０５、支払い金額用の１０６、カード所有者名用の１０７に、それぞれの英数字データを入力するために設計されている。オブジェクト１０２〜１０７は要求側である。ボタン１０８及び１０９はそれぞれ、要求をサーバに送信する操作、及びウィンドウフォームを閉じる操作を開始する。図７は、コンテナ１０１には存在するが、ユーザには見えないブローカは示していない。ブローカのContainerプロパティは、ウィンドウフォーム１０１を指し示す必要がある。ボタン１０８のBrokerプロパティは、既存のブローカを指し示す必要がある。
【００９８】
情報入力制限が実行されうる方法を説明する。入力フィールドの制限は、ContentType及びMaxLengthプロパティに関連付けられうる。MaxLengthプロパティは、入力シンボルの可能な最大数を定義する。ContentTypeプロパティは、入力コントロールに入力されうるシンボルを定義する。したがって、入力フィールド１０３〜１０５については、ContentTypeプロパティは整数値に設定される必要がある。このタイプのコンテンツは、デジタルシンボルの入力のみを可能にする。入力フィールド１０６については、ContentTypeプロパティは通貨値に設定される必要がある。このタイプのコンテンツは、デジタルシンボル及び小数シンボル（地域の調整に応じて小数点又はコンマ）の入力のみを可能にする。その他の入力フィールドは、同様に調整される。シンボル入力プロセス中に、オブジェクト（入力フィールド）は、ContentTypeプロパティ値で入力されているシンボルの対応関係を確認し、許容されないシンボルを無視する。入力確認は、オブジェクトに対して外部にあるイベントハンドラではなく、オブジェクト自身によって行われる。
【００９９】
ユーザの不適切なアクションに対する警告が実行されうる方法を示す（図８のブロック図）。検討中の事例において、ユーザの典型的な不適切なアクションは、入力フィールドに記入しないこと、及びクレジットカードの種類を選択しないことである。ユーザがボタン１０８を押すと、以下の順序で操作が実行される。
【０１００】
ボタン１０８は、ブローカを始動させる（ブローカのGoメソッドを呼び出す）（ブロック８１）。
【０１０１】
ブローカはコンテナ１０１のFormRequestメソッドを呼び出す（Containerプロパティによって指し示される）（ブロック８２）。
【０１０２】
コンテナ１０１は、自己完結オブジェクト、それに関連する要求側１０２〜１０７を検索し（ループ、ブロック８３〜８６）、各々にReceiveRequestメソッドを呼び出す（ブロック８３）。（ブロック８６は、すべての要求側が処理されたかどうかを確認する）。
【０１０３】
ドロップダウンリスト１０２のReceiveRequestメソッドを呼び出すとき、ユーザアクションの妥当性確認が行われる（ブロック８４）。この場合、確認は、ユーザがクレジットカードの種類を選択したかどうかについて実行される。ユーザがクレジットカードの種類を選択してない場合、これは不適切なアクションであるが、プログラム操作は中断され、ドロップダウンリストが「The credit card type has not been selected（クレジットカードの種類が選択されていません）」というテキストをユーザに表示するメッセージボックス（ブロック８５）を開く。
【０１０４】
入力フィールド１０３〜１０７の各々にReceiveRequestメソッドを呼び出すとき、各フィールドは各自ユーザアクションの妥当性を確認する（ブロック８４）。入力フィールドの場合、これは、このフィールドに記入されているかどうかを確認することである。ユーザがコントロール１０３に記入してない場合、これは不適切なアクションであるが、プログラム操作は中断され、入力フィールド１０３が「The field‘Credit card number'has not been filled（‘クレジットカード番号’のフィールドが記入されていません）」というテキストをユーザに表示するメッセージボックス（ブロック８５）を開く。（テキスト‘Credit card number（クレジットカード番号）’は、入力コントロール１０３のプロパティFieldNameに含まれる必要がある）。
【０１０５】
すべてのフィールドが記入された場合、新しいコンテナ、支払いを実行した結果を伴うウィンドウフォームを受信する操作が実行される（ブロック４７〜５７）。
【０１０６】
プログラム操作が停止するごとに、ユーザは、必要な修正を行ってからボタン１０８を再度押す必要がある。不適切なユーザアクションの制御及びそれに関する報告は、オブジェクトに対して外部にあるイベントハンドラではなく、オブジェクト自身によって行われる。
【０１０７】
自己完結オブジェクトの相互に合意した振る舞いが実行されうる方法を示す。検討中の事例において（図７）、クレジットカード番号の桁数（入力コントロール１０３）は、ドロップダウンリスト１０２で選択されたクレジットカードの種類によって決まる。したがって、たとえば、VISAクレジットカードの番号は１３〜１６桁で構成され、American Expressクレジットカードの番号は１５桁で構成され、Dinners Clubクレジットカードの番号は１４桁で構成される。さらに、クレジットカードの正しい番号は、特定のカードの種類ごとに固有の規則に従っている。したがって、オブジェクト１０２及び１０３だけは一貫して操作する必要がある。この問題を解決するため、クレジットカード番号の入力フィールドは、リスト１０２を指し示すCreditCardListプロパティを有する必要がある。この場合、入力中に、許容可能な入力桁数は、リスト１０２で選択されているクレジットカードの種類と一致させることができ、コントロール１０３にReceiveRequestメソッドを呼び出す場合、入力の番号がそれぞれのアルゴリズムに従ってクレジットカードの種類に適合するかどうかの確認を行うことが可能である。この場合、入力の番号がクレジットカードの種類に適合しないとき、ユーザはそれぞれのメッセージで警告を受け取ることができる。この操作が、イベントハンドラではなく、オブジェクト自身によって行われることが重要である。
【０１０８】
このように、イベントハンドラを使用することなく、ユーザインターフェイスオブジェクトの適切な振る舞いがどのように提供されうるかを示してきた。
【０１０９】
前述の操作シーケンスは、本質的に、情報クライアント−サーバシステムの本来の操作プロトコルの基礎を成すが、これは特定の形式的な特徴付け後に考案されうる。このプロトコルは、ＴＣＰ／ＩＰ、ＨＴＴＰ、ＨＴＴＰＳ、ＳＯＡＰなどの既知のネットワークプロトコル[Internet and World Wide Web. How to Program, 3rd Edition. By Harvey M. Deitel, Paul J. Deitel, Andrew B. Goldberg. Published Nov 24, 2003 by Prentice Hall. 1296 pages]及び、たとえばモバイルネットワークのデータ転送のプロトコルなど、他のプロトコルを介して実行されうる。基本ネットワークプロトコルの選択（に）は、根本的な意味合いはなく、実装機能のみに影響を及ぼす。高水準プロトコル（たとえば、ＴＣＰ／ＩＰに比較してＨＴＴＰ、又はＨＴＴＰに比較してＳＯＡＰ）を選択することは、実行のプロセスを簡略化させることができる。一方、低水準プロトコルを選択することで、送信データパケットをよりコンパクトにし、通信チャネル経由で転送されるデータ量を減少させることができる。
【０１１０】
ユーザ認証及び許可に関連する問題について簡単に検討する。以下の３つのレベルの認証を区別する。
【０１１１】
情報システムが誰にもフリーアクセスを許し、認証が要求されない、最も簡単な場合は、ゼロレベルに関連する。この場合、ログイン要求はユーザのデータを満足することはない。
【０１１２】
クライアント及びサーバ通信がセキュリティ接続を介して実行される（たとえば、ＨＴＴＰＳプロトコル［３］が基本として選択されている）場合、ユーザの名前及びパスワードは通信チャネルを介して認証要求でサーバに直接送信されうる。この場合、認証には１つの要求で十分である（第１のレベル）。
【０１１３】
セキュリティの低い状態での接続が使用される場合、オープン又はキャッシュフォームでも通信チャネルを介してパスワードを送信することは不可能である。この場合、認証には、２つの要求が必要とされ（第２のレベル）、ダイジェスト認証又はKerberosプロトコル[Hacking Exposed Web Applications. By Joel Scambray, Mile Shema, Caleb Sima, Publisher: McGraw-Hill Osborne Media; 1 edition (June 19, 2002)]の場合と同様に、２つの工程で行われうる。
【０１１４】
いずれの場合においても、正常な認証とは、一意のセッション識別子をユーザに割り当てることである。ゼロの認証レベルにおいて、セッション識別子は、名前及びパスワードを確認することなくユーザに割り当てられる。情報システムのさらなる操作中、セッション識別子は、受信データ及びコンテナのすべての要求に含められ、ユーザ認証は要求ごとに実行される。
【０１１５】
データ暗号化のないプロトコル、たとえばＴＣＰ／ＩＰ又はＨＴＴＰが基本ネットワークプロトコルとして使用される場合、要求及び応答の完全又は選択的暗号化の形態のデータ保護は、当該のシステムに直接組み込まれうる。これには、Requester、Recipient、及びContainerインターフェイスが以下のプロパティを含むことが必要になる。
【０１１６】
Requesterインターフェイスにおいて、
EncryptRequestプロパティフラグは、この要求側と一致する要求部分が暗号化される必要がある場合に設定される。
【０１１７】
Recipientインターフェイスにおいて、
DecryptResponseプロパティフラグは、この受信側と一致する応答部分が復号化される必要がある場合に設定される。
【０１１８】
Containerインターフェイスにおいて、
EncryptCompleteRequestプロパティフラグは、完全要求が暗号化される必要がある場合に設定される。
DecryptCompleteResponseプロパティフラグは、完全応答が復号化される必要がある場合に設定される。
【０１１９】
暗号化アルゴリズムは、ダイナミックリンクライブラリの形式で実行されうる。さまざまなアルゴリズムが、完全及び／又は部分要求暗号化及び応答復号化に使用されうる。したがって、最大４つの異なるアルゴリズムが同時に使用されうる。
【０１２０】
要求を形成する間に完全及び／又は部分暗号化が行われうる方法を示す。（図９のブロック図）。FormRequestメソッドを呼び出すと（ブロック１２１）、コンテナは、各々にReceiveRequestメソッドを呼び出すことにより（ブロック１２２）自己完結オブジェクト、それに関連する要求側（ループ、ブロック１２２〜１２６）に問い合わせを行う。EncryptRequestプロパティが要求側で設定されている場合（ブロック１２３）、コンテナは、ダイナミックリンクライブラリを使用してこの要求部分を暗号化し（ブロック１２４）、このライブラリを暗号化形式で完全要求に含める（ブロック１２５）。ブロック１２６は、すべての要求側が処理されたかどうかを確認する。EncryptCompleteRequestプロパティがコンテナで設定されている場合（ブロック１２７）、形成された要求は、サーバに送信される前に（ブロック１２９）暗号化される（ブロック１２８）。
【０１２１】
サーバから応答を受信する際に完全及び／又は部分復号化が行われうる方法を示す（図１０のブロック図）。DistributeDataメソッドを呼び出すとき（ブロック１４１）、DecryptCompleteResponseプロパティがコンテナで設定されている場合（ブロック１４２）、コンテナは、ダイナミックリンクライブラリを使用してサーバから受信された応答を復号化する（ブロック１４３）。コンテナ１４は、受信側ごとにSetDataメソッドを呼び出すことにより（ブロック１４４）、自己完結オブジェクト、及びそれに関連する受信側間で受信データを配信する（ループ、ブロック１４４〜１４８）。DecryptResponseプロパティが特定の受信側で設定されている場合（ブロック１４５）、コンテナは、Set-Dataメソッドを呼び出す前に（ブロック１４７）ダイナミックリンクライブラリを使用してこの受信側向けのデータを復号化する（ブロック１４６）。ブロック１４８は、すべての受信側が処理されたかどうかを確認する。
【０１２２】
暗号鍵は、Kerberosプロトコル[Hacking Exposed Web Applications. By Joel Scambray, Mile Shema, Caleb Sima, Publisher: McGraw-Hill Osborne Media; 1 edition (June 19, 2002)]に従ってユーザを認証するときに、サーバから受信されうる。これらの鍵は、１つの操作セッション中に操作する。
【０１２３】
コンテナ記述を備えるデータの暗号化は、同様に編成されうる。この場合、コンテナ記述は通信チャネルを介して送信され、暗号化形式でクライアント機械可読媒体に格納される必要がある。記述を復号化する責任は、ブローカに課せられうる。復号化の必要は、ブローカのDecryptContainerDescriptionプロパティを設定することにより示されうる。コンテナ記述は複数の操作セッション中にクライアント機械可読媒体から読み取ることができるので、セッション鍵はコンテナ記述の復号化には使用できない。ユーザパスワードは、直接又はハッシングフォームのいずれでも、コンテナ記述を復号化する鍵として使用されうる。
【０１２４】
自己完結プログラムオブジェクトのシステムに基づいて汎用クライアントプログラムの制御の下でのクライアントコンピュータの操作を検討する。
【０１２５】
汎用クライアントプログラムは、大多数の実際的な情報システムの要件を満たすことができるように、自己完結プログラムオブジェクトのリッチセットを含む必要がある。オブジェクトをシステムに含めることは、そのようなタイプのオブジェクトがそれらの記述に関して作成され構成されうるということである。自己完結オブジェクトの標準セットが不十分であるような少数の情報システムは、ダイナミックリンクライブラリに含まれている追加のオブジェクトによって補充されうる。
【０１２６】
特定のアプリケーションの操作を開始するため、クライアントプログラムは以下のデータを備えるのに十分である。
アプリケーションサーバのネットワークアドレス
所定のアプリケーションにおいて実行するユーザ認証方式
第１のコンテナ、つまりユーザ認証の直後に要求されるコンテナの名前
（必要に応じて）システムを補足する自己完結オブジェクトを有するダイナミックリンクライブラリのリスト
（必要に応じて）要求及び応答の完全又は部分暗号化のためのプログラムコードを含むダイナミックリンクライブラリのリスト
【０１２７】
これらのデータは、クライアント機械可読媒体でアプリケーションの初期化ファイルに格納されうる。汎用クライアントプログラムの制御の下でのクライアントコンピュータの操作セッションの始めの操作シーケンスを検討する（図１１のブロック図）。
アプリケーションサーバアドレス上のデータ、認証方式、第１の要求されたコンテナの名前、及びダイナミックリンクライブラリのファイル名は、クライアントコンピュータの機械可読媒体にある初期化ファイルから読み出される（ブロック１６１）。
ダイナミックリンクライブラリのファイル名のリストが空ではない場合（ブロック１６２）、追加の自己完結オブジェクトを有するダイナミックリンクライブラリ及び暗号化アルゴリズム実行を有するライブラリはロードされる（ブロック１６３）。
認証要求を実行するために、ブローカ−オブジェクトが作成され、構成される（ブロック１６４）。
ユーザの認証方式がユーザ名及びパスワードの入力を必要とする場合（第１及び第２のレベル）（ブロック１６５）、名前及びパスワードを入力するフィールドとシステム入力ボタンを含む特殊ウィンドウフォームが作成されて、モニタ画面に表示される（ブロック１６６）。
ゼロレベルの認証が使用される場合、システムへの入力要求は、ユーザのアクションなしで実行される（ブロック１６７）。
第１又は第２のレベルの認証が使用される場合、認証は、それぞれ１つ又は２つの要求を使用するユーザによって名前及びパスワードが入力されシステム入力ボタンが押された後に実行される（ブロック１６８）。
正常な認証の場合（ブロック１６９）、既存のブローカは、既知の名前に従って、作成される第１のコンテナ（第１のウィンドウフォーム）を要求する（ブロック１７０）。
ブローカは、受信した記述に従って第１のウィンドウ名を作成して構成する（ブロック１７１）。
情報システムのさらなる操作は、第１のウィンドウフォームの内容によって定義される方法に従う。このフォームにおいて、その他のウィンドウフォームを要求するブローカが存在する必要がある。したがって、情報システムのさらなる操作の論理は、サーバによって（特に、サーバから受信された第１のウィンドウフォームの記述を通じて）完全に定義される（ブロック１７２）。
ユーザの情報システムの操作は、ユーザによって第１のウィンドウフォームが閉じられた後に終了する（ブロック１７３）。
【０１２８】
以上、自己完結プログラムオブジェクトのシステムに基づいて汎用クライアントプログラムの制御の下でクライアントコンピュータが、いかにして、論理がサーバによって完全に定義される操作を実行できるかを示してきた。クライアントプログラムは汎用であるため、さまざまな情報システムにおいてクライアントコンピュータの操作を、高機能グラフィカルユーザインターフェイスを提供して、制御することができる。他の情報システムにおいて操作するため、及び操作論理とデータ表現方式を変更する際に、クライアントプログラムをリセットする必要はない。このことは、必要とされる技術的結果の達成を導く、つまり、インストールパケットと更新版のクライアントプログラムを送信することにより生じる追加のトラフィックを排除するので、通信チャネル上のロードを軽減する。シンクライアントアーキテクチャにおけるクライアント−サーバシステムに特有の通信チャネルトラフィックもまた排除される。
【０１２９】
本発明は、その実施形態を用いて説明されてきたが、本発明の範囲は、それらの実施例によって限定されることはなく、可能な等価物を考慮に入れる特許請求の範囲によってのみ定義される。
【図面の簡単な説明】
【０１３０】
【図１】データの変更及び受信を必要とする場合の、自己完結オブジェクトシステムの操作を示す図である。
【図２】データの変更及び受信を必要とする場合を示すフローチャートである。
【図３】新しいコンテナを必要とする場合の、自己完結オブジェクトのシステムの操作を示す図である。簡単にするために、キャッシング機能はこの図には示されない。
【図４】キャッシング機能を構成しない新しいコンテナを必要とする場合を示すフローチャートである。
【図５】新しいコンテナを必要とする場合のキャッシング機能を示す図である。
【図６】新しいコンテナを必要とする場合のキャッシング機能を示すフローチャートである。
【図７】クレジットカードによる支払いの実行を対象とするウィンドウフォームの例を示す図である。
【図８】クレジットカードにより支払いを実行する場合を示すフローチャートである。
【図９】要求を完全又はサンプル暗号化する場合を示すフローチャートである。
【図１０】応答を完全又はサンプル復号化する場合を示すフローチャートである。
【図１１】汎用クライアントプログラムの実行を示すフローチャートである。
【図１】
2009508184.tif 000002
【図２】
2009508184.tif 000003
【図３】
2009508184.tif 000004
【図４】
2009508184.tif 000005
【図５】
2009508184.tif 000006
【図６】
2009508184.tif 000007
【図７】
2009508184.tif 000008
【図８】
2009508184.tif 000009
【図９】
2009508184.tif 000010
【図１０】
2009508184.tif 000011
【図１１】
2009508184.tif 000012
【手続補正書】
【提出日】平成20年3月17日(2008.3.17)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
サーバコンピュータ及び通信チャネルによって前記サーバと接続される１つ又は複数のクライアントコンピュータで構成される情報システムであって、データの変更及び検索操作は前記サーバコンピュータによって実行され、前記クライアントコンピュータは前記サーバへの前記データ変更及び検索要求を実行し、高機能グラフィカルユーザインターフェイスを提供し、クライアントコンピュータごとに、プログラムオブジェクトが特定数のカテゴリに分割され、予備決定されたプログラムインターフェイスがそれらのカテゴリに対応して配置され、前記サーバへの要求の形成及び前記サーバからの応答の処理がプログラムオブジェクトメソッドの呼び出しの事前決定されたチェーンによって形成される、動的に作成されたプログラムオブジェクトの拡張可能汎用システムを使用することを特徴とする情報システム。
【請求項２】
基本プロトコルとしてネットワークプロトコルＴＣＰ／ＩＰを使用することを特徴とする請求項１に記載の情報システム。
【請求項３】
基本プロトコルとしてネットワークプロトコルＨＴＴＰ及びＨＴＴＰＳを使用することを特徴とする請求項１に記載の情報システム。
【請求項４】
基本プロトコルとしてネットワークプロトコルＨＴＴＰ及びＨＴＴＰＳでプロトコルＳＯＡＰを使用することを特徴とする請求項１に記載の情報システム。
【請求項５】
サーバ側においてセッション識別子による許可でセッションプロトコルをサポートすることを特徴とする請求項１に記載の情報システム。
【請求項６】
ダイジェスト認証タイプによるユーザ認証を使用することを特徴とする請求項１に記載の情報システム。
【請求項７】
ケルベロスプロトコルによるユーザ認証を使用することを特徴とする請求項１に記載の情報システム。
【請求項８】
自己完結オブジェクトを記述するためにキャッシング機構を使用することを特徴とする請求項１に記載の情報システム。
【請求項９】
セッション鍵を使用して要求及び応答の完全及び／又は部分暗号化を使用することを特徴とする請求項１に記載の情報システム。
【請求項１０】
通信チャネルを介して送信され、暗号化形式でクライアント機械可読媒体にキャッシュされる自己完結オブジェクトの記述を使用することを特徴とする請求項１に記載の情報システム。
【請求項１１】
通信チャネルとして無線及び移動体通信ネットワークを使用し、クライアントコンピュータとして携帯電話を使用することを特徴とする請求項１に記載の情報システム。
【請求項１２】
クライアント−サーバ情報システムのクライアントコンピュータにおいてグラフィカルユーザインターフェイスを提供する方法であって、
ブローカの指示を目的とするイニシエータを用いて前記ブローカにより前記サーバへの要求を開始し、前記ブローカは相互間のオブジェクトの相互通信を目的とすることと、
要求側をグループにまとめ、前記要求の形成に関与することを目的とするコンテナを決定することと、
コンテナにおいて、要求側に含まれるデータがどのシンボルが挿入されうるかを決定する内容の導入されたデータ及びタイプの最大可能量を定義するインストールされた最大長に対応するかどうかを結果として決定するデータ入力コントロールを含んで要求側の問い合わせが実施されている間、前述の最大長値及びデータタイプと一致しない前記データは無視され、要求側がデータを含まない場合、プログラムの操作は停止され、ユーザが必要なデータを入力してないことを示すメッセージをユーザは受け取ることと、
前記サーバへの要求が形成されることに基づいて前記要求側が前記データを表し、この要求は前記データがサーバデータベースから取得され適切なフォーマットに変換されることにより前記ブローカに返され、前記サーバから取得された前記データが、グラフィカルユーザインターフェイスとして前記データを受信して表すことを目的として、関連する受信側間で前記データが配信されることによって別のコンテナに送信されることにより前記ブローカに送信されることとを特徴とする方法。
【国際調査報告】
2009508184.tif 000013
2009508184.tif 000014