JP2009516306A - メッセージリンクを利用するアプリケーションアクセス - Google Patents

Abstract

クライアント装置からプロキシサーバを介してアプリケーションサーバ上でアプリケーション機能の実行を成し遂げる方法を開示する。本方法は、アプリケーション機能実行の要求に関して第１のテキストメッセージを送信することを含む。本方法はさらに、上記テキストメッセージの発信元アドレスとは異なる確認アドレスを介してユーザを認証することにより、上記第１のテキストメッセージに関連づけられるユーザを認証することを含む。認証の後、本方法は、上記第１のテキストメッセージにより指定される通りにアプリケーションサーバにおいてアプリケーション機能を実行することも含み、これにより、上記第１のアプリケーション機能は少なくともテキストメッセージの宛先アドレスに基づいて確認される。

Description

今日の労働者は機動力を有するので、労働者がデスクを離れているときに内部ネットワークのリソース及びアプリケーションを安全に利用することが困難になる場合が多い。一般的な通信技術の１つに、電子メールが挙げられる。企業内で組織間の境界を越えて用いられる電子メールは、情報又は行動の伝達及び要求に用いられる。

ちょうど音声通信の場合の電話機のように、電子メールは、具体的には遠隔アクセス及びモバイルアクセスのための主要なビジネスアプリケーションとして採用されてきている。企業内では、電子メールは主要なビジネス通信プラットフォームである傾向があり、よって、ユーザのデスクトップ上でほぼ常時開かれている。電子メールはまた、無線ユーザのための主要なアプリケーションである傾向がある。

電子メールは当初、通常の物理的な郵便の電子的な拡張として開発されたので、原則的には非同期かつ自由な形式（フリーフォーム）である。一般に、非同期とは、ひとつの処理（例えば、電子メールを送信すること）が他の処理（例えば、電子メールを受信すること）とは独立して行われることを意味する。一方、同期とは、完了した又は中断中の動作（例えば、音声電話機による会話）である他の何らかの処理の結果としてのみ、１つの処理が行われることを意味する。電子メールメッセージは、一般に第１のユーザにより作成されて第２のユーザに送信され、続いて第２のユーザ側で引き続き読み出されるべくインボックス内の待ち行列に入れられ、おそらくは後に応答される。自由な形式は、電子メールメッセージにおける比較的少量の規格化された情報を指す。即ち、幾つかの固定のフィールド（例えば、宛先アドレス、発信元アドレス及び題名など）を除いて、電子メール文書自体の大部分は内容又は本文を含む。これは、一般に宛先の住所のみを必要とする通常の郵便のメッセージと同様である。

電子メールは、個人から個人へ送信されるという性格を有するので、一般に、ウェブブラウザなどのよりロバストなユーザインタフェースを有するより高度なクライアントアプリケーションを必要とするアクセスネットワークリソース（例えば、データベース、販売ツールなど）に対しては役に立たない。即ち、エラーは一般に比較的自由な形式であって規格化されていない、人が読み取ることのできるテキストによって示され、プログラムからプログラムへの通信ではこれが困難にされる。また、多くの移動無線装置（例えば、携帯電話機、ＰＤＡなど）は比較的小型であり、従って、内部ネットワークリソースの遠隔アクセスにとっては問題がある。現在の企業ソフトウェアプラットフォームはもともとこのタイプのアクセスのために開発されたものではなく、よって多くの場合、これらの無線装置からのアクセスをサポートするためには、多大な開発、実装及び管理費用を必要とする。

モバイル装置が音声以外のアプリケーションに対してユーザに提供するユーザインタフェースは、一般に、バッテリ持続時間の必要条件及び形式（フォーム）の要素に関する必要条件に起因して比較的粗末である。音声は別として、メッセージの受信は容易であるが、小さいディスプレイ及びキーボードはメッセージの送信をやっかいで問題のあるものにする。例えば、テキストメッセージの送信には、モバイルキーボードのサイズが比較的小さいことに起因して、多大な努力を必要とする場合がある。さらに、フルキーボードのない装置（大部分の携帯電話機上の数字キーパッドなど）は、事実上、データ送信をショートメッセージ（例えば、ＳＭＳなど）に制限する。

画面のサイズもまた、従来のクライアント／サーバのアプリケーション及びブラウザを用いることを制限する傾向がある。画面のパンニング又はＨＴＭＬからＷＭＬへの自動変換における試みにも関わらず、既存のアプリケーション及びウェブサイトは、一般にモバイル装置上の小さい画面では動作しない。ベンダによっては、特にモバイル装置を用いる労働者のために新規のバージョンのアプリケーション又はウェブサイトを書くことを選択しているものもあるが、これは容易な作業ではなく（１つの画面が多くのモバイル画面にならなければならない）、よって実装は高価である。また、モバイルソフトウェアに関しては移植可能性の規格が存在せず、現在の多様かつ急速な装置の開発を考えれば、この状況がすぐに改善されること目の当たりにすることを期待すべきではない。

１つ又は複数の実施形態において、本発明は、クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法に関する。クライアント装置はプロキシサーバに接続され、プロキシサーバはさらに、アプリケーション機能を実装するアプリケーションを実行するアプリケーションサーバに接続されている。本方法は、クライアント装置上のアプリケーション機能要求セットからアプリケーション機能を実行する要求を選択することを含む。本方法はさらに、上記要求に関する第１のテキストメッセージをプロキシサーバに送信することを含み、上記第１のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、上記第１のテキストメッセージはアプリケーション機能を実行する要求に関連している。本方法はさらに、テキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスのユーザへ認証メッセージを送り、上記認証メッセージに応答する確認をユーザから受信することにより、上記第１のテキストメッセージの発信元アドレスに関連づけられるユーザを認証することを含む。上記認証によってユーザが認証されるときに、本方法は、上記第１のテキストメッセージにより指定された通りにアプリケーションサーバにおいてアプリケーション機能を実行することも含み、これにより、上記第１のアプリケーション機能は少なくともテキストメッセージの宛先アドレスに基づいて確認される。

本発明の１つ又は複数の実施形態は、ユーザがクライアント装置を用いて１つ又は複数のサーバ上に存在する１つ又は複数のアプリケーションにアクセスすることを容易にするためのシステムを含む。上記システムは、ユーザから第１のユーザメッセージを受信し、当該第１のユーザメッセージに応答して認証アドレスを発生し第１の要求を確認アドレスに送信するように構成されたメッセージモジュールを含んでもよい。認証アドレスは、臨時のアドレスが発生された後又は第１の要求が送信された後、所定の時間期間（例えば、３分）で失効するように構成されてもよい。上記システムはまた、臨時のアドレスにおいて確認アドレスを発信元とする肯定の応答メッセージが受信されるときに、ユーザからの第２のユーザメッセージ及び第１のユーザメッセージのうちの少なくとも一方のユーザメッセージから命令を抽出するように構成されたパーサを含んでもよい。上記システムはまたさらに、命令が抽出されるときに、命令を１つ又は複数のサーバに伝達し、１つ又は複数のアプリケーションによって１つ又は複数の応答が発生されてクライアント装置に送信されることをトリガするように構成されたコネクタを含んでもよい。

以下、本発明の詳細な説明において、かつ添付の図面に関連して本発明のこれらの特徴及び他の特徴をより詳しく記述する。

本発明は制限としてではなく一例として示され、添付の図面において、同様の参照符号は同様の構成要素を示す。

以下、添付の図面に示されている幾つかの好ましい実施形態を参照して、本発明を詳しく説明する。以下の説明では、本発明の完全な理解をもたらすために多くの特定の詳細な事項について記述するが、当業者には、本発明がこれらの特定の詳細な事項の幾つか又は全てを用いることなく実施されてもよいことは明白であろう。他の例では、本発明を不必要に分かりにくくしないために、周知の処理ステップ及び／又は構成については詳述していない。本発明の特徴及び優位点は、諸図面及び下記の論考を参照することによってより良く理解することができる。

以下、方法及び技術を含む様々な実施形態について記述する。また本発明は、本発明の技術の実施形態を実行するためのコンピュータ読み取り可能な命令が記憶されるコンピュータ読み取り可能媒体を含む物品を包含してもよい点を考慮するべきである。コンピュータ読み取り可能媒体は、例えば、半導体、磁気、光磁気、光学又は他の形式のコンピュータ読み取り可能なコードを記憶するためのコンピュータ読み取り可能媒体を含んでもよい。さらに本発明は、本発明の実施形態を実施するための装置を包含してもよい。このような装置は、本発明の実施形態に関連する動作を実行する、専用の及び／又はプログラム可能な回路を含んでもよい。このような装置の例は、汎用コンピュータ及び／又は適切にプログラムされる場合には専用の計算装置を含み、コンピュータ／計算装置と本発明の実施形態に関連する様々な動作のために適合化された専用の／プログラム可能な回路との組合せを含んでよい。

本発明の一実施形態によれば、アプリケーション及び／又は情報アクセス装置（以下、アクセス装置という。）は、拡張された情報へのアクセス及び検索を促進するように効果的に用いられる。ある非自明な様式において、テキストベースのメッセージ（例えば、電子メール、ＳＭＳなど）は個人対個人の通信の形式を超えて拡張され、ウェブ上のトランザクション、アプリケーションデータ又はリソースなどの「もの」へのアクセスに向けられたプラットフォーム及びサービスの両方を提供してもよい。情報へのアクセス及び検索は、一般に、信任された（trusted）ものと信任されていない（non-trusted）ものの何れかであってもよい。信任とは、一般に、明白に規定されたルールのシステム（例えば、特権、制限、権利など）の遵守に対する第２の当事者の意向に関して第１の当事者が有する信頼度を指す。

一般に、本アクセス装置は、信任されていない要求(non trusted requests）、信任されている発信元からの要求（trusted origin requests）及び信任が厚い要求（highly trusted request）の３つのタイプの要求を区別する。二人の当事者間で転送されている情報が、その一般的な開示に比べて特に価値のある情報ではないとき、あるいは一般に慎重に取り扱う必要がない情報ではないときには、一般に、信任されていない関係性が確立される。信任されていない要求は、任意の者／任意の場所から受け入れられてもよく、結果は送信者に返される。これは、単純な公開又は公衆タイプのトランザクションである。ある実施形態では、本アクセス装置は、慎重に取り扱う必要がない情報（例えば、ニュース、天候、交通など）をテキストベースのメッセージングアドレスが返す信任されないサービスを生成するために用いられてもよい。例えば、あるニュースの話題を電子メールの題名とする電子メールメッセージをｃｍＮｅｗｓ＠ＣｌａｉｒＭａｉｌ．ｃｏｍなどの電子メールアドレスに送信することにより、その話題に関するニュースを含む応答が受信されてもよい。

信任されている発信元からの要求は、登録されているユーザのリストに記載されている又は外部のソース（例えば、ＬＤＡＰ、ＭＳアクティブディレクトリなど）から導出される、設定済みのユーザ（信任されているユーザのアドレスのセットを含む）からに限定的に受け入れられてもよい。正しく認証されない要求（例えば、スパムなど）は直ちに拒絶され、応答は適切な信任されているアドレス（必ずしも送信者宛でなく）のみに返されてもよい。ＳＭＳアドレスは、装置に固有のものであるので、応答アドレスとして特に有益である。

このようにして、登録ユーザとしてアクセス装置をいたずらにだまそうとする未登録の侵入者は検出され、よって、応答において信頼のある情報を受信することはできない。また、信任されているユーザアドレスを用いる技術も、他の当事者にとって未知の第三者が一方の当事者からのメッセージを傍受して第２の当事者に転送するという状況である、介入者攻撃に耐える。

信任が厚い要求は、トランザクション確認の送信者の認証をさらに必要とする、信任されている発信元からの要求である。例えば、信任が厚い要求は、銀行口座間の資金振替に用いられてもよい。確認メッセージは、まず、予め手配された「認証アドレス」に送信されてもよい。信任されている要求の場合と同様に、登録ユーザはこれらの確認メッセージが送信されるアドレスを定義するが、当該アドレスは、必ずしも上記要求の発信元である装置又はプロトコルと同一ではない。

次に、確認メッセージ又は短い時間期間の間だけ有効な認証トークン（タイムスタンプを含む）が暗号化されてもよい。一般に持続期間は、暗号化の解読に必要な時間が、メッセージが有効である時間ウィンドウより実質的に長くなるように選ばれる。ユーザは次に、おそらくは例えば個人識別番号（ＰＩＮ（personal identification number））である何らかの情報を確認メッセージに追加して当該確認メッセージに応答し、システムをより安全にしてもよい。即ち、暗号化メッセージが傍受されてＰＩＮなしに返されるときに、そのトランザクションは認証されないことになる。アクセス装置によって応答が受信され（かつＰＩＮが適宜チェックされ）ると、トランザクションは認証され、実行され、「完了をマーク付け」される。トランザクションは一度しか実行され得ないので、上述したように、この最後のステップは介入者攻撃から守るために用いられる。例えば、振替金額を電子メールの題名にしてｃｍＴｒａｎｓｆｅｒ＠ＣｌａｉｒＭａｉｌ．ｃｏｍなどの電子メールアドレスを打ち込み、確認に対して応答すれば、ユーザは予め指定された２つの口座間で資金の振替を開始することができる。

また、ロバストな認証メカニズムはまた、スパム（例えば、求められていないバルクメッセージなど）を実質的に低減することに役立つ。スパムは、事実上誰でも大量の電子メールを事実上無料で送信できるので、残念ながら電子メッセージを用いる誇大広告及び勧誘を促進している。懸念が重大レベルに達しつつある今、大部分の企業はそのメッセージングシステムをスパムの洪水から保護すると同様に、不正なメッセージを不正な場所に跳ね返すことによって自らもスパムのソースになることを回避しなければならない。

例えば、スパムの送信者は、スパムの送信者がブロックされているネットワークに接続する方法を発見する試みにおいて、偽造であるが有効な送信者アドレスを有するメッセージを第３のサイトの無効な宛先アドレスに送ることがある。結果的に、第３のサイトの電子メールサーバは、上記メッセージを配信することができずに、当該配信されなかった（スパム）メッセージのコピーを、サーバが送信者と信じる者に、この場合は上記偽造の送信者アドレスに送り返すであろう。

また、無効な宛先アドレスは、サービス拒絶攻撃を実行する目的で用いられることがある。例えば、攻撃者からのメッセージは、無効な宛先アドレス及び無効な返信用アドレスの両方を用いて電子メールサーバに送られることがある。上述の場合と同様に、メッセージは配信され得ないので、電子メールサーバは実在しない送信者に応答し、これにより、メッセージはもとの電子メールサーバへと跳ね返されることになる。結果的には、メッセージの送信ループが生成される場合があり、最終的に、多大なネットワークリソースが消費され、よって適正なトラフィックを送信することができなくなる。

本アクセス装置はまた、認証技術を用いることにより、正当なユーザのみのために情報がアクセスされトランザクションが実行されることを保証する。特に、アクセス装置は、クライアント装置に送信される暗号化されたトークンを用いてもよい。ユーザは、応答し、又はトークンを迅速かつ正確に提出しなければならない。トークンは数分で失効するので、盗聴者には解読する時間がない。ユーザが（オプションとして、追加のパスワード又はＰＩＮを用いて）応答すると、トークンはキャンセルされるので、盗聴者は複製されたメッセージを用いてトランザクションに影響を与えることができない。この技術は、単純な装置のみを用いて、モバイル装置内の暗号化／復号化を必要としない認証動作を保証する。一般に、モバイル装置では、バッテリの寿命を長くするために、比較的低い性能のプロセッサが用いられることが多い。結果的に、モバイル装置は、計算集約的な暗号化／復号化タスクのためには最適化されない傾向がある。

また、本アクセス装置は、内部及び外部ソースの両方への管理された企業内アクセスのために、ホスト型のアクセスインフラストラクチャを許容してもよい。これはさらに、拡大された生産性及びオーナ総所有コスト（ＴＣＯ（total cost of ownership））を許容する、アプリケーション及びウェブサービスへの指向的なトランザクションアクセスのための管理可能なインフラストラクチャを提供してもよい。ある実施形態では、シンプルリクエストアクセス（ＳＲＡ（simple request access））プロトコルがアプリケーション及び情報への安全な指向性のテキストベースのメッセージングアクセスをもたらし、ユーザ生産性を拡大してサポート及びトレーニングコストを下げる。即ち、ユーザのデスクトップコンピュータ、ラップトップコンピュータ、モバイル装置、ＰＤＡ、スマートホン、無線電子メール装置などに追加のソフトウェアをインストールする必要はない。

典型的には、「アクション」又は「トランザクション」に関するテキストベースのメッセージングアドレスを、単純な指向性の要求から複雑なアクションが実行されることを可能にするプラットフォーム内で発生することが可能である。単一の要求又はメッセージは、複数のアプリケーションをスパンし、統合された又は調整された結果をもたらしてもよい。また、同一又は異種のアクセスの信任状（クレデンシャル（credential））をそれぞれ用いる複数のアプリケーション問い合わせ（クエリ）の結果は、統一された結果に統合されてもよい。

これで、ユーザのアドレスブックに記憶されるテキストベースのメッセージングアドレスは要求のタイプを定義することができる。また、要求者に関連する情報は、シンプルリクエストアクセス（ＳＲＡ（simple request access））サーバなどの情報／アプリケーションアクセスサーバ（アクセスサーバ）におけるプロフィールデータベースによってもたらされてもよく、要求の履歴のロギングが可能である。

一般に、ロギングには２つの方法がある。第１のタイプでは、クライアントのログがクライアント装置のインボックスで保持されてもよく、上記インボックスでは、送受信される全てのメッセージのコピーが後のアクセス及び検索のために記憶される。第２のタイプでは、サーバのログがアクセスサーバにおいて保持されてもよい。一般に、サーバのログは、ユーザ名、タスク、時刻などのトランザクション情報を記録する。その結果、アクセスサーバは、サーベンスオクスリー法（Sarbanes-Oxley Act）などの企業管理ガイドライン及び規制によりしばしば要求される実質的に高レベルの監査能力を提供してもよい。

本アクセス装置は、ＳＲＡ（simple request access（シンプルリクエストアクセス））アドレスを有する従来のテキストベースのメッセージングアプリケーション（例えば、電子メール、ＳＭＳなど）を最適化し、同期、ミニブラウザ及び高価な専用のクライアントアプリケーションなどの他の多くのアプローチの制限を回避する。テキストベースのメッセージに従来欠けているアクセス機能は、アクセスサーバに送信される単純な英数字のテキストメッセージ（又は記号（indicia）のセット）として提供されてもよく、アクセスサーバは、このメッセージに従って、要求された結果を単純な電子メッセージを用いて返す。即ち、クレアメイル（ClairMail）のサーバは、ユーザのためのプロキシとして動作することにより、ユーザのパーソナルアシスタントとして動作してもよい。

ある非自明な方法では、各ＳＲＡメッセージはそれ自体の固有アドレスを有する。一般的に用いられるＳＲＡは、最小のキーストロークの素早いアクセスのために、他の従来のテキストベースのメッセージングアドレスと共にアドレスブック内に保持されてもよい。例えば、要求は、「顧客ＸＹＺの信用限度額はいくらか？」、「銘柄記号ＸＸＸの株価を入手する？」、「顧客ＸＹＺのためにＹＹＹを１００単位だけ発注する？」又は「ＸＸＸの株式を１００株売る？」である可能性がある。

ある実施形態では、これらの要求はそれぞれ、例えばａｄｄｒｅｓｓ＠ｓｅｒｖｅｒ．ｃｏｍなどの適切なアドレスへ、追加の適切なパラメータ（例えば、顧客番号／名ＸＹＺ、銘柄記号ＸＸＸ、売買する単位数又は株数、項目番号／名ＹＹＹなど）と共に送信されることも可能である。電子メールの構成は、特に、一般にアドレスの大きいセットを提供し、アドレスの大きいセットはトランザクション名のために大きいネームスペースを与える。

また、このアプローチはモバイル装置のために最適化されてもよいが、これは、任意の電子メールを使用可能な又は他のメッセージング能力を有する装置から用いられてもよい。１つ又は複数の実施形態では、要求はＳＭＳメッセージとして送信されることが可能である。１つ又は複数の実施形態では、要求をウェブサービスメッセージとして送信することが可能である。１つ又は複数の実施形態では、要求をＩＭ（インスタントメッセージ（instant message））として送信することが可能である。１つ又は複数の実施形態では、ウェブインタフェースを、詳細な要求を送信するために用いてもよい。１つ又は複数の実施形態では、所定の要求のために複数のプロトコルが結合されてもよい。１つ又は複数の実施形態では、要求は、要求のための所定のプロトコルを利用してもよく、異なるプロトコルを用いることにより要求結果を返してもよい。次には、要求に関するＵＲＬ（ユニバーサルリソースロケータ（Universal Resource Locator））を、容易な検索のためのブックマークＵＲＬとしてブックマークしてもよい。

また、ＳＲＡは、比較的強力であるが単純でもある安全なユーザインタフェースを提供する。一般に、企業アプリケーションはセキュリティ及び信頼性を要求する。セキュリティは、機密情報が内密に、かつ盗聴者を避けて保たれることを必要とする。一方で、信頼性は、メッセージが、当該メッセージが発信者であると意図する者から到来していることを必要とする。アクセス装置は、一般に信任されているアドレスを含むメッセージを受け入れることによって、実質的にロバストなメッセージ認証を可能にする。即ち、望まれないメッセージ又は不正な送信者は検出されて回避されることが可能である。

普及しているメッセージプロトコル（ＳＭＳ、ＳＭＴＰ）は一般に安全ではないので、容易に傍受されかつ不正に応答される可能性がある。１つの解決方法として、メッセージがソース側で秘密鍵を用いて暗号化され、次いで送信者の公開鍵を用いて宛先側で復号化される公開鍵インフラストラクチャ（ＰＫＩ（public key infrastructure））技術が用いられてきている。今日のモバイル装置はＰＫＩを用いるのに十分なメモリ及び計算能力を有する場合もあるが、一般に秘密鍵を安全に保持するためのメカニズムを設けていない。

例えば、（想像することは極めて困難であろう）秘密鍵も比較的長く、当該秘密鍵を思い出すことは困難である傾向があるので、モバイル装置上では比較的短くて思い出し易いＰＩＮ又は（想像することが比較的容易であろう）個人識別番号を用いて保護される場合が多い。従って、比較的弱いＰＩＮを用いる比較的強い秘密鍵のローカルな記憶装置は、装置の持ち主の権利及び特権を、上記ＰＩＮを正しく推測して上記装置を用いる者に不注意で暴露する場合がある。

本アクセス装置は、モバイル装置における鍵管理の問題を未然に防ぐ場合があり、例えば異なるメモリサイズ（例えば、多大なメモリを有するものもあれば、僅かなメモリしか持たないものもある）、異なるプログラミング言語（例えば、Ｃ／Ｃ＋＋でプログラムされるものもあれば、ジャバ（Ｊａｖａ（登録商標））でプログラムされるものもある）、異なる構成要素（例えば、ＳＩＭカードを有するものもあれば、持たないものもある）などの装置間の差に関連づけられる問題を未然に防ぐ場合がある。本アクセス装置は、単純なメッセージプロトコル（ＳＭＴＰなど）に、ＰＩＮを用いるオプションをも用いて暗号化されたトークンを通過させるメッセージ交換を積み重ねることにより、要求を保護してもよい。結果的に、計算集約的な暗号化は、（比較的弱いプロセッサを有するであろう）クライアント装置ではなく、（強力なプロセッサセットを有するであろう）アクセスサーバにおいて行われてもよい。

本アクセス装置はまた、管理されたサービス又はファイアウォール内にインストールされる企業内電化製品の何れかとして提供されてもよいハードウェア／ソフトウェアの組合せも備える。アクセス装置の「フロントエンド」は、クライアントからの要求を受信しこれに応答するメッセージサーバ（又はメッセージモジュール）であってもよい。アクセス装置の「バックエンド」は、要求を処理し、要求者に代わって適切なアプリケーションにアクセスする要求サーバ（又は要求モジュール）を備える。メッセージサーバと要求サーバとの組合せは、一般に、各クライアントのためのプロキシサーバとして機能してもよい。即ち、本アプリケーションは、クライアント自身と直接的に対話するのではなく、アクセス装置と対話していることを必ずしも認識していなくてもよい。

ある実施形態では、メッセージサーバは、例えばＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ＸＭＰＰ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ、ＨＴＴＰなどのうちの１つ又はそれ以上であるメッセージサービスを実行することに加えて、外部システムの構成要素と内部システムの構成要素との間のゲートウェイでもある。別の実施形態では、メッセージサーバはまた、遠隔管理のための安全なウェブサーバ及びファイアウォールを運転させる。セキュリティを最大にするために、一般に他のポート又はネットワーク接続は外界に対して利用不可にされてもよい。スケーラビリティ及び利用可能性の観点から、メッセージサーバを複製することが可能である。メッセージサーバは、プロフィールデータベースに記憶されるデータを用いて認証システムを運転させてもよい。無効なメッセージは、放棄されるか拒否される。有効なメッセージは即座に処置されてもよいが、大部分のメッセージは、同様にデータベース内又はファイルシステム上に記憶される持続性のメッセージ待ち行列の１つに追加される。

一般に、本アクセス装置内では、メッセージ待ち行列は、データの整合性及びパフォーマンス関して最適化される方法で、コンピュータクラスタの異なるノード上に展開されてもよい。即ち、ある特定のメッセージ待ち行列は２つ以上のソースから同時に修正されてもよく（例えば、追加、削除など）、しかもアクセス装置内で一貫した状態を保持する。

要求サーバは、持続性の待ち行列からメッセージを取り出し、当該メッセージから入力データ／パラメータを抽出し、ユーザ信任状などのプロフィール情報を追加し、クライアントアプリケーションに渡す。即ち、要求サーバは所望される情報アクセスを実行し、又は要求により指定されるトランザクションを実行し、結果を返す。要求サーバは、上記結果を単純なメッセージにフォーマットして、ユーザへ返す。スケーラビリティ及び利用可能性の観点から、要求サーバを複製することが可能である。各サーバは待ち行列から次のメッセージを取り出し、他のサーバを妨害しない。

要求サーバは、１つ又は複数のクライアントアプリケーション機器を用いることによりアプリケーションを実行できる場合が多い。クライアント機器をまた、唯一の又は少数のアプリケーションのみを実行するように専門化することが可能である。これは、クライアントアプリケーションが多くのコンピューティングリソースを必要とする場合又はおそらくは外部のネットワーク接続又はデータベースへの専用のアクセスを必要とする場合に有益である。これらの場合には、異なる待ち行列が用いられる。メッセージサーバは適切な待ち行列にメッセージを方向づけ、当該待ち行列の要求サーバのセットのみが当該待ち行列からメッセージを取り出す。

結果的に生じるシステムは実質的にあらゆる側面に拡張可能であり（例えば、メッセージサーバ、要求サーバ及びクライアントアプリケーション機器は全て複製されうる）、実質的に高い利用可能性、及び、実質的に容易な保守及び更新パスを有する実質的なスケーラビリティ（低コストのシステムから適正価格の高い能力のシステムまで）が保証される。一般に、小型で低コストのシステムは移動する少数の人員を擁する組織に必要とされるが、大企業に関するシステムの場合は単一のコンピュータの能力を上回る。

本アクセス装置はまた、実質的に並列の動作も可能にする。例えば、メッセージサーバを、単一のコンピュータ上で、又は並列のコンピュータセット上で運転させることが可能である。追加のコンピュータを、いつでも単純に追加することが可能である。ユーザプロフィールデータの保持には単一の論理データベースが用いられ、要求に応じて容量及びパフォーマンスをスケーリングする際には、従来のデータベース複製が用いられる。小規模設備では、要求サーバはデータベースと並列に動作することが可能であり、又は最大のサーバのニーズに適合するようにサーバセット上に分散されることが可能である。クライアントアプリケーションは、作業負荷及び必要とされる応答時間に適合するように追加されてもよい。

また、本アクセス装置は、年中無休の利用可能性も可能にする。固有の冗長性を有効にすることにより、アクセス装置は、任意の１つの構成要素が故障した場合でもスケーラビリティ及びシステム利用可能性の両方を可能にする。メッセージは、メッセージサーバの何れかによって処理されることが可能である。例えば、任意の要求サーバ又はクライアントアプリケーション機器が故障したとすれば、サービスを継続するために他の要求サーバ又はクライアントアプリケーション機器を用いることができる。要求を処理している間に１つの要求サーバが故障すれば、タイムアウトが発生し、次の要求サーバが自動的に処理を引き継ぐ。

本アクセス装置はまた、高信頼性でもある。信頼性は、予測されるシステム行動と、不測のシステム入力を含む実際のシステムの動作との間の差の尺度である。本アクセス装置は、例えば送信者のＩＰアドレスとドメインとが整合するかどうかを確認するＤＮＳの前方／逆引き探索チェック（forward and reverse DNS lookup checking）によって、偽のメッセージが拒絶されることを可能にする。また、偽メッセージの検出を、有効な送信側ＩＰアドレスがドメインＤＮＳにリストされる送信者ポリシフレームワーク（ＳＰＦ（Sender Policy Framework））などの最新技術を用いて達成してもよい。また、オープンシステムはサービス拒絶攻撃（ＤｏＳ（denial-of-service attacks））を受けやすいので、本アクセス装置は、このような攻撃を検出して応答する特別の技術を有する。悪質な送信者を早期に識別することは、コンピュータリソース（ＣＰＵタイム、メモリ、ログファイル）がほとんど浪費されないことを保証し、「ターピット（tarpit）」技術を用いることによって１つの場所からの複数の入力は遅延される。正当なユーザには一般に影響は出ないが、不正なユーザはサービス損失が発生し得ない速度にまでサービスを遅延される。

システムの監視及び管理も、コストを低く保つために自動化される。要求されると、これらの監視及び管理機能を、安全なウェブアクセスを用いて遠隔から利用できる。適正に認証されたユーザは、任意のウェブブラウザからアクセスサーバ（１つ又は複数の実施形態に係るメッセージサーバ及び要求サーバを含む）を管理することができる。

本発明の特徴及び優位点は、図面及び以下の論考を参照することにより、より良く理解されるものと思われる。

図１は、本発明の１つ又は複数の実施形態に係るアプリケーション／情報アクセス装置の簡略化されたブロック図である。ユーザは、クライアント装置１０２を動作させてもよい。クライアント装置１０２は、移動電話機、無線電子メール装置（例えば、ブラックベリ（Blackberry））、ＰＤＡ又はラップトップコンピュータなどのモバイル装置を示してもよい。クライアント装置１０２は、移動しない（non-mobile）コンピュータを示してもよい。移動電話機、特に今日のスマートホンのうちの１つは、急速に、特に優れたモバイル装置となりつつあると思われる。

クライアント装置１０２は、広域ネットワーク１０４などのネットワークを介して単純な要求アクセスサーバ１０６（ＳＲＡサーバ１０６）に接続している。広域ネットワーク１０４は、無線ネットワークとインターネットとの組合せを示してもよい。ＳＲＡサーバ１０６は、プロキシサーバを示してもよい。ＳＲＡサーバ１０６は、［後述される］メッセージサーバと、［後述される］要求サーバとを含んでもよい。ＳＲＡメッセージは、クライアントのＡＰＩにより用いられるリモートプロシージャコール（ＲＰＣ（Remote Procedure Call））メカニズムに酷似する要求を伝達するために用いられる。

広範な装置及びネットワークを最大限に利用するため、及びコルバ（ＣＯＲＢＡ）のようなＲＰＣプロトコルの複雑さを回避するために、本アクセス装置は、人が読み取ることのできるアドレス及びメッセージのためのテキストを用いてもよい。単純なメッセージング能力はセキュリティ及び認証性に必要であろう全ての事柄であるので、これは実質的に全ての装置からのアクセスを保証する。

ＳＲＡサーバ１０６は、ユーザ認証、要求の拡大（augmentation）及び個人化に用いられるユーザプロフィールデータベース１０８を保持してもよく、ユーザプロフィールデータベース１０８では、ユーザの好み、デフォルト値及び信任状などの情報が記憶され暗号化されてもよい。例えば、「ティッカーシンボル（Ticker Symbol）ＸＸＸの株価を得る」又は「電話番号を調べる」といった信任されていない要求は認証を必要としない。信任されている要求は、登録されているユーザのリストを参照して検証される。信任が厚い要求は、上述したように、通常は登録されているユーザのリストを参照する検証及び確認メッセージの両方を必要とするだけでなく、認証トークンが、最初に予め手配された「認証アドレス」に、オプションとして追加のＰＩＮと共に送信されることもまた必要とする。ＳＲＡサーバ１０６は、（必要であれば認証されている）要求メッセージを受信すると、これを直接的に処置してもよく、ＷＡＮ（広域ネットワーク（wide area network））１１１（例えば、インターネットなど）上で公に利用可能なインターネットサーバ１１６ａ−ｂに接続してもよく、又は上記要求をＬＡＮ（ローカルエリアネットワーク（local area network））１１４又は（図示されていない）無線ネットワークを介して１つ又は複数のアプリケーションサーバ１２０へ送ってもよい。アプリケーションサーバ１２０は、データベース１１２などの持続性のデータ記憶装置に接続されてもよい。多くの要求に対して、ＳＲＡサーバは要求者に代わって行動し、ユーザプロフィールデータベースからのデータを用いてインターネット上で個人情報にアクセスし、又はユーザの代わりにクライアントアプリケーション１１０にログインする。１つ又は複数の実施形態では、クライアントアプリケーション１１０へのアクセスは、ユーザ自身の意志に沿ってユーザインタフェースを介して行われる。例えば、ＳＲＡサーバ１０６は、通常はクライアントアプリケーション１１０により人であるユーザと対話するために用いられるＧＵＩ（グラフィックユーザインタフェース（graphical user interface））ベースのトランザクション（例えば、テキスト、マウスの移動及びクリックなど）を傍受してもよい。

要求者のプロフィールは、ユーザ名及びオプションとして各要求のパスワードを含み、公衆ＷＡＮ１１１を介して私的な情報（例えば、ユーザ名、パスワードなど）が送信されないことを保証する。また、ユーザプロフィールデータベースは、適切なファイアウォールによって安全に保護されてもよい。ある実施形態では、ＳＲＡサーバ１０６は、セキュリティを維持するために、（例えば、ＳＭＴＰ ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ＸＭＰＰ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ、ＨＴＴＰなどのうちの１つ又はそれ以上のための）ＷＡＮに対して開かれたポートを３つ又は４つだけ備えてもよい。別の実施形態では、クライアントアプリケーションは典型的なクライアント／サーバ企業アプリケーションの一部であり、クライアントはおそらくは企業ファイアウォール内部のローカルエリアネットワークを介して、アプリケーションサーバ及びデータベースに接続する。

図２は、本発明の１つ又は複数の実施形態に係るユーザ要求を処理する認証メカニズムを示す簡略化されたブロック図である。クライアント装置１０２は、ステップ２１１において、アクセス又はトランザクションの許可を得るためにＳＲＡメッセージ（第１のユーザメッセージ）を送信してもよい。ＳＲＡサーバ１０６は、ステップ２１２において、メッセージ送信者の名前を用いて、データベース１０８内のユーザプロフィールを探索してもよい。ユーザプロフィールの一部は、許可を得るために用いられるユーザのアドレスである。上記アドレスは、クライアント装置１０２であってもよい。あるいは又は追加的に、上記アドレスは、異なる装置を示してもよい。上記異なる装置及びＳＲＡサーバ１０６は、同一のメッセージングプロトコルを用いても、異なるメッセージングプロトコルを用いてもよい。

次に、ＳＲＡサーバ１０６は、暗号化されたトークンを発生し、当該トークンを用いて関連する一時的なメールボックス（例えば電子メールアドレス、電話番号、ウェブアドレス又はＵＲＬである一時的なアドレス又はインスタントメッセージアドレス）を生成してもよい。次にシステムは、ステップ２１３において認証要求をユーザに送り返してもよい。１つ又は複数の実施形態では、このメールボックスのアドレスは決して事前には存在せず、数分で失効するものであってもよく、従って盗聴者は当該アドレスを事前に知ることはできず、暗号化されたトークンの解読を試みるための時間は数分しかないものと思われる。トークン鍵の長さの選択及び短時間での失効は、実質的にセキュリティを保証する。ステップ２１４において、クライアント装置１０２（ユーザ）は、（第２のユーザメッセージにおいて）認証要求に対して肯定的に（より確実な要求にするために個人識別番号であるＰＩＮなどの追加の識別情報を追加して）応答してもよい。ステップ２１４において、ＳＲＡサーバ１０６が認証応答を受信すると、一時的なメールボックスは破壊されてもよく、元の要求は、一般に認証されたとしてマーク付けされる。次に、ＳＲＡサーバ１０６は、ステップ２１５において、上記要求を適切なクライアントアプリケーション１１０に送ってもよい。クライアントアプリケーション１１０は、２１６において、クライアントアプリケーション１１０からの結果をＳＲＡサーバ１０６へ返してもよい。ＳＲＡサーバ１０６は、２１７において、上記結果をクライアント装置（及びユーザ）に送信してもよい。

図３は、本発明の１つ又は複数の実施形態に係る不正な要求を処理する図２の認証メカニズムを示す簡略化されたブロック図である。不正なクライアント３０２は、ステップ３１１において、偽の「発信元：」アドレスを用いてＳＲＡサーバ１０６へ（偽の）要求を送信することにより、アクセス装置を突き破ろうとする。次に、ＳＲＡサーバ１０６は、認証のためにデータベース１０８内のアドレスを探索してもよい。次いで、暗号化されたトークン及び一時的なメールボックスが生成されてもよい。

これに続いて、ステップ３１３では、認証要求が正当なクライアント３０４（正当なユーザ３０４）の信任されているアドレスのうちの１つのアドレスに転送される。即ち、正当なユーザ３０４は、偽の認証要求及び送信側アドレスを受信する。正当なユーザ３０４は、単にこれを無視してもよい。また、正当なユーザ３０４は、３１４において否定的に応答してもよく、続いてステップ３１５において、クライアントアプリケーション１１０が保護されていることを示す確認メッセージをＳＲＡサーバ１０６から受信してもよい。この否定的な応答は、不正なクライアント３０２を識別し当該不正なクライアント３０２からのさらなるアクセスをブロックするために用いられてもよい。上述したように、信任されているアドレスセットを用いることは、ＳＲＡサーバ１０６が、特にＳＭＴＰなどの容易に偽造され得る一般的なインターネットプロトコルと共に用いられる場合に、スパムのないメッセージサーバとして動作することを可能にする。

図４は、本発明の１つ又は複数の実施形態に係るアクセス装置のスケーラビリティを示す簡略化されたブロック図である。メッセージサーバ及び要求サーバなどの（図１に示されている）ＳＲＡサーバ１０６の１つ又は複数の構成要素は、パフォーマンス及び利用可能性に関する任意の要望に適合するようにスケールアップされてもよい。スケーラビリティは、大企業のニーズに適合するためだけでなく、適正なサイズのシステムを最低のコストで単純な成長経路（growth path）によって配備するためにも重要である場合がある。

メッセージサーバ（例えば、ＳＭＴＰサーバ４０２ａ−ｃ）は、ラウンドロビン（round-robin）ＤＮＳなどの従来のＩＰスプレイング（spraying）技術又は負荷をバランスさせるための他の解決方法又はシスコシステムズ株式会社（Cisco Systems, Inc.）（www.cisco.com）から市販されているローカルディレクター（Local Director）などの機器によって負荷を分散してもよい。

データベース１０８は、ネットワークを介して同時にアクセスする複数の読み手及び書き手に関して必要最小限のロッキングで設計される場合のあるメッセージ待ち行列を、記憶してもよい。これは、高い信頼性で高いパフォーマンスを保証する。容量は、異なる待ち行列を異なるシステム上へ記憶することによって拡張されることが可能である。

要求サーバ４０４ａ−ｃは、当該要求サーバ４０４ａ−ｃに指定されたメッセージ待ち行列からメッセージを取り出し、これらを順次処理し、続いて当該メッセージをクライアントアプリケーション４０６ａ−ｂのうちの少なくとも１つなどの適切なクライアントアプリケーションに転送してもよい。１つの要求が終了されると、直ちに次のメッセージが処理され、負荷は自然に分散される。要求サーバの数が少ないほど、提供されるシステムのコストは下がるであろうが、システムが混雑しているときには応答時間における待ち時間は長くなるであろう。追加コストで要求サーバ４０４ａ−ｃの数を増やすと、システムが混雑しているときでも待ち時間は最小限に維持されるであろう。また、要求サーバをオンザフライ（リアルタイム）で追加することは容易である場合があるので、システムを処理及びパフォーマンス上のニーズに適合するようにスケーリングすることが可能である。

図５は、本発明の１つ又は複数の実施形態に係るメッセージ保護メカニズムを示す簡略化されたブロック図である。着信してくるメッセージは、不正なメッセージ又はエラーメッセージに対して費やされるコンピューティングリソースが最小になるようにふるい分けられてもよい。メッセージ保護メカニズムも同様に、サービス拒絶（ＤｏＳ（Denial of Service））攻撃の防止を手助けする場合がある。メッセージ保護メカニズムを、ＳＭＴＰサーバ４０２ａなどのメッセージサーバに実装してもよい。

論理回路５１１において、着信してくるメッセージのソースアドレス（例えば、ＩＰアドレス）は既知のスパムソースのブラックリスト５０８と比較されてもよく、ブラックリスト５０８に示されているメッセージは、システムに受け入れられることすらなく、直ちにドロップされる。論理回路５１２では、メッセージングプロトコル及び、ソースＩＰアドレスにＤＮＳ ＭＸレコードがない、ソースのＤＮＳエントリがないなどの偽のメッセージにおいて不正である場合の多い項目のヘッダ情報に対して幾つかの追加のチェックが実行され、偽のメッセージとして検出されたメッセージは直ちに拒絶される。

アクセス装置（又はＳＭＴＰサーバ４０２ａ）は、「バウンス」メッセージをソースへ送り返すように構成されてもよく、さらに上記ソースが偽のソースであるときには、当該バウンスメッセージが再度「バウンス」する。これらのダブルバウンスメッセージは、一般にエラー（時として、一時的なエラー）であるので、ログはされるがそれ以上の処理はされない。これらの早期のチェックはアクセス装置内の構成要素に掛かる負荷を低減する場合があり、当該構成要素をＤｏＳ攻撃から防止する手助けをする。各チェックは、あらゆるソースアドレスについて、１つ又は複数の特定のＩＰアドレスについて、又は１つ又は複数のＩＰアドレスの範囲に対して有効又は無効にされてもよい。早期のチェックは、組織がメッセージ送信サーバを正しくセットアップせず（例えば、ＤＮＳエントリの欠落、逆引きＤＮＳの不在、ＭＸエントリの欠落）、しかも上記組織は正当なメッセージソースであって受け入れられる必要がある場合に特に重要であることがある。アクセス装置の管理者は、チェックを動的に有効化及び／又は無効化してもよい。また、追加のスパムフィルタリングが用いられてもよい。

論理回路３では、これまでは未知であるユーザ（ソース）からの認証メッセージがチェックされてもよい。メッセージが暗号化された名前の特定のメールボックスに宛てられていて、当該メッセージが有効な応答（タイムアウト時間内、必要であればＰＩＮを伴っているなど）であるときに、そのユーザは「認証」され、当該ユーザのプロフィールがデータベース１０８に追加／更新される。

論理回路５１４では、「認証された」確認メッセージがユーザの［図示されていない］クライアント装置へ返されてもよい。誰が認証されることになるかに関する特定の詳細は、システム毎に変わってもよい。公開のシステムは、全てのユーザを（ブラックリストに記載されていない限り）認証してもよい。非公開のシステムは、何らかの他のデータベース／ディレクトリ（例えば、ＬＤＡＰ、ＭＳアクティブディレクトリなど）において既知であるユーザのみを許可する場合もあり、「認証された」確認メッセージを用いる必要はない場合がある。

論理回路５１５では、メッセージが「認証された」メッセージでないときには、当該メッセージがチェックされることにより、ユーザが既知である（即ち、メッセージのソースアドレスがユーザプロフィールデータベース内の１つに一致する）か否か、及びこの要求に対する信任されていないアクセスが許可されるか否かが確認される。ユーザが未知のユーザであるときには、制御は論理回路５１６に移行し、ユーザが既知であるときに、又は信任されていないアクセスが許可されるときに、制御は論理回路５１７に移行する。

論理回路５１６では、（暗号鍵を用いて）認証（歓迎）メッセージが生成され、ユーザへ返されてもよい。ソースアドレスが偽物でありかつ／又は無効であるときに、この認証メッセージは待ち行列に入れられるか、喪失されるか、バウンスするであろうから、ソースアドレスは未知のままである。

論理回路５１７では、メッセージ／要求は構文解析され、適切な処理のために送り出されて（ディスパッチされて）もよい。幾つかの要求は論理回路５１８において直ちに応答を生じさせ、他の要求は持続性の待ち行列５１０に入れられる。待ち行列５１０では、要求は今後のアクションのために保留されてもよい。

図６は、本発明の１つ又は複数の実施形態に係るアプリケーション／情報アクセスのタイプ（要求タイプ）及び要求処理を示す。要求処理は、図４に示す要求サーバ４０４ａなどの要求サーバにおいて実施されてもよい。要求サーバは、要求待ち行列６０２から次の要求を取り出し、当該要求のタイプに従って当該要求を処理してもよい。

本アクセス装置は、要求メッセージからの入力及び出力パラメータをアプリケーションインタフェースを用いて整合させる、通常は単純なスクリプトの形式である高速開発技術を利用してもよい。複雑な要求は、単純なスクリプトの組合せによって構築されてもよい。例えば、「ＵＰＣから製品を探索する」及び「製品の見積価格を入手する」を組み合わせることによって、「ＵＰＣから見積価格を入手する」要求を新たに生成してもよい。なお、本アクセス装置は、複数の要求サーバが並列動作することを可能にするように構成されてもよい。並列処理は、容量の必要条件に適合するようにシステムをスケーリングするために重要である場合がある。

また、個々の要求サーバは、特殊なソフトウェア又はハードウェアの搭載が要求されるときに重要である特有の要求を扱うように専門化されてもよい。

タイプ６１１の要求は、構造化された要求を必要とする１つ又は複数の最新のウェブサービスに対する要求を示してもよい。要求サーバは、タイプ６１１の要求メッセージからの構造化されていない入力パラメータを整合し、当該構造化されていない入力パラメータをＷＳＤＬ（ウェブサービス定義言語（Web Service Definition Language））パラメータに定義された構造化されたＸＭＬ（structured XML）の文書にコピーしてもよい。ウェブサービス要求から返されるＸＭＬ文書による結果は、ＷＳＤＬの出力パラメータを用いて抽出され、ＸＳＬＴを用いて適切にテキストにフォーマットされ、ユーザへの応答メッセージに入れられてもよい。このパラメータの整合及びフォーマットには高速スクリプトを用いてもよく、スクリプト高速の作成及び簡単な保守が可能になる。

タイプ６１２の要求は、ウェブページの取り出し（フェッチ）などの構造化されていない、又は比較的構造化されていない要求を受け入れる１つ又は複数のＩＰサービスに対する要求を示してもよい。要求サーバは、タイプ６１２の要求からの入力パラメータを適切な要求（例えば、ＨＴＴＰ ＧＥＴ又はＰＯＳＴなど）へコピーしてもよく、また返された結果の抽出を方向付けてもよい。可能な限り、ＨＴＭＬの結果はＸＭＬに変換され、タイプ６１１と同一の構造化された抽出及びフォーマット技術が用いられてもよい。タイプ６１２のスクリプトは、比較的構造化されていない要求及び応答を使うことに固有のばらつきを扱うために、タイプ６１１のスクリプトより僅かに複雑であってもよい。それにも関わらず、タイプ６１２のスクリプトはタイプ３の要求（後述する）よりも単純であってもよく、なおも高速開発技術の利点を提供する場合がある。

タイプ６１３の要求は、新しいクライアントプログラムを書くという、新規のアプリケーションからのアプリケーションデータにアクセスする従来の方法を示してもよい。プログラムは、要求から入力パラメータを取り出し、ベンダにより提供されるＡＰＩを用いてアプリケーションへ送り、次に結果を返すように記述される。新しいクライアントプログラムの開発及び保守は実質的に高価であることは一般に既知であるので、タイプ６１３の要求は通常、本アクセス装置から排除されてもよい。それでもなお、タイプ６１１及びタイプ６１２が利用不可である場合には、例えば必要に応じて利用可能にされてもよい。

タイプ４の要求は、アプリケーションアクセスの問題を解決する新しい高速開発アプローチを示してもよい。このアプローチは、スクリーンスクレーピング、切り貼り及びＯＣＲの各技術を用いる新規の「ビジュアルＡＰＩ」を用いてもよい。スクリプトは、入力及び出力パラメータの整合を、既存のアプリケーションの表示画面上の入力及び出力フィールドに方向づけてもよい。要求サーバは、入力パラメータを入力フィールドへ貼り付けてもよく、スクリプトによる命令に従って出力パラメータを抽出する。タイプ４の要求は、高価なプログラミングを必要とすることなく、既存のアプリケーション及びレガシーアプリケーションにアクセスするために用いられてもよい。タイプ４の要求は、シトリックス（Ｃｉｔｒｉｘ）、ＶＮＣ、ＭＳ端末サーバ、ＶＴ１００などのうちの１つ又はそれ以上を含むブラウザベースのアプリケーション又は端末セッションアプリケーションを利用してもよい。タイプ４スクリプトは、一般に単純であり、書き込みが速く、保守が容易である。

図７は、本発明の１つ又は複数の実施形態に係るアクセスシステム７００の構成を示す簡略化されたブロック図である。アクセスシステム７００の（例えばインターネットである通信ネットワーク７９０に面している）フロントエンドは、メッセージソフトウェア（例えば、ＳＭＴＰなど）を実行するＳＭＴＰサーバ７０２ａ−ｂなどの１つ又は複数のコンピュータを備えてもよい。上記１つ又は複数のコンピュータはファイアウォールを動作させてもよく、管理用のウェブサーバを動作させてもよい。故障又は保守の間にも継続して利用できる最少でも２つサーバが存在することが好ましい場合がある。

（内部ネットワークに面する）バックエンドは、データベースサーバ７０８及び／又はレイド（ＲＡＩＤ（redundant array of independent disks））ファイルシステム７０４を実行してもよい。大規模なアクセスシステムはデータベースサーバ７０８を二重化（duplicate）してもよく、関連のデータベースをＲＡＩＤファイルシステム７０４などの高い利用可能性のための従来のデータベース技術を用いて複製してもよい。必要に応じて、クライアントアプリケーションを実行するために追加の機器が包含されてもよい。これらのクライアントアプリケーションのうちのいくつかのクライアントアプリケーションは、企業サーバへのアクセスを要求してもよい。このアクセスは、通常、専用のネットワーク接続を用いて、又はおそらく公衆インターネット上のバーチャルプライベートネットワーク（ＶＰＮ（）virtual private network）を用いて実行されてもよい。本アクセスシステムのフロントエンド及びバックエンドは、リナックス（Ｌｉｎｕｘ）又はマイクロソフト（Ｍｉｃｒｏｓｏｆｔ）（登録商標）ウィンドウズ（Ｗｉｎｄｏｗｓ）（登録商標）などの周知のオペレーションシステム上で実行されてもよい。また、リナックスのオペレーションシステムであるクライアントアプリケーション１１０もリナックス又はマイクロソフト（登録商標）ウィンドウズ（登録商標）などの周知のオペレーションシステム上で実行されてもよいが、これは、本アクセスシステムのフロントエンド及び／又はバックエンドで実行されているオペレーションシステムと同一であっても異なっていてもよい。

図８は、本発明の１つ又は複数の実施形態に係るアクセスシステムの管理を示す簡略化されたブロック図である。本アクセスシステムの１つ又は複数のサーバ機能は、組み込まれた遠隔管理を有していてもよい。安全なネットワークインタフェース（例えば、ＨＴＴＰＳ、ＳＳＨなど）は、本アクセスシステムのメッセージサーバ上へホストされてもよく、ウェブサーバ管理アプリケーション８０２ａ−ｂにアクセスするように用いられてもよい。ウェブサーバ管理アプリケーション８０２ａ−ｂは、例えばデータベースサーバ７０８及び／又はＲＡＩＤファイルシステム７０４に記憶される単純な要求アクセスデータベース、メッセージ待ち行列、システムログ、ブラックリストなどを管理するように構成されてもよい。また、クライアントアプリケーション８０４もまた、統合された遠隔制御機能を備えてもよい。これらの機器の遠隔管理は、例えば遠隔制御クライアントアプリケーションを用いて、又は遠隔コントロールアプレットを用いるウェブを介して実施されてもよい。本アクセスシステムのメッセージサーバ及び要求サーバのうちの１つ又はそれ以上は、無人で動作してもよい。例えば、ログファイルのロールオーバは自動であってもよく、メッセージ待ち行列は必要に応じて長くなりかつ短くなってもよい。システムの監視及び管理機能は、要求されると、任意の認証された適切な管理者によってウェブブラウザ又は管理コンソールから容易に実行されてもよい。

アクセスサービスプロバイダは、公衆及び登録ユーザに開放されている公衆アクセスサービスを実行してもよい。企業もまた、当該企業のユーザにアプリケーションアクセスを提供するためにアクセスシステムを採用してもよく、本アクセスシステムは、企業のために、アクセスサービスプロバイダにより管理されたサービスとして運用されてもよい。あるいは又は追加的に、本アクセスシステムは企業サイトにインストールされてもよく、当該企業によって運用されてもよい。

図９は、本発明の１つ又は複数の実施形態に係るアクセス装置と共にウェブサービスを用いることを示す簡略化されたブロック図である。一般に、ウェブサービスは、インターネットプロトコルのバックボーン上のＸＭＬ、ＳＯＡＰ、ＷＳＤＬ及びＵＤＤＩといった公開されている規格のうちの１つ又はそれ以上を用いて複数のアプリケーションをＳＯＡ（サービス指向アーキテクチャ（services oriented architecture））に統合する標準化された方法を示してもよい。ＸＭＬはデータにタグ付けするために用いられてもよく、ＳＯＡＰはデータを転送するために用いられてもよく、ＷＳＤＬは利用可能なサービスを記述するために用いられてもよく、ＵＤＤＩはどのようなサービスが利用可能であるかをリストするために用いられてもよい。

ウェブサービスは、異なる複数のソースからの異なる複数のアプリケーションが時間のかかる特別のコーディングなしに互いに通信することを可能にし、すべての通信はＸＭＬで行われるので、ウェブサービスは任意の１つのオペレーションシステム又はプログラミング言語に縛られない。例えば、特別なプログラミングなしに、ジャバはパール（Ｐｅｒｌ）と話すことができ、ウィンドウズのアプリケーションはユニックス（ＵＮＩＸ（登録商標））のアプリケーションと話すことができる。

図９における例では、アクセスサーバ９０６ａ−ｂは、図１に示すＳＲＡサーバ１０６などの１つ又は複数のＳＲＡサーバを示してもよい。アクセスサーバ９０６ａ−ｂは、ユーザ９０２ａ−ｃがウェブサービスプロバイダ９０８ａ−ｃからウェブサービスにアクセスすることを可能にしてもよい。１つ又はそれ以上の実施形態では、アクセスサーバ９０６ａ−ｂは、ユーザ９０２ａ−ｃから着信するテキストメッセージを適切なウェブサービスプロトコルに翻訳するように構成されてもよい。図９における例で示すように、アクセスサービス９０６ｂなどのアクセスサービスは、ユーザ９０２ｃなどのユーザが、１つの要求によってサービスプロバイダ９０８ａ及び９０８ｃなどの複数のウェブサービス（又はサービスプロバイダ）にアクセスすることを可能にしてもよい。

アクセスサーバ９０６ａ−ｂは、ユーザ９０２ａ−ｃからの様々な入力メッセージタイプ及びプロトコル（ＳＭＴＰ、ＳＭＳなど）を処理するように構成されてもよい。アクセスサーバ９０６ａ−ｂはまた、サービスプロバイダ９０８ａ−ｃからのウェブサービス呼び出しの形式のＸＭＬメッセージを処理するように構成されてもよい。アクセスサーバ９０６ａ−ｂはまた、関連のウェブサービス（例えば、アクセスサービス９０６ｂに関連づけられるサービスプロバイダ９０８ａ及び９０８ｃ）の利用可能性を、ＵＤＤＩを利用して標準的な方法で公開するように構成されてもよい。

図９は、ユーザ９０２ａ−ｃがアクセスサーバ９０６ａ−ｂにメッセージを送信し、アクセスサーバ９０６ａ−ｂがサービスプロバイダ９０８ａ−ｃのうちの１つ又はそれ以上にアクセスする多階層（multi-tier）のサービスを示す。

本アクセス装置は、ユーザプロフィールのキャッシングなどのユーザ９０２ａ−ｃ及びサービスプロバイダ９０８ａ−ｃの両方にとって著しい優位点を提供してもよい。例えば、ユーザ９０２ａはアクセスサーバ９０６ａに登録されていてもよく、ユーザ９０２ａの必要なプロフィール及び好みの情報はユーザプロフィールデータベース１０８ａに記憶されていてもよい。次にアクセスサーバ９０６ａはサービスプロバイダ９０８ｂからウェブサービスにアクセスすることができ、続いてユーザ９０２ａのプロフィールのコピーをユーザプロフィールデータベース１０８ａからサービスプロバイダ９０８ｂ及びユーザプロフィールデータベース９１０ｂへ転送することができる。アクセスサーバ９０６ａ−ｂ間のプロトコルは、安全かつ信任されているものであってもよい。認証されると、メッセージは、ユーザの認証性を信任できる別のサーバへ安全に（例えば、ＳＳＬ接続を用いて暗号化されて）送られてもよい。

ユーザ９０２ａが新しいサービスプロバイダへのアクセスを追加することを希望する場合、ユーザ９０２ａはアクセスサーバ９０６ａに対してウェブサービスプロトコルを用いて新しいサービスプロバイダに接続するように命令してもよく、この場合も、ユーザ９０２ａのプロフィールをユーザプロフィールデータベース１０８ａから新しいサービスプロバイダへ転送してもよい。ユーザにとっての利点は、同一の登録情報を入力し直すことを回避すること、及びユーザプロフィール（即ち、名前、好み、パスワードなど）の単一のコピーを保持することを含む。ウェブサービスプロバイダにとっての利点は、ユーザと対話する単純化されたセキュリティインタフェースを含む。

本アクセス装置が提供する別の優位点は、即ちユーザのアクセスを監視し、管理しかつログすることのできる単一の場所である「制御ポイント」の生成であってもよい。制御ポイントは、例えば請求書作成又は報告又は監査に用いられてもよい。

図１０は、本発明の１つ又は複数の実施形態に係るアクセス装置を用いてアプリケーションを実行するための方法を示すフローチャートである。本方法は、クライアント装置からアプリケーションサーバ上でのアプリケーション機能の実行を成し遂げるために実施されてもよい。クライアント装置は、プロキシサーバに接続されてもよい。プロキシサーバは、アプリケーション機能を実装するアプリケーションを実行するアプリケーションサーバに接続されてもよい。ステップ１００２において、テキストメッセージは、クライアント装置から、プロキシサーバにおけるテキストメッセージの宛先アドレスで受信される。１つ又は複数の実施形態では、クライアント装置は第１のネットワークを介してプロキシサーバに接続され、プロキシサーバは第２のネットワークを介してアプリケーションサーバに接続される。１つ又は複数の実施形態では、第１のネットワークは広域ネットワーク及び無線ネットワークのうちの一方である。１つ又は複数の実施形態では、第２のネットワークは広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの１つである。次にステップ１００４では、認証メッセージが、テキストメッセージの発信元アドレス（例えば、図３に示す不正なクライアント３０２）とは異なるテキストメッセージの確認アドレスのユーザ（例えば、図３の例に示す正当なユーザ３０４又は図２の例に示すクライアント装置１０２）に送信される。１つ又は複数の実施形態では、認証メッセージはユーザへ、ユーザからのテキストメッセージの送信に用いられる第２のプロトコルとは異なる第１のプロトコルを用いて送信される。

１つ又は複数の実施形態では、第１のプロトコル及び第２のプロトコルは、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つを含む。１つ又は複数の実施形態では、テキストメッセージの確認アドレスは、上記認証後には不活性にされるように構成される非持続性の（non-persistent）テキストメッセージアドレスを表す。１つ又は複数の実施形態では、テキストメッセージの宛先アドレスは、クライアント装置上のメッセージングアドレスブックに記憶される。最後にステップ１００６では、ユーザが認証されていれば、アプリケーションサーバにおいてアプリケーション機能が実行される。アプリケーション機能は、例えば、信用限度額のチェック、株価の入手、発注、株式の売り、ＵＰＣコードからの製品調査及び製品見積価格の入手を含んでもよい。

図１１は、本発明の１つ又は複数の実施形態に係る、例えばＳＲＡサーバ１０６であるＳＲＡサーバ１０６を示す簡略化されたブロック図である。上述したように、ユーザは、モバイル装置（即ち、移動電話機、ブラックベリ又はＰＤＡ）、ラップトップコンピュータ又は移動しないコンピュータなどのクライアント装置１０２を動作させてもよい。ＳＲＡサーバ１０６は、広域ネットワーク１０４（例えば、無線ネットワーク、インターネットなど）を介してクライアント装置１０２に接続してもよく、アプリケーション及びサービス１１２４ａ−ｄのセットに接続してもよい。ＳＲＡサーバ１０６は、後述するように論理回路モジュールセットを含んでもよい。

サービスガードモジュール１１０４は、ＳＲＡサーバ１０６を広域ネットワーク１０４上の攻撃的な装置による侵入及びサービス拒絶攻撃から保護してもよい。侵入は、ＳＲＡサーバ１０６上の、又はＳＲＡサーバ１０６に接続される常駐のリソースの保全性、機密性又は利用可能性を危うくしようとするアクションセットを示してもよい。サービス拒絶攻撃は、ＳＲＡサーバ１０６に無用なトラフィックをフラッディングにより送ることによって当該ＳＲＡサーバ１０６を実質的に正常に機能しなくするように設計される攻撃のタイプを示してもよい。

１つ又は複数の実施形態では、サービスガードモジュール１１０４は、広域ネットワーク１０４からＳＲＡサーバ１０６への認証されていないアクセス及びＳＲＡサーバ１０６から広域ネットワーク１０４への認証されていないアクセスを防ぐためのファイアウォールとして機能してもよい。クライアント装置１０２への又はクライアント装置１０２からの全てのメッセージは、一般にサービスガードモジュール１１０４によってフィルタリングされる。例えば、サービスガードモジュール１１０４は、広域ネットワーク１０４へ出入りする各パケットが定義された規則セットに基づいて受け入れられ又は拒絶されるパケットフィルタリング技術を用いてもよい。また、サービスガードモジュール１１０４は、電子メールガード１１０４ａ、ＳＭＳガード１１０４ｂ、ＩＭガード１１０４ｃ、ＨＴＭＬガード１１０４ｄなどのサブモジュールをさらに含んでもよい。電子メールガード１１０４ａは、ＳＲＡサーバ１０６を電子メールから保護するように構成されてもよい。一般に、電子メールはメッセージが大規模なグループ又は受信者へ即座に同報に送信されることを可能にするので、電子メールメッセージは、コンピュータ間にウイルスを、一般的には開かれた時点で実行される悪意のあるプログラムを含むメッセージへの「添付物」として運ぶために用いられることが多い。

ＳＭＳガード１１０４ｂは、攻撃的である可能性のあるＳＭＳメッセージからＳＲＡサーバ１０６を保護するように構成されてもよい。ＳＭＳ又はショートメッセージサービスは、短いテキストメッセージが移動電話機、ファックス機器及び／又はＩＰアドレスに送信されることを可能にする。一般に、ショートメッセージは１６０英数字以下の長さであってもよく、画像又はグラフィックを含まない。

ＩＭガード１１０４ｃは、ＩＭメッセージから保護するように構成されてもよい。ＩＭ又はインスタントメッセージは、インターネット上で実質的にリアルタイムの通信を可能にするタイプの通信サービスである。

ＨＴＭＬガード１１０４ｄは、ＨＴＭＬコードを含むメッセージから保護するように構成されてもよい。ＨＴＭＬ即ちハイパーテキストマークアップ言語は、一般に、ワールドワイドウェブ上で文書を作成するために用いられるオーサリング言語である。ＨＴＭＬは、一般に、様々なタグ及び属性を用いることによりウェブ文書の構成及びレイアウトを定義する。

サービスガードモジュール１１０４は、要求パーサモジュール１１０６に接続されてもよい。要求パーサモジュール１１０６は、電子メール、ＳＭＳ、ＩＭ及びＨＴＭＬメッセージをそれぞれ構文解析する電子メールパーサ１１０６ａ、ＳＭＳパーサ１１０６ｂ、ＩＭパーサ１１０６ｃ及びＨＴＭＬパーサ１１０６ｄを含んでもよい。メッセージのタイプ（例えば、電子メール、ＳＭＳ、ＩＭ及びＨＴＭＬ）に依存して、要求パーサモジュール１１０６は、クライアント装置１０２からの要求のテキストを、解析できる小さい構成要素に分割してもよい。例えば、要求は、命令−−変数＠ｓｅｒｖｅｒ．ｃｏｍのフォーマットで構成されてもよい。ここで、命令は、最も近いレストランの位置、現在の天候又は資金の振替などのＳＲＡサーバ１０６によって実行されるべき要求を表すものであってもよく、変数は、位置、名前、口座番号、上述したような暗号化されたトークンなどの追加の情報を表すものであってもよく、ｓｅｒｖｅｒ．ｃｏｍは、上記命令の実行場所としてユーザが希望する特定のＳＲＡサーバ１０６の名前である。パーシングは、字句解析と意味解析とに分割されてもよい。字句解析は、もっぱら句読点及び他のキーに基づいて文字列をトークンと呼ばれる構成要素に分割してもよい。次いで意味解析は、文字列又は命令の意味を決定することを試行してもよい。

アクセス制御マネージャモジュール１１０８は要求パーサモジュール１１０６に接続されてもよく、かつＳＲＡサーバ１０６（及び／又はアプリケーション及びサービス１１２４ａ−ｄ）上のコンピュータリソースへのアクセスを制限するメカニズム及びポリシを制御してもよい。１つ又は複数の実施形態では、ＡＣＬ即ちアクセス制御リスト（access control list）が用いられてもよい。ＡＣＬは、アプリケーション及びサービス１１２４ａ−ｄのうちの１つ又はそれ以上などの特定のシステムオブジェクトに対して各ユーザ又はグループがどのような許可又はアクセス権を有しているかをＳＲＡサーバ１０６に通知するデータセットを示してもよい。各オブジェクトは、どのユーザが上記オブジェクトへのアクセスを有するかを識別する固有のセキュリティ属性を有してもよく、ＡＣＬは各オブジェクト及びユーザのアクセス特権（読み取り、書き込み又は実行など）のリストを示してもよい。

要求アクションバスモジュール１１１０は、アクセス制御マネージャモジュール１１０８をサービスコネクタモジュール１１１２に接続してもよい。ユーザがアクセス制御マネージャモジュール１１０８によって認証されると、ユーザ要求は要求アクションバスモジュール１１１０内の行列に入れられてもよい。ここで、上記ユーザ要求は、例えばアプリケーション及びサービス１１２４のうちの１つ又はそれ以上である適切なアプリケーション又はサービスが利用可能になったときに、サービススクリプトモジュール１１３２に基づいてサービスコネクタモジュール１１１２により引き出されてもよい。スクリプトは、ユーザ対話なしに実行され得るＳＲＡサーバ１０６コマンドのリストを有するマクロファイル又はバッチファイルを示してもよい。１つ又は複数の実施形態では、サービススクリプト１１３２のスクリプトを書くために特定のスクリプト言語が用いられてもよい。１つ又は複数の実施形態では、ＳＲＡサーバ１０６が要求アクションバスモジュール１１１０上でユーザ要求を実行する順序は、これらが待ち行列に置かれた順序と同一であってもよい。１つ又は複数の実施形態では、幾つかのユーザ要求に他のものより高い優先順位が与えられてもよい。

ユーザからの入ってくるメッセージは、信任状、好み、デフォルト値、信任されている応答経路、応答プロトコル、応答フォーマット、必要な認証方法などのうちの１つ又はそれ以上などのユーザプロフィール情報によって拡大されてもよい。これは、簡潔な要求がユーザのタイプ分けを最小限にすることを可能にし、しかも複雑な演算を実行する場合のある処理に豊富なデータを提供する。この方法は、ネットワーク上で信任状を送信する必要又は信任状を悪意のあるソフトウェア又は送信側装置に対して危険に曝す必要を回避する。

サービスコネクタモジュール１１１２は、アプリケーション及びサービス１１２４ａ−ｄに接続するためのコネクタ及び／又はアダプタセットを含んでもよい。例えば、ＷＳＤＬコネクタ１１１２ａはＳＲＡサーバ１０６が１つ又は複数のウェブサービス１１２４ａに接続することを可能にしてもよい。ＷＳＤＬは、一般に、ウェブサービスの能力をメッセージ交換能力のある複数の通信エンドポイントの集合（collection）として記述するために用いられるＸＭＬフォーマットの言語である。１つ又は複数の実施形態では、ＷＳＤＬコネクタ１１１２ａはＵＤＤＩディレクトリに接続してもよい。ＵＤＤＩ即ち統一的な記述、発見及び統合（universal description, discovery and integration）は、一般に企業が自らをインターネット上へリストし、かつ従来の電話帳のイエローページ及びホワイトページと同様に互いに発見し合うことを可能にするウェブベースの分散されたディレクトリである。

ＨＴＭＬコネクタ１１１２ｂは、ＳＲＡサーバ１０６が１つ又は複数のウェブアプリケーション１１２４ｂに接続することを可能にしてもよい。上述したように、ＨＴＭＬは一般に、ワールドワイドウェブ上で文書を作成するために用いられるオーサリング言語である。ＨＴＭＬコネクタ１１１２ｂは、前に生成されたウェブページの一部が抽出されてクライアント装置１０２に配信されることを可能にしてもよい。

ＵＩコネクタ１１１２ｃは、ＳＲＡサーバ１０６がＵＩ即ちユーザインタフェース（user interface）を介して１つ又は複数のクライアントアプリケーション１１２４ｃに接続することを可能にしてもよい。ＵＩは、人であるユーザがプログラムと通信するためのコマンドセット又はメニューセットとのインタフェースを示してもよい。追加のプログラミングの必要性を実質的に低減するために、ＵＩコネクタ１１１２ｃは人であるユーザを模倣し、自動的にＣＤＲＯＭ百科事典又は地図プログラムなどの遠隔ユーザアプリケーションに問い合わせて、そこから関連の情報を抽出するように構成されてもよい。

ＡＰＩコネクタ１１１２ｄは、ＳＲＡサーバ１０６が１つ又は複数のアプリケーションサーバ１１２４ｄに接続することを可能にしてもよい。ＡＰＩ即ちアプリケーションプログラムインタフェース（application program interface）は、ソフトウェアアプリケーションを構築するためのルーチン、プロトコル及びツールのセットを示してもよい。ａｐｐサーバ即ちアプリケーションサーバは、一般にユーザとバックエンドのアプリケーション又はデータベースとの間のアプリケーションの動作を取り扱うプログラムである。ａｐｐサーバは、典型的には、複雑なトランザクションベースのアプリケーション又はデータベースに用いられる。例えば、ＡＰＩコネクタ１１１２ｄはＳＲＡサーバ１０６をＳＡＰアプリケーションサーバに接続し、ユーザがクライアント装置１０２から顧客の注文ステータスを問い合わせることを可能にしてもよい。

サービス管理モジュール１１１４は、ＳＲＡサーバ１０６の管理者がネットワーク、コンピュータ及びデータベースの集合を安全に管理することを可能にしてもよい。

プロフィール管理モジュール１１１６は、ＳＲＡサーバ１０６が各ユーザのサービス及びリソースプロフィールのセットを保持することを可能にしてもよい。例えば、ユーザは、要求を行うクライアント装置１０２のタイプに依存して要求がカスタマイズされることを望む場合がある。

サービス提供モジュール１１１８は、ＳＲＡサーバ１０６の管理者がユーザにアプリケーション及びサービス１１２４ａ−ｄのうちの１つ又はそれ以上へのアクセスを提供することを可能にしてもよい。一般に、上記提供は、ユーザのアイデンティティ及びプロフィール管理モジュール１１１６に記憶されている特定のプロフィールに基づいて、特定のユーザによる１つ又は複数の特定のサービス及び／又はアプリケーションへのアクセスを許容することを含む。

サービス監視モジュール１１２０は、ＳＲＡサーバ１０６管理者がネットワーク上の全てのハードウェア及びソフトウェアの目録を作成しかつ診断テストを実行することを可能にしてもよい。

利用報告モジュール１１２２は、ＳＲＡサーバ１０６内のリソースの利用並びにアプリケーション及びサービス１１２４へのユーザのアクセスを監視して報告してもよい。

１つ又は複数の実施形態では、トランザクションの状態は一時的なメールボックスの使用を介して保持されてもよい。インターネット上では一般的に、トランザクションの状態はブラウザのクッキーの使用を介して保持されることが多い。クッキーは、典型的には、ウェブサーバによりウェブブラウザへ与えられる小さいメッセージである。ブラウザは上記メッセージをテキストファイルで記憶し、ブラウザがサーバからページを要求する毎に当該メッセージをサーバへ送り返す。ウェブサーバが連続するウェブページ要求間で特定のブラウザ（又はユーザ）を識別することを可能にすることにより、クッキーは基本的な形式のトランザクションセキュリティを提供してもよい。即ち、トランザクションを開始する特定のブラウザ（即ち、Ａｍａｚｏｎ．ｃｏｍから本を購入するユーザ）は、当該トランザクションを完了するブラウザと同一であるべきである。

しかしながら、ブラウザとは異なり、モバイル装置のアプリケーションは、一般にトランザクションではなく通信のために最適化される。即ち、モバイル装置は、電子メール及びＳＭＳなどの音声及びテキストメッセージの送受信には十分に優れているが、多くのモバイル装置の物理的サイズ及び計算能力は、ウェブサーバなどのインターネットアプリケーションへのユーザインタフェースとしてのその効果を減じる場合がある。続いて、モバイル装置のメッセージングアプリケーションにおいて、トランザクション状態を保持するクッキーと同等のものは一般に存在しない。

ある非自明な方法において、１つ又は複数の実施形態では、トランザクション状態を保持するために、クッキーの代わりとしてサービスメールボックス（サービスアドレス）が用いられてもよい。即ち、クッキーをローカルに記憶する代わりに、クライアント装置には固有の返信用アドレスセット又はサービスメールボックスが付与される。特定のサービスメールボックスに対する応答は、特定のクライアント装置の状態の特定の変化をＳＲＡサーバ１０６に対して信号で通知する。例えば、メニューーツリーの１つの経路の選択のように、複数の要求を含む場合のあるトランザクションの場合、特定のサービスメールボックスに対する応答は特定のメニューの選択に対応し、これにより、選択の次のレベルがクライアント装置に送信される場合がある。１つ又は複数の実施形態では、メニューは認証問い合わせ（クエリ）を含んでもよい。

これを、ウェブページ及びハイパーリンクと比較すると、ナビゲーションはリンクをクリックすることによって単純にされる。サービスメールボックスは、メッセージにおいてクリックへの単純なリンクとして用いられる。特定のサービスメールボックスに関連づけられる状態の情報は、必要な全てのナビゲーション及びトランザクションの情報を伝達する。サービスメールボックスのこのような使用は、メッセージングシステムをウェブのように使いやすくする。

例えば、ユーザは、特定の顧客の最新の注文総量を見るために、ＳＲＡサーバ１０６を介してＳＡＰアプリケーションへのアクセスを希望する場合がある。上記ユーザは、アクセス制御マネージャ１１０８によって認証されているときには、第１のテキストメッセージをＳＲＡサーバ１０６の特定の電子メールアドレスに送信することができ、これに続いて当該第１のテキストメッセージは、ＳＲＡサーバ１０６に対して、予め定義されたプロフィール情報及びスクリプトに基づいてＳＡＰアプリケーションと通信するように命令する。例えば、サーバアドレス（サービスアドレス）は、名前−顧客名を題名にしてｃｍ−ＳＡＰ＠ｓｅｒｖｅｒ．ｃｏｍのように入力されてもよい。ここで、顧客名は関心対象である特定の顧客の名前であり、ｓｅｒｖｅｒ．ｃｏｍはユーザが命令の実行場所として希望する特定のＳＲＡサーバ１０６の名前である。

次に、ＳＲＡサーバ１０６は、メッセージ本体に下記のような単純化されたメニューを付してクライアント装置へテキストメッセージを返すことになる。

納品：ｃｍ−ＳＡＰ−１００００＠ｓｅｒｖｅｒ．ｃｏｍ
現在の注文：ｃｍ−ＳＡＰ−２００００＠ｓｅｒｖｅｒ．ｃｏｍ
入荷待ち：ｃｍ−ＳＡＰ−３００００＠ｓｅｒｖｅｒ．ｃｏｍ
その他：ｃｍ−ＳＡＰ−４００００＠ｓｅｒｖｅｒ．ｃｏｍ
返品：ｃｍ−ＳＡＰ−５００００＠ｓｅｒｖｅｒ．ｃｏｍ

各メニュー項目は、ＳＡＰ−１００００、ＳＡＰ−２００００、ＳＡＰ−３００００などのサービス識別情報を含む。ｃｍ−ＳＡＰ−２００００＠ｓｅｒｖｅｒ．ｃｏｍへテキストメッセージを送信すると、メッセージ本体に下記のような単純化されたサブメニューを付して新しいメッセージが送信される。

現在までの注文総量：ｃｍ−ＳＡＰ−１１０００＠ｓｅｒｖｅｒ．ｃｏｍ
現在までの四半期分注文量：ｃｍ−ＳＡＰ−２２０００＠ｓｅｒｖｅｒ．ｃｏｍ
現在までの一月分の注文量：ｃｍ−ＳＡＰ−３３０００＠ｓｅｒｖｅｒ．ｃｏｍ
最終注文量：ｃｍ−ＳＡＰ−４４０００＠ｓｅｒｖｅｒ．ｃｏｍ
その他：ｃｍ−ＳＡＰ−５５０００＠ｓｅｒｖｅｒ．ｃｏｍ
返品：ｃｍ−ＳＡＰ−６６０００＠ｓｅｒｖｅｒ．ｃｏｍ

ｃｍ−ＳＡＰ−４４０００＠ｓｅｒｖｅｒ．ｃｏｍにテキストメッセージを送信することは、ＳＲＡサーバ１０６に対して顧客ｃｕｓｔｏｍｅｒｎａｍｅによる最終注文の総量を送信することを命令する。

なお、サービスメールボックス名は、セキュリティを追加するために暗号化されてもよい。ユーザはリンクをクリックすることができて、アドレスをタイプする必要はないので、所望されるときに、長い暗号鍵を用いることができる。

１つ又は複数の実施形態では、アクセス装置に二つの要素の認証が用いられてもよい。上述したように、信任が厚い要求は、送信者が確認メッセージ又は認証トークンを用いることなどによってトランザクションを確認することを求める場合がある。しかしながら、通信チャネル又は通信経路が危うくされていれば、侵入者はその確認メッセージ又は認証トークンを傍受して正しく応答することがあり、正当なユーザがトランザクションを適正に確認したものとＳＲＡサーバ１０６に信じ込ませる。セキュリティレベルを上げるためには、少なくとも２つの通信チャネル、即ち第１の主要なトランザクションチャネル及び第２の確認チャネルが用いられてもよい。

例えば、銀行は、認証を目的としてＡＴＭ機器に接続されるアクセスサーバを有してもよい。ＡＴＭから一定額を超える金額（即ち、＞＄３００）の引出しを希望する顧客は、ユーザのクライアント装置（即ち、携帯電話機、ＰＤＡなど）に特定のＯＴＰ（一回限りのＰＩＮ（one time PIN））などの一回限りの識別情報を伴うＳＭＳメッセージを受信する。トランザクションを完了するためには、上記情報がＡＴＭ機器に短時間（例えば、ＯＴＰの送信後３分以内）で入力される必要がある。

別の例では、ブラウザを用い銀行のウェブサイトから第三者の口座へお金を振り替えることを希望する顧客は、ブラウザウィンドウへ入力される必要のあるＯＴＰを伴うＳＭＳメッセージを受信することになる。別の例では、ＡＴＭ機器又は銀行のウェブサイトは、トランザクションが認証される前にクライアント装置からＳＭＳ又は電子メールを介してアクセスサーバに送信されなければならないセキュリティシリアル番号を発生する。

１つ又は複数の実施形態では、シリアル番号又はトークンは、ＲＳＡ ＳｅｃｕｒＩＤ認証装置などのスマートカードによって発生される。スマートカードは、電子メモリと、おそらくは内蔵された集積回路（ＩＣ（integrated circuit））とを含む、ほぼクレジットカードのサイズの小型の電子装置を示してもよい。ＩＣを含むスマートカードは、集積回路カード（ＩＣＣ（Integrated Circuit Cards））と呼ばれることがある。ユーザが資金の引出し又は振替を希望すると、クライアント装置上にその時点で有効なトークンを要求するメッセージが受信されてもよい。１つ又は複数の実施形態では、確認メッセージは、アクセスサーバ要求を行っているユーザ以外のユーザに送信される。例えば、従業員は、確認メッセージが従業員の監督者に送信されて認められた後に資金の振替又は引出しを行うことができる。

１つ又は複数の実施形態では、アクセス装置は、トランザクションを認証するためにモバイル装置ＳＩＭを用いることができる。加入者識別モジュール（subscriber identity module）の略称であるＳＩＭは、一般にＧＳＭ携帯電話機内のスマートカードであり、音声及びデータ送信を暗号化し、電話サービスを提供するネットワークに対してユーザが識別され認証されうるように、特定のユーザに関するデータを記憶する。ＳＩＭはまた、ユーザに特有の個人的な電話設定及び電話番号などのデータを記憶する。ＳＩＭは１つの電話機から別の電話機へ移動されることが可能であり、かつ／又は異なるＳＩＭが任意のＧＳＭ電話機へ挿入されることが可能である。各ＳＩＭ上の識別情報は一般に固有であるので、トランザクションは、始めにモバイル装置へ確認メッセージを送信し、上記確認メッセージをＳＩＭカードで暗号化し、上記確認（又は、当該確認の暗号ハッシュ）をアクセスサーバへ返すことによって安全に認証されてもよい。

１つ又は複数の実施形態では、アクセスサーバはシングルサインオン機能を提供してもよい。クライアント／サーバの関係における認証処理であるシングルサインオンは、ユーザ又はクライアントが１つの名前及びパスワードを入力して２つ以上のアプリケーションへのアクセス又は企業内の幾つかのリソースへのアクセスを有することを可能にする。シングルサインオンは、一般に、ユーザが１つのアプリケーションから別のアプリケーションへ切り替える際にさらなる認証を入力する必要性を低減させる。

１つ又は複数の実施形態では、アクセスサーバは、Ｗ３Ｃ標準のＸＦｏｒｍｓを使用可能にされているクライアント装置に接続してもよい。一般にデータ入力後に各フォームがウェブサーバに送信されることを要求する標準のＨＴＭＬのＷｅｂフォームとは異なり、ＸＦｏｒｍｓを使用可能なアプリケーションは、フォームセットがローカルに処理された後にウェブサーバへＸＭＬ文書として送信されることを可能にしてもよい。また、ＸＭＬをデータの定義に用いかつＨＴＭＬ又はＸＨＴＭＬをデータ表示に用いることにより、ＸＦｏｒｍｓを使用可能なアプリケーションは、移動電話機、ハンドヘルド装置及び視覚障害者用の点字リーダなどの異なるユーザインタフェースのためにカスタマイズされてもよい。

１つ又は複数の実施形態では、アクセスサーバはＲＦＩＤを使用可能なモバイル装置と通信してもよい。無線周波識別（radio frequency identification）の略称であるＲＦＩＤシステムは、一般に、無線周波信号を放射して情報を処理装置に転送するアンテナ及び送受信機と、ＲＦ回路及び送信されるべき情報を含む集積回路であるトランスポンダ又はタグとから成る。バーコード技術とは異なり、ＲＦＩＤは見通し範囲内での読み取り（line-of-sight reading）の必要性を減じ、より長い距離を隔てて実行されることが可能である。そうでなければ情報をタイプしなければならないようなユーザにとって、多大な優位点がある。また、何らかのサーバと通信する必要のあるモバイルＲＦＩＤ装置にとっても多大な優位点がある場合があり、本発明の１つ又は複数の実施形態に係るアクセス装置は、この問題に対して単純で低コストかつ効果的な解決方法を提供する場合がある。

例えば、ユーザが２つの薬剤間の薬物相互作用に関する情報を求めていれば、ＲＦＩＤ対応モバイル装置はまず、各薬剤容器の上又は内部に記された情報読み取ってもよい。次に、このＲＦＩＤ情報はアクセスサーバに送信され、アクセスサーバは薬物相互作用のデータベースサービスへ問合せを行う。アクセスサーバは次に、特定の薬物相互作用情報をモバイル装置への応答としてカスタマイズされたテキストメッセージで送信してもよい。

１つ又は複数の実施形態では、アクセスサーバは、ＧＰＳを使用可能なモバイル装置と通信してもよい。全地球測位システム（Global Positioning System）の略称であるＧＰＳは、一般に、地球の周りを回る２４個の衛星と、これらに対応する地上の受信機とによって形成される世界的な衛星ナビゲーションシステムである。ＧＰＳ衛星は、衛星の位置及び正確な時刻に関するデータを含むデジタル無線信号を地上にある受信機へ継続的に送信する。３つの衛星を用いることにより、ＧＰＳは、３つの球が交差する場所に基づいて受信機の経度及び緯度を計算することができる。４つの衛星を用いれば、ＧＰＳは標高も決定することができる。例えば、ユーザがレストランの位置などの位置に固有の情報を求めていれば、ユーザの現在位置は、ユーザが手動で入力する代わりに、ＧＰＳ対応モバイル装置によってアクセスサーバへ自動的に送信されてもよい。アクセスサーバは次に、現在の住所から所望される住所への方向を含むテキストメッセージで応答してもよい。モバイルＲＦＩＤリーダの場合と同様に、これは、退屈なエラーの発生しやすい位置情報の手動入力を行おうとしないユーザにとって多大な優位点となることがある。

１つ又は複数の実施形態では、モバイル装置内のアドレスブックエントリは、コマンド構文のヘルプ及び／又はヒントに用いられてもよい。例えば、ユーザは、ｃｍｈｅｌｐ＠ｓｅｒｖｅｒ．ｃｏｍなどのヘルプアドレスへメッセージを送ることによって、アクセスサーバに一般的なヘルプメニューに関する問合せを行うことができる。ここで、ｃｍｈｅｌｐは特定のヘルプ要求であり、ｓｅｒｖｅｒ．ｃｏｍはユーザがヘルプ命令の実行場所として希望する特定のアクセスサーバの名前である。例えば、受信と同時に、テキストメッセージの本体として下記のような単純化された一般的なヘルプメニューが返されてもよい。

メール宛先：ｃｍＣｕｒｒｅｎｃｙ＠ｓｅｒｖｅｒ．ｃｏｍ
ＧｏＣｕｒｒｅｎｃｙ．ｃｏｍにおける通貨の探索

メール宛先：ｃｍＤｉｃｔｉｏｎａｒｙ＠ｓｅｒｖｅｒ．ｃｏｍ
ｗｗｗ．ｄｉｃｔｉｏｎａｒｙ．ｃｏｍにおける単語の探索

メール宛先：ｃｍＤｉｒｅｃｔｉｏｎｓ＠ｓｅｒｖｅｒ．ｃｏｍ
ｗｗｗ．ｍａｐｑｕｅｓｔ．ｃｏｍからのドライブの方向

メール宛先：ｃｍＦｒｏｏｇｌｅ＠ｓｅｒｖｅｒ．ｃｏｍ
製品のＦｒｏｏｇｌｅ検索 ｆｒｏｏｇｌｅ．ｇｏｏｇｌｅ．ｃｏｍ

メール宛先：ｃｍＧｏｏ＠ｓｅｒｖｅｒ．ｃｏｍ
ＰＤＡディスプレイのＧｏｏｇｌｅ検索 ｇｏｏｇｌｅ．ｃｏｍ／ｐａｌｍ

さらに特定のヘルプは、例えば題名に単語「ヘルプ」を付した特定の要求を送信することによって入手されることが可能である。

１つ又は複数の実施形態では、ユーザの打ち込み（タイピング）の量を減らすために略語セットが用いられてもよい。例えば、ユーザは、ｃｍｋｅｙｇｅｔ＠ｓｅｒｖｅｒ．ｃｏｍへメッセージを送信することによって、アクセスサーバに略語セットの問合せを行うことができる。ここで、ｃｍｋｅｙｇｅｔは略語又はキーリクエストであり、ｓｅｒｖｅｒ．ｃｏｍはユーザがヘルプ命令の実行場所として希望する特定のアクセスサーバの名前である。例えば、受信と同時に、テキストメッセージの本体として下記のような単純化された一般ヘルプメニューが返されてもよい。

ＳＦＯ−アドレス１
ＬＡＸ−アドレス２
ＨＯＭＥ−アドレス３

ユーザは次に、既存のキーを修正するか、新しいキーを追加して、テキストをｃｍｋｅｙ＠ｓｅｒｖｅｒ．ｃｏｍに送信することができる。続いてユーザは、ｃｍｄｉｒｅｃｔｉｏｎ：ＨＯＭＥ：ＳＦＯ＠ｓｅｒｖｅｒ．ｃｏｍへテキストメッセージを送信することによって自宅からサンフランシスコ空港への方向を要求することができる。

１つ又は複数の実施形態では、ＬＯＣＮキーは、要求されるキーが失われている場合に位置に関する要求のためのデフォルトのキーであることが想定されてもよい。１つ又は複数の実施形態では、ユーザの現在の位置は、既知であれば（即ち、ＧＰＳを使用可能なユーザ装置、ユーザによる予めの入力などにより）、位置に関する要求のための現在の位置のキーであることが想定されてもよい。例えば、ｃｍｓｔａｒｂｕｃｋｓ＠ｓｅｒｖｅｒ．ｃｏｍへ題名なしのメッセージが送信されるときに、一般にアクセスサーバは、それがユーザの現在の位置であると信じる場所から最も近いスターバックスまでの方向を返すことになる。

以上、幾つかの好ましい実施形態に関連して本発明を説明してきたが、本発明の範囲内にある変形例、置換例及び同等物は存在する。本明細書に提示した発明の名称及び要約は便宜的なものであり、本発明を添付の請求の範囲を限定するように解釈するために用いられるべきではない。

従って、本発明の優位点には、信任されている汎用パーソナルアクセスシステム及びそのための方法のアーキテクチャが含まれる。追加の優位点には、内部及び外部ソースの両方への管理された企業アクセスのためのホスト型のアクセスインフラストラクチャ、アプリケーション及びウェブサービスへの指向性のトランザクションアクセスのための管理可能なインフラストラクチャ及び生産性の拡大及び総所有コスト（ＴＣＯ（total cost of ownership））の低減が含まれる。

以上、例示的な実施形態及び最良の態様を開示したが、開示された実施形態には、添付の請求の範囲により定義される本発明の主題及び精神を逸脱することなく修正及び変形が行われてもよい。

本発明の１つ又は複数の実施形態に係るアプリケーション／情報アクセス装置の簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るユーザ要求を処理する認証メカニズムを示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係る不正な要求を処理する図２の認証メカニズムを示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るアクセス装置のスケーラビリティを示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るメッセージ保護メカニズムを示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るアプリケーション／情報アクセスのタイプを示す。 本発明の１つ又は複数の実施形態に係るアクセスシステムの構成を示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るアクセスシステムの管理を示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るアクセス装置と共にウェブサービスを用いることを示す簡略化されたブロック図である。 本発明の１つ又は複数の実施形態に係るアクセス装置を用いてアプリケーションを実行するための方法を示すフローチャートである。 本発明の１つ又は複数の実施形態に係るアクセスサーバを示す簡略化されたブロック図である。

Claims (87)

1. クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法であって、前記クライアント装置はプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
   前記方法は、
   前記クライアント装置上のアプリケーション機能要求セットから前記アプリケーション機能を実行する要求を選択することと、
   前記要求に関する第１のテキストメッセージを前記プロキシサーバに送信することとを含み、前記第１のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第１のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
   前記方法は、
   認証メッセージを前記テキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスのユーザに送ることによって前記第１のテキストメッセージの発信元アドレスに関連づけられる前記ユーザを認証し、前記認証メッセージに応答して前記ユーザから確認を受信することと、
   前記ユーザが前記認証によって認証されるときに、前記アプリケーションサーバにおいて前記第１のテキストメッセージによって指定される通りに前記アプリケーション機能を実行することとを含み、これにより、前記第１のアプリケーション機能は少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される方法。
2. 前記クライアント装置は第１のネットワークを介して前記プロキシサーバに接続され、前記プロキシサーバは第２のネットワークを介して前記アプリケーションサーバに接続される請求項１記載の方法。
3. 前記第１のネットワークと前記第２のネットワークとは同一である請求項２記載の方法。
4. 前記第１のネットワークと前記第２のネットワークとは異なる請求項２記載の方法。
5. 前記第１のネットワークは、広域ネットワーク及び無線ネットワークのうちの少なくとも一方を含む請求項２記載の方法。
6. 前記第２のネットワークは、広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの少なくとも１つを含む請求項２記載の方法。
7. 前記第１のテキストメッセージはさらに前記第１のテキストメッセージの本体における複数のパラメータを含み、前記複数のパラメータは前記アプリケーション機能の実行に関する複数のパラメータを表し、前記複数のパラメータは英数字テキストとして表現される請求項２記載の方法。
8. 前記認証メッセージは、前記第１のテキストメッセージを前記ユーザから送信するために用いられた第２のプロトコルとは異なる第１のプロトコルを用いて前記ユーザに送信される請求項７記載の方法。
9. 前記第１のプロトコル及び前記第２のプロトコルは、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ＸＭＰＰ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つを含む請求項８記載の方法。
10. 前記テキストメッセージの確認アドレスは、前記認証後には不活性にされるように構成される非持続性のテキストメッセージアドレスを表す請求項９記載の方法。
11. 前記認証することは、時間的制約を有する認証トークン、個人識別番号（ＰＩＮ）及びパスワードのうちの少なくとも１つを用いる請求項１０記載の方法。
12. 前記アプリケーション機能要求セットは、メッセージングアドレスブック、電子メール及びＸＭＬ文書のうちの少なくとも１つに記憶される請求項１記載の方法。
13. 前記第１のメッセージは、フォームを用いて前記クライアント装置上に生成される請求項１記載の方法。
14. 前記フォームは、ＸＦｏｒｍ、ＨＴＭＬフォーム及びＷＭＬフォームのうちの少なくとも１つを含む請求項１３記載の方法。
15. 前記テキストメッセージは人が読み取ることのできるテキストを含む請求項１記載の方法。
16. 前記テキストメッセージはリモートプロシージャコールである請求項１記載の方法。
17. 前記アプリケーションサーバはグラフィカルユーザインターフェースを含み、前記プロキシサーバは前記グラフィカルユーザインターフェースを介して前記アプリケーションサーバに接続される請求項１記載の方法。
18. 前記アプリケーションサーバはＡＰＩを含み、前記プロキシサーバは前記ＡＰＩを介して前記アプリケーションサーバに接続される請求項１記載の方法。
19. クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法であって、前記クライアント装置はプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
    前記方法は、
    前記クライアント装置上のアプリケーション機能要求セットから前記アプリケーション機能を実行する要求を選択することと、
    前記要求に関する第１のテキストメッセージを前記プロキシサーバに送信することとを含み、前記第１のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第１のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
    前記方法は、
    認証メッセージを前記テキストメッセージの発信元アドレスと同一のテキストメッセージの確認アドレスのユーザに送ることによって前記第１のテキストメッセージの発信元アドレスに関連づけられる前記ユーザを認証し、前記認証メッセージに応答して前記ユーザから確認を受信することと、
    前記ユーザが前記認証によって認証されるときに、前記アプリケーションサーバにおいて前記第１のテキストメッセージによって指定される通りに前記アプリケーション機能を実行することとを含み、これにより、前記アプリケーション機能は少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される方法。
20. クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法であって、前記クライアント装置はプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
    前記方法は、
    前記クライアント装置上のアプリケーション機能要求セットから前記アプリケーション機能を実行する要求を選択することと、
    前記要求に関する第１のテキストメッセージを前記プロキシサーバに送信することとを含み、前記第１のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第１のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
    前記方法は、
    前記アプリケーションサーバにおいて前記第１のメッセージによって指定される通りに前記アプリケーション機能を実行することを含み、これにより、前記アプリケーション機能は少なくとも前記メッセージの宛先アドレスに基づいて確認される方法。
21. 前記クライアント装置は第１のネットワークを介して前記プロキシサーバに接続され、前記プロキシサーバは第２のネットワークを介して前記アプリケーションサーバに接続される請求項２０記載の方法。
22. 前記第１のネットワークと前記第２のネットワークとは同一である請求項２１記載の方法。
23. 前記第１のネットワークと前記第２のネットワークとは異なる請求項２１記載の方法。
24. 前記第１のネットワークは、広域ネットワーク及び無線ネットワークのうちの少なくとも一方を含む請求項２１記載の方法。
25. 前記第２のネットワークは、広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの少なくとも１つを含む請求項２１記載の方法。
26. 前記第１のテキストメッセージはさらに前記第１のテキストメッセージの本体における複数のパラメータを含み、前記複数のパラメータは前記アプリケーション機能の実行に関する複数のパラメータを表し、前記複数のパラメータは英数字テキストとして表現される請求項２１記載の方法。
27. 前記アプリケーション機能要求セットは、メッセージングアドレスブック、電子メール及びＸＭＬ文書のうちの１つに記憶される請求項２０記載の方法。
28. 前記アプリケーションサーバはグラフィカルユーザインターフェースを含み、前記プロキシサーバは前記グラフィカルユーザインターフェースを介して前記アプリケーションサーバに接続される請求項２０記載の方法。
29. 前記アプリケーションサーバはＡＰＩを含み、前記プロキシサーバは前記ＡＰＩを介して前記アプリケーションサーバに接続される請求項２０記載の方法。
30. クライアント装置がアプリケーションサーバ上のアプリケーション機能を遠隔から実行することを可能にするための装置であって、前記クライアント装置はプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
    前記装置は、
    前記クライアント装置上のアプリケーション機能セットから前記アプリケーション機能を実行する要求を選択するための手段と、
    前記要求に関する第１のテキストメッセージを前記プロキシサーバに送信するための手段とを備え、前記第１のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第１のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
    前記装置は、
    認証メッセージを前記第１のテキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスのユーザに送ることによって前記第１のテキストメッセージの発信元アドレスに関連づけられる前記ユーザを認証し、前記認証メッセージに応答して前記ユーザから確認を受信するための手段と、
    前記ユーザが前記認証によって認証されるときに、前記アプリケーションサーバにおいて前記第１のテキストメッセージによって指定される通りに前記アプリケーション機能を実行するための手段とを備え、これにより、前記アプリケーション機能は少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される装置。
31. 前記クライアント装置は第１のネットワークを介して前記プロキシサーバに接続され、前記プロキシサーバは第２のネットワークを介して前記アプリケーションサーバに接続される請求項３０記載の装置。
32. 前記第１のネットワークと前記第２のネットワークとは同一である請求項３１記載の装置。
33. 前記第１のネットワークと前記第２のネットワークとは異なる請求項３１記載の装置。
34. 前記第１のネットワークは、広域ネットワーク及び無線ネットワークのうちの少なくとも一方を含む請求項３０記載の装置。
35. 前記第２のネットワークは、広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの少なくとも１つを含む請求項３１記載の装置。
36. 前記第１のテキストメッセージはさらに前記第１のテキストメッセージの本体における複数のパラメータを含み、前記複数のパラメータは前記アプリケーション機能の実行に関する複数のパラメータを表し、前記複数のパラメータは英数字テキストとして表現される請求項３１記載の装置。
37. 前記認証メッセージは、前記第１のテキストメッセージを前記ユーザから送信するために用いられた第２のプロトコルとは異なる第１のプロトコルを用いて前記ユーザに送信される請求項３６記載の装置。
38. 前記第１のプロトコル及び前記第２のプロトコルは、ＳＭＴＰ、ＳＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つを含む請求項３７記載の装置。
39. 前記テキストメッセージの確認アドレスは、前記認証後には不活性にされるように構成される非持続性のテキストメッセージアドレスを表す請求項３８記載の装置。
40. 前記認証することは、時間的制約を有する認証トークン、個人識別番号（ＰＩＮ）及びパスワードのうちの少なくとも１つを用いる請求項３８記載の装置。
41. 前記アプリケーション機能要求セットは、メッセージングアドレスブック、電子メール及びＸＭＬ文書のうちの１つに記憶される請求項３０記載の装置。
42. 前記アプリケーションサーバはグラフィカルユーザインターフェースを含み、前記プロキシサーバは前記グラフィカルユーザインターフェースを介して前記アプリケーションサーバに接続される請求項３０記載の装置。
43. 前記アプリケーションサーバはＡＰＩを含み、前記プロキシサーバは前記ＡＰＩを介して前記アプリケーションサーバに接続される請求項３０記載の装置。
44. ユーザがクライアント装置を用いて１つ又は複数のサーバ上に存在する１つ又は複数のアプリケーションにアクセスすることを容易にするためのシステムであって、
    メッセージモジュールと、パーサと、コネクタとを備え、
    前記メッセージモジュールは、前記ユーザから第１のユーザメッセージを受信し、前記第１のユーザメッセージに応答して認証アドレスを発生し第１の要求を確認アドレスに送信するように構成され、
    前記パーサは、前記認証アドレスにおいて前記確認アドレスを発信元とする肯定の応答メッセージが受信されるときに、前記ユーザからの第２のユーザメッセージ及び前記第１のユーザメッセージのうちの少なくとも一方のユーザメッセージから命令を抽出するように構成され、
    前記コネクタは、前記命令が抽出されるときに、前記命令を前記１つ又は複数のサーバに伝達し、前記１つ又は複数のアプリケーションによって１つ又は複数の応答が発生されて前記クライアント装置に送信されることをトリガするように構成されるシステム。
45. 前記第１のユーザメッセージ及び前記第２のユーザメッセージのうちの少なくとも１つは前記クライアント装置から送信される請求項４４記載のシステム。
46. 前記認証アドレスは、前記認証アドレスが発生された後、所定の時間期間内に失効するように構成される請求項４４記載のシステム。
47. 前記認証アドレスは、第１の要求が送信された後、３分未満で失効するように構成される請求項４４記載のシステム。
48. 前記認証アドレスは暗号化される請求項４４記載のシステム。
49. 前記第１の要求は、前記第１の要求が送信された後、所定の時間期間内に失効するように構成される一回限りの識別情報を含み、前記肯定の応答メッセージは前記一回限りの識別情報を含む請求項４４記載のシステム。
50. 前記一回限りの識別情報は、前記第１の要求が送信された後、３分未満で失効するように構成される請求項４９記載のシステム。
51. 前記確認アドレスは前記第１のユーザメッセージの発信元アドレスとは異なる請求項４４記載のシステム。
52. 前記確認アドレスは、前記ユーザ及び前記ユーザの監督者のうちの少なくとも一方に関連づけられる請求項４４記載のシステム。
53. 前記認証アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項４４記載のシステム。
54. 前記確認アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項４４記載のシステム。
55. 前記肯定の応答メッセージは、前記確認アドレスに加えて識別情報を含む請求項４４記載のシステム。
56. 前記第１のユーザメッセージ及び前記第２のユーザメッセージのうちの少なくとも１つは、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つに従う請求項４４記載のシステム。
57. 前記第１のユーザメッセージ及び前記第２のユーザメッセージの前記少なくとも一方のユーザメッセージ又はそれ以上は、ＳＭＴＰ及びＳＭＳのうちの少なくとも一方に従う請求項４４記載のシステム。
58. 前記コネクタはさらに、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つに従うプロトコルを用いて前記１つ又は複数のサーバと通信するように構成される請求項４４記載のシステム。
59. 前記確認アドレスは前記第１のユーザメッセージの発信元アドレスを表す請求項４４記載のシステム。
60. 前記第１の要求及び前記メッセージモジュールにより前記クライアント装置に送信される第２の要求のうちの少なくとも一方はメニューを含み、前記メニューは１つ又は複数のメニュー項目を含み、前記１つ又は複数のメニュー項目は、１つ又は複数の認証問い合わせ、及び前記１つ又は複数のアプリケーションにより提供される１つ又は複数のサービスのうちの少なくとも一方を表す請求項４４記載のシステム。
61. 前記第１の要求及び前記第２の要求のうちの少なくとも１つはＳＭＴＰ及びＳＭＳのうちの少なくとも一方に従う請求項６０記載のシステム。
62. 前記１つ又は複数のメニュー項目はそれぞれサービスアドレスを含み、前記サービスアドレスは第１の部分と第２の部分とを含み、前記第１の部分はサービス識別情報を含み、前記第２の部分はシステムを識別する請求項６０記載のシステム。
63. 前記サービスアドレスは暗号化される請求項６２記載のシステム。
64. 前記サービスアドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項６２記載のシステム。
65. 前記コネクタは、前記命令を前記１つ又は複数のサーバのうちの２つ以上のサーバへ同時に伝達するように構成される請求項４４記載のシステム。
66. ユーザがクライアント装置を用いて１つ又は複数のサーバ上に存在する１つ又は複数のアプリケーションにアクセスすることを容易にするためのコンピュータ実装方法であって、
    前記ユーザから第１のメッセージを受信することと、
    認証アドレスを発生することと、
    第１の要求を確認アドレスに送信することと、
    前記認証アドレスにおいて前記確認アドレスを発信元とする肯定の応答メッセージが受信されるときに、前記ユーザからの第２のユーザメッセージ及び前記第１のユーザメッセージのうちの少なくとも一方から命令を抽出することと、
    前記命令が抽出されるときに、前記１つ又は複数のアプリケーションによって１つ又は複数の応答が発生され前記クライアント装置に送信されることをトリガするように、前記命令を前記１つ又は複数のサーバに伝達することとを含むコンピュータ実装方法。
67. 前記第１のユーザメッセージ及び前記第２のユーザメッセージのうちの少なくとも１つは前記クライアント装置から送信される請求項６６記載のコンピュータ実装方法。
68. 前記認証アドレスは、前記認証アドレスが発生された後、所定の時間期間内に失効するように構成される請求項６６記載のコンピュータ実装方法。
69. 前記認証アドレスは、第１の要求が送信された後、３分未満で失効するように構成される請求項６６記載のコンピュータ実装方法。
70. 前記認証アドレスは暗号化される請求項６６記載のコンピュータ実装方法。
71. 前記第１の要求は、前記第１の要求が送信された後、所定の時間期間内に失効するように構成される一回限りの識別情報を含み、前記肯定の応答メッセージは前記一回限りの識別情報を含む請求項６６記載のコンピュータ実装方法。
72. 前記一回限りの識別情報は、前記第１の要求が送信された後、３分未満で失効するように構成される請求項７１記載のコンピュータ実装方法。
73. 前記確認アドレスは前記第１のユーザメッセージの発信元アドレスとは異なる請求項６６記載のコンピュータ実装方法。
74. 前記確認アドレスは、前記ユーザ及び前記ユーザの監督者のうちの少なくとも一方に関連づけられる請求項６６記載のコンピュータ実装方法。
75. 前記認証アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項６６記載のコンピュータ実装方法。
76. 前記確認アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項６６記載のコンピュータ実装方法。
77. 前記肯定の応答メッセージは、前記確認アドレスに加えて識別情報を含む請求項６６記載のコンピュータ実装方法。
78. 前記第１のユーザメッセージ及び前記第２のユーザメッセージのうちの少なくとも１つは、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つに従う請求項６６記載のコンピュータ実装方法。
79. 前記第１のユーザメッセージ及び前記第２のユーザメッセージのうちの少なくとも一方又はそれ以上は、ＳＭＴＰ及びＳＭＳのうちの少なくとも一方に従う請求項６６記載のコンピュータ実装方法。
80. 前記コネクタはさらに、ＳＭＴＰ、ＳＭＳ、ＭＭＳ、ＩＭ、ウェブサービス、ＳＯＡＰ、ＸＭＬ、ＷＡＰ、ＷＭＬ、ＨＴＴＰＳ及びＨＴＴＰのうちの少なくとも１つに従うプロトコルを用いて前記１つ又は複数のサーバと通信するように構成される請求項６６記載のコンピュータ実装方法。
81. 前記確認アドレスは前記第１のユーザメッセージの発信元アドレスを表す請求項６６記載のコンピュータ実装方法。
82. 前記第１の要求及び前記メッセージモジュールにより前記クライアント装置に送信される第２の要求のうちの少なくとも一方はメニューを含み、前記メニューは１つ又は複数のメニュー項目を含み、前記１つ又は複数のメニュー項目は、１つ又は複数の認証問い合わせ、及び前記１つ又は複数のアプリケーションにより提供される１つ又は複数のサービスのうちの少なくとも一方を表す請求項６６記載のコンピュータ実装方法。
83. 前記第１の要求及び前記第２の要求のうちの少なくとも１つはＳＭＴＰ及びＳＭＳのうちの少なくとも一方に従う請求項８２記載のコンピュータ実装方法。
84. 前記１つ又は複数のメニュー項目はそれぞれサービスアドレスを含み、前記サービスアドレスはサービス識別情報とアクセスシステム識別情報とを含む請求項８２記載のコンピュータ実装方法。
85. 前記サービスアドレスは暗号化される請求項８４記載のコンピュータ実装方法。
86. 前記サービスアドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも１つを含む請求項８４記載のコンピュータ実装方法。
87. 前記命令は前記１つ又は複数のサーバのうちの２つ以上のサーバへ同時に伝達される請求項６６記載のコンピュータ実装方法。

Images