(57)【特許請求の範囲】
【請求項１】
受信したデータを集約して、１つのリクエストとして送信する装置であって、
データ受領部と、データ送信部と、バッファと、集約条件決定部とを備え、
前記データ受領部が、データを受信し、
前記データ送信部が、前記データ受領部によって受信されたデータを前記バッファに蓄積し、
前記データ送信部が、データサイズに基づいて設定された第１の集約条件と、時間長さとして設定された第２の集約条件とのうちの少なくとも１つを集約条件に用い、前回のリクエストの送信後に前記データ受領部によって受信されたすべてのデータを累積しても、前記第１の集約条件を満たさず、前記前回のリクエストの送信後に前記データ受領部によってデータの受信が開始されてからの時間長さが、前記第２の集約条件に達していないと判定すると、前記データ受領部が、後続するデータを受信することと、前記データ送信部が、前記データ受領部によって受信されたデータを前記バッファに蓄積することとを継続し、
前記集約条件決定部が、前記第１の集約条件を、前記データの受信に適用された通信プロトコルで決定される一度に送信可能なデータサイズと、前記送信されたリクエストの各データのデータサイズの平均値および標準偏差に基づいて動的に設定し、前記第２の集約条件を、過去一定期間、データを集約せずに送信した際の各データの送信所要時間の平均値に基づいて動的に設定し、
前記データ送信部が、前記第１の集約条件が満たされるか、または前記第２の集約条件に達していると判定すると、前記データ送信部が、前記バッファに蓄積されたデータを集約して、１つのリクエストとして送信する、装置。
【請求項２】
受信したデータを集約して、１つのリクエストとして送信する方法であって、
データを受信してバッファに蓄積し、
データサイズに基づいて設定された第１の集約条件と、時間長さとして設定された第２の集約条件とのうちの少なくとも１つを集約条件に用い、前回のリクエストの送信後に受信されたすべてのデータを累積しても、前記第１の集約条件を満たさず、前記前回のリクエストの送信後にデータの受信が開始されてからの時間長さが、前記第２の集約条件に達しない間は、後続するデータの受信および蓄積を継続し、
前記第１の集約条件を、前記データの受信に適用された通信プロトコルで決定される一度に送信可能なデータサイズと、前記送信されたリクエストの各データのデータサイズの平均値および標準偏差に基づいて動的に設定し、前記第２の集約条件を、過去一定期間、データを集約せずに送信した際の各データの送信所要時間の平均値に基づいて動的に設定し、
前記第１の集約条件が満たされるか、または前記第２の集約条件に達した場合、前記バッファに蓄積されたデータを集約して、１つのリクエストとして送信する、方法。
【請求項３】
受信したデータを集約して、１つのリクエストとして送信するためのプログラムであって、
コンピュータに、
データを受信してバッファに蓄積させる機能と、
データサイズに基づいて設定された第１の集約条件と、時間長さとして設定された第２の集約条件とのうちの少なくとも１つを集約条件に用い、前回のリクエストの送信後に受信されたすべてのデータを累積しても、前記第１の集約条件を満たさず、前記前回のリクエストの送信後にデータの受信が開始されてからの時間長さが、前記第２の集約条件に達しない間は、後続するデータの受信および蓄積を継続する機能と、
前記第１の集約条件を、前記データの受信に適用された通信プロトコルで決定される一度に送信可能なデータサイズと、前記送信されたリクエストの各データのデータサイズの平均値および標準偏差に基づいて動的に設定し、前記第２の集約条件を、過去一定期間、データを集約せずに送信した際の各データの送信所要時間の平均値に基づいて動的に設定する機能と、
前記第１の集約条件が満たされるか、または前記第２の集約条件に達した場合、前記バッファに蓄積されたデータを集約して、１つのリクエストとして送信する機能と、
を実現させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信したデータを集約し、１つのリクエストとして送信するためのデータ集約装置、方法、およびプログラムに関するものである。
【背景技術】
【０００２】
従来、例えばゲートウェイ（以下、「ＧＷ」と称する）のように、デバイスからデータを受信し、受信したデータを集約して、１つのリクエストとして、他のデバイスへ送信するデータ集約装置が知られている。
【０００３】
この種のデータ集約装置の一例であるＧＷ  １００を、図７の機能ブロック図および図８の動作シーケンス図を用いて説明する。
【０００４】
すなわち、ＧＷ  １００は、デバイス１１０から送られたデータを受信すると、これら受信したデータを、一定のデータサイズ長毎に集約して、１つのリクエストとして、他のデバイスのデータ受信部１２０へ送信するための装置である。
【０００５】
このようなＧＷ  １００には、送信データ受領部１０２と、データ送信部１０４と、バッファ１０６と、集約閾値蓄積部１０８とが備えられている。
【０００６】
集約閾値蓄積部１０８には、予め定められた集約閾値が格納されており、この集約閾値は、集約閾値蓄積部１０８からデータ送信部１０４へ通知される（Ｓ２００）。集約閾値とは、デバイス１１０から送信されたデータを、集約してデータ受信部１２０へ送信するための集約量のことであって、例えばバイト数のようなデータサイズ長で設定される。
【０００７】
デバイス１１０から送信されたデータは、送信データ受領部１０２によって受信され（Ｓ２０２）、データ送信部１０４へ送られる（Ｓ２０４）。
【０００８】
データ送信部１０４では、ステップＳ２０４で送られたデータのサイズが累積カウントされるとともに、ステップＳ２０４で送られたデータが、バッファ１０６へ送られ、バッファ１０６に蓄積される（Ｓ２０６）。
【０００９】
データ送信部１０４では、累積カウントされたデータのサイズが、ステップＳ２００で通知された集約閾値を超えていなければ、まだ集約はなされず、デバイス１１０からの次のデータの受信が継続され、ステップＳ２０２〜Ｓ２０６の処理が繰り返される（Ｓ２０８）。
【００１０】
そして、例えば、デバイス１１０からのｎ回目のデータ受信時（ただし、ｎは、１以上の整数）に、データ送信部１０４によって、累積カウントされたデータのサイズが、集約閾値を超えたと判定されると、それまでにバッファ１０６に蓄積されていたデータが、データ送信部１０４によって取得され（Ｓ２１０）、１つのリクエストとして集約されて、データ送信部１０４から、データ受信部１２０へと送信される（Ｓ２１２）。
【先行技術文献】
【非特許文献】
【００１１】
【非特許文献１】oneM2M TS-0001-V1.6.1 Annex D.12 pp.289-308
【発明の概要】
【発明が解決しようとする課題】
【００１２】
しかしながら、このような従来のデータ集約装置では、以下のような問題がある。
【００１３】
すなわち、前述したように、デバイス１１０から送信されたデータを、１つのリクエストとして集約して送信する場合、集約量を定義する集約閾値は、データの内容や傾向に関わらず、常に固定された一定のデータサイズ長（たとえば、Ｍバイト）で設定されている。
【００１４】
そのため、データが、早急に送信を要する内容のものであっても、集約閾値で定義されたデータサイズまでデータが累積されなければ、データ送信部１０４からデータ受信部１２０へのリクエストの送信は開始されない。
【００１５】
これによって、従来のデータ集約装置１００では、データ送信部１０４からデータ受信部１２０へリクエストの送信が開始されるまでに、時間がかかりすぎ、それによって不都合が生じる場合があるという問題がある。
【００１６】
本発明はこのような事情に鑑みてなされたものであり、データを集約してリクエストを送信する場合であっても、適切なタイミングでリクエストを送信することが可能なデータ集約装置、方法、およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１７】
上記目的を達成するためにこの発明の第１の観点は、以下のような構成要素を備えている。
【００１８】
すなわち、本発明の第１の観点は、データを受信してバッファに蓄積する。そして、データサイズに基づいて設定された第１の集約条件と、時間長さとして設定された第２の集約条件とのうちの少なくとも１つを集約条件に用い、前回のリクエストの送信後に受信されたすべてのデータを累積しても、第１の集約条件を満たさず、前回のリクエストの送信後にデータの受信が開始されてからの時間長さが、第２の集約条件に達しない間は、後続するデータの受信および蓄積を継続する。第１の集約条件は、データの受信に適用された通信プロトコルで決定される一度に送信可能なデータサイズと、送信されたリクエストの各データのデータサイズの平均値および標準偏差に基づいて動的に設定され、第２の集約条件は、過去一定期間、データを集約せずに送信した際の各データの送信所要時間の平均値に基づいて動的に設定される。そして、第１の集約条件が満たされるか、または第２の集約条件に達している場合、バッファに蓄積されたデータを集約して、１つのリクエストとして送信する。
【発明の効果】
【００２１】
すなわちこの発明によれば、データを集約してリクエストを送信する場合であっても、適切なタイミングでリクエストを送信することが可能となるので、リクエストの送信が開始されるまでに、時間がかかりすぎ、それによって不都合が生じることを回避することが可能となる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態に係るデータ集約方法が適用されたデータ集約装置の構成例を示す機能ブロック図である。
【図２】同データ集約装置の動作例を示す動作シーケンス図である。
【図３】データ受信履歴・データサイズ履歴記録部のデータ構造の一例を示す図である。
【図４】第１の集約条件に従うデータ集約を説明するための図である。
【図５】第２の集約条件の算出方法を説明するための図である。
【図６】第２の集約条件に従って決定された「時間長」閾値を説明するための図である。
【図７】従来のデータ集約装置の一例であるゲートウェイの構成例を示す機能ブロック図である。
【図８】同ゲートウェイの動作例を示す動作シーケンス図である。
【発明を実施するための形態】
【００２３】
以下に、本発明を実施するための最良の形態について図面を参照しながら説明する。
【００２４】
図１は、本発明の実施形態に係るデータ集約方法が適用されたデータ集約装置１０の構成例を示す機能ブロック図である。
【００２５】
すなわち、本実施形態に係るデータ集約方法が適用されたデータ集約装置１０は、デバイス３０から送られたデータを受信すると、これら受信したデータを集約して、１つのリクエストとして、他のデバイスのデータ受信部４０へ送信するための装置である。従来技術では、固定された一定のデータサイズ長が、データの集約閾値として用いられていたが、本実施形態では、データサイズ長に基づいて設定された第１の集約条件と、データの受信時間長によって設定された第２の集約条件とに基づいてデータの集約を行う。しかも、従来技術では、集約閾値は固定値であったが、本実施形態では、第１の集約条件、および第２の集約条件ともに、送信されたリクエストの各データの受信実績に応じて動的に設定される。本実施形態に係るデータ集約方法が適用されたデータ集約装置１０は、このような構成によって、データを集約して、１つのリクエストとして送信する場合であっても、適切なタイミングで送信することを可能としている。
【００２６】
このような機能を実現するために、データ集約装置１０は、送信データ受領部１２と、データ送信部１４と、バッファ１６と、集約条件蓄積部１８と、データ受信履歴・データサイズ履歴記録部２０と、集約条件決定部２２とを備えている。
【００２７】
これら各部位の構成を、図２の動作シーケンス図を用いて説明する。
【００２８】
集約条件蓄積部１８は、リクエストに集約された各データのデータサイズ長に基づいて設定された第１の集約条件と、リクエストに集約された各データの受信時間長によって設定された第２の集約条件とを格納している。データ送信部１４は、このような第１の集約条件および第２の集約条件を、次のリクエストのためのデータ集約のために、集約条件蓄積部１８から取得する（Ｓ５０）。
【００２９】
集約条件とは、デバイス３０から送信されたデータを、１つのリクエストとして集約するための条件のことである。本実施形態では、後述するステップＳ６６〜Ｓ７０で説明されるように、データ受信履歴・データサイズ履歴記録部２０と集約条件決定部２２が、リクエストに集約された各データの受信実績に応じて、第１の集約条件および第２の集約条件を動的に更新し、次のリクエストのためのデータ集約のために、集約条件蓄積部１８に蓄積する。したがって、本実施形態に係るデータ集約装置１０を最初に利用する際には、デフォルト値として設定された、第１の集約条件および第２の集約条件を用いる。
【００３０】
送信データ受領部１２は、デバイス３０から送信されたデータを、デバイス３０の識別番号（デバイスＩＤ）ａ、このデータ送信に使用された通信プロトコルｂとともに受信する（Ｓ５２）。さらに、このデータを受信した受信時刻ｃ、このデータのデータサイズｄ、およびこのデータ送信の所要時間ｅを、デバイスＩＤａおよび通信プロトコルｂに加えて、データとともに、データ送信部１４へ送る（Ｓ５４）。
【００３１】
データ送信部１４は、送信データ受領部１２から送られたデータを、バッファ１６へ送る（Ｓ５６）。データ送信部１４はまた、送信データ受領部１２から送られたデバイスＩＤ  ａ、通信プロトコルｂ、データの受信時刻ｃ、データサイズｄ、およびデータ送信所要時間ｅを、データ受信履歴・データサイズ履歴記録部２０へ送る（Ｓ５８）。データ送信部１４はさらに、データサイズｄを累積する。
【００３２】
バッファ１６は、ステップＳ５６においてデータ送信部１４から送られたデータを蓄積する。
【００３３】
データ受信履歴・データサイズ履歴記録部２０は、ステップＳ５８においてデータ送信部１４から送られたデバイスＩＤ  ａ、通信プロトコルｂ、データの受信時刻ｃ、データサイズｄ、およびデータ送信所要時間ｅを紐付けて記録する。図３は、これらデータが紐付けられて記録されたデータ受信履歴・データサイズ履歴記録部２０のデータ構造の一例を示す図である。
【００３４】
一定期間、データの集約を行わずに送信されたデータより得られ、データ受信履歴・データサイズ履歴記録部２０に蓄積されたデータ送信情報より、集約条件決定部２２は、データ受信履歴・データサイズ履歴記録部２０から、データの受信時刻および送信所要時間（例えば、年月日時分秒）からなるデータ受信履歴を取得する（Ｓａ０１）。
【００３５】
さらに、集約条件決定部２２は、ステップＳａ０１で取得されたデータ受信履歴に基づいて、第２の集約条件を決定する（Ｓａ０２）。
【００３６】
そして、集約条件決定部２２は、このようにして決定した第２の集約条件を、集約条件蓄積部１８に送る（Ｓａ０３）。
【００３７】
データ送信部１４は、累積されたデータサイズと、第１の集約条件とを比較する。また、累積されたデータ送信所要時間と、第２の集約条件とを比較する。そして、データ送信部１４は、第１の集約条件も満たされず、第２の集約条件にも達していないと判定すると、まだデータの集約を行わず、送信データ受領部１２が、デバイス３０からの次のデータを受信し、ステップＳ５２〜Ｓ５８の処理を繰り返す（Ｓ６０）。
【００３８】
一方、例えば、デバイス３０からのＮ回目のデータ受信時（ただし、Ｎは、１以上の整数）において、データ送信部１４が、第１の集約条件を満たすか、または第２の集約条件に達したと判定すると、データ送信部１４は、それまでにバッファ１６に蓄積されていたデータを取得し（Ｓ６２）、これら取得したデータを１つのリクエストとして集約して、データ受信部４０へと送信する（Ｓ６４）。
【００３９】
ステップＳ６４の後、集約条件決定部２２が、データ受信履歴・データサイズ履歴記録部２０から、ステップＳ６０の間に記録されたデータの受信時刻および送信所要時間（例えば、年月日時分秒）ならびにデータサイズ（例えば、バイト数）からなるデータ受信履歴を取得する（Ｓ６６）。
【００４０】
さらに、集約条件決定部２２は、ステップＳ６６で取得されたデータ受信履歴に基づいて、新たな第１の集約条件を決定する（Ｓ６８）。
【００４１】
そして、集約条件決定部２２は、このようにして決定した第１の集約条件を、集約条件蓄積部１８に送る（Ｓ７０）。
【００４２】
集約条件蓄積部１８は、蓄積している第１の集約条件を、集約条件決定部２２から送られた第１の集約条件で上書きすることによって、第１の集約条件を更新する。これら更新された第１の集約条件は、次のリクエストのためのデータ集約のために使用される。
【００４３】
その後、次のリクエストのためのデータ集約のために、ステップＳ５０〜Ｓ６４までの処理が実施され、データ送信部１４が、更新された第１の集約条件および第２の集約条件に基づいて、データを１つのリクエストとして集約し、データ受信部４０へ送る。さらにその後、ステップＳ６６〜Ｓ７０までの処理を実施し、第１の集約条件の更新を行う。このような処理を繰り返すことによって、集約条件決定部２２が、リクエストに集約された各データの受信実績に応じて、第１の集約条件を動的に更新し、次のリクエストのためのデータ集約のために、集約条件蓄積部１８に蓄積する。その後、リクエストに集約され送信されたデータが、バッファ１６から削除され、次のリクエストのためのデータを受信する準備がなされる。
【００４４】
以下に、ステップＳ６８でなされる新たな第１の集約条件およびステップＳａ０２でなされる第２の集約条件の算出方法、およびデータ送信部１４においてなされる、第１の集約条件を満たしているか否か、および第２の集約条件に達しているか否かの判定方法について説明する。
【００４５】
第１の集約条件は、通信プロトコルｂで決定される「一度に送信可能なデータサイズ」を超えるデータの受信を待つことにより発生する、「データ集約のために次のデータの受信を待つことで時間を要し、データ送信に遅延が発生すること」を極力避けるために設定された条件である。このような第１の集約条件を決定するために、集約条件決定部２２は、データ受信履歴・データサイズ履歴記録部２０に記録されたデータサイズｄの平均値μと標準偏差σを算出する。
【００４６】
データ送信部１４は、前述したように、送信されたデータサイズｄを累積するが、例えば図４に示す蓄積データ１、２、３、４のように、通信プロトコルｂで決定される「一度に送信可能なデータサイズｆ」に達するまでは、第１の集約条件を満たしていないと判定し、受信したデータをバッファ１６に蓄積する。しかしながら、蓄積データ４を受信した時点で、その後、μ＋３σのデータサイズを有するデータ５を受信することによって、「一度に送信可能なデータサイズの上限ｆ」を超えることが見込まれる場合には、第1の集約条件を満たすと判定し、それまでに蓄積されているデータ１〜４を１つのリクエストとして集約し、送信する。
【００４７】
このように、第１の集約条件は、通信プロトコルｂで決定される「一度に送信可能なデータサイズｆ」と、データ受信履歴・データサイズ履歴記録部２０に記録されたデータサイズｄの平均値μおよび標準偏差σから決定される。
【００４８】
第２の集約条件は、デバイス３０から送信されるデータの受信間隔が長くなった場合に、データ集約のために次のデータの受信を待つことで時間を要し、データ送信に遅延が発生してしまうことを極力避けるために設定された条件である。このために、データ送信所要時間ｅの平均値よりも短い時間間隔で受信したデータを、１つに集約して送信した方が効率的であるとの考えの下、「時間長」閾値として第２の集約条件を決定している。
【００４９】
このために、集約条件決定部２２が、先ず、データ受信履歴・データサイズ履歴記録部２０に記録されたデータ送信所要時間ｅをもとに、送信データ受領部１２によって受信された各データのデータ送信所要時間ｅの平均値を算出する。集約条件決定部２２はさらに、データ受信履歴・データサイズ履歴記録部２０に記録されたデータ受信時刻ｃをもとに、送信データ受領部１２によってデータが受信された時点から、次のデータが受信された時点までの間隔が、データ送信所要時間ｅの平均値よりも短い場合、これら２つのデータを「集約したほうがよいデータ群」と判定する。
【００５０】
例えば、指定された期間のデータ送信所要時間ｅの平均値が、１２０ミリ秒（ｍｓ）であったとする。一方、図５（ａ）に示すように、前回のリクエストに集約されたデータのうち、データＸが受信された時点ｔ１から、次のデータＹが受信された時点ｔ２までの間隔が、１００（ｍｓ）であり、前述したデータ送信所要時間ｅの平均値である１２０（ｍｓ）よりも短い場合、データＸとデータＹとを、「集約したほうがよいデータ群」と判定する。
【００５１】
集約条件決定部２２はさらに、このようにして得られた「集約したほうがよいデータ群」の一番古いデータであるデータＸの受信時刻ｔ１と、一番新しいデータであるデータＹの次のデータであるデータＺの受信時刻ｔ３との差分が最も長い時間長を、第２の集約条件とする。すなわち、第２の集約条件は、このような「時間長」閾値である。図５（ｂ）は、この「時間長」閾値が、２１５（ｍｓ）である例を示す図である。
【００５２】
データ送信部１４は、図６に示すように、直前のデータ送信後、次にデータを受信した時刻から、この「時間長」だけ待ち、その間に得られた全てのデータを集約し、１つのリクエストとして送信する。
【００５３】
図１に図示されるように、デバイス３０とデータ受信部４０との間にデータ集約装置１０を配置するネットワーク構成は、イーサネット（登録商標）等のＬＡＮ、あるいは公衆回線や専用回線を介して複数のＬＡＮが接続されるＷＡＮ等からなる。ＬＡＮの場合には、必要に応じてルータを介した多数のサブネットから構成される。また、ＷＡＮの場合には、公衆回線に接続するためのファイアウォール等を適宜備えているが、ここではその図示及び詳細説明を省略する。
【００５４】
また、データ集約装置１０は、例えば磁気ディスク等の記録媒体に記録されたプログラムや、インターネット等の通信ネットワークを介してダウンロードしたプログラムを読み込み、このプログラムによって動作が制御されるコンピュータによって実現される。
【００５５】
次に、以上のように構成した本実施形態に係るデータ集約方法が適用されたデータ集約装置１０の動作について説明する。
【００５６】
このデータ集約装置１０は、デバイス３０から送信されるデータを受信し、複数のデータを集約して、データ受信部４０へ送信するための装置であり、図１に図示されるように、デバイス３０から送信されたデータを受信する送信データ受領部１２に加えて、データ送信部１４、バッファ１６、集約条件蓄積部１８、データ受信履歴・データサイズ履歴記録部２０、および集約条件決定部２２が備えられている。
【００５７】
集約条件蓄積部１８には、データサイズ長に基づいて設定された第１の集約条件と、データの受信時間長によって設定された第２の集約条件とが格納されている。これら第１の集約条件および第２の集約条件は、過去の各データの受信実績に基づいて動的に設定される。したがって、本実施形態に係るデータ集約装置１０を最初に利用する際には、集約条件蓄積部１８に格納された第１の集約条件および第２の集約条件のデフォルト値が用いられる。それ以降は、第１の集約条件および第２の集約条件が、リクエストのデータの受信実績に基づいて動的に設定され、集約条件蓄積部１８に格納される。
【００５８】
このようなデータ集約装置１０によってデータの集約を開始する際には、一定期間、データの集約を行わずに送信されたデータより得られ、データ受信履歴・データサイズ履歴記録部２０に蓄積されたデータ送信情報より、集約条件決定部２２は、データ受信履歴・データサイズ履歴記録部２０から、データの受信時刻および送信所要時間（例えば、年月日時分秒）からなるデータ受信履歴を取得する。
【００５９】
さらに、集約条件決定部２２は、ステップＳａ０１で取得されたデータ受信履歴に基づいて、第２の集約条件を決定する。
【００６０】
そして、集約条件決定部２２は、このようにして決定した第２の集約条件を、集約条件蓄積部１８に送る。
【００６１】
集約条件蓄積部１８に格納された第１の集約条件および第２の集約条件は、データ送信部１４によって取得される（Ｓ５０）。
【００６２】
そして、デバイス３０から送信されたデータが、送信データ受領部１２によって、デバイス３０の識別番号（デバイスＩＤ）ａ、および、このデータ送信に使用された通信プロトコルｂとともに受信される（Ｓ５２）。さらに、送信データ受領部１２からは、このデータを受信した受信時刻ｃ、このデータのデータサイズｄ、およびこのデータ送信の所要時間ｅが、デバイスＩＤａおよび通信プロトコルｂに加えて、データとともに、データ送信部１４へ送られる（Ｓ５４）。
【００６３】
送信データ受領部１２から送られたデータは、データ送信部１４によって、バッファ１６へ送られ、バッファ１６に蓄積される（Ｓ５６）。また、送信データ受領部１２から送られたデバイスＩＤ  ａ、通信プロトコルｂ、データの受信時刻ｃ、データサイズｄ、およびデータ送信所要時間ｅも、データ送信部１４によって、データ受信履歴・データサイズ履歴記録部２０へと送られる（Ｓ５８）。さらに、データ送信部１４では、データサイズｄが累積される。
【００６４】
データ受信履歴・データサイズ履歴記録部２０では、ステップＳ５８においてデータ送信部１４から送られたデバイスＩＤ  ａ、通信プロトコルｂ、データの受信時刻ｃ、データサイズｄ、およびデータ送信所要時間ｅが、図３に示されるように、紐付けられて記録される。
【００６５】
また、データ送信部１４では、累積されたデータサイズと、第１の集約条件とが比較される。さらに、累積されたデータ送信所要時間と、第２の集約条件とが比較される。そして、第１の集約条件を満たしておらず、第２の集約条件にも達していないと、データ送信部１４によって判定されると、データの集約はまだ行われない。そして、送信データ受領部１２による、デバイス３０からの次のデータの受信が継続され、ステップＳ５２〜Ｓ５８の処理が繰り返される（Ｓ６０）。
【００６６】
一方、例えば、デバイス３０からのＮ回目のデータ受信時（ただし、Ｎは、１以上の整数）において、データ送信部１４によって、第１の集約条件を満たすか、または第２の集約条件に達したとの判定がなされると、それまでにバッファ１６に蓄積されていたデータが、データ送信部１４によってバッファ１６から取得され（Ｓ６２）、これら取得されたデータが、１つのリクエストとして集約され、データ送信部１４からデータ受信部４０へと送信される（Ｓ６４）。
【００６７】
ステップＳ６４の後、集約条件決定部２２によって、データ受信履歴・データサイズ履歴記録部２０から、ステップＳ６０の間に記録されたデータの受信時刻および送信所要時間（例えば、年月日時分秒）ならびにデータサイズ（例えば、バイト数）からなるデータ受信履歴が取得される（Ｓ６６）。
【００６８】
さらに、集約条件決定部２２では、ステップＳ６６で取得されたデータ受信履歴に基づいて、新たな第１の集約条件が決定される（Ｓ６８）。
【００６９】
そして、このようにして決定された第１の集約条件が、集約条件決定部２２から集約条件蓄積部１８へ送られる（Ｓ７０）。
【００７０】
集約条件蓄積部１８では、蓄積している第１の集約条件が、集約条件決定部２２から送られた第１の集約条件に上書きされることによって、第１の集約条件が更新される。これら更新された第１の集約条件および第２の集約条件は、次のリクエストのためのデータ集約のために使用される。
【００７１】
その後、次のリクエストのためのデータ集約のために、ステップＳ５０〜Ｓ６４までの処理が実施され、更新された第１の集約条件および第２の集約条件に基づいて、データ送信部１４によって、次のリクエストに各データが集約され、データ受信部４０へ送られる。さらにその後、ステップＳ６６〜Ｓ７０までの処理が実施され、第１の集約条件が更新される。このような処理が繰り返されることによって、リクエストに集約された各データの受信実績に応じて、集約条件決定部２２によって、第１の集約条件が動的に更新され、次のリクエストのためのデータ集約のために、集約条件蓄積部１８に蓄積される。その後、リクエストに集約されたデータが、バッファ１６から削除され、次のリクエストのためのデータを受信する準備がなされる。
【００７２】
上述したように、本実施形態に係るデータ集約方法が適用されたデータ集約装置１０においては、上記のような作用により、データサイズ長に基づいて設定された第１の集約条件と、データの受信時間長によって設定された第２の集約条件とに基づいてデータの集約がなされる。そして、第１の集約条件、および第２の集約条件ともに、送信されたリクエストの各データの受信実績に応じて動的に設定される。したがって、本実施形態に係るデータ集約方法が適用されたデータ集約装置１０は、データを集約してリクエストを送信する場合であっても、不必要にデータを集約することを避け、適切なタイミングでリクエストを送信することが可能となるので、リクエストの送信が開始されるまでに、時間がかかりすぎ、それによって不都合が生じることを回避することが可能となる。
【００７３】
以上、本発明を実施するための最良の形態について、添付図面を参照しながら説明したが、本発明はかかる構成に限定されない。特許請求の範囲の発明された技術的思想の範疇において、当業者であれば、各種の変更例及び修正例に想到し得るものであり、それら変更例及び修正例についても本発明の技術的範囲に属するものと了解される。
【符号の説明】
【００７４】
１〜５  データ、１０  データ集約装置、１２  送信データ受領部、１４  データ送信部、１６  バッファ、１８  集約条件蓄積部、２０  データ受信履歴・データサイズ履歴記録部、２２  集約条件決定部、３０  デバイス、４０  データ受信部、１００  従来のデータ集約装置、１０２  送信データ受領部、１０４  データ送信部、１０６  バッファ、１０８  集約閾値蓄積部、１１０  デバイス、１２０  データ受信部
【図１】
0006507091.tif 000002
【図２】
0006507091.tif 000003
【図３】
0006507091.tif 000004
【図４】
0006507091.tif 000005
【図５】
0006507091.tif 000006
【図６】
0006507091.tif 000007
【図７】
0006507091.tif 000008
【図８】
0006507091.tif 000009