• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 H04L
審判 査定不服 2項進歩性 取り消して特許、登録 H04L
管理番号 1360100
審判番号 不服2019-1763  
総通号数 244 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2020-04-24 
種別 拒絶査定不服の審決 
審判請求日 2019-02-07 
確定日 2020-03-16 
事件の表示 特願2016-133919「グローバルプラットフォーム仕様を使用した発行元セキュリティドメインの鍵管理のためのシステム及び方法」拒絶査定不服審判事件〔平成28年10月13日出願公開,特開2016-181936,請求項の数(20)〕について,次のとおり審決する。 
結論 原査定を取り消す。 本願の発明は,特許すべきものとする。 
理由 第1.手続の経緯
第1.手続の経緯
本願は,2012年9月28日(パリ条約による優先権主張外国庁受理2011年12月20日 アメリカ合衆国)を国際出願日とする特願2014-549034号の一部を,特許法44条1項の規定により,平成28年7月6日に新たな特許出願としたものであって,
平成28年8月4日付けで審査請求がなされると共に手続補正がなされ,平成29年10月27日付けで審査官により拒絶理由が通知され,これに対して平成30年5月2日付けで意見書が提出されると共に手続補正がなされたが,平成30年9月28日付けで審査官により拒絶査定がなされ(謄本送達;平成30年10月9日),これに対して平成31年2月7日付けで審判請求がなされると共に手続補正がなされ,平成31年2月28日付けで審査官により特許法164条3項の規定に基づく報告がなされ,令和1年9月30日付けで当審により拒絶理由が通知され,これに対して令和1年12月13日付けで意見書が提出されると共に手続補正がなされたものである。

第2 原審拒絶査定の概要
原審における平成30年9月28日付け拒絶査定(以下,これを「原審拒絶査定」という)の概要は次のとおりである。

本願の請求項1?本願の請求項10,本願の請求項13?本願の請求項16,本願の請求項19,及び,本願の請求項20に係る発明は,以下の引用文献1?引用文献3に基づいて,その発明の属する技術の分野における通常の知識を有する者(以下,「当業者」という。)が容易に発明できたものであるから,特許法第29条第2項の規定により特許を受けることができない。

引用文献等一覧
1.特開2009-060528号公報
2.米国特許出願公開第2006/0196931号明細書
3.特開平11-168460号公報

第3 当審拒絶理由の概要
当審における令和1年9月30日付けの拒絶理由(以下,これを「当審拒絶理由」という)の概要は次のとおりである。

本件出願は,特許請求の範囲の記載が下記の点で不備のため,特許法36条6項2号に規定する要件を満たしていない。



1.本願の請求項1に,
「ベンダー装置において,
前記クライアント装置に前記初期ISD鍵セットを提供する段階であって,前記初期ISD鍵セットは暗号化されていない形式である,段階と,
前記クライアント装置に対して,前記サーバー装置に関連付けられる公開鍵を提供する段階と,
前記初期ISD鍵セットを前記公開鍵で暗号化して暗号化済み初期ISD鍵セットを生成する段階と,
前記ベンダー装置から独立して新規のISD鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように,前記暗号化済み初期ISD鍵セットを前記サーバー装置に提供する段階であって,前記新規のISD鍵セットを確立するために前記クライアント装置が,前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のISD鍵セットを生成し,前記サーバー装置へ提供される暗号化済みの新規のISD鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する,段階と,
を含む」
と記載され,上記引用の記載からは,上記引用記載が「ベンダー装置において」で始まることから,上記引用記載中の各「段階」は,「ベンダー装置」に関するものであるかのように見える。
しかしながら,上記引用記載中の,
「新規のISD鍵セットを確立するために前記クライアント装置が,前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のISD鍵セットを生成し,前記サーバー装置へ提供される暗号化済みの新規のISD鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する,段階」は,
「クライアント装置」の処理を示すものと解されるので,各「段階」の処理主体が何で,全体としてどのような構成を表現しようとしているのか,本願の請求項1に記載の内容からは,不明である。
(請求項1は,「方法」に関するクレームであって,各「段階」は,当該「方法」が,どのような過程を経るかを表現するものであるから,当該「段階」の処理主体が,明確になるような表現を検討されたい。)

2.本願の請求項1の上記1.において引用した記載中の,
「サーバー装置から受信した初期化スクリプトに基づいて前記新規のISD鍵セットを生成し,前記サーバー装置へ提供される暗号化済みの新規のISD鍵セットを生成するために前記公開鍵を用いて前記新規の鍵セットを暗号化する」,
において,「ISD鍵セット生成し,・・・ISD鍵セットを生成するために」における後半の「ISD鍵セットを生成するため」の処理が「鍵セットの暗号化」なので,「ISD鍵の生成」と対応していない。(後半は,“ISD鍵セットを提供するために”ではないのか?,また,「新規の鍵セット」は,「新規のISD鍵セット」である。)
(以下省略)

第4.本願発明について
本願の請求項1?本願の請求項20に係る発明(以下,これを「本願発明1?本願発明20」という)は,令和1年12月13日付けの手続補正(以下,これを「本件手続補正」という)により補正された特許請求の範囲の請求項1?請求項20に記載された事項により特定されるものであり,そのうち,本願発明1は,次のとおりのものである。

「ベンダー装置,クライアント装置及びサーバー装置が関与する,サーバー装置と通信するように構成されているクライアント装置用の初期発行元セキュリティドメイン(ISD)鍵セットをプレパーソナライゼーションするための方法であって,前記ベンダー装置において,
前記クライアント装置に前記初期ISD鍵セットを提供する段階であって,前記初期ISD鍵セットは暗号化されていない形式である,段階と,
前記クライアント装置に対して,前記サーバー装置に関連付けられる公開鍵を提供する段階と,
前記初期ISD鍵セットを前記公開鍵で暗号化して暗号化済み初期ISD鍵セットを生成する段階と,
前記ベンダー装置から独立して新規のISD鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように,前記暗号化済み初期ISD鍵セットを前記サーバー装置に提供する段階と,
前記クライアント装置において,前記新規のISD鍵セットを確立するために,前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のISD鍵セットを生成し,前記サーバー装置へ提供される暗号化済みの新規のISD鍵セットを提供するために前記公開鍵を用いて前記新規のISD鍵セットを暗号化する,段階と,
を含む方法。」

第5.引用文献に記載の事項及び引用文献に記載の発明
1.引用文献1について
(1)記載の事項
引用文献1には,関連する図面と共に,次の事項が記載されている。

A.「【0009】
本発明の鍵設定方法は,前記暗号操作装置として,SAM(Secure Application Module)を用いる。」

B.「【0017】
図1および図2に示すように,本実施の形態の鍵設定システムは,端末2およびSAM4を製造して提供する端末製造者の端末製造者サーバ5と,端末2を用いてサービスを提供するサービス提供者のサービス提供者サーバ3と,端末1に情報を設定する情報設定者の情報設定者サーバ1とが存在する。情報設定者は,例えば,端末製造者やサービス提供者が合意した特定の信頼機関等,契約により独立性の保障された機関や,端末の運用を管理する者等である。なお,情報設定者は,サービス提供者および端末製造者とは異なる。」

C.「【0020】
図1および図2を参照しながら,本実施の形態の鍵設定方法の手順について説明する。
まず,端末製造者サーバ5は,公開鍵PK1と,公開鍵PK1に対応する秘密鍵SK1を生成する(S10)。端末製造者サーバ5は,秘密鍵SK1をSAM4に書き込み(S12),公開鍵PK1を端末2に書き込む(S14)。SAM4は,端末製造者サーバ5から転送された秘密鍵SK1を実装する(S16)。端末2は,端末製造者サーバ5から転送された公開鍵PK1を実装する(S18)。
【0021】
端末製造者サーバ5は,共通鍵CK2を生成する(S20)。端末製造者サーバ5は,共通鍵CK2を端末2およびSAM4に書き込む(S22,S24)。端末2およびSAM4は,端末製造者サーバ5から転送された共通鍵CK2を実装する(S26,S28)。
【0022】
次に,端末製造者は,鍵を設定したSAM4をサービス提供者に渡し,鍵を設定した端末2を情報設定者に渡す。
【0023】
サービス提供者サーバ3は,サービスに係るアプリケーションの実行に必要な運用鍵Kを生成する(S30)。サービス提供者サーバ3は,生成した運用鍵KをSAM4に書き込む(S32)。
【0024】
SAM4は,サービス提供者サーバ3から書き込まれた運用鍵Kを共通鍵CK2を用いて暗号化し,暗号化運用鍵E[CK2,K]を生成する(S34)。また,SAM4は,秘密鍵SK1を用いて,暗号化運用鍵E[CK2,K]に署名SG1を付与する(S36)。SAM4は,署名SG1が付された暗号化運用鍵E[CK2,K]をサービス提供者サーバ3に出力する(S38)。
【0025】
サービス提供者サーバ3は,SAM4から取得した署名SG1が付された暗号化運用鍵E[CK2,K]を,情報設定者サーバ1に送信する(S40)。
【0026】
情報設定者サーバ1は,サービス提供者サーバ3から受け取った署名SG1が付された暗号化運用鍵E[CK2,K]を,端末2に転送する(S42)。
【0027】
端末2は,情報設定者サーバ1より転送された署名SG1を,端末製造者サーバ5にて設定された公開鍵PK1を用いて検証する(S44)。検証に成功すると,暗号化運用鍵E[CK2,K]を共通鍵CK2で復号し,運用鍵Kを取得する(S46)。端末2は,取り出した運用鍵Kを端末2に設定し,運用開始可能な状態になる(S48)。
以上,本実施の形態の鍵設定方法について説明した。」

D.「【0029】
端末製造者サーバ5が生成した秘密鍵SK1をSAM4に,公開鍵PK1を端末2に設定し,サービス提供者サーバ3はSAM4内の秘密鍵SK1を用いて暗号化運用鍵E[CK2,K]の署名SG1を取得する。情報設定者サーバ1は,サービス提供者サーバ3から受け取った署名SG1を端末2に転送し,端末2は,公開鍵PK1を用いて検証することにより,端末2に設定する運用鍵Kがサービス提供者によって生成されたものであることを保証できる。」

(2)記載の発明
上記「(1)記載の事項」に引用した,引用文献1に記載の内容から,引用文献1には,次の発明(以下,これを「引用発明」という)が記載されているものと認める。

「端末製造者サーバが,公開鍵PK1と公開鍵PK1に対応する秘密鍵SK1を生成し,秘密鍵SK1をSAM(Secure Application Module)に書き込み,公開鍵PK1を端末に書き込み,共通鍵CK2を生成し,共通鍵CK2を端末およびSAMに書き込み,
端末製造者が,鍵を設定したSAMをサービス提供者に渡し,鍵を設定した端末を情報設定者に渡し,
サービス提供者サーバが,サービスに係るアプリケーションの実行に必要な運用鍵Kを生成し,生成した運用鍵KをSAMに書き込み,
SAMが,サービス提供者サーバから書き込まれた運用鍵Kを共通鍵CK2を用いて暗号化し,暗号化運用鍵E[CK2,K]を生成し,秘密鍵SK1を用いて,暗号化運用鍵E[CK2,K]に署名SG1を付与し,署名SG1が付された暗号化運用鍵E[CK2,K]をサービス提供者サーバに出力し,
サービス提供者サーバが,SAMから取得した署名SG1が付された暗号化運用鍵E[CK2,K]を,情報設定者サーバに送信し,
情報設定者サーバが,サービス提供者サーバから受け取った署名SG1が付された暗号化運用鍵E[CK2,K]を,端末に転送し,
端末が,情報設定者サーバより転送された署名SG1を,端末製造者サーバにて設定された公開鍵PK1を用いて検証し,検証に成功すると,暗号化運用鍵E[CK2,K]を共通鍵CK2で復号し,運用鍵Kを取得し,取り出した運用鍵Kを端末に設定し,運用開始可能な状態になり,
端末は,公開鍵PK1を用いて検証することにより,端末に設定する運用鍵Kがサービス提供者によって生成されたものであることを保証でき,
端末として,クレジットカードによる決済端末を用いる,
鍵設定方法。」

2.引用文献2について
引用文献2には,関連する図面と共に,次の事項が記載されている。

E.「[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.」
(【0002】
MasterCard及びVisaなどのクレジットカード会社は,現在のところクレジットカード個人化を行うためにEMV(Europay,Mastercard,及びVisa)クレジットカード決済規格を利用することに成功している。クレジットカード個人化とは,EMVチップを含むスマートカードなどのユーザのクレジットカードにセキュリティ及びユーザデータが送信されるプロセスのことを指す。この個人化プロセスの最初のステップは,発行者セキュリティドメインを設定する段階であり,現在では通常スマートカード製造業者の工場で行われる。セキュリティドメインは,アプリケーションデータのダウンロード及び実際の個人化を行うのに使用される個人化デバイスと,クレジットカードに埋め込まれたEMVチップとの間でセキュアチャンネルを作成するのに使用される。セキュアチャンネルは,公的に容易に入手可能ではない状態で情報を送信することができるあらゆるチャンネルであり,例えば,種々の暗号化方式を使用して或いはチャンネルのエンドポイント両方を認証することによって作成することができる。セキュアチャンネルが作成されると,個人化デバイスはEMVチップを起動し,最終的には個人化データをEMVチップに送信することができる。クレジットカード会社は,この個人化プロセスを行うためにOrga,Axalto,Giesecke及びDevrient,又はCedexなどのスマートカード製造業者に頼ることが多い。これらの製造業者は,ユーザ固有のデータを各クレジットカードに埋め込むために,必要とされるユーザ個人化データをクレジットカード会社から受け取り,以下に説明されるステップを行う。このように,スマートカード製造業者は,クレジットカード会社に代わってクレジットカード発行者として役割を果たすことができる。<対応する日本語公報である,特表2008-537370号公報より引用。以下,同じ。>)

F.「[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.」
(【0006】
最近では,MasterCard及びVisaなどの会社が,例えばPayPass又はVisa Waverとして知られる新しい決済方法を導入しており,RFID(無線識別)機能を有するクレジットカードが製造されている。この新しい方法では,RFIDデバイスが小売店に備え付けられ,該RFIDデバイスは,ユーザが読取装置の数センチメートル手前に自分のカードを置くと,これらのRFID対応クレジットカードを読み取ることができる。この新しい方法によってクレジットカードの決済がより早くより簡単になる。類似の近接RFIDシステムは,Octopus(オクトパス)又はヘルシンキ公共交通などの公共交通システムでも使用されている。例えば,RFID機能を含むプリペイドのバス又は列車のカードが顧客によって購入され,バス停又は列車の駅にあるRFID読取装置と共に使用して,バス又は列車に乗るためのチケットを購入することができる。
【0007】
種々のベンダーロケーション,並びに種々の公共交通ステーションでのRFID読取装置の使用は,これらの販売時点情報管理(POS)RFID読取装置を利用できる他のタイプの決済方法の機会を与える。このような1つの決済方法によって,個人が自分の携帯電話或いは携帯電話又はPDAに接続(例えば,ブルートゥース,ケーブル,RFID,又は赤外線を介して)されているパーソナルデジタルアシスタント(PDA)又はモバイルパーソナルコンピュータ(PC)などのある他のモバイルデバイスを使用して,クレジットカード又は他のユーザ固有の情報を転送することが可能になる。言い換えると,個人が,自分のクレジットカード又はプリペイド公共交通カードを使用する場合と同じ状況で自分の携帯電話を使用することができるようになる。例えば,ユーザの個人クレジットカードの詳細をモバイルデバイスに組み込み,POS RFID読取装置に送信することができるようになる。例えば,PayPass及びVisaWaveに使用されるのと同じプロトコルを使用することができる。この場合,モバイルデバイスは,PCに接続されることになり,PCは,モバイルデバイスに必要なデータを要求し,次いで,このデータをPOSに(インターネットを介して)転送することになる。
【0008】
このモバイルEMVシステムを実施するために,最初にシステム全体を証明する必要がある。EMV証明は,EMV発行者として役割を果たすことを意図する全てのスマートカード発行者が従う必要のある,EMVによって定められた高価な手続である。証明なしでは,クレジットカード会社は,内包する固有リスクを受け入れてモバイルEMVソリューションを会社の決済インフラストラクチャに「接続する」可能性は低い。しかしながら,モバイルデバイスは,付加的なソフトウェアアプリケーションを実行しスマートカードよりも多くの外部インターフェースを有することができるので,スマートカードよりも遙かにオープンである。この結果,既存のモバイルデバイスハードウェア上で構築されたモバイルEMVソフトウェアアプリケーションは,EMV証明を取得しようとする場合に重大な問題に直面する可能性があり,従って,必要な証明の取得が非常に困難で費用のかかるものになる。
【0009】
1つの代替の解決策は,既存のモバイルデバイスハードウェア上にモバイルEMVソフトウェアアプリケーションを構築するのではなく,既に証明済みのEMVチップ又はスマートカードをモバイルデバイスに組み込むことである。これを行うための1つの選択肢は,第2のスロットをモバイルデバイスに取り入れることであり,この場合,EMVチップは,例えばスマートカード製造業者で通常通り個人化し,次いで,後でユーザによってモバイルデバイスに挿入することができる。しかしながら,この方法も大量市場に対するモバイルデバイスのハードウェアコストが追加されることに起因して,極めて高価になる可能性がある。他の選択肢は,多くのアプリケーションをサポートする汎用ICカード(UICC)をモバイルデバイスに組み込むか,或いは,証明済みのEMVチップをモバイルデバイスの製造中にデバイスに埋め込むかのいずれかになる。
【0010】
しかしながら,製造中には,最終的に誰が各モバイルデバイスを所有するかが分からず,従って,通常の製造プロセス中にあらゆる決済データが完全に個人化されるのが阻止される。これは,カードの受取人がカードの発行中に既知である今日のクレジットカードビジネスとは相違する。1つの解決策は,クレジットカードに関して上述されたのと類似の方法で,製造中にモバイルデバイスにUICCを組み込むか或いは証明済みEMVチップを埋め込み,次いで,ユーザがスマートカード製造業者又は個人化ビューローに自分のモバイルデバイスを送ることを必要とし,そこで個人化を行うことができるようにすることである。しかしながら,これには,ユーザがある時間期間の間自分のモバイルデバイスをスマートカード製造業者に明け渡すことが必要になる。別の解決策では,ユーザがクレジットカードを申し込むのと同じ方法でクレジットカード機能を有する電話を申し込むことが必要である。次いで,クレジットカード機能を有する完全に個人化されたモバイルデバイスは,直接ユーザに送られることになる。しかしながら,これらの選択肢では,既存の製造プロセス及び販売網を変更することが必要になり,これらは,高コストで時間がかかることになる。
【0011】
別の解決策は,ユーザが自分のモバイルデバイスを購入した後で,無線(OTA)で個人化を行うことである。しかしながら,セキュリティデータのOTA送信には一定のリスクが内在する。上述のように,個人化プロセスを開始する前に,個人化デバイスとEMVチップ又はUICCとの間のセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成する必要がある。従って,モバイルデバイスにOTAでクレジットカード個人化データを送信する安全な手段,すなわち必要な発行者セキュリティドメイン及びセキュアチャンネルを作成する手段に対するニーズがある。
【発明の開示】
【0012】
一般的に言えば,本発明の例示的な実施形態は,クレジットカード個人化又は公共交通チケット発券データなどの個人化データを無線(OTA)で送信することができるセキュアチャンネルの設定のための発行者セキュリティドメインを作成する方法を提供することによって,公知の従来技術に対して改善をもたらす。詳細には,例示的な実施形態では,汎用認証アーキテクチャ(GAA)を使用して,ユーザ装置(UE)とネットワークアプリケーション機能(NAF)サーバとして働く個人化アプリケーションサーバ又はビューローとの間のセキュア通信チャンネルを作成するのに使用することができる共有秘密を設定することができる。
【0013】
一般に,本明細書で使用されるユーザ装置とは,ユーザ装置のユーザによってリクエストされた商品又はサービスに課金する機能を組み込んだモバイルデバイス(例えば,セルラー電話,パーソナルデジタルアシスタント(PDA),ラップトップ,ページャーなど)を指す。例えばユーザ装置は,モバイルデバイスに埋め込まれたEMV証明済みチップ,或いはモバイルデバイスに関連したUICC又はスマートカードに記憶された1つ又はそれ以上のEMVアプリケーションのいずれかを介してEMV機能を有するモバイルデバイスを意味することができる。1つの例示的な実施形態では,EMVアプリケーションは,ネットワークオペレータのUICC又はスマートカード上に記憶することができる。或いは,1つ又はそれ以上のEMVアプリケーションを含む別個のEMV固有UICC又はスマートカードを提供することができる。この実施形態では,モバイルデバイスは,それぞれのUICC(すなわち,ネットワークオペレータUICCとEMV固有のUICC)に対して2つのスロットを含み,EMV固有のUICC又はスマートカードは,取り除くことができ,2つのスロットを所有する別のモバイルデバイスと共に使用することができる。このようにしてユーザは,EMV固有のUICC又はスマートカードをモバイルデバイスに挿入することによって異なるモバイルデバイス(例えばユーザ自身の,並びにユーザの母親,父親,姉妹などの)をクレジットカード又は公共交通チケット発券カードとして簡単に使用することができる。
【0014】
例示的な実施形態において,セキュアチャンネルを介して個人化データを受信することができるユーザ装置,セキュアチャンネルを介して個人化データを送信することができる個人化アプリケーションサーバ(例えばGAAが使用されているNAFサーバ),及びこのユーザ装置と個人化アプリケーションサーバを実現するシステムもまた備えられる。
【0015】
従って本発明の1つの態様によれば,個人化アプリケーションサーバからユーザ装置への個人化データの無線(OTA)送信のためのセキュアチャンネルを設定するのに使用することができる発行者セキュリティドメインを作成するための方法が提供される。1つの例示的な実施形態では,本方法は,(1)ユーザ装置及び個人化アプリケーションサーバに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と,(2)1つ又はそれ以上の共有秘密鍵を使用して発行者セキュリティドメインを作成する段階とを含み,ここで発行者セキュリティドメインは,個人化アプリケーションサーバからユーザ装置への個人化データのOTA送信のためのセキュアチャンネルを設定するのに使用することができる。
【0016】
本発明の別の態様によれば,第1エンティティから第2エンティティにセキュアな方法で個人化データをOTAで送信する方法が提供される。1つの例示的な実施形態では,本方法は,(1)汎用認証アーキテクチャ(GAA)を使用して第1及び第2エンティティに既知の1つ又はそれ以上の共有秘密鍵を生成する段階と,(2)1つ又はそれ以上の共有秘密鍵を使用して第1と第2エンティティとの間に発行者セキュリティドメインを作成する段階と,(3)発行者セキュリティドメインを使用して第1と第2エンティティとの間にセキュアチャンネルを設定する段階と,(4)セキュアチャンネルを介して個人化データを送信する段階とを含む。)

G.「[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.」
(【0029】
図3は,汎用ブートストラッピングのための例示的なネットワークモデルを示す。図に示すように,ブートストラッピングサーバ機能(BSF)60は,双方向リンクを介してユーザ装置(UE)40に接続されている。BSF60及びUE40は,AKAプロトコルを使用して相互に認証し,セッション鍵に合意することができる。これらのセッション鍵は,後で,ユーザ装置とネットワークアプリケーション機能(NAF)サーバ70との間のセッションに使用することができ,該サーバは,双方向リンクによってユーザ装置40及びBSF60に接続されている。1つの例示的な実施形態では,NAFサーバ70は,オペレータのシステム内に含まれる。或いは,NAFサーバ70は単に,セキュリティクレデンシャルサービスを提供するためにオペレータと契約することができる。サードパーティネットワークの場合には,アーキテクチャは,図示されていないが「Generic Authentication Architecture(GAA:汎用認証アーキテクチャ);Generic Bootstrapping Architecture(汎用ブートストラッピングアーキテクチャ)」(2005年6月7日発行)(3GPP TS33.220v7.0.0(2005-06))(以下「TS33.220」)と題された3GPP技術仕様33.220に説明されるようなDiameter(ダイアメータ)-プロキシ(D-プロキシ)を含むことができ,この内容は,引用により全体が本明細書に組み込まれ,www.3gpp.orgで見ることができる。
【0030】
以下に詳細に説明されるブートストラッピング手続の後で,ユーザ装置40及びNAF70は,例えばクレジットカード個人化又は公共交通チケット発券アプリケーションであるアプリケーション固有プロトコルを実行することができ,ここでは,メッセージの認証及び機密保護が相互認証の間に生成されたセッション鍵に基づくことになる。従って,GAA/GBA22は,一般的に,3パーティ認証ケースとして見なすことができ,BSF60は更に,例えばGBAユーザセキュリティ設定(GUSS)を記憶するHSS30又はHLRに接続される。幾つかのHSSが存在する場合には,BSFとHSSとの間の接続はSLF(サーバロケーション機能)を利用でき,これによってBSFは,適切なユーザデータを記憶するHSSを見つけることができる。)

H.「[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.」
(【0043】
図6は,本発明の例示的な実施形態に従って動作することができるUEのブロック図である。UEは,以下に説明されるようなEMV機能を有する,例えば携帯電話,パーソナルデジタルアシスタント(PDA),ページャー,パーソナルコンピュータ(PC),ラップトップ,タブレット,又は他のいずれかの類似のデバイスなどのモバイルデバイスを含むことができる。図示のように,UEは,少なくともセキュアコア610,UICC(汎用ICカード)620,EMVアプリケーション632,及びGBAアプリケーション634からなることができる。セキュアコア610は,モバイルデバイスの中心又は最も内側の部分である必要はなく,本明細書で説明されるように機能することができるいずれかの1つ又は複数の要素を単に表わすものであって,製造中にインストールされ,生成された共有秘密鍵612を記憶することができるブランクチップ,並びに決済又はチケット発券のためにUEの使用を可能にするためにユーザによって或いはユーザに代わってインストールされた1つ又はそれ以上の決済又はチケット発券アプリケーション614からなることができる。
【0044】
UICC620は,これが配置されるモバイルデバイスのユーザに固有の識別情報626を記憶するユーザ識別モジュールを含むことができる。ユーザ識別モジュールは,実際にはモジュラーである必要はない。言い換えると,ユーザ識別モジュール内に記憶されている識別情報は,1つのモジュラーエンティティの一部として記憶する必要はなく,代わりに,モバイルデバイス全体に分散されてもよい。この識別情報626は,GAA手続(又は共有秘密鍵インストレーションプロセス)中に使用して,BSFサーバに対してUEを識別することができる。1つの実施形態では,UICC620は更にEMV_U622及びGBA_U624アプリケーションを含み,これらはまた,UICC620とNAFサーバとの間にセキュアリンクを設定するために共有秘密鍵インストレーションプロセスにおいて使用される。詳細には,GBA_Uアプリケーション624を用いてNAF固有鍵を生成することができ,該固有鍵を用いて,モバイルネットワークオペレータとUICC620との間で共有される秘密鍵(すなわちCK及びIK)に基づいて,UEをNAFサーバに対して認証するか,或いは2つの間の通信をセキュアにすることができる。1つの実施形態では,UEは,UICC620においてGBA_Uアプリケーション624を含まない場合がある。この場合,鍵生成及び記憶機能は,UEのGBAアプリケーション634によって行われ,UICCは必要な情報を配信するだけである。1つの実施形態では,EMV_Uアプリケーションは,共有秘密鍵インストレーションプロセスの進行をモニターするのに使用される状態機械を含む。この実施形態では,インストレーションプロセスが中断された場合,状態機械は,インストレーションを再開する必要があることを指示する。UEがGBA_Uアプリケーションを含まない場合,EMV_Uアプリケーションはまた,モバイル端末に常駐し,UICCには常駐しない。
【0045】
UEに含まれるEMVアプリケーション632は,UEの外部にあるエンティティ(例えばNAF及びBSFサーバ)と,UICC620及びセキュアコア610との間の通信を可能にすることによって通信エンティティとして動作する。例えば,共有秘密鍵インストレーションプロセスにおいて,EMVアプリケーション632は,以下に詳細に説明されるように,NAFサーバに発行者セキュリティドメイン鍵を要求し,これらを解読するためにUICC620に渡し,更にこれらの鍵をセキュアコア610上に記憶する役割を果たす。上述のように,UICC620内にGBA_Uアプリケーション624が存在しない1つの実施形態では,UEにあるGBAアプリケーション634が,以下に説明される鍵生成及び記憶機能を実行する。
【0046】
図7Aは,クレジットカード用にUEを準備する場合,或いは類似の個人化,すなわちセキュリティ及びユーザデータをUEに送信することができるセキュア通信チャンネルを設定するのに用いることができる発行者セキュリティドメインを作成する場合の例示的な実施形態において実行されるステップを示す信号フロー図である。第1のステップで,EMVアプリケーション(モバイル/ユーザデバイス(UE)に常駐している)は,NAFサーバ(すなわち,オペレータによってホストされるか或いはオペレータとビジネス関係にある個人化ビューロー)に付加的なセキュリティデータをリクエストする。付加的なセキュリティデータは,実際の個人化プロセスに後で使用され,例えば暗号化鍵及び/又はMAC(メッセージ認証コード)鍵とすることができる発行者セキュリティドメイン鍵を表わす。ステップ2で,NAFサーバは,認証チャレンジをEMVアプリケーションに返し,EMVアプリケーションがGAA共有秘密方法を使用して自らを認証するようリクエストする。次にステップ3で,UEのEMVアプリケーションは,UEに同様に位置付けられたGBAアプリケーションにGAA共有秘密をリクエストする。
【0047】
ステップ4で,共有秘密は,上記に詳細に説明されたブートストラッピング手続を使用して設定される。UEのGBAアプリケーション,UICCのGBA_Uアプリケーション,及びブートストラッピングサーバ機能(BSF)サーバは各々,このプロセスに含まれる。この手続の最後で鍵が生成される(GBA_UがUICCによってサポートされる場合,Ks_ext_NAF及びKs_int_NAF,そうでない場合はKs_NAF)。Ks_int_NAF及び/又はKs_ext_NAFは,GBA_Uアプリケーション及びBSFの両方に既知である。GBA_Uが使用されない場合,BSFはKs_NAFを認知しており,NAFはこれらの鍵をBSFにリクエストすることができる。UEは,Ks_ext_NAFとKs_NAFのみを認知している。共有秘密が設定されると,GBAアプリケーションは,ステップ5で,Ks_ext_NAFをUEのEMVアプリケーションに与える(或いは,GBA手続がUEのみに依存する場合には,UEは既にKs_NAFを有している)。ステップ6で,EMVアプリケーションは,Ks_ext_NAF又はKs_NAFを使用してNAFサーバの認証チャレンジへの応答をNAFサーバに返す。
【0048】
ステップ7で,NAFサーバは,BSFサーバからNAF固有鍵(すなわちKs_ext_NAF及びKs_int_NAF,又はKs_NAF)をフェッチする。次いでステップ8で,NAFサーバは認証応答を検証し,例えばKs_int_NAF又はKs_NAFを使用して付加的なセキュリティデータを暗号化し,暗号化されたデータをUEのEMVアプリケーションに転送する。しかしながら,EMVアプリケーションは,Ks_int_NAFで暗号化された受信データを解読することができない。一方では,データがKs_NAFで暗号化された場合には,UEはこれを解読することができ,ステップ11でセキュリティデータのインストレーションに進むことになる点に留意されたい。UEが受信されたデータを解読できないと仮定すると,ステップ9で,EMVアプリケーションは,暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をUICC上のEMV_Uアプリケーションに渡す。UEでのセキュリティオペレーションは,セキュアな環境又は信頼できるプラットフォームにおいて実行することができる。
【0049】
ステップ10で,EMV_Uアプリケーションは,メッセージを解読するために必要なKs_int_NAF鍵をEMV_Uが持たないので,暗号化された付加的なセキュリティデータ(すなわち発行者セキュリティドメイン鍵)をGBA_Uに与える。GBA_Uアプリケーションは,ステップ11でデータを解読し,これをEMV_Uアプリケーションに返す。或いは,ステップ10及び11で,EMV_Uアプリケーションは,GBA_UアプリケーションにKs_int_NAF鍵をリクエストすることができる。Ks_int_NAF鍵を受け取ると,EMV_Uアプリケーションは自らデータを解読することができる。これによって,UICC上でのEMV_Uアプリケーションが付加的なセキュリティデータのインストレーション及び発行者セキュリティドメインの作成を行うことが可能となる。付加的なセキュリティデータ,例えば鍵,鍵の有効期間,鍵生成時間,及び/又はB-TIDは,セキュアコア上に発行者セキュリティドメインを作成するのに使用される。次いで,この発行者セキュリティドメインを用いて,決済アプリケーションデータ,クレジットカード個人化データ,又は同様のものなどのアプリケーション固有のセキュリティドメインを記憶することができる。)

上記引用の記載から,引用文献2には,概略すると,
「クレジットカードによる決済端末をパーソナライゼーションするにあたり,発行元セキュリティドメイン(ISD)鍵セットを設定する」という技術事項が記載されている。

3.引用文献3について
引用文献3には,関連する図面と共に,次の事項が記載されている。

I.「【0041】図3は送信装置10および受信装置20によってそれぞれ実行される暗号化処理および復号処理の概要を鍵の働きを中心に示すものである。図4は送信装置10における暗号化処理,受信装置20における復号処理およびこれらの送,受信装置10,20間の通信処理の処理手順を示すフローチャートである。
【0042】まず送信装置10において,操作者は入力装置11から平文を入力する,または送信装置10内において自動的に平文が作成される(他のコンピュータにおいて作成された平文を送信装置10が受信した(FDなどから読み取った)場合を含む)。平文は文書データに限られることはなく,たとえばエレクトロニック・コマース(電子商取引)におけるクレジット・カード番号や暗証番号等も含まれる。入力された平文は送信装置10の内部メモリ15に一時的に記憶される。
【0043】共通鍵生成プログラムにしたがって共通鍵が生成される。たとえば,共通鍵生成プログラムとして乱数発生プログラムを用い,乱数を発生させこれを共通鍵とする。
【0044】生成された共通鍵は,識別子に対応して外部記憶装置18に登録(記憶)される(ステップ101 )。ここでは識別子をiで示し,識別子iに対応する共通鍵を共通鍵iとする。識別子は,暗号ネットワーク・システムにおける処理で用いられる鍵を同定するために用いられる。これは送信装置10と受信装置20の間で,または送信装置10もしくは受信装置20とその他の装置との間で複数の暗号文の送受信を行う場合に有効である。識別子iには,たとえば共通鍵が生成されるたびに増加していく,または変更される数字(共通鍵が生成されるたびに生成される乱数など),操作者が入力する文字,数字などが用いられる。複数の共通鍵をあらかじめ生成して外部記憶装置18に記憶しておき,識別子iが生成または入力される度に,記憶している共通鍵の1つに識別子iを対応させてもよい。
【0045】つぎに共通鍵iを用いて共通鍵暗号化プログラムにしたがって平文が暗号化される(ステップ102 )(これにより生成された暗号文を暗号文iとする)。暗号文iは,識別子iおよび第1の公開鍵/秘密鍵生成プログラムとともに,送信装置10から受信装置20に送信される(ステップ103 )。
【0046】受信装置20は送信装置10から送信された暗号文i,識別子iおよび第1の公開鍵/秘密鍵生成プログラムを受信すると,受信した第1の公開鍵/秘密鍵生成プログラムを実行する。これにより第1の公開鍵と第1の秘密鍵の対が生成される(ステップ201 )。
【0047】生成された第1の公開鍵と第1の秘密鍵のうちの第1の秘密鍵が,識別子iに対応して受信装置20の外部記憶装置28に登録(記憶)される(ステップ202 )。一方,第1の公開鍵は識別子iとともに送信装置10に送信される(ステップ203)。これらの識別子iに対応する第1の秘密鍵および第1の公開鍵を,第1の秘密鍵i,第1の公開鍵iとする。
【0048】第1の公開鍵iと識別子iを受信した送信装置10は,外部記憶装置18に登録された共通鍵の中から,受信した識別子iに対応する共通鍵iを検索する(ステップ104)。
【0049】検索された共通鍵iが受信装置20から送信された第1の公開鍵iを用いて第1の公開鍵システム暗号化プログラムにしたがって暗号化される(ステップ105 )。暗号化された共通鍵(以下,暗号化共通鍵iという)は識別子iとともに受信装置20に送信される(ステップ106 )。
【0050】受信装置20は外部記憶装置28に登録された第1の秘密鍵の中から,識別子iに対応する第1の秘密鍵iを検索する(ステップ204 )。検索された第1の秘密鍵iは,共通鍵iの暗号化(ステップ105 )に用いられた第1の公開鍵iと対をなすものである。
【0051】受信装置20において,検索された第1の秘密鍵iを用いて第1の公開鍵システム復号プログラムにしたがって送信装置10から送信された暗号化共通鍵iが復号され(ステップ205 ),共通鍵iが得られる。続いて,復号された共通鍵iを用いて共通鍵復号プログラムにしたがって,先に受信した暗号文iが復号される(ステップ206 )。これにより平文が得られる。
【0052】ネットワーク10を介して送信される鍵は,暗号化共通鍵iおよび第1の公開鍵iのみであり,高い秘匿性の求められる第1の秘密鍵iの送信は行われない。さらに受信側では第1の秘密鍵をあらかじめ入手しておく必要がなく,暗号文の受信の度に第1の公開鍵と第1の秘密鍵の対を生成する。このため第三者による暗号文の解読は極めて困難であり,暗号化通信の安全性が高い。さらに識別子iを暗号化共通鍵,第1の公開鍵および第1の秘密鍵に対応させることによって,第1の公開鍵iを受信装置20から送信装置10に送信したときに送信装置10では,受信した第1の公開鍵で暗号化すべき共通鍵を特定することができ,暗号化共通鍵iを送信装置10から受信装置20に送信したときに,受信装置20では復号処理に用いるべき第1の秘密鍵および暗号化共通鍵を特定することができる。多数の暗号文の送受信が行われた場合でも,暗号化処理および復号処理を間違いなく進めることができる。
【0053】送信装置10から受信装置20に送信される第1の公開鍵/秘密鍵生成プログラム(ステップ103 )および暗号化共通鍵(ステップ106 )は,送信装置10から受信装置20に送信する態様でなく,受信装置20から送信装置10にアクセスし,これら第1の公開鍵/秘密鍵生成プログラムおよび暗号化共通鍵をダウンロードする態様としてもよい。受信装置20の操作者は暗号文に付された識別子iにもとづいて,ダウンロードすべき暗号化共通鍵を特定することができる。これに代えて,第1の公開鍵/秘密鍵生成プログラムおよび暗号化共通鍵を送信装置10とは別のコンピュータに置かれたアクセス可能なデータベースに格納しておき,受信装置20がこのデータベースをアクセスして,第1の公開鍵/秘密鍵生成プログラムおよび暗号化共通鍵を入手するようにすることもできる。さらに,第1の公開鍵/秘密鍵生成プログラムをあらかじめ受信装置20に設けておいてもよい。
【0054】上述の第1の実施例においては平文を共通鍵iを用いて暗号化し,暗号文を復号している。これに代えて,公開鍵システムにおける公開鍵を用いて平文を暗号化し,これに対応する秘密鍵を用いて暗号文を復号することもできる(これらの鍵を平文用公開鍵,平文用秘密鍵という)(後に説明する第2?第13実施例についてもこの変形例はあてはまる)。この場合送信装置10ではあらかじめ平文用公開鍵と平文用秘密鍵の対が生成され,生成された平文用秘密鍵が識別子iとともに外部記憶装置18に登録される(ステップ101 に対応)。この平文用秘密鍵(平文用秘密鍵iとする)に対応する平文用公開鍵(平文用公開鍵iとする)を用いて送信装置10において平文が暗号化される(ステップ102 に対応)。送信装置10では受信装置20から送信された第1の公開鍵iで平文用秘密鍵iが暗号化され,暗号化平文用秘密鍵iが識別子iとともに受信装置20に送信される(ステップ104?106に対応)。受信装置20では第1の秘密鍵iで暗号化平文用秘密鍵iが復号され,復号された平文用秘密鍵iで暗号文が平文に復号される(ステップ204?206 に対応)。
【0055】平文を公開鍵(平文用公開鍵)を用いて暗号化する場合には,楕円暗号方式(アルゴリズム)を利用した暗号化プログラム(復号プログラムも)を用いるとよい。高速に平文を暗号化でき,コンピュータのメモリの使用量を少なくすることができる。
【0056】第2実施例
第2実施例は,送信装置10および受信装置20のそれぞれがもつプログラムの種類およびそれによる動作が第1実施例と異なる。すなわち,第1実施例において送信装置10に設けられていたプログラムi),ii) ,iii)およびiv) のうち,ii)共通鍵生成プログラムを除く,i)共通鍵暗号化プログラム,iii)第1の公開鍵システム暗号化プログラムおよびiv) 第1の公開鍵/秘密鍵生成プログラムが受信装置20に設けられている。
【0057】図5は第2実施例の送信装置10における暗号化処理,受信装置20における復号処理,およびこれらの送,受信装置10,20間の通信処理の処理手順を示すフローチャートである。ステップ 200およびステップ 103Aを除く処理は第1実施例(図4)と同じであるので説明を省略する。
【0058】送信装置10から共通鍵暗号化プログラムおよび第1の公開鍵システム暗号化プログラムの送信要求があった場合,または受信装置20が送信装置10からの暗号文の送信を要求する場合には,受信装置20は,共通鍵暗号化プログラムおよび第1の公開鍵システム暗号化プログラムを送信装置10に送信する(ステップ200 )。
【0059】送信装置10において,共通鍵iを用いて共通鍵暗号化プログラムにしたがって平文が暗号化される(ステップ102 )。送信装置10から受信装置20に,暗号文iおよび識別子iが送信される(ステップ103A)。ステップ201 ?203 ,ステップ104 ?106 ,ステップ204 ?206 の処理(図4と同じ)が行われ,受信装置20に送信された暗号文が平文に復号される。
【0060】第2実施例では,送信装置10が共通鍵暗号化プログラムおよび第1の公開鍵システム暗号化プログラムを持たない場合でも,第1実施例と同様の暗号化通信を行うことができ,しかもセキュリティを確保することができる。」

上記引用の記載から,引用文献3には,概略すると,
「送信装置が,受信装置の公開鍵を用いて共通鍵を暗号化し,暗号化した共通鍵を受信装置に送信し,受信装置において暗号化した共通鍵を復号して用いる」という技術事項が記載されている。

第6.本願発明と引用発明との対比及び相違点についての判断
1.本願発明1について
(1)対比
ア.引用発明における「サービス提供者サーバ」,「端末」,及び,「端末製造者サーバ」が,
本願発明1における「サーバー装置」,「クライアント装置」,及び,「ベンダー装置」にそれぞれ相当し,
引用発明における「共通鍵CK2」は,「端末製造者サーバ」において,「端末」に書き込まれることから,
本願発明1における「初期発行元セキュリティドメイン(ISD)鍵セット」と,
“初期鍵である”点で共通し,
ここで,当該「共通鍵CK2」は,引用発明において,「サービス提供サーバ」が,自らが生成した「運用鍵K」の暗号化に用い,「端末」は,「暗号化された運用鍵K」の復号に,当該「共通鍵CK2」を用いているが,このとき,当該「共通鍵CK2」を復号する操作は行っていないので,引用発明において,当該「共通鍵CK2」は,「端末製造者サーバ」において,「端末」に書き込まれるときに,暗号化されていないことは,明らかである。
したがって,
引用発明において,「端末製造者サーバが,・・・共通鍵CK2を生成し,共通鍵CK2を端末およびSAMに書き込」むことは,
本願発明1における「前記クライアント装置に前記初期ISD鍵セットを提供する段階であって,前記初期ISD鍵セットは暗号化されていない形式である,段階」と,
“クライアント装置に初期鍵を提供する段階であって,前記初期鍵は暗号化されていない形式である,段階”である点で,共通する。

イ.引用発明においては,「端末が,情報設定者サーバより転送された署名SG1を,端末製造者サーバにて設定された公開鍵PK1を用いて検証し」,「端末は,公開鍵PK1を用いて検証することにより,端末に設定する運用鍵Kがサービス提供者によって生成されたものであることを保証できる」ことから,
引用発明における「公開鍵PK1」は,サービス提供者に関連付けられた公開鍵であるから,
本願発明1における「前記サーバー装置に関連付けられる公開鍵」に相当し,
引用発明における「公開鍵PK1と公開鍵PK1に対応する秘密鍵SK1を生成し,秘密鍵SK1をSAM(Secure Application Module)に書き込み,公開鍵PK1を端末に書き込」むことが,
本願発明1における「前記クライアント装置に対して,前記サーバー装置に関連付けられる公開鍵を提供する段階」に相当する。

ウ.上記ア.において検討した事項から,
引用発明において,“端末製造者サーバは,共通鍵CKをSAMに書き込み,前記SAMをサービス提供者に渡”していることから,
引用発明においては,“端末製造者サーバは,共通鍵CKを,サービス提供者サーバに提供する”ものであって,このことが,
本願発明1における「前記ベンダー装置から独立して新規のISD鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように,前記暗号化済み初期ISD鍵セットを前記サーバー装置に提供する段階」と,
“初期鍵をサーバ装置に提供する段階”である点で共通する。

エ.そして,引用発明は,「サービス提供者サーバ」,「端末」,及び,「端末製造者サーバ」が関与する,「サービス提供者サーバ」と通信するよう構成されている「端末」用の「初期鍵」を事前に設定するための方法に関するものであるから,
本願発明1における「ベンダー装置,クライアント装置及びサーバー装置が関与する,サーバー装置と通信するように構成されているクライアント装置用の初期発行元セキュリティドメイン(ISD)鍵セットをプレパーソナライゼーションするための方法」と,
“ベンダー装置,クライアント装置及びサーバー装置が関与する,サーバー装置と通信するように構成されているクライアント装置用の初期鍵プレパーソナライゼーションするための方法”である点で共通する。

オ.以上,上記ア.?エ.において検討した事項から,本願発明と,引用発明との,一致点,及び,相違点は,次のとおりである。

[一致点]
ベンダー装置,クライアント装置及びサーバー装置が関与する,サーバー装置と通信するように構成されているクライアント装置用の初期鍵プレパーソナライゼーションするための方法であって,ベンダー装置において,
クライアント装置に初期鍵を提供する段階であって,前記初期鍵は暗号化されていない形式である,段階と,
前記クライアント装置に対して,前記サーバー装置に関連付けられる公開鍵を提供する段階と,
初期鍵をサーバ装置に提供する段階と,
を含む方法。

[相違点1]
“初期鍵”に関して,
本願発明1においては,「クライアント装置用の初期発行元セキュリティドメイン(ISD)鍵セット」であるのに対して,
引用発明においては,「共通鍵CK2」である点。

[相違点2]
本願発明1は,「初期ISD鍵セットを前記公開鍵で暗号化して暗号化済み初期ISD鍵セットを生成する段階」を有するものであるのに対して,
引用発明は,そのような「段階」を有してない点。

[相違点3]
“初期鍵をサーバ装置に提供する段階”に関して
本願発明1においては,「ベンダー装置から独立して新規のISD鍵セットを確立するために前記クライアント装置及び前記サーバー装置を使用可能にするように,前記暗号化済み初期ISD鍵セットを前記サーバー装置に提供する段階」であるのに対して,
引用発明においては,「サービス提供者サーバ」に,「共通鍵CK2」を提供する段階である点。

[相違点4]
本願発明1においては,「クライアント装置において,前記新規のISD鍵セットを確立するために,前記サーバー装置から受信した初期化スクリプトに基づいて前記新規のISD鍵セットを生成し,前記サーバー装置へ提供される暗号化済みの新規のISD鍵セットを提供するために前記公開鍵を用いて前記新規のISD鍵セットを暗号化する,段階」を有するものであるのに対して,
引用発明は,そのような「段階」を有していない点。

(2)相違点についての当審の判断
事案に鑑みて,上記[相違点4]について先に検討すると,[相違点4]に係る本願発明1の構成は,上記引用文献1?引用文献3には記載されておらず,本願の優先日前において周知技術であるともいえない。
したがって,他の相違点について判断するまでもなく,本願発明1は,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

2.本願発明2?本願発明7について
本願の請求項2?本願の請求項7は,本願の請求項1を直接・間接に引用するものであるから,本願発明2?本願発明7は,上記「1.本願発明1について」の「(2)相違点についての当審の判断」において検討した,[相違点4]に係る構成を有するものである。
したがって,本願発明2?本願発明7は,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

3.本願発明8?本願発明12について
本願発明8は,上記「1.本願発明1について」の「(2)相違点についての当審の判断」において検討した,[相違点4]に係る構成を有するものである。
そして,本願の請求項9?本願の請求項12は,本願の請求項8を直接・間接に引用するものであるから,本願発明9?本願発明12は,本願発明8と同じく,上記「1.本願発明1について」の「(2)相違点についての当審の判断」において検討した
成を有するものである。
したがって,本願発明8?本願発明12は,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

4.本願発明13?本願発明20について
本願発明13は,上記「1.本願発明1について」の「(2)相違点についての当審の判断」において検討した,[相違点4]に係る構成を有するものである。
そして,本願の請求項14?本願の請求項20は,本願の請求項13を直接・間接に引用するものであるから,本願発明14?本願発明20は,本願発明13と同じく,上記「1.本願発明1について」の「(2)相違点についての当審の判断」において検討した,[相違点4]に係る構成を有するものである。
したがって,本願発明13?本願発明20は,当業者であっても引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。

第7.原審拒絶査定についての判断
本件手続補正により,本願発明1?本願発明20は,[相違点4]に係る構成を有するものとなっており,当業者であっても,原審拒絶査定において引用された引用文献1?引用文献3に基づいて,容易に発明できたものとはいえない。したがって,原審拒絶査定の理由を維持することはできない。

第8.当審拒絶理由について
記載不備に関する,当審拒絶理由は,令和1年12月13日付けの手続補正によって解消した。

第9.むすび
以上のとおり,本願発明1?本願発明20は,当業者が引用発明,引用文献2,及び,引用文献3に記載された技術的事項に基づいて容易に発明をすることができたものではない。
したがって,原審拒絶査定の理由によっては,本願を拒絶することはできない。
また,他に本願を拒絶すべき理由を発見しない。

よって,結論のとおり審決する。
 
審決日 2020-03-03 
出願番号 特願2016-133919(P2016-133919)
審決分類 P 1 8・ 537- WY (H04L)
P 1 8・ 121- WY (H04L)
最終処分 成立  
前審関与審査官 中里 裕正  
特許庁審判長 仲間 晃
特許庁審判官 石井 茂和
松平 英
発明の名称 グローバルプラットフォーム仕様を使用した発行元セキュリティドメインの鍵管理のためのシステム及び方法  
代理人 田中 伸一郎  
代理人 大塚 文昭  
代理人 那須 威夫  
代理人 西島 孝喜  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ