JP2020095449A - データ流通管理システム、データ流通管理支援装置およびデータ流通管理方法 - Google Patents

Abstract

【課題】データ流通の柔軟性を向上させる。【解決手段】システム管理部１０２は、システム利用者が入力する各種情報や、システム利用者によって希望される提供データのモデル変換処理およびサンプリング処理を実行するノードパッケージや、ノードパッケージをデプロイする際に必要になるパラメータを管理したり、ノードパッケージをデプロイしたりし、システム実行部１０３は、端末データを受け付け、データ提供先システムごとにデプロイされる個々のノード管理テナント１２３へ入力データを複製して転送したり、転送されたデータを処理してデータ提供先システムに送信したりする。【選択図】図１

Description

本発明は、データ流通の柔軟性を向上させることが可能なデータ流通管理システム、データ流通管理支援装置およびデータ流通管理方法に関する。

近年、企業や自治体が他の組織に向けて所有データを公開するオープンデータや、ＲＥＳＴ ＡＰＩ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を通じて組織間の枠を超えたデータ流通を促すＡＰＩエコノミーの機運が高まっている。

このような異業種・企業間のデータ流通は、事業分野を超えたデータの利活用により、複数のステークホルダが関与した複雑な社会的課題の解決を目ざす新規システムの開発に重要な位置を占めている。また、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）やセンシング技術の向上により、各企業が管理するデータ生成端末デバイスから得られるデータの質および量が大幅に増加している。上述した潮流を受けて、自社管理端末デバイスで生成されるデータの仕様を柔軟に変更させながら流通を図ることが求められる。

このようなデータを利用するシステムでは、仕様変更前のデータに密に依存した固定的なシステム設計が施されている場合が多い。このため、データ仕様を変更すると、稼働中の既存・新規システムへの影響が波及されるため、データの仕様変更のハードルは高い。

こうした課題に関連する技術として、特許文献１に開示されたデータ流通管理システムがある。特許文献１に開示されたデータ流通管理システムでは、データ提供者から提供されるデータの仕様と、利用者が希望するデータの仕様のマッチングを行うマッチング手段と、マッチングが成立したデータの流通契約を管理する手段と、契約によって提供されるデータを利用者側の端末デバイスに配信する手段を備えている。このデータ流通管理システムは、データ提供者と利用者がそれぞれ提示した固定的なデータの仕様をマッチングする手段を提供する。

特開２０１７−８４１３４号公報

しかしながら、特許文献１には、マッチングしたデータの配信開始後にデータ提供者が管理する端末デバイスで生成されるデータ（上記データ流通管理システムに提供するデータ）の仕様が変更された場合に、データ利用者が求めるデータを継続的に流通させる方法の開示はない。

本発明は、上記事情に鑑みなされたものであり、その目的は、データ流通の柔軟性を向上させることが可能なデータ流通管理システム、データ流通管理支援装置およびデータ流通管理方法を提供することにある。

上記目的を達成するため、第１の観点に係るデータ流通管理システムは、端末デバイスから収集される端末データの送信先のデータ仕様を管理する管理部と、前記管理部で管理される前記送信先のデータ仕様に基づいてデプロイされ、前記端末データの仕様変更に関する処理を実行する処理ノードを備える。

本発明によれば、データ流通の柔軟性を向上させることができる。

図１は、第１実施形態に係るデータ流通管理システムの構成を示すブロック図である。 図２は、図１の利用時入力データの一例を示す図である。 図３は、図１の利用者情報管理テーブルの一例を示す図である。 図４は、図１のデータスキーマ管理テーブルの一例を示す図である。 図５は、図１のノード設定管理テーブルの一例を示す図である。 図６は、図１のリクエスト転送先情報管理テーブルの一例を示す図である。 図７は、図１のデータ流通管理システムのテータ提供者向けの動作を示すフローチャートである。 図８は、図１のデータ流通管理システムのテータ利用者向けの動作を示すフローチャートである。 図９は、図１のシステム管理部の登録時の動作を示すフローチャートである。 図１０は、図１のシステム管理部による処理ノードのデプロイ時の動作を示すフローチャートである。 図１１は、図１の利用者向けコンソールの表示画面の一例を示す図である。 図１２は、第２実施形態に係るデータ流通管理システムの構成を示すブロック図である。 図１３は、図１２の業務指標−性能指標マッピングデータの一例を示す図である。 図１４は、図１２の利用者情報管理テーブルの一例を示す図である。 図１５は、図１２の業務指標算出ロジック管理テーブルの一例を示す図である。 図１６は、図１２の業務指標別ノード最適設定管理テーブルの一例を示す図である。 図１７は、図１２のリクエスト転送先情報管理テーブルの一例を示す図である。 図１８は、図１２のデータ流通システム動的管理部の登録時の動作を示すフローチャートである。 図１９は、図１２のデータ流通管理システムの性能指標変更時の動作を示すフローチャートである。 図２０は、図１のデータ流通管理システムのハードウェア構成を示すブロック図である。

実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また、実施形態の中で説明されている諸要素およびその組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、第１実施形態に係るデータ流通管理システムの構成を示すブロック図である。
図１において、データ流通管理システム１００は、システム管理部１０２と、システム実行部１０３を備える。データ流通管理システム１００は、利用者コンソール１０１と、端末データ受付部１０６と、データ提供者システム１０７と、データ利用者システム１０８に接続されている。

データ流通管理システム１００は、端末デバイス１０５から収集されるＩｏＴデータなどを、企業１７１および組織１７２の枠を超えて流通させる場合、端末デバイス１０５が生成するデータ（端末データと言う）のデータ仕様（ＩｏＴデータのデータ構造や、ストリーミング配信などの配信方式など）をデータ提供者およびデータ利用者ごとに柔軟に変更して流通させる。

データ仕様は、端末デバイス１０５から送信される端末データに関して、例えば、端末データに含まれる項目の追加や変更、ストリーミング方式などのデータ配信方式および送信時のレイテンシなどの性能要件などを指す。

データ提供者は、端末データを生成する端末デバイス１０５を保有および管理する企業、組織および個人を指す。多くの場合、データ提供者は、企業であるが、自社の既存業務で利用するために端末デバイス１０５を保有し、端末データを収集している。

データ利用者は、データ提供者が管理する端末デバイス１０５で生成された端末データの流通を受け、その端末データを利用する企業、組織または個人を指す。

利用者コンソール１０１は、データ流通管理システム１００が提供するデータ流通管理機能をシステム利用者が利用するためのインターフェースである。システム利用者は、上記のデータ提供者とデータ利用者の双方を指す。システム利用者は、利用者コンソール１０１を用いて、利用時入力データ１０９を入力することができる。利用時入力データ１０９は、システム利用者に提供されるデータのデータ仕様をシステム利用者ごとに指定することができる。

端末デバイス１０５は、データ流通管理システム１００を介して流通される端末データを生成する。端末デバイス１０５は、例えば、スマートフォンなどの携帯端末、工場機器に設置されたセンサ、救急車両の管制センタに位置情報や患者の容体をセンシングしたデータを送信する救急車などである。

端末データ受付部１０６は、端末デバイス１０５が生成した端末データの入力を受け付け、システム実行部１０３へ転送する。

データ提供者システム１０７は、自社が保有および管理する端末デバイス１０５の端末データが、データ流通管理システム１００を経由して提供される。データ提供者である企業Ａ１７１は、データ提供者システム１０７を利用する。企業Ａ１７１は、複数の端末デバイス１０５を含む端末グループ１７４を管理する。

データ利用者システム１０８は、他社が保有および管理する端末デバイス１０５から生成された端末データを、データ流通管理システム１００を経由して受ける。データ利用者である組織Ｂ１７２は、データ利用者システム１０８を利用する。

システム管理部１０２は、端末デバイス１０５から収集される端末データの送信先のデータ仕様を管理する。このとき、システム利用者が入力する各種情報や、システム利用者によって希望される提供データのモデル変換処理およびサンプリング処理などを実行するノードパッケージや、ノードパッケージをデプロイする際に必要になるパラメータを管理したり、ノードパッケージをデプロイしたりする。

ノードパッケージは、端末データの仕様変更に関わる機能要件および非機能要件の達成を目的とした処理ノード１３１の構築（デプロイ）を自動化するスクリプト群である。ノードパッケージは、処理ノード１３１を構成するミドルウェアの導入・構築処理やミドルウェアを実行制御するプログラムのほか、ミドルウェアが導入された計算リソースのクラスタリングやネットワーク設定などを含んでいてもよい。また、ノードパッケージは、構築された処理ノード１３１内で実施されるデータ構造変換処理プログラムが一部に含まれていてもよい。このスクリプトの実行によって、入力されたリクエストデータ（端末データ）のモデル変換やストリーミングデータのサンプリングなどを実行する処理ノード１３１の構築や処理実行がなされる。処理ノード１３１の実態は、ＶｉｒｔｕａｌＭａｃｈｉｎｅ（ＶＭ）、Ｃｏｎｔａｉｎｅｒ（コンテナ）またはクラウドサービス型のデータ処理機能であってもよい。

ノードパッケージを実現する具体的な製品として、コンテナベースのＩＴシステム構成管理ツールであるＧｏｏｇｌｅ社が開発するＫｕｂｅｒｎｅｔｅｓや、Ｒｅｄｈａｔ社が開発するＡｎｓｉｂｌｅなどが挙げられる。

システム実行部１０３は、端末データ（リクエストデータ）を受け付け、データ提供先システムごとにデプロイされる個々のノード管理テナント１２３へ入力データを複製して転送したり、転送されたデータを処理してデータ提供先システムに送信したりする。データ提供先システムは、データ提供者システム１０７とデータ利用者システム１０８である。

ここで、ノード管理テナント１２３は、システム利用者ごとに別個のものとしてデプロイされる。そして、ノード管理テナント１２３は、システム利用者ごとに提供を受けたいデータの仕様に適合するように、１種類の端末データのデータ仕様を変換することができる。これにより、データ流通管理システム１００は、端末データのデータ仕様が変更された場合においても、システム利用者ごとに提供を受けたいデータの仕様に適合させることができ、システム利用者が求めるデータを継続的に流通させることができる。

以下、システム管理部１０２およびシステム実行部１０３の構成および動作について詳細に説明する。

システム管理部１０２は、システム操作ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）提供部１１１と、利用者情報管理テーブル１１２と、データスキーマ管理テーブル１１３と、ノード設定管理テーブル１１５と、ノード設定マッピング部１１６と、デプロイ実行部１１７と、パッケージ管理レポジトリ１１８を備える。

システム操作ＡＰＩ提供部１１１は、利用者コンソール１０１を通じて、データ流通管理システム１００を利用する企業Ａ１７１や組織Ｂ１７２と、データ流通管理システム１００の間で必要な情報のやり取りを行い、その情報を利用者情報管理テーブル１１２と、データスキーマ管理テーブル１１３と、ノード設定管理テーブル１１５へ分配して格納する。

利用者情報管理テーブル１１２は、システム操作ＡＰＩ提供部１１１に入力された利用者情報や、システム実行部１０３でデータ処理を実施する処理ノード１３１のノード設定情報などを登録する。

データスキーマ管理テーブル１１３は、データ流通管理システム１００で流通するデータのデータスキーマの定義をシステム利用者ごとに登録する。例えば、データスキーマ管理テーブル１１３は、端末データのコンテンツに含まれるデータ項目ごとに提供の有無や提供相手の範囲を管理することができる。データ提供者である企業Ａ１７１の場合は、端末データに含まれるデータスキーマと、自社が受け取る出力データのデータスキーマの２つを持つ。データ利用者である組織Ｂ１７２の場合は、他者から受け取る出力データのデータスキーマのみを持つ。

ノード設定管理テーブル１１５は、パッケージ管理レポジトリ１１８で蓄積される個々のノードパッケージについて、予め作成されたパラメータ設定のメタ情報などを登録する。例えば、ノード設定管理テーブル１１５は、データコンテンツにつき、テキスト、画像および動画データなどのデータ形式や、データ提供方式につき、データ配信形態（逐次配信、バッチデータ配信など）とデータ提供のプロトコル（ＨＴＴＰかＷｅｂＳｏｃｋｅｔなど）や、性能要件につき、レイテンシ、スループットおよび同時接続端末数などのデータ仕様に関する種々の条件を踏まえてテンプレート化されたノードパッケージを管理することができる。

ノード設定マッピング部１１６は、システム利用者が求める機能要件および非機能要件をデプロイ可能なノードパッケージの設計にマッピングする。例えば、ノード設定マッピング部１１６は、データスキーマに沿って入出力データ間のデータモデル変換を実行したり、入力データをサンプリングしたりする機能を持つ処理ノード１３１のデプロイに関して、処理ノード１３１のデプロイスクリプトであるノードパッケージの選択やパッケージデプロイ時に入力するパラメータを補完したりする。

例えば、ノード設定マッピング部１１６は、ストリーミングデータのバッチデータ化については、システム利用者に提供されるデータのデータ仕様またはデータ利用者などからの入力により、バッチデータ作成に必要なバッチ間隔などの情報を必要に応じて補完したり、サンプリング対象のデータを識別する識別子やサンプリングレートなどの情報を必要に応じて補完したりすることができる。また、ノード設定マッピング部１１６は、システム利用者に提供されるデータのデータ仕様のコンテンツに構造化テキストデータ（ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ（登録商標） Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）やＣＳＶ（Ｃｏｍｍａ−Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ））が含まれる場合に、システム利用者に提供されるデータのデータ仕様のコンテンツ定義と、端末デバイス１０５から得られる端末データのデータ仕様のコンテンツ定義の双方を入力として得ることにより、端末データに含まれるデータ項目の削除や項目名の変更を施すことができる。

デプロイ実行部１１７は、ノード設定マッピング部１１６が算出したノードパッケージおよびパラメータを入力として受け付け、システム実行部１０３に処理ノード１３１をデプロイする。ここで、処理ノード１３１をデプロイすることにより、ストリーミングデータのバッチデータ化やサンプリングなどのデータ処理機能と、端末データのデータ構造を送信先のデータ構造に変換するデータ構造変換機能をゲートウェイ上で実現することができる。

パッケージ管理レポジトリ１１８は、パッケージ管理者１７３が提供するノードパッケージを蓄積し、管理する。

システム実行部１０３は、リクエスト転送先情報管理テーブル１２１と、リクエスト複製・転送実行部１２２と、ノード管理テナント１２３を備える。

リクエスト転送先情報管理テーブル１２１は、端末データをリクエストデータとして受け付けるデータパス情報や送信先情報と、リクエストデータを処理ノード１３１へ転送する際に必要な処理ノード１３１のアドレス情報などを管理する。

リクエスト複製・転送実行部１２２は、端末データ受付部１０６から入力された端末データを複製し、システム利用者ごとに用意されるノード管理テナント１２３で管理される各処理ノード１３１へ転送する。例えば、ノード管理テナント１２３は、システム利用者ごとに分離されているため、リクエスト複製・転送実行部１２２は、端末デバイス１０５から送信された１つのリクエストデータを複製し、企業Ａ１７１と組織Ｂ１７２のそれぞれのノード管理テナント１２３に転送する。リクエストデータは、リクエスト転送先情報管理テーブル１２１が示す処理ノード１３１のアドレスへ転送される。

ノード管理テナント１２３は、システム利用者ごとに用意される処理ノード１３１が稼働する。ノード管理テナント１２３は、システム実行部１０３が稼働するサーバシステム以外にも、パブリッククラウドやプライベートクラウド上に構築されてもよい。ノード管理テナント１２３は、システム利用者ごとに作成され、処理ノード１３１が格納される論理的に分割されたネットワーク環境である。

システム実行部１０３内部では、ノード管理テナント１２３の作成時にノード管理テナント１２３のドメイン名が生成され、リクエスト転送先情報管理テーブル１２１に登録される。ドメイン名のほか、テナント名によりノード管理テナント１２３へのデータ通信が可能であってもよい。ノード管理テナント１２３の例として、Ａｍａｚｏｎ Ｗｅｂ ＳｅｒｖｉｃｅのＶＰＣ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｃｌｏｕｄ）などがある。ノード管理テナント１２３は、処理ノード１３１へのロードバランシング機能を提供し、ノード管理テナント１２３に対するデータ入力をノード管理テナント１２３内の処理ノード１３１へルーティングする。

また、処理ノード１３１が端末データのサンプリング機能を提供する場合、任意の端末データは特定の処理ノード１３１に入力される必要があるが、ノード管理テナント１２３で実行されるロードバラインシング機能は、例えば、端末デバイス１０５のアドレス情報や、入力データに含まれるデータ項目をキーにして、任意の端末データを適切な処理ノード１３１へ振り分ける機能を提供してもよい。

ノード管理テナント１２３は、処理ノード１３１を備える。各処理ノード１３１は、データ処理部１３２と、リクエストデータ送受信部１３３を備える。

処理ノード１３１は、システム管理部１０２で管理される送信先のデータ仕様に基づいてデプロイされ、端末データの仕様変更に関する処理を実行する。このとき、処理ノード１３１は、リクエスト複製・転送実行部１２２を経由して入力されるリクエスト情報に対して、データモデル変換、サンプリングおよびマイクロバッチ化などの処理を施す。例えば、処理ノード１３１は、端末デバイス１０５から受信した端末データのコンテンツに含まれるデータのデータ構造を、システム利用者に提供されるデータのデータ仕様で定義されたデータ構造に変換したり、その変換データのバッファリングによるストリーミングデータのバッチデータ化やサンプリングなどの処理を実行したりする。処理ノード１３１は、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）やコンテナのほか、クラウドサービスとして提供される関数実行型の計算リソースとして提供されてもよい。

データ処理部１３２は、データモデル変換、サンプリングおよびマイクロバッチ化などの処理ロジックの実行機能を提供する。処理ロジックは、ノードパッケージに予め含まれていてもよい。この場合、データ処理部１３２は、処理ノード１３１のデプロイ時のパラメータに含まれる入出力データスキーマを動的に読み込み、データ構造を変換するプログラムや、パラメータに指定されたサンプリングレートで入力されたリクエストデータのサンプリングなどを実行する。

リクエストデータ送受信部１３３は、処理ノード１３１で処理したリクエストデータを別の処理ノード１３１との間で送受信したり、データ提供先システムへ送信したりする。特に、データの送信に必要なアドレス情報は、処理ノード１３１の作成時のパラメータ、あるいはリクエスト転送先情報管理テーブル１２１の情報が更新されたタイミングで入力されてもよい。

図２は、図１の利用時入力データの一例を示す図である。
図２において、利用時入力データ１０９は、システム利用者がシステム利用開始時に入力する。利用時入力データ１０９により、データ流通管理システム１００内で処理される端末データに対する処理種別や、処理したデータの送信先情報を設定する。

利用時入力データ１０９は、データ提供者による入力データ２０１か、データ利用者による入力データ２０２かで異なる。データ提供者による入力データ２０１は、端末デバイス１０５から受信する入力データのデータスキーマを含む場合があるが、データ利用者による入力データ２０２ではこれを必要としない。これは、データ提供者と異なり、データ利用者は、端末デバイス１０５を管理しないことによる。

いずれの入力データ２０１、２０２も、利用者情報２１１と、データスキーマ２１２と、流通情報２１３と、システム要件２１４を含む。

利用者情報２１１は、システム利用者を識別する情報である。システム利用者を識別する識別子は、企業や企業内組織のような団体名を用いてもよいし、英数字からなる識別子を新たに付与してもよい。

データスキーマ２１２は、端末データのデータスキーマ（入力データスキーマ）や、システム利用者がデータ流通管理システム１００からデータを受ける際に期待する送信（出力）データのデータスキーマ（出力データスキーマ）で構成される。出力データのデータスキーマは、システム利用者に提供されるデータのデータ仕様の一部を構成する情報である。

流通情報２１３は、端末デバイス１０５が端末データ受付部１０６にリクエストデータを入力する際のデータパス情報である。このデータパス情報は、データ流通管理システム１００内で端末データを識別する際に利用してもよい。出力データ送信先は、処理ノード１３１で処理されたデータの送信先情報である。

システム要件２１４は、端末デバイス１０５から収集されるリクエストデータのデータ仕様のうち、データモデル以外の仕様に関する情報である。機能要件として、サンプリング、マイクロバッチ化、あるいはストリームデータ化などの出力形態や、処理ノード１３１の実行箇所を定義するデプロイ先に関する要件が含まれていてもよい。また、非機能要件として、出力形態に関してサンプリングレートに関する情報や、ストリームデータを送信するまでのレイテンシ性能や、見込みスループットなどの性能に関する要件が含まれていてもよい。

図３は、図１の利用者情報管理テーブルの一例を示す図である。
図３において、利用者情報管理テーブル１１２は、データ流通管理システム１００の利用者情報を記録する。

利用者情報管理テーブル１１２は、利用組織ＩＤ３１１と、参照データパス３１２と、出力データ送信先３１３と、データ管理者フラグ３１４と、スキーマＩＤ３１５と、ノード設計パターン情報３１６と、テナント名３１７を含む。

利用組織ＩＤ３１１は、データ流通管理システム１００を利用する企業、組織あるいはそれらの部門や個人ごとに割り当てられる識別子情報である。利用組織ＩＤ３１１は、利用者情報管理テーブル１１２の各行３２１〜３２３ごとに割り当てられる。利用組織ＩＤ３１１は、利用時入力データ１０９の利用者情報２１１から作成されてもよいし、データ流通管理システム１００から割り当てられたものでもよい。

参照データパス３１２は、端末デバイス１０５が送信データ受付部１０６にデータを送信する際に利用するエンドポイントの識別子であり、ＲＥＳＴ ＡＰＩにおけるリソース名に相当する。参照データパス３１２は、データ提供者が入力した利用時入力データ１０９によって決定されているが、データ流通管理システム１００が一意なものを決定してもよい。

出力データ送信先３１３は、データ提供者とデータ利用者のそれぞれにおいて、データ流通管理システム１００で処理されたデータの送信を受けるシステムのアドレス情報である。これは、利用時入力データ１０９に定義されることを想定するが、データの送信を受けるシステムの管理者によって、利用者コンソール１０１から変更可能であってもよい。

データ管理者フラグ３１４は、データ提供者であるかデータ利用者であるかを識別する情報である。

スキーマＩＤ３１５は、システム利用者ごとにデータスキーマ管理テーブル１１３に定義される情報である。スキーマＩＤ３１５は、データ提供者については、管理する端末デバイス１０５から入力されるデータのスキーマと、データ流通管理システム１００から送信されるデータ（出力データ）のデータスキーマが定義される。データ利用者については、データ流通管理システム１００から送信されるデータ（出力データ）のデータスキーマのみが定義される。

ノード設計パターン情報３１６は、システム利用者ごとに用意されるノード管理テナント１２３にデプロイされる処理ノード１３１の設計情報を管理する。ノード設計パターン情報３１６は、システム利用者によって直接入力されるのではなく、利用時入力データ１０９などに基づきノード設定マッピング部１１６によって追記される。

テナント名３１７は、処理ノード１３１がデプロイされるノード管理テナント１２３を識別するための情報である。テナント名３１７は、システム利用者によって直接入力されるのではなく、デプロイ実行部１１７などにより、システム実行部１０３にノード管理テナント１２３が作成された際に自動的に入力される。

図４は、図１のデータスキーマ管理テーブルの一例を示す図である。
図４において、データスキーマ管理テーブル１１３は、システム利用者ごとに生成される入出力データスキーマ情報を管理する。データスキーマ管理テーブル１１３は、スキーマＩＤ４１１と、入力データスキーマ４１２と、出力データスキーマ４１３を含む。データスキーマ管理テーブル１１３は、スキーマ名を含んでいてもよい。

入力データスキーマ４１２は、データ提供者から入力される利用時入力データ１０９に含まれてもいいし、データ提供者が端末データのサンプルをデータ流通管理システム１００に提供することによって、手動または自動で作られてもよい。出力データスキーマ４１３は、利用時入力データ１０９とともにデータ提供者から提供されてもよいし、利用者コンソール１０１を通じて、システム利用者が変更できてもよい。

スキーマＩＤ４１１は、データスキーマ管理テーブル１１３の各行４２１、４２２の識別子であり、データ流通管理システム１００が付与する。スキーマＩＤ４１１は、利用者情報管理テーブル１１２で管理されるスキーマＩＤ３１５と同一である。

入力データスキーマ４１２は、データ提供者が備える端末デバイス１０５から生成され、データ流通管理システム１００に入力されるデータのスキーマである。入力データスキーマ４１２には、データ提供者からデータ利用者に提供されるコンテンツに含まれるデータ項目ごとに提供の有無および提供相手の範囲を設定することができる。入力データスキーマ４１２は、入力される端末データに含まれる項目を網羅していることが想定されるため、利用時入力データ１０９で定義される以外に、入力データサンプルの提供をデータ提供者から受けて補完されてもいい。ただし、入力データスキーマ４１２は、各データ項目がデータ提供者自身以外に流通されるのを防ぐ機能も備えており、データ項目ごとに”Ｓｈａｒｅｄ：Ｆａｌｓｅ”や”Ｓｈａｒｅｄ：Ｔｒｕｅ“のような情報が付加されていてもよい。これらの情報は、データ提供者向けにＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）ベースやＣＵＩ（Ｃｈａｒａｃｔｅｒ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）ベースのインターフェースが設けられていてもよい。また、データ流通範囲の制御については、例えば、業種単位や企業グループ単位のロールを設けて細かく制御されてもよい。

出力データスキーマ４１３は、システム利用者へ提供されるデータについて、データ構造を定義する情報である。出力データスキーマ４１３は、システム利用者が自身の受け取るデータの構造を定義する目的で、入力データスキーマ４１２と同様に、ＧＵＩベースやＣＵＩベースのインターフェースが設けられていてもよい。

図５は、図１のノード設定管理テーブルの一例を示す図である。
図５において、ノード管理テーブル１１５は、パターンＩＤ５１１と、処理対象５１２と、ノード設計パターン５１３を含む。処理対象５１２は、処理種別５１４と、データ種５１５と、データ更新間隔５１６を含む。ノード設計パターン５１３は、ノードパッケージ５１３と、パラメータ５１８と、デプロイ先５１９を含む。

パターンＩＤ５１１は、ノード管理テーブル１１５で管理される各処理ノードパターンの識別子である。パターンＩＤ５１１は、ノード管理テーブル１１５の各行５２１〜５２６に割り当てられる。パターンＩＤ５１１は、データ流通管理システム１００が割り当ててもよい。

処理対象５１２は、個々のパターンで対象とする、データ流通管理システム１００へ入力されたデータに対する処理種別５１４、データ種５１５およびデータ更新間隔５１６の組合せ情報である。処理対象５１２は、処理ノード１３１が処理するデータの形式や処理内容による違いを区別し、この区別と処理ノード１３１の設計パターンを紐づけるための情報である。

ノード設計パターン５１３は、処理ノード１３１に含まれるミドルウェアやサービスの組合せを示すノードパッケージ５１７や、ノードパッケージの実行制御に必要なパラメータ情報５１８、ノードパッケージのデプロイ先５１９を組合せた情報である。ノード設計パターン５１３は、具体的にどのノードパッケージを用い、どんなパラメータを与えて処理ノード１３１の振る舞いを制御するかを決定することができる。

処理種別５１４は、処理ノード１３１が実現する処理内容を示す情報である。ノード管理テナント１２３は、例えば、データモデル変換とデータのサンプリングをシステム利用者から希望された場合、２つの処理ノード１３１をノード管理テナント１２３内にデプロイし、リクエストデータを順に処理することで希望された処理を実現する。処理ノード１３１の順序性については後述する。

データ種５１５は、処理ノード１３１により実行される処理が対象とするデータ形式を示す情報である。データ種５１５は、データ形式の違いにより（例：テキストデータと画像データなど）、処理ノード１３１内で利用されるミドルウェアが異なる場合に、異なるミドルウェアを内包するパッケージを適宜選択して対応するために用いることができる。

データ更新間隔５１６は、処理ノード１３１がリクエストデータに対する処理を実行する際、どの程度の頻度でデータ処理を実行するかの参考情報である。データ更新間隔５１６は、データ流通管理システム１００に入力されたデータが、システム利用者のシステムに送信されるまでの時間に影響を与える。例えば、データ更新間隔５１６は、データ処理のレイテンシなどの非機能要件の指標とみなすこともできる情報である。

処理対象５１２は、データ配信形態（逐次配信、バッチデータ配信など）やデータ提供のプロトコル（ＨＴＴＰかＷｅｂＳｏｃｋｅｔなど）などのデータ提供方式や、レイテンシ、スループットおよび同時接続端末数などの性能要件の情報を含んでいてもよい。

ノードパッケージ５１７は、処理ノード１３１をデプロイする際に用いるパッケージを指定する情報であり、パッケージ管理レポジトリ１１８に蓄積されたノードパッケージを参照するための値である。

パラメータ５１８は、ノードパッケージをデプロイする際に入力するパラメータのメタ情報である。パラメータ５１８は、デプロイされたノードパッケージ（処理ノード１３１）によって実行される処理内容を制御する。例えば、ノード管理テーブル１１５の行５２１は、ＪＳＯＮ形式で入力された端末データのモデル変換を行う処理ノードであるが、どのようなスキーマのデータをどのようなスキーマに変換して出力するのかを外部的に設定する必要がある。行５２１の例では、これを示すパラメータのメタ情報として参照データパスと出力データスキーマＩＤが示されている。

デプロイ先５１９は、ノードパッケージをデプロイする環境を示す情報である。デプロイ先５１９は、データ流通管理システム１００が稼働する環境のほか、システム利用者のオンプレミス環境やパブリッククラウドであってもよい。また、図５では、デプロイ先５１９が固定的に示されているが、システム利用者の要望によって、処理ノード１３１のデプロイ先５１９が動的に変更されてもよい。

図６は、図１のリクエスト転送先情報管理テーブルの一例を示す図である。
図６において、リクエスト転送先情報管理テーブル１２１は、参照データパス６１１と、テナント名６１２と、出力データ送信先６１３と、処理ノードアドレス６１４を含む。

参照データパス６１１は、端末デバイス１０５からリクエストデータ受付部１０６を経由して、リクエスト複製・転送実行部１２２に到着した端末データを識別する情報である。

テナント名６１２は、システム実行部１０３内部に作成されるノード管理テナント１２３の識別情報またはリクエストデータの転送先アドレス情報である。

出力データ送信先６１３は、ノード管理テナント１２３内部の処理ノード１３１で処理された端末データが最終的に送信されるアドレス情報である。出力データ送信先６１３は、利用時入力データ１０９などによってシステム利用者によって入力され、デプロイ実行部１１７や利用者情報管理テーブル１１２を経由して設定される。

処理ノードアドレス６１４は、ノード管理テナント１２３内にデプロイされたノードパッケージのアドレス情報である。処理ノードアドレス６１４は、ノードデプロイ実行部１１７などによって、パッケージデプロイ後に自動的に保管される。処理ノードアドレス６１４は、リクエスト転送先情報管理テーブル１２１の各行６２１〜６２５に割り当てられる。

ここで、１つの参照データパス６１１に対して、データ提供者システム１０７の出力データ送信先６１３＝ｓｙｓ−ａ．ｃｏｍと、データ利用者システム１０８の出力データ送信先６１３＝ｓｙｓ−ｂ．ｃｏｍをリクエスト転送先情報管理テーブル１２１に設定することにより、端末デバイス１０５から収集された端末データを、企業Ａ１７１と組織Ｂ１７２とで別々に設けられたノード管理テナント１３１に入力することができ、端末データのデータ仕様が変更された場合においても、システム利用者ごとに提供を受けたいデータの仕様に適合させることができる。

図７は、図１のデータ流通管理システムのテータ提供者向けの動作を示すフローチャートである。
図７において、Ｓ７１０では、図１の企業Ａ１７１は、利用者コンソール１０１から、図２の利用時入力データ２０１を入力する。

Ｓ７２０は、Ｓ７１０の入力を受けて、システム操作ＡＰＩ提供部１１１が実行する。Ｓ７２０では、システム操作ＡＰＩ提供部１１１は、Ｓ７２１からＳ７２３を実行する。

Ｓ７２１では、システム操作ＡＰＩ提供部１１１は、利用時入力データ１０９のうち、利用者情報２１１と流通情報２１３を利用者情報管理テーブル１１２に登録する。

Ｓ７２２では、システム操作ＡＰＩ提供部１１１は、利用時入力データ１０９のうち、データスキーマ２１２をデータスキーマ管理テーブル１１３に登録する。

Ｓ７２３では、システム操作ＡＰＩ提供部１１１は、利用時入力データ１０９のうち、データスキーマ２１２とシステム要件２１４をノード設定管理テーブル１１５に入力する。

Ｓ７３０では、ノード設定マッピング部１１６は、システム操作ＡＰＩ提供部１１１から入力されたシステム要件２１４を基に、処理ノード１３１のデプロイを実行する。Ｓ７３０では、ノード設定マッピング部１１６は、Ｓ７３１からＳ７３４を実行する。

Ｓ７３１では、ノード設定マッピング部１１６は、システム利用者が希望するデータ仕様の変換に必要なノードパッケージをノード設定管理テーブル１１５から選択する。このとき、ノード設定マッピング部１１６は、図２の入出力データスキーマ２１２の変換（データモデル変換）に着目し、図５の処理対象５１２のデータ種５１５からデータモデル変換処理を実行するノードパッケージを選択する。

Ｓ７３２では、ノード設定マッピング部１１６は、図５のパッケージ５１７のパラメータ５１８（参照データパスと入出力データスキーマ）を補完し、図３の利用者情報管理テーブル１１２のノード設計パターン情報３１６のフローおよびパラメータに登録する。

Ｓ７３３では、ノード設定マッピング部１１６は、図２のシステム要件２１４の機能要件(サンプリングやマイクロバッチ化など)を満たす図５の処理種別５１４などの条件に合致するパッケージ５１７を、ノード設定管理テーブル１１５から１つ以上選択する。

パッケージ５１７の選択には、処理種別５１４のほか、処理対象５１２のデータ種５１５およびデータ更新間隔５１６（図２のシステム要件２１４の非機能要件のレイテンシなど）などの条件を利用することができる。

パッケージ５１７の選択に関して、“データモデル変換”、“サンプリング”および“マイクロバッチ化”のうち２つ以上が必要な場合には、Ｓ７３０で示されるように“データモデル変換”のパッケージ選択が先に実施され“サンプリング”および“マイクロバッチ”の順で実行されることを想定している。処理ノード１３１の実行順序は、別途ルールとして定義されてもよい。処理種別５１２は、“データモデル変換”、“サンプリング”および“マイクロバッチ化”の３つ以外の種類があってもよい。

Ｓ７３４では、ノード設定マッピング部１１６は、Ｓ７３３で選択したノードパッケージが要求するパラメータを、図２のシステム要件２１４で補完し、図３の利用者情報管理テーブル１１２のノード設計パターン情報３１６に追記するデプロイ実行部１１７に入力する。ノード設定管理テーブル１１５のパラメータ５１８は、ノードパッケージのデプロイ時に設定すべきパタメータのメタ情報であるため、補完の必要がある。Ｓ７３３で選択した全てのノードパッケージに対してＳ７３４を繰り返す。

Ｓ９５０では、デプロイ実行部１１７は、ノード設定マッピング部１１６の一連の処理Ｓ７３０によって登録または更新された利用者情報管理テーブル１１２のノード設計パターン情報３１６に従って、ノード管理テナント１２３や処理ノード１３１をシステム実行部１０３にデプロイする。その後、デプロイ実行部１１７は、ノード管理テナント１２３や処理ノード１３１への端末データの転送に必要な情報をリクエスト転送先情報管理テーブル１２１に登録する。

端末データの転送に必要な情報の例は、リクエスト転送先情報管理テーブル１２１で管理される図６のテナント名６１２や処理ノードアドレス６１４が挙げられる。これらの情報は、システム実行部１０３においてＩＴシステムの名前解決方法であるＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）により転送先が一意に特定可能であってもよい。また、図１のノード管理テナント１２３内で処理した転送データを、システム利用者が備えるシステムに再転送するための情報として、図６の出力データ送信先６１３が、図３の利用者情報管理テーブル１１２の出力データ送信先３１３を用いて補完されてもよい。

Ｓ７４１では、図１の企業Ａ１７１は、企業Ａ１７１が管理する端末グループ１７４に含まれる端末デバイス１０５のデータ送信先として、データ受付部１０６へのアクセス情報（参照データパス）を設定する。

Ｓ７５１では、端末データ受付部１０６は、端末デバイス１０５からの端末データをリクエスト複製・転送実行部１２２に入力する。

Ｓ７５２では、リクエスト複製・転送実行部１２２は、リクエスト転送先情報管理テーブル１２１の情報に従って、端末データ(リクエストデータ)をノード管理テナント１２３に転送する。

Ｓ７５３では、ノード管理テナント１２３は、端末データ(リクエストデータ)を処理ノード１３１へ転送し、その端末データがデータ提供先のデータ仕様に適合するように処理した後、その処理データをデータ提供先に送信し、Ｓ７５１に戻る。

図８は、図１のデータ流通管理システムのテータ利用者向けの動作を示すフローチャートである。
図８において、データ利用者による利用の場合、図７のＳ７２０、Ｓ７３０、Ｓ９５０、Ｓ７５２およびＳ７５３が共通している。

Ｓ８１０では、図１の組織Ｂ１７２は、利用者コンソール１０１から、図２の利用時入力データ２０２を入力する。

次に、システム操作ＡＰＩ提供部１１１はＳ７２０を実行し、ノード設定マッピング部１１６はＳ７３０を実行し、デプロイ実行部１１７はＳ９５０を実行する。

Ｓ８４１では、企業Ａ１７１が管理する端末デバイス１０５は、逐次的または定期的に端末データを端末データ受付部１０６に送信する。

Ｓ８４２では、リクエスト複製・転送実行部１２２は、リクエスト転送先情報管理テーブル１２１の情報に従って、端末データ(リクエストデータ)をノード管理テナント１２３に転送する。

Ｓ８４３では、ノード管理テナント１２３は、端末データ(リクエストデータ)を処理ノード１３１へ転送し、その端末データがデータ提供先のデータ仕様に適合するように処理した後、その処理データをデータ提供先に送信し、Ｓ８４１に戻る。

図９は、図１のシステム管理部の登録時の動作を示すフローチャートである。
図９において、Ｓ９１１では、図１のパッケージ管理レポジトリ１１８は、パッケージ管理者１７３によるノードパッケージの追加、削除および更新を受ける。

Ｓ９１２では、パッケージ管理者１７４は、パッケージの機能要件および非機能要件や、パッケージをデプロイして作成される処理ノード１３１によるリクエストデータ処理に必要なパラメータをノード設定管理テーブル１１５に登録する。

図１０は、図１のシステム管理部による処理ノードのデプロイ時の動作を示すフローチャートである。
図１０において、Ｓ９２１では、システム操作ＡＰＩ提供部１１１は、システム利用者が入力したデータスキーマ２１２と、システム要件２１４（機能・非機能要件情報）をノード設定マッピング部１１６に入力する。

次に、ノード設定マッピング部１１６は、図７のＳ７３０を実行する。

次に、Ｓ９４１では、ノード設定マッピング部１１６は、更新した利用者情報管理テーブル１１２の対象行データをデプロイ実行部１１７に入力する。

次に、デプロイ実行部１１７は、Ｓ９５０を実行する。Ｓ９５０では、デプロイ実行部１１７は、Ｓ９５１からＳ９５３を実行する。

Ｓ９５１では、デプロイ実行部１１７は、リクエスト複製・転送実行部１２２からのデータ入力を受け付けるノード管理テナント１２３をシステム実行部１０３に設置する。ノード管理テナント１２３は、ＶＭやコンテナ、パブリッククラウドサービスなどの処理ノード１３１が設置・実行可能な論理的なネットワーク環境である。

Ｓ９５２では、デプロイ実行部１１７は、図３のノード設計パターン情報３１６に記載された情報に基づいて、処理ノード１３１をノード管理テナント１２３に設置する。

Ｓ９５３では、デプロイ実行部１１７は、処理ノード１３１やノード管理テナント１２３の受信先情報(アドレスなど)をリクエスト転送先情報管理テーブル１２１に登録する。

Ｓ９６１では、リクエスト複製・転送実行部１２２は、リクエストデータ転送先情報管理テーブル１２１の情報を読み込み、ノード管理テナント１２３や処理ノード１３１へ端末データを転送するための情報をキャッシュする。

図１１は、図１の利用者向けコンソールの表示画面の一例を示す図である。
図１１において、図１の利用者コンソール１０１は、データ提供者が端末データを管理する表示画面１０１１と、データ利用者が提供を受けるデータの仕様を管理する表示画面１０２１を表示する。

表示画面１０１１は、ユーザ情報表示１０１２と、収集データ一覧１０１３と、利用データ一覧１０１４と、収集データのデータパスを含む端末データ受付部１０６のアドレス情報１０１５と、入力データスキームの管理画面１０１６を備える。

ユーザ情報表示１０１２は、現在管理システムを利用している利用者の情報を示し、例えば、図３の利用組織ＩＤ３１１などが表示されてもよい。

収集データ一覧１０１３は、自身が管理する端末デバイス１０５からの収集データの一覧を示し、登録している参照データパス３１２が示されていてもよい。参照データパス３１２をクリックするなどして選択することにより、端末データ受付部１０６のアドレス情報１０１５と、入力データスキームの管理画面１０１６が適宜該当するデータに関するものに切り替わってもよい。

利用データ一覧１０１４は、自社あるいは他者から提供されているデータの一覧を示し、各データの参照データパス３１２が示されていてもよい。収集データ一覧１０１３と同様、参照データパス３１２を選択することにより、表示画面１０２１に関して後述するように、利用するデータのデータ仕様を管理する画面に遷移してもよい。

端末データ受付部１０６のアドレス情報１０１５は、選択されているデータ（自社管理の端末デバイス１０５が生成するデータ）を受け付ける端末データ受付部１０６のアドレスやＵＲＬ情報などを示す。

入力データスキームの管理画面１０１６は、端末データのデータ構造を示す。データの列名や型名は、端末データのサンプルを入力することで自動的に補完されてもよい。管理画面１０１６は、個々のデータ項目について、他のデータ利用者へデータを提供する際に、公開の是非を変更することが可能であってもよい。

表示画面１０２１は、ユーザ情報表示１０１２と、収集データ一覧１０１３と、利用データ一覧１０２２と、データ利用方式設定画面１０２３と、データ構造設定画面１０２４とを備える。

利用データ一覧１０２２は、利用データ一覧１０１４と同様の情報を提供する。ただし、出力データスキーマは、システム利用者が柔軟に変更可能であり、各データに対して複数の出力データスキーマを作成し、適宜選択して利用することが可能であってもよい。利用データ一覧１０２２は、利用可能な（出力）データスキーマを一覧表示したり、どの（出力）データスキーマが適用されているかを示すレ点などのマークを示したりしてもよい。

データ利用方式設定画面１０２３では、利用データのデータ仕様のうち、サンプリングレートなどを設定することができる。データ利用方式設定画面１０２３は、他者から提供される端末データのオリジナルのデータ収集方式（データ生成頻度など）を示していてもよい。この情報を参考に、データ利用者は自身が希望するデータ利用方式（サンプリングレートやマイクロバッチデータの収拾間隔）を設定可能である。

データ構造設定画面１０２４は、データ提供者が自社以外であれば、データ提供者が公開可能としたデータ項目、データ提供者が自身であれば、収集する全てのデータ項目を表示してもよい。データ構造設定画面１０２４では、管理システム１００がデータ提供先にデータを提供する際に、出力データに含むべきデータ項目の要否を設定することができる。

なお、図１では、システム管理部１０２とシステム実行部１０３をデータ流通管理システム１００内に設けた例を示したが、システム管理部１０２とシステム実行部１０３を分散して配置し、システム管理部１０２とシステム実行部１０３とをネットワークを介して接続するようにしてもよい。例えば、システム管理部１０２は、複数のシステム利用者に対して共通に設け、システム実行部１０３は、システム利用者ごとに別個に設けるようにしてもよい。

図１２は、第２実施形態に係るデータ流通管理システムの構成を示すブロック図である。
図１２において、データ流通管理システム１００Ｂは、システム管理部１０２Ｂと、システム実行部１０３Ｂを備える。データ流通管理システム１００Ｂは、利用者コンソール１０１と、端末データ受付部１０６と、データ提供者システム１０７と、データ利用者システム１０８に接続されている。

データ流通管理システム１００Ｂは、端末デバイス１０５から収集されるＩｏＴデータなどを、企業１７１や組織１７２の枠を超えて流通させる場合、端末デバイス１０５が生成する端末データのデータ仕様をデータ提供者およびデータ利用者ごとに柔軟に変更して流通させる。このとき、データ流通管理システム１００Ｂは、データ利用者が受け取る任意の参照データパスを経由する端末データについて、その端末データの内容に応じてデータ仕様を変更することができる。

ここで、システム利用者は、利用者コンソール１０１を用いて、利用時入力データ１０９および業務指標−性能指標マッピングデータ１１０１を入力することができる。業務指標−性能指標マッピングデータ１１０１は、端末デバイス１０５から受信した端末データとシステム利用者に固有な業務指標への対応付けと、業務指標と図２のシステム要件２１４への対応付けとを行うための参考情報である。

システム管理部１０２Ｂは、システム利用者が入力する各種情報や、システム利用者によって希望される提供データのモデル変換処理およびサンプリング処理などを実行するノードパッケージや、ノードパッケージをデプロイする際に必要になるパラメータを管理したり、ノードパッケージをデプロイしたりする。このとき、システム管理部１０２Ｂは、端末デバイス１０５ごとの状態を逐次監視し、端末デバイス１０５から受信した端末データの変化を特定の業務指標に対応付け、業務指標の変化に応じて特定の端末デバイス１０５からの端末データに対してデータ仕様の変更を動的に与えることができる。

システム実行部１０３Ｂは、端末データを受け付け、データ提供先システムごとに端末データの内容に応じてデプロイされる個々のノード管理テナント１２３Ｂへ入力データを複製して転送したり、転送されたデータを処理してデータ提供先システムに送信したりする。

ここで、ノード管理テナント１２３Ｂは、システム利用者ごとに端末データの内容に応じて別個のものとしてデプロイされる。そして、ノード管理テナント１２３Ｂは、システム利用者ごとに提供を受けたいデータの仕様に適合するように、端末データのデータ仕様を、その端末データを出力する端末デバイス１０５の状態に応じて変更することができる。これにより、データ流通管理システム１００Ｂは、端末データのデータ仕様が変更された場合においても、システム利用者ごとに提供を受けたいデータの仕様に適合させることができ、データ利用者が求めるデータを継続的に流通させることができる。

システム管理部１０２Ｂは、図１のシステム管理部１０２の構成に加え、データ流通システム動的管理部１１２０を備える。システム管理部１０２Ｂは、図１の利用者情報管理テーブル１１２の代わりに、利用者情報管理テーブル１１２Ｂを備える。データ流通システム動的管理部１１２０は、業務指標算出ロジック管理テーブル１１２１と、業務指標別ノード最適設定管理テーブル１１２２と、業務指標抽出部１１２３と、目標性能指標算出部１１２４を備える。

利用者情報管理テーブル１１２Ｂは、利用時入力データ１０９および業務指標−性能指標マッピングデータ１１０１を利用者ごとに管理する。

データ流通システム動的管理部１１２０は、端末デバイス１０５から受信する端末データについて、業務指標−性能指標マッピングデータ１１０１に定義された受信データと業務指標の対応付けを算出し、業務指標の変化を検出した場合に必要な処理ノード１３１Ｂのデプロイ指示や端末データの転送ルールの変更を行う。

データ流通システム動的管理部１１２０は、業務指標算出ロジック管理テーブル１１２１と、業務指標別ノード最適設定管理テーブル１１２２と、業務指標抽出部１１２３と、目標性能指標算出部１１２４を備える。

業務指標算出ロジック管理テーブル１１２１は、端末デバイス１０５から受信した端末データを、データ利用者に固有の業務指標に変換するロジックを管理する。業務指標算出ロジック管理テーブル１１２１で管理される情報は、業務指標−性能指標マッピングデータ１１０１に定義された情報の一部がシステム操作ＡＰＩ提供部１１１によって格納されてもよい。

業務指標別ノード最適設定管理テーブル１１２２は、データ利用者に固有の業務指標ごとに、ノード管理テナント１２３Ｂにデプロイされる処理ノード１３１Ｂのパッケージおよびパラメータなどを管理する。業務指標別ノード最適設定管理テーブル１１２２で管理される情報のうち、ノード管理テナント１２３Ｂ内の処理ノード１３１Ｂのデプロイに関する情報は、ノード設定マッピング部１１６により算出された情報が格納されてもよい。

業務指標抽出部１１２３は、端末デバイス１０５から受信する端末データについて、リクエスト複製・転送実行部１２２から転送されるデータと、業務指標算出ロジック管理テーブル１１２１で管理されるロジック情報を基に、データ利用者に固有の業務指標を算出する。

目標性能指標算出部１１２４は、業務指標抽出部１１２３によって算出されたデータ利用者に固有の業務指標と、業務指標別ノード最適設定管理テーブル１１２２の情報を基に、データ利用者の業務指標の変化に対して、端末データが転送されるべきノード管理テナント１２３Ｂの判定及び端末デバイス１０５からの受信データの転送情報の変更などを実施する。

システム実行部１０３Ｂは、リクエスト転送先情報管理テーブル１２１Ｂと、リクエスト複製・転送実行部１２２と、ノード管理テナント１２３Ｂを備える。

ノード管理テナント１２３Ｂは、端末データの内容に応じてシステム利用者ごとに用意される処理ノード１３１Ｂが稼働する。ノード管理テナント１２３Ｂは、システム利用者ごとかつ端末データの内容ごとに作成され、処理ノード１３１Ｂが格納される論理的に分割されたネットワーク環境である。

ノード管理テナント１２３Ｂは、処理ノード１３１Ｂを備える。各処理ノード１３１Ｂは、データ処理部１３２Ｂと、リクエストデータ送受信部１３３Ｂを備える。

処理ノード１３１Ｂは、リクエスト複製・転送実行部１２２を経由して入力されるリクエスト情報に対して、データモデル変換、サンプリングおよびマイクロバッチ化などの処理を施す。

データ処理部１３２Ｂは、データモデル変換、サンプリングおよびマイクロバッチ化などの処理ロジックの実行機能を提供する。

リクエストデータ送受信部１３３Ｂは、処理ノード１３１Ｂで処理したリクエストデータを別の処理ノード１３１Ｂと送受信したり、データ提供先システムへ送信したりする。

以下、図１２のデータ流通管理システム１００Ｂの動作について、救急車で収集される急患の状態に関する心拍数や心電図情報を、その急患の搬送予定の病院の急患管理システムに通知するユースケースを想定して説明する。このユースケースでは、急患の状態情報を送信する救急車を１つの端末デバイス１０５、急患管理システムをデータ提供先システムとみなすことができる。

図１のデータ流通管理システム１００では、急患管理システムが受け取るデータ仕様を、急患管理システムの管理者が利用者コンソール１０１から設定することができる。しかし、図１のデータ流通管理システム１００では、参照データパスごとに１つのデータ仕様が適用されるため、急患管理システムは、急患の状態変化（例えば、心拍数の低下による急患の急変など）に応じて、端末データが変化した端末デバイス１０５のみを対象にデータの仕様を動的に変更することができない。

これに対して、図１２のデータ流通管理システム１００Ｂは、端末デバイス１０５ごとの状態を逐次監視し、端末デバイス１０５から受信した端末データの変化を「急患の状態変化」のような特定の業務指標に対応付け、業務指標の変化に応じて特定の端末デバイス１０５からの端末データに対してデータ仕様を動的に変更することができる。

図１３は、図１２の業務指標−性能指標マッピングデータの一例を示す図である。
図１３において、データ利用者の業務指標−性能指標マッピングデータ１１０１は、利用者情報２１１と、業務指標１２１１と、算出式１２１２と、業務指標別システム要件１２１３を備える。利用者情報２１１は、図２の内容と同一である。

業務指標１２１１は、データ利用者に固有の情報である。業務指標１２１１は、例えば、救急搬送中の急患状態通知システムであれば、「急患状態の緊急度」のような指標パラメータである。図１２のデータ流通管理システム１００Ｂは、この業務指標１２１１の変化に応じて、データ利用者が提供を受けるデータの仕様を変化させる。業務指標１２１１は、業務指標１２１１を管理するデータの識別情報（後述の端末データ識別子１４１１）を含んでいてもよい。

業務指標１２１１の変化は、急患情報通知システムのように、救急車両ごと（端末デバイス１０５ごと）に異なる場合がある。つまり、大多数の救急車両の「急患の緊急度」は低く、救急車両の特定の急患だけ緊急度が高くなる場合がある。このような場合は、データ流通管理システム１００Ｂは、特定の急患の情報を含む救急車両（端末デバイス１０５）を識別し、大多数の端末デバイス１０５の端末データが転送されるノード管理テナント１２３Ｂとは別のノード管理テナント１２３に特定の急患の情報を転送する。図１３の例では、端末データ識別子１４１１は、ｐａｔｉｅｎｔＩｎｆｏ．ｎａｍｅであり、上記の急患情報通知システムでは、急患の名前ごとに、業務指標１２１１の変化が管理される。

算出式１２１２は、業務指標１２１１を算出のための式に関する情報である。例えば、データ利用者が利用する端末デバイス１０５のデータから業務指標１２１１を算出する。算出式１２１２は、業務指標１２１１の算出式の他にも、算出に用いるデータを特定する情報として、端末データの識別を行う参照データパスおよび算出利用データ項目を備える。業務指標−性能指標マッピングデータ１１０１の算出式１２１２の情報は、図１５の業務指標算出ロジック管理テーブル１１２１の算出式１４１３、参照データパス３１２および算出利用データ項目１４１２に設定される。

業務指標別システム要件１２１３は、業務指標１２１１の指標パラメータごとに、データ利用者が求めるシステム要件が定義された情報である。業務指標別システム要件１２１３は、利用時入力データ１０９のシステム要件２１４と同様の情報が、指標パラメータごとに個別に定義されていてもよい。

また、業務指標−性能指標マッピングデータ１１０１は、データ利用者が自身で作成してもよいし、データ流通管理システム１００Ｂを提供するサービスがデータ利用者１７２に対するＳＩ（Ｓｙｓｔｅｍ Ｉｎｔｅｇｒａｔｉｏｎ）を通じて作成してもよい。

図１４は、図１２の利用者情報管理テーブルの一例を示す図である。
図１４において、利用者情報管理テーブル１１２Ｂは、利用組織ＩＤ３１１と、参照データパス３１２と、出力データ送信先３１３と、データ管理者フラグ３１４と、業務指標ＩＤ１３１１と、テナント名１３１２を備える。利用組織ＩＤ３１１と、参照データパス３１２と、出力データ送信先３１３と、データ管理者フラグ３１４は、図３の内容と同一である。利用者情報管理テーブル１１２Ｂの利用組織ＩＤ３１１は、各行１３２１〜１３２３ごとに割り当てられる。

業務指標ＩＤ１３１１は、図１３の業務指標−性能指標マッピングデータ１１０１を参照するための識別子情報である。業務指標ＩＤ１３１１は、業務指標−性能指標マッピングデータ１１０１ごとに図１２の業務指標算出ロジック管理テーブル１１２１で与えられる。

テナント名１３１２は、データ利用者が提供を受ける参照データパス３１２のデータを処理するノード管理テナント１２３Ｂの識別情報である。データ利用者に固有の業務指標１２１１に対して、データ仕様の異なる提供データを生成するために複数のノード管理テナント１２３がデプロイされる場合があるため、１つ以上のテナント名１３１２が管理される。

図１５は、図１２の業務指標算出ロジック管理テーブルの一例を示す図である。
図１５において、業務指標算出ロジック管理テーブル１１２１は、業務指標ＩＤ１３１１と、参照データパス３１２と、利用組織ＩＤ３１１と、端末データ識別子１４１１と、算出利用データ項目１４１２と、算出式１４１３を備える。業務指標ＩＤ１３１１は、図１４の利用者情報管理テーブル１１２Ｂの業務指標ＩＤ１３１１と同一である。業務指標算出ロジック管理テーブル１１２１の業務指標ＩＤ１３１１は、業務指標算出ロジック管理テーブル１１２１の各行１４１２ごとに割り当てられる。利用組織ＩＤ３１１と、参照データパス３１２は、図３の利用者情報管理テーブル１１２の利用組織ＩＤ３１１と、参照データパス３１２とそれぞれ同一である。

端末データ識別子１４１１は、図１３の業務指標１２１１の変化を管理するデータの識別情報である。

算出利用データ項目１４１２は、図１３の算出式１２１２に含まれる情報であり、業務指標の算出のために端末デバイス１０５のデータの中の任意のデータ項目を指定する情報である。図１５の例では、１つのデータ項目を指定しているが、複数個のデータ項目が指定されていてもよい。

算出式１４１３は、図１３の算出式１２１２に含まれる情報であり、算出利用データ項目１４１２で指定されたデータ項目を用いて業務指標を算出するための式情報である。図１５の算出式１４１３は、例えば、グラフ１４３１Ｂで示すことができる。

図１６は、図１２の業務指標別ノード最適設定管理テーブルの一例を示す図である。
図１６において、業務指標別ノード最適設定管理テーブル１１２２は、業務指標ＩＤ１３１１と、業務指標１５１１と、性能指標１５１２と、スキーマＩＤ４１１と、ノード設計パターン情報３１６を備える。ノード設計パターン情報３１６は、図３の利用者情報管理テーブル１１２のノード設計パターン情報３１６と同一である。スキーマＩＤ４１１は、図４のデータスキーマ管理テーブル１１３のスキーマＩＤ４１１と同一である。業務指標ＩＤ１３１１は、図１３の利用者情報管理テーブル１１２Ｂの業務指標ＩＤ１３１１と同一である。

業務指標１５１１は、データ利用者に固有の業務指標に関して取り得る値を示したものである。図１６では、業務指標１５１１が“大”、“中”、“小”のような離散値であるが、“緊急度＝ａ（０≦ａ）”のように連続値であってもよい。

性能指標１５１２は、業務指標１５１１の値に対応する性能指標の値である。性能指標は、データ提供の性能要件を示すことができる。図１６に示すように、業務指標１５１１と性能指標１５１２の値は一見関連性の薄い離散値をとり得る他、“データ更新間隔δ＝ａｘ＋ｂ”のような連続値をとってもよい。

図１７は、図１２のリクエスト転送先情報管理テーブルの一例を示す図である。
図１７において、リクエスト転送先情報管理テーブル１２１Ｂは、参照データパス６１１と、出力データ送信先６１３と、テナント名６１２と、ルール適用順序１６１１と、振分けルール１６１２と、業務指標１６１３と、処理ノードアドレス６１４を備える。参照データパス６１１と、出力データ送信先６１３と、テナント名６１２と、処理ノードアドレス６１４は、図６のリクエスト転送先情報管理テーブル１２１の内容と同一である。

ルール適用順序１６１１は、リクエストデータの転送先を示す各テナント名６１２について、リクエストデータの振り分けルール１６１２を適用する順序を示す。図１７では、データ利用者（出力データ送信先６１３の管理者）が予め指定した業務指標１６１３が“緊急度＝大”に変化し、一部のリクエストデータ（振分けルール１６１２に示したＰａｔｉｅｎｔＩｎｆｏ．ｎａｍｅ＝（ａ、ｂ、ｃ）のデータ）のテナント名６１２「ＳｙｓＢ２」への転送が求められている例を示した。

振分けルール１６１２は、テナント名６１２にリクエストデータを振分ける際に、リクエストデータを識別するルールを定義する。業務指標１６１３は、テナント名６１２で指定されるノード管理テナント１２３Ｂで実施される処理に対応する業務指標を示す値である。

ここで、例えば、１つのデータ利用者システム１０８の出力データ送信先６１３＝ｓｙｓ−ｂ．ｃｏｍに対して、緊急度＝小に対応した処理ノードアドレス＝ｂ１．ｌｏｃａｌと、緊急度＝大に対応した処理ノードアドレス＝ｂ２．ｌｏｃａｌをリクエスト転送先情報管理テーブル１２１Ｂに設定することにより、端末デバイス１０５から収集された端末データを、業務指標１６１３に応じて別々に設けられたノード管理テナント１３１Ｂに入力することができ、業務指標１６１３に応じて性能指標１５１２を変化させることができる。

図１８は、図１２のデータ流通システム動的管理部の登録時の動作を示すフローチャートである。
図１８において、Ｓ１７１１では、システム操作ＡＰＩ提供部１１１は、データ利用者からの業務指標−性能指標マッピングデータ１１０１の入力を受け付ける。

Ｓ１７１２では、システム操作ＡＰＩ提供部１１１は、業務指標−性能指標マッピングデータ１１０１の業務指標１２１１などをデータ流通システム動的管理部１１２０に入力する。

Ｓ１７１３では、データ流通システム動的管理部１１２０は、業務指標１２１１および算出式１２１２などを業務指標算出ロジック管理テーブル１１２１に登録する。

図１９は、図１２のデータ流通管理システムの性能指標変更時の動作を示すフローチャートである。
図１９において、Ｓ７５１では、端末データ受付部１０６は、端末デバイス１０５からの端末データをリクエスト複製・転送実行部１２２に入力する。

Ｓ１８１０は、Ｓ７５１の入力を受けて、リクエスト複製・転送実行部１２２が実行する。Ｓ１８１０では、リクエスト複製・転送実行部１２２は、Ｓ１８１１からＳ１８１４を実行する。

Ｓ１８１１では、リクエスト複製・転送実行部１２２は、リクエスト転送先情報管理テーブル１２１Ｂを参照する。リクエスト転送先情報管理テーブル１２１Ｂの情報は、図１０のＳ９６１においてリクエスト複製・転送実行部１２２にキャッシュされていてもよい。

Ｓ１８１２では、リクエスト複製・転送実行部１２２は、端末データの入力を受けて、図１５の参照データパス６１１と、端末データ識別子１４１１に対応する端末データ内のデータ項目が合致する図１７の振り分けルール１６１２をキーにリクエスト転送先情報管理テーブル１２１Ｂの行を検索する。この処理では、システム利用者の業務指標の変化を踏まえ、端末データの端末データ識別子１４１１ごとに個々のシステム利用者が利用するいくつかのノード管理ナント１２３Ｂに端末データを転送し分けるために必要な情報を取得する。

Ｓ１８１３では、リクエスト複製・転送実行部１２２は、端末データを複製し、検索行が指定するテナント名６１２へ端末データを転送する。

Ｓ１８１４では、リクエスト複製・転送実行部１２２は、検索行の業務指標１６１３と端末データを業務指標抽出部１１２３に転送する。

Ｓ１８２０は、Ｓ１８１４の入力を受けて、業務指標抽出部１１２３が実行する。Ｓ１８２０では、業務指標抽出部１１２３は、Ｓ１８２１からＳ１８２２を実行する。

Ｓ１８２１では、業務指標抽出部１１２３は、業務指標算出ロジック管理テーブル１１２１から業務指標１６１３をキーに行を検索する。

Ｓ１８２２では、業務指標抽出部１１２３は、図１５の算出利用データ項目１４１２に該当する端末データの情報と、算出式１４１３を用いて業務指標を算出し、目標性能指標算出部１１２４に入力する。加えて、業務指標抽出部１１２３は、Ｓ１８１４にて探索した業務指標１６１３（Ｓ１８２２で算出した業務指標とは異なる）を目標性能指標算出部１１２４に入力する。

Ｓ１８３０は、Ｓ１８２２の入力を受けて、目標性能指標算出部１１２４が実行する。Ｓ１８３０では、目標性能指標算出部１１２４は、Ｓ１８３１からＳ１８３４を実行する。

Ｓ１８３１では、目標性能指標算出部１１２４は、Ｓ１８２２で算出した業務指標と、Ｓ１８１４で探索した業務指標１６１３を比較する。両者が一致した場合は、端末データ識別子１４１１で識別される端末データについて、業務指標の変化はなかったと判断し、処理を終了する。両者が一致しなかった場合、業務指標の変化が生じたと判断し、Ｓ１８３２に進む。

Ｓ１８３２では、目標性能指標算出部１１２４は、リクエスト転送先情報管理テーブル１２１Ｂに対して、Ｓ１８２２で算出した業務指標をキーに行検索を行う。行検索がヒットした場合は、Ｓ１８２２で算出した業務指標を示す端末データを処理するノード管理テナント１２３Ｂが既に存在することを意味する。この場合はノード管理テナント１２３Ｂの新たなデプロイは必要ないため、目標性能指標算出部１１２４は、図１７のリクエスト転送先情報管理テーブル１２１Ｂの振り分けルール１６１２の該当行に、端末データの端末データ識別子１４１１を登録する。

Ｓ１８３３では、目標性能指標算出部１１２４は、業務指標別ノード最適設定管理テーブル１１２２から、Ｓ１８２２で算出した業務指標を含む行を検索する。

Ｓ１８３４では、検索行のノード設計パターン情報３１６をデプロイ実行部１１７に入力する。

Ｓ１８４１では、デプロイ実行部１１７およびノード設定マッピング部１１６は、図９のＳ７３０−Ｓ９５０に示す処理で新しいノード管理テナント１２３Ｂと処理ノード１３１Ｂをデプロイする。

Ｓ１８４２では、図１７のテナント名６１２、処理ノードのアクセス情報およびＳ１８２２で算出した業務指標のセットを図１７のリクエスト転送先情報管理テーブル１２１Ｂに格納する。

Ｓ１８４３では、リクエスト転送先情報管理テーブル１２１Ｂから、Ｓ１８２２で算出した業務指標を含む行を探し、振り分けルール１６１２に端末データ識別子を登録する。

図２０は、図１のデータ流通管理システムのハードウェア構成を示すブロック図である。
図２０において、データ流通管理システム１００は、プロセッサ１１、通信制御デバイス１２、通信インターフェース１３、主記憶デバイス１４および外部記憶デバイス１５を備える。プロセッサ１１、通信制御デバイス１２、通信インターフェース１３、主記憶デバイス１４および外部記憶デバイス１５は、内部バス１６を介して相互に接続されている。主記憶デバイス１４および外部記憶デバイス１５は、プロセッサ１１からアクセス可能である。

また、データ流通管理システム１００の外部には、入力装置２０および出力装置２１が設けられている。入力装置２０および出力装置２１は、入出力インターフェース１７を介して内部バス１６に接続されている。入力装置２０は、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置等である。出力装置２１は、例えば、画面表示装置（液晶モニタ、有機ＥＬ（Ｅｌｅｃｔｒｏ Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、グラフィックカード等）、音声出力装置（スピーカ等）、印字装置等である。

プロセッサ１１は、データ流通管理システム１００全体の動作制御を司るハードウェアである。主記憶デバイス１４は、例えば、ＳＲＡＭまたはＤＲＡＭなどの半導体メモリから構成することができる。主記憶デバイス１４には、プロセッサ１１が実行中のプログラムを格納したり、プロセッサ１１がプログラムを実行するためのワークエリアを設けたりすることができる。

外部記憶デバイス１５は、大容量の記憶容量を備える記憶デバイスであり、例えば、ハードディスク装置やＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）である。外部記憶デバイス１５は、各種プログラムの実行ファイルやプログラムの実行に用いられるデータを保持することができる。外部記憶デバイス１５には、データ流通管理プログラム１５Ａおよび管理情報１５Ｂを格納することができる。データ流通管理プログラム１５Ａは、データ流通管理システム１００にインストール可能なソフトウェアであってもよいし、データ流通管理システム１００にファームウェアとして組み込まれていてもよい。

通信制御デバイス１２は、外部との通信を制御する機能を備えるハードウェアである。通信制御デバイス１２は、通信インターフェース１３を介してネットワーク１９に接続される。ネットワーク１９は、インターネットなどのＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷｉＦｉまたはイーサネット（登録商標）などのＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよいし、ＷＡＮとＬＡＮが混在していてもよい。

入出力インターフェース１７は、入力装置２０から入力されるデータをプロセッサ１１が処理可能なデータ形式に変換したり、プロセッサ１１から出力されるデータを出力装置２１が処理可能なデータ形式に変換したりする。

プロセッサ１１がデータ流通管理プログラム１５Ａを主記憶デバイス１４に読み出し、データ流通管理プログラム１５Ａを実行することにより、ネットワーク１９を介して端末デバイス１０５からＩｏＴデータを収集し、ＩｏＴデータのデータ仕様をシステム利用者ごとに柔軟に変更して流通させることができる。プロセッサ１１は、データ流通管理プログラム１５Ａに実行に当たり、管理情報１５Ｂを参照することができる。この時、データ流通管理プログラム１５Ａは、図１のシステム操作ＡＰＩ提供部１１１と、ノード設定マッピング部１１６と、デプロイ実行部１１７と、リクエスト複製・転送実行部１２２と、ノード管理テナント１２３の機能を実現することができる。管理情報１５Ｂは、図１の利用者情報管理テーブル１１２と、データスキーマ管理テーブル１１３と、ノード設定管理テーブル１１５と、パッケージ管理レポジトリ１１８と、リクエスト転送先情報管理テーブル１２１の情報を含むことができる。

なお、データ流通管理プログラム１５Ａの実行は、複数のプロセッサやコンピュータに分担させてもよい。あるいは、プロセッサ１１は、ネットワーク１９を介してクラウドコンピュータなどにデータ流通管理プログラム１５Ａの全部または一部の実行を指示し、その実行結果を受け取るようにしてもよい。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。

１００…データ流通管理システム、１０１…利用者コンソール、１０２…システム管理部、１０３…システム実行部、１０５…端末デバイス、１０６…端末データ受付部、１０７…データ提供者システム、１０８…データ利用者システム、１０９…利用時入力データ、１１１…システム操作ＡＰＩ提供部、１１２…利用者情報管理テーブル、１１３…データスキーマ管理テーブル１１５…ノード設定管理テーブル、１１６…ノード設定マッピング部、１１７…デプロイ実行部、１１８…パッケージ管理レポジトリ、１２１…リクエスト転送先情報管理テーブル、１２１…リクエスト複製・転送実行部、１２３…ノード管理テナント、１３１…処理ノード、１３２…データ処理部、１３３…リクエストデータ送受信部、１７１…企業Ａ、１７２…組織Ｂ、１７３…パッケージ管理者、１７４…企業Ａが管理する端末グループ、１１０１…業務指標−性能指標マッピングデータ、１１２０…データ流通システム動的管理部、１１２１…業務指標算出ロジック管理テーブル、１１２２…業務指標別ノード最適設定管理テーブル、１１２３…業務指標抽出部、１１２４…目標性能指標算出部、１１３１…リクエスト転送先情報管理テーブル

Claims (15)

1. 端末デバイスから収集される端末データの送信先のデータ仕様を管理する管理部と、
   前記管理部で管理される前記送信先のデータ仕様に基づいてデプロイされ、前記端末データの仕様変更に関する処理を実行する処理ノードを備えるデータ流通管理システム。
2. 前記処理ノードを管理するノード管理テナントを備え、
   前記ノード管理テナントを前記送信先ごとに設ける請求項１に記載のデータ流通管理システム。
3. 前記端末データを提供する提供者および前記端末データを利用する利用者ごとに前記ノード管理テナントを設ける請求項２に記載のデータ流通管理システム。
4. 前記提供者から前記利用者に提供されるコンテンツに含まれるデータ項目ごとに提供の有無および提供相手の範囲を定義する請求項３に記載のデータ流通管理システム。
5. 前記端末データが送信される時に利用されるエンドポイントの識別子である１つの参照データパスに対して、前記ノード管理テナントごとに前記処理ノードのアドレスが設定される請求項２に記載のデータ流通管理システム。
6. 前記端末データの仕様変更に関するデータ変換機能がテンプレート化されたパッケージを管理するレポジトリと、
   前記データ仕様変更に関するパラメータを前記パッケージに設定するマッピング部と、
   前記パラメータが設定されたパッケージを前記ノード管理テナントとしてデプロイするデプロイ実行部とを備える請求項２に記載のデータ流通管理システム。
7. 前記デプロイ実行部は、
   前記端末データに含まれるコンテンツについて、テキスト、画像および動画のデータ形式と、前記端末データの送信形態およびデータ提供のプロトコルを含むデータ提供方式と、前記データ提供のレイテンシ、スループットおよび同時接続端末数を含む性能要件に基づいて、前記テンプレート化されたパッケージを選択する請求項６に記載のデータ流通管理システム。
8. 前記処理ノードは、
   前記端末データのデータ構造を前記送信先のデータ仕様で定義されたデータ構造に変換し、
   前記データ構造が変換されたデータのバッファリングによるストリーミングデータのバッチデータ化または前記データ構造が変換されたデータのサンプリングを実行する請求項１に記載のデータ流通管理システム。
9. 前記送信先のデータ仕様または外部入力に基づいて、前記バッチデータの作成に必要なバッチ間隔を含む情報を補完し、
   前記送信先のデータ仕様または外部入力に基づいて、前記サンプリングの対象データの識別子およびサンプリングレートを含む情報を補完する請求項８に記載のデータ流通管理システム。
10. 前記送信先のデータ仕様のコンテンツに構造化テキストデータが含まれる場合、
    前記端末データのデータ仕様のコンテンツ定義と前記送信先のデータ仕様のコンテンツ定義を取得し、
    前記端末データに含まれるデータ項目の削除または項目名の変更を施す請求項８に記載のデータ流通管理システム。
11. 前記処理ノードを管理するノード管理テナントを備え、
    前記ノード管理テナントを前記端末データの内容に応じて分ける請求項１に記載のデータ流通管理システム。
12. 前記端末データを利用する利用者の業務に関する業務指標に基づいて、前記ノード管理テナントを分ける請求項１１に記載のデータ流通管理システム。
13. 前記端末デバイスごとまたは前記端末データに含まれる識別子ごとに前記業務指標を管理し、
    前記端末デバイスから取得した端末データに基づいて前記業務指標を算出し、
    前記管理する業務指標と前記算出した業務指標との比較結果に基づいて、前記算出した業務指標に対応したノード管理テナントをデプロイする請求項１２に記載のデータ流通管理システム。
14. 端末デバイスから収集される端末データの仕様変更に関するデータ変換機能がテンプレート化されたパッケージを管理するレポジトリと、
    前記端末データの仕様変更に関するパラメータを前記パッケージに設定するマッピング部と、
    前記パラメータが設定されたパッケージをデプロイするデプロイ実行部とを備えるデータ流通管理支援装置。
15. 端末デバイスから収集される端末データの仕様変更に関するデータ変換機能がテンプレート化されたパッケージに前記端末データの仕様変更に関するパラメータを設定し、
    前記パラメータが設定されたパッケージをデプロイし、
    前記デプロイされたパッケージを用いることで、送信先のデータ仕様に適合するように前記端末データのデータ仕様を変更し、
    前記データ仕様が変更された前記端末データを前記送信先に送信するデータ流通管理方法。
    
    

Images