(57)【要約】【課題】ハードディスクレコーダーに代表される、放送を受信して記憶装置に記録する形態の機器では記憶装置の記憶容量が不足することが多い。通信ネットワーク上に設けられたデータベースサーバに記録するサービスが従来から提唱されているが、記録するデータの圧縮率をさらに向上させない限り、コスト的に充分なサービスを提供するのが難しい。デジタル放送に関しては既に１つの解法が示されているが、アナログ放送には適用できない。【解決手段】放送内容をデジタル化して圧縮する際に、システムに接続された機器の間で同期を取ることにより記録されるデータがなるべく同じになるようにする。そしてデータベースサーバにおいてリファレンスデータとの差分を作成し、これをデータベースサーバあるいは機器で保存することで記録するサイズを小さくする。【選択図】図１
2006333293.tif 000002
【特許請求の範囲】
【請求項１】
放送の内容を受信し記録する機器と、通信ネットワーク上に設けられた圧縮サービスを提供するデータベースサーバとから構成される記録システムであって、
前記機器で記録したデータを、通信ネットワークを介して前記データベースサーバに送り、
前記データベースサーバ自身が受信し記録したデータをリファレンスデータとし、リファレンスデータとの差分を記録することを特徴とするネットワーク圧縮システム。
【請求項２】
前記データベースサーバに送られてきた複数のデータと前記リファレンスデータとの差分の総量ができるだけ少なくなるように算出したデータをリファレンスデータとする請求項１に記載のネットワーク圧縮システム。
【請求項３】
前記機器で放送内容を記録する際に、記録するタイミングを他の前記機器と同期させる請求項１または２に記載のネットワーク圧縮システム。
【請求項４】
放送内容の画像認識結果を、前記通信ネットワークを介して前記データベースサーバとやりとりすることで他の前記機器と記録するタイミングを同期させる請求項１〜３のいずれか一項に記載のネットワーク圧縮システム。
【請求項５】
放送内容の色や明るさの変化量、あるいは音声のパターン認識結果を、前記通信ネットワークを介して前記データベースサーバとやりとりすることで他の前記機器と記録するタイミングを同期させる請求項１〜３のいずれか一項に記載のネットワーク圧縮システム。
【請求項６】
前記機器で受信内容を記録する際に適当な時間間隔で区切ってデータをそれぞれ個別に記録する請求項１〜５のいずれか一項に記載のネットワーク圧縮システム。
【請求項７】
前記差分データを前記データベースサーバから前記機器に送り返す、請求項１〜６のいずれか一項に記載のネットワーク圧縮システム。
【請求項８】
前記差分データを前記データベースサーバから暗号化した上で前記機器に送り返す、請求項１〜６のいずれか一項に記載のネットワーク圧縮システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はアナログ放送内容をデジタル記録するハードディスクレコーダーやパソコンなどの機器と、その圧縮率を向上させるサービスを行う、通信ネットワーク上に設置されたデータベースサーバに関するものである。
【背景技術】
【０００２】
従来のアナログＴＶ放送内容をデジタル記録するハードディスクレコーダーやパソコンなどの民生機器は、放送内容を受信し、ＭＰＥＧ等のフォーマットに変換し、そのままハードディスク等の記録装置に記録していた。近年、記録装置の容量の増大は著しいが、それでもユーザーの要望を完全に満たすには至っていない。放送内容を記録するにあたって用いられるＭＰＥＧ等のフォーマットは、近接するフレーム間の画像の差分情報を用いるなどしてデータサイズを大幅に削減しているものの、元のデータ量が非常に多いので、圧縮後のデータサイズでもかなり大きくなる。
【０００３】
このデータサイズを削減することにより、記録装置に記録できる時間が延びるため、画質を落として記録時間を延ばすオプションなどが提供されるのが普通である。しかしこのオプションを使用した場合は画質が低下するという致命的な問題が発生する。
【０００４】
記録装置に記録できる量が限られている問題を解決するために、通信ネットワーク上に設置されたデータベースサーバを利用可能にするシステム／サービスが提案されている。しかし、一時的に記録する量が多くなった場合に柔軟に対応でき、データのバックアップサービスを受けることができるなどの魅力は有るものの、本質的には記録装置が家庭内の機器に有るのか、それとも通信ネットワークの先（データベースサーバ内）に有るのかの違いだけであり、一定のコストで提供できる記憶容量に本質的な違いは無い。データベースサーバのサービスを提供する業者は大規模記録装置を使うことによるコスト削減が多少は可能であるが、通信ネットワークの回線使用料や、データを記録する管理費用、利益などを付加しなければならないので、それを考えるとあまり魅力のあるものにならないようである。少なくとも現時点で実際にこのようなサービスを大規模に行い成功している例は無いと思われる。
【０００５】
特許文献１は、デジタル放送に関してこの問題を解決するものである。デジタル放送の場合は最初からデジタル化されたデータが放送されるため、ハードディスクレコーダーやパソコンなどでエンコードすることはなく、そのまま放送内容をデジタル記録するだけである。記録されるデータは原則として全ての機器で同じになる。場合によっては記録時間を延ばすため、いったんデコードした後、画質を落として再エンコードすることもあるが、パラメータが同じであれば同じ結果が得られると考えられる。このような条件下では、通信ネットワーク上に設置されたデータベースサーバに多くのユーザーから寄せられた記録内容を預かった場合、データベースサーバ上には全く同じデータが数多く存在すると考えられる。このとき、１個だけを残して他のデータを削除することができれば、記録装置の利用効率が格段に向上する。その他特許文献１では、同一番組のデータが複数の画質で記録された場合に最も解像度の高いものを選択すること、低い解像度のデータを記録した機器には解像度が高いデータから記録時と同程度に解像度を落として返すことを述べている。
【０００６】
いっぽう、アナログＴＶ放送を受信し、ＭＰＥＧフォーマットで記録した場合、それぞれの記録データは同じにはならない。この違いが出る原因は、受信状態の違いや重畳されるノイズの量の違いに加えて、記録を開始する時間の微妙なずれがあることや、ＭＰＥＧフォーマットのＩフレームのタイミングがずれることによる。
【０００７】
ＭＰＥＧフォーマットは一般に知られているように、動画像の各フレームを１フレームだけの情報だけから画像を圧縮したＩフレームと、前のフレームからの差分情報を圧縮したＰフレームに分類して圧縮する。場合によっては前後のフレームの情報を使用するさらに複雑な形式も使用されるが、ここでの説明に関係ないので詳細は省略する。ＭＰＥＧフォーマットの仕様ではＩフレームはどこかに１個以上存在すれば良く、残りは全てＰフレームでも構わない。圧縮率を高めるにはなるべくＰフレームを増やし、Ｉフレームを減らすほうが有利であるが、ハードディスクレコーダーやパソコンなどの機器が放送内容をＭＰＥＧフォーマットで記録する際は、再生時の特殊再生（途中からの再生、早送りなど）に備えて、０．５秒〜１秒毎にＩフレームを入れるのが一般的である。
【特許文献１】特開２００３−１５３１５２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
特許文献１で述べられた内容は優れた方法であるが、デジタル放送にしか適用できないことが問題である。また、最も高画質なデータだけを記録するため、低画質のデータを記録した場合は記録した内容と必ずしも一致しない結果が返される可能性がある。本発明はアナログ放送を受信しデジタル記録した場合に適用可能であり、機器で記録したデータと同じ内容以外が返されることはない。
【課題を解決するための手段】
【０００９】
前記従来の課題を解決するために、本発明のネットワーク圧縮のシステムはハードディスクレコーダーやパソコン等の機器でアナログ放送を受信し、内容をデジタル記録した内容をいったん通信ネットワークに接続された圧縮サービスを提供するデータベースサーバに送る。データベースサーバは機器から送られたデータをリファレンスデータと比較し、その差分だけをデータベースサーバに記録するか、差分を暗号化して機器に送り返す。リファレンスデータはデータベースサーバを運用する業者自身で放送内容を受信して記録した結果を使用したり、圧縮のために送られてきたデータから平均値を取るなどして作成したデータを使用したりすれば良い。差分データをなるべく小さくするためには後者のほうが有効であるが、処理に少し時間がかかるので、場合によって使い分ける方法も考えられる。
【００１０】
差分データをなるべく小さくするために、それぞれの機器では圧縮率などの記録パラメータを統一するとともに、記録するタイミングを合わせる。データの記録形式としてＭＰＥＧフォーマットを使用する場合はこれによってＩフレーム挿入のタイミングが揃い、記録データ毎の違いを減らすことができる。タイミングを合わせるには正確な時計を使用するか、ネットワークを利用して時計の同期を取るか、あるいは記録に先立って放送内容をパターン認識したり、放送内容の色や明るさのヒストグラムデータの変化量を認識したりして同期を取る必要が有る。いくら正確な時計を使用しても多少のずれは避けられないことと、放送局からの距離や、アンテナで受信してからの機器までの間の配線での遅れの量を考えれば、放送内容を使用して同期を取る方法が最も効果が高いであろう。
【００１１】
このネットワーク圧縮は、いったん機器ローカルの記録装置に記録し、オフラインで通信ネットワークを通じて圧縮サービスを提供するデータベースサーバに送り、圧縮結果をオフラインで送り返してもらうか、データベースサーバに記録してもらう実現方法と、受信した時に特にローカルに保存は行わず、記録結果をリアルタイムでデータベースサーバに送り、少しの遅延時間で圧縮結果を受け取るか、データベースサーバに記録してもらう実現方法が考えられる。圧縮結果を受け取る場合には、機器上から圧縮前のデータは削除するが、圧縮前のデータと圧縮後のデータの両方を持っていると論理的にはリファレンスデータを再現できてしまう点で法律的に問題がある。そのため、本発明に本質的には関係が無いが、圧縮結果を機器に送り返す場合は内容を自由に操作できないように暗号化しておく必要があるだろう。
【００１２】
圧縮後にそのデータを再生したい場合は、圧縮後のデータをデータベースサーバに送るか、データベースサーバ上に記録されているデータから、オフラインで圧縮前のデータを送り返してもらう実現形態か、もしくはストリーミング技術等を用いてリアルタイムで再生を行う実現形態が考えられる。
【００１３】
リアルタイムで圧縮／再生を行うサービスを提供する場合はもちろんであるが、オフラインで処理するサービスを提供する場合でも、番組の一部だけを記録するユーザーもいるので、放送内容の記録ファイルは適当な間隔で細分化し、細分化された単位で差分処理を行うべきである。この細分化の間隔は任意に選択できる。
【発明の効果】
【００１４】
本発明のネットワーク圧縮システムによれば、アナログ放送内容をデジタル記録する際に、その記録データのサイズを非常に小さくすることが可能になる。そのため、一定量の記録装置に保存できる時間数を飛躍的に伸ばすことができる。
【発明を実施するための最良の形態】
【００１５】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００１６】
（実施の形態１）
図１は本発明の実施の形態１におけるネットワーク圧縮システムの概念図である。アンテナ１０７で受信した放送の内容を記録する機器Ａ１０１で記録したデータ１０４を、通信ネットワーク１１０を用いて圧縮サービスを提供するデータベースサーバ１１１に送信する。データベースサーバ１１１は自分自身がアンテナ１１４で受信した放送内容を記録し、リファレンスデータ１１３とする。そしてデータベースサーバ１１１では機器Ａ１０１から届いたデータ１１５と、リファレンスデータ１１３の差分を取り、その結果１１７をデータベースサーバ１１１の記憶装置１１２に記録する。
【００１７】
なお、ここでいう「差分」はデータのフォーマットを無視してバイナリデータ列と見立てての単純な差分でも構わないが、データのフォーマットを知り、構成する成分別に分類し、それぞれ成分別の差分を計算することにより、データ全体の差分データをより小さくすることが可能となる。
【００１８】
システムはオンライン・リアルタイム、オフライン・非リアルタイムのいずれでも実装できる。単純なのはオフライン・非リアルタイムのシステムで、機器Ａ１０１で記録したデータ１０４をネットワークが混雑する時間帯を避けるなどしてデータベースサーバ１１１に送信すれば良い。以降の処理はデータベースサーバ１１１が行う。記録したデータを再生したい場合は、データベースサーバ１１１に指示すれば、データベースサーバ１１１は記憶装置１１２に記録してあった差分情報１１７とリファレンスデータ１１３から元のデータ１１５を作成し、通信ネットワーク１１０を介して機器Ａ１０１にデータを返すようにすれば良い。
【００１９】
オンライン・リアルタイムのシステムの場合は、機器Ａ１０１で記録したデータ１０４は放送中も記録したところまで通信ネットワーク１１０を介してデータベースサーバ１１１に送信する。差分データ１１７の作成もリアルタイムで行うようにすれば、機器Ａ上に大きなデータを置く必要が無くなる。このような構成の場合、再生時はデータベースサーバ１１１が記憶装置１１２に記録してあった差分情報１１７とリファレンスデータ１１３から元のデータ１１５を作成し、通信ネットワーク１１０を介して機器Ａ１０１にデータを返すのは同じであるが、データファイルとして返すのではなく、ストリーム配信することで簡単にリアルタイムに再生することが可能になる。もちろん、実施の形態６のようにデータを細かい時間に区切ればストリームを用いなくてもリアルタイム的な処理が可能になるが、これについては後で説明する。
【００２０】
データベースサーバ１１１への記録はオフライン・非リアルタイムで、再生はオンライン・リアルタイムという構成もありうる。
【００２１】
なお、言うまでも無いが説明上単純化しているが、本システムに接続される機器Ａ〜Ｃは３台とは限らず、台数は一般的にはもっと多数であり、しかも台数が動的に変化しうる。放送は同時に複数のチャンネルで行われており、オフライン処理を行う場合は同じチャンネルの前後の放送内容とも並列処理を行うことになる。ここでの説明は特定のチャンネルの特定の番組（放送内容）に着目した場合のものであり、実際の運用上はチャンネル別、番組別に複数の処理が並列処理する形態になるであろう。
【００２２】
（実施の形態２）
図２は本発明の実施の形態２におけるネットワーク圧縮システムの概念図である。実施の形態１との違いは、データベースサーバ２１１自身は放送の受信を行わず、それぞれの機器から送られてきたデータを元にして、できるだけデータベースサーバ２１１に記録する差分データ２１７等の合計サイズが小さくなるようにリファレンス値を設定することである。
【００２３】
図２では本システムを構成するのは機器Ａ２０１、機器Ｂ２０２、機器Ｃ２０３の３機であり、それら全てが放送を受信し、それぞれデータをデータベースサーバ２１１に送ってくるものとして説明をしているが、実際には機器の台数はずっと多く、そしてそれらの機器が特定の番組についてデータを送ってくるものかどうかが分からないのである。オフライン処理を認めている場合、かなり時間が経過してからデータが送られてくる場合もあるから、全てのデータが揃うのを待ってから処理するというのは現実的ではない。その場合は先着順に一定数のデータを選ぶなどして、その範囲で最も差分データの総量が一番少なくなるようにリファレンス値２１３を決めて運用する。
【００２４】
送られてきた複数のデータからリファレンス値２１３を算出するモジュール２１８の実装方法については、データのファイルフォーマットや、差分データの記録形式によってどうすれば差分の総量が小さくなるかは変わってくる。通常、「もっとも小さい」というのを目指すのは難しく、「できるだけ小さくする」ぐらいのアルゴリズムを目指すことになる。
【００２５】
単純なアルゴリズム実装例として、以下のような実装が考えられる。
【００２６】
まず、送られてきた複数のデータをそれぞれ構成している成分別に分解する。次に各成分について、送られてきた複数のデータ間で、それぞれが似ている部分の対応付けを行う。対応付けとは、一致しているか、非常に似ている部分を関連付けることである。たとえば、対応付けできた部分の単純な数値の平均値を成分別のリファレンス値とすれば良い。対応付けできなかった部分は順増部分としてデータそのものを差分データに含むか、リファレンス値から削減部分として取除く範囲の情報を差分データに含む必要が有る。
【００２７】
成分別に作成したデータからリファレンス値２１３を構成する。
【００２８】
オフライン処理で、時間をかけても良い場合は、さまざまな値をリファレンス値にして、差分データの合計サイズがどれぐらいになるのかを実際にやってみて、もっとも小さくなるものを採用すればよい。
【００２９】
（実施の形態３）
実施の形態１、実施の形態２をアナログＴＶ放送に関して適用する際に問題となるのは、一般に動画像の記録フォーマットは１フレームだけの情報を使用するＩフレームと、前のフレームとの差分情報を使用するＰフレームに分かれているため、Ｉフレームが入る位置によってデータが大きく違ってくることである。
【００３０】
この問題を避ける一番簡単な方法は、Ｉフレームのタイミングを合わせることである。たとえば、正確な時間を刻むように調整された時計を用い、たとえば毎秒正時（ちょうど秒単位になり、秒未満の時間が０のタイミング）以降開始された最初のフレームをＩフレームと定め、それ以外のフレームをＰフレームと定めれば良い。通信ネットワークを用いて時計を正確な値に保つ方法は一般に知られている。その仕組みを用いれば時計の精度が多少悪くても充分実用になる。
【００３１】
ただし、実際には放送局からの距離、アンテナから機器までの間のシステム構成（たとえばケーブルテレビでは時間が少し遅くなっている可能性が高い）によってディレイの量は異なるため、微調整が必要となる。正確な時計に機器のユーザーが設定する微調整の時間定数を加えて同期を取ることになる。
【００３２】
（実施の形態４）
実施の形態３での問題点は、同期を取るための微調整量を決めることが実際問題として難しいことである。そこで、その調整を自動化するのが実施の形態４である。
【００３３】
実施の形態４では同期を取るために実際に受信している放送内容を利用する。簡単な実装としては、記録を開始する少し前に試験的に適当な時間、たとえば１秒分を仮に記録し、それに対して画像認識を実施し、映っている人物や物体の位置などの情報を得る。これを機器の時計で計測した時間とともに通信ネットワークを介してデータベースサーバに送り、同期に必要なパラメータを依頼する。データベースサーバはリファレンス値に対して実施した画像認識結果と付き合わせ、どの程度時間をずらせば良いのかを判定し、再び通信ネットワークを介して機器に情報を送り返す。
【００３４】
（実施の形態５）
実施の形態４では画像認識を用いるとしたが、画像認識は処理時間が非常に大きく、処理内容も複雑である。したがってリアルタイム系に実装するのは難しい場合もあると考えられる。そのような場合は、放送内容の１フレーム分の画像の平均色の変化、平均明度の変化、音声のボリュームといったより簡単に得られる情報を用い、その変化が起こったタイミングで同期を取ればよい。画像認識を正確に行うのに比べると不正確ではあるが、より簡単に実装できる。
【００３５】
（実施の形態６）
このネットワーク圧縮システムを利用するユーザーの全てが、放送内容を記録する際に、番組の最初から最後まで記録することしかしないという前提は置けない。また、リアルタイム処理をよりシンプルに実施するためにも、番組全体の受信が完了してからしか処理を開始できないのでは使い勝手が悪くなる。これらの問題を解決するには、適当な時間間隔を単位とし、その単位時間で区切ってデータ化することである。
【００３６】
たとえば、適当な時間間隔を５秒とし、その先頭フレームと、１秒間隔でＩフレームが入ったデータを単位として考えると、通信ネットワークを介してデータベースサーバに送るのも、差分を計算するのもこのデータを単位とするとよい。こうすることによって番組の記録開始時間や終了時間は５秒単位で自由に設定可能になる。また、オフライン処理では適当な時間間隔（この例では５秒）以上のずれは自動的に関係が無くなるという利点もある。
【００３７】
（実施の形態７）
今までの実施の形態では作成した差分データをデータベースサーバの記憶装置に保存する形態であった。この形態の問題点は、このネットワーク圧縮システムを利用するユーザー数や記録されるデータの量が予想しにくい場合に、どうしてもデータベースサーバの記憶装置などは余裕を持った構成にせざるを得ず、高コストなシステムになってしまうことである。
【００３８】
この問題を避けるためには、データベースサーバで作成した差分データを、通信ネットワークを用いて機器に送り返せばよい。そうするとデータベースサーバに必要な記憶装置の容量はリファレンスデータを保存する容量と、作業用の一時データを保存するための多少の余裕が有れば良いことになる。仮に、非常に多くのユーザーがこのシステムを一斉に使用したとしても、リファレンスデータの容量は、各地で放送されている番組の総量を超えない。これはこのシステムを利用するユーザー数が非常に多い場合の“差分データの総和”よりもずっと少ないデータ量で済むと考えられる上、チャンネル数と時間経過で大雑把な必要容量が見積もれるので、計画的な設備投資が可能になる。
【００３９】
（実施の形態８）
実装の形態７の問題点は、機器側に元データと差分データの両方が存在すると、そこからリファレンスデータを再現できる可能性があることである。これはユーザーが私的に記録した内容とは異なるため、現行国内法上、再現できると問題が有る。実際には、差分の逆演算を行うのはそれほど簡単な作業ではないし、そのような機能はもちろん機器としては提供しない。さらに、機器にデータベースサーバから差分データが届けば元データは消去するし、逆に元データが届けば差分データは消去するように実装すれば問題無いはずである。
【００４０】
このままでもほとんど問題は無いが、機器に記録した内容をＤＶＤや外部ハードディスク等の外部媒体に記録する仕組みを提供している場合は、悪意あるユーザーであれば元データと差分データの両方を手に入れることが可能になってしまう。
【００４１】
このような問題に対処するため、差分データはデータベースサーバから機器にそのまま送り返すのではなく、暗号化して送り返すことにする。そうすることによって元データと暗号化された差分データの両方が機器上に存在したとしても、リファレンスデータを再現することはできなくなる。暗号化の方法に関してはさまざまな方法が知られており、その適当なものを選択すればよい。
【００４２】
本発明の説明ではアナログのＴＶ放送をデジタル化し、ＭＰＥＧ形式で記録する場合について説明したが、記録形式として他の形式を採用した場合も、フレーム間の差分情報を利用している形式であれば本質的な差は無く、同様に適用できることは言うまでも無い。
【００４３】
フレーム間の差分情報を利用していない形式で記録する場合でも、リアルタイムのサービスを提供したり、番組の部分記録をサポートしたりするためには、一定間隔で区切りながら記録内容を比較する方法をとることが考えられ、区切る間隔を一定にするためには同期を取らないといけないことに変わりは無い。よって、やはり同様に適用できる。
【００４４】
ＴＶ放送の音声データの記録や、本発明をラジオ放送に適用した場合も同様である。
【００４５】
また、原理的にはＴＶ放送とラジオ放送に限定されるものではなく、それ以外にも同一内容の情報が多くのユーザーに配布されるような形態のものであって、単純に記録するだけでデジタル的に同一内容が得られるものではないものに適用できることは言うまでも無い。たとえば、無線通信の交信記録や、講演会やコンサートの内容を主催者の許可を得て私的に記録する場合などが考えられる。
【産業上の利用可能性】
【００４６】
本発明にかかるネットワーク圧縮のシステム／装置／方法を用いれば、ハードディスクレコーダーやパソコン等のアナログ放送をデジタル記録する機器において、記録するデータの圧縮率を飛躍的に高めることができる。圧縮結果をデータベースサーバに配置する場合も、記録しておくデータの量をかなり削減できるため、ユーザーに低コストでサービスを提供できる可能性が高い。したがってこれらの機能を含む家電機器、パソコン、ゲーム機などの分野で利用される可能性がある。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施の形態１におけるネットワーク圧縮システムの概念図
【図２】本発明の実施の形態２におけるネットワーク圧縮システムの概念図
【符号の説明】
【００４８】
１０１    放送の内容を受信し記録する機器Ａ
１０２    放送の内容を受信し記録する機器Ｂ
１０３    放送の内容を受信し記録する機器Ｃ
１０４    機器Ａで記録されたデータ
１０５    機器Ｂで記録されたデータ
１０６    機器Ｃで記録されたデータ
１０７    機器Ａに接続されたアンテナ
１０８    機器Ｂに接続されたアンテナ
１０９    機器Ｃに接続されたアンテナ
１１０    通信ネットワーク
１１１    圧縮サービスを提供するデータベースサーバ
１１２    データベースサーバの記憶装置
１１３    リファレンスデータ
１１４    データベースサーバに接続されたアンテナ
１１５    機器Ａで記録したデータがデータベースサーバに転送されたもの
１１６    機器Ａで記録したデータとリファレンスデータの差分を計算する手段
１１７    機器Ａで記録したデータとリファレンスデータの差分データ
２０１    放送の内容を受信し記録する機器Ａ
２０２    放送の内容を受信し記録する機器Ｂ
２０３    放送の内容を受信し記録する機器Ｃ
２０４    機器Ａで記録されたデータ
２０５    機器Ｂで記録されたデータ
２０６    機器Ｃで記録されたデータ
２０７    機器Ａに接続されたアンテナ
２０８    機器Ｂに接続されたアンテナ
２０９    機器Ｃに接続されたアンテナ
２１０    通信ネットワーク
２１１    圧縮サービスを提供するデータベースサーバ
２１２    データベースサーバの記憶装置
２１３    リファレンスデータ
２１５    機器Ａで記録したデータがデータベースサーバに転送されたもの
２１６    機器Ａで記録したデータとリファレンスデータの差分を計算する手段
２１７    機器Ａで記録したデータとリファレンスデータの差分データ
２１８    機器Ａ、機器Ｂ、機器Ｃから送られてきたデータからリファレンス値を作成するモジュール
【図１】
2006333293.tif 000003
【図２】
2006333293.tif 000004