(57)【要約】  本発明は、マシンツーマシン通信技術の分野に関し、リソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信するステップであって、要求メッセージが、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する、ステップと、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新するステップと、更新されたプロデューサデータリソースをコンシューマアプリケーションに返信するステップとを含む。前述の解決策を使用することにより、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題が解決される。
2019506785.tif 000002
【特許請求の範囲】
【請求項１】
リソース取得方法であって、前記方法が、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するステップであって、前記要求メッセージが、前記プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する、ステップと、
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップと、
前記更新されたプロデューサデータリソースを前記コンシューマアプリケーションに返信するステップと
を含む、方法。
【請求項２】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信する前記ステップの前に、前記方法が、
前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するステップであって、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、ステップと、
前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するステップと
をさらに含む、請求項1に記載の方法。
【請求項３】
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップが、具体的に、
前記指示情報に基づいて前記プロデューサデータリソースに対して事前設定動作を実行するステップ、
前記実行された事前設定動作が前記トリガ条件を満たすと判断するステップ、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信するステップであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、ステップ、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信するステップ、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップ
である、請求項2に記載の方法。
【請求項４】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項2または3に記載の方法。
【請求項５】
前記トリガ条件が、前記作成された子リソースの数量制限および／または複数の子リソースの作成時間間隔制限をさらに含む、請求項4に記載の方法。
【請求項６】
前記子リソースが結果ステータスおよび要求コンテンツを含み、
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップの後に、前記方法が、
前記結果ステータスを処理前状態から処理成功状態に変更するステップと、
前記現時点のデータを使用して前記要求コンテンツを更新するステップと
をさらに含む、請求項4または5に記載の方法。
【請求項７】
リソース取得方法であって、前記方法が、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するステップであって、前記要求メッセージが、前記プロデューサデータリソースを返信し、前記プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する、ステップと、
前記コンシューマアプリケーションに前記プロデューサデータリソースを返信するステップと、
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップと
を含む、方法。
【請求項８】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信する前記ステップの前に、前記方法が、
前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するステップであって、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、ステップと、
前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するステップと
をさらに含む、請求項7に記載の方法。
【請求項９】
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップが、具体的に、
前記指示メッセージに基づいて前記プロデューサデータリソースに対して事前設定動作を実行するステップ、
前記事前設定動作が前記トリガ条件を満たすと判断するステップ、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信するステップであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、ステップ、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信するステップ、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップ
である、請求項8に記載の方法。
【請求項１０】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項8または9に記載の方法。
【請求項１１】
データリソースプラットフォームであって、前記プラットフォームが、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するように構成された受信ユニットであって、前記要求メッセージが、前記プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する、受信ユニットと、
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するように構成された処理ユニットと、
前記更新されたプロデューサデータリソースを前記コンシューマアプリケーションに返信するように構成された送信ユニットと
を備える、プラットフォーム。
【請求項１２】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された前記要求メッセージを受信する前に、前記受信ユニットが、前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含み、
前記処理ユニットが、前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される、
請求項11に記載のプラットフォーム。
【請求項１３】
前記処理ユニットにより、前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを前記更新することが、具体的に、
前記指示情報に基づいて前記プロデューサデータリソースに対して事前設定動作を実行すること、
前記事前設定動作が前記トリガ条件を満たすと判断すること、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信することであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、送信すること、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信すること、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新すること
である、請求項12に記載のプラットフォーム。
【請求項１４】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項12または13に記載のプラットフォーム。
【請求項１５】
前記トリガ条件が、前記作成された子リソースの数量制限および／または複数の子リソースの作成時間間隔制限をさらに含む、請求項14に記載のプラットフォーム。
【請求項１６】
前記子リソースが結果ステータスおよび要求コンテンツを含み、
前記送信ユニットが、前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新した後に、前記処理ユニットが、前記結果ステータスを処理前状態から処理成功状態に変更し、前記現時点のデータを使用して前記要求コンテンツを更新するようにさらに構成される、
請求項14または15に記載のプラットフォーム。
【請求項１７】
データリソースプラットフォームであって、前記プラットフォームが、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するように構成された受信ユニットであって、前記要求メッセージが、前記プロデューサデータリソースを返信し、前記プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する、受信ユニットと、
前記コンシューマアプリケーションに前記プロデューサデータリソースを返信するように構成された送信ユニットと
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するように構成された処理ユニットと、
を備える、プラットフォーム。
【請求項１８】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された前記要求メッセージを受信する前に、前記受信ユニットが、前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含み、
前記処理ユニットが、前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される、
請求項17に記載のプラットフォーム。
【請求項１９】
前記処理ユニットにより、前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを前記更新することが、具体的に、
前記指示メッセージに基づいて前記プロデューサデータリソースに対して事前設定動作を実行すること、
前記事前設定動作が前記トリガ条件を満たすと判断すること、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信することであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、送信すること、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信すること、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新すること
である、請求項18に記載のプラットフォーム。
【請求項２０】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項18または19に記載のプラットフォーム。
【請求項２１】
プロセッサおよびメモリを備えるデータリソースプラットフォームであって、
前記メモリがコンピュータ可読プログラムを記憶し、
前記プロセッサが、前記メモリ内の前記プログラムを実行することにより、請求項1から6に記載の前記方法を実行するように構成される、
プラットフォーム。
【請求項２２】
プロセッサおよびメモリを備えるデータリソースプラットフォームであって、
前記メモリがコンピュータ可読プログラムを記憶し、前記プロセッサが、前記メモリ内の前記プログラムを実行することにより、請求項7から10に記載の前記方法を実行するように構成される、
プラットフォーム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、参照によりその全体が本明細書に組み込まれる、2015年12月31日に中国特許庁に出願された「RESOURCE ACQUIRING METHOD AND APPARATUS」と題する、中国特許出願第201511030526．5号の優先権を主張する。
【０００２】
本発明は、マシンツーマシン通信（Machine−to−Machine Communications、M2M）技術の分野に関し、詳細には、リソース取得方法および装置に関する。
【背景技術】
【０００３】
マシンツーマシン通信（Machine−to−Machine Communications、M2M）は、マシン間の知的な対話をコアとするネットワーク化されたアプリケーションおよびサービスである。M2Mは、モニタリング、スケジューリングコマンド、データ収集、測定などの面でユーザの情報化要件を満たすために、ワイヤレスまたは有線の通信モジュールおよびアプリケーション処理ロジックをマシンに挿入することにより、手動介入なしにデータ通信を実現する。
【０００４】
M2Mでは、通常、アプリケーションが別のアプリケーションによって生成された値を読み取る必要があるシナリオに遭遇する。たとえば、温度センサは、市役所や公園などの公共エリアに設置され、収集した温度値をM2Mプラットフォームに継続的に報告し、温度値は（以下、温度リソースと略称される）リソース形式でM2Mプラットフォームに格納される。リソースは、RESTfulアーキテクチャの情報のカプセル化であり、磁気ディスクに格納されたテキスト、またはデータベース内のデータレコードであってもよい。リソースには、データ自体、データのメタデータ、データ提示方法などが含まれる。このシナリオでは、公園に行く予定の訪問者は、ウェブページまたは携帯電話クライアントを使用することにより、M2Mプラットフォーム内の温度リソースに取得要求を送信する方式で、M2Mプラットフォームに格納された温度値を読み取ることができ、その要求に対する応答は温度値を搬送する。そのようなシナリオでは、センサは、データ（つまり温度値）を生成し、M2Mプラットフォームに温度値を報告するように構成されたプロデューサアプリケーションであり、Webページまたは携帯電話クライアントは、データを消費し、M2Mプラットフォーム内の温度値を読み取るように構成されたコンシューマアプリケーションである。
【０００５】
従来のM2Mシステムでは、プロデューサアプリケーションは、プロデューサアプリケーションによって生成されたデータに関心があるコンシューマアプリケーションの数を知ることができない。コンシューマアプリケーションがデータを取得しない場合でも、プロデューサアプリケーションは更新要求をさらに継続的に送信する。反対に、コンシューマアプリケーションは、更新されたデータが現在M2Mプラットフォームに格納されているかどうかを知ることができない。したがって、プロデューサアプリケーションがデータをリフレッシュしていない場合でも、コンシューマアプリケーションは取得要求をさらに継続的に送信するが、通常は古いデータが取得される。
【０００６】
いくつかの実際の配置、たとえば、上述されたシナリオでは、センサは、限られたデバイス、つまりバッテリ駆動センサであり、CPU処理能力、メモリ、およびネットワーク帯域幅はすべて制限される。それは、ネットワーク接続またはウェイクアップ回数を可能な限り減らすことを目的としており、それにより、稼働時間を引き延ばす長い休止時間が保証される。現在のシナリオでは、データのプロデューサアプリケーションとコンシューマアプリケーションは、情報間で整合しない。その結果、プロデューサアプリケーションによって報告されたデータを取得するプロセスにおいて、コンシューマアプリケーションは、冗長なメッセージの送信および浪費に連続して遭遇する。
【発明の概要】
【０００７】
本発明は、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、リソース取得方法および装置を提供する。
【課題を解決するための手段】
【０００８】
前述の目的を達成するために、本発明の実施形態において以下の技術的解決策が使用される。
【０００９】
第1の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信し、要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する。従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーションにデータコンテンツを直接フィードバックする代わりに、プラットフォームは、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新し、次いで、更新されたプロデューサデータリソースをコンシューマアプリケーションに返信する。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。その上、方法は、コンシューマアプリケーションがデータを取得するときに、データがリフレッシュされておらず、結果として古いデータが取得されるケースを回避するために、コンシューマアプリケーションがプロデューサアプリケーションによって生成された最新データを取得できることを保証することができる。
【００１０】
第2の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信することであって、要求メッセージが、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する、受信することと、コンシューマアプリケーションにプロデューサデータリソースを返信することと、次いで、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することとを行う。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。その上、方法によれば、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信した後、プラットフォームは、プロデューサデータリソースのデータコンテンツ内の現在データを取得し、コンシューマアプリケーションに現在データを返信し、コンシューマアプリケーションが時間内にデータを取得することを保証し、さらに、プロデューサアプリケーションをトリガしてプロデューサデータリソースを更新し、その結果、コンシューマアプリケーションは、次回データを取得するときに更新されたデータを取得することができる。
【００１１】
可能な設計では、前述の第1の態様または第2の態様において、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージをプラットフォームが受信する前に、方法は以下のステップをさらに含む。プラットフォームは、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信することであって、サブスクリプションリソース作成要求が、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、受信することと、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成することとを行う。プロデューサデータリソースのサブスクリプションリソースはプラットフォーム上に作成され、その結果、プロデューサデータリソースが事前設定変更を有するとき、プラットフォームは、時間内にプロデューサアプリケーションに通知メッセージを送信することができ、通知メッセージは、プロデューサデータリソースを更新するようにプロデューサアプリケーションに命令するために使用される。したがって、プロデューサアプリケーションは、コンシューマアプリケーションが、これに応答するために、最新データを取得しようとしていることを時間内に知る。
【００１２】
可能な設計では、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的に以下のようであり得る：プラットフォームは、指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行することと、実行された事前設定動作がトリガ条件を満たすと判断することと、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信することと、プロデューサアプリケーションによって返信された現時点のデータを受信することと、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することとを行う。プラットフォーム／ゲートウェイ101が、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーション103によって送信された要求メッセージを受信すると、従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーション103にデータコンテンツを直接フィードバックする代わりに、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースに対して事前設定動作を実行して、最新データを取得するための通知メッセージをプロデューサアプリケーションに送信するようにプラットフォーム／ゲートウェイ101をトリガする。本発明のこの実施形態における方法を用いて、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいて、プロデューサデータリソースを更新することができる。
【００１３】
可能な設計では、トリガ条件は、プロデューサデータリソースの子リソースを作成することを含み、子リソースのタイプは事前設定タイプである。特定のタイプのプロデューサデータリソースの子リソースを作成する方式では、プラットフォームは、より柔軟で効果的なトリガ機構を実現するために、プロデューサデータリソース自体に対して動作を実行する代わりに、プロデューサアプリケーションに通知メッセージを送信するようにトリガされる。場合によっては、トリガ条件は、作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限をさらに含む。
【００１４】
別の可能な設計では、子リソースは結果ステータスおよび要求コンテンツを含み、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新するステップの後に、方法は、結果ステータスを処理前状態から処理成功状態に変更するステップと、現時点のデータを使用して要求コンテンツを更新するステップとをさらに含む。
【００１５】
第3の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信することであって、サブスクリプションリソース作成要求が、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、受信することと、サブスクリプションリソース作成要求に基づいてプロデューサデータリソースのサブスクリプションリソースを作成することと、コンシューマアプリケーションによって送信された動作要求を受信することと、動作要求に基づいてプロデューサデータリソースに対して事前設定動作を実行することと、実行された事前設定動作がトリガ条件を満たすと判断することと、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信することと、プロデューサアプリケーションによって返信された現時点のデータを受信することと、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することとを行う。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。
【００１６】
第4の態様によれば、本発明の一実施形態はデータリソースプラットフォームを提供する。データリソースプラットフォームは、第1から第3の態様のリソース取得方法におけるプラットフォームの動作を実装する機能を有する。この機能は、ハードウェアを使用して実装されてもよいし、ハードウェアが対応するソフトウェアを実行することによって実装されてもよい。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のモジュールを含む。
【００１７】
可能な設計では、データリソースプラットフォームの構造は、プロセッサおよびメモリを含む。メモリは、前述の方法を実行するデータベース処理デバイスをサポートするプログラムを記憶するように構成され、プロセッサは、メモリに記憶されたプログラムを実行するように構成される。データベース処理デバイスは、別のデバイスまたは通信ネットワークと通信するためにデータベース処理デバイスによって使用される通信インタフェースをさらに含む場合がある。
【００１８】
第5の態様によれば、本発明の一実施形態は、前述のデータリソースプラットフォームによって使用されるコンピュータソフトウェア命令を記憶するように構成されたコンピュータ記憶媒体を提供し、コンピュータ記憶媒体は、データリソースプラットフォーム用に設計され、前述の態様を実行するように構成されたプログラムを含む。
【００１９】
可能な設計では、同じコンシューマアプリケーションが、データリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信するたびに、プラットフォーム／ゲートウェイ101は、acquireタイプの新しい子リソースを作成する。プラットフォーム／ゲートウェイ101の処理負荷を軽減するために、プラットフォーム／ゲートウェイ101は、ルールに従って、作成されたacquireタイプのリソースを削除する。たとえば、acquireタイプの各リソースは、acquireタイプのリソースの作成から始まるライフサイクルをもち、acquireタイプのリソースの存在時間がライフサイクルを超えたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、acquireタイプのリソースの結果ステータスが処理失敗もしくは処理中であるとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、またはacquireタイプのリソースの更新識別子がalwaysであり、結果ステータスが処理失敗もしくは処理中あると判断されたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除する。
【００２０】
従来技術と比較して、本発明で提供される解決策は、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決することができる。
【００２１】
本発明のこれらの態様または別の態様は、以下の実施形態の説明において、より簡潔で、容易に理解可能である。
【図面の簡単な説明】
【００２２】
【図１】本発明の一実施形態による、リソースを取得するための現行のアーキテクチャの図である。
【図２】本発明の一実施形態による、コンピュータデバイスの概略図である。
【図３】本発明の一実施形態による、リソース取得方法の概略フローチャートである。
【図４】本発明の一実施形態による、別のリソース取得方法の概略フローチャートである。
【図５】本発明の一実施形態による、データリソースプラットフォームの概略構造図である。
【図６】本発明の一実施形態による、別のデータリソースプラットフォームの概略構造図である。
【発明を実施するための形態】
【００２３】
本発明の目的、技術的解決策、および利点をより明確にするために、以下で、添付図面を参照して、詳細に本発明の実施形態をさらに説明する。
【００２４】
図1は、本発明の一実施形態による、リソースを取得するための現行のアーキテクチャを記載する。現行のアーキテクチャ100は、従来のM2Mアーキテクチャに基づき、プラットフォーム／ゲートウェイ101と、（端末A、B、およびCなどの）コンシューマ端末102と、（端末Xなどの）プロデューサ端末104とを含む。コンシューマアプリケーション103がコンシューマ端末102にインストールされ、コンシューマアプリケーション103は、ネットワーク106を使用してプラットフォーム／ゲートウェイ101にリモートアクセスし、プラットフォーム／ゲートウェイ101を使用して、プロデューサ端末104内のプロデューサアプリケーション105によって収集されたデータを取得する。プロデューサアプリケーション105はプロデューサ端末104にインストールされ、プロデューサアプリケーション105は、ネットワーク106を使用してプラットフォーム／ゲートウェイ101に収集されたデータを送信し、その結果、プラットフォーム／ゲートウェイは、プロデューサアプリケーション105によって収集されたデータをコンシューマアプリケーション103に供給する。
【００２５】
本発明のこの実施形態では、コンシューマアプリケーション103がインストールされるコンシューマ端末102は、図示された端末A、B、およびCに限定されないことに留意されたい。実際、コンシューマアプリケーションの量は極めて大量の場合があり、プロデューサアプリケーション105によって収集されたデータは、M2Mネットワークに接続された多くのコンシューマ端末102内のコンシューマアプリケーション103によって同時に使用される場合がある。プロデューサアプリケーション105によって収集されたデータは、（以下、プロデューサデータリソースと略称される）リソース形式でプラットフォーム／ゲートウェイ101に格納される。プラットフォーム／ゲートウェイ101に格納されるプロデューサデータリソースには、リソース識別子、データコンテンツなどが含まれる。従来技術では、コンシューマアプリケーション103がプロデューサデータリソースを取得する必要があるとき、プロデューサデータリソースのリソース識別子を搬送するデータリソース取得要求のみが、プラットフォーム／ゲートウェイ101に送信される必要がある。しかしながら、プロデューサアプリケーション105は収集されたデータをリアルタイムでプラットフォーム／ゲートウェイ101に送信しないので、コンシューマアプリケーション103によって取得されたプロデューサデータリソースは最新ではない可能性が高い。コンシューマアプリケーション103によって取得されたプロデューサデータリソースがプロデューサアプリケーション105によって収集された最新データであることを保証するために、コンシューマアプリケーション103によってプラットフォーム／ゲートウェイ101に送信されるデータリソース取得要求は、最新データを返信するようにプラットフォーム／ゲートウェイ101に命令するために使用される指示情報を搬送する。コンシューマアプリケーション103によって送信されたデータリソース取得要求を受信した後、プラットフォーム／ゲートウェイ101は、データリソース取得要求内の指示情報に基づいて、コンシューマアプリケーション103がプロデューサアプリケーション103によって収集された最新データを取得しようとしていると判断し、プロデューサアプリケーション105に通知メッセージを送信し、通知メッセージは、コンシューマアプリケーション103が取得することを要求した収集された最新データが存在することをプロデューサアプリケーション105に通知するために使用される。プラットフォーム／ゲートウェイ101によって送信された通知メッセージを受信した後、プロデューサアプリケーション105は、最新データを収集し、プラットフォーム／ゲートウェイ101に最新データを送信する。プラットフォーム／ゲートウェイ101は、受信された最新データに基づいてプロデューサデータリソースを更新し、収集された最新データを搬送する応答メッセージをコンシューマアプリケーション103に送信する。
【００２６】
プラットフォーム／ゲートウェイ101は、M2Mシステム内のIN（Infrastructure Node、基盤ノード）またはMN（Middle Node、中間ノード）であってもよく、コンシューマ端末102／プロデューサ端末104は、ASN（Application Service Node、アプリケーションサービスノード）またはADN（Application Dedicated Node、アプリケーション専用ノード）であってもよい。具体的には、コンシューマ端末102は、携帯電話、PC、およびipadなどの、M2Mシステムに接続された様々なモバイル端末であってもよい。コンシューマアプリケーション103は、空気温度計アプリケーション、電気メータアプリケーション、または高度道路交通アプリケーションなどの、コンシューマ端末102にインストールされた任意のアプリケーションプログラムであってもよい。プロデューサ端末104は、たとえば、温度センサなどの様々なセンサであってもよい。コンシューマアプリケーション103は、コンシューマ端末にインストールされた任意のアプリケーションプログラムである。ネットワーク106は、プラットフォーム／ゲートウェイ101、たとえば、Local Area Networks（LAN）またはWireless Local Area Networks（WLAN）などの任意の通信ネットワークと通信し、接続することを、コンシューマ端末102／プロデューサ端末104に行わせるために使用される任意の媒体であってもよい。
【００２７】
本発明のこの実施形態では、最新データを返信するようにプラットフォーム／ゲートウェイ101に命令するために使用される指示情報は、プロデューサアプリケーション105から収集された最新データを取得し、収集された最新データをコンシューマアプリケーション103に返信するようにプラットフォーム／ゲートウェイ101に命令するために、プラットフォーム／ゲートウェイ101に送信されたデータリソース取得要求内でコンシューマアプリケーション103によってさらに搬送される。本発明のこの実施形態では、コンシューマアプリケーション103が最新データを取得する必要がないとき、プロデューサアプリケーション103はデータを収集する必要がない。これにより、コンシューマアプリケーション103がプロデューサアプリケーション103によって報告されたデータを必要としないことによって生じる浪費が回避され、プロデューサ端末104の電力消費が低減され、コンシューマアプリケーション103が最新データを取得する必要があるときに古いデータを取得しないことが保証される。
【００２８】
図2に示されように、図1のコンシューマ端末102およびプラットフォーム／ゲートウェイ101は、図2のコンピュータデバイス（またはシステム）を用いて実装される場合がある。
【００２９】
図2は、本発明の一実施形態による、コンピュータデバイスの概略図である。コンピュータデバイス200は、少なくとも1つのプロセッサ201と、通信バス202と、メモリ203と、少なくとも1つの通信インタフェース204とを含む。
【００３０】
プロセッサ201は、汎用中央処理装置（CPU）、マイクロプロセッサ、特定用途向け集積回路（application−specific integrated circuit、ASIC）、または本発明の解決策のプログラムの実行を制御するように構成された1つもしくは複数の集積回路であってもよい。
【００３１】
通信バス202は、構成要素間で情報を送信するための経路を含む場合がある。通信インタフェース204は、任意のトランシーバタイプの装置に適用可能であり、別のデバイス、または、イーサネット（登録商標）、無線アクセスネットワーク（RAN）、もしくは無線ローカルエリアネットワーク（Wireless Local Area Networks、WLAN）などの通信ネットワークと通信するように構成される。
【００３２】
メモリ203は、読取り専用メモリ（read−only memory、ROM）もしくは静的情報および静的命令を記憶することができる別のタイプの静的ストレージデバイス、またはランダムアクセスメモリ（random access memory、RAM）もしくは情報および命令を記憶することができる別のタイプの動的ストレージデバイスであってもよく、電気的消去可能プログラマブル読出し専用メモリ（Electrically Erasable Programmable Read−Only Memory、EEPROM）、コンパクトディスク読取り専用メモリ（Compact Disc Read−Only Memory、CD−ROM）もしくは別のコンパクトディスク記憶媒体、（コンパクトディスク、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む）光ディスク記憶媒体および磁気ディスク記憶媒体、別の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するように構成することができ、コンピュータにアクセス可能な任意の他の媒体であってもよいが、それらに限定されない。メモリは、独立して存在し、バスを使用してプロセッサに接続されてもよい。あるいは、メモリは、プロセッサと一体化されてもよい。
【００３３】
メモリ203は、本発明の解決策を実行するためのアプリケーションプログラムコードを記憶するように構成され、実行はプロセッサ201によって制御される。プロセッサ201は、メモリ203に記憶されたアプリケーションプログラムコードを実行するように構成される。
【００３４】
具体的な実装の間、一実施形態では、プロセッサ201は、1つまたは複数のCPU、たとえば、図2のCPU0およびCPU1を含む場合がある。
【００３５】
具体的な実装の間、一実施形態では、コンピュータデバイス200は、図2の中にあるプロセッサ201およびプロセッサ208などの複数のプロセッサを含む場合がある。これらのプロセッサの各々は、シングルCPU（single−CPU）プロセッサであってもよく、マルチCPU（multi−CPU）プロセッサであってもよい。本明細書では、プロセッサは、（コンピュータプログラム命令などの）データを処理するように構成された1つまたは複数のデバイス、回路、および／または処理コアであってもよい。
【００３６】
具体的な実装の間、一実施形態では、コンピュータデバイス200は、出力デバイス205および入力デバイス206をさらに含む場合がある。出力デバイス205は、プロセッサ201と通信し、複数の方式で情報を表示することができる。たとえば、出力デバイス205は、液晶ディスプレイ（liquid crystal display、LCD）、発光ダイオード（light emitting diode、LED）表示デバイス、陰極線管（cathode ray tube、CRT）表示デバイス、プロジェクタ（projector）などであってもよい。入力デバイス206は、プロセッサ201と通信し、複数の方式でユーザの入力を受け取ることができる。たとえば、入力デバイス206は、マウス、キーボード、タッチスクリーンデバイス、センサデバイスなどであってもよい。
【００３７】
コンピュータデバイス200は、汎用コンピュータデバイスまたは専用コンピュータデバイスであってもよい。具体的な実装の間、コンピュータデバイス200は、デスクトップコンピュータ、ポータブルコンピュータ、ネットワークサーバ、パームトップコンピュータ（Personal Digital Assistant、PDA）、携帯電話、タブレットコンピュータ、ワイヤレス端末デバイス、通信デバイス、組込み型デバイス、または図2のデバイスに類似する構造を有するデバイスであってもよい。本発明のこの実施形態では、コンピュータデバイス200のタイプは限定されない。
【００３８】
図1に示されたコンシューマ端末102は、図2に示されたデバイスであってもよく、1つまたは複数のソフトウェアモジュール（たとえば、第1の対話モジュールおよび第1の処理モジュール）が、コンシューマ端末102のメモリに記憶されてもよい。コンシューマ端末102は、最新のプロデューサデータを取得するために、プロセッサおよびメモリ内のプログラムコードを使用してソフトウェアモジュールを実装することができる。1つまたは複数のソフトウェアモジュール（たとえば、第2の対話モジュールおよび第2の処理モジュール）は、プラットフォーム／ゲートウェイ101のメモリに記憶される。コンシューマ端末102は、プロデューサアプリケーション105から最新のプロデューサデータを取得し、コンシューマアプリケーション103に最新のプロデューサデータを送信するために、プロセッサおよびメモリ内のプログラムコードを使用してソフトウェアモジュールを実装することができる。
【００３９】
図1に示された現行のアーキテクチャの図に基づいて、現行のアーキテクチャにおけるコンシューマアプリケーション103がリソースを取得する処理プロセスをより明確に記載するために、本発明の実施形態は、リソース取得方法の概略フローチャートを提供する。プロデューサアプリケーション105は、プラットフォーム／ゲートウェイ101がプロデューサデータリソースの事前設定タイプの子リソース、たとえば、acquireタイプの子リソースを作成するとき、プロデューサアプリケーション105に通知メッセージを送信するように命令するために、プロデューサデータリソースの子リソースとしてサブスクリプションリソースを作成するように、プラットフォーム／ゲートウェイ101要求する。通知メッセージを受信すると、プロデューサアプリケーション105は最新データを収集し、プラットフォーム／ゲートウェイ101に最新データを送信する。コンシューマアプリケーション103がプロデューサアプリケーション105によって収集された最新データを取得する必要があるとき、プロデューサデータリソースの事前設定タイプの子リソースを作成するようにプラットフォーム／ゲートウェイ101をトリガすることができる取得要求のみが、プラットフォーム／ゲートウェイ101に送信される必要がある。
【００４０】
図3に示されたように、図3は、本発明の一実施形態による、リソース取得方法の概略フローチャートである。たとえば、oneM2Mでは、プロデューサアプリケーション105によって報告された温度値などのデータが格納されるプロデューサデータリソースとして、containerリソースが使用される。その上、プロデューサデータリソースのためにサブスクリプションリソースが作成され、containerリソースに変更があると、プラットフォーム／ゲートウェイ101は、サブスクリプションリソースに基づいて対応する加入者に通知メッセージを送信する。本発明のこの実施形態では、コンシューマアプリケーション103がcontainerリソースの最新の状態を取得するように試みたとき、プロデューサアプリケーション105は通知メッセージを受信する。プロデューサアプリケーション105が最新データを使用してcontainerリソースを更新した後、コンシューマアプリケーション103は、更新されたcontainerリソース内のデータコンテンツに格納されたデータを取得することができる。この実施形態では、説明および記載を行うためにoneM2M規格が例として使用される。プロデューサデータリソースはcontainerリソースであり、サブスクリプションリソースはsubscriptionリソースである。
【００４１】
ステップ301．プロデューサアプリケーション105がプラットフォーム／ゲートウェイ101にサブスクリプションリソース作成要求を送信し、サブスクリプションリソース作成要求は、サブスクリプションリソースの識別子、加入者の識別子、サブスクリプションイベントのトリガ条件を含む。
【００４２】
具体的には、本発明のこの実施形態では、サブスクリプションリソースの識別子は、プロデューサデータリソースの識別子、すなわちcontainerリソースの識別子であり、加入者の識別子はプロデューサアプリケーション105の識別子である。サブスクリプションリソースに対して事前設定動作が実行されるので、サブスクリプションリソースが事前設定変更を有するとき、加入者に通知メッセージを送信するようにプラットフォーム／ゲートウェイ101がトリガされる。サブスクリプションリソースが事前設定変更を有することを可能にする事前設定動作は、サブスクリプションイベントのトリガ条件である。本発明のこの実施形態では、サブスクリプションイベントのトリガ条件は、具体的には、プロデューサデータリソースの子リソースを作成することであり、子リソースのタイプは事前設定タイプである。場合によっては、トリガ条件は、作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限をさらに含む。
【００４３】
可能な設計では、プロデューサアプリケーション105は、以下のように、プラットフォーム／ゲートウェイ101にサブスクリプションリソース作成要求を送信することができる。
POST／CSEBase／container
＜m2m＞
＜subscription＞
＜eventType＞CHILD＿CREATION＜／eventType＞
＜resourceType＞ACQUIRE＜／resourceType＞
＜batchNotify＞2＜／batchNotify＞
＜originatorID＞ALL＜／originatorID＞
＜creator＞AEX＜／creator＞
＜notificationURI＞http：／／example．SP．AE1＜／notificationURI＞
＜／subscription＞
＜／m2m＞
【００４４】
POSTT要求のアドレス「／CSEBase／container」は、本明細書におけるプロデューサデータリソースの識別子であるサブスクリプションリソースの識別子を示す。＜subscription＞は、プロデューサアプリケーション105がプロデューサデータリソースの下にサブスクリプションリソースを作成しようとしていることを示し、サブスクリプションリソースのeventTypeはチャイルドリソースの作成のみに関心があることを示すchild creationであり、resourceTypeは、acquireタイプの子リソースのみに関心があることを示すacquireであり、batchNotifyは、イベントが少なくとも2回トリガされたときにのみ通知が送信されることを示す2に設定され、本明細書でのイベントはacquireタイプの子リソースの作成であり、creatorは、本明細書ではコンシューマアプリケーションの識別子である加入者の識別子を示し、notificationURIは、加入者が通知メッセージを受信したアドレスを示す。すなわち、プロデューサデータリソースの作成された子リソースのリソースタイプがacquireであり、子リソースの数が2よりも大きいとき、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105に通知メッセージを送信し、通知メッセージを送信するためのアドレスはhttp：／／example．SP．AE1である。
【００４５】
可能な設計では、プロデューサデータリソースのacquireタイプの2つの子リソースの作成時間間隔が事前設定時間を超えることなどの、サブスクリプションイベントの別のトリガ条件がさらに設定される場合がある。様々なトリガ条件を設定することにより、プロデューサ端末のデータ取得の適時性と消費電力とのバランスが良好になり得る。様々なトリガ条件は、一緒に使用されてもよく、各々が単独で使用されてもよく、本発明ではトリガ条件は限定されない。
【００４６】
ステップ302．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105によって送信されたサブスクリプションリソース作成要求を受信し、サブスクリプションリソースを作成し、サブスクリプションリソースはプロデューサデータリソースの子リソースである
【００４７】
具体的には、プラットフォーム／ゲートウェイ101により、受信されたサブスクリプションリソース作成要求に基づいてプロデューサデータリソースの下にサブスクリプションリソースを作成することは、当業者によく知られた技術であり、詳細は本明細書では再び記載されない。
【００４８】
ステップ303．コンシューマアプリケーション1がデータリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信し、データリソースを取得するために使用される要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するようにプラットフォーム／ゲートウェイ101に命令する指示情報を搬送する。
【００４９】
具体的には、コンシューマアプリケーション1は、プラットフォーム／ゲートウェイ101にretrieve要求を送信して、containerリソースを検索することを要求し、要求はkeepUpdate識別子を搬送する。keepUpdate識別子は、HTTPメッセージの拡張ヘッダを使用して送信される。
【００５０】
GET要求は以下の通りであり得る。
GET／CSEBase／container
X−M2M−From：AE1
X−M2M−KEEPUPDATE：Onlyonce
【００５１】
GET要求のアドレス「／CSEBase／container」は、本明細書ではプロデューサデータリソースの識別子である、サブスクリプションリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション103の識別子である、要求を開始するアプリケーションの識別子を示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値Onlyonceは、コンシューマアプリケーション103が更新されたプロデューサデータリソースを取得しようとしていることを示す。
【００５２】
ステップ304．プラットフォーム／ゲートウェイ101が、データリソースを取得するために使用され、コンシューマアプリケーション1によって送信された要求メッセージを受信し、要求メッセージ内の指示情報に基づいて、プロデューサデータリソースの子リソースとしてacquireタイプのリソースを作成する。
【００５３】
acquireタイプのリソースには、要求コンテンツ、結果ステータス、および更新識別子が含まれる。プラットフォーム／ゲートウェイ101が、要求メッセージ内の指示情報に基づいてacquireタイプのリソースを最初に作成するとき、要求コンテンツは空白であり、結果ステータスは処理前であり、更新識別子の値はOnlyonceである。結果ステータスは処理前であり、acquireタイプのリソースが処理前状態であることを示し、更新識別子の値はOnlyonceであり、プラットフォーム／ゲートウェイ101が、containerリソースが一度更新に成功した後にのみ、acquireタイプのリソースの結果ステータスを処理前から処理成功に変更することができることを示し、containerリソースの最新データはacquireタイプのリソースの要求コンテンツに格納される。しかしながら、containerリソースが後で再び更新された場合、変更されたcontainerリソースの最新データは、二度とacquireタイプのリソースの要求コンテンツに更新されない。containerリソースの更新に失敗した場合、acquireタイプのリソースの結果ステータスは処理前から処理失敗に変更される。
【００５４】
ステップ305．コンシューマアプリケーション2がデータリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信し、データリソースを取得するために使用される要求メッセージは、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令する指示情報を搬送する。
【００５５】
具体的には、コンシューマアプリケーション2は、プラットフォーム／ゲートウェイ101にretrieve要求を送信して、containerリソースを検索することを要求し、要求はkeepUpdate識別子を搬送する。keepUpdate識別子は、HTTPメッセージの拡張ヘッダを使用して送信される。
【００５６】
GET要求は以下の通りである。
GET／CSEBase／container
X−M2M−From：AE2
X−M2M−KEEPUPDATE：always
【００５７】
GET要求のアドレス「／CSEBase／container」は、本明細書ではプロデューサデータリソースの識別子である、サブスクリプションリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション2の識別子である、要求を開始するアプリケーションの識別子を示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値alwaysは、コンシューマアプリケーション103が現在のプロデューサデータリソースを取得しようとしていることを示す。
【００５８】
ステップ306．プラットフォーム／ゲートウェイ101が、データリソースを取得するために使用され、コンシューマアプリケーション2によって送信された要求メッセージを受信し、要求メッセージ内の指示情報に基づいて、プロデューサデータリソースの子リソースとしてacquireタイプのリソースを作成する。
【００５９】
acquireタイプのリソースには、要求コンテンツ、結果ステータス、および更新識別子が含まれる。プラットフォーム／ゲートウェイ101が、要求メッセージ内の指示情報に基づいてacquireタイプのリソースを最初に作成するとき、要求コンテンツは空白であり、結果ステータスは処理前であり、更新識別子の値はalwaysである。更新識別子の値はalwaysであり、プラットフォーム／ゲートウェイ101がcontainerリソースが更新されるのを待つ必要はないが、プロデューサデータリソースのデータコンテンツ内の現在値を直接取得し、現在値を要求コンテンツに格納し、次いで、acquireタイプのリソースの結果ステータスを処理前から処理成功に直接変更することを示す。
【００６０】
ステップ307．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105に通知メッセージを送信し、通知メッセージは、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される。
【００６１】
具体的には、サブスクリプションリソースが事前設定変更を有すると判断すると、プラットフォーム／ゲートウェイ101は加入者に通知メッセージを送信する。本発明のこの実施形態では、ステップ301の例によれば、サブスクリプションイベントのトリガ条件は、acquireタイプの少なくとも2つの子リソースがプロデューサデータリソースの下に作成されることである。ステップ304およびステップ306が実行された後、acquireタイプの2つの子リソースがプロデューサデータリソースの下に作成される。したがって、この場合、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105に通知メッセージを送信するようにトリガされる。
【００６２】
ステップ308．プラットフォーム／ゲートウェイ101がコンシューマアプリケーション2に応答メッセージを送信し、応答メッセージは、プロデューサデータリソースのデータコンテンツ内の現在値を搬送する。
【００６３】
ステップ307およびステップ308の順番は限定されないことに留意されたい。ステップ305において、コンシューマアプリケーション2によってプラットフォーム／ゲートウェイ101に送信された要求メッセージ内で搬送される指示情報は、現在のプロデューサデータリソースを返信し、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するので、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105が最新データを返信するのを待つ必要はなく、プロデューサデータリソースのデータコンテンツ内に格納された現在データを直接取得し、コンシューマアプリケーション2に現在データを返信する。場合によっては、プロデューサデータリソースのデータコンテンツに格納されたデータは、プロデューサデータリソース内のデータコンテンツからプラットフォーム／ゲートウェイ101によって取得されてもよく、ステップ306において作成されたacquireタイプのリソースの要求コンテンツから取得されてもよい。
【００６４】
ステップ309．プロデューサアプリケーション105が最新データを取得し、プラットフォーム／ゲートウェイ101に更新要求を送信し、更新要求は取得された最新データを含む。
【００６５】
場合によっては、プラットフォーム／ゲートウェイ101は、受信された通知メッセージに基づいて、containerリソースが更新される必要があると判断する。したがって、最新データが取得される。たとえば、現在の温度値が収集される。次いで、containerリソースを更新するように要求するために、プラットフォーム／ゲートウェイ101にupdate要求が送信され、update要求は取得された最新データを搬送する。
【００６６】
ステップ310．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105によって送信された更新要求を受信し、更新要求に基づいてプロデューサデータリソースを更新する。
【００６７】
具体的には、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105によって送信された更新要求内で搬送された最新データに基づいて、containerリソース内のデータコンテンツを更新する。
【００６８】
場合によっては、プラットフォーム／ゲートウェイ101は、containerリソースの下のacquireタイプの子リソースが更新される必要があるかどうかを1つずつさらに判定する。具体的には、プラットフォーム／ゲートウェイ101は、containerリソースの下のacquireタイプの子リソースの結果ステータスが処理前状態であるかどうかを1つずつ判定し、結果ステータスが処理前状態であるとき、更新要求内で搬送された最新データに基づいてacquireタイプの子リソースの対応する要求コンテンツを更新し、結果ステータスを処理成功に変更する。
【００６９】
ステップ311．プラットフォーム／ゲートウェイ101がコンシューマアプリケーション1に応答メッセージを送信し、応答メッセージは、プロデューサアプリケーション105によって返信された最新データを搬送する。
【００７０】
場合によっては、プロデューサアプリケーション105によって返信され、応答メッセージ内で搬送される最新データは、ステップ310において更新されたプロデューサデータリソース内のデータコンテンツからプラットフォーム／ゲートウェイ101によって取得されてもよく、acquireタイプの更新されたリソースの要求コンテンツから取得されてもよい。
【００７１】
可能な設計では、同じコンシューマアプリケーションが、データリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信するたびに、プラットフォーム／ゲートウェイ101は、acquireタイプの新しい子リソースを作成する。プラットフォーム／ゲートウェイ101の処理負荷を軽減するために、プラットフォーム／ゲートウェイ101は、ルールに従って、作成されたacquireタイプのリソースを削除する。たとえば、acquireタイプの各リソースは、acquireタイプのリソースの作成から始まるライフサイクルをもち、acquireタイプのリソースの存在時間がライフサイクルを超えたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、acquireタイプのリソースの結果ステータスが処理失敗もしくは処理中であるとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、またはacquireタイプのリソースの更新識別子がalwaysであり、結果ステータスが処理失敗もしくは処理中あると判断されたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除する。
【００７２】
可能な設計では、プロデューサデータリソースのデータコンテンツは、常にプロデューサアプリケーションから受信された最新データを格納し、acquireタイプのリソースの要求コンテンツは、前述の実施形態における更新識別子がOnlyonceであるacquireタイプのリソースなどの、プロデューサアプリケーションによって生成された履歴データを格納することができる。プラットフォーム／ゲートウェイ101はさらに、データリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージをさらに受信し、データリソースを取得するために使用される要求メッセージは、前述のステップにおいて作成されたacquireタイプのリソースの識別子を搬送し、プラットフォーム／ゲートウェイ101は、acquireタイプの子リソースの識別子に基づいて、acquireタイプのリソースの要求コンテンツに格納されているデータを取得し、コンシューマアプリケーションにデータを返信する。
【００７３】
本発明のこの実施形態では、プラットフォーム／ゲートウェイ101が、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーション103によって送信された要求メッセージを受信すると、従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーション103にデータコンテンツを直接フィードバックする代わりに、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースに対して事前設定動作を実行して、最新データを取得するための通知メッセージをプロデューサアプリケーションに送信するようにプラットフォーム／ゲートウェイ101をトリガする。プラットフォーム／ゲートウェイ101によって送信された通知メッセージを受信した後、プロデューサアプリケーション105は最新データを取得し、プラットフォーム／ゲートウェイ101に更新要求を送信し、その結果、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースを更新し、コンシューマアプリケーションに最新データを返信する。本発明のこの実施形態における方法を用いて、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。
【００７４】
図4は、本発明の一実施形態による、別のリソース取得方法の概略フローチャートである。図4に示されたように、方法は以下のステップを含む。
【００７５】
ステップ401およびステップ402は、図3に示された実施形態のステップ301およびステップ302と同じである。ステップ404、ステップ406、ステップ407、ステップ408、およびステップ409は、それぞれ、図3に示された実施形態のステップ304、ステップ306、ステップ307、ステップ309、およびステップ310と同じである。関連する説明については、前述のステップを参照されたい。詳細は本明細書では再び記載されない。
【００７６】
ステップ403．コンシューマアプリケーション1がプラットフォーム／ゲートウェイ101にリソース作成要求を送信し、リソース作成要求は、プロデューサデータリソースの子リソースを作成するようにプラットフォーム／ゲートウェイ101に命令するために使用され、プロデューサデータリソースの識別子、作成される必要があるリソースのタイプ、および作成される必要があるリソースのコンテンツを含む。
【００７７】
具体的には、リソース作成要求は以下の通りであり得る。
POST／CSEBase／container
X−M2M−From：AE1
Content−Type：application／vnd．onem2m−res＋xml；  resourceType＝ACQUIRE
＜m2m＞
＜acquire＞
＜request＞BLANK＜／request＞
＜keepUpdate＞Onlyonce＜／keepUpdate＞
＜／acquire＞
＜／m2m＞
【００７８】
POST要求のアドレス「／CSEBase／container」は、プロデューサデータリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション103の識別子である、要求を開始するアプリケーションの識別子を示す。resourceType＝ACQUIREは、作成される必要があるリソースのタイプがACQUIREタイプであることを示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値Onlyonceは、コンシューマアプリケーション103が更新されたプロデューサデータリソースを取得しようとしていることを示す。2つの＜acquire＞識別子間のコンテンツは、作成される必要があるリソースのコンテンツであり、要求コンテンツおよび更新識別子を含む。BLANKは、リソースが作成されたばかりのとき要求コンテンツが空白であることを示し、Onlyonceは、更新識別子keepUpdateの値がOnlyonceであることを示し、更新識別子の値はOnlyonceであり、ACQUIREタイプのリソースを作成した後、プラットフォーム／ゲートウェイ101が、containerリソースが一度更新に成功した後にのみ、acquireタイプのリソースの結果ステータスを処理前から処理成功に変更することができることを示し、containerリソースの最新データは、acquireタイプのリソースの要求コンテンツに格納される。しかしながら、containerリソースが後で再び更新された場合、変更されたcontainerリソースの最新データは、二度とacquireタイプのリソースの要求コンテンツに更新されない。
【００７９】
ステップ305．コンシューマアプリケーション2がプラットフォーム／ゲートウェイ101にリソース作成要求を送信し、リソース作成要求は、プロデューサデータリソースの子リソースを作成するようにプラットフォーム／ゲートウェイ101に命令するために使用され、プロデューサデータリソースの識別子、作成される必要があるリソースのタイプ、および作成される必要があるリソースのコンテンツを含む。
【００８０】
具体的には、リソース作成要求は以下の通りであり得る。
POST／CSEBase／container
X−M2M−From：AE2
Content−Type：application／vnd．onem2m−res＋xml；  resourceType＝ACQUIRE
＜m2m＞
＜acquire＞
＜request＞BLANK＜／request＞
＜keepUpdate＞always＜／keepUpdate＞
＜／acquire＞
＜／m2m＞
【００８１】
リソース作成要求は、リソース作成要求内の更新識別子がalwaysであるという点で、ステップ403におけるリソース作成要求とは異なる。更新識別子の値はalwaysであり、リソースを作成した後、プラットフォーム／ゲートウェイ101がcontainerリソースが更新されるのを待つ必要はないが、プロデューサデータリソースのデータコンテンツの現在値を直接取得し、現在値を要求コンテンツに格納し、acquireタイプのリソースの結果ステータスを処理前から処理成功に直接変更することを示す。
【００８２】
図3に示された実施形態とは異なり、本発明のこの実施形態では、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーションによって更新されたデータを能動的にコンシューマアプリケーションに送信しないことに留意されたい。コンシューマアプリケーションが最新データを取得する必要があるとき、コンシューマアプリケーションは、acquireタイプのリソース内の要求コンテンツまたはプロデューサデータリソース内のデータコンテンツを能動的に取得する必要がある。能動的取得のプロセスは、当業者によく知られた技術であり、詳細は本明細書では再び記載されない。
【００８３】
本発明の一実施形態は、図3に記載された方法実施形態と同じ独創的なアイデアに属するデータリソースプラットフォームの概略構造図をさらに記載する。図5に示されたように、データリソースプラットフォーム500は、図3に記載された方法実施形態におけるプラットフォーム／ゲートウェイ101の機能を実行するように構成され、受信ユニット501と、処理ユニット503と、送信ユニット505とを含む。
【００８４】
受信ユニット501は、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信するように構成され、要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する。処理ユニット503は、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新するように構成される。送信ユニット505は、更新されたプロデューサデータリソースをコンシューマアプリケーションに返信するように構成される。
【００８５】
場合によっては、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信する前に、受信ユニット501は、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、サブスクリプションリソース作成要求は、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む。処理ユニット503は、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される。
【００８６】
可能な実装形態では、処理ユニットにより、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的には：指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行すること、事前設定動作がトリガ条件を満たすと判断すること、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信すること、プロデューサアプリケーションによって返信された現時点のデータを受信すること、およびプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することである。
【００８７】
トリガ条件は、プロデューサデータリソースの子リソースを作成することであって、子リソースのタイプが事前設定タイプである、作成すること、および／または作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限を含む。
【００８８】
さらに、子リソースは結果ステータスおよび要求コンテンツを含み、送信ユニットがプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新した後、処理ユニットは、結果ステータスを処理前状態から処理成功状態に変更し、現時点のデータを使用して要求コンテンツを更新するようにさらに構成される。
【００８９】
この実施形態では、データリソースプラットフォーム500は、機能ユニットの形態で提示される。本明細書における「ユニット」は、特定用途向け集積回路（application−specific integrated circuit、ASIC）、回路、1つもしくは複数のソフトウェアもしくはファームウェアのプログラムを実行するためのプロセッサ、メモリ、集積論理回路、および／または前述の機能を実現することができる別のデバイスであってもよい。簡単な実施形態では、当業者は、データリソースプラットフォーム500が図2に示された形態であってもよいと考えることができる。受信ユニット501、処理ユニット503、および送信ユニット505は、図3のプロセッサおよびメモリを使用して実装されてもよい。具体的には、受信ユニット501および送信ユニット505は、プロセッサが第1の対話モジュールを実行することによって実装されてもよく、処理ユニット503は、プロセッサが第1の処理モジュールを実行することによって実装されてもよい。
【００９０】
本発明の一実施形態は、図3に記載された方法実施形態と同じ独創的なアイデアに属するデータリソースプラットフォームの概略構造図をさらに記載する。図6に示されたように、データリソースプラットフォーム600は、図3に記載された方法実施形態におけるプラットフォーム／ゲートウェイ101の機能を実行するように構成され、受信ユニット601と、処理ユニット605と、送信ユニット603とを含む。
【００９１】
受信ユニット601は、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信するように構成され、要求メッセージは、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する。送信ユニット603は、プロデューサデータリソースをコンシューマアプリケーションに返信するように構成される。処理ユニット605は、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新するように構成される。
【００９２】
場合によっては、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信する前に、受信ユニット601は、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、サブスクリプションリソース作成要求は、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む。処理ユニット605は、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される。
【００９３】
可能な実装形態では、処理ユニット605により、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的には：指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行すること、事前設定動作がトリガ条件を満たすと判断すること、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信すること、プロデューサアプリケーションによって返信された現時点のデータを受信すること、およびプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することである。トリガ条件は、プロデューサデータリソースの子リソースを作成することであって、子リソースのタイプが事前設定タイプである、作成すること、および／または作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限を含む。
【００９４】
この実施形態では、データリソースプラットフォーム600は、機能ユニットの形態で提示される。本明細書における「ユニット」は、特定用途向け集積回路（application−specific integrated circuit、ASIC）、回路、1つもしくは複数のソフトウェアもしくはファームウェアのプログラムを実行するためのプロセッサ、メモリ、集積論理回路、および／または前述の機能を実現することができる別のデバイスであってもよい。簡単な実施形態では、当業者は、データリソースプラットフォーム600が図2に示された形態であってもよいと考えることができる。受信ユニット601、送信ユニット603、および処理ユニット605は、図2のプロセッサおよびメモリを使用して実装されてもよい。具体的には、受信ユニット601および送信ユニット603は、プロセッサが第2の対話モジュールを実行することによって実装されてもよく、処理ユニット605は、プロセッサが第2の処理モジュールを実行することによって実装されてもよい。
【００９５】
本発明の一実施形態は、データリソースプラットフォームによって使用されるコンピュータソフトウェア命令を記憶するように構成されたコンピュータ記憶媒体をさらに提供し、コンピュータ記憶媒体は、前述の方法実施形態を実行するために設計されたプログラムを含む。記憶されたプログラムを実行することにより、データリソースを取得するための方法が実装される場合がある。
【００９６】
本発明は、実施形態を参照して記載されているが、保護を主張する本発明を実装するプロセスにおいて、当業者は、添付の図面、開示された内容、および添付の特許請求の範囲を参照することにより、開示された実施形態の別の変形形態を理解し実装することができる。特許請求の範囲では、「含む」（comprising）は別の構成要素または別のステップを排除せず、「a」または「one」は複数のケースを排除しない。単一のプロセッサまたは別のユニットは、特許請求の範囲に列挙されたいくつかの機能を実装することができる。いくつかの手段が相互に異なる従属請求項に列挙されているという事実は、これらの手段の組合せがより良い結果をもたらすことができないことを示すものではない。
【００９７】
本発明の実施形態は、方法、装置（デバイス）、またはコンピュータプログラム製品として提供される場合があることを当業者なら理解されよう。したがって、本発明は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組合せを有する実施形態の形態を使用してもよい。その上、本発明は、コンピュータ使用可能プログラムコードを含む、（限定はしないが、ディスクメモリ、CD−ROM、光メモリなどを含む）1つまたは複数のコンピュータ使用可能記憶媒体に実装されたコンピュータプログラム製品の形態を使用してもよい。コンピュータプログラムは、適切な媒体に記憶／分配され、別のハードウェアとともにハードウェアの一部として提供もしくは使用されるか、あるいは、Internetまたは別の有線もしくはワイヤレスの電気通信システムを使用することなどにより、別の分配形態を使用してもよい。
【００９８】
本発明は、本発明の実施形態による、方法、装置（デバイス）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して記載されている。コンピュータプログラム命令は、フローチャートおよび／またはブロック図の各プロセスおよび／または各ブロック、ならびにフローチャートおよび／またはブロック図のプロセスおよび／またはブロックの組合せを実装するために使用される場合があることを理解されたい。これらのコンピュータプログラム命令は、機械を生成するために、汎用コンピュータ、専用コンピュータ、組込み型プロセッサ、または任意の他のプログラマブルデータ処理デバイスのプロセッサに提供される場合があり、その結果、コンピュータまたは任意の他のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装するための装置を生成する。
【００９９】
これらのコンピュータプログラム命令は、特定の方式で動作するようにコンピュータまたは任意の他のプログラマブルデータ処理デバイスに命令することができるコンピュータ可読メモリに記憶される場合もあり、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生成する。命令装置は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装する。
【０１００】
これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにロードされる場合もあり、その結果、一連の動作およびステップは、コンピュータまたは別のプログラマブルデータ処理デバイス上で実行され、それにより、コンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラマブルデータ処理デバイス上で実行される命令は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装するためのステップを実現する。
【０１０１】
本発明は、具体的な特徴およびそれらの実施形態を参照して記載されているが、明らかに、本発明の精神および範囲から逸脱することなく、それらに対して様々な修正および組合せを行うことができる。それに対応して、本明細書および添付の図面は、添付の特許請求の範囲によって定義される本発明の説明の単なる例であり、本発明の範囲を包含する修正、変形、組合せ、または均等物のいずれかまたはすべてと見なされる。明らかに、当業者は、本発明の趣旨および範囲から逸脱することなく、本発明に対して様々な修正および変形を行うことができる。本発明は、以下の特許請求の範囲およびそれらの等価な技術によって定義される保護範囲内に入るという条件で、これらの修正および変形を包含するものである。
【符号の説明】
【０１０２】
100  現行のアーキテクチャ
101  プラットフォーム／ゲートウェイ
102  コンシューマ端末
103  コンシューマアプリケーション
104  プロデューサ端末
105  プロデューサアプリケーション
106  ネットワーク
200  コンピュータデバイス
201  プロセッサ
202  通信バス
203  メモリ
204  通信インタフェース
205  出力デバイス
206  入力デバイス
208  プロセッサ
500  データリソースプラットフォーム
501  受信ユニット
503  処理ユニット
505  送信ユニット
600  データリソースプラットフォーム
601  受信ユニット
603  送信ユニット
605  処理ユニット
【図１】
2019506785.tif 000003
【図２】
2019506785.tif 000004
【図３】
2019506785.tif 000005
【図４】
2019506785.tif 000006
【図５】
2019506785.tif 000007
【図６】
2019506785.tif 000008
【手続補正書】
【提出日】平成30年6月25日(2018.6.25)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マシンツーマシン通信（Machine−to−Machine Communications、M2M）技術の分野に関し、詳細には、リソース取得方法および装置に関する。
【背景技術】
【０００２】
マシンツーマシン通信（Machine−to−Machine Communications、M2M）は、マシン間の知的な対話をコアとするネットワーク化されたアプリケーションおよびサービスである。M2Mは、モニタリング、スケジューリングコマンド、データ収集、測定などの面でユーザの情報化要件を満たすために、ワイヤレスまたは有線の通信モジュールおよびアプリケーション処理ロジックをマシンに挿入することにより、手動介入なしにデータ通信を実現する。
【０００３】
M2Mでは、通常、アプリケーションが別のアプリケーションによって生成された値を読み取る必要があるシナリオに遭遇する。たとえば、温度センサは、市役所や公園などの公共エリアに設置され、収集した温度値をM2Mプラットフォームに継続的に報告し、温度値は（以下、温度リソースと略称される）リソース形式でM2Mプラットフォームに格納される。リソースは、RESTfulアーキテクチャの情報のカプセル化であり、磁気ディスクに格納されたテキスト、またはデータベース内のデータレコードであってもよい。リソースには、データ自体、データのメタデータ、データ提示方法などが含まれる。このシナリオでは、公園に行く予定の訪問者は、ウェブページまたは携帯電話クライアントを使用することにより、M2Mプラットフォーム内の温度リソースに取得要求を送信する方式で、M2Mプラットフォームに格納された温度値を読み取ることができ、その要求に対する応答は温度値を搬送する。そのようなシナリオでは、センサは、データ（つまり温度値）を生成し、M2Mプラットフォームに温度値を報告するように構成されたプロデューサアプリケーションであり、Webページまたは携帯電話クライアントは、データを消費し、M2Mプラットフォーム内の温度値を読み取るように構成されたコンシューマアプリケーションである。
【０００４】
従来のM2Mシステムでは、プロデューサアプリケーションは、プロデューサアプリケーションによって生成されたデータに関心があるコンシューマアプリケーションの数を知ることができない。コンシューマアプリケーションがデータを取得しない場合でも、プロデューサアプリケーションは更新要求をさらに継続的に送信する。反対に、コンシューマアプリケーションは、更新されたデータが現在M2Mプラットフォームに格納されているかどうかを知ることができない。したがって、プロデューサアプリケーションがデータをリフレッシュしていない場合でも、コンシューマアプリケーションは取得要求をさらに継続的に送信するが、通常は古いデータが取得される。
【０００５】
いくつかの実際の配置、たとえば、上述されたシナリオでは、センサは、限られたデバイス、つまりバッテリ駆動センサであり、CPU処理能力、メモリ、およびネットワーク帯域幅はすべて制限される。それは、ネットワーク接続またはウェイクアップ回数を可能な限り減らすことを目的としており、それにより、稼働時間を引き延ばす長い休止時間が保証される。現在のシナリオでは、データのプロデューサアプリケーションとコンシューマアプリケーションは、情報間で整合しない。その結果、プロデューサアプリケーションによって報告されたデータを取得するプロセスにおいて、コンシューマアプリケーションは、冗長なメッセージの送信および浪費に連続して遭遇する。
【発明の概要】
【０００６】
本発明は、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、リソース取得方法および装置を提供する。
【課題を解決するための手段】
【０００７】
前述の目的を達成するために、本発明の実施形態において以下の技術的解決策が使用される。
【０００８】
第1の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信し、要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する。従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーションにデータコンテンツを直接フィードバックする代わりに、プラットフォームは、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新し、次いで、更新されたプロデューサデータリソースをコンシューマアプリケーションに返信する。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。その上、方法は、コンシューマアプリケーションがデータを取得するときに、データがリフレッシュされておらず、結果として古いデータが取得されるケースを回避するために、コンシューマアプリケーションがプロデューサアプリケーションによって生成された最新データを取得できることを保証することができる。
【０００９】
第2の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信することであって、要求メッセージが、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する、受信することと、コンシューマアプリケーションにプロデューサデータリソースを返信することと、次いで、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することとを行う。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。その上、方法によれば、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信した後、プラットフォームは、プロデューサデータリソースのデータコンテンツ内の現在データを取得し、コンシューマアプリケーションに現在データを返信し、コンシューマアプリケーションが時間内にデータを取得することを保証し、さらに、プロデューサアプリケーションをトリガしてプロデューサデータリソースを更新し、その結果、コンシューマアプリケーションは、次回データを取得するときに更新されたデータを取得することができる。
【００１０】
可能な設計では、前述の第1の態様または第2の態様において、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージをプラットフォームが受信する前に、方法は以下のステップをさらに含む。プラットフォームは、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信することであって、サブスクリプションリソース作成要求が、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、受信することと、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成することとを行う。プロデューサデータリソースのサブスクリプションリソースはプラットフォーム上に作成され、その結果、プロデューサデータリソースが事前設定変更を有するとき、プラットフォームは、時間内にプロデューサアプリケーションに通知メッセージを送信することができ、通知メッセージは、プロデューサデータリソースを更新するようにプロデューサアプリケーションに命令するために使用される。したがって、プロデューサアプリケーションは、コンシューマアプリケーションが、これに応答するために、最新データを取得しようとしていることを時間内に知る。
【００１１】
可能な設計では、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的に以下のようであり得る：プラットフォームは、指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行することと、実行された事前設定動作がトリガ条件を満たすと判断することと、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信することと、プロデューサアプリケーションによって返信された現時点のデータを受信することと、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することとを行う。プラットフォーム／ゲートウェイ101が、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーション103によって送信された要求メッセージを受信すると、従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーション103にデータコンテンツを直接フィードバックする代わりに、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースに対して事前設定動作を実行して、最新データを取得するための通知メッセージをプロデューサアプリケーションに送信するようにプラットフォーム／ゲートウェイ101をトリガする。本発明のこの実施形態における方法を用いて、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいて、プロデューサデータリソースを更新することができる。
【００１２】
可能な設計では、トリガ条件は、プロデューサデータリソースの子リソースを作成することを含み、子リソースのタイプは事前設定タイプである。特定のタイプのプロデューサデータリソースの子リソースを作成する方式では、プラットフォームは、より柔軟で効果的なトリガ機構を実現するために、プロデューサデータリソース自体に対して動作を実行する代わりに、プロデューサアプリケーションに通知メッセージを送信するようにトリガされる。場合によっては、トリガ条件は、作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限をさらに含む。
【００１３】
別の可能な設計では、子リソースは結果ステータスおよび要求コンテンツを含み、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新するステップの後に、方法は、結果ステータスを処理前状態から処理成功状態に変更するステップと、現時点のデータを使用して要求コンテンツを更新するステップとをさらに含む。
【００１４】
第3の態様によれば、本発明の一実施形態はリソース取得方法を提供する。方法は、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、以下のステップを含む。プラットフォームは、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信することであって、サブスクリプションリソース作成要求が、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、受信することと、サブスクリプションリソース作成要求に基づいてプロデューサデータリソースのサブスクリプションリソースを作成することと、コンシューマアプリケーションによって送信された動作要求を受信することと、動作要求に基づいてプロデューサデータリソースに対して事前設定動作を実行することと、実行された事前設定動作がトリガ条件を満たすと判断することと、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信することと、プロデューサアプリケーションによって返信された現時点のデータを受信することと、プロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することとを行う。本発明のこの実施形態で提供される方法によれば、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。
【００１５】
第4の態様によれば、本発明の一実施形態はデータリソースプラットフォームを提供する。データリソースプラットフォームは、第1から第3の態様のリソース取得方法におけるプラットフォームの動作を実装する機能を有する。この機能は、ハードウェアを使用して実装されてもよいし、ハードウェアが対応するソフトウェアを実行することによって実装されてもよい。ハードウェアまたはソフトウェアは、前述の機能に対応する1つまたは複数のモジュールを含む。
【００１６】
可能な設計では、データリソースプラットフォームの構造は、プロセッサおよびメモリを含む。メモリは、前述の方法を実行するデータベース処理デバイスをサポートするプログラムを記憶するように構成され、プロセッサは、メモリに記憶されたプログラムを実行するように構成される。データベース処理デバイスは、別のデバイスまたは通信ネットワークと通信するためにデータベース処理デバイスによって使用される通信インタフェースをさらに含む場合がある。
【００１７】
第5の態様によれば、本発明の一実施形態は、前述のデータリソースプラットフォームによって使用されるコンピュータソフトウェア命令を記憶するように構成されたコンピュータ記憶媒体を提供し、コンピュータ記憶媒体は、データリソースプラットフォーム用に設計され、前述の態様を実行するように構成されたプログラムを含む。
【００１８】
可能な設計では、同じコンシューマアプリケーションが、データリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信するたびに、プラットフォーム／ゲートウェイ101は、acquireタイプの新しい子リソースを作成する。プラットフォーム／ゲートウェイ101の処理負荷を軽減するために、プラットフォーム／ゲートウェイ101は、ルールに従って、作成されたacquireタイプのリソースを削除する。たとえば、acquireタイプの各リソースは、acquireタイプのリソースの作成から始まるライフサイクルをもち、acquireタイプのリソースの存在時間がライフサイクルを超えたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、acquireタイプのリソースの結果ステータスが処理失敗もしくは処理中であるとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、またはacquireタイプのリソースの更新識別子がalwaysであり、結果ステータスが処理失敗もしくは処理中あると判断されたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除する。
【００１９】
従来技術と比較して、本発明で提供される解決策は、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決することができる。
【００２０】
本発明のこれらの態様または別の態様は、以下の実施形態の説明において、より簡潔で、容易に理解可能である。
【図面の簡単な説明】
【００２１】
【図１】本発明の一実施形態による、リソースを取得するための現行のアーキテクチャの図である。
【図２】本発明の一実施形態による、コンピュータデバイスの概略図である。
【図３】本発明の一実施形態による、リソース取得方法の概略フローチャートである。
【図４】本発明の一実施形態による、別のリソース取得方法の概略フローチャートである。
【図５】本発明の一実施形態による、データリソースプラットフォームの概略構造図である。
【図６】本発明の一実施形態による、別のデータリソースプラットフォームの概略構造図である。
【発明を実施するための形態】
【００２２】
本発明の目的、技術的解決策、および利点をより明確にするために、以下で、添付図面を参照して、詳細に本発明の実施形態をさらに説明する。
【００２３】
図1は、本発明の一実施形態による、リソースを取得するための現行のアーキテクチャを記載する。現行のアーキテクチャ100は、従来のM2Mアーキテクチャに基づき、プラットフォーム／ゲートウェイ101と、（端末A、B、およびCなどの）コンシューマ端末102と、（端末Xなどの）プロデューサ端末104とを含む。コンシューマアプリケーション103がコンシューマ端末102にインストールされ、コンシューマアプリケーション103は、ネットワーク106を使用してプラットフォーム／ゲートウェイ101にリモートアクセスし、プラットフォーム／ゲートウェイ101を使用して、プロデューサ端末104内のプロデューサアプリケーション105によって収集されたデータを取得する。プロデューサアプリケーション105はプロデューサ端末104にインストールされ、プロデューサアプリケーション105は、ネットワーク106を使用してプラットフォーム／ゲートウェイ101に収集されたデータを送信し、その結果、プラットフォーム／ゲートウェイは、プロデューサアプリケーション105によって収集されたデータをコンシューマアプリケーション103に供給する。
【００２４】
本発明のこの実施形態では、コンシューマアプリケーション103がインストールされるコンシューマ端末102は、図示された端末A、B、およびCに限定されないことに留意されたい。実際、コンシューマアプリケーションの量は極めて大量の場合があり、プロデューサアプリケーション105によって収集されたデータは、M2Mネットワークに接続された多くのコンシューマ端末102内のコンシューマアプリケーション103によって同時に使用される場合がある。プロデューサアプリケーション105によって収集されたデータは、（以下、プロデューサデータリソースと略称される）リソース形式でプラットフォーム／ゲートウェイ101に格納される。プラットフォーム／ゲートウェイ101に格納されるプロデューサデータリソースには、リソース識別子、データコンテンツなどが含まれる。従来技術では、コンシューマアプリケーション103がプロデューサデータリソースを取得する必要があるとき、プロデューサデータリソースのリソース識別子を搬送するデータリソース取得要求のみが、プラットフォーム／ゲートウェイ101に送信される必要がある。しかしながら、プロデューサアプリケーション105は収集されたデータをリアルタイムでプラットフォーム／ゲートウェイ101に送信しないので、コンシューマアプリケーション103によって取得されたプロデューサデータリソースは最新ではない可能性が高い。コンシューマアプリケーション103によって取得されたプロデューサデータリソースがプロデューサアプリケーション105によって収集された最新データであることを保証するために、コンシューマアプリケーション103によってプラットフォーム／ゲートウェイ101に送信されるデータリソース取得要求は、最新データを返信するようにプラットフォーム／ゲートウェイ101に命令するために使用される指示情報を搬送する。コンシューマアプリケーション103によって送信されたデータリソース取得要求を受信した後、プラットフォーム／ゲートウェイ101は、データリソース取得要求内の指示情報に基づいて、コンシューマアプリケーション103がプロデューサアプリケーション103によって収集された最新データを取得しようとしていると判断し、プロデューサアプリケーション105に通知メッセージを送信し、通知メッセージは、コンシューマアプリケーション103が取得することを要求した収集された最新データが存在することをプロデューサアプリケーション105に通知するために使用される。プラットフォーム／ゲートウェイ101によって送信された通知メッセージを受信した後、プロデューサアプリケーション105は、最新データを収集し、プラットフォーム／ゲートウェイ101に最新データを送信する。プラットフォーム／ゲートウェイ101は、受信された最新データに基づいてプロデューサデータリソースを更新し、収集された最新データを搬送する応答メッセージをコンシューマアプリケーション103に送信する。
【００２５】
プラットフォーム／ゲートウェイ101は、M2Mシステム内のIN（Infrastructure Node、基盤ノード）またはMN（Middle Node、中間ノード）であってもよく、コンシューマ端末102／プロデューサ端末104は、ASN（Application Service Node、アプリケーションサービスノード）またはADN（Application Dedicated Node、アプリケーション専用ノード）であってもよい。具体的には、コンシューマ端末102は、携帯電話、PC、およびipadなどの、M2Mシステムに接続された様々なモバイル端末であってもよい。コンシューマアプリケーション103は、空気温度計アプリケーション、電気メータアプリケーション、または高度道路交通アプリケーションなどの、コンシューマ端末102にインストールされた任意のアプリケーションプログラムであってもよい。プロデューサ端末104は、たとえば、温度センサなどの様々なセンサであってもよい。コンシューマアプリケーション103は、コンシューマ端末にインストールされた任意のアプリケーションプログラムである。ネットワーク106は、プラットフォーム／ゲートウェイ101、たとえば、Local Area Networks（LAN）またはWireless Local Area Networks（WLAN）などの任意の通信ネットワークと通信し、接続することを、コンシューマ端末102／プロデューサ端末104に行わせるために使用される任意の媒体であってもよい。
【００２６】
本発明のこの実施形態では、最新データを返信するようにプラットフォーム／ゲートウェイ101に命令するために使用される指示情報は、プロデューサアプリケーション105から収集された最新データを取得し、収集された最新データをコンシューマアプリケーション103に返信するようにプラットフォーム／ゲートウェイ101に命令するために、プラットフォーム／ゲートウェイ101に送信されたデータリソース取得要求内でコンシューマアプリケーション103によってさらに搬送される。本発明のこの実施形態では、コンシューマアプリケーション103が最新データを取得する必要がないとき、プロデューサアプリケーション103はデータを収集する必要がない。これにより、コンシューマアプリケーション103がプロデューサアプリケーション103によって報告されたデータを必要としないことによって生じる浪費が回避され、プロデューサ端末104の電力消費が低減され、コンシューマアプリケーション103が最新データを取得する必要があるときに古いデータを取得しないことが保証される。
【００２７】
図2に示されように、図1のコンシューマ端末102およびプラットフォーム／ゲートウェイ101は、図2のコンピュータデバイス（またはシステム）を用いて実装される場合がある。
【００２８】
図2は、本発明の一実施形態による、コンピュータデバイスの概略図である。コンピュータデバイス200は、少なくとも1つのプロセッサ201と、通信バス202と、メモリ203と、少なくとも1つの通信インタフェース204とを含む。
【００２９】
プロセッサ201は、汎用中央処理装置（CPU）、マイクロプロセッサ、特定用途向け集積回路（application−specific integrated circuit、ASIC）、または本発明の解決策のプログラムの実行を制御するように構成された1つもしくは複数の集積回路であってもよい。
【００３０】
通信バス202は、構成要素間で情報を送信するための経路を含む場合がある。通信インタフェース204は、任意のトランシーバタイプの装置に適用可能であり、別のデバイス、または、イーサネット（登録商標）、無線アクセスネットワーク（RAN）、もしくは無線ローカルエリアネットワーク（Wireless Local Area Networks、WLAN）などの通信ネットワークと通信するように構成される。
【００３１】
メモリ203は、読取り専用メモリ（read−only memory、ROM）もしくは静的情報および静的命令を記憶することができる別のタイプの静的ストレージデバイス、またはランダムアクセスメモリ（random access memory、RAM）もしくは情報および命令を記憶することができる別のタイプの動的ストレージデバイスであってもよく、電気的消去可能プログラマブル読出し専用メモリ（Electrically Erasable Programmable Read−Only Memory、EEPROM）、コンパクトディスク読取り専用メモリ（Compact Disc Read−Only Memory、CD−ROM）もしくは別のコンパクトディスク記憶媒体、（コンパクトディスク、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク、ブルーレイディスクなどを含む）光ディスク記憶媒体および磁気ディスク記憶媒体、別の磁気ストレージデバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送もしくは記憶するように構成することができ、コンピュータにアクセス可能な任意の他の媒体であってもよいが、それらに限定されない。メモリは、独立して存在し、バスを使用してプロセッサに接続されてもよい。あるいは、メモリは、プロセッサと一体化されてもよい。
【００３２】
メモリ203は、本発明の解決策を実行するためのアプリケーションプログラムコードを記憶するように構成され、実行はプロセッサ201によって制御される。プロセッサ201は、メモリ203に記憶されたアプリケーションプログラムコードを実行するように構成される。
【００３３】
具体的な実装の間、一実施形態では、プロセッサ201は、1つまたは複数のCPU、たとえば、図2のCPU0およびCPU1を含む場合がある。
【００３４】
具体的な実装の間、一実施形態では、コンピュータデバイス200は、図2の中にあるプロセッサ201およびプロセッサ208などの複数のプロセッサを含む場合がある。これらのプロセッサの各々は、シングルCPU（single−CPU）プロセッサであってもよく、マルチCPU（multi−CPU）プロセッサであってもよい。本明細書では、プロセッサは、（コンピュータプログラム命令などの）データを処理するように構成された1つまたは複数のデバイス、回路、および／または処理コアであってもよい。
【００３５】
具体的な実装の間、一実施形態では、コンピュータデバイス200は、出力デバイス205および入力デバイス206をさらに含む場合がある。出力デバイス205は、プロセッサ201と通信し、複数の方式で情報を表示することができる。たとえば、出力デバイス205は、液晶ディスプレイ（liquid crystal display、LCD）、発光ダイオード（light emitting diode、LED）表示デバイス、陰極線管（cathode ray tube、CRT）表示デバイス、プロジェクタ（projector）などであってもよい。入力デバイス206は、プロセッサ201と通信し、複数の方式でユーザの入力を受け取ることができる。たとえば、入力デバイス206は、マウス、キーボード、タッチスクリーンデバイス、センサデバイスなどであってもよい。
【００３６】
コンピュータデバイス200は、汎用コンピュータデバイスまたは専用コンピュータデバイスであってもよい。具体的な実装の間、コンピュータデバイス200は、デスクトップコンピュータ、ポータブルコンピュータ、ネットワークサーバ、パームトップコンピュータ（Personal Digital Assistant、PDA）、携帯電話、タブレットコンピュータ、ワイヤレス端末デバイス、通信デバイス、組込み型デバイス、または図2のデバイスに類似する構造を有するデバイスであってもよい。本発明のこの実施形態では、コンピュータデバイス200のタイプは限定されない。
【００３７】
図1に示されたコンシューマ端末102は、図2に示されたデバイスであってもよく、1つまたは複数のソフトウェアモジュール（たとえば、第1の対話モジュールおよび第1の処理モジュール）が、コンシューマ端末102のメモリに記憶されてもよい。コンシューマ端末102は、最新のプロデューサデータを取得するために、プロセッサおよびメモリ内のプログラムコードを使用してソフトウェアモジュールを実装することができる。1つまたは複数のソフトウェアモジュール（たとえば、第2の対話モジュールおよび第2の処理モジュール）は、プラットフォーム／ゲートウェイ101のメモリに記憶される。コンシューマ端末102は、プロデューサアプリケーション105から最新のプロデューサデータを取得し、コンシューマアプリケーション103に最新のプロデューサデータを送信するために、プロセッサおよびメモリ内のプログラムコードを使用してソフトウェアモジュールを実装することができる。
【００３８】
図1に示された現行のアーキテクチャの図に基づいて、現行のアーキテクチャにおけるコンシューマアプリケーション103がリソースを取得する処理プロセスをより明確に記載するために、本発明の実施形態は、リソース取得方法の概略フローチャートを提供する。プロデューサアプリケーション105は、プラットフォーム／ゲートウェイ101がプロデューサデータリソースの事前設定タイプの子リソース、たとえば、acquireタイプの子リソースを作成するとき、プロデューサアプリケーション105に通知メッセージを送信するように命令するために、プロデューサデータリソースの子リソースとしてサブスクリプションリソースを作成するように、プラットフォーム／ゲートウェイ101要求する。通知メッセージを受信すると、プロデューサアプリケーション105は最新データを収集し、プラットフォーム／ゲートウェイ101に最新データを送信する。コンシューマアプリケーション103がプロデューサアプリケーション105によって収集された最新データを取得する必要があるとき、プロデューサデータリソースの事前設定タイプの子リソースを作成するようにプラットフォーム／ゲートウェイ101をトリガすることができる取得要求のみが、プラットフォーム／ゲートウェイ101に送信される必要がある。
【００３９】
図3に示されたように、図3は、本発明の一実施形態による、リソース取得方法の概略フローチャートである。たとえば、oneM2Mでは、プロデューサアプリケーション105によって報告された温度値などのデータが格納されるプロデューサデータリソースとして、containerリソースが使用される。その上、プロデューサデータリソースのためにサブスクリプションリソースが作成され、containerリソースに変更があると、プラットフォーム／ゲートウェイ101は、サブスクリプションリソースに基づいて対応する加入者に通知メッセージを送信する。本発明のこの実施形態では、コンシューマアプリケーション103がcontainerリソースの最新の状態を取得するように試みたとき、プロデューサアプリケーション105は通知メッセージを受信する。プロデューサアプリケーション105が最新データを使用してcontainerリソースを更新した後、コンシューマアプリケーション103は、更新されたcontainerリソース内のデータコンテンツに格納されたデータを取得することができる。この実施形態では、説明および記載を行うためにoneM2M規格が例として使用される。プロデューサデータリソースはcontainerリソースであり、サブスクリプションリソースはsubscriptionリソースである。
【００４０】
ステップ301．プロデューサアプリケーション105がプラットフォーム／ゲートウェイ101にサブスクリプションリソース作成要求を送信し、サブスクリプションリソース作成要求は、サブスクリプションリソースの識別子、加入者の識別子、サブスクリプションイベントのトリガ条件を含む。
【００４１】
具体的には、本発明のこの実施形態では、サブスクリプションリソースの識別子は、プロデューサデータリソースの識別子、すなわちcontainerリソースの識別子であり、加入者の識別子はプロデューサアプリケーション105の識別子である。サブスクリプションリソースに対して事前設定動作が実行されるので、サブスクリプションリソースが事前設定変更を有するとき、加入者に通知メッセージを送信するようにプラットフォーム／ゲートウェイ101がトリガされる。サブスクリプションリソースが事前設定変更を有することを可能にする事前設定動作は、サブスクリプションイベントのトリガ条件である。本発明のこの実施形態では、サブスクリプションイベントのトリガ条件は、具体的には、プロデューサデータリソースの子リソースを作成することであり、子リソースのタイプは事前設定タイプである。場合によっては、トリガ条件は、作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限をさらに含む。
【００４２】
可能な設計では、プロデューサアプリケーション105は、以下のように、プラットフォーム／ゲートウェイ101にサブスクリプションリソース作成要求を送信することができる。
POST／CSEBase／container
＜m2m＞
＜subscription＞
＜eventType＞CHILD＿CREATION＜／eventType＞
＜resourceType＞ACQUIRE＜／resourceType＞
＜batchNotify＞2＜／batchNotify＞
＜originatorID＞ALL＜／originatorID＞
＜creator＞AEX＜／creator＞
＜notificationURI＞http：／／example．SP．AE1＜／notificationURI＞
＜／subscription＞
＜／m2m＞
【００４３】
POSTT要求のアドレス「／CSEBase／container」は、本明細書におけるプロデューサデータリソースの識別子であるサブスクリプションリソースの識別子を示す。＜subscription＞は、プロデューサアプリケーション105がプロデューサデータリソースの下にサブスクリプションリソースを作成しようとしていることを示し、サブスクリプションリソースのeventTypeはチャイルドリソースの作成のみに関心があることを示すchild creationであり、resourceTypeは、acquireタイプの子リソースのみに関心があることを示すacquireであり、batchNotifyは、イベントが少なくとも2回トリガされたときにのみ通知が送信されることを示す2に設定され、本明細書でのイベントはacquireタイプの子リソースの作成であり、creatorは、本明細書ではコンシューマアプリケーションの識別子である加入者の識別子を示し、notificationURIは、加入者が通知メッセージを受信したアドレスを示す。すなわち、プロデューサデータリソースの作成された子リソースのリソースタイプがacquireであり、子リソースの数が2よりも大きいとき、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105に通知メッセージを送信し、通知メッセージを送信するためのアドレスはhttp：／／example．SP．AE1である。
【００４４】
可能な設計では、プロデューサデータリソースのacquireタイプの2つの子リソースの作成時間間隔が事前設定時間を超えることなどの、サブスクリプションイベントの別のトリガ条件がさらに設定される場合がある。様々なトリガ条件を設定することにより、プロデューサ端末のデータ取得の適時性と消費電力とのバランスが良好になり得る。様々なトリガ条件は、一緒に使用されてもよく、各々が単独で使用されてもよく、本発明ではトリガ条件は限定されない。
【００４５】
ステップ302．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105によって送信されたサブスクリプションリソース作成要求を受信し、サブスクリプションリソースを作成し、サブスクリプションリソースはプロデューサデータリソースの子リソースである
【００４６】
具体的には、プラットフォーム／ゲートウェイ101により、受信されたサブスクリプションリソース作成要求に基づいてプロデューサデータリソースの下にサブスクリプションリソースを作成することは、当業者によく知られた技術であり、詳細は本明細書では再び記載されない。
【００４７】
ステップ303．コンシューマアプリケーション1がデータリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信し、データリソースを取得するために使用される要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するようにプラットフォーム／ゲートウェイ101に命令する指示情報を搬送する。
【００４８】
具体的には、コンシューマアプリケーション1は、プラットフォーム／ゲートウェイ101にretrieve要求を送信して、containerリソースを検索することを要求し、要求はkeepUpdate識別子を搬送する。keepUpdate識別子は、HTTPメッセージの拡張ヘッダを使用して送信される。
【００４９】
GET要求は以下の通りであり得る。
GET／CSEBase／container
X−M2M−From：AE1
X−M2M−KEEPUPDATE：Onlyonce
【００５０】
GET要求のアドレス「／CSEBase／container」は、本明細書ではプロデューサデータリソースの識別子である、サブスクリプションリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション103の識別子である、要求を開始するアプリケーションの識別子を示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値Onlyonceは、コンシューマアプリケーション103が更新されたプロデューサデータリソースを取得しようとしていることを示す。
【００５１】
ステップ304．プラットフォーム／ゲートウェイ101が、データリソースを取得するために使用され、コンシューマアプリケーション1によって送信された要求メッセージを受信し、要求メッセージ内の指示情報に基づいて、プロデューサデータリソースの子リソースとしてacquireタイプのリソースを作成する。
【００５２】
acquireタイプのリソースには、要求コンテンツ、結果ステータス、および更新識別子が含まれる。プラットフォーム／ゲートウェイ101が、要求メッセージ内の指示情報に基づいてacquireタイプのリソースを最初に作成するとき、要求コンテンツは空白であり、結果ステータスは処理前であり、更新識別子の値はOnlyonceである。結果ステータスは処理前であり、acquireタイプのリソースが処理前状態であることを示し、更新識別子の値はOnlyonceであり、プラットフォーム／ゲートウェイ101が、containerリソースが一度更新に成功した後にのみ、acquireタイプのリソースの結果ステータスを処理前から処理成功に変更することができることを示し、containerリソースの最新データはacquireタイプのリソースの要求コンテンツに格納される。しかしながら、containerリソースが後で再び更新された場合、変更されたcontainerリソースの最新データは、二度とacquireタイプのリソースの要求コンテンツに更新されない。containerリソースの更新に失敗した場合、acquireタイプのリソースの結果ステータスは処理前から処理失敗に変更される。
【００５３】
ステップ305．コンシューマアプリケーション2がデータリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信し、データリソースを取得するために使用される要求メッセージは、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令する指示情報を搬送する。
【００５４】
具体的には、コンシューマアプリケーション2は、プラットフォーム／ゲートウェイ101にretrieve要求を送信して、containerリソースを検索することを要求し、要求はkeepUpdate識別子を搬送する。keepUpdate識別子は、HTTPメッセージの拡張ヘッダを使用して送信される。
【００５５】
GET要求は以下の通りである。
GET／CSEBase／container
X−M2M−From：AE2
X−M2M−KEEPUPDATE：always
【００５６】
GET要求のアドレス「／CSEBase／container」は、本明細書ではプロデューサデータリソースの識別子である、サブスクリプションリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション2の識別子である、要求を開始するアプリケーションの識別子を示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値alwaysは、コンシューマアプリケーション103が現在のプロデューサデータリソースを取得しようとしていることを示す。
【００５７】
ステップ306．プラットフォーム／ゲートウェイ101が、データリソースを取得するために使用され、コンシューマアプリケーション2によって送信された要求メッセージを受信し、要求メッセージ内の指示情報に基づいて、プロデューサデータリソースの子リソースとしてacquireタイプのリソースを作成する。
【００５８】
acquireタイプのリソースには、要求コンテンツ、結果ステータス、および更新識別子が含まれる。プラットフォーム／ゲートウェイ101が、要求メッセージ内の指示情報に基づいてacquireタイプのリソースを最初に作成するとき、要求コンテンツは空白であり、結果ステータスは処理前であり、更新識別子の値はalwaysである。更新識別子の値はalwaysであり、プラットフォーム／ゲートウェイ101がcontainerリソースが更新されるのを待つ必要はないが、プロデューサデータリソースのデータコンテンツ内の現在値を直接取得し、現在値を要求コンテンツに格納し、次いで、acquireタイプのリソースの結果ステータスを処理前から処理成功に直接変更することを示す。
【００５９】
ステップ307．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105に通知メッセージを送信し、通知メッセージは、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される。
【００６０】
具体的には、サブスクリプションリソースが事前設定変更を有すると判断すると、プラットフォーム／ゲートウェイ101は加入者に通知メッセージを送信する。本発明のこの実施形態では、ステップ301の例によれば、サブスクリプションイベントのトリガ条件は、acquireタイプの少なくとも2つの子リソースがプロデューサデータリソースの下に作成されることである。ステップ304およびステップ306が実行された後、acquireタイプの2つの子リソースがプロデューサデータリソースの下に作成される。したがって、この場合、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105に通知メッセージを送信するようにトリガされる。
【００６１】
ステップ308．プラットフォーム／ゲートウェイ101がコンシューマアプリケーション2に応答メッセージを送信し、応答メッセージは、プロデューサデータリソースのデータコンテンツ内の現在値を搬送する。
【００６２】
ステップ307およびステップ308の順番は限定されないことに留意されたい。ステップ305において、コンシューマアプリケーション2によってプラットフォーム／ゲートウェイ101に送信された要求メッセージ内で搬送される指示情報は、現在のプロデューサデータリソースを返信し、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するので、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105が最新データを返信するのを待つ必要はなく、プロデューサデータリソースのデータコンテンツ内に格納された現在データを直接取得し、コンシューマアプリケーション2に現在データを返信する。場合によっては、プロデューサデータリソースのデータコンテンツに格納されたデータは、プロデューサデータリソース内のデータコンテンツからプラットフォーム／ゲートウェイ101によって取得されてもよく、ステップ306において作成されたacquireタイプのリソースの要求コンテンツから取得されてもよい。
【００６３】
ステップ309．プロデューサアプリケーション105が最新データを取得し、プラットフォーム／ゲートウェイ101に更新要求を送信し、更新要求は取得された最新データを含む。
【００６４】
場合によっては、プラットフォーム／ゲートウェイ101は、受信された通知メッセージに基づいて、containerリソースが更新される必要があると判断する。したがって、最新データが取得される。たとえば、現在の温度値が収集される。次いで、containerリソースを更新するように要求するために、プラットフォーム／ゲートウェイ101にupdate要求が送信され、update要求は取得された最新データを搬送する。
【００６５】
ステップ310．プラットフォーム／ゲートウェイ101がプロデューサアプリケーション105によって送信された更新要求を受信し、更新要求に基づいてプロデューサデータリソースを更新する。
【００６６】
具体的には、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーション105によって送信された更新要求内で搬送された最新データに基づいて、containerリソース内のデータコンテンツを更新する。
【００６７】
場合によっては、プラットフォーム／ゲートウェイ101は、containerリソースの下のacquireタイプの子リソースが更新される必要があるかどうかを1つずつさらに判定する。具体的には、プラットフォーム／ゲートウェイ101は、containerリソースの下のacquireタイプの子リソースの結果ステータスが処理前状態であるかどうかを1つずつ判定し、結果ステータスが処理前状態であるとき、更新要求内で搬送された最新データに基づいてacquireタイプの子リソースの対応する要求コンテンツを更新し、結果ステータスを処理成功に変更する。
【００６８】
ステップ311．プラットフォーム／ゲートウェイ101がコンシューマアプリケーション1に応答メッセージを送信し、応答メッセージは、プロデューサアプリケーション105によって返信された最新データを搬送する。
【００６９】
場合によっては、プロデューサアプリケーション105によって返信され、応答メッセージ内で搬送される最新データは、ステップ310において更新されたプロデューサデータリソース内のデータコンテンツからプラットフォーム／ゲートウェイ101によって取得されてもよく、acquireタイプの更新されたリソースの要求コンテンツから取得されてもよい。
【００７０】
可能な設計では、同じコンシューマアプリケーションが、データリソースを取得するために使用される要求メッセージをプラットフォーム／ゲートウェイ101に送信するたびに、プラットフォーム／ゲートウェイ101は、acquireタイプの新しい子リソースを作成する。プラットフォーム／ゲートウェイ101の処理負荷を軽減するために、プラットフォーム／ゲートウェイ101は、ルールに従って、作成されたacquireタイプのリソースを削除する。たとえば、acquireタイプの各リソースは、acquireタイプのリソースの作成から始まるライフサイクルをもち、acquireタイプのリソースの存在時間がライフサイクルを超えたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、acquireタイプのリソースの結果ステータスが処理失敗もしくは処理中であるとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除し、またはacquireタイプのリソースの更新識別子がalwaysであり、結果ステータスが処理失敗もしくは処理中あると判断されたとき、プラットフォーム／ゲートウェイ101はacquireタイプのリソースを削除する。
【００７１】
可能な設計では、プロデューサデータリソースのデータコンテンツは、常にプロデューサアプリケーションから受信された最新データを格納し、acquireタイプのリソースの要求コンテンツは、前述の実施形態における更新識別子がOnlyonceであるacquireタイプのリソースなどの、プロデューサアプリケーションによって生成された履歴データを格納することができる。プラットフォーム／ゲートウェイ101はさらに、データリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージをさらに受信し、データリソースを取得するために使用される要求メッセージは、前述のステップにおいて作成されたacquireタイプのリソースの識別子を搬送し、プラットフォーム／ゲートウェイ101は、acquireタイプの子リソースの識別子に基づいて、acquireタイプのリソースの要求コンテンツに格納されているデータを取得し、コンシューマアプリケーションにデータを返信する。
【００７２】
本発明のこの実施形態では、プラットフォーム／ゲートウェイ101が、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーション103によって送信された要求メッセージを受信すると、従来技術とは異なり、プロデューサデータリソース内のデータコンテンツを直接取得し、コンシューマアプリケーション103にデータコンテンツを直接フィードバックする代わりに、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースに対して事前設定動作を実行して、最新データを取得するための通知メッセージをプロデューサアプリケーションに送信するようにプラットフォーム／ゲートウェイ101をトリガする。プラットフォーム／ゲートウェイ101によって送信された通知メッセージを受信した後、プロデューサアプリケーション105は最新データを取得し、プラットフォーム／ゲートウェイ101に更新要求を送信し、その結果、プラットフォーム／ゲートウェイ101は、プロデューサデータリソースを更新し、コンシューマアプリケーションに最新データを返信する。本発明のこの実施形態における方法を用いて、プロデューサアプリケーションは、プロデューサアプリケーションが頻繁かつ不必要にプロデューサデータリソースを更新することを防止し、プロデューサアプリケーションによって生成されたデータとコンシューマアプリケーションによって使用されるデータとの間の不一致の問題を解決するために、必要に応じてプロデューサデータリソースに対するコンシューマアプリケーションの要求に基づいてプロデューサデータリソースを更新する。
【００７３】
図4は、本発明の一実施形態による、別のリソース取得方法の概略フローチャートである。図4に示されたように、方法は以下のステップを含む。
【００７４】
ステップ401およびステップ402は、図3に示された実施形態のステップ301およびステップ302と同じである。ステップ404、ステップ406、ステップ407、ステップ408、およびステップ409は、それぞれ、図3に示された実施形態のステップ304、ステップ306、ステップ307、ステップ309、およびステップ310と同じである。関連する説明については、前述のステップを参照されたい。詳細は本明細書では再び記載されない。
【００７５】
ステップ403．コンシューマアプリケーション1がプラットフォーム／ゲートウェイ101にリソース作成要求を送信し、リソース作成要求は、プロデューサデータリソースの子リソースを作成するようにプラットフォーム／ゲートウェイ101に命令するために使用され、プロデューサデータリソースの識別子、作成される必要があるリソースのタイプ、および作成される必要があるリソースのコンテンツを含む。
【００７６】
具体的には、リソース作成要求は以下の通りであり得る。
POST／CSEBase／container
X−M2M−From：AE1
Content−Type：application／vnd．onem2m−res＋xml；  resourceType＝ACQUIRE
＜m2m＞
＜acquire＞
＜request＞BLANK＜／request＞
＜keepUpdate＞Onlyonce＜／keepUpdate＞
＜／acquire＞
＜／m2m＞
【００７７】
POST要求のアドレス「／CSEBase／container」は、プロデューサデータリソースの識別子を示す。X−M2M−Fromは、本明細書ではコンシューマアプリケーション103の識別子である、要求を開始するアプリケーションの識別子を示す。resourceType＝ACQUIREは、作成される必要があるリソースのタイプがACQUIREタイプであることを示す。X−M2M−KEEPUPDATE識別子は、プロデューサデータリソースを更新するようにプラットフォーム／ゲートウェイ101に命令するために使用され、X−M2M−KEEPUPDATE識別子の値Onlyonceは、コンシューマアプリケーション103が更新されたプロデューサデータリソースを取得しようとしていることを示す。2つの＜acquire＞識別子間のコンテンツは、作成される必要があるリソースのコンテンツであり、要求コンテンツおよび更新識別子を含む。BLANKは、リソースが作成されたばかりのとき要求コンテンツが空白であることを示し、Onlyonceは、更新識別子keepUpdateの値がOnlyonceであることを示し、更新識別子の値はOnlyonceであり、ACQUIREタイプのリソースを作成した後、プラットフォーム／ゲートウェイ101が、containerリソースが一度更新に成功した後にのみ、acquireタイプのリソースの結果ステータスを処理前から処理成功に変更することができることを示し、containerリソースの最新データは、acquireタイプのリソースの要求コンテンツに格納される。しかしながら、containerリソースが後で再び更新された場合、変更されたcontainerリソースの最新データは、二度とacquireタイプのリソースの要求コンテンツに更新されない。
【００７８】
ステップ305．コンシューマアプリケーション2がプラットフォーム／ゲートウェイ101にリソース作成要求を送信し、リソース作成要求は、プロデューサデータリソースの子リソースを作成するようにプラットフォーム／ゲートウェイ101に命令するために使用され、プロデューサデータリソースの識別子、作成される必要があるリソースのタイプ、および作成される必要があるリソースのコンテンツを含む。
【００７９】
具体的には、リソース作成要求は以下の通りであり得る。
POST／CSEBase／container
X−M2M−From：AE2
Content−Type：application／vnd．onem2m−res＋xml；  resourceType＝ACQUIRE
＜m2m＞
＜acquire＞
＜request＞BLANK＜／request＞
＜keepUpdate＞always＜／keepUpdate＞
＜／acquire＞
＜／m2m＞
【００８０】
リソース作成要求は、リソース作成要求内の更新識別子がalwaysであるという点で、ステップ403におけるリソース作成要求とは異なる。更新識別子の値はalwaysであり、リソースを作成した後、プラットフォーム／ゲートウェイ101がcontainerリソースが更新されるのを待つ必要はないが、プロデューサデータリソースのデータコンテンツの現在値を直接取得し、現在値を要求コンテンツに格納し、acquireタイプのリソースの結果ステータスを処理前から処理成功に直接変更することを示す。
【００８１】
図3に示された実施形態とは異なり、本発明のこの実施形態では、プラットフォーム／ゲートウェイ101は、プロデューサアプリケーションによって更新されたデータを能動的にコンシューマアプリケーションに送信しないことに留意されたい。コンシューマアプリケーションが最新データを取得する必要があるとき、コンシューマアプリケーションは、acquireタイプのリソース内の要求コンテンツまたはプロデューサデータリソース内のデータコンテンツを能動的に取得する必要がある。能動的取得のプロセスは、当業者によく知られた技術であり、詳細は本明細書では再び記載されない。
【００８２】
本発明の一実施形態は、図3に記載された方法実施形態と同じ独創的なアイデアに属するデータリソースプラットフォームの概略構造図をさらに記載する。図5に示されたように、データリソースプラットフォーム500は、図3に記載された方法実施形態におけるプラットフォーム／ゲートウェイ101の機能を実行するように構成され、受信ユニット501と、処理ユニット503と、送信ユニット505とを含む。
【００８３】
受信ユニット501は、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信するように構成され、要求メッセージは、プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する。処理ユニット503は、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新するように構成される。送信ユニット505は、更新されたプロデューサデータリソースをコンシューマアプリケーションに返信するように構成される。
【００８４】
場合によっては、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信する前に、受信ユニット501は、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、サブスクリプションリソース作成要求は、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む。処理ユニット503は、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される。
【００８５】
可能な実装形態では、処理ユニットにより、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的には：指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行すること、事前設定動作がトリガ条件を満たすと判断すること、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信すること、プロデューサアプリケーションによって返信された現時点のデータを受信すること、およびプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することである。
【００８６】
トリガ条件は、プロデューサデータリソースの子リソースを作成することであって、子リソースのタイプが事前設定タイプである、作成すること、および／または作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限を含む。
【００８７】
さらに、子リソースは結果ステータスおよび要求コンテンツを含み、送信ユニットがプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新した後、処理ユニットは、結果ステータスを処理前状態から処理成功状態に変更し、現時点のデータを使用して要求コンテンツを更新するようにさらに構成される。
【００８８】
この実施形態では、データリソースプラットフォーム500は、機能ユニットの形態で提示される。本明細書における「ユニット」は、特定用途向け集積回路（application−specific integrated circuit、ASIC）、回路、1つもしくは複数のソフトウェアもしくはファームウェアのプログラムを実行するためのプロセッサ、メモリ、集積論理回路、および／または前述の機能を実現することができる別のデバイスであってもよい。簡単な実施形態では、当業者は、データリソースプラットフォーム500が図2に示された形態であってもよいと考えることができる。受信ユニット501、処理ユニット503、および送信ユニット505は、図3のプロセッサおよびメモリを使用して実装されてもよい。具体的には、受信ユニット501および送信ユニット505は、プロセッサが第1の対話モジュールを実行することによって実装されてもよく、処理ユニット503は、プロセッサが第1の処理モジュールを実行することによって実装されてもよい。
【００８９】
本発明の一実施形態は、図3に記載された方法実施形態と同じ独創的なアイデアに属するデータリソースプラットフォームの概略構造図をさらに記載する。図6に示されたように、データリソースプラットフォーム600は、図3に記載された方法実施形態におけるプラットフォーム／ゲートウェイ101の機能を実行するように構成され、受信ユニット601と、処理ユニット605と、送信ユニット603とを含む。
【００９０】
受信ユニット601は、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信するように構成され、要求メッセージは、プロデューサデータリソースを返信し、プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する。送信ユニット603は、プロデューサデータリソースをコンシューマアプリケーションに返信するように構成される。処理ユニット605は、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新するように構成される。
【００９１】
場合によっては、プロデューサデータリソースを取得するために使用され、コンシューマアプリケーションによって送信された要求メッセージを受信する前に、受信ユニット601は、プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するようにさらに構成され、サブスクリプションリソース作成要求は、プロデューサデータリソースの識別子、プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む。処理ユニット605は、サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するようにさらに構成される。
【００９２】
可能な実装形態では、処理ユニット605により、プロデューサアプリケーションから現時点のデータを取得し、現時点のデータを使用してプロデューサデータリソースを更新することは、具体的には：指示情報に基づいてプロデューサデータリソースに対して事前設定動作を実行すること、事前設定動作がトリガ条件を満たすと判断すること、プロデューサアプリケーションの識別子に基づいてプロデューサアプリケーションに通知メッセージを送信することであって、通知メッセージが、コンシューマアプリケーションが現時点のデータを取得する必要があることを示すために使用される、送信すること、プロデューサアプリケーションによって返信された現時点のデータを受信すること、およびプロデューサアプリケーションによって返信された現時点のデータを使用してプロデューサデータリソースを更新することである。トリガ条件は、プロデューサデータリソースの子リソースを作成することであって、子リソースのタイプが事前設定タイプである、作成すること、および／または作成された子リソースの数量制限、および／または複数の子リソースの作成時間間隔制限を含む。
【００９３】
この実施形態では、データリソースプラットフォーム600は、機能ユニットの形態で提示される。本明細書における「ユニット」は、特定用途向け集積回路（application−specific integrated circuit、ASIC）、回路、1つもしくは複数のソフトウェアもしくはファームウェアのプログラムを実行するためのプロセッサ、メモリ、集積論理回路、および／または前述の機能を実現することができる別のデバイスであってもよい。簡単な実施形態では、当業者は、データリソースプラットフォーム600が図2に示された形態であってもよいと考えることができる。受信ユニット601、送信ユニット603、および処理ユニット605は、図2のプロセッサおよびメモリを使用して実装されてもよい。具体的には、受信ユニット601および送信ユニット603は、プロセッサが第2の対話モジュールを実行することによって実装されてもよく、処理ユニット605は、プロセッサが第2の処理モジュールを実行することによって実装されてもよい。
【００９４】
本発明の一実施形態は、データリソースプラットフォームによって使用されるコンピュータソフトウェア命令を記憶するように構成されたコンピュータ記憶媒体をさらに提供し、コンピュータ記憶媒体は、前述の方法実施形態を実行するために設計されたプログラムを含む。記憶されたプログラムを実行することにより、データリソースを取得するための方法が実装される場合がある。
【００９５】
本発明は、実施形態を参照して記載されているが、保護を主張する本発明を実装するプロセスにおいて、当業者は、添付の図面、開示された内容、および添付の特許請求の範囲を参照することにより、開示された実施形態の別の変形形態を理解し実装することができる。特許請求の範囲では、「含む」（comprising）は別の構成要素または別のステップを排除せず、「a」または「one」は複数のケースを排除しない。単一のプロセッサまたは別のユニットは、特許請求の範囲に列挙されたいくつかの機能を実装することができる。いくつかの手段が相互に異なる従属請求項に列挙されているという事実は、これらの手段の組合せがより良い結果をもたらすことができないことを示すものではない。
【００９６】
本発明の実施形態は、方法、装置（デバイス）、またはコンピュータプログラム製品として提供される場合があることを当業者なら理解されよう。したがって、本発明は、ハードウェアのみの実施形態、ソフトウェアのみの実施形態、またはソフトウェアとハードウェアの組合せを有する実施形態の形態を使用してもよい。その上、本発明は、コンピュータ使用可能プログラムコードを含む、（限定はしないが、ディスクメモリ、CD−ROM、光メモリなどを含む）1つまたは複数のコンピュータ使用可能記憶媒体に実装されたコンピュータプログラム製品の形態を使用してもよい。コンピュータプログラムは、適切な媒体に記憶／分配され、別のハードウェアとともにハードウェアの一部として提供もしくは使用されるか、あるいは、Internetまたは別の有線もしくはワイヤレスの電気通信システムを使用することなどにより、別の分配形態を使用してもよい。
【００９７】
本発明は、本発明の実施形態による、方法、装置（デバイス）、およびコンピュータプログラム製品のフローチャートおよび／またはブロック図を参照して記載されている。コンピュータプログラム命令は、フローチャートおよび／またはブロック図の各プロセスおよび／または各ブロック、ならびにフローチャートおよび／またはブロック図のプロセスおよび／またはブロックの組合せを実装するために使用される場合があることを理解されたい。これらのコンピュータプログラム命令は、機械を生成するために、汎用コンピュータ、専用コンピュータ、組込み型プロセッサ、または任意の他のプログラマブルデータ処理デバイスのプロセッサに提供される場合があり、その結果、コンピュータまたは任意の他のプログラマブルデータ処理デバイスのプロセッサによって実行される命令は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装するための装置を生成する。
【００９８】
これらのコンピュータプログラム命令は、特定の方式で動作するようにコンピュータまたは任意の他のプログラマブルデータ処理デバイスに命令することができるコンピュータ可読メモリに記憶される場合もあり、その結果、コンピュータ可読メモリに記憶された命令は、命令装置を含む人工物を生成する。命令装置は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装する。
【００９９】
これらのコンピュータプログラム命令は、コンピュータまたは別のプログラマブルデータ処理デバイスにロードされる場合もあり、その結果、一連の動作およびステップは、コンピュータまたは別のプログラマブルデータ処理デバイス上で実行され、それにより、コンピュータ実装処理が生成される。したがって、コンピュータまたは別のプログラマブルデータ処理デバイス上で実行される命令は、フローチャートの1つもしくは複数のプロセス内、および／またはブロック図の1つもしくは複数のブロック内の特定の機能を実装するためのステップを実現する。
【０１００】
本発明は、具体的な特徴およびそれらの実施形態を参照して記載されているが、明らかに、本発明の精神および範囲から逸脱することなく、それらに対して様々な修正および組合せを行うことができる。それに対応して、本明細書および添付の図面は、添付の特許請求の範囲によって定義される本発明の説明の単なる例であり、本発明の範囲を包含する修正、変形、組合せ、または均等物のいずれかまたはすべてと見なされる。明らかに、当業者は、本発明の趣旨および範囲から逸脱することなく、本発明に対して様々な修正および変形を行うことができる。本発明は、以下の特許請求の範囲およびそれらの等価な技術によって定義される保護範囲内に入るという条件で、これらの修正および変形を包含するものである。
【符号の説明】
【０１０１】
100  現行のアーキテクチャ
101  プラットフォーム／ゲートウェイ
102  コンシューマ端末
103  コンシューマアプリケーション
104  プロデューサ端末
105  プロデューサアプリケーション
106  ネットワーク
200  コンピュータデバイス
201  プロセッサ
202  通信バス
203  メモリ
204  通信インタフェース
205  出力デバイス
206  入力デバイス
208  プロセッサ
500  データリソースプラットフォーム
501  受信ユニット
503  処理ユニット
505  送信ユニット
600  データリソースプラットフォーム
601  受信ユニット
603  送信ユニット
605  処理ユニット
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
リソース取得方法であって、前記方法が、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するステップであって、前記要求メッセージが、前記プロデューサデータリソースを更新し、更新されたプロデューサデータリソースを返信するように命令するために使用される指示情報を搬送する、ステップと、
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップと、
前記更新されたプロデューサデータリソースを前記コンシューマアプリケーションに返信するステップと
を含む、方法。
【請求項２】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信する前記ステップの前に、前記方法が、
前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するステップであって、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、ステップと、
前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するステップと
をさらに含む、請求項1に記載の方法。
【請求項３】
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップが、具体的に、
前記指示情報に基づいて前記プロデューサデータリソースに対して事前設定動作を実行するステップ、
前記実行された事前設定動作が前記トリガ条件を満たすと判断するステップ、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信するステップであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、ステップ、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信するステップ、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップ
である、請求項2に記載の方法。
【請求項４】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項2または3に記載の方法。
【請求項５】
前記トリガ条件が、前記作成された子リソースの数量制限および／または複数の子リソースの作成時間間隔制限をさらに含む、請求項4に記載の方法。
【請求項６】
前記子リソースが結果ステータスおよび要求コンテンツを含み、
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップの後に、前記方法が、
前記結果ステータスを処理前状態から処理成功状態に変更するステップと、
前記現時点のデータを使用して前記要求コンテンツを更新するステップと
をさらに含む、請求項4または5に記載の方法。
【請求項７】
リソース取得方法であって、前記方法が、プロデューサアプリケーションによって生成されたプロデューサデータリソースを取得するためにコンシューマアプリケーションによって使用され、
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信するステップであって、前記要求メッセージが、前記プロデューサデータリソースを返信し、前記プロデューサデータリソースを更新するように命令するために使用される指示メッセージを搬送する、ステップと、
前記コンシューマアプリケーションに前記プロデューサデータリソースを返信するステップと、
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップと
を含む、方法。
【請求項８】
前記プロデューサデータリソースを取得するために使用され、前記コンシューマアプリケーションによって送信された要求メッセージを受信する前記ステップの前に、前記方法が、
前記プロデューサアプリケーションによって送信されたサブスクリプションリソース作成要求を受信するステップであって、前記サブスクリプションリソース作成要求が、前記プロデューサデータリソースの識別子、前記プロデューサアプリケーションの識別子、およびサブスクリプションイベントのトリガ条件を含む、ステップと、
前記サブスクリプションリソース作成要求に基づいてサブスクリプションリソースを作成するステップと
をさらに含む、請求項7に記載の方法。
【請求項９】
前記プロデューサアプリケーションから現時点のデータを取得し、前記現時点のデータを使用して前記プロデューサデータリソースを更新する前記ステップが、具体的に、
前記指示メッセージに基づいて前記プロデューサデータリソースに対して事前設定動作を実行するステップ、
前記事前設定動作が前記トリガ条件を満たすと判断するステップ、
前記プロデューサアプリケーションの前記識別子に基づいて前記プロデューサアプリケーションに通知メッセージを送信するステップであって、前記通知メッセージが、コンシューマアプリケーションが前記現時点のデータを取得する必要があることを示すために使用される、ステップ、
前記プロデューサアプリケーションによって返信された前記現時点のデータを受信するステップ、および
前記プロデューサアプリケーションによって返信された前記現時点のデータを使用して前記プロデューサデータリソースを更新するステップ
である、請求項8に記載の方法。
【請求項１０】
前記トリガ条件が、前記プロデューサデータリソースの子リソースを作成することを含み、前記子リソースのタイプが事前設定タイプである、請求項8または9に記載の方法。
【請求項１１】
プロセッサおよびメモリを備えるデータリソースプラットフォームであって、
前記メモリがコンピュータ可読プログラムを記憶し、
前記プロセッサが、前記メモリ内の前記プログラムを実行することにより、請求項1から6に記載の前記方法を実行するように構成される、
プラットフォーム。
【請求項１２】
プロセッサおよびメモリを備えるデータリソースプラットフォームであって、
前記メモリがコンピュータ可読プログラムを記憶し、前記プロセッサが、前記メモリ内の前記プログラムを実行することにより、請求項7から10に記載の前記方法を実行するように構成される、
プラットフォーム。
【国際調査報告】
2019506785.tif 000009
2019506785.tif 000010
2019506785.tif 000011
2019506785.tif 000012
2019506785.tif 000013
2019506785.tif 000014