(57)【要約】  システムは、第１のデバイス（１３０）から、セキュアリソースへアクセスするためのセキュアリソースリクエスト（１５０）および検証電話番号を受信し、検証電話番号に関連付けられている第２のデバイス（１１０）とのセキュアセッションを確立し、セキュアリソースリクエストを検証するために第２のデバイスから認証メカニズム（１７０）をリクエストし、第２のデバイスからリクエストした認証メカニズムを受信する場合（１８０）、受信した認証メカニズムを検証し、受信した認証メカニズムの検証に基づいて、セキュアリソースへの第１のデバイスのアクセスを許可するかまたは拒否するかを判定する。
2010519631.tif 000002
【特許請求の範囲】
【請求項１】
第１のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストと、検証電話番号とを受信するステップと、
前記検証電話番号に関連付けられている第２のデバイスとのセキュアセッションを確立するステップと、
前記第２のデバイスから前記セキュアリソースリクエストを検証するための認証メカニズムをリクエストするステップと、
前記第２のデバイスからリクエストされた前記認証メカニズムが受信される場合、その受信した認証メカニズムを検証するステップと、
前記受信した認証メカニズムの検証に基づいて、前記セキュアリソースへのアクセスを前記第１のデバイスに許可するかまたは拒否するかを判定するステップと
を備えることを特徴とする方法。
【請求項２】
前記検証電話番号を前記認証メカニズムと関連付けるステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記第２のデバイスに提供するステップと、
前記第２のデバイスが前記アドレスにアクセスする場合に、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記受信した認証メカニズムを検証するステップは、前記受信した認証メカニズムが、前記検証電話番号に関連付けられている認証メカニズムと整合するかを判定するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項５】
セキュアリソースを使用するためのセキュアリソースリクエストを受信するステップと、
前記セキュアリソースに関連付けられているデバイスを判定するステップと、
前記セキュアリソースに関連付けられている前記デバイスとのセキュアセッションを確立するステップと、
前記デバイスから前記セキュアリソースリクエストの認可をリクエストするステップと、
前記デバイスから前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証するステップと、
前記認可の検証に基づいて、前記セキュアリソースの使用を第１のデバイスに許可するかまたは拒否するかを判定するステップと
を備えることを特徴とする方法。
【請求項６】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記デバイスに提供するステップと、
前記デバイスが前記アドレスにアクセスする場合、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項５に記載の方法。
【請求項７】
前記認可をリクエストするステップは、
前記セキュアリソースの記述を前記デバイスに提供するステップと、
プライベートキーにより、前記デバイスによる前記記述の署名をリクエストするステップと
を備えることを特徴とする請求項５に記載の方法。
【請求項８】
前記認可を検証するステップは、前記デバイスに関連付けられているパブリックキーにより前記認可を検証するステップを含む
ことを特徴とする請求項５に記載の方法。
【請求項９】
第１のデバイス内で実行される方法であって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、前記セキュアセッションを確立するステップと、
前記セキュアリソースリクエストを認証するための認証メカニズムに対するリクエストを受信するステップと、
前記セキュアリソースリクエストが認証される場合、リクエストされた前記認証メカニズムを提供するステップと
を備えることを特徴とする方法。
【請求項１０】
前記セキュアリソースへのアクセスを第２のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記認証メカニズムに対するリクエストを受信するステップは、前記セキュアリソースの記述を受信するステップを含む
ことを特徴とする請求項９に記載の方法。
【請求項１２】
第１のデバイス内で実行される方法であって、
セキュアリソースを使用するためのセキュアリソースリクエストを第２のデバイスによって認可するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、前記セキュアセッションを確立するステップと、
前記セキュアリソースリクエストを認可するためのリクエストを受信するステップと
前記セキュアリソースリクエストが認可される場合、リクエストされた認可を提供するステップと
を備えることを特徴とする方法。
【請求項１３】
前記セキュアリソースを使用するための認可を前記第２のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記認可するためのリクエストを受信するステップは、
前記セキュアリソースの記述を受信するステップと、
前記プライベートキーにより、前記記述を署名するためのリクエストを受信するステップと
を備えることを特徴とする請求項１２に記載の方法。
【請求項１５】
前記リクエストされた認可を提供するステップは、前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された前記記述を提供するステップを含む
ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記認可するためのリクエストを受信するステップは、
前記セキュアリソースの記述を受信するステップと、
前記セキュアリソースの使用をリクエストするユーザの識別情報を受信するステップまたは前記セキュアリソースリクエストを特定する乱数を受信するステップと
を備えることを特徴とする請求項１２に記載の方法。
【請求項１７】
第１のデバイス内で実行される方法であって、
セキュアリソースへのアクセスまたはセキュアリソースの使用をリクエストするステップと、
前記第１のデバイスに前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を認証する第２のデバイスを特定する検証電話番号を提供するステップと
前記第２のデバイスによって提供される認証に基づいて、前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を受け付けるステップと
を備えることを特徴とする方法。
【請求項１８】
システムであって、
第１のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信する手段と
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するための、前記第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立する手段と、
前記第２のデバイスから、前記セキュアリソースリクエストの認可をリクエストする手段と、
前記第２のデバイスから、前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証する手段と、
前記認可の検証に基づいて、前記第１のデバイスに前記セキュアリソースへのアクセスを許可するかまたは拒否するかを判定する手段と
を備えることを特徴とするシステム。
【請求項１９】
前記認可をリクエストする手段は、
前記セキュアリソースリクエストを検証するために、前記第２のデバイスから認証メカニズムをリクエストする手段と、またはプライベートキーにより、前記第２のデバイスによるセキュアリソースの記述の署名をリクエストする手段との１つを含む
ことを特徴とする請求項１８に記載のシステム。
【請求項２０】
前記認可を検証する手段は、前記第２のデバイスから受信される認証メカニズムが、前記第２のデバイスの検証電話番号に関連付けられている認証メカニズムに整合するかを判定する手段と、または前記第２のデバイスに関連付けられているパブリックキーによる認可を検証する手段の１つを含む
ことを特徴とする請求項１８に記載のシステム。
【請求項２１】
システムであって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信する手段と、
前記アドレスに基づいて、前記セキュアセッションを確立する手段と、
前記セキュアリソースリクエストを認可するためのリクエストを受信する手段と、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を提供する手段と
を備えることを特徴とするシステム。
【請求項２２】
前記認可するためのリクエストを受信する手段は、前記セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を備える
ことを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記リクエストされた認可を提供する手段は、前記セキュアリソースリクエストが認証される場合、前記リクエストされた認証メカニズムを提供する手段を備える
ことを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記認可するためのリクエストを受信する手段は、
前記セキュアリソースの使用をリクエストするユーザの識別情報及び前記セキュアリソースリクエストを特定する乱数の少なくとも１つと前記セキュアリソースの記述とを受信する手段と、
プライベートキーにより、前記記述を署名するためのリクエストを受信する手段と
を備えることを特徴とする請求項２１に記載のシステム。
【請求項２５】
前記リクエストされた認可を提供する手段は、
前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された記述を提供する手段を備える
ことを特徴とする請求項２４に記載のシステム。
【請求項２６】
デバイスであって、
複数の命令を記憶するメモリと、
前記メモリの命令を実行するプロセッサとを備え、
前記プロセッサは、
前記第１のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストを受信し、
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するために、前記第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立し、
前記第２のデバイスから、前記セキュアリソースリクエストの認可をリクエストし、
前記セキュアリソースリクエストの認可が前記第２のデバイスから受信される場合、前記認可を検証し、
前記認可の検証に基づいて、前記セキュアリソースへのアクセスを前記第１のデバイスに許可するかまたは拒否するかを判定する
ための、前記メモリの命令を実行する
ことを特徴とするデバイス。
【請求項２７】
デバイスであって、
複数の命令を記憶するメモリと
前記メモリの命令を実行する処理ロジックとを備え、
前記処理ロジックは、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信し、
前記アドレスに基づいて、前記セキュアセッションを確立し、
前記セキュアリソースリクエストを認可するためのリクエストを受信し、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を提供する
ための、前記メモリの命令を実行する
ことを特徴とするデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
個人は、他パーティのアクセスを制御された方法で潜在的に許可することを好むようないくつかのリソースを個人が所有することがある。信頼に値しない終端点（例えば、ネットワークに接続される非認証デバイス）から、組織の内部ネットワークリソースへのアクセスを組織は絶えず防止しようとする。個人および／または組織体は、セキュアリソースへのアクセスを動的に制御する、並びにセキュアリソースにアクセスしている時間または方法を制御することを要望することがあるいくつかの状況が存在しうる。例えば、個人は自身の子供が自身のクレジットカード（即ち、セキュアリソース）にアクセスすることを許容することはできるが、自身の子供がクレジットカードにより購入リクエストが行われる場合には、その通知を受け、トランザクションを認可することを好むであろう。別の例では、組織は、従業員が内部ネットワークのある部署にアクセスすることを許可することはできるが、同じ従業員が内部ネットワークの他部署にアクセスすることを拒否することがありうる。
【０００２】
一態様に従えば、方法は、第１のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストおよび検証電話番号を受信するステップ、検証電話番号に関連付けられている第２のデバイスとのセキュアセッションを確立するステップ、第２のデバイスからセキュアリソースリクエストを検証するための認証メカニズムをリクエストするステップ、第２のデバイスからリクエストされた認証メカニズムが受信される場合、受信した認証メカニズムを検証するステップ、および受信した認証メカニズムの検証に基づいて、セキュアリソースへのアクセスを第１のデバイスに許可するかまたは拒否するかを判定するステップを含むことができる。
【０００３】
加えて、本方法は、検証電話番号を認証メカニズムと関連付けるステップを含むことができる。
【０００４】
加えて、セキュアセッションを確立するステップは、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ：Short Message Service）信号を生成するステップ、そのＳＭＳ信号を第２のデバイスに提供するステップ、および第２のデバイスがアドレスにアクセスする場合、セキュアセッションを確立するステップを含むことができる。
【０００５】
加えて、受信した認証メカニズムを検証するステップは、受信した認証メカニズムが検証電話番号に関連付けられている認証メカニズムと整合するかを判定するステップを含むことができる。
【０００６】
別の態様に従えば、方法は、セキュアリソースを使用するためのリクエストを受信するステップ、セキュアリソースに関連付けられているデバイスを判定するステップ、セキュアリソースに関連付けられているデバイスとのセキュアセッションを確立するステップ、デバイスからセキュアリソースリクエストの認可をリクエストするステップ、デバイスからセキュアリソースリクエストの認可を受信する場合、認可を検証するステップ、および認可の検証に基づいて、セキュアリソースの使用を第１のデバイスに許可するかまたは拒否するかを判定するステップを含むことができる。
【０００７】
加えて、セキュアセッションを確立するステップは、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ）信号を生成するステップ、ＳＭＳ信号をデバイスに提供するステップ、およびデバイスがアドレスにアクセスする場合、セキュアセッションを確立するステップを含むことができる。
【０００８】
加えて、認可をリクエストするステップは、セキュアリソースの記述をデバイスに提供するステップ、およびプライベートキーにより、デバイスによる記述の署名をリクエストするステップを含むことができる。
【０００９】
加えて、認可を検証するステップは、デバイスに関連付けられているパブリックキーにより認可を検証するステップを含むことができる。
【００１０】
さらに別の態様に従えば、第１のデバイス内で実行される方法は、セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ）信号を受信するステップ、アドレスに基づいて、セキュアセッションを確立するステップ、セキュアリソースリクエストを認証するための認証メカニズムに対するリクエストを受信するステップ、およびセキュアリソースリクエストが認証される場合、リクエストされた認証メカニズムを提供するステップを含むことができる。
【００１１】
加えて、本方法は、セキュアリソースへのアクセスを第２のデバイスに許可するまたは拒否するかの指示を受信するステップを含むことができる。
【００１２】
加えて、認証メカニズムに対するリクエストを受信するステップは、セキュアリソースの記述を受信するステップを含むことができる。
【００１３】
さらなる態様に従えば、第１のデバイス内で実行される方法は、セキュアリソースを使用するためのセキュアリソースリクエストを第２のデバイスによって認可するために、セキュアセッションを確立するアドレスを含むショートメッセージサービス（ＳＭＳ）信号を受信するステップ、アドレスに基づいて、セキュアセッションを確立するステップ、セキュアリソースリクエストを認可するためのリクエストを受信するステップ、およびセキュアリソースリクエストが認可される場合、リクエストされた認可を提供するステップを含むことができる。
【００１４】
加えて、本方法は、セキュアリソースを使用するための認可を第２のデバイスに許可するかまたは拒否するかの指示を受信するステップを含むことができる。
【００１５】
加えて、認可するためのリクエストを受信するステップは、セキュアリソースの記述を受信するステップ、およびプライベートキーにより、記述を署名するためのリクエストを受信するステップを含むことができる。
【００１６】
加えて、リクエストされた認可を提供するステップは、セキュアリソースリクエストが認可される場合、プライベートキーにより署名された記述を提供するステップを含むことができる。
【００１７】
加えて、認可するためのリクエストを受信するステップは、セキュアリソースの記述を受信するステップ、セキュアリソースの使用をリクエストするユーザの識別情報を受信するステップまたはセキュアリソースリクエストを特定する乱数を受信するステップの少なくとも１つを含むことができる。
【００１８】
別の態様に従えば、第１のデバイス内で実行される方法は、セキュアリソースへのアクセスまたはセキュアリソースの使用をリクエストするステップ、第１のデバイスにセキュアリソースへのアクセスまたはセキュアリソースの使用を認証する第２のデバイスを特定する検証電話番号を提供するステップ、および第２のデバイスによって提供される認証に基づいて、セキュアリソースへのアクセス権またはセキュアリソースの使用権を受信するステップを含むことができる。
【００１９】
さらなる態様に従えば、システムは、第１のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信する手段、ショートメッセージサービス（ＳＭＳ）信号により、セキュアリソースへのアクセスを認可するための、第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立する手段、第２のデバイスからセキュアリソースリクエストの認可をリクエストする手段、第２のデバイスからセキュアリソースリクエストの認可が受信される場合、認可を検証する手段、および認可の検証に基づいて、第１のデバイスにセキュアリソースへのアクセスを許可するかまたは拒否するかを判定する手段を含むことができる。
【００２０】
加えて、認可をリクエストする手段は、セキュアリソースリクエストを検証するために、第２のデバイスから認証メカニズムをリクエストする手段、またはプライベートキーにより、第２のデバイスによるセキュアリソースの記述の署名をリクエストする手段の１つを含むことができる。
【００２１】
加えて、認可を検証する手段は、第２のデバイスから受信する認証メカニズムが第２のデバイスの検証電話番号に関連付けられている認証メカニズムに整合するかを判定する手段、または第２のデバイスに関連付けられているパブリックキーによる認可を検証する手段の１つを含むことができる。
【００２２】
なおさらに別の態様に従えば、システムは、セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ）信号を受信する手段、アドレスに基づいて、セキュアセッションを確立する手段、セキュアリソースリクエストを認可するためのリクエストを受信する手段、およびセキュアリソースリクエストが認可される場合、リクエストされた認可を提供する手段を含むことができる。
【００２３】
加えて、リクエストを受信する手段は、セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を含むことができる。
【００２４】
加えて、リクエストされた認可を提供する手段は、セキュアリソースリクエストが認証される場合、リクエストされた認証メカニズムを提供する手段を含むことができる。
【００２５】
加えて、認可するためのリクエストを受信する手段は、セキュアリソースの記述と、セキュアリソースの使用をリクエストするユーザの識別情報またはセキュアリソースリクエストを特定する乱数の少なくとも１つを受信する手段と、およびプライベートキーにより、記述を署名するためのリクエストを受信する手段を含むことができる。
【００２６】
加えて、リクエストされた認可の提供する手段は、セキュアリソースリクエストが認可される場合、プライベートキーにより署名された記述を提供する手段を含むことができる。
【００２７】
別の態様に従えば、デバイスは、複数の命令を記憶するメモリおよびメモリの命令を実行するプロセッサを含むことができる。プロセッサは、第１のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信し、ショートメッセージサービス（ＳＭＳ）信号によりセキュアリソースへのアクセスを認可するために、第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立し、第２のデバイスから、セキュアリソースリクエストの認可をリクエストし、セキュアリソースリクエストの認可が第２のデバイスから受信される場合、認可を検証し、認可の検証に基づいて、第１のデバイスにセキュアリソースへのアクセスを許可するかまたは拒否するかを判定することができる。
【００２８】
なおさらに別の態様に従えば、デバイスは、複数の命令を記憶するメモリおよびメモリの命令を実行する処理ロジックを含むことができる。処理ロジックは、セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ）信号を受信し、アドレスに基づいて、セキュアセッションを確立し、セキュアリソースリクエストを認可するためのリクエストを受信し、セキュアリソースリクエストが認可される場合、リクエストされた認可を提供することができる。
【００２９】
本明細書に組込み、その一部を構成する添付図面は本明細書に記述する１つまたは複数の実装を図示し、記述と共にこれらの実装を説明する：
【図面の簡単な説明】
【００３０】
【図１】本明細書において記載されるシステムおよび方法を実装することができるネットワークの例示図である。
【図２】図１のユーザデバイスの例示的前面図である。
【図３】図２のユーザデバイスの例示的構成要素図である。
【図４】図１のクライアントまたはサーバの例示図である。
【図５】図１のクライアントによって提供される例示的表示図である。
【図６】図１のユーザデバイスによって提供される例示的表示図である。
【図７】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図８】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図９】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図１０】本明細書に記載される実装による例示的処理を示すフローチャートである。
【図１１】本明細書に記載される実装による例示的処理を示すフローチャートである。
【発明を実施するための形態】
【００３１】
以下の詳細な記述は、添付する図面を参照する。種々の図面における同一の参照番号は、同一のまたは類似の要素を特定することがある。また、以下の詳細な記述は、本発明を限定するものではない。
【００３２】
概要
本明細書に記載される実装は、セキュアな（secure：安全な）ユーザデバイスによって提供される認証および認可の少なくとも一方に基づいて、１つまたは複数のセキュアリソースへのアクセス権を提供することができる。例えば、一実装では、ユーザデバイスは、パブリックキーンフラストラクチャ（ＰＫＩ：public key infrastructure）をサポートすることができるセルラーまたは携帯電話機に対応する。ユーザデバイスは、セキュアリソース（例えば、セキュアネットワークに提供されているサーバ）へのアクセスを試行する別のデバイス（例えば、クライアントデバイス）の認証および認可の少なくとも一方を提供する２つの組のＰＫＩ信用証明（例えば、プライベートキーおよびパブリックキー、あるいは証明書）を含むことができる。ユーザデバイスのユーザは、クライアントのユーザと同一である、またはクライアントのユーザとは異なる。
【００３３】
一実装（以下では、「認証例」と呼ぶ）では、デバイス（例えば、クライアント）のユーザは、セキュアリソース（例えば、セキュアネットワークのサーバによって提供されるアプリケーション）へのアクセスをリクエストすることができる。ユーザは、クライアントを通じて、ユーザを認証する検証電話番号を提供することができる。セキュアリソースリクエストおよび検証電話番号は、サーバによって受信することができ、また、サーバは、サーバとのセキュアセッションを確立するためのアドレスを含むショートメッセージサービス（ＳＭＳ）信号を生成することができる。ＳＭＳ信号は、検証電話番号およびユーザとに関連付けられているユーザデバイスに提供することができ、セキュアセッションをサーバと確立することができる。サーバは、検証電話番号を認証メカニズム（例えば、ユーザ名、パスワード、個人識別番号（ＰＩＮ：personal identification number）等）と関連付けることができ、セキュアリソースリクエストを検証するために、認証メカニズムをユーザデバイスからリクエストすることができる。ユーザデバイスは、認証メカニズムをサーバに提供することができ、また、サーバは、クライアントがセキュアリソースへアクセスすることを許可するまたは拒否するかを判定するために、認証メカニズムを検証することができる。例えば、ユーザデバイスがリクエストされた認証メカニズムを提供する場合、ユーザに、クライアントを通じて、サーバによって提供されるセキュアリソースへのアクセスを許可することができる。
【００３４】
別の実装（以下では、「トランザクション例」と呼ぶ）では、個人（例えば、従業員）はデバイス（例えば、クライアント）を通じてセキュアリソース（例えば、管理者による認可をリクエストすることができるセキュアサーバのアプリケーション）の使用認可をリクエストすることができる。サーバは、セキュアリソースをユーザデバイスに（例えば、管理者のユーザデバイスに）に関連する、電話番号およびパブリックキーと関連付けることができる。サーバは、ユーザデバイスに。サーバとのセキュアセッションを確立するためのアドレスを含むＳＭＳ信号を送信することができる。セキュアセッションがサーバとユーザデバイスとの間で確立される場合、サーバは、ユーザデバイスにセキュアリソースの記述（description）、認可をリクエストする従業員、従業員によるセキュアリソースの使用を認可するためのリクエスト、およびリクエストを識別する乱数の少なくとも１つを送信することができる。セキュアリソースの記述にプライベートキーにより電子的に署名し、その署名した記述および乱数をサーバに送信することによって、管理者はユーザデバイスを通じてセキュアリソースリクエストを認可することができる。ユーザにセキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイスと関連付けられているパブリックキーにより、および／または受信した乱数と元々の乱数との比較によって、サーバは署名されたセキュアリソースの記述を検証することができる。例えば、署名された記述が検証される場合、従業員は、クライアントを通じて、セキュアリソースを使用するための認可を受信することができる。
【００３５】
本明細書において使用される「セキュアリソース（secure resource）」という用語、以下のものを含むように広く解釈される。これには、任意のネットワーク、デバイス、アプリケーション、プロパティおよび／またはネットワークの組み合わせ、デバイス群、アプリケーション群および／またはアクセスを制御することができるプロパティを含んでいる。例えば、セキュアリソースは、セキュアネットワークまたはプライベートネットワーク、イントラネット、ローカルネットワーク、アプリケーション群および／またはセキュアネットワークに提供されるデバイス、イントラネットまたはローカルネットワーク、クレジットカード、車両（例えば、自動車、トラック、航空機、ボート等）、建物、パーソナル・ウェブ・ページ、電子メールアカウント、ログイン、パスワード、ユーザ名、等をリクエストする任意のウェブサイト、および／または任意の他のネットワーク、デバイス、アプリケーションおよび／または認可および／または認証をリクエストすることができるプロパティを含むことができる。
【００３６】
例示的ネットワーク構成
図１は、本明細書で記載されるシステムおよび方法を実装することができるネットワーク１００の例示図である。ネットワーク１００は、ネットワーク１４０を介して接続される、ユーザデバイス１１０、サーバ１２０およびクライアント１３０を含むことができる。簡略のため、１つのユーザデバイス１１０、１つのサーバ１２０および１つのクライアント１３０がネットワーク１４０に接続されているに示している。実際には、さらに多くのユーザデバイス群、サーバ群および／またはクライアント群が存在していても良い。また、いくつかの例では、ユーザデバイスは、サーバの１つまたは複数の機能を実行することができ、サーバは、ユーザデバイスの１つまたは複数の機能を実行することができる。他の例では、クライアントは、サーバの１つまたは複数の機能を実行することができ、サーバは、クライアントの１つまたは複数の機能を実行することができる。
【００３７】
ユーザデバイス１１０は、１つまたは複数のエンティティを含むことができる。エンティティは、電話機、セルラーフォン（例えば、無線アプリケーションプロトコル（ＷＡＰ：Wireless Application Protocol）アプリケーション等のインターネットベースのアプリケーションを提供する）、パーソナルコンピュータ、パーソナル・デジタル・アシスタント（ＰＤＡ：personal digital assistant）、ラップトップまたは別のタイプの計算デバイスまたは通信デバイス、これらのデバイスの１つにおいて実行するスレッドあるいはプロセス、および／またはこれらのデバイスの１つによって実行可能なオブジェクト等のデバイスとして定義することができる。一実装では、ユーザデバイス１１０は、本明細書で記載されるように、１つまたは複数のセキュアリソースの認可および認証の少なくとも一方を提供することができる。
【００３８】
サーバ１２０は、本明細書に記載されるように、情報を収集、処理、検索および提供の少なくとも１つを実行する１つまたは複数のサーバエンティティを含むことができる。例えば、一実装では、サーバ１２０は、１つまたは複数のセキュアリソース、および／または、本明細書で記載されるように、１つまたは複数のセキュアリソースの認可／認証を提供することができる。
【００３９】
クライアント１３０は、電話機、セルラーフォン（例えば、ＷＡＰアプリケーション等のインターネットベースのアプリケーションを提供する）、パーソナルコンピュータ、ＰＤＡ、ラップトップ、カード認可デバイス（例えば、クレジットまたはデビットカード認可デバイス、キーフォッブ等）、または別のタイプの計算または通信デバイス、これらのデバイスの１つにおいて実行されるスレッドあるいはプロセス、および／またはこれらのデバイスの１つによって実行可能なオブジェクト等の１つまたは複数のエンティティを含むことができる。一実装では、クライアント１３０は、本明細書に記載されるように、セキュアリソースへのアクセスおよび／またはセキュアリソースの使用認可をリクエストすることができる。他の実装では、クライアント１３０は、第２のユーザデバイス１１０に対応する。
【００４０】
ネットワーク１４０は、ローカル・エリア・ネットワーク（ＬＡＮ：local area network）、ワイド・エリア・ネットワーク（ＷＡＮ：wide area network）、メトロポリタン・エリア・ネットワーク（ＭＡＮ：metropolitan area network）、公衆交換電話ネットワーク（ＰＳＴＮ：Public Switched Telephone Network）またはセルラー電話ネットワーク等の電話ネットワーク、イントラネット、インターネット、またはネットワークの組み合わせを含むことができる。ユーザデバイス１１０、サーバ１２０およびクライアント１３０は、有線および／または無線接続によりネットワーク１４０に接続することができる。
【００４１】
図１は、ネットワーク１００の例示的構成要素を示している。他の実装では、ネットワーク１００は、図１に示される構成要素より、さらに少ない、異なる、または追加の構成要素を含んでも良い。
【００４２】
図１にさらに示されるように、例示的動作では、クライアント１３０は、セキュアリソースへアクセスするためのリクエスト１５０をサーバ１２０に送信することができる。認証例では、クライアント１３０は、リクエスト１５０と共にユーザデバイス１１０の検証電話番号を提供することができる。この検証電話番号は、クライアント１３０のユーザを認可および／または認証するために利用することができる。トランザクション例では、サーバ１２０は、リクエスト１５０のセキュアリソースと関連付けられているユーザデバイス（例えば、ユーザデバイス１１０）を判定することができる。サーバ１２０は、ユーザデバイス１１０とのセキュアセッションを確立するためのＳＭＳ信号１６０を生成することができ、また、セキュアセッションが確立される場合、認証メカニズム（例えば、ユーザ名、パスワード、ＰＩＮ等）に対するリクエスト１７０をユーザデバイス１１０に送信することができる。認証例では、サーバ１２０は、検証電話番号を認証メカニズムと関連付けることができ、また、この認証メカニズムをユーザデバイス１１０からリクエストすることができる。トランザクション例では、サーバ１２０は、セキュアリソースの記述をユーザデバイス１１０に提供することができ、ユーザデバイス１１０によるプライベートキーにより記述の署名をリクエストすることができる。
【００４３】
図１にさらに示されるように、ユーザデバイス１１０は、認証メカニズム１８０をサーバ１２０に提供することができる。認証例では、ユーザデバイス１１０は、認証メカニズム１８０を直接サーバ１２０に提供することができ、また、認証メカニズム１８０は、検証電話番号と関連付けられる。サーバ１２０は、認証メカニズム１８０を受信することができ、また、認証メカニズム１８０を（例えば、認証メカニズム１８０を検証電話番号と比較することによって）検証することができる。トランザクション例では、ユーザデバイス１１０は、プライベートキーによりセキュアリソースの記述に署名することができる。サーバ１２０は、署名された記述を受信することができ、また、ユーザデバイス１１０と関連付けられているパブリックキーで、署名されたセキュアリソースの記述を検証することができる。認証およびトランザクションの例の両方では、サーバ１２０は、セキュアリソースへのアクセスを許可または拒否する信号１９０をクライアント１３０に送信することができる。例えば、クライアント１３０がセキュアリソースへのアクセスを許可される場合、サーバ１２０は、クライアント１３０にセキュアリソースへのアクセス権を提供することができる。
【００４４】
例示的ユーザデバイス構成
図２は、本明細書に記載される一実装におけるユーザデバイス１１０の例示的前面図である。図２に示されるように、ユーザデバイス１１０は、筐体２１０、スピーカ２２０、ディスプレイ２３０、制御ボタン２４０、キーパッド２５０および／またはマイクロフォン２６０を含むことができる。筐体２１０は、ユーザデバイス１１０の構成要素を外部要素から保護することができる。スピーカ２２０は、可聴情報をユーザデバイス１１０のユーザに提供することができる。
【００４５】
ディスプレイ２３０は、可視情報をユーザに提供することができる。例えば、ディスプレイ２３０は、ユーザデバイス１１０への入力テキスト、サーバ１２０等の別のデバイスから受信されるテキストおよび／またはグラフィックス（例えば、ＳＭＳ信号）および／または着信呼または発信呼またはテキストメッセージ、メディア、ゲーム、電話帳、アドレス庁、現在時間等に関する情報を表示することができる。制御ボタン２４０は、ユーザがユーザデバイス１１０と相互動作することを許容することで、ユーザデバイス１１０に１つまたは複数の動作を実行させるようにすることができる。例えば、制御ボタン２４０を使用することで、ユーザデバイス１１０に情報を送信させるようにすることができる。キーパッド２５０は、標準電話機キーパッドを含むことができる。マイクロフォン２６０は、可聴情報をユーザから受信することができる。
【００４６】
図２はユーザデバイス１１０の例示的要素を示している。他の実装では、ユーザデバイス１１０は、図２に示される要素よりもさらに少ない、または、異なる、または追加要素を含むことができる。なおさらに他の実装では、ユーザデバイス１１０の１つまたは複数の要素は、ユーザデバイス１１０の１つまたは複数の他の要素によって実行されるタスクを実行することができる。
【００４７】
図３は、ユーザデバイス１１０の例示的構成要素図である。図３に示されるように、ユーザデバイス１１０は、処理ロジック３１０、メモリ３２０、ユーザインタフェース３３０、通信インタフェース３４０および／またはアンテナアセンブリ３５０を含むことができる。処理ロジック３１０は、プロセッサ、マイクロプロセッサ、特定用途集積回路（ＡＳＩＣ：application specific integrated circuit）、フィールド・プログラマブル・ゲートアレイ（ＦＰＧＡ：field programmable gate array）、またはその類を含むことができる。処理ロジック３１０は、ユーザデバイス１１０およびその構成要素の動作を制御することができる。メモリ３２０は、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）、リードオンリメモリ（ＲＯＭ：read only memory）および／または処理ロジック３１０によって使用することができるデータおよび命令を記憶する別のタイプのメモリを含むことができる。
【００４８】
ユーザインタフェース３３０は、情報をユーザデバイス１１０に入力するメカニズムおよび／またはユーザデバイス１１０から情報を出力するメカニズムを含むことができる。入力メカニズムおよび出力メカニズムの例は、ボタン（例えば、制御ボタン２４０、キーパッド２５０のキー、ジョイスティック等）を含み、また、データおよび制御コマンドをユーザデバイス１１０に入力する；スピーカ（例えば、スピーカ２２０）が電気信号を受信し、オーディオ信号を出力する；マイクロフォン（例えば、マイクロフォン２６０）がオーディオ信号を受信し、電気信号を出力する；ディスプレイ（例えば、ディスプレイ２３０）がビジュアル情報（例えば、ユーザデバイス１１０に入力されるテキスト）を出力する、および／またはバイブレータがユーザデバイス１１０を振動させるようにすることを許容することができる。
【００４９】
通信インタフェース３４０は、例えば、処理ロジック３１０からのベースバンド信号を無線周波数（ＲＦ：radio frequency）信号に変換することができる送信機、および／またはＲＦ信号をベースバンド信号に変換することができる受信機を含むことができる。選択的には、通信インタフェース３４０は、送信機および受信機の両方の機能を実行するための送受信機を含むことができる。通信インタフェース３４０は、ＲＦ信号の送信および／または受信のためにアンテナアセンブリ３５０に接続することができる。アンテナアセンブリ３５０は、空中を介して、ＲＦ信号を送信および／または受信する１つまたは複数のアンテナを含むことができる。アンテナアセンブリ３５０は、例えば、通信インタフェース３４０からＲＦ信号を受信し、かつ空中を介してＲＦ信号を送信し、そして、空中を介してＲＦ信号を受信し、そのＲＦ信号を通信インタフェース３４０に提供することができる。一実装では、例えば、通信インタフェース３４０は、ネットワーク１４０等のネットワークと通信することができる。
【００５０】
以下で詳細に記載されるように、ユーザデバイス１１０は、メモリ３２０等のコンピュータ読取可能媒体に含まれるアプリケーションのソフトウェア命令を実行する処理ロジック３１０に応じて一定の動作を実行することができる。コンピュータ読取可能媒体は、物理メモリデバイスまたは論理メモリデバイスおよび／または搬送波として定義することができる。ソフトウェア命令は、別のコンピュータ可読媒体から、または、通信インタフェース３４０を介して別のデバイスから、メモリ３２０に読み込むことができる。メモリ３２０に含まれるソフトウェア命令は、処理ロジック３１０が後述するプロセスを実行させることができる。選択的には、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて配線回路を使用して、本明細書に記載されるプロセスを実現することができる。従って、本明細書に記載される実装は、ハードウェア回路とソフトウェアの特定の組み合わせに限定されるものではない。
【００５１】
図３はユーザデバイス１１０の例示的構成要素を示している。他の実装では、ユーザデバイス１１０は、図３に示される構成要素よりもさらに少ない、異なるまたは追加の構成要素を含むことができる。なおさらにさらに他の実装では、ユーザデバイス１１０の１つまたは複数の構成要素は、ユーザデバイス１１０の１つまたは複数の他の構成要素によって実行されるタスクを実行することができる。
【００５２】
例示的クライアント／サーバ構成
図４は、サーバ１２０またはクライアント１３０に対応するクライアント／サーバエンティティの例示図である。図示されるように、クライアント／サーバエンティティは、バス４１０、処理ユニット４２０、メインメモリ４３０、ＲＯＭ４４０、ストレージデバイス４５０、入力デバイス４６０、出力デバイス４７０および／または通信インタフェース４８０を含むことができる。バス４１０は、クライアント／サーバエンティティの構成要素間の通信を許容するパスを含むことができる。
【００５３】
処理ユニット４２０は、プロセッサ、マイクロプロセッサ、または命令を解釈、実行することができる他のタイプの処理ロジックを含むことができる。メインメモリ４３０は、ＲＡＭまたは処理ユニット４２０による実行のための情報および命令を記憶することができる別のタイプの動的ストレージデバイスを含むことができる。ＲＯＭ４４０は、ＲＯＭデバイス、または処理ユニット４２０による使用のための静的情報および／または命令を記憶することができる別のタイプの静的ストレージデバイスを含むことができる。ストレージデバイス４５０は、磁気および／または光記録媒体およびそれに対応する駆動装置を含むことができる。
【００５４】
入力デバイス４６０は、オペレータが、キーボード、マウス、ペン、マイクロフォン、音声認識および／または生体測定メカニズム等のクライアント／サーバエンティティに情報を入力することを許容するメカニズムを含むことができる。出力デバイス４７０は、オペレータに情報を出力する、ディスプレイ、プリンタ、スピーカ等を含むメカニズムを含むことができる。通信インタフェース４８０は、クライアント／サーバエンティティが他のデバイスおよび／またはシステムと通信することを可能にする、送受信機の類のメカニズムを含むことができる。例えば、通信インタフェース４８０は、ネットワーク１４０等のネットワークを介して、別のデバイスまたはシステムと通信するメカニズムを含むことができる。
【００５５】
以下で詳細に記載されるように、クライアント／サーバエンティティは、メインメモリ４３０等のコンピュータ読取可能媒体に含まれるソフトウェア命令を実行する処理ユニット４２０に応じて一定の動作を実行することができる。このソフトウェア命令は、ストレージデバイス４５０等の別のコンピュータ読取可能媒体、または通信インタフェース４８０を介して別のデバイスから、メインメモリ４３０に読み込むことができる。メインメモリ４３０に含まれるソフトウェア命令は、処理ユニット４２０に後述する処理を実行させるようにすることができる。選択的には、ソフトウェア命令の代わりに、またはソフトウェア命令と組み合わせて配線回路を使用して、本明細書に記載されるプロセスを実装することができる。従って、本明細書に記載される実装は、ハードウェア回路とソフトウェアの特定の組み合わせに限定されるものではない。
【００５６】
図４は、クライアント／サーバエンティティの例示的構成要素を示している。他の実装では、クライアント／サーバエンティティは、図４に示される構成要素よりもさらに少ない、異なるまたは追加の構成要素を含むことができる。なおさらに他の実装では、クライアント／サーバエンティティの１つまたは複数の構成要素は、クライアント／サーバエンティティの１つまたは複数の他の構成要素によって実行されるタスクを実行することができる。
【００５７】
例示的クライアント／サーバの動作
図５は、クライアント１３０によって提供することができる例示的表示５００の図である。図５の左側に示されるように、ユーザは、クライアント１３０を介して（例えば、サーバ１２０によって提供される）セキュアリソースへのアクセスをリクエストすることができる。例えば、ユーザは、企業のイントラネット、セキュアサーバ、セキュアネットワーク内において提供されるアプリケーション、クレジットまたはデビットカード、建物、車両等へのアクセスをリクエストすることができる。認証例では、クライアント１３０は、検証電話番号の入力を可能にするメカニズム５１０、および入力された検証電話番号の提出を可能にする提出メカニズム５２０を含むディスプレイを提供することができる。メカニズム５１０は、例えば、入力フィールド、電話番号の選択を提供するドロップ−ダウンメニュー、および／または他の同様の入力メカニズムを含むことができる。提出メカニズム５２０は、ユーザがメカニズム５２０に覆いかぶさるまたはメカニズム５２０をクリックする場合に選択することができるメカニズム（例えば、アイコン、リンク、ボタンおよび／または他の同様の選択メカニズム）を含むことができる。
【００５８】
セキュアリソースリクエスト、およびメカニズム５１０によって入力される検証電話番号は、サーバ１２０によって受信することができ、また、以下の図６に関して記載されるように、サーバ１２０は、ユーザデバイス１１０と共に検証機能を実行することができる。サーバ１２０は、検証電話番号を認証メカニズム（例えば、ユーザ名、パスワード、ＰＩＮ等）と関連付けることができる。図５の中央に示されるように、サーバ１２０がユーザデバイス１１０と共に検証機能を実行中である場合、クライアント１３０は、クライアント１３０がセキュアリソースへのアクセスを待機していることを示す情報５３０を表示することができる。図５の右側に示されるように、サーバ１２０が検証機能を完了した後、クライアント１３０は、セキュアリソースへのアクセスが許可されるかまたは拒否されるかを示す情報５４０を表示することができる。
【００５９】
図５には示されないが、トランザクション例では、ユーザは、クライアント１３０を介して（例えば、サーバ１２０によって提供される）セキュアリソースを使用するための認可をリクエストすることができる。サーバ１２０は、セキュアリソースをユーザデバイス１１０に関係する電話番号およびパブリックキーと関連付けることができ、以下で図６に関して記載されるように、ユーザデバイス１１０と共に検証機能を実行することができる。サーバ１２０がユーザデバイス１１０と共に検証機能を実行中である場合、クライアント１３０は、クライアント１３０がセキュアリソースを使用するための認可を待機していることを示す（例えば、情報５３０と同様の）情報を表示することができる。例えば、ユーザがクレジット・カード・トランザクションの認可をリクエスト中である場合、クライアント１３０は、クレジット・カード・トランザクションが認可を待機していることを示す情報を表示することができる。サーバ１２０が検証機能を完了した後、クライアント１３０は、ユーザがセキュアリソースを使用することが認可されることを示す（例えば、情報５４０と同様の）情報を表示することができる。
【００６０】
図５は、クライアント１３０の例示的表示５００を示している。他の実装では、クライアント１３０は、図５に示される表示よりさらに少ない、異なるまたは追加表示を提供することができる。なおさらにさらに他の実装では、図５の例示的表示５００は、図５に示される表示よりさらに少ない、異なるまたは追加要素を含むことができる。
【００６１】
例示的ユーザデバイス／サーバ動作
図６は、ユーザデバイス１１０によって提供することができる例示的表示６００の図である。図６の左側に示されるように、ユーザがクライアント１３０を介して（例えば、サーバ１２０によって提供される）セキュアリソースへのアクセスをリクエストする場合、サーバ１２０は、ＳＭＳ信号（例えば、図１のＳＭＳ信号１６０）を生成することができる。認証例では、ＳＭＳ信号は、検証電話番号およびユーザに関連付けられているユーザデバイス１１０によって受信することができ、また、セキュアセッションは、ユーザデバイス１１０とサーバ１２０との間で確立することができる。ユーザデバイス１１０は、ＳＭＳ信号の受信を示す情報６１０（例えば、アイコン、リンク等）を表示することができる。図６の中央に示されるように、ユーザデバイス１１０のユーザが（例えば、情報６１０に覆いかぶさるまたは情報６１０をクリックすることによって）情報６１０を選択する場合、ユーザデバイス１１０は、ＳＭＳ信号の内容を表示することができる。ＳＭＳ信号の内容は、例えば、セキュアリソースへのアクセスの検証処理を開始するためのアドレス６３０（例えば、ユニフォーム・リソース・ロケータ（ＵＲＬ：Uniform Resource Locator）の選択をユーザにリクエストする情報６２０を含むことができる。
【００６２】
認証例では、ＳＭＳ信号は、リクエストされたセキュアリソースの記述、およびサーバ１２０によって維持されるダウンロード可能なアプリケーション（例えば、ジャバミッドレット（Java midlet））へのＵＲＬを含むことができる。サーバ１２０によって維持される各ダウンロード可能なアプリケーションは、プライベートキーフィールドを伴うデータセグメントを含むことができ、また、データセグメントを、セキュリティ目的のため（例えば、ハッキングを防止するため）に暗号化することができる。サーバ１２０は、（例えば、ユーザデバイス１１０の）検証電話番号のリストを、対応するダウンロード可能なアプリケーション（およびその対応する認証メカニズム）と関連付けて、検証電話番号と対応する認証メカニズムとのペアを作成することができる。ダウンロード可能なアプリケーションが開始される場合（例えば、ユーザがアドレス６３０を選択する場合）、ユーザデバイス１１０は、サーバ１２０とコンタクトして、サーバ１２０とセキュア通信を開始することができる。例えば、ユーザデバイス１１０は、セキュアソケット接続（または他のタイプのセキュア接続）を経て、自身の電話番号をサーバ１２０に提供することができる。
【００６３】
セキュア通信がユーザデバイス１１０とサーバ１２０との間で確立される場合、サーバ１２０は、多様な情報をユーザデバイス１１０に提供して、検証処理を支援することができる。例えば、図６の右側に示されるように、ユーザデバイス１１０は、リクエストされたセキュアリソースの記述を提供する情報６４０、認証メカニズムの入力を可能にするメカニズム６５０、セキュアリソースへのアクセスが許可されるかまたは拒否されるかを問い合わせる情報６６０、および入力した認証メカニズムの提出を可能にする２つの提出メカニズム（例えば、ＹＥＳ（肯定）メカニズム６７０およびＮＯ（否定）メカニズム６８０）、並びにアクセスが許可または拒否されるかの決定を表示することができる。メカニズム６５０は、例えば、入力フィールド、認証メカニズムの選択を提供するドロップ−ダウンメニューおよび／または他の同様の入力メカニズムを含むことができる。提出メカニズム６７０および６８０は、ユーザが提出メカニズム６７０および６８０に覆いかぶさるまたは提出メカニズム６７０および６８０をクリックする場合に選択することができるメカニズム（例えば、アイコン、リンク、ボタンおよび／または他の同様の選択メカニズム）を含むことができる。他の実装では、ユーザデバイス１１０に関連付けられている認証メカニズムを自動的に生成することができ（例えば、肯定メカニズム６７０が選択される場合）、メカニズム６５０を省略することができる。
【００６４】
ユーザデバイス１１０のユーザがセキュアリソースへのアクセスの提供を要望する場合、ユーザは（例えば、メカニズム６５０を介して、またはユーザデバイス１１０で自動的に）認証メカニズムを提供することができ、そして、ＹＥＳメカニズム６７０を選択することができる。サーバ１２０は、ユーザデバイス１１０から認証メカニズムを受信することができ、次に、セキュアリソースへのアクセスを許可または拒否するかを判定するために、認証メカニズムを検証することができる。例えば、サーバ１２０は、ユーザに、クライアント１３０を介してサーバ１２０によって提供されるセキュアリソースへのアクセスを許可することができる。ユーザデバイスのユーザが、セキュアリソースへのアクセスを拒否することを要望する場合、ユーザは、メカニズム６５０を介する情報の提供を省略および／またはＮＯメカニズム６８０を選択することができる。サーバ１２０は、この情報に基づいて、および／または認証メカニズムが検証されない場合、セキュアリソースへのアクセスを拒否することができる。
【００６５】
ユーザが２度目に同一のセキュアリソースへのアクセスを試行する場合（例えば、ユーザがセキュアなウェブサイトに２度目にログインすることを試行する）、サーバ１２０は、ダウンロード可能なアプリケーション（例えば、ジャバミッドレット）がユーザデバイス１１０上で実行中であるかを確認するためのチェックを行うことができる。ジャバミッドレットが、ユーザデバイス１１０上で動作中である場合、認証処理（例えば、プライベートキーのリクエスト）を直ちに開始することができる。ジャバミッドレットがユーザデバイス１１０上で動作中でない場合、ＳＭＳ信号は、ユーザデバイス１１０に送信することができ、上記の認証処理を開始することができる。
【００６６】
図６には示されないが、トランザクション例では、サーバ１２０は、セキュアリソースおよび／またはセキュアリソースリクエストを、ユーザデバイス１１０に関連するする電話番号およびパブリックキーと関連付けることができる。サーバ１２０は、サーバ１２０とのセキュアセッションを確立する（アドレス６３０と同様の）ためのアドレスを含むＳＭＳ信号をユーザデバイス１１０に送信することができる。セキュアセッションがサーバ１２０とユーザデバイス１１０との間で確立される場合、サーバ１２０は、ユーザデバイス１１０に（そして、ユーザデバイス１１０が表示することができる）、（情報６４０と同様の）セキュアリソースの記述、認可をリクエストするユーザ（例えば、個人、デバイス等）、（情報６６０ならびに提出メカニズム６７０および６８０と同様の）ユーザによるセキュアリソースの使用を認可するためのリクエスト、および／またはリクエストを特定する乱数を送信することができる。プライベートキーによりセキュアリソースの記述に電子的に署名し、その署名した記述および乱数をサーバ１２０に送信することによって、セキュアリソースリクエストを、ユーザデバイス１１０を介して認可することができる。他の実装では、セキュアリソースリクエストは、認可のためにプライベートキーを利用することができる他のメカニズムにより認可することができる。
【００６７】
セキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイス１１０に関連付けられているパブリックキーにより、および／または受信した乱数をオリジナルの乱数と比較することによって、サーバ１２０は署名されたセキュアリソースの記述を検証することができる。例えば、署名された記述がサーバ１２０によって検証される場合、（例えば、クライアント１３０を介する）リクエスタはセキュアリソースを使用するための認可を受信することができる。
【００６８】
本明細書に記載される実装は、検証電話番号と、各ダウンロード可能なアプリケーションに対応する認証メカニズムとのペアリングを検討するが、他の実装では、そのようなペアリングを省略することができ、また、セキュアリソースへのアクセスをリクエストするユーザは、ユーザデバイス１１０の検証から必要とされるキーコード（例えば、数字、文字、または数字または文字の組み合わせ）を提供することができる。
【００６９】
さらに、本明細書に記載される実装はＳＭＳ信号の提供を検討するが、他の実装では、ＳＭＳ信号とは別の信号を使用することができる。例えば、インターネットプロトコル（ＩＰ：Internet Protocol）マルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）信号、ジャバー（Jabber）信号、または別のＩＰベースの信号を使用することができる。ＩＰベースの信号が使用される場合、ユーザデバイス１１０は自動的にサーバ１２０に接続することができ、また、適切なプロトコル（例えば、ＩＭＳの場合におけるセッション開始プロトコル（ＳＩＰ：Session Initiation Protocol）、ジャバーの場合における拡張メッセージングおよびプレゼンスプロトコル（ＸＭＰＰ：Extensible Messaging and Presence Protocol）等）を使用して、サーバ１２０はユーザデバイス１１０とコンタクトすることができる。サーバ１２０にそのＩＰアドレスを提供するユーザデバイス１１０以外には、ユーザデバイス１１０のＩＰアドレスが未知である場合、ＳＭＳ信号の使用は有利でありうる。このＳＭＳ信号は、従って、未知のユーザデバイス１１０とサーバ１２０との間で通信を開始することができる。
【００７０】
なおさらに、本明細書に記載される実装は、チャットセッションをユーザデバイス１１０（例えば、携帯電話機）からクライアント１３０（例えば、クライアント１３０に提供されるウェブインターフェース）に送信するために使用することができる。これは、本明細書に記載される実装をチャットアプリケーションに組み込むことによって実現することができる。ユーザがチャットをクライアント１３０に送信することを要望する場合、ユーザは、クライアント１３０のウェブインターフェースにおいてユーザデバイス１１０の電話番号を入力することができ、ここで、クライアント１３０は、ユーザがチャットをクライアント１３０のウェブインターフェースに送信することを要望するかをユーザに問い合わせ、ユーザデバイス１１０においてダイアログを起動することができる。
【００７１】
図６は、ユーザデバイス１１０の例示的表示６００を示している。他の実装では、ユーザデバイス１１０は、図６に示される表示よりもさらに少ない、異なるまたは追加の表示を提供することができる。なおさらに他の実装では、図６の例示的表示６００は、図６に示される表示よりもさらに少ない、異なるまたは追加の要素を含むことができる。
【００７２】
例示的処理
図７乃至図１１は、本明細書に記載される実装に従う例示的処理のフローチャートを示している。一般的に、図７は、サーバ１２０によって実行することができる例示的認証処理７００を示し、図８は、サーバ１２０によって実行することができる例示的トランザクション処理８００を示し、図９は、ユーザデバイス１１０によって実行することができる例示的認証処理９００を示し、図１０は、ユーザデバイス１１０によって実行することができる例示的トランザクション処理１０００を示し、図１１は、クライアント１３０によって実行することができる例示的処理１１００を示している。処理７００−１１００は、ユーザデバイス１１０、サーバ１２０、クライアント１３０またはユーザデバイス１１０、サーバ１２０および／またはクライアント１３０の組み合わせにおける、ハードウェアおよび／またはソフトウェア構成要素によって実行することができる。
【００７３】
認証処理（サーバ）
図７に示されるように、処理７００はセキュアリソースへアクセスするためのリクエストおよび／または検証電話番号の受信により開始することができる（ブロック７１０）。例えば、図５に関する上述の一実装例では、セキュアリソースリクエストおよびクライアント１３０のメカニズム５１０によって入力される検証電話番号は、サーバ１２０によって受信することができる。
【００７４】
セキュアセッションを確立するために、ＳＭＳ信号を検証電話番号に対して生成、送信することができる（ブロック７２０）。例えば、図６に関する上述の一実装例では、ユーザが、クライアント１３０を介して、（例えば、サーバ１２０によって提供される）セキュアリソースへのアクセスをリクエストする場合、サーバ１２０は、ＳＭＳ信号（例えば、図１のＳＭＳ信号１６０）を生成することができる。ＳＭＳ信号は、例えば、セキュアリソースアクセスの検証処理を開始するためのアドレス６３０（例えば、ＵＲＬ)の選択をユーザにリクエストする情報６２０を含むことができる。
【００７５】
図７にさらに示されるように、検証電話番号は、認証メカニズムと関連付けることができる（ブロック７３０）。例えば、図５に関する上述の一実装例では、サーバ１２０は、検証電話番号を認証メカニズム（例えば、ユーザ名、パスワード、ＰＩＮ等）と関連付けることができる。
【００７６】
認証メカニズムは、セキュアリソースアクセスリクエストを検証するためにリクエストすることができる（ブロック７４０）。例えば、図６に関する上述の一実装例では、セキュア通信をユーザデバイス１１０とサーバ１２０との間で確立される場合、サーバ１２０は、多様な情報をユーザデバイス１１０に提供し、検証処理を支援することができる。一例では、サーバ１２０は、認証メカニズムの入力をリクエストするためのメカニズム６５０、セキュアリソースへのアクセスが許可されるまたは拒否されることになるかを問い合わせる情報６６０、および入力された認証メカニズムの提出を可能にする２つの提出メカニズム（例えば、ＹＥＳ（肯定）メカニズム６７０およびＮＯ（否定）メカニズム６８０）、並びにアクセスを許可するかまたは拒否するかの決定を提供することができる。
【００７７】
図７にさらに示されるように、認証メカニズムが受信される場合（ブロック７５０）、認証メカニズムを検証し（ブロック７６０）、検証に基づいて、セキュアリソースへのアクセスを許可することができる（ブロック７７０）。例えば、図６に関する上述の一実装例では、ユーザデバイス１１０のユーザがセキュアリソースへのアクセスを提供する（provide access：アクセスを受け付けてもらう）ことを要望する場合、ユーザは（例えば、メカニズム６５０による、またはユーザデバイス１１０により自動的に）認証メカニズムを提供することができる。サーバ１２０は、認証メカニズムをユーザデバイス１１０から受信することができ、例えば、受信した認証メカニズムと、検証電話番号と関連付けられている認証メカニズムとを比較することによって、認証メカニズムを検証することができる。サーバ１２０は、認証メカニズムの検証結果に基づいて、セキュアリソースへのアクセスを許可または拒否するかを判定することができる。
【００７８】
トランザクション処理（サーバ）
図８に示されるように、処理８００は、セキュアリソースへのアクセスを認可するためのリクエストの受信により開始することができる（ブロック８１０）。例えば、図１に関する上述の一実装例では、クライアント１３０は、セキュアリソースへのアクセスをリクエストするためのリクエスト１５０をサーバ１２０に送信することができる。
【００７９】
セキュアリソースに関連付けられているユーザデバイスを判定することができる（ブロック８２０）。例えば、図６に関する上述の一実装例では、サーバ１２０は、セキュアリソースを、ユーザデバイス１１０に関連するする電話番号およびパブリックキーと関連付けることができる。
【００８０】
図８にさらに示されるように、ユーザデバイスとのセキュアセッションを確立するために、ＳＭＳ信号を生成することができる（ブロック８３０）。例えば、図６に関する上述の一実装例では、サーバ１２０は、ユーザデバイス１１０に、サーバ１２０とのセキュアセッションを確立するためのアドレスを含むＳＭＳ信号を送信することができる。ＳＭＳ信号は、例えば、ユーザに、セキュアリソースへのアクセス検証処理を開始するためのアドレス６３０（例えば、ＵＲＬ）を選択することをリクエストする情報６２０を含むことができる。
【００８１】
セキュアリソースの記述および署名用のリクエストを提供することができる（ブロック８４０）。例えば、図６に関する上述の一実装例では、セキュアセッションが、サーバ１２０とユーザデバイス１１０との間で確立される場合、サーバ１２０は、ユーザデバイス１１０に（そしてユーザデバイスが表示することができる）、（情報６４０と同様の）セキュアリソースの記述、認可をリクエストするユーザ（例えば、個人、デバイス等）、（情報６６０ならびに提出メカニズム６７０および６８０と同様の）ユーザによってセキュアリソースの使用を認可するためのリクエストおよび／またはリクエストを特定する乱数を送信することができる。
【００８２】
図８にさらに示されるように、プライベートキーにより署名されたセキュアリソースの記述が受信される場合（ブロック８５０）、署名された記述をユーザデバイスに関連付けられているパブリックキーにより検証することができ（ブロック８６０）、また、その検証に基づいて、セキュアリソースを使用するための認可を許可または拒否することができる（ブロック８７０）。例えば、図６に関する上述の一実装例では、セキュアリソースの記述にプライベートキーにより電子的に署名し、その署名した記述および乱数をサーバ１２０に送信することによって、セキュアリソースリクエストをユーザデバイス１１０により認可することができる。セキュアリソースへのアクセスを許可または拒否するかを判定するために、ユーザデバイス１１０に関連付けられているパブリックキーにより、および／または受信した乱数とオリジナルの乱数との比較によって、サーバ１２０は、署名されたセキュアリソースの記述を検証することができる。サーバ１２０は、サーバ１２０によって実行される検証の結果に基づいて、セキュアリソースを使用するための認可を許可または拒否することができる。
【００８３】
認証処理（ユーザデバイス）
図９に示されるように、処理９００は、セキュアセッションを確立するためのアドレスを含むＳＭＳ信号の受信により開始することができる（ブロック９１０）。例えば、図６に関する上述の一実装例では、ＳＭＳ信号を、検証電話番号およびユーザと関連付けられているユーザデバイス１１０によって受信することができる。ユーザデバイス１１０は、ＳＭＳ信号の受信を示す情報６１０（例えば、アイコン、リンク等）を表示することができる。ユーザデバイス１１０のユーザが（例えば、情報６１０に覆いかぶさるまたは情報６１０をクリックすることによって）情報６１０を選択する場合、ユーザデバイス１１０は、例えば、ユーザにアドレス６３０（例えば、ＵＲＬ）を選択することをリクエストする情報６２０を表示し、セキュアリソースへのアクセス検証処理を開始することができる。
【００８４】
受信したアドレスに基づいてセキュアセッションが確立される場合（ブロック９２０）、アクセスすべきセキュアリソースの記述および／または認証メカニズムリクエストを受信することができる（ブロック９３０）。例えば、図６に関する上述の一実装例では、ＵＲＬは、サーバ１２０によって保持されるダウンロード可能なアプリケーション（例えば、ジャバミッドレット）へのアドレスを提供することができる。ダウンロード可能なアプリケーションが開始される場合（例えば、ユーザがアドレス６３０を選択する場合）、ユーザデバイス１１０は、サーバ１２０とコンタクトし、サーバ１２０とのセキュア通信を開始することができる（例えば、ユーザデバイス１１０は、その電話番号をセキュアソケット接続を経てサーバ１２０に提供することができる）。セキュア通信がユーザデバイス１１０とサーバ１２０との間で確立される場合、ユーザデバイス１１０は、リクエストされたセキュアリソースの記述を提供する情報６４０、および認証メカニズムを入力するためのリクエスト（例えば、メカニズム６５０）を受信することができる。
【００８５】
図９にさらに示されるように、認証メカニズムが提供される場合（ブロック９４０）、セキュアリソースへのアクセスを許可または拒否するかの指示を受信することができる（ブロック９５０）。例えば、図６に関する上述の一実装例では、ユーザデバイス１１０のユーザが、セキュアリソースへのアクセスを許可することを要望する場合、ユーザは（例えば、メカニズム６５０による、またはユーザデバイス１１０により自動的に）認証メカニズムを提供することができる。サーバ１２０は、認証メカニズムをユーザデバイス１１０から受信することができ、また、セキュアリソースへのアクセスを許可または拒否することを判定するために、認証メカニズムを検証することができる。他の実装では、ユーザデバイス１１０は、（例えば、サーバ１２０から）セキュアリソースへのアクセスが許可または拒否されているかの指示を受信することができる。
【００８６】
トランザクション処理（ユーザデバイス）
図１０に示されるように、処理１００は、セキュアセッションを確立するためのアドレスを含むＳＭＳ信号の受信により開始することができる（ブロック１０１０）。例えば、図６に関する上述の一実装例では、ＳＭＳ信号は、リクエストされたセキュアリソースに関連付けられているユーザデバイス１１０によって受信することができる。ユーザデバイス１１０は、ＳＭＳ信号の受信を示す情報６１０（例えば、アイコン、リンク等）を表示することができる。ユーザデバイス１１０のユーザが（例えば、情報６１０に覆いかぶさるまたは情報６１０をクリックすることによって）情報６１０を選択する場合、ユーザデバイス１１０は、セキュアリソースへのアクセス検証処理を開始するために、例えば、ユーザにアドレス６３０（例えば、ＵＲＬ）を選択することをリクエストする情報６２０を表示することができる。
【００８７】
セキュアセッションが受信したアドレスに基づいて確立される場合（ブロック１０２０）、アクセスすべきセキュアリソースの記述および／または署名のためのリクエストを受信することができる（ブロック１０３０）。例えば、図６に関する上述の一実装例では、セキュアセッションがサーバ１２０とユーザデバイス１１０との間で確立される場合、サーバ１２０は、ユーザデバイス１１０に（そして、ユーザデバイス１１０が表示することができる）、（情報６４０と同様の）セキュアリソースの記述、認可をリクエストするユーザ（例えば、個人、デバイス等）、（情報６６０ならびに提出メカニズム６７０および６８０と同様の）、（例えば、プライベートキーによる署名により）ユーザによってセキュアリソースの使用を認可するためのリクエスト、および／またはリクエストを特定する乱数を送信することができる。
【００８８】
図１０にさらに示されるように、セキュアリソースリクエストが認可される場合、セキュアリソースの記述は、プライベートキーにより署名することができる（ブロック１０４０）。例えば、図６に関する上述の一実装例では、ユーザデバイス１１０によりセキュアリソースの記述にプライベートキーにより電子的に署名することによって、セキュアリソースリクエストを認可することができる。
【００８９】
プライベートキーにより署名されたセキュアリソースの記述を提供することができ（ブロック１０５０）、セキュアリソースへのアクセスを許可または拒否するかの指示を受信することができる（ブロック１０６０）。例えば、図６に関する上述の一実装例では、ユーザデバイス１１０は、署名した記述および乱数をサーバ１２０に送信することができる。ユーザデバイス１１０に関連付けられているパブリックキーにより、および／または受信した乱数とオリジナル乱数との比較によって、サーバ１２０は、署名されたセキュアリソースの記述を検証することができる。他の実装では、ユーザデバイス１１０は、（例えば、サーバ１２０から）セキュアリソースへアクセスするための認可が、許可または拒否されているかの指示を受信することができる。
【００９０】
認証／トランザクション処理（クライアント）
図１１に示されるように、処理１１００は、セキュアリソースへのアクセスリクエストの送信により開始することができる（ブロック１１１０）。例えば、図５に関する上述の一実装例（例えば、認証およびトランザクション例）では、ユーザは、クライアント１３０を介して（例えば、サーバ１２０によって提供される）セキュアリソースへのアクセスをリクエストすることができる。一例では、ユーザは、企業のイントラネット、セキュアサーバ、セキュアネットワーク内で提供されるアプリケーション、クレジットまたはデビットカード、建物、車両等へのアクセスをリクエストすることができる。
【００９１】
ユーザデバイスの検証電話番号を提供することができる（ブロック１１２０）。例えば、図５に関する上述の一実装例（例えば、認証例）では、クライアント１３０は、検証電話番号の入力を可能にするメカニズム５１０、および入力された検証電話番号の提出を可能にする提出メカニズム５２０を含む表示を提供することができる。セキュアリソースリクエストおよびメカニズム５１０によって入力される検証電話番号はサーバ１２０によって受信することができ、サーバ１２０は、ユーザデバイス１１０と共に検証機能を実行することができる。トランザクション例では、検証電話番号は提供される必要はない、これは、サーバ１２０がリクエストされたセキュアリソースを、ユーザデバイス１１０に関係する、電話番号およびパブリックキーと関連付けることができ、また、ユーザデバイス１１０による検証機能を実行することができるからである。
【００９２】
図１１にさらに示されるように、セキュアリソースへのアクセスまたはセキュアリソースへのアクセスの拒否は、ユーザデバイスの検証に基づいて、受信することができる（ブロック１１３０）。例えば、図５に関する上述の一実装例（例えば、認証およびトランザクション例）では、サーバ１２０が検証機能を完了した後、クライアント１３０は、セキュアリソースへのアクセスを許可または拒否するか、および／またはユーザにセキュアリソースを使用することを認可するかを示す情報５４０を（例えば、サーバ１２０から）受信し、表示することができる。
【００９３】
結論
本明細書に記載される実装は、セキュアなユーザデバイスによって提供される認証および／または認可に基づいて、１つまたは複数のセキュアリソースへのアクセスを提供することができる。例えば、一実装では、ユーザデバイスは、ＰＫＩをサポートすることができるセルラー電話または携帯電話機に対応する。このユーザデバイスは、セキュアリソースへのアクセスを試行する別のデバイスに認証および／または認可を提供する２つの組のＰＫＩ信用証明を含むことができる。本明細書に記載される実装は、複数のパスワード、ユーザ名等を記憶する必要なく、任意のセキュアリソースにアクセスするための、簡単で、セキュアなシステムおよび方法を提供することができる。
【００９４】
実装に関する上述の記述は、図示および説明を提供するものであるが、全てを網羅する、または本発明を開示する正確な形態に限定することを意図しない。修正および変形は、上記の教示に照らして可能であるか、または本発明の実施から得ることができる。
【００９５】
例えば、図７乃至図１１に関して一連の動作を記述しているが、動作順序は他の実装では変更することができる。さらに、従属関係のない動作は、平行して実行することができる。
【００９６】
また、用語「ユーザ」が本明細書で使用されている。用語「ユーザ」は、クライアントおよび／またはユーザデバイスまたはクライアントのユーザおよび／またはユーザデバイスを含むと広く解釈することを意図する。
【００９７】
上記のごとく、態様は図に示す実装では、多くの異なる形態のソフトウェア、ファームウェアおよびハードウェアにおいて実装することができることは明らかであろう。これらの態様を実装するために使用される実際のソフトウェアコードまたは特別な制御ハードウェアは、限定的なものと解釈すべきではない。従って、態様に関する動作および振る舞いは、特定のソフトウェアコードを参照することなく記述した−これは、ソフトウェアおよび制御ハードウェアは、本明細書の記述に基づいて態様を実装するように設計することができると理解される。
【００９８】
本願で使用される要素、動作または命令は、明確にそのように記述しない限り本発明に極めて重要なものまたは本質的なものとして解釈されるべきではない。また、本明細書において使用されるように、冠詞「ある（ａ）」は、１つまたは複数の項目を含むことが意図される。ただ１つの項目が意図される場合では、用語「１つの（one）］または同様の言葉が使用される。さらに、熟語「基づいて（based on）」は、明確にそうでなく述べない限り、「少なくとも一部では基づいて（based, at least in part on）」を意味することが意図される。
【図１】
2010519631.tif 000003
【図２】
2010519631.tif 000004
【図３】
2010519631.tif 000005
【図４】
2010519631.tif 000006
【図５】
2010519631.tif 000007
【図６】
2010519631.tif 000008
【図７】
2010519631.tif 000009
【図８】
2010519631.tif 000010
【図９】
2010519631.tif 000011
【図１０】
2010519631.tif 000012
【図１１】
2010519631.tif 000013
【手続補正書】
【提出日】平成20年12月22日(2008.12.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストと検証電話番号とを受信するステップと、
前記検証電話番号に関連付けられている第２のデバイスとのセキュアセッションを確立するステップと、
前記第２のデバイスから前記セキュアリソースリクエストを検証するための認証メカニズムをリクエストするステップと、
前記第２のデバイスから、リクエストされた前記認証メカニズムが受信される場合、その受信した認証メカニズムを検証するステップと、
前記受信した認証メカニズムの検証に基づいて、前記セキュアリソースへのアクセスを前記第１のデバイスに許可するかまたは拒否するかを判定するステップと、
前記セキュアリソースへのアクセスを前記第１のデバイスに許可すると判定される場合、前記第１のデバイスからの前記セキュアリソースへのアクセスを受け付けるステップと
を備えることを特徴とする方法。
【請求項２】
前記検証電話番号を前記認証メカニズムと関連付けるステップを更に備える
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記第２のデバイスに提供するステップと、
前記第２のデバイスが前記アドレスにアクセスする場合に、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記受信した認証メカニズムを検証するステップは、前記受信した認証メカニズムが、前記検証電話番号に関連付けられている認証メカニズムと整合するかを判定するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項５】
第１のデバイスで実行される方法であって、
第２のデバイスから、セキュアリソースを使用するためのセキュアリソースリクエストを受信するステップと、
前記セキュアリソースに関連付けられている第３のデバイスを判定するステップと、
前記セキュアリソースに関連付けられている前記第３のデバイスとのセキュアセッションを確立するステップと、
前記第３のデバイスから前記セキュアリソースリクエストの認可をリクエストするステップであって、
前記セキュアリソースの記述を前記第３のデバイスへ提供するステップと、
プライベートキーにより、前記第３のデバイスによる記述の署名をリクエストするステップとを含む、
ステップと、
前記第３のデバイスから前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証するステップと、
前記認可の検証に基づいて、前記セキュアリソースの使用を前記第２のデバイスに許可するかまたは拒否するかを判定するステップと、
前記セキュアリソースの使用を前記第２のデバイスに許可すると判定される場合、前記第２のデバイスからの前記セキュアリソースの使用を受け付けるステップと
を備えることを特徴とする方法。
【請求項６】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記第３のデバイスに提供するステップと、
前記第３のデバイスが前記アドレスにアクセスする場合、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項５に記載の方法。
【請求項７】
前記認可を検証するステップは、前記第３のデバイスに関連付けられているパブリックキーにより前記認可を検証するステップを含む
ことを特徴とする請求項５に記載の方法。
【請求項８】
第１のデバイス内で実行される方法であって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、前記セキュアセッションを確立するステップと、
前記セキュアリソースリクエストを認証するための認証メカニズムに対するリクエストを受信するステップと、
前記セキュアリソースリクエストが認証される場合、リクエストされた前記認証メカニズムを提供するステップとを備え、
前記第２のデバイスは、前記セキュアリソースリクエストが認証される場合に、前記セキュアリソースへのアクセスが受け付けられる
ことを特徴とする方法。
【請求項９】
前記セキュアリソースへのアクセスを第２のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項８に記載の方法。
【請求項１０】
前記認証メカニズムに対するリクエストを受信するステップは、前記セキュアリソースの記述を受信するステップを含む
ことを特徴とする請求項８に記載の方法。
【請求項１１】
第１のデバイス内で実行される方法であって、
セキュアリソースを使用するためのセキュアリソースリクエストを第２のデバイスによって認可するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信するステップと、
前記アドレスに基づいて、第３のデバイスとの前記セキュアセッションを確立するステップと、
前記第３のデバイスから、前記セキュアリソースリクエストを認可するためのリクエストを受信するステップであって、
前記セキュアリソースの記述を受信するステップと、
プライベートキーにより、前記記述を署名するためのリクエストを受信するステップとを含む、
ステップと、
前記セキュアリソースリクエストが認可される場合、リクエストされた認可を前記第３のデバイスに提供するステップとを備え、
前記第２のデバイスは、前記セキュアリソースリクエストが認可される場合に、前記セキュアリソースへの使用が受け付けられる
ことを特徴とする方法。
【請求項１２】
前記セキュアリソースを使用するための認可を前記第２のデバイスに許可するかまたは拒否するかの指示を受信するステップを更に備える
ことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記リクエストされた認可を提供するステップは、前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された前記記述を前記第３のデバイスに提供するステップを含む
ことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記認可するためのリクエストを受信するステップは、
前記セキュアリソースの記述を受信するステップと、
前記セキュアリソースの使用をリクエストするユーザの識別情報を受信するステップまたは前記セキュアリソースリクエストを特定する乱数を受信するステップと
を備えることを特徴とする請求項１１に記載の方法。
【請求項１５】
第１のデバイス内で実行される方法であって、
セキュアリソースへのアクセスまたはセキュアリソースの使用をリクエストするステップと、
前記第１のデバイスに前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を認証する第２のデバイスを特定する検証電話番号を提供するステップと
前記第２のデバイスによって提供される認証に基づいて、前記セキュアリソースへのアクセスまたは前記セキュアリソースの使用を受け付けるステップと
を備えることを特徴とする方法。
【請求項１６】
システムであって、
第１のデバイスからセキュアリソースへアクセスするためのセキュアリソースリクエストを受信する手段と
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するための、前記第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立する手段と、
前記第２のデバイスから、前記セキュアリソースリクエストの認可をリクエストする手段と、
前記第２のデバイスから、前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証する手段と、
前記認可の検証に基づいて、前記第１のデバイスに前記セキュアリソースへのアクセスを許可するかまたは拒否するかを判定する手段と、
前記セキュアリソースへのアクセスを前記第１のデバイスに許可すると判定される場合、前記第１のデバイスからの前記セキュアリソースへのアクセスを受け付ける手段と
を備えることを特徴とするシステム。
【請求項１７】
前記認可をリクエストする手段は、
前記セキュアリソースリクエストを検証するために、前記第２のデバイスから認証メカニズムをリクエストする手段と、またはプライベートキーにより、前記第２のデバイスによるセキュアリソースの記述の署名をリクエストする手段との１つを含む
ことを特徴とする請求項１６に記載のシステム。
【請求項１８】
前記認可を検証する手段は、前記第２のデバイスから受信される認証メカニズムが、前記第２のデバイスの検証電話番号に関連付けられている認証メカニズムに整合するかを判定する手段と、または前記第２のデバイスに関連付けられているパブリックキーによる認可を検証する手段の１つを含む
ことを特徴とする請求項１６に記載のシステム。
【請求項１９】
第１のデバイスであって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信する手段と、
前記アドレスに基づいて、第３のデバイスと前記セキュアセッションを確立する手段と、
前記第３のデバイスから、前記セキュアリソースリクエストを認可するためのリクエストを受信する手段であって、
前記セキュアリソースの使用をリクエストするユーザの識別情報及び前記セキュアリソースリクエストを特定する乱数の少なくとも１つと前記セキュアリソースの記述とを受信する手段と、
プライベートキーにより、前記記述を署名するためのリクエストを受信する手段と、
を備える手段と、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を前記第３のデバイスに提供する手段とを備え、
前記第２のデバイスは、前記セキュアリソースリクエストが認証される場合に、前記セキュアリソースへのアクセスが受け付けられる
ことを特徴とする第１のデバイス。
【請求項２０】
前記認可するためのリクエストを受信する手段は、前記セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を備える
ことを特徴とする請求項１９に記載の第１のデバイス。
【請求項２１】
前記リクエストされた認可を提供する手段は、前記セキュアリソースリクエストが認証される場合、前記リクエストされた認証メカニズムを前記第３のデバイスに提供する手段を備える
ことを特徴とする請求項２０に記載の第１のデバイス。
【請求項２２】
前記リクエストされた認可を提供する手段は、
前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された記述を前記第３のデバイスに提供する手段を備える
ことを特徴とする請求項１９に記載の第１のデバイス。
【請求項２３】
サーバデバイスであって、
複数の命令を記憶するメモリと、
前記メモリの命令を実行するプロセッサとを備え、
前記プロセッサは、
前記第１のデバイスから、セキュアリソースへアクセスするためのセキュアリソースリクエストを受信し、
ショートメッセージサービス信号により、前記セキュアリソースへのアクセスを認可するために、前記第１のデバイスとは異なる第２のデバイスとのセキュアセッションを確立し、
前記第２のデバイスから、前記セキュアリソースリクエストの認可をリクエストし、
前記セキュアリソースリクエストの認可が前記第２のデバイスから受信される場合、前記認可を検証し、
前記認可の検証に基づいて、前記セキュアリソースへのアクセスを前記第１のデバイスに許可するかまたは拒否するかを判定し、
前記セキュアリソースへのアクセスを前記第１のデバイスに許可すると判定される場合、前記第１のデバイスからの前記セキュアリソースへのアクセスを受け付ける
ための、前記メモリの命令を実行する
ことを特徴とするデバイス。
【請求項２４】
第１のデバイスであって、
複数の命令を記憶するメモリと
前記メモリの命令を実行するプロセッサとを備え、
前記プロセッサは、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第２のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信し、
前記アドレスに基づいて、第３のデバイスと前記セキュアセッションを確立し、
前記第３のデバイスから、前記セキュアリソースリクエストを認可するためのリクエストを受信し、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を前記第３のデバイスに提供する
ための、前記メモリの命令を実行し、
前記第２のデバイスは、前記セキュアリソースリクエストが認可される場合に、前記セキュアリソースへの使用が受け付けられる
ことを特徴とする第１のデバイス。
【手続補正書】
【提出日】平成21年10月20日(2009.10.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
第１のデバイスで実行される方法であって、
第２のデバイスから、セキュアリソースを使用するためのセキュアリソースリクエストを受信するステップと、
前記セキュアリソースに関連付けられている第３のデバイスを判定するステップと、
前記セキュアリソースに関連付けられている前記第３のデバイスとのセキュアセッションを確立するステップと、
前記第３のデバイスから前記セキュアリソースリクエストの認可をリクエストするステップであって、
前記セキュアリソースの記述を前記第３のデバイスへ提供するステップと、
プライベートキーにより、前記第３のデバイスによる記述の署名をリクエストするステップとを含む、
ステップと、
前記第３のデバイスから前記セキュアリソースリクエストの認可が受信される場合、前記認可を検証するステップと、
前記認可の検証に基づいて、前記セキュアリソースの使用を前記第２のデバイスに許可するかまたは拒否するかを判定するステップと、
前記セキュアリソースの使用を前記第２のデバイスに許可すると判定される場合、前記第２のデバイスからの前記セキュアリソースの使用を受け付けるステップと
を備えることを特徴とする方法。
【請求項２】
前記セキュアセッションを確立するステップは、
前記セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を生成するステップと、
前記ショートメッセージサービス信号を前記第３のデバイスに提供するステップと、
前記第３のデバイスが前記アドレスにアクセスする場合、前記セキュアセッションを確立するステップと
を備えることを特徴とする請求項１に記載の方法。
【請求項３】
前記認可を検証するステップは、前記第３のデバイスに関連付けられているパブリックキーにより前記認可を検証するステップを含む
ことを特徴とする請求項１に記載の方法。
【請求項４】
第１のデバイスであって、
複数の命令を記憶するためのメモリと、
プロセッサとを備え、
前記プロセッサは、
セキュアリソースを使用するためのセキュアリソースリクエストを第２のデバイスによって認可するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信し、
前記アドレスに基づいて、第３のデバイスとの前記セキュアセッションを確立し、
前記第３のデバイスから、前記セキュアリソースリクエストを認可するための、前記セキュアリソースの記述を含むリクエストと、プライベートキーによる前記記述を署名するためのリクエストを受信し、
前記セキュアリソースリクエストが認可される場合、リクエストされた認可を前記第３のデバイスに提供する
ための、前記メモリに記憶されている命令を実行し、
前記第２のデバイスは、前記セキュアリソースリクエストが認可される場合に、前記セキュアリソースへの使用が受け付けられる
ことを特徴とする第１のデバイス。
【請求項５】
前記プロセッサは、更に、前記セキュアリソースを使用するための認可を前記第２のデバイスに許可するかまたは拒否するかの指示を受信するための、前記メモリに記憶されている命令を実行する
ことを特徴とする請求項４に記載の第１のデバイス。
【請求項６】
前記プロセッサは、更に、前記セキュアリソースリクエストが認可される場合、前記プライベートキーにより署名された前記記述を前記第３のデバイスに提供するための、前記メモリに記憶されている命令を実行する
ことを特徴とする請求項４に記載の第１のデバイス。
【請求項７】
前記プロセッサは、更に、
前記セキュアリソースの記述を受信し、
前記セキュアリソースの使用をリクエストするユーザの識別情報を受信すること、または前記セキュアリソースリクエストを特定する乱数を受信することの一方を実行するための、前記メモリに記憶されている命令を実行する
を備えることを特徴とする請求項４に記載の方法。
【請求項８】
システムであって、
セキュアリソースへアクセスするためのセキュアリソースリクエストを第１のデバイスによって認証するために、セキュアセッションを確立するためのアドレスを含むショートメッセージサービス信号を受信する手段と、
前記アドレスに基づいて、第２のデバイスと前記セキュアセッションを確立する手段と、
前記第２のデバイスから、前記セキュアリソースリクエストを認可するためのリクエストを受信する手段であって、
前記セキュアリソースの使用をリクエストするユーザの識別情報及び前記セキュアリソースリクエストを特定する乱数の少なくとも１つと前記セキュアリソースの記述とを受信する手段と、
プライベートキーにより、前記記述を署名するためのリクエストを受信する手段と、
を備える手段と、
前記セキュアリソースリクエストが認可される場合、前記リクエストされた認可を前記第２のデバイスに提供する手段とを備え、
前記第１のデバイスは、前記セキュアリソースリクエストが認証される場合に、前記セキュアリソースへのアクセスが受け付けられる
ことを特徴とするシステム。
【請求項９】
前記認可するためのリクエストを受信する手段は、前記セキュアリソースリクエストを認証するための認証メカニズムのリクエストを受信する手段を備える
ことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記リクエストされた認可を提供する手段は、前記セキュアリソースリクエストが認証される場合、前記リクエストされた認証メカニズムを前記第２のデバイスに提供する手段を備える
ことを特徴とする請求項９に記載のシステム。
【国際調査報告】
2010519631.tif 000014
2010519631.tif 000015
2010519631.tif 000016
2010519631.tif 000017
2010519631.tif 000018