(57)【特許請求の範囲】
【請求項１】
情報ネットワークと通信可能なシンクライアントコンピュータを用いてパーソナライズされた情報を獲得するための方法であって、
前記シンクライアントコンピュータが、ユーザから供給された情報を含み前記ユーザの複数のペルソナを表す個人パターンテンプレートを、前記シンクライアントコンピュータ内のメモリに確立する動作を備え、
前記複数のペルソナは、前記複数のペルソナが適用される異なるコンテキストに対応した複数のペルソナセットを含み、
前記複数のペルソナセットは、ペルソナ情報を含む１つ以上のペルソナレコードと、各ペルソナレコードに対応する１つ以上のプロフィールレコードと、を含む階層的データレコードを設定することによって生成され、
各プロフィールレコードは、ユーザ名とユーザ住所とを含む詳細ユーザプロフィール情報を含み、
前記複数のペルソナセットは、各プロフィールレコードに含まれている前記詳細ユーザプロフィール情報と、各ペルソナレコードに含まれている前記ペルソナ情報とを、前記階層的データレコードが格納されるデータモデル内に集合させることによって生成されており、
前記方法は、さらに、
前記シンクライアントコンピュータが、ユーザ入力に部分的に基づいて照会を作成する動作と、
前記シンクライアントコンピュータが、情報ネットワークに情報の照会を送信する動作と、
前記シンクライアントコンピュータが、前記情報ネットワークからの照会に対する応答を受信する動作と、
前記シンクライアントコンピュータが、前記シンクライアントコンピュータ上のアプリケーションツールを利用して前記応答内の情報を処理してフィルタ済み応答を得る動作と、
を備え、
前記応答内の情報の処理は、
前記複数のペルソナの中から、ユーザの選択に基づいて１つのペルソナを選択する動作と、
選択されたペルソナのペルソナ情報、及び、詳細ユーザプロフィール情報に基づいて、前記アプリケーションツールによって前記応答内の情報をフィルタリングする動作と、
を含み、
前記方法は、さらに、
前記シンクライアントコンピュータが、前記選択されたペルソナに基づいて前記応答内でフィルタリングされた情報を前記ユーザに対して表示する動作と
を備える方法。
【請求項２】
請求項１記載の方法であって、
前記個人パターンテンプレートは、複数のワードパターンを含む、方法。
【請求項３】
請求項１記載の方法であって、
前記シンクライアントコンピュータは、前記情報ネットワークに存在するモバイルポータルサーバと通信可能である、方法。
【請求項４】
請求項１記載の方法であって、
前記シンクライアントコンピュータはインテリジェントエージェントプロセッサを含む、方法。
【請求項５】
請求項１記載の方法であって、
前記シンクライアントコンピュータは、カスタマデータを照会する手段を含む、方法。
【請求項６】
請求項１記載の方法であって、
前記シンクライアントコンピュータは、情報の暗号化と解読を行うためのセキュリティ手段を含む、方法。
【請求項７】
請求項１記載の方法であって、
前記シンクライアントコンピュータは、第三者のコンテンツを獲得するためのインターフェースを含む前記情報ネットワークと通信可能である、方法。
【請求項８】
請求項１記載の方法であって、
前記シンクライアントコンピュータはモバイルクライアントのサポートを含む前記情報ネットワークと通信可能である、方法。
【請求項９】
情報ネットワークと通信してパーソナライズされた情報を獲得するシンクライアントコンピュータであって、
ユーザから供給された情報を含み前記ユーザの複数のペルソナを表す個人パターンテンプレートを格納するメモリを備え、
前記複数のペルソナは、前記複数のペルソナが適用される異なるコンテキストに対応した複数のペルソナセットを含み、
前記複数のペルソナセットは、ペルソナ情報を含む１つ以上のペルソナレコードと、各ペルソナレコードに対応する１つ以上のプロフィールレコードと、を含む階層的データレコードを設定することによって生成され、
各プロフィールレコードは、ユーザ名とユーザ住所とを含む詳細ユーザプロフィール情報を含み、
前記複数のペルソナセットは、各プロフィールレコードに含まれている前記詳細ユーザプロフィール情報と、各ペルソナレコードに含まれている前記ペルソナ情報とを、前記階層的データレコードが格納されるデータモデル内に集合させることによって生成されており、
前記シンクライアントコンピュータは、さらに、
前記シンクライアントコンピュータ上で、ユーザ入力に部分的に基づいて照会を作成するロジックと、
前記情報ネットワークに情報の照会を送信するロジックと、
前記照会に対する応答を前記情報ネットワークから受信するロジックと、
前記シンクライアントコンピュータ上のアプリケーションツールを利用して前記応答内の情報を処理してフィルタ済み応答を得るロジックであって、前記複数のペルソナの中から、ユーザの選択に基づいて１つのペルソナを選択し、選択されたペルソナのペルソナ情報、及び、詳細ユーザプロフィール情報に基づいて、前記アプリケーションツールによって前記応答内の情報をフィルタリングするロジックと、
前記選択されたペルソナに基づいて前記応答内でフィルタリングされた情報を前記ユーザに対して表示するロジックと
を備える装置。
【請求項１０】
パーソナライズされた情報を取得するコンピュータプログラムを格納するコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、シンクライアントコンピュータのメモリにロード可能であり、
前記コンピュータプログラムは、
ユーザから供給された情報を含み前記ユーザの複数のペルソナを表す個人パターンテンプレートを確立する命令を備え、
前記複数のペルソナは、前記複数のペルソナが適用される異なるコンテキストに対応した複数のペルソナセットを含み、
前記複数のペルソナセットは、ペルソナ情報を含む１つ以上のペルソナレコードと、各ペルソナレコードに対応する１つ以上のプロフィールレコードと、を含む階層的データレコードを設定することによって生成され、
各プロフィールレコードは、ユーザ名とユーザ住所とを含む詳細ユーザプロフィール情報を含み、
前記複数のペルソナセットは、各プロフィールレコードに含まれている前記詳細ユーザプロフィール情報と、各ペルソナレコードに含まれている前記ペルソナ情報とを、前記階層的データレコードが格納されるデータモデル内に集合させることによって生成されており、
前記プログラムは、さらに、
前記シンクライアントコンピュータ上で、ユーザ入力に部分的に基づいて照会を作成する命令と、
情報ネットワークに情報の照会を送信する命令と、
前記情報ネットワークからの照会に対する応答を受信する命令と、
前記シンクライアントコンピュータ上のアプリケーションツールを利用して前記応答内の情報を処理してフィルタ済み応答を得る命令であって、前記複数のペルソナの中から、ユーザの選択に基づいて１つのペルソナを選択し、選択されたペルソナのペルソナ情報、及び、詳細ユーザプロフィール情報に基づいて、前記アプリケーションツールによって前記応答内の情報をフィルタリングする命令と、
前記選択されたペルソナに基づいて前記応答内でフィルタリングされた情報を前記ユーザに対して表示する命令と
を備えるコンピュータ読み取り可能な媒体。
【請求項１１】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記個人パターンテンプレートは、複数のワードパターンを含む、コンピュータ読み取り可能な媒体。
【請求項１２】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、さらに、モバイルポータルサーバと通信するための命令を備える、コンピュータ読み取り可能な媒体。
【請求項１３】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、さらに、前記情報ネットワークと通信してカスタマデータを照会するための命令を備える、コンピュータ読み取り可能な媒体。
【請求項１４】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、さらに、情報の暗号化と解読を行うための命令を備える、コンピュータ読み取り可能な媒体。
【請求項１５】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、さらに、前記情報ネットワークと通信して第三者のコンテンツを獲得するためのインターフェースを提供する命令を備える、コンピュータ読み取り可能な媒体。
【請求項１６】
請求項１０記載のコンピュータ読み取り可能な媒体であって、
前記コンピュータプログラムは、さらに、前記情報ネットワークと通信してモバイルクライアントのサポートを提供する命令を備える、コンピュータ読み取り可能な媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、エージェントベースのシステムに関し、特に、インターフェースサポートフレームワークを介し、インターネットにアクセスしてユーザが必要とする商品情報を獲得するモバイルコンピューティング環境に関する。
【０００２】
【従来の技術及び発明が解決しようとする課題】
あらゆる環境におけるコンピュータ支援は、コンピュータ技術が社会に組み込まれる度合いが高まるにつれ、不可欠となりつつある。モバイルコンピューティング技術では、個人があらゆる時にあらゆる環境でコンピュータ関連情報にアクセスできるようにすることで、この問題に取り組んでいる。
【０００３】
モバイルコンピュータ技術における第一の大きな進歩の１つは、携帯情報端末（ＰＤＡ）である。ＰＤＡは、ユーザがコンピュータ関連情報にアクセスすることを可能にし、更に手のひらのサイズである。ＰＤＡを使用することで、ユーザは、身辺雑事を整理し、メモを取り、方程式を計算し、住所録に連絡先の電話番号を記録できる。加えて、ＰＤＡは通常、デスクトップコンピュータとの通信が可能であり、これは一般的には有線接続を介して行われる。この接続により、ＰＤＡは、デスクトップコンピュータとの間での情報のダウンロード及び情報のアップロードが可能となる。その後の開発によって、ＰＤＡに無線機能が与えられた。無線機能により、ＰＤＡは、そのＰＤＡに物理的に接続されていない他のコンピュータと対話することが可能になった。
【０００４】
無線ＰＤＡは、ワールドワイドウェッブに接続されたコンピュータと通信することが可能になり、これは間もなく、Ｗｅｂブラウジングが可能なＰＤＡをもたらした。ＰＤＡのＷｅｂブラウジング機能を開発した第一の企業の１つはインターコムだった。インターコムのFalcon Mobile Serverにより、Ｗｅｂ機能付きＰＤＡは、ホストコンピュータと直接接続することができる。ソフトウェアをホストサーバにインストールするだけで、ＰＤＡ端末はワールドワイドウェッブを通じて情報にアクセスできるようになった。
【０００５】
現在では、モバイルコンピューティングにおける更なる統合が望まれている。テキサス州アービングの企業であるノキアは、Ｎｏｋｉａ  ９０００無線ボイス電話を開発することで、この統合問題に部分的に取り組んだ。Ｎｏｋｉａ  ９０００には、小型キーボードと、マイクロブラウザベンダであるアンワイヤードプラネット社からの特別なＷｅｂブラウザと、小型ＶＧＡモニタが含まれる。ノキアは、エリクソン社、モトローラ社、及びアンワイヤードプラネット社と共同で、標準化されたブラウザ技術及びサーバフォーマットであるワイヤレスアプリケーションプロトコル（ＷＡＰ）を確立した。ＷＡＰは、製造業者に、無線電話にデータ機能を搭載するための標準化された方法を提供し、これにより通信事業者は無線通信による管理の度合いを高めることができる。例えば、通信事業者が新しいデータサービスの実地試験を行いたい場合、この通信事業者はサーバ上でサービスを実施し、マイクロブラウザを通じて、これを電話に伝達し、満足できないサービスであることが分かった場合には、このサービスを調整できる。
【０００６】
従来技術の図１Ａは、Ｗｅｂポータルネットワークに基づく従来技術のモバイルコンピューティングソリューションの図である。従来技術において、ユーザ１０は、ネットワークのそれぞれの参加者に個別に対処する必要があった。従来技術のモバイルコンピューティングソリューションにおいて、ユーザ１０は、インターネットサービスプロバイダ（ＩＳＰ）１２を利用して、Ｗｅｂポータル１４へのアクセスを得る。Ｗｅｂポータル１４は、ユーザ１０に直接情報を提供するサードパーティサービス１６にアクセスする。しかしながら、インターネットサービスプロバイダ１２と取引することに加え、ユーザ１０は装置製造業者又は小売業者１８から無線装置を購入する必要がある。ほとんどの場合では、ユーザ１０は、ブラウザプロバイダ２０からブラウザを購入する必要もある。一般に、ユーザは、無線通信費用を支払う必要があり、これによりユーザが電話会社２２と取引する必要性が生じる。最後に、Ｗｅｂでの何らかの購入により、ユーザ１０がクレジットカード会社２４と取引する必要性が生じる。統一されたパッケージサービスが理想的なモバイルコンピューティングソリューションであることは明白である。更には、エージェントを使用する統一されたパッケージサービスが非常に望ましい。
【０００７】
エージェントベースの技術は、フォアグラウンド及びバックグラウンドモードで様々なコンピュータベースのタスクを実行するためにユーザと対話するように設計されたアプリケーションでの使用に関して、重要性が増している。エージェントソフトウェアは、ルーチンであるタスク、冗長なタスク、及び時間のかかるタスクを実行するために、ユーザの立場に立って設定されたコンピュータプログラムを備える。個々のユーザによって有効となるように、エージェントは個々のユーザの目標、習慣、及び好みに合わせてパーソナライズする必要がある。そのため、ユーザからユーザ固有の知識を効率的及び効果的に取得し、これを利用してユーザに代わってタスクを実行するために、エージェントには大きな要件が存在する。
【０００８】
エージェンシ又はエージェントのユーザという概念は定着している。エージェントとは、通常は当事者と呼ばれる別の人間により、その当事者に代わって行動することを認められた人間である。これにより、当事者はエージェントに対して、当事者が実行したくないタスク又は実行できないタスクを実行する権限を与える。例えば、保険エージェントは当事者のために保険に関する要件を取り扱うことが可能であり、或いはタレントエージェントは演奏者に代わって行動し、コンサートの日程を手配できる。
【０００９】
コンピュータの出現により、エージェントを利用する新しい領域が登場した。エキスパートシステムの分野での大きな進歩により、コンピュータプログラムは、コンピュータユーザに代わって行動し、ルーチンであるタスク、冗長なタスク、及びその他の時間のかかるタスクを実行することができる。こうしたコンピュータプログラムは、「ソフトウェアエージェント」と呼ばれる。
【００１０】
更に、最近ではコンピュータ及び通信ネットワークが急増している。こうしたネットワークにより、ユーザは、基本的には、地理的な制限をまったく受けずに、膨大な量の情報及びサービスにアクセスすることができる。したがって、ソフトウェアエージェントは、ユーザに代わって多数のタスクを実行するための豊かな環境を有している。例えば、現在では、エージェントにより、飛行機の予約を行い、チケットを購入し、そのチケットをユーザに直接送ることが可能である。同様に、エージェントは、インターネットをスキャンし、最新のスポーツ情報又はニュースから応用物理の特定の卒業論文に至るまでの情報を取得することができる。現在のソリューションでは、ユーザの来るべきイベントについて、的を絞って情報を取得することにエージェント技術を応用することはできない。
【００１１】
【発明の概要】
Ｗｅｂベース情報検索及び表示システムを促進するシステムを開示する。インターネットプロトコル機能が付いた無線電話又は同様のハンドヘルド型無線装置が、インターネットへのポータブルポータルを提供するために、他の周辺機器と統合される。この無線装置は、ユーザに、ユーザが関心を持っている情報を入力することを促す。この情報により、（Ｗｅｂサーバ上で実行される）サービスルーチンにクエリが伝送される。このサービスルーチンは、その後、分散通信ネットワークを利用してＷｅｂにクエリ（照会）を行い、様々なＷｅｂサプライヤから価格、納品、及び入手可能性に関する情報を探す。この情報は、フォーマットされた後、インターフェースサポートフレームワークを介してハンドヘルドデバイスのスクリーン上に表示される。こうして、ユーザは、ハンドヘルドデバイスを使用して対話式に注文することが可能になる。
【００１２】
【発明の実施の形態】
前記及びその他の目的、態様、及び利点は、図面を参照して、以下の本発明の好適な実施形態の詳細な説明からより良く理解される。
【００１３】
本発明によるシステムの好適な実施形態は、好ましくは、ＩＢＭ互換パーソナルコンピュータ、Ａｐｐｌｅマッキントッシュコンピュータ、又はＵＮＩＸベースワークステーションといったパーソナルコンピュータのコンテキストにおいて実施される。代表的なハードウェア環境は図１に表されており、ここでは、マイクロプロセッサ等の中央演算処理装置１１０と、システムバス１１２によって相互接続される他の多数のユニットとを有する好適な実施形態によるワークステーションの典型的なハードウェア構成を表している。図１に示すワークステーションは、ランダムアクセスメモリ（ＲＡＭ）１１４と、読み取り専用メモリ（ＲＯＭ）１１６と、ディスク記憶ユニット１２０等の周辺機器をバス１１２に接続するための入出力アダプタ１１８と、キーボード１２４、マウス１２６、スピーカ１２８、マイクロフォン１３２、及び又はタッチスクリーン（表示なし）等のその他のユーザインタフェース装置をバス１１２に接続するためのユーザインタフェースアダプタ１２２と、ワークステーションを通信ネットワーク（例えばデータ処理ネットワーク）に接続するための通信アダプタ１３４と、バス１１２をディスプレイ装置１３８に接続するためのディスプレイアダプタ１３６とを含む。このワークステーションには通常、Ｍｉｃｒｏｓｏｆｔ  Ｗｉｎｄｏｗｓ  ＮＴ又はＷｉｎｄｏｗｓ／９５オペレーティングシステム（ＯＳ）、ＩＢＭ  ＯＳ／２オペレーティングシステム、ＭＡＣ  ＯＳ、又はＵＮＩＸオペレーティングシステム等のオペレーティングシステムが常駐する。当業者には、こうした前記のものとは異なるプラットフォーム及びオペレーティングシステム上でも、本発明が実施可能であることが理解される。
【００１４】
好適な実施形態は、Ｊａｖａ(登録商標)、Ｃ、及びＣ＋＋言語を使用し、オブジェクト指向プログラミング方法論を利用して書かれる。オブジェクト指向プログラミング（ＯＯＰ）は、複雑なアプリケーションの開発に使用されることが増えている。ＯＯＰがソフトウェアの設計及び開発の主流になるにつれ、様々なソフトウェアソリューションでは、ＯＯＰの恩恵を利用するための適応が求められる。メッセージングインタフェースのためのＯＯＰクラス及びオブジェクトのセットを提供できるように、こうしたＯＯＰの原理を電子メッセージングシステムのメッセージングインタフェースに適応させる必要性が存在する。
【００１５】
ＯＯＰはオブジェクトを使用するコンピュータソフトウェアを開発するプロセスであり、問題を分析するステップと、システムを設計するステップと、プログラムを構築するステップとを含む。オブジェクトとは、データと関連構造及び手順の集合とを両方とも包含するソフトウェアパッケージである。データと関連構造及び手順の集合とを両方とも包含するため、特定のタスクを実行するために他の追加構造、手順、又はデータを必要としない自給自足型コンポーネントとしてイメージできる。そのため、ＯＯＰでは、コンピュータプログラムを、ほぼ自立したコンポーネントの集合としてとらえ、これはオブジェクトと呼ばれ、それぞれが特定のタスクに関する責任を有する。こうしたデータ、構造、及び手順を１コンポーネント又はモジュールにパッケージングする概念は、カプセル化と呼ばれる。
【００１６】
一般に、ＯＯＰコンポーネントは再使用可能なソフトウェアモジュールであり、オブジェクトモデルと一致するインタフェースを提示し、コンポーネント統合アーキテクチャを通じてランタイム時にアクセスされる。コンポーネント統合アーキテクチャは、異なる処理空間にあるソフトウェアモジュールが、互いの能力又は機能を利用することを可能にする一連のアーキテクチャメカニズムである。これは一般に、このアーキテクチャを構築する共通コンポーネントオブジェクトモデルを仮定することで実行される。
【００１７】
この点において、オブジェクトとオブジェクトのクラスとを区別することには価値がある。オブジェクトは、オブジェクトのクラスの単一のインスタンスであり、単にクラスと呼ばれる場合が多い。オブジェクトのクラスは、青写真と考えることが可能であり、ここから多くのオブジェクトを形成することができる。
【００１８】
ＯＯＰによって、プログラマは、別のオブジェクトの一部であるオブジェクトを作成することができる。例えば、ピストンエンジンを表すオブジェクトは、ピストンを表すオブジェクトと複合関係を有すると言える。実際には、ピストンエンジンは、ピストンと、バルブと、他の多くのコンポーネントとを備え、ピストンがピストンエンジンの要素であるという事実は、ＯＯＰにおいて、２つのオブジェクトによって、論理的及び意味的に表すことができる。
【００１９】
ＯＯＰでは、他のオブジェクトに「ぶら下がる」オブジェクトを作成することもできる。２つのオブジェクトがあり、一方はピストンエンジンを表し、他方はピストンがセラミック製であるピストンエンジンを表す場合、２つのオブジェクトの間の関係は複合関係ではない。セラミックピストンエンジンは、ピストンエンジンを構成していない。むしろ単に、ピストンエンジンよりも１つ多くの制限、つまりピストンがセラミック製であるという制限を有するピストンエンジンの一種である。この場合、セラミックピストンエンジンを表すオブジェクトは派生オブジェクトと呼ばれ、ピストンエンジンを表すオブジェクトのあらゆる態様を継承し、更なる制限又は詳細が加わっている。セラミックピストンエンジンを表すオブジェクトは、ピストンエンジンを表すオブジェクトに「ぶら下がって」いる。こうしたオブジェクトの間の関係は継承と呼ばれる。
【００２０】
セラミックピストンエンジンを表すオブジェクト又はクラスが、ピストンエンジンを表すオブジェクトのあらゆる態様を継承する時、これはピストンエンジンクラスにおいて定められら標準的なピストンの熱特性を継承する。しかしながら、セラミックピストンエンジンオブジェクトは、金属製ピストンに関連するものとは通常異なる、セラミック固有熱特性をオーバライドする。オリジナルをスキップして、セラミックピストンに関連する新しい関数を使用する。異なる種類のピストンエンジンは異なる特性を有するが、ピストンエンジンに関連する同じ基本関数を有する可能性がある（例えば、エンジン内のピストンの数、点火順序、潤滑等）。任意のピストンエンジンオブジェクトにおいて、こうしたそれぞれの関数にアクセスするために、プログラマは同じ関数を同じ名前で呼び出すが、それぞれのタイプのピストンエンジンは、同じ名前の陰に異なる／オーバライドされる関数の実施を有する可能性がある。異なる関数の実施を同じ名前の陰に隠すこうした能力は多形性と呼ばれ、これによりオブジェクト間の通信は大幅に簡素化される。
【００２１】
複合関係、カプセル化、継承、及び多形性の概念により、オブジェクトは実世界のほとんどあらゆるものを表すことが可能である。実際には、私達が有する現実の論理的な認識は、オブジェクト指向ソフトウェアにおいてオブジェクトとなることが可能なものの種類を決定することに関する唯一の制限となる。いくつかの代表的なカテゴリは次の通りである、
●オブジェクトは、交通量シミュレーションの自動車、回路設計プログラムの電気コンポーネント、経済モデルの国、又は航空管制プログラムの飛行機といった物理的な物を表すことができる。
●オブジェクトは、ウィンドウ、メニュー、又はグラフィックオブジェクトといったコンピュータユーザ環境の要素を表すことができる。
●オブジェクトは、個人ファイル又は都市の緯度及び経度の表といった明細表を表すことができる。
●オブジェクトは、時間、角度、及び複素数、又は平面の点といったユーザ定義データタイプを表すことができる。
【００２２】
ほぼすべての論理的に分離可能な内容を表すオブジェクトの非常に大きな能力を有するため、ＯＯＰによって、ソフトウェア開発者は、現実の一部の態様のモデルであるコンピュータプログラムを設計及び実施することが可能となり、その現実は物理的な実体、プロセス、システム、又は合成物であっても構わない。オブジェクトはいかなるもので表すことが可能であるため、ソフトウェア開発者は、将来の大きなソフトウェアプロジェクトにおいてコンポーネントとして使用することが可能なオブジェクトを作成できる。
【００２３】
新しいソフトウェアプログラムの９０％が、以前から存在する再使用可能なオブジェクトから作られた、証明済みで既存のコンポーネントから構成される場合、新しいソフトウェアプロジェクトの残りの１０％のみを最初から書き、テストする必要がある。９０％は、広範にテストされた再使用可能オブジェクトの評価に由来するため、エラーが発生する可能性のある領域はプログラムの１０％である。その結果、ＯＯＰにより、ソフトウェア開発者は、他の既に構築されたオブジェクトからオブジェクトを構築することができる。
【００２４】
このプロセスは、アセンブリ及びサブアセンブリから構築される複雑な機械と良く似ている。そのため、ＯＯＰ技術では、オブジェクトとして開発者が利用可能な既存のコンポーネントからソフトウェアが構築される点において、ソフトウェアエンジニアはハードウェアエンジニアに近い存在となる。こうしたすべてが１つにまとまり、ソフトウェアの品質改善、及び開発速度の増加につながる。
【００２５】
プログラミング言語は、カプセル化、継承、多形性、及び複合関係といったＯＯＰの原理を完全にサポートし始めている。Ｃ＋＋言語の登場により、多くの市販ソフトウェア開発者はＯＯＰを採用した。Ｃ＋＋は、高速な機械実行可能コードを提供するＯＯＰ言語である。更に、Ｃ＋＋は、市販アプリケーションとシステムプログラミングプロジェクトとの両方に適している。今のところ、Ｃ＋＋は多くのＯＯＰプログラマの中で最も人気の高い選択肢であるが、Ｓｍａｌｌｔａｌｋ、コモンリスプオブジェクトシステム（ＣＬＯＳ）、及びＥｉｆｆｅｌといったその他の多数のＯＯＰ言語が存在する。加えて、ＯＯＰ機能は、Ｐａｓｃａｌ等の更に伝統的で人気の高いプログラミング言語にも追加されている。
【００２６】
オブジェクトクラスの利点は以下のようにまとめることができる。
●オブジェクトとそれに対応するクラスとは、複雑なプログラミング問題を多くの小さく単純な問題に分割する。
●カプセル化は、互いに通信可能な小さく独立したオブジェクトへのデータの編成を通じて、データ抽象化を強制する。カプセル化は、オブジェクト内のデータを予想外のダメージから保護するが、オブジェクトのメンバ関数及び構造を呼び出すことで、他のオブジェクトがそのデータと対話することを可能にする。
●サブクラシング及び継承により、システム内で利用可能な標準クラスから新しい種類のオブジェクトを派生させることを通じて、オブジェクトの拡張及び修正が可能となる。したがって、最初から始める必要なく、新しい機能が作成される。
●多形性及び多重継承により、複数のプログラマは、多くの異なるクラスの特性を混合及び一致させ、依然として予測可能な形で関連するオブジェクトと協調することが可能な特別なオブジェクトを作成できる。
●クラス継承及びコンテインメント継承が、実世界のオブジェクトとそれらの間の関係とのモデリングに関する柔軟なメカニズムを提供する。
●再使用可能クラスのライブラリは、多くの状況で有効であるが、いくつかの制限も有する。例えば、以下の通りである。
●複雑性。複雑なシステムにおいて、関連するクラスのクラス継承は、数十又は数百のクラスにより、極めて紛らわしくなる可能性がある。
●制御フロー。クラスライブラリを利用して書かれたプログラムは、依然として制御フローに責任を有する（つまり、特定のライブラリから作成されたすべてのオブジェクトの間の対話を制御する必要がある）。プログラマは、どの種類のオブジェクトに関して、どのタイミングで、どの関数を呼び出すかを判断する必要がある。
●作業の重複。クラスライブラリによって、プログラマは多くのコードの小さな断片を使用及び再使用できるが、それぞれのプログラマはこうした断片を異なる方法で組み合わせる。二人のプログラマは、同じクラスライブラリのセットを使用して、正確に同じことを行う２つのプログラムを書くことができるが、これらの内部構造（つまり設計）はまったく異なる可能性があり、これはそれぞれのプログラマが途中で行った多数の小さな判断によって決まる。必然的に、同様のコードの断片は、わずかに異なる方法で同様の事柄を行うことになり、行うべき協調動作を行わない。
【００２７】
クラスライブラリは非常に柔軟である。プログラムが複雑になるにつれ、更に多くのプログラマは基本的な問題に対する基本的なソリューションを何度も再発明することを強いられる。比較的新しいクラスライブラリの概念の拡張は、クラスライブラリのフレームワークを有することである。このフレームワークは更に複雑で、小規模なパターンと、特定のアプリケーション領域での共通要件及び設計を実施する大きなメカニズムとを記録した共同クラスの大きな集合で構成される。これは最初、メニュー、ウィンドウ、ダイアログボックス、及びその他のパーソナルコンピュータ用の標準ユーザインタフェース要素を表示することに伴う雑用から、フリーアプリケーションのプログラマによって開発された。
【００２８】
フレームワークは更に、自分の書いたコードと他人の書いたコードとの対話に関するプログラマの考え方の変化を表す。手続き型プログラミングの初期に、プログラマは、特定のタスクを実行するために、オペレーティングシステムが提供するライブラリを呼び出したが、基本的には、プログラムは最初から最後まで実行され、プログラマのみが制御フローに責任を有した。これは、給与小切手を印刷すること、数表を計算すること、又は１つの形のみで実行されるプログラムのその他の問題を解決することには適していた。
【００２９】
グラフィカルユーザインタフェースの開発は、こうした手続き的プログラミングの仕組みを完全に覆し始めた。こうしたインタフェースにより、ユーザは、プログラムロジックではなく、プログラムを駆動し、一定の行動が実行されるべき時期を判断できるようになる。現在、ほとんどのパーソナルコンピュータソフトウェアでは、マウス、キーボード、及びその他の外部イベントのソースをモニタするイベントループによって、これを達成し、ユーザが実行した行動に従ってプログラマのコードの該当する部分を呼び出す。プログラマは、もはやイベントが発生する順番を決定する必要はない。代わりに、プログラムは別個の断片に区分され、これは予測できない時期に予測できない順序で呼び出される。このようにして制御をユーザに委ねることで、開発者は、より使いやすいプログラムを作成する。にもかかわらず、開発者によって書かれたプログラムの個々の断片は、依然として特定のタスクを達成するためにオペレーティングシステムが提供するライブラリを呼び出し、プログラマは依然として、イベントループに呼び出された後のそれぞれの断片内での制御フローを決定する必要がある。アプリケーションコードは依然としてシステムの「頂上に居座って」いる。
【００３０】
イベントループプログラムであっても、プログラマは、すべてのアプリケーション毎に個別に書く必要がない多数のコードを書く必要がある。アプリケーションフレームワークの概念は、イベントループの概念を更に進める。基本メニュー、ウィンドウ、及びダイアログボックスを構築し、その後これらをすべて一緒に動作させるためのあらゆるナット及びボルトに対処する代わりに、アプリケーションフレームワークを使用するプログラマは最初に、アプリケーションコードと基本ユーザインタフェースを適所に配置する。その後、フレームワークの一般的な能力を、意図するアプリケーションの特定の能力と置き換えることで、そこから構築を行っていく。
【００３１】
アプリケーションフレームワークは、プログラマが最初から書く必要のあるコードの総量を減少させる。しかしながら、フレームワークは実際のところ、ウィンドウの表示、コピー及びペーストのサポート、その他を行う一般的なアプリケーションであるため、プログラマはイベントループプログラムで許されるよりも大きな度合いの制御を放棄することもできる。フレームワークコードは、ほとんどすべてのイベントハンドリング及び制御フローを管理し、プログラマのコードは、フレームワークが必要とする時のみ（例えば、独自のデータ構造を作成又は操作するために）呼び出される。
【００３２】
フレームワークプログラムを書くプログラマは、制御をユーザに委ねる（イベントループプログラムの場合も同じ）だけでなく、プログラム内の詳細な制御フローもフレームワークに委ねる。このアプローチにより、興味深い方法で共に動作する更に複雑なシステムの作成が可能となり、同様の問題のために何度も繰り返し作成されたカスタムコードを有する個別のプログラムとは対照的である。
【００３３】
したがって、上で説明したように、フレームワークは基本的には、一定の問題領域に関する再使用可能な設計ソリューションを形作る協同クラスの集合である。通常は、（例えばメニュー及びウィンドウに関する）デフォルトの行動を提供するオブジェクトを含み、プログラマは、デフォルト行動の一部を継承させ、フレームワークが適切な時期にアプリケーションコードを呼び出すように、その他の行動をオーバライドすることで、これを使用する。
【００３４】
フレームワークとクラスライブラリとの間には主に３種類の相違点がある。
●行動対プロトコル。クラスライブラリは基本的には、プログラムにおいて個々の行動が求められる時に呼び出すことが可能な行動の集合である。一方、フレームワークは、行動だけでなく、行動を統合可能な方法を管理するプロトコル又は規則セットを提供し、これにはプログラマが提供するはずのものに対するフレームワークが提供するものに関する規則が含まれる。
●呼び出し対オーバライド。クラスライブラリでは、コードによりプログラマがオブジェクトのインスタンスを作成し、メンバ関数を呼び出す。フレームワークにより、同じようにオブジェクトのインスタンスを作成し、呼び出すことは可能だが（つまり、フレームワークをクラスライブラリとして扱う）、フレームワークの再使用可能設計の大きな利点を利用し、プログラマは通常、オーバライドし、フレームワークによって呼び出されるコードを書く。フレームワークは、オブジェクト内での制御フローを管理する。プログラムを書くことには、様々な断片がどのように動作すべきかを指定することではなく、フレームワークによって呼び出されるソフトウェアの様々な断片の中で責任を区分することが含まれる。
●実施対設計。クラスライブラリでは、プログラマは実施のみを再使用するが、フレームワークでは設計を再使用する。フレームワークは、関連プログラムのファミリ又はソフトウェアの断片が動作する方法を具現化する。これは一定の領域の様々な特定の問題に適合可能な一般的な設計ソリューションを表す。例えば、単一のフレームワークはユーザインタフェースが動作する方法を具現化可能であり、ただし、同じフレームワークで作成された２種類のユーザインタフェースは、まったく異なるインタフェースの問題を解決する可能性がある。
【００３５】
したがって、様々な問題及びプログラミングタスクに対するソリューションのためのフレームワークの開発を通じて、ソフトウェアの設計及び開発作業における大きな削減が達成できる。本発明の好適な実施形態では、HyperText Markup Language（ＨＴＭＬ）を利用して、クライアントとＮｅｗｃｏとの間で媒体を輸送する汎用の安全な通信プロトコルと共に、ドキュメントをインターネット上で実施する。ＨＴＴＰ又はその他のプロトコルは、過度の実験を行うことなく、容易にＨＴＭＬの代用とすることができる。こうした製品の情報は、Ｔ・バーナーズ＝リー、Ｄ・コノリの「ＲＦＣ１８６６：Hypertext Markup Language−２．０」（１９９５年１１月）、及びＲ・フィールディング、Ｈ・フリスティック、Ｔ・バーナーズ＝リー、Ｊ・ゲティス、及びＪ・Ｃ・モグルの「Hypertext Transfer Protocol-HTTP/1.1:HTTP Working Group Internet Draft」（１９９６年５月２日）において入手できる。ＨＴＭＬは、１つのフォーマットから他のフォーマットへ移動可能なハイパーテキストドキュメントを作成するのに使用される単純なデータフォーマットである。ＨＴＭＬドキュメントは、広範囲の領域からの情報を表すのに最適な一般的なセマンティクスを有するＳＧＭＬドキュメントである。ＨＴＭＬは、１９９０年以降、ワールドワイドウェッブグローバル情報事業によって使用されている。ＨＴＭＬは、ＩＳＯ規格８８７９：１９８６情報処理テキスト及びオフィスシステム、Standard Generalized Markup Language（ＳＧＭＬ）のアプリケーションである。
【００３６】
現在まで、Ｗｅｂ開発ツールは、クライアントからサーバまでの範囲に渡り、既存のコンピューティングリソースと相互運用する動的Ｗｅｂアプリケーションを作成する能力において制限されている。最近まで、ＨＴＭＬは、Ｗｅｂベースのソリューションの開発において使用される支配的な技術だった。しかしながら、ＨＴＭＬは以下の領域において不適切であることが明らかにされている。
●低い性能。
●限られたユーザインタフェース能力。
●静的Ｗｅｂページのみを作成可能。
●既存のアプリケーション及びデータとの相互運用性の欠如。
●基準化できないこと。
【００３７】
サンマイクロシステムズのＪａｖａ言語は、以下により、クライアント側の多くの問題を解決する。
●クライアント側の性能を改善すること。
●動的なリアルタイムＷｅｂアプリケーションの作成を可能にすること。
●幅広いユーザインタフェースコンポーネントを作成する能力を提供すること。
【００３８】
Ｊａｖａ(登録商標)によって、開発者は堅牢なユーザインタフェース（ＵＩ）コンポーネントを作成することができる。カスタム「ウィジェット」（例えば、リアルタイム株価表示機、アニメーションアイコン等）を作成可能であり、クライアント側の性能は改善される。ＨＴＭＬとは違い、Ｊａｖａ(登録商標)はクライアント側の妥当性確認の概念をサポートし、性能の改善のためにクライアントに適切な処理をオフロードする。動的なリアルタイムＷｅｂページが作成可能である。前記カスタムＵＩコンポーネントを使用することで、動的Ｗｅｂページも作成可能である。
【００３９】
サンのＪａｖａ言語は、「インターネットをプログラムする」ための業界で認められた言語として出現した。サンではＪａｖａ(登録商標)を、「シンプルで、オブジェクト指向で、分散型で、インタープリタ型で、堅牢で、安全で、アーキテクチャニュートラルで、ポータブルで、高性能で、マルチスレッドで、動的で、専門語準拠である汎用プログラミング言語」と定義している。Ｊａｖａ(登録商標)は、プラットフォーム独立Ｊａｖａアプレットの形態において、インターネットのためのプログラミングをサポートする。Ｊａｖａアプレットは、サンのＪａｖａアプリケーションプログラミングインタフェース（ＡＰＩ）に準拠した小さな特化したアプリケーションで、これにより開発者は、Ｗｅｂドキュメントに「インタラクティブコンテンツ」を追加することができる（例えば、単純なアニメーション、ページ装飾、基本的なゲーム）。アプレットは、サーバからクライアントへコードをコピーすることで、Ｊａｖａ互換ブラウザ（例えば、Netscape Navigator）内で実行される。言語の観点からは、Ｊａｖａ(登録商標)の中核機能セットはＣ＋＋に基づいている。サンのＪａｖａ(登録商標)に関する文献では、Ｊａｖａ(登録商標)は基本的に「Ｃ＋＋であり、更に動的なメソッドソリューションのためにＯｂｊｅｃｔｉｖｅＣの拡張子が付いている」と記載されている。
【００４０】
Ｊａｖａ(登録商標)と同様の機能を提供する別の技術は、マイクロソフトとＡｃｔｉｖｅＸテクノロジによって提供され、開発者及びＷｅｂデザイナに、インターネット及びパーソナルコンピュータ用の動的コンテンツを構築するのに必要な手段を与える。ＡｃｔｉｖｅＸは、アニメーションと、３Ｄバーチャルリアリティと、ビデオと、その他のマルチメディアコンテンツとを開発するツールを含む。このツールはインターネット規格を使用し、複数のプラットフォームで動作し、１００を超える企業によってサポートされている。このグループのビルディングブロックは、ＡｃｔｉｖｅＸコントロールと呼ばれる小さな高速のコンポーネントで、これにより開発者はソフトウェアの一部をHypertext Markup Language（ＨＴＭＬ）のページに埋め込むことができる。ＡｃｔｉｖｅＸコントロールは、様々なプログラミング言語と共に動作し、こうした言語にはMicrosoft Visual C++、 Borland Delphi、 Microsoft Visual Basicプログラミングシステムが含まれ、将来的には、マイクロソフトのＪａｖａ用開発ツール、コードネーム「Ｊａｋａｒｔａ」も含まれる。ＡｃｔｉｖｅＸテクノロジは更に、ＡｃｔｉｖｅＸサーバフレームワークを含み、これにより開発者はサーバアプリケーションを作成することが可能になる。当業者は、本発明を実施するために、過度の実験を行うことなく、ＡｃｔｉｖｅＸをＪａｖａ(登録商標)の代用とすることができると容易に認識する。
【００４１】
好適な実施形態によれば、個人が様々なソースからミーティングについての関連情報を検索するのを支援することで、来るべきミーティングのための個人の準備に責任を有するエージェントとして、バックグラウンドファインダ（ＢＦ）が実施される。ＢＦは対象となるミーティングを示す文字の形態で入力テキストを受領する。この入力テキストは、ミーティングの時間を含むカレンダプログラムによって、好適な実施形態に従って生成される。ミーティングの時間が近づくと、カレンダプログラムは対象イベントのテキストを取得するためにクエリを受け、その情報はエージェントへの入力として利用される。その後、エージェントは、入力ミーティングテキストをパースし、タイトル、ボディ、参加者、場所、時間等の様々なコンポーネントを抽出する。このシステムは、ミーティングテキストの特定のミーティングフィールドを特定するためにパターンマッチングも実行する。この情報は、Ｗｅｂ上の様々な情報源にクエリを行い、現在のミーティングについての関連する記事を取得してカレンダリングシステムに返送するために利用される。例えば、個人がネットスケープとマイクロソフトとの紛争に関して話し合うために、これら２社とのミーティングに出席する場合、この個人はカレンダリングシステムから、こうした初期情報を取得することになる。このシステムはその後テキストをパースし、ミーティングする企業が「ネットスケープ」及び「マイクロソフト」であり、トピックが「紛争」であることを認識する。その後、このシステムは、トピックについての関連情報をＷｅｂでクエリする。したがって、本発明の目的によれば、このシステムはカレンダリングシステムを更新し、最終的には、対象となるミーティングに関するユーザの準備をするために収集できる最高の情報をユーザに与える。好適な実施形態によれば、この情報はカレンダシステムに組み込まれたリンクからの選択により取得されたファイルに格納される。
【００４２】
プログラム構成：
好適な実施形態によるコンピュータプログラムは、５つの個別のモジュール、つまりBF.Main、BF.Parse、 Background Finder.Error、 BF.PatternMatching、及びBF.Searchによって構成される。更に、デバッグの目的でのみ使用されるユーザインタフェースを提供するfrmMainも存在する。好適な実施形態による実行可能なプログラムは、このユーザインタフェースによって決して実行されず、マイクロソフトのＷｉｎｓｏｃｋコントロールを通じてのみカレンダリングシステムに戻されるべきである。システムの好適な実施形態は、２種類のモードで実行され、これはカレンダリングシステムによってシステムに送られるコマンドラインの下で指定できる。このシステムは、シンプルモードで動作している時、キーワードクエリを実行し、外部のサーチエンジンに発信する。コンプレックスモードで実行される時、このシステムは、サーチエンジンに送信するクエリを形成する前にパターンマッチングを実行する。
【００４３】
データ構造：
好適な実施形態よるシステムは、３つのユーザ定義構造を利用する。
１．TMeetingRecord
２．TPatternElement
３．TPatternRecord
ユーザ定義構造TMeetingRecordは、単一のミーティングに関するあらゆる関連情報を格納するために使用される。この情報には、ユーザＩＤ、ミーティングの当初の説明、ミーティングのタイトル及びボディからのキーワードの抽出リスト等が含まれる。重要な注意点として、好適な実施形態によるシステムのインスタンスにつき、１つのみのミーティングレコードが作成される。これは、来るべきミーティングに関するサービスをおこなうためにシステムが生じる度に、１つのみのミーティングに関する情報を検索するタスクが割り当てられるためである。そのため、現在のミーティングに対応して作成されたミーティングレコードが調査される。ParseMeetingTextは、このミーティングレコードを占有させ、その後これはミーティングに関する情報を他の機能に提供するためにパースされる。GoPatternMatchが、特定のミーティングフィールドに任意の値を結びつけることが可能である場合、ミーティングレコード内の対応するエントリも更新される。括弧内で説明されるそれぞれのフィールドが付いたtMeetingRecordの構造を、好適な実施形態に従って、以下に提示する。
【００４４】
A.1.1.1.1.1  Public Type tMeetingRecord
sUserID As String  （Muninによって与えられるユーザＩＤ）
sTitleOrig As String  （Muninに送り返すために側に置く必要があるオリジナルのノンストップリステッドタイトル）
sTitleKW As String  （キーワードのみを有するストップリステッドタイトル）
sBodyKW As String  （キーワードのみを有するストップリステッドボディ）  sCompany() As String  （パターンマッチングを通じてタイトル又はボディにおいて特定される会社）
sTopic() As String  （パターンマッチングを通じてタイトル又はボディにおいて特定されるトピック）
sPeople() As String  （パターンマッチングを通じてタイトル又はボディにおいて特定される人間）
sWhen() As String  （パターンマッチングを通じてタイトル又はボディにおいて特定される時間）
sWhere() As String  （パターンマッチングを通じてタイトル又はボディにおいて特定される場所）
sLocation As String  （Muninによって渡される場所）
sTime As String  （Muninによって渡される時間）
sParticipants() As String  （Muninによって渡される従事する全参加者）
sMeetingText As String  （ユーザＩＤのないオリジナルのミーティングテキスト）
End Type
【００４５】
パターンマッチングにおいて利用されるそれぞれの個別パターンを保持するために作成される他の２つの構造が存在する。レコードtAPatternRecordは、パターンのすべてのコンポーネント／要素を含む配列である。タイプtAPatternElementは、パターン内の要素を表すストリングの配列である。それぞれの要素には多くの「代替物」が存在する可能性があるため、すべての代替物が何かを追跡するストリングの配列が必要となる。tAPatternElement及びtAPatternRecordの構造を、好適な実施形態に従って、以下に提示する。
【００４６】
Public Type tAPatternElement
elementArray() As String
End Type
Public Type tAPatternRecord
patternArray() tAPatternElement
End Type
【００４７】
共通ユーザ定義定数：
プログラムのそれぞれの宣言セクションでは多くの定数が定義されており、これは好適な実施形態によるシステムを維持するプロセスの一部として定期的な更新が必要な場合がある。この定数は、コードを維持するための更新として発生するシステムの動的な設定を可能にするためにアクセス可能である。
【００４８】
以下の表に含まれるのは、時折修正される可能性が最も高いと私が考えるそれぞれのモジュールからの定数のリストである。しかしながら、以下のリストに含まれないが、コード内で使用される他のコードも存在する。これは、こうしたリストに含まれない定数が、決して変更されないことを意味するものではない。変更される頻度が少ないことを意味するものである。
【００４９】
メインモジュール（BF.Main）について：
【００５０】
【表１】
0004294876.tif 000002
【００５１】
サーチモジュール（BF.Search）について：
【００５２】
【表２】
0004294876.tif 000003
【００５３】
パースモジュール（BF.Parse）について：
【００５４】
【表３】
0004294876.tif 000004
【００５５】
パターンマッチングモジュール（BFPatternMatch）について：このモジュールには、頻繁に更新する必要のある定数は存在しない。
【００５６】
一般的なプロセスフロー：
プロセスフローとそれぞれの間の関数の調整とは、図２乃至６に例示した５つのフローチャートによって最も上手く表すことができる。図２は、好適な実施形態による全体的なプロセスフローを表している。処理はチャートの最上部にある関数ブロック２００で開始され、これはプログラムがスタートした時に開始される。アプリケーションがスタートすると、関数ブロック２１０に示すように、コマンドラインがパースされ、適切なミーティングテキストが移動され、好適な実施形態によるバックグラウンドファインド動作のターゲットが開始される。関数ブロック２２０に示すように、ターゲットが決定された後、グローバルストップリストが生成される。その後、関数ブロック２３０に示すように、マッチング動作に利用されるすべてのパターンが生成される。その後、チャートをトレースすることにより、関数ブロック２００がGoBF２４０を呼び出し、これは特定のターゲットのサーチエンジンのために正しい検索クエリ情報をラップすることに関するロジック処理に責任を有する。例えば、関数ブロック２４０は関数ブロック２５０に続き、その後、関数ブロック２６０に示すようにGoPatternMatchを呼び出す。GoPatternMatchのプロセスフローを見るためには、「BFのパターンマッチングユニットに関するプロセスフロー」というタイトルの図にスワップする。
【００５７】
注意すべき重要な事柄の１つは、チャートの同じレベルで表された関数は、共通する親関数によって、左から右（上から下）に連続して呼び出されることである。例えば、Main２００は、ProcessCommandLine２１０を呼び出し、その後CreateStopList２２０を呼び出し、その後CreatePattern２３０を呼び出し、その後GoBackgroundFinder２４０を呼び出す。図３乃至６はそれぞれ、プログラム全体、パーシングユニット、パターンマッチングユニット、及びサーチユニットに関するロジックを詳細に表している。図６は、BackgroundFinderを通じた重要な情報のデータフローを決定するロジックを詳細に表しており、こうした情報の作成及び処理に責任を有する関数を示している。
【００５８】
シンプルクエリモード下での詳細なサーチアーキテクチャ：
Ａｌｔａ  Ｖｉｓｔａの検索：
【００５９】
（図２の関数ブロック２７０）
Ａｌｔａ  Ｖｉｓｔａサーチエンジンは、図２の関数ブロック２７０に示すように、識別情報を利用して、現在のミーティングに関連するトピックに関する全般情報を戻す。好適な実施形態によるシステムは、オリジナルミーティングテキストのタイトル部分からすべてのキーワードを取り出し、Ａｌｔａ  Ｖｉｓｔａに対して送る高度なクエリを構築する。このキーワードは、クエリにおいて論理的に統合される。この結果も、同じキーワードのセットに基づいてランク付けされる。検索したい項目に関して、データ制限又は発行者の基準を促進できることを当業者は容易に理解する。上位ランクの記事のセットは、好適な実施形態によるカレンダリングシステムに戻される。
【００６０】
ＮＥＷＳ  ＰＡＧＥ：
（図２の関数ブロック２７５）
Ｎｅｗｓ  Ｐａｇｅ検索システムは、ターゲットミーティングに関する最新のニューストピックを与えることに責任を有する。このシステムは、オリジナルミーティングテキストのタイトル部分からすべてのキーワードを取り出し、Ｎｅｗｓ  Ｐａｇｅサーチエンジンに対して送るクエリを構築する。このキーワードは、クエリにおいて論理的に統合される。最近発行された項目のみが検索される。Ｎｅｗｓ  Ｐａｇｅ検索システムは、ユーザの好みに応じてユーザが設定可能なデータ制限基準を提供する。上位ランクの記事はカレンダリングシステムに戻される。
【００６１】
図３は、好適な実施形態のユーザプロフィールデータモデルである。処理は関数ブロック３００で開始され、これはメインモジュールからプログラムを呼び出すことに責任を有する。その後、関数ブロック３１０において、ラッパ関数が呼び出され、関数ブロック３２０でのキーワード抽出処理が準備される。キーワードが抽出された後、処理フローは関数ブロック３３０に続き、区切り文字が正確に配置されているかどうかが判断される。その後、関数ブロック３４０において、特定のストリング内のワード数が計算され、関数ブロック３５０において、特定のフィールドの区切り文字と、ミーティングテキストからの特定のフィールドとが検索される。その後、関数ブロック３８０において、ストリングの区切り文字が再度チェックされ、適切に配置されていることが確認される。最後に、関数ブロック３６０において、メッセージのタイトル及びボディからのそれぞれのワードの抽出が一度に１ワードずつ実行され、入力語句において次に最も近いワード区切り文字を見つける関数ブロック３６２と、ワードから不要なデータを取り去る関数ブロック３６４と、ワードがストップリストにあるかどうかを判断し、ワードがストップリストにある場合はエラーを戻す関数ブロック３６６とのロジックが利用される。
【００６２】
好適な実施形態によるパターンマッチング：
シンプルサーチ方法に関連する制限には以下が含まれる。
【００６３】
１．ミーティングテキストからキーワードのセットを抽出するために、不要なワードのストップリストに頼ることから、ストップリストがどのくらい包括的かによって制限される。ミーティングテキストのどの部分を捨てるべきかを考えるよりも、ミーティングテキストのどの部分が必要かに注目するべきである。
【００６４】
２．好適な実施形態によるシンプルサーチ方法では、ミーティングタイトルからのキーワードのみを使用して、Ａｌｔａ  Ｖｉｓｔａ及びＮｅｗｓ  Ｐａｇｅに送るクエリを形成する。これは、クエリの代替情報源、つまりミーティング通知のボディを無視している。ミーティングボディからのキーワードをクエリの形成に含めることは不可能であり、これは意味のある結果を得られないほど長く複雑なクエリが生じることが多いためである。
【００６５】
３．それぞれのキーワードが何を意味するかを伝える方法は存在しない。例えば、２つのキーワードとして「アンディ」と「グローブ」とが抽出される可能性がある。しかしながら、シンプルサーチでは、「アンディ・グローブ」が実際は人名であることを知る方法はない。「アンディ・グローブ」が人名であることを何らかの方法で理知的に推測できる可能性を想像せよ。彼が雇用されている場所及び現在住んでいる場所といった情報。
【００６６】
４．まとめると、不必要なワードをパースして除外するためにストップリストのみに頼っていることから、「情報過多」に悩まされている。
【００６７】
好適な実施形態に従って、パターンマッチングはこうした制限を克服する：
ここでは、好適な実施形態に従って、上に対応するそれぞれの問題にパターンマッチングがどのように対処できるかを示す。
【００６８】
１．パターンマッチングを行うことで、ミーティングテキストの必要な部分のみを一致させ、この部分を抽出する。
【００６９】
２．ミーティングボディに関してパターンマッチングを実行し、ミーティングボディから必要な部分のみを抽出すること。これにより、ミーティングボディは完全に無駄なものにはならない。
【００７０】
３．パターンマッチングは、指定したテンプレートのセットに基づき、人名、社名、及びその他の項目をミーティングテキストから特定することを可能にする。
【００７１】
４．まとめると、パターンマッチングにより、情報過多に悩まされることがなくなる。当然ながら、大きな問題は、パターンマッチングがどの程度上手く動作するかである。人工知能処理のみに頼る場合、１００％のヒット率にはならない。提示された全社名の約２０％を特定することが可能である。
【００７２】
パターン：
好適な実施形態のコンテキストにおけるパターンは、ミーティングテキスト内で探している語句の構造を指定するテンプレートである。パターンは誰かのミーティングテキストの現れる高い可能性を有する語句のテンプレートであるため、好適な実施形態によってサポートされるパターンは選択される。例えば、カレンダにミーティングを入力する時、多くの人は「Meet with Bob Dutton from Stanford University next Tuesday（来週の火曜日にスタンフォード大学のボブ・ダットンと会う）」といった事柄を書き込むことになる。この場合、共通パターンは、ワード「with」の後に人名（この例ではBob Dutton）が続き、その後にワード「from」が続き、最後は団体名（この例ではStanford University）で終わるといったものになる。
【００７３】
パターンマッチングの用語：
パターンマッチングに関連する共通用語を以下に提示する。
◆パターン：パターンとは、ミーティングテキストを結びつけたい語句の構造を指定するテンプレートである。これはサブユニットを含む。
【００７４】
◆要素：パターンは多くのサブユニットを含むことができる。こうしたサブユニットは要素と呼ばれる。例えば、「with $PEOPLE$ from $COMPANY$」というパターンにおいては、「with」、「$PEOPLE$」、「from」、「$COMPANY$」がすべての要素である。
【００７５】
◆プレースホルダ：プレースホルダは、値を結びつける必要がある特別な種類の要素である。上の例を使うと、「$PEOPLE$」はプレースホルダである。
【００７６】
◆インジケータ：インジケータは、ミーティングテキスト内で見つける必要があるが、値を結びつける必要がない別の種類の要素である。特定のパターンにおいて、１つ以上のインジケータを探す場合が多い。そのためインジケータは「アトミック」タイプではない。
【００７７】
◆置換文字：置換文字は、互いにすべて同義語であるインジケータのセットである。入力において、これらのいずれかを見つけるのは良いことである。
【００７８】
それぞれのミーティングに関して特定される５つのフィールドが存在する。
◆会社（$COMPANY$）
◆人物（$PEOPLE$）
◆場所（$LOCATION$）
◆時間（$TIME$）
◆トピック（$TOPIC_UPPER$）又は（$TOPIC_All$）
括弧内は、コード内で対応するミーティングフィールドを表すものとして私が使用したプレースホルダである。
【００７９】
それぞれのプレースホルダは以下の意味を有する。
◆$COMPANY$：大文字で始まるワードのストリングを結びつける（例えば、Meet with Joe Carter of <Andersen Consulting>）。
【００８０】
◆$PEOPLE$：「，」、「ａｎｄ」、又は「＆」によって結合される可能性がある大文字で始まる２つのワードのストリングの連続を結びつける（例えば、Meet with <Joe Carter> of Andersen Consulting、Meet with <Joe Carter and Luke Hughes> of Andersen Consulting）。
【００８１】
◆$LOCATION$：大文字で始まるワードのストリングを結びつける（例えば、Meet Susan at<Palo Alto Square>）。
【００８２】
◆$TIME$：フォーマット＃：＃＃を含むストリングを結びつける（例えば、Dinner at <6:30pm>）。
【００８３】
◆$TOPIC_UPPER$：トピックに関する大文字で始まるワードのストリングを結びつける（例えば<Stanford Engineering Recruting> Meeting to talk about new hires）。
【００８４】
◆$TOPIC_All$：大文字で始まるかどうかにまったく関係なく、ワードのストリングを結びつける（例えば、Meet to talk about <ubiquitous computing>）。
【００８５】
以下はＢＦによってサポートされるすべてのパターンを示す表である。それぞれのパターンはパターングループに属する。パターングループ内のすべてのパターンは、同様のフォーマットを共有し、どのインジケータが置換文字として使用されるかという点においてのみ、それぞれが異なる。注意点として、灰色のパターンはコードにおいてもコメントされている。ＢＦは、こうしたパターンをサポートする能力を有するが、私達はこれらのパターンをマッチングさせることがこの時点で不可欠ではないと判断した。
【００８６】
【表４】
0004294876.tif 000005
0004294876.tif 000006
【００８７】
図４は、好適な実施形態によるパターンマッチングの詳細なフローチャートである。処理は関数ブロック４００で開始され、ここでメインプログラムがパターンマッチングアプリケーションを呼び出し、制御を関数ブロック４１０に渡し、パターンマッチング処理を開始する。次に、関数ブロック４２０において、ラッパ関数がループを続け、関数ブロック４３０に示すように、テキストストリングの一部をパターンに結びつけることができるかどうかを判断することを含め、それぞれのパターンを処理する。その後、関数ブロック４４０において、存在する場合、様々なプレースホルダが値に結びつけられ、関数ブロック４４１において、句読点によって分離された名前のリストが結びつけられ、関数ブロック４４２において、大文字で始まる２つのワードをフルネームとして見つけ、大文字で始まるかどうかを判断するためにワード後にあるスペース後の次の文字を捕らえることでフルネームが処理される。次に、関数ブロック４４３において、時間がストリングから適切な方法でパースされ、関数ブロック４４４においてブランクスペース後の次のワードがパースされる。次に、関数ブロック４４５において、会社、トピック、又は場所といった大文字で始まる連続する語句が結びつけられ、関数ブロック４４６において、好適な実施形態による更なる処理のために、ブランク後の次のワードが取得される。マッチミーティングフィールド処理に続いて、パターンの先頭であるインジケータの位置を特定するために関数ブロック４５０が利用され、ブランク後の次のワードが関数ブロック４５２に示すように取得され、関数ブロック４５４に示すように、このワードがチェックされ、インジケータかどうかが判断される。次に、関数ブロック４６０において、パターンの終わりにないインジケータの位置を特定するためにストリングがパースされ、改行又はキャリッジリターンに続くものといった不必要な余白後の次のワードが関数ブロック４６２に示すように処理され、関数ブロック４６４に示すように、このワードが分析され、インジケータかどうかが判断される。次に、関数ブロック４７０において、次のストリングの処理に備えるために、一時レコードがヌルセットにリセットされ、関数ブロック４８０において、ミーティングレコードが更新され、関数ブロック４８２において、チェックが実行され、ミーティングレコードをパースする前に、ミーティングレコードにエントリが既に行われたかどうかが判断される。
【００８８】
特定済みミーティングフィールドの使用：
重要と考えるミーティングテキスト内のフィールドを特定したため、これに対して行える事柄は数多く存在する。最も重要なパターンマッチングの応用の１つは、当然ながら、最終的にはＡｌｔａ  Ｖｉｓｔａ及びＮｅｗｓ  Ｐａｇｅに発信する、私達が構築したクエリを改善することである。ＢＦに追加することが可能なパターンマッチングの結果を利用したオプション及び強化は他にも数多く存在する。こうした他のオプションについては、次のセクションで説明する。本セクションの目的は、優れたサーチ結果の取得を支援するために、パターンマッチングで得られた結果をどのように使用できるかに関する十分な理解を読者に与えることである。
【００８９】
図５は、クエリを準備し、インターネットから情報を取得するための好適な実施形態による詳細な処理のフローチャートである。処理は、関数ブロック５００で開始され、Ｗｅｂサーチエンジンを利用したインターネットサーチに備えるラッパ関数を処理するために、直ちに関数ブロック５１０へと続く。このサーチが、Ａｌｔａ  Ｖｉｓｔａサーチエンジンを利用する場合は、関数ブロック５３０において、システムはミーティングレコードから情報を取り出し、関数ブロック５４０乃至５６０において、このサーチエンジンに発信するクエリを形成する。このサーチが、ＮｅｗｓＰａｇｅサーチエンジンを利用する場合は、関数ブロック５２０において、システムはミーティングレコードから情報を取り出し、関数ブロック５２１乃至５２８においてクエリを形成する。
【００９０】
Ａｌｔａ  Ｖｉｓｔａサーチエンジン：
Ａｌｔａ  Ｖｉｓｔａサーチエンジンの長所は、強化された柔軟性を提供することである。高度なクエリ方法を使用することで、あらゆる種類のブールクエリを構築し、望み通りのサーチのランク付けが可能となる。しかしながら、Ａｌｔａ  Ｖｉｓｔａの最大の欠点の１つは、大きなクエリを取り扱うのに優れておらず、無関係な結果を返す可能性が高くなることである。ミーティングテキスト内でトピック及び会社を特定可能である場合、優れた結果が期待される非常に短いが包括的なクエリを形成することができる。更に、発見したトピックにも注目する必要がある。特にユーザが会社について既によく知っており、その会社と数多くのミーティングを行っている場合、会社に関する情報を見つけることは、そのユーザにとって大きなメリットではない可能性がある。こうしたユーザがリサーチしたいのはトピックについてである。
【００９１】
Ｎｅｗｓ  Ｐａｇｅサーチエンジン：
Ｎｅｗｓ  Ｐａｇｅサーチエンジンの長所は、有効な社名を与えることが可能である場合、最新のニュースのサーチにおいて優れた仕事を行うことである。そのため、ニュースページＷｅｂサイトにクエリを発信する時は、特定可能なあらゆる社名を送り、社名が発見できない場合のみ、発見したトピックをクエリの形成に使用する。どちらも発見できない場合、サーチは実行されない。Ａｌｔａ  Ｖｉｓｔａに発信するクエリの形成に利用されるアルゴリズムは図７に例示されている。Ｎｅｗｓ  Ｐａｇｅに発信するのクエリの形成に使用するアルゴリズムは図８に例示されている。
【００９２】
以下の表では、好適な実施形態によるそれぞれの関数を詳細に説明している。関数が登場する順番は、可能な限りプロセスフローに似せている。関数が数回呼び出される状況が存在する時、この関数は、この関数を呼び出す第一の関数の後に記述され、その説明は、この関数を呼び出すその後の関数の後には繰り返されない。
【００９３】
【表５】
0004294876.tif 000007
0004294876.tif 000008
0004294876.tif 000009
0004294876.tif 000010
0004294876.tif 000011
0004294876.tif 000012
0004294876.tif 000013
0004294876.tif 000014
0004294876.tif 000015
0004294876.tif 000016
0004294876.tif 000017
0004294876.tif 000018
0004294876.tif 000019
【００９４】
図６は、好適な実施形態に従った、Ａｌｔａ  Ｖｉｓｔａ及びＮｅｗｓ  Ｐａｇｅサーチエンジンに対するサーチの準備及び発信に利用する実際のコードのフローチャートである。処理は関数ブロック６１０で開始され、ここでコマンドラインが利用され、特定のカレンダ情報によってカレンダエントリが更新される。このメッセージは関数ブロック６２０に従って次に掲示され、関数ブロック６３０に従って現在のミーティング情報を格納するためにミーティングレコードが作成される。次に、関数ブロック６４０において、クエリがＡｌｔａ  Ｖｉｓｔａサーチエンジンに発信され、関数ブロック６５０において、クエリがＮｅｗｓ  Ｐａｇｅサーチエンジンに発信される。サーチエンジンからメッセージが戻されると、これは関数ブロック６６０に示すように結果データ構造に格納され、この情報は関数ブロック６７０の記述のように、処理され、ミーティングの準備で使用するファイル内においてサマリ形式で格納される。
【００９５】
図７は、好適な実施形態によるクエリの作成に関する詳細を提示している。処理は関数ブロック７１０で開始され、ここでミーティングレコードがパースされ、会社、人物、トピック、場所、及び時間である可能性のあるものが取得される。その後、関数ブロック７２０において、少なくとも１つのトピックが特定され、関数ブロック７３０において、少なくとも１つの社名が特定され、最後に関数ブロック７４０において、ユーザの最終的な消費のために、どのデータをファイルに送信するかについて判断がなされる。
【００９６】
図８は、図７で提示されたクエリのテーマのバリエーションである。ミーティングレコードは関数ブロック８００においてパースされ、会社が関数ブロック８２０において特定され、トピックが関数ブロック８３０において特定され、最後に関数ブロック８４０において、クエリの策定にトピック及び又は社名が利用される。
【００９７】
特定のユーザ要件のために様々な特定の特徴を追加する代替実施形態については以下で説明する。
【００９８】
パターンマッチングのターゲット率強化：
BFの性能を高めるためには、手続き「CreatePatterns」に、パターン／パターングループを追加する。パターンを宣言する既存のコードは、将来のパターンのテンプレートとして使用することができる。すべてが動的配列として格納されるため、カット及びペーストによってコードを再使用するのが便利である。値をプレースホルダに関連付けることに責任を有する関数BindName、 BindTime、 BindCompanyLocTopicは強化することができる。この強化は、結びつける値の数を増やすために、特定のミーティングフィールドを結びつける基準のセットを増やすことで実現される。例えば、BindTimeは現在、＃＃：＃＃又は＃：＃＃の形式のすべての値を受け入れて結びつける。結びつけることが可能な時間を増やすためには、更に美的な時間用語「o'clock」が後に続く数字１乃至１２を受け入れるようにすることができる。語彙に基づく認識アルゴリズムと、BFが行うそれぞれの推測に精度レートを割り当てることとにより、有効となる特定の閾値を満たす唯一の推測が可能になる。
【００９９】
パターンマッチングを通じてシステムがどの場所を特定したかに応じて、或いはミーティング場所としてユーザがどの場所を示したかに応じて、好適な実施形態によるシステムは、ランチ／ディナー／朝食というワードを検出した時には必ず、複数の優れたレストランを提案する。更に、会社ファインダのようなサイトを使用して、手元にあるものが本当に社名であることを確認可能であり、或いはパターンマッチングで社名が特定できない場合は、会社ファインダのＷｅｂサイトを「辞書」として使用し、大文字で始まる特定のワードが社名を表すかどうかを判断することができる。特定した会社の株価及び急報を表示することも可能である。
【０１００】
好適な実施形態による無線バーゲン特定：
図９は、従来の物理的な非Ｗｅｂ小売環境においてＷｅｂベースの比較ショッピングを可能にするために設計された装置及びソフトウェアのハードウェア及び論理制御フローを表したフロー図である。インターネットプロトコル能力を有する無線電話又は同様のハンドヘルド型無線装置９２０は、小型バーコードリーダ９１０（電話の内部又は短いケーブルで設置される）と統合され、書籍その他の製品９００の統一商品コード（ＵＰＣ）バーコードをスキャンするのに使用される。この無線装置９２０は、アンテナ９３０を介して、バーコードをポケットバーゲンファインダサービスモジュール（Ｗｅｂサーバで実行）９４０に送信し、これがバーコードを（書籍の場合は）国際標準図書番号又は（他の製品の場合は）適切な識別子に変換する。このサービスモジュールは、その後、適切なサードパーティの（複数の）Ｗｅｂサイトにコンタクトし、様々なＷｅｂサプライヤ９５０からの製品に関する価格、出荷、及び入手可能性の情報を見つける。この情報はフォーマットされ、ハンドヘルド型装置のスクリーンに表示される。ＩＰ無線電話その他のハンドヘルド型装置９２０は、メトリコムのＲicochet SE Wireless Modem等の無線モデムを利用する。この装置を利用することで、ユーザは、コーヒーショップでくつろぎながら、揺れ動いているラテを危険なほどキーボードの近くに置き、古びた小さなテーブルの上に乗ったポータブルコンピュータにより、電話回線による直接接続に匹敵する速さでインターネットにアクセスできる。
【０１０１】
８オンス（２２７ｇ）のRicochet SE Wireless Modemは、タバコのパックほどの大きさであり、セットアップは極めて単純で、付属のベルクロの部品によってこのモデムをポータブル機器の裏側に取り付け、ケーブルをシリアルポートに差し込み、短く太いアンテナを起こし、送信するだけである。ソフトウェアのセットアップも同様に容易であり、簡単なインストーラによって、Ricochetモデムドライバが追加され、接続アイコンがデスクトップに配置される。モデムの機能的な態様は、従来の電話モデムと同一である。
【０１０２】
当然ながら、無線性能には、従来のダイヤルアップ接続と同様の信頼性はない。サンフランシスコのいくつかの場所では、窓の近くにいる限り、強力な接続を得ることができた。しかし、ＣＮＥＴの総レンガ造りの本社内では、Ricochetはまったく接続できなかった。オンラインでつながっている時は、遅い速度へのゆっくりとした低下と共に２８．８ｋｂｐｓまでの性能が利用できる。しかし、遅い速度でも失望はなかった。代替方法――セルラモデムによる接続――に比べ、Ricochetは遥かに速く、信頼性があり、使用コストが少ない。当然ながら、このSE Wirelessはバッテリ電源である。このモデムの連続バッテリ寿命は１２時間までである。好適な実施形態によれば、ポータブルコンピュータのデュアル電池は、Ricochetの出力が弱まる前に切れる。
【０１０３】
したがって、この無線モデムを利用することで、ユーザは好適な実施形態に従って、Ｗｅｂサーバソフトウェア９４０を利用して、適切な製品９５０を特定し、次に、適切な装置の（複数の）キーを使用してサプライヤを選択し、注文を入れることができる。バーゲンファインダサービスモジュールは、その後、適切なサードパーティＷｅｂサプライヤ９６０により、注文を完了させる。
【０１０４】
ｍｙＳｉｔｅ！  パーソナルＷｅｂサイト及び意図価値ネットワークのプロトタイプ：
ｍｙＳｉｔｅ！は、好適な実施形態によるインパクトの強いインターネットベースのアプリケーションであり、買い手中心世界におけるパーソナルＷｅｂサイトを介して、それぞれの顧客にサービスを与え、パーソナライズされた体験を提供するというテーマに注目したものである。このサービスは顧客の意図−基本的な生活のニーズ又は広範なプランニングを要する判断と、財務プランニング、ヘルスケア、個人的及び職業的成長、家族生活、その他の問題といったいくつかの次元に渡る調整−を満足させることを中心に直観的に編成されている。それぞれのメンバーは自分自身のプロフィールを保有及び維持しており、これにより、自分自身を限定的にターゲットとするシステムにおいてコンテンツを作成及びブラウズすることが可能となる。製品又はサービスの要求を入力した時点から、支払いの完了まで、インテリジェントエージェントを利用して、リサーチが実施され、取引が実行され、アドバイスが提供される。高度なプロファイリング及びフィルタリングを使用することで、インテリジェントエージェントはユーザについて学び、提供するサービスを改善する。顧客の意図には、日常ロジスティックス管理（例えば、電子メール、カレンダ、連絡先、予定リスト、請求書の支払、ショッピング、及び旅行プランニング）と、新しいコミュニティへの移動（例えば、新しい生活場所を見つけること、家族の所有物を移動させること、旅行に出かけること及び保険担保を送ること、仕事及び個人の連絡先に通知すること、新しいコミュニティについて学ぶこと）とが含まれる。消費者の観点から、ｍｙＳｉｔｅ！は、ユーザが関連製品及びサービスにアクセスし、極めて容易かつ便利に日常のタスクを達成することが可能な中心的場所を提供する。
【０１０５】
ビジネスの観点から、ｍｙＳｉｔｅ！は、効果的に顧客を集め、サービスを提供し、保持するための付加価値のある革新的な方法を意味する。意図価値ネットワークにより、ユーザは、パーソナライズされたサイトに入り、学習するインテリジェントエージェントの支援により、ネットワーク参加者とシームレスに対話することができる。好適な実施形態による意図価値ネットワークは優れた価値を提供する。カスタマイズされた情報、アドバイス、及び製品に対する、１日２４時間、週７日のアクセスが提供される。この情報はパーソナライズされているため、それぞれのユーザは、必要なターゲットユーザとの関連性を保証するために高度にカスタマイズされたコンテンツを閲覧することになる。
【０１０６】
エゴセントリックインタフェース：
エゴセントリックインタフェースは、特定のユーザのニーズ、好み、及び現在のコンテキストを満足させるために作成されたユーザインタフェースである。これは、中央プロフィールデータベースに格納されたユーザの個人情報を利用して、インタフェースをカスタマイズする。ユーザは、セキュリティ許可をオンにし、インタフェース要素及びコンテンツに関する好みを設定することができる。エゴセントリックインタフェースに統合されるコンテンツは、ユーザについての関連情報によってカスタマイズされる。コンテンツを表示する時、エゴセントリックインタフェースには、コンテンツがどのようにユーザと関連するかを実証する形で、コンテンツとユーザとの間の関係が含まれる。例えば、ユーザが契約済みの来るべきスキー旅行に関する情報を表示する時、このインタフェースには、スキー旅行中に同じ地域にいる他の人物等、ユーザの個人カレンダ及び連絡先リストからのイベントに関する情報が含まれる。これは、個別のユーザがよく知っているコンテキストに新しい情報の断片を入れる役割を果たす。
【０１０７】
図１０Ａは、ワールドワイドウェッブでの意図価値ネットワークアーキテクチャの実施を表している。簡略化の目的から、この図ではセキュリティ、スケーラビリティ、及びプライバシに関する複雑性を無視している。顧客は、Netscape Navigator又はMicrosoft Internet Explorer等、インターネットに接続されたパーソナルコンピュータ上で実行されている任意のインターネットＷｅｂブラウザ１０１０、或いは無線能力を有する携帯情報端末によって、意図価値ネットワークにアクセスできる。意図価値ネットワークにアクセスする複数の方法の詳細な説明については図１７を参照せよ。顧客は固有の名前又はインテグレータのＷｅｂサーバ１０２０に関連するＩＰアドレスによって意図価値ネットワークにアクセスする。インテグレータは、意図データベース１０３０、コンテンツデータベース１０４０、サプライヤプロフィールデータベース１０５０、及び顧客プロフィールデータベース１０６０といったリソースの組み合わせを使用して、意図価値ネットワークを作成する。
【０１０８】
意図データベース１０３０は、意図の構造と、意図を充足させるのに必要な製品及びサービスのタイプとに関するすべての情報を格納する。このデータベースの情報には、意図のステップ、関心のあるエリア、レイアウトテンプレート、及びパーソナライゼーションテンプレートが含まれる。コンテンツデータベース１０４０は、アドバイス、紹介情報、パーソナライズコンテンツ、満足度評価、製品評価、及び進捗レポート等、意図に関連するすべての情報を格納する。
【０１０９】
サプライヤプロフィールデータベース１０５０には、意図に統合された製品及びサービスのプロバイダに関する情報が含まれる。このデータベースに含まれる情報は、意図フレームワークとサプライヤとの間のリンクを提供する。これには、製品リストと、特徴及び説明と、サプライヤの製品Ｗｅｂサイトのアドレスとが含まれる。顧客プロフィールデータベース１０６０には、名前と、住所と、社会保障番号及びクレジットカード情報と、個人的嗜好と、行動情報と、履歴と、Ｗｅｂサイトレイアウトの好みと等、顧客に関する個人情報が含まれる。サプライヤのＷｅｂサーバ１０７０は、情報及び取引のサポートを顧客に提供するために必要なサプライヤのあらゆるデータベースへのアクセスを提供する。
【０１１０】
製品情報データベース１０８０は、特徴、入手可能性、及び価格等、あらゆる製品関連情報を格納する。製品注文データベース１０９０は、あらゆる顧客の注文を格納する。このデータベースとのインタフェースは、ＳＡＰ、Ｂａａｎ、Ｏｒａｃｌｅその他が提供している統合基幹業務アプリケーションを通じて行うことが可能であり、或いはサプライヤのＷｅｂサーバ又はアプリケーションサーバを通じて直接アクセスすることができる。顧客情報データベース１０９１は、取引を完了するため、或いは顧客レコードを維持するためにサプライヤが必要とするあらゆる顧客情報を格納する。
【０１１１】
図１０Ｂは、エゴセントリックインタフェース内でＷｅｂページを作成するために利用されるロジックを提示するフローチャートである。この環境では、パブリックインターネット又はプライベートイントラネット等のように、ＷｅｂサーバとＷｅｂブラウザとはＴＣＰ／ＩＰネットワークによって接続されていると仮定する。可能なＷｅｂサーバには、Microsoft Internet Information Server、Netscape Enterprise Server、又はApacheが含まれる。可能なＷｅｂブラウザには、Microsoft Internet Explorer又はNetscape Navigatorが含まれる。クライアント（つまりＷｅｂブラウザ）は、サーバ（つまりＷｅｂサーバ）に対して、特定のＷｅｂページを要求する１００１。これは通常、ユーザがＷｅｂページ内のボタン又はリンクをクリックすることで達成される。Ｗｅｂサーバは、クライアント（つまりＷｅｂブラウザ）に格納されるユーザＩＤを管理するデータベース及びユーザプロフィールデータベース１００３への要求によって、その特定のユーザに関するレイアウト及びコンテンツの好みを取得する１００２。次に、Ｗｅｂサーバは、コンテンツデータベース１００５から、要求されたページのコンテンツを検索する１００４。次に、カレンダ、電子メール、連絡先リスト、及びタスクリストの項目等、関連するユーザ中心コンテンツが検索される１００６（このプロセスの詳細な説明については図１１を参照）。データベースへのクエリは、ユーザプロフィールデータベース１００３内のユーザプロフィールの一部として格納されているユーザのコンテンツの好みを利用して、戻されるコンテンツをフィルタリングする。戻されたコンテンツはその後、ユーザプロフィールにおいて定義されたレイアウトの好みに従って、Ｗｅｂページにフォーマットされる１００７。このＷｅｂページはその後、クライアントに戻され、ユーザに対して表示される１００８。
【０１１２】
図１１は、Ｗｅｂページに追加するユーザ中心コンテンツを検索するプロセスを表している。このプロセスは、図１０Ｂの１００６を更に詳細な形で説明している。ここではサーバが、ユーザプロフィールと、このページに統合されることになる既存のコンテンツとを既に取得していると仮定する。このサーバは、フィルタリングされたコンテンツをパースし１１１０、イベント、連絡先、名前、及び電子メールアドレスのインスタンスを探す。これらのいずれかが見つかった場合は、タグが付けられ、一時保有空間に格納される。次に、このサーバは、様々なデータベースに格納された任意のユーザ中心コンテンツを見つけようと試みる１１２０。これには、一時保存空間内のタグ付き項目を、カレンダデータベース１１４０のカレンダ項目１１３０と、電子メールデータベース１１１４の電子メール項目１１１５と、連絡先データベース１１６８の連絡先項目１１１７と、タスクリストデータベース１１１８のタスクリスト項目１１１９と、ニュースデータベース１１２０のニュース項目１１２１とにマッチングさせることが伴う。関連するユーザ中心コンテンツを検索した後、これは共に編集され戻される１１２２２。
【０１１３】
ユーザペルソナ：
このシステムでは、ユーザは、プロフィール情報を異なるコンテキストで有効なセットに集合させる多数の異なるペルソナを作成することができる。ユーザは、自宅用に購入を行う時、１つのペルソナを作成することができる。このペルソナは、自宅の住所を含む可能性があり、このユーザがショッピング時に良質なバーゲン品を探していることを示す可能性がある。同じユーザは、仕事のコンテキストにいる時に使用することが可能な第二のペルソナを作成することができる。このペルソナは、ユーザの職場の所在地を格納する可能性があり、このユーザが特定のベンダを好むこと、或いは割引プログラムを設定している特定の企業のために働いていることを示す可能性がある。仕事関連品目のショッピングの時、ユーザは、このペルソナを使用することができる。ペルソナは規則や制限も含むことができる。例えば、仕事のペルソナは、ユーザが一社のみの旅行代理店で飛行機の予約を行い、雇用主が設定した手配規則を利用するように制限することができる。
【０１１４】
図１２は、ユーザと、複数のペルソナと、複数のプロフィールとの間の関係を表している。ユーザレベルにあるのはユーザプロフィール１２００である。このプロフィールはユーザとユーザの口座情報を表す。データベースには、口座を有するそれぞれのユーザに関する固有のレコードが１つ存在する。それぞれのユーザには複数のペルソナ１２２０、１２３０、及び１２４０が付属する。これらのペルソナは、複数のプロフィールを有効なコンテキストにグループ化するのに使用される。例えば、ユーザがサンフランシスコに住み、パロアルトで働いているが、タホ湖に山荘を所有しているとする。彼は、自分のサイトにアクセスする可能性のある３種類のコンテキストを有している。１つのコンテキストは仕事関連である。他の２つは家庭生活関連だが、場所が異なっている。このユーザは仕事用ペルソナ１２２０と、自宅用ペルソナ１２３０と、山荘用ペルソナ１２４０とを作成することができる。それぞれのペルソナは、異なる一般プロフィール１２５０、１２６０、及び１２７０を参照し、これにはその場所の住所が含まれる。したがって、３つの一般プロフィールが存在する。それぞれのペルソナは更に、２つの旅行プロフィールの一方を参照する。このユーザは、仕事用旅行プロフィール１２８０を維持しており、これにはチケットの手配及び予約の実行に関する会社のあらゆる規則が含まれる。このプロフィールは、例えば、この人物がビジネスクラス又はファーストクラスでのみ旅行すること、及び彼の好みの航空会社がユナイテッド航空であることを指定できる。仕事用ペルソナは、この仕事用旅行プロフィールを参照する。このユーザは更に、彼がエコノミクラスで旅行することを好み、全般的に安いことから払い戻し不可のセールを求めていることを指定する自宅用旅行プロフィール１２９０を維持することが可能である。自宅用ペルソナ及び山荘用ペルソナの両方が自宅用旅行プロフィールを指し示す。
【０１１５】
図１３は、ペルソナの概念をサポートするデータモデルを表している。ユーザ表１３１０には、システム内に口座を有するそれぞれのユーザの記録が含まれる。この表には、ユーザ名及びパスワード１３２０と、固有の識別子とが含まれる。それぞれのユーザは複数のペルソナ１３３０を有することが可能であり、これはプロフィール１３４０と呼ばれる更に特化した構造のコンテナとして機能する。プロフィールには、プロフィールフィールド１３５０レコード内の詳細な個人情報が含まれる。それぞれのプロフィールには、プロフィール制限１３６０レコードのセットが付属する。これらのそれぞれには、名前１３７０と規則１３８０とが含まれ、これが制限を定義する。規則は、パターンに似た形式（もしｘならばｙ）で、これにより規則を特定の用途に制限することができる。プロフィール制限の一例には、リストに含まれる特定の航空会社でユーザが飛行機を予約できないことを定めた規則がある。このプロフィール制限は、例えばユーザの雇用主によって設定された「仕事用」ペルソナの「旅行」プロフィールに含めることができる。それぞれのプロフィールフィールドには更に許可１３９０のセットが含まれ、これはそのレコードに含まれる。こうした許可は、特定のプロフィールフィールドの情報に対するどのようなアクセス権を誰が有しているかを定める。
【０１１６】
意図中心インタフェース：
退職又は移転のプランニングといった顧客の意図を満足させるには、特化したインタフェースが必要である。顧客の意図は、例えば経済的安全性、住宅、及び運搬手段から、ヘルスケア、個人的及び職業的成長、及び娯楽に至るまでの多数のエリアに渡る広範なプランニング及び調整を必要とする。意図の満足させるには、消費者のニーズの充足を支援するために業界を超えて機能する相補的なビジネスのネットワークが必要となる。
【０１１７】
意図中心インタフェースは、ユーザが個人の意図を管理するのを支援するために設計されたユーザインタフェースである。任意の一定の時点において、インタフェースのコンテンツはカスタマイズされ、こうした特定の意図に関連するコンテンツのみが示される。意図中心インタフェースにより、ユーザは、こうした特定の意図を満足させるプロセスを管理することができる。これには、一連の別個のステップと、ユーザがアクセス可能なコンテンツエリアのセットとが関与する。任意の時点において、ユーザは異なる意図を管理するインタフェースに切り替えることも可能であり、この行為により、インタフェースのコンテンツは変化し、新たに選択された意図を満足させることに関連するコンテンツのみが含まれるようになる。
【０１１８】
図１４は、意図中心インタフェースをサポートするのに必要なデータモデルの詳細な説明を提示している。それぞれのユーザペルソナ１４１０（ペルソナのデータモデルの詳細な説明については図１３を参照）は、任意の数のアクティブユーザ意図１４２０を有する。それぞれのアクティブユーザ意図にはニックネーム１４３０が与えられ、これはユーザがスクリーン上で見る表示名である。それぞれのアクティブユーザ意図は更に、多数のデータフィールド１４４０を含み、これにはユーザとの対話全体を通じて収集された任意のユーザデータが含まれる。例えば、ユーザがスクリーン上のフォームを埋め、そのフィールドの１つが社会保障番号である場合、対応するデータフィールドは、名前＝「ＳＳＮ」１４６０、値＝「９９９−９９−９９９９」１４６０を含むことになる。それぞれのユーザ意図は更に、意図ステップ１４７０完了ステータスを追跡する。完了１４８０フィールドは、ユーザがステップを完了したかどうかを示す。すべてのユーザ意図は、一般意図１４９０のユーザ固有バージョンであり、一般意図はあらゆるユーザのための意図に関するデフォルトモデルである。一般意図は、意図のサブステップに付属するカスタム規則１４１１及び１４１２を通じてカスタマイズされる。こうしたカスタム規則は、システムが個々のユーザのプロフィール情報を使用して、それぞれのユーザの意図をどのようにカスタマイズするかを表すパターンである。
【０１１９】
統計エージェント：
エージェントは、それぞれのユーザの主要な統計値を追跡する。こうした統計値は、ユーザに特定の行動を促すために仮想現実ペットのたまごっちと同様の形で使用される。こうした記録される統計値は、ログインの頻度、ニュース記事等のコンテンツの評価の頻度、及び特定の期間に実行したタスク数によって測定されるエージェントの活動である。この情報は、感情的に訴えかけて特定の行動をユーザに促すために、システムによって使用される。
【０１２０】
図１５は、エージェントの現在の統計値を表示するページを生成するプロセスを表している。ユーザがクライアントブラウザによりエージェント統計ページを要求した時１５１０、サーバはユーザのプロフィールデータベース１５３０からユーザの統計値を検索する１５２０。次に、このサーバは、標準化された統計値セットを作成するために必要な数学的計算を実行する１５４０。次に、このサーバは、コンテンツデータベース１５６０から、ユーザ中心統計値を計算するために使用する式を検索する１５５０。その後、一般式と、そのユーザの統計値とを使用して、グラフが生成される１５７０。このグラフは、統計ページを作成するためのテンプレートに挿入される１５８０。その後、このページがユーザに戻される１５９０。
【０１２１】
パーソナライズ製品レポートサービス：
このシステムは、ユーザプロフィールに基づいてユーザ毎にカスタマイズされた消費者レポートのようなサービスを提供する。このシステムは、製品の品質と、多数の次元での望ましさとに関するユーザからの評価を記録及び提供する。このシステムと従来の製品品質測定サービスとの違いは、ユーザに返ってくる評価がパーソナライズされている点である。このサービスは、ユーザのプロフィールとのマッチングが最も緊密であり、求められている製品をこれまでに評価したことがある人物を見つけることで機能する。このアルゴリズムを使用することは、ユーザに対して、そのユーザに似た人物からの統計値のみを含む製品レポートを確実に送り返すのに役立つ。
【０１２２】
図１６は、ユーザ向けパーソナライズ製品評価を決定するアルゴリズムを表している。ユーザが製品Ｘに関する製品レポートを要求した時１６１０、このアルゴリズムは、その製品を以前に評価したことがあるユーザのプロフィールデータベース１６３０（製品評価を含む）から、プロフィールを検索する１６２０。次に、システムは、コンテンツデータベース１６５０からプロフィールマッチングアルゴリズムのデフォルトの閾値を検索する１６４０。次に、プロフィールマッチングアルゴリズムにおいて指定されたいくつかの次元に、ユーザの選抜候補者リストをすべてマップする１６６０。その後、最も近い近接者の上位ｎ名（閾値変数として事前に指定）を決定し、プロフィールマッチングアルゴリズムの結果を使用して、この人達がセット内のユーザのプロフィールからの距離ｙ（同じく閾値変数として事前に指定）の中にあるかどうかを判断するテストを実行する１６７０。この閾値の中にない場合は、閾値変数が緩和され１６８０、再度、テストが実行される。この処理は、テストで真が戻されるまで繰り返される。その後、最も近い近接者ｎ名の小さなセットからの製品評価を使用して、いくつかの次元に沿った多数の製品統計値が決定される１６９０。こうした統計値は、製品レポートのテンプレートに挿入され１６９５、製品レポートとしてユーザに戻される１６９７。
【０１２３】
個人プロフィール及びサービスの偏在：
このシステムは、個人のプロフィールを１箇所で集中的に記憶する場所を提供する。この記憶場所は、パブリックインターネットを通じて利用可能なサーバであり、インターネットに接続された適切なアクセス能力を有する任意の装置によってアクセス可能である。至るところでプロフィールにアクセスできることから、ユーザのプロフィールに基づいてユーザ向けのサービスをカスタマイズするために、多数のアクセス装置を使用することができる。例えば、業者のＷｅｂサイトでは、このプロフィールを使用して、ユーザにパーソナライズされたコンテンツを提供することができる。インターネットにアクセス可能な携帯情報端末（ＰＤＡ）では、ＰＤＡ上の個人のカレンダ、電子メール、連絡先リスト、タスクリスト、及びメモを、インターネットサイトに格納されているバージョンと同期させることができる。これにより、個人は、必要な時期及び必要なフォーマットに関係なくデータを利用可能にしておくために、このデータの１つのバージョンのみを維持しておけばよい。
【０１２４】
図１７は、こうした中央格納プロフィールにアクセスする多数の異なる方法に関連する詳細なロジックを提示している。プロフィールデータベース１７１０は、ユーザのプロフィール情報の中央記憶場所である。プロフィールゲートウェイサーバ１７２０は、ユーザ自身からのものか、或いはユーザにサービスを提供しようとしている業者からのものであるかに関係なく、プロフィール情報に関するあらゆる要求を受領する。このプロフィールゲートウェイサーバは、プロフィール所有者が明確に許可を与えた時のみ、情報を公表する状態を確保することに責任を有する。ＴＣＰ／ＩＰ（標準ネットワーク通信プロトコル）でパブリックインターネット１７３０にアクセス可能な任意の装置は、インテリジェントＨＴＴＰ要求によって、プロフィールデータベースからの情報を要求することができる。消費者は、例えば、テレビ１７４０、携帯電話、スマートカード、ガスメータ、水道メータ、台所用品、セキュリティシステム、デスクトップコンピュータ、ラップトップ、ポケットオーガナイザ、ＰＤＡ、及び自動車等の装置からサービスへのアクセスを得ることができる。同様に、業者１７５０も（それぞれのプロフィールを所有する消費者からの許可を受けて）こうしたプロフィールにアクセス可能であり、これにより、カスタマイズ及びパーソナライズされたサービスを消費者に提供することができる。
【０１２５】
この偏在プロフィールの潜在的な使用方法の１つは、ホテルチェーンに関する。消費者は、自分を一意に特定するデジタル証明書が入ったスマートカードを携帯することができる。このスマートカードのデジタル証明書は、システムによって発行されたものであり、システムは消費者のプロフィール情報をプロフィールデータベースに記録している。消費者は、このカードをホテルチェーンに持っていき、チェックインする。ホテルの雇用者はカードを読み取り機に通し、消費者は暗証番号を入力し、デジタル証明書のロックを解除する。証明書は（安全な送信プロトコルを使用して）プロフィールゲートウェイサーバに送られ、認証される。これにより、ホテルでは、消費者が以前に指定した消費者のプロフィールの特定部分にアクセスできるようになる。ホテルでは、消費者のあらゆる請求情報及びホテルの部屋の好みを検索することができる。更にホテルでは、消費者の映画及び食事の好みにもアクセスし、この両方についてカスタマイズしたメニューを提供することができる。ホテルでは、消費者の配偶者に電子メールを送り、消費者がホテルにチェックインしており無事であることを知らせるサービスを提供できる。あらゆる取引情報は、ホテルにチェックインした後、消費者のプロフィールにアップロードすることができる。これにより、ホテルのパートナーは（同様に消費者からの許可を受けて）ホテルが収集した消費者に関する情報を利用することができる。
【０１２６】
意図価値ネットワーク：
意図価値ネットワークにおいて、全体的なインテグレータシステムは、ユーザへの製品及びサービスの納入を調整する。このインテグレータは、ユーザのプロフィールに反映されるユーザの好みに基づいて、ユーザに物理的及び仮想的に製品及びサービスを提供する承認サプライヤのネットワークを管理する。このインテグレータは、サプライヤと消費者との間の関係を管理し、サプライヤによる消費者の意図の充足を調整する。インテグレータは、例えば、消費者に製品及びサプライヤに関する情報を提供すること及び客観的なアドバイスを与えることによって、これを行う。
【０１２７】
図１８では、消費者と１つのサプライヤが関与するインテグレータとの間の詳細な対話を開示している。このユーザはＷｅｂブラウザ１８１０にアクセスし、インテグレータに製品及び価格情報を要求する。この要求は、ユーザのＷｅｂブラウザからインテグレータのＷｅｂ／アプリケーションサーバ１８２０に送られる。ユーザの好み及び個人情報がインテグレータの顧客プロフィールデータベース１８３０から取得され、Ｗｅｂ／アプリケーションサーバに戻される。要求された製品情報はサプライヤの製品データベース１８４０から抽出され、特定の顧客向けにカスタマイズされる。Ｗｅｂ／アプリケーションサーバは、顧客に関する質問情報により、サプライヤの顧客情報データベース１８５０を更新する。その後、製品及び価格情報はＷｅｂページ１８６０にフォーマットされ、顧客のＷｅｂブラウザに戻される。
【０１２８】
サマリエージェント：
アプリケーション及びＷｅｂサーバで実行されるソフトウェアエージェント一式は、ユーザのための反復するタスク又は日常的なタスクを管理するようにプログラムされる。このエージェントは、ユーザが設定した規則に従って動作し、ユーザによって明示的に定義されたタスクのみを実行することができる。このエージェントは、ユーザへの請求を支払うこと、コンテンツ及び電子メールをフィルタリングすること、タスク及びエージェントの活動のサマリ表示を提供することを管理できる。エージェント用のユーザインタフェースは、特定のユーザに合わせて変更することができる。
【０１２９】
図１９では、ユーザ向けの口頭サマリを生成するエージェントによる処理の好適な実施形態に従ったロジックを開示している。ユーザがサマリページを要求した時１９００、サーバは、ユーザプロフィールデータベース１９３０から、エージェントのタイプ、規則、及びサマリレベルといったユーザのエージェントの好みを取得する１９２０。サーバは、コンテンツデータベース１９５０から、電子メール、予定リストの項目、ニュース、及び請求といったコンテンツを取得する１９４０。エージェントは、プロフィールデータベースに格納された規則を使用して、こうしたすべてのコンテンツをパースし、コンテンツのサマリを作成する１９６０。コンテンツはテンプレートに従ってＷｅｂページにフォーマットされる１９７０。コンテンツデータベース１９９０のコンテンツとデータベースに格納されるスピーチテンプレートとを使用して、エージェントのスピーチ用テキストが生成される１９８０。このスピーチテキストはＷｅｂページに挿入され１９９５、このページはユーザに戻される１９９７。
【０１３０】
信頼される第三者：
上のシナリオでは、Ｗｅｂサイトは、公表されたポリシに従って、情報のプライバシの保証を維持する必要がある。このシステムは、消費者の信頼される第三者であり、あらゆる場合において、消費者に代わって行動し、商取引の機会のシミュレーションではなく情報のプライバシに偏り過ぎる。この信頼される第三者は、明言されたポリシにより特定の連座を保証する適切なプロセスのセットを有する。
【０１３１】
「ｍｅコマース」：
この言葉は「ｅコマース」という言葉を拡張したもので、「パーソナライズ電子商取引」を意味する。図２０は、好適な実施形態によるディスプレイログインを表している。このディスプレイは、エージェント２０００を有するMicrosoft Internet Explorerアプリケーションとして実施され、エージェントは、様々なシステムコンポーネントをカスタマイズ及びパーソナライズし、情報を集め、ユーザの個人的要件と対話するために、システムとの対話のプロセスを通じて、ユーザをガイドする。ユーザはユーザ名を２０１０に、パスワードを２０２０に入力し、ボタン２０４０を選択して、ログイン手続きを開始する。ロゴ２０３０が示すように、このシステムは電子商取引を、パーソナライズされた、いわゆる「ｍｅ」コマースに変える。
【０１３２】
図２１は、好適な実施形態による日常ロジスティックス管理ディスプレイを表している。ユーザはアニメーションエージェント２１００にパーソナライズメッセージ２１９０によって迎えられる。ユーザは、旅行２１１０、家庭の雑用２１２０、金融２１３０、及び市場活動２１４０を含め、要件に基づいて様々な活動を選択できる。ある活動から別の活動への迅速なナビゲーションを促進するために、電子メール、カレンダリング、ドキュメント作成といったルーチンタスク用のアイコン２１４２も提供される。ニュースその他の関心のある項目の転送を可能にするために、ダイレクトリンク２１４６も提供される。ユーザがいる場所に基づいて、様々なプロフィールを選択することができる。これは例えば、仕事、自宅、又は休暇等である。このプロフィールは、ユーザが別の場所のための新しいプロフィールを必要とする時に追加することができる２１７０。個人情報の様々な項目２１８０は、様々な試みをサポートするためにユーザから収集される。更に、情報がタイムリで現行のものであることを確認するために項目２１８０毎に許可２１５０が設定される。
【０１３３】
図２２は、好適な実施形態によるユーザメインディスプレイを表している。ユーザの好みに基づいて、世界のニュース２２００及びローカルニュース２２１０が提供される。このユーザは、メインディスプレイに直接情報を提供する項目として不動産２２３０も選択している。更に、ユーザの好みに基づいて、異なるエージェント２２２０が提供される。
【０１３４】
図２３は、好適な実施形態によるエージェント対話を表している。エージェント２３１０は、ユーザに情報２３００を伝達し、ユーザの生命保険のニーズが変化したことを示し、ユーザ向けの情報を最善の形でまとめたチャートをユーザに示している。現在のユーザ統計値に基づいて、更に詳細な情報を促すために、特定のヒント２３９５が提供される。ユーザの生命保険のニーズに関するチャート２３７０も、ユーザが適切な行動を判断するのを支援するために、ディスプレイの中央で強調表示される。保険証書の変更を容易にするためにボタン２３８０が提供され、ユーザの保険要件に関する様々な表示を選択するのを支援するためにボタンのセット２３９０が提供される。
【０１３５】
イベントバックグラウンダ：
イベントバックグラウンダは、来るべきイベントの短い説明で、イベントの直前にユーザに送られる。イベントバックグラウンダは、このイベントに関連する最新情報によって絶えず更新される。旅程及びロジスティックスといった関連情報が含まれ、同じ場所にいる可能性のあるユーザの知人といった他の有効な情報も提供される。イベントバックグラウンダの目的は、パブリックＷｅｂサイト及びユーザのカレンダ及び連絡先リストといった多数のリソースから引き出した、イベントに関する最も新しい情報を提供し、ユーザが一定の状況において適切に反応するのを可能にすることである。
【０１３６】
ビシニティフレンドファインダ
このソフトウェアは、友人、家族、又は知人がユーザと同じ周辺にいること、或いは同じ周辺に来ることをユーザに伝える機会を探す。このソフトウェアは、来るべきイベントについてユーザのカレンダをスキャンする。次に、地形マップを使用して、こうしたカレンダイベントを、連絡先に載っている人物のカレンダイベントと比較する。その後、ユーザに任意の一致を通知し、これにより、特定の時間にユーザの近くにいる予定である人物がいることをユーザに伝える。
【０１３７】
情報過多：
情報過多という用語は、その定義と、意味及び結果との両方において、現在では比較的理解されるようになっている。人間が一度に利用可能な注意の量は限られているが、こうした注意を求める量は毎日増え続けている。簡単に言えば、多すぎる情報と少なすぎる時間こそが、今日の知識労働者の生活を複雑にする主な要因である。
【０１３８】
情報過多に動的に対処する第一の試みでは、情報の量が減るように情報のインテリジェントフィルタリングを行うことに注目する。しかしながら、情報の小片を単純にランダムに取り除くのではなく、こうしたアプローチのほとんどでは、どの情報を最終的にユーザに提示するかについて知的になることを試みている。これは、ユーザの関心に基づいてそれぞれのドキュメントを評価し、関連性の少ないものを捨てることで達成される。そのため、結果として、質も向上する。
【０１３９】
情報のフィルタリングは、この新しい時代において情報に対処するための第一のステップに過ぎない。おそらく間違いなく、ドキュメントの質と同じように重要なのは、それに容易にアクセスできることである。ミーティングに出席してしまえば、そのミーティングの題材について重要な情報を含んでいるドキュメントが自分のオフィスに届けられても、価値はほとんどない。相互通信の技術に刺激されビジネスの速度が高まるにつれ、どんな時でも、どんな場所にいても、質の高い情報を受け取ることができる能力は不可欠になっている。この新しいアプローチは、インテリジェント情報伝達と呼ばれ、新しい情報自体の先駆けとなっている。
【０１４０】
好適な実施形態では、情報過多を減少させるだけでなく、高品質の情報をユーザが求める場所及び時間に伝達する試みにおいて、上で説明したインテリジェント情報伝達の理論を実証している。言い換えれば、このシステムは、適切な情報を、適切な人物へ、適切な時間に、適切な場所で伝達する。
【０１４１】
アクティブナレッジ管理システムの説明：
図２４は、好適な実施形態によるアクティブナレッジ管理システムのブロック図である。このシステムは以下の部分、つまり１つ以上のサーバとのバックエンド２４００接続と、パーソナル移動無線クライアント（アウェアネスマシン）２４３０、２４３６と、パブリッククライアント（マジックウォール）２４１０、２４２０と、Ｗｅｂクライアント２４４６、２４４８と、電子メールクライアント２４５０、２４６０とによって構成される。
【０１４２】
パックエンドサーバ（２４００）プロセス：
図２５は、好適な実施形態によるバックエンドサーバのブロック図である。このバックエンド（図２４の２４００）は、以下のソフトウェア活動要素、つまりインテリジェントエージェントコーディネータ（Ｍｕｎｉｎ）２５８０と、情報優先度決定サブシステム２５３０、継続的及び断続的に実行される情報収集及び処理用インテリジェントエージェント２５００、２５０２、及び２５０４と、ユーザプロフィールデータベース２５４２及びサポートソフトウェアと、情報チャネルデータベース２５４２及びサポートソフトウェアと、通信ソフトウェア２５５０と、情報変換ソフトウェア２５６０と、補助ソフトウェアとを有するコンピュータシステムである。
【０１４３】
アウェアネスマシン（図２４の２４４６及び２４４８）：
●アウェアネスマシンは、ハードウェア装置とソフトウェアアプリケーションとの組み合わせである。ハードウェアはハンドヘルド型コンピュータと無線通信装置とによって構成される。アウェアネスマシンは、無線の情報細流を継続的に受領することで、絶えず更新される所有者の世界の状態を反映する。この情報は、インテリジェントエージェント一式によって掘り出され処理されるものであり、メールのメッセージ、それぞれのユーザの好みに合ったニュース、スケジュールの更新、来るべきミーティング及びイベントの背景情報、更には天気情報及び交通情報によって構成される。
【０１４４】
図２５のインテリジェントエージェントコーディネータ２５８０も、システムに対するユーザの「インタフェース」であり、ユーザがシステムと対話するときは常に、ＧＵＩその他のエンドユーザインタフェースに関係なく、これらは最終的にはインテリジェントエージェントコーディネータとやり取りをする（質問を行い、コマンドを送る）。インテリジェントエージェントコーディネータには主に４つの責任があり、それは１）ユーザの活動を監視すること、２）情報要求を処理すること、３）それぞれのユーザのプロフィールを維持すること、及び４）ユーザ及びそれぞれのエージェントとの間でやり取りする情報の経路を定めることである。
【０１４５】
ユーザの活動の監視：
ユーザがセンサを始動させた時は常に、インテリジェントエージェントコーディネータは「環境キュー」を受領する。このキューは、インテリジェントエージェントコーディネータが、情報伝達の目的で、ユーザがいる場所の理解を得ることを可能にするだけでなく、それぞれの人物の生活の標準パターン（到着時間、出発時間等）を学習することも可能にする。こうしたパターンは、情報を伝達する時のシステムの知性を高める試みにおいて、絶えず更新され改良される。例えば、現在、１人の人物がいくつかの電子メールアカウント（仕事ベース、自宅ベース、移動ベース等）を有することは珍しくなく、こうしたすべてのアカウントに関する検索プロセスにいくつかの異なるコンピュータが関与することも珍しくない。したがって、インテリジェントエージェントコーディネータが正しい場所への情報伝達を成功させるには、ユーザが情報を見る確率を最大にするために、こうしたすべてのアカウントと、ユーザがこれらにアクセスする可能性のある時間とを考慮する必要がある。これについては、別のセクションで更に説明する。
【０１４６】
情報要求の処理：
インテリジェントエージェントコーディネータは、それぞれのユーザを意図して情報をパーソナライズし、ユーザが受け取る情報において、それぞれのユーザの関心を更に正確に反映させるために、他のエージェントからの情報要求を処理する。こうした要求は一般に、ユーザのプロフィールに関連している。例えば、エージェントは、ユーザのために交通レポートを作成している時、インテリジェントエージェントコーディネータに、そのユーザの交通地域（サーチストリング）を要求する可能性がある。ユーザのプロフィールデータに対するすべてのアクセスは、この方法においてアクセスされる。
【０１４７】
ユーザプロフィールの維持：
ユーザプロフィールにはユーザに関する広範な情報が含まれる。この情報は、ユーザ指定データと、インテリジェントエージェントコーディネータがそれぞれのユーザの情報及び活動から学習及び推定した情報との混合物である。プロフィールに含まれるデータを保護するために、インテリジェントエージェントコーディネータはすべての情報要求を処理する必要がある。インテリジェントエージェントコーディネータは、更に多くのルーチンである日常的タスクを支援するために、ユーザの活動を観察し、その生活パターンの学習を試みることにより、こうしたプロフィールを絶えず修正及び更新する。インテリジェントエージェントコーディネータは更に、それぞれのユーザの毎日の活動から意味を拾い集めるために、他のエージェントを利用する。これらのエージェントは、こうしたデータを掘り出し、現在の関心事、長期的な関心事、更にはそれぞれのタイプの情報を伝達する時間の好みを示すものを見つけようとする。インテリジェントエージェントコーディネータの観察に関する別の重要な態様は、経路指定の目的で、それぞれのユーザが１日を通じて物理的にどこに位置するのかを判断しようとすることである。
【０１４８】
情報の経路指定：
ほとんどの人間は１日を通じて移動する。インテリジェントエージェントコーディネータは、観察（監視されない学習）と環境からのキューとの両方により、ユーザがどこに位置するか、或いはどこに位置する可能性が高いかを判断しようと試みることで、この事実に敏感になろうとする。これはユーザの情報をどこに送るかを判断するためだけでなく、どのフォーマットで情報を送るかを判断するためにも間違いなく重要である。例えば、ユーザが机に向かっており、Ｗｅｂクライアントを使用しているばあい、インテリジェントエージェントコーディネータはユーザのＰＣから活動を示すものを受領し、任意の必要な情報をそこへ送るべきであることが分かる。加えて、デスクトップＰＣは通常非常に強力であるため、機能をすべて使った画像の多いバージョンを送ることができる。しかしながら、これに代わる状況、つまりインテリジェントエージェントコーディネータが（出口の近くにあるキーカードリーダにより）あなたがビルを出たばかりであることを示すものを受領した状況も考えられる。その数分後、インテリジェントエージェントコーディネータが、あなた宛の緊急メッセージを受領したとの通知を受領したとする。インテリジェントエージェントコーディネータは、あなたがビルを出たことを知っており、それ以外の行動を示すものを受領していないため、ハンドヘルド型装置（その能力についても知っている）によって連絡できるとみなし、画像優先バージョンではなく、緊急メッセージのテキストをそこに送る。
【０１４９】
内在するイノベーション：
アクティブナレッジ管理システムは、ナレッジ管理と人間及びコンピュータの対話との世界において、いくつかの最も高度な思考を意味している。主なイノベーションの一部には以下が含まれる。
●上で例示したインテリジェントエージェントコーディネータ。
●インテリジェント情報伝達の理論の開発、実証、及び実現。
●すべてが共通のバックエンドを利用した情報伝達のいくつかのチャネルのサポート。例えば、ユーザがマジックウォールの前にいる場合、情報はマルチメディア対応形式で提示される。ユーザは移動中であるとシステムが判断した場合、情報は標準のテキストによってアウェアネスマシンに送られる。これにより、ユーザが情報を求める時間及び場所に関係なく情報を伝達することを促進する。
●静的なユーザプロフィールに基づくだけでなく、ユーザの対話履歴と、「人、場所、及び時間」の認識を含む現在のリアルタイム状況とを考慮することによる情報のパーソナライズ。
●インテリジェントエージェントコーディネータの意見、ユーザの好み、及びユーザの対話履歴を考慮する高速でスケーラブルな情報優先度決定サブシステムの利用。インテリジェントエージェントの部分から日常的判断の負荷を取り去ることにより、システムのスケーラビリティを損なうことなく、エージェントを更に精巧で精度の高いものにできる。
●インテリジェントエージェントのアニメーション表示及び触覚入力と組み合わせた音声認識及び音声合成により、効率的で、直観的で、感情的に満足感を与えるシステムとの対話を提供する。
【０１５０】
クライアント報告サブシステムモデル：
コンテキスト：
報告サブシステムは、レポート（読み出し、記録事項の作成）を行うためにクライアント上の他のサブシステムによって使用される。このサブシステムは、取り扱うデータのタイプを想定しない―このデータは、（アーキテクチャサービスの一環としての）誤ったレポート又は（アプリケーションデータサービスの一環としての）リード管理情報である可能性がある。報告サブシステムは、この意味において、インフラの一部であり、クライアント上のあらゆる場所で利用可能な一連の基本サービスである。報告サブシステムは、通信サブシステムを使用して、データの格納及び転送を行う。
【０１５１】
アーキテクチャの概要：
報告サブシステムはあらゆるクライアントサブシステムにサービスを提供する。このサブシステムは、クライアントアプリケーション内と、クライアント及びサーバ間とにおいてメッセージを伝えるメカニズムを備える。この報告メカニズムは、通信サブシステムを使用して、データの格納及び転送を行う。例外は、この報告メカニズムを使用して、エラーに関する情報のみをレポートする。
【０１５２】
役割：
報告メカニズムは、インフラサービスのセットを提供し、これによりアーキテクチャコンポーネントは、情報をレポートすることができる。このサブシステムは、レポートされる情報について規定しないが、システム障害又は顧客対話情報といった特定のタイプのレポート情報へのマッピングを行うコンポーネントを含む。
【０１５３】
このサブシステムのコンポーネントの一部は、例外のセットとして提示され、これにより、処理中に遭遇したエラー条件の自動レポートが可能になる。
【０１５４】
このサブシステムはデータを受け入れ、適切なフォーマットで通信サブシステムに転送する。このサブシステムは、エラー条件の結果である処理中に生成された例外を捕捉しレポートする。このサブシステムは、エラーロギングから販売のリードに至るまで、作成する必要のある任意のタイプのレポートに対処することが可能である。必要に応じて新しいタイプの情報を記録するのに十分な柔軟性を有する。更に、必要に応じて新しいタイプのレポートを追加できる十分な柔軟性を有する。加えて、ロギングプロセス中に特定の情報が利用できない状態に対処することができる。
【０１５５】
責任：
クライアント報告サブシステムは、アプリケーションのあらゆる部分で使用する例外のセットを提供することに責任を有する。このサブシステムは更に、ロギング失敗レポートと、アプリケーションハートビートレポートと、メッセージ受領証と、紹介又はリードと、管理情報システムのエントリとに責任を有する。
【０１５６】
免責：
このサブシステムは、インタフェースでの対話その他の場所から情報を収集することに責任を有しておらず、どのデータセットをレポートする必要があるかを判断することにも責任を有していない。レポートすることには、レポートを印刷することは含まれない。
【０１５７】
コンポーネントの仕様：
クライアント例外報告コンポーネント
これは例外クラスのセットであり、クライアント報告コンポーネントの報告サービスを使用して、障害情報を格納及び送信する。
【０１５８】
クライアント報告コンポーネント
これはあらゆるレポートの情報を収集し、フォーマットし、クライアント通信サブシステムに送信するメカニズムである。
【０１５９】
作成、存続、及び管理：
このサブシステムの重要な要素は、レポートオブジェクトの作成を管理する静的なクラス−レポートファクトリである。このクラスは、通信サブシステム（クライアントの構成を管理）によってインスタンスを作成され、常に利用可能である。そうではない場合には深刻なエラーとなる。レポートは、必要に応じて、その場限りで生成される。
【０１６０】
サイジング及び容量：
クライアントアーキテクチャの要件がどんなものであっても、クライアント報告サブシステムの「スループット」（一定の時間に要求されるレポート数、タイプの合計数として理解される）は、システムリソースに大きな負担をかけない。レポートに関する容量要件のほとんどは、こうしたレポートの格納及び伝送用に準備する必要がある通信サブシステムによって吸収される。
【０１６１】
それでもなお、このサブシステムはアーキテクチャによって要求されるあらゆるスループットに対処できる必要があり、その設計では、アーキテクチャのそれぞれの部分で生成される推定仕事量を考慮に入れる。
【０１６２】
性能：
クライアント報告サブシステムでは性能は重要ではない。レポートデータは、僅かな例外を除き、伝送前に格納されるため、データが送信される前の遅延は予期される。特定のタイプの深刻又はクリティカルな障害は一度に報告する必要があるが、こうした伝送に必要な低い帯域幅は性能の問題を提示しない。
【０１６３】
設計のガイドライン：
アーキテクチャのレポートのニーズは変動するが、能力の中核セット（障害レポート、リード管理、対話レポート）は常に要件として残る。このサブシステムは、能力の拡張又は削減だけでなく、それぞれの能力のために記録するデータの詳細度及び性質の調整を可能とする柔軟性を有する、
このシステムの実施はプロジェクトＪａｖａコード化規格に従う。
【０１６４】
論理コンポーネント：
クライアント例外報告コンポーネント内の例外はクライアント報告コンポーネントを呼び出し、障害レポートを作成する。
【０１６５】
コンポーネントの説明：
クライアント例外コンポーネント
これは例外クラスの階層であり、例外の処理と受け渡しを支援するために構築される。これらの例外は、それが表す例外イベントに関する情報を受け入れる。こうした情報と、このクラスが自分のイベントについて知っている他のすべての事柄とによって、このコンポーネントはクライアント報告コンポーネントを使用して障害レポートを作成する。
【０１６６】
クライアント報告コンポーネント
静的なレポートファクトリは、合図されたイベントの形式で、他のコンポーネントからの要求を受け入れる。このイベントに基づいて、このファクトリは特定のタイプのレポートを作成する。このレポートは、その後、呼び出しコンポーネント又はレポータによって供給された情報に占有される。
【０１６７】
レポートの発信：
コンポーネントＡは、クライアント報告サブシステムに対して合図を送り、レポートすべきイベントが発生したことを示す。次に、クライアント報告サブシステムは、イベントに関する情報を要求し、レポートを作成する。最後に、クライアント報告サブシステムは、クライアント通信サブシステムに、レポートを送る準備ができたことを合図する。
【０１６８】
例外の投げ込み：
第一に、コンポーネントＡは、適切な例外のインスタンスを作成することにより例外的なイベントが発生したことを合図する。第二に、コンポーネントＡは、レポートすべきイベントの関連情報を例外に渡す。第三に、コンポーネントＡは、例外を投げ込むことを要求する。第四に、クライアント例外報告コンポーネントは、上で概要を説明したクライアント報告コンポーネントを使用して、利用可能な情報に基づき、送信されるレポートを発信する。最後に、クライアント例外報告コンポーネントは例外を投げ込む。
【０１６９】
ローカルコンテンツサブシステムモデル：
コンテキスト：
ローカルコンテンツサブシステムは、アプリケーションによって求められるあらゆるコンテンツを提供する。これには静的コンテンツ及び動的コンテンツの両方が含まれる。更に、アプリケーションが求めるビジネスサービスを提供する。「格納及び検索」に基づいて動作し、ユーザ又は企業から取得したデータを格納し、データを検索するメカニズムを提供する。ローカルコンテンツサブシステムは、コンテンツを提供するためにＩＳＦサブシステムによって使用される。通信サブシステムを使用して、ビジネスデータを受領する。
【０１７０】
アーキテクチャの概要：
ローカルコンテンツサブシステムのオブジェクトは、アプリケーションアーキテクチャの初期化サブシステムによって作成される。ローカルコンテンツサブシステムによって提供されるサービスは更に、アプリケーションアーキテクチャを通じて、初期化サブシステム及びＩＳＦサブシステムを介してアクセスされる。
【０１７１】
ローカルコンテンツサブシステムのコンテンツの例は、アプリケーションによって求められる様々なタイプのビジネス知識及びプロセスを反映する。ユーザデータ及びビジネスデータには、それぞれユーザ及び企業から収集したデータが関与する。計算コンポーネントは複雑な計算を実行し、製品コンポーネントは企業が使用する製品を表す。コンテンツプロバイダコンポーネントは静的媒体コンテンツを定義する。
【０１７２】
役割：
ローカルコンテンツサブシステムは、アプリケーションに静的及び動的コンテンツを提供する。更に、アプリケーションによって求められる、あらゆるビジネス固有サービスを提供する。
【０１７３】
責任：
ローカルコンテンツサブシステムは、アプリケーションに静的及び動的媒体を提供する。ローカルコンテンツサブシステムは更に、ユーザが入力した詳細、及びビジネスデータを格納し、ビジネスに関する計算を実行する。
【０１７４】
免責：
すべてのアプリケーション固有動作は、アプリケーションパーソナリティを通じて提供される。この動作は、ハムレットスクリプトによって定義され、これはスクリプト間のナビゲーションも定義する。このスクリプトはメタファに区分され、そのそれぞれは対話のスタイルの実施形態である。
【０１７５】
媒体へのアクセスは、このサブシステムに属するコンテンツプロバイダコンポーネントを通じて提供される。しかしながら、このコンポーネントのオブジェクトは、アプリケーションパーソナリティで定義されたコンテンツファイルから、システムイニシャライザコンポーネントによって自動的に作成される。
【０１７６】
作成、存続、及び管理：
ビジネスデータコンポーネントは、システム初期化の時期に作成及び初期化される。これはシステムの寿命に渡って存続する。
【０１７７】
ユーザデータコンポーネントは、顧客がシステムを使用している時間全体に渡って利用できる。顧客のセッションが終了した時、ユーザデータコンポーネント内のすべてのオブジェクトに対するリファレンスは、オブジェクトをガーベジコレクションできるようにリリースされる。
【０１７８】
ローカルコンテンツサブシステムのオブジェクトは（ビジネスデータコンポーネントを除き）、内部的に、或いは初期化サブシステムによって、作成及び初期化される。こうしたオブジェクトに対するリファレンスは、ＩＳＦサブシステムによって管理される。ビジネスデータオブジェクトは、通信サブシステムによって作成、初期化、及び管理される。
【０１７９】
論理コンポーネント：
ＩＳＦは、実際にはローカルコンテンツサブシステムに関する知識を持たない。ローカルコンテンツサブシステムは、ＩＳＦによって定義されたインタフェースのセットを実施する。初期化サブシステムは、アプリケーションパーソナリティで定義されたスクリプトを使用して、コンテンツを検索するために、（こうしたインタフェースを実施する）どのオブジェクトを使用する必要があるかを定義する。ＩＳＦは初期化コンポーネントを使用して、こうしたオブジェクトを作成し、その後、これらを管理する。
【０１８０】
アプリケーションパーソナリティの開発者は、ローカルコンテンツオブジェクトを直接管理することとして、自分のスクリプトを容易にとらえることができる。これにより、ローカルコンテンツオブジェクトは、アプリケーションアーキテクチャレイヤの知識を持たずに開発することができる。
【０１８１】
コンポーネントの説明：
ユーザデータ
ユーザによって入力されたデータを格納及び検索し、格納されたデータに関する計算を開始する。
ビジネスデータ
企業によって提供されたデータを格納及び検索する。
計算
複雑な計算を実行する。
製品
特定のマーケティング製品に関連する情報へのアクセスを提供する。
コンテンツプロバイダ
静的媒体へのアクセスを提供する。これはインタフェースの実施であり、別個のコンポーネントとしてドキュメントされない。
【０１８２】
インタフェースサポートフレームワークサブシステムモデル：
コンテキスト：
インタフェースサポートフレームワークサブシステムは、アプリケーションアーキテクチャレイヤの一部である。動的なマルチメディアインタフェースのあらゆる可能性を活用する豊かなインタラクティブ環境を提供する。このＩＳＦは、すべてのオブジェクトが動的な動作を行うことが期待される劇場のメタファを中心に構築される。
【０１８３】
ＩＳＦ内のオブジェクトは、アプリケーションアーキテクチャレイヤ内のアプリケーション初期化サブシステムによって初期化され、テクニカルアーキテクチャレイヤのコンテンツプレイヤ、印刷及び報告サブシステムを利用する。
【０１８４】
アーキテクチャの概要：
ＩＳＦ内のオブジェクトはアプリケーション初期化サブシステムによって初期化される。報告及び取引インタフェースサービスは、テクニカルアーキテクチャレイヤのためにＩＳＦデータをログし、レポート又は印刷するために使用される。テクニカルアーキテクチャ内のコンテンツプレイヤサブシステムは、ユーザに媒体を提示するために、ＩＳＦによって使用される。
【０１８５】
ＩＳＦサブシステムは、モデル・ビュー・コントローラのパターンに従った階層化アーキテクチャの上に構築される。事実コンポーネントは、ビジネスのオブジェクトモデルと、ビジネス媒体コンテンツの定義とを含む。視覚コンポーネントは、ユーザにビジネスモデルのビューを提供するために媒体を表示及び操作する。動作コンポーネントは、視覚コンポーネントと事実コンポーネントとの間のあらゆる対話を制御する。
【０１８６】
役割：
ＩＳＦサブシステムは、マルチメディアコンテンツを制御された形で提示するために、アプリケーションにサービスを提供する。更に、ユーザの入力に反応し、シーンの変化に影響を与える能力を提供する。
【０１８７】
責任：
ＩＳＦサブシステムは、アプリケーションのそれぞれのシーンを表示し、表示されている間にシーンのコンテンツを修正する。加えて、ＩＳＦサブシステムは、シーン間のナビゲーションを可能にし、ユーザ対話に反応し、ビジネスコンテンツを検索し、ビジネス関数及び計算を実行し、共通ユーザインタフェース構成子を提供する。ＩＳＦのその他の責任には、印刷ジョブ及びビデオ会議セッションを開始することと、ユーザのエントリをシーンにレポートすることと、セッションの持続時間と、役割とのユーザ対話と、ユーザのナビゲーションと、ＩＳＦ内で発生したエラーをレポートすることとが含まれる。最後に、ＩＳＦはユーザセッションを管理し、システムの起動及びシャットダウンといったシステムレベルのイベント又はスクリーンペイント要求に反応する。
【０１８８】
設計のガイドライン：
ＩＳＦサブシステムは、マルチメディアコンテンツを提示するためにアプリケーションにサービスを提供する。アーキテクチャ的にはモデル・ビュー・コントローラパラダイムに対応する３つの別個のコンポーネントに階層化される。これにより、コアビジネスオブジェクト及びそのデータ（モデル）は、この情報の視覚表現（ビュー）から分離され、モデル又はビューを制御し、これらの変化に反応するロジック（コントローラ）から分離される。このアーキテクチャは、システムのグラフィック的スタイル（ステージ、役割、及びシーン）と、動作コード（アクタ、シーンディレクタ、及びステージマネージャ）と、基盤となるコンテンツプロバイダ（ビジネスオブジェクト）との間の境界を提供する。これらのセクションは、視覚、動作、及び事実コンポーネントとなる。
【０１８９】
事実レイヤは視覚レイヤを認識しない。これにより、基盤となるビジネス領域モデルを混乱させることなく、視覚メタファは変化することができる。動作レベルは、事実レイヤと視覚レイヤとの間を仲介し、いずれかのレイヤとの非常に複雑な対話は避けるべきである。可能な場合は、レイヤ間の更なる相互依存性を回避するために、パブリッシュ／サブスクライブパターンによる匿名通信を使用がされる。
【０１９０】
ステージはディスプレイコンテキストとして特定される。これは制御するロケーションとのみ通信することができる。これはステージマネージャの影に隠れており、ステージマネージャではあらゆる視覚要求が管理される必要がある。
【０１９１】
ＩＳＦは階層システムである。シーン内のすべての役割は一連の視覚シブリングを形成する。これらの役割は、実際には、他の役割を含みカプセル化する。これにより、再帰を通じて、任意の数の別個の処理レイヤが可能となる。それぞれの子は直接の親とのみ通信し、その親を超えた通信の制御を放棄する。この封じ込め関係は、視覚レイヤ及び動作レイヤの両方において可能である。
【０１９２】
ナビゲーションを支援するために、シーンサムネイルが維持される。ユーザはシーンサムネイルに触れることで、以前訪れたシーンに戻ることができる。
【０１９３】
コンポーネントの説明：
視覚コンポーネント
ユーザ対話及びマルチメディアコンテンツの提示。
動作コンポーネント
アプリケーション動作及びマルチメディアコンテンツの検索。
事実コンポーネント
マルチメディアコンテンツとビジネス関数サービス及び計算を提供する。
【０１９４】
プロセス制御：
この表ではＩＳＦ内で実行される様々なキースレッドについて説明している。
【０１９５】
【表６】
0004294876.tif 000020
【０１９６】
ユーザがステージ上のロケーションにタッチ：
説明：
エンドユーザが、アプリケーションの可視ウィンドウ、ステージにタッチする。これにより、アプリケーションからの応答が開始される。
アクタ：エンドユーザ
関与するコンポーネント：視覚
関与するキーオブジェクト：ステージ
【０１９７】
ステージがユーザタッチを処理：
説明：
アプリケーションウィンドウは、タッチされたエリアによってどの位置が影響されるかを判断し、対応するタッチの役割に通知する。このステージは、ウィンドウ上に表示される視覚キューも制御する。
アクタ：エンドユーザ
関与するコンポーネント：視覚
関与するキーオブジェクト：タイマ、ユーザ対話レポータ、ロケーション、メディアプレイヤ
【０１９８】
役割がユーザタッチイベントを受け入れ：
説明：
それぞれの役割がユーザタッチを通知される。これにより、役割は、対応する媒体での媒体の変更を要求することを強制され、完了後、アクタにユーザ対話を通知する。
アクタ：ステージ
関与するコンポーネント：ビジュアル、動作
関与するキーオブジェクト：アクタ、役割
【０１９９】
アクタがイベントキャスティングをアクティベイト：
説明：
アクタはすべての登録済みキャスティングリストを循環し、特定のイベントに関心を有するすべてのキャスティングをアクティブにする。キャスティングは多形的に動作し、そのため、どのように反応するかの動作は、アクタではなくキャスティングに保持される。
アクタ：役割、実行キャスティング
関与するコンポーネント；動作
関与するキーオブジェクト：アクタ、キャスティング、ステージマネージャ、シーンディレクタ
【０２００】
ステージマネージャがシーンの移行を実行：
説明：
ステージマネージャは、ナビゲーションキャスティングの情報に基づき、現在アクティブであるシーンを新しいシーンに置き換える。どのように変化が発生するかを制御し、キオスクワールドの視覚的イリュージョンを持続することが重要である。
【０２０１】
このシナリオは、アプリケーションの起動、又は再起動時にも呼び出される。この場合、現在のシーンは存在しないが、アプリケーションはアプリケーションの第一のシーンへ移行するように命令される。
【０２０２】
アクタ：ナビゲーションキャスティング、システムイニシャライザ
関与するコンポーネント：動作、視覚
関与するキーオブジェクト：ステージ、シーンディレクタ、セッションマネージャ
【０２０３】
シーンディレクタがキャスト変更を実行：
説明：
シーンディレクタは、すべてのタイミングのアクティブ化を調整し、ステージマネージャへの任意のメッセージが共にグループ化され、適切な時期に連動するようにする。これにより、シーン上で見ることができる役割のあらゆる変化が同時に起こるようになる。
【０２０４】
アクタ：コンテンツキャスティング、スライドキャスティング
関与するコンポーネント：視覚、動作
関与するキーオブジェクト：シーンディレクタ、ステージマネージャ
【０２０５】
シーンディレクタがスライド効果によりキャスト変更を実行：
説明：
シーンディレクタは、スライドしないすべての役割をステージに上げ、その後、スライドキャスティングのコンテンツを、直線に沿って、最終的な目的地に表示する必要がある。
【０２０６】
アクタ：スライドキャスティング
関与するコンポーネント：視覚、動作
【０２０７】
ビジネスオブジェクトによるビジネス関数の呼び出し：
説明：
アプリケーションは、ビジネス領域モデルからのビジネス情報を要求することができる（例えば、支払額を戻す）。このインタフェースは、ビジネスオブジェクトに値を入れることもサポートする（例えば、ローン期間の金額として格納する）。それぞれのビジネスオブジェクトには、動作を呼び出すために一般的なインタフェースが提供される。望ましい動作は、ビジネス関数キャスティングにおいて指定され、これはビジネスオブジェクトに関連するアクタに情報を戻すことができる。
【０２０８】
アクタ：ビジネス関数キャスティング
関与するコンポーネント：事実
【０２０９】
ステージマネージャがインアクティブ状態からタイムアウト：
アプリケーションは、アトラクタシーンに戻る前にユーザがアプリケーションから立ち去った場合に備え、タイムアウト機能をサポートする必要がある。これにより、ユーザが入力した詳細のプライバシが守られる。
アクタ：ウェイトタイマ
関与するコンポーネント：動作
【０２１０】
セッションマネージャがアプリケーションをリセット：
説明：
アプリケーションの実行中、ステージを第一のシーンにリセットし、セッションをクリアしなければならない可能性がある。これはシステムのインアクティブ状態によって、或いはビジネスオブジェクトを通じてディスパッチされる直接的なユーザの要求によってトリガすることができる。
【０２１１】
アクタ：ステージマネージャのウェイトタイマ、ビジネスオブジェクト
関与するコンポーネント：動作
【０２１２】
セッション情報をリセット：
それぞれのセッションは、ユーザについて収集した情報を格納する。セッションの終わりにおいて、或いはユーザの要求により、すべての入力データを消去することができる。これはプライバシをサポートする。
【０２１３】
アクタ：セッションマネージャ
関与するコンポーネント：動作
【０２１４】
反応媒体が媒体を表示：
説明：
ＩＳＦの視覚コンポーネントは、あらゆる媒体（画像、音声、動画、テキスト）をステージに表示することに責任を有する。これは、クライアントテクニカルアーキテクチャ内の基盤となる媒体サブシステムと実際にインタフェースする。それぞれのプレイヤは、ゲートキーパを通じて取得され、ユーザに媒体を提示するために必要なすべてのコードをサポートする。
【０２１５】
アクタ：役割
関与するコンポーネント：視覚、動作、事実、コンテンツプレイヤ
関与するキーオブジェクト：反応媒体、媒体プレイヤ、ステージ
【０２１６】
アプリケーションがハードコピーの印刷を要求：
説明：
クライアントアプリケーションは、静的情報（チェックリスト）又は動的情報（現在の利率と、製品、製品シミュレーション、及び又は線グラフのその他の動的コンポーネントとを含む製品説明）の印刷を要求できる。これは、エンドユーザによって、印刷キャスティングを通じて開始される。
【０２１７】
アクタ：印刷キャスティング
関与するコンポーネント：動作、印刷
関与するキーオブジェクト：ビジネスオブジェクト
報告インタフェースサブシステムモデル
【０２１８】
コンテキスト：
報告インタフェースサブシステムは、アプリケーションアーキテクチャレイヤによってログされた情報を収集し、テクニカルアーキテクチャレイヤのクライアント報告サブシステムに送る。
【０２１９】
アーキテクチャの概要：
報告インタフェース情報は、アプリケーションアーキテクチャレイヤ内のコンポーネントによってログされ、テクニカルアーキテクチャレイヤのクライアント報告サブシステムに送られる。
【０２２０】
役割：
報告インタフェースサブシステムは、キオスクとのユーザ対話をログするサービスを提供し、アプリケーションアーキテクチャレイヤ内で発生したソフトウェア及びハードウェア障害をレポートする。
【０２２１】
責任：
報告インタフェースサブシステムは、ユーザがシステムに行ったこと、例えば、ユーザがどのシーンを訪れているか、どの視覚要素と対話しているかを捕らえることで、キオスクとのユーザ対話を収集及びログすることに責任を有する。報告インタフェースサブシステムは、顧客が関心を持っているビジネス製品と、顧客が呼び出したビジネス関数の出力と、顧客が入力したビジネスデータとに関する情報も収集及びログする。最後に、報告インタフェースサブシステムは、キオスクのソフトウェア及びハードウェアの性能に関する情報を捕らえる。この情報は、その後、エラー処理及び障害管理分析のために使用することができる。
【０２２２】
免責：
報告インタフェースサブシステムには、顧客の名前及び電話番号といった顧客間連情報を収集及びログするサービスは含まれない。
【０２２３】
システム管理サブシステムモデル：
コンテキスト：
システム管理には、自動及び手動手続きの組み合わせの定義が関与する。自動化は、主にSystem Management Server（ＳＭＳ）の使用を通じて達成される。ＳＭＳは、Microsoft Backoffceツールスイートのツールであり、分散環境でシステムソフトウェア及びハードウェアを集中的に管理することができる。
【０２２４】
システム管理サブシステムモデルのアーキテクチャ：
システム管理サブシステムのアーキテクチャは、２つのコンポーネント、System Management Server（ＳＭＳ）、及び障害監視によって構成される。
【０２２５】
System Management Server（ＳＭＳ）：
System Management Server（ＳＭＳ）はマイクロソフトのツールであり、ソフトウェア／コンテンツの配布、ソフトウェア監査の実施、障害診断の実行、及びリモート制御の実施に使用することができる。ＳＭＳは、このアーキテクチャ用に開発されたコンポーネント、つまりファイル転送ユーティリティによって補足される。
【０２２６】
障害監視：
キオスクは、ハートビートメッセージシステムを通じてリアルタイムで監視される。ハートビートパルスは、設定された割合（例えば１分毎）でキオスクから送られ、キオスク監視アプリケーションを実行するコンソールで監視される。キオスクのステータスが変化して障害を示した場合、監視アプリケーションは適切な行動を開始する。一部のエラーは、既存の運用センタによって処理される。こうしたエラーの経路指定は、アプリケーションサービスサブシステムによってカバーされる。
【０２２７】
役割：
ＳＭＳは、中規模のソフトウェア配布（コード及びコンテンツの両方）及びリモートキオスクの障害診断に使用される。ＳＭＳを柔軟にする多数の特徴と、有効なサポート機能とが存在する。障害診断は、それぞれのキオスクと関連する周辺機器とのリアルタイムのステータスを見る手段を提供する。特定のキオスクで問題（用紙切れ等）が発生した時、そのキオスクに運用担当者の注意が向けられる。問題の解決方法を検証するためにキオスクのステータスを観察することができる。
【０２２８】
責任：
ＳＭＳは、ソフトウェア配布と、ハードウェア障害管理及び診断と、クライアントのリモートリブートとに責任を有する。ＳＭＳは、ネットワーク内のあらゆるキオスクのステータスを選択的に見るためのユーザインタフェースも提供する。
【０２２９】
作成、存続、及び管理：
ＳＭＳは、好適な実施形態による専用サーバに常駐し、常に利用可能である。
【０２３０】
性能：
ＭＭＴ上での障害の発生と、その後の運用端末での障害の表示との間の経過時間は、ハートビートの頻度、アプリケーションサーバがハートビートを処理する能力、及び運用端末でのリフレッシュの頻度に応じて変化する。
【０２３１】
好適な実施形態による例を以下に提示する。
【０２３２】
【表７】
0004294876.tif 000021
【０２３３】
ハートビートメッセージが５分以内にキオスクから受領されない場合（設定可能）、障害監視はキオスクのステータスを未知に設定する。このタイムラグは、実際の問題がハートビートメッセージの通常の処理時間よりも僅かに遅れて存在する時に、ＭＭＴマシンを誤って未知としてレポートするのを避けるために必要である。
【０２３４】
論理コンポーネント：
ＳＭＳサイトは、２つのコンポーネント−一次サイト及びクライアントによって構成される。一次サイトはＳＭＳ階層の最上レベルである。このサイトは、このサイト自体と下にある二次サイトとに関するシステム及びインベントリ情報を格納するための独自のＳＱＬデータベースを含んでいる。クライアント（キオスク）は、一次サイトから管理される。クライアントは、ＳＭＳインベントリサービスを通じて、ＳＭＳサーバにハードウェア／ソフトウェア情報を送る。
【０２３５】
障害監視：
設定可能な間隔の後、クライアントはマシン、プリンタ、及びアプリケーションのステータスチェックを行い、結果をハートビートメッセージによりサーバに送る。次にサーバは、運用スタッフによって障害の監視が行われるキオスクステータスデータベースにこのステータスを入れる。
【０２３６】
サーバ通信サブシステムモデル：
コンテキスト：
サーバ通信サブシステムモデルは、サーバテクニカルアーキテクチャの一部である。
【０２３７】
サーバ通信サブシステムは、クライアントと、中央サーバと、メインフレームホストとの間のあらゆる通信を処理する。
【０２３８】
アーキテクチャの概要：
非同期メッセージングコンポーネントは、標準インターネットメールプロトコル、ＳＭＴＰ、及びＰＯＰ３を使用して、クライアントとサーバとの間の非同期メッセージベースの通信を提供する。
【０２３９】
ビジネスプロセスアクセスモジュールコンポーネントは、ＭＭＴからの対話情報を記録するといった事前に定められたビジネス機能を呼び出すための共通ポイントを提供する。ＨＴＴＰは、ワールドワイドウェッブ上のＨＴＴＰサーバと通信するために使用されるプロトコルである。これは、起動時のクライアント設定プロセス中、アプリケーションコンポーネント及びコンテンツの小さな更新を配布するためにＭＭＴで使用される。メインフレーム常駐データベースへのアクセスは、必要なデータベースの表を対応するサーバ常駐データベースの表に複製することで行われる。逆のプロセスは、サーバで蓄積されたデータをメインフレームデータベースの表で集中的に格納するために使用される。サーバからの一般的な警告は、メインフレームのフロントエンドプロセッサとのインタフェースを通じて、メインフレームへ伝送される。
【０２４０】
役割：
サーバ通信サブシステムの役割は、サーバに、ＭＭＴ（又はインターネット）クライアントとネットワークサーバとの間、及びネットワークサーバとメインフレームシステムとの間の通信機能を提供することである。加えて、サーバ通信サブシステムは、組織固有機能へのアクセスを分離及び提供する。
【０２４１】
責任：
サーバ通信サブシステムは、標準インターネットプロトコルに従い、その伝達チャネルへの容易な移植を可能とする。加えて、サーバ通信サブシステムは、クライアントとアプリケーションサーバとの間の信頼性の高い非同期通信、及び組織固有機能への制御された信頼性の高いアクセスを提供する。最後に、サーバ通信サブシステムは、アプリケーションコンポーネント及びコンテンツ等のクライアントの設定に対する更新を伝達する機能を提供し、データベースの複製及び一般的な警告のレポート等の事前に定められたプロセスを通じて組織のレガシシステムへのアクセスを提供する。
【０２４２】
免責：
サーバ通信は、ＡＣＴメッセージングアーキテクチャに準拠するモジュールを呼び出すことに限定される。別のプラットフォームとの通信が必要な場合、これは組織のメッセージング又はアクセス方法を使用する外部システムモジュールの中に位置している必要がある。
【０２４３】
取引インタフェースサブシステムモデル：
アーキテクチャの概要：
取引は、アプリケーションアーキテクチャレイヤ内のコンポーネントによって開始され、テクニカルアーキテクチャレイヤ内のクライアント報告サブシステムに送られる。
【０２４４】
このドキュメントにおいて特定される取引サービスは、それ自体では独立したコンポーネントとして実施されないが、既存のアプリケーションアーキテクチャコンポーネントの拡張として実施される。
【０２４５】
役割：
取引インタフェースサブシステムは、エンドユーザに関するコンテンツ情報を格納するために、アプリケーションにインタフェースを提供することに責任を有する。これに含まれるのは、その一部として、ローンを完了するために必要な情報、顧客の人口統計に関する調査ベースの情報、勘定残高の質問、ファンドトランスファである。
【０２４６】
顧客リード取引実行：
顧客リード取引実行アプリケーションは、インタフェースサポートフレームワークを促進し、テクニカルアーキテクチャの報告サブシステムのサービスがエンドユーザに関する情報の収集及び格納をサポートすることを可能にする。
【０２４７】
免責：
取引インタフェースの現在の使用方法では、非同期通信のみが利用可能であることを仮定している。
【０２４８】
サーバアプリケーションサービスサブシステムモデル：
アーキテクチャの概要：
このアプリケーションサービスサブシステムは、ＭＭＴサーバアプリケーション及びアーキテクチャモジュールを構築するための定義のセットを含む。
【０２４９】
役割：
サーバアプリケーションサービスサブシステムは、アプリケーション及びアーキテクチャ機能にアクセスするためのサービス及び定義のセットを含む。このサブシステムは、アプリケーションサーバ又は運用ワークステーション端末上でアプリケーション及びモジュールを構築及び実行するための構造及びサポートサービスを定義する。サポートされる機能には、ＭＭＴとの間の取引処理、例えば、顧客紹介情報、顧客対話情報、ＭＩＳ情報、障害情報、製品レート及び価格情報、アプリケーション設定情報、メッセージ受領情報、及びハートビートステータス情報が含まれる。
【０２５０】
責任：
サーバアプリケーションサービスサブシステムは、基盤となるデータベース管理システムから独立して、サーバ上のアプリケーションビジネスロジックを処理する。このアプリケーションビジネスロジックには、顧客紹介情報、顧客対話情報、ＭＩＳ情報、障害情報、製品レート及び価格情報、アプリケーション設定情報、メッセージ受領情報、及びハートビートステータス情報が含まれる。
【０２５１】
サーバアプリケーションサービスサブシステムは更に、エラーのログ、一定のコードのデコード（例えば、「１」＝ＮＳＷ、「２」＝ＱＬＤ等）、及びそれぞれのマシンに位置するレジストリからの設定情報の検索を行うために、サーバ及びクライアントアプリケーションが利用可能な共通サービスを提供する
【０２５２】
最後に、サーバアプリケーションサービスサブシステムは、一定のＢＰメッセージに関するビジネスプロセス（ＢＰ）を呼び出す。
【０２５３】
論理コンポーネント：
サーバアプリケーションサービスサブシステムは、共通サービスと、データアクセスモジュールと、ビジネスプロセスと、ビジネスプロセスアクセスモジュールとを含む。それぞれのコンポーネントの定義は下の通りである。
【０２５４】
コンポーネントの説明：
定義：
共通サービス。コード表のデコードと、レジストリからの設定情報の検索と、メッセージ処理と、サーバアプリケーションのエラーのログ及び処理に関するサポートとを含むアプリケーション機能の開発をサポートする共通サービス。
【０２５５】
データアクセスモジュール。データアクセスモジュール（ＤＡＭ）は、アプリケーションデータベース内のデータへのアクセスを提供する。ＤＡＭは、挿入、削除、更新、選択、１つ以上の表の全選択といった特定のデータアクセスを実行する。これは、基盤となるＤＢＭＳにアクセスするためにＯＤＢＣを使用するレコードセットオブジェクトをカプセル化するＭＦＣ拡張ＤＬＬである。ＤＡＭの定義は、こうしたモジュールがどのように使用及びコード化されるかの概略を表す。
【０２５６】
ビジネスプロセス。ビジネスプロセス（ＢＰ）は、ビジネスプロセスアクセスモジュールアーキテクチャによって呼び出すことが可能なアプリケーション又はアーキテクチャ機能である。ＢＰはメッセージタイプによって特定される。ＢＰは、ＢＰによって定義された要求メッセージを受け入れ、同期メッセージに応答メッセージを提供することができる。データベースアクセスは、ＤＡＭＳによってＢＰに提供される。ＢＰは定義済みエントリポイントを有するＭＦＣ拡張ＤＬＬである。
【０２５７】
ビジネスプロセスアクセスモジュール。このコンポーネントは通信サブシステムにおいて詳述されている。ビジネスプロセスアクセスモジュール（ＢＰＡＭ）は、ビジネスプロセスへのアクセスを提供するアーキテクチャコンポーネントである。ＢＰＡＭは一定のメッセージタイプに関するＢＰを呼び出す。ＢＰＡＭはメッセージアドレス表にアクセスし、ＢＰモジュールの詳細をルックアップする。このコンポーネントは通信サブシステムにおいて詳述されている。
【０２５８】
好適な実施形態による無線電子バレット：
本発明の１実施形態は、モバイルポータル及び電子バレットを含むモバイルポータルプラットフォームである。電子バレットは、シンクライアントソフトウェアを実行するハンドヘルド型無線コンピュータ装置である。電子バレットには、ＧＰＳ、バイオセンサ、及び環境センサといった様々なセンサが統合される。加えて、カメラ及び音声レコーダ等の記録機器も電子バレットに統合される。モバイルポータルには、インターネット又はモバイルポータルエクストラネットを通じて、様々なサードパーティのコンテンツ及びサービスプロバイダに接続されるモバイルポータルサーバが含まれる。
【０２５９】
図２６は、本発明の１実施形態のハードウェア及びソフトウェアがどのように動作するかを表したフローチャートである。電子バレット２６０２は、この無線ハンドヘルド型装置に統合されたセンサ、ＧＰＳ、カメラ、マイクロフォン、及びその他のユーザ入力２６００からの入力データを受領する。電子バレット２６０２上で実行されるシンクライアントアプリケーションにより、下で詳しく説明するように、電子バレット２６０２は、大量の内部メモリ及び記憶容量を必要とせずに、多数の異なるソフトウェアアプリケーションを実行することができる。電子バレット２６０２は、受領したデータ及びユーザ入力に基づいてメッセージを形成する。その後、電子バレット２６０２は、アンテナ２６０４を介して、モバイルポータル２６０６にメッセージを伝送する。モバイルポータル２６０６は、電子バレット２６０２から受領したメッセージをパースし、受領したメッセージに基づいて新しいメッセージを形成する。次に、モバイルポータル２６０６は、無線ハンドヘルド型装置２６０２から受領したメッセージのコンテンツに基づいて、新しいメッセージを伝送するのに適切なサードパーティサービスプロバイダ２６０８を判断し、その後、新しいメッセージを伝送する。次に、サードパーティサービスプロバイダは、適切なサービスを実行し、結果をモバイルポータル２６０６に返送する。その後、モバイルポータルはサードパーティサービスプロバイダ２６０８から受領したデータに基づいてメッセージを形成し、このメッセージを電子バレット２６０２に返送する。その後、電子バレットは受領したデータをフォーマット及び表示する。電子バレット２６０２は、メトリコムのＲｉｃｏｃｈｅｔ  ＳＥ  Ｗｉｒｅｌｅｓｓ  Ｍｏｄｅｍ等の無線モデムを利用する。
【０２６０】
当然ながら、無線性能には、従来のダイヤルアップ接続と同様の信頼性はない。サンフランシスコのいくつかの場所では、窓の近くにいる限り、強力な接続を得ることができた。しかし、ＣＮＥＴの総レンガ造りの本社内では、Ｒｉｃｏｃｈｅｔはまったく接続できなかった。オンラインでつながっている時は、遅い速度へのゆっくりとした低下と共に２８．８ｋｂｐｓまでの性能が利用できる。しかし、遅い速度でも失望はなかった。代替方法――セルラモデムによる接続――に比べ、Ｒｉｃｏｃｈｅｔは遥かに速く、信頼性があり、使用コストが少ない。当然ながら、このＳＥ  Ｗｉｒｅｌｅｓｓはバッテリ電源である。このモデムの連続バッテリ寿命は１２時間までである。
【０２６１】
したがって、無線モデムを利用することで、ユーザは電子バレット２６０２を介してモバイルポータル２６０６を利用することができる。適切な（複数の）キーを使用することで、ユーザは、センサ、ＧＰＳ、カメラ、マイクロフォン、及びその他のユーザ入力２６００から取得した適切なデータに呼応して、使用するサービスを選択することができる。
【０２６２】
特定の状況においては、電子バレット２６０２から取得したデータのタイプ及び値に基づいて選択したサービスにデータを自動的に送ることができる。例えば、統合されたバイオセンサが特定の事前に定められたデータ値を取得した時、適切な救急治療提供者が自動的に連絡を受ける。加えて、センサ、ＧＰＳ、カメラ、マイクロフォン、及びその他のユーザ入力２６００から取得したデータは、適切なサービスプロバイダへ送る前に組み合わせることもできる。例えば、上の例では、ＧＰＳ位置データをバイオセンサのデータと共に救急治療提供者に送ることができる。救急治療提供者はこれにより、患者の生物学的データと患者の位置とを知ることになる。その後、適切なサービスが提供される。
【０２６３】
モバイルポータルプラットフォーム：
モバイルポータルプラットフォームは、好適な実施形態によるインパクトの強いサーバベースのアプリケーションであり、サーバ上に位置するパーソナルサイトを通じて、それぞれの顧客にサービスを与え、パーソナライズされた体験を提供するというテーマに注目したものである。直観的に編成されるこのサービスは顧客の意図−基本的な生活のニーズ又は広範なプランニングを要する判断と、財務プランニング、ヘルスケア、個人的及び職業的成長、家族生活、その他の問題といったいくつかの次元に渡る調整を満足させることを中心に直観的に編成されている。それぞれのメンバーは自分自身のプロフィールを保有及び維持しており、これにより、自分自身を限定的にターゲットとするシステムにおいてコンテンツを作成及びブラウズすることが可能となる。サービスの要求を入力した時点から、インテリジェントエージェントを利用して、リサーチが実施され、取引が実行され、アドバイスが提供される。高度なプロファイリング及びフィルタリングを使用することで、インテリジェントエージェントはユーザについて学び、提供するサービスを改善する。
【０２６４】
システムの好適な実施形態では、ＧＰＳレシーバ付きＷｉｎｄｏｗｓ  ＣＥ  ＰＤＡを利用する。この実施形態は、複数の店舗を含むショッピングセンタ用に構成されている。このシステムはＧＰＳレシーバを使用して、ユーザの位置を判断する。このシステムの利点の１つは、ショッピングセンタ自体での何らかの特別な機器の存在に依存することなく、近くの店舗でデータを検索することが可能になる点である。小型で安価なレシーバの精度は約７５乃至１００フィート（２３乃至３１ｍ）に限られているが、これはこれまでのところ、近辺の店舗を正確に特定するために必要なすべてであることが証明されている。このシステムは、実際の店舗の広告及び価格ではなく、生成されたデータを使用する。十分に構造化されたオンラインカタログが使用される。他の実施形態では、比較的小さな量の知識を使用して一定の店舗で「止まることを学習する」エージェントを利用する。更に、小売店がオンラインカタログを使用するための標準パッケージを使用し始めるにつれ、異なるフォーマットの数が減ることが予想され、結果として、競合するフォーマットの数は対応が容易なものになる。電子商取引が進歩するにつれ、商品の提供をどのように表すかの管理を発展させる標準を期待することも不合理ではない。
【０２６５】
目的指定：
買い物に出かける前に、買い物客は、約８５製品カテゴリ（男性用カジュアルパンツ、女性用フォーマルシューズ、花、その他）の既存のセットから、購入する品目のリストを作成する。買い物客は更に、ショッピングセンタのリストから、訪れるつもりの買い物場所を示す。
【０２６６】
初期の店舗選択：
ショッピングセンタに到着した後、最初に、目的指定中にユーザが入力したタイプの品物を少なくとも１つ販売している最寄りの店舗を示す。店舗名と共に、好適な実施形態のシステムは、購入可能な具体的な品目及びその価格のリストを作成する。ショッピングセンタの地図では、店舗の正確な位置と、その買い物客の現在の位置とを両方表示する。買い物客は、任意の時期に、現在の位置に基づいて店舗を示すように問い合わせる。
【０２６７】
ブラウジング：
全般的に特定の目的地を決めずにショッピングセンタを訪問又は買い物している多くの買い物客のニーズに対処する。図２７Ａは、本発明の好適な実施形態によるディスプレイを表している。このディスプレイは、ショッピングセンタ内を散策する時に買い物客が使用するブラウズモードで動作している。ブラウズモードでは、システムは、現在買い物客に最も近い店舗において販売されている関心のある品目を示す。品目は、目的スクリーンに入力されたカテゴリと一致する場合、関心のあるものとみなされる。関心のある品目がない場合は、特定の品目ではなく、その店舗で販売されている一般的な商品のタイプが表示される。買い物客が歩くにつれ、地図では、その買い物客のショッピングセンタ内での正確な現在の位置が表示される。ブラウジング中に表示された品目を買い物客が選択した場合、システムは買い物客に対して、同じ製品をより安い価格で提供している現地の小売店を警告するか、或いは現地の最安値を知らせる。このサーチは現地のショッピングモールに限定され、これは買い物客が移動する意志を有すると仮定された区域となる。
【０２６８】
代案：
強調する価値がある点として、本発明のエージェントはショッピングタスクの広範な態様をサポートし、例えば、双方向チャネルとして動作できる。つまり、買い物客に情報を提供できるだけでなく、買い物客の裁量において、小売店に情報を提供することもできる。この実施形態では、このシステムは買い物客の目的と好みを小売店ベースのエージェントに示し、このエージェントは次に、製品にサービスをバンドルしたカスタマイズされたオファーによって応答する。オファーのカスタマイズを可能にすることは、価格のみで競合したくない小売店の協力を得るために非常に重要であり、価格以外の基準に基づいて購入する顧客にとって価値のあることである。好適な実施形態は、主にショッピングタスクのコンテキストにおける位置ベースのフィルタリングに注目しているが、本発明は、物理世界において様々なタスクに従事する人に情報チャネルを提供する「物理的タスクサポート」エージェントの基盤を提供する。
【０２６９】
位置の予測値：
ユーザの物理的な位置は、ユーザのタスクを予測するのに非常に有効である場合が多いため、本発明は位置ベースではないエージェントに比べて大きな利点がある。誰かがボウリング場又は郵便局にいることが分かったなら、現在の活動を合理的に推測できる。ユーザの現在のタスクに関する知識は、そのユーザが有益と思う可能性が高い情報のタイプをほぼ決定する。ボウリングをしている人が郵便料金を、或いは切手を買っている人が最適なボウリングの球の重さを気にする可能性は低い。加えて、特定の場所でのリソース及び障害に関する知識は、その場所にいる人物にとって可能であり実行すると思われる行動の範囲を示す。ユーザにとって可能であり実行すると思われる行動に関するこうした認識は、ユーザが有益と思う可能性が高い情報のタイプに更に制約を加えるために使用できる。例えば、レストランのワインリストの知識は、提示するワインのアドバイスに制約を加えるために、推奨システムによって使用することができる。
【０２７０】
ショッピングセンタでの買い物客の正確な位置に関する知識は、買い物客の近辺の店舗の特定を可能にするため価値がある。買い物客に最も近い店舗の提供内容は、その買い物客がすぐに選択可能なものを意味する。その買い物客が、商品を直接調べることを重視し、他のストアへ行くことに伴うコストがある場合、最も近い周辺の店舗の商品は、その買い物客にとって最も可能性の高い当面の選択肢となる。結果として、任意の一定の時間に提供される最も有益な情報は、周辺の店舗における以前に述べた目的と一致する商品の入手可能性である。
【０２７１】
人間は自分の多くのタスクを実行する間に異なる場所へ移動する傾向がある。これは、その人物の近辺が、入手できる可能性のあるあらゆる範囲の選択肢を完全に捕らえていないことを示す。実際、ある場所を立ち去る大きな理由の１つは、現在の場所では不可能な行動を実行することである。それにもかかわらず、人間には比較的近くのエリア内でほとんどのタスクに対処する傾向がある。したがって、自分の近辺は一定の時点で利用可能な選択肢を示し、更に広範な場所の観点はタスクを行う過程で考慮する可能性の高い選択肢を捕らえている場合が多い。ショッピングセンタでの買い物の場合、例えば、買い物客の近辺の店舗は、その時点で利用可能な選択肢を表す。しかしながら、ショッピングセンタの買い物客は、一般にショッピングセンタ内の任意の店舗に移動する意志を有する。そのため、買い物全体での可能な選択肢には、ショッピング内のすべての店舗が含まれる。したがって、関心のある提供物に関する情報を近辺の店舗のみから提示するのは、これらがすぐに利用可能な選択肢となるためである。代案を求められた時、システムはショッピングセンタ内のすべての店舗―つまり、ショッピングタスク全体が実行される可能性が高いエリアにシステム自体を限定する。数百又は数千マイル離れた店舗が、最も安価な現地での代案よりも数ドル安く同じ商品を販売していることを警告されても、買い物客が問題の商品を直接調べる必要がある場合、或いは出荷を待つ意志がない場合にはほとんど価値がない。
【０２７２】
物理的ショッピング対オンラインショッピング：
位置ベースではないエージェントに対する大きな利点に加えて、本発明はオンライン（又はＷｅｂ）ショッピングの欠点を克服する。更なるホームコンピュータの浸透、オンラインでの提供物の拡大、及び優れたオンラインショッピングツールのみによって、やがてオンラインショッピングが支配的なショッピング形態になるという主張は魅力的である。そのため、一見したところでは、後にバーチャル化される活動をサポートするために場所を使用し始めるのは誤りのように思える。既に、オンラインショッピングをサポートする多数のソフトウェアエージェントが出現している。例えば、ユーザが音楽ＣＤの最も安価なソースを特定することを可能にするプログラムに名称が与えられている。同様のプログラムは、BargainBot等、書籍の購入に関しても開発されている。こうしたシステムは、特定の商品に関する完全な市場を創り出す電子商取引Ｗｅｂエージェントの可能性を実証している。こうしたエージェントの成功は、更に多様な商品に関する同様のＷｅｂショッピングエージェントの開発を促進する。
【０２７３】
オンラインショッピングの限界：
間違いなく、オンラインショッピングの成長は続き、更に強力なオンラインショッピングエージェントに向かう傾向は継続する。それにもかかわらず、Ｗｅｂエージェントがどれだけ精巧になったとしても、予測可能な未来において、従来の物理的ショッピングが市場を支配し続けることは明らかであると思える。オンラインショッピングに内在するいくつかの難点は、物理的ショッピングの継続的な信頼を確かなものにする。
【０２７４】
代替不能物：
Ｗｅｂベースのショッピングエージェントは通常、書籍及び音楽ＣＤといった代替可能製品に関する最も安い価格をユーザが特定することを可能にする。こうした商品に関する「完全な市場」を創り出す能力は消費者にとって大きな恩恵だが、こうしたアプローチを任意の製品に応用することを複雑にするいくつかの難点が存在する。
【０２７５】
商品がショッピングエージェントに特に最適なのは、競合するオファーとの間での比較が容易なためである。商品は代替可能であるため、差異がある非常に数少ない次元は価格となる。そのため、価格は、唯一ではないものの、購入の判断を行う主要な基準となる。
【０２７６】
しかしながら、商品を超えて考えるとすぐに、他のいくつかの基準が重要になる。例えば、セータ、マットレス、又はテーブルといった品目をどのように比較するだろう？  価格に加え、使用されている材質と、色と、フィット感及び使い心地と、出来映えとに注意する。同様の問題は他のほとんどの製品に当てはまる。
【０２７７】
不正確な目的指定：
第二に、関連する難点は、自分の欲求をエージェントに伝えることにある。ショッピングエージェントは、自分の欲しい商品をユーザが正確に知っている場合には素晴らしい働きをする。この場合、ユーザは製品の名前を単純に入力すればいい。残念ながら、買い物する時に特定の品目を思いついていない場合、何が欲しいかをエージェントに伝える問題はもっと困難になる。例えば、ユーザは自分の居間に置きたいランプの種類をエージェントにどのように伝えればいいだろう？
【０２７８】
不明確な好み：
買い物客が、価格帯、色、オプション、ブランドその他といった特徴の説明を含めることを可能にするインタフェースは、上の問題に対処するのに役立つが、これは十分ではない。たいていの場合、買い物客は、ショッピングを開始し、目的の製品の様々な例を調べる機会を持つまで、好みを確立していないか、或いは欲しい物を正確に表現することができない。
【０２７９】
ショッピングは娯楽である：
人間は買い物が好きであり、特定の購入品が頭になくとも買い物をする。ある研究では、消費者の４２％は、レジャーとしてのウィンドウショッピング及び社交活動のためにショッピングセンタを訪れた「目的のない買い物客」である。
【０２８０】
ショッピングは感覚的である：
ユーザが、こうした詳細を効果的に提供できるとしても、大部分のユーザが購入の決断をこうしたエージェントに任せる可能性は低い。結局、多くの人は、信頼する配偶者であっても、自分の代わりに適切な購入を行うかどうかを不安に感じる。ほとんどの人は、購入の決断をする前に、考慮しているものを直接目で見て、手で触れたいと考える。エージェントに提供可能な僅かな好みを、この豊かな直接的な体験に置き換えることはできない。こうした好みは、買い物客が考慮する一連の候補を生成するのに使用できる程度のものである。
【０２８１】
瞬間的な満足感：
ショッピングは往々にして非常に感情的な活動となる。人間は購入品に満足し、家に帰って試してみるのが待ちきれない場合が多い。オンライン購入と受領との間の本質的な遅延は、確認後すぐに家へ持ち帰る必要がある人にとって大きな問題となる。
【０２８２】
結局、消費者は上で挙げた限界から、物理的ショッピングに従事し続けることになる。しかしながら、タスクを完全にソフトウェアエージェントに任せることができないという事実は、こうしたエージェントの役割を排除するものではない。第一に、欲しい物が分かっている時、商品の購入に関して、エージェントはユーザにとって有益である。しかしながら、第二の役割は、人間が物理的なショッピングタスクに従事する時間全体を通じて、これ自体をサポートすることである。これは当然ながら、ショッパーズアイプロジェクトにおいて用いられるアプローチである。
【０２８３】
ショッパーズアイ：
一見すると、本発明は、純粋なＷｅｂベースエージェントと同じ限界のいくつかによって影響を受けるように思える。結局のところ、自分の目的をＰＤＡに伝えることは、Ｗｅｂベースエージェントにつたえることよりも容易になるだろうか？  ＰＤＡシステムによってサポートされる購入では、Ｗｅｂベースエージェントの場合よりも自分の好みは明確になるだろうか？
【０２８４】
純粋なＷｅｂベースエージェントと現在の「物理的タスクサポートエージェント」（つまり、物理的な場面でタスクに従事するユーザをサポートするエージェント）との間の主な違いは、Ｗｅｂベースエージェントが、ユーザによって考慮されるあらゆる情報を伝えることに完全に責任を有する点にある。一方、好適な実施形態による「物理的タスクサポート」エージェントは、ユーザの環境の態様を参照することで、Ｗｅｂベースエージェントのアプローチを補強することができる。例えば、３０フィート（９ｍ）離れた店舗に特定のセータがある場合、そのセータの使い心地を十分に伝えることは極度に重要な事柄とはならない。必要なのは買い物客にそのセータを紹介することのみである。買い物客は、そのセータを試着してみることで、システムによって伝えることが可能ないかなる情報よりも遥かに優れたセータの認識を得ることができる。Ｗｅｂベースエージェントで不正確に指定された目的に一致する製品が多すぎる時は、更に限定的なサーチを行う必要がある。しかしながら、多くの一致は単純に、買い物客が大きな関心を持つ可能性が高い店舗が存在しているため訪問するべきであることを示しているに過ぎない。店舗に入ってしまえば、その人が関心を持つ商品の範囲を狭めることは、Ｗｅｂベースエージェント上で目的を精緻なものにすることより遥かに容易である場合が多い。そのため、物理的タスクサポートエージェントは、タスクの過程全体を通じて情報を伝達する手段として、物理的な環境の態様にユーザの注意を促すことで、ユーザが自分の好みを形にして、具体的な目的を特定するのを支援することができる。
【０２８５】
物理的ショッピングエージェントの約束：
物理的なショッピングがエージェントのコミュニティによって無視されてきたのは驚くべきことではない。結局、ごく最近になるまで、離れた場所にいる個々の買い物客にカスタマイズされた情報を届けるための信頼性の高い方法はまったく存在しなかった、しかしながら、ＰＤＡの爆発的な発展と、更に高度になる通信能力とは、ＰＤＡがユーザの居場所に関係なく「ジャストインタイム」に情報を伝える効果的なチャネルになることを約束している。本発明は、ショッピングタスクのあらゆる段階をサポートするチャネルの発展の約束を活用して、物理的ショッピングをサポートする直観的な新しいエージェントを提供し、以下を含む前記の問題を解決する。
【０２８６】
目的の指定：
買い物客は最初に、関心を持っている商品の少なくとも一般的なカテゴリを示す。ショッピングエージェントは、様々な特定性の度合いにおいて、目的の指定を可能にする必要がある。本発明では、こうした目的はタスクの進捗と共に精緻なものにすることができる。
【０２８７】
製品スペースの調査：
買い物客は、選択を行えるようになる前に、利用可能なものについて知識を得る必要がある。ショッピングエージェントは、様々な提供内容のクラス、レビュー、実演その他を提示することで、このタスクを支援できる。本発明の物理的ショッピングエージェントは、現地で利用可能な提供内容のツアーを買い物客に提供することで、これを補強することができる。
【０２８８】
好みの精緻化：
買い物客が利用可能なものを学習し、提供内容を吟味するにつれ、買い物客の好みは発展していく。エージェントは、買い物客が経時的に好みを精緻化するのを可能にする必要がある。本発明により、ユーザは好みを精緻化することができる。
【０２８９】
候補製品の特定及び比較：
買い物客は、自分の欲しいもの及び入手可能なものを理解し始めるにつれ、通常、更に慎重に考慮する候補のリストを編集する。本発明のエージェントは、こうしたリストの構築及び維持をサポートし、様々な基準によるリスト内の候補の比較を容易にする。
【０２９０】
オファーの交渉：
本ショッピングエージェントは、買い物客に情報を提供することに限定されない。小売店との価格及びサービスオプションの交渉が可能となる。
【０２９１】
製品の選択、購入、及び製品サポート：
本発明は、取引自体を促進し、製品サービスを提供可能なチャネルとして使用することができる。
【０２９２】
図２７Ｂは、モバイルポータル２４１２と電子バレット２７１３とを含むモバイルポータルプラットフォーム２７１０の図である。電子バレット２７１３は、無線ＰＤＡ等のサポートハードウェア装置２７１６と、シンクライアントオペレーティングシステム２７１８の上で実行されるモバイルポータルシンクライアント規格２７１４とを含む。モバイルポータルは、暗号化及び解読要素２７２０と、インテリジェントエージェント２７２４を含むモバイルポータルサーバ２７２２と、顧客インテリジェント要素２７２６と、顧客データベース２７２８とで構成される。
【０２９３】
シンクライアントとは、削減されたハードウェアコストと、削減された維持及びサポートコストと、削減されたＬＡＮ／ＷＡＮ帯域幅要件と、短縮されたダウンタイムと、改善された性能と、強化されたセキュリティとの組み合わせによって、全体的な所有コストの削減を提供する、急速に現れつつあるテクノロジグループを表すために使用される一般的な用語である。シンクライアントの「シン（薄い）」という用語は、クライアントオペレーティングシステムの（非常に小さな）サイズを指す。対照的に、従来のＰＣオペレーティングシステム（ＤＯＳ、Ｗｉｎｄｏｗｓ９５、その他）は、その大きなサイズ及びリソース要件から「ファット（太い）」クライアントとみなされる。シンクライアントオペレーティングシステムがシンである事実にもかかわらず、シンクライアントの能力は堅牢である。クライアントソリューションは現在、ミッションクリティカルな環境に配備されており、無数のアプリケーションに信頼性及び反応性に優れたアクセスを提供している。モバイルポータルシンクライアント２７１４は、処理の大部分がモバイルポータルサーバ２７２２と、関連するサードパーティコンテンツ及びサービスプロバイダ２７３０とで実行されるシンクライアントである。ユーザはモバイルポータルシンクライアントアプリケーション２７１４を利用して、モバイルポータルプラットフォーム２７１０が提供するサービスを選択し、情報をレビューする。モバイルポータルシンクライアントアプリケーション２７１４は、シンクライアントオペレーティングシステム２７１８を使用して、多くの装置を独立させる。シンクライアントオペレーティングシステム２７１８は、モバイルポータルシンクライアントアプリケーション２７１４とサポートハードウェア２７１６との間のメッセンジャとして働く。シンクライアントオペレーティングシステム２７１８により、モバイルポータルシンクライアント２７１４は、ディスプレイ呼び出し及びユーザ入力クエリといった低レベルなハードウェア動作に関して、シンクライアントオペレーティングシステム２７１８に対して関数呼び出しを行うことができる。電子バレット２７１３用のサポートハードウェアとして使用されるそれぞれのハードウェア装置２７１６に関して、別個のシンクライアントオペレーティングシステム２７１８を開発することができる。これにより、モバイルポータルシンクライアントアプリケーション２７１４は、低レベル設計の修正を必要とせずに、異なるサポートハードウェア２７１６上で実行できる。
【０２９４】
モバイルポータル２７１２は、パケット交換無線ネットワーク２７３２を介して、電子バレット２７１３からデータを受領する。パケット交換無線ネットワークを通じて受領された情報は、その後、モバイルポータル２７１２の暗号化及び解読要素２７２０によってデコードされる。データがデコードされると、モバイルポータルサーバ２７２２はインテリジェントエージェント２７２４、顧客インテリジェンス２７２６、及び顧客データ２７２８を利用して、要求されたデータをサードパーティコンテンツ及びサービスプロバイダ２７３０から取得する。モバイルポータルサーバ２７２２は、インテリジェントソフトウェアエージェントを利用して、顧客のニーズに応答する。ソフトウェアエージェント２７２２は、顧客データ２７２８を利用して、個々のユーザの目的、習慣、及び好みに合わせてタスクをパーソナライズするための判断を行う。次に顧客データ２７２８は、顧客及び顧客の行動によって通常通りに更新される。ユーザがモバイルポータル２７１２を使用するたびに、ユーザによるクエリ及びその他のモバイルポータルプラットフォーム２７１０の使用に関してログが記録される。これにより、ソフトウェアエージェント２７２４は、ユーザの過去の習慣を利用して、タスクをパーソナライズすることができる。
【０２９５】
ソフトウェアエージェント２７２４に加え、モバイルポータルサーバ２７２２は、顧客インテリジェンス２７２６を利用して、ユーザのニーズに応答する。ユーザは、データの掘り出し及びパターン認識を利用して、望みの情報を見つけることができる。ここでも、顧客のデータ２７２８は更新され、ユーザによるデータの掘り出し及びパターン認識の使用が反映される。サードパーティコンテンツ及びサービスプロバイダ２７３０は、ユーザによって要求されたサービス及び情報を提供するために、モバイルポータル２７１２によって利用される。サードパーティコンテンツ及びサービスプロバイダには、インターネット又はモバイルポータルエクストラネットを通じてアクセスすることができる。インテリジェントエージェントソフトウェア２７１２は、サードパーティプロバイダをサーチし、顧客データ２７２８に含まれる顧客のプロフィールを考慮して、ユーザにとって最適なものを判断する。これにより、ユーザはクエリにおける特定性を、ユーザプロフィールがない場合に行わなければならないものに比べて減らすことができる。例えば、ユーザはモバイルポータルプラットフォーム２７１０を利用してジャケットを要求することができる。インテリジェントエージェントは、その後、顧客データ２７２８を利用して、顧客が実際に望んでいるものを更に具体的に決定する。この場合、顧客データ２７２８は、この特定のユーザがレザージャケットではなくデニムジャケットを好むことを知らせる。インテリジェントエージェント２７２４は、その後、デニムジャケットをサーチすることになる。当然ながら、ユーザプロフィールに格納されているものとは反対の情報を取得するために、ユーザはユーザプロフィールを無効にすることができる。提供される代表的なサービスの一部には、地理的位置情報、音声及び画像編集、個人向けニュース及び娯楽、個人向けショッピング、個人向け健康及び安全、個人用オーガナイザ、個人向け金融、及び個人用通信が含まれる。
【０２９６】
地理的位置サービスは通常、統合されたグローバルポジショニングシステムから受領した情報に基づく。ＧＰＳデータは、ユーザに位置固有の情報を提供するために特定のユーザ要求データと組み合わせる。例えば、ユーザがサンフランシスコにおり、この都市での良質な食事の情報を取得したいとする。このユーザは、電子バレット２７１３を利用して良質な食事の情報を要求する。統合されたＧＰＳレシーバから取得した位置データは、ユーザの良質な食事に関する要求と組み合わされ、その後、この組み合わせ済みメッセージがモバイルポータル２７１２に伝送される。受領したデータに基づき、モバイルポータルは適切なサービスを選択し、この場合はサンフランシスコでの良質な食事について、要求を伝送する。モバイルポータルは次に、受領した応答を電子バレット２７１３に返送する。その後、ユーザには要求した情報が提示され、電子バレット２７１３のディスプレイ装置上でフォーマット及び表示される。
【０２９７】
音声及び画像編集サービスは通常、統合されたカメラ及びマイクロフォンから受領したデータに基づく。ユーザは通常、統合されたデジタルカメラを利用して、画像を取り込む。しかしながら、ユーザは、スキャナ、電子メール、及びＷｅｂページといった他のソースからデジタル画像を取得することもできる。加えて、ユーザは通常、統合されたマイクロフォンを利用して音声ファイルを取り込む。しかしながら、音声ファイルは、電子メール、Ｗｅｂページ、及びＣＤといった他のソースから取得することもできる。画像及び又は音声データは、ユーザに画像及び音声編集能力を提供するために、特定のユーザ要求と組み合わせる。例えば、ユーザは、統合されたデジタルカメラによって画像を取り込み、その後、特定の写真エディタを使用して画像を編集することを要求できる。統合されたデジタルカメラによって取り込まれた画像は、次に、写真の編集に関するユーザの要求と組み合わされ、その後、この組み合わせ済みメッセージがモバイルポータル２７１２に伝送される。受領したデータに基づき、モバイルポータル２７１２は適切なサービスを選択し、この場合は画像編集の要求を伝送する。モバイルポータルは次に、受領した応答を電子バレット２７１３に返送する。その後、ユーザには要求した情報が提示され、電子バレット２７１３のディスプレイ装置上でフォーマット及び表示される。この場合、ユーザは画像編集用のインタフェースを受領することになる。ユーザはその後、この画像編集用ユーザインタフェースを使用して画像を編集する。画像の変更は要求として扱われ、モバイルポータル２７１２はこれを、ローカル又は独立したサーバで実行される画像編集アプリケーションに渡す。
【０２９８】
好適な実施形態による生物医学センサの統合：
本発明の１実施形態は、圧力トランスデューサ、呼吸センサ、ボリュメトリックセンサ、及び除細動器等の統合された生物医学センサを含む電子バレットである。
【０２９９】
血圧を測定するために統合圧力トランデューサは、浸透性および非浸透性の２つのタイプであり得る。浸透性統合圧力トランスデューサでは、ユーザは血流内にユニットの一部を埋め込む必要があり、非浸透性統合圧力トランスデューサは血流にアクセスする必要がない。圧力トランスデューサは、患者の血圧を測定し、この場合は電子バレットである受信ユニットにこれをレポートする。その後、電子バレットは、モバイルポータルシンクライアント及びモータルポータルサーバを利用して、圧力トランスデューサから受領したデータを分析及び経路指定することができる。
【０３００】
歪みゲージ及びボリュメトリックセンサ等の呼吸センサも電子バレットに統合することができる。胸部の周りに装着した歪みゲージは、呼吸中の胸の拡張及び収縮によるゲージの拡張及び収縮に従ってインピーダンスを変化させる。ボリュメトリックセンサは、患者がボリュメトリックセンサに息を吹き込んだ時等に、センサを通過する気圧の量を感知する。歪みゲージとボリュメトリックセンサとは両方とも、対応するデータを電子バレットユニットに無線伝送することができるため、ユーザには活動における大きな自由が与えられる。圧力トランスデューサから受領したデータと同様に、歪みゲージ及びボリュメトリックセンサから受領したデータは、モバイルポータルプラットフォームを利用して分析及び経路指定することができる。
【０３０１】
電子バレットに統合された除細動器は、心臓機能を感知するために利用することができる。除細動器は、生理食塩水ベースのゲルを利用して患者に取り付けられ、Ｒ、Ｔ、及びＰ波によって鼓動を探知する。歪みゲージ及びボリュメトリックセンサと同様に、除細動器はデータを電子バレットユニットに無線伝送することが可能であり、電子バレットユニットはその後、モバイルポータルプラットフォームを利用してデータを分析及び経路指定する。
【０３０２】
前記の生物医学センサは、特定のユーザのニーズに応じて、個別に統合すること、或いは環境センサ、他の生物医学センサ、又はＧＰＳレシーバ等のその他のセンサと組み合わせて統合することが可能である。例えば、心臓の問題に関する病歴を有する高齢のユーザは、統合された除細動器及びＧＰＳレシーバを含む電子バレットを有することができる。
【０３０３】
モバイルポータルプラットフォームを利用することで、ユーザは、有害である恐れがある様々な食品及び薬品を含め、自分の状態に関する最新のニュース及び情報を常に知ることができる。
【０３０４】
加えて、電子バレットは、ユーザの位置に関係なく、心臓の状態から発生する恐れがある問題を感知することができる。公園を散歩中、ユーザが胸の痛みを感じた場合、電子バレットは、ユーザの心臓の状態から発生した問題によって痛みが生じていることを感知する。これは、統合された除細動器と電子バレットの分析能力とを利用することで達成される。この場合、統合された除細動器から受領したデータが事前に定められた安全な閾値を超えたため、電子バレットは緊急事態が発生したことを警告される。モバイルポータルプラットフォームを利用することで、電子バレットはその後、適切な救急対応ユニットに通知を行い、その心臓に関するデータをユーザの医師に転送し、ユーザの家族に連絡する。
【０３０５】
加えて、電子バレットは、統合されたＧＰＳレシーバから受領した位置座標を、救急対応ユニットに転送し、ユーザの位置の特定及び救助を可能にする。病院での治療の後、モバイルポータルプラットフォームは、ユーザの食事及び栄養摂取、更には運動の日課及び投薬を含め、ユーザのアフターケアプログラムを調整することができる。
【０３０６】
好適な実施形態によるサポートコード：
以下のコードは、好適な実施形態によるＭｉｃｒｏｓｏｆｔ  Ａｃｔｉｖｅ  Ｓｅｒｖｅｒ  Ｐａｇｅｓ環境において書かれ実行される。これは主に、データベースの情報のクエリ及び格納を行うためにコード内に埋め込まれたいくつかのデータベース呼び出しを有するＭｉｃｒｏｓｏｆｔ  Ｊｓｃｒｉｐｔで構成される。
【０３０７】
意図中心インタフェース
【０３０８】
意図ＡＳＰページを作成する（「intention_create.asp」）
【０３０９】
【表８】
0004294876.tif 000022
0004294876.tif 000023
0004294876.tif 000024
0004294876.tif 000025
【０３１０】
意図リストＡＳＰページを検索する（「intention_list.asp」）
【０３１１】
【表９】
0004294876.tif 000026
0004294876.tif 000027
0004294876.tif 000028
【０３１２】
ユーザ意図リストＡＳＰページを表示する（「navigation.asp」から抜粋）
【０３１３】
【表１０】
0004294876.tif 000029
0004294876.tif 000030
【０３１４】
以上様々な実施形態を説明してきたが、これらの実施例は、限定のためではなく例示のために説明されたものと理解されるべきである。したがって、好適な実施形態の幅及び範囲は、上で説明した各実施形態例のいずれによっても制限されず、以下の請求項及びそれらの等価物によってのみ画定されるべきである。
【図面の簡単な説明】
【図１】  好適な実施形態による代表的なハードウェア環境を示すブロック図である。
【図１Ａ】  Ｗｅｂポータルネットワークに基づく従来技術のモバイルコンピューティングソリューションを示す図である。
【図２】  好適な実施形態によるシステムのフローチャートである。
【図３】  好適な実施形態によるシステムのパーシングユニットのフローチャートである。
【図４】  好適な実施形態によるパターンマッチングに関するフローチャートである。
【図５】  好適な実施形態によるサーチユニットに関するフローチャートである。
【図６】  好適な実施形態による全体的なシステム処理に関するフローチャートである。
【図７】  好適な実施形態によるトピック処理のフローチャートである。
【図８】  好適な実施形態によるミーティングレコード処理のフローチャートである。
【図９】  好適な実施形態によるポケットバーゲンファインダのプロセスフローを示すブロック図である。
【図１０Ａ】  好適な実施形態によるカスタマイズコンテンツＷｅｂページの作成に関連するロジックを示すブロック図及びフローチャートである。
【図１０Ｂ】  好適な実施形態によるカスタマイズコンテンツＷｅｂページの作成に関連するロジックを示すブロック図及びフローチャートである。
【図１１】  好適な実施形態によるユーザ中心コンテンツの検索に関連する詳細なロジックを示すフローチャートである。
【図１２】  好適な実施形態によるユーザプロフィールのデータモデルを示す図である。
【図１３】  好適な実施形態によるペルソナデータモデルを示す図である。
【図１４】  好適な実施形態によるインテンションデータモデルを示す図である。
【図１５】  好適な実施形態によるエージェントの現行統計の作成に関する処理のフローチャートである。
【図１６】  好適な実施形態によるユーザのための個人化された製品評点を決定するロジックのフローチャートである。
【図１７】  好適な実施形態による中央で保存されたプロフィールにアクセスするロジックのフローチャートである。
【図１８】  好適な実施形態によるユーザと特定のサプライヤのインテグレータとの間の対話ロジックのフローチャートである。
【図１９】  好適な実施形態による口頭サマリを生成するエージェント処理のフローチャートである。
【図２０】  好適な実施形態によるディスプレイログインを示す図である。
【図２１】  好適な実施形態による日常ロジスティックス管理ディスプレイを示す図である。
【図２２】  好適な実施形態によるユーザメインディスプレイを示す図である。
【図２３】  好適な実施形態によるエージェント対話ディスプレイを示す図である。
【図２４】  好適な実施形態によるアクティブナレッジ管理システムを示すブロック図。
【図２５】  好適な実施形態によるバックエンドサーバを示すブロック図である。
【図２６】  本発明の１実施形態のハードウェア及びソフトウェアがどのように動作するかを表すフローチャートである。
【図２７Ａ】  好適な実施形態によるブラウザモードのディスプレイを示す図である。
【図２７Ｂ】  好適な実施形態によるモバイルポータルプラットフォームを示す図である。
【符号の説明】
１１０  …  ＣＰＵ
１１６  …  ＲＯＭ
１１４  …  ＲＡＭ
１１２  …  バス
１１８  …  入出力アダプタ
１２０  …  ディスク記憶ユニット
１２４  …  キーボード
１２６  …  マウス
１２８  …  スピーカ
１３２  …  マイクロフォン
１３４  …  通信アダプタ
１３５  …  ネットワーク
１３６  …  ディスプレイアダプタ
１３８  …  ディスプレイ装置
１０１０  …  顧客のＷｅｂブラウザ
１０２０  …  インテグレータのＷｅｂサーバ
１０３０  …  意図データベース
１０４０  …  コンテンツデータベース
１０５０  …  サプライヤプロフィールデータベース
１０６０  …  顧客プロフィールデータベース
１０７０  …  サプライヤのＷｅｂサーバ
１０８０  …  製品情報データベース
１０９０  …  製品注文データベース
１０９１  …  顧客情報データベース
１７１０  …  プロフィールデータベース
１７２０  …  プロフィールゲートウェイサーバ
１７３０  …  パブリックインターネット
１７４０  …  テレビ
１７５０  …  業者
２０００、２２２０、２３１０  …  エージェント
２０３０  …  ロゴ
２０４０  …  ボタン
２１００  …  アニメーションエージェント
２１１０  …  旅行
２１２０  …  家庭の雑用
２１３０  …  金融
２１４０  …  市場活動
２１４２  …  アイコン
２１４６  …  ダイレクトリンク
２１５０  …  許可
２１８０  …  項目
２２００  …  世界のニュース
２２１０  …  ローカルニュース
２２３０  …  不動産
２３００  …  情報
２３７０  …  チャート
２３８０  …  ボタン
２３９０  …  ボタンのセット
２３９５  …  ヒント
２４００  …  バックエンド
２４１０、２４２０  …  マジックウォール
２４３０、２４３６  …  アウェアネスマシン
２４４６、２４４８  …  Ｗｅｂクライアント
２４５０、２４６０  …  電子メールクライアント
２７１０  …  モバイルポータルプラットフォーム
２７１２  …  モバイルポータル
２７１３  …  電子バレット
２７１４  …  シンクライアント
２７１６  …  ハードウェア装置
２７１８  …  オペレーティングシステム
２７２０  …  暗号化及び解読要素
２７２２  …  モバイルポータルサーバ
２７２４  …  インテリジェントエージェント
２７２６  …  顧客インテリジェント要素
２７２８  …  顧客データベース
２７３０  …  サードパーティコンテンツ及びサービスプロバイダ
２７３２  …  パケット交換無線ネットワーク
【図１】
0004294876.tif 000031
【図１Ａ】
0004294876.tif 000032
【図２】
0004294876.tif 000033
【図３】
0004294876.tif 000034
【図４】
0004294876.tif 000035
【図５】
0004294876.tif 000036
【図６】
0004294876.tif 000037
【図７】
0004294876.tif 000038
【図８】
0004294876.tif 000039
【図９】
0004294876.tif 000040
【図１０Ａ】
0004294876.tif 000041
【図１０Ｂ】
0004294876.tif 000042
【図１１】
0004294876.tif 000043
【図１２】
0004294876.tif 000044
【図１３】
0004294876.tif 000045
【図１４】
0004294876.tif 000046
【図１５】
0004294876.tif 000047
【図１６】
0004294876.tif 000048
【図１７】
0004294876.tif 000049
【図１８】
0004294876.tif 000050
【図１９】
0004294876.tif 000051
【図２０】
0004294876.tif 000052
【図２１】
0004294876.tif 000053
【図２２】
0004294876.tif 000054
【図２３】
0004294876.tif 000055
【図２４】
0004294876.tif 000056
【図２５】
0004294876.tif 000057
【図２６】
0004294876.tif 000058
【図２７Ａ】
0004294876.tif 000059
【図２７Ｂ】
0004294876.tif 000060