JP2005506595A

JP2005506595A - プラットフォーム独立の分散ユーザインタフェースのシステムアーキテクチャ

Info

Publication number: JP2005506595A
Application number: JP2002564734A
Authority: JP
Inventors: マンスール，ピーター，エム．; シュヴィッタース，チャッド，アーサー
Original assignee: スプロキットテクノロジーズ，インク．
Priority date: 2002-01-08
Filing date: 2002-01-08
Publication date: 2005-03-03

Abstract

分散ユーザインタフェース（ＵＩ）システムは、サーバベースアプリケーションのためのＵＩをレンダリングするように構成されたクライアントデバイスを含む。クライアントデバイスは、インターネットのようなネットワークを通じてＵＩサーバと通信する。ＵＩサーバは、ＵＩのためのフォーマットを実行し、クライアントデバイスでローカルに利用可能な複数のネイティブＵＩコントロールを利用するのが望ましい。このようにして、クライアントデバイスは、ＵＩの実際のレンダリングに対して受け持ち責務のみを担えばよい。ソースデータ項目は必要な時にＵＩサーバからクライアントデバイスにダウンロードされ、クライアントデバイスはダウンロードされたソースデータ項目でＵＩを埋める。クライアントデバイスはキャッシュを使用して、検索を容易にするためにローカルにソースデータ項目を記憶する。
【選択図】図１

Description

【技術分野】
【０００１】
関連出願の相互参照
本願に対する関連する出願は、"Platform-Independent Distributed User Interface Server Architecture"という名称で２００１年２月１４日に出願された米国特許出願番号第０９／７８２，８４５号、および"Platform-Independent Distributed User Interface Client Architecture"という名称で２００１年２月１４日に出願された米国特許出願番号第０９／７８３，６７３号である。
【０００２】
発明の分野
本発明は、包括的には、クライアント−サーバ型データ通信システムに関する。より詳細には、本発明は、ネイティブなクライアントユーザインタフェース機能を利用して、サーバから受信したデータを表示するシステムに関する。
【背景技術】
【０００３】
発明の背景
インターネットおよび無線データネットワークを介してデータサービスを受けるユーザの数は急速なペースで増大し続けている。例えば、数百万人が従来型の方法でインターネットにアクセスし、多くの人々はウェブ対応無線電話機を使用している。さらに、ますます多くの人々がハンドヘルドコンピュータまたは携帯情報端末（ＰＤＡ）を所有し、その多くはインターネットへの従来型接続および／または無線接続を確立することが可能である。
【０００４】
この急激な技術的拡大の核心には、データ対応インターネット機器がある。こうしたデバイスには、次のような広範囲の形態要素（フォームファクタ）が含まれる：ウェブ対応電話機、多機能電話機、ＰＤＡ、携帯ゲーム機及び他のデバイス。元来これらのデバイスは小型で、携帯性があり、手頃な価格であり、パーソナル情報マネージャ（ＰＩＭ）のデータや電子メールのような貴重なデータ、ならびにゲーム、音楽、およびストリーミングビデオのような娯楽への即時アクセスを提供する。携帯コンピューティングデバイス（ＨＣＤ）と無線ネットワーク接続との組合せはエンドユーザにとって極めて魅力的であり、ＨＣＤがかつて持っていたよりも相当に高い価値のものを提供する。この変化に伴い、携帯性、即時起動、および長いバッテリ寿命のような長期的利益がはるかに大切になる。ラップトップコンピュータを持ち運びそれが起動するのを待つという不便さのない安定的接続の魅力は明らかである。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
無線接続されたＨＣＤに関しては、以下の有利な用途が想起される：電子メールへのアクセス、インターネットへのアクセス、カレンダおよびスケジューラへのアクセス、ならびに同僚とのコラボレーション。残念ながら、ほとんどのＨＣＤは当初はパーソナルコンピュータの付属機器またはスタンドアロン型のデータバンクとして機能するように設計された。直接ネットワーク接続に重点を置くように状況を移行させることにより、これらのデバイスは、ネットワークへのそれらのインタフェースをパーソナルコンピュータが提供していた時にそれらがもともと持っていたレベルの処理機能を喪失している。歴史的には、リモートデータアクセスの問題を解決するためには２つのアプローチがある：（１）ユーザデバイス（「ファット（肥大）」（“ｆａｔ”）クライアント）が小型コンピュータとして機能するというクライアント側処理、および（２）サーバ側処理と連係して動作するシンクライアント（ｔｈｉｎ（やせた）ｃｌｉｅｎｔ）。
【０００６】
無線接続デバイスの認知された価値を維持するのに十分な機能を提供するため、一部のソリューションプロバイダは、より多くの機能をデバイスに提供するという旧来アプローチをとることにより、ファットクライアントデバイスを作り出している。例えば、一部のプロバイダは、自社のプラットフォームやアプリケーションにソフトウェアや機能を付加して、エンドユーザが自分の電子メールサーバに直接接続し、ウェブページを閲覧し、ストリーミングメディアファイルのダウンロードおよび再生を行うことができるようにしている。その結果として、市場の最も広い部門に位置づけられる製品を作り出す努力がなされている。しかし、実際的な技術要求により、ベンダはしばしば、ますます多くのリソースをクライアントデバイスに付加するよう余儀なくされる。より高速なプロセッサおよび付加メモリがデバイスのコストを上昇させるだけでなく、付加の電力要求は、より大きいバッテリを必要とし、デバイスのサイズおよび重量の両方に不利になる。
【０００７】
エンドユーザにとっての実用性を決める３つのパラメータは、携帯性、経済性、および価値である。ファットクライアントデバイスは、付加的機能から利益を受けるものの、通常は携帯性、経済性、製品の実用性、および主流の採用の減少を被る。さらに、このようなファットクライアントデバイスにより実際に与えられる機能を詳細に見ると、さらなる制限が明らかになる。例えば、このようなデバイスは通常、単純なＰＯＰ３およびＩＭＡＰ４電子メールアカウントにはアクセスすることができるが、電子メールやＰＩＭデータにアクセスするために集合的もしくは企業体のファイアウォールとかネゴシエートしたりプロプライエタリサーバ（例えば、ＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅやＬｏｔｕｓＤｏｍｉｎｏ）と通信したりするほど十分には高機能でないことがある。結果として、集合的もしくは企業体のエンドユーザは、自分の無線ＨＣＤのために別個の電子メールアカウントを維持しなければならず、集合的もしくは企業体サーバのＰＩＭデータにアクセスすることができなくなる。
【０００８】
シンクライアントアーキテクチャは、次の３つの典型的なカテゴリに分けることができる：ウェブインタフェース、仮想マシン、およびシンクライアント。この３つのうち、ステートレスなウェブインタフェースのカテゴリは、無線通信事業者および電話機製造業者の間でのＷＡＰ(wireless application protocol)の人気の上昇とともに、最も注目を集めていると思われる。しかし、フォーマットがＷＡＰ、ＨＴＭＬ(hypertext markup language)、または他のいかなるＸＭＬ(extensible markup language)から派生したものであっても、基本概念は変わらない。すなわち、ステートレスなブラウザベースのユーザインタフェースを用いて、アプリケーション機能の１００％およびフォーマット作業の一部を処理するサーバベースアプリケーションとやり取りすることである。その結果（少なくともＷＡＰブラウザのインプリメンテーションもしくは実現については）、広範囲の安価なローエンドデバイスに適合するのに十分な、小型で簡易なクライアントが得られる。この方向に進むことにより、携帯性および経済性は解決されるが、価値は強力なサーバベースアプリケーションから引き出される。しかし、この種のアーキテクチャは、エンドユーザに多少の一部の実用性を提供するものの、ＷＡＰ電話機およびその他のＷＡＰ対応デバイスはしばしばユーザインタフェースの観点からは制限される。
【０００９】
インターネットの広範囲の普及とともに、いわゆる「ウェブベースアプリケーション」が非常に広まっている。人気のあるサイト（いくつかの例として、Ｈｏｔｍａｉｌ、Ｙａｈｏｏ！Ｍａｉｌ、Ｙａｈｏｏ！Ｃａｌｅｎｄａｒ、およびＭｉｃｒｏｓｏｆｔＩｎｖｅｓｔｏｒがあげられる）は、以前はクライアント側ソフトウェアとしてしか利用可能でなかった種類のアプリケーションへのウェブインタフェースをユーザに提供する。あるレベルでは、「アプリケーション」という用語は正確であると思われるが、旧来のクライアント側アプリケーションとウェブベースアプリケーションの使用モデルはかなり異なる。クライアント側モデルとは異なり、ウェブベースアプリケーションは、ステートレスかつ非インタラクティブである。例えば、エンドユーザのマウスのクリック、メニューの選択、または更新のいずれもが、サーバへの再接続と、ウェブページのリフレッシュを要求する。最も高速なインターネット接続を通じてでさえ、ウェブベースアプリケーション上でのユーザ経験は、クライアント側アプリケーションの持続的でインタラクティブな性質に比べると困難なものである。このアプローチのもう１つの欠点は、ウェブベースの電子メールアプリケーションは、そのユーザがさらに別の電子メールアドレスを管理することを要求することである。これらのアプローチは、デスクトップアプリケーションの真の意味では、すなわちサービスの代わりに個々のソースデータに到達するためのツールとしては、機能し得ない。
【００１０】
一部の既存のソリューションプロバイダは、ユーザがインターネット経由で自分の会社のデータにアクセスすることを可能にするウェブベースのシステムを提供している。しかし、これらのプロバイダは、会社が仮想私設ネットワーク（ＶＰＮ）をその会社のデータセンタとプロバイダのサービスセンタの間に設定することを要求する。これは、もっともらしい企業ソリューションのように思われるかもしれないが、個々のエンドユーザは依然として、ラップトップコンピュータを持ち歩くことに代わる実現可能な代替案なしに取り残される。さらに、多くの企業情報システム（ＩＳ）の専門家は、自分がサポートする人々から機能や要望が発生しないうちは、なかなか新しい技術を採用しない。エンドユーザの要望は、特定の状況を扱わなければ生じるものではなく、こうして、結果的に自己永続的な循環に陥る。
【００１１】
インターネットの普及が本格化し始め、ウェブページの静的でステートレスな性質が明らかになると、Ｊａｖａ、ＡｃｔｉｖｅＸ、およびＤＨＴＭＬ(dynamic hypertext markup language)のような新しい技術が開発された。無線ＨＣＤの人気の増大と、静的ウェブビューの不十分さは再び、ワイヤレス市場における次の開発プラットフォームに関連する競争を促すことになる。
【００１２】
Ｊａｖａアーキテクチャの主要な要素は仮想マシンである。この概念は健全であり、多くの場合にはかなり有効であるが、無線ＨＣＤを考慮する場合に障害となり得るいくつかの制限がある。仮想マシンは、オペレーティングシステム（ＯＳ）とアプリケーションの間に層（レイヤ）を確立する。各仮想マシンは種々のターゲットオペレーティングシステム用にコンパイルされるため、個々のアプリケーションをコンパイルすることを不要にする。アプリケーションが単に仮想マシン層に書き込みを行うだけで、仮想マシン層がＯＳ層向けに翻訳を行う。仮想マシンは、ＯＳ内のＯＳとして機能する。このことから、「仮想」マシンという用語が用いられる。
【００１３】
ＯＳからの分離のレベルは、相当のパフォーマンスオーバーヘッドを伴うものである。仮想マシンは、アプリケーションを直接実行するというよりむしろ、まずアプリケーションを実行してから、そのコマンドを下位ＯＳが理解可能な呼出しにマッピングしなければならない。仮想マシンが実現可能なクロスプラットフォームソリューションであるためには、デバイスの共通項の要求にも応じなければならないため、よりハイエンドなプラットフォームに対するその機能性は制限される。さらに、ほとんどの仮想マシンインプリメンテーションは、ユーザがアプリケーションにアクセスするたびにアプリケーション全体をデバイスにダウンロードし、それにより、遅い又は整合していない、無線接続により長い遅延を引き起こす。
【００１４】
Ｊａｖａへの最初の反応はＡｃｔｉｖｅＸであった。このソリューションは、ある一定の場合には非常に有効であるが、プラットフォーム独立性の欠如がその欠点となり得る。Ｊａｖａに対する最近の反応はＤＨＴＭＬである。これは、ＨＴＭＬと連係してクライアント側スクリプティングを組み込み、プラットフォーム独立性を保持しながら標準ＨＴＭＬよりもはるかにインタラクティブなユーザ経験を提供する。しかし、あるレベルでは、ＤＨＴＭＬは仮想マシンの概念に非常に類似している。ＤＨＴＭＬは、実際の仮想マシンを有するのではなく、Ｊａｖａ仮想マシンが使用するのとほとんど同じようにして、スクリプトおよびコードのスニペットを使用する。この点で、ブラウザは、アプリケーションとＯＳの間の層（レイヤ）として機能するため、仮想マシンと同じ制限の多くを受ける。
【００１５】
本明細書で論じられるいわゆる「シンクライアント」技術のほとんどとは異なり、ＡｃｔｉｖｅＸは、ＯＳおよびプラットフォームを直接に補強的に支援し、（「ウェブベース」ではなく）「ウェブアクセス」アプリケーションに対する強力なソリューションとなっている。しかし、このために、ＡｃｔｉｖｅＸはＯＳ依存およびプロセッサ依存となり、多重のＯＳおよびプロセッサ構成が多く存在するＨＣＤの分野に対しては不適当なソリューションとなる。さらに、ＡｃｔｉｖｅＸは、いくつかの点で、ローカル処理のためにクライアント側ソフトウェアをインストールするというファットクライアントの概念への復帰である。
【００１６】
ネットワーク帯域幅の増大に伴い、もっとも旧式のクライアント−サーバ型アーキテクチャの１つが復活しつつある。会社ＩＳの専門家が急いで所有権の全コストを削減しようとするにつれて、Ｃｉｔｒｉｘ、Ｘ−Ｗｉｎｄｏｗｓ、ＷｉｎｄｏｗｓＴｅｒｍｉｎａｌＳｅｒｖｅｒ、およびＰＣＡｎｙｗｈｅｒｅのようなソリューションの人気が増大している。これらのソリューションはすべて、多重のプラットフォームに移植可能なシンクライアントを使用し、リモートサーバ上で実行中のそれらのアプリケーションの完全なグラフィック表現をユーザに提供する。
【００１７】
この種の構成を使用することにより、会社は、そのすべてのユーザが自分のデスクトップ上にある（ＷｉｎｄｏｗｓＣＥベースのターミナルのような）簡易クライアントを通じて単一のＷｉｎｄｏｗｓ２０００サーバからアプリケーションにアクセスするようなシステムを使用できる。会社にとっての利点は、このシステムによれば多くのユーザが単一の管理ポイントでリソースを共有することが可能になるため、システム全体のサポートが容易になることである。欠点は、集中した障害ポイントを提示することにもなることである。
【００１８】
残念ながら、このモデルは、通信リンクを通じてでは重く非効率的である。あらゆるキーストロークおよびユーザアクションがサーバへ送信され、クライアントに返されなければならず、そうしてはじめてユーザは、それが画面に登録されたのを見ることができる。さらに、この「ウィンドウ」をサーバに提示するためには、大きいビットマップがサーバとクライアントの間で送信され、これは相当の帯域幅を必要とする。
【００１９】
ほとんどの場合、これらの種類のシステムは、高速ローカルエリアネットワーク（ＬＡＮ）環境内に配置されるため、これらの問題点はユーザに悪影響を及ぼさない。しかし、無線ＨＣＤの状況で考えると、整合的でない、低帯域幅のコネクションがあると、ターミナルサーバの配備は実質的に使用不能となる。さらに、これらのターミナルは単にサーバ上で実行中のアプリケーションへのビューを提供するだけであるため、ユーザインタフェースは通常、ＨＣＤの小型の画面サイズには適合しない。
【００２０】
したがって、ターミナルサーバアーキテクチャの価値は、デスクトップＬＡＮ環境では明らかであるが、より小型の無線接続デバイスに良好に釣り合いがとれているものではない。
【課題を解決するための手段】
【００２１】
発明の簡単な要約
本発明の好ましい実施形態は、以下の属性を示すデータ通信アーキテクチャを提供する：クライアント側のリソース要求を削減するための比較的スリムなシンクライアント；持続性ステートを有するインタラクティブなエンドユーザ経験；クライアントプラットフォーム独立性；特定クライアントプラットフォームの能力の補強；および不整合な、低帯域幅のコネクションを通じて良好に機能する能力。本発明による分散ユーザインタフェース（ＵＩ）アーキテクチャは、特定的には、無線ＨＣＤの状況に対処することができる。このアーキテクチャは、サーバ側アプリケーションにアクセスするためにどのプラットフォームが使用されているかにかかわらず、クライアントの常駐ＯＳユーザインタフェースを補強して、デバイスの残りの部分と整合性のあるルックアンドフィールを生成する持続的でインタラクティブなインタフェースを提供する。その結果、ほとんどの「ダム（ｄｕｍｂ）」シンクライアントよりも実際にはサイズが小さいセミダム(semi-dumb)クライアントが得られる。
【００２２】
分散ＵＩアーキテクチャは、ターミナルセッションとして機能するサーバとの持続性ステートのコネクションを維持すなわちエミュレートする。分散アーキテクチャとターミナルサーバアプリケーションとの主な相違は、分散アーキテクチャはサーバとクライアントとの間でデータとその表示方法の簡単な記述（クライアントの能力に基づいてサーバにより決定されるような）とを送信するだけであるという点である。クライアント側ソフトウェアは、ネイティブＧＵＩコントロールを用いて、クライアント上にＵＩ要素を生成し、こうして、それらのコントロールにより提供できる利点を補強する。これは、アプリケーションデータの表示をクライアントデバイスにとってはるかにより適当なものにしながら、送信しなければならない情報の総量を大幅に削減する。
【００２３】
その結果、いずれのキーストロークをも「往復」させることは不要となる。というのは、このような入力をクライアント側のコントロールを用いて生成できるからである。そして、データを、送信される各データパケットの使用をより効率的にするバンドルとして送信できる。さらに、Ｗｉｎｄｏｗｓ／ＷｉｎｄｏｗｓＣＥ，のような多少複雑なプラットフォーム上では、いくつかのコントロールは機能が比較的豊富である。例えば、これらのオペレーティングシステムのリストビューコントロールは、ユーザが、列幅を修正変更し、スクロールバーを用いてリストをスクロールすることを許容する。好ましい実施形態では、分散ＵＩアーキテクチャは、ＵＩをデータから分離し、こうして、クライアントは、サーバからの支援を必要とせずにこれらの機能を利用することができる。
【００２４】
本発明の以上および他の側面を、一形態では、クライアント−サーバ型アーキテクチャに関連付けて実施されるデータ処理方法により実現できる。この方法は、クライアントデバイスがそのＵＩ能力をＵＩサーバに記述することを含み、ＵＩサーバは、受信したＵＩ能力に基づいて、ＵＩ要素をどのように構成するかを決定する。ＵＩサーバは、ＵＩフォーム定義をクライアントデバイスに提供し、クライアントデバイスは、そのフォーム定義に従ってＵＩをレンダリングし、ＵＩサーバから受信したデータ項目でＵＩを埋める。
【００２５】
本発明のより完全な理解は、詳細な説明および特許請求の範囲を添付図面と併せて考慮して参照することにより得られる。図中、同一の参照番号は図面全体を通して類似の要素を指す。
【発明を実施するための最良の形態】
【００２６】
望ましい実施形態の詳細な説明
本明細書において、本発明は、機能ブロックコンポーネントおよび種々の処理ステップによって説明できる。このような機能ブロックは、特定化された機能を実行するように構成された任意の数のハードウェアコンポーネントによって実現できることを了解すべきものである。例えば、本発明は、１つ以上のマイクロプロセッサまたは他の制御デバイスの制御下でさまざまな機能を実行可能な種々の集積回路コンポーネント、例えばメモリ要素、ディジタル信号処理要素、論理要素、ルックアップテーブル等を使用できる。さらに、当業者に明らかなように、本発明は、任意の数のデータ伝送プロトコル、サーバベースのエンドユーザアプリケーション、およびクライアントデバイスに関連付けて実施できるものであり、本明細書に記載されるシステムは本発明の１つの例示的適用例に過ぎない。
【００２７】
本明細書に記載され図面に図示される所定のインプリメンテーションもしくは実現は本発明の例示であり、その最良の実施形態であって、それ以外の点ではいかなる意味においても本発明の範囲を限定するべきものでないと了解すべきものである。実際、簡単のため、データ処理、データ伝送、シグナリング、ネットワーク制御等のシステムの機能面（およびシステムの個々の動作側面コンポーネント）のための従来の技法は、本明細書では詳細には説明しないことがある。さらに、種々の添付図面に図示される連結線は、種々の要素間の例示的な機能関係および／または物理的結合を表すべきものである。具体的実施形態では、多くの代替的または付加的機能関係または物理的コネクションが存在してもよいことが留意されるべきである。
【実施例】
【００２８】
システムの概要
本発明の技法は、ネットワークデータ通信システムと関連付けて実行されることが望ましい。したがって、図１は、本発明の技法が実施できる分散ユーザインタフェース（ＵＩ）システム１００の概略図である。システム１００は、少なくとも１つのサーバデバイス（またはシステム）から任意の数のリモートエンドユーザのクラアイントデバイスへ情報、データ、制御コマンド等を転送するように適切に構成される。システム１００は、任意の数の相異なる通信システム、サービスプロバイダ、およびエンドユーザデバイスと協働するそのフレキシブルな性質および能力を反映するように一般化された方法で図示されている。本明細書の説明は、電子メールデータ、ＰＩＭデータ、ならびにカレンダ、ノート、タスク、および連絡先リストのような「オフィス管理」データの処理および提示に重点を置いているが、本発明の技法はそのようには限定されない。実際、本明細書で説明される概念は、静止画像、プレーンテキスト、スタイル付き組版、ワードプロセッサ文書、スプレッドシート、ディジタルメディア等、データ通信ネットワーク経由で伝送可能な任意の他の種類の情報を含む（これには限定されない）いかなる適当なデータフォーマットの処理、転送、および／または提示にも等価的にも適用可能である。
【００２９】
システム１００は、少なくとも１つのＵＩサーバ１０８と通信する任意の数のクライアント提示デバイス１０２、１０４、１０６を含む。典型的な配置構成において、ＵＩサーバ１０８は、デスクトップ型または他のパーソナルコンピュータシステムとして実現される。このような配置構成では、個々のエンドユーザが、ＵＩサーバ１０８およびそれぞれのクライアントデバイス１０２、１０４、１０６を維持する。代替的に、ＵＩサーバ１０８は、より大規模な企業ネットワーク環境における任意の数のスケーラブルなコンポーネントとして実現可能である。この点で、スケーラブルな企業ソリューションは、いくつかのネットワークベースのエンドユーザアプリケーションを実行しながら、並行して任意の数の相異なるエンドユーザおよび任意の数の相異なるクライアントデバイスプラットフォームを同時にサポートするように構成されてもよい。さらに別の配置構成では、単一のエンドユーザが単一のクライアントデバイスで、相異なるサービス、アプリケーション等を表す複数の相異なるＵＩサーバと通信してもよい。例えば、１つのクライアントデバイスが、デスクトップＵＩサーバ、サービスプロバイダにより維持されるＵＩサーバ、娯楽サービスにより維持されるＵＩサーバ等によりサポートされてもよい。説明を簡単かつ簡潔にするため、以下ではデスクトップＵＩサーバ１０８のみについて詳細に説明する。しかし、デスクトップサーバの機能および概念は、スケーラブルな、またはネットワークベースのサーバとの関連でも等価的に適用可能であるため、システム１００で利用されるサーバハードウェアデバイスの実際の数は、システムの特定の要件および／または仕様に応じて異なっていてよい。
【００３０】
本明細書で使用する表現として、「クライアントデバイス」または「提示デバイス」とは、分散ＵＩシステム１００のエンドユーザに情報を提供することが可能な任意のデバイスまたはデバイスの組合せである。例えば、クライアントデバイス１０２、１０４、１０６は、パーソナルコンピュータ、テレビジョンモニタ、インターネット対応コンソール、無線電話機、携帯情報端末（ＰＤＡ）、家庭電化製品、自動車内のコンポーネント、ビデオゲームコンソール等であってよい。クライアントデバイスは、種々の既知のオペレーティングシステム（ＯＳ）を使用しながら、任意の数の従来のプラットフォームに従って構成できる。例えばクライアントデバイスは、ＰａｌｍＯＳが動作するＨａｎｄｓｐｒｉｎｇＶｉｓｏｒ、ＷｉｎｄｏｗｓＣＥＯＳが動作するＰｏｃｋｅｔＰＣ、Ｗｉｎｄｏｗｓ２０００ＯＳが動作するラップトップコンピュータ、ＯＥＭ供給のカスタムＯＳが動作する多機能電話機、またはＷｉｎｄＲｉｖｅｒのｐＳｏｓのような市販のＲＴＯＳで構築された特殊データデバイスであり得る。実際には、システム１００は、無線クライアントデバイスとともに使用するのに特に適している。というのは、システム１００は、現在の広域無線ネットワークに固有の帯域幅制限および不整合なコネクションを、既存の代替手段よりもはるかに良好に処理することができるからである。図１は、クライアントデバイス１０４を、無線デバイスまたはシステムとして図示している。
【００３１】
好ましい実施形態によれば、クライアントデバイスは、ネットワーク１１０、例えばローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、インターネット等を経由してＵＩサーバ１０８と通信する。図１には示していないが、ネットワーク１１０は、任意の数の協働する無線および／または有線ネットワーク要素、例えばスイッチ、ルータ、ハブ、無線ベースステーション、ゲートウェイ等を含んでよい。本発明は、ネットワーク１１０を利用することは必ずしも必要でないことを了解すべきである。例えば、任意の数のクライアントデバイスがＵＩサーバ１０８に（直接に、または無線方式で）接続可能である。好ましい実施形態では、ネットワーク１１０はインターネットであり、個々のクライアントデバイスはそれぞれ、従来のアプリケーションプログラムおよび従来のデータ通信プロトコルを用いてインターネットとのコネクティビティを確立するように構成される。例えば、各クライアントデバイスは、インターネットサービスプロバイダ（ＩＳＰ）（図１には図示せず）経由でインターネットに接続されるように構成できる。
【００３２】
具体的実施形態では、クライアントデバイス１０２、１０４、１０６およびＵＩサーバ１０８は、種々の通信リンク１１２、１１４を通してネットワーク１１０に接続される。本明細書で用いられる表現として「通信リンク」とは、通信の媒体すなわちチャネルとともに、そのリンクを通じてコミュニケーションを実行するために用いられるプロトコルをも指す。一般に、通信リンクとしては、電話線、モデム接続、インターネット接続、サービス総合ディジタル網（ＩＳＤＮ）接続、非同期転送モード（ＡＴＭ）接続、フレームリレー接続、イーサネット接続、ギガビットイーサネット接続、ファイバチャネル接続、同軸接続、光ファイバ接続、衛星接続（例えばDigital Satellite Service）、無線接続、無線周波数（ＲＦ）接続、電磁リンク、双方向ページング接続、およびそれらの組合せがあり得るが、これらには限定されない。
【００３３】
通信リンク１１２、１１４は、所与のクライアントデバイスに関連する特定の通信技術および／またはデータ伝送プロトコルに従って適切に構成できる。例えば、通信リンク１１２、１１４はブロードバンドデータ伝送技法および／またはＴＣＰ／ＩＰプロトコル一式を利用するが、このリンクは、ＮｅｔＢＩＯＳ、ＮｅｔＢＥＵＩ、ＤＬＣ(data link control)、ＡｐｐｌｅＴａｌｋ、またはそれらの組合せを使用することも可能であるのが望ましい。通信リンク１１２、１１４は、インフラストラクチャに応じて、連続的な通信およびデータ更新用に、または断続的通信用に確立できる。
【００３４】
ＵＩサーバ１０８は１つ以上のデータソースまたはデータサーバ１１６を含み、および／またはそれと通信するのが望ましい。データソースまたはデータサーバ１１６は、従来の技法に従って構成できる。本明細書で用いられる表現として、データサーバ１１６は、クライアントデバイスのユーザに転送できるソースデータ項目を管理する。具体的な分散ＵＩシステム１００では、データサーバ１１６は、クライアントデバイスとの間での電子メール、文書、ＰＩＭデータ、および／または他のいかなる種類のデータの転送をも管理できる。例えば、データサーバ１１６は、ＵＩサーバ１０８と同じコンピュータ上のＭｉｃｒｏｓｏｆｔＯｕｔｌｏｏｋの「．ｐｓｔ」ファイルのようなローカルなパーソナルストレージとして、またはＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅＳｅｒｖｅｒ、ＬｏｔｕｓＤｏｍｉｎｏＳｅｒｖｅｒ、ＰＯＰ３サーバ、ＩＭＡＰサーバ等として実現できる。所与のデータサーバ１１６は、ＵＩサーバ１０８に統合されてもよく、ＵＩサーバ１０８に関連するサーバサイトで維持される別個のコンポーネントであってもよく、またはＵＩサーバ１０８の維持を担当するエンティティとは無関係の第三者によって維持されてもよい。したがって、データサーバ１１６は、直接通信リンク１１８を通じて、および／または間接通信リンク１２０を用いてネットワーク１１０経由で、ＵＩサーバ１０８と通信するように構成できる。
【００３５】
「サーバ」は、データの管理、処理、検索、および／または転送に関連する任意の数の機能およびオペレーションを、特にネットワーク環境で実行するように構成されたコンピューティングデバイスまたはシステムとしてしばしば定義される。あるいは、「サーバ」は、このようなプロセス、方法、および／または技法を実行するソフトウェアを指すこともある。本明細書で用いられる表現として、「ＵＩサーバ」とは、クライアントデバイスによりアクセスされるいくつかのサーバベースのアプリケーションを実行する一方で、クライアント側ＵＩのためにデータを処理しフォーマットを定義するコンピューティングアーキテクチャを包括的に指す。ほとんどの市販の汎用サーバと同様、実際のＵＩサーバは、ＵＮＩＸ、ＬＩＮＵＸ、ＡＰＰＬＥＭＡＣＩＮＴＯＳＨＯＳ、またはＭＩＣＲＯＳＯＦＴＷＩＮＤＯＷＳの任意の変形のような、いかなる適当なオペレーティングシステム上で動作するようにも構成可能であり、また任意の数のマイクロプロセッサデバイス、例えばＩＮＴＥＬによるＰＥＮＴＩＵＭファミリのプロセッサやＡＤＶＡＮＣＥＤＭＩＣＲＯＤＥＶＩＣＥＳ、ＩＢＭ、ＳＵＮＭＩＣＲＯＳＹＳＴＥＭＳ、またはＭＯＴＯＲＯＬＡから市販されているプロセッサデバイスを使用可能である。
【００３６】
サーバプロセッサは、システムメモリ（例えば、適当な量のランダムアクセスメモリ）、および適当な量のストレージすなわち「永久」メモリと通信する。永久メモリとしては、１つまたは複数のハードディスク、フロッピーディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、磁気テープ、リムーバブルメディア、ソリッドステートメモリデバイス、またはそれらの組合せがあり得る。公知の技法に従って、オペレーティングシステムプログラムおよびサーバアプリケーションプログラムは固定メモリに常駐し、動作中はその一部がシステムメモリにロードできる。コンピュータプログラミングの当業者の実務に従って、本発明は、ＵＩサーバ１０８またはクライアントデバイスにより実行可能なオペレーションのシンボリックな表現に関して以下では説明される。このようなオペレーションは、コンピュータ実行(computer-executed)オペレーションと呼ばれることもある。認識されるように、シンボリックに表現されたオペレーションとしては、種々のマイクロプロセッサデバイスによるシステムメモリ内のメモリ位置におけるデータビットを表す電気信号の操作、および他の信号の処理がある。データビットが維持されるメモリ位置は、そのデータビットに対応する特定の電気、磁気、光、または有機特性を有する物理位置である。
【００３７】
ソフトウェアで実現される場合、本発明の種々の要素（これはクライアントデバイスに常駐することも、あるいはＵＩサーバ１０８に常駐することもあり得る）は本質的に、種々のタスクを実行するコードセグメントである。プログラムすなわちコードセグメントは、プロセッサ可読媒体に記憶され、または伝送媒体すなわち通信パス上の搬送波に具現化されたコンピュータデータ信号により伝送されることが可能である。「プロセッサ可読媒体」または「機械可読媒体」は、情報の記憶または転送が可能ないかなる媒体をも含んでよい。プロセッサ可読媒体の例としては、電子回路、半導体メモリデバイス、ＲＯＭ、フラッシュメモリ、消去可能ＲＯＭ（ＥＲＯＭ）、フロッピーディスケット、ＣＤ−ＲＯＭ、光ディスク、ハードディスク、光ファイバ媒体、無線周波数（ＲＦ）リンク等がある。コンピュータデータ信号は、電子ネットワークチャネル、光ファイバ、無線、電磁パス、またはＲＦリンクのような伝送媒体を通じて伝搬可能ないかなる信号をも含んでよい。コードセグメントは、インターネット、イントラネット、ＬＡＮ等のようなコンピュータネットワーク経由でダウンロード可能である。
【００３８】
図２は、本発明による分散ＵＩシステム２００の典型的インプリメンテーションもしくは実現の高レベル概略図である。図２に示すように、適当なデータサーバ２０２は（データサーバ１１６に関して上記で説明したように）、ソースデータ項目を、１つまたは複数のサーバベースアプリケーションに関連するアプリケーション層２０４に転送する。具体的なインプリメンテーションもしくは実現では、ソースデータ項目の特性は、特定のアプリケーションによって規定できる。例えば、ソースデータ項目は、テキストメッセージ、電子メールアドレス、連絡先リスト、ｔｏ−ｄｏ項目、面会の約束、ディジタルメディアクリップ、任意のフォーマットのファイル、すなわちビットマップ、ワードプロセッサ文書、スプレッドシート文書またはパーソナルコンピュータによって普通に表示される他のいかなるタイプのデータをも表すことができる。
【００３９】
アプリケーション層２０４は、ソースデータ項目を処理し、ＵＩサーバ２０６と通信する。ＵＩサーバ２０６は同じコンピュータまたは異なるコンピュータのいずれにあってもよい。上記のように、ＵＩサーバ２０６は、サーバベースアプリケーションと協働して、ＵＩレイアウト、生データ処理、およびデータの通信をＵＩサーバ２０６に任せながら、ＵＩレンダリングの大部分がクライアントデバイスによって実行されるようにする。この点で、ＵＩサーバ２０６は、クライアントデバイス２０８と通信する結果として、「仮想アプリケーションクライアント」デバイス２０８となる。以下でさらに詳細に説明するように、クライアントデバイスは、キャッシュされた情報を利用してアプリケーションファサード(application facade)を生成する。クライアントプラットフォームは、他の任意のアプリケーションと同じ方法でこのアプリケーションファサードを解釈し処理する。その結果、ターミナルサーバソリューションに関連する価値およびコンピューティングパワーの大部分を有しながら、ファットクライアントと同様のエンドユーザの経験が得られる。
【００４０】
電子メールアプリケーションの例
例示のため、本発明の技法は、本明細書では、既存のデスクトップ電子メールアプリケーションとの関連で説明される。もちろん、分散ＵＩシステムは、任意の数の代替的および／または付加的アプリケーションをサポートし得る（そして実際にサポートするのが望ましい）。図３は、デスクトップ電子メールアプリケーションに関連するＵＩ３００の例の図示である。本発明の要件ではないが、ＵＩ３００は、標準的な、または市販のアプリケーションによって利用されるＵＩコンポーネント、コントロール、アイコン、およびフィーチャを利用してもよい。例えば、ＵＩ３００は、ＭｉｃｒｏｓｏｆｔのＯｕｔｌｏｏｋ、ＭｉｃｒｏｓｏｆｔのＯｕｔｌｏｏｋＥｘｐｒｅｓｓ、ＮｏｖｅｌｌのＧｒｏｕｐＷｉｓｅ等の例であってもよい。
【００４１】
ＵＩ３００の全体的外観はいくつかの個別のＵＩコントロール要素からなるのが望ましい。本明細書で用いられる表現として、「ＵＩコントロール」または「コントロール要素」とは、クライアントデバイスＯＳによって提供されるＵＩのユニットオブジェクト（すなわち、ネイティブＵＩコントロール）またはクライアントデバイスに常駐する他の何らかのアプリケーションによって提供されるＵＩのユニットオブジェクトを指す。また、分散ＵＩシステムは、ある特定のサーバベースアプリケーションに固有の、および／またはある特定のクライアントプラットフォームに固有の「カスタム」ＵＩコントロールを使用してもよい。アプリケーションは、これらの提供されるコントロールを補強することによって、過度のコーディングおよび処理を避けることができる。コントロールによって、クライアントエンドユーザは、データの表示、入力、修正変更、操作、および／または閲覧、ならびにアプリケーションによる実行のためのコマンドおよびアクションの起動を行うことができる。実際のシステムでは、各クライアントプラットフォームは、ネイティブＵＩコントロール（例えばボタン、スクロールバー、編集フィーチャ、メニュー、リストボックス、リストビュー、単一行編集領域、複数行編集領域、ラベル、および画像ツール）の固有のリストを有し得る。例えば、ＵＩ３００は、メニューコントロール行３０２、ボタンコントロール行３０４、ツリービューコントロール３０６、リストビューコントロール３０８、およびテキスト編集コントロール３１０を含む。
【００４２】
分散ＵＩシステムは、システムによって処理される相異なるタイプのアプリケーションＵＩを表すＵＩフォームを使用する。本明細書で用いられる場合、「ＵＩフォーム」は、任意の所与の瞬間におけるクライアントデバイスディスプレイのレイアウトの記述である。ＵＩフォーム定義はコントロールのリスト、クライアントデバイス表示画面上にレンダリングされるコントロールのそれぞれの位置、イベントスクリプト、データソース、およびおそらくはその他の特性を指定する。ＵＩフォームは、ＵＩコントロールによって表示されるべきユーザのデータを含まないが、所与のコントロールがどこでソースデータ項目を検索できるか（例えば、クライアントデバイスにおけるメモリ位置へのポインタ）、および／またはある特定のコントロールの起動に応答してどのイベントスクリプトが実行されるかを指定できるのが望ましい。実際のシステムでは、ＵＩサーバは、特定のクライアントデバイスプラットフォームと、クライアントデバイスによってアクセスされるサーバベースアプリケーションの特定のスクリーンショットとに対応する相異なるＵＩフォーム定義のリストを維持する。さらに、クライアントデバイスは、これらのＵＩフォーム定義のキャッシュされたコピーをセーブしてもよい（ＵＩサーバは、ＵＩフォーム定義をクライアントデバイスに必要に応じて送信するのがのぞましい）。
【００４３】
図４は、図３に示したＵＩ３００に関連するリストビューコントロール４００の例示である。リストビューコントロール４００は、電子メールアプリケーションに関連するいくつかのリスト化されたエントリ（例えば電子メールメッセージ）をリスト表示することができる。リストビューコントロールは、公知のターミナルサーバのインプリメンテーションもしくは実現の場合のようにＵＩサーバに完全に頼るよりむしろ、クライアント側のデータ操作のために補強できるいくつかの高度な機能を有する。このような機能としては、列のサイズ修正変更およびスクロールバー４０２を用いたスクロールの能力がある。従来のデスクトップまたはＬＡＮ環境では、エンドユーザは単に、スクロールバーを操作してリストを閲覧することができるだけである。これに対して、分散ＵＩシステムは、クライアントデバイスにおいて制限された数のリストを維持するように適切に構成される。エンドユーザがある一定のしきい値を超えて上または下にスクロールする時にクライアントデバイスはＵＩサーバから付加リストを要求するので、帯域幅およびクライアントメモリスペースを保つ。この「仮想」データ方式は、リストビューデータだけでなくそれ以外にも適用可能である。例えば、この機能は、いかなるタイプのデータ、例えばテキスト、ビットマップ等を操作するためにも利用できる。
【００４４】
図５は、図３に示したＵＩ３００に関連するテキスト編集コントロール５００の例示である。（図５は、種々のラベルコントロール（From、To、およびSubject）ならびにラベル付きフィールドに関連する「不可視」テキスト編集コントロールも含む；これらのコントロールは、テキスト編集コントロール５００の上方の「ヘッダ」領域に位置する）。テキスト編集コントロール５００は、エンドユーザが新規電子メールを作成し、または受信電子メールを閲覧する間に、生成および／または操作できる。テキスト編集コントロール５００は、テキスト折り返しを収容するために複数行編集（ＭＬＥ）機能を利用してもよい。実際には、テキスト編集コントロールは、テキストメッセージの一部のみを表示する一方で、他の部分はクライアントキャッシュメモリまたはＵＩサーバに常駐してもよい。エンドユーザ操作が付加的テキストの表示を要求する場合、テキストメッセージの付加的部分をクライアントキャッシュから検索でき、またはＵＩサーバから要求できる。新規電子メールメッセージが完了すると、テキスト編集コントロール５００の内容はセーブされ、その後のＵＩサーバへの送信のため処理できる（後述）。
【００４５】
上記のように、個々のボタンコントロール、メニューコントロール、およびツリービューコントロールは、ＵＩ３００の全体的外観にも寄与し、この外観はそれぞれのクライアントデバイスによってレンダリングされる。もちろん、クライアントデバイスのサイズおよびデバイス能力に応じて、特定のＵＩを、より簡略かつより容易に小型ディスプレイ上でレンダリングできる。簡単に述べれば、はじめてコネクションが所与のクライアントデバイスからＵＩサーバへ形成された時に、ディスプレイ情報（これはたった数バイトのみでもよい）がクライアントデバイスに送信され、フォーム定義としてキャッシュされる。その後、ＵＩはそのフォーム定義に基づいて生成される。重要な点として、コントロールはレイアウト内に配置されるが、フォーム定義はラベルまたはアイコンを含む必要がない。例えば、図６は、電子メールアプリケーションに関連する不完全すなわち「スケルトゥル」“ｓｋｅｌｅｔａｌ”ＵＩ６００の例示である。ユーザは通常動作中にスケルトゥルＵＩ６００を経験することはないが、クライアントデバイスは、相異なるＵＩコンポーネントを別々のメモリ位置に保持することによってそれらを区別するのが望ましい。これにより、個々の要素が別々に更新されることが可能となり、サーバ側での修正変更の場合のデータ転送が最小化される。一旦、種々のコントロールがＵＩ６００を形成するように位置付けると、アイコン、ラベル、およびメニュー項目は別個のキャッシュから一体化されることが可能であり、実際のソースデータ項目（例えば、メッセージリストの内容およびテキスト編集フィールド）が欠けただけの中間的ＵＩが生じる。
【００４６】
上記のように、クライアントデバイスによって生成される電子メールＵＩはアプリケーションファサード（ａｐｐｐｌｉｃａｔｉｏｎｆａｃａｄｅ）であるとみなすことが可能であり、コントロールは単純なデータ操作のために使用可能であるが、このＵＩは実際には電子メールクライアントではない。実際の電子メールアプリケーションはサーバベースであり、ＵＩサーバによって実行され、ソースデータ項目のみ（そしてほとんどの場合、クライアントＵＩによってサポートされる現在のビューを満たすのに十分なだけの）がＵＩフォームに送信される。これにより、分散ＵＩシステムは、完全にインタラクティブで一定ステートの経験を提供し、しかもＰＰＴＰまたはＩＰｓｅｃのような仮想私設ネットワークを通じて、ＭＡＰＩを用いたデータサーバへの直接コネクティビティのような豊富な機能性を提供することができる。
【００４７】
さらに、大きいメッセージや添付ファイルを開くことがはるかに簡単になる。その理由は、添付ファイルは実際にはＵＩサーバ上で開かれており、どの時点においても、単一ページビュー（およびおそらくはある程度の付加的なキャッシュされたデータ）をクライアントに送信するだけでよいからである。これに対して、従来の無線ＰＤＡ（例えば、ＰａｌｍデバイスやＢｌａｃｋｂｅｒｒｙデバイス）は添付ファイルを開くことができず、無線ＷｉｎｄｏｗｓＣＥデバイスは、開く前に添付ファイル全体をダウンロードしなければならない（そしてユーザは、仮にその文書タイプがサポートされていると仮定しても、文書変換による書式喪失のリスクを負う）。クライアントデバイスにより提示されるビューは、添付ファイルタイプおよび／またはデバイス能力に応じて、編集可能であることも、読み出し専用のこともあり得る。
【００４８】
望ましい実施形態では、クライアントデバイスは、相異なるコントロールに対応するイベントスクリプトを利用する。例えば、ユーザがＩｎｂｏｘビューから「新規メッセージ作成(Compose New Message)」を選択した場合、そのボタンに関連付けられたイベントスクリプトがクライアントデバイスによって実行されることになり、「新規メッセージ(New Message)」フォームが表示できる。同様に、ユーザが「送信(Send)」ボタンを操作すると、アプリケーションはＩｎｂｏｘビューに自動的に復帰し、作成されたデータを解析および処理のためにＵＩサーバへ送信できる。イベントスクリプトの主な利点は、それにより一部のオペレーションがクライアント／サーバ通信遅延なしに素早く実行できることである。これは例えば、クライアントデバイスが無線圏外にある場合には顕著になり得る。したがって、イベントスクリプトは、ある程度のオフライン機能を可能にしながら、オンライン動作を迅速化することができる。
【００４９】
上記の例は、分散ＵＩシステムの利点の一部を、特に従来のターミナルサーバアーキテクチャとの比較において例示している。とりわけ、データはその最も純粋なコンポーネントに圧縮されることが可能であり、データの本質的部分のみを送信すればよく、ＵＩはクライアントデバイスプラットフォームに適しており、クライアントは各アプリケーションをサポートするように特別に構成される必要はない。例えば、典型的なファットクライアント環境では、添付されたワードプロセッサ文書付きの電子メールを開く場合、電子メールサーバと通信するクライアント側電子メールアプリケーションとともに、ワードプロセッサ文書を開いて表示することができるクライアント側アプリケーションが要求される。しかし、分散ＵＩシステムを使用することにより、データは、（サーバのＵＩを使用するターミナルサーバとは異なり）クライアントデバイスによりそのネイティブＵＩでレンダリングするためにＵＩサーバ上で変換される。そしてクライアントデバイスは、そのデータをＵＩコンポーネントとマージして、持続ステートインタラクティブインタフェースに持続性のステートを提供することになる。その結果として、付加的ソフトウェアをクライアントデバイスにインストールすることを必要とせずに、付加的機能性（例えば、異なるファイルタイプを開く能力）をＵＩサーバに付加することができる。
【００５０】
さらに、従来の状況では、ワードプロセッサ文書ファイル全体がクライアントデバイスにダウンロードされて変換されなければならないものである。しばしば整合していない、および／または低帯域幅の無線接続を通じてでは、長いファイルのダウンロードは失敗する可能性が高い。上記のように、文書がダウンロードされた後でさえ、クライアントデバイスの変換はしばしばフォーマットエラーにつながる。分散ＵＩシステムでは、クライアントデバイスは比較的少量のデータを表示し記憶するだけであり、ユーザが閲覧するために下方にスクロールする時に、より多くのデータがＵＩサーバからダウンロードされる。その結果、従来のように初期的にダウンロードで失敗しやすいということがなく、巨大なローカルストレージを要求せず、しかも変換ロスなしに、同じ添付ファイルを素早く開くことができる。
【００５１】
本発明の１つの側面で、クライアントデバイスは、ファイル全体を持たずにデータを「チャンク」すなわち少量ずつ編集するように適切に構成できる。したがって、文書の残りの部分がＵＩサーバに保持され、および／または文書の他の部分がダウンロードされている間に、文書の一部が編集のためにクライアントデバイスにダウンロードできる。エンドユーザの視点からは、文書またはデータ項目の全体がクライアントデバイスに常駐するように見えるようになる。この機能によれば、適当なサーバベースアプリケーションと協働して、データの編集部分すなわちチャンクが更新のためにＵＩサーバに返送されることも可能となる。
【００５２】
結局、分散ＵＩシステムは、ファットクライアントの経験の柔軟性を、そのようなシステムのリソース要求なしに提供する。クライアントデバイスは、現在のファットクライアントデバイスよりも多くの機能を有しながら、より小型で、より低い処理パワー、より少ないメモリ、およびより長いバッテリ寿命を有することが可能である。
【００５３】
汎用システムアーキテクチャ
図７は、分散ＵＩシステムの例のサーバおよびクライアントコンポーネントの概略図である。上記のように、図７に示す要素は、ソフトウェアプログラム、ソフトウェアプログラムモジュール、機能コンポーネント、処理タスクまたはスレッド、メモリ要素、アプリケーションプログラムコードセグメント等を表す。実際のシステムでは、図７に示すサーバ側要素は、ＵＩサーバに常駐するＵＩサーバ処理アーキテクチャ７０２に含まれる一方、図７に示すクライアント側要素は、それぞれのクライアントデバイスに常駐するクライアント処理アーキテクチャ７０４に含まれる。これらの処理アーキテクチャのそれぞれは、１つまたは複数のプロセッサデバイスおよび任意の数のメモリデバイス（図７には図示せず）で実現できる。図２４は、分散ＵＩシステムの代替概略図である。図７および図２４は同じ実用システムに適用可能である。
【００５４】
簡単に述べれば、ＵＩサーバ処理アーキテクチャ７０２は、いくつかのサーバベースアプリケーション７１０および第１の通信インタフェース要素７１２と通信するＵＩサーバアプリケーション７０８を含む。ＵＩサーバアプリケーション７０８は、サーバ送信要素７１４、サーバ受信要素７１６、ＵＩフォームデータベース要素７１７、シャドウキャッシュ要素７１８、およびデバイス能力記憶要素７２０を含むか、またはその他の方法でそれらに関連付けられる。サーバベースアプリケーション７１０は、１つまたは複数のデータソースモジュール７２２（これはまた任意の数のデータサーバと通信する）と通信できる。また、ＵＩサーバ処理アーキテクチャ７０２は、デスクトップアプリケーションランチャ（これはアプリケーション７１０の別のインスタンスとして実現できる）をサポートしてもよく、このデスクトップアプリケーションランチャは、エンドユーザが利用可能な１つまたは複数のデスクトップアプリケーション７２６と通信する。
【００５５】
クライアント処理アーキテクチャ７０４は、第２の通信インタフェース要素７３０と通信するクライアントアプリケーション７２８を含む。第１および第２の通信インタフェース要素７１２、７３０は、相互に通信し、ソースデータ項目、制御コマンド、アクション要求、およびクライアントデバイスとＵＩサーバの間で送信できるその他のコマンドの送受信を容易にするように適切に構成される（ＵＩサーバおよびクライアントデバイスは、情報の実際の送信、受信、および交換を実行するために任意の数の公知の技法を利用可能であることが認識されるべきである；図７に示す実際の実施形態では通信インタフェース要素７１２、７３０が使用される）。クライアントアプリケーション７２８は、クライアント送信要素７３６、クライアント受信要素７３８、クライアントＵＩモジュール７４０、および１つまたは複数のクライアントデータキャッシュ７４２を含むか、またはその他の方法でそれらに関連付けられる。また、クライアントアプリケーション７２８は、ＯＳ依存コード７３２およびいくつかのＯＳアプリケーションプログラムインタフェース（ＡＰＩ）７３４と協働して機能する。これらのＯＳ関連要素は、メモリ割当てＡＰＩ、スレッド作成ＡＰＩ、プロセス間通信ＡＰＩ、ＵＩコントロールからメッセージを検索するためのメカニズム等を表すものである。クライアントアプリケーションモジュールを、ＯＳ依存コード７３２およびＯＳＡＰＩ７３４から分離することにより、クライアントアーキテクチャは異なる既存のクライアントデバイスプラットフォームに容易に移植できる。
【００５６】
図７は、ネットワークを通じての双方向通信をサポートする接続モードにおけるＵＩサーバおよびクライアントデバイスを図示している。このような接続モードは各通信セッション中に利用されるが、ＵＩサーバおよびクライアントデバイスはオフラインで独立かつ個別に動作できる。言い換えれば永続的すなわち連続的セッションがＵＩサーバとクライアントデバイスの間に維持される必要はない。この例の目的上、ＵＩサーバおよびクライアントデバイスは、ファイアウォール７０６を避けるように適切に接続される。例えば、実施形態では、ＵＩサーバはポート８０（ウェブブラウザポート）経由でクライアントデバイスと通信するのが望ましい。無線実施形態では、２つの通信インタフェース要素はＨＴＴＰ以外の適当なプロトコルを利用するのが望ましい。ＨＴＴＰは分散ＵＩシステムの目的では面倒であり特に効率的ではないおそれがある。例えば、通信インタフェース要素は、以下の特性を有するプライベートプロトコルを使用できる：ＨＴＭＬより小さい記述のオーバーヘッド；ウェブページに関連するすべてのデータではなく要求されたソースデータ項目のみを送信する能力；および対話性の付加を容易にする多数のコマンドのリストをサポートする能力。もちろん、ある一定の配置構成（例えばデスクトップネットワーク構成）は、ＨＴＴＰを利用できる。
【００５７】
実際には、通信インタフェース７１２、７３０は、クライアントデバイスおよびＵＩサーバに常駐する適当な（ダイナミックリンクライブラリ（ＤＬＬ）のような）実行可能プログラムモジュールにより提供されるとよい。コミュニケーションＤＬＬは、クライアントデバイスとＵＩサーバの間の通信を管理する種々の機能を含むがそれには限定されない。例えば、コミュニケーションＤＬＬは、データ圧縮、暗号化、ポート選択、任意のポインタの自己関連付け、ワードサイズおよびバイト順序の管理（ＵＩサーバがクライアントのためにこれらを処理してもよい）、ならびにソケット管理を実行できる。サーバ側コミュニケーションＤＬＬは、通信セッションを確立するために、あるポート、例えば標準のＨＴＴＰポート８０を選択し、クライアントと連絡をとる（またはクライアントをリッスンする）方法を決定する。サーバ側コミュニケーションＤＬＬは、コネクションの切断をそれぞれのサーバベースアプリケーション７１０に報告するが、ＤＬＬがクライアントデバイスへの再接続に対して責務を引き続き担う。他の構成では、クライアントデバイスがＵＩサーバへの接続を行うことができる。
【００５８】
ＵＩサーバのアーキテクチャ
上記で簡単に述べたように、ＵＩサーバはＵＩサーバ処理アーキテクチャ７０２を使用する。処理アーキテクチャ７０２は任意の数のサーバベースアプリケーション７１０を含み得る。サーバベースアプリケーション７１０は好ましくはＵＩサーバアプリケーション７０８により駆動される（実際のインプリメンテーションもしくは実現では、ＵＩサーバアプリケーション７０８は単一の実行可能ファイル、すなわちドライバアプリケーションとして働く単一の「．ｅｘｅ」として実現される）。ＵＩサーバアプリケーション７０８は、通信インタフェース要素７１２との間で情報を通信する「コーラー」として機能し得る。簡単に述べれば、ＵＩサーバアプリケーション７０８は、それ以外のサーバ通信インタフェース要素７１２またはサーバベースアプリケーション７１０によっては処理されないサーバ側のタスクおよびプロセスを実行する。例えば、ＵＩサーバアプリケーション７０８は、以下のタスクのいずれを実行することも可能である：コネクションを確立するために通信インタフェース要素７１２を呼び出す；接続、再接続、および複数のクライアントを管理する；どのサーバベースアプリケーションがインストールされており利用可能であるかをモニタする；サーバベースアプリケーション間の切り替えを行う；サーバベースアプリケーションをロードしそれにメッセージをディスパッチする；ならびにいくつかの共通機能フィーチャ、例えばフォーム定義の作成、フォント幅の計算等を提供する。とりわけ、ＵＩサーバアプリケーション７０８は、複数のアプリケーションに共通のその他の機能も含み得る。例えば、デバイス能力情報およびアプリケーション登録機能を含み得る。
【００５９】
ＵＩサーバアプリケーション７０８のメインループは、サーバ受信要素７１６経由でクライアントデバイスから入力を取得し、現在のサーバベースアプリケーションに関連する適当な処理ルーチンへコマンドをディスパッチする（具体的実施形態では、サーバベースアプリケーション７１０はいくつかの標準ディスパッチエントリポイントを有するＤＬＬを登録することになる）。すると、現在のアプリケーション７１０は、通信インタフェース要素７１２に関連するＡＰＩを呼び出して、データをデバイスへ送信することができる。データの送信はサーバ送信要素７１４によって実行される（したがって、スレッド化システム上のＵＩサーバアプリケーション７０８は、「送信」キューのためのグローバルデータ、サーバ送信要素７１４をウェイクアップする方法、およびサーバ送信要素７１４に割込みをかけるためのフラグを有するのが望ましい）。動作中、ＵＩサーバアプリケーション７０８は、クライアントデバイスへ送信すべきデータ項目、コマンド、およびその他の情報のリストを含む「送信」キューを維持する。
【００６０】
システムが機能するための要件ではないが、実際の実施形態は、ＵＩサーバアプリケーション７０８において少なくとも２つのスレッド、例えばサーバ送信スレッドおよびサーバ受信スレッドを利用するのが望ましい。特にＵＩサーバが情報をクライアントデバイスへの「チャンク」として処理し送信するという方法を考慮すると、個々のオペレーションを容易にキャンセルできることを保証するために、送信スレッドと受信スレッドを分離するのが望ましい。したがって、サーバ送信スレッドは、サーバ受信スレッド（これは独立にクライアントからコマンド、入力、および情報を収集する）から取得される取り消しおよびステート変化を処理することができる。ただし、このコードを非スレッド化モジュールとして実現することも可能である。このような実現は、スケーラブルなサーバ環境では望ましいことがある。
【００６１】
サーバベースアプリケーション７１０は、任意の数の相異なるアプリケーション、フィーチャ、または機能、例えば電子メールアプリケーション、カレンダアプリケーション、アドレス帳すなわち連絡先リスト、チャットアプリケーション、タスクリマインダリスト、アラームフィーチャ、メッセージングサービス、またはデスクトップ（もしくはその他の）コンピュータ上で実行可能な他のいかなるアプリケーションをも表すことができる。これらのアプリケーションは主としてＵＩサーバに常駐し、ＵＩサーバは、クライアントデバイスに代わってアプリケーション処理の全部ではないにしてもほとんどを処理する。現在のＵＩステートおよびユーザにより選択されたアクションに基づいてどのようなＵＩ修正変更を行うかをクライアントデバイスに通知すること以外では、ＵＩサーバの仕事は基本的にはリモートデータソースとなることである。この種のデータソースと典型的なデータソースの主な相違点は単に、クライアントがデータの名称、タイプ、またはソースを知る必要がないことである。ＵＩサーバは、ＵＩサーバがフォーム定義内のコントロール記述と関連付けているデータＩＤに基づいて、クライアントのためにデータの取得およびフォーマットを行うことに責務を持つ。とりわけ、ＵＩサーバは、任意の所与のサーバベースアプリケーション７１０のために、複数のデータソースと通信しそれをサポートするように構成できる。例えば、ＰＩＭアプリケーションは、いくつかの相異なるデータソース、例えばＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅ、ＳｔａｒｆｉｓｈＯｒｇａｎｉｚｅｒ、ＮｏｖｅｌｌＣｏｍｍｕｎｉｃａｔｏｒ等を利用する可能性がある。よって、各サーバベースアプリケーション７１０は、アプリケーションごとのデータソースモジュール７２２へのインタフェースを含むことが望ましい。データソースモジュール７２２は、どのデータソースが使用されているかに応じて取り替え可能である。
【００６２】
可能な一実現例によれば、ＵＩサーバアプリケーション７０８は、いくつかのアプリケーションサイズのＤＬＬを有するステートマシンとして実現できる。したがって、各サーバベースアプリケーション７１０は、実際にはアプリケーションモジュールの組合せとして実現されるが、クライアントデバイスのユーザにとっては別個のアプリケーションのように見えることになる。これらの各ＤＬＬは、所与のフォームのステートを処理する個別のルーチンを有し得る。ＵＩサーバは、通信障害がサーバ通信インタフェース要素７１２によって報告される時であっても、各サーバベースアプリケーション７１０の現在のステートを維持するのが望ましい。この機能により、分散ＵＩシステムは、クライアントデバイスの接続ステータスにかかわらず持続的に種々のアプリケーションを維持することができる。さらに、ＵＩサーバアプリケーション７０８は、サーバベースアプリケーション７１０を登録するように構成されたＡＰＩを含み、それぞれの個別のアプリケーション７１０は、サーバベースアプリケーション７１０のリストを取得するための別のＡＰＩを呼び出すことができるのが望ましい。このようにして、すべての利用可能な、すなわちサポートされているアプリケーション７１０のリストを、それぞれの個別のアプリケーション７１０により生成されるメニューすなわちコントロール要素（例えば、「移動(GO)」メニュー）内に配置できる。
【００６３】
別の可能なインプリメンテーションもしくは実現では、ＵＩサーバアプリケーション７０８は、ステートマシンとして実現する必要はない。さらに、本発明の要件ではないが、いずれのサーバベースアプリケーション７１０も、個々にステートマシンとして実現できる。このインプリメンテーションもしくは実現では、個々のアプリケーション７１０にはアプリケーションリストが提供されない。むしろ、ＵＩサーバアプリケーション７０８がアプリケーションリストをクライアントデバイスに送信することが可能であり、それによってクライアントデバイスがいずれかのサーバベースアプリケーション７１０内からアクセス可能となる。代替的に、クライアントデバイスは、アプリケーションリストを表示するために設けられた別個のアプリケーションを含んでもよい。
【００６４】
サーバベースアプリケーション７１０は、任意の数のデータソースモジュール７２２と通信し、データソースモジュール７２２がソースデータ項目を１つまたは複数のデータサーバ（図１参照）から取得してもよい。データソースモジュール７２２は、任意の適当な通信プロトコルまたはモデル、例えばＭｉｃｒｏｓｏｆｔＯｕｔｌｏｏｋＯｂｊｅｃｔＭｏｄｅｌ（ＯＯＭ）を利用してデータサーバと通信できる。例えば、複数のデータソースモジュール７２２が、以下のサーバタイプの１つとそれぞれ通信するように（公知の技法に従って）適当に構成できる：ＭｉｃｒｏｓｏｆｔＥｘｃｈａｎｇｅ、ＬｏｔｕｓＮｏｔｅｓ、ＩＭＡＰ、ＰＯＰ３、およびＳＭＴＰ。代替的に、単一のデータソースモジュール７２２がＯＯＭのようなマルチソースＡＰＩを使用して、それらのデータソースのどの１つとも通信することが可能である。ソースデータ項目を取得後、データソースモジュール７２２は、ソースデータ項目を処理するサーバベースアプリケーション７１０のためのインタフェースまたは媒介手段として機能し得る。この点で、サーバベースアプリケーションは、クライアントデバイスにおいて提示および／または編集のためにソースデータ項目を操作するように構成される。
【００６５】
上記で簡単に述べたように、ＵＩサーバ処理アーキテクチャ７０２は、ＵＩフォームデータベース要素７１７を含み、またはそれと通信するのが望ましい。ＵＩフォームデータベース要素７１７は、フォーム、コントロール、レイアウト、パラメータ、および／またはアプリケーションＵＩに関連する特性に関係する情報を記憶するのが望ましい。具体的実施形態では、ＵＩフォームデータベース要素７１７は、ＵＩの処理およびレンダリング中にクライアントデバイスによって利用されるフォーム定義を記憶する。実施形態では、ＵＩコントロール、ＵＩフォーム、およびＵＩ定義は、それぞれのクライアントデバイスのいくつかのデバイス能力に（少なくとも部分的に）基づくのが望ましい。この機能関係は図７に図示されている。図７は、デバイス能力記憶要素７２０に作用的に結合したＵＩフォームデータベース要素７１７を示している。
【００６６】
ＵＩフォーム上の任意の所与のコントロールは、そのコントロールがエンドユーザによって（例えばボタン押下、リストビュー項目のダブルクリック、リストボックス選択を行うこと等により）起動され、操作され、または選択される時に実行すべきコマンドのリスト（すなわちスクリプト）を有することができる。これらの「スクリプティング」コマンドは、ＵＩサーバがクライアントデバイスに送信することができるコマンドの簡単なサブセットであってもよい。これらのコマンドにより、クライアントデバイスは、ＵＩサーバに頼らずにローカルに、共通のアクションを実行することができる。とりわけ、コマンドスクリプトをＵＩサーバによって指定し、適当な時に（例えば、初期化セッション中に）クライアントデバイスに伝送することが可能であり、またはコマンドスクリプトは、対応するＵＩサーバアプリケーションと互換性のある適当なクライアントデバイス・ソフトウェア・アプリケーションにあらかじめロードされることが可能である。こうして、コマンドスクリプトは、クライアントデバイスによって実行されるが、ＵＩサーバに由来してもよい。
【００６７】
ＵＩフォームは、テキストファイルとして、または任意の適当なファイルフォーマットに従って動的または静的に定義できる。サーバベースアプリケーション７１０は、新規なクライアントデバイス構成またはプラットフォームをサポートするためにデフォルトの動的レイアウトジェネレータを含んでもよい。さらに、ＵＩサーバアプリケーション７０８およびアプリケーション７１０を、新規なクライアントプラットフォームとの互換性のために必要に応じて更新できる。前に注記したように、ＵＩサーバアーキテクチャ７０２は、ＵＩの詳細の、全部ではないにしてもほとんどを受け持ち、このことが、クライアントデバイスの処理を簡単化し、システムの更新をより容易にするのが望ましい。
【００６８】
シャドウキャッシュ７１８は、ＵＩサーバにより維持され、ソースデータ項目、ＵＩフォーム情報、およびＵＩサーバからクライアントデバイスに送信されたその他のクライアント関連データのリストを含み得る。また、シャドウキャッシュ７１８は、新規な、または修正変更されたデータ項目、ＵＩフォーム情報、およびクライアントデバイスから受信したその他のクライアント関連データのリストを含んでもよい。こうして、シャドウキャッシュ７１８は、ＵＩサーバからクライアントデバイスへ送信された項目を表すデータおよび／またはクライアントキャッシュにセーブされた項目を表すデータを含むことができる。ＵＩサーバは、シャドウキャッシュ７１８に問い合わせて、クライアントデバイスにキャッシュされているデータを判定すること、およびクライアントデバイスにより入力されたキャッシュされているデータへの修正変更に応答してシャドウキャッシュ７１８を更新することが可能である。シャドウキャッシュ７１８によって、ＵＩサーバが、クライアントキャッシュのステータスをモニタし、クライアントデバイスとの同期化を維持し、ある特定のデータタイプをクライアントデバイスへいつ「プッシュ」するのが適当かを認識し、持続的アプリケーションステートをサポートすることが可能になるとともに、ＵＩサーバアプリケーション７０８が、アプリケーション７１０を繰り返し呼び出すことなく新規な、または修正変更された情報をクライアントデバイスにダウンロードするのを管理することが可能となる。
【００６９】
デバイス能力記憶要素７２０は各サーバベースアプリケーション７１０によってアクセス可能であるのが望ましい。この記憶要素７２０は、それぞれのクライアントデバイスのデバイス能力を記憶する。望ましい実施形態では、ＵＩサーバは初期セッション中に各クライアントデバイスのデバイス能力を取得する。本明細書で用いられる表現として、「デバイス能力」とは、クライアントデバイスの任意のパラメータ、仕様、要件、制限、物理的または機能的特性、識別情報、またはステータス情報を意味する。ＵＩサーバは、１つまたは複数のデバイス能力を利用して、クライアントデバイスのＵＩフォームを定義する。実際のＵＩサーバは、以下のデバイス能力の１つまたは複数を取得し、処理し、記憶できる（以下の例のリストは、本発明の範囲を限定し、またはその他の方法で制約するべきものではない）：
・リッチテキスト、ビットマップ、ＨＴＭＬ、ＷＡＰ、および／またはテキストフォーマットの文書を処理する能力；
・デバイス製造元；
・バージョンまたはリリース識別子；
・デバイスＯＳ；
・ディスプレイ画面寸法（例えば幅および高さ）；
・画面のタイプ（例えばピクセル型かそれともブロック型か）および解像度；
・フォーム領域の寸法（例えば幅および高さ）ならびに位置；
・タスクバーの寸法（例えば幅および高さ）ならびに位置；
・スクロールバーの寸法（例えば幅および高さ）ならびに位置；
・最大受信可能パケットサイズ；
・望ましい、またはデフォルトのフォント；
・利用可能なネイティブコントロールのリスト；
・利用可能なネイティブアイコンのリスト；
・任意のカスタムアイコンの仕様またはフォーマット；ならびに
・クライアントキャッシュサイズ。
【００７０】
デスクトップアプリケーションランチャ
ＵＩサーバ処理アーキテクチャは、デスクトップアプリケーションランチャ７２４も含み得る。デスクトップアプリケーションランチャ７２４は、通常はデスクトップ経由でアクセス可能なアプリケーションまたはプログラムをユーザが起動することを可能にするように適切に構成される。実際のインプリメンテーションもしくは実現では、アプリケーションランチャ７２４は、サーバベースアプリケーション７１０の１つとして実現される。アプリケーションランチャ７２４は種々のデスクトップアプリケーション７２６と通信するのが望ましい。デスクトップアプリケーション７２６はＵＩサーバにより維持（またはアクセス）できる。アプリケーションランチャ７２４は、デスクトップアプリケーションを小さいウィンドウに縮小しようと試み、デスクトップアプリケーションの出力をモニタする。アプリケーションランチャ７２４は、デスクトップアプリケーションからの表示データを分散ＵＩシステムと互換性のあるフォーマットに変換する。こうして、ＵＩサーバは、レンダリングのために、変換されたデータをクライアントデバイスへ動的に送信することができる。アプリケーションランチャ７２４は、どのようなＵＩ要素を描画すべきかをクライアントデバイスに通知し、テキストまたはグラフィック出力をクライアントデバイス上の適当なコントロールへ送信することになる。デバイス上で押下されたボタン（または他のユーザ入力）は、デスクトップアプリケーション７２６内の同一または同等の入力に変換される。
【００７１】
実質的に、アプリケーションランチャ７２４は、所与のデスクトップアプリケーションからの出力をクアライアントデバイスへ送信し、クライアントデバイスからの入力をデスクトップアプリケーションへ送信する媒介手段として機能する。実際には、アプリケーションランチャ７２４は、サーバＯＳと互換性のある適当なメッセージングフォーマット（例えばＷｉｎｄｏｗｓメッセージ）を使用することができる。この点で、分散ＵＩシステムは、ターミナルサーバと同様にも機能するが、帯域幅要求は大幅に削減される。
【００７２】
ＵＩサーバ処理アーキテクチャ７０２は、サードパーティ開発者がより多くのサーバベースアプリケーション７１０を書くことを可能にする第３者のソフトウェア開発者キット（ＳＤＫ）を含んでもよい。ＳＤＫによれば、ＵＩサーバとともに使用するために既存のデスクトップアプリケーションを移植することもより容易になる。
【００７３】
クライアントデバイスのアーキテクチャ
好ましい実施形態では、クライアントアプリケーション７２８は（通信インタフェース要素７３０およびＯＳ依存コード７３２とともに）クライアントデバイス内の読み出し専用メモリに埋め込まれる。実際の配置構成では、所与のクライアントデバイスは必ずしもアップグレード可能でなくてもよい。こうして、クライアントアプリケーション７２８は任意の数のＵＩサーババージョンと互換性があるように設計されるのが望ましい。クライアントアプリケーション７２８はＵＩサーバとの互換性のために特に設計されたクライアントデバイスに常駐してもよいが、クライアントアプリケーション７２８は、多くのデバイスプラットフォーム（おそらくは多くの異なる製造元によって発売された）に移植される可能性が高い。よって、クライアントアプリケーション７２８は、プラットフォーム固有の、および／またはＯＳ依存のコード７３２（例えば、ウィンドウの作成、キャッシュメモリの割当て、ビットマップの表示等に関連するコード）を分離するように構成されるのが望ましい。
【００７４】
複数のスレッドは必須ではないが、例示的実施形態では、クライアントアプリケーション７２８は次の３個の別個の処理スレッドすなわちモジュールを含む：クライアント送信（または応答）スレッド７３６、クライアント受信（またはコマンド）スレッド７３８、およびクライアントＵＩスレッド７４０。クライアント受信スレッド７３８は、コマンド、ソースデータ項目、およびＵＩサーバから来るその他の情報を処理するために設けられる。クライアント受信スレッド７３８は、ＵＩスレッド７４０およびクライアントデータキャッシュ７４２と通信できる。受信スレッド７３８は基本的に、ＵＩサーバからコマンドを受信しながらループしている。受信スレッド７３８は、コマンドに応答して、データをデータキャッシュ７４２に入れてもよく、またはＵＩスレッド７４０がすべき仕事がある時にはＵＩスレッド７４０に通知してもよい。クライアント受信スレッド７３８は、他のクライアント要素に割込みをかけるようにコマンドが要求する場合（例えば、コマンドが、新規のＵＩフォームに切り替えるようにクライアントデバイスに命令する場合）に割込みを行うことが可能である。
【００７５】
ＵＩサーバからのコマンドを受信し処理するため、クライアント受信要素７３８は、完全なコマンドがソケットに到着するのを待機するルーチンを呼び出す（実際のインプリメンテーションもしくは実現では、各コマンドの前に単に１６ビットの長さが置かれる）。コマンドの一部が到着し、残りが適時に到着しない場合、クライアント受信要素７３８は再送要求を開始してもよい。クライアント受信要素７３８は、受信データの復号化および圧縮解除、自己関連ポインタの調整、ならびにデータを適当な構造体内に入れることに責務を持ってもよい。その後、受信要素７３８は、コマンドタイプに基づくスイッチ文に入る。例えば、ほとんどのコマンドは、キャッシュ内のデータを設定もしくは修正変更するか（およびその変化についてＵＩモジュール７４０に知らせる）、または改変を行うこと（例えば、コントロールの移動、新規フォームのロード等）をＵＩモジュール７４０に知らせるかのいずれかである。その結果として、受信要素は、ＵＩサーバによって使用されるすべてのコマンドのフォーマットを理解するとともに、クライアントキャッシュ７４２の詳細を理解するのが望ましい。
【００７６】
別個のＵＩモジュール７４０は、ＵＩフォームの描画、クライアント受信要素７３８に到着したデータの表示、およびユーザによって与えられるコマンドに対する作用のようなＵＩタスクのために専用的に使用するのが望ましい。ＵＩモジュール７４０は、クライアント受信要素７３８からのコマンドおよびクライアントデバイスのエンドユーザ操作によって発生されるコマンドを待機する。また、ＵＩモジュール７４０は、クライアントデータキャッシュ７４２をも理解するので、ＵＩモジュール７４０が受信要素７３８によってＵＩディスプレイを更新するように命令された時にその更新を行うことができる。例えば、ＵＩモジュール７４０が、データキャッシュ７４２内にない何らかのデータ項目を必要とする場合、クライアント送信要素７３６経由でそのようなデータを要求することになる（しかし、受信要素７３８によってそれを表示するよう通知されるまではその表示を行わない）。ＵＩモジュール７４０は、ユーザアクションに応答して、「スクリプト」コマンドのキャッシュされたテーブルを調べ、クライアントデバイスがどのようなアクションをとるべきかを決定してもよい。データは、クライアントデバイスがより多くの情報を要求した時にどのフォームがアクティブであったかを指定するトークン等の適当な識別子を含んでもよい（ユーザは、付加的データを待機している間に異なるフォームに切り替えている可能性がある）。このようなトークンは、データとともにＵＩサーバによって提供されることが可能である。クライアントデバイスは、そのトークンをトランスペアレントでない識別子(opaque identifier)のように処理し得る。
【００７７】
クライアント送信要素７３６は、ＵＩサーバへデータを送信するために設けられる。好ましい実施形態では、クライアント送信要素７３６は、クライアントデバイスが損失データパケットを容易に再送することができるように、ＵＩモジュール７４０から分離される。送信要素７３６は主として、ＵＩモジュール７４０による要求に応じて情報をＵＩサーバへ送信することになる。送信要素７３６は受信要素７３８と協働して、送信された要求が妥当な時間内に確実に受信の肯定応答されるようにしてもよい。もし受信の肯定応答されなければ、要求は再送されることが可能である。好ましい実施形態では、サーバ受信の肯定応答は、ＵＩサーバへ送信されるすべての情報についてモニタされる。これにより、クライアントデバイスは、サーバが受信していないデータを追跡することができる。同様に、ＵＩサーバがクライアントの要求に応答してマルチパート返信を送信する場合、ＵＩサーバは最終パートとともに応答受信の肯定応答を送信するのが望ましい。
【００７８】
送信要素７３６は、ＵＩモジュール７４０からデータを取得し、それをソケットデータに（または、現在のデータ通信方式と互換性のある任意の適当なデータフォーマットに）変換するルーチンを呼び出すように構成されてもよい。また、送信要素７３６は、コマンド長およびコマンド識別（これに対して、ＵＩサーバによって受信の肯定応答がなされ、クライアントデバイスは、通信が成功したことを告げることができる）を前に付加し、ポインタを自己関連性のあるものにし、データを圧縮し、それを暗号化して、それをＵＩサーバへ送信することも可能である。
【００７９】
クライアントキャッシュ
クライアントデバイスは、データの種々のタイプごとにいくつかのキャッシュを維持する。例えば、クライアントデバイスは、ＵＩフォームまたはＵＩフォーム定義のリストを記憶するのが望ましい。これらは、種々のサーバベースアプリケーションがそれらを共有することができるように名前付けされることが可能である。各ＵＩフォームはキャッシュされたコントロールを有してもよく、各コントロールはキャッシュされたデータを含んでもよい。データは、どのフォームか、フォームのどのインスタンスか（例えば、「メッセージ読み出し(Read Message)」フォームは多数のメッセージ閲覧するために使用可能である）、およびどのコントロールかを指定する。さらに、複数コントロールのうちのあるもの（例えばリストビュー）は、データの配列を含むことができる。本発明はいかなる特定データタイプの処理にも限定されないが、典型的データ項目はテキスト、アイコン、またはビットマップを表すものである。実際の記憶スペースの制限により、クライアントデバイスはある使用期間後にキャッシュメモリを使い果たす可能性がある。その結果、クライアントデバイスは、到来データがＵＩサーバから到着する時にデータキャッシュ７４２から項目を消去しその到来データを収容するように構成されるのが望ましい。
【００８０】
図８は、分散ＵＩシステムによって使用できるクライアントアイコンおよびコントロールデータキャッシュ構造体８００の概略図である。ＵＩコントロールがアプリケーションから分離されることに加えて、フォーム定義においてコントロールにマッピングされるアイコン、メニュー項目、およびラベルもまた別のキャッシュ構造体に保持される。これは２つの理由で行われる。第１に、アプリケーションサービスプロバイダ（ＡＳＰ）または無線通信事業者は、アプリケーションのＵＩレイアウトを変えずに、アプリケーションのルックアンドフィールを変えること、または単一の項目を変えることを選択する可能性がある。ＵＩの個々の特性を分離することは、より多くの柔軟性をＡＳＰに与える。第２の理由は、所定のアイコン（例えば、フォーマットアイコンまたはメニュー項目）は種々のアプリケーションにまたがって繰り返される。別個のキャッシュからそれらを参照することは、冗長性の必要性を減らし、より低いリソース要求を維持する。
【００８１】
実際のメモリストレージ制限により、クライアントキャッシュのサイズはプラットフォームごとに異なり得る。よって、クライアントデバイスアプリケーションは、新規にダウンロードされるデータを収容するために、一部の情報タイプは保護される一方、優先度の低い情報タイプはより簡単に削除されるようにして、階層的にクライアントキャッシュを維持するように構成されるのが望ましい。例えば、キャッシュ構造体８００は、任意の数の論理レベルすなわち区分を含み得る。実際には、それぞれの記憶されるデータ項目は、このようなレベルを表す識別子を含んでもよい。図示した例では、第１レベル８０２は、最低優先度を有する通常のソースデータ項目に関連する。すなわち、これらの項目は、それよりも低いレベルに含まれる他の項目より前に破棄される。第５レベル８１０は、フォームデータまたはフォーム定義に関連する。第５レベル８１０は、最高の相対優先度を有する情報タイプを含む。すなわち、これらの項目は、クライアントデバイスが付加的なキャッシュスペースを必要とする場合に最も破棄されにくい。
【００８２】
例示的実施形態では、ＵＩサーバがはじめてクライアントデバイスに接続すると、コントロールがどのように配置されるべきかについての詳細がキャッシュされ、アプリケーション識別がそれらに関連付けられる。その時点から、サーバにより別段の要求がされなければ、そのアプリケーションファサードはキャッシュされたＵＩフォームデータから構築されることになる。記憶されているＵＩレイアウトに関して必ずしもＵＩサーバに問い合わせる必要はない。さらに、個々のＵＩ要素が実際にダウンロードされる必要はない。代わりに、ＵＩサーバは単に、クライアントデバイスがネイティブＯＳのＧＵＩ要素を使用するように命令する指示をクライアントデバイスに送信することができる。それらのＧＵＩ要素はすでにクライアントプラットフォームＯＳの一部としてクライアント上にある。ネイティブコントロールを補強的に支援することは、パフォーマンスを改善し、よりファットインタラクティブなクライアントのような感じ（ｆｅｅｌ）をリモートアプリケーションに提供する。さらに、このような補強的支援は、全体的なネットワーク帯域幅要求を低下させる。
【００８３】
残りのレベルは、増大した重要度すなわちより高い優先度に対応する：第２レベル８０４はＵＩアイコンに関連し；第３レベル８０６は重要なデータに関連し；および第４レベル８０８は重要なＵＩアイコンに関連する。項目の「重要度」は、ＵＩサーバによって規定されてもよい。重要なデータまたはアイコンとは、ユーザがすぐに使用する可能性が高いもの、またはクライアントデバイスが他のものより頻繁に利用する可能性があるものである。例えば、電子メールメッセージのテキストは、重要であるとラベル付けされる必要はない。というのは、いったん開かれた後は、ユーザがそれを近い将来に再び開く可能性は低いからである。他方、メッセージのリストは重要である。というのは、ユーザは、リストと、リスト内の特定のメッセージとの間で頻繁に切り替えを行う可能性が高いからである。
【００８４】
任意の所与のキャッシュレベル内で、データは、いつそれがクライアントデバイスによって最後に使用されたかに応じて削除される。こうして、最も過去に使用されたもの（「古いほうの」データ）がまず破棄される一方、最も近時に使用されたもの（「新しいほうの」データ）はできるだけ長く保存される。よって、クライアントキャッシュ構造体８００内の既存の項目のすべてが置き換わるとすれば、最も過去に使用された通常の種類のデータが最初に削除される一方、最も近時に使用されたフォームデータは最後に削除されることになる。図８中の矢印は、キャッシュ項目が破棄される順序を表す。
【００８５】
キャッシュ構造体８００に加えて、クライアントデバイスは、コントロール・オブジェクト・マッピング・キャッシュ、イベントキャッシュ、および／または他の論理的に分離されたキャッシュ構造体を維持してもよい。コントロール・オブジェクト・マッピング・キャッシュは、クライアントプラットフォームが分散ＵＩシステムから独立であることを容易にする。アプリケーションがはじめて起動される時（または、変化が生じたことをＵＩサーバがクライアントに通知する時はいつでも）、ＵＩサーバはクライアントデバイスにいくつかのフォーム定義を送信する。これらはアプリケーションファサードを記述するのに役立つ。しかし、どのプラットフォームも相異なるコントロールを有し得るので、コントロール・オブジェクト・マッピング・キャッシュは、どのコントロールが各ＵＩサーバコマンドにマッピングされるかを決定するための「仮想マシン」として働く。各プラットフォームが相異なる制限を有することを理解すると、ＵＩサーバは、クライアントデバイスに基づいてＵＩ記述を変えることが可能であるが、基本的コントロールは依然として仮定できる。この情報は別個のキャッシュに記憶されることにより、プラットフォームの機能性を拡張するために後日にコントロールを付加し、それによってマッピングを変えることができるのが望ましい。コントロール・オブジェクト・マッピング・キャッシュを単に更新することにより、新規なコントロールをプラットフォームに容易に付加することができる。
【００８６】
イベントキャッシュ（これは、ＵＩフォームデータキャッシュの一部であるとみなしてもよい）は、特定のＵＩ要素を１つのイベントまたは１つのアクションにマッピングするために使用される。例えば、電子メールアプリケーションでは、「新規メール作成(Compose New Mail)」ボタンを、ユーザがそのオプションを選択した時に、サーバを何ら参照することなくＵＩが直ちに表示されるように、対応するフォーム定義にマッピングできる。この場合も、これにより複数のアプリケーションが共通のイベントを共有することが可能となるために冗長性が低下し、イベントはＵＩサーバによって必要に応じて更新または付加されることが可能となる。
【００８７】
仮想コントロール
上記のように、クライアントデバイスは任意の数の「仮想」コントロールを含み得る。例えば、比較的大きいデータ（例えばドロップダウンリスト、リストビュー、マルチライン編集コントロール、ピクチャ等）を含むいかなる項目も、ＵＩサーバから小さいチャンクすなわち増分として送信できる。クライアントは、各セグメントをキャッシュし、ユーザがデータをナビゲートする時に必要に応じて付加セグメントを要求することになる。実際には、ＵＩサーバは初期的に完全な長さの識別子またはいくつかのリストビュー項目を送信することができる。その後、クライアントデバイスがデータ管理責任を負い、クライアントキャッシュを満たすために必要な時に項目を要求する。クライアントキャッシュは、ユーザが過度の期間待機することなくＵＩディスプレイをナビゲートすることができるのに十分なデータを含むのが望ましい。
【００８８】
具体的な一実施形態では、クライアントデバイスは、データの全部がクライアントデバイス上に存在するかのように見えながらユーザがデータをナビゲートすることができるように、仮想スクロールバー（または何らかのそのようなコントロール）を維持することができる。こうして、スクロールバーは、別のコントロール要素（例えばリストビュー）と連係してレンダリングされることが可能であるが、「リンクされている」コントロール要素の内容、特性、または表現を修正変更するために構成された顕著なコントロールとして実現できる。この点で、クライアントデバイスによってレンダリングされる仮想ＵＩコントロールは、リモートデータソースに影響を与えるように適切に構成できる。クライアントＵＩモジュール７４０は、要求したデータを待機する必要はない。ユーザは、しばらくの間ビットマップを下へスクロールした後、ルックアヘッドデータがＵＩサーバによって送信されている間に別のフォームに切り替えてもよい。データ項目はＵＩサーバによって修正変更できる。例えば、新しい電子メールが来た時、またはユーザがメッセージを削除した時に、リストビュー項目が挿入および削除できる。
【００８９】
送信／受信／再接続の処理
例示的な一インプリメンテーションもしくは実現によれば、データおよびコマンドの送受信の手続きは、ＵＩサーバとクライアントデバイスで本質的に同じである。それぞれの側がデータパケットの２つのキューを維持する：一方は未送信パケットのリストであり、他方は送信されたが相手側によって受信の肯定応答がなされていないパケットのリストである。接続の確立後、送信要素は「送信」キューにデータがあればそれを見て、その接続を通じてデータパケットを（順に）送信し始める。送信オペレーションの成功後、（例外が存在しないと仮定すると）パケットは「送信済み」キューの末尾に移動される。
【００９０】
その一方で、受信要素は、データが相手側から到着するのを待機している。完全なパケットすなわちコマンドが到着すると、受信要素はパケットヘッダを解析して、現在のパケットが、要求していないパケットであるか、それとも受信の肯定応答を意味するパケットであるかを判定する。例えば、クライアントデバイスは、現在のコマンドがクライアントコマンドの範囲内にあるか、それともサーバコマンドの範囲内にあるかをチェックすることによりこの判定を行うことができる。クライアントコマンドは、現在のパケットが単にサーバからの受信の肯定応答であり、クライアントによって以前に送信された対応するパケットが受信されたことを意味する。現在のパケットが実際に受信の肯定応答パケットである場合、受信要素は「送信済み」キューの先頭を見て、対応するパケットを削除する。そのパケットは今や首尾よく受信されており、もはやモニタする必要がない。
【００９１】
受信パケットが要求していないコマンドである場合、受信側は直ちにそのパケットの応答受信の肯定を行うべきである。受信の肯定応答パケットが生成され、「送信」キューに入れられる。送信要素は、「送信」キューを処理している時にこのパケットを見ると、それを相手側に送信する。しかし、送信後に「送信済み」キューにその受信の肯定応答パケットを移動することはない。
【００９２】
セッションが中断されてから再接続された後の回復のために、それぞれの側は、失われた可能性のあるデータが正しい順序で確実に再送されるようにする責任を負う。このために、それぞれの側はその「送信済み」キュー全体を「送信」キューの先頭に、または「再送」キューに入れる。この再優先順位付けは、相手側によって検証可能な形で受信されていないいかなるデータも正しい順序で送信されることを保証する。この方式は、受信の肯定応答がまだ送信または受信されていない場合に、実際には相手側によって受信されているパケットが再送される可能性があるという問題点を生じる。この問題点は、要求していないコマンドに対する受信の肯定応答をわずかに異なる方法で処理することによって対処することができる。例えば、それぞれの側は、送信した最後の受信の肯定応答パケットのためのプレースホルダを記憶しておくことができる。最後に受信の肯定応答をしたプレースホルダよりも小さいプレースホルダを有する要求をしていない新たなパケットを受信した場合、その要求をしていない新たなパケットは、すでに処理した何かの再送として認識される。こうして、もう一度受信の肯定応答を送信し、その新しいパケットは破棄することができる。
【００９３】
プロセスフローの例
ＵＩサーバおよびクライアントデバイスはそれぞれ、分散ＵＩシステムの動作をサポートするためにいくつかの手続き、プロセス、およびタスクを実行するように構成される。以下で、いくつかの例示的なプロセスフロー状況について詳細に説明する。説明を整合させるため、これらのプロセスフロー状況は、上記の分散ＵＩシステムの要素および機能を参照することもある。とりわけ、分散ＵＩシステムの実際のインプリメンテーションもしくは実現は、いくつかの等価な方法で以下の手続きを具体化することが可能であり、本明細書で説明される特定のプロセスタスク（およびこのようなタスクの実行順序）は、特定の配置構成の要求に適合するように改変、除去、または補足してもよい。
【００９４】
全般的なクライアント−サーバ動作
図９は、本明細書に記載される分散ＵＩシステムによって実行できる分散ＵＩプロセス９００のフローチャートである。プロセス９００が開始されると、クライアントデバイスがＵＩサーバとの接続を確立する（タスク９０２）。クライアントおよびサーバのそれぞれの通信インタフェース要素はこの接続を確立するように機能できる（好ましい実施形態では、接続はインターネットのようなネットワークを通じて確立される）。接続の形成後、プロセス９００は、このセッションが特定クライアントデバイスとＵＩサーバ間の最初の接続に相当するかどうかを判定する（問合せタスク９０４）。ＵＩサーバが、例えば受信したクライアントデバイス識別子を既知の、または先に接続されたクライアントデバイスのテーブルと比較することによって、この判定をしてもよい。現在のセッションがクライアントデバイスとＵＩサーバの間の初期的接続を表している場合、初期化プロセス９０６（以下でさらに詳細に説明する）が促される。他方、現在のセッションがオフライン期間に後続する再接続である場合、同期化プロセス９０８（以下でさらに詳細に説明する）が促される。
【００９５】
クライアントデバイスおよびＵＩサーバの初期化または同期化の後、ユーザは、ＵＩサーバによって維持されている利用可能なアプリケーションのリストからサーバベースアプリケーションを選択することができる（タスク９１０）。ユーザの選択に応答して、ＵＩサーバは、選択されたアプリケーションを実行する（タスク９１２）。これは、クライアントデバイスにおける提示のためにソースデータ項目を操作するように構成されてもよい。その一方で、クライアントデバイスは、選択されたアプリケーションでの使用に適したＵＩフォーム（これは任意の数のＵＩコントロールを含み得る）を生成し表示する（タスク９１４）。この点で、ＵＩは、選択されたアプリケーションの動作と整合するようにエンドユーザに受信ソースデータ項目を提示する。
【００９６】
表示されたＵＩをたどりながら、ユーザは、クライアントデバイスにおいて、ＵＩフォームもしくはＵＩコントロールを操作するか、またはその他の方法でアクションを実行することが可能である（タスク９１６）。例えば、電子メールアプリケーションとの関連では、ユーザは、「新規メッセージ作成(Compose New Message)」要求を開始したり、あるリストビューエントリをダブルクリックしてメッセージを読み出したり、スクロールバーを操作して付加的エントリまたは付加的テキストを閲覧したり、メッセージまたはエントリを削除したり、別のアプリケーションに切り替えたり、メッセージに応答できる。ユーザアクションに応答して、クライアントデバイスは、適当な方法で応動できる（タスク９１８）。例えば、クライアントデバイスは、そのアクションに関連する１つもしくは複数のコマンドスクリプトを実行し、または対応するアクション要求もしくはコマンドを発生し送信してもよい。スクリプトおよびアクション要求は、ＵＩサーバへの情報の送信および／またはＵＩサーバからの情報もしくはソースデータ項目の要求に関連していてもよい。
【００９７】
ＵＩサーバは、クライアントのアクション要求およびコマンドを、どのように応答するのが最良であるかを決定するために適当な方法で受信し処理することができる。例えば、クライアントのコマンドおよび／または要求に応答して、あるいはＵＩサーバにおける新たなデータの存在に応答して、ＵＩサーバは、任意の数のコマンドおよび／またはソースデータ項目をクライアントデバイスに返送してもよい（タスク９２０）。ＵＩサーバからその新しい情報を受信した後、クライアントデバイスは、ＵＩフォームまたはいくつかのＵＩコントロールを更新する（タスク９２２）。特定の更新特性は、ＵＩサーバから受信される情報に左右されるものである。
【００９８】
分散ＵＩプロセス９００は、エンドユーザまたはＵＩサーバがアプリケーションを切り替える（問合せタスク９２４）か、またはＵＩサーバから切断する（問合せタスク９２６）ことに決めるまで、ループし続けてもよい。アプリケーションの切り替えに応答して、タスク９１０が、新しい選択を処理するために再び開始される。さらに、同期化手続き９０８（またはその一部）を、任意の新たに選択されたアプリケーションに対して反復できる。すなわち（このプロセスフローの例示的順序から明らかではないが）、初期同期化手続きは、コネクションのときのすべてのサーバベースアプリケーション、選択されたアプリケーションのみ、または１つ以上のデフォルトアプリケーションを同期化すように構成されてもよい。こうして、コネクションされている間、ユーザは、選択されたサーバベースアプリケーションと継続的に双方向の情報のやり取りをすることができる。
【００９９】
クライアント／サーバの初期化
図１０は、分散ＵＩプロセス９００に関連して実行できる例示的な初期化プロセス９０６のフローチャートである。特定クライアントデバイスとＵＩサーバの間の最初のコネクションに応答して、クライアントは、識別または登録情報をＵＩサーバへ送信できる（タスク１００２）。このような情報は、クライアントデバイスを一意的に識別して、ＵＩサーバがそのサーバベースアプリケーションを各クライアントデバイスごとに持続的ステートに維持できるようにするために役立つ。識別情報としては、限定ではないが、次の項目のいずれを含んでもよい：ユーザ名およびパスワード；デバイスＩＤ；デバイスシリアル番号；またはデバイスタイプ。さらに、クライアントデバイスは、任意の適当なフォーマットを用いて自己のデバイス能力をＵＩサーバへ送信し（タスク１００４）、ＵＩサーバは将来の参照のためにそのデバイス能力をセーブする。
【０１００】
クライアントデバイスまたはエンドユーザは結局、ＵＩサーバからアプリケーションリストを要求してもよい（タスク１００６）。アプリケーションリスト要求は、初期化中に自動的に生成されてもよく、またはエンドユーザのインタラクションを要求してもよい。アプリケーションリストは、クライアントデバイスがアクセス可能なサーバベースアプリケーションを指定する。要求に応答して、ＵＩサーバは、適当なアプリケーションリストをクライアントデバイスへ送信することにより応答する（タスク１００８）。もちろん、ＵＩサーバは、「利用可能なアプリケーションなし(No Applications Available)」メッセージで応答することにより、エンドユーザによる次のアクションを促してもよい。１つまたは複数のアプリケーションが利用可能であると仮定すると、クライアントデバイスは、アプリケーションリストをエンドユーザに対して表示することができる（タスク１０１０）。例えば、実際のクライアントデバイスのインプリメンテーションは、エンドユーザが便利な方法で、任意のアプリケーションからのリストを表示し、利用可能なアプリケーションのいずれかを起動することができるように、クライアントＵＩ上に「開始(Start)」または「移動(Go)」ボタンを提供してもよい。
【０１０１】
クライアント／サーバの同期化
図１１は、分散ＵＩプロセス９００に関連して実行できる例示的なクライアント／サーバ同期化プロセス９０８のフローチャートである。上記のように、クライアントデバイスは、オフラインの間に、すなわちＵＩサーバから切断されている間または接続不良の期間中に、アクションおよびオペレーションを実行することができる。このようなオフラインアクションは、クライアントデバイスにおいて１つまたは複数のソースデータ項目を修正変更または削除することができる。さらに、ＵＩサーバは、クライアントデバイスが切断されている間に既存のソースデータ項目に修正変更、削除、または付加をすることができる。同期化プロセス９００、または適当な等価プロセスは、クライアントデバイスおよびＵＩサーバがそれぞれいかなるオフライン時の変化をも反映するために確実に更新されるように実行できる。
【０１０２】
同期化プロセス９００は、クライアントデバイスがＵＩサーバとのセッションを再確立した後に実行されるのが望ましい。ＵＩサーバと再接続された後、クライアントデバイスは検証のための適当な識別子をＵＩサーバに送信する（タスク１１０２）。ＵＩサーバは、クライアントデバイスを検証した場合、そのクライアントデバイスについてセーブされているアプリケーションステートを検索できる（タスク１１０４）。実際には、ＵＩサーバは、クライアントデバイスが切断されている時はいつでもアプリケーションの現在ステートをセーブしている。この点で、ＵＩサーバは、いかなる個々のサーバベースアプリケーションのステートセーブしてもよく、またはそのクライアントデバイスのすべてのアプリケーションを表すグローバルステートを検索してもよい。
【０１０３】
クライアントデバイスは、オフラインの間に（空き記憶スペースを得るために）クライアントキャッシュから削除された項目のリストを送信できる（タスク１１０６）。それらの項目はクライアントキャッシュから削除されることが可能であり、適当な通知が生成されてクライアント「送信」キューに入れられてもよい。削除された項目のリストは、個々の通知の組合せ、またはすべての削除された項目を識別する単一の通知のいずれでもよい。オフライン期間に後続するこの「バッチ」送信手続きとは異なり、ＵＩサーバに接続されている間は、クライアントキャッシュから削除されたデータ項目は一致適合化のため規則的にＵＩサーバへ送信される。
【０１０４】
その後、ＵＩサーバは、オフライン時のキャッシュ変化があればそれをクライアントデバイスへ送信できる（タスク１１０８）。このようなオフラインキャッシュ変化は、キャッシュされているリストに関連するデータの到来（例えばクライアントデバイスがキャッシュされているメッセージリストを有する場合の新たな電子メールの到着）を表すものである。好ましい実施形態では、ＵＩサーバによって維持されるシャドウキャッシュ（図７参照）が更新されて、クライアントによって削除されたデータ項目があればそれを除去し、ソースデータ項目のクライアントによる修正変更があればそれを反映し、および／またはいずれかのオフラインコマンドの実行に関してＵＩサーバによりなされた付加、削除、もしくは修正変更があればそれを反映する（タスク１１１０）。さらに、クライアントキャッシュは、現在同期化されているステータスを反映するのに必要な範囲で更新される。
【０１０５】
また、クライアントデバイスは、オフラインの間にクライアントデバイスによって生成された１つまたは複数のオフラインのアクションおよび／またはデータを示すいくつかのコマンドを送信してもよい（タスク１１１２）。例えば、オフラインの間にエンドユーザは、オフラインでなければＵＩサーバによって直ちに実行されるアクション要求を生成するかもしれない。このようなアクション要求は、クライアントデバイスがＵＩサーバに再接続されるまで「保留(hold)」状態に置かれる。もう１つの例として、エンドユーザは、クライアントデバイスが切断モードにある間に、新規メッセージの作成または既存のデータの修正変更をするかもしれない。新規データ項目、修正変更されたデータ項目、および関連するコマンドはタスク１１１２の間に送信される。
【０１０６】
結局、クライアントデバイスは利用可能なアプリケーションを選択し、ＵＩサーバは選択されたアプリケーションをロードすることになる（タスク１１１４）。この時に、ＵＩサーバは、現在ロードされているアプリケーションへ、そのアプリケーションによって実行されるための適当なオフラインコマンドおよび要求をディスパッチし得る（タスク１１１６）。オフラインコマンドは、それがクライアントデバイスによって送信された順序で実行されるのが望ましい。タスク１１１６が完了すると、クライアントデバイスの現在のステートは、ＵＩサーバと同期化されるべきである。
【０１０７】
アプリケーションおよびフォームの選択
図１２は、分散ＵＩアーキテクチャによって実行できるアプリケーションおよびフォーム選択プロセス１２００のフローチャートである。プロセス１２００は、特定のサーバベースアプリケーションの選択に応答してクライアントデバイスでの表示のために適当なＵＩフォームを選択する。よって、プロセス１２００が開始されるのは、クライアントデバイスが、利用可能なサーバベースアプリケーションを選択した時である（タスク１２０２）。その選択に応答して、クライアントデバイスは、特定のアプリケーションを識別する選択情報をＵＩサーバへ送信する（タスク１２０４）。その選択に応答して、ＵＩサーバは、そのアプリケーションをロードし実行する（タスク１２０６）。その後、そのアプリケーションは、クライアントデバイスに対して、特定のＵＩフォームを生成するように命令する（タスク１２０８）。具体的実施形態では、ＵＩサーバが、ＵＩフォーム定義または対応する識別子をクライアントデバイスに送信してもよい。ＵＩフォーム定義はクライアントデバイスプラットフォームおよび／または選択されたアプリケーションに特に適合したものでよい（上記のように、ＵＩフォーム定義はクライアントデバイスの複数のデバイス能力に基づくのが望ましい）。この点で、クライアントデバイスが実際にはＵＩをレンダリングするが、ＵＩサーバがどのＵＩフォームを表示すべきかを規定する。特定のＵＩフォームは、選択されたアプリケーションに関連するデフォルトビューであってもよく、またはエンドユーザアクションに基づいてもよい。例えば、電子メールアプリケーションは、電子メールメッセージのリストを有する「Ｉｎｂｏｘ」ＵＩフォームを自動的に要求してもよい。
【０１０８】
ＵＩフォームコマンドに応答して、クライアントデバイスは、要求されたＵＩフォーム定義が利用可能であるかどうかを決定するために、自己のキャッシュに問い合わせてもよい（タスク１２１０）。利用可能でない場合、クライアントデバイスはＵＩサーバからＵＩフォーム定義を要求する（タスク１２１２）。この要求に応答して、ＵＩサーバはＵＩフォーム定義を検索（または生成）し、それを適当なフォーマットでクライアントデバイスに返送する（タスク１２１４）。クライアントデバイスは、ＵＩフォーム定義を受信した後、その定義を自己のキャッシュにセーブする（タスク１２１６）。好ましい実施形態では、クライアントデバイスは、フォーム定義がクライアントキャッシュから最後に削除されるべきデータタイプとなるように、最低キャッシュレベルにすべてのフォーム定義をセーブする（図８およびクライアントキャッシュについての対応する説明を参照のこと）。ＵＩフォームがクライアントキャッシュにローカルに記憶された後、クライアントデバイスは、ＵＩサーバと連絡を取ることを必要とせずにＵＩフォーム定義を検索することができる。
【０１０９】
所与のＵＩフォーム定義がクライアントキャッシュに入った後、クライアントデバイスは、その定義に基づいて対応するＵＩフォームを生成できる（タスク１２１８）。好ましい具体的な実施形態では、クライアントデバイスは、クライアントプラットフォームＯＳに関連するネイティブＵＩコントロールを用いてＵＩフォームを生成する。その後、クライアントデバイスは、ＵＩフォームをレンダリングし、そのＵＩをそれぞれのソースデータ項目で埋めることができる（タスク１２２０）。
【０１１０】
ＵＩフォーム定義がＵＩサーバによって修正変更された場合、プロセス１２００の一部は、クライアントデバイスが常に各ＵＩフォームの最新バージョンを確実に利用するように実行するとよい。この点で、フォーム定義は、クライアントにキャッシュされているフォーム定義のバージョンが最新であるかどうかをＵＩサーバが判定することを可能にする日付および／またはバージョンスタンプを含むとよい。
【０１１１】
クライアントキャッシュのメンテナンス
図１３は、クライアントデバイスがＵＩサーバからデータを受信した時に実行できるクライアントキャッシュメンテナンスプロセス１３００のフローチャートである。この例の目的上、クライアントキャッシュはフルであり、新しいデータをセーブすることができるようにするにはより古いデータが削除または除去しなければならないと仮定する。そうではなく、クライアントキャッシュが十分な容量を有する場合には、データ項目は、キャッシュされている項目の削除を必要とせずに、通常通りセーブされるべきものである。本明細書では、プロセス１３００は、図８に示した例示的なクライアントキャッシュ構造体と整合するように説明される。
【０１１２】
クライアントキャッシュ維持プロセス１３００が開始されるのは、クライアントデバイスがＵＩサーバから新しいもしくは付加のデータ項目を取得し、またはクライアントデバイス自身がクライアントキャッシュに入れるための新しいもしくは付加のデータ項目を生成した時である（タスク１３０２）。クライアントデバイスは、それが受信した順序で、または任意の優先方式に従って、到来するデータ項目を処理するように構成でき、この例の目的上、データ項目は一度に１個ずつ処理される。もちろん、プロセス１３００は、所要の量の記憶スペースが利用可能になってから、新しいデータ項目をチャンク単位でセーブしてもよい。
【０１１３】
スペースを解放するため、プロセス１３００はまず、初期的に最高キャッシュレベルから、キャッシュされているデータ項目を削除する。削除は、図８に関連して説明したように、最も過去に使用されたデータから開始して（タスク１３０４）、そのレベルに関連する最も近時に使用されたデータへと進む。キャッシュされているデータ項目がロックされている場合、クライアントデバイスはそれをキャッシュから除去しようとはしない。データ項目は、表示されているＵＩフォームにそれが含まれている場合、またはクライアントデバイスによってそれが現在修正変更されている最中である場合に、クライアントデバイスによってロックできる。一旦必要量のスペースが利用可能になると、新しいデータ項目が空きキャッシュスペースにセーブされる（タスク１３０６）。（新しいデータ項目が、最近に削除されたキャッシュ項目より多くのメモリを要求する場合には、以下で説明するように付加のキャッシュ項目が反復的に削除されることが必要となり得る。）こうして、到来するデータ項目を収容するために既存のデータソース項目が削除される。
【０１１４】
まだ他の新しいデータ項目が残っている場合（問合せタスク１３０８）、プロセス１３００は続行される。そうでない場合、プロセス１３００はタスク１３１６（後述）に進んでよい。クライアントキャッシュが現在のキャッシュレベルにまだ他の項目を含んでいる場合（問合せタスク１３１０）、そのレベルにおける次の項目が削除される（タスク１３１２）。上記のように、いかなる所与のレベルに関連するキャッシュ項目も、最も過去に使用されたものから最も近時に使用されたものへという順序で削除されるのが望ましい。図１３に示すように、新しい項目のすべてがセーブされるまで、または現在のキャッシュレベルに関連する項目のすべてが削除されるまで、キャッシュ項目が削除されて新しいデータ項目で置き換えられる。
【０１１５】
現在のキャッシュレベルから古い項目のすべてが削除された場合（問合せタスク１３１０）、クライアントデバイスは、次のキャッシュレベルの最も過去に使用された項目を削除する（タスク１３１４）。このプロセスフローは、新しいデータ項目のすべてがクライアントキャッシュにセーブされるまで繰り返される。この点で、既存のキャッシュ項目は、階層的優先方式に従って選択的に削除される。本明細書で説明される実施形態によって利用される優先方式は、ＵＩフォームデータを最も優先し、最低優先度を古いソースデータに割り当てる。この優先方式は、例えばソースデータ、アイコンデータ、フォームデータ等のデータタイプに従って、キャッシュされている項目を選択的に削除する。
【０１１６】
キャッシュの更新に応答して、クライアントデバイスは、クライアント「送信」キューに適当なエントリを生成するのが望ましい（タスク１３１６）。このエントリすなわちコマンドは、除去されたキャッシュ項目のリストを提供することによってＵＩサーバに通知する。その後、ＵＩサーバは、同じ項目を削除することによって、自己のシャドウキャッシュを更新することができる（タスク１３１８）。このようにして、シャドウキャッシュはクライアントキャッシュと整合的な一貫性のある状態に保たれ、ＵＩサーバはクライアントデータ項目の正確な目録を維持する。
【０１１７】
ＵＩサーバの処理
図１４は、ＵＩサーバによって実行できるサーバ起動プロセス１４００のフローチャートである。プロセス１４００は、一般的に、ＵＩサーバが起動され、呼び出され、またはその他の方法で応答することが期待されるいくつかの状況を考慮している。この点で、プロセス１４００が開始されるのは、ＵＩサーバが適当な起動要求を受信した時である（タスク１４０２）。この起動要求は、ＵＩサーバによって内部的に生成されてもよく、クライアントデバイスから受信されてもよく、またはシステム管理者もしくは他の「サードパーティ」エンティティから受信されてもよい。
【０１１８】
起動要求が、新しいサーバベースアプリケーションをＵＩサーバに登録することの要求を表している場合（問合せタスク１４０４）、ＵＩサーバは、そのアプリケーションの名前および実行可能部分（例えば、適当なアプリケーションＤＬＬ）を適当なメモリ位置に記憶できる（タスク１４０６）。その後、ＵＩサーバは、この新しいアプリケーションを、１つ以上のクライアントデバイスにとって利用可能にすることができる。
【０１１９】
起動要求が新しいＵＩフォームをＵＩサーバに登録することの要求を表している場合（問合せタスク１４０８）、ＵＩサーバは、フォーム定義、およびおそらくはフォームの名前または識別子を適当なメモリ位置に記憶できる（タスク１４１０）。新しいフォームは、新しいアプリケーションをサポートするため、または先にサポートされていたアプリケーションのより新しいバージョンをサポートするために定義できる。
【０１２０】
起動要求がクライアントデバイスからの接続要求を表している場合（問合せタスク１４１２）、ＵＩサーバは、クライアントデバイスの識別性を検証しようと試みることになる（タスク１４１４）。クライアントデバイスが認証されたと仮定すると、ＵＩサーバは、同じエンドユーザによって操作されている別のクライアントデバイスに現在接続されているかどうかを判定する（問合せタスク１４１６）。この状況は、単一のエンドユーザが複数のクライアントデバイスを操作し、それらの相異なるデバイスを用いてＵＩサーバに接続する時に起こる。実際のシステムは、同期化の問題を避けるために同時コネクション数を制限してもよい。こうして、ＵＩサーバは、別の関連するクライアントデバイスにすでに接続されている場合、その別のデバイスを切断する前に、その別のデバイスの現在の動作ステートをセーブする（タスク１４１８）。その後、要求するクライアントデバイスは、ＵＩサーバに接続され、それと同期化することが可能となる（タスク１４２０）。
【０１２１】
起動要求がサーバベースアプリケーションからメッセージを送信することの要求を表している場合（問合せタスク１４２２）、ＵＩサーバは、適当な要求またはコマンドをフォーマットし、それをサーバ「送信」キューに入れることが可能である（タスク１４２４）。ＵＩサーバからのデータの送信については、図１５に関連して以下でさらに詳細に説明する。
【０１２２】
起動要求がクライアントデバイスから受信されたメッセージ、コマンド、データ項目、または要求を表している場合（問合せタスク１４２６）、ＵＩサーバは、適当なサーバ受信手続き１４２８を実行できる。適当な手続き１４２８については、図１６に関して以下でさらに詳細に説明する。
【０１２３】
もちろん、ＵＩサーバは、任意の数の起動要求タイプを取得することが可能であり、上記のものは本発明の範囲を限定するべきものでない。この点で、サーバ起動プロセス１４００は、適当な方法で任意の起動要求を処理するように構成できる（タスク１４３０）。
【０１２４】
図１５は、データをクライアントデバイスへ送信する時にＵＩサーバによって実行できるサーバ送信プロセス１５００のフローチャートである。実際には、プロセス１５００は、サーバ送信要素およびサーバ通信インタフェース要素のようなサーバ処理アーキテクチャの種々の要素によって実行できる。データをクライアントデバイスへ送信する準備ができている場合、ＵＩサーバは、処理のためにサーバ「送信」キュー内の次のエントリを検索する（タスク１５０２）。現在のエントリが再送要求を表している場合（問合せタスク１５０４）、ＵＩサーバは、対応するデータをクライアントデバイスへ直ちに送信することができる（タスク１５０６）。その後、再送要求はサーバ「送信済み」キューに移動できる（タスク１５０７）。ＵＩサーバは、サーバシャドウキャッシュがすでにそのデータ項目を含んでいる（そしてそのデータはすでに正しくフォーマットされている）ので、データを素早く再送することができる。
【０１２５】
現在のエントリが再送要求を表していない場合、対応するデータ（またはそれの何らかのレコードまたはそれへのポインタ）がサーバシャドウキャッシュにセーブされる（タスク１５０８）。サーバシャドウキャッシュは、クライアントキャッシュのコピーとして機能する。こうして、ＵＩサーバは規則的にシャドウキャッシュを維持し、シャドウキャッシュはクライアントデバイスにローカルにセーブされているソースデータ項目のリストおよび／またはＵＩサーバからクライアントデバイスへ送信されたデータ項目のリストを含み得る。結局、ＵＩサーバは、クライアントデバイスへの送信のためにデータを処理することになる（タスク１５１０）。実際のＵＩサーバは、データについて適当なコマンドを構築してもよい。このことは、コマンド長、識別子、および送信クッキーまたはトークンを含むことができる（しかしこれらに限定されない）メタ情報データを付加すること；ならびに、報告されたクライアントの能力に応じてデータ暗号化、圧縮、および文字列タイプまたはバイト順序の調整を含む（しかしこれらに限定されない）いくつかの共通のデータ変換を実行することによって行われる。
【０１２６】
データを含むコマンドは、サーバ通信インタフェース要素および通信ネットワークを経由してクライアントへ送信される（タスク１５１２）。送信後、ＵＩサーバはそのコマンド、またはそのコマンドの適当な識別子をサーバ「送信済み」キューに移動する（タスク１５１４）。コマンドは、その受信がクライアントデバイスによって受信の肯定応答されるまでサーバ「送信済み」キューにとどまるのがのぞましい。よって、サーバ送信プロセス１５００は、指定された期間内に受信の肯定応答が受信されたかどうかを鑑定するためにタイマをモニタしてもよい（問合せタスク１５１６）。受信された場合、コマンドはサーバ「送信済み」キューから除去または削除してよい（タスク１５１８）。ＵＩサーバは、割り当てられた制限時間内に受信の肯定応答を受信しない場合、近いうちにクライアントデバイスへ再送できるようにそのコマンドをサーバ「送信」キューに戻してもよい（タスク１５２０）。
【０１２７】
図１６は、到来するメッセージを処理するためにＵＩサーバによって実行できるサーバ受信プロセス１４２８のフローチャートである。プロセス１４２８は、サーバ起動プロセス１４００（図１４参照）に関連して実行できる。よって、プロセス１４２８は、ＵＩサーバがメッセージ、コマンド、または要求をクライアントデバイスから受信した時に開始できる（タスク１６０２）。メッセージがアプリケーションリスト要求を表している場合、ＵＩサーバは、クライアントデバイスに利用可能なサーバベースアプリケーションの現在のリストを検索し、そのリストに対する適当なコマンドを生成し、そのコマンドをクライアントデバイスへ送信するためにサーバ「送信」キューに入れることになる（タスク１６０６）。
【０１２８】
受信されたメッセージは、エンドユーザがある１つのサーバベースアプリケーションから別のサーバベースアプリケーションへの切り替えを決めた時にクライアントデバイスによって生成されるアプリケーション切り替え通知をあらわすことがある。受信メッセージがアプリケーション切り替え通知を表している場合（問合せタスク１６０８）、ＵＩサーバは現在のアプリケーションに、それが切り替えられることになると通知してもよい（タスク１６１０）。この通知により、現在のアプリケーションは、自己のステートを保存し、そして、その他の方法で切り替えの準備をすることができる。ＵＩサーバは結局、新しいアプリケーションを実行のためにロードすることになる（タスク１６１２）。具体的実施形態では、タスク１６１２によりＵＩサーバは適当なアプリケーションＤＬＬをロードする。その後、ＵＩサーバは、新たにロードされたアプリケーションに、現在のアプリケーションとしてのその現在の動作ステータスを通知できる（タスク１６１４）。さらに、前のアプリケーションはアンロードされるか、またはその他の方法でアイドルステートに置かれる（タスク１６１６）。
【０１２９】
受信メッセージがアプリケーションリスト要求でもなければアプリケーション切り替え通知でもない場合、ＵＩサーバは、適当な方法でクライアントメッセージを処理できる（タスク１６１７）。この点で、ＵＩサーバは、任意の数のクライアントメッセージを取得してもよく、上記のものは本発明の範囲を限定すべきものでない。例えば、クライアントメッセージは、コントロールに添付されたスクリプトに従ってクライアントデバイスによって生成されたコマンド、ボタンコントロールが起動されたことの通知、ユーザがリストビューを下方にスクロールすることを可能にするためのさらに多くのデータの要求、または「セーブ(save)」ボタンの起動に関連するデータであることが可能である。その後、ＵＩサーバは、現在のアプリケーションのディスパッチエントリポイントへそのメッセージをディスパッチし得る（タスク１６１８）。このようにして、現在のアプリケーションはメッセージを適切な方法で処理することができる。
【０１３０】
図１７は、データ修正変更を処理するためのプロセスのフローチャートである。この修正変更は、データソースに起因する。データ修正変更プロセス１７００は、外部ソースが１つ以上のアプリケーションに関連するデータの付加、修正変更、または削除をした場合に開始してよい（タスク１７０２）。便宜上、「修正変更されたデータ」とは、新規データ、修正変更されたデータ、または削除されたデータを指す。すなわち、「変更されたデータ」は、任意の所与のアプリケーションのソースデータ項目のステータスにおける任意の変化も表すものである。修正変更されたデータが「プッシュ」データである場合、すなわち、新しい電子メールのように、他から加えられた変化にユーザの注意を向けるのに十分なほど重要であるデータである場合には、たとえユーザがそのタイプのデータを現在調べていなくても（問合せタスク１７０４）、ＵＩサーバはクライアントデバイスへ送信するためにプッシュ通知命令を生成できる（タスク１７０６）。修正変更されたデータが「プッシュ」データでない場合、ＵＩサーバは、修正変更されたデータがクライアントにすでにキャッシュされているデータ項目に関連するかどうかをテストできる（問合せタスク１７０８）。例えば、修正変更されたデータは、キャッシュされたデータ項目の更新されたバージョンであるかもしれない。この点で、ＵＩサーバは、クライアントキャッシュの現在のステータスを判定するために自己のシャドウキャッシュを調べてもよい。修正変更されたデータ項目がクライアントにキャッシュされていない場合、データ修正変更プロセス１７００は終了する（この修正変更されたデータは、クライアントデバイスがそれぞれのアプリケーションを呼び出すまで、またはそのデータ項目が再び修正変更されるまで、ＵＩサーバによって維持されることになる）。
【０１３１】
修正変更されたデータ項目がキャッシュされているデータ項目に関連する場合、または修正変更されたデータ項目が「プッシュ」データタイプである場合、ＵＩサーバは自己のシャドウキャッシュを更新してその修正変更を反映させる（タスク１７１０）。新しいデータが関与する場合、それはシャドウキャッシュに付加される。改変されたデータが関与する場合、前のバージョンが新しいバージョンで置き換えられる。その後、修正変更されたデータ項目（および、該当する場合にはプッシュ通知命令）はフォーマットされ、サーバ「送信」キューに入れられる（タスク１７１２）。結局、ＵＩサーバはそれをクライアントデバイスへ送信することになる（タスク１７１４）。とりわけ、修正変更されたデータがクライアントデバイスに送信されるまでには変動する時間遅延が生じるおそれがある。実際、クライアントデバイスはこの時間中にＵＩサーバから切断されるかもしれない。
【０１３２】
修正変更されたデータ項目がＵＩサーバから受信された後、クライアント受信要素はそのデータ項目をクライアントキャッシュに入れる（タスク１７１６）。好ましい実施形態は、データをクライアントキャッシュにセーブする時に、図１３に関連して上記で説明したプロセスのようなキャッシュ管理アルゴリズムを使用する。クライアント受信要素は、クライアントデバイスが修正変更されたデータを適当な方法で処理することができるようにクライアントＵＩモジュールに警告または注意を与えるようにしてもよい（タスク１７１８）。該当する場合、クライアントＵＩモジュールは、オプショナルなプッシュ通知命令を実行する（タスク１７２０）。このことは、ユーザに「プッシュ」データが到着したことを通知するため使用できる。例えば、ＵＩモジュールはクライアントデバイスにおいて、ポップアップウィンドウを生成して表示し、またはオーディオ音を再生してもよい。
【０１３３】
受信されたデータ項目（またはデータ項目が属する関連リスト）がクライアントデバイスに現在表示されている場合（問合せタスク１７２２）、クライアントデバイスは、修正変更されたデータ項目に収容するために、ＵＩフォームおよびディスプレイの更新を始める（タスク１７２４）。そうでない場合、修正変更されたデータ項目は、それが要求され、削除され、またはさらに修正変更されるまで、クライアントキャッシュに保存できる（タスク１７２６）。
【０１３４】
クライアントデバイスの処理
図１８は、受信データを処理する時にクライアントデバイスによって実行できるクライアント受信プロセス１８００のフローチャートである。プロセス１８００は、クライアントデバイスがメッセージ、要求、またはコマンドをＵＩサーバから受信した時に開始できる。好ましい具体的な実施形態では、クライアントデバイスは、完全なコマンドが受信されるまで到来データを一時バッファに入れる（タスク１８０２）。その後、クライアントデバイスは、バッファ内容に対して、任意の必要なデータ復号化または圧縮解除を実行できる（タスク１８０４）。相異なるコマンドタイプは、クライアントデバイスによって別様に処理できる。その結果として、クライアントデバイスはまずコマンドを解析し、コマンドタイプを判定してもよい（タスク１８０６）。
【０１３５】
コマンドがクライアントアクションコマンドを表している場合（問合せタスク１８０８）、コマンドをさらなる処理のためにクライアントＵＩモジュールに送信できる（タスク１８１０）。これに関連して、クライアントアクションコマンドは、現在のサーバベースアプリケーションに関係したものであってよい。ＵＩサーバは、クライアントデバイスに特定のアクション（例えば、所与のＵＩフォームの表示、ＵＩコントロールの偏差の修正変更、または移動又はコントロールの内容の消去）を実行させることが必要な時、クライアントアクションコマンドを生成することができる。クライアントデバイスは（例えばＵＩモジュール経由で）クライアントアクションコマンドを実行し、必要であればＵＩを更新して、クライアントアクションコマンドの実行の結果として生じる変化があればそれを反映させる。
【０１３６】
コマンドがデータキャッシュコマンド（例えば、ソースデータ項目またはその他のデータオブジェクトを含むコマンド）を表している場合（問合せタスク１８１２）、そのデータは、コマンドによって指定されるようにクライアントキャッシュに記憶される（タスク１８１４）。例えば、コマンドは、データ内容を参照する識別子を指定すること、データタイプを提供すること、およびデータが記憶されるべきキャッシュレベルを指定することが可能である。クライアントキャッシュ内へセーブされると、ＵＩモジュールが適切な方法でそのデータを処理することができるように、そのデータの到着がＵＩモジュールに通知される（タスク１８１６）。
【０１３７】
コマンドが、もともとクライアントデバイスから送信されたデータの受信の肯定応答を表している場合（問合せタスク１８１８）、クライアントデバイスはそれに応答してクライアント「送信済み」キューから対応するエントリを除去する（タスク１８２０）。こうして、クライアントデバイスは、もとのデータ項目の再送の心配をする必要がない。
【０１３８】
コマンドがクライアントアクション、データ項目、または受信の肯定応答以外のものを表している場合、クライアントデバイスは、そのコマンドタイプを認識した場合にはそのコマンドを処理することができる（タスク１８２２）。すなわち、分散ＵＩシステムは、上記の特定のコマンドの処理に限定される必要はない。もちろん、クライアントデバイスが、受信されたコマンド、メッセージ、または要求を認識しない場合には、エラーメッセージを生成するか、または単にそれを無視してもよい。
【０１３９】
図１９は、クライアントデバイスのＵＩモジュールによって実行できるＵＩ要素プロセス１９００のフローチャートである。図１８に関連して上記で説明したように、クライアントデバイスは、コマンド、データ、要求、またはメッセージを現在のＵＩに関連づけて処理するためにＵＩモジュールに送ることが可能である。ＵＩモジュールは、受信要素によって警告された時はいつも、またはユーザがある特定のアクションをＵＩに対して実行した時に、アクティブになる。例えば、ＵＩモジュールがデータ項目を受信した場合（問合せタスク１９０２）、ＵＩモジュールはまず、受信されたデータ項目（またはそれの異なるバージョン）がすでに現在のＵＩフォームに表示されているかどうかをチェックできる（問合せタスク１９０４）。表示されていない場合、受信データ項目はクライアントキャッシュにセーブされ（タスク１９０６）、クライアントデバイスによって呼び出されるか、削除されるか、または修正変更されるまでそこに常駐することになる。
【０１４０】
問合せタスク１９０４で、受信データ項目（またはそれの異なるバージョン）が現在のＵＩフォームに表示されていると判定された場合、ＵＩモジュールは、新しいデータ項目に対するロックをインクリメントまたは起動して、それが使用されている間に削除されることを防止する（タスク１９０８）。受信データ項目が、古い項目を置き換えるべきものである場合、古い項目に対するロックをデクリメントして、その古い項目をキャッシュから除去できるようにする。新たにキャッシュされるデータ項目は、そのそれぞれのキャッシュレベルの終端に移動されて（または適切にマークされて）（図８および対応する説明を参照のこと）、削除を受けにくくされる（タスク１９１０）。結局、受信データ項目は、現在のＵＩフォーム上のそれぞれのＵＩコントロールに表示される（タスク１９１２）。
【０１４１】
ＵＩモジュールがコマンド、例えばクライアントアクションコマンド、サーバコマンド等を受信した場合（問合せタスク１９１４）、ＵＩモジュールはそのコマンドを実行する（タスク１９１６）。これらのＵＩコマンドは、ＵＩフォームを切り替える要求、ＵＩコントロールを移動する要求、およびその他のＵＩ表示機能またはＵＩオペレーションに関係する要求を表せる。
【０１４２】
ＵＩモジュールが、現在のＵＩフォームでのエンドユーザ操作またはインタラクションに応答したコマンド、要求、またはメッセージを受信した場合（問合せタスク１９１８）、ＵＩモジュールは、このようなユーザアクションを、図２１〜図２３に関連して以下でさらに詳細に説明するように処理できる（タスク１９２０）。もちろん、ＵＩ要素プロセス１９００は、ＵＩモジュールが他の機能、コマンド、要求、またはメッセージを処理することができるように適切に修正変更できる（タスク１９２２）。
【０１４３】
図２０は、情報をＵＩサーバへ送信する時にクライアントデバイスによって実行できるクライアント送信プロセス２０００のフローチャートである。クライアント送信要素、クライアント通信インタフェース、およびその他のクライアントデバイス要素は、プロセス２０００を実行するように協働できる。データをＵＩサーバへ送信する準備ができると、クライアントデバイスは、処理のためにクライアント「送信」キュー内の次のエントリを検索する（タスク２００２）。現在のエントリが再送要求を表している場合（問合せタスク２００４）、クライアントデバイスは、どのような付加的なキャッシュ維持手続きを実行することも必要ではなく、対応するデータをＵＩサーバへ直ちに送信することができる（タスク２００６）。
【０１４４】
現在のエントリが再送要求を表していない場合、対応するデータがクライアントキャッシュから一時バッファに転送される（タスク２００８）。これによりクライアントデバイスは、送信されるデータをキャッシュ外に移動し、一箇所でそれをフォーマットすることができる。（代替的に、送信データはキャッシュ内でロックされ、ＵＩサーバから受信の肯定応答を受信するまでクライアントデバイスがそれを破棄しないようにすることができる。）さらに、キャッシュ項目ロックは、その項目がクライアントデバイスによって削除されることを可能にするためにデクリメントまたは解除(deactivate)される（タスク２０１０）。結局、クライアントデバイスは、ＵＩサーバへの送信のためにデータを処理する（タスク２０１２）。サーバ送信プロセス１５００に関連して上記で説明したように、タスク２０１２中に実行される処理は、データに対する適当なコマンドの構築（そのコマンドは、コマンド長、識別子、および送信クッキーまたはトークンを含み得る）、データ暗号化の実行、ならびにデータ圧縮の実行に関係してもよい。
【０１４５】
データを含むコマンドは、クライアント通信インタフェース要素および通信ネットワークを経由してＵＩサーバへ送信される（タスク２０１４）。送信後、クライアントデバイスはそのコマンド、またはそのコマンドの適当な識別子をクライアント「送信済み」キューに移動する（タスク２０１６）。コマンドは、その受信がクライアントデバイスによって受信の肯定応答されるまでサーバ「送信済み」キューにとどまるのが望ましい。例えば、クライアントデバイスが、指定された期間内にＵＩサーバから受信の肯定応答を受信した場合（問合せタスク２０１８）、コマンドはクライアント「送信済み」キューから除去または削除されてよい（タスク２０２０）。クライアントは、割り当てられた制限時間内に受信の肯定応答を受信しない場合、間もなくＵＩサーバへ再送できるようにそのコマンドをクライアント「送信」キューに戻してもよい（タスク２０２２）。
【０１４６】
図２１および図２２は、ＵＩにおけるデータ表示コントロールの操作を処理するためのクライアントプロセス２１００のフローチャートを示している。このような操作は、エンドユーザがＵＩとやり取りする時に起こり得る。こうして、表示コントロール操作は、スクロールバーの移動、ディスプレイ上のアイコンの配置、特定メッセージのダブルクリック、およびエンドユーザが現在のサーバベースアプリケーションに関連するソースデータ項目を間接的に要求する時のような、ＵＩ表示フィーチャの変化または修正変更を表す。こうして、プロセス２１００は、クライアントデバイスによって生成されるＵＩ表示コントロールのエンドユーザ操作に応答して、ＵＩ表示の１つまたは複数のフィーチャ（例えば、ＵＩフォーム、いくつかのＵＩコントロール、アイコン外観等）を更新することによって開始できる（タスク２１０２）。
【０１４７】
通常、ＵＩ表示コントロールの操作の結果、付加的なデータ項目が表示される。すなわち、現在のＵＩフォームは、多分より多くのデータ項目で埋められることが必要とされる。よって、クライアントデバイスは、適当な要求を行うことによって、現在のＵＩフォームにおける表示のためのデータ項目の検索を開始する（タスク２１０４）。クライアントデバイスは、クライアントデバイスが実際にデータを必要とする前にＵＩサーバから付加データを要求する「ルックアヘッド」技法を使用してもよい。例えば、プロセス２１００は、データ要求しきい値を超えたかどうかをテストしてもよい（問合せタスク２１０６）。このしきい値を超えていない場合、クライアントデバイスは、要求されたデータ項目がクライアントキャッシュにローカルにセーブされているかどうかを判定するために自己のキャッシュに問い合わせてもよい（問合せタスク２１０８）。要求されたデータ項目がクライアントキャッシュに存在する場合、ＵＩモジュールは、キャッシュからローカルにデータ項目を検索し、それをＵＩフォームに表示することができる（タスク２１１０）。しかし、必要なデータ項目がキャッシュされていない場合、クライアントデバイスはそれをＵＩサーバから要求することになる。
【０１４８】
ルックアヘッドしきい値に達している場合（または要求されたデータがクライアントキャッシュに入っていない場合）、クライアントデバイスは、付加データが要求されたことを示すようにＵＩ表示を更新してもよい（タスク２１１２）。この通知はエンドユーザに対する通知であり、データがＵＩサーバからダウンロードされている間のプレースホルダとして働く。例えば、クライアントデバイスは、適当なＵＩコントロールフィールドに「データ要求済み(Data Requested)」のようなテキストを表示してもよい。
【０１４９】
付加データが必要となったことに応答して、クライアントデバイスは、クライアント「送信」キューにダウンロード要求を入れる（タスク２１１４）。この点で、クライアントデバイスは、表示コントロールに対するユーザの操作がデータ要求コマンドをトリガしたか、またはさもなければデータダウンロードしきい値を超えた場合に、ＵＩサーバから複数の付加的のソースデータ項目を要求することができる。その後、変動する期間が経過する可能性があり、その間にクライアントデバイスはＵＩサーバから切断されるかもしれない。結局、クライアント「送信」キューに入れられた直後であるか、クライアントがＵＩサーバとの接続を再確立した後であるかにかかわらず、ダウンロード要求（または適当に構成されたコマンドもしくはメッセージ）はＵＩサーバに送信される（タスク２１１６）。送信が成功したと仮定すると、ＵＩサーバはダウンロード要求を受信し、それを適当なサーバベースアプリケーションに転送することになる（タスク２１１８）。このアプリケーションは、データ要求を処理し、要求されたデータ項目（または適当に構成されたコマンドもしくは要求）を、クライアントデバイスへ返送するためにサーバ「送信」キューに入れる（タスク２１２０）。
【０１５０】
要求されたデータ項目は、サーバ「送信」キューで不定期間待機するかもしれない。この期間は、そのデータ項目がクライアントデバイスに送信される前の切断されている期間を含み得る（タスク２１２２；フローチャートは図２２に続いている）。ダウンロードが成功したと仮定すると、クライアント受信要素は、データ項目を受信し、データタイプに従って、およびキャッシュ優先度または優先方式（前述）に従って、そのデータ項目をクライアントキャッシュに入れる（タスク２１２４）。さらに、クライアント受信モジュールは、新たにダウンロードされたデータ項目が利用可能であることをクライアントＵＩモジュールに通知してもよい（タスク２１２６）。ＵＩモジュールがデータ項目を待機しているか、または表示している場合（問合せタスク２１２８）、ＵＩモジュールは、対応するＵＩコントロールまたはフォームに表示するためにそのデータを検索する（タスク２１３０）。この状況は、例えば、現在のＵＩフォームが新しいソースデータ項目で埋められることを待機している場合に起こり得る。これに対して、ＵＩモジュールが新しいデータ項目を直ちには必要としていない場合、それらのデータ項目は、クライアントデバイスによって要求され、削除され、または後で修正変更されるまで、クライアントキャッシュに維持できる（タスク２１３２）。もちろん、上記のように、クライアントキャッシュは、必要であればクライアントキャッシュ内の既存のソースデータ項目が新しいデータ項目で置き換えることができるように管理されるのが望ましい。
【０１５１】
図２３は、クライアントデバイスにおけるアクションコントロールの操作を処理するプロセス２３００のフローチャートである。この場合、アクションコントロールとは、ユーザによって操作されるＵＩコントロールであって、その結果としてアプリケーションが、コントロールに表示されるデータを更新することとは異なって、あるアクションを実行することになるようなＵＩコントロールである。典型的なアクションコントロールとしてはメニューおよびボタンがあるが、リストビュー内のエントリのダブルクリックのような、何らかの仕事を実行するように「起動」されたデータ表示コントロールも含まれる。アクションコントロールは、データ項目の削除、データ項目の送信、アプリケーションの切り替え、またはＵＩフォームのクローズのようなアクションを引き起こす。実際の配置構成仕様では、アクションコントロールを、例えば「削除(Delete)」ボタン、「メッセージ送信(Send Message)」ボタン等の特定のＵＩ機能ボタンと関連付けることができる。
【０１５２】
プロセス２３００は、起動されたアクションコントロールに対応する起動スクリプトの識別から開始できる（タスク２３０２）。上記のように、クライアントデバイスは、任意の数のコマンドスクリプトを利用して、ＵＩサーバがあまり関与せずに効率的なクライアント側処理を容易にすることが可能である。適当なコマンドスクリプトは、識別された後、スクリプト内の各エントリを検索し処理することによって実行できる。よって、プロセス２３００は、ＵＩモジュールがコマンドを処理することができるように、コマンドスクリプト内の次のエントリを取得する（タスク２３０４）。
【０１５３】
現在のエントリが「データ送信」コマンドを表している場合（問合せタスク２３０６）、列挙されたＵＩコントロールからのユーザ入力データが転送のためにフォーマットされ、クライアント「送信」キューに入れられる（タスク２３０８）。その後、プロセスフローは、次のコマンドエントリが処理できるように、問合せタスク２３２８に進んでよい。やがて、以下でさらに詳細に説明するように、ユーザ入力データはクライアント送信要素によってＵＩサーバへ送信される。
【０１５４】
現在のエントリが「フォーム切り替え」コマンドを表している場合（問合せタスク２３１０）、クライアントデバイスは、現在のＵＩフォームを終了して新しいＵＩフォームを表示し始める。クライアントデバイスは、単一のアプリケーションによって利用される任意の数のＵＩフォーム間を切り替えることができる。さらに、ＵＩフォームの切り替えは、現在のサーバベースアプリケーションにおける変化に対応してもよい。フォームを切り替える時、具体的な実施形態はまず、現在のＵＩフォームに関連するキャッシュされているデータ項目に対するロックをデクリメントまたは解除してもよい（タスク２３１２）。上記のように、ＵＩフォームがアクティブであるか、または表示されている時、それぞれのデータ項目は、削除されないようにするためにキャッシュ内でロックされる。結局、クライアントデバイスは古いＵＩフォームから新しいＵＩフォームに切り替わる（タスク２３１４）。フォームの切り替えに関して、クライアントデバイスはいくつかの付加ステップ（例えば、ユーザが別のフォームへどのように切り替えるかにかかわらずステートおよび／またはデータがセーブされることを可能にする「フォーム終了」スクリプト）を実行してもよい。その後、クライアントＵＩモジュールは、エンドユーザに対する表示のために、新しいＵＩフォームを必要なデータ項目で埋めることができる。その後、プロセスフローは問合せタスク２３２８に進む。
【０１５５】
現在のエントリが「コントロール修正変更」コマンドを表している場合（問合せタスク２３１６）、クライアントデバイスは、指定されたプロパティを指定されたＵＩコントロールに適用することができる（タスク２３１８）。このようなコマンドは、コントロールが移動、サイズ修正変更、隠蔽、表示、無効化、消去等をされる時に生成できる。この点で、クライアントＵＩモジュールは、指定されたＵＩコントロールに関連するＵＩコントロール定義を検索し、指定されたプロパティを適用して、指定されたＵＩコントロールをディスプレイ上にレンダリングできる。典型的なＵＩコントロールプロパティとしては、サイズ、位置、可視性、およびラベリングがある。タスク２３１８の後、プロセスフローは問合せタスク２３２８に進む。
【０１５６】
現在のコマンドが「項目削除」コマンドを表している場合（問合せタスク２３２０）、クライアントデバイスはＵＩを適当な方法で更新する。エンドユーザは、ＵＩフォーム内の相異なる点で（例えばリストビューコントロールから、メッセージビューから、またはフォルダツリービューから）、「項目削除」コマンドを発することができる。すでにより詳細に説明したように、削除された項目がもともとキャッシュにセーブされていた場合にはクライアントキャッシュを修正変更できる。「項目削除」コマンドに応答して、クライアントデバイスは、識別された、または選択された項目をそれぞれのコントロール（例えばリストコントロール）から除去できる（タスク２３２２）。さらに、削除された項目および／またはその項目の適当な識別子が転送のためにフォーマットされ、クライアント「送信」キューに入れられる（タスク２３２４）。やがて、削除された項目（および／またはその識別子）がＵＩサーバに送信される。ＵＩサーバはそのシャドウキャッシュを更新して、クライアントキャッシュの現在のステータスを正確に反映させるのが望ましい。タスク２３２４の後、プロセスフローは問合せタスク２３２８に進む。
【０１５７】
クライアントデバイスは、他のコマンドを（必要があれば）適当な方法で処理するように適切に構成できる（タスク２３２６）。すなわち、クライアントデバイスは、本明細書で特定的に説明されたコマンドタイプの処理に限定される必要はない。現在のコマンドエントリが処理された後、クライアントデバイスは、まだ他にコマンドエントリが残っているかどうかを判定する（問合せタスク２３２８）。残っていない場合、プロセス２３００は終了する。残っている場合、プロセス２３００は、タスク２３０４でスクリプト内の次のコマンドエントリを取得することから、再び開始できる。このようにして、クライアントデバイスが現在のアクションコントロールを表すスクリプト全体を処理するまで、各コマンドエントリが処理される。
【０１５８】
システム機能の要約
図２４は、分散ＵＩシステム２４００の概略図である。図２４は、システム２４００の動作特徴のいくつかを示している。図２４に示す特徴および要素は、図７に関連して上記で説明したいくつかの特徴および要素と同等でもよい。実際、図７および図２４は両方とも同じシステムを表し得る。図２４は、上記で詳細に説明した技法の簡潔な要約の目的で提示されている。
【０１５９】
クライアントデバイス２４０２は、インターネットのような適当なネットワーク２４０６経由でＵＩサーバ２４０４と通信する。クライアントデバイス２４０２は、表示要素２４０８およびユーザ入力要素２４１０（例えば、マウスまたはトラックボールのようなポインティングデバイス、キーボード、キーパッド、タッチスクリーン等）を含む。動作時に、クライアントデバイス２４０２は、表示要素２４０８上のユーザインタフェース２４１２をレンダリングする。ユーザインタフェース２４１２は、ユーザ入力要素２４１０経由でエンドユーザによって操作できる。例えば、エンドユーザは、ＵＩサーバ２４０４とのコネクションを確立すること、ログインデータを入力すること、サーバベースアプリケーションを起動および終了すること、サーバベースアプリケーション間を切り替えること、ユーザインタフェース２４１２上にレンダリングされたアクションコントロールを操作すること、ユーザインタフェース２４１２上にレンダリングされた表示コントロールを操作すること、ユーザインタフェース２４１２に関連付けられたデータ項目を入力および編集すること、ならびにユーザインタフェース２４１２経由でその他のオペレーションを実行することができる。
【０１６０】
ＵＩサーバ２４０４は、クライアントデバイス２４０２自体から、サードパーティのエンティティもしくはプロセスから、またはあらかじめロードされたデータベースの形態で内部的に、クライアントデバイス２４０２のデバイス能力２４１４を取得するのが望ましい。デバイス能力２４１４は、ユーザインタフェース２４１２のフォーマットまたは構成に影響を及ぼし、それを制約し、またはその他の方法でそれに関係を持つことができるクライアントデバイス２４０２の特性またはパラメータを表す。ＵＩサーバ２４０４は、クライアントデバイス２４０２が使用するためのさまざまなＵＩフォーム定義２４１８をフォーマットし構成するためにＵＩフォーマット２４１６を実行する。特定のフォーム定義２４１８は、クライアントデバイス能力２４１４と、クライアントデバイス２４０２にとってアクセス可能な任意の数のサーバベースアプリケーション２４２０とに基づくか、またはさもなければそれらによって決定される（サーバベースアプリケーション２４２０は、ユーザインタフェース２４１２経由でエンドユーザに提示するためにソースデータ項目２４２２を処理し操作するように構成される）。ＵＩサーバ２４０４は、ユーザインタフェース２４１２経由でユーザにアプリケーションリスト２４２１を提供してもよい。それによりユーザは、素早くサーバベースアプリケーションを選択し、またはアプリケーション間を切り替えることが可能となる。
【０１６１】
クライアントデバイス２４０２は、特定のユーザインタフェースをレンダリングするために必要な時、ＵＩサーバ２４０４からＵＩフォーム定義２４１８を取得する。任意の数のＵＩフォーム定義２４１８が、クライアントデバイス２４０２にとってローカルに利用可能なように適切に構成されたクライアントキャッシュ要素２４２６に記憶できる。（ＵＩサーバではなく）クライアントデバイス２４０２が、種々のＵＩレンダリングタスク２４２４を実行して、表示要素２４０８上にユーザインタフェース２４１２を生成しレンダリングする。この点で、ＵＩレンダリングタスク２４２４は、適当なＵＩフォーム定義２４１８をキャッシュ要素２４２６から検索し、そのフォーム定義に関連する種々のＵＩ要素のフォーマットおよび配置を行い、ならびに任意の数のネイティブＵＩコントロール、ラベル、またはアイコン２４２８を組み込む（このようなネイティブＵＩフィーチャはクライアントデバイスＯＳに関連する）。また、ＵＩレンダリングタスク２４２４は、特に、適当なネイティブＵＩフィーチャが利用可能でない時に、任意の数の「カスタム」ＵＩ要素またはフィーチャを現在のユーザインタフェース２４１２に組み込むことができる。
【０１６２】
クライアントデバイス２４０２がＵＩレンダリングタスク２４２４を実行するが、ソースデータ項目２４２２はＵＩサーバ２４０４から取得される。この点で、ＵＩサーバ２４０４は、サーバベースアプリケーション２４２０のためのソースデータ項目２４２２の処理および取扱に関連する種々のデータ管理タスク２４３０を実行する。例えば、データ管理タスク２４３０は、データ送受信プロセス、データ検索プロセス、ＵＩコントロール内のデータ配置等に関連するものであってよい。
【０１６３】
データに対するクライアントからの要求に応答して、データ管理タスク２４３０は、クライアントデバイス２４０２へダウンロードするためにいくつかのソースデータ項目２４２２を検索できる。クライアントデバイスは、ダウンロードされたデータ項目を適当なキャッシュ要素２４３２にセーブし、ユーザインタフェース２４１２内の種々のＵＩコントロールを１つまたは複数のデータ項目で埋める。実際の記憶スペース制限により、クライアントデバイス２４０２は、ＵＩフォームキャッシュ要素２４２６および／またはデータキャッシュ要素２４３２に関連する種々のキャッシュ管理タスク２４３４を実行する可能性がある。好ましい実施形態では、キャッシュ管理タスク２４３４は、上記のように、必要な時に付加的なソースデータ項目を要求し、空きスペースが必要な時にキャッシュ項目を選択的に除去し、キャッシュがサーバベースアプリケーションの現在のステートと同期化し続けるようにキャッシュを更新し、およびその他のプロセスを実行する。
【０１６４】
サーバ側では、データ管理タスク２４３０（および／またはアプリケーション２４２０）は、ＵＩサーバ２４０４によって維持されるシャドウキャッシュ２４３６を更新することに責務を持つことができる。シャドウキャッシュ２４３６は、クライアントデバイス２４０２によってキャッシュされているデータ（例えば、ソースデータ項目、フォーム定義等）のコピーまたはそのデータへの参照を含むのが望ましい。シャドウキャッシュ２４３６により、ＵＩサーバ２４０４は、クライアントデバイス２４０２の現在のステータスをモニタし、効率的で効果的な方法でデータの転送を管理することができる。
【０１６５】
分散ＵＩシステムは、これらの好ましい機能および動作を使用して、伝送帯域幅を節約するような方法で任意の数のサーバベースアプリケーションのためのグラフィカルユーザインタフェースを提供する。さらに、分散ＵＩシステムは、大量の処理パワーおよび／または大きいデータ記憶容量を有するクライアントデバイスとともに使用するように制約される必要がない。その結果として、比較的小さい携帯無線クライアントデバイスが、サーバベースアプリケーションにアクセスしながら、本発明の技法を利用することができる。
【０１６６】
以上、本発明について、好ましい実施形態を参照して説明した。しかし、本明細書を読んだ当業者には認識されるように、本発明の範囲から逸脱することなく、好ましい実施形態に改変および修正変更をなし得る。これらおよび他の改変または修正変更は、添付の特許請求の範囲に記載されているような本発明の範囲内に含まれると解釈される。
【図面の簡単な説明】
【０１６７】
【図１】分散ユーザインタフェース（ＵＩ）システムのネットワーク配置構成の概略図である。
【図２】分散ＵＩシステムの典型的インプリメンテーションの高レベル概略図である。
【図３】分散ＵＩシステムによりサポートされる電子メールアプリケーションに関連するユーザインタフェースの説明図である。
【図４】図３に示すＵＩに関連するリストビューコントロールの説明図である。
【図５】図３に示すＵＩに関連するテキスト編集コントロールの説明図である。
【図６】電子メールアプリケーションに関連する不完全なＵＩの説明図である。
【図７】分散ＵＩシステムのサーバおよびクライアントコンポーネントの概略図である。
【図８】クライアントキャッシュ構造体の概略図である。
【図９】分散ＵＩプロセスのフローチャート図である。
【図１０】分散ＵＩアーキテクチャにより実行できる初期化プロセスのフローチャート図である。
【図１１】分散ＵＩアーキテクチャにより実行できるクライアント−サーバ同期化プロセスのフローチャート図である。
【図１２】分散ＵＩアーキテクチャにより実行できるアプリケーションおよびフォーム選択プロセスのフローチャート図である。
【図１３】クライアントキャッシュメンテナンスプロセスのフローチャート図である。
【図１４】サーバ起動プロセスのフローチャート図である。
【図１５】データを送信するサーバプロセスのフローチャート図である。
【図１６】受信メッセージを処理するサーバプロセスのフローチャート図である。
【図１７】データ修正変更を処理するプロセスのフローチャート図である。
【図１８】受信データを処理するクライアントプロセスのフローチャート図である。
【図１９】ＵＩ要素プロセスのフローチャート図である。
【図２０】データを送信するクライアントプロセスのフローチャート図である。
【図２１】データ表示コントロール操作を処理するクライアントプロセスのフローチャート図である。
【図２２】図２１に示すフローチャートの続きの図である。
【図２３】アクションコントロール操作を処理するクライアントプロセスのフローチャート図である。
【図２４】分散ＵＩシステムの概略図である。

Claims

サーバベースアプリケーションのためのユーザインタフェース（ＵＩ）をクライアントデバイスで、ＵＩサーバによって定められたＵＩフォーマットに従って生成するステップと、
前記サーバベースアプリケーションに関係する複数のソースデータ項目を前記ＵＩサーバから前記クライアントデバイスへ送信するステップと、
前記ＵＩによって使用される少なくとも１つのネイティブＵＩコントロールを前記複数のソースデータ項目で埋めるステップとを含むことを特徴とする、データ処理方法。
前記クライアントデバイスの複数のデバイス能力に基づいて前記ＵＩの特性をフォーマットするステップをさらに含むことを特徴とする、請求項１に記載の方法。
前記少なくとも１つのネイティブＵＩコントロールは前記クライアントデバイスに対するオペレーティングシステムに関連することを特徴とする、請求項１に記載の方法。
前記クライアントデバイスにおける提示のためソースデータ項目を操作するために前記サーバベースアプリケーションを前記ＵＩサーバで実行するステップをさらに含むことを特徴とする、請求項１に記載の方法。
前記クライアントデバイスのユーザによる前記ＵＩの操作に応答してアクション要求を生成するステップと、
前記アクション要求に応答して前記ＵＩを更新するステップとをさらに含むことを特徴とする、請求項１に記載の方法。
前記クライアントデバイスが前記ＵＩサーバから切断されている間に前記クライアントデバイスによりオフラインアクションを実行するステップと、
ひきつづいて、前記クライアントデバイスと前記ＵＩサーバ間にセッションを確立するステップと、
その後、前記クライアントデバイスから前記ＵＩサーバへ前記オフラインアクションを指示するコマンドを送信するステップとをさらに含むことを特徴とする、請求項１に記載の方法。
前記サーバベースアプリケーションにより前記コマンドを実行するステップをさらに含むことを特徴とする、請求項６に記載の方法。
前記オフラインアクションは前記クライアントデバイスにおける前記ソースデータ項目の少なくとも１つを修正変更し、
前記方法は、前記ソースデータ項目の修正変更を反映するために前記ＵＩサーバによって維持される対応する複数のソースデータ項目を更新するステップをさらに含むことを特徴とする、請求項６に記載の方法。
前記ＵＩサーバにおいてシャドウキャッシュを維持するステップをさらに含み、該シャドウキャッシュは、前記ＵＩサーバから前記クライアントデバイスへ送信されるソースデータ項目のリストを含むことを特徴とする、請求項１に記載の方法。
前記複数のソースデータ項目を前記クライアントデバイスに常駐するクライアントキャッシュにセーブするステップをさらに含むことを特徴とする、請求項１に記載の方法。
前記複数のソースデータ項目を収容するためにクライアントキャッシュ項目を除去するステップをさらに含むことを特徴とする、請求項１０に記載の方法。
前記除去するステップは、階層的優先方式に従って前記クライアントキャッシュ項目を選択的に除去することを特徴とする、請求項１１に記載の方法。
前記サーバベースアプリケーションに関係するクライアントアクションコマンドを前記ＵＩサーバから前記クライアントデバイスへ送信するステップと、
前記クライアントデバイスにより前記クライアントアクションコマンドを実行するステップとをさらに含むことを特徴とする、請求項１に記載の方法。
前記複数のソースデータ項目は、前記ＵＩサーバにおいて利用可能な比較的大きい量の関連データの一部を表すことを特徴とする、請求項１に記載の方法。
前記比較的大きい量の関連データは項目リストを含み、
前記複数のソースデータ項目は前記項目リストのサブセットを表すことを特徴とする、請求項１４に記載の方法。
前記比較的大きい量の関連データは文書を含み、
前記複数のソースデータ項目は前記文書の一部を表すことを特徴とする、請求項１４に記載の方法。
前記比較的大きい量の関連データは画像を含み、
前記複数のソースデータ項目は前記画像の一部を表すことを特徴とする、請求項１４に記載の方法。
前記比較的大きい量の関連データはテキスト本文を含み、
前記複数のソースデータ項目は前記テキスト本文の一部を表すことを特徴とする、請求項１４に記載の方法。
クライアントデバイスの複数のデバイス能力に応答してユーザインタフェース（ＵＩ）フォームを定義するステップと、
前記クライアントデバイスにローカルに前記ＵＩフォームを記憶するステップと、
ＵＩサーバによって実行されるサーバベースアプリケーションに関係する複数のソースデータ項目を前記クライアントデバイスにローカルにセーブするステップと、
前記ＵＩフォームを前記複数のソースデータ項目で埋めるステップとを含むことを特徴とする、データ処理方法。
前記複数のソースデータ項目を前記ＵＩサーバから前記クライアントデバイスへ送信するステップをさらに含むことを特徴とする、請求項１９に記載の方法。
前記定義するステップは、前記クライアントデバイスから取得されるデバイス識別子に応答して前記ＵＩサーバによって実行されることを特徴とする、請求項１９に記載の方法。
前記クライアントデバイスにおける提示のためのソースデータ項目を操作するために前記サーバベースアプリケーションを前記ＵＩサーバで実行するステップをさらに含むことを特徴とする、請求項１９に記載の方法。
前記クライアントデバイスのユーザによる前記ＵＩフォームの操作に応答してアクション要求を生成するステップと、
前記アクション要求に応答して前記ＵＩフォームを更新するステップとをさらに含むことを特徴とする、請求項１９に記載の方法。
前記クライアントデバイスが前記ＵＩサーバから切断されている間に前記クライアントデバイスによりオフラインアクションを実行するステップと、
ひきつづいて、前記クライアントデバイスと前記ＵＩサーバ間にセッションを確立するステップと、
その後、前記クライアントデバイスから前記ＵＩサーバへ前記オフラインアクションを指示するコマンドを送信するステップとをさらに含むことを特徴とする、請求項１９に記載の方法。
前記サーバベースアプリケーションにより前記コマンドを実行するステップをさらに含むことを特徴とする、請求項２４に記載の方法。
前記オフラインアクションは前記クライアントデバイスにおける前記ソースデータ項目の少なくとも１つを修正変更し、
前記方法は、前記ソースデータ項目の修正変更を反映するために前記ＵＩサーバによって維持される対応する複数のソースデータ項目を更新するステップをさらに含むことを特徴とする、請求項２４に記載の方法。
前記セーブステップは、前記複数のソースデータ項目を前記クライアントデバイスに常駐するクライアントキャッシュにセーブすることを特徴とする、請求項１９に記載の方法。
前記複数のソースデータ項目を収容するためにクライアントキャッシュ項目を除去するステップをさらに含むことを特徴とする、請求項２７に記載の方法。
前記除去するステップは、階層的優先方式に従って前記既存のクライアントキャッシュ項目を選択的に除去することを特徴とする、請求項２８に記載の方法。
前記クライアントデバイスによってレンダリングされた表示コントロールの操作に応答して前記ＵＩフォームを更新するステップと、
前記表示コントロールの前記操作によりデータ要求コマンドをトリガした場合に複数の付加的ソースデータ項目を前記ＵＩサーバから要求するステップと、
前記クライアントキャッシュにセーブされているソースデータ項目を前記複数の付加的ソースデータ項目で置き換えるステップとをさらに含むことを特徴とする、請求項２７に記載の方法。
前記クライアントデバイスによってレンダリングされた表示コントロールの操作に応答して前記ＵＩフォームを更新するステップと、
前記表示コントロールの前記操作に応答して付加的ソースデータ項目を前記クライアントキャッシュから検索するステップと、
前記付加的ソースデータ項目を前記ＵＩフォームに表示するステップとをさらに含むことを特徴とする、請求項２７に記載の方法。
前記サーバベースアプリケーションに関係するクライアントアクションコマンドを前記ＵＩサーバから前記クライアントデバイスへ送信するステップと、
前記クライアントデバイスにより前記クライアントアクションコマンドを実行するステップとをさらに含むことを特徴とする、請求項１９に記載の方法。
前記定義するステップは、前記サーバベースアプリケーションに基づいて前記ＵＩフォームを定義することを特徴とする、請求項１９に記載の方法。
前記定義するステップは、前記クライアントデバイスにローカルに記憶されている少なくとも１つのネイティブＵＩコントロールで前記ＵＩフォームを定義することを特徴とする、請求項１９に記載の方法。
前記ＵＩサーバは、前記ＵＩフォームに関連する総数のソースデータ項目にアクセスするものであり、
前記セーブするステップ中にセーブされる前記複数のソースデータ項目は前記総数のソースデータ項目の一部を表すようにしたことを特徴とする、請求項１９に記載の方法。
前記ＵＩサーバが付加的ソースデータ項目に対する要求を受信するステップと、
前記ＵＩサーバが前記要求に応答して前記総数のソースデータ項目のうちの後続部分を前記クライアントデバイスへ送信するステップとをさらに含むことを特徴とする、請求項３５に記載の方法。
前記ＵＩサーバは、前記ＵＩフォームの操作に応答して前記クライアントデバイスから前記要求を受信することを特徴とする、請求項３６に記載の方法。
クライアントデバイスにおける提示のためのソースデータ項目を操作するように構成されたサーバベースアプリケーションをユーザインタフェース（ＵＩ）サーバで実行するステップと、
前記クライアントデバイスのユーザにデータ項目を提示することが可能なＵＩフォームを前記クライアントデバイスに表示するステップと、
前記クライアントデバイスのユーザによる前記ＵＩフォームの操作に応答してアクション要求を生成するステップと、
前記アクション要求に応答して前記ＵＩフォームを更新するステップとを含むことを特徴とする、データ処理方法。
前記アクション要求を前記クライアントデバイスから前記ＵＩサーバへ送信するステップと、
前記ＵＩサーバにより前記アクション要求を処理するステップとをさらに含むことを特徴とする、請求項３８に記載の方法。
前記サーバベースアプリケーションに関係する複数のソースデータ項目を前記ＵＩサーバから前記クライアントデバイスへ送信するステップをさらに含み、該送信するステップは前記アクション要求に応答して実行されることを特徴とする、請求項３８に記載の方法。
前記複数のソースデータ項目は、前記ＵＩサーバにおいて利用可能な比較的大きい量の関連データの一部を表すことを特徴とする、請求項４０に記載の方法。
前記ＵＩフォームの初期操作に応答して、前記ＵＩサーバから前記複数のソースデータ項目を要求するステップと、
ひきつづいて、前記ＵＩフォームの後続操作に応答して、前記ＵＩサーバから複数の付加的ソースデータ項目を要求するステップとをさらに含み、
前記複数の付加的ソースデータ項目は、前記の比較的大きい量の関連データのうちの第２部分を表すことを特徴とする、請求項４１に記載の方法。
前記ＵＩサーバが、新しい、削除された、または修正変更されたデータ項目を表す情報を受信するステップと、
前記ＵＩサーバが、前記新しい、削除された、または修正変更されたソースデータ項目を表すプッシュデータを前記クライアントデバイスへ送信するステップとをさらに含むことを特徴とする、請求項３８に記載の方法。
前記ＵＩサーバが、前記プッシュデータに対応するプッシュ通知を前記クライアントデバイスへ送信するステップをさらに含むことを特徴とする、請求項４３に記載の方法。
クライアントデバイスの複数のデバイス能力に基づいてサーバベースアプリケーションに対するユーザインタフェース（ＵＩ）フォーム定義を生成するステップと、
前記ＵＩフォーム定義に対応するＵＩフォームをレンダリングするように前記クライアントデバイスに命令するステップと、
前記クライアントデバイスのオペレーティングシステムに関連する少なくとも１つのネイティブＵＩコントロールで前記ＵＩフォームをレンダリングするステップと、
前記サーバベースアプリケーションに関係する複数のデータ項目をＵＩサーバから前記クライアントデバイスへ送信するステップと、
前記複数のデータ項目を前記少なくとも１つのネイティブＵＩコントロールにおいて表示するステップとを含むことを特徴とする、データ処理方法。
前記ＵＩフォームに含まれるＵＩコントロールの操作に対応するコマンドスクリプトを指定するステップをさらに含み、該コマンドスクリプトは前記クライアントデバイスによる実行のために構成されたことを特徴とする、請求項４５に記載の方法。
前記クライアントデバイスにより、前記クライアントデバイスにおける前記ＵＩコントロールの操作に応答して前記コマンドスクリプトを実行するステップをさらに含むことを特徴とする、請求項４６に記載の方法。
前記複数のデータ項目を前記クライアントデバイスに常駐するクライアントキャッシュにセーブするステップをさらに含むことを特徴とする、請求項４５に記載の方法。
前記表示するステップの前に、前記複数のデータ項目を前記クライアントキャッシュから検索するステップをさらに含むことを特徴とする、請求項４８に記載の方法。
前記少なくとも１つのネイティブＵＩコントロールの操作に応答して、前記ＵＩサーバから前記複数のデータ項目を要求するステップをさらに含むことを特徴とする、請求項４５に記載の方法。
前記複数のデータ項目は、前記ＵＩサーバにおいて利用可能な比較的大きい量の関連データの一部を表すことを特徴とする、請求項４５に記載の方法。
前記少なくとも１つのネイティブＵＩコントロールの初期操作に応答して、前記ＵＩサーバから前記複数のデータ項目を要求するステップと、
ひきつづいて、前記少なくとも１つのネイティブＵＩコントロールの更なる操作に応答して、前記ＵＩサーバから複数の付加的データ項目を要求するステップとをさらに含み、
前記複数の付加的データ項目は、前記比較的大きい量の関連データのうちの第２部分を表すことを特徴とする、請求項５１に記載の方法。
ユーザインタフェース（ＵＩ）フォーム定義に従ってサーバベースアプリケーションのためのＵＩを生成し、該ＵＩによって使用される少なくとも１つのネイティブＵＩコントロールをソースデータ項目で埋めるように構成されたＵＩモジュールを含むクライアントデバイスアーキテクチャと、
前記サーバベースアプリケーションに関係する複数のソースデータ項目を前記クライアントデバイスアーキテクチャへ送信するように構成されたサーバ送信モジュールを含むＵＩサーバアーキテクチャとを含み、
前記ＵＩモジュールは、前記ＵＩコントロールを前記複数のソースデータ項目で埋めるように構成されていることを特徴とする、分散ユーザインタフェース（ＵＩ）アーキテクチャ。
前記ＵＩサーバアーキテクチャは、前記クライアントデバイスアーキテクチャを含むクライアントデバイスの複数のデバイス能力に基づいて前記ＵＩフォーム定義を生成するＵＩフォーマットモジュールをさらに含むことを特徴とする、請求項５３に記載の分散ＵＩアーキテクチャ。
前記クライアントデバイスアーキテクチャは、前記複数のソースデータ項目を記憶するように構成されたクライアントキャッシュをさらに含むことを特徴とする、請求項５３に記載の分散ＵＩアーキテクチャ。
前記ＵＩサーバアーキテクチャは、前記クライアントキャッシュの内容を表すデータを記憶するように構成されたシャドウキャッシュをさらに含むことを特徴とする、請求項５５に記載の分散ＵＩアーキテクチャ。
前記クライアントキャッシュは、前記ＵＩフォーム定義を記憶するようにさらに構成されたことを特徴とする、請求項５５に記載の分散ＵＩアーキテクチャ。
前記複数のソースデータ項目は、前記ＵＩサーバアーキテクチャに利用可能な比較的大きい量の関連データの一部を表すことを特徴とする、請求項５３に記載の分散ＵＩアーキテクチャ。
クライアント処理アーキテクチャ、および互換性のある通信要素と通信するように構成されたクライアント通信要素を有するクライアントデバイスと、
サーバ処理アーキテクチャ、および前記クライアント通信要素と通信するように構成されたサーバ通信要素を有するＵＩサーバとを含み、
前記クライアント処理アーキテクチャは、
デバイス識別子を前記ＵＩサーバへ送信し、
ＵＩフォーム定義に従ってＵＩフォームを生成し、そして、
サーバベースアプリケーションに関連する複数のソースデータ項目で少なくとも１つのネイティブＵＩコントロールを埋めるように構成され、
前記サーバ処理アーキテクチャは、
前記デバイス識別子を前記クライアントデバイスから受信し、
前記デバイス識別子に応答して前記ＵＩフォーム定義を識別するように構成され、そして、
前記ＵＩフォームでレンダリングするために前記複数のソースデータ項目を前記クライアントデバイスへ送信するように構成されたことを特徴とする、分散ユーザインタフェース（ＵＩ）システム。
前記クライアントデバイスは、ＵＩ特性に関係する複数のデバイス能力を含み、
前記サーバ処理アーキテクチャは、前記複数のデバイス能力に基づいて前記ＵＩフォーム定義を生成するようにさらに構成されたことを特徴とする、請求項５９に記載のシステム。
前記クライアントデバイスは、前記複数のソースデータ項目を記憶するように構成されたクライアントキャッシュをさらに含むことを特徴とする、請求項５９に記載のシステム。
前記クライアントデバイスは、前記ＵＩフォーム定義を記憶するように構成されたクライアントキャッシュをさらに含むことを特徴とする、請求項５９に記載のシステム。
前記複数のソースデータ項目は、前記ＵＩサーバにおいて利用可能な比較的大きい量の関連データの一部を表すことを特徴とする、請求項５９に記載のシステム。
前記クライアント処理アーキテクチャは、前記ＵＩフォームの初期操作に応答して、前記ＵＩサーバから前記複数のソースデータ項目を要求するようにさらに構成され、
前記クライアント処理アーキテクチャは、ひきつづいて、前記ＵＩフォームのさらなる操作に応答して、前記ＵＩサーバから複数の付加的ソースデータ項目を要求するようにさらに構成され、
前記複数の付加的ソースデータ項目は、前記の比較的大きい量の関連データのうちの第２部分を表すことを特徴とする、請求項６３に記載のシステム。