(57)【要約】      （修正有）【課題】クライアント処理装置とサーバ処理装置の通信回数を削減することで複数の独立したプログラムが動作するクライアント装置の処理性能、特にユーザ操作に対するレスポンスを向上させる通信方法を提供する。【解決手段】アプリ１２１がサーバ処理装置１３０に出力する特定のリクエストと同タイミングに発生するリクエストを、予め通信グルーピングテーブル１２６に定義しておく。アプリが実際にリクエストを出力すると、通信グルーピングテーブル１２６を参照し、同タイミングで発生するリクエストもまとめてサーバ処理装置１３０に送信する。サーバ処理装置では、複数のリクエストを一括して処理し、結果をクライアント処理装置１１０に返す。【選択図】図１
2012064128.tif 000002
【特許請求の範囲】
【請求項１】
複数のアプリが同時に動作するクライアント処理装置と、前記クライアント処理装置に接続され、前記アプリからのリクエストに対応した処理を実行するサーバ処理装置からなるシステムにおいて、
前記クライアント処理装置は、
第一のアプリが前記サーバ処理装置に送出する第一のリクエストと、前記第一のアプリから呼び出される前記第一のアプリ以外の第二のアプリが同タイミングで送出する第二のリクエストがあったとき、
前記クライアント処理装置内の通信グルーピングテーブルに前記第一のリクエストと前記第二のリクエストとの関連を定義しておき、
前記第一のアプリから前記第一のリクエストが発生したとき、前記通信グルーピングテーブルから前記第二のリクエストを見つけ、前記第一のリクエストと前記第二のリクエストを合成したリクエストを前記サーバ処理装置の仲介機能に送信し、
前記サーバ処理装置は、
前記仲介機能によって、前記第一のリクエストを処理する第一の提供機能を呼び出して第一の処理結果を取得し、前記第二のリクエストを処理する第二の提供機能を呼び出して第二の処理結果を取得し、
前記第一及び第二の処理結果を合成して前記クライアント処理装置に返し、
前記クライアント処理装置では、
前記合成された処理結果を分割し、前記第一の処理結果を前記第一のアプリに返し、
前記第二の処理結果はキャッシュに保存し、
前記第二のリクエストが発生したとき、前記キャッシュから前記第二の処理結果を取得して前記第二のアプリに返すことを特徴とする通信量削減方法。
【請求項２】
請求項１において、前記サーバ処理装置で動作する仲介機能、前記第一の提供機能、前記第二の提供機能を、別のサーバ処理装置で動作するように構成し、前記仲介機能は、リクエストに応じて前記別のサーバ処理装置にある提供機能を呼び出すことを特徴とする通信量削減方法。
【請求項３】
請求項１において、
前記第一のリクエストと前記第二のリクエストが各々、パラメータを持っているときに、前記第一のリクエストのパラメータと、前記第二のリクエストのパラメータの間の関係を前記通信グルーピングテーブル内に定義しておき、
前記第一のリクエスト発生時に、前記通信グルーピングテーブル内に定義した関係を利用し、前記第一のリクエストに含まれるパラメータから、前記第二のリクエストに含まれるパラメータを生成することを特徴とする通信量削減方法。
【請求項４】
請求項１において、前記クライアント処理装置から前記サーバ処理装置へのリクエストの送信履歴から前記通信グルーピングテーブルを生成する際に、
前記クライアント処理装置から前記サーバ処理装置へのリクエスト送信時に、前記クライアント処理装置ではログを記録しておき、
前記クライアント処理装置で動作する通信グルーピングテーブル更新機能は、溜まったログを解析し、
リクエストが発生した時刻の差が特定時間内であるリクエストを抽出し、
前記ログ内で前記第三のリクエストと前記第四のリクエストが同時に発生した回数を評価し、評価の結果、同タイミングで発生することが多いことが分かったらそれらを前記通信グルーピングテーブルに格納することを特徴とする通信量削減方法。
【請求項５】
請求項４において、前記第三のリクエストと前記第四のリクエストのパラメータ値を比較し、パラメータ値の間に関係があるときに、前記第三のリクエストと前記第四のリクエストを対応付けて前記通信グルーピングテーブルに格納することを特徴とする通信量削減方法。
【請求項６】
複数のアプリが同時に動作するクライアント処理装置と、前記クライアント処理装置に接続され、前記アプリからのリクエストに対応した処理を実行するサーバ処理装置からなるシステムにおいて、
前記クライアント処理装置は、
第一のアプリが前記サーバ処理装置に送出する第一のリクエストと、前記第一のアプリから呼び出される前記第一のアプリ以外の少なくとも一つの第二のアプリが一連の操作の中で送出する第二のリクエストがあったとき、
前記クライアント処理装置内の通信グルーピングテーブルに、前記第一のリクエストと前記少なくとも一つの第二のリクエストとの関連を予め定義しておき、
前記第一のアプリから前記第一のリクエストが発生したとき、前記通信グルーピングテーブルを参照して、前記リクエストの送受信を制御するための制御テーブルに、前記第一のリクエストと前記少なくとも一つの第二のリクエストを設定し、
キャッシュ内に、前記第一のリクエスト及び前記少なくとも一つの第二のリクエストのそれぞれに対応した処理結果が既に存在するかどうかを調べて、存在の有無に応じたオン又はオフの第１のフラグを、前記第一のリクエスト及び前記少なくとも一つの第二のリクエストのそれぞれに対応して、前記制御テーブルに設定し、
前記第１のフラグの値の補数である第２のフラグを、前記第一のリクエスト及び前記少なくとも一つの第二のリクエストのそれぞれに対応して、前記制御テーブルに設定し、
前記第１のフラグがオンである少なくとも一つの前記リクエストのそれぞれの処理結果を、前記アプリのそれぞれに返し、
前記第２のフラグがオンである少なくとも一つの前記リクエストを合成して前記サーバに送信し、前記サーバ処理装置から合成された処理結果をまとめて受け取ったら分割してキャッシュに保存することを特徴とする通信量削減方法。
【発明の詳細な説明】
【技術分野】
【０００１】
携帯電話やカーナビ、PCのようなクライアント処理装置(コンピュータ)で動作する複数のプログラムと、クライアント処理装置とネットワークで接続したサーバ処理装置(コンピュータ)で動作するサーバプログラムの通信方法に関する。
【背景技術】
【０００２】
Android端末では、ユーザが自分でインターネット上に存在するマーケットからアプリを自由にインストールできる。インストールしたアプリは各々必要に応じて独立してネットワークを介してサーバと通信を行う。
特開2009-157648は、クライアント処理装置で稼動する複数のウィジェットと呼ぶプログラムが各々サーバと通信するとき、ウィジェットが出力するサーバに対するリクエストを、クライアント端末に配したバッファに保存しておき、バッファが一杯になる、又はバッファ期間が満了するタイミングでバッファに溜まったリクエストをサーバに向かって一括送信し、サーバから応答データを受信すると、受信データを解析し、リクエストしたウィジェットを特定して、個々のウィジェットに返すことにより、
ネットワーク通信の発生回数を抑制することができ、通信トラフィックの増大を防ぐことを可能とする方法を開示している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開2009-157648号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
Android端末で、Androidマーケットから取得するようなアプリでは、個別に取得したアプリ同士が連携して動作することが可能である。
しかし、アプリとサーバとの通信はアプリ毎に独立に実施されているため、多くのデータの送受信が発生すると、送受信処理の負荷により性能が悪化することがあった。
特開2009-157648を用いると、リクエストを一時的にバッファに保存し、バッファが一杯になる又はバッファ期間が満了するまでリクエストが送出されないため、通信量を削減することが可能となるが、アプリがリクエストしたときにすぐにリクエストが発生しないことがあるため、レスポンス受信が遅くなることがあると考えられる。
本発明の目的は、通信回数を削減することでウィジェットのような複数の独立したプログラムが動作するクライアント装置の処理性能を向上すること。特にユーザ操作に対するレスポンスを向上すること。
【課題を解決するための手段】
【０００５】
クライアント処理装置で動作する第一のアプリと第一のアプリに関連する第二のアプリが同時に動作しているとき、
第一のアプリがサーバ処理装置に第一のリクエストを送信するタイミングで、第二のアプリがサーバ処理装置に第二のリクエストを送信することが多い場合、
第一のリクエストと第一のリクエストに関連する第二のリクエストとの対応関係をクライアント処理装置の通信グルーピングテーブルに格納しておく。
クライアント処理装置内のサーバ通信仲介機能はアプリからサーバ処理装置に向けて発生する全てのリクエストを仲介する。
サーバ通信仲介機能が第一のリクエストを検出すると、第一のリクエストと同種のリクエストを通信グルーピングテーブルから検索し、第一のリクエストの記述があれば、第二のリクエストを生成し、第一及び第二のリクエストを合成してサーバ処理装置に送信する。
サーバ処理装置が合成したリクエストを受けると、第一のリクエストと第二のリクエストに対する処理を各々実施し、双方の処理結果を合成してクライアント処理装置に返す。
サーバ通信仲介機能が処理結果を受け取ると、処理結果を分解し、第一のリクエストに対応する処理結果を第一のアプリに返し、その他の処理結果はサーバ通信キャッシュに保存する。
第二のアプリが送信した第二のリクエストをサーバ通信仲介機能が検出すると、そのリクエストに対応する処理結果がサーバ通信キャッシュに存在するかどうかを調べ、サーバ通信キャッシュにあればその処理結果を第二のアプリに返す。
【発明の効果】
【０００６】
クライアント処理装置で稼働中のアプリが各々独立して実施していた通信を、一括して実施することでアプリの性能向上を実現する。
【図面の簡単な説明】
【０００７】
【図１】実施例１の構成図を示す。
【図２】カーナビ上のアプリの動作例を示す。
【図３】通信グルーピングテーブルを示す。
【図４】サーバ通信キャッシュを示す。
【図５】通信に関連がある部分のシーケンス図を示す。
【図６】サーバ通信仲介機能のフローチャートを示す。
【図７】クライアント通信仲介機能のフローチャートを示す。
【図８】実施例２の構成図を示す。
【図９】通信グルーピングテーブル更新機能のフローチャートを示す。
【図１０】送受信制御テーブル。
【図１１】関連リクエストが複数の場合の通信グルーピングテーブル。
【発明を実施するための形態】
【０００８】
（実施例１）
図1に実施例1におけるシステムの構成図を示す。
本実施例では、クライアント処理装置110にカーナビ端末を用い、サーバ処理装置130とネットワーク100を介して通信して処理を実施するように構成する。
各処理装置(110、130)は、CPU(112、132)、入力部(115、135)、表示部(113、133)、通信部(111、131)、メモリ(120、140)等を持つコンピュータである。
CPU(112、132)はプログラムやデータをメモリ(120、140)に読み込み、プログラムに従い処理を行う。表示部はプログラムをCPU(112、132)の処理結果をユーザに示し、入力部(115、135)はユーザからの入力を受け付ける。通信部(111、131)は、ネットワーク100を介して別の処理装置とデータのやり取りを実施する。さらにクライアント処理装置110には自車位置を取得するためにGPS114がある。
クライアント処理装置110のメモリ120には、プログラムであるサーバ通信仲介機能124、GPS管理機能125、アプリ群121及び、データである通信グルーピングテーブル126、サーバ通信キャッシュ127がある。
サーバ処理装置130のメモリ140には、プログラムであるクライアント通信仲介機能144、サーバ機能145、提供機能群141がある。
クライアント処理装置110のアプリ121はサーバ処理装置130と通信して処理を行う。
本実施例では、ナビアプリ122と広告アプリ123の二つのアプリを例に説明する。
図2に、クライアント処理装置であるカーナビ上で動作するアプリの動作例として、ナビアプリの画面201と広告アプリ画面202を示す。
ナビアプリ122は、GPS装置から自車位置を取得し、地図上に表示したり、目的地までのルートを探索し、誘導したりする機能を持つ。
広告アプリ123は、自車位置周辺の店舗の広告を表示する機能であり、自車位置の更新に従って広告の内容を自動的に変更する。
このとき、ナビアプリ122が表示する地図データはサーバ処理装置130の地図配信機能142から取得し、広告アプリ123が表示する広告データはサーバ処理装置130の広告配信機能143から取得する。
地図データは、地図を格子状に区切った単位で管理しており、地図データを取得する際は、例えば格子状で区切られた地図の左上の緯度と経度を地図配信機能142に送信することで実現する。
サーバ処理装置130のサーバ機能145にWebサーバを用いた場合、例えば以下のようなURLに対してリクエストを送出することで地図データを取得できるように構成する。
http://hsdlserver.com/map?lat=35.584653&lng=139.524095
上記の35.584653と139.524095は、格子の左上の緯度と経度の値である。mapは提供機能141を特定するために用い、この場合は地図配信機能142を利用することを表す。このURLにリクエストを送信するとサーバ機能145は地図配信機能142に緯度と経度を渡すと地図データを返す。
広告データは、地図データと同様に地図を格子状に区切った単位に存在する店舗を管理しており、広告データを取得する際は、例えば格子状で区切られた地図の左上の緯度と経度を広告配信機能143に送信することで実現する。
例えば以下のようなURLに対してリクエストを送出することで広告データを取得できるように構成する。
http://hsdlserver.com/adv?lat=35.584653&lng=139.524095
上記の35.584653と139.524095は、格子の左上の緯度と経度の値である。advは提供機能141を特定するために用い、この場合は広告配信機能143を利用することを表す。このURLにリクエストを送信するとサーバ機能145は広告配信機能143に緯度と経度を渡すと広告データを返す。
自車位置として緯度と経度ではなく、格子状の地図データ一つ一つにユニークに割り当てたメッシュコードを用いても良い。
昨今、携帯電話等の端末においてもiPhone(登録商標)やAndroid(登録商標)に代表されるように、ユーザが自由に端末にアプリをインストールして利用する形態が一般的になりつつある。本実施例におけるナビアプリ122、広告アプリ123も同様に、独自に開発され、ユーザが自由にインストールして利用することを想定している。
各々独自に開発されたものではあるが、ナビアプリ122と広告アプリ123はどちらも自車位置に応じてサーバ処理装置130と通信を行うため、近いタイミングで２つの通信が発生する。
近いタイミングで発生する２つの通信を一括化するために、予めクライアント処理装置110の通信グルーピングテーブル126に図3に示すようなデータを格納する。
通信グルーピングテーブル126のリクエストURL301にはアプリが呼び出したURLを格納し、関連リクエストURL302は同タイミングで発生する可能性が高いリクエストのURLを格納する。
通信グルーピングテーブル126は、ユーザ、カーナビ端末メーカ、アプリ開発者等によって作成する、又はアプリの組み合わせを考慮して自動的に作成することが考えられる。
図4にサーバ通信キャッシュ127を示す。リクエストURL401とそのリクエストを実施したときの処理結果402をサーバ通信キャッシュ127に格納する。<地図データ>及び<広告データ>の内容については言及しない。
図5にアプリの通信に関わる部分のシーケンス図を示す。
カーナビアプリは定期的に地図上の自車位置を更新する処理を繰り返す(512)。
更新処理では、まずGPS管理機能125に対して自車位置取得要求501を送信し、自車位置を取得する。
自車位置を表示するために必要な地図が足りない場合、カーナビアプリは地図配信機能142に対して地図データ取得要求502を出す。
サーバ通信仲介機能124が、地図データ取得要求502を検出すると、通信グルーピングテーブル126のデータに従って、リクエストURL301を関連リクエストURL302に変換し、両方のリクエストを１つにまとめて地図データ及び広告データ取得要求503としてクライアント通信仲介機能144に送信する。
クライアント通信仲介機能144は、地図データ及び広告データ取得要求503を分解し、地図配信機能142に地図データ取得要求504、広告配信機能143に広告データ取得要求505を各々送信し、地図データ及び広告データを取得する。地図データ及び広告データを取得したら１つにまとめて合成し(506)、サーバ通信仲介機能124に返す(507)。サーバ通信仲介機能124では、合成された地図データ及び広告データをそれぞれに分割し(508)、サーバ通信キャッシュ127に広告データ保存509を行い、地図データはカーナビアプリに返す(510)。
【０００９】
上記の処理により、クライアント処理装置110からサーバ処理装置130へのデータ取得のための２つのリクエストが１つにまとめられて送信され、２つのリクエストのそれぞれに対応した２つのデータが１つにまとめられてサーバ処理装置130からクライアント処理装置110に送信される。
ナビアプリ122は地図データを用い、地図描画511を実施する。
広告アプリ123は定期的に自車位置周辺の広告データを取得し広告を更新する(518)。
自車位置周辺の変化に応じて、GPS管理機能125に自車位置取得要求513を実施し、自車位置を取得する。
新たな広告データを取得する必要があるかどうかを判定し、必要があれば、サーバ通信仲介機能124及びクライアント通信仲介機能144を介して、広告配信機能143に対して広告データ取得要求514を実施する。
本シーケンスでは、サーバ通信仲介機能124が、広告データ取得要求514を検出したとき、既にサーバ通信キャッシュ127に広告データが存在していれば、サーバ処理装置130にリクエストを出力せず保存されている広告データを読み込み(515)、広告アプリ123に返す(516)。
広告アプリ123は広告データを描画する(517)。
クライアント処理装置110で動作するサーバ通信仲介機能124の詳細を説明する。
図6にクライアント処理装置110で動作するサーバ通信仲介機能124のフローチャートを示す。
アプリからサーバ処理装置へのリクエストを検出したら(601)、サーバ通信キャッシュ127に既にそのリクエストの処理結果が存在するかどうかを調べる(602)。
処理結果が存在するならば、保存されているリクエストの処理結果を返す(603)。この場合、すでに関連リクエストの処理結果も存在することが多いので、関連リクエストに対しては通常の処理を行う。処理結果が存在していないならば、リクエストURLが通信グルーピングテーブル126に存在するかどうかを調べる(604)。リクエストURLが存在していないならば、サーバ処理装置130へリクエストを送出する(606)。
リクエストURLが存在しているならば、通信グルーピングテーブル126の同時リクエストURLの処理結果が既にサーバ通信キャッシュ126に存在するかどうかを調べる(605)。  
このときの動作について図3を用いて説明する。
図3の最初のエントリーでは、mapへのリクエストが発生したときの関連リクエストURL302はadvのリクエストである。リクエストURL301に含まれる%1%及び%2%はアプリが設定した緯度及び経度である。関連リクエストURL302の%1%、%2%はアプリが設定した緯度及び経度と同じ値を利用できることを表す。リクエストと関連リクエストのそれぞれに含まれるパラメータの変数名を同じにすることにより、リクエストと関連リクエスト間のパラメータの関連性を定義できる。%1%、%2%を実際の値に置き換えることで、関連リクエストURL302を生成する。
この例では、URL各々に対してアプリが設定したパラメータをそのまま設定したが、何らかの計算により算出した結果をパラメータとして利用しても良い。その場合、グルーピングテーブル内にパラメータ間の関係を定義しておく。例えば、以下のように、２つのパラメータ%1%、%2%を用いて、リクエスト及び関連リクエストではそれぞれ異なった値が定義される。
リクエストURL:http://・・・?a=%1%&b=%2%    関連リクエストURL:http://・・・?ab=%1%+%2%
生成したURLに対応する処理結果が、サーバ通信キャッシュ126に存在するかどうかを調べる(605)。
キャッシュに生成したＵＲＬに対する処理結果が存在するならば、アプリのリクエストをそのままサーバ処理装置へ送出する(606)。  
サーバ処理装置は、サーバ機能145でリクエストを受け、リクエストされた提供機能141の処理を実行し、処理結果をサーバ通信仲介機能124に返す(607)。サーバ通信仲介機能124は、リクエストの結果をアプリに返す(608)。
関連リクエストURLのリクエストの処理結果が存在しないならば(605)、関連リクエストURLをクライアント仲介機能144のURLに変換する(609)。これは例えば以下のように変換する。
http://hsdlserver.com/proxy?s1=<リクエストURL>&s2=<関連リクエストURL>
このとき、<リクエストURL>及び<関連リクエストURL>は、リクエストのパラメータにパラメータとして利用できない文字も利用可能とするためにエンコード済みのURLを用いる。
クライアント仲介機能144のURLに変換したらサーバ処理装置へリクエストを送出する(610)。
サーバ処理装置130のサーバ機能145でリクエストを受信すると、クライアント通信仲介機能の処理611を呼び出し、処理結果を返す。
サーバ通信仲介機能124が処理の結果を受け取ると、その処理結果を各提供機能の結果毎に分割する(612)。
次に、関連リクエストURLの処理結果をサーバ通信キャッシュに保存し(613)、アプリが出力したリクエストの処理結果をアプリに返す(614)。
サーバ処理装置130で処理中に、クライアント処理装置110で関連リクエストURLのリクエストが発生したときのために、サーバ処理装置130へリクエストを送出610した後に、リクエスト中のURLをクライアント処理装置110内に記録しておき、
関連リクエストURLへのリクエストが発生したらリクエスト中URLを参照し、
リクエスト中URLに関連リクエストが存在していればサーバ処理装置130にリクエストを出さずにリクエスト中のＵＲＬに含まれている関連リクエストの処理結果が返るのを待つ方法が考えられる。
図7にサーバ処理装置130で動作するクライアント通信仲介機能144のフローチャートを示す。
リクエストを受信をすると(701)、合成したリクエストに含まれるリクエスト一覧を取得する(702)。
リクエスト先の提供機能を呼び出し(703)、提供機能の処理を実行し(704)、提供機能の処理結果を取得する(705)。
リクエスト一覧全てについて処理したかを確認し(706)、処理していなければ次の提供機能を呼び出す(703)。
全てについて処理したならば、提供機能の処理結果を合成する(707)。合成の方法として、例えばZIPによる圧縮を行う方法が考えられる。
合成した処理結果をクライアント処理装置に返す(708)。
クライアント処理装置110のサーバ通信仲介機能124が処理結果を受け取ると、結果を分割するステップ612以降を実施する。
本実施例では、GPS管理機能125からの自車位置取得(501、513)を契機にして、アプリ間が連携する様子を例に説明したが、ユーザの画面の操作や、特定のアプリが別のアプリの機能を呼び出す等、直接やり取りしたタイミングを契機にして、処理を実施することも考えられる。
以上により、従来各アプリ121が独立して実施していたクライアント処理装置110からサーバ処理装置130へのデータの送受信処理の回数を減らすことができ、通信にかかる負荷を軽減することが可能となる。
（実施例２）
実施例1では、各提供機能141が一つのサーバ処理装置130で稼動する場合の例を示した。実施例2では、各提供機能141及び通信仲介機能144が各々一つのサーバ処理装置130-1〜130-3で稼動する場合の例を示す。
図8にシステム構成を示す。
地図配信機能142及び広告配信機能143を、それぞれサーバ処理装置:地図配信130-2及びサーバ処理装置:広告配信130-3に配置する。
クライアント通信仲介機能144は、サーバ処理装置:仲介130-1に配置する。
本構成では、通信グルーピングテーブル126に格納するリクエストURL301及び関連リクエストURL302はそれぞれ別のサーバ通信処理装置130のURLとなる。
これにより、図5のサーバ処理装置のクライアント通信仲介機能144、地図配信機能142、広告配信機能143は各々別のサーバ処理装置130で稼動する。
図7の提供機能呼び出し703は、それぞれ別サーバ処理装置130へのリクエストとなり、提供機能141の処理は別サーバ処理装置130で稼動する処理となる。
処理の流れは実施例1と同様である。但し、クライアント処理装置110からサーバ処理装置130-1へのリクエストＵＲＬ（地図配信機能）及び関連リクエストＵＲＬ（広告配信機能）の送出は、一括して行われる。それぞれの処理結果の送出も、一括してサーバ処理装置130-1からクライアント処理装置110に送出される。
クライアント処理装置110からサーバ処理装置:仲介130-1までの通信速度が遅く、サーバ処理装置:仲介130-1とサーバ処理装置:地図配信130-2及び、サーバ処理装置:仲介130-1とサーバ処理装置:広告配信130-3の間の通信速度が速い場合や、クライアント処理装置110に比べてサーバ処理装置:仲介130-1の処理速度が速い場合に有効である。このような場合でも、上記のように、リクエストＵＲＬと関連リクエストＵＲＬがクライアント処理装置110からサーバ処理装置130-1へ一括して送出され、かつ、それぞれのリクエストに対する処理結果も同様に、サーバ処理装置130-1からクライアント処理装置110に一括して送出されるため、リクエストや処理結果の送出の時間が短縮される。
（実施例３）
実施例1において、通信グルーピングテーブル126を自動生成する実施例を示す。
図1のクライアント処理装置110のメモリ120に新たに通信グルーピングテーブル更新機能を配置する。
図6のサーバ通信仲介機能124のフローチャートのサーバ処理装置130へリクエストを送出する処理の後に、リクエストURLと、リクエスト送出時刻をログに記録する処理を追加する。
通信グルーピングテーブル更新機能は、収集したログの解析を行い、近いタイミングで発生することが多い２つのリクエストを見つけ、それら２つのリクエストの間に関連性があれば通信グルーピングテーブル126にリクエストURL301及び関連リクエストURL302を登録する。通信グルーピングテーブル更新処理のフローチャートを図9に示す。
まずログから特定時間内に発生したリクエスト群を収集する901。例えば、特定のログの時刻と時刻の差が5秒以内のログを集め、一つのリクエスト群とする。
次に、一つのリクエスト群に含まれるリクエスト同士を比較し、リクエスト間のパラメータの関連性を抽出する(902)。例えば、以下の二つのリクエストが特定時間内に発生した場合、パラメータを比較すると、lat及びlng（緯度及び経度）に設定している値が同一であるため、関連性があると言える。
http://mapserver.com/getmap?lat=35.584653&lng=139.524095
http://advserver.com/getadv?lat=35.584653&lng=139.524095
リクエストに含まれるパラメータに基づいて、関連性を抽出できたなら(903)、関連性のあったリクエストの組み合わせをカウントする(904)。例えば、上記の二つのURLの場合、http://mapserver.com/getmapとhttp://advserver.com/getadvの組み合わせに対して関連があった回数に1を足す。
逆に関連性が抽出できなかったなら、関連性のなかったリクエストの組み合わせをカウントする(905)。
全てのリクエスト群について処理したかを確認し(906)、処理していなければステップ902から繰り返す。
全てのリクエスト群について処理したならば、関連性の高いリクエストの組み合わせを通信グルーピングテーブルに登録する(907)。関連性の高さの判定方法として、例えば、特定のリクエストの組み合わせについて関連性はあったが、関連性のなかった回数がゼロだった場合、あるいは、特定のリクエストの組み合わせについて関連性のあった回数が、関連性のあった回数と関連性のなかった回数の合計に対して50%以上であった場合、関連性があると判断する、等が考えられる。
関連性の高いリクエストの組み合わせを通信グルーピングテーブルに登録するとき、URLに含まれるパラメータの値は%1%、%2%のように変数化する。
関連性の高いリクエストの組み合わせを全て、リクエストの発生した順序を考慮してリクエスト及びその関連リクエストとして、通信グルーピングテーブルに登録し終えたら、終了する(908)。
この処理を定期的に実施することで、通信グルーピングテーブル126の内容を複数のアプリ121の組み合わせの特性に合わせて更新できる。
（実施例４）
最初にユーザによって入力されたリクエストに関連する関連リクエストが複数ある場合を説明する。例えば、入力されたリクエストＡに関連するリクエストＢ又はＣのいずれかがユーザによって選択される場合、あるいは、入力されたリクエストＡの後に関連するリクエストＢ、続けてリクエストＣが選択される場合などがある。
入力されたリクエストに関連する関連リクエストが複数ある場合に、複数のリクエストを合成して送信したり、合成された処理結果を受け取ったりするための送受信制御テーブルを図１０に示す。図１０では、入力されたリクエストに対してｎ個の関連リクエストがある場合を示す。図１０は、関連リクエストがない場合でも適用できる。図１０の送受信制御テーブルには、リクエスト、複数の関連リクエストのそれぞれについて、サーバ通信キャッシュ127内に処理結果が存在するかどうかを示すフラグＸ、及びサーバ処理装置130にリクエストを送信するかどうかを示すフラグＹ（Ｙ＝１−ｘ）が設けられている。フラグＹの定義から明らかなように、フラグＹは実質的にフラグＸと等価である、即ち、フラグＸの値に連動してフラグＹの値が決まる。
【００１０】
図３に示した通信グルーピングテーブル126を、複数の関連リクエストがある場合に拡張したものを図１１に示す。図１１に示すテーブルには、実施例３で示したように、通信のログに基づいて予めリクエスト間の関連が定義されているものとする。
【００１１】
関連するリクエストが複数ある場合のクライアント処理装置110における処理手順を以下に示す。以下に示す手順は、関連リクエストがない、リクエスト単体の場合でもそのまま適用できる。
（１）クライアント処理装置110でリクエストが発生したら、図１１に示す通信グルーピングテーブルを参照して、図１０の送受信制御テーブルに入力リクエスト及び関連リクエストのＵＲＬを設定する。
（２）サーバ通信キャッシュ127内に処理結果が存在するかどうかを調べて、図１０のテーブルのフラグＸに、処理結果の存在の有無に応じて１（有）又は０（無）を設定する。
（３）図１０のテーブルのリクエスト送信の要否のフラグＹに、フラグＸの補数の値を設定する。即ち、フラグＸが０ならば、フラグＹに１を設定し、フラグＸが１ならば、フラグＹに０を設定する。（サーバ通信キャッシュ127内に処理結果が存在すれば、サーバ処理装置130にリクエストを送信せず、処理結果が存在すれば、リクエストを送信する。）
（４）図１０のフラグＸが１であるリクエストのそれぞれに対応した処理結果をサーバ通信キャッシュ127から取り出して、それぞれのアプリに返す。
（５）図１０のフラグＹが１であるリクエストを合成して１つのリクエストにまとめてサーバ処理装置130に送信し、サーバ処理装置130から合成された処理結果をまとめて受け取ったら分割してサーバ通信キャッシュに保存する。
【符号の説明】
【００１２】
100  ネットワーク
110  クライアント処理装置
111  クライアント処理装置の通信部
112  クライアント処理装置のCPU
113  クライアント処理装置の表示部
114  クライアント処理装置のGPS
115  クライアント処理装置の入力部
120  クライアント処理装置のメモリ
121  アプリ群
122  ナビアプリ
123  広告アプリ
124  サーバ通信仲介機能
125 GPS管理機能
126  通信グルーピングテーブル
127  サーバ通信キャッシュ
130  サーバ処理装置
131  サーバ処理装置の通信部
132  サーバ処理装置のCPU
133  サーバ処理装置の表示部
134  サーバ処理装置のHDD
135  サーバ処理装置の入力部
140  サーバ処理装置のメモリ
141  提供機能群
142  地図配信機能
143  広告配信機能
144  クライアント通信仲介機能
145  サーバ機能
【図１】
2012064128.tif 000003
【図２】
2012064128.tif 000004
【図３】
2012064128.tif 000005
【図４】
2012064128.tif 000006
【図５】
2012064128.tif 000007
【図６】
2012064128.tif 000008
【図７】
2012064128.tif 000009
【図８】
2012064128.tif 000010
【図９】
2012064128.tif 000011
【図１０】
2012064128.tif 000012
【図１１】
2012064128.tif 000013
【手続補正書】
【提出日】平成23年8月19日(2011.8.19)
【手続補正１】
【補正対象書類名】図面
【補正対象項目名】図１
【補正方法】変更
【補正の内容】
【図１】
2012064128.tif 000014
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図３
【補正方法】変更
【補正の内容】
【図３】
2012064128.tif 000015
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図６
【補正方法】変更
【補正の内容】
【図６】
2012064128.tif 000016
【手続補正４】
【補正対象書類名】図面
【補正対象項目名】図７
【補正方法】変更
【補正の内容】
【図７】
2012064128.tif 000017
【手続補正５】
【補正対象書類名】図面
【補正対象項目名】図８
【補正方法】変更
【補正の内容】
【図８】
2012064128.tif 000018
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
携帯電話やカーナビ、PCのようなクライアント処理装置(コンピュータ)で動作する複数の
プログラムと、クライアント処理装置とネットワークで接続したサーバ処理装置(コンピ
ュータ)で動作するサーバプログラムの通信方法に関する。
【背景技術】
【０００２】
Android端末では、ユーザが自分でインターネット上に存在するマーケットからアプリを
自由にインストールできる。インストールしたアプリは各々必要に応じて独立してネット
ワークを介してサーバと通信を行う。
【０００３】
特開2009-157648は、クライアント処理装置で稼動する複数のウィジェットと呼ぶプログ
ラムが各々サーバと通信するとき、ウィジェットが出力するサーバに対するリクエストを
、クライアント端末に配したバッファに保存しておき、バッファが一杯になる、又はバッ
ファ期間が満了するタイミングでバッファに溜まったリクエストをサーバに向かって一括
送信し、サーバから応答データを受信すると、受信データを解析し、リクエストしたウィ
ジェットを特定して、個々のウィジェットに返すことにより、
ネットワーク通信の発生回数を抑制することができ、通信トラフィックの増大を防ぐこと
を可能とする方法を開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開2009-157648号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Android端末で、Androidマーケットから取得するようなアプリでは、個別に取得したアプ
リ同士が連携して動作することが可能である。
【０００６】
しかし、アプリとサーバとの通信はアプリ毎に独立に実施されているため、多くのデータ
の送受信が発生すると、送受信処理の負荷により性能が悪化することがあった。
【０００７】
特開2009-157648を用いると、リクエストを一時的にバッファに保存し、バッファが一杯
になる又はバッファ期間が満了するまでリクエストが送出されないため、通信量を削減す
ることが可能となるが、アプリがリクエストしたときにすぐにリクエストが発生しないこ
とがあるため、レスポンス受信が遅くなることがあると考えられる。
【０００８】
本発明の目的は、通信回数を削減することでウィジェットのような複数の独立したプログ
ラムが動作するクライアント装置の処理性能を向上すること。特にユーザ操作に対するレ
スポンスを向上すること。
【課題を解決するための手段】
【０００９】
クライアント処理装置で動作する第一のアプリと第一のアプリに関連する第二のアプリが
同時に動作しているとき、
第一のアプリがサーバ処理装置に第一のリクエストを送信するタイミングで、第二のアプ
リがサーバ処理装置に第二のリクエストを送信することが多い場合、
第一のリクエストと第一のリクエストに関連する第二のリクエストとの対応関係をクライ
アント処理装置の通信グルーピングテーブルに格納しておく。
【００１０】
クライアント処理装置内のサーバ通信仲介機能はアプリからサーバ処理装置に向けて発生
する全てのリクエストを仲介する。
【００１１】
サーバ通信仲介機能が第一のリクエストを検出すると、第一のリクエストと同種のリクエ
ストを通信グルーピングテーブルから検索し、第一のリクエストの記述があれば、第二の
リクエストを生成し、第一及び第二のリクエストを合成してサーバ処理装置に送信する。
サーバ処理装置が合成したリクエストを受けると、第一のリクエストと第二のリクエスト
に対する処理を各々実施し、双方の処理結果を合成してクライアント処理装置に返す。
【００１２】
サーバ通信仲介機能が処理結果を受け取ると、処理結果を分解し、第一のリクエストに対
応する処理結果を第一のアプリに返し、その他の処理結果はサーバ通信キャッシュに保存
する。
【００１３】
第二のアプリが送信した第二のリクエストをサーバ通信仲介機能が検出すると、そのリク
エストに対応する処理結果がサーバ通信キャッシュに存在するかどうかを調べ、サーバ通
信キャッシュにあればその処理結果を第二のアプリに返す。
【発明の効果】
【００１４】
クライアント処理装置で稼働中のアプリが各々独立して実施していた通信を、一括して実
施することでアプリの性能向上を実現する。
【図面の簡単な説明】
【００１５】
【図１】実施例１の構成図を示す。
【図２】カーナビ上のアプリの動作例を示す。
【図３】通信グルーピングテーブルを示す。
【図４】サーバ通信キャッシュを示す。
【図５】通信に関連がある部分のシーケンス図を示す。
【図６】サーバ通信仲介機能のフローチャートを示す。
【図７】クライアント通信仲介機能のフローチャートを示す。
【図８】実施例２の構成図を示す。
【図９】通信グルーピングテーブル更新機能のフローチャートを示す。
【図１０】送受信制御テーブル。
【図１１】関連リクエストが複数の場合の通信グルーピングテーブル。
【発明を実施するための形態】
【００１６】
（実施例１）
図1に実施例1におけるシステムの構成図を示す。
【００１７】
本実施例では、クライアント処理装置110にカーナビ端末を用い、サーバ処理装置130とネ
ットワーク100を介して通信して処理を実施するように構成する。
【００１８】
各処理装置(110、130)は、CPU(112、132)、入力部(115、135)、表示部(113、133)、通信
部(111、131)、メモリ(120、140)等を持つコンピュータである。
【００１９】
CPU(112、132)はプログラムやデータをメモリ(120、140)に読み込み、プログラムに従い
処理を行う。表示部はプログラムをCPU(112、132)の処理結果をユーザに示し、入力部(11
5、135)はユーザからの入力を受け付ける。通信部(111、131)は、ネットワーク100を介し
て別の処理装置とデータのやり取りを実施する。さらにクライアント処理装置110には自
車位置を取得するためにGPS114がある。
【００２０】
クライアント処理装置110のメモリ120には、プログラムであるサーバ通信仲介機能124、GPS管理機能125、アプリ群121及び、データである通信グルーピングテーブル126、サーバ通信キャッシュ127がある。
【００２１】
サーバ処理装置130のメモリ140には、プログラムであるクライアント通信仲介機能144、
サーバ機能145、提供機能群141がある。
【００２２】
クライアント処理装置110のアプリ121はサーバ処理装置130と通信して処理を行う。
本実施例では、ナビアプリ122と広告アプリ123の二つのアプリを例に説明する。
【００２３】
図2に、クライアント処理装置であるカーナビ上で動作するアプリの動作例として、ナビ
アプリの画面201と広告アプリ画面202を示す。
【００２４】
ナビアプリ122は、GPS装置から自車位置を取得し、地図上に表示したり、目的地までのルートを探索し、誘導したりする機能を持つ。
【００２５】
広告アプリ123は、自車位置周辺の店舗の広告を表示する機能であり、自車位置の更新に
従って広告の内容を自動的に変更する。
【００２６】
このとき、ナビアプリ122が表示する地図データはサーバ処理装置130の地図配信機能142
から取得し、広告アプリ123が表示する広告データはサーバ処理装置130の広告配信機能143から取得する。
【００２７】
地図データは、地図を格子状に区切った単位で管理しており、地図データを取得する際は
、例えば格子状で区切られた地図の左上の緯度と経度を地図配信機能142に送信すること
で実現する。
【００２８】
サーバ処理装置130のサーバ機能145にWebサーバを用いた場合、例えば以下のようなURLに対してリクエストを送出することで地図データを取得できるように構成する。
【００２９】
http://hsdlserver.com/map?lat=35.584653&lng=139.524095
上記の35.584653と139.524095は、格子の左上の緯度と経度の値である。mapは提供機能141を特定するために用い、この場合は地図配信機能142を利用することを表す。このURLにリクエストを送信するとサーバ機能145は地図配信機能142に緯度と経度を渡すと地図データを返す。
【００３０】
広告データは、地図データと同様に地図を格子状に区切った単位に存在する店舗を管理し
ており、広告データを取得する際は、例えば格子状で区切られた地図の左上の緯度と経度
を広告配信機能143に送信することで実現する。
【００３１】
例えば以下のようなURLに対してリクエストを送出することで広告データを取得できるよ
うに構成する。
【００３２】
http://hsdlserver.com/adv?lat=35.584653&lng=139.524095
上記の35.584653と139.524095は、格子の左上の緯度と経度の値である。advは提供機能141を特定するために用い、この場合は広告配信機能143を利用することを表す。このURLにリクエストを送信するとサーバ機能145は広告配信機能143に緯度と経度を渡すと広告データを返す。
【００３３】
自車位置として緯度と経度ではなく、格子状の地図データ一つ一つにユニークに割り当て
たメッシュコードを用いても良い。
【００３４】
昨今、携帯電話等の端末においてもiPhone(登録商標)やAndroid(登録商標)に代表される
ように、ユーザが自由に端末にアプリをインストールして利用する形態が一般的になりつ
つある。本実施例におけるナビアプリ122、広告アプリ123も同様に、独自に開発されユ
ーザが自由にインストールして利用することを想定している。
【００３５】
各々独自に開発されたものではあるが、ナビアプリ122と広告アプリ123はどちらも自車位置に応じてサーバ処理装置130と通信を行うため、近いタイミングで２つの通信が発生する。
【００３６】
近いタイミングで発生する２つの通信を一括化するために、予めクライアント処理装置11
0の通信グルーピングテーブル126に図3に示すようなデータを格納する。
通信グルーピングテーブル126のリクエストURL301にはアプリが呼び出したURLを格納し、
関連リクエストURL302は同タイミングで発生する可能性が高いリクエストのURLを格納す
る。
【００３７】
通信グルーピングテーブル126は、ユーザ、カーナビ端末メーカ、アプリ開発者等によっ
て作成する、又はアプリの組み合わせを考慮して自動的に作成することが考えられる。
【００３８】
図4にサーバ通信キャッシュ127を示す。リクエストURL401とそのリクエストを実施したときの処理結果402をサーバ通信キャッシュ127に格納する。<地図データ>及び<広告データ>の内容については言及しない。
【００３９】
図5にアプリの通信に関わる部分のシーケンス図を示す。
【００４０】
カーナビアプリは定期的に地図上の自車位置を更新する処理を繰り返す(512)。
【００４１】
更新処理では、まずGPS管理機能125に対して自車位置取得要求501を送信し、自車位置を取得する。
【００４２】
自車位置を表示するために必要な地図が足りない場合、カーナビアプリは地図配信機能14
2に対して地図データ取得要求502を出す。
【００４３】
サーバ通信仲介機能124が、地図データ取得要求502を検出すると、通信グルーピングテーブル126のデータに従って、リクエストURL301を関連リクエストURL302に変換し、両方のリクエストを１つにまとめて地図データ及び広告データ取得要求503としてクライアント通信仲介機能144に送信する。
【００４４】
クライアント通信仲介機能144は、地図データ及び広告データ取得要求503を分解し、地図配信機能142に地図データ取得要求504、広告配信機能143に広告データ取得要求505を各々送信し、地図データ及び広告データを取得する。地図データ及び広告データを取得したら１つにまとめて合成し(506)、サーバ通信仲介機能124に返す(507)。サーバ通信仲介機能124では、合成された地図データ及び広告データをそれぞれに分割し(508)、サーバ通信キャッシュ127に広告データ保存509を行い、地図データはカーナビアプリに返す(510)。
【００４５】
上記の処理により、クライアント処理装置110からサーバ処理装置130へのデータ取得のための２つのリクエストが１つにまとめられて送信され、２つのリクエストのそれぞれに対応した２つのデータが１つにまとめられてサーバ処理装置130からクライアント処理装置110に送信される。
【００４６】
ナビアプリ122は地図データを用い、地図描画511を実施する。
【００４７】
広告アプリ123は定期的に自車位置周辺の広告データを取得し広告を更新する(518)。
【００４８】
自車位置周辺の変化に応じて、GPS管理機能125に自車位置取得要求513を実施し、自車位置を取得する。
【００４９】
新たな広告データを取得する必要があるかどうかを判定し、必要があれば、サーバ通信仲
介機能124及びクライアント通信仲介機能144を介して、広告配信機能143に対して広告データ取得要求514を実施する。
【００５０】
本シーケンスでは、サーバ通信仲介機能124が、広告データ取得要求514を検出したとき、
既にサーバ通信キャッシュ127に広告データが存在していれば、サーバ処理装置130にリクエストを出力せず保存されている広告データを読み込み(515)、広告アプリ123に返す(516)。
【００５１】
広告アプリ123は広告データを描画する(517)。
【００５２】
クライアント処理装置110で動作するサーバ通信仲介機能124の詳細を説明する。
【００５３】
図6にクライアント処理装置110で動作するサーバ通信仲介機能124のフローチャートを示す。
【００５４】
アプリからサーバ処理装置へのリクエストを検出したら(601)、サーバ通信キャッシュ127
に既にそのリクエストの処理結果が存在するかどうかを調べる(602)。
【００５５】
処理結果が存在するならば、保存されているリクエストの処理結果を返す(603)。この場
合、すでに関連リクエストの処理結果も存在することが多いので、関連リクエストに対し
ては通常の処理を行う。処理結果が存在していないならば、リクエストURLが通信グルー
ピングテーブル126に存在するかどうかを調べる(604)。リクエストURLが存在していない
ならば、サーバ処理装置130へリクエストを送出する(606)。
【００５６】
リクエストURLが存在しているならば、通信グルーピングテーブル126の同時リクエストURLの処理結果が既にサーバ通信キャッシュ126に存在するかどうかを調べる(605)。  
【００５７】
このときの動作について図3を用いて説明する。
【００５８】
図3の最初のエントリーでは、mapへのリクエストが発生したときの関連リクエストURL302
はadvのリクエストである。リクエストURL301に含まれる%1%及び%2%はアプリが設定した
緯度及び経度である。関連リクエストURL302の%1%、%2%はアプリが設定した緯度及び経度
と同じ値を利用できることを表す。リクエストと関連リクエストのそれぞれに含まれるパ
ラメータの変数名を同じにすることにより、リクエストと関連リクエスト間のパラメータ
の関連性を定義できる。%1%、%2%を実際の値に置き換えることで、関連リクエストURL302
を生成する。
【００５９】
この例では、URL各々に対してアプリが設定したパラメータをそのまま設定したが、何ら
かの計算により算出した結果をパラメータとして利用しても良い。その場合、グルーピン
グテーブル内にパラメータ間の関係を定義しておく。例えば、以下のように、２つのパラ
メータ%1%、%2%を用いて、リクエスト及び関連リクエストではそれぞれ異なった値が定義
される。
【００６０】
リクエストURL:http://・・・?a=%1%&b=%2%    関連リクエストURL:http://・・・?ab=%1
%+%2%生成したURLに対応する処理結果が、サーバ通信キャッシュ126に存在するかどうかを調べる(605)。
【００６１】
キャッシュに生成したＵＲＬに対する処理結果が存在するならば、アプリのリクエストを
そのままサーバ処理装置へ送出する(606)。  
【００６２】
サーバ処理装置は、サーバ機能145でリクエストを受け、リクエストされた提供機能141の処理を実行し、処理結果をサーバ通信仲介機能124に返す(607)。サーバ通信仲介機能124は、リクエストの結果をアプリに返す(608)。
【００６３】
関連リクエストURLのリクエストの処理結果が存在しないならば(605)、関連リクエストURLをクライアント仲介機能144のURLに変換する(609)。これは例えば以下のように変換する。
【００６４】
http://hsdlserver.com/proxy?s1=<リクエストURL>&s2=<関連リクエストURL>
このとき、<リクエストURL>及び<関連リクエストURL>は、リクエストのパラメータにパラ
メータとして利用できない文字も利用可能とするためにエンコード済みのURLを用いる。
クライアント仲介機能144のURLに変換したらサーバ処理装置へリクエストを送出する(610)。
【００６５】
サーバ処理装置130のサーバ機能145でリクエストを受信すると、クライアント通信仲介機能の処理611を呼び出し、処理結果を返す。
【００６６】
サーバ通信仲介機能124が処理の結果を受け取ると、その処理結果を各提供機能の結果毎
に分割する(612)。
【００６７】
次に、関連リクエストURLの処理結果をサーバ通信キャッシュに保存し(613)、アプリが出
力したリクエストの処理結果をアプリに返す(614)。
【００６８】
サーバ処理装置130で処理中に、クライアント処理装置110で関連リクエストURLのリクエストが発生したときのために、サーバ処理装置130へリクエストを送出610した後に、リクエスト中のURLをクライアント処理装置110内に記録しておき、
関連リクエストURLへのリクエストが発生したらリクエスト中URLを参照し、
リクエスト中URLに関連リクエストが存在していればサーバ処理装置130にリクエストを出さずにリクエスト中のＵＲＬに含まれている関連リクエストの処理結果が返るのを待つ方法が考えられる。
【００６９】
図7にサーバ処理装置130で動作するクライアント通信仲介機能144のフローチャートを示す。
【００７０】
リクエストを受信をすると(701)、合成したリクエストに含まれるリクエスト一覧を取得
する(702)。
【００７１】
リクエスト先の提供機能を呼び出し(703)、提供機能の処理を実行し(704)、提供機能の処
理結果を取得する(705)。
【００７２】
リクエスト一覧全てについて処理したかを確認し(706)、処理していなければ次の提供機
能を呼び出す(703)。
【００７３】
全てについて処理したならば、提供機能の処理結果を合成する(707)。合成の方法として
、例えばZIPによる圧縮を行う方法が考えられる。
【００７４】
合成した処理結果をクライアント処理装置に返す(708)。
【００７５】
クライアント処理装置110のサーバ通信仲介機能124が処理結果を受け取ると、結果を分割するステップ612以降を実施する。
【００７６】
本実施例では、GPS管理機能125からの自車位置取得(501、513)を契機にして、アプリ間が連携する様子を例に説明したが、ユーザの画面の操作や、特定のアプリが別のアプリの機能を呼び出す等、直接やり取りしたタイミングを契機にして、処理を実施することも考えられる。
【００７７】
以上により、従来各アプリ121が独立して実施していたクライアント処理装置110からサーバ処理装置130へのデータの送受信処理の回数を減らすことができ、通信にかかる負荷を軽減することが可能となる。
【００７８】
（実施例２）
実施例1では、各提供機能141が一つのサーバ処理装置130で稼動する場合の例を示した。
実施例2では、各提供機能141及び通信仲介機能144が各々一つのサーバ処理装置130-1〜130-3で稼動する場合の例を示す。
【００７９】
図8にシステム構成を示す。
【００８０】
地図配信機能142及び広告配信機能143を、それぞれサーバ処理装置:地図配信130-2及びサーバ処理装置:広告配信130-3に配置する。
【００８１】
クライアント通信仲介機能144は、サーバ処理装置:仲介130-1に配置する。
【００８２】
本構成では、通信グルーピングテーブル126に格納するリクエストURL301及び関連リクエ
ストURL302はそれぞれ別のサーバ通信処理装置130のURLとなる。
【００８３】
これにより、図5のサーバ処理装置のクライアント通信仲介機能144、地図配信機能142、
広告配信機能143は各々別のサーバ処理装置130で稼動する。
【００８４】
図7の提供機能呼び出し703は、それぞれ別サーバ処理装置130へのリクエストとなり、提供機能141の処理は別サーバ処理装置130で稼動する処理となる。
【００８５】
処理の流れは実施例1と同様である。但し、クライアント処理装置110からサーバ処理装置130-1へのリクエストＵＲＬ（地図配信機能）及び関連リクエストＵＲＬ（広告配信機能）の送出は、一括して行われる。それぞれの処理結果の送出も、一括してサーバ処理装置130-1からクライアント処理装置110に送出される。
【００８６】
クライアント処理装置110からサーバ処理装置:仲介130-1までの通信速度が遅く、サーバ
処理装置:仲介130-1とサーバ処理装置:地図配信130-2及び、サーバ処理装置:仲介130-1とサーバ処理装置:広告配信130-3の間の通信速度が速い場合や、クライアント処理装置110に比べてサーバ処理装置:仲介130-1の処理速度が速い場合に有効である。このような場合でも、上記のように、リクエストＵＲＬと関連リクエストＵＲＬがクライアント処理装置110からサーバ処理装置130-1へ一括して送出され、かつ、それぞれのリクエストに対する処理結果も同様に、サーバ処理装置130-1からクライアント処理装置110に一括して送出されるため、リクエストや処理結果の送出の時間が短縮される。
【００８７】
（実施例３）
実施例1において、通信グルーピングテーブル126を自動生成する実施例を示す。
【００８８】
図1のクライアント処理装置110のメモリ120に新たに通信グルーピングテーブル更新機能を配置する。
【００８９】
図6のサーバ通信仲介機能124のフローチャートのサーバ処理装置130へリクエストを送出する処理の後に、リクエストURLと、リクエスト送出時刻をログに記録する処理を追加する。
【００９０】
通信グルーピングテーブル更新機能は、収集したログの解析を行い、近いタイミングで発
生することが多い２つのリクエストを見つけ、それら２つのリクエストの間に関連性があ
れば通信グルーピングテーブル126にリクエストURL301及び関連リクエストURL302を登録する。通信グルーピングテーブル更新処理のフローチャートを図9に示す。
【００９１】
まずログから特定時間内に発生したリクエスト群を収集する901。例えば、特定のログの
時刻と時刻の差が5秒以内のログを集め、一つのリクエスト群とする。
【００９２】
次に、一つのリクエスト群に含まれるリクエスト同士を比較し、リクエスト間のパラメー
タの関連性を抽出する(902)。例えば、以下の二つのリクエストが特定時間内に発生した
場合、パラメータを比較すると、lat及びlng（緯度及び経度）に設定している値が同一で
あるため、関連性があると言える。
【００９３】
http://mapserver.com/getmap?lat=35.584653&lng=139.524095
http://advserver.com/getadv?lat=35.584653&lng=139.524095
【００９４】
リクエストに含まれるパラメータに基づいて、関連性を抽出できたなら(903)、関連性の
あったリクエストの組み合わせをカウントする(904)。例えば、上記の二つのURLの場合、
http://mapserver.com/getmapとhttp://advserver.com/getadvの組み合わせに対して関連があった回数に1を足す。
【００９５】
逆に関連性が抽出できなかったなら、関連性のなかったリクエストの組み合わせをカウン
トする(905)。
【００９６】
全てのリクエスト群について処理したかを確認し(906)、処理していなければステップ902
から繰り返す。
【００９７】
全てのリクエスト群について処理したならば、関連性の高いリクエストの組み合わせを通
信グルーピングテーブルに登録する(907)。関連性の高さの判定方法として、例えば、特
定のリクエストの組み合わせについて関連性はあったが、関連性のなかった回数がゼロだ
った場合、あるいは、特定のリクエストの組み合わせについて関連性のあった回数が、関
連性のあった回数と関連性のなかった回数の合計に対して50%以上であった場合、関連性
があると判断する、等が考えられる。
【００９８】
関連性の高いリクエストの組み合わせを通信グルーピングテーブルに登録するとき、URL
に含まれるパラメータの値は%1%、%2%のように変数化する。
【００９９】
関連性の高いリクエストの組み合わせを全て、リクエストの発生した順序を考慮してリク
エスト及びその関連リクエストとして、通信グルーピングテーブルに登録し終えたら、終
了する(908)。
【０１００】
この処理を定期的に実施することで、通信グルーピングテーブル126の内容を複数のアプ
リ121の組み合わせの特性に合わせて更新できる。
【０１０１】
（実施例４）
最初にユーザによって入力されたリクエストに関連する関連リクエストが複数ある場
合を説明する。例えば、入力されたリクエストＡに関連するリクエストＢ又はＣのいずれ
かがユーザによって選択される場合、あるいは、入力されたリクエストＡの後に関連する
リクエストＢ、続けてリクエストＣが選択される場合などがある。
【０１０２】
入力されたリクエストに関連する関連リクエストが複数ある場合に、複数のリクエストを
合成して送信したり、合成された処理結果を受け取ったりするための送受信制御テーブル
を図１０に示す。図１０では、入力されたリクエストに対してｎ個の関連リクエストがあ
る場合を示す。図１０は、関連リクエストがない場合でも適用できる。図１０の送受信制
御テーブルには、リクエスト、複数の関連リクエストのそれぞれについて、サーバ通信キ
ャッシュ127内に処理結果が存在するかどうかを示すフラグＸ、及びサーバ処理装置130にリクエストを送信するかどうかを示すフラグＹ（Ｙ＝１−ｘ）が設けられている。フラグＹの定義から明らかなように、フラグＹは実質的にフラグＸと等価である、即ち、フラグＸの値に連動してフラグＹの値が決まる。
【０１０３】
図３に示した通信グルーピングテーブル126を、複数の関連リクエストがある場合に
拡張したものを図１１に示す。図１１に示すテーブルには、実施例３で示したように、通
信のログに基づいて予めリクエスト間の関連が定義されているものとする。
【０１０４】
関連するリクエストが複数ある場合のクライアント処理装置110における処理手順を
以下に示す。以下に示す手順は、関連リクエストがない、リクエスト単体の場合でもその
まま適用できる。
【０１０５】
（１）クライアント処理装置110でリクエストが発生したら、図１１に示す通信グルーピ
ングテーブルを参照して、図１０の送受信制御テーブルに入力リクエスト及び関連リクエ
ストのＵＲＬを設定する。
【０１０６】
（２）サーバ通信キャッシュ127内に処理結果が存在するかどうかを調べて、図１０のテ
ーブルのフラグＸに、処理結果の存在の有無に応じて１（有）又は０（無）を設定する。
【０１０７】
（３）図１０のテーブルのリクエスト送信の要否のフラグＹに、フラグＸの補数の値を設
定する。即ち、フラグＸが０ならば、フラグＹに１を設定し、フラグＸが１ならば、フラ
グＹに０を設定する。（サーバ通信キャッシュ127内に処理結果が存在すれば、サーバ処
理装置130にリクエストを送信せず、処理結果が存在すれば、リクエストを送信する。）
【０１０８】
（４）図１０のフラグＸが１であるリクエストのそれぞれに対応した処理結果をサーバ通
信キャッシュ127から取り出して、それぞれのアプリに返す。
【０１０９】
（５）図１０のフラグＹが１であるリクエストを合成して１つのリクエストにまとめてサ
ーバ処理装置130に送信し、サーバ処理装置130から合成された処理結果をまとめて受け取ったら分割してサーバ通信キャッシュに保存する。
【符号の説明】
【０１１０】
100  ネットワーク
110  クライアント処理装置
111  クライアント処理装置の通信部
112  クライアント処理装置のCPU
113  クライアント処理装置の表示部
114  クライアント処理装置のGPS
115  クライアント処理装置の入力部
120  クライアント処理装置のメモリ
121  アプリ群
122  ナビアプリ
123  広告アプリ
124  サーバ通信仲介機能
125 GPS管理機能
126  通信グルーピングテーブル
127  サーバ通信キャッシュ
130  サーバ処理装置
131  サーバ処理装置の通信部
132  サーバ処理装置のCPU
133  サーバ処理装置の表示部
134  サーバ処理装置のHDD
135  サーバ処理装置の入力部
140  サーバ処理装置のメモリ
141  提供機能群
142  地図配信機能
143  広告配信機能
144  クライアント通信仲介機能
145  サーバ機能