JP5304193B2 - Ｉｃカード決済端末、その制御装置、プログラム - Google Patents

Description

本発明は、電子マネーを用いるキャッシュレス決済システムに係わり、特に複数種類のＩＣカードに対応可能なＩＣカード決済端末に関する。

非接触ＩＣカードや非接触ＩＣカード機能内蔵の携帯電話等（以下、ＩＣカードというものとする）を用いた、電子マネーを使用するキャッシュレス決済システムでは、ＩＣカードへの入金処理や、利用額の差引き処理を始めとするＩＣカードへのアクセス処理を、ＩＣカード・リーダ／ライタ（Ｒ／Ｗ）を有するＩＣカード決済端末が、ＰＯＳレジなどの上位端末からの指示に従って行っている。

ここで、現在では複数種類のＩＣカードが存在する。すなわち、電子マネーは、各社から異なる仕様の電子マネーブランドが規定され、それぞれ電子マネー用のＩＣカードが発行され、また携帯端末用ソフトウェアがリリースされている。すなわち、複数のＩＣカード発行・決済会社がそれぞれ自社ブランドのＩＣカードを発行・管理している。そして、昨今、１台の決済端末で複数のブランドの（複数種類の）電子マネーを利用できるマルチブランド決済端末に対するニーズが高まっている。

この様な複数種類のＩＣカードに対応可能なＩＣカード決済端末では、自端末で扱う各ブランド毎の処理機能が必要である。これは、例えば、ＩＣカードとの通信は秘匿通信（暗号化通信）であるので、その為の鍵情報等が必要であるが、複数ブランドに対応する場合、各ブランド毎の鍵情報等を保持する必要がある。

ＩＣカード決済端末の主な処理機能は、利用客が保持するＩＣカードから利用額を差し引いたり、あるいは金額を積みましたりすることや、決済処理結果等を示す明細情報等（取引情報）を生成・記録し、この明細情報等を各電子マネーブランド会社（ＩＣカード発行・決済会社）におけるセンタサーバへ送信すること等である。

上記の通り、ＩＣカードとの通信はセキュリティ性を高めるために暗号化されており、暗号化／復号化の為の鍵等の秘匿情報を端末が保持する必要があるが、この秘匿情報は電子マネーブランド毎に異なる。またＩＣカードの仕様も各ブランド毎に異なるため、ＩＣカードのリードライト方法も異なる。上記取引情報を各社のセンタサーバに送信する場合においても、接続先（各社のセンタサーバのＩＰアドレス等）が異なることは勿論のこと、その通信仕様も異なる。そこで従来は、その決済端末で扱う全ての電子マネーブランドに関わる処理を、ひとつのプログラム上で実現することで、１台の決済端末で複数のブランドの電子マネーを取り扱っていた。

また、例えば特許文献１に開示の従来技術が知られている。
特許文献１の発明は、複数種類の電子マネーに対する決済処理を迅速に行えるようにするものである。特許文献１には、対応可能とする電子マネーのそれぞれの決済処理を行う複数の決済部１０３Ａ〜１０３Ｃを具備すると共に、対応可能とする全ての電子マネーに関する情報の読み取りを行う選択部を具備し、選択部によりメディア検出を行った結果に応じて上記決済部１０３Ａ〜１０３Ｃを動作させることが開示されている。
特開２００８−１６０１６号公報

従来の技術では、各電子マネーブランドが規定する秘匿情報を単一のプログラムが操作することとなる。また、秘匿情報に限らず、例えば上記取引情報等、様々な情報を単一のプログラムが操作することとなる。

例えば、電子マネーブランドＡ、ＢおよびＣに対応する決済端末を例にする場合、仮にブランドＡのＩＣカードに関する処理（ＩＣカードとの通信（認証処理やデータ・リード／ライト処理等）、決済処理、ブランドＡのセンタサーバへの取引情報送信処理等）を実行するプログラムに欠陥があった場合、それを起因として、ブランドＡだけでなく他のブランドＢ，Ｃに関するサービス（そのＩＣカードに関する処理）が停止する可能性があるまた、例えば、ブランドＡの情報だけでなく他のブランドの情報も壊したしまう可能性がある。

また、電子マネーシステムにおいて、秘匿情報はシステム全体の安全性／信頼性を確保するための重要な要素であり、他ブランドと同居する形で秘匿情報を取り扱うことに抵抗を感じる電子マネーブランド会社もあり、電子マネーに関わる各機能の個別化が要求されるなど、セキュリティ上の問題がある。

また、決済端末を設置する各店舗毎に、利用可能としたい電子マネーブランドの組み合わせが異なる場合がある。例えば店舗１では電子マネーブランドＡ，Ｂを、店舗２では電子マネーブランドＡ，Ｃを、店舗３では電子マネーブランドＢ，Ｃを、利用可能としたい等といった要求がある。あるいは、複数ブランド利用に限らず、任意の１つのブランドのみ利用可能としたい店舗があることも考えられる。

上記の様な要求に対応して、単一のプログラムで１又は複数の電子マネーブランド利用を実現する場合、各電子マネーブランド毎とその組み合わせ毎のプログラムの作成が必要となる。すなわち、例えばブランドA、B、Cの３つのブランドが存在するとした場合、少なくともＡ、Ｂ、Ｃ、Ａ＋Ｂ、Ａ＋Ｃ、Ｂ＋Ｃ、Ａ＋Ｂ＋Ｃの7パターンのプログラムを作成、用意しておく必要がある。また、各パターン作成する毎に、それが正常に動作することを検証する必要がある。

電子マネーブランドは現状少なくとも３つを超えるブランドが存在する。この為、上記店舗要求に合わせて多くのパターンのプログラムを作成することは製造コスト増加、品質の悪化などの影響が問題となっている。

また、各プログラムの個別化する技術としては、各プログラムの動作するメモリ領域を仮想化し、各プログラムが利用できるメモリ空間を制限するというものがある。この方法では各アプリケーションを個別化し、各アプリケーションに相関が無く、独立させて動作させることが可能であるが、決済端末のように上位機器からの指令で各アプリケーションを選択的に動作・制御させるような場合に、各アプリケーションを総合的に制御する点で課題となっていた。

また、万が一、決済端末内に不正なプログラムが入り込んでいた場合、このプログラムが動作することで、様々な問題（例えば情報の消去、改竄、漏洩等）が起こり得る。
また、他のブランドと同居することに関して心配する声が挙がっている。すなわち、例えば、他のブランドのアプリケーションが、自社ブランドのデータを盗み見しようとする可能性について、心配する声が挙がっている。

本発明の課題は、複数ブランドに対応可能なＩＣカード決済端末において、各決済端末毎で対応するブランド又はブランドの組み合わせが異なる場合でも、登録情報を設定／変更するだけで対応可能となり、また不正プログラムが入り込んでも実質的に動作できないように制御でき、また他のブランドのデータにアクセスできないようにできるＩＣカード決済端末、その制御装置、プログラム等を提供することにある。

本発明のＩＣカード決済端末は、複数種類のＩＣカードに対応可能なＩＣカード決済端末であって、前記各種ＩＣカードそれぞれに対応して、そのＩＣカードに対応する処理を実行する各種アプリケーションモジュールを記憶するアプリケーションモジュール記憶部と、該各種アプリケーションモジュールを管理・制御すると共に、前記アプリケーションモジュールからの要求に応じて、記憶装置へのデータアクセス制御または外部装置への通信制御あるいはＩＣカードとの通信制御を実行する共通処理部とを有し、前記共通処理部は、予め前記各種アプリケーションモジュールのうちの任意の１以上のアプリケーションモジュールに関する登録情報を記憶しておく登録情報記憶手段と、初期処理として、前記アプリケーションモジュール記憶部に記憶されている各種アプリケーションモジュールのうち、その前記登録情報が前記登録情報記憶手段に登録されているアプリケーションモジュールを起動するアプリケーションモジュール管理手段と、起動したアプリケーションモジュールの管理情報を記憶する起動アプリケーション管理情報記憶手段とを有する。

上記ＩＣカード決済端末では、まず、従来のように１つのプログラム上に複数種類のブランドのアプリケーションをまとめるのではなく、各ブランド個別に独立したアプリケーションであるアプリケーションモジュールを予め生成して記憶しておく。そして、その登録情報が登録情報記憶手段に登録されているアプリケーションモジュールのみを起動する。これによって、登録情報記憶手段の登録内容を変えるだけで、各決済端末毎に容易に自由に、その決済端末で対応するブランドまたは複数ブランドの組み合わせを設定することが可能となる。

また、例えば、前記アプリケーションモジュール管理手段は、前記登録情報に基づいてパス情報を生成し、該パス情報を用いてアプリケーションモジュールを起動し、該起動成功した場合には、該起動したアプリケーションモジュールに対してコネクション確立すると共に、該起動したアプリケーションモジュールに関する前記管理情報であって前記生成したパス情報を含む管理情報を、前記起動アプリケーション管理情報記憶手段に記憶する。

これは、例えば、前記登録情報には前記アプリケーションモジュールの名称が含まれており、前記各種アプリケーションモジュールは、予め、その名称と予め決められた所定のルールとに基づいて決定される格納場所に格納されており、前記アプリケーションモジュール管理手段は、前記登録情報に含まれる名称と前記所定のルールとに基づいて、そのアプリケーションモジュールの格納場所を示す前記パス情報を生成する。

上記の通り、正当なアプリケーションモジュールであれば、その名称と予め決められた所定のルールとに基づいて決定される格納場所に格納されている。よって、もし正当なアプリケーションモジュール以外のアプリケーションが存在しても、起動されないし、コネクションも確立されない。

また、例えば、前記共通処理部は、任意の前記アプリケーションモジュールからの任意の要求に応じて、前記記憶装置へのデータアクセス制御または外部装置への通信制御あるいはＩＣカードとの通信制御を実行する際に、該要求元のアプリケーションモジュールに関する前記管理情報が前記起動アプリケーション管理情報記憶手段に記憶されているか否かをチェックし、記憶されていない場合には該要求を拒否する。

上記の通り、正当なアプリケーションモジュール以外のアプリケーションは、起動されないように制御しているが、もし万が一、このアプリケーションが動作する状態になったとしても、共通処理部を介して行う処理は、実質的に、実行できないことになる。

また、例えば、前記共通処理部は、前記アプリケーションモジュールからの要求に応じて前記記憶装置へのデータアクセス制御を行う場合、該要求に含まれるアクセス対象のデータファイルの名称と、前記起動アプリケーション管理情報記憶手段に記憶されている前記パス情報とを用いて、該データファイルにアクセスする為のファイルパスを生成し、該ファイルパスを用いて前記アクセス対象のデータファイルにアクセスする。

上記構成により、任意のアプリケーションモジュール（正当なものも含む）が、他のアプリケーションモジュールのデータファイルにアクセスしようとしても、出来ないことになる。

本発明のＩＣカード決済端末、その制御装置、プログラム等によれば、複数ブランドに対応可能なＩＣカード決済端末において、各決済端末毎で対応するブランド又はブランドの組み合わせが異なる場合でも、登録情報を設定／変更するだけで対応可能となり、また不正プログラムが入り込んでも実質的に動作できないように制御でき、また他のブランドのデータにアクセスできないようにできる。

以下、図面を参照して本発明の実施の形態について説明する。
図１（ａ）、（ｂ）に本例のＩＣカード決済端末の構成例を示す。
図１（ａ）は、本例のＩＣカード決済端末の構成例、及びこの端末を含むキャッシュレス決済システム全体の構成例を示す。

図示のＩＣカード決済端末１０は、主制御部１１、記憶装置１２、通信制御部（対主局）１３、通信制御部（対センタ）１４、通信制御部（対カード）１５を有する。
通信制御部（対主局）１３は主局（上位コントローラ）１との通信を行う機能部であり、通信制御部（対センタ）１４はセンタサーバ２等の外部装置との通信をネットワーク（インターネット等）を介して行う機能部であり、通信制御部（対カード）１５はＩＣカード３との通信を行う機能部である。これらについては特に説明しないが、主局１は例えばＰＯＳ端末等であり、センタサーバ２は上述したＩＣカード発行・決済会社のサーバ装置である。また、通信制御部（対カード）１５は、例えばアンテナと通信用回路等から成る。尚、ＩＣカード３は、ＩＣカードだけでなく、例えばＩＣカード機能搭載の携帯電話等であってもよい。

図１（ｂ）に、上記ＩＣカード決済端末１０の主制御部１１の機能構成例を示す。
主制御部１１は、フレームワーク２０と各ブランドアプリケーションＡ，Ｂ，Ｃ，・・・ｎ（これらを総称してブランドアプリケーション２５という）の各機能部を有する。

フレームワーク２０は、上記各種ブランドアプリケーション２５を管理・制御すると共に、ブランドアプリケーション２５からの要求に応じて、記憶装置１２へのデータアクセス制御、または外部装置（センターサーバ２や主局１）への通信制御、あるいはＩＣカード３との通信制御を実行する共通処理部である。

フレームワーク２０は、アプリケーション管理部２１、上位通信制御部２２、データ制御部２３、Ｒ／Ｗ通信制御部２４の各機能部を有する。また、図１に示していないが、フレームワーク２０内には、通信制御部（対センタ）１４を制御して、センタサーバ２との通信処理を実行させる処理機能部（センタ通信制御部というものとする）も存在する。

上記各種ブランドアプリケーション２５の管理・制御は、アプリケーション管理部２１が実行する。また、上記「記憶装置１２へのデータアクセス制御、または外部装置（センターサーバ２や主局１）への通信制御、あるいはＩＣカード３との通信制御」は、データ制御部２３、または上位通信制御部２２（または不図示のセンタ通信制御部）、あるいはＲ／Ｗ通信制御部２４が行う。

主制御部１１は、ＣＰＵ／ＭＰＵであり、不図示のメモリまたは記憶装置１２に予め記憶されている所定のアプリケーションプログラムを実行することにより、上記フレームワーク２０の処理機能（その各機能部２１〜２４の処理機能）、各ブランドアプリケーション２５の処理機能を実現する。これは、換言すれば、後述する図２、図６（ａ）、（ｂ）、図７に示すフローチャートの処理を主制御部１１に実行させる為のアプリケーションプログラムが、記憶装置１２等に記憶されているものとなる。また、これらの処理に必要なテーブル情報等も、記憶装置１２等に記憶されている。すなわち、後述する図３、図４に示す情報は、予め記憶装置１２等に記憶されている。また、後述する図５に示すテーブル情報も、後述する処理により生成され、不図示のメモリまたは記憶装置１２に記憶される。

上記構成の主制御部１１に関して、まず、ブランド別のアプリケーションのモジュール化が行われている。すなわち、各ブランド毎に独立したブランドアプリケーションＡ，Ｂ，Ｃ，・・・ｎが存在する。そして、各ブランドアプリケーション２５は、共通処理部であるフレームワーク２０によって管理制御され、あるいはフレームワーク２０に対して要求を出すことでフレームワーク２０を介して様々な処理（センターサーバ２との通信、ＩＣカードとの通信、記憶装置１２へのアクセス、主局１との通信等）を実行する。

すなわち、各ブランドアプリケーション２５は、例えばＩＣカードとの通信を行う場合には、Ｒ／Ｗ通信制御部２４に要求を出す。これより、Ｒ／Ｗ通信制御部２４が、通信制御部（対カード）１５を制御して、ＩＣカード３との通信処理を実行する。

ここで、Ｒ／Ｗ通信制御部２４は、要求を拒否する場合もある（不正と判定された場合等）。これは他の制御部２２，２３（あるいは上記不図示のセンタ通信制御部）に関しても同様である。

データ制御部２３は、任意のブランドアプリケーション２５からの要求に応じて、記憶装置１２に対するアクセス処理（データ・リード／ライト等）を実行する。但し、上記の通り要求を拒否する場合もある。

同様にして、上位通信制御部２２は、任意のブランドアプリケーション２５からの要求に応じて、通信制御部（対主局）１３を制御して主局（上記コントローラ）１との通信処理を実行する。不図示のセンタ通信制御部も、任意のブランドアプリケーション２５からの要求に応じて、通信制御部（対センタ）１４を制御して、センタサーバ２等の外部装置との通信処理を実行する。

また、ブランドアプリケーションＡ，Ｂ，Ｃ，・・・ｎの全てが動作するとは限らない。すなわち、アプリケーション管理部２１は、予め登録された情報（後述する図３の搭載アプリケーション情報３０等）に基づいて、登録されたブランドアプリケーションのみ起動する。

上述してあるように、従来では、例えばＡ，Ｂ，Ｃの３つのブランドが存在する場合を例にすると、Ａのみ、Ｂのみ、Ｃのみ、Ａ＋Ｂ、Ａ＋Ｃ、Ｂ＋Ｃ、Ａ＋Ｂ＋Ｃの７パターンの「１つのプログラム」を作成する必要であった。また、例えば、“Ａのみ”と“Ｂのみ”の各プログラムについては正常動作することが確認済みであっても、“Ａ＋Ｂ”のプログラムも正常動作するとは限らない。この為、“Ａ＋Ｂ”のプログラムを作成後、これを検証する必要があった。

これに対して、上記本例の構成では、まず、各ブランド毎の個別のアプリケーションである上記ブランドアプリケーションＡ，Ｂ，Ｃを端末１０内に記憶しておく。そして、搭載アプリケーション情報３０にＡのみ登録しておけば、この端末１０は上記７パターンのうちの“Ａのみ”のプログラムを搭載したものと同様のものとなる。同様に、“Ａ＋Ｂ”としたい場合には、搭載アプリケーション情報３０にＡとＢを登録すればよい。他のパターンについても同様である。更に、例えば、“Ａ＋Ｂ＋Ｃ＋Ｄ”としたい場合には、端末１０内にブランドアプリケーションＤを追加記憶したうえで、搭載アプリケーション情報３０にＡとＢとＣとＤを登録すればよい。

このように、上記本例の構成では、複数のブランド（複数種類の電子マネー；複数種類のＩＣカード）に対応可能なＩＣカード決済端末１０に関して、各端末１０毎にその端末で対応するブランド（１または複数のブランド）が異なる場合でも、各ブランド毎の個別のアプリケーションを作成しておけばよく、各ブランドの組み合わせ毎のアプリケーションは作成する必要はなくなる。例えば、上記のＡ，Ｂ，Ｃの例では、従来では７パターン作成する必要があったが、本例では３パターンだけ作成すれば済む。当然、各ブランドの組み合わせパターン毎に、そのアプリケーションの上記検証を行う必要はなくなる。

また、上記起動処理に関して、後述する実行ファイルパスを生成してこの実行ファイルパスを用いてブランドアプリケーション起動を行うので、たとえ正当なブランドアプリケーション２５以外のアプリケーション（不正なプログラム等）が入り込んでいても、この不正プログラム等が起動されないようにできる。また、万が一、この不正プログラム等が勝手に起動したとしても、後述するようにテーブル４０を用いてチェックするので、この不正プログラム等は実質的に動作不能となる（少なくともフレームワーク２０を介して行う処理、すなわちＩＣカードや記憶装置１２や外部装置に対して行う処理等は、実現できない）。

図２に、上記フレームワーク２０の起動処理のフローチャート図を示す。
この処理はアプリケーション管理部２１が実行する。
図２に示すように、フレームワーク２０が起動されると、まず、アプリケーション管理部２１が、搭載アプリケーション情報テーブル３０（図３に一例を示す；後に説明する）に格納されている情報を読み出す（ステップＳ１２）。尚、図では、まず未処理のブランドアプリケーション２５があるか否かを判定するが（ステップＳ１１）、この判定処理はステップＳ１２の後に行っても良い。ステップＳ１１の処理は、搭載アプリケーション情報テーブル３０に登録されたブランドアプリケーション２５全てについて、ステップＳ１２以降の処理を実施したか否かを判定するものである。

また、ステップＳ１２の処理は、搭載アプリケーション情報テーブル３０の各レコードのうちの１つを読み出すものである。すなわち、登録されている任意の１つのブランドアプリケーション２５に関する情報を読み出すものである。そして、１つのブランドアプリケーション２５（処理対象アプリケーション）に関する情報を読み出す毎に、ステップＳ１３以降の処理を実行する。

ここで、搭載アプリケーション情報テーブルの一例を図３に示す。
図３に示す搭載アプリケーション情報テーブル３０は、アプリケーションＮｏ．３１、アプリケーション名称３２、サービス種別３３、動作パラメータ３４等の各種情報より成る。

アプリケーションＮｏ．３１には、当該テーブル３０上での通し番号（シリアル番号）であり、特に意味はない。上記の通り、テーブル３０の各レコードは、それぞれ、１つのブランドアプリケーション２５に関する各種情報が登録されたものである。勿論、上記の通り、ブランドアプリケーションＡ〜ｎの全てが登録されているとは限らない。この登録情報は、図示の例では、アプリケーション名称３２、サービス種別３３、動作パラメータ３４である。

まず、アプリケーション名称３２は、そのブランドアプリケーション２５の名称であり、図示の例では例えばbrand_a、brand_b等が登録されている。尚、例えば、brand_aは上記ブランドアプリケーションＡの名称である。

サービス種別３３は、そのブランドアプリケーションＡのサービス種別である。尚、サービス種別は、例えば、主局１がＩＣカード決済端末１０に対して任意のアプリケーションの処理を指定する為に用いる識別情報である。動作パラメータ３４については、ここでは特に関係ないので説明しない。

上記ステップＳ１２で読み出した１レコードの情報に基づいて、まず、ステップＳ１３の処理を行う。すなわち、上記処理対象アプリケーションについて、そのアプリケーション名称３２に基づいて、予め決められている所定の生成方法で、そのブランドアプリケーション２５の実行ファイルパスを生成する。そして、この実行ファイルパスを用いて、そのブランドアプリケーション２５を起動する（ステップＳ１３）。この実行ファイルパス生成処理について、以下、図４に示す一例を用いて説明する。

まず、上記各ブランドアプリケーション２５の実行ファイルが、予め作成されて例えば図４に示す格納形式で格納されている。例えば、図４に示す“brand_a.exe”は上記ブランドアプリケーションＡの機能を実現する実行ファイルである。“brand_b.exe”は上記ブランドアプリケーションＢの実行ファイルである。他も同様である。そして、各実行ファイルは、予め、図４に示すパスに従って格納管理されている。すなわち、例えば上記“brand_a.exe”はルートパス“Ｃ：／appl／brand_a／”の元に格納されている。ここでは、applと、brand_a、brand_b等は、それぞれフォルダ名である。

つまり、この例では、共通パス“Ｃ：／appl”の下に各実行ファイルをそれぞれ格納する為のフォルダが存在しており、各フォルダの名称はそのフォルダ内に格納される実行ファイルの名称と同名（拡張子は除く）となっている（例えば、“brand_a.exe”に対して“brand_a”）。つまり、各ブランドアプリケーションに関して、それぞれ、applフォルダ下にアプリケーション名称３２と同名のフォルダがあり、かつこのフォルダの中にアプリケーション名称３２と同名（+特定の拡張子；本例では．exe）の実行ファイルがある。

この様な規定（ルール）が予め決められており（但し、上記の規定は一例であり、規定は自由に決めてよい）、この規定（ルール）に従った所定のルートパスの下、所定の実行ファイル名で各ブランドアプリケーション２５の実行ファイルが格納されている。よって、上記ステップＳ１３の処理では、この規定に応じて、上記実行ファイルパスを生成できる。実行ファイルパスは、上記ルートパス＋実行ファイル名である。

例えば、アプリケーション名称３２が“brand_a”であった場合には、ルートパス＝“Ｃ：／appl／brand_a／”、実行ファイル名＝“brand_a.exe”が生成され、これより実行ファイルパス＝“Ｃ：／appl／brand_a／brand_a.exe”が生成できる。

尚、アプリケーション名称３２は、上記の例に限らず、例えばフルパスで指定してもよいし、ファイルシステムが利用できない場合は、各ブランドアプリケーション２５が格納されている物理的なメモリの番地でもよい。また本例では、アプリケーション名称３２から格納パス名および実行ファイル名称を生成したが、パス名称、実行ファイル名称およびアプリケーション名称のように必要な情報を分けて定義してもよい。

そして、処理対象のブランドアプリケーション２５が、正当なものであるならば、その実行ファイルは、上記規定（ルール）に従って所定の格納場所に所定のファイル名で格納されているはずである。よって、上記生成した実行ファイルパスを用いれば、処理対象のブランドアプリケーション２５は起動できるはずである。一方、この規定（ルール）を知らない第三者が作成・格納したアプリケーションは、上記生成した実行ファイルパスを用いても、起動できないはずである。

これより、上記の通り、ステップＳ１３では、生成した実行ファイルパスを用いてアプリケーション起動を試みる。そして、もしアプリケーション起動できなかった場合には、実行ファイルなしと判定して（ステップＳ１４，ＮＯ）、ステップＳ１１に戻る。尚、ステップＳ１４がＮＯとなることは、上記の通り、処理対象が不正プログラムである可能性があることも意味している。

そして、搭載アプリケーション情報テーブル３０に登録されている全てのブランドアプリケーションについて処理実行した場合には（ステップＳ１１，ＮＯ）、本処理を終了する。一方、未処理の登録アプリケーションが残っている場合には、ステップＳ１２に進み、未処理の登録アプリケーションに関する処理を実行する。

一方、上記生成した実行ファイルパスによってブランドアプリケーション２５が起動できた場合には（ステップＳ１４，ＹＥＳ）、このブランドアプリケーション２５に任意の通信ポート番号を割り当てる等した後（ステップＳ１５）、この通信ポート番号を含む、当該ブランドアプリケーションに関する所定の管理情報を、アプリケーション管理情報テーブル４０に登録する（ステップＳ１６）。すなわち、上記生成したルートパス、通信ポート番号等を登録する。通信ポート番号は、任意に決定してよいが、重複しないように、ユニークな番号を割り付ける。通信ポート番号は、後にブランドアプリケーション２５とフレームワーク２０とが通信するために使用するポート番号である（ＴＣＰ／ＩＰにおけるポート番号等と同様と考えてよい）。つまり、これによって、フレームワーク２０−アプリケーション２５間のコネクションを確立できるものである。

また、従来より、端末１０上の各アプリケーション（上記ブランドアプリケーション２５だけでなく、全てのアプリケーション；よって、フレームワーク２０も含まれる）には、端末１０のＯＳ（オペレーティングシステム）が、各アプリケーション毎にユニークなＩＤ（アプリケーションＩＤ）を割り当てて、管理・制御している。

フレームワーク２０は、このＯＳの機能により、各ブランドアプリケーションのアプリケーションＩＤを知ることができる。これより、フレームワーク２０は、上記起動できたブランドアプリケーション２５のアプリケーションＩＤを、上記ルートパスや通信ポート番号等と共にテーブル４０に登録する。

アプリケーション管理情報テーブル４０には、予め上記テーブル３０に登録されており、且つ起動できた（不正プログラムである可能性が極めて低い）ブランドアプリケーション２５のみが登録されることになる。よって、後述するように、後の通常処理において、このテーブル４０を参照してチェックを行うことで、より強固なセキュリティを実現できる。

図５に、アプリケーション管理情報テーブル４０の一例を示す。
図５に示す例のアプリケーション管理情報テーブル４０は、アプリケーションNo.４１、アプリケーションＩＤ４２、サービス種別４３、フレームワーク−アプリケーション間通信ポート番号４４（以下、略して通信ポート番号４４という）、及びルートパス４５の各種情報より成る。

アプリケーションNo.４１は、上記アプリケーションNo.３１と同様、テーブル４０上での通し番号等であり、任意に割り当てるものである。サービス種別４３は、上記サービス種別３３に相当する。よって、ステップＳ１６では、処理対象ブランドアプリケーションのサービス種別３３をサービス種別４３に格納する。ルートパス４５には上記ステップＳ１３で生成した上記ルートパスを格納する。例えば上記の例では“Ｃ：／appl／brand_a／”をルートパス４５に格納する。アプリケーションＩＤ４２は、上記の通り、起動できた処理対象ブランドアプリケーション２５のアプリケーションＩＤである。通信ポート番号４４には、上記ステップＳ１５で任意に割り当てた通信ポート番号を格納する。

尚、フレームワークとアプリケーション間の通信は、イベントを用いても良いし、ポーリングを用いてもよい。また、ＯＳを利用している場合は、ＯＳが提供するメッセージ通信を利用しても良い。よって、上記通信ポート番号は一例であり、この例に限るものではない。要は、フレームワークとアプリケーション間の通信に必要な情報を生成して、アプリケーション管理情報テーブル４０に登録すればよい。換言すれば、フレームワーク２０−アプリケーション２５間のコネクション確立に必要な情報であれば何でもよい。

図６（ａ）に、各ブランドアプリケーションの通常起動処理フローを示す。
各ブランドアプリケーション２５は、フレームワーク２０による上記ステップＳ１３の処理によって起動されると、まず内部的な初期化処理を行う（ステップＳ２１）。この初期処理の内容については特に説明しない。そして、フレームワーク２０に対して通信ポート番号要求を出し、そのブラントアプリケーション２５に割り付けられた上記通信ポート番号を取得する（ステップＳ２２）。この後は、特にフレームワーク２０が当該ブランドアプリケーション２５との通信（後述する指示メッセージ回送等）を行う際には、上記通信ポート番号を用いる。

そして、データ受信待ち状態へ移行する（ステップＳ２３）。すなわち、フレームワーク２０は、上記図２の起動処理終了後は、例えば、後に図７で説明するように、上位端末（主局１）から任意の動作指示メッセージを受ける毎に、この指示に対応するブランドアプリケーション２５に、この指示メッセージを転送（回送）する。ステップＳ２３の処理は、例えば、当該回送されてくる指示メッセージの受信待ち状態へ移行することを意味するが、この例に限るものではない。尚、この受信待ち状態では、ステップＳ２２で取得した通信ポート番号を監視している。

上記ステップＳ２２による上記通信ポート番号要求を受信したときのフレームワーク２０の処理例を、図６（ｂ）に示す。尚、この処理は、アプリケーション管理部２１が実行する。尚、この処理は、図２の処理が完了後に実行可能となる。

まず、フレームワーク２０は、特に説明しないがＯＳの機能によって、当該ＯＳが管理する各アプリケーション（フレームワーク自体も含む）の上記アプリケーションＩＤを知ることができ、よって、要求元のブランドアプリケーション２５のＩＤを認識できる（ステップＳ３１）。これより、この要求元のブランドアプリケーション２５が、アプリケーション管理情報テーブル４０に登録されているか否かをチェックする。すなわち、アプリケーション管理情報テーブル４０を検索して、要求元のブランドアプリケーション２５のアプリケーションＩＤが登録されているか否か（アプリケーションＩＤ４２に一致するものがあるか否か）をチェックする（ステップＳ３２）。

もし、登録されているならば（ステップＳ３２，ＹＥＳ）、要求元のブランドアプリケーション２５に対して、そのブランドアプリケーション２５に割り当てた上記通信ポート番号４４を応答する（ステップＳ３３）。これより、要求元のブランドアプリケーション２５は、上記ステップＳ２２の処理における通信ポート番号の取得が行える。

一方、未登録の場合には（ステップＳ３２，ＮＯ）、要求元のアプリケーションは不正なアプリケーションである可能性があると判定し、異常応答を行う（ステップＳ３４）。この場合、要求元のブランドアプリケーション２５は、上記ステップＳ２２の処理において通信ポート番号は取得できない。

上記起動時の図２、図６の処理完了後は、ＩＣカード決済端末１０は通常処理モードに移行する。その後は、通常処理、例えばＩＣカード決済処理やセンタサーバ２への決済明細データ送信処理等を実行する。

図７に、この通常処理のフローチャート図を示す。
上位端末（主局１）は、ＩＣカード決済端末１０に対して、任意のサービス種別の処理実行を指示する。上位端末（主局１）は、上記の通りＰＯＳレジ等であり、例えば顧客が、当該ＩＣカード決済端末１０で取り扱う各種ＩＣカードのうちの任意の種類のＩＣカードを使用する場合、店員等が上位端末を操作してこのＩＣカードの決済処理実行を指示すると、上位端末はこの指示に応じたサービス種別をコマンドに含めてＩＣカード決済端末１０へ送信する（ステップＳ４１）。

ＩＣカード決済端末１０のフレームワーク２０のアプリケーション管理部２１は、このコマンド（動作指示メッセージ）を受信すると（ステップＳ５１）、このコマンド内のサービス種別を確認し（ステップＳ５２）、図５のアプリケーション管理情報テーブル４０を検索して、該当するアプリケーションが存在するか否かをチェックする（ステップＳ５３）。すなわち、コマンドのサービス種別と同一のサービス種別４３が登録されているか否かをチェックする。

該当アプリケーションがテーブル４０に登録されていない場合には（ステップＳ５３，ＮＯ）、ステップＳ５６に進み、動作結果メッセージを上位端末に返信するが、この場合は処理実行不能応答等となる。

一方、該当アプリケーションが存在する場合には（ステップＳ５３，ＹＥＳ）、この該当アプリケーションのレコードの通信ポート番号４４を取得する。そして、この通信ポート番号４４が示す通信ポートに対して、上記コマンドを回送（送信）する（ステップＳ５４）。

尚、ここで、例えば、ブランドアプリケーション２５として不正なアプリケーションが格納され、更にこの不正なアプリケーションに関する情報が搭載アプリケーション情報テーブル３０に登録された場合を考える。この場合でも、この不正なアプリケーションに係わる第３者が、上述した所定の「規定」を知らなければ、ステップＳ１４の判定がＮＯとなる。すなわち、上記不正なアプリケーションの格納場所（フォルダ名等）や実行ファイル名を上記「規定」に従ったものにしない限り、生成した実行ファイルパスによって不正プログラムを起動させることは出来ない。よって、この不正プログラムは図５のアプリケーション管理情報テーブル４０に登録されないし、通信ポート番号が割り当てられることもない。

これより、不正プログラムが不正な処理を実行することを防止できる。また、この不正プログラムがフレームワーク２０からの起動処理や指示を受けることなく勝手に起動して動作しようとしても、後述する図８の処理により、実質的に動作不能となる。詳しくは後述する。

上記ステップＳ３３の処理が実行されて自己に割り当てられた通信ポート番号を取得できた各ブランドアプリケーション２５は、上記ステップＳ２３で移行したデータ受信待ち状態において、上記通信ポート番号の通信ポートを監視し、フレームワーク２０からのコマンド回送を待つ。

そして、各ブランドアプリケーション２５は、コマンドの回送が合った場合には（動作指示メッセージを受信した場合）（ステップＳ６１）、受信したコマンドの内容を解析して、このコマンド内容により指示された処理動作を行う（ステップＳ６２）。そして、処理動作実行完了したら、動作結果をフレームワーク２０（そのアプリケーション管理部２１）へ返信する（ステップＳ６３）。この場合、フレームワーク２０は、この返信（動作結果）を受信すると（ステップＳ５５）、この動作結果情報を上位端末１へ返信する（ステップＳ５６）。上位端末１は、この動作結果情報を受信して、所定の処理を実行する（ステップＳ４２）。

ここで、上記ステップＳ６２の処理動作の一例として、任意のブランドのＩＣカード決済処理が指示された場合について説明する。
この場合、上記ステップＳ６２の処理動作を実行するブランドアプリケーション２５は、まず、フレームワーク２０のＲ／Ｗ通信制御部２４を呼び出して、ＩＣカードとの通信処理制御を実行させる。すなわち、Ｒ／Ｗ通信制御部２４は、上記ブランドアプリケーションからの要求に応じて、通信制御部（対カード）１５を制御して、ＩＣカードとの通信を行わせて、ＩＣカードに対して金額を積み増したりまた差し引いたりする決済処理を行う。

その際、ＩＣカード３との秘匿通信に必要な鍵情報等を、記憶装置１２（その一部としての耐タンパメモリ）から取得する為に、データ制御部２３を呼び出して、記憶装置１２からの鍵情報等の読出しを要求する。

また、上記ブランドアプリケーション２５は、上記決済処理が正常終了したら、フレームワーク２０のデータ制御部２３を呼び出して、この決済処理の明細情報（取引情報）を、例えば記憶装置１２に格納する処理制御を実行させる。すなわち、データ制御部２３は、上記ブランドアプリケーション２５からの要求に応じて、上記取引情報を記憶装置１２に格納する処理を実行する。

ここで、上記Ｒ／Ｗ通信制御部２４、データ制御部２３は、何れも、上記アプリケーション２５からの要求を拒否する場合がある。これは、これら制御部２３、２４に限らず、フレームワーク２０内の全ての処理機能部においても、同様であってよい。すなわち、上位通信制御部２２やアプリケーション管理部２１（あるいは、上記センタ通信制御部）においても、任意のアプリケーション２５から呼び出されて任意の要求を受けた場合に、この要求を拒否する場合がある。

すなわち、上記Ｒ／Ｗ通信制御部２４、データ制御部２３等は、何れも、上記呼び出しを行ったブランドアプリケーション２５が、正当なアプリケーション以外のアプリケーション（不正なアプリケーション等）であるか否かを確認し、不正なアプリケーションであると判定した場合には、その要求を拒否し、要求された処理動作は実行しない。

上記不正プログラムか否かのチェック処理は、テーブル４０を参照して行う。すなわち、呼び出し元のブランドアプリケーションが、テーブル４０に登録されているか否かをチェックし、登録されていない場合には要求を拒否する。このチェックは、例えば上記アプリケーションＩＤを用いて行う。すなわち、上記呼び出しを受けた処理機能部（Ｒ／Ｗ通信制御部２４やデータ制御部２３等）は、上記図６（ｂ）の場合と同様、呼び出し元のアプリケーションのアプリケーションＩＤが分かるので、このアプリケーションＩＤを用いて図８の処理を実行する。図８の不正チェック処理を実行したうえで、問題無いことを確認したら、要求に応じた処理を実行する。

図８の不正チェック処理では、上記呼び出し元のブランドアプリケーションのアプリケーションＩＤに基づいて、このアプリケーションＩＤが図５のアプリケーション管理情報テーブル４０に登録されているか否かをチェックする（ステップＳ７１）。すなわち、呼び出し元のブランドアプリケーションのアプリケーションＩＤと一致するアプリケーションＩＤ４２が、存在するか否かをチェックする。

そして、登録されていない場合には（ステップＳ７２，ＮＯ）、不正なアプリケーションの可能性ありとして、アクセス（要求）を拒否する（ステップＳ７４）。
一方、登録されていれば（ステップＳ７２，ＹＥＳ）、このアプリケーション２５からの要求に応じた処理を実行する（ステップＳ７３）。例えば、Ｒ／Ｗ通信制御部２４の場合、ＩＣカード３との通信を許可し、実行する。例えば、データ制御部２３の場合、記憶装置１２に対するアクセスを許可し、データ・リードライト処理等を実行する。

ここで、記憶装置１２に対するアクセス処理に関しては、更に、各ブランドアプリケーション２５が、他のブランドアプリケーション２５のデータにアクセスできないように制御できる。

この制御処理については、特に図示しないが、例えば以下のように処理する。
まず、本例の決済端末上のファイル構成が例えば図４に示す例の場合、各ブランドアプリケーション毎に、そのアプリケーションのデータファイルは全て、そのアプリケーションの実行ファイル（.exe）と同じ場所(同じフォルダ又はこのフォルダ以下のフォルダ)に格納されている。例えば、ブランドアプリケーションＡを例にすると、そのデータファイルは全て、図４に示すフォルダ“brand_ａ”に格納されている。あるいはこの“brand_ａ”以下の不図示の任意のフォルダ（例えば、brand_ａ／brand_ａ１等とする）に格納されている。但し、ここでは全データがフォルダ“brand_ａ”に格納されているものとする。

上記の通り、フォルダ“brand_ａ”には、実行ファイル“brand_ａ.exe”も格納されている。つまり、換言すれば、各ブランドアプリケーション２５のデータは、そのブランドアプリケーションの起動の為に生成した上記実行ファイルパスと同様のパス情報によりアクセス可能となるような格納位置に格納されている。

そして、本説明では一例として、ブランドアプリケーションＡのデータファイルとして、ファイル名が“filename”のデータファイルがフォルダ“brand_ａ”に格納されているものする。

本例では、各ブランドアプリケーション２５は、任意のデータファイルにアクセスする際、データ制御部２３を呼び出してそのファイル名のみを通知する（パス情報は無し）。よって、上記の例では、ブランドアプリケーションＡは、データ制御部２３に対して、アクセス対象のデータファイルのファイル名“filename”を通知する。

データ制御部２３は、上記の通り、呼び出し元のブランドアプリケーション２５のアプリケーションＩＤ（本例では“a1”となる）を用いて、上記の通り不正チェックを行うが、不正がないと判定して記憶装置１２へのアクセスを行う際に、データファイルのパス情報の生成を行う。

すなわち、呼び出し元のブランドアプリケーション２５のアプリケーションＩＤを用いて、図５のアプリケーション管理情報テーブル４０を検索して、該当するレコードのルートパス４５を取得する。これより、上記ブランドアプリケーションＡの例では、ルートパス“Ｃ：／appl／brand_a／”が取得される。そして、取得したルートパスと通知されたファイル名とを用いてパス変換を実施する。すなわち、上記“Ｃ：／appl／brand_a／”と“filename”とを合わせて、実際にアクセスするファイルは“C:/appl/brand_a/filename”としてパス変換を実施する（実行ファイルパスを生成することと同様）。

データ制御部２３は、上記生成した実行ファイルパスを用いて、記憶装置１２に対するファイルアクセス処理を実行する。従って、各ブランドアプリケーション２５は、自ブランドのファイルだけしかアクセスできない。例えば、ブランドアプリケーションＢに関して、同名のファイル（ファイル名“filename”のファイル）が存在したとしても、ブランドアプリケーションＢからの“filename”へのアクセス要求に対して、データ制御部２３は今度は実行ファイルパス“C:/appl/brand_b/filename”を生成することになるので、フォルダ“brand_a”内の“filename”にアクセスされることはない。

また、任意の正当なアプリケーション（仮にブランドアプリケーションＢとする）が、不正アクセスを試みても、アクセス出来ない。すなわち、予めブランドアプリケーションＢのブランド会社側で、何らかの方法で図４に示すファイル構成を取得して、これに基づいてブランドアプリケーションＢ内に例えばブランドアプリケーションＡのファイルにアクセスする処理を含めたとする。すなわち、上記のようにファイル名だけ指定するのではなく、パス情報も含めて、“C:/appl/brand_a/filename”と指定するようにプログラムしたものとする。

この場合でも、データ制御部２３は、この“C:/appl/brand_a/filename”をファイル名として扱って上記処理を行うので、実行ファイルパス＝“C:/appl/brand_b/filename/ C:/appl/brand_a/filename”というような意味不明の情報が生成されるだけである。よって、ブランドアプリケーションＢがブランドアプリケーションＡのファイルにアクセスすることはできない。

上記のように、本例の決済端末１０では、各ブランドアプリケーション２５が、そのアプリケーションの実行ファイルの格納フォルダ以下のファイルだけしかアクセスできないように、制限をかけることが出来る。すなわち、各ブランドアプリケーションが、他のブランドアプリケーションのファイルにアクセス出来ないように、制限を掛けることができる。

尚、本例では各ブランドアプリケーションからのR/W通信機能の利用、データ処理機能の利用について記述したが、もちろんその他の物理的に接続されているデバイス（LCDやLCDの表示装置、各種記憶装置、スイッチなどの入力装置）やソフトウェアで作成され、フレームワークで提供される各機能を同様にアクセス制限をかけることができる。

ここで、上記ブランドアプリケーションのモジュール化について、図９（ａ）、（ｂ）を参照して説明する。
図９（ａ）は従来の主制御部の機能ブロック図である。上記の通り、従来では、その決済端末で扱う全ての電子マネーブランドに関わる処理を、ひとつのプログラム上で実現していた。ここでは、仮に、ブランドＡとブランドＢを扱う決済端末を例にする。

この例では、ひとつのプログラム上に、ブランドＡとブランドＢのアプリケーションが存在することになる。但し、図示の通り、ブランドＡとブランドＢの両方とも、そのアプリケーションが機能別に分離されており、且つ各機能毎に両ブランドがまとまっている。

すなわち、各ブランドのアプリケーションの機能は、例えば図示のように、コマンド処理部（データ制御含む）１１０、センタ通信部１２０、ＩＣカードＲ／Ｗ部１３０の各機能毎のモジュールに分けられている。そして、図示の通り、各機能部１１０，１２０，１３０毎に、ブランドＡとブランドＢの両方のアプリケーションが存在している。尚、「ひとつのプログラム」の機能としては更に主局通信処理部１００があるが、これはブランド毎ではなく、共通の機能となる。

主局通信処理部１００は、通信制御部（対主局）１３を制御して主局１（上位端末）との通信を行って、例えば主局１（上位端末）から任意のコマンド(指示)を受けると、これをコマンド処理部１１０に渡す。

コマンド処理部１１０は、例えば上記上位端末からの指示を受けると、この指示を解釈して、この指示に応じた処理を実行する。例えば、ＩＣカード決済処理を実行し、決済結果（取引情報）を記憶装置１２に格納する為の処理を実行する。但し、その際、ＩＣカード決済処理の為のＩＣカードとの通信処理は、ＩＣカードＲ／Ｗ部１３０に依頼して実行させる。これは、例えばブランドＡのＩＣカード決済処理を指示された場合には、コマンド処理部１１０、ＩＣカードＲ／Ｗ部１３０それぞれにおいてブランドＡのアプリケーションが実行されることになる。

尚、例えば図示のコマンド処理部１１０内の「ブランドＡ」１１１は、ブランドＡに関するコマンド処理部の処理を実行するアプリケーションを意味する。他も同様である。
上記従来の構成では、例えばコマンド処理部１１０を例にすると、これは「ブランドＡ」１１１と「ブランドＢ」１１２とを有している。つまり、このコマンド処理部１１０のアプリケーションは“「ブランドＡ」１１１＋「ブランドＢ」１１２”となっている。

ここで、例えば仮に過去には「ブランドＡ」１１１のみのアプリケーションと、「ブランドＢ」１１２のみのアプリケーションとだけがあったが、後からブランドＡとＢの両方に対応可能としたい為に、“「ブランドＡ」１１１＋「ブランドＢ」１１２”を作成したとした場合、「ブランドＡ」１１１のみのアプリケーション、「ブランドＢ」１１２のみのアプリケーションそれぞれの動作については、過去に検証を行って問題ないことを確認していたとしても、“「ブランドＡ」１１１＋「ブランドＢ」１１２”のアプリケーションも問題なく動作するとは限らなかった。

この為、従来では“「ブランドＡ」１１１＋「ブランドＢ」１１２”のアプリケーションを作成後、それが問題なく動作することを検証する作業が必要であった。この様に、従来では、逐一各パターン毎（上記の例では７パターン）のアプリケーションを作成する手間が掛かるだけでなく、それが問題なく動作することを確認する為の手間が掛かっていた。

一方、本例の上記ブランドアプリケーション２５（ここでは一例として、ブランドアプリケーションＡ，Ｂ）は、図９（ｂ）に示すように、上記の各種機能が各ブランド別にモジュール化されたものとなっている。

例えば、ブランドアプリケーションＡは、図９（ａ）に示すブランドＡに関する各種機能部のアプリケーションがまとめられている（モジュール化されている）。すなわち、ブランドアプリケーションＡは、図９（ａ）に示すブランドＡ１１１、ブランドＡ１２１、ブランドＡ１３１を全て有する。同様に、ブランドアプリケーションＢは、図９（ａ）に示すブランドＢ１１２、ブランドＢ１２２、ブランドＢ１３２を全て有する。

つまり、本構成では、ＩＣカード決済処理、決済データ（取引明細等）記憶処理、センタへのデータ送信処理等の、電子マネーを用いるキャッシュレス決済に係わる各種処理を行うアプリケーションが、各ブランド別（電子マネー種別別；ＩＣカードの種類別）に個別に独立したモジュール化されたアプリケーションとなっている。よって、上記各ブランドアプリケーション２５を「各ブランド別（電子マネー種別別；ＩＣカードの種類別）の独立したアプリケーションモジュール」または「各種ＩＣカードそれぞれに対応するアプリケーションモジュール」等と呼ぶものとする。

ここで、従来ではブランドＡ，Ｂ，Ｃに対応する７つのパターンが必要である旨説明したが、ここでは簡単の為、ブランドＡ，Ｂに対応する場合を例にすると、この場合は、“Ａのみ”、“Ｂのみ”、“Ａ＋Ｂ”の３つのパターンが考えられる。この場合、図９（ａ）に示す例は、“Ａ＋Ｂ”に対応する「１つのプログラム」に相当することになるが、他の２つのパターンについても各々「１つのプログラム」を作成する必要がある。すなわち、各機能部１１０，１２０，１３０それぞれがブランドＡ１１１、ブランドＡ１２１、ブランドＡ１３１のみを有する「１つのプログラム」と、各機能部１１０，１２０，１３０それぞれがブランドＢ１１２、ブランドＢ１２２、ブランドＢ１３２のみを有する「１つのプログラム」とを作成する必要がある。

一方、図９（ｂ）に示す本例の場合には、図示の各ブランドアプリケーションＡ，Ｂを予め用意しておけば、後は各店舗毎（各端末１０毎）に後述する図３の搭載アプリケーション情報テーブル３０の設定を行うことで、上記３つのパターンの何れにも対応できる。

尚、例えば図９（ａ）におけるブランドＡ１１１と図９（ｂ）におけるブランドＡ１１１とは、全く同じとは限らないが、その処理機能自体は同様である。
尚、上記モジュール化した各ブランドアプリケーション２５は、仮想メモリ空間を使ってデータにアクセスしているので（ＯＳが制御する）、任意のアプリケーションの動作が他のアプリケーション（そのデータ等）に影響を及ぼすことはない。つまり、ファイアウォールを築けることになる。

以上説明したように、本例のＩＣカード決済端末１０では、まず、複数のブランド（複数種類の電子マネー；複数種類のＩＣカード）それぞれに対応する、各ブランド別の独立したアプリケーションモジュール（各ブランドアプリケーションＡ，Ｂ，Ｃ等）が、予め生成されて記憶されている。そして、フレームワーク２０は、これら複数のアプリケーションモジュールのうち、テーブル３０に登録されているものだけを起動する。これより、テーブル３０の設定を変えるだけで（アプリケーション登録の追加、削除等）、各端末１０毎に、その端末１０で対応する１つのブランドまたは複数のブランドの組み合わせを、容易に設定／変更することが可能となる（特徴１）。

更に、フレームワーク２０は、上記アプリケーションモジュール起動の際には、テーブル３０の情報と予め決められている所定のルールとに従って、実行ファイルパスを生成し、この実行ファイルパスを用いて起動を試みる。もし、不正なアプリケーションが入り込んでおり且つその情報が不正にテーブル３０に記憶されていても、上記所定のルールを知らない限り、このアプリケーションは起動されない（特徴２）。

更に、フレームワーク２０は、起動できたアプリケーションモジュールに対してコネクションを確立するので、フレームワーク２０の制御に依らずに勝手に起動したアプリケーションモジュールがあったとしても、フレームワーク２０とのコネクションが無いことになる（特徴３）。

更に、フレームワーク２０は、任意のアプリケーションモジュール２５からの要求に応じて、記憶装置１２へのデータアクセス制御や、外部装置（主局１やセンタサーバ２）への通信制御や、ＩＣカード３との通信制御を実行するが、テーブル４０に登録されていないアプリケーションモジュール、すなわち上記起動が行われていないアプリケーションモジュールからの要求があった場合には、この要求を拒否する。例えば、不正なアプリケーションモジュールから要求があっても、これはテーブル４０には登録されていないので、要求を拒否することになる。よって、不正なアプリケーションモジュールは、少なくともフレームワーク２０を介して実行する処理、すなわち記憶装置１２へのデータアクセス制御や、外部装置（主局１やセンタサーバ２）への通信制御や、ＩＣカード３との通信制御は、実質的に行えないことになる（特徴４）。

フレームワーク２０は、アプリケーションモジュールからの要求に応じて記憶装置１２へのデータアクセス制御を行う際、上記起動時に登録した上記実行ファイルパスのパス情報（上記ルートパス等）を用いて、要求されたデータファイルにアクセスするので、各アプリケーションモジュールは、自己のデータファイルにしかアクセスできない。つまり、例えば正当なアプリケーションモジュールが、他のアプリケーションモジュールのデータにアクセスしようとしても、出来ない。勿論、不正なアプリケーションは、何等データにはアクセスできない（特徴５）。

本発明は、上記特徴１のみでも成立するし、特徴１を含む任意の２以上の組み合わせによっても成立する。つまり、この組み合わせに関しては、特徴１＋特徴２、特徴１＋特徴３、特徴１+特徴４、特徴１＋特徴５、特徴１＋特徴２+特徴３、特徴１＋特徴２＋特徴４、特徴１＋特徴２＋特徴５、特徴１＋特徴２＋特徴３＋特徴４、特徴１＋特徴２＋特徴３＋特徴４＋特徴５が成立し得る。

（ａ）、（ｂ）は、本例のＩＣカード決済端末の構成例を示す図である。 フレームワークの起動処理のフローチャート図である。 搭載アプリケーション情報テーブルの一例を示す図である。 各ブランドアプリケーションの格納形式を示す図である。 アプリケーション管理情報テーブルの一例を示す図である。 （ａ）は各ブランドアプリケーションの通常起動処理、（ｂ）はこれに伴うフレームワークの処理のフローチャート図である。 通常処理のフローチャート図である。 不正チェック処理のフローチャート図である。 （ａ）は従来の主制御部の機能ブロック図、（ｂ）は本例のアプリケーションモジュールの構成を示す図である。

符号の説明

１ 主局（上位コントローラ）
２ センタサーバ
３ ＩＣカード
１０ ＩＣカード決済端末
１１ 主制御部
１２ 記憶装置
１３ 通信制御部（対主局）
１４ 通信制御部（対センタ）
１５ 通信制御部（対カード）
２０ フレームワーク
２１ アプリケーション管理部
２２ 上位通信制御部
２３ データ制御部
２４ Ｒ／Ｗ通信制御部
２５ ブランドアプリケーション
３０ 搭載アプリケーション情報テーブル
３１ アプリケーションＮｏ．
３２ アプリケーション名称
３３ サービス種別
３４ 動作パラメータ
４０ アプリケーション管理情報テーブル
４１ アプリケーションNo.
４２ アプリケーションＩＤ
４３ サービス種別
４４ フレームワーク−アプリケーション間通信ポート番号
４５ ルートパス

Claims (6)

1. 複数種類のＩＣカードに対応可能なＩＣカード決済端末であって、
   前記各種ＩＣカードそれぞれに対応して、そのＩＣカードに対応する処理を実行する各種アプリケーションモジュールを記憶するアプリケーションモジュール記憶部と、
   該各種アプリケーションモジュールを管理・制御すると共に、前記アプリケーションモジュールからの要求に応じて、記憶装置へのデータアクセス制御または外部装置への通信制御あるいはＩＣカードとの通信制御を実行する共通処理部とを有し、
   前記共通処理部は、
   予め前記各種アプリケーションモジュールのうちの任意の１以上のアプリケーションモジュールに関する登録情報を記憶しておく登録情報記憶手段と、
   初期処理として、前記アプリケーションモジュール記憶部に記憶されている各種アプリケーションモジュールのうち、その前記登録情報が前記登録情報記憶手段に登録されているアプリケーションモジュールを起動するアプリケーションモジュール管理手段と、
   起動したアプリケーションモジュールの管理情報を記憶する起動アプリケーション管理情報記憶手段と、
   を有することを特徴とするＩＣカード決済端末。
2. 前記アプリケーションモジュール管理手段は、前記登録情報に基づいてパス情報を生成し、該パス情報を用いてアプリケーションモジュールを起動し、該起動成功した場合には、該起動したアプリケーションモジュールに対してコネクション確立すると共に、該起動したアプリケーションモジュールに関する前記管理情報であって前記生成したパス情報を含む管理情報を、前記起動アプリケーション管理情報記憶手段に記憶することを特徴とする請求項１記載のＩＣカード決済端末。
3. 前記登録情報には前記アプリケーションモジュールの名称が含まれており、
   前記各種アプリケーションモジュールは、予め、その名称と予め決められた所定のルールとに基づいて決定される格納場所に格納されており、
   前記アプリケーションモジュール管理手段は、前記登録情報に含まれる名称と前記所定のルールとに基づいて、そのアプリケーションモジュールの格納場所を示す前記パス情報を生成することを特徴とする請求項２記載のＩＣカード決済端末。
4. 前記共通処理部は、任意の前記アプリケーションモジュールからの任意の要求に応じて、前記記憶装置へのデータアクセス制御または外部装置への通信制御あるいはＩＣカードとの通信制御を実行する際に、該要求元のアプリケーションモジュールに関する前記管理情報が前記起動アプリケーション管理情報記憶手段に記憶されているか否かをチェックし、記憶されていない場合には該要求を拒否することを特徴とする請求項１〜３の何れかに記載のＩＣカード決済端末。
5. 前記共通処理部は、前記アプリケーションモジュールからの要求に応じて前記記憶装置へのデータアクセス制御を行う場合、該要求に含まれるアクセス対象のデータファイルの名称と、前記起動アプリケーション管理情報記憶手段に記憶されている前記パス情報とを用いて、該データファイルにアクセスする為のファイルパスを生成し、該ファイルパスを用いて前記アクセス対象のデータファイルにアクセスすることを特徴とする請求項２または３記載のＩＣカード決済端末。
6. 複数種類のＩＣカードに対応可能なＩＣカード決済端末のコンピュータを、
   前記各種ＩＣカードそれぞれに対応して、そのＩＣカードに対応する処理を実行する各種アプリケーションモジュールを記憶するアプリケーションモジュール記憶部と、
   該各種アプリケーションモジュールを管理・制御すると共に、前記アプリケーションモジュールからの要求に応じて、記憶装置へのデータアクセス制御または外部装置への通信制御あるいはＩＣカードとの通信制御を実行する共通処理部と、
   前記共通処理部における、予め前記各種アプリケーションモジュールのうちの任意の１以上のアプリケーションモジュールに関する登録情報を記憶しておく登録情報記憶手段と、初期処理として、前記アプリケーションモジュール記憶部に記憶されている各種アプリケーションモジュールのうち、その前記登録情報が前記登録情報記憶手段に登録されているアプリケーションモジュールを起動するアプリケーションモジュール管理手段と、起動したアプリケーションモジュールの管理情報を記憶する起動アプリケーション管理情報記憶手段、
   として機能させる為のプログラム。

Images