JP7201000B2 - データ処理システム、方法およびプログラム - Google Patents

データ処理システム、方法およびプログラム Download PDF

Info

Publication number
JP7201000B2
JP7201000B2 JP2020546694A JP2020546694A JP7201000B2 JP 7201000 B2 JP7201000 B2 JP 7201000B2 JP 2020546694 A JP2020546694 A JP 2020546694A JP 2020546694 A JP2020546694 A JP 2020546694A JP 7201000 B2 JP7201000 B2 JP 7201000B2
Authority
JP
Japan
Prior art keywords
data
persistence
processing
request
processing system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2020546694A
Other languages
English (en)
Other versions
JPWO2020054147A1 (ja
Inventor
浩之 前大道
育生 山崎
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Publication of JPWO2020054147A1 publication Critical patent/JPWO2020054147A1/ja
Application granted granted Critical
Publication of JP7201000B2 publication Critical patent/JP7201000B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/76—Admission control; Resource allocation using dynamic resource allocation, e.g. in-call renegotiation requested by the user or requested by the network in response to changing network conditions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/803—Application aware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/826—Involving periods of time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/09—Management thereof
    • H04W28/0925—Management thereof using policies

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明の実施形態は、データ処理システム、方法およびプログラムに関する。
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（）により属性値キャッシュに格納する。
プリフェッチを行なわない場合は、永続化機能部２３ｂ３は、特に処理は行なわずに次の通知を待つ。
なお、本発明は、上記実施形態に限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。更に、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。
また、各実施形態に記載した手法は、計算機（コンピュータ）に実行させることができるプログラム（ソフトウエア手段）として、例えば磁気ディスク（フロッピー（登録商標）ディスク、ハードディスク等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤ、ＭＯ等）、半導体メモリ（ＲＯＭ、ＲＡＭ、フラッシュメモリ等）等の記録媒体に格納し、また通信媒体により伝送して頒布することもできる。なお、媒体側に格納されるプログラムには、計算機に実行させるソフトウエア手段（実行プログラムのみならずテーブル、データ構造も含む）を計算機内に構成させる設定プログラムをも含む。本装置を実現する計算機は、記録媒体に記録されたプログラムを読み込み、また場合により設定プログラムによりソフトウエア手段を構築し、このソフトウエア手段によって動作が制御されることにより上述した処理を実行する。なお、本明細書でいう記録媒体は、頒布用に限らず、計算機内部あるいはネットワークを介して接続される機器に設けられた磁気ディスク、半導体メモリ等の記憶媒体を含むものである。
１０，１１０…ノード
２０，１２０…ＣＳＥ
２１，１２１…リクエスト受付部
２２，１２２…リソース処理部
２２ａ，１２２ａ…第１コンテナ
２２ｂ，１２２ｂ…第２コンテナ
２３…永続化処理部
２３ａ…切替部
２３ｂ１…第１永続化機能部
２３ｂ２…第２永続化機能部
２３ｂ３…第３永続化機能部
４０，４１…ネットワークインタフェース部
３００，３０１…デバイス

Claims (11)

  1. １以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続されるデータ処理システムであって、
    プロセッサを有し、
    前記プロセッサは、
    前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付ける受付処理を行ない、
    前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能を有し、前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じた処理を前記永続化機能により行なって、その処理結果を前記データベースに永続的に格納する永続化処理を行ない、
    前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じたファイルであって、当該リクエスト又はデータの処理先が前記複数種類の永続化機能のいずれかであるかが設定された設定ファイルに基づいて、前記受付処理により受け付けられた前記リクエスト又はデータの処理先を前記複数種類の永続化機能のいずれかに切り替える切替処理を行なう、ように構成される、
    データ処理システム。
  2. 前記プロセッサは、
    前記受付処理として、
    前記デバイスからのデータを受け付け、
    前記永続化処理として、
    前記受付処理により受け付けられた単一のデータが、複数の論理データからなる物理データであるときに、前記単一のデータを論理データごとに分離して、前記分離された物理データを前記処理結果として前記データベースに格納する、ように構成される、
    請求項１に記載のデータ処理システム。
  3. 前記データベースは、物理的又は論理的に異なる２つ以上のデータベース群によって構成される、
    請求項２に記載のデータ処理システム。
  4. 前記プロセッサは、
    前記永続化処理として、
    前記受付処理により受け付けられた前記単一のデータに通し番号を付与したデータと、前記分離された物理データの各々に前記分離する前のデータに付与された通し番号と同じ通し番号を付与した物理データとを前記データベースにそれぞれ格納する、ように構成される、
    請求項２に記載のデータ処理システム。
  5. 前記プロセッサは、
    前記受付処理として、
    前記デバイスからのデータを受け付け、
    前記永続化処理として、
    前記受付処理により受け付けられたデータが、相互に関連付けられた複数種類のデータからなるときに、前記複数種類のデータを種類ごとに分離して、前記分離されたデータを前記データベースに格納する、ように構成される、
    請求項１に記載のデータ処理システム。
  6. 前記プロセッサは、
    前記永続化処理として、
    前記データベースに格納されたデータを読み出して、前記アプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される、
    請求項１に記載のデータ処理システム。
  7. 前記プロセッサは、
    前記永続化処理として、
    前記データベースに格納されたデータを読み出して、前記読み出されたデータのうち第１のデータを、第１のアプリケーションプログラムによりアクセス可能なデータとして設定し、前記読み出されたデータのうち第２のデータを、第２のアプリケーションプログラムによりアクセス可能なデータとして設定する、ように構成される、
    請求項６に記載のデータ処理システム。
  8. 前記プロセッサは、
    前記永続化処理として、
    ネットワークインタフェースを介して前記デバイスと異なる第２のデバイスとの間で通信をさらに行ない、
    前記受付処理より第１の通信プロトコルで受け付けられた前記リクエストに基づき、前記第２のデバイスとの間で前記第１の通信プロトコルと異なる第２のプロトコルを用いて情報の送受信を行なう、ように構成される、
    請求項１に記載のデータ処理システム。
  9. 前記永続化処理により前記第２のデバイスから取得された情報を記憶する記憶装置をさらに有し、
    前記プロセッサは、
    前記受付処理より第１の通信プロトコルで受け付けられた、前記第２のデバイスから情報を取得するリクエストに基づき、前記第２のデバイスから取得した情報を前記記憶装置に記憶し、
    前記受付処理より第１の通信プロトコルで受け付けられたリクエストに基づき、前記リクエストで示される、取得対象の情報が前記記憶装置に記憶される場合は、この情報を前記記憶装置から読み出す、ように構成される、
    請求項８に記載のデータ処理システム。
  10. １以上のアプリケーションプログラムと１以上のデバイスがデータベースにネットワークを介して接続され、プロセッサを具備するデータ処理システムが行なうデータ処理方法であって、
    前記プロセッサにより、
    前記アプリケーションプログラムからのリクエスト又は前記デバイスからのデータを受け付ける受付処理を行ない、
    前記リクエスト又はデータのタイプに応じて処理を行なって、その処理結果を前記データベースに永続的に格納する複数種類の永続化機能を有し、前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じた処理を前記永続化機能により行なって、その処理結果を前記データベースに永続的に格納する永続化処理を行ない、
    前記受付処理により受け付けられた前記リクエスト又はデータのタイプに応じたファイルであって、当該リクエスト又はデータの処理先が前記複数種類の永続化機能のいずれかであるかが設定された設定ファイルに基づいて、前記受付処理により受け付けられた前記リクエスト又はデータの処理先を前記複数種類の永続化機能のいずれかに切り替える切替処理を行なう、
    データ処理方法。
  11. 請求項１乃至９のいずれか１項に記載のデータ処理システムの前記各処理として前記プロセッサを機能させるデータ処理プログラム。
JP2020546694A 2018-09-14 2019-06-04 データ処理システム、方法およびプログラム Active JP7201000B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018172086 2018-09-14
JP2018172086 2018-09-14
PCT/JP2019/022190 WO2020054147A1 (ja) 2018-09-14 2019-06-04 データ処理システム、方法およびプログラム

Publications (2)

Publication Number Publication Date
JPWO2020054147A1 JPWO2020054147A1 (ja) 2021-09-24
JP7201000B2 true JP7201000B2 (ja) 2023-01-10

Family

ID=69778533

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020546694A Active JP7201000B2 (ja) 2018-09-14 2019-06-04 データ処理システム、方法およびプログラム

Country Status (3)

Country Link
US (1) US20220107954A1 (ja)
JP (1) JP7201000B2 (ja)
WO (1) WO2020054147A1 (ja)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010117905A (ja) 2008-11-13 2010-05-27 Fuji Xerox Co Ltd 情報処理装置およびプログラム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4070693B2 (ja) * 2002-09-13 2008-04-02 株式会社リコー 画像形成装置およびスキャンデータ処理方法
JP2007220086A (ja) * 2006-01-17 2007-08-30 Ntt Docomo Inc 入出力制御装置、入出力制御システム及び入出力制御方法
US20080247004A1 (en) * 2007-04-03 2008-10-09 Michael Yeung System and method for workflow control of scanned document input
JP5610368B2 (ja) * 2010-05-13 2014-10-22 セイコーエプソン株式会社 ジョブ処理装置およびジョブ処理方法
CN102147711B (zh) * 2010-12-31 2014-04-02 华为数字技术（成都）有限公司 一种基于数据内容识别的存储方法及装置
US9047288B2 (en) * 2012-01-06 2015-06-02 Apple Inc. Intelligent data delivery and storage based on data characteristics
US9098217B2 (en) * 2013-03-22 2015-08-04 Hewlett-Packard Development Company, L.P. Causing an action to occur in response to scanned data

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010117905A (ja) 2008-11-13 2010-05-27 Fuji Xerox Co Ltd 情報処理装置およびプログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
西沢 夢路，基礎からのＭｙＳＱＬ 改訂版，第1版，ソフトバンククリエイティブ株式会社，pp. 284--285
飯沢 篤志，データベースおもしろ講座－７－，ｂｉｔ，日本，共立出版株式会社，1991年11月01日，Ｖｏｌ．２３ Ｎｏ．１２（通巻３０２号），pp. 104--115

Also Published As

Publication number Publication date
WO2020054147A1 (ja) 2020-03-19
US20220107954A1 (en) 2022-04-07
JPWO2020054147A1 (ja) 2021-09-24

Similar Documents

Publication Publication Date Title
JP7322119B2 (ja) ネットワーク上のデータソースへの照会
US7383552B2 (en) Object manager for common information model
US8407349B2 (en) Discovering and identifying manageable information technology resources
KR101004576B1 (ko) 연쇄 발견 웹 서비스
US7844612B2 (en) Method for pruning objects in a service registry and repository
WO2016123921A1 (zh) 基于Http协议的多数据源的数据处理方法及系统
US7698479B2 (en) User interface to a data storage system and rule store
US7725469B2 (en) System and program products for pruning objects in a service registry and repository
JP5454201B2 (ja) データストア切替装置、データストア切替方法およびデータストア切替プログラム
US11762775B2 (en) Systems and methods for implementing overlapping data caching for object application program interfaces
US9367610B2 (en) Knowledge registry systems and methods
EP3583766B1 (en) Service discovery using attribute matching
US7467373B2 (en) Global object system
Rudolf SQL, noSQL or newSQL–comparison and applicability for Smart Spaces
JP7201000B2 (ja) データ処理システム、方法およびプログラム
US8181187B2 (en) Gateways having localized in-memory databases and business logic execution
AU2019202964B2 (en) Apparatus and Method for Communicating Data in a Multi-Tennant Computer System
Sacco Redis: Key/Value Database
US20100257194A1 (en) Retrieving data in batches from a line of business system
Xing et al. Active ontology: An information integration approach for dynamic information sources
Krogh et al. The X DevAPI
Quinto et al. Introduction to Impala
MacLean et al. Exploring Android Persistence and Content Providers
Vaddeman et al. Hadoop Ecosystem Tools

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210114

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20220121

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220308

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20220509

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220707

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20221122

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20221205

R150 Certificate of patent or registration of utility model

Ref document number: 7201000

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150