JP7464503B2 - データ要求処理装置、データ要求処理方法及び記憶媒体 - Google Patents

Description

本発明は、データ連携及び流通の優先度制御に関する技術に関する。

近年、日本政府は、ネットワーク化やサイバー空間利用の飛躍的な発展により、新しいサービスが次々と創出され、社会の主体となる人々に豊かさをもたらす「超スマート社会」を未来社会の姿として定義し、その実現に向けた一連の取組を「Ｓｏｃｉｅｔｙ ５．０」として推進している。

Ｓｏｃｉｅｔｙ ５．０では、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）で人と物がつながり、様々なデータ（知識・情報）が流通・連携されることで新たな価値が生み出すことが期待されており、データ流通・連携の取組が活発に行われている。

一例として、スマートシティに関する取組（例えば、非特許文献１）では、行政が保有するデータや、建物や道路等のインフラのＩｏＴデータなどを横断的に連携することができるデータ連携・流通のプラットフォーム（以下、都市ＯＳ）が提唱されている。以下、都市ＯＳにおける、データ流通・連携の事例を説明する。

都市ＯＳは、データを提供元から利用者（又は、アプリケーション・サービス）へ仲介するが、社会状況の変化に伴う変更に対して、ダイナミックでかつ柔軟に対応できるイベント処理機能（非特許文献１：７．２．４．２）が要求されている。

また、データ利用者が提供するサービス・アプリケーションは、データのリアルタイム性を要するもの（例えば、監視カメラによる犯罪の抑止やインフラの災害監視）、リアルタイム性が要求されないものまで様々であり、都市ＯＳが仲介するデータにもリアルタイム性、即ち即座に利用者に仲介するものと、そうでないものが混在する。

リアルタイム性が要求されるデータ仲介においては、従来のデータ連携では、特許文献１、２のような優先制御の手法が用いられてきた。

特許文献１の技術は、予め提供させるデータに優先度を設定し、優先順位の高いデータを提供元から受信した場合に、仲介する処理をジョブとして優先度管理する。現在実行中のジョブによって仲介するジョブを実行するためのリソースを確保できない場合に、実行中のジョブの優先度情報に基づいて、実行中のジョブのうち、受信したジョブよりも優先度が低いジョブの少なくとも１つを停止する、ことが開示されている。

これにより、仲介するデータ量が増加しても、リアルタイム性が必要なデータに優先度を予め設定することにより、優先順位の高いデータをリアルタイムに仲介することができる。

特許文献２の技術は、アプリケーションからのデータ取得のリクエストの頻度を用いて、レスポンスの遅延を解消する技術である。特許文献２によれば、優先度ルール記憶部に、受け取られた各リクエストを、種別毎に、時刻と共に格納している優先度テーブル、及び各リクエストの時刻を時系列にそって格納している時刻記録テーブルを格納する。

優先度設定部は、最新のリクエストを対象として、優先度テーブルから、最新のリクエストの種別と同一の種別のリクエストの数を特定し、さらに、特定したリクエストの数と時刻記録テーブルに格納されている時刻の数とに基づいて、最新リクエストの発生頻度を算出し、処理順序を決定する際の指標となる優先度を設定する、ことが開示されている。これにより、仲介するデータが増加した場合に、予めプログラムされた優先度ルールにより、頻度の高いデータをリアルタイムに仲介することができる。

特開２０２０－２４６３６号公報 特開２０１２－７９１９０号公報

"スマートシティリファレンスアーキテクチャ ホワイトペーパー（日本語版）"、内閣府 発行、２０２０／４／１更新

一方で、都市ＯＳは、前述の通り、社会状況の変化に伴う変更に対して、ダイナミックでかつ柔軟に対応できる必要があり、予め設定されたリアルタイム性に関する優先度を変更する場合がある。

例えば、道路等のインフラ保守に関するアプリケーションにおいて、通常時において都市ＯＳではリアルタイム性を必要としない優先度で設定されているが、アクシデントが発生した緊急時には、アクシデント発生箇所に関して仲介するデータの優先度を一時的に高くするなどである。

また、事故や災害などが発生した場合でも、都市ＯＳは、状況に応じてダイナミックでかつ柔軟に対応し、安定的にデータの利用者がデータを取得し続けられるようにすることが要求される。

ここで、特許文献１、２を適用した場合でも、上記のダイナミックでかつ柔軟なデータの仲介は実現できない。特許文献１では、予め提供元から送付されるデータに優先度を設定しておくことが必要であり、緊急時にダイナミックに優先度を変える方法については開示されていない。

特許文献２は、頻度を用いて優先度を設定する方法に関して開示しており、頻度の増加するケース以外のケースに関しては開示されていない。このように特許文献１、２のどちらを適用しても、状況が変わった場合に優先度の変更ができず、緊急時に必要なデータの仲介処理ができなくなる可能性があった。

そこで本発明は、上記問題点に鑑みてなされたもので、データの仲介を行う際に、状況に応じてダイナミックでかつ柔軟にデータを要求するリクエストの優先度を制御することを目的とする。

本発明は、プロセッサとメモリを有するデータ要求処理装置であって、データベースに格納されているデータをリクエストするメッセージを受信し、前記メッセージに含まれるデータ要求に優先度を設定して、前記優先度に応じて前記データ要求の処理順序を決定する優先度制御部を有し、前記優先度制御部は、前記メッセージを受信する受信部と、前記メッセージに含まれるデータ要求を取得し、前記データ要求を分析して前記優先度の設定に必要なパラメータを生成する分析部と、前記パラメータを用いて前記データ要求に優先度を設定する優先度設定部と、を有し、前記優先度設定部は、前記パラメータを受け付けて、所定のルールで前記パラメータを分類し、前記分類の結果に応じて前記データ要求の優先度を設定する。

本発明によれば、状況に応じてダイナミックでかつ柔軟にリクエストの優先度を制御して、リアルタイム性が必要なアプリケーションは安定的にデータを取得することができる。

本明細書において開示される主題の、少なくとも１つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。

本発明の実施例１によるデータ要求処理システムの構成の一例を示すブロック図である。 本発明の実施例１によるデータ要求処理システムで行われる処理の一例を示すシーケンス図である。 本発明の実施例１によるリクエストの構造の一例を示す図である。 本発明の実施例１によるリクエスト分析部の構成の一例を示すブロック図である。 本発明の実施例１によるリクエスト分析部の処理を示すフローチャートである。 本発明の実施例１による優先度設定部の構成の一例を示すブロック図である。 本発明の実施例１による優先度設定部の処理を示すフローチャートである。 本発明の実施例１によるレスポンス時間テーブルの一例を示す図である。 本発明の実施例２によるリクエスト分析部の構成の一例を示すブロック図である。 本発明の実施例２によるリクエスト分析部と管理部間の処理を示すフローチャートである。 本発明の実施例２によるリクエスト分析部の処理を示すフローチャートである。 本発明の実施例３によるリクエスト分析部の構成の一例を示すブロック図である。 本発明の実施例３によるリクエスト分析部の処理を示すフローチャートである。

以下、本発明の実施の形態について、図面を参照して詳細に説明する。なお、各図において共通する部分には、同一の符号が付与されている。

実施例１で説明する都市ＯＳ（データ連携・流通のプラットフォーム）のデータ仲介では、都市ＯＳの内部に仲介するデータを格納しておくためのデータベース（内部データベース）を用意し、データ提供者が都市ＯＳの内部データベースにデータを格納しておく。

データ利用者は、都市ＯＳの内部データベースに格納されたデータを都市ＯＳに対してリクエストする方法と、データ利用者が提供元のデータベース（外部データベース）に格納されているデータについて都市ＯＳを介してリクエストして取得する方法がある。

実施例１で説明する都市ＯＳのデータ仲介において、リクエストからレスポンス（リクエストされたデータをアプリケーションに返すこと）までの時間を保証するために、プランを作成しておき、プランに加入したデータ利用者は、プランで決められた最低レスポンス時間内にデータを取得できるようにする仕組みを実装することができる。

実施例１は、上記の外部データベースに都市ＯＳがデータをリクエストする場合に、状況に応じてレスポンス時間テーブルを参照してリクエストからレスポンスまでかかった時間（以下、実測レスポンス時間）を用いて、リクエストの優先順位を変更し、処理遅延を解消するデータ要求処理システムに関して説明する。なお、上記状況は、例えば、レスポンスに時間がかかる状況や、上記の都市ＯＳのプランで決められた最低限のレスポンス時間より遅れそうな状況、又は、カテゴリ（種類）や属性（自治体、民間、企業、等）別にデータの取得に時間がかかる状況である。

図１は、実施例１によるデータ要求処理システムの構成の一例を示すブロック図である。

データ要求処理システムは、データ要求処理装置１と、アプリケーション２－１～２－３をそれぞれ実行する端末１００－１～１００－３と、ネットワーク３、ネットワーク４、データベース５、外部データベース６、データ送信部７から構成される。なお、データベース５と、データ送信部７はデータ要求処理装置１が提供する例を示すが、他の計算機が提供してもよい。また、端末を個々に特定しない場合には、「－」以降を省略した符号「１００」を用いる。他の構成要素の符号についても同様である。

データ要求処理装置１は、プロセッサ２１と、メモリ２２と、ストレージ装置２３と、通信インターフェース２４と、入出力装置２５を含む計算機である。

メモリ２２には、都市ＯＳ３０がロードされて、プロセッサ２１によって実行される。都市ＯＳ３０は、優先度制御部１１と、スケジューリング部１２と、データ送信部７の機能部を含む。優先度制御部１１は、リクエスト受信部１１１と、リクエスト分析部１１２と、優先度設定部１１３の機能部を含む。

都市ＯＳ３０の各機能を提供する優先度制御部１１と、スケジューリング部１２と、データ送信部７は、プログラムとしてメモリ２２にロードされる。

プロセッサ２１は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、プロセッサ２１は、優先度制御プログラムに従って処理を実行することで優先度制御部１１として機能する。他のプログラムについても同様である。さらに、プロセッサ２１は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

ストレージ装置２３は、データベース５を格納する。データベース５は都市ＯＳ３０の内部のデータベースとして管理される。通信インターフェース２４は、ネットワーク３、４に接続されて、端末１００や外部データベース６と通信を行う。入出力装置２５は、キーボードやマウス或いはタッチパネル等の入力装置と、ディスプレイ等の出力装置を含む。

優先度制御部１１は、後述するように、アプリケーション２から受け付けたデータのリクエストメッセージに優先度を設定して、スケジューリング部１２に出力する。スケジューリング部１２は優先度（優先順位）の高い順にリクエストメッセージを処理してデータベース５又は外部データベース６にアクセスする。なお、外部データベース６は、外部の都市ＯＳ（図示省略）によって管理される。

なお、スケジューリング部１２は、リクエストメッセージから抽出したクエリ（データ要求）をデータベース５又は外部データベース６に出力してもよいし、データベース５又は外部データベース６がリクエストメッセージを受け付け可能な場合には、リクエストメッセージを送信すればよい。

データ送信部７は、データベース５又は外部データベース６の応答を受け付けると、レスポンスメッセージを生成して、アプリケーション２に送信する。

図２は、データ要求処理システムのシーケンスを示す。なお、以下の説明では、端末１００－１～１００－３のアプリケーション２－１～２－３の構成は同様であるので、アプリケーション２－１について説明する。

端末１００が実行するアプリケーション２は、ネットワーク３を介して、データ要求処理装置１に接続し、データ取得のためのリクエストメッセージを送信する（Ｓ１）。

データ要求処理装置１は、優先度制御部１１で設定された優先度（可変優先度）に従って、リクエストメッセージの処理順位を決定し、スケジューリング部１２で処理順位の高いリクエストメッセージのクエリを送信してデータベース５にアクセスする。

スケジューリング部１２は、データの所在によっては、データベース５かネットワーク４を介して接続された外部データベース６にアクセスする。データベース５又は外部データベース６から取得したデータはデータ送信部７に出力され、データ送信部７はレスポンスメッセージを生成して、アプリケーション２にデータを送信する。

優先度制御部１１のリクエスト受信部１１１は、アプリケーション２から送信されたリクエストメッセージを記録する。リクエスト分析部１１２は、リクエスト受信部１１１に記録されているリクエストメッセージを取得し（Ｓ２、Ｓ３）、リクエストメッセージを分析し（Ｓ４）、分析結果のパラメータ（リアルタイム性）を生成し（Ｓ５）、優先度設定部１１３に出力する（Ｓ６、Ｓ７）。

優先度設定部１１３は、リクエスト分析部１１２からの全パラメータが入力されると、パラメータからリクエストメッセージ毎に優先度の変更を判断し、判断に応じて可変優先度を算出する（Ｓ８）。優先度設定部１１３は、リクエストメッセージと可変優先度をスケジューリング部１２へ送信する（Ｓ９）。

スケジューリング部１２は、受信したリクエストメッセージの可変優先度に従って、リクエストメッセージに含まれるクエリを送信して、データベース５にデータを要求する（Ｓ１０）。データベース５はリクエストメッセージのクエリで要求されたデータを検索した結果をデータ送信部７に送信する（Ｓ１１）。

スケジューリング部１２は、リクエストメッセージで要求されたデータが外部データベース６の場合には、外部データベース６にデータを要求する（Ｓ１２）し、外部データベース６はリクエストメッセージで要求されたデータを検索した結果（データ）をデータ送信部７に送信する（Ｓ１３）。

データ送信部７は、データベース５又は外部データベース６から受信したデータからレスポンスメッセージを生成して（Ｓ１４）アプリケーション２へ送信する（Ｓ１５）。

図３は、実施例１によるリクエストメッセージ３００の構造の一例を示す図である。ｒｅｑｕｅｓｔＩＤ３０１は、アプリケーション２から送信されたリクエストメッセージを識別するための項目で、リクエスト受信部１１１で付与される。

ｒｅｑｕｅｓｔＴｉｍｅ３０２は、リクエストメッセージ３００がリクエスト受信部１１１に記録（又は受信）された時刻であり、リクエスト受信部１１１で付与される。ａｐｐｒｉｃａｔｉｏｎＩＤ３０３は、アプリケーション２を識別するための項目であり、アプリケーション２から送信されるリクエストメッセージ３００に含まれる。

ｐｒｉｏｒｔｙ３０４は、予め決められたアプリケーション２毎の優先度（アプリ優先度）であり、アプリケーション２から送信されるリクエストメッセージ３００に含まれる。アプリ優先度（３０４）は、例えば、自然数を用いて優先順位の値を設定する（例えば、１～７）。なお、優先度設定部１１３で設定される可変優先度の値の範囲も前記のアプリ優先度（３０４）と同じレンジとする。なお、優先順位は値が小さいほど優先度が高いものとする。

ｑｕｅｒｙ３０５は、リクエストメッセージ３００に含まれるデータ要求であり、要求されるデータ名３０５１や、データのカテゴリ（種別・図中ｄａｔａＣａｔａｌｏｇ）３０５２や、サイズ３０５３、属性（図中ｐｒｏｐｅｒｔｙ）３０５４など、データを取得するために必要な情報の全てが含まれる。ｑｕｅｒｙ３０５は、アプリケーション２から送信されるリクエストメッセージ３００に含まれている。

図４は、実施例１によるリクエスト分析部１１２の構成の一例を示すブロック図である。リクエスト分析部１１２は、リクエストメッセージ３００を取得するリクエスト取得部１１２１と、リクエストメッセージ３００に含まれるアプリ優先度（３０４）を取得するアプリ優先度読み取り部１１２２と、リクエストメッセージ３００からｑｕｅｒｙ３０５を取得するクエリ読み取り部１１２３と、データ送信部７からレスポンスに関する情報を受け付けて実測レスポンス時間を算出してレスポンス時間テーブル１１２５に格納するレスポンス時間計算部１１２６と、ｑｕｅｒｙ３０５とレスポンス時間テーブル１１２５の情報からパラメータを生成するパラメータ検出部１１２４を含む。

図５は、リクエスト分析部１１２の処理を示すフローチャートである。この処理は、リクエスト受信部１１１からリクエストメッセージ３００を受診した場合に実行される。

リクエスト取得部１１２１は、リクエスト受信部１１１に記録されているリクエストメッセージ３００を要求し、レスポンスとしてリクエストメッセージを取得する（Ｓ５１）。

リクエスト取得部１１２１は、取得したリクエストメッセージ３００をアプリ優先度読み取り部１１２２と、クエリ読み取り部に送る（Ｓ５２）。アプリ優先度読み取り部１１２２は、リクエストメッセージ３００からｒｅｑｕｅｓｔＩＤ３０１と、ｐｒｉｏｒｉｔｙ３０４を取得（Ｓ５３）し、優先度設定部１１３に出力する（Ｓ５７）。

クエリ読み取り部１１２３は、ｒｅｑｕｅｓｔＩＤ３０１と、ｒｅｑｕｅｓｔＴｉｍｅ３０２と、ａｐｐｒｉｃａｔｉｏｎＩＤ３０３と、クエリ３０５をリクエストメッセージ３００から取得し（Ｓ５４）、パラメータ検出部１１２４に出力する。

パラメータ検出部１１２４は、クエリ読み取り部１１２３で取得した項目を用いて、可変優先度を設定するのに必要なパラメータを生成する。実施例１では、パラメータ検出部１１２４は、レスポンス時間テーブル１１２５にアクセスし、ｑｕｅｒｙ３０５を用いてリクエストメッセージ３００に該当する過去の実測レスポンス時間を参照する（Ｓ５５）。

パラメータ検出部１１２４は、例えば、ｑｕｅｒｙ３０５のデータ名３０５１を取得し、データ名３０５１でレスポンス時間テーブル１１２５を検索し、データ名１２０２が一致するレコードの実測レスポンス時間１２０４を取得し、リクエストメッセージ３００でアクセスする際の推定レスポンス時間として設定する。

図８は、レスポンス時間テーブル１１２５の一例を示す図である。レスポンス時間テーブル１１２５は、アプリＩＤ１２０１と、データ名１２０２と、種類１２０３と、実測レスポンス時間１２０４と、所在１２０５と、タイムスタンプ１２０６を１つのレコードに含む。

アプリＩＤ１２０１は、アプリケーション２の識別子を格納する。データ名１２０２は、リクエストメッセージ３００で要求されたデータの名称が格納される。種類１２０３にはデータの種類が格納される。所在１２０５には、データが格納されている位置（又はパス）が格納される。タイムスタンプ１２０６には、データが登録された日時が格納される。

実測レスポンス時間１２０４は、データ送信部７から送信されたデータ要求に対してデータベース５からの応答がデータ送信部７に到着した時刻と、リクエストメッセージ３００のｒｅｑｕｅｓｔＴｉｍｅ３０２の差分からレスポンス時間計算部１１２６が計算した時間である。

なお、実測レスポンス時間１２０４は、上記に限定されるものではなく、スケジューリング部１２がリクエストメッセージ３００又はクエリを送信してから、データベース５（又は外部データベース６）の応答をデータ送信部７で受け付けるまでの時間をレスポンス時間計算部１１２６が測定して、レスポンス時間テーブル１１２５へ蓄積してもよい。

なお、レスポンス時間テーブル１１２５は、図示はしないが、少なくともデータ名（３０５１）と、データのカテゴリ（３０５２）と、実測レスポンス時間を１つのレコードに含めばよい。

また、レスポンス時間計算部１１２６は、計算した実測レスポンス時間１２０４と、データ名１２０１やデータの所在などの情報を登録し、登録した時刻をタイムスタンプ１２０６に設定する。レスポンス時間計算部１１２６は、毎回のレスポンス毎に計算するか、一定時間内に発生したレスポンスの平均値を計算することも可能である。

次に、パラメータ検出部１１２４は、取得した実測レスポンス時間１２０４を用いて、パラメータを生成する（Ｓ５６）。なお、パラメータ検出部１１２４は、レスポンス時間テーブル１１２５から複数の実測レスポンス時間１２０４を検索した場合には、タイムスタンプ１２０６が最新のレコードの値を選択して推定レスポンス時間とする。

例えば、外部データベース６にデータを要求する状況においては、パラメータ検出部１１２４は、ｑｕｅｒｙ３０５のデータ名を用いてレスポンス時間テーブル１１２５を検索し、パラメータとして実測レスポンス時間１２０４と、外部アクセス判定結果が「Ｔｒｕｅ」の値と、データの所在１２０５を生成する。なお、外部アクセス判定結果は、「Ｔｒｕｅ」又は「Ｆａｌｓｅ」が設定される。

また、パラメータ検出部１１２４は、要求されているデータの所在１２０５が、外部データベース６ではない場合にはパラメータとして外部アクセス判定結果が「Ｆａｌｓｅ」の値を生成する。パラメータ検出部１１２４が生成したパラメータは優先度設定部１１３に出力される（Ｓ５７）。

リクエストメッセージ３００の到着からデータ送信部７が検索結果を取得するまでにレスポンスに時間を要するカテゴリ３０５２（種類１２０３）のデータの処理速度を上げるために、パラメータ検出部１１２４が、リクエストメッセージ３００のカテゴリ３０５２でレスポンス時間テーブル１１２５を検索し、データの種類１２０３に一致する実測レスポンス時間１２０４をパラメータとして使用することも可能である。

又は、レスポンスに時間を要する属性（自治体、民間、企業、等）のデータの処理速度を上げるために、レスポンス時間テーブル１１２５にデータの属性情報と実測レスポンス時間１２０４を登録し、パラメータとして生成することも可能である。

又は、都市ＯＳ３０のプランで決められた最低限のレスポンス時間より遅れそうな場合に、遅延を回避するため、レスポンス時間テーブル１１２５にプラン情報（最低限レスポンス時間）を加えておくことができる。

パラメータ検出部１１２４は、リクエストメッセージ３００のａｐｐｒｉｃａｔｉｏｎＩＤ３０３に一致するアプリＩＤ１２０１のレコードを検索し、レスポンス時間テーブル１１２５からプラン情報（最低限レスポンス時間）、実測レスポンス時間１２０４を取得する。そして、パラメータ検出部１１２４は、アプリケーション２が加入しているプランの最低限レスポンス時間と、実測レスポンス時間１２０４の差を計算し、パラメータを生成することも可能である。

パラメータ検出部１１２４は、実測レスポンス時間１２０４と外部アクセス判定結果（「Ｔｒｕｅ」又は「Ｆａｌｓｅ」）と、上記ステップＳ５３で取得したアプリ優先度（３０４）を含むパラメータを優先度設定部１１３に出力する（Ｓ５７）。

次に、リクエスト分析部１１２のリクエスト取得部１１２１は、優先度設定部１１３からパラメータの受信完了の通知（レスポンス）を待って処理を終了する（Ｓ５８）。

図６は、優先度設定部１１３の構成の一例を示すブロック図である。優先度設定部１１３は、リクエスト分析部１１２からパラメータを受け付けて、可変優先度を算出してスケジューリング部１２へ出力する。優先度設定部１１３は、パラメータ受信部１１３１と、優先度計算部１１３２と、処理順序制御部１１３３から構成される。

図７は、優先度設定部１１３で行われる処理の一例を示すフローチャートである。

パラメータ受信部１１３１は、リクエスト分析部１１２から出力されたパラメータを受信し、ｒｅｑｕｅｓｔＩＤ３０１で、リクエストメッセージ毎のパラメータを識別する（Ｓ７１）。

パラメータ受信部１１３１は、リクエストメッセージのパラメータの受信が完了すると、リクエスト分析部１１２のリクエスト取得部１１２１にパラメータの受信終了のレスポンスを返し、リクエスト取得部１１２１に新しいリクエストメッセージを取得するよう通知する（Ｓ７２、Ｓ７３）。

パラメータ受信部１１３１は、パラメータが複数の場合は、全てのパラメータの受信が完了してからリクエスト取得部１１２１にレスポンスを返す。パラメータ受信部１１３１が受け取ったパラメータは優先度計算部１１３２に出力され、優先度計算部１１３２はパラメータを用いて可変優先度を計算する（Ｓ７４）。

実施例１の優先度計算部１１３２は、パラメータ内の実測レスポンス時間を、リクエストメッセージ３００で要求されたデータを取得する際の推定レスポンス時間として扱う。優先度計算部１１３２は、推定レスポンス時間が予め設定した閾値を超えているかを判断し、閾値を超える場合は、アプリ優先度（ｐｒｉｏｒｉｔｙ３０４）よりも優先順位を上げて、可変優先度（値は減少）を設定する。

優先順位を上げる程度は、アプリ優先度（３０４）の設定レンジ内（例えば、自然数で１～７）で、アプリ優先度（３０４）を１段階又は２段階だけ上げた可変優先度を設定することができる。そして、推定レスポンス時間が、閾値を超えると、優先度計算部１１３２が可変優先度を最優先（可変優先度＝１）に設定することができる。

すでに、アプリ優先度（３０４）が最優先順位（＝１）に相当する値であれば、優先度計算部１１３２は優先順位の変更はしない。優先度計算部１１３２は、推定レスポンス時間が閾値を超えない場合は、優先順位を変えずに、優先度計算部１１３２はアプリ優先度（３０４）で処理する。

又は、優先度計算部１１３２は、予め閾値を複数設定し、推定レスポンス時間が低い閾値（第１の閾値）を超えない場合は、優先度計算部１１３２が優先順位（可変優先度）を下げ、推定レスポンス時間が高い閾値（第２の閾値）を超える場合は、優先順位（可変優先度）を上げ、その間の場合は、優先順位を変えない方法もある。

又は、優先度計算部１１３２は、予め複数の閾値を設定し、推定レスポンス時間が低い閾値（第１の閾値）を超える場合は、優先順位を１段階上げた可変優先度を算出し、推定レスポンス時間が高い閾値（第２の閾値）を超える場合は、優先順位を２段階だけ上げた可変優先度を算出する方法もある。

優先度計算部１１３２は、外部データベース６からデータを取得する場合、受け取ったパラメータの外部アクセス判定結果が「Ｔｒｕｅ」である場合、推定レスポンス時間と閾値を比較し、可変優先度を設定するようにしてもよい。

また、優先度計算部１１３２は、受け取ったパラメータの外部アクセス判定結果が「Ｆａｌｓｅ」の場合は、アプリ優先度（３０４）のまま処理する。或いは、優先度計算部１１３２は、パラメータのうち外部アクセス判定結果の「Ｔｒｕｅ」又は「Ｆａｌｓｅ」のみ用いて、「Ｔｒｕｅ」の場合に優先順位を上げ、「Ｆａｌｓｅ」場合にはアプリ優先度（３０４）で処理することも可能である。

また、優先度計算部１１３２は、パラメータのうち外部アクセス判定結果の「Ｔｒｕｅ」又は「Ｆａｌｓｅ」のみ用いて、「Ｔｒｕｅ」の場合に優先順位を上げ、「Ｆａｌｓｅ」場合にはアプリ優先度（３０４）で処理することも可能である。

また、優先度計算部１１３２は、パラメータに外部アクセス判定結果の「Ｔｒｕｅ」が含まれる場合には、推定レスポンス時間と閾値に応じて可変優先度を算出し、パラメータが「Ｆａｌｓｅ」の場合にはアプリ優先度（３０４）の値を可変優先度に設定してもよい。

また、優先度設定部１１３は、リクエスト分析部１１２から受け付けたパラメータが、カテゴリ３０５２や属性（ｐｒｏｐｅｒｔｙ３０５４）の場合、推定レスポンス時間と閾値を用いて、優先度計算部１１３２で可変優先度を設定してもよい。

また、パラメータ検出部１１２４が、複数のリクエストメッセージ３００について推定レスポンス時間を取得して、複数のリクエストメッセージ３００と複数の推定レスポンス時間を優先度設定部１１３に出力することができる。この場合、パラメータ受信部１１３１で、複数のリクエストメッセージと複数の推定レスポンス時間を優先度計算部１１３２に出力し、優先度計算部１１３２は、複数のリクエストメッセージの推定レスポンス時間を比較して、推定レスポンス時間が最長時間か、推定レスポンス時間が長い上位いくつかの優先順位を上げて、可変優先度を設定する方法もある。

パラメータ受信部１１３１から、一定期間の間に貯められたリクエストメッセージのパラメータを優先度計算部１１３２に出力する場合、優先度計算部１１３２は、推定レスポンス時間が最長時間か、推定レスポンス時間が上位いくつかのリクエストメッセージか、推定レスポンス時間が上位何割かのリクエストメッセージの優先順位を上げることも可能である。

処理順序制御部１１３３は、算出された可変優先度（又はアプリ優先度（３０４））を含めて、スケジューリング部１２にリクエストメッセージ３００を送信する（Ｓ７５）。なお、処理順序制御部１１３３は、リクエストメッセージ３００のクエリ（ｑｕｅｒｙ３０５）と可変優先度（アプリ優先度）を送信すればよい。

スケジューリング部１２は、優先順位の異なる複数のキューで構成され、優先順位（可変優先度）の高いキューから優先的にデキューされるアルゴリズムでスケジューリングを実施する。

スケジューリング部１２からアクセス先のデータベース５又は外部データベース６にリクエストメッセージのクエリ（ｑｕｅｒｙ３０５）が送信されて、リクエストメッセージ３００で要求されたデータの取得が実施される。

以上のように実施例１のデータ要求処理装置１は、リクエストメッセージ３００の受信からレスポンスまでにかかった時間情報（推定レスポンス時間）と所定の閾値に基づいて、優先順位（可変優先度）を変更し、リクエストメッセージの処理を迅速化することで、端末１００から要求されたデータの取得までの時間を短縮することができる。

また、データ要求処理装置１は、外部データベース６へアクセスする場合（パラメータの外部アクセス判定結果が「Ｔｒｕｅ」）に、推定レスポンス時間と閾値を用いて可変優先度を算出し、推定レスポンス時間の長さに応じた優先順位を設定することで、データの仲介を行う際にネットワーク４やアクセスの状況に応じてダイナミックでかつ柔軟にデータを要求するリクエストの優先度を制御することが可能となる。

実施例２では、端末１００のアプリケーション２が、事故や災害のように発生時期が予想できない状況で優先度の変更を要求し、データ要求処理装置１が優先度の変更要求に応じて、優先順位を上げるための制御をリクエスト分析部１１２と、優先度設定部１１３で実施する例を説明する。

図９は、実施例２によるリクエスト分析部の構成を示す。

実施例２において、リクエスト分析部１１２は、リクエスト取得部１１２１と、アプリ優先度読み取り部１１２２と、クエリ読み取り部１１２３と、パラメータ検出部１１２４及び優先度変更要求取得部１１２７から構成される。パラメータ検出部１１２４は、優先度変更を管理するために入出力装置２５からの指令を受け付ける。

リクエスト取得部１１２１、アプリ優先度読み取り部１１２２、クエリ読み取り部１１２３は実施例１と同様である。実施例２のリクエスト分析部１１２は、前記実施例１のレスポンス時間計算部１１２６とレスポンス時間テーブル１１２５を削除し、優先度変更要求取得部１１２７を加えた点が実施例１と相違する。

図１０は、本発明の実施例２によるリクエスト分析部１１２の処理の一例を示すフローチャートである。この処理は、リクエスト受信部１１１から優先度変更要求を含むリクエストメッセージ３００を受け付けた場合に開始される。なお、優先度変更要求は、リクエストメッセージ３００と異なるメッセージであってもよい。

優先度変更要求取得部１１２７は、リクエスト受信部１１１から優先度変更を含むリクエストメッセージ３００を取得する（Ｓ９１）。優先度変更のリクエストメッセージ３００は、ａｐｐｒｉｃａｔｉｏｎＩＤ３０３と、アプリ優先度（ｐｒｉｏｒｉｔｙ３０４）と同様の形式（レンジなど）を含む要求優先度で構成される。優先度変更要求取得部１１２７は、リクエストメッセージ３００内の優先度変更要求を抽出してパラメータ検出部１１２４へ送信する。

パラメータ検出部１１２４は、優先度変更のリクエストを受け付ける（Ｓ９２）と、入出力装置２５へ優先度変更要求の可否を問い合せる（Ｓ９３）。入出力装置２５を利用する管理者は、通知を受けた入出力装置２５で、要求優先度への変更を許可（Ｔｒｕｅ）又は不可（Ｆａｌｓｅ）を決定し（Ｓ９４）、決定内容を応答に含めてパラメータ検出部１１２４に送信する（Ｓ９５）。

図１１は、本発明の実施例２によるリクエスト分析部１１２の処理の一例を示すフローチャートである。この処理は、入出力装置２５から優先度の変更の可否を受け付けた場合に開始される。

ステップＳ１０１～Ｓ１０４は前記実施例１の図５に示したステップＳ５１～Ｓ５４と同様の処理である。

入出力装置２５から許可又は拒否の応答を受け付けたパラメータ検出部１１２４は、優先度変更の可否が設定されたａｐｐｒｉｃａｔｉｏｎＩＤ３０３と同一のＩＤを含むアプリケーション２のリクエストメッセージ３００を取得し、優先度変更の可否が「Ｔｒｕｅ」（許可）であるかを判定し（Ｓ１０５）、「Ｔｒｕｅ」であればステップＳ１０６へ進み、「Ｆａｌｓｅ」（拒否）であればステップＳ１０７へ進む。

ステップＳ１０６では、パラメータ検出部１１２４が、優先度変更要求に含まれる要求優先度をパラメータとして生成し、優先度設定部１１３に出力する（Ｓ１０８）。一方、優先度変更が不可であれば、パラメータ検出部１１２４は０の値をパラメータとし（Ｓ１０７）、優先度設定部１１３に出力する（Ｓ１０８）。

優先度設定部１１３の優先度計算部１１３２は、受け付けたパラメータが０値であれば、アプリ優先度（３０４）をそのまま可変優先度に設定し、０でなければ、要求優先度を可変優先度に設定して出力する。

次に、リクエスト分析部１１２のリクエスト取得部１１２１は、優先度設定部１１３からパラメータの受信完了の通知（レスポンス）を待って処理を終了する（Ｓ１０９）。

なお、上記の他に、要求優先度は、通常時は「０」に設定され、予め設定された緊急時は「１」に設定しておき、緊急時には、可変優先度を最優先順位に設定することも可能である。

実施例２より、停電が起きた場合の電力インフラの保守アプリケーションや、洪水が起きた場合の下水道インフラの保守アプリケーションなど、平常より、優先されるべき事故や災害が発生した場合、それらのアプリケーション２が優先度変更を要求する場合に、データ要求処理装置１は当該アプリケーション２の優先順位を上げることが可能となる。なお、混雑度を計算するアプリケーション２が、都市内のイベントにより人の混雑発生した場合に、データ要求処理装置１が当該アプリケーション２の優先順位を上げるようにしてもよい。

実施例３は、アプリケーション２が様々なアプリケーションで利用された汎用性が高いデータにアクセスする場合に、過去のリクエストメッセージを用いて、優先順位を変更するためのパラメータを生成するリクエスト分析部１１２の例に関して説明する。

図１２は、実施例３によるリクエスト分析部１１２の構成の一例を示す。実施例３のリクエスト分析部１１２は、リクエスト取得部１１２１と、アプリ優先度読み取り部１１２２と、クエリ読み取り部１１２３と、パラメータ検出部１１２４及びリクエスト記録部１１２８から構成される。

リクエスト取得部１１２１、アプリ優先度読み取り部１１２２、クエリ読み取り部１１２３は実施例１と同様である。実施例３のリクエスト分析部１１２は、前記実施例１のレスポンス時間計算部１１２６とレスポンス時間テーブル１１２５を削除し、リクエスト記録部１１２８を加えた点が実施例１と相違する。

図１３は、実施例３によるリクエスト分析部の処理を示すフローチャートである。この処理は、リクエスト受信部１１１からリクエストメッセージ３００を受診した場合に実行される。

リクエスト取得部１１２１は、リクエスト受信部１１１に記録されているリクエストメッセージ３００を要求し、リクエストメッセージ３００を取得する（Ｓ１２１）。

リクエスト取得部１１２１は、取得したリクエストメッセージ３００をアプリ優先度読み取り部１１２２と、クエリ読み取り部に送信する（Ｓ１２２）。アプリ優先度読み取り部１１２２は、リクエストメッセージ３００からｒｅｑｕｅｓｔＩＤ３０１と、ｐｒｉｏｒｉｔｙ３０４を取得（Ｓ１２３）し、優先度設定部１１３に出力する（Ｓ１２７）。

クエリ読み取り部１１２３は、ｒｅｑｕｅｓｔＩＤ３０１と、ｒｅｑｕｅｓｔＴｉｍｅ３０２と、ａｐｐｒｉｃａｔｉｏｎＩＤ３０３と、クエリ３０５をリクエストメッセージ３００から取得優先度変更要求（Ｓ１２４）し、取得した情報をリクエスト記録部１１２８に記録を行う。また、クエリ読み取り部１１２３は、取得した情報をパラメータ検出部１１２４に出力する。

リクエスト記録部１１２８は過去のリクエストメッセージ３００のｒｅｑｕｅｓｔＴｉｍｅ３０２と、ａｐｐｒｉｃａｔｉｏｎＩＤ３０３と、ｑｕｅｒｙ３０５を記録する。リクエスト記録部１１２８は、ＳＳＤのような記憶装置か、ＤＲＡＭのように揮発性の記憶装置で構成することも可能である。

パラメータ検出部１１２４は、リクエスト記録部１１２８にアクセスして、ステップＳ１２４で取得したｒｅｑｕｅｓｔＴｉｍｅ３０２よりも過去のリクエストメッセージ３００を検索する（Ｓ１２５）。パラメータ検出部１１２４は、検索結果を用いてパラメータを生成する（Ｓ１２６）。パラメータ検出部１１２４は、生成されたパラメータを優先度設定部１１３に出力する（Ｓ１２７）。

例えば、汎用性の高いデータを要求する場合、パラメータ検出部１１２４は、ｒｅｑｕｅｓｔＴｉｍｅ３０２より一定期間の過去で、ａｐｐｒｉｃａｔｉｏｎＩＤ３０３が異なり、かつｑｕｅｒｙ３０５の同じデータを要求したリクエストメッセージ３００を検索しする。

パラメータ検出部１１２４は、同じデータを利用しているアプリケーションの数を特定し、アプリケーションの数が多い（又は最大）リクエストメッセージ３００のｑｕｅｒｙ３０５からパラメータを生成し（Ｓ１２６）、優先度設定部１１３に送信する（Ｓ１２７）。

次に、リクエスト分析部１１２のリクエスト取得部１１２１は、優先度設定部１１３からパラメータの受信完了の通知（レスポンス）を待って処理を終了する（Ｓ１２８）。

なお、特定したアプリケーション数は毎回のリクエストメッセージ３００に対して算出するか、算出したアプリケーション数をリクエスト記録部１１２８に一定時間記録しておいて、以降のリクエストメッセージ３００はその値をパラメータとして設定する方法もある。優先度設定部１１３の優先度計算部１１３２は、実施例１と同様の方法で、可変優先度の設定を実施する。

実施例３により、過去のリクエストメッセージ３００の情報を用いて、優先順位を上げ、リクエストメッセージ３００の処理を迅速化することで、データ取得までの時間を短縮することができる。

＜結び＞
以上のように、上記実施例のデータ要求処理装置１は、以下のような構成とすることができる。

（１）プロセッサ（２１）とメモリを有するデータ要求処理装置（１）であって、データベース（５又は外部データベース６）に格納されているデータをリクエストするメッセージ（リクエストメッセージ３００）を受信し、前記メッセージ（３００）に含まれるデータ要求（ｑｕｅｒｙ３０５）に優先度（可変優先度）を設定して、前記優先度に応じて前記データ要求（３０５）の処理順序を決定する優先度制御部（１１）を有し、前記優先度制御部（１１）は、前記メッセージ（３００）を受信する受信部（リクエスト受信部１１１）と、前記メッセージ（３００）に含まれるデータ要求（３０５）を取得し、前記データ要求（３０５）を分析して、前記優先度の設定に必要なパラメータ（推定レスポンス時間（実測レスポンス時間１２０４）又は外部アクセス判定結果）を生成する分析部（リクエスト分析部１１２）と、前記パラメータ（１２０４又は外部アクセス判定結果）を用いて前記データ要求（３０５）に優先度を設定する優先度設定部（１１３）と、を有し、前記優先度設定部（１１３）は、前記パラメータ（１２０４又は外部アクセス判定結果）を受け付けて、所定のルールで前記パラメータ（１２０４又は外部アクセス判定結果）を分類し、前記分類の結果に応じて前記データ要求（３０５）の優先度（可変優先度）を設定することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、パラメータ（１２０４又は外部アクセス判定結果）の状況に応じてダイナミックでかつ柔軟にリクエストの優先度を制御して、リアルタイム性が必要なアプリケーションは安定的にデータを取得することができる。

（２）上記（１）に記載のデータ要求処理装置であって、前記分析部（１１２）は、過去に算出されたレスポンス時間（実測レスポンス時間１２０４）を蓄積したテーブル（レスポンス時間テーブル１１２５）を参照し、前記データ要求（３０５）に対応するレスポンス時間（１２０４）を取得して前記パラメータとして出力し、前記優先度設定部（１１３）は、前記レスポンス時間（推定レスポンス時間）に応じて前記データ要求（３０５）に前記優先度を設定することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、レスポンスまでにかかった時間情報（推定レスポンス時間）に基づいて、優先順位（可変優先度）を変更し、リクエストメッセージの処理を迅速化することで、端末１００から要求されたデータの取得までの時間を短縮することができる。

（３）上記（２）に記載のデータ要求処理装置であって、前記優先度設定部（１１３）が設定した前記優先度に応じた前記データ要求（３０５）を前記データベース（５、６）に送信するスケジューリング部（１２）を、さらに有し、前記分析部（１１２）は、前記データ要求（３０５）が前記スケジューリング部（１２）で送信されてから前記データベース（５、６）からの応答を受け付けるまでの時間をレスポンス時間（１２０４）として計算して前記テーブル（１１２５）に蓄積するレスポンス時間計算部（１１２６）を、さらに有することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、レスポンスまでにかかった時間情報（推定レスポンス時間）に基づいて、優先順位（可変優先度）を変更し、リクエストメッセージの処理を迅速化することで、端末１００から要求されたデータの取得までの時間を短縮することができる。

（４）上記（１）に記載のデータ要求処理装置であって、 前記優先度設定部（１１３）は、前記分析部（１１２）から出力されたパラメータ（１２０４又は外部アクセス判定結果）と、予め設定された閾値とを比較して、前記比較の結果に応じて前記データ要求（３０５）の前記優先度を設定することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、レスポンスまでにかかった時間情報（推定レスポンス時間）と所定の閾値に基づいて、優先順位（可変優先度）を変更し、リクエストメッセージの処理を迅速化することで、端末１００から要求されたデータの取得までの時間を短縮することができる。

（５）上記（２）に記載のデータ要求処理装置であって、前記分析部（１１２）は、複数の前記データ要求（３０５）について前記レスポンス時間を取得して、前記複数のメッセージと複数の前記レスポンス時間を前記優先度設定部（１１３）に出力し、前記優先度設定部（１１３）は、前記複数のレスポンス時間に応じて、前記複数のデータ要求（３０５）の優先度を設定することを特徴とするデータ要求処理装置。

上記構成により、パラメータ検出部１１２４が、複数のリクエストメッセージ３００について推定レスポンス時間を取得して、複数のリクエストメッセージ３００と複数の推定レスポンス時間を優先度設定部１１３に出力することができる。この場合、パラメータ受信部１１３１で、複数のリクエストメッセージと複数の推定レスポンス時間を優先度計算部１１３２に出力し、優先度計算部１１３２は、複数のリクエストメッセージの推定レスポンス時間を比較して、推定レスポンス時間が最長時間か、推定レスポンス時間が長い上位いくつかの優先順位を上げることができる。

また、パラメータ受信部１１３１から、一定期間の間に貯められたリクエストメッセージのパラメータ（１２０４又は外部アクセス判定結果）を優先度計算部１１３２に出力する場合、優先度計算部１１３２は、推定レスポンス時間が最長時間か、推定レスポンス時間が上位いくつかのリクエストメッセージか、推定レスポンス時間が上位何割かのリクエストメッセージの優先順位を上げることも可能である。

（６）上記（２）に記載のデータ要求処理装置であって、前記受信部は、前記優先度の変更要求を受信し、前記分析部（１１２）は、前記優先度の変更要求の可否の問い合せを出力し、前記問い合せに対する応答を受け付け、当該応答の内容（Ｔｒｕｅ又はＦａｌｓｅ）を前記優先度設定部（１１３）に出力し、前記優先度設定部（１１３）は、前記応答の内容に応じて前記優先度を設定することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、停電が起きた場合の電力インフラの保守アプリケーションや、洪水が起きた場合の下水道インフラの保守アプリケーションなど、平常より、優先されるべき事故や災害が発生した場合、それらのアプリケーション２が優先度変更を要求する場合に、データ要求処理装置１は当該アプリケーション２の優先順位を上げることが可能となる。

（７）上記（６）に記載のデータ要求処理装置であって、前記分析部（１１２）は、前記問い合せに対する応答がＴｒｕｅを含む場合には、前記優先度設定部（１１３）に前記優先度の変更要求を通知し、前記優先度設定部（１１３）は、前記通知に応じて前記優先度を設定することを特徴とするデータ要求処理装置。

上記構成により、優先度設定部１１３の優先度計算部１１３２は、受け付けたパラメータ（１２０４）が０値であれば、アプリ優先度（３０４）をそのまま可変優先度に設定し、０でなければ、要求優先度を可変優先度に設定して出力することができる。

（８）上記（１）に記載のデータ要求処理装置であって、前記分析部（１１２）は、過去のメッセージ（３００）に含まれるデータ要求（３０５）を記録する記録部（１１２８）と、前記記録部（１１２８）から過去のデータ要求（３０５）を検索して、前記パラメータ（１２０４又は外部アクセス判定結果）を生成する検出部（パラメータ検出部１１２４）と、を有することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、過去のリクエストメッセージ３００の情報を用いて、優先順位を上げ、リクエストメッセージ３００の処理を迅速化することで、データ取得までの時間を短縮することができる。

（９）上記（１）に記載のデータ要求処理装置であって、上記（８）に記載のデータ要求処理装置であって、前記検出部（１１２４）は、前記記録部（１１２８）から、異なるアプリケーションで、かつ、前記データ要求（３０５）と同一のデータを要求した過去のデータ要求（３０５）を検索し、前記アプリケーションの数を取得し、前記アプリケーションの数が所定の条件を満たすデータ要求（３０５）からパラメータを生成することを特徴とするデータ要求処理装置。

上記構成により、データ要求処理装置１は、アプリケーションの数が所定の条件（例えば、最大）を満たすデータ要求からパラメータ（１２０４又は外部アクセス判定結果）を生成することができ、過去のリクエストメッセージ３００の情報を用いて、優先順位を上げ、リクエストメッセージ３００の処理を迅速化することで、データ取得までの時間を短縮することができる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。

また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１ データ要求処理装置
２ アプリケーション
３、４ ネットワーク
５ データベース
６ 外部データベース
７ データ送信部
１１ 優先度制御部
１２ スケジューリング部
１１１ リクエスト受信部
１１２ リクエスト分析部
１１３ 優先度設定部
１１４ 管理部
３００ リクエストメッセージ
１１２１ リクエスト取得部
１１２２ アプリ優先度読み取り部
１１２３ クエリ読み取り部
１１２４ パラメータ検出部
１１２５ パラメータテーブル
１１２６ レスポンス時間計算部
１１２７ 優先度変更要求取得部
１１２８ リクエスト記録部
１１３１ パラメータ受信部
１１３２ 優先度計算部
１１３３ 処理順序制御部

Claims (4)

1. プロセッサとメモリを有するデータ要求処理装置であって、
   データベースに格納されているデータをリクエストするメッセージを受信し、前記メッセージに含まれるデータ要求に優先度を設定して、前記優先度に応じて前記データ要求の処理順序を決定する優先度制御部を有し、
   前記優先度制御部は、
   前記メッセージを受信する受信部と、
   前記メッセージに含まれるデータ要求を取得し、前記データ要求を分析して前記優先度の設定に必要なパラメータを生成する分析部と、
   前記パラメータを用いて前記データ要求に優先度を設定する優先度設定部と、を有し、
   前記優先度設定部は、
   前記パラメータを受け付けて、所定のルールで前記パラメータを分類し、前記分類の結果に応じて前記データ要求の優先度を設定し、
   前記分析部は、
   過去のメッセージに含まれるデータ要求を記録する記録部と、
   前記記録部から過去のデータ要求を検索して、前記パラメータを生成する検出部と、を有し、
   前記検出部は、
   前記記録部から、異なるアプリケーションで、かつ、前記データ要求と同一のデータを要求した過去のデータ要求を検索し、前記アプリケーションの数を取得し、前記アプリケーションの数が所定の条件を満たすデータ要求からパラメータを生成することを特徴とするデータ要求処理装置。
2. 請求項１に記載のデータ要求処理装置であって、
   前記優先度設定部は、
   前記分析部から出力されたパラメータと、予め設定された閾値とを比較して、前記比較の結果に応じて前記データ要求の前記優先度を設定することを特徴とするデータ要求処理装置。
3. プロセッサとメモリを有する計算機で、データ要求を処理するデータ要求処理方法であって、
   前記計算機が、データベースに格納されているデータをリクエストするメッセージを受信する受信ステップと、
   前記計算機が、前記メッセージに含まれるデータ要求を取得し、前記データ要求を分析して優先度の設定に必要なパラメータを生成する分析ステップと、
   前記計算機が、前記パラメータを受け付けて、所定のルールで前記パラメータを分類し、前記分類の結果に応じて前記データ要求の前記優先度を設定して、前記優先度に応じて前記データ要求の処理順序を決定する優先度設定ステップと、
   を含み、
   前記分析ステップは、
   過去のメッセージに含まれるデータ要求を記録する記録ステップと、
   前記記録ステップで記録された過去のデータ要求を検索して、前記パラメータを生成する検出ステップと、を含み、
   前記検出ステップは、前記記録ステップで記録された過去のデータ要求において、異なるアプリケーションで、かつ、前記データ要求と同一のデータを要求した過去のデータ要求を検索し、前記アプリケーションの数を取得し、前記アプリケーションの数が所定の条件を満たすデータ要求からパラメータを生成することを特徴とするデータ要求処理方法。
4. プロセッサとメモリを有する計算機で、データ要求を処理させるためのプログラムを格納した記憶媒体であって、
   データベースに格納されているデータをリクエストするメッセージを受信する受信ステップと、
   前記メッセージに含まれる前記データ要求を取得し、前記データ要求を分析して優先度の設定に必要なパラメータを生成する分析ステップと、
   前記パラメータを受け付けて、所定のルールで前記パラメータを分類し、前記分類の結果に応じて前記データ要求の前記優先度を設定して、前記優先度に応じて前記データ要求の処理順序を決定する優先度設定ステップと、を含み、
   前記分析ステップは、
   過去のメッセージに含まれるデータ要求を記録する記録ステップと、
   前記記録ステップで記録された過去のデータ要求を検索して、前記パラメータを生成する検出ステップと、を含み、
   前記検出ステップは、前記記録ステップで記録された過去のデータ要求において、異なるアプリケーションで、かつ、前記データ要求と同一のデータを要求した過去のデータ要求を検索し、前記アプリケーションの数を取得し、前記アプリケーションの数が所定の条件を満たすデータ要求からパラメータを生成する、処理を前記計算機に実行させるためのプログラムを格納した非一時的な計算機読み取り可能な記憶媒体。

Images