JP2009516305A - クライアントによって発生される認証コードを用いるアプリケーションアクセス - Google Patents
クライアントによって発生される認証コードを用いるアプリケーションアクセス Download PDFInfo
- Publication number
- JP2009516305A JP2009516305A JP2008541294A JP2008541294A JP2009516305A JP 2009516305 A JP2009516305 A JP 2009516305A JP 2008541294 A JP2008541294 A JP 2008541294A JP 2008541294 A JP2008541294 A JP 2008541294A JP 2009516305 A JP2009516305 A JP 2009516305A
- Authority
- JP
- Japan
- Prior art keywords
- message
- address
- user
- request
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
- H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/58—Message adaptation for wireless communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/35—Network arrangements, protocols or services for addressing or naming involving non-standard use of addresses for implementing network functionalities, e.g. coding subscription information within the address or functional addressing, i.e. assigning an address to a function
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
- H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
- H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/168—Implementing security features at a particular protocol layer above the transport layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Communication Control (AREA)
- Telephonic Communication Services (AREA)
Abstract
クライアント装置からプロキシサーバを介してアプリケーションサーバ上でアプリケーション機能の実行を成し遂げる方法を開示する。本方法は、アプリケーション機能実行の要求に関して第1のテキストメッセージを送信することを含む。本方法はさらに、上記テキストメッセージの発信元アドレスとは異なる確認アドレスを介してユーザを認証することにより、上記第1のテキストメッセージに関連づけられるユーザを認証することを含む。認証の後、本方法は、上記第1のテキストメッセージにより指定される通りにアプリケーションサーバにおいてアプリケーション機能を実行することも含み、これにより、上記第1のアプリケーション機能は少なくともテキストメッセージの宛先アドレスに基づいて確認される。
Description
今日の労働者は機動力を有するので、労働者がデスクを離れているときに内部ネットワークのリソース及びアプリケーションを安全に利用することが困難になる場合が多い。一般的な通信技術の1つに、電子メールが挙げられる。企業内で組織間の境界を越えて用いられる電子メールは、情報又は行動の伝達及び要求に用いられる。
ちょうど音声通信の場合の電話機のように、電子メールは、具体的には遠隔アクセス及びモバイルアクセスのための主要なビジネスアプリケーションとして採用されてきている。企業内では、電子メールは主要なビジネス通信プラットフォームである傾向があり、よって、ユーザのデスクトップ上でほぼ常時開かれている。電子メールはまた、無線ユーザのための主要なアプリケーションである傾向がある。
電子メールは当初、通常の物理的な郵便の電子的な拡張として開発されたので、原則的には非同期かつ自由な形式(フリーフォーム)である。一般に、非同期とは、ひとつの処理(例えば、電子メールを送信すること)が他の処理(例えば、電子メールを受信すること)とは独立して行われることを意味する。一方、同期とは、完了した又は中断中の動作(例えば、音声電話機による会話)である他の何らかの処理の結果としてのみ、1つの処理が行われることを意味する。電子メールメッセージは、一般に第1のユーザにより作成されて第2のユーザに送信され、続いて第2のユーザ側で引き続き読み出されるべくインボックス内の待ち行列に入れられ、おそらくは後に応答される。自由な形式は、電子メールメッセージにおける比較的少量の規格化された情報を指す。即ち、幾つかの固定のフィールド(例えば、宛先アドレス、発信元アドレス及び題名など)を除いて、電子メール文書自体の大部分は内容又は本文を含む。これは、一般に宛先の住所のみを必要とする通常の郵便のメッセージと同様である。
電子メールは、個人から個人へ送信されるという性格を有するので、一般に、ウェブブラウザなどのよりロバストなユーザインタフェースを有するより高度なクライアントアプリケーションを必要とするアクセスネットワークリソース(例えば、データベース、販売ツールなど)に対しては役に立たない。即ち、エラーは一般に比較的自由な形式であって規格化されていない、人が読み取ることのできるテキストによって示され、プログラムからプログラムへの通信ではこれが困難にされる。また、多くの移動無線装置(例えば、携帯電話機、PDAなど)は比較的小型であり、従って、内部ネットワークリソースの遠隔アクセスにとっては問題がある。現在の企業ソフトウェアプラットフォームはもともとこのタイプのアクセスのために開発されたものではなく、よって多くの場合、これらの無線装置からのアクセスをサポートするためには、多大な開発、実装及び管理費用を必要とする。
モバイル装置が音声以外のアプリケーションに対してユーザに提供するユーザインタフェースは、一般に、バッテリ持続時間の必要条件及び形式(フォーム)の要素に関する必要条件に起因して比較的粗末である。音声は別として、メッセージの受信は容易であるが、小さいディスプレイ及びキーボードはメッセージの送信をやっかいで問題のあるものにする。例えば、テキストメッセージの送信には、モバイルキーボードのサイズが比較的小さいことに起因して、多大な努力を必要とする場合がある。さらに、フルキーボードのない装置(大部分の携帯電話機上の数字キーパッドなど)は、事実上、データ送信をショートメッセージ(例えば、SMSなど)に制限する。
画面のサイズもまた、従来のクライアント/サーバのアプリケーション及びブラウザを用いることを制限する傾向がある。画面のパンニング又はHTMLからWMLへの自動変換における試みにも関わらず、既存のアプリケーション及びウェブサイトは、一般にモバイル装置上の小さい画面では動作しない。ベンダによっては、特にモバイル装置を用いる労働者のために新規のバージョンのアプリケーション又はウェブサイトを書くことを選択しているものもあるが、これは容易な作業ではなく(1つの画面が多くのモバイル画面にならなければならない)、よって実装は高価である。また、モバイルソフトウェアに関しては移植可能性の規格が存在せず、現在の多様かつ急速な装置の開発を考えれば、この状況がすぐに改善されること目の当たりにすることを期待すべきではない。
1つ又は複数の実施形態において、本発明は、クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法に関する。クライアント装置はプロキシサーバに接続され、プロキシサーバはさらに、アプリケーション機能を実装するアプリケーションを実行するアプリケーションサーバに接続されている。本方法は、クライアント装置上のアプリケーション機能要求セットからアプリケーション機能を実行する要求を選択することを含む。本方法はさらに、上記要求に関する第1のテキストメッセージをプロキシサーバに送信することを含み、上記第1のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、上記第1のテキストメッセージはアプリケーション機能を実行する要求に関連している。本方法はさらに、テキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスのユーザへ認証メッセージを送り、上記認証メッセージに応答する確認をユーザから受信することにより、上記第1のテキストメッセージの発信元アドレスに関連づけられるユーザを認証することを含む。上記認証によってユーザが認証されるときに、本方法は、上記第1のテキストメッセージにより指定された通りにアプリケーションサーバにおいてアプリケーション機能を実行することも含み、これにより、上記第1のアプリケーション機能は少なくともテキストメッセージの宛先アドレスに基づいて確認される。
本発明の1つ又は複数の実施形態は、ユーザがクライアント装置を用いて上記クライアント装置及び第2の装置のうちの少なくとも一方において発生される認証コードにより1つ又は複数のサーバ上に存在する1つ又は複数のアプリケーションにアクセスすることを容易にするためのシステムを含む。本システムは、ユーザから第1のユーザメッセージを受信し、上記第1のユーザメッセージに応答して認証アドレスを発生しかつ認証コードの発生を要求するための第1の要求を確認アドレスに送信するように構成されるメッセージモジュールを含む。確認アドレスは、クライアント装置及び第2の装置のうちの少なくとも一方に対応する。本システムは、認証アドレスにおいて認証コードを含む肯定の応答メッセージが受信されるときに、クライアント装置及び第2の装置の一方から送信される第1のユーザメッセージ及び第2のユーザメッセージのうちの少なくとも一方から命令を抽出するように構成されるパーサも含む。本システムはさらに、命令が抽出されるときに、1つ又は複数の応答が1つ又は複数のアプリケーションにより発生されクライアント装置に送信されることをトリガするように、1つ又は複数のサーバに命令が伝達されるように構成されるコネクタを含む。
以下、本発明の詳細な説明において、かつ添付の図面に関連して本発明のこれらの特徴及び他の特徴をより詳しく記述する。
本発明は制限としてではなく一例として示され、添付の図面において、同様の参照符号は同様の構成要素を示す。
以下、添付の図面に示されている幾つかの好ましい実施形態を参照して、本発明を詳しく説明する。以下の説明では、本発明の完全な理解をもたらすために多くの特定の詳細な事項について記述するが、当業者には、本発明がこれらの特定の詳細な事項の幾つか又は全てを用いることなく実施されてもよいことは明白であろう。他の例では、本発明を不必要に分かりにくくしないために、周知の処理ステップ及び/又は構成については詳述していない。本発明の特徴及び優位点は、諸図面及び下記の論考を参照することによってより良く理解することができる。
以下、方法及び技術を含む様々な実施形態について記述する。また本発明は、本発明の技術の実施形態を実行するためのコンピュータ読み取り可能な命令が記憶されるコンピュータ読み取り可能媒体を含む物品を包含してもよい点を考慮するべきである。コンピュータ読み取り可能媒体は、例えば、半導体、磁気、光磁気、光学又は他の形式のコンピュータ読み取り可能なコードを記憶するためのコンピュータ読み取り可能媒体を含んでもよい。さらに本発明は、本発明の実施形態を実施するための装置を包含してもよい。このような装置は、本発明の実施形態に関連する動作を実行する、専用の及び/又はプログラム可能な回路を含んでもよい。このような装置の例は、汎用コンピュータ及び/又は適切にプログラムされる場合には専用の計算装置を含み、コンピュータ/計算装置と本発明の実施形態に関連する様々な動作のために適合化された専用の/プログラム可能な回路との組合せを含んでよい。
本発明の一実施形態によれば、アプリケーション及び/又は情報アクセス装置(以下、アクセス装置という。)は、拡張された情報へのアクセス及び検索を促進するように効果的に用いられる。ある非自明な様式において、テキストベースのメッセージ(例えば、電子メール、SMSなど)は個人対個人の通信の形式を超えて拡張され、ウェブ上のトランザクション、アプリケーションデータ又はリソースなどの「もの」へのアクセスに向けられたプラットフォーム及びサービスの両方を提供してもよい。情報へのアクセス及び検索は、一般に、信任された(trusted)ものと信任されていない(non-trusted)ものの何れかであってもよい。信任とは、一般に、明白に規定されたルールのシステム(例えば、特権、制限、権利など)の遵守に対する第2の当事者の意向に関して第1の当事者が有する信頼度を指す。
一般に、本アクセス装置は、信任されていない要求(non trusted requests)、信任されている発信元からの要求(trusted origin requests)及び信任が厚い要求(highly trusted request)の3つのタイプの要求を区別する。二人の当事者間で転送されている情報が、その一般的な開示に比べて特に価値のある情報ではないとき、あるいは一般に慎重に取り扱う必要がない情報ではないときには、一般に、信任されていない関係性が確立される。信任されていない要求は、任意の者/任意の場所から受け入れられてもよく、結果は送信者に返される。これは、単純な公開又は公衆タイプのトランザクションである。ある実施形態では、本アクセス装置は、慎重に取り扱う必要がない情報(例えば、ニュース、天候、交通など)をテキストベースのメッセージングアドレスが返す信任されないサービスを生成するために用いられてもよい。例えば、あるニュースの話題を電子メールの題名とする電子メールメッセージをcmNews@ClairMail.comなどの電子メールアドレスに送信することにより、その話題に関するニュースを含む応答が受信されてもよい。
信任されている発信元からの要求は、登録されているユーザのリストに記載されている又は外部のソース(例えば、LDAP、MSアクティブディレクトリなど)から導出される、設定済みのユーザ(信任されているユーザのアドレスのセットを含む)からに限定的に受け入れられてもよい。正しく認証されない要求(例えば、スパムなど)は直ちに拒絶され、応答は適切な信任されているアドレス(必ずしも送信者宛でなく)のみに返されてもよい。SMSアドレスは、装置に固有のものであるので、応答アドレスとして特に有益である。
このようにして、登録ユーザとしてアクセス装置をいたずらにだまそうとする未登録の侵入者は検出され、よって、応答において信頼のある情報を受信することはできない。また、信任されているユーザアドレスを用いる技術も、他の当事者にとって未知の第三者が一方の当事者からのメッセージを傍受して第2の当事者に転送するという状況である、介入者攻撃に耐える。
信任が厚い要求は、トランザクション確認の送信者の認証をさらに必要とする、信任されている発信元からの要求である。例えば、信任が厚い要求は、銀行口座間の資金振替に用いられてもよい。確認メッセージは、まず、予め手配された「認証アドレス」に送信されてもよい。信任されている要求の場合と同様に、登録ユーザはこれらの確認メッセージが送信されるアドレスを定義するが、当該アドレスは、必ずしも上記要求の発信元である装置又はプロトコルと同一ではない。
次に、確認メッセージ又は短い時間期間の間だけ有効な認証トークン(タイムスタンプを含む)が暗号化されてもよい。一般に持続期間は、暗号化の解読に必要な時間が、メッセージが有効である時間ウィンドウより実質的に長くなるように選ばれる。ユーザは次に、おそらくは例えば個人識別番号(PIN(personal identification number))である何らかの情報を確認メッセージに追加して当該確認メッセージに応答し、システムをより安全にしてもよい。即ち、暗号化メッセージが傍受されてPINなしに返されるときに、そのトランザクションは認証されないことになる。アクセス装置によって応答が受信され(かつPINが適宜チェックされ)ると、トランザクションは認証され、実行され、「完了をマーク付け」される。トランザクションは一度しか実行され得ないので、上述したように、この最後のステップは介入者攻撃から守るために用いられる。例えば、振替金額を電子メールの題名にしてcmTransfer@ClairMail.comなどの電子メールアドレスを打ち込み、確認に対して応答すれば、ユーザは予め指定された2つの口座間で資金の振替を開始することができる。
また、ロバストな認証メカニズムはまた、スパム(例えば、求められていないバルクメッセージなど)を実質的に低減することに役立つ。スパムは、事実上誰でも大量の電子メールを事実上無料で送信できるので、残念ながら電子メッセージを用いる誇大広告及び勧誘を促進している。懸念が重大レベルに達しつつある今、大部分の企業はそのメッセージングシステムをスパムの洪水から保護すると同様に、不正なメッセージを不正な場所に跳ね返すことによって自らもスパムのソースになることを回避しなければならない。
例えば、スパムの送信者は、スパムの送信者がブロックされているネットワークに接続する方法を発見する試みにおいて、偽造であるが有効な送信者アドレスを有するメッセージを第3のサイトの無効な宛先アドレスに送ることがある。結果的に、第3のサイトの電子メールサーバは、上記メッセージを配信することができずに、当該配信されなかった(スパム)メッセージのコピーを、サーバが送信者と信じる者に、この場合は上記偽造の送信者アドレスに送り返すであろう。
また、無効な宛先アドレスは、サービス拒絶攻撃を実行する目的で用いられることがある。例えば、攻撃者からのメッセージは、無効な宛先アドレス及び無効な返信用アドレスの両方を用いて電子メールサーバに送られることがある。上述の場合と同様に、メッセージは配信され得ないので、電子メールサーバは実在しない送信者に応答し、これにより、メッセージはもとの電子メールサーバへと跳ね返されることになる。結果的には、メッセージの送信ループが生成される場合があり、最終的に、多大なネットワークリソースが消費され、よって適正なトラフィックを送信することができなくなる。
本アクセス装置はまた、認証技術を用いることにより、正当なユーザのみのために情報がアクセスされトランザクションが実行されることを保証する。特に、アクセス装置は、クライアント装置に送信される暗号化されたトークンを用いてもよい。ユーザは、応答し、又はトークンを迅速かつ正確に提出しなければならない。トークンは数分で失効するので、盗聴者には解読する時間がない。ユーザが(オプションとして、追加のパスワード又はPINを用いて)応答すると、トークンはキャンセルされるので、盗聴者は複製されたメッセージを用いてトランザクションに影響を与えることができない。この技術は、単純な装置のみを用いて、モバイル装置内の暗号化/復号化を必要としない認証動作を保証する。一般に、モバイル装置では、バッテリの寿命を長くするために、比較的低い性能のプロセッサが用いられることが多い。結果的に、モバイル装置は、計算集約的な暗号化/復号化タスクのためには最適化されない傾向がある。
また、本アクセス装置は、内部及び外部ソースの両方への管理された企業内アクセスのために、ホスト型のアクセスインフラストラクチャを許容してもよい。これはさらに、拡大された生産性及びオーナ総所有コスト(TCO(total cost of ownership))を許容する、アプリケーション及びウェブサービスへの指向的なトランザクションアクセスのための管理可能なインフラストラクチャを提供してもよい。ある実施形態では、シンプルリクエストアクセス(SRA(simple request access))プロトコルがアプリケーション及び情報への安全な指向性のテキストベースのメッセージングアクセスをもたらし、ユーザ生産性を拡大してサポート及びトレーニングコストを下げる。即ち、ユーザのデスクトップコンピュータ、ラップトップコンピュータ、モバイル装置、PDA、スマートホン、無線電子メール装置などに追加のソフトウェアをインストールする必要はない。
典型的には、「アクション」又は「トランザクション」に関するテキストベースのメッセージングアドレスを、単純な指向性の要求から複雑なアクションが実行されることを可能にするプラットフォーム内で発生することが可能である。単一の要求又はメッセージは、複数のアプリケーションをスパンし、統合された又は調整された結果をもたらしてもよい。また、同一又は異種のアクセスの信任状(クレデンシャル(credential))をそれぞれ用いる複数のアプリケーション問い合わせ(クエリ)の結果は、統一された結果に統合されてもよい。
これで、ユーザのアドレスブックに記憶されるテキストベースのメッセージングアドレスは要求のタイプを定義することができる。また、要求者に関連する情報は、シンプルリクエストアクセス(SRA(simple request access))サーバなどの情報/アプリケーションアクセスサーバ(アクセスサーバ)におけるプロフィールデータベースによってもたらされてもよく、要求の履歴のロギングが可能である。
一般に、ロギングには2つの方法がある。第1のタイプでは、クライアントのログがクライアント装置のインボックスで保持されてもよく、上記インボックスでは、送受信される全てのメッセージのコピーが後のアクセス及び検索のために記憶される。第2のタイプでは、サーバのログがアクセスサーバにおいて保持されてもよい。一般に、サーバのログは、ユーザ名、タスク、時刻などのトランザクション情報を記録する。その結果、アクセスサーバは、サーベンスオクスリー法(Sarbanes-Oxley Act)などの企業管理ガイドライン及び規制によりしばしば要求される実質的に高レベルの監査能力を提供してもよい。
本アクセス装置は、SRA(simple request access(シンプルリクエストアクセス))アドレスを有する従来のテキストベースのメッセージングアプリケーション(例えば、電子メール、SMSなど)を最適化し、同期、ミニブラウザ及び高価な専用のクライアントアプリケーションなどの他の多くのアプローチの制限を回避する。テキストベースのメッセージに従来欠けているアクセス機能は、アクセスサーバに送信される単純な英数字のテキストメッセージ(又は記号(indicia)のセット)として提供されてもよく、アクセスサーバは、このメッセージに従って、要求された結果を単純な電子メッセージを用いて返す。即ち、クレアメイル(ClairMail)のサーバは、ユーザのためのプロキシとして動作することにより、ユーザのパーソナルアシスタントとして動作してもよい。
ある非自明な方法では、各SRAメッセージはそれ自体の固有アドレスを有する。一般的に用いられるSRAは、最小のキーストロークの素早いアクセスのために、他の従来のテキストベースのメッセージングアドレスと共にアドレスブック内に保持されてもよい。例えば、要求は、「顧客XYZの信用限度額はいくらか?」、「銘柄記号XXXの株価を入手する?」、「顧客XYZのためにYYYを100単位だけ発注する?」又は「XXXの株式を100株売る?」である可能性がある。
ある実施形態では、これらの要求はそれぞれ、例えばaddress@server.comなどの適切なアドレスへ、追加の適切なパラメータ(例えば、顧客番号/名XYZ、銘柄記号XXX、売買する単位数又は株数、項目番号/名YYYなど)と共に送信されることも可能である。電子メールの構成は、特に、一般にアドレスの大きいセットを提供し、アドレスの大きいセットはトランザクション名のために大きいネームスペースを与える。
また、このアプローチはモバイル装置のために最適化されてもよいが、これは、任意の電子メールを使用可能な又は他のメッセージング能力を有する装置から用いられてもよい。1つ又は複数の実施形態では、要求はSMSメッセージとして送信されることが可能である。1つ又は複数の実施形態では、要求をウェブサービスメッセージとして送信することが可能である。1つ又は複数の実施形態では、要求をIM(インスタントメッセージ(instant message))として送信することが可能である。1つ又は複数の実施形態では、ウェブインタフェースを、詳細な要求を送信するために用いてもよい。1つ又は複数の実施形態では、所定の要求のために複数のプロトコルが結合されてもよい。1つ又は複数の実施形態では、要求は、要求のための所定のプロトコルを利用してもよく、異なるプロトコルを用いることにより要求結果を返してもよい。次には、要求に関するURL(ユニバーサルリソースロケータ(Universal Resource Locator))を、容易な検索のためのブックマークURLとしてブックマークしてもよい。
また、SRAは、比較的強力であるが単純でもある安全なユーザインタフェースを提供する。一般に、企業アプリケーションはセキュリティ及び信頼性を要求する。セキュリティは、機密情報が内密に、かつ盗聴者を避けて保たれることを必要とする。一方で、信頼性は、メッセージが、当該メッセージが発信者であると意図する者から到来していることを必要とする。アクセス装置は、一般に信任されているアドレスを含むメッセージを受け入れることによって、実質的にロバストなメッセージ認証を可能にする。即ち、望まれないメッセージ又は不正な送信者は検出されて回避されることが可能である。
普及しているメッセージプロトコル(SMS、SMTP)は一般に安全ではないので、容易に傍受されかつ不正に応答される可能性がある。1つの解決方法として、メッセージがソース側で秘密鍵を用いて暗号化され、次いで送信者の公開鍵を用いて宛先側で復号化される公開鍵インフラストラクチャ(PKI(public key infrastructure))技術が用いられてきている。今日のモバイル装置はPKIを用いるのに十分なメモリ及び計算能力を有する場合もあるが、一般に秘密鍵を安全に保持するためのメカニズムを設けていない。
例えば、(想像することは極めて困難であろう)秘密鍵も比較的長く、当該秘密鍵を思い出すことは困難である傾向があるので、モバイル装置上では比較的短くて思い出し易いPIN又は(想像することが比較的容易であろう)個人識別番号を用いて保護される場合が多い。従って、比較的弱いPINを用いる比較的強い秘密鍵のローカルな記憶装置は、装置の持ち主の権利及び特権を、上記PINを正しく推測して上記装置を用いる者に不注意で暴露する場合がある。
本アクセス装置は、モバイル装置における鍵管理の問題を未然に防ぐ場合があり、例えば異なるメモリサイズ(例えば、多大なメモリを有するものもあれば、僅かなメモリしか持たないものもある)、異なるプログラミング言語(例えば、C/C++でプログラムされるものもあれば、ジャバ(Java(登録商標))でプログラムされるものもある)、異なる構成要素(例えば、SIMカードを有するものもあれば、持たないものもある)などの装置間の差に関連づけられる問題を未然に防ぐ場合がある。本アクセス装置は、単純なメッセージプロトコル(SMTPなど)に、PINを用いるオプションをも用いて暗号化されたトークンを通過させるメッセージ交換を積み重ねることにより、要求を保護してもよい。結果的に、計算集約的な暗号化は、(比較的弱いプロセッサを有するであろう)クライアント装置ではなく、(強力なプロセッサセットを有するであろう)アクセスサーバにおいて行われてもよい。
本アクセス装置はまた、管理されたサービス又はファイアウォール内にインストールされる企業内電化製品の何れかとして提供されてもよいハードウェア/ソフトウェアの組合せも備える。アクセス装置の「フロントエンド」は、クライアントからの要求を受信しこれに応答するメッセージサーバ(又はメッセージモジュール)であってもよい。アクセス装置の「バックエンド」は、要求を処理し、要求者に代わって適切なアプリケーションにアクセスする要求サーバ(又は要求モジュール)を備える。メッセージサーバと要求サーバとの組合せは、一般に、各クライアントのためのプロキシサーバとして機能してもよい。即ち、本アプリケーションは、クライアント自身と直接的に対話するのではなく、アクセス装置と対話していることを必ずしも認識していなくてもよい。
ある実施形態では、メッセージサーバは、例えばSMTP、SMS、MMS、IM、XMPP、ウェブサービス、SOAP、XML、WAP、WML、HTTPS、HTTPなどのうちの1つ又はそれ以上であるメッセージサービスを実行することに加えて、外部システムの構成要素と内部システムの構成要素との間のゲートウェイでもある。別の実施形態では、メッセージサーバはまた、遠隔管理のための安全なウェブサーバ及びファイアウォールを運転させる。セキュリティを最大にするために、一般に他のポート又はネットワーク接続は外界に対して利用不可にされてもよい。スケーラビリティ及び利用可能性の観点から、メッセージサーバを複製することが可能である。メッセージサーバは、プロフィールデータベースに記憶されるデータを用いて認証システムを運転させてもよい。無効なメッセージは、放棄されるか拒否される。有効なメッセージは即座に処置されてもよいが、大部分のメッセージは、同様にデータベース内又はファイルシステム上に記憶される持続性のメッセージ待ち行列の1つに追加される。
一般に、本アクセス装置内では、メッセージ待ち行列は、データの整合性及びパフォーマンス関して最適化される方法で、コンピュータクラスタの異なるノード上に展開されてもよい。即ち、ある特定のメッセージ待ち行列は2つ以上のソースから同時に修正されてもよく(例えば、追加、削除など)、しかもアクセス装置内で一貫した状態を保持する。
要求サーバは、持続性の待ち行列からメッセージを取り出し、当該メッセージから入力データ/パラメータを抽出し、ユーザ信任状などのプロフィール情報を追加し、クライアントアプリケーションに渡す。即ち、要求サーバは所望される情報アクセスを実行し、又は要求により指定されるトランザクションを実行し、結果を返す。要求サーバは、上記結果を単純なメッセージにフォーマットして、ユーザへ返す。スケーラビリティ及び利用可能性の観点から、要求サーバを複製することが可能である。各サーバは待ち行列から次のメッセージを取り出し、他のサーバを妨害しない。
要求サーバは、1つ又は複数のクライアントアプリケーション機器を用いることによりアプリケーションを実行できる場合が多い。クライアント機器をまた、唯一の又は少数のアプリケーションのみを実行するように専門化することが可能である。これは、クライアントアプリケーションが多くのコンピューティングリソースを必要とする場合又はおそらくは外部のネットワーク接続又はデータベースへの専用のアクセスを必要とする場合に有益である。これらの場合には、異なる待ち行列が用いられる。メッセージサーバは適切な待ち行列にメッセージを方向づけ、当該待ち行列の要求サーバのセットのみが当該待ち行列からメッセージを取り出す。
結果的に生じるシステムは実質的にあらゆる側面に拡張可能であり(例えば、メッセージサーバ、要求サーバ及びクライアントアプリケーション機器は全て複製されうる)、実質的に高い利用可能性、及び、実質的に容易な保守及び更新パスを有する実質的なスケーラビリティ(低コストのシステムから適正価格の高い能力のシステムまで)が保証される。一般に、小型で低コストのシステムは移動する少数の人員を擁する組織に必要とされるが、大企業に関するシステムの場合は単一のコンピュータの能力を上回る。
本アクセス装置はまた、実質的に並列の動作も可能にする。例えば、メッセージサーバを、単一のコンピュータ上で、又は並列のコンピュータセット上で運転させることが可能である。追加のコンピュータを、いつでも単純に追加することが可能である。ユーザプロフィールデータの保持には単一の論理データベースが用いられ、要求に応じて容量及びパフォーマンスをスケーリングする際には、従来のデータベース複製が用いられる。小規模設備では、要求サーバはデータベースと並列に動作することが可能であり、又は最大のサーバのニーズに適合するようにサーバセット上に分散されることが可能である。クライアントアプリケーションは、作業負荷及び必要とされる応答時間に適合するように追加されてもよい。
また、本アクセス装置は、年中無休の利用可能性も可能にする。固有の冗長性を有効にすることにより、アクセス装置は、任意の1つの構成要素が故障した場合でもスケーラビリティ及びシステム利用可能性の両方を可能にする。メッセージは、メッセージサーバの何れかによって処理されることが可能である。例えば、任意の要求サーバ又はクライアントアプリケーション機器が故障したとすれば、サービスを継続するために他の要求サーバ又はクライアントアプリケーション機器を用いることができる。要求を処理している間に1つの要求サーバが故障すれば、タイムアウトが発生し、次の要求サーバが自動的に処理を引き継ぐ。
本アクセス装置はまた、高信頼性でもある。信頼性は、予測されるシステム行動と、不測のシステム入力を含む実際のシステムの動作との間の差の尺度である。本アクセス装置は、例えば送信者のIPアドレスとドメインとが整合するかどうかを確認するDNSの前方/逆引き探索チェック(forward and reverse DNS lookup checking)によって、偽のメッセージが拒絶されることを可能にする。また、偽メッセージの検出を、有効な送信側IPアドレスがドメインDNSにリストされる送信者ポリシフレームワーク(SPF(Sender Policy Framework))などの最新技術を用いて達成してもよい。また、オープンシステムはサービス拒絶攻撃(DoS(denial-of-service attacks))を受けやすいので、本アクセス装置は、このような攻撃を検出して応答する特別の技術を有する。悪質な送信者を早期に識別することは、コンピュータリソース(CPUタイム、メモリ、ログファイル)がほとんど浪費されないことを保証し、「ターピット(tarpit)」技術を用いることによって1つの場所からの複数の入力は遅延される。正当なユーザには一般に影響は出ないが、不正なユーザはサービス損失が発生し得ない速度にまでサービスを遅延される。
システムの監視及び管理も、コストを低く保つために自動化される。要求されると、これらの監視及び管理機能を、安全なウェブアクセスを用いて遠隔から利用できる。適正に認証されたユーザは、任意のウェブブラウザからアクセスサーバ(1つ又は複数の実施形態に係るメッセージサーバ及び要求サーバを含む)を管理することができる。
本発明の特徴及び優位点は、図面及び以下の論考を参照することにより、より良く理解されるものと思われる。
図1は、本発明の1つ又は複数の実施形態に係るアプリケーション/情報アクセス装置の簡略化されたブロック図である。ユーザは、クライアント装置102を動作させてもよい。クライアント装置102は、移動電話機、無線電子メール装置(例えば、ブラックベリ(Blackberry))、PDA又はラップトップコンピュータなどのモバイル装置を示してもよい。クライアント装置102は、移動しない(non-mobile)コンピュータを示してもよい。移動電話機、特に今日のスマートホンのうちの1つは、急速に、特に優れたモバイル装置となりつつあると思われる。
クライアント装置102は、広域ネットワーク104などのネットワークを介して単純な要求アクセスサーバ106(SRAサーバ106)に接続している。広域ネットワーク104は、無線ネットワークとインターネットとの組合せを示してもよい。SRAサーバ106は、プロキシサーバを示してもよい。SRAサーバ106は、[後述される]メッセージサーバと、[後述される]要求サーバとを含んでもよい。SRAメッセージは、クライアントのAPIにより用いられるリモートプロシージャコール(RPC(Remote Procedure Call))メカニズムに酷似する要求を伝達するために用いられる。
広範な装置及びネットワークを最大限に利用するため、及びコルバ(CORBA)のようなRPCプロトコルの複雑さを回避するために、本アクセス装置は、人が読み取ることのできるアドレス及びメッセージのためのテキストを用いてもよい。単純なメッセージング能力はセキュリティ及び認証性に必要であろう全ての事柄であるので、これは実質的に全ての装置からのアクセスを保証する。
SRAサーバ106は、ユーザ認証、要求の拡大(augmentation)及び個人化に用いられるユーザプロフィールデータベース108を保持してもよく、ユーザプロフィールデータベース108では、ユーザの好み、デフォルト値及び信任状などの情報が記憶され暗号化されてもよい。例えば、「ティッカーシンボル(Ticker Symbol)XXXの株価を得る」又は「電話番号を調べる」といった信任されていない要求は認証を必要としない。信任されている要求は、登録されているユーザのリストを参照して検証される。信任が厚い要求は、上述したように、通常は登録されているユーザのリストを参照する検証及び確認メッセージの両方を必要とするだけでなく、認証トークンが、最初に予め手配された「認証アドレス」に、オプションとして追加のPINと共に送信されることもまた必要とする。SRAサーバ106は、(必要であれば認証されている)要求メッセージを受信すると、これを直接的に処置してもよく、WAN(広域ネットワーク(wide area network))111(例えば、インターネットなど)上で公に利用可能なインターネットサーバ116a−bに接続してもよく、又は上記要求をLAN(ローカルエリアネットワーク(local area network))114又は(図示されていない)無線ネットワークを介して1つ又は複数のアプリケーションサーバ120へ送ってもよい。アプリケーションサーバ120は、データベース112などの持続性のデータ記憶装置に接続されてもよい。多くの要求に対して、SRAサーバは要求者に代わって行動し、ユーザプロフィールデータベースからのデータを用いてインターネット上で個人情報にアクセスし、又はユーザの代わりにクライアントアプリケーション110にログインする。1つ又は複数の実施形態では、クライアントアプリケーション110へのアクセスは、ユーザ自身の意志に沿ってユーザインタフェースを介して行われる。例えば、SRAサーバ106は、通常はクライアントアプリケーション110により人であるユーザと対話するために用いられるGUI(グラフィックユーザインタフェース(graphical user interface))ベースのトランザクション(例えば、テキスト、マウスの移動及びクリックなど)を傍受してもよい。
要求者のプロフィールは、ユーザ名及びオプションとして各要求のパスワードを含み、公衆WAN111を介して私的な情報(例えば、ユーザ名、パスワードなど)が送信されないことを保証する。また、ユーザプロフィールデータベースは、適切なファイアウォールによって安全に保護されてもよい。ある実施形態では、SRAサーバ106は、セキュリティを維持するために、(例えば、SMTP SMTP、SMS、MMS、IM、XMPP、ウェブサービス、SOAP、XML、WAP、WML、HTTPS、HTTPなどのうちの1つ又はそれ以上のための)WANに対して開かれたポートを3つ又は4つだけ備えてもよい。別の実施形態では、クライアントアプリケーションは典型的なクライアント/サーバ企業アプリケーションの一部であり、クライアントはおそらくは企業ファイアウォール内部のローカルエリアネットワークを介して、アプリケーションサーバ及びデータベースに接続する。
図2は、本発明の1つ又は複数の実施形態に係るユーザ要求を処理する認証メカニズムを示す簡略化されたブロック図である。クライアント装置102は、ステップ211において、アクセス又はトランザクションの許可を得るためにSRAメッセージ(第1のユーザメッセージ)を送信してもよい。SRAサーバ106は、ステップ212において、メッセージ送信者の名前を用いて、データベース108内のユーザプロフィールを探索してもよい。ユーザプロフィールの一部は、許可を得るために用いられるユーザのアドレスである。上記アドレスは、クライアント装置102であってもよい。あるいは又は追加的に、上記アドレスは、異なる装置を示してもよい。上記異なる装置及びSRAサーバ106は、同一のメッセージングプロトコルを用いても、異なるメッセージングプロトコルを用いてもよい。
次に、SRAサーバ106は、暗号化されたトークンを発生し、当該トークンを用いて関連する一時的なメールボックス(例えば電子メールアドレス、電話番号、ウェブアドレス又はURLである一時的なアドレス又はインスタントメッセージアドレス)を生成してもよい。次にシステムは、ステップ213において認証要求をユーザに送り返してもよい。1つ又は複数の実施形態では、このメールボックスのアドレスは決して事前には存在せず、数分で失効するものであってもよく、従って盗聴者は当該アドレスを事前に知ることはできず、暗号化されたトークンの解読を試みるための時間は数分しかないものと思われる。トークン鍵の長さの選択及び短時間での失効は、実質的にセキュリティを保証する。ステップ214において、クライアント装置102(ユーザ)は、(第2のユーザメッセージにおいて)認証要求に対して肯定的に(より確実な要求にするために個人識別番号であるPINなどの追加の識別情報を追加して)応答してもよい。ステップ214において、SRAサーバ106が認証応答を受信すると、一時的なメールボックスは破壊されてもよく、元の要求は、一般に認証されたとしてマーク付けされる。次に、SRAサーバ106は、ステップ215において、上記要求を適切なクライアントアプリケーション110に送ってもよい。クライアントアプリケーション110は、216において、クライアントアプリケーション110からの結果をSRAサーバ106へ返してもよい。SRAサーバ106は、217において、上記結果をクライアント装置(及びユーザ)に送信してもよい。
図3は、本発明の1つ又は複数の実施形態に係る不正な要求を処理する図2の認証メカニズムを示す簡略化されたブロック図である。不正なクライアント302は、ステップ311において、偽の「発信元:」アドレスを用いてSRAサーバ106へ(偽の)要求を送信することにより、アクセス装置を突き破ろうとする。次に、SRAサーバ106は、認証のためにデータベース108内のアドレスを探索してもよい。次いで、暗号化されたトークン及び一時的なメールボックスが生成されてもよい。
これに続いて、ステップ313では、認証要求が正当なクライアント304(正当なユーザ304)の信任されているアドレスのうちの1つのアドレスに転送される。即ち、正当なユーザ304は、偽の認証要求及び送信側アドレスを受信する。正当なユーザ304は、単にこれを無視してもよい。また、正当なユーザ304は、314において否定的に応答してもよく、続いてステップ315において、クライアントアプリケーション110が保護されていることを示す確認メッセージをSRAサーバ106から受信してもよい。この否定的な応答は、不正なクライアント302を識別し当該不正なクライアント302からのさらなるアクセスをブロックするために用いられてもよい。上述したように、信任されているアドレスセットを用いることは、SRAサーバ106が、特にSMTPなどの容易に偽造され得る一般的なインターネットプロトコルと共に用いられる場合に、スパムのないメッセージサーバとして動作することを可能にする。
図4は、本発明の1つ又は複数の実施形態に係るアクセス装置のスケーラビリティを示す簡略化されたブロック図である。メッセージサーバ及び要求サーバなどの(図1に示されている)SRAサーバ106の1つ又は複数の構成要素は、パフォーマンス及び利用可能性に関する任意の要望に適合するようにスケールアップされてもよい。スケーラビリティは、大企業のニーズに適合するためだけでなく、適正なサイズのシステムを最低のコストで単純な成長経路(growth path)によって配備するためにも重要である場合がある。
メッセージサーバ(例えば、SMTPサーバ402a−c)は、ラウンドロビン(round-robin)DNSなどの従来のIPスプレイング(spraying)技術又は負荷をバランスさせるための他の解決方法又はシスコシステムズ株式会社(Cisco Systems, Inc.)(www.cisco.com)から市販されているローカルディレクター(Local Director)などの機器によって負荷を分散してもよい。
データベース108は、ネットワークを介して同時にアクセスする複数の読み手及び書き手に関して必要最小限のロッキングで設計される場合のあるメッセージ待ち行列を、記憶してもよい。これは、高い信頼性で高いパフォーマンスを保証する。容量は、異なる待ち行列を異なるシステム上へ記憶することによって拡張されることが可能である。
要求サーバ404a−cは、当該要求サーバ404a−cに指定されたメッセージ待ち行列からメッセージを取り出し、これらを順次処理し、続いて当該メッセージをクライアントアプリケーション406a−bのうちの少なくとも1つなどの適切なクライアントアプリケーションに転送してもよい。1つの要求が終了されると、直ちに次のメッセージが処理され、負荷は自然に分散される。要求サーバの数が少ないほど、提供されるシステムのコストは下がるであろうが、システムが混雑しているときには応答時間における待ち時間は長くなるであろう。追加コストで要求サーバ404a−cの数を増やすと、システムが混雑しているときでも待ち時間は最小限に維持されるであろう。また、要求サーバをオンザフライ(リアルタイム)で追加することは容易である場合があるので、システムを処理及びパフォーマンス上のニーズに適合するようにスケーリングすることが可能である。
図5は、本発明の1つ又は複数の実施形態に係るメッセージ保護メカニズムを示す簡略化されたブロック図である。着信してくるメッセージは、不正なメッセージ又はエラーメッセージに対して費やされるコンピューティングリソースが最小になるようにふるい分けられてもよい。メッセージ保護メカニズムも同様に、サービス拒絶(DoS(Denial of Service))攻撃の防止を手助けする場合がある。メッセージ保護メカニズムを、SMTPサーバ402aなどのメッセージサーバに実装してもよい。
論理回路511において、着信してくるメッセージのソースアドレス(例えば、IPアドレス)は既知のスパムソースのブラックリスト508と比較されてもよく、ブラックリスト508に示されているメッセージは、システムに受け入れられることすらなく、直ちにドロップされる。論理回路512では、メッセージングプロトコル及び、ソースIPアドレスにDNS MXレコードがない、ソースのDNSエントリがないなどの偽のメッセージにおいて不正である場合の多い項目のヘッダ情報に対して幾つかの追加のチェックが実行され、偽のメッセージとして検出されたメッセージは直ちに拒絶される。
アクセス装置(又はSMTPサーバ402a)は、「バウンス」メッセージをソースへ送り返すように構成されてもよく、さらに上記ソースが偽のソースであるときには、当該バウンスメッセージが再度「バウンス」する。これらのダブルバウンスメッセージは、一般にエラー(時として、一時的なエラー)であるので、ログはされるがそれ以上の処理はされない。これらの早期のチェックはアクセス装置内の構成要素に掛かる負荷を低減する場合があり、当該構成要素をDoS攻撃から防止する手助けをする。各チェックは、あらゆるソースアドレスについて、1つ又は複数の特定のIPアドレスについて、又は1つ又は複数のIPアドレスの範囲に対して有効又は無効にされてもよい。早期のチェックは、組織がメッセージ送信サーバを正しくセットアップせず(例えば、DNSエントリの欠落、逆引きDNSの不在、MXエントリの欠落)、しかも上記組織は正当なメッセージソースであって受け入れられる必要がある場合に特に重要であることがある。アクセス装置の管理者は、チェックを動的に有効化及び/又は無効化してもよい。また、追加のスパムフィルタリングが用いられてもよい。
論理回路3では、これまでは未知であるユーザ(ソース)からの認証メッセージがチェックされてもよい。メッセージが暗号化された名前の特定のメールボックスに宛てられていて、当該メッセージが有効な応答(タイムアウト時間内、必要であればPINを伴っているなど)であるときに、そのユーザは「認証」され、当該ユーザのプロフィールがデータベース108に追加/更新される。
論理回路514では、「認証された」確認メッセージがユーザの[図示されていない]クライアント装置へ返されてもよい。誰が認証されることになるかに関する特定の詳細は、システム毎に変わってもよい。公開のシステムは、全てのユーザを(ブラックリストに記載されていない限り)認証してもよい。非公開のシステムは、何らかの他のデータベース/ディレクトリ(例えば、LDAP、MSアクティブディレクトリなど)において既知であるユーザのみを許可する場合もあり、「認証された」確認メッセージを用いる必要はない場合がある。
論理回路515では、メッセージが「認証された」メッセージでないときには、当該メッセージがチェックされることにより、ユーザが既知である(即ち、メッセージのソースアドレスがユーザプロフィールデータベース内の1つに一致する)か否か、及びこの要求に対する信任されていないアクセスが許可されるか否かが確認される。ユーザが未知のユーザであるときには、制御は論理回路516に移行し、ユーザが既知であるときに、又は信任されていないアクセスが許可されるときに、制御は論理回路517に移行する。
論理回路516では、(暗号鍵を用いて)認証(歓迎)メッセージが生成され、ユーザへ返されてもよい。ソースアドレスが偽物でありかつ/又は無効であるときに、この認証メッセージは待ち行列に入れられるか、喪失されるか、バウンスするであろうから、ソースアドレスは未知のままである。
論理回路517では、メッセージ/要求は構文解析され、適切な処理のために送り出されて(ディスパッチされて)もよい。幾つかの要求は論理回路518において直ちに応答を生じさせ、他の要求は持続性の待ち行列510に入れられる。待ち行列510では、要求は今後のアクションのために保留されてもよい。
図6は、本発明の1つ又は複数の実施形態に係るアプリケーション/情報アクセスのタイプ(要求タイプ)及び要求処理を示す。要求処理は、図4に示す要求サーバ404aなどの要求サーバにおいて実施されてもよい。要求サーバは、要求待ち行列602から次の要求を取り出し、当該要求のタイプに従って当該要求を処理してもよい。
本アクセス装置は、要求メッセージからの入力及び出力パラメータをアプリケーションインタフェースを用いて整合させる、通常は単純なスクリプトの形式である高速開発技術を利用してもよい。複雑な要求は、単純なスクリプトの組合せによって構築されてもよい。例えば、「UPCから製品を探索する」及び「製品の見積価格を入手する」を組み合わせることによって、「UPCから見積価格を入手する」要求を新たに生成してもよい。なお、本アクセス装置は、複数の要求サーバが並列動作することを可能にするように構成されてもよい。並列処理は、容量の必要条件に適合するようにシステムをスケーリングするために重要である場合がある。
また、個々の要求サーバは、特殊なソフトウェア又はハードウェアの搭載が要求されるときに重要である特有の要求を扱うように専門化されてもよい。
タイプ611の要求は、構造化された要求を必要とする1つ又は複数の最新のウェブサービスに対する要求を示してもよい。要求サーバは、タイプ611の要求メッセージからの構造化されていない入力パラメータを整合し、当該構造化されていない入力パラメータをWSDL(ウェブサービス定義言語(Web Service Definition Language))パラメータに定義された構造化されたXML(structured XML)の文書にコピーしてもよい。ウェブサービス要求から返されるXML文書による結果は、WSDLの出力パラメータを用いて抽出され、XSLTを用いて適切にテキストにフォーマットされ、ユーザへの応答メッセージに入れられてもよい。このパラメータの整合及びフォーマットには高速スクリプトを用いてもよく、スクリプト高速の作成及び簡単な保守が可能になる。
タイプ612の要求は、ウェブページの取り出し(フェッチ)などの構造化されていない、又は比較的構造化されていない要求を受け入れる1つ又は複数のIPサービスに対する要求を示してもよい。要求サーバは、タイプ612の要求からの入力パラメータを適切な要求(例えば、HTTP GET又はPOSTなど)へコピーしてもよく、また返された結果の抽出を方向付けてもよい。可能な限り、HTMLの結果はXMLに変換され、タイプ611と同一の構造化された抽出及びフォーマット技術が用いられてもよい。タイプ612のスクリプトは、比較的構造化されていない要求及び応答を使うことに固有のばらつきを扱うために、タイプ611のスクリプトより僅かに複雑であってもよい。それにも関わらず、タイプ612のスクリプトはタイプ3の要求(後述する)よりも単純であってもよく、なおも高速開発技術の利点を提供する場合がある。
タイプ613の要求は、新しいクライアントプログラムを書くという、新規のアプリケーションからのアプリケーションデータにアクセスする従来の方法を示してもよい。プログラムは、要求から入力パラメータを取り出し、ベンダにより提供されるAPIを用いてアプリケーションへ送り、次に結果を返すように記述される。新しいクライアントプログラムの開発及び保守は実質的に高価であることは一般に既知であるので、タイプ613の要求は通常、本アクセス装置から排除されてもよい。それでもなお、タイプ611及びタイプ612が利用不可である場合には、例えば必要に応じて利用可能にされてもよい。
タイプ4の要求は、アプリケーションアクセスの問題を解決する新しい高速開発アプローチを示してもよい。このアプローチは、スクリーンスクレーピング、切り貼り及びOCRの各技術を用いる新規の「ビジュアルAPI」を用いてもよい。スクリプトは、入力及び出力パラメータの整合を、既存のアプリケーションの表示画面上の入力及び出力フィールドに方向づけてもよい。要求サーバは、入力パラメータを入力フィールドへ貼り付けてもよく、スクリプトによる命令に従って出力パラメータを抽出する。タイプ4の要求は、高価なプログラミングを必要とすることなく、既存のアプリケーション及びレガシーアプリケーションにアクセスするために用いられてもよい。タイプ4の要求は、シトリックス(Citrix)、VNC、MS端末サーバ、VT100などのうちの1つ又はそれ以上を含むブラウザベースのアプリケーション又は端末セッションアプリケーションを利用してもよい。タイプ4スクリプトは、一般に単純であり、書き込みが速く、保守が容易である。
図7は、本発明の1つ又は複数の実施形態に係るアクセスシステム700の構成を示す簡略化されたブロック図である。アクセスシステム700の(例えばインターネットである通信ネットワーク790に面している)フロントエンドは、メッセージソフトウェア(例えば、SMTPなど)を実行するSMTPサーバ702a−bなどの1つ又は複数のコンピュータを備えてもよい。上記1つ又は複数のコンピュータはファイアウォールを動作させてもよく、管理用のウェブサーバを動作させてもよい。故障又は保守の間にも継続して利用できる最少でも2つサーバが存在することが好ましい場合がある。
(内部ネットワークに面する)バックエンドは、データベースサーバ708及び/又はレイド(RAID(redundant array of independent disks))ファイルシステム704を実行してもよい。大規模なアクセスシステムはデータベースサーバ708を二重化(duplicate)してもよく、関連のデータベースをRAIDファイルシステム704などの高い利用可能性のための従来のデータベース技術を用いて複製してもよい。必要に応じて、クライアントアプリケーションを実行するために追加の機器が包含されてもよい。これらのクライアントアプリケーションのうちのいくつかのクライアントアプリケーションは、企業サーバへのアクセスを要求してもよい。このアクセスは、通常、専用のネットワーク接続を用いて、又はおそらく公衆インターネット上のバーチャルプライベートネットワーク(VPN()virtual private network)を用いて実行されてもよい。本アクセスシステムのフロントエンド及びバックエンドは、リナックス(Linux)又はマイクロソフト(Microsoft)(登録商標)ウィンドウズ(Windows)(登録商標)などの周知のオペレーションシステム上で実行されてもよい。また、リナックスのオペレーションシステムであるクライアントアプリケーション110もリナックス又はマイクロソフト(登録商標)ウィンドウズ(登録商標)などの周知のオペレーションシステム上で実行されてもよいが、これは、本アクセスシステムのフロントエンド及び/又はバックエンドで実行されているオペレーションシステムと同一であっても異なっていてもよい。
図8は、本発明の1つ又は複数の実施形態に係るアクセスシステムの管理を示す簡略化されたブロック図である。本アクセスシステムの1つ又は複数のサーバ機能は、組み込まれた遠隔管理を有していてもよい。安全なネットワークインタフェース(例えば、HTTPS、SSHなど)は、本アクセスシステムのメッセージサーバ上へホストされてもよく、ウェブサーバ管理アプリケーション802a−bにアクセスするように用いられてもよい。ウェブサーバ管理アプリケーション802a−bは、例えばデータベースサーバ708及び/又はRAIDファイルシステム704に記憶される単純な要求アクセスデータベース、メッセージ待ち行列、システムログ、ブラックリストなどを管理するように構成されてもよい。また、クライアントアプリケーション804もまた、統合された遠隔制御機能を備えてもよい。これらの機器の遠隔管理は、例えば遠隔制御クライアントアプリケーションを用いて、又は遠隔コントロールアプレットを用いるウェブを介して実施されてもよい。本アクセスシステムのメッセージサーバ及び要求サーバのうちの1つ又はそれ以上は、無人で動作してもよい。例えば、ログファイルのロールオーバは自動であってもよく、メッセージ待ち行列は必要に応じて長くなりかつ短くなってもよい。システムの監視及び管理機能は、要求されると、任意の認証された適切な管理者によってウェブブラウザ又は管理コンソールから容易に実行されてもよい。
アクセスサービスプロバイダは、公衆及び登録ユーザに開放されている公衆アクセスサービスを実行してもよい。企業もまた、当該企業のユーザにアプリケーションアクセスを提供するためにアクセスシステムを採用してもよく、本アクセスシステムは、企業のために、アクセスサービスプロバイダにより管理されたサービスとして運用されてもよい。あるいは又は追加的に、本アクセスシステムは企業サイトにインストールされてもよく、当該企業によって運用されてもよい。
図9は、本発明の1つ又は複数の実施形態に係るアクセス装置と共にウェブサービスを用いることを示す簡略化されたブロック図である。一般に、ウェブサービスは、インターネットプロトコルのバックボーン上のXML、SOAP、WSDL及びUDDIといった公開されている規格のうちの1つ又はそれ以上を用いて複数のアプリケーションをSOA(サービス指向アーキテクチャ(services oriented architecture))に統合する標準化された方法を示してもよい。XMLはデータにタグ付けするために用いられてもよく、SOAPはデータを転送するために用いられてもよく、WSDLは利用可能なサービスを記述するために用いられてもよく、UDDIはどのようなサービスが利用可能であるかをリストするために用いられてもよい。
ウェブサービスは、異なる複数のソースからの異なる複数のアプリケーションが時間のかかる特別のコーディングなしに互いに通信することを可能にし、すべての通信はXMLで行われるので、ウェブサービスは任意の1つのオペレーションシステム又はプログラミング言語に縛られない。例えば、特別なプログラミングなしに、ジャバはパール(Perl)と話すことができ、ウィンドウズのアプリケーションはユニックス(UNIX(登録商標))のアプリケーションと話すことができる。
図9における例では、アクセスサーバ906a−bは、図1に示すSRAサーバ106などの1つ又は複数のSRAサーバを示してもよい。アクセスサーバ906a−bは、ユーザ902a−cがウェブサービスプロバイダ908a−cからウェブサービスにアクセスすることを可能にしてもよい。1つ又はそれ以上の実施形態では、アクセスサーバ906a−bは、ユーザ902a−cから着信するテキストメッセージを適切なウェブサービスプロトコルに翻訳するように構成されてもよい。図9における例で示すように、アクセスサービス906bなどのアクセスサービスは、ユーザ902cなどのユーザが、1つの要求によってサービスプロバイダ908a及び908cなどの複数のウェブサービス(又はサービスプロバイダ)にアクセスすることを可能にしてもよい。
アクセスサーバ906a−bは、ユーザ902a−cからの様々な入力メッセージタイプ及びプロトコル(SMTP、SMSなど)を処理するように構成されてもよい。アクセスサーバ906a−bはまた、サービスプロバイダ908a−cからのウェブサービス呼び出しの形式のXMLメッセージを処理するように構成されてもよい。アクセスサーバ906a−bはまた、関連のウェブサービス(例えば、アクセスサービス906bに関連づけられるサービスプロバイダ908a及び908c)の利用可能性を、UDDIを利用して標準的な方法で公開するように構成されてもよい。
図9は、ユーザ902a−cがアクセスサーバ906a−bにメッセージを送信し、アクセスサーバ906a−bがサービスプロバイダ908a−cのうちの1つ又はそれ以上にアクセスする多階層(multi-tier)のサービスを示す。
本アクセス装置は、ユーザプロフィールのキャッシングなどのユーザ902a−c及びサービスプロバイダ908a−cの両方にとって著しい優位点を提供してもよい。例えば、ユーザ902aはアクセスサーバ906aに登録されていてもよく、ユーザ902aの必要なプロフィール及び好みの情報はユーザプロフィールデータベース108aに記憶されていてもよい。次にアクセスサーバ906aはサービスプロバイダ908bからウェブサービスにアクセスすることができ、続いてユーザ902aのプロフィールのコピーをユーザプロフィールデータベース108aからサービスプロバイダ908b及びユーザプロフィールデータベース910bへ転送することができる。アクセスサーバ906a−b間のプロトコルは、安全かつ信任されているものであってもよい。認証されると、メッセージは、ユーザの認証性を信任できる別のサーバへ安全に(例えば、SSL接続を用いて暗号化されて)送られてもよい。
ユーザ902aが新しいサービスプロバイダへのアクセスを追加することを希望する場合、ユーザ902aはアクセスサーバ906aに対してウェブサービスプロトコルを用いて新しいサービスプロバイダに接続するように命令してもよく、この場合も、ユーザ902aのプロフィールをユーザプロフィールデータベース108aから新しいサービスプロバイダへ転送してもよい。ユーザにとっての利点は、同一の登録情報を入力し直すことを回避すること、及びユーザプロフィール(即ち、名前、好み、パスワードなど)の単一のコピーを保持することを含む。ウェブサービスプロバイダにとっての利点は、ユーザと対話する単純化されたセキュリティインタフェースを含む。
本アクセス装置が提供する別の優位点は、即ちユーザのアクセスを監視し、管理しかつログすることのできる単一の場所である「制御ポイント」の生成であってもよい。制御ポイントは、例えば請求書作成又は報告又は監査に用いられてもよい。
図10は、本発明の1つ又は複数の実施形態に係るアクセス装置を用いてアプリケーションを実行するための方法を示すフローチャートである。本方法は、クライアント装置からアプリケーションサーバ上でのアプリケーション機能の実行を成し遂げるために実施されてもよい。クライアント装置は、プロキシサーバに接続されてもよい。プロキシサーバは、アプリケーション機能を実装するアプリケーションを実行するアプリケーションサーバに接続されてもよい。ステップ1002において、テキストメッセージは、クライアント装置から、プロキシサーバにおけるテキストメッセージの宛先アドレスで受信される。1つ又は複数の実施形態では、クライアント装置は第1のネットワークを介してプロキシサーバに接続され、プロキシサーバは第2のネットワークを介してアプリケーションサーバに接続される。1つ又は複数の実施形態では、第1のネットワークは広域ネットワーク及び無線ネットワークのうちの一方である。1つ又は複数の実施形態では、第2のネットワークは広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの1つである。次にステップ1004では、認証メッセージが、テキストメッセージの発信元アドレス(例えば、図3に示す不正なクライアント302)とは異なるテキストメッセージの確認アドレスのユーザ(例えば、図3の例に示す正当なユーザ304又は図2の例に示すクライアント装置102)に送信される。1つ又は複数の実施形態では、認証メッセージはユーザへ、ユーザからのテキストメッセージの送信に用いられる第2のプロトコルとは異なる第1のプロトコルを用いて送信される。
1つ又は複数の実施形態では、第1のプロトコル及び第2のプロトコルは、SMTP、SMS、MMS、IM、ウェブサービス、SOAP、XML、HTTPS及びHTTPのうちの少なくとも1つを含む。1つ又は複数の実施形態では、テキストメッセージの確認アドレスは、上記認証後には不活性にされるように構成される非持続性の(non-persistent)テキストメッセージアドレスを表す。1つ又は複数の実施形態では、テキストメッセージの宛先アドレスは、クライアント装置上のメッセージングアドレスブックに記憶される。最後にステップ1006では、ユーザが認証されていれば、アプリケーションサーバにおいてアプリケーション機能が実行される。アプリケーション機能は、例えば、信用限度額のチェック、株価の入手、発注、株式の売り、UPCコードからの製品調査及び製品見積価格の入手を含んでもよい。
図11は、本発明の1つ又は複数の実施形態に係る、例えばSRAサーバ106であるSRAサーバ106を示す簡略化されたブロック図である。上述したように、ユーザは、モバイル装置(即ち、移動電話機、ブラックベリ又はPDA)、ラップトップコンピュータ又は移動しないコンピュータなどのクライアント装置102を動作させてもよい。SRAサーバ106は、広域ネットワーク104(例えば、無線ネットワーク、インターネットなど)を介してクライアント装置102に接続してもよく、アプリケーション及びサービス1124a−dのセットに接続してもよい。SRAサーバ106は、後述するように論理回路モジュールセットを含んでもよい。
サービスガードモジュール1104は、SRAサーバ106を広域ネットワーク104上の攻撃的な装置による侵入及びサービス拒絶攻撃から保護してもよい。侵入は、SRAサーバ106上の、又はSRAサーバ106に接続される常駐のリソースの保全性、機密性又は利用可能性を危うくしようとするアクションセットを示してもよい。サービス拒絶攻撃は、SRAサーバ106に無用なトラフィックをフラッディングにより送ることによって当該SRAサーバ106を実質的に正常に機能しなくするように設計される攻撃のタイプを示してもよい。
1つ又は複数の実施形態では、サービスガードモジュール1104は、広域ネットワーク104からSRAサーバ106への認証されていないアクセス及びSRAサーバ106から広域ネットワーク104への認証されていないアクセスを防ぐためのファイアウォールとして機能してもよい。クライアント装置102への又はクライアント装置102からの全てのメッセージは、一般にサービスガードモジュール1104によってフィルタリングされる。例えば、サービスガードモジュール1104は、広域ネットワーク104へ出入りする各パケットが定義された規則セットに基づいて受け入れられ又は拒絶されるパケットフィルタリング技術を用いてもよい。また、サービスガードモジュール1104は、電子メールガード1104a、SMSガード1104b、IMガード1104c、HTMLガード1104dなどのサブモジュールをさらに含んでもよい。電子メールガード1104aは、SRAサーバ106を電子メールから保護するように構成されてもよい。一般に、電子メールはメッセージが大規模なグループ又は受信者へ即座に同報に送信されることを可能にするので、電子メールメッセージは、コンピュータ間にウイルスを、一般的には開かれた時点で実行される悪意のあるプログラムを含むメッセージへの「添付物」として運ぶために用いられることが多い。
SMSガード1104bは、攻撃的である可能性のあるSMSメッセージからSRAサーバ106を保護するように構成されてもよい。SMS又はショートメッセージサービスは、短いテキストメッセージが移動電話機、ファックス機器及び/又はIPアドレスに送信されることを可能にする。一般に、ショートメッセージは160英数字以下の長さであってもよく、画像又はグラフィックを含まない。
IMガード1104cは、IMメッセージから保護するように構成されてもよい。IM又はインスタントメッセージは、インターネット上で実質的にリアルタイムの通信を可能にするタイプの通信サービスである。
HTMLガード1104dは、HTMLコードを含むメッセージから保護するように構成されてもよい。HTML即ちハイパーテキストマークアップ言語は、一般に、ワールドワイドウェブ上で文書を作成するために用いられるオーサリング言語である。HTMLは、一般に、様々なタグ及び属性を用いることによりウェブ文書の構成及びレイアウトを定義する。
サービスガードモジュール1104は、要求パーサモジュール1106に接続されてもよい。要求パーサモジュール1106は、電子メール、SMS、IM及びHTMLメッセージをそれぞれ構文解析する電子メールパーサ1106a、SMSパーサ1106b、IMパーサ1106c及びHTMLパーサ1106dを含んでもよい。メッセージのタイプ(例えば、電子メール、SMS、IM及びHTML)に依存して、要求パーサモジュール1106は、クライアント装置102からの要求のテキストを、解析できる小さい構成要素に分割してもよい。例えば、要求は、命令−−変数@server.comのフォーマットで構成されてもよい。ここで、命令は、最も近いレストランの位置、現在の天候又は資金の振替などのSRAサーバ106によって実行されるべき要求を表すものであってもよく、変数は、位置、名前、口座番号、上述したような暗号化されたトークンなどの追加の情報を表すものであってもよく、server.comは、上記命令の実行場所としてユーザが希望する特定のSRAサーバ106の名前である。パーシングは、字句解析と意味解析とに分割されてもよい。字句解析は、もっぱら句読点及び他のキーに基づいて文字列をトークンと呼ばれる構成要素に分割してもよい。次いで意味解析は、文字列又は命令の意味を決定することを試行してもよい。
アクセス制御マネージャモジュール1108は要求パーサモジュール1106に接続されてもよく、かつSRAサーバ106(及び/又はアプリケーション及びサービス1124a−d)上のコンピュータリソースへのアクセスを制限するメカニズム及びポリシを制御してもよい。1つ又は複数の実施形態では、ACL即ちアクセス制御リスト(access control list)が用いられてもよい。ACLは、アプリケーション及びサービス1124a−dのうちの1つ又はそれ以上などの特定のシステムオブジェクトに対して各ユーザ又はグループがどのような許可又はアクセス権を有しているかをSRAサーバ106に通知するデータセットを示してもよい。各オブジェクトは、どのユーザが上記オブジェクトへのアクセスを有するかを識別する固有のセキュリティ属性を有してもよく、ACLは各オブジェクト及びユーザのアクセス特権(読み取り、書き込み又は実行など)のリストを示してもよい。
要求アクションバスモジュール1110は、アクセス制御マネージャモジュール1108をサービスコネクタモジュール1112に接続してもよい。ユーザがアクセス制御マネージャモジュール1108によって認証されると、ユーザ要求は要求アクションバスモジュール1110内の行列に入れられてもよい。ここで、上記ユーザ要求は、例えばアプリケーション及びサービス1124のうちの1つ又はそれ以上である適切なアプリケーション又はサービスが利用可能になったときに、サービススクリプトモジュール1132に基づいてサービスコネクタモジュール1112により引き出されてもよい。スクリプトは、ユーザ対話なしに実行され得るSRAサーバ106コマンドのリストを有するマクロファイル又はバッチファイルを示してもよい。1つ又は複数の実施形態では、サービススクリプト1132のスクリプトを書くために特定のスクリプト言語が用いられてもよい。1つ又は複数の実施形態では、SRAサーバ106が要求アクションバスモジュール1110上でユーザ要求を実行する順序は、これらが待ち行列に置かれた順序と同一であってもよい。1つ又は複数の実施形態では、幾つかのユーザ要求に他のものより高い優先順位が与えられてもよい。
ユーザからの入ってくるメッセージは、信任状、好み、デフォルト値、信任されている応答経路、応答プロトコル、応答フォーマット、必要な認証方法などのうちの1つ又はそれ以上などのユーザプロフィール情報によって拡大されてもよい。これは、簡潔な要求がユーザのタイプ分けを最小限にすることを可能にし、しかも複雑な演算を実行する場合のある処理に豊富なデータを提供する。この方法は、ネットワーク上で信任状を送信する必要又は信任状を悪意のあるソフトウェア又は送信側装置に対して危険に曝す必要を回避する。
サービスコネクタモジュール1112は、アプリケーション及びサービス1124a−dに接続するためのコネクタ及び/又はアダプタセットを含んでもよい。例えば、WSDLコネクタ1112aはSRAサーバ106が1つ又は複数のウェブサービス1124aに接続することを可能にしてもよい。WSDLは、一般に、ウェブサービスの能力をメッセージ交換能力のある複数の通信エンドポイントの集合(collection)として記述するために用いられるXMLフォーマットの言語である。1つ又は複数の実施形態では、WSDLコネクタ1112aはUDDIディレクトリに接続してもよい。UDDI即ち統一的な記述、発見及び統合(universal description, discovery and integration)は、一般に企業が自らをインターネット上へリストし、かつ従来の電話帳のイエローページ及びホワイトページと同様に互いに発見し合うことを可能にするウェブベースの分散されたディレクトリである。
HTMLコネクタ1112bは、SRAサーバ106が1つ又は複数のウェブアプリケーション1124bに接続することを可能にしてもよい。上述したように、HTMLは一般に、ワールドワイドウェブ上で文書を作成するために用いられるオーサリング言語である。HTMLコネクタ1112bは、前に生成されたウェブページの一部が抽出されてクライアント装置102に配信されることを可能にしてもよい。
UIコネクタ1112cは、SRAサーバ106がUI即ちユーザインタフェース(user interface)を介して1つ又は複数のクライアントアプリケーション1124cに接続することを可能にしてもよい。UIは、人であるユーザがプログラムと通信するためのコマンドセット又はメニューセットとのインタフェースを示してもよい。追加のプログラミングの必要性を実質的に低減するために、UIコネクタ1112cは人であるユーザを模倣し、自動的にCDROM百科事典又は地図プログラムなどの遠隔ユーザアプリケーションに問い合わせて、そこから関連の情報を抽出するように構成されてもよい。
APIコネクタ1112dは、SRAサーバ106が1つ又は複数のアプリケーションサーバ1124dに接続することを可能にしてもよい。API即ちアプリケーションプログラムインタフェース(application program interface)は、ソフトウェアアプリケーションを構築するためのルーチン、プロトコル及びツールのセットを示してもよい。appサーバ即ちアプリケーションサーバは、一般にユーザとバックエンドのアプリケーション又はデータベースとの間のアプリケーションの動作を取り扱うプログラムである。appサーバは、典型的には、複雑なトランザクションベースのアプリケーション又はデータベースに用いられる。例えば、APIコネクタ1112dはSRAサーバ106をSAPアプリケーションサーバに接続し、ユーザがクライアント装置102から顧客の注文ステータスを問い合わせることを可能にしてもよい。
サービス管理モジュール1114は、SRAサーバ106の管理者がネットワーク、コンピュータ及びデータベースの集合を安全に管理することを可能にしてもよい。
プロフィール管理モジュール1116は、SRAサーバ106が各ユーザのサービス及びリソースプロフィールのセットを保持することを可能にしてもよい。例えば、ユーザは、要求を行うクライアント装置102のタイプに依存して要求がカスタマイズされることを望む場合がある。
サービス提供モジュール1118は、SRAサーバ106の管理者がユーザにアプリケーション及びサービス1124a−dのうちの1つ又はそれ以上へのアクセスを提供することを可能にしてもよい。一般に、上記提供は、ユーザのアイデンティティ及びプロフィール管理モジュール1116に記憶されている特定のプロフィールに基づいて、特定のユーザによる1つ又は複数の特定のサービス及び/又はアプリケーションへのアクセスを許容することを含む。
サービス監視モジュール1120は、SRAサーバ106管理者がネットワーク上の全てのハードウェア及びソフトウェアの目録を作成しかつ診断テストを実行することを可能にしてもよい。
利用報告モジュール1122は、SRAサーバ106内のリソースの利用並びにアプリケーション及びサービス1124へのユーザのアクセスを監視して報告してもよい。
1つ又は複数の実施形態では、トランザクションの状態は一時的なメールボックスの使用を介して保持されてもよい。インターネット上では一般的に、トランザクションの状態はブラウザのクッキーの使用を介して保持されることが多い。クッキーは、典型的には、ウェブサーバによりウェブブラウザへ与えられる小さいメッセージである。ブラウザは上記メッセージをテキストファイルで記憶し、ブラウザがサーバからページを要求する毎に当該メッセージをサーバへ送り返す。ウェブサーバが連続するウェブページ要求間で特定のブラウザ(又はユーザ)を識別することを可能にすることにより、クッキーは基本的な形式のトランザクションセキュリティを提供してもよい。即ち、トランザクションを開始する特定のブラウザ(即ち、Amazon.comから本を購入するユーザ)は、当該トランザクションを完了するブラウザと同一であるべきである。
しかしながら、ブラウザとは異なり、モバイル装置のアプリケーションは、一般にトランザクションではなく通信のために最適化される。即ち、モバイル装置は、電子メール及びSMSなどの音声及びテキストメッセージの送受信には十分に優れているが、多くのモバイル装置の物理的サイズ及び計算能力は、ウェブサーバなどのインターネットアプリケーションへのユーザインタフェースとしてのその効果を減じる場合がある。続いて、モバイル装置のメッセージングアプリケーションにおいて、トランザクション状態を保持するクッキーと同等のものは一般に存在しない。
ある非自明な方法において、1つ又は複数の実施形態では、トランザクション状態を保持するために、クッキーの代わりとしてサービスメールボックス(サービスアドレス)が用いられてもよい。即ち、クッキーをローカルに記憶する代わりに、クライアント装置には固有の返信用アドレスセット又はサービスメールボックスが付与される。特定のサービスメールボックスに対する応答は、特定のクライアント装置の状態の特定の変化をSRAサーバ106に対して信号で通知する。例えば、メニューーツリーの1つの経路の選択のように、複数の要求を含む場合のあるトランザクションの場合、特定のサービスメールボックスに対する応答は特定のメニューの選択に対応し、これにより、選択の次のレベルがクライアント装置に送信される場合がある。1つ又は複数の実施形態では、メニューは認証問い合わせ(クエリ)を含んでもよい。
これを、ウェブページ及びハイパーリンクと比較すると、ナビゲーションはリンクをクリックすることによって単純にされる。サービスメールボックスは、メッセージにおいてクリックへの単純なリンクとして用いられる。特定のサービスメールボックスに関連づけられる状態の情報は、必要な全てのナビゲーション及びトランザクションの情報を伝達する。サービスメールボックスのこのような使用は、メッセージングシステムをウェブのように使いやすくする。
例えば、ユーザは、特定の顧客の最新の注文総量を見るために、SRAサーバ106を介してSAPアプリケーションへのアクセスを希望する場合がある。上記ユーザは、アクセス制御マネージャ1108によって認証されているときには、第1のテキストメッセージをSRAサーバ106の特定の電子メールアドレスに送信することができ、これに続いて当該第1のテキストメッセージは、SRAサーバ106に対して、予め定義されたプロフィール情報及びスクリプトに基づいてSAPアプリケーションと通信するように命令する。例えば、サーバアドレス(サービスアドレス)は、名前−顧客名を題名にしてcm−SAP@server.comのように入力されてもよい。ここで、顧客名は関心対象である特定の顧客の名前であり、server.comはユーザが命令の実行場所として希望する特定のSRAサーバ106の名前である。
次に、SRAサーバ106は、メッセージ本体に下記のような単純化されたメニューを付してクライアント装置へテキストメッセージを返すことになる。
納品:cm−SAP−10000@server.com
現在の注文:cm−SAP−20000@server.com
入荷待ち:cm−SAP−30000@server.com
その他:cm−SAP−40000@server.com
返品:cm−SAP−50000@server.com
現在の注文:cm−SAP−20000@server.com
入荷待ち:cm−SAP−30000@server.com
その他:cm−SAP−40000@server.com
返品:cm−SAP−50000@server.com
各メニュー項目は、SAP−10000、SAP−20000、SAP−30000などのサービス識別情報を含む。cm−SAP−20000@server.comへテキストメッセージを送信すると、メッセージ本体に下記のような単純化されたサブメニューを付して新しいメッセージが送信される。
現在までの注文総量:cm−SAP−11000@server.com
現在までの四半期分注文量:cm−SAP−22000@server.com
現在までの一月分の注文量:cm−SAP−33000@server.com
最終注文量:cm−SAP−44000@server.com
その他:cm−SAP−55000@server.com
返品:cm−SAP−66000@server.com
現在までの四半期分注文量:cm−SAP−22000@server.com
現在までの一月分の注文量:cm−SAP−33000@server.com
最終注文量:cm−SAP−44000@server.com
その他:cm−SAP−55000@server.com
返品:cm−SAP−66000@server.com
cm−SAP−44000@server.comにテキストメッセージを送信することは、SRAサーバ106に対して顧客customernameによる最終注文の総量を送信することを命令する。
なお、サービスメールボックス名は、セキュリティを追加するために暗号化されてもよい。ユーザはリンクをクリックすることができて、アドレスをタイプする必要はないので、所望されるときに、長い暗号鍵を用いることができる。
1つ又は複数の実施形態では、アクセス装置に二つの要素の認証が用いられてもよい。上述したように、信任が厚い要求は、送信者が確認メッセージ又は認証トークンを用いることなどによってトランザクションを確認することを求める場合がある。しかしながら、通信チャネル又は通信経路が危うくされていれば、侵入者はその確認メッセージ又は認証トークンを傍受して正しく応答することがあり、正当なユーザがトランザクションを適正に確認したものとSRAサーバ106に信じ込ませる。セキュリティレベルを上げるためには、少なくとも2つの通信チャネル、即ち第1の主要なトランザクションチャネル及び第2の確認チャネルが用いられてもよい。
例えば、銀行は、認証を目的としてATM機器に接続されるアクセスサーバを有してもよい。ATMから一定額を超える金額(即ち、>$300)の引出しを希望する顧客は、ユーザのクライアント装置(即ち、携帯電話機、PDAなど)に特定のOTP(一回限りのPIN(one time PIN))などの一回限りの識別情報を伴うSMSメッセージを受信する。トランザクションを完了するためには、上記情報がATM機器に短時間(例えば、OTPの送信後3分以内)で入力される必要がある。
別の例では、ブラウザを用い銀行のウェブサイトから第三者の口座へお金を振り替えることを希望する顧客は、ブラウザウィンドウへ入力される必要のあるOTPを伴うSMSメッセージを受信することになる。別の例では、ATM機器又は銀行のウェブサイトは、トランザクションが認証される前にクライアント装置からSMS又は電子メールを介してアクセスサーバに送信されなければならない認証コード(例えば、セキュリティシリアル番号、アルファベットコード又は英数字コード)を発生する。
1つ又は複数の実施形態では、認証コード(例えば、セキュリティシリアル番号、アルファベットコード又は英数字コード)は、例えばアクセスサーバにより提供される鍵(又は種(乱数の初期値))を用いてRSA SecurID認証装置などのスマートカードによって発生される。次に、この認証コードはユーザ(又は、ユーザの監督者(supervisor)などの第2のエンティティ)へ表示されてもよく、ユーザ(又は、第2のエンティティ)は当該認証コードを入力し、認証を受けるために当該認証コードをアクセスサーバに送信しなければならない場合がある。認証コードの内容は、スマートカードにより周期的に、例えば60秒毎に変更(もしくは再発生)されてもよい。所定の時間に対する正しい認証コードは、ユーザが認証されてもよいようにアクセスサーバに送信される必要がある。スマートカードは、電子メモリと、おそらくは内蔵された集積回路(IC(integrated circuit))とを含む、ほぼクレジットカードのサイズの小型の電子装置を示してもよい。ICを含むスマートカードは、集積回路カード(ICC(Integrated Circuit Cards))と呼ばれることがある。ユーザが資金の引出し又は振替を希望すると、クライアント装置上にその時点で有効なトークンを要求するメッセージが受信されてもよい。1つ又は複数の実施形態では、確認メッセージは、アクセスサーバ要求を行っているユーザ以外のユーザに送信される。例えば、従業員は、確認メッセージが従業員の監督者に送信されて認められた後に資金の振替又は引出しを行うことができる。
1つ又は複数の実施形態では、アクセス装置は、トランザクションを認証するためにモバイル装置SIMを用いることができる。加入者識別モジュール(subscriber identity module)の略称であるSIMは、一般にGSM携帯電話機内の取外し可能なスマートカードであり、音声及びデータ送信を暗号化し、電話サービスを提供するネットワークに対してユーザが識別され認証されうるように、特定のユーザに関するデータを記憶する。SIMはまた、ユーザに特有の個人的な電話設定及び電話番号などのデータを記憶する。SIMは1つの電話機から別の電話機へ移動されることが可能であり、かつ/又は異なるSIMが任意のGSM電話機へ挿入されることが可能である。各SIM上の識別情報は一般に固有であるので、トランザクションは、始めにモバイル装置へ確認メッセージを送信し、上記確認メッセージをSIMカードで暗号化し、上記確認(又は、当該確認の暗号ハッシュ)をアクセスサーバへ返すことによって安全に認証されてもよい。
1つ又は複数の実施形態では、アクセスサーバはシングルサインオン機能を提供してもよい。クライアント/サーバの関係における認証処理であるシングルサインオンは、ユーザ又はクライアントが1つの名前及びパスワードを入力して2つ以上のアプリケーションへのアクセス又は企業内の幾つかのリソースへのアクセスを有することを可能にする。シングルサインオンは、一般に、ユーザが1つのアプリケーションから別のアプリケーションへ切り替える際にさらなる認証を入力する必要性を低減させる。
1つ又は複数の実施形態では、アクセスサーバは、W3C標準のXFormsを使用可能にされているクライアント装置に接続してもよい。一般にデータ入力後に各フォームがウェブサーバに送信されることを要求する標準のHTMLのWebフォームとは異なり、XFormsを使用可能なアプリケーションは、フォームセットがローカルに処理された後にウェブサーバへXML文書として送信されることを可能にしてもよい。また、XMLをデータの定義に用いかつHTML又はXHTMLをデータ表示に用いることにより、XFormsを使用可能なアプリケーションは、移動電話機、ハンドヘルド装置及び視覚障害者用の点字リーダなどの異なるユーザインタフェースのためにカスタマイズされてもよい。
1つ又は複数の実施形態では、アクセスサーバはRFIDを使用可能なモバイル装置と通信してもよい。無線周波識別(radio frequency identification)の略称であるRFIDシステムは、一般に、無線周波信号を放射して情報を処理装置に転送するアンテナ及び送受信機と、RF回路及び送信されるべき情報を含む集積回路であるトランスポンダ又はタグとから成る。バーコード技術とは異なり、RFIDは見通し範囲内での読み取り(line-of-sight reading)の必要性を減じ、より長い距離を隔てて実行されることが可能である。そうでなければ情報をタイプしなければならないようなユーザにとって、多大な優位点がある。また、何らかのサーバと通信する必要のあるモバイルRFID装置にとっても多大な優位点がある場合があり、本発明の1つ又は複数の実施形態に係るアクセス装置は、この問題に対して単純で低コストかつ効果的な解決方法を提供する場合がある。
例えば、ユーザが2つの薬剤間の薬物相互作用に関する情報を求めていれば、RFID対応モバイル装置はまず、各薬剤容器の上又は内部に記された情報読み取ってもよい。次に、このRFID情報はアクセスサーバに送信され、アクセスサーバは薬物相互作用のデータベースサービスへ問合せを行う。アクセスサーバは次に、特定の薬物相互作用情報をモバイル装置への応答としてカスタマイズされたテキストメッセージで送信してもよい。
1つ又は複数の実施形態では、アクセスサーバは、GPSを使用可能なモバイル装置と通信してもよい。全地球測位システム(Global Positioning System)の略称であるGPSは、一般に、地球の周りを回る24個の衛星と、これらに対応する地上の受信機とによって形成される世界的な衛星ナビゲーションシステムである。GPS衛星は、衛星の位置及び正確な時刻に関するデータを含むデジタル無線信号を地上にある受信機へ継続的に送信する。3つの衛星を用いることにより、GPSは、3つの球が交差する場所に基づいて受信機の経度及び緯度を計算することができる。4つの衛星を用いれば、GPSは標高も決定することができる。例えば、ユーザがレストランの位置などの位置に固有の情報を求めていれば、ユーザの現在位置は、ユーザが手動で入力する代わりに、GPS対応モバイル装置によってアクセスサーバへ自動的に送信されてもよい。アクセスサーバは次に、現在の住所から所望される住所への方向を含むテキストメッセージで応答してもよい。モバイルRFIDリーダの場合と同様に、これは、退屈なエラーの発生しやすい位置情報の手動入力を行おうとしないユーザにとって多大な優位点となることがある。
1つ又は複数の実施形態では、モバイル装置内のアドレスブックエントリは、コマンド構文のヘルプ及び/又はヒントに用いられてもよい。例えば、ユーザは、cmhelp@server.comなどのヘルプアドレスへメッセージを送ることによって、アクセスサーバに一般的なヘルプメニューに関する問合せを行うことができる。ここで、cmhelpは特定のヘルプ要求であり、server.comはユーザがヘルプ命令の実行場所として希望する特定のアクセスサーバの名前である。例えば、受信と同時に、テキストメッセージの本体として下記のような単純化された一般的なヘルプメニューが返されてもよい。
メール宛先:cmCurrency@server.com
GoCurrency.comにおける通貨の探索
メール宛先:cmDictionary@server.com
www.dictionary.comにおける単語の探索
メール宛先:cmDirections@server.com
www.mapquest.comからのドライブの方向
メール宛先:cmFroogle@server.com
製品のFroogle検索 froogle.google.com
メール宛先:cmGoo@server.com
PDAディスプレイのGoogle検索 google.com/palm
GoCurrency.comにおける通貨の探索
メール宛先:cmDictionary@server.com
www.dictionary.comにおける単語の探索
メール宛先:cmDirections@server.com
www.mapquest.comからのドライブの方向
メール宛先:cmFroogle@server.com
製品のFroogle検索 froogle.google.com
メール宛先:cmGoo@server.com
PDAディスプレイのGoogle検索 google.com/palm
さらに特定のヘルプは、例えば題名に単語「ヘルプ」を付した特定の要求を送信することによって入手されることが可能である。
1つ又は複数の実施形態では、ユーザの打ち込み(タイピング)の量を減らすために略語セットが用いられてもよい。例えば、ユーザは、cmkeyget@server.comへメッセージを送信することによって、アクセスサーバに略語セットの問合せを行うことができる。ここで、cmkeygetは略語又はキーリクエストであり、server.comはユーザがヘルプ命令の実行場所として希望する特定のアクセスサーバの名前である。例えば、受信と同時に、テキストメッセージの本体として下記のような単純化された一般ヘルプメニューが返されてもよい。
SFO−アドレス1
LAX−アドレス2
HOME−アドレス3
LAX−アドレス2
HOME−アドレス3
ユーザは次に、既存のキーを修正するか、新しいキーを追加して、テキストをcmkey@server.comに送信することができる。続いてユーザは、cmdirection:HOME:SFO@server.comへテキストメッセージを送信することによって自宅からサンフランシスコ空港への方向を要求することができる。
1つ又は複数の実施形態では、LOCNキーは、要求されるキーが失われている場合に位置に関する要求のためのデフォルトのキーであることが想定されてもよい。1つ又は複数の実施形態では、ユーザの現在の位置は、既知であれば(即ち、GPSを使用可能なユーザ装置、ユーザによる予めの入力などにより)、位置に関する要求のための現在の位置のキーであることが想定されてもよい。例えば、cmstarbucks@server.comへ題名なしのメッセージが送信されるときに、一般にアクセスサーバは、それがユーザの現在の位置であると信じる場所から最も近いスターバックスまでの方向を返すことになる。
以上、幾つかの好ましい実施形態に関連して本発明を説明してきたが、本発明の範囲内にある変形例、置換例及び同等物は存在する。本明細書に提示した発明の名称及び要約は便宜的なものであり、本発明を添付の請求の範囲を限定するように解釈するために用いられるべきではない。
従って、本発明の優位点には、信任されている汎用パーソナルアクセスシステム及びそのための方法のアーキテクチャが含まれる。追加の優位点には、内部及び外部ソースの両方への管理された企業アクセスのためのホスト型のアクセスインフラストラクチャ、アプリケーション及びウェブサービスへの指向性のトランザクションアクセスのための管理可能なインフラストラクチャ及び生産性の拡大及び総所有コスト(TCO(total cost of ownership))の低減が含まれる。
以上、例示的な実施形態及び最良の態様を開示したが、開示された実施形態には、添付の請求の範囲により定義される本発明の主題及び精神を逸脱することなく修正及び変形が行われてもよい。
Claims (83)
- スマートカードを有するクライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法であって、前記クライアント装置はプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
前記方法は、
前記クライアント装置上のアプリケーション機能要求セットから前記アプリケーション機能を実行する要求を選択することと、
前記要求に関する第1のテキストメッセージを前記プロキシサーバに送信することとを含み、前記第1のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第1のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
前記方法は、
トークン要求メッセージを、前記テキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスの前記ユーザに送ることと、
前記スマートカード内にトークンを発生することと、
前記トークンを前記プロキシサーバに送信することと、
前記トークンが有効であるときに、前記アプリケーションサーバにおいて前記第1のテキストメッセージによって指定される通りに前記アプリケーション機能を実行することとを含み、これにより、前記第1のアプリケーション機能は、少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される方法。 - 前記クライアント装置は第1のネットワークを介して前記プロキシサーバに接続され、前記プロキシサーバは第2のネットワークを介して前記アプリケーションサーバに接続される請求項1記載の方法。
- 前記第1のネットワークと前記第2のネットワークとは同一である請求項2記載の方法。
- 前記第1のネットワークと前記第2のネットワークとは異なる請求項2記載の方法。
- 前記第1のネットワークは、広域ネットワーク及び無線ネットワークのうちの少なくとも一方を含む請求項2記載の方法。
- 前記第2のネットワークは、広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの少なくとも1つを含む請求項2記載の方法。
- 前記第1のテキストメッセージはさらに前記第1のテキストメッセージの本体における複数のパラメータを含み、前記複数のパラメータは前記アプリケーション機能の実行に関する複数のパラメータを表し、前記複数のパラメータは英数字テキストとして表現される請求項2記載の方法。
- 前記トークン要求メッセージは、前記第1のテキストメッセージを前記ユーザから送信するために用いられた第2のプロトコルとは異なる第1のプロトコルを用いて前記ユーザに送信される請求項7記載の方法。
- 前記第1のプロトコル及び前記第2のプロトコルは、SMTP、SMS、MMS、IM、XMPP、ウェブサービス、SOAP、XML、WAP、WML、HTTPS及びHTTPのうちの少なくとも1つを含む請求項8記載の方法。
- 前記テキストメッセージの確認アドレスは、認証後には不活性にされるように構成される非持続性のテキストメッセージアドレスを表す請求項9記載の方法。
- 前記アプリケーション機能要求セットは、メッセージングアドレスブック、電子メール及びXML文書のうちの少なくとも1つに記憶される請求項1記載の方法。
- 前記第1のメッセージは、フォームを用いて前記クライアント装置上に生成される請求項1記載の方法。
- 前記フォームは、XForm、HTMLフォーム及びWMLフォームのうちの少なくとも1つを含む請求項13記載の方法。
- 前記テキストメッセージは人が読み取ることのできるテキストを含む請求項1記載の方法。
- 前記テキストメッセージはリモートプロシージャコールである請求項1記載の方法。
- 前記アプリケーションサーバはグラフィカルユーザインターフェースを含み、前記プロキシサーバは前記グラフィカルユーザインターフェースを介して前記アプリケーションサーバに接続される請求項1記載の方法。
- 前記アプリケーションサーバはAPIを含み、前記プロキシサーバは前記APIを介して前記アプリケーションサーバに接続される請求項1記載の方法。
- クライアント装置からアプリケーションサーバ上のアプリケーション機能の実行を成し遂げるための方法であって、前記クライアント装置はスマートカードを含みかつプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
前記方法は、
前記クライアント装置上のアプリケーション機能要求セットから前記アプリケーション機能を実行する要求を選択することと、
前記要求に関する第1のテキストメッセージを前記プロキシサーバに送信することとを含み、前記第1のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第1のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
前記方法は、
トークン要求メッセージを、前記テキストメッセージの発信元アドレスと同一のテキストメッセージの確認アドレスの前記ユーザに送ることと、
前記スマートカード内にトークンを発生することと、
前記トークンを前記プロキシサーバに送信することと、
前記トークンが有効であるときに、前記アプリケーションサーバにおいて前記第1のテキストメッセージによって指定される通りに前記アプリケーション機能を実行することとを含み、これにより、前記第1のアプリケーション機能は、少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される方法。 - クライアント装置がアプリケーションサーバ上のアプリケーション機能を遠隔から実行することを可能にするための装置であって、前記クライアント装置はスマートカードを含みかつプロキシサーバに接続され、前記プロキシサーバはさらに前記アプリケーション機能を実装するアプリケーションを実行する前記アプリケーションサーバに接続され、
前記装置は、
前記クライアント装置上のアプリケーション機能セットから前記アプリケーション機能を実行する要求を選択するための手段と、
前記要求に関する第1のテキストメッセージを前記プロキシサーバに送信するための手段とを備え、前記第1のテキストメッセージはテキストメッセージの宛先アドレスとテキストメッセージの発信元アドレスとを含み、前記第1のテキストメッセージは前記アプリケーション機能を実行する要求に関連し、
前記装置は、
トークン要求メッセージを、前記テキストメッセージの発信元アドレスとは異なるテキストメッセージの確認アドレスの前記ユーザに送るための手段と、
前記スマートカード内にトークンを発生するための手段と、
前記トークンを前記プロキシサーバに送信するための手段とを備え、
前記トークンが有効であるときに、前記アプリケーションサーバにおいて前記第1のテキストメッセージによって指定される通りに前記アプリケーション機能を実行し、これにより、前記第1のアプリケーション機能は、少なくとも前記テキストメッセージの宛先アドレスに基づいて確認される装置。 - 前記クライアント装置は第1のネットワークを介して前記プロキシサーバに接続され、前記プロキシサーバは第2のネットワークを介して前記アプリケーションサーバに接続される請求項19記載の装置。
- 前記第1のネットワークと前記第2のネットワークとは同一である請求項20記載の装置。
- 前記第1のネットワークと前記第2のネットワークとは異なる請求項21記載の装置。
- 前記第1のネットワークは、広域ネットワーク及び無線ネットワークのうちの少なくとも一方を含む請求項19記載の装置。
- 前記第2のネットワークは、広域ネットワーク、無線ネットワーク及びローカルエリアネットワークのうちの少なくとも1つを含む請求項20記載の装置。
- 前記第1のテキストメッセージはさらに前記第1のテキストメッセージの本体における複数のパラメータを含み、前記複数のパラメータは前記アプリケーション機能の実行に関するパラメータを表し、前記複数のパラメータは英数字テキストとして表現される請求項20記載の装置。
- 認証メッセージは、前記第1のテキストメッセージを前記ユーザから送信するために用いられた第2のプロトコルとは異なる第1のプロトコルを用いて前記ユーザに送信される請求項25記載の装置。
- 前記第1のプロトコル及び前記第2のプロトコルは、SMTP、SMS、IM、ウェブサービス、SOAP、XML、HTTPS及びHTTPのうちの少なくとも1つを含む請求項26記載の装置。
- 前記テキストメッセージの確認アドレスは、前記認証後には不活性にされるように構成される非持続性のテキストメッセージアドレスを表す請求項27記載の装置。
- 前記アプリケーション機能要求セットは、メッセージングアドレスブック、電子メール及びXML文書のうちの少なくとも1つに記憶される請求項19記載の装置。
- 前記アプリケーションサーバはグラフィカルユーザインターフェースを含み、前記プロキシサーバは前記グラフィカルユーザインターフェースを介して前記アプリケーションサーバに接続される請求項19記載の装置。
- 前記アプリケーションサーバはAPIを含み、前記プロキシサーバは前記APIを介して前記アプリケーションサーバに接続される請求項19記載の装置。
- ユーザがクライアント装置を用いて1つ又は複数のサーバ上に存在する1つ又は複数のアプリケーションにアクセスすることを、前記クライアント装置及び第2の装置のうちの少なくとも一方の装置において発生される認証コードによって容易にするためのシステムであって、
メッセージモジュールと、パーサと、コネクタとを備え、
前記メッセージモジュールは、前記ユーザから第1のユーザメッセージを受信し、前記第1のユーザメッセージに応答して、認証アドレスを発生し前記認証コードが発生されることを要求するための第1の要求を確認アドレスに送信するように構成され、前記確認アドレスは前記クライアント装置及び前記第2の装置の前記少なくとも一方の装置に対応し、
前記パーサは、前記認証アドレスにおいて前記認証コードを含む肯定の応答メッセージが受信されるときに、前記クライアント装置及び前記第2の装置の一方から送信される前記第1のユーザメッセージ及び第2のユーザメッセージのうちの少なくとも一方のメッセージから命令を抽出するように構成され、
前記コネクタは、前記命令が抽出されるときに、前記1つ又は複数のアプリケーションによって1つ又は複数の応答が発生され前記クライアント装置に送信されることをトリガするように、前記命令を前記1つ又は複数のサーバに伝達するように構成されるシステム。 - 前記認証コードは、前記クライアント装置及び前記第2の装置のうちの少なくとも一方に配置される取外し可能なモジュールによって発生される請求項32記載のシステム。
- 前記認証コードは、前記クライアント装置及び前記第2の装置の前記少なくとも一方の装置に表示され前記肯定の応答メッセージに手動で入力されるように構成される請求項32記載のシステム。
- 前記認証コードの内容は周期的に変更される請求項32記載のシステム。
- 前記認証コードは、数字コード、アルファベットコード及び英数字コードのうちの少なくとも1つを含む請求項32記載のシステム。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージのうちの少なくとも1つは前記クライアント装置から送信される請求項32記載のシステム。
- 前記認証アドレスは、前記認証アドレスが発生された後、所定の時間期間内に失効するように構成される請求項32記載のシステム。
- 前記認証アドレスは、第1の要求が送信された後、3分未満で失効するように構成される請求項32記載のシステム。
- 前記認証アドレスは暗号化される請求項32記載のシステム。
- 前記第1の要求は、前記第1の要求が送信された後、所定の時間期間内に失効するように構成される一回限りの識別情報を含み、前記肯定の応答メッセージは前記一回限りの識別情報をさらに含む請求項32記載のシステム。
- 前記一回限りの識別情報は、前記第1の要求が送信された後、3分未満で失効するように構成される請求項41記載のシステム。
- 前記確認アドレスは前記第1のユーザメッセージの発信元アドレスとは異なる請求項32記載のシステム。
- 前記確認アドレスは、前記ユーザ及び前記ユーザの監督者のうちの少なくとも一方に関連づけられる請求項32記載のシステム。
- 前記認証アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項32記載のシステム。
- 前記確認アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項32記載のシステム。
- 前記肯定の応答メッセージは、前記確認アドレスに加えて識別情報を含む請求項32記載のシステム。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージのうちの少なくとも1つは、SMTP、SMS、MMS、IM、ウェブサービス、SOAP、XML、WAP、WML、HTTPS及びHTTPのうちの少なくとも1つに従う請求項32記載のシステム。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージの前記少なくとも一方のメッセージ又はそれ以上は、SMTP及びSMSのうちの少なくとも一方に従う請求項32記載のシステム。
- 前記コネクタはさらに、SMTP、SMS、MMS、IM、ウェブサービス、SOAP、XML、WAP、WML、HTTPS及びHTTPのうちの少なくとも1つに従うプロトコルを用いて前記1つ又は複数のサーバと通信するように構成される請求項32記載のシステム。
- 前記確認アドレスは前記第1のユーザメッセージの発信元アドレスを表す請求項32記載のシステム。
- 前記第1の要求及び前記メッセージモジュールにより前記クライアント装置に送信される第2の要求のうちの少なくとも一方はメニューを含み、前記メニューは1つ又は複数のメニュー項目を含み、前記1つ又は複数のメニュー項目は、1つ又は複数の認証問い合わせ、及び前記1つ又は複数のアプリケーションにより提供される1つ又は複数のサービスのうちの少なくとも一方を表す請求項32記載のシステム。
- 前記第1の要求及び前記第2の要求のうちの少なくとも1つはSMTP及びSMSのうちの少なくとも一方に従う請求項52記載のシステム。
- 前記1つ又は複数のメニュー項目はそれぞれサービスアドレスを含み、前記サービスアドレスは第1の部分と第2の部分とを含み、前記第1の部分はサービス識別情報を含み、前記第2の部分はシステムを識別する請求項52記載のシステム。
- 前記サービスアドレスは暗号化される請求項54記載のシステム。
- 前記サービスアドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項54記載のシステム。
- 前記コネクタは、前記命令を前記1つ又は複数のサーバのうちの2つ以上のサーバへ同時に伝達するように構成される請求項32記載のシステム。
- ユーザがクライアント装置を用いて1つ又は複数のサーバ上に存在する1つ又は複数のアプリケーションにアクセスすることを、前記クライアント装置及び第2の装置のうちの少なくとも一方の装置において発生される認証コードによって容易にするためのコンピュータ実装方法であって、
前記ユーザから第1のメッセージを受信することと、
認証アドレスを発生することと、
前記認証コードが発生されることを要求するための第1の要求を確認アドレスに送信することとを含み、前記確認アドレスは前記クライアント装置及び前記第2の装置の前記少なくとも一方の装置に対応し、
前記実装方法は、
前記認証アドレスにおいて前記認証コードを含む肯定の応答メッセージが受信されるときに、前記クライアント装置及び前記第2の装置の一方から送信される前記第1のユーザメッセージ及び第2のユーザメッセージのうちの少なくとも一方から命令を抽出することと、
前記命令が抽出されるときに、前記1つ又は複数のアプリケーションによって1つ又は複数の応答が発生され前記クライアント装置に送信されることをトリガするように、前記命令を前記1つ又は複数のサーバに伝達することとを含むコンピュータ実装方法。 - 前記認証コードは、前記クライアント装置及び前記第2の装置のうちの少なくとも一方に配置される取外し可能なモジュールによって発生される請求項58記載のコンピュータ実装方法。
- 前記認証コードは、前記クライアント装置及び前記第2の装置の前記少なくとも一方の装置に表示され前記肯定の応答メッセージに手動で入力されるように構成される請求項58記載のコンピュータ実装方法。
- 前記認証コードの内容は周期的に変更される請求項58記載のコンピュータ実装方法。
- 前記認証コードは、数字コード、アルファベットコード及び英数字コードのうちの少なくとも1つを含む請求項58記載のコンピュータ実装方法。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージのうちの少なくとも1つは前記クライアント装置から送信される請求項58記載のコンピュータ実装方法。
- 前記認証アドレスは、前記認証アドレスが発生された後、所定の時間期間内に失効するように構成される請求項58記載のコンピュータ実装方法。
- 前記認証アドレスは、第1の要求が送信された後、3分未満で失効するように構成される請求項58記載のコンピュータ実装方法。
- 前記認証アドレスは暗号化される請求項58記載のコンピュータ実装方法。
- 前記第1の要求は、前記第1の要求が送信された後、所定の時間期間内に失効するように構成される一回限りの識別情報を含み、前記肯定の応答メッセージは前記一回限りの識別情報を含む請求項58記載のコンピュータ実装方法。
- 前記一回限りの識別情報は、前記第1の要求が送信された後、3分未満で失効するように構成される請求項67記載のコンピュータ実装方法。
- 前記確認アドレスは前記第1のユーザメッセージの発信元アドレスとは異なる請求項58記載のコンピュータ実装方法。
- 前記確認アドレスは、前記ユーザ及び前記ユーザの監督者のうちの少なくとも一方に関連づけられる請求項58記載のコンピュータ実装方法。
- 前記認証アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項58記載のコンピュータ実装方法。
- 前記確認アドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項58記載のコンピュータ実装方法。
- 前記肯定の応答メッセージは、前記確認アドレスに加えて識別情報を含む請求項58記載のコンピュータ実装方法。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージのうちの少なくとも1つは、SMTP、SMS、MMS、IM、ウェブサービス、SOAP、XML、WAP、WML、HTTPS及びHTTPのうちの少なくとも1つに従う請求項58記載のコンピュータ実装方法。
- 前記第1のユーザメッセージ及び前記第2のユーザメッセージのうちの少なくとも一方又はそれ以上は、SMTP及びSMSのうちの少なくとも一方に従う請求項58記載のコンピュータ実装方法。
- 前記コネクタはさらに、SMTP、SMS、MMS、IM、ウェブサービス、SOAP、XML、WAP、WML、HTTPS及びHTTPのうちの少なくとも1つに従うプロトコルを用いて前記1つ又は複数のサーバと通信するように構成される請求項58記載のコンピュータ実装方法。
- 前記確認アドレスは前記第1のユーザメッセージの発信元アドレスを表す請求項58記載のコンピュータ実装方法。
- 前記第1の要求及び前記メッセージモジュールにより前記クライアント装置に送信される第2の要求のうちの少なくとも一方はメニューを含み、前記メニューは1つ又は複数のメニュー項目を含み、前記1つ又は複数のメニュー項目は、1つ又は複数の認証問い合わせ、及び前記1つ又は複数のアプリケーションにより提供される1つ又は複数のサービスのうちの少なくとも一方を表す請求項58記載のコンピュータ実装方法。
- 前記第1の要求及び前記第2の要求のうちの少なくとも1つはSMTP及びSMSのうちの少なくとも一方に従う請求項78記載のコンピュータ実装方法。
- 前記1つ又は複数のメニュー項目はそれぞれサービスアドレスを含み、前記サービスアドレスはサービス識別情報とアクセスシステム識別情報とを含む請求項78記載のコンピュータ実装方法。
- 前記サービスアドレスは暗号化される請求項80記載のコンピュータ実装方法。
- 前記サービスアドレスは、電子メールアドレス、電話番号、ユニバーサルリソースロケータ及びインスタントメッセージアドレスのうちの少なくとも1つを含む請求項80記載のコンピュータ実装方法。
- 前記命令は前記1つ又は複数のサーバのうちの2つ以上のサーバへ同時に伝達される請求項58記載のコンピュータ実装方法。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/280,140 US7844674B2 (en) | 2004-12-03 | 2005-11-15 | Architecture for general purpose trusted personal access system and methods therefor |
US11/422,317 US7870201B2 (en) | 2004-12-03 | 2006-06-05 | Apparatus for executing an application function using a mail link and methods therefor |
US11/422,318 US7870202B2 (en) | 2004-12-03 | 2006-06-05 | Apparatus for executing an application function using a smart card and methods therefor |
PCT/US2006/044261 WO2007059169A2 (en) | 2005-11-15 | 2006-11-14 | Media transfer protocol |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2009516305A true JP2009516305A (ja) | 2009-04-16 |
Family
ID=38049255
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008541296A Pending JP2009516306A (ja) | 2005-11-15 | 2006-11-14 | メッセージリンクを利用するアプリケーションアクセス |
JP2008541294A Pending JP2009516305A (ja) | 2005-11-15 | 2006-11-14 | クライアントによって発生される認証コードを用いるアプリケーションアクセス |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2008541296A Pending JP2009516306A (ja) | 2005-11-15 | 2006-11-14 | メッセージリンクを利用するアプリケーションアクセス |
Country Status (4)
Country | Link |
---|---|
EP (2) | EP1955184A2 (ja) |
JP (2) | JP2009516306A (ja) |
CA (2) | CA2627530A1 (ja) |
WO (2) | WO2007059183A2 (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010146169A (ja) * | 2008-12-17 | 2010-07-01 | Nippon Telegr & Teleph Corp <Ntt> | Webシステムおよびリクエスト処理方法 |
JP2015501572A (ja) * | 2011-10-12 | 2015-01-15 | テクノロジー・ビジネス・マネジメント・リミテッド | セキュアid認証のためのシステム |
JP7223196B1 (ja) | 2022-03-07 | 2023-02-15 | PayPay株式会社 | 情報処理装置、情報処理方法、およびプログラム |
Families Citing this family (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7274928B2 (en) | 1998-10-02 | 2007-09-25 | Telespree Communications | Portable cellular phone system having automatic initialization |
EP2165488A4 (en) * | 2007-06-05 | 2015-08-26 | Secure Mailbox Sweden Ab | DIRECT AND SECURE INFORMATION CHANNEL |
JP4807377B2 (ja) * | 2008-05-13 | 2011-11-02 | ソニー株式会社 | 通信装置、通信方法、通信システム及びサービス発行方法 |
US20120110011A1 (en) * | 2010-10-29 | 2012-05-03 | Ihc Intellectual Asset Management, Llc | Managing application access on a computing device |
CN103209198B (zh) * | 2012-01-13 | 2016-06-15 | 深圳市腾讯计算机系统有限公司 | 一种网络应用之间的切换方法和系统 |
JP2013205604A (ja) * | 2012-03-28 | 2013-10-07 | Toshiba Corp | 通信装置および鍵管理方法 |
JP5853890B2 (ja) * | 2012-07-25 | 2016-02-09 | カシオ計算機株式会社 | ソフトウェア実行制御装置、実行制御方法、及び実行制御プログラム |
US9264414B2 (en) * | 2013-03-15 | 2016-02-16 | Microsoft Technology Licensing, Llc | Retry and snapshot enabled cross-platform synchronized communication queue |
AU2014264204B2 (en) * | 2013-05-10 | 2019-04-18 | Truteq International (Pty) Ltd | A method and system for communicating banking-related security messages |
US9088568B1 (en) | 2013-09-11 | 2015-07-21 | Talati Family LP | Apparatus, system and method for secure data exchange |
US10861090B2 (en) | 2013-11-27 | 2020-12-08 | Apple Inc. | Provisioning of credentials on an electronic device using passwords communicated over verified channels |
US10275823B2 (en) * | 2015-06-15 | 2019-04-30 | Adidas Ag | Systems and techniques for computer-enabled geo-targeted product reservation for secure and authenticated online reservations |
JP6753728B2 (ja) * | 2016-08-23 | 2020-09-09 | Line株式会社 | プログラム、情報処理方法、及び端末 |
JP6560649B2 (ja) * | 2016-09-30 | 2019-08-14 | Kddi株式会社 | 認証サーバ、端末装置、システム、認証方法、及びプログラム |
CN111984958B (zh) * | 2020-08-06 | 2024-02-02 | 成都安恒信息技术有限公司 | 一种支持vnc双因子的认证方法 |
US20230319017A1 (en) * | 2022-03-30 | 2023-10-05 | Seclore Technology Pvt Ltd. | System and method for automatic document protection using information rights management |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5953506A (en) * | 1996-12-17 | 1999-09-14 | Adaptive Media Technologies | Method and apparatus that provides a scalable media delivery system |
US6292833B1 (en) * | 1998-07-17 | 2001-09-18 | Openwave Systems Inc. | Method and apparatus for providing access control to local services of mobile devices |
GB2346766A (en) * | 1999-02-12 | 2000-08-16 | Nokia Mobile Phones Ltd | Routing messages between a client and a selected server |
US20040193694A1 (en) * | 1999-11-10 | 2004-09-30 | Randy Salo | Application gateway systems |
US6938087B1 (en) * | 2000-09-12 | 2005-08-30 | Hewlett-Packard Development Company, L.P. | Distributed universal communication module for facilitating delivery of network services to one or more devices communicating over multiple transport facilities |
US7631084B2 (en) * | 2001-11-02 | 2009-12-08 | Juniper Networks, Inc. | Method and system for providing secure access to private networks with client redirection |
GB0204589D0 (en) * | 2002-02-27 | 2002-04-10 | Gordano Ltd | Filtering E-mail messages |
US8032592B2 (en) * | 2002-04-18 | 2011-10-04 | Intuit Inc. | System and method for data collection and update utilizing surrogate e-mail addresses using a server |
GB2400254A (en) * | 2003-03-31 | 2004-10-06 | Sony Uk Ltd | Video processing |
-
2006
- 2006-11-14 WO PCT/US2006/044284 patent/WO2007059183A2/en active Application Filing
- 2006-11-14 CA CA002627530A patent/CA2627530A1/en not_active Abandoned
- 2006-11-14 WO PCT/US2006/044261 patent/WO2007059169A2/en active Application Filing
- 2006-11-14 JP JP2008541296A patent/JP2009516306A/ja active Pending
- 2006-11-14 EP EP06837628A patent/EP1955184A2/en not_active Withdrawn
- 2006-11-14 CA CA002627534A patent/CA2627534A1/en not_active Abandoned
- 2006-11-14 JP JP2008541294A patent/JP2009516305A/ja active Pending
- 2006-11-14 EP EP06837611A patent/EP1955183A2/en not_active Withdrawn
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2010146169A (ja) * | 2008-12-17 | 2010-07-01 | Nippon Telegr & Teleph Corp <Ntt> | Webシステムおよびリクエスト処理方法 |
JP2015501572A (ja) * | 2011-10-12 | 2015-01-15 | テクノロジー・ビジネス・マネジメント・リミテッド | セキュアid認証のためのシステム |
JP7223196B1 (ja) | 2022-03-07 | 2023-02-15 | PayPay株式会社 | 情報処理装置、情報処理方法、およびプログラム |
JP2023130280A (ja) * | 2022-03-07 | 2023-09-20 | PayPay株式会社 | 情報処理装置、情報処理方法、およびプログラム |
Also Published As
Publication number | Publication date |
---|---|
EP1955184A2 (en) | 2008-08-13 |
EP1955183A2 (en) | 2008-08-13 |
CA2627534A1 (en) | 2007-05-24 |
CA2627530A1 (en) | 2007-05-24 |
WO2007059169A2 (en) | 2007-05-24 |
WO2007059183A3 (en) | 2009-04-30 |
JP2009516306A (ja) | 2009-04-16 |
WO2007059183A2 (en) | 2007-05-24 |
WO2007059169A3 (en) | 2009-04-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7870201B2 (en) | Apparatus for executing an application function using a mail link and methods therefor | |
US7870202B2 (en) | Apparatus for executing an application function using a smart card and methods therefor | |
US7844674B2 (en) | Architecture for general purpose trusted personal access system and methods therefor | |
JP2009516305A (ja) | クライアントによって発生される認証コードを用いるアプリケーションアクセス | |
US12051075B2 (en) | Systems and methods for providing notifications to devices | |
US8122251B2 (en) | Method and apparatus for preventing phishing attacks | |
EP2375688B1 (en) | Managing automatic log in to Internet target resources | |
US8621604B2 (en) | Evaluating a questionable network communication | |
US8019995B2 (en) | Method and apparatus for preventing internet phishing attacks | |
US9002018B2 (en) | Encryption key exchange system and method | |
US20150229609A1 (en) | Evaluating a questionable network communication | |
US10846432B2 (en) | Secure data leak detection | |
US20060174119A1 (en) | Authenticating destinations of sensitive data in web browsing | |
WO2015023316A1 (en) | Evaluating a questionable network communication | |
WO2014105263A1 (en) | Multi-factor authentication and comprehensive login system for client-server networks | |
WO2006056992A2 (en) | Obtaining and assessing objective data relating to network resources | |
CN114826692B (zh) | 信息登录系统、方法、电子设备及存储介质 | |
Curran et al. | Integrating geolocation into electronic finance applications for additional security | |
Perišić | Web Services Security: an Overview | |
Rautila et al. | Secure inspection of web transactions | |
Ryan et al. | Usable Encryption Enabled by AJAX | |
WO2023166336A1 (en) | System and method to prevent an attack on an application programming interface | |
Kyrillidis et al. | Web Server on a SIM card | |
Celikkan et al. | NFC based mobile single sign-on solution as a chrome extension | |
Pendlimarri et al. | Ancillary Resistor leads to Sparse Glitches: an Extra Approach to Avert Hacker using Syndicate Browser Design |