(57)【要約】【課題】中継サーバにタンパ技術を組み込む必要無く、センタサーバの負荷を軽減できるようにする。【解決手段】各決済端末６は定期的に中継サーバ５へ鍵要求を送信する。この鍵要求には自端末が保持している秘匿鍵のバージョン情報が付加されており、中継サーバ５はこれが自己が保持するバージョン情報と不一致の場合のみ、センタサーバ１へアクセスして新たな秘匿鍵を取得して要求元の端末６へ渡す。この秘匿鍵は暗号化されており、復号化の為の鍵は、各決済端末６は持っているが中継サーバ５は保持していない。【選択図】図１
2008197817.tif 000002
【特許請求の範囲】
【請求項１】
電子マネー機能を有するＩＣカードに対して秘匿鍵を用いた電子マネー決済処理を行う複数の決済端末と、該各決済端末とネットワークを介して接続された中継サーバと、該中継サーバとネットワークを介して接続されたセンタサーバとからなる電子マネーシステムにおいて、
前記各決済端末は、定期的に、前記中継サーバを介して前記センタサーバに対する鍵要求を送る確認・更新手段を備え、
前記中継サーバは、前記鍵要求を受信する毎に、該要求元の決済端末が保持している前記秘匿鍵を更新する必要があるか否かを判定し、更新する必要がある場合には前記センタサーバにアクセスして新たな秘匿鍵を取得して該新たな秘匿鍵を前記要求元の決済端末へ転送する更新中継手段を有し、
前記各決済端末は、該中継サーバから前記新たな秘匿鍵が転送された場合、その後は該新たな秘匿鍵を用いて前記ＩＣカードに対する電子マネー決済処理を行うことを特徴とする電子マネーシステム。
【請求項２】
前記センタサーバから取得する新たな秘匿鍵は暗号化されており、前記中継サーバの更新中継手段は、該暗号化された秘匿鍵をそのまま前記要求元の決済端末へ転送することを特徴とする請求項１記載の電子マネーシステム。
【請求項３】
前記中継サーバの更新中継手段は、前記定期的な鍵要求送信を行う各決済端末のうち、所定期間内において最初に鍵要求送信を行った決済端末からの該鍵要求を受信した場合、無条件で、前記センタサーバから暗号化された秘匿鍵を取得して該取得した秘匿鍵を該要求元の決済端末へ転送し、
該最初に鍵要求送信を行った決済端末は、該暗号化された秘匿鍵を復号化して該秘匿鍵及びそのバージョン情報を取得して記憶すると共に該バージョン情報を前記中継サーバに送信して記憶させ、
前記各決済端末は、自端末が保持している秘匿鍵のバージョン情報を前記鍵要求に付加して送信し、
前記中継サーバの更新中継手段は、前記最初に鍵要求送信を行った決済端末以外の決済端末から前記バージョン情報が付加された鍵要求を受信した場合、該付加されたバージョン情報と前記記憶しているバージョン情報とが不一致の場合には、該要求元の決済端末が保持している前記秘匿鍵を更新する必要があると判定することを特徴とする請求項１記載の電子マネーシステム。
【請求項４】
電子マネー機能を有するＩＣカードに対して秘匿鍵を用いた電子マネー決済処理を行う複数の決済端末と、該各決済端末とネットワークを介して接続された中継サーバと、該中継サーバとネットワークを介して接続されたセンタサーバとからなる電子マネーシステムにおける前記中継サーバであって、
任意の前記決済端末からの鍵要求を受信する毎に、該要求元の決済端末が保持している前記秘匿鍵を更新する必要があるか否かを判定し、更新する必要がある場合には前記センタサーバにアクセスして新たな秘匿鍵を取得して該新たな秘匿鍵を前記要求元の決済端末へ転送する更新中継手段、
を有することを特徴とする中継サーバ。
【請求項５】
電子マネー機能を有するＩＣカードに対して秘匿鍵を用いた電子マネー決済処理を行う複数の決済端末と、該各決済端末とネットワークを介して接続された中継サーバと、該中継サーバとネットワークを介して接続されたセンタサーバとからなる電子マネーシステムにおける前記中継サーバのコンピュータに、
任意の前記決済端末からの鍵要求を受信する毎に、該要求元の決済端末が保持している
前記秘匿鍵を更新する必要があるか否かを判定し、更新する必要がある場合には前記センタサーバにアクセスして新たな秘匿鍵を取得して該新たな秘匿鍵を前記要求元の決済端末へ転送する機能、
を実現させる為のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、非接触ICカード（以下ICカード）を用いた電子マネー用の決済端末を用い、投入金額分の電子マネーをICカードに入金、積み増ししたり、商品やサービス購入時の利用額分の電子マネーをICカードから差し引いたりする電子マネーシステムに関する。
【背景技術】
【０００２】
今日、電車やバスなどの公共交通手段や、各種商店等において、ＩＣカード（非接触型又は接触型のＩＣカード；以下特に区別せずにＩＣカードと記す）を用いた電子マネーを使用するキャッシュレス決済システム（電子マネーシステム）が導入されている。このようなシステムでは、ＩＣカードへの入金処理や、利用額の差引き処理を始めとするＩＣカードへのアクセス処理（電子マネー決済処理）を、ＩＣカードＲ／Ｗ（リーダ／ライタ）を有する決済端末が行なっている。
【０００３】
電子マネーを用いた決済システムでは、ＩＣカードへの不正なアクセス（入金せずに利用額を積みましや利用履歴を書換え等）を防ぐために、決済端末とＩＣカードとの通信において、秘匿鍵による認証を行なったり、通信を暗号化したりするなどして、安全性を高めている。
【０００４】
この秘匿鍵は、一元管理および決済端末への配信を可能とするため、センタサーバで管理されており、決済端末は、このセンタサーバにアクセスすることで秘匿鍵を獲得する。その際、この秘匿鍵は輸送鍵と呼ばれる鍵で暗号化されて配信される。決済端末側では、受信した秘匿鍵を輸送鍵で復号化して自端末内に保持するが、そのために決済端末にはタンパ技術（端末への不正アクセスやデータ改ざんを物理的及び論理的に防衛する既存技術）が用いられており、輸送鍵および秘匿鍵を安全に格納することが出来る。
【０００５】
この秘匿鍵は、変更される場合もあるため（バージョンアップ等）、決済端末ではその変更有無を確認するために、定期的に（例えば毎日の端末起動時等）、センタサーバにアクセスする必要がある。この為、秘匿鍵の変更有無に関わらず、例えば決済端末起動時等に必ずセンタサーバにアクセスすることになってしまう。そのため、決済端末の設置台数が増加するに従い、センタサーバにおける通信負荷が日常的に増加するという問題があり、また、それを解決するための、例えばセンタサーバ増強などの施策にかかるコスト増も問題となる。
【０００６】
このような問題を解決する手段として、以下の特許文献１に記載の発明では、センタサーバと決済端末との間に中継するサーバを設置し、中継サーバがセンタサーバから秘匿鍵を受信してそこから決済端末への配信を実施することで、センタサーバへの通信負荷を削減している。
【特許文献１】特開２００２−７３９７３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかし、上記特許文献１の発明では、中継サーバにおいて秘匿鍵を保持、管理する必要がある。そのため、秘匿鍵の漏洩や改ざんを防ぐために、中継サーバにタンパ技術を組み込む必要がある。また、サーバ用のオペレーティングシステムには通常一般的に利用されているものが用いられることが多く、詳細な知識を必要とせずサーバ内へのアクセスが可能であるため、中継サーバの設置場所や運用管理規定等を定める必要があり、逆にコストが増加することが考えられる。
【０００８】
本発明の課題は、中継サーバを設ける電子マネーシステムにおいて、中継サーバにおいて秘匿鍵を保持、管理する必要無く（中継サーバにタンパ技術を組み込む必要無く）、コスト増となることなく、センタサーバの負荷を軽減できる電子マネーシステム、その中継サーバ、プログラム等を提供することである。
【課題を解決するための手段】
【０００９】
本発明の電子マネーシステムは、電子マネー機能を有するＩＣカードに対して秘匿鍵を用いた電子マネー決済処理を行う複数の決済端末と、該各決済端末とネットワークを介して接続された中継サーバと、該中継サーバとネットワークを介して接続されたセンタサーバとからなる電子マネーシステムにおいて、前記各決済端末は、定期的に、前記中継サーバを介して前記センタサーバに対する鍵要求を送る確認・更新手段を備え、前記中継サーバは、前記鍵要求を受信する毎に、該要求元の決済端末が保持している前記秘匿鍵を更新する必要があるか否かを判定し、更新する必要がある場合には前記センタサーバにアクセスして新たな秘匿鍵を取得して該新たな秘匿鍵を前記要求元の決済端末へ転送する更新中継手段を有し、前記各決済端末は、該中継サーバから前記新たな秘匿鍵が転送された場合、その後は該新たな秘匿鍵を用いて前記ＩＣカードに対する電子マネー決済処理を行う。
【００１０】
上記センタサーバが秘匿鍵を管理しており、秘匿鍵は変更される場合がある。この為、各決済端末は定期的にセンタサーバに問い合わせて、秘匿鍵が変更されている場合には、新たな秘匿鍵を取得して自己の秘匿鍵を更新する必要があるが、更新する必要が無い場合、すなわちセンタサーバ側で秘匿鍵が変更されていない場合には、中継サーバの判断により、センタサーバへのアクセスは行われない。これによって、実質的に無意味なアクセスによって通信負荷が増大する事態を回避できる。
【００１１】
上記電子マネーシステムにおいて、例えば、前記センタサーバから取得する新たな秘匿鍵は暗号化されており、前記中継サーバの更新中継手段は、該暗号化された秘匿鍵をそのまま前記要求元の決済端末へ転送する。
【００１２】
中継サーバが秘匿鍵を保持することはなく、中継サーバにタンパ技術を適用する必要はない。
上記電子マネーシステムにおいて、例えば、前記中継サーバの更新中継手段は、前記定期的な鍵要求送信を行う各決済端末のうち、所定期間内において最初に鍵要求送信を行った決済端末からの該鍵要求を受信した場合、無条件で、前記センタサーバから暗号化された秘匿鍵を取得して該取得した秘匿鍵を該要求元の決済端末へ転送し、該最初に鍵要求送信を行った決済端末は、該暗号化された秘匿鍵を復号化して該秘匿鍵及びそのバージョン情報を取得して記憶すると共に該バージョン情報を前記中継サーバに送信して記憶させ、前記各決済端末は、自端末が保持している秘匿鍵のバージョン情報を前記鍵要求に付加して送信し、前記中継サーバの更新中継手段は、前記最初に鍵要求送信を行った決済端末以外の決済端末から前記バージョン情報が付加された鍵要求を受信した場合、該付加されたバージョン情報と前記記憶しているバージョン情報とが不一致の場合には、該要求元の決済端末が保持している前記秘匿鍵を更新する必要があると判定するようにしてよい。
【発明の効果】
【００１３】
上記本発明の電子マネーシステム、その中継サーバ、プログラム等によれば、中継サーバにおいて秘匿鍵を保持、管理する必要無く（中継サーバにタンパ技術を組み込む必要無く）、コスト増となることなく、センタサーバの負荷を軽減できる。
【発明を実施するための最良の形態】
【００１４】
以下、図面を参照して、本発明の実施の形態について説明する。
図１に本発明の電子マネーシステム全体の構成例を示す。図２、図３にそれぞれ、図１における決済端末、中継サーバの構成例を示す。
【００１５】
図１に示す電子マネーシステムでは、まず、センタサーバ１と中継サーバ５とが、ネットワーク２を介して通信可能な構成となっている。尚、中継サーバ５は、例えば図示のように、ＩＳＰ（Internet Service Provider;プロバイダ）３、ＡＤＳＬ機器４を介して、ネットワーク２に接続している。
【００１６】
また、この中継サーバ５及び複数の決済端末６（各店舗に１台以上設置されている）はネットワーク７に接続されており、各決済端末６はネットワーク７を介して中継サーバ５との通信を行う。
【００１７】
各決済端末６は、電子マネー機能を有するICカードメディア（ICカード等）との間で接触型又は非接触型の通信を行って、ICカードに記憶される金額データの積み増し／差し引き等を行ったり、履歴書込み等を行う（電子マネー決済処理を行う）。
【００１８】
上述した従来技術で説明した通り、各決済端末６がＩＣカードとの通信を行う為に必要となる秘匿鍵は、センタサーバ１において管理されており、更新される場合がある。秘匿鍵情報の中には、その鍵のバージョン情報も含まれている。秘匿鍵は、通信によって決済端末６に配信される際、輸送鍵という別の鍵で暗号化される。そのため、それを受信する決済端末６でも同様の輸送鍵が必要となり、決済端末６内部のタンパ性を有する記憶領域に格納されている。勿論、秘匿鍵も、当該タンパ性を有する記憶領域に安全に格納されている。
【００１９】
図２に示すように、決済端末６は、主局（上位コントローラ）１０と従局（カード制御ユニット）２０とから成る。従局２０は、主制御部２１（ＣＰＵ等）、記憶装置（不揮発性）２２、記憶装置２３（揮発性）、通信制御部（対主局）２４、通信制御部２５、通信制御部（対カード）２６、及びＲ／Ｗ（リーダライタ）２７等から成り、特に図示しないが、上記の通り、タンパ技術が適用されている。
【００２０】
主制御部２１（ＣＰＵ等）は、当該従局２０全体を制御する中央処理装置である。
記憶装置（不揮発性）２２は、例えばフラッシュメモリ等の不揮発性のメモリ等であり、例えば後述する図４、図５のフローチャートに示す決済端末６の処理を、主制御部２１（ＣＰＵ等）により実行させる為の所定のアプリケーションプログラムが記憶されている。また、上記輸送鍵や、秘匿鍵、そのバージョン情報等も格納されている。
【００２１】
記憶装置２３（揮発性）は、例えばＲＡＭ等の揮発性メモリ等である。
通信制御部（対主局）２４は主局（上位コントローラ）１０と接続されており、主局１０との通信を制御する。主制御部２１は、この通信制御部（対主局）２４を介して、主局１０との通信を行うが、本発明には特に関係しないので、特に説明しない。
【００２２】
通信制御部２５は、ネットワーク７に接続しており、このネットワーク７を介して中継サーバ５との通信を行う。
Ｒ／Ｗ（リーダライタ）２７は、ＩＣカード・リーダ／ライタであり、ここでは一例として非接触型ＩＣカードとの通信を行うものとするが、上記の通り、接触型であってもよい。通信制御部（対カード）２６は、このＲ／Ｗ（リーダライタ）２７を制御して、任意のユーザが提示するＩＣカードとの通信を行って、上述した各種電子マネー決済処理を行う。その際、上記秘匿鍵が必要となる。
【００２３】
従来技術で説明したように、この秘匿鍵は変更（バージョンアップ等）される場合があ
り、例えばバージョンアップされた場合には、新バージョンの秘匿鍵を取得する必要がある。
【００２４】
ここで、本手法では、秘匿鍵は、センタサーバ１が記憶・管理しており、中継サーバ５には記憶されないようにしている（各決済端末にも記憶されるが、既に旧バージョンとなってしまっている可能性がある）。その為、各決済端末６は、従来技術で説明したように、例えば端末起動時など定期的に、秘匿鍵の変更の有無を確認する為の通信を行うが、センタサーバ１と直接通信は行わずに、中継サーバ５が通信を中継する。そして、中継サーバ５は、必要な場合のみ、センタサーバ１との通信を行って、センタサーバ１から新たな秘匿鍵を取得して決済端末６に渡す。
【００２５】
この様な秘匿鍵の配信に係わる処理の一例は、図４、図５に示してあり、後に説明する。
図３に示す中継サーバ５は、主制御部３１（ＣＰＵ等）、記憶装置３２（不揮発性）、通信制御部３３等から成る。
【００２６】
主制御部３１（ＣＰＵ等）は、当該中継サーバ５全体を制御する中央処理装置である。
記憶装置（不揮発性）３２には、例えば後述する図４、図５のフローチャートに示す中継サーバ５の処理を、主制御部３１（ＣＰＵ等）により実行させる為の所定のアプリケーションプログラムが記憶されている。また、後述する鍵取得実施フラグ等も、記憶装置３２に記憶される。
【００２７】
通信制御部３３は、ネットワーク２やネットワーク７に接続しており、これらネットワークを介して、センタサーバ１や各決済端末６との通信を行う。
そして、本例の中継サーバ５では、秘匿鍵は記憶しないので、タンパ技術を組み込む必要はなくなる。
【００２８】
図４および図５に、秘匿鍵の配信処理フローを示す。
本例では、秘匿鍵の変更に対応するため、各決済端末６は、定期的に(例えば１日１度（例えば端末起動時）)、秘匿鍵変更有無確認の為の処理を行う。すなわち、起動時などの任意のタイミングで、決済端末６は、まず、自端末６が現在保持している秘匿鍵のバージョン情報を上記記憶装置２２から読み出して（ステップＳ１１）、センタサーバ１に対する秘匿鍵要求を、中継サーバ５へ送信する（ステップＳ１２）。この要求には、上記読出したバージョン情報を付加している。
【００２９】
中継サーバ５は、任意の決済端末６からの上記要求を受信したら（ステップＳ２１）、自らが保持する鍵取得実施フラグを読み出す（ステップＳ２２）。このフラグは、“実施済”および“未実施”のどちらかの状態をもち、例えば日付けが変わった時など１日１度の任意のタイミングで“未実施”状態にリセットされる。そして、ステップＳ２２で読み出した鍵取得実施フラグが、“実施済”状態であれば(ステップＳ２３，ＹＥＳ)ステップＳ２４へ進み、“未実施”状態であれば（ステップＳ２３，ＮＯ）ステップＳ２７へ進む。
【００３０】
ステップＳ２３の判定がＮＯとなるのは、上記鍵取得実施フラグが“未実施”状態にリセットされた後に最初に（例えば、各日毎にその日の最初に）上記秘匿鍵要求を出した決済端末６に係わる処理の場合のみである。以下、まず、鍵要求元の決済端末６が、このような最初に要求を出した決済端末６である場合の処理について説明する。
【００３１】
この場合、すなわち、鍵取得実施フラグが“未実施”の場合（ステップＳ２３，ＮＯ）、中継サーバ５は、上記要求に付加されるバージョン情報に関係なく、センタサーバ１に
アクセスして秘匿鍵配信を要求し、センタサーバ１がこの要求に応じて、輸送鍵で暗号化された秘匿鍵を配信し（ステップＳ４１）、中継サーバ５はこの秘匿鍵を受信する（ステップＳ２７）。
【００３２】
そして中継サーバ５は鍵要求元の決済端末６に対し、秘匿鍵の更新が必要であることを示す情報と共に、センタサーバより受信した“輸送鍵で暗号化された秘匿鍵”を、鍵要求に対する処理結果として応答する（ステップＳ２８、Ｓ２９）。この様に、中継サーバ５では秘匿鍵は復号化できないので、実質的に秘匿鍵を保持することはない為、タンパ技術を適用する必要はない。
【００３３】
鍵要求元の決済端末６は、上記中継サーバ５からの応答を受信すると（ステップＳ１３）、該応答内容から、秘匿鍵の更新が必要か否かを判定する（ステップＳ１４）。上記の例では、応答内容に上記“秘匿鍵の更新が必要であることを示す情報”が含まれているので、更新が必要と判定し（ステップＳ１４，ＹＥＳ）ステップＳ１５へ進む。尚、もし、後述する“秘匿鍵の更新が不要であるという情報”が応答されてきた場合には、更新は不要と判定して（ステップＳ１４，ＮＯ）そのままステップＳ１８の処理に移る。
【００３４】
更新が必要な場合、まずステップＳ１５において、自らが保持する輸送鍵で、上記“輸送鍵で暗号化された秘匿鍵”を復号化する。次に、復号した秘匿鍵の内容から秘匿鍵のバージョン情報を読み出す（ステップＳ１６）。そして、これら秘匿鍵及びそのバージョン情報を、自端末６内の所定の記憶領域（例えば記憶装置（不揮発性）２２内の所定の記憶領域）に記憶する（上書きするか、若しくは既存の秘匿鍵及びそのバージョン情報は破棄する）。
【００３５】
その後、この決済端末６は、上記所定の記憶領域に記憶されている上記“秘匿鍵のバージョン情報”を中継サーバ５に送信する（ステップＳ１８）。ステップＳ１４の判定がＮＯの場合は、既存の秘匿鍵のバージョン情報が、中継サーバ５に送信されることになるが、後述するように、この様な場合はステップＳ１８の処理は行わなくても良い。
【００３６】
中継サーバ５は、上記決済端末６から送信された“秘匿鍵のバージョン情報”を受信すると（ステップＳ３０）、中継サーバ５内の（例えば記憶装置３２内の）所定の記憶領域に、受信した“秘匿鍵のバージョン情報”を格納する（上書き等する）（ステップＳ３１）。また、自らが保持する上記鍵取得実施フラグを“実施”状態に変更する（ステップＳ３２）。
【００３７】
上述したように、本例では、複数の決済端末６がそれぞれ１日１回、中継サーバ５にアクセスして上記鍵要求を行うが、各日毎に、その日に最初に鍵要求を行った（中継サーバ５にアクセスした）端末６は、必ずセンタサーバ１から秘匿鍵を受信する。それ故、当該最初にアクセスした決済端末６が受信する秘匿鍵は、更新されたものであるとは限らない。もし、センタサーバ１側で秘匿鍵の更新が行われていないならば、ステップＳ１７の処理を行っても、実質的に、秘匿鍵及びそのバージョン情報に変更はないことになる（新バージョンとはならず、現バージョンのままとなる）。従って、この場合、ステップＳ３１の処理によって中継サーバ５側に記憶されるバージョン情報は、現バージョンとなる。
【００３８】
一方、もし、センタサーバ１側で秘匿鍵の更新が行われていたならば、ステップＳ１７の処理によって新バージョンの秘匿鍵及びそのバージョン情報が決済端末６側に記憶される共に、ステップＳ３１の処理によって中継サーバ５側に記憶されるバージョン情報は、新バージョンとなる。
【００３９】
この様に、その日に最初にアクセスしてきた決済端末６に係わる上記処理が行われた結
果、中継サーバ５側に記憶されるバージョン情報は、センタサーバ１側で秘匿鍵の更新が行われているか否かを示す情報となる。つまり、本例の中継サーバ５は、後述するステップＳ２５の判定を行うことで、各決済端末６から秘匿鍵要求があっても、センタサーバ１側で秘匿鍵の更新が行われていないならば、センタサーバ１にアクセスしないようにしているが、本例の中継サーバ５は秘匿鍵の記憶・管理は行なわないので、センタサーバ１側で秘匿鍵の更新が行われているか否かを認識できない為、例えばその日の最初に上述した処理を行うようにしている。つまり、複数の決済端末６のうち最初の１台が必ず、センタサーバ１が現在管理している秘匿鍵を受け取って、そのバージョン情報を中継サーバ５に通知している。尚、その意味で、ステップＳ１８及びステップＳ３０〜Ｓ３２の処理は、その日初めてアクセスしてきた決済端末６に係わる処理のときのみ、実行するようにしてもよい。
【００４０】
以下、上記初めてアクセスした決済端末６以外の決済端末６（つまり、２番手以降）が、秘匿鍵要求を出した場合の図４、図５の処理について説明する。
この場合、ステップＳ１１、Ｓ１２、及びステップＳ２１，Ｓ２２の処理は、上記と同じであるが、既に１台の決済端末６がセンタサーバ１から秘匿鍵を受信し、かつその秘匿鍵のバージョンを中継サーバ５に通知しているので、上記ステップＳ３２の処理により鍵取得実施フラグ設定は“済”状態となっている為、ステップＳ２３の判定は必ずＹＥＳとなる。この場合、上記ステップＳ３１で記憶したバージョン情報を読み出して（ステップＳ２４）、これが上記秘匿鍵要求に付加されているバージョン情報と一致するか否かを判定する（ステップＳ２５）。つまり、センタサーバ１が現在管理している秘匿鍵のバージョンと、今回秘匿鍵要求を出している決済端末６が保持している秘匿鍵のバージョンとが一致するか否かを比較・判定する。
【００４１】
もしセンタサーバ１において秘匿鍵の更新が行なわれていなければ、比較の結果は“一致”となる（ステップＳ２５，ＹＥＳ）。この場合、中継サーバ５は要求元の決済端末６に対して、“秘匿鍵の更新が不要であることを示す情報”を、鍵要求に対する処理結果として応答する（ステップＳ２６，Ｓ２９）。
【００４２】
決済端末６は、中継サーバ５からの応答を受信し（ステップＳ１３）、秘匿鍵の更新が必要か否かを判定するが、ここでは上記“秘匿鍵の更新が不要であることを示す情報”が応答されてくるので更新は不要と判定され（ステップＳ１４，ＮＯ）、ステップＳ１５〜Ｓ１７の秘匿鍵更新処理は行われず、ステップＳ１８へ移る。尚、上記の通り、最初にアクセスした決済端末６以外は、ステップＳ１８の処理を行わなくてもよい。
【００４３】
一方、もし、センタサーバ１において秘匿鍵の更新が行なわれていたならば、上記最初にアクセスした決済端末６に係わる処理におけるステップＳ３１によって、中継サーバ５に記憶されるバージョン情報は、新バージョンとなっている一方、他の（未アクセスの）決済端末６が保持している秘匿鍵は現バージョンのままなので、上記ステップＳ２５の判定結果はＮＯ（不一致）となる。従って、この場合には、上記ステップＳ２７、Ｓ４１の処理が行われることになる。すなわち、中継サーバ５は、センタサーバ１にアクセスして、“輸送鍵で暗号化された秘匿鍵”を取得する。そして、上記ステップＳ２８、Ｓ２９の処理を実行することで、取得した“輸送鍵で暗号化された秘匿鍵”を、要求元の決済端末６に渡す。これより、この決済端末６は、上記ステップＳ１５〜Ｓ１７の処理を実行することで、新バージョンの秘匿鍵及びそのバージョン情報を格納することになる。
【００４４】
尚、上記の通り、ステップＳ１８の処理は行わなくてもよい。
以上説明したように、本発明の電子マネーシステム、その中継サーバ、プログラム等によれば、中継サーバを設ける電子マネーシステムにおいて、中継サーバにおいて秘匿鍵を保持、管理する必要無く（中継サーバにタンパ技術を組み込む必要無く）、コスト増とな
ることなく、センタサーバ／中継サーバの通信負荷を軽減できる
すなわち、センタサーバから決済端末への秘匿鍵の配信を最初の１台分実施後、その後の各決済端末からの秘匿鍵要求に対し、センタサーバと決済端末との通信を中継する中継サーバにて、秘匿鍵の更新必要有無を判定し、不要な場合センタサーバへのアクセスを実施しないことから、決済端末の設置台数の増加に対するセンタサーバの通信負荷を抑制することができる。
【００４５】
また、中継サーバでは秘匿鍵の復号化およびその秘匿鍵自体の管理を行なわないことから、中継サーバに高度なタンパ機能を実装する必要がないため、コストを増加させずに、通信負荷抑制を実現することが出来る。
【００４６】
尚、上述した説明では、要求元の決済端末の秘匿鍵を更新する必要があるか否かを判定する為の手法の一例を示したが、この例に限らない。
例えば、センタサーバが、毎日の初めに、あるいは秘匿鍵が変更（バージョンアップ等）されたときに、現在管理している秘匿鍵のバージョン情報を中継サーバに通知して記憶させるようにしてもよい。
【００４７】
あるいは、秘匿鍵の変更は、バージョンアップに限らない。バージョンアップではない変更が行われた場合、例えば上記バージョン情報の代わりに秘匿鍵の識別番号等を用いてもよい。但し、ここでは、秘匿鍵の識別番号等もバージョン情報の一種と考えてよよい。
【図面の簡単な説明】
【００４８】
【図１】本発明の電子マネーシステム全体の構成例である。
【図２】図１に示す決済端末の構成例である。
【図３】図１に示す中継サーバの構成例である。
【図４】秘匿鍵の配信処理のフローチャート図（その１）である。
【図５】秘匿鍵の配信処理のフローチャート図（その２）である。
【符号の説明】
【００４９】
１      センタサーバ
２      ネットワーク
３      ＩＳＰ
４      ＡＤＳＬ機器
５      中継サーバ
６      決済端末
７      ネットワーク
１０      主局（上位コントローラ）
２０      従局（カード制御ユニット）
２１      主制御部（ＣＰＵ等）
２２      記憶装置（不揮発性）
２３      記憶装置（揮発性）
２４      通信制御部（対主局）
２５      通信制御部
２６      通信制御部（対カード）
２７      Ｒ／Ｗ（リーダライタ）
３１      主制御部（ＣＰＵ等）
３２      記憶装置（不揮発性）
３３      通信制御部
【図１】
2008197817.tif 000003
【図２】
2008197817.tif 000004
【図３】
2008197817.tif 000005
【図４】
2008197817.tif 000006
【図５】
2008197817.tif 000007