(57)【要約】  一実施形態に係るデータ処理システムは、１以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続されるデータ処理システムであって、プロセッサを有し、前記プロセッサは、前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付ける受付処理を行ない、前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能を有し、前記受け付けられた前記リクエスト又はデータのタイプに応じた処理を前記永続化機能により行なって、その処理結果を前記データベースに永続的に格納する永続化処理を行ない、前記受け付けられた前記リクエスト又はデータのタイプに基づいて、前記受け付けられた前記リクエスト又はデータの処理先を前記複数種類の永続化機能のいずれかに切り替える切替処理を行なう、ように構成される。
2020054147.tif 000002
【特許請求の範囲】
【請求項１】
１以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続されるデータ処理システムであって、
プロセッサを有し、
前記プロセッサは、
前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付ける受付処理を行ない、
前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能を有し、前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じた処理を前記永続化機能により行なって、その処理結果を前記データベースに永続的に格納する永続化処理を行ない、
前記受付処理により受け付けられた前記リクエスト又はデータのタイプに基づいて、前記受付処理により受け付けられた前記リクエスト又はデータの処理先を前記複数種類の永続化機能のいずれかに切り替える切替処理を行なう、ように構成される、
データ処理システム。
【請求項２】
前記プロセッサは、
前記受付処理として、
前記デバイスからのデータを受け付け、
前記永続化処理として、
前記受付処理により受け付けられた単一のデータが、複数の論理データからなる物理データであるときに、前記単一のデータを論理データごとに分離して、前記分離された物理データを前記処理結果として前記データベースに格納する、ように構成される、
請求項１に記載のデータ処理システム。
【請求項３】
前記プロセッサは、
前記永続化処理として、
前記受付処理により受け付けられた前記単一のデータに通し番号を付与したデータと、前記分離された物理データの各々に前記分離する前のデータに付与された通し番号と同じ通し番号を付与した物理データとを前記データベースにそれぞれ格納する、ように構成される、
請求項２に記載のデータ処理システム。
【請求項４】
前記プロセッサは、
前記受付処理として、
前記デバイスからのデータを受け付け、
前記永続化処理として、
前記受付処理により受け付けられたデータが、相互に関連付けられた複数種類のデータからなるときに、前記複数種類のデータを種類ごとに分離して、前記分離されたデータを前記データベースに格納する、ように構成される、
請求項１に記載のデータ処理システム。
【請求項５】
前記プロセッサは、
前記永続化処理として、
前記データベースに格納されたデータを読み出して、前記アプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される、
請求項１に記載のデータ処理システム。
【請求項６】
前記プロセッサは、
前記永続化処理として、
前記データベースに格納されたデータを読み出して、前記読み出されたデータのうち第１のデータを、第１のアプリケーションプログラムによりアクセス可能なデータとして設定し、前記読み出されたデータのうち第２のデータを、第２のアプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される、
請求項５に記載のデータ処理システム。
【請求項７】
前記プロセッサは、
前記永続化処理として、
ネットワークインタフェースを介して前記デバイスと異なる第２のデバイスとの間で通信をさらに行ない、
前記受付処理より第１の通信プロトコルで受け付けられた前記リクエストに基づき、前記第２のデバイスとの間で前記第１の通信プロトコルと異なる第２のプロトコルを用いて情報の送受信を行なう、ように構成される、
請求項１に記載のデータ処理システム。
【請求項８】
前記永続化処理により前記第２のデバイスから取得された情報を記憶する記憶装置をさらに有し、
前記プロセッサは、
前記受付処理より第１の通信プロトコルで受け付けられた、前記第２のデバイスから情報を取得するリクエストに基づき、前記第２のデバイスから取得した情報を前記記憶装置に記憶し、
前記受付処理より第１の通信プロトコルで受け付けられたリクエストに基づき、前記リクエストで示される、取得対象の情報が前記記憶装置に記憶される場合は、この情報を前記記憶装置から読み出す、ように構成される、
請求項７に記載のデータ処理システム。
【請求項９】
１以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続され、プロセッサを具備するデータ処理システムが行なうデータ処理方法であって、
前記プロセッサは、前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付け、
前記プロセッサは、前記受け付けられた前記リクエスト又はデータのタイプに基づいて、前記受け付けられた前記リクエスト又はデータの処理先を、前記リクエスト又はデータのタイプに応じた処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能のいずれかに切り替え、
前記プロセッサは、前記切り替えられた永続化機能により、前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する、
データ処理方法。
【請求項１０】
請求項１乃至８のいずれか１項に記載のデータ処理システムの前記各処理として前記プロセッサを機能させるデータ処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、データ処理システム、方法およびプログラムに関する。
【背景技術】
【０００２】
oneM2M（水平統合型のIoT（Inter-net of Things）プラットフォームの標準化を進めるために開始されたパートナーシッププロジェクト）で標準化されているoneM2Mアーキテクチャ、およびoneM2Mの前身であるETSI（European Telecommunication Standards Institute） TC M2M標準がある（例えば、非特許文献１、２、３、４、５又は６を参照）。【０００３】
oneM2Mでは、CSE（Common Services Entity）と呼ばれる共通機能群（Common Services Function）に対し、アプリケーションプログラム（以下、アプリケーションと称することがある）が、mcaと呼ばれるインタフェース（CSE-AE（Application Entity）間のインタフェース）を介して接続される。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】oneM2M Web Site、http://www.onem2m.org/
【非特許文献２】oneM2M Specification TS-0001 version 2.10.0
【非特許文献３】oneM2M Specification TS-0004 version 2.7.1
【非特許文献４】水平統合型IoTプラットフォーム標準規格 oneM2Mの最新動向,NTT技術ジャーナル  2018.2, p69-72、http://www.ntt.co.jp/journal/1802/files/JN20180269.pdf
【非特許文献５】ARIB・TTC共催セミナー 「IoT標準化最新動向 〜oneM2M技術仕様リリース2の全貌〜」、http://www.ttc.or.jp/j/info/seminar/history/rep20160909/download20160909/
【非特許文献６】OM2M、http://www.eclipse.org/om2m/
【発明の概要】
【発明が解決しようとする課題】
【０００５】
oneM2Mでは、さまざまなIoTデータを、CSEの内部のリソースの一種である<ContentInstance>（データを貯めるコンテナの働きをする〈container〉の直下に生成され、データを格納する）、<TimeSerieseInstance>（時系列データの欠損を検出する〈timeSeries〉の直下に生成され、データ生成時間を属性として保持する）中にデータをまとめて格納する方式が用いられる。【０００６】
通常のアプリケーションは、mcaを通じてリソースのURI（Uniform Resource Identifier）を指定してデータを取り出して演算などの加工を行なう。ここでは、アプリケーションは、大量のデータをネットワークプロトコル経由で取得するので、CSEおよびアプリケーションをそれぞれ格納する計算機の計算資源を多く消費し、結果を得るまでに多くの時間を要するという課題がある（課題（Ｋ１））。【０００７】
また、統計計算などに頻出する計算が必要であっても、通常では、この計算する機能をアプリケーションの内部に実装する必要があり、実装の工数が増えてしまう課題もある（課題（Ｋ２））。【０００８】
また、このような中身に関知しないシステムでは、データに効果的なインデックスを設定することが困難であり、そのために、より一層の処理時間が必要になるという課題もある（課題（Ｋ８））。【０００９】
図１０は、従来のデータ処理システムの構成例を示す図である。  
図１０に示すように、従来のデータ処理システムでは、ノード（Node）１１０内にＣＳＥ１２０、ＤＢＭＳ（Data Base Management System）１３０が設けられる。ＣＳＥ１２０は、リクエスト受付部１２１、リソース処理部１２２、永続化処理部１２３を有する。永続化とは、プログラムの終了後も、データが失われない場所にデータが保存される処理である。【００１０】
リクエスト受付部１２１は、データ観測デバイスなどのデバイスからのデータ、又は第１アプリケーション（変換アプリケーション）、第２アプリケーション（統計アプリケーション）からのリクエストをそれぞれ受け付ける。  
リソース処理部１２２は、containerリソース（データをためるコンテナの働きをする）に対応する第１コンテナ１２２ａ、および第２コンテナ１２２ｂを有する。【００１１】
永続化処理部１２３は、リクエスト受付部１２１により受け付けられて第１コンテナ１２２ａ、第２コンテナ１２２ｂに格納されたデータに対する所定の処理を行なって、処理結果をＤＢＭＳ１３０に渡す。【００１２】
また、永続化処理部１２３は、第１コンテナ１２２ａ、第２コンテナ１２２ｂに予め格納されたデータに対する、リクエスト受付部１２１により受け付けられたリクエストに応じた所定の処理を行なって、処理結果をＤＢＭＳ１３０に渡す。  
ＤＢＭＳ１３０は、永続化処理部１２３から渡されたデータを内部のデータテーブル１３１または１３２に永続的に格納する。この例では、第１コンテナ１２２ａから永続化処理部１２３を経由して渡されたデータはデータテーブル１３１に格納され、第２コンテナ１２２ｂから永続化処理部１２３を経由して渡されたデータはデータテーブル１３２に格納される。【００１３】
実質的に複数の論理的なデータが一つの物理データの内部に格納されるようなデータが、デバイスから送られてくる場合がある。この際に用いられる典型的な手法としては、図１０に示すように、第１コンテナ１２２ａに格納されるデータを第１アプリケーションが取り出して個々の論理的なデータに分離して第２コンテナ１２２ｂに格納する。そして、データに対する統計計算を行なう第２アプリケーションが第２コンテナ１２２ｂにアクセスしてデータを取り出す。【００１４】
この手法においては、まず、第１アプリケーションを作成するための工数が必要となり（課題（Ｋ３））、この第１アプリケーションを動作させるための計算資源も必要となる（課題（Ｋ４））。  
また、第１アプリケーションを動作させるときの時間がデータ処理システム全体の遅延時間となる（課題（Ｋ５））。つまり、第１コンテナ１２２ａにデータが入れられたタイミングから第２コンテナ１２２ｂにデータが格納できるタイミングまでの間に差が生じる。このため、時間にセンシティブなIoTアプリケーションには適用できなくなる課題に繋がる（課題（Ｋ６））。【００１５】
さらに、第１コンテナ１２２ａと第２コンテナ１２２ｂとにおいて、フォーマットは異なるものの、意味的には同一のデータがＤＢＭＳ１３０に格納されるので、同一のデータに対するストレージ領域を多く消費してしまうという課題もある（課題（Ｋ１０））。【００１６】
第２コンテナ１２２ｂに格納されるデータのうち、アクセスできる権限がデータごとに異なる場合がある。oneM2Mでは、インスタンスごとにアクセスコントロールポリシー（accessControlPolicyリソース（アクセス制御のためのポリシー）に対応）を設定することもできるが、このためには、設定のためのリソースを生成したり参照したりする必要が生じ、アプリケーションプログラムの複雑性が増すとともに、処理時間が増加する課題もある（課題（Ｋ７））。【００１７】
この発明は上記事情に着目してなされたもので、その目的とするところは、効率的なデータ処理を行なうことができるようにしたデータ処理システム、方法およびプログラムを提供することにある。
【課題を解決するための手段】
【００１８】
上記目的を達成するために、この発明の一実施形態に係るデータ処理システムの第１の態様は、データ処理システムが、１以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続されるデータ処理システムであって、プロセッサを有し、前記プロセッサは、前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付ける受付処理を行ない、前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能を有し、前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じた処理を前記永続化機能により行なって、その処理結果を前記データベースに永続的に格納する永続化処理を行ない、前記受付処理により受け付けられた前記リクエスト又はデータのタイプに基づいて、前記受付処理により受け付けられた前記リクエスト又はデータの処理先を前記複数種類の永続化機能のいずれかに切り替える切替処理を行なう、ように構成される。【００１９】
この発明のデータ処理システムの第２の態様は、第１の態様において、前記プロセッサは、前記受付処理として、前記デバイスからのデータを受け付け、前記永続化処理として、前記受付処理により受け付けられた単一のデータが、複数の論理データからなる物理データであるときに、前記単一のデータを論理データごとに分離して、前記分離された物理データを前記処理結果として前記データベースに格納する、ように構成される。【００２０】
この発明のデータ処理システムの第３の態様は、第２の態様において、前記プロセッサは、前記永続化処理として、前記受付処理により受け付けられた前記単一のデータに通し番号を付与したデータと、前記分離された物理データの各々に前記分離する前のデータに付与された通し番号と同じ通し番号を付与した物理データとを前記データベースにそれぞれ格納する、ように構成される。【００２１】
この発明のデータ処理システムの第４の態様は、第１の態様において、前記プロセッサは、前記受付処理として、前記デバイスからのデータを受け付け、前記永続化処理として、前記受付処理により受け付けられたデータが、相互に関連付けられた複数種類のデータからなるときに、前記複数種類のデータを種類ごとに分離して、前記分離されたデータを前記データベースに格納する、ように構成される。【００２２】
この発明のデータ処理システムの第５の態様は、第１の態様において、前記プロセッサは、前記永続化処理としては、前記データベースに格納されたデータを読み出して、前記アプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される。【００２３】
この発明のデータ処理システムの第６の態様は、第５の態様において、前記プロセッサは、前記永続化処理として、前記データベースに格納されたデータを読み出して、前記読み出されたデータのうち第１のデータを、第１のアプリケーションプログラムによりアクセス可能なデータとして設定し、前記読み出されたデータのうち第２のデータを、第２のアプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される。【００２４】
この発明のデータ処理システムの第７の態様は、第１の態様において、前記永続化処理として、ネットワークインタフェースを介して前記デバイスと異なる第２のデバイスとの間で通信をさらに行ない、前記受付処理より第１の通信プロトコルで受け付けられた前記リクエストに基づき、前記第２のデバイスとの間で前記第１の通信プロトコルと異なる第２のプロトコルを用いて情報の送受信を行なう、ように構成される。【００２５】
この発明のデータ処理システムの第８の態様は、第７の態様において、前記永続化処理により前記第２のデバイスから取得された情報を記憶する記憶装置をさらに有し、前記プロセッサは、前記受付処理より第１の通信プロトコルで受け付けられた、前記第２のデバイスから情報を取得するリクエストに基づき、前記第２のデバイスから取得した情報を前記記憶装置に記憶し、前記受付処理より第１の通信プロトコルで受け付けられたリクエストに基づき、前記リクエストで示される、取得対象の情報が前記記憶装置に記憶される場合は、この情報を前記記憶装置から読み出す、ように構成される。【００２６】
本発明の一実施形態に係るデータ処理方法の一つの態様は、１以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続され、プロセッサを具備するデータ処理システムが行なうデータ処理方法であって、前記プロセッサは、前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付け、前記プロセッサは、前記受け付けられた前記リクエスト又はデータのタイプに基づいて、前記受け付けられた前記リクエスト又はデータの処理先を、前記リクエスト又はデータのタイプに応じた処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能のいずれかに切り替え、前記プロセッサは、前記切り替えられた永続化機能により、前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納するようにしたものである。【００２７】
本発明の一実施形態におけるデータ処理プログラムの一つの態様は、第１乃至第７の態様のいずれか１つにおけるデータ処理システムの前記各処理として前記プロセッサを機能させるものである。
【発明の効果】
【００２８】
この発明の一実施形態に係るデータ処理システムの第１の態様によれば、外部からのリクエスト又はデータのタイプに応じたデータ処理が行われ、その処理結果のデータがデータベースに永続的に格納される。このため、受け付けたリクエスト又はデータのタイプに応じた効率的なデータ処理を行なうことができる。【００２９】
この発明の一実施形態に係るデータ処理システムの第２の態様によれば、単一のデータが論理データごとに分離されて、分離されたデータがデータベースに格納されるので、論理データごとにデータ処理を行なうことができる。【００３０】
この発明の一実施形態に係るデータ処理システムの第３の態様によれば、分離前のデータと分離後のデータに共通した通し番号が付与されるので、分離前のデータを再取得した時の高速なレスポンスを実現でき、元のデータの再現性を向上させることができる。【００３１】
この発明の一実施形態に係るデータ処理システムの第４の態様によれば、複数種類のデータが関連付けられてなるときに、複数種類のデータが個別のデータに分離されて、分離された個別のデータがデータベースに格納されるので、データの種類ごとに処理を行なうことができる。【００３２】
この発明の一実施形態に係るデータ処理システムの第５の態様によれば、データベースに格納されたデータがアプリケーションプログラムによりアクセス可能なデータとして設定されるので、アプリケーションプログラムによりアクセス可能なデータを生成するための別のアプリケーションプログラムが不要となる。【００３３】
この発明の一実施形態に係るデータ処理システムの第６の態様によれば、格納されたデータが区分され、区分ごとに異なるアプリケーションプログラムによるアクセスが可能になる。このため、データのアクセスコントロールポリシーの数を少なくすることができる。【００３４】
この発明の一実施形態に係るデータ処理システムの第７の態様によれば、受付処理より第１の通信プロトコルで受け付けられたリクエストに基づき、第２のデバイスとの間で第１の通信プロトコルと異なる第２のプロトコルを用いて情報の送受信を行なうので、リクエストでの通信プロトコルと異なるプロトコル上のデバイスから動的にデータを取得できるため、このデータの処理においてシステム上の資源を多く使用することがなく、取得されたデータをアプリケーションプログラムが利用するときのラグ時間を短縮できる。【００３５】
この発明の一実施形態に係るデータ処理システムの第８の態様によれば、第２のデバイスから取得した情報を記憶装置に記憶し、リクエストで示される、取得対象の情報が記憶装置に記憶される場合は、この情報を記憶装置から読み出すので、取得対象の情報の取得を効率的に行なうことができる。【００３６】
すなわち、この発明の各態様によれば、効率的なデータ処理を行なうことが可能になる。
【図面の簡単な説明】
【００３７】
【図１】図１は、本発明の第１の実施形態に係るデータ処理システムの構成例を示す図である。
【図２Ａ】図２Ａは、従来のデータ処理システムの機能構成と、本発明の一実施形態に係るデータ処理システムの機能構成との対比について説明する図である。
【図２Ｂ】図２Ｂは、従来のデータ処理システムの機能構成と、本発明の一実施形態に係るデータ処理システムの機能構成との対比について説明する図である。
【図３】図３は、本発明の第１の実施形態に係るデータ処理システムの切替部による処理動作の一例を示すフローチャートである。
【図４】図４は、本発明の第１の実施形態に係るデータ処理システムがＤＢＭＳに格納するデータの一例を表形式で示す図である。
【図５】図５は、本発明の第１の実施形態に係るデータ処理システムが、内部構造を有するデータをＤＢＭＳに格納するデータの一例を表形式で示す図である。
【図６】図６は、本発明の第１の実施形態に係るデータ処理システムが、内部構造を有する論理的なデータを含むデータをＤＢＭＳに格納するデータの一例を表形式で示す図である。
【図７】図７は、本発明の第１の実施形態に係るデータ処理システムのＤＢＭＳに格納される分離前データ用テーブルの一例を表形式で示す図である。
【図８】図８は、本発明の第１の実施形態に係るデータ処理システムのＤＢＭＳに格納される分離後データ用テーブルの一例を表形式で示す図である。
【図９】図９は、本発明の第１の実施形態に係るデータ処理システムの第２コンテナに格納されるデータの一例を表形式で示す図である。
【図１０】図１０は、従来のデータ処理システムの構成例を示す図である。
【図１１】図１１は、oneM2Mの典型的なInterworking手法の一例を示す図である。
【図１２】図１２は、本発明の第２の実施形態に係るデータ処理システムの機能構成の一例を示す図である。
【図１３】図１３は、永続化機能部のlist（）が呼び出されたときの処理動作の一例を示す図である。
【図１４】図１４は、永続化機能部のgetResource（）が呼び出されたときの処理動作の一例を示す図である。
【図１５】図１５は、永続化機能部のupdateResource（）が呼び出されたときの処理動作の一例を示す図である。
【図１６】図１６は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュがあるときの処理動作の一例を示す図である。
【図１７】図１７は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュ、属性値キャッシュがあるときの処理動作の第１の例を示す図である。
【図１８】図１８は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュ、属性値キャッシュがあるときの処理動作の第２の例を示す図である。
【発明を実施するための形態】
【００３８】
以下、図面を参照しながら、この発明に係わる一実施形態を説明する。  
（第１の実施形態）
まず、本発明の第１の実施形態について説明する。  
図１は、本発明の第１の実施形態に係るデータ処理システムの構成例を示す図である。  
本発明の第１の実施形態に係るデータ処理システムは、１以上のアプリケーションプログラムと複数のデバイスとがデータベースと通信ネットワークを介して接続されるデータ処理システムであって、図１に示すように、ノード１０内にＣＳＥ（データ処理装置）２０、ＤＢＭＳ３０が設けられる。ＣＳＥ２０は、リクエスト受付部２１、リソース処理部２２、永続化処理部２３を有する。各部の詳細については後述する。図１ではデバイスとしてデータ観測デバイスのみを示している。
【００３９】
また、ノード１０内のＣＳＥ２０は、パーソナルコンピュータ（ＰＣ）などのコンピュータデバイスを用いたシステムにより実現可能である。例えば、コンピュータデバイスは、ＣＰＵ（Central Processing Unit）などのプロセッサと、プロセッサに接続されるメモリと、入出力インタフェースとを備える。このうちメモリは、不揮発性メモリなどの記憶媒体を有する記憶装置により構成される。
【００４０】
ＣＳＥ２０のリクエスト受付部２１、永続化処理部２３の機能は、例えば、プロセッサがメモリに格納されているプログラムを読み出して実行することにより実現される。なお、これらの機能の一部又は全部は、特定用途向け集積回路（ＡＳＩＣ）などの回路によって実現されてもよい。  
リソース処理部２２は、上記メモリのうち随時の書込および読み出しが可能な不揮発性メモリに設けられる。
【００４１】
リクエスト受付部２１は、データ観測デバイスなどのデバイスからのデータ、又はアプリケーション（統計アプリケーションなど）からのリクエストをそれぞれ受け付ける。  
リソース処理部２２は、containerリソースに対応する第１コンテナ２２ａ、第２コンテナ２２ｂを有する。
【００４２】
永続化処理部２３は、リクエスト受付部２１により受け付けられて第１コンテナ２２ａに格納されたデータに対する所定の処理を行なって、処理結果をＤＢＭＳ３０に渡す。
【００４３】
また、永続化処理部２３は、第２コンテナ２２ｂに予め格納されたデータに対する、リクエスト受付部２１により受け付けられたリクエストに応じた所定の処理を行なって、処理結果をＤＢＭＳ３０に渡す。  
ＤＢＭＳ３０は、永続化処理部２３から渡された処理結果であるデータを内部のデータテーブルに永続的に格納する。
【００４４】
また、永続化処理部２３は、切替部２３ａ、第１永続化機能部２３ｂ１、第２永続化機能部２３ｂ２、第３永続化機能部２３ｂ３を有する。ここでは、永続化処理部は３種類の永続化機能部を有する例を説明するが、この数は特に限られない。
【００４５】
永続化処理部２３内の各種永続化機能部は、データのタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じて設けられる。これらの永続化機能部は、リクエスト受付部２１により受け付けられたデータのタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じた処理を行なって、処理結果をＤＢＭＳ３０に永続的に格納する。
【００４６】
永続化処理部２３内の切替部２３ａは、リクエスト受付部２１により受け付けられたデータのタイプ、およびリソースツリー上のURIを認識し、このデータの出力先、つまりデータの処理先を、永続化処理部２３内の各種永続化機能部のうち、認識したタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じた永続化機能部に切り替える。この切り替えでは、永続化処理部２３内の複数種類の永続化機能部のうち、データの処理先として有効である１つの永続化機能部が選択される。
【００４７】
また、永続化処理部２３内の各種永続化機能部は、リクエストのタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じて設けられる。これらの永続化機能部は、第２コンテナ２２ｂに予め格納されたデータに対する、リクエスト受付部２１により受け付けられたリクエストのタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じた処理を行なって、その処理結果をＤＢＭＳ３０に永続的に格納する。
【００４８】
永続化処理部２３内の切替部２３ａは、リクエスト受付部２１により受け付けられたリクエストのタイプ、およびリソースツリー上のURIの場所を認識し、このリクエストの出力先、つまりデータの処理先を、永続化処理部２３内の各種永続化機能部のうち、認識したタイプ、およびリソースツリー上のURIの場所の一方または組み合わせに応じた永続化機能部に切り替える。
【００４９】
本発明の第１の実施形態により実現できる構成の一例を説明する。ここでは、以下の（Ｓ１）〜（Ｓ９）および（ＳＢ１）を実現することについて説明する。  
（Ｓ１）
oneM2MのＣＳＥ内部の永続化処理部内に複数種類の永続化機能部をプラグインできるようにする。  
（Ｓ１）では、共通のインタフェースを実装するクラスとして永続化機能部を実現することで、動的に機能を呼び出すことが、様々なプログラム言語(Java（登録商標）, C++, ruby, python等)で可能である。
【００５０】
ここで、永続化機能部のinterfaceとしては例えば次の例のように(LIST1)までの記載で表すことができる。
【００５１】
（interfaceの例）
Interface PersistenceLayer {
void create( String uri, Resource r );
Resource retrieve(String uri);
void update( String uri, Resource r );
void delete(String uri);
}
(LIST1)
ここで、Resourceクラスは、各々の具体的なResourceクラスのスーパクラスである。各具体的なクラスはJavaBeanのようなクラスで実現できる。つまり、具体的なクラスは、取得メソッドと設定メソッドとをそれぞれ有するようなオブジェクトである。また、別の形態では、具体的なクラスは、publicなfieldを有するようなシンプルなオブジェクトであってもよく、また、JSONを表現するようなオブジェクトであってもよい。
【００５２】
（Ｓ１−１）
上記のプラグインは、開発者が要件に応じて作ることができ、同時に複数種類の永続化機能部が同一のＣＳＥ２０の内部で使用されることができる。
【００５３】
次に、上記の、create, retrieve, update, deleteメソッドを実装して、データを適切な粒度に分解して、バックエンドのＤＢＭＳ３０に格納する機能を実現するコードについて説明する。
【００５４】
このコードは、例えば、以下のように論理的なデータ単位に分離されてＤＢＭＳ３０に格納されることができる。
【００５５】
（コードの例）
MyEizokuka {
void create(uri, Resource r){
String con = r.getCon();
String[] data = con.split(“,”);
for(String item: data ){
Resource r2 = new ContentInstance();
R2.con = item;
DB.store(r2 );
}
}
…
}
上記のコードの例では、create(作成)に係るコードについて記載したが、retrieve(データ内容取得), update(データ更新), delete(削除)に係るコードについても、ＤＢＭＳ３０に格納できる。
【００５６】
（Ｓ１−２）
上記の永続化機能部の名称を割り当てる設定ファイルを、リソースのタイプと、リソースツリー上のURIの場所との一方または組み合わせに基づいて用意して、ＣＳＥ２０内の図示しない内部メモリに格納する。  
例えば、次のような設定ファイルを用意することができる。
【００５７】
（設定ファイルの例）
<rules>
<rule>
<name>rule1</name>
<uri>/a/b/c</uri>
<resourceTypes>
<resourceType>4</resourceType>
<resourceType>5</resourceType>
</resourceTypes>
<driver>jp.co.ntt.onem2m.MyEizokuka1</driver>
</rule>
<rule>
<name>rule2</name>
<uri>/a/b/d </uri>
<resourceTypes> 
<resourceType>4</resourceType>
<resourceType>5</resourceType>
</resourceTypes>
<driver>jp.co.ntt.onem2m.MyEizokuka2</driver>
</rule>
<rule>
<name>rule3</name>
<uri>*</uri>
<resourceTypes>
<resourceType>10</resourceType>
</resourceTypes>
<driver>jp.co.ntt.onem2m.MyEizokuka3</driver>
</rule>
この設定ファイル中で、「＊」は任意のURIに該当することを意味する。設定ファイル中のDriverタグの内部には、上記の各種永続化機能部に対応する名称が記載される。例えば、Driverタグ内の「MyEizokuka1」、「MyEizokuka2」、「MyEizokuka3」は、上記の永続化処理部２３内の第１永続化機能部２３ｂ１、第２永続化機能部２３ｂ２、第３永続化機能部２３ｂ３にそれぞれ対応する名称とすることができる。
【００５８】
（Ｓ１−３）
永続化処理部は、切替部を設ける。この切替部は、設定ファイルを読み込んで、必要なリクエストに対する処理先である永続化機能部を切り替える。
【００５９】
図２Ａ、図２Ｂは、従来のデータ処理システムの機能構成と、本発明の第１の実施形態に係るデータ処理システムの機能構成との対比について説明する図である。図２Ａは、従来のデータ処理システムに対応し、図２Ｂは、本発明の第１の実施形態に係るデータ処理システムに対応する。
【００６０】
図２Ｂに示すように、本発明の第１の実施形態では、従来例の永続化処理部１２３と異なり、永続化処理部２３中に切替部２３ａと、各種永続化機能部２３ｂ１，２３ｂ２，２３ｂ３とをそれぞれ有する。この切替部２３ａは、上部のリクエストの中のuriとresourceTypeを、設定ファイルで指定された永続化機能部に振り分ける。
【００６１】
図３は、本発明の第１の実施形態に係るデータ処理システムの切替部による処理動作の一例を示すフローチャートである。  
初回の実行時には、永続化処理部２３の切替部２３ａは、ＣＳＥ２０から設定ファイルを読み込む（Ｓ１１→Ｓ１２）。切替部２３ａは、リクエストの中のuri、resourceTypeが、設定ファイルに登録されているルールの１つにマッチングするときは（Ｓ１３のＹｅｓ）、マッチングするルールのdriverタグに記載された名称に対応する永続化機能部を永続化処理部２３内の複数種類の永続化機能部２３ｂ１，２３ｂ２，２３ｂ３の中から特定する。この特定された永続化機能部に対応するdriverのクラスが未インスタンス化である場合には（Ｓ１４のＮｏ）、切替部２３ａは、このクラスをインスタンス化して（Ｓ１５）、上記のマッチングするルールのdriverを呼び出す（Ｓ１６）。上記特定された永続化機能部に対応するdriverのクラスがインスタンス化されている場合（Ｓ１４のＹｅｓ）は、切替部２３ａは、上記のマッチングするルールのdriverを呼び出す（Ｓ１６）。
【００６２】
呼び出されるdriverのパラメータは、切替部のパラメータと同様のものが用いられる。  
また、切替部のdriverのクラスは、永続化機能部のインタフェースである上記の(LIST1)に示すクラスと同様でよい。
【００６３】
（永続化機能部の構成方法）
（Ｓ２）
永続化処理部２３内の複数種類の永続化機能部のうち一つは、リソース処理部２２から単一のデータを渡される。図１に示した例では、複数種類の永続化機能部は、第１永続化機能部２３ｂ１、第２永続化機能部２３ｂ２、第３永続化機能部２３ｂ３である。上記のように単一のデータを渡された際に、このデータに複数の論理上のデータが含まれている、つまり渡されたデータが複数の論理データでなる物理データである場合には、上記複数種類の永続化機能部のうち一つは、渡されたデータを論理データごとに分離して、この分離された物理データを処理結果としてＤＢＭＳ３０に格納する。
【００６４】
例えば、入力データに複数の論理上のデータがカンマ区切りで格納されている場合について説明する。  
図４は、本発明の第１の実施形態に係るデータ処理システムがＤＢＭＳに格納するデータの一例を表形式で示す図である。図４では、列の属性として、OriginalSeq、DestinationSeq、content、resourceName、その他データなどを有し、リソースのContentInstanceのcontentに“10, 20, 11, 22, 33”が入っている例について説明する。
【００６５】
図４に示した例では、論理的なデータとしては５個のデータが１つの物理データに包含されているので、第１永続化機能部２３ｂ１は、これらのデータを個別のデータに分離してＤＢＭＳ３０に格納する。この際に、これらの論理的なデータは同一の物理データに包含されていたので、図４に示したデータにおけるOriginalSeqには、共通する「１」が設定される。図４に示したデータにおけるDestinationSeqとしては連番の「１」から「５」が設定される。
【００６６】
次に、入力データとして、“5, 6, 7”という３個の論理的なデータが２つ目の物理データとして第１永続化機能部２３ｂ１に到着した場合は、図４に示したデータにおけるOriginalSeqの列には、上記の「１」に１を加えた「２」が付与される。
【００６７】
また、oneM2Mのリソースにはcontent以外の属性も含まれている。例えば属性「resourceName」は名前を意味する属性であり、resource内に含まれている。その他データもあるが、詳細の説明は省略する。
【００６８】
また、特定のresourceNameに対応するデータの取得リクエストがリクエスト受付部２１により受け付けられた場合は、永続化処理部２３は、ＤＢＭＳ３０に格納されるレコードのうち、特定のresourceNameに該当するレコードをDestinationSeqの昇順に連結してリクエスト元に返却する。
【００６９】
（Ｓ３）
永続化処理部２３内の複数種類の永続化機能部のうち１つは、リソース処理部２２から切替部２３ａを介して入力データを渡された際に、このデータが、１つの論理上のデータの内部に内部構造を有するデータである場合には、当該データを、この内部構造に応じた、ＤＢＭＳ３０に格納されるデータベースのスキーマに格納するように構成される。
【００７０】
例えば、入力データが、x,yの２種類であるデータがカンマ区切りで相互に関連付けられた複数種類のデータでなる場合について説明する。これら相互に関連付けられた複数種類のデータは、x軸上およびy軸上の位置であったり、加速度であったりする。例えば、最初に、”10,5”という１つ目の物理データ、次に”9,6”という2つ目の物理データがリソース処理部２２から永続化処理部２３に届いたとする。すると、永続化処理部２３は、上記のカンマ区切りのデータをｘ,ｙに応じて種類ごとに、ここでは２つに分離し、この分離したデータの値をx,yのカラムにそれぞれ挿入する。  
図５は、本発明の第１の実施形態に係るデータ処理システムが、内部構造を有するデータをＤＢＭＳに格納するデータの一例を表形式で示す図である。図５では、列の属性として、OriginalSeq、X、Y、resourceName、その他データなどを有する。  
また、resourceNameとしてData1に対して取得要求がリクエスト受付部２１により受け付けられた場合は、永続化処理部２３は、該当するレコードのx列、y列を連結してリクエスト元に返却する。
【００７１】
（Ｓ４）
Ｓ４では、入力データに”x1,y1,x2,y2,x3,y3”という形式でデータが入っている場合について説明する。つまり、内部構造を有する論理的な複数のデータが連結されて一つの物理データとしてリソース処理部２２から永続化処理部２３に渡される場合である。
【００７２】
ここでは、上記の”x1,y1,x2,y2,x3,y3”との入力データのうち、内部構造を有する１つ目の論理的なデータは”x1,y1”というデータであり、内部構造を有する２つ目の論理的なデータは”x2,y2”というデータであり、内部構造を有する３つ目の論理的なデータは”x3,y3”というデータである。
【００７３】
ここで、”10,7,9,6,8,5”との入力データであって３つの論理的なデータ（”10,7”、”9,6”、”8,5”）を含む１つ目の物理データ、および”7,4”との１つの論理的なデータを含む２つ目の物理データがリソース処理部２２から永続化処理部２３にそれぞれ渡された場合で説明する。
【００７４】
図６は、本発明の第１の実施形態に係るデータ処理システムが、内部構造を有する論理的なデータを含むデータをＤＢＭＳに格納するデータの一例を表形式で示す図である。図６では、列の属性として、OriginalSeq、DestinationSeq、X、Y、resourceName、その他データなどを有する。
【００７５】
（Ｓ５）
上記の（Ｓ２）、（Ｓ４）では、永続化処理部２３による変換（分離）後のデータのみがＤＢＭＳ３０に格納される例を説明したが、（Ｓ５）では、永続化処理部２３が、変換前、つまり入力データの値の分離前のデータ、および変換後、つまり入力データの値の分離後のデータをＤＢＭＳ３０にそれぞれ格納する例について説明する。
【００７６】
図７は、本発明の第１の実施形態に係るデータ処理システムのＤＢＭＳに格納される分離前データ用テーブルの一例を表形式で示す図である。図７に示したデータは、列の属性として、OriginalSeq、con、resourceName、その他データなどを有する。
【００７７】
図８は、本発明の第１の実施形態に係るデータ処理システムのＤＢＭＳに格納される分離後データ用テーブルの一例を表形式で示す図である。図８に示したデータは、列の属性として、OriginalSeq、DestinationSeq、X、Yを有する。
【００７８】
ここでは、入力データを図７に示す「分離前データ用テーブル」、および図８に示す「分離後データ用テーブル」でなる２つのテーブルにそれぞれ格納する例を説明する。  
ここでは、分離前のデータは「分離前データ用テーブル」に格納される。図７に示した例では、各行に１つの物理データが格納される。図８に示した例では、物理データを分離したデータが個別の行に格納される。また、分離前データ用テーブルにおける「con」の列の値を「分離後データ用テーブル」における「X」、「Y」の列の各行に分離して記載する。「分離後データ用テーブル」のカラムOriginalSeqは外部参照キーであり、「分離前データ用テーブル」の同名のカラムを参照する。
【００７９】
図７、８に示した例では、分離前の１つの物理データ「10,7,9,6,8,5」が格納されるデータにはOriginalSeq「１」が付与され、このデータが分離されてなる１つ目の論理データ「10,7」、２つ目の論理データ「9,6」、３つ目の論理データ「8,5」には分離前のデータに付与されていたOriginalSeq「１」が共通して付与される。
【００８０】
本実施形態では、永続化処理部２３は、分離前に受け付けられた単一のデータにデータごとの通し番号であるOriginalSeqを付与したデータと、当該単一のデータを分離した個別の物理データの各々に対し分離する前のデータに付与された通し番号OriginalSeqを付与した物理データとをＤＢＭＳ３０にそれぞれ格納することができる。
【００８１】
このようにすることで、元のcontainerに格納されるデータが再取得された際には、連結などの操作が不要なので、高速なレスポンスが期待できる。また、連結のロジックの設定が不要となり、元の入力データの再現性が高まる。
【００８２】
これは、元の入力データ中の小数点以下の表示桁数が変化したり、元データ中のスペースなどが省略されたりする場合があったとしても、正確に元のデータを返却できる。  
一方で、ＤＢＭＳ３０の記憶容量を多く消費してしまう。ただし、resourceName又はその他データの属性などを重複して保持する必要がないという点は有利である。
【００８３】
（Ｓ６）
第２コンテナ２２ｂに格納されるデータに対する、アプリケーションからのリクエストに応じた処理のために、永続化処理部２３内の、第１永続化機能部２３ｂ１、第２永続化機能部２３ｂ２、第３永続化機能部２３ｂ３のうち、アプリケーションからのリクエストのタイプ・リソースツリー上のURIの場所の一方または組み合わせに応じて切替部２３ａにより切り替えられた永続化機能部は、処理対象である１つの論理的なデータを第２コンテナ２２ｂにマッピングして、リクエスト元のアプリケーションがリクエストによる処理対象のデータの特定のためのアクセス可能なデータとして公開する。
【００８４】
ここでは図４に示した格納データを用いて説明する。  
切替部２３ａにより切り替えられた永続化機能部は、図４に示したデータの各行をリソース処理部２２が管理するリソースであるContentInstanceにマッピングして渡す。この永続化機能部は、データの読み込み専用の運用とする。
【００８５】
（Ｓ７）
切替部２３ａにより切り替えられた永続化機能部は、データの特定のフィールドを参照することで、第２コンテナ２２ｂにおけるマッピング先のコンテナを変更する。
【００８６】
図９は、本発明の第１の実施形態に係るデータ処理システムの第２コンテナに格納されるデータの一例を表形式で示す図である。図９に示したデータは、列の属性として、OriginalSeq、DestinationSeq、X、Y、Data Owner、resourceName、その他データなどを有する。
【００８７】
上記の（Ｓ６）では、切替部２３ａにより切り替えられた永続化機能部は、図４に示したデータ各行を第２コンテナ２２ｂにおける唯一のコンテナにマッピングしたが、（Ｓ７）では、切替部２３ａにより切り替えられた永続化機能部は、例えば、図９に示すData Owner列の値を参照して、この値に応じたコンテナにのみデータを参照させる。
【００８８】
つまり、第２コンテナ２２ｂにおけるContainer Aからは、DestinationSeqが、「１、２、３」であるデータのみが見え、第２コンテナ２２ｂにおけるContainer Bからは、DestinationSeqが「４」であるデータのみが見えるようにできる。
【００８９】
このようにすることができれば、データに対するアクセスコントロールポリシーを容易に設定できるというメリットが生じる。つまり、Container Aには、このContainer Aに係る権限を有するアプリケーションにアクセスを許し、Container Bには、このContainer Bに係る権限を有するアプリケーションにアクセスを許すという２つのアクセスコントロールポリシーを作成するだけで、期待されるアクセス制御を実現できる。
【００９０】
従来の図１０に示した構成では、図９に示したデータの例では、各行についてアクセスコントロールポリシーを設定する必要があるので、４つのアクセスコントロールポリシーの設定が必要である。データ量がさらに増えると、設定する数の差がさらに大きくなることは明白である。
【００９１】
（Ｓ８）
ＤＢＭＳ３０は、ＲＤＢ（Relational database）などのように内部の統計計算などの演算機能を有したデータベースで構成し、アプリケーションから、このデータベースへのアクセスを可能とする構成とする。
【００９２】
図１に示すように、統計アプリケーションＢからＤＢＭＳ３０へのアクセスが許可されており、ＤＢＭＳ３０がＲＤＢである場合では、ＳＱＬ言語を用いて統計アプリケーションＢへの処理用リクエストを行なうことができる。他の種類データベースの場合でも、同様の言語であるクエリ言語を用いてＤＢＭＳ３０へアクセスすることができる。これにより、統計アプリケーションＢは、ＤＢＭＳ３０が有するSQL言語を用いて統計計算を実施することができる。
【００９３】
これにより、従来技術と比較してＤＢＭＳ３０とＣＳＥ２０との間でデータを転送しなくて済むため、高速な演算処理が実施できる。また、ＤＢＭＳ３０が有する統計関数などの演算機能を利用できるため、解析プログラム中に該当機能のロジックを設計する必要がなく、開発工数を低減できる。
【００９４】
（Ｓ９）
ＤＢＭＳ３０内のデータベースに、データの意味に則したスキーマのテーブルを設定する。これにより、頻出する検索に対するインデックスを容易に生成できる。
【００９５】
（ＳＢ１）
データの定義、スキーマを読み込んで、永続化機能部とデータベース中のテーブルを実行時に生成する。
【００９６】
上記では、永続化機能部は、想定するデータ、データベースのスキーマに応じて開発者が作成することを前提としていた。  
これに対し（ＳＢ１）では、永続化機能部は、データ形式のメタ情報から、データベースのスキーマおよび変換プログラムを生成する。
【００９７】
メタデータには、例えばXSD（XML Schema Definition）のようなものがあり、次のような定義が可能である。  
永続化機能部は、メタデータを利用して、内部に含まれるデータと、その名称(ValueA, ValueB)、型情報(文字列（string）、真偽値（boolean）)を取得することができる。永続化機能部は、この取得結果からテーブルを容易に生成でき、また、元のデータから上記のテーブルに挿入するプログラムを生成することが可能である。
【００９８】
（メタデータの定義の例）
<xs:element name="MyData" >
<xs:complexType>
<xs:sequence>
<xs:element name="ValueA" type="xs:string" />
<xs:element name="ValueB" type="xs:boolean" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:element>
このようなファイルを読み込ませると同時に、永続化機能部を本機能で作成することが可能である。
【００９９】
以下、上記の課題を解決したときの効果（ＢはBenefitの意味）について説明する。  
（Ｂ１）、（Ｂ２）：課題（Ｋ１）、（Ｋ２）を解決したときの効果
（Ｓ８）により、ＤＢＭＳ３０が有する解析機能を利用して解析アプリケーションを作成できるので、開発工数を小さくできる。ＤＢＭＳ３０内で解析処理が行われ、ＤＢＭＳ３０とＣＳＥ２０との間でデータ転送を行なう必要がないため、リソースを節約でき処理時間を高速にすることができる。
【０１００】
（Ｂ８）：課題（Ｋ８）を解決したときの効果
（Ｓ９）により、データの意味に則したスキーマのテーブルが用意される構成なので、データ検索のためのIndexを容易に設定することが可能になる。
【０１０１】
（Ｂ５）：課題（Ｋ５）を解決したときの効果
第１コンテナ２２ａにデータを格納するとともに、第２コンテナ２２ｂにもデータが用意されるため、即時に結果を得ることができる。
【０１０２】
（Ｂ３）、（Ｂ４）：課題（Ｂ３）、（Ｂ４）を解決したときの効果
図１０に示した変換アプリケーションが不要なので、計算機の計算資源を有効に活用できる。
【０１０３】
（Ｂ６）：課題（Ｂ６）を解決したときの効果
（Ｂ５）挙げた遅延時間を解消し、（Ｓ９）により適用可能なIoTアプリケーションが増加することができる。
【０１０４】
（Ｂ１０）：課題（Ｋ１０）を解決したときの効果
（Ｓ２）、（Ｓ３）、（Ｓ４）により、データ変換後のデータのみを保持するので、ＤＢＭＳ３０の記憶領域を節約できる。
【０１０５】
（Ｂ７）：課題（Ｋ７）を解決したときの効果
（Ｓ９）により、アクセスコントロールポリシーの設定が簡略化できると共に、処理時間向上の効果が得られる。
【０１０６】
なお、本実施形態ではoneM2Mを基準に説明したが、その前身であるETSI TC M2M標準であっても、用語の差異を考慮して同様に実現できる。  
なお、本実施形態ではContainerリソース、ContentInstanceリソースを用いた例を中心に説明したが、TimeSerieseリソース（containerリソースと似た役割を有し、時系列データの欠損を検出できる）、TimeSerieseInstanceリソースを用いても同様に実現できる。なお、FlexContainerリソース（保持する属性をカスタマイズし、Inteworkingにおいて多様な型を扱う）を用いても同様に実現できる。  
本実施形態では、各種コードはJavaを用いた例を中心に説明したが、それ以外のプログラム言語でも同様に実現することが可能である。
【０１０７】
（第２の実施形態）
次に、本発明の第２の実施形態について説明する。  
図１１は、oneM2Mの典型的なInterworking手法の一例を示す図である。  
図１１に示すように、別のノード２００内にＩＰＥ（Interworking Proxy Entity）２０１、ネットワークインタフェース部２０２、２０３が設けられる。図１１に示すように、oneM2Mの典型的なInterworking手法は、oneM2MのＣＳＥ１２０にて、他のプロトコル/規格のデータをＩＰＥ２０１内のネットワークインタフェース部２０２およびＣＳＥ１２０内のネットワークインタフェース部１４０を介して取得および変換してＤＢＭＳ１３０に格納する形で行われる。
【０１０８】
ＩＰＥ２０１は、非oneM2Mプロトコルを用いて、ネットワークインタフェース部２０３を介して外部のデバイス３０１、３１０と接続し、状態やパラメータの変化を検知する。この形態では、他のプロトコル/規格側の値などの更新頻度が高い場合は、ＩＰＥ２０１およびＣＳＥ１２０の計算資源を多く使用し、ＣＳＥ２０上のＤＢＭＳ１３０のストレージ領域も多く使用してしまうという課題がある。
【０１０９】
例えば、ＩＰＥ２０１が、データが更新されるたびにＣＳＥ１２０上にデータをコピーするように構成されていた場合で、非oneM2Mプロトコル上のデバイス３００、３１０のセンサー値が10msec毎に更新される場合は、秒間100回でＩＰＥ２０１による、デバイス３００、３１０に対するデータ取得、データ変換、ＣＳＥ１２０上への書き込み、これに伴うＤＢＭＳ１３０への書き込みが発生することになる。
また、ＩＰＥ２０１によりＣＳＥ１２０上にコピーされたデータをデータ利用アプリケーションが利用するために、データが発生してから利用されるまでの比較的大きな時間差（ラグ時間）が生じるという課題もある。
【０１１０】
例えば、ＩＰＥ２０１が、１秒置きにＣＳＥ１２０上にデータをコピーするように構成されていた場合で、非oneM2Mプロトコル上のデバイス３００、３１０のセンサー値が10msec毎に更新される場合では、ＣＳＥ１２０上にコピーされたデータをアプリケーションが閲覧する時には、最大で1秒程度のラグ時間が生じてしまう。
【０１１１】
図１２は、本発明の第２の実施形態に係るデータ処理システムの機能構成の一例を示す図である。    
図１２に示した例では、図２Ｂと比較して、ノード１０は、アプリケーションと通信するネットワークインタフェース部４０、および外部のデバイスと通信するデバイス向けネットワークインタフェース部４１を有する。
【０１１２】
上記の課題については、図２Ｂに示すように、永続化処理部２３内の永続化機能部２３ｂ３をＤＢＭＳ３０に接続する代わりに、図１２に示すように、永続化機能部２３ｂ３が、非oneM2Mプロトコルを用いて、ノード１０内のデバイス向けネットワークインタフェース部４１を介して、ノード１０の外部のデバイスと通信するように構成することで解決が可能である。ここで、非oneM2Mプロトコルの具体例としてはUPnP（登録商標）, DLNA（登録商標）, ZigBEE（登録商標）, Bluetooth（登録商標）， DeviceWebAPI, LoRaWAN（登録商標）などが挙げられるが、これらに限定されない。
【０１１３】
この構成を用いることで、他のプロトコル/規格側の値などの更新頻度が高い場合でも、ＣＳＥ２０の計算資源（ＣＰＵ処理時間、メモリ）を多く使用するということは発生せず、また、ＣＳＥ上のストレージ領域も特段多く使用することは無くなる。  
また、アプリケーションが求めた際に、ノード１０は、非oneM2Mプロトコル上のデバイスにデータを動的に取得しにいくために、比較的大きなラグ時間が発生することがなくなる。
【０１１４】
次に、図１２に示す、例えば永続化処理部２３内の切替部２３ａと、デバイス向けネットワークインタフェース部４１が協働して下記の（１）〜（５）のように動作する例ついて説明する。説明はJava言語を用いて説明されるが、これに限定されず、他の言語であってもよい。また、説明を簡単にするために、単純なAPI（アプリケーションプログラミングインタフェース）を用いた例を用いて説明しているが、このAPIに限定されない。
【０１１５】
（１）String[ ] getList（String uri）; // 与えられたURIの直下にあるリソースのURIを返す。  
（２）Object getResource（String uri） //与えられたURIに該当するリソースの全体を返す。  
（３）Object［ ］ getResourceWithSpecifiedAttribute（String uri, String [ ]  attributeNameList ） //与えられたURIに該当するリソースの指定された属性を返す。  
（４）Void updateResouce（String uri, String [ ]  attributeNameList,  Object [ ] attributeValueList  ）;// 与えられたURIのリソースを attributeNameList, attributeValueListで示される属性値で更新する。  
（５）Void  deleteResource（String uri） //与えられたURIに該当するリソースを削除する。
【０１１６】
また、非oneM2Mプロトコルにおける、デバイスとの通信プロトコルが以下の（１１）〜（１５）のようなものである例を説明する。  
（１１）Device［ ］ DiscoverDevice（  ）;// デバイスを発見し、配列として返す。  
（１２）String［ ］ getDeviceAttributeList（ Device d）;// デバイスが有する属性名の配列を返す。  
（１３）Object［ ］  getDeviceAttributeValue（Device d, String［ ］ attributeNames）; // デバイスの指定された属性名に対する属性値を配列として返す。  
（１４）void  setDeviceAttributeValue（Device d, String［ ］ attributeNames, Object [ ] attributeValueList）; // デバイスの指定された属性名に対する属性値を配列として返す。  
【０１１７】
また、永続化機能部２３ｂ３が受け持つURIは以下の（２１）のようになっている例を説明する。  
（２１）-/IWKG/ProtocolX/｛deviceName｝
【０１１８】
図１３は、永続化機能部のlist（）が呼び出されたときの処理動作の一例を示す図である。  
次に、永続化機能部２３ｂ３のlist（）が「URI ＝ -/IWKG/ProtocolX/」として、呼び出された場合の処理を説明する。これは、物理的な意味としては、永続化機能部２３ｂ３がデバイスのリストを求めることに対応する。  
永続化機能部２３ｂ３は、デバイスとノード１０との間のネットワークであるデバイスネットワークに対してdiscovery（）を実行し、このデバイスネットワークから取得されたデバイス名の一覧（例えばDevice1, Device2, .. Device n）が永続化機能部２３ｂ３へ返却される。
【０１１９】
ここで、この一覧を受け取った永続化機能部２３ｂ３は、得られた一覧で示される各デバイス名を、上記呼び出されたURIに結合して配列を作り（例 -/IWKG/ProtocolX/Device1, -/IWKG/ProtocolX/Device2, .. -/IWKG/ProtocolX/Device n）、切替部２３ａに返す。
【０１２０】
なお、上記説明では、デバイスネットワークがdiscovery（）に対応したネットワークとして記載したが、これ以外のデバイスネットワークでもよく、ノード１０とデバイスとの間にネットワークマネージャが存在して管理しているような場合では、永続化機能部２３ｂ３は、そのネットワークマネージャに問い合わせるようにすれば良い。
【０１２１】
図１４は、永続化機能部のgetResource（）が呼び出されたときの処理動作の一例を示す図である。  
次に、永続化機能部２３ｂ３のgetResource（）が「URI ＝ -/IWKG/ProtocolX/Device1」として呼び出された場合の処理を説明する。これは、物理的な意味としては、デバイス名が「Device1」であるデバイス（以下、「Device1」と称する）の全属性値が永続化機能部２３ｂ３返されることに対応する。例として温湿度計の例で説明する。
永続化機能部２３ｂ３は、Device1が有する属性名を取得するための、getDeviceAttributeList（）を呼び出す。ここでは、「Device1」は、temperature（温度）とhumidity（湿度）とでなる２種類の属性を有しているとし、それぞれの属性名が永続化機能部２３ｂ３に返される。
【０１２２】
永続化機能部２３ｂ３は、この得られた属性名に対応する値を、引数attributeNames として指定し、getDeviceAttributeValue（）を呼び出す。
ここで、属性「temperature」の値である属性値「25.5（℃）」と、属性「humidity」の値「60（％）」が「Device1」から永続化機能部２３ｂ３に返される。
この値を受け取った永続化機能部２３ｂ３は、上記の属性名と、当該属性名に対応する属性値との組を切替部２３ａに返却する。図１４ではJSONの形で説明しているが、これに限定されない。
【０１２３】
図１５は、永続化機能部のupdateResouce（）が呼び出されたときの処理動作の一例を示す図である。  
次に、永続化機能部２３ｂ３のupdateResouce（）がURI ＝ -/IWKG/ProtocolX/Device2として呼び出された場合の処理を説明する。これは、物理的な意味としては、デバイス名が「Device2」であるデバイス（以下、「Device2」と称する）の属性値が更新されることに対応する。ここでは、Device2が音楽プレイヤーである例で説明する。
【０１２４】
永続化機能部２３ｂ３からは、更新対象の属性名に係る、attributeNameListとしては、［ playingMusic, Volume］が、更新対象の属性値に係る、 attributeValueListとしては、 ［”スリラー”, 15］ がそれぞれ指定されたものとする。  
この場合は、永続化機能部２３ｂ３は、デバイスとしてDevice2を指定し、
setDeviceAttributeValue（Device2, attributeNames, attributeValueList）; 
を呼び出す。
【０１２５】
上記のように構成することで、図１２に示すアプリケーションが非oneM2Mに対してアクセスすることができるようになる。これは図１１を参照して挙げられた課題を解決している。
【０１２６】
図１６は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュがあるときの処理動作の一例を示す図である。  
図１６に示した例は、図１４に示した例を拡張したものであり、一般的にデバイスが有する属性名キャッシュを永続化機能部２３ｂ３内に配置することにより、属性名の取得の効率化を図るものである。
【０１２７】
属性名キャッシュは、例えば下記の（３１）、（３２）のようなI/Fを有する。
（３１）String ［  ］  getDeviceAttributeList（Device d）;//指定されたデバイスが有する属性名を取得する。 
（３２）putDeviceAttributeList（Device d , String ［ ］ attributeName）;//指定されたデバイスが有する属性名を登録する。
【０１２８】
図１６に示すように、永続化機能部２３ｂ３がDevice1に属性名を問い合わせる前に、getDeviceAttributeList（）により属性名キャッシュにDevice1の属性名を問い合わる。この属性名キャッシュにDevice1の属性名のキャッシュデータが存在する場合は、永続化機能部２３ｂ３は、この属性名を取得する。
また、属性名キャッシュにDevice1の属性名のキャッシュデータが存在しない場合は、永続化機能部２３ｂ３は、図１４に示した例と同様にgetDeviceAttributeList（）によりDevice1に属性名を問い合わせる。  
このとき、後に属性名のデータを効率的に取得するために、永続化機能部２３ｂ３は、Device1から取得した属性名のデータをputDeviceAttributeList（）により属性名キャッシュに登録する。
【０１２９】
図１７は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュ、属性値キャッシュがあるときの処理動作の第１の例を示す図である。  
デバイスネットワークにおいては、属性値の更新時に通知を受け取ることのできるものと、この受け取ることが不可能なものがある。
通知を受け取ることのできないデバイスネットワークにおいての実現例を以降に説明する。
【０１３０】
この実現例では、図１７に示すように、一般的にデバイスが有する属性値キャッシュを永続化機能部２３ｂ３内に配置することにより、属性値の更新時の受け取りの効率化を図る。
属性値キャッシュは、例えば下記の（４１）、（４２）のようなI/Fを有する。
（４１）
Object ［  ］  getDeviceAttributeValue（Device d、String［ ］ attributeNames ）; //指定したデバイスが有する属性名を取得する。
（４２）
putDeviceAttributeValue（Device d , String ［ ］ attributeName, Object［ ］ values）;//指定したデバイスが有する属性名を登録する。
【０１３１】
図１７のように、永続化機能部２３ｂ３がDevice1に属性値を問い合わせる前に、getDeviceAttributeValue（）により属性値キャッシュにDevice1の属性値を問い合わせる。この属性値キャッシュにDevice1の属性値のキャッシュデータが存在する場合は、永続化機能部２３ｂ３は、この属性値を取得する。
【０１３２】
また、属性値キャッシュにDevice1の属性値のキャッシュデータが存在しない場合は、永続化機能部２３ｂ３は、図１４に示した例と同様にgetDeviceAttributeValue（）によりDevice1に属性値を問い合わせる。
このとき、後に属性値のデータを効率的に取得するために、永続化機能部２３ｂ３は、Device1から取得した属性値のデータをputDeviceAttributeValue（）により属性値キャッシュに登録する。
【０１３３】
上記の属性値キャッシュは、キャッシュの有効性管理を行なうことができる。最も簡単な例としては、システムのパラメータとして与えられた duration（例えば 100msecなど）を属性値キャッシュに保持しておき、上記のputDeviceAttributeValue（）が呼び出された時刻を起点に、durationで指定された時間が経過したときに、対応するキャッシュデータを属性値キャッシュから廃棄する。
【０１３４】
次にキャッシュ有効性制御について説明する。  
また、キャシュの有効性管理の別の例として、データの更新時刻、データの変更時刻の少なくとも1つを用いて、キャッシュの有効時間を動的に判定し、これを制御する、キャッシュ有効性制御が挙げられる。データの更新時刻とは、データが更新された時刻のことである。ただし、データ自身が変更されない場合もある。データの値が同じであるのにデータ更新があったことは、更新時刻、およびバージョン番号を共に返却する機能を有するデバイス等において検出できる。
【０１３５】
一方、そのような機能がないデバイスにおいては、前回取得したデータ値に対し、次に取得したデータ値が異なることをもって判断することができる。
具体例として、まず、永続化機能部２３ｂ３は、切替部２３ａからの要求とは独立してデバイスモニタリングフェーズを有し、デバイスモニタリングフェーズの期間にデータの更新時刻、およびデータ変更時刻をモニタリングする。
【０１３６】
この期間は、永続化機能部２３ｂ３は、やや高い頻度でデバイスにアクセスし、データ更新時刻およびデータ変更時刻をそれぞれ取得する。永続化機能部２３ｂ３は、データ更新時刻の差およびデータ変更時刻の差をそれぞれ算出し、この差に基づいてデータ更新間隔およびデータ変更間隔をそれぞれ求める。永続化機能部２３ｂ３は、これらの間隔の傾向に対して、上記のdurationを決定する。
【０１３７】
第１の方法としては、永続化機能部２３ｂ３は、データ更新間隔の最小値をdurationとする。  
第２の方法としては、永続化機能部２３ｂ３は、データ変更間隔の最小値をdurationとする。  
第３の方法としては、永続化機能部２３ｂ３は、データ更新間隔の統計計算を行ない、データ更新間隔の平均μと標準偏差σをそれぞれ求め、μ-n・σをdurationとして採用する。ここで、例えばnには、1, 2, 3が割り当てられる。  
第４の方法としては、永続化機能部２３ｂ３は、データ変更間隔の統計計算を行ない、データ変更間隔の平均μと標準偏差σを求め、μ-n・σをdurationとして採用する。ここで、例えばnには、1, 2, 3が割り当てられる。
これにより、実質的なデータ変更間隔およびデータ更新間隔に応じたキャッシュの寿命を取得できる。
このようなモニタリングフェーズは、システムの起動時だけではなく、定期的に行なうことで、傾向の変化に追従することができる。
【０１３８】
次に、通知を受け取ることのできるデバイスネットワークにおける属性値キャッシュの管理方法について説明する。図１８は、永続化機能部のgetResource（）が呼び出されたときで属性名キャッシュ、属性値キャッシュがあるときの処理動作の第２の例を示す図である。
図１８に示した例では、Device1が属性値を更新した際に、この更新の通知を永続化機能部２３ｂ３が受け取る。ここにはデバイスのIDと変更の在った属性名がパラメータとして永続化機能部２３ｂ３に渡される。この後、永続化機能部２３ｂ３は、指定されたパラメータに従って、属性値キャッシュに記憶される、Device1が属性値のデータを無効にする。
【０１３９】
無効化の後は、新規属性のプリフェッチ（prefetch：事前読み込み）を行なうかどうかで処理が分岐する。プリフェッチを行なう場合は、永続化機能部２３ｂ３が、変更が在った属性値のデータをgetDeviceAttributeValue（）によりDevice1から取得し、この属性値のデータをputDeviceAttributeValue（）により属性値キャッシュに格納する。  
プリフェッチを行なわない場合は、永続化機能部２３ｂ３は、特に処理は行なわずに次の通知を待つ。
【０１４０】
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。
【０１４１】
また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。
【符号の説明】
【０１４２】
１０，１１０…ノード
２０，１２０…ＣＳＥ
２１，１２１…リクエスト受付部
２２，１２２…リソース処理部
２２ａ，１２２ａ…第１コンテナ
２２ｂ，１２２ｂ…第２コンテナ
２３…永続化処理部
２３ａ…切替部
２３ｂ１…第１永続化機能部
２３ｂ２…第２永続化機能部
２３ｂ３…第３永続化機能部
４０，４１…ネットワークインタフェース部
３００，３０１…デバイス
【図１】
2020054147.tif 000003
【図２Ａ】
2020054147.tif 000004
【図２Ｂ】
2020054147.tif 000005
【図３】
2020054147.tif 000006
【図４】
2020054147.tif 000007
【図５】
2020054147.tif 000008
【図６】
2020054147.tif 000009
【図７】
2020054147.tif 000010
【図８】
2020054147.tif 000011
【図９】
2020054147.tif 000012
【図１０】
2020054147.tif 000013
【図１１】
2020054147.tif 000014
【図１２】
2020054147.tif 000015
【図１３】
2020054147.tif 000016
【図１４】
2020054147.tif 000017
【図１５】
2020054147.tif 000018
【図１６】
2020054147.tif 000019
【図１７】
2020054147.tif 000020
【図１８】
2020054147.tif 000021
【国際調査報告】
2020054147.tif 000022
2020054147.tif 000023