JP2000122945A - 対話式協調動作システム、方法及びデ―タ提示方法 - Google Patents

Abstract

(57)【要約】 【課題】 ユーザ端末とサーバなどの中央の場所に常駐
する共用されるアプリケーション・プログラムとの対話
式協調動作のためのシステム及び方法の提供。 【解決手段】 本方式によると、ダイアログ・データの
転送と保持のためのプレゼンテーション要素の構造と、
プレゼンテーション要素の実施と制御のための管理機構
とが、ユーザ端末内で確立される。ダイアログ・データ
の転送と保持のための対応要素の対応する構造が、アプ
リケーション・プログラムを使用して確立され、関連づ
けられたプレゼンテーション要素内とそれに対応する対
応要素内におけるダイアログ要素のための対応する２セ
ットのデータが、ダイアログ・データの対話式交換のた
めにそれぞれ維持される。これは、リンクまたはネット
ワークを介した伝送とは独立して、ユーザ端末とアプリ
ケーション・プログラムがそれぞれプレゼンテーション
要素及び対応要素とそれぞれ協調動作を可能にして行わ
れる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、中央位置、たとえ
ばサーバに常駐する一般に使用されるアプリケーション
・プログラムと協調動作し、ユーザ端末上で稼働するグ
ラフィカル・ユーザ・インタフェースを使用してデータ
の入力及び表示を対話式に行うことができるシステムに
関する。

【０００２】

【従来の技術】共通サーバ内のアプリケーション・プロ
グラムと遠隔ユーザ端末との間の対話式協調動作のため
に現在使用されているシステムでは、汎用対話セッショ
ンが可能である。しかし、それらの多くは、使用するア
プリケーションに特に適合させた多くの処理機能が必要
な「ヘビー」ユーザ端末を必要とする。その結果、ユー
ザ端末は高価になり、アプリケーション・プログラムを
修正または改良する場合は特に、多くのユーザ端末を更
新するために膨大な労力が必要になる。現在使用されて
いる他のシステムは、単純なユーザ端末を有するが、ユ
ーザ端末と、すべての対話式入出力操作で必要になるア
プリケーションのホストである中央サーバとの間で多く
の伝送を必要とする。さらに、現在のシステムのパフォ
ーマンスはリンク品質への依存度が大きく、高帯域幅と
低待ち時間が必要である。

【０００３】

【発明が解決しようとする課題】本発明の一目的は、ユ
ーザ端末におけるアプリケーション固有のプログラムを
必要とせず、ユーザ端末におけるプレゼンテーション論
理（入力／出力データの作成と伝送）のタスクの一部の
処理を可能にする、ユーザ端末と中央位置にあるアプリ
ケーション・プログラムとの間の対話式協調動作のため
のシステム及び方法を提供することである。本発明の他
の目的は、そのようなシステムにおいてアプリケーショ
ン・プログラムとユーザ端末との間で伝送する必要があ
るデータ及びメッセージの量を低減することと、対話セ
ッション中のデータ伝送のためのリンクの最適使用を可
能にすることである。

【０００４】本発明の他の目的は、上記のようなシステ
ムにおいて、大量のデータの伝送と制限されたリンク
（ネットワーク）機能とによって生じる可能性のある過
度の遅延を回避することである。

【０００５】

【課題を解決するための手段】上記の目的は、リンクま
たはネットワークを介したサーバ内のアプリケーション
・プログラムとユーザ端末との間の対話式協調動作のた
めの新規な方式によって達成される。この方式による
と、アプリケーション・プログラムとユーザ端末との間
にプレゼンテーション層が設けられる。このプレゼンテ
ーション層は、一部はユーザ端末で実施され、一部はサ
ーバで実施される。この層は、ユーザ端末上に表示され
るダイアログ要素を表す１対のプレゼンテーション要素
を含む。この対のうちの一方のプレゼンテーション要素
はユーザ端末に設けられ、それに対応するこの対の他方
のインタフェース要素がサーバに設けられる。さらに、
ユーザ端末で実行され、提示ダイアログ要素を制御する
プログラムが提供される。

【０００６】リンクまたはネットワークを介したアプリ
ケーション・プログラムと遠隔ユーザ端末との対話式協
調動作が、本発明によって改良される。この方式による
と、ダイアログ・データの伝送と保持を行うプレゼンテ
ーション要素と、このプレゼンテーション要素の実施と
制御を行う管理機構から成る構造がユーザ端末に確立さ
れる。ダイアログ・データの伝送と保持を行う対応要素
の対応する構造が、アプリケーション・プログラムで確
立される。これは、リンクまたはネットワークを介した
伝送とは独立して、ユーザ端末とアプリケーション・プ
ログラムがそれぞれプレゼンテーション要素及びその対
応要素とそれぞれ協調動作することができるような方法
で行われる。

【０００７】本発明によって、対話セッションにおける
データ伝送のためのプレゼンテーション論理の一部をユ
ーザ端末で実施することができるが、それにもかかわら
ず、様々な応用分野に汎用的に適合するユーザ端末とす
ることができる。新しいアプリケーションまたは変更さ
れたアプリケーションを使用する場合、ユーザ端末を修
正する必要がない。単に、対話セッションの初めに多少
のインタフェース要素構造（ウィジェット構造）を定義
するだけでよい。リンクの両側で同じデータが中間間保
持されるため、伝送はユーザ端末とアプリケーションに
とって透過的である。独立した伝送と、実際に必要な
（可視）データのみを伝送すると同時にいずれかの側の
対応する論理インタフェース要素で他の必要なデータを
準備することができるために、対話式協調動作がリンク
及びネットワークの条件からの独立度が高い。

【０００８】

【発明の実施の形態】用語の定義 ユーザ端末とは、入力データまたは出力データあるいは
その両方の準備と伝送を行うことができるシステムであ
る。すなわち、ユーザ端末は、ユーザが情報の入力また
は受信あるいはその両方を対話式で行うことができるあ
らゆるシステムである。例としては、ワークステーショ
ン、端末、ネットワーク・コンピュータ、パーソナル・
コンピュータ、デスクトップ機、携帯用システム、ハン
ドヘルド・コンピュータ装置などがある。本明細書で
は、ユーザ端末を中央位置またはサーバと呼ぶ別のシス
テムに接続するリンクまたはネットワークがある場合、
そのユーザ端末を遠隔ユーザ端末と呼ぶ。遠隔という語
は、ユーザ端末が中央位置またはサーバから離れて配置
されていることを示すために使用しているのではない。
遠隔ユーザ端末はそのすぐ隣に配置されていてもよい。

【０００９】アプリケーション・プログラムとは、デー
タを処理する何らかのコードである。ソフトウェア・パ
ッケージの一部またはモジュールとすることもでき、パ
ッケージ全体とすることもできる。アプリケーション・
プログラムの典型例は、テキスト及び画像処理、スプレ
ッド・シート、ミーティング・カレンダーなどのオフィ
ス環境で使用されるプログラム、または、保険業、銀
行、製造施設、ホテル、コール・センター用などの専用
アプリケーションである。他の例は、通信ネットワーク
の構成や監視に使用されるネットワーク管理ソフトウェ
アである。本発明は、対話式システムの構築を可能にす
る。

【００１０】中央位置とは、サーバ（アプリケーション
・サーバとも呼ぶ）またはアプリケーションのホストと
なることができる他の任意の機構である。通常、アプリ
ケーションはソフトウェアの形でホストされる。サーバ
の例は、ワークステーション、パーソナル・コンピュー
タ、デスクトップ機、携帯用システム、サーバ機、メイ
ンフレーム・コンピュータなどである。

【００１１】リンクまたはネットワークとは、データや
情報の交換を可能にする、ユーザ端末と中央位置との間
の接続である。有線方式または無線方式、あるいはその
両方の組合せとすることができる。

【００１２】その他の語及び表現については、言及する
際に説明するか、または本明細書の文脈から見て当業者
には明らかである。

【００１３】１）環境 本発明の環境は、少なくとも１つのユーザ端末が、アプ
リケーション・プログラムを含むデータ処理機構に接続
されているシステムである。マルチユーザ環境では、ア
プリケーション・プログラムを含む共通データ処理機構
に接続された複数のユーザ端末がある。ユーザは、アプ
リケーション、たとえば顧客口座の日時更新などを実行
するときに、自分の端末で情報の入力と受信を対話式に
行うことができる。

【００１４】ユーザ端末と共通機構との間でデータの処
理及び記憶を分散させる可能性は様々ある。１つの極端
な例は、データの表示と入力の受入れのみを行うユーザ
用の単なる端末を設け、すべての処理が中央コンピュー
タにあるアプリケーションによって行われるものであ
る。これは、ネットワークを介して多くの伝送を必要と
し、望ましくない遅延を生じさせることがある。もう一
つの悪影響は、その端末にローカル・インテリジェンス
がない場合、ユーザ・インタフェースの品質が低いこと
である。他の極端な例は、アプリケーション・プログラ
ムがすべての処理を行うことができる高性能なユーザ端
末を設け、対話セッションの結果のみが中央データベー
スに記憶されるものである。この場合、使用するアプリ
ケーションに変更または改善を加えるには、すべてのユ
ーザ端末のプログラムと構造の更新が必要であり、それ
によって頻繁な改善や更新ができなくなる。

【００１５】本発明は、ユーザ端末と共通機構（たとえ
ばサーバ）との間の対話式協調動作のための処理及び記
憶、すなわちプレゼンテーション論理が、ユーザ端末を
様々な変化するアプリケーションに汎用的に使用するこ
とができるような方式で分散され、ネットワークを介し
た伝送が最小限に低減されるシステムを提供することで
ある。

【００１６】図１は、本発明を含むシステムの概要ブロ
ック図である。本発明の基本概念及び詳細について、以
下に説明する。

【００１７】２）本発明の基本提案 ユーザとシステムとの対話のために、具体的には、デー
タ入力用のボックス、クリックのためのボタン、コマン
ド項目を備えたメニュー・バー、テーブルなど、表示装
置１２上のフィールドである様々な（物理的）ダイアロ
グ要素１１が使用される。ダイアログ要素１１は、ユー
ザに対するデータ及びメッセージの視覚的出力と、ユー
ザによるデータの入力のために使用される。本発明は、
各ダイアログ要素１１（またはそのような要素から成る
各複合グループ）のために、ユーザ端末１３とアプリケ
ーション１８との間に別々の論理経路を設ける。各ダイ
アログ要素１１ごとに、それぞれの論理経路は、ユーザ
端末側に、「プレゼンテーション要素」または以下で簡
単に「ウィジェット」と呼ぶダイアログ要素の論理表現
１５を含み、アプリケーション（共通サーバ）側に、
「対応要素」または以下で「プロキシ」と呼ぶ上記の論
理表現の対応物１６を含む。その構造を図１に示す。

【００１８】したがって、プレゼンテーション論理は、
ユーザ端末１３とサーバ１４との間で分離される。ユー
ザ端末１３は、（あたかもアプリケーション１８と直接
対話しているかのように）その端末に備えられたプレゼ
ンテーション要素１５（ウィジェット）とのみ対話し、
サーバ１４内のアプリケーション・プログラムは、対応
要素１６（プロキシ）と対話する。この分離は、ユーザ
にもアプリケーション・プログラムにも透過である。す
なわち、両者はダイアログ要素１１と直接通信している
かのように動作する。データ及びメッセージの実際の伝
送は、ユーザやアプリケーション・プログラムの関与な
しで、ウィジェット１５とプロキシ１６との間で行われ
る。したがって、言い換えると、ユーザ端末１３の表示
装置１２上のダイアログ要素１１とサーバ１４上のアプ
リケーション・プログラムとの間の論理（プレゼンテー
ション）経路はいくつかのセクションに分離され、ウィ
ジェット１５とプロキシ１６は中間「バッファ」とな
る。

【００１９】本発明は、きわめて軽いユーザ端末１３に
よるアプリケーション１８の配備をサポートする。

【００２０】基本思想は、中央制御されたアプリケーシ
ョン・サーバ１４上でアプリケーション１８を実行する
ことである。それによって、システムのメンテナンス及
び管理の集中化が可能になり、ユーザ端末管理のコスト
が低減される。アプリケーション１８のプレゼンテーシ
ョン部分のみがユーザの端末１３で実行される。プレゼ
ンテーション部分は、具体的にはプレゼンテーション要
素１５またはウィジェットを実施（及び管理）する、汎
用に適したコンパクトなプログラムによって実施され
る。

【００２１】したがって、この解決策の重要な構成要素
は、ユーザ端末１３上で実施されるこのインタフェース
・プログラムであり、以下、「ユーザ・インタフェース
・エンジン」（ＵＩエンジン）１７と呼ぶ。ＵＩエンジ
ン１７は、ユーザ端末１３上でアプリケーション１８の
ユーザ・インタフェースを実現し、エンド・ユーザと対
話する。

【００２２】ＵＩエンジン１７は、プレゼンテーション
論理のみを実行し、（データ形式検証などのいくつかの
基本的タスク以外の）アプリケーション論理は実行しな
い。ＵＩエンジン１７とアプリケーション１８との間の
実際の通信は、プレゼンテーション要素１５（ウィジェ
ット）とそれに関連づけられた対応要素１６（プロキ
シ）との間で行われる。アプリケーションは、最初に、
ＵＩエンジン１７に対し、ユーザ・インタフェースを表
すべきウィジェット１５の選択と構造に関して指示す
る。ＵＩエンジン１７は、これらのウィジェット１５を
必要な構造で起動し、ユーザがウィジェット１５で表さ
れたダイアログ要素１１と対話するときと、アプリケー
ション１８からのデータを必要とするときに、アプリケ
ーション１８に通知する。

【００２３】したがって、ユーザ端末１３で稼働するの
は、様々なアプリケーション１８から汎用的に使用可能
なＵＩエンジン１７だけである。ユーザ端末１３で実行
されるアプリケーション固有コードがないため、それぞ
れのユーザ端末１３のアプリケーション固有の管理が不
要である。

【００２４】アプリケーション１８は、高水準ユーザ・
インタフェース・プロトコルを介してＵＩエンジン１７
と通信する。このプロトコルは、低帯域幅の低速通信リ
ンク１９に合わせて縮小して設計される。配信を扱う特
別なツール・キットによってこのプロトコルからアプリ
ケーション開発者を遮蔽することができる。言い換える
と、アプリケーション開発者は、分散アプリケーション
を開発していることを知っている必要がない。分散はす
べて背後で処理される。

【００２５】ＵＩエンジン１７は、使用可能なウェブ・
ブラウザ内部のアプレットとして、または外部の支援ア
プリケーションとしても実行することができる。

【００２６】ハイパーテキスト・マークアップ言語（Ｈ
ＴＭＬ）に基づく従来のウェブ・アプリケーションとは
異なり、本発明を使用するシステムのアプリケーション
１８の開発者は、ＣＧＩのような動的ＨＴＭＬページ生
成及びサーバ拡張機構を扱う必要がない。アプリケーシ
ョン１８は、JavaやSmalltalkのような従来のプログラ
ミング言語を使用して開発することができる。ユーザ端
末１３上でもサーバ１４上でも異種技法（ＨＴＭＬ、Pl
ugins、Java、及びJavaScript）は不要である。これに
よって、ローバスト性（堅固さ）と開発の容易さの両方
が向上する。さらに、ユーザ・インタフェースはＨＴＭ
Ｌによって制約されない。

【００２７】３）ウィジェット及び構造に関する詳細 対話セッションのためのアプリケーション１８の構築
は、オブジェクト（対応要素）１６の特別なセットを必
要とする。これらの対応要素は、アプリケーション・イ
ンタフェースと、「通常の」ウィジェットと異ならない
機能動作とを有するが、ユーザ・インタフェースがまっ
たくない。これらの各対応要素１６は、通信機構によっ
てＵＩエンジン１７内の対応する「実」ウィジェット１
５と対話することができ、実ウィジェット１５のプロキ
シとして機能する。したがって、すべてのウィジェット
構成は、２つのハーフ・オブジェクト、すなわち、アプ
リケーション・プログラミング・インタフェース「対応
要素」１６（プロキシ）と実ユーザ・インタフェース
「プレゼンテーション要素」１５（ウィジェット）とに
分割される（図１及び図２参照）。

【００２８】アプリケーション１８は、要求、イベン
ト、及びコールバックから成るプロトコルを介してＵＩ
エンジン１７と通信する。アプリケーション１８は、リ
ンクまたはネットワーク１９を介してＵＩエンジン１７
に「要求」を送る。ユーザ対話の結果、典型的にはいく
つかの低水準イベント（たとえば「マウス・クリッ
ク」）が発生し、それらのイベントはまずＵＩエンジン
１７によって処理され、次に意味イベント（「実行アク
ション」）に変換され、リンクまたはネットワーク１９
を介してアプリケーション１８に戻される。典型的に
は、これらのイベントを使用してウィジェット構成の他
方の半分（プロキシ）を同期させ、次に何らかのアプリ
ケーション固有アクションをトリガする。ＵＩエンジン
１７は、アプリケーションの対応要素１６（プロキシ）
からの何らかのデータを必要とする場合、「コールバッ
ク」をトリガする。

【００２９】構造 ウィジェット１５（及びプロキシ１６）は階層を形成す
る（図３参照）。ルートには、アプリケーション１８の
全体的状態（終了など）を操作するメソッドとウィンド
ウまたは「シェル」２２のリストを維持するメソッドを
備える「アプリケーション」ウィジェット２１がある。
シェル２２は、任意選択のメニュー・バー２３（メニュ
ー項目を有するメニューのツリー２３）と内容領域とを
備えた最上位ウィンドウを表す。内容領域は、複合ウィ
ジェットのツリーである。複合ウィジェットは、ツリー
の内部ノードを形成し、レイアウトを実現する。単純な
ウィジェットは、ツリーのリーフである。図３には、
「ドシェ（Dossier）」と呼ぶサンプル・アプリケーシ
ョンのツリーの一部が図示されている。ウィジェット・
カテゴリの詳細な説明を以下に示す。

【００３０】ハーフ・オブジェクト分割（ウィジェット
／プロキシ）両方にわたる状態の維持は微妙である。通
信上の問題があったり、ユーザ端末１３がクラッシュし
たという理由だけで、アプリケーション１８を使用不能
にしたくはない。したがって、ＵＩエンジン１７は「概
念上無状態」である。すなわち、すべての状態がアプリ
ケーション１８で維持される。当然ながら、ＵＩエンジ
ン１７でも何らかの状態（たとえばウィジェット階層）
が維持されるが、一種のキャッシュとしてのみ保持され
る。このキャッシュは（たとえばＵＩエンジン１７をリ
セットすることによって）いつでもクリアすることがで
き、アプリケーション１８からＵＩエンジン１７にすべ
ての情報が再送信される。

【００３１】この機能は、ハーフ・オブジェクト（プロ
キシ／ウィジェット）間の通信方針に大きな影響を与え
る。通常は、アプリケーション側のプロキシ１６が修正
され、（状態の変更）、次に、ＵＩエンジン１７内の関
連づけられたウィジェット１５にそれに対応する変更を
加える（ウィジェット１５を「同期させる」）試みがな
される。（たとえば通信のタイムアウトまたはＵＩエン
ジン１７がダウンしたために）関連づけられたＵＩエン
ジン・ウィジェット１５がない場合、この「同期化」ス
テップはノーオペレーションであるが、プロキシ１６は
一貫した状態になる。後でＵＩエンジン１７が回復した
場合、アプリケーション１８はＵＩエンジン１７に再接
続し、現行状態に「同期」する。

【００３２】本発明によるシステムは、低帯域幅接続１
９に合わせて縮小されるように設計される。したがっ
て、ある種の決定にネットワーク待ち時間及びネットワ
ーク帯域幅が影響を与える。両ハーフ・オブジェクト
（プロキシ／ウィジェット）間の通信を最小限にする必
要があり、ユーザ・インタフェースの反応が遅くなるの
を回避するために要求を常に単一のメッセージとしてバ
ッチ化する必要がある。本発明は、可視のプレゼンテー
ション・データのみ（たとえば１００００行あるテーブ
ル内の可視の１０行のみ）または間もなく可視になる可
能性が高い部分のみ（たとえばテーブル内の次の１０
行）を送信することによって、通信オーバーヘッドを最
小限にすることができる。

【００３３】高待ち時間環境に対処するために、システ
ムは単一要求をバッチ化する必要がある。しかし、バッ
チ化は、要求がほとんど非同期の場合、すなわち即答を
必要とせず、送信側の妨げにならない場合にのみ可能で
ある。したがって、アプリケーション１８とＵＩエンジ
ン１７との間の通信は、ほとんど非同期である。たとえ
ば、ＵＩエンジン１７は、テーブルを描画する必要があ
る場合、アプリケーション１８に要求を送り返し、テー
ブルの可視部分のデータを要求する。ＵＩエンジン１７
は、要求したデータをただちに入手することを期待せ
ず、その代わりにプレース・ホルダを描画する。ＵＩエ
ンジン１７は、データが着信するまで待たないため、中
断せず、すぐに応答できる状態を維持する。ネットワー
ク待ち時間とアプリケーションの応答性に応じて、要求
データは後で非同期的に着信し、プレース・ホルダ・デ
ータを置き換える。

【００３４】ウィジェット・カテゴリの概要 以下の５つのカテゴリがある。 １．リソース リソースとは、ユーザ・インタフェース要素そのもので
はないが、それらの要素を構成するために使用され、し
たがってＵＩエンジン１７内及びアプリケーション１８
内に存在する必要があるすべてのオブジェクトである。
例としては、フォント、ビットマップ、画像、及びカー
ソルがある。

【００３５】２．ウィジェット ウィジェットは、ボタン、ラベル、編集可能フィール
ド、メニュー、メニュー項目のような単純なものから、
一次元スクローリング・リスト、２次元テーブルまたは
ツリー表示のようなより複雑なものまで、あらゆる種類
のプレゼンテーション要素である。

【００３６】３．レイアウト このカテゴリのウィジェットは、その子ウィジェットの
ための特定のレイアウト方針を実施するウィジェットを
含む。

【００３７】４．シェル シェル２２は、すべてのウィジェット・ツリーのルーツ
を形成する最上位ウィジェットである。シェル２２は、
典型的にはモーダル・ウィンドウまたは非モーダル・ウ
ィンドウとして表され、任意選択によりメニュー・バー
２３を有する。シェル２２はこれらの要素の協調動作を
制御する。シェル２２の例としては、「標準」シェル、
ダイアログ、アラート、及びアプリケーション全体を管
理するルート・シェル（「アプリケーション」）があ
る。

【００３８】５．モデル このカテゴリには、上記のウィジェット・カテゴリ２の
うちのいくつかのウィジェットのデータ源として使用可
能なクラスが含まれる。モデルは、周知のＭＶＣ（モデ
ル・ビュー・コントローラ）パラダイムのモデルと同じ
であり、ウィジェットはビュー及びコントローラの構成
要素を表す。

【００３９】モデル・ベースのウィジェット （カテゴリ２の）ほとんどのウィジェットは、２つの異
なるアプリケーション・プログラミング・インタフェー
スをサポートする。第１のインタフェースは、すべての
ウィジェットが組込みモデルを有し、モデルへのアクセ
スと変更のためのインタフェースを備えることを前提と
する。たとえば、「フィールド」はテキスト・モデル
と、メソッドsetText及びgetTextを有する。さらに、こ
のウィジェットは、ユーザ・インタフェース要素の視覚
的外観、たとえば使用するフォントや表示文字数を指定
するメソッドを備える。

【００４０】第２のアプリケーション・プログラミング
・インタフェースは、別個のオブジェクトである外部モ
デル３１を使用する（図４参照）。異なるウィジェット
３２が同じアプリケーションデータ構造からデータを受
け取る場合（同じデータ・オブジェクトの複数のビュー
の場合）、それらのウィジェットはすべて同じモデル３
１を共用することができる。

【００４１】このパラダイムに基づき、アプリケーショ
ン１８は典型的には、モデル「プロキシ」３１／３４と
ウィジェット／プロキシ３２／３３の両方の作成と構成
を行い、次に、たいていはウィジェット／プロキシ３２
／３３を使用しない。アプリケーション１８は、ＵＩエ
ンジン１７内で提示されたデータを更新する必要がある
場合、モデル「プロキシ」３１と対話する。アプリケー
ション１８が変更されたデータを取り出したい場合は、
ウィジェット／プロキシ３２／３３ではなくモデル３１
にそれを要求する。

【００４２】このアプリケーション・プログラミング・
インタフェースの一例は、Tableウィジェット／プロキ
シ及びTableModelである（実際には、Tableウィジェッ
ト／プロキシは組込みモデルを持たず、モデル・ベース
のアプリケーション・プログラミング・インタフェース
のみをサポートする）。TableModelは、行と列を有する
二次元データ構造を実施する。モデルのうちのＵＩエン
ジン側半分のモデルはキャッシュを含み、それによって
Tableウィジェットのデータ・アクセス要求をただちに
満たすことができる。キャッシュに有効データが入って
いない場合、TableModelはプレース・ホルダを返し、ア
プリケーション側半分のモデルに対して新しいデータを
非同期的に要求する。このデータが着信すると、それに
依存するウィジェットはそれを通知され、更新される。

【００４３】TableModelの両半分間で使用される更新方
針は、構成可能である。１つの同期方針は、送信データ
量を少なくすることによって、低帯域幅の低待ち時間接
続のために通信を最適化する。高帯域幅、高待ち時間の
ためのもう一つの方針は、往復する要求の数を減らす
が、送信データのサイズは最小化しない。

【００４４】FormModelは、モデル・ベースのアプリケ
ーション・プログラミング・インタフェースの他の例で
ある。FormModelは、異種辞書に類似した名前指定及び
タイプ指定属性のセットを表す。カテゴリ２のほとんど
のウィジェット／プロキシは、FormModelと属性名を使
用して初期設定することができる。文字列属性にはフィ
ールドを使用することができ、ブール属性にはCeckBo
x、列挙型属性にはRadioButtonを使用することができ
る。これらのウィジェット／プロキシは、それぞれの組
込みモデルを無視するが、変更を追跡し、指定されたFo
rmModelの名前指定属性の更新を可能にする。

【００４５】TableModelと同様に、異なる同期方針によ
って異なるネットワーク特性に対応することができる。
１つの方針は、属性変更のたびにFormModelのアプリケ
ーション側半分を更新する。他の方針は、明示的要求時
のみ、すべての変更を収集し、それらをリンクまたはネ
ットワーク１９を介してアプリケーション１８に１回の
コールバックで送り返す。

【００４６】４）通信態様 プロキシ１６とウィジェット１５の間の堅固で十分に高
速な伝送の場合、本発明のシステムは以下の特徴も有す
る。− プロキシ１６とウィジェット１５との間の通信
を、使用ネットワーク１９（またはリンク）の特性（帯
域幅、待ち時間）に合わせて適応化させることができ
る。−ウィジェット１５の実施は実行可能な限り無状態
であり、それによって、（ネットワーク中断またはユー
ザ端末／ＵＩエンジン１３／１７のリセット後に）プロ
キシの状態からアプリケーション１８の完全なユーザ・
インタフェースをいつでも再構築することができる。

【００４７】理想的なネットワーク条件の場合、すなわ
ち高帯域幅で低待ち時間の場合、プロキシ１６からそれ
に関連づけられたウィジェット１５にすべての要求及び
データを即時に伝送することができる。しかし、ネット
ワーク帯域幅が小さい場合、その限られた容量を最適に
使用しなければならない。すなわち、伝送を最小限に減
らす必要がある。伝送データ量を減らすために、実際に
可視である情報のみを伝送する。たとえば、アプリケー
ション１８に、数千個のデータ・セットを中に提示しな
ければならないテーブルがある場合、それらのデータ・
セットは最初にＵＩエンジン１７に全部は送信されな
い。ＵＩエンジン１７は、可視行のデータ・セットの送
信のみを要求する。さらに、アイコン、画像、アラート
などの静的情報は、ＵＩエンジン１７に１回だけ送信さ
れ、そこで必要な回数だけ使用される。

【００４８】上記の手段は、低待ち時間のネットワーク
１９に適している。待ち時間が長い場合（低速伝送の場
合）、他の手段がとられる。同期要求を回避し、ウィジ
ェット１５のローカル・インテリジェンスを向上させる
ことによって、プロキシ１６とウィジェット１５を可能
な限り遠くに分離する。（前述の）テーブル・プレゼン
テーションの場合、プロキシ１６とウィジェット１５の
間のすべての要求は非同期である。これは、ウィジェッ
トがＮ個のデータ・セットを要求した場合、Ｎ個のデー
タ・セットがすべて受信されるまで遮断されない。要求
の送信後、ウィジェット１５はローカル・テーブル構造
を一時的表現（プレース・ホルダ）オブジェクトで満た
す。ネットワーク動作に応じていくらかの遅延後に要求
データが受信され、それによってこのプレース・ホルダ
・オブジェクトが置き換えられる。同期通信の回避によ
って、多くの小さな要求を結合して単一の伝送にするこ
とも可能になり、それぞれの応答を受け取る前に保留中
の要求によって他の処理が中断されることがなくなる。

【００４９】必要通信量を低減するその他の手段 ＵＩエンジン１７とアプリケーション１８との間の往復
を減らすために、本発明を使用するシステムは、以下の
共通して使用される機能のための組込み機構を提供する
ことができる。 １）イネーブルとディスエーブル あるウィジェット１５の特別な条件を使用して、ＵＩエ
ンジン１７とアプリケーション１８との間の通信などで
他のウィジェットをイネーブル／ディスエーブルにする
ことができる。例としては、空／非空のフィールド、リ
スト及びテーブル・ウィジェット内の空／非空の選択項
目がある。 ２）検証 ＵＩエンジン１７とアプリケーション１８との間の通信
なしで範囲検査や構文検査のような検証を行うために、
あるウィジェット１５に事前定義検証オブジェクト及び
形式設定オブジェクトを付加することができる。これ
は、変更がただちに伝送されずにバッチ化されるFormMo
delベースのウィジェットで特に有用である。

【００５０】テキスト・ユーザ入力を処理し、アプリケ
ーション・プログラム２０から受け取ったデータ、テキ
スト表示しなければならないデータをを発行するすべて
のウィジェット１５について、そのデータ・タイプにと
って典型的な形式設定と検証を組み合わせるDataTypeと
いう抽象化が存在する。このオブジェクトは、任意の数
のウィジェット１５に使用することができるため、ＵＩ
エンジン１７に１回だけ送信すれば済む。その後で、そ
れ以上の通信を行わずにこのオブジェクトをユーザ入力
の検証に使用することができ、入力の繰り返しまたは修
正を要求することができ、出力のためにその項目を形式
設定することができる。

【００５１】５）その他の詳細及び可能性 ａ）データ依存書式（ページブック） 特定の状況では、関連データの値に応じて異なるウィジ
ェット１５（ダイアログ要素１１）をユーザに示さなけ
ればならない。たとえば、アカウント・データの場合、
アカウントのタイプに応じて追加の入力フィールドを示
さなければならない。これは、ユーザ・インタフェース
を動的に変更しなければならないことを意味する。本発
明を使用するシステムでは、ページブックを使用してこ
のような「動的書式」を実施することができる。ページ
ブックはページの集合から成り、ページブックの値に基
づいて、ＵＩエンジン１７はどのページを表示する必要
があるかをローカルで決定することができる。したがっ
て、そのような場合、ユーザ端末１３とアプリケーショ
ン１８との間で追加の伝送は不要である。

【００５２】ｂ）複数セッション 本発明を使用するシステムでは、ユーザ端末とアプリケ
ーションとの間に複数のセッションが存在する可能性も
ある。 １）単一のユーザ・セッションが２つ以上の異なるアプ
リケーション４１、４２と同時に動作することができ
る。この場合、ＵＩエンジン４０内の各セッションごと
に別個の異なるウィジェット構造が存在する。一方、各
アプリケーション４１、４２は、ユーザ端末のＵＩエン
ジン４０内のウィジェット・ツリー４５、４６のうちの
１つに対応する１つのプロキシ・ツリー４３、４４を維
持する（図５参照）。 ２）多くのユーザ端末がそれぞれ同時に単一のアプリケ
ーションとのセッションを有することができる。その場
合、そのアプリケーションは１つのプロキシ構造を有
し、ユーザ端末内の各ＵＩエンジンは１つの対応するウ
ィジェット構造を有する。

【００５３】６）伝送の詳細（接続オブジェクト） ユーザ端末内のウィジェット・ツリーとアプリケーショ
ンが保持するプロキシ・ツリーとの間のデータの効率的
な伝送のために、両側に特別な接続機構（接続オブジェ
クト４７）を設ける。この特別な接続機構４７を使用す
る１つのユーザ端末と２つのアプリケーション４１、４
２との間の複数セッション事例の一例を、図５に示す。

【００５４】この場合、ＵＩエンジン４０はマルチスレ
ッド構成として実施される。リスナー（聴取）スレッド
４９がアプリケーション４１、４２から接続を受け入
れ、各クライアントのために接続オブジェクト４７を作
成する。接続オブジェクト４７内のスレッドがそれぞれ
のアプリケーション４１、４２から要求を受け取り、そ
れらの要求をインタフェース・ツール・キットのイベン
ト待ち行列４８に入れる。ＵＩ４０からアプリケーショ
ン４１、４２に返されるイベント及びコールバックは、
それに関連づけられた接続オブジェクト４７の書込み待
ち行列５０に入れられ、別個の書込みスレッド５１内部
（図５の左側）で処理される。

【００５５】メイン・スレッド５２がイベント待ち行列
４８からイベントを読み取って処理する。これらの要求
は、後で参照するために接続オブジェクトのレジストリ
５７に登録されるか、またはすでに存在するオブジェク
トのメソッドを呼び出す。

【００５６】ウィジェット・ツリー４５、４６のすべて
の操作は逐次化されるため、明示的同期は不要である。
ＵＩエンジン４０からアプリケーション４１、４２への
コールバックは、同期して結果を待つことはなく、メイ
ン・スレッド５２では遮断が起こり得ない。両方の設計
上の決定によって、アーキテクチャが大幅に簡略化さ
れ、ローバスト性（堅固さ）が増す。

【００５７】アプリケーション側のアーキテクチャはＵ
Ｉエンジン側と同様である。すべてのアプリケーション
４１、４２が、２つのスレッド５４、５５を使用して非
同期通信を処理しレジストリ５６内のプロキシを維持す
る接続オブジェクト５３（図５の右側）を有する。

【００５８】複数のユーザ端末が１つのアプリケーショ
ンとの同時セッションを有する場合にも同様の構造が使
用される。いずれの場合も、ウィジェット構造とプロキ
シ構造の各対ごとに、対応する接続オブジェクトの対が
作成される。

【００５９】単一のアプリケーションと共に複数のセッ
ションが稼働している場合、または同じデータベース２
５を使用するアプリケーションの場合（図１参照）、
（ＵＩエンジン４０のための図５の左側に示すような）
逐次化バッファ４８がアプリケーション側にも必要であ
る。逐次化バッファを使用しない場合、同時アクセスか
らデータを保護するために同期化機構を使用する必要が
ある。

【００６０】２つのスレッド５１、５８（発信及び着
信）に対応するほかに、接続オブジェクト４７は接続に
付随するすべての資源、たとえばウィジェット及びプロ
キシにそれぞれオブジェクト識別子を関連づけるリスト
（レジストリ）の管理も行う。接続が閉じられた場合、
それに付随する資源がすべて解放される。

【００６１】７）アプリケーション・コントローラ ユーザ端末６０とアプリケーション６１、６２との間に
接続を確立するのを支援するために、本発明を使用する
システムにアプリケーション・コントローラ６３を備え
ることができる（図６参照）。アプリケーション・コン
トローラ６３はそれ自体が、それが稼働している機械６
４上で他の（通常の）アプリケーション６１、６２の開
始と停止を行うことができるアプリケーション・プログ
ラムである。さらに、接続されているＵＩエンジン６５
にコマンド（connectToApp）を送り、サーバ６４上で稼
働しているこれらのアプリケーション６１、６２のいず
れかとの接続６６、６７の確立を要求（connect）する
ことができる。ＵＩエンジン６５は、同時に複数の接続
６６、６７を処理することができる。これらの接続６
６、６７は受動的に確立することができ、それによって
ＵＩエンジン６５はサーバ・モードでアプリケーション
６１、６２の接続を待つ。その逆もサポート可能であ
る。すなわち、ＵＩエンジン６５によって接続６６、６
７を能動的に確立することができる。クライアント・モ
ードで、ＵＩエンジン６５は所与のＵＲＬアドレスを呼
び出す。ＵＲＬは、ＵＩエンジン６５を開始させるとき
にコマンド行引数に指定することができる。しかし、特
定の接続を介してプログラム式にアプリケーション・サ
ーバに対して（アプリケーションのＵＲＬを含む）要求
を送ることによって、ＵＩエンジン６５をアプリケーシ
ョン・サーバ６４に接続させることも可能である。

【００６２】アプリケーション・コントローラ６３は、
ウィンドウ７０に複数のアプリケーションを視覚的に提
示する（図７）。アプリケーション表現をダブル・クリ
ックするか（フィールド７２をクリックするとドシェ
（Dossier）アプリケーションが開始される）、または
アプリケーションを選択して「接続（Connect）」ボタ
ン７１をクリックすると、ＵＩエンジン６５はアプリケ
ーションのサーバ６４に接続する。接続は、アプリケー
ションを選択して「切断（Disconnect）」ボタン７３を
クリックすることによって再び閉じることができる。ア
プリケーションのサーバ６４への接続を確立することが
できる場合、対応する視覚表現が、列７４の赤色のライ
トを緑色に変えることによってそれを示す。接続は保留
の場合もある。すなわち、ＵＩエンジン６５では開始さ
れているが、サーバ６４が応答していないためにまだ確
立されていない場合である。保留接続は、列７４内の黄
色のライトによって示すことができる。アプリケーショ
ンの状態を表示または表現する方法はこの他にも多数あ
ることは明らかである。

【００６３】８）例 この項では、２つの例を示す。１つはテーブル・データ
の伝送の例で、もう一つは円グラフ表示のためのウィジ
ェットを生成する例である。

【００６４】ａ）テーブルの例 本発明を使用するシステムでは、プロキシ（アプリケー
ション・サーバ上に備えられた対応要素）は、ホスト・
プログラミング言語（たとえばJavaまたはSmalltalk）
で提供されるダイアログ要素に可能な限り類似したアプ
リケーション・プログラミング・インタフェースを有す
る。ウィジェット／プロキシ構成を使用した場合に行わ
れる様々なアクションは、プロキシのインタフェースの
通信特性についてきわめて異なる要件を有することがあ
る。したがって、ユーザはウィジェット／プロキシを使
用する場合、通信条件に厳格に合わせなければならない
ことになる。

【００６５】しかし、本発明を使用するシステムでは、
通信プロトコルがアプリケーション・プログラミング・
インタフェースからかなりの程度分離されている。これ
をテーブル・モデルの事例に関して以下に示す（図８参
照）。

【００６６】ＵＩエンジン８０におけるテーブル・モデ
ルは、主として以下のコマンドを受け入れる。 −changed：ＵＩエンジン８０内のモデルに、シャドウ
・テーブル・モデル全体（またはそのうちの指定部分）
を無効にするように通知する。これが視覚表現に影響を
与える場合、requestDataコマンドを使用して新しいデ
ータが要求される。 −sendData：ＵＩエンジン８０内のシャドウ・テーブル
・モデルにデータ（複数の行または列あるいはその両方
を含むブロック）を送る。この送出は、requestDataコ
マンドに対する応答として行うことも自発的に行うこと
もできる。

【００６７】アプリケーション側８１のプロキシは、以
下の要求を扱う。 −requestData：アプリケーション８１に対してデータ
・ブロックを要求する。この呼出しは非同期である。す
なわち、ＵＩエンジン８０をブロックせず、したがって
データの即時配信は行われない。しかし、データが妥当
な時間内に送信されることを期待する。 −setData：ユーザによって変更されたテーブル・デー
タをＵＩエンジン８０からアプリケーション８１に転送
する。

【００６８】以下では、ＵＩエンジン８０とアプリケー
ション８１との間のデータ交換の典型例について、図８
と共に説明する。第１のステップ８２で、アプリケーシ
ョン８１はＵＩエンジン８０内のモデルにテーブルのサ
イズに関して通知する。この例では、ＵＩエンジン８０
は、テーブルの最初の１０行を表示しなければならな
い。通信特性２０のために、ＵＩエンジン８０はコマン
ドrequestData（０，１９）を出すことによって２０行
を要求する（ステップ８３）。ここで、アプリケーショ
ン８１はそのデータを送るが、最初の１０行のみを送る
ことにする（ステップ８４）。それぞれのコマンドはse
ndData（０，１０，Data）である。ＵＩエンジン８０に
よって要求された残りの１０行を送る前に、アプリケー
ション８１はテーブル全体を無効化する（ステップ８
５）。アプリケーション８１は、コマンドchanged（Ｒ
ＯＷＳ，０，９９９）を送ることによってＵＩエンジン
８０内のモデルにシャドウ・テーブル・モデル全体を無
効にするように通知する。次に、ＵＩエンジン８０は再
び、テーブルの可視領域のデータのみを要求する。この
例では最初の２０行が可視であるため、ＵＩエンジンは
コマンドrequestData（０，１９）を発行する（ステッ
プ８６）。最後のステップ８７で、アプリケーション８
１は今度はＵＩエンジン８０に要求されたデータを送
る。それぞれのコマンドはsendData（０，２０，Data）
である。

【００６９】図８に示すスキームを実施する場合、通信
特性が考慮される。アプリケーション側８１のテーブル
・データの変更の結果としてchange要求を送るかどう
か、または変更されたデータをsenddataコマンドでＵＩ
エンジン８０に直接送るかどうかの選択を行う。第１の
解決策では通信の手間が増えるが、送信データ量は最小
限に低減される。第２の解決策では、通信の手間は最小
限になるが、可視ではない（表示の必要がない可能性も
ある）データが送信される可能性がある。

【００７０】ｂ）円グラフの例 ウィジェットの生成を、円グラフ９０（図９参照）の例
に関して以下に説明する。前述のように、ダイアログ要
素のウィジェット／プロキシ構成は、ＵＩエンジン内の
プレゼンテーション要素（ウィジェット）とアプリケー
ション・サーバ内の対応要素（プロキシ）の両半分から
成る。これらの要素（ハーフ・オブジェクト）に加え
て、実ダイアログ要素８０があるが、これはすでに存在
することが多く、本発明を使用するシステムに合わせて
適応させる必要はない。実ダイアログ要素と、ＵＩエン
ジン内のプレゼンテーション要素（ウィジェット）はJa
vaで実施される。アプリケーション・サーバ内の対応要
素（プロキシ）は、システムがサポートする各言語（た
とえばSmalltalkやJava）ごとに実施しなければならな
い。

【００７１】円グラフ実施態様の詳細 円グラフ（PieChart）９０は、示す値とそれぞれの名前
と色の設定をサポートする。円区分９１〜９３をクリッ
クすると、クリックされた区分の名前を持つアクション
が引数として送られる。

【００７２】説明を簡単にするために、PieChart９０は
モデル・ベースのウィジェットとしては実施されていな
い。モデル・ベースのウィジェットの実施には、モデル
・オブジェクトの変更にアクセスし、追跡する対応する
ハーフ・オブジェクトの実施が必要になる。

【００７３】ウィジェット（プレゼンテーション要素）
の実施 ＵＩエンジンがインスタンス化する必要がある場合、プ
ロキシ１６に対応するウィジェット１５を見つけるため
に様々な規則を使用する。（注：この場合、２つのハー
フ・オブジェクトの関連づけはウィジェットの名前に基
づく。）規則は、ＵＩエンジン・ウィジェット（UIPieC
hart）の「ＵＩ」エンジン・プレフィックスと、プロキ
シ・ハーフの（UlCPieChart）のプレフィックスを使用
することである。各ＵＩエンジン・ウィジェットは、そ
の状態をプリキシから初期設定しなければならない。さ
らに、PieChart９０は以下のアプリケーション・プログ
ラミング・インタフェースを提供する。 １．データ（値、ラベル、色）を設定する要求を処理す
る ２．円区分がクリックされるとプロキシ１６にイベント
を送る。

【００７４】UIPieChartは、com.oti.ulc.UI.Component
から派生する子孫である。UIPieCharはPieChartを、Ｕ
Ｉエンジンが使用できるように適応化させる。そのため
に、UIPieChartはPieChartウィジェットを指す参照を維
持する。以下に、UIPieChartのクラス定義からの一例を
示す。 public class UIPieChart extends UIComponent implements ActionListener { private PieChart fPieChart= null; } その状態をプロキシからリストアするために、UIPieChartはrestoreStateを上書 きする。 public void restoreState(ORBConnection conn, Anything args) { super.restoreState(conn, args); fPieChart= new PieChart(args.get("w", 200), args.get("h", 150)); fPieChart.setData(args.get("data")); fPieChart.addActionListener(this); }

【００７５】継承されたrestoreStateメソッドに対する
呼出しによって、継承された状態がリストアされる。Pi
eChartウィジェットが、このリストアされた状態を使用
して作成され、初期設定される。この例では、ORBConne
ction引数は使用されず、単にベース・クラスに渡され
る。

【００７６】ＵＩエンジンとプロキシとの間のデータ通
信は、Anythingと呼ぶデータ・オブジェクトに基づく。
Anythingは、プロセス間で転送可能な動的データ構造で
ある。メソッドrestoreStateは、Anythingをその引数と
して受け取り、Anythingアクセス・メソッドを使用して
個々の引数を取り出す。Anythingは、単純なデータ・タ
イプまたは配列と、Anythingの辞書を含むことができ
る。引数を取り出すには、プロキシとＵＩエンジン・ウ
ィジェットが、引数をAnythingにどのようにパッケージ
化するかについて合意する必要がある。この場合、Anyt
hingは辞書であり、restoreStateは引数を名前によって
取り出す。たとえば、arts.get("w")は、円グラフの幅
引数を取り出す。同様に、メソッドsetDataは、Anythin
gから円グラフのデータをリストアし、それをPieChart
ウィジェットに渡す。

【００７７】UIPieChartは、円区分９１〜９３がクリッ
クされるとプロキシに通知したいため、ActionListener
インタフェースを実施する。UIPieChartはそれ自体をPi
eChartのアクション・リスナーとして登録する。プロキ
シから送られた要求はhandleRequestにディスパッチさ
れる。このメソッドは、要求の名前をAnythingとしてパ
ッケージ化されたその引数と共に受け取る。UIPieChart
は、円グラフのデータを設定するために以下のようにse
tDataという単一の要求のみを実施する。 public void handleRequest(ORBConnection conn, String request, Anything args){ if(request.equals(" setData")) { setData(args); return; } seper.handleRequest(conn, request, args); }

【００７８】メソッドhandleRequestはメソッドsetData
を使用してAnythingからデータを取り出し、それをPieC
hartに入れる。継承されたhandleRequestを呼び出すこ
とによって、ベース・クラスはその要求を処理すること
ができる。

【００７９】ユーザが円区分をクリックすると、UIPiec
hartはプロキシにイベントを送る。そのために、Action
ListenerメソッドactionPerformedを実施し、sendEvent
ULCを呼び出してそのイベントを送る。

【００８０】SendEventULCはイベントの名前とそのタイ
プ名と引数とを入手する。イベントの引数はAnythingに
入れられる。この場合、これはクリックされた円区分の
ラベルに対応する単純な文字列である。

【００８１】プロキシ（対応要素）の実施 上述の例では、ＵＩエンジン側半分における要求の処理
とイベントの送信方法を示した。この項では、PieChart
９０のプロキシ側半分を実施する方法について説明す
る。このPieChartウィジェットは、JavaとSmalltalkの
両方から使用可能である必要があるため、両方の言語の
実施態様がある。

【００８２】Javaでのプロキシの実施 PieChartのJava側半分はクラスULCPieChartに定義され
る。UIPieChartとは異なり、ULCPieChartは任意のパッ
ケージに定義することができる。この実施態様は、プロ
キシにＵＬＣをプレフィックスとして付ける規則を使用
する。内部的に、プロキシはそのＵＩエンジン・ウィジ
ェットを作成したい場合、作成するウィジェットのタイ
プ名をＵＩエンジンに渡す。デフォルトでは、タイプ名
はＵＬＣプレフィックスの付いていないクラス名に対応
する。所望であれば、ULCProxyに定義されているメソッ
ドtypeStringを上書きすることによってこのデフォルト
を変更することができる。

【００８３】プロキシは、対応するＵＩエンジン側半分
の状態を保持する必要がある。そのために、ULCPieChar
tは円グラフの値、ラベル、及び色をそのインスタンス
変数に格納する。

【００８４】ULCPieChartは、ＵＩエンジンにそのプロ
キシ・クラスの場所を知らせる必要がある。これは、完
全修飾クラス・パスを返すtypeStringメソッドを実施す
ることによって行われる。

【００８５】ULCPieChartは、ＵＩエンジン要求を対称
に実施しなければならない。まず、ＵＩエンジンにウィ
ジェットの状態を送る必要がある。これは、saveState
を上書きすることによって行われる。SaveStateは、そ
のインスタンス変数で保持されている引数をAnythingに
入れる。

【００８６】setData要求は以下のULCPieChartメソッド
で実施される。 public void setData(String[] labels, double[] values, String[] colors) { fValues= new double[values.length]; fcolors= new String[colors.length]; fLabels= new String[Labels.length] system.arraycopy(labels, 0, fLabels, 0, labels.length); System.arraycopy(values, 0 fValues, 0, values.length); System.arraycopy(colors, 0, fColors, 0, colors.length); Anything data= new Anything(); fillData(data); sendUI("setData", data); }

【００８７】要求メソッドは、その引数をAnythingにパ
ッケージするだけでよい。この場合、値、ラベル、及び
色を有する配列を、ＵＩエンジン側半分によって実行さ
れるAnything構造に入れる。次に、要求は要求名とAnyt
hing引数をＵＩエンジンに送るsendUIによってＵＩエン
ジンに送られる。

【００８８】最後のステップは、UIpieChart９０からの
アクション・イベントを処理することである。要求を処
理するには、handleRequestを上書きする。このメソッ
ドは、要求データを格納するAnythingと共に要求の名前
を受け取る。 public void handleRequest(ORBConnection conn, String request, Anything arg) { if (request.equals("ebent")) { // (1) string type= args.get("type", "???"); if (type.equals("action")) // (2) distributeToListeners(new ULCActionEvent(this, args.get("cmd", "???"))); // (3) return; } super.handleRequest(conn, request, args); }

【００８９】handeleRequestで実施されるステップは以
下の通りである。 １．要求がイベントであるかどうかを検査する。 ２．イベント要求のタイプを検査して、アクション・イ
ベントであるかどうかを調べる。 ３．アクション・イベントである場合、ULCActionEvent
を作成し、distributeToListenersメソッドを使用して
登録されているリスナーに通知する。 ４．アクション・イベントでない場合、それをベース・
クラスに渡す。

【００９０】Smalltalkでのプロキシの実施 ULCPieChartのSmalltalk実施態様は、Java実施態様と概
念的には同じである。saveState：メソッドが、ウィジ
ェット・データをSmalltalk版のAnythingにパックす
る。

【００９１】以下は、setData要求の実施態様である。 setData: aValuesCollection colors: aColorsCollecton labels: aLabelsCollection | data | data := self fillData: aValues Collection colors: aColorsCollection labels: aLabelsCollection. self sendToUI: 'setData' with: data

【００９２】Smalltalkでは、ＵＩエンジン・ウィジェ
ットの作成を要求するために使用されるタイプ名は、メ
ソッドtypeStringを上書きすることによって定義され
る。

【００９３】ULCPieChartの場合、単にストリング'PieC
hart'を返すだけでよい。

【００９４】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００９５】（１）リンクまたはネットワーク（１９）
を介してサーバ（１４、６４）内のアプリケーション・
プログラム（１８、６１、６２、８１）とユーザ端末
（１３、６０）の間で対話式協調動作を行うためのシス
テムであって、前記アプリケーション・プログラム（１
８、６１、６２、８１）と前記ユーザ端末（１３、６
０）との間にプレゼンテーション層が設けられ、前記ユ
ーザ端末（１３、６０）上での情報のプレゼンテーショ
ンのためにダイアログ要素（１１、７０、９０）が使用
されるシステムにおいて、前記プレゼンテーション層
が、一部が前記ユーザ端末（１３、６０）内で実施さ
れ、一部が前記サーバ（１４、６４）で実施され、前記
ダイアログ要素（１１、７０、９０）を表す１対のプレ
ゼンテーション要素を含み、前記対のうちの１つのプレ
ゼンテーション要素（１５）が前記ユーザ端末（１３、
６０）内に設けられ、前記対のうちの対応するプレゼン
テーション要素（１６）が前記サーバ（１４、６４）に
設けられ、前記ユーザ端末（１３、６０）内に前記ユー
ザ端末（１３、６０）内の前記プレゼンテーション要素
（１５）を独立して制御するプログラム・オブジェクト
（１７、４０、６５）が設けられたシステム。 （２）ユーザ端末（１３、６０）と、アプリケーション
・プログラム（１８、６１、６２、８１）を有するサー
バ（１４、６４）と、データ交換のためのユーザ端末
（１３、６０）とサーバ（１４、６４）との間のリンク
またはネットワーク（１９）とを含み、前記ユーザ端末
（１３、６０）と前記アプリケーション・プログラム
（１８、６１、６２、８１）との間のダイアログ・デー
タ及びメッセージの対話式伝送のためにプレゼンテーシ
ョン・インタフェースが設けられたシステムであって、
前記プレゼンテーション層が、ユーザ端末（１３、６
０）とアプリケーション・プログラム（１８、６１、６
２、８１）とに分割され、ユーザ端末（１３、６０）に
おける前記ダイアログ・データのプレゼンテーションま
たは入力あるいはその両方のために使用されるダイアロ
グ要素のために、前記ダイアログ・データの転送と保持
のための１対のインタフェース要素を備え、前記対のう
ちの一方のインタフェース要素（１５）が前記ユーザ端
末（１３、６０）内に配置され、前記対のうちの他方の
インタフェース要素（１６）が前記サーバ（１４、６
４）内に配置され、前記ユーザ端末（１３、６０）内に
配置された前記インタフェース要素（１５）を制御する
プログラム・オブジェクト（１７、４０、６５）が前記
ユーザ端末（１３、６０）内に設けられ、それぞれ前記
ユーザ端末（１３、６０）内と前記サーバ（１４、６
４）内の前記対のインタフェース要素の対応するインタ
ーネット要素間で前記ダイアログ・データを独立して交
換する機構が設けられたシステム。 （３）前記ユーザ端末（１３、６０）上でのダイアログ
・データの入力または出力あるいはその両方のためのダ
イアログ要素を含む、リンクまたはネットワーク（１
９）を介したアプリケーション・プログラム（１８、６
１、６２、８１）と遠隔ユーザ端末（１３、６０）との
間の対話協調動作のための方法であって、前記ユーザ端
末（１３、６０）内に前記ダイアログ・データの転送と
保持を行うプレゼンテーション要素（１５）の構造と、
前記プレゼンテーション要素（１５）の実施と制御を行
う管理機構とを設定するステップと、前記アプリケーシ
ョン・プログラム（１８、６１、６２、８１）と共に、
前記ダイアログ・データの転送と保持を行う対応要素
（１６）の対応する構造を設定するステップと、前記ダ
イアログ・データの対話式交換のために、関連づけられ
たプレゼンテーション要素（１５）内と対応する対応要
素（１６）内とでそれぞれ前記ダイアログ要素のための
２つの対応するデータ・セットを保持するステップとを
含み、それによって、前記ユーザ端末（１３、６０）と
前記アプリケーション・プログラム（１８、６１、６
２、８１）とがそれぞれ、前記リンクまたはネットワー
ク（１９）を介した伝送とは独立して、前記プレゼンテ
ーション要素（１５）及び対応要素（１６）とそれぞれ
協調動作することができる方法。 （４）前記ユーザ端末内の前記インタフェース要素（１
５）と前記アプリケーション・プログラムに備えられた
前記インタフェース要素（１６）とのために、両側の対
応するモデルが対称であるデータ構造モデルが備えら
れ、それによって両方のモデルのそれぞれの場所に同じ
データを格納することができる、上記（１）または
（２）に記載のシステム。 （５）前記モデルが前記ユーザ端末内の関連づけられた
インタフェース要素（１５）及び前記サーバの前記イン
タフェース要素（１６）からそれぞれ分離して設けら
れ、それによって両側の対応するモデル間でデータを直
接転送することができる、上記（４）に記載のシステ
ム。 （６）同じデータ構造からの異なるデータ・セットを必
要とする、サーバに設けられた複数のプレゼンテーショ
ン要素（１６）のために、共通のモデルが設けられた、
上記（４）に記載のシステム。 （７）サーバ（１４、６４）に設けられた前記インタフ
ェース要素（１６）及び前記ユーザ端末（１３、６０）
内に設けられた前記インタフェース要素（１５）が、前
記各インタフェース要素が使用されるアプリケーション
に従ったツリー構造に編成され、前記ユーザ端末（１
３、６０）内の前記構造は前記アプリケーション・プロ
グラム（１８、６１、６２、８１）からの命令に従って
前記ユーザ端末（１３、６０）内に設けられたプログラ
ム・オブジェクト（１７、４０、６５）によって実施さ
れる、上記（１）または（２）に記載のシステム。 （８）前記ユーザ端末（１３、６０）内のプレゼンテー
ション要素（１５）の各構造と前記サーバ（１４、６
４）に備えられたインタフェース要素（１６）の各構造
とについて通信機構が設けられ、各通信機構が、双方向
データ伝送のために前記リンクまたはネットワーク（１
９）に接続され、インタフェース要素の関連づけられた
前記構造との間でデータまたは要求の伝送を行うための
バッファ機能（４８、５０）を有する別々の入力パスと
出力パスを有する、上記（１）または（２）に記載のシ
ステム。 （９）前記通信機構の伝送特性が、前記リンクまたはネ
ットワーク（１９）の現行伝送特性に適合するように選
択的に修正可能である、上記（８）に記載のシステム。 （１０）前記ユーザ端末（１３、６０）上での情報のプ
レゼンテーションが、ダイアログ・データまたはメッセ
ージあるいはその両方の入力または出力あるいはその両
方である、上記（１）または（２）に記載のシステム。 （１１）前記対のプレゼンテーション要素がデータ、好
ましくはダイアログ・データの交換のために使用され
る、上記（１）または（２）に記載のシステム。 （１２）前記対のインタフェース要素のうちの前記ユー
ザ端末（１３、６０）内に設けられたインタフェース要
素（１５）がウィジェットまたはプレゼンテーション要
素であり、前記対のインタフェース要素のうちの前記サ
ーバ（１４、６４）に設けられた対応するプレゼンテー
ション要素（１６）がプロキシまたは対応要素である、
上記（１）または（２）に記載のシステム。 （１３）前記プログラム・オブジェクト（１７、４０、
６５）がユーザ・インタフェース・エンジンである、上
記（１）または（２）に記載のシステム。 （１４）対話式セッションのために前記アプリケーショ
ン・プログラム（１８、６１、６２、８１）を使用して
前記対応要素（１６）内にロードされたデータのセット
から、前記ユーザ端末（１３、６０）が実際に必要とす
るデータのみが前記ユーザ端末（１３、６０）内の前記
プレゼンテーション要素（１５）に転送される、上記
（３）に記載の方法。 （１５）アプリケーションから前記ユーザ端末（１３、
６０）への前記ダイアログ・データの非同期転送のため
に、前記ユーザ端末（１３、６０）における関係するプ
レゼンテーション要素をプレース・ホルダ項目で満た
し、それぞれの前記対応要素（１６）から前記リンクま
たはネットワーク（１９）を介して実際のデータ項目を
受け取ると、前記プレース・ホルダ項目が実際のデータ
項目によって置き換えられる、上記（３）に記載の方
法。 （１６）前記ユーザ端末（１３、６０）の前記プレゼン
テーション要素（１５）内の必要データに、前記サーバ
（１４、６４）に備えられた前記対応要素（１６）内の
データをロードし直すことによって、中断後の対話セッ
ションを再開するステップをさらに含む、上記（３）に
記載の方法。 （１７）少なくとも１つのローカル・プレゼンテーショ
ン要素の状況に応じて前記ユーザ端末（１３、６０）内
の前記プレゼンテーション要素（１５）をイネーブルま
たはディスエーブルにし、それによってリンクまたはネ
ットワーク（１９）を介した前記アプリケーション（１
８、６１、６２、８１）からのイネーブルまたはディス
エーブル情報の伝送を回避する、上記（３）に記載の方
法。 （１８）前記プレゼンテーション要素（１５）と対応要
素（１６）とをツリー構造に編成するステップと、対話
セッションの初めに前記ユーザ端末（１３、６０）を前
記アプリケーション・プログラム（１８、６１、６２、
８１）の制御下で初期設定するステップとを含む、上記
（３）に記載の方法。 （１９）現行の状況に適合させるように、対話セッショ
ン中に前記アプリケーション・プログラム（１８、６
１、６２、８１）の制御下で前記ユーザ端末（１３、６
０）内の前記プレゼンテーション要素（１５）のツリー
構造を修正するステップを含む、上記（１８）に記載の
方法。 （２０）対話式システムにおいて、アプリケーション・
プログラム（１８、６１、６２、８１）のホストである
設備（１４、６４）にネットワークまたはリンク（１
９）を介して接続されたユーザ端末（１３、６０）上で
データを提示する方法であって、前記ユーザ端末（１
３、６０）において、前記アプリケーション・プログラ
ム（１８、６１、６２、８１）からデータを受け取り、
保持するプレゼンテーション要素（１５）を設定するス
テップと、前記ユーザ端末（１３、６０）において、前
記プレゼンテーション要素（１５）を制御する管理機構
を設定するステップと、前記設備（１４、６４）におい
て、前記データの転送と保持を行う対応要素（１６）の
対応する構造を設定するステップと、前記設備（１４、
６４）と前記ユーザ端末（１３、６０）との間のデータ
の対話式交換のために、前記プレゼンテーション要素
（１５）と前記対応する対応要素（１６）のそれぞれに
おいて１セットの対応するデータを維持するステップと
を含み、それによって、ユーザ端末（１３、６０）が前
記プレゼンテーション要素（１５）で維持されているデ
ータをユーザに提示するために使用することができる方
法。 （２１）前記対話式システムが保険業、銀行業、製造
業、ホテル、またはコール・センターのアプリケーショ
ンである、上記（２０）に記載の方法。 （２２）前記設備（１４、６４）が前記アプリケーショ
ン・プログラム（１８、６１、６２、８１）にデータを
提供するデータベースまたは業務サービスに接続され、
前記データが保険業、銀行業、製造業、ホテル、または
コール・センター固有のデータである、上記（２１）に
記載の方法。 （２３）前記ユーザ端末（１３、６０）に新規データを
入力するステップと、前記プレゼンテーション要素（１
５）から前記リンクまたはネットワーク（１９）と前記
対応する対応要素（１６）とを介して前記アプリケーシ
ョン・プログラム（１８、６１、６２、８１）に前記新
規データを転送するステップとを含む、上記（２０）に
記載の方法。 （２４）前記プレゼンテーション要素（１５）から前記
リンクまたはネットワーク（１９）と前記対応する対応
要素（１６）とを介して前記アプリケーション・プログ
ラム（１８、６１、６２、８１）に前記新規データを転
送する前に、前記ユーザ端末（１３、６０）内で前記新
規データをローカルで検証するステップを含む、上記
（２３）に記載の方法。

【図面の簡単な説明】

【図１】本発明を使用するシステムを示すブロック図で
ある。

【図２】図１のシステムにおけるプレゼンテーション要
素と対応要素（ウィジェット／プロキシ）の対／分割性
を示す図である。

【図３】特定のアプリケーション（ドシェ（Dossie
r））のために使用されるプレゼンテーション要素（ウ
ィジェット）の構造を示す図である。

【図４】プレゼンテーション要素と対応要素のそれぞれ
が、モデル間の中間記憶と直接伝送のためにそれぞれの
データ構造の関連づけられたモデルを有する本発明の特
定の実施形態を示す図である。

【図５】リンクの両側で対称な入力／出力機構とバッフ
ァリング機構とを使用する、プレゼンテーション要素と
対応要素との間の通信の編成を示す図である。

【図６】ユーザ端末内のユーザ・インタフェース・エン
ジンが共通（中央）アプリケーション・サーバ内のアプ
リケーション・コントローラとどのように協調動作して
対話セッションを開始することができるかを示す図であ
る。

【図７】ユーザ端末内のユーザ・インタフェース・エン
ジンが共通（中央）アプリケーション・サーバ内のアプ
リケーション・コントローラとどのように協調動作して
対話セッションを開始することができるかを示す図であ
る。

【図８】本発明を使用するシステムにおけるテーブル・
データの対話式伝送の詳細を示す図である。

【図９】ウィジェットの実施態様を説明する円グラフを
示す図である。

【符号の説明】

１１ ダイアログ要素 １２ 表示装置 １３ ユーザ端末 １４ サーバ １５ プレゼンテーション要素（ウィジェット） １６ 対応要素 １７ ユーザ・インタフェース・エンジン １８ アプリケーション １９ 通信リンク ２１ アプリケーション・ウィジェット ２２ シェル ２３ メニュー・バー ３１ モデル ３２ ウィジェット ３３ モデル ４０ ＵＩエンジン ４１ アプリケーション ４２ アプリケーション ４３ プロキシ・ツリー ４４ プロキシ・ツリー ４５ ウィジェット・ツリー ４６ ウィジェット・ツリー ４７ 接続オブジェクト ４８ イベント待ち行列 ５１ 書込みスレッド ５２ メイン・スレッド ５３ 接続オブジェクト ５４ 読取りスレッド ５５ 書込みスレッド ５６ レジストリ ５７ レジストリ ５８ 読取りスレッド ６０ ユーザ端末 ６１ アプリケーション ６２ アプリケーション ６３ アプリケーション・コントローラ ６４ アプリケーション・サーバ ６５ ＵＩエンジン

───────────────────────────────────────────────────── フロントページの続き (72)発明者 サンジャイ・マダヴァン スイス シー・エイチ−8052 チューリヒ シャフハウザーシュトラーセ452 (72)発明者 アンドレ・ヴァイナント スイス シー・エイチ−8006 チューリヒ ブリュームリスアルプシュトラーセ19

Claims (24)

【特許請求の範囲】
1. 【請求項１】リンクまたはネットワーク（１９）を介し
   てサーバ（１４、６４）内のアプリケーション・プログ
   ラム（１８、６１、６２、８１）とユーザ端末（１３、
   ６０）の間で対話式協調動作を行うためのシステムであ
   って、 前記アプリケーション・プログラム（１８、６１、６
   ２、８１）と前記ユーザ端末（１３、６０）との間にプ
   レゼンテーション層が設けられ、 前記ユーザ端末（１３、６０）上での情報のプレゼンテ
   ーションのためにダイアログ要素（１１、７０、９０）
   が使用されるシステムにおいて、 前記プレゼンテーション層が、一部が前記ユーザ端末
   （１３、６０）内で実施され、一部が前記サーバ（１
   ４、６４）で実施され、前記ダイアログ要素（１１、７
   ０、９０）を表す１対のプレゼンテーション要素を含
   み、前記対のうちの１つのプレゼンテーション要素（１
   ５）が前記ユーザ端末（１３、６０）内に設けられ、前
   記対のうちの対応するプレゼンテーション要素（１６）
   が前記サーバ（１４、６４）に設けられ、 前記ユーザ端末（１３、６０）内に前記ユーザ端末（１
   ３、６０）内の前記プレゼンテーション要素（１５）を
   独立して制御するプログラム・オブジェクト（１７、４
   ０、６５）が設けられたシステム。
2. 【請求項２】ユーザ端末（１３、６０）と、アプリケー
   ション・プログラム（１８、６１、６２、８１）を有す
   るサーバ（１４、６４）と、データ交換のためのユーザ
   端末（１３、６０）とサーバ（１４、６４）との間のリ
   ンクまたはネットワーク（１９）とを含み、 前記ユーザ端末（１３、６０）と前記アプリケーション
   ・プログラム（１８、６１、６２、８１）との間のダイ
   アログ・データ及びメッセージの対話式伝送のためにプ
   レゼンテーション・インタフェースが設けられたシステ
   ムであって、 前記プレゼンテーション層が、ユーザ端末（１３、６
   ０）とアプリケーション・プログラム（１８、６１、６
   ２、８１）とに分割され、ユーザ端末（１３、６０）に
   おける前記ダイアログ・データのプレゼンテーションま
   たは入力あるいはその両方のために使用されるダイアロ
   グ要素のために、前記ダイアログ・データの転送と保持
   のための１対のインタフェース要素を備え、前記対のう
   ちの一方のインタフェース要素（１５）が前記ユーザ端
   末（１３、６０）内に配置され、前記対のうちの他方の
   インタフェース要素（１６）が前記サーバ（１４、６
   ４）内に配置され、 前記ユーザ端末（１３、６０）内に配置された前記イン
   タフェース要素（１５）を制御するプログラム・オブジ
   ェクト（１７、４０、６５）が前記ユーザ端末（１３、
   ６０）内に設けられ、 それぞれ前記ユーザ端末（１３、６０）内と前記サーバ
   （１４、６４）内の前記対のインタフェース要素の対応
   するインターネット要素間で前記ダイアログ・データを
   独立して交換する機構が設けられたシステム。
3. 【請求項３】前記ユーザ端末（１３、６０）上でのダイ
   アログ・データの入力または出力あるいはその両方のた
   めのダイアログ要素を含む、リンクまたはネットワーク
   （１９）を介したアプリケーション・プログラム（１
   ８、６１、６２、８１）と遠隔ユーザ端末（１３、６
   ０）との間の対話協調動作のための方法であって、 前記ユーザ端末（１３、６０）内に前記ダイアログ・デ
   ータの転送と保持を行うプレゼンテーション要素（１
   ５）の構造と、前記プレゼンテーション要素（１５）の
   実施と制御を行う管理機構とを設定するステップと、 前記アプリケーション・プログラム（１８、６１、６
   ２、８１）と共に、前記ダイアログ・データの転送と保
   持を行う対応要素（１６）の対応する構造を設定するス
   テップと、 前記ダイアログ・データの対話式交換のために、関連づ
   けられたプレゼンテーション要素（１５）内と対応する
   対応要素（１６）内とでそれぞれ前記ダイアログ要素の
   ための２つの対応するデータ・セットを保持するステッ
   プとを含み、 それによって、前記ユーザ端末（１３、６０）と前記ア
   プリケーション・プログラム（１８、６１、６２、８
   １）とがそれぞれ、前記リンクまたはネットワーク（１
   ９）を介した伝送とは独立して、前記プレゼンテーショ
   ン要素（１５）及び対応要素（１６）とそれぞれ協調動
   作することができる方法。
4. 【請求項４】前記ユーザ端末内の前記インタフェース要
   素（１５）と前記アプリケーション・プログラムに備え
   られた前記インタフェース要素（１６）とのために、両
   側の対応するモデルが対称であるデータ構造モデルが備
   えられ、それによって両方のモデルのそれぞれの場所に
   同じデータを格納することができる、請求項１または２
   に記載のシステム。
5. 【請求項５】前記モデルが前記ユーザ端末内の関連づけ
   られたインタフェース要素（１５）及び前記サーバの前
   記インタフェース要素（１６）からそれぞれ分離して設
   けられ、それによって両側の対応するモデル間でデータ
   を直接転送することができる、請求項４に記載のシステ
   ム。
6. 【請求項６】同じデータ構造からの異なるデータ・セッ
   トを必要とする、サーバに設けられた複数のプレゼンテ
   ーション要素（１６）のために、共通のモデルが設けら
   れた、請求項４に記載のシステム。
7. 【請求項７】サーバ（１４、６４）に設けられた前記イ
   ンタフェース要素（１６）及び前記ユーザ端末（１３、
   ６０）内に設けられた前記インタフェース要素（１５）
   が、前記各インタフェース要素が使用されるアプリケー
   ションに従ったツリー構造に編成され、前記ユーザ端末
   （１３、６０）内の前記構造は前記アプリケーション・
   プログラム（１８、６１、６２、８１）からの命令に従
   って前記ユーザ端末（１３、６０）内に設けられたプロ
   グラム・オブジェクト（１７、４０、６５）によって実
   施される、請求項１または２に記載のシステム。
8. 【請求項８】前記ユーザ端末（１３、６０）内のプレゼ
   ンテーション要素（１５）の各構造と前記サーバ（１
   ４、６４）に備えられたインタフェース要素（１６）の
   各構造とについて通信機構が設けられ、各通信機構が、
   双方向データ伝送のために前記リンクまたはネットワー
   ク（１９）に接続され、インタフェース要素の関連づけ
   られた前記構造との間でデータまたは要求の伝送を行う
   ためのバッファ機能（４８、５０）を有する別々の入力
   パスと出力パスを有する、請求項１または２に記載のシ
   ステム。
9. 【請求項９】前記通信機構の伝送特性が、前記リンクま
   たはネットワーク（１９）の現行伝送特性に適合するよ
   うに選択的に修正可能である、請求項８に記載のシステ
   ム。
10. 【請求項１０】前記ユーザ端末（１３、６０）上での情
    報のプレゼンテーションが、ダイアログ・データまたは
    メッセージあるいはその両方の入力または出力あるいは
    その両方である、請求項１または２に記載のシステム。
11. 【請求項１１】前記対のプレゼンテーション要素がデー
    タ、好ましくはダイアログ・データの交換のために使用
    される、請求項１または２に記載のシステム。
12. 【請求項１２】前記対のインタフェース要素のうちの前
    記ユーザ端末（１３、６０）内に設けられたインタフェ
    ース要素（１５）がウィジェットまたはプレゼンテーシ
    ョン要素であり、前記対のインタフェース要素のうちの
    前記サーバ（１４、６４）に設けられた対応するプレゼ
    ンテーション要素（１６）がプロキシまたは対応要素で
    ある、請求項１または２に記載のシステム。
13. 【請求項１３】前記プログラム・オブジェクト（１７、
    ４０、６５）がユーザ・インタフェース・エンジンであ
    る、請求項１または２に記載のシステム。
14. 【請求項１４】対話式セッションのために前記アプリケ
    ーション・プログラム（１８、６１、６２、８１）を使
    用して前記対応要素（１６）内にロードされたデータの
    セットから、前記ユーザ端末（１３、６０）が実際に必
    要とするデータのみが前記ユーザ端末（１３、６０）内
    の前記プレゼンテーション要素（１５）に転送される、
    請求項３に記載の方法。
15. 【請求項１５】アプリケーションから前記ユーザ端末
    （１３、６０）への前記ダイアログ・データの非同期転
    送のために、前記ユーザ端末（１３、６０）における関
    係するプレゼンテーション要素をプレース・ホルダ項目
    で満たし、それぞれの前記対応要素（１６）から前記リ
    ンクまたはネットワーク（１９）を介して実際のデータ
    項目を受け取ると、前記プレース・ホルダ項目が実際の
    データ項目によって置き換えられる、請求項３に記載の
    方法。
16. 【請求項１６】前記ユーザ端末（１３、６０）の前記プ
    レゼンテーション要素（１５）内の必要データに、前記
    サーバ（１４、６４）に備えられた前記対応要素（１
    ６）内のデータをロードし直すことによって、中断後の
    対話セッションを再開するステップをさらに含む、請求
    項３に記載の方法。
17. 【請求項１７】少なくとも１つのローカル・プレゼンテ
    ーション要素の状況に応じて前記ユーザ端末（１３、６
    ０）内の前記プレゼンテーション要素（１５）をイネー
    ブルまたはディスエーブルにし、それによってリンクま
    たはネットワーク（１９）を介した前記アプリケーショ
    ン（１８、６１、６２、８１）からのイネーブルまたは
    ディスエーブル情報の伝送を回避する、請求項３に記載
    の方法。
18. 【請求項１８】前記プレゼンテーション要素（１５）と
    対応要素（１６）とをツリー構造に編成するステップ
    と、 対話セッションの初めに前記ユーザ端末（１３、６０）
    を前記アプリケーション・プログラム（１８、６１、６
    ２、８１）の制御下で初期設定するステップとを含む、
    請求項３に記載の方法。
19. 【請求項１９】現行の状況に適合させるように、対話セ
    ッション中に前記アプリケーション・プログラム（１
    ８、６１、６２、８１）の制御下で前記ユーザ端末（１
    ３、６０）内の前記プレゼンテーション要素（１５）の
    ツリー構造を修正するステップを含む、請求項１８に記
    載の方法。
20. 【請求項２０】対話式システムにおいて、アプリケーシ
    ョン・プログラム（１８、６１、６２、８１）のホスト
    である設備（１４、６４）にネットワークまたはリンク
    （１９）を介して接続されたユーザ端末（１３、６０）
    上でデータを提示する方法であって、 前記ユーザ端末（１３、６０）において、前記アプリケ
    ーション・プログラム（１８、６１、６２、８１）から
    データを受け取り、保持するプレゼンテーション要素
    （１５）を設定するステップと、 前記ユーザ端末（１３、６０）において、前記プレゼン
    テーション要素（１５）を制御する管理機構を設定する
    ステップと、 前記設備（１４、６４）において、前記データの転送と
    保持を行う対応要素（１６）の対応する構造を設定する
    ステップと、 前記設備（１４、６４）と前記ユーザ端末（１３、６
    ０）との間のデータの対話式交換のために、前記プレゼ
    ンテーション要素（１５）と前記対応する対応要素（１
    ６）のそれぞれにおいて１セットの対応するデータを維
    持するステップとを含み、 それによって、ユーザ端末（１３、６０）が前記プレゼ
    ンテーション要素（１５）で維持されているデータをユ
    ーザに提示するために使用することができる方法。
21. 【請求項２１】前記対話式システムが保険業、銀行業、
    製造業、ホテル、またはコール・センターのアプリケー
    ションである、請求項２０に記載の方法。
22. 【請求項２２】前記設備（１４、６４）が前記アプリケ
    ーション・プログラム（１８、６１、６２、８１）にデ
    ータを提供するデータベースまたは業務サービスに接続
    され、前記データが保険業、銀行業、製造業、ホテル、
    またはコール・センター固有のデータである、請求項２
    １に記載の方法。
23. 【請求項２３】前記ユーザ端末（１３、６０）に新規デ
    ータを入力するステップと、 前記プレゼンテーション要素（１５）から前記リンクま
    たはネットワーク（１９）と前記対応する対応要素（１
    ６）とを介して前記アプリケーション・プログラム（１
    ８、６１、６２、８１）に前記新規データを転送するス
    テップとを含む、請求項２０に記載の方法。
24. 【請求項２４】前記プレゼンテーション要素（１５）か
    ら前記リンクまたはネットワーク（１９）と前記対応す
    る対応要素（１６）とを介して前記アプリケーション・
    プログラム（１８、６１、６２、８１）に前記新規デー
    タを転送する前に、前記ユーザ端末（１３、６０）内で
    前記新規データをローカルで検証するステップを含む、
    請求項２３に記載の方法。