JP5433538B2

JP5433538B2 - 通信量削減方法

Info

Publication number: JP5433538B2
Application number: JP2010209643A
Authority: JP
Inventors: 英樹 ▲高▼野; 俊介秋藤; 辰昭長船
Original assignee: Hitachi Automotive Systems Ltd
Current assignee: Hitachi Astemo Ltd
Priority date: 2010-09-17
Filing date: 2010-09-17
Publication date: 2014-03-05
Anticipated expiration: 2030-09-17
Also published as: US8832183B2; JP2012064128A; US20120215835A1

Description

携帯電話やカーナビ、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 サーバ機能

Claims

複数のプログラムが連携して動作するクライアント処理装置と、
前記クライアント処理装置に接続され、前記プログラムからのリクエストに対応した処理を実行するサーバ処理装置と、を有し、
前記クライアント処理装置は、
第一のプログラムが前記サーバ処理装置の第一のＵＲＬへ送出する第一のリクエストと、前記第一のプログラムから呼び出される第二のプログラムが第二のＵＲＬへ送出する第二のリクエストがあったとき、
前記クライアント処理装置内の通信グルーピング情報に定義された、前記第一のリクエストと前記第二のリクエストとの関連に基づいて、
前記第一のプログラムから前記第一のリクエストが送出されたとき、前記通信グルーピング情報から前記第二のリクエストを抽出し、前記第一のリクエストと前記第二のリクエストを合成したリクエストを前記サーバ処理装置の仲介機能の第三のＵＲＬへ送信し、
前記サーバ処理装置は、
前記仲介機能によって、前記第一のＵＲＬに対して、前記第一のリクエストを処理する第一の提供機能を呼び出して第一の処理結果を取得し、前記第二のＵＲＬに対して、前記第二のリクエストを処理する第二の提供機能を呼び出して第二の処理結果を取得し、
前記第一及び第二の処理結果を合成して前記クライアント処理装置に返し、
前記クライアント処理装置は、
前記合成された処理結果を分割し、前記第一の処理結果を前記第一のプログラムに返し、
前記第二の処理結果はキャッシュに保存し、
前記第二のリクエストが発生したとき、前記キャッシュから前記第二の処理結果を取得して前記第二のプログラムに返す
ことを特徴とする通信システム。
請求項１に記載の通信システムにおいて、
前記クライアント処理装置は、
前記サーバ処理装置へ前記第一のリクエストを送出した後、前記合成された処理結果を受信する前に前記第二のリクエストが発生した場合は、前記第二のリクエストを前記サーバ処理装置へ送信せず、
前記サーバ処理装置から、前記合成された処理結果が返されるのを待つ
ことを特徴とする通信システム。
請求項１または２に記載の通信システムにおいて、
前記サーバ処理装置で動作する仲介機能、前記第一の提供機能、前記第二の提供機能を、別のサーバ処理装置で動作するように構成し、前記仲介機能は、リクエストに応じて前記別のサーバ処理装置にある提供機能を呼び出す
ことを特徴とする通信システム。
請求項１から３のいずれか一に記載の通信システムにおいて、
前記第一のリクエストと前記第二のリクエストが各々、パラメータを持っているときに、前記第一のリクエストのパラメータと、前記第二のリクエストのパラメータの間の関係を前記通信グルーピングテーブル内に定義しておき、
前記第一のリクエスト発生時に、前記通信グルーピングテーブル内に定義した関係を利用し、前記第一のリクエストに含まれるパラメータから、前記第二のリクエストに含まれるパラメータを生成する
ことを特徴とする通信システム。
請求項１から４のいずれか一に記載の通信システムにおいて、
前記クライアント処理装置から前記サーバ処理装置へのリクエストの送信履歴から前記通信グルーピングテーブルを生成する際に、
前記クライアント処理装置から前記サーバ処理装置へのリクエスト送信時に、前記クライアント処理装置ではログを記録しておき、
前記クライアント処理装置で動作する通信グルーピングテーブル更新機能は、溜まったログを解析し、
リクエストが発生した時刻の差が特定時間内であるリクエストを抽出し、
前記ログ内で前記第三のリクエストと前記第四のリクエストが同時に発生した回数を評価し、評価の結果、同タイミングで発生することが多いことが分かったらそれらを前記通信グルーピングテーブルに格納する
ことを特徴とする通信システム。
請求項５に記載の通信システムにおいて、
前記第三のリクエストと前記第四のリクエストのパラメータ値を比較し、パラメータ値の間に関係があるときに、前記第三のリクエストと前記第四のリクエストを対応付けて前記通信グルーピングテーブルに格納する
ことを特徴とする通信システム。
複数のプログラムが連携して動作するクライアント処理装置と、
前記クライアント処理装置に接続され、前記プログラムからのリクエストに対応した処理を実行するサーバ処理装置とを有し、
前記クライアント処理装置は、
第一のプログラムが前記サーバ処理装置の第一のＵＲＬへ送出する第一のリクエストと、前記第一のプログラムから呼び出される第二のプログラムが一連の操作の中で第二のＵＲＬへ送出する第二のリクエストがあったとき、
前記クライアント処理装置内の通信グルーピング情報に定義された、前記第一のリクエストと前記少なくとも一つの第二のリクエストとの関連に基づいて、
前記第一のプログラムから前記第一のリクエストが送出されたとき、前記リクエストの送受信を制御するための制御情報に、前記第一のリクエストと前記少なくとも一つの第二のリクエストを設定し、
キャッシュ内に、前記第一のＵＲＬに対する前記第一のリクエスト及び前記第二のＵＲＬに対する前記少なくとも一つの第二のリクエストのそれぞれに対応した処理結果が既に存在するかどうかを調べて、存在の有無に応じたオン又はオフの第１のフラグを、前記第一のリクエスト及び前記少なくとも一つの第二のリクエストのそれぞれに対応して、前記制御情報に設定し、
前記第１のフラグの値の補数である第２のフラグを、前記第一のリクエスト及び前記少なくとも一つの第二のリクエストのそれぞれに対応して、前記制御情報に設定し、
前記第１のフラグがオンである少なくとも一つの前記リクエストのそれぞれの処理結果を、前記プログラムのそれぞれに返し、
前記第２のフラグがオンである少なくとも一つの前記リクエストを合成して前記サーバ処理装置に送信し、前記サーバ処理装置から合成された処理結果をまとめて受け取ったら分割してキャッシュに保存する
ことを特徴とする通信システム。