JP7420743B2 - 購読サーバ、購読端末、情報購読方法及びシステム - Google Patents

Description

関連出願
本願は、２０１８年５月１８日に提出された中国特許出願Ｎｏ．２０１８１０４７９２２９．６の優先権を要求し、ここで上記の中国特許出願に開示された内容を本願の一部分として援用する。

本開示は、モノのインターネットの技術分野に関し、特に、購読サーバ、購読端末及び情報購読方法とシステムに関する。

モノのインターネット（ＩｏＴ）システムにおいて、Ｍ２Ｍ（Ｍａｃｈｉｎｅ ｔｏ Ｍａｃｈｉｎｅ）は、重要な方面の一つであり、機器端末のインテリジェントインタラクションを中核としたネットワーク化の応用とサービスである。一つの機器は、別の機器のイベントを購読することができ、これにより、別の機器にイベントが発生する時に、別の機器のイベントを取得することができる。通常、イベントは、複数の部分、例えば、中核的部分と補助部分を含む可能性がある。中核的部分はイベントの中核である。しかし、中核的部分だけでは応用のニーズを満足できなく、総合的に判定するには、ほかの補助部分の協力が必要となる。

イベント購読のメカニズムを利用してイベントの情報を取得する関連方法は、以下のとおりである：中核的情報を取得した後、さらに補助情報に対する取得請求を送信することにより、補助情報を取得し、かつ、補助情報を取得しなければ、完全なイベントを構築できない。つまり、イベントの中核的情報を取得した後、イベントの処理を即時に行うことができず、さらにほかの補助情報を取得する必要がある。このような方法の課題は、イベントの処理時間を遅らせるかもしれないことにある。

イベント購読のメカニズムを利用してイベント情報を取得する別の関連方法は、以下のとおりである：イベントの完全な情報を取得するために、イベントの中核的情報と補助情報をそれぞれ購読する必要がある。しかし、中核的情報と補助情報の送信周期が通常に異なるため、被通知側が通知側からの補助情報を絶えず受信するが、中核的情報を待ってイベント処理を行う状況が現れるかもしれない。このような方法の課題は、イベントの中核的情報がない時に、補助情報を受信するため、被通知側の処理負担が増加すると同時に、被通知側と通知側のインターネット負荷が増加することにある。

第１の方面において、本開示は、情報購読方法を提供した。該方法は、第１実体からの請求の請求情報が該第１実体に関連する購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報と確認することと、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することと、第１情報と第２情報を含む通知メッセージを前記購読リソースの被通知側に送信することと、を含む。

ある実施例において、前記購読リソースは、前記イベント通知規則、前記関連対象、及び、前記被通知側の通知アドレスの標識符号を含む。

ある実施例において、前記購読リソースは、前記イベント通知規則と前記被通知側の通知アドレスの標識符号を含む。前記関連対象は、前記第１実体のリソースの容器において作成された関連対象である。

ある実施例において、前記関連対象は、関連リソース、または、関連リソースの標識を含む。前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することは、前記関連リソースから前記イベントの第２情報を取得すること、または、前記関連リソースの標識に基づき、対応した関連リソースから前記イベントの第２情報を取得することと、を含む。

ある実施例において、前記判定の前に、前記購読リソースの請求側からの第１実体に対する購読請求を受信することをさらに含む。前記購読請求に前記イベント通知規則、前記関連リソースの標識、及び、前記被通知側の通知アドレスの標識符号を含む。受信した購読請求に基づき第１実体に対する前記購読リソースを作成する。

ある実施例において、前記購読リソースに、通知内容のタイプをさらに含む。また、前記通知内容のタイプの選択可能な値は、関連リソースのタイプの値を含む。

ある実施例において、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することは、前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することを含む。

ある実施例において、第１実体は、応用実体または汎用サービス実体である。

ある実施例において、前記請求は、内容実例を作成する請求または内容実例を更新する請求を含む。

ある実施例において、前記方法は、第１実体によって送信される内容実例を作成する請求に基づき、第１実体のリソースに用いられる容器において新しい内容実例を作成し、かつ、受信した情報を前記新しい内容実例において記憶すること、をさらに含む。

ある実施例において、前記関連リソースは、実体のリソース、容器または内容実例を含む。前記実体は、応用実体または汎用サービス実体を含む。

ある実施例において、前記関連リソースは、第１実体と異なる第２実体のリソースである。前記購読リソースの関連対象に基づき前記イベントの前記第２情報を取得することの前に、該方法はさらに以下を含む：第２実体によって送信される前記イベントの第２情報を携帯する内容実例を作成する請求を受信することと、第２実体によって送信される内容実例を作成する請求に基づき、第２実体のリソースの容器において新しい内容実例を作成し、前記イベントの第２情報を前記新しい内容実例において記憶することをさらに含む。

ある実施例において、前記イベントの第１情報はイベントの中核的情報であり、前記イベントの第２情報はイベントの補助情報である。

ある実施例において、前記イベントの中核的情報は交通事故の発生情報であり、前記イベントの補助情報は事故車両の位置情報である。第１実体は交通事故の識別応用実体であり、第２実体は車両位置のセンシング応用実体である。

第２の方面において、本開示は、購読サーバをさらに提供した。該購読サーバは、確認モジュール、取得モジュールと送信モジュールを含む。確認モジュールは、第１実体からの請求の請求情報が第１実体に関連する購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報と確認するためのものである。取得モジュールは、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得するためのものである。送信モジュールは、第１情報と第２情報を含む通知メッセージを前記購読リソースの被通知側に送信するためのものである。

ある実施例において、前記購読サーバは、前記購読リソースの請求側からの第１実体に対する購読請求を受信した後、前記購読請求に基づき第１実体の前記購読リソースを作成するための作成モジュールをさらに含む。前記購読請求は、前記イベント通知規則、関連リソースの標識、及び、前記被通知側の通知アドレスの標識符号を含む。前記関連リソースの標識は、前記関連対象を作成するためのものである。

ある実施例において、前記購読サーバは、前記購読リソースの請求側からの第１実体に対する購読請求を受信した後、前記購読請求に基づき第１実体の前記購読リソースを作成するための作成モジュールをさらに含む。前記購読請求は、前記イベント通知規則及び前記被通知側の通知アドレスの標識符号を含む。

ある実施例において、前記取得モジュールは、前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得するためのものである。

ある実施例において、前記請求は、内容実例を作成する請求を含む。前記購読サーバは、受信モジュールと作成モジュールをさらに含む。受信モジュールは、第１実体によって送信される内容実例を作成する請求を受信するためのものである。作成モジュールは、前記の内容実例を作成する請求に基づき、第１実体のリソースの容器において、新しい内容実例を作成し、かつ、受信した情報を前記新しい内容実例において記憶するためのものである。

ある実施例において、前記関連リソースは、前記第１実体と異なる第２実体のリソースである。前記受信モジュールはさらに、第２実体によって送信される前記イベントの第２情報を携帯する内容実例を作成する請求を受信するためのものである。前記作成モジュールはさらに、第２実体によって送信される内容実例を作成する請求に基づき、第２実体のリソースの容器において、新しい内容実例を作成し、かつ、前記イベントの第２情報を前記新しい内容実例において記憶するためのものである。

第３の方面において、本開示は購読端末をさらに提供した。該購読端末は、購読請求モジュールと通知メッセージの処理モジュールを含む。購読請求モジュールは、第１実体に対する購読請求を購読サービス実体に送信することにより、第１実体に関連する購読リソースを作成するためのものである。前記購読請求は、イベント通知規則及び前記購読リソースの被通知側の通知アドレスの標識符号を含む。通知メッセージの処理モジュールは、前記購読サービス実体によって送信される通知メッセージを受信かつ処理するためのものである。前記通知メッセージは、第１実体によって送信される請求の内容情報に基づき確認したイベントの第１情報と、前記購読リソースの関連対象に基づき取得した前記イベントの第２情報とを含む。

ある実施例において、前記購読請求は、前記購読リソースにおける関連対象を作成するための関連リソースの標識をさらに含む。

ある実施例において、前記購読請求は、通知内容のタイプをさらに含む。該通知内容のタイプは、関連リソースのタイプの値として設置される。

第４の方面において、本開示は、情報購読システムをさらに提供した。該情報購読システムは、第１実体、上記の購読サービス実体、購読端末を含む。第１実体は、請求を送信するためのものである。購読端末は、前記購読リソースの被通知側として、前記通知メッセージを受信かつ処理するためのものである。

第５の方面において、本開示は、別の情報購読システムをさらに提供した。該情報購読システムは、請求を送信するための第１実体と、上記の購読サービス実体と、上記の購読端末を含む。購読端末は、前記購読リソースの被通知側として、前記通知メッセージを受信かつ処理するためのものである。

第６の方面において、本開示は、コンピュータ読み取り可能な指令が記憶されたコンピュータ読み取り可能な媒体をさらに提供した。前記コンピュータ読み取り可能な指令は、計算デバイスの実行時に前記計算デバイスに上記の方法を実行させる。

第７の方面において、本開示は、計算デバイスをさらに提供した。該計算デバイスは、一つまたは複数のプロセッサと、複数の指令が記憶されているメモリを含む。前記複数の指令は、前記一つまたは複数のプロセッサの実行に応答して、前記一つまたは複数のプロセッサに上記の方法を実行させる。

本開示の目的、技術案及び利点をより明瞭にさせるために、以下、図面を参照し、具体的な実施例を合わせて、ある実施例において本開示を詳細に説明する。

関連技術の情報購読方法のフロー図である； 関連技術の別の情報購読方法のフロー図である； 本開示の実施例による情報購読システムの構成図である； 本開示の実施例による購読サービス実体が、登録した実体に対してローカルに作成するリソースのデータ構造である； 本開示の実施例による購読サービス実体が、登録した実体に対してローカルに作成するリソースの別のデータ構造である； 本開示の実施例による購読サービス実体が購読リソースを作成する方法フロー図である； 本開示の実施例による情報購読方法のフロー図である； 本開示の実施例による購読サービス実体の内部構造のフレーム図である； 本開示の実施例による購読端末の内部構造のフレーム図である。

以下、本開示の実施例を詳しく説明する。前記実施例の例は、図面において示されており、そのうち、同じまたは類似の記号は同じまたは類似の素子または同じまたは類似した機能を有する素子を表示する。以下、図面を参照して記載した実施例は、本開示に対する制限と解釈することができなく、例示的な、本開示を説明するためのものに過ぎない。

当業者にとって理解できるように、別段の指定、または、文脈から明らかに単数形式であるという意味がなければ、ここで使用される「一」、「一つ」、「前記」と「該」は、複数の形式を含んでもよい。ここで使用される用語である「及び／または」は、１つまたは複数の互いに関連付けられたリスト項目の任意またはすべての可能な組み合わせを含む。

本開示の実施形態において、「第１」と「第２」等を使用するすべての表現は、２つの同じ名称の異なる実体または異なるパラメータを区別するためであることを説明する必要がある。本開示の文脈において、「第１」、「第２」などは、表現の便宜を図るためのものに過ぎなく、本開示の実施例に対する限定として理解するべきではない。

Ｍ２Ｍ通信システムの機能フレームは、応用実体（ＡＥ）と汎用サービス実体（ＣＳＥ）を定義した。応用実体は、Ｍ２Ｍの応用サービスロジック、例えば、交通事故の処理応用、カーネットワーキング応用、工業制御応用などを実現する実体である。汎用サービス実体は、サービス機能を実現する実体を代表し、一つのグループの「汎用サービス機能」を実例化するものであり、主にデータ管理、デバイス管理、購読管理及び安全メカニズムなどを含む。

図１は、関連技術における情報購読方法のフロー図を示す。該方法において、イベント購読のメカニズムを利用してイベントの中核的情報と補助情報を取得する。図１においては、応用実体１（ＡＥ１）、応用実体２（ＡＥ２）、応用実体３（ＡＥ３）及び汎用サービス実体（ＣＳＥ）を示す。一例の交通事故のシーンにおいて、ＡＥ１は、交通事故を識別する識別応用実体であってもよく、ＡＥ２は、交通事故の関連データを感知するセンシング応用実体であり、ＡＥ３は、交通事故を処理する管理応用実体である。

初期に、応用実体ＡＥ１は、登録請求をＣＳＥに送信することにより、ＣＳＥにおいて登録することができる。ＣＳＥは、登録請求に基づき、ＡＥ１に対して、ＡＥ１のリソースを作成し、かつ、登録応答をそれに返す。

それに類似して、ＡＥ２及び／またはＡＥ３もＣＳＥにおいて登録することができる。登録が成功した後、それに応じて、ＣＳＥは、ＡＥ２及び／またはＡＥ３のリソースをローカルに作成することができる。

例示したシーンにおいて、ＡＥ３は、交通事故の情報を得ることで交通事故の処理を行うように配置されている。このため、交通事故の処理を行うには、ＡＥ１によって送信される交通事故の発生情報（イベントの中核的情報）及びＡＥ２によって採集される事故車両の位置情報（イベントの補助情報）を得る必要がある。

１０１において、ＡＥ１のイベントを購読するように、ＡＥ３は、ＡＥ１に対する購読請求をＣＳＥに送信することができる。それに応じて、ＣＳＥは、ＡＥ１のリソースの下で購読リソースを作成し、かつ、購読応答をＡＥ３に送信する。

１０２において、ＡＥ１は、イベント（例えば、交通事故）の発生を検出する時に、内容実例を作成する請求をＣＳＥに送信し、その中には、発生したイベントに関連する内容情報、例えば、交通事故の発生情報を含む。ＣＳＥは、ＡＥ１の請求を受信した後、ＡＥ１のリソースの容器＜ＡＥ１＞／ｃｏｎｔａｉｎｅｒの下で内容実例を作成し、その中には、交通事故の発生情報を記録し、かつ、内容実例の作成の応答をＡＥ１に送信する。

１０３において、それに応じて、ＣＳＥは、さらにＡＥ１におけるイベントに関する通知請求を発生してＡＥ３に通知する。ＡＥ３は、通知請求を受け取った後に、通知応答をＣＳＥに送信し、かつ、該イベントに関連するリソースパラメータを取得する。

取得したリソースパラメータから、次の処理を行うには、ＡＥ３にとって、例えば、該交通事故における事故車両の位置情報を含むＡＥ２における情報をさらに取得する必要があることを発見する時に、１０４において、ＡＥ３は、ＡＥ２における情報を取得する情報請求をＣＳＥに送信する。ＣＳＥは、該情報請求に対して応答して、ＡＥ２における情報を提供する。ＡＥ３は、ＡＥ１の情報と取得したＡＥ２の情報に基づき、完全なイベントメッセージパッケージを構築して、交通事故の処理を行う。

該方法の課題は、以下のとおりである：ＡＥ３がイベントの中核的情報を取得した後、イベントの処理を即時に行うことができず、さらにほかの実体の有する情報を取得する必要があり、よって、イベントの処理時間を遅らせる。交通事故にとって、これは、ベスト事故救援時間を逃がすかもしれないことを意味する。

図２は、関連技術の別の情報購読方法のフロー図を示す。図１と類似しているように、図２は、ＡＥ１、ＡＥ２、ＡＥ３及びＣＳＥに関し、かつ、初期に、ＡＥ１－３もＣＳＥにおいて登録されている。

２０１において、ＡＥ３は、ＡＥ１とＡＥ２の両方に対する購読請求をＣＳＥに送信して、ＡＥ１とＡＥ２のイベントをそれぞれ購読する。それに応じて、ＣＳＥは、ＡＥ１リソースとＡＥ２リソースの下で購読リソースを作成し、かつ、購読応答をＡＥ３に送信する。

２０２において、ＡＥ２は、内容実例を作成／更新する請求を送信することにより、例えば車両の位置情報を定期的にＣＳＥへ送信する。ＣＳＥは、ＡＥ２の情報を受信する度に、内容実例を新しく作成／更新して、イベントを記録し、かつ、内容実例の作成／更新の応答をＡＥ２に送信する。

２０３において、それに応じて、ＣＳＥは、さらに通知請求をＡＥ３に送信することにより、ＡＥ２からの情報をそれに送信する。ＡＥ３は、通知請求を受け取った後に、通知応答をＣＳＥに送信する。

２０４において、ＡＥ１は、イベントの発生、例えば交通事故の発生を検出する時に、内容実例を作成する請求をＣＳＥに送信する。ＣＳＥは、ＡＥ１の請求を受信した後、ＡＥ１リソースの容器＜ＡＥ１＞／ｃｏｎｔａｉｎｅｒの下で内容実例を作成し、その中に、交通事故の発生情報を記録し、かつ、内容実例の作成の応答をＡＥ１に送信する。

２０５において、それに応じて、ＣＳＥは、さらにＡＥ１におけるイベントに関する通知請求を発生してＡＥ３に通知する。ＡＥ３は、通知請求を受け取った後に、通知応答をＣＳＥに送信する。

あるシーンにおいて、ＡＥ１が交通事故を検出した後に、ＡＥ２が、車両の位置情報を引き続き送信する可能性がある。このように、２０６において、ＡＥ２は、内容実例を作成／更新する請求を送信することにより、例えば車両の位置情報をＣＳＥに送信する。ＣＳＥは、ＡＥ２の情報を受信した後、同様に内容実例を新しく作成／更新してイベントを記憶し、かつ、内容実例の作成／更新の応答をＡＥ２に送信する。

２０７において、それに応じて、ＣＳＥは、さらに通知請求をＡＥ３に送信することにより、ＡＥ２からの情報をそれへ送信する。ＡＥ３は、通知請求を受け取った後に、通知応答をＣＳＥに送信する。

ＡＥ３は、ＡＥ１で発生したイベント、即ちＡＥにおける交通事故の発生情報を受信したと判断した後、その前に受信したＡＥ２の情報を取得する。ＡＥ３は、例えば、ＡＥ１におけるイベント情報と、ＡＥにおけるイベントが発生する時間と最も近いＡＥ２データを用いて、完全なイベントメッセージパッケージを構築することにより、交通事故処理を行う。

該方法の課題は、例えば、カーネットワーキングのシーンにおいて、交通事故の発生情報の報告周期がより長く、車両位置情報の報告周期がより短い、ということである。このように、ＣＳＥは、車両位置に類似した補助情報を携帯する通知メッセージを絶えず購読情報の被通知側（例えば、ＡＥ３）に送信する。被通知側は、補助情報で生成したイベントのみに基づき判定を行うことができなく、交通事故発生情報に類似した中核的情報を待つ必要がある。このため、イベントの中核的情報がない時に、補助情報の受信により、被通知側の処理負担が増加すると同時に、被通知側（例えば、ＡＥ３）と通知側（例えば、ＣＳＥ）のインターネット負担も増加した。

本開示の実施例によれば、購読サービス実体、購読端末、情報購読方法及びシステムが提供されている。それは、通知側と被通知側のインターネット負荷の増加を回避するとともに、イベントの通知メッセージを受信した後に、イベントを即時に処理するための十分な情報を保証することができる。

本開示の実施例において、第１実体（例えば、ＡＥ１）が請求情報を購読サービス実体（例えば、ＣＳＥ）に送信した後、購読サービス実体は、請求情報が購読リソースにおけるイベント通知規則を満足すると判定するなら、請求の内容情報をイベントの第１情報と確認する；さらに、前記購読リソースの関連対象（例えば、ＡＥ２のリソース）から前記イベントの第２情報を取得し、第１情報と第２情報を含む通知メッセージを前記購読リソースの被通知側（例えば、ＡＥ３）に送信する。このように、イベントの第１情報を購読する時に、購読サービス実体は、イベントに関連する第２情報も取得することにより、完全なイベント情報として組み合わせて、通知メッセージにおいて被通知側（例えば、ＡＥ３）に送信する。このように、購読リソースの被通知側は、イベントの通知メッセージを受信した後に、完全なイベント情報に基づき、イベントを即時に処理し、イベント処理時間の遅延を回避することができる；一方、イベントの第２情報を直接的に購読しないため、購読情報の通知メッセージ量が減少し、被通知側と通知側のインターネット負荷が軽くなった。

図３は、本開示の実施例による情報購読システムの構成図を示す。該情報購読システムは、第１実体３０１、購読サーバ３０２及び購読リソースの被通知側３０３が含まれた。購読サーバ３０２は、購読サービス実体を含んでもよい。下記において、購読サーバと購読サービス実体は、相互交換可能に使用することができる。

第１実体３０１は、請求を購読サーバ３０２に送信するためのものである。第１実体は、購読される実体であってもよい。ある実施例において、第１実体３０１は、Ｍ２Ｍ通信における応用実体（ＡＥ）であってもよい。

別の実施例において、第１実体は、さらに汎用サービス実体であってもよい。Ｍ２Ｍ通信システムの機能フレームは、応用サービスノード（ＡＳＮ）を定義した。それは、一つの汎用サービス実体と少なくとも一つの応用実体を含むことができる。このようなシーンにおいて、応用実体は、まず同じＡＳＮに含まれる汎用サービス実体に登録することができる。その後、汎用サービス実体は、ＡＳＮを代表して購読サービス実体に対して作成、取得、更新、削除及び通知などの請求を送信し、かつ購読サービス実体の応答を受信することができる。

ある実施例において、請求は、内容実例を作成する請求または内容実例を更新する請求であってもよい。例示的に、第１実体は、イベントの発生（例えば、交通事故の発生または車両位置の変化）を検出する時に前記請求を送信する。そのことの代わりに、第１実体は、前記請求を定期的に送信することにより、購読サービス実体において記憶される情報を周期的に作成または更新することもできる。請求は、請求情報を含んでもよい。請求情報は、請求のタイプ、例えば、請求に係る動作を指示するためのタイプ情報であってもよい。付加的または代わりに、請求情報は、例えばイベントに関連する情報を送信するための内容情報であってもよい。

購読サーバ３０２は、第１実体３０１によって送信される請求の請求情報が購読リソースにおけるイベント通知規則を満足することを受信かつ判定した後、前記請求の内容情報をイベントの第１情報と確認する。該購読リソースは、該第１実体のリソースの下で作成されるサブリソースであってもよく、イベント通知規則などの属性を含むことができる。請求情報がイベント通知規則を満足することは、該請求の内容情報がイベントとして購読リソースにおいて指定される被通知側に通知されることを表明する。

購読サーバ３０２は、さらに前記購読リソースの関連対象に基づき、前記イベントの第２情報を取得する。関連対象は、関連リソースまたは関連リソースの標識を含むことができる。一例において、関連対象は、第２実体３０４のリソースであってもよい。第２実体３０４は、購読サーバ３０２に登録され且つその上で対応したリソースを作成する実体であってもよい。これにより、購読サーバ３０２は、第２実体３０４のリソースから第２実体３０４からの前記イベントに関連する第２情報を取得することができる。購読サーバ３０２は、前記イベントの第１情報と第２情報を含む通知メッセージを、購読リソースにおいて指定される被通知側３０３に送信する。購読サーバ３０２における購読サービス実体は、Ｍ２Ｍ通信における汎用サービス実体（ＣＳＥ）であってもよい。

購読リソースの被通知側３０３は、購読サービス実体３０２によって送信される通知メッセージを受信かつ処理するためのものである。被通知側３０３は、通知メッセージに含まれる第１情報と第２情報に基づき、関連するイベントを処理することができる。購読リソースの被通知側３０３は、応用実体（ＡＥ）または汎用サービス実体（ＣＳＥ）であってもよい。本文において、第３実体と購読リソースの被通知側は、相互交換可能に使用することができる。

ある実施例において、第１実体は、情報を購読サーバに送信する前に、まず購読サーバにおいて登録することができる。登録が成功した後、購読サーバは、第１実体のリソースをローカルに作成する。

図４は、本開示の実施例による購読サービス実体が、登録した実体に対してローカルに作成したリソースのデータ構造を示す。例えば、図４に示すように、第１実体と第２実体の登録後、購読サービス実体は、それらに対して、第１実体のリソースと第２実体のリソースをそれぞれ作成する。それぞれの実体のリソースにおいて、サブリソース、例えば容器をさらに作成することができる。図４には、第１実体のリソースにおいて、第１実体の容器がさらに作成されていることを示す。容器において、購読リソースを作成することができる。購読リソースは、異なる属性、例えば、イベント通知規則、通知アドレスの標識符号及び関連対象等を含むことができる。通知アドレスの標識符号は、例えば、前記購読リソースの被通知側の通知アドレス、例えば、ＵＲＩ（即ち、第３実体のＵＲＩ）であってもよい。関連対象の存在は、該購読リソースのイベント通知がさらに該購読リソースに関連するほかの対象に関することを表明することができる。関連対象は、同一のリソースにおけるほかのサブリソースに指向／関連する関連リソースの標識であってもよく、ほかのリソースまたはほかのリソースにおけるサブリソース、例えば、容器または内容実例などに指向／関連する関連リソースの標識であってもよい。例えば、図４に示すように、第１実体の購読リソースの関連対象は、第２実体の容器に指向することができる。付加的または代わりに、関連リソースの標識は、リソースタイプの標識をさらに含むことができ、これにより、同一のタイプの一つまたは複数のリソースに指向／関連する。このように、簡単な形態で複数のリソースを同時に関連させ、購読効率を向上させた。

好ましくは、購読リソースの属性は、さらに通知内容のタイプを含むことができる。通知内容のタイプが関連リソースのタイプの値として設置される時に、指示通知メッセージは、関連対象の関連情報を含むべきである。

容器において、さらに内容実例、例えば、図４に示す第２実体の容器の下の複数の内容実例を作成することができる。ある例において、イベントが発生し、かつ、具体的な内容が生成する時に、イベントに関連する内容情報を記憶するための内容実例を作成することができる。

本開示のこの実施例において、購読リソースの関連対象は、購読リソースにおいて設置されている。それに応じて、購読リソースにおける関連対象は、購読リソースの請求側が購読請求により管理することができ、例えば、設置、変更または削除などを行う。

図５は、購読サービス実体が登録した実体に対してローカルに作成したリソースの別のデータ構造を示す。図４と類似しているように、購読サービス実体は、それぞれの登録した実体に対して、リソースを作成することができる。それぞれの実体のリソースにおいて、例えば、容器のサブリソースをさらに作成することができる。容器において、購読リソースと内容実例などを作成することができる。図４との相違は以下のとおりである：購読リソースの関連対象は、該購読リソースの属性として作成するのではなく、変更することにより、購読される実体（図５中において、第１実体）のリソースの容器においてサブリソースとして作成することができる。

この実施例において、購読リソースの関連対象は、購読リソースの被購読側（例えば、第１実体）のリソースの容器において直接的に設置されるので、関連対象は、購読リソースの請求側によって購読請求により個別に設置、変更または削除されなくてもよく、第１実体の複数の購読リソースによって共有されることができる。ある実施例において、関連対象は、購読サービス実体または第１実体によって設置、変更または削除することができる。

図６は、本開示の実施例による購読サービス実体で購読リソースを作成する方法フロー図を示す。

Ｓ６０１：購読リソースの請求側は、第１実体に対する購読請求を、購読サービス実体に送信する。購読リソースの請求側は、購読リソースの被通知側自体であってもよく、即ち、前述の第３実体であってもよい。その代わりに、購読リソースの請求側は、ほかの実体に対して購読請求を送信し、かつ、購読請求においてほかの実体を被通知側と指定することもできる。これにより、それは、購読サービス実体において登録したほかの実体であってもよい。

好ましくは、購読リソースの請求側が購読サービス実体に送信する第１実体に対する購読請求は、イベント通知規則、関連リソースの標識、及び、通知アドレスの標識符号（例えば、第３実体のＵＲＩ）が含まれた。このように、関連対象の関連情報は、購読リソースの請求側が購読請求によって設置または変更することができる。その代わりに、請求側によって送信される購読請求は、関連リソースの標識を含まなくてもよい。このように、関連対象の関連情報は、購読サービス実体によって設置または変更されることができる。

好ましくは、購読請求は、さらに通知内容のタイプを含むことができる。通知内容のタイプは、関連リソースのタイプの値として設置されることができる。

Ｓ６０２：購読サービス実体は、購読リソースの請求側によって送信される購読請求に基づき、第１実体の購読リソースを作成する。

好ましくは、購読サービス実体は、購読リソースの請求側によって送信される購読請求に基づき、第１実体のリソースの容器において購読リソースを作成することができる。作成される購読リソースは、イベント通知規則、関連対象、及び、通知アドレスの標識符号、例えば、前記購読リソースの被通知側のＵＲＩ（即ち、第３実体のＵＲＩ）を含むことができる。その代わりに、購読請求が関連リソースの標識を含まない時に、作成される購読リソースは、関連対象を含まなくてもよい。この時に、第１実体のリソースの容器において作成される関連対象を前記購読リソースの関連対象として用いることができる。

関連対象は、関連リソース、または、関連リソースの標識を含むことができる。例を挙げて言えば、関連リソースは、第２実体のリソース／容器／最も新しい内容実例など、または、これらのリソースに対応したリソース標識であってもよい。

好ましくは、購読請求にさらに通知内容のタイプを含む場合について、作成される購読リソースは、さらに通知内容のタイプを含むことができる。購読請求における通知内容のタイプを関連リソースのタイプの値として設置すれば、作成される購読リソースにおける通知内容のタイプも関連リソースのタイプの値として設置される。このように、作成される購読リソースが関連対象を含まない場合において、購読サービス実体も、該購読リソースのイベント通知がさらにほかの関連リソースに関することが分かる。

Ｓ６０３：購読サービス実体は、購読応答を購読リソースの請求側に返すことにより、購読を完了させる。

付加的または代わりに、購読サービス実体は、購読請求に基づき第１実体を作成する購読リソースを除いて、管理員によって入力される購読リソースの作成指令に基づき、第１実体の購読リソースをローカルに作成することもできる。

第１実体の購読リソースを作成した後、購読請求において指定される購読リソースの被通知側は、購読サービス実体から第１実体に関する購読情報を受け取ることができる。図７は、本開示の実施例による情報購読の方法フロー図を示す。

Ｓ７０１：第１実体は、購読サービス実体に請求を送信する。

好ましくは、第１実体は、イベントの発生を検出した後に、請求を購読サービス実体に送信することができる。前記請求は、例えば、内容実例を作成する請求または内容実例を更新する請求であってもよい。請求は、請求情報を含むことができる。例えば、カーネットワーキングのシーンにおいて、第１実体は、交通事故の識別応用モジュールであり、購読サービス実体が関連するイベントを記憶するように、交通事故の発生を検出した後、交通事故の発生情報を、内容実例を作成する請求に携帯して、購読サービス実体に送信する。

Ｓ７０２：購読サービス実体は、前記請求における請求情報が該第１実体の購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報として確認する。

好ましくは、購読サービス実体は、第１実体によって送信される内容実例を作成する請求に基づき、第１実体のリソースの容器において、新しい内容実例を作成し、受信した情報を、作成された内容実例に記憶する。

購読サービス実体は、請求情報と購読リソースのイベント通知規則を比較する。請求情報が購読リソースのイベント通知規則を満足するなら、前記請求の内容情報をイベントの第１情報として確認する。好ましくは、前記イベントの第１情報は、イベントの中核的情報であってもよい。例えば、カーネットワーキングのシーンにおいて、イベントの中核的情報は、交通事故の発生情報であってもよい。

ある実施例において、請求情報は、請求の内容情報を含むことができる。それに応じて、イベント通知規則によってモニターされたものは、請求における具体的な内容である。付加的にまたは代わりに、請求情報は、請求に対応したタイプ（動作）情報を含むことができる。それに応じて、イベント通知規則によってモニターされたものは、請求に関するタイプまたは動作である。

例示的なカーネットワーキングのシーンにおいて、第１実体の請求は、内容容器１の下の内容実例１を作成する請求（内容：ｉｓＡｃｃｉｄｅｎｔ＝Ｙ（事故であるか。＝はい））であり、それに応じて、タイプ情報は、内容容器１の下の内容実例１を作成することであり、内容情報は、内容容器１の下の内容実例１である（内容：ｉｓＡｃｃｉｄｅｎｔ＝Ｙ）。

一例において、イベント通知規則は、請求における具体的な内容をモニターすることができる。例えば、イベント内容＝（ｉｓＡｃｃｉｄｅｎｔ＝Ｙ）を通知する時に、第１情報は、内容容器１の下の内容実例１（内容：ｉｓＡｃｃｉｄｅｎｔ＝Ｙ）として確認することができる。別の例において、イベント通知規則は、請求のタイプをモニターすることができる。例えば、イベントのタイプ＝内容容器１の内容実例を作成することを通知する時に、第１情報は、内容容器１の下の内容実例１として確認することができる（内容：ｉｓＡｃｃｉｄｅｎｔ＝Ｙ）。

Ｓ７０３：購読サービス実体は、前記購読リソースの関連対象に基づき、前記イベントの第２情報を取得する。関連対象は、前記購読リソースにおける一つの属性であってもよく、かつ、好ましくは、購読請求に基づき作成される。または、関連対象は、前記第１実体のリソースの容器において、サブリソースとして作成され、かつ、好ましくは、第１実体の複数の購読リソースによって共有されることができる。

ある実施例において、購読リソースが通知内容のタイプを含む場合について、通知内容のタイプの値は、通知メッセージに含まれる内容のタイプを指示することができる。通知内容のタイプは、複数の選択可能な値を含むことができる。例えば、通知内容のタイプの値は、通知メッセージに含まれる内容がイベントの補正の属性であることを指示するための「補正属性のタイプの値」であってもよい。通知内容のタイプの値は、さらに通知メッセージに含まれる内容がイベントの全ての属性であることを指示するための「全部属性のタイプの値」であってもよい。

本開示の実施例によれば、通知内容のタイプの値は、さらに通知メッセージに関連リソースの関連情報をさらに含むための「関連リソースのタイプの値」に拡張されることができる。このように、従来の購読リソースにおけるデータ構造を利用して本開示の実施例に新しく増加された機能を実現することができ、即ち、通知メッセージは、関連リソースの関連情報をさらに携帯する。

ある実施例において、本ステップにおいて、購読サービス実体は、前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソース中の中、または、購読リソースの外の関連対象に基づき、前記イベントの第２情報を取得することができる。

購読リソースの関連対象は、関連リソース、または、関連リソースの標識を含むことができる。購読サービス実体は、関連リソースの標識に基づき、対応した関連リソースから前記イベントの第２情報を取得することができ、または、購読サービス実体は、関連リソースから前記イベントの第２情報を直接的に取得することができる。

関連リソースは、実体（第１実体とほかの実体）のリソース、容器、または内容実例などであってもよい。実体は、応用実体または汎用サービス実体を含むことができる。

例を挙げて言えば、関連リソースは、第１実体と異なる第２実体のリソースであってもよい。それに応じて、関連対象の標識は、第２実体のリソースの標識であってもよく、かつ、購読サービス実体は、第２実体のリソースの標識に基づき、第２実体のリソースから前記イベントの第２情報を取得することができる。

第２実体は、購読サービス実体に予め登録される実体であってもよい。第２実体が購読サービス実体に登録される時に、購読サービス実体も第２実体のリソースをローカルに作成した。

第２実体は、購読サービス実体に登録された後、イベントの第２情報を、内容実例を作成する請求に携帯して、購読サービス実体に送信することができる。前記イベントの第２情報は、イベントの補助情報であってもよい。例示的に、該第２情報は、第２実体によって、内容実例を作成する請求に定期的に携帯され、購読サービス実体に送信されることができる。例えば、カーネットワーキングのシーンにおいて、第２実体は、車両における位置センシング応用モジュールであってもよく、イベントの第２情報は、車両の位置情報であってもよい。購読サービス実体は、路側ユニットであってもよい。第２実体は、イベントの第２情報（例えば、車両の位置情報）を、内容実例を作成する請求に定期的に携帯し、購読サービス実体に送信することができる。購読サービス実体は、第２実体によって送信される内容実例を作成する請求を受信しる度に、新しい内容実例を作成し、該内容実例において、内容実例を作成する請求におけるイベントの第２情報（例えば、車両の位置情報）を記憶する。このように、購読サービス実体は、第１実体から受信した請求の内容情報がイベントの第１情報であると確認すれば、関連対象、即ち、第２実体のリソースから新しく作成された内容実例において記憶されるイベントの第２情報（例えば、車両の位置情報）を取得することができる。

Ｓ７０４：購読サービス実体は、通知メッセージを、前記購読リソースの被通知側としての第３実体に送信する。

本ステップにおいて、購読サービス実体は、イベントの第１情報と第２情報を含む通知メッセージを第３実体に送信する。イベントの第１情報と第２情報は、情報内容の自体であってもよいし、情報標識であってもよい。

Ｓ７０５：前記購読リソースの被通知側としての第３実体は、通知メッセージを受信かつ処理する。

本ステップにおいて、第３実体は、イベントの第１情報と第２情報を含む通知メッセージを受信した後、通知メッセージからイベントの完全な情報を取得することができ、これにより、イベントを直接的に処理し、イベント処理時間の遅延を回避することができる。また、第２実体のイベントの第２情報を直接的に購読しなくてもよく、購読情報の通知メッセージ量が減少し、第３実体と購読サービス実体のインターネット負荷が軽くなった。カーネットワーキングのシーンにおいて、第３実体は、交通事故の管理応用モジュールであってもよく、通知メッセージを受信した後、通知メッセージにおける交通事故の発生情報及び車両の位置情報に基づき、交通事故の処理を即時に行うことができる。

図８は、本開示の実施例による購読サーバの内部構造のフレーム図を示す。該購読サーバは、確認モジュール８０１、取得モジュール８０２、送信モジュール８０３が含まれた。

確認モジュール８０１は、第１実体からの請求の請求情報が第１実体の購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報として確認するためである。前記購読リソースは、前記イベント通知規則、及び、被通知側の通知アドレスの標識符号以下を含む。前記購読リソースは、対応した関連対象をさらに備える。関連対象は、属性として購読リソースに含まれてもよいし、購読リソースと異なるサブリソースとして作成されてもよい。前記関連対象は、関連リソース、または、関連リソースの標識を含む。ある実施例において、購読リソースは、通知内容のタイプをさらに含むことができる。好ましくは、前記イベントの第１情報は、イベントの中核的情報であってもよい。

取得モジュール８０２は、前記購読リソースの関連対象に基づき、前記イベントの第２情報を取得するためのものである。好ましくは、取得モジュール８０２は、前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソースの関連対象に基づき、前記イベントの第２情報を取得する。前記関連リソースは、第１実体のほかのサブリソース、または、ほかの実体のリソース、容器または内容実例などであってもよい。ほかの実体は、応用実体、または、汎用サービス実体を含むことができる。好ましくは、前記イベントの第２情報は、イベントの補助情報であってもよい。

送信モジュール８０３は、前記イベントの第１情報と第２情報を含む通知メッセージを、前記購読リソースの被通知側に送信するためのものである。

ある実施例において、購読サーバは、作成モジュール８０４をさらに含むことができる。作成モジュール８０４は、前記購読リソースの請求側からの第１実体に対する購読請求を受信した後、前記購読請求に基づき、第１実体の前記購読リソースを作成する。前記購読請求は、前記イベント通知規則、関連リソースの標識、及び、通知アドレスの標識符号を含むことができる。

ある実施例において、購読サーバは、受信モジュール８０５をさらに含むことができる。受信モジュール８０５は、第１実体からの内容実例を作成する請求を受信するためのものである。作成モジュール８０４は、該請求に基づき、第１実体のリソースの容器において、新しい内容実例を作成し、受信した請求における情報（イベントの第１情報を含む）を、作成された内容実例に記憶する。

前記関連リソースが、例えば、第２実体のリソースである時に、受信モジュール８０５は、第２実体からの前記イベントの第２情報を携帯する内容実例を作成する請求をさらに受信する。作成モジュール８０４は、該請求に基づき、第２実体によって送信される内容実例を作成する請求に基づき、第２実体のリソースにおいて、第２実体の容器内に新しい内容実例を作成し、かつ、前記イベントの第２情報を、第２実体の新しく作成された内容実例において記憶する。

図６と図７に対して検討したすべての可能性は、図８に対しても有効であることを指摘する必要がある。

例示的に、購読サーバは、プロセッサとメモリを含む計算デバイスであってもよく、それは、サーバの形式を採用してもよいし、デスクトップパソコン、ノートパソコン、スマートフォン、タブレット、及び、ほかの、プロセッサとメモリを含む電子デバイスであってもよい。

図９は、本開示の実施例による購読端末の内部構造のフレーム図を示す。該購読端末は、購読リソースの請求側としてもよいし、購読リソースの被通知側としてもよい。該購読端末は、購読請求モジュール９０１と通知メッセージ処理モジュール９０２を含む。

購読請求モジュール９０１は、第１実体に対する購読請求を購読サーバに送信することにより、第１実体に関連する購読リソースを作成するためのものである。前記購読請求は、イベント通知規則、関連リソース標識、及び、被通知側の通知アドレスの標識符号を含む。ある実施例において、購読請求は、関連リソースのタイプの値として設置される通知内容のタイプをさらに含むことができる。

通知メッセージ処理モジュール９０２は、前記購読サーバによって送信される通知メッセージを受信かつ処理するためのものである。前記通知メッセージは、第１実体によって送信される請求の内容情報に基づき確認したイベントの第１情報と、前記購読リソースの関連対象に基づき取得した前記イベントの第２情報を含む。

本開示の実施例において、イベントの第１情報と第２情報をともに通知メッセージにより購読リソースの被通知側に送信するように、第１実体からのイベントの第１情報を受信した後、第１実体の購読リソースの関連対象に基づき、対応した関連対象から前記イベントの第２情報を取得することができる。このように、被通知側は、通知メッセージを受信した後、完全なイベント情報に基づき、イベントを即時に処理し、イベント処理時間の遅延を回避することができる。一方、イベントの第２情報を直接的に購読しないため、購読情報の通知メッセージ量が減少し、被通知側と通知側のインターネット負荷が軽くなった。

本開示の実施例によれば、通知内容のタイプの値を拡がることにより、通知内容のタイプの選択可能な値はさらに、通知メッセージにおいて関連リソースの関連情報を含むことを指示するための「関連リソースのタイプの値」であってもよい。このように、従来の購読リソースにおけるデータ構造を利用して、本開示の実施例に新しく増加される機能を実現することができ、よって、既存の購読メカニズムに後向きに互換することが便利である。

例示的に、購読端末は、テレビ、インテリジェント家電デバイス、充電自動車、デスクトップパソコン、ノートパソコン、スマートフォン、タブレット、ゲームコントローラー、音楽プレーヤー（例えば、ｍｐ３プレーヤーなど）、及び、ほかの、プロセッサとメモリを含む端末（例えば、移動端末、インテリジェント端末）であっても良い。

用語の「モジュール」、「システム」及び／または「インターフェイス」などは、本文において使用される時に、一般にコンピュータに関連する実体、または、ハードウェア、ハードウェアとソフトウェアの組み合わせ、ソフトウェア、または、実行中のソフトウェアを指す。ある例において、「モジュール」は、プロセッサ、機能ブロックなどとして配置されたハードウェアユニットであってもよい。これは、ハードウェアとして、専用集積回路、または、一つまたは複数の半導体で構成されるほかのロジックデバイスを実現することを含むことができる。ハードウェアユニットは、材料、または、その中に採用される処理メカニズムによって限定されない。ハードウェアユニットは、以下のコンポーネントを含むことができる：集積回路またはシステムオンチップ、専用集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、複雑なプログラマブルロジックデバイス（ＣＰＬＤ）、及び、ケイ素またはほかのハードウェアデバイスにおけるほかの実現。別の例において、「モジュール」は、プロセッサにおいて実行されるプロセス、プロセッサ、対象、実行可能なファイル、実行のスレッド、プログラム、及び／または、コンピュータであってもよいが、これに限定されない。例を挙げて言えば、コントローラーにおいて実行されるアプリケーションもコントローラーもモジュールであってもよい。一つまたは複数のモジュールは、実行中のプロセス及び／またはスレッドにおいて存在し、かつ、モジュールは、一つのコンピュータに限定され、及び/または二つ以上のコンピュータの間に分布することができる。

また、保護請求する主題は、標準的なプログラミング及び／またはエンジニアリング技術を使用して、ソフトウェア、ファームウェア、ハードウェアまたはこれらの任意の組み合わせを生成することにより、開示された主題を実現するようにコンピュータを制御する方法、装置または製造品に実現されてもよい。本文において使用される場合、用語の「製造品」は、任意のコンピュータの可読デバイス、キャリアまたは媒体からアクセス可能なコンピュータプログラムをカバーする。

さらに、本文には、実施例の様々な動作が提供されている。一実施例において、記載された動作のうちの１つまたは複数は、一つまたは複数のコンピュータ読み取り可能な媒体に記憶されたコンピュータ読み取り可能な指令を構成してもよい。前記コンピュータ読み取り可能な指令は、計算デバイスによって実行される場合において、計算デバイスに前記動作を実行させる。いくつかまたは全部の動作を記載する順序は、これらの動作が必然的に順序に依存することを指すように解釈されるべきではない。本説明のおかげで、当業者は取替可能な順序を意識することができる。さらに、すべての動作が、本文に提供される各実施例において必然的に存在するわけではないことが理解すべきである。

「コンピュータ読み取り可能な媒体」とは、情報の持続的な記憶を可能にする非一時の媒体及び／またはデバイス、及び／または、単なる信号伝送、搬送波または信号自体が対比になる有形の記憶装置をいう。よって、コンピュータ読み取り可能な媒体は、非信号伝送媒体を指す。コンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュール、ロジック素子／回路またはほかのデータなどの情報を記憶するのに適した方法または技術で実現される揮発性および不揮発性、取り外し可能な、及び、取り外し不可能な媒体及び／または記憶デバイスなどのようなハードウェアを含む。コンピュータ読み取り可能な媒体の例は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたはほかのメモリ技術、ＣＤ－ＲＯＭ、デジタル多機能ディスク（ＤＶＤ）またはほかの光学記憶装置、ハードディスク、カセット、磁気ディスク記憶装置またはほかの磁気記憶装置、または、所望の情報の記憶に適し、かつ、コンピュータによってアクセス可能なほかの記憶装置、有形の媒体または製造品を含むことができるが、これらに限定されない。

上記のいかなる実施例の検討は単なる例示であり、本開示の範囲（特許請求の範囲を含む）がこれらの例に限定されることを意味するものではないことを、当業者は理解すべきである。本開示の思想では、上記実施例または異なる実施例における技術的特徴の間の組み合わせも可能であり、ステップは、任意の適当な順序で実現されてもよい。また、上記の本開示の異なる方面の多くのほかの変化が存在する。簡明にするために、それらが詳細に提供されていない。このため、本開示の精神及び原則に基づき行った全ての省略、修正、同一取替、改善などは、本開示の保護範囲に含まれるべきである。

302 購読サービス実体
801 確認モジュール
802 取得モジュール
803 送信モジュール
804 作成モジュール
805 受信モジュール
901 購読請求モジュール
902 通知メッセージ処理モジュール

Claims (33)

1. 第１実体からの請求の請求情報が該第１実体に関連する購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報と確認することと、
   前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することと、
   第１情報と第２情報を含む通知メッセージを前記購読リソースの被通知側に送信することと、を含むことを特徴とする情報購読のための方法。
2. 前記購読リソースが前記イベント通知規則、前記関連対象、及び、前記被通知側の通知アドレスの標識符号を含むことを特徴とする請求項１に記載の方法。
3. 前記購読リソースが前記イベント通知規則と前記被通知側の通知アドレスの標識符号を含み、
   前記関連対象が前記第１実体のリソースの容器において作成された関連対象であることを特徴とする請求項１に記載の方法。
4. 前記関連対象は、関連リソース、または、関連リソースの標識を含み、
   前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することは、
   前記関連リソースから前記イベントの第２情報を取得すること、または、
   前記関連リソースの標識に基づき、対応した関連リソースから前記イベントの第２情報を取得すること、を含むことを特徴とする請求項１～３のいずれか一項に記載の方法。
5. 前記判定の前に、前記購読リソースの請求側からの第１実体に対する購読請求を受信することをさらに含み、
   前記購読請求に、前記イベント通知規則、関連リソースの標識、及び、前記被通知側の通知アドレスの標識符号を含み、
   受信した購読請求に基づき、第１実体に対する前記購読リソースを作成することを特徴とする請求項４に記載の方法。
6. 前記購読リソースに通知内容のタイプをさらに含み、かつ、前記通知内容のタイプの選択可能な値が関連リソースのタイプの値を含むことを特徴とする請求項４または５に記載の方法。
7. 前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することは、
   前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得することを含むことを特徴とする請求項６に記載の方法。
8. 第１実体が応用実体または汎用サービス実体であることを特徴とする請求項１～７のいずれか一項に記載の方法。
9. 前記請求が、内容実例を作成する請求または内容実例を更新する請求を含むことを特徴とする請求項１～８のいずれか一項に記載の方法。
10. 第１実体によって送信される内容実例を作成する請求に基づき、第１実体のリソースに用いられる容器において新しい内容実例を作成し、かつ、受信した情報を前記新しい内容実例において記憶することをさらに含むことを特徴とする請求項９に記載の方法。
11. 関連リソースは、実体のリソース、容器または内容実例を含み、
    前記実体が応用実体または汎用サービス実体を含むことを特徴とする請求項４に記載の方法。
12. 関連リソースは、第１実体と異なる第２実体のリソースであり、
    前記購読リソースの関連対象に基づき前記イベントの前記第２情報を取得することの前に、
    第２実体によって送信される前記イベントの第２情報を携帯する内容実例を作成する請求を受信することと、
    第２実体によって送信される内容実例を作成する請求に基づき、第２実体のリソースの容器において新しい内容実例を作成し、かつ、前記イベントの第２情報を前記新しい内容実例において記憶することをさらに含むことを特徴とする請求項４に記載の方法。
13. 前記イベントの第１情報がイベントの中核的情報であり、前記イベントの第２情報がイベントの補助情報であることを特徴とする請求項１２に記載の方法。
14. 前記イベントの中核的情報が交通事故の発生情報であり、前記イベントの補助情報が事故車両の位置情報であり、
    第１実体が交通事故の識別応用実体であり、第２実体が車両位置のセンシング応用実体であることを特徴とする請求項１３に記載の方法。
15. 第１実体からの請求の請求情報が第１実体に関連する購読リソースにおけるイベント通知規則を満足すると判定した後、前記請求の内容情報をイベントの第１情報と確認するための確認モジュールと、
    前記購読リソースの関連対象に基づき前記イベントの第２情報を取得するための取得モジュールと、
    第１情報と第２情報を含む通知メッセージを前記購読リソースの被通知側に送信するための送信モジュールとを含むことを特徴とする購読サーバ。
16. 前記購読リソースが前記イベント通知規則、前記関連対象、及び、前記被通知側の通知アドレスの標識符号を含むことを特徴とする請求項１５に記載の購読サーバ。
17. 前記購読リソースの請求側からの第１実体に対する購読請求を受信した後、前記購読請求に基づき第１実体の前記購読リソースを作成するための作成モジュールをさらに含み、
    前記購読請求が前記イベント通知規則、関連リソースの標識、及び、前記被通知側の通知アドレスの標識符号を含み、前記関連リソースの標識が、前記関連対象を作成するためのものであることを特徴とする請求項１６に記載の購読サーバ。
18. 前記購読リソースが前記イベント通知規則と前記被通知側の通知アドレスの標識符号を含み、前記関連対象が、前記第１実体のリソースの容器において設置された関連対象であることを特徴とする請求項１５に記載の購読サーバ。
19. 前記購読リソースの請求側からの第１実体に対する購読請求を受信した後、前記購読請求に基づき第１実体の前記購読リソースを作成するための作成モジュールをさらに含み、
    前記購読請求が、前記イベント通知規則及び前記被通知側の通知アドレスの標識符号を含むことを特徴とする請求項１８に記載の購読サーバ。
20. 前記購読リソースが通知内容のタイプをさらに含み、かつ、前記通知内容のタイプの選択可能な値が関連リソースのタイプの値を含むことを特徴とする請求項１７に記載の購読サーバ。
21. 前記取得モジュールは、前記通知内容のタイプが関連リソースのタイプの値であると確認した後、前記購読リソースの関連対象に基づき前記イベントの第２情報を取得するためのものであることを特徴とする請求項２０に記載の購読サーバ。
22. 前記請求が、内容実例を作成する請求を含み、
    前記購読サーバが、
    第１実体によって送信される内容実例を作成する請求を受信するための受信モジュールと、
    前記の内容実例を作成する請求に基づき第１実体のリソースの容器において新しい内容実例を作成し、かつ、受信した情報を前記新しい内容実例において記憶するための作成モジュールをさらに含むことを特徴とする請求項１５または１６に記載の購読サーバ。
23. 関連リソースは、実体のリソース、容器または内容実例であり、
    前記実体が応用実体または汎用サービス実体を含むことを特徴とする請求項１７に記載の購読サーバ。
24. 関連リソースが、前記第１実体と異なる第２実体のリソースであり、
    前記受信モジュールがさらに、第２実体によって送信される前記イベントの第２情報を携帯する内容実例を作成する請求を受信するためのものであり、かつ、前記作成モジュールがさらに、第２実体によって送信される内容実例を作成する請求に基づき、第２実体のリソースの容器において新しい内容実例を作成し、かつ、前記イベントの第２情報を前記新しい内容実例において記憶するためのものであることを特徴とする請求項２２に記載の購読サーバ。
25. 前記イベントの第１情報がイベントの中核的情報であり、前記イベントの第２情報がイベントの補助情報であることを特徴とする請求項１５～２４のいずれか一項に記載の購読サーバ。
26. 第１実体に対する購読請求を購読サーバに送信することにより、第１実体に関連する購読リソースを作成するための購読請求モジュールと、
    前記購読サーバによって送信される通知メッセージを受信かつ処理するための通知メッセージの処理モジュールを備え、
    前記購読請求が、イベント通知規則及び前記購読リソースの被通知側の通知アドレスの標識符号を含み、前記通知メッセージが、第１実体によって送信される請求の内容情報に基づき確認したイベントの第１情報と、前記購読リソースの関連対象に基づき取得した前記イベントの第２情報とを含むことを特徴とする購読端末。
27. 前記購読請求に、前記購読リソースにおける関連対象を作成するための関連リソースの標識をさらに含むことを特徴とする請求項２６に記載の購読端末。
28. 前記購読請求は通知内容のタイプをさらに含み、かつ、該通知内容のタイプが関連リソースのタイプの値として設置されることを特徴とする請求項２７に記載の購読端末。
29. 請求を送信するための第１実体と、
    請求項１５～２５のいずれか一項に記載の購読サーバと、
    前記購読リソースの被通知側として、前記通知メッセージを受信かつ処理するための購読端末と、を含むことを特徴とする情報購読システム。
30. 第一実体が応用実体または汎用サービス実体であることを特徴とする請求項２９に記載のシステム。
31. 請求を送信するための第１実体と、
    請求項１５～２５のいずれか一項に記載の購読サーバと、
    前記購読リソースの被通知側として、前記通知メッセージを受信かつ処理するための請求項２６～２８のいずれか一項に記載の購読端末を含むことを特徴とする情報購読システム。
32. 計算デバイスの実行時に前記計算デバイスに請求項１～１４のいずれか一項に記載の方法を実行させるコンピュータ読み取り可能な指令が記憶されていることを特徴とするコンピュータ読み取り可能な媒体。
33. 一つまたは複数のプロセッサと、
    前記一つまたは複数のプロセッサの実行に応答して、前記一つまたは複数のプロセッサに請求項１～１４のいずれか一項に記載の方法を実行させる複数の指令が記憶されているコンピュータ読み取り可能な媒体と、を含むことを特徴とする計算デバイス。

Images