(57)【要約】  通信装置は、送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部と、前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部と、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部とを備える。
2013183649.tif 000002
【特許請求の範囲】
【請求項１】
送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部と、
前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部と、
前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部と
を備える通信装置。
【請求項２】
前記データ集約部は、
前記送信順序情報に基づいて、送信優先度が高いと判断されるアプリケーションデータから順番に前記集約対象の複数のアプリケーションデータとして抽出する請求項1に記載の通信装置。
【請求項３】
前記送信予定データ記憶部は、
第１の送信優先順位を有する第１の送信キューと、前記第１の送信優先順位よりも低い第２の送信優先順位を有する第２の送信キューとを含む複数の送信キューを含み、前記複数のアプリケーションデータ各々を、前記送信優先順位情報に応じて前記複数の送信キューいずれかに蓄積し、
前記データ集約部は、
前記第１の送信キュー蓄積されているアプリケーションデータを、前記第２の送信キュー蓄積されているアプリケーションデータよりも先に取り出し、前記最大送信サイズ未満となるように前記集約データを生成する
請求項１または２に記載の通信装置。
【請求項４】
前記送信順序情報は、
対応付けられているアプリケーションデータの送信の優先順位を許容遅延時刻で示す情報である請求項１から３のうちいずれか一項に記載の通信装置。
【請求項５】
前記データ集約部は、
前記抽出された複数のアプリケーションデータから抽出された少なくとも一つのアプリケーションデータを各々含む複数の組み合わせパターンを抽出し、前記複数の組み合わせパターン各々に含まれる前記少なくとも一つのアプリケーションデータのデータサイズに基づき、前記複数の組み合わせパターンから一つの組み合わせパターンを選択して、前記選択された組み合わせパターンに含まれる複数のアプリケーションデータに基づき、前記集約データを生成する請求項１から４のうちいずれか一項に記載の通信装置。
【請求項６】
前記データ集約部は、
前記抽出された複数のアプリケーションデータから抽出された少なくとも一つのアプリケーションデータを各々含む複数の組み合わせパターンを抽出し、前記複数の組み合わせパターン各々に含まれる前記少なくとも一つのアプリケーションデータの前記許容遅延時刻と所定の時刻との差の値に基づいて、前記複数の組み合わせパターンから一つの組み合わせパターンを選択して、前記選択された組み合わせパターンに含まれる複数のアプリケーションデータに基づき、前記集約データを生成する請求項４に記載の通信装置。
【請求項７】
前記抽出された複数のアプリケーションデータから抽出された少なくとも一つのアプリケーションデータを各々含む複数の組み合わせパターンを抽出し、前記複数の組み合わせパターン各々に含まれる前記少なくとも一つのアプリケーションデータのデータサイズと前記最大送信サイズとの割合、および、前記複数組み合わせパターン各々に含まれる前記少なくとも一つのアプリケーションデータの送信順序情報に基づき、前記複数の組み合わせパターンから一つの前記組み合わせパターンを選択して、前記選択された組み合わせパターンに含まれる複数のアプリケーションデータに基づき、前記集約データを生成する請求項１から４のうちいずれか一項に記載の通信装置。
【請求項８】
第１および第２通信端末を備える通信システムであって、
前記第１通信端末は、
送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部と、
前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部と、
前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部と、を有し、
前記第２通信端末は、
前記データ送信部が送信した前記集約データを受信するデータ受信部と、
前記集約データを解析して分解するデータ分析部と、を有する
通信システム。
【請求項９】
送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部を参照し、
前記送信予定データ記憶部に記憶されている前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、
データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、
前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成し、
前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信する
ことを含む通信方法。
【請求項１０】
コンピュータを、
送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部、
前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数の前記アプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部、
前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、通信システム、通信方法及びプログラムに関する。
【背景技術】
【０００２】
近年、スマートハウスやＭ２Ｍ（Ｍａｃｈｉｎｅ  ｔｏ  Ｍａｃｈｉｎｅ）の実現に向けて、太陽光発電システムや蓄電池等のエネルギー関連機器や家電機器を対象に、遠隔監視や遠隔制御によるエネルギーマネジメントの研究開発や実証実験が進められている。外部の遠隔監視・制御サーバ（以下、外部サーバと呼ぶ。）と家庭内の機器間のゲートウェイ機器として、スマートメータやＨＥＭＳ（Ｈｏｍｅ  Ｅｎｅｒｇｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）が挙げられる。外部サーバは、各種通信メディアを介してスマートメータやＨＥＭＳに命令を送り、各機器を制御する。【０００３】
外部サーバによる機器の制御として、太陽光発電システムの発電電力の制限命令や、蓄電池の充放電量の指定などがある。各制御命令は制御対象の識別子や発電量／充放電を示すコード、各コードへの指示内容を示す情報などから構成される。制御命令のサイズは非常に小さい。例えば、ＥＣＨＯＮＥＴ（登録商標（以下、省略）；Ｅｎｅｒｇｙ  Ｃｏｎｓｅｒｖａｔｉｏｎ  ａｎｄ  Ｈｏｍｅｃａｒｅ  Ｎｅｔｗｏｒｋ）では蓄電池制御に関するメッセージフォーマットが規定される。そのメッセージフォーマットのデータサイズの多くは１０〜２０バイトである（エコーネット規格：ｈｔｔｐ：／／ｗｗｗ．ｅｃｈｏｎｅｔ．ｇｒ．ｊｐ／ｓｐｅｃ／ｓｐｅｃ＿ｖ１００＿ｌｉｔｅ．ｈｔｍ）。【０００４】
外部サーバと需要家を繋ぐ通信メディアとしては１００バイト程度の極小帯域を利用することが検討されている。そのため、限られた通信帯域の効率的利用が求められる。しかし、現状では、外部サーバは、需要家に対して、複数種類の制御命令をその命令ごとに規定されるタイミングで送信している。そのため、前述のように小さいデータサイズの命令が狭帯域の通信メディア上を流れることになる。【０００５】
多数の制御命令を通信する場合にデータ転送効率を向上させるための技術の一つにパケット集約技術がある。この技術では、複数のデータをそれぞれ別のパケットとして伝送するのではなく、例えば１つのパケットに複数のデータを集約して含ませる。
この技術によれば、各パケットの先頭部分に付加されるヘッダ領域を共通化することが可能となる。このヘッダ領域の共通化によって、帯域幅を効率的に利用することができる。
このような技術の一例が特許文献１や特許文献２に記載されている。【０００６】
特許文献１に記載されている技術では、集約パケットを生成する際に集約パケットのサイズを動的に変化させる。これによって音声データ等を伝送する際に、パケット集約ジッタや最初の集約パケットの遅延を減らすことが可能となる。【０００７】
特許文献２に記載されている技術では、パケットをトンネリングする際に、ヘッダ部分を共通化する。すなわち、特許文献２に記載されている技術では、動画像や音声などを表す大容量データを伝送する際に、ＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）パケットをＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）によってカプセル化する。その際、集約したＲＴＰパケットのヘッダ部分を共通化することで、パケットヘッダによるオーバーヘッドを低減している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】日本国特許第４７２７９７７号公報
【特許文献２】日本国特開２００８−３１１９４２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１や特許文献２に記載されている技術では、送信する複数のデータを集約する際に、遅滞なく送信予定の各データを送信する。この方法では、例えば上述したような外部サーバによる家庭内機器の制御におけるデータ通信では、効率的に希望のサイズの集約データを生成できなくない場合がある、という問題がある。このケースでは、制御を行うアプリケーションが不定期に制御用のデータを送信しようとする。そのため、全てのデータを遅延なく集約しようとすると、集約用のデータが十分に確保できず、希望のサイズの集約データを生成できない場合がある。これは、制御用のデータのうち遅延が許容されるデータであっても、遅延なく集約しようとするためである。【００１０】
本発明は、上記の事情を考慮してなされた。本発明の目的の一例は、上記の課題を解決することができる通信装置、通信システム、通信方法及び通信プログラムを提供することである。
【課題を解決するための手段】
【００１１】
上記課題を解決するため、本発明の実施態様に係る通信装置は、送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部と、前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部と、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部とを備える。【００１２】
本発明の実施態様に係る通信システムは、第１および第２通信端末を備える。前記第１通信端末は、送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部と、前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部と、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部と、を有する。前記第２通信端末は、前記データ送信部が送信した前記集約データを受信するデータ受信部と、前記集約データを解析して分解するデータ分析部と、を有する。【００１３】
本発明の実施態様に係る通信方法は、送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部を参照し、前記送信予定データ記憶部に記憶されている前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成し、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信することを含む。【００１４】
本発明の実施態様に係るプログラムは、コンピュータを、送信順序を示す送信順序情報と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する送信予定データ記憶部、前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出し、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数の前記アプリケーションデータを抽出し、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成するデータ集約部、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信するデータ送信部として機能させる。
【発明の効果】
【００１５】
本発明によれば、例えば、遅滞がある程度許容されるデータと、遅滞をできるだけ少なくすることが望ましいデータとがこの順番で発生したような場合でも、発生順序にかかわらず、適切な順序でデータを集約することが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態における通信システムの構成図である。
【図２】本発明の第１の実施形態における第１通信端末の構成図である。
【図３】本発明の第１の実施形態における送信予定データ記憶部が記憶するデータの一例を示した図である。
【図４】本発明の第１の実施形態における集約データの一例を示した図である。
【図５】本発明の第１の実施形態における第２通信端末の構成図である。
【図６】本発明の第１の実施形態における第１通信端末の内部動作に関するフローチャートである。
【図７】本発明の第１の実施形態における集約方法の一例に関するフローチャートである。
【図８】本発明の第１の実施形態における第２通信端末の内部動作に関するフローチャートである。
【図９】本発明の第２の実施の形態における第１通信端末の構成図である。
【図１０】本発明の第２の実施の形態における送信キューの一例を示した図である。
【図１１Ａ】本発明の第２の実施の形態における集約方法の一例を説明するための図である。
【図１１Ｂ】本発明の第２の実施の形態における集約方法の一例を説明するための図である。
【図１２】本発明の第２の実施形態における集約方法の一例に関するフローチャートである。
【図１３】本発明の第２の実施形態における集約方法の一例に関するフローチャートである。
【図１４】本発明の第１の実施形態の動作を説明するための送信予定データの例を示した図である。
【図１５】本発明の第１の実施形態の動作を説明するための送信予定データ記憶部に記憶された送信予定データの例を示した図である。
【図１６】本発明の第１の実施形態の動作を説明するための集約データの例を示した図である。
【図１７】本発明の基本的な実施形態の構成図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施の形態について図面を参照して説明する。本実施形態の通信システムの特徴の一つは、データ種別に応じてデータを集約することで、ネットワークへの負荷を軽減する。
本発明では、送信しようとするアプリケーションデータが発生した場合、そのアプリケーションデータを、一旦、送信予定データとして送信予定データ記憶部に記憶することができる。その際、アプリケーションデータは、当該アプリケーションデータの送信順序の先後を示す送信順序情報と、当該アプリケーションデータの宛先端末を示す宛先情報とに対応付けて記憶される。また、集約データは、宛先情報が同一の複数の送信予定データを送信予定データ記憶部から抽出し、抽出した送信予定データを送信順序情報に応じて複数組み合わせることで生成される。すなわち、本発明によれば、アプリケーションデータの送信順序の先後を示す送信順序情報に応じてデータを集約することが可能となる。したがって、例えば、遅滞がある程度許容されるデータと、遅滞をできるだけ少なくすることが望ましいデータとがこの順番で発生したような場合でも、発生順序にかかわらず、適切な順序でデータを集約することが可能となる。
【００１８】
本発明を実施するための第１の実施の形態における通信システムの構成図を図１に示す。図１を参照すると、第１の実施形態の通信システム１００は、第１通信端末（送信側の通信端末）１０１と第２通信端末（受信側の通信端末）１０２とを備えている。この第１通信端末１０１と第２通信端末１０２とは、ネットワーク１０３を介して接続されている。図１は通信システム１００の一構成例であり、通信システム１００の構成はこれに限られない。すなわち、通信システム１００は、例えば、２以上の第１通信端末１０１を備えてもよく、２以上の第２通信端末１０２を備えてもよい。
【００１９】
第１通信端末１０１は、ネットワーク１０３を介して、第２通信端末１０２にメッセージを届ける端末である。例えば、サーバや携帯端末などの通信装置である。この第１通信端末１０１は、図示していない所定の記憶部に自端末の識別子を表すデータを記憶している。
【００２０】
第２通信端末１０２は、ネットワーク１０３を介して、第１通信端末１０１からメッセージを受け取る端末である。例えば、サーバや携帯端末などの通信装置である。
この第２通信端末１０２は、図示していない所定の記憶部に自端末の識別子を表すデータを記憶している。
【００２１】
ネットワーク１０３は、メッセージを伝送する通信網である。例えば、電力線搬送通信、携帯電話網、光通信網などの通信網である。
【００２２】
なお、図１に示した通信システムにおいて、第１通信端末１０１や第２通信端末１０２は、例えば、背景技術として上述した外部サーバと家庭内の機器間のゲートウェイ機器や、外部サーバに対応する。
【００２３】
第１通信端末１０１の構成例を図２に示す。第１通信端末１０１は、データ生成部群２０１、送信タイミング管理部２０２、許容遅延情報記憶部２０３、送信予定データ記憶部２０４、データ集約部２０５、最大送信サイズ記憶部２０６、集約ポリシ記憶部２０７、及びデータ送信部２０８を備える。
【００２４】
データ生成部群２０１は、少なくとも一つ以上のデータ生成部２０１ｘを有する。各データ生成部２０１ｘは個々のタイミングでアプリケーションデータを生成する。さらに各データ生成部２０１ｘは、アプリケーションデータと宛先端末（この例では第２通信端末１０２）の識別子とを有する送信予定データを、自身の識別子と関連付けて、送信タイミング管理部２０２に渡す。データ生成部２０１ｘは、具体的には、Ｃ言語、Ｊａｖａ（登録商標）、ＪａｖａＳｃｒｉｐｔ（登録商標）などのプログラミング言語で記述されるアプリケーションプログラムである。
【００２５】
送信予定データに含まれるアプリケーションデータは、アプリケーションヘッダとアプリケーションボディとを有する。アプリケーションヘッダは、アプリケーションの種別やその識別子などを有する。より具体的には、アプリケーションヘッダは、ＥＣＨＯＮＥＴにおけるオブジェクトコードやサービス種別コード、あるいはＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）におけるメッセージヘッダに該当する。アプリケーションボディは、アプリケーションの処理内容に関わる情報を有する。より具体的には、アプリケーションボディは、ＥＣＨＯＮＥＴにおけるプロパティコード、ＥＣＨＯＮＥＴデータ、あるいはＨＴＴＰにおけるメッセージボディに該当する。
【００２６】
宛先端末の識別子は、例えば宛先端末のＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）アドレスや宛先端末のホスト名に該当する。
【００２７】
送信タイミング管理部２０２は、データ生成部群２０１から送信予定データとデータ生成部２０１ｘの識別子を受け取る。送信タイミング管理部２０２は、データ生成部２０１ｘに関連する許容遅延情報を、許容遅延情報記憶部２０３から取得する。送信タイミング管理部２０２は、各データ生成部２０１ｘに関連する許容遅延情報に基づいて、各送信予定データの送信タイミングを監視する。送信タイミング管理部２０２は、送信予定データと、許容遅延情報あるいはこの情報を基に新たに生成される許容遅延情報とを関連付けて、送信予定データ記憶部２０４に記録する。送信タイミング管理部２０２は、データ生成部群２０１から送信予定データを受け取るとき、あるいは任意の送信予定データが送信タイミングであると判断するとき、あるいは所定の周期で、データ集約部２０５にデータの集約を開始することを指示する。
【００２８】
許容遅延情報とは、送信予定データに許容される遅延に関する情報である。許容遅延情報は、具体的には、データ生成部２０１ｘからデータを受け取ってから許容される相対遅延時間や、遅延の許容度などに該当する。遅延の許容度の具体例は、即時送信や、送信優先度の高・低などである。すなわち、アプリケーションデータに対応付けられる許容遅延情報は、そのアプリケーションデータの他のアプリケーションデータに対する送信順序の先後を示す情報である。
【００２９】
許容遅延情報は、データ生成部２０１ｘの識別子を検索キーとして、許容遅延情報記憶部２０３から取得される。
【００３０】
許容遅延情報に基づいて新たに生成される許容遅延情報は、例えば相対遅延時間に基づいて算出される絶対時刻に該当する。この絶対時刻の算出方法としては、データ生成部２０１ｘから送信予定データを受け取る時間に相対遅延時間を加算した値を絶対時刻とする方法を用いてもよい。
【００３１】
許容遅延情報記憶部２０３は、許容遅延情報とデータ生成部２０１ｘの識別子とを関連付けて記憶する。許容遅延情報記憶部２０３は、送信タイミング管理部２０２からの要求に応じて、該当する許容遅延情報を送信タイミング管理部２０２に送る。
【００３２】
送信予定データ記憶部２０４は、送信タイミング管理部２０２から送信予定データを受け取る。送信予定データ記憶部２０４は、送信予定データを記憶する。その際、送信予定データ記憶部２０４は、送信タイミング管理部２０２から受け取った送信予定データに含まれるアプリケーションデータを、送信順序の先後を示す情報と、そのアプリケーションデータの宛先端末を示す情報とに対応付けて、送信予定データとして複数記憶する。送信順序の先後を示す情報とは、受け取った送信予定データに含まれるアプリケーションデータの他のアプリケーションデータに対する送信順序の先後を示す情報である。さらに、送信予定データ記憶部２０４は、データ集約部２０５からの要求に応じて該当する送信予定データをデータ集約部２０５に送る。
【００３３】
送信予定データ記憶部２０４が記憶する送信予定データの一例を図３に示す。
送信予定データ記憶部２０４は、許容遅延情報（遅延許容時刻を含む）と送信予定データ（宛先端末の識別子、アプリケーションデータを含む）とを関連付けて記憶している。例えば、データ（１）は、許容遅延情報の遅延許容時刻として「時刻Ａ」、宛先端末の識別子として「端末Ａ」、アプリケーションヘッダとして「ＡＨ１」、アプリケーションボディとして「ＡＢ１」を記憶している。同様に、データ（２）は、許容遅延情報の遅延許容時刻として「時刻Ｂ」、宛先端末の識別子として「端末Ｂ」、アプリケーションヘッダとして「ＡＨ２」、アプリケーションボディとして「ＡＢ２」を記憶している。データ（３）は、許容遅延情報の遅延許容時刻として「時刻Ｃ」、宛先端末の識別子として「端末Ａ」、アプリケーションヘッダとして「ＡＨ１」、アプリケーションボディとして「ＡＢ３」を記憶している。
【００３４】
データ集約部２０５は、送信タイミング管理部２０２から送信予定データの集約指示を受ける。データ集約部２０５は、送信予定データ記憶部２０４から全てのデータを取得する。データ集約部２０５は、最大送信サイズ記憶部２０６からアプリケーションボディの最大送信サイズを取得する。データ集約部２０５は、集約ポリシ記憶部２０７から集約ポリシを取得する。データ集約部２０５は、送信予定データの遅延許容時刻及び送信最大サイズに応じ、集約ポリシを考慮して、送信予定データを集約する。集約データの生成方法に関しては後述する。データ集約部２０５は、送信可能な集約データをデータ送信部２０８に渡す。
【００３５】
最大送信サイズ記憶部２０６は、送信時のアプリケーションボディの最大サイズを記憶する。さらに、最大送信サイズ記憶部２０６は、データ集約部２０５からの要求に応じて最大送信サイズをデータ集約部２０５に送る。最大送信サイズとは、１つの集約データとし集約する際の最大サイズを示す情報である。本実施形態において、最大送信サイズ記憶部２０６は、送信時のアプリケーションボディの最大サイズを示す情報を記憶する。本実施形態はこれに限られず、最大送信サイズ記憶部２０６は、１つのデータとして集約された際の集約データの全体の最大サイズを示す情報であってもよく、送信時のアプリケーションボディに加え、送信時のアプリケーションヘッダ等を示す情報を含む情報であってもよい。
【００３６】
集約ポリシ記憶部２０７は、集約ポリシを記憶する。集約ポリシ記憶部２０７は、データ集約部２０５からの要求に応じて、集約ポリシをデータ集約部２０５に送る。
【００３７】
集約ポリシとは、送信予定データの集約の方法を規定する情報である。集約ポリシが表す集約方法は、送信予定データの少なくとも一つ以上の構成要素を基に規定され、第２通信端末１０２のデータ解析方法（後述）を考慮して規定される方法である。
【００３８】
具体的な集約ポリシの例を、図３の送信予定データを元に説明する。この例における集約ポリシは以下の［手順１］および［手順２］を有する。
［手順１］：宛先端末の識別子とアプリケーションヘッダが同等の送信予定データである送信予定データを選択する。
［手順２］：［手順１］で選択した送信予定データが含む、宛先端末の識別子とアプリケーションヘッダとを共通化し、アプリケーションボディを集約する。
【００３９】
この場合に生成される集約データを図４に示す。この集約データは、図３におけるデータ（１）とデータ（３）とを用いて生成される集約データである。そのため、図３に示した集約データは、宛先端末の識別子「端末Ａ」とアプリケーションヘッダ「ＡＨ１」とを共通化し、アプリケーションボディとして「ＡＢ１」及び「ＡＢ３」を持つ集約データとなっている。
【００４０】
この集約ポリシは第２通信端末１０２のデータ解析方法を考慮して規定される。このデータ解析方法の具体例は次の通りである。
【００４１】
・アプリケーションヘッダによって、受信端末側のデータ処理部５０５ｘ（後述）が決定されること。
・集約データのアプリケーションボディを集約前の複数のアプリケーションボディに分解した後に、それらアプリケーションボディを前述のデータ処理部５０５ｘに渡すことができること。
【００４２】
集約データを分解できる例は、アプリケーションボディの先頭の規定数バイトに集約前のアプリケーションボディ単体のデータサイズが記載される場合が挙げられる。受信側のデータ処理部５０５ｘは、このデータサイズに従い、集約データを集約前の複数のアプリケーションボディに分解する。
【００４３】
データ送信部２０８は、データ集約部２０５から集約データを受け取る。データ送信部２０８は、集約データを第２通信端末１０２に送信する。データ送信部２０８が集約データを送信する動作の具体例は、集約データを基にＩＰパケットを生成することを含む。このとき、集約データには、必要に応じてアプリケーションヘッダを追加したり、通信用のヘッダを追加したりする。追加されるアプリケーションヘッダの具体例は、ＥＣＨＯＮＥＴにおけるトランザクションＩＤ（ＩＤｅｎｔｉｆｉｅｒ）を含む。通信用のヘッダの具体例は、ＩＰヘッダやＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）ヘッダを含む。
【００４４】
データ第２通信端末１０２の構成例を図５に示す。データ第２通信端末１０２は、データ受信部５０１、データ解析部５０２、アプリケーションヘッダ解析方法記憶部５０３、アプリケーションボディ処理方法記憶部５０４、及びデータ処理部群５０５から構成される。
【００４５】
データ受信部５０１は、第１通信端末１０１からデータを受け取る。データ受信部５０１は、データから集約データを抽出する。データ受信部５０１は、集約データをデータ解析部５０２に渡す。集約データを抽出するとは、通信用のヘッダを取りはずすことでアプリケーションが扱うデータを抽出することを意味する。
【００４６】
データ解析部５０２は、データ受信部５０１から集約データを受け取る。データ解析部５０２は、アプリケーションヘッダ解析方法記憶部５０３から、アプリケーションヘッダとデータ処理部５０５ｘとを関連付ける情報を取得する。データ解析部５０２は、アプリケーションボディ処理方法記憶部５０４から、アプリケーションボディの処理方法に関する情報を受け取る。データ解析部５０２は、アプリケーションボディの処理方法に関する情報に基づいて、アプリケーションボディを処理可能な単位に分解する。データ解析部５０２は、アプリケーションヘッダから特定されるデータ処理部群５０５のデータ処理部５０５ｘに対して、処理可能な単位に分解された全ての情報を渡す。
【００４７】
アプリケーションボディ処理方法に関する情報とは、アプリケーションボディを処理可能な単位に分解するための方法を表す情報である。アプリケーションボディ処理方法に関する情報の具体例は、アプリケーションボディの分解単位を表す情報がどこに設定されているのかということを示す情報と、その分解単位を表す情報を用いてどのようにアプリケーションボディを分解するのかということを示す情報とを含む情報である。アプリケーションボディの分解単位を表す情報がどこに設定されているのかということを示す情報の一例は、アプリケーションボディの先頭から所定のバイト数内の値に処理可能なデータサイズが記載されている、という情報であってもよい。どのようにアプリケーションボディを分解するのかということを示す情報の一例は、アプリケーションボディの先頭からそのデータサイズ分を処理可能な単位として取り出し、さらに、この処理をアプリケーションボディがなくなるまで繰り返す、という情報であってもよい。この場合、データ解析部５０２は、アプリケーションボディの先頭からここで記載されるデータサイズ分を処理可能な単位として取り出す。さらに、データ解析部５０２は、この処理をアプリケーションボディがなくなるまで繰り返す。
【００４８】
アプリケーションヘッダ解析方法記憶部５０３は、アプリケーションヘッダとデータ処理部５０５ｘとを関連付ける情報を記憶する。アプリケーションヘッダ解析方法記憶部５０３は、データ解析部５０２の要求に応じて、その関連情報をデータ解析部５０２に送る。
【００４９】
アプリケーションボディ処理方法記憶部５０４は、アプリケーションボディを処理可能な単位に分解するための方法に関する情報を記憶する。さらに、アプリケーションボディ処理方法記憶部５０４は、データ解析部５０２の要求に応じて、処理方法に関する情報を送る。
【００５０】
データ処理部群５０５は、少なくとも一つ以上のデータ処理部５０５ｘを有する。各データ処理部５０５ｘは、データ解析部５０２からデータを受け取る。各データ処理部５０５ｘは、データを規定の方法に基づいて処理する。各データ処理部５０５ｘにおける規定のデータ処理方法の具体例は、各情報をＤＢ（データベース）に記録したり、情報を異なる端末に送信したり、送信元の端末に応答を返すことを判断したりすることを含む。このデータ処理部５０５ｘの具体例は、ＥＣＨＯＮＥＴにおけるＥＣＨＯＮＥＴアプリケーションや、ＨＴＴＰにおけるサーブレットやＰＨＰ（Ｈｙｐｅｒｔｅｘｔ  Ｐｒｅｐｒｏｃｅｓｓｏｒ）などのサーバサイドアプリケーションを含む。
【００５１】
次に、第１の実施形態の全体の動作についてフローチャートを基に詳細に説明する。第１通信端末１０１の内部動作を図６に示す。第１通信端末１０１の送信タイミング管理部２０２が、データ生成部群２０１から送信予定データとデータ生成部２０１ｘの識別子とを受け取る。さらに、送信タイミング管理部２０２が、許容遅延情報記憶部２０３からデータ生成部２０１ｘに関連する許容遅延情報を取得する。そして、送信タイミング管理部２０２は、ステップＳ６０２での記憶処理等の処理対象となる送信予定データを更新する（ステップＳ６０１）。次に、送信タイミング管理部２０２は、送信予定データと許容遅延情報とを関連付けて送信予定データ記憶部２０４に記憶する（ステップＳ６０２）。次に、データ集約部２０５が、送信タイミング管理部２０２からの指示に応じて、各送信予定データの許容遅延情報と、集約方法に関する情報と、最大送信サイズとを考慮して、集約可能な送信予定データがある場合、送信予定データ記憶部２０４に現時点において蓄積されている送信予定データから集約データを生成する（詳細は後述）（ステップＳ６０３）。データ集約部２０５は、送信可能な集約データを生成できると判断した場合（ステップＳ６０３：Ｙｅｓ）はステップＳ６０４へ進む。データ集約部２０５が送信可能な集約データを生成できない生成できないと判断した場合（ステップＳ６０３：Ｎｏ）はステップＳ６０５へ進む。次に、データ送信部２０８が、データ集約部２０５から集約データを受け取ると、受け取った集約データを送信する（ステップＳ６０４）。第１通信端末１０１は、ここで処理を終了する（ステップＳ６０５）。
【００５２】
ステップＳ６０３の具体例、すなわちデータ集約部２０５が行う集約処理の具体例として、３種類の集約方法を、集約方法Ａ、Ｂ及びＣとして説明する。各集約方法の説明の前提として、集約ポリシ、最大送信サイズとして次の状況を想定する。すなわち、この想定におけるは、最大送信サイズの想定を、ＡＢｍａｘとする。また、この想定における集約ポリシは以下の［手順１Ａ］および［手順２Ａ］を有する。
［手順１Ａ］：宛先端末の識別子とアプリケーションヘッダを共通とする送信予定データを抽出する。
［手順２Ａ］：［手順１Ａ］を満たす送信予定データで、宛先端末の識別子とアプリケーションヘッダを共通化し、アプリケーションボディを連結したデータを集約データとする。
【００５３】
まず、図７を参照して、集約方法Ａについて説明する。
【００５４】
ステップＡ−１１：データ集約部２０５は、集約ポリシの[手順１Ａ]に従い、送信予定データ記憶部２０４を参照して、宛先端末の識別子とアプリケーションヘッダの値が共通の送信予定データでグループ分けする。
ステップＡ−１２：データ集約部２０５は、グループ分けすべきグループの有無を判断する。データ集約部２０５は、グループ分けすべきグループが有ると判断した場合（ステップＡ−１２：Ｙｅｓ）は、ステップＡ−２１へ進む。データ集約部２０５は、グループ分けすべきグループが無いと判断した場合（ステップＡ−１２：Ｎｏ）は、処理を完了する。
【００５５】
ステップＡ−２１：データ集約部２０５は、ステップＡ−１１でグループ分けしたグループから任意のグループを選択する。データ集約部２０５は、ステップＡ−２１では、後述するステップＡ−３１でまだ処理されていない未処理のグループを選択対象とする。すなわち、データ集約部２０５は、ステップＡ−２１では、過去に選択されたグループとは異なるグループを選択する。
ステップＡ−２２：データ集約部２０５は、未処理のグループの有無を判断する。データ集約部２０５は、未処理のグループが有ると判断した場合（ステップＡ−２２：Ｙｅｓ）はステップＡ−３１へ進む。データ集約部２０５は、未処理のグループが無いと判断した場合（ステップＡ−２２：Ｎｏ）は処理を完了する。
【００５６】
ステップＡ−３１：データ集約部２０５は、ステップＡ−２１で選択したグループに属する送信予定データから、許容遅延時刻が現在時刻で指定される送信予定データを抽出して選択する。
ステップＡ−３２：データ集約部２０５は、許容遅延時刻が現在時刻で指定される送信予定データの有無を判断する。データ集約部２０５は、許容遅延時刻が現在時刻で指定される送信予定データが有ると判断した場合（ステップＡ−３２：Ｙｅｓ）はステップＡ−４１へ進む。データ集約部２０５は、許容遅延時刻が現在時刻で指定される送信予定データが無いと判断した場合（ステップＡ−３２：Ｎｏ）はステップＡ−２１へ戻る。ここで、抽出される送信予定データは、即時に送信する必要があると判断される送信予定データである。
【００５７】
ステップＡ−４１：ステップＡ−３１で選択された送信予定データとその他の送信予定データとを有する集約データの全組み合わせパターンに関して、データ集約部２０５は、集約効率Ｅ、送信優先度Ｑ及び集約適正度Ａの計算を行う。データ集約部２０５は、これらの算出した集約効率Ｅ、送信優先度Ｑ及び集約適正度Ａに基づいて送信する集約データを決定する。ただし、送信する集約データは、ステップＡ−３１で選択されたすべての送信予定データに基づくステップＡ−４１での集約適正度Ａの計算処理が終了した後に最終的に決定される。
【００５８】
ステップＡ−４１における計算処理を具体例を示して説明する。この例では、ある組み合わせパターンとして決定される送信予定データの各アプリケーションボディのサイズをＡＢ１、ＡＢ２、・・・、ＡＢｎと仮定し、また、ステップＡ−３１で選択された送信予定データのアプリケーションボディのサイズをＡＢ０と仮定する。この場合、集約効率Ｅは次のように算出される。
【００５９】
集約効率Ｅは、式（１）を満たす送信予定データの組み合わせパターンを対象として、式（２）により算出することができる。
【００６０】
（ＡＢ０＋ＡＢ１＋ＡＢ２＋・・・＋ＡＢｎ）＜ＡＢｍａｘ    …式（１）
【００６１】
Ｅ＝α＊（ＡＢ０＋ＡＢ１＋ＡＢ２＋・・・＋ＡＢｎ）／ＡＢｍａｘ  …式（２）
【００６２】
その他の送信予定データの各遅延許容時刻をＴ１、Ｔ２、・・・、Ｔｎと表記し、現在時刻をｔと表記する。この場合、送信優先度Ｑは次のように算出される。なお、Ｔ１、Ｔ２、・・・、Ｔｎ及びｔは「分」を単位として時刻を表す。ただし、これに限らず、例えば「秒」を単位として時刻を表してもよい。
【００６３】
Ｑ＝β（１／（Ｔ１−ｔ）＋１／（Ｔ２−ｔ）＋・・・＋１／（Ｔｎ−ｔ））  …式（３）
【００６４】
ただし、「Ｔｉ＝ｔ」の場合は、その送信予定データの送信優先度Ｑは、「Ｑ＝β＊Ｑ０」と設定する。「Ｔｉ＝ｔ」となる送信予定データは、許容遅延情報に現在時刻が記載されている送信予定データであり、その処理優先度を所定の値（Ｑ０）と設定する。
【００６５】
なお、α、βは重み付け定数を表す。重み付け定数βに対して、重み付け定数αを大きく設定すると送信優先度Ｑに対して集約効率Ｅがデータ集約における送信予定データの選択に影響する。一方で、重み付け定数αに対して、重み付け定数βを大きく設定すると集約効率Ｅに対して送信優先度Ｑがデータ集約における送信予定データの選択に影響する。
【００６６】
さらに、送信予定データの組み合わせパターンごとの集約適正度Ａを算出する。
【００６７】
Ａ＝Ｅ＋Ｑ  …式（４）
【００６８】
ステップＡ−４１では、データ集約部２０５は、算出される集約適正度Ａが最大値を取る組み合わせパターンの送信予定データを集約し、送信可能な集約データを生成する。
【００６９】
許容遅延情報が現在時刻で指定される、ある送信予定データに関して、式（１）を満たすその他の送信予定データが無い場合は、その送信予定データを集約データとする。
【００７０】
ステップＡ−４１では、上記のようにして、データ集約部２０５は、ステップＡ−３１で選択された送信予定データとその他の送信予定データとを有する集約データの全組み合わせパターンにおいて集約効率Ｅ、送信優先度Ｑ及び集約適正度Ａの計算を行う。その後、データ集約部２０５は、ステップＡ−３１に戻り、ステップＡ−２１で選択されるグループ内で許容遅延情報が現在時刻で指定される送信予定データが無くなるまで繰り返し同じグループに対してステップＡ−４１の処理を実行する。さらに、データ集約部２０５は、同一グループ内の送信予定データに関して、ステップＡ−４１で処理すべき送信予定データが無くなったと判断するとステップＡ−２１に戻り、新たなグループを選択するステップＡ−２１から以降同じ動作を繰り返す。
【００７１】
集約方法Ａによって送信予定データを集約した場合、例えば図３及び図４を参照して説明した例では、次のような集約効果（すなわちデータ削減率Ｒ）が期待できる。つまり、集約せずに図３に示したデータ（１）およびデータ（３）を別々に第２通信端末１０２に送信する場合に比べて、図４に示した集約データを送信する場合には式（５）で算出されるデータ削減率Ｒが期待できる。
【００７２】
Ｒ＝（ＨＳ＋ＡＨＳ＋ＡＢＳ１＋ＡＢＳ３）／（（ＨＳ＋ＡＨＳ＋ＡＢＳ１）＋（ＨＳ＋ＡＨＳ＋ＡＢＳ３））＜１  …式（５）
【００７３】
ここでの試算は、図６におけるステップＳ６０４で集約データがパケット化される際に、パケットがＩＰ／ＵＤＰパケットであることを想定している。また、ＯＳＩ（Ｏｐｅｎ  Ｓｙｓｔｅｍｓ  Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ）参照モデルにおける物理層（Ｌ１）、データリンク層（Ｌ２）及びネットワーク層（Ｌ３）のヘッダが合計でＨＳバイトである。アプリケーションヘッダがＡＨＳバイトである。データ（１）のアプリケーションボディがＡＢＳ１バイトである。データ（３）のアプリケーションボディがＡＢＳ３バイトである。式（５）によれば、データ（１）とデータ（３）をばらばらに送信する場合と比べて、データ（１）とデータ（３）を集約して送信する場合では（ＨＳ＋ＡＨＳ）のデータサイズが削減されることが分かる。集約する送信予定データの個数が増えるに従って、この削減効果は上がる。
【００７４】
次に、集約方法Ｂについて説明する。集約方法Ｂでは、集約方法ＡにおけるステップＡ−３にさらに次のステップＢ−１が追加される。
【００７５】
ステップＢ−１：データ集約部２０５は、遅延許容時刻が現在時刻と異なる送信予定データ（ステップＡ−３におけるその他の送信予定データに該当する。）で集約データを生成する。送信予定データの全ての組み合わせパターン各々に関して集約データの集約効率Ｅ、送信優先度Ｑ、集約適正度Ａの計算を行う。各値の算出方法は式（１）、（２）、（３）、及び（４）と同様の方法である。ただし、式（２）、（３）における重み付け定数α、βの値は異なる値を設定しても良い。
【００７６】
データ集約部２０５は、ここで算出される集約適正度Ａが所定の値を上回る組み合わせパターンである場合には、その組み合わせパターンで集約データを生成する。データ集約部２０５は、所定の値を上回る組み合わせパターンが見つかり次第、その組み合わせパターンの送信予定データについて集約データを生成しても良い。データ集約部２０５は、所定の値を上回る組み合わせパターンを全て抽出した後に、集約適正度Ａが最も高い組み合わせのパターンの送信予定データから順に集約データを生成しても良い。データ集約部２０５は、この動作を所定の値を上回る組み合わせパターンが無くなるまで繰り返す。
【００７７】
次に、集約方法Ｃについて説明する。集約方法Ｃでは、許容遅延情報が現在時刻で示される送信予定データとその他の送信予定データを区別せずに、全ての組み合わせパターンで各集約データの集約効率Ｅ、送信優先度Ｑ、集約適正度Ａの計算を行う。以降の手順は、集約方法Ｂと同様であるため説明を省略する。
【００７８】
所定の集約適正度Ａとして例えば、「Ａ＝βＱ０」としてもよい。この場合、許容遅延情報が現在時刻で示される送信予定データを漏れ無く送信できる。なぜなら、許容遅延情報が現在時刻で示される送信予定データを含む集約データの集約適正度Ａは式（３）から「Ａ＝βＱ０」となるため、その集約データの送信優先度ＱはβＱ０より必ず大きな値で算出されるためである。
【００７９】
次に、第２通信端末１０２の内部動作を図８に示す。第２通信端末１０２は、まず、データ受信部５０１が外部から（この場合、第１通信端末１０１から）データを受信する。第２通信端末１０２は、その受信したデータから通信用ヘッダを取り除くことでアプリケーションデータを抽出する（ステップＳ７０１）。次に、データ解析部５０２が、アプリケーションデータのアプリケーションヘッダを解析する（ステップＳ７０２）。
【００８０】
次に、データ解析部５０２が、アプリケーションボディを処理可能な単位に分解する（分解方法については後述する）（ステップＳ７０３）。次に、データ処理部群５０５のデータ処理部５０５ｘが、ステップＳ７０２の解析結果に応じて、ステップＳ７０３で分解された各情報単位を処理する（ステップＳ７０４）。次に、第２通信端末１０２は、処理を終了する（ステップＳ７０５）。
【００８１】
ステップＳ７０３について具体的な例を説明する。アプリケーションボディの先頭の所定バイト数にその処理可能な単位のデータサイズが記載されている場合を想定する。この場合、第２通信端末１０２は、アプリケーションボディの先頭から前述の所定のバイト数に記載されるデータサイズだけ取り出す。ここで取り出すデータが処理可能な単位のデータとなる。第２通信端末１０２は、この動作をアプリケーションボディがなくなるまで繰り返し行う。
【００８２】
以上のように、第１の実施形態によれば、第１通信端末１０１から第２通信端末１０２までの通信メディアの帯域を効率的に利用できるようになる。なぜなら、第１通信端末１０１から第２通信端末１０２への送信予定データを集約することができるためである。
【００８３】
第１の実施形態において、各構成が次のような動作を行っても良い。
上記では、データ生成部群２０１を構成する各データ生成部２０１ｘが自身の識別子を渡す場合について説明したがこれに限られない。送信タイミング管理部２０２がデータ生成元の識別子を取得しても良い。
【００８４】
データ生成部群２０１を構成する各データ生成部２０１ｘは自信の識別子の代わりに許容遅延情報を、送信タイミング管理部２０２に渡しても良い。
【００８５】
データ生成部群２０１ｘを構成するデータ生成部２０１ｘは、複数種類の送信予定データを生成し、各データを個々のタイミングで送信しても良い。
【００８６】
また、送信タイミング管理部２０２は、データ集約部２０５に送信タイミングを通知する際に、更新のあったデータの識別子あるいは、許容遅延情報に基づいて送信タイミングを判断されるデータの識別子を、通知しても良い。このとき、データ集約部２０５は、通知のあるデータを基に集約データの生成を試行する、としても良い。
【００８７】
データ生成部群２０１は、第１通信端末１０１とは異なる通信端末上に有っても良い。
【００８８】
送信タイミング管理部２０２は、許容遅延情報記憶部２０３から送信予定データの許容遅延情報を取得する際に、データ生成部２０１ｘから受け取る送信予定データに含まれる情報を基に、許容遅延情報を取得しても良い。その場合、送信予定データに含まれる情報は、前述の宛先端末の識別子、アプリケーションヘッダ、アプリケーションボディ、あるいはそれらのデータの一部の情報である。ここで一部の情報の具体例は、宛先端末のＩＰアドレス、ＥＣＨＯＮＥＴにおけるＥＣＨＯＮＥＴサービス種別やＥＣＨＯＮＥＴプロパティコード、ＨＴＴＰにおけるＧＥＴ、ＰＯＳＴなどのリクエスト内容を示す情報を含む。
【００８９】
許容遅延情報記憶部２０３は、許容遅延情報として送信優先度Ｑを記憶しても良い。この場合、式（２）は、次の式（２ａ）のように変更される。すなわち、その他の送信予定データの送信優先度をＱ１、Ｑ２、・・・、Ｑｎと表記すると、集約データの送信優先度Ｑは次のように算出される。
【００９０】
Ｑ＝β（Ｑ１＋Ｑ２・・・＋Ｑｎ）  …式（２ａ）
【００９１】
データ生成部１０１が生成するアプリケーションデータを構成するアプリケーションボディは、複数のアプリケーションボディを有しても良い。この場合、複数のアプリケーションボディ各々の先頭から所定バイト数に各アプリケーションボディのデータサイズが記載される必要がある。
【００９２】
アプリケーションボディ処理方法記憶部５０４が記憶する処理方法は、アプリケーションボディを所定のサイズごとに分解する方法であっても良い。この場合、データ生成部２０１ｘは送信予定データを生成する際に、そのアプリケーションボディのデータサイズが等しいデータを生成する必要がある。
【００９３】
アプリケーションボディ処理方法記憶部５０４が記憶する処理方法は、アプリケーションボディの所定の位置に記載されるアプリケーションボディの分解方法に従い、アプリケーションボディを分解する方法であっても良い。この場合、第１通信端末１０１のデータ集約部２０５はアプリケーションボディを集約した後に、その先頭にその分解方法を含むデータを付与する必要がある。この分解方法の具体例は、集約対象の送信予定データの各データサイズの羅列が記載されることを含む。第２通信端末１０２のデータ解析部５０２はこの分解方法に記載のデータサイズに従い集約データのアプリケーションボディを分解する。
【００９４】
次に、図９から図１１Ｂを参照して本発明の第２の実施の形態について説明する。第２の実施形態は、上記第１の実施形態と比較して、送信予定データ記憶部が、待ち行列のデータ構造（すなわちキュー）を用いて送信予定データを記憶する点が異なっている。以下では、主に、第２の実施形態と、第１の実施形態で述べた構成及び動作との差分について説明する。
【００９５】
第２の実施の形態における第１通信端末１０１ａの構成例を図９に示す。第１通信端末１０１ａは、図１及び図２に示した第１通信端末１０１に対応する構成を有する。図９に示したデータ生成部群８０１は、図２に示したデータ生成部群２０１と対応する構成を有する。同様に、データ生成部８０１ｘは、データ生成部２０１ｘと対応する構成を有する。送信タイミング管理部８０２は、送信タイミング管理部２０２と対応する構成を有する。許容遅延情報記憶部８０３は、許容遅延情報記憶部２０３と対応する構成を有する。送信予定データ記憶部８０５は、送信予定データ記憶部２０４と対応する構成を有する。データ集約部８０６は、データ集約部２０５と対応する構成を有する。最大送信サイズ記憶部８０７は、最大送信サイズ記憶部２０６と対応する構成を有する。集約ポリシ記憶部８０４は、集約ポリシ記憶部２０７と対応する構成を有する。データ送信部８０８は、データ送信部２０８と対応する構成を有する。
【００９６】
送信タイミング管理部８０２は、データ生成部群８０１から送信予定データとデータ生成部８０１ｘの識別子を受け取る。送信タイミング管理部８０２は、許容遅延情報記憶部８０３から、データ生成部８０１ｘに関連する許容遅延情報として送信優先度を受け取る。送信タイミング管理部８０２は、集約ポリシ記憶部８０４から集約方法に関する情報を受け取る。集約ポリシと送信優先度を考慮して、送信タイミング管理部８０２は、送信予定データ記憶部８０５が有する送信キューｓｑに送信予定データを入れる（送信キューｓｑへの送信予定データの入れ方については後述する）。
【００９７】
集約ポリシとして、前述の[手順１Ａ]および[手順１Ｂ]に従い、許容遅延情報を送信優先度とする場合の、送信キューｓｑの構成例を図１０に示す。この送信キューＳＱは送信予定データ用であり、集約条件である端末の識別子が“端末Ａ”で、アプリケーションヘッダが“ＡＨ１”であり、送信優先度が“即時”である。
【００９８】
送信キューＳＱは、宛先端末の識別子とアプリケーションヘッダのセットと送信優先度ごとに用意される。送信キューＳＱは、宛先端末の識別子とアプリケーションヘッダのセットと、送信優先度との組み合わせに対応する複数組分用意される。このとき、該当する送信キューＳＱが無い場合は、送信予定データ記憶部８０５に新たに送信キューＳＱを作成し、その送信キューＳＱに送信予定データ（図１０において、符号Ｓｄで示す）を入れる。送信タイミング管理部８０２は送信予定データが更新されるときに、あるいは即時や高優先度の送信予定データが更新されるとき、あるいは所定の周期でデータ集約部にデータの集約を開始することを指示する。
【００９９】
許容遅延情報記憶部８０３は、データ生成部８０１ｘの識別子と送信優先度とを関連付けて記憶する。許容遅延情報記憶部８０３は、送信タイミング管理部８０２の要求に応じて、該当する送信優先度を送信タイミング管理部８０２に送る。送信優先度の具体例は、即時に送信すべきデータであることを示す情報、比較的高い優先度で送信すべきデータであることを示す情報、比較的低い優先度で送信すべきデータであることを示す情報を含む。
【０１００】
送信予定データ記憶部８０５は、図１０に示したように、宛先端末の識別子とアプリケーションヘッダと送信優先度ごとに用意される送信キューＳＱを用いて送信予定データを記憶する。その際、送信予定データ記憶部８０５は、送信タイミング管理部８０２の要求に応じて該当する送信キューＳＱで送信予定データを記憶する。送信キューＳＱは、例えばＦＩＦＯ（Ｆｉｒｓｔ  Ｉｎ  Ｆｉｒｓｔ  Ｏｕｔ）などのキューであってもよい。この場合、送信キューＳＱは、キューに蓄えられるデータの順に、そのデータが取り出されるように動作する。すなわち、送信予定データ記憶部８０５は、送信タイミング管理部８０２から受け取った送信予定データに含まれるアプリケーションデータを、そのアプリケーションデータの他のアプリケーションデータに対する送信順序の先後を示す情報（すなわち優先度）と、そのアプリケーションデータの宛先端末を示す情報（すなわち宛先端末の識別子）とに対応付けて用意されているいずれかの送信キューＳＱに、送信予定データとして記憶する。
【０１０１】
データ集約部８０６は、送信タイミング管理部８０２から送信予定データの集約指示を受ける。データ集約部８０６は、最大送信サイズ記憶部８０７から宛先までのアプリケーションボディの送信最大サイズを取得する。データ集約部８０６は、集約ポリシ記憶部８０４から集約方法に関する情報を取得する。データ集約部８０６は、集約方法と最大送信サイズを考慮して、送信予定データ記憶部の送信優先度の高い送信キューＳＱに蓄積される送信予定データから順に取り出して、集約データを生成する。集約データの生成方法としては、宛先端末の識別子とアプリケーションヘッダとが共通の送信キューＳＱごとにデータ集約を実施する（集約データの生成方法に関しては後述）。
【０１０２】
第１通信端末１０１ａの内部動作について、図６を参照して、上記第１の実施形態との差分を示すことで説明する。第１通信端末１０１ａは、図６におけるステップＳ６０３で、集約ポリシと最大送信サイズを考慮し、送信予定データ記憶部８０５の各送信キューＳＱから送信予定データを必要に応じて取り出し、集約データを生成する。図６におけるステップＳ６０３での集約データの集約方法を、集約方法Ｄとして説明する。
【０１０３】
集約方法Ｄ：
集約方法Ｄについて、図１１Ａ、図１１Ｂ、図１２、及び図１３を参照して説明する。図１１Ａは、送信予定データ記憶部８０５に設定される送信キューＳＱの構成例を示した図である。図１１Ａは、各送信キューＳＱに格納された送信予定データの例を示した図である。図１２及び図１３は、集約方法Ｄによる集約処理の流れを示したフローチャートである。図１２に示したフローと図１３に示したフロートは結合子Ｅで接続される。
【０１０４】
図１１Ａに示したように、集約方法Ｄでは、送信予定データ記憶部８０５に、送信キューＳＱとして、第１の送信キューＳＱ１、第２の送信キューＳＱ２、および第３の送信キューＳＱ３を用意する。第１の送信キューＳＱ１は、優先度が最も高い「即時」である送信予定データ用である。第２の送信キューＳＱ２は、優先度が２番目に高い「高優先」の送信予定データ用である。第３の送信キューＳＱ３は、優先度が最も低い「低優先」である送信予定データ用である。これらの送信キューＳＱ１〜３の送信予定データ各々（図１１Ａにおいて“（１）”〜“（５）”として示している）は、宛先端末の識別子（端末Ａ）とアプリケーションヘッダ（ＡＨ１）とが互いに同じである。図１１Ｂに示したように、データ（１）から（５）のアプリケーションボディは、それぞれＡＢ１、ＡＢ２、ＡＢ３、ＡＢ４、及びＡＢ５である。データ集約部８０６は、宛先端末の識別子とアプリケーションヘッダとが同じ送信予定データ用の複数の送信キューＳＱ１〜３を基に集約データを生成する。
【０１０５】
アプリケーションボディの最大送信サイズをＡＢｍａｘと表記する。
【０１０６】
ステップＤ−１１（図１２参照）：データ集約部８０６は、送信予定データ記憶部８０５内の第１送信キューＳＱ１に蓄積される送信予定データを参照する。
ステップＤ−１２：データ集約部８０６は、第１送信キューＳＱ１に蓄積される送信予定データの有無を判断する。データ集約部８０６は、第１送信キューＳＱ１に送信予定データが有ると判断した場合はステップＤ−２１へ進む。データ集約部８０６は、第１送信キューＳＱ１に送信予定データが無いと判断した場合はステップＤ−３１へ進む。図１１Ａに示した例では、データ（１）が第１送信キューＳＱ１に蓄積される送信予定データに該当する。
【０１０７】
ステップＤ−２１：データ集約部８０６は、これまで参照した送信予定データのアプリケーションボディの合計値が最大送信サイズを上回るかどうかを判定する。
データ集約部８０６は、合計値が最大送信サイズを上回らないと判断した場合（ステップＤ−２２：Ｎｏ）、その送信予定データを取り出して（ステップＤ−２３）、ステップＤ−１１へ進む。
データ集約部８０６は、合計値が最大送信サイズを上回ると判断した場合（ステップＤ−２２：Ｙｅｓ）、最後に参照したデータを除く、その他の送信予定データを元に集約データを生成する（ステップＤ−２４）。
【０１０８】
図１１Ａに示した例では、データ集約部８０６は、データ（１）のサイズが最大送信サイズを上回らないと判断し、データ（１）を取り出す。データ集約部８０６がステップＤ−１２を再度実施すると、第１送信キューＳＱ１が空であるためステップＤ−３１に進む。
【０１０９】
ステップＤ−３１：データ集約部８０６は、第２送信キューＳＱ２に蓄積されている送信予定データを参照する。
ステップＤ−３２：データ集約部８０６は、第２送信キューＳＱ２に蓄積される送信予定データの有無を判断する。データ集約部８０６は、第２送信キューＳＱ２に送信予定データが有ると判断した場合（ステップＤ−３２：Ｙｅｓ）はステップＤ−４１へ進む。データ集約部８０６は、第２送信キューＳＱ２に送信予定データが無いと判断した場合（ステップＤ−３２：Ｎｏ）はステップＤ−５１（図１３参照）へ進む。
【０１１０】
ステップＤ−４１〜Ｄ−４４：ステップＤ−２１〜Ｄ−２４と同様の処理を実施する。
【０１１１】
図１１Ａに示した例では、ステップＤ−３１及びＤ−４１を２回実施することで、データ（２）及びデータ（３）が取り出される。この場合、これまでに取り出した送信予定データのアプリケーションボディのサイズの合計値は、最大送信サイズに満たないと仮定する（ＡＢ１＋ＡＢ２＋ＡＢ３  ≦  ＡＢｍａｘ）。そのため、ステップＤ−３１が再度実施される。この時、第２送信キューＳＱ２が空であるため、処理がステップＤ−５１に進む。
【０１１２】
ステップＤ−５１：データ集約部８０６は、第３送信キューＳＱに蓄積される送信予定データを参照する。
ステップＤ−５２：データ集約部８０６は、第３送信キューＳＱに蓄積される送信予定データの有無を判断する。データ集約部８０６は、送信予定データが有ると判断した場合（ステップＤ−５２：Ｙｅｓ）はステップＤ−６１へ進む。データ集約部８０６は、送信予定データが無いと判断した場合（ステップＤ−５２：Ｎｏ）はステップＤ−７１へ進む。
【０１１３】
ステップＤ−６１〜Ｄ−６４：データ集約部８０６は、ステップＤ−２１〜Ｄ−２４及びステップＤ−４１〜Ｄ−４４と同様の処理を実施する。
【０１１４】
ステップＤ−７１：データ集約部８０６は、処理を終了する。
【０１１５】
図１１Ａに示した例では、ステップＤ−５１及びＤ−６１を２回実施することで、データ集約部８０６は、データ（４）を参照及び取り出すとともに、データ（５）を参照する。この場合、これまでの送信予定データのアプリケーションボディの合計値がデータ（５）を参照する時点で、最大送信サイズを超えると仮定する（ＡＢ１＋ＡＢ２＋ＡＢ３＋ＡＢ４＋ＡＢ５  ＞  ＡＢｍａｘ）。データ集約部８０６は、最後に参照したデータを除くその他の送信予定データ（データ（１）、（２）、（３）及び（４））を元に集約データを生成する。
【０１１６】
この集約方法Ｄにおいて、一つの送信予定データで最大送信サイズを上回る場合は、そのデータを集約せずに送信する。
【０１１７】
以降では、異なる「宛先端末の識別子とアプリケーションヘッダ」によって特定される複数の送信キューＳＱにおいてもステップＤ−１１〜Ｄ−６４と同様の処理を実施する。
【０１１８】
全ての送信キューＳＱについて処理を実施した時点でデータ集約部８０６は、処理を完了する。
【０１１９】
本第２の実施形態にかかる第１通信端末１０１ａによれば、各送信予定データの許容遅延時刻を意識することなく、送信予定データを集約できる。なぜなら、集約ポリシと送信優先度に基づいて用意される送信キューＳＱを利用するためである。これは、送信キューＳＱが蓄積される送信予定データが蓄積された順に取り出されるように動作するためである。
【０１２０】
次に、上記第１の実施形態における通信システムにおいて、通信端末１０１及び１０２間でＥＣＨＯＮＥＴ規定のメッセージを扱う場合の具体的な処理例について説明する。
【０１２１】
この処理例において用いる送信予定データの例を図１４に示す。送信予定データは大きく分けて、宛先端末の識別子と、アプリケーションヘッダ及びアプリケーションボディとを有する。この例では、宛先端末の識別子に、ＩＰアドレスが該当する。アプリケーションヘッダに、ＳＥＯＪ、ＤＥＯＪ、ＥＳＶが該当する。ＳＥＯＪは宛先ＥＣＨＯＮＥＴオブジェクトである。ＤＥＯＪは送信元ＥＣＨＯＮＥＴオブジェクトである。ＥＳＶはＥＣＨＯＮＥＴサービスである。ＥＰＣ、ＰＤＣ、ＥＤＴが、アプリケーションボディに該当する。ＥＰＣはＥＣＨＯＮＥＴプロパティコードである。ＰＤＣはプロパティデータカウンタである。ＥＤＴはＥＣＨＯＮＥＴデータである。
【０１２２】
ＥＣＨＯＮＥＴ規定により、データサイズは次の通りである。ＳＥＯＪのデータサイズは、３バイトである。ＤＥＯＪのデータサイズは、３バイトである。ＥＳＶのデータサイズは、１バイトである。ＥＰＣのデータサイズは、１バイトである。ＰＤＣのデータサイズは、１バイトである。ＥＤＴのデータサイズは、ＰＤＣの値で指定される任意のサイズである。
【０１２３】
データ（１）では、宛先端末の識別子として「ＩＰアドレス＝１０．１０．１０．１０」が指定されている。アプリケーションヘッダとして「ＳＥＯＪ＝０ｘ０５ＦＦ０１」、「ＤＥＯＪ＝０ｘ０２７Ｄ０１」、及び「ＥＳＶ＝０ｘ６０」が指定されている（ここで「０ｘ」は１６進数を表す接頭語である。）。アプリケーションボディとして「ＥＰＣ＝０ｘＥ０」、「ＰＤＣ＝０ｘ０４」、及び「ＥＤＴ＝０ｘ１０００００００（サイズは４バイト）」が割り当てられている。
データ（２）では、宛先端末の識別子として「ＩＰアドレス＝２０．２０．２０．２０」が指定されている。アプリケーションヘッダとして「ＳＥＯＪ＝０ｘ０５ＦＥ０１」、「ＤＥＯＪ＝０ｘ０２７９０１」、及び「ＥＳＶ＝０ｘ６１」が指定されている。アプリケーションボディとして「ＥＰＣ＝０ｘＥ５」、「ＰＤＣ＝０ｘ０１」、及び「ＥＤＴ＝０ｘ３３（サイズは１バイト）」が割り当てられている。
データ（３）では、宛先端末の識別子として「ＩＰアドレス＝１０．１０．１０．１０」が指定されている。アプリケーションヘッダとして「ＳＥＯＪ＝０ｘ０５ＦＦ０１」、「ＤＥＯＪ＝０ｘ０２７Ｄ０１」、及び「ＥＳＶ＝０ｘ６０」が指定されている。アプリケーションボディとして「ＥＰＣ＝０ｘＤ７」、「ＰＤＣ＝０ｘ０１」、及び「ＥＤＴ＝０ｘ００（サイズは１バイト）」が割り当てられている。
図１４に示した例では、データ（１）とデータ（３）とが、宛先端末の識別子とアプリケーションヘッダが同一のデータである。
【０１２４】
図１５に、送信予定データ記憶部２０４に記憶されている送信予定データを示す。データ（ｄ１）は、図１４に示したデータ（１）が許容遅延時刻「１２：００」（＝１２時００分）に関連付けられて記憶されたデータである。データ（ｄ２）は、図１４に示したデータ（２）が許容遅延時刻「１３：００」に関連付けられて記憶されたデータである。データ（ｄ３）は、図１４に示したデータ（３）が許容遅延時刻「１２：３０」に関連付けられて記憶されたデータである。データ（ｄ４）は、図１４では示していない新たなデータが、許容遅延時刻「１３：００」に関連付けられて記憶されたデータである。データ（ｄ４）は、図１４に示したデータ（１）及び（３）と同一の宛先端末の識別子とアプリケーションヘッダとを有している。データ（ｄ４）には、アプリケーションボディとして「ＥＰＣ＝０ｘＤ９」、「ＰＤＣ＝０ｘ０１」、及び「ＥＤＴ＝０ｘ００（サイズは１バイト）」が割り当てられている。
【０１２５】
集約ポリシは、次の[手順１Ｂ]及び[手順２Ｂ]で規定される。
[手順１Ｂ]：宛先端末のＩＰアドレス、ＳＥＯＪ、ＤＥＯＪ、ＥＳＶを共通の値とする送信予定データを抽出する。
[手順２Ｂ]：宛先端末のＩＰアドレス、ＳＥＯＪ、ＤＥＯＪ、ＥＳＶを共通化し、ＥＰＣ、ＰＤＣ、ＥＤＴをつなぎ合わせたデータを新たな集約データとする。
【０１２６】
データ送信部２０８が集約データを送信する場合、集約データには端末の識別子として送信元ＩＰアドレスやＵＤＰヘッダなどが付与される。集約データにはＥＣＨＯＮＥＴのアプリケーションヘッダとして、さらにＥＨＤ１、ＥＨＤ２、ＴＩＤ、ＯＰＣが追加される。ＥＨＤ１及びＥＨＤ２は、ＥＣＨＯＮＥＴ電文ヘッダ１及びＥＣＨＯＮＥＴ電文ヘッダ２である。ＴＩＤは、トランザクションＩＤである。ＯＰＣは、送信されるデータに含まれる、ＥＰＣ、ＰＤＣ、ＥＤＴのセット数である。
【０１２７】
通信帯域に関する情報すなわち最大送信サイズは、ＥＰＣ、ＰＤＣ、ＥＤＴの最大送信サイズ＝１００バイトであると仮定する。
【０１２８】
データ集約部２０５は、図７を参照して説明した集約方法Ａを用いて集約処理を実行する場合について説明する。現在時刻ｔが１２：００（＝１２時００分）である状態を想定する。
【０１２９】
図７に示したステップＡ−１１では、データ集約部２０５は、集約ポリシの[手順１Ｂ]に従い、宛先端末のＩＰアドレスとＳＥＯＪ、ＥＤＯＪ、ＥＳＶを共通とする送信予定データごとにグループ分けする。図１５に示した例では、データ（ｄ１）、（ｄ３）及び（ｄ４）が宛先端末のＩＰアドレスとＳＥＯＪ、ＥＤＯＪ、ＥＳＶとを共通としている。そのため、データ集約部２０５は、データｄ１からｄ４を２つのグループにグループ分けする。第１のグループはデータ（ｄ１）、（ｄ３）及び（ｄ４）を有する。第２のグループはデータ（ｄ２）を有する。
【０１３０】
次に、図７に示したステップＡ−２１で、データ集約部２０５が、第１のグループを選択する。
【０１３１】
次に、図７に示したステップＡ−３１で、データ集約部２０５は、第１のグループ内で、許容遅延時刻が現在時刻で指定される送信予定データを抽出する。この例の場合、データ（ｄ１）の許容遅延時刻が「１２：００」なので、データ集約部２０５は、データ（ｄ１）を抽出する。
【０１３２】
次に、図７に示したステップＡ−４１で、データ集約部２０５は、ステップＡ−３１で抽出したデータと、１つ以上のその他の送信予定データとを有する集約データの全組み合わせパターンに関して、集約効率Ｅ、送信優先度Ｑ、集約適正度Ａの計算を行う。集約効率Ｅは第１の実施形態における式（１）、式（２）を用いて算出する。
【０１３３】
ここで考えらえる組み合わせパターンは次のとおりである。
【０１３４】
組み合わせパターン（１）：データ（ｄ１）とデータ（ｄ３）
【０１３５】
組み合わせパターン（２）：データ（ｄ１）とデータ（ｄ４）
【０１３６】
組み合わせパターン（３）：データ（ｄ１）と、データ（ｄ３）、及びデータ（ｄ４）
【０１３７】
データ集約部２０５は、組み合わせパターン（１）〜（３）各々に関して、集約効率Ｅを計算する。
【０１３８】
データ（ｄ１）のアプリケーションボディのサイズは６バイト（１＋１＋４）である。同様の計算から、データ（ｄ３）及び（ｄ４）のアプリケーションボディのサイズは、で共に３バイトである。よって、組み合わせパターン（１）〜（３）各々は、式（１）の条件を満たす。
【０１３９】
次に式（１）を満たす組み合わせパターンの集約効率Ｅを第１の実施形態における式（２）を用いて算出する。ここでα＝１００として計算する。
【０１４０】
組み合わせパターン（１）のＥ＝１００＊（３）／１００＝３
【０１４１】
同様の計算から、組み合わせパターン（２）および（３）の集約効率Ｅは以下のように算出される。
組み合わせパターン（２）のＥ＝３
【０１４２】
組み合わせパターン（３）のＥ＝６
【０１４３】
次に式（１）を満たす組み合わせパターンの送信優先度Ｑを第１の実施形態における式（３）を用いて算出する。ここでβ＝１２０として計算する。
【０１４４】
組み合わせパターン（１）のＱ＝１２０＊（１／３０）＝４
【０１４５】
組み合わせパターン（２）のＱ＝１２０＊（１／６０）＝２
【０１４６】
組み合わせパターン（３）のＱ＝１２０＊（１／３０＋１／６０）＝６
【０１４７】
次に式（１）の条件を満たす組み合わせパターンの集約適正度Ａを第１の実施形態における式（４）を用いて算出する。
【０１４８】
組み合わせパターン（１）のＡ＝７
【０１４９】
組み合わせパターン（２）のＡ＝５
【０１５０】
組み合わせパターン（３）のＡ＝１２
【０１５１】
算出される集約適正度Ａが最大値を取る組み合わせパターンは、組み合わせパターン（３）であると判断される。データ集約部２０５は、集約データを組み合わせパターン（３）のデータの組、すなわち、データ（ｄ１）とデータ（ｄ３）とデータ（ｄ４）とを有するデータの組を集約データの構成データのパターンとして選択する。
【０１５２】
次に、データ集約部２０５は、集約ポリシの[手順２Ｂ]に従い組み合わせパターン（３）の送信予定データを集約する。データ集約部２０５によるデータ集約処理の結果、生成される集約データを図１６に示す。図１６に示す通り、生成された集約データは、「宛先端末のＩＰアドレス＝１０．１０．１０．１０」と、アプリケーションヘッダとして「ＳＥＯＪ＝０ｘ０５ＦＦ０１」、「ＤＥＯＪ＝０ｘ０２７Ｄ０１」、及び「ＥＳＶ＝０ｘ６０」とを格納する。さらに、生成された集約データは、アプリケーションボディとしてもともとはデータ（ｄ１）のアプリケーションボディである「ＥＰＣ＝０ｘＥ０」、「ＰＤＣ＝０ｘ０４」、及び「ＥＤＴ＝０ｘ１０００００００」を格納する。さらに、生成された集約データは、その後にデータ（ｄ３）のアプリケーションボディであった「ＥＰＣ＝０ｘＤ７」、「ＰＤＣ＝０ｘ０１」、及び「ＥＤＴ＝０ｘ００」を格納する。最後に、生成された集約データは、その後にデータ（ｄ４）のアプリケーションボディであった「ＥＰＣ＝０ｘＤ９」、「ＰＤＣ＝０ｘ０１」、及び「ＥＤＴ＝０ｘ００」を格納する。
【０１５３】
上記各実施形態における通信システム１００は、通信網の最大送信サイズよりも小さいサイズのデータを異なる通信装置に送信する通信装置に適用できる。具体的には、通信システム１００は、通信サーバや中継サーバなどに適用できる。
【０１５４】
本発明の各実施の形態は、上記の構成及び動作に限定されない。例えば、図２、図５及び図９に示した構成例における各ブロックを分割したり、分散したり、統合したりすることができる。図２、図５及び図９に示した構成例は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）とそのＣＰＵで実行されるプログラムとを用いて構成することができる。その場合のプログラムは、コンピュータ読み取り可能な記録媒体や通信回線を介して流通させることができる。
【０１５５】
上記第１の実施形態と第２の実施形態とを包含する本発明の基本的な実施の形態を、図１７に示す。図１７に示したように、本発明の基本的な実施形態としての通信装置１０００は、送信予定データ記憶部１００１と、データ集約部１００２と、データ送信部１００３と、を備える。送信予定データ記憶部１００１は、送信順序を示す送信順序情報（アプリケーションデータの送信順序の先後を示す情報）と送信先である宛先端末を示す宛先情報とにそれぞれ対応付けられている複数のアプリケーションデータを記憶する。送信予定データ記憶部１００１は、前記複数のアプリケーションデータから、互いに同一の宛先情報と対応付けられている複数のアプリケーションデータを抽出する。送信予定データ記憶部１００１は、データサイズの上限値を示す最大送信サイズと前記送信順序情報に基づき、前記抽出された複数のアプリケーションデータから集約対象の複数のアプリケーションデータを抽出する。送信予定データ記憶部１００１は、前記集約対象の複数のアプリケーションデータに基づいて前記同一の宛先情報が割り当てられた集約データを生成する。データ送信部１００３は、前記集約データを、前記割り当てられた宛先情報によって示される宛先端末に送信する。
【０１５６】
送信予定データ記憶部１００１は、図２の送信予定データ記憶部２０４及び図９の送信予定データ記憶部８０５に対応している。データ集約部１００２は、図２のデータ集約部２０５及び図９のデータ集約部８０６に対応している。データ送信部１００３は、図２のデータ送信部２０８及び図９のデータ送信部８０８に対応している。
【０１５７】
なお、上記の実施形態の一部又は全部は、以下の付記のようにも記載され
うるが、以下には限られない。
【０１５８】
［付記１］
通信システムは、集約方法記憶部と、集約データ決定部と、データ集約部と、通信部と、を備える。
集約方法記憶部は、データ受信側の通信端末が処理可能なデータ集約方法を記憶する。
集約データ決定部は、宛先端末の識別子と前記データ集約方法と最大送信サイズに基づいて１つ以上のアプリケーションデータのうち１つ以上のアプリケーションデータから構成される組み合わせを集約対象として決定する。
データ集約部は、前述の集約対象として決定される１つ以上のアプリケーションデータを前記データ集約方法で集約することで新たなアプリケーションデータを生成する。
通信部は、前記集約データを前記端末の識別子を元に送信する。
【０１５９】
［付記２］
前記集約データ決定部は、さらにアプリケーションデータごとの送信優先順位に関わる情報に基づいてアプリケーションデータの組み合わせを集約対象として決定する。
【０１６０】
［付記３］
前記集約データ決定部は、前記最大送信サイズに対する前記データ集約方法に基づいて生成される集約データのサイズの比率が大きいアプリケーションデータの組み合わせを集約対象として決定する。
【０１６１】
［付記４］
前記集約データ決定部は、さらにアプリケーションデータごとの送信優先順位に関わる情報に基づいてアプリケーションデータの組み合わせごとの送信順序に関する優先度を決定し、その優先度が大きい値を持つ組み合わせを集約対象として決定する。
【０１６２】
［付記５］
前記集約データ決定部は、前記最大送信サイズに対する前記データ集約方法に基づいて生成される前記集約データのサイズの比率と、前記アプリケーションデータの組み合わせごとの送信順序に関する優先度の加重平均値の大きい値を持つ組み合わせを集約対象として決定する。
【０１６３】
［付記６］
前記アプリケーションデータは、送信優先順位に関わる情報ごとに異なる送信キューに蓄積される。前記集約データ決定部は、送信優先順位の高い送信キューから低い送信キューの順番で各送信キューに蓄積されるアプリケーションデータを取り出し、最大送信サイズに収まるような集約対象を決定する。
【０１６４】
［付記７］
前記データ集約方法とは、宛先端末の識別子と、前記アプリケーションデータを構成するアプリケーションヘッダのうち少なくとも一つ以上の情報とを、共通の値として持つ１つ以上の前記アプリケーションデータを用いて、宛先端末の識別子と、前記アプリケーションデータを構成するアプリケーションヘッダのうち少なくとも一つ以上の情報を共通化して、アプリケーションデータを構成するアプリケーションボディを集約することで新たなアプリケーションデータを生成する方法である。
【０１６５】
［付記８］
前記アプリケーションヘッダとは、アプリケーションデータの先頭に付与される情報であり、ＥＣＨＯＮＥＴにおけるＥＨＤ、ＴＩＤ、ＤＥＯＪ、ＳＥＯＪ、ＥＳＶ、ＯＰＣのいずれか一つ以上の情報であり、ＨＴＴＰにおけるメッセージヘッダである。
前記アプリケーションボディとは、アプリケーションデータからヘッダ情報を除いたデータ本体の情報であり、ＥＣＨＯＮＥＴにおけるＥＰＣ、ＰＤＣ、ＥＤＴのいずれか一つ以上の情報であり、ＨＴＴＰにおけるメッセージボディである。
【０１６６】
［付記９］
通信システムは、送信側の通信装置と受信側の通信装置と、それらを接続するネットワークとを備える。
前記送信側の通信装置は、集約方法記憶部と、集約データ決定部と通信部とを備える。
集約方法記憶部は、データ第２通信端末が処理可能なデータ集約方法を記憶する。集約データ決定部は、宛先端末の識別子と前記データ集約方法と最大送信サイズに基づいて１つ以上のアプリケーションデータのうち１つ以上の前記アプリケーションデータから構成される組み合わせを集約対象として決定する。
通信部は、前述の集約対象として決定される１つ以上の前記アプリケーションデータを前記データ集約方法で集約することで新たなアプリケーションデータを生成するデータ集約手段と、前記集約することで生成される新たなアプリケーションデータを前記端末の識別子を元に送信する。
前記ネットワークは、送信側の通信装置から送信される前記アプリケーションデータを前記受信側の通信装置に伝送する。
前記受信側の通信装置は、受信部と集約データ処理部とを備える。
受信部は、前記集約することで生成される新たなアプリケーションデータを前記送信側の通信装置から受信する。
集約データ処理部は、前記送信側の通信装置が記憶する前記処理可能なデータ集約方法に対応するデータの解析方法を用いて、前記集約することで生成される新たなアプリケーションデータを処理する。
【０１６７】
［付記１０］
前記最大送信サイズとは、宛先の通信端末までのＭＴＵ（Ｍａｘｉｍｕｍ  Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｕｎｉｔ）である。
【０１６８】
［付記１１］
前記アプリケーションデータは、１つ以上のアプリケーションにより生成されるデータである。
【０１６９】
［付記１２］
前記集約データ決定部は、前記アプリケーションデータが更新されるタイミング、あるいは所定の周期で処理を開始する。
【０１７０】
［付記１３］
前記データ集約方法とは、宛先端末の識別子と、前記アプリケーションデータを構成するアプリケーションヘッダのうち少なくとも一つ以上の情報とを、共通の値として持つ１つ以上の前記アプリケーションデータを用いて、宛先端末の識別子と、前記アプリケーションデータを構成するアプリケーションヘッダのうち少なくとも一つ以上の情報を共通化して、アプリケーションデータを構成するアプリケーションボディを集約することで新たなアプリケーションデータを生成する方法である。
前記データ集約方法に対応するデータの解析方法とは、前記集約することで新たに生成されるアプリケーションデータを構成するアプリケーションヘッダの情報から処理方法を決定し、前記集約することで新たに生成されるアプリケーションデータを構成するアプリケーションボディを所定の方法に従い分解する方法である。
【０１７１】
［付記１４］
前記集約することで新たに生成されるアプリケーションデータを構成するアプリケーションボディを分解する所定の方法とは、アプリケーションボディをあらかじめ設定されるデータサイズごとに分解する、あるいはアプリケーションボディの所定の位置に記載される分解方法に従い分解する、あるいはアプリケーションボディの先頭から数バイトに記載される分解後のデータサイズを参照し、さらにアプリケーションボディの先頭から前述データサイズを取り出す、さらに以降は同じ動作をアプリケーションボディが無くなるまで繰り返す方法である。
【０１７２】
［付記１５］
前記集約データ決定部は、前記送信順序情報に基づき、抽出した前記アプリケーションデータのうち送信順序が先である複数の前記アプリケーションデータを判定し、送信順序が先である複数の前記アプリケーションデータと、これら複数の前記アプリケーションデータに共通の前記宛先情報とを含む前記集約データを生成する。
【０１７３】
この出願は、２０１２年６月８日に出願された日本国特願２０１２−１３０９９８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【０１７４】
本発明は、通信網の最大送信サイズよりも小さいサイズのデータを異なる通信装置に送信する通信装置に適用し得る。
【符号の説明】
【０１７５】
１００  通信システム
１０１  第１通信端末
１０２  第２通信端末
１０３  ネットワーク
２０１及び８０１  データ生成部群
２０２及び８０２  送信タイミング管理部
２０３及び８０３  許容遅延情報記憶部
２０４及び８０５  送信予定データ記憶部
２０５及び８０６  データ集約部
２０６及び８０７  最大送信サイズ記憶部
２０７及び８０４  集約ポリシ記憶部
２０８及び８０８  データ送信部
５０１  データ受信部
５０２  データ解析部
５０３  アプリケーションヘッダ解析方法記憶部
５０４  アプリケーションボディ処理方法記憶部
５０５  データ処理部群
【図１】
2013183649.tif 000003
【図２】
2013183649.tif 000004
【図３】
2013183649.tif 000005
【図４】
2013183649.tif 000006
【図５】
2013183649.tif 000007
【図６】
2013183649.tif 000008
【図７】
2013183649.tif 000009
【図８】
2013183649.tif 000010
【図９】
2013183649.tif 000011
【図１０】
2013183649.tif 000012
【図１１Ａ】
2013183649.tif 000013
【図１１Ｂ】
2013183649.tif 000014
【図１２】
2013183649.tif 000015
【図１３】
2013183649.tif 000016
【図１４】
2013183649.tif 000017
【図１５】
2013183649.tif 000018
【図１６】
2013183649.tif 000019
【図１７】
2013183649.tif 000020
【国際調査報告】
2013183649.tif 000021
2013183649.tif 000022
2013183649.tif 000023
2013183649.tif 000024