JP2007510235A - アプリケーション信任状を供給するための方法および装置 - Google Patents

Abstract

装置上で作動しているアプリケーションのための信任状を提供するための方法および装置。一実施形態において、方法は装置上で作動しているアプリケーションにアプリケーション信任状を供給する。この場合、アプリケーション信任状は、アプリケーションにより使用され、データサーバーに対して認証する。方法は、アプリケーション信任状を発生するための要求を受信することを含み、この場合、要求は、アプリケーション識別子を含む。また、方法は、アプリケーション識別子と、装置に関連するマスター信任状を用いてアプリケーション信任状を発生することを含む。

Description

この発明は、一般に信任状システムに関し、特に、認証とセキュリティのために装置上で作動しているアプリケーションにアプリケーション信任状を供給するための方法および装置に関する。

技術の進歩によって、広域のデータネットワークが開発され、配備された。これらのネットワークは、インターネットのような公衆のデータネットワークと、無線電気通信ネットワークのような専門分野に特化したネットワークの両方を含む。これらのネットワークは、ネットワークリソースとして利用可能な多種多様の情報およびサービスにアクセスする能力を有する。

ネットワークリソースの増大する需要がある１つの例は無線ネットワーク環境にある。無線環境では、無線電話、携帯情報端末（ＰＤＡ）およびページング装置のような様々な無線装置は、無線ネットワークを介して通信する。また、無線ネットワークは、無線装置に種々のネットワークリソースを供給するように動作するネットワークサーバーを含んでいてもよい。さらに、無線ネットワークは、インターネットのような公衆通信回線に接続されていてもよく、それにより公衆通信回線上のリソースが無線ネットワーク上の無線装置に利用可能になることができる。

典型的には、無線装置は、アプリケーションプログラムを無線ネットワークからダウンロードするかもしれない。アプリケーションは無料でダウンロードされるかもしれないし、または無線装置のユーザーにより購入されるかもしれない。無線装置のユーザーは、無制限の期間または固定の期間または使用回数に基づいた満了期間、アプリケーションまたはコンテンツを使用する権利を有効に取得する。実行中に、アプリケーションは、データサーバーから所有権データを検索しようと試みるかもしれない。例えば、アプリケーションはニュース検索アプリケーションかもしれない。そして動作中に、アプリケーションは、所有権ニュースデータサーバーからニュースデータを要求する。データを送信する前に、データサーバーは、アプリケーションがデータを受信するための権限が与えられていることを検証する必要がある。それゆえ、アプリケーションがデータサーバーに認証することが必要である。

しかしながら、すべての装置に対して異なる、装置とサーバーとの間に共有される秘密が無い限り、強力な認証は可能ではない。もしそうでないならば、アプリケーションのリバースエンジニアリングは、サーバーにアクセスするための十分な情報を明らかにするであろう。共有秘密キーは帯域外で分配されるべきであり、装置とサーバー間のネットワーク接続を介して配信されるべきではない。１つのアプローチは、製造または販売の時にすべてのデバイスに個別のキーを供給することである。このようにして、いくつかのシステムは音声通話を認証するように動作する。しかしながら、この技術は多数のアプリケーションに拡大せず、装置の購入の後にダウンロードされるアプリケーションに対して作用せず、アプリケーションベンダーは製造または販売プロセスにアクセスしなかったかもしれない。

他の技術は、各装置ユーザーに対して別個のパスワードを発行することである。この場合、パスワードは、音声メール、ｅメール、またはその他の帯域外手段を用いて配信される。これは部分的な解決を提供するかもしれない。しかしながら、この技術は、より多くのユーザー応答性を生じ、アプリケーションまたはコンテンツ開発者のためにより多くのオーバーヘッドを生じ、すべてのユーザーにより使用されるすべてのアプリケーションのためのパスワードを作成し、配信し、維持する必要を生じる。

それゆえ、必要なものは、所有権データサーバーからデータのための要求を認証するために、装置上で作動しているアプリケーションにより使用することができるアプリケーション信任状を提供するためのシステムである。

発明の概要

１つ以上の実施形態において、装置上で作動しているアプリケーションに信任状を供給する信任状システムが記載される。一実施形態において、装置上で作動しているアプリケーションは、信任状システムに送信される信任状のための要求にアプリケーション識別子を供給する。信任状システムはアプリケーション識別子とマスター信任状を用いてアプリケーションにより使用されるアプリケーション信任状を発生する。アプリケーション信任状を取得した後に、アプリケーションは、データのための要求をデータサーバーに送信する。この要求は、アプリケーション信任状とアプリケーション識別子を含む。データサーバーは要求を受信し、信任状サーバーに送信されるサーバー信任状のための要求内にアプリケーション識別子を含む。信任状サーバーは、マスター信任状のコピーを有する。信任状サーバーは、アプリケーション識別子とマスター信任状を使用し、サーバー信任状を発生する。サーバー信任状は、データサーバーに返送される。次に、データサーバーは、アプリケーション信任状をサーバー信任状と比較し、一致するなら、サーバーは、要求されたデータをアプリケーションに送信する。従って、特別なパスワードの使用無く、アプリケーションがデータサーバーに認証することが可能である。

他の実施形態において、データサーバーは、信任状検証のための要求において、アプリケーション識別子とアプリケーション信任状を信任状サーバーに送信する。信任状サーバーは、アプリケーション識別子とマスター信任状を用いてサーバー信任状を発生する。信任状サーバーは、アプリケーション信任状をサーバー信任状と比較し、２つの信任状が一致するか否かを決定する。信任状が一致するなら、信任状サーバーは、肯定的なインジケーターをデータサーバーに送信し、それによりデータサーバーに、要求されたデータをアプリケーションに送信する権限を与える。

一実施形態において、方法は、装置上で作動しているアプリケーションにアプリケーション信任状を供給する。この場合、アプリケーション信任状は、アプリケーションにより使用され、データサーバーを認証する。方法は、アプリケーション信任状を発生するための要求を受信することを含む。この場合、要求は、アプリケーション識別子を含む。また、方法は、アプリケーション識別子と、装置に関連するマスター信任状を用いてアプリケーション信任状を発生することを含む。

他の実施形態において、アプリケーション信任状を装置上で作動しているアプリケーションに供給するように動作する装置が提供される。この場合、アプリケーション信任状は、アプリケーションにより使用され、データサーバーに対して認証する。装置は、アプリケーション信任状のための要求を受信するように動作する受信ロジックを含む。この場合、要求は、アプリケーション識別子を含む。また、装置は、アプリケーション識別子とマスター信任状を用いてアプリケーション信任状を発生するように動作する発生ロジックを含む。

他の実施形態において、装置上で作動しているアプリケーションにアプリケーション信任状を供給するように動作する装置が提供される。この場合、アプリケーション信任状は、アプリケーションにより使用されデータサーバーに対して認証する。装置は、アプリケーション信任状のための要求を受信する手段を含む。この場合、要求はアプリケーション識別子を含む。また、装置は、アプリケーション識別子とマスター信任状を用いてアプリケーション信任状を発生する手段を含む。

他の実施形態において、装置内のプロセッサーにより実行されると、装置上で作動しているアプリケーションにアプリケーション信任状を供給する命令を含むコンピューター読み出し可能媒体が提供される。この場合、アプリケーション信任状は、アプリケーションにより使用されデータサーバーに対して認証する。コンピューター読み出し可能媒体は、アプリケーション信任状のための要求を受信するための命令を含む。この場合、要求は、アプリケーション識別子を含む。また、コンピューター読み出し可能媒体は、アプリケーション識別子とマスター信任状を用いてアプリケーション信任状を発生するための命令を含む。

他の実施形態において、装置上で作動しているアプリケーションを認証するように信任状サーバーを動作させるための方法が提供される。この場合、アプリケーションは、データのための要求をデータサーバーに送信し、要求は、アプリケーション信任状を含む。方法は、サーバー信任状のための要求においてアプリケーション識別子を受信することと、アプリケーション識別子とマスター信任状を用いてサーバー信任状を発生することを含む。また、方法は、サーバー信任状をデータサーバーに送信することを含む。この場合、サーバー信任状とアプリケーション信任状が一致するなら、アプリケーションは認証される。

この発明の他の観点、利点、および特徴は、以下に述べる図面の簡単な説明、発明の詳細な記載、およびクレームの再考の後で明白になるであろう。

ここに記載された実施形態の上述の観点および付随する利点は、添付された図面とともに以下の詳細な記載を参照することにより容易に明白になるであろう。

以下の詳細な記載は、装置上で作動しているアプリケーションに信任状を供給する信任状システムを記載する。装置は、デスクトップコンピューター、サーバー、または他のタイプのコンピューターのような任意のタイプの計算装置であってよい。また、システムは、タブレットコンピューター、ＰＤＡｓ、無線電話、ｅメール装置、ページャー、または任意の他のタイプのポータブル装置のようなポータブル装置に使用するのにもよく適している。それゆえ、システムは多種多様の装置に使用するのに適しているけれども、明瞭さの目的のために、この発明の実施形態は、無線装置を参照してここに記載される。

装置は、製造時に装置にインストールされた、またはパブリックディスクロージャーからマスター信任状を保護するある他の安全な手続を用いてマスター信任状のコピーを含む。マスター信任状も信任状サーバーに知られている。

１つ以上の実施形態において、信任状システムは、装置に固有のリソースのための汎用の電話を供給することによるように、装置の動作を簡単にするために使用される装置上で実行しているランタイム環境と相互作用する。そのような１つのランタイム環境は、カリフォルニア州、サンディエゴのＱＵＡＬＣＯＭＭ社により開発された無線のためのバイナリランタイム環境（ＢＲＥＷ）ソフトウエアプラットフォームである。以下の記載では、装置は、ＢＲＥＷソフトウエアプラットフォームのようなランタイム環境を実行すると仮定されるであろう。しかしながら、信任状システムの１つ以上の実施形態は、さまざまな有線および無線装置上で作動しているアプリケーションにアプリケーション信任状を供給するための他のタイプのランタイム環境とともに使用するために適している。

図１は装置上で作動しているアプリケーションにアプリケーション信任状を供給する信任状システムの一実施形態を含むデータネットワーク１００を示す。ネットワーク１００は、無線通信チャネル１０６を介してデータネットワーク１０４と通信する無線装置１０２を含む。ネットワーク１００は任意のタイプのデータネットワークであってよく、有線および無線のコンポーネントを含んでいてよい。また、ネットワーク１００は、無線装置１０２およびネットワーク１００と通信している他のエンティティにサービスを供給するように動作する信任状サーバー１０８を含む。例えば、無線装置１０２は、無線電話であってもよく、信任状サーバー１０８は、装置１０２に電気通信サービスを供給する全国的な電気通信ネットワークの一部であってもよい。また、ネットワーク１０４と通信しているのはデータサーバーである。データサーバー１１０は、マルチメディアコンテンツまたは他のタイプのデータのようなデータを、無線ネットワーク１０４と通信している装置に供給するように動作する。

一実施形態において、装置１０２は、製造中に装置にインストールされたまたはある他の安全な手続を用いることによりインストールされたマスター信任状１１４を含む。マスター信任状１１４は、装置１０２が信任サーバー１０８のような他のエンティティに対して認証することができるように公になっていない任意のタイプの適切な信任状であってよい。また、装置１０２は、信任状発生ロジック１１６を含む。信任状発生ロジック１１６は、特定の入力情報に基づいて信任状を発生する。一実施形態において、ロジック１１６は、「一方向の」発生技術を使用し、それにより発生された信任状は、信任状を発生するために使用された入力情報を決定するためにデコードまたは反転することができない。例えば、ロジック１１６は、信任状を発生するためにハッシュ関数を使用してもよい。

動作中に、信任状システムは、１つ以上の以下のステップを実行することにより装置１０２上で作動中のアプリケーションにアプリケーション信任状を供給するように動作する。

１． 装置１０２上で作動中のアプリケーションプログラム１１８は、信任状システムからアプリケーション信任状を要求する。アプリケーションは、アプリケーション信任状のための要求内にアプリケーション識別子（ＩＤ）を含む。アプリケーション信任状のための要求は１２８で示される。

２． 信任状システムは、アプリケーションＩＤおよびマスター信任状１１４を使用してアプリケーション１１８のためのアプリケーション信任状を発生する。

アプリケーション信任状は、１３０で示されるようにアプリケーション１１８に戻される。

３． アプリケーション１１８は、アプリケーション信任状および任意でＩＤを、データ取得の要求とともにデータサーバー１１０に送信する。データ取得のための要求は１２０で示される。

４． データサーバー１１０はサーバー信任状のための要求でＩＤを信任状サーバー１０８に送信する。サーバー信任状のための要求は１２２で示される。

５． 信任状サーバー１０８は、ＩＤとマスター信任状１１４を用いて、信任状サーバー１０８に配置される信任状発生ロジック１１６を用いてサーバー信任状を発生する。結果として生じるサーバー信任状は、１２４で示されるようにデータサーバーに戻される。

６． データサーバー１１０はアプリケーション信任状をサーバー信任状と比較し、２つが一致するなら、データのためのアプリケーションの要求１２０は認証され、データサーバー１１０は１２６で示されるように要求されたデータを送信する。

それゆえ、アプリケーション信任状は、ユーザー毎に変化することができるので、システムは、ユーザーとアプリケーションの両方を認証するように動作する。

図２は、装置１０２上で作動中のアプリケーションにアプリケーション信任状を供給する信任状システムの一実施形態を含む装置１０２の一実施形態を図解する機能ブロック図２００を示す。

装置１０２は、アプリケーション／ＩＤ署名チェッカー２０２、信任状発生ロジック２０６、マスター信任状２０４、アプリケーション２１０、アプリケーションＩＤ２１２およびデジタル署名２１４を含む。マスター信任状２０４は、安全な不揮発性メモリまたは他の安全なロジックに記憶される。それによりマスター信任状は、消去および権限の無い開示から保護される。署名２１４は、あるアプリケーション署名サービスまたは権限により作成され、アプリケーションをアプリケーションＩＤと結びつける。１つ以上の実施形態において、任意のタイプの変更検出技術は署名２１４の代わりに使用することができる。

アプリケーション／ＩＤ署名チェッカー２０２はデジタル署名で符号化された情報が変更されたか否かを検出する。また、それは、アプリケーションが、真に、特定のアプリケーションＩＤが割り当てられたアプリケーションであることをハンドセットが強力な方法で知ることを可能にする。例えば、アプリケーション２１０、ＩＤ２１２、および署名２１４をチェッカー２０２に供給することにより、チェッカー２０２は、デジタル署名が作成された後にアプリケーション２１０および／またはＩＤ２１２が変更されたかまたは修正されたか否かを決定することができる。１つ以上の実施形態において、チェッカー２０２は、任意のタイプの変更検出技術を用いて動作する。

信任状発生ロジックは、その入力において受信した情報に基づいて信任状を発生する。発生ロジック２０６は、「一方向」技術を用いて信任状を発生するので、信任状は、信任状を作成するために使用される情報を決定するためにデコードまたは反転することができない。

一実施形態の動作中に、アプリケーション２１０は、関連するアプリケーションＩＤ２１２および署名２１４を有する。署名２１４はアプリケーション２１０とＩＤ２１２を結びつける。署名は、アプリケーション開発者によって、またはアプリケーション開発者とは異なる第三者によって発生されたかもしれない。アプリケーション２１０は、データサーバー、例えば図１のデータサーバー１１０からデータを検索するように動作する。しかしながら、データを検索するために、アプリケーション２１０は、データサーバーに対して認証するためにアプリケーション信任状を取得する必要がある。以下の方法は、一実施形態において、どのようにして信任状システムがアプリケーション信任状をアプリケーション２１０に供給し、それにより、アプリケーション２１０がデータサーバー、例えばサーバー１１０に対して認証することができるかを記載する。

図３は、アプリケーション信任状を、装置上で作動中のアプリケーションに供給するために信任状システムを動作させるための方法の一実施形態を示す。例えば、方法３００は、図２に示される装置１０２を参照して記載されるであろう。アプリケーション２１０は装置１０２上で作動中であり、アプリケーション２１０はデータを検索するためにデータサーバーに対して認証するためにアプリケーション信任状を必要とすることを仮定するであろう。

ブロック３０２において、装置は、アプリケーション２１０および／またはＩＤ２１２が変更されたかまたは不正に関連づけられたか否かを決定するように動作する。一実施形態において、アプリケーション２１０、ＩＤ２１２、および署名２１４は、経路２２４により示されるようにチェッカー２０２に送信される。チェッカー２０２は、任意の周知の技術を用いて、アプリケーションおよび／またはＩＤ２１２が変更されなかったことを検証するように動作する。

ブロック３０４において、アプリケーションは、信任状システムからアプリケーション信任状を要求しそれによりアプリケーションは、データを検索するためにデータサーバーに認証することができる。一実施形態において、アプリケーション信任状のための要求において、経路２１６により示されるように、アプリケーションのＩＤ２１２は、信任状発生ロジック２０６に供給される。アプリケーションが、他のアプリケーションのために信任状を得るために任意のＩＤを供給することができないように、アプリケーションのＩＤ２１２はチェックされた後に供給されることに留意する必要がある。

ブロック３０６において、アプリケーション信任状は、アプリケーションのために発生される。一実施形態において、発生ロジック２０６は、アプリケーションＩＤ２１２およびマスター信任状２０４を用いてアプリケーション信任状２０８を発生する。例えば、一実施形態において、発生ロジック２０６は、ハッシュ関数を用いてアプリケーション信任状２０８を発生するので、アプリケーション信任状２０８は、マスター信任状２０４を発見するためにデコードまたは反転することはできない。次に、アプリケーション信任状２０８は、経路２１８により示されるようにアプリケーション２１０に戻される。アプリケーション信任状２０８は、「一方向」の技術を用いて発生されるので、マスター信任状２０４は、発見されたり開示されたりする危険性は決してない。

ブロック３０８において、アプリケーション信任状は、装置上で使用するためにデータを検索するためにデータサーバーに対して認証するためにアプリケーションにより使用される。例えば、アプリケーション２１０は、信任状２０８を、経路２２０により示されるように、データサーバーに対するデータのための要求において送信する。また、その要求は、アプリケーションのＩＤ２１２を含んでいてもよい。例えば、その要求は、図１のデータサーバー１１０に送信される。データサーバー１１０はすでにアプリケーションのＩＤにアクセスしているかもしれない。従って、装置がＩＤをデータサーバーに送信する必要がないかもしれない。

ブロック３１０において、アプリケーションのデータ要求は認証されていると仮定して、経路２２２に示されるように要求されたデータがデータサーバーからアプリケーション２１０に送信される。例えば、データサーバー１１０は、アプリケーション２１０から要求を受信し、要求されたデータを送信する前にアプリケーションを認証するように動作する。データサーバーにより実行される認証プロセスのより詳細な記載は、この文献の他のセクションにおいて提供される。

方法３００は、例証であることを意図しており、ここに記載された種々の実施形態の動作を制限しないことを意図している。例えば、当業者が、記載された方法のいずれかに対して、多少の変更、追加または削除を行うことは明白であろう。さらに記載された方法ステップは、記載された実施形態の範囲から逸脱することなく、結合したり、再配置したり、整理し直してもよい。

図４は、装置上で作動中のアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含むデータサーバー１１０の機能ブロック図４００を示す。例えば、サーバー１１０は、アプリケーション２１０からデータのための要求を受信し、要求は、アプリケーション信任状２０８およびアプリケーションＩＤ２１２を含む。サーバー１１０が要求を認証した後で、サーバーは、要求されたデータをアプリケーション２１０に供給する。サーバー１１０は、コンテンツサーバー４０４、コンテンツ／データ４０６、信任状および整合ロジック４０２を含む。

一実施形態において、信任状整合ロジック４１４は、アプリケーション信任状およびサーバー信任状を受信し、それらを比較するように動作する。比較４１８の結果は、コンテンツサーバー４０４に送信される。通常、信任状が値において等しい場合、結果４１８は承認されるであろう。アプリケーション信任状２０８とサーバー信任状４１４との間の本質的な差は、前者がエンドユーザー装置上で発生され、後者がサーバー上で発生されることである。

サーバー１１０の構成は、信任状システムの１つの実施形態を実施するための１つの構成にすぎないことに留意する必要がある。また、この発明の範囲内の他のサーバーまたはサーバー構成を用いて信任状システムを実施することも可能である。

図５は、装置上で作動中のアプリケーションにより供給されるアプリケーション信任状を認証するための信任状システム内のデータサーバーを動作させるための方法５００の一実施形態を示す。例えば、方法５００は、図４において示されるサーバーを参照して記載されるであろう。アプリケーション２１０が装置上で作動中であり、アプリケーション２１０は、信任状システムからアプリケーション信任状２０８を取得することが仮定されるであろう。アプリケーション２１０は、アプリケーション信任状２０８とアプリケーションＩＤ２１２をデータサーバー１１０へのデータのための要求において提出する。

ブロック５０２において、データサーバーは、装置上で作動中のアプリケーションからデータのための要求を受信する。データのための要求は、アプリケーション信任状２０８とアプリケーションＩＤ２１２を含む。

ブロック５０４において、データサーバーは、信任状サーバーからサーバー信任状を要求する。例えば、アプリケーションＩＤ２１２と認証トークン４０８は、サーバー信任状のための要求において信任状サーバーに（４１０および４１２により示されるように）送信される。例えば、要求は、信任状サーバー１０８に送信される。

ブロック５０６において、サーバー信任状は、信任状サーバーから受信される。例えば、信任状サーバー１０８は、アプリケーションＩＤ２１２と、信任状サーバー１０８に記憶されているマスター信任状２０４のコピーを用いてサーバー信任状４１４を発生する。サーバー信任状４１４は、アプリケーション信任状２０８を発生するために使用されたのと同じ信任状発生技術を用いて発生される。

ブロック５０８において、サーバー信任状４１４がアプリケーション信任状２０８と一致するか否かを決定するためにテストが行われ、それにより、アプリケーション２１０をデータ要求者として認証する。例えば、整合ロジック４０２は、任意のタイプの整合技術を用いて２つの信任状を整合する。２つの信任状が整合するなら、肯定的なインジケーターが整合出力４１８において供給される。その結果、アプリケーション２１０のデータ要求は認証され、コンテンツサーバー４０４は、アプリケーションのデータ要求を満足させるために、アプリケーション２１０にコンテンツ／データ４０６を送信するように動作する。２つの信任状が一致しないなら、否定的なインジケーターが整合出力４１８に供給され、コンテンツサーバー４０４は、データ要求に応答していかなるデータも供給しない。

方法５００は例証であることを意図しており、ここに記載された種々の実施形態の動作を制限しないことを意図している。例えば、記載された方法のいずれかに対して多少の変更、追加または削除を行うことは、当業者には明白であろう。さらに、記載された方法ステップは、記載された実施形態の範囲から逸脱することなく、結合したり、再配置したり、整理し直してもよい。

図６は、装置上で作動中のアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含むデータサーバー１１０の他の実施形態の機能ブロック図６００を示す。図６に示される実施形態において、サーバー１１０は、信任状サーバーに（４１０、４１２および６０４で示されるように）ＩＤ２１２、認証トークン４０８、およびアプリケーション信任状２０８を送る信任状送者６０２を含む。信任状サーバーは、サーバー信任状を発生し、サーバー信任状をアプリケーション信任状２０８と比較する。アプリケーション信任状とサーバー信任状が一致するなら、信任状サーバーは、権限６０６をデータサーバー１１０に送信する。権限は、（経路４１８を介して）コンテンツサーバー４０４に送られる。コンテンツサーバー４０４は次に、コンテンツ／データ４０６を要求するアプリケーション２１０に送信する。従って、図６に示される実施形態において、信任状サーバーは、アプリケーション信任状をサーバー信任状と比較するように動作する。図４の実施形態において、データサーバー１１０はこの比較を実行する。

図７は、装置上で作動中のアプリケーションに供給されるアプリケーション信任状を認証するために信任状システム内で動作する信任状サーバー１０８の一実施形態を示す。信任状サーバー１０８は、検証ロジック７０２、マスター信任状２０４および信任状発生ロジック７０６を含む。

図８は、装置上で作動中のアプリケーションにより供給されるアプリケーション信任状を認証するための信任状システム内の信任状サーバーを動作させるための方法８００の一実施形態を示す。例えば、方法８００は、図７に示される信任状サーバー１０８を参照して記載されるであろう。アプリケーション信任状２０８と一致することができるサーバー信任状を取得するためにデータサーバー１１０が信任状サーバー１０８に要求を送信したと仮定されるであろう。信任状サーバー１０８により受信されるサーバー信任状のための要求はアプリケーションＩＤ２１２と認証トークン４０８を含む。

ブロック８０２において、信任状サーバー１０８は、データサーバーからの要求を受信しサーバー信任状を取得する。例えば、データサーバー１１０は、要求を信任状サーバー１０８に送信してサーバー信任状を取得し、要求は、アプリケーションＩＤ２１２と認証トークン４０８を含む。

ブロック８０４において、信任状サーバー１０８は、認証トークン４０８を用いて検証ロジック７０２において要求を認証する。この認証は、アプリケーションＩＤ２１２により示されるアプリケーションに属するサーバー信任状４１４にアクセスすることを許可されたデータサーバーからの所定のアプリケーションＩＤ２１２に対して要求がなされたことを確信するために使用される。

ブロック８０６において、要求が検証された後、信任状発生ロジック７０６は、アプリケーションＩＤ２１２とマスター信任状２０４を使用してサーバー信任状４１４を発生する。ほとんどの実施形態において、信任状発生ロジック７０６は、エンド装置１０２上のロジック２０６と機能的に同じであろう。

ブロック８０８において、信任状サーバーは、サーバー信任状を（経路７０４により示されるように）データサーバーに送信し、それによりデータサーバーは、サーバー信任状を用いて、装置上で作動中のアプリケーションからのデータ要求を認証する。

方法８００は例証であることを意図しており、ここに記載された種々の実施形態の動作を制限しないことを意図する。例えば、記載された方法のいずれかに対して多少の変更、追加、または削除を行うことは当業者にとって明白であろう。さらに、記載された方法ステップは、記載された実施形態の範囲を逸脱することなく、結合し、再配置し、または整理し直してもよい。

図９は、装置上で作動中のアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含む信任状サーバー１０８の他の実施形態の機能ブロック図９００を示す。図９に示される実施形態において、サーバー１０８は、アプリケーション信任状２０８を受信し、信任状整合ロジック９０２を含む。

作動中に、信任状発生ロジック７０６は、サーバー信任状４１４を発生する。次に、サーバー信任状４１４は、信任状整合ロジック９０２においてアプリケーション信任状２０８と比較される。アプリケーション信任状２０８とサーバー信任状４１４が一致するなら、信任状サーバーは、権限６０６をデータサーバー１１０に送信する。従って、図９に示される実施形態において、信任状サーバー１０８は、アプリケーション信任状２０８をサーバー信任状４１４と比較するように動作し、図７の実施形態において、データサーバー１１０はこの比較を実行する。

実施
上述したシステムは、さまざまな実施において具現化してもよい相互接続された機能エレメントを含む。例えば、記載されたエレメントのいずれかが、ＣＰＵ、プロセッサー、ゲートアレイ、ハードウエアロジック、メモリ、ソフトウエア、またはハードウエアとソフトウエアの任意の組み合わせを含んでいてもよい。各システムはさらに、ここに記載された機能を実行するための機械読み出し可能な命令を実行するためのロジックを含む。

１つ以上の実施形態において、機械読み出し可能な命令は、記載したシステムのいずれかにインターフェースするコンピューター読み出し可能媒体上に記憶される。それにより命令は、実行のためにシステムにダウンロードしてもよく記載された機能を遂行してもよい。コンピューター読み出し可能媒体は、フロッピー（登録商標）ディスク、ハードディスク、フラッシュメモリ、ＲＡＭ、ＲＯＭ，ＣＤＲＯＭ，またはここに記載されたシステムにより実行される命令を含んでいてもよい任意のタイプのコンピューター読み出し可能媒体を含む。

装置上で作動中のアプリケーションに信任状を供給するための方法および装置を含む信任状システムが記載された。このシステムは、すべてのタイプの装置に使用するのに適しており、特に、携帯電話のような無線装置に使用するのに適しており、データサーバーまたは他のシステムに対して認証を必要とするアプリケーションにアプリケーション信任状を供給する。

従って、信任状システムのための方法および装置の１つ以上の実施形態が図解されここに記載されたが、精神または必須の特性から逸脱することなく、実施形態に対して種々の変更を行うことができることが理解されるであろう。それゆえ、本明細書における開示と記載は、例証であることを意図しており、以下のクレームで述べられるこの発明の範囲を限定することを意図していない。

図１は、無線装置上で作動しているアプリケーションにアプリケーション信任状を供給する信任状システムの一実施形態を含むデータネットワークを示す。 図２は、装置上で作動しているアプリケーションにアプリケーション信任状を供給するように動作する信任状システムの一実施形態を含む図１の無線装置の一実施形態を図解する機能ブロック図を示す。 図３は、装置上で作動しているアプリケーションにアプリケーション信任状を供給するように信任状システムを動作させるための方法の一実施形態を示す。 図４は、装置上で作動しているアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含むデータサーバーの機能ブロック図を示す。 図５は、装置上で作動しているアプリケーションにより供給されるアプリケーション信任状を認証するために信任状システム内のデータサーバーを動作させるための方法の一実施形態を示す。 図６は、装置上で作動しているアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含むデータサーバーの他の実施形態の機能ブロック図を示す。 図７は、装置上で作動しているアプリケーションに供給されたアプリケーション信任状を認証するために信任状システムにおいて動作する信任状サーバーの一実施形態を示す。 図８は、装置上で作動しているアプリケーションにより供給されるアプリケーション信任状を認証するために信任状システム内の信任状サーバーを動作させるための方法の一実施形態を示す。 図９は、装置上で作動しているアプリケーションから受信されたデータのための要求を認証する信任状システムの一実施形態を含む信任状サーバーの他の実施形態の機能ブロック図を示す。

Claims (45)

1. 装置上で作動中のアプリケーションにアプリケーション信任状を供給する方法であって、アプリケーション信任状は、データサーバーに対して認証するためにアプリケーションにより使用される方法において、
   アプリケーション信任状を発生するための要求を受信することであって、前記要求は、アプリケーション識別子を含むことと、および
   前記アプリケーション識別子と、前記装置に関連するマスター信任状を用いて前記アプリケーション信任状を発生することとを備えた方法。
2. 前記アプリケーション信任状を発生するステップは、一方向の発生技術を含み、それにより前記アプリケーション識別子と前記マスター信任状は、前記アプリケーション信任状から発見することができない、請求項１の方法。
3. アプリケーションまたはアプリケーション識別子が変更されたか否かを決定するために、およびアプリケーションがアプリケーション識別子に関連していることを証明するために変更検出と認証技術を用いることをさらに備えた、請求項１の方法。
4. 前記変更検出技術は、前記アプリケーションのプロバイダーと異なるサーバーにより発生される、請求項３の方法。
5. 前記変更検出技術は、デジタル署名である、請求項４の方法。
6. 前記装置は無線装置である、請求項１の方法。
7. 前記装置上で作動中のアプリケーションにアプリケーション信任状を供給するように動作する装置であって、データサーバーに対して認証するためにアプリケーション信任状がアプリケーションにより使用される装置において、
   アプリケーション信任状のための要求を受信するように動作する受信ロジックであって、前記要求は、アプリケーション識別子を含む受信ロジックと、および
   前記アプリケーション識別子とマスター信任状を用いて前記アプリケーション信任状を発生するように動作する発生ロジックとを備えた装置。
8. 前記発生ロジックは一方向の信任状発生技術を使用し、それにより前記アプリケーション識別子と前記マスター信任状は、前記アプリケーション信任状から発見することができない、請求項７の装置。
9. 前記アプリケーションまたは前記アプリケーション識別子が変更されたか否かを決定するためにおよび前記アプリケーションが前記アプリケーション識別子と関連していることを証明するように動作する変更検出および認証技術をさらに備えた、請求項８の装置。
10. 前記変更検出技術は、前記アプリケーションのプロバイダーとは異なるサーバーにより発生される、請求項９の装置。
11. 前記変更検出技術は、デジタル署名である、請求項１０の装置。
12. 前記装置は無線装置である、請求項７の装置。
13. 装置上で作動中のアプリケーションにアプリケーション信任状を供給するように動作する装置であって、前記アプリケーション信任状は、データサーバーに対して認証するために前記アプリケーションにより使用される装置において、
    前記アプリケーション信任状のための要求を受信する手段であって、前記要求はアプリケーション識別子を含む手段と、
    前記アプリケーション識別子およびマスター信任状を用いて前記アプリケーション信任状を発生する手段。
14. 一方向発生技術を用いて前記アプリケーション信任状を発生する手段をさらに備え、それにより、前記アプリケーション識別子と前記マスター信任状は、前記アプリケーション信任状から発見することができない、請求項１３の装置。
15. 前記アプリケーションまたはアプリケーション識別子が変更されたか否かを決定するためにおよび前記アプリケーションが前記アプリケーション識別子と関連することを証明するために変更検出および認証技術を用いる手段をさらに備えた、請求項１３の装置。
16. 前記変更検出技術は、前記アプリケーションのプロバイダーとは異なるサーバーにより発生される、請求項１５の装置。
17. 前記変更検出技術は、デジタル署名である、請求項１６の装置。
18. 装置内のプロセッサーにより実行されると、前記装置上で作動中のアプリケーションにアプリケーション信任状を供給する命令を含むコンピューター読み出し可能媒体であって、前記アプリケーション信任状は、データサーバーに対して認証するために前記アプリケーションにより使用される、コンピューター読み出し可能媒体において、
    前記アプリケーション信任状のための要求を受信する命令であって、前記要求は、アプリケーション識別子を含む命令と、
    前記アプリケーション識別子とマスター信任状を用いて前記アプリケーション信任状を発生するための命令とを備えた、コンピューター読み出し可能媒体。
19. 前記アプリケーションまたは前記アプリケーション識別子が変更されたか否かを決定するために、および前記アプリケーションが前記アプリケーション識別子と関連することを証明するために変更検出および認証技術を用いるための命令を含む、請求項１８のコンピューター読み出し可能媒体。
20. 前記変更検出技術は、前記アプリケーションのプロバイダーとは異なるサーバーにより発生される、請求項１９のコンピューター読み出し可能媒体。
21. 前記変更検出技術はデジタル署名である、請求項２０のコンピューター読み出し可能媒体。
22. 一方向発生技術を用いて前記アプリケーション信任状を発生するための命令をさらに備え、それにより、前記アプリケーション識別子と前記マスター信任状は、前記アプリケーション信任状から発見することができない、請求項１８のコンピューター読み出し可能媒体。
23. 前記装置は、無線装置である、請求項１８のコンピューター読み出し可能媒体。
24. 装置上で作動中のアプリケーションを認証するように信任状サーバーを動作させるための方法であって、前記アプリケーションは、データのための要求をデータサーバーに送信し、前記要求はアプリケーション信任状を含む方法において、
    サーバー信任状のための要求においてアプリケーション識別子を受信することと、
    前記アプリケーション識別子とマスター信任状を用いて前記サーバー信任状を発生することと、
    前記サーバー信任状を前記データサーバーに送信することであって、前記サーバー信任状と前記アプリケーション信任状が一致するなら、前記アプリケーションは認証されることとを備えた方法。
25. 前記要求が前記アプリケーション識別子に関連することを証明する認証トークンを受信することをさらに備えた、請求項２４の方法。
26. 前記アプリケーション信任状を受信することと、
    前記アプリケーション信任状と前記サーバー信任状とを整合させることと、
    前記アプリケーション信任状が前記サーバー信任状に一致するなら、データ要求を実行するために、データサーバーに権限を送信することとをさらに備えた、請求項２４の方法。
27. 前記発生ステップは、一方向の発生技術を用いて前記サーバー信任状を発生させることを含み、それにより、前記アプリケーション識別子と前記マスター信任状は、前記サーバー信任状から発見することができない、請求項２４の方法。
28. 装置上で作動中のアプリケーションを認証するために信任状サーバーに使用するための装置であって、前記アプリケーションは、データのための要求をデータサーバーに送信し、前記要求は、アプリケーション信任状を含む装置において、
    サーバー信任状のための要求においてアプリケーション識別子を受信するように動作する第１の受信ロジックと、
    前記アプリケーション識別子とマスター信任状とに基づいて前記サーバー信任状を発生するように動作する発生ロジックと、
    前記サーバー信任状を前記データサーバーに送信するように動作する送信ロジックであって、前記データサーバーは、前記サーバー信任状を前記アプリケーション信任状と一致させ前記アプリケーションを認証する送信ロジックとを備えた装置。
29. 前記要求は、前記アプリケーション識別子に関連することを証明する認証トークンを受信することをさらに備えた、請求項２８の装置。
30. 前記発生ロジックは、一方向発生技術を用いて前記サーバー信任状を発生するためのロジックを含み、それにより前記アプリケーション識別子と前記マスター信任状は前記サーバー信任状から発見することができない、請求項２８の装置。
31. 前記アプリケーション信任状を受信するように動作する第２の受信ロジックと、
    前記アプリケーション信任状を前記サーバー信任状と一致させ、前記アプリケーション信任状が前記サーバー信任状と一致するなら、前記データ要求を実行するための権限を前記データサーバーに送信するように動作する整合ロジックをさらに備えた、請求項２８の装置。
32. 装置上で作動中のアプリケーションを認証するために信任状サーバーに使用する装置であって、前記アプリケーションは、データサーバーにデータのための要求を送信し、前記要求は、アプリケーション信任状を備える装置において、
    サーバー信任状のための要求においてアプリケーション識別子を受信する手段と、
    前記アプリケーション識別子およびマスター信任状に基づいて前記サーバー信任状を発生する手段と、
    前記サーバー信任状を前記データサーバーに送信する手段であって、前記データサーバーは、前記サーバー信任状を前記アプリケーション信任状と一致させ前記アプリケーションを認証する手段とを備えた装置。
33. 前記要求は、前記アプリケーション識別子に関連することを証明する認証トークンを受信することをさらに備えた、請求項３２の装置。
34. 前記発生手段は、一方向発生技術を用いて前記サーバー信任状を発生するための手段を備え、それにより前記アプリケーション識別子と前記マスター信任状は、前記サーバー信任状から発見することができない、請求項３２の装置。
35. 前記アプリケーション信任状を受信する手段と、
    前記アプリケーション信任状を前記サーバー信任状と一致させる手段と、
    前記アプリケーション信任状が前記サーバー信任状に一致するなら、前記データ要求を実行するための権限を前記データサーバーに送信する手段とをさらに備えた、請求項３２の装置。
36. 信任状サーバー内のプロセッサーにより実行されると、装置上で作動中のアプリケーションを認証するように動作する命令を備え、前記要求は、アプリケーション信任状を備えたコンピューター読み出し可能媒体であって、
    サーバー信任状のための要求において、前記アプリケーション識別子を受信する命令と、
    前記アプリケーション識別子とマスター信任状に基づいて前記サーバー信任状を発生するための命令と、
    前記サーバー信任状を前記データサーバーに送信するための命令であって、前記データサーバーは、前記サーバー信任状を前記アプリケーション信任状と一致させ前記アプリケーションを認証する命令とを備えたコンピューター読み出し可能媒体。
37. 前記要求は、前記アプリケーション識別子と関連することを証明する認証トークンを受信することをさらに備えた、請求項３６のコンピューター読み出し可能媒体。
38. 前記発生するための命令は、一方向発生技術を用いて前記サーバー信任状を発生するための命令を備え、それにより、前記アプリケーション識別子と前記マスター信任状は、前記サーバー信任状から発見することができない、請求項３６のコンピューター読み出し可能媒体。
39. 前記アプリケーション信任状を受信する命令と、
    前記アプリケーション信任状を前記サーバー信任状と一致させるための命令と、
    前記アプリケーション信任状が前記サーバー信任状と一致するなら、前記データ要求を実行するための権限を前記データサーバーに送信する命令とをさらに備えた、請求項３６のコンピューター読み出し可能媒体。
40. 装置上で作動中のアプリケーションに関連するアプリケーション信任状を処理するための方法であって、前記アプリケーション信任状はデータサーバーに対して認証するために前記アプリケーションにより使用される方法において、
    前記アプリケーション信任状を発生するための要求を受信することであって、前記要求は、アプリケーション識別子を含むことと、
    前記アプリケーション識別子およびマスター信任状を用いて前記アプリケーション信任状を発生することと、
    データサーバーにデータのための要求を送信することであって、前記要求は、前記アプリケーション信任状を備えることと、
    信任状サーバーからサーバー信任状を要求することであって、前記サーバー信任状のための要求は、前記アプリケーション識別子と、データサーバーが自身を認証するトークンを備えることと、
    前記アプリケーション識別子と前記マスター信任状を用いて前記サーバー信任状を発生することと、
    前記サーバー信任状を前記データサーバーに送信することと、
    前記サーバー信任状を前記アプリケーション信任状と一致させることであって、前記２つの信任状が一致するなら、前記アプリケーションは認証されることと、
    前記データを前記アプリケーションに送信することとを備えた方法。
41. 前記アプリケーション信任状と前記サーバー信任状は、一方向発生技術を用いて発生され、それにより前記アプリケーション識別子と前記マスター信任状は、発見することができない、請求項４０の方法。
42. 前記アプリケーション識別子が変更されたか否かを決定するためにおよび前記アプリケーションが前記アプリケーション識別子と関連することを証明するために変更および認証技術を用いることをさらに備えた、請求項４０の方法。
43. 前記変更検出技術はデジタル署名である、請求項４２の方法。
44. 前記要求が前記アプリケーション識別子に関連することを証明する前記信任状サーバーにおいて認証トークンを受信することをさらに備えた、請求項４０の方法。
45. 前記装置は無線装置である、請求項４０の方法。

Images