JP2019506696A - 資源取得方法および関係した装置 - Google Patents

資源取得方法および関係した装置 Download PDF

Info

Publication number
JP2019506696A
JP2019506696A JP2018558470A JP2018558470A JP2019506696A JP 2019506696 A JP2019506696 A JP 2019506696A JP 2018558470 A JP2018558470 A JP 2018558470A JP 2018558470 A JP2018558470 A JP 2018558470A JP 2019506696 A JP2019506696 A JP 2019506696A
Authority
JP
Japan
Prior art keywords
resource
attribute value
stored
receiving unit
attribute
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2018558470A
Other languages
English (en)
Inventor
ワン，スチェン
イン，ジィアシン
ジャン，ヨンジン
ツェン，ミッチ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2019506696A publication Critical patent/JP2019506696A/ja
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H04L67/5682—Policies or rules for updating, deleting or replacing the stored data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/26—Resource reservation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • G06F16/9574—Browsing optimisation, e.g. caching or content distillation of access to content, e.g. by caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/565—Conversion or adaptation of application format or content
    • H04L67/5651—Reducing the amount or size of exchanged application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/27—Control channels or signalling for resource management between access points
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/365—Application layer names, e.g. buddy names, unstructured names chosen by a user or home appliance name
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Multimedia (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本発明の実施形態は、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減するための資源取得方法および関係した装置を提供する。本発明の実施形態における方法は：受付部によって、資源に含まれる目標属性を取得するために端末によって送られた第一の要求を受領する段階であって、前記第一の要求は前記目標属性の一様資源識別子URIを担持する、段階と；前記受付部によって、前記URIに基づいて、前記受付部が前記目標属性が属する資源を記憶していることを判別する段階であって、前記目標属性は前記資源に含まれる部分的な内容である、段階と；前記受付部によって、前記URIによって示される有効な目標属性を前記端末に送る段階とを含む。本発明の実施形態はさらに、受付部と資源サーバーとの間の冗長なデータ伝送を効果的に削減する受付部および資源サーバーを提供する。

Description

本願は、ここに参照によってその全体において組み込まれる、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システムのエンティティーに対応する。
上記の表１に示されるように、実際のネットワーク展開では、端末は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）を例を使って記述しておく。
外１
下記は、端末が資源の全内容（つまり、該資源）を取得することを要求するか資源の部分的内容（目標属性）を取得することを要求するかに基づいて、実施形態を具体的に記述する。図５を参照するに、この実施形態は、以下の段階を含む資源取得方法を提供する。
１．端末が目標属性を取得することを要求する。
５０１．端末は、目標属性を取得するために、受付部に、第一の要求を送る。ここで、第一の要求は目標属性の一様資源識別子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」を含む。表２参照。
上記の表２から、lastModifiedTimeの属性値が異なることがわかる。資源サーバーは、異なる資源バージョンの間の内容比較のためにlastModifiedTimeの異なる属性値に対応する異なる資源バージョンを記憶していることを注意しておくべきである。それらのバージョンは異なるが、それらのバージョンにおけるすべての属性値が変わっているわけではなく、一部の属性値のみが変わっていることがある。
資源サーバーに記憶されている目標属性内であり、受付部に記憶されている目標属性に対して変化している属性値内容を資源サーバーによって決定するために二つの方法があることを注意しておくべきである。第一の方法では、属性の属性値が直接比較される。表２に示されるように、「content size」の属性値は変化しておらず、いずれも「1K」であり、「content」の属性値は変化しており、一方は「raining」であり、他方は「cloudy」である。
第二の方法では、属性の更新時刻が比較される。すなわち、各属性は更新時刻に対応する。表３を参照するに、更新時刻は各属性のフラグ・ビットの状態値であり、各属性は更新時刻をもつ。
第二の方法では、資源サーバーは属性値を比較する必要はなく、属性値の更新時刻を比較する。上記の表３から、「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が属する資源がローカル記憶に存在することを判別する。受付部に記憶されている資源に含まれる属性値内容は次の表４に示される。
６０３．受付部は、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」を含む。具体的な実際の応用では、資源に含まれる属性は四つの属性に限定されない。これは限定ではなく、単にこの実施形態における説明のための例である。表５参照。
上記の表５から、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である。
第二の方法では、属性の更新時刻が比較される。すなわち、資源の各属性は更新時刻に対応する。表６を参照するに、更新時刻は各属性のフラグ・ビットの状態値であり、各属性は更新時刻をもつ。
第二の方法では、資源サーバーは属性の属性値を比較する必要はなく、属性値の更新時刻を比較する。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）、回路、プロセッサおよびメモリ、集積論理回路および／または上記の機能を提供できる別の装置を指しうる。単純な実施形態では、当業者は、図８の装置が図３に示される形であってもよいことを把握しうる。モジュールは、図３のトランシーバ、プロセッサおよびメモリを使って実装されてもよい。
本発明のある実施形態はさらに、上記の方法実施形態を実行するために設計されたプログラムを含め、図７に示される受付部および図８に示される資源サーバーによって使用されるコンピュータ・ソフトウェア命令を記憶するよう構成されたコンピュータ可読媒体を提供する。資源は、記憶されたプログラムを実行することによって取得されうる。
当業者は、本願の主題の全部または一部が、ハードウェアおよび／またはファームウェアと組み合わせたソフトウェアにおいて実装されうることを理解するはずである。たとえば、本明細書に記載される主題は、一つまたは複数のプロセッサによって実行されるソフトウェアで実装されてもよい。実装の例では、本明細書に記載される主題は、コンピュータ実行可能命令を記憶する非一時的なコンピュータ可読媒体を使って実装されてもよい。コンピュータ・プロセッサがコンピュータ実行可能命令を実行するとき、該命令が、諸段階を実行するようコンピュータを制御する。本明細書に記載される主題の実装に適用可能なコンピュータ可読媒体の例は、非一時的なコンピュータ可読媒体、たとえば磁気ディスク記憶媒体、チップ記憶デバイス、プログラム可能な論理デバイスまたは特定用途向け集積回路を含む。加えて、本明細書に記載される主題を実装するコンピュータ可読媒体は、単一のデバイスまたはコンピューティング・プラットフォームに位置していてもよく、あるいは複数のデバイスまたはコンピューティング・プラットフォームに分散されてもよい。
最後に、上記の実施形態が単に本発明の技術的解決策を記述するために意図されたものであり、本発明を限定するためではないことを注意しておくべきである。本発明は上記の実施形態を参照して詳細に記述されているが、当業者は、本発明の実施形態の技術的解決策の範囲から外れることなく、上記の実施形態に記述されている技術的解決策に修正を加えたり、あるいはそのいくつかの技術的特徴に等価な置換を行なったりしてもよいことを理解するはずである。
本発明は通信分野に、詳細には資源取得方法および関係した装置に関する。

Claims (12)

  1. マシンツーマシンM2M通信システムに適用される資源取得方法であって：
    受付部によって、資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
    前記受付部によって、前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
    前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを含む、
    方法。
  2. 前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
    前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別することを含み、前記有効な資源は具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源である、
    請求項１記載の方法。
  3. 前記資源が、前記資源の有効期間を示すために使われる時間属性および最終修正時刻属性を含み、前記受付部によって、前記資源識別子によって示される有効な資源を前記資源要求者に送る前に、当該方法がさらに：
    前記受付部によって、前記時間属性に基づいて、前記資源が有効期限切れであることを判別する段階と；
    前記受付部によって、第二の要求を資源サーバーに送る段階であって、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持する、段階と；
    前記受付部によって、前記資源サーバーによってフィードバックされた属性値内容を受領する段階であって、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容である、段階と；
    前記受付部によって、受領された前記属性値内容に基づいて、前記受付部に記憶されている前記資源を更新する段階であって、前記資源の前記有効期間についての前記時間属性および前記最終修正時刻属性を更新することを含み、更新された資源が有効な資源であり、具体的には、受領された前記属性値内容と、前記資源の、前記受付部に記憶されている、変化していない属性値内容とである、段階と；
    前記受付部によって、前記有効な資源を前記資源要求者に送る段階とを含む、
    請求項１記載の方法。
  4. 前記資源識別子は一様資源識別子URIまたはM2Mシステムにおいて定義されている資源識別子である、請求項１ないし３のうちいずれか一項記載の方法。
  5. 前記資源要求者が前記受付部に登録される、請求項１ないし４のうちいずれか一項記載の方法。
  6. マシンツーマシンM2M通信システムに適用される資源取得方法であって：
    資源を取得するための、受付部によって送られた第二の要求を、資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
    前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、前記資源サーバーによって判別する段階と；
    前記変化している値内容を前記資源サーバーによって前記受付部に送る段階とを含む、
    資源取得方法。
  7. マシンツーマシンM2M通信システムに適用される受付部であって：
    資源を取得するために資源要求者によって送られた第一の要求を受領するよう構成された受領モジュールであって、前記第一の要求は前記資源の資源識別子を担持する、受領モジュールと；
    前記受領モジュールによって受領された前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する判別モジュールと；
    前記資源識別子によって示される有効な資源を前記資源要求者に送るよう構成された送信モジュールとを有する、
    受付部。
  8. 前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
    前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れでないことを判別し、前記有効な資源が具体的には、前記資源識別子によって示され、前記受付部に記憶されている資源であることを判別するよう構成される、
    請求項７記載の受付部。
  9. 前記資源が、前記資源の有効期間を示すために使われる時間属性を含み、
    前記判別モジュールはさらに、前記時間属性に基づいて、前記資源が有効期限切れであることを判別するよう構成され；
    前記送信モジュールはさらに、第二の要求を資源サーバーに送るよう構成され、前記第二の要求は、前記受付部に記憶されている前記資源の最終修正時刻属性値および前記資源識別子を担持し；
    前記受領モジュールはさらに、前記資源サーバーによってフィードバックされた属性値内容を受領して、前記受付部に記憶されている資源を更新するよう構成されており、前記受付部に記憶されている最終修正時刻属性値が前記資源サーバーに記憶されている最終修正時刻属性値と異なるとき、前記属性値内容は具体的には、前記資源サーバーに記憶されている資源の属性値の、前記受付部に記憶されている前記資源の属性値に対して変化している属性値内容であり；
    前記判別モジュールはさらに、前記資源が有効な資源が具体的には、前記受付部によって受領された、変化している前記属性値内容と、前記資源の、変化していない属性値内容とであることを決定するよう構成されており；
    前記送信モジュールはさらに、前記有効な資源を前記資源要求者に送るよう構成されている、
    請求項７記載の受付部。
  10. マシンツーマシンM2M通信システムに適用される資源サーバーであって：
    資源を取得するための、受付部によって送られた第二の要求を受領するよう構成された受領モジュールであって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、受領モジュールと；
    前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の値内容であって、前記受付部に記憶されている前記資源に対して変化している値内容を、判別するよう構成された判別モジュールと；
    前記変化している値内容を前記受付部に送るよう構成されている送信モジュールとを有する、
    資源サーバー。
  11. コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
    トランシーバと；
    前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
    M2Mシステムに適用される受付部であって、
    前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
    資源を取得するために資源要求者によって送られた第一の要求を受領する段階であって、前記第一の要求は前記資源の資源識別子を担持する、段階と；
    前記資源識別子に基づいて、前記受付部が前記資源を記憶していることを判別する段階と；
    前記資源識別子によって示される有効な資源を前記資源要求者に送る段階とを
    当該受付部に実行させる、
    受付部。
  12. コンピュータ実行可能なプログラム・コードを記憶するよう構成されたメモリと；
    トランシーバと；
    前記メモリおよび前記トランシーバに結合されたプロセッサとを有する、
    M2Mシステムに適用される資源サーバーであって、
    前記プログラム・コードは命令を含み、前記プロセッサによって実行されたとき、前記命令は、以下の動作、すなわち：
    資源を取得するための、受付部によって送られた第二の要求を資源サーバーによって受領する段階であって、前記第二の要求は、前記資源の資源識別子および前記資源の最終修正時刻属性を担持する、段階と；
    前記資源サーバーに記憶されている前記資源の最終修正時刻属性値が受領された最終修正時刻属性値と異なるとき、前記資源サーバーに記憶されている資源の属性値内容であって、前記受付部に記憶されている前記資源に対して変化している属性値内容を、判別する段階と；
    前記変化している値内容を前記受付部に送る段階とを
    当該資源サーバーに実行させる、
    資源サーバー。
JP2018558470A 2016-02-02 2017-01-20 資源取得方法および関係した装置 Pending JP2019506696A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
CN201610072844.6 2016-02-02
CN201610072844.6A CN107026882B (zh) 2016-02-02 2016-02-02 一种资源获取的方法及相关设备
PCT/CN2017/071939 WO2017133496A1 (zh) 2016-02-02 2017-01-20 一种资源获取的方法及相关设备

Publications (1)

Publication Number Publication Date
JP2019506696A true JP2019506696A (ja) 2019-03-07

Family

ID=59500115

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018558470A Pending JP2019506696A (ja) 2016-02-02 2017-01-20 資源取得方法および関係した装置

Country Status (6)

Country Link
US (1) US10880785B2 (ja)
EP (1) EP3402164B8 (ja)
JP (1) JP2019506696A (ja)
KR (1) KR102223260B1 (ja)
CN (1) CN107026882B (ja)
WO (1) WO2017133496A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110166502B (zh) * 2018-02-11 2021-06-01 中国移动通信有限公司研究院 数据获取方法、服务提供端、服务使用端及网络功能实体
CN113162987B (zh) * 2018-04-20 2022-09-16 华为云计算技术有限公司 一种设备状态同步的方法及公共能力组件
WO2019220010A1 (en) * 2018-05-12 2019-11-21 Nokia Technologies Oy Security management for network function messaging in a communication system
CN110764688B (zh) * 2018-07-27 2023-09-05 杭州海康威视数字技术股份有限公司 对数据进行处理的方法和装置
KR102137882B1 (ko) * 2018-10-24 2020-07-24 전자부품연구원 구독 만료 관리 방법 및 이를 적용한 m2m 시스템
US20220015096A1 (en) * 2018-11-27 2022-01-13 Hyundai Motor Company Method and device for repeatedly transmitting message in m2m system
GB2582735B (en) 2019-02-01 2022-11-30 Arm Ip Ltd Template-based registration
GB2582737B (en) * 2019-02-01 2021-07-14 Arm Ip Ltd Device registration mechanism
CN111163127B (zh) * 2019-12-02 2021-12-14 聚好看科技股份有限公司 一种媒资属性推送方法及服务器
CN113973093B (zh) * 2020-07-24 2023-10-13 中移(苏州)软件技术有限公司 数据传输方法及装置、电子设备、可读存储介质
CN112883315A (zh) * 2021-02-25 2021-06-01 北京有竹居网络技术有限公司 一种资源展示方法及装置
CN114531448B (zh) * 2022-02-21 2024-02-27 联想(北京)有限公司 算力确定方法、装置及算力共享系统

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002055870A (ja) * 2000-08-15 2002-02-20 Fuji Xerox Co Ltd データ提供装置、データ取得装置及びデータ処理システム
US20040068579A1 (en) * 2002-08-13 2004-04-08 International Business Machines Corporation System and method to refresh proxy cache server objects
US20040254921A1 (en) * 1998-06-26 2004-12-16 Edith Cohen Method and apparatus for improving end to end performance of a data network
JP2009009592A (ja) * 2008-08-08 2009-01-15 Hitachi Ltd 輻輳制御方法
JP2009076093A (ja) * 2008-11-13 2009-04-09 Softbank Mobile Corp キャッシングシステム
US20150055557A1 (en) * 2012-03-22 2015-02-26 Interdigital Patent Holdings, Inc. Method and apparatus for supporting machine-to-machine caching at a service capability layer

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101808218B (zh) * 2009-02-16 2012-07-04 深圳市闪联信息技术有限公司 电子节目单内容的获取和更新方法、装置和系统
CN103257973A (zh) * 2012-02-20 2013-08-21 腾讯科技（深圳）有限公司 浏览器缓存更新方法和系统
CN102843437A (zh) * 2012-09-17 2012-12-26 北京星网锐捷网络技术有限公司 网页应用的转换方法、装置和网络设备
US11095743B2 (en) * 2014-07-16 2021-08-17 Tensera Networks Ltd. Optimized content-delivery network (CDN) for the wireless last mile
GB2546692A (en) * 2014-10-13 2017-07-26 Seven Networks Llc Wireless traffic management system for caching at a mobile device based on user characteristics
EP3298806B1 (en) * 2015-05-20 2019-10-16 Convida Wireless, LLC Methods and apparatus for analyzing and grouping service layer subscriptions and notifications for enhanced efficiency
EP3353993B1 (en) * 2015-09-23 2023-09-06 Convida Wireless, LLC Enhanced restful operations

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040254921A1 (en) * 1998-06-26 2004-12-16 Edith Cohen Method and apparatus for improving end to end performance of a data network
JP2002055870A (ja) * 2000-08-15 2002-02-20 Fuji Xerox Co Ltd データ提供装置、データ取得装置及びデータ処理システム
US20040068579A1 (en) * 2002-08-13 2004-04-08 International Business Machines Corporation System and method to refresh proxy cache server objects
JP2009009592A (ja) * 2008-08-08 2009-01-15 Hitachi Ltd 輻輳制御方法
JP2009076093A (ja) * 2008-11-13 2009-04-09 Softbank Mobile Corp キャッシングシステム
US20150055557A1 (en) * 2012-03-22 2015-02-26 Interdigital Patent Holdings, Inc. Method and apparatus for supporting machine-to-machine caching at a service capability layer

Also Published As

Publication number Publication date
KR102223260B1 (ko) 2021-03-04
CN107026882B (zh) 2021-02-12
US20180343590A1 (en) 2018-11-29
EP3402164A4 (en) 2018-11-14
WO2017133496A1 (zh) 2017-08-10
CN107026882A (zh) 2017-08-08
KR20180107777A (ko) 2018-10-02
EP3402164B1 (en) 2022-03-09
EP3402164B8 (en) 2022-04-13
EP3402164A1 (en) 2018-11-14
US10880785B2 (en) 2020-12-29

Similar Documents

Publication Publication Date Title
JP2019506696A (ja) 資源取得方法および関係した装置
US20230319534A1 (en) Cross-resource subscription for m2m service layer
US20160227346A1 (en) Service Layer Resource Propagation Across Domains
CN107404512B (zh) 资源订阅方法、资源订阅装置和资源订阅系統
CN106534243A (zh) 基于http协议的缓存、请求、响应方法及相应装置
CN109462640B (zh) 一种元数据同步方法、数据端、交互系统及介质
US11671514B2 (en) Service layer message templates in a communications network
US20090025037A1 (en) Method, system and terminal for changing a management object of broadcast service guide
US20170353818A1 (en) Method for deleting notification resource, and common service entity
US20230053967A1 (en) Group updating method, message sending method, and apparatuses
US11323368B1 (en) System and method for web service atomic transaction (WS-AT) affinity routing
CN109688204B (zh) 基于ndn网络的文件下载方法、节点、终端
KR101986851B1 (ko) M2m 통신에서의 자원 검색 방법 및 그 장치
CN112445859A (zh) 数据管理方法、装置和系统
CN113079029A (zh) 配置信息订阅方法及装置
KR20160147861A (ko) 정보 객체 획득 방법, 서버, 및 사용자 장비
JP2016525728A (ja) 無線通信システムにおけるサーバーの端末のリソース要請又は端末のリソース提供のための方法及びこのための装置
US9798785B2 (en) Apparatus and method for searching for address book information
CN113691614B (zh) 资讯处理方法和装置
US20230396498A1 (en) Optimization of network function profile administration and discovery
CN117389756A (zh) 区块链事件处理装置、方法、设备及存储介质
CN116647594A (zh) 一种信息载体访问方法、装置及电子设备
WO2023072801A1 (en) Methods and apparatuses for network function discovery
CN117221316A (zh) 消息处理方法、消息队列遥测传输集群、装置及设备
CN116567090A (zh) 一种服务数据传输方法、系统、电子设备及存储介质

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180829

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180829

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20190626

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190702

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190917

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20200218

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200617

C60 Trial request (containing other claim documents, opposition documents)

Free format text: JAPANESE INTERMEDIATE CODE: C60

Effective date: 20200617

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20200625

C21 Notice of transfer of a case for reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C21

Effective date: 20200630

A912 Re-examination (zenchi) completed and case transferred to appeal board

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20200828

C211 Notice of termination of reconsideration by examiners before appeal proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C211

Effective date: 20200901

C22 Notice of designation (change) of administrative judge

Free format text: JAPANESE INTERMEDIATE CODE: C22

Effective date: 20201124

C23 Notice of termination of proceedings

Free format text: JAPANESE INTERMEDIATE CODE: C23

Effective date: 20210126

C03 Trial/appeal decision taken

Free format text: JAPANESE INTERMEDIATE CODE: C03

Effective date: 20210302

C30A Notification sent

Free format text: JAPANESE INTERMEDIATE CODE: C3012

Effective date: 20210302