特許 5792732 モジュラーデバイス認証フレームワーク

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5792732

(24)【登録日】2015年8月14日

(45)【発行日】2015年10月14日

(54)【発明の名称】モジュラーデバイス認証フレームワーク

(51)【国際特許分類】

   G06F 21/44 20130101AFI20150928BHJP

   H04L 9/32 20060101ALI20150928BHJP

【ＦＩ】

   G06F21/44

   H04L9/00 675B

【請求項の数】13

【全頁数】25

(21)【出願番号】特願2012-532275(P2012-532275)

(86)(22)【出願日】2010年9月29日

(65)【公表番号】特表2013-506918(P2013-506918A)

(43)【公表日】2013年2月28日

(86)【国際出願番号】US2010050729

(87)【国際公開番号】WO2011041419

(87)【国際公開日】20110407

【審査請求日】2013年9月24日

(31)【優先権主張番号】12/570,416

(32)【優先日】2009年9月30日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】506329306

【氏名又は名称】アマゾン テクノロジーズ インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ジョエル シー．ヘッグ

(72)【発明者】

【氏名】シッダールタ スリラム

(72)【発明者】

【氏名】カムレシュ ティー．タルレージャー

【審査官】 金沢 史明

(56)【参考文献】

【文献】 特開２００６−０３１５２２（ＪＰ，Ａ）

【文献】 特開平１０−３０４３３３（ＪＰ，Ａ）

【文献】 特開２００３−３０８２９７（ＪＰ，Ａ）

【文献】 特開２００７−２５７４２６（ＪＰ，Ａ）

【文献】 特開２００９−２９０６４８（ＪＰ，Ａ）

【文献】 特開２００５−１３５４１２（ＪＰ，Ａ）

【文献】 特開２００５−１０２１８８（ＪＰ，Ａ）

【文献】 特開２００４−０２１６８６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００７／０１１３０８６（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３０−２１／４６

Ｈ０４Ｌ ９／３２

(57)【特許請求の範囲】

【請求項1】

サービスへのアクセスを提供するために、１つ以上のコンピューティングデバイスで実行される方法であって、
１つ以上の前記コンピューティングデバイスによって、前記サービスへのアクセスをリクエストしているデバイスを認証する複数の認証モジュールを格納することであって、前記デバイスは、少なくとも、第１のデバイスタイプを有する第１の複数のデバイスと、第２のデバイスタイプを有する第２の複数のデバイスとを含む、格納することと、
１つ以上の前記コンピューティングデバイスによって、前記第１のデバイスタイプに特化した認証スキームを使用して、前記第１の複数のデバイスの認証を実行するように、前記複数の認証モジュールのうちの第１の認証モジュールを構成することと、
１つ以上の前記コンピューティングデバイスによって、前記第２のデバイスタイプに特化した認証スキームを使用して、前記第２の複数のデバイスの認証を実行するように、前記複数の認証モジュールのうちの第２の認証モジュールを構成することと、
１つ以上の前記コンピューティングデバイスによって、第３のデバイスタイプに対応するリクエストを受信するように、前記複数の認証モジュールのうちの第３の認証モジュールを構成することであって、前記複数の認証モジュールのうち第３の認証モジュールは、前記第３のデバイスタイプを認証するための代替の認証スキームを有する信頼できるパートナーデバイスへ、前記第３のデバイスタイプに対応するリクエストを伝送し、前記代替の認証スキームは、前記信頼できるパートナーデバイスが前記サービスへのアクセスのために前記リクエストしているデバイスへトークンを提供することを含み、前記トークンは、前記リクエストしているデバイスのデバイスタイプ識別子に少なくとも部分的に基づいている、構成することと、
１つ以上の前記コンピューティングデバイスによって、前記サービスにアクセスするためのリクエストを前記サービスへのアクセスをリクエストしているデバイスから受信することであって、前記リクエストは、前記サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む、受信することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストから前記デバイスタイプ識別子を抽出することと、
１つ以上の前記コンピューティングデバイスによって、前記デバイスタイプ識別子は、前記第１のデバイスタイプと対応するか、前記第２のデバイスタイプと対応するか、または前記第３のデバイスタイプと対応するかを判定することと、
１つ以上の前記コンピューティングデバイスによって、前記デバイスタイプ識別子が前記第１のデバイスタイプと対応する場合に、前記第１の認証モジュールを選択することと、前記デバイスタイプ識別子が前記第２のデバイスタイプと対応する場合に、前記第２の認証モジュールを選択することと、前記デバイスタイプ識別子が前記第３のデバイスタイプと対応する場合に、前記第３の認証モジュールを選択することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストしているデバイスが前記サービスにアクセスすることが許可されているかどうかを判定するために、前記選択された認証モジュールを使用して前記リクエストを認証することであって、それによって前記リクエストしているデバイスに特化した前記認証スキームを使用して、前記リクエストしているデバイスの認証を実行することと、
１つ以上の前記コンピューティングデバイスによって、前記選択された認証モジュールが、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されていることを判定する場合には、前記サービスへのアクセスを提供し、前記選択された認証モジュールが、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されていないことを判定する場合には、前記サービスへのアクセスを回避することと
を含む方法。

【請求項2】

サービスへのアクセスを提供するために、１つ以上のコンピューティングデバイスで実行される方法であって、
１つ以上の前記コンピューティングデバイスによって、前記サービスにアクセスするためのリクエストを前記サービスへのアクセスをリクエストしているデバイスから受信することであって、前記リクエストは、前記サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む、受信することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストから前記デバイスタイプ識別子を抽出することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストしているデバイスについての対応するデバイスタイプを判定することと、
１つ以上の前記コンピューティングデバイスによって、前記デバイスタイプ識別子に基づいて、複数の認証モジュールから認証モジュールを選択することであって、前記複数の認証モジュールから前記認証モジュールを選択することは、対応する前記デバイスタイプが、前記複数の認証モジュールのうちの他の認証モジュールによって認識されないデバイスタイプ識別子を有する認識されないデバイスタイプであることに基づいて選択される、複数の認証モジュールから認証モジュールを選択することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストしているデバイスが前記サービスにアクセスすることが許可されているかどうかを判定するために、前記選択された認証モジュールを使用して前記リクエストを認証することであって、前記認証することは、信頼できるパートナーデバイスへ前記認識されないデバイスタイプに対応する前記リクエストを伝送することを含み、前記信頼できるパートナーデバイスは、前記リクエストしているデバイスに前記サービスへのアクセスを認証するトークンを提供し、前記トークンは、前記リクエストしているデバイスの前記デバイスタイプ識別子に少なくとも部分的に基づいている、認証することと、
１つ以上の前記コンピューティングデバイスによって、少なくとも、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されているという判定に基づいて、前記サービスへのアクセスを提供することと、前記選択された認証モジュールが、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されていないと判定することに応じて、前記サービスへのアクセスを回避することと
を含む方法。

【請求項3】

前記選択された認証モジュールは、前記リクエストしているデバイスが、前記サービスにアクセスすることを認証されているかどうかを判定するために、前記リクエストしているデバイスと機密情報データを共有する、請求項２に記載の方法。

【請求項4】

複数のデバイスタイプを有する複数のデバイスは、前記選択された認証モジュールによって前記サービスにアクセスする、請求項２に記載の方法。

【請求項5】

共通のＵＲＬを使用して、前記認証モジュールのうちの少なくとも２つがアクセスされる、請求項２に記載の方法。

【請求項6】

前記信頼できるパートナーデバイスは、前記リクエストしているデバイスへトークンを提供し、前記方法は、
１つ以上の前記コンピューティングデバイスによって、前記リクエストしているデバイスから前記トークンのコピーを受信することと、
１つ以上の前記コンピューティングデバイスによって、前記トークンの前記コピーが本物であるという判定に基づいて、前記サービスへのアクセスを提供することと
をさらに含む請求項２に記載の方法。

【請求項7】

前記トークンは、非公開／公開キーペアから公開キーに対応する非公開キーで暗号化され、前記選択された認証モジュールは、前記トークンが本物であるかどうかを判定するために、前記対応する公開キーで前記トークンを復号化すること、
をさらに含む請求項６に記載の方法。

【請求項8】

前記トークンは、前記リクエストしているデバイスから受信したユーザ名とパスワードとの組み合わせが前記信頼できるパートナーデバイスによって検証されることに応じて、前記信頼できるパートナーデバイスによって、前記リクエストしているデバイスへ提供される、請求項６に記載の方法。

【請求項9】

１つ以上の前記コンピューティングデバイスによって、前記リクエストしているデバイスから前記リクエストを受信する前に、前記リクエストしているデバイスへ認証トークンを提供することと、
１つ以上の前記コンピューティングデバイスによって、前記リクエストは、前記認証トークンに付随して生じることを検証することにより、前記選択された認証モジュールを使用して前記リクエストを認証することと
をさらに含む請求項２に記載の方法。

【請求項10】

サービスへのアクセスを提供するためのサーバであって、前記サーバは、
プログラム命令を実行するためのプロセッサと、
前記プログラム命令を格納するコンピュータ可読記録媒体であって、前記プログラム命令は、前記プロセッサによって実行される場合に、
サービスにアクセスするためのリクエストを受信し、前記リクエストは、前記サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含み、
前記リクエストから前記デバイスタイプ識別子を抽出し、
前記リクエストしているデバイスについての対応するデバイスタイプを判定し、
前記デバイスタイプ識別子に基づいて、複数の認証モジュールから認証モジュールを選択し、前記複数の認証モジュールから前記認証モジュールを選択することは、対応する前記デバイスタイプが、前記複数の認証モジュールのうちの他の認証モジュールによって認識されないデバイスタイプ識別子を有する認識されないデバイスタイプであることに基づいて選択され、
前記リクエストしているデバイスが、前記サービスにアクセスすることが許可されているかどうかを判定するために、前記選択された認証モジュールを使用して、前記リクエストしているデバイスの前記デバイスタイプに関する前記リクエストを認証し、前記認証することは、信頼できるパートナーデバイスへ前記認識されないデバイスタイプに対応する前記リクエストを伝送することを含み、前記信頼できるパートナーデバイスは、前記リクエストしているデバイスへ前記サービスへのアクセスを認証するトークンを提供し、前記トークンは、前記リクエストしているデバイスのデバイスタイプ識別子に少なくとも部分的に基づいており、
少なくとも、前記リクエストしているデバイスが、前記サービスにアクセスすることを認証されているという判定に基づいて、前記サービスへのアクセスを提供し、前記サービスへのアクセスを提供することは、前記リクエストしているデバイスから前記トークンのコピーを受信し、および前記トークンの前記コピーが本物であるという判定をすることを含む、
プロセスを実行するコンピュータ可読記録媒体と
を備えるサーバ。

【請求項11】

前記選択された認証モジュールは、前記リクエストしているデバイスが、前記サービスにアクセスすることを認証されているかどうかを判定するために、前記リクエストしているデバイスと機密情報データを共有する、請求項１０に記載のサーバ。

【請求項12】

コンピュータに、サービスへのアクセスを提供する方法を実行させるためのプログラムを記録したコンピュータ可読記録媒体であって、前記方法は、
サービスにアクセスするためにリクエストを受信するステップであって、前記リクエストは、前記サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む、受信するステップと、
前記リクエストから前記デバイスタイプ識別子を抽出するステップと、
前記リクエストしているデバイスについての対応するデバイスタイプを判定するステップと、
前記デバイスタイプが複数の認証モジュールのうちの他の認証モジュールによって認識されないデバイスタイプ識別子を有する認識されないデバイスタイプであることに基づいて、前記複数の認証モジュールから認証モジュールを選択するステップと、
前記リクエストしているデバイスが前記サービスにアクセスすることが許可されているかどうかを判定するために、前記選択された認証モジュールを使用して前記リクエストを認証するステップであって、前記認証するステップは、代替の認証スキームを有する信頼できるパートナーデバイスへ前記認識されないデバイスタイプに対応する前記リクエストを伝送するステップを含み、前記代替の認証スキームは、前記リクエストしているデバイスへ前記サービスへのアクセスを認証するトークンを提供し、前記トークンは、前記リクエストしているデバイスのデバイスタイプ識別子に少なくとも部分的に基づいている、認証するステップと、
少なくとも、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されているという判定に基づいて、前記サービスへのアクセスを提供するステップであって、前記サービスへのアクセスを提供するステップは、前記リクエストしているデバイスから前記トークンのコピーを受信するステップと、および前記トークンの前記コピーが本物であるという判定をするステップを含む、サービスへのアクセスを提供するステップと
を含むコンピュータ可読記録媒体。

【請求項13】

前記選択された認証モジュールは、前記リクエストしているデバイスが前記サービスにアクセスすることを認証されているかどうかを判定するために、前記リクエストしているデバイスと機密情報データを共有する、請求項１２に記載のコンピュータ可読記録媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モジュラーデバイス認証フレームワークに関する。

【背景技術】

【0002】

オンラインエントリは、他の可能性の中でも、パーソナルコンピュータ（ＰＣ）、個人情報端末（ＰＤＡ）、携帯電話、ポケットＰＣ、スマートフォン、セットトップボックス、デジタルビデオレコーダ（ＤＶＲ）、およびゲーム機を含む、種々の異なるクライアントデバイスへ、幅広い種々のサービスを提供する。これらのクライアントデバイスは、多くの場合、オンラインストアまたは聴覚的／視覚的コンテンツ、ソフトウェアプログラム、デジタル書籍、もしくは他の電子コンテンツの他のプロバイダ等の種々のウェブサービスにアクセスする。多くの場合において、特定のウェブサービスのための異なるクライアントデバイスによるリクエストは、ウェブサービスがリクエストを引き受ける前に認証しなければならない。

【0003】

異なるクライアントデバイスは、多くの場合、ウェブサービスへのアクセスを提供する異なる認証メカニズムをサポートする。例えば、いくつかのデバイスタイプは、デバイスの特定のブランドに一意の独自の認証メカニズムを使用してもよい。他のデバイスタイプは、セキュアソケットレイヤ（「ＳＳＬ」）等の、より一般的なアプリケーションの認証メカニズムを使用してもよい。いくつかの場合では、この問題は、各ウェブサービスが特定の認証メカニズムを実装するように、デバイスの各タイプに別々のウェブサービスを提供することにより解決される。しかしながら、このようにして別々のウェブサービスが提供される場合、エンティティは特定のデバイスタイプに適合された別々のウェブサービスとして、各認証スキームを実装する必要があるため、種々のウェブサービスの間の労力の実質的な重複する場合がある。さらに、ベンダーは、ＵＲＬ（Uniform Resource Locators）等の各ウェブサービスについて、異なるアドレスを使用してもよい。これは、複数のデバイスタイプを有するユーザに、何らかの混乱を生じさせる場合がある。例えば、ユーザは、単一のベンダーがユーザの各デバイスについて、複数のウェブサイトおよび対応するＵＲＬを有することに気付いていない場合がある。このため、ユーザは、ＵＲＬが別のデバイスで適正に機能している場合であっても、１つのデバイスでウェブサービスにアクセスしようとする際に、正しくないＵＲＬを使用する場合がある。既存のメカニズムは、例えば、デバイスを正しいＵＲＬにリダイレクトさせることで、この問題に対処できるが、これらのメカニズムは、その場しのぎであり、すべてのデバイスタイプによってサポートされていない可能性がある。従って、従来のデバイス認証メカニズムのこれらの制限を克服するための、システムおよび方法が必要である。

【図面の簡単な説明】

【0004】

本開示に組み込まれ、かつ本開示一部を成す添付の図面は、種々の開示された実施形態を示す。各図について説明する。

【図1】サービスへのアクセスを提供するためのシステムの一例の図である。

【図2】サーバのアーキテクチャの一例の図である。

【図3】認証モジュールのアーキテクチャの一例の図である。

【図4】別の認証モジュールのアーキテクチャの一例の図である。

【図5】サービスへのアクセスを提供するためのルーチンの一例の流れ図である。

【図6】デバイスリクエストを認証するためのルーチンの一例の流れ図である。

【図7】デバイスリクエストを認証するための別のルーチンの一例の流れ図である。

【発明を実施するための形態】

【0005】

以下の発明を実施するための形態では、添付の図が参照される。可能な場合、同じまたは同様のパーツを参照するために、図および以下の記載において同じ参照番号が使用される。いくつかの例示的な実施形態が本明細書に記載されるが、修正、適合および他の実装が可能である。例えば、図に示される構成要素に置換、追加または修正を行ってもよく、本明細書に記載される例示的な方法は、ステップを置換、順序の付け直し、または開示された方法にステップを追加することで、修正してもよい。従って、以下の発明を実施するための形態は、開示された実施形態を制限するものではない。代わりに、添付の特許請求の範囲により、適正な範囲が定義される。

【0006】

開示された実施形態は、ウェブサービス等のサービスへのアクセスを提供するためのシステムおよび方法を提供する。システムおよび方法は、デバイスタイプが異なる認証スキームを実装する場合でも、多数の異なるデバイスタイプが、単一のウェブサービスにアクセスできるようにしてもよい。例えば、ウェブサービスを提供するサーバは、いくつかのデバイスタイプに特化した認証モジュールを格納してもよい。特定のデバイスリクエストがウェブサービスにアクセスする場合、サーバは、リクエストからデバイスタイプ識別子を抽出してもよい。サーバは、次いで、リクエストしているデバイスを認証するための適切な認証モジュールを選択してもよい。

【0007】

開示された実施形態に従い、コンピュータで実装される方法は、サービスへのアクセスを提供する。本方法に従い、認証モジュールは、サービスへのアクセスをリクエストしているデバイスを認証するために格納される。デバイスは、少なくとも、第１のデバイスタイプを有する第１の複数のデバイスおよび第２のデバイスタイプを有する第２の複数のデバイスを含む。認証モジュールのうちの第１の１つは、第１のデバイスタイプに特化した認証スキームを使用して、第１の複数のデバイスの認証を実行するように構成される。認証モジュールのうちの第２の１つは、第２のデバイスタイプに特化した認証スキームを使用して、第２の複数のデバイスの認証を実行するように構成される。サーバは、サービスにアクセスするためのリクエストを受信し、リクエストは、サービスをリクエストしているデバイスのデバイスタイプ識別子を含む。デバイスタイプ識別子がリクエストから抽出され、方法は、デバイスタイプ識別子が、第１のデバイスタイプまたは第２のデバイスタイプと対応するかどうかを判定する。第１の認証モジュールは、デバイスタイプ識別子が第１のデバイスタイプと対応する場合に選択され、第２の認証モジュールは、デバイスタイプ識別子が第２のデバイスタイプと対応する場合に選択される。リクエストは、リクエストしているデバイスがサービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用して認証され、これにより、リクエストしているデバイスに特化した認証スキームを使用して、リクエストしているデバイスの認証を実行する。選択された認証モジュールが、リクエストしているデバイスがサービスへのアクセスが認証されていることを判定する場合、サービスへのアクセスが提供される。選択された認証モジュールが、リクエストしているデバイスがサービスにアクセスすることを認証されていないと判定する場合、サービスへのアクセスは回避される。

【0008】

別の開示された実施形態に従う、コンピュータで実装される方法は、サービスへのアクセスを提供する。本方法に従い、サービスにアクセスするためのリクエストが受信され、リクエストは、サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む。デバイスタイプ識別子はリクエストから抽出され、リクエストしているデバイスの対応するデバイスタイプが判定される。認証モジュールは、デバイスタイプ識別子に基づいて複数の認証モジュールから選択され、選択された認証モジュールは、リクエストしているデバイスのデバイスタイプに対する認証スキームを実装する。リクエストは、リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用して認証される。少なくとも、リクエストしているデバイスが、サービスにアクセスすることを認証されているという判定に基づいて、サービスへのアクセスが提供される。

【0009】

別の開示された実施形態に従い、サーバは、サービスへのアクセスを提供する。サーバは、プログラム命令を実行するためのプロセッサ、およびプログラム命令を格納するコンピュータ可読媒体を含む。プロセッサによって実行される場合、プログラム命令は、サービスにアクセスするためのリクエストを受信するように、プロセスを実行する。リクエストは、サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む。プログラム命令は、リクエストからデバイスタイプ識別子を抽出し、リクエストしているデバイスに対応するデバイスタイプを判定する。プログラム命令は、デバイスタイプ識別子に基づいて複数の認証モジュールから認証モジュールを選択し、選択された認証モジュールは、リクエストしているデバイスのデバイスタイプに対する認証スキームを実装する。プログラム命令は、リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用してリクエストを認証し、少なくとも、リクエストしているデバイスがサービスにアクセスすることを認証されているという判定に基づいて、サービスへのアクセスを提供する。

【0010】

図１は、開示された実施形態に従う、サービスへのアクセスを提供するためのシステム１００の一例である。システム１００は、サーバ上で実行するサービス（例えばウェブサービス）にアクセスするための１つ以上のクライアントデバイスの機能性を提供してもよい。システム１００に示されるように、クライアント１１０、１２０、および１３０、サーバ１４０、証明機関１５０、信頼できないクライアントデバイス１７０、信頼できるパートナーサーバ１８０、およびレガシーデバイス１９０は、ネットワーク１６０に接続される。特定の数の構成要素が図１に示されているが、当業者は、任意の数のこれらの構成要素が提供されてもよいことを理解するであろう。当業者は、さらに、システム１００の１つ以上の構成要素によって提供される機能が１つの構成要素に組み込まれてもよく、または複数の構成要素にわたって分散されてもよいことを認識するであろう。例えば、サーバ１４０は、いくつかのメインサーバと共にいくつかのバックアップサーバを含むサーバファームを使用して実装されてもよい。さらに、サーバ１４０は、本明細書に記載される種々の処理ステップを、複数のサーバにわたって分散することで、実装されてもよい。ネットワーク１６０は、クライアントデバイス１１０、１２０、および１３０、サーバ１４０、証明機関１５０、信頼できないクライアントデバイス１７０、信頼できるパートナーサーバ１８０、およびレガシーデバイス１９０等のシステム１００内の種々の構成要素の間に通信を提供する。ネットワーク１６０は、共有ネットワーク、公開ネットワーク、または非公開ネットワークであってもよく、ワイドエリアネットワークまたはローカルエリアネットワークを包含してもよく、有線および／または無線通信ネットワークの任意の適した組み合わせを通して実装してもよい。さらに、ネットワーク１６０は、イントラネットまたはインターネットを含んでもよい。

【0011】

サーバ１４０は、コンピュータプログラムによって選択的に作動または再構成してもよい、１つ以上のプロセッサ１４５を有する、汎用コンピュータ（例えばパーソナルコンピュータ、ネットワークコンピュータ、サーバ、またはメインフレームコンピュータ）を備えてもよい。プロセッサ１４５は、メモリ１４６からの処理の命令を読み込み、かつ命令を実行することにより、開示された実施形態に従うステップまたは方法を実行してもよい。具体的には、ウェブサービス１４１およびウェブサービス１４２は、プロセッサ１４５による実行に適した、メモリ１４６に格納された命令として実装されてもよい。メモリ１４６は、ソフトウェアと同様にデータを格納する１つ以上のメモリまたは格納デバイスであってもよい。メモリ１４６は、例えば、ＲＡＭ、ＲＯＭ、磁気格納装置、または光学格納装置のうちの１つ以上を含んでもよい。さらに、メモリ１４６は、プロセッサ１４０によって実行される場合、以下に記載される１つ以上のステップを実行するプログラムモジュールを格納してもよい。

【0012】

他の実施形態では、サーバ１４０は、開示された実施形態に従う方法を実行するように、特に構成されてもよい。例えば、本明細書において開示された処理ステップのうちの１つ以上を、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）、特定用途向け集積回路（「ＡＳＩＣ」）または適したチップセット上に実装してもよい。本明細書に記載される暗号化および復号化ステップは、かかるハードウェアデバイス上での実装に特に適している場合がある。サーバ１４０は、ウェブサービス１４１およびウェブサービス１４２等の種々のサービスへのアクセスを提供してもよい。サーバ１４０は、クライアントデバイス１１０、１２０、および１３０、および／またはかかるクライアントデバイスを動作するユーザを認証するための機能性を提供してもよい。例えば、ネットワーク１５０上で聴覚／視覚的またはソフトウェアコンテンツを提供するエンティティは、ウェブサービス１４１および１４２を使用して、かかるコンテンツを提供してもよい。

【0013】

クライアントデバイス１１０、１２０、および１３０が、異なる通信プロトコルまたはデータフォーマットを使用してもよいように、サーバ１４０は、さらに、その開示が、参照することによりその全体が本明細書に明示的に組み込まれる、2008年6月30日出願の米国出願番号第12／165,188号“Client-to-Service Compatibility Framework”により詳細に記載される、デバイス互換性レイヤ１４３も含んでもよい。例えば、デバイス互換性レイヤ１４３は、クライアントデバイス１１０、１２０、および１３０からの通信を、ウェブサービス１４１および１４２と互換可能な形態に変換してもよい。サーバ１４０は、さらに、以下により詳細に記載されるように、ウェブデバイス１１０、１２０、および１３０を認証するためのデバイス認証レイヤ１４４を含んでもよい。

【0014】

証明機関１５０は、コンピュータプログラムによって選択的に作動または再構成されてもよい１つ以上のプロセッサ（図示せず）を有する汎用コンピュータ（例えばパーソナルコンピュータ、ネットワークコンピュータ、サーバ、またはメインフレームコンピュータ）を含んでもよい。さらに、証明機関１５０は、サーバ１４０、さらに、クライアントデバイス１１０、１２０および１３０と、ネットワーク１６０を介して通信してもよい。証明機関１５０は、サーバ１４０に関する上記の記載と同様の方法で、サーバファーム、分散技術、およびソフトウェアおよびハードウェアの種々の組み合わせを使用して実装されてもよい。証明機関１５０は、以下により詳細に記載されるように、デジタル証明書に含まれるデジタル署名を生成するための暗号化装置１５１を含んでもよい。

【0015】

クライアントデバイス１１０、１２０、および１３０は、サーバ１４０および証明機関１５０と通信するための任意のタイプのデバイスであってもよい。例えば、クライアントデバイス１１０、１２０、および１３０は、パーソナルコンピュータ、ハンドヘルドデバイス（例えばＰＤＡ、スマートフォンなどのような携帯電話、など）、テレビ、デジタル音楽プレーヤー、セットトップボックス、デジタルビデオレコーダ（ＤＶＲ）、もしくゲーム機、または任意の他の適切なコンピューティングプラットフォームあるいはネットワーク１６０とデータを交換する能力を有するデバイスにしてもよい。クライアントデバイス１１０、１２０、および１３０は、それぞれ、例えば、１つ以上のプロセッサおよび１つ以上のメモリ（図示せず）を含んでもよい。ユーザは、ウェブブラウザ等のクライアントデバイス１１１、１２１、および１３１上に実装される適したアプリケーション論理を通して、ネットワーク１６０によって、サーバ１４０上のウェブサービス１４１および１４２にアクセスしてもよい。例えば、サーバ１４０は、クライアントデバイス１１１、１２１、および１３１上のアプリケーション論理によって処理され、ユーザに表示されるドキュメント（例えばウェブページ）を伝送してもよい。ドキュメントは、ユーザがウェブサービス１４１およびウェブサービス１４２等のサーバ１４０によって提供される１つ以上のセキュアなサービスにログオンするためのオプションを含んでもよい。例えば、ユーザは、ユーザ名（例えば電子メールアドレス）およびパスワード等の証明書を提供することにより、クライアントデバイス１１０、１２０、および１３０上で使用するためのデジタルコンテンツにアクセスするために、ウェブサービス１４１および１４２にログオンしてもよい。

【0016】

信頼できないクライアントデバイス１７０は、上記に記載されるように、クライアントデバイス１１０、１２０、および１３０と同様であってもよい。しかしながら、信頼できないクライアントデバイス１７０は、サーバ１４０上で利用可能な認証メカニズムをサポートしないデバイスタイプであってもよい。信頼できるパートナーサーバ１８０は、上記に記載されるように、サーバ１４０と同様であってもよい。信頼できるパートナーサーバ１８０は、ウェブサービス１４１および１４２と同様であってもよい、ウェブサービス１８１へのアクセスを提供してもよい。信頼できないクライアントデバイス１７０は、ウェブサービス１４１および１４２にアクセスするために、信頼できるパートナーサーバ１８０と通信してもよい。例えば、信頼できないクライアントデバイス１７０は、信頼できるパートナーサーバ１８０によって認証してもよく、信頼できるパートナーサーバ１８０は、信頼できないクライアントデバイス１７０に、セキュアなトークンを提供してもよい。信頼できないクライアントデバイス１７０は、次いで、ウェブサービス１４１へアクセスするために、セキュアなトークンを使用してもよい。

【0017】

サーバ１４０は、ウェブサービス１４１および１４２にアクセスするために、クライアントデバイス１１０〜１３０、信頼できないクライアントデバイス１７０、およびレガシーデバイス１９０から、リクエストを受信してもよい。サーバ１４０は、次いで、各リクエストを認証するための適切な認証モジュールを選択してもよい。選択された認証モジュールは、リクエストを発行するデバイスに依存してもよい。このようにして、サーバ１４０は、選択された認証モジュールを介して、デバイスタイプに特化した認証スキームを提供してもよい。

【0018】

図２は、開示された実施形態に従う、サーバ１４０のアーキテクチャの一例の図を示す。上記されるように、サーバ１４０は、クライアントデバイス１１０、１２０および１３０から、ウェブサービス１４１および１４２と互換性のある形態へ通信を変換するためのデバイス互換性レイヤ１４３を含んでもよい。サーバ１４０は、さらに、認証モジュール２２１〜２２５を使用して、クライアントデバイス１１０、１２０、および１３０を認証するためのデバイス認証レイヤ１４４も含んでもよい。サーバ１４０は、以下により詳細に記載されるように、クライアントデバイス１１０、１２０および１３０から認証モジュール２２１〜２２５のうちの適切な１つへ、リクエストを経路指定するために総合的に役立つ、認証フィルタ２２６およびモジュールセレクタ２２７をさらに含んでもよい。

【0019】

クライアントリクエストが認証モジュール２２１〜２２５のうちの１つによって認証された後、リクエストは、ウェブサービス１４１またはウェブサービス１４２等の適切なサービスに受け渡される。代替的に、リクエストが認証されない場合、適切な認証モジュールは、サービスにリクエストを経路指定しなくてもよい。ウェブサービス１４１は、認証後にほとんどのリクエストが経路指定される、「デフォルト」または「標準」のウェブサービスであってもよい。ウェブサービス１４２は、組み込まれた認証メカニズムを有するレガシーウェブサービスであってもよく、レガシーデバイス１９０等の特定のレガシーデバイスタイプに特化してもよい。以下に記載されるように、認証モジュール２２１〜２２５は、クライアントデバイス１１０、１２０、および１３０からの種々のリクエストを認証するため、認証されたリクエストは適切なウェブサービスに受け渡される。図２は構成要素の特定の番号および配設を示すが、任意の番号または配設の認証モジュールまたは他の構成要素をサーバ１４０で使用してもよい。

【0020】

図３は、開示された実施形態に従う、認証モジュール２２１のアーキテクチャの例示的なブロック図を示す。認証モジュール２２１は、多数の異なるデバイスタイプによってサポートされる認証スキームを実装してもよい。例えば、以下の記載の目的のために、クライアントデバイス１１０および１３０は、２つの異なるデバイスタイプになっている。クライアントデバイス１１０および１３０は、共に、ＳＳＬ（セキュアソケットレイヤ）、ネットワークにわたるセキュアな通信を可能にするセキュリティプロトコルを実装してもよい。認証モジュール２２１は、クライアントデバイス１１０および１３０と安全に通信し、これらを認証するために、サーバ１４０上にＳＳＬを実装してもよい。いくつかの実施形態では、認証モジュール２２１は、ＳＳＬのアップグレードバージョンであるＴＬＳ（トランスポートレイヤセキュリティ）プロトコルを実装してもよい。

【0021】

ＳＳＬ／ＴＳＬ処理を実装するために、認証モジュール２２１は、サーバ証明書３０１を格納してもよい。サーバ証明書３０１は、以下により詳細に記載されるように、１つ以上のクライアントデバイスに対してサーバ１４０を認証するように使用されてもよい。認証モジュール２２１は、１つ以上のクライアントデバイスによる特定のＳＳＬ／ＴＳＬセッション中に通信を暗号化するためのセッションキー３０２をさらに格納してもよい。サーバ１４０は、デジタル署名を作成するために暗号化装置３０３を使用してもよく、サーバ１４０は、以下により詳細に記載されるように、デジタル署名を検証するように復号化装置３０４を使用してもよい。これらのＳＳＬ／ＴＳＬセッションは、ウェブサービス１４１から電子コンテンツをダウンロードするために、クライアントデバイスによって使用されてもよい。

【0022】

図４は、開示された実施形態に従う、認証モジュール２２２のアーキテクチャの例示的なブロック図を示す。認証モジュール２２２は、特定のデバイス製造業者に関連付けられる１つ以上のデバイスタイプによってサポートされる、独自の認証スキームを実装してもよい。さらに、クライアントデバイス１２０は、独自の認証スキームを使用するデバイスであってもよい。

【0023】

認証モジュール２２２は、デバイス１２０と安全に通信し、デバイス１２０を認証するように、サーバ１４０上の独自の認証スキームを実装してもよい。いくつかの実施形態では、認証モジュール２２２は、独自の認証スキームに関連付けられるデバイス製造業者によって提供される。認証モジュール２２２は、さらに、クライアントデバイス１２０内に格納される共有された機密情報４０１を格納してもよい。認証モジュール２２２は、さらに、クライアントデバイス１２０によって送信されるウェブサービスへアクセスするためのリクエストの署名を検証するために使用される、署名検証装置４０２を含んでもよい。認証モジュール２２３、２２４、および２２５は、種々の他の認証スキームを実装してもよい。例えば、認証モジュール２２３は、認証なしでデータを通過させるにすぎない、「ｎｏ−ｏｐ」モジュールであってもよい。開発の目的と、ウェブサービス１４２のアクセスの目的との両方のために、認証モジュール２２３を使用してもよい。リクエストを認証せずに、リクエストが認証モジュール２２３を通過できるようにすることは、ウェブサービス１４２は内部認証スキームを有するため、セキュリティを危険にさらさない。

【0024】

認証モジュール２２４は、それによって信頼できないクライアントデバイス１７０がウェブサービス１４１にアクセスできる「セッション認証」スキームを実装してもよい。これを行うには、信頼できないクライアントデバイス１７０は、信頼できるパートナーサーバ１８０と連携してもよい。信頼できるパートナーサーバ１８０は、認証モジュール２２１を使用してウェブサービス１４１にアクセスしてもよく、サーバ１４０からセキュアなトークンを獲得する。サーバ１４０は、セキュアなトークンを作成するために使用される機密情報の暗号キーを格納してもよい。代替的に、信頼できるパートナーサーバ１８０は、さらに、暗号キーのコピーを格納してもよい。かかる実施形態では、信頼できるパートナーサーバ１８０は、セキュアなトークンを作成してもよい。いずれの場合においても、セキュアなトークンは、信頼できないクライアントデバイス１７０の識別子等の暗号化されたデータを含んでもよい。信頼できるパートナーサーバ１８０がセキュアなトークンを作成する、またはサーバ１４０からセキュアなトークンを取得すると、信頼できるパートナーサーバ１８０は、次いで、信頼できないクライアントデバイス１７０へセキュアなトークンを提供してもよい。信頼できないクライアントデバイス１７０は、サーバ１４０へ、ウェブサービス１４１のリクエストを有するトークンを送信してもよく、認証モジュール２２５は、トークンを検証することにより、リクエストを認証してもよい。例えば、認証モジュール２２５は、暗号キーによってトークンを復号化すること、および信頼できないクライアントデバイス１７０の識別子を検証することにより、セキュアなトークンを認証してもよい。

【0025】

いくつかの実施形態では、セキュアなトークンは、非対称のキーペアからの非公開キーを使用して、サーバ１４０または信頼できるパートナーサーバ１８０によって作成される。かかる実施形態では、セキュアなトークンが本物であるかどうかを判定するためにセキュアなトークンを復号化するように、対応する公開キーを使用してもよい。認証モジュール２２５は、登録されたＩＰアドレスのリストを格納するＩＰホワイトリスト認証スキームを実装してもよい。認証モジュール２２５は、登録されたＩＰアドレスからのリクエストがウェブサービス１４１を通過できるようにするのみでもよい。これを行うには、認証モジュール２２５は、リクエストに関連付けられるＩＰアドレスを判定し、許容可能なＩＰアドレスのホワイトリストとＩＰアドレスを比較し、リクエストに関連付けられるＩＰアドレスがホワイトリスト上にある場合に、ウェブサービス１４１へのアクセスを提供してもよい。

【0026】

認証モジュール２２５は、ウェブサービス１４１にアクセスするために新しいデバイスタイプを統合する場合に、特に有用である場合がある。例えば、新しいデバイスタイプは、結果的には、認証モジュール２２１の認証スキームをサポートするように意図されてもよい。しかしながら、ウェブサービス１４１へアクセスするために新しいデバイスタイプを開発および統合する場合、認証モジュール２２１を使用して先行する（forego）ことがより効率的である場合がある。ウェブサービス１４１をリクエストできるデバイスを制限するためにＩＰホワイトリストを使用することにより、デバイス統合は、より迅速に進行できる。デバイス統合プロセス中、新しいデバイスタイプは、コア機能性が試験されると認証モジュール２２１を使用するように、移行されてもよい。

【0027】

図５は、開示された実施形態に従う、サービスへのアクセスを提供するためのルーチン５００の一例の流れ図である。ルーチン５００は、メモリ１４６に格納されたプログラムモジュールのうちの１つ以上に従い、プロセスを実装してもよい。

【0028】

ルーチン５００の開始時、ブロック５０１において、サーバ１４０は、クライアントデバイス１１０、１２０、および１３０、ならびに信頼できないクライアントデバイス１７０を認証するための認証モジュール２２１〜２２５を格納してもよい。上記に記載されるように、クライアントデバイス１１０、１２０、および１３０は、異なる認証スキームを使用する種々のデバイスタイプであってもよい。いくつかの実施形態では、認証モジュール２２１〜２２５は、それぞれ、共通のインターフェースを実装する１つ以上のクラスを含んでもよい。当業者には理解されるように、インターフェースは、インターフェースを実装する各クラスがサポートしなければならない一組の方法を定義してもよい。このため、認証モジュール２２１〜２２５のそれぞれは、インターフェースによって定義される共通の一組の認証方法をサポートするクラスを含んでもよい。

【0029】

ブロック５０２において、サーバ１４０は、上記に記載される特定の認証スキームを実装するように、認証モジュール２２１〜２２５を構成してもよい。例えば、管理者は、クライアントデバイス１１０および１３０によってサポートされるＳＳＬプロトコルを実装するためにアプリケーションモジュール２２１を構成するように、サーバ１４０と相互作用してもよい。管理者は、さらに、クライアントデバイス１２０によってサポートされる独自のプロトコルを実装するように、アプリケーションモジュール２２２を構成してもよい。同様に、管理者は、上記のｎｏ−ｏｐ、ホワイトリスト、およびセッション認証スキームを実装するように、アプリケーションモジュール２２３、２２４、および２２５をさらに構成してもよい。

【0030】

サーバ１４０上の外部アプリケーションソフトウェア、例えばウェブサービス１４１および１４２、デバイス互換性レイヤ２１０、認証フィルタ２２６、およびモジュールセレクタ２２７上の観点から、認証スキームは、共通のインターフェースによって定義される方法のうちの１つ以上を使用して呼び出されてもよい。このため、基礎的な認証スキームの詳細は、インターフェースを使用して要約されてもよく、外部ソフトウェアは、適切な認証モジュールを使用して、共通の方法を呼び出すことができる。

【0031】

次に、ブロック５０３において、サーバ１４０は、ウェブサービス１４１またはウェブサービス１４２にアクセスするためのリクエストを受信してもよい。上記に記載されるように、ウェブサービス１４１は、デフォルトのウェブサービスであってもよく、一方で、ウェブサービス１４２は、一般的には特定のレガシーデバイスタイプによってアクセスされるウェブサービスであってもよい。以下により詳細に記載されるように、サーバ１４０は、リクエストがウェブサービス１４１および１４２に達することができるようにする前にリクエストを認証するように、適切な認証モジュールへリクエストを経路指定してもよい。

【0032】

次に、ブロック５０４において、認証フィルタ２２６は、どのデバイスのタイプがウェブサービス１４１をリクエストしているかを判定するために、リクエストからデバイスタイプ識別子を抽出してもよい。いくつかの実施形態では、認証フィルタ２２６は、デバイスタイプ識別子のリクエストにおけるリクエストヘッダまたはパラメータリストを検索するＪ２ＥＥフィルタである。いくつかの実施形態では、対応するデバイスタイプを格納する表に対するデバイスシリアル番号またはＭＡＣ ＩＤのマッピングなどのような、デバイスタイプを判定するために他のメカニズムを使用してもよい。

【0033】

ブロックＳ５０５において、デバイス認証フィルタ２２６は、モジュールセレクタ２２７への抽出されたデバイスタイプ識別子を提供してもよい。モジュールセレクタ２２７は、抽出されたデバイスタイプ識別子に基づいてリクエストを認証するように、適切な認証装置モジュール２２１〜２２５を判定してもよい。いくつかの実施形態では、モジュールセレクタ２２７は、そのそれぞれが、認証モジュール２２１〜２２５の特定の１つにマッピングされる、デバイスタイプ識別子の表と共に構成されるｊａｖａ ｂｅａｎである。

【0034】

次に、判定ブロック５０６において、ブロック５０５において選択された認証モジュールは、リクエストを認証するかどうかを判定してもよい。以下により詳細に記載されるように、認証モジュール２２１〜２２５は、それぞれ、リクエストを認証するための異なる認証スキームを実装してもよい。しかしながら、判定ブロック５０６において、どの認証モジュールがリクエストを認証するかに関係なく、選択された認証モジュールによって実装されるもの以外に、さらなるセキュリティ技術を適用することができる。例えば、クライアントデバイスのユーザは、選択された認証モジュールによって要求される認証に加えて、ユーザ名およびパスワードを提供することにより認証されてもよい。加えて、いくつかの実施形態では、複数の認証モジュールは、総合的に、特定のリクエストを認証してもよい。

【0035】

図５に示されるように、選択された認証モジュールがリクエストを認証する場合、ルーチン５００はブロック５０７に移動する。ブロック５０７において、サーバ１４０は、リクエストされたサービス、例えばウェブサービス１４１／１４２へのアクセスを提供する。このため、リクエストしているデバイスは、ウェブサービス１４１／１４２から利用可能な電子コンテンツにアクセスできる。しかしながら、選択された認証モジュールがリクエストを認証しない場合、ルーチン５００はブロック５０８に移動し、サーバ１４０は、リクエストされたウェブサービス１４１／１４２へのアクセスを回避する。いくつかの実施形態では、リクエストしているデバイスは、無制限の認証試行回数が許可されていてもよい。他の実施形態では、リクエストしているデバイスからの以降のリクエストは、特定の回数の試行後にブロックされてもよい。

【0036】

上記されるように、ルーチン５００のブロック５０５において、サーバ１４０は、デバイスから受信されるリクエストを認証するために認証モジュールを選択してもよい。リクエストを送信するデバイスのデバイスタイプによって、ブロック５０５において異なる認証モジュールが選択される。例えば、認証モジュール２２１〜２２５のうちの任意の１つを選択してもよい。以下の記載は、認証モジュール２２１〜２２５のうちの１つを選択するための処理の概要を提供する。

【0037】

認証モジュール２２１は、クライアントデバイス１１０およびクライアントデバイス１３０の両方を認証するために使用されてもよい。クライアントデバイス１１０およびクライアントデバイス１３０は、共に認証モジュール２２１にマッピングされる異なるデバイスタイプであってもよい。クライアントデバイス１１０またはクライアントデバイス１３０のいずれかがウェブサービス１４１にリクエストを送信する場合、モジュールセレクタ２２７は、認証モジュール２２１を選択する。認証モジュール２２１は、次いで、図６に関して以下により詳細に示されるように、ＳＳＬを使用してリクエストを認証してもよい。クライアントデバイス１１０および１３０は、異なるデバイスタイプ識別子を使用する異なるタイプのデバイスであってもよいが、両方のデバイスタイプは、認証モジュール２２１にマッピングされてもよい。

【0038】

クライアントデバイス１２０等のデバイスタイプを認証するように、認証モジュール２２２を使用してもよい。従って、クライアントデバイス１２０に対する抽出されたデバイスタイプ識別子に基づいて、モジュールセレクタ２２７は、認証モジュール２２２を選択してもよい。上記に記載されるように、認証モジュール２２２は、クライアントデバイス１２０等の特定のデバイスタイプの製造業者によってサポートされる独自の認証スキームを実装する。認証モジュール２２２は、図７に関して以下により詳細に記載されるように、独自の認証スキームを使用してリクエストを認証してもよい。認証モジュール２２３は、レガシーデバイス１９０等のレガシーデバイスタイプを認証するように使用されてもよい。記載されるように、レガシーデバイス１９０は、ウェブサービス１４２、つまり、組み込まれた認証スキームを有するレガシーウェブサービスを使用する。レガシーデバイス１９０からのリクエストから抽出されたデバイスタイプ識別子に基づき、モジュールセレクタ２２７は、認証モジュール２２３を選択してもよい。記載されるように、リクエストは、認証モジュール２２３を通してウェブサービス１４２へ直接通過することが許可されているため、認証モジュール２２３は、ｎｏ−ｏｐ認証スキームを実装してもよい。しかしながら、ウェブサービス１４２は、リクエストを認証するための組み込まれたレガシー認証メカニズムを実装するため、セキュリティが維持されてもよい。いくつかの実施形態では、ウェブサービス１４２に対するリクエストは、ウェブサービス１４１へアクセスするために、リクエストから別個のＵＲＬにアクセスされてもよい。

【0039】

認証モジュール２２４は、信頼できないクライアントデバイス１７０等のデバイスを認証するように使用されてもよい。信頼できないクライアントデバイス１７０は、モジュールセレクタ２２７によって認識されないデバイスタイプ識別子を使用してもよい。デバイスタイプ識別子が信頼できるデバイスからのものではない場合、モジュールセレクタ２２７は、信頼できるパートナーサーバ１８０を通したリクエストを認証するために、認証モジュール２２４を選択してもよい。これを行うためには、信頼できないクライアントデバイス１７０は、リクエストを有する信頼できるパートナーサーバ１８０の識別子を含んでもよい。認証モジュール２２４は、セキュアなトークンを作成し、信頼できるパートナーサーバ１８０へセキュアなトークンを伝送してもよい。代替的に、信頼できるパートナーサーバ１８０は、セキュアなトークンを作成してもよい。セキュアなトークンは、暗号キーにより、信頼できないクライアントデバイス１７０の識別子等のデータを暗号化することによって作成されてもよい。

【0040】

信頼できないクライアントデバイス１７０は、サーバ１４０による直接の認証ではなく、信頼できるパートナーサーバ１８０による認証のための、ステップを用いてもよい。例えば、信頼できないクライアントデバイス１７０は、ユーザ名およびパスワードを使用して、信頼できるパートナーサーバ１８０を認証してもよい。信頼できるパートナーサーバ１８０がリクエストを認証すると、信頼できるパートナーサーバ１８０は、信頼できないクライアントデバイス１７０へセキュアなトークンを伝送してもよい。

【0041】

信頼できないクライアントデバイス１７０は、サーバ１４０との以降の通信においてセキュアなトークンを含むことにより、ウェブサービス１４１にアクセスしてもよい。例えば、認証モジュール２２４は、暗号キーによってセキュアなトークンを復号化することにより、セキュアなトークンを認証してもよい。いくつかの実施形態では、セキュアなトークンは、事前設定された期限後に期限切れとなってもよい。サーバ１４０は、期限の切れたトークンを使用するウェブサービス１４１へのアクセスを可能にしなくてもよい。

【0042】

認証モジュール２２５は、ＩＰホワイトリスト認証スキームを実装してもよい。この技術は、いかなるクライアントデバイスによる対応するサポートも、またはクライアントデバイスの修正もなしで容易に実装することができるため、認証モジュール２２５は、事実上、ウェブサービス１４１または１４２に対するいかなるリクエスト上で使用されてもよい。例えば、クライアントデバイス１１０および１３０からの任意のリクエストを認証するために、認証モジュール２２５を使用してもよい。かかる実施形態では、認証モジュール２２５は、リクエストを送信するデバイスのＩＰアドレスをチェックしてもよい。ＩＰアドレスがホワイトリスト上にある場合、認証モジュール２２５は、次いで、以降の処理のために、認証モジュール２２１へリクエストを提供することができる。認証モジュール２２５は、認証モジュール２２２、２２３、および２２４と共に、同様の方法で使用されてもよい。さらに、上記されるように、いくつかの実施形態では、リクエストのスタンドアロン認証のために認証モジュール２２５を使用してもよい。例えば、ウェブサービス１４１が新しいデバイスタイプをサポートするために試験されている場合に、デバイス統合段階において認証モジュール２２５を使用してもよい。

【0043】

いくつかの実施形態では、認証モジュール２２１〜２２５のうちの１つ以上は、リクエストしているデバイスが認証されない場合でも、ウェブサービス１４１への制限されたアクセスを提供してもよい。例えば、ウェブサービス１４１は、そのうちのいくつかが電子コンテンツにアクセスするために使用され、他のものがウェブサービス１４１の種々の特徴を閲覧するように使用される、複数の方法を提供してもよい。かかる実施形態では、認証モジュール２２１〜２２５のうちの１つ以上は、リクエストしているデバイスがウェブサービス１４１を閲覧するために使用されている方法にアクセスしている場合に、ウェブサービス１４１へのアクセスを提供してもよいが、リクエストしているデバイスの、電子コンテンツをダウンロードする方法へのアクセスを可能にする前に、認証を必要とする場合がある。
ＳＳＬ／ＴＳＬ認証

【0044】

上記に記載されるように、認証モジュール２２１は、ウェブサービス１４１のリクエストの認証を実行するために、ＳＳＬまたはＴＳＬを使用してもよい。図６は、ルーチン５００のブロック５０６を実装するために認証モジュール２２１によって使用される例示的なルーチン６００を示す。以下の記載は、クライアントデバイス１１０がウェブサービス１４１へのアクセスをリクエストしていると仮定する。しかしながら、既に記載されるように、クライアントデバイス１１０および１３０は、共に、ＳＳＬ／ＴＳＬ認証をサポートしてもよい。以下に記載されるように、クライアントデバイス１１０およびサーバ１４０の両方は、ルーチン６００を使用して互いに認証するためにステップを実行してもよい。

【0045】

ブロック６０１において、認証モジュール２２１は、クライアントデバイス１１０からウェブサービス１４１のリクエストを受信してもよい。記載されるように、リクエストは、ウェブサービス１４１から利用可能な電子コンテンツ等の、任意のタイプのセキュアなデータにアクセスするためであってもよい。さらに、記載されるように、リクエストは、モジュールセレクタ２２７から認証モジュール２２１へ受け渡されてもよい。

【0046】

次に、ブロック６０２において、サーバ１４０上の認証モジュール２２１は、格納されたサーバ証明書３０１をクライアントデバイス１１０へ送信してもよい。サーバ証明書３０１は、サーバ１４０の識別子、証明機関の識別子１５０、およびサーバ１４０に一意の公開暗号化キーを含んでもよい。サーバ証明書３０１は、さらに、証明機関１５０によって生成されるデジタル署名を含んでもよい。

【0047】

クライアントデバイス１１０がサーバ証明書３０１を受信後、ブロック６０３において、クライアントデバイス１１０は、サーバ証明書３０１を使用してサーバ１４０を認証する。例えば、クライアントデバイス１１０は、まず、サーバ証明書３０１が証明機関１５０によって作成されたことを確実にするために、デジタル署名を検証してもよい。次いで、クライアントデバイス１１０は、サーバ証明書３０１から公開暗号化キーを抽出してもよく、サーバ１４０から通信を認証するために公開暗号化キーを使用してもよい。次に、ブロック６０４において、クライアントデバイス１１０は、サーバ１４０へクライアント証明書を送信してもよい。クライアント証明書は、クライアントデバイス１１０の識別子、証明機関１５０の識別子、およびクライアントデバイス１１０に一意の公開キーを含んでもよい。クライアント証明書は、さらに、暗号化装置１５１を使用して、証明機関１５０によって作成されたデジタル署名を含んでもよい。例えば、ルーチン６００の前に、証明機関１５０は、クライアント証明書を作成し、クライアントデバイス１１０へ証明書を伝送し、クライアントデバイス１１０上にクライアント証明書を格納している場合がある。

【0048】

次に、ブロック６０５において、サーバ１４０は、クライアント証明書を使用してクライアントデバイス１１０を認証する。例えば、サーバ１４０は、最初に、サーバ証明書３０１が証明機関１５０によって作成されたことを確実にするために、クライアント証明書上のデジタル署名を検証してもよい。次いで、サーバ１４０は、クライアント証明書から公開暗号化キーを抽出してもよく、復号化装置３０４を使用してクライアントデバイス１１０からの通信を検証するために公開暗号化キーを使用してもよい。

【0049】

次に、ルーチン６００は、ブロック６０８に移動する。ブロック６０６において、クライアントデバイス１１０およびサーバ１４０は、これらの間の通信を暗号化するために使用される非公開キーを相互に確立してもよい。この非公開キーは、セッションキー３０２として図３に示される。ブロック６０９において、クライアントデバイス１１０は、セッションキー３０２によって暗号化された通信を使用してウェブサービス１４１にアクセスしてもよい。いくつかの実施形態では、セッションキー３０２は、サーバ１４０およびクライアントデバイス１１０によるより効率的な暗号化処理を可能にする、対称の暗号化キーである。

【0050】

いくつかの実施形態では、クライアントデバイス１１０は、サーバ１４０が通信に添付するデジタル署名を検証することにより、ブロック６０３においてサーバ１４０からの通信を認証してもよい。かかる実施形態では、サーバ１４０は、証明機関１５０によりルーチン６００より前にサーバ１４０に提供された一意の非公開暗号化キーにより、暗号化装置３０３を使用してデジタル署名を生成してもよい。この一意の非公開キーは、サーバ１４０に指定された一意の公開キーをさらに含む、非対称のキーペアからの１つのキーであってもよい。

【0051】

同様に、いくつかの実施形態では、サーバ１４０は、クライアントデバイス１１０が通信に添付するデジタル署名を検証することにより、ブロック６０５においてクライアントデバイス１１０からの通信を認証してもよい。かかる実施形態では、クライアントデバイス１１０は、証明機関１５０によりルーチン６００より前にクライアントデバイス１１０へ提供される一意の非公開暗号化キーを使用して、デジタル署名を生成してもよい。この一意の非公開キーは、クライアントデバイス１１０に割り当てられた一意の公開キーをさらに含む非対称のキーペアからの１つのキーであってもよい。

【0052】

さらに他の実施形態では、認証モジュール２２１は、ルーチン６００のブロックのすべてを実行しなくてもよい。例えば、別々の負荷均衡化モジュール（図示せず）を、サーバ１４０上に提供してもよい。負荷均衡化モジュールは、複数のサーバにわたって負荷を分散させる役目があってもよく、さらに、ＳＳＬ／ＴＳＬ処理も実装してもよい。かかる実施形態では、負荷均衡化モジュールは、ルーチン６００を実装し、ブロック６０５においてクライアント証明書が有効であると判定されるかどうかを示す認証モジュール２２１へ、結果を提供する。その場合、認証モジュール２２１は、ウェブサービス１４１へのアクセスを可能にする。そうではない場合、認証モジュール２２１は、ウェブサービス１４１へのアクセスを回避する。

【0053】

＜独自の認証＞
上記されるように、クライアントデバイス１２０は、独自の認証スキームをサポートしてもよく、認証モジュール２２２は、サーバ１４０上に独自の認証スキームを実装してもよい。図７は、かかる認証スキームを実装するためのルーチン７００の一例の流れ図である。ルーチン７００は、メモリ１４６に格納されたプログラムモジュールのうちの１つ以上に従うプロセスを実装してもよい。

【0054】

ブロック７０１において、共有された機密情報は、クライアントデバイス１２０に格納されてもよい。いくつかの実施形態では、共有された機密情報４０１は対称の暗号化キーである。代替的に、共有された機密情報４０１に、非対称のキーペアを使用することができる。共有された機密情報４０１が非対称のキーペアである実施形態では、クライアントデバイス１２０は、ペアからのキーのうちの１つを格納してもよく、認証モジュール２２２は、ペアからのもう一方のキーを格納してもよい。

【0055】

ブロック７０２において、共有された機密情報４０１は、共有された機密情報４０１として図４に示される、認証モジュール２２２に格納される。これは、クライアントデバイス１２０の製造業者とウェブサービス１４１のオペレータとの間で何らかの調整を必要とする場合がある。例えば、製造業者は、クライアントデバイス１２０内の改ざん防止メモリに共有された機密情報を埋め込んでもよく、また、セキュアなチャネルを通して、ウェブサービス１４１の動作へ、共有された機密情報４０１を提供する。

【0056】

ブロック７０３において、クライアントデバイス１２０は、ウェブサービス１４１のリクエストを作成してもよい。リクエストは、ウェブサービス１４１からリクエストされる特定の電子コンテンツを識別するデータの暗号化されていないブロックであってもよい。リクエストは、さらに、認証モジュール２２２へのクライアントデバイス１２０を識別する情報を含んでもよい。

【0057】

次に、ブロック７０４において、クライアントデバイス１２０は、共有された機密情報４０１を使用して、ウェブサービス１２１のリクエストに署名してもよい。例えば、クライアントデバイス１２０は、リクエストの機能に、共有された機密情報４０１を加えたものとしてハッシュを計算してもよい。クライアントデバイス１２０は、署名として、リクエストへハッシュを添付してもよい。いくつかの実施形態では、クライアントデバイス１２０は、さらに、署名されたリクエストを暗号化もしてもよい。ブロック７０５において、クライアントデバイス１２０は、署名されたリクエストをサーバ１４０へ送信してもよい。次に、ブロック７０６において、認証モジュール２２２は、署名検証装置４０２を使用してリクエスト上の署名を検証してもよい。例えば、署名検証装置４０２は、リクエストのハッシュ機能に共有された機密情報を加えたものを計算してもよく、また、ハッシュ値を付加された署名と比較してもよい。値が一致する場合、認証モジュール２２２は、リクエストがいじられていない、例えば攻撃者がリクエストを操作していないと考える。ブロック７０７において、クライアントデバイス１２０は、リクエスト上の署名が検証される場合に、ウェブサービス１４１にアクセスすることが許可されている。そうではない場合、ブロック７０８において、ウェブサービス１４１へのアクセスが回避される。

【0058】

当業者が理解されるように、ブロック５０１〜５０８、６０１〜６０９、および７０１〜７０８のうちの１つ以上は随意によるものであってもよく、特定の実施形態において、実装から省略してもよい。さらに、いくつかの実装において、ブロック５０１〜５０８、６０１〜６０７、および７０１〜７０８は、順序を付け直されてもよく、下位ステップを含んでもよく、かつ／または、追加のステップを含んでもよい。

【0059】

＜トークンのさらなる利用＞
記載されるように、認証モジュール２２４は、信頼できないクライアントデバイス１７０との通信を認証するために、セキュアなトークンを使用してもよい。記載される実装において、信頼できるパートナーサーバ１８０は、信頼できないクライアントデバイス１７０による認証処理を実行してもよく、信頼できるパートナーサーバ１８０は、信頼できないクライアントデバイス１７０へセキュアなトークンを伝送してもよい。しかしながら、セキュアなトークンの実装は、いずれかの特定の認証モジュールを使用するように制限されてはいない。むしろ、認証モジュール２２１〜２２５のうちのいずれかに加えて、セキュアなトークンを実装することができる。

【0060】

いくつかの実施形態では、セキュアなトークンは、対称の暗号キーに基づいてもよい。対称のキーは、サーバ１４０および特定のクライアントデバイスの間で、何らかの安全な方法で共有されてもよい。いくつかの実施形態では、クライアントデバイスは、対称のキーに基づいて、トークンによって事前に装着される。例えば、クライアントデバイス１１０がユーザに分散される前に、この２つのＭＡＣ ＩＤ、シリアル番号、またはこれら２つの組み合わせのハッシュ関数は、ハッシュ関数への入力として対称のキーを使用して計算されてもよい。いくつかの実施形態では、対称のキーは、ユーザがクライアントデバイス１１０を受信する時（例えばユーザがオンラインストア等の小売業者からデバイスを購入する場合）に、対応するトークンと共に生成されてもよい。他の実施形態では、トークンは、非対称のキーペアを使用して、サーバ１４０によって作成されてもよい。ペアからの非公開キーは、クライアントデバイス１１０へセキュアなトークンを提供する前に、セキュアなトークンを暗号化するように使用されてもよい。

【0061】

クライアントデバイス１１０がセキュアなトークンによって装着されると、セキュアなトークンをさらなるセキュリティのために使用してもよい。例えば、セキュアなトークンが認証モジュール２２１と共に使用される場合、ＳＳＬ／ＴＳＬセッションがサーバ１４０とクライアントデバイス１１０との間に確立されると、ユーザは、ユーザ名およびパスワードを使用して認証する必要がなくてもよい。むしろ、クライアントデバイス１１０は、セキュアなトークンをサーバ１４０へ伝送してもよい。サーバ１４０は、対称のキー、または、非対称の暗号化を使用する場合に、キーペアからの公開キーを使用して、トークンを復号化してもよい。この実装は、ユーザ名およびパスワードの代替物としてトークンを使用できるため、ユーザにとっては、ウェブサービス１４１へアクセスしたいと思うたびに、それらのユーザ名およびパスワードを提出しなければならないというユーザのいくつかの不便な点が不要となる。

【0062】

上記の記載は、例示を目的として示されている。これは包括的なものではなく、開示された形態または実施形態と全く同じものに制限するわけではない。開示された実施形態の明細書および実施を考慮することにより、当業者には、修正および適合が明らかであろう。例えば、記載された実装はソフトウェアを含むが、開示された実施形態に従うシステムおよび方法は、ハードウェアおよびソフトウェアの組み合わせまたはハードウェアのみで実装することができる。ハードウェアの例としては、パーソナルコンピュータ、サーバ、ラップトップ、メインフレーム、マイクロ〜プロセッサ等を含む、コンピューティングシステムまたは処理システムが挙げられる。さらに、開示された実施形態の態様は、メモリに格納されるものとして記載されているが、当業者は、これらの態様は、２次的な格納デバイス、例えば、ハードディスク、フロッピーディスク、もしくはＣＤ−ＲＯＭなどのような他のタイプのコンピュータ可読媒体、または他の形態のＲＡＭまたはＲＯＭ、ＵＳＢ媒体、ＤＶＤ、または他の光学ドライブ媒体にも格納することができることを、理解するであろう。

【0063】

記載および開示された方法に基づくコンピュータプログラムは、経験豊かな開発者の技術の範囲内のものである。種々のプログラムまたはプログラムモジュールを、当業者に公知の技術のいずれかを使用して作成することができ、または、既存のソフトウェアに関連して設計することができる。例えば、プログラムセクションまたはプログラムモジュールを、．Ｎｅｔ Ｆｒａｍｅｗｏｒｋ，．Ｎｅｔ Ｃｏｍｐａｃｔ Ｆｒａｍｅｗｏｒｋ（およびＶｉｓｕａｌ Ｂａｓｉｃ、Ｃ等の関連する言語）、Ｊａｖａ（登録商標）、Ｃ＋＋、ＨＴＭＬ、ＨＴＭＬ／ＡＪＡＸの組み合わせ、ＸＭＬ、またはＪａｖａアプレットを含むＨＴＭＬで、またはその手段によって設計することができる。かかるソフトウェアセクションまたはモジュールのうちの１つ以上は、コンピュータシステムまたは既存の電子メールまたはブラウザソフトウェアに統合することができる。

【0064】

第１項。
サービスへのアクセスを提供するためにコンピュータで実装される方法であって、
サービスへのアクセスをリクエストしているデバイスを認証するように認証モジュールを格納することであって、デバイスは、少なくとも、第１のデバイスタイプを有する第１の複数のデバイスと第２のデバイスタイプを有する第２の複数のデバイスとを含む、格納することと、
第１のデバイスタイプに特化した認証スキームを使用して、第１の複数のデバイスの認証を実行するように、認証モジュールのうちの第１の１つを構成することと、
第２のデバイスタイプに特化した認証スキームを使用して、第２の複数のデバイスの認証を実行するように、認証モジュールのうちの第２の１つを構成することと、
サーバにより、サービスにアクセスするためのリクエストを受信することであって、リクエストはサービスをリクエストしているデバイスのデバイスタイプ識別子を含む、受信することと、
リクエストからデバイスタイプ識別子を抽出することと、
デバイスタイプ識別子が、第１のデバイスタイプと対応するか、または第２のデバイスタイプと対応するかを判定することと、
デバイスタイプ識別子が第１のデバイスタイプと対応する場合に第１の認証モジュールを選択することと、デバイスタイプ識別子が第２のデバイスタイプと対応する場合に第２の認証モジュールを選択することと、
リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用してリクエストを認証することにより、リクエストしているデバイスに特化した認証スキームを使用して、リクエストしているデバイスの認証を実行することと、
選択された認証モジュールが、リクエストしているデバイスがサービスにアクセスすることを認証されていることを判定する場合に、サービスへのアクセスを提供することと、選択された認証モジュールが、リクエストしているデバイスがサービスにアクセスすることを認証されていないことを判定する場合に、サービスへのアクセスを回避することと、を含む、方法。

【0065】

第２項。
第３のデバイスタイプに対応するリクエストを自動的に認証するように、認証モジュールのうちの第３の１つを構成することと、
第３のデバイスタイプを認証するための組み込まれた認証スキームを有する代替のサービスに、第３のデバイスタイプに対応するリクエストを転送することと、をさらに含む、第１項に記載のコンピュータで実装される方法。

【0066】

第３項。
選択されたリクエストに関連付けられるＩＰアドレスを判定することと、
可能なＩＰアドレスのリストと、ＩＰアドレスを比較することと、
選択されたリクエストに関連付けられるＩＰアドレスが、許容可能なＩＰアドレスのリストに含まれる場合に、サービスへのアクセスを提供することにより、選択されたリクエストを認証するように、認証モジュールのうちの第３の１つを構成することをさらに含む、第１項に記載のコンピュータで実装される方法。

【0067】

第４項。
第１の認証モジュールが、リクエストしているデバイスがサービスにアクセスすることを認証されているかどうかを判定するために、セキュアソケットレイヤ（ＳＳＬ）を使用する、第１項に記載のコンピュータで実装される方法。

【0068】

第５項。
サービスへのアクセスを提供するためにコンピュータで実装される方法であって、
サービスにアクセスするためのリクエストを受信することであって、リクエストはサービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む、受信することと、
リクエストからデバイスタイプ識別子を抽出することと、
リクエストしているデバイスの対応するデバイスタイプを判定することと、
デバイスタイプ識別子に基づいて複数の認証モジュールから認証モジュールを選択することであって、選択された認証モジュールは、リクエストしているデバイスのデバイスタイプの認証スキームを実装する、選択することと、
リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用してリクエストを認証することと、
少なくとも、リクエストしているデバイスがサービスにアクセスすることを認証されているという判定に基づいて、サービスへのアクセスを提供することと、を含む、方法。

【0069】

第６項。
選択された認証モジュールは、リクエストしているデバイスが、サービスにアクセスすることを認証されているかどうかを判定するために、リクエストしているデバイスと機密情報データを共有する、第５項に記載のコンピュータで実装される方法。

【0070】

第７項。
選択された認証モジュールは、複数の方法へのアクセスを提供し、方法のサブセットは、認証されていないデバイスにアクセス可能である、第５項に記載のコンピュータで実装される方法。

【0071】

第８項。
複数のデバイスタイプを有する複数のデバイスは、選択された認証モジュールを介してサービスにアクセスする、第５項に記載のコンピュータで実装される方法。

【0072】

第９項。
認証モジュールのうちの少なくとも２つが共通のＵＲＬを使用してアクセスされる、第５項に記載のコンピュータで実装される方法。

【0073】

第１０項。
信頼できるパートナーサーバが、リクエストしているデバイスへトークンを提供する方法であって、
リクエストしているデバイスからトークンのコピーを受信することと、
トークンのコピーが本物であるという判定に基づいて、サービスへのアクセスを提供することと、をさらに含む、第５項に記載のコンピュータで実装される方法。

【0074】

第１１項。
トークンは非公開／公開キーペアから公開キーに対応する非公開キーによって暗号化され、方法は、
トークンが本物であるかどうかを判定するために、対応する公開キーによってトークンを復号化することをさらに含む、第１０項に記載のコンピュータで実装される方法。

【0075】

第１２項。
信頼できるパートナーサーバが、リクエストしているデバイスから受信されるユーザ名とパスワードとの組み合わせを検証した後で、信頼できるパートナーサーバによって、リクエストしているデバイスへトークンが提供される、第１０項に記載のコンピュータで実装される方法。

【0076】

第１３項。
リクエストしているデバイスからリクエストを受信する前に、リクエストしているデバイス内のトークンを事前格納することと、
リクエストが、事前に格納されたトークンに付随して生じることを検証することにより、選択された認証モジュールを使用してリクエストを認証すること、をさらに含む、第５項に記載のコンピュータで実装される方法。

【0077】

第１４項。
選択された認証モジュールは、リクエストしているデバイスが、サービスにアクセスすることを認証されているかどうかを判定するために、セキュアソケットレイヤ（ＳＳＬ）を使用する、第５項に記載のコンピュータで実装される方法。

【0078】

第１５項。
サービスへのアクセスを提供するためのサーバであって、サーバは、
プログラム命令を実行するためのプロセッサと、
プログラム命令を格納するコンピュータ可読媒体であって、プログラム命令は、プロセッサによって実行される場合、
サービスへのアクセスのリクエストを受信することであって、リクエストは、サービスへのアクセスをリクエストするデバイスのデバイスタイプ識別子を含む、受信し、
リクエストからデバイスタイプ識別子を抽出し、
リクエストしているデバイスに対応するデバイスタイプを判定し、
デバイスタイプ識別子に基づいて、複数の認証モジュールから認証モジュールを選択することであって、選択された認証モジュールはリクエストしているデバイスのデバイスタイプについて認証スキームを実装する、選択し、
リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用してリクエストを認証し、かつ
少なくとも、リクエストしているデバイスがサービスにアクセスすることを認証されているという判定に基づいて、サービスへのアクセスを提供するようにプロセスを実行する、コンピュータ可読媒体と、を備える、サーバ。

【0079】

第１６項。
選択された認証モジュールは、リクエストしているデバイスがサービスにアクセスすることを認証されているかどうかを判定するために、セキュアソケットレイヤ（ＳＳＬ）を使用する、第１５項に記載のサーバ。

【0080】

第１７項。
選択された認証モジュールは、リクエストしているデバイスが、サービスにアクセスすることを認証されているかどうかを判定するために、リクエストしているデバイスと機密情報データを共有する、第１５項に記載のサーバ。

【0081】

第１８項。
プロセッサによって実行される方法を実行するためのプログラム命令を格納するコンピュータ可読媒体であって、方法は、サービスへのアクセスを提供し、プロセッサによって実行される、
サービスにアクセスするためのリクエストを受信するステップであって、リクエストは、サービスへのアクセスをリクエストしているデバイスのデバイスタイプ識別子を含む、ステップと、
リクエストからデバイスタイプ識別子を抽出するステップと、
リクエストしているデバイスに対応するデバイスタイプを判定するステップと、
デバイスタイプ識別子に基づいて、複数の認証モジュールから認証モジュールを選択するステップであって、選択された認証モジュールは、リクエストしているデバイスのデバイスタイプのために、認証スキームを実装する、ステップと、
リクエストしているデバイスが、サービスにアクセスすることを許可されているかどうかを判定するために、選択された認証モジュールを使用してリクエストを認証するステップと、
少なくとも、リクエストしているデバイスがサービスにアクセスすることを認証されているという判定に基づいて、サービスへのアクセスを提供するステップと、を含む、コンピュータ可読媒体。

【0082】

第１９項。
選択された認証モジュールは、リクエストしているデバイスが、サービスにアクセスすることを認証されているかどうかを判定するために、セキュアソケットレイヤ（ＳＳＬ）を使用する、第１８項に記載のコンピュータ可読媒体。

【0083】

第２０項。
選択された認証モジュールは、リクエストしているデバイスが、サービスにアクセスすることを認証されているかどうかを判定するために、リクエストしているデバイスと機密情報データを共有する、第１８項に記載のコンピュータ可読媒体。

【0084】

加えて、本明細書では例示的な実施形態が記載されているが、本開示に基づいて当業者に理解されるように、同等の要素、修正、省略、組み合わせ（例えば種々の実施形態にわたる態様の）、適合、および／または変更を有する任意のおよびすべての実施形態の範囲。本特許請求の範囲における制限は、特許請求の範囲で使用される言語に基づいて幅広く解釈されるべきであり、例は非排他的であると解釈される、現在の明細書または出願の実施時において記載される例に制限されない。さらに、開示されたルーチンのブロックは、ブロックの順序の付け直しおよび／またはブロックの挿入または削除を含む、任意の方法で修正してもよい。従って、明細書および例は、以下の特許請求の範囲およびそれらの均等物の全範囲によって示される真の範囲および精神により、例示的にすぎないものとして考えられるように意図されている。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】