【事件の表示】
　特願２０１６−１３３９１９「グローバルプラットフォーム仕様を使用した発行元セキュリティドメインの鍵管理のためのシステム及び方法」拒絶査定不服審判事件〔平成２８年１０月１３日出願公開，特開２０１６−１８１９３６，請求項の数（２０）〕について，次のとおり審決する。
【結　論】
　原査定を取り消す。
　本願の発明は，特許すべきものとする。
【理　由】
第１．手続の経緯
　第１．手続の経緯
　本願は，２０１２年９月２８日（パリ条約による優先権主張外国庁受理２０１１年１２月２０日　アメリカ合衆国）を国際出願日とする特願２０１４−５４９０３４号の一部を，特許法４４条１項の規定により，平成２８年７月６日に新たな特許出願としたものであって，
　平成２８年８月４日付けで審査請求がなされると共に手続補正がなされ，平成２９年１０月２７日付けで審査官により拒絶理由が通知され，これに対して平成３０年５月２日付けで意見書が提出されると共に手続補正がなされたが，平成３０年９月２８日付けで審査官により拒絶査定がなされ（謄本送達；平成３０年１０月９日），これに対して平成３１年２月７日付けで審判請求がなされると共に手続補正がなされ，平成３１年２月２８日付けで審査官により特許法１６４条３項の規定に基づく報告がなされ，令和１年９月３０日付けで当審により拒絶理由が通知され，これに対して令和１年１２月１３日付けで意見書が提出されると共に手続補正がなされたものである。
　
第２　原審拒絶査定の概要
　原審における平成３０年９月２８日付け拒絶査定（以下,これを「原審拒絶査定」という）の概要は次のとおりである。
　
　本願の請求項１〜本願の請求項１０，本願の請求項１３〜本願の請求項１６，本願の請求項１９，及び，本願の請求項２０に係る発明は，以下の引用文献１〜引用文献３に基づいて，その発明の属する技術の分野における通常の知識を有する者（以下，「当業者」という。）が容易に発明できたものであるから，特許法第２９条第２項の規定により特許を受けることができない。
　
引用文献等一覧
　１．特開２００９−０６０５２８号公報
　２．米国特許出願公開第２００６／０１９６９３１号明細書
　３．特開平１１−１６８４６０号公報
　
第３　当審拒絶理由の概要
　当審における令和１年９月３０日付けの拒絶理由（以下，これを「当審拒絶理由」という）の概要は次のとおりである。
　
　本件出願は，特許請求の範囲の記載が下記の点で不備のため，特許法３６条６項２号に規定する要件を満たしていない。
　
　　　　　　　　　　　　　　　　記
　
１．本願の請求項１に，
「ベンダー装置において，
　前記クライアント装置に前記初期ＩＳＤ鍵セットを提供する段階であって，前記初期ＩＳＤ鍵セットは暗号化されていない形式である，段階と，
　前記クライアント装置に対して，前記サーバー装置に関連付けられる公開鍵を提供する段階と，
　前記初期ＩＳＤ鍵セットを前記公開鍵で暗号化して暗号化済み初期ＩＳＤ鍵セットを生成する段階と，
　前記ベンダー装置から独立して新規のＩＳＤ鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように，前記暗号化済み初期ＩＳＤ鍵セットを前記サーバー装置に提供する段階であって，前記新規のＩＳＤ鍵セットを確立するために前記クライアント装置が，前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のＩＳＤ鍵セットを生成し，前記サーバー装置へ提供される暗号化済みの新規のＩＳＤ鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する，段階と，
を含む」
　と記載され，上記引用の記載からは,上記引用記載が「ベンダー装置において」で始まることから，上記引用記載中の各「段階」は，「ベンダー装置」に関するものであるかのように見える。
　しかしながら，上記引用記載中の，
「新規のＩＳＤ鍵セットを確立するために前記クライアント装置が，前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のＩＳＤ鍵セットを生成し，前記サーバー装置へ提供される暗号化済みの新規のＩＳＤ鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する，段階」は，
「クライアント装置」の処理を示すものと解されるので，各「段階」の処理主体が何で，全体としてどのような構成を表現しようとしているのか，本願の請求項１に記載の内容からは，不明である。
（請求項１は，「方法」に関するクレームであって，各「段階」は，当該「方法」が，どのような過程を経るかを表現するものであるから，当該「段階」の処理主体が，明確になるような表現を検討されたい。）
　
２．本願の請求項１の上記１．において引用した記載中の，
「サーバー装置から受信した初期化スクリプトに基づいて前記新規のＩＳＤ鍵セットを生成し，前記サーバー装置へ提供される暗号化済みの新規のＩＳＤ鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する」，
　において，「ＩＳＤ鍵セット生成し，・・・ＩＳＤ鍵セットを生成するために」における後半の「ＩＳＤ鍵セットを生成するため」の処理が「鍵セットの暗号化」なので，「ＩＳＤ鍵の生成」と対応していない。（後半は，“ＩＳＤ鍵セットを提供するために”ではないのか？，また，「新規の鍵セット」は，「新規のＩＳＤ鍵セット」である。）
（以下省略）
　
第４．本願発明について
　本願の請求項１〜本願の請求項２０に係る発明（以下，これを「本願発明１〜本願発明２０」という）は，令和１年１２月１３日付けの手続補正（以下，これを「本件手続補正」という）により補正された特許請求の範囲の請求項１〜請求項２０に記載された事項により特定されるものであり，そのうち，本願発明１は，次のとおりのものである。
　
「ベンダー装置，クライアント装置及びサーバー装置が関与する，サーバー装置と通信するように構成されているクライアント装置用の初期発行元セキュリティドメイン（ＩＳＤ）鍵セットをプレパーソナライゼーションするための方法であって，前記ベンダー装置において，
　前記クライアント装置に前記初期ＩＳＤ鍵セットを提供する段階であって，前記初期ＩＳＤ鍵セットは暗号化されていない形式である，段階と，
　前記クライアント装置に対して，前記サーバー装置に関連付けられる公開鍵を提供する段階と，
　前記初期ＩＳＤ鍵セットを前記公開鍵で暗号化して暗号化済み初期ＩＳＤ鍵セットを生成する段階と，
　前記ベンダー装置から独立して新規のＩＳＤ鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように，前記暗号化済み初期ＩＳＤ鍵セットを前記サーバー装置に提供する段階と，
　前記クライアント装置において，前記新規のＩＳＤ鍵セットを確立するために，前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のＩＳＤ鍵セットを生成し，前記サーバー装置へ提供される暗号化済みの新規のＩＳＤ鍵セットを提供するために前記公開鍵を用いて前記新規のＩＳＤ鍵セットを暗号化する，段階と，
を含む方法。」
　
第５．引用文献に記載の事項及び引用文献に記載の発明
１．引用文献１について
（１）記載の事項
　引用文献１には，関連する図面と共に，次の事項が記載されている。
　
Ａ．「【０００９】
　本発明の鍵設定方法は，前記暗号操作装置として，ＳＡＭ（Secure Application Module）を用いる。」
　
Ｂ．「【００１７】
　図１および図２に示すように，本実施の形態の鍵設定システムは，端末２およびＳＡＭ４を製造して提供する端末製造者の端末製造者サーバ５と，端末２を用いてサービスを提供するサービス提供者のサービス提供者サーバ３と，端末１に情報を設定する情報設定者の情報設定者サーバ１とが存在する。情報設定者は，例えば，端末製造者やサービス提供者が合意した特定の信頼機関等，契約により独立性の保障された機関や，端末の運用を管理する者等である。なお，情報設定者は，サービス提供者および端末製造者とは異なる。」
　
Ｃ．「【００２０】
　図１および図２を参照しながら，本実施の形態の鍵設定方法の手順について説明する。
　まず，端末製造者サーバ５は，公開鍵ＰＫ１と，公開鍵ＰＫ１に対応する秘密鍵ＳＫ１を生成する（Ｓ１０）。端末製造者サーバ５は，秘密鍵ＳＫ１をＳＡＭ４に書き込み（Ｓ１２），公開鍵ＰＫ１を端末２に書き込む（Ｓ１４）。ＳＡＭ４は，端末製造者サーバ５から転送された秘密鍵ＳＫ１を実装する（Ｓ１６）。端末２は，端末製造者サーバ５から転送された公開鍵ＰＫ１を実装する（Ｓ１８）。
【００２１】
　端末製造者サーバ５は，共通鍵ＣＫ２を生成する（Ｓ２０）。端末製造者サーバ５は，共通鍵ＣＫ２を端末２およびＳＡＭ４に書き込む（Ｓ２２，Ｓ２４）。端末２およびＳＡＭ４は，端末製造者サーバ５から転送された共通鍵ＣＫ２を実装する（Ｓ２６，Ｓ２８）。
【００２２】
　次に，端末製造者は，鍵を設定したＳＡＭ４をサービス提供者に渡し，鍵を設定した端末２を情報設定者に渡す。
【００２３】
　サービス提供者サーバ３は，サービスに係るアプリケーションの実行に必要な運用鍵Ｋを生成する（Ｓ３０）。サービス提供者サーバ３は，生成した運用鍵ＫをＳＡＭ４に書き込む（Ｓ３２）。
【００２４】
　ＳＡＭ４は，サービス提供者サーバ３から書き込まれた運用鍵Ｋを共通鍵ＣＫ２を用いて暗号化し，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を生成する（Ｓ３４）。また，ＳＡＭ４は，秘密鍵ＳＫ１を用いて，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］に署名ＳＧ１を付与する（Ｓ３６）。ＳＡＭ４は，署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］をサービス提供者サーバ３に出力する（Ｓ３８）。
【００２５】
　サービス提供者サーバ３は，ＳＡＭ４から取得した署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を，情報設定者サーバ１に送信する（Ｓ４０）。
【００２６】
　情報設定者サーバ１は，サービス提供者サーバ３から受け取った署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を，端末２に転送する（Ｓ４２）。
【００２７】
　端末２は，情報設定者サーバ１より転送された署名ＳＧ１を，端末製造者サーバ５にて設定された公開鍵ＰＫ１を用いて検証する（Ｓ４４）。検証に成功すると，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を共通鍵ＣＫ２で復号し，運用鍵Ｋを取得する（Ｓ４６）。端末２は，取り出した運用鍵Ｋを端末２に設定し，運用開始可能な状態になる（Ｓ４８）。
  以上，本実施の形態の鍵設定方法について説明した。」
　
Ｄ．「【００２９】
　端末製造者サーバ５が生成した秘密鍵ＳＫ１をＳＡＭ４に，公開鍵ＰＫ１を端末２に設定し，サービス提供者サーバ３はＳＡＭ４内の秘密鍵ＳＫ１を用いて暗号化運用鍵Ｅ［ＣＫ２，Ｋ］の署名ＳＧ１を取得する。情報設定者サーバ１は，サービス提供者サーバ３から受け取った署名ＳＧ１を端末２に転送し，端末２は，公開鍵ＰＫ１を用いて検証することにより，端末２に設定する運用鍵Ｋがサービス提供者によって生成されたものであることを保証できる。」
　
（２）記載の発明
　上記「（１）記載の事項」に引用した，引用文献１に記載の内容から，引用文献１には，次の発明（以下，これを「引用発明」という）が記載されているものと認める。
　
「端末製造者サーバが，公開鍵ＰＫ１と公開鍵ＰＫ１に対応する秘密鍵ＳＫ１を生成し，秘密鍵ＳＫ１をＳＡＭ（Secure Application Module）に書き込み，公開鍵ＰＫ１を端末に書き込み，共通鍵ＣＫ２を生成し，共通鍵ＣＫ２を端末およびＳＡＭに書き込み，
　端末製造者が，鍵を設定したＳＡＭをサービス提供者に渡し，鍵を設定した端末を情報設定者に渡し，
　サービス提供者サーバが，サービスに係るアプリケーションの実行に必要な運用鍵Ｋを生成し，生成した運用鍵ＫをＳＡＭに書き込み，
　ＳＡＭが，サービス提供者サーバから書き込まれた運用鍵Ｋを共通鍵ＣＫ２を用いて暗号化し，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を生成し，秘密鍵ＳＫ１を用いて，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］に署名ＳＧ１を付与し，署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］をサービス提供者サーバに出力し，
　サービス提供者サーバが，ＳＡＭから取得した署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を，情報設定者サーバに送信し，
　情報設定者サーバが，サービス提供者サーバから受け取った署名ＳＧ１が付された暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を，端末に転送し，
　端末が，情報設定者サーバより転送された署名ＳＧ１を，端末製造者サーバにて設定された公開鍵ＰＫ１を用いて検証し，検証に成功すると，暗号化運用鍵Ｅ［ＣＫ２，Ｋ］を共通鍵ＣＫ２で復号し，運用鍵Ｋを取得し，取り出した運用鍵Ｋを端末に設定し，運用開始可能な状態になり，
　端末は，公開鍵ＰＫ１を用いて検証することにより，端末に設定する運用鍵Ｋがサービス提供者によって生成されたものであることを保証でき，
　端末として，クレジットカードによる決済端末を用いる，
　鍵設定方法。」
　
２．引用文献２について
　引用文献２には，関連する図面と共に，次の事項が記載されている。
　
Ｅ．「[0003]　Credit card companies, such as MasterCard and Visa, are currently successfully using an EMV (Europay, MasterCard, and Visa) credit card payment standard to perform credit card personalization. Credit card personalization refers to the process by which security and user data is transmitted to a user's credit card, such as a smart card containing an EMV chip. A first step in this personalization process is establishing an issuer security domain, which today is typically done in the factory of a smart card manufacturer. The security domain is used to create a secure channel between a personalization device, which is used to conduct the download of application data and the actual personalization, and the EMV chip embedded in the credit card. A secure channel is any channel over which information can be transmitted without being readily publicly available, and may be created, for example, using various encryption schemes or by authenticating both end points of the channel. Once the secure channel is created, the personalization device can activate the EMV chip and eventually transmit the personalization data to it. Credit card companies often rely on smart card manufacturers, such as Orga, Axalto, Giesecke and Devrient, or Cedex, to perform this personalization process. These manufacturers receive the needed user personalization data from the credit card companies and perform the steps discussed below in order to embed user-specific data into each credit card. The smart card manufacturers can then act as credit card issuers on behalf of the credit card companies.」
（【０００２】
　ＭａｓｔｅｒＣａｒｄ及びＶｉｓａなどのクレジットカード会社は，現在のところクレジットカード個人化を行うためにＥＭＶ（Ｅｕｒｏｐａｙ，Ｍａｓｔｅｒｃａｒｄ，及びＶｉｓａ）クレジットカード決済規格を利用することに成功している。クレジットカード個人化とは，ＥＭＶチップを含むスマートカードなどのユーザのクレジットカードにセキュリティ及びユーザデータが送信されるプロセスのことを指す。この個人化プロセスの最初のステップは，発行者セキュリティドメインを設定する段階であり，現在では通常スマートカード製造業者の工場で行われる。セキュリティドメインは，アプリケーションデータのダウンロード及び実際の個人化を行うのに使用される個人化デバイスと，クレジットカードに埋め込まれたＥＭＶチップとの間でセキュアチャンネルを作成するのに使用される。セキュアチャンネルは，公的に容易に入手可能ではない状態で情報を送信することができるあらゆるチャンネルであり，例えば，種々の暗号化方式を使用して或いはチャンネルのエンドポイント両方を認証することによって作成することができる。セキュアチャンネルが作成されると，個人化デバイスはＥＭＶチップを起動し，最終的には個人化データをＥＭＶチップに送信することができる。クレジットカード会社は，この個人化プロセスを行うためにＯｒｇａ，Ａｘａｌｔｏ，Ｇｉｅｓｅｃｋｅ及びＤｅｖｒｉｅｎｔ，又はＣｅｄｅｘなどのスマートカード製造業者に頼ることが多い。これらの製造業者は，ユーザ固有のデータを各クレジットカードに埋め込むために，必要とされるユーザ個人化データをクレジットカード会社から受け取り，以下に説明されるステップを行う。このように，スマートカード製造業者は，クレジットカード会社に代わってクレジットカード発行者として役割を果たすことができる。対応する日本語公報である，特表２００８−５３７３７０号公報より引用。以下，同じ。）
　
Ｆ．「[0007] Recently, companies such as MasterCard and Visa have introduced a new payment method known, for example, as PayPass or Visa Waver, wherein credit cards are manufactured having RFID (radio frequency identification) capabilities. Under this new method, merchants are equipped with RFID devices that are capable of reading these RFID-capable credit cards when a user places his or her card a few centimeters in front of the reader. This new method enables faster and easier credit card payments. Similar proximity RFID systems are also being used in public transportation systems, such as Octopus or Helsinki Public Transport. For example, prepaid bus, or train, cards containing RFID capabilities may be purchased by customers and used in conjunction with RFID readers at the bus or train station to purchase tickets for riding the bus or train.
[0008] The use of RFID readers at different vendor locations, as well as at various public transportation stations, opens the door to other types of payment methods that could utilize these point-of-sale (POS)RFID readers. One such payment method would be to enable an individual to use his or her mobile phone, or some other mobile device, such as a personal digital assistant (PDA) or mobile personal computer (PC) that is connected to a mobile phone or PDA (e.g., via Bluetooth, cable, RFID, or Infrared), to transfer credit card or other user-specific information. In other words, the individual could use his or her mobile phone in the same circumstances as he or she would use his or her credit card or prepaid public transportation card. For example, the user's personal credit card details could be embedded in the mobile device and transmitted to the POS RFID reader. The same protocols used, for example, for PayPass and VisaWave could be used. In this case, the mobile device would be connected to a PC; the PC would request the necessary data from the mobile device, and then transfer the data to the POS (via the Internet).
[0009] In order to implement this mobile EMV system, the overall system must first be certified. EMV certification is an expensive procedure defined by EMV that every smart card issuer that wishes to act as an EMV issuer must comply with. Without certification, it is unlikely that credit card companies will accept the inherent risks involved and “connect” the mobile EMV solution to their payment infrastructure. Mobile devices, however, are much more open than smart cards, since they can run additional software applications and have more external interfaces than a smart card. As a result, mobile EMV software applications built on existing mobile device hardware would likely face serious challenges when attempting to obtain EMV certification; thus making obtaining the requisite certification very difficult and expensive.
[0010] One alternative solution is to integrate an already certified EMV chip or smart card into the mobile device, rather than building mobile EMV software applications on existing mobile device hardware. To do this, one option is to introduce a second slot into the mobile device, wherein the EMV chip could be personalized as usual, for example at a smart card manufacturer, and then later inserted into the mobile device by the user. However, this approach too can be very expensive due to the additional hardware costs for the mobile device for the mass-market. Other options would be to either incorporate a Universal Integrated Circuit Card (UICC) that supports many applications into the mobile device, or embed the certified EMV chip into the mobile device during manufacturing of the device.
[0011] During manufacturing, however, it is not known who will ultimately own each mobile device; thus preventing any payment data from being fully personalized during the normal manufacturing process. This is different from the credit card business of today, where the recipient of the card is known during issuance of the card. One solution is to incorporate the UICC or embed the certified EMV chip into the mobile device during manufacture and then require that the user send his or her mobile device to a smart card manufacturer or personalization bureau that can then perform the personalization, in a manner similar to that discussed above with respect to the credit cards. This, however, requires that the user relinquish his mobile device to the smart card manufacturer for some period of time. Another solution is to require that the user apply for a phone with credit card functionality in the same manner as he or she would apply for a credit card. The fully personalized mobile device having credit card capabilities would then be sent directly to the user. These options, however, would require that changes be made to the existing manufacturing process and sales channels, and they can be expensive and time consuming.
[0012] Another solution is to perform the personalization over the air (OTA) after the user has purchased his or her mobile device. However, certain risks are inherent in the transmission of security data OTA. As stated above, prior to initiating a personalization process, an issuer security domain that can be used to establish a secure channel between the personalization device and the EMV chip or UICC must be created. A need therefore exists for a secure means of transmitting credit card personalization data to a mobile device OTA-i.e., a means of creating the requisite issuer security domain and secure channel.
　
BRIEF SUMMARY OF THE INVENTION  　
[0013] Generally described, exemplary embodiments of the present invention provide an improvement over the known prior art by providing a method of creating an issuer security domain for the establishment of a secure channel over which personalization data, such as credit card personalization or public transport ticketing data, can be transmitted over the air (OTA). In particular, in exemplary embodiments Generic Authentication Architecture (GAA) may be used to establish a shared secret that can be used to create a secure communication channel between the user equipment (UE) and a personalization application server or bureau acting as a network application function (NAF) server.
[0014] In general, as used herein, user equipment refers to a mobile device (e.g., a cellular telephone, personal digital assistant (PDA), laptop, pager, etc.) incorporating functionality to charge for goods or services requested for by the user of the user equipment. For example, user equipment may refer to a mobile device having EMV functionality through either an EMV-certified chip embedded in the mobile device, or one or more EMV applications stored on a UICC or smart card associated with the mobile device. In one exemplary embodiment, the EMV application may be stored on the network operator's UICC or smart card. Alternatively, a separate, EMV-specific UICC or smart card containing the one or more EMV applications may be provided. In this embodiment, the mobile device would comprise two slots for the respective UICCs (i.e., the network operator UICC and the EMV-specific UICC), wherein the EMV-specific UICC or smart card is capable of being removed and used in conjunction with another mobile device also possessing two slots. In this way, a user is capable of using different mobile devices (e.g., the user's own, as well as his or her mother's, father's, sister's, etc.) as a credit card or public transport ticketing card simply by inserting their EMV-specific UICC or smart card into the mobile device.
[0015] User equipment capable of receiving personalization data over a secure channel, a personalization application server (e.g., a NAF server where GAA is used) capable of transmitting the personalization data over the secure channel, and a system embodying this user equipment and personalization application server, are also provided in exemplary embodiments.
[0016] According to one aspect of the invention, therefore, a method is provided for creating an issuer security domain that is capable of being used to establish a secure channel for over the air (OTA) transmission of personalization data from a personalization application server to an user equipment. In one exemplary embodiment, the method includes: (1) generating one or more shared secret keys known to the user equipment and the personalization application server; and (2) using the one or more shared secret keys to create an issuer security domain, wherein the issuer security domain is capable of being used to establish a secure channel for OTA transmission of personalization data from the personalization application server to the user equipment.
[0017] According to another aspect of the invention, a method of transmitting personalization data OTA from a first entity to a second entity in a secure manner is provided. In one exemplary embodiment, the method includes: (1) generating one or more shared secret keys known to the first and second entities using a Generic Authentication Architecture (GAA); (2) using the one or more shared secret keys to create an issuer security domain between the first and second entities; (3) establishing a secure channel between the first and second entities using the issuer security domain; and (4) transmitting the personalization data over the secure channel.」
（【０００６】
　最近では，ＭａｓｔｅｒＣａｒｄ及びＶｉｓａなどの会社が，例えばＰａｙＰａｓｓ又はＶｉｓａ  Ｗａｖｅｒとして知られる新しい決済方法を導入しており，ＲＦＩＤ（無線識別）機能を有するクレジットカードが製造されている。この新しい方法では，ＲＦＩＤデバイスが小売店に備え付けられ，該ＲＦＩＤデバイスは，ユーザが読取装置の数センチメートル手前に自分のカードを置くと，これらのＲＦＩＤ対応クレジットカードを読み取ることができる。この新しい方法によってクレジットカードの決済がより早くより簡単になる。類似の近接ＲＦＩＤシステムは，Ｏｃｔｏｐｕｓ（オクトパス）又はヘルシンキ公共交通などの公共交通システムでも使用されている。例えば，ＲＦＩＤ機能を含むプリペイドのバス又は列車のカードが顧客によって購入され，バス停又は列車の駅にあるＲＦＩＤ読取装置と共に使用して，バス又は列車に乗るためのチケットを購入することができる。
【０００７】
　種々のベンダーロケーション，並びに種々の公共交通ステーションでのＲＦＩＤ読取装置の使用は，これらの販売時点情報管理（ＰＯＳ）ＲＦＩＤ読取装置を利用できる他のタイプの決済方法の機会を与える。このような１つの決済方法によって，個人が自分の携帯電話或いは携帯電話又はＰＤＡに接続（例えば，ブルートゥース，ケーブル，ＲＦＩＤ，又は赤外線を介して）されているパーソナルデジタルアシスタント（ＰＤＡ）又はモバイルパーソナルコンピュータ（ＰＣ）などのある他のモバイルデバイスを使用して，クレジットカード又は他のユーザ固有の情報を転送することが可能になる。言い換えると，個人が，自分のクレジットカード又はプリペイド公共交通カードを使用する場合と同じ状況で自分の携帯電話を使用することができるようになる。例えば，ユーザの個人クレジットカードの詳細をモバイルデバイスに組み込み，ＰＯＳ  ＲＦＩＤ読取装置に送信することができるようになる。例えば，ＰａｙＰａｓｓ及びＶｉｓａＷａｖｅに使用されるのと同じプロトコルを使用することができる。この場合，モバイルデバイスは，ＰＣに接続されることになり，ＰＣは，モバイルデバイスに必要なデータを要求し，次いで，このデータをＰＯＳに（インターネットを介して）転送することになる。
【０００８】
　このモバイルＥＭＶシステムを実施するために，最初にシステム全体を証明する必要がある。ＥＭＶ証明は，ＥＭＶ発行者として役割を果たすことを意図する全てのスマートカード発行者が従う必要のある，ＥＭＶによって定められた高価な手続である。証明なしでは，クレジットカード会社は，内包する固有リスクを受け入れてモバイルＥＭＶソリューションを会社の決済インフラストラクチャに「接続する」可能性は低い。しかしながら，モバイルデバイスは，付加的なソフトウェアアプリケーションを実行しスマートカードよりも多くの外部インターフェースを有することができるので，スマートカードよりも遙かにオープンである。この結果，既存のモバイルデバイスハードウェア上で構築されたモバイルＥＭＶソフトウェアアプリケーションは，ＥＭＶ証明を取得しようとする場合に重大な問題に直面する可能性があり，従って，必要な証明の取得が非常に困難で費用のかかるものになる。
【０００９】
　１つの代替の解決策は，既存のモバイルデバイスハードウェア上にモバイルＥＭＶソフトウェアアプリケーションを構築するのではなく，既に証明済みのＥＭＶチップ又はスマートカードをモバイルデバイスに組み込むことである。これを行うための１つの選択肢は，第２のスロットをモバイルデバイスに取り入れることであり，この場合，ＥＭＶチップは，例えばスマートカード製造業者で通常通り個人化し，次いで，後でユーザによってモバイルデバイスに挿入することができる。しかしながら，この方法も大量市場に対するモバイルデバイスのハードウェアコストが追加されることに起因して，極めて高価になる可能性がある。他の選択肢は，多くのアプリケーションをサポートする汎用ＩＣカード（ＵＩＣＣ）をモバイルデバイスに組み込むか，或いは，証明済みのＥＭＶチップをモバイルデバイスの製造中にデバイスに埋め込むかのいずれかになる。
【００１０】
　しかしながら，製造中には，最終的に誰が各モバイルデバイスを所有するかが分からず，従って，通常の製造プロセス中にあらゆる決済データが完全に個人化されるのが阻止される。これは，カードの受取人がカードの発行中に既知である今日のクレジットカードビジネスとは相違する。１つの解決策は，クレジットカードに関して上述されたのと類似の方法で，製造中にモバイルデバイスにＵＩＣＣを組み込むか或いは証明済みＥＭＶチップを埋め込み，次いで，ユーザがスマートカード製造業者又は個人化ビューローに自分のモバイルデバイスを送ることを必要とし，そこで個人化を行うことができるようにすることである。しかしながら，これには，ユーザがある時間期間の間自分のモバイルデバイスをスマートカード製造業者に明け渡すことが必要になる。別の解決策では，ユーザがクレジットカードを申し込むのと同じ方法でクレジットカード機能を有する電話を申し込むことが必要である。次いで，クレジットカード機能を有する完全に個人化されたモバイルデバイスは，直接ユーザに送られることになる。しかしながら，これらの選択肢では，既存の製造プロセス及び販売網を変更することが必要になり，これらは，高コストで時間がかかることになる。
【００１１】
　別の解決策は，ユーザが自分のモバイルデバイスを購入した後で，無線（ＯＴＡ）で個人化を行うことである。しかしながら，セキュリティデータのＯＴＡ送信には一定のリスクが内在する。上述のように，個人化プロセスを開始する前に，個人化デバイスとＥＭＶチップ又はＵＩＣＣとの間のセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する必要がある。従って，モバイルデバイスにＯＴＡでクレジットカード個人化データを送信する安全な手段，すなわち必要な発行者セキュリティドメイン及びセキュアチャンネルを作成する手段に対するニーズがある。
【発明の開示】
【００１２】
　一般的に言えば，本発明の例示的な実施形態は，クレジットカード個人化又は公共交通チケット発券データなどの個人化データを無線（ＯＴＡ）で送信することができるセキュアチャンネルの設定のための発行者セキュリティドメインを作成する方法を提供することによって，公知の従来技術に対して改善をもたらす。詳細には，例示的な実施形態では，汎用認証アーキテクチャ（ＧＡＡ）を使用して，ユーザ装置（ＵＥ）とネットワークアプリケーション機能（ＮＡＦ）サーバとして働く個人化アプリケーションサーバ又はビューローとの間のセキュア通信チャンネルを作成するのに使用することができる共有秘密を設定することができる。
【００１３】
　一般に，本明細書で使用されるユーザ装置とは，ユーザ装置のユーザによってリクエストされた商品又はサービスに課金する機能を組み込んだモバイルデバイス（例えば，セルラー電話，パーソナルデジタルアシスタント（ＰＤＡ），ラップトップ，ページャーなど）を指す。例えばユーザ装置は，モバイルデバイスに埋め込まれたＥＭＶ証明済みチップ，或いはモバイルデバイスに関連したＵＩＣＣ又はスマートカードに記憶された１つ又はそれ以上のＥＭＶアプリケーションのいずれかを介してＥＭＶ機能を有するモバイルデバイスを意味することができる。１つの例示的な実施形態では，ＥＭＶアプリケーションは，ネットワークオペレータのＵＩＣＣ又はスマートカード上に記憶することができる。或いは，１つ又はそれ以上のＥＭＶアプリケーションを含む別個のＥＭＶ固有ＵＩＣＣ又はスマートカードを提供することができる。この実施形態では，モバイルデバイスは，それぞれのＵＩＣＣ（すなわち，ネットワークオペレータＵＩＣＣとＥＭＶ固有のＵＩＣＣ）に対して２つのスロットを含み，ＥＭＶ固有のＵＩＣＣ又はスマートカードは，取り除くことができ，２つのスロットを所有する別のモバイルデバイスと共に使用することができる。このようにしてユーザは，ＥＭＶ固有のＵＩＣＣ又はスマートカードをモバイルデバイスに挿入することによって異なるモバイルデバイス（例えばユーザ自身の，並びにユーザの母親，父親，姉妹などの）をクレジットカード又は公共交通チケット発券カードとして簡単に使用することができる。
【００１４】
　例示的な実施形態において，セキュアチャンネルを介して個人化データを受信することができるユーザ装置，セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバ（例えばＧＡＡが使用されているＮＡＦサーバ），及びこのユーザ装置と個人化アプリケーションサーバを実現するシステムもまた備えられる。
【００１５】
　従って本発明の１つの態様によれば，個人化アプリケーションサーバからユーザ装置への個人化データの無線（ＯＴＡ）送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するための方法が提供される。１つの例示的な実施形態では，本方法は，（１）ユーザ装置及び個人化アプリケーションサーバに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と，（２）１つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する段階とを含み，ここで発行者セキュリティドメインは，個人化アプリケーションサーバからユーザ装置への個人化データのＯＴＡ送信のためのセキュアチャンネルを設定するのに使用することができる。
【００１６】
　本発明の別の態様によれば，第１エンティティから第２エンティティにセキュアな方法で個人化データをＯＴＡで送信する方法が提供される。１つの例示的な実施形態では，本方法は，（１）汎用認証アーキテクチャ（ＧＡＡ）を使用して第１及び第２エンティティに既知の１つ又はそれ以上の共有秘密鍵を生成する段階と，（２）１つ又はそれ以上の共有秘密鍵を使用して第１と第２エンティティとの間に発行者セキュリティドメインを作成する段階と，（３）発行者セキュリティドメインを使用して第１と第２エンティティとの間にセキュアチャンネルを設定する段階と，（４）セキュアチャンネルを介して個人化データを送信する段階とを含む。）
　
Ｇ．「[0040] FIG.3 illustrates an exemplary network model for generic bootstrapping. As shown, a Bootstrapping Server Function (BSF) 60 is connected via a bidirectional link to the User Equipment (UE) 40. The BSF 60 and UE 40 can mutually authenticate using the AKA protocol and agree on session keys. These session keys can later be used for a session between the user equipment and a Network Application Function (NAF) server 70, which is also connected to the user equipment 40 and to the BSF 60 by means of a bidirectional link. In one exemplary embodiment the NAF server 70 is included in the operator's system. Alternatively, the NAF server 70 may merely be under a contract with the operator for the provision of security credential services. In the case of a third-party network, the architecture may also include a Diameter-Proxy (D-Proxy), not shown, as described in the 3GPP Technical Specification 33.220, entitled Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (Release 7, June 2005) (3GPP TS 33.220 v7.0.0 (2005-06)) (hereinafter“TS 33.220”), the contents of which are incorporated herein by reference in their entirety and which can be found at www.3gpp.org.
[0041] After the bootstrapping procedure, which is described in detail below, the user equipment 40 and the NAF 70 can run an application-specific protocol, for instance a credit card personalization or public transport ticketing application, where the authentication and confidentiality of the messages will be based on the session keys generated during mutual authentication. Accordingly, GAA/GBA 22 can, in general, be regarded as a 3-party authentication scenario, wherein the BSF 60 is further connected to a HSS 30 or HLR, which stores, for example, GBA user security settings (GUSS). In the case where there are several HSS, the connection between BSF and HSS may utilize a SLF (Server Location Function), so that the BSF is able to find the HSS, which stores the appropriate user data.」
（【００２９】
　図３は，汎用ブートストラッピングのための例示的なネットワークモデルを示す。図に示すように，ブートストラッピングサーバ機能（ＢＳＦ）６０は，双方向リンクを介してユーザ装置（ＵＥ）４０に接続されている。ＢＳＦ６０及びＵＥ４０は，ＡＫＡプロトコルを使用して相互に認証し，セッション鍵に合意することができる。これらのセッション鍵は，後で，ユーザ装置とネットワークアプリケーション機能（ＮＡＦ）サーバ７０との間のセッションに使用することができ，該サーバは，双方向リンクによってユーザ装置４０及びＢＳＦ６０に接続されている。１つの例示的な実施形態では，ＮＡＦサーバ７０は，オペレータのシステム内に含まれる。或いは，ＮＡＦサーバ７０は単に，セキュリティクレデンシャルサービスを提供するためにオペレータと契約することができる。サードパーティネットワークの場合には，アーキテクチャは，図示されていないが「Ｇｅｎｅｒｉｃ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＧＡＡ：汎用認証アーキテクチャ）；Ｇｅｎｅｒｉｃ  Ｂｏｏｔｓｔｒａｐｐｉｎｇ  Ａｒｃｈｉｔｅｃｔｕｒｅ（汎用ブートストラッピングアーキテクチャ）」（２００５年６月７日発行）（３ＧＰＰ  ＴＳ３３．２２０ｖ７．０．０（２００５−０６））（以下「ＴＳ３３．２２０」）と題された３ＧＰＰ技術仕様３３．２２０に説明されるようなＤｉａｍｅｔｅｒ（ダイアメータ）−プロキシ（Ｄ−プロキシ）を含むことができ，この内容は，引用により全体が本明細書に組み込まれ，ｗｗｗ．３ｇｐｐ．ｏｒｇで見ることができる。
【００３０】
　以下に詳細に説明されるブートストラッピング手続の後で，ユーザ装置４０及びＮＡＦ７０は，例えばクレジットカード個人化又は公共交通チケット発券アプリケーションであるアプリケーション固有プロトコルを実行することができ，ここでは，メッセージの認証及び機密保護が相互認証の間に生成されたセッション鍵に基づくことになる。従って，ＧＡＡ／ＧＢＡ２２は，一般的に，３パーティ認証ケースとして見なすことができ，ＢＳＦ６０は更に，例えばＧＢＡユーザセキュリティ設定（ＧＵＳＳ）を記憶するＨＳＳ３０又はＨＬＲに接続される。幾つかのＨＳＳが存在する場合には，ＢＳＦとＨＳＳとの間の接続はＳＬＦ（サーバロケーション機能）を利用でき，これによってＢＳＦは，適切なユーザデータを記憶するＨＳＳを見つけることができる。）
　
Ｈ．「[0054] FIG. 6 is a block diagram of a UE capable of operating in accordance with exemplary embodiments of the present invention. The UE may include, for example, a mobile device, such as a cellular telephone, personal digital assistant (PDA), pager, personal computer (PC), laptop, tablet, or any other similar device, having EMV functionality, as described below. As shown, the UE may consist at least of a secure core 610, a UICC (universal integrated circuit card) 620, an EMV application 632, and a GBA application 634. The secure core 610, which need not be a central or innermost part of the mobile device, and instead merely represents any element or elements capable of functioning as described herein, may, in turn, consist of a blank chip that is installed during manufacture and is capable of storing the generated shared secret keys 612, as well as one or more payment or ticketing applications 614 installed by or on behalf of the user to facilitate usage of the UE for payment or ticketing.
[0055] The UICC 620 may contain a user identification module that stores identification information 626 specific to the user of the mobile device on which it is located. The user identification module need not actually be modular in nature. In other words, the identification information stored in the user identification module need not be stored as part of one modular entity and may, instead, be distributed throughout the mobile device. This identification information 626 may be used during the GAA procedure (or shared secret key installation process) to identify the UE to the BSF server. In one embodiment, the UICC 620 further includes EMV_U 622 and GBA_U 624 applications that are also used in the shared secret key installation process to establish the secure link between the UICC 620 and the NAF server. In particular, the GBA_U application 624 may be used to generate the NAF-specific keys, which can be used to authenticate the UE to the NAF server or to secure a communication between the two, based on the secret keys shared between the mobile network operator and the UICC 620 (i.e., CK and IK). In one embodiment, the UE may not contain a GBA_U application 624 in the UICC 620. In this instance, the key generation and storage functionality is performed by the GBA application 634 in the Ut, and the UICC would only deliver the necessary information. In one embodiment, the EMV_U application comprises a state machine that is used to monitor the progress of the shared secret key installation process. In this embodiment, if the installation process is interrupted, the state machine indicates that the installation must start again. If the UE does not contain a GBA_U application, then the EMV_U application would also reside in the mobile terminal and not in the UICC.
[0056] The EMV application 632 included in the UE serves as a communication entity by facilitating communication between entities external to the UE (e.g., the NAF and BSF servers), and the UICC 620 and secure core 610. For example, in the shared secret key installation process, the EMV application 632 is responsible for requesting the issuer security domain keys from the NAF server, handing them to the UICC 620 for decryption, and storing those keys on the secure core 610, discussed in detail below. As stated above, in one embodiment, in which there is no GBA_U application 624 in the UICC 620, the GBA application 634, which is in the UE, performs the key generation and storage function discussed below.
[0057] FIG.7A is a signal flow diagram illustrating the steps taken in exemplary embodiments when preparing the UE for credit card, or similar, personalization−i.e., creating an issuer security domain that can be used to establish the secure communication channel over which security and user data can be transmitted to the UE. In the first step, the EMV application (residing on the mobile/user device (UE)) requests additional security data from the NAF server (i.e., a personalization bureau either hosted by the operator or in a business relationship with the operator). The additional security data represents the issuer security domain keys that are later used for the actual personalization process and could be, for instance, an encryption key and/or a MAC (message authentication code) key. In step 2, the NAF server returns an authentication challenge to the EMV application and requests that the EMV application use a GAA shared secret method to authenticate itself. The EMV application on the UE then, in step 3, requests the GAA shared secret from the GBA application also located on the UE.
[0058] In step 4, the shared secret is established using the bootstrapping procedure discussed in detail above. The GBA application on the UE, a GBA_U application on the UICC, and the bootstrapping server function (BSF) server are each involved in this process. At the conclusion of this procedure keys are generated (Ks_ext_NAF and Ks_int_NAF, in the instance where GBA_U is supported by the UICC, or Ks_NAF, in the instance where it is not). Ks_int_NAF and/or Ks_ext_NAF are known to both the GBA_U application and the BSF. In the case where GBA_U is not used, the BSF knows Ks_NAF, and the NAF can request these keys from the BSF. The UE knows only Ks_ext_NAF and Ks_NAF. Once the shared secret is established, the GBA application gives the Ks_ext_NAF to the EMV application in the UE (or, in the instance where the GBA procedure only relies on the UE, then the UE already has the Ks_NAF), in step 5. In step 6, the EMV application returns a response to the NAF server's authentication challenge to the NAF server using Ks_ext_NAF or Ks_NAF.
[0059] In step 7, the NAF server fetches the NAF-specific keys (i.e., Ks_ext_NAF and Ks_int_NAF, or Ks_NAF) from the BSF server. The NAF server then verifies the authentication response, encrypts the additional security data, for example, using Ks_int_NAF or Ks_NAF, and transfers the encrypted data to the EMV application on the UE, in step 8. The EMV application, however, cannot decrypt the received data encrypted with Ks_int_NAF. Note, however, that if the data is encrypted with Ks_NAF, then the UE can decrypt it, and the UE will proceed with the installation of the security data in step 11. Assuming that the UE cannot decrypt the received data, in step 9 the EMV application hands the encrypted additional security data (i.e., the issuer security domain keys) to the EMV_U application on the UICC. The security operations in the UE may be performed in a secure environment or trusted platform.
[0060] In step 10, the EMV_U application gives the encrypted additional security data (i.e., the issuer security domain keys) to the GBA_U, since the EMV_U does not have the required Ks_int_NAF key to decrypt the message. The GBA_U application decrypts the data in step 11, and gives it back to the EMV_U application. Alternatively, in steps 10 and 11, the EMV_U application can request the Ks_int_NAF key from the GBA_U application. Upon receiving the Ks_int_NAF key, the EMV_U application can decrypt the data itself. This enables the EMV_U application on the UICC to then perform the installation of the additional security data and creation of the issuer security domain. The additional security data, e.g., keys, key lifetime, key creation time, and/or B-TID, is used to create an issuer security domain on the secure core. This issuer security domain can then be used to store application-specific security domains, such as payment application data, credit card personalization data, or the like.」
（【００４３】
　図６は，本発明の例示的な実施形態に従って動作することができるＵＥのブロック図である。ＵＥは，以下に説明されるようなＥＭＶ機能を有する，例えば携帯電話，パーソナルデジタルアシスタント（ＰＤＡ），ページャー，パーソナルコンピュータ（ＰＣ），ラップトップ，タブレット，又は他のいずれかの類似のデバイスなどのモバイルデバイスを含むことができる。図示のように，ＵＥは，少なくともセキュアコア６１０，ＵＩＣＣ（汎用ＩＣカード）６２０，ＥＭＶアプリケーション６３２，及びＧＢＡアプリケーション６３４からなることができる。セキュアコア６１０は，モバイルデバイスの中心又は最も内側の部分である必要はなく，本明細書で説明されるように機能することができるいずれかの１つ又は複数の要素を単に表わすものであって，製造中にインストールされ，生成された共有秘密鍵６１２を記憶することができるブランクチップ，並びに決済又はチケット発券のためにＵＥの使用を可能にするためにユーザによって或いはユーザに代わってインストールされた１つ又はそれ以上の決済又はチケット発券アプリケーション６１４からなることができる。
【００４４】
　ＵＩＣＣ６２０は，これが配置されるモバイルデバイスのユーザに固有の識別情報６２６を記憶するユーザ識別モジュールを含むことができる。ユーザ識別モジュールは，実際にはモジュラーである必要はない。言い換えると，ユーザ識別モジュール内に記憶されている識別情報は，１つのモジュラーエンティティの一部として記憶する必要はなく，代わりに，モバイルデバイス全体に分散されてもよい。この識別情報６２６は，ＧＡＡ手続（又は共有秘密鍵インストレーションプロセス）中に使用して，ＢＳＦサーバに対してＵＥを識別することができる。１つの実施形態では，ＵＩＣＣ６２０は更にＥＭＶ＿Ｕ６２２及びＧＢＡ＿Ｕ６２４アプリケーションを含み，これらはまた，ＵＩＣＣ６２０とＮＡＦサーバとの間にセキュアリンクを設定するために共有秘密鍵インストレーションプロセスにおいて使用される。詳細には，ＧＢＡ＿Ｕアプリケーション６２４を用いてＮＡＦ固有鍵を生成することができ，該固有鍵を用いて，モバイルネットワークオペレータとＵＩＣＣ６２０との間で共有される秘密鍵（すなわちＣＫ及びＩＫ）に基づいて，ＵＥをＮＡＦサーバに対して認証するか，或いは２つの間の通信をセキュアにすることができる。１つの実施形態では，ＵＥは，ＵＩＣＣ６２０においてＧＢＡ＿Ｕアプリケーション６２４を含まない場合がある。この場合，鍵生成及び記憶機能は，ＵＥのＧＢＡアプリケーション６３４によって行われ，ＵＩＣＣは必要な情報を配信するだけである。１つの実施形態では，ＥＭＶ＿Ｕアプリケーションは，共有秘密鍵インストレーションプロセスの進行をモニターするのに使用される状態機械を含む。この実施形態では，インストレーションプロセスが中断された場合，状態機械は，インストレーションを再開する必要があることを指示する。ＵＥがＧＢＡ＿Ｕアプリケーションを含まない場合，ＥＭＶ＿Ｕアプリケーションはまた，モバイル端末に常駐し，ＵＩＣＣには常駐しない。
【００４５】
　ＵＥに含まれるＥＭＶアプリケーション６３２は，ＵＥの外部にあるエンティティ（例えばＮＡＦ及びＢＳＦサーバ）と，ＵＩＣＣ６２０及びセキュアコア６１０との間の通信を可能にすることによって通信エンティティとして動作する。例えば，共有秘密鍵インストレーションプロセスにおいて，ＥＭＶアプリケーション６３２は，以下に詳細に説明されるように，ＮＡＦサーバに発行者セキュリティドメイン鍵を要求し，これらを解読するためにＵＩＣＣ６２０に渡し，更にこれらの鍵をセキュアコア６１０上に記憶する役割を果たす。上述のように，ＵＩＣＣ６２０内にＧＢＡ＿Ｕアプリケーション６２４が存在しない１つの実施形態では，ＵＥにあるＧＢＡアプリケーション６３４が，以下に説明される鍵生成及び記憶機能を実行する。
【００４６】
　図７Ａは，クレジットカード用にＵＥを準備する場合，或いは類似の個人化，すなわちセキュリティ及びユーザデータをＵＥに送信することができるセキュア通信チャンネルを設定するのに用いることができる発行者セキュリティドメインを作成する場合の例示的な実施形態において実行されるステップを示す信号フロー図である。第１のステップで，ＥＭＶアプリケーション（モバイル／ユーザデバイス（ＵＥ）に常駐している）は，ＮＡＦサーバ（すなわち，オペレータによってホストされるか或いはオペレータとビジネス関係にある個人化ビューロー）に付加的なセキュリティデータをリクエストする。付加的なセキュリティデータは，実際の個人化プロセスに後で使用され，例えば暗号化鍵及び／又はＭＡＣ（メッセージ認証コード）鍵とすることができる発行者セキュリティドメイン鍵を表わす。ステップ２で，ＮＡＦサーバは，認証チャレンジをＥＭＶアプリケーションに返し，ＥＭＶアプリケーションがＧＡＡ共有秘密方法を使用して自らを認証するようリクエストする。次にステップ３で，ＵＥのＥＭＶアプリケーションは，ＵＥに同様に位置付けられたＧＢＡアプリケーションにＧＡＡ共有秘密をリクエストする。
【００４７】
　ステップ４で，共有秘密は，上記に詳細に説明されたブートストラッピング手続を使用して設定される。ＵＥのＧＢＡアプリケーション，ＵＩＣＣのＧＢＡ＿Ｕアプリケーション，及びブートストラッピングサーバ機能（ＢＳＦ）サーバは各々，このプロセスに含まれる。この手続の最後で鍵が生成される（ＧＢＡ＿ＵがＵＩＣＣによってサポートされる場合，Ｋｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦ，そうでない場合はＫｓ＿ＮＡＦ）。Ｋｓ＿ｉｎｔ＿ＮＡＦ及び／又はＫｓ＿ｅｘｔ＿ＮＡＦは，ＧＢＡ＿Ｕアプリケーション及びＢＳＦの両方に既知である。ＧＢＡ＿Ｕが使用されない場合，ＢＳＦはＫｓ＿ＮＡＦを認知しており，ＮＡＦはこれらの鍵をＢＳＦにリクエストすることができる。ＵＥは，Ｋｓ＿ｅｘｔ＿ＮＡＦとＫｓ＿ＮＡＦのみを認知している。共有秘密が設定されると，ＧＢＡアプリケーションは，ステップ５で，Ｋｓ＿ｅｘｔ＿ＮＡＦをＵＥのＥＭＶアプリケーションに与える（或いは，ＧＢＡ手続がＵＥのみに依存する場合には，ＵＥは既にＫｓ＿ＮＡＦを有している）。ステップ６で，ＥＭＶアプリケーションは，Ｋｓ＿ｅｘｔ＿ＮＡＦ又はＫｓ＿ＮＡＦを使用してＮＡＦサーバの認証チャレンジへの応答をＮＡＦサーバに返す。
【００４８】
　ステップ７で，ＮＡＦサーバは，ＢＳＦサーバからＮＡＦ固有鍵（すなわちＫｓ＿ｅｘｔ＿ＮＡＦ及びＫｓ＿ｉｎｔ＿ＮＡＦ，又はＫｓ＿ＮＡＦ）をフェッチする。次いでステップ８で，ＮＡＦサーバは認証応答を検証し，例えばＫｓ＿ｉｎｔ＿ＮＡＦ又はＫｓ＿ＮＡＦを使用して付加的なセキュリティデータを暗号化し，暗号化されたデータをＵＥのＥＭＶアプリケーションに転送する。しかしながら，ＥＭＶアプリケーションは，Ｋｓ＿ｉｎｔ＿ＮＡＦで暗号化された受信データを解読することができない。一方では，データがＫｓ＿ＮＡＦで暗号化された場合には，ＵＥはこれを解読することができ，ステップ１１でセキュリティデータのインストレーションに進むことになる点に留意されたい。ＵＥが受信されたデータを解読できないと仮定すると，ステップ９で，ＥＭＶアプリケーションは，暗号化された付加的なセキュリティデータ（すなわち発行者セキュリティドメイン鍵）をＵＩＣＣ上のＥＭＶ＿Ｕアプリケーションに渡す。ＵＥでのセキュリティオペレーションは，セキュアな環境又は信頼できるプラットフォームにおいて実行することができる。
【００４９】
　ステップ１０で，ＥＭＶ＿Ｕアプリケーションは，メッセージを解読するために必要なＫｓ＿ｉｎｔ＿ＮＡＦ鍵をＥＭＶ＿Ｕが持たないので，暗号化された付加的なセキュリティデータ（すなわち発行者セキュリティドメイン鍵）をＧＢＡ＿Ｕに与える。ＧＢＡ＿Ｕアプリケーションは，ステップ１１でデータを解読し，これをＥＭＶ＿Ｕアプリケーションに返す。或いは，ステップ１０及び１１で，ＥＭＶ＿Ｕアプリケーションは，ＧＢＡ＿ＵアプリケーションにＫｓ＿ｉｎｔ＿ＮＡＦ鍵をリクエストすることができる。Ｋｓ＿ｉｎｔ＿ＮＡＦ鍵を受け取ると，ＥＭＶ＿Ｕアプリケーションは自らデータを解読することができる。これによって，ＵＩＣＣ上でのＥＭＶ＿Ｕアプリケーションが付加的なセキュリティデータのインストレーション及び発行者セキュリティドメインの作成を行うことが可能となる。付加的なセキュリティデータ，例えば鍵，鍵の有効期間，鍵生成時間，及び／又はＢ−ＴＩＤは，セキュアコア上に発行者セキュリティドメインを作成するのに使用される。次いで，この発行者セキュリティドメインを用いて，決済アプリケーションデータ，クレジットカード個人化データ，又は同様のものなどのアプリケーション固有のセキュリティドメインを記憶することができる。）
　
　上記引用の記載から，引用文献２には，概略すると，
「クレジットカードによる決済端末をパーソナライゼーションするにあたり，発行元セキュリティドメイン（ＩＳＤ）鍵セットを設定する」という技術事項が記載されている。
　
３．引用文献３について
　引用文献３には，関連する図面と共に，次の事項が記載されている。
　
Ｉ．「【００４１】図３は送信装置10および受信装置20によってそれぞれ実行される暗号化処理および復号処理の概要を鍵の働きを中心に示すものである。図４は送信装置10における暗号化処理，受信装置20における復号処理およびこれらの送，受信装置10，20間の通信処理の処理手順を示すフローチャートである。
【００４２】まず送信装置10において，操作者は入力装置11から平文を入力する，または送信装置10内において自動的に平文が作成される（他のコンピュータにおいて作成された平文を送信装置10が受信した（ＦＤなどから読み取った）場合を含む）。平文は文書データに限られることはなく，たとえばエレクトロニック・コマース（電子商取引）におけるクレジット・カード番号や暗証番号等も含まれる。入力された平文は送信装置10の内部メモリ15に一時的に記憶される。
【００４３】共通鍵生成プログラムにしたがって共通鍵が生成される。たとえば，共通鍵生成プログラムとして乱数発生プログラムを用い，乱数を発生させこれを共通鍵とする。
【００４４】生成された共通鍵は，識別子に対応して外部記憶装置18に登録（記憶）される（ステップ101 ）。ここでは識別子をｉで示し，識別子ｉに対応する共通鍵を共通鍵ｉとする。識別子は，暗号ネットワーク・システムにおける処理で用いられる鍵を同定するために用いられる。これは送信装置10と受信装置20の間で，または送信装置10もしくは受信装置20とその他の装置との間で複数の暗号文の送受信を行う場合に有効である。識別子ｉには，たとえば共通鍵が生成されるたびに増加していく，または変更される数字（共通鍵が生成されるたびに生成される乱数など），操作者が入力する文字，数字などが用いられる。複数の共通鍵をあらかじめ生成して外部記憶装置18に記憶しておき，識別子ｉが生成または入力される度に，記憶している共通鍵の１つに識別子ｉを対応させてもよい。
【００４５】つぎに共通鍵ｉを用いて共通鍵暗号化プログラムにしたがって平文が暗号化される（ステップ102 ）（これにより生成された暗号文を暗号文ｉとする）。暗号文ｉは，識別子ｉおよび第１の公開鍵／秘密鍵生成プログラムとともに，送信装置10から受信装置20に送信される（ステップ103 ）。
【００４６】受信装置20は送信装置10から送信された暗号文ｉ，識別子ｉおよび第１の公開鍵／秘密鍵生成プログラムを受信すると，受信した第１の公開鍵／秘密鍵生成プログラムを実行する。これにより第１の公開鍵と第１の秘密鍵の対が生成される（ステップ201 ）。
【００４７】生成された第１の公開鍵と第１の秘密鍵のうちの第１の秘密鍵が，識別子ｉに対応して受信装置20の外部記憶装置28に登録（記憶）される（ステップ202 ）。一方，第１の公開鍵は識別子ｉとともに送信装置10に送信される（ステップ203）。これらの識別子ｉに対応する第１の秘密鍵および第１の公開鍵を，第１の秘密鍵ｉ，第１の公開鍵ｉとする。
【００４８】第１の公開鍵ｉと識別子ｉを受信した送信装置10は，外部記憶装置18に登録された共通鍵の中から，受信した識別子ｉに対応する共通鍵ｉを検索する（ステップ104）。
【００４９】検索された共通鍵ｉが受信装置20から送信された第１の公開鍵ｉを用いて第１の公開鍵システム暗号化プログラムにしたがって暗号化される（ステップ105 ）。暗号化された共通鍵（以下，暗号化共通鍵ｉという）は識別子ｉとともに受信装置20に送信される（ステップ106 ）。
【００５０】受信装置20は外部記憶装置28に登録された第１の秘密鍵の中から，識別子ｉに対応する第１の秘密鍵ｉを検索する（ステップ204 ）。検索された第１の秘密鍵ｉは，共通鍵ｉの暗号化（ステップ105 ）に用いられた第１の公開鍵ｉと対をなすものである。
【００５１】受信装置20において，検索された第１の秘密鍵ｉを用いて第１の公開鍵システム復号プログラムにしたがって送信装置10から送信された暗号化共通鍵ｉが復号され（ステップ205 ），共通鍵ｉが得られる。続いて，復号された共通鍵ｉを用いて共通鍵復号プログラムにしたがって，先に受信した暗号文ｉが復号される（ステップ206 ）。これにより平文が得られる。
【００５２】ネットワーク10を介して送信される鍵は，暗号化共通鍵ｉおよび第１の公開鍵ｉのみであり，高い秘匿性の求められる第１の秘密鍵ｉの送信は行われない。さらに受信側では第１の秘密鍵をあらかじめ入手しておく必要がなく，暗号文の受信の度に第１の公開鍵と第１の秘密鍵の対を生成する。このため第三者による暗号文の解読は極めて困難であり，暗号化通信の安全性が高い。さらに識別子ｉを暗号化共通鍵，第１の公開鍵および第１の秘密鍵に対応させることによって，第１の公開鍵ｉを受信装置20から送信装置10に送信したときに送信装置10では，受信した第１の公開鍵で暗号化すべき共通鍵を特定することができ，暗号化共通鍵ｉを送信装置10から受信装置20に送信したときに，受信装置20では復号処理に用いるべき第１の秘密鍵および暗号化共通鍵を特定することができる。多数の暗号文の送受信が行われた場合でも，暗号化処理および復号処理を間違いなく進めることができる。
【００５３】送信装置10から受信装置20に送信される第１の公開鍵／秘密鍵生成プログラム（ステップ103 ）および暗号化共通鍵（ステップ106 ）は，送信装置10から受信装置20に送信する態様でなく，受信装置20から送信装置10にアクセスし，これら第１の公開鍵／秘密鍵生成プログラムおよび暗号化共通鍵をダウンロードする態様としてもよい。受信装置20の操作者は暗号文に付された識別子ｉにもとづいて，ダウンロードすべき暗号化共通鍵を特定することができる。これに代えて，第１の公開鍵／秘密鍵生成プログラムおよび暗号化共通鍵を送信装置10とは別のコンピュータに置かれたアクセス可能なデータベースに格納しておき，受信装置20がこのデータベースをアクセスして，第１の公開鍵／秘密鍵生成プログラムおよび暗号化共通鍵を入手するようにすることもできる。さらに，第１の公開鍵／秘密鍵生成プログラムをあらかじめ受信装置20に設けておいてもよい。
【００５４】上述の第１の実施例においては平文を共通鍵ｉを用いて暗号化し，暗号文を復号している。これに代えて，公開鍵システムにおける公開鍵を用いて平文を暗号化し，これに対応する秘密鍵を用いて暗号文を復号することもできる（これらの鍵を平文用公開鍵，平文用秘密鍵という）（後に説明する第２〜第１３実施例についてもこの変形例はあてはまる）。この場合送信装置10ではあらかじめ平文用公開鍵と平文用秘密鍵の対が生成され，生成された平文用秘密鍵が識別子ｉとともに外部記憶装置18に登録される（ステップ101 に対応）。この平文用秘密鍵（平文用秘密鍵ｉとする）に対応する平文用公開鍵（平文用公開鍵ｉとする）を用いて送信装置10において平文が暗号化される（ステップ102 に対応）。送信装置10では受信装置20から送信された第１の公開鍵ｉで平文用秘密鍵ｉが暗号化され，暗号化平文用秘密鍵ｉが識別子ｉとともに受信装置20に送信される（ステップ104〜106に対応）。受信装置20では第１の秘密鍵ｉで暗号化平文用秘密鍵ｉが復号され，復号された平文用秘密鍵ｉで暗号文が平文に復号される（ステップ204〜206 に対応）。
【００５５】平文を公開鍵（平文用公開鍵）を用いて暗号化する場合には，楕円暗号方式（アルゴリズム）を利用した暗号化プログラム（復号プログラムも）を用いるとよい。高速に平文を暗号化でき，コンピュータのメモリの使用量を少なくすることができる。
【００５６】第２実施例
第２実施例は，送信装置10および受信装置20のそれぞれがもつプログラムの種類およびそれによる動作が第１実施例と異なる。すなわち，第１実施例において送信装置10に設けられていたプログラムi)，ii) ，iii)およびiv) のうち，ii)共通鍵生成プログラムを除く，i)共通鍵暗号化プログラム，iii)第１の公開鍵システム暗号化プログラムおよびiv) 第１の公開鍵／秘密鍵生成プログラムが受信装置20に設けられている。
【００５７】図５は第２実施例の送信装置10における暗号化処理，受信装置20における復号処理，およびこれらの送，受信装置10，20間の通信処理の処理手順を示すフローチャートである。ステップ 200およびステップ 103Ａを除く処理は第１実施例（図４）と同じであるので説明を省略する。
【００５８】送信装置10から共通鍵暗号化プログラムおよび第１の公開鍵システム暗号化プログラムの送信要求があった場合，または受信装置20が送信装置10からの暗号文の送信を要求する場合には，受信装置20は，共通鍵暗号化プログラムおよび第１の公開鍵システム暗号化プログラムを送信装置10に送信する（ステップ200 ）。
【００５９】送信装置10において，共通鍵ｉを用いて共通鍵暗号化プログラムにしたがって平文が暗号化される（ステップ102 ）。送信装置10から受信装置20に，暗号文ｉおよび識別子ｉが送信される（ステップ103Ａ）。ステップ201 〜203 ，ステップ104 〜106 ，ステップ204 〜206 の処理（図４と同じ）が行われ，受信装置20に送信された暗号文が平文に復号される。
【００６０】第２実施例では，送信装置10が共通鍵暗号化プログラムおよび第１の公開鍵システム暗号化プログラムを持たない場合でも，第１実施例と同様の暗号化通信を行うことができ，しかもセキュリティを確保することができる。」
　
　上記引用の記載から，引用文献３には，概略すると，
「送信装置が，受信装置の公開鍵を用いて共通鍵を暗号化し，暗号化した共通鍵を受信装置に送信し，受信装置において暗号化した共通鍵を復号して用いる」という技術事項が記載されている。
　
第６．本願発明と引用発明との対比及び相違点についての判断
１．本願発明１について
（１）対比
ア．引用発明における「サービス提供者サーバ」，「端末」，及び，「端末製造者サーバ」が，
　本願発明１における「サーバー装置」，「クライアント装置」，及び，「ベンダー装置」にそれぞれ相当し，
　引用発明における「共通鍵ＣＫ２」は，「端末製造者サーバ」において，「端末」に書き込まれることから，
　本願発明１における「初期発行元セキュリティドメイン（ＩＳＤ）鍵セット」と，
“初期鍵である”点で共通し，
　ここで，当該「共通鍵ＣＫ２」は，引用発明において，「サービス提供サーバ」が，自らが生成した「運用鍵Ｋ」の暗号化に用い，「端末」は，「暗号化された運用鍵Ｋ」の復号に，当該「共通鍵ＣＫ２」を用いているが，このとき，当該「共通鍵ＣＫ２」を復号する操作は行っていないので，引用発明において，当該「共通鍵ＣＫ２」は，「端末製造者サーバ」において，「端末」に書き込まれるときに，暗号化されていないことは，明らかである。
　したがって，
　引用発明において，「端末製造者サーバが，・・・共通鍵ＣＫ２を生成し，共通鍵ＣＫ２を端末およびＳＡＭに書き込」むことは，
　本願発明１における「前記クライアント装置に前記初期ＩＳＤ鍵セットを提供する段階であって，前記初期ＩＳＤ鍵セットは暗号化されていない形式である，段階」と，
“クライアント装置に初期鍵を提供する段階であって，前記初期鍵は暗号化されていない形式である，段階”である点で，共通する。
　
イ．引用発明においては，「端末が，情報設定者サーバより転送された署名ＳＧ１を，端末製造者サーバにて設定された公開鍵ＰＫ１を用いて検証し」，「端末は，公開鍵ＰＫ１を用いて検証することにより，端末に設定する運用鍵Ｋがサービス提供者によって生成されたものであることを保証できる」ことから，
　引用発明における「公開鍵ＰＫ１」は，サービス提供者に関連付けられた公開鍵であるから，
　本願発明１における「前記サーバー装置に関連付けられる公開鍵」に相当し，
　引用発明における「公開鍵ＰＫ１と公開鍵ＰＫ１に対応する秘密鍵ＳＫ１を生成し，秘密鍵ＳＫ１をＳＡＭ（Secure Application Module）に書き込み，公開鍵ＰＫ１を端末に書き込」むことが，
　本願発明１における「前記クライアント装置に対して，前記サーバー装置に関連付けられる公開鍵を提供する段階」に相当する。
　
ウ．上記ア．において検討した事項から，
　引用発明において，“端末製造者サーバは，共通鍵ＣＫをＳＡＭに書き込み，前記ＳＡＭをサービス提供者に渡”していることから，
　引用発明においては，“端末製造者サーバは，共通鍵ＣＫを，サービス提供者サーバに提供する”ものであって，このことが，
　本願発明１における「前記ベンダー装置から独立して新規のＩＳＤ鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように，前記暗号化済み初期ＩＳＤ鍵セットを前記サーバー装置に提供する段階」と，
“初期鍵をサーバ装置に提供する段階”である点で共通する。
　
エ．そして，引用発明は，「サービス提供者サーバ」，「端末」，及び，「端末製造者サーバ」が関与する，「サービス提供者サーバ」と通信するよう構成されている「端末」用の「初期鍵」を事前に設定するための方法に関するものであるから，
　本願発明１における「ベンダー装置，クライアント装置及びサーバー装置が関与する，サーバー装置と通信するように構成されているクライアント装置用の初期発行元セキュリティドメイン（ＩＳＤ）鍵セットをプレパーソナライゼーションするための方法」と，
“ベンダー装置，クライアント装置及びサーバー装置が関与する，サーバー装置と通信するように構成されているクライアント装置用の初期鍵プレパーソナライゼーションするための方法”である点で共通する。
　
オ．以上，上記ア．〜エ．において検討した事項から，本願発明と，引用発明との，一致点，及び，相違点は，次のとおりである。
　
［一致点］
　ベンダー装置，クライアント装置及びサーバー装置が関与する，サーバー装置と通信するように構成されているクライアント装置用の初期鍵プレパーソナライゼーションするための方法であって，ベンダー装置において，
　クライアント装置に初期鍵を提供する段階であって，前記初期鍵は暗号化されていない形式である，段階と，
　前記クライアント装置に対して，前記サーバー装置に関連付けられる公開鍵を提供する段階と，
　初期鍵をサーバ装置に提供する段階と，
　を含む方法。
　
［相違点１］
“初期鍵”に関して，
　本願発明１においては，「クライアント装置用の初期発行元セキュリティドメイン（ＩＳＤ）鍵セット」であるのに対して，
　引用発明においては，「共通鍵ＣＫ２」である点。
　
［相違点２］
　本願発明１は，「初期ＩＳＤ鍵セットを前記公開鍵で暗号化して暗号化済み初期ＩＳＤ鍵セットを生成する段階」を有するものであるのに対して，
　引用発明は，そのような「段階」を有してない点。
　
［相違点３］
“初期鍵をサーバ装置に提供する段階”に関して
　本願発明１においては，「ベンダー装置から独立して新規のＩＳＤ鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように，前記暗号化済み初期ＩＳＤ鍵セットを前記サーバー装置に提供する段階」であるのに対して，
　引用発明においては，「サービス提供者サーバ」に，「共通鍵ＣＫ２」を提供する段階である点。
　
［相違点４］
　本願発明１においては，「クライアント装置において，前記新規のＩＳＤ鍵セットを確立するために，前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のＩＳＤ鍵セットを生成し，前記サーバー装置へ提供される暗号化済みの新規のＩＳＤ鍵セットを提供するために前記公開鍵を用いて前記新規のＩＳＤ鍵セットを暗号化する，段階」を有するものであるのに対して，
　引用発明は，そのような「段階」を有していない点。
　
（２）相違点についての当審の判断
　事案に鑑みて，上記［相違点４］について先に検討すると，［相違点４］に係る本願発明１の構成は，上記引用文献１〜引用文献３には記載されておらず，本願の優先日前において周知技術であるともいえない。
　したがって，他の相違点について判断するまでもなく，本願発明１は，当業者であっても引用発明，引用文献２，及び，引用文献３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
２．本願発明２〜本願発明７について
　本願の請求項２〜本願の請求項７は，本願の請求項１を直接・間接に引用するものであるから，本願発明２〜本願発明７は，上記「１．本願発明１について」の「（２）相違点についての当審の判断」において検討した，［相違点４］に係る構成を有するものである。
　したがって，本願発明２〜本願発明７は，当業者であっても引用発明，引用文献２，及び，引用文献３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
３．本願発明８〜本願発明１２について
　本願発明８は，上記「１．本願発明１について」の「（２）相違点についての当審の判断」において検討した，［相違点４］に係る構成を有するものである。
　そして，本願の請求項９〜本願の請求項１２は，本願の請求項８を直接・間接に引用するものであるから，本願発明９〜本願発明１２は，本願発明８と同じく，上記「１．本願発明１について」の「（２）相違点についての当審の判断」において検討した
成を有するものである。
　したがって，本願発明８〜本願発明１２は，当業者であっても引用発明，引用文献２，及び，引用文献３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
４．本願発明１３〜本願発明２０について
　本願発明１３は，上記「１．本願発明１について」の「（２）相違点についての当審の判断」において検討した，［相違点４］に係る構成を有するものである。
　そして，本願の請求項１４〜本願の請求項２０は，本願の請求項１３を直接・間接に引用するものであるから，本願発明１４〜本願発明２０は，本願発明１３と同じく，上記「１．本願発明１について」の「（２）相違点についての当審の判断」において検討した，［相違点４］に係る構成を有するものである。
　したがって，本願発明１３〜本願発明２０は，当業者であっても引用発明，引用文献２，及び，引用文献３に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。
　
第７．原審拒絶査定についての判断
　本件手続補正により，本願発明１〜本願発明２０は，［相違点４］に係る構成を有するものとなっており，当業者であっても，原審拒絶査定において引用された引用文献１〜引用文献３に基づいて，容易に発明できたものとはいえない。したがって，原審拒絶査定の理由を維持することはできない。
　
第８．当審拒絶理由について
　記載不備に関する，当審拒絶理由は，令和１年１２月１３日付けの手続補正によって解消した。
　
第９．むすび
　以上のとおり，本願発明１〜本願発明２０は，当業者が引用発明，引用文献２，及び，引用文献３に記載された技術的事項に基づいて容易に発明をすることができたものではない。
　したがって，原審拒絶査定の理由によっては，本願を拒絶することはできない。
　また，他に本願を拒絶すべき理由を発見しない。
　
　よって，結論のとおり審決する。