(57)【特許請求の範囲】
【請求項１】
非セキュアな第１の情報処理部と、セキュアな第２の情報処理部とにより構成され、複数の決済処理を実行可能な決済処理装置であって、
前記決済処理を実行する決済処理部と、
各々の前記決済処理の実行時に呼び出される複数の個別機能部と、
前記決済処理の実行に伴う前記個別機能部の呼出手順を監視し、前記呼出手順の履歴を蓄積部に保存するモニタ部と、
前記モニタ部により前記蓄積部に保存された前記個別機能部の呼出手順の履歴を基に、前記決済処理の実行時における前記個別機能部の呼出手順の正当性を判断する判断部と、を備え、
前記判断部は、前記第２の情報処理部に実装された、
決済処理装置。
【請求項２】
請求項１に記載の決済処理装置であって、
前記個別機能部の呼出手順は、前記個別機能部の呼出順序及び呼出頻度のうち少なくとも一方を含む、
決済処理装置。
【請求項３】
請求項１又は２に記載の決済処理装置であって、
前記判断部は、
前記個別機能部の呼出手順が異常であると判断された場合、前記決済処理の実行を停止させる、
決済処理装置。
【請求項４】
請求項３に記載の決済処理装置であって、
前記判断部は、
前記個別機能部の呼出手順が異常であると判断された場合、所定の警報を報知させる、
決済処理装置。
【請求項５】
請求項１又は２に記載の決済処理装置であって、
前記判断部は、
前記個別機能部の呼出手順が正常であると判断された場合、前記決済処理の実行を許可する、
決済処理装置。
【請求項６】
請求項１から５のうちいずれか一項に記載の決済処理装置であって、
前記モニタ部は、
前記蓄積部に蓄積された前記個別機能部の呼出手順の履歴を更新する、
決済処理装置。
【請求項７】
請求項１に記載の決済処理装置であって、
前記決済処理装置は、可搬型である、
決済処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の処理を実行可能な決済処理装置に関する。
【背景技術】
【０００２】
例えば、クレジットカードを使用した物品又は役務の（信用）取引においては、取引を行う人物と取引に使用されるクレジットカードの所有者とが同一人物であるかどうかを確認（本人確認）することにより、取引の安全性（セキュリティ）が確保されている。この本人確認は、取引の決済処理時に取引内容の印字された取引伝票に顧客がサインし、このサインとクレジットカードに記載されているサインとを店員が目視により対比することにより行われている。
【０００３】
近年、このような署名の入力及び表示が可能な端末装置は、スマートフォンやタブレット端末を用いて実現されている。スマートフォンやタブレット端末は民生用機器として多数流通しており、安価に調達して決済端末装置を構築することが可能となる。即ち、このような決済端末装置は、スマートフォンやタブレット端末等のように民生用機器として多数流通している情報端末を用いて構成できれば、決済端末装置自体を安価に調達可能である。また、決済処理その他の業務に用いられるアプリケーション（ソフトウェア）の開発プラットフォームの汎用化が可能となるので、開発資産の再利用や流用が容易となる。
【０００４】
しかしながら、民生用機器として使用されることを想定して設計された情報端末には、顧客の情報を保護して取引を安全に行うために必要な「耐タンパ性」が備わっていない。「耐タンパ性」とは、情報端末から情報を盗み出そうとする攻撃に対する耐性である。情報端末から情報を盗み出そうとする攻撃の対策として耐タンパ性を確保するため、決済処理に用いられるカードの認証情報に関わる部分（特許文献１では「セキュア部」と称されている。決済端末装置として必要な耐タンパ性を備える部分。）が汎用部分から分離された移動体装置が提案されている（例えば特許文献１、２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】米国特許出願公開第２０１０／０１４５８５４号明細書
【特許文献２】特開２００４−３５５２１１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、上述した特許文献１，２を含む従来の情報処理装置では、セキュアな部分についてはセキュリティが確保されるが、非セキュアな部分については一般的にセキュリティが不十分となる。そのため、非セキュアな部分に、不正なアプリケーションがインストールされた場合、本人確認のための認証情報（例えば、ＰＩＮ（Personal Identification Number）又は署名）を入力するための正規な入力領域が不正に隠される可能性があった。或いは、不正なアプリケーションにより別の不正な入力領域が表示される可能性があった。このような事情から、ユーザは、不正な入力領域を正規な入力領域と錯誤して、不正な入力領域に認証情報を入力した場合に、認証情報を奪取（フィッシング）される可能性があった。
【０００７】
また、通常の（正常に動作する）アプリケーションでは、このアプリケーションにおける処理の実行に伴って、アプリケーションの実行時に使用される複数のＡＰＩ（Application Program Interface）も既定の順序に従って呼び出される。ところが、不正なアプリケーションがインストールされた場合、アプリケーションの実行時に使用されるＡＰＩの呼び出し順序が既定の順序通りとならず、不正な決済処理が行われてしまう可能性もある。
【０００８】
本発明は、上述した従来の状況に鑑みて、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるＡＰＩの呼び出し順序の監視により、疑義のある取引等の処理を抑止し、認証情報等のセキュリティを確保する決済処理装置を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明は、非セキュアな第１の情報処理部と、セキュアな第２の情報処理部とにより構成され、複数の決済処理を実行可能な決済処理装置であって、前記決済処理を実行する決済処理部と、各々の前記決済処理の実行時に呼び出される複数の個別機能部と、前記決済処理の実行に伴う前記個別機能部の呼出手順を監視し、前記呼出手順の履歴を蓄積部に保存するモニタ部と、前記モニタ部により前記蓄積部に保存された前記個別機能部の呼出手順の履歴を基に、前記決済処理の実行時における前記個別機能部の呼出手順の正当性を判断する判断部と、を備え、前記判断部は、前記第２の情報処理部に実装される決済処理装置である。
【００１０】
この決済処理装置では、複数の個別機能部は、各々の処理の実行に伴って使用され、それぞれ異なる個別の機能を有する。判断部は、蓄積部に蓄積された個別機能部の使用手順の履歴を基に、個別機能部の使用手順の正当性を判断する。
【００１１】
これにより、決済処理装置は、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用される個別機能部の使用順序により、疑義のある取引等の処理を抑止することができるので、認証情報等のセキュリティを確保することができる。また、決済処理装置は、不正な処理が行われることで発生する、加盟店やアクワイヤラ等への損害を低減することができる。
【００１２】
また、本発明は、前記個別機能部の使用手順は、前記個別機能部の使用順序及び使用頻度のうち少なくとも一方を含む、決済処理装置である。
【００１３】
これにより、個別機能部の使用手順には、不正な処理が実行された場合に変化として現れやすい個別機能部の使用順序及び使用頻度の少なくとも一方が含まれるので、決済処理装置は、不正な処理を発見し易くすることができる。
【００１４】
また、本発明は、前記判断部は、前記個別機能部の使用手順が異常であると判断された場合、前記決済処理の実行を停止させる、決済処理装置である。
【００１５】
これにより、決済処理装置は、使用手順が異常である場合、処理の実行が停止させることができるので、不正な処理が継続して行われることを防ぐことができる。
【００１６】
また、本発明は、前記判断部は、前記個別機能部の使用手順が異常であると判断された場合、所定の警報を報知させる、決済処理装置である。
【００１７】
これにより、決済処理装置は、使用手順が異常であった場合、所定の警報を報知することができるので、操作者に不正な処理の実行を気付かせることができる。
【００１８】
また、本発明は、前記判断部は、前記個別機能部の使用手順が正常であると判断された場合、前記決済処理の実行を許可する、決済処理装置である。
【００１９】
これにより、決済処理装置は、使用手順が正常であった場合、処理の実行を許可するので、操作者が所望する処理を継続させることができる。
【００２０】
また、本発明は、前記判断部は、前記個別機能部の使用手順を蓄積部に蓄積し、前記蓄積部に蓄積された前記個別機能部の使用手順の履歴を更新する、決済処理装置である。
【００２１】
これにより、決済処理装置は、個別機能部の使用手順を蓄積部に蓄積するので、個別機能部の使用手順の履歴を最新状態に更新することができる。
【発明の効果】
【００２２】
本発明によれば、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるＡＰＩの呼び出し順序の監視により、疑義のある取引等の処理を抑止し、認証情報等のセキュリティを確保することができる。
【図面の簡単な説明】
【００２３】
【図１】（Ａ）本実施形態の決済端末装置を含む決済システムの全体構成を示す図、（Ｂ）（Ａ）に示す決済端末装置の外観を示す正面図
【図２】本実施形態の決済端末装置の機能的な内部構成の一例を示すブロック図
【図３】本実施形態の決済端末装置において使用可能な各種アプリケーションの一例を示す図
【図４】本実施形態の決済端末装置のハードウェア部の構成の一例を示す図
【図５】本実施形態の決済端末装置におけるＡＰＩの呼出手順を監視する動作を説明するフローチャート
【図６】（Ａ）磁気クレジットカードを使用し、ＡＰＩの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す図、（Ｂ）ＡＰＩの呼出手順が正常に行われた場合の他の決済処理の動作手順の一例を示す図、（Ｃ）ＡＰＩの呼出手順が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す図
【図７】（Ａ）ＩＣクレジットカードを使用し、ＡＰＩの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す図、（Ｂ）ＡＰＩの呼出頻度が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す図、（Ｃ）ＡＰＩの呼出頻度が異常であり、不正と疑われる場合の他の決済処理の動作手順の一例を示す図
【発明を実施するための形態】
【００２４】
以下、本発明に係る情報処理装置の実施形態（以下、「本実施形態」という）について、図面を参照して説明する。本実施形態では、本発明に係る情報処理装置の一例として、商品又は役務の取引における決済処理の際に用いられる決済端末装置を例示して説明する。
【００２５】
図１（Ａ）は、本実施形態の決済端末装置１００を含む決済システム５の全体構成を示す図である。決済システム５は、物品等の取引における決済処理を行うものであり、決済センタ３に設置されたデータ処理装置４と、各加盟店８に設置された決済端末装置１００とがインターネット７を介して接続された構成を有する。
【００２６】
決済センタ３は、物品等の取引においては、取引を行う人物と取引に使用されるクレジットカード等の所有者とが同一人物であるかどうかを確認する。また、この確認に際し、取引を行う人物（操作者）は、決済端末装置１００にＰＩＮ(Personal identification number)を入力する。
【００２７】
決済センタ３のデータ処理装置４は、決済端末装置１００に入力されたＰＩＮ情報を、インターネット７を経由して受け取り、あらかじめデータベースに登録されている認証情報と照合する。照合の結果、認証が成功した場合、決済センタ３は、この操作者に与信を与える。決済センタ３から与信が与えられると、決済端末装置１００は、決済処理を続行する。
【００２８】
図１（Ｂ）は、図１（Ａ）に示す決済端末装置１００の外観を示す正面図である。決済端末装置１００は、操作者が手で把持可能な可搬型のものであり、その操作面にタッチパネルＴＰを有する。ここでは、タッチパネルＴＰは２つの画面を有する。一方（図中上方）のタッチパネルＴＰ１の画面には、決済金額情報及びＰＩＮの入力を促すメッセージが表示される。他方（図中下方）のタッチパネルＴＰ２の画面には、ＰＩＮパッドが表示される。操作者は、ＰＩＮパッドをペンでタッチすることで、ＰＩＮ入力を行う。
【００２９】
図２は、本実施形態の決済端末装置１００の機能的な内部構成の一例を示すブロック図である。決済端末装置１００は、ハードウェア部１１０と、オペレーティングシステム（ＯＳ）１２０と、ＡＰＩ部１５０と、アプリケーション部１６０と、後述する判断部１４５を有するモニタ統計部１４０と、画面ＵＩアプリケーション１３０とを含む構成である。モニタ統計部１４０（判断部１４５も含む）と統計蓄積部６０とは、例えば改ざん防止のため、後述するセキュア部（第２の情報処理部４１）内に実装されることが好ましい。
【００３０】
ハードウェア部１１０には、その記憶領域に、統計蓄積部６０が割り当てられたストレージメモリ５５が設けられている。統計蓄積部６０には、後述するように、アプリケーション毎にＡＰＩ(Application Programming Interface)を呼び出す手順の履歴が蓄積される。図２には、ＡＰＩを呼び出した手順の履歴として、例えば「ＡＢＣＤ」、「ＡＢＣＤ」、「ＡＢＣＥ」、「ＡＢＣＤ」、「ＡＢＣ」、…が蓄積されている。なお、図２の説明において、「Ａ」、「Ｂ」、「Ｃ」、「Ｄ」、「Ｅ」は、個々のＡＰＩを示す。
【００３１】
ＡＰＩ部１５０には、アプリケーション部１６０内の各アプリケーションから呼び出される個別機能部が用意されている。そして、それぞれの個別機能部は、ＡＰＩを介して、該当する個別機能のプログラムを呼び出すことが可能に構成されている。ＡＰＩとは、アプリケーションの機能を補助し、個別の機能を有する外部アプリケーション、及びこの外部アプリケーションを利用可能にするインターフェースを含むプログラムである。このインターフェースには、外部アプリケーションの呼び出しや記述の仕方等を定めた仕様が含まれる。図２には、例えば６種類のＡＰＩ（ＡＰＩ＿Ａ〜ＡＰＩ＿Ｅ）１５１〜１５５が示されている。
【００３２】
モニタ統計部１４０（監視部）は、判断部１４５を含み、後述するセキュア部内の第２のＣＰＵ４２がＯＳ１２０上で動作するファームウェア（ミドルウェア）を実行することによって実現される機能である。
【００３３】
モニタ統計部１４０は、第１のＣＰＵ２２がアプリケーション（処理）を実行する際、各アプリケーションがＡＰＩ部１５０からＡＰＩを呼び出す手順（ＡＰＩの呼出手順）を監視し、この呼出手順を統計蓄積部６０に蓄積するとともに、判断部１４５に渡す。ここでは、呼出手順（使用手順）には、不正なアプリケーションが実行された場合、変化として現れやすい、ＡＰＩの呼出順序（使用順序）及び呼出頻度（使用頻度）の少なくとも一方が含まれる。なお、呼出手順には、ＡＰＩの呼出時間の間隔等が含まれてもよい。
【００３４】
判断部１４５は、モニタ統計部１４０から受け取ったＡＰＩの呼出手順（呼出順序及び呼出頻度）を元に、統計蓄積部６０を参照し、アプリケーションの正当性、つまり正当なアプリケーションが実行されているか否かを判断する。
【００３５】
例えば、図２において、ＡＰＩの呼出順序として、モニタ統計部１４０に蓄積されている呼出手順の履歴を基に、「ＡＢＣＤ」が正常であることが分かっている場合、判断部１４５は、モニタ統計部１４０によって監視されたＡＰＩの呼出順序から、正当なアプリケーションが実行されていると判断する。一方、このアプリケーションでは行われないような、ＡＰＩの呼出順序が「ＡＢＣＥ」である場合、判断部１４５は、不正なアプリケーションが実行されていると判断する。また、ＡＰＩの呼出順序が「ＡＢＣ」である場合、判断部１４５は、途中で取引を停止した可能性があるとして、疑わしいアプリケーション（グレーゾーンのアプリケーション）であると判断する。疑わしいアプリケーションの場合、操作者は、その後の処理を任意に選択可能である。
【００３６】
ここで、呼出順序が正常であるか否かの判断には、統計蓄積部６０に、アプリケーション毎に蓄積されている呼出順序の履歴が用いられる。例えば、監視された呼出順序が履歴として蓄積されている多くの呼出順序と同じである場合、判断部１４５は、この監視された呼出順序が正常であると判断する。逆に、稀な呼出順序である場合、判断部１４５は、この監視された呼出順序を異常であると判断する。これは、正常な取引処理の多くが最も高い頻度の呼出順序で行われているとの考え方に基づく。
【００３７】
また、履歴として蓄積されている多くのＡＰＩに対する呼出頻度が最大３回（一例）である場合、判断部１４５は、監視された呼出頻度が３回以内であると、この監視された呼出頻度が正常であると判断し、４回以上であると、異常であると判断する。
【００３８】
なお、ここでは、統計蓄積部６０に履歴として蓄積されている多くの呼出手順と同じであるか否かによって、つまり、多くの前歴があるか否かによって呼出手順の正当性を判断したが、正当性の判断方法はこれに限られない。例えば、不正なアプリケーションによる呼出手順をあらかじめ統計蓄積部に登録しておき、この呼出手順と同じである場合、判断部は、異常であると判断してもよい。或いは、正常なアプリケーションによる呼出手順をあらかじめ統計蓄積部に登録しておき、この呼出手順と同じである場合、判断部は、正常であると判断してもよい。このように、あらかじめ決められた呼出手順に則っているか否かによって、判断部１４５が正当性を判断してもよい。
【００３９】
アプリケーション部１６０には、各種のアプリケーションがインストールされている。図２に示す各種のアプリケーションは、決済アプリケーション１６１、業務アプリケーション１６３及び汎用アプリケーション１６５の３つに大別される。図３は、本実施形態の決済端末装置１００において使用可能な各種アプリケーションの一例を示す図である。決済アプリケーション１６１には、磁気クレジット決済アプリケーション、ＩＣクレジット決済アプリケーション、デビット決済アプリケーション、電子マネー決済アプリケーション、ポストペイ決済アプリケーション等が含まれる。
【００４０】
業務アプリケーション１６３には、商品カタログアプリケーション、商品販売（契約）アプリケーション、公共料金収受アプリケーション、販売集計レポートアプリケーション等が含まれる。
【００４１】
汎用アプリケーション１６５には、ブラウザアプリケーション、Ｅｍａｉｌ Ｃｌｉｅｎｔアプリケーション、文書作成アプリケーション、表計算アプリケーション等が含まれる。
【００４２】
図４は、本実施形態の決済端末装置１００のハードウェア部１１０の構成の一例を示す図である。決済端末装置１００のハードウェア部１１０は、第１の情報処理部２１と、セキュアな第２の情報処理部４１とを備える。第１の情報処理部２１は、第１のＣＰＵ（Central Processing Unit）２２と、局所無線通信部２３と、広域無線通信部２５と、表示部２９と、タッチ入力検出部２７とを含む構成である。
【００４３】
また、第１の情報処理部２１は、第１のフラッシュＲＯＭ（Read Only Memory）３１と、第１のＲＡＭ（Random Access Memory）３３と、キー入力部３５と、磁気カードリーダ部１３と、第１のＩＦ（Interface）部３７とを含む構成である。
【００４４】
また、第１の情報処理部２１は、第１のタッチ入力処理部１０７と、第１の表示生成部１０９とを含む構成である。
【００４５】
第１の情報処理部２１では、第１のＣＰＵ２２に各部が接続される。第１のＣＰＵ２２は、第１の情報処理部２１の全体を統括し、例えば、各種制御、処理、設定、判定、決定、確認等を行う。
【００４６】
局所無線通信部２３は、局所無線通信アンテナ２３Ａと接続され、局所無線通信路（図示せず）を用いて、例えば無線ＬＡＮで通信する機能を有する。局所無線通信部２３は、無線ＬＡＮ通信以外の通信（例えばBluetooth（登録商標）通信）を行ってもよい。
【００４７】
広域無線通信部２５は、広域無線通信アンテナ２５Ａと接続され、図示しない広域無線通信路（例えばＷＡＮ（Wide Area Network））を介して通信する機能を有する。広域無線通信路における通信は、例えばＷ−ＣＤＭＡ（Wideband Code Division Multiple Access）、ＵＭＴＳ（Universal Mobile Telecommunications System）、ＣＤＭＡ（Code Division Multiple Access）２０００、ＬＴＥ（Long Term Evolution）等の移動体通信を用いて行われてもよい。
【００４８】
タッチパネルＴＰは、タッチ入力検出部２７の検出面と表示部２９の画面とを重ね合わせた構造を有する。本実施形態では、タッチパネルＴＰは、２つのタッチパネルＴＰ１及びタッチパネルＴＰ２に分割されている。タッチパネルＴＰ１の画面には、非セキュアな表示領域及びセキュアな表示領域が設定される。タッチパネルＴＰ１の検出面には、非セキュアな入力領域が設定される。また、タッチパネルＴＰ２の画面には、セキュアな表示領域が設定される。タッチパネルＴＰ２の検出面には、非セキュアな入力領域が設定される。表示部２９は、タッチパネルＴＰ（図１（Ｂ）参照）の表示を制御する機能を有する。タッチ入力検出部２７はタッチパネルＴＰに対するタッチ入力を検出する機能を有する。
【００４９】
第１のフラッシュＲＯＭ３１は、各種のデータを記憶する機能を有する。第１のフラッシュＲＯＭ３１には、前述した決済アプリケーション１６１、業務アプリケーション１６３、汎用アプリケーション１６５等の種々のアプリケーションが更新可能に記憶される。また、第１のフラッシュＲＯＭ３１には、第１の情報処理部２１を制御するためのプログラムが記憶される。
【００５０】
第１のＲＡＭ３３は、例えば第１の情報処理部２１の動作に伴う演算処理の際に、演算処理の途中において発生する処理データを、一時的に記憶するために用いられるメモリである。
【００５１】
キー入力部３５は、筺体の側面等に配置された入力キー（図示せず）からの入力を受け付ける機能を有する。磁気カードリーダ部１３は、その一部がスリットの内部に配置され、磁気カードの磁気ストライプを読み取る機能を有する。
【００５２】
第１のタッチ入力処理部１０７は、非セキュアな入力領域に入力された操作（ペン入力等）に対応する処理を行う。第１の表示生成部１０９は、非セキュアな表示領域に表示される画像データを生成する。
【００５３】
第１の情報処理部２１及び第２の情報処理部４１は、第１のインターフェース部（以下「第１のＩＦ部」）３７及び第２のインターフェース部（以下「第２のＩＦ部」）４３を介して、互いに接続され、各種のデータやコマンドの受け渡しが行われる。また、第１のＩＦ部３７と第２のＩＦ部４３とは、互いに結合可能である。
【００５４】
第２の情報処理部４１は、セキュア部であり、第２のＩＦ部４３と、第２のＣＰＵ４２と、非接触型ＩＣカードリーダライタ部４５と、第２のフラッシュＲＯＭ５１と、第２のＲＡＭ５３と、第２のタッチ入力処理部１１３と、第２の表示生成部１１５と、ストレージメモリ５５とを含む構成である。
【００５５】
第２の情報処理部４１では、第２のＣＰＵ４２に各部が接続される。第２のＣＰＵ４２は、第２の情報処理部４１の全体を統括し、例えば、各種制御、処理（例えば決済処理）、設定、判定、決定、確認、認証、照合（例えば、ＰＩＮ、署名、の照合）等を行う。
【００５６】
第２のフラッシュＲＯＭ５１は、各種のデータを記憶する機能を有する。また、第２のフラッシュＲＯＭ５１には、各種のデータの他、第２の情報処理部４１を制御するためのプログラムが記憶される。
【００５７】
第２のＲＡＭ５３は、例えば第２の情報処理部４１の動作に伴う演算処理等の際に、演算処理の途中において発生する処理データを、一時的に記憶するために用いられるメモリである。
【００５８】
非接触型ＩＣカードリーダライタ部４５は、ループアンテナ４５Ａを有し、セキュア部である第２の情報処理部４１に備えられ、ＩＣカードの入出力を制御する。
【００５９】
第２のタッチ入力処理部１１３は、セキュアな入力領域に入力された操作（ペン入力等）に対応する処理を行う。第２の表示生成部１１５は、セキュアな表示領域に表示される画像データを生成する。
【００６０】
ストレージメモリ５５は、データを長期保存可能なＳＳＤ（Solid State Drive）等のメモリであり、その記憶領域の一部に統計蓄積部６０を割り当てる。
【００６１】
上述した構成を有する決済端末装置１００の動作について、以下説明する。ここでは、決済アプリケーションの実行に伴ってＡＰＩが呼び出される呼出手順を監視する場合について説明する。
【００６２】
図５は、本実施形態の決済端末装置１００におけるＡＰＩの呼出手順を監視する動作を説明するフローチャートである。
【００６３】
図５において、先ず、決済アプリケーション１６１の処理が開始されるまで待つ（Ｓ１）。決済アプリケーション１６１の処理が開始すると、モニタ統計部１４０は、決済アプリケーション１６１によって呼び出されるＡＰＩの呼出手順を監視する（Ｓ２）。ここでは、呼出手順として、呼出順序が監視される。モニタ統計部１４０は、ＡＰＩの呼出順序の監視結果を判断部１４５に渡す。
【００６４】
判断部１４５は、統計蓄積部６０に蓄積されている呼出手順の履歴を参照する（Ｓ３）。判断部１４５は、例えば、統計蓄積部６０に蓄積されている呼出手順の履歴から、正当な決済アプリケーション１６１の実行に伴って呼び出されるＡＰＩの呼出順序を読み出す。ここでは、前述したように、統計蓄積部６０に蓄積されている、アプリケーション毎の呼出順序のうち、最も多く蓄積されている呼出順序が正常な呼出順序であると想定している。
【００６５】
判断部１４５は、監視されているＡＰＩの呼出順序が蓄積されているＡＰＩの呼出順序と一致するか否かを判断する（Ｓ４）。なお、呼出順序の代わりに、呼出頻度を用いてもよいし、呼出順序と呼出頻度の両方を用いてもよいし、別の呼出手順を用いてもよい。一致する場合、判断部１４５は、決済アプリケーションの実行を許可する（Ｓ５）。一方、一致しない場合、判断部１４５は、決済アプリケーションの実行を停止し（Ｓ６）、警報を発する（Ｓ７）。ここでは、警報として、注意を喚起するメッセージがタッチパネルＴＰの画面に表示されるが、音声が発せられてもよい。
【００６６】
ステップＳ５で決済アプリケーションの実行が許可された後、或いはステップＳ７で警報が発せられた後、モニタ統計部１４０は、監視されたＡＰＩの呼出手順を統計蓄積部６０に蓄積し、統計蓄積部６０に蓄積されているＡＰＩの呼出手順の履歴を更新する（Ｓ８）。この後、本動作は終了する。
【００６７】
ＡＰＩの呼出手順について具体例を示す。図６（Ａ）は、磁気クレジットカードを使用し、ＡＰＩの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す。決済アプリケーション１６１は、始めに、磁気クレジットカードの読み取りを行うＡＰＩを呼び出し（Ｔ１）、操作者に磁気クレジットカードの読み取り動作を行わせる。
【００６８】
決済アプリケーション１６１は、接続先センタを選択するＡＰＩを呼び出し（Ｔ２）、読み取った磁気クレジットカードのブランドに対応する接続先センタを選択する。なお、読み取った磁気クレジットカードが複数のカードブランドを持っている場合には、決済アプリケーション１６１は、複数のカードブランドの中から操作者によって選択されたカードブランドに対応する接続先センタを選択する。決済アプリケーション１６１は、決済金額を入力するＡＰＩを呼び出し（Ｔ３）、操作者に決済金額を入力させる。
【００６９】
決済アプリケーション１６１は、支払回数を入力するＡＰＩを呼び出し（Ｔ４）、操作者に支払回数を入力させる。決済アプリケーション１６１は、手順Ｔ２で選択した接続先センタに与信を要求するＡＰＩを呼び出し（Ｔ５）、接続先センタに対し、与信の要求を送信する。
【００７０】
決済アプリケーション１６１は、接続先センタから与信の結果を受信するＡＰＩを呼び出し（Ｔ６）、与信の結果を受信する。与信が付加されると、決済アプリケーション１６１は、決済処理を行ってレシートを印字するＡＰＩを呼び出し（Ｔ７）、レシートを印字する。
【００７１】
図６（Ｂ）は、ＡＰＩの呼出手順が正常に行われた場合の他の決済処理の動作手順の一例を示す。この決済アプリケーション１６１は、手順Ｔ４で支払回数を入力するＡＰＩを呼び出した後、操作者から取消操作を受け付けたことによって、決済処理を取り消すＡＰＩを呼び出し（Ｔ８）、本決済処理を取り消す。
【００７２】
図６（Ｃ）は、ＡＰＩの呼出手順が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す。図６（Ｃ）に示す不正と疑われる決済アプリケーションは、手順Ｔ５で与信の要求を送信した後、接続先センタから与信の結果を受信することなく、手順Ｔ７でレシートを印字するＡＰＩを呼び出している。図６（Ａ）と比べると、与信の結果を受け取ることなく、レシートの印字が行われる。このように、与信が与えらないことが事前に分かっているような、与信結果の受信を伴わない決済アプリケーションは、不正なアプリケーションと判断される。
【００７３】
図７（Ａ）は、ＩＣクレジットカードを使用し、ＡＰＩの呼出手順が正常に行われた場合の決済処理の動作手順の一例を示す。決済アプリケーション１６１は、始めに、ＩＣクレジットカードの読み取りを行うＡＰＩを呼び出し（Ｔ１Ａ）、操作者にＩＣクレジットカードの読み取り動作を行わせる。
【００７４】
決済アプリケーション１６１は、ＰＩＮ入力を処理するＡＰＩを呼び出し（Ｔ１Ｂ）、操作者によるＰＩＮ入力を受け付ける。このＡＰＩでは、ＰＩＮの再入力は最大３回に制限されている。この制限値である３回は、あらかじめ登録されてもよいし、過去の履歴から自動的に設定されてもよい。この後、ＡＰＩの呼出手順は、図６（Ａ）と同様に行われる。
【００７５】
図７（Ｂ）は、ＡＰＩの呼出頻度が異常であり、不正と疑われる場合の決済処理の動作手順の一例を示す。不正と疑われるアプリケーションは、ＰＩＮ入力を受け付けるＡＰＩを４回以上呼び出している。このＡＰＩの呼出手順が異常であると判断された場合、このアプリケーションの実行は停止される。なお、停止に限らず、任意の処理が行われてもよい。
【００７６】
図７（Ｃ）は、ＡＰＩの呼出頻度が異常であり、不正と疑われる場合の他の決済処理の動作手順の一例を示す。即ち、不正と疑われるこのアプリケーションは、カードの読み取りを行うＡＰＩを短時間に複数回（ここでは、１０分間に３０回超）行っている。この場合、偽造カードの所有者又は正当なカードの所有者ではない第三者による不正な決済が、短時間に複数回行われている状況が想定される。このＡＰＩの呼出が異常であると判断された場合、同様に、このアプリケーションの実行は停止される。なお、停止に限らず、任意の処理が行われてもよい。
【００７７】
以上により、本実施形態の決済端末装置１００では、複数のＡＰＩ１５１〜１５５は、決済アプリケーション１６１の実行に伴って呼び出され、それぞれ個別の機能を有する。モニタ統計部１４０は、決済アプリケーション１６１の実行に伴って呼び出されるＡＰＩの呼出手順を監視する。統計蓄積部６０は、ＡＰＩの呼出手順の履歴を蓄積する。判断部１４５は統計蓄積部６０に蓄積されたＡＰＩの呼出手順の履歴を基に、モニタ統計部１４０で監視されるＡＰＩの呼出手順の正当性を判断する。
【００７８】
これにより、決済端末装置１００は、ＡＰＩの呼出手順が異常であると判断された場合、決済端末装置１００は、決済アプリケーション１６１の実行を停止できる。従って、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるＡＰＩの呼び出し順序の監視により、疑義のある取引等の処理を抑止することができるので、認証情報等のセキュリティを確保することができる。特に、入力されるＰＩＮのセキュリティを確保することができる。更に、決済端末装置１００は、悪意のあるアプリケーションが不正な振る舞いを行うことにより発生する、加盟店やアクワイヤラへの損害（例えばＰＩＮ・署名の盗み出し・改ざん、不正な取引）を低減することができる。
【００７９】
また、監視される呼出手順には、不正なアプリケーションが実行された場合に変化として現れやすいＡＰＩの呼出順序及び呼出頻度の少なくとも一方が含まれるので、決済端末装置１００は、不正なアプリケーションによる処理を発見し易くすることができる。
【００８０】
また、決済端末装置１００は、ＡＰＩの呼出手順が異常である場合、アプリケーションの実行を停止させることができるので、不正なアプリケーションが継続して行われることを防ぐことができる。
【００８１】
また、決済端末装置１００は、ＡＰＩの呼出手順が異常であった場合、所定の警報を報知することができるので、操作者に不正なアプリケーションによる処理の実行を気付かせることができる。
【００８２】
また、決済端末装置１００は、呼出手順が正常であった場合、アプリケーションによる処理の実行を許可するので、操作者が所望するアプリケーションによる処理の実行を継続することができる。
【００８３】
また、決済端末装置１００は、監視された呼出手順を統計蓄積部に蓄積するので、ＡＰＩの呼出手順の履歴を最新状態に更新することができる。
【００８４】
以上、図面を参照しながら各種の実施形態について説明したが、本発明はかかる例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【００８５】
例えば、上記実施形態では、個別機能部として、アプリケーションによって呼び出されるＡＰＩ（Application Programming Interface)を例示したが、個別の機能を有するタイマ、カウンタ、プリンタ等のハードウェア資源であってもよい。
【産業上の利用可能性】
【００８６】
本発明は、セキュアな部分と非セキュアな部分とが共存する場合であっても、アプリケーションの実行時に使用されるＡＰＩの呼び出し順序の監視により、疑義のある取引等の処理を抑止し、認証情報等のセキュリティを確保する決済処理装置として有用である。
【符号の説明】
【００８７】
３  決済センタ
４  データ処理装置
５  決済システム
８  加盟店
１３  磁気カードリーダ部
２１  第１の情報処理部
２２  第１のＣＰＵ
２３Ａ、２５Ａ、４５Ａ  アンテナ
２３  局所無線通信部
２５  広域無線通信部
２７  タッチ入力検出部
２９  表示部
３１  第１のフラッシュＲＯＭ
３３  第１のＲＡＭ
３５  キー入力部
３７  第１のＩＦ部
４１  第２の情報処理部
４２  第２のＣＰＵ
４３  第２のＩＦ部
４５  非接触型ＩＣカードリーダライタ部
５１  第２のフラッシュＲＯＭ
５３  第２のＲＡＭ
５５  ストレージメモリ
６０  統計蓄積部
１００  決済端末装置
１０７  第１のタッチ入力処理部
１０９  第１の表示生成部
１１０  ハードウェア部
１１３  第２のタッチ入力処理部
１１５  第２の表示生成部
１２０  オペレーティングシステム（ＯＳ）
１３０  画面ＵＩアプリケーション
１４０  モニタ統計部
１４５  判断部
１５０  ＡＰＩ部
１５１〜１５５  ＡＰＩ
１６０  アプリケーション部
１６１  決済アプリケーション
１６３  業務アプリケーション
１６５  汎用アプリケーション
ＴＰ、ＴＰ１、ＴＰ２  タッチパネル
【図１】
0006025125.tif 000002
【図２】
0006025125.tif 000003
【図３】
0006025125.tif 000004
【図４】
0006025125.tif 000005
【図５】
0006025125.tif 000006
【図６】
0006025125.tif 000007
【図７】
0006025125.tif 000008