(57)【要約】本発明の実施形態は、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減するための資源取得方法および関係した装置を提供する。本発明の実施形態における方法は：受付部によって、資源に含まれる目標属性を取得するために端末によって送られた第一の要求を受領する段階であって、前記第一の要求は前記目標属性の一様資源識別子URIを担持する、段階と；前記受付部によって、前記URIに基づいて、前記受付部が前記目標属性が属する資源を記憶していることを判別する段階であって、前記目標属性は前記資源に含まれる部分的な内容である、段階と；前記受付部によって、前記URIによって示される有効な目標属性を前記端末に送る段階とを含む。本発明の実施形態はさらに、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減する受付部および資源サーバーを提供する。
2019506696.tif 000002
【特許請求の範囲】
【請求項１】
マシンツーマシンM2M通信システムに適用される資源取得方法であって：
受付部によって、資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
前記受付部によって、前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを含む、
方法。
【請求項２】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別することを含み、前記有効な資源は具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源である、
請求項１記載の方法。
【請求項３】
前記資源が、前記資源の有効期間を示すために使われる時間属性および最終修正時刻属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れであることを判別する段階と；
前記受付部によって、第二の要求を資源サーバーに送る段階であって、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持する、段階と；
前記受付部によって、前記資源サーバーによってフィードバックされた属性値内容を受領する段階であって、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容である、段階と；
前記受付部によって、受領された前記属性値内容に基づいて、前記受付部に記憶されている前記資源を更新する段階であって、前記資源の前記有効期間についての前記時間属性および前記最終修正時刻属性を更新することを含み、更新された資源が有効な資源であり、具体的には、受領された前記属性値内容と、前記資源の、前記受付部に記憶されている、変化していない属性値内容とである、段階と；
前記受付部によって、前記有効な資源を前記資源要求者に送る段階とを含む、
請求項１記載の方法。
【請求項４】
前記資源識別子は一様資源識別子URIまたはM2Mシステムにおいて定義されている資源識別子である、請求項１ないし３のうちいずれか一項記載の方法。
【請求項５】
前記資源要求者が前記受付部に登録される、請求項１ないし４のうちいずれか一項記載の方法。
【請求項６】
マシンツーマシンM2M通信システムに適用される資源取得方法であって：
資源を取得するための、受付部によって送られた第二の要求を、資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、前記資源サーバーによって判別する段階と；
前記変化している値内容を前記資源サーバーによって前記受付部に送る段階とを含む、
資源取得方法。
【請求項７】
マシンツーマシンM2M通信システムに適用される受付部であって：
資源を取得するために資源要求者によって送られた第一の要求を受領するよう構成された受領モジュールであって、前記第一の要求は前記資源の資源識別子を担持する、受領モジュールと；
前記受領モジュールによって受領された前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する判別モジュールと；
前記資源識別子によって示される有効な資源を前記資源要求者に送るよう構成された送信モジュールとを有する、
受付部。
【請求項８】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別し、前記有効な資源が具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源であることを判別するよう構成される、
請求項７記載の受付部。
【請求項９】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れであることを判別するよう構成され；
前記送信モジュールはさらに、第二の要求を資源サーバーに送るよう構成され、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持し；
前記受領モジュールはさらに、前記資源サーバーによってフィードバックされた属性値内容を受領して、前記受付部に記憶されている資源を更新するよう構成されており、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容であり；
前記判別モジュールはさらに、前記資源が有効な資源が具体的には、前記受付部によって受領された、変化している前記属性値内容と、前記資源の、変化していない属性値内容とであることを決定するよう構成されており；
前記送信モジュールはさらに、前記有効な資源を前記資源要求者に送るよう構成されている、
請求項７記載の受付部。
【請求項１０】
マシンツーマシンM2M通信システムに適用される資源サーバーであって：
資源を取得するための、受付部によって送られた第二の要求を受領するよう構成された受領モジュールであって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、受領モジュールと；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、判別するよう構成された判別モジュールと；
前記変化している値内容を前記受付部に送るよう構成されている送信モジュールとを有する、
資源サーバー。
【請求項１１】
コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
トランシーバと；
前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
M2Mシステムに適用される受付部であって、
前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを
当該受付部に実行させる、
受付部。
【請求項１２】
コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
トランシーバと；
前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
M2Mシステムに適用される資源サーバーであって、
前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
資源を取得するための、受付部によって送られた第二の要求を資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の属性値内容であって、前記受付部に記憶されている前記資源に対して変化している属性値内容を、判別する段階と；
前記変化している値内容を前記受付部に送る段階とを
当該資源サーバーに実行させる、
資源サーバー。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、ここに参照によってその全体において組み込まれる、2016年2月2日に中国特許庁に出願された「資源取得方法および関係した装置」と題する中国特許出願第201610072844.6号の優先権を主張するものである。
技術分野
本発明は通信分野に、詳細には資源取得方法および関係した装置に関する。
【背景技術】
【０００２】
マシンツーマシン（M2M:  Machine  to  Machine）はある端末から別の端末へのデータ伝送、つまり機械と機械の会話をいう。M2Mは機械どうしの間の知的で対話的な通信である。M2M技術が急速に発達するにつれて、M2M技術はより多くの垂直産業および分野に広く適用されてきている。たとえば、M2M技術は、知的な輸送、農業灌漑、スマート家庭、電力網およびメーター計測といった産業に応用される。アプリケーション・サービスに対する種々の垂直産業の要求を満たすため、いくつかの共通機能、たとえばデータ・アクセスおよび記憶、データ共有および伝送、グループ通信、データ申し込み通知、セキュリティー、課金および装置管理を実装するよう、M2Mシステムのために同じM2Mプラットフォームが開発される。M2Mシステムは、端末、受付部および資源サーバーを含んでいてもよい。受付部は、オペレーター・プラットフォームであってもよく、あるいは家庭ゲートウェイであってもよい。資源サーバーは、特定的に指定されたサービスを提供し、気象サーバーであってもよく、あるいは保有装置管理サーバーであってもよい。端末は、受付部を使うことによって、資源サーバーから資源を取得する。資源は、情報の抽象化である。名前を付けられる任意の情報が、資源として使用できる。たとえば、文書、ピクチャーまたは時間に関係したサービス（「2015年9月1日の南京の天気」）が資源でありうる。実際の応用では、たとえば以下のようになる。
【０００３】
端末Aが資源Cを取得する必要があり、端末Bも資源Cを取得する必要がある。資源Cは特定の内容、内容サイズおよび内容フォーマットといった属性を含む。ある場合では、端末Aによって取得される必要のある資源Cは、端末Bによって取得される必要のある資源Cと同じである。よって、資源サーバーは同じ資源を受付部に二回送る。別の場合では、端末Bによって取得される資源Cに比べ、端末Aによって取得される資源Cは、いくつかの属性値が変化しただけであり、属性値の大半は同じである。資源サーバーは大半の重複データ、すなわち属性値が同じデータを受付部に複数回送ることがある。これは、資源サーバーと受付部との間で冗長なデータ伝送を引き起こし、ネットワーク資源の無駄を引き起こし、端末への受付部の応答速度を低下させる。
【発明の概要】
【０００４】
本発明の実施形態は、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減し、ネットワーク資源を節約するための資源取得方法および関係した装置を提供する。
【０００５】
本発明の実施形態では、通信システムが提供される。通信システムは、端末と、受付部と、資源サーバーとを含む。ある特定のM2Mネットワーク展開では、端末は、アプリケーション専用ノード（ADN:  Application  Dedicated  Node）、アプリケーション・サービス・ノード（ASN:  Application  Service  Node）または中間ノード（MN:  Middle  Node）に対応してもよく、受付部および資源サーバーはASN、MNまたはインフラストラクチャー・ノード（IN:  Infrastructure  Node）に対応してもよい。受付部（受付部共通サービス・エンティティー［Registrar  Common  Service  Entity］、略R-CSE）は端末によって登録されるCSEである。共通サービス・エンティティー（CSE:  Common  Service  Entity）はM2Mシステムの共通機能コンポーネントとして使われ、共通機能を担持していてもよい。資源サーバー（ホスティング共通サービス・エンティティー［Hosting  Common  Service  Entity］、略H-CSE）は資源または属性を保持するエンティティーである。
【０００６】
受付部は、複数の端末をサポートしてもよい。受付部は、オペレーター・プラットフォームであってもよく、あるいは家庭ゲートウェイであってもよい。資源サーバーは、特定的に指定されたサービスを提供し、たとえば気象サーバーであってもよく、あるいは保有装置管理サーバーであってもよい。端末は、受付部を使うことによって、資源サーバーから資源または資源の属性を取得する。本発明の実施形態では、受付部に、資源を記憶する記憶機構が導入される。端末が目標属性を取得することを要求するとき、ここで、目標属性は資源に含まれる部分属性であるが、受付部はまずローカルな記憶を探索し、目標属性が属する資源がローカルに記憶されているかどうかを判定する。資源が記憶されていれば、受付部は、目標属性を資源サーバーから取得する必要なしに、ローカルに記憶されている資源に含まれる目標属性を、端末に直接送る。それにより、受付部と資源サーバーとの間のデータ伝送を効果的に削減する。
【０００７】
本発明では、端末は、資源または資源に含まれる目標属性を取得する必要があることがある。下記は、端末が目標属性を取得する必要がある場合を記述する。
【０００８】
第一の側面によれば、本発明のある実施形態は、マシンツーマシンM2M通信システムに適用される資源取得方法を提供する。受付部は、資源に含まれる目標属性を取得するために端末によって送られた第一の要求を受領し、ここで、第一の要求は目標属性の一様資源識別子URIを担持している。受付部は、URIに基づいて、前記第一の要求が前記資源に含まれる前記目標属性を要求するために使われていることを判別してもよい。目標属性は、資源に含まれる部分的な内容である。目標属性は、少なくとも一つの属性である。受付部は、一様資源識別子（英語：Uniform  Resource  Identifier、略URI）に基づいて、その目標属性が属する資源を受付部が記憶していることを判別する。その際、受付部は、URIの資源部分をインデックスとして使って、ローカル記憶を探索し、その目標属性が属する資源がローカル記憶に存在するかどうかを判定する。受付部がその目標属性が属する資源がローカル記憶に記憶されていると判定するとき、受付部は、URIによって示された有効な目標属性を端末に送る。ここでいう目標属性は、受付部におけるローカルに記憶された目標属性である。ここでの資源は、端末が受付部に取得要求を初めて送った後に、受付部が資源サーバーから応答を取得して該応答を記憶した後に、得られるものである。受付部に記憶される資源は更新され、よって、データは定期的に更新され、記憶されることができる。好ましくは、データは、その後資源サーバーによって受付部に返される、変化している属性値内容に基づいて、同期的に更新され、記憶される。
【０００９】
本発明のこの実施形態により、受付部に記憶機構が導入され、端末が受付部に目標属性を要求するとき、受付部は、URIの資源部分をインデックスとして使って記憶を探索する。目標属性が属する資源がローカルに記憶されていると判定する場合、受付部は、目標属性を資源サーバーから取得する必要なしに、ローカルに記憶されている資源に含まれる目標属性を、端末に、直接送る。それにより、受付部と資源サーバーとの間のデータ伝送量を効果的に削減する。
【００１０】
具体的には、受付部が有効な目標属性を決定するいくつかの異なる場合がある。下記はそれらの場合を別個に記述する。
【００１１】
ある可能な設計では、資源は、資源の有効期間を示すために使われる時間属性を含む。受付部は、時間属性に基づいて、目標属性が属する資源の有効期限が切れているかどうかを判定してもよい。資源が有効期限切れでなければ、受付部は、その有効な目標属性は具体的には、URIによって示され、受付部に記憶された目標属性であると判定する。受付部はその有効な目標属性を端末に送る。
【００１２】
ある可能な設計では、受付部が、時間属性に基づいて、目標属性が属する資源の有効期限が切れていると判定する場合、さらに、受付部は、資源サーバーに第二の要求を送る。第二の要求は、資源サーバーから目標属性を取得するために使われる。第二の要求は、受付部に記憶されている資源の最終修正時刻属性値および前記URIを担持する。その後、受付部は、資源サーバーによってフィードバックされる属性値内容を受領する。ここで、受付部に記憶されている最終修正時刻属性値が資源サーバーに記憶されている最終修正時刻属性値と異なるとき、属性値内容は具体的には、資源サーバーに記憶されている目標属性における、受付部に記憶されている目標属性に対して変わっている属性値内容である。
【００１３】
受付部によって決定される有効な目標属性は具体的には：受付部によって受領される属性値内容および受付部に記憶された目標属性内の、変化していない属性値内容である。
【００１４】
本発明のこの実施形態では、受付部はまず、資源の時間属性に基づいて、資源が有効期限切れかどうかを判定し、資源が有効期限切れでなければ、資源サーバーから目標属性を取得する必要なしに、有効期限切れでない、ローカルに記憶された資源に含まれるその目標属性が有効な目標属性であると直接、判定する。資源が有効期限切れであれば、受付部は、資源に記憶されている最終修正時刻属性値を資源サーバーに送り、資源サーバーは、その最終修正時刻属性値に基づいて、受付部に記憶されている目標属性における、変化する属性値内容を決定する。受付部は、目標属性における、変化する、資源サーバーによって送られた属性値内容を受領するが、目標属性の全内容を受領するのではない。これは事実上、受付部と資源サーバーとの間のデータ伝送を削減する。受付部は、変化している受領された属性値内容と、変化していない、ローカルに記憶された属性値内容とが、有効な目標属性であると判定する。受付部は、有効な目標属性を端末に送る。
【００１５】
端末が受付部から目標属性を取得する場合を上記で述べた。下記は、端末が資源を取得する必要がある場合を記述する。
【００１６】
ある可能な設計では、受付部は、資源を取得するための、端末によって送られた第三の要求を受領する。第三の要求は資源のURIを担持する。受付部は、URIをインデックスとして使ってローカル記憶を探索する。受付部は、資源のURIに基づいて、資源がローカルに記憶されていることを判別する。加えて、受付部は、資源の時間属性に基づいて、資源が有効期限切れかどうかを判定する。資源が有効期限切れであれば、受付部は第四の要求を資源サーバーに送る。第四の要求は、資源サーバーから資源を取得することを要求するために使われ、第四の要求は資源のURIと、受付部に記憶されている資源の最終修正時刻属性値とを担持する。その後、受付部は、資源サーバーによってフィードバックされた属性値内容を受領する。資源サーバーに記憶されている最終修正時刻属性値が受付部に記憶されている最終修正時刻属性値と異なるとき、該属性値内容は、資源サーバーに記憶された資源における属性値の、受付部に記憶されている資源に対して変化する属性値内容である。受付部は、有効な資源が具体的には：変化している受領された属性値内容および受付部に記憶されている、変化していない属性値内容であることを判別する。受付部は、有効な資源を端末に送る。変化している属性値内容を受け取るとき、受付部は該変化している属性値内容に基づいて対応する属性値を更新し、更新された属性値を記憶する。
【００１７】
本発明のこの実施形態では、受付部に記憶されている資源の部分的な属性内容のみが変化し、変化しないいくらかの部分的な属性内容がまだある場合、受付部は、資源内の、変化する属性値内容のみを受領し、資源内のすべての属性値内容を受領するのではない。それにより、受付部と資源サーバーとの間で伝送されるデータを削減する。
【００１８】
第二の側面によれば、本発明の実施形態は、上記の側面を実行するために設計されたプログラムを含む、上記の受付部によって使われるコンピュータ・ソフトウェア命令を記憶するよう構成されたコンピュータ記憶媒体を提供する。
【００１９】
第三の側面によれば、本発明の実施形態は、上記の方法において受付部によって実際上実行される機能を有する受付部を提供する。該機能は、ハードウェアによって実装されてもよく、あるいは対応するソフトウェアを実行するハードウェアによって実行されてもよい。ハードウェアまたはソフトウェアは、上記の機能に対応する一つまたは複数のモジュールを含む。
【００２０】
第四の側面によれば、受付部の構造がメモリ、トランシーバおよびプロセッサを含む。メモリは、コンピュータ実行可能なプログラム・コードを記憶するよう構成されており、トランシーバに結合される。プログラム・コードは命令を含む。プロセッサによって実行されたとき、命令は受付部に、上記の方法における情報または命令を実行させる。
【００２１】
第五の側面によれば、本発明のある実施形態は、マシンツーマシンM2M通信システムに適用される資源取得方法を提供する。資源サーバーは、資源に含まれる目標属性を取得するために受付部によって送られた第二の要求を受領する。第二の要求は目標属性のURIと、資源の最終修正時刻属性とを担持している。目標属性は、資源に含まれる部分的な内容である。資源サーバーは、URIに基づいて、第二の要求が前記資源を要求するために使われていることを判別してもよい。さらに、資源サーバーは、受領された最終修正時刻属性値が記憶されている最終修正時刻属性値と同じであるかどうかを判定する。目標属性が属する資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるときは、資源サーバーは、受付部によって要求された目標属性を一つ一つ比較する。資源サーバーは、資源サーバーに記憶されている目標属性において、受付部に記憶されている目標属性に対して変化している属性値内容を判別し、任意的に、変わっている属性値内容に基づいて応答を生成する。本発明のこの実施形態により、資源サーバーは、要求された目標属性を一つ一つ比較し、変化している属性値内容のみを受付部に送るか、あるいは、要求された目標属性を一つ一つ比較した後に、資源サーバーが目標属性における属性内容の何も変化していないと見出す場合には、資源サーバーは、目標属性が変化していないことを示すよう、受付部に前記応答を送り、資源サーバーはすべての目標属性を受付部に送る必要がなく、それにより、資源サーバーと受付部との間で伝送される冗長なデータを削減する。
【００２２】
ある可能な設計では、資源サーバーは、資源を取得するための、受付部によって送られた第四の要求を受領する。第四の要求は資源のURIと、受付部に記憶されている資源の最終修正時刻属性値とを担持する。資源サーバーが、資源の記憶されている最終修正時刻属性値が資源の受領された最終修正時刻属性値と異なると判定するとき、資源サーバーは、要求された資源におけるすべての属性を一つ一つ比較する。資源サーバーは、資源サーバーに記憶された資源における、受付部に記憶されている資源に対して変化している属性値内容を判別する。資源サーバーは、受付部に、変化している属性値内容を送る。
【００２３】
本発明のこの実施形態では、資源サーバーは、受領された最終修正時刻属性値を、ローカルに記憶されている最終修正時刻族性値と比較する。二つの最終修正時刻族性値が互いに異なっていれば、資源サーバーは、記憶されている最終修正時刻族性値に対応する資源における、受領された最終修正時刻属性値に対応する資源に対して変化している属性値を判別するために比較を実行し、変化している属性値のみを受付部に送り、資源におけるすべての属性値を受付部に送るのではない。それにより、受付部と資源サーバーとの間の冗長な情報伝送を大幅に削減し、ネットワーク資源を節約する。
【００２４】
第六の側面によれば、本発明の実施形態は、上記の側面を実行するために設計されたプログラムを含む、上記の資源サーバーによって使われるコンピュータ・ソフトウェア命令を記憶するよう構成されたコンピュータ記憶媒体を提供する。
【００２５】
第七の側面によれば、本発明の実施形態は資源サーバーを提供する。該資源サーバーは、上記の方法を実装するために資源サーバーによって実行される機能を有する。該機能は、ハードウェアによって実装されてもよく、あるいは対応するソフトウェアを実行するハードウェアによって実行されてもよい。ハードウェアまたはソフトウェアは、上記の機能に対応する一つまたは複数のモジュールを含む。
【００２６】
第八の側面によれば、本発明の実施形態は資源サーバーを提供する。該資源サーバーは、メモリ、トランシーバおよびプロセッサを含む。メモリは、コンピュータ実行可能なプログラム・コードを記憶するよう構成されており、トランシーバに結合される。プログラム・コードは命令を含む。プロセッサによって実行されたとき、命令は資源サーバーに、上記の方法における情報または命令を実行させる。
【図面の簡単な説明】
【００２７】
【図１】本発明のある実施形態に基づくM2Mシステムの概略図である。
【図２】本発明のある実施形態に基づく通信システムの概略図である。
【図３】本発明のある実施形態に基づくM2MシステムにおけるCSEの概略的な構造図である。
【図４】本発明のある実施形態に基づく資源データの概略的な構造図である。
【図５】本発明の実施形態に基づく資源取得方法の実施形態の概略図である。
【図６】本発明の実施形態に基づく資源取得方法のもう一つの実施形態の概略図である。
【図７】本発明のある実施形態に基づく受付部の概略的な構造図である。
【図８】本発明のある実施形態に基づく資源サーバーの概略的な構造図である。
【発明を実施するための形態】
【００２８】
本発明の実施形態は、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減し、受付部が端末に応答する速度を改善する資源取得方法および関係した装置を提供する。
【００２９】
本発明の技術的解決策をよりよく当業者に理解してもらうために、下記は本発明の実施形態の技術的解決策を、本発明の実施形態における付属の図面を参照して記述する。明らかに、記載される実施形態は、本発明の実施形態の全部ではなく、単に一部である。創造的な努力なしに本発明の実施形態に基づいて当業者によって得られる他のすべての実施形態が本発明の保護範囲内にはいる。
【００３０】
本発明の明細書、請求項および付属の図面において、用語「第一」「第二」「第三」「第四」など（もしあれば）は、同様なオブジェクトの間の区別をするために意図されており、必ずしも特定の順序または序列を示すものではない。そのように称されるデータは適切な状況では交換可能であり、本稿に記載される本発明の実施形態は本稿で示されるまたは記載される順序以外の順序で実装されることができることを理解しておくべきである。さらに、用語「含む」「包含する」および他の任意の変形は、非排他的な包含をカバーする意味である。たとえば、一連の段階またはユニットを含むプロセス、方法、システム、プロダクトまたは装置は、必ずしもそれらのユニットに限定されず、明示的に挙げられていない、あるいはそのようなプロセス、方法、システム、プロダクトまたは装置に内在的な、他のユニットを含んでいてもよい。
【００３１】
図１は、本発明のある実施形態に基づくM2Mシステムの概略的なアーキテクチャー図である。M2Mシステムは、M2Mプラットフォーム１０２、M2Mゲートウェイ１０３、M2M装置１０４およびAE（Application  Entity［アプリケーション・エンティティー］）１０１を含む。図１に示されるように、M2Mプラットフォーム１０２はIN（Infrastructure  Node［インフラストラクチャー・ノード］）であってもよく、M2Mゲートウェイ１０３はMN（Middle  Node［中間ノード］）であり、M2M装置はASN（Application  Service  Node［アプリケーション・サービス・ノード］または図示しないADN（Application  Dedicated  Node［アプリケーション専用ノード］）である。さらに、M2Mシステムの共通機能コンポーネントとしてCSE（Common  Service  Entity［共通サービス・エンティティー］）が使われ、共通機能を担持していてもよい。CSEはM2Mプラットフォーム、M2MゲートウェイまたはM2M装置として使われるASNに含まれて、対応する機能を実装してもよい。AEは独立に存在してもよく、あるいはM2Mプラットフォーム、M2MゲートウェイまたはM2M装置として使われるASNもしくはADNに含まれてもよい。CSEは、Mca参照点を使うことにより、AEが、CSEによって開かれる共通機能にアクセスできるようにし、Mcc参照点を使うことにより、CSE間の通信を実装し、Mcn参照点を使うことにより、基礎になるネットワーク機能の呼び出しを実装する。
【００３２】
本発明のある実施形態において、図２は、端末１０、受付部２０および資源サーバー３０を含む通信システムの概略図である。受付部２０（英語：Registrar  Common  Service  Entity［受付部共通サービス・エンティティー］、略R-CSE）は端末によって登録されるCSEである。資源サーバー３０（英語：Hosting  Common  Service  Entity［ホスティング共通サービス・エンティティー］、略H-CSE）は、資源または属性を保持するエンティティーである。本発明のこの実施形態における端末１０、受付部２０および資源サーバー３０は、次の表１に示されるように、図１のM2Mシステムのエンティティーに対応する。
【００３３】
【表１】
2019506696.tif 000003
上記の表１に示されるように、実際のネットワーク展開では、端末はADN、ASNまたはMNに対応してもよく、受付部２０および資源サーバー３０はASN、MNまたはINに対応してもよい。本願の実施形態における資源取得方法は、端末が受付部を使って資源サーバーから資源を取得するシナリオに適用可能であるのみならず、AEが受付部を使って資源サーバーから資源を取得するシナリオにも適用可能である。AEは独立して配備されるIN-AEノード（プラットフォーム側のアプリケーション・サーバーまたはクラウドに配備されるアプリケーション・サーバーなど）であってもよく、あるいはADNに、ASN型の端末に、あるいはMNゲートウェイに位置する論理的な機能ユニットであってもよい。本発明のこの実施形態では、資源取得方法およびプロセスは、端末を例として使って記載される。当業者は、本方法が、任意の形のAEが受付部を使って資源サーバーから資源を取得するシナリオにも適用可能であることを理解するはずである。
【００３４】
受付部は、複数の端末１０をサポートしてもよい。受付部２０は、オペレーター・プラットフォームであってもよく、あるいは家庭ゲートウェイであってもよい。資源サーバー３０は具体的に特定されたサービスを提供し、気象サーバーであってもよく、あるいは運用機器管理〔フリート・マネジメント〕サーバーであってもよい。端末１０は、受付部２０を使って資源サーバー３０から資源または資源の属性を取得してもよい。
【００３５】
図３は、本発明のある実施形態に基づくM2MシステムにおけるCSE  ４０の概略的な構造図である。CSE  ４０はR-CSEであってもよく、あるいはH-CSEであってもよい。CSE  ４０は一つまたは複数のポート２１を含んでいてもよく、トランシーバ（transceiver）２２に結合される。トランシーバ２２は、送信器、受信器または送信器と受信器の組み合わせであってもよく、ポート２１を使って別のネットワーク・ノードにデータ・パケットを送る、あるいは別のネットワーク・ノードからデータ・パケットを受け取る。プロセッサ２３はトランシーバ２２に結合され、データ・パケットを処理するよう構成される。プロセッサ２３は、一つまたは複数のマルチコア・プロセッサ２３および／またはメモリ２４を含んでいてもよい。プロセッサ２３は汎用プロセッサ２３、特定用途向け集積回路（application  specific  integrated  circuit、略ASIC）またはデジタル信号プロセッサ（英語：digital  signal  processor、略DSP）２３であってもよい。
【００３６】
メモリ２４は、非一時的な記憶媒体であってもよく、プロセッサ２３と結合され、種々の型のデータ、たとえば意味内容的に記述された資源または意味内容的に記述された資源によって記述される資源を記憶するよう構成される。メモリ２４は、読み出し専用メモリ２４（英語：read  only  memory、略ROM）、ランダムアクセスメモリ２４（英語：random  access  memory、略RAM）、情報および命令を記憶できる別の型の動的記憶デバイスまたは磁気ディスクメモリ２４を含んでいてもよい。メモリ２４は、意味内容検証に関係した方法を実装するための命令を記憶するよう構成されていてもよい。プログラミングはプロセッサ２３において実行され、実行可能命令がメモリ２４にロードされ、メモリ２４は読み出し専用メモリもしくはランダムアクセスメモリの少なくとも一方であることが理解されうる。
【００３７】
ある実施形態では、受付部（R-CSE）として使われるとき、CSE  ４０はメモリ２４、プロセッサ２３、トランシーバ２２およびトランシーバ２２に結合された前記一つまたは複数のポート２１を含む。メモリ２４は、コンピュータ実行可能なプログラム・コードを記憶するよう構成される。プロセッサ２３は、メモリ２４およびトランシーバ２２に結合される。
【００３８】
プログラム・コードは命令を含む。プロセッサ２３によって実行されるとき、命令は、受付部に、図５および図６の関係する段階を実行させる。
【００３９】
さらに、資源サーバー（R-CSE）として使われるとき、CSE  ４０はメモリ２４、プロセッサ２３、トランシーバ２２およびトランシーバ２２に結合された前記一つまたは複数のポート２１を含む。メモリ２４は、コンピュータ実行可能なプログラム・コードを記憶するよう構成される。プロセッサ２３は、メモリ２４およびトランシーバ２２に結合される。
【００４０】
プログラム・コードは命令を含む。プロセッサ２３によって実行されるとき、命令は、資源サーバーに、図５および図６の関係する段階を実行させる。
【００４１】
M2Mシステムでは、操作対象は資源の形で現われる。資源は、情報の表現の抽象的な形である。名付けることのできる任意の情報が、資源として使用されることができる。たとえば、文書、ピクチャーまたは時間に関係したサービス（たとえば「2015年9月1日の南京の天気」）である。一般に、一様資源識別子（英語：Uniform  Resource  Identifier、略URI）が特定の資源を同定するために使われる。各資源は一意的なアドレス（URI）をもつ。資源は、それぞれ生成、取得、更新および削除に対応するCRUD（create/retrieve/update/delete）によってURIを管理してもよい。
【００４２】
資源は、子資源および属性を含んでいてもよく、子資源も属性を含んでいてもよい。資源と属性との間の相違は、属性はもはや下位の子資源もしくは属性を含まないが、資源は下位の子資源もしくは属性を含むという点にある。
【００４３】
本発明のこの実施形態では、図４に示される資源データの構造図を参照されたい。図４における四角い細長いボックスは資源を示し、角丸の細長いボックスは属性を示す。資源「コンテナ」（container）はデータを記憶してもよく、主として、別のエンティティーとデータを共有し、該データを追跡するよう構成される。コンテナ・インスタンス（contentInstance）は子資源であり、作成者（creator）およびインスタンスの最大量（maxNrOfInstances）がコンテナ資源の属性として使われる。特定の内容（content）、内容サイズ（contentSize）、最終修正時刻（lastModifiedTime）および時間（cacheExpire）は、子資源のコンテナ・インスタンスに含まれる属性として使われる。属性は、資源の特定の記述であり、資源の特定のデータを格納するために使われる。一つの属性は、名前‐値対（name-value  pair）をもつ。たとえば、属性creatorの名前‐値対はcreator＝Samと表わされる。これは、作成者がSamという名前の人物であることを示す。共有される必要のある情報がある場合、container資源が生成され、その情報は、コンテナ資源の子資源contentInstanceのcontent属性に追加される。気象情報共有、農家の作物生長情報共有などが含まれる。
【００４４】
本発明のこの実施形態において、資源を記憶するために、受付部に記憶機構が導入される。端末が資源を取得するまたは目標属性を取得するとき、目標属性は資源に含まれる部分属性である。すなわち、目標属性は少なくとも一つの属性でありうる。一例では、端末は目標属性を取得する。端末が目標属性を取得するための要求を受付部に送るとき、受付部は、ローカルな記憶を探索してもよい。受付部が、目標属性が属する資源が記憶されていると判定するとき、受付部は、有効な目標属性を端末に送る。有効な目標属性は、時間（cacheExpire）属性が目標属性が属する資源が有効期限切れでないことを示すときは、受付部に記憶されている目標属性である。任意的に、時間（cacheExpire）属性が目標属性が属する資源が有効期限切れであることを示すときは、受付部は、資源の最終修正時刻（lastModifiedTime）属性値を資源サーバーに送る。受領された最終修正時刻（lastModifiedTime）属性値が資源サーバーに記憶されている最終修正時刻属性値と異なると判定するとき、資源サーバーは、ローカルに記憶されている最終修正時刻属性値に対応する目標属性内であって、受領された最終修正時刻属性値に対応する目標属性に対して変わっている属性値を受付部に、送る。理解の容易のため、図４における属性値内容、たとえば特定の内容（content）、内容サイズ（contentSize）、最終修正時刻（lastModifiedTime）または有効期限（cacheExpire）を例を使って記述しておく。
【外１】
【００４５】
2019506696.tif 000004
下記は、端末が資源の全内容（つまり、該資源）を取得することを要求するか資源の部分的内容（目標属性）を取得することを要求するかに基づいて、実施形態を具体的に記述する。図５を参照するに、この実施形態は、以下の段階を含む資源取得方法を提供する。
【００４６】
１．端末が目標属性を取得することを要求する。
【００４７】
５０１．端末は、目標属性を取得するために、受付部に、第一の要求を送る。ここで、第一の要求は目標属性の一様資源識別子URIを担持している。
【００４８】
目標属性は少なくとも一つの属性であってもよい。本願でこの点は限定されない。理解の容易のため、下記は例を使って記述を与える。
【００４９】
たとえば、端末は気象情報を取得する。
【００５０】
端末は第一の要求を受付部に送る。ここで、第一の要求は資源contentInstanceの属性「content」および「content  size」を要求する。
【００５１】
第一の要求は：
GET  /m2m.provider.com/CSE221/container/contentinstance?  atr=con&atr=cs  HTTP/1.1
というものであってもよい。ここで、GETはバージョンHTTP/1.1に準拠する取得動作を表わす。
【００５２】
第一の要求に担持されるURIは：
/m2m.provider.com/CSE221/container/contentinstance?atr=con&atr=cs
であり、ここで、/m2m.provider.com/CSE221/container/contentinstanceはURIの資源部分を表わし、「con」はURIの資源部分によって示される資源の属性「content」を表わし、csはURIの資源部分によって示される資源の属性content  sizeを表わす。
【００５３】
５０２．受付部が第一の要求を受領し、URIの資源部分に基づいて、受付部が目標属性が属する資源を記憶していることを判別する。
【００５４】
受付部は、第一の要求において担持されているURIを受領する。第一に、受付部はURIをパースする。受付部は、URIをパースすることによって、第一の要求におけるURIの資源部分および／または属性部分を判別してもよい。
【００５５】
たとえば、段階５０１における第一の要求において担持されるURIは次のようにパースされる。
【００５６】
/m2m.provider.com/CSE221/container/contentinstance?atr=con&atr=csにおいて、URIの資源部分および属性部分が、両部分の間の境界記号「?」に基づいて分類され、区別される。「?」の前の部分が資源部分であり、「?」より後の部分については、「atr」に基づいて、属性（attribute）が要求されていると判別されうる。
【００５７】
この場合、資源部分は「/m2m.provider.com/CSE221/container/contentinstance」であり、「atr=con&atr=cs」に基づいて、第一の要求を使って要求された属性は資源の属性contentおよび属性content  sizeであると判別されてもよい。
【００５８】
同様に、第一の要求において担持されるURIが：
/m2m.provider.com/CSE221/container/contentinstance
であって「?」記号がない場合には、それは第一の要求は資源を要求するために使われていることを示す。
【００５９】
まとめると、この実施形態において、第一の要求は目標属性を要求するために使われる。
【００６０】
第二に、受付部は、URIの資源部分をインデックスとして使ってローカル記憶を探索して、目標属性が属する資源がローカルに記憶されているかどうかを判定する。
【００６１】
たとえば、受付部は、URIの資源部分：
「/m2m.provider.com/CSE221/container/contentinstance」をインデックスとして使ってローカル記憶を探索し、目標属性が属する資源がローカル記憶に存在することを判別し、atr=con&atr=csに基づいて、端末によって要求される目標属性がcontentおよびcontent  sizeであることを判別する。
【００６２】
受付部に記憶されている、目標属性が属する資源は、前記端末によって初めて要求された資源に基づいて受付部によって記憶されたものであることが理解されうる。すなわち、ある資源を取得するための任意の端末によって送られた要求を受領するとき、受付部は、要求されたURIに基づいて、その資源はローカルに記憶されていないと判定する。その端末によって要求されたその資源を資源サーバーから取得した後、受付部は、その資源がローカルに記憶されていないという判定結果に基づいて、資源サーバーから得られた応答を受付部において記憶する。
【００６３】
受付部に記憶され、目標属性が属する資源を含む応答は、次のようなものである：
HTTP/1.1  200  OK        /HTTP/1.1に準拠して応答成功200  OKを示す
Content-Type:  application/xml        /メッセージ本体のコンテンツ形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  05:  51:  59  GMT      /メッセージ送信時刻がグリニッジ標準時2015年9月29日火曜日05:51:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>        /部分的更新が始まることを示す
<lastModifiedTime>Tue,  29  Sep  2015  04:51:59  GMT  </lastModifiedTime>
<contentSize>1k</contentSize>    /contentSizeの属性値が"1k"であることを示す
<content>cloudy</content>        /contentの属性値が「曇り」であることを示す
<cacheExpire>Tue,  29  Sep  2015  06:00:00  GMT  </cacheExpire>
/cacheExpireの属性値がグリニッジ標準時2015年9月29日火曜日06:00:00であることを示す
<contentInstance>        /資源部分の終わりを示す。
【００６４】
別の態様では、受付部はさらに、送られた資源に資源サーバーによって追加された属性値cacheExpireに基づいて、資源サーバーから得られた資源を記憶してもよい。具体的には、資源サーバーが同じ資源に対する少なくとも二つの要求を受領した後、該同じ資源に対する要求の量が事前設定された値に達すると判定するとき、資源サーバーは、その資源を含む応答を記憶するよう受付部に指示するために、属性値cacheExpireを、受付部に送られる応答に追加する。
【００６５】
５０３．受付部は、目標属性が属する、URIによって指示される資源が有効期限切れであることを判別する。
【００６６】
受付部は、cacheExpire属性値に基づいて、目標属性が属する資源が有効期限切れかどうかを判定する。資源が有効期限切れであれば、目標属性は有効期限切れである。cacheExpire属性値は絶対的な時刻（たとえばグリニッジ平均時2015年9月9日05:43:02）であってもよく、あるいは相対的な時間（たとえば600s）であってもよい。本願ではこの点は限定されない。
【００６７】
受付部が現在時刻をcacheExpire属性値と比較して、目標属性が属する資源が有効期限切れかどうかを判定することについて、下記で例を使って記述する。
【００６８】
cacheExpire属性値がグリニッジ平均時2015年9月9日05:43:02であり、第一の要求が受領されるときの現在時刻がグリニッジ平均時2015年9月9日05:45:02である場合、記憶内の目標属性は有効期限切れであると判定される。別の例では、cacheExpire属性値が相対時間であり、すなわちcacheExpire:600sであり、受付部が資源を記憶する時刻がグリニッジ平均時2015年9月9日05:33:02であり、受付部が第一の要求を受け取る現在時刻がグリニッジ平均時2015年9月9日05:55:02であり、記憶内の目標属性は有効期限切れである。
【００６９】
受付部によって、資源が有効期限切れでないと判定する原理は、資源が有効期限切れであると判定する原理と同じである。ここでは何らかの例を使って詳細を述べることはしない。
【００７０】
５０４．受付部は、資源サーバーに第二の要求を送る。ここで、第二の要求は、受付部に記憶されている資源のlastModifiedTimeの属性値と、前記URIとを担持する。
【００７１】
たとえば、第二の要求は次のようなものである：
GET/m2m.provider.com/CSE221/container/contentinstance?atr=con&atr=cs  HTTP/1.1
LastModifiedTime:  Tue,  29  Sep  2015  04:51:59  GMT
ここで、第二の要求のヘッダ・フィールドがlastModifiedTimeを担持し、lastModifiedTimeの属性値は：Tuesday,  September  29,  2015,  04:51:59  Greenwich  Mean  Timeである。
【００７２】
第一の要求において担持されるURIは：
/m2m.provider.com/CSE221/container/contentinstance?atr=con&atr=cs
であり、「/m2m.provider.com/CSE221/container/contentinstance?atr=con&atr=cs」の説明は段階５０１における説明と同じである。ここで詳細を述べることはしない。
【００７３】
５０５．資源サーバーは第二の要求を受領し、第二の要求は目標属性の一様資源識別子URIおよび資源のlastModifiedTimeの属性値を担持する。
【００７４】
資源サーバーに記憶されている、目標属性が属する資源は次のようなものであることが理解されうる：
<contentInstance>        /資源部分が始まることを示す
<lastModifiedTime>Tue,  29  Sep  2015  05:51:59  GMT</lastModifiedTime>
/lastModifiedTimeの属性値がグリニッジ平均時2015年9月29日火曜日05:51:59であることを示す
<contentSize>1k</contentSize>    /contentSizeの属性値が「1k」であることを示す
<content>raining</content>        /contentの属性値が「雨」であることを示す
<cacheExpire>Tue,  29  Sep  2015  07:00:00  GMT</cacheExpire>
/cacheExpireの属性値がグリニッジ平均時2015年9月29日火曜日07:00:00であることを示す
…
<contentInstance>        /資源部分の終わり。
【００７５】
資源サーバーは、資源サーバーに記憶されているlastModifiedTimeの属性値がlastModifiedTimeの受領された属性値と同じかどうかを判定する。目標属性が属する資源のlastModifiedTimeの属性値がlastModifiedTimeの受領された属性値と異なるときは、二つの場合がある。
【００７６】
（１）資源サーバーは、受付部によって要求された諸目標属性を一つずつ比較する。資源サーバーは、資源サーバーに記憶されている目標属性内であり、受付部に記憶されている目標属性に対して変化している属性値内容を判別し、変化している属性値内容に基づいて応答を生成する。
【００７７】
（２）任意的に、要求された諸目標属性を一つ一つ比較した後に、資源サーバーは資源サーバーに記憶されている目標属性のどれも、受付部に記憶されている目標属性に対して変化がないと判定する。
【００７８】
下記は、例を使って場合（１）を記述する：第二の要求は、size/m2m.provider.com/CSE221/container/contentinstanceによって示される資源におけるcontentおよびcontentを取得し、目標属性は属性「content」および「content  size」を含む。表２参照。
【００７９】
【表２】
2019506696.tif 000005
上記の表２から、lastModifiedTimeの属性値が異なることがわかる。資源サーバーは、異なる資源バージョンの間の内容比較のためにlastModifiedTimeの異なる属性値に対応する異なる資源バージョンを記憶していることを注意しておくべきである。それらのバージョンは異なるが、それらのバージョンにおけるすべての属性値が変わっているわけではなく、一部の属性値のみが変わっていることがある。
【００８０】
資源サーバーに記憶されている目標属性内であり、受付部に記憶されている目標属性に対して変化している属性値内容を資源サーバーによって決定するために二つの方法があることを注意しておくべきである。第一の方法では、属性の属性値が直接比較される。表２に示されるように、「content  size」の属性値は変化しておらず、いずれも「1K」であり、「content」の属性値は変化しており、一方は「raining」であり、他方は「cloudy」である。
【００８１】
第二の方法では、属性の更新時刻が比較される。すなわち、各属性は更新時刻に対応する。表３を参照するに、更新時刻は各属性のフラグ・ビットの状態値であり、各属性は更新時刻をもつ。
【００８２】
【表３】
2019506696.tif 000006
第二の方法では、資源サーバーは属性値を比較する必要はなく、属性値の更新時刻を比較する。上記の表３から、「content  size」に対応する更新時刻は同じであり、「content」に対応する更新時刻は異なっていることがわかる。したがって、資源サーバーに記憶されている目標属性内であり、受付部に記憶されている更新時刻に対して変わっている属性値内容は、「content=raining」であり、変化しない属性値内容は「content  size＝1K」である。
【００８３】
資源サーバーによって実行される属性値についての比較の結果は同じであるが、比較のための方法は異なることが理解されうる。第一の方法では、属性の属性値が直接比較されるが、第二の方法では、属性値の更新時刻が比較される。
【００８４】
５０６．資源サーバーは受付部に応答を送る。ここで、応答は、変化のある属性値内容を含む。
【００８５】
任意的に、資源サーバーは、受付部に、変化のある属性値内容を直接送ってもよい。具体的な仕方は本願では限定されない。
【００８６】
上記の場合（１）については、資源サーバーによって生成されたメッセージ送信時刻は「Tue,  29  Sep  2015  06:01:59  GMT」であり、応答は、第二の要求を使って要求された目標属性内であり、変化している属性値内容に基づいて生成される。資源サーバーによって生成される応答は次のようなものである：
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠し、200  OK応答成功を示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT    
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<partialUpdate>          /部分的更新が始まることを示す
<contentInstance>    /資源部分が始まることを示す
<content>raining</content>    /contentの属性値が「雨」であることを示す
<contentInstance>    /資源部分の終わりを示す
</partialUpdate>        部分的更新の終わりを示す。
【００８７】
任意的に、場合（２）については、資源サーバーは識別子情報を生成する。識別子情報は、変化する属性値内容が空集合であることを示す。
【００８８】
任意的に、識別子情報は、前記応答に加えられてもよい。前記応答は、目標属性が変化していないことを示し、前記応答は次のようなものである。
HTTP/1.1  304  Not  Modified
これは、返される304応答が第二の要求を使って要求された目標属性が変化していないことを示すことを示す。
Date:  Tue,  29  Sep  2015  06:01:59  GMT    
これは、メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す。
【００８９】
任意的に、資源サーバーは、異なる状態コード、たとえば3xyを使うことによって、目標属性が変化していないことを示してもよい。
【００９０】
５０７．受付部は応答を受信し、有効な目標属性を決定する。
【００９１】
任意的に、有効な目標属性は新たな応答に加えられてもよい。
【００９２】
場合（１）については、段階５０６において、有効な目標属性は、変化している受領された属性値内容と、変化していない、受付部に記憶された属性値内の属性値内容である。
【００９３】
受付部は前記応答を受領し、前記応答の指標（partialUpdate）に基づいて、あるいは特定の応答状態コード（たとえば3xz  partial  update）を使うことによって、前記応答が部分更新応答であることを判別することが理解されうる。
【００９４】
受付部は、応答メッセージ送信時刻を現在時刻に修正する。たとえば、メッセージ送信時刻を現在時刻「Date:  Tue,  29  Sep  2015  06:01:59  GMT」に修正し、受領された応答に、変化していない、ローカルに記憶されている属性値内容「contentSize」を加えて、新たな応答を生成する。
【００９５】
任意的に、受付部は、応答メッセージ送信時刻を現在時刻に修正する。たとえば、メッセージ送信時刻を現在時刻「Date:  Tue,  29  Sep  2015  06:01:59  GMT」に修正し、受付部に記憶されている資源の応答をコピーし、目標属性が属する資源における、目標属性以外の属性を、コピーされたバージョンから削除し、「content」の属性値を「cloudy」から「raining」に変えて、新たな応答を生成する。新たな応答の例は次のようなものである。
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠して、応答成功200  OKを示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>        /資源部分の始まりを示す
<contentSize>1k</contentSize>    /contentSizeの属性値が「1k」であることを示す
<content>raining</content>        /contentの属性値が「雨」であることを示す
<contentInstance>        /資源部分の終わりを示す。
【００９６】
新たな応答の上記の例から、有効な目標属性は、変化している受領された属性値内容（content=raining）と、変化していない、受付部に記憶されている目標属性内の属性値内容（contentSize=1k）とであることがわかる。
【００９７】
場合（２）については、段階５０６において、有効な目標属性は、受付部に記憶されている目標属性である。
【００９８】
受付部が識別子情報を受領し、識別子情報によって示される属性値内容であって変化しているものが空集合であるときは、受付部は、識別子情報に基づいて、当該URIによって示される記憶されている資源における目標属性が変化していないと判定する。
【００９９】
任意的に、受付部が応答を受領し、応答の指標（たとえば304  Not  Modified）に基づいて、要求された目標属性が変化していないことを判別する。受付部は、記憶されている応答および要求された属性値に基づいて新たな応答を生成し、該新たな応答メッセージの送信時刻を現在時刻に修正する。たとえば、メッセージ送信時刻を現在時刻「Date:  Tue,  29  Sep  2015  06:01:59  GMT」に修正する。受付部は、資源をコピーし、資源内の、目標属性以外の属性を、コピーされたバージョンから削除し、コピーされたバージョンの応答における属性値「contentSize」および属性値「content」に基づいて新たな応答を生成する。新たな応答は次のように示される。
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠して、応答成功200  OKを示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>        /資源部分の始まりを示す
<contentSize>1k</contentSize>    /contentSizeの属性値が「1k」であることを示す
<content>cloudy</content>        /contentの属性値が「曇り」であることを示す
<contentInstance>        /資源部分の終わりを示す。
【０１００】
新たな応答の上記の例から、有効な目標属性は、受付部に記憶されている目標属性（contentSize=1kおよびcontent=cloudy）であることがわかる。
【０１０１】
５０８．受付部は、有効な目標属性を端末に送る。
【０１０２】
受付部は、有効な目標属性を端末に直接送ってもよい。
【０１０３】
任意的に、有効な目標属性が応答に加えられ、メッセージ送信時刻を修正した後に、受付部は応答を端末に送る。
【０１０４】
具体的に送信の仕方は本願では限定されない。
【０１０５】
段階５０３ないし段階５０７は、受付部に記憶されている、目標属性が属する資源が有効期限切れである場合であることを注意しておく。
【０１０６】
任意的に、受付部が、cacheExpire属性値に基づいて、目標属性が属する資源が有効期限切れでないと判定する場合、有効な目標属性は、受付部に記憶されているURIによって示される、有効期限切れになっていない属性値内容である。受付部は、ローカルに記憶されている目標属性（contentおよびcontentSize）を使うことにより、かつ端末によって要求された目標属性に基づいて、応答を直接生成し、該応答を端末に返す。
【０１０７】
受付部は、記憶されている目標属性を端末に送ってもよく、あるいは該目標属性を応答に加えて、該応答を端末に送ってもよい。具体的な送信の仕方は限定されない。
【０１０８】
受付部は、メッセージ送信時刻を修正して、記憶されている目標属性に基づいて応答を生成する。応答は次のようなものである。
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠して、応答成功200  OKを示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>        /資源部分の始まりを示す
<contentSize>1k</contentSize>    /contentSizeの属性値が「1k」であることを示す
<content>cloudy</content>        /contentの属性値が「曇り」であることを示す
<contentInstance>        /資源部分の終わりを示す。
【０１０９】
有効な目標属性は、cacheExpire属性値によって示され、有効期限切れでない、資源に含まれる目標属性である。
【０１１０】
この実施形態では、受付部に記憶機構が導入され、端末が受付部に目標属性を要求するとき、受付部はURIの資源部分をインデックスとして使って記憶を探索する。目標属性が属する資源がローカルに記憶されていると判定する場合、受付部は、資源のcacheExpire属性値に基づいて、資源が有効期限切れかどうかを判定する。資源が有効期限切れでない場合、受付部は、資源サーバーから資源を取得する必要なく、記憶されている目標属性を端末に送る。それにより、資源サーバーと受付部との間のデータ伝送を大幅に削減する。さらに、資源が有効期限切れであると受付部が判定する場合には、受付部は資源のlastModifiedTimeの属性値を資源サーバーに送る。資源サーバーは、lastModifiedTimeの受領された属性値をlastModifiedTime最新の属性値と比較し、lastModifiedTimeの二つの属性値が異なっている場合、資源サーバーはさらに、lastModifiedTimeの記憶されている属性値に対応する目標属性内であり、lastModifiedTimeの受領された属性値に対応する目標属性に対して変化している属性値内容を判別し、変化している属性値内容のみを受付部に送り、目標属性内のすべての属性値内容を受付部に送ることはしない。それにより、受付部と資源サーバーとの間の冗長な情報伝送を大幅に削減し、ネットワーク資源を節約する。
【０１１１】
２．端末が資源を取得することを要求する。
【０１１２】
図６を参照するに、本発明は、以下の段階を含む資源取得方法を提供する。
【０１１３】
６０１．端末は、資源を取得するために、受付部に、第三の要求を送る。ここで、第三の要求は資源の一様資源識別子URIを担持している。
【０１１４】
たとえば、端末は気象情報を取得する。
【０１１５】
端末は第三の要求を受付部に送る。ここで、第三の要求は資源<contentInstance>を取得することを要求するために使われる。
【０１１６】
第三の要求は次のようなものである：
GET  /m2m.provider.com/CSE221/container/contentinstance  HTTP/1.1
第三の要求に担持されるURIは：
/m2m.provider.com/CSE221/container/contentinstance
である。第三の要求およびURIの説明については、上記の実施形態における段階５０１の説明を参照されたい。ここで再び詳細を述べることはしない。
【０１１７】
６０２．受付部は第三の要求を受領し、URIに基づいて、受付部がその資源を記憶していることを判別する。
【０１１８】
受付部は、第三の要求において担持されているURIを受領し、URIをパースし、端末がその資源を要求していることを判別する。URIのパースおよびその資源が要求されていることの判別の説明については、上記の実施形態における段階５０２を参照されたい。ここで再び詳細を述べることはしない。
【０１１９】
受付部は、URIの資源部分をインデックスとして使ってローカル記憶を探索して、第三の要求を使って要求された資源がローカルに記憶されているかどうかを判定する。
【０１２０】
たとえば、受付部は、URIの資源部分：
「/m2m.provider.com/CSE221/container/contentinstance」をインデックスとして使ってローカル記憶を探索し、資源contentinstanceが属する資源がローカル記憶に存在することを判別する。受付部に記憶されている資源に含まれる属性値内容は次の表４に示される。
【０１２１】
【表４】
2019506696.tif 000007
６０３．受付部は、URIによって指示される資源が有効期限切れであることを判別する。
【０１２２】
受付部は、cacheExpire属性値に基づいて、資源が有効期限切れであることを判別する。cacheExpire属性値に基づいて、資源が有効期限切れであるかどうかを判定することの説明については、上記の実施形態における段階５０３を参照されたい。ここで再び詳細を述べることはしない。
【０１２３】
６０４．受付部は、資源サーバーに第四の要求を送る。ここで、第四の要求は、受付部に記憶されている資源のlastModifiedTimeの属性値と、前記URIとを担持する。
【０１２４】
たとえば、第二の要求は次のようなものである：
GET/m2m.provider.com/CSE221/container/contentinstance  HTTP/1.1
LastModifiedTime:  Tue,  29  Sep  2015  04:51:59  GMT
ここで、第四の要求のヘッダ・フィールドがlastModifiedTimeを担持し、lastModifiedTimeの属性値は：Tuesday,  September  29,  2015,  04:51:59  Greenwich  Mean  Timeである。
【０１２５】
第四の要求において担持されるURIは：
/m2m.provider.com/CSE221/container/contentinstanceである。
【０１２６】
第四の要求およびURIの説明については、上記の実施形態の段階５０１の記述を参照されたい。ここで再び詳細を述べることはしない。
【０１２７】
６０５．資源サーバーは第四の要求を受領し、第四の要求は資源の一様資源識別子URIおよび資源のlastModifiedTimeの属性値を担持する。
【０１２８】
資源サーバーは、lastModifiedTimeのローカルに記憶されている属性値がlastModifiedTimeの受領された属性値と同じかどうかを判定する。資源のlastModifiedTimeの属性値がlastModifiedTimeの受領された属性値と異なるときは、資源サーバーは、要求された資源におけるすべての属性を一つずつ比較する。資源サーバーは、資源サーバーに記憶されている資源内であり、受付部に記憶されている資源に対して変化している属性値内容を判別する。
【０１２９】
任意的に、資源サーバーは、変化している属性値内容に基づいて応答を生成する。
【０１３０】
第四の要求は、資源を要求するために使われる。資源は、属性「contentSize」「content」「lastModifiedTime」および「cacheExpire」を含む。具体的な実際の応用では、資源に含まれる属性は四つの属性に限定されない。これは限定ではなく、単にこの実施形態における説明のための例である。表５参照。
【０１３１】
【表５】
2019506696.tif 000008
上記の表５から、lastModifiedTimeの属性値が異なることがわかる。資源サーバーに記憶されている資源内であり、受付部に記憶されている資源に対して変化している属性値を資源サーバーによって決定するために二つの方法がある。第一の方法では、属性の属性値が直接比較される。表５に示されるように、「contentSize」の属性値は変化しておらず、いずれも「1K」である。「content」の属性値は変化しており、一方は「raining」であり、他方は「cloudy」である。「cacheExpire」の属性値は変化しており、一方は「2015-9-29,  06:00:00」であり、他方は「2015-9-29,  07:00:00」である。「lastModifiedTime」の属性値は変化しており、一方は2015-9-29,  05:51:59であり、他方は2015-9-29,  04:51:59である。
【０１３２】
第二の方法では、属性の更新時刻が比較される。すなわち、資源の各属性は更新時刻に対応する。表６を参照するに、更新時刻は各属性のフラグ・ビットの状態値であり、各属性は更新時刻をもつ。
【０１３３】
【表６】
2019506696.tif 000009
第二の方法では、資源サーバーは属性の属性値を比較する必要はなく、属性値の更新時刻を比較する。lastModifiedTimeについては、lastModifiedTimeの更新時刻と属性値は同じであることを注意しておくべきである。上記の表６から、「contentSize」に対応する更新時刻は同じであり、「content」に対応する更新時刻は異なっており、「cacheExpire」に対応する更新時刻は異なっており、lastModifiedTimeに対応する更新時刻は異なっていることがわかる。したがって、資源サーバーに記憶されている資源内であり、受付部に記憶されている資源に対して更新刻が変わっている属性値内容は、content=raining、cacheExpire=2015-9-29,  07:00:00およびlastModifiedTime=2015-9-29,  05:51:59であり、変化しない属性値内容はcontentSize＝1Kである。
【０１３４】
資源サーバーによって実行される、変化がある属性値についての比較の結果は同じであるが、比較のための方法は異なることが理解されうる。第一の方法では、属性の属性値が直接比較されるが、第二の方法では、属性値の更新時刻が比較される。
【０１３５】
６０６．資源サーバーは受付部に、変化のある属性値内容を送る。
【０１３６】
任意的に、変化のある属性値内容は応答に加えられてもよい。
【０１３７】
資源サーバーによって生成されたメッセージの送信時刻が「Tue,  29  Sep  2015  06:01:59  GMT」であり、応答が、変化のある属性値内容（content=raining、cacheExpire=Tue,  29  Sep  2015,  07:00:00  GMT）に基づいて生成される場合、応答は次のようなものである：
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠し、200  OK応答成功を示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT    
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<partialUpdate>        /部分的更新が始まることを示す
<contentInstance>  /資源部分が始まることを示す
<content>raining</content>    /contentの属性値が「雨」であることを示す
<cacheExpire>Tue,  29  Sep  2015  07:00:00  GMT</cacheExpire>
/cacheExpireの属性値が2015年9月29日火曜日07:00:00であることを示す
<lastModifiedTime>2015-9-29,  05:51:59    /lastModifiedTimeの属性値が「2015-9-29,  05:51:59」であることを示す
<contentInstance>        /資源部分の終わりを示す
</partialUpdate>        /部分的更新の終わりを示す。
【０１３８】
任意的に、資源サーバーは、異なる状態コード、たとえば3xyを使って、資源内の部分的な属性値が変化していることを示してもよい。
【０１３９】
変化する属性値内容または前記応答を受領するとき、受付部は、該変化する属性値内容に基づいて、対応する属性値を更新し、更新された属性値を記憶することを注意しておくべきである。たとえば、上記の応答が説明のための例として使われる。受付部は「raining」に応答してローカルに記憶されている資源のcontentの属性値を更新し、「cacheExpire」の属性値を「Tue,  29  Sep  2015  07:00:00  GMT」に更新し、「lastModifiedTime」の属性値を「2015-9-29,  05:51:59」に更新する。
【０１４０】
６０７．受付部は変化のある属性値内容を受領し、有効な資源を決定する。
【０１４１】
任意的に、受付部は、前記応答を受領してもよい。前記応答は、変化のある属性値内容を含む。
【０１４２】
受付部は前記応答の指標識別子（partialUpdateなど）を受領してもよく、あるいは特定の応答状態コード（3xc  partial  update）を使うことによって、前記資源内の部分的な属性値内容が変化していることを判別してもよいことが理解されうる。
【０１４３】
この場合、受付部は、有効な資源は、変化している受領された属性値内容と、記憶されている資源内の、変化していない属性値内容であることを判別する。
【０１４４】
受付部は、変化している受領された属性値内容に基づいて、ローカル記憶内の変化していない属性値内容を判別する。前記資源において、属性値内容のある部分が変化していることが判別される場合、属性値内容の他の部分は変化していない。
【０１４５】
任意的に、有効な属性値内容が新たな応答に加えられてもよい。具体的には、受付部は、メッセージ送信時刻を現在時刻に修正し、前記応答に、変化していない、ローカルに記憶されている属性値内容（contentSize＝1k）を加えて、新たな応答を生成する。
【０１４６】
任意的に、受付部は、前記応答を受領する。受付部は、メッセージ送信時刻を現在時刻に修正し、変化している属性値内容を更新し、更新された属性値内容を記憶する。たとえば、受付部は「content」の属性値を「raining」に更新し、「cacheExpire」の属性値を「Tue,  29  Sep  2015  07:00:00  GMT」に更新し、「lastModifiedTime」の属性値を「2015-9-29,  05:51:59」に更新する。受付部は、更新されたローカルに記憶された資源に基づいて、新たな応答を生成する。
【０１４７】
任意的に、受付部は、メッセージ送信時刻を現在時刻に修正し、contentのローカルに記憶されている属性値を「raining」に更新し、「cacheExpire」の属性値を「Tue,  29  Sep  2015  07:00:00  GMT」に更新し、「lastModifiedTime」の属性値を「2015-9-29,  05:51:59」に更新し、「contentSize」の属性値を不変に維持して、新たな応答を生成する。
【０１４８】
生成される新たな応答の例は次のようなものである。
HTTP/1.1  200  OK        /バージョンHTTP/1.1に準拠して、応答成功200  OKを示す
Content-Type:  application/xml    /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT
/メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>        /資源部分の始まりを示す
<contentSize>1k</contentSize>    /contentSizeの属性値が「1k」であることを示す
<content>raining</content>        /contentの属性値が「雨」であることを示す
<cacheExpire>Tue,  29  Sep  2015  07:00:00  GMT</cacheExpire>
/cacheExpireの属性値が2015年9月29日火曜日07:00:00であることを示す
<lastModifiedTime>2015-9-29,  05:51:59    /lastModifiedTimeの属性値が「2015-9-29,  05:51:59」であることを示す
<contentInstance>        /資源部分の終わりを示す。
【０１４９】
６０８．受付部は、有効な資源を端末に送る。
【０１５０】
受付部は、有効な資源を端末に直接送ってもよい。
【０１５１】
任意的に、有効な資源が応答に加えられ、メッセージ送信時刻を修正した後に、受付部は応答を端末に送る。
【０１５２】
次のことに注意しておくべきである。
【０１５３】
（１）段階６０３ないし段階６０７は、受付部に記憶されている資源が有効期限切れである場合である。任意的に、受付部が、cacheExpire属性値に基づいて、資源が有効期限切れでないと判定する場合、有効な資源は、受付部に記憶されている、URIによって示される資源である。
【０１５４】
（２）段階６０５ないし段階６０７は、資源サーバーによって受領されるlastModifiedTimeの属性値が資源サーバーに記憶されているlastModifiedTimeの属性値と異なる場合である。任意的に、資源サーバーによって受領されるlastModifiedTimeの属性値が資源サーバーに記憶されているlastModifiedTimeの属性値と同じである場合、資源サーバーは識別子情報を生成してもよい。識別子情報は、受付部に記憶されている資源が変化していないこと、すなわち変化している属性値内容が空集合であることを示す。
【０１５５】
任意的に、この識別子情報が前記応答に加えられてもよい。前記応答は、受付部に記憶されている資源が変化していないことを示し、前記応答は次のようなものである：
HTTP/1.1  304  Not  Modified
返される304応答が第四の要求を使って要求された目標属性が変化していないことを示すことを示す
Date:  Tue,  29  Sep  2015  06:01:59  GMT
メッセージ送信時刻がグリニッジ平均時2015年9月29日火曜日06:01:59であることを示す。
【０１５６】
受付部が資源サーバーによって送られた前記識別子情報または前記応答を受領するとき、受付部は、有効な資源が受付部に記憶されている資源であると判別する。
【０１５７】
（３）この実施形態において、段階６０２ないし６０７は、受付部が資源の応答を記憶している場合である。受付部が、第三の要求に基づいて、受付部が資源の応答を記憶していないと判別する場合には、受付部は第三の要求を資源サーバーに転送する必要があり、資源サーバーから該資源を初めて取得する。第三の要求は段階６０１において示されている。
【０１５８】
資源サーバーが第三の要求を受領し、第三の要求がlastModifiedTimeを担持していない場合、そのことは、その資源が初めて要求されたことを示す。資源サーバーは、資源のURIに基づいて、その資源が要求されていることを判別し、資源サーバーは応答を生成する。
【０１５９】
たとえば、応答は次のようなものである。
HTTP/1.1  200  OK        /200  OKは、バージョンHTTP/1.1の標準に準拠して、応答成功を示す
Content-Type:  application/xml        /メッセージ本体の内容形式がXMLであることを示す
Date:  Tue,  29  Sep  2015  05:51:59  GMT    /メッセージ送信時刻
<?xml  version="1.0"  encoding="UTF-8"?>
<contentInstance>  /資源部分の始まり
<lastModifiedTime>Tue,  29  Sep  2015  04:51:59  GMT</lastModifiedTime>
/この資源のlastModifiedTimeの属性値はグリニッジ平均時2015年9月29日火曜日04:51:59
<contentSize>1k</contentSize>    /contentSizeの属性値は「1k」
<content>cloudy</content>        /contentの属性値は「曇り」
<cacheExpire>Tue,  29  Sep  2015  06:00:00  GMT</cacheExpire>
/この資源のcacheExpireの属性値はグリニッジ平均時2015年9月29日火曜日06:00:00
…
<contentInstance>        /資源部分の終わり。
【０１６０】
前記応答の受領後、受付部は、cacheExpireに基づいて、記憶がサポートされる必要があることを判別することがある。すなわち、資源がcacheExpire属性値を含むとき、受付部は応答全体を記憶する。
【０１６１】
図５に対応する実施形態における段階５０２における資源と図６に対応する実施形態における段階６０２における資源はそれぞれ、端末が初めて受付部から要求を取得した後に、受付部が資源サーバーから応答を取得して記憶した後に得られたものであることが理解されうる。受付部に記憶されている資源は更新され、それにより、データが定期的に更新され、記憶されることができる。好ましくは、データは、資源サーバーによって受付部にその後返される、変化する属性値内容に基づいて、同期的に更新され、記憶される。
【０１６２】
この実施形態では、受付部に記憶機構が導入され、端末が受付部に資源を要求するとき、受付部はURIをインデックスとして使って記憶を探索する。資源が該記憶に記憶されていると判定する場合、受付部は、cacheExpire属性値に基づいて、資源が有効期限切れかどうかを判定する。資源が有効期限切れでない場合、受付部は、資源サーバーから資源を取得する必要なく、記憶されている資源を端末に送る。それにより、資源サーバーと受付部との間のデータ伝送を大幅に削減する。さらに、資源が有効期限切れであると受付部が判定する場合には、受付部は資源のlastModifiedTimeの属性値を資源サーバーに送る。資源サーバーは、lastModifiedTimeの受領された属性値をlastModifiedTimeのローカルに記憶されている属性値と比較し、lastModifiedTimeの二つの属性値が異なっている場合、資源サーバーはさらに、lastModifiedTimeの記憶されている属性値に対応する資源内であり、lastModifiedTimeの受領された属性値に対応する資源に対して変化している属性値を判別し、変化している属性値のみを受付部に送り、資源内のすべての属性値を受付部に送ることはしない。それにより、受付部と資源サーバーとの間の冗長な情報伝送を大幅に削減し、ネットワーク資源を節約する。
【０１６３】
資源取得方法が上記で詳細に記載されている。本発明の実施形態はさらに、受付部を提供する。図７に示される受付部７００の概略的な構造図を参照するに、受付部は受領モジュール７０１、判別モジュール７０２および送信モジュール７０３を含む。
【０１６４】
受領モジュール７０１は、資源に含まれる目標属性を取得するために端末によって送られた第一の要求を受領するよう構成され、ここで、第一の要求は目標属性の一様資源識別子URIを担持している。
【０１６５】
判別モジュール７０２は、受領モジュール７０１によって受領されたURIに基づいて、前記目標属性が属する資源を受付部が記憶していることを判別するよう構成される。ここで、前記目標属性は、前記資源に含まれる部分的な内容である。
【０１６６】
送信モジュール７０３は、URIによって示される有効な目標属性を端末に送るよう構成される。
【０１６７】
さらに、受領モジュール７０１は、図５および図６において受付部によって実行される段階５０２、段階５０７、段階６０２および段階６０７のような段階を実行するようさらに構成される。判別モジュール７０２は、図５および図６において受付部によって実行される段階５０３および段階６０３を実行するようさらに構成される。送信モジュールは、図５および図６における段階５０４、段階５０８、段階６０４および段階６０８を実行するよう構成される。ここで本発明のこの実施形態において詳細を述べることはしない。
【０１６８】
さらに、図７の受付部は、機能モジュールの形で呈示されている。本稿での「モジュール」は、一つまたは複数のソフトウェアもしくはファームウェア・プログラムを実行する特定用途向け集積回路（application-specific  integrated  circuit、ASIC）、回路、プロセッサおよびメモリ、集積論理回路および／または上記の機能を提供できる別の装置を指しうる。単純な実施形態では、当業者は、図７の受付部が図３に示される形であってもよいことを把握しうる。モジュールは、図３のプロセッサ、トランシーバおよびメモリを使って実装されてもよい。
【０１６９】
図８に示されるように、本発明のある実施形態はさらに、資源サーバーの概略的な構造図を提供する。資源サーバーはM2Mシステムに適用される。本装置は：受領モジュール８０１、判別モジュール８０２および送信モジュール８０３を含む。
【０１７０】
受領モジュール８０１は、資源に含まれる目標属性を取得するために受付部によって送られた第二の要求を受領するよう構成される。第二の要求は目標属性の一様資源識別子URIと、資源の最終修正時刻属性とを担持している。目標属性は、資源に含まれる部分的な内容である。
【０１７１】
判別モジュール８０２は、資源サーバーに記憶されている目標属性の最終修正時刻属性値が、受領された最終修正時刻属性値と異なるときは、資源サーバーに記憶されている目標属性内であり、受付部に記憶されている目標属性に対して変化している属性値内容を判別するよう構成される。
【０１７２】
送信モジュール８０３は、変化している属性値内容を受付部に送るよう構成される。
【０１７３】
さらに、受領モジュール８０１は、図５の段階５０５における「第二の要求を受領する」段階および図６の段階６０５における「第四の要求を受領する」段階を実行するようさらに構成される。判別モジュール８０２は、図５における段階５０５における「資源サーバーに記憶されている目標属性の最終修正時刻属性値が、受領された最終修正時刻属性値と異なるときは、資源サーバーに記憶されている目標属性内であり、受付部に記憶されている目標属性に対して変化している属性値内容を判別する」段階および図６における段階６０５における「資源の記憶されている最終修正時刻属性値が、資源の受領された最終修正時刻属性値と異なるときは、資源サーバーに記憶されている資源内であり、受付部に記憶されている資源に対して変化している属性値内容を判別する」段階をさらに実行してもよい。送信モジュール８０３は、図５および図６における段階５０６および段階６０６を実行するようさらに構成されてもよい。ここで本発明のこの実施形態において詳細を述べることはしない。
【０１７４】
さらに、図８の装置は、機能モジュールの形で呈示されている。本稿での「モジュール」は、一つまたは複数のソフトウェアもしくはファームウェア・プログラムを実行する特定用途向け集積回路（application-specific  integrated  circuit、ASIC）、回路、プロセッサおよびメモリ、集積論理回路および／または上記の機能を提供できる別の装置を指しうる。単純な実施形態では、当業者は、図８の装置が図３に示される形であってもよいことを把握しうる。モジュールは、図３のトランシーバ、プロセッサおよびメモリを使って実装されてもよい。
【０１７５】
本発明のある実施形態はさらに、上記の方法実施形態を実行するために設計されたプログラムを含め、図７に示される受付部および図８に示される資源サーバーによって使用されるコンピュータ・ソフトウェア命令を記憶するよう構成されたコンピュータ可読媒体を提供する。資源は、記憶されたプログラムを実行することによって取得されうる。
【０１７６】
当業者は、本願の主題の全部または一部が、ハードウェアおよび／またはファームウェアと組み合わせたソフトウェアにおいて実装されうることを理解するはずである。たとえば、本明細書に記載される主題は、一つまたは複数のプロセッサによって実行されるソフトウェアで実装されてもよい。実装の例では、本明細書に記載される主題は、コンピュータ実行可能命令を記憶する非一時的なコンピュータ可読媒体を使って実装されてもよい。コンピュータ・プロセッサがコンピュータ実行可能命令を実行するとき、該命令が、諸段階を実行するようコンピュータを制御する。本明細書に記載される主題の実装に適用可能なコンピュータ可読媒体の例は、非一時的なコンピュータ可読媒体、たとえば磁気ディスク記憶媒体、チップ記憶デバイス、プログラム可能な論理デバイスまたは特定用途向け集積回路を含む。加えて、本明細書に記載される主題を実装するコンピュータ可読媒体は、単一のデバイスまたはコンピューティング・プラットフォームに位置していてもよく、あるいは複数のデバイスまたはコンピューティング・プラットフォームに分散されてもよい。
【０１７７】
最後に、上記の実施形態が単に本発明の技術的解決策を記述するために意図されたものであり、本発明を限定するためではないことを注意しておくべきである。本発明は上記の実施形態を参照して詳細に記述されているが、当業者は、本発明の実施形態の技術的解決策の範囲から外れることなく、上記の実施形態に記述されている技術的解決策に修正を加えたり、あるいはそのいくつかの技術的特徴に等価な置換を行なったりしてもよいことを理解するはずである。
【図１】
2019506696.tif 000010
【図２】
2019506696.tif 000011
【図３】
2019506696.tif 000012
【図４】
2019506696.tif 000013
【図５】
2019506696.tif 000014
【図６】
2019506696.tif 000015
【図７】
2019506696.tif 000016
【図８】
2019506696.tif 000017
【手続補正書】
【提出日】平成30年8月29日(2018.8.29)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マシンツーマシンM2M通信システムに適用される資源取得方法であって：
受付部によって、資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
前記受付部によって、前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを含む、
方法。
【請求項２】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別することを含み、前記有効な資源は具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源である、
請求項１記載の方法。
【請求項３】
前記資源が、前記資源の有効期間を示すために使われる時間属性および最終修正時刻属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れであることを判別する段階と；
前記受付部によって、第二の要求を資源サーバーに送る段階であって、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持する、段階と；
前記受付部によって、前記資源サーバーによってフィードバックされた属性値内容を受領する段階であって、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容である、段階と；
前記受付部によって、受領された前記属性値内容に基づいて、前記受付部に記憶されている前記資源を更新する段階であって、前記資源の前記有効期間についての前記時間属性および前記最終修正時刻属性を更新することを含み、更新された資源が有効な資源であり、具体的には、受領された前記属性値内容と、前記資源の、前記受付部に記憶されている、変化していない属性値内容とである、段階と；
前記受付部によって、前記有効な資源を前記資源要求者に送る段階とを含む、
請求項１記載の方法。
【請求項４】
前記資源識別子は一様資源識別子URIまたはM2Mシステムにおいて定義されている資源識別子である、請求項１ないし３のうちいずれか一項記載の方法。
【請求項５】
前記資源要求者が前記受付部に登録される、請求項１ないし４のうちいずれか一項記載の方法。
【請求項６】
マシンツーマシンM2M通信システムに適用される資源取得方法であって：
資源を取得するための、受付部によって送られた第二の要求を、資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、前記資源サーバーによって判別する段階と；
前記変化している値内容を前記資源サーバーによって前記受付部に送る段階とを含む、
資源取得方法。
【請求項７】
マシンツーマシンM2M通信システムに適用される受付部であって：
資源を取得するために資源要求者によって送られた第一の要求を受領するよう構成された受領モジュールであって、前記第一の要求は前記資源の資源識別子を担持する、受領モジュールと；
前記受領モジュールによって受領された前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する判別モジュールと；
前記資源識別子によって示される有効な資源を前記資源要求者に送るよう構成された送信モジュールとを有する、
受付部。
【請求項８】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別し、前記有効な資源が具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源であることを判別するよう構成される、
請求項７記載の受付部。
【請求項９】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れであることを判別するよう構成され；
前記送信モジュールはさらに、第二の要求を資源サーバーに送るよう構成され、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持し；
前記受領モジュールはさらに、前記資源サーバーによってフィードバックされた属性値内容を受領して、前記受付部に記憶されている資源を更新するよう構成されており、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容であり；
前記判別モジュールはさらに、前記資源が有効な資源が具体的には、前記受付部によって受領された、変化している前記属性値内容と、前記資源の、変化していない属性値内容とであることを決定するよう構成されており；
前記送信モジュールはさらに、前記有効な資源を前記資源要求者に送るよう構成されている、
請求項７記載の受付部。
【請求項１０】
マシンツーマシンM2M通信システムに適用される資源サーバーであって：
資源を取得するための、受付部によって送られた第二の要求を受領するよう構成された受領モジュールであって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、受領モジュールと；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、判別するよう構成された判別モジュールと；
前記変化している値内容を前記受付部に送るよう構成されている送信モジュールとを有する、
資源サーバー。
【請求項１１】
コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
トランシーバと；
前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
M2Mシステムに適用される受付部であって、
前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを
当該受付部に実行させる、
受付部。
【請求項１２】
コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
トランシーバと；
前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
M2Mシステムに適用される資源サーバーであって、
前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
資源を取得するための、受付部によって送られた第二の要求を資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の属性値内容であって、前記受付部に記憶されている前記資源に対して変化している属性値内容を、判別する段階と；
前記変化している値内容を前記受付部に送る段階とを
当該資源サーバーに実行させる、
資源サーバー。
【請求項１３】
前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、前記命令がさらに次の動作、すなわち：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別する段階を、前記受付部に実行させ、前記有効な資源は具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源である、
請求項１２記載の受付部。
【請求項１４】
前記資源が、前記資源の有効期間を示すために使われる時間属性および最終修正時刻属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、前記命令がさらに、次の動作、すなわち：
前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れであることを判別する段階と；
前記受付部によって、第二の要求を資源サーバーに送る段階であって、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持する、段階と；
前記受付部によって、前記資源サーバーによってフィードバックされた属性値内容を受領する段階であって、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容である、段階と；
前記受付部によって、受領された前記属性値内容に基づいて、前記受付部に記憶されている前記資源を更新する段階であって、前記資源の前記有効期間についての前記時間属性および前記最終修正時刻属性を更新することを含み、更新された資源が有効な資源であり、具体的には、受領された前記属性値内容と、前記資源の、前記受付部に記憶されている、変化していない属性値内容とである、段階と；
前記受付部によって、前記有効な資源を前記資源要求者に送る段階とを前記受付部に実行させる、
請求項１２記載の受付部。
【請求項１５】
前記資源識別子は一様資源識別子URIまたはM2Mシステムにおいて定義されている資源識別子である、請求項１２ないし１４のうちいずれか一項記載の受付部。
【請求項１６】
前記資源要求者が前記受付部に登録される、請求項１２ないし１４のうちいずれか一項記載の受付部。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
本発明は通信分野に、詳細には資源取得方法および関係した装置に関する。
【国際調査報告】
2019506696.tif 000018
2019506696.tif 000019
2019506696.tif 000020
2019506696.tif 000021