JP7059916B2

JP7059916B2 - 情報処理システム、方法およびプログラム

Info

Publication number: JP7059916B2
Application number: JP2018236520A
Authority: JP
Inventors: 晶玉孫; 育生山崎; 翔子片山; 誓治大森
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2018-12-18
Filing date: 2018-12-18
Publication date: 2022-04-26
Anticipated expiration: 2038-12-18
Also published as: WO2020129995A1; US11843678B2; US20220078257A1; JP2020098483A

Description

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

IEEEの予測では、2025年までに約754億台のデバイスがインターネットに接続される見込みである。このデバイスの増大は、特殊な業界の中に留まらず、様々なIoT(Internet of Things)規格を有する複数の業界に影響を及ぼす可能性がある。この変化に適応するために、各規格に共通する優秀な共通IoTプラットフォーム(PF)を用意するだけでなく、既存規格との間の複雑なデータ交換を簡素化させることが要望されている。

一方、oneM2Mという水平統合型のIoTプラットフォーム標準仕様（標準化を進めるために開始されたパートナーシッププロジェクト）は、様々なIoT規格の乱立を防ぐために開発された。oneM2Mは、データ管理・デバイス管理などの通信方式に非依存な共通機能の集合体CSE（Common Service Entity）と、他規格のプロトコルとのデータマッピング・交換を担うIPE（Interworking Proxy Entity）、集まったデータを利活用するAE（Application Entity）から成る。oneM2Mでは、CSEに対し、アプリケーションプログラム（以下、アプリケーション又はアプリと称することがある）が、mcaと呼ばれるインタフェース（CSE-AE（Application Entity）間のインタフェース）を介して接続される（例えば、非特許文献１、２を参照）。

Nassim DENNOUNI, Ahmed LEHIRECHE、Towards a spatiotemporel model for the interworking of the GIS oneM2M Specification TS-0004 version 3.0.1

ここで、IoT相互連携の現状について説明する。IoTデータは、データを収集した事業者（データ提供者）ごとに極めてサイロ化されて管理され、事業者ごとに固有のIoT-PF毎のAPI（Application Programming Interface（アプリケーション・プログラミング・インタフェース））・データモデルが異なるのが現状である。

例えば、第１の事業者が提供する例えば気象データ、第２の事業者が提供する交通流量データ、および第３の事業者が提供するイベント開催データに基づいて、複合データ活用アプリにより高度渋滞予測サービスを円滑に提供するケースでは、気象データは、第１の事業者に固有のIoT-PF、API/データモデルを介して複合データ活用アプリに提供され、交通流量データは、第２の事業者に固有のIoT-PF、API/データモデルを介して複合データ活用アプリに提供され、イベント開催データは、第３の事業者に固有のIoT-PF、API/データモデルを介して複合データ活用アプリに提供される。
このようなケースでは、データ提供者ごとの全てのAPI・データモデルを個別に対応し続ける必要があり、継続的なデータ活用が困難である。

上記のように、IoTデータは、収集したIoT-PF事業者ごとに極めてサイロ化されて管理されるが、API/データモデル（データ構造・語彙も含めて）が各種PF間で統一される可能性は極めて低い。
また、エッジPFも複数の事業者により実現される可能性があり、クラウド・エッジでAPIが異なり、多様化し、アプリの可搬性が低下する。

ここで、IoTデータを活用する多様なアプリ創出の阻害要因について説明する。
複数種類のPFがそれぞれ保持するデータを活用するためには、各種アプリの提供者がPF毎/デバイス毎のAPI・データモデルを習得する必要があり、大きな負担となる。
このため、PFの種類が数十種類以上になると対応が極めて困難となる。また、あるデータを連携させることによる価値の有無を判断するためには、お試しとしてのデータ取得が必要だが、このお試しのためにも相当の負担がかかる。

上記の対策として、アプリ提供者がPF毎/デバイス毎に個別対応することなく、また、短期間かつ低コストに相互連携を可能にし、持続的なデータ活用の発展を促進する技術を確立する必要がある。

次に、Specific Interworking(IWK)によるIoT相互連携の課題について説明する。
異種規格間のデータ交換を行なう際に、データ表現の抽象化を行わず、データを一つずつ変換して交換フローを作成する、Specific IWKと呼ばれる手法がある。

例えば、IoT規格A, B, Cから共通PFへデータ変換させるSpecific IWKとしては、規格A_Deviceと共通PFとの間の変換プロキシは、規格依存I/O変換、規格Aに固有のData Mapping A、規格Aに固有のIWK Procedures Aを含め、技術B PFと共通PFとの間の変換プロキシに、規格依存I/O変換、規格Bに固有のData Mapping B、規格Bに固有のIWK Procedures Bを含め、規格C PFと共通PFとの間の変換プロキシに、規格依存I/O変換、規格Cに固有のData Mapping C、規格Cに固有のIWK Procedures Cを含めることが挙げられる。

次にSpecific IWKの課題について、以下のa.～c.にて説明する。
a. まず、開発コストの高騰が挙げられる。データを交換させるには、この規格のデータ構造とデバイスとの関係性、データと共通プラットフォームのリソースとの対応、及びマッピングフローなどの知識を網羅的に理解しておくことが必要である。
一定以上の規模になると、すべてのデータに対して知識を蓄えることとデータ交換フローを用意することは実質困難になる。
新しい規格との間でデータ交換を行ないたい際に、データマッピングとデータ交換のフローを新しく作らなければならず、開発コストがインタワーキングする規格の増加によって高騰する。

b. 個別に決められたデータマッピングによって、共通プラットフォームのデータ構造も多様になり、データ活用アプリがデータを取得する際にも個別なデータ構造を知らなければならない。
c. データ保管状態と場所のカスタマイズは、規格ごとに個別に行なう必要がある。

この発明は、上記事情に着目してなされたもので、その目的とするところは、データの規格毎に個別対応することなく、また、短期間かつ低コストに相互連携してデータ交換することができるようにした情報処理システム、方法およびプログラムを提供することにある。

上記目的を達成するために、この発明の一実施形態に係る情報処理システムの第１の態様は、複数種類の固有の規格に対応したデバイスと、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバとにそれぞれ接続される、変換プロキシを有する情報処理システムであって、前記変換プロキシは、前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する取得手段と、記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理するデバイス管理手段と、前記取得手段により取得されたオントロジーデータと前記デバイス管理手段により管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成し、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう共通交換手段とを備えるようにしたものである。

この発明の情報処理システムの第２の態様は、第１の態様において、前記共通プラットフォームサーバは、前記デバイスから取得したデータを保管するデータ保管部を有し、前記リソースは、前記データ保管部に前記デバイスから取得した最新のデータを格納することを規定する第１のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記第１のデータフィールドの規定に基づいて、前記デバイスから取得した最新のデータを前記データ保管部に保管するようにしたものである。

この発明の情報処理システムの第３の態様は、第１の態様において、前記共通プラットフォームサーバは、前記デバイスから取得したデータを保管するデータ保管部を有し、前記リソースは、前記データ保管部に前記デバイスから取得した時系列データを格納することを規定する第２のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記第２のデータフィールドの規定に基づいて、前記デバイスから取得した時系列データを前記データ保管部に保管するようにしたものである。

この発明の情報処理システムの第４の態様は、第１の態様において、前記リソースは、前記デバイスから取得した最新のデータを前記アプリケーションからの要求に応じて前記デバイスから取得することを規定する第３のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記アプリケーションからの要求に応じて、前記第３のデータフィールドの規定に基づいて、前記デバイスから取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送るようにしたものである。

この発明の情報処理システムの第５の態様は、第１の態様において、前記リソースは、前記デバイスに対応付けられた固有の保管部に保管された時系列データをアプリケーションからの要求に応じて一括して取得することを規定する第４のデータフィールドを有し、前記変換プロキシの前記共通交換手段は、前記アプリケーションからの要求に応じて、前記第４のデータフィールドの規定に基づいて、前記保管部から取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る、ようにしたものである。

本発明の一実施形態に係る情報処理方法の一つの態様は、複数種類の固有の規格に対応したデバイスと、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバとにそれぞれ接続される、変換プロキシを有する情報処理システムが行う情報処理方法であって、前記変換プロキシは、前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得し、前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理し、前記取得されたオントロジーデータと前記管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成して、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なうようにしたものである。

本発明の一実施形態に係る情報処理プログラムの一つの態様は、第１乃至第５の態様のいずれか１つにおける情報処理システムの前記各手段としてプロセッサを機能させるものである。

この発明の一実施形態に係る情報処理システムの第１の態様によれば、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータと、デバイス情報とに基づいて、規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとを関連付けたリソースが作成され、このリソースに基づいて共通プラットフォームサーバとの間でデータ交換が行われるので、規格ごとにコーディングする必要があった部分を共通化した上でデータ交換を行なうことができる。

この発明の一実施形態に係る情報処理システムの第２の態様によれば、リソースは、共通プラットフォームにデバイスから取得された最新のデータを格納することを規定したデータフィールドを有し、このデータフィールドの規定に応じて、デバイスから取得した最新のデータが共通プラットフォームのデータ保管部に保管されるので、規格ごとにコーディングする必要があった部分を共通化した上でデバイスから最新のデータを得ることができる。

この発明の一実施形態に係る情報処理システムの第３の態様によれば、リソースは、共通プラットフォームにデバイスからの時系列データを格納することを規定したデータフィールドを有し、このデータフィールドの規定に応じて、デバイスから取得した時系列データが共通プラットフォームのデータ保管部に保管されるので、規格ごとにコーディングする必要があった部分を共通化した上でデバイスからの時系列データを得ることができる。

この発明の一実施形態に係る情報処理システムの第４の態様によれば、リソースは、デバイスからの最新のデータをアプリケーションからの要求によってデバイスから取得することを規定するデータフィールドを有し、このデータフィールドの規定に応じて、デバイスから取得したデータがアプリケーションに送られるので、規格ごとにコーディングする必要があった部分を共通化した上でデバイスから最新のデータをアプリケーションに渡すことができる。

この発明の一実施形態に係る情報処理システムの第５の態様によれば、リソースは、デバイスに固有の保管部に保管された時系列データをアプリケーションからの要求によって一括して取得することを規定するデータフィールドを有し、アプリケーションからの要求によって、上記データフィールドの規格に応じて、上記保管部から取得したデータが共通プラットフォームサーバを介してアプリケーションに送られるので、規格ごとにコーディングする必要があった部分を共通化した上でデバイス側の時系列データをアプリケーションに渡すことができる。

すなわち、本発明の各態様によれば、収集するデータの規格毎に個別対応することなく、また、短期間かつ低コストに相互連携してデータ交換することが可能になる。

本発明の一実施形態に係る情報処理システムに適用されるOntology based IWKの一例を示す図。本発明の一実施形態に係る情報処理システムにOntology based IWKを適用したときの構成例を示す図。本発明の一実施形態に係る情報処理システムの構成例を示す図。本発明の一実施形態に係る情報処理システムに使用されるoneM2M base ontologyの一部の例を示す図。データ構造の抽象化の例を示す図。最新値のみの保存について説明する図。オントロジー拡張フィールドの一例を説明する図。変換プロキシ接続時のワークフローの一例を説明する図。変換プロキシ接続時のシーケンスの一例を説明する図。 InputDataPoint交換のワークフローの一例を示す図。 InputDataPoint交換のシーケンスの一例を示す図。 OutputDataPoint交換のワークフローの一例を示す図。 OutputDataPoint交換のシーケンスの一例を示す図。他規格とのデータ交換フローの共通化の一例を説明する図。時系列データの蓄積の一例について説明する図。オントロジー拡張フィールドの一例を説明する図。データ交換のワークフローの一例を示す図。データ交換のワークフローの一例を示す図。データ交換のシーケンスの一例を示す図。時系列データ蓄積の手順の一例を示す図。時系列データ蓄積の実施例を示す図。データ交換のワークフローの一例を示す図。データ交換のワークフローの一例を示す図。データ交換のシーケンスの一例を示す図。時系列データ蓄積の手順の一例を示す図。時系列データ蓄積の実施例を示す図。オンデマンド取得の一例について説明する図。オントロジー拡張フィールドの一例を説明する図。データ交換のワークフローの一例を示す図。データ交換のワークフローの一例を示す図。データ交換のシーケンスの一例を示す図。オンデマンド取得の手順の一例を示す図。オンデマンド取得の実施例を示す図。オンデマンド一括取得の一例について説明する図。オントロジー拡張フィールドの一例を説明する図。データ交換のワークフローの一例を示す図。データ交換のシーケンスの一例を示す図。オンデマンド一括取得の実施例を示す図。

以下、図面を参照しながら、この発明に係わる一実施形態を説明する。
本発明の一実施形態に係る情報処理システムでは、従来の、データごとに1対1で行っていたデータマッピングとデータ交換とを、オントロジー(Ontology)を用いて抽象化し、抽象化エンティティに対して処理を共通化する。これにより、抽象化された単位で処理が決まり、データマッピングとデータ交換フローの開発コストの削減とアプリによるデータ取得方式の統一を実現する。

これにより、データ流通基盤の運用者は、少ない開発コストで基盤設定を完了できる。データ活用アプリから見ると、共通PFにあるデータの構成が共通化されるため、データ活用アプリにとってデータ取得の仕方も一義に決められ、アプリの開発と修正も簡単になる。

また、本発明の一実施形態に係る情報処理システムでは、データ保管状態とデータ保管場所に対して、パターンを分けて、このパターンごとに処理フローを設計し、上記の抽象化された単位でデータ交換方式の切り替えを実現する。
これにより、データ保管が簡単な設定で最適化され、基盤のパフォーマンスを保てる。

次に、オントロジーを用いたIoT相互連携高度化について説明する。
本発明の一実施形態では、異種規格を跨ったデータ表現をオントロジーによって構造化し、高度に抽象化されたデータ表現に対する共通的なデータ交換フローを設計することによって、異種規格とoneM2Mとの間のデータ交換の処理を共通化させる。

図１は、本発明の一実施形態に係る情報処理システムに適用されるOntology based IWKの一例を示す図である。
図１に示した例では、IoT規格A, B, CからoneM2Mによる共通PFへデータ変換させるOntology based IWKとしては、規格A_Deviceと共通PFとの間の変換プロキシ、技術B PFと共通PFとの間の変換プロキシ、およびC PFと共通PFとの間の変換プロキシに、規格依存I/O変換に加え、共通のBase Ontology Derived Model Mapping、およびCommon IWK Proceduresを含める。

図２は、本発明の一実施形態に係る情報処理システムにOntology based IWKを適用したときの構成例を示す図である。
図２に示した例では、A社IoT-PFがA社IoT-PF対応のオントロジー作成GUI（グラフィカルユーザインタフェース）、変換プロキシを介して共通PFサーバに接続され、B社IoT-PFがB社IoT-PF対応のオントロジー作成GUI、変換プロキシを介して共通PFサーバに接続され、C社IoT-PFがC社IoT-PF対応のオントロジー作成GUI、変換プロキシを介して共通PFサーバに接続され、センサデバイスがセンサデバイス提供元の規格対応のオントロジー作成GUI、変換プロキシを介して共通PFサーバに接続される。共通PFサーバは、複合データ活用アプリα、複合データ活用アプリβ、複合データ活用アプリγなどの各種アプリとの間で高度抽象化API・データ構造を実現してデータをやり取りする。

次にOntology based IWKの効果について説明する。
図２に示した構成では、図１に示した共通PF、Base Ontology Derived Model Mapping、およびCommon IWK Proceduresの処理が共通化されるので、これらを事業者ごとに都度開発する必要がなくなるため、変換プロキシの開発コストを低減することができる。

また、各種データ活用アプリから見ると、共通PFにより処理するデータの構成が共通化されるため、データ活用アプリにとってデータ取得の仕方も一義に決められ、アプリの開発と修正も簡単になる。
また、データ保管が簡単設定で最適化され、基盤のパフォーマンスを保つことができる。

図３は、本発明の一実施形態に係る情報処理システムの構成例を示す図である。
図３に示すように、本発明の一実施形態に係る情報処理システムでは、各事業者に対応して設けられるデータ処理装置１０が、複数種類の固有の規格に対応したセンサなどのデバイスと、アプリケーションとの間でデータ交換を行なう共通PFサーバ３０とにネットワークを介してそれぞれ接続される。データ処理装置１０は、上記の規格ごとに設けられ、該当の規格に対応したデバイスと接続される。データ処理装置１０、共通PFサーバ３０の機能は、プログラムを実行するＣＰＵ（Central Processing Unit）等のプロセッサ、およびＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）等の記憶媒体、キーボードなどの入力装置、ディスプレイなどの表示装置を用いて実現される。

データ処理装置１０は、オントロジー作成GUIと変換プロキシを有する。
オントロジー作成GUIは、オントロジー作成部（O, オントロジー作成部と表記することがある）１１を有する。

変換プロキシは、オントロジー読取部（A, オントロジー読取部と表記することがある）２１、デバイス管理部（B, デバイス管理部と表記することがある）２２、センサデータ交換部（C, センサデータ交換部と表記することがある）２３、共通交換部（D, 共通交換部と表記することがある）２４を有する。

オントロジー読取部２１は、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する。このオントロジー読取部２１は、オントロジーデータ格納部（格納部Ｘと表記することがある）２１ａを有する。

デバイス管理部２２は、固有の規格に対応したデバイスに固有のデバイス情報を取得して管理する。このデバイス管理部２２は、デバイス情報格納部（格納部Ｙと表記することがある）２２ａを有する。

センサデータ交換部２３には、事業者のセンサ、デバイス又はPFが接続される。このセンサデータ交換部２３は、センサデータ格納部（格納部Ｚと表記することがある）２３ａを有する。

共通交換部２４は、オントロジー読取部２１により取得されたオントロジーデータとデバイス管理部２２により管理されるデバイス情報とに基づいて、複数種類の固有の規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成して、このリソースを用いて共通PFサーバ３０との間でデータ交換を行なう。

共通PFサーバ３０は、各規格に共通した１つのサーバとして設けられ、データ保管部（E, データ保管部と表記することがある）３１、データ検索部（F, データ検索部と表記することがある）３２を有する。
データ保管部３１は、データ構造が記述されたオントロジーファイル(.owl(Web Ontology Language))を格納するオントロジーデータ格納部（格納部Ｖと表記することがある）３１ａ、データツリー格納部（格納部Ｗと表記することがある）３１ｂ）を有する。データツリーは、例えば「|-デバイス」、「|-サービス」、「|-データ」などで構成される。

オントロジー読取部２１、デバイス管理部２２、共通交換部２４、データ保管部３１、データ検索部３２は、各種規格で共通に設けることができ、センサデータ交換部２３は、規格ごとに設けられる。

次に、各部の入出力の機能について以下に説明する。
A, オントロジー読取部
・入力：GUIで作成されたowlファイル
・出力：オントロジーエンティティ関係マップ（Device、Service間、Service、DataPoint間の関係）
B, デバイス管理部
・入力：センサ出力（センサ接続の場合）、PF Device Discovery API（PF接続の場合）
・出力：デバイス情報マップ（{Device ID, Device Name}）
C, センサデータ交換部
・入力：Data Discovery API （オントロジーのServiceとDataPointエンティティ下に記述した値）
・出力：センサデータ（温度：37℃、湿度：50%など）、コマンド（switchON…）

D, 共通交換部
・入力：デバイス情報fromデバイス管理部、センサデータfromセンサデータ交換部
・出力：サーバへのデータ交換リクエスト（リソース作成、データ更新など）
E, データ保管部
・入力：変換プロキシからのデータ交換リクエストfrom共通交換部
・出力：リソース作成
F, データ検索部
・入力：SPARQL（RDF(Resource Description Framework)クエリ言語の１種）クエリ
・出力：データ取得URI、データ値
O, オントロジー作成部
・入力：人手による入力
・出力：IWK用のオントロジー(.owl)

次にBase Ontology (oneM2M)について説明する。
本発明の一実施形態では、oneM2M Base Ontologyを用いて各異種規格のデータ構造の抽象化を行い、抽象化したデータ構造の情報をRDFを用いて機械可読な形で記述し、データとデバイスの関係性などの知識をメタデータとして構造化し、データ情報を関連付けする。

図４は、本発明の一実施形態に係る情報処理システムに使用されるoneM2M base ontologyの一部の例を示す図である。
図４に示した例では、IoTデバイス（Device）はサービス（Service）経由でデータの送受信を行うことを想定する。RESTfulインタフェースを持つ異種規格の場合は、サービスの下にDataPointを定義する。この例では、クラス「Device」、「Service」はプロパティ「hasService」で関連付けられ、クラス「Service」、「OutputDataPoint」はプロパティ「hasOutputDataPoint」で関連付けられ、クラス「Service」、「InputDataPoint」はプロパティ「hasInputDataPoint」で関連付けられ、クラス「Device」、「Thing」はプロパティ「is-a」で関連付けられる。複雑なIoTデバイスの場合には、図４のように、「ConsistsOf」フィールドを利用して、子デバイスと子サービスを表現することによって、階層関係を定義する。

図５は、データ構造の抽象化の例を示す図である。RPCインタフェースの異種規格に対しては、RPCの機能ファンクションと同様なOperationを定義する。例えば、図５のように、「洗濯機」に「スイッチ」というサービスがあり、DataPointを利用する場合は、InputDataPointによって、スイッチOn/Offの操作を行い、OutputDataPointから現在のスイッチの状態を獲得する。

次に、IoT相互接続におけるデータの保存・取得の以下の４つの形態（形態1．～4．）について説明する。
形態1．（基本形態）：共通PFに最新値を更新（最新値のみ保存）
形態2．（拡張形態）：共通PFに時系列データ（Time Series）を蓄積（時系列データ蓄積）
形態3．（拡張形態）：アプリのリクエスト時にのみ、他規格PF/Deviceからデータを取得（オンデマンド取得）
形態4．（拡張形態）：アプリのリクエスト時に、他規格PF/Deviceに蓄積されたデータを一括取得（オンデマンド一括取得）

（形態1．）
次に、基本形態としての「形態1．：共通PFに最新値を更新」の詳細について説明する。図６は、最新値のみの保存について説明する図である。
共通PFに最新値を更新する際の課題を説明する。元々、oneM2MのOBI(Ontology Based Interworking)では他規格（データ提供者に固有の規格）のデータを接続させる際のコーディングを減らす目的がある。しかしながら仕様で決められた内容だけではリソース構造を一致させることにとどまり、実態としてはデバイスに対して大量のコーディングが必要になってしまう。

そこで、形態1．の技術では、<Protocol:hasAPI>を用い、他規格のデータに接続するためのAPIをオントロジーに追加することによって、デバイスごとにコーディングしなければならなかった部分をオントロジーにより吸収し、コーディング量を劇的に削減する。

次に、形態1．におけるオントロジー拡張フィールドについて説明する。図７は、オントロジー拡張フィールドの一例を説明する図である。
図７に示すように、形態1．では、共通PFサーバ３０に他規格のデバイスからの最新のデータを格納することを規定するメタデータフィールド「規格名：hasAPI」を用いて、抽象化したデータ構造のオントロジーと他規格に対応したデータ交換インタフェースとの関連付けを行なう。

例えば、DataPoint送受信するための他規格インタフェース（API）をオントロジーにあるDataPointインスタンス（当該インスタンスが属するクラス「OutputDataPoint」、「InputDataPoint」を含む）に関連付けるメタデータフィールド「規格名：hasAPI」（eg: DWAPI(Device Web API):hasAPI）が設計される。

また、同じメタデータフィールドを用いて、他規格のサービスを呼び出す際のAPIも記述できる。そして、上層がデータを効率的に理解するために、メタデータフィールド「規格名：hasUnit」を設計し、他規格で定義したデータの単位をオントロジーに記述する。

図７に示した例では、図４に示したように、クラス「Device」、「Service」はプロパティ「hasService」で関連付けられ、クラス「Service」、「OutputDataPoint」はプロパティ「hasOutputDataPoint」で関連付けられ、クラス「Service」、「InputDataPoint」はプロパティ「hasInputDataPoint」で関連付けられ、クラス「Device」、「Thing」はプロパティ「is-a」で関連付けられる。

そして、形態1．ではクラス「OutputDataPoint」はメタデータフィールド「規格名：hasUnit」によりクラス「Unit」を関連付けられ、クラス「InputDataPoint」はメタデータフィールド「Protocol：hasUnit」によりクラス「Unit」を関連付けられる。

また、クラス「Service」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられ、クラス「OutputDataPoint」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられ、クラス「Service」、「InputDataPoint」はメタデータフィールド「Protocol：hasAPI」によりクラス「Unit」と関連付けられる。

次に、変換プロキシ接続時のワークフローについて説明する。図８は、変換プロキシ接続時のワークフローの一例を説明する図である。図９は、変換プロキシ接続時のシーケンスの一例を説明する図である。このワークフロー、シーケンスは、形態1．～4．に共通する。

このワークフローでは、変換プロキシがオントロジーを読み込み、オントロジーの内容に応じてDevice/Service/InputDataPoint/OutputDataPointの共通的な処理を行なう。
まず、オントロジー読取部２１は、オントロジー作成部１１により作成されたオントロジーファイルを読取り、格納部Xに格納する（Ｓ１１）。ここでオントロジー読取部２１は、共通交換部２４に対し、OBI Clientを作成し、オントロジーをRegisterする。共通交換部２４は、変換プロキシのリソースを作成し、共通PFサーバ３０のデータ保管部３１に送る。また、共通交換部２４は、変換プロキシを表すリソース直下にオントロジーデータを、格納部Yを保管先として保管する。

デバイス管理部２２は、他規格のPF/Deviceからデバイス情報を取得し（Ｓ１２）、新しいデバイスならデバイスリスト{Device ID, Device Name}を更新し、共通交換部２４で送信する。

次に共通交換部２４は、取得されたデバイス情報で示されるDeviceがオントロジーにあるか否かを判定し（Ｓ１３）、Deviceがオントロジーにないときは、オントロジーに対応していないとしてデバイスリストから削除する。Deviceがオントロジーにあるときは、共通交換部２４は、Device Wrapperを作成する（Ｓ１４）。
データ保管部３１は、変換プロキシのリソースの一種であるDeviceリソースを作成し、データ保管部３１内の格納部W, Vに保管する（Ｓ１５）。

次に、共通交換部２４は、Service Wrapperを作成し、データ保管部３１の格納部W, Vに保管する（Ｓ１８）。データ保管部３１は、変換プロキシのリソースの一種であるServiceリソースを作成し、データ保管部３１格納部W, Vに保管する（Ｓ１７）。

次に、共通交換部２４は、オントロジーにおけるDeviceの下層に未処理Serviceがあるか否かを判定し（Ｓ１９）、未処理ServiceがあればＳ１８に遷移する。また、未処理Service Wrapperがなければ、共通交換部２４は、InputDataPointの有無を確認し（Ｓ２０）、InputDataPointがあれば、Serviceリソースの下層にSubscriptionリソースを作成し、データ保管部３１の格納部Wに格納する（Ｓ２１）。Subscriptionリソースとは、共通PFのデータリソースの一種である。その他のリソース（eg: Service resource）の下に置くと、そのリソースに更新があるときに、通知が送られる。通知先は、Subscriptionリソースに記述される。
Ｓ２１の後は、Ｓ２２、および後述するInputDataPoint交換フロー（Ｓ３１～３６）に移行する。

InputDataPointがないときは、共通交換部２４は、OutputDataPointの有無を確認し（Ｓ２２）、OutputDataPointがないときは処理が終了する。OutputDataPointがあるときは、共通交換部２４は、センサデータ取得サブフローを作成し（OutputDataPointと、格納部Xから取得した、親Serviceの他規格APIとをワークフローに保管する）、
Ｓ２１の後は、後述するOutputDataPoint交換フロー（Ｓ４１～４７）に移行する。

InputDataPoint交換フローについて説明する。図１０は、InputDataPoint交換のワークフローの一例を示す図であり、図１１は、InputDataPoint交換のシーケンスの一例を示す図である。このワークフロー、シーケンスは、形態1．～4．に共通する。
InputDataPoint交換では、オントロジーに記述した他規格APIを用いて、InputDataPoint（他規格PF或いはデバイスにデータ/コマンドを送る）の共通的な処理を行なう。

まず、共通PFサーバ３０のデータ検索部３２は、アプリからのSPARQLにより、データ保管部３１の格納部Vで検索し、Deviceと配下のService, InputDataPointを発見する（例：「Device: WashingMaching」、「|-Service: Control」、「|-InputDataPoint: Switch」）（Ｓ３１）。

データ検索部３２は、データ保管部３１の格納部Ｗにおいて、Serviceリソース下のInputDataPoint属性を更新（例：Switch: ONに）する（Ｓ３２）。
データ保管部３１は、このサービス下のSubscriptionリソースに指定された変換プロキシに通知を送る（Ｓ３３）。

変換プロキシの共通交換部２４は、オントロジー対応InputDataPointであるか否かを判定し（Ｓ３４）、オントロジー対応InputDataPointでなければ処理が終了する。
オントロジー対応InputDataPointであれば、共通交換部２４は、オントロジーから本InputDataPointと、その親Serviceの対応する他規格のAPIとを読取る（Ｓ３５）。
そして、センサデータ交換部２３は、他規格のAPIを使って他規格のPF或いはデバイスにコマンドを送る（Ｓ３６）。

OutputDataPoint交換フローについて説明する。図１２は、OutputDataPoint交換のワークフローの一例を示す図であり、図１３は、OutputDataPoint交換のシーケンスの一例を示す図である。このワークフロー、シーケンスは、形態1．～4．に共通する。
OutputDataPoint交換では、オントロジーに記述した他規格APIを用いて、OutputDataPoint（他規格PF或いはデバイスからデータ/コマンドを取得）の共通的な処理を行なう。

定期開始(Thread)後、センサデータ交換部２３は、OutputDataPointと、その親Serviceの他規格APIを用いて、センサデータを格納部Zから取得する（Ｓ４１）。
センサデータ交換部２３は、オントロジーに設定したDataTypeに変換可能か否かを判定し（Ｓ４２）、変換可能でなければ異常終了(Thread)となる。
変換可能であれば、センサデータ交換部２３は、オントロジーに設定した、本OutputDataPointのDataTypeに変換する（Ｓ４３）。

共通交換部２４は、OutputDataPointのリソース値の更新をデータ保管部３１にリクエストする（Ｓ４４）。
データ保管部３１は、格納部WにおけるOutputDataPointのリソース値を更新する（Ｓ４５）。
データ保管部３１は、本OutputDataPoint下にsubscriptionリソースがあるか否かを判断する（Ｓ４６）。
このsubscriptionリソースがなければ、正常終了(Thread)となる。

また、上記のsubscriptionリソースがあれば、データ保管部３１は、OutputDataPointの最新値をsubscriptionリソースが指定したアプリに送り（Ｓ４７）、正常終了(Thread)となる。

次に、「環境監視センサ」というデバイス（DWAPI規格準拠）を例とする、すべてのデータ交換フローがオントロジー設定に沿って行なわれる実施例について説明する。
図１４は、他規格とのデータ交換フローの共通化の一例を説明する図である。
ここでは、他規格に対して、各種のデータ構造に拘らない共通化されたデータ交換フローを設計する。

図１４に示した例では、インスタンス「getData」、「ManageDev」がクラス「Service」に属し、インスタンス「温度」、「湿度」、「CO2」がクラス「OutputDataPoint」に属し、インスタンス「Interval」、「Switch」がクラス「InputDataPoint」に属する。

また、インスタンス「EnvSensor」は、プロパティ「hasService」によりインスタンス「getData」、「ManageDev」に関連付けられ、インスタンス「getData」は、プロパティ「hasOutputDataPoint」によりインスタンス「温度」、「湿度」、「CO2」に関連付けられ、インスタンス「ManageDev」は、プロパティ「hasInputDataPoint」によりインスタンス「Interval」、「Switch」に関連付けられる。

インスタンス「EnvSensor」は、プロパティ「is-a」によりインスタンス「環境センサー」と関連付けられ、インスタンス「ManageDev」はプロパティ「hasAPI」により他規格API（インスタンス）「Sensor/Service1」と関連付けられ、インスタンス「getData」は、プロパティ「hasAPI」により他規格API「Sensor/Service2」と関連付けられる。

インスタンス「温度」は、プロパティ「hasAPI」により他規格API「DATA:arg(argument)1」と、インスタンス「湿度」は、プロパティ「hasAPI」により他規格API「DATA:arg2」と、インスタンス「CO2」は、プロパティ「hasAPI」により他規格API「DATA:arg3」と、インスタンス「Interval」は、プロパティ「hasAPI」により他規格API「DATA:arg4」と、インスタンス「Switch」は、プロパティ「hasAPI」により他規格API「DATA:arg5」とそれぞれ関連付けられる。
他規格API「DATA:arg1」、「DATA:arg2」、「DATA:arg3」、「DATA:arg4」、「DATA:arg5」は、クラス「API」と関連付けられる。

まず、他規格のデバイス発見APIを利用して、接続しているデバイスリストが取得される。デバイス発見APIのない他規格（eg: LoRa(Long Range)）に対して各デバイスから初めて取得されたデータから、解析が行われ、デバイス種類（EnvSensor）を表すフィールドが抽出される（図１４中のａ）。

次に、RDFクエリ言語であるSPARQL (中にBOでBase Ontologyを表す)
{?Device RDFS:subClassof BO:Device}
を用いて、事前に定義した抽象化オントロジーの中にこのデバイス種類が存在しているかどうかが判断される。オントロジーの対応しているデバイスであれば、共通処理としてoneM2M側のリソースツリーにそのデバイスを表すリソース（デバイスAE(Application Entity)）が作成される。

次に、デバイス種類（EnvSensor）が持つサービス（getDataとManageDev）が下記のSPARQLで抽出される（図１４中のｂ）。
{?Device BO:hasService ?Service}
抽出されたサービスに対して、oneM2M側で<FC>（flexContainer）というリソースが作成される。また、後ほどデータ交換のための各サービスを呼び出すための他規格API（DWAPI:Sensor/Service1など）も抽出されて保持される。

さらに、抽出された各サービスに対して、対応OutputDataPointの有無が以下で判断される（図１４中のｃ）。
{?Service BO:hasOutputDataPoint ?o}
OutputDataPointが存在する場合は、保管しているそのサービスの他規格APIに対して、データ取得スレッドが新規に作成され、データの受信準備が行われる。オントロジーにある各OutputDataPointの他規格API（eg: DWAPI:DATA:arg1）がメタデータフィールド（DWAPI:hasAPI）によって取得されて保持される。

毎回そのサービスからデータを取得できた際に、DataPointの他規格APIを利用して、各OutputDataPointの値がサービス呼出し結果から取得されてoneM2Mリソースの対応customAttributeが更新される（図１４中のｄ）。

一方、各サービスに対して、対応InputDataPointの有無が以下のSPARQLで判断される。
{?Service BO:hasInputDataPoint ?i}
InputDataPointが存在する場合、oneM2Mで作成された、そのサービスの<FC>リソースの下に、IPE(Interworking Proxy Entity)を主にした<Subscription>リソースが作成され、oneM2M側で、そのInputDataPointの値が変えられるときにIPEが受信できるようにされる。oneM2M側の変化を受信したら、対応InputDataPointの他規格APIを利用して他規格デバイスに対して更新が行われる（図１４中のｄ）。

ここまでの処理フローは「Device」「Service」「DataPoint」の三つの抽象クラスで高度に共通化された。それぞれのインスタンスの処理の違いはすべてオントロジーに定義され、実行時に動的にパラメータとして読込んで動作させる。また、子デバイスと子サービスの処理も、メタデータフィールド「consistsOf」を利用して抽出されてから、共通的に行われる。

ここで、オントロジーのAEへの提供について説明する。
作成したオントロジーで表す他規格デバイスのデータ構造は上層のAEに対しても有効な知識である。図１４に示したデバイス、サービスを表すoneM2Mリソースの下にある<SD>（Semantic Descriptor）リソースに対応のオントロジー情報を以下のルールで保管し、SPARQL言語という機械可読のデバイス・サービス発見とデータ取得のインタフェースをAEに提供する。
Device、Service間の部分は各デバイスの<SD>に保管される。
Service、DataPoint間の部分は各サービス配下の＜SD＞に保管される。

（形態2．）
次に、基本形態に対する拡張形態としての「形態2．：時系列データ蓄積」の詳細について説明する。図１５は、時系列データの蓄積の一例について説明する図である。
時系列データの蓄積における課題を説明する。元々、oneM2MのOBIではデータは最新値しか共通PFに保存されていなかったので、過去の時系列情報が必要な分析を行うとき（例えばカルマンフィルタみたいな分析、又はイベントログによる障害切り分けなど）にはアプリ側でデータを保存していない限りは対応できなかった。

そこで、形態2．の技術では、<Protocol:storeTimeseries>を用い、時系列データとしての蓄積機能フィールドを新たに追加することで、時系列ヒストリーデータを共通PF上に格納する。

次に、形態.2におけるオントロジー拡張フィールドについて説明する。図１６は、オントロジー拡張フィールドの一例を説明する図である。
図１６に示すように、形態.2では、共通PFサーバ３０に他規格のデバイスからの時系列データを格納することを規定するメタデータフィールド「規格名：storeTimeseries」を用いて、時系列ヒストリーデータを共通PF上に格納する。

図１６に示した（Option.1）では、メタデータフィールド「規格名：storeTimeseries」をServiceに追加し、trueに設定する場合、当該Service配下のすべてのOutputDataPointを一つの共通PF上のTimeSeriesリソースに統合して保存する。

図１６に示した(Option.2)では、メタデータフィールド「規格名：storeTimeseries」をOutputDataPointに追加し、trueに設定する場合、当該OutputDataPointの値を一つの共通PF上のTimeSeriesリソースに保存する。
形態2．における、変換プロキシ接続時のワークフローは形態1．と同じである。

次に、（Option.1）におけるデータ交換のワークフローについて説明する。図１７、図１８は、データ交換のワークフローの一例を示す図であり、図１９は、データ交換のシーケンスの一例を示す図である。
（Option.1）におけるデータ交換では、オントロジーに記述されたService配下のstoreTimeseriesのBoolean値を用いて、Service配下のOutputDataPointの共通的な履歴データ保管処理を行う。

まず、オントロジー読取部２１は、ServiceのstoreTimeseriesがtrueであるか否かを判断し（Ｓ５１）、trueであれば、オントロジー読取部２１は、格納部XにおけるstoreTSforServiceのFlagをtrueに設定する（Ｓ５２）。

Ｓ５２の後、共通交換部２４は、格納部WにおけるServiceリソースの子リソースに時系列データ格納リソースがあるか否かを判断する（Ｓ５３）。時系列データ格納リソースがなければ、データ保管部３１は、これを作成する（Ｓ５４）。ここで、センサデータ交換部２３は、センサデータを取得して共通交換部２４に送信し、共通交換部２４は、データ保管部３１におけるセンサデータを更新する（OutputDataPointの値を更新する）。
Ｓ５１のNoのとき、Ｓ５３のYesのとき、又はＳ５４の後、上記のOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。

OutputDataPoint交換フローの後、共通交換部２４は、storeTSforServiceのFlagがtrueであるか否かを判別し（Ｓ５５）、trueでなければ処理が終了し、trueであれば、Serviceが持つOutputDataPointを1つのJSONにマージする（Ｓ５６）。

データ保管部３１は、JSONを時系列データ格納リソースに追加してデータ保管部３１に送り（Ｓ５７）、処理が終了する。センサデータの取得からＳ５７までの処理は設定された周期で繰り返される。

また、アプリによる処理開始後、データ検索部３２は、SPARQLでオントロジーデータ内のstoreTimeseriesを確認し、URIデータを取得し、アプリに送る（Ｓ５８）。
データ保管部３１は、格納部Xから時系列データを取得し（Ｓ５９）、データ検索部３２は、アプリに時系列データを返答し、処理が終了する（Ｓ５１１）。

次に、時系列データ蓄積の（Option1.）の手順について説明する。図２０は、時系列データ蓄積の手順の一例を示す図である。
図２０に示すように、時系列データ蓄積の（Option1.）では以下の(1)～(9)の処理がなされる。
(1)変換プロキシがOntologyを読み、storeTimeseries:trueのServiceに対して変換プロキシ内storeTSforServiceをtrueにsetする。
(2)storeTSforServiceFlagがtrueの場合、対象Service<fcnt>の子リソースに対象ts_Service<ts>があるか調べる。
(3)ts_Service<ts>がなければCREATEする。
(4)変換プロキシから、他規格PF/DeviceのAPI経由でデータを得る。
(5)Service下のOutputDataPointを1つのJSONにマージする。
(6)変換プロキシが上記JSONをCREATEする（ts_Service<ts>/<tsi>）。
(7)アプリがSPARQLにより欲しいServiceのstoreTimeseries状態を確認する。
(8)アプリが対象<ts>を取得する。
(9)アプリが<ts>/<latest>などを取得する。

次に、形態2.の（Option1.）の実施例を説明する。図２１は、時系列データ蓄積の実施例を示す図である。
（Option1.）では、複数のDataPointをまとめて蓄積したい場合、Serviceごとに時系列データ保存のON/OFFを設定する。ここで、対象のServiceの下にTs（時系列データ）を作成し、Service配下にある全てのOutputDataPointをまとめて<Tsi>のconにJSONで格納する。図２１に示した例では、getGPS下のDataPoint値をまとめて格納する（{datadataLongitude:XXX, dataLatitude:YYY}）。

次に、（Option.2）におけるデータ交換のワークフローについて説明する。図２２、図２３は、データ交換のワークフローの一例を示す図であり、図２４は、データ交換のシーケンスの一例を示す図である。
（Option.2）におけるデータ交換では、オントロジーに記述された他規格APIを用いて、OutputDataPoint（他規格PF或いはデバイスからデータ/コマンドを取得）の共通的な処理を行う。

まず、オントロジー読取部２１は、OutputDataPointのstoreTimeseriesがtrueであるか否かを判断し（Ｓ６１）、trueであれば、オントロジー読取部２１は、格納部XにおけるstoreTimeseriesDataPointのFlagをtrueに設定する（Ｓ６２）。

Ｓ６２の後、共通交換部２４は、格納部WにおけるServiceリソースの子リソースにOutputDataPointの時系列データ格納リソースがあるか否かを判断する（Ｓ６３）。
時系列データ格納リソースがなければ、データ保管部３１は、これを作成する（Ｓ６４）。ここで、センサデータ交換部２３は、センサデータを取得して共通交換部２４に送信し、共通交換部２４は、データ保管部３１におけるセンサデータを更新する（OutputDataPointの値を更新する）。

Ｓ６１のNoのとき、Ｓ６３のYesのとき、又はＳ６４の後、上記のOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。
OutputDataPoint交換フローの後、共通交換部２４は、storeTimeseriesDataPointのFlagがtrueであるか否かを判別し（Ｓ６５）、trueでなければ処理が終了し、trueであれば、データ保管部３１は、OutputDataPointを時系列データ格納リソースに追加し、処理が終了する（Ｓ６６）。センサデータの取得からＳ６７までの処理は設定された周期で繰り返される。

また、アプリによる処理開始後、データ検索部３２は、SPARQLでオントロジーデータ内のstoreTimeseriesを確認し、URI(Uniform Resource Identifier)データを取得し、アプリに送る（Ｓ６８）。
データ保管部３１は、格納部Xから時系列データを取得し（Ｓ６９）、データ検索部３２は、アプリに時系列データを返答し、処理が終了する（Ｓ６１１）。

次に、時系列データ蓄積の（Option2.）の手順について説明する。図２５は、時系列データ蓄積の手順の一例を示す図である。
図２５に示すように、時系列データ蓄積の（Option2.）では以下の(1)～(8)の処理がなされる。
(1)変換プロキシがOntologyを読み、storeTimeseries:trueのOutputDataPointに対してObiServiceWrapperのstoreTimeseriesをtrueにsetする。
(2)ObiServiceWrapperのstoreTimeseriesFlagがtrueの場合、対象Service<fcnt>の子リソースに対象ts_OutputDataPoint<ts>があるか調べる。
(3)ts_OutputDataPoint<ts>がなければCREATEする。
(4)変換プロキシから他規格PF/DeviceのAPI経由でデータを得る。
(5)変換プロキシがDataPointをCREATEする（ts_OutputDataPoint<ts>/<tsi>）。
(6)アプリがSPARQLにより欲しいServiceのstoreTimeseries状態を確認する。
(7)アプリが対象<ts>を取得する。
(8)アプリが<ts>/<latest>など取得する。

次に、形態2.の（Option2.）の実施例を説明する。図２６は、時系列データ蓄積の実施例を示す図である。
（Option2.）では、DataPointごとに蓄積したい場合、OutputDataPointに時系列データ保存のON/OFFを設定する。
ここで、対象のOutputDataPoint毎にTs（時系列データ）を作成し、値をTsiのconに格納する。

（形態3．）
次に、基本形態に対する拡張形態としての「形態3．：オンデマンド取得」の詳細について説明する。図２７は、オンデマンド取得の蓄積の一例について説明する図である。
オンデマンド取得における課題を説明する。元々、oneM2MのOBIでは得られたデータを常に更新し続けていたが、高頻度でデータを発生するデバイスに対し、データ利用の需要が少ないときはデータを更新しても無駄になるケースが考えられる。

そこで、形態3．の技術では、<Protocol:onDemand>を用い、データの最新値を共通PFに保存せずに、アプリのリクエストによってオンデマンドで他規格デバイス（或いはPF）から取得する機能フィールドを新たに追加することで、利用者の需要に応じてデータを取得する。

次に、形態.3におけるオントロジー拡張フィールドについて説明する。図２８は、オントロジー拡張フィールドの一例を説明する図である。
図２８に示すように、形態.3では、デバイスからの最新のデータをアプリケーションからの要求によって当該デバイスから取得することを規定するメタデータフィールド「規格名：onDemand」を用いて、アプリのリクエストによってオンデマンドで他規格デバイス（或いはPF）からデータを取得する。

形態3.では、メタデータフィールド「規格名：onDemand」をOutputDataPointに追加し、trueに設定する場合、共通PFが常に他規格PF/Deviceから最新値を取り続けずに、アプリのリクエストに応じてオンデマンドで取得していく。
形態3.における、変換プロキシ接続時のワークフローは形態1．と同じである。

次に、形態3.におけるデータ交換のワークフローについて説明する。図２９、図３０は、データ交換のワークフローの一例を示す図であり、図３１は、データ交換のシーケンスの一例を示す図である。
形態3.におけるデータ交換では、オントロジーに記述されたonDemandのBoolean値を用いて、OutputDataPointの共通的なオンデマンド取得処理を行う。
他規格、プロトコルとデータマッピング・交換を担うIPE（Interworking Proxy Entity）登録により処理が開始されると、オントロジー読取部２１は、格納部XにおけるOutputDataPointのonDemandがtrueであるか否かを判断し（Ｓ７１）、trueであれば、共通交換部２４は、共通PFに当該OutputDataPointの親Serviceの下にsubscriptionを作成リクエスト、通知先を変換プロキシに設定する（Ｓ７２）。
共通PF３０のデータ保管部３１は、共通PFに当該OutputDataPointの親Serviceの下にsubscriptionを作成し、処理が終了する（Ｓ７３）。
Ｓ７１でtrueでなければOutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされて、処理が終了する。

また、アプリによる処理開始後、データ検索部３２は、SPARQLで格納部Vにおけるオントロジーデータ内のonDemand=trueを確認し、URIデータを取得し、アプリに送る（Ｓ７４）。

アプリは、欲しいDataPointにSubscriptionを作成し、データ保管部３１の格納部Wに格納する（Ｓ７５）。
アプリは、データ取得希望（DataPointを更新“demanding”）をデータ保管部３１に送る（Ｓ７６）。

データ保管部３１は、DataPointの変更を共通交換部２４に通知する（Ｓ７７）。
共通交換部２４は、“demanding“状態のDataPointを確認する（Ｓ７８）。
共通交換部２４は、センサデータ交換部２３にDemanding通知を行う（Ｓ７９）。
センサデータ交換部２３は、センサデータを取得し（Ｓ７１１）、OutputDataPointを共通交換部２４に送信する（Ｓ７１２）。

共通交換部２４は、データ保管部３１の格納部WにおけるOutputDataPointにセンサデータを反映して更新する（Ｓ７１３）。
データ保管部３１はデータ検索部３２を介してセンサデータをアプリに通知する（Ｓ７１４）。
データ検索部３２は、センサデータを受け取ったらSubアプリを削除する（Ｓ７１５）。

次に、オンデマンド取得の手順について説明する。図３２は、オンデマンド取得の手順の一例を示す図である。
図３２に示すように、オンデマンド取得では以下の(1)～(10)の処理がなされる。
(1)変換プロキシがOntologyを読み、onDemand:trueのDataPointに対して共通PF内の対象Service<fcnt>の下にsub変換プロキシ<sub>を作る。Serviceが複数DataPointを持つ場合もsubscriptionは1つが、後ほどのnotify受信時に、DataPoint単位で通知を振り分ける。
(2)アプリがSPARQLにより欲しいDataPointのonDemand状態を確認する。
(3)onDemandがTrueな場合は、対象Service<fcnt>の下にsubアプリ<sub>を作る。
(4)欲しいDataPointをUPDATEする（[DataPoint]:”demanding”）。
(5)上記により共通PFから変換プロキシにNotifyする（sub変換プロキシ）。
(6)変換プロキシ内でNotificationの内容を確認する。
(7)変換プロキシから他規格PF/DeviceのAPI経由でデータを得る。
(8)変換プロキシがDataPointをUPDATEする（[DataPoint]:{value}）。
(9)上記により共通PFからアプリにNotify（subアプリ）する。
(10)データを受け取ったらアプリがsubアプリを削除する。

次に、形態3.の実施例を説明する。図３３は、オンデマンド取得の実施例を示す図である。
形態3.では、OutputDataPoint毎にデータをオンデマンドで取得するか否かを設定する。図３３に示した例では、dataCO2値をオンデマンドで取得して、共通PF内のリソースツリーに一旦格納してアプリに送る。

（形態4．）
次に、基本形態に対する拡張形態としての「形態4．：スパン指定オンデマンド一括取得」の詳細について説明する。図３４は、オンデマンド一括取得の蓄積の一例について説明する図である。
オンデマンド一括取得における課題を説明する。
元々、oneM2MのOBIでは、得られたデータの最新値のみを保持しており、他PFに過去のデータが蓄積されていたとしても、アプリからのリクエストで、これらのデータを取得することはできなかった。

そこで、形態4．の技術では、<Protocol:onDemandTS>を用い、アプリのリクエストによってオンデマンドで他規格デバイス（或いはPF）からデータを期間指定で一括取得する機能フィールドを新たに追加することで、利用者の需要に応じて他PFに蓄積されている過去のデータを一定期間分一括で取得する。

次に、形態.4におけるオントロジー拡張フィールドについて説明する。図３５は、オントロジー拡張フィールドの一例を説明する図である。
図３５に示すように、形態.4では、デバイスに固有の他規格PF/Deviceに保管された時系列データをアプリケーションからの要求によって一括して取得することを規定するメタデータフィールド「規格名：onDemandTS」を用いて、アプリのリクエストによってオンデマンドで他規格デバイス（或いはPF）から、他規格PF/Deviceに保管している履歴データを一括取得する。

形態4.では、メタデータフィールド「規格名：onDemandTS」をOutputDataPointに追加し、trueに設定する場合、共通PFが常に他規格PF/Deviceから最新値を取り続けずに、アプリのリクエストに応じてオンデマンドで取得していく。取得する際に、アプリが指定したタイムスパンで履歴データを一括取得し、共通PFに保存する。
形態4.における、変換プロキシ接続時のワークフローは形態1．と同じである。

次に、形態4.におけるデータ交換のワークフローについて説明する。図３６は、データ交換のワークフローの一例を示す図であり、図３７は、データ交換のシーケンスの一例を示す図である。
形態4.におけるデータ交換では、オントロジーに記述されたonDemandTSのBoolean値を用いて、OutputDataPointの共通的なオンデマンドスパン指定一括取得処理を行う。
IPE登録により処理が開始されると、図２９で説明したＳ７１～Ｓ７４、OutputDataPoint交換フロー（Ｓ４１～Ｓ４７)がなされる。

また、アプリによる処理開始後、図３０に示したＳ７４～Ｓ７９までの処理がなされ、センサデータ交換部２３は、指定期間分のセンサデータを取得し（Ｓ７１１）、OutputDataPoint（センサデータ）を共通交換部２４に送信する（Ｓ７１２）。

共通交換部２４は、対象OutputDataPointの時系列データ格納リソースがあるか否かを調べて、なければこれを作成し、このリソースの下の層にセンサデータ群を作成する（Ｓ７１３）。以降は、図３０で説明したＳ７１４、Ｓ７１５がなされて処理が終了する。

次に、スパン指定オンデマンド一括取得の手順について説明する。
スパン指定オンデマンド一括取得では図３２に示した(1)から(5)までがなされ、以下の(6)以降がなされる。
(6)変換プロキシ内でNotificationの内容を確認し、取得期間を確認する。
(7)変換プロキシから他規格PF/DeviceのAPI経由でデータを得る。
(8)対象OutputDataPoint<ts>があるか否かを調べ、なければCREATEし、この下の層にデータ更新をCREATEする（Device/Service/<ts>/<tsi>）。
(9)上記により共通PFからアプリにNotify（subアプリ）する。
(10)データを受け取ったらアプリがsubアプリを削除する。

次に、形態4.の実施例を説明する。図３８は、オンデマンド一括取得の実施例を示す図である。
形態4.では、OutputDataPoint毎にデータをオンデマンドで一括取得するか否かと、取得する期間を設定する。図３８に示した例では、取得した過去データが蓄積される。

以上説明したように、本発明の一実施形態に係る情報処理システムでは、固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータと、デバイス情報とに基づいて、規格に共通したデータ構造と固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成して、共通プラットフォームサーバとの間でデータ交換を行なうので、規格ごとにコーディングする必要があった部分を共通化した上でデータ交換を行なうことができる。

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

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

１０…データ処理装置、１１…オントロジー作成部、２１…オントロジー読取部、２１ａ…オントロジーデータ格納部、２２…デバイス管理部、２２ａ…デバイス情報格納部、２３…センサデータ交換部、２３ａ…センサデータ格納部、２４…共通交換部、３０…共通PFサーバ、３１…データ保管部、３１ａ…オントロジーデータ格納部、３１ｂ…データツリー格納部、３２…データ検索部。

Claims

複数種類の固有の規格に対応したデバイスと、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバとにそれぞれ接続される、変換プロキシを有する情報処理システムであって、
前記変換プロキシは、
前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得する取得手段と、
前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理するデバイス管理手段と、
前記取得手段により取得されたオントロジーデータと前記デバイス管理手段により管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成し、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう共通交換手段と、
を備えた情報処理システム。
前記共通プラットフォームサーバは、
前記デバイスから取得したデータを保管するデータ保管部を有し、
前記リソースは、
前記データ保管部に前記デバイスから取得した最新のデータを格納することを規定する第１のデータフィールドを有し、
前記変換プロキシの前記共通交換手段は、
前記第１のデータフィールドの規定に基づいて、前記デバイスから取得した最新のデータを前記データ保管部に保管する、
請求項１に記載の情報処理システム。
前記共通プラットフォームサーバは、
前記デバイスから取得したデータを保管するデータ保管部を有し、
前記リソースは、
前記データ保管部に前記デバイスから取得した時系列データを格納することを規定する第２のデータフィールドを有し、
前記変換プロキシの前記共通交換手段は、
前記第２のデータフィールドの規定に基づいて、前記デバイスから取得した時系列データを前記データ保管部に保管する、
請求項１に記載の情報処理システム。
前記リソースは、
前記デバイスから取得した最新のデータを前記アプリケーションからの要求に応じて前記デバイスから取得することを規定する第３のデータフィールドを有し、
前記変換プロキシの前記共通交換手段は、
前記アプリケーションからの要求に応じて、前記第３のデータフィールドの規定に基づいて、前記デバイスから取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る、
請求項１に記載の情報処理システム。
前記リソースは、
前記デバイスに対応付けられた固有の保管部に保管された時系列データをアプリケーションからの要求に応じて一括して取得することを規定する第４のデータフィールドを有し、
前記変換プロキシの前記共通交換手段は、
前記アプリケーションからの要求に応じて、前記第４のデータフィールドの規定に基づいて、前記保管部から取得したデータを前記共通プラットフォームサーバを介して前記アプリケーションに送る、
請求項１に記載の情報処理システム。
複数種類の固有の規格に対応したデバイスと、アプリケーションとの間でデータ交換を行なう共通プラットフォームサーバとにそれぞれ接続される、変換プロキシを有する情報処理システムが行う情報処理方法であって、
前記変換プロキシは、
前記固有の規格に対応したデータ構造がオントロジーによって記述されたオントロジーデータを取得し、
前記複数種類の固有の規格に対応したデバイスに対応付けられた固有のデバイス情報を取得して管理し、
前記取得されたオントロジーデータと前記管理されるデバイス情報とに基づいて、前記複数種類の固有の規格に共通したデータ構造と前記固有の規格に対応したデータ交換インタフェースとを関連付けたリソースを作成して、前記作成されたリソースを用いて前記共通プラットフォームサーバとの間でデータ交換を行なう、
情報処理方法。
請求項１乃至５のいずれか１項に記載の情報処理システムの前記各手段としてプロセッサを機能させる情報処理プログラム。