決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム
【課題】電子マネー事業者が電子マネー決済処理の決済処理セキュリティ情報を決済端末のメーカに渡すことなく、決済端末を運用可能な状態にできるようにする。
【解決手段】電子マネー事業者のセンタ装置２と端末メーカのサーバ１との間で、予めネットワーク７を介して前準備処理を行うことで、センタ装置２側は“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５、サーバ１側は“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を取得して保持しておく。サーバ１側では決済端末１０にこの暗号化された端末情報２５等を格納して出荷する。この決済端末１０は、出荷されて任意の店舗等に設置後、ネットワーク７を介してセンタ装置２と暗号化通信を行って、決済処理セキュリティ情報である中間コード３１、セキュリティデータ３２を取得して格納する。その際、決済端末１０、センタ装置２は、それぞれ、上記情報３５、２５を用いて、通信相手が正当な相手であることを確認する。
【解決手段】電子マネー事業者のセンタ装置２と端末メーカのサーバ１との間で、予めネットワーク７を介して前準備処理を行うことで、センタ装置２側は“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５、サーバ１側は“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を取得して保持しておく。サーバ１側では決済端末１０にこの暗号化された端末情報２５等を格納して出荷する。この決済端末１０は、出荷されて任意の店舗等に設置後、ネットワーク７を介してセンタ装置２と暗号化通信を行って、決済処理セキュリティ情報である中間コード３１、セキュリティデータ３２を取得して格納する。その際、決済端末１０、センタ装置２は、それぞれ、上記情報３５、２５を用いて、通信相手が正当な相手であることを確認する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＣカード等を用いる電子マネーシステムに係わり、特にその決済端末に対するセキュリティ情報設定方式に関する。
【背景技術】
【０００２】
ＩＣカードを使った電子マネーシステムが広く利用されている。電子マネーを運営する各電子マネー事業者は、電子マネーシステムを安全に運用するために、独自にセキュリティ機能を決済端末、データセンターに組み込むことで、セキュリティを確保している。セキュアなシステムを構築するためには、システム全体を電子マネー事業者が単独で構築することが望ましい。そこで、セキュリティ処理に関する機能を電子マネー事業者が開発して、決済端末に組み込むことでメーカとのセキュリティ境界を保っている。
【０００３】
これを実現するため、例えばインタプリタ機能をＩＣカード端末内のセキュアなＬＳＩに実装し、電子マネー事業者が例えばインタプリタ言語で開発したアプリケーション（ＩＣカードと通信して電子マネー決済処理を行うアプリケーション等（ここではインタプリタが解釈可能な中間コードを例にする））をロードし、ＬＳＩ内でこのアプリケーションを実行させる方法が考えられる。尚、上記セキュアなＬＳＩとは、例えば耐タンパ技術（例えば筐体の開封検知によりＬＳＩ内の上記アプリケーションを消去するもの等）により保護されているものである。
【０００４】
ここで、例えば、特許文献１には、インタプリタが解釈可能な中間コードを格納するＲＡＭと、中間コードを解釈実行可能なインタプリタ実行プログラムを格納するＲＯＭと、インタプリタ実行プログラムの実行を制御するＣＰＵとを備えたＬＳＩを用いることが開示されている。上記中間コードは、暗号化されている場合と暗号化されている場合がある。あるいは、上記ＲＡＭには暗号化された中間コードと暗号化されていない中間コードとが格納されており、この両方の中間コードをインタプリタ実行プログラムで解釈可能とすることも開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−３３３９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１などの従来技術において、特に暗号化された中間コードを用いる手法においては、中間コードの暗号化は決済端末を製造する製造メーカ（または、この決済端末内の上記ＬＳＩを別のメーカが製造する場合には、当該ＬＳＩの製造／販売業者等）が割り当てた固定の暗号化鍵を利用しなければならず、中間コードの暗号化を製造メーカ等に委ねなければならず、電子マネー事業者と製造メーカ等との間の明確なセキュリティ境界を保つことが困難である。
【０００７】
ここで、従来では、決済端末内のＬＳＩに格納させる中間コードが暗号化されているか否かに関係なく、電子マネー事業者は、自己が開発した上記アプリケーション（ここでは中間コード）を決済端末の例えば製造メーカに渡して、製造メーカにおいてこのアプリケーションをそのまま（または暗号化して）決済端末内のＬＳＩ内のメモリに格納する作業を行うことで、決済端末が完成して出荷されることになる。この為、製造メーカ側で上記アプリケーション（中間コード）の内容を知り得ることになる。また、アプリケーション（中間コード）に限らず、そのセキュリティデータ（ＩＣカードとの通信の際に必要となる秘匿鍵等；中間コードが暗号化されている場合には、更に、復号化の為の鍵情報等）も、製造メーカに渡して、決済端末内のＬＳＩ内のメモリに格納させる作業を行わせる必要があり、セキュリティデータに関しても、その内容を製造メーカ側が知り得る状態にある。
【０００８】
電子マネー事業者側としては、電子マネー事業者と製造メーカ等と間の明確なセキュリティ境界を保つ為に、中間コードやセキュリティデータを製造メーカ等に渡したく無いという要望がある。しかしながら、上記の通り、中間コードやセキュリティデータを製造メーカ等に渡さなければ、実質的に決済端末は完成しないことになり（ハードウェアは製造できても、決済端末として機能する状態にはならない）、従来ではこの要望は適わなかった。
【０００９】
本発明の課題は、電子マネー事業者が、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等を、第３者（端末メーカ等）に公開することなく決済端末に設定でき、更に、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム等を提供することである。
【課題を解決するための手段】
【００１０】
本発明の決済処理セキュリティ情報配信方法は、電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける決済処理セキュリティ情報配信方法であって、予め、前記センタ装置と前記サーバ装置とが前記ネットワークを介して相互に通信処理を行うことで、前記センタ装置は、自己に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持する前準備処理ステップと、前記サーバ装置が、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記前準備処理ステップの際に取得した前記特定情報とを設定・格納する設定処理ステップと、前記各決済端末が出荷されて任意の設置場所に設置された後、前記センタ装置と前記決済端末とが前記ネットワークを介して暗号化通信により相互認証処理を行う処理であって、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と前記前準備処理ステップの際に取得した前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理ステップと、前記相互認証が成功した場合、前記センタ装置が前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、前記相互認証処理ステップで得られる暗号鍵によって暗号化して配信する配信ステップと、前記決済端末が、該暗号化された配信情報を前記相互認証処理ステップで得られる前記暗号鍵によって復号することで前記決済処理セキュリティ情報を取得する決済処理セキュリティ情報取得ステップとを有する。
【００１１】
本手法では、電子マネー事業者は、電子マネー決済処理に係わる決済処理セキュリティ情報（例えば上述した中間コード等）を、第３者（決済端末メーカ等）に渡さない。よって、各決済端末は、決済端末メーカ側によって製造・設定・出荷された時点では、決済処理セキュリティ情報を保持していないので、電子マネー決済処理の行えない（機能しない）。決済処理セキュリティ情報は、後から（決済端末設置後に）電子マネー事業者のセンタ装置から決済端末に配信される。
【００１２】
但し、決済処理セキュリティ情報は重要な情報であり、漏洩や誤配信は許されないので、センタ装置−決済端末間の通信を暗号化通信で行うだけでなく、予め前準備処理によって電子マネー事業者−決済端末メーカ間で交換した暗号化情報である上記暗号化特定情報、暗号化端末情報等を用いて認証処理を行うことで、相互に通信相手が正当なものであることを確認し、安全に決済処理セキュリティ情報を配信できるようにしている。
【発明の効果】
【００１３】
本発明の決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム等によれば、電子マネー事業者は、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等を、第３者（端末メーカ等）に公開することなく、決済端末に設定できる。この設定処理はネットワークを介して行うが、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる。
【図面の簡単な説明】
【００１４】
【図１】実施例１のプログラム配信システムの構成例を示す図である。
【図２】実施例１のプログラム配信システムの処理シーケンス例を示す図である。
【図３】図２のStep12の処理を詳細に説明する為のフロー図である。
【図４】実施例２のプログラム配信システムの構成例を示す図である。
【図５】実施例２のプログラム配信システムの処理シーケンス例を示す図である。
【図６】実施例３におけるプログラム配信システムの構成例を示す図である。
【図７】実施例３のプログラム配信システムの処理シーケンス例を示す図である。
【図８】実施例４におけるプログラム配信システムの構成例を示す図である。
【図９】実施例４におけるStep12の処理を詳細に説明する為のフロー図である。
【図１０】実施例５におけるプログラム配信システムの構成例を示す図である。
【図１１】実施例６のプログラム配信システムの処理シーケンス例を示す図である。
【図１２】メモリ管理テーブルのデータ構成例である。
【図１３】コンピュータハードウェア構成図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態について説明する。
（実施例1）（単一アプリケーションの場合）
図１は、実施例１として、単一アプリケーションの場合のプログラム配信システムの構成例を示す図である。
【００１６】
ところで、ここで、現在では複数種類のＩＣカードが存在する。つまり、電子マネーは、各電子マネー事業者（ＩＣカード発行・決済会社）から異なる仕様の電子マネーブランドが規定され、それぞれ電子マネー用のＩＣカードが発行され、また携帯端末用ソフトウェアがリリースされている。また、決済端末における電子マネー決済処理に係わるソフトウェアも各電子マネー事業者がそれぞれ規定し作成している。このように、複数の電子マネー事業者が、それぞれ自社ブランドのＩＣカード等を発行し、また決済端末を製造させ、電子マネー決済処理を管理している。そして、昨今、１台の決済端末で複数のブランドの（複数種類の）電子マネーを利用できるマルチブランド対応の電子マネー決済端末が出現してきている。
【００１７】
この様な複数種類のＩＣカードに対応可能な決済端末では、自端末で扱う各ブランド毎の処理機能が必要である。これは、例えば、ＩＣカードとの通信は秘匿通信（暗号化通信）であるので、その為の鍵情報等が必要であるが、複数ブランドに対応する場合、各ブランド毎の鍵情報等を保持する必要がある。また、鍵情報に限らず、電子マネー決済処理に係わるアルゴリズムやＩＣカードとの通信方式も、各ブランド毎に異なるものであり、それぞれが上記アルゴリズムを実現するアプリケーションプログラム（上記中間コード等）を作成している。
【００１８】
実施例１に関する上記「単一アプリケーションの場合」とは、決済端末が、複数ブランド対応ではなく、任意の単一ブランドのみ対応可能なものである場合を意味している。尚、決済端末が複数ブランド対応の場合の実施例として、後に説明する実施例５、６がある。また、後に説明する実施例２〜４も、単一アプリケーションの場合の実施例である。
【００１９】
尚、決済端末の通信相手（電子マネー決済の処理対象）は、非接触ＩＣカードのようなカード型の形態に限らず、例えばＩＣカード機能内蔵の携帯電話やタグ型（ＩＣタグ）あるいは腕時計型の形態等であってもよく、これらを総称して非接触型情報媒体と呼ぶものとする。但し、本説明では非接触ＩＣカードを例にして説明する。尚、非接触ＩＣカードを省略してＩＣカードという場合もある。
【００２０】
また、以下の各実施例の説明では、上記電子マネー決済処理に係わるアプリケーションプログラムの一例として、上記従来技術、課題で示した「インタプリタが解釈可能な中間コード」を例にして説明するが、この例に限るものではない。すなわち、本例で決済端末に配信・設定する電子マネー決済処理プログラムは、上記中間コードに限るものではなく、またインタプリタ処理するプログラムに限るものでもない。
【００２１】
また、決済端末が決済処理を実行できるようにする為に（つまり、決済端末が機能する為に）必要な情報は、中間コード３１等の電子マネー決済処理プログラムだけでなく、セキュリティデータ３２（上記ＩＣカードとの暗号通信に必要な秘匿鍵）も含まれるものであり、またこれらのプログラム／データ（鍵等）は、漏洩してはならない重要な情報であり後述するセキュアなＬＳＩ２０内で記憶・実行させるべきものであるので、これらのプログラム／データ（鍵等）（本例では中間コード３１及びセキュリティデータ３２）をまとめて「（電子マネー決済処理に係わる）決済処理セキュリティ情報」と呼ぶものとする。
【００２２】
以下の各実施例の説明では、この「決済処理セキュリティ情報」の一例として、中間コード３１とセキュリティデータ３２（上記ＩＣカードとの暗号通信に必要な秘匿鍵等の、中間コードによる電子マネー決済処理の際に必要となる各種データ）を例にして説明するが、上記の通りこの例に限るものではない。
【００２３】
以下、図１に示す実施例１の決済処理セキュリティ情報配信システムの構成について説明する。
尚、図１、図４等に示すシステムは、電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムであるが、このシステムの主な特徴は上記「決済処理セキュリティ情報」を安全に各決済端末に配信して設定させるものであることから「決済処理セキュリティ情報配信システム」と呼ぶ場合もある。
【００２４】
図示の決済処理セキュリティ情報配信システムは、概略的には、電子マネー事業者が有する中間コードダウンロードセンタに設置されるセンタ装置（電子マネー事業者センタ装置２）と、決済端末１０を製造する任意の決済端末メーカ側に備えられるサーバ装置（端末メーカサーバ１）と、様々な各種店舗等に設置される多数の決済端末１０とが、ネットワーク７（インターネットやＶＰＮ（Virtual Private Network；仮想プライベートネットワーク）等）に接続された構成となっており、相互にデータ送受信可能となっている。尚、図上、決済端末メーカ内に決済端末１０を示してあるが、これは出荷時の決済端末１０の状態（初期設定）を説明する為に示しているものである。尚、この設定時に（図では省略してあるが）後述する各種プログラム３０も設定される。
【００２５】
尚、センタ装置２−サーバ１間に関しては、何らかの専用線で接続されていてもよい。
決済端末１０はセキュアなＬＳＩ２０を備えるものである。これは、上記従来で説明したように、例えば耐タンパ技術が適用されたものであり、その内部に格納されるアプリケーションやデータ等が安全に保護され漏洩しないようになっている。上記の通り、「決済処理セキュリティ情報」の一例である中間コード３１やセキュリティデータ３２は、このＬＳＩ２０内に保持させてＬＳＩ２０内で処理実行させるべきものである。
【００２６】
ここで、図示の通り、出荷時の状態では決済端末１０のＬＳＩ２０内には、中間コード３１やそのセキュリティデータ３２は格納されていない。つまり、本手法では、電子マネー事業者は、中間コード３１やそのセキュリティデータ３２を決済端末メーカ側に渡さないので、決済端末メーカはこれら中間コード３１等の内容を知り得ない一方で、当然、これら中間コード３１等を決済端末１０にインストールすることは出来ない。よって、出荷時の状態のままでは決済端末１０はＩＣカードによる電子マネー決済処理を実行できないが、本手法では後に（出荷先の任意の店舗に設置後に）センタ装置２から決済端末１０へネットワーク７を介して中間コード３１等をダウンロードするようにしている。
【００２７】
但し、この方法では、ネットワーク７を介して中間コード３１等の極めて重要なアプリケーション／データを配信することになるので、安全に配信できるようにすることが求められる。これに対して、本手法では例えば図１に示す各種鍵や事前に特定の鍵によって暗号化済みの情報等を用いて、図２、図３で説明する処理を行うことで、中間コード３１等を安全・確実に配信できるようにすることを特徴としている。
【００２８】
尚、図上下側に示す決済端末１０の構成では、中間コード３１等がセンタ装置２からダウンロードされて格納された後の状態を示している。
ここで、図示の決済処理セキュリティ情報配信システムにおいて用いる各種鍵は、図上ではＡ〜Ｇとして示す７種類の鍵である。すなわち、まず、全ての決済端末で共有する“端末の共有鍵（Kct）”（図上ではＡを併記する；これより、“端末の共有鍵Ａ（Kct）”と記す場合もある；他の鍵も同様である）がある。“端末の共有鍵Ａ（Kct）”は、例えば共通鍵暗号方式による鍵である（よって、暗号化と復号化の両方で同じ鍵を用いる）。“端末の共有鍵Ａ（Kct）”は例えばサーバ１内で任意に生成する。
【００２９】
また、各決済端末１０それぞれが自らの内部で生成する公開鍵暗号方式の鍵ペアである“端末の公開鍵Ｂ（Kpt）”と“端末の秘密鍵Ｃ（Kst）”がある。また、上記電子マネー事業者センタ装置２において内部で生成する公開鍵暗号方式の鍵ペアである“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”がある。また、上記電子マネー事業者センタ装置２において内部で生成する、共通鍵暗号方式による鍵である“センタ秘匿鍵Ｄ（Kcc）”がある。“センタ秘匿鍵Ｄ（Kcc）”によって暗号化と復号化の両方が行える。
更に、電子マネー事業者センタ装置２−任意の決済端末１０間での後述する相互認証処理によって得られる所定情報（本例では乱数）に基づいて生成される“セッション鍵Ｇ（Ks）”がある。“セッション鍵Ｇ（Ks）”は一時的に生成・使用される鍵である。
【００３０】
以下、図１に示す端末メーカサーバ１（以下、省略してサーバ１と記す場合もある）、電子マネー事業者センタ装置２（以下、省略してセンタ装置２と記す場合もある）、決済端末１０の構成について、より詳しく説明する。
【００３１】
まず、端末メーカサーバ１と電子マネー事業者センタ装置２は、ハードウェア的には一般的な汎用コンピュータの構成であってよく、ここでは特に図示しないが、よく知られているように、ＣＰＵ、記憶装置（ハードディスク等）、メモリ、通信機能部等を有し、記憶装置に予め記憶されている所定のアプリケーションプログラムを、ＣＰＵが読み出し実行することにより、所定の処理を実現する。本実施例１では、例えば後述する図２や図３に示す処理を実行する。
【００３２】
例えば、端末メーカサーバ１は上記“端末の共有鍵Ａ（Kct）”を生成・保持しており、電子マネー事業者センタ装置２は上記“センタ秘匿鍵Ｄ（Kcc）”を生成・保持しており、サーバ１とセンタ装置２はこれらの鍵を用いて後に図２で説明する前準備処理を実行する（サーバ１−センタ装置２間で暗号化情報の交換処理を実行する）。また、前準備処理後、サーバ１は、図２で説明する出荷前の各決済端末１０に対する出荷設定処理を実行する。また、センタ装置２は、上記前準備処理後、各決済端末１０との間で図２、図３で説明する相互認証処理、セキュリティ情報配信処理を実行する。
【００３３】
ここで、電子マネー事業者センタ装置２は、図１に示すように、上記メモリとして不揮発メモリ３と揮発性メモリ４を有している。不揮発メモリ３は例えばハードディスク等の補助記憶装置であり、揮発性メモリ４は例えば主記憶装置である。
【００３４】
不揮発メモリ３には、予め、中間コード３１及びそのセキュリティデータ３２が格納されており、更に、当該センタ装置２内で任意に生成する暗号鍵（“センタ秘匿鍵Ｄ（Kcc）”、及び公開鍵暗号方式の鍵ペアである“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”）が格納される。不揮発メモリ３には、更に、予め、センタ装置２に係わる特定情報（後に説明するセンタ情報等）が設定・格納されている。また、後に図２で説明する端末メーカサーバ１とのデータ交換処理（前準備処理）によって得られた“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５が格納される。
【００３５】
ここで、既に説明してある通りであり、中間コード３１及びそのセキュリティデータ３２は「（電子マネー決済処理に係わる）決済処理セキュリティ情報」であり、当然、決済端末１０はこの決済処理セキュリティ情報が無いと電子マネー決済処理を実行することはできない。また、この決済処理セキュリティ情報は、当然、重要な情報であり漏洩することは許されず、耐タンパのＬＳＩ２０内に保持されてＬＳＩ２０内で処理実行すべきものである。
【００３６】
しかしながら、本手法では、電子マネー事業者が上記決済処理セキュリティ情報を決済端末メーカ側に渡したくないという要望を実現する為、ＬＳＩ２０内に決済処理セキュリティ情報が保持されていない状態で決済端末１０が出荷されることになる。この為、そのままでは決済端末１０は電子マネー決済端末として機能しないことになる。この為、本手法では、後から、電子マネー事業者のセンタ装置２から各決済端末１０へ決済処理セキュリティ情報を配信するが、上記の通り決済処理セキュリティ情報の漏洩は許されないので、センタ装置２−決済端末１０間の通信を暗号化によって行うだけでなく、センタ装置２、決済端末１０それぞれが通信相手が正当な相手か否かを確認して、誤って第３者の装置に決済処理セキュリティ情報を配信することが無いようにする。
【００３７】
このような相互に通信相手が正当な相手か否かを確認の為に、後述するように予め前準備処理や設定処理により生成・格納した“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５等を用いる手法を提案するものである。
【００３８】
また、上記揮発性メモリ４には、任意の決済端末１０との所定の通信処理（後述する相互認証処理、中間コード３１等の配信処理等）を行う毎にその際に一時的に取得／生成される各種情報が格納される。すなわち、通信相手の任意の決済端末１０から取得した当該決済端末１０の上記“端末の公開鍵Ｂ（Kpt）”と、当該決済端末１０との後述する相互認証処理によって得られる所定情報（本例では乱数）に基づいてセンタ装置２が生成する“セッション鍵Ｇ（Ks）”が、一時的に格納される。また、この“セッション鍵Ｇ（Ks）”を用いて上記不揮発メモリ３内の中間コード３１及びそのセキュリティデータ３２を暗号化した“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４が、一時的に格納される。これら各種情報は、任意の決済端末１０との上記所定の通信処理を行う毎に取得／生成されて一時的に格納されるものであり、この通信処理が完了したら消去される。
【００３９】
また、端末メーカサーバ１は、特に図示しないが、その不揮発性メモリまたはハードディスク等に、予め登録された上記端末共有鍵Ａ（Kct）を格納しており、また各決済端末１０を製造する毎に、その決済端末１０に係わる各種情報である後述する「端末情報」（詳しくは後述する）が登録されて格納される。更に、上記製造した各決済端末１０に対する出荷前の設定作業を行う前に、上記前準備処理によって電子マネー事業者センタ装置２から各決済端末１０毎に対応する“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を取得して格納している。
【００４０】
尚、上記登録は、例えば端末メーカ１の作業員等が行うものである。
そして、端末メーカ側では、例えば作業員等が行う各決済端末１０の出荷前設定作業において、例えばサーバ１と設定対象の決済端末１０とを接続して、サーバ１から決済端末１０に上記端末共有鍵Ａ（Kct）とその端末１０に対応する上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを転送して、これらを決済端末１０の不揮発性メモリ２４に格納させる。更に、各決済端末１０に、その内部で任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて、これも不揮発性メモリ２４に格納させる。
【００４１】
また、サーバ１から後述する各種プログラム（インタプリタ処理やアプリケーション格納処理等のプログラム３０等）を決済端末１０に転送させて、これらも不揮発性メモリ２４に格納させる。
【００４２】
各決済端末１０は、上記出荷前設定作業完了後、出荷されて任意の各店舗に設置される。そして、後に図２、図３で説明する上記センタ装置２との所定の通信処理を行うことで、上記「決済処理セキュリティ情報」（中間コード３１とセキュリティデータ３２）を安全・確実に取得することができ、これによって電子マネー決済処理が可能な状態となる（ＩＣカードによる電子マネー決済端末として機能する状態となる）。
【００４３】
決済端末１０の詳細構成例、及び上記センタ装置２との所定の通信処理実行後の状態を、図１の図上下側に示し、以下、これを参照して説明する。
図示の例では、決済端末１０は、端末管理ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、ＵＩ１４、第１通信部１５、第２通信部１６、第３通信部１７、及びＬＳＩ２０等を有する。
【００４４】
決済端末１０を任意の店舗に設置する際に、第１通信部１５を店舗内の上位装置（ＰＯＳレジ５等）に接続し、第２通信部１６をネットワーク７に接続しておく。これより、決済端末１０は、上位装置（ＰＯＳレジ５等）と通信可能となり、またネットワーク７を介して外部の他の情報処理装置（ここでは特に電子マネー事業者センタ装置２）と通信可能となる。また、第３通信部１７は製造時に既にＬＳＩ２０内の第４通信部２２と接続しており、端末管理ＣＰＵ１１とＬＳＩ２０とは、これら通信部１７，２２を介して、相互にデータ送受信するものである。
【００４５】
端末管理ＣＰＵ１１は、当該決済端末１０全体を制御する中央処理装置である。端末管理ＣＰＵ１１は、ＲＯＭ１３に格納されている所定の各種アプリケーションプログラムを読出し・実行することにより、各種処理を実行する。例えば、第１通信部１５を介して上位装置（ＰＯＳレジ５等）との通信処理を行ったり、第２通信部１６を介してネットワーク７（ＬＡＮやインターネット等）を介した電子マネー事業者センタ装置２との通信処理を行ったり、第３通信部１７を介してＬＳＩ２０とのデータ送受信処理を行う。特に、後述する図２の処理において、ＬＳＩ２０と外部の装置（上記ＰＯＳレジ５やセンタ装置２等）との通信を中継する処理を行う。また、ＩＣカード６による電子マネー決済処理に関して、ＬＳＩ２０内で中間コード３１等により実行されるセキュアな処理以外の処理（例えば利用履歴の生成・格納等）も行う。これらの処理を実行するプログラムも、上記出荷前設定作業の際に登録されて、ＲＯＭ１３に格納される。
【００４６】
尚、上記ＲＯＭに格納される各種アプリケーションは、後の説明における“非セキュリティ部分のプログラム”や“非決済プログラム６３”に相当するものである。
上記のように、端末管理ＣＰＵ１１は、主に、決済端末１０内で実行される各種処理のうち、上記ＬＳＩ２０内で実行されるセキュアな処理（電子マネー決済処理）以外の処理を実行するものである。
【００４７】
ＲＯＭ１３には端末管理ＣＰＵ１１に実行させる上記所定の各種アプリケーションプログラム等が格納されている。
尚、ＲＯＭ１３は、純粋なＲＯＭ（書き換え不可）ではなく、例えばフラッシュメモリやＥＥＰＲＯＭなどの書換え可能な不揮発性メモリである。これより、例えばＩＣカード６との電子マネー決済処理毎にその利用履歴等が格納される。ＲＡＭ１２は例えばワークメモリである。
【００４８】
ＵＩ１４は、ユーザインタフェースに係わる機能部であり、例えばタッチパネル等の入力装置と、ディスプレイ等の表示装置等である。
ＬＳＩ２０は、ＣＰＵ２１、第４通信部２２、第５通信部２６、揮発性メモリ２３（ＳＲＡＭ等）、及び上述してある不揮発性メモリ２４（ＥＥＰＲＯＭ等）を有する。
【００４９】
ＬＳＩ２０は、例えば、プログラム３０によるインタプリタ処理により中間コード３１を解釈・実行して（その際、セキュリティデータ３２の暗号鍵情報等を用いる）、ＩＣカード６との電子マネー決算処理等を行い、またその利用履歴を暗号化して端末管理ＣＰＵ１１に渡し、ＲＯＭ１３等に格納させる。尚、プログラム３０は、図示の上記インタプリタ処理やアプリ等格納処理等をＣＰＵ２１により実行させる為の各種アプリケーションプログラムである。アプリ等格納処理は、後述する図２、図３に示すセンタ装置２との相互認証処理や中間コード３１等の配信処理におけるＬＳＩ２０の処理を行うものである。詳しくは後述する。
【００５０】
尚、ＬＳＩ２０には所謂“耐タンパ”適用されており、例えば不正を検知した場合には（筐体の破壊等の検知）、例えば揮発性メモリ２３、不揮発性メモリ２４に格納されている全データを消去することで、上記中間データ３１等の重要データの漏洩を阻止する。
【００５１】
上述してあるように、不揮発性メモリ２４（ＥＥＰＲＯＭ等）には、出荷時に既に、上記プログラム３０や、各種暗号鍵（上記端末共有鍵Ａ（Kct）、“端末の公開鍵Ｂ（Kpt）”、“端末の秘密鍵Ｃ（Kst）”）や、所定の暗号化情報（センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報２５）が格納されている。
【００５２】
ＣＰＵ２１は、上記の通り、各種プログラム３０を適宜読出し・実行することにより、例えば、後に図２、図３で説明する各種処理等を実行する。特に、上記アプリ等格納処理のプログラムを実行することにより、電子マネー事業者センタ装置２から中間コード３１、そのセキュリティデータ３２を取得できる（上記の通り、図には既に取得済みの状態を示してある）。また、このアプリ等格納処理中、揮発性メモリ２３には、センタ装置２から取得する“センタ公開鍵Ｅ（Kpc）”と、後に図２で説明する相互認証処理に基づいて内部で生成する“セッション鍵Ｇ（Ks）”が一時的に格納される。これら揮発性メモリ２３内の鍵情報は、中間コード３１、そのセキュリティデータ３２を取得したら（センタ装置２との通信が完了したら）消去する。
【００５３】
また、第５通信部２６は、ＩＣカード６と通信を行う機能部であり、例えばアンテナと送受信回路等から構成される。
上記図１に示す構成の決済処理セキュリティ情報配信システムでは、端末メーカ側には中間コード３１、そのセキュリティデータ３２は渡されない。よって、端末メーカ側では、中間コード３１、そのセキュリティデータ３２の内容を知ることができないが、その一方で当然、出荷時には決済端末１０内に中間コード３１、そのセキュリティデータ３２は格納されていない状態であるので、このままではＬＳＩ２０は機能せず、ＩＣカード６との通信・決済処理を行うことはできない（運用可能な状態ではない）。中間コード３１、そのセキュリティデータ３２は、各決済端末１０を任意の店舗内に設置後に、電子マネー事業者センタ装置２から配信する。
【００５４】
但し、中間コード３１、そのセキュリティデータ３２は、非常に重要な情報であり、漏洩してはならない。これに対して、本例の決済処理セキュリティ情報配信システムでは、上述した各種鍵や暗号化情報を用いて、安全に中間コード３１、そのセキュリティデータ３２を配信することができる。これについて、以下、図２、図３を参照して、主に安全に中間コード３１、そのセキュリティデータ３２を配信する為の処理について、詳細に説明する。
【００５５】
図２は、実施例１のプログラム配信システムの処理シーケンス例を示す図である。以下、この例を用いて説明する。
まず、上記前準備処理として、端末メーカサーバ１と電子マネー事業者センタ装置２との間で、ネットワーク７を介して所定のデータを交換する処理を行う。すなわち、まず、当該サーバ１−センタ装置２間でのデータ交換処理を暗号化通信で行うようにする為に、所定の暗号鍵の交換を行う（Ｓ１）。ここでは一例として、図３に示すセンタ装置２−決済端末１０間の暗号化通信例と同様に、公開鍵暗号方式を用いるものとする。よって、サーバ１とセンタ装置２とで、それぞれ公開鍵暗号方式による鍵ペア（公開鍵と秘密鍵のペア）を生成し、互いに自己の鍵ペアにおける公開鍵を相手側に送信する（ここでは、一方の公開鍵を公開鍵（Kp_tm）とし、他方は公開鍵（Kp_bc）とし、これらを交換する）。
【００５６】
そして、上記自己が生成した鍵ペア及び相手の公開鍵とを用いて、図３の場合と同様に、それぞれが任意の乱数を生成しつつ相互認証処理を行い、この相互認証処理の際に生成・交換される乱数情報等を用いて、通信セッション鍵（Ks_tmbc）を生成する。
【００５７】
以降の処理（Ｓ２以降の処理）においてはこの通信セッション鍵（Ks_tmbc）を用いて暗号化通信によるデータ送受信を行う。尚、当然、暗号化通信は、上記公開鍵暗号方式に限らず、共通鍵暗号方式によって行ってもよい。この場合には、サーバ１とセンタ装置２は予め同じ暗号鍵を共有している。
【００５８】
Ｓ２以降の処理について説明する。
まず、サーバ１は、出荷する決済端末１０に関する所定の各種情報である端末情報（例えば、端末ID，事業者ID，店舗ID，店舗端末IDなど）を、センタ装置２へ送信する（Ｓ２）。この端末情報は上記通信セッション鍵により暗号化されている（以下のＳ３，Ｓ４，Ｓ５で送受信する情報も同じであり、上記通信セッション鍵（Ks_tmbc）により暗号化されている）。また、以下の説明では逐一述べないが、暗号化された端末情報等は、通信セッション鍵（Ks_tmbc）による復号される。
【００５９】
尚、上記通信セッション鍵（Ks_tmbc）は、サーバ１−センタ装置２間のデータ送受信に用いる暗号鍵であり、後述する決済端末１０−センタ装置２間のデータ送受信に用いるセッション鍵Ｇ(ks)とは別のものである。同様に、上述した公開鍵（Kp_tm，Kp_bc）も、サーバ１−センタ装置２間の通信に用いるものであり、上述した７種類の鍵における公開鍵Ｂ，Ｅとは別のものである。
【００６０】
センタ装置２は、受信した端末情報を、電子マネー事業者側のみが知り得る（保持する）秘匿鍵である上記“センタ秘匿鍵Ｄ（Kcc）”によって暗号化することで上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を生成し、この“暗号化された端末情報”２５をサーバ１へ返信する（Ｓ３）。また、センタ装置２は、受信した端末情報を不揮発メモリ３に記憶しておく。サーバ１は上記返信された“暗号化された端末情報”２５を、自己の不図示の不揮発性メモリ等に記憶する（送信した端末情報に対応付けて記憶する）。
【００６１】
また、センタ装置２は、自装置に係わる所定の情報であるセンタ情報（事業者コード，ネットワークアドレスなど）を、サーバ１へ送信する（Ｓ４）。サーバ１は、受信したセンタ情報を、決済端末メーカ側のみが知り得る（保持する）秘匿鍵である上記“端末共有鍵Ａ（Kct）”で暗号化することで上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を生成し、この“暗号化されたセンタ情報”３５をセンタ装置２へ返信する（Ｓ５）。また、サーバ１は受信したセンタ情報を記憶しておく。センタ装置２は、上記返信された“暗号化されたセンタ情報”３５を、不揮発メモリ３に記憶する。
【００６２】
上述した前準備処理におけるＳ２とＳ３の処理は、出荷する各決済端末毎に対応して行うものである。よって、例えば出荷する決済端末１０が１００台あれば、Ｓ２とＳ３の処理を１００回行うことになる。一方、Ｓ４とＳ５の処理は、基本的に、１回だけ行えばよい。
【００６３】
以上説明した前準備処理を完了したら、その結果を用いて、端末メーカ側では、上記“出荷する決済端末１０”に対して上記出荷設定処理を行う。尚、この処理はサーバ１と“出荷する決済端末１０”とを接続して通信可能な状態として行う。
【００６４】
すなわち、例えば作業員等による指示操作により、“出荷する決済端末１０”において、その内部で上記任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる（Ｓ６）。
【００６５】
その後、サーバ１から“出荷する決済端末１０”に対して、上述した“端末共有鍵Ａ（Kct）”、当該“出荷する決済端末１０”の端末情報（端末ID，店舗ID，店舗端末IDなど）、当該“出荷する決済端末１０”に端末情報が暗号化されてなる上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、更に上記Ｓ４の処理で取得したセンタ情報を送信して、そのＬＳＩ２０の不揮発性メモリ２４に記憶させる（Ｓ７，Ｓ８，Ｓ９）。よって、図１には示していないが、端末情報（暗号化されていない）やセンタ情報も不揮発性メモリ２４に記憶される。また、既に述べた通り上記プログラム３０も設定されて不揮発性メモリ２４に記憶される。
【００６６】
また、ＵＩ（ユーザインタフェース）表示、つまりディスプレイ等への任意の情報表示や、利用履歴（明細）記録等の非セキュリティ部分の電子マネー事業者のアプリケーションを、決済端末１０のＲＯＭ１３（フラッシュメモリやＥＥＰＲＯＭ等）に格納する。
【００６７】
以上の出荷前の処理を経て、“出荷する決済端末１０”が出荷されて任意の店舗内に設置されたら、この決済端末１０はセンタ装置２０と通信を行って中間コード３１、そのセキュリティデータ３２を取得することで、運用可能状態となる。これについて、以下、図２だけでなく図３も参照して説明する。
【００６８】
上記設置後、電源ＯＮされて起動された決済端末１０において、端末管理ＣＰＵ１１は、まず、上記電子マネー事業者の“非セキュリティ部分のプログラム”を、ＲＡＭ１２にロードして実行する。このプログラム処理では、まず、図２に示すＳｔｅｐ１１、Ｓｔｅｐ１２、Ｓｔｅｐ１３の処理（その端末管理ＣＰＵ１１の処理）を実行する。尚、その際、ＬＳＩ２０のＣＰＵ２１は、上記プログラム３０により上記アプリ等格納処理を実行している。以下に、まず、これら各Stepの処理について説明する。
【００６９】
Step１1； 端末管理ＣＰＵ１１は、まず、ＬＳＩ２０と通信を行い、ＬＳＩ２０が中間コード３１とセキュリティデータ３２を保持しているか否かをチェックする（Ｓ１０）。そして、中間コード３１等を既に保持している場合には、図示のStep14以降の処理を実行可能な状態へ移行する。つまり、中間コード３１等の配信を受ける為の処理は行わない。
【００７０】
一方、中間コード３１等を保持していない（未配信）の場合には、中間コード３１等の配信を受ける為に、まず、ネットワーク７を介してセンタ装置２に接続し、公開鍵の交換を行う。これは、図３の最初の処理に示すように、決済端末１０の端末管理ＣＰＵ１１は、ＬＳＩ２０の不揮発性メモリ２４に保持されている上記“端末の公開鍵Ｂ（Kpt）”をＬＳＩ２０から取得して、これをセンタ装置２へ送信する。センタ装置２は、自己の不揮発メモリ３に保持されている上記“センタ公開鍵Ｅ（Kpc）”を決済端末１０へ送信する。端末管理ＣＰＵ１１は、受信した“センタ公開鍵Ｅ（Kpc）”をＬＳＩ２０に渡して揮発性メモリ２３に記憶させる。
【００７１】
Step12； 相互認証処理を実行し、認証成功したら“セッション鍵Ｇ（Ks）”を生成する。“セッション鍵Ｇ（Ks）”は、相互認証処理の際に得られる情報（例えば乱数）を用いて、決済端末１０、センタ装置２でそれぞれ生成するものであり、同じものが生成される。
【００７２】
上記相互認証処理では、予め上記前準備処理によって得られてセンタ装置２、決済端末１０にそれぞれ格納されている上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、端末情報、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５、センタ情報等を用いて、相互に、通信相手が正当なものであるか否かを確認する。これによって、センタ装置２にとっては誤って第３者の端末に中間コード３１等を配信してしまうことなく、また決済端末１０にとっては誤って第３者の装置から不正なプログラムをダウンロードすることで内部で（特にＬＳＩ２０内で）何らかの不正処理が実行されてしまうことなく、安全・確実に中間コード３１等が決済端末１０に配信されるようにできる。
【００７３】
尚、Step12の処理に関しては、詳しくは後に図３を参照して説明する。
Step13； 上記相互認証成功した場合、決済端末１０は、センタ装置２に対して中間コード３１とセキュリティデータ３２を要求する。この要求を受けたセンタ装置２は、上記不揮発メモリ３に格納されている中間コード３１及びそのセキュリティデータ３２を、上記生成した“セッション鍵Ｇ（Ks）”を用いてそれぞれ暗号化して、上記“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４を生成して決済端末１０へ送信する。これを受信した決済端末１０側では、ＬＳＩ２０内において、これら“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４を、上記生成した“セッション鍵Ｇ（Ks）”で復号して、中間コード３１及びそのセキュリティデータ３２を得て、これらのコード３１、データ３２を不揮発性メモリ２４に格納する。
【００７４】
尚、復号化した後、この中間コード３１及びそのセキュリティデータ３２の検証を行い、検証結果がＯＫである場合に、これらのコード／データを不揮発性メモリ２４に格納する。尚、この検証処理は、本発明には特に関係ないので特に詳細には説明しないが、例えばセンタ装置２は中間コード３１のハッシュ値を生成してこのハッシュ値も一緒に送信し、ＬＳＩ２０はこのハッシュ値を用いて検証を行うものである。
【００７５】
以上で中間コード３１等は安全・確実に決済端末１０に配信され、センタ装置２−決済端末１０間の通信処理は終了する。通信処理終了したら、センタ装置２、決済端末１０は、それぞれ“セッション鍵Ｇ（Ks）”、相手から渡された公開鍵を消去する。
【００７６】
以上により、決済端末１０のセキュリティ機能（セキュアな電子マネー決済処理機能）の活性化が完了し、電子マネー決済処理が可能となる。
ここで、図３には、上記Step12の処理を詳細に説明する為のフロー図を示す。
【００７７】
尚、以下の説明では逐一述べないが、図３における決済端末１０側の処理は、基本的にＬＳＩ２０内のＣＰＵ２１が実行するものであり、端末管理ＣＰＵ１１はセンタ装置２−ＬＳＩ２０間で送受信されるパケットの中継・転送を行うものである。
【００７８】
以下、図３を参照して上記Step12の処理（相互認証処理）について説明する。
図３においては最初にStep11の処理例（公開鍵Ｂ，Ｅの交換）が示してあり、これについては既に説明してある。
【００７９】
図３に示す相互認証処理では、まず、決済端末１０は、その内部で任意の乱数Rtを生成し、また上記出荷設定時に記憶されている自身の端末情報を用いて、この端末情報のハッシュ値を生成する。
【００８０】
そして、これら乱数Rt、端末情報ハッシュ値と、出荷設定時に記憶されている“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とから成るデータ（図示の送信データ４１）を、各種鍵により暗号化してセンタ装置２へ送信する。これは、まず、乱数Rtと端末情報ハッシュ値とを自身の秘密鍵（“端末の秘密鍵Ｃ（Kst）”）で暗号化し、更にこれら暗号化情報と上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを上記Step11の処理で取得している“センタ公開鍵Ｅ（Kpc）”で暗号化することで図示の暗号化データ４２を生成する。そして、この暗号化データ４２をセンタ装置２へ送信する。
【００８１】
上記暗号化データ４２を受信したセンタ装置２は、この暗号化データ４２を自身が保持する各種鍵を用いて復号する。すなわち、まず、上記“センタ公開鍵Ｅ（Kpc）”による暗号化に対して、“センタ秘密鍵Ｆ（Ksc）”を用いて復号することで、「“端末の秘密鍵Ｃ（Kst）”で暗号化された乱数Rt及び端末情報ハッシュ値」と“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを得る。
【００８２】
続いて、上記「“端末の秘密鍵Ｃ（Kst）”で暗号化された乱数Rt及び端末情報ハッシュ値」を“端末の公開鍵Ｂ（Kpt）”で復号して、乱数Rtと端末情報ハッシュ値を得る。更に、上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５をセンタ秘匿鍵Ｄ（Kcc）で復号して「端末情報」を得る。これらの処理により図示の復号データ４３を得ることができる。
【００８３】
上記復号処理が正常に行えなかった場合や後述するステップＳ２１，Ｓ２２の判定で一方でも判定ＮＯであった場合は、処理終了し、それ以降の処理は行われない。よって、当然、中間データ等の配信は行われない。但し、決済端末１０に認証失敗を通知してもよい。
【００８４】
一方、上記復号処理が正常完了して上記復号データ４３を得ることができた場合には、続いて、この復号データ４３における「端末情報」と、上記Ｓ２の処理の際に取得して登録してあった端末情報とが一致するか否かをチェックする（上記の通り、基本的には複数の端末情報（例えば１００台分の端末情報）が記憶されているので、その中で一致するものがあるか否かをチェックする）。つまり、通信相手の装置が、登録済みの決済端末１０であるか否かを確認する（ステップＳ２１）。
【００８５】
端末情報が一致する場合には（ステップＳ２１，ＹＥＳ）、続いてこの端末情報のハッシュ値を求め（尚、ハッシュ値の生成アルゴリズムは、上記決済端末１０と同じである）、このハッシュ値が上記復号データ４３における端末情報ハッシュ値と一致するか否かをチェックし（ステップＳ２２）、一致する場合には（ステップＳ２２，ＹＥＳ）、通信相手の決済端末１０が正当なものであるものとして端末認証成功と判定し、処理を続行する。
【００８６】
また、上記ステップＳ２１の処理によって、通信相手の決済端末１０を特定できる（登録されている決済端末のうちのどの決済端末であるのか分かる）。よって、例えば、登録されている（つまり、出荷されているはずの）各決済端末１０のうち、どの決済端末１０に中間コード３１等を配信済み（または未配信）であるか等を管理することも可能となる。
【００８７】
一方、上記ステップＳ２１，Ｓ２２の何れかで不一致の判定（ＮＯ）となった場合には、上記の通り、処理終了し、それ以降の処理は行われない。よって、当然、中間データ等の配信は行われない。
【００８８】
上記ステップＳ２１，Ｓ２２の判定がＹＥＳとなり認証成功した場合には、続いて、まず、上記取得した乱数Rtを揮発性メモリ４に記憶する。そして、任意の乱数Rcを生成し、更に自己のセンタ情報のハッシュ値を生成する。そして、これら乱数Rc、センタ情報ハッシュ値と、上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とから成るデータ（図示の応答データ４４）を、各種鍵により暗号化して図示の暗号化データ４５を生成して、これを接続先の決済端末１０へ送信する。
【００８９】
これは、まず、乱数Rcとセンタ情報ハッシュ値とを“センタ秘密鍵Ｆ（Ksc）”で暗号化し、更にこれら暗号化情報と上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とを上記Step11の処理で取得している“端末の公開鍵Ｂ（Kpt）”で暗号化することで図示の暗号化データ４５を生成する。そして、この暗号化データ４５を接続先の決済端末１０へ送信する。
【００９０】
この暗号化データ４５を受信した決済端末１０は、この暗号化データ４５を自身が保持する各種鍵を用いて復号する。すなわち、まず、上記“端末の公開鍵Ｂ（Kpt）”による暗号化に対しては、“端末の秘密鍵Ｃ（Kst）”で復号することで、「“センタ秘密鍵Ｆ（Ksc）”で暗号化された乱数Rc及びセンタ情報ハッシュ値」と“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を得る。続いて、上記「“センタ秘密鍵Ｆ（Ksc）”で暗号化された乱数Rc及びセンタ情報ハッシュ値」を“センタ公開鍵Ｅ（Kpc）”で復号して、乱数Rcとセンタ情報ハッシュ値を得る。また、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を、端末共有鍵Ａ（Kct）で復号して「センタ情報」を得る。これらの処理により図示の復号データ４６を得ることができる。
【００９１】
そして、この復号データ４６における「センタ情報」が、上記出荷設定時に記憶されているセンタ情報と一致するか否かをチェックする（ステップＳ２３）。一致する場合には（ステップＳ２３，ＹＥＳ）、続いてこのセンタ情報のハッシュ値を求め、このハッシュ値が上記復号データ４６におけるセンタ情報ハッシュ値と一致するか否かをチェックし（ステップＳ２４）、一致する場合には（ステップＳ２４，ＹＥＳ）、通信相手のセンタ装置２が正当なものであるとしてセンタ認証成功と判定し、処理を続行する。尚、上記取得した乱数Rcは揮発性メモリ２３等に記憶しておく。
【００９２】
一方、上記各種鍵による暗号化データ４５の復号化処理が成功しなかった場合、または上記ステップＳ２３，Ｓ２４の何れか一方でも不一致の判定（ＮＯ）となった場合には、処理終了し、それ以降の処理は行われない。よって、当然、中間データ３１等のダウンロードは行われない。但し、センタ装置２に対して認証失敗を通知してもよい。
【００９３】
尚、上記乱数の一致も認証成功の条件としてもよい。この場合、センタ装置２は上記復号データ４３における乱数Ｒｔも上記暗号化データ４５に含めて送信し、決済端末１０は受信した暗号化データ４５に含まれる乱数Ｒｔが自己が生成している乱数Ｒｔと一致するか否かをチェックする処理も上記ステップＳ２３、Ｓ２４の処理に加えて行うようにしてもよい。尚、乱数Ｒｃに関しても同様にしてセンタ装置２側で乱数Ｒｃ一致か否かをチェックするようにしてもよい。
【００９４】
尚、上記ステップＳ２２、ステップＳ２４の処理は、必ずしも必須の処理ではなく、ステップＳ２１、ステップＳ２３の処理のみを行っても良い。つまり、センタ装置２はステップＳ２１の判定がＹＥＳである場合には通信相手の決済端末１０を認証成功と判定してよく、決済端末１０はステップＳ２３の判定がＹＥＳである場合には通信相手のセンタ装置２を認証成功と判定してもよい。勿論、この場合には、上記端末情報ハッシュ値やセンタ情報ハッシュ値は、生成する必要はないしデータ４１、４４に含める必要もない。
【００９５】
上記センタ装置２、決済端末１０はどちらも、上記のように認証成功と判定した場合には、図示していないが、更に以下に説明する処理を実行する。
すなわち、センタ装置２、決済端末１０の両方とも、上記相互認証処理が成功したときには、自己が生成した乱数と相手から取得した乱数の２つの乱数、すなわち上記乱数Ｒｔと乱数Rcを記憶している。すなわち、相互認証処理によって得られる所定情報を記憶している。これより、センタ装置２、決済端末１０の両方とも、この２つの乱数Ｒｔと乱数Rcとに基づいて上記“セッション鍵Ｇ（Ks）”を生成する。これは、センタ装置２、決済端末１０の両方で同じ“セッション鍵Ｇ（Ks）”を生成するものである。つまり、“セッション鍵Ｇ（Ks）”の生成アルゴリズムは、何でもよいが（例えば単純な例では「Ｒｔ＋Ｒｃ」とする）、予め各決済端末１０とセンタ装置２に、同じ生成アルゴリズムのプログラムを格納しておく。よって、セッション鍵生成に用いるデータが同じであるので（ここでは乱数Ｒｔと乱数Ｒｃ）、決済端末１０とセンタ装置２は同じセッション鍵を生成することになる。
【００９６】
そして、上記Step13で説明してある通り、中間コード３１等の配信処理は、“セッション鍵Ｇ（Ks）”を用いた暗号化通信により行うことになる。つまり、センタ装置２は中間コード３１等を“セッション鍵Ｇ（Ks）”で暗号化して決済端末１０に送信し、これを受信した決済端末１０（そのＬＳＩ２０）はこの暗号化情報を自己の“セッション鍵Ｇ（Ks）”を用いて復号することで、安全に中間コード３１等を取得することができる。
【００９７】
上述した処理により、決済端末１０は安全・確実に中間コード３１及びそのセキュリティデータ３２を得ることができ、ＩＣカード等との電子マネー決済処理が可能となり、運用開始することができる。
【００９８】
運用開始後の処理である図２に示すStep14、Step15、Step16の処理は、Step16の撤去処理においてＬＳＩ２０内の中間コード３１，セキュリティデータ３２等を削除する点以外は、既存の処理と同じであってよい。よって、以下、簡単に説明するのみとする。
【００９９】
まず、Step14の決済処理について説明する。
決済端末１０がＰＯＳレジ５等の上位端末から決済指示を受けると、端末管理ＣＰＵ１１は、明細を作成してこれを仮明細としてフラッシュやＥＥＰＲＯＭなどの不揮発性メモリ（ＲＯＭ１３）に記憶する。また、ＵＩ１４による表示制御によって顧客にＩＣカードの提示を促す等した後、ＬＳＩ２０に決済指示を出す。
【０１００】
ＬＳＩ２０のＣＰＵ２１は、この決済指示に従って、プログラム３０のインタプリタ処理によって中間コード３１を解釈・実行することで（その際、セキュリティデータ３２を用いる）、ＩＣカード６との（秘匿通信による）電子マネー決済処理を行う。そして、決済処理の完了で明細を確定し、処理結果を端末管理ＣＰＵ１１に通知する。
【０１０１】
端末管理ＣＰＵ１１は、ＵＩ１４による表示制御（ディスプレイ表示等）で決済完了を顧客に通知するとともに、上位端末に決済結果を通知する。
次にStep15の締め処理について説明する。
【０１０２】
決済端末１０が上位端末から締め指示を受けると、端末管理ＣＰＵ１１は、締め対象の明細情報を作成し、フラッシュやＥＥＰＲＯＭなどの不揮発性メモリ（ＲＯＭ１３）に記憶する。また、端末管理ＣＰＵ１１は、ＬＳＩ２０に締め対象の明細情報を渡して暗号化処理を指示する。
【０１０３】
ＬＳＩ２０は、この指示に従って、プログラム３０のインタプリタ処理によって中間コード３１を解釈・実行することで（その際、セキュリティデータ３２を用いる）、上記の明細情報の暗号化を行って、この暗号化明細情報を端末管理ＣＰＵ１１に返信する。
【０１０４】
端末管理ＣＰＵ１１は、この暗号化明細情報をセンタ装置２に送信する。送信完了後、端末管理ＣＰＵ１１は、締め情報とセンタ装置２への通信結果を上位端末に通知する。
次に、Step16の店舗の改修や移転・サービス終了時等における決済端末１０の撤去に伴う撤去処理について説明する。
【０１０５】
決済端末１０が上位端末から撤去指示を受けると、端末管理ＣＰＵ１１は、ＬＳＩ２０に対して中間コード３１，セキュリティデータ３２の削除を指示する。ＬＳＩ２０は、この指示に従い、不揮発性メモリ２４に記憶されている中間コード３１，セキュリティデータ３２を削除して、削除完了を端末管理ＣＰＵ１１に通知する。
【０１０６】
削除処理の完了を確認した端末管理ＣＰＵ１１は、センタ装置２に対して撤去完了の通知を行う。
以上説明したように、実施例１のシステムによれば、電子マネー事業者は、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等（「決済処理セキュリティ情報」；本例では中間コード３１、セキュリティデータ３２）を、第３者（端末メーカ等）に公開することなく、決済端末を機能させるためのアプリケーション等（決済処理セキュリティ情報）を決済端末に設定できる。この設定処理はネットワークを介して行うが、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる。尚、以下に説明する実施例２〜６の各実施例についても、上記実施例１の効果と同様の効果が得られる（更に、その実施例に固有の効果が得られる場合もある）。
【０１０７】
次に、以下、実施例２について説明する。
図４は、実施例２におけるプログラム配信システムの構成例を示す図である。
尚、図４のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。図１と異なるのは、鍵の格納場所や一部の処理内容であり、以下、主に実施例１とは異なる点について説明する。
【０１０８】
図４に示す通り、実施例１との違いは、中間コード３１，セキュリティデータ３２を、不揮発性メモリ２４ではなく、揮発性メモリ２３に記憶することである。
図５は、実施例２の決済処理セキュリティ情報配信システムの処理シーケンス例を示す図である。
【０１０９】
図示の通り、図５は、図２に示す実施例１のシーケンスと殆ど同じであり、異なる点についてのみ説明する。すなわち、図２のStep11の代わりに、図示のStep11’の処理を実行する点のみが異なる。
【０１１０】
実施例２では、決済端末１０は、中間コード３１等の有無を確認する処理（Ｓ１０）は行わずに、常に、上記Ｓ１０の判定において中間コード３１等を保持していない（未配信）と判定された場合の処理を実行する。よって、図示のStep11’の処理では、決済端末１０は、電源ＯＮされたら、上記Step11で説明した「ネットワーク７を介してセンタ装置２に接続し、公開鍵の交換を行う」処理を実行する。そして、Step12,13の処理を実行することで、中間コード３１等を取得する。
【０１１１】
実施例２では、上記の通り、中間コード３１，セキュリティデータ３２を揮発性メモリ２３に記憶しているので、電源ＯＦＦにより消去される。よって、再起動の際には必ずＬＳＩ２０内には中間コード３１，セキュリティデータ３２は保持されていない状態であるので、上記ステップＳ１０の処理を行う必要がない。よって、上記Step11の代わりに上記Step11’の処理を実行している。
【０１１２】
実施例２では、電源ＯＦＦにより必ず中間コード３１，セキュリティデータ３２は消去されるので、運用中以外（夜間等）で電源ＯＦＦ状態にあるときに、中間コード３１，セキュリティデータ３２が漏洩する可能性は無いことになる。また、不揮発性メモリ２４のメモリ容量が少なくて済む（少なくとも実施例１の場合と比べて少なくて済む）。
【０１１３】
次に、以下、実施例３について説明する。
図６は、実施例３における決済処理セキュリティ情報配信システムの構成例を示す図である。
【０１１４】
また、図７は、実施例３の決済処理セキュリティ情報配信システムの処理シーケンス例を示す図である。
尚、図６のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。
【０１１５】
実施例３では、決済端末１０において、ダウンロードした中間コード３１，セキュリティデータ３２を、ＬＳＩ２０内の揮発性メモリ２３や不揮発性メモリ２４には格納せずに、暗号化された状態でＬＳＩ２０の外部のＲＯＭ１３に格納しておく。そして、任意のときに、ＬＳＩ２０は、ＲＯＭ１３に格納してある中間コード等（上記の通り暗号化されている）を取得して、これを復号して揮発性メモリ２３上に展開する。その後、ＣＰＵ２１は、インタプリタ処理によりこの揮発性メモリ２３に格納されている中間コード３１等を解釈・実行して、ＩＣカード決済処理等を実行することになる。
【０１１６】
尚、図６には、中間コード３１等を揮発性メモリ２３上に展開済みの状態を示してある。これは、一見、図４の実施例２と同様に見えるが、実施例２では中間コード等の保存場所が揮発性メモリ２３であるのに対して、本例では中間コード等の保存場所はＲＯＭ１３であり、揮発性メモリ２３上には一時的に記憶されるものである。
【０１１７】
また、実施例２では上記の通り、電源ＯＦＦ状態にあるときに中間コード３１，セキュリティデータ３２が漏洩する可能性は無いという効果が得られるが、その一方で、電源ＯＦＦ後に再起動した際には必ず、ＬＳＩ２０内に中間コード３１等が無い状態となっている為、再度、センタ装置２にアクセスして中間コード等をダウンロードする必要があるが、実施例３においてはＲＯＭ１３に格納してある中間コード等（暗号化）を取得して復号化すれば済むので、この様な手間が必要無くなる。
【０１１８】
更に、実施例３では、複数種類の電子マネーアプリケーションを扱う場合に、より大きな効果を奏するものとなる。すなわち、この場合、例えば後に実施例５等で説明するように、中間コード３１等を不揮発性メモリ２４に格納する場合には、複数種類の電子マネーそれぞれに対応する中間コード３１等を格納する必要がある為、その分、不揮発性メモリ２４のメモリ容量を大きくする必要がある。
【０１１９】
これに対して、実施例３では、複数種類の電子マネーそれぞれに対応する中間コード等を、全て、上記の通り暗号化してＲＯＭ１３に格納するので、不揮発性メモリ２４のメモリ容量の削減効果が、より大きなものとなる。また、ＲＯＭ１３に格納されている各種電子マネーの暗号化中間コード３６等のうち任意の電子マネーの暗号化中間コード３６等のみを復号化して揮発性メモリ２３に格納すればよいので、複数種類の電子マネーに対応する場合でも揮発性メモリ２３のメモリ容量を大きくする必要はない（実施例２において複数種類の電子マネーに対応する場合には、揮発性メモリ２３のメモリ容量を大きくする必要がある）。これは、例えば、３種類の電子マネーａ，ｂ，ｃに対応する場合を例にすると、ＲＯＭ１３にはこれら各種電子マネーａ，ｂ，ｃそれぞれに対応する暗号化中間コード３６等が格納されることになるが、例えば電子マネーａに対応するＩＣカードとの決済処理を行う際には、ＬＳＩ２０は電子マネーａに対応する暗号化中間コード３６等のみをＲＯＭ１３から取得して復号化して揮発性メモリ２３上に一時的に展開し、これを用いて決済処理を行い、決済処理完了したらメモリ２３上から削除すればよい。
【０１２０】
以下、上述した実施例３について更に詳しく説明する。
まず、上記の通り中間コード等は暗号化された状態でＲＯＭ１３に格納されるが、これは図６に示す例では、“端末の公開鍵Ｂ（Kpt）で暗号化された中間コード”３６（暗号化中間コード３６という場合もある）、“端末の公開鍵Ｂ（Kpt）で暗号化されたセキュリティデータ”３７（暗号化セキュリティデータ３７という場合もある）となっている。
【０１２１】
すなわち、実施例３の図７のステップ１３’では、上記実施例１等と同様にセンタ装置２は中間コード３１等をセッション鍵Ｇ(ks)で暗号化して配信してくるのが（上記暗号化中間コード３３、暗号化セキュリティデータ３４を配信してくる）、これをそのままＲＯＭ１３に格納するわけではない。セッション鍵Ｇ(ks)は、センタ装置２との通信の際に一時的に生成・使用されるものであり、通信完了と共に消去されるので、後で復号化できなくなるからである。
【０１２２】
これより、決済端末１０においては、図７のステップ１３’に示すように、端末管理ＣＰＵ１１は、配信されてきた暗号化中間コード３３等をＬＳＩ２０に渡し、ＬＳＩ２０は、上記実施例１等と同様にセッション鍵Ｇ(ks)を用いて暗号化中間コード３３等を復号して中間コード３１等を取得してその検証等を行った後、検証ＯＫであれば、取得した中間コード３１等を自己の“端末の公開鍵Ｂ（Kpt）”で暗号化して上記暗号化中間コード３６、暗号化セキュリティデータ３７を生成して、これらをＲＯＭ１３に格納する。これら暗号化データ３６，３７の復号は“端末の秘密鍵Ｃ（Kst）”を用いて行うことになる。
【０１２３】
尚、図７において、前準備処理、出荷前設定処理、及びStep１１，１２の処理は実施例１（図２）と同じであり、特に説明しない。
一方、図７に示すStep１４’，１５’、１６’の処理は、図２のStep１４，１５、１６の処理と一部異なる。すなわち、まず、Step１４’はＰＯＳ端末５からの決済指示に応じて決済処理、インタプリタ処理を行う点は図２のStep１４と同じであるが、その前に、ＰＯＳ端末５からの決済指示が来た際に、端末管理ＣＰＵ１１がＬＳＩ２０に上記ＲＯＭに格納されている上記暗号化中間コード３６、暗号化セキュリティデータ３７を渡して、ＬＳＩ２０においてこれらを“端末の秘密鍵Ｃ（Kst）”で復号して揮発性メモリ２３上に展開する処理を行う。そして、ＬＳＩ２０は、揮発性メモリ２３上に展開した中間コード３１等を用いて、電子マネー決済処理を行うことになる。
【０１２４】
また、ＬＳＩ２０は、決済処理完了したら、揮発性メモリ２３上に展開した中間コード３１等を削除する。
尚、複数種類の電子マネーに対応する場合には、端末管理ＣＰＵ１１は、上記ＰＯＳ端末５からの決済指示によって指定された電子マネー種類に応じた上記暗号化中間コード３６等を、ＲＯＭ１３から取得してＬＳＩ２０に渡すことになる。
【０１２５】
Step１５’の処理も、上記Step１４’の場合と略同様に、締め指示を受けたら、端末管理ＣＰＵ１１が上記ＲＯＭ１３に格納されている暗号化中間コード３６、暗号化セキュリティデータ３７をＬＳＩ２０に配信して、ＬＳＩ２０においてこれらを復号して揮発性メモリ２３上に展開する処理を行う（中間コード３１、セキュリティデータ３２を得て揮発性メモリ２３に格納する処理）。
【０１２６】
そして、ＬＳＩ２０内でStep１５と同様にこれら中間コード３１等を用いて締め処理等を行う。そして、ＬＳＩ２０は、締め処理完了したら、揮発性メモリ２３上に展開した中間コード３１等を削除する。
【０１２７】
また、Step１６’の処理では、端末管理ＣＰＵ１１は、撤去指示に応じて、ＲＯＭ１３に記憶されている暗号化データ（暗号化中間コード３６、暗号化セキュリティデータ３７）を削除する。
【０１２８】
尚、上記Step１４’の処理例では、決済処理毎に逐一、ＲＯＭ１３から暗号化中間コード３６等を取得して復号して中間コード３１等を揮発性メモリ２３に展開してその後に消去するものとしたが、この例に限らず、例えば起動時に暗号化中間コード３６等を復号して中間コード３１等を揮発性メモリ２３に展開した後は、消去せずに運用し、運用終了（電源ＯＦＦ）により消去されるようにしてもよい。但し、上述してある通り、複数の電子マネーアプリケーションを扱う場合には、上記Step１４’の処理例の処理を行うことで、揮発性メモリ２３のメモリ容量が少なくて済むという効果が得られる。
【０１２９】
次に、以下、実施例４について説明する。
上記実施例１〜３では、決済端末１０−センタ装置２間の暗号化通信に公開鍵暗号方式を用いる場合について説明したが、実施例４のように共通鍵暗号方式を採用しても良い。
【０１３０】
この場合、予め、電子マネー事業者側と端末メーカ側の両方で、同じ暗号鍵（端末−センタ共通鍵Ｈ（Kc_tc））を共有しておく必要がある。あるいは、電子マネー事業者側、端末メーカ側それぞれが独自に共通鍵暗号方式による暗号鍵を生成し、それぞれが自己が生成した暗号鍵を予め相手に渡しておくようにしてもよい。前者の場合、決済端末１０、センタ装置２はそれぞれ、同一の暗号鍵を用いるが、暗号化の手順が異なる方法で暗号化を行うようにしてもよい（勿論、両者とも、この２種類の暗号化手順を知っており、その暗号化／復号化プログラムを格納している）。一方、後者の場合、後述する暗号化データ５１の生成とその復号の為の暗号鍵と、暗号化データ５２の生成とその復号の為の暗号鍵とは異なることになる。
【０１３１】
但し、以下の説明では、上記のことを逐一説明することなく、単純に、電子マネー事業者側と端末メーカ側の両方で共有する同一の暗号鍵である“端末−センタ共通鍵Ｈ（Kc_tc）”によって、暗号化／復号化が行われるものとして説明する。
【０１３２】
まず、上記“端末−センタ共通鍵Ｈ（Kc_tc）”は、上記出荷設定作業の際、出荷する各決済端末１０に、上記“端末共有鍵Ａ（Kct）”や端末情報、センタ情報等と共に格納される。また、実施例４でも上記実施例１と同様に上記前準備処理を行っており、これによって得た上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５も、出荷設定作業の際に決済端末１０に格納される。尚、これら各種設定情報は、図８に示す通り、不揮発性メモリ２４に格納される。
【０１３３】
図８は、実施例４における決済処理セキュリティ情報配信システムの構成例を示す図である。
尚、図８のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。実施例１との違いは、センタ装置２−決済端末１０間の暗号化通信を、公開鍵ペアではなく、上記“端末−センタ共通鍵Ｈ（Kc_tc）”を用いて行う点である。つまり、公開鍵暗号方式ではなく共通鍵暗号方式で暗号化通信を行う点である。
【０１３４】
よって、本システムで用いる各種鍵は、図８の図上左下に示す通り、“端末の共有鍵Ａ（Kct）”、“端末−センタ共通鍵Ｈ（Kc_tc）”、“センタ秘匿鍵Ｄ（Kcc）”、“セッション鍵Ｇ（Ks）”の４種類である。そして、これにより、図示の通り、各メモリに格納される鍵が一部、図１とは異なることになる。
【０１３５】
まず、センタ装置２においては、その不揮発メモリ３には、上記センタの公開鍵ペア（“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”）の代わりに、“端末−センタ共通鍵Ｈ（Kc_tc）”が記憶される。他の鍵や暗号化データは図１と同じである。また、実施例１では図２のStep11において公開鍵の交換を行ったが、本例では必要ないので、揮発メモリ４に“端末の公開鍵Ｂ（Kpt）”が記憶されることはない。
【０１３６】
また、決済端末１０においては、その不揮発性メモリ２４には、上記端末の公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）の代わりに、“端末−センタ共通鍵Ｈ（Kc_tc）”が記憶される。他の鍵や暗号化データは図１と同じである。また、実施例１では図２のStep11において公開鍵の交換を行ったが、本例では必要ないので、揮発メモリ２３に“センタ公開鍵Ｅ（Kpc）”が記憶されることはない。
【０１３７】
実施例４においても、その全体的な処理シーケンスは、図２と略同様であり、ここでは特に説明しない。但し、上記の通り、Step11において公開鍵の交換を行わない点は異なるし、Step12の詳細な処理内容は異なる。すなわち、本例では、Step12の詳細な処理は、図３ではなく、図９の処理を行うことになる。
【０１３８】
図９は、実施例４におけるStep12の処理を詳細に説明する為のフロー図である。
図９において、図３と同一のデータや処理には、同一符号を付してある。
すなわち、決済端末１０において上記送信データ４１を生成する点、この送信データ４１の暗号化データを受信したセンタ装置２が、これを復号して得た上記復号データ４３を用いてステップＳ２１、Ｓ２２の判定処理を行う点は、実施例１の図３の処理と同じであり、ここでは特に説明しない。また、センタ装置２において認証成功後に上記応答データ４４を生成する点、この応答データ４４の暗号化データを受信した決済端末１０が、これを復号して得た上記復号データ４６を用いてステップＳ２３，２４の判定処理を行う点も、実施例１の図３の処理と同じであり、ここでは特に説明しない。
【０１３９】
上記の通り、図９において、図３と異なる点は、上記送信データ４１、応答データ４４の暗号化、復号化の処理であり、以下、これについて説明する。
尚、上記の通り、上記送信データ４１、応答データ４４自体は、図３と同じであるが、一応説明しておくならば、送信データ４１は、決済端末１０内で任意に生成した乱数Rtと、端末情報ハッシュ値と、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とから成る。また、応答データ４４は、センタ装置２が内部で任意に生成する乱数Rcと、センタ情報ハッシュ値と、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とから成る。
【０１４０】
まず、決済端末１０は、上記送信データ４１を生成したら、出荷設定時に上記不揮発性メモリ２４に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”でこの送信データ４１を暗号化することで、図示の暗号化データ５１を生成して送信する。この暗号化データ５１を受信したセンタ装置２は、上記不揮発メモリ３に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”と“センタ秘匿鍵Ｄ（Kcc）”を用いてこの暗号化データ５１を復号することで上記復号データ４３を得る。そして、上述したようにステップＳ２１、Ｓ２２の判定処理を行い、端末認証成功したならば、処理を続行して、上記復号データ４３における乱数Rtを記憶すると共に以下の処理を行う。
【０１４１】
すなわち、センタ装置２は、上記応答データ４４を生成したら、上記不揮発メモリ３に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”でこの応答データ４４を暗号化することで、図示の暗号化データ５２を生成して送信する。この暗号化データ５２を受信した決済端末１０は、上記不揮発性メモリ２４に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”と“端末の共有鍵Ａ（Kct）”とを用いて、この暗号化データ５２を復号することで上記復号データ４６を得る。そして、上述したようにステップＳ２３、Ｓ２４の判定処理を行い、センタ認証成功したならば、上記復号データ４６における乱数Rcを記憶する。そして、この乱数Rcと上記乱数Rtとに基づいて“セッション鍵Ｇ（Ks）”を生成し、Step13の処理を行うことになる。上記の通り、Step13以降の処理は図２と略同様であり、ここでは特に説明しない。
【０１４２】
上述したように、決済端末１０−センタ装置２間の相互認証処理の際の暗号化通信は、公開鍵暗号方式に限らず、共通鍵暗号方式を用いてもよい。
（実施例５）（複数の電子マネーアプリケーションを扱う場合）
図１０は、実施例５における決済処理セキュリティ情報配信システムの構成例を示す図である。すなわち、複数種類の電子マネーアプリケーションを扱うことが可能なシステム構成例を示す。
【０１４３】
尚、図１０のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。尚、図示の端末メーカサーバ１’は、基本的には図１の端末メーカサーバ１と略同様の処理機能を有するが、以下に説明するように複数の電子マネー事業者それぞれに対する前準備処理を行う点等が異なることから異なる符合（１ではなく１’を付してある）。
【０１４４】
尚、図では１つの電子マネー事業者のセンタ装置２のみを示すが、複数の電子マネー事業者の各センタ装置２が存在し得る。そして、図１０の端末メーカサーバ１’は、これら各センタ装置２との間で、予め上記実施例１等と同様に前準備処理を実行して、各センタ装置２から“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５やセンタ情報を取得しておく。当然、センタ秘匿鍵Ｄ（Kcc）は各センタ装置２毎に異なるものであるので、暗号化端末情報２５は（センタ情報も）各センタ装置２毎に異なるものであり、よってサーバ１は、取得した暗号化端末情報２５やセンタ情報を、各電子マネー事業者毎に対応付けてサーバ１内に格納しておき、その後のオンライン設定等に用いる。
【０１４５】
また、サーバ１’は、上記端末共有鍵Ａ（Kct）を、各電子マネー事業者毎に対応付けてそれぞれ生成して格納する。よって、端末共有鍵Ａ（Kct）は、１つではなく複数存在し、各電子マネー事業者毎に異なるものであるから、ここでは図示のように“アプリ固有秘匿鍵６２”と記すものとする。そして、上記前準備処理の際にセンタ装置２へ送信する上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５も、通信相手の電子マネー事業者に対応したアプリ固有秘匿鍵６２を用いて暗号化するものである。尚、その意味では、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５は“アプリ固有秘匿鍵６２で暗号化されたセンタ情報”３５と言うこともできるが、ここでは“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５と記すものとする。
【０１４６】
端末メーカ側において出荷設定の際には、出荷する各決済端末１０毎に上記実施例１と同様の設定を行う。但し、設定対象の決済端末１０が複数種類の電子マネーアプリケーションを扱うものである場合には、その決済端末１０で扱う電子マネー種類それぞれに対応する上記“アプリ固有秘匿鍵Ａ”と“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、センタ情報等を、ＬＳＩ２０内の不揮発性メモリ２４に格納する。
【０１４７】
勿論、実施例１と同様に、設定対象の決済端末１０においてその内部で上記任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる処理や、UI表示、プログラム追加・変更・削除、利用履歴（明細）記録等の非セキュリティ部分の電子マネー事業者のアプリケーションを、ＲＯＭ１３に格納する処理も行う。尚、この非セキュリティアプリケーションは、図１０においては“非決済プログラム”６３として示している。上記公開鍵ペアは、各電子マネー事業者毎に異なるものでないので、図示の通り１対の公開鍵ペアのみが記憶される。一方、上記“非決済プログラム”は、各電子マネー事業者毎に異なるものであり、図示の通り、各電子マネー種類それぞれについての“非決済プログラム”６３が格納される。
【０１４８】
出荷されて任意の店舗に設置後の決済端末１０は、上記実施例１の場合と同様に、上記公開鍵ペアや端末情報、“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等を用いて、センタ装置２から中間コード３１、セキュリティデータ３２を取得することになる。複数種類の電子マネーに対応する場合には、各電子マネー事業者のセンタ装置２からそれぞれ中間コード３１、セキュリティデータ３２を取得することになる。その際、通信相手の電子マネー事業者に対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５を用いることになる。中間コード３１等の取得の為の処理自体（相互認証処理やセッション鍵による暗号化中間コード３３等の配信、その復号処理等）は、実施例１と略同様であり、ここでは説明しない。
【０１４９】
取得した中間コード３１、セキュリティデータ３２は、図示の通り、各電子マネー事業者毎に対応付けて不揮発性メモリ２４に格納管理する。
その後は、例えばstep14の処理では、任意のＩＣカード６と決済処理を行う毎に、このＩＣカードの種類（電子マネーの種類）に対応する中間コード３１等を用いて、電子マネー決済処理を行うことになる。
【０１５０】
尚、後述する実施例６と同様に、上記取得・格納した中間コード３１、セキュリティデータ３２の格納アドレスを、後述するメモリ管理テーブル７０において、サービスコードに対応付けて記憶・管理するようにしてもよい。そして、上記任意のＩＣカード６との決済処理の際には、ＰＯＳレジ５等の上位端末からの決済指示で決済対象の電子マネー種類に応じた上記サービスコードが指定されるので、メモリ管理テーブル７０を参照することで、決済対象の電子マネー種類に応じた中間コード３１、セキュリティデータ３２の格納位置が分かるので、これらを用いて決済処理を行うことになる。
【０１５１】
以上説明したように、実施例５では、実施例１等のシステムの特徴を備えつつ複数種類の電子マネーアプリケーションを扱うことが可能なシステムを提供できる。
ここで、例えば、各決済端末１０の出荷先の各店舗毎に、その店舗の考えによりその店舗で扱う電子マネーの種類や数が決められているものであり、端末メーカ側では出荷先の要求に応じて各決済端末１０の設定を行うことになる。例えばある店舗ｘでは電子マネーａのみ、別の店舗ｙでは電子マネーｂのみ、更に別の店舗ｚでは電子マネーａとｃを扱うものとする。この場合、端末メーカ側では、出荷設定の際に、店舗ｘ向けの決済端末１０に対しては電子マネーａに対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等の設定情報を設定することになる。同様に、店舗ｙ向けの決済端末１０に対しては電子マネーｂに対応する上記設定情報（“アプリ固有秘匿鍵”６２等）を設定することになり、店舗ｚ向けの決済端末１０に対しては電子マネーａとｃそれぞれに対応する上記設定情報（“アプリ固有秘匿鍵”６２等）を設定することになる。
【０１５２】
しかしながら、出荷後に、店舗側の事情等により、その店舗で扱う電子マネーの種類を増やしたい（あるいは変更したい）場合がある。
また、上述したことから、上記実施例５では、出荷設定の際に、作業員は、各決済端末１０毎に、その決済端末１０で扱う電子マネー種類に対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等を選択して設定することになり、手間が掛かることになる。
【０１５３】
以下に説明する実施例６は、この様な問題に対応するものである。
実施例６は、実施例５と同様に複数種類の電子マネーアプリケーションを扱うことが可能なシステムを前提とする。よって、システム構成自体は、図１０と同じであってよく、以下の説明では図１０を参照して説明する。
【０１５４】
そして、図１１に、実施例６の通信シーケンスを示し、これを用いて説明する。
図１１に示すように、実施例６では、まず出荷設定の際には、決済端末１０に対して暗号鍵の設定（公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる処理）とその決済端末１０の端末情報の設定のみを行う（図２のＳ６とＳ８の処理のみ行う）。これらの情報は、各電子マネー事業者毎に対応するものではなく、共通して利用されるものであるからである。
【０１５５】
よって、このときには“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等の設定（図２のＳ７，Ｓ９の処理）は行わない。よって、実施例１等とは異なり、必ずしも出荷設定前に前準備処理を行わなければならないわけではない。但し、後述するメンテナンス情報アップロードのときまでには、前準備処理を行っている必要はある。前準備処理自体は、図２に示すものと同じであってよく（上記Ｓ１〜Ｓ５の処理を行う）、ここでは説明しない。但し、実施例５と同様、各電子マネー事業者それぞれのセンタ装置２と前準備処理を行って、各電子マネー種類毎に対応する“暗号化された端末情報”２５を取得することになる。また、これによって、各電子マネー事業者のセンタ装置２には、それぞれ、その電子マネー事業者に応じた“アプリ固有秘匿鍵”６２によって暗号化された“暗号化されたセンタ情報”３５が記憶されることになる。
【０１５６】
ここで、予め、各電子マネー種類毎に所定のサービスコードが決められているものとする。
そして、例えば、上記出荷設定作業において、出荷する各決済端末１０に関して、その決済端末１０で扱う電子マネー種類のサービスコードを、当該決済端末１０の端末識別ＩＤ等に対応付けてサーバ１の不図示の決済端末管理テーブルに登録しておく。この登録内容は、後に、例えば店舗側からの要求に応じて更新される場合がある。例えば、上記店舗ｚを例にすると、この店舗ｚに出荷される決済端末１０に関しては、最初は電子マネーａとｃのサービスコードが登録されるが、後に店舗ｚ側の要求により例えば電子マネーｂのサービスコードが追加登録されるものとする。この例では、この決済端末１０は、最初は２種類の電子マネーａとｃに対応するものであるが、後に３種類の電子マネーａ，ｂ，ｃに対応するものとなる。但し、実際にこれら各種電子マネーの決済処理を実行可能となる為には、後述するメンテナンス情報アップロード時の処理やstep13による中間データ３１等の取得処理を行う必要がある。
【０１５７】
尚、上記出荷設定作業の際、決済端末１０の不揮発性メモリ２４には、図１０に示すプログラム３０’も格納される。上記実施例１のプログラム３０はインタプリタ処理、アプリ格納処理等を行うプログラムであるが、このプログラム３０’は図１０に示すように更にサービス管理処理を実行するプログラムも含まれる。
【０１５８】
上記出荷設定作業を経て出荷されて任意の店舗に設置された決済端末１０は、例えば定期的に（本例ではメンテナンス情報アップロードで）、上記サービス管理処理プログラムを実行する。メンテナンス情報アップロードは、例えば、その決済端末１０の現在の状態を示す情報（例えば、現況、どの電子マネーに対応しているのか等）を、サーバ１に通知するものである。
【０１５９】
この処理では、まず、ネットワーク７を介して端末メーカサーバ１に接続して、所定の認証処理を行い（Ｓ１１）、認証成功した場合にはＳ１２以降の処理を行う。尚、認証処理自体は既存の認証手法による処理であってよく、ここでは特に説明しない。
【０１６０】
上記Ｓ１１の接続・認証処理の際、決済端末１０は、自己のメモリ（例えば不揮発性メモリ２４）に格納されているメモリ管理テーブル７０に登録されているサービスコード全てを、自己の端末識別ＩＤと共に端末メーカサーバ１に送信する。サーバ１は、上記不図示の決済端末管理テーブルを参照して、このテーブルに登録されているサービスコードと受信したサービスコードとを比較チェックして、アプリ追加が必要か不要かを判定する。例えば、上記店舗ｚを例にすると、例えば店舗ｚの決済端末１０が電子マネーａとｃのサービスコードを通知してきた場合、決済端末管理テーブルに電子マネーａとｃのサービスコードのみが登録されている場合にはアプリ追加不要と判定し、電子マネーａ，ｂ，ｃのサービスコードが登録されている場合には電子マネーｂのアプリ追加必要と判定する。
【０１６１】
また、出荷されて設置後に初めてサーバ１にアクセスしてきた決済端末１０については、当然、未だ中間コード３１等は何も記憶されていないので、メモリ管理テーブル７０には何も登録されていない状態であるので（後述する説明参照）、“サービスコード無し”をサーバ１に通知する。これより、サーバ１は、この決済端末１０について決済端末管理テーブルに登録されている全てのサービスコードのアプリ追加が必要と判定することになる。
【０１６２】
アプリ追加不要と判定した場合には、その旨を決済端末１０に返信する。
一方、アプリ追加必要と判定した場合には、以下に説明するＳ１２以降の処理を実行する。
【０１６３】
尚、上記メモリ管理テーブル７０に関しては、その一例を図１２に示し、後に説明する。
以下、Ｓ１２以降の処理について説明する。
【０１６４】
まず、サーバ１は、上記Ｓ１１の処理によりアプリ追加必要と判定した電子マネー種類（上記の例では電子マネーｂ）に係わるプログラム情報（この電子マネーの上記サービスコードや、そのプログラム、鍵等に関するサイズ情報等；具体例は後に図１２で説明する）と共にアプリ追加指示を決済端末１０に通知する（Ｓ１２）。
【０１６５】
尚、アプリ追加必要と判定した電子マネー種類が複数ある場合には、そのうちの任意の１つについてＳ１２以降の処理を行い、Ｓ１４の配信処理を実行するものとなり実行した場合には、その後に、他の電子マネー種類について同様にＳ１２以降の処理を行う。
【０１６６】
上記Ｓ１２の通知を受信した決済端末１０の端末管理ＣＰＵ１１は、まず、ＲＯＭ１３の空き容量の確認を行い、上記プログラム情報に含まれる非決済プログラム６３のサイズ情報に基づいて、当該非決済プログラム６３をＲＯＭ１３に格納可能か否か（「非決済プログラムのサイズ＜空き容量」か否か）を判定する。格納不能な場合にはその旨をサーバ１に通知する。
【０１６７】
一方、格納可能であれば、上記受信したプログラム情報（但し、非決済プログラムのサイズ情報は除く）をＬＳＩ２０に渡して、プログラム追加可能かを問い合わせる指示を出す。
【０１６８】
ＬＳＩ２０は、この指示に応じて、上記追加対象の電子マネー種類のプログラム、鍵等を不揮発性メモリ２４に格納可能か否かを、メモリ２４の全体サイズと現在の使用量と追加アプリのプログラム情報に基づいて判定して、判定結果を端末管理ＣＰＵ１１に返信する。
【０１６９】
これは、例えば、まず上記メモリ管理テーブル７０等に基づいて、不揮発性メモリ２４に現在格納されている各種データの総データサイズは分かるので、不揮発性メモリ２４の現在の空き容量は分かる（空き容量＝不揮発性メモリ２４の容量（全体サイズ）−総データサイズ）。一方、上記渡されたプログラム情報に基づいて、上記新たに追加すべき電子マネー種類に係わるプログラム、鍵等の総データサイズは分かるので、このプログラム等を不揮発性メモリ２４に格納可能か否かを判定できる。つまり、総データサイズ＜空き容量であれば格納可能と判定する。これより、判定結果を端末管理ＣＰＵ１１に通知する。
【０１７０】
また、もし格納可能と判定した場合には、上記メモリ管理テーブル７０に新規レコードを生成し、上記端末管理ＣＰＵ１１から渡されたプログラム情報（サービスコード、各サイズ（データ長））を新規レコードに格納する。
【０１７１】
ここで、図１２を参照してメモリ管理テーブル７０の一例について説明する。
図１２は、メモリ管理テーブル７０のデータ構成例である。
図示のメモリ管理テーブル７０は、サービスコード７１、端末共有鍵格納アドレス７２、そのデータ長７３、暗号化端末情報格納アドレス７４、そのデータ長７５、中間コード格納アドレス７６、そのデータ長７７、セキュリティデータ格納アドレス７８、そのデータ長７９の各データ項目より成る。
【０１７２】
つまり、メモリ管理テーブル７０には、不揮発性メモリ２４に格納される各種電子マネー毎の決済処理用プログラム／データ等の格納アドレスとサイズ情報が格納される。すなわち、各種電子マネー毎に、それに対応するアプリ固有秘匿鍵６２、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、中間コード３１、セキュリティデータ３２等の格納場所やサイズがメモリ管理テーブル７０に登録されることになる。
【０１７３】
例えば、端末共有鍵格納アドレス７２、そのデータ長７３は、アプリ固有秘匿鍵６２の格納アドレスとデータサイズである。暗号化端末情報格納アドレス７４、そのデータ長７５は、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５の格納アドレスとデータサイズである。中間コード格納アドレス７６、そのデータ長７７は、中間コード３１の格納アドレスとデータサイズである。セキュリティデータ格納アドレス７８、そのデータ長７９は、セキュリティデータ３２の格納アドレスとデータサイズである。
【０１７４】
上記端末管理ＣＰＵ１１から渡されるプログラム情報の具体例は、特に図示しないが、サービスコード、アプリ固有秘匿鍵６２のサイズ、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５のサイズ、中間コード３１のサイズ、セキュリティデータ３２のサイズであり、上記新規レコードへの格納処理の際には、これらがサービスコード７１、データ長７３、データ長７５、データ長７７、データ長７９にそれぞれ格納されることになる。各格納アドレス７２，７４，７６，７８はこの時点では未だ格納されない。
【０１７５】
また、上記メモリ２４に格納可能か否かの判定は、受信したプログラム情報における上記各データ長７３、７５，７７，７９の総和が、上記メモリ２４の空き容量未満であるか否かを判定することになる。
【０１７６】
端末管理ＣＰＵ１１は、上記ＬＳＩ２０から上記判定結果を受け取ると、これをサーバ１へ転送する（Ｓ１３の応答）。
サーバ１は、この応答を受信すると、判定結果が格納不可である場合には、本処理を終了する。一方、格納可能である場合には、追加すべき電子マネーに係わる、サービスコード、非決済部分のアプリケーション（非決済プログラム６３）、電子マネー事業者センタ接続情報（その電子マネー事業者のセンタ装置２のＩＰアドレス等）、センタ情報、アプリ固有秘匿鍵６２、及び“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を、決済端末１０にダウンロードする（Ｓ１４）。
【０１７７】
決済端末１０の端末管理ＣＰＵ１１は、これらダウンロード情報をＬＳＩ２０へ渡し、復号化等の処理を実行させ、復号化されて得られた各種情報のうち、サービスコードと非決済プログラム６３と電子マネー事業者センタ接続情報を受け取って、これらをＲＯＭ１３に記憶する。
【０１７８】
一方、ＬＳＩ２０は、上記復号化により得られた各種情報のうち、アプリ固有秘匿鍵６２）、及び“暗号化された端末情報”２５を、不揮発性メモリ２４に格納し、これらの格納アドレスをメモリ管理テーブル７０の端末共有鍵格納アドレス７２と暗号化端末情報格納アドレス７４にそれぞれ格納する。尚、その際、不揮発性メモリ２４における中間コード３１とセキュリティデータ３２の格納領域も確保しておき、これらの格納アドレスもメモリ管理テーブル７０の中間コード格納アドレス７６とセキュリティデータ格納アドレス７８にそれぞれ格納する。これにより、メモリ管理テーブル７０へのデータ登録は完了する。但し、この処理は、中間コード３１とセキュリティデータ３２を実際に取得・格納するまでは行わないようにしてもよい。
【０１７９】
その後は、決済端末１０は、上記の通り取得した各種設定情報を用いて、実施例１等の場合と同様にして、上記電子マネー事業者センタ接続情報を用いて電子マネー事業者のセンタ装置２へアクセスし、中間コード３１とセキュリティデータ３２を取得して、既に確保してある領域に中間コード３１とセキュリティデータ３２を記憶する。これにより、当該新たな電子マネーに係わる決済処理機能が活性化されることになる。
【０１８０】
その後の決済処理、締め処理、撤去処理は、実施例１の図２で説明したstep14,15,16の処理と略同様であってよいが、本例ではこれらの処理の際に、端末管理ＣＰＵ１１からは処理対象の電子マネーアプリのサービスコードを含んだコマンド指示（決済・締めなど）がＬＳＩ２０に送信され、ＬＳＩ２０はメモリ管理テーブル７０を参照することで上記指示されたサービスコードに対応する中間コード３１、セキュリティデータ３２の格納アドレスを読取り、読取ったアドレスに格納されている中間コード３１等を用いることで、指示された電子マネーに係わる決済処理等を実行することになる。
【０１８１】
以上説明したように、本システムによれば、電子マネー事業者は、電子マネーアプリケーションのセキュリティ処理に係わる情報（中間コード３１、セキュリティデータ３２等）を、端末メーカ側に公開することなく、これらの情報は出荷後にネットワークを介して決済端末１０にセキュアにダウンロードすることで電子マネー決済処理を実行可能な状態にすることができる。また、サービスコードによるメモリ管理を行うことで、複数の電子マネーアプリの管理ができ、一台で複数の電子マネーアプリケーションを実行可能となる。
【０１８２】
最後に、図１３に、上記センタ装置２やサーバ１のコンピュータのハードウェア構成の一例を示しておく。
図１３に示すコンピュータ１００は、ＣＰＵ１０１、メモリ１０２、入力部１０３、出力部１０４、記憶部１０５、記録媒体駆動部１０６、及びネットワーク接続部１０７を有し、これらがバス１０８に接続された構成となっている。
【０１８３】
ＣＰＵ１０１は、当該コンピュータ１００全体を制御する中央処理装置である。
メモリ１０２は、任意の処理実行の際に、記憶部１０５（あるいは可搬型記録媒体１０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、メモリ１０２に読み出したプログラム／データを用いて、各種処理を実行する。
【０１８４】
出力部１０４は、例えばディスプレイ等であり、入力部１０３は、例えば、キーボード、マウス等である。
ネットワーク接続部１０７は、例えば上記ネットワーク７に接続して、他の情報処理装置との通信（コマンド／データ送受信等）を行う為の構成である。
【０１８５】
記憶部１０５は、例えばハードディスク等であり、上述した各種処理をＣＰＵ１０１により実現させる為のアプリケーションプログラムが格納されている。すなわち、当該コンピュータ１００がセンタ装置２である場合には、上記前準備処理や、各決済端末１０への中間コード３１等のダウンロード処理等を、ＣＰＵ１０１により実行させる為のアプリケーションプログラムが格納されている。また、当該コンピュータ１００がサーバ１である場合には、上記前準備処理や、出荷設定処理（Ｓ６〜Ｓ９）や、図１１に示すダウンロード処理（Ｓ１１〜Ｓ１４）等を、ＣＰＵ１０１により実行させる為のアプリケーションプログラムが格納されている。
【０１８６】
尚、当該コンピュータ１００がセンタ装置２である場合、記憶部１０５は上記不揮発メモリ３に相当すると考えても良い（メモリ１０２は揮発性メモリ４に相当すると考えてよい）。
【０１８７】
ＣＰＵ１０１は、上記記憶部１０５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
あるいは、上記記憶部１０５に格納される各種プログラム／データは、可搬型記録媒体１０９に記憶されているものであってもよい。この場合、可搬型記録媒体１０９に記憶されているプログラム／データは、記録媒体駆動部１０６によって読み出される。可搬型記録媒体１０９とは、例えば、ＦＤ（フレキシブル・ディスク）１０９ａ、ＣＤ−ＲＯＭ１０９ｂ、その他、ＤＶＤ、光磁気ディスク等である。
【０１８８】
あるいは、また、上記プログラム／データは、ネットワーク接続部１０７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。
【０１８９】
また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。
【符号の説明】
【０１９０】
１ 端末メーカサーバ
２ 電子マネー事業者センタ装置
３ 不揮発メモリ
４ 揮発性メモリ
５ ＰＯＳレジ
６ ＩＣカード
７ ネットワーク
１０ 決済端末
１１ 端末管理ＣＰＵ
１２ ＲＡＭ
１３ ＲＯＭ
１４ ＵＩ
１５ 第１通信部
１６ 第２通信部
１７ 第３通信部
２０ ＬＳＩ
２１ ＣＰＵ
２２ 第４通信部
２３ 揮発性メモリ
２４ 不揮発性メモリ
２５ センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報
２６ 第５通信部
３１ 中間コード
３２ セキュリティデータ
３３ 暗号化中間コード
３４ 暗号化セキュリティデータ
３５ 端末共有鍵Ａ（Kct）で暗号化されたセンタ情報
３６ 端末の公開鍵Ｂ（Kpt）で暗号化された中間コード
３７ 端末の公開鍵Ｂ（Kpt）で暗号化されたセキュリティデータ
４１ 送信データ
４２ 暗号化データ
４３ 復号データ
４４ 応答データ
４５ 暗号化データ
４６ 復号データ
５１ 暗号化データ
５２ 暗号化データ
６２ アプリ固有秘匿鍵
６３ 非決済プログラム
７０ メモリ管理テーブル
７１ サービスコード
７２ 端末共有鍵格納アドレス
７３ データ長
７４ 暗号化端末情報格納アドレス
７５ データ長
７６ 中間コード格納アドレス
７７ データ長
７８ セキュリティデータ格納アドレス
７９ データ長
１００ コンピュータ
１０１ ＣＰＵ
１０２ メモリ
１０３ 入力部
１０４ 出力部
１０５ 記憶部
１０６ 記録媒体駆動部
１０７ ネットワーク接続部
１０８ バス
【技術分野】
【０００１】
本発明は、ＩＣカード等を用いる電子マネーシステムに係わり、特にその決済端末に対するセキュリティ情報設定方式に関する。
【背景技術】
【０００２】
ＩＣカードを使った電子マネーシステムが広く利用されている。電子マネーを運営する各電子マネー事業者は、電子マネーシステムを安全に運用するために、独自にセキュリティ機能を決済端末、データセンターに組み込むことで、セキュリティを確保している。セキュアなシステムを構築するためには、システム全体を電子マネー事業者が単独で構築することが望ましい。そこで、セキュリティ処理に関する機能を電子マネー事業者が開発して、決済端末に組み込むことでメーカとのセキュリティ境界を保っている。
【０００３】
これを実現するため、例えばインタプリタ機能をＩＣカード端末内のセキュアなＬＳＩに実装し、電子マネー事業者が例えばインタプリタ言語で開発したアプリケーション（ＩＣカードと通信して電子マネー決済処理を行うアプリケーション等（ここではインタプリタが解釈可能な中間コードを例にする））をロードし、ＬＳＩ内でこのアプリケーションを実行させる方法が考えられる。尚、上記セキュアなＬＳＩとは、例えば耐タンパ技術（例えば筐体の開封検知によりＬＳＩ内の上記アプリケーションを消去するもの等）により保護されているものである。
【０００４】
ここで、例えば、特許文献１には、インタプリタが解釈可能な中間コードを格納するＲＡＭと、中間コードを解釈実行可能なインタプリタ実行プログラムを格納するＲＯＭと、インタプリタ実行プログラムの実行を制御するＣＰＵとを備えたＬＳＩを用いることが開示されている。上記中間コードは、暗号化されている場合と暗号化されている場合がある。あるいは、上記ＲＡＭには暗号化された中間コードと暗号化されていない中間コードとが格納されており、この両方の中間コードをインタプリタ実行プログラムで解釈可能とすることも開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−３３３９８４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
上記特許文献１などの従来技術において、特に暗号化された中間コードを用いる手法においては、中間コードの暗号化は決済端末を製造する製造メーカ（または、この決済端末内の上記ＬＳＩを別のメーカが製造する場合には、当該ＬＳＩの製造／販売業者等）が割り当てた固定の暗号化鍵を利用しなければならず、中間コードの暗号化を製造メーカ等に委ねなければならず、電子マネー事業者と製造メーカ等との間の明確なセキュリティ境界を保つことが困難である。
【０００７】
ここで、従来では、決済端末内のＬＳＩに格納させる中間コードが暗号化されているか否かに関係なく、電子マネー事業者は、自己が開発した上記アプリケーション（ここでは中間コード）を決済端末の例えば製造メーカに渡して、製造メーカにおいてこのアプリケーションをそのまま（または暗号化して）決済端末内のＬＳＩ内のメモリに格納する作業を行うことで、決済端末が完成して出荷されることになる。この為、製造メーカ側で上記アプリケーション（中間コード）の内容を知り得ることになる。また、アプリケーション（中間コード）に限らず、そのセキュリティデータ（ＩＣカードとの通信の際に必要となる秘匿鍵等；中間コードが暗号化されている場合には、更に、復号化の為の鍵情報等）も、製造メーカに渡して、決済端末内のＬＳＩ内のメモリに格納させる作業を行わせる必要があり、セキュリティデータに関しても、その内容を製造メーカ側が知り得る状態にある。
【０００８】
電子マネー事業者側としては、電子マネー事業者と製造メーカ等と間の明確なセキュリティ境界を保つ為に、中間コードやセキュリティデータを製造メーカ等に渡したく無いという要望がある。しかしながら、上記の通り、中間コードやセキュリティデータを製造メーカ等に渡さなければ、実質的に決済端末は完成しないことになり（ハードウェアは製造できても、決済端末として機能する状態にはならない）、従来ではこの要望は適わなかった。
【０００９】
本発明の課題は、電子マネー事業者が、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等を、第３者（端末メーカ等）に公開することなく決済端末に設定でき、更に、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム等を提供することである。
【課題を解決するための手段】
【００１０】
本発明の決済処理セキュリティ情報配信方法は、電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける決済処理セキュリティ情報配信方法であって、予め、前記センタ装置と前記サーバ装置とが前記ネットワークを介して相互に通信処理を行うことで、前記センタ装置は、自己に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持する前準備処理ステップと、前記サーバ装置が、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記前準備処理ステップの際に取得した前記特定情報とを設定・格納する設定処理ステップと、前記各決済端末が出荷されて任意の設置場所に設置された後、前記センタ装置と前記決済端末とが前記ネットワークを介して暗号化通信により相互認証処理を行う処理であって、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と前記前準備処理ステップの際に取得した前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理ステップと、前記相互認証が成功した場合、前記センタ装置が前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、前記相互認証処理ステップで得られる暗号鍵によって暗号化して配信する配信ステップと、前記決済端末が、該暗号化された配信情報を前記相互認証処理ステップで得られる前記暗号鍵によって復号することで前記決済処理セキュリティ情報を取得する決済処理セキュリティ情報取得ステップとを有する。
【００１１】
本手法では、電子マネー事業者は、電子マネー決済処理に係わる決済処理セキュリティ情報（例えば上述した中間コード等）を、第３者（決済端末メーカ等）に渡さない。よって、各決済端末は、決済端末メーカ側によって製造・設定・出荷された時点では、決済処理セキュリティ情報を保持していないので、電子マネー決済処理の行えない（機能しない）。決済処理セキュリティ情報は、後から（決済端末設置後に）電子マネー事業者のセンタ装置から決済端末に配信される。
【００１２】
但し、決済処理セキュリティ情報は重要な情報であり、漏洩や誤配信は許されないので、センタ装置−決済端末間の通信を暗号化通信で行うだけでなく、予め前準備処理によって電子マネー事業者−決済端末メーカ間で交換した暗号化情報である上記暗号化特定情報、暗号化端末情報等を用いて認証処理を行うことで、相互に通信相手が正当なものであることを確認し、安全に決済処理セキュリティ情報を配信できるようにしている。
【発明の効果】
【００１３】
本発明の決済処理セキュリティ情報配信方法、決済処理セキュリティ情報配信システム、そのセンタ装置、サーバ装置、決済端末、及びプログラム等によれば、電子マネー事業者は、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等を、第３者（端末メーカ等）に公開することなく、決済端末に設定できる。この設定処理はネットワークを介して行うが、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる。
【図面の簡単な説明】
【００１４】
【図１】実施例１のプログラム配信システムの構成例を示す図である。
【図２】実施例１のプログラム配信システムの処理シーケンス例を示す図である。
【図３】図２のStep12の処理を詳細に説明する為のフロー図である。
【図４】実施例２のプログラム配信システムの構成例を示す図である。
【図５】実施例２のプログラム配信システムの処理シーケンス例を示す図である。
【図６】実施例３におけるプログラム配信システムの構成例を示す図である。
【図７】実施例３のプログラム配信システムの処理シーケンス例を示す図である。
【図８】実施例４におけるプログラム配信システムの構成例を示す図である。
【図９】実施例４におけるStep12の処理を詳細に説明する為のフロー図である。
【図１０】実施例５におけるプログラム配信システムの構成例を示す図である。
【図１１】実施例６のプログラム配信システムの処理シーケンス例を示す図である。
【図１２】メモリ管理テーブルのデータ構成例である。
【図１３】コンピュータハードウェア構成図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して本発明の実施の形態について説明する。
（実施例1）（単一アプリケーションの場合）
図１は、実施例１として、単一アプリケーションの場合のプログラム配信システムの構成例を示す図である。
【００１６】
ところで、ここで、現在では複数種類のＩＣカードが存在する。つまり、電子マネーは、各電子マネー事業者（ＩＣカード発行・決済会社）から異なる仕様の電子マネーブランドが規定され、それぞれ電子マネー用のＩＣカードが発行され、また携帯端末用ソフトウェアがリリースされている。また、決済端末における電子マネー決済処理に係わるソフトウェアも各電子マネー事業者がそれぞれ規定し作成している。このように、複数の電子マネー事業者が、それぞれ自社ブランドのＩＣカード等を発行し、また決済端末を製造させ、電子マネー決済処理を管理している。そして、昨今、１台の決済端末で複数のブランドの（複数種類の）電子マネーを利用できるマルチブランド対応の電子マネー決済端末が出現してきている。
【００１７】
この様な複数種類のＩＣカードに対応可能な決済端末では、自端末で扱う各ブランド毎の処理機能が必要である。これは、例えば、ＩＣカードとの通信は秘匿通信（暗号化通信）であるので、その為の鍵情報等が必要であるが、複数ブランドに対応する場合、各ブランド毎の鍵情報等を保持する必要がある。また、鍵情報に限らず、電子マネー決済処理に係わるアルゴリズムやＩＣカードとの通信方式も、各ブランド毎に異なるものであり、それぞれが上記アルゴリズムを実現するアプリケーションプログラム（上記中間コード等）を作成している。
【００１８】
実施例１に関する上記「単一アプリケーションの場合」とは、決済端末が、複数ブランド対応ではなく、任意の単一ブランドのみ対応可能なものである場合を意味している。尚、決済端末が複数ブランド対応の場合の実施例として、後に説明する実施例５、６がある。また、後に説明する実施例２〜４も、単一アプリケーションの場合の実施例である。
【００１９】
尚、決済端末の通信相手（電子マネー決済の処理対象）は、非接触ＩＣカードのようなカード型の形態に限らず、例えばＩＣカード機能内蔵の携帯電話やタグ型（ＩＣタグ）あるいは腕時計型の形態等であってもよく、これらを総称して非接触型情報媒体と呼ぶものとする。但し、本説明では非接触ＩＣカードを例にして説明する。尚、非接触ＩＣカードを省略してＩＣカードという場合もある。
【００２０】
また、以下の各実施例の説明では、上記電子マネー決済処理に係わるアプリケーションプログラムの一例として、上記従来技術、課題で示した「インタプリタが解釈可能な中間コード」を例にして説明するが、この例に限るものではない。すなわち、本例で決済端末に配信・設定する電子マネー決済処理プログラムは、上記中間コードに限るものではなく、またインタプリタ処理するプログラムに限るものでもない。
【００２１】
また、決済端末が決済処理を実行できるようにする為に（つまり、決済端末が機能する為に）必要な情報は、中間コード３１等の電子マネー決済処理プログラムだけでなく、セキュリティデータ３２（上記ＩＣカードとの暗号通信に必要な秘匿鍵）も含まれるものであり、またこれらのプログラム／データ（鍵等）は、漏洩してはならない重要な情報であり後述するセキュアなＬＳＩ２０内で記憶・実行させるべきものであるので、これらのプログラム／データ（鍵等）（本例では中間コード３１及びセキュリティデータ３２）をまとめて「（電子マネー決済処理に係わる）決済処理セキュリティ情報」と呼ぶものとする。
【００２２】
以下の各実施例の説明では、この「決済処理セキュリティ情報」の一例として、中間コード３１とセキュリティデータ３２（上記ＩＣカードとの暗号通信に必要な秘匿鍵等の、中間コードによる電子マネー決済処理の際に必要となる各種データ）を例にして説明するが、上記の通りこの例に限るものではない。
【００２３】
以下、図１に示す実施例１の決済処理セキュリティ情報配信システムの構成について説明する。
尚、図１、図４等に示すシステムは、電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムであるが、このシステムの主な特徴は上記「決済処理セキュリティ情報」を安全に各決済端末に配信して設定させるものであることから「決済処理セキュリティ情報配信システム」と呼ぶ場合もある。
【００２４】
図示の決済処理セキュリティ情報配信システムは、概略的には、電子マネー事業者が有する中間コードダウンロードセンタに設置されるセンタ装置（電子マネー事業者センタ装置２）と、決済端末１０を製造する任意の決済端末メーカ側に備えられるサーバ装置（端末メーカサーバ１）と、様々な各種店舗等に設置される多数の決済端末１０とが、ネットワーク７（インターネットやＶＰＮ（Virtual Private Network；仮想プライベートネットワーク）等）に接続された構成となっており、相互にデータ送受信可能となっている。尚、図上、決済端末メーカ内に決済端末１０を示してあるが、これは出荷時の決済端末１０の状態（初期設定）を説明する為に示しているものである。尚、この設定時に（図では省略してあるが）後述する各種プログラム３０も設定される。
【００２５】
尚、センタ装置２−サーバ１間に関しては、何らかの専用線で接続されていてもよい。
決済端末１０はセキュアなＬＳＩ２０を備えるものである。これは、上記従来で説明したように、例えば耐タンパ技術が適用されたものであり、その内部に格納されるアプリケーションやデータ等が安全に保護され漏洩しないようになっている。上記の通り、「決済処理セキュリティ情報」の一例である中間コード３１やセキュリティデータ３２は、このＬＳＩ２０内に保持させてＬＳＩ２０内で処理実行させるべきものである。
【００２６】
ここで、図示の通り、出荷時の状態では決済端末１０のＬＳＩ２０内には、中間コード３１やそのセキュリティデータ３２は格納されていない。つまり、本手法では、電子マネー事業者は、中間コード３１やそのセキュリティデータ３２を決済端末メーカ側に渡さないので、決済端末メーカはこれら中間コード３１等の内容を知り得ない一方で、当然、これら中間コード３１等を決済端末１０にインストールすることは出来ない。よって、出荷時の状態のままでは決済端末１０はＩＣカードによる電子マネー決済処理を実行できないが、本手法では後に（出荷先の任意の店舗に設置後に）センタ装置２から決済端末１０へネットワーク７を介して中間コード３１等をダウンロードするようにしている。
【００２７】
但し、この方法では、ネットワーク７を介して中間コード３１等の極めて重要なアプリケーション／データを配信することになるので、安全に配信できるようにすることが求められる。これに対して、本手法では例えば図１に示す各種鍵や事前に特定の鍵によって暗号化済みの情報等を用いて、図２、図３で説明する処理を行うことで、中間コード３１等を安全・確実に配信できるようにすることを特徴としている。
【００２８】
尚、図上下側に示す決済端末１０の構成では、中間コード３１等がセンタ装置２からダウンロードされて格納された後の状態を示している。
ここで、図示の決済処理セキュリティ情報配信システムにおいて用いる各種鍵は、図上ではＡ〜Ｇとして示す７種類の鍵である。すなわち、まず、全ての決済端末で共有する“端末の共有鍵（Kct）”（図上ではＡを併記する；これより、“端末の共有鍵Ａ（Kct）”と記す場合もある；他の鍵も同様である）がある。“端末の共有鍵Ａ（Kct）”は、例えば共通鍵暗号方式による鍵である（よって、暗号化と復号化の両方で同じ鍵を用いる）。“端末の共有鍵Ａ（Kct）”は例えばサーバ１内で任意に生成する。
【００２９】
また、各決済端末１０それぞれが自らの内部で生成する公開鍵暗号方式の鍵ペアである“端末の公開鍵Ｂ（Kpt）”と“端末の秘密鍵Ｃ（Kst）”がある。また、上記電子マネー事業者センタ装置２において内部で生成する公開鍵暗号方式の鍵ペアである“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”がある。また、上記電子マネー事業者センタ装置２において内部で生成する、共通鍵暗号方式による鍵である“センタ秘匿鍵Ｄ（Kcc）”がある。“センタ秘匿鍵Ｄ（Kcc）”によって暗号化と復号化の両方が行える。
更に、電子マネー事業者センタ装置２−任意の決済端末１０間での後述する相互認証処理によって得られる所定情報（本例では乱数）に基づいて生成される“セッション鍵Ｇ（Ks）”がある。“セッション鍵Ｇ（Ks）”は一時的に生成・使用される鍵である。
【００３０】
以下、図１に示す端末メーカサーバ１（以下、省略してサーバ１と記す場合もある）、電子マネー事業者センタ装置２（以下、省略してセンタ装置２と記す場合もある）、決済端末１０の構成について、より詳しく説明する。
【００３１】
まず、端末メーカサーバ１と電子マネー事業者センタ装置２は、ハードウェア的には一般的な汎用コンピュータの構成であってよく、ここでは特に図示しないが、よく知られているように、ＣＰＵ、記憶装置（ハードディスク等）、メモリ、通信機能部等を有し、記憶装置に予め記憶されている所定のアプリケーションプログラムを、ＣＰＵが読み出し実行することにより、所定の処理を実現する。本実施例１では、例えば後述する図２や図３に示す処理を実行する。
【００３２】
例えば、端末メーカサーバ１は上記“端末の共有鍵Ａ（Kct）”を生成・保持しており、電子マネー事業者センタ装置２は上記“センタ秘匿鍵Ｄ（Kcc）”を生成・保持しており、サーバ１とセンタ装置２はこれらの鍵を用いて後に図２で説明する前準備処理を実行する（サーバ１−センタ装置２間で暗号化情報の交換処理を実行する）。また、前準備処理後、サーバ１は、図２で説明する出荷前の各決済端末１０に対する出荷設定処理を実行する。また、センタ装置２は、上記前準備処理後、各決済端末１０との間で図２、図３で説明する相互認証処理、セキュリティ情報配信処理を実行する。
【００３３】
ここで、電子マネー事業者センタ装置２は、図１に示すように、上記メモリとして不揮発メモリ３と揮発性メモリ４を有している。不揮発メモリ３は例えばハードディスク等の補助記憶装置であり、揮発性メモリ４は例えば主記憶装置である。
【００３４】
不揮発メモリ３には、予め、中間コード３１及びそのセキュリティデータ３２が格納されており、更に、当該センタ装置２内で任意に生成する暗号鍵（“センタ秘匿鍵Ｄ（Kcc）”、及び公開鍵暗号方式の鍵ペアである“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”）が格納される。不揮発メモリ３には、更に、予め、センタ装置２に係わる特定情報（後に説明するセンタ情報等）が設定・格納されている。また、後に図２で説明する端末メーカサーバ１とのデータ交換処理（前準備処理）によって得られた“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５が格納される。
【００３５】
ここで、既に説明してある通りであり、中間コード３１及びそのセキュリティデータ３２は「（電子マネー決済処理に係わる）決済処理セキュリティ情報」であり、当然、決済端末１０はこの決済処理セキュリティ情報が無いと電子マネー決済処理を実行することはできない。また、この決済処理セキュリティ情報は、当然、重要な情報であり漏洩することは許されず、耐タンパのＬＳＩ２０内に保持されてＬＳＩ２０内で処理実行すべきものである。
【００３６】
しかしながら、本手法では、電子マネー事業者が上記決済処理セキュリティ情報を決済端末メーカ側に渡したくないという要望を実現する為、ＬＳＩ２０内に決済処理セキュリティ情報が保持されていない状態で決済端末１０が出荷されることになる。この為、そのままでは決済端末１０は電子マネー決済端末として機能しないことになる。この為、本手法では、後から、電子マネー事業者のセンタ装置２から各決済端末１０へ決済処理セキュリティ情報を配信するが、上記の通り決済処理セキュリティ情報の漏洩は許されないので、センタ装置２−決済端末１０間の通信を暗号化によって行うだけでなく、センタ装置２、決済端末１０それぞれが通信相手が正当な相手か否かを確認して、誤って第３者の装置に決済処理セキュリティ情報を配信することが無いようにする。
【００３７】
このような相互に通信相手が正当な相手か否かを確認の為に、後述するように予め前準備処理や設定処理により生成・格納した“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５等を用いる手法を提案するものである。
【００３８】
また、上記揮発性メモリ４には、任意の決済端末１０との所定の通信処理（後述する相互認証処理、中間コード３１等の配信処理等）を行う毎にその際に一時的に取得／生成される各種情報が格納される。すなわち、通信相手の任意の決済端末１０から取得した当該決済端末１０の上記“端末の公開鍵Ｂ（Kpt）”と、当該決済端末１０との後述する相互認証処理によって得られる所定情報（本例では乱数）に基づいてセンタ装置２が生成する“セッション鍵Ｇ（Ks）”が、一時的に格納される。また、この“セッション鍵Ｇ（Ks）”を用いて上記不揮発メモリ３内の中間コード３１及びそのセキュリティデータ３２を暗号化した“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４が、一時的に格納される。これら各種情報は、任意の決済端末１０との上記所定の通信処理を行う毎に取得／生成されて一時的に格納されるものであり、この通信処理が完了したら消去される。
【００３９】
また、端末メーカサーバ１は、特に図示しないが、その不揮発性メモリまたはハードディスク等に、予め登録された上記端末共有鍵Ａ（Kct）を格納しており、また各決済端末１０を製造する毎に、その決済端末１０に係わる各種情報である後述する「端末情報」（詳しくは後述する）が登録されて格納される。更に、上記製造した各決済端末１０に対する出荷前の設定作業を行う前に、上記前準備処理によって電子マネー事業者センタ装置２から各決済端末１０毎に対応する“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を取得して格納している。
【００４０】
尚、上記登録は、例えば端末メーカ１の作業員等が行うものである。
そして、端末メーカ側では、例えば作業員等が行う各決済端末１０の出荷前設定作業において、例えばサーバ１と設定対象の決済端末１０とを接続して、サーバ１から決済端末１０に上記端末共有鍵Ａ（Kct）とその端末１０に対応する上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを転送して、これらを決済端末１０の不揮発性メモリ２４に格納させる。更に、各決済端末１０に、その内部で任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて、これも不揮発性メモリ２４に格納させる。
【００４１】
また、サーバ１から後述する各種プログラム（インタプリタ処理やアプリケーション格納処理等のプログラム３０等）を決済端末１０に転送させて、これらも不揮発性メモリ２４に格納させる。
【００４２】
各決済端末１０は、上記出荷前設定作業完了後、出荷されて任意の各店舗に設置される。そして、後に図２、図３で説明する上記センタ装置２との所定の通信処理を行うことで、上記「決済処理セキュリティ情報」（中間コード３１とセキュリティデータ３２）を安全・確実に取得することができ、これによって電子マネー決済処理が可能な状態となる（ＩＣカードによる電子マネー決済端末として機能する状態となる）。
【００４３】
決済端末１０の詳細構成例、及び上記センタ装置２との所定の通信処理実行後の状態を、図１の図上下側に示し、以下、これを参照して説明する。
図示の例では、決済端末１０は、端末管理ＣＰＵ１１、ＲＡＭ１２、ＲＯＭ１３、ＵＩ１４、第１通信部１５、第２通信部１６、第３通信部１７、及びＬＳＩ２０等を有する。
【００４４】
決済端末１０を任意の店舗に設置する際に、第１通信部１５を店舗内の上位装置（ＰＯＳレジ５等）に接続し、第２通信部１６をネットワーク７に接続しておく。これより、決済端末１０は、上位装置（ＰＯＳレジ５等）と通信可能となり、またネットワーク７を介して外部の他の情報処理装置（ここでは特に電子マネー事業者センタ装置２）と通信可能となる。また、第３通信部１７は製造時に既にＬＳＩ２０内の第４通信部２２と接続しており、端末管理ＣＰＵ１１とＬＳＩ２０とは、これら通信部１７，２２を介して、相互にデータ送受信するものである。
【００４５】
端末管理ＣＰＵ１１は、当該決済端末１０全体を制御する中央処理装置である。端末管理ＣＰＵ１１は、ＲＯＭ１３に格納されている所定の各種アプリケーションプログラムを読出し・実行することにより、各種処理を実行する。例えば、第１通信部１５を介して上位装置（ＰＯＳレジ５等）との通信処理を行ったり、第２通信部１６を介してネットワーク７（ＬＡＮやインターネット等）を介した電子マネー事業者センタ装置２との通信処理を行ったり、第３通信部１７を介してＬＳＩ２０とのデータ送受信処理を行う。特に、後述する図２の処理において、ＬＳＩ２０と外部の装置（上記ＰＯＳレジ５やセンタ装置２等）との通信を中継する処理を行う。また、ＩＣカード６による電子マネー決済処理に関して、ＬＳＩ２０内で中間コード３１等により実行されるセキュアな処理以外の処理（例えば利用履歴の生成・格納等）も行う。これらの処理を実行するプログラムも、上記出荷前設定作業の際に登録されて、ＲＯＭ１３に格納される。
【００４６】
尚、上記ＲＯＭに格納される各種アプリケーションは、後の説明における“非セキュリティ部分のプログラム”や“非決済プログラム６３”に相当するものである。
上記のように、端末管理ＣＰＵ１１は、主に、決済端末１０内で実行される各種処理のうち、上記ＬＳＩ２０内で実行されるセキュアな処理（電子マネー決済処理）以外の処理を実行するものである。
【００４７】
ＲＯＭ１３には端末管理ＣＰＵ１１に実行させる上記所定の各種アプリケーションプログラム等が格納されている。
尚、ＲＯＭ１３は、純粋なＲＯＭ（書き換え不可）ではなく、例えばフラッシュメモリやＥＥＰＲＯＭなどの書換え可能な不揮発性メモリである。これより、例えばＩＣカード６との電子マネー決済処理毎にその利用履歴等が格納される。ＲＡＭ１２は例えばワークメモリである。
【００４８】
ＵＩ１４は、ユーザインタフェースに係わる機能部であり、例えばタッチパネル等の入力装置と、ディスプレイ等の表示装置等である。
ＬＳＩ２０は、ＣＰＵ２１、第４通信部２２、第５通信部２６、揮発性メモリ２３（ＳＲＡＭ等）、及び上述してある不揮発性メモリ２４（ＥＥＰＲＯＭ等）を有する。
【００４９】
ＬＳＩ２０は、例えば、プログラム３０によるインタプリタ処理により中間コード３１を解釈・実行して（その際、セキュリティデータ３２の暗号鍵情報等を用いる）、ＩＣカード６との電子マネー決算処理等を行い、またその利用履歴を暗号化して端末管理ＣＰＵ１１に渡し、ＲＯＭ１３等に格納させる。尚、プログラム３０は、図示の上記インタプリタ処理やアプリ等格納処理等をＣＰＵ２１により実行させる為の各種アプリケーションプログラムである。アプリ等格納処理は、後述する図２、図３に示すセンタ装置２との相互認証処理や中間コード３１等の配信処理におけるＬＳＩ２０の処理を行うものである。詳しくは後述する。
【００５０】
尚、ＬＳＩ２０には所謂“耐タンパ”適用されており、例えば不正を検知した場合には（筐体の破壊等の検知）、例えば揮発性メモリ２３、不揮発性メモリ２４に格納されている全データを消去することで、上記中間データ３１等の重要データの漏洩を阻止する。
【００５１】
上述してあるように、不揮発性メモリ２４（ＥＥＰＲＯＭ等）には、出荷時に既に、上記プログラム３０や、各種暗号鍵（上記端末共有鍵Ａ（Kct）、“端末の公開鍵Ｂ（Kpt）”、“端末の秘密鍵Ｃ（Kst）”）や、所定の暗号化情報（センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報２５）が格納されている。
【００５２】
ＣＰＵ２１は、上記の通り、各種プログラム３０を適宜読出し・実行することにより、例えば、後に図２、図３で説明する各種処理等を実行する。特に、上記アプリ等格納処理のプログラムを実行することにより、電子マネー事業者センタ装置２から中間コード３１、そのセキュリティデータ３２を取得できる（上記の通り、図には既に取得済みの状態を示してある）。また、このアプリ等格納処理中、揮発性メモリ２３には、センタ装置２から取得する“センタ公開鍵Ｅ（Kpc）”と、後に図２で説明する相互認証処理に基づいて内部で生成する“セッション鍵Ｇ（Ks）”が一時的に格納される。これら揮発性メモリ２３内の鍵情報は、中間コード３１、そのセキュリティデータ３２を取得したら（センタ装置２との通信が完了したら）消去する。
【００５３】
また、第５通信部２６は、ＩＣカード６と通信を行う機能部であり、例えばアンテナと送受信回路等から構成される。
上記図１に示す構成の決済処理セキュリティ情報配信システムでは、端末メーカ側には中間コード３１、そのセキュリティデータ３２は渡されない。よって、端末メーカ側では、中間コード３１、そのセキュリティデータ３２の内容を知ることができないが、その一方で当然、出荷時には決済端末１０内に中間コード３１、そのセキュリティデータ３２は格納されていない状態であるので、このままではＬＳＩ２０は機能せず、ＩＣカード６との通信・決済処理を行うことはできない（運用可能な状態ではない）。中間コード３１、そのセキュリティデータ３２は、各決済端末１０を任意の店舗内に設置後に、電子マネー事業者センタ装置２から配信する。
【００５４】
但し、中間コード３１、そのセキュリティデータ３２は、非常に重要な情報であり、漏洩してはならない。これに対して、本例の決済処理セキュリティ情報配信システムでは、上述した各種鍵や暗号化情報を用いて、安全に中間コード３１、そのセキュリティデータ３２を配信することができる。これについて、以下、図２、図３を参照して、主に安全に中間コード３１、そのセキュリティデータ３２を配信する為の処理について、詳細に説明する。
【００５５】
図２は、実施例１のプログラム配信システムの処理シーケンス例を示す図である。以下、この例を用いて説明する。
まず、上記前準備処理として、端末メーカサーバ１と電子マネー事業者センタ装置２との間で、ネットワーク７を介して所定のデータを交換する処理を行う。すなわち、まず、当該サーバ１−センタ装置２間でのデータ交換処理を暗号化通信で行うようにする為に、所定の暗号鍵の交換を行う（Ｓ１）。ここでは一例として、図３に示すセンタ装置２−決済端末１０間の暗号化通信例と同様に、公開鍵暗号方式を用いるものとする。よって、サーバ１とセンタ装置２とで、それぞれ公開鍵暗号方式による鍵ペア（公開鍵と秘密鍵のペア）を生成し、互いに自己の鍵ペアにおける公開鍵を相手側に送信する（ここでは、一方の公開鍵を公開鍵（Kp_tm）とし、他方は公開鍵（Kp_bc）とし、これらを交換する）。
【００５６】
そして、上記自己が生成した鍵ペア及び相手の公開鍵とを用いて、図３の場合と同様に、それぞれが任意の乱数を生成しつつ相互認証処理を行い、この相互認証処理の際に生成・交換される乱数情報等を用いて、通信セッション鍵（Ks_tmbc）を生成する。
【００５７】
以降の処理（Ｓ２以降の処理）においてはこの通信セッション鍵（Ks_tmbc）を用いて暗号化通信によるデータ送受信を行う。尚、当然、暗号化通信は、上記公開鍵暗号方式に限らず、共通鍵暗号方式によって行ってもよい。この場合には、サーバ１とセンタ装置２は予め同じ暗号鍵を共有している。
【００５８】
Ｓ２以降の処理について説明する。
まず、サーバ１は、出荷する決済端末１０に関する所定の各種情報である端末情報（例えば、端末ID，事業者ID，店舗ID，店舗端末IDなど）を、センタ装置２へ送信する（Ｓ２）。この端末情報は上記通信セッション鍵により暗号化されている（以下のＳ３，Ｓ４，Ｓ５で送受信する情報も同じであり、上記通信セッション鍵（Ks_tmbc）により暗号化されている）。また、以下の説明では逐一述べないが、暗号化された端末情報等は、通信セッション鍵（Ks_tmbc）による復号される。
【００５９】
尚、上記通信セッション鍵（Ks_tmbc）は、サーバ１−センタ装置２間のデータ送受信に用いる暗号鍵であり、後述する決済端末１０−センタ装置２間のデータ送受信に用いるセッション鍵Ｇ(ks)とは別のものである。同様に、上述した公開鍵（Kp_tm，Kp_bc）も、サーバ１−センタ装置２間の通信に用いるものであり、上述した７種類の鍵における公開鍵Ｂ，Ｅとは別のものである。
【００６０】
センタ装置２は、受信した端末情報を、電子マネー事業者側のみが知り得る（保持する）秘匿鍵である上記“センタ秘匿鍵Ｄ（Kcc）”によって暗号化することで上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を生成し、この“暗号化された端末情報”２５をサーバ１へ返信する（Ｓ３）。また、センタ装置２は、受信した端末情報を不揮発メモリ３に記憶しておく。サーバ１は上記返信された“暗号化された端末情報”２５を、自己の不図示の不揮発性メモリ等に記憶する（送信した端末情報に対応付けて記憶する）。
【００６１】
また、センタ装置２は、自装置に係わる所定の情報であるセンタ情報（事業者コード，ネットワークアドレスなど）を、サーバ１へ送信する（Ｓ４）。サーバ１は、受信したセンタ情報を、決済端末メーカ側のみが知り得る（保持する）秘匿鍵である上記“端末共有鍵Ａ（Kct）”で暗号化することで上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を生成し、この“暗号化されたセンタ情報”３５をセンタ装置２へ返信する（Ｓ５）。また、サーバ１は受信したセンタ情報を記憶しておく。センタ装置２は、上記返信された“暗号化されたセンタ情報”３５を、不揮発メモリ３に記憶する。
【００６２】
上述した前準備処理におけるＳ２とＳ３の処理は、出荷する各決済端末毎に対応して行うものである。よって、例えば出荷する決済端末１０が１００台あれば、Ｓ２とＳ３の処理を１００回行うことになる。一方、Ｓ４とＳ５の処理は、基本的に、１回だけ行えばよい。
【００６３】
以上説明した前準備処理を完了したら、その結果を用いて、端末メーカ側では、上記“出荷する決済端末１０”に対して上記出荷設定処理を行う。尚、この処理はサーバ１と“出荷する決済端末１０”とを接続して通信可能な状態として行う。
【００６４】
すなわち、例えば作業員等による指示操作により、“出荷する決済端末１０”において、その内部で上記任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる（Ｓ６）。
【００６５】
その後、サーバ１から“出荷する決済端末１０”に対して、上述した“端末共有鍵Ａ（Kct）”、当該“出荷する決済端末１０”の端末情報（端末ID，店舗ID，店舗端末IDなど）、当該“出荷する決済端末１０”に端末情報が暗号化されてなる上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、更に上記Ｓ４の処理で取得したセンタ情報を送信して、そのＬＳＩ２０の不揮発性メモリ２４に記憶させる（Ｓ７，Ｓ８，Ｓ９）。よって、図１には示していないが、端末情報（暗号化されていない）やセンタ情報も不揮発性メモリ２４に記憶される。また、既に述べた通り上記プログラム３０も設定されて不揮発性メモリ２４に記憶される。
【００６６】
また、ＵＩ（ユーザインタフェース）表示、つまりディスプレイ等への任意の情報表示や、利用履歴（明細）記録等の非セキュリティ部分の電子マネー事業者のアプリケーションを、決済端末１０のＲＯＭ１３（フラッシュメモリやＥＥＰＲＯＭ等）に格納する。
【００６７】
以上の出荷前の処理を経て、“出荷する決済端末１０”が出荷されて任意の店舗内に設置されたら、この決済端末１０はセンタ装置２０と通信を行って中間コード３１、そのセキュリティデータ３２を取得することで、運用可能状態となる。これについて、以下、図２だけでなく図３も参照して説明する。
【００６８】
上記設置後、電源ＯＮされて起動された決済端末１０において、端末管理ＣＰＵ１１は、まず、上記電子マネー事業者の“非セキュリティ部分のプログラム”を、ＲＡＭ１２にロードして実行する。このプログラム処理では、まず、図２に示すＳｔｅｐ１１、Ｓｔｅｐ１２、Ｓｔｅｐ１３の処理（その端末管理ＣＰＵ１１の処理）を実行する。尚、その際、ＬＳＩ２０のＣＰＵ２１は、上記プログラム３０により上記アプリ等格納処理を実行している。以下に、まず、これら各Stepの処理について説明する。
【００６９】
Step１1； 端末管理ＣＰＵ１１は、まず、ＬＳＩ２０と通信を行い、ＬＳＩ２０が中間コード３１とセキュリティデータ３２を保持しているか否かをチェックする（Ｓ１０）。そして、中間コード３１等を既に保持している場合には、図示のStep14以降の処理を実行可能な状態へ移行する。つまり、中間コード３１等の配信を受ける為の処理は行わない。
【００７０】
一方、中間コード３１等を保持していない（未配信）の場合には、中間コード３１等の配信を受ける為に、まず、ネットワーク７を介してセンタ装置２に接続し、公開鍵の交換を行う。これは、図３の最初の処理に示すように、決済端末１０の端末管理ＣＰＵ１１は、ＬＳＩ２０の不揮発性メモリ２４に保持されている上記“端末の公開鍵Ｂ（Kpt）”をＬＳＩ２０から取得して、これをセンタ装置２へ送信する。センタ装置２は、自己の不揮発メモリ３に保持されている上記“センタ公開鍵Ｅ（Kpc）”を決済端末１０へ送信する。端末管理ＣＰＵ１１は、受信した“センタ公開鍵Ｅ（Kpc）”をＬＳＩ２０に渡して揮発性メモリ２３に記憶させる。
【００７１】
Step12； 相互認証処理を実行し、認証成功したら“セッション鍵Ｇ（Ks）”を生成する。“セッション鍵Ｇ（Ks）”は、相互認証処理の際に得られる情報（例えば乱数）を用いて、決済端末１０、センタ装置２でそれぞれ生成するものであり、同じものが生成される。
【００７２】
上記相互認証処理では、予め上記前準備処理によって得られてセンタ装置２、決済端末１０にそれぞれ格納されている上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、端末情報、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５、センタ情報等を用いて、相互に、通信相手が正当なものであるか否かを確認する。これによって、センタ装置２にとっては誤って第３者の端末に中間コード３１等を配信してしまうことなく、また決済端末１０にとっては誤って第３者の装置から不正なプログラムをダウンロードすることで内部で（特にＬＳＩ２０内で）何らかの不正処理が実行されてしまうことなく、安全・確実に中間コード３１等が決済端末１０に配信されるようにできる。
【００７３】
尚、Step12の処理に関しては、詳しくは後に図３を参照して説明する。
Step13； 上記相互認証成功した場合、決済端末１０は、センタ装置２に対して中間コード３１とセキュリティデータ３２を要求する。この要求を受けたセンタ装置２は、上記不揮発メモリ３に格納されている中間コード３１及びそのセキュリティデータ３２を、上記生成した“セッション鍵Ｇ（Ks）”を用いてそれぞれ暗号化して、上記“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４を生成して決済端末１０へ送信する。これを受信した決済端末１０側では、ＬＳＩ２０内において、これら“暗号化中間コード”３３及び“暗号化セキュリティデータ”３４を、上記生成した“セッション鍵Ｇ（Ks）”で復号して、中間コード３１及びそのセキュリティデータ３２を得て、これらのコード３１、データ３２を不揮発性メモリ２４に格納する。
【００７４】
尚、復号化した後、この中間コード３１及びそのセキュリティデータ３２の検証を行い、検証結果がＯＫである場合に、これらのコード／データを不揮発性メモリ２４に格納する。尚、この検証処理は、本発明には特に関係ないので特に詳細には説明しないが、例えばセンタ装置２は中間コード３１のハッシュ値を生成してこのハッシュ値も一緒に送信し、ＬＳＩ２０はこのハッシュ値を用いて検証を行うものである。
【００７５】
以上で中間コード３１等は安全・確実に決済端末１０に配信され、センタ装置２−決済端末１０間の通信処理は終了する。通信処理終了したら、センタ装置２、決済端末１０は、それぞれ“セッション鍵Ｇ（Ks）”、相手から渡された公開鍵を消去する。
【００７６】
以上により、決済端末１０のセキュリティ機能（セキュアな電子マネー決済処理機能）の活性化が完了し、電子マネー決済処理が可能となる。
ここで、図３には、上記Step12の処理を詳細に説明する為のフロー図を示す。
【００７７】
尚、以下の説明では逐一述べないが、図３における決済端末１０側の処理は、基本的にＬＳＩ２０内のＣＰＵ２１が実行するものであり、端末管理ＣＰＵ１１はセンタ装置２−ＬＳＩ２０間で送受信されるパケットの中継・転送を行うものである。
【００７８】
以下、図３を参照して上記Step12の処理（相互認証処理）について説明する。
図３においては最初にStep11の処理例（公開鍵Ｂ，Ｅの交換）が示してあり、これについては既に説明してある。
【００７９】
図３に示す相互認証処理では、まず、決済端末１０は、その内部で任意の乱数Rtを生成し、また上記出荷設定時に記憶されている自身の端末情報を用いて、この端末情報のハッシュ値を生成する。
【００８０】
そして、これら乱数Rt、端末情報ハッシュ値と、出荷設定時に記憶されている“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とから成るデータ（図示の送信データ４１）を、各種鍵により暗号化してセンタ装置２へ送信する。これは、まず、乱数Rtと端末情報ハッシュ値とを自身の秘密鍵（“端末の秘密鍵Ｃ（Kst）”）で暗号化し、更にこれら暗号化情報と上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを上記Step11の処理で取得している“センタ公開鍵Ｅ（Kpc）”で暗号化することで図示の暗号化データ４２を生成する。そして、この暗号化データ４２をセンタ装置２へ送信する。
【００８１】
上記暗号化データ４２を受信したセンタ装置２は、この暗号化データ４２を自身が保持する各種鍵を用いて復号する。すなわち、まず、上記“センタ公開鍵Ｅ（Kpc）”による暗号化に対して、“センタ秘密鍵Ｆ（Ksc）”を用いて復号することで、「“端末の秘密鍵Ｃ（Kst）”で暗号化された乱数Rt及び端末情報ハッシュ値」と“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とを得る。
【００８２】
続いて、上記「“端末の秘密鍵Ｃ（Kst）”で暗号化された乱数Rt及び端末情報ハッシュ値」を“端末の公開鍵Ｂ（Kpt）”で復号して、乱数Rtと端末情報ハッシュ値を得る。更に、上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５をセンタ秘匿鍵Ｄ（Kcc）で復号して「端末情報」を得る。これらの処理により図示の復号データ４３を得ることができる。
【００８３】
上記復号処理が正常に行えなかった場合や後述するステップＳ２１，Ｓ２２の判定で一方でも判定ＮＯであった場合は、処理終了し、それ以降の処理は行われない。よって、当然、中間データ等の配信は行われない。但し、決済端末１０に認証失敗を通知してもよい。
【００８４】
一方、上記復号処理が正常完了して上記復号データ４３を得ることができた場合には、続いて、この復号データ４３における「端末情報」と、上記Ｓ２の処理の際に取得して登録してあった端末情報とが一致するか否かをチェックする（上記の通り、基本的には複数の端末情報（例えば１００台分の端末情報）が記憶されているので、その中で一致するものがあるか否かをチェックする）。つまり、通信相手の装置が、登録済みの決済端末１０であるか否かを確認する（ステップＳ２１）。
【００８５】
端末情報が一致する場合には（ステップＳ２１，ＹＥＳ）、続いてこの端末情報のハッシュ値を求め（尚、ハッシュ値の生成アルゴリズムは、上記決済端末１０と同じである）、このハッシュ値が上記復号データ４３における端末情報ハッシュ値と一致するか否かをチェックし（ステップＳ２２）、一致する場合には（ステップＳ２２，ＹＥＳ）、通信相手の決済端末１０が正当なものであるものとして端末認証成功と判定し、処理を続行する。
【００８６】
また、上記ステップＳ２１の処理によって、通信相手の決済端末１０を特定できる（登録されている決済端末のうちのどの決済端末であるのか分かる）。よって、例えば、登録されている（つまり、出荷されているはずの）各決済端末１０のうち、どの決済端末１０に中間コード３１等を配信済み（または未配信）であるか等を管理することも可能となる。
【００８７】
一方、上記ステップＳ２１，Ｓ２２の何れかで不一致の判定（ＮＯ）となった場合には、上記の通り、処理終了し、それ以降の処理は行われない。よって、当然、中間データ等の配信は行われない。
【００８８】
上記ステップＳ２１，Ｓ２２の判定がＹＥＳとなり認証成功した場合には、続いて、まず、上記取得した乱数Rtを揮発性メモリ４に記憶する。そして、任意の乱数Rcを生成し、更に自己のセンタ情報のハッシュ値を生成する。そして、これら乱数Rc、センタ情報ハッシュ値と、上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とから成るデータ（図示の応答データ４４）を、各種鍵により暗号化して図示の暗号化データ４５を生成して、これを接続先の決済端末１０へ送信する。
【００８９】
これは、まず、乱数Rcとセンタ情報ハッシュ値とを“センタ秘密鍵Ｆ（Ksc）”で暗号化し、更にこれら暗号化情報と上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とを上記Step11の処理で取得している“端末の公開鍵Ｂ（Kpt）”で暗号化することで図示の暗号化データ４５を生成する。そして、この暗号化データ４５を接続先の決済端末１０へ送信する。
【００９０】
この暗号化データ４５を受信した決済端末１０は、この暗号化データ４５を自身が保持する各種鍵を用いて復号する。すなわち、まず、上記“端末の公開鍵Ｂ（Kpt）”による暗号化に対しては、“端末の秘密鍵Ｃ（Kst）”で復号することで、「“センタ秘密鍵Ｆ（Ksc）”で暗号化された乱数Rc及びセンタ情報ハッシュ値」と“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を得る。続いて、上記「“センタ秘密鍵Ｆ（Ksc）”で暗号化された乱数Rc及びセンタ情報ハッシュ値」を“センタ公開鍵Ｅ（Kpc）”で復号して、乱数Rcとセンタ情報ハッシュ値を得る。また、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５を、端末共有鍵Ａ（Kct）で復号して「センタ情報」を得る。これらの処理により図示の復号データ４６を得ることができる。
【００９１】
そして、この復号データ４６における「センタ情報」が、上記出荷設定時に記憶されているセンタ情報と一致するか否かをチェックする（ステップＳ２３）。一致する場合には（ステップＳ２３，ＹＥＳ）、続いてこのセンタ情報のハッシュ値を求め、このハッシュ値が上記復号データ４６におけるセンタ情報ハッシュ値と一致するか否かをチェックし（ステップＳ２４）、一致する場合には（ステップＳ２４，ＹＥＳ）、通信相手のセンタ装置２が正当なものであるとしてセンタ認証成功と判定し、処理を続行する。尚、上記取得した乱数Rcは揮発性メモリ２３等に記憶しておく。
【００９２】
一方、上記各種鍵による暗号化データ４５の復号化処理が成功しなかった場合、または上記ステップＳ２３，Ｓ２４の何れか一方でも不一致の判定（ＮＯ）となった場合には、処理終了し、それ以降の処理は行われない。よって、当然、中間データ３１等のダウンロードは行われない。但し、センタ装置２に対して認証失敗を通知してもよい。
【００９３】
尚、上記乱数の一致も認証成功の条件としてもよい。この場合、センタ装置２は上記復号データ４３における乱数Ｒｔも上記暗号化データ４５に含めて送信し、決済端末１０は受信した暗号化データ４５に含まれる乱数Ｒｔが自己が生成している乱数Ｒｔと一致するか否かをチェックする処理も上記ステップＳ２３、Ｓ２４の処理に加えて行うようにしてもよい。尚、乱数Ｒｃに関しても同様にしてセンタ装置２側で乱数Ｒｃ一致か否かをチェックするようにしてもよい。
【００９４】
尚、上記ステップＳ２２、ステップＳ２４の処理は、必ずしも必須の処理ではなく、ステップＳ２１、ステップＳ２３の処理のみを行っても良い。つまり、センタ装置２はステップＳ２１の判定がＹＥＳである場合には通信相手の決済端末１０を認証成功と判定してよく、決済端末１０はステップＳ２３の判定がＹＥＳである場合には通信相手のセンタ装置２を認証成功と判定してもよい。勿論、この場合には、上記端末情報ハッシュ値やセンタ情報ハッシュ値は、生成する必要はないしデータ４１、４４に含める必要もない。
【００９５】
上記センタ装置２、決済端末１０はどちらも、上記のように認証成功と判定した場合には、図示していないが、更に以下に説明する処理を実行する。
すなわち、センタ装置２、決済端末１０の両方とも、上記相互認証処理が成功したときには、自己が生成した乱数と相手から取得した乱数の２つの乱数、すなわち上記乱数Ｒｔと乱数Rcを記憶している。すなわち、相互認証処理によって得られる所定情報を記憶している。これより、センタ装置２、決済端末１０の両方とも、この２つの乱数Ｒｔと乱数Rcとに基づいて上記“セッション鍵Ｇ（Ks）”を生成する。これは、センタ装置２、決済端末１０の両方で同じ“セッション鍵Ｇ（Ks）”を生成するものである。つまり、“セッション鍵Ｇ（Ks）”の生成アルゴリズムは、何でもよいが（例えば単純な例では「Ｒｔ＋Ｒｃ」とする）、予め各決済端末１０とセンタ装置２に、同じ生成アルゴリズムのプログラムを格納しておく。よって、セッション鍵生成に用いるデータが同じであるので（ここでは乱数Ｒｔと乱数Ｒｃ）、決済端末１０とセンタ装置２は同じセッション鍵を生成することになる。
【００９６】
そして、上記Step13で説明してある通り、中間コード３１等の配信処理は、“セッション鍵Ｇ（Ks）”を用いた暗号化通信により行うことになる。つまり、センタ装置２は中間コード３１等を“セッション鍵Ｇ（Ks）”で暗号化して決済端末１０に送信し、これを受信した決済端末１０（そのＬＳＩ２０）はこの暗号化情報を自己の“セッション鍵Ｇ（Ks）”を用いて復号することで、安全に中間コード３１等を取得することができる。
【００９７】
上述した処理により、決済端末１０は安全・確実に中間コード３１及びそのセキュリティデータ３２を得ることができ、ＩＣカード等との電子マネー決済処理が可能となり、運用開始することができる。
【００９８】
運用開始後の処理である図２に示すStep14、Step15、Step16の処理は、Step16の撤去処理においてＬＳＩ２０内の中間コード３１，セキュリティデータ３２等を削除する点以外は、既存の処理と同じであってよい。よって、以下、簡単に説明するのみとする。
【００９９】
まず、Step14の決済処理について説明する。
決済端末１０がＰＯＳレジ５等の上位端末から決済指示を受けると、端末管理ＣＰＵ１１は、明細を作成してこれを仮明細としてフラッシュやＥＥＰＲＯＭなどの不揮発性メモリ（ＲＯＭ１３）に記憶する。また、ＵＩ１４による表示制御によって顧客にＩＣカードの提示を促す等した後、ＬＳＩ２０に決済指示を出す。
【０１００】
ＬＳＩ２０のＣＰＵ２１は、この決済指示に従って、プログラム３０のインタプリタ処理によって中間コード３１を解釈・実行することで（その際、セキュリティデータ３２を用いる）、ＩＣカード６との（秘匿通信による）電子マネー決済処理を行う。そして、決済処理の完了で明細を確定し、処理結果を端末管理ＣＰＵ１１に通知する。
【０１０１】
端末管理ＣＰＵ１１は、ＵＩ１４による表示制御（ディスプレイ表示等）で決済完了を顧客に通知するとともに、上位端末に決済結果を通知する。
次にStep15の締め処理について説明する。
【０１０２】
決済端末１０が上位端末から締め指示を受けると、端末管理ＣＰＵ１１は、締め対象の明細情報を作成し、フラッシュやＥＥＰＲＯＭなどの不揮発性メモリ（ＲＯＭ１３）に記憶する。また、端末管理ＣＰＵ１１は、ＬＳＩ２０に締め対象の明細情報を渡して暗号化処理を指示する。
【０１０３】
ＬＳＩ２０は、この指示に従って、プログラム３０のインタプリタ処理によって中間コード３１を解釈・実行することで（その際、セキュリティデータ３２を用いる）、上記の明細情報の暗号化を行って、この暗号化明細情報を端末管理ＣＰＵ１１に返信する。
【０１０４】
端末管理ＣＰＵ１１は、この暗号化明細情報をセンタ装置２に送信する。送信完了後、端末管理ＣＰＵ１１は、締め情報とセンタ装置２への通信結果を上位端末に通知する。
次に、Step16の店舗の改修や移転・サービス終了時等における決済端末１０の撤去に伴う撤去処理について説明する。
【０１０５】
決済端末１０が上位端末から撤去指示を受けると、端末管理ＣＰＵ１１は、ＬＳＩ２０に対して中間コード３１，セキュリティデータ３２の削除を指示する。ＬＳＩ２０は、この指示に従い、不揮発性メモリ２４に記憶されている中間コード３１，セキュリティデータ３２を削除して、削除完了を端末管理ＣＰＵ１１に通知する。
【０１０６】
削除処理の完了を確認した端末管理ＣＰＵ１１は、センタ装置２に対して撤去完了の通知を行う。
以上説明したように、実施例１のシステムによれば、電子マネー事業者は、自己の電子マネーの決済処理に係わるアプリケーション等であって特にセキュリティ仕様を実現するアプリケーション等（「決済処理セキュリティ情報」；本例では中間コード３１、セキュリティデータ３２）を、第３者（端末メーカ等）に公開することなく、決済端末を機能させるためのアプリケーション等（決済処理セキュリティ情報）を決済端末に設定できる。この設定処理はネットワークを介して行うが、予め実行されている前準備処理等によって得られている暗号化情報や各種鍵を用いることで、安全・確実に上記アプリケーション等を決済端末に配信して設定できる。尚、以下に説明する実施例２〜６の各実施例についても、上記実施例１の効果と同様の効果が得られる（更に、その実施例に固有の効果が得られる場合もある）。
【０１０７】
次に、以下、実施例２について説明する。
図４は、実施例２におけるプログラム配信システムの構成例を示す図である。
尚、図４のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。図１と異なるのは、鍵の格納場所や一部の処理内容であり、以下、主に実施例１とは異なる点について説明する。
【０１０８】
図４に示す通り、実施例１との違いは、中間コード３１，セキュリティデータ３２を、不揮発性メモリ２４ではなく、揮発性メモリ２３に記憶することである。
図５は、実施例２の決済処理セキュリティ情報配信システムの処理シーケンス例を示す図である。
【０１０９】
図示の通り、図５は、図２に示す実施例１のシーケンスと殆ど同じであり、異なる点についてのみ説明する。すなわち、図２のStep11の代わりに、図示のStep11’の処理を実行する点のみが異なる。
【０１１０】
実施例２では、決済端末１０は、中間コード３１等の有無を確認する処理（Ｓ１０）は行わずに、常に、上記Ｓ１０の判定において中間コード３１等を保持していない（未配信）と判定された場合の処理を実行する。よって、図示のStep11’の処理では、決済端末１０は、電源ＯＮされたら、上記Step11で説明した「ネットワーク７を介してセンタ装置２に接続し、公開鍵の交換を行う」処理を実行する。そして、Step12,13の処理を実行することで、中間コード３１等を取得する。
【０１１１】
実施例２では、上記の通り、中間コード３１，セキュリティデータ３２を揮発性メモリ２３に記憶しているので、電源ＯＦＦにより消去される。よって、再起動の際には必ずＬＳＩ２０内には中間コード３１，セキュリティデータ３２は保持されていない状態であるので、上記ステップＳ１０の処理を行う必要がない。よって、上記Step11の代わりに上記Step11’の処理を実行している。
【０１１２】
実施例２では、電源ＯＦＦにより必ず中間コード３１，セキュリティデータ３２は消去されるので、運用中以外（夜間等）で電源ＯＦＦ状態にあるときに、中間コード３１，セキュリティデータ３２が漏洩する可能性は無いことになる。また、不揮発性メモリ２４のメモリ容量が少なくて済む（少なくとも実施例１の場合と比べて少なくて済む）。
【０１１３】
次に、以下、実施例３について説明する。
図６は、実施例３における決済処理セキュリティ情報配信システムの構成例を示す図である。
【０１１４】
また、図７は、実施例３の決済処理セキュリティ情報配信システムの処理シーケンス例を示す図である。
尚、図６のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。
【０１１５】
実施例３では、決済端末１０において、ダウンロードした中間コード３１，セキュリティデータ３２を、ＬＳＩ２０内の揮発性メモリ２３や不揮発性メモリ２４には格納せずに、暗号化された状態でＬＳＩ２０の外部のＲＯＭ１３に格納しておく。そして、任意のときに、ＬＳＩ２０は、ＲＯＭ１３に格納してある中間コード等（上記の通り暗号化されている）を取得して、これを復号して揮発性メモリ２３上に展開する。その後、ＣＰＵ２１は、インタプリタ処理によりこの揮発性メモリ２３に格納されている中間コード３１等を解釈・実行して、ＩＣカード決済処理等を実行することになる。
【０１１６】
尚、図６には、中間コード３１等を揮発性メモリ２３上に展開済みの状態を示してある。これは、一見、図４の実施例２と同様に見えるが、実施例２では中間コード等の保存場所が揮発性メモリ２３であるのに対して、本例では中間コード等の保存場所はＲＯＭ１３であり、揮発性メモリ２３上には一時的に記憶されるものである。
【０１１７】
また、実施例２では上記の通り、電源ＯＦＦ状態にあるときに中間コード３１，セキュリティデータ３２が漏洩する可能性は無いという効果が得られるが、その一方で、電源ＯＦＦ後に再起動した際には必ず、ＬＳＩ２０内に中間コード３１等が無い状態となっている為、再度、センタ装置２にアクセスして中間コード等をダウンロードする必要があるが、実施例３においてはＲＯＭ１３に格納してある中間コード等（暗号化）を取得して復号化すれば済むので、この様な手間が必要無くなる。
【０１１８】
更に、実施例３では、複数種類の電子マネーアプリケーションを扱う場合に、より大きな効果を奏するものとなる。すなわち、この場合、例えば後に実施例５等で説明するように、中間コード３１等を不揮発性メモリ２４に格納する場合には、複数種類の電子マネーそれぞれに対応する中間コード３１等を格納する必要がある為、その分、不揮発性メモリ２４のメモリ容量を大きくする必要がある。
【０１１９】
これに対して、実施例３では、複数種類の電子マネーそれぞれに対応する中間コード等を、全て、上記の通り暗号化してＲＯＭ１３に格納するので、不揮発性メモリ２４のメモリ容量の削減効果が、より大きなものとなる。また、ＲＯＭ１３に格納されている各種電子マネーの暗号化中間コード３６等のうち任意の電子マネーの暗号化中間コード３６等のみを復号化して揮発性メモリ２３に格納すればよいので、複数種類の電子マネーに対応する場合でも揮発性メモリ２３のメモリ容量を大きくする必要はない（実施例２において複数種類の電子マネーに対応する場合には、揮発性メモリ２３のメモリ容量を大きくする必要がある）。これは、例えば、３種類の電子マネーａ，ｂ，ｃに対応する場合を例にすると、ＲＯＭ１３にはこれら各種電子マネーａ，ｂ，ｃそれぞれに対応する暗号化中間コード３６等が格納されることになるが、例えば電子マネーａに対応するＩＣカードとの決済処理を行う際には、ＬＳＩ２０は電子マネーａに対応する暗号化中間コード３６等のみをＲＯＭ１３から取得して復号化して揮発性メモリ２３上に一時的に展開し、これを用いて決済処理を行い、決済処理完了したらメモリ２３上から削除すればよい。
【０１２０】
以下、上述した実施例３について更に詳しく説明する。
まず、上記の通り中間コード等は暗号化された状態でＲＯＭ１３に格納されるが、これは図６に示す例では、“端末の公開鍵Ｂ（Kpt）で暗号化された中間コード”３６（暗号化中間コード３６という場合もある）、“端末の公開鍵Ｂ（Kpt）で暗号化されたセキュリティデータ”３７（暗号化セキュリティデータ３７という場合もある）となっている。
【０１２１】
すなわち、実施例３の図７のステップ１３’では、上記実施例１等と同様にセンタ装置２は中間コード３１等をセッション鍵Ｇ(ks)で暗号化して配信してくるのが（上記暗号化中間コード３３、暗号化セキュリティデータ３４を配信してくる）、これをそのままＲＯＭ１３に格納するわけではない。セッション鍵Ｇ(ks)は、センタ装置２との通信の際に一時的に生成・使用されるものであり、通信完了と共に消去されるので、後で復号化できなくなるからである。
【０１２２】
これより、決済端末１０においては、図７のステップ１３’に示すように、端末管理ＣＰＵ１１は、配信されてきた暗号化中間コード３３等をＬＳＩ２０に渡し、ＬＳＩ２０は、上記実施例１等と同様にセッション鍵Ｇ(ks)を用いて暗号化中間コード３３等を復号して中間コード３１等を取得してその検証等を行った後、検証ＯＫであれば、取得した中間コード３１等を自己の“端末の公開鍵Ｂ（Kpt）”で暗号化して上記暗号化中間コード３６、暗号化セキュリティデータ３７を生成して、これらをＲＯＭ１３に格納する。これら暗号化データ３６，３７の復号は“端末の秘密鍵Ｃ（Kst）”を用いて行うことになる。
【０１２３】
尚、図７において、前準備処理、出荷前設定処理、及びStep１１，１２の処理は実施例１（図２）と同じであり、特に説明しない。
一方、図７に示すStep１４’，１５’、１６’の処理は、図２のStep１４，１５、１６の処理と一部異なる。すなわち、まず、Step１４’はＰＯＳ端末５からの決済指示に応じて決済処理、インタプリタ処理を行う点は図２のStep１４と同じであるが、その前に、ＰＯＳ端末５からの決済指示が来た際に、端末管理ＣＰＵ１１がＬＳＩ２０に上記ＲＯＭに格納されている上記暗号化中間コード３６、暗号化セキュリティデータ３７を渡して、ＬＳＩ２０においてこれらを“端末の秘密鍵Ｃ（Kst）”で復号して揮発性メモリ２３上に展開する処理を行う。そして、ＬＳＩ２０は、揮発性メモリ２３上に展開した中間コード３１等を用いて、電子マネー決済処理を行うことになる。
【０１２４】
また、ＬＳＩ２０は、決済処理完了したら、揮発性メモリ２３上に展開した中間コード３１等を削除する。
尚、複数種類の電子マネーに対応する場合には、端末管理ＣＰＵ１１は、上記ＰＯＳ端末５からの決済指示によって指定された電子マネー種類に応じた上記暗号化中間コード３６等を、ＲＯＭ１３から取得してＬＳＩ２０に渡すことになる。
【０１２５】
Step１５’の処理も、上記Step１４’の場合と略同様に、締め指示を受けたら、端末管理ＣＰＵ１１が上記ＲＯＭ１３に格納されている暗号化中間コード３６、暗号化セキュリティデータ３７をＬＳＩ２０に配信して、ＬＳＩ２０においてこれらを復号して揮発性メモリ２３上に展開する処理を行う（中間コード３１、セキュリティデータ３２を得て揮発性メモリ２３に格納する処理）。
【０１２６】
そして、ＬＳＩ２０内でStep１５と同様にこれら中間コード３１等を用いて締め処理等を行う。そして、ＬＳＩ２０は、締め処理完了したら、揮発性メモリ２３上に展開した中間コード３１等を削除する。
【０１２７】
また、Step１６’の処理では、端末管理ＣＰＵ１１は、撤去指示に応じて、ＲＯＭ１３に記憶されている暗号化データ（暗号化中間コード３６、暗号化セキュリティデータ３７）を削除する。
【０１２８】
尚、上記Step１４’の処理例では、決済処理毎に逐一、ＲＯＭ１３から暗号化中間コード３６等を取得して復号して中間コード３１等を揮発性メモリ２３に展開してその後に消去するものとしたが、この例に限らず、例えば起動時に暗号化中間コード３６等を復号して中間コード３１等を揮発性メモリ２３に展開した後は、消去せずに運用し、運用終了（電源ＯＦＦ）により消去されるようにしてもよい。但し、上述してある通り、複数の電子マネーアプリケーションを扱う場合には、上記Step１４’の処理例の処理を行うことで、揮発性メモリ２３のメモリ容量が少なくて済むという効果が得られる。
【０１２９】
次に、以下、実施例４について説明する。
上記実施例１〜３では、決済端末１０−センタ装置２間の暗号化通信に公開鍵暗号方式を用いる場合について説明したが、実施例４のように共通鍵暗号方式を採用しても良い。
【０１３０】
この場合、予め、電子マネー事業者側と端末メーカ側の両方で、同じ暗号鍵（端末−センタ共通鍵Ｈ（Kc_tc））を共有しておく必要がある。あるいは、電子マネー事業者側、端末メーカ側それぞれが独自に共通鍵暗号方式による暗号鍵を生成し、それぞれが自己が生成した暗号鍵を予め相手に渡しておくようにしてもよい。前者の場合、決済端末１０、センタ装置２はそれぞれ、同一の暗号鍵を用いるが、暗号化の手順が異なる方法で暗号化を行うようにしてもよい（勿論、両者とも、この２種類の暗号化手順を知っており、その暗号化／復号化プログラムを格納している）。一方、後者の場合、後述する暗号化データ５１の生成とその復号の為の暗号鍵と、暗号化データ５２の生成とその復号の為の暗号鍵とは異なることになる。
【０１３１】
但し、以下の説明では、上記のことを逐一説明することなく、単純に、電子マネー事業者側と端末メーカ側の両方で共有する同一の暗号鍵である“端末−センタ共通鍵Ｈ（Kc_tc）”によって、暗号化／復号化が行われるものとして説明する。
【０１３２】
まず、上記“端末−センタ共通鍵Ｈ（Kc_tc）”は、上記出荷設定作業の際、出荷する各決済端末１０に、上記“端末共有鍵Ａ（Kct）”や端末情報、センタ情報等と共に格納される。また、実施例４でも上記実施例１と同様に上記前準備処理を行っており、これによって得た上記“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５も、出荷設定作業の際に決済端末１０に格納される。尚、これら各種設定情報は、図８に示す通り、不揮発性メモリ２４に格納される。
【０１３３】
図８は、実施例４における決済処理セキュリティ情報配信システムの構成例を示す図である。
尚、図８のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。実施例１との違いは、センタ装置２−決済端末１０間の暗号化通信を、公開鍵ペアではなく、上記“端末−センタ共通鍵Ｈ（Kc_tc）”を用いて行う点である。つまり、公開鍵暗号方式ではなく共通鍵暗号方式で暗号化通信を行う点である。
【０１３４】
よって、本システムで用いる各種鍵は、図８の図上左下に示す通り、“端末の共有鍵Ａ（Kct）”、“端末−センタ共通鍵Ｈ（Kc_tc）”、“センタ秘匿鍵Ｄ（Kcc）”、“セッション鍵Ｇ（Ks）”の４種類である。そして、これにより、図示の通り、各メモリに格納される鍵が一部、図１とは異なることになる。
【０１３５】
まず、センタ装置２においては、その不揮発メモリ３には、上記センタの公開鍵ペア（“センタ公開鍵Ｅ（Kpc）”と“センタ秘密鍵Ｆ（Ksc）”）の代わりに、“端末−センタ共通鍵Ｈ（Kc_tc）”が記憶される。他の鍵や暗号化データは図１と同じである。また、実施例１では図２のStep11において公開鍵の交換を行ったが、本例では必要ないので、揮発メモリ４に“端末の公開鍵Ｂ（Kpt）”が記憶されることはない。
【０１３６】
また、決済端末１０においては、その不揮発性メモリ２４には、上記端末の公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）の代わりに、“端末−センタ共通鍵Ｈ（Kc_tc）”が記憶される。他の鍵や暗号化データは図１と同じである。また、実施例１では図２のStep11において公開鍵の交換を行ったが、本例では必要ないので、揮発メモリ２３に“センタ公開鍵Ｅ（Kpc）”が記憶されることはない。
【０１３７】
実施例４においても、その全体的な処理シーケンスは、図２と略同様であり、ここでは特に説明しない。但し、上記の通り、Step11において公開鍵の交換を行わない点は異なるし、Step12の詳細な処理内容は異なる。すなわち、本例では、Step12の詳細な処理は、図３ではなく、図９の処理を行うことになる。
【０１３８】
図９は、実施例４におけるStep12の処理を詳細に説明する為のフロー図である。
図９において、図３と同一のデータや処理には、同一符号を付してある。
すなわち、決済端末１０において上記送信データ４１を生成する点、この送信データ４１の暗号化データを受信したセンタ装置２が、これを復号して得た上記復号データ４３を用いてステップＳ２１、Ｓ２２の判定処理を行う点は、実施例１の図３の処理と同じであり、ここでは特に説明しない。また、センタ装置２において認証成功後に上記応答データ４４を生成する点、この応答データ４４の暗号化データを受信した決済端末１０が、これを復号して得た上記復号データ４６を用いてステップＳ２３，２４の判定処理を行う点も、実施例１の図３の処理と同じであり、ここでは特に説明しない。
【０１３９】
上記の通り、図９において、図３と異なる点は、上記送信データ４１、応答データ４４の暗号化、復号化の処理であり、以下、これについて説明する。
尚、上記の通り、上記送信データ４１、応答データ４４自体は、図３と同じであるが、一応説明しておくならば、送信データ４１は、決済端末１０内で任意に生成した乱数Rtと、端末情報ハッシュ値と、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５とから成る。また、応答データ４４は、センタ装置２が内部で任意に生成する乱数Rcと、センタ情報ハッシュ値と、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５とから成る。
【０１４０】
まず、決済端末１０は、上記送信データ４１を生成したら、出荷設定時に上記不揮発性メモリ２４に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”でこの送信データ４１を暗号化することで、図示の暗号化データ５１を生成して送信する。この暗号化データ５１を受信したセンタ装置２は、上記不揮発メモリ３に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”と“センタ秘匿鍵Ｄ（Kcc）”を用いてこの暗号化データ５１を復号することで上記復号データ４３を得る。そして、上述したようにステップＳ２１、Ｓ２２の判定処理を行い、端末認証成功したならば、処理を続行して、上記復号データ４３における乱数Rtを記憶すると共に以下の処理を行う。
【０１４１】
すなわち、センタ装置２は、上記応答データ４４を生成したら、上記不揮発メモリ３に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”でこの応答データ４４を暗号化することで、図示の暗号化データ５２を生成して送信する。この暗号化データ５２を受信した決済端末１０は、上記不揮発性メモリ２４に記憶されている上記“端末−センタ共通鍵Ｈ（Kc_tc）”と“端末の共有鍵Ａ（Kct）”とを用いて、この暗号化データ５２を復号することで上記復号データ４６を得る。そして、上述したようにステップＳ２３、Ｓ２４の判定処理を行い、センタ認証成功したならば、上記復号データ４６における乱数Rcを記憶する。そして、この乱数Rcと上記乱数Rtとに基づいて“セッション鍵Ｇ（Ks）”を生成し、Step13の処理を行うことになる。上記の通り、Step13以降の処理は図２と略同様であり、ここでは特に説明しない。
【０１４２】
上述したように、決済端末１０−センタ装置２間の相互認証処理の際の暗号化通信は、公開鍵暗号方式に限らず、共通鍵暗号方式を用いてもよい。
（実施例５）（複数の電子マネーアプリケーションを扱う場合）
図１０は、実施例５における決済処理セキュリティ情報配信システムの構成例を示す図である。すなわち、複数種類の電子マネーアプリケーションを扱うことが可能なシステム構成例を示す。
【０１４３】
尚、図１０のシステムは、ハードウェア構成自体は図１に示すシステムと同じであってよく、同一符号を付してあり、説明は省略する。以下、主に実施例１とは異なる点について説明する。尚、図示の端末メーカサーバ１’は、基本的には図１の端末メーカサーバ１と略同様の処理機能を有するが、以下に説明するように複数の電子マネー事業者それぞれに対する前準備処理を行う点等が異なることから異なる符合（１ではなく１’を付してある）。
【０１４４】
尚、図では１つの電子マネー事業者のセンタ装置２のみを示すが、複数の電子マネー事業者の各センタ装置２が存在し得る。そして、図１０の端末メーカサーバ１’は、これら各センタ装置２との間で、予め上記実施例１等と同様に前準備処理を実行して、各センタ装置２から“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５やセンタ情報を取得しておく。当然、センタ秘匿鍵Ｄ（Kcc）は各センタ装置２毎に異なるものであるので、暗号化端末情報２５は（センタ情報も）各センタ装置２毎に異なるものであり、よってサーバ１は、取得した暗号化端末情報２５やセンタ情報を、各電子マネー事業者毎に対応付けてサーバ１内に格納しておき、その後のオンライン設定等に用いる。
【０１４５】
また、サーバ１’は、上記端末共有鍵Ａ（Kct）を、各電子マネー事業者毎に対応付けてそれぞれ生成して格納する。よって、端末共有鍵Ａ（Kct）は、１つではなく複数存在し、各電子マネー事業者毎に異なるものであるから、ここでは図示のように“アプリ固有秘匿鍵６２”と記すものとする。そして、上記前準備処理の際にセンタ装置２へ送信する上記“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５も、通信相手の電子マネー事業者に対応したアプリ固有秘匿鍵６２を用いて暗号化するものである。尚、その意味では、“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５は“アプリ固有秘匿鍵６２で暗号化されたセンタ情報”３５と言うこともできるが、ここでは“端末共有鍵Ａ（Kct）で暗号化されたセンタ情報”３５と記すものとする。
【０１４６】
端末メーカ側において出荷設定の際には、出荷する各決済端末１０毎に上記実施例１と同様の設定を行う。但し、設定対象の決済端末１０が複数種類の電子マネーアプリケーションを扱うものである場合には、その決済端末１０で扱う電子マネー種類それぞれに対応する上記“アプリ固有秘匿鍵Ａ”と“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、センタ情報等を、ＬＳＩ２０内の不揮発性メモリ２４に格納する。
【０１４７】
勿論、実施例１と同様に、設定対象の決済端末１０においてその内部で上記任意の上記公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる処理や、UI表示、プログラム追加・変更・削除、利用履歴（明細）記録等の非セキュリティ部分の電子マネー事業者のアプリケーションを、ＲＯＭ１３に格納する処理も行う。尚、この非セキュリティアプリケーションは、図１０においては“非決済プログラム”６３として示している。上記公開鍵ペアは、各電子マネー事業者毎に異なるものでないので、図示の通り１対の公開鍵ペアのみが記憶される。一方、上記“非決済プログラム”は、各電子マネー事業者毎に異なるものであり、図示の通り、各電子マネー種類それぞれについての“非決済プログラム”６３が格納される。
【０１４８】
出荷されて任意の店舗に設置後の決済端末１０は、上記実施例１の場合と同様に、上記公開鍵ペアや端末情報、“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等を用いて、センタ装置２から中間コード３１、セキュリティデータ３２を取得することになる。複数種類の電子マネーに対応する場合には、各電子マネー事業者のセンタ装置２からそれぞれ中間コード３１、セキュリティデータ３２を取得することになる。その際、通信相手の電子マネー事業者に対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５を用いることになる。中間コード３１等の取得の為の処理自体（相互認証処理やセッション鍵による暗号化中間コード３３等の配信、その復号処理等）は、実施例１と略同様であり、ここでは説明しない。
【０１４９】
取得した中間コード３１、セキュリティデータ３２は、図示の通り、各電子マネー事業者毎に対応付けて不揮発性メモリ２４に格納管理する。
その後は、例えばstep14の処理では、任意のＩＣカード６と決済処理を行う毎に、このＩＣカードの種類（電子マネーの種類）に対応する中間コード３１等を用いて、電子マネー決済処理を行うことになる。
【０１５０】
尚、後述する実施例６と同様に、上記取得・格納した中間コード３１、セキュリティデータ３２の格納アドレスを、後述するメモリ管理テーブル７０において、サービスコードに対応付けて記憶・管理するようにしてもよい。そして、上記任意のＩＣカード６との決済処理の際には、ＰＯＳレジ５等の上位端末からの決済指示で決済対象の電子マネー種類に応じた上記サービスコードが指定されるので、メモリ管理テーブル７０を参照することで、決済対象の電子マネー種類に応じた中間コード３１、セキュリティデータ３２の格納位置が分かるので、これらを用いて決済処理を行うことになる。
【０１５１】
以上説明したように、実施例５では、実施例１等のシステムの特徴を備えつつ複数種類の電子マネーアプリケーションを扱うことが可能なシステムを提供できる。
ここで、例えば、各決済端末１０の出荷先の各店舗毎に、その店舗の考えによりその店舗で扱う電子マネーの種類や数が決められているものであり、端末メーカ側では出荷先の要求に応じて各決済端末１０の設定を行うことになる。例えばある店舗ｘでは電子マネーａのみ、別の店舗ｙでは電子マネーｂのみ、更に別の店舗ｚでは電子マネーａとｃを扱うものとする。この場合、端末メーカ側では、出荷設定の際に、店舗ｘ向けの決済端末１０に対しては電子マネーａに対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等の設定情報を設定することになる。同様に、店舗ｙ向けの決済端末１０に対しては電子マネーｂに対応する上記設定情報（“アプリ固有秘匿鍵”６２等）を設定することになり、店舗ｚ向けの決済端末１０に対しては電子マネーａとｃそれぞれに対応する上記設定情報（“アプリ固有秘匿鍵”６２等）を設定することになる。
【０１５２】
しかしながら、出荷後に、店舗側の事情等により、その店舗で扱う電子マネーの種類を増やしたい（あるいは変更したい）場合がある。
また、上述したことから、上記実施例５では、出荷設定の際に、作業員は、各決済端末１０毎に、その決済端末１０で扱う電子マネー種類に対応する“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等を選択して設定することになり、手間が掛かることになる。
【０１５３】
以下に説明する実施例６は、この様な問題に対応するものである。
実施例６は、実施例５と同様に複数種類の電子マネーアプリケーションを扱うことが可能なシステムを前提とする。よって、システム構成自体は、図１０と同じであってよく、以下の説明では図１０を参照して説明する。
【０１５４】
そして、図１１に、実施例６の通信シーケンスを示し、これを用いて説明する。
図１１に示すように、実施例６では、まず出荷設定の際には、決済端末１０に対して暗号鍵の設定（公開鍵ペア（“端末の公開鍵Ｂ（Kpt）”及び“端末の秘密鍵Ｃ（Kst）”）を生成させて不揮発性メモリ２４に記憶させる処理）とその決済端末１０の端末情報の設定のみを行う（図２のＳ６とＳ８の処理のみ行う）。これらの情報は、各電子マネー事業者毎に対応するものではなく、共通して利用されるものであるからである。
【０１５５】
よって、このときには“アプリ固有秘匿鍵”６２、“暗号化された端末情報”２５等の設定（図２のＳ７，Ｓ９の処理）は行わない。よって、実施例１等とは異なり、必ずしも出荷設定前に前準備処理を行わなければならないわけではない。但し、後述するメンテナンス情報アップロードのときまでには、前準備処理を行っている必要はある。前準備処理自体は、図２に示すものと同じであってよく（上記Ｓ１〜Ｓ５の処理を行う）、ここでは説明しない。但し、実施例５と同様、各電子マネー事業者それぞれのセンタ装置２と前準備処理を行って、各電子マネー種類毎に対応する“暗号化された端末情報”２５を取得することになる。また、これによって、各電子マネー事業者のセンタ装置２には、それぞれ、その電子マネー事業者に応じた“アプリ固有秘匿鍵”６２によって暗号化された“暗号化されたセンタ情報”３５が記憶されることになる。
【０１５６】
ここで、予め、各電子マネー種類毎に所定のサービスコードが決められているものとする。
そして、例えば、上記出荷設定作業において、出荷する各決済端末１０に関して、その決済端末１０で扱う電子マネー種類のサービスコードを、当該決済端末１０の端末識別ＩＤ等に対応付けてサーバ１の不図示の決済端末管理テーブルに登録しておく。この登録内容は、後に、例えば店舗側からの要求に応じて更新される場合がある。例えば、上記店舗ｚを例にすると、この店舗ｚに出荷される決済端末１０に関しては、最初は電子マネーａとｃのサービスコードが登録されるが、後に店舗ｚ側の要求により例えば電子マネーｂのサービスコードが追加登録されるものとする。この例では、この決済端末１０は、最初は２種類の電子マネーａとｃに対応するものであるが、後に３種類の電子マネーａ，ｂ，ｃに対応するものとなる。但し、実際にこれら各種電子マネーの決済処理を実行可能となる為には、後述するメンテナンス情報アップロード時の処理やstep13による中間データ３１等の取得処理を行う必要がある。
【０１５７】
尚、上記出荷設定作業の際、決済端末１０の不揮発性メモリ２４には、図１０に示すプログラム３０’も格納される。上記実施例１のプログラム３０はインタプリタ処理、アプリ格納処理等を行うプログラムであるが、このプログラム３０’は図１０に示すように更にサービス管理処理を実行するプログラムも含まれる。
【０１５８】
上記出荷設定作業を経て出荷されて任意の店舗に設置された決済端末１０は、例えば定期的に（本例ではメンテナンス情報アップロードで）、上記サービス管理処理プログラムを実行する。メンテナンス情報アップロードは、例えば、その決済端末１０の現在の状態を示す情報（例えば、現況、どの電子マネーに対応しているのか等）を、サーバ１に通知するものである。
【０１５９】
この処理では、まず、ネットワーク７を介して端末メーカサーバ１に接続して、所定の認証処理を行い（Ｓ１１）、認証成功した場合にはＳ１２以降の処理を行う。尚、認証処理自体は既存の認証手法による処理であってよく、ここでは特に説明しない。
【０１６０】
上記Ｓ１１の接続・認証処理の際、決済端末１０は、自己のメモリ（例えば不揮発性メモリ２４）に格納されているメモリ管理テーブル７０に登録されているサービスコード全てを、自己の端末識別ＩＤと共に端末メーカサーバ１に送信する。サーバ１は、上記不図示の決済端末管理テーブルを参照して、このテーブルに登録されているサービスコードと受信したサービスコードとを比較チェックして、アプリ追加が必要か不要かを判定する。例えば、上記店舗ｚを例にすると、例えば店舗ｚの決済端末１０が電子マネーａとｃのサービスコードを通知してきた場合、決済端末管理テーブルに電子マネーａとｃのサービスコードのみが登録されている場合にはアプリ追加不要と判定し、電子マネーａ，ｂ，ｃのサービスコードが登録されている場合には電子マネーｂのアプリ追加必要と判定する。
【０１６１】
また、出荷されて設置後に初めてサーバ１にアクセスしてきた決済端末１０については、当然、未だ中間コード３１等は何も記憶されていないので、メモリ管理テーブル７０には何も登録されていない状態であるので（後述する説明参照）、“サービスコード無し”をサーバ１に通知する。これより、サーバ１は、この決済端末１０について決済端末管理テーブルに登録されている全てのサービスコードのアプリ追加が必要と判定することになる。
【０１６２】
アプリ追加不要と判定した場合には、その旨を決済端末１０に返信する。
一方、アプリ追加必要と判定した場合には、以下に説明するＳ１２以降の処理を実行する。
【０１６３】
尚、上記メモリ管理テーブル７０に関しては、その一例を図１２に示し、後に説明する。
以下、Ｓ１２以降の処理について説明する。
【０１６４】
まず、サーバ１は、上記Ｓ１１の処理によりアプリ追加必要と判定した電子マネー種類（上記の例では電子マネーｂ）に係わるプログラム情報（この電子マネーの上記サービスコードや、そのプログラム、鍵等に関するサイズ情報等；具体例は後に図１２で説明する）と共にアプリ追加指示を決済端末１０に通知する（Ｓ１２）。
【０１６５】
尚、アプリ追加必要と判定した電子マネー種類が複数ある場合には、そのうちの任意の１つについてＳ１２以降の処理を行い、Ｓ１４の配信処理を実行するものとなり実行した場合には、その後に、他の電子マネー種類について同様にＳ１２以降の処理を行う。
【０１６６】
上記Ｓ１２の通知を受信した決済端末１０の端末管理ＣＰＵ１１は、まず、ＲＯＭ１３の空き容量の確認を行い、上記プログラム情報に含まれる非決済プログラム６３のサイズ情報に基づいて、当該非決済プログラム６３をＲＯＭ１３に格納可能か否か（「非決済プログラムのサイズ＜空き容量」か否か）を判定する。格納不能な場合にはその旨をサーバ１に通知する。
【０１６７】
一方、格納可能であれば、上記受信したプログラム情報（但し、非決済プログラムのサイズ情報は除く）をＬＳＩ２０に渡して、プログラム追加可能かを問い合わせる指示を出す。
【０１６８】
ＬＳＩ２０は、この指示に応じて、上記追加対象の電子マネー種類のプログラム、鍵等を不揮発性メモリ２４に格納可能か否かを、メモリ２４の全体サイズと現在の使用量と追加アプリのプログラム情報に基づいて判定して、判定結果を端末管理ＣＰＵ１１に返信する。
【０１６９】
これは、例えば、まず上記メモリ管理テーブル７０等に基づいて、不揮発性メモリ２４に現在格納されている各種データの総データサイズは分かるので、不揮発性メモリ２４の現在の空き容量は分かる（空き容量＝不揮発性メモリ２４の容量（全体サイズ）−総データサイズ）。一方、上記渡されたプログラム情報に基づいて、上記新たに追加すべき電子マネー種類に係わるプログラム、鍵等の総データサイズは分かるので、このプログラム等を不揮発性メモリ２４に格納可能か否かを判定できる。つまり、総データサイズ＜空き容量であれば格納可能と判定する。これより、判定結果を端末管理ＣＰＵ１１に通知する。
【０１７０】
また、もし格納可能と判定した場合には、上記メモリ管理テーブル７０に新規レコードを生成し、上記端末管理ＣＰＵ１１から渡されたプログラム情報（サービスコード、各サイズ（データ長））を新規レコードに格納する。
【０１７１】
ここで、図１２を参照してメモリ管理テーブル７０の一例について説明する。
図１２は、メモリ管理テーブル７０のデータ構成例である。
図示のメモリ管理テーブル７０は、サービスコード７１、端末共有鍵格納アドレス７２、そのデータ長７３、暗号化端末情報格納アドレス７４、そのデータ長７５、中間コード格納アドレス７６、そのデータ長７７、セキュリティデータ格納アドレス７８、そのデータ長７９の各データ項目より成る。
【０１７２】
つまり、メモリ管理テーブル７０には、不揮発性メモリ２４に格納される各種電子マネー毎の決済処理用プログラム／データ等の格納アドレスとサイズ情報が格納される。すなわち、各種電子マネー毎に、それに対応するアプリ固有秘匿鍵６２、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５、中間コード３１、セキュリティデータ３２等の格納場所やサイズがメモリ管理テーブル７０に登録されることになる。
【０１７３】
例えば、端末共有鍵格納アドレス７２、そのデータ長７３は、アプリ固有秘匿鍵６２の格納アドレスとデータサイズである。暗号化端末情報格納アドレス７４、そのデータ長７５は、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５の格納アドレスとデータサイズである。中間コード格納アドレス７６、そのデータ長７７は、中間コード３１の格納アドレスとデータサイズである。セキュリティデータ格納アドレス７８、そのデータ長７９は、セキュリティデータ３２の格納アドレスとデータサイズである。
【０１７４】
上記端末管理ＣＰＵ１１から渡されるプログラム情報の具体例は、特に図示しないが、サービスコード、アプリ固有秘匿鍵６２のサイズ、“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５のサイズ、中間コード３１のサイズ、セキュリティデータ３２のサイズであり、上記新規レコードへの格納処理の際には、これらがサービスコード７１、データ長７３、データ長７５、データ長７７、データ長７９にそれぞれ格納されることになる。各格納アドレス７２，７４，７６，７８はこの時点では未だ格納されない。
【０１７５】
また、上記メモリ２４に格納可能か否かの判定は、受信したプログラム情報における上記各データ長７３、７５，７７，７９の総和が、上記メモリ２４の空き容量未満であるか否かを判定することになる。
【０１７６】
端末管理ＣＰＵ１１は、上記ＬＳＩ２０から上記判定結果を受け取ると、これをサーバ１へ転送する（Ｓ１３の応答）。
サーバ１は、この応答を受信すると、判定結果が格納不可である場合には、本処理を終了する。一方、格納可能である場合には、追加すべき電子マネーに係わる、サービスコード、非決済部分のアプリケーション（非決済プログラム６３）、電子マネー事業者センタ接続情報（その電子マネー事業者のセンタ装置２のＩＰアドレス等）、センタ情報、アプリ固有秘匿鍵６２、及び“センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報”２５を、決済端末１０にダウンロードする（Ｓ１４）。
【０１７７】
決済端末１０の端末管理ＣＰＵ１１は、これらダウンロード情報をＬＳＩ２０へ渡し、復号化等の処理を実行させ、復号化されて得られた各種情報のうち、サービスコードと非決済プログラム６３と電子マネー事業者センタ接続情報を受け取って、これらをＲＯＭ１３に記憶する。
【０１７８】
一方、ＬＳＩ２０は、上記復号化により得られた各種情報のうち、アプリ固有秘匿鍵６２）、及び“暗号化された端末情報”２５を、不揮発性メモリ２４に格納し、これらの格納アドレスをメモリ管理テーブル７０の端末共有鍵格納アドレス７２と暗号化端末情報格納アドレス７４にそれぞれ格納する。尚、その際、不揮発性メモリ２４における中間コード３１とセキュリティデータ３２の格納領域も確保しておき、これらの格納アドレスもメモリ管理テーブル７０の中間コード格納アドレス７６とセキュリティデータ格納アドレス７８にそれぞれ格納する。これにより、メモリ管理テーブル７０へのデータ登録は完了する。但し、この処理は、中間コード３１とセキュリティデータ３２を実際に取得・格納するまでは行わないようにしてもよい。
【０１７９】
その後は、決済端末１０は、上記の通り取得した各種設定情報を用いて、実施例１等の場合と同様にして、上記電子マネー事業者センタ接続情報を用いて電子マネー事業者のセンタ装置２へアクセスし、中間コード３１とセキュリティデータ３２を取得して、既に確保してある領域に中間コード３１とセキュリティデータ３２を記憶する。これにより、当該新たな電子マネーに係わる決済処理機能が活性化されることになる。
【０１８０】
その後の決済処理、締め処理、撤去処理は、実施例１の図２で説明したstep14,15,16の処理と略同様であってよいが、本例ではこれらの処理の際に、端末管理ＣＰＵ１１からは処理対象の電子マネーアプリのサービスコードを含んだコマンド指示（決済・締めなど）がＬＳＩ２０に送信され、ＬＳＩ２０はメモリ管理テーブル７０を参照することで上記指示されたサービスコードに対応する中間コード３１、セキュリティデータ３２の格納アドレスを読取り、読取ったアドレスに格納されている中間コード３１等を用いることで、指示された電子マネーに係わる決済処理等を実行することになる。
【０１８１】
以上説明したように、本システムによれば、電子マネー事業者は、電子マネーアプリケーションのセキュリティ処理に係わる情報（中間コード３１、セキュリティデータ３２等）を、端末メーカ側に公開することなく、これらの情報は出荷後にネットワークを介して決済端末１０にセキュアにダウンロードすることで電子マネー決済処理を実行可能な状態にすることができる。また、サービスコードによるメモリ管理を行うことで、複数の電子マネーアプリの管理ができ、一台で複数の電子マネーアプリケーションを実行可能となる。
【０１８２】
最後に、図１３に、上記センタ装置２やサーバ１のコンピュータのハードウェア構成の一例を示しておく。
図１３に示すコンピュータ１００は、ＣＰＵ１０１、メモリ１０２、入力部１０３、出力部１０４、記憶部１０５、記録媒体駆動部１０６、及びネットワーク接続部１０７を有し、これらがバス１０８に接続された構成となっている。
【０１８３】
ＣＰＵ１０１は、当該コンピュータ１００全体を制御する中央処理装置である。
メモリ１０２は、任意の処理実行の際に、記憶部１０５（あるいは可搬型記録媒体１０９）に記憶されているプログラムあるいはデータを一時的に格納するＲＡＭ等のメモリである。ＣＰＵ１０１は、メモリ１０２に読み出したプログラム／データを用いて、各種処理を実行する。
【０１８４】
出力部１０４は、例えばディスプレイ等であり、入力部１０３は、例えば、キーボード、マウス等である。
ネットワーク接続部１０７は、例えば上記ネットワーク７に接続して、他の情報処理装置との通信（コマンド／データ送受信等）を行う為の構成である。
【０１８５】
記憶部１０５は、例えばハードディスク等であり、上述した各種処理をＣＰＵ１０１により実現させる為のアプリケーションプログラムが格納されている。すなわち、当該コンピュータ１００がセンタ装置２である場合には、上記前準備処理や、各決済端末１０への中間コード３１等のダウンロード処理等を、ＣＰＵ１０１により実行させる為のアプリケーションプログラムが格納されている。また、当該コンピュータ１００がサーバ１である場合には、上記前準備処理や、出荷設定処理（Ｓ６〜Ｓ９）や、図１１に示すダウンロード処理（Ｓ１１〜Ｓ１４）等を、ＣＰＵ１０１により実行させる為のアプリケーションプログラムが格納されている。
【０１８６】
尚、当該コンピュータ１００がセンタ装置２である場合、記憶部１０５は上記不揮発メモリ３に相当すると考えても良い（メモリ１０２は揮発性メモリ４に相当すると考えてよい）。
【０１８７】
ＣＰＵ１０１は、上記記憶部１０５に格納されている各種プログラムを読み出し・実行することにより、上述した各種処理を実現する。
あるいは、上記記憶部１０５に格納される各種プログラム／データは、可搬型記録媒体１０９に記憶されているものであってもよい。この場合、可搬型記録媒体１０９に記憶されているプログラム／データは、記録媒体駆動部１０６によって読み出される。可搬型記録媒体１０９とは、例えば、ＦＤ（フレキシブル・ディスク）１０９ａ、ＣＤ−ＲＯＭ１０９ｂ、その他、ＤＶＤ、光磁気ディスク等である。
【０１８８】
あるいは、また、上記プログラム／データは、ネットワーク接続部１０７により接続しているネットワークを介して、他の装置内に記憶されているものをダウンロードするものであってもよい。あるいは、更に、インターネットを介して、外部の他の装置内に記憶されているものをダウンロードするものであってもよい。
【０１８９】
また、本発明は、上記本発明の各種処理をコンピュータ上で実現するプログラムを記録した可搬型記憶媒体として構成できるだけでなく、当該プログラム自体として構成することもできる。
【符号の説明】
【０１９０】
１ 端末メーカサーバ
２ 電子マネー事業者センタ装置
３ 不揮発メモリ
４ 揮発性メモリ
５ ＰＯＳレジ
６ ＩＣカード
７ ネットワーク
１０ 決済端末
１１ 端末管理ＣＰＵ
１２ ＲＡＭ
１３ ＲＯＭ
１４ ＵＩ
１５ 第１通信部
１６ 第２通信部
１７ 第３通信部
２０ ＬＳＩ
２１ ＣＰＵ
２２ 第４通信部
２３ 揮発性メモリ
２４ 不揮発性メモリ
２５ センタ秘匿鍵Ｄ（Kcc）で暗号化された端末情報
２６ 第５通信部
３１ 中間コード
３２ セキュリティデータ
３３ 暗号化中間コード
３４ 暗号化セキュリティデータ
３５ 端末共有鍵Ａ（Kct）で暗号化されたセンタ情報
３６ 端末の公開鍵Ｂ（Kpt）で暗号化された中間コード
３７ 端末の公開鍵Ｂ（Kpt）で暗号化されたセキュリティデータ
４１ 送信データ
４２ 暗号化データ
４３ 復号データ
４４ 応答データ
４５ 暗号化データ
４６ 復号データ
５１ 暗号化データ
５２ 暗号化データ
６２ アプリ固有秘匿鍵
６３ 非決済プログラム
７０ メモリ管理テーブル
７１ サービスコード
７２ 端末共有鍵格納アドレス
７３ データ長
７４ 暗号化端末情報格納アドレス
７５ データ長
７６ 中間コード格納アドレス
７７ データ長
７８ セキュリティデータ格納アドレス
７９ データ長
１００ コンピュータ
１０１ ＣＰＵ
１０２ メモリ
１０３ 入力部
１０４ 出力部
１０５ 記憶部
１０６ 記録媒体駆動部
１０７ ネットワーク接続部
１０８ バス
【特許請求の範囲】
【請求項１】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける決済処理セキュリティ情報配信方法であって、
予め、前記センタ装置と前記サーバ装置とが前記ネットワークを介して相互に通信処理を行うことで、前記センタ装置は、自己に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持する前準備処理ステップと、
前記サーバ装置が、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記前準備処理ステップの際に取得した前記特定情報とを設定・格納する設定処理ステップと、
前記各決済端末が出荷されて任意の設置場所に設置された後、
前記センタ装置と前記決済端末とが前記ネットワークを介して暗号化通信により相互認証処理を行う処理であって、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と前記前備処理ステップの際に取得した前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理ステップと、
前記相互認証が成功した場合、前記センタ装置が前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、前記相互認証処理ステップで得られる暗号鍵によって暗号化して配信する配信ステップと、
前記決済端末が、該暗号化された配信情報を前記相互認証処理ステップで得られる前記暗号鍵によって復号することで前記決済処理セキュリティ情報を取得する決済処理セキュリティ情報取得ステップと、
を有することを特徴とする決済処理セキュリティ情報配信方法。
【請求項２】
前記相互認証処理ステップにおいて、
前記センタ装置は、受信した暗号化端末情報を前記第２の秘匿鍵によって復号化でき、且つ該復号化により得た端末情報が前記前準備処理ステップの際に登録されている端末情報と一致する場合には、通信相手の決済端末を認証成功とし、
前記決済端末は、受信した暗号化特定情報を前記第１の秘匿鍵により復号化でき、且つ復号化により得た特定情報が前記設定処理ステップで設定された特定情報と一致する場合には、通信相手のセンタ装置を認証成功とすることを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項３】
前記相互認証処理ステップにおいて、
前記決済端末は、更に、前記端末情報のハッシュ値を生成し、該端末情報ハッシュ値を前記第１の送信情報に含めて前記センタ装置へ送信し、
前記センタ装置は、前記端末情報一致に加えて更に、前記復号化により得た端末情報のハッシュ値を生成し該ハッシュ値が受信した前記端末情報ハッシュ値と一致する場合に、通信相手の決済端末を認証成功と判定し、
前記センタ装置は、更に、前記特定情報のハッシュ値を生成し、該特定情報ハッシュ値を前記第２の送信情報に含めて前記決済端末へ送信し、
前記決済端末は、前記特定情報一致に加えて更に、前記復号化により得た特定情報のハッシュ値を生成し該ハッシュ値が受信した前記特定情報ハッシュ値と一致する場合に、通信相手のセンタ装置を認証成功と判定することを特徴とする請求項２記載の決済処理セキュリティ情報配信方法。
【請求項４】
前記前準備処理ステップにおいて、
前記センタ装置は前記特定情報を前記サーバ装置へ送信し、該サーバ装置が該特定情報を記憶すると共に該特定情報を自装置が保持する前記第１の秘匿鍵で暗号化して前記暗号化特定情報を生成して該暗号化特定情報を前記センタ装置に返信し、該センタ装置が該暗号化特定情報を記憶し、
前記サーバ装置は、出荷対象の決済端末がある毎に、その前記端末情報を前記センタ装置に送信し、該センタ装置は該端末情報を記憶すると共に該端末情報を自装置のみが保持する前記第２の秘匿鍵で暗号化して前記暗号化端末情報を生成して該暗号化端末情報を前記サーバ装置に返信し、該サーバ装置が該暗号化端末情報を記憶することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項５】
前記決済端末は、耐タンパ適用されたＬＳＩと、該ＬＳＩの外部にある制御手段を有し、
前記設定処理ステップで設定・格納される前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記配信される決済処理セキュリティ情報は、前記ＬＳＩ内の記憶手段に記憶され、
前記相互認証処理ステップ、配信ステップに係わる暗号化／復号化処理は前記ＬＳＩ内で実行されることを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項６】
前記ＬＳＩ内の記憶手段は揮発性メモリと不揮発性メモリより成り、
前記配信された決済処理セキュリティ情報は、前記不揮発性メモリに格納されることを特徴とする請求項５記載の決済処理セキュリティ情報配信方法。
【請求項７】
前記ＬＳＩ内の記憶手段は揮発性メモリと不揮発性メモリより成り、
前記配信された決済処理セキュリティ情報は、前記揮発性メモリに格納されることを特徴とする請求項５記載の決済処理セキュリティ情報配信方法。
【請求項８】
前記決済端末は、耐タンパ適用されたＬＳＩと、該ＬＳＩの外部にある第２記憶手段を有し、
前記設定処理ステップで設定される前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵は、前記ＬＳＩ内の不揮発性メモリに記憶され、前記相互認証処理ステップ、配信ステップに係わる暗号化／復号化処理は前記ＬＳＩ内で実行され、
前記ＬＳＩは、前記決済処理セキュリティ情報取得ステップによって取得した前記決済処理セキュリティ情報を、自己が生成した暗号鍵を用いて暗号化して、該暗号化決済処理セキュリティ情報を前記第２記憶手段に記憶し、任意のときに該第２記憶手段から前記暗号化決済処理セキュリティ情報を取得して、これを前記暗号鍵を用いて復号して得た前記決済処理セキュリティ情報を前記ＬＳＩ内の揮発性メモリ上に一時的に記憶することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項９】
前記前準備処理ステップは、複数の前記電子マネー事業者の各センタ装置それぞれと前記決済端末メーカのサーバ装置との間で実行され、その際、該サーバ装置は、前記複数の前記電子マネー事業者の各センタ装置毎に、それぞれ異なる前記第１の秘匿鍵によって前記特定情報の暗号化を行って該暗号化特定情報をセンタ装置に返信し、各センタ装置から取得した前記暗号化端末情報、特定情報を各電子マネー事業者毎に対応付けて保持し、
前記サーバ装置は、前記設定処理ステップにおいて前記暗号化端末情報と前記第１の秘匿鍵は設定しないで、前記決済端末が出荷されて任意の設置場所に設置された後に前記ネットワークを介して、その決済端末が扱う各電子マネーに係わる前記第１の秘匿鍵と前記暗号化特定情報を当該決済端末に配信して設定させるオンライン設定処理ステップを更に有し、
決済端末は、自己が扱う各電子マネー毎にその電子マネー事業者のセンタ装置にアクセスして、前記設定処理ステップとオンライン設定処理ステップにより設定された情報に基づいて、前記相互認証処理ステップと配信ステップとによりその電子マネーの決済処理に係わる前記決済処理セキュリティ情報を取得することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項１０】
前記サーバ装置は、前記オンライン設定処理ステップにおいて前記配信を行う前に、その決済端末が扱う各電子マネーのなかで配信対象となる電子マネーを判定し、該配信対象の各電子マネー毎に、その電子マネーに係わり配信すべき全データの容量を配信先の決済端末に通知し、
前記各決済端末は、前記通知を受信すると、自己の記憶手段の空き容量と前記全データ容量とに基づいて、前記配信すべき全データを新たに格納可能か否かを判定し、格納可能な場合のみ前記サーバ装置に前記オンライン設定処理ステップによる配信を実行させることを特徴とする請求項９記載の決済処理セキュリティ情報配信方法。
【請求項１１】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムであって、
前記センタ装置と前記サーバ装置は、それぞれ、第１の前準備処理手段、第２の前準備処理手段を有し、
予め前記第１の前準備処理手段と第２の前準備処理手段とによって前記ネットワークを介して相互に所定データの送受信を行うことで、前記センタ装置の第１の前準備処理手段は、自装置に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置の第２の前準備処理手段は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持し、
前記サーバ装置は、更に、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段を備え、
前記センタ装置は、更に、第１の相互認証処理手段と、セキュリティ情報配信手段とを備え、
前記各決済端末は、第２の相互認証処理手段と、配信情報格納手段とを備え、
前記各決済端末が出荷されて任意の設置場所に設置された後、
前記第１の相互認証処理手段と第２の相互認証処理手段とによって前記ネットワークを介して暗号化通信により相互認証処理を行い、その際、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証し、
前記相互認証処理が成功した場合、前記センタ装置のセキュリティ情報配信手段は、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信し、該決済端末の前記配信情報格納手段は配信された暗号化決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納することを特徴とする決済処理セキュリティ情報配信システム。
【請求項１２】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記サーバ装置であって、
予め、前記ネットワークを介して前記センタ装置との通信を行って、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報を送信して、該センタ装置から該端末情報が当該センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報が返信されてくるとこれを保持し、前記センタ装置から該センタ装置に係わる特定情報が送られてくると、該特定情報を前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化して該暗号化特定情報をセンタ装置に返信する前準備処理手段と、
出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段と、
を有することを特徴とするサーバ装置。
【請求項１３】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記センタ装置であって、
予め、前記ネットワークを介して前記サーバ装置との通信を行って、自装置に係わる特定情報を前記サーバ装置に送信し、該サーバ装置から該特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報が返信されてくるとこれを記憶し、前記サーバ装置から各決済端末毎の所定情報である各端末情報が送信されてくると、該各端末情報を当該センタ装置のみが保持する第２の秘匿鍵によって暗号化して該暗号化端末情報を前記サーバ装置に返信する前準備処理手段と、
任意の設置場所に設置された前記決済端末から前記ネットワークを介してアクセスがあると、暗号化通信による相互認証処理を行い、その際、前記暗号化特定情報を含む第２の送信情報を決済端末へ送信し、該決済端末から前記暗号化端末情報を含む第１の送信情報が送られてくると、該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証する相互認証処理手段と、
前記相互認証処理手段によって通信相手の決済端末と相互に認証成功した場合、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信するセキュリティ情報配信手段と、
を有することを特徴とするセンタ装置。
【請求項１４】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記決済端末であって、
少なくとも自己の端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報と、前記決済端末メーカ側のみが保持する第１の秘匿鍵と、前記センタ装置に係わる特定情報を含む各種設定情報を、該サーバ装置により設定させてこれを自端末内の記憶部に格納する設定情報格納手段と、
自端末が任意の設置場所に設置された後、前記ネットワークを介して前記センタ装置にアクセスして、暗号化通信により相互認証処理を行い、その際、前記設定された暗号化端末情報を含む第１の送信情報を前記センタ装置に送信すると共に、該センタ装置から送られてくる、前記特定情報が前記第１の秘匿鍵によって暗号化されて成る暗号化特定情報を含む第２の送信情報を受信すると、該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理手段と、
前記相互認証処理手段によって前記センタ装置と相互に認証処理が成功した場合、前記センタ装置から電子マネー決済処理に係わる決済処理セキュリティ情報が前記相互認証処理で得られる暗号鍵によって暗号化されて送られてくると、該暗号化された決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納する決済処理セキュリティ情報取得・格納手段と、
を有することを特徴とする決済端末。
【請求項１５】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記サーバ装置のコンピュータを、
予め、前記ネットワークを介して前記センタ装置との通信を行って、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報を送信して、該センタ装置から該端末情報が当該センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報が返信されてくるとこれを保持し、前記センタ装置から該センタ装置に係わる特定情報が送られてると、該特定情報を前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化して該暗号化特定情報をセンタ装置に返信する前準備処理手段と、
出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段、
として機能させる為のプログラム。
【請求項１６】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記センタ装置のコンピュータを、
予め、前記ネットワークを介して前記サーバ装置との通信を行って、自装置に係わる特定情報を前記サーバ装置に送信し、該サーバ装置から該特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報が返信されてくるとこれを記憶し、前記サーバ装置から各決済端末毎の所定情報である各端末情報が送信されてくると、該各端末情報を当該センタ装置のみが保持する第２の秘匿鍵によって暗号化して該暗号化端末情報を前記サーバ装置に返信する前準備処理手段と、
任意の設置場所に設置された前記決済端末から前記ネットワークを介してアクセスがあると、暗号化通信による相互認証処理を行い、その際、前記暗号化特定情報を含む第２の送信情報を決済端末へ送信し、該決済端末から前記暗号化端末情報を含む第１の送信情報が送られてくると、該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証する相互認証処理手段と、
前記相互認証処理手段によって通信相手の決済端末と相互に認証成功した場合、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信するセキュリティ情報配信手段、
として機能させる為のプログラム。
【請求項１７】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記決済端末のコンピュータを、
少なくとも自己の端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報と、前記決済端末メーカ側のみが保持する第１の秘匿鍵と、前記センタ装置に係わる特定情報を含む各種設定情報を、該サーバ装置により設定させてこれを自端末内の記憶部に格納する設定情報格納手段と、
自端末が任意の設置場所に設置された後、前記ネットワークを介して前記センタ装置にアクセスして、暗号化通信により相互認証処理を行い、その際、前記設定された暗号化端末情報を含む第１の送信情報を前記センタ装置に送信すると共に、該センタ装置から送られてくる、前記特定情報が前記第１の秘匿鍵によって暗号化されて成る暗号化特定情報を含む第２の送信情報を受信すると、該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理手段と、
前記相互認証処理手段によって前記センタ装置と相互に認証処理が成功した場合、前記センタ装置から電子マネー決済処理に係わる決済処理セキュリティ情報が前記相互認証処理で得られる暗号鍵によって暗号化されて送られてくると、該暗号化された決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納する決済処理セキュリティ情報取得・格納手段、
として機能させる為のプログラム。
【請求項１】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける決済処理セキュリティ情報配信方法であって、
予め、前記センタ装置と前記サーバ装置とが前記ネットワークを介して相互に通信処理を行うことで、前記センタ装置は、自己に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持する前準備処理ステップと、
前記サーバ装置が、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記前準備処理ステップの際に取得した前記特定情報とを設定・格納する設定処理ステップと、
前記各決済端末が出荷されて任意の設置場所に設置された後、
前記センタ装置と前記決済端末とが前記ネットワークを介して暗号化通信により相互認証処理を行う処理であって、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と前記前備処理ステップの際に取得した前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理ステップと、
前記相互認証が成功した場合、前記センタ装置が前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、前記相互認証処理ステップで得られる暗号鍵によって暗号化して配信する配信ステップと、
前記決済端末が、該暗号化された配信情報を前記相互認証処理ステップで得られる前記暗号鍵によって復号することで前記決済処理セキュリティ情報を取得する決済処理セキュリティ情報取得ステップと、
を有することを特徴とする決済処理セキュリティ情報配信方法。
【請求項２】
前記相互認証処理ステップにおいて、
前記センタ装置は、受信した暗号化端末情報を前記第２の秘匿鍵によって復号化でき、且つ該復号化により得た端末情報が前記前準備処理ステップの際に登録されている端末情報と一致する場合には、通信相手の決済端末を認証成功とし、
前記決済端末は、受信した暗号化特定情報を前記第１の秘匿鍵により復号化でき、且つ復号化により得た特定情報が前記設定処理ステップで設定された特定情報と一致する場合には、通信相手のセンタ装置を認証成功とすることを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項３】
前記相互認証処理ステップにおいて、
前記決済端末は、更に、前記端末情報のハッシュ値を生成し、該端末情報ハッシュ値を前記第１の送信情報に含めて前記センタ装置へ送信し、
前記センタ装置は、前記端末情報一致に加えて更に、前記復号化により得た端末情報のハッシュ値を生成し該ハッシュ値が受信した前記端末情報ハッシュ値と一致する場合に、通信相手の決済端末を認証成功と判定し、
前記センタ装置は、更に、前記特定情報のハッシュ値を生成し、該特定情報ハッシュ値を前記第２の送信情報に含めて前記決済端末へ送信し、
前記決済端末は、前記特定情報一致に加えて更に、前記復号化により得た特定情報のハッシュ値を生成し該ハッシュ値が受信した前記特定情報ハッシュ値と一致する場合に、通信相手のセンタ装置を認証成功と判定することを特徴とする請求項２記載の決済処理セキュリティ情報配信方法。
【請求項４】
前記前準備処理ステップにおいて、
前記センタ装置は前記特定情報を前記サーバ装置へ送信し、該サーバ装置が該特定情報を記憶すると共に該特定情報を自装置が保持する前記第１の秘匿鍵で暗号化して前記暗号化特定情報を生成して該暗号化特定情報を前記センタ装置に返信し、該センタ装置が該暗号化特定情報を記憶し、
前記サーバ装置は、出荷対象の決済端末がある毎に、その前記端末情報を前記センタ装置に送信し、該センタ装置は該端末情報を記憶すると共に該端末情報を自装置のみが保持する前記第２の秘匿鍵で暗号化して前記暗号化端末情報を生成して該暗号化端末情報を前記サーバ装置に返信し、該サーバ装置が該暗号化端末情報を記憶することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項５】
前記決済端末は、耐タンパ適用されたＬＳＩと、該ＬＳＩの外部にある制御手段を有し、
前記設定処理ステップで設定・格納される前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵と、前記配信される決済処理セキュリティ情報は、前記ＬＳＩ内の記憶手段に記憶され、
前記相互認証処理ステップ、配信ステップに係わる暗号化／復号化処理は前記ＬＳＩ内で実行されることを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項６】
前記ＬＳＩ内の記憶手段は揮発性メモリと不揮発性メモリより成り、
前記配信された決済処理セキュリティ情報は、前記不揮発性メモリに格納されることを特徴とする請求項５記載の決済処理セキュリティ情報配信方法。
【請求項７】
前記ＬＳＩ内の記憶手段は揮発性メモリと不揮発性メモリより成り、
前記配信された決済処理セキュリティ情報は、前記揮発性メモリに格納されることを特徴とする請求項５記載の決済処理セキュリティ情報配信方法。
【請求項８】
前記決済端末は、耐タンパ適用されたＬＳＩと、該ＬＳＩの外部にある第２記憶手段を有し、
前記設定処理ステップで設定される前記端末情報及びその前記暗号化端末情報と前記第１の秘匿鍵は、前記ＬＳＩ内の不揮発性メモリに記憶され、前記相互認証処理ステップ、配信ステップに係わる暗号化／復号化処理は前記ＬＳＩ内で実行され、
前記ＬＳＩは、前記決済処理セキュリティ情報取得ステップによって取得した前記決済処理セキュリティ情報を、自己が生成した暗号鍵を用いて暗号化して、該暗号化決済処理セキュリティ情報を前記第２記憶手段に記憶し、任意のときに該第２記憶手段から前記暗号化決済処理セキュリティ情報を取得して、これを前記暗号鍵を用いて復号して得た前記決済処理セキュリティ情報を前記ＬＳＩ内の揮発性メモリ上に一時的に記憶することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項９】
前記前準備処理ステップは、複数の前記電子マネー事業者の各センタ装置それぞれと前記決済端末メーカのサーバ装置との間で実行され、その際、該サーバ装置は、前記複数の前記電子マネー事業者の各センタ装置毎に、それぞれ異なる前記第１の秘匿鍵によって前記特定情報の暗号化を行って該暗号化特定情報をセンタ装置に返信し、各センタ装置から取得した前記暗号化端末情報、特定情報を各電子マネー事業者毎に対応付けて保持し、
前記サーバ装置は、前記設定処理ステップにおいて前記暗号化端末情報と前記第１の秘匿鍵は設定しないで、前記決済端末が出荷されて任意の設置場所に設置された後に前記ネットワークを介して、その決済端末が扱う各電子マネーに係わる前記第１の秘匿鍵と前記暗号化特定情報を当該決済端末に配信して設定させるオンライン設定処理ステップを更に有し、
決済端末は、自己が扱う各電子マネー毎にその電子マネー事業者のセンタ装置にアクセスして、前記設定処理ステップとオンライン設定処理ステップにより設定された情報に基づいて、前記相互認証処理ステップと配信ステップとによりその電子マネーの決済処理に係わる前記決済処理セキュリティ情報を取得することを特徴とする請求項１記載の決済処理セキュリティ情報配信方法。
【請求項１０】
前記サーバ装置は、前記オンライン設定処理ステップにおいて前記配信を行う前に、その決済端末が扱う各電子マネーのなかで配信対象となる電子マネーを判定し、該配信対象の各電子マネー毎に、その電子マネーに係わり配信すべき全データの容量を配信先の決済端末に通知し、
前記各決済端末は、前記通知を受信すると、自己の記憶手段の空き容量と前記全データ容量とに基づいて、前記配信すべき全データを新たに格納可能か否かを判定し、格納可能な場合のみ前記サーバ装置に前記オンライン設定処理ステップによる配信を実行させることを特徴とする請求項９記載の決済処理セキュリティ情報配信方法。
【請求項１１】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムであって、
前記センタ装置と前記サーバ装置は、それぞれ、第１の前準備処理手段、第２の前準備処理手段を有し、
予め前記第１の前準備処理手段と第２の前準備処理手段とによって前記ネットワークを介して相互に所定データの送受信を行うことで、前記センタ装置の第１の前準備処理手段は、自装置に係わる特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報を取得して保持し、前記サーバ装置の第２の前準備処理手段は、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報を取得して保持し、
前記サーバ装置は、更に、出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段を備え、
前記センタ装置は、更に、第１の相互認証処理手段と、セキュリティ情報配信手段とを備え、
前記各決済端末は、第２の相互認証処理手段と、配信情報格納手段とを備え、
前記各決済端末が出荷されて任意の設置場所に設置された後、
前記第１の相互認証処理手段と第２の相互認証処理手段とによって前記ネットワークを介して暗号化通信により相互認証処理を行い、その際、前記決済端末が前記暗号化端末情報を含む第１の送信情報を前記センタ装置へ送信し、該センタ装置は該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証し、前記センタ装置が前記暗号化特定情報を含む第２の送信情報を前記決済端末に送信し、該決済端末は該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証し、
前記相互認証処理が成功した場合、前記センタ装置のセキュリティ情報配信手段は、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信し、該決済端末の前記配信情報格納手段は配信された暗号化決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納することを特徴とする決済処理セキュリティ情報配信システム。
【請求項１２】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記サーバ装置であって、
予め、前記ネットワークを介して前記センタ装置との通信を行って、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報を送信して、該センタ装置から該端末情報が当該センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報が返信されてくるとこれを保持し、前記センタ装置から該センタ装置に係わる特定情報が送られてくると、該特定情報を前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化して該暗号化特定情報をセンタ装置に返信する前準備処理手段と、
出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段と、
を有することを特徴とするサーバ装置。
【請求項１３】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記センタ装置であって、
予め、前記ネットワークを介して前記サーバ装置との通信を行って、自装置に係わる特定情報を前記サーバ装置に送信し、該サーバ装置から該特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報が返信されてくるとこれを記憶し、前記サーバ装置から各決済端末毎の所定情報である各端末情報が送信されてくると、該各端末情報を当該センタ装置のみが保持する第２の秘匿鍵によって暗号化して該暗号化端末情報を前記サーバ装置に返信する前準備処理手段と、
任意の設置場所に設置された前記決済端末から前記ネットワークを介してアクセスがあると、暗号化通信による相互認証処理を行い、その際、前記暗号化特定情報を含む第２の送信情報を決済端末へ送信し、該決済端末から前記暗号化端末情報を含む第１の送信情報が送られてくると、該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証する相互認証処理手段と、
前記相互認証処理手段によって通信相手の決済端末と相互に認証成功した場合、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信するセキュリティ情報配信手段と、
を有することを特徴とするセンタ装置。
【請求項１４】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記決済端末であって、
少なくとも自己の端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報と、前記決済端末メーカ側のみが保持する第１の秘匿鍵と、前記センタ装置に係わる特定情報を含む各種設定情報を、該サーバ装置により設定させてこれを自端末内の記憶部に格納する設定情報格納手段と、
自端末が任意の設置場所に設置された後、前記ネットワークを介して前記センタ装置にアクセスして、暗号化通信により相互認証処理を行い、その際、前記設定された暗号化端末情報を含む第１の送信情報を前記センタ装置に送信すると共に、該センタ装置から送られてくる、前記特定情報が前記第１の秘匿鍵によって暗号化されて成る暗号化特定情報を含む第２の送信情報を受信すると、該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理手段と、
前記相互認証処理手段によって前記センタ装置と相互に認証処理が成功した場合、前記センタ装置から電子マネー決済処理に係わる決済処理セキュリティ情報が前記相互認証処理で得られる暗号鍵によって暗号化されて送られてくると、該暗号化された決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納する決済処理セキュリティ情報取得・格納手段と、
を有することを特徴とする決済端末。
【請求項１５】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記サーバ装置のコンピュータを、
予め、前記ネットワークを介して前記センタ装置との通信を行って、出荷する各決済端末毎に、その決済端末に係わる所定情報である端末情報を送信して、該センタ装置から該端末情報が当該センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報が返信されてくるとこれを保持し、前記センタ装置から該センタ装置に係わる特定情報が送られてると、該特定情報を前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化して該暗号化特定情報をセンタ装置に返信する前準備処理手段と、
出荷する各決済端末毎に、その決済端末の前記端末情報及びその前記暗号化端末情報と、前記第１の秘匿鍵と前記特定情報を設定する設定処理手段、
として機能させる為のプログラム。
【請求項１６】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記センタ装置のコンピュータを、
予め、前記ネットワークを介して前記サーバ装置との通信を行って、自装置に係わる特定情報を前記サーバ装置に送信し、該サーバ装置から該特定情報が前記決済端末メーカ側のみが保持する第１の秘匿鍵によって暗号化されて成る暗号化特定情報が返信されてくるとこれを記憶し、前記サーバ装置から各決済端末毎の所定情報である各端末情報が送信されてくると、該各端末情報を当該センタ装置のみが保持する第２の秘匿鍵によって暗号化して該暗号化端末情報を前記サーバ装置に返信する前準備処理手段と、
任意の設置場所に設置された前記決済端末から前記ネットワークを介してアクセスがあると、暗号化通信による相互認証処理を行い、その際、前記暗号化特定情報を含む第２の送信情報を決済端末へ送信し、該決済端末から前記暗号化端末情報を含む第１の送信情報が送られてくると、該第１の送信情報と前記第２の秘匿鍵と予め登録されている前記端末情報に基づいて通信相手の決済端末を認証する相互認証処理手段と、
前記相互認証処理手段によって通信相手の決済端末と相互に認証成功した場合、前記決済端末に対して、電子マネー決済処理に係わる決済処理セキュリティ情報を、該相互認証処理で得られる暗号鍵によって暗号化して配信するセキュリティ情報配信手段、
として機能させる為のプログラム。
【請求項１７】
電子マネー事業者のセンタ装置と、決済端末メーカのサーバ装置と、各決済端末とが、ネットワークに接続されて相互にデータ送受信可能なネットワークシステムにおける前記決済端末のコンピュータを、
少なくとも自己の端末情報が前記センタ装置のみが保持する第２の秘匿鍵によって暗号化されて成る暗号化端末情報と、前記決済端末メーカ側のみが保持する第１の秘匿鍵と、前記センタ装置に係わる特定情報を含む各種設定情報を、該サーバ装置により設定させてこれを自端末内の記憶部に格納する設定情報格納手段と、
自端末が任意の設置場所に設置された後、前記ネットワークを介して前記センタ装置にアクセスして、暗号化通信により相互認証処理を行い、その際、前記設定された暗号化端末情報を含む第１の送信情報を前記センタ装置に送信すると共に、該センタ装置から送られてくる、前記特定情報が前記第１の秘匿鍵によって暗号化されて成る暗号化特定情報を含む第２の送信情報を受信すると、該第２の送信情報と前記第１の秘匿鍵と前記特定情報に基づいて前記センタ装置を認証する相互認証処理手段と、
前記相互認証処理手段によって前記センタ装置と相互に認証処理が成功した場合、前記センタ装置から電子マネー決済処理に係わる決済処理セキュリティ情報が前記相互認証処理で得られる暗号鍵によって暗号化されて送られてくると、該暗号化された決済処理セキュリティ情報を前記相互認証処理で得られる暗号鍵によって復号して格納する決済処理セキュリティ情報取得・格納手段、
として機能させる為のプログラム。
【図２】
【図５】
【図７】
【図１１】
【図１２】
【図１３】
【図１】
【図３】
【図４】
【図６】
【図８】
【図９】
【図１０】
【図５】
【図７】
【図１１】
【図１２】
【図１３】
【図１】
【図３】
【図４】
【図６】
【図８】
【図９】
【図１０】
【公開番号】特開２０１０−２１２８０５（Ｐ２０１０−２１２８０５Ａ）
【公開日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願番号】特願２００９−５４１８０（Ｐ２００９−５４１８０）
【出願日】平成２１年３月６日（２００９．３．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（０００２３７７１０）富士電機リテイルシステムズ株式会社 (1,851)
【Ｆターム（参考）】
【公開日】平成２２年９月２４日（２０１０．９．２４）
【国際特許分類】
【出願日】平成２１年３月６日（２００９．３．６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＥＰＲＯＭ
【出願人】（０００２３７７１０）富士電機リテイルシステムズ株式会社 (1,851)
【Ｆターム（参考）】
[ Back to top ]