知財求人 - 知財ポータルサイト「IP Force」
▶ キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニーの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-11-21
(54)【発明の名称】非接触カードを使用する医療状態の安全な検証
(51)【国際特許分類】
G16H 10/00 20180101AFI20231114BHJP
H04L 9/32 20060101ALI20231114BHJP
【ＦＩ】
G16H10/00
H04L9/32 200B
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023526059
(86)(22)【出願日】2021-10-29
(85)【翻訳文提出日】2023-06-26
(86)【国際出願番号】 US2021057215
(87)【国際公開番号】W WO2022094187
(87)【国際公開日】2022-05-05
(31)【優先権主張番号】17/086,029
(32)【優先日】2020-10-30
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ブルートゥース
(71)【出願人】
【識別番号】519111877
【氏名又は名称】キャピタル・ワン・サービシーズ・リミテッド・ライアビリティ・カンパニー
【氏名又は名称原語表記】Ｃａｐｉｔａｌ Ｏｎｅ Ｓｅｒｖｉｃｅｓ， ＬＬＣ
(74)【代理人】
【識別番号】100145403
【弁理士】
【氏名又は名称】山尾 憲人
(74)【代理人】
【識別番号】100135703
【弁理士】
【氏名又は名称】岡部 英隆
(74)【代理人】
【識別番号】100163902
【弁理士】
【氏名又は名称】市川 奈月
(72)【発明者】
【氏名】オズボーン，ケビン
(72)【発明者】
【氏名】ルール，ジェフリー
【テーマコード（参考）】
5L099
【Ｆターム（参考）】
5L099AA21
(57)【要約】
非接触カードを用いた医療状態の検証のシステム、方法、製造品、およびコンピュータ可読媒体。アプリケーションは、対象者および医療状態を示す要求を受信できる。アプリケーションは、非接触カードから暗号を受信する。アプリケーションは、サーバから復号結果を受信し、サーバが暗号を復号したと判定できる。アプリケーションは、非接触カードから、医療証明、医療証明のデジタル署名、およびデジタル署名の公開鍵を受信できる。アプリケーションは、デジタル署名の公開鍵に基づいてデジタル署名を復号化し、復号化されたデジタル署名に基づいて医療証明を検証できる。アプリケーションは、医療証明の検証に基づいて、対象者が医療状態に対する免疫を持っていると判定できる。アプリケーションは、対象者が医療状態に対する免疫がある結果を出力できる。
【特許請求の範囲】
【請求項1】
プロセッサと、メモリとを備えるシステムであって、前記メモリは、前記プロセッサによって実行されると、前記プロセッサに、
アプリケーションによって、対象者および医療状態を示す要求を受信させ、
前記アプリケーションによって、前記対象者の口座に関連付けられた非接触カードから暗号を受信させ、
前記アプリケーションによって、サーバから復号結果を受信させ、
前記アプリケーションによって、前記復号結果に基づいて、前記サーバが暗号を復号化したと判定させ、
前記アプリケーションによって、前記復号結果に応答して、前記非接触カードから、医療証明、医療証明のデジタル署名、および前記デジタル署名の公開鍵を受信させ、
前記アプリケーションによって、前記デジタル署名の前記公開鍵に基づいて、前記デジタル署名を復号化させ、
前記アプリケーションによって、前記復号化されたデジタル署名に基づいて、前記医療証明を検証させ、
前記医療証明の前記検証に基づいて、前記対象者が前記医療状態に対する免疫があることを判定させ、および、
前記アプリケーションによって、前記対象者が前記医療状態に対する免疫があることを示す証明結果を出力させる
命令を記憶する
システム。
【請求項2】
前記メモリは、前記プロセッサによって実行されたとき、前記プロセッサに、前記アプリケーションによって、前記デジタル署名の公開鍵証明を受信させ、および、
前記アプリケーションによって、前記公開鍵証明の第１のデジタル署名を検証させる
命令を記憶する
請求項１に記載のシステム。
【請求項3】
前記公開鍵証明は、前記公開鍵証明を含む複数の公開鍵証明のチェーンを含み、前記メモリは、前記プロセッサによって実行されたときに、前記プロセッサに、
前記アプリケーションによって、少なくとも１つの規定に基づいて、前記複数の公開鍵証明の各デジタル署名を検証させる
命令を記憶する、
請求項２に記載のシステム。
【請求項4】
前記メモリは、前記プロセッサによって実行されたときに、前記プロセッサに、前記アプリケーションによって、前記復号化されたデジタル署名と前記受信した医療証明とを比較させ、
前記アプリケーションによって、前記比較に基づいて、前記復号化されたデジタル署名が前記受信した医療証明と一致すると決定させる、
命令を記憶する
請求項１に記載のシステム。
【請求項5】
前記メモリは、前記プロセッサによって実行されたとき、前記プロセッサに、前記アプリケーションによって、前記医療証明を第１のフォーマットから第２のフォーマットへのデコードを実行させる
命令を記憶する
請求項４に記載のシステム。
【請求項6】
前記医療証明は、（i）前記対象者に割り当てられた顧客識別子と、（ii）前記医療証明の日付と、（iii）前記対象者の前記医療証明と、（iv）前記非接触カードによって生成された第２の暗号と、を含み、前記証明結果は、前記対象者が医療状態に対して免疫があることを特定し、
前記証明結果は、（i）前記対象者の予防接種と、（ii）前記対象者の抗体と、のうちの少なくとも１つに基づいて、前記対象者が前記医療状態に対して免疫があることを特定する、
請求項５に記載のシステム。
【請求項7】
前記メモリは、前記プロセッサによって実行されると、前記プロセッサに、前記アプリケーションによって、前記第２の暗号を前記サーバへ送信させ、
前記アプリケーションによって、前記サーバから、前記第２の暗号の復号結果を受信させ、
前記アプリケーションによって、前記第２の暗号の前記復号結果に基づいて、前記サーバが前記第２の暗号を復号化したと判定させ、
前記アプリケーションによって、さらに、前記サーバが前記第２の暗号を復号化した前記判定に基づいて、前記対象者が前記医療状態に対して免疫があると判定させる
命令を記憶する
請求項６に記載のシステム。
【請求項8】
コンピュータ読み取り可能なプログラムコードを有する非一過性のコンピュータ可読記憶媒体であって、前記コンピュータ読み取り可能なプログラムコードは、プロセッサ回路によって実行可能であり、前記プロセッサ回路に、
アプリケーションによって、対象者および医療状態を示す要求の受信、
前記アプリケーションによって、前記対象者の口座に関連付けられた非接触カードから暗号の受信、
前記アプリケーションによって、サーバから復号結果の受信、
前記アプリケーションによって、前記復号結果に基づいて、前記サーバが暗号を復号化した判定、
前記アプリケーションによって、前記非接触カードから、医療証明、前記医療証明のデジタル署名、および前記デジタル署名の公開鍵の受信、
前記アプリケーションによって、前記デジタル署名の前記公開鍵に基づく、前記デジタル署名の復号化、
前記アプリケーションによって、前記復号化されたデジタル署名に基づく、前記医療証明書の検証、
前記医療証明書の前記検証に基づいて、前記対象者が医療状態に対する免疫があることの判定、および、
前記アプリケーションによって、前記対象者が前記医療状態に対する免疫があることを示す証明結果の出力、
を実行させる、
コンピュータ可読記憶媒体。
【請求項9】
前記プロセッサ回路によって実行可能なコンピュータ読み取り可能なプログラムコードは、前記プロセッサ回路に、前記アプリケーションによって、前記デジタル署名の公開鍵証明の受信、および、
前記アプリケーションによって、前記公開鍵証明の第１のデジタル署名の検証、
を実行させる
請求項８に記載のコンピュータ可読記憶媒体。
【請求項10】
前記公開鍵証明は、複数の公開鍵証明を含む公開鍵証明のチェーンを含み、前記プロセッサ回路によって実行可能なコンピュータ読み取り可能なプログラムコードは、前記プロセッサ回路に、
前記アプリケーションによって、少なくとも１つの規定に基づいて、前記複数の公開鍵証明の各デジタル署名の検証、
を実行させる
請求項９に記載のコンピュータ可読記憶媒体。
【請求項11】
前記プロセッサ回路によって実行可能なコンピュータ読み取り可能なプログラムコードは、前記プロセッサ回路に、前記アプリケーションによって、前記復号化されたデジタル署名と前記受信した医療証明とを比較させ、
前記アプリケーションによって、前記比較に基づいて、前記復号化されたデジタル署名が前記受信した医療証明と一致すると決定させる、
請求項８に記載のコンピュータ可読記憶媒体。
【請求項12】
前記プロセッサ回路によって実行可能なコンピュータ読み取り可能なプログラムコードは、前記プロセッサ回路に、前記アプリケーションによって、前記医療証明を第１のフォーマットから第２のフォーマットにデコードさせる
請求項１１に記載のコンピュータ可読記憶媒体。
【請求項13】
前記医療証明は、（i）前記対象者に割り当てられた顧客識別子と、（ii）前記医療証明の日付と、（iii）前記対象者の前記医療証明と、（iv）前記非接触カードによって生成された第２の暗号と、を含み、前記証明結果は、（i）前記対象者の予防接種と、（ii）前記対象者の抗体と、のうちの少なくとも１つに基づいて、前記対象者が前記医療状態に対して免疫があることを特定する、
請求項１２に記載のコンピュータ可読記憶媒体。
【請求項14】
前記プロセッサ回路によって実行可能なコンピュータ読み取り可能なプログラムコードは、前記プロセッサ回路に、前記アプリケーションによって、前記第２の暗号を前記サーバに送信させ、
前記アプリケーションによって、前記サーバから、前記第２の暗号の復号結果を受信させ、
前記アプリケーションによって、前記第２の暗号の前記復号結果に基づいて、前記サーバが前記第２の暗号を復号化したと判定させ、
前記アプリケーションによって、さらに、前記サーバが前記第２の暗号を復号化した前記判定に基づいて、前記対象者が前記医療状態に対して免疫があると判定させる
命令を記憶する
請求項１３に記載のコンピュータ可読記憶媒体。
【請求項15】
装置で実行されるアプリケーションによって、対象及び医療状態を示す要求を受信し、前記アプリケーションによって、前記対象者の口座に関連付けられる非接触カードから暗号を受信し、
前記アプリケーションによって、サーバから復号結果を受信し、
前記アプリケーションによって、前記復号結果に基づいて、前記サーバが前記暗号を復号化したと判定し、
前記アプリケーションによって、前記非接触カードから、医療証明、前記医療証明のデジタル署名、および前記デジタル署名の公開鍵を受信し、
前記アプリケーションによって、前記デジタル署名の前記公開鍵に基づいて、前記デジタル署名を復号化し、
前記アプリケーションによって、前記復号化されたデジタル署名に基づいた前記医療証明を検証し、
前記医療証明の前記検証に基づいて、前記対象者が前記医療状態に対する免疫があることを判定し、
前記アプリケーションによって、前記対象者が前記医療状態に対して免疫があることを示す証明結果を生成し、および、
前記アプリケーションによって、前記証明結果を受信者デバイスに送信する
ことを含む方法。
【請求項16】
前記アプリケーションによって、複数の公開鍵証明書を含む証明チェーンであって、各公開鍵証明がそれぞれのデジタル署名に関連付けられた証明チェーンを受信し、前記アプリケーションによって、少なくとも１つの規定に基づいて、前記複数の公開鍵証明の各デジタル署名を検証する
請求項１５に記載の方法。
【請求項17】
前記証明の検証は、前記アプリケーションによって、前記復号化されたデジタル署名と前記受信した医療証明とを比較し、および、
前記アプリケーションによって、前記比較に基づいて、前記復号化されたデジタル署名が前記受信した医療証明書と一致すると判定すると決定させる、
ことを含む
請求項１５に記載の方法。
【請求項18】
前記アプリケーションによって、前記医療証明を第１のフォーマットから第２のフォーマットにデコードすることをさらに含む請求項１７に記載の方法。
【請求項19】
前記医療証明は、（i）前記対象者に割り当てられた顧客識別子と、（ii）前記医療証明の日付と、（iii）前記対象者の前記医療証明と、（iv）前記非接触カードによって生成された第２の暗号と、を含み、前記証明結果は、（i）前記対象者の予防接種と、（ii）前記対象者の抗体と、のうちの少なくとも１つに基づいて、前記対象者が前記医療状態に対して免疫があることを特定する、
請求項１８に記載の方法。
【請求項20】
前記アプリケーションによって、前記第２の暗号をサーバに送信させ、前記アプリケーションによって、前記サーバから、前記第２の暗号の復号結果を受信させ、
前記アプリケーションによって、前記第２の暗号の前記復号結果に基づいて、前記サーバが前記第２の暗号を復号したと判定させ、
前記アプリケーションによって、さらに、前記サーバが前記第２の暗号を復号化した前記判定に基づいて、前記対象者が前記医療状態に対して免疫があると判定させる、
請求項１９に記載の方法。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書で開示される実施形態は、一般に非接触カードに関し、より具体的には、非接触カードを使用する医療状態の安全な検証に関する。
【背景技術】
【0002】
多くの場合、人々は予防接種などの医療状態の証明を、要請する団体に提出しなければならない。この要件は、パンデミック時やそれ以降に悪化する。しかし、人々が物理的な書類を携帯することは現実的ではない。さらに、どのような種類の文書であっても、その信憑性を考慮しなければならない。同様に、各人のプライバシーも守られなければならない。従来の解決策では、これらやその他の考慮事項に対処できない。
【発明の概要】
【0003】
本出願は、２０２０年１０月３０日に出願の、タイトル「非接触カードを使用する医療状態の安全な検証」とする米国特許出願番号１７／０８６０２９の優先権を主張する。前述の特許出願の内容は、参照によりその全体が本明細書に援用される。
【0004】
本明細書に開示される実施形態は、非接触カードを使用して医療状態を安全に検証するシステム、方法、製造品、およびコンピュータ可読媒体を提供する。一例では、アプリケーションは、対象者および医療状態を指定する要求を受信できる。アプリケーションは、対象者の口座に関連付けられた非接触カードから暗号を受信できる。アプリケーションは、サーバから復号結果を受信し、サーバが暗号を復号したと判定する。アプリケーションは、復号結果に基づいて非接触カードから、医療証明、医療証明のデジタル署名、およびデジタル署名の公開鍵を受信してもよい。アプリケーションは、デジタル署名の公開鍵に基づいてデジタル署名を復号化し、復号化されたデジタル署名に基づいて医療証明を検証できる。アプリケーションは、医療証明の検証に基づいて、対象者が医療状態に対する免疫があると判定できる。アプリケーションは、対象者が医療状態に対して免疫があることを示す証明結果を出力できる。
【図面の簡単な説明】
【0005】
【発明を実施するための形態】
【0006】
本明細書で開示する実施形態は、非接触カードを使用して医療状態を安全に検証する技術を提供する。一般に、非接触カードは、医療証明を保存できる。医療証明は、予防接種状況、感染状況など、人の任意の健康属性に関連し得る。医療証明は、ワクチンを投与した医療提供者など、認証されたエンティティによって署名され得る。
【0007】
後日、関連する人物は、医学的証明を確認する、例えば、予防接種を受けた証明が必要となることがある。たとえば、その人が公共交通機関を利用しようとすると、公共交通機関の駅にある端末が予防接種の証明を要求することがある。非接触カードを端末にタップすると、非接触カードがデータパッケージを生成し得る。データパッケージには、鍵の多様化を使用して生成された動的暗号が含まれ得る。端末は、暗号を認証サーバに送信し、鍵の多様化を使用して復号化し得る。認証サーバが暗号を復号化できる場合、認証サーバは一般に、その人物の身元を確認し、検証し得る。認証サーバは、暗号が復号されたか、および／または人物の身元が検証されたかなど、復号結果を端末に送信し得る。
【0008】
復号結果が認証サーバが暗号を復号化したことを示す場合、アプリケーションは、医療証明、医療証明のデジタル署名、およびデジタル署名の公開鍵を受信でき、これらは、初期データパッケージおよび／または端末への別のタップに応答して非接触カードによって生成される別のデータパッケージで提供され得る。次に、端末は、デジタル署名の証明チェーンの検証に基づいて、デジタル署名を検証し得る。端末は、公開鍵を使用してデジタル署名を復号し得る。端末は、復号化されたデジタル署名を受信した医療証明と比較し得る。比較の結果、一致した場合（例えば、復号化されたデジタル署名が医療証明と一致した場合）、端末は医療証明を検証できる。その後、端末は、その人物が予防接種を証明したと判定できる。その後、端末は、証明された予防接種の表示を出力し、および／または、他の操作（例えば、公共交通施設への入場を許可するために改札口および／またはドアを開くなどの操作）を実行できる。
【0009】
有利なことに、本明細書で開示される実施形態は、医療証明を安全に証明する技術を提供する。暗号を検証するために鍵の多様化を活用することによって、本開示の実施形態は、カード所有者の身元を安全に検証できる。暗号、デジタル署名確認、および証明確認を活用することにより、ここに開示される実施形態は、非接触カードに格納された医療証明を安全に検証できる。これらの技術を組み合わせることにより、より正確かつ安全でスケーラブルな医療証明の検証を提供できる。さらに、本明細書で開示する実施形態は、機密情報の露出を制限することにより、データプライバシーおよび／または個人プライバシーを保持できる。
【0010】
本明細書で使用される表記および命名法を一般的に参照すると、以下に続く詳細な説明の１つ以上の部分は、コンピュータまたはコンピュータのネットワーク上で実行されるプログラム手順の表現で提示され得る。このような手順の記述および表現は、当業者が自分の仕事の実態を他の当業者に最も効果的に伝えるために使用する。手順とは、ここでは、そして一般的には、所望の結果を導く自己矛盾のない一連の操作であると考えられている。これらの操作は、物理量の物理的操作を必要とするものである。必ずしもそうである必要はないが、通常、これらの量は、記憶、転送、結合、比較、その他の操作が可能な電気信号、磁気信号、光学信号の形をとる。このような信号をビット、値、要素、記号、文字、用語、数字などと呼ぶのは、主に一般的な用法から便利な場合がある。しかし、これらや類似の用語はすべて、適切な物理量と関連付けられるべきものであり、それらの量に適用される便利なラベルに過ぎないことに注意すべきである。
【0011】
さらに、これらの操作は、しばしば、人間のオペレータによって実行される精神的操作に一般的に関連付けられる、加算または比較などの用語で言及される。しかしながら、１つ以上の実施形態の一部を形成する本明細書で記載の操作のいずれにおいても、人間のオペレータのそのような能力は必要ではなく、ほとんどの場合において望ましいものではない。むしろ、これらの操作は機械操作である。様々な実施形態の操作を実行する有用な機械は、ここでの教示に従って記述された内部に格納されたコンピュータプログラムによって選択的に起動または構成されるデジタルコンピュータを含み、および／または必要な目的のために特別に構築された装置またはデジタルコンピュータを含む。様々な実施形態はまた、これらの操作を実行する装置またはシステムに関する。これらの装置は、必要な目的のために特別に構築されてもよい。これらの様々な機械に必要な構造は、与えられた説明から明らかであろう。
【0012】
次に、図面を参照し、図面では、全体を通して同様の要素を参照するために同様の参照数字が使用されている。以下の説明では、説明のために、その完全な理解を提供するために、多数の具体的な詳細を記載する。しかしながら、新規な実施形態は、これらの具体的な詳細がなくても実施可能であることは明らかであろう。他の例では、その説明を容易にするために、周知の構造および装置をブロック図の形態で示す。その意図は、特許請求の範囲内のすべての変更、等価物、および代替物をカバーすることである。
【0013】
図１Ａは、本開示の実施形態のシステム１００の一例を示す。図１Ａ～１Ｂに示されるシステム１００は、特定のトポロジーにおいて限定された数の要素を有するが、システム１００は、所与の実装のために所望されるように、代替のトポロジーにおいてより多くのまたはより少ない要素を含み得ることが理解され得る。
【0014】
図示するように、システム１００は、１つ以上のコンピュ－ティング装置１０２、１つ以上の非接触カード１０４、および１つ以上の認証サーバ１０６を備える。非接触カード１０４は、クレジットカード、デビットカード、ATMカード、ギフトカードなど、あらゆる種類の支払カードの代表である。非接触カード１０４は、NFC、EMV規格、または無線通信における他の短距離プロトコルを介してコンピュ－ティング装置１０２の通信インタフェース１２８と通信する無線周波数識別（RFID）チップなどの１つ以上の通信インタフェース１２６を含むことができる。NFCは通信プロトコルの一例として使用されているが、本開示は、EMV規格、Bluetooth（登録商標）、および／またはWi-Fi（登録商標）などの他の種類の無線通信にも同様に適用可能である。コンピュ－ティング装置１０２は、スマートフォン、タブレットコンピュータ、ウェアラブルデバイス、ラップトップ、ポータブルゲームデバイス、仮想化コンピューティングシステム、加盟店端末、POSシステム、サーバ、デスクトップコンピュータなど、任意の数および種類のコンピューティング装置を代表する。コンピュ－ティング装置１０２は、オペレーティングシステム（OS）（図示せず）によって制御されてもよい。オペレーティングシステムの例としては、Android（登録商標）OS、iOS（登録商標）、macOS（登録商標）、Linux（登録商標）、およびWindows（登録商標）オペレーティングシステムが挙げられる。
【0015】
サーバ１０６は、サーバ、ワークステーション、計算クラスタ、クラウドコンピューティングプラットフォーム、仮想化コンピューティングシステムなど、任意の種類のコンピューティング装置の代表である。明確にするために省略するが、コンピュ－ティング装置１０２、非接触カード１０４、およびサーバ１０６はそれぞれ、プログラムおよび／または命令を実行する少なくとも１つのプロセッサ回路を含む。
【0016】
図示されているように、非接触カード１０４のメモリ１０８は、アプレット１１０、カウンタ１１２、マスター鍵１１４、多様化鍵１１６、および一意の顧客識別子（ＩＤ）１１８を含む。アプレット１１０は、本明細書で説明する動作を実行する実行可能コードである。カウンタ１１２、マスター鍵１１４、多様化鍵１１６、及び顧客ＩＤ１１８は、以下でより詳細に説明されるように、システム１００におけるセキュリティの提供に使用される。
【0017】
コンピュ－ティング装置１０２のメモリ１２０は、クライアントアプリケーション１２２および証明１２４を含む。証明１２４は、任意の種類の健康関連データ、例えば、予防接種記録、ワクチン接種記録、健康履歴、疾病履歴、感染履歴、病原体履歴などの代表的である。より一般的には、証明１２４は、医療保険の相互運用性と説明責任に関する法律（HIPAA：Health Insurance Portability and Accountability Act）に基づく保護された健康情報（protected health information （PHI））の任意の種類を含むことができ、保護された健康情報PHIは、診断または治療などのヘルスケアサービスを提供する過程で作成、使用、または開示される。一例では、証明１２４は、SARS-CoV-2ウイルスによって引き起こされるCOVID-19疾患に関連し、例えば、人がワクチン接種を受けたためウイルスに対する免疫を持っているかどうか、以前の感染および血流中の抗体の存在に基づいて免疫を持っているかどうか、および／またはワクチン接種の欠如および／または以前の感染に基づいて免疫を持っていないかどうかである。
【0018】
証明１２４は、クライアントアプリケーション１２２によって生成されてもよいし、異なるソースからクライアントアプリケーション１２２に提供されてもよい。クライアントアプリケーション１２２は、本明細書で説明する手法を実行する任意の種類のアプリケーションであってよい。少なくとも１つの実施形態では、クライアントアプリケーション１２２は、非接触カード１０４に関連する金融機関によって提供され、および／または、本明細書で説明する手法を実行する、金融機関によって提供されるロジック（たとえば、ソフトウェア開発キット（SDK）、APIなど）を含む。例えば、医療記録システムは、本明細書で説明する暗号技術および他の技術を容易にするSDKを含むことができる。
【0019】
証明１２４は、単語、フレーズ、英数字コードなど、任意の適切な形式をとることができる。例えば、医療保健専門家は、クライアントアプリケーション１２２を介して、証明１２４の関連データを入力できる。そのような例では、医師および／または他の医療専門家は、患者にCOVID-19ワクチンを投与できる。その後、医師は、クライアントアプリケーション１２２を使用して、患者のための証明１２４を生成できる。一実施形態では、証明１２４は、証明の日付（例えば、ワクチンの接種日）、関連する保護された健康情報PHIの表示（例えば、ワクチンに対応する英数字のコード、ワクチン接種を受けたことを示すフレーズなど）、および非接触カード１０４から受信した顧客ＩＤ１１８を含む。以下により詳細に述べるように、ある実施形態では、証明１２４は、非接触カード１０４によって生成された暗号（例えば、暗号化された顧客ＩＤ１３０）を含んでもよい。
【0020】
一般に、証明１２４を非接触カード１０４に生成および／または格納するために、システム１００は、ユーザの身元を認証および／または検証する。ユーザの身元を認証するために、本明細書で開示する実施形態は、非接触カード１０４を活用できる。より具体的には、ユーザが証明１２４を非接触カード１０４に格納するよう要求すると、クライアントアプリケーション１２２は、非接触カード１０４を装置１０２にタップするようユーザに指示する通知を出力できる。一般に、非接触カード１０４が装置１０２の通信インタフェース１２８の通信範囲内に持ち込まれると、非接触カード１０４のアプレット１１０は、証明１２４を非接触カードに格納するために必要な認証プロセスの一部として、暗号化された顧客ＩＤ１３０、たとえば暗号を生成できる。非接触カード１０４と装置１０２との間のNFCデータ転送を可能にするために、クライアントアプリケーション１２２は、非接触カード１０４が装置１０２の通信インタフェース１２８に十分に近づいたときに、非接触カード１０４と通信できる。
【0021】
前述のとおり、システム１００は、データを保護するために鍵の多様化を実施し、本明細書では鍵の多様化方法と呼ぶことがある。一般に、サーバ１０６（または他のコンピューティング装置）および非接触カード１０４は、同じマスター鍵１１４（マスター対称鍵とも呼ばれる）で準備されてもよい。より具体的には、各非接触カード１０４は、サーバ１０６に対応するペアを有する別個のマスター鍵１１４でプログラムされる。例えば、非接触カード１０４が製造されるとき、一意のマスター鍵１１４が非接触カード１０４のメモリ１０８にプログラムされてもよい。同様に、一意のマスター鍵１１４は、サーバ１０６の口座データ１３８内の非接触カード１０４に関連する顧客の記録（および／または、ハードウェアセキュリティモジュール（HSM）１４０などの別の安全な場所）に格納されてもよい。マスター鍵１１４は、非接触カード１０４およびサーバ１０６以外のすべての関係者から秘密にでき、それによってシステム１００のセキュリティを強化できる。幾つかの実施形態では、非接触カード１０４のアプレット１１０は、マスター鍵１１４およびデータを入力として暗号アルゴリズムを使用して、データ(例えば、顧客ＩＤ１１８)を暗号化および／または復号化できる。例えば、顧客ＩＤ１１８をマスター鍵１１４で暗号化すると、暗号化された顧客ＩＤ１３０が得られる。同様に、認証サーバ１０６は、対応するマスター鍵１１４を使用して、非接触カード１０４に関連するデータを暗号化および／または復号化できる。
【0022】
他の実施形態では、非接触カード１０４とサーバ１０６のマスター鍵１１４をカウンタ１１２と併用し、キーの多様化を用いてセキュリティを強化できる。カウンタ１１２は、非接触カード１０４とサーバ１０６の間で同期される値を含む。カウンタ値１１２は、非接触カード１０４とサーバ１０６（および／または非接触カード１０４と装置１０２）との間でデータが交換されるたびに変化する数値を含みうる。（例えば、サーバ１０６および／または装置１０２へ）データを送信する準備をするとき、非接触カード１０４はカウンタ値１１２をインクリメントしてもよい。その後、非接触カード１０４は、マスター鍵１１４とカウンタ値１１２を入力として暗号アルゴリズムに提供しうる。暗号アルゴリズムは、出力として多様化鍵１１６を生成する。暗号アルゴリズムは、暗号化アルゴリズム、ハッシュベースメッセージ認証コード(HMAC)アルゴリズム、暗号ベースメッセージ認証コード(CMAC)アルゴリズムなどを含み得る。暗号アルゴリズムの非限定的な例は、3DESやAES128などの対称暗号化アルゴリズム、HMAC-SHA-256などの対称HMACアルゴリズム、AES-CMACなどの対称CMACアルゴリズムなどを含み得る。鍵多様化技術の例は、２０１８年１１月２９日に出願された米国特許出願１６／２０５１１９号明細書にさらに詳細に記載されている。前述の特許出願は、参照によりその全体が本明細書に援用される。
【0023】
鍵の多様化の例を続けると、非接触カード１０４は、多様化鍵１１６および暗号アルゴリズムへの入力としてのデータを使用して、データ(例えば、顧客ＩＤ１１８および／または任意の他のデータ)を暗号化できる。例えば、多様化鍵１１６で顧客ＩＤ１１８を暗号化すると、暗号化された顧客ＩＤ１３０が得られる。
【0024】
使用される暗号化技術にかかわらず、非接触カード１０４は、暗号化されたデータ（例えば、暗号化された顧客ＩＤ１３０）を装置１０２のクライアントアプリケーション１２２（例えば、NFC接続、ブルートゥース接続など）に送信することができる。次に、装置１０２のクライアントアプリケーション１２２は、暗号化された顧客ＩＤ１３０をネットワーク１３２を介してサーバ１０６に送信できる。少なくとも１つの実施形態では、非接触カード１０４は、暗号化されたデータとともにカウンタ値１１２を送信する。このような実施形態では、非接触カード１０４は、暗号化されたカウンタ値１１２を送信してもよいし、暗号化されていないカウンタ値１１２を送信してもよい。
【0025】
受信すると、認証アプリケーション１３４は、暗号化された顧客ＩＤ１３０を認証できる。たとえば、認証アプリケーション１３４は、認証サーバ１０６のメモリ１３６に格納されたマスター鍵１１４のコピーを使用して、暗号化された顧客ＩＤ１３０の復号化を試みることができる。別の例では、認証アプリケーション１３４は、マスター鍵１１４およびカウンタ値１１２を暗号アルゴリズムに入力として提供できる。結果として得られる多様化鍵１１６は、非接触カード１０４の多様化鍵１１６に対応する可能性があり、暗号化された顧客ＩＤ１３０を復号するために使用される可能性がある。
【0026】
使用される復号化方法にかかわらず、認証アプリケーション１３４は、暗号化された顧客ＩＤ１３０の復号化に成功し、それによって暗号化された顧客ＩＤ１３０を検証できる(例えば、結果の顧客ＩＤ１１８を口座データ１３８に格納された顧客ＩＤと比較することによって、および／または、鍵１１４および／または１１６を使用する復号化が成功した表示に基づき)。鍵１１４、１１６はメモリ１３６に格納されているように描かれているが、鍵１１４、１１６は、セキュアエレメントおよび／またはＨＳＭ１４０など、他の場所に格納されてもよい。このような実施形態では、セキュアエレメントおよび／またはＨＳＭ１４０は、鍵１１４および／または１１６と暗号化関数とを使用して、暗号化された顧客ＩＤ１３０を復号化しうる。同様に、セキュアエレメント及び/又はＨＳＭ１４０は、上述のように、マスター鍵１１４及びカウンタ値１１２に基づいて多様化鍵１１６を生成してもよい。
【0027】
しかし、認証アプリケーション１３４が暗号化された顧客ＩＤ１３０を復号化して期待される結果(たとえば、非接触カード１０４に関連する口座の顧客ＩＤ１１８)を得ることができない場合、認証アプリケーション１３４は暗号化された顧客ＩＤ１３０を検証しない。このような例では、認証アプリケーション１３４は、検証に失敗した旨の表示をクライアントアプリケーション１２２に送信する。このように、クライアントアプリケーション１２２は、証明１２４のセキュリティを保持するために、要求された証明１２４の保存の実行を拒否できる。
【0028】
図１Ｂは、認証アプリケーション１３４が暗号化された顧客ＩＤ１３０の復号化に成功し、暗号、およびそれに関連するユーザの身元を検証(または認証)した実施形態を示す。図示するように、認証アプリケーション１３４は復号結果１４４を装置１０２に送信し、復号結果１４４は、認証アプリケーション１３４が暗号化された顧客ＩＤ１３０の復号に成功したことを示す。復号結果１４４の受信に応答して、クライアントアプリケーション１２２は、認証アプリケーション１３４が暗号化された顧客ＩＤ１３０の復号化に成功したと判定できる。この判定に基づき、クライアントアプリケーション１２２は、医療証明１２４をカード１０４に格納するプロセスに進むことを決定できる。
【0029】
セキュリティとプライバシーを向上させるために、クライアントアプリケーション１２２は、秘密鍵(図示せず)を使用して、証明１２４のデジタル署名１４２を計算できる。一般に、証明１２４と秘密鍵は、デジタル署名１４２を計算するアルゴリズムへの入力として提供される。公開鍵１４６は秘密鍵に対応し、デジタル署名１４２を復号するために使用される。
【0030】
したがって、前の例に引き続き、証明１２４は、ワクチンが患者に投与された日付、関連する保護された健康情報PHIの表示(例えば、ワクチンに対応する英数字コード、ワクチン接種を受けたことを示すフレーズなど)、非接触カード１０４から受信した顧客ＩＤ１１８を含むことができる。したがって、デジタル署名１４２は、日付、保護された健康情報PHI、顧客ＩＤ１１８の署名を含むことができる。前述のように、いくつかの実施形態では、証明１２４は暗号化された顧客ＩＤ１３０を含む。そのような実施形態では、デジタル署名１４２は、暗号化された顧客ＩＤ１３０の署名をさらに含む。
【0031】
図示するように、クライアントアプリケーション１２２は、次に非接触カード１０４を装置１０２にタップするようユーザに指示できる。これにより、クライアントアプリケーション１２２は、証明１２４、デジタル署名１４２、および公開鍵１４６を非接触カード１０４に転送する。アプレット１１０は、その後、証明１２４、デジタル署名１４２、および公開鍵１４６をメモリ１０８に格納してもよい。
【0032】
図２Ａは、開示された実施形態と一致する、システム２００の一例の概略図を示す。図２Ａ～２Ｃに示すシステム２００は、特定のトポロジーにおいて限定された数の要素を有するが、システム２００は、所与の実装のために所望されるように、代替のトポロジーにおいてより多くのまたはより少ない要素を含み得ることが理解され得る。
【0033】
図示するように、システム２００は、コンピュ－ティング装置１０２、非接触カード１０４、およびサーバ１０６を含む。一般に、図２Ａは、非接触カード１０４に格納された医療証明１２４が、ユーザの医療状態を確認するために使用される実施形態を示す。例えば、ユーザは、ワクチン接種などを介して、COVID-19疾患に対する免疫の証明を必要とする場合がある。そのような例では、コンピュ－ティング装置１０２のユーザは、COVID-19に対する免疫を証明するために証明１２４の使用を要求できる。いくつかの実施形態では、ユーザは、非接触カード１０４に関連付けられた口座（例えば、口座データ１３８に反映されている口座）にアクセスするために、クライアントアプリケーション１２２に認証資格情報を提供できる。たとえば、認証資格情報には、ユーザ名（またはログイン）とパスワード、生体認証資格情報（例えば、指紋、フェースＩＤなど）などが含まれる。
【0034】
次に、クライアントアプリケーション１２２は、非接触カード１０４をコンピュ－ティング装置１０２にタップするようユーザに指示できる。そうすることにより、非接触カード１０４のアプレット１１０は、上述のように生成された顧客ＩＤ１１８および多様化鍵１１６に基づいて、暗号化された顧客ＩＤ２０２を生成する。アプレット１１０は、次に、暗号化された顧客ＩＤ２０２を、例えばNFCを介して装置１０２に送信できる。受信されると、クライアントアプリケーション１２２は、暗号化された顧客ＩＤ２０２を認証アプリケーション１３４に送信してもよい。
【0035】
受信されると、認証アプリケーション１３４は暗号化された顧客ＩＤ２０２を認証できる。たとえば、認証アプリケーション１３４は、マスター鍵１１４とインクリメントされたカウンタ値１１２を、多様化鍵１１６を出力として生成する暗号アルゴリズムへの入力として提供することにより、暗号化された顧客ＩＤ２０２の復号化を試みることができる。結果として得られる多様化鍵１１６は、暗号化されたID２０２を作成するために非接触カード１０４によって生成された多様化鍵１１６のインスタンスに対応する場合があり、暗号化された顧客ＩＤ２０２を復号化するために使用され得る。一般に、認証アプリケーション１３４は、復号化が成功したか失敗したかを示す復号結果をクライアントアプリケーション１２２に送信してもよい。
【0036】
図２Ｂは、認証アプリケーション１３４が暗号化された顧客ＩＤ２０２の復号化に成功した実施形態を示す。これに応答して、認証アプリケーション１３４は、暗号化された顧客ＩＤ２０２が復号化されたことを示す復号結果２０４をコンピュ－ティング装置１０２に送信する。復号結果２０４に基づいて、クライアントアプリケーション１２２は、暗号化された顧客ＩＤ２０２が復号されたと判定する。クライアントアプリケーション１２２が、復号化が成功しなかったと判定した場合、クライアントアプリケーション１２２は、証明１２４の不正な暴露を防ぐために、それ以上の操作を制限できる。
【0037】
図２Ｃは、クライアントアプリケーション１２２が非接触カード１０４を装置１０２にタップするようユーザに指示する実施形態を示す。これにより、アプレット１１０は、証明１２４、証明１２４のデジタル署名１４２、およびデジタル署名１４２の公開鍵１４６を装置１０２に送信する。デバイスへのカードの別々のタップに基づいて送信されるように描かれているが、いくつかの実施形態では、暗号化された顧客ＩＤ２０２、証明１２４、デジタル署名１４２、および公開鍵１４６は、デバイスへのカードの１回のタップを介してクライアントアプリケーション１２２に送信されてもよい。このような実施形態では、クライアントアプリケーション１２２は、これらの要素を解析して、本明細書で説明する機能を実行する。
【0038】
いくつかの実施形態において、アプレット１１０は、例えば、ユーザおよび／または医療証明１２４の基礎となる保護された健康情報PHIを個人的に特定し得るいかなる情報も公開することなく、医療証明１２４のゼロ知識証明を提供し得る。より一般的には、アプレット１１０および／またはクライアントアプリケーション１２２は、証明１２４、デジタル署名１４２、および／または公開鍵１４６を処理する１つ以上の規則を含む適合のプロトコルを含むことができる。たとえば、アプレット１１０および／またはクライアントアプリケーション１２２の規則は、デジタル署名１４２および／または公開鍵１４６の証明チェーンの検証を要求できる。一般に、証明１２４がカードに格納されるとき、公開鍵１４６および／またはデジタル署名１４２は、証明１２４に署名するエンティティの証明（例えば、医療機関、非接触カード１０４の発行者、政府機関など）に関連付けられ得る。証明は、対応する公開鍵を使用してアプレット１１０および／またはクライアントアプリケーション１２２によって復号化または検証され得る１つ以上の暗号要素（例えば、デジタル署名）を含み得る。
【0039】
複数のエンティティが証明１２４に署名する場合、各エンティティは関連する証明を持ちうる。そのような実施形態では、これらの証明はリンクして証明チェーンを形成し、チェーン内の各証明のデジタル署名は、アプレット１１０および／またはクライアントアプリケーション１２２によって検証（たとえば、対応する公開鍵を使用して復号）されてもよい。各証明が検証されない場合、アプレット１１０および／またはクライアントアプリケーション１２２は、医療証明１２４の公開を控えてもよい。いくつかの実施形態では、証明は、非接触カードおよび／またはクライアントアプリケーション１２２によって格納されてもよい。他の実施形態では、クライアントアプリケーション１２２は、ネットワーク１３２を介して認証局（図示せず）から証明を受信してもよい。
【0040】
別の例では、アプレット１１０および／またはクライアントアプリケーション１２２の１つ以上の規則が、少なくとも１つの既知の（または予め定義された）エンティティが証明１２４に署名することを要求する場合がある。たとえば、規則は、政府機関、非接触カード１０４に関連する金融機関、病院、研究所、または他のエンティティのうちの１つ以上が証明に署名していることを要求できる。証明チェーンが、少なくとも１つの既知のエンティティが証明に署名したことを示さない場合、および／または関連する証明が検証されない場合、アプレット１１０および／またはクライアントアプリケーション１２２は、医療証明１２４の公開を控えることができる。
【0041】
図２Ｃに示すように、すべてのルールが満たされ、クライアントアプリケーション１２２は非接触カード１０４から証明１２４、デジタル署名１４２、公開鍵１４６を受信する。前述のように、いくつかの実施形態では、証明１２４は暗号（例えば、暗号化された顧客ＩＤ１３０）を含みうる。そのような実施形態では、クライアントアプリケーション１２２の規則は、医療証明１２４を公開する前に、この暗号の検証を要求できる。そのような実施形態では、クライアントアプリケーション１２２は、暗号化された顧客ＩＤ１３０を抽出し、検証のために暗号化された顧客ＩＤ１３０をサーバ１０６に送信してもよい。暗号化された顧客ＩＤ１３０を生成するために使用された多様化鍵は、最新のカウンタ値１１２を使用して再び生成されないため、サーバ１０６は、暗号化された顧客ＩＤ１３０の初期インスタンスを復号化するために使用された多様化鍵１１６を保存できる。追加的および／または代替的に、証明１２４は、暗号化された顧客ＩＤ１３０を生成した多様化鍵１１６を生成するために使用されたカウンタ値１１２を含むことができ、クライアントアプリケーション１２２は、暗号化された顧客ＩＤ１３０と共にこのカウンタ値１１２をサーバ１０６に送信できる。そうすることで、サーバ１０６はその後、多様化鍵１１６を使用して、医療証明１２４に含まれる暗号化された顧客ＩＤ１３０を復号化できる。その後、サーバ１０６は、復号結果をクライアントアプリケーション１２２に送信できる。暗号化された顧客ＩＤ１３０の復号化が成功しなかった場合、クライアントアプリケーション１２２は、医療証明１２４の公開を控えることができる。暗号化された顧客ＩＤ１３０の復号化が成功した場合、クライアントアプリケーション１２２は処理を継続してもよい。
【0042】
証明１２４の暗号化された顧客ＩＤ１３０のオプションの復号化を含むすべての規則が満たされた場合、クライアントアプリケーション１２２はデジタル署名１４２を復号化できる。次に、クライアントアプリケーション１２２は、デジタル署名１４２を証明１２４と比較できる。比較の結果、一致した場合、クライアントアプリケーション１２２は、医療証明１２４を検証できる。デジタル署名１４２は各データ要素を暗号的に結合するため、証明１２４は復号化されたデジタル署名１４２と一致するように変更されていない必要がある。証明１２４が何らかの方法で改ざんまたは変更されている場合、復号化されたデジタル署名１４２との比較は失敗する可能性がある。証明１２４が変更されていない場合、復号化されたデジタル署名１４２との比較はパスする可能性があり、クライアントアプリケーション１２２は証明１２４を検証する。
【0043】
一致をもたらす比較に基づいてクライアントアプリケーション１２２が証明を検証する場合、クライアントアプリケーション１２２は証明結果を生成できる。証明結果は、一般に、医療証明１２４、例えば、ユーザがCOVID-19に対して免疫があること及び/又は免疫でないこと、又は任意の他の医学的状態を反映できる。いくつかの実施形態では、クライアントアプリケーション１２２は、証明結果および／または証明１２４を装置１０２のディスプレイ上に出力する。追加的および／または代替的に、クライアントアプリケーション１２２は、証明１２４および／または証明結果を、例えば電子メール、テキスト・メッセージ、プッシュ通知などを介して、別のコンピュ－ティング装置１０２に送信してもよい。いくつかの実施形態では、装置１０２は、NFCを使用して他のカード読み取りデバイスと通信できるモバイルデバイスである。そのような例では、クライアントアプリケーション１２２は、NFCを介して他の装置１０２によって読み取ることができる証明１２４および／または証明結果を含むNDEFファイルを生成できる。
【0044】
例えば、公共交通機関が複数の端末、販売時点情報管理装置、または他のコンピュ－ティング装置１０２を含むコンピュ－ティング装置１０２を含む場合、ユーザは公共交通機関を利用するためにCOVID-19からの免責を証明する必要があるかもしれない。このような実施形態では、ユーザは非接触カード１０４を端末に直接タップできる。その後、端末は、暗号化された顧客ＩＤ２０２および／または１３０を検証し、非接触カード１０４に格納された証明１２４を検証するために（証明の検証、デジタル署名１４２の復号化、および比較を含む）、本明細書で説明する操作を実行してもよい。他の例では、端末は、医療証明１２４を要求するために、ユーザのコンピュ－ティング装置１０２(例えば、スマートフォン)と通信してもよい。このような実施形態では、ユーザの装置１０２は上述のように動作し、証明結果を端末に送信する。
【0045】
証明結果を受信すると、装置１０２はそれに応答して１つ以上の操作を実行できる。例えば、証明結果が、人が最近（例えば、予め定義された日数以内）にCOVID-19と診断されたことを示す場合、装置１０２は、ドアの施錠、改札口の施錠、警報の開始などによって、公共交通システム、公共の場所、私的な場所などへのアクセスを制限してもよい。同様に、証明結果が、その人がCOVID-19に対する免疫を持っていること、および／または、健康であることを示す場合、装置１０２は、ドア、改札口などのロックを解除することによって、公共交通機関または他の場所へのアクセスを許可できる。同様に、クライアントアプリケーション１２２は、医療証明１２４を公開する判定に応じて、これらの操作および／または他の操作を実行および／または開始できる。
【0046】
いくつかの実施形態では、クライアントアプリケーション１２２は復号化されたデジタル署名１４２および／または証明１２４を復号化してもよい。前述のように、いくつかの実施形態では、異なる符号化スキームが、医療証明１２４を符号化するために使用され得る。したがって、そのような実施形態では、クライアントアプリケーション１２２は、適切な比較（例えば、エンコードされたデータとエンコードされたデータを比較、および／またはデコードされたデータとデコードされたデータを比較）が行われていることを保証する。同様に、クライアントアプリケーション１２２は、医療証明１２４を復号化および／または符号化して、ユーザによって読み取り可能な出力を提供してもよい(例えば、英数字の文字列を、COVID-19に対する免疫のような特定の医療状態を伝える単語やフレーズに変換する)。
【0047】
図３Ａは、モバイルコンピュ－ティング装置１０２－１の一例を示す概略図３００ａである。図示されているように、クライアントアプリケーション１２２は、ユーザがCOVID-19に対する免疫があることを証明するために、非接触カード１０４をタップすることを示す通知を装置１０２に出力する。一実施形態では、アプリケーション１２２は、他の装置１０２－２から免疫を証明する要求を受信する。別の実施形態では、アプリケーション１２２は、外部装置からの要求を受信せずに通知を出力する。
【0048】
図示するように、ユーザは非接触カード１０４をコンピュ－ティング装置１０２－１にタップできる。そうすることで、非接触カード１０４のアプレット１１０は、上述のように、顧客ＩＤ１１８および多様化鍵１１６に基づいて暗号（例えば、暗号化された顧客ＩＤ）を生成する。その後、アプレット１１０は、例えばNFCを介して、暗号を装置１０２－１に送信できる。前述のように、いくつかの実施形態では、非接触カード１０４は、証明１２４、デジタル署名１４２、および公開鍵１４６を、暗号とともに装置１０２-1に送信する。受信すると、クライアントアプリケーション１２２は、処理のために暗号を認証アプリケーション１３４に送信できる。
【0049】
受信すると、認証アプリケーション１３４は暗号の検証を試みる。たとえば、認証アプリケーション１３４は、マスター鍵１１４およびインクリメントされたカウンタ値１１２を暗号アルゴリズムに入力として提供することにより、暗号の復号化を試みることができる。結果として得られる多様化鍵１１６は、暗号を作成するために非接触カード１０４によって生成された多様化鍵１１６のインスタンスに対応する場合があり、暗号を復号するために使用される場合がある。一般に、認証アプリケーション１３４は、復号化が成功したか失敗したかを示す復号結果をクライアントアプリケーション１２２に送信できる。
【0050】
図３Ｂは、クライアントアプリケーション１２２が、認証サーバが暗号を復号化したことを示す復号結果を受信する例を示す概略図３００ｂである。これに応答して、クライアントアプリケーション１２２はデジタル署名１４２の復号化を試みる。クライアントアプリケーション１２２が、証明１２４、デジタル署名１４２、および／または公開鍵１４６を受信していない場合、クライアントアプリケーション１２２は、ユーザにカードを装置１０２にタップするよう指示でき、これによりアプレット１１０は、サーバによる暗号の復号化に基づいて、証明１２４、デジタル署名１４２、および／または公開鍵１４６を送信する。
【0051】
クライアントアプリケーション１２２は、デジタル署名１４２の証明チェーンを検証し、デジタル署名１４２を復号化する。クライアントアプリケーション１２２は、復号化されたデジタル署名１４２を証明１２４と比較する。一致する場合、クライアントアプリケーション１２２は、証明１２４に含まれる医療記録を検証する。その後、クライアントアプリケーション１２２は、証明結果を指定する表示、例えば、ユーザがCOVID-19に対して免疫があることを指定する表示を出力できる。前述のように、クライアントアプリケーション１２２は、証明結果の表示を、例えばWi-Fiおよび／またはNFCを介して、要求装置１０２-２に送信してもよい。
【0052】
さらに、クライアントアプリケーション１２２および／または要求装置１０２-２は、証明結果に基づいて、任意の数および／または種類の動作を実行および／または開始できる。例えば、要求が、人がCOVID-19に罹患しているかどうかを判定することを示す場合、クライアントアプリケーション１２２および／または要求装置１０２-２は、検証済み医療証明１２４が、人が予め定義された日数以内にCOVID-19と診断されたことを示すという判定に基づいて、公共の場所、公共交通機関、建物などへのアクセスポイントを閉鎖できる。同様に、検証された医療証明１２４が、人がワクチンを介してCOVID-19に対する免疫を持っていることを示す場合、クライアントアプリケーション１２２および／または要求装置１０２-２は、公共の場所、公共交通機関、建物などへのアクセスポイントを開放してもよい。
【0053】
図４Ａは、非接触カード１０４の構成例を示す概略図４００であり、非接触カード１０４の前面または背面にサービスプロバイダインジケータ４０２として表示されるように、サービスプロバイダによって発行されるクレジットカード、デビットカード、またはギフトカードなどの支払カードを含むことができる。いくつかの例では、非接触カード１０４は、支払カードとは関係なく、限定されないが、身分証明を含んでもよい。いくつかの例では、非接触カードは、デュアルインタフェース非接触支払カード、リワードカードなどを含んでもよい。非接触カード１０４は、基材４０８を含むことができ、この基材は、プラスチック、金属、および他の材料を含む単層または１つ以上の積層層を含むことができる。例示的な基材には、ポリ塩化ビニル、ポリ塩化ビニルアセテート、アクリロニトリルブタジエンスチレン、ポリカーボネート、ポリエステル、陽極酸化チタン、パラジウム、金、炭素、紙、および生分解性材料が含まれる。いくつかの例では、非接触カード１０４は、ISO/IEC 7810規格のID-1フォーマットに準拠した物理的特性を有することがあり、非接触カードは、その他の点では、ISO/IEC 14443規格に準拠することがある。しかしながら、本開示による非接触カード１０４は、異なる特性を有してもよく、本開示は、非接触カードが決済カードに実装されることを必要としないことが理解される。
【0054】
非接触カード１０４は、また、カードの前面および／または背面に表示される識別情報４０６と、接触パッド４０４お含むことができる。接触パッド４０４は、１つ以上のパッドを含み、非接触カードを介してATM、ユーザ装置、スマートフォン、ラップトップ、デスクトップ、またはタブレットコンピュータなどの別のクライアント機器との接触を確立するように含んでもよい。接触パッドは、ISO/IEC7816規格などの１つ以上の規格に従って設計され、EMVプロトコルに従って通信を可能にできる。非接触カード１０４は、図４Ｂでさらに説明するように、処理回路、アンテナ、および他の構成要素も含むことができる。これらの構成要素は、接触パッド４０４の後方または基材４０８の他の場所、例えば基材４０８の異なる層内に配置されてもよく、接触パッド４０４と電気的および物理的に結合されてもよい。非接触カード１０４は、磁気ストリップまたはテープも含むことができ、この磁気ストリップまたはテープは、カードの裏面に配置されることができる（図４Ａには図示せず）。非接触カード１０４は、NFCプロトコルを介して通信可能なアンテナと結合された近距離無線通信（NFC）デバイスを含むこともできる。実施形態はこれに限定されない。
【0055】
図示するように、非接触カード１０４の接触パッド４０４は、プロセッサ４１０、メモリ１０８、および１つ以上の通信インタフェース１２６を含む、情報を記憶、処理、および通信する処理回路４１４を含むことができる。処理回路４１４は、プロセッサ、メモリ、エラーおよびパリティ/CRCチェッカ、データエンコーダ、アンチコリジョンアルゴリズム、コントローラ、コマンドデコーダ、セキュリティプリミティブ、および本明細書で説明する機能を実行するために必要な改ざん防止ハードウェアを含む追加のコンポーネントを含んでもよいことが理解される。
【0056】
メモリ１０８は、読み出し専用メモリ、書き込み一回読み出し多重メモリ、または読み出し/書き込みメモリ、例えば、RAM、ROM、およびEEPROMであってよく、非接触カード１０４は、これらのメモリのうちの１つ以上を含んでよい。読み出し専用メモリは、工場出荷時に読み出し専用としてプログラム可能であってもよいし、ワンタイムプログラム可能であってもよい。ワンタイムプログラマブルは、一度書き込んだら何度でも読み出す機会を提供する。書き込み一回読み出し多重メモリは、メモリチップが工場から出荷された後の時点でプログラムできる。一度プログラムされたメモリは、書き直すことはできないが、何度でも読み出すことができる。読み出し／書き込みメモリは、工場出荷後に何度もプログラムされ、再プログラムされる可能性がある。読み出し/書き込みメモリは、工場出荷後に何度も読み出されることもある。場合によっては、メモリ１０８は、データを暗号化するためにプロセッサ４１０によって実行される暗号化アルゴリズムを利用する暗号化メモリであってもよい。
【0057】
メモリ１０８は、１つ以上のアプレット１１０、１つ以上のカウンタ１１２、顧客ＩＤ１１８、および仮想口座番号であってもよい１つ以上の口座番号４１２を記憶してもよい。１つ以上のアプレット１１０は、Java（登録商標）カードアプレットのような、１つ以上の非接触カード上で実行する１つ以上のソフトウェアアプリケーションを含みうる。しかしながら、アプレット１１０はJavaカードアプレットに限定されるものではなく、非接触カードまたは限られたメモリを有する他のデバイス上で動作可能な任意のソフトウェアアプリケーションであってもよいことが理解される。１つ以上のカウンタ１１２は、整数を記憶するのに十分な数値カウンタを含んでもよい。顧客ＩＤ１１８は、非接触カード１０４の使用者に割り当てられた一意の英数字識別子を含み、識別子は、非接触カードの使用者を他の非接触カードの使用者から区別できる。いくつかの例では、顧客ＩＤ１１８は、顧客とその顧客に割り当てられた口座の両方を識別でき、さらに、顧客の口座に関連付けられた非接触カード１０４を識別できる。前述のように、口座番号（複数可）４１２は、非接触カード１０４に関連する数千の一回限りの使用仮想口座番号を含むことができる。
【0058】
前述の例示的な実施形態のプロセッサ４１０およびメモリ要素は、接触パッド４０４を参照して説明されているが、本開示はこれに限定されない。これらの要素は、接触パッド４０４の外部に実装されてもよいし、接触パッド４０４から完全に分離されてもよいし、接触パッド４０４内に配置されたプロセッサ４１０およびメモリ１０８要素に加えて、さらなる要素として実装されてもよいことが理解される。
【0059】
いくつかの例では、非接触カード１０４は、１つ以上のアンテナ４１６を含むことができる。１つ以上のアンテナ４１６は、非接触カード１０４内および接触パッド４０４の処理回路４１４の周囲に配置できる。例えば、１つ以上のアンテナ４１６は、処理回路４１４と一体であってもよく、１つ以上のアンテナ４１６は、外部ブースターコイルと共に使用されてもよい。別の例として、１つ以上のアンテナ４１６は、接触パッド４０４および処理回路４１４の外部にあってもよい。
【0060】
一実施形態では、非接触カード１０４のコイルは、空芯変圧器の二次側として機能してもよい。端末は、電力または振幅変調を切断することによって非接触カード１０４と通信できる。非接触カード１０４は、非接触カード１０４の電力接続のギャップを使用して、端末から送信されたデータを推測してもよく、このデータは、１つ以上のコンデンサを介して機能的に維持されてもよい。非接触カード１０４は、コイルの負荷を切り替えたり、負荷変調を行ったりすることによって、通信を送り返してもよい。負荷変調は、干渉によって端末のコイルで検出されることがある。より一般的には、アンテナ４１６、プロセッサ４１０、および／またはメモリ１０８を使用して、非接触カード１０４は、NFC、ブルートゥース、および／またはWi-Fi通信を介して通信する通信インタフェースを提供する。
【0061】
上記で説明したように、非接触カード１０４は、JavaCardのような限られたメモリを有するスマートカードまたは他のデバイス上で動作可能なソフトウェアプラットフォーム上に構築されてもよく、１つ以上のアプリケーションまたはアプレットが安全に実行されてもよい。アプレット１１０は、様々なモバイルアプリケーションベースのユースケースにおいて多要素認証（MFA）のためのワンタイムパスワード（OTP）を提供するために非接触カードに追加されてもよい。アプレット１１０は、モバイルNFCリーダ(例えば、モバイルデバイスまたはPOS端末の)などのリーダからの近距離データ交換要求などの１つ以上の要求に応答し、NDEFテキストタグとしてエンコードされた暗号化されたセキュアなOTPを含むNDEFメッセージを生成してもよい。
【0062】
NDEF OTPの一例は、NDEFショートレコードレイアウト（SR=1）である。このような例では、１つ以上のアプレット１１０は、OTPをNDEFタイプ４の既知の種類のテキストタグとしてエンコードし得る。いくつかの例では、NDEFメッセージは１つ以上のレコードを含み得る。アプレット１１０は、OTPレコードに加えて、１つ以上の静的タグレコードを追加し得る。
【0063】
いくつかの例では、１つ以上のアプレット１１０は、RFIDタグをエミュレートし得る。RFIDタグは１つ以上の多形タグを含むことができる。いくつかの例では、タグが読み取られるたびに、非接触カード１０４の真正性を示す可能性のある異なる暗号データが提示される。１つ以上のアプレット１１０に基づいて、タグのNFC読み取りが処理され、データがバンキングシステムのサーバなど のサーバに送信され、データがサーバで検証される場合がある。
【0064】
いくつかの例では、非接触カード１０４およびサーバ１０６は、カードが適切に識別されるように、特定のデータを含むことができる。非接触カード１０４は、１つ以上の固有の識別子(図示せず)を含むことができる。読み取り操作が行われるたびに、カウンタ１１２はインクリメントし得る。いくつかの例では、（例えば、コンピュ－ティング装置１０２によって）非接触カード１０４からのデータが読み取られるたびに、カウンタ１１２は検証のためにサーバに送信され、カウンタ１１２がサーバのカウンタと等しい（検証の一環として）か判定する。
【0065】
１つ以上のカウンタ１１２は、リプレイ攻撃を防止してもよい。例えば、暗号が取得され、リプレイされた場合、カウンタ１１２が読み取られたか、使用されたか、または他の方法で引き渡された場合、その暗号は直ちに拒否される。カウンタ１１２が使用されていない場合は、リプレイされる可能性がある。いくつかの例では、カード上でインクリメントされるカウンタは、取引のためにインクリメント されるカウンタとは異なる。非接触カード１０４上のアプレット１１０の間には通信がないので、非接触カード１０４はアプリケーショントランザクションカウンタ１１２を決定できない。いくつかの例では、非接触カード１０４は、トランザクションアプレットであり得る第１のアプレット１１０－１と、非接触カード１０４に格納された１つ以上の医療証明１２４を処理する医療証明アプレットであり得る第２のアプレット１１０－２とを含んでもよい。各アプレット１１０－１および１１０-２は、それぞれのカウンタ１１２を含んでもよい。
【0066】
いくつかの例では、カウンタ１１２は同期しなくてもよい。いくつかの例では、斜め方向からの読み取りなど、トランザクションを開始する偶発的な読み取りを考慮するために、カウンタ１１２はインクリメントするが、アプリケーションはカウンタ１１２を処理しない。いくつかの例では、装置１０２が起動されると、NFCが有効化され、装置１０２は利用可能なタグを読み取ってもよいが、読み取りに対して何のアクションも実行しない。
【0067】
カウンタ１１２の同期を保つために、バックグラウンドアプリケーションのようなアプリケーションを実行し、装置１０２がウェイクアップしたときに検出し、検出により発生した読み取りがカウンタ１１２を前進させることを示すバンキングシステムのサーバと同期してもよい。他の例では、ハッシュドワンタイムパスワードは、同期ずれのウィンドウが受け入れられるように利用されてもよい。例えば、閾値１０以内であれば、カウンタ１１２は進んでもよい。しかし、異なる閾値数以内、例えば１０または１０００以内であれば、再同期を実行する要求が処理されてもよく、この要求は、１つ以上のアプリケーションを介して、ユーザがユーザのデバイスを介して1回または複数回タップ、ジェスチャー、または他の方法で指示することを要求する。カウンタ１１２が適切な順序で増加すれば、ユーザがそうしたことを知ることができる。
【0068】
カウンタ１１２、マスター鍵、および多様化鍵を参照して本明細書で説明する鍵多様化方法は、鍵多様化方法による暗号化および／または復号化の一例である。本開示は他の種類の鍵多様化方法にも同様に適用可能であるため、この例の鍵多様化手法は本開示を限定するものと考えられるべきではない。
【0069】
非接触カード１０４の作成プロセスでは、カードごとに２つの暗号鍵が一意に割り当てられる。暗号鍵は、データの暗号化と復号化の両方で使用され得る対称鍵を含んでもよい。トリプルDES(3DES)アルゴリズムは、EMVで使用され得、非接触カード１０４のハードウェアで実装される。鍵の多様化プロセスを使用することにより、鍵を必要とする各エンティティの一意に識別可能な情報に基づいて、１つ以上の鍵をマスター鍵から導出できる。
【0070】
いくつかの例では、脆弱性の影響を受けやすい3DESアルゴリズムの欠陥を克服するために、セッション鍵が導出されることがあるが（セッションごとに一意のキーなど）、マスター鍵を使用するのではなく、固有のカード導出鍵とカウンタがダイバーシフィケーションデータとして使用されることがある。例えば、非接触カード１０４が動作中に使用されるたびに、メッセージ認証コード（MAC）の作成と暗号化の実行に異なる鍵を使用できる。この結果、暗号の三重化が実現する。セッションキーは、１つ以上のアプレットによって生成され、１つ以上のアルゴリズム（EMV 4.3 Book 2 A1.3.1 Common Session Key Derivivationで定義される）でアプリケーション・トランザクションカウンタを使用して導出される。
【0071】
例えば、奇数番号のカードは２ずつ、偶数番号のカードは5ずつインクリメントされる。例えば、奇数番号のカードは２ずつインクリメントし、偶数番号のカードは５ずつインクリメントできる。いくつかの例では、インクリメントは、１枚のカードが１、３、５、２、２、...の繰り返しで順番にインクリメントするように、順次読み取りで変化することもある。特定のシーケンスまたはアルゴリズムシーケンスは、パーソナライゼーション時に定義されてもよいし、一意の識別子から派生する１つ以上のプロセスから定義されてもよい。これにより、リプレイ攻撃者が少数のカードインスタンスから一般化することを困難にできる。
【0072】
認証メッセージは、１６進ASCII形式のテキストNDEFレコードのコンテンツとして配信される。別の例では、NDEFレコードは１６進数形式でエンコードされる。
【0073】
開示された実施形態の動作は、以下の図を参照してさらに説明され得る。いくつかの図は、論理フローを含む場合がある。本明細書で提示されるそのような図は、特定の論理フローを含むことがあるが、論理フローは、本明細書で説明されるような一般的な機能がどのように実装され得るかの例を提供するに過ぎないことが理解され得る。さらに、所定の論理フローは、特に指示がない限り、必ずしも提示された順序で実行される必要はない。さらに、論理フローに示されたすべての行為が、いくつかの実装において必要とされるとは限らない。さらに、所定の論理フローは、ハードウェア要素、プロセッサによって実行されるソフトウェア要素、またはそれらの任意の組み合わせによって実装されてもよい。実施形態は、本文脈で限定されない。
【0074】
図５は、論理フロー５００の一実施形態を示す。論理フロー５００は、本明細書で説明する１つ以上の実施形態によって実行される動作の一部または全部を代表するものであってもよい。例えば、論理フロー５００は、非接触カード１０４を使用して医療状態の安全な検証を提供する動作の一部または全部を含むことができる。実施形態は、本文脈で限定されない。
【0075】
図示するように、ブロック５０２において、論理フロー５００は、非接触カード１０４に医療証明１２４を格納することを含む。一般に、前述のように、証明１２４はユーザの任意の保護された健康情報PHIに関連してよい。証明１２４のデジタル署名１４２は、署名エンティティ（例えば、医療提供者など）に関連する秘密鍵を使用して生成されうる。対応する公開鍵１４６、デジタル署名１４２、および証明１２４は、非接触カード１０４に格納されうる。一部の実施形態では、デジタル署名に関連する証明チェーンが非接触カード１０４に格納される。
【0076】
ブロック５０４において、クライアントアプリケーション１２２および／またはアプレット１１０は、カード１０４に格納された医療証明１２４を検証する要求を受信する。前述のように、要求は、ユーザ、アプリケーション、デバイス、または任意の他の要求エンティティによって開始されてもよい。要求は、医療証明１２４に基づいて検証される医療状態を指定してもよい。ブロック５０６において、アプレット１１０および／またはクライアントアプリケーション１２２は、医療証明１２４、公開鍵１４６、およびデジタル署名１４２を使用して要求を処理する。要求を処理する１つ以上の関連する操作は、図６および図７を参照してさらに説明される。一般に、アプレット１１０および／またはクライアントアプリケーション１２２は、デジタル署名１４２の証明チェーンを検証し、公開鍵１４６を使用してデジタル署名１４２を復号化し、復号化されたデジタル署名１４２を医療証明１２４と比較してもよい。比較の結果、一致した場合、医療証明１２４は検証される。同様に、要求に基づいて、アプレット１１０および／またはクライアントアプリケーション１２２は、結果を生成しうる。一般に、証明結果は、検証された医療証明１２４に基づく要求に対する応答である。例えば、要求がCOVID-19に対する免疫を証明することを指定した場合、アプレット１１０および／またはクライアントアプリケーション１２２は、証明１２４に基づいて、人がCOVID-19に対する免疫を持っているかどうかを示す応答を返してもよい。同様に、アプレット１１０および／またはクライアントアプリケーション１２２は、証明結果に基づいて１つ以上の操作の実行を開始してもよい。
【0077】
図６は、論理フロー６００の一実施形態を示す。論理フロー６００は、本明細書で説明する１つ以上の実施形態によって実行される動作の一部または全部を代表するものであってもよい。例えば、論理フロー６００は、非接触カード１０４に記憶された証明１２４に基づいて医療状態を検証する動作の一部または全部を含むことができる。実施形態は、この文脈に限定されない。
【0078】
ブロック６０２において、論理フロー６００は、対象者および医療状態を指定する要求を受信する。たとえば、クライアントアプリケーション１２２は、非接触カード１０４に関連付けられた認証された口座名義人がCOVID-19に対する免疫の証明を検証することを指定する要求を受信できる。たとえば、クライアントアプリケーション１２２は、ユーザが要求を生成できるようにする１つ以上の選択可能な要素を含むことができる。他の例では、要求は他のアプリケーションおよび／または他の装置から受信されてもよい。ブロック６０４において、論理フロー６００は、アプリケーション１２２によって、対象者の口座に関連付けられた非接触カードから暗号を受信する。暗号は、多様化鍵１１６および顧客ＩＤ１１８に基づいて生成されてもよい。多様化鍵１１６は、カウンタ１１２とマスター鍵１１４に基づいて生成されてもよい。アプリケーション１２２は、ブロック６０６において、検証のために暗号をサーバ１０６に送信してもよい。
【0079】
ブロック６０８において、サーバ１０６は、本明細書で説明するように、現在のカウンタとマスター鍵から多様化鍵を生成することにより、暗号を復号する。ブロック６１０において、アプリケーション１２２はサーバ１０６から復号結果を受信する。ブロック６１２において、アプリケーション１２２は、復号結果に基づいて、サーバが暗号を復号したと判定する。ブロック６１４において、論理フロー６００は、アプリケーション１２２によって、復号結果に基づいて、および／またはサーバによる暗号の復号に基づいて、非接触カード１０４から、医療証明１２４、医療証明のデジタル署名１４２、およびデジタル署名の公開鍵１４６を受信する。ブロック６１６において、アプリケーション１２２は公開鍵１４６に基づいてデジタル署名１４２を復号する。ブロック６１８において、アプリケーション１２２は、復号化されたデジタル署名を医療証明と比較し、比較の結果が一致すると判定することにより、復号化されたデジタル署名に基づいて医療証明１２４を検証する。ブロック６２０において、アプリケーション１２２は、医療証明１２４の検証に基づいて、対象者が医療状態に対して免疫があると判定する。ブロック６２２において、アプリケーション１２２は、対象者が医療状態に対して免疫があることを特定する証明結果を生成する。ブロック６２４において、アプリケーション１２２は証明結果を受信者デバイスに送信する。これにより、受信者デバイスは、例えば、公共の場所へのアクセスを許可および／または拒否するなどの操作を実行できる。
【0080】
図７は、論理フロー７００の一実施形態を示す。論理フロー７００は、本明細書で説明する１つ以上の実施形態によって実行される動作の一部または全部を代表できる。例えば、論理フロー７００は、非接触カード１０４に記憶された証明１２４を処理する動作の一部または全部を含むことができる。実施形態は、この文脈に限定されない。クライアントアプリケーション１２２を参照して説明したが、非接触カード１０４のアプレット１１０が論理フロー７００の操作の一部または全部を実行してもよい。
【0081】
ブロック７０２において、クライアントアプリケーション１２２は公開鍵１４６に基づいてデジタル署名１４２を復号する。ブロック７０４において、クライアントアプリケーション１２２は、デジタル署名１４２に関連する証明チェーン内の各証明書を検証する。ブロック７０６において、クライアントアプリケーション１２２は、１つ以上の規定の各々が満たされていることを判定する。たとえば、ルールは、デジタル署名１４２が１つ以上の予め定められるエンティティ、たとえば病院、政府機関などによって署名されることを要求できる。デジタル署名１４２が(例えば証明チェーンに反映されるように)１つ以上の予め定め定められるエンティティによって署名される場合、クライアントアプリケーション１２２は、これらの規則が満たされると判定する。同様に、サーバ１０６による暗号の復号は、満たされる別の規則であってもよい。ブロック７０８において、クライアントアプリケーション１２２は、任意で、医療証明１２４を第１のフォーマットから第２のフォーマットに復号し、本明細書で、第１および第２のフォーマットは、異なるデータフォーマット、異なるデータ種類などである。
【0082】
ブロック７１０において、クライアントアプリケーション１２２は、医療証明１２４を復号化されたデジタル署名１４２と比較する。ブロック７１２において、クライアントアプリケーション１２２は、復号化されたデジタル署名が受信した医療証明１２４と一致すると判定し、それによって医療証明１２４を検証する。ブロック７１４において、クライアントアプリケーション１２２は、医療証明の検証に基づいて、対象者が医療状態に対して免疫があると判定する。ブロック７１６において、クライアントアプリケーション１２２は、アプリケーションによって、対象者が医療状態に対して免疫があることを示す証明結果を生成する。ブロック７１８において、クライアントアプリケーション１２２は証明結果を受信者装置に送信する。ブロック７２０において、クライアントアプリケーション１２２は、証明結果を装置１０２のディスプレイに出力する。
【0083】
図８は、例示的な実施形態によるNDEFショートレコードレイアウト（SR=1）データ構造８００を示す。１つ以上のアプレットは、OTPをNDEFタイプ４の既知のタイプのテキストタグとしてエンコードしてもよい。いくつかの例では、NDEFメッセージは１つ以上のレコードを含む。アプレットは、OTPレコードに加えて、１つ以上の静的タグレコードを追加してもよい。限定されないが、一例は、タグの種類：既知の種類、テキスト、英語によるエンコード；アプレットＩＤ：D2760000850104；性能：読み取りのみ；エンコード：認証メッセージはASCII１６進数としてエンコードされうる；type-length-value (TLV) データは、NDEF メッセージの生成に使用できるパーソナライゼーションパラメータとして提供されうる。一実施形態では、認証テンプレートは、実際の動的認証データを提供する既知のインデックスを持つ最初のレコードを含み得る。様々な実施形態において、データ構造８００のペイロードは、暗号（例えば、暗号化された顧客ＩＤ１１８）、医療証明１２４、デジタル署名１４２、および／または公開鍵１４６を格納できる。
【0084】
図９は、上述したような様々な実施形態の実装に適したコンピューティングシステム９０２を含む例示的なコンピュータアーキテクチャ９００の実施形態を示す。一実施形態では、コンピュータアーキテクチャ９００は、コンピューティングアーキテクチャ１００または２００の一部を含み得るか、または一部として実装され得る。ある実施形態では、コンピューティングシステム９０２は、例えば、システム１００～２００の非接触カード１０４、コンピュ－ティング装置１０２、およびサーバ１０６を代表してもよい。実施形態は、この文脈に限定されない。より一般的には、コンピューティングアーキテクチャ９００は、図１Ａ～８を参照して本明細書で記載されるすべての論理、アプリケーション、システム、方法、装置、および機能を実装する。
【0085】
本出願で使用される場合、「システム」および「コンポーネント」という用語は、ハードウェア、ハードウェアとソフトウェアとの組み合わせ、ソフトウェア、または実行中のソフトウェアのいずれかであるコンピュータ関連エンティティを指すことを意図しており、その例は、例示的なコンピューティングコンピュータアーキテクチャ９００によって提供される。例えば、コンポーネントは、プロセッサ上で実行されるプロセス、プロセッサ、ハードディスクドライブ、(光および／または磁気記憶媒体の)複数の記憶ドライブ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであり得るが、これらに限定されない。例示として、サーバ上で実行されるアプリケーションとサーバの両方がコンポーネントであり得る。１つ以上のコンポーネントは、プロセスおよび／または実行のスレッド内に存在でき、コンポーネントは、１つのコンピュータ上に局在でき、および／または２つ以上のコンピュータ間に分散できる。さらに、コンポーネントは、様々な種類の通信媒体によって互いに通信可能に結合され、動作を調整できる。この調整には、単方向または双方向の情報交換が含まれる。例えば、構成要素は、通信媒体を介して通信される信号の形で情報を通信できる。情報は、様々な信号線に割り当てられた信号として実装できる。このような割り当てでは、各メッセージは信号である。しかしながら、さらなる実施形態では、代替的にデータメッセージを採用できる。そのようなデータメッセージは、様々な接続を介して送信できる。例示的な接続には、パラレルインタフェース、シリアルインタフェース、およびバスインタフェースが含まれる。
【0086】
コンピューティングアーキテクチャ９００は、１つ以上のプロセッサ、マルチコア・プロセッサ、コプロセッサ、メモリユニット、チップセット、コントローラ、周辺機器、インタフェース、発振器、タイミングデバイス、ビデオカード、オーディオカード、マルチメディア入出力（I/O）コンポーネント、電源などの様々な共通のコンピューティング要素を含む。しかしながら、実施形態は、コンピューティングアーキテクチャ１００による実装に限定されない。
【0087】
図９に示すように、コンピューティングアーキテクチャ９００は、プロセッサ９１２、システムメモリ９０４、およびシステムバス９０６を含む。プロセッサ９１２は、様々な市販のプロセッサのいずれでもよい。
【0088】
システムバス９０６は、システムメモリ９０４を含むがこれに限定されないシステムコンポーネントのプロセッサ９１２へのインタフェースを提供する。システムバス９０６は、市販されている様々なバスアーキテクチャのいずれかを使用して、メモリバス(メモリコントローラ付きまたはメモリコントローラなし)、周辺機器バス、およびローカルバスにさらに相互接続できる、いくつかの種類のバス構造のいずれかとできる。インタフェースアダプタは、スロットアーキテクチャを介してシステムバス９０８に接続できる。スロットアーキテクチャの一例は、限定されないが、AGP(Accelerated Graphics Port)、カードバス、(拡張)業界標準アーキテクチャ((E)ISA)、MCA(Micro Channel Architecture)、NuBus、PCI(X)(Peripheral Component Interconnect(Extended))、PCI Express、PCMCIA(Personal Computer Memory Card International Association)などが含まれる。
【0089】
コンピューティングアーキテクチャ９００は、様々な製造品を含むか、または実装できる。製造品は、ロジックを記憶するコンピュータ可読記憶媒体を含み得る。コンピュータ可読記憶媒体の例は、揮発性メモリまたは不揮発性メモリ、取り外し可能または取り外し不可能なメモリ、消去可能または消去不可能なメモリ、書き込み可能または再書き込み可能なメモリなどを含む、電子データを記憶できる任意の有形媒体を含み得る。ロジックの例は、ソースコード、コンパイルコード、インタプリタコード、実行可能コード、静的コード、動的コード、オブジェクト指向コード、ビジュアルコードなど、任意の適切な種類のコードを使用して実装される実行可能なコンピュータプログラム命令を含み得る。実施形態はまた、少なくとも部分的に、非一過性のコンピュータ可読媒体に含まれるか、または非一過性のコンピュータ可読媒体上に含まれる命令として実装されてもよく、この命令は、本明細書で説明される動作の実行を可能にするために、１つ以上のプロセッサによって読み取られ、実行され得る。
【0090】
システムメモリ９０４は、読み出し専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、ダイナミックRAM(DRAM)、ダブルデータレートDRAM(DDRAM)、シンクロナスDRAM(SDRAM)、スタティックRAM(SRAM)、プログラマブルROM(PROM)、消去可能プログラマブルROM(EPROM)などの１つ以上の高速メモリユニットの形態の様々な種類のコンピュータ可読記憶媒体、電気的に消去可能なプログラマブルROM(EEPROM)、フラッシュメモリ、強誘電体ポリマーメモリなどのポリマーメモリ、オボニックメモリ、相変化または強誘電体メモリ、シリコン-酸化物-窒化物-酸化物-シリコン(SONOS)メモリ、磁気カードまたは光カード、RAID(Redundant Array of Independent Disks)ドライブなどのデバイスのアレイ、ソリッドステートメモリデバイス（例えば、USBメモリ、ソリッド・ステート・ドライブ(SSD)、その他情報を記憶するのに適したあらゆる種類の記憶媒体）を含むことができる。図９に示す図示の実施形態では、システムメモリ９０４は、不揮発性メモリ９０８および／または揮発性メモリ９１０を含むことができる。基本入出力システム(BIOS)は、不揮発性メモリ９０８に格納し得る。
【0091】
コンピュータ９０２は、内蔵（または外付け）ハードディスクドライブ９３０、リムーバブル磁気ディスク９２０から読み出しまたはリムーバブル磁気ディスク９２０に書き込む磁気ディスクドライブ９１６、およびリムーバブル光ディスク９３２（たとえば、CD-ROMまたはDVD）から読み出しまたはリムーバブル光ディスク９３２に書き込む光ディスクドライブ９２８を含む、１つ以上の低速メモリユニットの形態の様々な種類のコンピュータ可読記憶媒体を含むことができる。ハードディスクドライブ９３０、磁気ディスクドライブ９１６および光ディスクドライブ９２８は、それぞれ、ＨＤＤインタフェース９１４、およびＦＤＤインタフェース９１８および光ディスクドライブインタフェース９３４によってシステムバス９０６に接続され得る。外部ドライブ実装のためのＨＤＤインタフェース９１４は、ユニバーサルシリアルバス（USB）およびIEEE 1394インタフェース技術の少なくとも１つまたは両方を含むことができる。
【0092】
ドライブおよび関連するコンピュータ可読媒体は、データ、データ構造、コンピュータ実行可能命令などの揮発性および／または不揮発性ストレージを提供する。例えば、オペレーティングシステム９２２、１つ以上のアプリケーション９４２、他のプログラムモジュール９２４、およびプログラムデータ９６２を含む、多数のプログラムモジュールをドライブおよび不揮発性メモリ９０８、および揮発性メモリ９１０に格納できる。例示的なオペレーティングシステム９２２は、AndroidOS、iOS、macOS、Linux、およびWindowsオペレーティングシステムを含む。一実施形態において、１つ以上のアプリケーション９４２、他のプログラムモジュール９２４、およびプログラムデータ９２６は、例えば、アプレット１１０、カウンタ１１２、マスター鍵１１４、多様化鍵１１６、顧客ＩＤ１１８、クライアントアプリケーション１２２、証明１２４、暗号化された顧客ＩＤ１３０、認証アプリケーション１３４、口座データ１３８、デジタル署名１４２、復号結果１４４、公開鍵１４６、暗号化された顧客ＩＤ２０２、および復号結果２０４のような、システム１００～２００の様々なアプリケーションおよび／またはコンポーネントを含み得る。
【0093】
ユーザは、例えばキーボード９５０やマウス９５２などのポインティングデバイスなどの１つ以上の有線/無線入力デバイスを介して、コマンドや情報をコンピュータ９０２に入力できる。他の入力デバイスとしては、マイクロフォン、赤外線（IR）リモートコントロール、無線周波数（RF）リモートコントロール、ゲームパッド、スタイラスペン、カードリーダー、ドングル、指紋リーダ、手袋、グラフィックタブレット、ジョイスティック、キーボード、網膜リーダ、タッチスクリーン（例えば、静電容量式、抵抗式など）、トラックボール、トラックパッド、センサー、スタイラスなどを含み得る。これらおよび他の入力デバイスは、システムバス９０６に結合された入力デバイスインタフェース９３６を介してプロセッサ９１２に接続されることが多いが、パラレルポート、IEEE1394シリアルポート、ゲームポート、USBポート、IRインタフェースなどの他のインタフェースによって接続することもできる。
【0094】
モニタ９４４または他の種類の表示装置も、ビデオアダプタ９４６などのインタフェースを介してシステムバス９０６に接続される。モニタ９４４は、コンピュータ９０２の内部であっても外部であってもよい。モニタ944に加えて、コンピュータは、通常、スピーカ、プリンタなどの他の周辺出力デバイスを含む。
【0095】
コンピュータ９０２は、リモートコンピュータ９４８などの１つ以上のリモートコンピュータへの有線および／または無線通信を介した論理接続を使用して、ネットワーク環境で動作できる。リモートコンピュータ９４８は、ワークステーション、サーバコンピュータ、ルータ、パーソナルコンピュータ、ポータブルコンピュータ、マイクロプロセッサベースの娯楽用電化製品、ピアデバイス、または他の一般的なネットワークノードとでき、典型的には、コンピュータ９０２に関連して説明した要素の多くまたはすべてを含むが、簡潔にするために、メモリおよび／または記憶装置９５８のみが図示される。図示された論理接続は、ローカルエリアネットワーク９５６および／またはより大規模なネットワーク、例えばワイドエリアネットワーク９５４への有線／無線接続を含む。このようなLANおよびWANネットワーキング環境は、オフィスや企業では一般的であり、イントラネットのような企業全体のコンピュータネットワークを容易にし、これらはすべて、例えばインターネットのようなグローバル通信ネットワークに接続できる。
【0096】
ローカルエリアネットワーク９５６のネットワーク環境で使用される場合、コンピュータ９０２は、有線および／または無線通信ネットワークインタフェースまたはネットワークアダプタ９３８を介してローカルエリアネットワーク９５６に接続される。ネットワークアダプタ９３８は、ローカルエリアネットワーク９５６への有線および／または無線通信を容易にでき、ネットワークアダプタ９３８の無線機能と通信するためにその上に配置された無線アクセスポイントを含むこともできる。
【0097】
ワイドエリアネットワーク９５４のネットワーク環境で使用される場合、コンピュータ９０２はモデム９４０を含むことができ、またはワイドエリアネットワーク９５４上の通信サーバに接続され、またはインターネットによるなど、ワイドエリアネットワーク９５４を介して通信を確立する他の手段を有する。モデム９４０は、内部または外部、有線および／または無線デバイスとでき、入力デバイスインタフェース９３６を介してシステムバス９０６に接続する。ネットワーク環境では、コンピュータ９０２に関連して描かれたプログラムモジュール、またはその一部を、リモートメモリおよび／または記憶装置９５８に格納できる。図示したネットワーク接続は例示的であり、コンピュータ間の通信リンクを確立する他の手段を使用できることが理解されよう。
【0098】
コンピュータ９０２は、ワイヤレス通信（例えば、IEEE 802.11無線変調技術）で動作可能に配置されたワイヤレスデバイスなど、IEEE802ファミリーの規格を使用する有線およびワイヤレスデバイスまたはエンティティと通信するように動作可能である。これには、少なくともWi-Fi（またはWireless Fidelity）、WiMax、およびBluetooth無線技術などが含まれる。したがって、通信は、従来のネットワークのようにあらかじめ定義された構造であることも、少なくとも２つの機器間の単なるアドホック通信であることもある。Wi-Fiネットワークは、IEEE 802.118（a、b、g、nなど）と呼ばれる無線技術を使用し、安全で信頼性が高く、高速な無線接続を提供する。Wi-Fiネットワークは、コンピュータ同士やインターネット、有線ネットワーク（IEEE 802.3関連のメディアと機能を使用する）との接続に使用できる。
【0099】
図１Ａ～９を参照して先に説明したようなデバイスの様々な要素は、様々なハードウェア要素、ソフトウェア要素、またはその両方の組み合わせを含み得る。ハードウェア要素の例は、デバイス、論理デバイス、コンポーネント、プロセッサ、マイクロプロセッサ、回路、プロセッサ、回路素子（例えば、トランジスタ、抵抗器、コンデンサ、インダクタなど）、集積回路、特定用途向け集積回路(ASIC)、プログラマブルロジックデバイス(PLD)、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、メモリユニット、論理ゲート、レジスタ、半導体デバイス、チップ、マイクロチップ、チップセットなどを含み得る。ソフトウェア要素の例は、ソフトウェアコンポーネント、プログラム、アプリケーション、コンピュータプログラム、アプリケーションプログラム、システムプログラム、ソフトウェア開発プログラム、マシンプログラム、オペレーティングシステムソフトウェア、ミドルウェア、ファームウェア、ソフトウェアモジュール、ルーチン、サブルーチン、機能、方法、手順、ソフトウェアインタフェース、アプリケーションプログラムインタフェース(API)、命令セット、コンピューティングコード、コンピュータコード、コードセグメント、コンピュータコードセグメント、ワード、値、シンボル、またはそれらの任意の組み合わせを含み得る。しかしながら、実施形態がハードウェア要素および／またはソフトウェア要素を使用して実装されるかどうかを決定することは、所与の実装に対して所望される計算速度、電力レベル、熱許容範囲、処理サイクル予算、入力データ速度、出力データ速度、メモリリソース、データバス速度、および他の設計または性能制約などの任意の数の要因に従って変化し得る。
【0100】
少なくとも１つの実施形態の１つ以上の態様は、プロセッサ内の様々なロジックを表す、機械可読媒体に格納された代表的な命令によって実装されてもよく、この命令が機械によって読み取られると、機械は、本明細書で説明する技術を実行するロジックを製造する。「IPコア」として知られるこのような表現は、有形の機械可読媒体に格納され、論理またはプロセッサを製造する製造機械にロードするために、様々な顧客または製造施設に供給され得る。いくつかの実施形態は、例えば、機械によって実行されると、実施形態に従った方法および／または動作を機械に実行させ得る命令または命令セットを記憶し得る機械可読媒体または物品を使用して実施され得る。そのような機械は、例えば、任意の適切な処理プラットフォーム、コンピューティングプラットフォーム、コンピューティング装置、処理デバイス、コンピューティングシステム、処理システム、コンピュータ、プロセッサなどを含むことができ、任意の適切なハードウェアおよび／またはソフトウェアの組み合わせを使用して実装されることができる。機械可読媒体または物品は、例えば、任意の適切な種類のメモリユニット、メモリ装置、メモリ物品、メモリ媒体、記憶装置、記憶物品、記憶媒体および／または記憶装置、例えば、メモリ、取り外し可能または取り外し不可能媒体、消去可能または消去不可能媒体、書き込み可能または再書き込み可能媒体、デジタルまたはアナログ媒体、ハードディスク、フロッピーディスク、コンパクトディスク読み取り専用メモリ（CD-ROM）、コンパクトディスク記録可能（CD-R）、コンパクトディスク再書き込み可能（CD-RW）を含むことができる、デジタルまたはアナログ媒体、ハードディスク、フロッピーディスク、コンパクトディスク読み出し専用メモリ（CD-ROM）、コンパクトディスク記録可能（CD-R）、コンパクトディスク書き換え可能（CD-RW）、光ディスク、磁気媒体、光磁気媒体、取り外し可能なメモリカードまたはディスク、様々な種類のデジタル多用途ディスク（DVD）、テープ、カセットなど。命令は、ソースコード、コンパイルされたコード、解釈されたコード、実行可能なコード、静的コード、動的コード、暗号化されたコードなど、任意の適切な種類のコードを含むことができ、任意の適切な高レベル、低レベル、オブジェクト指向、視覚的、コンパイルされたおよび／または解釈されたプログラミング言語を使用して実装される。
【0101】
前述の実施形態例の説明は、例示および説明の目的で提示されたものである。これは、網羅的であること、または本開示を開示された正確な形態に限定することを意図するものではない。本開示に照らして、多くの修正および変形が可能である。本開示の範囲は、この詳細な説明によってではなく、添付された特許請求の範囲によって限定されることが意図される。本出願の優先権を主張する将来の出願は、異なる態様で開示された主題を請求でき、一般に、本明細書で様々に開示されるかまたは他の方法で示されるような１つ以上の制限の任意のセットを含むことができる。
【図1A】
【図1B】
【図2A】
【図2B】
【図2C】
【図3A】
【図3B】
【図4A】
【図4B】
【図5】
【図6】
【図7】
【図8】
【図9】
【国際調査報告】