JP2022536820A - デバイスおよびアプリケーションの完全性の検証 - Google Patents

Abstract

本開示は、信用トークンを使用して、そこからデータが受信されるデバイスおよびアプリケーションの完全性を検証することに関する。一態様では、この方法は、1つまたは複数の信用トークンに対する要求をクライアントデバイスから受信するステップを含む。この要求は、クライアントデバイスから取得された1つまたは複数のデバイスレベルの不正検出信号、またはその要求を開始したアプリケーションのコードを表すデータのうちの少なくとも1つを含む。この要求はまた、1つまたは複数の信用トークンの各々に対するそれぞれのナンスを含む。1つまたは複数のデバイスレベルの不正検出信号、またはアプリケーションのコードを表すデータのうちの少なくとも1つに基づいて、1つまたは複数の信用トークンをクライアントデバイスに発行すると判定する。各信用トークンは、信用トークンに対するナンスを使用して生成される。1つまたは複数の信用トークンがクライアントデバイスに提供される。

Description

クライアントデバイスは、インターネットなどの公衆網を介してデータを送信する。これらの通信は、意図される受信者以外のエンティティによって傍受および/または改変されることがある。加えて、エンティティは、ネットワーク識別情報を偽造し、これらの偽造されたネットワーク識別情報から生じているように見えるデータを送ることがある。エンティティは、アプリケーションコードを改変して、不正データを送る、悪意のあるコードを挿入することもある。

本明細書は、信用トークンを使用して、そこからデータが受信されるデバイスおよびアプリケーションの完全性を検証することに関する技術について説明する。

概して、本明細書で説明する主題の1つの発明性のある態様は、1つまたは複数の信用トークンに対する要求をクライアントデバイスから受信するステップを含む方法で具現され得る。この要求は、(i)クライアントデバイスから取得された1つまたは複数のデバイスレベルの不正検出信号、または(ii)その要求を開始したアプリケーションのコードを表すデータのうちの少なくとも1つ、および1つまたは複数の信用トークンの各々に対するそれぞれのナンスを含む。(i)1つまたは複数のデバイスレベルの不正検出信号、または(ii)アプリケーションのコードを表すデータのうちの少なくとも1つに基づいて、1つまたは複数の信用トークンをクライアントデバイスに発行すると判定する。1つまたは複数の信用トークンをクライアントデバイスに発行するとの判定に応じて、信用トークンに対するナンスを使用して、1つまたは複数の信用トークンの各々が生成され、1つまたは複数の信用トークンがクライアントデバイスに提供される。本態様の他の実装形態は、コンピュータ記憶デバイス上に符号化された、これらの方法の態様を実行するように構成された、対応する装置、システム、およびコンピュータプログラムを含む。

これらのおよび他の実装形態は、各々、以下の特徴のうちの1つまたは複数の随意に含み得る。いくつかの態様では、(i) 1つまたは複数のデバイスレベルの不正検出信号、または(ii)アプリケーションのコードを表すデータのうちの少なくとも1つに基づいて、1つまたは複数の信用トークンをクライアントデバイスに発行すると判定するステップは、1つまたは複数のデバイスレベルの不正検出信号に基づいて、クライアントデバイスが信用できるデバイスであると判定するステップと、アプリケーションのコードを表すデータに基づいて、アプリケーションが信用できるアプリケーションであると判定するステップと、クライアントデバイスが信用できるデバイスであり、アプリケーションが信用できるアプリケーションであるとの判定に応じて、1つまたは複数の信用トークンをクライアントデバイスに発行すると判定するステップとを含む。

いくつかの態様では、アプリケーションのコードを表すデータは、アプリケーションのコードの暗号学的ハッシュを含む。1つまたは複数の信用トークンをクライアントデバイスに発行すると判定するステップは、アプリケーションのコードを表すデータに基づいて、アプリケーションが信用できるアプリケーションであると判定するステップと、アプリケーションが信用できるアプリケーションであるとの判定に応じて、1つまたは複数の信用トークンをクライアントデバイスに発行すると判定するステップとを含み得る。

いくつかの態様では、アプリケーションが信用できるアプリケーションであると判定するステップは、アプリケーションのコードの暗号学的ハッシュをアプリケーションの公式ビルド(builds)のコードの暗号学的ハッシュと比較するステップと、アプリケーションコードの暗号学的ハッシュとアプリケーションの公式ビルドのコードの暗号学的ハッシュの一致に応じて、アプリケーションが信用できるアプリケーションであると判定するステップとを含む。

いくつかの態様では、アプリケーションが信用できるアプリケーションであると判定するステップは、アプリケーションが悪意のあるアプリケーション論理を含まないことを示す証明書がアプリケーションに対して発行されていると判定するステップを含む。

いくつかの態様では、各信用トークンに対するナンスは、ブラインド署名方式を使用してブラインド化されたブラインド化ナンスである。1つまたは複数の信用トークンの各々を生成することは、ブラインド署名方式を使用して、信用トークンに対するブラインド化ナンスのブラインド署名を生成することを含み得る。信用トークンは、ブラインド化ナンスおよびブラインド化ナンスのブラインド署名を含み得る。

いくつかの態様は、償還(redemption)のための所与の信用トークンを含む償還要求をクライアントデバイスから受信するステップを含み得る。所与の信用トークンは、非ブラインド化ナンスおよびナンスのブラインド化バージョンに基づいて生成されたブラインド署名を含み得る。所与の信用トークンのブラインド署名は、非ブラインド化ナンスおよびブラインド署名方式を使用して検証され得る。ブラインド署名の検証に応じて、所与の信用トークンに対する署名された償還記録がクライアントデバイスに送られる。

いくつかの態様では、要求は、クライアントデバイスに対する公開鍵を含む。1つまたは複数の信用トークンの各々は、クライアントデバイスに対する公開鍵を使用して暗号化され得る。1つまたは複数の信用トークンをクライアントデバイスに提供することは、1つまたは複数の暗号化された信用トークンをクライアントデバイスに提供することを含み得る。

いくつかの態様では、要求は、クライアントデバイスに対するデバイス識別子を含む。クライアントデバイスに対する信用性の履歴記録は、デバイス識別子を使用して保持され得る。1つまたは複数の信用トークンをクライアントデバイスに発行すると判定するステップは、デバイスレベルの不正検出信号およびクライアントデバイスに対する信用性の履歴記録の組合せに基づいて、クライアントデバイスが信用できるデバイスであると判定するステップを含み得る。

いくつかの態様では、デバイスレベルの不正検出信号およびクライアントデバイスに対する信用性の履歴記録の組合せに基づいて、クライアントデバイスが信用できるデバイスであると判定するステップは、デバイスレベルの不正検出信号、クライアントデバイスに対する信用性の履歴記録、および所与の時間期間中にクライアントデバイスによって要求された信用トークンの数の組合せに基づいて、クライアントデバイスが信用できるデバイスであると判定するステップを含む。

本明細書で説明する主題は、以下の利点のうちの1つまたは複数を実現するために特定の実施形態で実装され得る。デバイスから要求(または、他の通信もしくはデータ)を受信する受信者は、デバイスに発行された信用トークンに基づいて、たとえば、信用トークンが償還されるとき、デバイスに提供される署名された償還記録に基づいて、要求を送ったデバイス、およびそのデバイス上で実行しているアプリケーションが信用できるデバイスであると検証し得る。このトークンおよび/または署名された償還記録は、信用トークンシステムによる評価に基づいて、デバイスおよびそのアプリケーションが信用できることを証明する。

信用トークンシステムは、デバイスレベルの不正検出信号を評価して、クライアントデバイスが信用できるかどうかを判定し得る。信用トークンシステムは、要求を開始したアプリケーション、たとえば、ウェブブラウザが、たとえば、デバイス上のアプリケーションのビルドが信用トークンの発行に先立つ公式ビルドであるかどうかに基づいて、信用できるアプリケーションであるかどうかを判定することもできる。これは、デバイスが(たとえば、データセンター内の仮想機械または悪意のある感染した/損なわれたデバイスではなく)真のデバイスであること、またアプリケーションが潜在的に悪意のあるコードが挿入されたカスタムビルドではないことを確実にする。評価のこの組合せに基づいて発行された信用トークンの使用は、悪用(たとえば、偽のアカウントの作成を試みるかまたはユーザの実際のアカウントを奪う、悪意のあるボット)および不正(たとえば、偽造された要求/通信から利益を得ることを試みる、悪意のある当事者)から受信者を保護することができ、デバイスおよびアプリケーションから受信された信用できる通信に依存するシステムおよびプロトコルの信用を確実にする。開示するシステムおよび方法は、したがって、デバイス間の通信のための確実な手段を提供する技術的な利点を提供する。さらに、開示するシステムおよび方法は、デバイスレベルおよびアプリケーションレベルの情報に基づいて、信用トークンを発行することが可能であるため、開示するシステムおよび方法は、ユーザプライバシーを保持しながら、通信のこの確実な手段を提供し、それにより、クライアントデバイスが信用できるかどうかを判定するために、ユーザレベルのデータ(ブラウザ履歴または他のユーザプロファイル情報)を評価する必要を回避し得る。したがって、開示するシステムおよび方法は、ユーザ情報を保護し、ユーザプライバシーを保持する技術的利点をやはり提供する。

信用トークンは、クライアントデバイスにおいてブラインド化され、信用トークンシステムに送られる、ブラインド化されたブラインド化ナンスに基づいて生成され得る。クライアントデバイスは、信用トークンシステムを用いて信用トークンを償還するのに先だって、信用トークンのナンスを非ブラインドし得る。このようにして、信用トークンシステムは発行された信用トークンのブラインド化ナンスを償還された信用トークンの非ブラインド化ナンスと相関させることができないため、ユーザプライバシーは保護される。したがって、これは、デバイスレベルおよびアプリケーションレベルの信号に関してユーザプライバシーを保持する技術的利点を提供する。ユーザプライバシーは、クライアントデバイスのユーザに関する信号とは無関係に、デバイスおよびアプリケーションの信号のみに基づいて、信用トークンを発行することによってさらに改善され得る。ブラウジング履歴またはクライアントデバイスのユーザにとって個人的な他のデータなど、クライアントデバイスのユーザに関するそのような情報は、したがって、信用トークンを発行するためには不要であり、したがって、この情報は、評価のために信用トークン発行者に送信される必要がない。このようにして、個人的なユーザ情報は保護され、これは、ユーザプライバシーを保持する技術的利点を提供する。

信用トークンは、バッチで要求および発行され得る。信用トークンシステムはクライアントデバイスおよびアプリケーションの単一の評価に基づいて複数のトークンを発行したため、これは信用トークンシステムに課される負担(たとえば、使用されるCPUサイクルの数)を低減し、したがって、複数の信用トークンを発行するために必要とされるリソースを低減する技術的利点を提供する。トークンは各要求に対してクライアントデバイスの評価を待つのではなく、信用トークン検証を必要とする任意の要求に先立って、クライアントデバイスに発行され得るため、これはクライアントデバイスにおけるレイテンシをやはり低減し、したがって、信用トークンを発行するために、レイテンシを低減して、より応答性が高いシステムの技術的利点をやはり提供する。

前述の主題の様々な特徴および利点は、以下で、図面に関して説明される。追加の特徴および利点は、本明細書で説明する主題および特許請求の範囲から明らかである。

信用トークンシステムが信用トークンを発行し、償還する、例示的な環境のブロック図である。 信用トークンを発行するための例示的なプロセスを示す流れ図である。 信用トークンを償還するための例示的なプロセスを示す流れ図である。 償還された信用トークンに基づいて、署名された償還記録を含む要求を処理するための例示的なプロセスを示す流れ図である。 上記で説明した動作を実行するために使用され得る例示的なコンピュータシステムのブロック図である。

様々な図面における同様の参照番号および名称は、同様の要素を示す。

概して、本書は、信用トークンを使用して、そこから要求、通信、または他のデータが受信されるデバイスおよびアプリケーションの完全性を検証するためのシステムおよび技術について説明する。クライアントデバイスから受信されたいくつかのタイプの要求の受信者は、それらの要求が有効であり、損なわれたもしくは不正なデバイスまたはアプリケーションから受信されていないことを確実にすることを望む。たとえば、ユーザプライバシーシステムは、データセンター内で実行している不正仮想機械または悪意のあるコードを備えたアプリケーションのカスタムビルドからではなく、ユーザに対するプライバシー設置を変更するための要求が真のクライアントデバイスから、かつアプリケーションの公式ビルドから、受信されることを確実にし、それにより、アプリケーションを使用するときのユーザプライバシーを強化することを望むことがある。以下の説明は主にクライアントデバイスによって送られた要求に関して説明されるが、これらの技法は、クライアントデバイスから受信される他のタイプのデータまたは通信の完全性を検証するために使用され得る。

たとえば、要求の受信者によって、信用性が重要であると見なされる要求を送ることになるアプリケーションは、信用トークンシステムから信用トークンを要求し得る。信用トークンシステムは、クライアントデバイスおよびアプリケーションの信用性を評価し、両方が信用できると見なされる場合、信用トークンシステムは、信用トークンをクライアントデバイスに発行し得る。アプリケーションが後で要求を受信者に提出するとき、アプリケーションは、アプリケーションが要求内に含み得る、署名された償還記録(SRR:signed redemption record)に対して信用トークンを償還し得る。以下でより詳細に説明するように、SRRは、要求のデータが操作されないことを確実にし、クライアントデバイスおよびアプリケーションが信用トークンシステムによって信用できると評価および/または見なされたことを証明するために信用トークンシステムによって生成されるデジタル署名を含み得る。信用トークンシステムによって生成されるデジタル署名は、クライアントデバイスが信用できることを検証し、デジタル署名は、この検証が操作されていないことをやはり確実にするため、これは、クライアントデバイスが信用できると判定するためのセキュアな手段を提供する。

図1は、信用トークンシステム130が、トークンを発行し、償還する、例示的な環境100のブロック図である。例示的な環境100は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、インターネット、モバイルネットワーク、またはそれらの組合せなど、データ通信ネットワーク105を含む。ネットワーク105は、クライアントデバイス110、受信者の受信者デバイス120、および信用トークンシステム130を接続する。例示的な環境100は、多くの異なるクライアントデバイス110、信用トークンシステム130、および受信者デバイス120を含み得る。

クライアントデバイス110は、ネットワーク105を介して通信することが可能な電子デバイスである。例示的なクライアントデバイス110は、パーソナルコンピュータ、モバイル通信デバイス、たとえば、スマートフォン、およびネットワーク105を介してデータを送り、受信することができる他のデバイスを含む。

クライアントデバイス110は、一般に、ネットワーク105を介してデータを送ること、および受信することを円滑にする、ウェブブラウザおよび/またはネイティブアプリケーションなどのアプリケーション112を含む。ネイティブアプリケーションは、特定のプラットフォームまたは特定のデバイスに対して開発されたアプリケーションである。いくつかの実装形態では、クライアントデバイス110は、デジタルメディアデバイス、たとえば、テレビジョンにプラグインするストリーミングデバイス、またはビデオをテレビジョンにストリーミングするための他のディスプレイ、である。デジタルメディアデバイスは、ビデオをストリーミングし、かつ/またはリソースを提示する、ウェブブラウザおよび/または他のアプリケーションを含んでもよい。

クライアントデバイス110はまた、信用できるプログラム114を含む。信用できるプログラム114は、偽造が困難な信頼できるソースからの信用できるコードを含み得る。たとえば、信用できるプログラム114は、オペレーティングシステム、オペレーティングシステムの一部分、ウェブブラウザ、などであってよい。概して、信用できるプログラム114は、侵入が困難であり、犯罪者が信用できるプログラム114を改ざんするために拡張することが必要になる時間および労力の量が極めて高い。加えて、信用できるプログラム114は信頼できるソースによって提供され保持されるため、高まるいかなる脆弱性もソースによって対処され得る。信用できるプログラムは侵入が困難であるため、そのような信用できるプログラムをこのように使用することは、クライアントデバイスにおけるセキュリティを増大する技術的利点を提供する。加えて、信用できるプログラムは信頼できるソースによって保持されるため、このプログラムは信用できるプログラム内の脆弱性を低減する利点を提供する。

信用できるプログラム114は、ユーザデバイス110に対して局所的であってよい。たとえば、信用できるプログラム114は、ユーザデバイス110のオペレーティングシステムのデバイスドライバであってよい。いくつかの実装形態では、信用できるプログラム114は、ユーザデバイス110に対して完全に局所的に動作し、ユーザ情報を送信する必要を低減する。いくつかの実装形態では、信用できるプログラム114は、ユーザデバイス110に対して、ネットワーク105などのネットワークを介して、局所的に動作し得る。たとえば、信用できるプログラム114は、ユーザデバイス110上にインストールされ、ネットワーク105を介して情報を送信および受信するウェブブラウザであってよい。

アプリケーション112は、要求を受信者の受信者デバイス120に送り得る。受信者デバイス120は、コンピュータ(たとえば、サーバ)、モバイル通信デバイス、およびネットワーク105を介してデータを送り、受信することができる他のデバイスであってよい。これらの要求は、設定、たとえば、ユーザプライバシー設定、を更新する要求、コンテンツに対する要求、データを報告する要求、アプリケーションをインストールする要求、および/または他の適切なタイプの要求を含み得る。例示的な受信者は、要求に応じてコンテンツを提供するコンテンツプロバイダである。

いくつかの要求に対して、アプリケーション112は、信用トークン、または要求が信用できるアプリケーションおよび信用できるデバイスによって送られていることを検証するための償還された信用トークンに基づくSRRを含み得る。アプリケーション112は、たとえば、信用できるプログラム114を介して、信用トークンシステム130から1つまたは複数の信用トークンを要求し得る。たとえば、アプリケーション112は、信用トークンを要求するように、信用できるプログラム114のアプリケーションプログラミングインターフェース(API)を呼び出すことができる。信用できるプログラム114は、次いで、信用トークンシステム130から信用トークンを要求し得る。

信用できるプログラム114は、データのセットを収集し、アプリケーションに対する信用トークンに対する要求内に含めることができる。データのこのセットは、各要求された信用トークンに対するナンスを含み得る。ナンスは、任意の(たとえば、ランダム、または疑似ランダム)数である。いくつかの実装形態では、各信用トークンに対する平文ナンスを含むのではなく、要求は、各要求された信用トークンに対するブラインド化ナンスを含む。信用できるプログラム114(または、アプリケーション112自体)がナンスを生成し、ブラインド署名方式を使用してナンスをブラインド化し得る。ナンスをブラインド化することは、たとえば、ナンスをブラインド化係数と組み合わせることによって、ナンスの値を隠すかまたは不明瞭にすることを含み得る。ブラインド署名方式は、インターネットエンジニアリングタスクフォース(IETF)検証可能なオブリビアス疑似ランダム関数(VOPRF:Verifiable, Oblivious Pseudorandom Function)プロトコル、RSA(リベスト-シャミア-エーデルマン)、または別の適切なブラインド署名方式を含み得る。以下でより詳細に説明するように、ナンスは、信用トークンを生成するために使用され、ブラインド化ナンスの使用は、ユーザプライバシーを改善する技術的利点を提供する。

信用トークンに対する要求のデータのセットは、デバイスレベルの不正検出信号を含み得る。デバイスレベルの不正検出信号は、クライアントデバイスが損なわれているかどうか、またはクライアントデバイスが通常のクライアントデバイスとして動作しているかまたはエミュレートされたクライアントデバイスとして動作しているかを判定するために使用され得る、クライアントデバイスの動作特性またはメトリックを表すデータを含み得る。いくつかの動作特性およびメトリックは、エミュレータと比べて、真のクライアントデバイスでは異なることがよくある。いくつかの実装形態では、デバイスレベルの不正検出信号は、信用トークンを要求しているアプリケーション112の動作特性およびメトリックを含むアプリケーションレベルの不正検出信号を含む。信用できるプログラム114は、これらのデバイスレベルの不正検出信号を収集し、これらの信号を信用トークンに対する要求内に含めることができる。

信用トークンに対する要求内のデータのセットは、信用トークンに対する要求を開始し、最終的に信用トークンを使用する、アプリケーション112に関するデータを含んでもよい。このデータは、アプリケーションに対する識別情報、たとえば、アプリケーションのパッケージファイルに対するパッケージ名、およびクライアントデバイス110上のアプリケーション112のインスタンスがアプリケーションの公式ビルドであるかどうかを判定するために使用され得るデータを含み得る。このデータは、アプリケーション112のコードを表すデータを含み得る。たとえば、信用できるアプリケーション114は、暗号学的ハッシュ関数を使用してアプリケーション112のコードの暗号学的ハッシュを生成し、コードのハッシュを要求内に含めることができる。このハッシュは、アプリケーション112に対するアプリケーションバイナリファイルのハッシュ、アプリケーション112に対する実行可能ファイルのハッシュ、および/またはクライアントデバイス110におけるアプリケーション112の現在実行しているビルドのすべてのファイルのハッシュであってよい。いくつかの実装形態では、データは、開発者の秘密鍵を使用してアプリケーション112の開発者によって署名された証明書のハッシュを含んでもよい。信用できるプログラム114は、ハッシュがクライアントデバイス110上で実行しているアプリケーション112の現在のビルドを表すことを確実にするために、要求時にハッシュを生成し得る。

いくつかの実装形態では、信用トークンに対する要求のデータのセットは、その要求を提出しているクライアントデバイス110に対する一意のデバイス識別子を含み得る。このデバイス識別子は、クライアントデバイスの公開鍵であってよい。たとえば、クライアントデバイス110は、公開鍵、および公開鍵に対応する、たとえば、公開鍵に数学的にリンクされた、秘密鍵を含む非対称暗号鍵ペアを含み得る。以下でより詳細に説明するように、デバイス識別子は、所与のクライアントデバイスに対して発行された信用トークンの数を制限し、かつ/またはクライアントデバイス110に対する信用性の履歴記録を保持するために使用され得る。

信用トークンシステム130は、クライアントデバイス110から信用トークン要求を受信し、要求の少なくともいくつかに応じて、信用トークンを発行し、クライアントデバイス110に対する信用トークンを償還し得る。信用トークンシステム130は、その各々が、1つまたは複数のデータ処理装置、たとえば、1つまたは複数のサーバコンピュータを使用して実装され得る、信用トークン発行者132、デバイス評価器134、およびアプリケーション評価器136を含む。いくつかの実装形態では、信用トークン発行者132、デバイス評価器134、およびアプリケーション評価器136のうちの2つ以上が同じコンピュータ上で実装される。

いくつかの実装形態では、信用トークンシステム130は、信用できるプログラム114を開発するエンティティによって保持され、動作される。たとえば、信用できるプログラム114がオペレーティングシステムである場合、信用トークンシステム130は、オペレーティングシステム開発者によって動作されてよい。いくつかの実装形態では、信用トークンシステム130は、信用できるプログラム114を開発するエンティティとは異なるエンティティによって、たとえば、第三者デバイスおよびアプリケーション不正検出システムによって動作される。

デバイス評価器134は、信用トークン要求のデバイスレベルの不正検出信号を評価して、そこから信用トークン要求が受信されたクライアントデバイス110が、信用できるデバイスであるかどうかを判定する。デバイス評価器134は、不正検出信号に基づいて、クライアントデバイス110の信用性のレベルを判定し得る。たとえば、信用性のレベルは、数値スケール、たとえば、1～3、0～10、0～100、または別の適切なスケールであってよい。デバイス評価器134は、信用性のレベルが信用性しきい値を満たす場合、たとえば、しきい値以上である場合、信用できるデバイスとしてクライアントデバイス110を分類し得る。

いくつかの実装形態では、デバイス評価器134は、デバイスレベルの不正検出信号に基づいて、真のクライアントデバイス、エミュレータ、ルート化(rooted)デバイス、および/または他の適切なカテゴリーのデバイスを区別する。この例では、デバイス評価器134は、クライアントデバイスが特定のカテゴリー、たとえば、真のクライアントデバイスカテゴリー内に分類されるとき、クライアントデバイスを信用できるデバイスと分類し得る。

デバイス評価器134は、クライアントデバイス110に関する分類をデバイス信用データベース146または他の適切なデータ構造内に記憶し得る。各クライアントデバイス110に対して、デバイス信用データベース146は、クライアントデバイス110に対するデバイス識別子およびクライアントデバイス110に対する信用性の履歴記録を含み得る。履歴記録は、クライアントデバイス110の1つまたは複数の履歴分類を含み得る。たとえば、クライアントデバイス110に対する信用性の履歴記録は、所与の時間期間にわたって、クライアントデバイス110の信用性のレベルおよび/またはクライアントデバイス110の分類(たとえば、信用できるか否か、かつ/またはカテゴリー)を含み得る。所与の時間期間は、同じデバイス識別子を有するクライアントデバイス110から(デバイス識別子はいくつかの実装形態では変更され得るため)、または限定された時間期間(たとえば、先週、先月、去年、など)にわたって、受信されたすべての要求を含み得る。

クライアントデバイス110に対する信用性の履歴記録は、信用トークン要求に応じて、信用トークンをクライアントデバイス110に発行するかどうかを判定するために使用され得る。いくつかの実装形態では、信用トークン発行者132は、クライアントデバイス110に対する信用性のパターンを考慮して、信用トークンをクライアントデバイス110に発行するかどうかを判定し得る。たとえば、悪意のある当事者は、時間の通常の方法部分で、かつ時間の不正方法部分で、クライアントデバイス110を動作させることがある。このクライアントデバイス110に対する履歴記録は、クライアントデバイス110がある時点で信用でき、他の時点で信用できないことを示し得る。言い換えれば、クライアントデバイス110が信用できると判定された1つまたは複数の前のインスタンス、およびクライアントデバイス110が信用できないと判定された1つまたは複数の前のインスタンスが存在し得る。この例では、評価の結果が、悪意のある当事者がシステムをどのように操作する(game)かを学ぶことを回避するためには、クライアントデバイス110は信用できないというものである場合ですら、信用トークンシステム130は、信用トークンをクライアントデバイス110に発行し得る。これは、悪意のある当事者が、信用トークン発行者がどのように動作するかを判定することを妨げる技術的利点を提供し、それにより、信用トークン発行者に対してセキュリティを提供する。具体的には、悪意のある当事者が、信用トークンシステムがどのように動作するかを学んだ場合、その当事者は、信用できないにもかかわらず、信用トークンを取得するために、システムを操作することが可能である。したがって、悪意のある当事者が、システムがどのように動作するかを学ぶことをこのように妨げることは、セキュリティの増大を実現する。別の例では、履歴記録が、クライアントデバイス110がほとんどの時間または常に信用できないことを示す場合、クライアントデバイス110が、少なくともしきい値数の連続的評価にわたって、またはしきい値時間期間、たとえば、一週間、一月、など、にわたって、信用できると見なされない限り、信用トークンシステム130は、信用トークンをクライアントデバイス110に発行することができない。したがって、クライアントデバイスが信用できるか否かを判定するために履歴記録を使用することができ、これにより、デバイスが信用できるか否かを検出するための手段を提供する技術的利点を提供する。

アプリケーション評価器136は、信用トークン要求のデータを評価して、クライアントデバイス110上のアプリケーション112のインスタンスがアプリケーションの公式ビルドであるかどうかを判定する。アプリケーション評価器136は、アプリケーション112の公式ビルドのコードのハッシュを含むアプリケーションビルドデータベース148(または、他の適切なデータ構造)にアクセスし得る。たとえば、アプリケーション開発者がアプリケーションの新しいビルドを発表するとき、アプリケーション開発者は、アプリケーションのコードを信用トークンシステム130に提供し得る。信用トークンシステム130は、クライアントデバイス110の信用できるプログラム114がアプリケーション112のコードのハッシュを生成するために使用する同じ暗号化関数を使用してコードのハッシュを生成し得る。アプリケーションビルドデータベース148は、各アプリケーションに対して、アプリケーションに対する識別子、およびアプリケーションの各公式ビルドに対して、アプリケーションのコードのハッシュを含み得る。いくつかの実装形態では、信用トークンシステム130は、クライアントデバイス110がダウンロードのためにアプリケーションを利用可能にするアプリケーションストアから、各アプリケーションに対するコードを受信し得る。

アプリケーション評価器136は、信用トークン要求内に含まれたアプリケーションのハッシュをアプリケーションビルドデータベース148内に記憶されたアプリケーションの各公式ビルドに対するアプリケーションのハッシュと比較し得る。アプリケーション評価器は、信用トークン要求内に含まれたアプリケーション112に対する識別子を使用して、アプリケーションビルドデータベース内のアプリケーション112の公式ビルドに対するハッシュを識別し得る。信用トークン要求内のアプリケーション112のコードのハッシュとアプリケーション112の公式ビルドのコードのハッシュの間に一致が存在する場合、アプリケーション評価器136は、クライアントデバイス110上で実行しているアプリケーションのインスタンスはアプリケーションの公式ビルドであり、アプリケーションは信用できるアプリケーションであると判定し得る。一致が存在しない場合、アプリケーション評価器136は、クライアントデバイス110上で実行しているアプリケーションのインスタンスはアプリケーションの公式ビルドではないと判定し得る。

いくつかの実装形態では、信用トークン要求は、アプリケーション112に対する識別子を含まなくてもよい。この例では、アプリケーション評価器136は、アプリケーションのコードのハッシュを複数のアプリケーションのコードのハッシュと比較して、一致が存在するかどうかを判定し得る。

いくつかの実装形態では、アプリケーション評価器136は、インスタンスが公式ビルドではないとの判定に応じて、クライアントデバイス110上で実行しているアプリケーションのインスタンスが信用できるアプリケーションではないと判定し得る。いくつかの実装形態では、アプリケーション評価器136は、インスタンスが公式ビルドではないとの判定に応じて、追加の情報を考慮し得る。たとえば、アプリケーション評価器136は、悪意があるまたは無効として分類されたアプリケーションの非公式ビルドからのネットワークトラフィックの割合を示すネットワークトラフィック分析データを考慮し得る。アプリケーションの非公式ビルドからの少なくともしきい値割合(たとえば、80%、50%、100%、または別の適切なしきい値)のネットワークトラフィックが、悪意があるまたは無効であると見なされる場合、アプリケーション評価器136は、公式ビルドではないアプリケーションのいずれのインスタンスも信用できないと判定し得る。

信用トークン発行者132は、信用トークン要求内に含まれたデータならびに/またはデバイス評価器134および/もしくはアプリケーション評価器136によって行われた判定に基づく信用トークン要求に応じて、信用トークンを発行するかどうかを判定し得る。たとえば、信用トークン発行者132は、デバイスレベルの不正検出信号および/またはアプリケーションのコードを表すデータに基づいて、信用トークン要求に応じて、信用トークンを発行するかどうかを判定し得る。

いくつかの実装形態では、デバイス評価器134がクライアントデバイス110は信用できるデバイスであると判定するとき、かつ/またはアプリケーション評価器136がアプリケーション112は信用できるアプリケーションであると判定するとき、信用トークン発行者132は、信用トークン要求に応じて、信用トークンをクライアントデバイス110に発行し得る。いくつかの実装形態では、クライアントデバイス110が信用できるデバイスであると見なされ、かつアプリケーション112が信用できるアプリケーションであると見なされるときのみ、信用トークン発行者132は、信用トークンをクライアントデバイス110に発行すると判定する。いくつかの実装形態では、信用トークン発行者132は、デバイス評価器134またはアプリケーション評価器136のうちの少なくとも1つが信用性評決を出力するとき、信用トークンを発行すると判定する。他の実装形態は、1つの評価器がクライアントデバイス110またはアプリケーション112は信用できると見なすとき、信用トークン発行者132がトークンをクライアントデバイス110に発行するように、デバイス評価器134またはアプリケーション評価器132のうちの1つのみを含み得る。信用トークンを発行するための例示的なプロセスについては、図2に示し、以下で説明する。

信用トークン発行者132は、クライアントデバイス110に発行された信用トークンの数のカウントをトークン発行データベース142(または、他の適切なデータ構造)内に保持し得る。トークン発行データベース142は、各デバイス識別子に対して、1つまたは複数の時間期間にわたって、たとえば、毎日、毎週、毎月、かつ/またはデバイス識別子を含む第1の信用トークン要求以降全体的に、デバイス識別子に対応する、クライアントデバイス110に発行された信用トークンの数のカウントを含み得る。信用トークン発行者132は、このデータを使用して、クライアントデバイス110に発行された信用トークンの数を限定すること、または信用トークンがデバイスに発行されることを全面的に防ぐことができる。たとえば、クライアントデバイス110に対する履歴傾向に基づいて、たとえば、要求される信用トークンの数がクライアントデバイスに対して以上に高い場合、クライアントデバイス110は最近損なわれた可能があるため、信用トークン発行者132は、信用トークンをクライアントデバイス110に発行することを停止し得る。これは、デバイスレベルおよびアプリケーションレベルの信号が、そのデバイスが信用できることを示す場合ですら、潜在的に信用できないデバイスに信用トークンが発行されることを防ぐ技術的利点を提供し、それにより、信用できないデバイスを検出するための改善された方法を提供する。これはまた、信用できないデバイスが信用できると見なされることを防ぐことによって、セキュリティを保持する技術的利点を提供する。

信用トークン発行者132は、クライアントデバイス110に対する信用トークンを償還することもできる。クライアントデバイス110のアプリケーション112がそれに関するSRRが適切である要求を送ろうとしているとき、アプリケーション112は、信用トークンを信用トークンシステム130に償還する要求を送り得る。この要求は、クライアントデバイス110に発行される信用トークンを含み得る。信用トークン発行者132は、信用トークンを評価し、有効である場合、信用トークン発行者は、SRRを生成し、SRRをクライアントデバイス110に送り得る。

信用トークン発行者132が信用トークンを償還するとき、信用トークン発行者132は、トークン償還データベース144(または、他の適切なデータ構造)を更新し得る。信用トークン発行者132は、トークン償還データベース144を使用して、各信用トークンが一回のみ償還されることを確実にし得る。トークン償還データベース144は、各償還された信用トークンに対して、信用トークンのナンスの平文値を含み得る。信用トークン発行者132が信用トークンを償還する要求を受信するとき、信用トークン発行者132は、ナンスの平文値をトークン償還データベース144内のナンスの平文値と比較し得る。一致が存在する場合、信用トークンはすでに償還されており、信用トークン発行者は、SRRを発行しなくてよい。一致が存在しない場合、信用トークン発行者132は、SRRを発行し、信用トークンも有効であると仮定して、償還された信用トークンのナンスの平文値を含めるためにトークン償還データベース144を更新し得る。信用トークンを償還するための例示的なプロセスについては、図3に示し、以下で説明する。

信用トークンを償還した後、アプリケーション112は、要求を受信者の受信者デバイス120に送り得る。この要求は、信用トークンの償還に応じて、クライアントデバイス110(または、アプリケーション112)に発行されたSRRを含み得る。受信者デバイス120は、SRRを評価して、その要求に応答するかどうか、かつ/またはどのように応答するかを判定し得る。SRRを含む要求を処理するための例示的なプロセスについては、図4に示し、以下で説明する。

図2は、信用トークンを発行するための例示的なプロセスを示す流れ図である。プロセス200は、たとえば、信用トークンシステム、たとえば、図1の信用トークンシステム130、によって実装され得る。プロセス200の動作は、非一時的コンピュータ可読媒体上に記憶された命令として実装されてもよく、1つまたは複数のデータ処理装置による命令の実行は、1つまたは複数のデータ処理装置にプロセス200の動作を実行させ得る。簡潔のために、プロセス200は、図1の信用トークンシステム130に関して説明される。

信用トークンシステム130は、1つまたは複数の信用トークンに対する要求をクライアントデバイス110から受信する(202)。クライアントデバイス110上にインストールされたアプリケーション112は、アプリケーション112が信用トークンを使用して、受信者と通信しているクライアントデバイス110の完全性を検証することができるように、要求を開始し得る。たとえば、アプリケーション112は、周期的に(たとえば、一日一回、週に一回、など)、または記憶されているが、アプリケーション112に対して信用トークンが償還されていない数がしきい値以下に下がるとき、信用トークンを要求し得る。信用トークンを要求するために、アプリケーション112は、クライアントデバイス110の信用できるプログラム114のAPI、たとえば、クライアントデバイス110のオペレーティングシステムを呼び出すことができる。

信用トークンシステム130によって受信された要求は、各要求された信用トークンに対するナンス、デバイスレベルの不正検出信号、および信用トークンに対する要求を開始したアプリケーション112に関するデータを含み得る。いくつかの実装形態では、要求は、クライアントデバイス110に対する一意のデバイス識別子を含んでもよい。アプリケーションに関するデータは、アプリケーションに対する識別子およびアプリケーションのコードのハッシュを含み得る。

信用トークンシステム130は、デバイスレベルの不正検出信号を評価する(204)。たとえば、信用トークンシステム130のデバイス評価器134は、不正検出信号内に含まれた動作特性およびメトリックを真のクライアントデバイス、エミュレータ、ルート化デバイスなどに対する対応する特性およびメトリックと比較し得る。クライアントデバイス110の特性およびメトリックがデバイスのカテゴリーのうちの1つと同様である場合、デバイス評価器134は、クライアントデバイス110をそのカテゴリーに分類し得る。たとえば、デバイス評価器134は、各動作特性またはメトリックに対して、真のクライアントデバイスを特徴づける第1の値もしくは第1の値範囲、エミュレータを特徴づける第2の値もしくは第2の値範囲、および/またはルート化デバイスを特徴づける第3の値もしくは第3の値範囲にアクセスする。デバイス評価器134は、クライアントデバイス110の各動作特性またはメトリックを各デバイスカテゴリーの対応する値または値範囲と比較し得る。デバイス評価器134は、複数の特性およびメトリックに対してこの比較を実行し、より多くの動作特性およびメトリックが真のデバイスに対する対応する範囲内であるか(または、それらの範囲に近いか)、エミュレータに対する対応する範囲内であるか(または、それらの範囲に近いか)、またはルート化デバイスに対する対応する範囲内であるか(または、それらの範囲に近いか)を判定し得る。デバイス評価器134は、次いで、クライアントデバイス110が、それに関してより多くのメトリックがデバイスカテゴリーの範囲内にあるデバイスカテゴリーにより類似すると判定し得る。他の実装形態では、他のデバイスカテゴリーが使用されてよく、デバイスの他のタイプのパラメータが使用されてよい。他の実装形態では、教師ありまたは半教師あり機械学習(ML)モデルに対する入力信号として収集された動作特性およびメトリック、およびトレーニングラベルとして、既知のデバイスの既知のカテゴリーを使用して、デバイスを複数のデバイスカテゴリーに分類するように、MLモデルをトレーニングし得る。

別の例では、デバイス評価器134は、動作特性およびメトリックに基づいて、クライアントデバイス110に信用性のレベルを割り当て得る。たとえば、デバイス評価器134は、各動作特性またはメトリックを信用できるデバイスを示す対応する値または値範囲と比較し得る。デバイス評価器134は、信用できる範囲内および/または信用できる対応するしきい値範囲内にある動作特性およびメトリックの数に基づいて、信用性のレベルを割り当て得る。

デバイス評価器134は、評価に基づいて、クライアントデバイス110が信用できるデバイスであるかどうかを判定する(206)。デバイス評価器134は、クライアントデバイス110に割り当てられた信用性のレベルに基づいて、クライアントデバイス110が信用できるデバイスかどうかを判定し得る。たとえば、デバイス評価器134は、たとえば、データベースから信用性しきい値にアクセスし、信用性のレベルを信用性しきい値と比較し得る。信用性のレベルがしきい値を満たす(たとえば、しきい値以上である)場合、デバイス評価器134は、クライアントデバイス110が信用できるデバイスであると判定し得る。信用性のレベルがしきい値を満たさない場合、デバイス評価器134は、クライアントデバイス110が信用できないデバイスであると判定し得る。いくつかの実装形態では、しきい値は、不正を検出するために信用トークンを使用する、発行された信用トークンのユーザ、たとえば、発行された信用トークンの受信者、によって設定され得る。しきい値は、信用トークンシステム130によって、たとえば、信用トークン発行者132によって設定され得る。

別の例では、デバイス評価器134は、クライアントデバイス110に割り当てられたカテゴリーに基づいて、クライアントデバイス110が信用できるデバイスかどうかを判定し得る。デバイス評価器134は、クライアントデバイス110に割り当てられたカテゴリーを信用できると見なされる1つまたは複数のカテゴリーおよび信用できないと見なされる1つまたは複数のカテゴリーと比較し得る。たとえば、デバイス評価器134がクライアントデバイス110を真のクライアントデバイスと分類する場合、デバイス評価器134は、クライアントデバイス110が信用できるデバイスであると判定し得る。デバイス評価器134がクライアントデバイス110をエミュレータまたはルート化デバイスと分類する場合、デバイス評価器134は、クライアントデバイス110が信用できないデバイスであると判定し得る。信用できるデバイスおよび信用できないデバイスに対するカテゴリーは、データベースからアクセスされ得る。

別の例では、デバイス評価器134は、所与の時間期間にわたって、たとえば、過去一時間、過去一日、過去一週間、過去一月、など、クライアントデバイス110によって要求された信用トークンの数に基づいて、クライアントデバイス110が信用できるデバイスかどうかを判定し得る。たとえば、デバイス評価器134は、たとえば、データベースからトークンしきい値にアクセスし、所与の時間期間中にクライアントデバイス110によって要求されたトークンの数をしきい値と比較し得る。所与の時間期間中にクライアントデバイス110によって要求されたトークンの数がしきい値未満である場合、デバイス評価器134は、クライアントデバイス110は信用できると判定し得る。所与の時間期間中にクライアントデバイス110によって要求されたトークンの数がしきい値以上である場合、デバイス評価器134は、クライアントデバイス110は信用できないと判定し得る。これは、デバイスレベルおよびアプリケーションレベルの信号がそのデバイスは信用できることを示す場合ですら、潜在的に信用できないデバイスに信用トークンが発行されることを防ぐ技術的利点を提供し、それにより、信用できないデバイスを検出するための改善された方法を提供する。

いくつかの実装形態では、デバイス評価器134は、デバイスレベルの不正検出信号の評価および所与の時間期間中に要求された信用トークンの数の組合せに基づいて、クライアントデバイス110が信用できるデバイスであると判定し得る。たとえば、デバイス評価器134は、信用性のレベルがそのしきい値を満たし(または、クライアントデバイス110に割り当てられたカテゴリーが信用できるカテゴリーであり)、クライアントデバイス110によって要求された信用トークンの数がそのしきい値未満であるときのみ、クライアントデバイス110は信用できるデバイスであると判定し得る。

デバイス評価器134がクライアントデバイス110は信用できるデバイスではないと判定する場合、信用トークンシステム130は、信用トークンをクライアントデバイス110に発行することはできない(208)。いくつかの実装形態では、上記で説明したように、信用トークンが信用できるデバイスではないと判定される場合ですら、信用トークンシステム130は、信用トークンをクライアントデバイスに発行し得る。これらの特定の実装形態では、これは、信用できないデバイスがシステムを操作することができないように、信用できないデバイスが、信用トークンシステムがどのように動作するかに関するいずれの情報も推論することを防ぐ技術的利点を提供する。したがって、これは、信用トークンシステムのセキュリティおよび完全性を増大する。

デバイス評価器134がクライアントデバイスは信用できるデバイスであると判定する場合、アプリケーション112の信用性が評価される(210)。信用トークンシステム130のアプリケーション評価器136は、アプリケーション112の信用性を評価し得る。アプリケーション評価器136は、要求内で受信されたアプリケーション112のコードのハッシュをアプリケーションの既知の公式ビルドのコードのハッシュと比較して、クライアントデバイス110上にインストールされたアプリケーション112のインスタンスがアプリケーション112の公式ビルドであるかどうかを判定し得る。要求内で受信されたアプリケーション112のコードのハッシュがアプリケーション112の既知の公式ビルドのコードのハッシュと一致する場合、アプリケーション評価器136は、クライアントデバイス110上にインストールされたアプリケーション112のインスタンスがアプリケーション112の公式ビルドであると判定し得る。一致が存在しない場合、アプリケーション評価器136は、クライアントデバイス110上にインストールされたアプリケーション112のインスタンスがアプリケーション112の公式ビルドではないと判定し得る。

いくつかの実装形態では、デバイス評価器134は、アプリケーション112のコードが、悪意がないとして証明されているかどうかに基づいて、アプリケーション112が信用できるアプリケーションであるかどうかを判定する。たとえば、オペレーティングシステム開発者および/またはそこからアプリケーション112がダウンロードされ得るアプリケーションストアを動作させるエンティティなど、信用できる当事者は、アプリケーション112の公式バージョンのコードを評価して、アプリケーション112の公式ビルドが、ウィルス、マルウェア、または他の悪意のあるアプリケーション論理を含むかどうかを判定し得る。そのような悪意のあるアプリケーション論理が見出されない場合、信用できる当事者は、アプリケーション112に対して、アプリケーション112が悪意のあるアプリケーション論理を含まないことを示す証明書を発行し得る。悪意のあるアプリケーション論理が信用できる当事者によって見出された場合、信用できる当事者は、アプリケーション112が悪意のあるアプリケーション論理を含むことを示す証明書を発行することを断ることまたは証明書を発行することができる。信用できる当事者は、アプリケーションの各公式ビルドを評価し、評価に基づいて、各公式ビルドに対してそれぞれの証明書を発行するかどうかを判定し得る。信用できる当事者がアプリケーションストアである例では、アプリケーション112が公式ビルドであり、かつ悪意のあるアプリケーション論理を含まないことを示す証明書を発行する代わりに、アプリケーションが広く配信され得るように、アプリケーションストアは、アプリケーションストア内でアプリケーションを公開し得る。いくつかの例では、アプリケーション112が公式ビルドであり、悪意のあるアプリケーション論理を含まないことを示す証明書を発行する代わりに、信用できる当事者は、アプリケーション112に対するすべての既知の信用できるアプリケーションを列挙するデータベースに記録を挿入し得る。

アプリケーション評価器136は、クライアントデバイス110上にインストールされたアプリケーション112が信用できるかどうかを判定する(212)。いくつかの実装形態では、アプリケーション評価器136は、アプリケーション112が公式ビルドであるとの判定に応じて、アプリケーション112は信用できると判定する。アプリケーション112が公式ビルドでない場合、アプリケーション評価器は、悪意があるまたは無効として分類されたアプリケーションの非公式ビルドからのネットワークトラフィックの割合を示すネットワークトラフィック分析データを考慮し得る。アプリケーションの非公式ビルドからの少なくともしきい値割合のネットワークトラフィックが、悪意があるまたは無効であると見なされる場合、アプリケーション評価器136は、公式ビルドではないアプリケーション112のいずれのインスタンスも信用できないと判定し得る。しきい値割合未満のネットワークトラフィックが、悪意があるまたは無効であると見なされる場合、アプリケーション評価器136は、アプリケーション112が公式ビルドでないにもかかわらず、アプリケーション112は信用できると判定し得る。

いくつかの実装形態では、アプリケーション評価器136は、アプリケーション112が公式ビルドであるとの判定に応じて、かつアプリケーション112が悪意のあるアプリケーション論理を含まないことを示す証明書がクライアントデバイス112上のアプリケーション112のビルドに対して発行されているとの判定に応じて、アプリケーション112は信用できるアプリケーションであると判定する。すなわち、この実装形態では、アプリケーション112は両方の基準を満たさなければならない。

アプリケーション評価器136がアプリケーション112は信用できないと判定する場合、信用トークンシステム130は、信用トークンをクライアントデバイス110に発行することができない(208)。アプリケーション評価器136がアプリケーション112は信用できると判定する場合、信用トークンシステムは、アプリケーション112に対する信用トークンを生成する。

この例示的なプロセスでは、信用トークンシステム130は、クライアントデバイス110とアプリケーション112が両方とも信用できると見なされるときのみ、信用トークンを発行する。他の例では、信用トークンシステム130は、たとえば、クライアントデバイス110またはアプリケーション112のいずれかを評価することによってのみ、クライアントデバイス110またはアプリケーション112のいずれかが信用できると見なされるとき、信用トークンを発行し得る。

信用トークンシステム130の信用トークン発行者132は、要求内で受信された各ナンスに対する信用トークンを生成し得る(214)。信用トークン発行者132は、ナンスの値に基づいてデジタル署名を生成することによって、信用トークンを生成し得る。信用トークンは、ナンスおよびデジタル署名の組合せであってよい。

いくつかの実装形態では、信用トークン発行者132は、ナンスをブラインド化するためにクライアントデバイス110において使用される同じブラインド署名方式を使用してブラインド化ナンスをブラインド署名することによって、信用トークンを生成する。このようにして、信用トークン発行者132は、ナンスの実際の平文値にアクセスすることはできないが、ナンスの平文値に基づいて後で検証され得るデジタル署名を生成し得る。この例では、信用トークンは、ブラインド化ナンスおよびブラインド化ナンスのブラインド署名の組合せであってよい。以下で論じるように、信用トークン発行者がナンスの平文値にアクセスすることができないようにナンスをブラインド化することは、ユーザデータに対してプライバシーを保持する技術的利点を提供する。これは、信用トークンシステムは、(信用トークンの発行時に信用トークン発行者によって理解される)ブラインド化ナンスを(発行されたトークンの償還時に理解される)対応する非ブラインド化ナンスと相関させることができず、したがって、信用トークンシステムは、発行された信用トークンを償還された信用トークンと相関させることを試みることによって、クライアントデバイスからの任意のユーザ情報を推論することができないためである。

いくつかの実装形態では、信用トークンは、追加のデータを、たとえば、ブラインド署名内に符号化されたメタデータの形態で、含んでもよい。符号化されたメタデータは、信用トークン発行者132が様々なトークン発行論理を比較し、どの論理が不正検出において最も効率的であるかを判定するのに役立ち得る。加えて、符号化されたメタデータは、デバイス110およびアプリケーション112に割り当てられた信用性のレベルを示し得る。信用トークン発行者132は、少量の情報を隠れビットおよび署名検証鍵の形態でブラインド署名に符号化し得る。たとえば、ブラインド署名が4個の検証鍵のうちの1つによって検証され得る場合、信用トークン発行者132は、2ビットの情報を署名内に符号化し得る。

いくつかの実装形態では、信用トークン発行者132は、クライアントデバイス110の公開鍵を使用して各信用トークンを暗号化し得る。たとえば、信用トークンに対する要求は、クライアントデバイス110に対する一意の識別子として、クライアントデバイス110の公開鍵を含み得る。クライアントデバイス110の公開鍵を使用して各信用トークンを暗号化することによって、秘密鍵を有するクライアントデバイス110のみが信用トークンを解読し得る。これは、信用トークンに対する要求を提出したクライアントデバイス110が秘密鍵を実際に有し、したがって、他のクライアントデバイスが発行された信用トークンを取得できないことを確実にする。したがって、これは、要求を提出し、公開鍵に対応する秘密鍵を実際に所有するクライアントデバイスのみが発行された信用トークンを償還し得ることを確実にすることによって、発行された信用トークンに対する追加のセキュリティを提供する。したがって、要求側クライアントデバイスの公開鍵を使用して、各信用トークンを暗号化することによって、発行された信用トークンに対する追加のセキュリティの技術的利点が提供される。

信用トークン発行者132は、信用トークンをクライアントデバイス110に送る(216)。信用トークンがクライアントデバイス110の公開鍵を使用して暗号化される場合、信用できるプログラム114は、公開鍵に対応する秘密鍵を使用して、信用トークンを解読し得る。ブラインド化ナンスが使用される場合、ブラインド化ナンスを生成したアプリケーション112(または、信用できるプログラム114)は、各信用トークンのブラインド署名を検証し得る。アプリケーション112または信用できるプログラム114は、アプリケーション112または信用できるプログラム114が信用トークンに対する要求のために作成したナンスのブラインド化された値に基づいて、ブラインド署名を検証し得る。署名が有効でない場合、アプリケーション112または信用されたプログラム114は、信用トークンを拒否し得る。

署名が有効である場合、アプリケーション112または信用できるプログラム114は、ナンスをブラインド化し、ブラインド化ナンスをブラインド署名するために使用されたブラインド署名方式を使用して、ブラインド化ナンスを非ブラインド化し得る。ナンスを非ブラインド化することは、ナンスがもはや不明瞭でないように、ブラインド化係数をナンスから除去することを含み得る。ブラインド署名方式に応じて、アプリケーション112または信用できるプログラム114は、たとえば、ブラインド署名からブラインド化係数を除去することによって、ブラインド署名方式を使用して、ブラインド署名を非ブラインド化してもよい。

アプリケーション112は、その場合、各信用トークンに対して、非ブラインド化ナンス(たとえば、平文ナンス)およびブラインド署名をブラインド化された形態または非ブラインド化された形態のいずれかで含む信用トークンの非ブラインド化されたバージョンを記憶し得る。すなわち、アプリケーション112は、非ブラインド化ナンスおよびブラインド署名を含む信用トークンの新しいバージョンを更新または生成し得る。アプリケーション112は、クライアントデバイス110におけるセキュアな記録ロケーション内に信用トークンを記憶し得る。

図3は、信用トークンを償還するための例示的なプロセス300を示す流れ図である。プロセス300は、たとえば、信用トークンシステム、たとえば、図1の信用トークンシステム130、によって実装され得る。プロセス300の動作は、非一時的コンピュータ可読媒体上に記憶された命令として実装されてもよく、1つまたは複数のデータ処理装置による命令の実行は、1つまたは複数のデータ処理装置にプロセス300の動作を実行させ得る。簡潔のために、プロセス300は、図1の信用トークンシステム130に関して説明される。

信用トークンシステム130は、信用トークンを償還する要求をクライアントデバイス110から受信する(302)。クライアントデバイス110上で実行しているアプリケーション112は、要求にSRRを含めることを求める、受信者に対する要求の開始に応じて、信用トークンを償還する要求を発行し得る。たとえば、ウェブブラウザが発行者の特定のウェブサイトにナビゲートするとき、ウェブサイトまたはそのウェブサイト内に埋め込まれた別のドメインのモジュールは、信用トークンを償還して、クライアントデバイス110およびウェブブラウザが信用できることを確実にするようにウェブブラウザに要求し得る。

アプリケーション112は、アプリケーション112に発行された複数の信用トークンから信用トークンを取得し、信用トークンを含む償還要求を信用トークンシステム130に送ることができる。この要求は、アプリケーション112によって生成された公開鍵(または、公開鍵の暗号ハッシュ)を含んでもよい。ウェブブラウザの例を続けると、この要求は、ブラウザがウェブブラウザによって提示されているウェブサイトのドメインに対して作成した公開鍵、およびそのドメインを識別するデータを含み得る。ウェブブラウザは、ウェブブラウザが訪問した各ドメインに対する鍵ペアを生成し得る。各鍵ペアは、公開鍵および対応する秘密鍵を含み得る。

信用トークンを生成するためにブラインド化ナンスが使用される場合、償還のために送られる信用トークンは、ブラインド化ナンスではなく、非ブラインド化ナンスおよびブラインド署名を含み得る。このようにして、信用トークンシステム130は、償還のために提出された信用トークンをアプリケーション112に発行された信用トークンと相関させることができず、これは、信用トークンシステムが、発行され、その後、償還された信用トークンから、クライアントデバイスまたはクライアントデバイスのユーザに関する何らかの情報を推論することができないことを意味する。したがって、これは、信用トークンを償還するとき、ユーザプライバシーを保持する技術的利点を提供する。信用トークンシステム130は、発行された信用トークン(および、したがって、ブラインド化ナンス)および信用トークンを発行するときに査定された信用性のレベルをクライアントデバイス110に対するデバイス識別子とリンクするデータを記憶し得るため、信用トークンシステム130は、場合によっては、クライアントデバイス110からのSRRの受信者を信用性のレベルと相関させることが可能になる。しかしながら、信用トークンシステム130は、非ブラインド化ナンスをブラインド化ナンスと相関させることができないため、償還において非ブラインド化ナンスを有する信用トークンを使用することは、図2の動作204および210において信用トークンをデバイスレベルの不正検出信号およびアプリケーション112に関するデータと相関させることを妨げる。これにより、この技法は、ユーザのプライバシーを保護する。

信用トークンシステム130は、受信された信用トークンのブラインド署名の検証を試みる(304)。たとえば、信用トークンシステム130の信用トークン発行者132は、発行された信用トークンのブラインド化ナンスをブラインド署名するために使用されたブラインド署名方式を使用して、ブラインド署名の検証を試みることができる。信用トークン発行者132は、ブラインド署名方式および非ブラインド化ナンスの平文値を使用して、ブラインド署名を検証し得る。

ブラインド署名が成功裏に検証されない(306)場合、信用トークンシステム130は、信用トークンを償還することができない(308)。ブラインド署名が成功裏に検証される場合、信用トークン発行者132は、信用トークンがすでに償還されているかどうかを判定する(310)。この判定は、ブラインド署名を検証する前、その後、またはそれと並行してもしくは同時に、実行され得る。

信用トークン発行者132は、非ブラインド化ナンスを、たとえば、トークン償還データベース144内に記憶された、前に償還された信用トークンの非ブラインド化ナンスと比較し得る。前に償還された信用トークンは、クライアントデバイス110からまたは複数のクライアントデバイス110から償還されたトークンを含み得る。償還されることになる信用トークンの非ブラインド化ナンスと前に償還された信用トークンの非ブラインド化ナンスの間に一致が存在する場合、信用トークン発行者132は、信用トークンが前に償還されていると判定し得る。償還されることになる信用トークンの非ブラインドナンスと前に償還された信用トークンの非ブラインド化ナンスの間に一致が存在しない場合、信用トークン発行者132は、信用トークンが前に償還されていないと判定し得る。

信用トークンが前に償還されている場合、信用トークン発行者132は、信用トークンを再度償還することができない(308)。信用トークンがまだ償還されていない場合、信用トークン発行者132は、信用トークンを償還し、SRRをアプリケーション112に発行し得る(312)。

SRRは、SRRが生成された時間および日付を示す償還タイムスタンプを含むデータのセット、償還要求内で識別されたウェブサイトのドメインを識別するデータ、ブラウザがドメインに対して作成した公開鍵、および/または複数の信用する信用トークンステムが存在し得るため、信用トークンを発行および償還した信用トークンシステム130を識別するデータのセットを含み得る。SRRは、信用トークンシステム130の秘密鍵を使用して生成されたデータのセットのデジタル署名を含んでもよい。このようにして、受信者および任意の他のエンティティは、信用トークンシステム130の秘密鍵に対応する公開鍵を使用してデジタル署名を検証することによって、データのセットが操作されていないことを検証し得る。信用トークンシステム130の秘密鍵を使用して署名されているデータとともに、ブラウザがドメインに対して作成した公開鍵を含めることは、SRRをその特定のドメインおよびブラウザとバインドする。信用トークン発行者132は、SRRを生成し、信用トークンの償還を要求したアプリケーション112にSRRを送ることができる。

信用トークン発行者132は、信用トークンが償還されていることを示すようにトークン償還データベース144を更新することもできる(314)。たとえば、信用トークン発行者132は、非ブラインド化ナンスの平文値をトークン償還データベース144に追加して、信用トークンが複数回償還されることを防ぐことができる。

図4は、償還された信用トークンに基づいて、署名された償還記録を含む要求を処理するための例示的なプロセス400を示す流れ図である。プロセス400は、たとえば、受信者デバイス、たとえば、図1の受信者デバイス120、によって実装され得る。プロセス400の動作は、非一時的コンピュータ可読媒体上に記憶された命令として実装されてもよく、1つまたは複数のデータ処理装置による命令の実行は、1つまたは複数のデータ処理装置にプロセス400の動作を実行させ得る。簡潔のために、プロセス400は、図1の信用トークンシステム130に関して説明される。

受信者デバイス120は、1つまたは複数のSRRを含む要求をクライアントデバイス110から受信する(402)。この要求は、デバイスおよび上記で説明したアプリケーション評価に基づいて生成された、償還された信用トークンに対して生成されたSRRを含み得る。いくつかの実装形態では、この要求は、クライアントデバイス上の1つまたは複数のアプリケーションとのユーザ対話の評価に基づいて、たとえば、評価、およびユーザ対話が、エミュレートされたユーザ対話ではなく、真のユーザ対話であるとの判定に基づいて、発行された信用トークンに基づいて生成された追加のSRRを含み得る。この要求のSRRは、償還された信用トークンに基づいてアプリケーション112(または、図1の信用できるプログラム114)に対して信用トークンシステム130によって生成されたSRRを含み得る。

この要求は、たとえば、SRRを含む、要求の他のコンテンツのデジタル署名を含んでもよい。アプリケーション112または信用できるプログラム114は、アプリケーション112がドメインに対して作成した秘密鍵を使用してデジタル署名を生成し得る。この秘密鍵は、アプリケーション112がドメインに対して生成した公開鍵に対応する。公開鍵、またはその暗号ハッシュ結果のいずれかが、SRR内に含まれる。このようにして、要求およびSRRはドメインにバインドされる。

受信者デバイス120は、各SRRの検証を試みる(404)。この検証は、SRRを生成した信用トークンシステム130の公開鍵を使用して、SRRのデジタル署名の検証を試みることを含み得る。受信者デバイス120は、SRRが古い状態でないことを確実にするために、償還タイムスタンプが現在時間のしきい値時間量内であるかどうかを判定することもできる。

受信者デバイス120は、各SRRが検証されているかどうかを判定する(406)。受信者デバイス120は、SRRのデジタル署名が検証されているかどうか、かつ/または償還タイムスタンプがしきい値時間量内であるかどうかに基づいて、SRRが検証されているかどうかを判定し得る。デジタル署名が成功裏に検証され、かつ償還タイムスタンプが現在時間のしきい値時間量内である場合、受信者デバイス120は、SRRは検証されていると判定し得る。デジタル署名が成功裏に検証されないか、または償還タイムスタンプが現在時間のしきい値時間量内でない場合、受信者デバイス120は、SRRは検証されていないと判定し得る。

いくつかの実装形態では、受信者デバイス120は、アプリケーションがドメインに対して作成した公開鍵を使用して要求のデジタル署名を検証することもでき、公開鍵(または、その暗号ハッシュ結果)は、たとえば、SRRおよび/または要求自体の中に含まれてよい。デジタル署名を検証することができない場合、受信者デバイス120は、要求は無効であると判定することができ、その要求に応答しなくてよい。

各SRRが検証されない場合、受信者デバイス120は、その要求に応答しなくてよい(408)。たとえば、受信者デバイス120は、その要求を無視してよい。

各SRRが検証される場合、受信者デバイス120は、その要求に応答する(410)。たとえば、受信者デバイス120は、その要求に応答してコンテンツを提供し、その要求に基づいて、データ、またはその要求に応じて設定を更新すること、などが可能である。

図5は、上記で説明した動作を実行するために使用され得る例示的なコンピュータシステム500のブロック図である。システム500は、プロセッサ510、メモリ520、記憶デバイス530、および入出力デバイス540を含む。構成要素510、520、530、および540の各々は、たとえば、システムバス550を使用して、相互接続され得る。プロセッサ510は、システム500内で実行するための命令を処理することが可能である。いくつかの実装形態では、プロセッサ510は、シングルスレッドプロセッサである。別の実装形態では、プロセッサ510は、マルチスレッドプロセッサである。プロセッサ510は、メモリ520内または記憶デバイス530上に記憶された命令を処理することが可能である。

メモリ520は、情報をシステム500内に記憶する。一実装形態では、メモリ520は、コンピュータ可読媒体である。いくつかの実装形態では、メモリ520は、揮発性メモリユニットである。別の実装形態では、メモリ520は、不揮発性メモリユニットである。

記憶デバイス530は、システム500に対する大容量記憶装置を提供し得る。いくつかの実装形態では、記憶デバイス530は、コンピュータ可読媒体である。様々な異なる実装形態では、記憶デバイス530は、たとえば、ハードディスクデバイス、光ディスクデバイス、複数のコンピューティングデバイス(たとえば、クラウド記憶デバイス)によってネットワーク上で共有される記憶デバイス、または何らかの他の大容量記憶デバイスを含み得る。

入出力デバイス540は、システム500に対する入出力動作を提供する。いくつかの実装形態では、入出力デバイス540は、ネットワークインターフェースデバイス、たとえば、Ethernetカード、シリアル通信デバイス、たとえば、RS-232ポート、および/またはワイヤレスインターフェースデバイス、たとえば、802.11カードのうちの1つまたは複数を含み得る。別の実装形態では、入出力デバイスは、入力データを受信し、出力データを外部デバイス560、たとえば、キーボード、プリンタ、およびディスプレイデバイスに送るように構成された、ドライバデバイスを含み得る。しかしながら、モバイルコンピューティングデバイス、モバイル通信デバイス、セットトップボックステレビジョンクライアントデバイス、など、他の実装形態が使用されてもよい。

例示的な処理システムが図5で説明されているが、本明細書で説明した主題および機能的動作の実装形態は、他のタイプのデジタル電子回路において、あるいは、本明細書で開示した構造およびそれらの構造等価物を含む、コンピュータソフトウェア、ファームウェア、もしくは、ハードウェアにおいて、またはそれらのうちの1つもしくは複数の組合せにおいて実装され得る。

本明細書で説明した主題および動作の実施形態は、デジタル電子回路において、または、本明細書で開示した構造およびそれらの構造等価物を含む、コンピュータソフトウェア、ファームウェア、もしくはハードウェアにおいて、またはそれらのうちの1つもしくは複数の組合せにおいて実装され得る。本明細書で説明した主題の実施形態は、データ処理装置による実行のために、またはデータ処理装置の動作を制御するために、1つまたは複数のコンピュータ記憶媒体上で符号化された1つまたは複数のコンピュータプログラム、すなわち、コンピュータプログラム命令の1つまたは複数のモジュールとして実装され得る。代替的にまたは追加として、プログラム命令は、データ処理装置による実行のために、好適な受信機装置への送信のために情報を符号化するために生成された、人工的に生成された伝搬信号、たとえば、機械生成の電気、光、または電磁信号上で符号化され得る。コンピュータ記憶媒体は、コンピュータ可読記憶デバイス、コンピュータ可読記憶基板、ランダムもしくはシリアルアクセスメモリアレイまたはデバイス、またはそれらのうちの1つもしくは複数の組合せであり得るか、またはその中に含まれ得る。さらに、コンピュータ記憶媒体は、伝搬信号ではなく、コンピュータ記憶媒体は、人工的に生成された伝搬信号において符号化されたコンピュータプログラム命令のソースまたは宛先であり得る。コンピュータ記憶媒体はまた、1つもしくは複数の別個の物理的構成要素または媒体(たとえば、複数のCD、ディスク、または他の記憶デバイス)であり得るか、またはその中に含まれ得る。

本明細書で説明した動作は、1つまたは複数のコンピュータ可読記憶デバイス上に記憶されたか、または他のソースから受信されたデータに対して、データ処理装置によって実行される動作として実装され得る。

「データ処理装置」という用語は、例として、プログラマブルプロセッサ、コンピュータ、システムオンチップ、もしくは上記のうちの複数のもの、または上記の組合せを含めて、データを処理するためのすべての種類の装置、デバイス、および機械を包含する。装置は、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)を含むことができる。装置は、ハードウェアに加えて、当該のコンピュータプログラムのための実行環境を作成するコード、たとえば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、クロスプラットフォームランタイム環境、仮想マシン、またはそれらのうちの1つもしくは複数の組合せを構成するコードをも含むことができる。装置および実行環境は、ウェブサービス、分散コンピューティングおよびグリッドコンピューティングインフラストラクチャなど、様々な異なるコンピューティングモデルインフラストラクチャを実現することができる。

(プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、またはコードとしても知られる)コンピュータプログラムは、コンパイラ型またはインタープリタ型言語、宣言型または手続き型言語を含む、任意の形態のプログラミング言語で書き込まれてよく、スタンドアロンプログラムとして、またはモジュール、構成要素、サブルーチン、オブジェクト、もしくはコンピューティング環境において使用するのに好適な他のユニットとして、を含めて、任意の形態で展開され得る。コンピュータプログラムは、ファイルシステムにおけるファイルに対応し得るが、そうでなくてもよい。プログラムは、他のプログラムまたはデータ(たとえば、マークアップ言語ドキュメント内に記憶された1つまたは複数のスクリプト)を保持するファイルの一部分に記憶されるか、当該のプログラムに専用の単一のファイル内に記憶されるか、または複数の協調ファイル(coordinate files)(たとえば、1つまたは複数のモジュール、サブプログラム、またはコードの部分を記憶するファイル)内に記憶され得る。コンピュータプログラムは、1つのコンピュータ上で実行されるか、または、1つのサイトに配置されるかもしくは複数のサイトにわたって分散され、通信ネットワークによって相互接続される複数のコンピュータ上で実行されるように展開され得る。

本明細書で説明したプロセスおよび論理フローは、入力データに対して動作し、出力を生成することによって動作を実行するために、1つまたは複数のコンピュータプログラムを実行する1つまたは複数のプログラマブルプロセッサによって実行され得る。プロセスおよび論理フローは、専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)によっても実行され得、装置が、同じく専用論理回路、たとえば、FPGA(フィールドプログラマブルゲートアレイ)またはASIC(特定用途向け集積回路)として実装され得る。

コンピュータプログラムの実行に適したプロセッサは、例として、汎用マイクロプロセッサと専用マイクロプロセッサの両方を含む。概して、プロセッサは、命令およびデータを読取り専用メモリ、もしくはランダムアクセスメモリ、またはその両方から受信することになる。コンピュータの必須要素は、命令に従って動作を実行するためのプロセッサ、および命令およびデータを記憶するための1つまたは複数のメモリデバイスである。概して、コンピュータはまた、データを記憶するための1つまたは複数の大容量デバイス、たとえば、磁気ディスク、光磁気ディスク、または光ディスク、を含むことになるか、またはそれらからデータを受信するか、もしくはそれらにデータを転送するか、またはその両方を実行するように動作可能に結合されることになる。しかしながら、コンピュータは、そのようなデバイスを有さなくてもよい。さらに、コンピュータは、別のデバイス、たとえば、ほんのいくつかの例を挙げれば、モバイル電話、携帯情報端末(PDA)、モバイルオーディオもしくはビデオプレイヤ、ゲームコンソール、全地球測位システム(GPS)受信機、またはポータブル記憶デバイス(たとえば、ユニバーサルシリアルバス(USB)フラッシュドライブ)の中に埋め込まれてもよい。コンピュータプログラム命令およびデータを記憶するのに好適なデバイスは、例として、半導体メモリデバイス、たとえば、EPROM、EEPROM、およびフラッシュメモリデバイス、磁気ディスク、たとえば、内蔵ハードディスクまたはリムーバブルディスク、光磁気ディスク、ならびにCD-ROMおよびDVD-ROMディスクを含む、すべての形態の不揮発性メモリ、媒体およびメモリデバイスを含む。プロセッサおよびメモリは、専用論理回路によって補足され得るか、または専用論理回路内に組み込まれ得る。

ユーザとの対話を提供するために、本明細書で説明した主題の実施形態は、情報をユーザに表示するためのディスプレイデバイス、たとえば、CRT(陰極線管)またはLCD(液晶ディスプレイ)モニタ、およびそれによりユーザが入力をコンピュータに提供し得るキーボードおよびポインティングデバイス、たとえば、マウスまたはトラックボールを有するコンピュータ上で実装され得る。他の種類のデバイスもユーザとの対話を提供するために同様に使用され得る:たとえば、ユーザに提供されるフィードバックは、任意の形態の感覚フィードバック、たとえば、視覚フィードバック、聴覚フィードバック、または触覚フィードバックであってよく、ユーザからの入力は、音響、音声、または触覚入力を含めて、任意の形態で受信され得る。加えて、コンピュータは、ユーザが使用するデバイスに文書を送り、そこから文書を受信することによって、たとえば、ユーザのクライアントデバイス上のウェブブラウザから受信された要求に応じて、ウェブブラウザにウェブページを送ることによって、ユーザと対話し得る。

本明細書で説明した主題の実施形態は、たとえば、データサーバとして、バックエンド構成要素を含むか、もしくはミドルウェア構成要素、たとえば、アプリケーションサーバを含むか、またはフロントエンド構成要素、たとえば、ユーザが本明細書で説明した主題の実装形態とそれを通して対話することができるグラフィカルユーザインターフェースまたはウェブブラウザを有するクライアントコンピュータを含むか、あるいは1つもしくは複数のそのようなバックエンド構成要素、ミドルウェア構成要素、またはフロントエンド構成要素の任意の組合せを含む、コンピューティングシステムにおいて実装され得る。システムの構成要素は、デジタルデータ通信の任意の形態または媒体、たとえば、通信ネットワークによって相互接続され得る。通信ネットワークの例は、ローカルエリアネットワーク(「LAN」)およびワイドエリアネットワーク(「WAN」)、インターネットワーク(たとえば、インターネット)、およびピアツーピアネットワーク(たとえば、アドホックピアツーピアネットワーク)を含む。

コンピューティングシステムは、クライアントおよびサーバを含み得る。クライアントおよびサーバは、概して、互いからリモートにあり、一般に、通信ネットワークを通して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で動作し、互いに対してクライアントサーバ関係を有する、コンピュータプログラムによって生じる。いくつかの実施形態では、サーバは、(たとえば、クライアントデバイスと対話するユーザにデータを表示し、そのユーザからユーザ入力を受信する目的で)クライアントデバイスにデータ(たとえば、HTMLページ)を送信する。クライアントデバイスにおいて生成されたデータ(たとえば、ユーザ対話の結果)は、サーバにおいてクライアントデバイスから受信され得る。

本明細書は多くの特定の実装詳細を含むが、これらは、任意の発明のまたは特許請求され得るものの範囲に対する限定と解釈すべきではなく、特定の発明の特定の実施形態に特定の特徴の説明と解釈すべきである。本明細書で別個の実施形態の文脈で説明したいくつかの特徴は、単一の実施形態で組み合わせて実装されてもよい。逆に、単一の実施形態の文脈で説明した様々な特徴は、複数の実施形態で別個に、または任意の好適な部分組合せで実装されてもよい。さらに、特徴は上記でいくつかの組合せで動作するとして説明されている場合があり、当初、そのように特許請求されている場合すらあるが、特許請求される組合せからの1つまたは複数の特徴は、場合によっては、組合せから削除されてよく、特許請求される組合せは、部分組合せまたは部分組合せの変形形態に関する場合がある。

同様に、動作は図面において特定の順序で示されているが、これは、所望の結果を達成するために、そのような動作が、示された特定の順序でまたは順番で実行されることを必要とする、またはすべての示された動作が実行されるべきであると理解すべきではない。状況によっては、マルチタスキングおよび平行処理が有利であり得る。さらに、上記で説明した実施形態の様々なシステム構成要素の分離は、すべての実施形態においてそのような分離を必要とすると理解すべきではなく、説明したプログラム構成要素およびシステムは、概して、単一のソフトウェア製品内にともに組み込まれてよいか、または複数のソフトウェア製品内に梱包されてよいことを理解されたい。

以上、本主題の特定の実施形態について説明した。他の実施形態は、以下の請求項の範囲内である。場合によっては、請求項で列挙される活動は、異なる順序で実行されてよく、依然として所望の結果を達成する。加えて、添付の図面に示したプロセスは、所望の結果を達成するために、必ずしも示した特定の順序または順番を必要としない。いくつかの実装形態では、マルチタスキングおよび平行処理が有利であり得る。

100 環境
105 データ通信ネットワーク、ネットワーク
110 クライアントデバイス、ユーザデバイス、デバイス
112 アプリケーション
114 信用できるプログラム
120 受信者デバイス
130 信用トークンシステム
132 信用トークン発行者
134 デバイス評価器
136 アプリケーション評価器
142 トークン発行データベース
144 トークン償還データベース
146 デバイス信用データベース
148 アプリケーションビルドデータベース
200 プロセス
300 プロセス
400 プロセス
500 コンピュータシステム
510 プロセッサ、構成要素
520 メモリ、構成要素
530 記憶デバイス、構成要素
540 入出力デバイス、構成要素
550 システムバス
560 外部デバイス

Claims (38)

1. コンピュータ実装方法であって、
   1つまたは複数の信用トークンに対する要求をクライアントデバイスから受信するステップであって、前記要求が、
   (i)前記クライアントデバイスから取得された1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記要求を開始したアプリケーションのコードを表すデータのうちの少なくとも1つ、および
   前記1つまたは複数の信用トークンの各々に対するそれぞれのナンス
   を含む、受信するステップと、
   (i)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定するステップと、
   前記1つまたは複数の信用トークンを前記クライアントデバイスに発行するとの前記判定に応じて、
   前記信用トークンに対する前記ナンスを使用して、前記1つまたは複数の信用トークンの各々を生成するステップと、
   前記1つまたは複数の信用トークンを前記クライアントデバイスに提供するステップと
   を含む、方法。
2. (i)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定するステップが、
   前記1つまたは複数のデバイスレベルの不正検出信号に基づいて、前記クライアントデバイスが信用できるデバイスであると判定するステップと、
   前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定するステップと、
   前記クライアントデバイスが信用できるデバイスであり、前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定するステップと
   を含む、請求項1に記載の方法。
3. 前記アプリケーションの前記コードを表す前記データが、前記アプリケーションの前記コードの暗号学的ハッシュを含む、請求項1または2に記載の方法。
4. 前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定するステップが、
   前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定するステップと、
   前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定するステップと
   を含む、請求項1に記載の方法。
5. 前記アプリケーションが信用できるアプリケーションであると前記判定するステップが、
   前記アプリケーションの前記コードの暗号学的ハッシュを前記アプリケーションの公式ビルドのコードの暗号学的ハッシュと比較するステップと、
   前記アプリケーションの前記コードの前記暗号学的ハッシュと前記アプリケーションの公式ビルドのコードの暗号学的ハッシュの一致に応じて、前記アプリケーションが信用できるアプリケーションであると判定するステップと
   を含む、請求項2または4に記載の方法。
6. 前記アプリケーションが信用できるアプリケーションであると前記判定するステップが、前記アプリケーションが悪意のあるアプリケーション論理を含まないことを示す証明書が前記アプリケーションに対して発行されていると判定するステップを含む、請求項2または4に記載の方法。
7. 各信用トークンに対する前記ナンスが、ブラインド署名方式を使用してブラインド化されたブラインド化ナンスである、請求項1から6のいずれか一項に記載の方法。
8. 前記1つまたは複数の信用トークンの各々を前記生成するステップが、ブラインド署名方式を使用して、前記信用トークンに対する前記ブラインド化ナンスのブラインド署名を生成するステップであって、前記信用トークンが、前記ブラインド化ナンスおよび前記ブラインド化ナンスの前記ブラインド署名を含む、生成するステップを含む、請求項7に記載の方法。
9. 償還のための所与の信用トークンを含む償還要求を前記クライアントデバイスから受信するステップであって、前記所与の信用トークンが、非ブラインド化ナンス、および前記ナンスのブラインド化バージョンに基づいて生成されたブラインド署名を含む、受信するステップと、
   前記非ブラインド化ナンスおよび前記ブラインド署名方式を使用して、前記所与の信用トークンの前記ブラインド署名を検証するステップと、
   前記ブラインド署名の前記検証に応じて、前記所与の信用トークンに対する署名された償還記録を前記クライアントデバイスに送るステップと
   をさらに含む、請求項8に記載の方法。
10. 前記要求が、前記クライアントデバイスに対する公開鍵をさらに含み、前記方法が、前記クライアントデバイスに対する前記公開鍵を使用して、前記1つまたは複数の信用トークンの各々を暗号化するステップをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに前記提供するステップが、前記1つまたは複数の暗号化された信用トークンを前記クライアントデバイスに提供するステップを含む、請求項1から9のいずれか一項に記載の方法。
11. 前記要求が、前記クライアントデバイスに対するデバイス識別子を含み、前記方法が、前記デバイス識別子を使用して、前記クライアントデバイスに対する信用性の履歴記録を保持するステップをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定するステップが、前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定するステップを含む、請求項1から10のいずれか一項に記載の方法。
12. 前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると前記判定するステップが、前記デバイスレベルの不正検出信号、前記クライアントデバイスに対する信用性の前記履歴記録、および所与の時間期間中に前記クライアントデバイスによって要求された信用トークンの数の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定するステップを含む、請求項11に記載の方法。
13. システムであって、
    1つまたは複数のプロセッサと、
    命令を記憶した、1つまたは複数の記憶デバイスと
    を備え、前記命令が、前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、請求項1から12のいずれか一項に記載の方法を実行させる、
    システム。
14. 前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、請求項1から12のいずれか一項に記載の方法を実行させる命令を担持する、コンピュータ可読媒体。
15. システムであって、
    1つまたは複数のプロセッサと、
    命令を記憶した、1つまたは複数のコンピュータ可読媒体と
    を備え、前記命令が、前記1つまたは複数のプロセッサによって実行されたとき、前記1つまたは複数のプロセッサに、
    1つまたは複数の信用トークンに対する要求をクライアントデバイスから受信することであって、前記要求が、
    (i)前記クライアントデバイスから取得された1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記要求を開始したアプリケーションのコードを表すデータのうちの少なくとも1つ、および
    前記1つまたは複数の信用トークンの各々に対するそれぞれのナンス
    を含む、受信することと、
    (I)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと、
    前記1つまたは複数の信用トークンを前記クライアントデバイスに発行するとの前記判定に応じて、
    前記信用トークンに対する前記ナンスを使用して、前記1つまたは複数の信用トークンの各々を生成することと、
    前記1つまたは複数の信用トークンを前記クライアントデバイスに提供することと
    を含む動作を実行させる、システム。
16. (i)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、
    前記1つまたは複数のデバイスレベルの不正検出信号に基づいて、前記クライアントデバイスが信用できるデバイスであると判定することと、
    前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定することと、
    前記クライアントデバイスが信用できるデバイスであり、前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと
    を含む、請求項15に記載のシステム。
17. 前記アプリケーションの前記コードを表す前記データが、前記アプリケーションの前記コードの暗号学的ハッシュを含む、請求項15に記載のシステム。
18. 前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、
    前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定することと、
    前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと
    を含む、請求項15に記載のシステム。
19. 前記アプリケーションが信用できるアプリケーションであると前記判定することが、
    前記アプリケーションの前記コードの暗号学的ハッシュを前記アプリケーションの公式ビルドのコードの暗号学的ハッシュと比較することと、
    前記アプリケーションの前記コードの前記暗号学的ハッシュと前記アプリケーションの公式ビルドのコードの暗号学的ハッシュの一致に応じて、前記アプリケーションが信用できるアプリケーションであると判定することと
    を含む、請求項18に記載のシステム。
20. 前記アプリケーションが信用できるアプリケーションであると前記判定することが、前記アプリケーションが悪意のあるアプリケーション論理を含まないことを示す証明書が前記アプリケーションに対して発行されていると判定することを含む、請求項18に記載のシステム。
21. 各信用トークンに対する前記ナンスが、ブラインド署名方式を使用してブラインド化されたブラインド化ナンスである、請求項15に記載のシステム。
22. 前記1つまたは複数の信用トークンの各々を前記生成することが、ブラインド署名方式を使用して、前記信用トークンに対する前記ブラインド化ナンスのブラインド署名を生成することであって、前記信用トークンが、前記ブラインド化ナンスおよび前記ブラインド化ナンスの前記ブラインド署名を含む、生成することを含む、請求項21に記載のシステム。
23. 前記動作が、
    償還のための所与の信用トークンを含む償還要求を前記クライアントデバイスから受信することであって、前記所与の信用トークンが、非ブラインド化ナンス、および前記ナンスのブラインド化バージョンに基づいて生成されたブラインド署名を含む、受信することと、
    前記非ブラインド化ナンスおよび前記ブラインド署名方式を使用して、前記所与の信用トークンの前記ブラインド署名を検証することと、
    前記ブラインド署名の前記検証に応じて、前記所与の信用トークンに対する署名された償還記録を前記クライアントデバイスに送ることと
    をさらに含む、請求項22に記載のシステム。
24. 前記要求が、前記クライアントデバイスに対する公開鍵をさらに含み、前記動作が、前記クライアントデバイスに対する前記公開鍵を使用して、前記1つまたは複数の信用トークンの各々を暗号化することをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに前記提供することが、前記1つまたは複数の暗号化された信用トークンを前記クライアントデバイスに提供することを含む、請求項15に記載のシステム。
25. 前記要求が、前記クライアントデバイスに対するデバイス識別子を含み、前記動作が、前記デバイス識別子を使用して、前記クライアントデバイスに対する信用性の履歴記録を保持することをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定することを含む、請求項15に記載のシステム。
26. 前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると前記判定することが、前記デバイスレベルの不正検出信号、前記クライアントデバイスに対する信用性の前記履歴記録、および所与の時間期間中に前記クライアントデバイスによって要求された信用トークンの数の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定することを含む、請求項15に記載のシステム。
27. 命令を記憶した、1つまたは複数の非一時的コンピュータ可読媒体であって、前記命令が、1つまたは複数のコンピュータによって実行されたとき、前記1つまたは複数のコンピュータに、
    1つまたは複数の信用トークンに対する要求をクライアントデバイスから受信することであって、前記要求が、
    (i)前記クライアントデバイスから取得された1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記要求を開始したアプリケーションのコードを表すデータのうちの少なくとも1つ、および
    前記1つまたは複数の信用トークンの各々に対するそれぞれのナンス
    を含む、受信することと、
    (i)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと、
    前記1つまたは複数の信用トークンを前記クライアントデバイスに発行するとの判定に応じて、
    前記信用トークンに対する前記ナンスを使用して、前記1つまたは複数の信用トークンの各々を生成することと、
    前記1つまたは複数の信用トークンを前記クライアントデバイスに提供することと
    を含む動作を実行させる、1つまたは複数の非一時的コンピュータ可読媒体。
28. (i)前記1つまたは複数のデバイスレベルの不正検出信号、または(ii)前記アプリケーションの前記コードを表す前記データのうちの少なくとも1つに基づいて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、
    前記1つまたは複数のデバイスレベルの不正検出信号に基づいて、前記クライアントデバイスが信用できるデバイスであると判定することと、
    前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定することと、
    前記クライアントデバイスが信用できるデバイスであり、前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと
    を含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
29. 前記アプリケーションの前記コードを表す前記データが、前記アプリケーションの前記コードの暗号学的ハッシュを含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
30. 前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、
    前記アプリケーションの前記コードを表す前記データに基づいて、前記アプリケーションが信用できるアプリケーションであると判定することと、
    前記アプリケーションが信用できるアプリケーションであるとの前記判定に応じて、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると判定することと
    を含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
31. 前記アプリケーションが信用できるデバイスであると前記判定することが、
    前記アプリケーションの前記コードの暗号学的ハッシュを前記アプリケーションの公式ビルドのコードの暗号学的ハッシュと比較することと、
    前記アプリケーションの前記コードの前記暗号学的ハッシュと前記アプリケーションの公式ビルドのコードの暗号学的ハッシュの一致に応じて、前記アプリケーションが信用できるアプリケーションであると判定することと
    を含む、請求項30に記載の1つまたは複数の非一時的コンピュータ可読媒体。
32. 前記アプリケーションが信用できるアプリケーションであると前記判定することが、前記アプリケーションが悪意のあるアプリケーション論理を含まないことを示す証明書が前記アプリケーションに対して発行されていると判定することを含む、請求項30に記載の1つまたは複数の非一時的コンピュータ可読媒体。
33. 各信用トークンに対する前記ナンスが、ブラインド署名方式を使用してブラインド化されたブラインド化ナンスである、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
34. 前記1つまたは複数の信用トークンの各々を前記生成することが、ブラインド署名方式を使用して、前記信用トークンに対する前記ブラインド化ナンスのブラインド署名を生成することであって、前記信用トークンが、前記ブラインド化ナンスおよび前記ブラインド化ナンスの前記ブラインド署名を含む、生成することを含む、請求項33に記載の1つまたは複数の非一時的コンピュータ可読媒体。
35. 前記動作が、
    償還のための所与の信用トークンを含む償還要求を前記クライアントデバイスから受信することであって、前記所与の信用トークンが、非ブラインド化ナンス、および前記ナンスのブラインド化バージョンに基づいて生成されたブラインド署名を含む、受信することと、
    前記非ブラインド化ナンスおよび前記ブラインド署名方式を使用して、前記所与の信用トークンの前記ブラインド署名を検証することと、
    前記ブラインド署名の前記検証に応じて、前記所与の信用トークンに対する署名された償還記録を前記クライアントデバイスに送ることと
    を含む、請求項34に記載の1つまたは複数の非一時的コンピュータ可読媒体。
36. 前記要求が、前記クライアントデバイスに対する公開鍵をさらに含み、前記動作が、前記クライアントデバイスに対する前記公開鍵を使用して、前記1つまたは複数の信用トークンの各々を暗号化することをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに前記提供することが、前記1つまたは複数の暗号化された信用トークンを前記クライアントデバイスに提供することを含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
37. 前記要求が、前記クライアントデバイスに対するデバイス識別子を含み、前記動作が、前記デバイス識別子を使用して、前記クライアントデバイスに対する信用性の履歴記録を保持することをさらに含み、前記1つまたは複数の信用トークンを前記クライアントデバイスに発行すると前記判定することが、前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定することを含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。
38. 前記デバイスレベルの不正検出信号および前記クライアントデバイスに対する信用性の前記履歴記録の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると前記判定するステップが、前記デバイスレベルの不正検出信号、前記クライアントデバイスに対する信用性の前記履歴記録、および所与の時間期間中に前記クライアントデバイスによって要求された信用トークンの数の組合せに基づいて、前記クライアントデバイスが信用できるデバイスであると判定するステップを含む、請求項27に記載の1つまたは複数の非一時的コンピュータ可読媒体。

Images