JP4523814B2 - 携帯電話に装着して用いる会員情報提示用電子モジュール - Google Patents

Description

本発明は、携帯電話に装着して用いる会員情報提示用電子モジュールおよびその発行方法に関し、特に、携帯電話を利用してクレジットカード決済などのサービスを提供するために利用される電子モジュールを遠隔地から発行する技術に関する。

会員に対して種々のサービスや特典を提供するために、様々な会員カードが発行されている。このような会員カードの代表は、信販会社によって個々の会員に発行されるクレジットカードである。最近は、セキュリティを向上させるために、ＩＣカードをクレジットカードとして利用する信販会社も増えてきている。ＩＣカードをクレジットカードとして会員に提供するためには、ＩＣカードに内蔵されている不揮発性メモリに、信販の決済に必要な決済情報を書き込む電子的な発行処理を行う必要がある。たとえば、下記の特許文献１には、店頭でＩＣカードを利用したクレジットカードを即時発効するための方法および装置が開示されている。
特開２００３−２０３２０７号公報

クレジットカードを始めとする種々の会員カードは、本来、サービス提供者によって発行されるべきものであり、これはカードの媒体がＩＣカードになっても同様である。したがって、ＩＣカードを個々の会員に発行する際には、各サービス提供者が独自に定めた会員情報やデジタル鍵などを書き込む処理が必要になる。たとえば、信販会社がＩＣカードをクレジットカードとして発行する場合、クレジットカード番号、有効年月、その他の会員情報、会員ごとに異なる秘密の鍵情報などを、当該信販会社が定めた固有の規則に基づいて発生させ、これをＩＣカードに書き込む処理が必要になる。このクレジットカードの発行処理は、通常、信販会社からの委託を受けた発行処理業者によって行われ、発行済みのクレジットカードは、書留郵便などの手段を用いて各会員へと配付されることになる。

ところが最近、携帯電話をクレジットカードなどの代用品として利用しようという提案がなされている。近年における携帯電話の普及はめざましく、特に若年層における利用率は極めて高くなってきている。しかも、第３世代の移動通信システム用の携帯電話は、ＵＩＭ（User Identity Module）と呼ばれる電子モジュール（小型のＩＣカード）を装着する機能を有しているため、このＵＩＭカードに必要な会員情報を書き込むようにすれば、このＵＩＭカードを装着した携帯電話を、クレジットカードなどの代用品として利用することが可能になる。たとえば、ＵＩＭカードに、クレジットカード番号や有効年月といった信販決済に必要な会員情報を書き込む処理を行えば、当該ＵＩＭカードは、携帯電話を介して当該会員情報を外部に提示する役割を果たし、会員情報提示用電子モジュールとして機能することになる。

しかしながら、このＵＩＭカードのような携帯電話装着用の電子モジュールを、クレジットカードや種々のサービスカードとして利用する場合、従来行われている発行方式をそのまま適用することはできない。なぜなら、従来の方式では、上述したように、サービス提供者側で発行処理を完了した状態のカードを、書留郵便などで直接会員宛に発送するという方法を採ることができるのに対して、携帯電話装着用の電子モジュールを媒体としたサービスカードの場合、そのような方式を採ることが困難なためである。通常、多くのユーザは、電器店、家電量販店などで携帯電話を購入することになるが、携帯電話を購入したユーザが、当該携帯電話をクレジットカードとして利用するかどうかは、ユーザ自身の判断による事項であり、また、どの信販会社を選択するかも、ユーザの好みによって定まる事項である。従って、現実的には、個々のユーザが電子モジュール付き携帯電話を購入し、特定の信販会社に対して信販サービスを受けたい旨の意志表示を待って、当該電子モジュールをクレジットカードとして利用できるようにするための発行処理を行わざるを得ない。

そこで本発明は、携帯電話に装着して用いる電子モジュールを、会員情報提示用電子モジュールとして機能させるための効率的な発行処理方法を提供することを目的とし、また、そのような発行処理方法に適した電子モジュールを提供することを目的とする。

(1) 本発明の第１の態様は、携帯電話に装着することにより、当該携帯電話を用いた会員情報提示処理を可能にするための電子モジュールに、
携帯電話との間で情報のやりとりを行う通信部と、
所定の初期鍵が格納された鍵格納部と、提示対象となる会員情報を格納するための会員情報格納部と、の対によって構成されている領域が、複数組確保されているデータ格納部と、
通信部を介して携帯電話から、特定の選択領域についての初期鍵を所定の本番鍵に書き換えるべき鍵書換命令が与えられたときに、初期鍵を利用したセキュリティ確保を行いながら、選択領域についての鍵格納部内の初期鍵を本番鍵に書き換える処理を行う鍵書換処理部と、
通信部を介して携帯電話から、選択領域についての会員情報格納部に所定の会員情報を書き込むべき会員情報書込命令が与えられたときに、選択領域についての本番鍵を利用したセキュリティ確保を行いながら、選択領域についての会員情報格納部内に所定の会員情報を書き込む処理を行う会員情報書込部と、
通信部を介して携帯電話から、所定領域についての会員情報提示命令が与えられたときに、所定領域についての会員情報格納部内に格納されている会員情報を外部に読み出して提示する処理を行う会員情報提示部と、
を設け、
複数組の各領域内に格納されている初期鍵は、互いに同一の共通初期鍵となるようにし、
鍵書換処理部は、書き換える処理を行う際に、初期鍵を用いた暗号化処理により暗号化された状態で本番鍵を受け取り、これを電子モジュール内部で復号化することにより第１の書換用セキュリティ確保を行うとともに、初期鍵を用いて作成された認証コードとともに本番鍵を受け取り、この認証コードを用いた正当性チェックにより第２の書換用セキュリティ確保を行い、
会員情報書込部は、書き込む処理を行う際に、本番鍵を用いた暗号化処理により暗号化された状態で会員情報を受け取り、これを電子モジュール内部で復号化することにより第１の書込用セキュリティ確保を行うとともに、本番鍵を用いて作成された認証コードとともに会員情報を受け取り、この認証コードを用いた正当性チェックにより第２の書込用セキュリティ確保を行うようにしたものである。

(2) 本発明の第２の態様は、上述の第１の態様に係る会員情報提示用電子モジュールにおいて、
会員情報として、クレジットカード会員がカード決済を行うために必要な決済情報を用い、携帯電話を利用した決済処理を行うことができるようにしたものである。

(3) 本発明の第３の態様は、電子モジュールを、上述の第１または第２の態様に係る会員情報提示用電子モジュールとして機能させるためのプログラムを用意するようにしたものである。
(4) 本発明の第４の態様は、電子モジュールを、上述の第１または第２の態様に係る会員情報提示用電子モジュールとして機能させるためのプログラムをコンピュータ読み取り可能な記録媒体に記録して配付できるようにしたものである。

続いて、本発明を図示する実施形態に基づいて説明する。

＜＜＜ §１．本発明に係る携帯電話装着用電子モジュールの基本構成 ＞＞＞
図１は、本発明に係る電子モジュール１００およびこれを装着する携帯電話２００の外観の一例を示す正面図である。図示の例は、一般にＵＩＭ（User Identity Module）と呼ばれている電子モジュール１００の例であり、携帯電話２００に装着して利用する。現在、一般に利用されているＵＩＭは、小型のＩＣカードというべき形態のものであるが、もちろん、本発明の適用対象となる電子モジュールの形態は、カード状のものに限定されるわけではない。以下、この電子モジュール１００に、クレジットカードとしての機能をもたせる実施形態を述べることにする。

クレジットカードとしての機能をもったＩＣカードなるものは、既に、いくつかの大手信販会社から発行されている。これらのＩＣカードには、クレジットカード番号や有効年月といった信販決済に必要な会員情報が書き込まれており、会員が決済を行う際には、これらの会員情報が外部に読み出されることになる。したがって、クレジットカードとしての機能をもった電子モジュールの基本機能は、決済を行う際に、クレジットカード番号や有効年月といった信販決済に必要な会員情報を外部に読み出して提示する機能ということができ、この点に関しては、本発明に係る電子モジュール１００も従来のＩＣカード式クレジットカードと同じである。

本発明に係る電子モジュール１００が、現在利用されている一般的なＩＣカード型クレジットカードと異なる点は、常に携帯電話２００に装着した状態で利用される、という点である。このため、決済時に読み出される会員情報は、携帯電話２００を介して外部へと提示されることになる。そして、既に述べたとおり、実用上は、電子モジュール１００は携帯電話２００の付属品としてユーザに提供される流通形態をとることになるため、クレジットカードとしての機能は、ユーザの手元に渡った後に行われる発行処理によって初めて付与されることになる。別言すれば、従来のＩＣカード型クレジットカードの場合、信販会社側で発行処理が完了した後に会員の下に配送するという形態を採ることができるのに対し、電子モジュール１００の場合、ユーザが携帯電話２００を購入した時点では、まだクレジットカードとしての機能を何ら有していないことになる。

図２は、携帯電話２００に添付して市場に流通させた時点における本発明に係る電子モジュール１００の構成を示すブロック図である。図示のとおり、この電子モジュール１００内には、通信部１１０，鍵書換処理部１２０，会員情報書込部１３０，会員情報提示部１４０，データ格納部１５０，モジュールＩＤ格納部１６０が設けられている。これらの各構成要素は、後述するクレジットカードとしての発行処理および決済処理を行うためのものであるが、図示の状態では、まだ、クレジットカードとしての機能は何ら有していない。通信部１１０は、携帯電話２００との間で情報のやりとりを行う構成要素であり、電子モジュール１００に対する交信は、すべてこの通信部１１０を介して行われる。

なお、ここでは発明の構成を説明する便宜上、電子モジュール１００を図示のようなブロックで示された機能的構成要素の集合として示すが、実際には、これらの各構成要素は、ＣＰＵ、メモリ、通信回路といった電子モジュール１００に備わっているハードウエアと、これに組み込まれたソフトウエアとの組み合わせによって実現される構成要素ということになる。したがって、たとえば、鍵書換処理部１２０、会員情報書込部１３０、会員情報提示部１４０の実体は、電子モジュール１００に組み込まれたプログラムであり、データ格納部１５０やモジュールＩＤ格納部１６０の実体は、電子モジュール１００内のメモリ（通常は、ＥＥＰＲＯＭなどの不揮発性メモリ）上に設けられた所定の記憶領域ということになる。また、図示の各構成要素は、本発明の機能に直接関連した構成要素であり、実際の電子モジュール１００には、この他にも種々の構成要素（たとえば、外部から与えられたプログラムをＥＥＰＲＯＭ内に追加するための構成要素や、携帯電話２００用の電話番号を記録するための構成要素など）が含まれている。

図２に示す実施形態では、データ格納部１５０内には、３組の領域が確保されている。第１の組は、鍵格納部１５１Ａと会員情報格納部１５２Ａとの対によって構成されており、第２の組は、鍵格納部１５１Ｂと会員情報格納部１５２Ｂとの対によって構成されており、第３の組は、鍵格納部１５１Ｃと会員情報格納部１５２Ｃとの対によって構成されている。ここで、各鍵格納部１５１Ａ，１５１Ｂ，１５１Ｃには、共通の初期鍵が予め格納されているが、各会員情報格納部１５２Ａ，１５２Ｂ，１５２Ｃには、何ら情報は記録されていない。後述する発行処理は、特定の組について、初期鍵を本番鍵に書き換えるとともに、会員情報格納部内に所定の会員情報を書き込む処理ということができる。図示の例では、３組の領域が確保されているので、合計３つまでのサービス提供業者による発行処理が可能になる。

＜＜＜ §２．クレジットカードとしての利用形態 ＞＞＞
ここでは、この電子モジュール１００をクレジットカードとして利用するための具体的な発行処理の手順を説明する前に、発行処理が完了した後のクレジットカードとしての利用形態の一例を、図３のブロック図を参照しながら説明する。図３に示す携帯電話２００内には、後述する発行処理が完了した状態の電子モジュール１００が既に装着されており、ユーザは、この携帯電話２００をクレジットカードの代用品として利用して、買い物や食事などの代金決済を行うことが可能になる。ここでは、ある信販会社Ａについての発行処理を受けることにより、携帯電話２００が、当該Ａ社が発行するクレジットカードとして機能する場合を例にとり、２通りのケースにおける決済処理を説明する。

まず、第１のケースは、このユーザが、実際の店舗で買い物をしたり、食事をしたりした場合に、当該店舗で決済を行うケースである。この場合、ユーザは、携帯電話２００を当該店舗に設置された店舗端末３００に接続して決済を行うことになる。図示の例は、携帯電話２００の赤外線通信機能を利用して、店舗端末３００に無線接続を行った例である。携帯電話２００に装着された電子モジュール１００は、会員情報提示用モジュールとして機能し、内部に格納されていた会員情報（この場合、クレジットカード番号および有効年月といった決済情報）を外部に提示する機能を果たす。具体的には、ユーザが携帯電話２００の表示ウインドウを見ながら、決済のために所定のメニューを選択する操作を行うと、電子モジュール１００内に格納されていた会員情報が、会員情報提示部１４０の機能により、携帯電話２００側へと読み出され、赤外線通信路を経て店舗端末３００側へと提示されることになる。図２に示す会員情報提示部１４０は、このような提示処理を行う機能を果たす。

店舗端末３００が取得した会員情報は、当該店舗を特定する情報や利用金額を示す情報とともに、決済ネットワーク４００を介して、Ａ社用ホスト５１０へと伝達される。Ａ社用ホスト５１０が、これらの情報に基づいて、所定の課金処理を行う点は、従来のクレジットカード決済の処理と全く同様である。

一方、第２のケースは、このユーザが、インターネット上の仮想店舗で買い物をしたような場合に、この仮想店舗で決済を行うケースである。この場合、ユーザは、携帯電話２００の移動体通信機能を利用して、インターネット上の仮想店舗にアクセスすることになるので、携帯電話２００からの情報は、移動体通信網６００、移動体通信網のゲートウェイサーバ６１０，インターネット７００、決済用ゲートウェイサーバ７１０を介して、ネットショップ用サーバ７２０へと伝達され、逆の経路をとって、ネットショップ用サーバ７２０からの情報が携帯電話２００へと伝達されることになる。ユーザが、ネットショップ用サーバ７２０からの指示にしたがって、クレジットカードによる決済を行うための操作を行うと、電子モジュール１００内に格納されていた会員情報が、携帯電話２００側へと読み出され、上記経路を経てネットショップ用サーバ７２０側へと提示されることになる。図２に示す会員情報提示部１４０は、このような提示処理を行う機能を果たす。

ネットショップ用サーバ７２０が取得した会員情報は、当該仮想店舗を特定する情報や利用金額を示す情報とともに、決済用ゲートウェイサーバ７１０および決済ネットワーク４００を介して、Ａ社用ホスト５１０へと伝達される。Ａ社用ホスト５１０が、これらの情報に基づいて、所定の課金処理を行う点は、上述した第１のケースと同様である。

なお、図示されているＢ社用ホスト５２０およびＣ社用ホスト５３０は、それぞれ別な信販会社Ｂ，Ｃによって発行されたクレジットカードに関する決済処理を行うホストコンピュータである。ユーザが、信販会社Ａだけでなく、信販会社Ｂ，Ｃについても、クレジットカードの発行処理を受けていれば、ユーザが指定した任意の信販会社についての決済処理が可能になる。

図４は、信販会社Ａ，Ｂ，Ｃの３社から、それぞれ発行処理を受けた場合の電子モジュール１００のデータ格納部１５０内の状態を示すブロック図である。この図４に示すデータ格納部１５０内の情報の格納状態を、図２に示すデータ格納部１５０内の情報の格納状態とを比較すれば、後述する発行処理によってどのような情報が書き込まれるかが明瞭になろう。たとえば、Ａ社の発行処理により書き込みが行われる第１の領域（図の上段）に関しては、鍵格納部１５１Ａの初期鍵がＡ社用の本番鍵に書き換えられており、会員情報格納部１５２ＡにはＡ社用の決済情報（Ａ社が発行するクレジットカードの番号や有効年月など）が格納されている。同様に、Ｂ社の発行処理により書き込みが行われる第２の領域（図の中段）に関しては、鍵格納部１５１Ｂの初期鍵がＢ社用の本番鍵に書き換えられており、会員情報格納部１５２ＢにはＢ社用の決済情報が格納されており、Ｃ社の発行処理により書き込みが行われる第３の領域（図の下段）に関しては、鍵格納部１５１Ｃの初期鍵がＣ社用の本番鍵に書き換えられており、会員情報格納部１５２ＣにはＣ社用の決済情報が格納されている。

ここで、図２に示す各鍵格納部１５１Ａ〜１５１Ｃに書き込まれていた初期鍵は、互いに同一の共通鍵（たとえば、１６バイトのデータ）であるが、図４に示す各鍵格納部１５１Ａ〜１５１Ｃに書き込まれている各本番鍵は、互いに異なる独立した鍵になっている。また、図４に示す各会員情報格納部１５２Ａ〜１５２Ｃに格納されている各決済情報も、当然ながら、互いに異なる情報である。各鍵格納部１５１Ａ〜１５１Ｃに書き込まれている本番鍵は、クレジットカードを利用した通常の決済処理で用いられることはないが、携帯電話２００を用いて、各信販会社に登録されているユーザ情報（たとえば、住所、電話番号、パスワードなど）を変更するような操作を行う場合には、この本番鍵を利用した認証が行われる。また、以下に述べるとおり、この本番鍵は、発行処理を行う際にも重要な機能を果たすことになる。

本発明に係る電子モジュールの発行処理とは、結局、予め鍵格納部１５１Ａ〜１５１Ｃに格納されていた初期鍵を本番鍵に書き換える処理と、空欄となっていた会員情報格納部１５２Ａ〜１５２Ｃに新たに会員情報を書き込む処理ということができる。ただし、この発行処理は、ユーザが携帯電話２００とともに電子モジュール１００を購入した後に行うことになるので、遠隔地から行う必要があり、十分なセキュリティが確保されるような配慮が必要になる。

そこで、本発明では、まず、鍵格納部１５１Ａ〜１５１Ｃに格納されていた初期鍵を本番鍵に書き換える処理を行う際に、当該初期鍵自身を利用したセキュリティ確保を行うようにし、続いて、会員情報格納部１５２Ａ〜１５２Ｃに新たに会員情報を書き込む処理を行う際に、本番鍵を利用したセキュリティ確保を行うようにしている。具体的なセキュリティ確保の手法については後述する。また、図示の実施形態のように、データ格納部１５０に、鍵格納部１５１と会員情報格納部１５２とからなる対が複数組（図示の例では３組）用意されている場合には、特定の組に所属する会員情報格納部１５２に会員情報を書き込む際に、同じ組に所属する鍵格納部１５１内の本番鍵を用いたセキュリティ確保を行うようにする。たとえば、第１の組に所属する会員情報格納部１５２ＡにＡ社用の決済情報を書き込む際には、同じ第１の組に所属する鍵格納部１５１Ａ内のＡ社用の本番鍵を用いたセキュリティ確保が図られることになる。

＜＜＜ §３．発行処理に至るまでのプロセス ＞＞＞
続いて、図５のブロック図を参照しながら、本発明に係る発行処理に至るまでの具体的なプロセスを説明する。ここでは、通信事業者Ｘが提供する電子モジュール１００付き携帯電話２００を、ユーザＹが購入し、当該ユーザＹが信販会社Ａを選択してクレジットカードとしての発行を受ける際に、信販会社Ａから発行処理の委託を受けた発行処理業者Ｚが発行処理を行う例について、具体的なプロセスを説明する。

まず、ユーザＹは、電器店や家電量販店などで、通信事業者Ｘが提供する携帯電話２００を購入する。この携帯電話２００には、電子モジュール１００が付属している。もっとも、この時点では、電子モジュール１００の構成は、図２のブロック図に示す状態となっており、初期鍵は格納されているものの、特定の信販会社についての本番鍵や会員情報はまだ格納されておらず、クレジットカードとしての機能を果たすことはできない。なお、ここで述べる実施形態では、各電子モジュール１００内のモジュールＩＤ格納部１６０には、それぞれ個々の電子モジュール１００に固有のモジュールＩＤが格納されているものとし、また、データ格納部１５０内に格納しておく初期鍵として、このモジュールＩＤにを用いて所定のアルゴリズムに基づく演算を行うことにより一義的に生成されるデジタルデータを用いるようにしている。したがって、同一の電子モジュール１００内の各領域に格納されている初期鍵は同一であるが、異なる電子モジュール１００には、それぞれ異なる初期鍵が格納されていることになる。

ここに示す実施形態では、この携帯電話２００のパッケージに、申込書２１０を同梱するようにしている。この申込書２１０は、電子モジュール１００にクレジットカードとしての機能をもたせるための発行処理を申し込むための書類である。実用上は、複数の信販会社についての申込書２１０をそれぞれ同梱しておくようにし、ユーザＹが、これらの中から、１つもしくは複数の信販会社を任意に選択して、発行処理を申し込むことができるようにしておくのが好ましい。ここでは、ユーザＹが信販会社Ａを選択してクレジットカードの発行処理を申し込む場合を例にとって、以下の説明を行うことにする。ユーザＹは、申込書２１０の所定欄に、通常のクレジットカードの申込書と同様に、住所、氏名、電話番号、勤務先、パスワードなどの情報を書き込んだ上で、これを通信事業者Ｘ宛に郵送すればよい。通信事業者Ｘは、必要に応じて、この申込書２１０に情報を付加した後、これを信販会社Ａへと転送する。なお、ここでは、この申込書２１０には、電子モジュール１００内のモジュールＩＤ格納部１６０に格納されているモジュールＩＤが予め記載されているものとする。

信販会社Ａは、ユーザＹから送られてきた申込書２１０を受信したら、通常の入会審査を行い、審査にパスした場合には、ユーザＹに関する個人情報を顧客データベース８００に登録するとともに、ユーザＹに対するクレジットカードの発行処理に必要なデータを、発行処理業者Ｚが管理する発行処理サーバ９００へと転送する。具体的には、申込書２１０に記載されていたユーザＹの住所・氏名・パスワード・モジュールＩＤなどを示すデータ、信販会社ＡによってユーザＹに新たに付与された会員ＩＤ、会員情報（この場合は、クレジットカード番号や有効年月などの決済情報）、本番鍵（もしくは本番鍵を生成する元になるデータ）が、発行処理サーバ９００へと転送される。

発行処理サーバ９００は、ユーザＹに関するデータ転送を受けると、まず、ユーザＹに対して通知書２２０を発行する処理を実行する。この通知書２２０には、信販会社Ａの審査にパスし、発行処理を行う準備が完了したので、携帯電話２００を用いて発行処理を受けることを促す指示や操作方法を記載しておくようにする。また、ユーザＹに対して付与された会員ＩＤも記載しておくようにする。通知書２２０は、電子メールなどを利用してユーザＹに電子データとして送付することも可能であるが、実用上は、一般のクレジットカードの送付と同様に、発行処理サーバ９００に接続されているプリンタから、必要な情報を紙面上に印刷し、書留郵便などを利用して書面として送付するようにするのが好ましい。

通知書２２０を受け取ったユーザＹは、この通知書２２０に記載されている操作方法に基づいて、信販会社Ａについてのクレジットカードの発行処理を受けるための操作を行う。この操作は、たとえば、携帯電話２００のＷｅｂブラウザ機能を利用して、発行処理サーバ９００が提供する所定のＷｅｂページをアクセスする操作でもよいし、発行処理用の専用プログラムを発行処理サーバ９００からダウンロードして、携帯電話２００内部のメモリや電子モジュール１００内のメモリにインストールした上で、当該プログラムを起動する操作でもよい。前者の場合は、携帯電話２００側のＷｅｂブラウザプログラムと、発行処理サーバ９００側のＷｅｂページに関連して動作する処理プログラムとの連携動作により、発行処理が実行されることになる。また、後者の場合は、携帯電話２００もしくは電子モジュール１００にインストールされたプログラムと発行処理サーバ９００側のプログラムとの連携動作により、発行処理が実行されることになる。いずれの場合でも、携帯電話２００と発行処理サーバ９００との間には、移動体通信網やインターネットを介した通信路が形成され、この通信路を介して情報のやりとりが行われる。

後に詳述するように、この発行処理により、発行処理サーバ９００から携帯電話２００に対して、Ａ社用の本番鍵が送信され、電子モジュール１００内の鍵格納部１５１Ａに格納されていた初期鍵が、Ａ社用の本番鍵に書き換えられ、更に、Ａ社用の決済情報が送信され、電子モジュール１００内の会員情報格納部１５２Ａに格納されることになる。こうして、発行処理が完了すると、発行処理サーバ９００から、信販会社Ａ側の顧客データベース８００に対して、ユーザＹに対する発行処理が完了した旨の報告がなされる。また、必要に応じて、通信事業者Ｘに対しても、何らかの報告を行うようにしてもよい。以後、ユーザＹは、図３のブロック図に示すように、携帯電話２００をＡ社から発行されたクレジットカードとして利用して、種々の決済を行うことができる。なお、Ｂ社およびＣ社についてもクレジットカードの発行処理を受ける場合は、上述したプロセスを、Ｂ社およびＣ社についても実行すればよい。

＜＜＜ §４．具体的な発行処理の手順 ＞＞＞
続いて、発行処理サーバ９００と携帯電話２００との交信により実行される具体的な発行処理の手順を、図６の流れ図を参照しながら説明する。まず、ステップＳ１において、モジュールＩＤの確認処理が行われる。この処理は、現在アクセス中の携帯電話２００に装着されている電子モジュール１００が、通信事業者Ｘから提供された正規の電子モジュールであることを確認するための処理である。この処理では、まず、モジュールＩＤ格納部１６０に格納されているモジュールＩＤが、携帯電話２００側へと読み出され、発行処理サーバ９００へと送信される。発行処理サーバ９００は、送信されてきたモジュールＩＤが、通信事業者Ｘから提供された正規の電子モジュールのモジュールＩＤであることを確認する処理を実行するとともに、このモジュールＩＤを参照することにより、ユーザＹに対する発行処理を行うために必要な発行データをデータベースから取り出す処理を実行する。

続いて、ステップＳ２において、ユーザ確認の処理が行われる。前述のように、この発行処理は、通知書２２０を受け取ったユーザＹが、携帯電話２００を用いて、発行処理サーバ９００へアクセスすることにより開始するが、発行処理サーバ９００は、セキュリティを確保する必要上、アクセスを求めてきた者が、通知書２２０を受け取ったユーザＹ本人であることを確認した上で、以後の処理を続行することになる。

この実施形態では、ユーザＹに、会員ＩＤおよびパスワードを入力させることにより、ユーザ確認を行うようにしている。パスワードは、ユーザＹ自身が、申込書２１０に記入したものであり、会員ＩＤは、通知書２２０に記載されている情報であるから、ユーザＹ本人であれば、いずれも認識している情報である。そこで、ユーザＹに、携帯電話２００のプッシュボタンから、会員ＩＤおよびパスワードを入力させた上で、これを発行処理サーバ９００へと送信する処理を行うようにする。発行処理サーバ９００は、送信されてきた会員ＩＤおよびパスワードが正しいものであることをチェックすることにより、現在アクセス中の者がユーザＹであることを確認することできる。なお、ユーザ確認の処理は、必ずしも会員ＩＤおよびパスワードの両方を用いて行う必要はなく、いずれか一方のみを用いて行うようにしてもかまわない。

こうして、ステップＳ１におけるモジュールＩＤ確認処理と、ステップＳ２におけるユーザ確認処理との双方において、正しい確認が行われた場合に、ステップＳ３以降の処理が行われる。なお、モジュールＩＤ確認処理とユーザ確認処理の順序は、上述の例と逆にしてもかまわない。ただ、上述の例のように、モジュールＩＤ確認処理を先に行うようにすると、ユーザ確認処理の手順を実施している間に、先に読み出したモジュールＩＤを利用して、ユーザＹに対する発行処理を行う際の準備を行うことができる。また、ここに示す実施形態では、データ格納部１５０内に３つの領域が設けられているが、ステップＳ３〜Ｓ５の処理は、この３つの領域の中から選択された１つの領域を対象として実行される。ここでは、説明の便宜上、第１の領域、すなわち、図２に示す鍵格納部１５１Ａおよび会員情報格納部１５２Ａからなる領域が選択されたものとして、以下の説明を行う（領域の選択は、まだ発行処理が実行されていない領域であれば、いずれの領域を選択してもかまわない）。

まず、ステップＳ３では、電子モジュール１００内に格納されている初期鍵の認証処理が行われる。ここで述べる実施形態の場合、発行処理サーバ９００によって、電子モジュール１００内の鍵格納部１５１Ａに格納されている初期鍵が、正規の初期鍵であることを確認するための手順が実行されることになる。本発明における初期鍵は、本番鍵に書き換えられるまでの暫定鍵としての役割を果たし、ステップＳ３において、初期鍵が正しく認証された場合に限り、次のステップＳ４における鍵書換処理が実行されることになる。また、後述するように、ステップＳ４における鍵書換処理では、初期鍵を利用したセキュリティ確保が行われる。

初期鍵も本番鍵も、本質的には秘密の鍵であり、一般公衆に対しては決して公開されることがない、という点において、両者は共通する。しかしながら、本番鍵が、特定の会員サービスを提供する事業体およびその委託を受けた者のみによって知られている非常に限定的な秘密鍵であるのに対して、初期鍵は、より多数の事業体によって知られた鍵である点で、両者は相違する。たとえば、図４の鍵格納部１５１Ａに書き込まれているＡ社用の本番鍵は、信販会社Ａによって設定された鍵であり、信販会社Ａとその委託を受けた発行処理業者Ｚのみが知りうる非常に限定的な秘密鍵である。これに対して、図２の鍵格納部１５１Ａに書き込まれている初期鍵は、信販会社Ａ，Ｂ，Ｃといった多数の信販会社、通信事業者Ｘを始めとする多数の通信事業者、発行処理業者Ｚを始めとする多数の発行処理業者、といった関連業者の間で共通して知られている鍵であり、各本番鍵に比べると、それだけセキュリティが緩い鍵ということができる。

なお、前述したように、本実施形態では、個々の電子モジュール１００内に予め格納されている初期鍵は、当該電子モジュール１００のモジュールＩＤを用いて所定のアルゴリズムに基づく演算を行うことにより一義的に生成されるデジタルデータである。したがって、初期鍵は、「関連業者の間で共通して知られている鍵」ではあるが、実際に「関連業者の間で共通して知られている事項」は、個々の初期鍵を構成するデジタルデータ自体ではなく、「初期鍵を生成するために行われる演算のアルゴリズム」である。より具体的には、所定のデジタルデータからなるマスター鍵と所定のアルゴリズムとが、関連業者の間で知られていることになる。各関連業者は、特定の電子モジュール１００内のモジュールＩＤ格納部１６０から、当該電子モジュール１００についてのモジュールＩＤを読み出す操作を行い、読み出したモジュールＩＤと上述したマスター鍵とを合成（たとえば、モジュールＩＤを構成するＮビットのデジタルデータに、マスター鍵を構成するＭビットのデジタルデータを付加して、Ｎ＋Ｍビットのデジタルデータを作成）した上で、上述した所定のアルゴリズムに基づく演算を施すことにより、当該モジュールＩＤに対応した初期鍵を生成することができる。

したがって、発行処理業者Ｚの管理下にある発行処理サーバ９００は、ステップＳ２で読み出したモジュールＩＤにマスター鍵を合成した上で、所定のアルゴリズムに基づく演算を施すことにより、当該モジュールＩＤに対応した初期鍵を生成することができるので、この生成した初期鍵が、鍵格納部１５１Ａに書き込まれていた初期鍵と一致することを確認することにより、初期鍵の認証を行うことができる。なお、この一致確認を行う際に、鍵格納部１５１Ａに書き込まれている初期鍵を、携帯電話２００側に読出し、これを発行処理サーバ９００へと送信させる方法を採ることも可能であるが、実用上は、秘密の鍵をそのまま読み出し、これを一般通信路を介して送信するのは好ましくない。そこで、本実施形態では、次のような手順で、ステップＳ３の初期鍵の認証処理を行っている。

まず、発行処理サーバ９００側で、乱数Ｒ１を発生し、これを電子モジュール１００側へと送信する。電子モジュール１００側では、別途、乱数Ｒ２を発生するとともに、鍵格納部１５１Ａに格納されている初期鍵に基づいて所定のセッション鍵を生成する。そして、乱数Ｒ１，Ｒ２および生成したセッション鍵に対して、所定のアルゴリズムＡ１に基づく演算を行い、カード側暗号データＣＣを生成する。そして、このカード側暗号データＣＣと乱数Ｒ２とを、電子モジュール１００から携帯電話２００を介して、発行処理サーバ９００へと送信するのである。

一方、発行処理サーバ９００側では、電子モジュール１００から読み出したモジュールＩＤに対応した初期鍵を生成し、この初期鍵に基づいて上述と同様の方法でセッション鍵を生成する。そして、先程発生させた乱数Ｒ１と，電子モジュール１００側から送信されてきた乱数Ｒ２と、生成したセッション鍵に対して、上記アルゴリズムＡ１に基づく演算を行い、カード側暗号データＣＣを生成する。そして、この発行処理サーバ９００側で発生させたカード側暗号データＣＣが、電子モジュール１００側から送信されてきたカード側暗号データＣＣに一致することが確認できれば、現在交信中の電子モジュール１００内の初期鍵が正規のものであると認証するのである。

なお、本実施形態では、上記プロセスと全く逆の手順により、電子モジュール１００側が発行処理サーバ９００側を正規のサーバであると認識するプロセスも実行するようにしており、相互の認証に成功した場合に、ステップＳ４以降の処理が実行されるようにしている。

続くステップＳ４では、初期鍵を本番鍵に書き換える鍵書換処理が実行される。すなわち、発行処理サーバ９００から電子モジュール１００に宛てて、所定の本番鍵を送信し、電子モジュール１００内部で、初期鍵を本番鍵に書き換える処理を実行させる。ここで述べる実施形態の場合、Ａ社用の本番鍵が、電子モジュール１００に宛てて送信され、鍵格納部１５１Ａ内に格納されていた初期鍵が、Ａ社用の本番鍵に書き換えられる。ただし、この鍵書換処理は、「初期鍵を利用したセキュリティ確保」を行いながら実行されることになる。以下、その具体的な手法を述べる。

本実施形態では、「初期鍵を利用したセキュリティ確保」を行うために、次の２通りの手法を採っている。第１の手法は、発行処理サーバ９００側で、本番鍵に対して、初期鍵を暗号化のキーとして利用した暗号化を行い、暗号化された状態の本番鍵を電子モジュール１００側へと送信する手法である。初期鍵を暗号化のキーとして利用した暗号化を行った場合、暗号化された状態の本番鍵を元の状態に復号化するには、暗号化のキーとなる初期鍵が必要であるので、万一、通信路上で、送信途上の本番鍵が漏洩したとしても、初期鍵がわからない以上、復号化することはできない。電子モジュール１００側では、鍵書換処理部１２０が、暗号化された状態で本番鍵を受け取り、これを初期鍵を利用して復号化すれば、本番鍵の安全な受け渡しが可能になる。

そして、第２の手法は、発行処理サーバ９００側で、本番鍵に初期鍵を付加した状態で何らかの認証コードを生成し（たとえば、Full Triple DES MACなど）、本番鍵をこの認証コードとともに電子モジュール１００側へと送信する手法である。この手法は、通信路上での本番鍵の漏洩という事態に対処することはできないが、偽の発行処理サーバ９００になりすましたハッカーからの攻撃に対しては、セキュリティを高める効果を発揮する。すなわち、電子モジュール１００側では、本番鍵とともに認証コードを受け取ることができるので、この認証コードを用いた正当性チェックを実施することが可能になる。具体的には、電子モジュール１００内の鍵書換処理部１２０において、受け取った本番鍵に、鍵格納部１５１Ａに格納されていた初期鍵を付加した状態で認証コードを生成する処理を実行させ、生成した認証コードと受け取った認証コードとの一致を確認させればよい。初期鍵を知らないハッカーは、正しい認証コードを生成することができないので、当該ハッカーから偽の発行処理サーバ９００になりすました攻撃があったとしても、ステップＳ４が実行されることはなく、初期鍵が偽の本番鍵に書き換えられることはない。また、この認証コードを用いる手法は、通信経路の途中でデータが不正な方法で改ざんされるのを防止する効果も奏する。データの改ざんが行われると、認証コードが不一致となるため、やはりステップＳ４は実行されない。

もちろん、実用上は、上述した第１の手法と第２の手法との双方を実行し、十分なセキュリティを確保した状態で、初期鍵を本番鍵に書き換える処理が行われるようにするのが好ましい。

次のステップＳ５では、会員情報の書込処理が実行される。すなわち、発行処理サーバ９００から電子モジュール１００に宛てて、所定の会員情報を送信し、電子モジュール１００内部で、これを会員情報格納部に格納する処理が実行される。ここで述べる実施形態の場合、Ａ社用のクレジットカード決済情報が会員情報として、電子モジュール１００に宛てて送信され、会員情報格納部１５２Ａに書き込まれる。ただし、この会員情報書込処理は、「本番鍵を利用したセキュリティ確保」を行いながら実行されることになる。以下、その具体的な手法を述べる。

本実施形態では、「本番鍵を利用したセキュリティ確保」を行うために、次の２通りの手法を採っている。第１の手法は、発行処理サーバ９００側で、送信対象となる会員情報に対して、本番鍵を暗号化のキーとして利用した暗号化を行い、暗号化された状態の会員情報を電子モジュール１００側へと送信する手法である。本番鍵を暗号化のキーとして利用した暗号化を行った場合、暗号化された状態の会員情報を元の状態に復号化するには、暗号化のキーとなる本番鍵が必要であるので、万一、通信路上で、送信途上の会員情報が漏洩したとしても、本番鍵がわからない以上、復号化することはできない。電子モジュール１００側では、会員情報書込部１３０が、暗号化された状態で会員情報を受け取り、これを本番鍵を利用して復号化すれば、会員情報の安全な受け渡しが可能になる。

そして、第２の手法は、発行処理サーバ９００側で、会員情報に本番鍵を付加した状態で何らかの認証コードを生成し（たとえば、Full Triple DES MACなど）、会員情報をこの認証コードとともに電子モジュール１００側へと送信する手法である。この手法は、通信路上での会員情報の漏洩という事態に対処することはできないが、偽の発行処理サーバ９００になりすましたハッカーからの攻撃に対しては、セキュリティを高める効果を発揮する。すなわち、電子モジュール１００側では、会員情報とともに認証コードを受け取ることができるので、この認証コードを用いた正当性チェックを実施することが可能になる。具体的には、電子モジュール１００内の会員情報書込部１３０において、受け取った会員情報に、鍵格納部１５１Ａに格納されていた本番鍵を付加した状態で認証コードを生成する処理を実行させ、生成した認証コードと受け取った認証コードとの一致を確認させればよい。本番鍵を知らないハッカーは、正しい認証コードを生成することができないので、当該ハッカーから偽の発行処理サーバ９００になりすました攻撃があったとしても、ステップＳ５が実行されることはなく、偽の会員情報が書き込まれることはない。また、この認証コードを用いる手法は、データの改ざんを防止する効果も奏する。データの改ざんが行われると、認証コードが不一致となるため、やはりステップＳ５は実行されない。

もちろん、実用上は、上述した第１の手法と第２の手法との双方を実行し、十分なセキュリティを確保した状態で、会員情報を書き込む処理が行われるようにするのが好ましい。

こうして、ステップＳ５の処理が完了すれば、電子モジュール１００に対する発行処理は完了である。ただ、ここに示す実施形態では、発行処理が完了した旨を報告するために、ステップＳ６の報告処理が行われるようにしている。この処理は、図５に示すように、発行処理サーバ９００から、信販会社Ａおよび通信事業者Ｘに対して、ユーザＹに対する発行処理が完了した事実を報告する処理である。信販会社Ａに対しては、顧客データベース８００にオンラインで直接データ入力を行うことによりユーザＹに対する発行処理完了を報告することが可能である。一方、通信事業者Ｘに対しては、電子メールなどによる報告も可能であるが、発行処理サーバ９００に接続されたプリンタを用いて、特定のモジュールＩＤに関する発行処理が完了したことを示す報告書を印刷し、これを郵送してもよい。あるいは、通信事業者Ｘや信販会社Ａの担当者が、インターネット等のネットワークを経由して、発行処理サーバ９００にアクセスして、必要な情報を直接ダウンロードできるような運用形態をとることも可能であるし、ＣＭＴ（Cartride Magnetic Tape）、ＭＤ、ＦＤなどの記録媒体を利用して、必要な情報を受け渡しするようにしてもよい。

なお、ここでは、ステップＳ２〜Ｓ５の各処理の手順説明として、発行処理サーバ９００と電子モジュール１００との間の情報の流れを中心に説明したが、実際には、発行処理サーバ９００が電子モジュール１００と直接交信しているわけではなく、両者間には携帯電話２００が仲介役として機能していることになる。ここで述べる実施形態の場合、電子モジュール１００は、ＵＩＭと呼ばれるＩＣカードであり、携帯電話２００と電子モジュール１００との間の交信は、携帯電話２００側から電子モジュール１００側に所定のコマンドを与えると、電子モジュール１００側でこのコマンドに基づく処理が実施され、携帯電話２００側にレスポンスが返されるという手順を繰り返し実行することによって行われる。

したがって、たとえば、ステップＳ４の処理は、通信部１１０を介して携帯電話２２０から、「初期鍵を所定の本番鍵に書き換えるべき鍵書換命令」が与えられることにより、鍵書換処理部１２０によって実行されることになる。同様に、ステップＳ５の処理は、通信部１１０を介して携帯電話２００から、「会員情報格納部に所定の会員情報を書き込むべき会員情報書込命令」が与えられることにより、会員情報書込部１３０によって実行されることになる。また、発行処理が完了した後、ユーザが実在の店舗や仮想店舗において行う決済処理は、通信部１１０を介して携帯電話２００から、「会員情報提示命令」が与えられることにより、会員情報提示部１４０によって実行されることになる。

＜＜＜ §５．その他の変形例 ＞＞＞
(1) 図６のステップＳ１〜Ｓ５までの手順は、上述したように、携帯電話２００と発行処理サーバ９００との間に所定の通信路が確保された状態で行われる処理であるため、通信環境にトラブルが生じると、中断せざるを得なくなる。そこで、実用上は、発行処理サーバ９００側に、特定の電子モジュール１００に対する一連の発行処理手順を実行する際に、どの段階まで進展したかを示すステータス情報を記録する機能をもたせておき、万一、通信環境にトラブルが生じて途中の段階で処理が中断した場合には、通信環境の復旧時には、可能な限り中断した時点からの継続処理が実行されるようにしておくのが好ましい。

(2) 図２に示すデータ格納部１５０には、３つの領域が定義されており、必要に応じて、図４に示す例のように、３つの異なる信販会社Ａ，Ｂ，Ｃについての発行処理をそれぞれ行うことが可能である。もちろん、このような領域は必ずしも３つ設けておく必要はなく、１つだけでもよいし、２つ、あるいは４つ以上設けるようにしてもかまわない。

(3) 上述の実施形態では、暗号化や認証コードの生成に、初期鍵そのもの、あるいは本番鍵そのものを用いる例を述べたが、その代わりに、初期鍵や本番鍵から派生的に生成されるセッション鍵を用いるようにしてもかまわない。

(4) 上述の実施形態では、電子モジュール１００をクレジットカードとして利用する例を述べたが、本発明は、このようなクレジットカードへの利用に限定されるものではない。本発明は、携帯電話に装着して用いる電子モジュールに、何らかの会員情報を格納し、必要に応じて、この会員情報を外部に提示する処理を行う用途に広く適用可能である。たとえば、商品の購入や役務の利用に応じて、会員に対して所定のサービスポイントを付与し、蓄積されたサービスポイントによって、景品との引き換えや割引という特典を付与するようなサービスカードとしての機能を電子モジュールに付加するような場合にも、本発明を適用することが可能である。この場合、発行処理により、電子モジュール内に会員番号などの会員情報を書き込むようにし、会員が当該サービスカードを利用する際には、携帯電話を介して、電子モジュール内に格納されていた会員情報を外部に提示することになる。

(5) 図２に示す電子モジュール１００の構成要素となる鍵書換処理部１２０，会員情報書込部１３０，会員情報提示部１４０は、前述したとおり、実際にはモジュール内に組み込まれたプログラムによって実現される要素である。したがって、これらのプログラムは、携帯電話２００の販売時点では備わっていなくても、後日、携帯電話２００を利用したダウンロード操作により、電子モジュール１００内に追加することが可能である。

(6) 上述の実施形態では、初期鍵や本番鍵が単一の暗号鍵から構成されている例を述べたが、これらの鍵を、それぞれ目的の異なる複数の暗号鍵（たとえば、それぞれ３つの暗号鍵）から構成してもかまわない。このように、本願における初期鍵や本番鍵は、目的別の複数の暗号鍵からなる、いわゆる鍵セットも含むものである。

(7) 図５に示す顧客データベース８００から発行処理サーバ９００へのデータの受け渡しは、必ずしもオンラインで行う必要はない。たとえば、信販会社Ａの担当者が、クレジットカードの発行処理に必要なデータを顧客データベース８００から取り出し、これを何らかの方法で発行処理業者Ｚの担当者へ引き渡すような方法をとってもかまわない。この場合、実用上は、何人分かのデータをまとめて引き渡すようにするのが好ましい。また、信販会社Ａから引き渡されたデータが、電子モジュール１００に対して直接書き込める形式のデータになっていない場合には、発行処理業者Ｚは、必要に応じて、引き渡されたデータに基づいて書込用のデータを生成する処理を行い、これを発行処理サーバ９００に登録するようにすればよい。

本発明に係る電子モジュール１００およびこれを装着する携帯電話２００の外観の一例を示す正面図である。 携帯電話に添付して市場に流通させた時点における電子モジュール１００の構成を示すブロック図である。 発行処理が完了した後の電子モジュールを装着した携帯電話のクレジットカードとしての利用形態の一例を示すブロック図である。 信販会社Ａ，Ｂ，Ｃの３社から、それぞれ発行処理を受けた場合の電子モジュール１００のデータ格納部１５０内の状態を示すブロック図である。 本発明に係る会員情報提示用電子モジュールの発行処理に至るまでの具体的なプロセスを示すブロック図である。 図５に示す発行処理サーバ９００と携帯電話２００との交信により実行される具体的な発行処理の手順を示す流れ図である。

符号の説明

１００…電子モジュール
１１０…通信部
１２０…鍵書換処理部
１３０…会員情報書込部
１４０…会員情報提示部
１５０…データ格納部
１５１Ａ〜１５１Ｃ…鍵格納部
１５２Ａ〜１５２Ｃ…会員情報格納部
１６０…モジュールＩＤ格納部
２００…携帯電話
２１０…申込書
２２０…通知書
３００…店舗端末
４００…決済ネットワーク
５１０…Ａ社用ホスト
５２０…Ｂ社用ホスト
５３０…Ｃ社用ホスト
６００…移動体通信網
６１０…移動体通信網のゲートウェイサーバ
７００…インターネット
７１０…決済用ゲートウェイサーバ
７２０…ネットショップ用サーバ
８００…顧客データベース
９００…発行処理サーバ
Ｓ１〜Ｓ６…流れ図の各ステップ

Claims (4)

1. 携帯電話に装着することにより、当該携帯電話を用いた会員情報提示処理を可能にするための電子モジュールであって、
   携帯電話との間で情報のやりとりを行う通信部と、
   所定の初期鍵が格納された鍵格納部と、提示対象となる会員情報を格納するための会員情報格納部と、の対によって構成されている領域が、複数組確保されているデータ格納部と、
   前記通信部を介して前記携帯電話から、特定の選択領域についての前記初期鍵を所定の本番鍵に書き換えるべき鍵書換命令が与えられたときに、前記初期鍵を利用したセキュリティ確保を行いながら、前記選択領域についての前記鍵格納部内の前記初期鍵を前記本番鍵に書き換える処理を行う鍵書換処理部と、
   前記通信部を介して前記携帯電話から、前記選択領域についての前記会員情報格納部に所定の会員情報を書き込むべき会員情報書込命令が与えられたときに、前記選択領域についての前記本番鍵を利用したセキュリティ確保を行いながら、前記選択領域についての前記会員情報格納部内に前記所定の会員情報を書き込む処理を行う会員情報書込部と、
   前記通信部を介して前記携帯電話から、所定領域についての会員情報提示命令が与えられたときに、前記所定領域についての前記会員情報格納部内に格納されている会員情報を外部に読み出して提示する処理を行う会員情報提示部と、
   を備え、
   前記複数組の各領域内に格納されている初期鍵は、互いに同一の共通初期鍵となっており、
   前記鍵書換処理部は、前記書き換える処理を行う際に、前記初期鍵を用いた暗号化処理により暗号化された状態で前記本番鍵を受け取り、これを電子モジュール内部で復号化することにより第１の書換用セキュリティ確保を行うとともに、前記初期鍵を用いて作成された認証コードとともに前記本番鍵を受け取り、この認証コードを用いた正当性チェックにより第２の書換用セキュリティ確保を行い、
   前記会員情報書込部は、前記書き込む処理を行う際に、前記本番鍵を用いた暗号化処理により暗号化された状態で前記会員情報を受け取り、これを電子モジュール内部で復号化することにより第１の書込用セキュリティ確保を行うとともに、前記本番鍵を用いて作成された認証コードとともに前記会員情報を受け取り、この認証コードを用いた正当性チェックにより第２の書込用セキュリティ確保を行うことを特徴とする携帯電話に装着して用いる会員情報提示用電子モジュール。
2. 請求項１に記載の会員情報提示用電子モジュールにおいて、
   会員情報書込部が、会員情報として、クレジットカード会員がカード決済を行うために必要な決済情報を書き込む処理を行い、携帯電話を利用した決済処理を行うことができるようにしたことを特徴とする携帯電話に装着して用いる会員情報提示用電子モジュール。
3. 電子モジュールを、請求項１または２に記載された会員情報提示用電子モジュールとして機能させるためのプログラム。
4. 電子モジュールを、請求項１または２に記載された会員情報提示用電子モジュールとして機能させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。