サーバ・オペレーションの認可を行うための装置、システムおよびコンピュータ・プログラム
【課題】データ通信ネットワークを介してユーザ・コンピュータから要求されたリモート・サーバのオペレーションを認可するための認可デバイスが提供される。
【解決手段】デバイスは、リモート・サーバとの通信のためにデバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、ユーザに情報を提供するためのユーザ・インタフェースとを有する。デバイスの制御ロジックは、セキュリティ・データを用いて、デバイスとサーバとの間に、ローカル・ユーザ・コンピュータを介して、デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合される。制御ロジックは、サーバへの他の接続を介したユーザ・コンピュータによって要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバからこの接続を介して収集する。ユーザによる認可を促すために、この情報はユーザ・インタフェースを介してユーザに提供される。サーバ・オペレーションは、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データに従って制御される。サーバ制御装置の制御ロジックは、そのオペレーションに対する少なくとも１人の認可ユーザによる認可が必要かどうかをルール・データから判定することによって、ユーザ・コンピュータからのオペレーション要求に応答する。もし認可が必要であれば、オペレーションは延期される。認可デバイスとの相互認証された接続が確立されるとき、制御装置は、ユーザ・コンピュータから要求されデバイス・ユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を供給できる。延期オペレーションは、そのオペレーションに必要な認可を出すすべての認可ユーザからの認可を受取ったときにのみ実行され、モバイル・コンピューティング環境における安全なマルチ・パーティ認可を提供する。
【解決手段】デバイスは、リモート・サーバとの通信のためにデバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、ユーザに情報を提供するためのユーザ・インタフェースとを有する。デバイスの制御ロジックは、セキュリティ・データを用いて、デバイスとサーバとの間に、ローカル・ユーザ・コンピュータを介して、デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合される。制御ロジックは、サーバへの他の接続を介したユーザ・コンピュータによって要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバからこの接続を介して収集する。ユーザによる認可を促すために、この情報はユーザ・インタフェースを介してユーザに提供される。サーバ・オペレーションは、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データに従って制御される。サーバ制御装置の制御ロジックは、そのオペレーションに対する少なくとも１人の認可ユーザによる認可が必要かどうかをルール・データから判定することによって、ユーザ・コンピュータからのオペレーション要求に応答する。もし認可が必要であれば、オペレーションは延期される。認可デバイスとの相互認証された接続が確立されるとき、制御装置は、ユーザ・コンピュータから要求されデバイス・ユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を供給できる。延期オペレーションは、そのオペレーションに必要な認可を出すすべての認可ユーザからの認可を受取ったときにのみ実行され、モバイル・コンピューティング環境における安全なマルチ・パーティ認可を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般的に、データ通信ネットワーク上のユーザ・コンピュータから要求されたサーバ・オペレーションの認可に関する。リモート・サーバ・オペレーションを認可し、こうした認可に依存してサーバによるオペレーションの実行を制御するための装置、システムおよびコンピュータ・プログラムが提供される。
【背景技術】
【０００２】
コンピュータのユーザが、サーバによる何らかのオペレーションの実行を要求するために、データ通信ネットワークを介してリモート・サーバと通信するためのシナリオは多数存在する。こうしたサーバは典型的に、リモート・ユーザによるオンライン・アクセスのためのサービスのプロバイダによって動作される。しかし本明細書において、「サーバ」という用語は最も一般的な意味で用いられ、接続するユーザに何らかのサービスまたは機能を提供するあらゆるコンピュータまたはシステムを含む。ユーザの要求によってサーバが実行するオペレーションは、たとえばデータベースまたは制限されたウェブ・サイトなど、何らかのリソースへのユーザのアクセスを単に認めることであってもよいし、ユーザによって指示される、たとえば銀行取引など何らかのトランザクションの実現であってもよい。いずれの場合においても、通信インフラストラクチャは、セキュリティ、特にサーバ・オペレーションが正しく認可されたユーザに対してのみ実行されることを確実にすることがしばしば重要な問題となるという性質をもつ。たとえばインターネット上で行われる電子ビジネスの場合、オンライン詐欺は絶えず増加を続ける脅威である。悪名高い中間者（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ：ＭＩＴＭ）などの高度な攻撃、およびたとえばウイルスまたはトロイの木馬などのさまざまなタイプの悪意あるソフトウェアは増加して広まっており、一方でアンチウイルス・ソフトウェアおよびファイアウォールなどの対抗策は、いつも攻撃者に一歩後れを取っているようにみえる。その結果、パーソナル・コンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒｓ：ＰＣｓ）などのユーザ・コンピュータおよびインターネット自体を、電子トランザクションに対するかなりのセキュリティ上のリスクを与える本質的に信頼できないものと考える必要がある。たとえば、ユーザが自身のＰＣからオンライン・サービス・プロバイダのポータルに接続してトランザクションを開始するとき、そのトランザクションが何らかの悪意あるソフトウェアまたはＭＩＴＭによって密かに操作されていないことをユーザは確信できない。サービス・プロバイダも、自身が正しく認可されたユーザと通信していることを確信できないという同様の困難に面する。
【０００３】
上記シナリオにおけるセキュリティの問題のいくつかに対処するために、さまざまなシステムが提案されてきた。たとえば、特許文献１は、ユーザＰＣに接続可能であって、スマート・カードのための読取装置を組込んだセキュリティ・デバイスを開示している。ユーザが自身のＰＣを介してリモート・サーバからのリソースを要求するとき、サーバはユーザの公開鍵を検索し、トランザクション情報をチャレンジとともに含む暗号化したデータ・ブロブを送り返すことによって応答する。ユーザＰＣから要求されたリソースがセキュリティ・デバイス上に表示され、ユーザはセキュリティ・デバイスへの入力によってこのリソースを要求したか否かを確認でき、この入力はサーバに送り返される。このデバイスは、所与のＰＣのユーザが、そのＰＣから一度に１つ発行されるリソース要求の同時確認を与えることを可能にする。しかし、このシステムは「偽チャレンジ（ｆａｌｓｅ−ｃｈａｌｌｅｎｇｅ）」攻撃を受けやすい。つまり、たとえばユーザを混乱させて応答させるために、何らかの悪意あるパーティがユーザの公開鍵のもとで暗号化チャレンジを生成して、それをユーザＰＣに送ることがあり得る。さらに、誰でもユーザの公開鍵によってチャレンジに対するユーザの応答メッセージを解読することができる。したがってこのシステムの有用性は限定されており、それ自体のセキュリティおよびプライバシーの問題を生じる。
【０００４】
２００７年１１月１９日に出願された我々の同時係属中の特許文献２は、ユーザ・コンピュータへの接続のための別のデバイスを開示している。このデバイスは、非特許文献１にも記載されている。このデバイスは、特定の銀行ＵＲＬ（ユニバーサル・リソース・ロケータ（ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ））に接続するためのブラウザによって接触されるユーザＰＣ上のプロキシ・アプリケーションに促されるときに、サーバとの安全な相互認証されたエンド・ツー・エンド接続をセットアップする。次いで、安全な接続を介して次のブラウザ・セッションが行われ、セキュリティ・デバイスによってモニタされる。デバイスが銀行取引の詳細などの機密情報を検出すると、それがデバイス上に表示され、ユーザはボタンを押して自身の確認を示すことができる。セキュリティ・デバイスはこの確認を受取ったときのみ、接続を維持してサーバにトランザクション要求を転送する。このデバイスも、所与のＰＣのユーザが、そのＰＣから一度に１つ発行される要求の同時確認を与えることを可能にするが、この場合には、いつユーザ認可が必要かを判断するセキュリティ・デバイスの制御下にある安全な接続を介してすべてのサーバ・セッションが行われる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第６，８９５，５０２号
【特許文献２】欧州特許出願第０７０２２４１９．１号
【非特許文献】
【０００６】
【非特許文献１】“Ｔｈｅ Ｚｕｒｉｃｈ Ｔｒｕｓｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ−Ａｎ Ｅｆｆｉｃｉｅｎｔ Ｄｅｆｅｎｃｅ ａｇａｉｎｓｔ Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ ａｎｄ Ｍａｌｉｃｉｏｕｓ Ｓｏｆｔｗａｒｅ Ａｔｔａｃｋｓ”，Ｔｈｏｍａｓ Ｗｅｉｇｏｌｄ ｅｔ ａｌ．，ｉｎ Ｐ．Ｌｉｐｐ，Ａ．−Ｒ．Ｓａｄｅｇｈｉ，ａｎｄ Ｋ．−Ｍ．Ｋｏｃｈ（Ｅｄｓ．）：ＴＲＵＳＴ ２００８，ＬＮＣＳ ４９６８，ｐｐ．７５−９１，Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ ２００８
【発明の概要】
【発明が解決しようとする課題】
【０００７】
パーソナル・コンピュータ（ＰＣ）などのユーザ・コンピュータおよびインターネット自体を、電子トランザクションに対するかなりのセキュリティ上のリスクを与える本質的に信頼できないものと考える必要がある。
【課題を解決するための手段】
【０００８】
本発明の１つの局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたリモート・サーバのオペレーションを認可するための認可デバイスを提供する。このデバイスは、
データ通信ネットワークを介したリモート・サーバとの通信のためにデバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、
ユーザに情報を提供するためのユーザ・インタフェースと、
使用中の制御ロジックにアクセス可能なセキュリティ・データを用いて、デバイスとサーバとの間に、ローカル・ユーザ・コンピュータを介して、デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合され、
サーバへの異なる接続を介して要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバから前記接続を介して収集するように適合され、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供するように適合された、
制御ロジックとを含む。
【０００９】
よって、本発明を実施する認可デバイスは、そのコンピュータ・インタフェースを介してユーザ・コンピュータに接続可能であり、サーバとの安全な相互認証されたエンド・ツー・エンド接続を確立する。加えて、デバイス制御ロジックはこの接続によって、サーバから、デバイスのユーザによる認可を必要とする、サーバへの異なる接続を介して要求されたあらゆるオペレーションを示す情報を収集する。よって、ユーザによる認可を必要とするオペレーション要求に対する情報の取得は制御ロジックのアクションによって開始され、それに関する情報が受取られるオペレーション要求は、サーバへの１つまたはそれ以上の異なる接続によって提出されたものである。したがってこのデバイスは、安全な接続のセットアップの前または後のあらゆる時間にサーバに提出され、かつデバイスが現在接続されているコンピュータ、またはサーバに対するネットワーク接続をある期間確立していた１つもしくはそれ以上の他のコンピュータ、あるいはその両方であるあらゆるユーザ・コンピュータからのあらゆるユーザによって提出された、あらゆる数のオペレーション要求の詳細を収集できる。この態様で、本発明を実施する認可デバイスは、モバイル・コンピューティング環境における信頼されていないユーザ・コンピュータから要求されたサーバ・オペレーションの安全な認可のため、およびこうした環境における要求のマルチ・パーティ認可のための基礎を提供する。特に、サーバ・オペレーションは、異なるユーザが認可デバイスを介してサーバに接続して未処理のオペレーション要求の詳細を収集する際に、必要な認可が非同期的に得られるような、２人以上の認可ユーザによる認可に依存し得る。さらに、ユーザ・コンピュータとサーバとの間の、たとえば現在のブラウザ・セッションなどの、あらゆる他のセッションは、安全な接続における認可手順に影響されないままでいることができ、まったく正常に行われ得る。よって本発明を実施するデバイスは、モバイル・コンピューティング環境における安全でないシステムにおけるサーバ・オペレーションの安全なマルチ・パーティ認可のための、柔軟で効率的でユーザ・フレンドリなシステムを提供する。
【００１０】
サーバからオペレーション要求情報を収集するために、デバイス制御ロジックはサーバに何らかの形の要求を発行して情報を返すように促すが、一般的にこの要求は明示的であっても暗黙的であってもよい。たとえば、この要求は安全な接続を確立するプロセスにおける暗黙的なものであってもよく、サーバは、接続を確立するために用いられるセキュリティ・データに関連する認可ユーザに対して適切な何らかのオペレーション要求情報を送ることによって、接続の確立成功に応答してもよい。代替的には、制御ロジックは、デバイス・ユーザによる認可を必要とするオペレーション要求についての情報に対する明示的な要求を送ってもよい。よって制御ロジックは、たとえば接続の確立に応答して、安全な接続を介して情報の要求を送るように適合されてもよく、好ましくは安全な接続が持続している間、定期的にサーバからの情報を要求する。ここで重要な点は、サーバからのオペレーション要求情報の取得が認可デバイスによって開始されることであり、これによってデバイスは、モバイル環境においてサーバへの安全な接続を有するときに、いつでもどこでも情報を得ることができる。
【００１１】
制御ロジックは、好ましくは認可デバイスのローカル・ユーザ・コンピュータへの接続に応答して、サーバへの安全な接続の確立を開始する。ユーザ・インタフェースが、たとえばユーザのＰＩＮ（個人識別番号（ｐｅｒｓｏｎａｌ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ））の打鍵などのための入力機構を含むとき、このプロセスは何らかのユーザ入力を必要としてもしなくてもよい。いずれの場合にも、安全な接続のセットアップは、相互認証プロセスに用いることのできる何らかの形のセキュリティ・データへのアクセスを有する制御ロジックに依存している。セキュリティ・データは典型的に、サーバを運営するサービス・プロバイダによって供給される秘密鍵を含むが、一般的には、安全な接続を確立するための認可デバイスとサーバとの相互認証を可能にするチャレンジ応答プロトコルのための、たとえばワン・タイム・パスワードまたはその他の相互に既知の秘密などの、あらゆるデータを含んでいてもよい。セキュリティ・データは、たとえばデバイスに埋込まれた改ざんできないチップの中など、認可デバイスのメモリに保存されていてもよい。代替的には、セキュリティ・データは、認可デバイスがインタフェースしてセキュリティ・データへの制御ロジックのアクセスを与えることのできる別のセキュリティ・デバイスに保存されていてもよい。ここでのセキュリティ・デバイスに対する好ましい形の要素は、スマート・カードである。
【００１２】
認可デバイス自体がさまざまな形を取ってもよい。たとえば、デバイスが、認可ユーザの有するスマート・カードなどのセキュリティ・デバイスとインタフェースするように適合されているとき、そのデバイスは便利には、カード読取装置またはその他のセキュリティ・デバイス・インタフェースを組込んだ小さな可搬型デスクトップ・デバイスである。こうしたデバイスは、認可の目的専用のものであってもよいし、たとえばマウスなどの付加的な機能を提供する何らかの他のデバイスと一体化されていてもよい。セキュリティ・データが認可デバイス自体に保存されているとき、そのデバイスは理想的にはユーザによって容易に持ち運ぶことのできる小さな可搬型デバイスであり、これも認可の目的専用のものであってもよいし、組合わされた機能を有してもよい。例として、このデバイスは、メモリ・スティックまたはＭＰ３プレーヤなどの個人用音楽プレーヤにおいて実施されてもよい。いずれの場合にも、悪意あるソフトウェアによる妨害を防ぐための保護機構を組込む必要をなくすために、このデバイスは汎用の計算機能を組込んでいないことが好ましい。つまり、デバイス・プロセッサに任意コードをロードできないようにこのデバイスを構成することが好ましい。
【００１３】
ユーザ・インタフェースは、理想的にはユーザに対してオペレーション要求情報を表示するためのディスプレイを含み、それは認可デバイス内の介在処理を伴っても伴わなくてもよい。しかし、以下に考察されるような代替案も想定できる。好ましい実施形態において、ユーザ・インタフェースは、デバイスに対するユーザ認可の入力のための入力機構も含み、制御ロジックは相互認証された接続を介してサーバにユーザ認可を伝達するように適合される。しかし、ここでも以下に記載されるような代替案も想定できる。ユーザ・インタフェースが入力機構を含むとき、それは理想的には、たとえばユーザＰＩＮなどの何らかのユーザ・セキュリティ情報の入力を可能にすることによって、認可されたユーザが認可手順のためにデバイスを「アンロック」することを可能にする。
【００１４】
本発明の第２の局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたサーバのオペレーションを制御するための装置を提供する。この装置は、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリと、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、そのオペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかをルール・データから判定し、もしそうであればそのオペレーションを延期するように適合され、
本発明の第１の局面に従う認可デバイスと通信して前記相互認証された接続を確立するように適合され、
ユーザ・コンピュータから要求され認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して認可デバイスに供給し、かつユーザから認可を受取るように適合され、
そのオペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションの実行を開始するように適合された、
制御ロジックとを含む。
【００１５】
本発明のこの局面の実施形態において、制御ロジックは、前記相互認証された接続を介した認可デバイスからの要求に応答して、認可要求情報を送ることができる。先に考察したとおり、こうした要求は明示的であっても暗黙的であってもよく、さらにこの装置によって継続的な要求として処理されてもよく、それによって、予め定められた時間間隔内に受取られた、デバイス・ユーザによる認可を必要とするあらゆるさらなるオペレーション要求は、安全な接続を介して認可デバイスに送られる。
【００１６】
本発明の第３の局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するためのサーバを提供する。このサーバは、
データ通信ネットワークを介してユーザ・コンピュータと通信するための通信回路と、ユーザ・コンピュータからの要求に応答して前記オペレーションを実行するためのサーバ・ロジックと、サーバ・ロジックによる前記オペレーションの実行を制御するための、本発明の第２の局面に従う装置とを含む。
【００１７】
本発明の第４の局面はデータ通信システムを提供し、このデータ通信システムは、本発明の第３の局面に従うサーバと、データ通信ネットワークを介してサーバと通信するための少なくとも１つのユーザ・コンピュータと、本発明の第１の局面に従う少なくとも１つの認可デバイスであって、デバイスの前記コンピュータ・インタフェースを介してユーザ・コンピュータに接続するための、認可デバイスとを含み、ユーザ・コンピュータは、前記相互認証された接続を介して認可デバイスとサーバとの間の通信を中継するように適合される。
【００１８】
本発明の第５の局面はコンピュータ・プログラムを提供し、このコンピュータ・プログラムは、データ通信ネットワークを介したリモート・サーバとの通信のためにユーザ・コンピュータに接続するために適合された、認可デバイスのユーザに情報を提供するためのユーザ・インタフェースを有するデバイスのプロセッサに、
認可デバイスに関連するセキュリティ・データを用いて、ローカル・ユーザ・コンピュータを介して、サーバとの暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立させ、
サーバへの異なる接続を介して要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバから前記接続を介して収集させ、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供させるためのプログラム・コード手段を含む。
【００１９】
本発明の第６の局面はコンピュータ・プログラムを提供し、このコンピュータ・プログラムは、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するために適合された、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリを有するサーバに、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、そのオペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかをルール・データから判定させ、もしそうであればそのオペレーションを延期させ、
本発明の第１の局面に従う認可デバイスと通信して前記相互認証された接続を確立させ、認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して認可デバイスに供給させ、かつユーザからの認可を受取らせ、
そのオペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションを実行させるためのプログラム・コード手段を含む。
【００２０】
本発明を実施するコンピュータ・プログラムは、独立したプログラムを構成するか、またはより大きなプログラムの構成要素であってもよく、たとえばディスクなどのコンピュータ読取可能媒体またはコンピュータ内でロードするための電子伝送などに包含されて供給されてもよい。コンピュータ・プログラムのプログラム・コード手段は、直接、または（ａ）別の言語、コードもしくは表記法への変換および（ｂ）異なる材料形への再生の一方もしくは両方の後に、コンピュータに問題の方法を実行させることが意図される命令のセットの、あらゆる言語、コードまたは表記法のあらゆる表現式を含んでもよい。
【００２１】
一般的に、本明細書においては本発明の１つの局面の実施形態を参照して特徴を説明しているが、本発明の別の局面の実施形態に、対応する特徴が与えられてもよい。
【００２２】
添付の図面を参照して、本発明の好ましい実施形態を例として説明する。
【図面の簡単な説明】
【００２３】
【図１】本発明を実施するデータ通信システムを概略的に表す図である。
【図２】図１のシステムの認証デバイス、ユーザＰＣおよびサーバをより詳細に示す図である。
【図３】ユーザＰＣからのオペレーション要求を受取ったサーバによって実行されるステップを示す図である。
【図４】図２の認証デバイスのオペレーションにおける主要なステップを示す図である。
【図５】図２の認証デバイスからのトランザクション情報の要求を受取ったサーバのオペレーションを示す図である。
【発明を実施するための形態】
【００２４】
図１は、モバイル・コンピューティング・シナリオにおける安全なマルチ・パーティ・トランザクション認可システムを実現するための、本発明を実施するデータ通信システムを示す。システム１はサーバ２を含み、サーバ２は図中にネットワーク４として一般的に表される１つまたはそれ以上のデータ通信ネットワークを介して、複数のユーザ・コンピュータ３と通信できる。ここでは、記載される機能を行うように構成された汎用コンピュータによってサーバ２が実現されると仮定するが、一般的にサーバ２の機能がサーバ・システムの複数の物理的機械に分散されてもよい。ユーザ・コンピュータ３は、ネットワーク４を介してサーバ２とのデータ通信が可能なさまざまなコンピューティング・デバイス、たとえばＰＣ、ＰＤＡ（携帯用情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔｓ））、携帯電話などによって実現されてもよい。本例の目的のために、サーバ２は、コンピュータ３を動作するユーザが定期的に接続して銀行取引を行うことのできるオンライン銀行サービスへのアクセスを与えるものと仮定する。サーバ２によるトランザクションの実現は、マルチ・パーティ認可プロセスを受ける。特に、ユーザ・コンピュータ３から要求され得る少なくともいくつかのトランザクションは、サーバ２によって実現される前に１人またはそれ以上の認可ユーザによって認可される必要がある。トランザクションを認可するために、認可ユーザはユーザ・コンピュータ３に接続可能な専用のモバイル・トランザクション認可デバイス（ｔｒａｎｓａｃｔｉｏｎ ａｕｔｈｏｒｉｚａｔｉｏｎ ｄｅｖｉｃｅ）（ＴＡＤ）５を使用し、図１にはこうしたデバイスが３つ示されている。
【００２５】
図２はＴＡＤ５、ユーザＰＣ３およびサーバ２の概略ブロック図であり、認可システムに含まれる主要な構成要素を示している。本例のＴＡＤ５は小型のデスクトップ・デバイスであって、デバイスをユーザ・コンピュータ３に接続するための、ここではＵＳＢインタフェース６であるコンピュータ・インタフェースと、ディスプレイ７およびユーザ入力のためのキーパッド８を含むユーザ・インタフェースとを有する。ＴＡＤ５は、スマート・カード１０とインタフェースするためのカード読取装置９の形のセキュリティ・デバイス・インタフェースも有する。制御ロジック１１はデバイスのオペレーションを全体的に制御し、以下に説明される認可プロセスのさまざまなステップを実現する。サーバ２は、データ通信ネットワーク（単数または複数）４とインタフェースするための通常の通信回路１３と、オンライン銀行サービスのさまざまな機能を実行するためのサーバ・ロジック１４とを含む。加えてサーバ２は、認可制御ロジック１５を含む認可装置と、オペレーションにおいて認可ロジック１５によって使用されるさまざまなデータを含有するメモリ１６とを含む。メモリは、以下に説明される目的を有する延期トランザクション・ログ１７と、ルール・データベース１８とを含む。ルール・データベース１８は、１人またはそれ以上の認可ユーザによる認可を必要とするトランザクションを規定する。特に、データベース１８に保存されるルール・データはトランザクションを示し、各トランザクションに対して、そのトランザクションに必要な認可を出す各認可ユーザの識別を示す。データベース１８中のルール構造は、特定のアプリケーションに依存して、簡単なルール・セットから複雑なデータ構造までの範囲に及んでもよい。一般的に、ＴＡＤ５中の制御ロジック１１およびサーバ２中のロジック１４、１５は、ハードウェア、ソフトウェアまたはその組合わせにおいて実現されてもよいが、我々はここでは、このロジックがサーバ・コンピュータ２またはＴＡＤ５のプロセッサ上を適宜走るソフトウェアによって実現されるものと仮定する。本明細書の記載から、当業者には好適なソフトウェアが明らかになるだろう。ＴＡＤ５の制御ロジック１１を実現するプロセッサは、このプロセッサに付加的な任意のコードをロードできないように設計される。
【００２６】
サーバ２は、ネットワーク４を介して、図面中に破線で示されるユーザＰＣ３への第１の接続を有することが示される。たとえば、ユーザＰＣは典型的に、ＰＣ３上を走るウェブ・ブラウザを介して、サーバ２へのインターネット接続を有する。ユーザＰＣ３は、ＴＡＤ５に対してさらに以下に考察されるように働くプロキシ・アプリケーション１９も走らせていることが示される。一般的にプロキシ１９はＰＣ３に予めインストールされていてもよいが、この好ましい実施形態において、プロキシは、たとえば自身をＵＳＢ大容量記憶装置として登録しているＴＡＤなどによって、ＴＡＤからロードされてもよい。
【００２７】
スマート・カード１０は、サーバ２を運営する銀行によって認可ユーザに発行される。カード１０は、ＴＡＤ５とサーバ２との間で行われる認証プロセスにおいて用いるためのセキュリティ・データを含有する。本例において、セキュリティ・データは秘密の暗号鍵であるが、スマート・カードは便宜に応じて、ユーザ・アカウント情報および証明書、たとえばサービス・プロバイダＵＲＬ、信頼されるＴＬＳ／ＳＳＬ（トランスポート層セキュリティ／セキュア・ソケット・レイヤ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ／Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）（商標））証明書、ユーザ名、ＰＩＮなど、および場合によってはサーバ２との通信において用いるための付加的な暗号鍵によっても個人化される。
【００２８】
システム１のオペレーションにおいて、銀行の顧客はあらゆる（信頼されていない）コンピュータ３からサーバ２に接続して、オンライン銀行ポータルにログインし、資金振替またはその他の銀行取引などのオペレーションを実行するようサーバに要求できる。こうしたトランザクション要求に応答したサーバ２のオペレーションが、図３の流れ図に示される。このプロセスは、ステップ２０に示されるトランザクション要求の受取りによって開始される。サーバ２が受取るすべてのトランザクション要求は、サーバ・ロジック１４によって認可ロジック１５に渡される。ステップ２１において、認可ロジックがルール・データベース１８にアクセスして、そのトランザクションに対する認可が必要かどうかをチェックする。判定ステップ２２において「Ｎｏ」（Ｎ）と示されるとおり、認可が必要でなければ、そのトランザクション要求はサーバ・ロジック１４に戻され、サーバ・ロジック１４はステップ２３において指示されたトランザクションを単純に実行して、プロセスが完了する。しかし、判定ステップ２２において「Ｙｅｓ」（Ｙ）と示されるとおり、トランザクションに対する認可が必要であれば、ステップ２４において認可ロジック１５は延期トランザクション・ログ１７にエントリを作成する。このエントリは、トランザクションの詳細に加えて、そのトランザクションに必要な認可を出すすべての認可ユーザの識別を記録する。よって、必要とされる認可（単数または複数）を受取るまでトランザクションは延期され、プロセスは終了する。
【００２９】
異なる信頼されないユーザ・コンピュータ３から、さまざまな時間に複数のユーザがトランザクションを指示し得る。前述のとおり、すべてのトランザクション要求がサーバ２によって対処されることによって、延期トランザクション・ログはいつでも認可を待つ複数のトランザクションの詳細を含み得る。ルール・データベース１８において識別される各認可ユーザは、上述のとおりスマート・カード１０を有する。認可ユーザはＴＡＤ５も有していてもよいし、ある場所にコンピュータ３とともに用いるためにＴＡＤ５が設けられてもよいし、あるいはその両方であってもよい。いずれの場合にも、ＴＡＤ５を有する認可ユーザがネットワーク接続されたコンピュータ３にアクセスするとき、ユーザは以下のとおりに認可手順を行い得る。ユーザはＴＡＤ５にスマート・カード１０を挿入し、ＵＳＢインタフェース６を介してＴＡＤをユーザＰＣ３に接続する。ＴＡＤ５のその後のオペレーションは制御ロジック１１によって制御され、図４の流れ図に示される。ステップ３０に示されるとおり、ＴＡＤ５のＰＣ３への接続に応答して、制御ロジック１１はサーバ２に接続するプロセスを開始する。まず、ステップ３１において、制御ロジックはディスプレイ７上のメッセージによって、ユーザに自身のＰＩＮをキーパッド８に入力するように促し、入力された番号はスマート・カード１０に保存された番号に対してチェックされる。デバイスはユーザに正しいＰＩＮを入力する機会を何度か与えてもよいが、有効ＰＩＮが入力されないとき（判定３２におけるＮ）、このプロセスは終了する。しかし、ＰＩＮが有効であると仮定するとき（判定３２におけるＹ）、ステップ３３において、制御ロジックはＰＣ３におけるプロキシ・アプリケーション１９を開始する。次にステップ３４に示されるとおり、制御ロジックはプロキシ１９の助けによって、ＴＡＤ５とサーバ２との間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立する。この接続は図２において実線で示される。この接続を確立するために、制御ロジックはカード読取装置９を介してスマート・カード１０と通信し、カード１０に保存されたセキュリティ・データにアクセスする。ＴＡＤとサーバとの相互認証を可能にするメッセージの暗号化／解読のために、予め同意された秘密鍵が用いられ、公知の態様でプロトコル・セットアップを実現することによって、サーバ２とのＴＬＳ／ＳＳＬ接続が確立される。このＴＬＳ／ＳＳＬ接続は、ＴＡＤ５と、（スマート・カード１０上の安全なデータを介した）そのＴＡＤの構成が目的とするサービス・プロバイダの信頼されるサーバ２との間のエンド・ツー・エンド接続であるが、プロキシはその２者間でネットワーク・パケットを盲目的に中継する。その結果、プロキシ１９およびＰＣ３を通過するすべてのデータが暗号化されるため、プロキシ１９およびＰＣ３は信頼できないものとなり得る。
【００３０】
安全な接続を確立した後、図４のステップ３５において、制御ロジック１１はサーバ２に、ＴＡＤのユーザによる認可まで延期されているあらゆるトランザクションの情報に対する要求を送る。安全な接続のセットアップにおいてすでに供給されていなければ、この要求にはカード１０から検索されたユーザＩＤデータが含まれていてもよい。サーバが、未処理の関連トランザクションはないと応答するとき（判定ステップ３６におけるＮ）、制御ロジックは遅延ブロック３７に表される予め定められた時間間隔だけ待つ。次いでプロセスはステップ３５に戻り、これによって安全な接続が持続する間、トランザクション情報に対する要求が定期的に繰り返される。判定ステップ３６に戻って、サーバ２によってトランザクション詳細が返されれば、ステップ３８において制御ロジックは認可されるべき第１のトランザクションの詳細をディスプレイ７に表示する。このディスプレイはユーザに、キーパッド８への入力によってそのトランザクションを承認または拒否するよう促すこともする。判定ステップ３９においてその結果が検出され、ユーザによるトランザクションの拒否（ステップ４０）または認可（ステップ４１）が、安全な接続を介してサーバ２に送り返される。判定ステップ４２において、制御ロジック１１は表示すべき別のトランザクションがあるかどうかを判定し、もしあれば、次のトランザクションのためにオペレーションはステップ３８に戻る。もしなければ、オペレーションは遅延ステップ３７に戻って、トランザクション情報の次の要求を待つ。
【００３１】
ＴＡＤがその安全な接続を介してサーバ２に接続している間、前述のプロセスが続く。このやり方で、ＴＡＤ５は安全な接続を介して、ＴＡＤのユーザによる認可を必要とし、かつユーザ・コンピュータ３とサーバ２との間の他の接続のいずれかを介してあらゆるユーザから要求されている延期トランザクションの詳細を収集し、その要求はＴＡＤ５の接続の前または後であってもよい。延期トランザクションは、サーバ２とのブラウザ・セッションを介して現在のＴＡＤユーザによって要求されたトランザクションを含んでもよく、このブラウザ・セッションはまったく正常に行われ、ＴＡＤの存在に影響を受けることがない。よってトランザクションは、いつでもどこからでもユーザがサーバに接続するときにユーザによって認可されることができ、トランザクション詳細は信頼されないコンピュータ３および信頼されないネットワーク４の媒介を介して、安全に伝達されて安全に認可される。
【００３２】
ＴＡＤ５からの延期トランザクション情報の要求に応答したサーバ２のオペレーションが、図５に示される。こうした要求はすべてサーバ２の認可ロジック１５に送られる。ステップ５０は認可ロジック１５による要求の受取りを表しており、次いで認可ロジック１５はステップ５１において、要求しているＴＡＤのユーザによる認可を必要とするあらゆるトランザクションについて、延期トランザクション・ログをチェックする。関連トランザクションが見出されないとき（判定５２におけるＮ）、ステップ５３においてそのことがＴＡＤに報告されて、プロセスは終了する。ログに何らかの関連トランザクションが見出されたとき（判定５２におけるＹ）、そのトランザクション詳細が安全な接続を介してＴＡＤに送られ、次いでロジック１５は遅延５５に示されるとおりに認可を待つ。認可応答が受取られないとき（判定５６におけるＮ）、ロジック１５はステップ５７において、応答に対する「タイムアウト」限界に達したかどうかを判定し、もしそうであればプロセスは終了する。限界に達していなければ、オペレーションは遅延５５に戻ってさらなる時間間隔だけ待つ。認可応答を受取ったとき（判定５６におけるＹ）、認可ロジックはステップ５８において、そのトランザクションが承認された（Ｙ）か拒否された（Ｎ）かを識別する。もし拒否されれば、ステップ５９および６０において認可ロジックはそのトランザクションを延期トランザクション・ログ１７から削除し、拒否されたことをサーバ・ロジック１４に通知する。次いでサーバ・ロジック１４は、たとえば要求しているユーザにトランザクション認可が拒否されたことを通知するなどの適切なアクションを取ることができる。次いでオペレーションはステップ６１に進み、ここでロジック１５は、認可を待つさらなるトランザクションがあるかどうかを判定する。もしなければプロセスは終了するが、もしさらなるトランザクションがあれば、オペレーションはステップ５５に戻ってさらなる認可を待つ。ステップ５８に戻って、ここでトランザクションが認可されるとき、次いでロジック１５は判定６３において、そのトランザクションに対する他のユーザの認可がなおも必要とされるかどうかをトランザクション・ログから判定する。もしそうであれば、ステップ６４においてログを単純に更新することによって現在のユーザの認可を示し、オペレーションは前と同様にステップ６１に進む。しかし、もし他のユーザの認可が必要でなければ、ステップ６５において認可ロジックはサーバ・ロジック１４にトランザクションを実行するよう指示する。次いで、ステップ６４において延期トランザクション・ログからそのトランザクションが削除され、オペレーションは認可を必要とする次のトランザクションのためにステップ６１に進む。現在のＴＡＤユーザによってすべてのトランザクションが認可（もしくは拒否）されるか、または認可に対するタイムアウト限界に達したとき、このプロセスは完了したとみなされる。
【００３３】
前述のプロセスは、モバイル・ユーザが通信システム内のあらゆるユーザ・コンピュータを介して接続するときにはいつでも、サーバがモバイル・ユーザからのトランザクション認可を受取ることを可能にする。ルール・データベース１８に規定されるとおり、すべての必要とされるパーティから必要な認可を受取ったときにのみ、サーバによってトランザクションが実現される。データベース１８中のルールは、たとえば企業内の組織的責任を反映するための、任意の複雑なマルチ・パーティ認証要求を実現でき、サーバはどのトランザクションがどのユーザによって明示的に認可される必要があるかを判定する。たとえば、ユーザ１が１０００ＵＳＤの価値のあるトランザクションを開始したと仮定するとき、データベースは、トランザクションが５００ＵＳＤよりも大きい価値を持つときには、ユーザ１に加えてユーザＮからも安全なトランザクション認可を必要とすることを指定したルールを含んでいてもよい。この場合、サーバは接続されたときに両方のユーザのＴＡＤに未処理のトランザクションを示し、両方のユーザがそのトランザクションを認可したときのみ、それはサーバによる処理に成功する。中間者（ＭＩＴＭ）または悪意あるソフトウェアがユーザによるトランザクション開始プロセスを攻撃しても、その後のマルチ・パーティ・トランザクション認証プロセスは、たとえＴＡＤが信頼できないコンピュータ上で動作されていても、こうした攻撃に対して安全である。ユーザはＴＡＤに表示された情報を信頼することができ、サービス・プロバイダの信頼されるサーバにユーザの認可決定を安全に通信して返すことができる。よってＴＡＤを介したトランザクション認可は、中間者（ＭＩＴＭ）および悪意あるソフトウェアの攻撃から電子トランザクションを保護し、複雑なマルチ・パーティ認可ルールを支持する一方で、ユーザの移動性を維持する。このやり方で、モバイル・コンピューティング環境において安全なマルチ・パーティ・トランザクション認可を効率的に実現できる。
【００３４】
上に好ましい実施形態を記載したが、さまざまな追加および代替形を想定できる。たとえば、コンピュータ３のユーザがトランザクションを開始するために、たとえばウェブ・ブラウザなどを介してサービス・プロバイダのポータルに最初にログインするときの、ユーザ認証の際にもＴＡＤ５が伴われてもよい。ユーザがポータルへのアクセスを要求するとき、サーバ２は安全な接続を介して何らかの認証コードを返してもよく、その認証コードは未処理トランザクションと同様にユーザのＴＡＤによって表示されてもよい。次いでユーザはこのコードを用いて、コンピュータ３のキーボードで、またはＴＡＤのキーパッドを介してそのコードを入力することによって、ポータルと認証を行い得る。一般的にＴＡＤを使用する際に、ユーザの判定は安全なＴＬＳ／ＳＳＬチャネルを介してサーバに返されることが好ましいが、ＴＡＤはトランザクション詳細とともにサーバによって生成された何らかのトランザクション／ユーザに特定的な認可コードを表示してもよい。次いでユーザはこのコードをディスプレイからコピーして、たとえばウェブ・ブラウザなどの、何か他のおそらくは信頼できない接続を介してサーバに送ってもよい。これは、ユーザによってウェブ・フォームに入力されるべき、通常はスクラッチ・リストまたはＳＭＳテキストを介して帯域外配信されるワン・タイム・コードを必要とする既存のウェブ・ポータルとの適合性を提供する。
【００３５】
オンライン銀行サービスの状況におけるオペレーションを説明したが、このシステムは、あらゆるタイプのリソースへのアクセスの認可を含む、多くのタイプのサーバ・オペレーションの認可のために適用できる。たとえば、マルチ・パーティ・トランザクション認可に対するのと同じやり方で、マルチ・パーティ・アクセス制御認可のためにＴＡＤを用いることができる。ここで、ユーザがサービス・プロバイダのポータルにログインしようと試みるとき、前の例におけるトランザクションに対するものと同様に、サーバは１人またはそれ以上の人物から彼らのＴＡＤを介して承認を要求できる。
【００３６】
ＴＡＤはさまざまな形を取ることができ、前述のとおり、その目的専用のものであってもよいし、たとえばマウスまたはＭＰ３プレーヤなどの、限定された付加的な機能を提供する何らかの他のデバイスと一体化されていてもよい。ユーザ・インタフェースはさまざまな態様で実現されてもよく、ユーザに音響プロンプトを与えるか、または異なる態様で視覚的情報を提供するか、あるいはその両方を行ってもよく、たとえばマウス・レーザ機構を利用してデスクトップに投影表示を生成してもよい。ＴＡＤコンピュータおよびセキュリティ・デバイス・インタフェースは一般的に、有線または無線接続のあらゆる便利な形を実現し得る。実際に、安全な接続を確立するためのセキュリティ・データは、ＴＡＤ内に物理的に埋込まれたメモリ中に保存されてもよく、たとえば自己破壊するデータ・コンテナまたは侵入検知センサなどを用いた、改ざんから物理的に保護された安全なチップの中などに保存されてもよい。
【００３７】
サーバ２の機能はサーバ・システムの異なる機械の上に分散されてもよく、メモリ１６は２つ以上の機械の上に分散した１つまたはそれ以上の異なるメモリ構成要素によって実現されてもよい。
【００３８】
本発明の範囲から逸脱することなく、記載された例示的な実施形態に対して多くのその他の変更および修正が行われ得ることが認められるだろう。
【技術分野】
【０００１】
本発明は一般的に、データ通信ネットワーク上のユーザ・コンピュータから要求されたサーバ・オペレーションの認可に関する。リモート・サーバ・オペレーションを認可し、こうした認可に依存してサーバによるオペレーションの実行を制御するための装置、システムおよびコンピュータ・プログラムが提供される。
【背景技術】
【０００２】
コンピュータのユーザが、サーバによる何らかのオペレーションの実行を要求するために、データ通信ネットワークを介してリモート・サーバと通信するためのシナリオは多数存在する。こうしたサーバは典型的に、リモート・ユーザによるオンライン・アクセスのためのサービスのプロバイダによって動作される。しかし本明細書において、「サーバ」という用語は最も一般的な意味で用いられ、接続するユーザに何らかのサービスまたは機能を提供するあらゆるコンピュータまたはシステムを含む。ユーザの要求によってサーバが実行するオペレーションは、たとえばデータベースまたは制限されたウェブ・サイトなど、何らかのリソースへのユーザのアクセスを単に認めることであってもよいし、ユーザによって指示される、たとえば銀行取引など何らかのトランザクションの実現であってもよい。いずれの場合においても、通信インフラストラクチャは、セキュリティ、特にサーバ・オペレーションが正しく認可されたユーザに対してのみ実行されることを確実にすることがしばしば重要な問題となるという性質をもつ。たとえばインターネット上で行われる電子ビジネスの場合、オンライン詐欺は絶えず増加を続ける脅威である。悪名高い中間者（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ：ＭＩＴＭ）などの高度な攻撃、およびたとえばウイルスまたはトロイの木馬などのさまざまなタイプの悪意あるソフトウェアは増加して広まっており、一方でアンチウイルス・ソフトウェアおよびファイアウォールなどの対抗策は、いつも攻撃者に一歩後れを取っているようにみえる。その結果、パーソナル・コンピュータ（ｐｅｒｓｏｎａｌ ｃｏｍｐｕｔｅｒｓ：ＰＣｓ）などのユーザ・コンピュータおよびインターネット自体を、電子トランザクションに対するかなりのセキュリティ上のリスクを与える本質的に信頼できないものと考える必要がある。たとえば、ユーザが自身のＰＣからオンライン・サービス・プロバイダのポータルに接続してトランザクションを開始するとき、そのトランザクションが何らかの悪意あるソフトウェアまたはＭＩＴＭによって密かに操作されていないことをユーザは確信できない。サービス・プロバイダも、自身が正しく認可されたユーザと通信していることを確信できないという同様の困難に面する。
【０００３】
上記シナリオにおけるセキュリティの問題のいくつかに対処するために、さまざまなシステムが提案されてきた。たとえば、特許文献１は、ユーザＰＣに接続可能であって、スマート・カードのための読取装置を組込んだセキュリティ・デバイスを開示している。ユーザが自身のＰＣを介してリモート・サーバからのリソースを要求するとき、サーバはユーザの公開鍵を検索し、トランザクション情報をチャレンジとともに含む暗号化したデータ・ブロブを送り返すことによって応答する。ユーザＰＣから要求されたリソースがセキュリティ・デバイス上に表示され、ユーザはセキュリティ・デバイスへの入力によってこのリソースを要求したか否かを確認でき、この入力はサーバに送り返される。このデバイスは、所与のＰＣのユーザが、そのＰＣから一度に１つ発行されるリソース要求の同時確認を与えることを可能にする。しかし、このシステムは「偽チャレンジ（ｆａｌｓｅ−ｃｈａｌｌｅｎｇｅ）」攻撃を受けやすい。つまり、たとえばユーザを混乱させて応答させるために、何らかの悪意あるパーティがユーザの公開鍵のもとで暗号化チャレンジを生成して、それをユーザＰＣに送ることがあり得る。さらに、誰でもユーザの公開鍵によってチャレンジに対するユーザの応答メッセージを解読することができる。したがってこのシステムの有用性は限定されており、それ自体のセキュリティおよびプライバシーの問題を生じる。
【０００４】
２００７年１１月１９日に出願された我々の同時係属中の特許文献２は、ユーザ・コンピュータへの接続のための別のデバイスを開示している。このデバイスは、非特許文献１にも記載されている。このデバイスは、特定の銀行ＵＲＬ（ユニバーサル・リソース・ロケータ（ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏｒ））に接続するためのブラウザによって接触されるユーザＰＣ上のプロキシ・アプリケーションに促されるときに、サーバとの安全な相互認証されたエンド・ツー・エンド接続をセットアップする。次いで、安全な接続を介して次のブラウザ・セッションが行われ、セキュリティ・デバイスによってモニタされる。デバイスが銀行取引の詳細などの機密情報を検出すると、それがデバイス上に表示され、ユーザはボタンを押して自身の確認を示すことができる。セキュリティ・デバイスはこの確認を受取ったときのみ、接続を維持してサーバにトランザクション要求を転送する。このデバイスも、所与のＰＣのユーザが、そのＰＣから一度に１つ発行される要求の同時確認を与えることを可能にするが、この場合には、いつユーザ認可が必要かを判断するセキュリティ・デバイスの制御下にある安全な接続を介してすべてのサーバ・セッションが行われる。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許第６，８９５，５０２号
【特許文献２】欧州特許出願第０７０２２４１９．１号
【非特許文献】
【０００６】
【非特許文献１】“Ｔｈｅ Ｚｕｒｉｃｈ Ｔｒｕｓｔｅｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｈａｎｎｅｌ−Ａｎ Ｅｆｆｉｃｉｅｎｔ Ｄｅｆｅｎｃｅ ａｇａｉｎｓｔ Ｍａｎ−ｉｎ−ｔｈｅ−Ｍｉｄｄｌｅ ａｎｄ Ｍａｌｉｃｉｏｕｓ Ｓｏｆｔｗａｒｅ Ａｔｔａｃｋｓ”，Ｔｈｏｍａｓ Ｗｅｉｇｏｌｄ ｅｔ ａｌ．，ｉｎ Ｐ．Ｌｉｐｐ，Ａ．−Ｒ．Ｓａｄｅｇｈｉ，ａｎｄ Ｋ．−Ｍ．Ｋｏｃｈ（Ｅｄｓ．）：ＴＲＵＳＴ ２００８，ＬＮＣＳ ４９６８，ｐｐ．７５−９１，Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ Ｂｅｒｌｉｎ Ｈｅｉｄｅｌｂｅｒｇ ２００８
【発明の概要】
【発明が解決しようとする課題】
【０００７】
パーソナル・コンピュータ（ＰＣ）などのユーザ・コンピュータおよびインターネット自体を、電子トランザクションに対するかなりのセキュリティ上のリスクを与える本質的に信頼できないものと考える必要がある。
【課題を解決するための手段】
【０００８】
本発明の１つの局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたリモート・サーバのオペレーションを認可するための認可デバイスを提供する。このデバイスは、
データ通信ネットワークを介したリモート・サーバとの通信のためにデバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、
ユーザに情報を提供するためのユーザ・インタフェースと、
使用中の制御ロジックにアクセス可能なセキュリティ・データを用いて、デバイスとサーバとの間に、ローカル・ユーザ・コンピュータを介して、デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合され、
サーバへの異なる接続を介して要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバから前記接続を介して収集するように適合され、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供するように適合された、
制御ロジックとを含む。
【０００９】
よって、本発明を実施する認可デバイスは、そのコンピュータ・インタフェースを介してユーザ・コンピュータに接続可能であり、サーバとの安全な相互認証されたエンド・ツー・エンド接続を確立する。加えて、デバイス制御ロジックはこの接続によって、サーバから、デバイスのユーザによる認可を必要とする、サーバへの異なる接続を介して要求されたあらゆるオペレーションを示す情報を収集する。よって、ユーザによる認可を必要とするオペレーション要求に対する情報の取得は制御ロジックのアクションによって開始され、それに関する情報が受取られるオペレーション要求は、サーバへの１つまたはそれ以上の異なる接続によって提出されたものである。したがってこのデバイスは、安全な接続のセットアップの前または後のあらゆる時間にサーバに提出され、かつデバイスが現在接続されているコンピュータ、またはサーバに対するネットワーク接続をある期間確立していた１つもしくはそれ以上の他のコンピュータ、あるいはその両方であるあらゆるユーザ・コンピュータからのあらゆるユーザによって提出された、あらゆる数のオペレーション要求の詳細を収集できる。この態様で、本発明を実施する認可デバイスは、モバイル・コンピューティング環境における信頼されていないユーザ・コンピュータから要求されたサーバ・オペレーションの安全な認可のため、およびこうした環境における要求のマルチ・パーティ認可のための基礎を提供する。特に、サーバ・オペレーションは、異なるユーザが認可デバイスを介してサーバに接続して未処理のオペレーション要求の詳細を収集する際に、必要な認可が非同期的に得られるような、２人以上の認可ユーザによる認可に依存し得る。さらに、ユーザ・コンピュータとサーバとの間の、たとえば現在のブラウザ・セッションなどの、あらゆる他のセッションは、安全な接続における認可手順に影響されないままでいることができ、まったく正常に行われ得る。よって本発明を実施するデバイスは、モバイル・コンピューティング環境における安全でないシステムにおけるサーバ・オペレーションの安全なマルチ・パーティ認可のための、柔軟で効率的でユーザ・フレンドリなシステムを提供する。
【００１０】
サーバからオペレーション要求情報を収集するために、デバイス制御ロジックはサーバに何らかの形の要求を発行して情報を返すように促すが、一般的にこの要求は明示的であっても暗黙的であってもよい。たとえば、この要求は安全な接続を確立するプロセスにおける暗黙的なものであってもよく、サーバは、接続を確立するために用いられるセキュリティ・データに関連する認可ユーザに対して適切な何らかのオペレーション要求情報を送ることによって、接続の確立成功に応答してもよい。代替的には、制御ロジックは、デバイス・ユーザによる認可を必要とするオペレーション要求についての情報に対する明示的な要求を送ってもよい。よって制御ロジックは、たとえば接続の確立に応答して、安全な接続を介して情報の要求を送るように適合されてもよく、好ましくは安全な接続が持続している間、定期的にサーバからの情報を要求する。ここで重要な点は、サーバからのオペレーション要求情報の取得が認可デバイスによって開始されることであり、これによってデバイスは、モバイル環境においてサーバへの安全な接続を有するときに、いつでもどこでも情報を得ることができる。
【００１１】
制御ロジックは、好ましくは認可デバイスのローカル・ユーザ・コンピュータへの接続に応答して、サーバへの安全な接続の確立を開始する。ユーザ・インタフェースが、たとえばユーザのＰＩＮ（個人識別番号（ｐｅｒｓｏｎａｌ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｎｕｍｂｅｒ））の打鍵などのための入力機構を含むとき、このプロセスは何らかのユーザ入力を必要としてもしなくてもよい。いずれの場合にも、安全な接続のセットアップは、相互認証プロセスに用いることのできる何らかの形のセキュリティ・データへのアクセスを有する制御ロジックに依存している。セキュリティ・データは典型的に、サーバを運営するサービス・プロバイダによって供給される秘密鍵を含むが、一般的には、安全な接続を確立するための認可デバイスとサーバとの相互認証を可能にするチャレンジ応答プロトコルのための、たとえばワン・タイム・パスワードまたはその他の相互に既知の秘密などの、あらゆるデータを含んでいてもよい。セキュリティ・データは、たとえばデバイスに埋込まれた改ざんできないチップの中など、認可デバイスのメモリに保存されていてもよい。代替的には、セキュリティ・データは、認可デバイスがインタフェースしてセキュリティ・データへの制御ロジックのアクセスを与えることのできる別のセキュリティ・デバイスに保存されていてもよい。ここでのセキュリティ・デバイスに対する好ましい形の要素は、スマート・カードである。
【００１２】
認可デバイス自体がさまざまな形を取ってもよい。たとえば、デバイスが、認可ユーザの有するスマート・カードなどのセキュリティ・デバイスとインタフェースするように適合されているとき、そのデバイスは便利には、カード読取装置またはその他のセキュリティ・デバイス・インタフェースを組込んだ小さな可搬型デスクトップ・デバイスである。こうしたデバイスは、認可の目的専用のものであってもよいし、たとえばマウスなどの付加的な機能を提供する何らかの他のデバイスと一体化されていてもよい。セキュリティ・データが認可デバイス自体に保存されているとき、そのデバイスは理想的にはユーザによって容易に持ち運ぶことのできる小さな可搬型デバイスであり、これも認可の目的専用のものであってもよいし、組合わされた機能を有してもよい。例として、このデバイスは、メモリ・スティックまたはＭＰ３プレーヤなどの個人用音楽プレーヤにおいて実施されてもよい。いずれの場合にも、悪意あるソフトウェアによる妨害を防ぐための保護機構を組込む必要をなくすために、このデバイスは汎用の計算機能を組込んでいないことが好ましい。つまり、デバイス・プロセッサに任意コードをロードできないようにこのデバイスを構成することが好ましい。
【００１３】
ユーザ・インタフェースは、理想的にはユーザに対してオペレーション要求情報を表示するためのディスプレイを含み、それは認可デバイス内の介在処理を伴っても伴わなくてもよい。しかし、以下に考察されるような代替案も想定できる。好ましい実施形態において、ユーザ・インタフェースは、デバイスに対するユーザ認可の入力のための入力機構も含み、制御ロジックは相互認証された接続を介してサーバにユーザ認可を伝達するように適合される。しかし、ここでも以下に記載されるような代替案も想定できる。ユーザ・インタフェースが入力機構を含むとき、それは理想的には、たとえばユーザＰＩＮなどの何らかのユーザ・セキュリティ情報の入力を可能にすることによって、認可されたユーザが認可手順のためにデバイスを「アンロック」することを可能にする。
【００１４】
本発明の第２の局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたサーバのオペレーションを制御するための装置を提供する。この装置は、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリと、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、そのオペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかをルール・データから判定し、もしそうであればそのオペレーションを延期するように適合され、
本発明の第１の局面に従う認可デバイスと通信して前記相互認証された接続を確立するように適合され、
ユーザ・コンピュータから要求され認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して認可デバイスに供給し、かつユーザから認可を受取るように適合され、
そのオペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションの実行を開始するように適合された、
制御ロジックとを含む。
【００１５】
本発明のこの局面の実施形態において、制御ロジックは、前記相互認証された接続を介した認可デバイスからの要求に応答して、認可要求情報を送ることができる。先に考察したとおり、こうした要求は明示的であっても暗黙的であってもよく、さらにこの装置によって継続的な要求として処理されてもよく、それによって、予め定められた時間間隔内に受取られた、デバイス・ユーザによる認可を必要とするあらゆるさらなるオペレーション要求は、安全な接続を介して認可デバイスに送られる。
【００１６】
本発明の第３の局面は、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するためのサーバを提供する。このサーバは、
データ通信ネットワークを介してユーザ・コンピュータと通信するための通信回路と、ユーザ・コンピュータからの要求に応答して前記オペレーションを実行するためのサーバ・ロジックと、サーバ・ロジックによる前記オペレーションの実行を制御するための、本発明の第２の局面に従う装置とを含む。
【００１７】
本発明の第４の局面はデータ通信システムを提供し、このデータ通信システムは、本発明の第３の局面に従うサーバと、データ通信ネットワークを介してサーバと通信するための少なくとも１つのユーザ・コンピュータと、本発明の第１の局面に従う少なくとも１つの認可デバイスであって、デバイスの前記コンピュータ・インタフェースを介してユーザ・コンピュータに接続するための、認可デバイスとを含み、ユーザ・コンピュータは、前記相互認証された接続を介して認可デバイスとサーバとの間の通信を中継するように適合される。
【００１８】
本発明の第５の局面はコンピュータ・プログラムを提供し、このコンピュータ・プログラムは、データ通信ネットワークを介したリモート・サーバとの通信のためにユーザ・コンピュータに接続するために適合された、認可デバイスのユーザに情報を提供するためのユーザ・インタフェースを有するデバイスのプロセッサに、
認可デバイスに関連するセキュリティ・データを用いて、ローカル・ユーザ・コンピュータを介して、サーバとの暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立させ、
サーバへの異なる接続を介して要求されデバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、サーバから前記接続を介して収集させ、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供させるためのプログラム・コード手段を含む。
【００１９】
本発明の第６の局面はコンピュータ・プログラムを提供し、このコンピュータ・プログラムは、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するために適合された、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリを有するサーバに、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、そのオペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかをルール・データから判定させ、もしそうであればそのオペレーションを延期させ、
本発明の第１の局面に従う認可デバイスと通信して前記相互認証された接続を確立させ、認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して認可デバイスに供給させ、かつユーザからの認可を受取らせ、
そのオペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションを実行させるためのプログラム・コード手段を含む。
【００２０】
本発明を実施するコンピュータ・プログラムは、独立したプログラムを構成するか、またはより大きなプログラムの構成要素であってもよく、たとえばディスクなどのコンピュータ読取可能媒体またはコンピュータ内でロードするための電子伝送などに包含されて供給されてもよい。コンピュータ・プログラムのプログラム・コード手段は、直接、または（ａ）別の言語、コードもしくは表記法への変換および（ｂ）異なる材料形への再生の一方もしくは両方の後に、コンピュータに問題の方法を実行させることが意図される命令のセットの、あらゆる言語、コードまたは表記法のあらゆる表現式を含んでもよい。
【００２１】
一般的に、本明細書においては本発明の１つの局面の実施形態を参照して特徴を説明しているが、本発明の別の局面の実施形態に、対応する特徴が与えられてもよい。
【００２２】
添付の図面を参照して、本発明の好ましい実施形態を例として説明する。
【図面の簡単な説明】
【００２３】
【図１】本発明を実施するデータ通信システムを概略的に表す図である。
【図２】図１のシステムの認証デバイス、ユーザＰＣおよびサーバをより詳細に示す図である。
【図３】ユーザＰＣからのオペレーション要求を受取ったサーバによって実行されるステップを示す図である。
【図４】図２の認証デバイスのオペレーションにおける主要なステップを示す図である。
【図５】図２の認証デバイスからのトランザクション情報の要求を受取ったサーバのオペレーションを示す図である。
【発明を実施するための形態】
【００２４】
図１は、モバイル・コンピューティング・シナリオにおける安全なマルチ・パーティ・トランザクション認可システムを実現するための、本発明を実施するデータ通信システムを示す。システム１はサーバ２を含み、サーバ２は図中にネットワーク４として一般的に表される１つまたはそれ以上のデータ通信ネットワークを介して、複数のユーザ・コンピュータ３と通信できる。ここでは、記載される機能を行うように構成された汎用コンピュータによってサーバ２が実現されると仮定するが、一般的にサーバ２の機能がサーバ・システムの複数の物理的機械に分散されてもよい。ユーザ・コンピュータ３は、ネットワーク４を介してサーバ２とのデータ通信が可能なさまざまなコンピューティング・デバイス、たとえばＰＣ、ＰＤＡ（携帯用情報端末（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔｓ））、携帯電話などによって実現されてもよい。本例の目的のために、サーバ２は、コンピュータ３を動作するユーザが定期的に接続して銀行取引を行うことのできるオンライン銀行サービスへのアクセスを与えるものと仮定する。サーバ２によるトランザクションの実現は、マルチ・パーティ認可プロセスを受ける。特に、ユーザ・コンピュータ３から要求され得る少なくともいくつかのトランザクションは、サーバ２によって実現される前に１人またはそれ以上の認可ユーザによって認可される必要がある。トランザクションを認可するために、認可ユーザはユーザ・コンピュータ３に接続可能な専用のモバイル・トランザクション認可デバイス（ｔｒａｎｓａｃｔｉｏｎ ａｕｔｈｏｒｉｚａｔｉｏｎ ｄｅｖｉｃｅ）（ＴＡＤ）５を使用し、図１にはこうしたデバイスが３つ示されている。
【００２５】
図２はＴＡＤ５、ユーザＰＣ３およびサーバ２の概略ブロック図であり、認可システムに含まれる主要な構成要素を示している。本例のＴＡＤ５は小型のデスクトップ・デバイスであって、デバイスをユーザ・コンピュータ３に接続するための、ここではＵＳＢインタフェース６であるコンピュータ・インタフェースと、ディスプレイ７およびユーザ入力のためのキーパッド８を含むユーザ・インタフェースとを有する。ＴＡＤ５は、スマート・カード１０とインタフェースするためのカード読取装置９の形のセキュリティ・デバイス・インタフェースも有する。制御ロジック１１はデバイスのオペレーションを全体的に制御し、以下に説明される認可プロセスのさまざまなステップを実現する。サーバ２は、データ通信ネットワーク（単数または複数）４とインタフェースするための通常の通信回路１３と、オンライン銀行サービスのさまざまな機能を実行するためのサーバ・ロジック１４とを含む。加えてサーバ２は、認可制御ロジック１５を含む認可装置と、オペレーションにおいて認可ロジック１５によって使用されるさまざまなデータを含有するメモリ１６とを含む。メモリは、以下に説明される目的を有する延期トランザクション・ログ１７と、ルール・データベース１８とを含む。ルール・データベース１８は、１人またはそれ以上の認可ユーザによる認可を必要とするトランザクションを規定する。特に、データベース１８に保存されるルール・データはトランザクションを示し、各トランザクションに対して、そのトランザクションに必要な認可を出す各認可ユーザの識別を示す。データベース１８中のルール構造は、特定のアプリケーションに依存して、簡単なルール・セットから複雑なデータ構造までの範囲に及んでもよい。一般的に、ＴＡＤ５中の制御ロジック１１およびサーバ２中のロジック１４、１５は、ハードウェア、ソフトウェアまたはその組合わせにおいて実現されてもよいが、我々はここでは、このロジックがサーバ・コンピュータ２またはＴＡＤ５のプロセッサ上を適宜走るソフトウェアによって実現されるものと仮定する。本明細書の記載から、当業者には好適なソフトウェアが明らかになるだろう。ＴＡＤ５の制御ロジック１１を実現するプロセッサは、このプロセッサに付加的な任意のコードをロードできないように設計される。
【００２６】
サーバ２は、ネットワーク４を介して、図面中に破線で示されるユーザＰＣ３への第１の接続を有することが示される。たとえば、ユーザＰＣは典型的に、ＰＣ３上を走るウェブ・ブラウザを介して、サーバ２へのインターネット接続を有する。ユーザＰＣ３は、ＴＡＤ５に対してさらに以下に考察されるように働くプロキシ・アプリケーション１９も走らせていることが示される。一般的にプロキシ１９はＰＣ３に予めインストールされていてもよいが、この好ましい実施形態において、プロキシは、たとえば自身をＵＳＢ大容量記憶装置として登録しているＴＡＤなどによって、ＴＡＤからロードされてもよい。
【００２７】
スマート・カード１０は、サーバ２を運営する銀行によって認可ユーザに発行される。カード１０は、ＴＡＤ５とサーバ２との間で行われる認証プロセスにおいて用いるためのセキュリティ・データを含有する。本例において、セキュリティ・データは秘密の暗号鍵であるが、スマート・カードは便宜に応じて、ユーザ・アカウント情報および証明書、たとえばサービス・プロバイダＵＲＬ、信頼されるＴＬＳ／ＳＳＬ（トランスポート層セキュリティ／セキュア・ソケット・レイヤ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ／Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）（商標））証明書、ユーザ名、ＰＩＮなど、および場合によってはサーバ２との通信において用いるための付加的な暗号鍵によっても個人化される。
【００２８】
システム１のオペレーションにおいて、銀行の顧客はあらゆる（信頼されていない）コンピュータ３からサーバ２に接続して、オンライン銀行ポータルにログインし、資金振替またはその他の銀行取引などのオペレーションを実行するようサーバに要求できる。こうしたトランザクション要求に応答したサーバ２のオペレーションが、図３の流れ図に示される。このプロセスは、ステップ２０に示されるトランザクション要求の受取りによって開始される。サーバ２が受取るすべてのトランザクション要求は、サーバ・ロジック１４によって認可ロジック１５に渡される。ステップ２１において、認可ロジックがルール・データベース１８にアクセスして、そのトランザクションに対する認可が必要かどうかをチェックする。判定ステップ２２において「Ｎｏ」（Ｎ）と示されるとおり、認可が必要でなければ、そのトランザクション要求はサーバ・ロジック１４に戻され、サーバ・ロジック１４はステップ２３において指示されたトランザクションを単純に実行して、プロセスが完了する。しかし、判定ステップ２２において「Ｙｅｓ」（Ｙ）と示されるとおり、トランザクションに対する認可が必要であれば、ステップ２４において認可ロジック１５は延期トランザクション・ログ１７にエントリを作成する。このエントリは、トランザクションの詳細に加えて、そのトランザクションに必要な認可を出すすべての認可ユーザの識別を記録する。よって、必要とされる認可（単数または複数）を受取るまでトランザクションは延期され、プロセスは終了する。
【００２９】
異なる信頼されないユーザ・コンピュータ３から、さまざまな時間に複数のユーザがトランザクションを指示し得る。前述のとおり、すべてのトランザクション要求がサーバ２によって対処されることによって、延期トランザクション・ログはいつでも認可を待つ複数のトランザクションの詳細を含み得る。ルール・データベース１８において識別される各認可ユーザは、上述のとおりスマート・カード１０を有する。認可ユーザはＴＡＤ５も有していてもよいし、ある場所にコンピュータ３とともに用いるためにＴＡＤ５が設けられてもよいし、あるいはその両方であってもよい。いずれの場合にも、ＴＡＤ５を有する認可ユーザがネットワーク接続されたコンピュータ３にアクセスするとき、ユーザは以下のとおりに認可手順を行い得る。ユーザはＴＡＤ５にスマート・カード１０を挿入し、ＵＳＢインタフェース６を介してＴＡＤをユーザＰＣ３に接続する。ＴＡＤ５のその後のオペレーションは制御ロジック１１によって制御され、図４の流れ図に示される。ステップ３０に示されるとおり、ＴＡＤ５のＰＣ３への接続に応答して、制御ロジック１１はサーバ２に接続するプロセスを開始する。まず、ステップ３１において、制御ロジックはディスプレイ７上のメッセージによって、ユーザに自身のＰＩＮをキーパッド８に入力するように促し、入力された番号はスマート・カード１０に保存された番号に対してチェックされる。デバイスはユーザに正しいＰＩＮを入力する機会を何度か与えてもよいが、有効ＰＩＮが入力されないとき（判定３２におけるＮ）、このプロセスは終了する。しかし、ＰＩＮが有効であると仮定するとき（判定３２におけるＹ）、ステップ３３において、制御ロジックはＰＣ３におけるプロキシ・アプリケーション１９を開始する。次にステップ３４に示されるとおり、制御ロジックはプロキシ１９の助けによって、ＴＡＤ５とサーバ２との間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立する。この接続は図２において実線で示される。この接続を確立するために、制御ロジックはカード読取装置９を介してスマート・カード１０と通信し、カード１０に保存されたセキュリティ・データにアクセスする。ＴＡＤとサーバとの相互認証を可能にするメッセージの暗号化／解読のために、予め同意された秘密鍵が用いられ、公知の態様でプロトコル・セットアップを実現することによって、サーバ２とのＴＬＳ／ＳＳＬ接続が確立される。このＴＬＳ／ＳＳＬ接続は、ＴＡＤ５と、（スマート・カード１０上の安全なデータを介した）そのＴＡＤの構成が目的とするサービス・プロバイダの信頼されるサーバ２との間のエンド・ツー・エンド接続であるが、プロキシはその２者間でネットワーク・パケットを盲目的に中継する。その結果、プロキシ１９およびＰＣ３を通過するすべてのデータが暗号化されるため、プロキシ１９およびＰＣ３は信頼できないものとなり得る。
【００３０】
安全な接続を確立した後、図４のステップ３５において、制御ロジック１１はサーバ２に、ＴＡＤのユーザによる認可まで延期されているあらゆるトランザクションの情報に対する要求を送る。安全な接続のセットアップにおいてすでに供給されていなければ、この要求にはカード１０から検索されたユーザＩＤデータが含まれていてもよい。サーバが、未処理の関連トランザクションはないと応答するとき（判定ステップ３６におけるＮ）、制御ロジックは遅延ブロック３７に表される予め定められた時間間隔だけ待つ。次いでプロセスはステップ３５に戻り、これによって安全な接続が持続する間、トランザクション情報に対する要求が定期的に繰り返される。判定ステップ３６に戻って、サーバ２によってトランザクション詳細が返されれば、ステップ３８において制御ロジックは認可されるべき第１のトランザクションの詳細をディスプレイ７に表示する。このディスプレイはユーザに、キーパッド８への入力によってそのトランザクションを承認または拒否するよう促すこともする。判定ステップ３９においてその結果が検出され、ユーザによるトランザクションの拒否（ステップ４０）または認可（ステップ４１）が、安全な接続を介してサーバ２に送り返される。判定ステップ４２において、制御ロジック１１は表示すべき別のトランザクションがあるかどうかを判定し、もしあれば、次のトランザクションのためにオペレーションはステップ３８に戻る。もしなければ、オペレーションは遅延ステップ３７に戻って、トランザクション情報の次の要求を待つ。
【００３１】
ＴＡＤがその安全な接続を介してサーバ２に接続している間、前述のプロセスが続く。このやり方で、ＴＡＤ５は安全な接続を介して、ＴＡＤのユーザによる認可を必要とし、かつユーザ・コンピュータ３とサーバ２との間の他の接続のいずれかを介してあらゆるユーザから要求されている延期トランザクションの詳細を収集し、その要求はＴＡＤ５の接続の前または後であってもよい。延期トランザクションは、サーバ２とのブラウザ・セッションを介して現在のＴＡＤユーザによって要求されたトランザクションを含んでもよく、このブラウザ・セッションはまったく正常に行われ、ＴＡＤの存在に影響を受けることがない。よってトランザクションは、いつでもどこからでもユーザがサーバに接続するときにユーザによって認可されることができ、トランザクション詳細は信頼されないコンピュータ３および信頼されないネットワーク４の媒介を介して、安全に伝達されて安全に認可される。
【００３２】
ＴＡＤ５からの延期トランザクション情報の要求に応答したサーバ２のオペレーションが、図５に示される。こうした要求はすべてサーバ２の認可ロジック１５に送られる。ステップ５０は認可ロジック１５による要求の受取りを表しており、次いで認可ロジック１５はステップ５１において、要求しているＴＡＤのユーザによる認可を必要とするあらゆるトランザクションについて、延期トランザクション・ログをチェックする。関連トランザクションが見出されないとき（判定５２におけるＮ）、ステップ５３においてそのことがＴＡＤに報告されて、プロセスは終了する。ログに何らかの関連トランザクションが見出されたとき（判定５２におけるＹ）、そのトランザクション詳細が安全な接続を介してＴＡＤに送られ、次いでロジック１５は遅延５５に示されるとおりに認可を待つ。認可応答が受取られないとき（判定５６におけるＮ）、ロジック１５はステップ５７において、応答に対する「タイムアウト」限界に達したかどうかを判定し、もしそうであればプロセスは終了する。限界に達していなければ、オペレーションは遅延５５に戻ってさらなる時間間隔だけ待つ。認可応答を受取ったとき（判定５６におけるＹ）、認可ロジックはステップ５８において、そのトランザクションが承認された（Ｙ）か拒否された（Ｎ）かを識別する。もし拒否されれば、ステップ５９および６０において認可ロジックはそのトランザクションを延期トランザクション・ログ１７から削除し、拒否されたことをサーバ・ロジック１４に通知する。次いでサーバ・ロジック１４は、たとえば要求しているユーザにトランザクション認可が拒否されたことを通知するなどの適切なアクションを取ることができる。次いでオペレーションはステップ６１に進み、ここでロジック１５は、認可を待つさらなるトランザクションがあるかどうかを判定する。もしなければプロセスは終了するが、もしさらなるトランザクションがあれば、オペレーションはステップ５５に戻ってさらなる認可を待つ。ステップ５８に戻って、ここでトランザクションが認可されるとき、次いでロジック１５は判定６３において、そのトランザクションに対する他のユーザの認可がなおも必要とされるかどうかをトランザクション・ログから判定する。もしそうであれば、ステップ６４においてログを単純に更新することによって現在のユーザの認可を示し、オペレーションは前と同様にステップ６１に進む。しかし、もし他のユーザの認可が必要でなければ、ステップ６５において認可ロジックはサーバ・ロジック１４にトランザクションを実行するよう指示する。次いで、ステップ６４において延期トランザクション・ログからそのトランザクションが削除され、オペレーションは認可を必要とする次のトランザクションのためにステップ６１に進む。現在のＴＡＤユーザによってすべてのトランザクションが認可（もしくは拒否）されるか、または認可に対するタイムアウト限界に達したとき、このプロセスは完了したとみなされる。
【００３３】
前述のプロセスは、モバイル・ユーザが通信システム内のあらゆるユーザ・コンピュータを介して接続するときにはいつでも、サーバがモバイル・ユーザからのトランザクション認可を受取ることを可能にする。ルール・データベース１８に規定されるとおり、すべての必要とされるパーティから必要な認可を受取ったときにのみ、サーバによってトランザクションが実現される。データベース１８中のルールは、たとえば企業内の組織的責任を反映するための、任意の複雑なマルチ・パーティ認証要求を実現でき、サーバはどのトランザクションがどのユーザによって明示的に認可される必要があるかを判定する。たとえば、ユーザ１が１０００ＵＳＤの価値のあるトランザクションを開始したと仮定するとき、データベースは、トランザクションが５００ＵＳＤよりも大きい価値を持つときには、ユーザ１に加えてユーザＮからも安全なトランザクション認可を必要とすることを指定したルールを含んでいてもよい。この場合、サーバは接続されたときに両方のユーザのＴＡＤに未処理のトランザクションを示し、両方のユーザがそのトランザクションを認可したときのみ、それはサーバによる処理に成功する。中間者（ＭＩＴＭ）または悪意あるソフトウェアがユーザによるトランザクション開始プロセスを攻撃しても、その後のマルチ・パーティ・トランザクション認証プロセスは、たとえＴＡＤが信頼できないコンピュータ上で動作されていても、こうした攻撃に対して安全である。ユーザはＴＡＤに表示された情報を信頼することができ、サービス・プロバイダの信頼されるサーバにユーザの認可決定を安全に通信して返すことができる。よってＴＡＤを介したトランザクション認可は、中間者（ＭＩＴＭ）および悪意あるソフトウェアの攻撃から電子トランザクションを保護し、複雑なマルチ・パーティ認可ルールを支持する一方で、ユーザの移動性を維持する。このやり方で、モバイル・コンピューティング環境において安全なマルチ・パーティ・トランザクション認可を効率的に実現できる。
【００３４】
上に好ましい実施形態を記載したが、さまざまな追加および代替形を想定できる。たとえば、コンピュータ３のユーザがトランザクションを開始するために、たとえばウェブ・ブラウザなどを介してサービス・プロバイダのポータルに最初にログインするときの、ユーザ認証の際にもＴＡＤ５が伴われてもよい。ユーザがポータルへのアクセスを要求するとき、サーバ２は安全な接続を介して何らかの認証コードを返してもよく、その認証コードは未処理トランザクションと同様にユーザのＴＡＤによって表示されてもよい。次いでユーザはこのコードを用いて、コンピュータ３のキーボードで、またはＴＡＤのキーパッドを介してそのコードを入力することによって、ポータルと認証を行い得る。一般的にＴＡＤを使用する際に、ユーザの判定は安全なＴＬＳ／ＳＳＬチャネルを介してサーバに返されることが好ましいが、ＴＡＤはトランザクション詳細とともにサーバによって生成された何らかのトランザクション／ユーザに特定的な認可コードを表示してもよい。次いでユーザはこのコードをディスプレイからコピーして、たとえばウェブ・ブラウザなどの、何か他のおそらくは信頼できない接続を介してサーバに送ってもよい。これは、ユーザによってウェブ・フォームに入力されるべき、通常はスクラッチ・リストまたはＳＭＳテキストを介して帯域外配信されるワン・タイム・コードを必要とする既存のウェブ・ポータルとの適合性を提供する。
【００３５】
オンライン銀行サービスの状況におけるオペレーションを説明したが、このシステムは、あらゆるタイプのリソースへのアクセスの認可を含む、多くのタイプのサーバ・オペレーションの認可のために適用できる。たとえば、マルチ・パーティ・トランザクション認可に対するのと同じやり方で、マルチ・パーティ・アクセス制御認可のためにＴＡＤを用いることができる。ここで、ユーザがサービス・プロバイダのポータルにログインしようと試みるとき、前の例におけるトランザクションに対するものと同様に、サーバは１人またはそれ以上の人物から彼らのＴＡＤを介して承認を要求できる。
【００３６】
ＴＡＤはさまざまな形を取ることができ、前述のとおり、その目的専用のものであってもよいし、たとえばマウスまたはＭＰ３プレーヤなどの、限定された付加的な機能を提供する何らかの他のデバイスと一体化されていてもよい。ユーザ・インタフェースはさまざまな態様で実現されてもよく、ユーザに音響プロンプトを与えるか、または異なる態様で視覚的情報を提供するか、あるいはその両方を行ってもよく、たとえばマウス・レーザ機構を利用してデスクトップに投影表示を生成してもよい。ＴＡＤコンピュータおよびセキュリティ・デバイス・インタフェースは一般的に、有線または無線接続のあらゆる便利な形を実現し得る。実際に、安全な接続を確立するためのセキュリティ・データは、ＴＡＤ内に物理的に埋込まれたメモリ中に保存されてもよく、たとえば自己破壊するデータ・コンテナまたは侵入検知センサなどを用いた、改ざんから物理的に保護された安全なチップの中などに保存されてもよい。
【００３７】
サーバ２の機能はサーバ・システムの異なる機械の上に分散されてもよく、メモリ１６は２つ以上の機械の上に分散した１つまたはそれ以上の異なるメモリ構成要素によって実現されてもよい。
【００３８】
本発明の範囲から逸脱することなく、記載された例示的な実施形態に対して多くのその他の変更および修正が行われ得ることが認められるだろう。
【特許請求の範囲】
【請求項１】
データ通信ネットワークを介してユーザ・コンピュータから要求されたリモート・サーバのオペレーションを認可するための認可デバイスであって、前記デバイスは、
データ通信ネットワークを介した前記リモート・サーバとの通信のために前記デバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、
ユーザに情報を提供するためのユーザ・インタフェースと、
使用中の制御ロジックにアクセス可能なセキュリティ・データを用いて、前記デバイスとサーバとの間に、前記ローカル・ユーザ・コンピュータを介して、前記デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合され、
前記サーバへの異なる接続を介して要求され前記デバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、前記サーバから前記接続を介して収集するように適合され、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供するように適合された、
制御ロジックと
を含む、デバイス。
【請求項２】
前記制御ロジックは、前記相互認証された接続を介して前記サーバからの前記情報を要求するように適合される、請求項１に記載のデバイス。
【請求項３】
前記制御ロジックは、前記相互認証された接続が持続する間、定期的に前記サーバからの前記情報を要求するように適合される、請求項１または２に記載のデバイス。
【請求項４】
前記制御ロジックは、前記デバイスの前記ローカル・ユーザ・コンピュータへの接続に応答して、前記相互認証された接続の確立を開始するように適合される、先行する請求項のいずれかに記載のデバイス。
【請求項５】
前記セキュリティ・データを保存するメモリを含む、先行する請求項のいずれかに記載のデバイス。
【請求項６】
前記セキュリティ・データを保存するセキュリティ・デバイスに前記認可デバイスを接続するためのセキュリティ・デバイス・インタフェースを含み、前記制御ロジックは使用中の前記セキュリティ・デバイス・インタフェースを介して前記セキュリティ・データにアクセスするように適合される、請求項１から４のいずれか１つに記載のデバイス。
【請求項７】
前記セキュリティ・デバイス・インタフェースは、前記セキュリティ・データを保存するスマート・カードに前記認可デバイスを接続するためのカード読取装置を含む、請求項６に記載のデバイス。
【請求項８】
前記ユーザ・インタフェースはユーザ認可の入力のための入力機構を含み、前記制御ロジックは前記相互認証された接続を介して前記サーバに前記ユーザ認可を伝達するように適合される、先行する請求項のいずれかに記載のデバイス。
【請求項９】
データ通信ネットワークを介してユーザ・コンピュータから要求されたサーバのオペレーションを制御するための装置であって、前記装置は、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリと、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、前記オペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかを前記ルール・データから判定し、もし認可が必要であれば前記オペレーションを延期するように適合され、
先行する請求項のいずれかに記載の認可デバイスと通信して前記相互認証された接続を確立するように適合され、
ユーザ・コンピュータから要求され前記認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して前記認可デバイスに供給し、かつ前記ユーザから認可を受取るように適合され、
前記オペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションの実行を開始するように適合された、
制御ロジックと
を含む、装置。
【請求項１０】
前記制御ロジックは、前記相互認証された接続を介した前記認可デバイスからの要求に応答して、前記認可デバイスに前記情報を供給するように適合される、請求項９に記載の装置。
【請求項１１】
前記制御ロジックは、前記相互認証された接続を介して前記認可デバイスの前記ユーザから前記認可を受取るように適合される、請求項９または１０に記載の装置。
【請求項１２】
データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するためのサーバであって、前記サーバは、
前記データ通信ネットワークを介してユーザ・コンピュータと通信するための通信回路と、
ユーザ・コンピュータからの要求に応答して前記オペレーションを実行するためのサーバ・ロジックと、
前記サーバ・ロジックによる前記オペレーションの実行を制御するための、請求項９から１１のいずれか１つに記載の装置と
を含む、サーバ。
【請求項１３】
データ通信システムであって、
請求項１２に記載のサーバと、
データ通信ネットワークを介して前記サーバと通信するための少なくとも１つのユーザ・コンピュータと、
少なくとも１つの、請求項１から８のいずれか１つに記載の認可デバイスであって、前記デバイスの前記コンピュータ・インタフェースを介して前記ユーザ・コンピュータに接続するための、前記デバイスと
を含み、前記ユーザ・コンピュータは、前記相互認証された接続を介して前記認可デバイスとサーバとの間の通信を中継するように適合される、データ通信システム。
【請求項１４】
コンピュータ・プログラムであって、データ通信ネットワークを介したリモート・サーバとの通信のためにユーザ・コンピュータに接続するために適合された、認可デバイスのユーザに情報を提供するためのユーザ・インタフェースを有する前記デバイスのプロセッサに、
前記認可デバイスに関連するセキュリティ・データを用いて、前記ローカル・ユーザ・コンピュータを介して、前記サーバとの暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立させ、
前記サーバへの異なる接続を介して要求され、前記デバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、前記サーバから前記接続を介して収集させ、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供させる
ためのコンピュータ・プログラム。
【請求項１５】
コンピュータ・プログラムであって、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するために適合された、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリを有するサーバに、
前記オペレーションを実行するためのユーザ・コンピュータからの要求に応答して、前記オペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかを前記ルール・データから判定させ、もし認可が必要であれば前記オペレーションを延期させ、
請求項１から８のいずれか１つに記載の認可デバイスと通信して前記相互認証された接続を確立させ、
ユーザ・コンピュータから要求され、前記認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して前記認可デバイスに供給させ、かつ前記ユーザからの認可を受取らせ、
前記オペレーションに必要な許可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションを実行させる
ためのコンピュータ・プログラム。
【請求項１】
データ通信ネットワークを介してユーザ・コンピュータから要求されたリモート・サーバのオペレーションを認可するための認可デバイスであって、前記デバイスは、
データ通信ネットワークを介した前記リモート・サーバとの通信のために前記デバイスをローカル・ユーザ・コンピュータに接続するためのコンピュータ・インタフェースと、
ユーザに情報を提供するためのユーザ・インタフェースと、
使用中の制御ロジックにアクセス可能なセキュリティ・データを用いて、前記デバイスとサーバとの間に、前記ローカル・ユーザ・コンピュータを介して、前記デバイスとサーバとの間の暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立するように適合され、
前記サーバへの異なる接続を介して要求され前記デバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、前記サーバから前記接続を介して収集するように適合され、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供するように適合された、
制御ロジックと
を含む、デバイス。
【請求項２】
前記制御ロジックは、前記相互認証された接続を介して前記サーバからの前記情報を要求するように適合される、請求項１に記載のデバイス。
【請求項３】
前記制御ロジックは、前記相互認証された接続が持続する間、定期的に前記サーバからの前記情報を要求するように適合される、請求項１または２に記載のデバイス。
【請求項４】
前記制御ロジックは、前記デバイスの前記ローカル・ユーザ・コンピュータへの接続に応答して、前記相互認証された接続の確立を開始するように適合される、先行する請求項のいずれかに記載のデバイス。
【請求項５】
前記セキュリティ・データを保存するメモリを含む、先行する請求項のいずれかに記載のデバイス。
【請求項６】
前記セキュリティ・データを保存するセキュリティ・デバイスに前記認可デバイスを接続するためのセキュリティ・デバイス・インタフェースを含み、前記制御ロジックは使用中の前記セキュリティ・デバイス・インタフェースを介して前記セキュリティ・データにアクセスするように適合される、請求項１から４のいずれか１つに記載のデバイス。
【請求項７】
前記セキュリティ・デバイス・インタフェースは、前記セキュリティ・データを保存するスマート・カードに前記認可デバイスを接続するためのカード読取装置を含む、請求項６に記載のデバイス。
【請求項８】
前記ユーザ・インタフェースはユーザ認可の入力のための入力機構を含み、前記制御ロジックは前記相互認証された接続を介して前記サーバに前記ユーザ認可を伝達するように適合される、先行する請求項のいずれかに記載のデバイス。
【請求項９】
データ通信ネットワークを介してユーザ・コンピュータから要求されたサーバのオペレーションを制御するための装置であって、前記装置は、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリと、
前記オペレーションを行うためのユーザ・コンピュータからの要求に応答して、前記オペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかを前記ルール・データから判定し、もし認可が必要であれば前記オペレーションを延期するように適合され、
先行する請求項のいずれかに記載の認可デバイスと通信して前記相互認証された接続を確立するように適合され、
ユーザ・コンピュータから要求され前記認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して前記認可デバイスに供給し、かつ前記ユーザから認可を受取るように適合され、
前記オペレーションに必要な認可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションの実行を開始するように適合された、
制御ロジックと
を含む、装置。
【請求項１０】
前記制御ロジックは、前記相互認証された接続を介した前記認可デバイスからの要求に応答して、前記認可デバイスに前記情報を供給するように適合される、請求項９に記載の装置。
【請求項１１】
前記制御ロジックは、前記相互認証された接続を介して前記認可デバイスの前記ユーザから前記認可を受取るように適合される、請求項９または１０に記載の装置。
【請求項１２】
データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するためのサーバであって、前記サーバは、
前記データ通信ネットワークを介してユーザ・コンピュータと通信するための通信回路と、
ユーザ・コンピュータからの要求に応答して前記オペレーションを実行するためのサーバ・ロジックと、
前記サーバ・ロジックによる前記オペレーションの実行を制御するための、請求項９から１１のいずれか１つに記載の装置と
を含む、サーバ。
【請求項１３】
データ通信システムであって、
請求項１２に記載のサーバと、
データ通信ネットワークを介して前記サーバと通信するための少なくとも１つのユーザ・コンピュータと、
少なくとも１つの、請求項１から８のいずれか１つに記載の認可デバイスであって、前記デバイスの前記コンピュータ・インタフェースを介して前記ユーザ・コンピュータに接続するための、前記デバイスと
を含み、前記ユーザ・コンピュータは、前記相互認証された接続を介して前記認可デバイスとサーバとの間の通信を中継するように適合される、データ通信システム。
【請求項１４】
コンピュータ・プログラムであって、データ通信ネットワークを介したリモート・サーバとの通信のためにユーザ・コンピュータに接続するために適合された、認可デバイスのユーザに情報を提供するためのユーザ・インタフェースを有する前記デバイスのプロセッサに、
前記認可デバイスに関連するセキュリティ・データを用いて、前記ローカル・ユーザ・コンピュータを介して、前記サーバとの暗号化されたエンド・ツー・エンド通信のための相互認証された接続を確立させ、
前記サーバへの異なる接続を介して要求され、前記デバイスのユーザによる認可を必要とするあらゆるオペレーションを示す情報を、前記サーバから前記接続を介して収集させ、
前記オペレーションの認可を促すために、前記ユーザ・インタフェースを介してユーザに前記情報を提供させる
ためのコンピュータ・プログラム。
【請求項１５】
コンピュータ・プログラムであって、データ通信ネットワークを介してユーザ・コンピュータから要求されたオペレーションを実行するために適合された、１人またはそれ以上の認可ユーザによる認可を必要とするオペレーションを規定するルール・データを保存するためのメモリを有するサーバに、
前記オペレーションを実行するためのユーザ・コンピュータからの要求に応答して、前記オペレーションのために少なくとも１人の認可ユーザによる認可が必要とされるかどうかを前記ルール・データから判定させ、もし認可が必要であれば前記オペレーションを延期させ、
請求項１から８のいずれか１つに記載の認可デバイスと通信して前記相互認証された接続を確立させ、
ユーザ・コンピュータから要求され、前記認可デバイスのユーザによる認可を必要とするあらゆる延期オペレーションを示す情報を、前記接続を介して前記認可デバイスに供給させ、かつ前記ユーザからの認可を受取らせ、
前記オペレーションに必要な許可を出すすべての認可ユーザから認可を受取ると、それに応答して、延期オペレーションを実行させる
ためのコンピュータ・プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１２−５０３２２９（Ｐ２０１２−５０３２２９Ａ）
【公表日】平成２４年２月２日（２０１２．２．２）
【国際特許分類】
【出願番号】特願２０１１−５２６６２６（Ｐ２０１１−５２６６２６）
【出願日】平成２１年９月１７日（２００９．９．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５４０７４
【国際公開番号】ＷＯ２０１０／０３２２０７
【国際公開日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２４年２月２日（２０１２．２．２）
【国際特許分類】
【出願日】平成２１年９月１７日（２００９．９．１７）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５４０７４
【国際公開番号】ＷＯ２０１０／０３２２０７
【国際公開日】平成２２年３月２５日（２０１０．３．２５）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]