特許 7436847 情報処理装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-14

(45)【発行日】2024-02-22

(54)【発明の名称】情報処理装置

(51)【国際特許分類】

   G06F 21/12 20130101AFI20240215BHJP

   G06F 21/56 20130101ALI20240215BHJP

   G06F 21/55 20130101ALI20240215BHJP

   G06F 11/07 20060101ALI20240215BHJP

【ＦＩ】

G06F21/12 360

G06F21/56 360

G06F21/55 320

G06F11/07 151

G06F11/07 190

【請求項の数】 3

(21)【出願番号】P 2020158707

(22)【出願日】2020-09-23

(65)【公開番号】P2022052359

(43)【公開日】2022-04-04

【審査請求日】2023-03-27

(73)【特許権者】

【識別番号】501428545

【氏名又は名称】株式会社デンソーウェーブ

(74)【代理人】

【識別番号】100106149

【弁理士】

【氏名又は名称】矢作 和行

(74)【代理人】

【識別番号】100121991

【弁理士】

【氏名又は名称】野々部 泰平

(74)【代理人】

【識別番号】100145595

【弁理士】

【氏名又は名称】久保 貴則

(72)【発明者】

【氏名】葛谷 匡昭

【審査官】中里 裕正

(56)【参考文献】

【文献】特開２０１３－０９３０５８（ＪＰ，Ａ）

【文献】特開２０１３－２４７６６４（ＪＰ，Ａ）

【文献】特開２０１１－０３４５５２（ＪＰ，Ａ）

【文献】特開２００９－２０５４７２（ＪＰ，Ａ）

【文献】特開２００８－０８４２４６（ＪＰ，Ａ）

【文献】特開２００５－２２９６４２（ＪＰ，Ａ）

【文献】特開２００１－３１８８１０（ＪＰ，Ａ）

【文献】特開平０５－０６１７３２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／１２

Ｇ０６Ｆ １１／０７

Ｇ０６Ｆ ２１／５５

Ｇ０６Ｆ ２１／５６

(57)【特許請求の範囲】

【請求項1】

第１アプリケーションプログラムが実行するプロセスが、第２アプリケーションプログラムが実行するプロセスと連携するために、
カーネル層で動作し、前記第１アプリケーションプログラムが前記第２アプリケーションプログラムに要求する処理を特定する情報であって、記述形式がプロセス間通信型となっている要求処理特定情報を、前記第２アプリケーションプログラムが実行するプロセスに送信するプロセス間通信部（２１）と、
アプリケーション層と前記カーネル層との間のフレームワーク層で動作し、前記第１アプリケーションプログラムが送信した情報をもとに生成された前記要求処理特定情報を取得して前記プロセス間通信部に送信する第１プロセス側通信部（２２）と、
前記フレームワーク層で動作し、前記プロセス間通信部が送信した前記要求処理特定情報を受信し、受信した前記要求処理特定情報を前記第２アプリケーションプログラムに送信する第２プロセス側通信部（２３）とを備えた情報処理装置（１０）であって、
前記第２プロセス側通信部および前記第１プロセス側通信部の少なくとも一方は、取得した前記要求処理特定情報をログに残すようになっており、
実行が要求されたことを検出する必要がある処理について、前記要求処理特定情報と、前記要求処理特定情報の前記アプリケーション層における記述とを対応付けた対応リストを記憶する記憶部（１４）と、
前記ログを取得する取得部（Ｓ１０）と、
前記取得部が取得したログと、前記記憶部に記憶されている前記対応リストとをもとに、処理が要求されたことを検出する必要があるアプリケーションプログラムである検出対象アプリケーションプログラムに処理が要求されたことを検出する検出部（Ｓ２０）とを備える、情報処理装置。

【請求項2】

請求項１に記載の情報処理装置であって、
前記第１プロセス側通信部は、スタックトレースを取得して前記ログに記憶するようになっており、
前記検出部が検出した前記検出対象アプリケーションプログラムと、前記ログに記憶されている前記スタックトレースとをもとに、前記検出対象アプリケーションプログラムに処理を要求したアプリケーションプログラムを特定するプログラム特定部（Ｓ３０）を備える、情報処理装置。

【請求項3】

請求項１または２に記載の情報処理装置であって、
前記第２プロセス側通信部および前記第１プロセス側通信部が両方とも、取得した前記要求処理特定情報をログに残すようになっており、
前記検出部は、前記第２プロセス側通信部が取得した前記要求処理特定情報がログにあるが、同じ前記要求処理特定情報を前記第１プロセス側通信部が取得したことが前記ログにない場合、不正処理が発生したと判断する、情報処理装置。

【発明の詳細な説明】

【技術分野】

【0001】

ユーザが意図していないアプリケーションプログラムに処理が要求されたことを検出できる情報処理装置に関する。

【背景技術】

【0002】

特許文献１には、ユーザが認識していない動作が、ユーザに気づかれないままに行われることを防止する装置が開示されている。特許文献１に開示された装置は、対象とするＡＰＩ（Application Programing Interface）をフックする。

【0003】

すなわち、特許文献１に開示された装置は、対象とするＡＰＩに、そのＡＰＩを実行しようとする動作を検出する処理を組み込む。そして、対象とするＡＰＩを実行しようとする動作を検出した場合、そのＡＰＩが実行される状況を解析する。解析の結果、ユーザが認識していない動作により情報が送信されると判定すると、ユーザに通知する等の処理を行う。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１３－１４５５１１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

特許文献１の技術を適用するためには、ソースコードが公開されている必要がある。したがって、ソースコードが公開されていないアプリケーションプログラム（以下、アプリケーション）に対しては、特許文献１の技術を適用することができない。

【0006】

そこで、ソースコードが公開されていないアプリケーションを利用する場合でも、ユーザの意図していないアプリケーションに処理が要求されたことを検出できるようにすることが望まれる。

【0007】

本開示は、この事情に基づいて成されたものであり、その目的とするところは、ユーザの意図していないアプリケーションに処理が要求されたことを検出できる情報処理装置を提供することにある。

【課題を解決するための手段】

【0008】

上記目的は独立請求項に記載の特徴の組み合わせにより達成され、また、下位請求項は更なる有利な具体例を規定する。特許請求の範囲に記載した括弧内の符号は、一つの態様として後述する実施形態に記載の具体的態様との対応関係を示すものであって、開示した技術的範囲を限定するものではない。

【0009】

上記目的を達成するための１つの開示は、
第１アプリケーションプログラムが実行するプロセスが、第２アプリケーションプログラムが実行するプロセスと連携するために、
カーネル層で動作し、第１アプリケーションプログラムが第２アプリケーションプログラムに要求する処理を特定する情報であって、記述形式がプロセス間通信型となっている要求処理特定情報を、第２アプリケーションプログラムが実行するプロセスに送信するプロセス間通信部（２１）と、
アプリケーション層とカーネル層との間のフレームワーク層で動作し、第１アプリケーションプログラムが送信した情報をもとに生成された要求処理特定情報を取得してプロセス間通信部に送信する第１プロセス側通信部（２２）と、
フレームワーク層で動作し、プロセス間通信部が送信した要求処理特定情報を受信し、受信した要求処理特定情報を第２アプリケーションプログラムに送信する第２プロセス側通信部（２３）とを備えた情報処理装置（１０）であって、
第２プロセス側通信部および第１プロセス側通信部の少なくとも一方は、取得した要求処理特定情報をログに残すようになっており、
実行が要求されたことを検出する必要がある処理について、要求処理特定情報と、要求処理特定情報のアプリケーション層における記述とを対応付けた対応リストを記憶する記憶部（１４）と、
ログを取得する取得部（Ｓ１０）と、
取得部が取得したログと、記憶部に記憶されている対応リストとをもとに、処理が要求されたことを検出する必要があるアプリケーションプログラムである検出対象アプリケーションプログラムに処理が要求されたことを検出する検出部（Ｓ２０）とを備える。

【0010】

この情報処理装置は、ユーザの意図していないアプリケーションに処理が要求されたことを検出するために、プロセス間通信において情報を取得する。すなわち、第１プロセス側通信部および第２プロセス側通信部の少なくとも一方は、取得した要求処理特定情報をログに残すようになっている。また、実行が要求されたことを検出する必要がある処理について、要求処理特定情報と、要求処理特定情報のアプリケーション層における記述とを対応付けた対応リストを記憶している。そして、ログに、対応リストにある要求処理特定情報が記憶されている場合に、検出対象アプリケーションプログラムに処理が要求されたことを検出する。

【0011】

このようにして検出対象アプリケーションプログラムに処理が要求されたことを検出するので、ソースコードが公開されていない検出対象アプリケーションプログラムであっても、その検出対象アプリケーションプログラムに処理が要求されたかどうかを検出することができる。

【0012】

また、この情報処理装置は、好ましくは、
第１プロセス側通信部は、スタックトレースを取得してログに記憶するようになっており、
検出部が検出した検出対象アプリケーションプログラムと、ログに記憶されているスタックトレースとをもとに、検出対象アプリケーションプログラムに処理を要求したアプリケーションプログラムを特定するプログラム特定部（Ｓ３０）を備える。

【0013】

スタックトレースには、検出対象アプリケーションに処理を要求したアプリケーションも記録されているので、このようにすれば、検出対象アプリケーションプログラムに処理を要求したアプリケーションプログラムも特定できる。たとえば、検出対象アプリケーションプログラムに処理を要求したアプリケーションプログラムをユーザに通知するようにすれば、ユーザは、どのアプリケーションプログラムが検出対象アプリケーションプログラムに処理を要求したのかも知ることができる。

【0014】

また、この情報処理装置は、好ましくは、
第２プロセス側通信部および第１プロセス側通信部が両方とも、取得した要求処理特定情報をログに残すようになっており、
検出部は、第２プロセス側通信部が取得した要求処理特定情報がログにあるが、同じ要求処理特定情報を第１プロセス側通信部が取得したことがログにない場合、不正処理が発生したと判断する。

【0015】

技術的には、第１プロセス側通信部を経由せずに、プロセス間通信部に要求処理特定情報を送信することができる。しかし、このような処理を実行することは不正な処理である。そこで、上記のようにして、検出部は、不正な処理が実行されたことを検出する。

【図面の簡単な説明】

【0016】

【図1】実施形態となる光学情報読み取り装置１０の外観図。

【図2】光学情報読み取り装置１０の構成を示すブロック図。

【図3】対応リストを説明する図。

【図4】情報処理部１７が実行するプログラム階層構造を示す図。

【図5】不正検出部１９が実行する処理を示す図。

【図6】Ｓ１０で取得するログの一例を示す図。

【発明を実施するための形態】

【0017】

以下、実施形態を図面に基づいて説明する。図１は、実施形態となる光学情報読み取り装置１０の外観図である。光学情報読み取り装置１０は情報処理装置の一例である。光学情報読み取り装置１０は、バーコード、二次元コードなどの情報コードを光学的に読み取る業務用の装置である。光学情報読み取り装置１０は、スマートフォン型であり、表示部１１を備えている。表示部１１には、操作画面、情報コードをデコードして得られた情報などが表示される。

【0018】

〔光学情報読み取り装置１０の構成〕
次に、光学情報読み取り装置１０の構成を説明する。図２に光学情報読み取り装置１０の構成をブロック図にて示している。光学情報読み取り装置１０は、表示部１１、通信部１２、カメラ１３、記憶部１４、操作部１６、情報処理部１７を備えている。

【0019】

表示部１１には、前述したように、操作画面、情報コードをデコードして得られた情報などが表示される。通信部１２は、光学情報読み取り装置１０の外部と無線通信する。通信部１２は、近距離無線通信回路、広域無線通信回路の一方または両方を備える。

【0020】

カメラ１３は、情報コードを撮影するためのものである。なお、情報コードを撮影しやすくするために、光学情報読み取り装置１０は照明を備えていてもよい。記憶部１４は、フラッシュメモリなどの不揮発性メモリである。記憶部１４には、情報処理部１７が実行するプログラムが記憶されている。記憶されているプログラムの１つに不正検出プログラム１５がある。

【0021】

また、記憶部１４には、図３に示す対応リストも記憶されている。この対応リストは、検出対象ＡＰＩについて、アプリケーション層における記述形式と、ＡＩＤＬによる記述形式に変換された記述であるＩ／Ｆディスクリプタとコードとを対応付けたリストである。なお、検出対象ＡＰＩは検出対象アプリケーションプログラムであり、ＡＩＤＬによる記述形式はプロセス間通信型の記述形式である。

【0022】

アプリケーション層における記述形式はＪＡＶＡ（登録商標）である。検出対象ＡＰＩは、処理が要求されたことを検出する必要があるアプリケーションが備えるＡＰＩである。ユーザは、意図しないアプリケーションに処理が要求されたことを知るために、そのアプリケーションを検出対象ＡＰＩとする。なお、検出対象ＡＰＩと記載する場合、そのＡＰＩのアプリケーション層における記述を意味する。

【0023】

対応リストの作り方を説明する。ソースコードが公開されている検出対象ＡＰＩは、ソースコードを解析して対応付けを行うことができる。ソースコードが公開されていない検出対象ＡＰＩは、この光学情報読み取り装置１０で検出対象ＡＰＩを実行する。ログから検出対象ＡＰＩが実行されるときに出力されるバインダ部２０のＩ／Ｆディスクリプタとコードを取得できるので、検出対象ＡＰＩと、Ｉ／Ｆディスクリプタおよびコードとを対応付けることができる。

【0024】

操作部１６は、表示部１１の表示面に重畳されたタッチパネルなどであり、ユーザが種々の情報を光学情報読み取り装置１０に入力する際に操作する。なお、操作部１６の一部または全部がメカニカルキーであってもよい。

【0025】

情報処理部１７は、プロセッサ、不揮発性メモリ、ＲＡＭ、Ｉ／Ｏ、およびこれらの構成を接続するバスラインなどを備えたコンピュータにより実現できる。情報処理部１７は、表示部１１、通信部１２、カメラ１３、記憶部１４、操作部１６と通信可能に接続されており、これらを制御する。

【0026】

プロセッサが、ＲＡＭの一時記憶機能を利用しつつ、不揮発性メモリ、あるいは、記憶部１４に記憶されたプログラムを実行することで、情報処理部１７は、読み取り処理部１８、不正検出部１９として作動する。これらの作動が実行されることは、プログラムに対応する方法が実行されることを意味する。

【0027】

読み取り処理部１８は、カメラ１３が撮影した画像を表している画像データを取得し、その画像データを画像解析して、画像に含まれている情報コードに格納されている符号を復号する。

【0028】

不正検出部１９は、情報処理部１７が備えるプロセッサが不正検出プログラム１５を実行することで実現する。不正検出部１９は図５を用いて後述する。

【0029】

図４には、情報処理部１７が実行するプログラム階層構造を示している。実施形態の光学情報読み取り装置１０はオペレーティングシステムとしてＡＮＤＲＯＩＤ（登録商標）を使用している。このオペレーティングシステムにおいては、プロセス間通信が可能である。

【0030】

プロセス間通信は、あるプロセス（第１プロセスとする）と別のプロセス（第２プロセスとする）とが連携する場合に、第１プロセスが第２プロセスに要求する処理を特定する情報（以下、要求処理特定情報）が、カーネル層を経由して第２プロセスに伝達される仕組みである。なお、プロセスとはプログラムの実行単位である。

【0031】

図４には、図示の便宜上、第１プロセスと第２プロセスをそれぞれ１つずつしか記載していないが、第１プロセスおよび第２プロセスは複数存在する。第１プロセスを実行するアプリケーションを第１アプリケーションＡＰＰ１とし、第２プロセスを実行するアプリケーションを第２アプリケーションＡＰＰ２とする。

【0032】

図４に示している第２アプリケーションＡＰＰ２は、ＡＰＩを備えている。ＡＰＩは、第２アプリケーションＡＰＰ２が他のアプリケーションに対して処理の少なくとも一部を提供するためのインターフェースである。

【0033】

プロセス間通信を実現するために、情報処理部１７は、バインダ部２０を備えている。バインダ部２０は、第１プロセスと第２プロセスとを結びつける機能を有する。バインダ部２０は、プロセス間通信を実現する一つの手段である。バインダ部２０は、第１プロセスが出力した信号を、アプリケーション層から一旦、カーネル層に伝達し、さらに、カーネル層から第２プロセスに伝達する。バインダ部２０は、カーネル層で動作するプロセス間通信部２１と、中間層であるフレームワーク層で動作するクライアント側通信部２２およびサービス側通信部２３を備える。なお、クライアント側通信部２２は第１プロセス側通信部に相当し、サービス側通信部２３は第２プロセス側通信部に相当する。

【0034】

また、情報処理部１７は、ＡＩＤＬ層で動作するクライアント側変換部２４とサービス側変換部２５を備える。第１アプリケーションＡＰＰ１は、第２アプリケーションＡＰＰ２に処理を要求する場合、サービスの提供を受けたい第２アプリケーションＡＰＰ２のＡＰＩを特定する情報と、そのサービスに要求する処理を示している情報を出力する。

【0035】

第１アプリケーションＡＰＰ１が出力する上記情報は、ＡＩＤＬ層で動作するクライアント側変換部２４に受信される。ＡＩＤＬは、ＡＮＤＲＯＩＤインターフェース定義言語を意味しており、プロセス間通信のための言語である。クライアント側変換部２４は、第１アプリケーションＡＰＰ１から受信した情報をＩ／Ｆディスクリプタとコードに変換してクライアント側通信部２２に送信する。Ｉ／Ｆディスクリプタとコードは、第１アプリケーションＡＰＰ１が第２アプリケーションＡＰＰ２に要求する処理を特定する情報であって、プロセス間通信の記述形式に変換された情報である。この情報が要求処理特定情報である。

【0036】

クライアント側通信部２２は、クライアント側変換部２４が送信したＩ／Ｆディスクリプタとコードを受信して、プロセス間通信部２１に送信する。プロセス間通信部２１は、Ｉ／Ｆディスクリプタとコードをどの第２プロセスが実行すべきかを決定する。そして、サービス側通信部２３に、Ｉ／Ｆディスクリプタとコード、および、それらを送信する第２プロセスを特定する情報を送信する。

【0037】

サービス側通信部２３は、プロセス間通信部２１から受信したＩ／Ｆディスクリプタとコードをサービス側変換部２５に送信する。サービス側変換部２５は、受信したＩ／Ｆディスクリプタとコードを、第１アプリケーションＡＰＰ１が出力した記述形式に戻して、第２アプリケーションＡＰＰ２のＡＰＩに送信する。

【0038】

ここまで説明したバインダ部２０、クライアント側変換部２４、サービス側変換部２５の処理は、一般的なプロセス間通信で行われる処理である。

【0039】

さらに、この実施形態のクライアント側通信部２２およびサービス側通信部２３は、以下の処理も実行する。クライアント側通信部２２は、一般的なクライアント側通信部に修正が加えられ、クライアント側通信部２２が取得したＩ／Ｆディスクリプタとコードを、取得した主体とともにログに残すようになっている。サービス側通信部２３も、一般的なサービス側通信部に修正が加えられ、取得したＩ／Ｆディスクリプタとコードを取得した主体とともにログに残すようになっている。

【0040】

加えて、クライアント側通信部２２は、Ｉ／Ｆディスクリプタとコードを受信してプロセス間通信部２１に送信するときに、スタックトレースを取得し、取得したスタックトレースもログに残すようになっている。スタックトレースは、現在のコードの位置まで経てきた関数を示す情報である。

【0041】

図５に不正検出部１９が実行する処理を示す。図５に示す処理は、一定周期で実行する。Ｓ１０は取得部としての処理であり、ログを取得する。Ｓ２０は検出部としての処理である。Ｓ２０は、Ｓ２１からＳ２６を備える。Ｓ２１では、サービス側通信部２３についてのログがあるか否かを判断する。Ｓ２１の判断結果がＮＯであればＳ１０に戻り、ＹＥＳであればＳ２２に進む。

【0042】

図６には、Ｓ１０で取得するログの一例を示している。図６に示すログには、下から２行目に、”Binder:execTransact()”が記述されている。これは、サービス側通信部２３が実行するメソッドである。したがって、Ｓ１０で取得したログが図６に示すログであった場合には、Ｓ２１の判断結果がＹＥＳになりＳ２２に進む。Ｓ２１の判断結果がＹＥＳである場合、プロセス間通信が実行されたことが分かる。

【0043】

Ｓ２２では、クライアント側通信部２２についてのログがあるか否かを判断する。この判断を実行する理由は、技術的にクライアント側通信部２２を経由せずにクライアント側変換部２４からプロセス間通信部２１へＩ／Ｆディスクリプタとコードを送信してしまうことが可能だからである。技術的には可能であっても、クライアント側通信部２２を経由しない処理は不正である。したがって、Ｓ２２の判断結果がＮＯであればＳ２６に進み、不正処理が発生したとする。一方、Ｓ２２の判断結果がＹＥＳであればＳ２３に進む。

【0044】

図６に示すログには、１行目に”BinderProxy”が記述されている。”BinderProxy”は、クライアント側通信部２２を意味している。したがって、Ｓ１０で取得したログが図６に示すログであった場合には、Ｓ２２の判断結果がＹＥＳになりＳ２３に進む。

【0045】

Ｓ２３では、ログから、検出対象ＡＰＩのＩ／Ｆディスクリプタとコードを検索する。Ｓ２４では、Ｓ２３での検索の結果、ログに検出対象ＡＰＩのＩ／Ｆディスクリプタとコードがあるか否かを判断する。Ｓ２４の判断結果がＮＯであればＳ１０に戻り、Ｓ２４の判断結果がＹＥＳであればＳ２５に進む。

【0046】

図６に示すログには、１行目に、図３に示す表の１行目のＩ／Ｆディスクリプタとコードが記述されている。したがって、Ｓ１０で取得したログが図６に示すログであった場合には、Ｓ２４の判断結果がＹＥＳになり、Ｓ２５に進む。Ｓ２５では、検出対象ＡＰＩに処理が要求されたことを検出したとする。続いてＳ２６に進む。

【0047】

Ｓ２６は、Ｓ２５を実行した場合に加え、Ｓ２２の判断結果がＮＯであった場合にも実行する。そのＳ２６では、前述したように、不正処理が発生したとする。

【0048】

続いてプログラム特定部であるＳ３０を実行する。Ｓ３０はＳ３１とＳ３２を備える。Ｓ３１では、検出対象ＡＰＩのスタックトレースのログを確認する。図６では、３行目からの破線の四角で囲んである部分がスタックトレースのログである。この部分において、Ｓ２５で検出した検出対象ＡＰＩのアプリケーション層における記述が存在している部分を確認することになる。

【0049】

Ｓ３２では、検出対象ＡＰＩを実行したモジュールを特定する。具体的には、スタックトレースのログにある、Ｓ２５で検出した検出対象ＡＰＩの次の行に記載されているモジュールが検出対象ＡＰＩを実行したモジュールであると決定する。

【0050】

図６の例では、Ｓ２５で検出した検出対象ＡＰＩは、スタックトレースのログの［３］に記述されている。したがって、次の［４］に記述されている”com.company.inventoryprivatedata”モジュールの”Utils”クラスの”utilMethod”メソッドから、検出対象ＡＰＩである”getLine1Number”メソッドが実行されたことがわかる。なお、メソッドは、処理をまとめたものであり、アプリケーションの一部である。

【0051】

Ｓ４０では、検出対象のＡＰＩに処理が要求されたこと、および、検出対象ＡＰＩに処理を要求したメソッドを、表示部１１に表示することでユーザに通知する。

【0052】

［実施形態のまとめ］
以上、説明した本実施形態では、クライアント側通信部２２およびサービス側通信部２３は、取得したＩ／Ｆディスクリプタとコードをログに残すようになっている。また、この光学情報読み取り装置１０は、Ｉ／Ｆディスクリプタとコードと、検出対象ＡＰＩとを対応づける対応リスト（図３）を記憶している。そして、不正検出部１９は、ログを取得し（Ｓ１０）、取得したログに、上記対応リストにあるＩ／Ｆディスクリプタとコードがあるかどうかを確認することで、検出対象ＡＰＩに処理が要求されたかどうかを検出する（Ｓ２０）。

【0053】

このようにして検出対象ＡＰＩに処理が要求されたかどうかを確認するので、ソースコードが公開されていない検出対象ＡＰＩであっても、その検出対象ＡＰＩに処理が要求されたかどうかを検出することができる。

【0054】

さらに、クライアント側通信部２２は、スタックトレースを取得してログに記憶するようになっている。不正検出部１９は、処理が要求されたことを検出した検出対象ＡＰＩと、ログに記憶されているスタックトレースとから、検出対象ＡＰＩを実行したアプリケーションを特定する（Ｓ３０）。そして、検出対象ＡＰＩを実行したアプリケーションも、ユーザに通知する（Ｓ４０）。したがって、ユーザは、検出対象ＡＰＩに処理が要求されたことだけでなく、どのアプリケーションが検出対象ＡＰＩに処理を要求したのかも知ることができる。

【0055】

さらに、不正検出部１９は、同じＩ／Ｆディスクリプタとコードについて、サービス側通信部２３のログがあるがクライアント側通信部２２のログがあるかどうかも判断している（Ｓ２２）。そして、サービス側通信部２３のログがあるがクライアント側通信部２２のログがない場合、不正処理が発生したと判断する（Ｓ２６）。したがって、クライアント側通信部２２を経由せずにプロセス間通信を行おうとする不正な処理を検出することもできる。

【0056】

以上、実施形態を説明したが、開示した技術は上述の実施形態に限定されるものではなく、次の変形例も開示した範囲に含まれ、さらに、下記以外にも要旨を逸脱しない範囲内で種々変更して実施できる。なお、以下の説明において、それまでに使用した符号と同一番号の符号を有する要素は、特に言及する場合を除き、それ以前の実施形態における同一符号の要素と同一である。また、構成の一部のみを説明している場合、構成の他の部分については先に説明した実施形態を適用できる。

【0057】

＜変形例１＞
実施形態では、クライアント側通信部２２とサービス側通信部２３がともに、取得したＩ／Ｆディスクリプタとコードをログに残していた。しかし、Ｓ２２の判断が必要ない場合には、サービス側通信部２３のみ、取得したＩ／Ｆディスクリプタとコードをログに残してもよい。

【0058】

また、クライアント側通信部２２とサービス側通信部２３は、同じ情報をログに残す。したがって、クライアント側通信部２２のみ、取得したＩ／Ｆディスクリプタとコードをログに残してもよい。この場合、Ｓ２１では、クライアント側通信部２２のログがあるかどうかを判断する。

【0059】

＜変形例２＞
検出対象ＡＰＩが実行されたことを検出するだけでよく、検出対象ＡＰＩに処理を要求したアプリケーションを特定する必要がない場合、Ｓ３０の処理を省略することができる。

【0060】

＜変形例３＞
不正処理が発生したことを検出した場合の処理は、表示部１１への通知に限られない。不正処理が発生したことを検出した場合の処理はサーバにその旨を送信したり、不正処理を要求したアプリケーションとの通信を制限したりする処理であってもよい。

【符号の説明】

【0061】

１０：光学情報読み取り装置（情報処理装置） １１：表示部 １２：通信部 １３：カメラ １４：記憶部 １５：不正検出プログラム １６：操作部 １７：情報処理部 １８：読み取り処理部 １９：不正検出部 ２０：バインダ部 ２１：プロセス間通信部 ２２：クライアント側通信部（第１プロセス側通信部） ２３：サービス側通信部（第２プロセス側通信部） ２４：クライアント側変換部 ２５：サービス側変換部 Ｓ１０：取得部 Ｓ２０：検出部 Ｓ３０：プログラム特定部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】