(58)【調査した分野】(Int.Cl.,DB名)
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、上述した特許文献1,2を含む従来の情報処理装置では、セキュアな部分についてはセキュリティが確保されるが、非セキュアな部分については一般的にセキュリティが不十分となる。そのため、非セキュアな部分に、不正なアプリケーションがインストールされた場合、本人確認のための認証情報(例えば、PIN(Personal Identification Number)又は署名)を入力するための正規な入力領域が不正に隠される可能性があった。或いは、不正なアプリケーションにより別の不正な入力領域が表示される可能性があった。このような事情から、ユーザは、不正な入力領域を正規な入力領域と錯誤して、不正な入力領域に認証情報を入力した場合に、認証情報を奪取(フィッシング)される可能性があった。
【0007】
また、通常の(正常に動作する)アプリケーションでは、このアプリケーションにおける処理の実行に伴って、アプリケーションの実行時に使用される複数のAPI(Application Program Interface)も既定の順序に従って呼び出される。ところが、不正なアプリケーションがインストールされた場合、アプリケーションの実行時に使用されるAPIの呼び出し順序が既定の順序通りとならず、不正な決済処理が行われてしまう可能性もある。
【0008】
本発明は、上述した従来の状況に鑑みて、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるAPIの呼び出し順序の監視により、疑義のある取引等の処理を抑止し、認証情報等のセキュリティを確保する
決済処理装置を提供することを目的とする。
【課題を解決するための手段】
【0009】
本発明は、非セキュアな第1の情報処理部と、セキュアな第2の情報処理部とにより構成され、複数の決済処理を実行可能な決済処理装置であって、
前記決済処理を実行する決済処理部と、各々の前記決済処理の実行
時に
呼び出される複数の個別機能部と、
前記決済処理の実行に伴う前記個別機能部の呼出手順を監視し、前記呼出手順の履歴を蓄積部に保存するモニタ部と、前記モニタ部により前記蓄積部に保存された前記個別機能部の
呼出手順の履歴を基に、
前記決済処理の実行時における前記個別機能部の
呼出手順の正当性を判断する判断部と、を備え、前記判断部は、前記第2の情報処理部に実装される決済処理装置である。
【0010】
この
決済処理装置では、複数の個別機能部は、各々の処理の実行に伴って使用され、それぞれ異なる個別の機能を有する。判断部は、蓄積部に蓄積された個別機能部の使用手順の履歴を基に、個別機能部の使用手順の正当性を判断する。
【0011】
これにより、
決済処理装置は、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用される個別機能部の使用順序により、疑義のある取引等の処理を抑止することができるので、認証情報等のセキュリティを確保することができる。また、
決済処理装置は、不正な処理が行われることで発生する、加盟店やアクワイヤラ等への損害を低減することができる。
【0012】
また、本発明は、前記個別機能部の使用手順は、前記個別機能部の使用順序及び使用頻度のうち少なくとも一方を含む、
決済処理装置である。
【0013】
これにより、個別機能部の使用手順には、不正な処理が実行された場合に変化として現れやすい個別機能部の使用順序及び使用頻度の少なくとも一方が含まれるので、
決済処理装置は、不正な処理を発見し易くすることができる。
【0014】
また、本発明は、前記判断部は、前記個別機能部の使用手順が異常であると判断された場合、前記
決済処理の実行を停止させる、
決済処理装置である。
【0015】
これにより、
決済処理装置は、使用手順が異常である場合、処理の実行が停止させることができるので、不正な処理が継続して行われることを防ぐことができる。
【0016】
また、本発明は、前記判断部は、前記個別機能部の使用手順が異常であると判断された場合、所定の警報を報知させる、
決済処理装置である。
【0017】
これにより、
決済処理装置は、使用手順が異常であった場合、所定の警報を報知することができるので、操作者に不正な処理の実行を気付かせることができる。
【0018】
また、本発明は、前記判断部は、前記個別機能部の使用手順が正常であると判断された場合、前記
決済処理の実行を許可する、
決済処理装置である。
【0019】
これにより、
決済処理装置は、使用手順が正常であった場合、処理の実行を許可するので、操作者が所望する処理を継続させることができる。
【0020】
また、本発明は、前記判断部は、前記個別機能部の使用手順を蓄積部に蓄積し、前記蓄積部に蓄積された前記個別機能部の使用手順の履歴を更新する、
決済処理装置である。
【0021】
これにより、
決済処理装置は、個別機能部の使用手順を蓄積部に蓄積するので、個別機能部の使用手順の履歴を最新状態に更新することができる。
【発明の効果】
【0022】
本発明によれば、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるAPIの呼び出し順序の監視により、疑義のある取引等の処理を抑止し、認証情報等のセキュリティを確保することができる。
【発明を実施するための形態】
【0024】
以下、本発明に係る情報処理装置の実施形態(以下、「本実施形態」という)について、図面を参照して説明する。本実施形態では、本発明に係る情報処理装置の一例として、商品又は役務の取引における決済処理の際に用いられる決済端末装置を例示して説明する。
【0025】
図1(A)は、本実施形態の決済端末装置100を含む決済システム5の全体構成を示す図である。決済システム5は、物品等の取引における決済処理を行うものであり、決済センタ3に設置されたデータ処理装置4と、各加盟店8に設置された決済端末装置100とがインターネット7を介して接続された構成を有する。
【0026】
決済センタ3は、物品等の取引においては、取引を行う人物と取引に使用されるクレジットカード等の所有者とが同一人物であるかどうかを確認する。また、この確認に際し、取引を行う人物(操作者)は、決済端末装置100にPIN(Personal identification number)を入力する。
【0027】
決済センタ3のデータ処理装置4は、決済端末装置100に入力されたPIN情報を、インターネット7を経由して受け取り、あらかじめデータベースに登録されている認証情報と照合する。照合の結果、認証が成功した場合、決済センタ3は、この操作者に与信を与える。決済センタ3から与信が与えられると、決済端末装置100は、決済処理を続行する。
【0028】
図1(B)は、
図1(A)に示す決済端末装置100の外観を示す正面図である。決済端末装置100は、操作者が手で把持可能な可搬型のものであり、その操作面にタッチパネルTPを有する。ここでは、タッチパネルTPは2つの画面を有する。一方(図中上方)のタッチパネルTP1の画面には、決済金額情報及びPINの入力を促すメッセージが表示される。他方(図中下方)のタッチパネルTP2の画面には、PINパッドが表示される。操作者は、PINパッドをペンでタッチすることで、PIN入力を行う。
【0029】
図2は、本実施形態の決済端末装置100の機能的な内部構成の一例を示すブロック図である。決済端末装置100は、ハードウェア部110と、オペレーティングシステム(OS)120と、API部150と、アプリケーション部160と、後述する判断部145を有するモニタ統計部140と、画面UIアプリケーション130とを含む構成である。モニタ統計部140(判断部145も含む)と統計蓄積部60とは、例えば改ざん防止のため、後述するセキュア部(第2の情報処理部41)内に実装されることが好ましい。
【0030】
ハードウェア部110には、その記憶領域に、統計蓄積部60が割り当てられたストレージメモリ55が設けられている。統計蓄積部60には、後述するように、アプリケーション毎にAPI(Application Programming Interface)を呼び出す手順の履歴が蓄積される。
図2には、APIを呼び出した手順の履歴として、例えば「ABCD」、「ABCD」、「ABCE」、「ABCD」、「ABC」、…が蓄積されている。なお、
図2の説明において、「A」、「B」、「C」、「D」、「E」は、個々のAPIを示す。
【0031】
API部150には、アプリケーション部160内の各アプリケーションから呼び出される個別機能部が用意されている。そして、それぞれの個別機能部は、APIを介して、該当する個別機能のプログラムを呼び出すことが可能に構成されている。APIとは、アプリケーションの機能を補助し、個別の機能を有する外部アプリケーション、及びこの外部アプリケーションを利用可能にするインターフェースを含むプログラムである。このインターフェースには、外部アプリケーションの呼び出しや記述の仕方等を定めた仕様が含まれる。
図2には、例えば6種類のAPI(API_A〜API_E)151〜155が示されている。
【0032】
モニタ統計部140(監視部)は、判断部145を含み、後述するセキュア部内の第2のCPU42がOS120上で動作するファームウェア(ミドルウェア)を実行することによって実現される機能である。
【0033】
モニタ統計部140は、第1のCPU22がアプリケーション(処理)を実行する際、各アプリケーションがAPI部150からAPIを呼び出す手順(APIの呼出手順)を監視し、この呼出手順を統計蓄積部60に蓄積するとともに、判断部145に渡す。ここでは、呼出手順(使用手順)には、不正なアプリケーションが実行された場合、変化として現れやすい、APIの呼出順序(使用順序)及び呼出頻度(使用頻度)の少なくとも一方が含まれる。なお、呼出手順には、APIの呼出時間の間隔等が含まれてもよい。
【0034】
判断部145は、モニタ統計部140から受け取ったAPIの呼出手順(呼出順序及び呼出頻度)を元に、統計蓄積部60を参照し、アプリケーションの正当性、つまり正当なアプリケーションが実行されているか否かを判断する。
【0035】
例えば、
図2において、APIの呼出順序として、モニタ統計部140に蓄積されている呼出手順の履歴を基に、「ABCD」が正常であることが分かっている場合、判断部145は、モニタ統計部140によって監視されたAPIの呼出順序から、正当なアプリケーションが実行されていると判断する。一方、このアプリケーションでは行われないような、APIの呼出順序が「ABCE」である場合、判断部145は、不正なアプリケーションが実行されていると判断する。また、APIの呼出順序が「ABC」である場合、判断部145は、途中で取引を停止した可能性があるとして、疑わしいアプリケーション(グレーゾーンのアプリケーション)であると判断する。疑わしいアプリケーションの場合、操作者は、その後の処理を任意に選択可能である。
【0036】
ここで、呼出順序が正常であるか否かの判断には、統計蓄積部60に、アプリケーション毎に蓄積されている呼出順序の履歴が用いられる。例えば、監視された呼出順序が履歴として蓄積されている多くの呼出順序と同じである場合、判断部145は、この監視された呼出順序が正常であると判断する。逆に、稀な呼出順序である場合、判断部145は、この監視された呼出順序を異常であると判断する。これは、正常な取引処理の多くが最も高い頻度の呼出順序で行われているとの考え方に基づく。
【0037】
また、履歴として蓄積されている多くのAPIに対する呼出頻度が最大3回(一例)である場合、判断部145は、監視された呼出頻度が3回以内であると、この監視された呼出頻度が正常であると判断し、4回以上であると、異常であると判断する。
【0038】
なお、ここでは、統計蓄積部60に履歴として蓄積されている多くの呼出手順と同じであるか否かによって、つまり、多くの前歴があるか否かによって呼出手順の正当性を判断したが、正当性の判断方法はこれに限られない。例えば、不正なアプリケーションによる呼出手順をあらかじめ統計蓄積部に登録しておき、この呼出手順と同じである場合、判断部は、異常であると判断してもよい。或いは、正常なアプリケーションによる呼出手順をあらかじめ統計蓄積部に登録しておき、この呼出手順と同じである場合、判断部は、正常であると判断してもよい。このように、あらかじめ決められた呼出手順に則っているか否かによって、判断部145が正当性を判断してもよい。
【0039】
アプリケーション部160には、各種のアプリケーションがインストールされている。
図2に示す各種のアプリケーションは、決済アプリケーション161、業務アプリケーション163及び汎用アプリケーション165の3つに大別される。
図3は、本実施形態の決済端末装置100において使用可能な各種アプリケーションの一例を示す図である。決済アプリケーション161には、磁気クレジット決済アプリケーション、ICクレジット決済アプリケーション、デビット決済アプリケーション、電子マネー決済アプリケーション、ポストペイ決済アプリケーション等が含まれる。
【0040】
業務アプリケーション163には、商品カタログアプリケーション、商品販売(契約)アプリケーション、公共料金収受アプリケーション、販売集計レポートアプリケーション等が含まれる。
【0041】
汎用アプリケーション165には、ブラウザアプリケーション、Email Clientアプリケーション、文書作成アプリケーション、表計算アプリケーション等が含まれる。
【0042】
図4は、本実施形態の決済端末装置100のハードウェア部110の構成の一例を示す図である。決済端末装置100のハードウェア部110は、第1の情報処理部21と、セキュアな第2の情報処理部41とを備える。第1の情報処理部21は、第1のCPU(Central Processing Unit)22と、局所無線通信部23と、広域無線通信部25と、表示部29と、タッチ入力検出部27とを含む構成である。
【0043】
また、第1の情報処理部21は、第1のフラッシュROM(Read Only Memory)31と、第1のRAM(Random Access Memory)33と、キー入力部35と、磁気カードリーダ部13と、第1のIF(Interface)部37とを含む構成である。
【0044】
また、第1の情報処理部21は、第1のタッチ入力処理部107と、第1の表示生成部109とを含む構成である。
【0045】
第1の情報処理部21では、第1のCPU22に各部が接続される。第1のCPU22は、第1の情報処理部21の全体を統括し、例えば、各種制御、処理、設定、判定、決定、確認等を行う。
【0046】
局所無線通信部23は、局所無線通信アンテナ23Aと接続され、局所無線通信路(図示せず)を用いて、例えば無線LANで通信する機能を有する。局所無線通信部23は、無線LAN通信以外の通信(例えばBluetooth(登録商標)通信)を行ってもよい。
【0047】
広域無線通信部25は、広域無線通信アンテナ25Aと接続され、図示しない広域無線通信路(例えばWAN(Wide Area Network))を介して通信する機能を有する。広域無線通信路における通信は、例えばW−CDMA(Wideband Code Division Multiple Access)、UMTS(Universal Mobile Telecommunications System)、CDMA(Code Division Multiple Access)2000、LTE(Long Term Evolution)等の移動体通信を用いて行われてもよい。
【0048】
タッチパネルTPは、タッチ入力検出部27の検出面と表示部29の画面とを重ね合わせた構造を有する。本実施形態では、タッチパネルTPは、2つのタッチパネルTP1及びタッチパネルTP2に分割されている。タッチパネルTP1の画面には、非セキュアな表示領域及びセキュアな表示領域が設定される。タッチパネルTP1の検出面には、非セキュアな入力領域が設定される。また、タッチパネルTP2の画面には、セキュアな表示領域が設定される。タッチパネルTP2の検出面には、非セキュアな入力領域が設定される。表示部29は、タッチパネルTP(
図1(B)参照)の表示を制御する機能を有する。タッチ入力検出部27はタッチパネルTPに対するタッチ入力を検出する機能を有する。
【0049】
第1のフラッシュROM31は、各種のデータを記憶する機能を有する。第1のフラッシュROM31には、前述した決済アプリケーション161、業務アプリケーション163、汎用アプリケーション165等の種々のアプリケーションが更新可能に記憶される。また、第1のフラッシュROM31には、第1の情報処理部21を制御するためのプログラムが記憶される。
【0050】
第1のRAM33は、例えば第1の情報処理部21の動作に伴う演算処理の際に、演算処理の途中において発生する処理データを、一時的に記憶するために用いられるメモリである。
【0051】
キー入力部35は、筺体の側面等に配置された入力キー(図示せず)からの入力を受け付ける機能を有する。磁気カードリーダ部13は、その一部がスリットの内部に配置され、磁気カードの磁気ストライプを読み取る機能を有する。
【0052】
第1のタッチ入力処理部107は、非セキュアな入力領域に入力された操作(ペン入力等)に対応する処理を行う。第1の表示生成部109は、非セキュアな表示領域に表示される画像データを生成する。
【0053】
第1の情報処理部21及び第2の情報処理部41は、第1のインターフェース部(以下「第1のIF部」)37及び第2のインターフェース部(以下「第2のIF部」)43を介して、互いに接続され、各種のデータやコマンドの受け渡しが行われる。また、第1のIF部37と第2のIF部43とは、互いに結合可能である。
【0054】
第2の情報処理部41は、セキュア部であり、第2のIF部43と、第2のCPU42と、非接触型ICカードリーダライタ部45と、第2のフラッシュROM51と、第2のRAM53と、第2のタッチ入力処理部113と、第2の表示生成部115と、ストレージメモリ55とを含む構成である。
【0055】
第2の情報処理部41では、第2のCPU42に各部が接続される。第2のCPU42は、第2の情報処理部41の全体を統括し、例えば、各種制御、処理(例えば決済処理)、設定、判定、決定、確認、認証、照合(例えば、PIN、署名、の照合)等を行う。
【0056】
第2のフラッシュROM51は、各種のデータを記憶する機能を有する。また、第2のフラッシュROM51には、各種のデータの他、第2の情報処理部41を制御するためのプログラムが記憶される。
【0057】
第2のRAM53は、例えば第2の情報処理部41の動作に伴う演算処理等の際に、演算処理の途中において発生する処理データを、一時的に記憶するために用いられるメモリである。
【0058】
非接触型ICカードリーダライタ部45は、ループアンテナ45Aを有し、セキュア部である第2の情報処理部41に備えられ、ICカードの入出力を制御する。
【0059】
第2のタッチ入力処理部113は、セキュアな入力領域に入力された操作(ペン入力等)に対応する処理を行う。第2の表示生成部115は、セキュアな表示領域に表示される画像データを生成する。
【0060】
ストレージメモリ55は、データを長期保存可能なSSD(Solid State Drive)等のメモリであり、その記憶領域の一部に統計蓄積部60を割り当てる。
【0061】
上述した構成を有する決済端末装置100の動作について、以下説明する。ここでは、決済アプリケーションの実行に伴ってAPIが呼び出される呼出手順を監視する場合について説明する。
【0062】
図5は、本実施形態の決済端末装置100におけるAPIの呼出手順を監視する動作を説明するフローチャートである。
【0063】
図5において、先ず、決済アプリケーション161の処理が開始されるまで待つ(S1)。決済アプリケーション161の処理が開始すると、モニタ統計部140は、決済アプリケーション161によって呼び出されるAPIの呼出手順を監視する(S2)。ここでは、呼出手順として、呼出順序が監視される。モニタ統計部140は、APIの呼出順序の監視結果を判断部145に渡す。
【0064】
判断部145は、統計蓄積部60に蓄積されている呼出手順の履歴を参照する(S3)。判断部145は、例えば、統計蓄積部60に蓄積されている呼出手順の履歴から、正当な決済アプリケーション161の実行に伴って呼び出されるAPIの呼出順序を読み出す。ここでは、前述したように、統計蓄積部60に蓄積されている、アプリケーション毎の呼出順序のうち、最も多く蓄積されている呼出順序が正常な呼出順序であると想定している。
【0065】
判断部145は、監視されているAPIの呼出順序が蓄積されているAPIの呼出順序と一致するか否かを判断する(S4)。なお、呼出順序の代わりに、呼出頻度を用いてもよいし、呼出順序と呼出頻度の両方を用いてもよいし、別の呼出手順を用いてもよい。一致する場合、判断部145は、決済アプリケーションの実行を許可する(S5)。一方、一致しない場合、判断部145は、決済アプリケーションの実行を停止し(S6)、警報を発する(S7)。ここでは、警報として、注意を喚起するメッセージがタッチパネルTPの画面に表示されるが、音声が発せられてもよい。
【0066】
ステップS5で決済アプリケーションの実行が許可された後、或いはステップS7で警報が発せられた後、モニタ統計部140は、監視されたAPIの呼出手順を統計蓄積部60に蓄積し、統計蓄積部60に蓄積されているAPIの呼出手順の履歴を更新する(S8)。この後、本動作は終了する。
【0067】
APIの呼出手順について具体例を示す。
図6(A)は、磁気クレジットカードを使用し、APIの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す。決済アプリケーション161は、始めに、磁気クレジットカードの読み取りを行うAPIを呼び出し(T1)、操作者に磁気クレジットカードの読み取り動作を行わせる。
【0068】
決済アプリケーション161は、接続先センタを選択するAPIを呼び出し(T2)、読み取った磁気クレジットカードのブランドに対応する接続先センタを選択する。なお、読み取った磁気クレジットカードが複数のカードブランドを持っている場合には、決済アプリケーション161は、複数のカードブランドの中から操作者によって選択されたカードブランドに対応する接続先センタを選択する。決済アプリケーション161は、決済金額を入力するAPIを呼び出し(T3)、操作者に決済金額を入力させる。
【0069】
決済アプリケーション161は、支払回数を入力するAPIを呼び出し(T4)、操作者に支払回数を入力させる。決済アプリケーション161は、手順T2で選択した接続先センタに与信を要求するAPIを呼び出し(T5)、接続先センタに対し、与信の要求を送信する。
【0070】
決済アプリケーション161は、接続先センタから与信の結果を受信するAPIを呼び出し(T6)、与信の結果を受信する。与信が付加されると、決済アプリケーション161は、決済処理を行ってレシートを印字するAPIを呼び出し(T7)、レシートを印字する。
【0071】
図6(B)は、APIの呼出手順が正常に行われた場合の他の決済処理の動作手順の一例を示す。この決済アプリケーション161は、手順T4で支払回数を入力するAPIを呼び出した後、操作者から取消操作を受け付けたことによって、決済処理を取り消すAPIを呼び出し(T8)、本決済処理を取り消す。
【0072】
図6(C)は、APIの呼出手順が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す。
図6(C)に示す不正と疑われる決済アプリケーションは、手順T5で与信の要求を送信した後、接続先センタから与信の結果を受信することなく、手順T7でレシートを印字するAPIを呼び出している。
図6(A)と比べると、与信の結果を受け取ることなく、レシートの印字が行われる。このように、与信が与えらないことが事前に分かっているような、与信結果の受信を伴わない決済アプリケーションは、不正なアプリケーションと判断される。
【0073】
図7(A)は、ICクレジットカードを使用し、APIの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す。決済アプリケーション161は、始めに、ICクレジットカードの読み取りを行うAPIを呼び出し(T1A)、操作者にICクレジットカードの読み取り動作を行わせる。
【0074】
決済アプリケーション161は、PIN入力を処理するAPIを呼び出し(T1B)、操作者によるPIN入力を受け付ける。このAPIでは、PINの再入力は最大3回に制限されている。この制限値である3回は、あらかじめ登録されてもよいし、過去の履歴から自動的に設定されてもよい。この後、APIの呼出手順は、
図6(A)と同様に行われる。
【0075】
図7(B)は、APIの呼出頻度が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す。不正と疑われるアプリケーションは、PIN入力を受け付けるAPIを4回以上呼び出している。このAPIの呼出手順が異常であると判断された場合、このアプリケーションの実行は停止される。なお、停止に限らず、任意の処理が行われてもよい。
【0076】
図7(C)は、APIの呼出頻度が異常であり、不正と疑われる場合の他の決済処理の動作手順の一例を示す。即ち、不正と疑われるこのアプリケーションは、カードの読み取りを行うAPIを短時間に複数回(ここでは、10分間に30回超)行っている。この場合、偽造カードの所有者又は正当なカードの所有者ではない第三者による不正な決済が、短時間に複数回行われている状況が想定される。このAPIの呼出が異常であると判断された場合、同様に、このアプリケーションの実行は停止される。なお、停止に限らず、任意の処理が行われてもよい。
【0077】
以上により、本実施形態の決済端末装置100では、複数のAPI151〜155は、決済アプリケーション161の実行に伴って呼び出され、それぞれ個別の機能を有する。モニタ統計部140は、決済アプリケーション161の実行に伴って呼び出されるAPIの呼出手順を監視する。統計蓄積部60は、APIの呼出手順の履歴を蓄積する。判断部145は統計蓄積部60に蓄積されたAPIの呼出手順の履歴を基に、モニタ統計部140で監視されるAPIの呼出手順の正当性を判断する。
【0078】
これにより、決済端末装置100は、APIの呼出手順が異常であると判断された場合、決済端末装置100は、決済アプリケーション161の実行を停止できる。従って、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるAPIの呼び出し順序の監視により、疑義のある取引等の処理を抑止することができるので、認証情報等のセキュリティを確保することができる。特に、入力されるPINのセキュリティを確保することができる。更に、決済端末装置100は、悪意のあるアプリケーションが不正な振る舞いを行うことにより発生する、加盟店やアクワイヤラへの損害(例えばPIN・署名の盗み出し・改ざん、不正な取引)を低減することができる。
【0079】
また、監視される呼出手順には、不正なアプリケーションが実行された場合に変化として現れやすいAPIの呼出順序及び呼出頻度の少なくとも一方が含まれるので、決済端末装置100は、不正なアプリケーションによる処理を発見し易くすることができる。
【0080】
また、決済端末装置100は、APIの呼出手順が異常である場合、アプリケーションの実行を停止させることができるので、不正なアプリケーションが継続して行われることを防ぐことができる。
【0081】
また、決済端末装置100は、APIの呼出手順が異常であった場合、所定の警報を報知することができるので、操作者に不正なアプリケーションによる処理の実行を気付かせることができる。
【0082】
また、決済端末装置100は、呼出手順が正常であった場合、アプリケーションによる処理の実行を許可するので、操作者が所望するアプリケーションによる処理の実行を継続することができる。
【0083】
また、決済端末装置100は、監視された呼出手順を統計蓄積部に蓄積するので、APIの呼出手順の履歴を最新状態に更新することができる。
【0084】
以上、図面を参照しながら各種の実施形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【0085】
例えば、上記実施形態では、個別機能部として、アプリケーションによって呼び出されるAPI(Application Programming Interface)を例示したが、個別の機能を有するタイマ、カウンタ、プリンタ等のハードウェア資源であってもよい。