特許 7168007 情報処理装置、方法およびプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-10-31

(45)【発行日】2022-11-09

(54)【発明の名称】情報処理装置、方法およびプログラム

(51)【国際特許分類】

   G06F 16/25 20190101AFI20221101BHJP

   G06F 16/17 20190101ALI20221101BHJP

【ＦＩ】

G06F16/25

G06F16/17 200

【請求項の数】 6

(21)【出願番号】P 2020569443

(86)(22)【出願日】2019-12-23

(86)【国際出願番号】 JP2019050400

(87)【国際公開番号】W WO2020158251

(87)【国際公開日】2020-08-06

【審査請求日】2020-12-25

(31)【優先権主張番号】P 2019013183

(32)【優先日】2019-01-29

(33)【優先権主張国・地域又は機関】JP

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100108855

【弁理士】

【氏名又は名称】蔵田 昌俊

(74)【代理人】

【識別番号】100075672

【弁理士】

【氏名又は名称】峰 隆司

(74)【代理人】

【識別番号】100179062

【弁理士】

【氏名又は名称】井上 正

(72)【発明者】

【氏名】柏木 啓一郎

(72)【発明者】

【氏名】石井 久治

(72)【発明者】

【氏名】神谷 弘樹

(72)【発明者】

【氏名】馬越 健治

(72)【発明者】

【氏名】藤野 知之

(72)【発明者】

【氏名】齋藤 由唯

【審査官】原 秀人

(56)【参考文献】

【文献】特開２００２－１３２５５０（ＪＰ，Ａ）

【文献】山本 秀典，スマートシティ向けＩＴ基盤における異種システム連携機能，情報処理学会デジタルプラクティス，日本，一般社団法人情報処理学会，2014年07月15日，Ｖｏｌ．５ Ｎｏ．３，pp. 205--212

【文献】Aco，ビデオ編集の基礎知識，Ｉ／Ｏ ，日本，株式会社工学社，2003年03月01日，第２８巻 第３号，pp. 12--14

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １６／００－１６／９５８

(57)【特許請求の範囲】

【請求項1】

複数のモジュールに共通して対応するコモンデータモデルを示す情報を管理するコモンデータモデル管理部と、
前記複数のモジュールの少なくとも一つに対応する独自データモデルを示す情報を管理する独自データモデル管理部と、
前記コモンデータモデル管理部により管理されるコモンデータモデルに対応するモジュールのバージョン、前記独自データモデル管理部により管理される独自データモデルに対応するモジュールのバージョン、および新たに導入するデータモデルに対応するモジュールのバージョンをそれぞれ管理し、これらのバージョンの互換性を検証する共通管理部と、
を備えた情報処理装置。

【請求項2】

前記共通管理部は、
前記コモンデータモデル管理部により管理されるコモンデータモデルに対応するモジュールのバージョンが、前記新たに導入されるデータモデルに対応する同じ種別のモジュールのバージョンに対応しないときに、前記コモンデータモデル管理部により管理されるコモンデータモデルに対応するモジュールのバージョンを、前記新たに導入されるデータモデルに対応する同じ種別のモジュールのバージョンに対応するように更新する、
請求項１に記載の情報処理装置。

【請求項3】

前記コモンデータモデル管理部により管理される前記コモンデータモデルを示す情報、および前記独自データモデル管理部により管理される前記独自データモデルを示す情報は、
前記モジュールに対応するクラスを示し、新たなクラスの追加、又はクラス間の新たなリレーションの追加が許容される一方で既存のクラスの変更、削除、又はクラス間の既存のリレーションの変更、削除が許容されないように管理する情報を含む、
請求項１に記載の情報処理装置。

【請求項4】

前記モジュールは、アプリケーションプログラムを含み、
前記コモンデータモデル管理部により管理される前記コモンデータモデルを示す情報、および前記独自データモデル管理部により管理される前記独自データモデルを示す情報は、
前記モジュールに対応するクラスを示し、前記クラスを前記アプリケーションプログラムに対して公開するか非公開とするかを示す情報を含む、
請求項１に記載の情報処理装置。

【請求項5】

情報処理装置が行なう情報処理方法であって、
複数のモジュールに共通して対応するコモンデータモデルを示す情報を管理し、
前記複数のモジュールの少なくとも一つに対応する独自データモデルを示す情報を管理し、
前記管理されるコモンデータモデルに対応するモジュールのバージョン、前記管理される独自データモデルに対応するモジュールのバージョン、および新たに導入するデータモデルに対応するモジュールのバージョンをそれぞれ管理し、これらのバージョンの互換性を検証する、
情報処理方法。

【請求項6】

請求項１乃至４いずれか１項に記載の情報処理装置の前記各部としてプロセッサを機能させる情報処理プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明の実施形態は、情報処理装置、方法およびプログラムに関する。

【背景技術】

【0002】

近年、様々なセンサ（sensor）又は機器からデータ（data）を収集して蓄積し、多様なアプリケーションプログラム（Application Program）（以下、アプリケーション、又はアプリ）に提供するIoT(Internet of Things)システム（system）が注目されている。このようなIoTシステムでは、複数のアプリケーションが同一のプラットフォーム（platform）上で動作する。

【0003】

機器などから収集されて蓄積されたデータが単一のアプリケーションにより利用される従来のシステムでは、高い頻度でアプリケーションが必要とするデータの組み合わせ、および実行される処理が予め想定された上で、データモデル（data model）およびAPI（Application Programming Interface（アプリケーションプログラミングインタフェース））が設計される。このため、アプリケーションが利用し易い形でデータが蓄積される。
これにより、アプリケーションの実装が容易であったり、性能が最適化されたりするなどの利点が得られる。

【0004】

これに対し、１つのシステムに蓄積されたデータが複数のアプリケーションにより利用される、近年のプラットフォームでは、実行される処理の内容およびデータ構造がアプリケーションごとに異なる。このため、複数のアプリケーションにより共通して利用可能であるデータモデルおよびAPIが設計される試みが行われてきた（例えば非特許文献１を参照）。

【0005】

しかし、複数のアプリケーションに共通するデータモデルおよびAPIが設計されると、どのようなアプリケーションでも使われる可能性が高い情報である、基本的な情報（時刻、機器ID（identification）など）のみによりデータが構造化された共通データモデルが設計される場合が多い。

【0006】

このような共通データモデルが利用される際には、各アプリケーションが共通のAPIを用いてデータを取得した後に、いくつかの処理を組み合わせて目的のデータを得なければならないなどの為に、アプリケーションの実装が複雑になる場合、および処理時間が長くなる場合があった。

【先行技術文献】

【非特許文献】

【0007】

【文献】山本晋太郎（Shintaro YAMAMOTO）, 松本真佑（Shinsuke MATSUMOTO）, and 中村匡秀（Masahide NAKAMURA）. "スマートシティにおける大規模住宅ログ活用プラットフォームのための API 実装.（Implementing API of Large-scale House Log Data Platform in Smart City）" 電子情報通信学会（The institute of electronics, information and communication engineers）技術研究報告: 信学技報（Technical report of IEICE） 112.305 (2012): 27-32.

【発明の概要】

【発明が解決しようとする課題】

【0008】

複数のデータモデルの共存、およびデータモデルの更新を許容するには、各データモデルから生成される情報を管理し、システム全体で整合性を維持する仕組みが必要であるが、このような仕組みが実現される為には様々な課題がある。

【0009】

第１の課題として、データモデル変更に伴なう、各種モジュール（module）、例えばアプリケーション、コンバータ（converter）、接続機器、内部モジュールに係る設定管理の難しさが挙げられる。コンバータは、各機器により生成されたデータを変換して受け渡す。

【0010】

一例として、新たな機能を有するアプリケーションに対応する独自データモデルがシステムに導入される場合を説明する。
アプリケーションの機能追加が実現されるために、独自データモデルは、従来のデータモデルに対し、このデータモデルに含まれていない、モジュールに対応する新たなクラス（class）定義等が追加されたモデルである。
システムに接続されている機器が生成するデータを新たなアプリケーションが利用する為には、機器により生成されるデータが、独自データモデルに追加されたクラスに応じた形でデータ蓄積部に渡される必要がある。

【0011】

そのため、コンバータに対して、独自データモデルに対応した設定情報が送られて、設定変更が行なわれる必要がある。
また、複数のデータモデルから各モジュールに送られる設定情報に矛盾が無いか否かが検証される仕組みも必要である。

【0012】

第２の課題として、データモデル定義の追加、更新による互換性への影響が挙げられる。
一例として、データモデルの更新時に、従来のデータモデルで使用されていたクラスが削除された場合、このクラスを利用していたアプリケーションの動作に不具合が発生する。
このような問題を防ぐため、従来のデータモデルと独自データモデルとの間の互換性が壊れないように、この独自データモデルの定義が行なわれる必要がある。

【0013】

第３の課題として、独自データモデルにより収集されたデータを、どのアプリケーションが利用できるかが管理される必要がある。
複数のアプリケーションが含まれるIoTシステムでは、特定のアプリケーションのみに一部データの利用を許可したいというニーズ（needs）がある。

【0014】

この発明は、上記事情に着目してなされたもので、その目的とするところは、モジュールの導入を容易とし、データモデルに基づく処理を最適化することができるようにした情報処理装置、方法およびプログラムを提供することにある。

【課題を解決するための手段】

【0015】

上記目的を達成するために、この発明の一実施形態に係る情報処理装置の一つの態様は、情報処理装置が、複数のモジュールに共通して対応するコモンデータモデルを示す情報を管理するコモンデータモデル管理部と、前記複数のモジュールの少なくとも一つに対応する独自データモデルを示す情報を管理する独自データモデル管理部と、前記コモンデータモデル管理部により管理されるコモンデータモデルに対応するモジュールのバージョン、前記独自データモデル管理部により管理される独自データモデルに対応するモジュールのバージョン、および新たに導入するデータモデルに対応するモジュールのバージョンをそれぞれ管理し、これらのバージョンの互換性を検証する共通管理部とを備えるようにしたものである。

【0016】

本発明の一実施形態に係る、情報処理装置が行なう情報処理方法の一つの態様は、複数のモジュールに共通して対応するコモンデータモデルを示す情報を管理し、前記複数のモジュールの少なくとも一つに対応する独自データモデルを示す情報を管理し、前記管理されるコモンデータモデルに対応するモジュールのバージョン、前記管理される独自データモデルに対応するモジュールのバージョン、および新たに導入するデータモデルに対応するモジュールのバージョンをそれぞれ管理し、これらのバージョンの互換性を検証するようにしたものである。

【発明の効果】

【0017】

本発明によれば、モジュールの導入を容易とし、データモデルに基づく処理を最適化することが可能になる。

【図面の簡単な説明】

【0018】

【図1】図１は、本発明の一実施形態に係るデータ処理装置の適用例を示す図である。

【図2】図２は、独自データモデル定義ファイル（file）の一例を表形式で示す図である。

【図3】図３は、データモデル－モジュールバージョン（version）対応情報の一例を表形式で示す図である。

【図4A】図４Ａは、機器構成情報の一例を説明する図である。

【図4B】図４Ｂは、機器構成情報の一例を説明する図である。

【図5】図５は、独自データモデルに対応するAPIの一例を説明する図である。

【図6A】図６Ａは、アプリケーション追加又は更新時の処理手順の一例を示すフローチャートである。

【図6B】図６Ｂは、アプリケーション追加又は更新時の処理手順の一例を示すフローチャートである。

【図7A】図７Ａは、互換性の検証の処理手順の一例を示すフローチャート（flow chart）である。

【図7B】図７Ｂは、互換性の検証の処理手順の一例を示すフローチャートである。

【図8】図８は、機器コンバータの設定の処理手順の一例を示すフローチャートである。

【図9】図９は、データ蓄積時の処理手順の一例を示すフローチャートである。

【図10】図１０は、アプリケーションからのデータ参照時の処理動作の一例を示すフローチャートである。

【図11】図１１は、データモデル定義ファイルに基づくアクセス制御（access control）の処理動作の一例を示すフローチャートである。

【図12】図１２は、本発明の一実施形態に係るデータ処理装置のハードウエア（hardware）構成の一例を示すブロック図である。

【発明を実施するための形態】

【0019】

以下、図面を参照しながら、この発明に係わる一実施形態を説明する。
本発明の一実施形態では、以下の（１）～（１０）のうちの一部又は複数が組み合わせられることにより、複数のモジュールに共通して対応するコモンデータモデル（common data model）と、複数のモジュールの少なくとも一つに対応する独自データモデルとが共存するシステムと、柔軟なデータモデル管理とが実現される。

【0020】

（１） １つ又は複数のデータモデルの定義ファイルが規定され、１つ以上のアプリケーション、機器又は機器により生成されるデータを変換するコンバータと接続されたシステムに、データモデル定義ファイルが以下の（１－１）,（１－２）に従ってインストール（installation）される。

【0021】

（１－１） 接続される機器又はインストールされるアプリケーションに関わらず、共通のコモンデータモデル定義ファイルがシステムにインストールされる。
（１－２） （１－１）で説明されたコモンデータモデル定義ファイルに加えて、システムに接続される機器又はインストールされるアプリケーションに対応する独自データモデル定義ファイルが存在すれば、システムにインストールされる。

【0022】

（２） （１）でインストールされたデータモデル定義ファイルと、既存として使用されていたデータモデル定義ファイルとの互換性が検証される。
（３） システムに接続されたアプリケーション、機器、コンバータ、内部モジュールなどに対応するデータモデルのバージョンが管理され、（１）でインストールされたデータモデルのバージョンとモジュールとの対応関係がシステムに登録される。

【0023】

（４） （１）でインストールされたデータモデル定義ファイルに基づいて機器識別IDが生成され、１つ又はそれ以上のモジュールの設定テンプレート（template）が取得され、この取得された設定テンプレートを用いてモジュールが設定される。
この取得された設定テンプレートが検証されてもよい。また、モジュールは機器のコンバータでもよい。

【0024】

（５） （１）のデータモデル定義ファイルは、以下の（５－１）～（５－５）で示されルール（rule）に従って定義される。
（５－１） 新たなモジュールに対応するクラスの追加は可能であるが、既存のモジュールに対応するクラスの変更又は削除は不可である。
（５－２） クラス間の新たなリレーション（relation）の追加は可能であるが、クラス間の既存のリレーションの変更又は削除は不可である。

【0025】

（５－３） 既存クラスのアトリビュート(attribute)の追加、変更、又は削除は不可である。
（５－４） クラス間のリレーションの定義において、始点であるクラスと終点であるクラスとがそれぞれ決定され、リレーションの方向が定められる。
（５－５） あるクラスから１つ以上のリレーションが辿られることで始点のクラスに戻り、処理がループ（loop）するようなリレーションの定義が禁止される。

【0026】

（６） （１）で示されたデータモデル定義ファイルは、以下の（６－１）,（６－２）で示されるルールに従って定義される。
（６－１） クラス名の上位に、ベンダ（vendor）を識別する情報、およびデータモデルを識別する情報が付与される。
（６－２） 機器識別IDの上位に、ベンダを識別する情報、およびデータモデルを識別する情報が付与される。

【0027】

（７） （１－１）で示されたコモンデータモデル定義ファイルと、（１－２）で示された独自データモデル定義ファイルとのリレーションは、以下の（７－１）～（７－４）で示されるルールに従って定義される。
（７－１） 機器の基本的な構成情報を表すクラス、ならびにコンバータとの通信状態などの基本的なステータス（status）を表すクラスは共通クラスと称される。共通クラスはコモンデータモデルならびに独自データモデルにおいて必須である。

【0028】

（７－２） 独自データモデルは、コモンデータモデルにおける共通クラスと組み合わせて利用される。独自データモデルにおいて、共通クラスの下位に独自クラスが定義されてもよい。
（７－３） コモンデータモデルから独自データモデルへのリレーションが定義されてもよい。
（７－４） 共通クラスの情報は、アクセス制御、Remote Procedure Call、管理システム、可視化アプリケーションなどで用いられてもよい。

【0029】

（８） （１）で説明されたデータモデル定義ファイルに対応するAPIは、以下の（８－１）,（８－２）で示されるルールに従って定義される。
（８－１） APIのエンドポイント（end point）のクラス名の上位に、ベンダを識別する情報、およびデータモデルを識別する情報が付与される。
（８－２） 機器又は機器のコンバータに対するAPIのエンドポイントの機器識別IDの上位に、ベンダを識別する情報、およびデータモデルを識別する情報が付与される。

【0030】

（９） （１）のデータモデル定義ファイルは、以下の（９－１）で示されるルールに従って定義される。
（９－１） アプリケーションに対して各クラスが公開されること、又は一定の条件を満たすアプリケーションに対して各クラスが非公開とされることがデータモデル定義ファイルで定義される。

【0031】

この一定の条件とは、（１）上記のデータモデル定義ファイルのバージョンに対応しないアプリケーションである、又は（２）データモデル定義ファイルが定義された開発者以外により開発されたアプリケーションである、等の条件が挙げられる。

【0032】

（１０） （９－１）で非公開であると定義されたクラスは、（９－１）で説明された一定の条件を満たすアプリケーションからのアクセスが行われないようにアクセス制限を行なう。
また、（９－１）で公開であると定義されたクラスは、対応するデータモデルのバージョンに依らずに、全てのアプリケーションからアクセス可能である。

【0033】

本発明の一実施形態では、共通データモデルだけではなく、必要に応じてアプリケーション独自のデータモデルが導入されることで、様々な種類のアプリケーションの実装が容易であり、アプリケーションの処理を最適化することが可能である。

【0034】

本発明の一実施形態では、複数のモジュール、例えばアプリケーションおよびコンバータが接続されるシステムにおいて、各データモデルとモジュールとの間の対応関係を管理し、互換性の検証を行ない、データモデルから生成される情報を各モジュールに設定し、独自データモデルを導入することが可能である。

【0035】

また、データモデルの互換性が維持される為に、本発明の一実施形態では、データモデルが定義される際に守られるべきルールが設定される。
さらに、本ルールに従って定義されたデータモデルに対応するAPIのエンドポイントを生成するモデルである、独自データモデルが導入された場合に、アプリケーションごとにデータへのアクセスが管理される。

【0036】

図１は、本発明の一実施形態に係るデータ処理装置の適用例を示す図である。
図１に示されるように、本発明の一実施形態に係るデータ処理装置（情報処理装置）１０は、共通管理部１１、コモンデータモデル管理部１２、独自データモデル管理部１３、コンバータ設定部１４、アクセス制御部１５、およびコンバータ１６ａ,１６ｂを有する。
コンバータ１６ａ,１６ｂは、外部のデバイス（device）A, Bと１対１で接続される。図１に示されるデータ処理装置１０の機能は、プログラムを実行するＣＰＵ（Central Processing Unit）等のプロセッサ（processor）、およびＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の記憶媒体が用いられることで実現される。

【0037】

共通管理部１１は、データモデル－モジュールバージョン対応情報を内部メモリに記憶する。
コモンデータモデル管理部１２は、コモンデータ蓄積部１２ａを有する。コモンデータモデル管理部１２は、データの公開、非公開を定義するコモンデータモデル定義ファイルを内部メモリに記憶する。
独自データモデル管理部１３は、独自データ蓄積部１３ａを有する。独自データモデル管理部１３は、データの公開、非公開を定義する独自データモデル定義ファイルを内部メモリに記憶する。

【0038】

データ処理装置１０は、デバイスA, Bから入力したデータをコモンデータ蓄積部１２ａ又は独自データ蓄積部１３ａに蓄積する。データ処理装置１０は、コモンデータモデル定義ファイル又は独自データモデル定義ファイルに定義されたアクセス制御情報に基づいて、アプリケーションA、アプリケーションB、アプリケーションC、又はアプリケーションDに提供する。

【0039】

図２は、独自データモデル定義ファイルの一例を表形式で示す図である。
図２に示されるように、独自データモデル管理部１３で管理される独自データモデル定義ファイルでは、クラス名、データ型、および公開・非公開のフラグ（flag）が対応付けて管理される。
図２に示された例では、クラス名「ClassA」、データ型「string」に対応するフラグは「１」（公開）であり、クラス名「ClassB」、データ型「String」に対応するフラグは「０」（非公開）であることが示される。

【0040】

図３は、データモデル－モジュールバージョン対応情報の一例を表形式で示す図である。
図３に示されるように、共通管理部１１で管理されるデータモデル－モジュールバージョン対応情報では、データモデルバージョン、対応アプリケーションバージョンおよび対応コンバータバージョンが対応付けて管理される。

【0041】

図３に示された例では、コモンデータモデル（CommonDatamodel）のバージョン「ver1」において、対応するアプリケーションA（AppA）のバージョンは「ver1」であり、アプリケーションB（AppB）のバージョンは「ver1-2」であり、アプリケーションC（AppC）のバージョンは「ver1-2」であり、対応するデバイスA（DeviceA）のバージョンは「ver1」であり、対応するデバイスB（DeviceB）のバージョンは「ver1-2」であることが示される。

【0042】

また、図３に示された例では、新たな独自データモデル（NewDatamodel）のバージョンは「ver1」であり、対応するアプリケーションB（AppB）のバージョンは「ver2」であり、対応するアプリケーションC（「AppC」のバージョンは「ver2」であり、対応するアプリケーションD（AppD）のバージョンは「ver1」であり、対応するデバイスB（DeviceB）のバージョンは「ver2」であることが示される。

【0043】

図４Ａおよび図４Ｂは、機器構成情報の一例を説明する図である。
図４Ａおよび図４Ｂに示された例では、データ処理装置１０で管理される機器構成情報は、モジュールに対応するクラス定義と、機器構成情報（インスタンス（instance））とを含む。
クラス定義は、コモンデータモデル（コモンデータモデルのクラス）および独自データモデル（独自データモデルのクラス）を含む。機器構成情報（インスタンス）は、コモンデータモデル（コモンデータモデルのインスタンス）および独自データモデル（独自データモデルのインスタンス）を含む。

【0044】

図４Ａに示された例では、コモンデータモデルのクラスは「device」、「device path」、「part」および「motor」である。この例では、「device」と下位の「device path」との間で1:1のリレーションが設定され、「device path」と下位の「part」との間で1:nのリレーションが設定され、「part」と下位の「motor」との間で1:1のリレーションが設定される。

【0045】

図４Ａに示された例では、独自データモデルのクラスは、下記の（１）、（２）である。
（１）「xxx.sample.com.my_datamodel.original_path」
（２）「xxx.sample.original_part」
図４Ａに示された例では、コモンデータモデルのクラス「device」と、独自データモデルのクラス「xxx.sample.com.my_datamodel.original_path」との間で1:nのリレーションが設定され、独自データモデルのクラス「xxx.sample.com.my_datamodel.original_path」と下位の「xxx.sample. original_part」との間で1:nのリレーションが設定される。

【0046】

また、図４Ｂに示された例では、コモンデータモデルのインスタンスは、「device01」、「devicepath01」、「part01」、「motor01」、「part02」および「motor02」である。
図４Ｂに示された例では、「device01」と下位の「devicepath01」との間にリレーションが設定され、この「devicepath01」と下位の「part01」の間および「devicepath01」と下位の「part02」との間にリレーションがそれぞれ設定される。
図４Ｂに示された例では、「part01」と下位の「motor01」との間にリレーションが設定され、「part02」と下位の「motor02」との間にリレーションが設定される。

【0047】

図４Ｂに示された例では、独自データモデルのインスタンスは、下記の（１）～（５）である。
（１）「xxx.sample.com.my_datamodel.original_path01」
（２）「xxx.sample.com.my_datamodel.original_path02」
（３）「xxx.sample.original_part01」
（４）「xxx.sample.original_part02」
（５）「xxx.sample.original_part03」

【0048】

図４Ｂに示された例では、コモンデータモデルのインスタンス「device01」と、独自データモデルのインスタンス「xxx.sample.original_part01」との間にリレーションが設定される。また、この例では、コモンデータモデルのインスタンス「device01」と、独自データモデルのインスタンス「xxx.sample.original_part02」との間にリレーションが設定される。

【0049】

図４Ｂに示された例では、「xxx.sample.com.my_datamodel.original_path01」と下位の「xxx.sample.original_part01」との間、および「xxx.sample.com.my_datamodel.original_path01」と下位の「xxx.sample.original_part02」にリレーションがそれぞれ設定される。

【0050】

図４Ｂに示された例では、「xxx.sample.com.my_datamodel.original_path02」と下位のxxx.sample.original_part02」との間にリレーションが設定され、「xxx.sample.com.my_datamodel.original_path02」と下位のxxx.sample.original_part03」との間にリレーションが設定される。

【0051】

図５は、独自データモデルに対応するAPIの一例を説明する図である。
図５に示された例では、独自データモデルのアプリケーション向けAPIでは、「/API名/APIバージョン/class/｛ベンダ名｝｛データモデル名｝｛クラス名｝/instance/｛機器識別ID｝/…」が定義される。

【0052】

また、図５に示された例では、独自データモデルの機器向けAPIでは、「/API名/class/｛ベンダ名｝｛データモデル名｝｛クラス名｝/instance/｛ベンダ名｝｛データモデル名｝｛機器識別ID｝/moment/｛タイムスタンプ（time stamp）｝」が定義される。

【0053】

図６Ａおよび図６Ｂは、アプリケーション追加又は更新時の処理手順の一例を示すフローチャートである。
まず、データ処理装置１０は、新しいアプリケーションを追加する要求又はアプリケーションのバージョンを更新する要求を受け取る（Ｓ１１）。
共通管理部１１は、データモデル-モジュールバージョン対応情報を更新または参照し、新しく追加又はバージョンアップ（upgrade）されるアプリケーションに対応するデータモデルについて、所定の手順に従って対応モジュールを調べ、互換性を確認する（Ｓ１２）。Ｓ１２の詳細については後述する。

【0054】

次に、データ処理装置１０は、追加又は更新されるアプリケーションに対応するデータモデルが、データ処理装置１０に既にインストールされているデータモデルに含まれるか否かを判断する（Ｓ１３）。該当のデータモデルが含まれていなければ、（Ｓ１３のＮｏ）、データ処理装置１０は、追加又は更新されるアプリケーションに対応するデータモデルをインストールする（Ｓ１４）。

【0055】

Ｓ１４の後、又はＳ１３で「Ｙｅｓ」のときは、データ処理装置１０は、追加又は更新されるアプリケーションに対応するコンバータが、データ処理装置に既にインストールされているデータモデルに含まれるか否かを判断する（Ｓ１５）。該当のコンバータが含まれていなければ（Ｓ１５のＮｏ）、データ処理装置１０は、追加又は更新されるアプリケーションに対応するコンバータをインストールする（Ｓ１６）。
Ｓ１６の後、又はＳ１５で「Ｙｅｓ」のときは、データ処理装置１０は、所定の手順に従ってコンバータを設定する（Ｓ１７）。Ｓ１７の詳細については後述する。

【0056】

次に、Ｓ１２の詳細について説明する。図７Ａおよび図７Ｂは、互換性の検証の処理手順の一例を示すフローチャートである。
まず、共通管理部１１は、新たに導入されるデータモデルに対応するアプリケーションおよびコンバータについて、データモデル-モジュールバージョン対応情報を更新する（Ｓ１２ａ）。

【0057】

共通管理部１１は、システムに導入されているデータモデルに対応する各アプリケーションおよびコンバータのバージョンを、データモデル-モジュールバージョン対応情報から取得する（Ｓ１２ｂ）。

【0058】

共通管理部１１は、Ｓ１２ｂで取得した、各アプリケーション又はコンバータのバージョンが、新たに導入されるデータモデルに対応する各アプリケーション又はコンバータのバージョンに対応しているか否かを判断する（Ｓ１２ｃ）。
該当のバージョンが対応していなければ（Ｓ１２ｃのＮｏ）、共通管理部１１は、新たに導入されるデータモデルに対応する各アプリケーション又はコンバータのバージョンを有するアプリケーション又はコンバータを入手可能か否かを判断する（Ｓ１２ｄ）。

【0059】

該当のアプリケーション又はコンバータを入手可能であれば（Ｓ１２ｄのＹｅｓ）、共通管理部１１は、新たに導入されるデータモデルに対応する各アプリケーション又はコンバータのバージョンを内部メモリに記憶する（Ｓ１２ｅ）。

【0060】

Ｓ１２ｅの後、又はＳ１２ｃで「Ｙｅｓ」のときは、次のアプリケーション又はコンバータが存在すれば（Ｓ１２ｆのＹｅｓ）、次のアプリケーション又はコンバータについてＳ１２ｃ以降の処理が再度行なわれる。

【0061】

次のアプリケーション又はコンバータが存在しなければ（Ｓ１２ｆのＮｏ）、共通管理部１１は、システムに導入されている全てのアプリケーション・コンバータのバージョンが、新たに導入されるデータモデルに対応する各アプリケーション又はコンバータのバージョンに対応していたか否かを判断する（Ｓ１２ｇ）。
該当のバージョンが対応していないとき（Ｓ１２ｇのＮｏ）、又はＳ１２ｄで「Ｎｏ」のときは、共通管理部１１は、新たに導入されるデータモデルに対し、既存のデータモデルに対応するモジュールとの互換性を有しないモジュールが含まれることを示すエラーを返す。
ここで、共通管理部１１は、新たに導入されるデータモデルに対応するアプリケーション又はコンバータのバージョンを有するアプリケーション又はコンバータを入手可能であれば、この入手可能であることを図示しない表示装置に表示する（Ｓ１２ｉ）。

【0062】

Ｓ１２ｇで「Ｙｅｓ」のときは、共通管理部１１は、新たに導入されるデータモデルに対応するアプリケーション・コンバータのバージョンが、既存のデータモデルに対応するアプリケーション・コンバータのバージョンとの互換性を有することを示す情報を出力する（Ｓ１２ｈ）。Ｓ１２ｉ又はＳ１２ｈの処理がなされると、共通管理部１１は、Ｓ１２の処理を終了する。

【0063】

次に、Ｓ１７の詳細について説明する。図８は、機器コンバータの設定の処理手順の一例を示すフローチャートである。
まず、共通管理部１１は、データモデル定義ファイルを更新する（Ｓ１７ａ）。
共通管理部１１は、データモデル-モジュールバージョン対応情報を参照し、この情報から、システムに含まれる当該データモデルに対応するコンバータを示す情報を取得する（Ｓ１７ｂ）。
共通管理部１１は、API経由で機器構成情報をコンバータ設定部１４に送る（Ｓ１７ｃ）。
共通管理部１１は、当該データモデルに対応するコンバータを設定する（Ｓ１７ｄ）。

【0064】

共通管理部１１は、システムに含まれるデータモデルに対応する全てのコンバータの設定が終了したか否かを判断し（Ｓ１７ｅ）、終了していなければ（Ｓ１７ｅのＮｏ）、次のコンバータについてＳ１７ｃ以降の処理を再度行なう。
Ｓ１７ｅで「Ｙｅｓ」のときは、共通管理部１１は、コンバータの設定を終了し（Ｓ１７ｆ）、Ｓ１７の処理を終了する。

【0065】

図９は、データ蓄積時の処理手順の一例を示すフローチャートである。
まず、デバイスから送信されたデータを、送信元デバイスに対応するコンバータが受け取る（Ｓ２１）。
コンバータは、コモンデータモデルに従ってデータを変換し、変換後のデータをコモンデータ蓄積部１２ａに送る（Ｓ２２）。

【0066】

共通管理部１１は、データモデル-モジュールバージョン対応情報で、コンバータが、コモンデータモデル以外のデータモデルに対応しているか否かを判断する（Ｓ２３）。
該当のコンバータが対応していれば（Ｓ２３のＹｅｓ）、このコンバータは、対応する独自データモデルに従ってデータを変換し、変換後のデータを独自データ蓄積部１３ａに送る（Ｓ２４）。

【0067】

Ｓ２４の後、又はＳ２３で「Ｎｏ」のときは、共通管理部１１は、コンバータに対応する全てのデータモデルに従ってデータの変換とデータ蓄積部への送信が行なわれか否かを判断する（Ｓ２５）。
該当の変換と送信が行なわれていなければ（Ｓ２５のＮｏ）、共通管理部１１は、次のデータモデルについてＳ２４の処理を再度行なう。Ｓ２５で「Ｙｅｓ」のときは、共通管理部１１は、データ蓄積に係る処理を終了する。

【0068】

図１０は、アプリケーションからのデータ参照時の処理動作の一例を示すフローチャートである。
まず、アプリケーションは、データモデル毎に異なるAPIを指定して、コモンデータモデル管理部１２にデータの参照を要求する（Ｓ３１）。

【0069】

コモンデータモデル管理部１２は、アプリケーションにより指定されたAPIがコモンデータモデルのAPIであるか否かを判断する（Ｓ３２）。
該当のAPIがコモンデータモデルのAPIであれば（Ｓ３２のＹｅｓ）、コモンデータモデル管理部１２は、アプリにより指定されたデータをコモンデータ蓄積部１２ａから取得してアプリに送る（Ｓ３３）。

【0070】

Ｓ３３の後、又はＳ３２で「Ｎｏ」のときは、独自データモデル管理部１３は、アプリケーションにより指定したAPIが独自データモデルのAPIであるか否かを判断する（Ｓ３４）。
Ｓ３４で「Ｙｅｓ」のときは、独自データモデル管理部１３は、アプリにより指定されたデータを独自データ蓄積部１３ａから取得してアプリに送る（Ｓ３５）。

【0071】

Ｓ３４で「Ｎｏ」のときは、独自データモデル管理部１３は、アプリケーションにエラーを返す（Ｓ３６）。Ｓ３５又はＳ３５の処理がなされると、共通管理部１１は、データ参照時の処理動作を終了する。
また、アクセス制御が行なわれる場合は、Ｓ３３,Ｓ３５において、当該ステップ（step）での処理の代わりに、データモデル定義ファイルに基づくアクセス制御が行なわれる。

【0072】

データモデル定義ファイルに基づくアクセス制御の詳細について説明する。
図１１は、データモデル定義ファイルに基づくアクセス制御の処理動作の一例を示すフローチャートである。
まず、アクセス制御部１５は、アプリケーションからデータの参照要求を受け取る（Ｓ４１）。
アクセス制御部１５は、要求されたクラスのデータモデル定義ファイルを参照する（Ｓ４２）。

【0073】

アクセス制御部１５は、データモデル定義ファイルで当該要求されたクラスが公開クラスであるか否かを判断する（Ｓ４３）。該当のクラスが公開クラスであれば（Ｓ４３のＹｅｓ）、アクセス制御部１５は、当該クラスのデータを取得し、要求元アプリケーションに渡す（Ｓ４５）。

【0074】

一方、データモデル定義ファイルで当該要求されたクラスが非公開クラスである場合（Ｓ４３のＮｏ）、アクセス制御部１５は、アクセス元アプリケーションが当該クラスへのアクセス権を有するアプリであるか否かを判断し（Ｓ４４）、アクセス権を有するアプリであれば（Ｓ４４のＹｅｓ）、Ｓ４５の処理がなされる。

【0075】

一方、アクセス権が有するアプリでなければ（Ｓ４４のＮｏ）、アクセス制御部１５は、要求元アプリケーションに対して、当該クラスへのアクセス権を有しないことを示すエラーを返す（Ｓ４６）。Ｓ４５又はＳ４６の処理がなされると、アクセス制御部１５は、データ参照時の処理動作を終了する。

【0076】

次に、アプリケーションの追加又は更新時の処理の具体例を説明する(図１～３、図６Ａ～図８参照)。
ここでは、アプリケーションA,B,Cと、デバイスA用のコンバータ（ver. 1）と、デバイスB用のコンバータ（ver. 1）と、コモンデータモデル（ver. 1）とを含むシステムに新たなアプリケーションD（ver. 1）が追加される例について説明する。

【0077】

データ処理装置１０は、新たなアプリケーションD（ver. 1）をシステムに追加する要求をユーザから受け取る。
共通管理部１１は、データモデル-モジュールバージョン対応情報を更新し、新たなアプリケーションD（ver. 1）に対応するデータモデルを調べる。

【0078】

共通管理部１１は、新たなアプリケーションD（ver. 1）に対応する独自データモデルNewDatamodel（ver. 1）におけるアプリケーションのバージョンとコンバータのバージョンとを調べる。

【0079】

共通管理部１１は、データモデル-モジュールバージョン対応情報を参照して、システムに含まれるアプリケーションA,B,CのバージョンとデバイスA用のコンバータ、デバイスB用のコンバータのバージョンとをそれぞれ確認する。共通管理部１１は、これらのバージョンがNewDatamodel（ver. 1）におけるアプリケーションのバージョンとコンバータのバージョンに対応するか否かを調べる。

【0080】

共通管理部１１は、NewDatamodel（ver. 1）に対応しないモジュールであるアプリケーション又はコンバータがある場合はユーザに通知する。共通管理部１１は、システムに含まれるアプリケーションA,B,CのバージョンとデバイスA用のコンバータ、デバイスB用のコンバータのバージョンを、NewDatamodel（ver. 1）における対応するバージョンへ更新する等の処理を行なう。

【0081】

共通管理部１１は、システムに含まれる全てのモジュールのバージョンが、導入されるモジュールのバージョンに対応する場合は、NewDatamodel（ver. 1）をシステムに追加し、アプリケーションが利用する機器種別等に応じて必要なコンバータを追加または更新する。

【0082】

一例として、アプリケーションD（ver. 1）がデバイスB用のコンバータ（ver.2）を必要とする場合、共通管理部１１は、デバイスB用のコンバータ（ver. 1）をデバイスB用の新たなコンバータ（ver. 2）に更新する。

【0083】

データモデルが追加又は更新された場合、コモンデータモデル管理部１２および独自データモデル管理部１３は、データモデル定義ファイルに基づいて機器構成情報をコンバータ設定部１４に送る。この機器構成情報に基づいて、コンバータ設定部１４はコンバータの設定を変更する。

【0084】

この例では、NewDatamodel（ver. 1）のデータモデル定義ファイルに基づいて生成された機器構成情報を用いて、コンバータ設定部１４は、デバイスB用のコンバータ（ver. 2）の設定を変更する。

【0085】

これにより、デバイスBから収集されるデータをNewDatamodel（ver. 1）に従って蓄積および利用する新たなアプリケーションであるアプリケーションD（ver. 1）が利用可能となる。

【0086】

次に、デバイスにより生成されたデータが蓄積されるときの処理の具体例を説明する（図１～３,９参照）。
ここでは、デバイスBからデータが蓄積される例を説明する。
まず、デバイスBは、このデバイスBに対応する、デバイスB用のコンバータ（ver. 2）にデータを送る。

【0087】

デバイスB用のコンバータ（ver. 2）は、コモンデータモデル（ver. 1）に従ってデータを変換して、変換されたデータをコモンデータ蓄積部１２ａに送る。このデータはコモンデータ蓄積部１２ａに蓄積される。

【0088】

また、デバイスB用のコンバータ（ver. 2）は、NewDatamodel（ver. 1）に従ってデータを変換して、変換されたデータを独自データ蓄積部１３ａに送る。このデータは独自データ蓄積部１３ａ蓄積される。

【0089】

次に、アプリケーションにより蓄積されたデータが参照される処理の具体例を説明する（図１～３,１０,１１参照）。
ここでは、アプリケーションD（ver. 1）からデータが参照される例について説明する。

【0090】

まず、アプリケーションD（ver. 1）は、データモデル名「NewDatamodel ver1」を含むAPIを指定してデータの参照要求を行なう。
独自データモデル管理部１３は、独自データ蓄積部１３ａから指定されたデータを取得してアプリケーションD（ver. 1）に返す。
このとき、アプリケーションごとにデータへのアクセス制御が行なわれる場合は、アクセス制御部１５は、独自データモデル管理部１３が独自データモデル定義ファイルを参照することで要求されたクラスのデータが要求元アプリケーションに公開されているか否かを判断する。該当のデータが公開されていれば、アクセス制御部１５は、要求されたクラスのデータを要求元のアプリケーションに返却する。

【0091】

また、上記要求されたクラスのデータが要求元アプリケーションに対して非公開のクラスであれば、アクセス制御部１５は、要求元アプリケーションにデータを返さず、エラーを通知する。

【0092】

図１２は、本発明の一実施形態に係るデータ処理装置のハードウエア構成の一例を示すブロック図である。
図１２に示された例では、上記の実施形態に係るデータ処理装置１０は、例えばサーバコンピュータ（server computer）またはパーソナルコンピュータ（personal computer）により構成され、ＣＰＵ等のハードウエアプロセッサ（hardware processor）１１１Ａを有する。そして、このハードウエアプロセッサ１１１Ａに対し、プログラムメモリ（program memory）１１１Ｂ、データメモリ（data memory）１１２、入出力インタフェース１１３及び通信インタフェース１１４が、バス（bus）１２０を介して接続される。

【0093】

通信インタフェース１１４は、例えば１つ以上の無線の通信インタフェースユニットを含んでおり、通信ネットワークＮＷとの間で情報の送受信を可能にする。無線インタフェースとしては、例えば無線ＬＡＮ（Local Area Network）などの小電力無線データ通信規格が採用されたインタフェースが使用される。

【0094】

入出力インタフェース１１３には、データ処理装置１０に付設される、オペレータ（operator）用の入力デバイス３０および出力デバイス４０が接続される。
入出力インタフェース１１３は、キーボード、タッチパネル（touch panel）、タッチパッド（touchpad）、マウス（mouse）等の入力デバイス３０を通じてオペレータにより入力された操作データを取り込むとともに、出力データを液晶または有機ＥＬ（Electro Luminescence）等が用いられた表示デバイスを含む出力デバイス４０へ出力して表示させる処理を行なう。なお、入力デバイス３０および出力デバイス４０には、データ処理装置１０に内蔵されたデバイスが使用されてもよく、また、ネットワーク（network）ＮＷを介してデータ処理装置１０と通信可能である他の情報端末の入力デバイスおよび出力デバイスが使用されてもよい。

【0095】

プログラムメモリ１１１Ｂは、非一時的な有形の記憶媒体として、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）等の随時書込みおよび読出しが可能な不揮発性メモリ（non-volatile memory）と、ＲＯＭ（Read Only Memory）等の不揮発性メモリとが組み合わせて使用されたもので、一実施形態に係る各種制御処理を実行する為に必要なプログラムが格納されている。

【0096】

データメモリ１１２は、有形の記憶媒体として、例えば、上記の不揮発性メモリと、ＲＡＭ（Random Access Memory）等の揮発性メモリ（volatile memory）とが組み合わせて使用されたもので、各種処理が行なわれる過程で取得および作成された各種データが記憶される為に用いられる。

【0097】

本発明の一実施形態に係るデータ処理装置１０は、ソフトウエア（software）による処理機能部として、図１に示される共通管理部１１、コモンデータモデル管理部１２、独自データモデル管理部１３、コンバータ設定部１４、アクセス制御部１５、およびコンバータ１６ａ,１６ｂを有するデータ処理装置として構成され得る。

【0098】

コモンデータ蓄積部１２ａ、独自データ蓄積部１３ａ、および内部メモリは、図１２に示されたデータメモリ１１２が用いられることで構成され得る。ただし、これらのコモンデータ蓄積部１２ａ、独自データ蓄積部１３ａ、および内部メモリはデータ処理装置１０内に必須の構成ではなく、例えば、ＵＳＢ（Universal Serial Bus）メモリなどの外付け記憶媒体、又はクラウド（cloud）に配置されたデータベースサーバ（database server）等の記憶装置に設けられたものであってもよい。

【0099】

上記の共通管理部１１、コモンデータモデル管理部１２、独自データモデル管理部１３、コンバータ設定部１４、アクセス制御部１５、およびコンバータ１６ａ,１６ｂの各部における処理機能部は、いずれも、プログラムメモリ１１１Ｂに格納されたプログラムを上記ハードウエアプロセッサ１１１Ａにより読み出させて実行させることにより実現され得る。なお、これらの処理機能部の一部または全部は、特定用途向け集積回路（ＡＳＩＣ（Application Specific Integrated Circuit））またはＦＰＧＡ（Field-Programmable Gate Array）などの集積回路を含む、他の多様な形式によって実現されてもよい。

【0100】

次に、本発明の一実施形態における効果について説明する。
コモンデータモデルのみを有する従来のシステムでは、全てのアプリケーションに共通する基本的なデータモデルに従ってコモンデータが蓄積される。このため、一部のアプリに係る複雑なデータ処理等が、それぞれのアプリ内で行なわれる必要があった。

【0101】

例えば、複雑なデータ処理を行なうアプリは、まず、コモンデータモデルで規定される、時刻情報等の基本的なキー（key）を用いてコモンデータを取得する。アプリは、取得したデータをデータベースに蓄積し、この蓄積したデータを用いて統計処理および学習処理等の複雑なデータ処理を行なう。
このような場合、アプリ内での複数回のデータ蓄積処理および参照処理が必要となり、アプリでの処理に係る負担の増加および処理の遅延の増大が問題である。

【0102】

また、このような複雑なデータ処理を行なうアプリが増えた場合、複数のアプリ間で重複するデータがデータベースに保持される必要があるため、システム全体のデータベースの容量が圧迫される。

【0103】

これに対し、本発明の一実施形態では、アプリ、コンバータ等の各モジュールに対応するデータモデルの種類、バージョンが自動的に管理される。また、本発明の一実施形態では、データモデルが更新された場合に、各モジュールの設定に必要な構成情報が自動的に管理される。このため、コモンデータモデルに加えて複数の独自データモデルが適用され得る。

【0104】

これにより、複雑なデータ処理を行なうアプリは、データ処理に必要な形式で独自データモデルにデータを予め蓄積し、このデータを直接参照する。これにより、アプリでの処理に係る負担を小さくすることができる。よって、アプリの処理の最適化とデータベースのディスク（disk）容量の削減に向けて、柔軟なデータモデル管理技術を実現できる。

【0105】

また、本発明の一実施形態では、複数のアプリが共通して利用する独自データを独自データモデル管理部１３の独自データ蓄積部１３ａから共有可能である。このため、各アプリで重複するデータがデータベースで管理される必要がなく、データベースの容量が効率的に利用され得る。

【0106】

さらに、本発明の一実施形態では、独自データ蓄積部１３ａ蓄積される独自データモデル定義ファイルにおいて、クラス毎に定義されたデータの公開/非公開情報に基づいてアクセス制御を行なうことができる。このため、従来のコモンデータモデルが用いられた場合と同様に、アプリ毎に公開が許可されたクラスの独自データのみが共有されることが可能である。
IoTシステムでは、複数のアプリケーション及び機器が共通のシステムに接続され、さらにシステム構築後に新たなアプリケーション、機器が追加される。

【0107】

本発明の一実施形態では、独自データモデル定義ファイルが管理され、古いデータモデルとの互換性およびシステム全体の整合性が維持されたまま、データモデルが追加又は更新可能である。これにより、IoTシステムがリリースされた後に追加されるアプリケーションおよび機器への対応を柔軟に行なうことができる。

【0108】

本発明の一実施形態では、アプリケーションおよび機器ごとに必要であるデータモデルに差異があることに注目し、データモデル間の互換性が管理および検証され、データモデルに基づいて生成される情報の管理が集中的に行なわれる。これにより、データモデルの柔軟な管理が可能となる。

【0109】

この発明の一実施形態に係る情報処理装置の第１の態様によれば、コモンデータモデルに対応するモジュールのバージョンと、新たに導入されるデータモデルに対応するモジュールのバージョンとの互換性が検証される。これにより、コモンデータモデルに加えて、新たなデータモデルに対応する独自データモデルが適用され得る。

【0110】

この発明の一実施形態に係る情報処理装置の第２の態様によれば、コモンデータモデルに対応するモジュールのバージョンが、新たに導入するデータモデルに対応するモジュールのバージョンに対応するように更新される。これにより、新たに導入されるデータモデルに合わせて、コモンデータモデルに対応するモジュールのバージョンが適正化され得る。

【0111】

この発明の一実施形態に係る情報処理装置の第３の態様によれば、データモデルを示す情報は、新たなクラス又はクラス間の新たなリレーションの追加が許容される一方で、既存のクラス又はクラス間の既存のリレーションの変更または削除は許容されない。これにより、新たなデータモデルと既存のデータモデルとの互換性を保つことができ、既存のデータモデルを利用するアプリケーションプログラムの動作の不具合を防止できる。

【0112】

この発明の一実施形態に係る情報処理装置の第４の態様によれば、データモデルを示す情報には、モジュールに対応するクラスをアプリケーションプログラムに公開するか非公開とするかを示す情報が含まれる。これにより、特定のアプリケーションプログラムにのみにデータの利用が許可され得る。

【0113】

また、各実施形態に記載された手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク（Floppy disk）、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ（Flash memory）等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。

【0114】

なお、本願発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の発明が含まれており、開示される複数の構成要件から選択された組み合わせにより種々の発明が抽出され得る。

【符号の説明】

【0115】

１０…データ処理装置
１１…共通管理部
１２…コモンデータモデル管理部
１２ａ…コモンデータ蓄積部
１３…独自データモデル管理部
１３ａ…独自データ蓄積部
１４…コンバータ設定部
１５…アクセス制御部
１６ａ，１６ｂ…コンバータ

【図1】

【図2】

【図3】

【図4A】

【図4B】

【図5】

【図6A】

【図6B】

【図7A】

【図7B】

【図8】

【図9】

【図10】

【図11】

【図12】