JP7010984B2 - メモリデバイスのデータ管理方法、データ管理システム - Google Patents

Description

本発明の実施形態は、メモリデバイスのデータ管理方法、データ管理システムに関する。

近年注目されているＩｏＴ技術では、多種多様なセンサからのデータが逐次収集される。またその収集されたデータを有効的に活用する場合、過去に収集されたデータまで遡って利用される場合が多い。そのため逐次収集されるデータは、適宜メモリ内への保存を通じて蓄積される。するとその結果として、メモリ内に保存されるデータ量が時間経過に従って膨大となってしまう。

特開２００６－３４５２０８号公報 特開２０１０－１８７１２４号公報

蓄積が可能データの具体的な一例として、特許文献１では、監視映像をＤＶＲ（Digital Video Recorder）に一時的に保管する技術が開示されている。またこの一時的に保管された監視映像は、データの送信の要求に応じて適宜に送信を要求した者へ送信される。ところで、このＤＶＲ内に蓄積される監視映像の量は、時間の経過と共に増大して、最終的にはデータの容量がＤＶＲの能力に対して超過してしまう。しかし、蓄積される監視映像のデータの容量がＤＶＲの能力を超過を対策する技術の開示は無い。

それに対して特許文献２では、監視映像のデータについて、容量の超過への対策の方法として、新規に収集する監視映像の上書き処理を行う。しかしこの方法では、上書きされる前の古い監視映像の有効活用が不可能となる。

実施形態では、蓄積が可能なデータを保存するメモリのデータを有効利用可能なデータ管理方法またはそれを用いた管理システムの提供が求められる。

一実施形態によれば、サーバと、前記サーバにネットワークを介して接続されるエッジ装置と、前記エッジ装置に接続される複数のメモリデバイスとを備えるネットワークシステムのデータ管理方法において、
前記エッジ装置は、
記複数のメモリデバイスのデータに関して少なくとも公開の有無を含む管理情報を収集し、前記収集した前記管理情報を前記ネットワークを介して前記サーバに送信し、
前記サーバは、
前記管理情報を、前記複数のメモリデバイス別にテーブルで管理し、かつ前記メモリデバイスの前記管理情報としては、前記メモリデバイス内に非公開データと公開データがあることの識別をクラス別で識別管理している、ことを特徴とするネットワークシステムのデータ管理方法が提供される。

図１は、本実施形態におけるネットワークシステムの構成図である。 図２は、インターネット上で使用される通信データ内の構造説明図である。 図３は、ＩＰｖ６ヘッダ内のデータ構造を説明する図である。 図４は、データ制御情報及び通信データ本体内のデータ構造を説明する図である。 図５は、通信データ本体内のデータ構造を説明する図である。 図６は、制御情報内の記述フォーマットを説明する図である。 図７は、制御情報内に記述される制御タイプ内容とパラメータの関係の一例を示す図である。 図８は、制御情報の記述例説明する図である。 図９Ａは、エッジ装置における収集データと解析データの移動経路を説明する図である。 図９Ｂは、エッジ装置におけるデータ収集と解析のフローを説明する図である。 図１０は、ユーザの管理情報を説明する図である。 図１１は、センサデータ収集場面の例を説明する図である。 図１２は、表示される広告内容と通行人状態の関係を説明する図である。 図１３Ａは、センサデバイスで撮影した生のセンサデータ例を説明する図である。 図１３Ｂは、生のセンサデータに対する加工後のデータ例を説明する図である。 図１４は、ユーザの管理情報に基づく管理パケット作成方法を説明する図である。 図１５は、エッジ装置とデバイス間のネットワーク接続関係例を説明する図である。 図１６は、エッジ／デバイステーブル内容例を説明する図である。 図１７は、ドメイン内における拡張可能なメモリ領域検索方法を説明する図である。 図１８は、エッジ／スモール／デバイスエージェントの役割分担を説明する図である。 図１９Ａは、メモリデバイス内に記録されるデータの変化を説明する図である。 図１９Ｂは、メモリデバイス内に記録されるデータの変化をさらに説明する図である。 図１９Ｃは、保存データの記録場所変更方法を示したフロー説明図である。 図２０Ａは、メモリデバイス内状態変化を説明する図である。 図２０Ｂは、メモリデバイス内状態変化に対応した善処方法を説明する図である。 図２０Ｃは、メモリデバイス内状態変化に対応した善処フローの説明図である。 図２１は、データベース検索方法の一例を説明する図である。 図２２は、ネットワークを経由した課金対象データの移動例を説明する図である。 図２３は、課金制御方法の概略を説明する図である。 図２４は、データ記録場所分散配置に拠るデータ信頼性向上方法を説明する図である。 図２５は、工場内での本実施形態の応用例を説明する図である。 図２６は、広い使用場面での本実施形態の応用例を説明する図である。 図２７は、広い使用場面での本実施形態におけるデータ解析方法を説明する図である。 図２８は、ネットワーク接続可能な移動体内での本実施形態の応用例を説明する図である。 図２９は、ネットワーク接続可能な移動体内のセンサ／駆動ドライブを説明する図である。 図３０は、ネットワーク接続可能な移動体内でのエッジエージェントの処理を示す図である。 図３１は、ネットワーク接続可能な移動体内でのデータ解析方法を説明する図である。

以下、図面を参照しながら実施形態を説明する。まず始めに、本実施形態の説明内容に関する章と節の構成を下記の目次にて示す。

第１章 本実施形態の概説
１．１節 ネットワークシステム全体の構成
１．２節 デバイス
１．２．１節 デバイス全般とデバイスエージェントの働き
１．２．２節 メモリデバイス
１．２．３節 センサデバイス
１．３節 エッジ装置とエッジエージェント
第２章 ネットワーク内で利用される通信データ
２．１節 インターネット上で使用される通信データ構造
２．２節 インターネット以外の通信経路で使用される通信データ構造
２．３節 データ制御情報及び通信データ本体内のデータ構造
第３章 ネットワーク経路内でのデータ通信方法
３．１節 データ収集とデータ解析
３．２節 個人情報保護対応のデータ解析とデータ公開／課金条件
３．３節 ドメイン内メモリ領域拡張方法
３．４節 メンテナンス情報の管理とネットワーク通信
３．５節 データベース検索方法
３．６節 従量課金の制御方法
３．６．１節 保存データ再生時の従量課金制御方法
３．６．２節 データ保存場所変更時の従量課金制御方法
第４章 分散配置されたデータと管理情報の信頼性確保方法
第５章 エッジ装置の他の実施形態
第１章 本実施形態の概説
まず始めに本実施形態におけるネットワークシステム全体の構成を説明し、その次にそのネットワークシステムを構成する構成要素個々の説明を行う。

１．１節 ネットワークシステム全体の構成
本実施形態に係るシステムでは、図１に示すように、インターネット２などのネットワーク回線を通じて異なる場所間でのデータ通信が行われる。図１ではネットワーク回線の具体例としてインターネット２を記載した。しかしそれに限らず、所定のローカルなネットワーク回線でも良い。またネットワーク回線を構成する通信媒体として、有線回線あるいは無線回線のいずれの通信媒体を使用しても良い。

本実施形態では、インターネット２も視野に入れたネットワーク回線への接続対象を分散サーバ群４、エッジ装置１４、１６、１８、そしてデバイス２０、２２、３２、３４、３６などに分類する。ここでエッジ装置１６内にデバイス３６が内蔵されても良いし、エッジ装置１４とデバイス２２、３２、３４間がネットワーク接続されても良い。また第２章で後述するＩＰ（internet protocol）アドレスを、全てのエッジ装置１４、１６、１８及び全てのデバイス２０、２２、３２、３４、３６に予め設定しても良い。それに拠り、至る所から任意のエッジ装置１４、１６、１８または任意のデバイス２０、２２、３２、３４、３６への直接アクセスが可能となる。

インターネット２を含めたネットワーク回線の接続形態として本実施形態では、『分散サーバ群４／エッジ装置１４／デバイス２２、３２、３４の３階層形態』や『分散サーバ群４／エッジ装置１６、１８の２階層形態』、『エッジ装置１４／デバイス２２、３２、３４の２階層形態』に限らず、分散サーバ群４から直接デバイス２０にアクセス可能な『分散サーバ群４／デバイス２０の２階層形態』を取っても良い。また図１のようにエッジ装置１４に複数のデバイス２２、３２、３４が接続される場合は、ネットワーク回線がエッジ装置１４を頂点とした『ツリー形態』を取る事ができる。更に図１に示す例では、このエッジ装置１４を含めて他のエッジ装置１６や携帯形エッジ装置１８及びメモリデバイス２０が、分散サーバ群４を頂点としたツリー形態内に含まれている。

ネットワーク回線を経由したデータ通信において本実施形態では、一方がデータ通信を主導し、それ以外が従属してデータ通信に参加する。このように互いに対等な関係でのデータ通信形態を取らないため、同一のネットワーク回線への複数接続状態に対しても安定に統制の取れたデータ通信を可能にする効果が有る。すなわち上述したネットワーク回線の接続形態では、具体的に
分散サーバ群４ ＞ エッジ装置１４、１６、１８ ＞ デバイス
の優先順に従って、データ通信上の主従関係（左側が主導側、右側が従属側を意味する）を規定する。このようなデータ通信上の主従関係の具体例として２．３節で後述するように、多くの場合には(1)主導側が“リクエスト”の送信を行い（“リクエスト”の通信情報を従属側が受信する）、(2)従属側がそれに対する“レスポンス”送信または“ステータス”送信を行う（“レスポンス”または“ステータス”の通信情報を主導側が受信する）。

このようにネットワーク回線を用いたデータ通信処理上の主従関係を明確化する分類方法として、図１の実施例に限らず他の分類方法を行っても良い。即ち、上記の分類方法に対応する『３層形態』や『２層形態』あるいは『ツリー形態』に対して、他の分類方法を行った場合には、他の『多層（４層以上）形態』や『非ツリー形態』を採用しても良い。

さらに本実施形態では、従属側に自律的な処理機能を持たせても良い。その結果として
得られるネットワーク上の効果として、(1)従属側から“リクエスト”の送信を行い（“リクエスト”の通信情報を主導側が受信する）、(2)主導側がそれに対する“レスポンス”送信または“ステータス”送信を行う（“レスポンス”または“ステータス”の通信情報を従属側が受信する）という、上記とは反対の処理が可能となる。

そして、従属側に自律的な処理機能を持たせる方法として、エッジ装置１４、１６、１８やデバイス２０、２２、３２、３４、３６内にエージェント４０、４２、４４、４６、４７、４８の機能を持たせても良い。このエージェント機能を具現化した例として、ＣＰＵ（Central Processing Unit）とそのプログラムが予め記録されたメモリの組み合わせでも良いし、簡単なエージェント機能を実現する専用ＩＣ（Integrated Circuit）を内蔵させても良い。また、上記の専用ＩＣ内部の構成として、単純なロジック回路の組み合わせ回路のみで構成されても良いし、プログラマブルなロジック形成が可能な構成でも良い。

ここで、従属側で行う自律的な処理内容として、エッジ装置１４、１６、１８とデバイス２０、２２、３２、３４、３６共に「専用ＩＣ内部の状態の管理」、「専用ＩＣ内部のデータ処理に関する自律的制御」、「得られたデータの簡単なデータ解析やデータ選別」、「得られたデータを基に加工して生成したデータの作成」、「データ解析の結果や選別したデータの主導側への送信制御」、「専用ＩＣ内部の状態の異常検出や専用ＩＣに記録されたデータに関する事前のリスク検出」、「専用ＩＣ内部の異常検出での結果や事前のリスク検出の主導側への送信の制御」、「メンテナンス情報の管理と送信の制御」、「通信相手（主導側）の状態の管理」などの処理を行っても良い。特にエッジ装置１４、１６においては、後述する管理情報６２、６６を用いて、管理下にある範囲内でのデータ公開に係る課金情報の自動算出を行っても良い。また課金情報の自動算出が行われる場合、取り扱われるデータの属性（ユーザに帰属するデータや、メモリ及びシステム等の管理者に帰属するデータ）に応じて、課金の値（無料も含む）が異なってもよい。

上記のように、データの通信での主従関係が定義されるネットワーク回線において、従属側に自律的な処理機能を持たせることによって、ネットワークシステム全体の処理効率が向上する効果がある。即ち、例えば唯一の主導側に対して、エージェント機能を持たない、非常に多くの従属側がネットワーク接続されている場合、全ての従属側の動作を円滑に制御するためには、主導側の負担が膨大となる。それに比べて、本実施形態のように従属側でエージェント機能を持たせると、主導側の負担が大幅に軽減する。

図１に示す分散サーバ群４は、１台以上のサーバから構成される。ここで説明する実施形態では、『ネットワーク回線（インターネット２が含まれても良い）を介したユーザへのサービス提供者』をサーバと定義する。従って、具体的な分散サーバ群４の具体的な形態として、例えば「ユーザに提供するサービス内容毎に異なるサーバが同一ネットワーク（インターネット２）上に接続されている」、「ネットワーク回線（インターネット２が含まれても良い）に接続された１台のサーバが、ユーザに対して異なる複数のサービスを提供する」、「ネットワーク回線（インターネット２が含まれても良い）には１台のインターフェースサーバが接続され、その背後で並列処理が可能な複数のサーバがこのインターフェースサーバに接続される」などのいずれの形態を構成しても良い。

また、サーバの機能（ユーザに提供するサービス内容）としては、所定ドメイン内を統合的に管理するクライアントサーバ、Ｗｅｂのホームページ表示に関与するＷｅｂサーバ、共通ドメイン内のデータを一括管理するデータベースサーバなどに限らず、あらゆる機能を有しても良い。

１．２節 デバイス
１．２．１節 デバイス全般とデバイスエージェントの働き
ここで説明する実施形態では、『所定の独自機能と通信機能を有した複合体』をデバイスと定義する。そして、この所定の独自機能としてセンサ機能を有したデバイスをセンサデバイス３２、３４、３６と呼び、メモリ機能を有したデバイスをメモリデバイス２０、２２、２６と呼ぶ。しかし、それに限らず、何らかの駆動機能を有するデバイスを駆動デバイス（actuator device）、表示機能を有するデバイスを表示デバイス（display device）、演算機能を有するデバイスをプロセッサデバイスと定義しても良い。

そして、デバイス内での通信機能に関与する通信方法としては、有線通信（wired communication）と無線通信（wireless communication）のいずれでも良い。また、接続形態として、「図１のメモリデバイス２０のように直接インターネット２に接続する形態」、「図１のセンサデバイス３２、３４やメモリデバイス２２のように、単独で存在してイントラネットに接続される形態」、「図１のセンサデバイス３６やメモリデバイス２６のように、エッジ装置１６内に組み込まれ、エッジ装置内での通信に関与する形態」
等いずれの形態も許容されるだけで無く、デバイスとして他のあらゆる形態を取っても良い。

ここでの実施形態では、１．１．１節で説明したように、デバイス２０、２２、２６、３２、３４、３６内にエージェントが常駐している（図１での図示を省いたが、センサデバイス３２、３４、３６内にもエージェントが常駐しても良い）。このデバイス２０、２２、２６、３２、３４、３６内のエージェントの中で、インターネット２に直接接続可能なエージェントを特にスモールエージェント４０と呼び、それ以外の相手とネットワーク接続するエージェントをデバイスエージェント４２、４６と呼ぶ。このスモールエージェント４０とデバイスエージェント４２、４６との間では、データ通信に使用する通信プロトコルが異なる。図２を用いて２．１節で後述するように、インターネット２内で使用される通信プロトコルでは物理層ヘッダＰＨＹＨＤからＴＣＰヘッダＴＣＰＨＤに至るヘッダ群の転送が必要となる。それに比べて、インターネット２以外でのデータの通信では、データ制御情報ＫＥＹＶＡＬ（及びそれに先行する物理層ヘッダＰＨＹＨＤとＭＡＣ層ヘッダ）のみのデータ通信が許容される。

１．２．２節 メモリデバイス
図１に示すメモリデバイス２０、２２、２６は図示して無いが、データ保存用メモリ領域、通信制御部とＣＰＵから構成される。更に、前記ＣＰＵ専用のメモリ領域を内蔵し、
○ 「１．１節と１．２．１節で説明したエージェント機能（スモールエージェント４０やデバイスエージェント４２、４６）を実現させるための制御プログラム」、「通信プロトコルに準拠した通信データ作成用データの一時保管」などに利用しても良い。ところで、上記ＣＰＵ専用のメモリ領域を持つ代わりに、前記のデータ保存用メモリ領域内を領域分割した特定領域内に上記制御プログラムや通信データの保存を行っても良い。

また、図１のセンサデバイス３２、３４が収集したオリジナルなセンサデータ、及びエッジエージェント４４内で解析して得られるデータ（アナライズド）が、前記データ保存用メモリ領域内に順次記録される。更に、前記データ保存用メモリ領域内の所定領域の中に管理情報６２や共通鍵５２、５４、５６の情報を格納しても良い。

デバイス内で行う自律的な処理内容に付いて既に１．１節で説明した。メモリデバイス２０、２２、２６内のスモールエージェント４０またはデバイスエージェント４２、４６が自律的に管理する内部状態の一例として、データ保存用メモリ領域内の記録容量や書き込み速度に関係するサンプリング速度だけに限らず、データ保存用メモリ領域内の書き換
え可能回数や記録したデータの保持期間などに関係する寿命情報などが対応する。

また、内部状態の異常検出や記録データに関して事前に検出するリスク情報の一例としては、メモリデバイス２０、２２、２６による記録データの保持が可能な期限が近づいた場合に起きる、記録データの損失に関するリスクや、メモリデバイス２０、２２、２６による記録容量が超過した場合に起きる、新しいデータの上書き処理に起因する古い記録データの損失に関するリスクなどが対応する。

一方、ネットワーク通信相手（主導側）に関して管理する状態の一例として、主導側のデータ転送速度や主導側の内部で所有するメモリデバイス２０、２２、２６のメモリ領域の記録容量などが対応する。

１．２．３節 センサデバイス
センサデバイス３２、３４、３６内には通信制御部と共に、そのセンサ特有のセンサ部を有する。このセンサ部として本実施形態では、音声や画像、映像に限らず、温度、湿度、圧力、振動、加速度、角速度などあらゆるデータの収集が対象となる。

また１．２．２節と同様にメモリ領域や専用ＣＰＵ（及びそのプログラム格納領域）を内蔵しても良い。

１．１節での説明内容に関係してセンサデバイス３２、３４、３６内のスモールエージェントまたはデバイスエージェントが自律的に管理する内部状態の一例として、センサの種別情報やセンサ部の処理性能、センサデバイス内の（メモリ領域の）記録容量などが対応する。また、センサデバイス３２、３４、３６内で特殊な処理が行える場合の処理内容の情報も管理しても良い。

特に、センサデバイス３２、３４、３６の場合には、検出すべき内部状態の異常やリスクとしては、センサ機能（センサ性能も含む）の低下や故障などが対応する。

一方、ネットワーク通信相手（主導側）に関して管理する状態の一例として、主導側のデータ転送速度や主導側の内部で所有するメモリ領域の記録容量などをスモールエージェントやデバイスエージェント内で管理しても良い。

１．３節 エッジ装置とエッジエージェント
本実施形態では、『インターネット２またはイントラネットなどのネットワーク接続が可能な装置』をエッジ装置１４、１６、１８と定義する。エンドユーザに近い場所をフロントエンドと呼ぶ場合がある。そして、そのフロントエンド側で使用しても良い装置と言う意味も含めてエッジ装置と呼ぶ。

このエッジ装置１４、１６、１８は、有線または無線回線を通じて分散サーバ群４と単独でネットワーク接続しても良い。

前記エッジ装置１４、１６、１８の具体例として、「据え置き形」、「携帯形」、「移動体形」などに分類しても良い。ここで、各形式には具体的に以下が該当する。

据え置き形は、パソコン、ルーター（ゲートウェー）、ＣＰＵ内蔵家電装置（テレビ、冷蔵庫、洗濯機、オーディオ装置など）、インテリジェントな情報伝達手段（固定電話や据え置き形テレビ電話システム）、エージェント機能を持った分電盤や監視システム（映像監視や気象監視を含む）などが、例えば該当する。

携帯形は、スマートホン、タブレット、携帯電話、ウェアラブル端末（エージェント機能が内蔵された時計やメガネなど）、携帯形の体調測定装置（万歩計（登録商標）、体温計、脈拍や鼓動測定器、血液中の酸素濃度や血糖値の測定装置など）などが、例えば該当する。

移動体形は、コネクティッドカーやコネクティッドバス、コネクティッドトラック、コネクティッド船舶などが、例えば該当する。

しかし、それらに限られず本実施形態では、『接続可能な装置』全てがエッジ装置１４、１６、１８に含まれる。

図１を用いて１．１節で説明したように、エッジ装置１４、１６、１８はエージェント機能（自律的な処理機能）を持っても良い。また１．１節で説明した具体的な実現方法によって、このエッジエージェント４４、４７、４８の機能が達成される。このエッジエージェント４４に関して前述した『得られたデータのデータ解析やデータ選別』機能を実行する一例を以下に説明する。エッジ装置１６内のセンサデバイス３６やエッジ装置１４と接続されたセンサデバイス３２、３４から収集されたオリジナルなセンサデータａ、ｂ、ｃ、あるいはインターネット２あるいはイントラネット回線を介して入手したオリジナルデータに対し、エッジエージェント４４（４７、４８）内部でデータ解析を行い、その解析結果（アナライズドデータ）ａ’、ｂ’、ｃ’を前記オリジナルなデータａ、ｂ、ｃと共にメモリデバイス２２内に格納しても良い。なお、データ解析には、ある程度の高度な画像（映像）解析／分析に限られず、文字認識や画像認識などの認識処理も含まれる。

また、それに限らずエッジ装置１４、１６、１８が管理する範囲内での課金情報の自動算出処理をエッジエージェント４４、４７、４８の内部で行い、その結果を主導側の分散サーバ群４に通知しても良い。

図１で携帯形エッジ装置１８内に示したユーザＩ／Ｆ部８の具体例として、入出力が同時に可能な部品（タッチパネルなど）を使用しても良い。しかし、それに限らずユーザＩ／Ｆ部８の内訳が入力部と出力部に分かれ、入力部としてタッチパッド、音声入力部、撮像部、キーボード、文字入力部などが対応するだけで無く、１．２．３節で説明したあらゆるセンサデバイスを入力部に対応（センサデータが携帯形エッジ装置１８内に入力される）させても良い。また、出力部として音声を出力させる構造や画像（映像）を表示させる構造を対応させるだけでなく、あらゆる表示または駆動機構を持った駆動デバイスも出力部に対応させても良い。

加えて、図１での図示は省略しているが、エッジ装置１４、１６内に上記ユーザＩ／Ｆ部８または入力部や出力部と同様な部品が含まれても良い。

第２章 ネットワーク内で利用される通信データ
本実施形態のシステムにおいてネットワーク通信する場合に利用される通信データ構造について、第２章で説明する。

２．１節 インターネット上で使用される通信データ構造
図１のインターネット２上で使用される通信データの構造を図２に示す。インターネット２上での通信媒体として有線か無線かを問わず、１つの塊を単位として通信データが間欠的に送信される。そしてこの塊が、図２（ｆ）の物理層フレームＰＰＤＵに相当する。

この１個の物理層フレームＰＰＤＵ内は図２（ａ）が示すように、送信側から受信側へ向けた送信順（前からの順番あるいは情報を送り出すタイミングが早い順）に物理層ヘッダＰＨＹＨＤ、ＭＡＣ層ヘッダＭＡＣＨＤ、ＩＰｖ６ヘッダＩＰｖ６ＨＤ、ＴＣＰヘッダＴＣＰＨＤ、データ制御情報及び通信データ本体ＫＥＹＶＡＬ、誤チェックＣＲＣの順番で構成される。一方、このデータ配置を図２（ｆ）の視点から見ると、“物理層フレームＰＰＤＵ内の先頭に物理層ヘッダＰＨＹＨＤが配置され、その背後に物理層データまたは物理層ペイロードＰＳＤＵが続き、そしてこの物理層データ／ペイロードＰＳＤＵ内に順次ＭＡＣ層ヘッダＭＡＣＨＤ、ＩＰｖ６ヘッダＩＰｖ６ＨＤ、ＴＣＰヘッダＴＣＰＨＤ、通信ミドルウェアデータＡＰＬＤＴ、拡張データＥＸＤＴ、誤チェックコードＣＲＣが格納される”とも認識できる。

そして同様に、ＭＡＣ層ヘッダＭＡＣＨＤ以降の領域をＭＡＣ層データあるいはＭＡＣ層のペイロードＭＳＤＵと見なせる。同じようにＩＰｖ６ヘッダＩＰｖ６ＨＤ以降の領域をＩＰｖ６層のデータまたはＩＰｖ６のペイロードＩＰｖ６ＤＵ、ＴＣＰヘッダＴＣＰＨＤ以降の領域をＴＣＰ層のデータあるいはＴＣＰペイロードＴＣＰＤＵとも見なせる。

本実施形態で使用する有線通信としては、ローカルな映像信号伝送線や音声信号伝達線から始まり、電話線やインターネットに関連したイーサーネット（Ethernet）（登録商標）対応通信に至るあらゆる通信方式を利用できる。また無線通信としては、ZigBee（登録商標）、Bluetooth（登録商標）、ＵＷＢ（Ultra Wide Band）、Ｚ-Waveなどの近距離無線方式、Ｗｉ－Ｆｉ（Wireless Fidelity）、EnOceanなどの中距離無線方式、２Ｇ／ＰＤＣ、ＧＳＭ（登録商標）（Second Generation / Personal Digital Cellular, Global System for Mobile Communications（登録商標））や３Ｇ／ＣＤＭＡ（Third Generation / Code Division Multiple Access）、ＷｉＭＡＸ（World wide Interoperability for Microwave Access）などの遠距離無線のあらゆる無線通信方式も使用できる。

そして、これらの通信方式毎に適正な物理層ヘッダＰＨＹＨＤとＭＡＣ層ヘッダＭＡＣＨＤ内のデータ構造が予め決まっている。従って、本実施形態では有線通信及び無線通信のいずれに対しても、各通信方式でのデータ通信に対応して物理層ヘッダＰＨＹＨＤとＭＡＣ層ヘッダＭＡＣＨＤを切り替える。このように本実施形態では、通信データ内に図２に示す階層構造を持たせることによって、有線通信か無線通信かを問わず、通信データ内の一部の切り替えのみであらゆる通信方式に準拠した通信データを送受信できる効果を有する。

１．１節内で触れたＩＰアドレスは、図２（ｄ）のＩＰｖ６ヘッダＩＰｖ６ＨＤの領域内に記述される。そして、このＩＰｖ６ヘッダＩＰｖ６ＨＤ内の構造を図３に示す。特に、図３（ｂ）が示す各１６バイトで記述される送信側及び受信側のＩＰアドレス情報ＳＩＰＡＤＲＳ、ＤＩＰＡＤＲＳを格納する領域を持つ所が重要となる。このＩＰアドレスを世界中の全てのエッジ装置１４、１６、１８と全てのデバイス２０、２２、２６、３２、３４、３６に予め設定すると（１．１節）、世界中のどこからでも特定のエッジ装置１４、１６、１８や特定のデバイス２０、２２、２６、３２、３４、３６との間でデータ通信が可能となる効果が生まれる。

ＩＰｖ６ヘッダＩＰｖ６ＨＤ内に形成されている、図３（ｂ）に示す最初の８バイト領域内に、ＩＰパケット関連情報ＩＰＰＫＴが格納される。また、ＩＰｖ６ヘッダＩＰｖ６ＨＤの中は図３（ｃ）のように、先頭情報ＳＩＰＨＤ、ＩＰｖ６データ／ペイロード長さ情報ＬＩＰｖ６ＤＵ、ＩＰｖ６ヘッダの直後に続くヘッダタイプの識別情報ＮＸＨＤ及び通過可能ノード残数情報ＨＰＬＭＴのそれぞれが格納される領域から構成され、それぞれ前記の順番で配置される。このＩＰｖ６データ／ペイロード長さ情報ＬＩＰｖ６ＤＵは図２（ｄ）に示すＩＰｖ６データ／ペイロードＩＰｖ６ＤＵのデータサイズを示し、この情報を格納する領域は２バイトのサイズを有する。

また、上記先頭情報ＳＩＰＨＤの７．５バイト領域内は前から順に４バイトで構成されるバージョン情報ＩＰＶＲＳ、１バイトで構成される交信クラス情報ＩＰＣＬＳ、２．５バイトで構成される通信種別ラベル情報ＩＰＬＢＬが配置される。

ところで、図２では通信経路指定にＴＣＰ（Trasmission Control Protocol）を使用する事を示している。しかし、本実施形態ではそれに限らず、他の実施形態として、ＩＰｖ６ヘッダＩＰｖ６ＨＤの直後にＵＤＰヘッダを配置してＵＤＰ（User Datagram Protocol）を使っても良い。

２．２節 インターネット以外の通信経路で使用される通信データ構造
本実施形態では、図２に示した通信データ構造を基準として通信経路に合わせた最適な階層構造の組み換えが可能となっている。このように基準となる通信データに階層構造を持たせて、通信経路毎の通信データの最適化を図り、効率の良いデータ通信を可能にする効果が生まれる。また、異なる通信経路間で上記階層構造内の一部の共通化を図り、エッジ装置１４、１６、１８やデバイス２０、２２、２６、３２、３４、３６内に組み込まれている通信制御部内の一部の通信データ構造で共通化が図れる効果も有る。

例えば、図１のエッジ装置１６にはメモリデバイス２６とセンサデバイス３６が内蔵されているため、メモリデバイス２６とエッジエージェント４７間あるいはセンサデバイス３６とエッジエージェント４７間では直接にデータの転送が可能である。このデータ転送の際は、ＩＰアドレスの指定などが不要なため、図２に示した複雑なデータ階層構造は冗長となる。従って、本実施形態におけるメモリデバイス２６とエッジエージェント４７との間あるいはセンサデバイス３６とエッジエージェント４７との間では、図２内のデータ制御情報及び通信データ本体ＫＥＹＶＡＬのみの転送を行う。

一方で、図１のセンサデバイス３２、３４とエッジ装置１４との間またはメモリデバイス２２とエッジ装置１４との間では、Ｗｉ－ＦｉまたはZigBeeなどの無線通信が必要な場合は、その無線通信規格に準拠した物理層ヘッダＰＨＹＨＤとＭＡＣ層ヘッダＭＡＣＨＤ（図２）が通信データ内に必要となる。従って、本実施形態では、この通信経路に関してＭＡＣ層データあるいはＭＡＣ層のペイロードＭＳＤＵ内に直接データ制御情報及び通信データ本体ＫＥＹＶＡＬのみを配置する（ＩＰｖ６ヘッダＩＰｖ６ＨＤとＴＣＰヘッダＴＣＰＨＤの配置を省く）。このように図２（ａ）に記載した各ヘッダの配置順を保持したまま、一部のヘッダ配置を削除してデータ通信する方法を通信データ内の階層構造の組み換えと呼ぶ。

２．３節 データ制御情報及び通信データ本体内のデータ構造
図２のデータ制御情報及び通信データ本体ＫＥＹＶＡＬ内のデータ構造を図４に示す。本実施形態では、データ制御情報及び通信データ本体ＫＥＹＶＡＬ内が、先行位置に配置されたデータ制御情報ＫＥＹＰＲＴと後行位置に配置された通信データ本体ＶＡＬＰＲＴとから構成される（図４（ｂ））。

図４（ｃ）が示すように、このデータ制御情報ＫＥＹＰＲＴ内の最初の１バイト領域内に接頭部ＰＲＦＩＸが配置される。本実施形態では、この接頭部ＰＲＦＩＸの中にビット表示で“１１１１１１１１”を設定する。このように“１”が１バイト分連続するため、エッジ装置１４、１６、１８やデバイス２０、２２、２６、３２、３４の通信制御部内でタイミングの同期合わせ（の再設定）を容易にしている。

本実施形態では、ネットワーク間で通信するデータに関しては、先行する制御情報ＣＮＴＩＮＦ（この部分をキーと呼んでも良い）と、それに続く通信データ本体ＶＡＬＰＲＴ（この部分をバリューと呼んでも良い）の組み合わせで構成する。このように通信データ
の基本構成を簡素化して、エッジ装置１４、１６、１８やデバイス２０、２２、２６、３２、３４の通信制御部内の処理を簡素化できるばかりで無く、２．２節で説明したように異なる通信経路内での通信データの一部共通化が図れる効果が生まれる。

本実施形態では、１回のデータ通信で通信可能なデータサイズを２Ｍバイト以下に設定し、長期に亘り連続して多量なデータ通信が必要な場合は複数の物理層フレームＰＰＤＵ（図２（ｆ））に分割してデータ通信させる構造となっている。このように２ＭＢを超えるデータ通信に分割して通信させて、通信経路内の長期占有を禁止して緊急情報通信を可能にする効果が有る。

また、制御情報ＣＮＴＩＮＦの設定可能データサイズを２Ｍに近い範囲まで許容して、複雑な制御情報ＣＮＴＩＮＦの通信を可能にしている。

このように本実施形態では、制御情報ＣＮＴＩＮＦと通信データ本体ＶＡＬＰＲＴのサイズをそれぞれ任意に設定可能にして、データ通信の柔軟性を高める。それに伴い制御情報ＣＮＴＩＮＦのサイズと通信データ本体ＶＡＬＰＲＴのサイズとを個々に通信可能にするため、図４（ｃ）に示すように、制御情報サイズＣＩ＿ＳＺと通信データ本体サイズＤＡＴ＿ＳＺを通知する領域をそれぞれ４バイトずつ設定している。

ここで、制御情報ＣＮＴＩＮＦと通信データ本体ＶＡＬＰＲＴに先行して制御情報サイズＣＩ＿ＳＺと通信データ本体サイズＤＡＴ＿ＳＺの情報を通知可能にして、エッジ装置１４、１６、１８やデバイス２０、２２、２６、３２、３４内の通信制御部でのデータ受信準備をスムーズに行うことができる。

例えば、図１のセンサデバイス３２内に撮像部が内蔵されると共にセンサデバイス３４内に音声入力部が内蔵されて、時系列的に映像変化データや音声変化データの収集が可能な場合には、収集されるセンサデータと共にデータ収集時の日時情報も必要となる。また、図１のセンサデバイス３６内に受光部（光量変化検出可能）が内蔵され、経過時間と共に検出光量の変化を適宜収集する場合にも、センサデータと共にデータ収集時の日時情報も必要となる。

上記の要請に対応するため本実施形態では、図４（ｄ）に示すように、センサで連続して収集されるセンサデータをデータ本体ＤＡＴＡ－１、－２として１８８バイト毎に分割し、それぞれの先行位置に各データ本体ＤＡＴＡ－１、－２のデータ収集時間情報（収集日を含めても良い）をそれぞれ４バイトのタイムスタンプＴＳＴＰ－１、タイムスタンプ－２として挿入しても良い。それにより、センサで連続して収集されるセンサデータの再生時にデータ本体ＤＡＴＡ－１、ＤＡＴＡ－２毎のデータ収集時間情報が確認できるため、（図１のエッジエージェント４４内で）効率良くかつ高い精度でデータ解析が可能となる効果が有る。

ところで、本実施形態では上記のセンサデータ以外に図１の管理情報６２や共通鍵５２、５４、５６５２、５４、５６５２の情報をデータ通信しても良い。この場合にはデータ収集もしくはデータの新規作成や更新を行った日時情報は、必ずしも通信データ本体ＶＡＬＰＲＴ内に混入させる必要は無く、例えばファイル名の一部に記載したりファイルの属性情報として設定しても良い。従って、この場合には図４（ｄ）のようにタイムスタンプＴＳＴＰ－１、－２の混在配置を行わずにデータ本体ＤＡＴＡ－１、－２を詰めて配置し、その中に纏めて前記の管理情報６２や共通鍵５２、５４、５６５２、５４、５６５２の情報を配置しても良い。

図４（ｄ）に示した通信データ本体ＶＡＬＰＲＴ内データ構造の他の応用例を図５に示す。図５では通信データ本体ＶＡＬＰＲＴ自体のデータ内容やデータ属性に関する管理情報を管理パケットＭＮＰＫＴ内に纏めて格納し、通信データ本体ＶＡＬＰＲＴ内部に適宜挿入（管理パケットＭＮＰＫＴを多重化）する。

従来技術では、作成されたデータは作成場所の近くに長期保存される場合が多かった。それに比べて本実施形態では第３章で後述するように、保存データの保存場所（記録場所）が異なる（メモリデバイス２０、２２、２６やメモリ部６内の）メモリ領域へ適宜移動可能となっている。このように所定データの保存場所（記録場所）が異なるメモリ領域へ移動された場合、その移動された所定データの管理情報が途中で紛失されるリスクが増加する。図５のように予め通信データ本体ＶＡＬＰＲＴ内部に挿入された管理情報を再生する事で、別の場所に保管されていた管理情報が紛失しても容易に復元できる効果を有する。それによって、通信データ本体ＶＡＬＰＲＴの信頼性が向上する。

図５（ｂ）の応用例では、通信データ本体ＶＡＬＰＲＴ内が１個以上の通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２から構成されて、各通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２内の先頭位置に管理パケットＭＮＰＫＴ－１、ＭＮＰＫＴ－２を配置する。この通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２の切れ目位置は、通信データ本体ＶＡＬＰＲＴ内のコンテンツ内容の変化位置に対応しても良いし、所定の経過時間毎に分割されても良い。或いは所定のデータサイズ毎に機械的に通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２に分割されても良い。

図５（ｂ）において通信データ本体内パックＶＡＬＰＣＫ－１内にＭ個の１８８バイト毎のデータ本体ＤＡＴＡ－１～ＤＡＴＡ－Ｍが含まれ、本体内パックＶＡＬＰＣＫ－２内にはＮ個のデータ本体ＤＡＴＡ－１～ＤＡＴＡ－Ｎが含まれている。上述したように通信データ本体ＶＡＬＰＲＴ内のコンテンツ内容に応じて通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２の切れ目が異なる場合には、前記ＭとＮの値が異なる（Ｍ≠Ｎ）。

また一定の時間間隔毎に分割する場合でも、映像のシーンに応じて映像圧縮率を変化させる場合には通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎のデータサイズが異なる。それに比べて所定のデータサイズ毎に機械的に通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２が分割される場合には、全ての通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２のサイズが一致する（Ｍ＝Ｎ）。

ところで、通信データ本体ＶＡＬＰＲＴ内のコンテンツ内容の変化位置に対応して通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２の切れ目位置を自動設定する方法として、図１４のステップ３８（３．２節参照）が示すようにセンサデバイス３２が収集したセンサデータをエッジエージェント４４（または図示して無いがセンサデバイス３２内に実装されたデバイスエージェント）が自動的にデータ解析して通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２のサイズを自動的に設定しても良い。

なお、本実施形態として図４（ｄ）や図５（ｂ）の構造に限定されず、例えばタイムスタンプＴＳＴＰを挿入しない構造や、通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２を形成せずに一定間隔毎に管理パケットＭＮＰＫＴが挿入された構造でも良い。

図５（ｃ）のように、各管理パケットＭＮＰＫＴの先頭位置には、管理パケット識別情報ＭＮＰＫ＿ＩＤが配置されている。この管理パケット識別情報ＭＮＰＫ＿ＩＤ内の具体的なコード内容として、通信データ本体ＶＡＬＰＲＴ内の他の部分では発生しない特殊コードを設定しても良い。一般的にネットワーク上で通信されるデータの多くは、変調後のコードで送信される場合が多い。例えば変調後のバイナリコード内で“１”が連続する（途中で“０”が配置されない）回数の上限値をｍとした時、この管理パケット識別情報ＭＮＰＫ＿ＩＤ内で“１”をｍ＋ｎ回（ｎは１以上の正数値）連続するコードを含めると、通信データ本体ＶＡＬＰＲＴ内の他の部分では発生しない特殊コードが設定できる。それによりエッジエージェント（またはデバイスエージェント、スモールエージェント）は、管理パケットＭＮＰＫＴ位置の抽出が容易となる。

前述したようにタイムスタンプＴＳＴＰサイズが４バイトでデータ本体の塊ＤＡＴＡ－１、ＤＡＴＡ－２が１８８バイトなので、管理パケットＭＮＰＫＴサイズを１９２バイトの整数倍にするとエージェント側で処理がし易くなる。また通信データ本体ＶＡＬＰＲＴのコンテンツ内容に応じて内部に挿入する情報内容を柔軟に変化できるように、管理パケットＭＮＰＫＴサイズは可変にする。それに対応して、管理パケットＭＮＰＫＴ毎の管理パケットサイズＭＰＫ＿ＳＺを管理パケット識別情報ＭＮＰＫ＿ＩＤ直後に配置する。それによりエッジエージェント（またはデバイスエージェント、スモールエージェント）は、管理パケットＭＮＰＫＴと他のパケット間の識別が容易となる。

更に管理パケットＭＮＰＫＴ内に通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎のパックサイズの情報（通信データ本体内パックサイズＶＰＫ＿ＳＺ）を持たせる事で、エッジエージェント（またはデバイスエージェント、スモールエージェント）は通信データ本体ＶＡＬＰＲＴ内の管理パケットＭＮＰＫＴのみの抽出が容易となる。

センサデバイス３２、３４、３６が収集するセンサデータの管理情報として本実施形態では、データ検索を容易にする情報やデータに関する時間や期間を管理する情報、データ公開可否や公開時の課金に関する情報を管理パケットＭＮＰＫＴ内に格納しても良い。

センサデータにデータ検索を容易にする下記情報を付随させると、インターネット２上で必要なデータの検索が容易となる効果が有る。１．１節内でエッジ装置１４、１６、１８や各種デバイス２０、２２、２６、３２、３４、３６にエッジエージェント４４、４７、４８やスモールエージェント４０、デバイスエージェント４２，４６を持たせて、得られたデータの解析が行える説明をした。そしてデータ解析結果として抽出されたキーワードや記号／アイコンをタグ化してデータ検出タグ情報ＤＳＲＣＴＧ内に格納し、図１４の管理パケット自動生成ステップ５１で管理パケットＭＮＰＫＴを自動生成する。なお前記データ検索タグ情報ＤＳＲＣＴＧ内に格納可能な情報はこれに限らず、データ検索に関係したいかなる情報を格納しても良い。

管理パケットＭＮＰＫＴ内に格納可能な期間管理情報ＴＭＭＮの中で、データ作成年月日ＤＹＭＤの情報は、データが作られた日時を意味する。ここでこの年月日情報の記載方法は本節内で図８を用いて後述するように、ＩＳＯ（国際標準）８６０１で規定された日時の表示方法を採用する。このデータ作成日時の一種は、センサデバイス３２，３４、３６に拠るセンサデータの収集日時を意味する。またそれと並行して図１４のステップ３４やステップ３６が示す（３．２節で後述する）ように、センサデータに対する加工後のデータの作成も行う。従って加工後のデータや解析後のデータに対しては、データ加工した日時またはデータ解析した日時の情報もデータ作成年月日ＤＹＭＤの情報に該当する。

日本では、一時期“タイムマシン記念品保存”が流行した。例えば、小学校や中学校卒業時に卒業生が記念品を校庭の地面の下に埋め、２０年か３０年後にそれを掘り起こして当時を懐かしむ風習が存在した。このように昔を懐かしむため、特定データの保存後は（例えば２０年とか３０年間の）特定期間にわたり使用を不可能にできる。それを可能にするため、非転送期間ＮＴＴＮを期間管理情報ＴＭＭＮ内に格納し、その期間は保存したメ
モリデバイス２２（またはメモリ部６）からの転送を禁止しても良い。同様にネットワーク経由でのデータ通信（転送）は許可するが、所定の期間は再生を禁止する場合、非再生期間ＮＤＳＴＭを記録するメモリデバイス２２（またはメモリ部６）の領域内に非再生期間ＮＤＳＴＭに対応する情報（例えばメッセージ、静止画データなどの付属的なデータ）を格納しても良い。

多くの国の特許制度では、出願から１．５年間は非公開時期に設定して出願人の便宜を図っている。このように“データ作成日から特定期間経過した後はデータの公開を許可”が必要となるデータも存在する。この要求に答えるため、本実施形態では管理パケットＭＮＰＫＴ内の期間管理情報ＴＭＭＮを格納できる領域内に非公開期間ＮＰＵＢＴＭを設定しても良い。例えば、データ作成年月日ＤＹＭＤからこの非公開期間ＮＰＵＢＴＭを加算した後の日時からデータを公開可能とする。

センサデバイス３２、３４、３６で収集したデータやユーザが作成したデータの活用方法として、“公開範囲を限定したらデータ公開しても良い”とか“公開料金を徴収できればデータ公開しても良い”などの社会的ニーズがある。本実施形態では、データ公開に関する情報やその時の課金に関する情報をデータ本体と共にデータ通信可能となっている。その結果として蓄えたデータを多くの人による活用を可能にして社会の活性化を促進できる効果がある。また、上記期間管理情報ＴＭＭＮとして格納される情報は上記に限定されず、時間や期間に関係するあらゆる情報をここに格納しても良い。

上記のデータ公開／課金関連情報を格納可能な領域として、管理パケットＭＮＰＫＴ内にデータ公開／課金情報ＤＴＰＵＢを格納する領域を設定しても良い。データ公開可否やデータ公開時の課金額に関して決定する人（または組織）を明示したデータ管理者識別情報（ＩＤ）ＤＭＮ＿ＩＤをデータ公開／課金情報ＤＴＰＵＢの先頭位置に配置して、分散サーバ群４や各種エージェント４０、４２、４４、４６、４７、４８がデータ公開可否の判定を早期に行える効果がある。ここでの“データ公開”とはデータ閲覧のみに限らず、そのデータの使用やデータ加工も含めた“データ活用の許容”を意味する。

なお、データ毎にデータ公開クラスＤＰＵＢＣＬを明記しても良い。最も広いデータ公開レベルとして、インターネット２の回線を用いて“誰でも活用（閲覧／使用／加工）可能”なレベルが考えられる。この公開レベルではインターネット２の回線内に限らず、プリントアウトした紙ベースでの閲覧やＵＳＢメモリなど非ネットワークのデータ記憶媒体にデータコピーしてデータ使用する場合も許容される。

本実施形態では、次に狭いデータ公開レベルとして、特定の分散サーバ群４が管理する特定のネットワークドメイン内での公開管理を行っても良い。この特定のネットワークドメインとは、例えばユーザＩＤとパスワード１０（図１）を用いて所定組織が管理するインターネット２の回線にアクセスできる場合を意味する。この場合の所定組織とは、特定の国家や企業、ＮＰＯ法人、サービス対象グループなどを想定している。

上記の場合、この所定組織に所属しているが特定の業務に関与しているグループメンバー、あるいはフォーラムなどの複数の異なる組織に跨るが共通目的の活動に参加するグループメンバーのみがデータ活用が許容される場合が考えられる。そして、データ公開クラスＤＰＵＢＣＬとしては上記ネットワークドメイン内でのデータ公開よりは公開範囲が狭くても良い。このグループメンバーとは、予め規定された特定のＳＮＳ（Social Network Service）の参加メンバーや特定メーリングリストに登録されたメンバーなどが含まれても良い。

最もデータ公開クラスの狭い範囲として、データ作成者本人及び／あるいはデータ作成者本人が指定した人のみの範囲での公開を規定しても良い。特に、図５（ｅ）のデータ公開クラスＤＰＵＢＣＬは“無料公開を許容するデータ公開範囲を規定したクラス”を意味しているが、本実施形態ではそれに限らず、特定の公開料金以下を設定したデータ公開範囲を規定しても良い。

例えば、「無料のデータ公開は禁止するが、データ公開料金の収入が得られるならデータ公開しても良い」と考えるユーザも存在する。この要求に答えるため、本実施形態では、データ公開クラス毎にデータ公開時に得られる収入額を細かく設定可能となっている。即ち、インターネット２上で完全にオープンにする時の公開料金ＦＥＥＯＰＮ及びネットワークドメイン内公開料金ＦＥＥＤＭＮ、特定グループメンバー内公開料金ＦＥＥＭＭＢをそれぞれ個別にデータ公開／課金情報ＤＴＰＵＢの記録領域内に設定しても良い。

ここで公開料金の設定方法として、通信データ本体内パックＶＡＬＰＣＫ毎の月額公開料金をドル建てまたはセント建てで設定しても良い。また上記領域に金額を設定する代わりに“No”や“forbiddance”、“forbidden”を記述して、“データ公開禁止”を明示しても良い。

図１２を用いて３．２節内で後述するように、センサデータによってはデータ公開／課金に関係するユーザ人数が時々刻々変化する場合がある。その場合、例えばデータ公開／課金に関係するユーザが変化する毎に通信データ本体内パックＶＡＬＰＣＫを分割し、通信データ本体内パックＶＡＬＰＣＫ毎にデータ公開クラスや公開料金を細かく設定しても良い。このように、本実施形態では通信データ本体内パックＶＡＬＰＣＫ毎に配置された管理パケットＭＮＰＫＴ毎にデータ公開／課金情報ＤＴＰＵＢを設定できるので、データ内に含まれるユーザが頻繁に変化する状況に関しても細かくデータ公開／課金の管理が行える効果がある。なお、上記のデータ公開／課金情報ＤＴＰＵＢ内に格納可能な情報はこれだけに限らず、データ公開や課金または料金に関係したあらゆる情報をこの領域内に格納しても良い。

図４（ｃ）の制御情報ＣＮＴＩＮＦ内の記述方法を図６に示す。この制御情報ＣＮＴＩＮＦ内の先頭位置に制御タイプＣＴＴＹＰＥが記載される事で、エッジ装置１４、１６、１８やデバイス２０、２２、２６、３２、３４内の通信制御部での迅速な受信対応を可能にする効果がある。また、規格策定時のバージョンアップ毎に制御情報ＣＮＴＩＮＦ内の記述方法が逐次変化する。従って、その逐次変化に迅速に対応できるように、制御タイプＣＴＴＹＰＥの直後に“／”を配置してバージョン情報ＶＥＲＩＮＦを記載する。また、図７を用いて後述するように、制御タイプＣＴＴＹＰＥの内容毎に必要な対応パラメータが異なる。従って、バージョン情報ＶＥＲＩＮＦの直後に“／”を配置し、その後に対応するパラメータ情報ＰＡＲＡＭＴが記述される。

本実施形態におけるパラメータ情報ＰＡＲＡＭＴ内の記述情報例を図６（ｂ）に示す。センサデバイス３２、３４、３６（図１）から収集されたオリジナルなセンサデータ（及びそのセンサデータを解析した結果得られるアナライズドデータ）は、メモリデバイス２０または２２、２６あるいは分散サーバ群４内のメモリ部６内に格納（記録または保存）される。この保存場所が“｛－｝”内のデータ格納場所情報ＴＥＮＴＩＤの記述場所内に記述される。その際、インターネット２に対応してＵＲＩ（Uniform Resource Identifier）で記述される。一般に前記ＵＲＩの記述方法として、例えば“//www.**.co.jp/$$$”などドメイン名から記述される場合が多い。しかし、例えばメモリデバイス２０など孤立して存在する場合には、１．１節または図３（ｂ）を用いて２．１節内で説明したＩＰアドレスを直接記述しても良い。また、ＵＲＩとしてＩＰアドレスを直接に記述する場合、その中のパーティションＩＤやそれに対応したドライブＩＤ情報も従属して記述しても良い。

図１の記載例では、センサデバイス３２、３４、３６から得られたセンサデータや管理情報６２や共通鍵５２、５４、５６５２、５４、５６５２のデータに関するデータ通信を示した。しかし、本実施形態ではそれに限らず、非ファイルデータやアナログデータを量子化した後のデータなどあらゆる種類のデータを扱える。この場合は、管理情報６２や共通鍵５２、５４、５６５２、５４、５６５２などのファイル形式で記録されたデータをＰＣデータ、静止画像などのデータをイメージデータ、動画や音声データをストリームデータなどと暫定的に呼び、所定期間連続して時間変化状態を検出するデータ（センサデータなど）をリアルタイムデータと呼ぶ。しかし、このような種別分類に限らず、例えばイメージデータやストリームデータ、リアルタイムデータを総称してオブジェクトデータに種別するなど別の種別分類方法を使用しても良い。このようなデータの種別情報を図６（ｂ）のように“／－／”内に記述しても良い。

図１のセンサデバイス３２、３４、３６から得られたセンサデータに限らず、あらゆる種別のデータを効率良くデータ受信できるように、通信されたデータ毎にデータ識別情報ＤＡＴＡＩＤがパラメータ情報ＰＡＲＡＭＴ内に“｛－｝”の形で記述しても良い。更に、通信データまたは通信方法に関する各種の属性は、属性情報ＡＴＲＩＢＴとして“｛－｝”内に纏めて記述される。そして、属性情報ＡＴＲＩＢＴの内容またはパラメータ情報ＰＡＲＡＭＴが複数存在する場合には、それぞれを『"-":"$$$"』の形式で記述し、それぞれを『カンマ（ ，）』で繋いでも良い。

本実施形態で扱われるデータ通信の制御内容の例を図７に示す。図６（ａ）内に記述される制御タイプＣＴＴＹＰＥとして、データ受信やデータ収集のリクエストとレスポンスに関わる“ＧＥＴ”、データ送信やメモリデバイス２０、２２、２６あるいはメモリ部６内への保存制御に関わる“ＰＵＴ”、データ削除に関わる“ＤＥＬＥＴＥ”などを定義しても良い。また、上記に限らず、他のタイプの制御タイプＣＴＴＹＰＥを定義しても良い。

図６（ａ）のパラメータ情報ＰＡＲＡＭＴとして記述する内容として本実施形態では、図７に示すように対応するパラメータ内容が事前に設定されている。例えば、“ＧＥＴ”に対応したパラメータとして“リクエスト”（１．１節）に関係するリクエストパラメータや“レスポンス”（１．１節）に関係するレスポンスパラメータの内容が予め規定されている。同様に制御タイプＣＴＴＹＰＥとして“ＰＵＴ”や“ＤＥＬＥＴＥ”に対してもリクエストパラメータの内容が予め規定されている。

１．１節内で従属側が主導側に対して“ステータス”の送信を行う事を既に説明した。 “ステータス”の一種として、例えばセンサデバイス３２、３４やメモリデバイス２０、２２、２６内におけるリスクの事前警告（警報通知）を行う“ＡＬＥＲＴ”を定義しても良い。この“ＡＬＥＲＴ”に関しては、ステータスパラメータの内容が事前に規定されている。

図６で説明した記述ルールに従った制御情報ＣＮＴＩＮＦ内の記述例を図８に示す。ここでは前述したように、所定の期間内に連続してセンサデバイス３２、３４、３６から得られたセンサデータをリアルタイムデータ（real-time data or RTdata）に種別を分類する。

このリアルタイムデータに関する“ＧＥＴ”を用いたリクエスト時の記述例を図８（ａ）に示し、“ＧＥＴ”を用いたレスポンス時の記述例を図８（ｂ）に示す。更に“ＧＥＴ”を用いたリクエスト時の記述例を図８（ｃ）に示す。いずれの場合も、通信されるリアルタイムデータの識別情報を“＄＄＄”で表し、『"RTdata_id":"$$$"』と記述した。ま
た図８（ｂ）（ｃ）の“real-time data”は通信データ本体ＶＡＬＰＲＴ（図４８（ｂ））を意味し、参考までに付加して記載した。

リアルタイムデータの受信要求をする場合、このリアルタイムデータが収集された期間を設定する必要が有る。そのため、受信要求されたリアルタイムデータの収集期間を『"Time-Zone":"###-##&"』で記述した。ここで『###』がデータ収集開始日時情報（通信を開始する場所のデータ収集日時情報）を示し、『##&』がデータ収集期間情報（通信を終了する場所までのデータ収集期間情報）を意味する。

本実施形態では日時情報の表示方法としてＩＳＯ（国際標準）８６０１で規定された日時の表示方法を採用する。例えば“２０１５年８月２７日９時４９分５８秒から５分間”を表示する場合、“2015-08-27T09:49:58-05:00”と表示する。データ収集（送信開始場所）の終了日時を記載する代わりに、上述の“期間情報”を記述すると、記述情報全体のデータサイズが短くなるばかりでなく、細かな時間間隔制御が容易かつ正確に行える効果がある。また、上記のように既に世界標準で規格化された記述方法を利用する事で、世界中の至る所で共通に時間管理が行える効果もある。

“ＧＥＴ”をリクエストした側は、通信される通信データ本体ＶＡＬＰＲＴのサイズを事前に知らない。それに対して、図８（ｂ）のようにデータサイズを事前通知する事で受信側で準備する（記録／保存に利用する）メモリ領域内のサイズが分かる。そのため、受信側でのデータ記録／保存あるいは表示の準備が円滑に進む効果がある。図８（ｂ）において『content-length』は通信データ本体ＶＡＬＰＲＴのデータサイズを示す事を意味し、実際のデータサイズは『％％％』内にバイト単位で記述される。

図８（ｃ）に基づいた他の応用例として、図６（ａ）のパラメータ情報ＰＡＲＡＭＴ内をより細かく規定した記述文例を図８（ｄ）に記載する。ここでは、データ検索に利用される検索関連情報ＳＲＣＩＮＦ、データ管理上の各種時間情報（期間情報）に関係する期間管理情報ＴＭＭＮ、通信データ本体ＶＡＬＰＲＴ全体のデータ公開条件や課金情報に関係するデータ公開／課金情報ＤＴＰＵＢ、通信データ本体ＶＡＬＰＲＴのデータ内容やデータ属性あるいはデータの保存場所に関する配置情報などを示すデータ本体属性情報ＤＴＡＴＴＲなどを記述しても良い。

図５（ｃ）～（ｅ）で記載した管理パケットＭＮＰＫＴ－１、ＭＮＰＫＴ－２の内容は通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎に変化し得る情報に対し、図８（ｄ）で記述される内容は通信データ本体ＶＡＬＰＲＴ（図３（ｂ））全体に関係した共通情報が記載される。また管理パケットＭＮＰＫＴの情報はデータ本体ＤＡＴＡ－１、ＤＡＴＡ－２が記録されるメモリ領域内に一緒に記録されるのに比べ、図８（ｄ）の記述内容は図１の管理情報６２、６４、６６と連動すると共にメモリ領域内の記録場所にも関係する。

図９Ｂのステップ２及び図１４のステップ３２やステップ３８が示すように本実施形態では、センサデバイス３２、３４、３６内のデバイスエージェントやエッジエージェント４４、４７、４８内でセンサデータ収集と同時にそのデータの解析を行う。その結果抽出された通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎の検索用キーワードは逐次管理パケットＭＮＰＫＴ内に記録される。そして全ての通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２で共通に抽出されたキーワードあるいは抽出頻度が多いキーワードが選択され、検索関連情報ＳＲＣＩＮＦの一部として記述できる。

ここに記載する検索用キーワードは、（図４（ｃ）の制御情報ＣＮＴＩＮＦとして許容される最大情報サイズ２Ｍバイトを超えない範囲で）数多く記載しても良い。そのため、
記載された検索用キーワードの数が、“number_of_Key-word”の値に入る。この場合に記載される検索用キーワードは、“key-word”で定義された領域の後にカンマ（，）で区切られて連続して記述される。なお、本実施形態では上記に限らず、他のデータ検索に役立ついかなる情報をも検索関連情報ＳＲＣＩＮＦの一部として記述しても良い。

期間管理情報ＴＭＭＮが記載される領域内で記述される“Record-start_Time”は、データ収集を開始した日時情報がＩＳＯ（国際標準）８６０１に対応して示される。また、対応する通信データ本体ＶＡＬＰＲＴを特定期間使用不可能にしたい場合は、“Forbidden-Transmission_Period”によって使用不可能期間を指定する。つまり、データ収集を開始した日時（Record-start_Time）から所定期間（Forbidden-Transmission_Period）経過後に初めて、対応する通信データ本体ＶＡＬＰＲＴをネットワーク経由でのデータ通信が許可される。

３．３節または３．４節で後述するように本実施形態では、将来的に通信データ本体ＶＡＬＰＲＴが分散サーバ群４内のメモリ部や他のメモリデバイス２０、２６内に移動される場合がある。この場合にデータ移動先でどの程度保存期間を保障すべきか否かについて、“Preservation_Period”で規定できる。即ち、“Preservation_Period”は、データ収集を開始した日時から保証される保存期間（消去禁止期間）を示す。但し、この期間中は、データ本体全体の消去は禁止されるが、一部の修正や部分削除は許される。

なお、上述した情報に限らず、時間や期間に関連したあらゆる情報を期間管理情報ＴＭＭＮの一部として記述しても良い。例えば、図１のセンサデバイス３２、３４から収集されたセンサデータ（あるいは解析後に得られたデータ）はエッジエージェント４４内で前述した検索関連情報ＳＲＣＩＮＦや期間管理情報ＴＭＭＮが付加され、図４（ａ）（ｂ）が示すデータ制御情報及び通信データ本体ＫＥＹＶＡＬの通信データが生成される。ここで生成された通信データはネットワーク通信経路を経由してメモリデバイス２２内のデバイスエージェント４２に渡される。その後でデバイスエージェント４２はデータ制御情報ＫＥＹＰＲＴと通信データ本体ＶＡＬＰＲＴに分離し、通信データ本体ＶＡＬＰＲＴのみをメモリデバイス内のオリジナルデータのメモリ領域（あるいはアナライズドデータのメモリ領域）内に記録する。一方、デバイスエージェント４２内で分離抽出されたデータ制御情報ＫＥＹＰＲＴはフォーマット変換されて管理情報６２内に格納される。

将来、この通信データ本体ＫＥＹＶＡＬ（或いはその一部）を分散サーバ群４内のメモリ部や他のメモリデバイス２０、２６内に移動する場合には、この管理情報６２内から必要な情報を抽出してデータ制御情報ＫＥＹＰＲＴを生成した後、データ制御情報及び通信データ本体ＫＥＹＶＡＬの形でデータ通信する。

一方、図８（ｄ）のデータ公開／課金情報ＤＴＰＵＢは、メモリ領域内の記録場所に影響する。本実施形態では、図１０を用いて３．３節で後述するように、データ公開クラスに応じてメモリ領域内の記録場所を変える事が出来る。従って、図８（ｄ）に示すデータ公開／課金情報ＤＴＰＵＢ内の“Publication_Class”の記載内容（pbc）に応じてメモリデバイス２２内でデータを保存する場所を変えても良い。

既に図５（ｅ）で説明したように、通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎にデータ公開クラスＤＰＵＢＣＬを変えても良い。従って、“Publication_Class”として記述する公開クラスは、全通信データ本体内パックＶＡＬＰＣＫ内で設定されたデータ公開クラスＤＰＵＢＣＬの中で最も緩い公開クラスを記載しても良い。その“Publication_Class”の記述内容に応じてメモリデバイス２２内のデータ保存場所が決まる。そして将来のデータ通信時にデバイスエージェント４２またはエッヂエージェント４４が通信データ本体内パックＶＡＬＰＣＫ－１、ＶＡＬＰＣＫ－２毎のデータ公開クラ
スＤＰＵＢＣＬを解釈し、データ再生もしくはデータ通信して良い通信データ本体内パックＶＡＬＰＣＫの選別を行っても良い。

同様にデータ公開／課金情報ＤＴＰＵＢ内の“Publication_Fee”で記述する公開料金は、全通信データ本体内パックＶＡＬＰＣＫ内で設定されたデータ保存場所に対応した公開料金の中で最も安い金額を記載する。このように最も安い金額や最も緩い公開クラスを記述すると、将来に必要なデータ検索の際、検索の間口を広げる効果が生まれる。なお、上記に説明した情報に限らず、データ公開や公開料金あるいは課金に関係したあらゆる情報をデータ公開／課金情報ＤＴＰＵＢの一種として記述しても良い。

特に、公開範囲に制限が掛かったデータをインターネット２を経由してデータ通信する場合は、分散サーバ群４のメモリ部６内またはメモリデバイス２２、２６内に予め記録された共通鍵５４を用いて暗号化されたデータが送信される。この時のデータ通信形態をデータ本体属性情報ＤＴＡＴＴＲ内の“Encryptiuon”の値として記述される。即ち、通信データが暗号化（encryption）されている場合は、その値が“yes”と記述される。一方で、非暗号化（plane）の状態で通信される場合は、その値が“No”と記述される。

図１９Ｂを用いて３．４節で説明するように、通信データ本体ＫＥＹＶＡＬを分散サーバ群４内のメモリ部や他のメモリデバイス２０、２６内に分散配置された場合、図１の管理情報６２、６４、６６内にはその状況が記録されている。そして、この分散配置された情報の一部をネットワーク経由で移動させる場合、“Data-Distribution”の値を“Yes”に記載する事で関連するデータが分散配置している事を通知できる。この情報によって、受信側が関連データが分散配置されているか否かを容易に理解できるため、データ管理が容易となる効果がある。ところで、分散配置されている関連データに関しては図２１を用いて３．５節で後述するように、インターネット２経由での問合せを利用して、関連データを全て集められる。

本実施形態において、保存されたデータの信頼性を保証する方法の一例として、冗長（パリティ）コードを用いてエラー訂正する方法を第５章で図２４を用いて後述する。このように同一ＥＣＣ（Error Correction Code）ブロック内のデータの分散配置有無を、“Block-Distribution”で明記しても良い。この値が“Yes”の場合は、ＥＣＣブロック内が分散配置されているので、メモリデバイス２０、２２、２６のいずれかが故障またはネットワークシステムから離脱してもエラー訂正機能で復元できる効果がある。

このデータ制御情報ＫＥＹＰＲＴ（図４（ｂ））をインターネット２の通信回線を使った送信する場合には、図８のようにテキスト形式で記述できる。一方、非インターネットの通信回線を使う場合、例えば図１の内蔵されたセンサデバイス３６やメモリデバイス２６内のデバイスエージェント４６にテキスト（キャラクタ）を解釈する機能を要請するには負担が掛かり過ぎる。従って、本実施形態ではこのような通信回路を用いたデータ通信の場合は、図８に示した記述内容（各キャラクタ）に対応したコードデータのみをデータ通信する。そして、デバイスエージェント４６内にコードデータと処理内容間の対応テーブルを事前に持たせて、負担軽減しつつデバイスエージェント４６のデータ通信制御を可能にする。

第３章 ネットワーク経路内でのデータ通信方法
第２章で説明した構造を有する通信データを用い、実際にネットワーク経路内でデータ通信する方法について説明する。特に、本実施形態ではエッジ装置１４、１６、１８内にエッジエージェント４４、４７、４８が常駐するだけで無く、各種デバイス２０、２２、２６、３２、３４内にスモールエージェント４０やデバイスエージェント４２の駐在が可能なため、それらが自律的な処理機能を持つ。この自律的な処理機能を利用した実施形態
を中心に説明する。

３．１節 データ収集とデータ解析
上記のエージェントによる自律的な処理機能を利用した最初の実施形態として、データ収集と同時並行して収集したデータの解析を行い、収集した生データと並行して解析結果のデータを保存する処理方法について説明する。特に、ここではセンサデバイス３２、３４、３６などから長期間に亘って連続して収集されるデータを扱い、データの解析結果に基づいてエンドユーザに対する新たなサービスを提供しても良い。その際、特に行動中のエンドユーザに対するサービス提供が可能となる。更に、この解析結果に基づき、ユーザの行動推定やユーザの要求推定に利用しても良い。

例えば、昼間に元気なユーザが長時間睡眠を取り続ける事は稀で、多くの場合はエンドユーザが活発に活動している。本実施形態ではデータ収集と同時にエッジエージェント４４、４７がリアルタイムでデータ解析を行うため、そのユーザの活発な行動中に適正なタイミングで新たなサービスを提供できる効果がある。

図９Ａに示す実施形態を用い、撮像機能を有するセンサデバイス３２と音声入力機能を有するセンサデバイス３４、及び光量変化を検出する機能（光センサ機能）を有するセンサデバイス３６から同時にエンドユーザの行動に関係するセンサデータを収集する場合（図９Ｂのデータ収集ステップ１）の実施形態について説明する。この場合のデータの通信経路とデータ通信の流れを図９Ａに示し、その時の動作フローを図９Ｂに示す。

センサデバイス３２とセンサデバイス３４で収集されたオリジナルデータｄはエッジエージェント４４に向けて送信され、このエッジエージェント４４内でデータ解析（図９Ｂのデータ解析ステップ２）される。またこのオリジナルデータｄは並行してメモリデバイス２２内に保存される（図９Ｂの生データの保存ステップ３）。ところで、前記エッジエージェント４４内でのデータ解析に直前のオリジナルデータｃが必要な場合は、適宜メモリデバイス２２内からエッジエージェント４４へ向けてデータ送信される。

それと同時にセンサデバイス３６で収集されたオリジナルデータｅはエッジエージェント４７に向けて送信され、このエッジエージェント４７内でデータ解析（図９Ｂのデータ解析ステップ２）される。またこのオリジナルデータｅは並行してメモリデバイス２６内に保存される（図９Ｂの生データの保存ステップ３）。

図９Ａに示したセンサデバイス３２、３４、３６からエッジエージェント４４、４７へ向けたオリジナルデータｄ、ｅに関する具体的なデータ通信方法について、第２章で説明した内容を利用して説明する。まず始めに、エッジエージェント４４、４７からセンサデバイス３２、３４、３６に向けて制御タイプＣＴＴＹＰＥとして“ＧＥＴ”の“リクエスト送信”を行う。次に、このエッジエージェント４４、４７からの“リクエスト”に対応して、センサデバイス３２、３４、３６からエッジエージェント４４、４７へ向けた“ＧＥＴ”の“レスポンス送信”を行う。そして、この“レスポンス送信”時に通信本体ＶＡＬＰＲＴの配置領域内（図４（ｂ））にオリジナルデータｄ、ｅを入れてデータ通信する。

また、エッジエージェント４４、４７からメモリデバイス２２、２６へ向けてオリジナルデータｄ、ｅをデータ通信する場合には、エッジエージェント４４、４７からメモリデバイス２２、２６へ向けて制御タイプＣＴＴＹＰＥとして“ＰＵＴ”のデータ通信を行う。なお、この時には、通信本体ＶＡＬＰＲＴの配置領域内にはオリジナルデータｄ、ｅが入っている。

エッジエージェント４４、４７内で行われる簡易的なデータ解析は、エンドユーザに対する新たなサービス提供を目的として行われる。例えば、センサデバイス３２の有効視野内に映った個々のユーザ（人間に限らず動物でも良い）に対し、その顔や身体的特徴とのパターンマッチング手法を用いて有効視野内のユーザ個々の識別を行っても良い。それと並行して、センサデバイス３４から収集した音声データとユーザ個々の声紋との間のパターンマッチングを行い、話しているユーザの推定を行っても良い。また、センサデバイス３６からの収集データを用いて部屋毎の照明器具の点滅状況推定を行っても良いし、センサデバイス３６を人感センサとして用いた場合の収集データからユーザの動きを検出しても良い。

その解析の結果で得られるデータをアナライズドデータｄ’、ｅ’として、ユーザ毎の居場所や移動状態を抽出できる。もしも、メモリデバイス２２や２６の記録容量が少ない場合には、その解析結果から所定範囲内の人間と動物の個体数のみを抽出してアナライズドデータｄ’、ｅ’にしても良い。そして、ここで得られたアナライズドデータｄ’、ｅ’は図９Ｂのステップ３に示すように、メモリデバイス２２、２６内に適宜記録される。

この時のエッジエージェント４４、４７からメモリデバイス２２、２６へ向けたアナライズドデータｄ’、ｅ’（エッジエージェント４４、４７内で生成された解析後のデータ）のデータ通信方法としては、エッジエージェント４４、４７からメモリデバイス２２、２６へ向けて送信される制御情報ＣＮＴＩＮＦ内の制御タイプＣＴＴＹＰＥとして“ＰＵＴ”のデータ通信を行う。ここで、通信本体ＶＡＬＰＲＴの配置領域内にはアナライズドデータｄ’、ｅ’が入っている。

図９Ｂのステップ４で示すエッジエージェント４４、４７がエンドユーザに対して行う簡易的サービスの提供内容は、例えば“特定部屋に対する人や動物の出入りに対応して自動的に照明スイッチのオンオフや、エアコンの温度や湿度を自動的に変化させる”レベルとなる。

図９Ａでは、固定位置にセンサデバイス３２、３４、３６が配置された例を示している。しかし、それに限らず他のデータ解析を行っても良い。例えばネットワーク接続可能な乗り物（connected Car / connected Bus / connected Truck）の場合には、センサデータの解析結果として“急加速／急発進の状態”や“運転手や乗客があくびをしたか？”などのアナライズドデータが得られる。

本実施形態では、上記だけに限らず図９Ｂステップ５の“解析後データの送信”ステップでは、解析後に得られたアナライズドデータｄ’、ｅ’を分散サーバ群４へ向けてデータ通信しても良い。この場合のデータ通信方法として、エッジエージェント４４、４７から分散サーバ群４へ向けて送信される制御情報ＣＮＴＩＮＦ内の制御タイプＣＴＴＹＰＥは“ＰＵＴ”となり、通信本体ＶＡＬＰＲＴの配置領域内にはアナライズドデータｄ’、ｅ’が入る。

なお、図９Ａに示すように、メモリデバイス２２、２６と分散サーバ群４内のメモリ部６には共通な共通鍵５４がそれぞれ格納されている。従って、インターネット２を経由で前記のアナライズドデータｄ’、ｅ’の通信時には、この共通鍵５４を使ったアナライズドデータｄ’、ｅ’を暗号化した後のデータを通信本体ＶＡＬＰＲＴの配置領域内に入れても良い。それにより、セキュリティ的に高い信頼性を確保できる効果がある。

図９Ａに示すように、エッジエージェント４４、４７と分散サーバ群４間はインターネット２を経由したデータ通信となる。従って、この際の通信データ構造は図２の構造を取る。前述したように、エッジエージェント４４、４７と分散サーバ群４（の受け入れ
窓口サーバ）はそれぞれ独自のＩＰアドレスが事前に設定されている。従って、この場合の送信側ＩＰアドレス情報ＳＩＰＡＤＲＳの配置領域内（図３（ｂ）参照）には、エッジエージェント４４、４７のＩＰアドレスが入り、受信側ＩＰアドレス情報ＤＩＰＡＤＲＳの配置領域内には分散サーバ群４（の受け入れ窓口サーバ）のＩＰアドレス情報が入る。

このように、インターネット２を介したデータ通信には図４に示したデータ制御情報及び通信データ本体ＫＥＹＶＡＬがそのままＴＣＰデータ／ペイロードＴＣＰＤＵ内（図２（ｃ）参照）に入るため、世界中のあらゆる場所にデータｄ’、ｅ’を送れる柔軟性があるばかりでなく、エッジエージェント４４、４７でのデータ通信時の処理負荷が大幅に軽減される効果がある。

ＩＰアドレスを用いて所定データをデータ通信する方法は、従来から知られていたが、送信されたデータの例えば表示や保存などの処理にはＷｅｂブラウザや特定ソフトの事前バンドルを前提とするなど受信側の負荷が非常に大きかった。それに比べて、本実施形態では図４～図８に示すように、送信データ本体ＶＡＬＰＲＴと同時に非常に簡単なデータ構造を持つデータ制御情報ＫＥＹＰＲＴを同時に送ことができる。その結果として、Ｗｅｂブラウザや特定ソフトの事前バンドルなどの負荷を受信側に掛けず、受信側で非常に容易に送信データの処理が行える効果がある。

上記の一連の処理の結果として図９Ａに示すように、分散サーバ群４のメモリ部６内には解析後のアナライズドデータｄ’ｅ’のみが保存される。図９Ｂのステップ６に従って分散サーバ群４内で“高度なデータ解析”を行う場合、オリジナルデータｄ、ｅも使用すると膨大な解析時間が掛かってしまう。それに比べて、解析後に得られたアナライズドデータｄ’ｅ’のみを使用して高度なデータ解析を行えば、非常に短時間に効果的なデータ解析ができる効果が生まれる。

この分散サーバ群４内で行う高度なデータ解析の具体例として、エンドユーザ個々の行動解析や要求推定をしても良い。それにより、例えば“エンドユーザの気分がイライラしている場合には照明の明かりを落とすと共に静かな音楽を流して気持ちを落ち着かせる”などの高度なサービスが出来る。

図９Ｂのステップ７に従った分散サーバ群４からエッジエージェント４４、４７に対して行う“高度なサービスの指示”の具体的内容としては、“部屋の照明の明るさを落とす”とか“自動的に静かな（ユーザの好みの）音楽を流す”などが挙げられる。

この場合の指示方法は、受信側ＩＰアドレス情報ＤＩＰＡＤＲＳの配置領域内（図３（ｂ）参照）にはエッジエージェント４４、４７のＩＰアドレスが入り、送信側ＩＰアドレス情報ＳＩＰＡＤＲＳの配置領域内には分散サーバ群４（の窓口サーバ）のＩＰアドレス情報が入るというものである。

更に、制御情報ＣＮＴＩＮＦ内の制御タイプＣＴＴＹＰＥ（図６（ａ））内には、“ＰＵＴ”が設定され、通信データ本体ＶＡＬＰＲＴの格納領域内には上記の“照明を落とした後の部屋内の明るさ”や“流す音楽の内容”が格納される。更に、この音楽を出力する時間範囲を、図８（ｃ）内の“Time-Zone”で設定しても良い。このように簡単なデータ制御情報ＫＥＹＰＲＴのみで、エンドユーザに対して非常に高度なサービスを提供できる効果がある。

図９Ｂのステップ８に記載したエンドユーザに対する“高度サービスの提供”の具体的内容は、分散サーバ群４から送信された具体的な指示内容に沿ってエッジエージェント
４４、４７がネットワーク接続されている駆動デバイス（図９Ａでは図示して無い）を駆動する。

図９Ａと図９Ｂを用いて説明した高度なデータ解析やエンドユーザに提供する高度なサービスは、上記に限定せず、如何なるデータ解析や如何なるサービス提供も本実施形態に含まれる。

３．２節 個人情報保護対応のデータ解析とデータ公開／課金条件
本実施形態で取り扱う通信データには個人情報も含まれ、個々人の要求に応じた個人情報を保護する必要がある。その個々人の非常にナイーブな要請に答えるため本実施形態では、分散サーバ群４のメモリ部またはメモリデバイス２０、２２、２６内の管理情報６６の一部として、図１０に示すユーザの管理情報を所有しても良い。

データの公開（活用）範囲を示すデータ公開クラス設定の一例として２．３節内で、特定のネットワークドメインまたは所定グループメンバーを単位としてデータの公開レベルを設定する方法を説明した。この方法を利用して上記ネットワークドメインに参加する全メンバーまたは所定グループに含まれる構成メンバーに関する情報を入手し、図１０の管理情報を作成しても良い。

図１０の縦方向列は、個々のユーザＵ１、Ｕ２、Ｕ３‥の個別情報を示すが、これに限らず、家族単位や組織単位、または特定グループ単位で記述しても良い。図１０内には個別ユーザ情報ＵＳＥＩＮＦとユーザ識別情報ＵＳＲＥＣＧ、ユーザ帰属情報ＵＳＢＬ、データ公開条件情報ＰＵＢＣＮＤに関係した情報が記載されている。

この個別ユーザ情報ＵＳＥＩＮＦ内にユーザ識別情報ＵＳＲ＿ＩＤとパスワードＰＡＳＳＷＤを纏めておくと、分散サーバ群４が管理するドメイン内にユーザ識別情報ＵＳＲ＿ＩＤとパスワードＰＡＳＳＷＤを用いて参加するユーザ個々の識別が容易となる。更に、分散サーバ群４やエッジエージェント４４、４７、４８がＥメールアドレスＥＭＡＤＲＳの情報を用いて、個々のユーザに対して所定データ公開の可否を問合せができる。

一般のユーザは個人情報の開示を嫌うが、個人情報公開時の公開料金が支払われるならば個人情報を公開しても良いというユーザは一定の割合で存在する。そのため、情報利用者は、データ公開条件情報ＰＵＢＣＮＤに合致（或いは同意）した場合、もしくはＥメールアドレスＥＭＡＤＲＳを用いて個別情報の公開許可を得た場合には、その公開料を料金振込用銀行口座番号ＢＮＫＡＣＴに自動的に振り込むことが可能となる。

例えば、センサデバイス３２（図１または図１１）でセンサデータを収集した場合、そのセンサデータ内に個人情報が含まれるか否かを分散サーバ群４またはエッジエージェント４４、４７、４８が自動識別する必要がある。この自動識別の際に利用するユーザ識別情報ＵＳＲＥＣＧとして、分散サーバ群４またはエッジエージェント４４、４７、４８は、顔認識用リンク先情報ＦＲＥＣＬＫや指紋照合用リンク先情報ＦＧＰＲＬＫを利用しても良い。これらの情報は、対応するデータベースへのリンク先情報がＵＲＩの形で記述されている。

本実施形態では、データ公開クラスＤＰＵＢＣＬとして、特定グループメンバーに限定したデータ公開またはデータ利用や所定のネットワークドメイン内に限定したデータ公開またはデータ利用を可能としている。

従って、図１０に示すユーザ帰属情報ＵＳＢＬとして、ユーザ個々が参加するグループの識別情報ＧＲＰ＿ＩＤやユーザ使用機器が登録されているネットワークドメインＮＤＭ＿ＩＤの情報が存在する。この情報が存在することで、ユーザ毎に具体的にどの範囲までデータの公開／利用が可能なのか（或いは利用さるのか）の判別が容易となる。

一方、前述したように公開料金が支払われるなら個人情報を公開しても良いと言うユーザは多い。そのため、データ公開クラスＤＰＵＢＣＬに応じて完全オープン公開ＰＵＢＯＰＮとドメイン内限定公開ＰＵＢＤＭＮ、特定メンバー限定公開ＰＵＢＭＭＢが用意されることができる。そして、各公開条件別に、公開時にユーザが請求する金額が一覧表として纏めておくことができる。

データ加工をする前の生のセンサデータを公開または第三者による活用を許可した場合の請求金額（公開禁止情報も含む）ＰＵＢＯＲＧがユーザ毎に記載可能となっている。この記載欄に例えば、“No”や“Forbiddance”、“Forbidden Condition”などと記載された場合は、対応するデータの公開または第３者の活用を禁止する状態を示す。

例えば、本人が含まれる高精細な（解像度の高い）映像や画像では本人の識別が容易なためデータ公開を嫌うが、データ加工条件として例えば低画質な（解像度の低い）映像や画像あるいは顔位置にモザイク処理がなされた映像や画像では本人識別が困難なためデータ公開を許可する場合がある。

従って、データ加工条件Ａ（例えば画質を落とす）での公開時の請求金額（公開禁止情報も含む）ＰＵＢＣＤＡやデータ加工条件Ｂ（例えば顔位置にモザイクを施す）での公開時の請求金額（公開禁止情報も含む）ＰＵＢＣＤＢを個別に設定できる。

図１０に示すように、完全オープン公開ＰＵＢＯＰＮと、メイン内限定公開ＰＵＢＤＭＮ、特定メンバー限定公開ＰＵＢＭＭＢの欄に、それぞれ「生データ公開時の請求金額（公開禁止も含む）ＰＵＢＯＲＧ」、「データ加工条件Ａでの公開時の請求金額（公開禁止情報も含む）ＰＵＢＣＤＡ」、「データ加工条件Ｂ（例えば顔位置にモザイクを施す）での公開時の請求金額（公開禁止情報も含む）ＰＵＢＣＤＢ」、を設定することができる。

図１０の記載例において、ユーザＵ２は全面的にデータ公開を禁止する。それに対してユーザＵ３は、完全オープン公開と、ドメイン内限定公開ＰＵＢＤＭＮにおいて、生データ公開は禁止する。そして、ドメイン内限定公開ＰＵＢＤＭＮにおいて、データ加工条件ＡとＢであれば公開料金として１ドル請求し、特定メンバー限定公開ＰＵＢＭＭＢに関しては、生データ公開ＰＵＢＯＲＧでは１ドル請求し、データ加工条件ＡとＢでの公開ＰＵＢＣＤＡ，ＰＵＢＣＤＢでは無料公開（公開料金０ドル）としている。また、ユーザＵ１はそれぞれの条件毎に公開料金を細かく規定している。

次に、センサデータの活用方法を説明する。センサデータの活用方法として必ずしもユーザ個々の識別まで必要とせず、特定対象人数のみ把握できれば良い場合が有る。その一例を図１１に示す。例えば、電子掲示板（signage）７０上に表示する広告内容を時間経過毎に変え、その広告を見る通行人あるいは広告音声を聞く人の通行人の人数に応じて広告料金を徴収する例の説明をする。

図１１の例では通路７２を通過する通行人７５～７９の中で、２人の通行人７５、７６のみが立ち止まって電子掲示板７０を眺めている。このような場合では人数のみ把握できれば、通行人個々の識別情報は必要では無い。

図１１のユースケースにおける経過時間１００に沿った変化例を図１２に示す。図１２では電子表示板７０に表示される内容が広告内容ａ＿１０４ａから広告内容ｂ＿１０４ｂに変化する場合を説明する。広告内容ａ＿１０４ａが表示され出すと、電子表示板７０を見ている人の人数ＮＷが時刻ｔ１で３人か５人に変化し、その後時刻ｔ３で４人になる。そして広告内容ｂ＿１０４ｂに変化すると、時刻ｔ５では２人に減る。

電子表示板７０は画像（映像）表示と同時に音声出力をする。従って、電子表示板７０を見ない通行人でも立ち止まって出力音声を聞いている人もいるので、電子表示板を見て無いが立ち止まっている人の人数ＮＳも同時にモニターする。

図１２では経過時間１００に沿ってｔ１～ｔ６の時刻に人数が変化する。センサデバイス３２内のデバイスエージェントあるいはセンサデータを収集したエッジエージェント４４（図１参照）がセンサデータをデータ解析し、時刻ｔ１～ｔ６毎に通信データ本体内パックＶＡＬＰＣＫ－１、－２の自動分割を行う。

図１１のセンサデバイス３２が撮像した画像（映像）の一例を図１３Ａに示す。通行人７７がセンサデバイス３２の方向に顔を向けているため、通行人７７の正面から見た顔が撮像されている。その生のセンサデータに対して、センサデバイス３２内のデバイスエージェントあるいはセンサデータを収集したエッジエージェント４４がデータ解析を行い、顔面位置を自動検出する。そして、データ加工結果として図１３Ｂに示すように、その顔面位置にモザイクを掛けても良い。

上記一連の処理内容を図１４に示す。ステップ３１では、センサデバイス３２に拠るセンサデータの収集が行われる。次に、ステップ３８では図１２のｔ１～ｔ６の時刻タイミングに合わせ、映像／画像解析に基付くパック切れ目位置の自動検出が行われ、その結果がステップ５１での管理パケットＭＮＰＫＴの自動生成に利用される。

センサデバイス３２によるセンサデータ収集と同時にステップ３６では、センサデバイス３２内のデバイスエージェントあるいはエッジエージェント４４内部で低画質の（解像度が低い）映像／画像の自動生成が行われ、生のセンサデータと共にデータバッファリングが行われる（ステップ３７）。

また、並行してセンサデバイス３２内のデバイスエージェントあるいはエッジエージェント４４内部では顔識別に拠るユーザの自動判別処理が行われ（ステップ３３）、その判別されたユーザ毎に図１０に示した管理情報内容の照合が行われてユーザ毎の公開範囲と請求金額の抽出が行われる（ステップ３５）。

次に、ステップ３５で得られた結果に基づき、ステップ４１～４３では生のセンサデータと加工条件毎の加工されたデータに対する公開条件が合致するか否かの判定を行う。ここで、図１０の記載内容として全ての公開範囲でのデータ公開／活用を禁止するユーザＵ２がセンサデータ内に含まれていると、ステップ３３の判別結果として判明した場合には、生のセンサデータと全ての加工条件の加工データがデータ破棄となる（ステップ４６～４８）。

また、ステップ４１～４３の判定で公開条件に合致したデータは、データ内容毎にそれに関係するユーザを全て自動判別し、図１０に記載された請求金額の合計値に基づいて管理パケットの自動生成を行う（ステップ５１）。例えば、データ内の特定の通信データ本体内パックＶＡＬＰＣＫが５人のユーザに関係した場合は、図１０内のデータ公開条件毎（データ公開条件情報ＰＵＢＣＮＤの横方向行毎）に５人の公開時請求金額を合計し、その合計値を図５（ｅ）の公開料金ＦＥＥＭＭＢ、ＦＥＥＤＭＮ、ＦＥＥＯＰＮの記載欄内に記載する。

本実施形態では、このようにデータ内の通信データ本体内パックＶＡＬＰＣＫ毎に関係するユーザを同定し、図１０の表を利用してデータ公開／第三者による活用可否やデータ公開／活用時の課金金額を細かく設定できる。従って、きめ細かいデータ公開／活用サービスを提供できる効果がある。なお、図１４に示した実施例では顔認識を用いてデータに関与するユーザの同定を行った。しかし、本実施形態ではそれに限らず、データに関与するユーザの同定／認知方法として他の任意方法を使用しても良い。

図１４のステップ５１で自動生成した管理パケットＭＮＰＫＴをステップ５２では図５（ｂ）に示したフォーマットに従って生データまたは加工後のデータ内に挿入（多重化）する。

また、ステップ５３のデータ保存の段階では、生データ及びデータ加工条件毎に図１０のデータ公開条件情報ＰＵＢＣＮＤ内記載内容に応じたデータ公開クラスＤＰＵＢＣＬを判定し、図１６内のメモリ領域管理情報ＲＤＭＧ内に記載されたデータ公開クラスＤＰＵＢＣＬに該当するメモリ領域内にデータ保存する。

本実施形態では、上述するように指定されたデータ公開クラスに応じたメモリ領域内に予めデータが保存されるので、第三者が公開／活用可能なデータ検索を容易に行える効果が有る。

３．３節 ドメイン内メモリ領域拡張方法
近年注目されているＩｏＴ技術では、多種多様なセンサからのセンサデータが逐次収集され、適宜メモリ内へ保存される。また、そのセンサデータを有効活用する場合、過去に収集されたデータまで遡って利用される場合が多い。するとその結果として、メモリ内に保存されるデータ量が時間経過に従って膨大化する。従って、各種データを保存するメモリの容量や特性の影響を受けずに、過去に蓄積されたデータの有効活用を可能とするデータ管理方法またはそれを用いた装置、デバイスの提供が求められる。

ここでは、上記の課題を解決するための構成の一例を挙げて説明する。例えば、図１のように、予めメモリデバイス２２のメモリ領域内にオリジナルなセンサデータａ、ｂ、ｃとそれをデータ解析して得られたアナライズドデータａ’、ｂ’、ｃ’が記録されていた場合を考える。次に、図１９Ａでは、センサデバイス３２、３４で収集されたセンサデータｄ、ｆをエッジエージェント４４内でデータ解析してアナライズドデータｄ’、ｆ’も生成される。そして、センサデータｄ、ｆとアナライズドデータｄ’、ｆ’をメモリデバイス２２のメモリ領域内に逐次保存すると、メモリ領域内の未記録残量が枯渇する恐れがある。

過去のデータａ、ｂ、ａ’、ｂ’を破棄して良い場合には、将来得られるデータを既にデータａ、ｂ、ａ’、ｂ’が記録された領域上に上書き処理できる。しかし上書き処理をすると、過去のデータａ、ｂ、ａ’、ｂ’まで遡った有効活用が不可能となる。

本実施形態では、例えば有効未記録残量などメモリ領域内の状態を管理して得られる情報をメンテナンス情報と呼ぶ。このメンテナンス情報の結果、例えば上書き処理の必要性が近付くなどのリスクを事前に予測して対応処理を行っても良い。図１９Ａの例での事前予測されたリスクとしては、“有効未記録残量が枯渇し、センサデバイス３２、３４からのセンサデータを収集し続けると上書き処理が必要となる（過去に収集されたセンサデータや解析後に得られたデータの一部が消される）”状況が該当する。

唯一のメモリデバイス２２内のメモリ領域のみを考える限り、上記の問題解決は難しい。その対策として、インターネット２の回線も視野に含めたネットワーク回線で接続された他のメモリ領域との間で互いに連携させると、自由度の高いストレージ環境を提供できる。具体的には特定メモリ領域内での既記録データを、互いに異なる複数のメモリ領域間での移動またはコピーを可能とする。その結果として、既記録データの不必要な消去処理を防止でき、将来に亘って既記録データの有効活用を可能にする効果がある。つまり、ネットワーク回線で接続された複数のメモリ領域間でのデータ記録処理またはデータ再生処理を連携させると、例えば記録容量超過を招き易い色々なデータ保存要求に対する自由度の高いストレージ環境を提供できる。

メモリ領域間で連携させる対象として、本実施形態では多様な連携方法を許容する。例えば、メモリデバイス２０、２２、２６間でメモリ領域間の連携をさせても良い。図示して無いが１台のエッヂ装置１４に複数のメモリデバイス２２が接続し、メモリデバイス２２間で相互通信可能な状況があっても良い。例えば、ＵＳＢ接続のようにエッジ装置１４を頂点として複数のメモリデバイス２２がツリー状に接続される場合でも、複数のメモリデバイス２２間での単独通信をしても良い。特に、ＳＣＳＩ（Small Computer System Interface）のようにデバイス間が直列接続されている場合には、エッジ装置１４を介さない複数のメモリデバイス２２間通信が一層容易となる。

図１８を用いて後述するように、メモリデバイス２２、２６に常駐するデバイスエージェント４２、４６は、メモリ領域内の物理特性まで細かく管理している。そのため、デバイスエージェント４２、４６間でメモリ領域の連携を図って、メモリ領域を非常に効果的に使え、物理アドレス上での１ビット当たりの記録コストを意味するビット単価（ビットコスト）を低額化できる効果がある。

一方、図１８が示すように、エッジ装置１４、１６内に常駐するエッジエージェント４４、４７はメモリ領域内の無欠陥な論理アドレス（理想空間）を扱い、メモリ領域内の詳細な物理特性まで管理しない。従って、エッジエージェント４４、４７間でメモリ領域の連携処理を行うと、メンテナンスコストを削減できる効果がある。

また、上記に限らず、分散サーバ群４とエッジエージェント４４、４７間でメモリ領域の連携をさせても良い。一般に、分散サーバ群４内のメモリ部６の記録容量は非常に大きいばかりでなく、分散サーバ群４の処理機能の自由度が高い。そのため、分散サーバ群４とエッジエージェント４４、４７間でメモリ領域の連携をさせると、多種多様なデータ保存要求に対して柔軟に対応できる。従って、非常に自由度の高いストレージ環境を提供できる効果がある。

本実施形態では、互いに連携可能なメモリ領域の情報を事前に所有し、分散サーバ群４に限らず、各エッジエージェント４４、４７、４８やスモールエージェント４０が連携可能な全メモリ領域を自由に使用できる。それにより、単独のメモリデバイス２２のみで処理する場合と比べて、全メモリ領域の記録容量（または未記録残量）が飛躍的に拡大し、データ保存の自由度が向上する効果がある。

例えば、図１９Ａのようにメモリデバイス２２において、未記録残量が少なくなる場合がある。この際、エッジエージェント４４がメモリデバイス２２のみの情報しか持たない場合の不具合と、エッジエージェント４４が互いに連携可能なメモリ領域の情報を事前に所有する場合の利点を説明する。エッジエージェント４４が他のメモリ領域情報を知らない場合は、分散サーバ群４に対して警報通知情報を通信する必要がある。その後、分散サーバ群４が必要なデータ移動先を探して、エッジエージェント４４に回答する必要が生じる。この分散サーバ群４がデータ移動先を探して回答するためのコストが発生し、システム全体の運営・管理コスト（メンテナンスコストも含む）が増加する問題が発生する。しかし、エッジエージェント４４がメモリ領域の連携先を事前に知っていれば、データ移動先を探すコストが省け、システム全体としてのコスト低減効果が生まれる。

図１または図１９Ａの実施形態におけるネットワーク接続関係を図１５に示す。図１５の実施形態では各デバイス２０、２２、２６、３２、３４、３６と各エッジ装置１４、１６、１８の上位接続先が一意的に決まっている。

図１または図１９Ａに示す分散サーバ群４内のメモリ部６に格納されているエッジ／デバイステーブル６８の具体的な内容を図１６に示す。この図１６内に、図１または図１９Ａに示した本実施形態内の全構成体の情報が纏まっている。図１５に示した各デバイス２０、２２、２６、３２、３４、３６と各エッジ装置１４、１６、１８の上位接続先は、図１６の設置／配置情報ＥＤＤＲＩＦ内の上位接続先ＵＰＣＮＴに記載されている。

図１６では、種別ＥＤＤＲとしてデバイスとエッジ装置毎に纏め、それぞれの識別情報（ＩＤ情報）を個別識別ＥＤＲ＿ＩＤの欄内に格納する。特にエッジ／デバイステーブル６８内に記録される各デバイス２０、２２、２６、３２、３４、３６と各エッジ装置１４、１６、１８のＩＰアドレスＩＰＡＤＲＳの情報を利用して、任意のデバイス２０、２２、２６、３２、３４、３６とエッジ装置１４、１６、１８から任意のデバイス２０、２２、２６、３２、３４、３６とエッジ装置１４、１６、１８へ直接データ通信できる効果が生まれる。既に２．１節で説明したように、このＩＰアドレスＩＰＡＤＲＳの情報を図３（ｂ）内の受信側ＩＰアドレス情報ＤＩＰＡＤＲＳを格納する領域内に記述すれば、インターネット２経由のデータ通信が可能となる。

図１６のメモリ領域管理情報ＲＤＭＧ内（図１９Ａではエッジ／デバイステーブル６８内）に、互いに連携可能なメモリ領域に関する情報が纏まっている。ここで図１または図１９Ａのメモリデバイス２０、２２、２６内のメモリ領域は、１個以上のパーティションやフォルダ／ディレクトリあるいは対応するドライブから構成され、その識別情報ＦＬＤ＿ＩＤが設定されている。また、それぞれは前述したデータ公開クラスＤＰＵＢＣＬに対応し、誰にでも公開されるフルオープンや特定ドメイン内にのみデータ公開可能なメモリ領域、所定のグループメンバーのみに公開されるメモリ領域、あるいは特定個人にのみ公開されるメモリ領域に分かれても良い。このようにデータ公開クラスＤＰＵＢＣＬ毎にメモリ領域が分かれると、データ管理やデータの公開管理が容易となる効果がある。

また、各分割されたデータ領域毎の管理者を示す管理者識別情報ＭＡＮ＿ＩＤを持って、公開時の課金処理が容易になる効果がある。具体的には、特定のデータ領域に保存されたデータを閲覧または活用する毎にその公開／使用料が管理者識別情報ＭＡＮ＿ＩＤに対応した管理者に支払われ、その管理者から図１０に示した個別ユーザに公開／使用料が分配されても良い。また、この時のメモリ領域毎の公開／使用料は、メモリ領域使用料ＦＥＥＭＥＭの記載欄内に再生／使用したバイト数に応じた月額料金がドル建てで記載されているため、世界中での課金額計算が容易となる。

なお、本実施形態における課金対象のサービス形態として、「既保存のデータ（センサデータに関する生データやそれを加工／解析して得られたアナライズドデータ、駆動デバイスの制御履歴に関するデータなど）を第三者に公開あるいは第三者が活用する時のサービスに対応した課金」と「メモリ領域を第三者に貸与する（第三者がメモリ領域内に所定データを保存させてもらう）サービスに対応する課金」の２種類を許容する。

図５（ｅ）の公開料金ＦＥＥＭＭＢ、ＦＥＥＤＭＮ、ＦＥＥＯＰＮや図８（ｄ）のPublication_Fee、図１０の公開時請求金額ＰＵＢＯＲＧ、ＰＵＢＣＤＡ、ＰＵＢＣＤＢなどは前記〔Ａ〕のサービス形態に対して支払う課金額を示す。一方で、図１６内のメモリ領域使用料ＦＥＥＭＥＭは、前記〔Ｂ〕のサービス形態に対して支払う課金額を示す箇所が異なる。

例えば、図１６の記載例では、Suzukiが管理するメモリデバイス２２内のフルオープンなデータ公開クラスＤＰＵＢＣＬに対応したメモリ領域Ｂ内を借用して、Andoが作成（関与）したデータを保存させてもらった場合を仮定する。この場合には、保存したデータサイズ（バイト単位）に応じたメモリ領域賃貸料を月額指定ドルずつAndoがSuzukiに支払う。

更に、このデータをKatoが再生または加工／編集する場合には、公開料としてKatoがAndoに対価を支払う。一方で、このデータがＡ、Ｂ、Ｃの３者が関与する場合（例えばこの映像データ内にＡ、Ｂ、Ｃの３者が映っていた場合）には、AndoがＡ、Ｂ、Ｃの３者に対して図１０のデータ公開条件情報ＰＵＢＣＮＤ内に記載された請求金額に応じてKatoから得られた対価を分配する。

ところで、Ａ、Ｂ、Ｃの３者に分配する請求金額の合計値が図５（ｅ）内の公開料金ＦＥＥＭＭＢ、ＦＥＥＤＭＮ、ＦＥＥＯＰＮ内に予め記載されている。従って、Katoはこの公開料金額が適正額か否かを判断して、該当するデータの再生または加工／編集するか否かを判断しても良い。

このエッジ／デバイステーブル６８では、特定ドメインに限らず、任意の範囲のデバイス２０、２２、２６、３２、３４、３６とエッジ装置１４、１６、１８に対して管理しても（エッジ／デバイステーブル６８内への登録を行っても）良い。

上記エッジ／デバイステーブル６８を作成する方法について、図１７を用いて説明する。インターネット２などのネットワーク回線に接続されるデバイス２０、２２、２６、３２、３４、３６とエッジ装置１４、１６、１８は時々刻々と変化する（接続と離脱を頻繁に行う）ため、適宜詳細にエッジ／デバイステーブル６８を更新するのが難しい。

それに対し、必要となった時に必要とする分散サーバ群４またはエージェント４０、４４、４７、４８がネットワーク回線を経由して“問い掛け”を行い、その“回答”結果をエッジ／デバイステーブル６８に纏め、関係者（他の分散サーバ群４またはエージェント４０、４４、４７、４８）に配布する形式を取る。それによりエッジ／デバイステーブル６８作成の柔軟性が向上し、ネットワークシステム全体のスケーラビリティーが向上する効果が生まれる。

例えばＪＭＳ（Java（登録商標） Message Service）ではPublish/Subscribeメッセージングモデルを提案している。これは同一のメッセージ（データ）を１対ｎに対して行うメッセージングモデルで、メッセージの送信者をパブリッシャ（Publisher）と呼び、メッセージの受信者をサブスクライバ（Subscriber）と呼ぶ。従って、分散サーバ群４を含めた任意のエージェント４０、４４、４７、４８がパブリッシャになれると共にサブスクライバにもなれる。またPublish/Subscribeメッセージングモデルにおける問合せサービス（環境）をノーティフィケーションサービスと呼ぶ。

上記エッジ／デバイステーブル６８を作成したい場合には、エッジ／デバイステーブル６８を作成したいパブリッシャはステップ６１において、ノーティフィケーションサービスを用いて拡張可能なメモリ領域とそれぞれのデータ公開クラスＤＰＵＢＣＬ（メモリ領域使用料ＦＥＥＭＥＭを含む）の問合せを行う。

ステップ６２で問合せを受けたサブスクライバは、拡張可能なメモリ領域とそれぞれのデータ公開クラスＤＰＵＢＣＬ（メモリ領域使用料ＦＥＥＭＥＭを含む）の回答を行う。その回答を基にパブリッシャがエッジ／デバイステーブル６８の作成または追記／更新（ステップ６３）を行い、その結果を関係者に配布する（ステップ６４）。なおここで配布されたエッジ／デバイステーブル６８は、メモリデバイス２２、２６内の管理情報６２、６６の一部として保存される。

ここでは“問い掛け”と“回答”の流れを説明する一例として、Publish/Subscribeメッセージングモデルを利用して説明した。しかし、本実施形態ではそれに限らず、あらゆる種類のメッセージ交換を行っても良い。その具体例として１対ｎ（多）のPublish/Subscribeメッセージングモデル以外に、ＳＮＳ（Social Network Sevice）の任意書き込み掲示版形式のメッセージング方式を採用しても良い。

ところで、上記問合せと回答に関するデータ通信時には、図２の通信データ構造を用い、図４と図６～図８で説明した内容のデータ制御情報ＫＥＹＰＲＴの送信を行う。

３．４節 メンテナンス情報の管理とネットワーク通信
図１または図１９Ａに示したエッジエージェント４４、４７（スモールエージェント４０を含む）とメモリデバイス内のデバイスエージェント４２、４６におけるメモリ領域内のそれぞれが管理内容の違いを図１８に示す。

図１８では、横方向にメモリ領域内管理アドレス（Ｍｇ１）、エージェントが行うメモリ領域内管理内容（Ｍｇ２）、エージェント間通知情報（Ｍｇ３）を分類し、縦方向にエッジ（スモール）エージェント（Ｍｅ１）、デバイスエージェント（Ｍｅ２）を分類している。

半導体メモリ、ＨＤＤ（Hard Disk Drive）、光ディスクの如何に関わらず、多くのストレージデバイス（メモリデバイス）では、物理アドレスと論理アドレスの２種類のアドレスを利用してメモリ領域内を管理する。論理アドレスは内部に欠陥の無い理想空間上で規定されたアドレスを意味する。しかし、実際のストレージデバイス（メモリデバイス）には、内部に欠陥領域や劣化領域が存在する。そこで物理アドレスを使って、このような欠陥／劣化領域場所の管理が可能となっている。

この例では、エッジ（スモール）エージェントは論理アドレス（欠陥の無い理想空間）のみを管理し（Ｍｅｇ１１）し、デバイスエージェントは物理アドレス（欠陥・劣化領域の管理も含む）を主に管理する（Ｍｇｅ１２）。また、前記物理アドレスと論理アドレス間の変換処理はデバイスエージェントが行う。

またデバイスエージェントは、欠陥領域の管理及びその欠陥領域に対応した領域の交替処理管理を行う。また、上書き回数やデータの安定保存期間に関係する劣化領域管理を行う。更に、デバイスエージェントは、記録データの信頼性確保対応する処理として、例えば信頼性が低下したデータのエラー訂正処理と、そのエラー訂正後のデータの別領域への書き替え処理などを行っても良い。従って、デバイスエージェントは、物理アドレス空間上でのデータ記録／再生／消去処理を担う（Ｍｇｅ２２）。

それに比べて、エッジ（スモール）エージェントは論理アドレス空間上でのデータ記録／再生／消去処理（上書き場所／対象データの管理も含む）を主に行う（Ｍｇｅ２１）。また、それに関係して、有効記録容量や有効未記録残量の管理も行う。

エッジ（スモール）エージェントが上記処理を行えるように、デバイスエージェント４２、４６からエッジエージェント４４、４７に対して有効記録容量の低下状況や有効未記録残量の劣化状況、既記録データ信頼性の低下状況（既記録データのエラー率変化）などの通知処理（Ｍｇｅ３０）を行う。

そして、デバイスエージェント４２、４６からの通知情報を基に、エッジエージェント４４、４７はメモリ領域内のタイムリーな状態を示すメンテナンス情報を適宜作成し、管理情報６２の一部としてメモリデバイス２２内に記録される。

図１９Ａのように、メモリデバイス２２内のメモリ領域内の未記録残量低下をデバイスエージェント４２が始めに検知し、デバイスエージェント４２からエッジエージェント４２に対して有効未記録残量通知を行う。すると、エッジエージェント４４はその通知内容を基に、メンテナンス情報の更新／生成を行う（図１９Ｃのステップ１１）。

次に、図１９Ｃのステップ１２としては、他のエッジエージェント４７や分散サーバ群４に対して警告通知必要性の有無を判定する。センサデバイス３２、３４からのセンサデータ収集が継続する場合には、エッジエージェント４２は上記メンテナンス情報内容を参照して既記録データａ、ｂ、ａ’、ｂ’が記録されている場所への上書きリスク可否を判定する。ここで、事前リスクを認知すると、現在収集中のセンサデータ及びデータ解析後のデータが対応するデータ公開クラスＤＰＵＢＣＬと図１６に示したエッジ／デバイステーブル６８内のデータ公開クラスＤＰＵＢＣＬ欄とを比較して、既記録データａ、ｂ、ａ’、ｂ’を移動できる場所を同定する。そして、図１９Ｂの実施例では、既記録データａ、ｂ、ａ’、ｂ’を分散サーバ群４内のメモリ部６とメモリデバイス２６内のメモリ領域内に同時に移動する。

このようにデータの移動先が決まると、そこに対してエッジエージェント４４は「メモリデバイス２２内メモリ領域内の有効未記録残量が枯渇直前」との警告通知情報を通信する（図１９Ｃステップ１３）。そして、その直後に図１９Ｃの既保存データの通信ステップ１４として、前記移動先に対して既記録データａ、ｂ、ａ’、ｂ’の送信を行う。

この場合、図４（ｂ）の通信データ本体ＶＡＬＰＲＴ内に既記録データａ、ｂ、ａ’、ｂ’が格納され、図１６のエッジ／デバイステーブル６８内に記載されたＩＰアドレスＩＰＡＤＲＳの内容を図３（ｂ）受信側ＩＰアドレス情報ＤＩＰＡＤＲＳの格納領域内に記載する。このようにして、インターネット２を介してメモリ領域が拡張される。特に、本実施形態では既記録データａ、ｂ、ａ’、ｂ’送信時に、図２のデータ構造及び図４（ａ）のデータ制御情報及び通信データ本体ＫＥＹＶＡＬの形態を取るため、インターネット２とイントラネット（またはローカルなネットワーク）を問わず簡易的方法で世界中の至る所に対してもネットワーク通信が出来る効果がある。

その後は、図１９Ｃのステップ１５、１６、１７に従って管理情報６２の作成または更新と保存及びエッジ装置１６や分散サーバ群４への通信を行う。

ところで、デバイスエージェント４２がメモリデバイス２２のメモリ領域内の状態を確認し、例えば、所定領域の書き換え回数が特定許容値を超えるなどの関係で使用不可能な領域（図２０Ａの“×印”で示した場所）が判明し、メモリデバイス２２の有効記録容量が所定の保証値を下廻ると共に有効未記録残量の劣化が生じた場合を考える。この場合の処理を図２０Ａ、図２０Ｂを利用して図２０Ｃで説明する。

この場合、デバイスエージェント４２はエッジエージェント４４に対して“有効記録容量が保証値を下廻り”、“有効未記録残量が劣化”した情報を伝える。するとその情報に対応して、エッジエージェント４４は図２０Ｃのステップ２１が示すようにメンテナンス情報の生成または書き替えを行う。

次に、警告通知の必要性判断（図２０Ｃのステップ２２）基準として、メンテナンス情報を利用して、既記録データｃ、ｄ、ｃ’、ｄ’が上書きされて消去されるリスクを判断する。そして、警告通知の必要性が生じた場合には、図１９Ｃと同様な処理が行われる。具体的な対策例として、図２０Ｂに示すように、既記録データｃ、ｄ、ｃ’、ｄ’を分散サーバ群内のメモリ部６とエッジ装置１６内のメモリデバイス２６内の２箇所に移動させる。

３．５節 データベース検索方法
本実施形態では、図１９Ｂや図２０Ｂに示すように、一連のデータａ、ｂ、ｃ、ｄ、ｆ、ｇ、ａ’、ｂ’、ｃ’、ｄ’、ｆ’、ｇ’が異なるメモリ領域内に分散配置される。このように分散配置された一連のデータを纏めて再生したり、活用するための分散データの検索方法を以下に説明する。

本実施形態では、既に３．３節の説明内容と同様に、分散サーバ群４またはエージェント４０、４４、４７、４８がネットワーク回線を経由して“問い掛け”を行い、その“回答”結果を基にして分散配置されたデータの収集や活用を行っても良い。

その具体的例として、３．３節で説明したPublish/Subscribeメッセージングモデルを用いたデータ検索方法例を、図２１を用いて説明する。分散サーバ群４またはエージェント４０、４４、４７、４８の中で分散配置された一連のデータ収集またはデータ活用が必要となったパブリッシャは、ノーティフィケーションサービスを用いて他の分散サーバ群４またはエージェント４０、４４、４７、４８に対して指定データ保存場所の問合せを行う（ステップ７１）。

すると、対応データの保存に関与している分散サーバ群４またはエージェント４０、４４、４７、４８はサブスクライバとして、ノーティフィケーションサービスを用いて上記指定データの保存場所を回答（ステップ７２）する。この場合の通信データは図２（ａ）の構造を利用する。そして、データ制御情報及び通信データ本体ＫＥＹＶＡＬ内の制御情報ＣＮＴＩＮＦ（図４（ｃ））内では、図６（ｂ）内のデータ格納場所ＴＥＮＴＩＤの記述領域内に上記保存場所を記載しても良い。また、それに限らず図４（ｂ）の通信データ本体ＶＡＬＰＲＴ内に所定フォーマットで保存場所を記述しても良い。

パブリッシャは図２１のステップ７３に示すように、回答を受信後にドメイン内に分散配置された指定データに関するデータ再生用テーブルを作成する。そして、そのデータ再生用テーブルを利用してステップ７４では、前回回答してくれたサブスクライバに対するデータ転送要求（図７の“ＰＵＴ”のリクエスト）を行う。

万が一、上記指定データが記録されたメモリデバイス２０、２２、２６がネットワーク回線から外れた場合には、第４章で後述する方法でエラー訂正処理などを行い収集データの信頼性回復処理（ステップ７５）を行っても良い。

インターネット２などのネットワーク回線に接続されるデバイス２０、２２、２６、３２、３４、３６とエッジ装置１４、１６、１８は時々刻々と変化する（接続と離脱を頻繁に行う）ため、上記のデータ検索方法を採用する事でシステム全体のスケーラビリティーが向上する効果がある。

ところで、３．３節で説明したように本実施形態でのデータ検索方法もPublish/Subscribeメッセージングモデルに限らず、本実施形態ではあらゆる種類の１対ｎ（多）のメッセージ交換やＳＮＳ環境のような多対多の掲示版形式を利用したデータ検索方法を使用して良い。

更に、図２１で行った特定のデータ検索方法に限らず、本実施形態ではあらゆる形態のデータベース自体の検索に上述したような方法を利用しても良い。

３．６節 従量課金の制御方法
３．６．１節 保存データ再生時の従量課金制御方法
図２２及び図２３は、例えば分散サーバ群４が、ユーザからの要求に応じてデータを格納したり、格納データをユーザに提供したりする場合、課金処理がどのように実施されかを説明する図である。先に説明したメモリデバイス２２及び又はエッジ装置４４などをデータ発生器２１０とすることができる。データ発生器２１０で生成されたデータは、例えば分散サーバ群４で管理される。分散サーバ群４に含まれる各サーバは、コントローラ（図示せず）と、管理情報６４を含む。例えばこの管理情報６４が、ソースデータ管理領域２３０を含むことができる。また各サーバは、それぞれのコントローラにより制御されており、以下に説明する各種のデータがコントローラの制御に基づいて処理される。

ソースデータ管理領域２３０は、課金制御データ領域２３１を有し、この課金制御データ領域２３１が、ソースデータ発生器２１０からのデータを管理するとともに、該データが利用されたとき、利用者に対する課金処理を実行する。利用者側としては、種々の対象物が可能であり、例えば携帯型エッジ装置１８が考えられる。この利用者の端末を利用者端末２５０として示している。

なお、インターネットを介して送受信されるデータは、共通鍵５２、５４、５６により暗号化されて送受信される。受信側は、共通鍵５２、５４、５６を用いて暗号されたデータを解凍することができる。メモリデバイス２２には、共通鍵５２が用意されており、メモリ部６には共通鍵５４が用意されている。なお、メモリデバイス２２及びメモリ部６は、公開しても構わないデータに関しては暗号化処理を行わない。

利用者端末２５０からの要求に応じて、ソースデータ管理領域２３０がデータを提供する場合は、両者間で予め取り決めた暗号化方式により、ソースデータ管理領域２３０において提供データの暗号化処理が行われる。利用者が要求するデータ及びソースデータ管理領域２３０が用意しているデータとしては、各種のデータがある。エッジエージェント４４から受け取った生のデータのみならず、サーバにおいてデータ解析した結果で得られたデータなども存在する。

データ発生器２１０が出力するソースデータは、各種のデータを含む。図２３に示すように、ソースデータは、例えば物理データ、仕様データ、取得・蓄積データ、履歴データなどを含む。物理データは、例えばメモリの物理的な値を示すものでメモリ容量を示すデータである。仕様データは、メモリの特性を表すデータであり、書き込み速度、読み取り速度などのデータである。そして、仕様データは、メモリの寿命に関するデータも含み、このデータとしては、書き換え回数の最大値、データの保持能力を示すデータ保持期間の値などを含む。

加えて、取得・蓄積データは、カメラからの映像データ、マイクからの音声データ、温度、湿度、圧力、化学反応、振動、加速度、歪度、回転数などを検知するセンサから検知データなどを収集したものである。更に、履歴データは、データの送信・受信などの履歴を示すデータである。取得・蓄積データは、取得日時、取得場所、取得領域、取得時の天気情報（温度・湿度・晴れ・曇り・雨・雪など）、などの付加情報を有してもよい。

データ発生器２１０は、定期的或いは予め設定されている条件が成立したときにサーバへ上記したデータを伝送（或いは通知）する。

予め設定されている条件としては、物理データ、仕様データに基づいて設定されている条件がある。この条件が成立する場合としては、例えば、メモリ容量に対して記憶データ量が所定容量を超えた場合、書き換え回数が所定回数を超えた場合、データ保持期間が設定期間を超えた場合などである。これらの情報は、エージェントの基本メンテナンス作業に関わることになる。

また、条件が成立する場合としては、「映像データや音声データが、特定の振る舞いをした場合（例えば、映像データの輝度が異様に変換した、映像データが取得できない、映像データによる色表示が異常（全フレーム赤、青、黄などの単色になったなど））」、「音声データによる音声レベルが零或いはピークを長時間超えている場合」、「温度、湿度、圧力、化学反応、振動、加速度或いは歪度、回転数などが、異常（設定した閾値を超えている）な場合」がある。これらの情報は、データ業務（data business）に関わる。

データ発生器２１０は、コントローラの制御に基づいて、通知条件設定器２１５からの条件データを受け付けることができる。条件データは、データ発生器２１０からサーバへデータを送信する場合の条件や、送信するデータの制限（許可、禁止など）を設定するためのデータである。例えば、個人的に使用するデータで、秘密を要するデータは、送信禁止フラグを該データに付けることができる。また、公開するデータに対しては、該データを送信するときの暗号化処理を省略することができる。

データ発生器２１０から上述したようなデータを受け取ったサーバは、コントローラの制御に基づいて、該データ（受信データ）を管理情報６４の一部として管理する。ここでは、課金システムについて説明する。

管理情報６４は、ソースデータ管理領域２３０を備え、ここに課金制御データ領域２３１を備えている。課金制御データ領域２３１は、データ発生器２１０からデータを受信した場合、課金対象データと非課金対象データとの分離を行い、それぞれのデータを別々に保存或いは識別する。このデータ分離のために課金制御データ領域２３１は、分離ブロック２３１ａを備える。

非課金対象データは、主としてデータ発生器２１０側のエージェントのメンテナンス保障にかかわるデータである。例えば、記憶データ容量が所定容量を超えた場合と、書き換え回数が所定回数を超えた場合と、データ保持期間が設定期間を超えた場合は、ソースデータ管理領域２３０は、エージェント及び又はその管理者に対して警告を行う。

課金対象データは、データ業務に利用される。課金対象データは、データ発生器２１０から直接受け取った一次データと、ソースデータ管理領域２３０内で独自に処理した二次データを含む。二次データとは、一次データを加工する、一次データと他のデータと組み合わせる、一次データ或いは加工データを解析するなどして、得られたデータである。これらの一次データ、二次データに対しては、付加価値（或いはランク）が付けられる。このランク付けのために、課金制御データ領域２３１は、ランク付けブロック２３１ｂを備える。

ソースデータ管理領域２３０は、コントローラの制御に基づいて、利用者端末２５０からの要求に応じて利用者端末２５０へデータを提供することができる。提供するデータとしては、有料あるいは無料のデータがある。ソースデータ管理領域２３０は、利用者端末２５０へ有料データを提供した場合、課金データを管理する。この課金データは、利用者端末２５０毎に応答処理ブロック２３１ｃにおいて、管理される。

ソースデータ管理領域２３０は、コントローラの制御に基づいて、管理条件設定器２３５からの条件データを受け付けることができる。条件データは、課金データに対するランクの変更データ、例えば特定の利用者端末からの要求に対してデータ提供を許可する或いはデータ提供を拒否するなどを制御するためのデータ提供制御データなどがある。データ提供制御データは、データを提供する管理者と利用端末２５０の管理者との間の契約に基づいて決定される。決定内容は、条件データとして、管理条件設定器２３５からソースデータ管理領域２３０に入力される。

ソースデータ管理領域２３０は、サーバグループの管理、ユーザ装置（例えば利用端末２５）を登録するための関連装置管理データ２３２を備える。コントローラの制御に基づいて、関連装置管理データ２３２は、新たな利用端末がサーバをアクセスしたときには、新たな利用端末の固有情報を取得して、そして前記新たな利用端末を管理下に置くことができる。同様な手法で、関連装置管理データ２３２は、新たなサーバ、新たなデータ発生器なども管理下に置くことができる。

上記の説明は、利用者端末２５０が、データを要求し、この要求に応じてサーバがデータの提供することを説明した。そして、データが利用者端末２５０に提供されたときに、課金処理が実施されることを説明した。しかし、課金処理は、上記の行為時（動作時）のみに限定されるものではない。

一方、データを全てのユーザに対してオープン開示する場合には、課金処理を行わず無料対応とする。

３．６．２節 データ保存場所変更時の従量課金制御方法
例えば、ソースデータ発生器２１０が、データを一時的にサーバ（或いは分散サーバ群４）に預ける場合がある。上記したソースデータ発生器２１０からサーバに送信されるデータとしては、一時的に預けられるデータも存在する。例えば、ソースデータ発生器２１０において、使用しているメモリの書き換え回数が所定回数を超えた場合、データ保持期間が設定期間を超える場合がある。このような場合、ソースデータ発生器２１０は、一時的にメモリに記憶しているデータを、一時的にサーバに退避する。そしてソースデータ発生器２１０は、サーバに退避させているデータの返信を要求し、交換した新メモリ、或いは一端データ消去したリフレッシュメモリに対して、再書き込みを実施する。このような場合、サーバでは、データ処理目的がメンテナンス作業であることから、データ処理料金は、無料とする。

ソースデータ発生器２１０では、使用中のメモリはその記憶データで満杯される場合がある。このような場合、ソースデータ発生器２１０は、メモリの記憶容量がデータで満杯になる前に事前に、メモリ状態情報をサーバに対して通知する。一般的には、メモリの記憶容量がデータで満杯になると、ソースデータ発生器２１０は、該メモリに対して上書きを実施する。この場合、メモリに記憶されていた古いデータは、上書きのために消滅する。

しかし、本実施形態の場合は、ソースデータ発生器２１０は、メモリ状態情報をサーバに通知する。ソースデータ発生器２１０は、メモリがデータで満杯になる前に事前通知としてメモリ状態情報をサーバに通知する。

すると、サーバは、ソースデータ発生器２１０に対して、その対応を問い合わせてくる。即ち、古いデータの上に上書きを行うか、又はメモリに記憶されているデータをサーバに預けるのか、もし預けたとしたらいつまで保証して欲しいのか、などの問い合わせをする。この問い合わせに対して、ソースデータ発生器２１０は、通知条件設定器２１５に設定されている条件データに基づいて、データをサーバに預けるのか否かを決定する。また条件データに基づいて、預けるデータの範囲（古いデータの範囲、或いはデータの種類）を設定することもできる。

ソースデータ発生器２１０は、データをサーバに預ける場合、メインサーバを指定することができる。メインとなるサーバは、預かるデータに応じて、課金処理を実施することができる。サーバは、例えば、古いデータ（早い時期に記憶されたデータ）の場合は、預かり金が高くなり、新しいデータ（最近記憶されたデータ）ほど、料金が安くなる方法を採用している。また、ソースデータ発生器２１０は、預けるデータに、重要度を示す重みづけを行ってもよい。この場合、重み付が大きいデータほど、メインサーバは、預かりデータを高くする。

第４章 分散配置されたデータと管理情報の信頼性確保方法
図２４は、上記した実施形態において、データの信頼性を確保するための一例であり、基本的な考え方を示している。データ信頼性確保システムでは、データ分散エリアが、ワールドワイドの広さであり、データ預かり先の媒体は、種々のサーバ及び又はエージェントにおける記憶媒体を利用することができる。

本実施形態において、スモールエージェント４０、デバイスエージェント４２、４６、エッジエージェント４４、４８などは、データを蓄積する機能、データを送信する機能を備える。また、これらのエージェント４０、４２、４４、４６、４８等は、蓄積したデータを長期間或いは短期間、一時的に外部のサーバあるいはエージェントに対して預けたい場合がある。

短期間としては、何らかの都合でエージェントのメモリの修理点検などを要することがある。更には、長期間の例としては、古いデータや履歴データを保存したい場合がある。そのような場合、本データ信頼性確保システムでは、各エージェントが、データの塊、或いはデータファイルをＥＣＣブロック（Error Correction Control Block )群に変換して、それぞれのＥＣＣブロックの各セクタを複数のサーバ（６ａ、６ｂ、６ｃ・・・・）に分散送信して預けることができる（ブロック分散（Block-Distribution）配置と称することができる）。
１つのＥＣＣブロックは、例えば１６セクタからなり、１つの１セクタは、例えば１３行のデータからなる。１つのＥＣＣブロックは、エラー訂正に寄与するouter 符号コードＰＯ, inner-code parityＰＩを含み、outer code parityＰＯは、１行ずつ分離されて、前記セクタ（１３行）の中の１つの行に埋め込まれている。

上記１６セクタのそれぞれの送信先は、エージェントにおいて、管理情報（ＵＲＬデータ）として保持される。一方、受け側のサーバ或いはエージェントは、自己の所有するメモリの一部にデータ預かり領域を確保している。受け側のサーバ或いはエージェントは、データを預かる場合は、送り先のエージェントのＵＲＬデータに関連つけて預かりデータをメモリに保存することができる。

データを預けた側のエージェントが、分散配置したデータを取集したい場合は、管理情報から各サーバのＵＲＬデータを読出し、預けたデータを該サーバに要求する。これにより、エージェントでは、各サーバからセクタが収集されて、ＥＣＣブロックが構築される。その後は、ＥＣＣブロックに対するエラー訂正処理が実施され、該エージェントは、オリジナルのデータファイル或いはデータの塊を復元することができる。

上記のような分散配置を行うことで、たとえ一部のサーバから預けデータの回収が不可能になっても、ＥＣＣブロックのエラー訂正能力の範囲で、オリジナルデータを復元す
ることが可能となる。また、上記の説明ではサーバ群４として示しているが、これに限定されるものではない。データ預かり機器としては、一般ユーザのパーソナルコンピュータ、企業のサーバの一部、などメモリ領域レンタル管理者との契約取引により、全世界に拡張することが可能である。つまり、本システム上では、データを預かり業務をメモリ領域管理者が展開することが可能となる。データの預かり期間として、短期、中期、長期に応じて預かり料金の設定を行うことが可能である。

なお、エージェントにおいて、オリジナルデータをＥＣＣブロックの状態に符号化する場合、その事前処理としてオリジナルデータに対してスクランブルを施してもよい。これにより、ＥＣＣブロックの一部の復元ができなかったとしても、オリジナルデータでは破損位置が細かく分散される。

第５章 エッジ装置の他の実施形態
第４章までは例として図１に示す実施形態を利用して説明した。しかし、本実施形態におけるエッジ装置としては下記に説明するように、多種多様な実施形態を採っても良い。

例えば、図２５に示すように工場全体または製造工程を１台のエッジ装置と見なしても良い。また、図２５に示すように、複数のエッジ装置３１４、３１８間で階層的なネットワーク接続を行っても良い。

図２５では、工場（エッジ装置）３１４内のエッジエージェント３４４が工程内に配置された各種センサデバイス３３２～３３８からのセンサデータを収集し、工場内の状態検知を行う。そのデータ収集時に必要な検知の設定条件をユーザ３１０に対して画像表示器３７６で表示しても良い。また、ユーザ３１０とのインターフェースとして、音声対話器３７４を利用しても良い。

ここで収集されたセンサデータの一部は、分散サーバ群３０４へデータ通信され、メモリ部３０６に保存された後、機械学習器３７０において利用されても良い。分散サーバ群３０４、メモリ部３０６、機械学習器３７０は、センサデータ収集、蓄積、分析処理を行う。

上記のように、工場に限らず図２６に示すように、本実施形態を作業現場ゾーン４００や製造プロセスゾーン４１０、市場ゾーン４２０に適用しても良い。図２６に示す実施形態では、複数のエッジ装置間が階層的にネットワーク接続されている。即ち、エッジ装置に対応する製造装置や検査装置、搬送装置毎の内部にエッジエージェント３４７（例えば製造装置のエッジ装置３４７－１）、エッジエージェント３４８（例えば検査装置のエッジ装置３４８－１）、エッジエージェント３４９（例えば搬送装置のエッジ装置３４９－１）が配置される。そして、エッジエージェント３４７、３４８、３４９及びセンサデバイス３３２からネットワーク回線３０２を経由して各種データが必要な箇所とデータ通信される。

この現場ゾーン４００全体を管理・制御するエッジ装置３１４内のエッジエージェント３４４はデータの送信制御や異常検知、デバイス制御などの自律的制御を行う。

一方では、このエッジ装置３１４に接続されて分散サーバ３０４側でビッグデータ解析１５０や機械学習３７０、リアルタイム監視１６８が行われる。またこの分散サーバ群３０４が所有するメモリ部３０６内には「部材」３０６－１に関するデータや「工場管理」３０６－２に関するデータ、「品質管理」３０６－３に関するデータが保存されている。そして、この「部材」に関するデータを用いて調達工程４１２の管理が行われ、「工場管理」に関するデータを用いて製造工程４１４の管理が行われ、「品質管理」に関する
データを用いて検査工４１６の管理が行われる。

上記に限らず、市場ゾーン４２０では出荷現場４３０、運用現場４３２、保守現場４３４、リユース現場４３６、廃棄現場４３８毎にエッジ装置とエッジエージェントが配置され、第４章までに説明したデータ通信やデータ保存／公開／活用に利用される。

第３章でのデータ解析例として主に、図１１～図１４に示す映像解析や画像解析を中心に説明した。しかし、本実施形態ではそれに限らず、任意形態のデータ解析を行っても良い。そのデータ解析例を図２７に示す。

図２７において、センサデバイス３３２－３３８からの各種センサデータ３９０や各種ログデータ３９６は、ネットワーク回線３０２を経由してＪＭＳ（３．３節と３．５節で説明したJava Message Service）でエッジエージェント３４４が収集する。このエッジエージェント３４４が持つ検知機能（ストリーム処理機能）１６０としてログパターン３９８を利用する機能と検知モデル１６６を活用する機能がある。

この検知モデル１６６として、多変量相関１７０、ＷＥＣＯ（Western Electric Company Rule）（３シグマ）１７２、ＭＴ（Mahalanobis Taguchi Method）法１７４、クラスタリング１７６、事象パターン１７８などいずれの方法を利用しても良い。

そして、そのデータ解析結果に基づき、エッジエージェント３４４はＪＭＳを利用して駆動デバイス３８０に対して自動制御１４０を行ったりアラート１２０の発行を行っても良い。また、それ以外に図１０の個別ユーザ情報ＵＳＥＩＮＦ内のＥメールアドレスＥＭＡＤＲＳの情報を利用して、特定ユーザに対してメール１１０に拠る通知や相談を行っても良い。

また、上記データ解析結果の活用方法として上記に限らず、第３章内容を始めとしたあらゆる活用方法に適用される。

エッジ装置として今までは主に据え置き形を中心に説明した。しかし、それに限らず移動体（connected Car, connected Bus, connected Truckなど）に対しても、本実施形態を適用しても良い。

図２８に示すように、ネットワーク接続可能な大形バス全体をエッジ装置５１６と見なすことができる。大形バス内に設置された中央制御演算器３５０（エッジエージェント３４７）が電池パック５３０や、駆動デバイスに属する空冷駆動デバイス３８２、インバータ３８４、モータ３８６の制御を行う。バスには、各種のセンサデバイス３３０が装備されており、各種のセンサデータをエッジエージェント３４７に送信することができる。

また、図２８に示すように電池パック５３０内にクラウドレディ電池バンク５３２が存在し、その中は複数のクラウドレディ電池モジュール５３４から構成されている。またそれぞれのデバイスエージェントとして、クラウドレディ電池バンク５３２内にはバッテリ管理ユニット５４２、クラウドレディ電池モジュール５３４内にはセル監視ユニット５４４が配置されている。

セル監視ユニット５４４は、充電率（State of charge)を監視することができる。また電池パック５３０に充電が行われるときの充電達成状況を監視したり、充電電力の接続、遮断制御も行うことができる。

エッジエージェント３４７は、分散サーバ群３０４から、電池残量状態を計算するた
めに、使用電池に適切な電池状態パラメータ３４７－１をダウンロードすることができる。また、使用中の電池状態（電池残量、電池特性など）を把握した電池状態把握情報３４７－２を分散サーバ群３０４にアップロードすることができる。分散サーバ群３０４は、電池状態把握情報３４７－２に基づいて、バスが使用している電池の監視と診断３４７－２を行い、サービスデータとしてエッジエージェント３４７（バス）に提供することができる。

バスは、更に充電装置（エッジ装置）５１４を搭載している。この充電装置５１４は、充電用電源（デバイス）５２２、送電装置（エッジ装置）５１８、受電装置（エッジ装置）５１９を備える。受電装置５１９が動作するときは、充電制御部３５２を介して、電池パック５３０の各セルにたいする充電が実施される。送電装置５１８は、例えば、他の車両に対して充電を行う場合に動作する。

図２９は、ネットワーク接続が可能な自動車（connected Car）内の各種機能を示している。図２９に示すように、シート制御機能６０１、バックガイドモニター６０２、アンチロックブレーキ機能６０３、スタビリティ制御部６０４、プリクラッシュ機能６０５、カーナビゲータ６０６、パワーステアリング機能６０７、モータージェネレータ６０８、エンジン制御機能６０９、オートクルーズ機能６１０、ライティング制御機能６１２、ミリ波レーダー装置６１３などが自動車に配置されており、それらが共通のエッジエージェント３４７に拠り管理／制御される。

図３０は、エッジエージェント３４７が担う機能について示している。各種デバイス６３２や特殊デバイス６３４、エッジ装置６１８からの出力信号が、車内のネットワーク回線を経由してエッジエージェント３４７内に入力される。また、エッジエージェント３４７内ではエッジ連携機能部６７６が存在し、ここで車内の各種エッジ装置６１８との間の連携動作を実現する。そしてデバイス制御部６７４が、車内の各種デバイス６３２の制御のインターフェースを行い、特殊Ｉ／Ｏ部６７０が特殊デバイス６３４との間のインターフェースを担う。

そして、車内の各種デバイス６３２で収集された各種のセンサデータはデータ処理部６７２内でデータ解析される。それだけで無く、機密性の高いセンサデータや解析後のデータに関しては、セキュリティ制御部６２０がセキュリティ制御を行う。

また、図３０内の管理機能部６４８では、図２９が示した各種機能の管理／制御を行う。更に、このエッジエージェント３４７内部には、クラウド及び通信状態に応じた最適送受信制御部６４２、データ種別や緊急度に応じた送受信制御部６４４が内蔵されている。

また、上記エッジエージェント３４７内では、分散サーバ群３０４内の通信相手（特定クラウド）を選択するクラウド選択部６４６や車内ネットワーク回路におけるデータ通信トラブルを解消するトラフィック制御６７８や所定ルールに基づくデータ選別６２２を行っても良い。

特に、移動体のドライバー５２や乗客の状態を監視する手段として図３１に示すように、車載カメラ（センサデバイス）３３９を使用しても良い。この場合、移動体内に駐在するデバイスエージェント３４７のデータ解析内容として、図３１に示すように脈拍数などのデータ１５０－１を用いてビッグデータ解析１５０（例えば個人特有の血圧のピークを追跡、ピークのスペクトル密度を計測）を行ったり、運転手のあくびなどの撮像画像データ１８０－１を用いて画像解析１８０を行っても良い。そのデータ解析結果に基づいて、ドライバー５５２に対して注意を喚起しても良いし、関連する事業者５５４の運行管理にフィードバックしても良い。

上記のように収集されるデータは、車及び又はその構成部品の品質情報７１１、画像分析により地図情報７１２や、音声分析により環境情報を得ることができる。更には、品質情報７１１を用いて、市場検討情報、品質検討情報７１４を作成したり、アラーム情報７１５、メール情報７１６などを作成することもできる。

なお、上記の各実施形態は、代表的な例を説明したものである。上記で説明した各種データとその取扱い方法、管理方法との組み合わせ、各種データと、記憶装置（メモリ）と、記憶方法と、通信方法と、データ処理方法との選択的な組み合わせも本発明に含まれるものである。例えば、通信方法においては、機器間の通信において、同一コンテンツを１チャンネル或いは１ストリームにて通信するのではなく、同一コンテンツを複数チャンネル或いは複数ストリームで分散して通信してもよい。また、上記したデータを取り扱う領域も、各種の組み合わせが可能であり、個人ベースの機器間、家庭内、工場内、各種地域内、また空間（例えば飛行体も含めた）領域、これらの組み合わせも含むものである。

更にまた、データの圧縮方法に関しても、上記の実施形態に限定されるものではなく、種々の方式（今後の新しい方式も含む）を適用することが可能である。加えて、異なる複数のデータ圧縮方式を、特定の地域やエージェント毎に選択的に採用することにより、データの秘匿性を高めること、システム使用料金の差別化を行うことも可能である。

２・・・インターネット、４・・・分散サーバ群、６・・・メモリ部、８・・・ユーザＩ／Ｆ部、１０・・・ユーザＩＤ＆パスワード、１４、１６・・・エッジ装置、１８・・・携帯形エッジ装置、２０、２４、２６・・・メモリデバイス、３２、３４、３６・・・センサデバイス、４０・・・スモールエージェント、４２、４６・・・デバイスエージェント、４４、４７、４８・・・エッジエージェント、
５２、５４、５６・・・共通鍵、６２、６４、６６・・・管理情報、６８・・・エッジ／デバイス テーブル、７０・・・電子表示版（electric signage）、７２・・・通路、７４・・・撮像の有効視野範囲、７５～７９・・・通行人、１００・・・経過時間、１０４ａ、１０４ｂ・・・広告内容、１１０・・・メール、１２０・・・アラート、１３０・・・ＪＭＳ（Java (登録商標) Message Service）、１４０・・・自動制御、
１５０・・・ビッグデータ分析、１６０・・・検知機能（ストリーム処理）、１６６・・・検知モデル、１６８・・・リアルタイム監視、１７０・・・多変量相関、１７２・・・ＷＥＣＯ（Western Electric Company Rule）、１７４・・・ＭＴ（Mahalanobis Taguchi Method）法、１７６・・・クラスタリング、１７８・・・事象パターン、１８０・・・画像解析、３０２・・・ネットワーク回線、３０４・・・分散サーバ群、３０６・・・メモリ部、
３１０・・・ユーザ、３３０・・・各種センサデバイス、３３２～３３８・・・センサデバイス、３３９・・・車載カメラ（センサデバイス）、３１４、３１６、３１８・・・エッジ装置、３４４、３４７、３４８、３４９・・・エッジエージェント、３５０・・・中央制御演算器、３５２・・・充電制御部、３７０・・・機械学習、３７４・・・音声対話、３７６・・・画像表示／検知設定、３８０・・・駆動（actuator）デバイス、３８２・・・空冷駆動デバイス、
３８４・・・インバータ（駆動デバイス）、３８６・・・モータ（駆動デバイス）、３８８・・・電池パックデバイス、３９０・・・センサデータ、３９６・・・ログデータ、３９８・・・ログパターン、４００・・・現場ゾーン（Industrial Zone）、４１０・・・製造プロセスゾーン、４１２・・・調達工程、４１４・・・製造工程、４１６・・・検査工程、４２０・・・市場ゾーン（Social Zone）、４３０・・・出荷現場、４３２・・・運用現場、４３４・・・保守現場、
４３６・・・リユース現場、４３８・・・廃棄現場、５１２・・・受電装置（エッジ装置
）、５１４・・・充電装置（エッジ装置）、５１６・・・エッジ装置（connected Bus）、５１８・・・送電装置（エッジ装置）、５２２・・・充電用電源（デバイス）、５３０・・・電池パック、５３２、５３４・・・クラウドレディ電池バンク（デバイス）、５４２・・・バッテリ管理ユニット（デバイスエージェント）、５４４・・・セル監視ユニット（デバイスエージェント）、
５５２・・・ドライバー、５５４・・・事業者、６０１・・・シート制御、６０２・・・バックガイドモニター、６０３・・・アンチロックブレーキ、６０４・・・スタビリティ制御、６０５・・・プリクラッシュ、６０６・・・カーナビ、６０７・・・パワーステアリング、６０８・・・モータージェネレータ、６０９・・・エンジン制御、６１０・・・オートクルーズ、６１２・・・ライディング制御、６１３・・・ミリ波レーダー、６１８・・・エッジ装置、
６２０・・・セキュリティ、６２２・・・ルールに基付くデータ選別、６３２・・・デバイス、６３４・・・特殊デバイス、６４２・・・クラウド及び通信状態に応じた最適送受信制御部、６４４・・・データ種別、緊急度に応じた送受信制御部、６４６・・・クラウド選択、６４８・・・管理機能、６７０・・・特殊Ｉ／Ｏ、６７２・・・データ処理、６７４・・・デバイス制御、６７６・・・エッジ連携、６７８・・・トラフィック制御、ＡＴＲＩＢＴ・・・属性情報、ＢＮＫＡＣＴ・・・料金振込用銀行口座番号、
ＣＩ＿ＳＺ・・・制御情報サイズ（４バイト）、ＣＮＴＩＮＦ・・・制御情報（２Ｍバイト以下）、ＣＲＣ・・・誤チェック、ＣＴＴＹＰＥ・・・制御タイプ、ＤＡＴ＿ＳＺ・・・通信データ本体サイズ（４バイト）、ＤＡＴＡ・・・データ本体（１８８バイト）、ＤＡＴＡＩＤ・・・データ識別情報、ＤＩＰＡＤＲＳ・・・受信側ＩＰアドレス（１６バイト）（Destination Internet Protocol Address）、ＤＮ・・・有効視野範囲内の人数増減、ＤＭＮ＿ＩＤ・・・データ管理者識別情報、
ＤＰＵＢＣＬ・・・データ公開クラス、ＤＳＲＣＴＧ・・・データ検索タグ情報、ＤＴ＿ＩＤ・・・データ識別情報、ＤＴＰＵＢ・・・データ公開／課金情報、ＤＴＴＹＰＥ・・・データ種別、ＤＹＭＤ・・・データ作成年月日、ＥＤＤＲＩＦ・・・設置／配置情報、ＥＤＤＲ・・・種別、ＥＤＲ＿ＩＤ・・・個別識別、ＥＭＡＤＲＳ・・・Ｅメールアドレス、ＦＥＥＤＭＮ・・・ネットワークドメイン内公開料金、ＦＥＥＭＥＭ・・・記録領域使用量（ドル／バイト・月）、
ＦＥＥＭＭＢ・・・グループメンバー内公開料金、ＦＥＥＯＰＮ・・・完全オープン時の公開料金、ＦＧＰＲＬＫ・・・指紋照合用リンク先情報、ＦＬＤ＿ＩＤ・・・パーティション／フォルダ／ディレクトリ／ドライブ識別、ＦＲＥＣＬＫ・・・顔認識用リンク先情報、ＧＲＰ＿ＩＤ・・・参加グループ識別情報、ＨＰＬＭＴ 通過可能ノード残数情報（Hop Limit）（１バイト）、ＩＰＡＤＲＳ・・・ＩＰアドレス、ＩＰＣＬＳ・・・交信クラス情報（１バイト）、
ＩＰＬＢＬ・・・通信種別ラベル情報（２．５バイト）、ＩＰＰＫＴ・・・ＩＰパケット関連情報（８バイト）、ＩＰｖ６ＤＵ・・・ＩＰｖ６データ／ペイロード、ＩＰｖ６ＨＤ・・・ＩＰｖ６ヘッダ、ＩＰＶＲＳ バージョン情報（４ビット）、ＬＩＰｖ６ＤＵ・・・ＩＰｖ６データ／ペイロード長さ情報（２バイト）（Length of Internet Protocol Version 6 Data / Payload）、ＫＥＹＰＲＴ・・・データ制御情報、ＫＥＹＶＡＬ・・・データ制御情報及び通信データ本体、
ＭＡＣＨＤ・・・ＭＡＣ層ヘッダ、ＭＡＮ＿ＩＤ・・・管理者識別情報、ＭＮＰＫＴ－１、－２・・・管理パケット、ＭＮＰＫ＿ＩＤ・・・管理パケット識別情報、ＭＰＤＵ・・・ＭＡＣ層フレーム、ＭＰＫ＿ＳＺ・・・管理パケットサイズ、ＭＳＤＵ・・・ＭＡＣ層データ／ペイロード（Medium Access Layer Data / Payload）、ＮＤＭ＿ＩＤ・・・ユーザ使用機器のネットワークドメイン、ＮＤＳＴＭ・・・非再生期間、ＮＰ・・・それ以外の通行人人数、ＮＰＵＢＴＭ・・・非公開期間、
ＮＳ・・・電子掲示板は見て無いが立ち止まっている人の人数、ＮＴＴＮ・・・非転送期間、ＮＸＨＤ・・・ＩＰｖ６ヘッダの直後に続くヘッダタイプの識別情報（１バイト）（Next Header Information to identify the type of header immediately following theIPv6 header）、ＮＷ・・・電子掲示板を見ている人の人数、ＰＡＲＡＭＴ・・・パラメータ情報、ＰＡＳＳＷＤ・・・パスワード、ＰＨＹＨＤ・・・物理層ヘッダ、ＰＰＤＵ・・・物理層フレーム、
ＰＲＦＩＸ・・・窃盗部（１バイト）、ＰＳＤＵ・・・物理層データ／ペイロード、ＰＵＢＣＤＡ・・・データ加工条件Ａでの公開時請求金額（公開禁止も含む）、ＰＵＢＣＤＢ・・・データ加工条件Ｂでの公開時請求金額（公開禁止も含む）、ＰＵＢＣＮＤ・・・データ公開条件情報、ＰＵＢＤＭＮ・・・ドメイン内限定公開、ＰＵＢＭＭＢ・・・特定メンバー限定公開、ＰＵＢＯＰＮ・・・完全オープン公開、ＰＵＢＯＲＧ・・・生データ公開時の請求金額（公開禁止も含む）、
ＲＤＭＧ・・・記録領域管理情報、ＳＩＰＡＤＲＳ・・・送信側ＩＰアドレス（１６バイト）（Source Internet Protocol Address）、ＳＩＰＨＤ・・・先頭情報、ＳＲＣＩＮＦ・・・検索関連情報、ＴＣＰＤＵ・・・ＴＣＰデータ／ペイロード（Transmission Control Protocol Data / Payload）、ＴＣＰＨＤ・・・ＴＣＰヘッダ（Transmission Control Protocol）、ＴＥＮＴＩＤ・・・データ格納場所、ＴＭＭＮ・・・期間管理情報、ＴＳＴＰ・・・タイムスタンプ（４バイト）、
ＵＳＥＲ・・・個別ユーザまたは家族、ＵＰＣＮＴ・・・上位接続先、ＵＳＢＬ・・・ユーザ帰属情報、ＵＳＥＩＮＦ・・・ユーザ情報、ＵＳＲ＿ＩＤ・・・ユーザ識別情報、ＵＳＲＥＣＧ・・・ユーザ認証情報、ＶＡＬＰＣＫ－１、－２・・・通信データ本体内パック、ＶＡＬＰＲＴ・・・通信データ本体、ＶＥＲＩＮＦ・・・バージョン情報、ＶＰＫ＿ＳＺ・・・通信データ本体内パックサイズ。

Claims (7)

1. サーバと、前記サーバにネットワークを介して接続されるエッジ装置と、前記エッジ装置にネットワークを介して接続される複数のメモリデバイスと、を備えるネットワークシステムのデータ管理方法において、
   前記エッジ装置は、
   第１のメモリデバイスに、センサデバイスからのデータを収集すると共に、前記収集したデータに関して少なくともデータ公開の有無を含む管理情報を設定し、前記収集したデータ及び前記管理情報を前記第１のメモリデバイス内のデータ保存部に保存することができ、
   さらに前記データを前記データ保存部に保存する場合、前記データ保存部でデータ損失が生じるリスクを、前記データ保存部の有効未記録残量が枯渇する前に認知し、
   前記データ損失が生じるリスクを認知した場合は、前記サーバと第２のメモリデバイスに、前記データ保存部の前記データ損失が生じるリスクのあるデータを前記管理情報と共に前記ネットワークを介して送信し、
   前記サーバと前記第２のメモリデバイスは、それぞれ互いに同じ内容のデータ検索場所を含む前記管理情報を保存して前記サーバ又は前記第２のメモリデバイス内のいずれか一方の管理情報が紛失しても他方の管理情報からの前記データ検索場所の復元を可能としており、
   また前記エッジ装置、前記サーバ及び前記第２のメモリデバイスは、
   前記管理情報を、前記複数のメモリデバイス別にテーブルで管理し、かつ前記サーバと前記第２のメモリデバイスに関わる前記管理情報の内容としては、前記複数のメモリデバイス内に非公開データと公開データがあることの識別を公開の範囲の大小を示すクラス別で識別管理している、ことを特徴とするネットワークシステムのデータ管理方法。
2. 前記管理情報は、前記公開データを特定のメンバー向けに公開しているのか、一般向けに公開しているのかの識別情報を有するテーブルを備える、請求項１記載のネットワークシステムのデータ管理方法。
3. 前記管理情報は、前記非公開データの料金に関する情報を含む、請求項１又は２記載のネットワークシステムのデータ管理方法。
4. 前記エッジ装置は、前記サーバへ送信するデータの制限を行うための入力を受け付ける請求項１又は２又は３記載のネットワークシステムのデータ管理方法。
5. サーバと、前記サーバにネットワークを介して接続される第１のメモリデバイスと、前記第１のメモリデバイス内に設けられたエージェント及び前記エージェントにより制御されるデータ保存部と備えるネットワークシステムのデータ管理システムであり、
   第１のメモリデバイスは、前記エージェントによる制御のもとで、センサデバイスから収集したデータと、当該データに関して少なくとも公開の有無を含む管理情報を前記データ保存部に保存し、
   さらに前記エージェントは、前記データを前記データ保存部に保存する場合、前記データ保存部でデータ損失が生じるリスクを、前記データ保存部の有効未記録残量が枯渇する前に認知し、
   前記データ損失が生じるリスクを認知した場合は、前記サーバと第２のメモリデバイスに、前記データ保存部の前記データ損失が生じるリスクのあるデータを前記管理情報と共に前記ネットワークを介して送信し、
   前記サーバと前記第２のメモリデバイスは、それぞれ互いに同じ内容のデータ検索場所を含む前記管理情報を保存して前記サーバ又は前記第２のメモリデバイス内のいずれか一方の管理情報が紛失しても他方の管理情報からの前記データ検索場所の復元を可能としており、
   また前記エージェント、前記サーバ及び前記第２のメモリデバイスは、
   前記管理情報を、複数のメモリデバイス別にテーブルで管理し、かつ前記サーバと前記第２のメモリデバイスに関わる前記管理情報の内容としては、前記複数のメモリデバイス内に非公開データと公開データがあることの識別を公開の範囲の大小を示すクラス別で識別管理している、ことを特徴とするネットワークシステムのデータ管理システム。
6. 前記管理情報は、前記公開データを特定のメンバー向けに公開しているのか、一般向けに公開しているのかの識別情報を有する前記テーブルを備える、請求項５記載のネットワークシステムのデータ管理システム。
7. 前記エージェントは、据え置き形、携帯形、移動体形のいずれかである、請求項５又は６記載のネットワークシステムのデータ管理システム。

Images