WO2013175607A1

WO2013175607A1 - 通信システム、クライアント端末及びサーバ装置

Info

Publication number: WO2013175607A1
Application number: PCT/JP2012/063314
Authority: WO
Inventors: 淳平羽藤
Original assignee: 三菱電機株式会社
Priority date: 2012-05-24
Filing date: 2012-05-24
Publication date: 2013-11-28
Also published as: JP5781225B2; JPWO2013175607A1; DE112012006414T5; US9680719B2; CN104220996A; US20150026244A1; CN104220996B

Abstract

　ＧＵＩ処理装置３２により発行された実行要求に対応する応答が応答記憶装置３１に記憶されていれば、その応答をＧＵＩ処理装置３２に出力する旨を指示する出力指令を出力する一方、その実行要求に対応する応答が応答記憶装置３１に記憶されていなければ、その実行要求に続いて発行される可能性がある要求の予測を行って、その実行要求と予測要求からなる要求パターンの生成を要求パターン管理装置３４に指示し、要求パターン管理装置３４により生成された要求パターンを含む一括要求を生成する一括要求処理装置３３を備えている。

Description

通信システム、クライアント端末及びサーバ装置

　この発明は、サービスの実行要求を発行するクライアント端末と、実行要求に対応するサービスの処理結果をクライアント端末に返信するサーバ装置と、クライアント端末及びサーバ装置からなる通信システムとに関するものである。

　組み込み機器上でＧＵＩ（Ｇｒａｐｈｉｃａｌ　Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）を持つアプリケーションを動作させる場合、従来は、アプリケーションの挙動を規定するサービスロジックとＧＵＩを同一の組み込み機器に実装し、そのサービスロジックとＧＵＩを連携動作させる方式が主流である。
　ただし、ＰＣ（Ｐｅｒｓｏｎａｌ　Ｃｏｍｐｕｔｅｒ）を中心とする環境では、インターネットを代表とするネットワーク技術を利用し、サービスロジックとＧＵＩをネットワーク上の別ノードに実装するサーバ・クライアント方式が主流になってきている。
　具体的には、サービスロジックをサーバ装置（ノード）に実装して、ＧＵＩをクライアント端末（ノード）に実装し、クライアント端末がネットワーク経由でサーバ装置にアクセスすることで連携動作を実現し、その結果、１つのアプリケーションを構成することが考えられる。

　近年、無線ネットワーク技術の普及によって、組み込み機器でも、常時ネットワークに接続可能な環境が整いつつある。また、組み込み機器の処理性能の向上が進んでいる。
　このため、サーバ・クライアント方式のアプリケーションを組み込み機器上で実現することが現実的になってきている。
　しかし、従来は、同一ノード内のプロセス間通信によって、サービスロジックとＧＵＩが連携動作していたが、ネットワーク間通信での連携に変更する必要があるため、その連携処理がボトルネックになる。そのため、連携処理に係るネットワーク通信の回数を削減するなどの対策が必要となる。

　以下の特許文献１には、クライアント端末に表示されるＧＵＩの画面単位に、その画面上での利用者の操作をクライアント端末が予測し、その操作が実際に行われる前に、その操作で必要となる連携処理を予め実行しておくことで、操作発生時に通信処理が発生しないようにしている通信システムが開示されている。
　ただし、この通信システムでは、ＧＵＩの画面が表示された直後にだけ、利用者の操作を予測するものであり、利用者の操作に伴って画面が遷移しなければ、再度の予測が行われない。
　そのため、同一画面を長時間表示するようなアプリケーションでは、連携処理に係るネットワーク通信の回数を十分に削減することができない。

　また、特許文献２には、以下の通信システムが開示されている。
　クライアント端末から何らかの処理の実行要求が発行された場合、サーバ装置が、その実行要求に付随して要求される可能性のある処理を予測して、実際に発行された実行要求に対応する処理を実行するとともに、付随して要求（以下、「予測要求」と称する）される可能性のある処理を実行する。
　サーバ装置は、実際に発行された実行要求に対応する処理結果をクライアント端末に返信した後、順次、予測要求に対応する処理結果をクライアント端末に返信する。

　クライアント端末では、サーバ装置における予測が的中していれば、サーバ装置から返信されている予測要求に対応する処理結果を利用することが可能であるため、新たな実行要求をサーバ装置に送信する必要がなくなり、連携処理に係るボトルネックを軽減することができる。
　しかし、サーバ装置が、予測要求に対応する処理結果をクライアント端末に返信する際、実際に発行された実行要求から予測される要求数が増加すると、通信処理負荷が増大する。
　また、クライアント端末では、サーバ装置が如何なる要求を予測しているのかが不明であるため、サーバ装置から予測要求に対応する処理結果を受信する前に、クライアント端末が当該予測要求と同じ要求を発行してしまう可能性がある。
　クライアント端末が予測要求と同じ要求を発行してしまうと、通信回数を削減することができない。また、サーバ装置では、同じ要求に対応する処理を複数回実行する必要が生じる。

特開平７－１６０４６２号公報（段落番号［００１７］から［００１９］）特開２００５－２２８２２８号公報（段落番号［００２１］［００３７］）

　従来の通信システムは以上のように構成されているので、特許文献１の場合、利用者の操作に伴って画面が遷移しなければ、再度の予測が行われない。そのため、同一画面を長時間表示するようなアプリケーションでは、連携処理に係るネットワーク通信の回数を十分に削減することができない課題があった。
　また、特許文献２の場合、実際に発行された実行要求から予測される要求数が増加すると、予測要求に対応する処理結果の通信負荷が増大する課題があった。また、クライアント端末では、サーバ装置が如何なる要求を予測しているのかが不明であるため、サーバ装置から予測要求に対応する処理結果を受信する前に、クライアント端末が当該予測要求と同じ要求を発行してしまう可能性があり、クライアント端末が予測要求と同じ要求を発行してしまうと、通信回数を削減することができない課題があった。

　この発明は上記のような課題を解決するためになされたもので、連携処理に係るネットワーク通信の回数を十分に削減することができる通信システムを得ることを目的とする。

　この発明に係る通信システムは、クライアント端末が、サーバ装置から返信された応答を記憶する応答記憶手段と、サービスの実行要求を発行する実行要求発行手段と、実行要求発行手段により発行された実行要求に対応する応答が応答記憶手段に記憶されていれば、その応答を実行要求発行手段に出力する旨を指示する出力指令を出力する一方、その実行要求に対応する応答が応答記憶手段に記憶されていなければ、その実行要求に続いて発行される可能性がある要求を予測し、その予測要求と上記実行要求からなる要求パターンを生成する要求パターン生成手段と、要求パターン生成手段により生成された要求パターンをサーバ装置に送信する一方、その要求パターンを構成している実行要求及び予測要求に対応するサーバ装置から送信された応答を受信する通信手段と、要求パターン生成手段から出力指令を受けると、応答記憶手段に記憶されている実行要求に対応する応答を実行要求発行手段に出力し、通信手段により実行要求及び予測要求に対応する応答が受信されると、その実行要求及び予測要求に対応する応答を応答記憶手段に格納するとともに、その実行要求に対応する応答を実行要求発行手段に出力する応答処理手段とから構成されているようにしたものである。

　この発明によれば、実行要求発行手段により発行された実行要求に対応する応答が応答記憶手段に記憶されていれば、その応答を実行要求発行手段に出力する旨を指示する出力指令を出力する一方、その実行要求に対応する応答が応答記憶手段に記憶されていなければ、その実行要求に続いて発行される可能性がある要求を予測し、その予測要求と上記実行要求からなる要求パターンを生成する要求パターン生成手段と、要求パターン生成手段により生成された要求パターンをサーバ装置に送信する一方、その要求パターンを構成している実行要求及び予測要求に対応するサーバ装置から送信された応答を受信する通信手段とを設け、応答処理手段が、要求パターン生成手段から出力指令を受けると、応答記憶手段に記憶されている実行要求に対応する応答を実行要求発行手段に出力し、通信手段により実行要求及び予測要求に対応する応答が受信されると、その実行要求及び予測要求に対応する応答を応答記憶手段に格納するとともに、その実行要求に対応する応答を実行要求発行手段に出力するように構成したので、実行要求に対応する応答が応答記憶手段に記憶されていれば、その実行要求を送信する必要がなくなり、その結果、連携処理に係るネットワーク通信の回数を十分に削減することができる効果がある。

この発明の実施の形態１による通信システムを示す構成図である。この発明の実施の形態１による通信システムに適用するＧＵＩノード１のＧＵＩ処理モジュール１１を示す構成図である。この発明の実施の形態１による通信システムに適用するサービスノード２のサービス提供モジュール２２を示す構成図である。ＧＵＩノード１におけるＧＵＩ処理装置３２の処理シーケンス（ＡＰＩ実行要求に対応する応答の記憶がない場合）を示すシーケンス図である。ＧＵＩノード１におけるＧＵＩ処理装置３２の処理シーケンス（ＡＰＩ実行要求に対応する応答の記憶がある場合）を示すシーケンス図である。一括要求処理装置３３がＡＰＩ実行要求であるのか、ＡＰＩ実行要求以外の要求であるのかを判定する処理を示すフローチャートである。サービスノード２におけるサービス提供モジュール２２の処理シーケンスを示すシーケンス図である。要求パターンのデータ構造を示す説明図である。実要求情報リストのデータ構造を示す説明図である。後続要求パターンリストのデータ構造を示す説明図である。実要求情報リストデータ構造及び後続要求パターンリストデータ構造を用いた具体的な要求パターンの一例を示す説明図である。処理対象リストの参照例を示す説明図である。要求パターン取得時の要求時系列解析結果の更新処理を示すフローチャートである。実要求通知時の要求時系列解析結果の更新処理を示すフローチャートである。処理対象リストの参照例を示す説明図である。処理対象リストの参照例を示す説明図である。予測要求パターンの組み合わせ例を示す説明図である。ＵＲＬによるＡＰＩの識別情報の記述例を示す説明図である。ＵＲＬによるＡＰＩの識別情報の記述例を示す説明図である。単一のサービスに対する複数のＡＰＩと、各ＡＰＩに対する複数の引数リストを１つのテキスト形式データで表現している具体例を示す説明図である。一括要求表現形式例を示す説明図である。応答の具体的なデータ表現例を示す説明図である。一括応答の具体的なデータ表現例を示す説明図である。ＧＵＩに表示される地図画像の一例を示す説明図である。地図更新に伴う要求例を示すシーケンス図である。縮尺変更に伴う要求例を示すシーケンス図である。ＧＵＩに表示される地図画像の一例を示す説明図である。図２７の画面に伴う要求例を示すシーケンス図である。画面単位で独立した要求パターン管理を行う場合の要求時系列解析結果のデータ構造例を示す説明図である。予測要求パターン数を最大５個までとした場合の要求パターンデータの生成例を示す説明図である。前回の要求通知から今回の要求通知までの経過時間を算出する処理を示すフローチャートである。経過時間を利用した場合の要求パターンデータの生成例を示す説明図である。応答提供管理テーブルの一例を示す説明図である。応答削除要求イベントの記述例を示す説明図である。応答更新要求イベントの記述例を示す説明図である。

　以下、この発明をより詳細に説明するために、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
　図１はこの発明の実施の形態１による通信システムを示す構成図である。
　図１において、クライアント端末であるＧＵＩノード１はＧＵＩを実装し、システムのＧＵＩ制御を行うノードである。
　即ち、ＧＵＩノード１はネットワーク３経由でサービスノード２と連携して、システムとしてのサービスを実現するノードであり、具体的には、サービスの実行要求をネットワーク３経由でサービスノード２に発行して、サービスノード２からネットワーク３経由で実行要求に対応するサービスの処理結果である応答を取得する。
　サーバ装置であるサービスノード２はシステムとして実現するサービスのロジック処理を行うノードであり、具体的には、クライアント端末１により発行された実行要求に対応するサービスを実行して、そのサービスの処理結果である応答を生成し、その応答をネットワーク３経由でクライアント端末１に返信する。

　ＧＵＩノード１はＧＵＩに関する制御全般を行うＧＵＩ処理モジュール１１と、ＧＵＩを表示するディスプレイ１２と、例えばＧＵＩ処理に反映させる各種情報の入力を受け付ける入力インタフェース１３と、例えばスピーカを含む音声出力機器等が接続されている出力インタフェース１４とから構成されている。
　ただし、ディスプレイ１２、入力インタフェース１３及び出力インタフェース１４は、ＧＵＩノード１内に存在していなくてもよく、必要に応じてネットワーク３に接続されている別ノード上に分散して配置しても構わない。その場合には、ＧＵＩノード１は、ネットワーク３経由で別ノードと連携動作することになる。

　この実施の形態１では、ＧＵＩノード１がコンピュータで構成されているものを想定しているので、事前に、後述するＧＵＩ処理モジュール１１の処理内容を示すプログラムをコンピュータのメモリに格納しておき、コンピュータのＣＰＵが当該メモリに格納されているプログラムを実行することで、ＧＵＩ処理モジュール１１を構築するものとする。
　なお、ＧＵＩ処理モジュール１１の内部構成は後述するが、ＧＵＩ処理モジュール１１の構成要素のそれぞれを専用のハードウェア（例えば、ＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコン）で構成するようにしてもよい。

　サービスノード２は各種の実行要求に対応するサービスを実行し、そのサービスの処理結果である応答を生成するサービスモジュール２１ａ，２１ｂ，２１ｃと、ＧＵＩノード１とネットワーク間通信を実施し、ＧＵＩノード１から送信された実行要求に対応する応答をＧＵＩノード１に返信する処理などを行うサービス提供モジュール２２とから構成されている。
　図１では、サービスノード２が３つのサービスモジュール２１ａ，２１ｂ，２１ｃを実装している例を示しているが、サービスモジュールの実装数は３つに限るものではなく、３つ未満でも、４つ以上でもよい。

　この実施の形態１では、サービスノード２がコンピュータで構成されているものを想定しているので、事前に、後述するサービス提供モジュール２２及びサービスモジュール２１ａ，２１ｂ，２１ｃの処理内容を示すプログラムをコンピュータのメモリに格納しておき、コンピュータのＣＰＵが当該メモリに格納されているプログラムを実行することで、サービス提供モジュール２２及びサービスモジュール２１ａ，２１ｂ，２１ｃを構築するものとする。
　なお、サービス提供モジュール２２の内部構成は後述するが、サービス提供モジュール２２の構成要素のそれぞれを専用のハードウェア（例えば、ＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコン）で構成するようにしてもよい。

　サービスモジュール２１ａ，２１ｂ，２１ｃは、サービス仕様で定義されている機能を呼び出すためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を一つ以上有しており、どのタイミングで、どのＡＰＩを実行するかは、（１）サービスノード２の内部制御ロジックに従う場合と、（２）ＧＵＩノード１から送信されるＡＰＩ実行要求に従って決まる場合の２通りが存在する。
　（１）の場合には、各サービスモジュールが有するＡＰＩを実行するが、（２）の場合には、ＧＵＩノード１から送信されたＡＰＩ実行要求を受信したサービス提供モジュール２２が実行する。
　本発明は、（２）の場合に関するものであるため、明細書中では、（１）の場合については言及しない。

　図２はこの発明の実施の形態１による通信システムに適用するＧＵＩノード１のＧＵＩ処理モジュール１１を示す構成図である。
　図２において、応答記憶装置３１は例えばＲＡＭやハードディスクなどの記録媒体から構成されており、サービスノード２からネットワーク３経由で返信された応答を記憶する処理を実施する。なお、応答記憶装置３１は応答記憶手段を構成している。

　ＧＵＩ処理装置３２は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、ＡＰＩ実行要求（サービスの実行要求）を発行して、そのＡＰＩ実行要求に対応する応答を取得し、その応答をディスプレイ１２に表示する処理を実施する。
　ここでは、ＡＰＩ実行要求に対応する応答をディスプレイ１２に表示する例を示しているが、その応答を音声で出力するようにしてもよい。具体的には、その応答を音声データに変換して、その音声データを出力インタフェース１４に出力し、その出力インタフェース１４に接続されている各種機器が音声データを解釈して、スピーカ等から音声を出力するようにすればよい。
　なお、ＧＵＩ処理装置３２は実行要求発行手段を構成している。

　一括要求処理装置３３は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、ＧＵＩ処理装置３２により発行されたＡＰＩ実行要求に対応する応答が応答記憶装置３１に記憶されていれば、その応答をＧＵＩ処理装置３２に出力する旨を指示する出力指令を応答処理装置３６に出力する一方、そのＡＰＩ実行要求に対応する応答が応答記憶装置３１に記憶されていなければ、そのＡＰＩ実行要求に続いて発行される可能性がある要求（以下、「予測要求」と称する）の予測を行って、そのＡＰＩ実行要求と予測要求からなる要求パターンの生成を要求パターン管理装置３４に指示し、要求パターン管理装置３４により生成された要求パターンを通信装置３５に出力する処理を実施する。

　要求パターン管理装置３４は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、ＡＰＩ実行要求の時系列パターンを動的解析して、その要求時系列解析結果を管理する機能を備えており、その要求時系列解析結果を参照して、一括要求処理装置３３から出力されたＡＰＩ実行要求に続いて発行される可能性がある要求を予測し、そのＡＰＩ実行要求と予測要求からなる要求パターンを生成する処理を実施する。
　なお、一括要求処理装置３３及び要求パターン管理装置３４から要求パターン生成手段が構成されている。

　通信装置３５はネットワーク３に対するインタフェース機器であり、要求パターン管理装置３４により生成されて、一括要求処理装置３３から出力された要求パターンをネットワーク３経由でサービスノード２に送信する一方、その要求パターンを構成しているＡＰＩ実行要求及び予測要求に対応するサービスノード２から送信された応答を受信する処理を実施する。なお、通信装置３５は通信手段を構成している。
　応答処理装置３６は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、一括要求処理装置３３から出力指令を受けると、応答記憶装置３１に記憶されているＡＰＩ実行要求に対応する応答をＧＵＩ処理装置３２に出力する処理を実施する。
　また、応答処理装置３６は通信装置３５により受信されたＡＰＩ実行要求及び予測要求に対応する応答を応答記憶装置３１に格納するとともに、そのＡＰＩ実行要求に対応する応答をＧＵＩ処理装置３２に出力する処理を実施する。なお、応答処理装置３６は応答処理手段を構成している。

　ここでは、ＧＵＩ処理モジュール１１の構成要素である応答記憶装置３１、ＧＵＩ処理装置３２、一括要求処理装置３３、要求パターン管理装置３４、通信装置３５及び応答処理装置３６のそれぞれが専用のハードウェアで構成されている例を示しているが、ＧＵＩ処理装置３２、一括要求処理装置３３、要求パターン管理装置３４、通信装置３５及び応答処理装置３６のそれぞれがソフトウェアで構築されていてもよい。
　その場合には、ＧＵＩ処理装置３２、一括要求処理装置３３、要求パターン管理装置３４、通信装置３５及び応答処理装置３６の処理内容を記述しているプログラムをＧＵＩノード１のメモリに格納し、ＧＵＩノード１のＣＰＵが当該メモリに格納されているプログラムを実行するようにすればよい。

　図３はこの発明の実施の形態１による通信システムに適用するサービスノード２のサービス提供モジュール２２を示す構成図である。
　図３において、通信装置４１はネットワーク３に対するインタフェース機器であり、ＧＵＩノード１から送信された要求パターンを受信する一方、その要求パターンを構成しているＡＰＩ実行要求及び予測要求に対応する応答をネットワーク経由３でＧＵＩノード１にまとめて返信する処理を実施する。なお、通信装置４１は要求パターン受信手段及び応答送信手段を構成している。

　一括要求解釈装置４２は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、通信装置４１により受信された要求パターンを構成しているＡＰＩ実行要求及び予測要求を分解して、個々の要求を要求処理装置４３に出力する一方、要求処理装置４３から出力された個々の要求に対応する応答を一括応答生成装置４５に出力し、一括応答生成装置４５により生成された一括応答（個々の要求に対応する応答がまとめられている応答）を通信装置４１に出力する処理を実施する。

　要求処理装置４３は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、一括要求解釈装置４２から出力された個々の要求毎に、当該要求に対応するサービスを実行するサービスモジュール２１を特定して、当該要求を当該サービスモジュール２１に対応するサービス実行装置４４に与える一方、そのサービス実行装置４４から出力された応答を取得して、その応答を一括要求解釈装置４２に出力する処理を実施する。
　例えば、当該要求に対応するサービスを実行するサービスモジュール２１がサービスモジュール２１ａであれば、当該要求をサービス実行装置４４ａに与えて、そのサービス実行装置４４ａから当該要求に対応する応答を一括要求解釈装置４２に出力する。

　サービス実行装置４４ａは例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、要求処理装置４３から出力された要求をサービスモジュール２１ａに与えることで、その要求に対応するサービスを実行させて、サービスモジュール２１ａからサービスの処理結果である応答を取得し、その応答を要求処理装置４３に出力する処理を実施する。
　サービス実行装置４４ｂは例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、要求処理装置４３から出力された要求をサービスモジュール２１ｂに与えることで、その要求に対応するサービスを実行させて、サービスモジュール２１ｂからサービスの処理結果である応答を取得し、その応答を要求処理装置４３に出力する処理を実施する。
　サービス実行装置４４ｃは例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、要求処理装置４３から出力された要求をサービスモジュール２１ｃに与えることで、その要求に対応するサービスを実行させて、サービスモジュール２１ｃからサービスの処理結果である応答を取得し、その応答を要求処理装置４３に出力する処理を実施する。
　なお、サービスモジュール２１ａ，２１ｂ，２１ｃ及びサービス実行装置４４ａ，４４ｂ，４４ｃから応答生成手段が構成されている。

　一括応答生成装置４５は例えばＣＰＵを実装している半導体集積回路、あるいは、ワンチップマイコンなどから構成されており、要求処理装置４３から個々の要求に対応する応答を受けると、その応答を応答記憶装置４６に一時的に格納し、要求パターンを構成している全ての要求に対応する応答をまとめて、一括応答を生成する処理を実施する。
　応答記憶装置４６は例えばＲＡＭやハードディスクなどの記録媒体から構成されており、応答を一時的に格納する。
　なお、一括要求解釈装置４２、要求処理装置４３、一括応答生成装置４５及び応答記憶装置４６から応答取得手段が構成されている。

　ここでは、サービス提供モジュール２２の構成要素である通信装置４１、一括要求解釈装置４２、要求処理装置４３、サービス実行装置４４ａ，４４ｂ，４４ｃ、一括応答生成装置４５及び応答記憶装置４６のそれぞれが専用のハードウェアで構成されている例を示しているが、通信装置４１、一括要求解釈装置４２、要求処理装置４３、サービス実行装置４４ａ，４４ｂ，４４ｃ及び一括応答生成装置４５のそれぞれがソフトウェアで構築されていてもよい。
　その場合には、通信装置４１、一括要求解釈装置４２、要求処理装置４３、サービス実行装置４４ａ，４４ｂ，４４ｃ及び一括応答生成装置４５の処理内容を記述しているプログラムをサービスノード２のメモリに格納し、サービスノード２のＣＰＵが当該メモリに格納されているプログラムを実行するようにすればよい。

　次に動作について説明する。
　ＧＵＩノード１からサービスノード２へのＡＰＩ実行要求は、ネットワーク３経由で転送される。
　サービスノード２はネットワーク３経由でＡＰＩ実行要求を受信すると、そのＡＰＩ実行要求で指定されたサービスに係る指定のＡＰＩを実行し、そのＡＰＩの実行結果を応答として、ネットワーク３経由でＧＵＩノード１に返信する。
　上記の通り、ＧＵＩノード１とサービスノード２が連携することで、システム全体として、サービスノード２が有する各種のサービスをユーザに提供する。

　以下、具体例をあげて、ＧＵＩノードとサービスノードが連携することで、サービスの実現が可能であることを説明する。
　ここでは、現在位置の周辺地図画像をディスプレイ１２に表示する通信システムを想定する。
　この場合、現在位置の座標情報を定期的に取得する処理（現在位置捕捉処理）と、現在位置の座標情報に基づいて、指定された縮尺で地図画像を生成する処理（地図生成処理）と、地図生成処理により生成された地図画像をディスプレイ１２に表示する処理（地図表示処理）とが必要になる。

　このとき、現在位置捕捉処理は、現在位置に関する情報を提供するサービスと捉えられる。同様に、地図生成処理も、位置情報に基づいて現在位置の周辺地図を提供するサービスと捉えられる。つまり、現在位置捕捉処理及び地図生成処理は、サービスノード２の処理となる。
　一方、地図表示処理は、現在位置捕捉処理及び地図生成処理の処理結果を加工してディスプレイ１２に表示する処理であるため、ＧＵＩノード１の処理となる。

　次に、サービスノード２がＧＵＩノード１に提供すべきＡＰＩについて説明する。
　システム全体として、現在位置の周辺地図画像をディスプレイ１２に表示すればよいため、サービスノード２がＧＵＩノード１に提供すべきＡＰＩは、現在位置周辺の地図提供ＡＰＩのみとなる。
　したがって、サービスノード２がＧＵＩノード１から現在位置周辺の地図提供ＡＰＩを受けると、現在位置捕捉処理を実施することで得られる現在位置情報をパラメータとして地図生成処理を実施し、その処理結果である地図情報を現在位置周辺の地図提供ＡＰＩの処理結果として、要求元であるＧＵＩノード１に返信できればよい。

　ＧＵＩノード１では、ＧＵＩ処理モジュール１１が、サービスノード２に対して、現在位置周辺の地図提供ＡＰＩのＡＰＩ実行要求を一定間隔で発行する一方、サービスノード２からＡＰＩ実行要求の応答として得られる地図情報をディスプレイ１２に表示可能なデータに加工することで、地図画像をディスプレイ１２に表示する処理を実施する。
　これにより、システムとして要求されているサービスをシステム利用者に提供することが可能になる。

　ＧＵＩノード１とサービスノード２間の具体的な処理シーケンスを説明する前に、ＧＵＩノード１が取り扱うＧＵＩ記述データについて説明する。
　ＧＵＩノード１で実現するＧＵＩを記述しているＧＵＩ記述データの一例として、ＨＴＭＬ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）が挙げられる。
　ＨＴＭＬは、文書の構造や表示の仕方などを記述することが可能な標準記述言語であり、その記述言語によって記述されたデータを指すものである。
　また、ＨＴＭＬは、ＨＴＭＬで記述された文書の外観の設定を記述するＣＳＳ（Ｃａｓｃａｄｅ　Ｓｔｙｌｅ　Ｓｈｅｅｔ）や、ＨＴＭＬで記述された文書内のオブジェクト等の制御を記述するＪａｖａＳｃｒｉｐｔ（登録商標。以下省略する。）を利用することが可能である。
　上述の通り、ＨＴＭＬは、本来文書の構造を記述する言語であるが、機能が拡充されており、近年では、アプリケーションやＧＵＩの開発言語としても利用されることが多くなってきている。

　一般的に、ＧＵＩは、ＧＵＩ中のオブジェクトやデータを規定するＭｏｄｅｌ、ＧＵＩの外観を規定するＶｉｅｗ、ＭｏｄｅｌやＶｉｅｗの制御を規定するＣｏｎｔｒｏｌに分けてデータ表現が可能である。
　ＨＴＭＬ、ＣＳＳ、ＪａｖａＳｃｒｉｐｔによってＧＵＩの記述を行う場合、ＧＵＩ処理モジュール１１は、ブラウザとして捉えることが可能である。
　ＨＴＭＬをＧＵＩ記述データに採用することで、画面に表示するテキストやボタン等のＧＵＩに必要なオブジェクトの配置や外観を、ＨＴＭＬによって記述することが可能である。また、各オブジェクトに対するユーザ操作やタイマー等のイベントに対応する制御や、ＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）等を用いた通信制御は、ＪａｖａＳｃｒｉｐｔによって記述することが可能である。

　ＧＵＩノード１をクライアント端末、サービスノード２をサーバ装置として捉えることで、サービスノード２に対するＨＴＴＰリクエストとして、ＡＰＩ実行要求を発行する処理をＪａｖａＳｃｒｉｐｔで記述ことが可能である。
　また、ＧＵＩ処理モジュール１１で、そのＪａｖａＳｃｒｉｐｔを実行することで、ＧＵＩノード１からサービスノード２へＡＰＩ実行要求を送信することが可能になり、ＨＴＴＰレスポンスとして、ＧＵＩノードが、そのＡＰＩ実行要求に対応する処理結果を受信することが可能になる。

　これ以降では、ＧＵＩ記述データは、ＨＴＭＬ、ＣＳＳ及びＪａｖａＳｃｒｉｐｔを利用し、ＧＵＩノード１とサービスノード２との間の通信プロトコルは、ＨＴＴＰを採用する方式で説明を行うが、本発明は、その方式に限定するものではなく、ＧＵＩノード１でＧＵＩを実現するための情報を記述することが可能であり、かつ、サービスノード２との通信を記述可能なＧＵＩ記述データであれば構わない。

　なお、ＧＵＩ記述データは、ＧＵＩノード１が保持していても構わないが、サービスノード２が保持しており、ＧＵＩノード１が必要に応じて、サービスノード２から取得する方式でも構わない。
　その場合、ＧＵＩ記述データの取得要求は、上記のＡＰＩ実行要求とは異なるものとして扱うものとする。以降、特に断りがなければ、要求と記述している場合には、ＡＰＩ実行要求のことを指すものとする。
　また、ネットワーク３に接続される別のノード（例えば、ＧＵＩ記述データを保管し、要求に応じて当該ＧＵＩ記述データを提供するＧＵＩデータサーバ）にＧＵＩ記述データを保管し、ＧＵＩノード１が必要に応じて、別のノードから取得する方式としても構わない。

　次に、ＧＵＩノード１がＡＰＩ実行要求を発行して、ＡＰＩ実行要求の処理結果を取得する際の処理内容を説明する。
　図４及び図５はＧＵＩノード１におけるＧＵＩ処理装置３２の処理シーケンスを示すシーケンス図である。
　ただし、図４は応答記憶装置３１がＡＰＩ実行要求に対応する応答を記憶していない場合の処理シーケンスを示し、図５はＡＰＩ実行要求に対応する応答を記憶している場合の処理シーケンスを示している。

　まず、ＧＵＩ処理装置３２は、ＡＰＩ実行要求を発行する（ステップＳＴ１）。
　このＡＰＩ実行要求は、実行対象となるＡＰＩに関する情報を含む要求（図４及び図５では、「要求Ａ」と表記している）と一緒に、その要求に対応する応答を応答処理装置３６が取得した際に実行すべきコールバック関数を指定することが可能であるものとする。
　これにより、ＧＵＩ処理装置３２は、ＡＰＩ実行要求に対応する応答をＧＵＩノード１が受け取ったことをトリガーとして処理を開始することが可能になる。
　なお、通信可能なサービスノード２が唯一である場合には、ＡＰＩ実行要求の送信先を示すサービスノード情報をパラメータで与えなくてもよいが、通信可能なサービスノード２が複数ある場合や、唯一である場合でも明示的にサービスノード情報をパラメータとして与えるとしてもよい。その場合、サービスノード情報をＵＲＬとして表現しても構わない。

　一括要求処理装置３３は、ＧＵＩ処理装置３２から要求を受けると、その要求がＡＰＩ実行要求であるのか、ＡＰＩ実行要求以外の要求であるのかを判定する（ステップＳＴ２）。
　ここで、図６は一括要求処理装置３３がＡＰＩ実行要求であるのか、ＡＰＩ実行要求以外の要求であるのかを判定する処理を示すフローチャートである。
　一括要求処理装置３３は、ＧＵＩ処理装置３２から要求が出力されるまで待機し、ＧＵＩ処理装置３２から要求が出力されると（ステップＳＴ５１）、その要求を取得する（ステップＳＴ５２）。

　一括要求処理装置３３は、要求を取得すると、その要求の種別を判別して、その要求がＡＰＩ実行要求であるのか、ＡＰＩ実行要求以外の要求であるのかを判定する（ステップＳＴ５３）。
　一括要求処理装置３３は、その要求がＡＰＩ実行要求以外の要求であれば、その要求の内容を変更することなく、要求先に送信する指示を通信装置３５に出力する（ステップＳＴ５４）。
　一方、その要求がＡＰＩ実行要求であれば、その要求の内容を変更し、変更後の内容である要求パターン（ＡＰＩ実行要求及び予測要求からなる要求パターン）を要求先に送信する指示を通信装置３５に出力する（ステップＳＴ５５）。
　ここでは、ＧＵＩ処理装置３２から出力された要求がＡＰＩ実行要求である例を示している。

　一括要求処理装置３３は、ＧＵＩ処理装置３２から出力された要求がＡＰＩ実行要求であると判定すると、そのＡＰＩ実行要求に対応する応答（図４及び図５では、「応答Ａ」と表記している）が応答記憶装置３１に記憶されているか否かを確認し（ステップＳＴ３）、その確認結果（応答Ａの有無）を取得する（ステップＳＴ４）。
　ここでは、ＡＰＩ実行要求に対応する応答Ａが応答記憶装置３１に記憶されていない場合を説明する。ＡＰＩ実行要求に対応する応答Ａが応答記憶装置３１に記憶されている場合は後述する。

　一括要求処理装置３３は、ＡＰＩ実行要求に対応する応答Ａが応答記憶装置３１に記憶されていない場合、ＡＰＩ実行要求をサービスノード２に送信して、サービスノード２からＡＰＩ実行要求に対応する応答Ａを取得する必要があるため、そのＡＰＩ実行要求に続いて発行される可能性がある要求（以下、「予測要求」と称する）の予測を行って、そのＡＰＩ実行要求（実要求）と予測要求からなる要求パターンの生成を要求パターン管理装置３４に指示する（ステップＳＴ５）。
　なお、要求パターンは、ＡＰＩ実行要求（実要求）と１以上の予測要求とからなる要求群である。

　要求パターン管理装置３４は、一括要求処理装置３３から要求パターンの生成指示を受けると、過去に発行されたＡＰＩ実行要求の時系列パターンの動的解析結果を参照して、過去に発行されたＡＰＩ実行要求の中で、一括要求処理装置３３から出力されたＡＰＩ実行要求（実要求）に続いて発行される可能性が最も高いＡＰＩ実行要求を予測し、その予測したＡＰＩ実行要求を予測要求に決定する。
　また、要求パターン管理装置３４は、過去に発行されたＡＰＩ実行要求の中で、その予測要求に続いて発行される可能性が最も高いＡＰＩ実行要求を予測し、その予測したＡＰＩ実行要求を予測要求に決定する。詳細は後述するが、この予測要求の決定処理を１回以上繰り返し実施する。
　要求パターン管理装置３４は、１以上の予測要求を決定すると、ＡＰＩ実行要求（実要求）と１以上の予測要求とからなる要求パターン（ＡＰＩ実行要求（実要求）＋予測要求＋予測要求＋・・・）を生成し（ステップＳＴ６）、その要求パターンを一括要求処理装置３３に出力する（ステップＳＴ７）。

　一括要求処理装置３３は、要求パターン管理装置３４から要求パターンを受けると、その要求パターンを含む一括要求を生成する。（ステップＳＴ８）。
　また、一括要求処理装置３３は、一括要求をサービスノード２に送信するためのハンドル情報、一括要求及びＡＰＩ実行要求（実要求）である要求Ａに対応するコールバック関数を応答処理装置３６に登録する（ステップＳＴ９，ＳＴ１０）。
　また、一括要求処理装置３３は、一括要求をサービスノード２に送信する指示を通信装置３５に出力し（ステップＳＴ１１）、通信装置３５から一括要求の送信指示の受領通知を受け取ると（ステップＳＴ１２）、要求発行処理が完了した旨をＧＵＩ処理装置３２に通知する（ステップＳＴ１３）。

　通信装置３５は、一括要求処理装置３３から一括要求の送信指示を受けると、その一括要求をネットワーク３経由でサービスノード２に送信する。
　また、通信装置３５は、サービスノード２から一括要求に含まれている要求パターンを構成している個々の要求（ＡＰＩ実行要求（実要求）＋予測要求＋予測要求＋・・・）に対応する一括応答（ＡＰＩ実行要求（実要求）の応答＋予測要求の応答＋予測要求の応答＋・・・）を受信すると、その一括応答と通信ハンドルを応答処理装置３６に出力する（ステップＳＴ１４）。
　サービスノード２の具体的な処理内容は後述する。

　応答処理装置３６は、通信装置３５から一括応答と通信ハンドルを受けると、その一括応答に含まれているＡＰＩ実行要求（実要求）の応答と、１以上の予測要求の応答とを応答記憶装置３１に格納する（ステップＳＴ１５，ＳＴ１６）。
　また、応答処理装置３６は、通信ハンドルをキーとして、先に登録されているコールバック関数の中から、ＡＰＩ実行要求（実要求）である要求Ａに対応するコールバック関数を取り出し、そのコールバック関数を実行することで、その要求Ａに対応する応答ＡをＧＵＩ処理装置３２に通知する（ステップＳＴ１７，ＳＴ１８）。
　ＧＵＩ処理装置３２は、その要求Ａに対応する応答Ａを受け取ると、例えば、その応答Ａをディスプレイ１２に表示する。

　次に、ＡＰＩ実行要求に対応する応答Ａが応答記憶装置３１に記憶されている場合を説明する。
　ステップＳＴ１～ＳＴ４までの処理内容は、ＡＰＩ実行要求に対応する応答Ａが記憶されていない場合と同様であるため説明を省略する。

　一括要求処理装置３３は、ＡＰＩ実行要求に対応する応答Ａが応答記憶装置３１に記憶されている場合、ＡＰＩ実行要求である要求Ａをサービスノード２に送信する必要がないため、要求発行処理が完了した旨をＧＵＩ処理装置３２に通知する（図５のステップＳＴ２１）。
　また、一括要求処理装置３３は、ＡＰＩ実行要求である要求Ａが発行された旨を要求パターン管理装置３４に通知する（ステップＳＴ２２，ＳＴ２３）。
　要求パターン管理装置３４は、ＡＰＩ実行要求である要求Ａが発行された旨の通知を受けると、過去に発行されたＡＰＩ実行要求の時系列パターンの動的解析結果を更新する。

　また、一括要求処理装置３３は、ＡＰＩ実行要求である要求Ａに対応する応答Ａをサービスノード２から送信された応答として取り扱うため、応答記憶装置３１に記憶されている要求Ａに対応する応答ＡをＧＵＩ処理装置３２に出力する旨を指示する出力指令を応答処理装置３６に出力する（ステップＳＴ２４）。
　図５では、応答処理装置３６に対する当該指示を「疑似応答通知」と表記しており、この疑似応答通知には、ＡＰＩ実行要求である要求Ａと、要求Ａに対応するコールバック関数とが含まれている。

　応答処理装置３６は、一括要求処理装置３３から疑似応答通知を受けると、その疑似応答通知に含まれている要求Ａをキーとして、応答記憶装置３１から要求Ａに対応する応答Ａを取得する（ステップＳＴ２５，ＳＴ２６）。
　また、応答処理装置３６は、その疑似応答通知に含まれているコールバック関数を実行することで、その要求Ａに対応する応答ＡをＧＵＩ処理装置３２に通知するとともに（ステップＳＴ２７，ＳＴ２８）、その応答ＡをＧＵＩ処理装置３２に通知した旨を一括要求処理装置３３に通知する（ステップＳＴ２９）。

　以上の通り、ＧＵＩノード１で処理を行うことで、既に応答を受け取っている要求をサービスノード２に発行することなく、処理を継続させることが可能になる。
　また、上記の説明では、要求を受けるスレッドと応答を受けるスレッドが異なる非同期処理で、要求・応答の一連の処理を行うことを前提にしているが、必ずしも非同期処理である必要はない。要求処理を行うスレッドが、応答を受け取れるまで待機する同期処理であっても構わない。

　次に、サービスノード２におけるサービス提供モジュール２２の処理内容を具体的に説明する。
　図７はサービスノード２におけるサービス提供モジュール２２の処理シーケンスを示すシーケンス図である。
　サービス提供モジュール２２の通信装置４１は、ＡＰＩ実行要求である要求Ａに対応する応答Ａが応答記憶装置３１に記憶されていないために、ＧＵＩノード１から一括要求が送信されると、その一括要求を受信して、その一括要求を一括要求解釈装置４２に出力する（ステップＳＴ３１）。

　一括要求解釈装置４２は、通信装置４１から一括要求を受けると、その一括要求に含まれている要求パターンを構成している個々の要求（ＡＰＩ実行要求（実要求）＋予測要求＋予測要求＋・・・）を分解し、個々の要求の要求先となるサービスのサービス識別子を抽出する（ステップＳＴ３２）。
　一括要求解釈装置４２は、個々の要求とサービス識別子の組を順番に要求処理装置４３に出力する（ステップＳＴ３３）。
　なお、要求とサービス識別子の組の出力順は、要求パターンにおける配列順であり、最初にＡＰＩ実行要求（実要求）とサービス識別子の組を出力してから、ＡＰＩ実行要求（実要求）の次に配列されている予測要求とサービス識別子の組を出力する。以下、順番に全ての予測要求とサービス識別子の組を出力する。

　要求処理装置４３は、一括要求解釈装置４２から要求とサービス識別子の組を受ける毎に、そのサービス識別子を参照して、当該要求に対応するサービスを実行するサービスモジュール２１を特定し（ステップＳＴ３４）、当該要求を当該サービスモジュール２１に対応するサービス実行装置４４に出力する（ステップＳＴ３５）。
　例えば、当該要求に対応するサービスを実行するサービスモジュールがサービスモジュール２１ａであれば、当該要求をサービス実行装置４４ａに出力し、サービスを実行するサービスモジュールがサービスモジュール２１ｂであれば、当該要求をサービス実行装置４４ｂに出力し、サービスを実行するサービスモジュールがサービスモジュール２１ｃであれば、当該要求をサービス実行装置４４ｂに出力する。

　サービス実行装置４４ａ，４４ｂ，４４ｃは、要求処理装置４３から要求を受けると、その要求をサービスモジュール２１ａ，２１ｂ，２１ｃに与えることで、その要求に対応するサービスを実行させて、サービスモジュール２１ａ，２１ｂ，２１ｃからサービスの処理結果である応答を取得し、その応答を要求処理装置４３に出力する（ステップＳＴ３６）。
　要求処理装置４３は、サービス実行装置４４ａ，４４ｂ，４４ｃから要求に対応する応答を受けると、その応答を一括要求解釈装置４２に出力する（ステップＳＴ３７）。

　一括要求解釈装置４２は、要求処理装置４３から要求に対応する応答を受けると、その応答を一括応答生成装置４５に出力する（ステップＳＴ３８）。
　一括応答生成装置４５は、要求処理装置４３から要求に対応する応答を受けると、その応答を応答記憶装置４６に登録する（ステップＳＴ３９）。
　応答記憶装置４６は、登録順序を維持したリスト形式で、要求に対応する応答を記憶領域に記憶する（ステップＳＴ４０，ＳＴ４１）。
　ステップＳＴ３３～ＳＴ４１の処理は、要求パターンを構成している個々の要求の個数分だけ繰り返し実施される。

　一括要求解釈装置４２は、ステップＳＴ３３～ＳＴ４１の処理が完了すると、一括応答の生成要求を一括応答生成装置４５に出力する（ステップＳＴ４２）。
　一括応答生成装置４５は、一括要求解釈装置４２から一括応答の生成要求を受けると、応答記憶装置４６に登録済みの個々の要求に対応する応答を取得し（ステップＳＴ４３，ＳＴ４４）、それらの応答をまとめて、一括応答を生成する（ステップＳＴ４５）。
　なお、複数の応答をまとめる処理では、登録順序を維持している応答リストを参照することで、要求パターンにおける個々の要求の配列順通りに、個々の要求に対応する応答をまとめる。
　したがって、一括応答の先頭の応答は、ＡＰＩ実行要求である要求Ａに対応する応答であり、一括応答の２番目の応答は、その要求Ａの次に配列されている予測要求に対応する応答である。

　一括応答生成装置４５は、一括応答を生成すると、その一括応答を一括要求解釈装置４２に出力する（ステップＳＴ４６）。
　一括要求解釈装置４２は、一括応答生成装置４５から一括応答を受けると、その一括応答を通信装置４１に出力する（ステップＳＴ４７）。
　通信装置４１は、一括要求解釈装置４２から一括応答を受けると、その一括応答をネットワーク３経由でＧＵＩノード１に返信する。

　以上により、ＧＵＩノード１とサービスノード２間の具体的な処理シーケンスが明らかになったが、以下、ＧＵＩノード１における構成要素の処理内容などを更に具体的に説明する。

［要求パターン管理装置３４の説明］
　図８は要求パターンのデータ構造を示す説明図である。
　まず、ＡＰＩ実行要求の時系列パターンの動的解析結果は、ＧＵＩ処理装置３２により発行されたＡＰＩ実行要求の時系列パターンと、そのＡＰＩ実行要求が発行される頻度を記録しているものである。
　図８において、要求時系列解析結果要素データ構造は、「実要求情報」と「後続パターンリスト」から構成されており、後続パターンリスト要素データ構造は、「信頼度パラメータ」と「後続パターン」から構成されている。

　「実要求情報」は、ＧＵＩ処理装置３２により発行されるＡＰＩ実行要求（以下、「実要求」と称する）に関する情報が格納される領域であり、「後続パターンリスト」は実要求情報に格納される実要求に続くパターンを要素として１つ以上持つリストで構成される。
　「後続パターンリスト」はリスト構造をなしており、実要求に続く確率が高い順に予測要求をソートして管理しても構わない。
　後続パターンリスト要素データ構造は、後続パターンリストの要素の一例を示しており、「信頼度パラメータ」は、そのパターンの信頼性を示す情報を格納し、「後続パターン」は、時系列順に後続パターンが並んでいる要求リストである。

　「信頼度パラメータ」としては、実際に発行されたことが確認された回数（発行回数）等が想定される。
　その他、実際に発行された最新の日時情報、予測要求として、その予測が成功した回数や失敗した回数など、予測要求を決定するに当たり、パラメータとして利用可能な情報を併せて格納しても構わない。
　「後続パターン」は、後続する要求情報を時系列順序で列挙している。
　「後続パターン」の要素に記述すべき要求の内容は、「実要求情報」と同等のデータ構造で構わない。それ以外にも、実行時に与える引数の値リストや、予測要求リストの各要素が、どの程度の信頼度であるかを示す情報を併せて格納しても構わない。その具体例は、要求毎の予測の成功・失敗の回数などが考えられる。

　次に、その他の表現形式での要求時系列解析結果の具体例を説明する。
　図９は実要求情報リストのデータ構造を示す説明図であり、図９に示すデータ構造は、図８の要求パターンのデータ構造に対応するデータ構造である。
　「実要求情報」は、実際に発行されることになった要求を示す情報を格納する領域であり、要求パターンの先頭要求になることを意味する。
　「後続パターン管理データ参照」は、実要求情報の後に実際に発行された要求に関する解析結果を管理するデータを参照する領域である。この参照では、後続用要求パターンリストデータが参照される。この参照を辿ることで、実要求の次に過去発行された要求の情報を参照することができる。
　「次実要求参照」は、その他の実要求情報リストデータがある場合に参照可能とする領域である。この領域がＮＵＬＬである場合には、それ以上の実要求情報リストデータは存在しないことを意味する。

　図１０は後続要求パターンリストのデータ構造を示す説明図であり、図１０に示すデータ構造は、図８の後続パターンリスト要素データ構造に対応するデータ構造である。
　「後続要求情報」は、次に発行されると予測される要求情報を格納する領域である。
　「信頼度情報」は、その予測要求が、どの程度信頼できるかを示す尺度となる情報を格納する領域である。
　「次後続要求リスト参照」は、その後続要求の後に続いて実際に発行された要求に関する解析結果を管理するデータを参照する領域である。この参照では、後続用要求パターンリストデータが参照される。この領域がＮＵＬＬである場合には、それ以上、次に発行された要求が存在しないことを意味する。
　「同列要求参照」は、その後続要求とは異なる要求で、同一の時系列順序で発行された要求に関する後続要求パターンリストデータを参照する領域である。この領域がＮＵＬＬである場合には、それ以上、同列で発行された要求が存在していないことを意味する。

　図１１は実要求情報リストデータ構造及び後続要求パターンリストデータ構造を用いた具体的な要求パターンの一例を示す説明図である。
　「実要求情報リスト」が実要求情報リストデータを要素としてリストデータを構成し、要求パターンの先頭となる要求を列挙したリストデータである。
　図１１の例では、要求Ａと要求Ｂが過去に実際に発行された要求の中で、先頭に発行されたことがある要求であることを示している。
　「実要求情報リスト」の各要素の後続要求パターン管理データ参照から参照しているものが、後続要求パターンリストデータを要素として樹状データを構成し、その実要求の後に続いた要求を管理する樹状データである。
　実要求情報リストの要素から直接参照されている後続要求パターンリストの要素と、その要素の同列後続要求参照を再帰的に辿ることで到達可能な要素が、実要求の直後に発行された要求に関する情報を「後続要求情報」に持っている。

　例えば、図１１では、実要求Ａから直接参照されている要素の要求Ｃと、要求Ｃの要素の同列後続要求参照を再帰的に辿ることで到達可能な要求である要求Ｂの二種類が、要求Ａの後に続く要求であることを意味する。
　同様に、後続要求パターンリストのある要素の次の後続要求リスト参照で参照される要素の要求と、その要素の同列後続要求参照を再帰的に辿ることで参照可能な要素の要求全ては、その要求パターン内である要求の後に続いたことがある要求に関する情報を「後続要求情報」に持っている。
　例えば、図１１では、実要求Ａの直後に発行される要求Ｃを基準の要求として考えた場合、その要求Ｃの後に続いたことがある要求は、要求Ｄと要求Ｅであることを意味している。

　以上のことを繰り返すことによって、要求Ａが実際に発行された場合、続く要求パターンは、下記の５通りであることを意味する。
　　　Ａ
　　　Ａ→Ｃ
　　　Ａ→Ｃ→Ｄ
　　　Ａ→Ｃ→Ｅ
　　　Ａ→Ｂ

　図８に示しているデータ構造では、１つの要求パターンに対して、１つの信頼度情報を設定しているが、図９及び図１０に示しているデータ構造では、各後続要求単位で信頼度情報を設定している点が異なる。
　つまり、図８に示しているデータ構造では、要求パターンの発行に関する信頼度を信頼度情報に設定しているのに対して、図９及び図１０に示しているデータ構造では、ある要求に対して、次に発行されると予測される要求毎の信頼度を信頼度情報として設定している点が異なる。

　以下、図９及び図１０に示しているデータ構造で要求パターンを管理する場合において、要求パターン管理装置３４がその要求パターンを動的に更新する具体例を説明する。
　要求パターン管理装置３４が、ＧＵＩノード１で実際に発行される要求を知るタイミングは、一括要求処理装置３３から出力される要求パターンの生成指示時（図４のステップＳＴ５）、もしくは、実要求通知（図５のステップＳＴ２２）でパラメータとして実要求を受ける時である。
　その際、要求パターンの全体のうち、通知された要求が、どの位置から検索すべきかを示す処理対象要求参照が要求パターン管理装置３４に入力されるものとして、以下の説明を行う。

　図１２は処理対象リストの参照例を示す説明図である。
　図１２は図１１の要求パターンと同等であり、処理対象リスト参照の具体例として、ａ，ｂ，ｃ，ｄの４種類を示している。加えて、要求パターンの生成指示時（図４のステップＳＴ５）の要求時系列解析結果の更新フローを図１３に示し、実要求通知時（図５のステップＳＴ２２）の要求時系列解析結果の更新フローを図１４に示している。

　まず、要求パターンの生成指示時における要求時系列解析結果の更新処理を説明する。
　要求パターン管理装置３４は、要求パターンの生成指示を受けると（図１３のステップＳＴ１０１）と、例えば、図１２に示す実要求情報リストから要求パターン生成要求のパラメータである実要求をキーとして、実要求情報リストから実要求に対応する要素を検索する（ステップＳＴ１０２）。
　要求パターン管理装置３４は、実要求に対応する要素が見つかると（ステップＳＴ１０３）、実要求に対応する要素の後続要求パターン管理データ参照の値を処理対象リスト参照に代入することで、次に実要求通知があった場合に、どのリストから要求パターンを更新すればよいのかが判別可能になり、更新処理を完了する（ステップＳＴ１０４）。

　要求パターン管理装置３４は、実要求に対応する要素が見つからない場合（ステップＳＴ１０３）、実要求を実要求情報に保持し、後続要求パターン管理データ参照にＮＵＬＬ要素を設定した要素を生成し、リストに追加する更新を行う（ステップＳＴ１０５）。
　その後、ステップＳＴ１０５で生成したＮＵＬＬ要素のリストを処理対象リスト参照に代入して、更新処理を完了する（ステップＳＴ１０６）。

　例えば、処理対象リスト参照が図１２の処理対象リスト参照ａの位置にある場合において、実要求Ｂをパラメータとして受けた場合、実要求情報リストには要求Ｂの要素があるため、ステップＳＴ１０４の処理によって、処理対象リスト参照が処理対象リスト参照ｂの位置に更新される。
　もしくは、実要求Ｃをパラメータに受けた場合、実要求情報リストには、要求Ｃの要素がないため、ステップＳＴ１０５，ＳＴ１０６の処理によって、図１５に示すように、要求Ｃに関する要素が実要求情報リストに追加され、その後続要求パターン管理データ参照はＮＵＬＬ要素のみを持つ予測要求パターンリストｅを持つように設定される。また、処理対象リスト参照は処理対象リスト参照ｅの通り、予測要求パターンリスト（１）を参照する。

　次に、実要求通知時における要求時系列解析結果の更新処理を説明する。
　要求パターン管理装置３４は、実要求通知を受けると（図１４のステップＳＴ１１１）、処理対象リスト参照が参照リストから実要求に対応する要素を検索する（ステップＳＴ１１２）。
　要求パターン管理装置３４は、実要求に対応する要素が見つかると（ステップＳＴ１１３）、実要求に対応する要素の信頼度情報を更新する（ステップＳＴ１１４）。
　例えば、信頼度情報を実要求が実際に発行された回数とした場合には、その値をインクリメントする。
　その後、要求パターン管理装置３４は、実要求に対応する要素の後続要求リスト参照の値を処理対象リスト参照に代入して、更新処理を終了する（ステップＳＴ１１５）。
　要求パターン管理装置３４は、実要求に対応する要素が見つからない場合（ステップＳＴ１１３）、処理対象リスト参照が参照するリストに対して要素を追加し、その後続要求情報にはパラメータの実要求として、更新処理を終了する（ステップＳＴ１１６）。

　例えば、処理対象リスト参照が図１２の処理対象リスト参照ｃの場合において、実要求通知でパラメータとして実要求Ｃを受けたとすると、ステップＳＴ１１４の処理によって、要求Ｃの信頼度情報を更新し、ステップＳＴ１１５の処理によって、処理対象リスト参照は処理対象リスト参照ｄに更新される。
　同様に、パラメータとして実要求Ｄを受けた場合には、図１６に示すように、要求パターンが更新される。
　具体的には、ステップＳＴ１１６の処理によって、要求Ｄに関する要素を新規生成し、処理対象リスト参照ｃが参照するリストの要求Ｂに関する要素の同列後続要求参照に要求Ｄに関する要素を参照させる。また、要求Ｄに関する要素の信頼度情報を初期化し、次の後続要求リスト参照ではＮＵＬＬ要素を持つリストを参照させる。そのうち、ステップＳＴ１１６の処理によって、処理対象リスト参照は処理対象リスト参照ｆのように更新される。

　次に、要求パターン管理装置３４の具体的な処理を説明する。
　要求パターン管理装置３４は、要求パターンの生成指示時（図４のステップＳＴ５）、あるいは、実要求通知時（図５のステップＳＴ２２）に処理を行う。

［要求パターンの生成指示時の処理内容］
　要求パターンの生成指示時（図４のステップＳＴ５）は、実要求に対応する応答が応答記憶装置３１に格納されていない状況で、一括要求処理装置３３から要求パターン管理装置３４に要求される。
　要求パターン管理装置３４は、一括要求処理装置３３からパラメータとして受け取る実要求をキーとして、最も発行されると判定される要求パターン（予測要求パターン）を要求時系列解析結果から導出し、その導出結果を返す処理を行う。

　具体的には、要求時系列解析結果の全要求時系列解析結果要素データの実要求情報と、パラメータである実要求とを比較して、一致する要求時系列解析結果要素データを導出する。
　一致判定では、要求内容の完全一致としても構わないが、部分一致による判定などでも構わない。具体的には、要求する処理は一致しているが、パラメータとして与える内容が一部異なる場合などが部分一致として考えられる。

　次に、その要求時系列解析結果要素データの後続パターンリストから信頼度パラメータを用いて、発行する確率が最も高い後続パターンを見つけ出し、実要求を先頭要素として、その後に見つけ出した後続パターンの要求を時系列順に連結したパターンを予測要求パターンとする。
　確率は、信頼度パラメータに格納される情報（例えば、発行回数）の大小で決定しても構わない。それ以外にも、複数の信頼度パラメータに格納される情報を、確率を算出する関数に適用することで、確率を算出するようにしても構わない。
　例えば、発行回数に対して、現在日時と実際に発行された最新の日時情報との差分時間の逆数をかける等の関数を用いて、確率を算出するようにしてもよい。また、システムとして定められた判定基準の元で確率を算出するようにしてもよい。その結果、最も確率の高い要求パターンを予測要求パターンとする。

　また、別の方法の要求パターンの決定方法として、２種類以上の要求パターンを候補として選定し、複数の予測要求パターンを組み合わせて、新たな１つの予測要求パターンとしても構わない。
　図１７は予測要求パターンの組み合わせ例を示す説明図である。
　図１７の例では、予測要求パターン１が最も発行される確率が最も高いと判定された予測要求パターン、予測要求パターン２が次に発行される確率が高いと判定された予測要求パターンである。
　この場合、例えば、２種類の予測要求パターン１，２の論理和を求め、その論理和で構成された予測要求パターン３を処理結果として返すことが考えられる。

　この方法を採用することによって、複数の予測要求パターンを１つの予測要求パターンとして表現することが可能になるため、発行する確率を向上させることが可能になる。
　この例では、発行確率が上位２個の予測要求パターンを論理和とすることで、新たな予測要求パターンを生成しているが、これに限定するものではなく、複数の予測要求パターンをある定められた合成関数に適用することで、新たな予測要求パターンを作成するようにしてもよい。

　また、別の予測要求パターンの決定方法として、処理過程で導出された予測要求パターンの一部を予測要求パターンとしても構わない。
　例えば、予測要求パターンの各要求が、先頭から自身までの要求パターンをシステムで処理した結果、その自身で予測に失敗した回数を保持していると仮定すると、その値がある閾値以上となる場合には、それ以降の要求を要求パターンから排除して、そこまでの要求パターンを予測要求パターンとする方法が考えられる。
　時系列順を考慮せず、あくまで、その要求パターンを処理結果とした際に、各要求で予測が成功した回数や失敗した回数を保持していると仮定し、要求パターンからある閾値以上の要求の全てで新たな要求パターンを構成し、新たな要求パターンを予測要求パターンとする方法も考えられる。

　上記の通り、システムで定められた基準以上の予測要求パターンを要求時系列解析結果に基づいて１つ以上選定し、それらを組み合わせることで実要求の後に発行されると予測される予測要求パターンを１つ決定するのが要求パターンの生成指示時（図４のステップＳＴ５）に対応する処理である。
　また、その処理の後、予測要求パターンや、その予測要求パターンを決定する際に利用した要求パターンリストに含まれる要求パターンは、その予測結果が確定するまで要求パターン管理装置３４が維持する。以下、それらの要求パターンのことを予測対象要求パターンと称する。

［実要求通知時の処理内容］
　実要求通知時（図５のステップＳＴ２２）は、実要求に対応する応答が応答記憶装置３１に格納されている状況で、一括要求処理装置３３から要求パターン管理装置３４に要求される。
　要求パターン管理装置３４は、一括要求処理装置３３からパラメータとして実要求通知を受け取ると、その通知を受ける前に生成している要求パターンを構成している予測要求の予測が成功していると認識する（予測通りに発行された認識する）。
　そこで、要求パターン管理装置３４は、その予測要求と一致している要求Ａと共に格納されている情報を更新する。

　例えば、格納されている情報が成功回数あれば、その成功回数のインクリメントを行い、格納されている情報が一時的な予測成否フラグであれば、フラグを立てるなどの更新が考えられる。
　また、後続パターンリスト中の各パターンの信頼度パラメータを再計算し、その値を更新するようにしてもよい。信頼度パラメータを更新することによって、そのシステムの利用状況に応じた予測パターンリストの構築が可能となり、予測確度を向上させることが可能になる。
　また、パラメータに対応する要求が上記要求パターンの中にない場合には、その要求を上記要求パターンに連結して、新たな予測パターンデータを構築し、予測パターンリストの要素として新規登録するようにしてもよい。新規登録することで新たな要求パターンを予測することが可能になり、予測確度を向上させることが可能となる。新規登録せずに、現在の要求パターンの新たなリスト要素として、その要求を追加する方法でも構わない。

　次に、一括要求処理装置３３の具体的な処理を説明する。
［一括要求の生成処理］
　ＧＵＩノード１からサービスノード２への要求をＨＴＴＰで行う方法として、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）によって要求先ノードと要求リソースを記述する方法が考えられる。ＵＲＩによる記述方式は複数考えられるが、例えば、図１８に示すような記述方法が挙げられる。

　図１８の例では、サービスノード２のドメイン名である［サービスノードドメイン］をＵＲＬのホスト名として記述し、第１のディレクトリ名で要求するサービスの名前である［サービス名］、第２のディレクトリ名でＡＰＩ（サービス内の要求するＡＰＩ）の名前である［ＡＰＩ名］を記述している。
　このようにＵＲＬを用いることで、ＧＵＩノード１は、通信相手をＵＲＬのホスト名から一意に識別することが可能であり、サービスノード２は、ＵＲＬの［サービス名］と［ＡＰＩ名］によって、どのサービスのどのＡＰＩを要求されているのかを一意に識別することが可能になる。

　ただし、図１８の記述方式では、１つのＵＲＬで発行可能なＡＰＩ実行要求は、単一のサービスが持つ単一のＡＰＩ名に限定されるため、本発明のように、複数のＡＰＩ実行要求を一括して発行する方式のものには適さない。
　そこで、図１９に示すように、ＵＲＬから［サービス名］と［ＡＰＩ名］を除外し、一括要求であることを示す［一括要求識別名］をＵＲＬの中に記述する方法が考えられる。
　その場合、サービス名とＡＰＩ名に相当する情報をＨＴＴＰ通信時のボディ部に記述することで、それらの情報を要求先ノードに通知することが可能である。

　ここで、サービスノード２が有するＡＰＩは、一般的に関数として扱うことが可能であり、その多くは、引数を受け取ることが可能である。
　つまり、ＨＴＴＰ通信時にボディ部に記述すべき情報として、ＡＰＩに対する引数の値も含まれることになる。なお、通常は複数の引数をＡＰＩに設定することが可能であるため、複数の引数をまとめて引数リストと称する。

　図２０は単一のサービスに対する複数のＡＰＩと、各ＡＰＩに対する複数の引数リストを１つのテキスト形式データで表現している具体例を示す説明図である。
　このデータはＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ　Ｏｂｊｅｃｔ　Ｎｏｔａｔｉｏｎ）形式で、多重配列オブジェクトとして前述の情報を記述している。
　最上位の配列（サービス要求配列オブジェクト）は、１番目の要素で要求対象となるサービスのサービス名を記述している。２番目以降の要素で、そのサービスに対して要求する具体的なＡＰＩと、その引数を配列オブジェクト（ＡＰＩ配列オブジェクト）として表現している。

　ＡＰＩ配列オブジェクトは複数指定することが可能であり、複数指定されている場合には、そのサービスに対して複数のＡＰＩを実行する旨を要求していることを意味する。
　ＡＰＩ配列オブジェクトは、１番目の要素で、要求するＡＰＩの名前を表現し、２番目以降の要素で、そのＡＰＩを実行する際の引数リストを表現した配列オブジェクト（引数配列オブジェクト）を列挙している。
　引数配列オブジェクトを生成するためには、要求パターンの生成指示時（図４のステップＳＴ５）に取得した要求パターンの各要求に付随する引数リストを利用して作成することが可能である。
　また、ＡＰＩ配列オブジェクトも同様に、要求パターンに含まれている同一サービスに対するＡＰＩを抽出することで作成することが可能である。

　引数配列オブジェクトが複数ある場合には、引数配列オブジェクトの個数だけＡＰＩを実行することを意味し、各実行では、それぞれの引数配列オブジェクトの内容を引数として与えて実行することを意味する。
　図２１に示すように、サービス要求配列オブジェクトを１つ以上持つ配列（一括要求配列オブジェクト）を構成することによって、複数のサービスに対する要求を一括して表現可能なデータ構造を構築することが可能になる。

　ここで、一括要求を発行する際、実要求と予測要求を区別する必要がある。
　区別する方法として、実要求については、一括要求の第１要素であるサービス要求配列オブジェクトの第２要素（先頭ＡＰＩ配列オブジェクト）で表現するという規定を設ける方法が考えられる。
　それ以外にも、ＡＰＩ配列オブジェクトの第１要素に実要求の場合には「ｔｒｕｅ」、それ以外の場合には「ｆａｌｓｅ」を持つ配列要素を追加することで表現するようにしてもよい。
　また、要求の順序を保存すべき場合には、実要求を先頭とし、その後に予測要求パターンに登録されている予測要求の順番通りに要素を構成することでも、順序を保存することが可能である。その場合、各サービスに対するサービス要求配列オブジェクトは必ずしも１つとなるとは限らない。

　以上の一括要求配列オブジェクトをボディ部に持ち、図１９に示すＵＲＬを指定し、ＰＯＳＴ命令を行うＨＴＴＰ要求を一括要求の具体例の一つと考えることが可能である。
　一括要求は、一括要求処理装置３３が、図４のステップＳＴ１１の処理によって、通信装置３５に発行することで開始され、その処理結果は要求可否のフラグとして、ステップＳＴ１２で一括要求処理装置３３に返される。
　また、その要求可否フラグは、ステップＳＴ１３でＧＵＩ処理装置３２に返される。

［ハンドル情報、一括要求及びコールバック関数の登録処理］
　一括要求処理装置３３は、一括要求を生成すると、その一括要求と関連する情報を応答処理装置３６に登録する。
　関連する情報としては、通信装置３５から受け取る一括要求に対応するハンドル情報、一括要求に対応する処理を受けた際に実要求を処理するためのコールバック関数等が考えられる。
　一括要求と関連する情報を受け取った応答処理装置３６は、その情報を自身で管理する記憶領域に保存し、その処理結果を一括要求処理装置３３に返信する。

［一括応答と通信ハンドルの通知処理］
　通信装置３５は、一括要求をネットワーク経由３でサービスノード２に送信したのち、サービスノード２から送信される一括要求に対応する一括応答を受信する。
　通信装置３５は、一括要求に対応する一括応答を受信すると、その一括応答を応答処理装置３６に通知するとともに、その応答に対応する要求を発行した通信処理を示すハンドル情報を応答処理装置３６に通知する。

　ここで、サービスノード２から返信される一括応答の具体例について説明する。
　図２２は応答の具体的なデータ表現例を示す説明図である。
　図２２の例では、要求の場合と同様に、データをＪＳＯＮ形式で表現している。
　一般的な関数では、関数の戻り値と、参照引数による応答の２種類が存在する。戻り値に関しては、通常、１つのオブジェクトのみとなるが、参照引数については、複数の設定が可能である。
　そこで、応答は、第１要素に関数の戻り値、第２要素以降に参照引数を格納するＪＳＯＮの配列オブジェクトとして表現することが可能である。
　また、戻り値はｖｏｉｄの場合があるが、その場合には、第１要素にｎｕｌｌ値もしくは空文字等を設定することで対処可能である。

　一括応答は、上記で説明した応答を要素として持つ配列オブジェクトとして表現することが可能である。図２３は一括応答の具体的なデータ表現例を示す説明図である。
　図２３の例では、一括要求に格納されている要求の順番を維持して、それぞれの応答を格納している。つまり、最初の要求が実要求である規定がなされていれば、この一括応答の先頭要素は、実要求に対応する実応答であることになる。

　応答処理装置３６は、通信装置３５から一括応答と通信ハンドルを受けると、先に登録されている情報の中から、その通信ハンドルに対応する情報を検索し、対応する一括要求とコールバック関数を取得する。
　応答処理装置３６は、一括応答にまとまられている個々の要求に対応する応答を要求とペアにして応答記憶装置３１に保存する。この処理によって、全ての応答は、要求内容をキーとして検索可能な形で応答記憶装置３１に格納される。応答記憶装置３１は格納した結果をステップＳＴ１６で応答処理装置３６に返信する。
　また、応答処理装置３６は、ＡＰＩ実行要求（実要求）である要求Ａに対応するコールバック関数を実行することで、その要求Ａに対応する応答ＡをＧＵＩ処理装置３２に通知する。コールバック関数には、少なくとも実要求に対応する実応答をパラメータとして渡して処理を行う。コールバック関数の処理結果は、ステップＳＴ１８で応答処理装置３６に返される。

　以下、具体的なサービスへの適用を例示する。
　例えば、カーナビゲーションシステムにおける現在位置周辺の地図画像を描画するサービスを例として、図２４の地図画像を用いて、更なる具体例を説明する。

　通常、現在位置周辺の地図画像を描画するサービスの場合、ＧＵＩの画面には現在位置周辺の地図画像を全面に描画し、その地図画像上に、現在位置を示す自車位置アイコンを描画して、地図上の現在位置を視覚的に表現する。
　それ以外に現在位置の住所等を描画する地名表示、地図描画内容に対する方位、地図の縮尺を示す地図縮尺、現在時刻を地図画像上に描画する。

　これら地図画像、現在位置、住所、方位、縮尺、現在時刻など情報は、ＧＵＩノード１では生成せずに、サービスノード２に問い合わせる（要求する）ことで、ＧＵＩノード１が入手して描画に利用する。
　ただし、本発明を適用しないシステムの場合、図２５に示すように、ＧＵＩノード１が、ステップＳＴ２０１，ＳＴ２０３，ＳＴ２０５，ＳＴ２０７の処理で、データ要求（地図要求、地図情報要求、現在位置要求、住所要求）をサービスノード２に行って、ステップＳＴ２０２，ＳＴ２０４，ＳＴ２０６，ＳＴ２０８の処理で、サービスノード２からデータ要求に対応する応答（地図画像、縮尺・方位、現在位置、現在住所）を受け取る。
　上記の処理を行うには、計４回の通信がＧＵＩノード１とサービスノード２間で発生することになる。この処理が地図描画タイミングの度に発生することになる。現在時刻については、ＧＵＩノード１の持つ時刻情報を使うことを想定する。

　一方、本発明を適用するシステムでは、ＧＵＩノード１が、ステップＳＴ２０１の処理に相当する地図要求をサービスノード２に発行する前に、一括要求生成装置３３と要求パターン管理装置３４によって、地図要求の次に発行される可能性の高い予測要求パターンを取得し、一括要求としてまとめて要求を行う。
　仮に、予測要求パターンの一部もしくは全てが間違っていたとしても、実際の要求となる実要求の発行を繰り返すことによって、要求パターン管理装置３４では、地図要求の後に続く要求パターンの更新が行われ、地図要求の後に続く要求は地図情報要求、現在位置要求、住所要求であることが反映され、長期的には、正しい予測が可能な要求パターンを生成することが可能になる。

　具体的には、要求パターンの生成指示時（図４のステップＳＴ５）や実要求通知時（図５のステップＳＴ２２）に、一括要求処理装置３３から要求パターン管理装置３４に通知される実要求に関する情報を利用し、それまでに発行された実要求の時系列パターンや予測対象要求パターンをもとに、各要求パターンの発行回数に関する情報を更新することが可能である。つまり、地図更新が発生する度に、地図要求、地図情報要求、現在位置要求、住所要求の順で要求が発生するため、その要求パターンの発行回数が増加する。
　その結果、発行回数が最大の要求パターンを予測要求パターンとして採用することで、正しい予測が可能になり、長期的には、４回必要であった通信回数を１回に削減することが可能になる。

　一方で、ユーザが途中で地図縮尺の強制変更を行った場合、図２６に示すように、ステップＳＴ２１１の処理で、ＧＵＩノード１からサービスノード２に新たな縮尺情報をパラメータとして縮尺変更要求を発行し、その後、地図要求、地図情報要求、現在位置要求、住所要求を発行すると仮定する。
　上記の場合、初めて縮尺変更する際には、縮尺変更要求を実要求とした場合の要求パターンが要求パターン管理装置３４には保存されていないため、縮尺変更要求のみをサービスノードに要求し、次の地図要求から一括要求処理が開始される。その処理によって、縮尺変更要求の後には、地図要求、地図情報要求、現在位置要求、住所要求が連続して発行することを要求パターン管理装置３４が学習し、その要求パターンを新規に作成する。
　これにより、２回目以降の縮尺変更要求が発行された場合には、新たに作成された要求パターンに従って地図要求、地図情報要求、現在位置要求、住所要求が予測要求となる一括要求を一括要求処理装置３３が作成して、その一括要求をサービスノード２に送信することになる。

　以上で明らかなように、この実施の形態１によれば、ＧＵＩ処理装置３２により発行された実行要求に対応する応答が応答記憶装置３１に記憶されていれば、その応答をＧＵＩ処理装置３２に出力する旨を指示する出力指令を応答処理装置３６に出力する一方、その実行要求に対応する応答が応答記憶装置３１に記憶されていなければ、その実行要求に続いて発行される可能性がある要求の予測を行って、その実行要求と予測要求からなる要求パターンの生成を要求パターン管理装置３４に指示し、要求パターン管理装置３４により生成された要求パターンを含む一括要求を生成する一括要求処理装置３３と、その実行要求に続いて発行される可能性がある要求を予測し、その実行要求と予測要求からなる要求パターンを生成する要求パターン管理装置３４と、一括要求処理装置３３により生成された一括要求をサービスノード２に送信する一方、サービスノード２から送信された一括要求に対応する一括応答を受信する通信装置３５とを設け、応答処理装置３６が、一括要求処理装置３３から出力指令を受けると、応答記憶装置３１に記憶されている実行要求に対応する応答をＧＵＩ処理装置３２に出力し、通信装置３５により一括応答が受信されると、その一括応答に含まれている実行要求及び予測要求に対応する応答を応答記憶装置３１に格納するとともに、その実行要求に対応する応答をＧＵＩ処理装置３２に出力するように構成したので、実行要求に対応する応答が応答記憶装置３１に記憶されていれば、その実行要求を送信する必要がなくなり、その結果、連携処理に係るネットワーク通信の回数を十分に削減することができる効果を奏する。

　即ち、一連のＧＵＩノード１とサービスノード２の処理によって、ＧＵＩノード１から実際に発行される単一の実要求から、それに続いて発行されると予測される要求を１つ以上決定することが可能になる。そのため、実要求と１つ以上の予測要求をまとめた一括要求を生成して、一括要求をサービスノード２に通知することが可能になる。
　また、サービスノード２は、一括要求を受けて、その内容となる要求を各サービスで処理することが可能になるとともに、その１つ以上の応答をまとめた一括応答を生成し、一括応答をＧＵＩノード１に返信することが可能になる。
　また、その一括応答を受信したＧＵＩノード１は、一括応答の内容を記憶し、その記憶した結果に対応する要求を発行する前に、その記憶した結果をＧＵＩノード１内で使いまわすことによって、サービスノード２への通信回数を削減することができ、通信に伴う処理速度の低下を回避することが可能なシステムとなる。
　また、予測結果の成否情報を管理することが可能なシステムであり、システムの使用状況等に応じて、予測パラメータを調整することで、予測要求の生成パターンを更新することが可能である。

実施の形態２．
　上記実施の形態１では、要求パターン管理装置３４が、ＡＰＩ実行要求に続いて発行される可能性がある要求を予測し、そのＡＰＩ実行要求と予測要求からなる要求パターンを生成するものを示したが、要求パターン管理装置３４が、ＧＵＩに表示される画面単位に、ＧＵＩ処理装置３２により発行された実行要求の履歴を管理して、実行要求の発行頻度を更新する処理を実施し、ＧＵＩ処理装置３２により新たに発行された実行要求が同じ実行要求であっても、ＧＵＩに表示されている画面が異なれば、異なる要求パターンを生成する場合があるようにしてもよい。
　具体的には、以下の通りである。

　サービス全体を想定した場合、ＧＵＩノード１で表示する画面毎に、同じ要求であっても、その後に続く要求のパターンは、異なることが想定される。
　例えば、図２４に示すような現在位置周辺の地図画面を表示する場合の地図要求と同一の要求であっても、画面に表示する内容が異なれば、その後に続く要求も異なる可能性が高い。

　図２７はＧＵＩノード１が表示する別の画面例であるが、地図を画面上に描画するとともに、方位や自車位置アイコンを描画するまでは図２４の場合と同様であるが、ある地点が、地図上のどこに存在するかをアイコンで描画する地点アイコンと、その地点アイコンに関する基本情報（地点名と、現在位置からの距離）を示すボタンをリスト形式で表している地点リストボタンも描画している。
　この場合、地図要求の後に続く要求が、地図情報要求、現在位置要求であるところまでは図２４の場合と同様であるが、図２８に示すように、その後に周辺検索要求が続いている点で異なっている。

　そのため、要求パターン管理装置３４は、図２４の画面と図２７の画面で同じ要求時系列解析結果でパターン管理を行った場合、例えば、図２７の画面でしばらく動作した後に図２４の画面に遷移して動作させた場合、予測要求パターンの最後の予測要求が住所要求ではなく、周辺検索となり、適切な要求パターンを予測要求パターンとすることができなくなる問題がある。
　そこで、要求パターン管理装置３４は、画面単位で独立した要求時系列解析結果の生成を行うことで、上記の問題に対処している。

　図２９は画面単位で独立した要求パターン管理を行う場合の要求時系列解析結果のデータ構造例を示す説明図である。
　図２９の要求時系列解析結果は、図８の要求時系列解析結果要素データ構造を要素に持つデータ構造であり、実要求をキーとして、その実要求の後に続く後続パターンリストを持つリスト構造になっている。
　また、図２９の後続パターンリストは、図８の後続パターンリスト要素データ構造を要素に持つデータ構造であり、後続パターン別に信頼度パラメータを持つリスト構造になっている。

　要求パターン管理装置３４は、実要求をキーとして、その要求時系列解析結果から対応する後続パターンリストを取得し、その後続パターンリストに基づいて予測要求パターンを決定する。
　これまでの説明では、画面が変化したとしても単一の要求時系列解析結果を管理していたが、画面別リストを導入することにより、画面毎に異なる要求時系列解析結果を定義して、画面毎に異なる要求時系列解析結果を管理することができるデータ構造である。
　画面毎に要求時系列解析結果を定義することで、図２４及び図２７の例で説明したような、画面毎に同一の要求時系列解析結果に基づいた予測によって適切な予測要求パターンを生成できない問題を解消することが可能になる。

　要求パターン管理装置３４は、現在処理中の画面情報を一括要求処理装置３３から画面が変更される度に受け取ることで、画面別リストのうち、どの画面を表示しているのかを知ることが可能になり、適切な実要求リストを基準とする要求パターン管理及び予測要求の決定が可能になる。
　また、一括要求処理装置３３は、ＧＵＩ処理装置３２からサービスノード２に発行されるＧＵＩ記述データ取得要求をトリガーとして、次の画面情報を要求パターン管理装置３４に通知することができる。もしくは、応答処理装置３６がサービスノード２からのＧＵＩ記述データ取得要求に対応する応答を受信したタイミングをトリガーとして、同様の処理を行っても構わない。

　また、ＧＵＩノード１が画面情報を保持している場合には、ＧＵＩ処理装置３２は、画面遷移が発生するタイミングで、要求パターン管理装置３４に対して、次の画面情報を通知することで対応可能になる。
　例えば、要求パターン管理装置３４が図２９の要求時系列解析結果を持ち、画面別リストの画面Ａを図２４に示す画面、画面Ｂを図２７に示す画面を意味するとすれば、図２４の画面を表示している場合には、要求パターン管理装置３４は、画面別リストの画面Ａの要素が参照する実要求リストを参照しながら処理を行う。
　そのとき、ＧＵＩ記述データ取得要求をトリガーとして、一括要求処理装置３３が、遷移先となる画面情報である画面Ｂを要求パターン管理装置３４に通知する。
　要求パターン管理装置３４は、その通知を受けると、処理対象となる実要求リストを画面別リストの画面Ｂの要素が参照する実要求リストに切り替え、それ以降の処理では、切り替えた実要求リストを参照しながら処理を行う。

実施の形態３．
　この実施の形態３では、要求パターン管理装置３４における要求時系列解析結果の生成方式について説明する。
　要求時系列解析結果は、ある実要求が発行された直後に続いて発行された要求のパターンに関する情報を収集して解析した結果であり、１つ以上で有限数の要求に関する情報で構成されたパターンの集合体である。
　そのパターンは、ＧＵＩ処理装置３２から一括要求処理装置３３に通知されるＡＰＩ実行要求を基に、その要求に関する情報や、その要求が発行される時系列順序に関する情報等を動的に収集して解析した結果となる要求時系列解析結果が生成される。
　また、要求パターン管理装置３４が一括要求処理装置３３からの要求パターンの生成指示を処理する場合、要求時系列解析結果の内容に基づいて予測要求パターンを構成する。

　要求時系列解析結果の具体的な形態としては、例えば、図２９に示すような収集された全ての要求パターンに対して、その要求パターンの先頭の要求が実際に発行されたときに、その後に対応する後続パターンと同じパターンの要求発行が行われるかの尺度となる信頼度パラメータを持たせて管理する方法がある。その場合には、それぞれの実要求と後続要求パターンを併せた要求パターンに含まれる要求数は有限でなければならない。
　以下、要求時系列解析結果に含まれる要求パターンを有限の要求数とするための具体的な方法を説明する。

（１）有限数の要求パターンを構成する方法の１つとして、要求パターンの要求数の最大数を設定する方式が考えられる。
　例えば、予測要求パターン数の最大数を５とする場合、要求パターン管理装置３４が生成する全ての予測要求パターンは最大で５個までとなり、有限数の要求で構成されたパターンの構成が可能になる。
　図３０は予測要求パターン数を最大５個までとした場合の要求パターンデータの生成例を示す説明図である。
　ここでは、説明の簡単化のため、要求パターン管理装置３４は、最初に一切の要求パターンデータを持っていない状態とする。
　その状態で、要求発行時系列リストに示す矢印の順番で、ＧＵＩ処理装置３２から要求が一括要求処理装置３３に通知される状況を想定する。

　最初の要求Ａが一括要求処理装置３３に通知されると、その要求Ａが要求パターン管理装置３４に通知され、要求パターン管理装置３４は、実要求情報Ａを生成するとともに（要求時系列解析結果（１）を参照）、初期値を持つ要求パターンリストを生成して、実要求情報Ａとの関連付けを行う（要求時系列解析結果（２）を参照）。
　その後に続く要求４個までは、新たに生成した要求パターンリストに挿入するフェーズに移行する。

　その後、順番に要求Ｂ、Ｃ、Ｄ、Ｅが通知されると、要求パターン管理装置３４は、直前に生成した後続要求リストの最後尾に要求を順次挿入する（要求時系列解析結果（３）を参照）。
　要求Ｅが後続要求リストに挿入された時点で、後続要求リストの要求数が４個で実要求が１個となり、最大数の５個に達したため、要求パターン管理装置３４は、次の要求が通知されたときは、実要求情報として処理するフェーズに移行する。

　その後、要求Ｆが通知されると、要求パターン管理装置３４は、要求パターンデータの実要求情報リストに要求Ｆと一致する情報があるか否かを確認する。
　その結果、一致する情報がないことが判明し、要求パターン管理装置３４は、実要求情報Ｆを生成するとともに（要求時系列解析結果（４）を参照）、初期値を持つ要求パターンリストを生成して、実要求情報Ｆとの関連付けを行う（要求時系列解析結果（５）を参照）。
　その後に続く要求４個までは、新たに生成した要求パターンリストに挿入するフェーズに移行する。

　その後、順番に要求Ｇ、Ｈ、Ｉ、Ｊが通知されると、要求パターン管理装置３４は、直前に生成した後続要求リストの最後尾に要求を順次挿入する（要求時系列解析結果（６）を参照）。
　要求Ｊが後続要求リストに挿入された時点で、後続要求リストの要求数が４個で実要求が１個となり、最大数の５個に達したため、要求パターン管理装置３４は、次の要求が通知されたときは、実要求情報として処理するフェーズに移行する。

　その後、要求Ａが通知されると、要求パターン管理装置３４は、要求パターンデータの実要求情報リストにＡと一致する情報があるか否かを確認する。
　その結果、一致する情報があることが判明すると、要求パターン管理装置３４は、一致した実要求情報に対して、初期値を持つ要求パターンリストを生成し、新たな要素として関連付けを行う（要求時系列解析結果（７）を参照）。
　その後に続く要求４個までは、新たに生成した要求パターンリストに挿入するフェーズに移行する。

　その後、順番に要求Ｋ、Ｌ、Ｍ、Ｎが通知されると、要求パターン管理装置３４は、直前に生成した後続要求リストの最後尾に要求を順次挿入する（要求時系列解析結果（８）を参照）。
　要求Ｎが後続要求リストに挿入された時点で、後続要求リストの要求数が４個で実要求が１個となり、最大数の５個に達したため、要求パターン管理装置３４は、次の要求が通知されたときは、実要求情報として処理するフェーズに移行する。

　以上の処理を繰り返すことによって、要求最大数が固定で指定された要求パターンを構成することが可能になる。
　ここで、固定される要求最大数であるが、システム全体として固定しても構わないが、例えば、ＧＵＩ画面単位で異なる値の固定値としても構わない。それ以外にも、状況に応じて、固定値を変動しても構わない。例えば、ＧＵＩノード１から発行される一括要求の予測成功率（例えば、実要求以外の予測要求が、一括要求生成後にＧＵＩ処理装置３２から実際に一括要求処理装置３３に発行要求された確率）がある閾値以上であれば、その固定値をインクリメントして、要求パターンに設定可能な要素数を増やし、一括要求で送信する要求数を増やすことで、更なる通信回数の削減を実現するなどが考えられる。
　この成功率に応じて変動させる場合には、要求パターン毎に固定値を設定する方法でも構わない。

（２）有限数の要求パターンを構成する別の方法として、ＧＵＩ処理装置３２から一括要求処理装置３３に通知されるＡＰＩ実行要求の時間間隔を利用する方法が考えられる。
　通常、ある一連の処理が開始され、その一連の処理の中で複数のＡＰＩを実行する場合、そのＡＰＩの実行間隔は、一般的に、ユーザ操作間隔等と比較して短い場合が多い。そのため、一連の処理が完了した後に、再度、ユーザ操作等のトリガーによって異なる一連の処理が発生するまでの時間は、一連の処理中のＡＰＩの実行間隔と比較すると、長い時間間隔である場合が多い。
　そのような状況を利用して、直前に通知された要求と、今回通知された要求の時間間隔を計測し、その時間間隔が所定の閾値（所定の時間間隔）未満であれば、その２つの要求は、一連の処理に含まれると判断することが可能となる。

　具体的には、図２５の地図更新処理に含まれる一連の要求である地図要求、地図情報要求、現在位置要求、住所要求の要求間の時間間隔は短くなるが、住所要求から次の地図要求が発行されるまでは、新たな画面更新タイミングが発生するまでとなるため、時間間隔が長くなることを意味している。
　上記の処理を行うため、この方法を採用した要求パターン管理装置３４は、要求が通知された際、前回の要求通知からの経過時間を算出する必要がある。
　図３１は前回の要求通知から今回の要求通知までの経過時間を算出する処理を示すフローチャートである。

　要求パターン管理装置３４は、一括要求処理装置３３から今回の要求となる要求Ａの通知を受けると（ステップＳＴ３０１）、現在時刻Ｔ１を取得する（ステップＳＴ３０２）。
　その後、前回の要求の通知時刻Ｔ０と時刻Ｔ１の差分ｄＴを算出する（ステップＳＴ３０３）。この差分ｄＴが要求Ａに対する経過時間となる。ここで、Ｔ０が未設定の場合には、ｄＴを０とする。
　要求パターン管理装置３４は、新たなＴ０の値として、Ｔ１の値を代入することで、経過時間算出処理を完了する（ステップＳＴ３０４）。

　要求パターン管理装置３４は、この処理によって算出した経過時間ｄＴが、システムとして定められた閾値ｓＴ未満である場合には、前回通知された要求が所属する要求パターンに対して、今回通知された要求Ａを追加する処理を実施する。
　一方、経過時間ｄＴが閾値ｓＴ以上である場合には、前回通知された要求が所属する要求パターンには、今回通知された要求Ａを追加せずに、新たな実要求として扱うことにする。

　図３２は経過時間を利用した場合の要求パターンデータの生成例を示す説明図である。
　要求発行時系列リストに示す矢印の順番で、ＧＵＩ処理装置３２から要求が一括要求処理装置３３に通知される状況を想定する。
　また、矢印のうち、単線矢印は、矢印の右の要求が通知された時刻と左の要求が通知された時刻の差分から算出された経過時間が閾値ｓＴ未満である事を意味し、二重線矢印は、ｓＴ以上であることを意味する。

　最初の要求Ａが通知されると、要求パターン管理装置３４は、経過時間を算出するが、前回の要求がないため、要求Ａを実要求として判定する。その結果、実要求情報Ａを生成するとともに、初期値を持つ要求パターンリストを生成して、実要求情報Ａとの関連付けを行う（要求時系列解析結果（１）を参照）。
　次に要求Ｂが通知されると、要求パターン管理装置３４は、経過時間を算出し、その結果、経過時間が閾値ｓＴ未満であることが判定される。
　経過時間が閾値ｓＴ未満の場合には、前回の要求Ａが属する要求パターンに対して、要求Ｂも属するため、要求Ｂを実要求Ａの最新の後続要求リストの要素として挿入する（要求時系列解析結果（２）を参照）。
　引き続き通知される要求Ｃ、Ｄについても、経過時間が閾値ｓＴ未満であるため、要求Ｂと同様に、実要求Ａの最新の後続要求リストの要素として挿入する（要求時系列解析結果（３）を参照）。

　次に要求Ｅが通知されると、要求パターン管理装置３４は、経過時間を算出し、その結果、経過時間が閾値ｓＴ以上であることが判定される。
　経過時間が閾値ｓＴ以上の場合には、前回の要求が属する要求パターンに、今回の要求が属さないため、要求Ｅを実要求として判定する。その結果、実要求情報Ｅを生成するとともに、初期値を持つ要求パターンリストを生成して、実要求情報Ｅとの関連付けを行う（要求時系列解析結果（４）を参照）。
　その後、２個目となる要求Ａが通知されると、要求パターン管理装置３４は、経過時間を算出し、その結果、経過時間が閾値ｓＴ以上であることが判定される。
　経過時間が閾値ｓＴ以上の場合には、前回の要求が属する要求パターンに、今回の要求が属さないため、要求Ａを実要求として判定する。ただし、実要求情報Ａは既に存在しているため、今回は新たに生成せずに、既存の実要求情報Ａを処理対象として、次の要求通知を待機する。

　次に要求Ｂ，Ｃ，Ｄが順次通知されると、それら全ての経過時間を算出し、全ての経過時間が閾値ｓＴ未満であることが判定され、実要求Ａに連続する要求パターンであると判定される。ただし、ここでは、既存の後続要求リストＢ，Ｃ，Ｄとパターンが一致しているため、現在の要求が、その後続要求リストのどの要素に対応する内容であるかを保持し続ける。つまり、要求Ｂが通知された場合には、後続要求リストの１番目の要求Ｂを指し示す情報を保持し、要求Ｃが通知された場合には、後続要求リストの２番目の要求Ｃを指し示す情報を保持し、要求Ｄが通知された場合には、後続要求リストの３番目の要求Ｄを指し示す情報を保持する。

　最終的に要求Ｄが通知された時点で、要求パターンとなるＡ，Ｂ，Ｃ，Ｄは２回発行していることになる。
　しかし、その次に通知される要求Ｅの経過時間が閾値ｓＴ未満であるならば、今回の要求パターンは、まだ未確定であるが、少なくとも要求Ａ，Ｂ，Ｃ，Ｄ，Ｅ、もしくは、それ以上の要求が続く要求パターンとなる。一方で、閾値ｓＴ以上であれば、今回の要求パターンはＡ，Ｂ，Ｃ，Ｄ，Ｅであることが確定する。
　つまり、閾値ｓＴ以上である場合、実際に通知された要求の時系列パターンが既存の要求パターンと一致することが確定する。その場合、一致した既存の要求パターンの信頼度パラメータを強化する方向で更新する。強化する方向で更新することによって、その要求パターンが一括要求の際に採用される確度を高めることになり、結果として、予測が成功する確率を向上させることが可能になる。
　一方、閾値ｓＴ未満の場合には、実際に通知された要求の時系列パターンが既存の要求パターンと一致しないことが確定するため、その場合には、初期値を持つ要求パターンリストを新たに生成し、その中の後続要求リストに要求Ｂ，Ｃ，Ｄ，Ｅを設定し、実要求情報Ａとの関連付けを行う（要求時系列解析結果（６）を参照）。

　以上のように、前回の要求通知から今回の要求通知までの経過時間によって、要求パターンの構成を判別する方法を利用することで、要求リストの要素最大数を指定する方法と比較して、より長いパターンの要求パターンを構成することが可能になるとともに、システムの動作状況に応じた要求パターンの判定が可能になる。

（３）有限数の要求パターンを構成する別の方法として、要求種別を利用する方法が考えられる。
　ＧＵＩノード１からサービスノード２に発行される要求は、ＡＰＩ実行要求以外にも、次の画面をＧＵＩノードで表示するためのＧＵＩ記述データを取得するためのＧＵＩ記述データ取得要求や、ネットワーク上に存在するノード全体にブロードキャストを行い、ノードの存在確認を行う等のシステム情報取得要求などがあり、要求する内容によって、分類することが可能である。

　ＧＵＩ記述データ取得要求が発行された場合、ＧＵＩノード１で画面上に表示する内容が更新されることを意味するため、その前後で、要求パターンが連続することは好ましくない。このＧＵＩ記述データ取得要求のように、その前後で、要求パターンの連続を断ち切る基準となる要求を終端要求と呼ぶことにする。
　そのことを利用して、有限数の要求パターンを構成するためには、例えば、ＧＵＩ記述データ取得要求が通知された場合に、前回の要求が属する要求パターンとは別の要求パターンとして、その要求もしくは次回通知されることになる要求を処理すべきか否かを示す終端要求内容テーブルを要求パターン管理装置３４が保持する必要がある。

　終端要求内容テーブルの１つの具体例として、ＧＵＩノード１からサービスノード２に発行される全ての要求のうち、終端要求と判定すべき要求の識別情報をテーブルに登録したものが考えられる。
　つまり、要求パターン管理装置３４は、要求が通知される度に、通知された要求の識別情報が終端要求内容テーブルにあるか否かの検索を行い、通知された要求の識別情報がある場合には、次回通知されることになる要求を新たな実要求として判定する準備を行い、次の要求通知を待機する。
　一方、通知された要求の識別情報がない場合には、前回通知された要求が属する要求パターンに対して、次回通知されることになる要求を追加する準備を行い、次の要求通知を待機する。このとき、終端要求と判定された今回の要求を前回通知された要求が属する要求パターンに追加しても構わない。その基準を終端要求内容テーブルに記述してあるとして、その基準に従って要求パターンへの追加の実施を決定するとしてもよい。

　終端要求内容テーブルは、要求パターン管理装置３４が固定で保持しているとしても構わない。一方で、終端要求内容テーブルは、サービスノード２からＧＵＩノード１が取得するようにしてもよい。
　サービスノード２から取得する方式を採用することで、サービスノード２が提供するサービスに適合する終端要求内容テーブルを用いた判定が行えるため、より確度の高い一括要求の生成が可能になる。

　更なる実施例として、新たな要求パターン管理装置３４の動作を説明する。
　要求パターン管理装置３４は、一括要求処理装置３３から出力される要求パターンの生成指示によって渡される要求をキーとして、その要求の後に要求されると予測される１つ以上の要求を決定する。その際に、決定した一つ以上の要求の中から、ある特定の要求を除外した結果を一括要求処理装置３３に返信する。
　例えば、後に要求されると予測される要求の中に、サービスノード２の状態を変更する要求（サービス状態変更要求）が含まれている場合、そのサービス状態変更要求を含めた状態で一括要求を生成して、その一括要求をサービスノード２に送信すると、サービスノード２は、サービス状態変更要求を実行することになり、サービスノードの状態が更新される。

　しかし、そのサービス状態変更要求は、ＧＵＩノード１で実際に要求すべき要求と決定しているわけではないため、その実行がＧＵＩノード１にとって想定していないサービスノード２の状態を引き起こす可能性がある。
　一括要求処理装置３３から要求パターンの生成指示を受けた要求パターン管理装置３４は、要求パターンデータから対応する要求パターンを決定した後に、ある特定の要求をその要求パターンから除外することによって、上記のようなＧＵＩノード１が想定しないサービスノード２の状態変更が発生しない要求パターンに更新することが可能になる。
　上記の例では、サービス状態変更要求に分類される要求が要求パターンに含まれている場合には、その要求を要求パターンから除外して、新たな要求パターンを構築して、その要求パターンを一括要求処理装置３３に返すことになる。

　また、上記の処理以外にも、要求パターン管理装置３４が要求パターンデータを更新する際に、除外対象となる要求を要求パターンデータに格納しない制御を行うこととし、一括要求処理装置３３から要求パターンの生成指示を受けた際には、除外対象となる要求を要求パターンから除外する処理を実施しないこととしても構わない。
　上記の２種類の処理方式と共に、除外対象となる要求パターンの判定基準となる情報は、ＧＵＩノード１内で固定値として保持するとしても構わない。また、判定基準となる情報は、システム起動時等でサービスノード２に対して取得要求を行うことで、システムとして連携して動作するサービスノード２毎の基準で判定可能としても構わない。

　さらに、上記の処理以外にも、除外対象となる要求を含めて一括要求を生成し、ＧＵＩノード１からサービスノード２に発行した後に、サービスノード２側の一括要求解釈装置４２が、除外対象となる要求判定を行い、除外対象と判定された要求は要求処理装置４３に出力せずに、エラー応答を一括応答生成装置４５に通知するようにしても構わない。
　その場合には、ＧＵＩノード１の応答処理装置３６でエラー応答を検出したとき、そのエラー応答を応答記憶装置３１に記憶しない制御を行う。

実施の形態４．
　上記実施の形態１～３では、応答処理装置３６が、通信装置３５により受信された一括応答に含まれている実行要求及び予測要求に対応する応答などの情報を応答記憶装置３１に格納するものを示したが、応答記憶装置３１に一旦情報が記憶されると、何もしなければ記憶され続けることになる。
　しかし、いつまでも、その情報が記憶され続けると、その情報が実際のサービスノード２の情報と合致しない状態になる可能性がある。
　そこで、この実施の形態４では、応答記憶装置３１に記憶されている応答などの情報を、あるタイミングで削除する制御を行うようにしている。

　応答記憶装置３１に記憶されている応答を削除する１つの方法として、以下の方法が考えられる。
　応答記憶装置３１は、応答処理装置３６から、ある応答に関する応答保存要求を受けると、受付時の時刻情報と一緒に、その応答を保存する。
　応答処理装置３６は、一定時間間隔で、応答記憶装置３１により現在保存されている全応答に対して、保存開始時点からの経過時間を算出し、ある応答の経過時間が、ある一定の閾値を経過している場合には、その応答を応答記憶装置３１から削除する制御を行う。
　上記の制御を行うことで、永久的に特定の応答が保存され続ける状況を解消することが可能になる。

　応答を削除する別の方法として、以下の方法が考えられる。
　応答記憶装置３１は、応答処理装置３６から、ある要求に対応する応答の取得要求を受けると、指定された要求に対する応答が保存されているか否か検索し、保存されている場合には、その応答を応答処理装置３６に返信する。
　応答処理装置３６は、要求に対する応答が保存されている場合、その応答を応答記憶装置３１から削除する制御を行う。
　この制御を行うことで、永久的に特定の応答が保存され続ける状況を解消することが可能になる。

　上記の制御は１回目の取得要求で削除する例として説明しているが、必ずしも１回目で削除する必要はなく、Ｎ回目の取得要求で削除するとしても構わない。その場合には、応答記憶装置３１は、保存する応答に対して、何回取得要求されたかを記憶する領域を設けて保存し、応答の保存時に、その領域には０を記録し、取得要求で処理される度にインクリメントを行う。
　応答処理装置３６は、その領域の値がＮであるか否かを判定し、Ｎになった時点で、その応答を削除するようにする。

　応答を削除する別の方法として、以下の方法が考えられる。
　サービスノード２の一括応答生成装置４５は、一括応答を生成する際に、各応答と一緒に、その応答がＧＵＩノード１内での有効期限となる情報（有効期限情報）、例えば、参照回数や生存時間などを一括応答に組み込んで生成する。
　一括応答を受信したＧＵＩノード１の応答処理装置３６は、一括応答に含まれている各応答と、それに対応する有効期限情報を抽出し、それらを組として応答記憶装置３１に保存する。
　有効期限情報が参照回数である場合、応答処理装置３６は、ある要求に対応する応答の取得要求を応答記憶装置３１に出力するタイミングで、その要求に対応する応答の有効期限情報と、その要求の参照回数情報を比較し、有効期限情報の方が小さければ、その応答を応答記憶装置３１から削除する制御を行う。

　また、有効期限情報が生存時間である場合、応答処理装置３６は、一定時間間隔で、応答記憶装置３１に保存されている全応答に対して、保存開始時点からの経過時間を算出し、ある応答の経過時間が、ある一定の閾値を経過している場合には、その応答を応答記憶装置３１から削除する制御を行う。
　その有効期限情報については、一括応答に毎回格納する処理としなくても構わない。例えば、全ての応答に対する有効期限情報が記述された有効期限情報テーブルを定義し、それをＧＵＩノード１が保持しており、その有効期限情報テーブルの情報を用いて、有効期限を超過した応答を判定して、削除処理を行うとしても構わない。
　また、有効期限情報テーブルは、サービスノード２が保持しており、ＧＵＩノード１からの明示的な有効期限情報テーブルの取得要求の応答として、サービスノード２からＧＵＩノード１に提供する方式でも構わない。

　応答を削除する別の方法として、以下の方法が考えられる。
　サービスノード２の一括応答生成装置４５は、一括応答を生成する際に、どの要求に対応する応答を、どんな値で、どのＧＵＩノード１に送信しているかを管理する応答提供管理手段を備えている。
　応答提供管理手段では、例えば、図３３に示すような応答提供管理テーブル等で、どの要求に対応する応答を、どんな値で、どのＧＵＩノード１に送信しているかを管理する。
　応答提供管理テーブルには、どの要求に対応する応答であるかを示す提供応答ＩＤと、提供した応答の具体的な値を示す提供応答値と、その応答をどのＧＵＩノード１に提供したのかを示す提供先ＧＵＩノードＩＤリストとを備えたテーブルである。
　ただし、サービスノード２が連携するＧＵＩノード１がシステム上唯一であれば、提供先ＧＵＩノードＩＤリストは省略しても構わない。

　図３３の応答提供管理テーブル（１）では、ＧＵＩノード１に提供した応答が２種類ある状態を示している。
　提供応答ＩＤには、その応答に対応する要求となるＵＲＬの一部を抽出してＩＤとして記述する例を示している。
　提供応答値には、応答となるＪＳＯＮ形式の値を格納する例を示している。
　提供先ＧＵＩノードＩＤリストには、要求元となるＧＵＩノード１のドメイン名の一部を抽出してＩＤとして記述する例を示している。
　例えば、提供応答ＩＤが“/srv1/getProps()”の応答をドメイン名の一部が“GUInode1”、または、“GUInode2”の２種類のＧＵＩノード１に提供していることを示している。

　この応答提供管理テーブル（１）の状態において、一括応答生成装置４５が、提供応答ＩＤが、例えば、“/srv1/getProps()”の応答の値の全て又は一部が更新されたことを検知したとする。
　その場合、一括応答生成装置４５は、提供応答ＩＤが“/srv1/getProps()”に対応する提供先ＧＵＩノードＩＤリストに登録されているＧＵＩノード１に対して、応答ＩＤが“/srv1/getProps()”の応答を応答記憶装置３１から削除要求を意味する応答削除要求イベントを発行する。

　図３４は応答削除要求イベントの記述例を示す説明図である。
　図３４の例では、ＪＳＯＮ形式の配列オブジェクトとして、応答削除要求イベントを記述している。第１要素でイベントの識別情報となるイベント名を記述し、第２要素で削除対象となる応答ＩＤを記述している。
　イベントの識別情報は、イベント名に限る必要はなく、個々のイベントに定義したイベント識別番号等でも構わない。
　また、図３４の例では、削除対象となる応答ＩＤは１つとなっているが、第２要素以降の要素は全て削除対象となる応答ＩＤを記述する仕様として、１つの応答削除要求イベントで、複数の削除対象となる応答ＩＤを記述可能としても構わない。
　なお、ＨＴＴＰを利用したクライアント・サーバシステムでは、サーバ装置からクライアント端末に対して、自発的に情報を発信する方法としてはＣｏｍｅｔやＳｅｒｖｅｒ－ＳｅｎｔＥｖｅｎｔｓ、ＷｅｂＳｏｃｋｅｔＡＰＩを利用することで実現可能である。

　応答削除要求イベントを発行後、一括応答生成装置４５は、そのイベントに対応する応答が記述されている要素を応答提供管理テーブルから削除する。
　例えば、図３３の応答提供管理テーブル（１）の状態で、応答ＩＤが“/srv1/getProps()”の要素に対して、応答削除要求イベントを発行した場合には、対応する要素を削除して、応答提供管理テーブルは図３３の応答提供管理テーブル（２）の状態に更新される。
　一方で、応答削除要求イベントを受信したＧＵＩノード１では、応答処理装置３６が、応答削除要求イベントを解釈し、削除対象となる応答ＩＤに対応する応答を削除するように応答記憶装置３１に要求することで、その応答を応答記憶装置３１から削除する制御を行う。
　以上の制御を行うことによって、ＧＵＩノード１の応答記憶装置３１に記憶された応答がサービスノード２内の状態と一致しなくなるまで、応答記憶装置３１が記憶し続ける状況を回避することができる。

　また、一括応答生成装置４５が、ある応答値の更新を検知した場合に、応答削除要求イベントではなく、応答更新要求イベントを発行することにしてもよい。
　応答更新要求イベントは、ＧＵＩノード１の応答記憶装置３１に記憶されている特定の応答を、そのイベントに記述されている応答の値に更新するように、サービスノード２からＧＵＩノード１への要求を記述したイベントである。
　図３５は応答更新要求イベントの記述例を示す説明図である。
　図３５の例では、ＪＳＯＮ形式の配列オブジェクトとして、応答更新要求イベントを記述している。第１要素でイベントの識別情報となるイベント名を記述し、第２要素で更新対象となる応答ＩＤを記述し、第３要素で更新すべき応答の値を記述している。
　イベントの識別情報はイベント名に限る必要はなく、個々のイベントに定義したイベント識別番号等でも構わない。
　また、図３５の例では、更新対象となる応答ＩＤと、その更新すべき応答の値は一組しか記述されていないが、複数個記述しても構わない。

　応答更新要求イベントを発行後、一括応答生成装置４５は、そのイベントに対応する応答が記述されている要素を応答提供管理テーブルから検索し、その要素の提供応答値を更新すべき応答の値に書き換える。
　例えば、図３３の応答提供管理テーブル（１）の状態で応答ＩＤが“/srv1/getProps()”の要素に対して、図３５に示す応答更新要求イベントを発行した場合、対応する要素の提供応答値の値を応答更新要求イベントの更新すべき応答の値に書き換え、図３３の応答提供管理テーブル（３）の状態に更新される。

　また、応答更新要求イベントを発行する対象となる応答を一部の応答に制限をかけても構わない。
　例えば、サービスノード２が保持する内部変数を参照するためのＡＰＩの実行要求に対応する応答は、サービスノード２の内部状態の変更に伴って頻繁に更新されることになる。
　一方で、サービスのある特定の機能を呼び出し、応答として処理成功・失敗フラグを返すようなＡＰＩの実行要求に対応する応答は、正常処理であれば、大多数の場合、成功フラグを返すことになり、応答が更新される頻度は低い。

　そこで、頻繁に要求される応答で、かつ、頻繁に応答が更新されるような上述のサービスノードの内部状態を表す変数の参照要求ＡＰＩのみに限り、応答更新要求イベントを発行するとしても構わない。
　その場合には、一括応答生成装置４５が応答提供管理テーブルを構築する際に、応答更新要求イベントの発行対象の要求に対応する応答であるか否かを判定し、発行対象でない場合には、応答提供管理テーブルへの登録処理をスキップする機能を持たせることで可能になる。

　加えて、サービスノード２の内部状態を参照するＧＵＩノード１での処理は、ＧＵＩノード１で処理中のＧＵＩ内容に依存して大きく変化することが考えられる。
　そのため、一括応答生成装置４５が持つ応答提供管理テーブルをＧＵＩ記述データ別に管理することとして、イベント発生を抑制することが考えられる。
　ＧＵＩ記述データ取得要求を受けたサービスノード２は、一括応答生成装置４５が、それまでに構築した応答提供管理テーブルを消去し、新たな応答提供管理テーブルを構築するとしてもよい。
　その場合、サービスノード２と連携するＧＵＩノード１が複数ある場合には、一括応答生成装置４５が管理する応答提供管理テーブルはＧＵＩノード１別に構築し、各ＧＵＩノード１からＧＵＩ記述データ取得要求を受けた場合には、そのＧＵＩノード１に対応する応答提供管理テーブルのみを消去することで、複数のＧＵＩノード１と連携する場合でも対応可能である。
　また、ＧＵＩ記述データ取得要求のみをトリガーとして対応する応答提供管理テーブルの消去を行う必要はなく、１つ以上の特定の要求の受信をトリガーとしてもよいし、あるパラメータが設定されているある特定の要求の受信をトリガーとしても構わない。

　なお、本願発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。

　この発明は、連携処理に係るネットワーク通信の回数を十分に削減する必要がある通信システムに適している。

　１　ＧＵＩノード（クライアント端末）、２　サービスノード（サーバ装置）、３　ネットワーク、１１　ＧＵＩ処理モジュール、１２　ディスプレイ、１３　入力インタフェース、１４　出力インタフェース、２１ａ，２１ｂ，２１ｃ　サービスモジュール（応答生成手段）、２２　サービス提供モジュール、３１　応答記憶装置（応答記憶手段）、３２　ＧＵＩ処理装置（実行要求発行手段）、３３　一括要求処理装置（要求パターン生成手段）、３４　要求パターン管理装置（要求パターン生成手段）、３５　通信装置（通信手段）、３６　応答処理装置（応答処理手段）、４１　通信装置（要求パターン受信手段、応答送信手段）、４２　一括要求解釈装置（応答取得手段）、４３　要求処理装置（応答取得手段）、４４ａ，４４ｂ，４４ｃ　サービス実行装置（応答生成手段）、４５　一括応答生成装置（応答取得手段）、４６　応答記憶装置（応答取得手段）。

Claims

　サービスの実行要求を発行するクライアント端末と、上記クライアント端末により発行された実行要求に対応するサービスを実行して、上記サービスの処理結果である応答を生成し、上記応答を上記クライアント端末に返信するサーバ装置とを備えた通信システムにおいて、
　上記クライアント端末は、上記サーバ装置から返信された応答を記憶する応答記憶手段と、サービスの実行要求を発行する実行要求発行手段と、上記実行要求発行手段により発行された実行要求に対応する応答が上記応答記憶手段に記憶されていれば、上記応答を上記実行要求発行手段に出力する旨を指示する出力指令を出力する一方、上記実行要求に対応する応答が上記応答記憶手段に記憶されていなければ、上記実行要求に続いて発行される可能性がある要求を予測し、その予測要求と上記実行要求からなる要求パターンを生成する要求パターン生成手段と、上記要求パターン生成手段により生成された要求パターンを上記サーバ装置に送信する一方、上記要求パターンを構成している実行要求及び予測要求に対応する上記サーバ装置から送信された応答を受信する通信手段と、上記要求パターン生成手段から出力指令を受けると、上記応答記憶手段に記憶されている実行要求に対応する応答を上記実行要求発行手段に出力し、上記通信手段により実行要求及び予測要求に対応する応答が受信されると、上記実行要求及び上記予測要求に対応する応答を上記応答記憶手段に格納するとともに、上記実行要求に対応する応答を上記実行要求発行手段に出力する応答処理手段とから構成されていることを特徴とする通信システム。
　サーバ装置は、各種の実行要求に対応するサービスを実行し、上記サービスの処理結果である応答を生成する１以上の応答生成手段と、クライアント端末から送信された要求パターンを受信する要求パターン受信手段と、上記要求パターン受信手段により受信された要求パターンを構成している個々の要求毎に、当該要求に対応するサービスを実行する応答生成手段を特定して、当該要求を上記応答生成手段に与え、上記応答生成手段により生成された応答を取得する応答取得手段と、上記応答取得手段により取得された個々の要求に対応する応答を上記クライアント端末にまとめて送信する応答送信手段とから構成されていることを特徴とする請求項１記載の通信システム。
　要求パターン生成手段は、実行要求発行手段により発行された実行要求の履歴を管理して、ある実行要求が発行された後、上記実行要求に続いて発行された実行要求の発行頻度を更新する処理を実施する一方、
　上記実行要求発行手段から新たに実行要求が発行されると、上記実行要求を要求パターンの先頭要素に決定するとともに、過去に上記実行要求に続いて発行された実行要求の中で、発行頻度が最高の実行要求を上記要求パターンの次要素に決定する処理を実施し、
　上記要求パターンの次要素を決定する処理を１回以上繰り返し実施することを特徴とする請求項１記載の通信システム。
　要求パターン生成手段は、ＧＵＩに表示される画面単位に、実行要求発行手段により発行された実行要求の履歴を管理して、実行要求の発行頻度を更新する処理を実施し、
　上記実行要求発行手段により新たに発行された実行要求が同じ実行要求であっても、ＧＵＩに表示されている画面が異なれば、異なる要求パターンを生成することがあることを特徴とする請求項３記載の通信システム。
　要求パターン生成手段は、要求パターンに含まれる要求の個数が予め設定されている上限数を超えないように、要求パターンを生成することを特徴とする請求項１記載の通信システム。
　要求パターン生成手段は、実行要求発行手段により前回発行された実行要求の発行時刻と、今回発行された実行要求の発行時刻との時刻差が閾値以上であれば、前回発行された実行要求と今回発行された実行要求を異なる要求パターンに含めることを特徴とする請求項１記載の通信システム。
　要求パターン生成手段は、要求パターンの中に特定の要求が含まれないように要求パターンを生成することを特徴とする請求項１記載の通信システム。
　要求パターン生成手段は、サーバ装置により実行されるサービスの状態の変更要求を特定の要求として、その変更要求を要求パターンに含めないようにすることを特徴とする請求項７記載の通信システム。
　応答取得手段は、要求パターン受信手段により受信された要求パターンに含まれている要求が特定の要求である場合、クライアント端末に対するエラー応答の通知を応答送信手段に指示することを特徴とする請求項２記載の通信システム。
　応答処理手段は、応答記憶手段に記憶されている１以上の応答のうち、所定の削除条件を満足する応答を削除することを特徴とする請求項２記載の通信システム。
　応答処理手段は、削除条件が保存期間である場合、応答記憶手段に記憶されている期間が上記保存期間を超えている応答を削除することを特徴とする請求項１０記載の通信システム。
　応答処理手段は、削除条件が参照回数である場合、実行要求発行手段に出力された回数が上記参照回数を超えている応答を削除することを特徴とする請求項１０記載の通信システム。
　応答取得手段は、応答生成手段により生成された応答の削除条件を設定し、
　応答送信手段は、個々の要求に対応する応答をクライアント端末に送信する際、上記応答取得手段により設定された削除条件を上記クライアント端末に送信することを特徴とする請求項１０記載の通信システム。
　サーバ装置から返信された応答を記憶する応答記憶手段と、サービスの実行要求を発行する実行要求発行手段と、上記実行要求発行手段により発行された実行要求に対応する応答が上記応答記憶手段に記憶されていれば、上記応答を上記実行要求発行手段に出力する旨を指示する出力指令を出力する一方、上記実行要求に対応する応答が上記応答記憶手段に記憶されていなければ、上記実行要求に続いて発行される可能性がある要求を予測し、その予測要求と上記実行要求からなる要求パターンを生成する要求パターン生成手段と、上記要求パターン生成手段により生成された要求パターンを上記サーバ装置に送信する一方、上記要求パターンを構成している実行要求及び予測要求に対応する上記サーバ装置から送信された応答を受信する通信手段と、上記要求パターン生成手段から出力指令を受けると、上記応答記憶手段に記憶されている実行要求に対応する応答を上記実行要求発行手段に出力し、上記通信手段により実行要求及び予測要求に対応する応答が受信されると、上記実行要求及び上記予測要求に対応する応答を上記応答記憶手段に格納するとともに、上記実行要求に対応する応答を上記実行要求発行手段に出力する応答処理手段とを備えたクライアント端末。
　各種の実行要求に対応するサービスを実行し、上記サービスの処理結果である応答を生成する１以上の応答生成手段と、クライアント端末から送信された要求パターンを受信する要求パターン受信手段と、上記要求パターン受信手段により受信された要求パターンを構成している個々の要求毎に、当該要求に対応するサービスを実行する応答生成手段を特定して、当該要求を上記応答生成手段に与え、上記応答生成手段により生成された応答を取得する応答取得手段と、上記応答取得手段により取得された個々の要求に対応する応答を上記クライアント端末にまとめて送信する応答送信手段とを備えたサーバ装置。