特許 6404154 リクエスト処理装置、その方法およびプログラム

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

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

(11)【特許番号】6404154

(24)【登録日】2018年9月21日

(45)【発行日】2018年10月10日

(54)【発明の名称】リクエスト処理装置、その方法およびプログラム

(51)【国際特許分類】

   G06F 9/54 20060101AFI20181001BHJP

   G06F 13/00 20060101ALI20181001BHJP

【ＦＩ】

   G06F9/54 B

   G06F13/00 353R

【請求項の数】9

【全頁数】12

(21)【出願番号】特願2015-57963(P2015-57963)

(22)【出願日】2015年3月20日

(65)【公開番号】特開2016-177602(P2016-177602A)

(43)【公開日】2016年10月6日

【審査請求日】2017年11月22日

(73)【特許権者】

【識別番号】000010098

【氏名又は名称】アルプス電気株式会社

(74)【代理人】

【識別番号】100108006

【弁理士】

【氏名又は名称】松下 昌弘

(74)【代理人】

【識別番号】100085453

【弁理士】

【氏名又は名称】野▲崎▼ 照夫

(74)【代理人】

【識別番号】100135183

【弁理士】

【氏名又は名称】大窪 克之

(74)【代理人】

【識別番号】100120204

【弁理士】

【氏名又は名称】平山 巌

(72)【発明者】

【氏名】兼國 雄介

(72)【発明者】

【氏名】村田 淳

(72)【発明者】

【氏名】高橋 将長

【審査官】 大桃 由紀雄

(56)【参考文献】

【文献】 特開平０９−１９８３４７（ＪＰ，Ａ）

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

【文献】 特開平０３−２３７５４０（ＪＰ，Ａ）

【文献】 国際公開第２００８／１０５０９９（ＷＯ，Ａ１）

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

Ｇ０６Ｆ ９／５４

Ｇ０６Ｆ １３／００

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

【請求項1】

アプリケーションプログラムからのリクエストを一時的に保存するキューと、
前記キューを管理する管理部と
を有するリクエスト処理装置であって、
前記管理部は、
前記キューに保存された前記リクエストがデキューされて当該リクエストを処理するファームウェアに送られると、その旨を示すデキュー通知を前記アプリケーションプログラムに送り、
前記ファームウェアからのリクエストに応じてハードウェアモジュールが処理を行い、当該ハードウェアモジュールに複数のプロファイルが規定されている場合に、
前記複数のプロファイル毎に前記キューが設けられ、
前記管理部は、前記複数のプロファイル毎に、当該プロファイルに対応した前記キューを管理することを特徴とするリクエスト処理装置。

【請求項2】

前記管理部は、
前記ファームウェアから前記リクエストに応じた処理が終了した旨の通知を受けると、その旨を示す処理終了通知を前記アプリケーションプログラムに提供することを特徴とする請求項１に記載のリクエスト処理装置。

【請求項3】

前記管理部は、ＡＰＩであり、
前記アプリケーションプログラムと、前記管理部の処理を記述した管理プログラムと、前記キューとが保存されるメモリと、
前記アプリケーションプログラムおよび前記管理プログラムを実行する処理部とを備えることを特徴とする請求項１または請求項２に記載のリクエスト処理装置。

【請求項4】

前記アプリケーションプログラムは、前記キューに前記リクエストを提供してから第１の所定時間以内に前記デキュー通知を受けない場合に、第１のタイムアウト処理を行うことを特徴とする請求項１〜３のいずれかに記載のリクエスト処理装置

【請求項5】

前記管理部は、前記ファームウェアから前記リクエストに応じた処理が終了した旨の通知を受けると、その旨を示す処理終了通知を前記アプリケーションプログラムに提供し、
前記アプリケーションプログラムは、前記デキュー通知を受けてから第２の所定時間以内に前記処理終了通知を受けない場合に、第２のタイムアウト処理を行うことを特徴とする請求項１〜４のいずれかに記載のリクエスト処理装置。

【請求項6】

前記管理部は、前記デキュー通知を複数の前記アプリケーションプログラムにブロードキャストすることを特徴とする請求項１〜５のいずれかに記載のリクエスト処理装置。

【請求項7】

前記管理部は、前記ファームウェアから前記リクエストに応じた処理が終了した旨の通知を受けると、その旨を示す処理終了通知を複数の前記アプリケーションプログラムにブロードキャストすることを特徴とする請求項１〜６のいずれかに記載のリクエスト処理装置。

【請求項8】

処理部が、アプリケーションプログラムからのリクエストを一時的にキューに保存する第１の工程と、
前記処理部が、前記第１の工程で前記キューに保存された前記リクエストをデキューして、当該リクエストを処理するファームウェアに送る第２の工程と、
前記処理部が、前記第２の工程で前記デキューされたリクエストが前記ファームウェアに送られたことを示すデキュー通知を前記アプリケーションプログラムに送る第３の工程とを有し、
前記ファームウェアからのリクエストに応じて処理を行うハードウェアモジュールに複数のプロファイルが規定されており、
前記複数のプロファイル毎に前記キューが設けられており、
前記処理部が、前記複数のプロファイル毎に、当該プロファイルに対応した前記キューを管理する処理として、前記第１の工程、前記第２の工程及び前記第３の工程を実行する、
リクエスト処理方法。

【請求項9】

請求項８に記載のリクエスト処理方法を前記処理部に実行させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、リクエスト（処理要求）を処理するリクエスト処理装置、その方法およびプログラムに関するものである。

【背景技術】

【0002】

アプリケーションプログラムが、ソフトウェアやハードウェアのリソースを使う場合に、当該アプリケーションプログラムが出した複数のリクエストをキューに保存し、リソースが使用可能になった場合に、キューに保存されたリクエストをＡＰＩ(Application Programming Interface)が順に読みだしてリソースに提供するシステムがある。
このようなシステムでは、リクエストがキューに保存されるエンキュー時刻を管理し、エンキュー時刻と現在時刻との比較し、エンキューから所定時間経過しても、そのリクエストに対応した処理終了通知を受けない場合には、タイムアウトが発生したことを判断して所定のタイムアウト処理を行う。これにより、トランザクションに依存しない独立性の高いプログラム開発を可能とした。
当該システムでは、同じプロファイルにおいて、一つのリクエストにリソースを使用中に、次のリクエストが発行された場合に、エラーメッセージを発行する。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００１−１９５３６０号公報

【発明の概要】

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

【0004】

従来のシステムでは、キューにリクエストをエンキューするアプリケーションプログラムと、デキューするＡＰＩとが独立していると、アプリケーションプログラムは、リクエストがデキューされた時刻を把握できない。そのため、アプリケーションプログラムが、リクエストがキューに留まっている時間を基にしたタイムアウト処理と、リクエストがＡＰＩによってデキューされて実行後の時間を基にしたタイムアウト処理とを区別して行うことができない。すなわち、タイムアウトの原因を特定できず、その原因に応じた適切なタイムアウト処理ができないという問題がある。

【0005】

本発明はかかる事情に鑑みてなされたものであり、その目的は、タイムアウトの原因に応じた適切なタイムアウト処理をアプリケーションプログラムが行うことができるリクエスト処理装置、その方法およびプログラムを提供することにある。

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

【0006】

上述した従来技術の問題点を解決し、上述した目的を達成するために、本発明のリクエスト処理装置は、アプリケーションプログラムからのリクエストを一時的に保存するキューと、前記キューを管理する管理部とを有するリクエスト処理装置であって、前記管理部は、前記キューに保存された前記リクエストがデキューされて当該リクエストを処理するファームウェアに送られると、その旨を示すデキュー通知を前記アプリケーションプログラムに送る。

【0007】

この構成によれば、アプリケーションプログラムは、管理部から受けたデキュー通知を基に、自らが出したリクエストがキューからデキューされた時刻を把握できる。これにより、アプリケーションプログラムは、リクエストがキューに留まった状態の第１のタイムアウト処理と、当該リクエストがデキューされた後にモジュールで処理完了されるまでの第２のタイムアウト処理とを個別に行うことができる。リクエスト処理システムでは、個々のアプリケーションプログラムは管理部からのデキュー通知を管理すればよく、キューを直接調べる必要がなくなるので、全体としての負荷を軽減できる。

【0008】

好適には本発明のリクエスト処理装置の前記管理部は、前記ファームウェアから前記リクエストに応じた処理が終了した旨の通知を受けると、その旨を示す処理終了通知を前記アプリケーションプログラムに提供する。
この構成によれば、アプリケーションブログラムは、自らが出したリクエストの処理終了通知を基に、当該リクエストがデキューされた後に処理終了通知が一定時間以上ない場合に、それに対応したタイムアウト処理を行うことができる。

【0009】

好適には本発明のリクエスト処理装置の前記管理部は、ＡＰＩであり、前記アプリケーションプログラムと、前記管理部の処理を記述した管理プログラムと、前記キューとが保存されるメモリと、前記アプリケーションプログラムおよび前記管理プログラムを実行する処理部とを備える。
この構成によれば、ソフトウェア階層のＡＰＩの機能として管理部を実現できる。

【0010】

好適には本発明のリクエスト処理装置の前記アプリケーションプログラムは、前記キューに前記リクエストを提供してから第１の所定時間以内に前記デキュー通知を受けない場合に、第１のタイムアウト処理を行う。
この構成によれば、アプリケーションプログラムは、自らが出したリクエストがキューに第１の所定時間を超えて留まった場合に対応した適切な第１のタイムアウト処理を行うことができる。

【0011】

好適には、本発明のリクエスト処理装置の前記アプリケーションプログラムは、前記デキュー通知を受けてから第２の所定時間以内に前記処理終了通知を受けない場合に、第２のタイムアウト処理を行う。
この構成によれば、アプリケーションプログラムは、自らが出したリクエストがキューから出された処理された場合に、その処理終了が第２の所定時間を超えた場合に対応した適切な第２のタイムアウト処理を行うことができる。

【0012】

好適には本発明のリクエスト処理装置は、前記ファームウェアからのリクエストに応じてハードウェアモジュールが処理を行い、当該ハードウェアモジュールに複数のプロファイルが規定されている場合に、前記複数のプロファイル毎に前記キューが設けられ、前記管理部は、前記複数のプロファイル毎に、当該プロファイルに対応した前記キューを管理する。
この構成によれば、複数のプロファイル毎にキューの管理を行うことができる。

【0013】

好適には本発明のリクエスト処理装置の前記管理部は、前記デキュー通知を複数の前記アプリケーションプログラムにブロードキャストする。これより、管理部の処理負担を軽減できる。
好適には本発明のリクエスト処理装置の前記管理部は、前記処理終了通知を複数の前記アプリケーションプログラムにブロードキャストする。これより、管理部の処理負担を軽減できる。

【0014】

本発明のリクエスト処理方法は、処理部が、アプリケーションプログラムからのリクエストを一時的にキューに保存する第１の工程と、処理部が、前記第１の工程で前記キューに保存された前記リクエストをデキューして、当該リクエストを処理するファームウェアに送る第２の工程と、処理部が、前記第２の工程で前記デキューされたリクエストが前記ファームウェアに送られたことを示すデキュー通知を前記アプリケーションプログラムに送る第３の工程とを有し、前記ファームウェアからのリクエストに応じて処理を行うハードウェアモジュールに複数のプロファイルが規定されており、前記複数のプロファイル毎に前記キューが設けられており、前記処理部が、前記複数のプロファイル毎に、当該プロファイルに対応した前記キューを管理する処理として、前記第１の工程、前記第２の工程及び前記第３の工程を実行する、リクエスト処理方法である。

【0015】

本発明のプログラムは、上記リクエスト処理方法を前記処理部に実行させるためのプログラムである。

【発明の効果】

【0016】

本発明によれば、タイムアウトの原因に応じた適切なタイムアウト処理をアプリケーションプログラムが行うことができるリクエスト処理装置、その方法およびプログラムを提供することができる。

【図面の簡単な説明】

【0017】

【図1】本発明の実施形態に係るリクエスト処理システムの機能ブロック図である。

【図2】メモリに記憶され、処理部で実行されるプログラムＰＲＧ等の階層を説明するための図である。

【図3】ＡＰＩの管理部の処理を説明するためのフローチャートである。

【図4】図１および図２に示すリクエスト処理システムにおけるリクエストＲＥＱおよび通知の流れを説明するための機能ブロック図である。

【図5】複数のリクエストＲＥＱが発生した場合におけるリクエスト処理システムの処理の流れを説明するためのフロー図である。

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

【0018】

以下、本発明の実施形態に係るリクエスト処理システムについて説明する。
図１は、本発明の実施形態に係るリクエスト処理システム１の機能ブロック図である。
図１に示すように、リクエスト処理システム１は、例えば、通信部１１、インタフェース１３、メモリ１５および処理部１７を有する。
通信部１１は、例えば、Bluetooth(登録商標)等の通信用のハードウェアである。
インタフェース１３は、外部装置との間でデータの入出力を行う。
メモリ１５は、処理部１７が実行するプログラムＰＲＧ、並びに処理部１７の処理に使われるデータや処理結果のデータを記憶する。
処理部１７は、プログラムＰＲＧを実行し、本実施形態で説明する各種の処理を実行する。プログラムＰＲＧには、アプリケーションプログラム３１、管理部５３を実現する管理プログラム等が含まれる。

【0019】

図２は、メモリ１５に記憶され、処理部１７で実行されるプログラムＰＲＧ等の階層（オペレーティングシステムの構造）を説明するための図である。
図２に示すように、当該プログラム階層では、例えば、アプリケーションプログラム３１、アプリケーションフレームワーク３３、ライブラリ３５、ランタイム３７、ＡＰＩ３９、ファームウェア４１およびハードウェアモジュール４３が上位から下位に向けて順に設けられている。

【0020】

アプリケーションプログラム３１は、利用者がリクエスト処理システム１で実行したい作業を実施する機能を直接的に有するソフトウェアである。
アプリケーションフレームワーク３３は、プログラミングにおいて、特定のオペレーティングシステムのためのアプリケーションの標準構造を実装するのに使われるクラスやライブラリの集まりである。
リクエスト処理システム１では、アプリケーションプログラム３１として、複数のアプリケーションプログラムＡＰを有し、これらがアプリケーションフレームワーク３３およびライブラリ３５を介してＡＰＩ３９に対して、並列に（同時期に）にリクエスト（メッセージ）ＲＥＱを送ることを想定している。リクエストＲＥＱには、命令やオペランド等が含まれる。

【0021】

ライブラリ３５は、汎用性の高い複数のプログラムを、再利用可能な形でひとまとまりにしたものである。
ランタイム３７は、コンピュータプログラムの実行時に必要となるソフトウェア部品(モジュール)である。

【0022】

ＡＰＩ３９は、リクエスト処理システム１（コンピュータ）のハードウェアとそのコンピュータ上で動作するソフトウェアの間に存在するソフトウェアで実装した抽象化レイヤーである。 オペレーティングシステムのカーネルからハードウェア毎に異なる差異を隠蔽する機能を持ち、それによってカーネルコードは異なるハードウェアのシステム上で動作してもほとんど変更する必要がなくなる。
ＡＰＩ３９としては、例えば、Ａｎｄｒｏｉｄ（登録商標）では、ＨＡＬ(Hardware Abstract Layer)が用いられる。
ＡＰＩ３９は、キュー５１を管理する管理部５３を有する。

【0023】

ファームウェア４１は、例えば、ＡＰＩ３９からのリクエストＲＥＱに応じて、ハードウェアモジュール４３に直接アクセスするコンポーネントである。

【0024】

ハードウェアモジュール４３は、例えば、図１に示す通信部１１である。ハードウェアモジュール４３は、ファームウェア４１からのリクエストＲＥＱに応じた処理を行う。
ハードウェアモジュール４３は、例えば、様々なデバイスでの通信に使用され、機器の種類ごとに策定されたプロトコルがある。本実施形態では、これらの使用方法をプロファイル (Profile)と呼び、通信しようとする機器同士が同じプロファイルを持っている場合に限り、そのプロファイルの機能を利用した通信を行うことができる。
ハードウェアモジュール４３は、例えば、Bluetooth等の通信モジュールである。
Bluetooth対応機種であっても利用する機器の双方が適切なプロファイルに対応している必要がある。本実施形態では、ハードウェアモジュール４３に複数のプロファイルＰＲＦが規定されている。

【0025】

キュー５１は、図２に示す階層のアプリケーションフレームワークで実現される。
キュー５１は、アプリケーションプログラム３１からのリクエストＲＥＱを一時的に保存する。リクエスト処理システム１では、キュー５１にリクエストＲＥＱが保存されるエンキュー時刻と、キュー５１からリクエストＲＥＱがファームウェア４１に出されるデキュー時刻とが管理される。
キュー５１は、上記複数のプロファイルＰＲＦ毎に設けられている。管理部５３は、上記複数のプロファイルＰＲＦ毎に、当該プロファイルＰＲＦに対応したキュー５１を管理する。

【0026】

以下、ＡＰＩ３９の処理について詳細に説明する。
図３は、ＡＰＩ３９の管理部５３の処理を説明するためのフローチャートである。
ステップＳＴ１：
管理部５３は、キュー５１にリクエストＲＥＱが保存されているか否かを判定し、肯定判定である場合にはステップＳＴ２の進み、否定判定である場合にはステップＳＴ１に戻る。

【0027】

ステップＳＴ２：
管理部５３あるいはその他のプログラムは、キュー５１からリクエストＲＥＱをデキューしてファームウェア４１に出力する。

【0028】

ステップＳＴ３：
管理部５３は、キュー５１からリクエストＲＥＱがデキューされると、その旨を示すデキュー通知ＳＭをアプリケーションプログラム３１に出す。当該デキュー通知ＳＭには、リクエストＲＥＱの識別情報（例えば、プロセス識別子）が含まれる。なお、デキュー通知ＳＭに、デキューされた時刻情報を含めてもよい。

【0029】

ステップＳＴ４：
ＡＰＩ３９は、ファームウェア４１から処理終了通知ＣＦＭを受けたか否かを判定し、肯定判定の場合には、ステップＳＴ５に進み、否定判定の場合は当該判定を繰り返す

【0030】

ステップＳＴ５：
ＡＰＩ３９は、処理終了通知ＡＣＴＩＯＮを、アプリケーションプログラム３１に出す。処理終了通知ＡＣＴＩＯＮには、リクエストＲＥＱの識別情報（例えば、プロセス識別子）が含まれる。処理終了通知ＡＣＴＩＯＮには処理終了時刻を含めてもよい。

【0031】

以上説明したように、管理部５３は、アプリケーションプログラム３１に対してリクエストＲＥＱの処理終了通知ＡＣＴＩＯＮの他に、キュー５１からリクエストＲＥＱがデキューされたことを示すデキュー通知ＳＭをアプリケーションプログラム３１に送る。

【0032】

図４は、図１および図２に示すリクエスト処理システム１におけるリクエストＲＥＱおよび通知の流れを説明するための機能ブロック図である。
図４に示す処理は、プロファイルＰＲＦ毎に行われる。
アプリケーションプログラム３１が、リクエストＲＥＱを図２に示すアプリケーションフレームワーク３３に出すと、それがキュー５１にエンキューされて一時的に保存される。
そして、キュー５１に保存されたリクエストＲＥＱがデキューされて、当該リクエストＲＥＱを処理するファームウェア４１に提供される。ファームウェア４１は、キュー５１からデキューされたリクエストＲＥＱをハードウェアモジュール４３に実行させる。

【0033】

管理部５３は、キュー５１からリクエストＲＥＱがデキューされると、その旨を示すデキュー通知ＳＭをアプリケーションプログラム３１に出す。

【0034】

ハードウェアモジュール４３は、ファームウェア４１からのリクエストＲＥＱに応じて処理を実行し、その処理が終了すると、その旨あるいは処理結果を含む処理終了通知ＣＦＭをファームウェア４１に出す。
ファームウェア４１は、ハードウェアモジュール４３においてリクエストＲＥＱに応じた処理が終了すると、その旨を示す処理終了通知ＣＦＭをＡＰＩ３９に出す。

【0035】

管理部５３は、ファームウェア４１から処理終了通知ＣＦＭを受けると、その旨を示す処理終了通知ＡＣＴＩＯＮを、アプリケーションプログラム３１に出す。

【0036】

アプリケーションプログラム３１は、上述したように管理部５３から受けたデキュー通知ＳＭおよび処理終了通知ＡＣＴＩＯＮを基に処理を行う。
例えば、アプリケーションプログラム３１は、キュー５１にリクエストＲＥＱを提供してから第１の所定時間以内にデキュー通知ＳＭを受けなけない場合に、第１のタイムアウト処理を行う。
また、アプリケーションプログラム３１は、デキュー通知ＳＭを受けてから第２の所定時間以内に処理終了通知ＡＣＴＩＯＮを受けなけない場合に、第２のタイムアウト処理を行う。

【0037】

このように、リクエスト処理システム１では、アプリケーションプログラムは、キュー５１のエンキューからデキューまでのタイムアウト管理と、デキューから処理終了までのタイムアウト管理を別々に行うことができる。
すなわち、アプリケーションプログラム３１は、管理部５３から受けたデキュー通知ＳＭおよび処理終了通知ＡＣＴＩＯＮを基に、自らが出したリクエストＲＥＱがキュー５１にエンキューされた時刻（自らがアプリケーションフレームワーク３３にリクエストＲＥＱを送った時刻）と、当該リクエストＲＥＱがキュー５１からデキューされた時刻（デキュー通知受信時刻）と、リクエストＲＥＱに応じた処理が終了した処理終了時刻（処理終了通知受信時刻）とを把握できる。

【0038】

そのため、アプリケーションプログラム３１は、リクエストＲＥＱがキュー５１に留まった状態の第１のタイムアウト処理と、当該リクエストＲＥＱがデキューされた後にハードウェアモジュール４３で処理完了されるまでの第２のタイムアウト処理とを個別に行うことができる。
リクエスト処理システム１では、個々のアプリケーションプログラムＡＰはＡＰＩ３９からのデキュー通知ＳＭと処理終了通知ＡＣＴＩＯＮを管理すればよく、キュー５１を直接調べる必要がなくなるので、システム全体としての負荷を軽減できる。

【0039】

図５は、複数のリクエストＲＥＱが発生した場合におけるリクエスト処理システム１の処理の流れを説明するためのフロー図である。
図５に示す例では、アプリケーションプログラム３１として、アプリケーションプログラムＡＰ（１）とＡＰ（２）とが動作している。
なお、アプリケーションプログラムＡＰ（１），ＡＰ（２）とＡＰＩ３９との処理はアプリケーションフレームワーク３３およびライブラリ３５を介して行われるが、その記載は省略する。

【0040】

アプリケーションプログラムＡＰ（１）が、リクエストＲＥＱ（１）をＡＰＩ３９に出すと、それがキュー５１にエンキューされて一時的に保存される（ステップＳＴ１１）。
そして、キュー５１に保存されたリクエストＲＥＱ（１）がデキューされて、当該リクエストＲＥＱ（１）を処理するファームウェア４１に提供される（ステップＳＴ１２）。
管理部５３は、キュー５１からリクエストＲＥＱ（１）がデキューされると、その旨を示すデキュー通知ＳＭ（１）をアプリケーションプログラム３１にブロードキャストし、アプリケーションプログラムＡＰ（１）がそれを受け取る（ステップＳＴ１３）。

【0041】

ファームウェア４１は、キュー５１からデキューされたリクエストＲＥＱ（１）をハードウェアモジュール４３に実行させる（ステップＳＴ１４）。

【0042】

次に、アプリケーションプログラムＡＰ（２）は、リクエストＲＥＱ（２）をアプリケーションフレームワーク３３に出すと、それがキュー５１にエンキューされて一時的に保存される（ステップＳＴ１５）。
また、ハードウェアモジュール４３が、リクエストＲＥＱ（１）の処理を終了し、その旨を示す処理終了通知ＣＦＭ（１）をファームウェア４１に出す（ステップＳＴ１６）。そして、当該処理終了通知ＣＦＭ（１）が、ファームウェア４１から管理部５３に送られ、管理部５３からアプリケーションプログラム３１に処理終了通知ＡＣＴＩＯＮ（１）がブロードキャストされる（ステップＳＴ１７，ＳＴ１８）。そして、アプリケーションプログラムＡＰ（１）が処理終了通知ＡＣＴＩＯＮ（１）を受け取る。

【0043】

その後、ステップＳＴ１５でキュー５１に保存されたリクエストＲＥＱ（２）がデキューされて、当該リクエストＲＥＱ（２）を処理するファームウェア４１に提供される（ステップＳＴ１９）。
管理部５３は、キュー５１からリクエストＲＥＱ（２）がデキューされると、その旨を示すデキュー通知ＳＭ（２）をアプリケーションプログラム３１にブロードキャストする（ステップＳＴ２０）。アプリケーションプログラムＡＰ２がデキュー通知ＳＭ（２）を受け取る。

【0044】

ファームウェア４１は、キュー５１からデキューされたリクエストＲＥＱ（２）をハードウェアモジュール４３に実行させる（ステップＳＴ２１）。
そして、ハードウェアモジュール４３が、リクエストＲＥＱ（２）の処理を終了し、その旨を示す処理終了通知ＣＦＭ（２）をファームウェア４１に出す（ステップＳＴ２２）。そして、当該処理終了通知ＣＦＭ（２）が、ファームウェア４１から管理部５３に送られ、管理部５３からアプリケーションプログラム３１に処理終了通知ＡＣＴＩＯＮ（２）がブロードキャストされる。そして、アプリケーションプログラムＡＰ（２）が処理終了通知ＡＣＴＩＯＮ（２）を受け取る。

【0045】

以上説明したように、リクエスト処理システム１では、キュー５１からリクエストＲＥＱがデキューされると、キュー５１からアプリケーションプログラム３１にデキュー通知ＳＭが出される。また、ハードウェアモジュール４３においてリクエストＲＥＱの処理が終了すると、管理部５３からアプリケーションプログラム３１に処理終了通知ＡＣＴＩＯＮが出される。これにより、アプリケーションプログラム３１は、デキュー通知ＳＭを基に、自らが出したリクエストＲＥＱがキュー５１からデキューされた時刻を把握できる。そのため、アプリケーションプログラム３１は、リクエストＲＥＱがキューに留まった状態の第１のタイムアウト処理と、当該リクエストがデキューされた後にモジュールで処理完了されるまでの第２のタイムアウト処理とを個別に行うことができる。例えば、アプリケーションプログラムＡＰは、デキュー通知ＳＭを受けるまではタイムアウト処理を行わないということもできる。リクエスト処理システム１では、個々のアプリケーションプログラムＡＰは管理部５３からのデキュー通知ＳＭを管理すればよく、キューを直接調べる必要がなくなるので、全体としての負荷を軽減できる。

【0046】

また、リクエスト処理システム１によれば、プロファイルＰＲＦ毎にキュー５１を設けてキュー５１で管理することで、異なるプロファイルの競合しないリクエストＲＥＱを並列に処理でき、リソースの有効活用を図れる。

【0047】

また、リクエスト処理システム１によれば、デキュー通知ＳＭおよび処理終了通知ＡＣＴＩＯＮは管理部５３からアプリケーションプログラム３１にブロードキャストされる。そのため、管理部５３の監視に伴う処理負担を軽減できる。

【0048】

本発明は上述した実施形態には限定されない。
すなわち、当業者は、本発明の技術的範囲またはその均等の範囲内において、上述した実施形態の構成要素に関し、様々な変更、コンビネーション、サブコンビネーション、並びに代替を行ってもよい。
例えば、上述した実施形態では、図２に示すプログラム階層のＡＰＩ３９として管理部５３を実現する場合を例示したが、アプリケーションプログラム３１からのリクエストＲＥＱを一括して受けるその他の機能モジュールとして実現してもよい。
また、上述した図５の例では、異なるアプリケーションプログラムＡＰ（１），（２）が競合するリクエストＲＥＱ（１），ＲＥＱ（２）を出す場合を例示したが、一つのアプリケーションプログラムＡＰが競合するリクエストＲＥＱを出してもよい。

【産業上の利用可能性】

【0049】

本発明は、複数のリクエストを処理するシステムに適用可能である。

【符号の説明】

【0050】

１…リクエスト処理システム
１１…通信部
１３…インタフェース
１５…メモリ
１７…処理部
３１…アプリケーションプログラム
３３…アプリケーションフレームワーク
３７…ランタイム
３９…ＡＰＩ
４１…ファームウェア
４３…ハードウェアモジュール
５１…キュー
５３…管理部
ＰＲＧ…プログラム
ＡＰ…アプリケーションプログラム
ＰＲＦ…プロファイル

【図1】

【図2】

【図3】

【図4】

【図5】