説明

セキュアリソースの認可

システムは、第1のデバイス(130)から、セキュアリソースへアクセスするためのセキュアリソースリクエスト(150)および検証電話番号を受信し、検証電話番号に関連付けられている第2のデバイス(110)とのセキュアセッションを確立し、セキュアリソースリクエストを検証するために第2のデバイスから認証メカニズム(170)をリクエストし、第2のデバイスからリクエストした認証メカニズムを受信する場合(180)、受信した認証メカニズムを検証し、受信した認証メカニズムの検証に基づいて、セキュアリソースへの第1のデバイスのアクセスを許可するかまたは拒否するかを判定する。

【発明の詳細な説明】
【技術分野】
【0001】
個人は、他パーティのアクセスを制御された方法で潜在的に許可することを好むようないくつかのリソースを個人が所有することがある。信頼に値しない終端点(例えば、ネットワークに接続される非認証デバイス)から、組織の内部ネットワークリソースへのアクセスを組織は絶えず防止しようとする。個人および/または組織体は、セキュアリソースへのアクセスを動的に制御する、並びにセキュアリソースにアクセスしている時間または方法を制御することを要望することがあるいくつかの状況が存在しうる。例えば、個人は自身の子供が自身のクレジットカード(即ち、セキュアリソース)にアクセスすることを許容することはできるが、自身の子供がクレジットカードにより購入リクエストが行われる場合には、その通知を受け、トランザクションを認可することを好むであろう。別の例では、組織は、従業員が内部ネットワークのある部署にアクセスすることを許可することはできるが、同じ従業員が内部ネットワークの他部署にアクセスすることを拒否することがありうる。
【0002】
一態様に従えば、方法は、第1のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストおよび検証電話番号を受信するステップ、検証電話番号に関連付けられている第2のデバイスとのセキュアセッションを確立するステップ、第2のデバイスからセキュアリソースリクエストを検証するための認証メカニズムをリクエストするステップ、第2のデバイスからリクエストされた認証メカニズムが受信される場合、受信した認証メカニズムを検証するステップ、および受信した認証メカニズムの検証に基づいて、セキュアリソースへのアクセスを第1のデバイスに許可するかまたは拒否するかを判定するステップを含むことができる。
【0003】
加えて、本方法は、検証電話番号を認証メカニズムと関連付けるステップを含むことができる。
【0004】
加えて、セキュアセッションを確立するステップは、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS:Short Message Service)信号を生成するステップ、そのSMS信号を第2のデバイスに提供するステップ、および第2のデバイスがアドレスにアクセスする場合、セキュアセッションを確立するステップを含むことができる。
【0005】
加えて、受信した認証メカニズムを検証するステップは、受信した認証メカニズムが検証電話番号に関連付けられている認証メカニズムと整合するかを判定するステップを含むことができる。
【0006】
別の態様に従えば、方法は、セキュアリソースを使用するためのリクエストを受信するステップ、セキュアリソースに関連付けられているデバイスを判定するステップ、セキュアリソースに関連付けられているデバイスとのセキュアセッションを確立するステップ、デバイスからセキュアリソースリクエストの認可をリクエストするステップ、デバイスからセキュアリソースリクエストの認可を受信する場合、認可を検証するステップ、および認可の検証に基づいて、セキュアリソースの使用を第1のデバイスに許可するかまたは拒否するかを判定するステップを含むことができる。
【0007】
加えて、セキュアセッションを確立するステップは、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS)信号を生成するステップ、SMS信号をデバイスに提供するステップ、およびデバイスがアドレスにアクセスする場合、セキュアセッションを確立するステップを含むことができる。
【0008】
加えて、認可をリクエストするステップは、セキュアリソースの記述をデバイスに提供するステップ、およびプライベートキーにより、デバイスによる記述の署名をリクエストするステップを含むことができる。
【0009】
加えて、認可を検証するステップは、デバイスに関連付けられているパブリックキーにより認可を検証するステップを含むことができる。
【0010】
さらに別の態様に従えば、第1のデバイス内で実行される方法は、セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS)信号を受信するステップ、アドレスに基づいて、セキュアセッションを確立するステップ、セキュアリソースリクエストを認証するための認証メカニズムに対するリクエストを受信するステップ、およびセキュアリソースリクエストが認証される場合、リクエストされた認証メカニズムを提供するステップを含むことができる。
【0011】
加えて、本方法は、セキュアリソースへのアクセスを第2のデバイスに許可するまたは拒否するかの指示を受信するステップを含むことができる。
【0012】
加えて、認証メカニズムに対するリクエストを受信するステップは、セキュアリソースの記述を受信するステップを含むことができる。
【0013】
さらなる態様に従えば、第1のデバイス内で実行される方法は、セキュアリソースを使用するためのセキュアリソースリクエストを第2のデバイスによって認可するために、セキュアセッションを確立するアドレスを含むショートメッセージサービス(SMS)信号を受信するステップ、アドレスに基づいて、セキュアセッションを確立するステップ、セキュアリソースリクエストを認可するためのリクエストを受信するステップ、およびセキュアリソースリクエストが認可される場合、リクエストされた認可を提供するステップを含むことができる。
【0014】
加えて、本方法は、セキュアリソースを使用するための認可を第2のデバイスに許可するかまたは拒否するかの指示を受信するステップを含むことができる。
【0015】
加えて、認可するためのリクエストを受信するステップは、セキュアリソースの記述を受信するステップ、およびプライベートキーにより、記述を署名するためのリクエストを受信するステップを含むことができる。
【0016】
加えて、リクエストされた認可を提供するステップは、セキュアリソースリクエストが認可される場合、プライベートキーにより署名された記述を提供するステップを含むことができる。
【0017】
加えて、認可するためのリクエストを受信するステップは、セキュアリソースの記述を受信するステップ、セキュアリソースの使用をリクエストするユーザの識別情報を受信するステップまたはセキュアリソースリクエストを特定する乱数を受信するステップの少なくとも1つを含むことができる。
【0018】
別の態様に従えば、第1のデバイス内で実行される方法は、セキュアリソースへのアクセスまたはセキュアリソースの使用をリクエストするステップ、第1のデバイスにセキュアリソースへのアクセスまたはセキュアリソースの使用を認証する第2のデバイスを特定する検証電話番号を提供するステップ、および第2のデバイスによって提供される認証に基づいて、セキュアリソースへのアクセス権またはセキュアリソースの使用権を受信するステップを含むことができる。
【0019】
さらなる態様に従えば、システムは、第1のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信する手段、ショートメッセージサービス(SMS)信号により、セキュアリソースへのアクセスを認可するための、第1のデバイスとは異なる第2のデバイスとのセキュアセッションを確立する手段、第2のデバイスからセキュアリソースリクエストの認可をリクエストする手段、第2のデバイスからセキュアリソースリクエストの認可が受信される場合、認可を検証する手段、および認可の検証に基づいて、第1のデバイスにセキュアリソースへのアクセスを許可するかまたは拒否するかを判定する手段を含むことができる。
【0020】
加えて、認可をリクエストする手段は、セキュアリソースリクエストを検証するために、第2のデバイスから認証メカニズムをリクエストする手段、またはプライベートキーにより、第2のデバイスによるセキュアリソースの記述の署名をリクエストする手段の1つを含むことができる。
【0021】
加えて、認可を検証する手段は、第2のデバイスから受信する認証メカニズムが第2のデバイスの検証電話番号に関連付けられている認証メカニズムに整合するかを判定する手段、または第2のデバイスに関連付けられているパブリックキーによる認可を検証する手段の1つを含むことができる。
【0022】
なおさらに別の態様に従えば、システムは、セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS)信号を受信する手段、アドレスに基づいて、セキュアセッションを確立する手段、セキュアリソースリクエストを認可するためのリクエストを受信する手段、およびセキュアリソースリクエストが認可される場合、リクエストされた認可を提供する手段を含むことができる。
【0023】
加えて、リクエストを受信する手段は、セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を含むことができる。
【0024】
加えて、リクエストされた認可を提供する手段は、セキュアリソースリクエストが認証される場合、リクエストされた認証メカニズムを提供する手段を含むことができる。
【0025】
加えて、認可するためのリクエストを受信する手段は、セキュアリソースの記述と、セキュアリソースの使用をリクエストするユーザの識別情報またはセキュアリソースリクエストを特定する乱数の少なくとも1つを受信する手段と、およびプライベートキーにより、記述を署名するためのリクエストを受信する手段を含むことができる。
【0026】
加えて、リクエストされた認可の提供する手段は、セキュアリソースリクエストが認可される場合、プライベートキーにより署名された記述を提供する手段を含むことができる。
【0027】
別の態様に従えば、デバイスは、複数の命令を記憶するメモリおよびメモリの命令を実行するプロセッサを含むことができる。プロセッサは、第1のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信し、ショートメッセージサービス(SMS)信号によりセキュアリソースへのアクセスを認可するために、第1のデバイスとは異なる第2のデバイスとのセキュアセッションを確立し、第2のデバイスから、セキュアリソースリクエストの認可をリクエストし、セキュアリソースリクエストの認可が第2のデバイスから受信される場合、認可を検証し、認可の検証に基づいて、第1のデバイスにセキュアリソースへのアクセスを許可するかまたは拒否するかを判定することができる。
【0028】
なおさらに別の態様に従えば、デバイスは、複数の命令を記憶するメモリおよびメモリの命令を実行する処理ロジックを含むことができる。処理ロジックは、セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS)信号を受信し、アドレスに基づいて、セキュアセッションを確立し、セキュアリソースリクエストを認可するためのリクエストを受信し、セキュアリソースリクエストが認可される場合、リクエストされた認可を提供することができる。
【0029】
本明細書に組込み、その一部を構成する添付図面は本明細書に記述する1つまたは複数の実装を図示し、記述と共にこれらの実装を説明する:
【図面の簡単な説明】
【0030】
【図1】本明細書において記載されるシステムおよび方法を実装することができるネットワークの例示図である。
【図2】図1のユーザデバイスの例示的前面図である。
【図3】図2のユーザデバイスの例示的構成要素図である。
【図4】図1のクライアントまたはサーバの例示図である。
【図5】図1のクライアントによって提供される例示的表示図である。
【図6】図1のユーザデバイスによって提供される例示的表示図である。
【図7】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図8】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図9】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図10】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図11】本明細書に記載される実装による例示的処理を示すフローチャートである。
【発明を実施するための形態】
【0031】
以下の詳細な記述は、添付する図面を参照する。種々の図面における同一の参照番号は、同一のまたは類似の要素を特定することがある。また、以下の詳細な記述は、本発明を限定するものではない。
【0032】
概要
本明細書に記載される実装は、セキュアな(secure:安全な)ユーザデバイスによって提供される認証および認可の少なくとも一方に基づいて、1つまたは複数のセキュアリソースへのアクセス権を提供することができる。例えば、一実装では、ユーザデバイスは、パブリックキーンフラストラクチャ(PKI:public key infrastructure)をサポートすることができるセルラーまたは携帯電話機に対応する。ユーザデバイスは、セキュアリソース(例えば、セキュアネットワークに提供されているサーバ)へのアクセスを試行する別のデバイス(例えば、クライアントデバイス)の認証および認可の少なくとも一方を提供する2つの組のPKI信用証明(例えば、プライベートキーおよびパブリックキー、あるいは証明書)を含むことができる。ユーザデバイスのユーザは、クライアントのユーザと同一である、またはクライアントのユーザとは異なる。
【0033】
一実装(以下では、「認証例」と呼ぶ)では、デバイス(例えば、クライアント)のユーザは、セキュアリソース(例えば、セキュアネットワークのサーバによって提供されるアプリケーション)へのアクセスをリクエストすることができる。ユーザは、クライアントを通じて、ユーザを認証する検証電話番号を提供することができる。セキュアリソースリクエストおよび検証電話番号は、サーバによって受信することができ、また、サーバは、サーバとのセキュアセッションを確立するためのアドレスを含むショートメッセージサービス(SMS)信号を生成することができる。SMS信号は、検証電話番号およびユーザとに関連付けられているユーザデバイスに提供することができ、セキュアセッションをサーバと確立することができる。サーバは、検証電話番号を認証メカニズム(例えば、ユーザ名、パスワード、個人識別番号(PIN:personal identification number)等)と関連付けることができ、セキュアリソースリクエストを検証するために、認証メカニズムをユーザデバイスからリクエストすることができる。ユーザデバイスは、認証メカニズムをサーバに提供することができ、また、サーバは、クライアントがセキュアリソースへアクセスすることを許可するまたは拒否するかを判定するために、認証メカニズムを検証することができる。例えば、ユーザデバイスがリクエストされた認証メカニズムを提供する場合、ユーザに、クライアントを通じて、サーバによって提供されるセキュアリソースへのアクセスを許可することができる。
【0034】
別の実装(以下では、「トランザクション例」と呼ぶ)では、個人(例えば、従業員)はデバイス(例えば、クライアント)を通じてセキュアリソース(例えば、管理者による認可をリクエストすることができるセキュアサーバのアプリケーション)の使用認可をリクエストすることができる。サーバは、セキュアリソースをユーザデバイスに(例えば、管理者のユーザデバイスに)に関連する、電話番号およびパブリックキーと関連付けることができる。サーバは、ユーザデバイスに。サーバとのセキュアセッションを確立するためのアドレスを含むSMS信号を送信することができる。セキュアセッションがサーバとユーザデバイスとの間で確立される場合、サーバは、ユーザデバイスにセキュアリソースの記述(description)、認可をリクエストする従業員、従業員によるセキュアリソースの使用を認可するためのリクエスト、およびリクエストを識別する乱数の少なくとも1つを送信することができる。セキュアリソースの記述にプライベートキーにより電子的に署名し、その署名した記述および乱数をサーバに送信することによって、管理者はユーザデバイスを通じてセキュアリソースリクエストを認可することができる。ユーザにセキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイスと関連付けられているパブリックキーにより、および/または受信した乱数と元々の乱数との比較によって、サーバは署名されたセキュアリソースの記述を検証することができる。例えば、署名された記述が検証される場合、従業員は、クライアントを通じて、セキュアリソースを使用するための認可を受信することができる。
【0035】
本明細書において使用される「セキュアリソース(secure resource)」という用語、以下のものを含むように広く解釈される。これには、任意のネットワーク、デバイス、アプリケーション、プロパティおよび/またはネットワークの組み合わせ、デバイス群、アプリケーション群および/またはアクセスを制御することができるプロパティを含んでいる。例えば、セキュアリソースは、セキュアネットワークまたはプライベートネットワーク、イントラネット、ローカルネットワーク、アプリケーション群および/またはセキュアネットワークに提供されるデバイス、イントラネットまたはローカルネットワーク、クレジットカード、車両(例えば、自動車、トラック、航空機、ボート等)、建物、パーソナル・ウェブ・ページ、電子メールアカウント、ログイン、パスワード、ユーザ名、等をリクエストする任意のウェブサイト、および/または任意の他のネットワーク、デバイス、アプリケーションおよび/または認可および/または認証をリクエストすることができるプロパティを含むことができる。
【0036】
例示的ネットワーク構成
図1は、本明細書で記載されるシステムおよび方法を実装することができるネットワーク100の例示図である。ネットワーク100は、ネットワーク140を介して接続される、ユーザデバイス110、サーバ120およびクライアント130を含むことができる。簡略のため、1つのユーザデバイス110、1つのサーバ120および1つのクライアント130がネットワーク140に接続されているに示している。実際には、さらに多くのユーザデバイス群、サーバ群および/またはクライアント群が存在していても良い。また、いくつかの例では、ユーザデバイスは、サーバの1つまたは複数の機能を実行することができ、サーバは、ユーザデバイスの1つまたは複数の機能を実行することができる。他の例では、クライアントは、サーバの1つまたは複数の機能を実行することができ、サーバは、クライアントの1つまたは複数の機能を実行することができる。
【0037】
ユーザデバイス110は、1つまたは複数のエンティティを含むことができる。エンティティは、電話機、セルラーフォン(例えば、無線アプリケーションプロトコル(WAP:Wireless Application Protocol)アプリケーション等のインターネットベースのアプリケーションを提供する)、パーソナルコンピュータ、パーソナル・デジタル・アシスタント(PDA:personal digital assistant)、ラップトップまたは別のタイプの計算デバイスまたは通信デバイス、これらのデバイスの1つにおいて実行するスレッドあるいはプロセス、および/またはこれらのデバイスの1つによって実行可能なオブジェクト等のデバイスとして定義することができる。一実装では、ユーザデバイス110は、本明細書で記載されるように、1つまたは複数のセキュアリソースの認可および認証の少なくとも一方を提供することができる。
【0038】
サーバ120は、本明細書に記載されるように、情報を収集、処理、検索および提供の少なくとも1つを実行する1つまたは複数のサーバエンティティを含むことができる。例えば、一実装では、サーバ120は、1つまたは複数のセキュアリソース、および/または、本明細書で記載されるように、1つまたは複数のセキュアリソースの認可/認証を提供することができる。
【0039】
クライアント130は、電話機、セルラーフォン(例えば、WAPアプリケーション等のインターネットベースのアプリケーションを提供する)、パーソナルコンピュータ、PDA、ラップトップ、カード認可デバイス(例えば、クレジットまたはデビットカード認可デバイス、キーフォッブ等)、または別のタイプの計算または通信デバイス、これらのデバイスの1つにおいて実行されるスレッドあるいはプロセス、および/またはこれらのデバイスの1つによって実行可能なオブジェクト等の1つまたは複数のエンティティを含むことができる。一実装では、クライアント130は、本明細書に記載されるように、セキュアリソースへのアクセスおよび/またはセキュアリソースの使用認可をリクエストすることができる。他の実装では、クライアント130は、第2のユーザデバイス110に対応する。
【0040】
ネットワーク140は、ローカル・エリア・ネットワーク(LAN:local area network)、ワイド・エリア・ネットワーク(WAN:wide area network)、メトロポリタン・エリア・ネットワーク(MAN:metropolitan area network)、公衆交換電話ネットワーク(PSTN:Public Switched Telephone Network)またはセルラー電話ネットワーク等の電話ネットワーク、イントラネット、インターネット、またはネットワークの組み合わせを含むことができる。ユーザデバイス110、サーバ120およびクライアント130は、有線および/または無線接続によりネットワーク140に接続することができる。
【0041】
図1は、ネットワーク100の例示的構成要素を示している。他の実装では、ネットワーク100は、図1に示される構成要素より、さらに少ない、異なる、または追加の構成要素を含んでも良い。
【0042】
図1にさらに示されるように、例示的動作では、クライアント130は、セキュアリソースへアクセスするためのリクエスト150をサーバ120に送信することができる。認証例では、クライアント130は、リクエスト150と共にユーザデバイス110の検証電話番号を提供することができる。この検証電話番号は、クライアント130のユーザを認可および/または認証するために利用することができる。トランザクション例では、サーバ120は、リクエスト150のセキュアリソースと関連付けられているユーザデバイス(例えば、ユーザデバイス110)を判定することができる。サーバ120は、ユーザデバイス110とのセキュアセッションを確立するためのSMS信号160を生成することができ、また、セキュアセッションが確立される場合、認証メカニズム(例えば、ユーザ名、パスワード、PIN等)に対するリクエスト170をユーザデバイス110に送信することができる。認証例では、サーバ120は、検証電話番号を認証メカニズムと関連付けることができ、また、この認証メカニズムをユーザデバイス110からリクエストすることができる。トランザクション例では、サーバ120は、セキュアリソースの記述をユーザデバイス110に提供することができ、ユーザデバイス110によるプライベートキーにより記述の署名をリクエストすることができる。
【0043】
図1にさらに示されるように、ユーザデバイス110は、認証メカニズム180をサーバ120に提供することができる。認証例では、ユーザデバイス110は、認証メカニズム180を直接サーバ120に提供することができ、また、認証メカニズム180は、検証電話番号と関連付けられる。サーバ120は、認証メカニズム180を受信することができ、また、認証メカニズム180を(例えば、認証メカニズム180を検証電話番号と比較することによって)検証することができる。トランザクション例では、ユーザデバイス110は、プライベートキーによりセキュアリソースの記述に署名することができる。サーバ120は、署名された記述を受信することができ、また、ユーザデバイス110と関連付けられているパブリックキーで、署名されたセキュアリソースの記述を検証することができる。認証およびトランザクションの例の両方では、サーバ120は、セキュアリソースへのアクセスを許可または拒否する信号190をクライアント130に送信することができる。例えば、クライアント130がセキュアリソースへのアクセスを許可される場合、サーバ120は、クライアント130にセキュアリソースへのアクセス権を提供することができる。
【0044】
例示的ユーザデバイス構成
図2は、本明細書に記載される一実装におけるユーザデバイス110の例示的前面図である。図2に示されるように、ユーザデバイス110は、筐体210、スピーカ220、ディスプレイ230、制御ボタン240、キーパッド250および/またはマイクロフォン260を含むことができる。筐体210は、ユーザデバイス110の構成要素を外部要素から保護することができる。スピーカ220は、可聴情報をユーザデバイス110のユーザに提供することができる。
【0045】
ディスプレイ230は、可視情報をユーザに提供することができる。例えば、ディスプレイ230は、ユーザデバイス110への入力テキスト、サーバ120等の別のデバイスから受信されるテキストおよび/またはグラフィックス(例えば、SMS信号)および/または着信呼または発信呼またはテキストメッセージ、メディア、ゲーム、電話帳、アドレス庁、現在時間等に関する情報を表示することができる。制御ボタン240は、ユーザがユーザデバイス110と相互動作することを許容することで、ユーザデバイス110に1つまたは複数の動作を実行させるようにすることができる。例えば、制御ボタン240を使用することで、ユーザデバイス110に情報を送信させるようにすることができる。キーパッド250は、標準電話機キーパッドを含むことができる。マイクロフォン260は、可聴情報をユーザから受信することができる。
【0046】
図2はユーザデバイス110の例示的要素を示している。他の実装では、ユーザデバイス110は、図2に示される要素よりもさらに少ない、または、異なる、または追加要素を含むことができる。なおさらに他の実装では、ユーザデバイス110の1つまたは複数の要素は、ユーザデバイス110の1つまたは複数の他の要素によって実行されるタスクを実行することができる。
【0047】
図3は、ユーザデバイス110の例示的構成要素図である。図3に示されるように、ユーザデバイス110は、処理ロジック310、メモリ320、ユーザインタフェース330、通信インタフェース340および/またはアンテナアセンブリ350を含むことができる。処理ロジック310は、プロセッサ、マイクロプロセッサ、特定用途集積回路(ASIC:application specific integrated circuit)、フィールド・プログラマブル・ゲートアレイ(FPGA:field programmable gate array)、またはその類を含むことができる。処理ロジック310は、ユーザデバイス110およびその構成要素の動作を制御することができる。メモリ320は、ランダム・アクセス・メモリ(RAM:random access memory)、リードオンリメモリ(ROM:read only memory)および/または処理ロジック310によって使用することができるデータおよび命令を記憶する別のタイプのメモリを含むことができる。
【0048】
ユーザインタフェース330は、情報をユーザデバイス110に入力するメカニズムおよび/またはユーザデバイス110から情報を出力するメカニズムを含むことができる。入力メカニズムおよび出力メカニズムの例は、ボタン(例えば、制御ボタン240、キーパッド250のキー、ジョイスティック等)を含み、また、データおよび制御コマンドをユーザデバイス110に入力する;スピーカ(例えば、スピーカ220)が電気信号を受信し、オーディオ信号を出力する;マイクロフォン(例えば、マイクロフォン260)がオーディオ信号を受信し、電気信号を出力する;ディスプレイ(例えば、ディスプレイ230)がビジュアル情報(例えば、ユーザデバイス110に入力されるテキスト)を出力する、および/またはバイブレータがユーザデバイス110を振動させるようにすることを許容することができる。
【0049】
通信インタフェース340は、例えば、処理ロジック310からのベースバンド信号を無線周波数(RF:radio frequency)信号に変換することができる送信機、および/またはRF信号をベースバンド信号に変換することができる受信機を含むことができる。選択的には、通信インタフェース340は、送信機および受信機の両方の機能を実行するための送受信機を含むことができる。通信インタフェース340は、RF信号の送信および/または受信のためにアンテナアセンブリ350に接続することができる。アンテナアセンブリ350は、空中を介して、RF信号を送信および/または受信する1つまたは複数のアンテナを含むことができる。アンテナアセンブリ350は、例えば、通信インタフェース340からRF信号を受信し、かつ空中を介してRF信号を送信し、そして、空中を介してRF信号を受信し、そのRF信号を通信インタフェース340に提供することができる。一実装では、例えば、通信インタフェース340は、ネットワーク140等のネットワークと通信することができる。
【0050】
以下で詳細に記載されるように、ユーザデバイス110は、メモリ320等のコンピュータ読取可能媒体に含まれるアプリケーションのソフトウェア命令を実行する処理ロジック310に応じて一定の動作を実行することができる。コンピュータ読取可能媒体は、物理メモリデバイスまたは論理メモリデバイスおよび/または搬送波として定義することができる。ソフトウェア命令は、別のコンピュータ可読媒体から、または、通信インタフェース340を介して別のデバイスから、メモリ320に読み込むことができる。メモリ320に含まれるソフトウェア命令は、処理ロジック310が後述するプロセスを実行させることができる。選択的には、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて配線回路を使用して、本明細書に記載されるプロセスを実現することができる。従って、本明細書に記載される実装は、ハードウェア回路とソフトウェアの特定の組み合わせに限定されるものではない。
【0051】
図3はユーザデバイス110の例示的構成要素を示している。他の実装では、ユーザデバイス110は、図3に示される構成要素よりもさらに少ない、異なるまたは追加の構成要素を含むことができる。なおさらにさらに他の実装では、ユーザデバイス110の1つまたは複数の構成要素は、ユーザデバイス110の1つまたは複数の他の構成要素によって実行されるタスクを実行することができる。
【0052】
例示的クライアント/サーバ構成
図4は、サーバ120またはクライアント130に対応するクライアント/サーバエンティティの例示図である。図示されるように、クライアント/サーバエンティティは、バス410、処理ユニット420、メインメモリ430、ROM440、ストレージデバイス450、入力デバイス460、出力デバイス470および/または通信インタフェース480を含むことができる。バス410は、クライアント/サーバエンティティの構成要素間の通信を許容するパスを含むことができる。
【0053】
処理ユニット420は、プロセッサ、マイクロプロセッサ、または命令を解釈、実行することができる他のタイプの処理ロジックを含むことができる。メインメモリ430は、RAMまたは処理ユニット420による実行のための情報および命令を記憶することができる別のタイプの動的ストレージデバイスを含むことができる。ROM440は、ROMデバイス、または処理ユニット420による使用のための静的情報および/または命令を記憶することができる別のタイプの静的ストレージデバイスを含むことができる。ストレージデバイス450は、磁気および/または光記録媒体およびそれに対応する駆動装置を含むことができる。
【0054】
入力デバイス460は、オペレータが、キーボード、マウス、ペン、マイクロフォン、音声認識および/または生体測定メカニズム等のクライアント/サーバエンティティに情報を入力することを許容するメカニズムを含むことができる。出力デバイス470は、オペレータに情報を出力する、ディスプレイ、プリンタ、スピーカ等を含むメカニズムを含むことができる。通信インタフェース480は、クライアント/サーバエンティティが他のデバイスおよび/またはシステムと通信することを可能にする、送受信機の類のメカニズムを含むことができる。例えば、通信インタフェース480は、ネットワーク140等のネットワークを介して、別のデバイスまたはシステムと通信するメカニズムを含むことができる。
【0055】
以下で詳細に記載されるように、クライアント/サーバエンティティは、メインメモリ430等のコンピュータ読取可能媒体に含まれるソフトウェア命令を実行する処理ユニット420に応じて一定の動作を実行することができる。このソフトウェア命令は、ストレージデバイス450等の別のコンピュータ読取可能媒体、または通信インタフェース480を介して別のデバイスから、メインメモリ430に読み込むことができる。メインメモリ430に含まれるソフトウェア命令は、処理ユニット420に後述する処理を実行させるようにすることができる。選択的には、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて配線回路を使用して、本明細書に記載されるプロセスを実装することができる。従って、本明細書に記載される実装は、ハードウェア回路とソフトウェアの特定の組み合わせに限定されるものではない。
【0056】
図4は、クライアント/サーバエンティティの例示的構成要素を示している。他の実装では、クライアント/サーバエンティティは、図4に示される構成要素よりもさらに少ない、異なるまたは追加の構成要素を含むことができる。なおさらに他の実装では、クライアント/サーバエンティティの1つまたは複数の構成要素は、クライアント/サーバエンティティの1つまたは複数の他の構成要素によって実行されるタスクを実行することができる。
【0057】
例示的クライアント/サーバの動作
図5は、クライアント130によって提供することができる例示的表示500の図である。図5の左側に示されるように、ユーザは、クライアント130を介して(例えば、サーバ120によって提供される)セキュアリソースへのアクセスをリクエストすることができる。例えば、ユーザは、企業のイントラネット、セキュアサーバ、セキュアネットワーク内において提供されるアプリケーション、クレジットまたはデビットカード、建物、車両等へのアクセスをリクエストすることができる。認証例では、クライアント130は、検証電話番号の入力を可能にするメカニズム510、および入力された検証電話番号の提出を可能にする提出メカニズム520を含むディスプレイを提供することができる。メカニズム510は、例えば、入力フィールド、電話番号の選択を提供するドロップ−ダウンメニュー、および/または他の同様の入力メカニズムを含むことができる。提出メカニズム520は、ユーザがメカニズム520に覆いかぶさるまたはメカニズム520をクリックする場合に選択することができるメカニズム(例えば、アイコン、リンク、ボタンおよび/または他の同様の選択メカニズム)を含むことができる。
【0058】
セキュアリソースリクエスト、およびメカニズム510によって入力される検証電話番号は、サーバ120によって受信することができ、また、以下の図6に関して記載されるように、サーバ120は、ユーザデバイス110と共に検証機能を実行することができる。サーバ120は、検証電話番号を認証メカニズム(例えば、ユーザ名、パスワード、PIN等)と関連付けることができる。図5の中央に示されるように、サーバ120がユーザデバイス110と共に検証機能を実行中である場合、クライアント130は、クライアント130がセキュアリソースへのアクセスを待機していることを示す情報530を表示することができる。図5の右側に示されるように、サーバ120が検証機能を完了した後、クライアント130は、セキュアリソースへのアクセスが許可されるかまたは拒否されるかを示す情報540を表示することができる。
【0059】
図5には示されないが、トランザクション例では、ユーザは、クライアント130を介して(例えば、サーバ120によって提供される)セキュアリソースを使用するための認可をリクエストすることができる。サーバ120は、セキュアリソースをユーザデバイス110に関係する電話番号およびパブリックキーと関連付けることができ、以下で図6に関して記載されるように、ユーザデバイス110と共に検証機能を実行することができる。サーバ120がユーザデバイス110と共に検証機能を実行中である場合、クライアント130は、クライアント130がセキュアリソースを使用するための認可を待機していることを示す(例えば、情報530と同様の)情報を表示することができる。例えば、ユーザがクレジット・カード・トランザクションの認可をリクエスト中である場合、クライアント130は、クレジット・カード・トランザクションが認可を待機していることを示す情報を表示することができる。サーバ120が検証機能を完了した後、クライアント130は、ユーザがセキュアリソースを使用することが認可されることを示す(例えば、情報540と同様の)情報を表示することができる。
【0060】
図5は、クライアント130の例示的表示500を示している。他の実装では、クライアント130は、図5に示される表示よりさらに少ない、異なるまたは追加表示を提供することができる。なおさらにさらに他の実装では、図5の例示的表示500は、図5に示される表示よりさらに少ない、異なるまたは追加要素を含むことができる。
【0061】
例示的ユーザデバイス/サーバ動作
図6は、ユーザデバイス110によって提供することができる例示的表示600の図である。図6の左側に示されるように、ユーザがクライアント130を介して(例えば、サーバ120によって提供される)セキュアリソースへのアクセスをリクエストする場合、サーバ120は、SMS信号(例えば、図1のSMS信号160)を生成することができる。認証例では、SMS信号は、検証電話番号およびユーザに関連付けられているユーザデバイス110によって受信することができ、また、セキュアセッションは、ユーザデバイス110とサーバ120との間で確立することができる。ユーザデバイス110は、SMS信号の受信を示す情報610(例えば、アイコン、リンク等)を表示することができる。図6の中央に示されるように、ユーザデバイス110のユーザが(例えば、情報610に覆いかぶさるまたは情報610をクリックすることによって)情報610を選択する場合、ユーザデバイス110は、SMS信号の内容を表示することができる。SMS信号の内容は、例えば、セキュアリソースへのアクセスの検証処理を開始するためのアドレス630(例えば、ユニフォーム・リソース・ロケータ(URL:Uniform Resource Locator)の選択をユーザにリクエストする情報620を含むことができる。
【0062】
認証例では、SMS信号は、リクエストされたセキュアリソースの記述、およびサーバ120によって維持されるダウンロード可能なアプリケーション(例えば、ジャバミッドレット(Java midlet))へのURLを含むことができる。サーバ120によって維持される各ダウンロード可能なアプリケーションは、プライベートキーフィールドを伴うデータセグメントを含むことができ、また、データセグメントを、セキュリティ目的のため(例えば、ハッキングを防止するため)に暗号化することができる。サーバ120は、(例えば、ユーザデバイス110の)検証電話番号のリストを、対応するダウンロード可能なアプリケーション(およびその対応する認証メカニズム)と関連付けて、検証電話番号と対応する認証メカニズムとのペアを作成することができる。ダウンロード可能なアプリケーションが開始される場合(例えば、ユーザがアドレス630を選択する場合)、ユーザデバイス110は、サーバ120とコンタクトして、サーバ120とセキュア通信を開始することができる。例えば、ユーザデバイス110は、セキュアソケット接続(または他のタイプのセキュア接続)を経て、自身の電話番号をサーバ120に提供することができる。
【0063】
セキュア通信がユーザデバイス110とサーバ120との間で確立される場合、サーバ120は、多様な情報をユーザデバイス110に提供して、検証処理を支援することができる。例えば、図6の右側に示されるように、ユーザデバイス110は、リクエストされたセキュアリソースの記述を提供する情報640、認証メカニズムの入力を可能にするメカニズム650、セキュアリソースへのアクセスが許可されるかまたは拒否されるかを問い合わせる情報660、および入力した認証メカニズムの提出を可能にする2つの提出メカニズム(例えば、YES(肯定)メカニズム670およびNO(否定)メカニズム680)、並びにアクセスが許可または拒否されるかの決定を表示することができる。メカニズム650は、例えば、入力フィールド、認証メカニズムの選択を提供するドロップ−ダウンメニューおよび/または他の同様の入力メカニズムを含むことができる。提出メカニズム670および680は、ユーザが提出メカニズム670および680に覆いかぶさるまたは提出メカニズム670および680をクリックする場合に選択することができるメカニズム(例えば、アイコン、リンク、ボタンおよび/または他の同様の選択メカニズム)を含むことができる。他の実装では、ユーザデバイス110に関連付けられている認証メカニズムを自動的に生成することができ(例えば、肯定メカニズム670が選択される場合)、メカニズム650を省略することができる。
【0064】
ユーザデバイス110のユーザがセキュアリソースへのアクセスの提供を要望する場合、ユーザは(例えば、メカニズム650を介して、またはユーザデバイス110で自動的に)認証メカニズムを提供することができ、そして、YESメカニズム670を選択することができる。サーバ120は、ユーザデバイス110から認証メカニズムを受信することができ、次に、セキュアリソースへのアクセスを許可または拒否するかを判定するために、認証メカニズムを検証することができる。例えば、サーバ120は、ユーザに、クライアント130を介してサーバ120によって提供されるセキュアリソースへのアクセスを許可することができる。ユーザデバイスのユーザが、セキュアリソースへのアクセスを拒否することを要望する場合、ユーザは、メカニズム650を介する情報の提供を省略および/またはNOメカニズム680を選択することができる。サーバ120は、この情報に基づいて、および/または認証メカニズムが検証されない場合、セキュアリソースへのアクセスを拒否することができる。
【0065】
ユーザが2度目に同一のセキュアリソースへのアクセスを試行する場合(例えば、ユーザがセキュアなウェブサイトに2度目にログインすることを試行する)、サーバ120は、ダウンロード可能なアプリケーション(例えば、ジャバミッドレット)がユーザデバイス110上で実行中であるかを確認するためのチェックを行うことができる。ジャバミッドレットが、ユーザデバイス110上で動作中である場合、認証処理(例えば、プライベートキーのリクエスト)を直ちに開始することができる。ジャバミッドレットがユーザデバイス110上で動作中でない場合、SMS信号は、ユーザデバイス110に送信することができ、上記の認証処理を開始することができる。
【0066】
図6には示されないが、トランザクション例では、サーバ120は、セキュアリソースおよび/またはセキュアリソースリクエストを、ユーザデバイス110に関連するする電話番号およびパブリックキーと関連付けることができる。サーバ120は、サーバ120とのセキュアセッションを確立する(アドレス630と同様の)ためのアドレスを含むSMS信号をユーザデバイス110に送信することができる。セキュアセッションがサーバ120とユーザデバイス110との間で確立される場合、サーバ120は、ユーザデバイス110に(そして、ユーザデバイス110が表示することができる)、(情報640と同様の)セキュアリソースの記述、認可をリクエストするユーザ(例えば、個人、デバイス等)、(情報660ならびに提出メカニズム670および680と同様の)ユーザによるセキュアリソースの使用を認可するためのリクエスト、および/またはリクエストを特定する乱数を送信することができる。プライベートキーによりセキュアリソースの記述に電子的に署名し、その署名した記述および乱数をサーバ120に送信することによって、セキュアリソースリクエストを、ユーザデバイス110を介して認可することができる。他の実装では、セキュアリソースリクエストは、認可のためにプライベートキーを利用することができる他のメカニズムにより認可することができる。
【0067】
セキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイス110に関連付けられているパブリックキーにより、および/または受信した乱数をオリジナルの乱数と比較することによって、サーバ120は署名されたセキュアリソースの記述を検証することができる。例えば、署名された記述がサーバ120によって検証される場合、(例えば、クライアント130を介する)リクエスタはセキュアリソースを使用するための認可を受信することができる。
【0068】
本明細書に記載される実装は、検証電話番号と、各ダウンロード可能なアプリケーションに対応する認証メカニズムとのペアリングを検討するが、他の実装では、そのようなペアリングを省略することができ、また、セキュアリソースへのアクセスをリクエストするユーザは、ユーザデバイス110の検証から必要とされるキーコード(例えば、数字、文字、または数字または文字の組み合わせ)を提供することができる。
【0069】
さらに、本明細書に記載される実装はSMS信号の提供を検討するが、他の実装では、SMS信号とは別の信号を使用することができる。例えば、インターネットプロトコル(IP:Internet Protocol)マルチメディアサブシステム(IMS:IP Multimedia Subsystem)信号、ジャバー(Jabber)信号、または別のIPベースの信号を使用することができる。IPベースの信号が使用される場合、ユーザデバイス110は自動的にサーバ120に接続することができ、また、適切なプロトコル(例えば、IMSの場合におけるセッション開始プロトコル(SIP:Session Initiation Protocol)、ジャバーの場合における拡張メッセージングおよびプレゼンスプロトコル(XMPP:Extensible Messaging and Presence Protocol)等)を使用して、サーバ120はユーザデバイス110とコンタクトすることができる。サーバ120にそのIPアドレスを提供するユーザデバイス110以外には、ユーザデバイス110のIPアドレスが未知である場合、SMS信号の使用は有利でありうる。このSMS信号は、従って、未知のユーザデバイス110とサーバ120との間で通信を開始することができる。
【0070】
なおさらに、本明細書に記載される実装は、チャットセッションをユーザデバイス110(例えば、携帯電話機)からクライアント130(例えば、クライアント130に提供されるウェブインターフェース)に送信するために使用することができる。これは、本明細書に記載される実装をチャットアプリケーションに組み込むことによって実現することができる。ユーザがチャットをクライアント130に送信することを要望する場合、ユーザは、クライアント130のウェブインターフェースにおいてユーザデバイス110の電話番号を入力することができ、ここで、クライアント130は、ユーザがチャットをクライアント130のウェブインターフェースに送信することを要望するかをユーザに問い合わせ、ユーザデバイス110においてダイアログを起動することができる。
【0071】
図6は、ユーザデバイス110の例示的表示600を示している。他の実装では、ユーザデバイス110は、図6に示される表示よりもさらに少ない、異なるまたは追加の表示を提供することができる。なおさらに他の実装では、図6の例示的表示600は、図6に示される表示よりもさらに少ない、異なるまたは追加の要素を含むことができる。
【0072】
例示的処理
図7乃至図11は、本明細書に記載される実装に従う例示的処理のフローチャートを示している。一般的に、図7は、サーバ120によって実行することができる例示的認証処理700を示し、図8は、サーバ120によって実行することができる例示的トランザクション処理800を示し、図9は、ユーザデバイス110によって実行することができる例示的認証処理900を示し、図10は、ユーザデバイス110によって実行することができる例示的トランザクション処理1000を示し、図11は、クライアント130によって実行することができる例示的処理1100を示している。処理700−1100は、ユーザデバイス110、サーバ120、クライアント130またはユーザデバイス110、サーバ120および/またはクライアント130の組み合わせにおける、ハードウェアおよび/またはソフトウェア構成要素によって実行することができる。
【0073】
認証処理(サーバ)
図7に示されるように、処理700はセキュアリソースへアクセスするためのリクエストおよび/または検証電話番号の受信により開始することができる(ブロック710)。例えば、図5に関する上述の一実装例では、セキュアリソースリクエストおよびクライアント130のメカニズム510によって入力される検証電話番号は、サーバ120によって受信することができる。
【0074】
セキュアセッションを確立するために、SMS信号を検証電話番号に対して生成、送信することができる(ブロック720)。例えば、図6に関する上述の一実装例では、ユーザが、クライアント130を介して、(例えば、サーバ120によって提供される)セキュアリソースへのアクセスをリクエストする場合、サーバ120は、SMS信号(例えば、図1のSMS信号160)を生成することができる。SMS信号は、例えば、セキュアリソースアクセスの検証処理を開始するためのアドレス630(例えば、URL)の選択をユーザにリクエストする情報620を含むことができる。
【0075】
図7にさらに示されるように、検証電話番号は、認証メカニズムと関連付けることができる(ブロック730)。例えば、図5に関する上述の一実装例では、サーバ120は、検証電話番号を認証メカニズム(例えば、ユーザ名、パスワード、PIN等)と関連付けることができる。
【0076】
認証メカニズムは、セキュアリソースアクセスリクエストを検証するためにリクエストすることができる(ブロック740)。例えば、図6に関する上述の一実装例では、セキュア通信をユーザデバイス110とサーバ120との間で確立される場合、サーバ120は、多様な情報をユーザデバイス110に提供し、検証処理を支援することができる。一例では、サーバ120は、認証メカニズムの入力をリクエストするためのメカニズム650、セキュアリソースへのアクセスが許可されるまたは拒否されることになるかを問い合わせる情報660、および入力された認証メカニズムの提出を可能にする2つの提出メカニズム(例えば、YES(肯定)メカニズム670およびNO(否定)メカニズム680)、並びにアクセスを許可するかまたは拒否するかの決定を提供することができる。
【0077】
図7にさらに示されるように、認証メカニズムが受信される場合(ブロック750)、認証メカニズムを検証し(ブロック760)、検証に基づいて、セキュアリソースへのアクセスを許可することができる(ブロック770)。例えば、図6に関する上述の一実装例では、ユーザデバイス110のユーザがセキュアリソースへのアクセスを提供する(provide access:アクセスを受け付けてもらう)ことを要望する場合、ユーザは(例えば、メカニズム650による、またはユーザデバイス110により自動的に)認証メカニズムを提供することができる。サーバ120は、認証メカニズムをユーザデバイス110から受信することができ、例えば、受信した認証メカニズムと、検証電話番号と関連付けられている認証メカニズムとを比較することによって、認証メカニズムを検証することができる。サーバ120は、認証メカニズムの検証結果に基づいて、セキュアリソースへのアクセスを許可または拒否するかを判定することができる。
【0078】
トランザクション処理(サーバ)
図8に示されるように、処理800は、セキュアリソースへのアクセスを認可するためのリクエストの受信により開始することができる(ブロック810)。例えば、図1に関する上述の一実装例では、クライアント130は、セキュアリソースへのアクセスをリクエストするためのリクエスト150をサーバ120に送信することができる。
【0079】
セキュアリソースに関連付けられているユーザデバイスを判定することができる(ブロック820)。例えば、図6に関する上述の一実装例では、サーバ120は、セキュアリソースを、ユーザデバイス110に関連するする電話番号およびパブリックキーと関連付けることができる。
【0080】
図8にさらに示されるように、ユーザデバイスとのセキュアセッションを確立するために、SMS信号を生成することができる(ブロック830)。例えば、図6に関する上述の一実装例では、サーバ120は、ユーザデバイス110に、サーバ120とのセキュアセッションを確立するためのアドレスを含むSMS信号を送信することができる。SMS信号は、例えば、ユーザに、セキュアリソースへのアクセス検証処理を開始するためのアドレス630(例えば、URL)を選択することをリクエストする情報620を含むことができる。
【0081】
セキュアリソースの記述および署名用のリクエストを提供することができる(ブロック840)。例えば、図6に関する上述の一実装例では、セキュアセッションが、サーバ120とユーザデバイス110との間で確立される場合、サーバ120は、ユーザデバイス110に(そしてユーザデバイスが表示することができる)、(情報640と同様の)セキュアリソースの記述、認可をリクエストするユーザ(例えば、個人、デバイス等)、(情報660ならびに提出メカニズム670および680と同様の)ユーザによってセキュアリソースの使用を認可するためのリクエストおよび/またはリクエストを特定する乱数を送信することができる。
【0082】
図8にさらに示されるように、プライベートキーにより署名されたセキュアリソースの記述が受信される場合(ブロック850)、署名された記述をユーザデバイスに関連付けられているパブリックキーにより検証することができ(ブロック860)、また、その検証に基づいて、セキュアリソースを使用するための認可を許可または拒否することができる(ブロック870)。例えば、図6に関する上述の一実装例では、セキュアリソースの記述にプライベートキーにより電子的に署名し、その署名した記述および乱数をサーバ120に送信することによって、セキュアリソースリクエストをユーザデバイス110により認可することができる。セキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイス110に関連付けられているパブリックキーにより、および/または受信した乱数とオリジナルの乱数との比較によって、サーバ120は、署名されたセキュアリソースの記述を検証することができる。サーバ120は、サーバ120によって実行される検証の結果に基づいて、セキュアリソースを使用するための認可を許可または拒否することができる。
【0083】
認証処理(ユーザデバイス)
図9に示されるように、処理900は、セキュアセッションを確立するためのアドレスを含むSMS信号の受信により開始することができる(ブロック910)。例えば、図6に関する上述の一実装例では、SMS信号を、検証電話番号およびユーザと関連付けられているユーザデバイス110によって受信することができる。ユーザデバイス110は、SMS信号の受信を示す情報610(例えば、アイコン、リンク等)を表示することができる。ユーザデバイス110のユーザが(例えば、情報610に覆いかぶさるまたは情報610をクリックすることによって)情報610を選択する場合、ユーザデバイス110は、例えば、ユーザにアドレス630(例えば、URL)を選択することをリクエストする情報620を表示し、セキュアリソースへのアクセス検証処理を開始することができる。
【0084】
受信したアドレスに基づいてセキュアセッションが確立される場合(ブロック920)、アクセスすべきセキュアリソースの記述および/または認証メカニズムリクエストを受信することができる(ブロック930)。例えば、図6に関する上述の一実装例では、URLは、サーバ120によって保持されるダウンロード可能なアプリケーション(例えば、ジャバミッドレット)へのアドレスを提供することができる。ダウンロード可能なアプリケーションが開始される場合(例えば、ユーザがアドレス630を選択する場合)、ユーザデバイス110は、サーバ120とコンタクトし、サーバ120とのセキュア通信を開始することができる(例えば、ユーザデバイス110は、その電話番号をセキュアソケット接続を経てサーバ120に提供することができる)。セキュア通信がユーザデバイス110とサーバ120との間で確立される場合、ユーザデバイス110は、リクエストされたセキュアリソースの記述を提供する情報640、および認証メカニズムを入力するためのリクエスト(例えば、メカニズム650)を受信することができる。
【0085】
図9にさらに示されるように、認証メカニズムが提供される場合(ブロック940)、セキュアリソースへのアクセスを許可または拒否するかの指示を受信することができる(ブロック950)。例えば、図6に関する上述の一実装例では、ユーザデバイス110のユーザが、セキュアリソースへのアクセスを許可することを要望する場合、ユーザは(例えば、メカニズム650による、またはユーザデバイス110により自動的に)認証メカニズムを提供することができる。サーバ120は、認証メカニズムをユーザデバイス110から受信することができ、また、セキュアリソースへのアクセスを許可または拒否することを判定するために、認証メカニズムを検証することができる。他の実装では、ユーザデバイス110は、(例えば、サーバ120から)セキュアリソースへのアクセスが許可または拒否されているかの指示を受信することができる。
【0086】
トランザクション処理(ユーザデバイス)
図10に示されるように、処理100は、セキュアセッションを確立するためのアドレスを含むSMS信号の受信により開始することができる(ブロック1010)。例えば、図6に関する上述の一実装例では、SMS信号は、リクエストされたセキュアリソースに関連付けられているユーザデバイス110によって受信することができる。ユーザデバイス110は、SMS信号の受信を示す情報610(例えば、アイコン、リンク等)を表示することができる。ユーザデバイス110のユーザが(例えば、情報610に覆いかぶさるまたは情報610をクリックすることによって)情報610を選択する場合、ユーザデバイス110は、セキュアリソースへのアクセス検証処理を開始するために、例えば、ユーザにアドレス630(例えば、URL)を選択することをリクエストする情報620を表示することができる。
【0087】
セキュアセッションが受信したアドレスに基づいて確立される場合(ブロック1020)、アクセスすべきセキュアリソースの記述および/または署名のためのリクエストを受信することができる(ブロック1030)。例えば、図6に関する上述の一実装例では、セキュアセッションがサーバ120とユーザデバイス110との間で確立される場合、サーバ120は、ユーザデバイス110に(そして、ユーザデバイス110が表示することができる)、(情報640と同様の)セキュアリソースの記述、認可をリクエストするユーザ(例えば、個人、デバイス等)、(情報660ならびに提出メカニズム670および680と同様の)、(例えば、プライベートキーによる署名により)ユーザによってセキュアリソースの使用を認可するためのリクエスト、および/またはリクエストを特定する乱数を送信することができる。
【0088】
図10にさらに示されるように、セキュアリソースリクエストが認可される場合、セキュアリソースの記述は、プライベートキーにより署名することができる(ブロック1040)。例えば、図6に関する上述の一実装例では、ユーザデバイス110によりセキュアリソースの記述にプライベートキーにより電子的に署名することによって、セキュアリソースリクエストを認可することができる。
【0089】
プライベートキーにより署名されたセキュアリソースの記述を提供することができ(ブロック1050)、セキュアリソースへのアクセスを許可または拒否するかの指示を受信することができる(ブロック1060)。例えば、図6に関する上述の一実装例では、ユーザデバイス110は、署名した記述および乱数をサーバ120に送信することができる。ユーザデバイス110に関連付けられているパブリックキーにより、および/または受信した乱数とオリジナル乱数との比較によって、サーバ120は、署名されたセキュアリソースの記述を検証することができる。他の実装では、ユーザデバイス110は、(例えば、サーバ120から)セキュアリソースへアクセスするための認可が、許可または拒否されているかの指示を受信することができる。
【0090】
認証/トランザクション処理(クライアント)
図11に示されるように、処理1100は、セキュアリソースへのアクセスリクエストの送信により開始することができる(ブロック1110)。例えば、図5に関する上述の一実装例(例えば、認証およびトランザクション例)では、ユーザは、クライアント130を介して(例えば、サーバ120によって提供される)セキュアリソースへのアクセスをリクエストすることができる。一例では、ユーザは、企業のイントラネット、セキュアサーバ、セキュアネットワーク内で提供されるアプリケーション、クレジットまたはデビットカード、建物、車両等へのアクセスをリクエストすることができる。
【0091】
ユーザデバイスの検証電話番号を提供することができる(ブロック1120)。例えば、図5に関する上述の一実装例(例えば、認証例)では、クライアント130は、検証電話番号の入力を可能にするメカニズム510、および入力された検証電話番号の提出を可能にする提出メカニズム520を含む表示を提供することができる。セキュアリソースリクエストおよびメカニズム510によって入力される検証電話番号はサーバ120によって受信することができ、サーバ120は、ユーザデバイス110と共に検証機能を実行することができる。トランザクション例では、検証電話番号は提供される必要はない、これは、サーバ120がリクエストされたセキュアリソースを、ユーザデバイス110に関係する、電話番号およびパブリックキーと関連付けることができ、また、ユーザデバイス110による検証機能を実行することができるからである。
【0092】
図11にさらに示されるように、セキュアリソースへのアクセスまたはセキュアリソースへのアクセスの拒否は、ユーザデバイスの検証に基づいて、受信することができる(ブロック1130)。例えば、図5に関する上述の一実装例(例えば、認証およびトランザクション例)では、サーバ120が検証機能を完了した後、クライアント130は、セキュアリソースへのアクセスを許可または拒否するか、および/またはユーザにセキュアリソースを使用することを認可するかを示す情報540を(例えば、サーバ120から)受信し、表示することができる。
【0093】
結論
本明細書に記載される実装は、セキュアなユーザデバイスによって提供される認証および/または認可に基づいて、1つまたは複数のセキュアリソースへのアクセスを提供することができる。例えば、一実装では、ユーザデバイスは、PKIをサポートすることができるセルラー電話または携帯電話機に対応する。このユーザデバイスは、セキュアリソースへのアクセスを試行する別のデバイスに認証および/または認可を提供する2つの組のPKI信用証明を含むことができる。本明細書に記載される実装は、複数のパスワード、ユーザ名等を記憶する必要なく、任意のセキュアリソースにアクセスするための、簡単で、セキュアなシステムおよび方法を提供することができる。
【0094】
実装に関する上述の記述は、図示および説明を提供するものであるが、全てを網羅する、または本発明を開示する正確な形態に限定することを意図しない。修正および変形は、上記の教示に照らして可能であるか、または本発明の実施から得ることができる。
【0095】
例えば、図7乃至図11に関して一連の動作を記述しているが、動作順序は他の実装では変更することができる。さらに、従属関係のない動作は、平行して実行することができる。
【0096】
また、用語「ユーザ」が本明細書で使用されている。用語「ユーザ」は、クライアントおよび/またはユーザデバイスまたはクライアントのユーザおよび/またはユーザデバイスを含むと広く解釈することを意図する。
【0097】
上記のごとく、態様は図に示す実装では、多くの異なる形態のソフトウェア、ファームウェアおよびハードウェアにおいて実装することができることは明らかであろう。これらの態様を実装するために使用される実際のソフトウェアコードまたは特別な制御ハードウェアは、限定的なものと解釈すべきではない。従って、態様に関する動作および振る舞いは、特定のソフトウェアコードを参照することなく記述した−これは、ソフトウェアおよび制御ハードウェアは、本明細書の記述に基づいて態様を実装するように設計することができると理解される。
【0098】
本願で使用される要素、動作または命令は、明確にそのように記述しない限り本発明に極めて重要なものまたは本質的なものとして解釈されるべきではない。また、本明細書において使用されるように、冠詞「ある(a)」は、1つまたは複数の項目を含むことが意図される。ただ1つの項目が意図される場合では、用語「1つの(one)]または同様の言葉が使用される。さらに、熟語「基づいて(based on)」は、明確にそうでなく述べない限り、「少なくとも一部では基づいて(based, at least in part on)」を意味することが意図される。

【特許請求の範囲】
【請求項1】
第1のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストと、検証電話番号とを受信するステップと、
前記検証電話番号に関連付けられている第2のデバイスとのセキュアセッションを確立するステップと、
前記第2のデバイスから前記セキュアリソースリクエストを検証するための認証メカニズムをリクエストするステップと、
前記第2のデバイスからリクエストされた前記認証メカニズムが受信される場合、その受信した認証メカニズムを検証するステップと、
前記受信した認証メカニズムの検証に基づいて、前記セキュアリソースへのアクセスを前記第1のデバイスに許可するかまたは拒否するかを判定するステップと
を備えることを特徴とする方法。
【請求項2】
前記検証電話番号を前記認証メカニズムと関連付けるステップを更に備える
ことを特徴とする請求項1に記載の方法。
【請求項3】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記第2のデバイスに提供するステップと、
前記第2のデバイスが前記アドレスにアクセスする場合に、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項1に記載の方法。
【請求項4】
前記受信した認証メカニズムを検証するステップは、前記受信した認証メカニズムが、前記検証電話番号に関連付けられている認証メカニズムと整合するかを判定するステップを含む
ことを特徴とする請求項1に記載の方法。
【請求項5】
セキュアリソースを使用するためのセキュアリソースリクエストを受信するステップと、
前記セキュアリソースに関連付けられているデバイスを判定するステップと、
前記セキュアリソースに関連付けられている前記デバイスとのセキュアセッションを確立するステップと、
前記デバイスから前記セキュアリソースリクエストの認可をリクエストするステップと、
前記デバイスから前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証するステップと、
前記認可の検証に基づいて、前記セキュアリソースの使用を第1のデバイスに許可するかまたは拒否するかを判定するステップと
を備えることを特徴とする方法。
【請求項6】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記デバイスに提供するステップと、
前記デバイスが前記アドレスにアクセスする場合、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項5に記載の方法。
【請求項7】
前記認可をリクエストするステップは、
前記セキュアリソースの記述を前記デバイスに提供するステップと、
プライベートキーにより、前記デバイスによる前記記述の署名をリクエストするステップと
を備えることを特徴とする請求項5に記載の方法。
【請求項8】
前記認可を検証するステップは、前記デバイスに関連付けられているパブリックキーにより前記認可を検証するステップを含む
ことを特徴とする請求項5に記載の方法。
【請求項9】
第1のデバイス内で実行される方法であって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、前記セキュアセッションを確立するステップと、
前記セキュアリソースリクエストを認証するための認証メカニズムに対するリクエストを受信するステップと、
前記セキュアリソースリクエストが認証される場合、リクエストされた前記認証メカニズムを提供するステップと
を備えることを特徴とする方法。
【請求項10】
前記セキュアリソースへのアクセスを第2のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項9に記載の方法。
【請求項11】
前記認証メカニズムに対するリクエストを受信するステップは、前記セキュアリソースの記述を受信するステップを含む
ことを特徴とする請求項9に記載の方法。
【請求項12】
第1のデバイス内で実行される方法であって、
セキュアリソースを使用するためのセキュアリソースリクエストを第2のデバイスによって認可するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、前記セキュアセッションを確立するステップと、
前記セキュアリソースリクエストを認可するためのリクエストを受信するステップと
前記セキュアリソースリクエストが認可される場合、リクエストされた認可を提供するステップと
を備えることを特徴とする方法。
【請求項13】
前記セキュアリソースを使用するための認可を前記第2のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項12に記載の方法。
【請求項14】
前記認可するためのリクエストを受信するステップは、
前記セキュアリソースの記述を受信するステップと、
前記プライベートキーにより、前記記述を署名するためのリクエストを受信するステップと
を備えることを特徴とする請求項12に記載の方法。
【請求項15】
前記リクエストされた認可を提供するステップは、前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された前記記述を提供するステップを含む
ことを特徴とする請求項14に記載の方法。
【請求項16】
前記認可するためのリクエストを受信するステップは、
前記セキュアリソースの記述を受信するステップと、
前記セキュアリソースの使用をリクエストするユーザの識別情報を受信するステップまたは前記セキュアリソースリクエストを特定する乱数を受信するステップと
を備えることを特徴とする請求項12に記載の方法。
【請求項17】
第1のデバイス内で実行される方法であって、
セキュアリソースへのアクセスまたはセキュアリソースの使用をリクエストするステップと、
前記第1のデバイスに前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を認証する第2のデバイスを特定する検証電話番号を提供するステップと
前記第2のデバイスによって提供される認証に基づいて、前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を受け付けるステップと
を備えることを特徴とする方法。
【請求項18】
システムであって、
第1のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信する手段と
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するための、前記第1のデバイスとは異なる第2のデバイスとのセキュアセッションを確立する手段と、
前記第2のデバイスから、前記セキュアリソースリクエストの認可をリクエストする手段と、
前記第2のデバイスから、前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証する手段と、
前記認可の検証に基づいて、前記第1のデバイスに前記セキュアリソースへのアクセスを許可するかまたは拒否するかを判定する手段と
を備えることを特徴とするシステム。
【請求項19】
前記認可をリクエストする手段は、
前記セキュアリソースリクエストを検証するために、前記第2のデバイスから認証メカニズムをリクエストする手段と、またはプライベートキーにより、前記第2のデバイスによるセキュアリソースの記述の署名をリクエストする手段との1つを含む
ことを特徴とする請求項18に記載のシステム。
【請求項20】
前記認可を検証する手段は、前記第2のデバイスから受信される認証メカニズムが、前記第2のデバイスの検証電話番号に関連付けられている認証メカニズムに整合するかを判定する手段と、または前記第2のデバイスに関連付けられているパブリックキーによる認可を検証する手段の1つを含む
ことを特徴とする請求項18に記載のシステム。
【請求項21】
システムであって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信する手段と、
前記アドレスに基づいて、前記セキュアセッションを確立する手段と、
前記セキュアリソースリクエストを認可するためのリクエストを受信する手段と、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を提供する手段と
を備えることを特徴とするシステム。
【請求項22】
前記認可するためのリクエストを受信する手段は、前記セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を備える
ことを特徴とする請求項21に記載のシステム。
【請求項23】
前記リクエストされた認可を提供する手段は、前記セキュアリソースリクエストが認証される場合、前記リクエストされた認証メカニズムを提供する手段を備える
ことを特徴とする請求項22に記載のシステム。
【請求項24】
前記認可するためのリクエストを受信する手段は、
前記セキュアリソースの使用をリクエストするユーザの識別情報及び前記セキュアリソースリクエストを特定する乱数の少なくとも1つと前記セキュアリソースの記述とを受信する手段と、
プライベートキーにより、前記記述を署名するためのリクエストを受信する手段と
を備えることを特徴とする請求項21に記載のシステム。
【請求項25】
前記リクエストされた認可を提供する手段は、
前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された記述を提供する手段を備える
ことを特徴とする請求項24に記載のシステム。
【請求項26】
デバイスであって、
複数の命令を記憶するメモリと、
前記メモリの命令を実行するプロセッサとを備え、
前記プロセッサは、
前記第1のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストを受信し、
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するために、前記第1のデバイスとは異なる第2のデバイスとのセキュアセッションを確立し、
前記第2のデバイスから、前記セキュアリソースリクエストの認可をリクエストし、
前記セキュアリソースリクエストの認可が前記第2のデバイスから受信される場合、前記認可を検証し、
前記認可の検証に基づいて、前記セキュアリソースへのアクセスを前記第1のデバイスに許可するかまたは拒否するかを判定する
ための、前記メモリの命令を実行する
ことを特徴とするデバイス。
【請求項27】
デバイスであって、
複数の命令を記憶するメモリと
前記メモリの命令を実行する処理ロジックとを備え、
前記処理ロジックは、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第2のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信し、
前記アドレスに基づいて、前記セキュアセッションを確立し、
前記セキュアリソースリクエストを認可するためのリクエストを受信し、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を提供する
ための、前記メモリの命令を実行する
ことを特徴とするデバイス。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate


【公表番号】特表2010−519631(P2010−519631A)
【公表日】平成22年6月3日(2010.6.3)
【国際特許分類】
【出願番号】特願2009−550327(P2009−550327)
【出願日】平成19年8月22日(2007.8.22)
【国際出願番号】PCT/IB2007/053360
【国際公開番号】WO2008/102220
【国際公開日】平成20年8月28日(2008.8.28)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
【出願人】(502087507)ソニー エリクソン モバイル コミュニケーションズ, エービー (823)
【Fターム(参考)】