JP6997992B2 - 情報管理装置、情報管理方法およびプログラム - Google Patents

Description

本発明は、情報管理装置、情報管理方法およびプログラムに関する。

インターネット上では、情報の識別子と情報の保存場所が同一であるＵＲＬ（Uniform Resource Locator）が一般的である。一方、情報の識別子と情報の保存場所を異なる体系で管理する情報指向ネットワークアーキテクチャが提案されている（非特許文献１）。
その１つ、ＣＣＮ（Content Centric Networking）は、コンテンツ名を通信の情報識別子として用い、物理的なネットワークアドレスを用いず、場所構造を持たない純粋なネームベースの情報指向ネットワークアーキテクチャである。

PublisherとSubscriber（データを生成する端末をPublisher、データを要求する端末をSubscriberと呼ぶ）の双方の利便性を考慮すると、共有にあたっては、連続生成されるライブデータ（ライフ期間の短いデータ）（後述）によるトラヒック集中を避けるため、データそのものについては、分散管理型を採用する。
また、分散管理されたデータを検索するためには、データの様々な属性を示すメタデータが使用される。メタデータの管理に関しては、データの登録・削除管理とデータ検索について、データのモビリティを考慮した効率的な共有方式が望まれる。

Subscriber は、所望コンテンツが「どこ」にあるのかを意識する必要がなく、「なに」を求めているのかのみを意識してデータ要求を行えばよい。しかし、場所構造を持たないために、例えば、所望コンテンツを遠方ノードのみが保持している場合、宛先地点を指定して一発でルーティングをするということができず、所望コンテンツを保持していそうなノードを、コンテンツ名のみでしらみつぶしに探索しながら、徐々にルーティングを行うため非常にコストが大きい。

非特許文献１では、データ（情報）を二種類に分類して、一方のデータはグローバルデータとして管理し、他方のデータはローカルネットワークのデータとして管理することで、グローバルデータの検索等にかかる時間を削減している。

伊藤智稀，他３名，「IoTデータの短寿命・ローカリティを考慮したメタデータ管理のための負荷分散制御」，信学技報, vol. 117, no. 460, IN2017-142, pp. 315-320, 2018年3月

しかしながら、非特許文献１に記載の技術を用いても映像機器のようなデバイスが多数存在する場合、それらの機器が生成する画像の検索の登録および書き込み・削除が莫大な量になり、管理の負荷が多大になる。また、一度も検索されることがない、すなわち、一度も使われることのない情報を登録するために費やす装置全体としての処理負荷が大きいというさらなる課題があった。

このような背景を鑑みて本発明がなされたのであり、本発明は、新たに生成された情報に対して、グローバルデータの検索における登録の回数を減らして装置全体としての処理負荷を低減することができる情報管理装置、情報管理方法およびプログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳが配置され、前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置であって、連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分ける第１分類手段と、前記第１分類手段により分けられた前記情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける第２分類手段と、前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩを割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理手段と、前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理手段と、前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理手段と、を備え、前記第１分類手段は、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更することを特徴とする情報管理装置とした。

また、請求項３に記載の発明は、ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳが配置され、前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置の情報管理方法であって、前記情報管理装置のサーバが、連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分けるとともに、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更する第１分類ステップと、前記第１分類ステップにより分けられた前記情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける第２分類ステップと、前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩを割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理ステップと、前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理ステップと、前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理ステップと、を実行することを特徴とする情報管理方法とした。

また、請求項４に記載の発明は、ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳが配置され、前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置としてのコンピュータを、連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分けるとともに、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更する第１分類手段、前記第１分類手段により分けられた前記情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける第２分類手段、前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩを割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理手段、前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理手段、前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理手段、として機能させるためのプログラムである。

このようにすることで、情報Ａに分けたライブデータについて、ＵＲＩを割り当てず、かつ、ＮＣＳ，ＧＮＲＳを用いた検索を行わない。すなわち、特定ローカルデータ管理手段は、情報Ａについて検索のための登録をしない。この登録をしないことで、登録のためのオーバヘッドのコストをなくすことができる。その結果、新たに生成された情報に対して、ＮＣＳ，ＧＮＲＳにおける登録の回数を減らして装置全体としての処理負荷を低減することができる。
このように、検索頻度や最近検索時刻といった検索度合いに応じて情報Ａを情報Ｂにカテゴリ変更する。これにより、何度も検索される情報に対しては、情報Ａを情報Ｂにカテゴリ変更してＵＲＩ登録を可能とし、全世界からの検索に対応できないことを回避することができる。

また、請求項２に記載の発明は、前記第１分類手段が、情報のローカル性の指標として前記ライブデータの生成地点までの距離が所定距離以下の場合、前記情報Ａに分類することを特徴とする請求項１に記載の情報管理装置とした。

このようにすることで、情報Ａに対して、検索する範囲をローカルに限定することにより、Publisherの絞り込みを行うことができる。

本発明によると、新たに生成された情報に対して、グローバルデータの検索における登録の回数を減らして装置全体としての処理負荷を低減する情報管理装置、情報管理方法およびプログラムを提供することができる。

本発明の実施形態に係る情報管理装置の情報管理方法を説明する図である。 上記実施形態に係る情報管理装置の情報管理方法の動作を示すフローチャートである。 比較例の情報管理装置の情報管理方法を説明する図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における情報管理装置等について説明する。
（比較例）
情報指向型ネットワークは、ＵＲＩ（Uniform Resource Identifier）が情報の識別子、ＮＡ（network address）が情報の保存場所である。ＵＲＩは、全世界でユニークである。例えば、１６０バイトの空間のランダム値を割り当てる方法が提案されている。
情報保管場所（Publisherと呼ぶ）を入手したい対象（Subscriberと呼ぶ）は、PublisherのＵＲＩを検索サイトなど何らかの方法で入手する。そして、Subscriberは、このＵＲＩを検索し、PublisherのＮＡを求め、このＮＡに対して通信を行う。
情報指向型ネットワークでは、情報にＵＲＩを割り当てるために、ＮＣＳ（Name Certification Service）という登録サービスを用いる。ＵＲＩからＮＡを検索するためにＧＮＲＳ（Global Name Resolution Service）という検索サービスを用いる。
ＧＮＲＳにおける検索のために、（1）ＵＲＩとＮＡの組を検索テーブルに書き込む、（2）検索後にＵＲＩとＮＡの組を検索テーブルから削除する、（3）ＵＲＩをテーブル検索してＮＡを出力する、という３つの処理が必要になる。

図３は、比較例の情報管理装置の情報管理方法を説明する図である。
図３に示すように、情報管理装置１０は、ローカルネットワーク１上に設置され、ＩｏＴ（Internet of Things）の情報の検索や識別子付与のための情報管理を行う。ローカルネットワーク１には、ＮＣＳ２０、ＧＮＲＳ３０、およびローカルデータベース（ＤＢ）４０が配置される。
情報管理装置１０は、例えば、エッジコンピューティングにより、端末の近くに分散配置されるサーバなどである。エッジコンピューティングにより、携帯電話事業者のコアネットワーク内にサーバを設置すると、遅延を少なくできる。
なお、情報管理装置１０、ＮＣＳ２０、ＧＮＲＳ３０、およびローカルデータベース（ＤＣ）４０のローカルネットワーク１への配置は一例であり、限定されない。

図３の比較例の情報管理装置１０が対象とするライブデータは、監視カメラのライブ映像、家電製品のステータス情報、自動車の位置情報などであり、登録者端末２（ＩｏＴ機器）により連続生成される、ライフ期間の短いデータである。
また、静的データは、YouTube（登録商標）動画などのライフ期間が長いデータである。なお、静的データという用語は、ライブデータと対比する意味で導入したものである。

比較例では、ライブデータの利用において高いローカル性が予想されることに鑑み、一部のデータをローカルに取り扱うことで、グローバルデータの検索における登録の回数を減らして装置全体としての処理負荷を低減する。

比較例のシステムでは、登録者端末２（ＩｏＴ機器）によりライブデータが常時連続生成される。このため、ＮＣＳ２０，ＧＮＲＳ３０への頻繁な登録トランザクションが発生し、その多くが短期間後には無効になることによるＮＣＳ２０，ＧＮＲＳ３０への頻繁な削除トランザクションが発生する。よって、ＮＣＳ２０，ＧＮＲＳ３０への膨大な登録・削除コストが問題となる。頻繁な登録トランザクションや削除トランザクションが発生する理由は、すべてのネットワークデータにＧＵＩＤを割り当て、ＮＣＳ２０，ＧＮＲＳ３０で登録・削除の管理を行う必要があることによる（図３符号ａ参照）。
図３符号ａに示す矢印は、通信回線を表している。情報管理装置１０のデータ蓄積部１２（後記）と、ＮＣＳ２０，ＧＮＲＳ３０とは、通信回線で結ばれている。データ蓄積部１２は、ＮＣＳ２０，ＧＮＲＳ３０に、通信回線によりアクセスを行う。

<ＮＣＳ２０>
ＮＣＳ２０は、すべてのネットワークデータに情報識別子（ＧＵＩＤ、Global Unique IDentifier）を割り当てる。ＮＣＳ２０は、データの様々な属性を示すメタデータからＧＵＩＤを検索する。
具体的には、ＮＣＳ２０は、グローバル識別子付与検索部２１を有する。グローバル識別子付与検索部２１は、コンテンツ名（Content name 1、Content name n、ライブデータ蓄積部）が入力（アクセス）されると、入力されたコンテンツ名を検索してＧＵＩＤ（ＧＵＩＤ1、ＧＵＩＤn、ＧＵＩＤx）を付与する。

<ＧＮＲＳ３０>
ＧＮＲＳ３０は、ＧＵＩＤからＮＡを検索する。具体的には、ＧＮＲＳ３０は、グローバルネットワークアドレス検索部３１を有する。グローバルネットワークアドレス検索部３１は、ＧＵＩＤ（ＧＵＩＤ1、ＧＵＩＤn、ＧＵＩＤx）が入力（アクセス）されると、入力されたＧＵＩＤをもとに、ネットワークアドレスＮＡ（ＮＡ1、ＮＡn、ＮＡx）を検索する。

<ローカルＤＢ４０>
ローカルＤＢ４０は、ローカルネットワーク１に配置され、ネットワークアドレスを検索するためのＧＵＩＤを蓄積する。具体的には、ローカルＤＢ４０は、ライブデータ検索部４１を有する。ライブデータ検索部４１は、ライブデータコンテンツ名（Content name x）が入力（アクセス）されると、入力されたライブデータコンテンツ名をもとに、ＧＵＩＤ（ＧＵＩＤx）を検索する。

<情報管理装置１０>
情報管理装置１０は、データ領域解析部１１と、静的データ蓄積部１３およびライブデータ蓄積部１４を有するデータ蓄積部１２と、データアクセス頻度解析部１５と、データ廃棄部１６と、を備える。

データ領域解析部１１は、登録者端末２（ＩｏＴ機器）により連続生成されるライブデータのデータ領域を解析する。具体的には、データ領域解析部１１は、Publisher のデータ生成頻度が、生成頻度閾値以上、または、Publisher が生成するデータのライフ期間が、ライフ期間閾値以下で、ライブPublisherが生成するデータをライブデータ（図３符号ｂ参照）として扱い、それ以外の非ライブデータは静的データ（図３符号ｃ参照）とする。これにより、Publisher 単位でライブデータと静的データの比率を制御することができる。ライブデータをローカル管理化することにより、グローバルな中央集中検索サーバにおける、頻繁なデータ生成による大きな登録・削除コストを軽減できる。
上記生成頻度閾値および上記ライフ期間閾値は、登録・削除コストと検索コストのトレードオフを考慮して調整する。

なお、図３符号ｂの白抜き矢印に示すライブデータと、図３符号ｃの白抜き矢印に示す静的データとの矢印の太さを変えているのは、ライブデータと静的データとに振り分けられるデータ量をイメージ的に表している（振り分けられるデータ量は、ライブデータの方が大きい）。

データ蓄積部１２は、静的データ蓄積部１３に静的データを蓄積し、ライブデータ蓄積部１４にライブデータを蓄積する。なお、データ蓄積部１２は、例えばＨＤＤ（hard disk drive），ＳＳＤ（solid state drive）等の記憶手段である。
静的データ蓄積部１３は、データ領域解析部１１で解析された静的データを蓄積するとともに、静的データについてＮＣＳ２０，ＧＮＲＳ３０へ登録・削除を行う（図３符号ａ参照）。すなわち、静的データ蓄積部１３は、ＮＣＳ２０の検索によりＧＵＩＤを取得した後、ＧＮＲＳ３０にアドレス解決を依頼する。

静的データ蓄積部１３は、ライブデータ蓄積部１４からライブデータを受け取る場合がある（図３符号ｄ参照）。静的データ蓄積部１３は、ライフ期間が過ぎた静的データをデータ廃棄部１６に出力する（図３符号ｅ参照）。

ライブデータ蓄積部１４は、データ領域解析部１１で解析されたライブデータを蓄積するとともに、ローカルＤＢ４０へ登録・削除を行う（図３符号ｆ参照）。
ライブデータ蓄積部１４は、ライブデータを検索する場合、ＮＣＳ２０の代わりにローカルＤＢ４０を検索した後、ＧＮＲＳ３０でアドレス解決を行う。ただし、メタライブデータ（例えばサブネット単位に定義したデータ）は、ＧＮＲＳ３０に登録されていない。このため、ライブデータ蓄積部１４は、ＧＮＲＳ３０でのアドレス解決に代えて、メタライブデータのアドレス解決を行う（図３符号ｄ参照）。よってメタライブデータは、グローバル識別子付与検索部２１のライブデータ蓄積部のＧＵＩＤxを含んでいる。
ライブデータ蓄積部１４は、ライフ期間が過ぎたライブデータをデータ廃棄部１６に出力する（図３符号ｇ参照）。

データアクセス頻度解析部１５は、静的データ蓄積部１３の静的データおよびライブデータ蓄積部１４のライブデータをもとに、データアクセス頻度を解析する（図３符号ｈ参照）。
ここで、ライブデータ蓄積部１４が、一部のデータをローカルに取り扱い、ローカルＤＢ４０へ登録・削除を行うことで、登録・削除の回数を減らすことができる一方、データをグローバルに扱わないことで、検索のデータヒット率が低下する。そこで、情報管理装置１０に、データアクセス頻度解析部１５を設置する。データアクセス頻度解析部１５は、静的データ蓄積部１３の静的データとライブデータ蓄積部１４のライブデータのデータアクセス頻度をもとに、ライブデータ蓄積部１４に蓄積したままで使用される可能性のないデータを解析する。ライブデータ蓄積部１４は、データアクセス頻度解析部１５の解析結果に従って、自身が蓄積したままで使用される可能性のないデータを静的データ蓄積部１３に書き込む（図３符号ｄ参照）。
データ廃棄部１６は、ライフ期間が過ぎたデータを廃棄する。

比較例では、ＩｏＴ機器により連続生成されるライブデータのうち、ローカルに検索を管理するデータをライブデータと指定し、グローバルに検索を管理する静的データと区別する。これにより、ＮＣＳ２０，ＧＮＲＳ３０における登録の負荷を減らして登録・削除コストを軽減することができる。

しかし、ＮＣＳ２０，ＧＮＲＳ３０において、ＵＲＩ登録のための負荷をより低減したい要請がある。
特に、映像機器のようなデバイスが多数存在し、それらの機器が生成する画像の検索に当たっては、画像数が非常に多くなるため、それらの登録および書き込み・削除が莫大な量になり、ＮＣＳ２０，ＧＮＲＳ３０の管理の負荷が多大になることが問題となる。さらに、一度も検索されることがない、すなわち、一度も使われることのない情報を登録するために費やす処理負荷の損失が大きい。
そこで、新たに生成された情報に対して、ＮＣＳ２０，ＧＮＲＳ３０における登録の負荷を減らして処理負荷をより一層低減することが要請されている。

（実施形態）
図１は、本発明の実施形態に係る情報管理装置１００の情報管理方法を説明する図である。図３の比較例と同一構成部分には同一符号を付して重複箇所の説明を省略する。
比較例では、メタデータを管理するＮＣＳ２０，ＧＮＲＳ３０またはローカルＤＢ４０に対し、データの登録・削除を行う操作を行っていた。
本発明者らは、一部のデータについてはそもそも使われることがないのではないか、ということに着目した。本実施形態は、データをすべて登録・削除するのではなく、一部のデータについては検索のための登録をしないことを特徴とする。
図１に示すように、情報管理装置１００は、ネットワークデータにＧＵＩＤ（情報識別子）が割り当てられ、データのメタデータからＧＵＩＤを検索するためのＮＣＳ２０、およびＧＵＩＤからネットワークアドレスを検索するためのＧＮＲＳ３０が配置される。情報管理装置１００は、ＧＵＩＤと、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャに適用される。
情報管理装置１００は、ローカルネットワーク１上に設置され、ＩｏＴの情報の検索や識別子付与のための情報管理を行う。ローカルネットワーク１には、ＮＣＳ２０、ＧＮＲＳ３０、およびローカルＤＢ４０が配置される。

情報管理装置１００は、カテゴリ分類部１１０（第１分類手段）と、データ領域解析部１１（第２分類手段）と、静的データ蓄積部１３（静的データ管理手段）、ライブデータ蓄積部１４（ローカルデータ管理手段）およびプライベートデータ蓄積部１２１（特定ローカルデータ管理手段）を有するデータ蓄積部１２０と、データアクセス頻度解析部１５と、データ廃棄部１６と、を備える。

<カテゴリ分類部１１０>
カテゴリ分類部１１０は、データ領域解析部１１の前段に設置され、登録者端末２（ＩｏＴ機器）により連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと、少なくとも１つのカテゴリに含まれる情報Ｂとにカテゴリ分類する。カテゴリ分類部１１０が、分けた結果が情報Ａと情報Ｂである。
カテゴリ分類部１１０は、（１）情報のローカル性が高い場合、情報Ａに分類するように設定しておくか、（２）情報の検索頻度が低い場合、情報Ａに分類するように設定しておく。上記（１）と上記（２）は、いずれか一つを用いてもよいし、両者を併用してもよい。
カテゴリ分類部１１０は、情報のローカル性の指標としてライブデータの生成地点までの距離が所定距離以下の場合、情報Ａに分類する。
カテゴリ分類部１１０は、情報の検索頻度が所定値以下の場合、情報Ａに分類する。

カテゴリ分類では、データがどれくらい検索されるかという人気度と、ローカル性との２つの特性を見る。情報Ａは、人気度が低い（あまり検索されない）、かつ、ローカル性が高い（近くで検索されやすい）情報である。換言すれば、情報Ａは、検索されずらく、もし検索されても近くにある情報である。情報Ａは、メタデータとして登録しなくても影響が小さい。また、近くのデータであれば、このようなデータをほしい人は近くを探せば見つかりやすい。

<カテゴリ分類の具体例>
カテゴリ分類部１１０は、登録者端末２（ＩｏＴ機器）により連続生成されるライブデータを、情報Ａと情報Ｂとに振り分ける。
ライブデータの振り分けは、例えば、下記（１）「データ生成者による振り分け」と、下記（２）「ネットワーク管理者等による振り分け」とがある。

（１）データ生成者による振り分け
データ生成者による振り分けの場合、地域性（ローカル性）は、データ生成者のオーナーに依存する。データ生成者は、図１の例では、例えば登録者端末２の管理者である。登録者端末２の管理者は、情報のローカル性が高いデータを情報Ａとし、それ以外のデータを情報Ｂとして手動でカテゴリ分類部１１０に振り分けを設定する。

・データ生成者単位の振り分け
登録者端末２の設置場所（撮影場所・撮影方向）毎に機器単位で振り分ける。
例えば、登録者端末２が監視カメラである場合、家屋の監視カメラは情報Ａ、公道上の監視カメラは情報Ｂにセットアップ時に手動でカテゴリ分類部１１０に振り分けを設定する。

上記は、機器単位の振り分けであるが、下記データ単位の振り分けも想定できる。
・データ単位の振り分け
ユーザ自身がデータ単位で振り分ける。
例えば、動画Ｘを録画したスマホユーザは、地元の人にだけ見てほしいので情報Ａを手動でカテゴリ分類部１１０に振り分けを設定する。一方、動画Ｙを録画したスマホユーザは、多くの人に自慢したいので情報Ｂを手動でカテゴリ分類部１１０に振り分けを設定する。

以上は、ユーザの振り分けであるが、ネットワーク管理者側による振り分けも想定できる。
（２）ネットワーク管理者による振り分け
ネットワーク管理者による振り分けの場合も、上記データ生成者単位の振り分けと同様に、「機器単位」と「データ単位」に分けられる。
・データ生成者単位の振り分け
例えば、家屋の監視カメラは、地域性指標「９０」、公道上の監視カメラは、地域性指標「３０」を持つとする。地域性指標が高いほど、近くで検索されやすい情報、すなわち情報Ａであるとする。
ネットワーク管理者は、情報Ａと情報Ｂの境目の地域性指標を調整（例えば地域性指標「４５」を境目の地域性指標としそれを超える場合にデータ登録）して振り分ける。

・データ単位の振り分け
例えば、監視カメラの映像Ｘは、平均１００（ｍ）離れた地点から検索されると想定し、また、監視カメラの映像Ｙは、平均１００（ｋｍ）離れた地点から検索されると想定する。
ネットワーク管理者は、情報Ａと情報Ｂの境目の距離を調整（例えば監視カメラの映像が平均１００（ｍ）以上の場合にデータ登録）して振り分け調整する。

なお、（１）データ生成者による振り分けと、（２）ネットワーク管理者等による振り分けとが重複した場合、（２）ネットワーク管理者等による振り分けを優先させる。
上記振り分けの例は、一例である。

さらに、登録者端末２から取得したデータの検索頻度に応じて、ネットワーク管理者が手動でカテゴリ分類部１１０により、情報Ａを情報Ｂにカテゴリ変更することも可能である。この場合、情報の検索頻度（人気度合い）の推定値をもとに、ネットワーク管理者が手動でカテゴリ分類部１１０に振り分けを設定してもよい。

<データ領域解析部１１>
データ領域解析部１１は、登録者端末２（ＩｏＴ機器）により連続生成されるライブデータのうち、カテゴリ分類部１１０でカテゴリ分類された情報Ｂのデータ領域を解析する。データ領域解析部１１は、カテゴリ分類部１１０により分けられた情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける。そして、データ領域解析部１１は、Publisher のデータ生成頻度が、生成頻度閾値以上、または、Publisher が生成するデータのライフ期間が、ライフ期間閾値以下に、ライブPublisherが生成するデータをライブデータ（図１符号ｂ参照）として扱い、それ以外の非ライブデータは静的データ（図１符号ｃ参照）とする。これにより、Publisher 単位でライブデータと静的データの比率を制御することができる。

<データ蓄積部１２０>
データ蓄積部１２０は、静的データ蓄積部１３に情報Ｂの静的データを蓄積し、ライブデータ蓄積部１４に情報Ｂのライブデータを蓄積し、プライベートデータ蓄積部１２１（特定ローカルデータ管理手段）に情報Ａのライブデータを蓄積する。

<静的データ蓄積部１３>
静的データ蓄積部１３は、データ領域解析部１１により分けられた情報Ｂの静的データを蓄積するとともに、情報Ｂの静的データについて、グローバルデータとしてＵＲＩを割り当て、ＮＣＳ２０，ＧＮＲＳ３０へ登録・削除を行う（図１符号ａ参照）。すなわち、静的データ蓄積部１３は、ＮＣＳ２０検索によりＧＵＩＤを取得した後、ＧＮＲＳ３０にアドレス解決を依頼する。なお、静的データ蓄積部１３が、ＮＣＳ２０，ＧＮＲＳ３０における登録を行うことで、登録のためのコストがかかる。

静的データ蓄積部１３は、ライブデータ蓄積部１４からライブデータを受け取る場合がある（図１符号ｄ参照）。静的データ蓄積部１３は、ライフ期間が過ぎた静的データをデータ廃棄部１６に出力する（図３符号ｇ参照）。

<ライブデータ蓄積部１４>
ライブデータ蓄積部１４は、データ領域解析部１１により分けられた情報Ｂのライブデータを蓄積するとともに、情報Ｂのライブデータについて、ＮＣＳ２０検索の代わりにローカルＤＢ４０の検索後に、ＧＮＲＳ３０を用いてネットワークアドレスを検索する。すなわち、ライブデータ蓄積部１４は、ＮＣＳ２０検索に代えてローカルＤＢ４０へ登録・削除を行う（図１符号ｆ参照）。なお、ライブデータ蓄積部１４が、ローカルＤＢ４０へ登録する場合、登録のためのコストがかかる。

ライブデータ蓄積部１４は、ライフ期間が過ぎたライブデータをデータ廃棄部１６に出力する（図１符号ｇ参照）。

<プライベートデータ蓄積部１２１>
プライベートデータ蓄積部１２１は、カテゴリ分類部１１０により分けられた情報Ａを、ライブデータ（プライベートデータ）として蓄積する。
プライベートデータ蓄積部１２１は、情報Ａに分けたライブデータについて、ＵＲＩを割り当てず、かつ、ＮＣＳ２０，ＧＮＲＳ３０を用いた検索を行わない。すなわち、プライベートデータ蓄積部１２１は、情報Ａについて検索のための登録をしない。登録しないことで、登録のためのオーバヘッドのコストをなくすことができる。

なお、プライベートデータ蓄積部１２１が、情報Ａには、ＵＲＩを割り当てず、かつ、ＮＣＳ２０，ＧＮＲＳ３０管理を行わないことは、図１のプライベートデータ蓄積部１２１にデータ廃棄部１６への出力以外の入出力が描かれていないことで示されている。

一般化して述べると、情報Ａに対しては、情報を保持する機器（Publisher）自身が情報の検索に対応する機能を持ち、情報Ａを欲するSubscriberは、適当なPublisherに対して直接検索を行う機能を持つ。
ここで、適当なPublisherに対して直接検索を行う機能において、Subscriberの近傍のPublisherのみを検索するようなPublisherの絞り込みを行う。

<データアクセス頻度解析部１５およびデータ廃棄部１６>
データアクセス頻度解析部１５は、静的データ蓄積部１３の静的データおよびライブデータ蓄積部１４のライブデータをもとに、データアクセス頻度を解析する（図３符号ｈ参照）。
データ廃棄部１６は、ライフ期間が過ぎた、静的データ、ライブデータ、およびプライベートライブデータを廃棄する。特に、データ廃棄部１６は、プライベートデータ蓄積部１２１からのデータをそのまま廃棄する。

以下、上述のように構成された情報管理装置１００の情報管理方法を説明する。
図２は、情報管理装置１００の情報管理方法の動作を示すフローチャートである。
まず、ステップＳ１でカテゴリ分類部１１０は、ＩｏＴ機器により連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分ける。例えば、カテゴリ分類部１１０は、情報のローカル性が高い場合や情報の検索頻度が低い場合、情報Ａに分類する。

ステップＳ２でデータ領域解析部１１は、カテゴリ分類部１１０により分けられた情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける。

ステップＳ３で静的データ蓄積部１３は、情報Ｂに分けた静的データについて、グローバルデータとしてＵＲＩを割り当て、ＮＣＳ２０およびＧＮＲＳ３０を用いて検索する。
ステップＳ４でライブデータ蓄積部１４は、情報Ｂに分けたライブデータについて、ローカルデータとしてローカルＤＢ４０検索後に、ＧＮＲＳ３０を用いてネットワークアドレスを検索する。

ステップＳ５でプライベートデータ蓄積部１２１は、情報Ａに分けたライブデータについて、ＵＲＩを割り当てず、かつ、ＮＣＳ２０およびＧＮＲＳ３０を用いた検索を行わずに廃棄させる。
なお、上記ステップＳ２実行後のステップＳ３またはステップＳ４の実行順序と、ステップＳ３またはステップＳ４とステップＳ５の実行順序は問わない。

ステップＳ６でデータアクセス頻度解析部１５は、静的データ蓄積部１３の静的データおよびライブデータ蓄積部１４のライブデータをもとに、データアクセス頻度を解析する。

ステップＳ７でデータ廃棄部１６は、ライフ期間が過ぎた、静的データ、ライブデータ、およびプライベートライブデータを廃棄して本フローの処理を終了する。

以上説明したように、本実施形態に係る情報管理装置１００は、登録者端末２により連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分けるカテゴリ分類部１１０と、カテゴリ分類部１１０により分けられた情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分けるデータ領域解析部１１と、情報Ａに分けたライブデータについて、ＵＲＩを割り当てず、かつ、ＮＣＳ２０，ＧＮＲＳ３０を用いた検索を行わずに廃棄させるプライベートデータ蓄積部１２１と、を備える。

このようにすることで、情報Ａに分けたライブデータについて、ＵＲＩを割り当てず、かつ、ＮＣＳ２０，ＧＮＲＳ３０を用いた検索を行わない。すなわち、プライベートデータ蓄積部１２１は、情報Ａについて検索のための登録をせず、アドレス管理も行わない。さらに、データ廃棄部１６は、プライベートデータ蓄積部１２１からのデータをそのまま廃棄する。登録しないことで、登録のためのオーバヘッドのコストをなくすことができる。その結果、新たに生成された情報に対して、ＮＣＳ，ＧＮＲＳにおける登録の回数を減らして装置全体としての処理負荷を低減することができる。

以上、本発明の実施形態について説明したが、本発明は前記実施形態に限定されず、本発明の要旨を逸脱しない範囲で適宜変更可能である。

また、上記各実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。

１ ローカルネットワーク
２ 登録者端末（ＩｏＴ機器）
１１ データ領域解析部（第２分類手段）
１３ 静的データ蓄積部（静的データ管理手段）
１４ ライブデータ蓄積部（ローカルデータ管理手段）
１５ データアクセス頻度解析部
１６ データ廃棄部
２０ ＮＣＳ
２１ グローバル識別子付与検索部
３０ ＧＮＲＳ
３１ グローバルネットワークアドレス検索部
４０ ローカルデータベース（ＤＢ）
４１ ライブデータ検索部
１００ 情報管理装置
１１０ カテゴリ分類部（第１分類手段）
１２０ データ蓄積部
１２１ プライベートデータ蓄積部（特定ローカルデータ管理手段）

Claims (4)

1. ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ（Name Certification Service）、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳ（Global Name Resolution Service）が配置され、
   前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置であって、
   連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分ける第１分類手段と、
   前記第１分類手段により分けられた前記情報Ｂを、ライフ期間の短いライブデータと、
   ライフ期間が長い静的データとに分ける第２分類手段と、
   前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩ（Uniform Resource Identifier）を割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理手段と、
   前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理手段と、
   前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理手段と、を備え、
   前記第１分類手段は、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更する
   ことを特徴とする情報管理装置。
2. 前記第１分類手段は、情報のローカル性の指標として前記ライブデータの生成地点まで
   の距離が所定距離以下の場合、前記情報Ａに分類する
   ことを特徴とする請求項１に記載の情報管理装置。
3. ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ（Name Certification Service）、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳ（Global Name Resolution Service）が配置され、
   前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置の情報管理方法であって、
   前記情報管理装置のサーバが、
   連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分けるとともに、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更する第１分類ステップと、
   前記第１分類ステップにより分けられた前記情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける第２分類ステップと、
   前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩ（Uniform Resource Identifier）を割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理ステップと、
   前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理ステップと、
   前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理ステップと、
   を実行することを特徴とする情報管理方法。
4. ネットワークデータに情報識別子が割り当てられ、データのメタデータから前記情報識別子を検索するためのＮＣＳ（Name Certification Service）、および前記情報識別子からネットワークアドレスを検索するためのＧＮＲＳ（Global Name Resolution Service）が配置され、
   前記情報識別子と、情報の保存場所とを別の体系とする情報指向ネットワークアーキテクチャにおける情報管理装置としてのコンピュータを、
   連続生成されるライブデータを、少なくとも１つのカテゴリに含まれる情報Ａと情報Ｂとに分けるとともに、検索頻度に基づいて、前記情報Ａを前記情報Ｂにカテゴリ変更する第１分類手段、
   前記第１分類手段により分けられた前記情報Ｂを、ライフ期間の短いライブデータと、ライフ期間が長い静的データとに分ける第２分類手段、
   前記情報Ｂに分けた前記静的データについて、グローバルデータとしてＵＲＩ（Uniform Resource Identifier）を割り当て、前記ＮＣＳおよび前記ＧＮＲＳを用いて検索する静的データ管理手段、
   前記情報Ｂに分けた前記ライブデータについて、ローカルデータとして、前記ネットワークアドレスを検索するための前記情報識別子を蓄積するローカルデータベース検索後に、前記ＧＮＲＳを用いてネットワークアドレスを検索するローカルデータ管理手段、
   前記情報Ａに分けた前記ライブデータについて、前記ＵＲＩを割り当てず、かつ、前記ＮＣＳおよび前記ＧＮＲＳを用いた検索を行わずに廃棄させる特定ローカルデータ管理手段、
   として機能させるためのプログラム。

Images