▶ 京東方科技集團股▲ふん▼有限公司の特許一覧 ▶ 北京京▲東▼方技▲術▼▲開▼▲発▼有限公司の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-31
(45)【発行日】2024-11-11
(54)【発明の名称】イベント通知方法、デバイス、装置及びコンピュータ記憶媒体
(51)【国際特許分類】
G06F 15/00 20060101AFI20241101BHJP
【ＦＩ】
G06F15/00 470
【請求項の数】
13
(21)【出願番号】P 2021530220
(86)(22)【出願日】2019-11-21
(65)【公表番号】
(43)【公表日】2022-01-31
(86)【国際出願番号】 CN2019119970
(87)【国際公開番号】W WO2020108379
(87)【国際公開日】2020-06-04
【審査請求日】2022-11-18
(31)【優先権主張番号】201811432991.5
(32)【優先日】2018-11-28
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】510280589
【氏名又は名称】京東方科技集團股▲ふん▼有限公司
【氏名又は名称原語表記】ＢＯＥ ＴＥＣＨＮＯＬＯＧＹ ＧＲＯＵＰ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｎｏ．１０ Ｊｉｕｘｉａｎｑｉａｏ Ｒｄ．，Ｃｈａｏｙａｎｇ Ｄｉｓｔｒｉｃｔ，Ｂｅｉｊｉｎｇ １０００１５，ＣＨＩＮＡ
(73)【特許権者】
【識別番号】519385216
【氏名又は名称】北京京▲東▼方技▲術▼▲開▼▲発▼有限公司
【氏名又は名称原語表記】ＢＥＩＪＩＮＧ ＢＯＥ ＴＥＣＨＮＯＬＯＧＹ ＤＥＶＥＬＯＰＭＥＮＴ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｒｏｏｍ ４０７，Ｂｕｉｌｄｉｎｇ １，Ｎｏ．９ Ｄｉｚｅ Ｒｏａｄ，ＢＤＡ，Ｂｅｉｊｉｎｇ，１００１７６，ＣＨＩＮＡ
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(72)【発明者】
【氏名】▲趙▼ 君杰
(72)【発明者】
【氏名】▲蘇▼ 京
(72)【発明者】
【氏名】▲張▼ 乾
【審査官】坂東 博司
(56)【参考文献】
【文献】特表２０１８－５２６７０３（ＪＰ，Ａ）
【文献】特開２００６－０９２２５４（ＪＰ，Ａ）
【文献】国際公開第２０１７／０８７３６７（ＷＯ，Ａ１）
【文献】米国特許出願公開第２０１８／０１６７７８５（ＵＳ，Ａ１）
【文献】特表２０１８－５３５６０５（ＪＰ，Ａ）
【文献】特開２０１３－０３７４１４（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／０００７１３８（ＵＳ，Ａ１）
【文献】中国特許出願公開第１０７６６６４３２（ＣＮ，Ａ）
【文献】米国特許出願公開第２０１０／０１６９３４４（ＵＳ，Ａ１）
【文献】米国特許出願公開第２０１５／００６７１５４（ＵＳ，Ａ１）
【文献】中国特許出願公開第１０７９６８８０５（ＣＮ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １５／００
(57)【特許請求の範囲】
【請求項1】
イベント通知方法であって、
サブスクライバからのイベントサブスクリプション要求を受信することであって、前記イベントサブスクリプション要求に１つ以上の通知者が含まれることと、
前記１つ以上の通知者を１つ以上のグループに分けることであって、各グループに１つ以上の通知者が含まれることと、
イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを用いて、イベント通知が発生したか否かを確定し、前記イベント通知ルールを満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することと、を含み、
前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、
前記イベント通知を送信した後、再通知基準を満たすか否かを確定し、前記再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信し、前記１つ以上のグループが、前記イベントサブスクリプション要求に含まれている前記１つ以上の通知者をグループ化することによって取得され、
前記イベント通知ルールを満たす場合に、イベント通知が送信されるグループは、初期通知グループとして表され、前記再通知基準を満たす場合に、イベント通知が送信されるグループは、再通知グループとして表され、前記初期通知グループと前記再通知グループが異なることをさらに含み、
前記イベント通知方法は、
送信通知間隔及び検証イベント通知間隔をチェックして、どれの間隔が大きいかを確定し、さらに、前記チェックに基づいて、前記再通知基準を満たすか否かを確定して、
前記送信通知間隔が前記検証イベント通知間隔よりも大きい場合、前記再通知基準を満たすか否かを確定する基準は、
前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定し、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することと、
前記検証イベント通知間隔が前記送信通知間隔よりも大きい場合、前記再通知基準を満たすと確定する基準は、
前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定することを含み、前記イベント通知方法は、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者に前記イベント通知を送信することをさらに含む
イベント通知方法。
【請求項2】
前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む、
請求項１に記載のイベント通知方法。
【請求項3】
前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む、
請求項１に記載のイベント通知方法。
【請求項4】
前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、前記再通知基準を満たすと確定することを含む、
請求項１に記載のイベント通知方法。
【請求項5】
通知者にイベント通知を送信するか否かを確定するためのイベント通知ルール属性と、前記１つ以上のグループに基づいて前記１つ以上の通知者のアドレス情報を記憶するためのイベント通知リスト属性と、
イベント通知ルールを満たすか否かを確定する時間間隔を設定するための検証イベント通知間隔属性と、
前記検証イベント通知間隔属性を有効化するか否かを設定するための検証イベント通知有効属性と、
イベント通知を送信する時間間隔を設定するための送信通知間隔属性とのうちの少なくとも１つの属性を定義することをさらに含む、
請求項１に記載のイベント通知方法。
【請求項6】
アプリケーションエンティティからの更新データを受信するように要求するために前記イベントサブスクリプション要求が使用され、前記イベント通知方法は、
前記更新データに基づいてイベント通知ルールを満たすか否かを確定することをさらに含む、
請求項１に記載のイベント通知方法。
【請求項7】
前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、前記１つ以上のグループの順番に基づいて、イベント通知を送信すべき前記少なくとも１つのグループを確定することをさらに含む、
請求項１に記載のイベント通知方法。
【請求項8】
前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを満たす場合、再通知基準を満たすか否かを確定することと、
前記再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することとを含む、
請求項１に記載のイベント通知方法。
【請求項9】
前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む、
請求項８に記載のイベント通知方法。
【請求項10】
前記イベントサブスクリプション要求は、単一リソースサブスクリプション要求及びクロスリソースサブスクリプション要求のうちの少なくとも１つである、請求項１に記載のイベント通知方法。
【請求項11】
サーバーデバイスであって、送受信機と、プロセッサとを備え、
前記送受信機は、サブスクライバからの、１つ以上の通知者が含まれるイベントサブスクリプション要求を受信するように構成され、
前記プロセッサは、前記１つ以上の通知者をそれぞれ１つ以上の通知者が含まれる１つ以上のグループに分け、及び、イベント通知ルールを満たすか否かを確定し、前記イベント通知ルールを用いて、イベント通知が発生したか否かを確定し、前記イベント通知ルールを満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示するように構成され、
前記イベント通知を送信した後、前記プロセッサは、再通知基準を満たすか否かを確定し、前記再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示し、前記１つ以上のグループが、前記イベントサブスクリプション要求に含まれている前記１つ以上の通知者をグループ化することによって取得され、
前記イベント通知ルールを満たす場合に、イベント通知が送信されるグループは、初期通知グループとして表され、前記再通知基準を満たす場合に、イベント通知が送信されるグループは、再通知グループとして表され、前記初期通知グループと前記再通知グループが異なるように構成され、
前記プロセッサは、
送信通知間隔及び検証イベント通知間隔をチェックして、どれの間隔が大きいかを確定し、さらに、前記チェックに基づいて、前記再通知基準を満たすか否かを確定して、
前記送信通知間隔が前記検証イベント通知間隔よりも大きい場合、前記再通知基準を満たすか否かを確定する基準は、
前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定し、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することと、
前記検証イベント通知間隔が前記送信通知間隔よりも大きい場合、前記再通知基準を満たすと確定する基準は、
前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定することを含み、前記プロセッサは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者に前記イベント通知を送信することをさらに含むように構成される
サーバーデバイス。
【請求項12】
イベント通知装置であって、１つ以上のプロセッサと、
コンピュータ読み取り可能なコードが記憶される１つ以上のメモリと、を備え、
前記コンピュータ読み取り可能なコードが前記１つ以上のプロセッサによって実行されると、請求項１から１０のいずれか一項に記載のイベント通知方法が行われる、
イベント通知装置。
【請求項13】
コンピュータ読み取り可能なコードを記憶しているコンピュータ記憶媒体であって、前記コンピュータ読み取り可能なコードが１つまたは複数のプロセッサによって実行されると、請求項１から１０のいずれか一項に記載のイベント通知方法が行われる、
コンピュータ記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、モノのインターネット分野に関し、具体的に、イベント通知方法、デバイス、装置及びコンピュータ記憶媒体に関する。
【背景技術】
【0002】
情報技術、特にインターネット技術の発展に伴い、情報化、遠隔管理制御、インテリジェント化を実現するためのモノのインターネット技術が成熟してきている。モノのインターネットワークは、ローカルネットワークやインターネットなどの通信技術を利用して、センサ、コントローラ、機械、人、物などを新しい方式で接続し、人と物、物と物の間の接続を形成する。モノのインターネット技術が各応用分野で急速に発展するにつれて、ますます多くのデバイスがモノのインターネットに接続し、スマートホーム、スマート交通、スマート健康などといった様々な新しい応用分野が出現している。モノのインターネットプラットフォームに接続されたデバイス端末は、サブスクリプション要求をモノのインターネットプラットフォームに送信することによって、それに関連するデータにサブスクライブすることができ、モノのインターネットプラットフォームは、サブスクリプション条件が満たされたときに、サブスクリプション要求に係る通知者にイベント通知を送信する。
【発明の概要】
【0003】
本開示の一態様によれば、サブスクライバからのイベントサブスクリプション要求を受信することであって、前記イベントサブスクリプション要求に１つ以上の通知者が含まれる、ことと、前記１つ以上の通知者を１つ以上のグループに分けることであって、各グループに１つ以上の通知者が含まれる、ことと、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することとを含むイベント通知方法が提供されている。
【0004】
本開示の実施例によれば、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを含む。
【0005】
本開示の実施例によれば、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、イベント通知を送信した後、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することをさらに含む。
【0006】
本開示の実施例によれば、前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0007】
本開示の実施例によれば、前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0008】
本開示の実施例によれば、前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、前記再通知基準を満たすと確定することを含む。
【0009】
本開示の実施例によれば、送信通知間隔及び検証イベント通知間隔を設定することであって、前記送信通知間隔が前記検証イベント通知間隔よりも大きい、ことをさらに含み、前記再通知基準を満たすか否かを確定することは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定し、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを含む。
【0010】
本開示の実施例によれば、送信通知間隔及び検証イベント通知間隔を設定することであって、前記送信通知間隔が前記検証イベント通知間隔よりも小さい、ことをさらに含み、前記再通知基準を満たすか否かを確定することは、前記送信通知間隔により確定された時点で、再通知基準を満たすと確定することを含む。
【0011】
本開示の実施例によれば、前記イベント通知方法は、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者に前記イベント通知を送信することをさらに含む。
【0012】
本開示の実施例によれば、通知者にイベント通知を送信するか否かを確定するためのイベント通知ルール属性と、前記１つ以上のグループに基づいて前記１つ以上の通知者のアドレス情報を記憶するためのイベント通知リスト属性とのうちの少なくとも１つの属性を定義することを含む。
【0013】
本開示の実施例によれば、前記イベント通知方法は、イベント通知ルールを満たすか否かを確定する時間間隔を設定するための検証イベント通知間隔属性を定義することをさらに含む。
【0014】
本開示の実施例によれば、前記イベント通知方法は、イベント通知を送信する時間間隔を設定するための送信通知間隔属性を定義することをさらに含む。
【0015】
本開示の実施例によれば、前記イベント通知方法は、前記検証イベント通知間隔属性を有効化するか否かを設定するための検証イベント通知有効属性を定義することをさらに含む。
【0016】
本開示の実施例によれば、アプリケーションエンティティからの更新データを受信するように要求するために前記イベントサブスクリプション要求が使用される。
【0017】
本開示の実施例によれば、前記イベント通知方法は、前記更新データに基づいてイベント通知ルールを満たすか否かを確定することをさらに含む。
【0018】
本開示の実施例によれば、イベント通知ルールを満たす場合にイベント通知を送信されるグループは、初期通知グループとして表され、再通知基準を満たす場合にイベント通知を送信されるグループは、再通知グループとして表され、前記初期通知グループと前記再通知グループが異なる。
【0019】
本開示の実施例によれば、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、前記１つ以上のグループの順番に基づいて、イベント通知を送信すべき前記少なくとも１つのグループを確定することをさらに含む。
【0020】
本開示の実施例によれば、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、再通知基準を満たすか否かを確定することと、再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することとを含む。
【0021】
本開示の実施例によれば、前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0022】
本開示の実施例によれば、前記イベントサブスクリプション要求は、単一リソースサブスクリプション要求及びクロスリソースサブスクリプション要求のうちの少なくとも１つである。
【0023】
本開示の別の態様によれば、送受信機と、プロセッサとを備えるサーバーデバイスであって、前記送受信機は、サブスクライバからの、１つ以上の通知者が含まれるイベントサブスクリプション要求を受信するように構成され、前記プロセッサは、前記１つ以上の通知者をそれぞれ１つ以上の通知者が含まれる１つ以上のグループに分け、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示するように構成される、サーバーデバイスが提供されている。
【0024】
本開示の実施例によれば、前記プロセッサは、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示するようにさらに構成される。本開示の実施例によれば、前記プロセッサは、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示した後、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを前記送受信機に指示するようにさらに構成され、イベント通知ルールを満たす場合にイベント通知を送信されるグループは、初期通知グループとして表され、再通知基準を満たす場合にイベント通知を送信されるグループは、再通知グループとして表され、前記初期通知グループと前記再通知グループが異なる。
【0025】
本開示の別の態様によれば、１つ以上のプロセッサと、コンピュータ読み取り可能なコードが記憶される１つ以上のメモリと、を備えるイベント通知装置であって、前記コンピュータ読み取り可能なコードは、前記１つ以上のプロセッサによって実行されると、上述したようなイベント通知方法が行われる、イベント通知装置が提供されている。
【0026】
本開示の別の態様によれば、コンピュータ読み取り可能なコードを記憶しているコンピュータ記憶媒体であって、前記コンピュータ読み取り可能なコードが１つまたは複数のプロセッサによって実行されると、上述したようなイベント通知方法が行われる、コンピュータ記憶媒体が提供されている。
【0027】
本開示の実施例又は従来技術の技術的解決策をより明確に説明するために、以下、実施例又は従来技術の説明で必要とされる図面について簡単に説明するが、以下の説明における図面は、本開示の実施例の一部にすぎず、当業者にとって、創造的な労力を課すことなく、これらの図面に基づいて他の図面を取得することができることは明らかである。
【図面の簡単な説明】
【0028】
【図1】本開示の実施例によるイベント通知方法のフローチャートである。
【図2】本開示の一実施例によるイベント通知の送信のフローチャートである。
【図3A】本開示の実施例による、検証イベント通知間隔よりも大きいように送信通知間隔を設定する模式図である。
【図3B】本開示の実施例による、検証イベント通知間隔よりも小さいように送信通知間隔を設定する模式図である。
【図4A】本開示の一実施例による、イベント通知方法を実施するためのサブスクリプションリソース構成の模式図である。
【図6A】本開示の別の実施例による、イベント通知方法を実施するためのサブスクリプションリソース構成の模式図である。
【図8A】本開示の別の実施例による、イベント通知方法を実施するためのサブスクリプションリソース構成の模式図である。
【図10A】本開示の実施例による、第４のグループ内の１つの通知者へのイベント通知の送信のフローチャートである。
【図10B】本開示の実施例による、第５のグループ内の複数の通知者へのイベント通知の送信のフローチャートである。
【図11】本開示の実施例による、イベント通知方法においてクロスリソースサブスクリプションのフローチャートである。
【図12】本開示の実施例によるサーバーデバイスの模式図である。
【図13】本開示の実施例によるイベント通知装置の模式図である。
【発明を実施するための形態】
【0029】
以下、本開示の実施例における技術的解決策を、本開示の実施例における図面を参照しながら、明確かつ完全に説明する。当然ながら、記載された実施例は、本開示の一部の実施例にすぎず、すべての実施例ではない。本開示の実施例に基づいて、創造的な労力を要することなく当業者によって得られる他のすべての実施例は、本開示の保護範囲に属する。
【0030】
本開示で使用される「第１の」、「第２の」および類似語は、任意の順序、量、または重要性を意味せず、異なる構成要素を区別するために使用されるだけである。同様に、「含める」または「含む」などの類似語は、当該単語の前に出現する要素または物体が、当該単語の後に出現する要素または物体およびその同等物を包含し、他の要素または物体を除外しないことを意味する。「結合される」または「接続される」などの用語は、物理的または機械的接続に限定されず、直接的または間接的を問わず、電気的接続を含むことができる。
【0031】
本開示では、フローチャートを用いて、本開示の実施例による方法のステップを説明する。なお、前後のステップは必ずしも順番に正確に実行されなくてもよい。逆に、様々なステップは、逆の順序で又は同時に処理されてもよい。また、これらの手順に他の操作を追加したり、何らかのステップを削除したりすることも可能である。
【0032】
モノのインターネットは、インターネットの拡張として、インターネット及びインターネット上の全てのリソースを含み、インターネットの全てのアプリケーションをサポートする。モノのインターネット技術が様々な分野で適用されるにつれて、スマートホーム、スマート交通、スマート健康などといった新しい適用分野が各種出現している。
【0033】
モノのインターネット技術の発展に伴い、煙警報器、火災警報器、マンホールカバー移動センサ等、ますます多い端末デバイスがモノのインターネットプラットフォームに接続する。このモノのインターネットプラットフォームは、例えば、汎用サービスエンティティとして具現化されてもよく、端末デバイスが汎用サービスエンティティに登録情報を送信することによって、汎用サービスエンティティに接続されてもよく、汎用サービスエンティティがこれにアクセスする端末デバイスを管理する。端末デバイスは、アプリケーションエンティティとして表され、汎用サービスエンティティにアクセスするアプリケーションエンティティがこの汎用サービスエンティティとデータ伝送および情報交換などの動作を行うことができる。なお、本文で述べるアプリケーションエンティティは、モノのインターネットの端末デバイスであってもよいし、デバイス内のソフトウェアモジュール等であってもよい。
【0034】
いくつかのアプリケーションエンティティ（例えば、サブスクライバとして）は、汎用サービスエンティティにサブスクリプション要求を送信することによって、例えば、他のアプリケーションエンティティ（例えば、被サブスクライバとして）からの情報、データ等をサブスクライブすることができ、前記サブスクライバは、例えば、汎用サービスエンティティからのデータ、動作等を要求することができ、ここに制限はない。前記サブスクリプション要求には、それに関連するイベント通知を受信するための複数の通知者を含み得る。前記サブスクリプション要求には、イベント通知ルールがさらに含まれてもよく、すなわち、該イベント通知ルールを満たす（例えば、煙警報がトリガされる）場合、前記サブスクリプション要求に含まれる通知者にイベント通知を送信し、前記イベント通知ルールは、サブスクリプション条件と呼ばれてもよい。これにより、イベント通知ルールを満たす場合に、汎用サービスエンティティは、サブスクリプション要求に含まれるすべての通知者にイベント通知を送信する。例えば、マンホールカバーが移動された時、マンホールカバー移動センサはこの変化を感知し、更新データを汎用サービスエンティティに送信し、汎用サービスエンティティはこのマンホールカバー移動センサの更新データに基づいてイベント通知ルールを満たすか否かを確定することができ、例えば、サブスクリプション条件がマンホールカバーの移動である場合、この時、汎用サービスエンティティは、前記イベント通知ルールを満たすと確定し、マンホールカバー移動のイベント通知のサブスクリプションを要求するサブスクリプション要求に含まれる全ての通知者にイベント通知を送信し、即ち、マンホールカバーが移動されたイベントを全ての通知者に通知する。
【0035】
既存のサブスクリプション要求通知ルールでは、前記サブスクリプション条件を満たすと、汎用サービスエンティティはイベント通知を全ての通知者に送信する。しかし、いくつかのシナリオでは、すべての通知者は、同時にイベント通知を受信することを望むわけではない。例えば、通知者に、上述のマンホールカバーの移動のサブスクリプション要求において、例えば、街路のマンホールカバー管理センタ、エリアのマンホールカバー管理センタ、区のマンホールカバー管理センタ、及び市のマンホールカバー管理センタ等の異なるレベルの市町村管理部が含まれていることがある。これらの異なるレベルのマンホールカバー管理センタは、マンホールカバーの移動に関するイベント通知を受信したがっているが、一方では、全てのイベント通知を同時に受信したがっていない。例えば、下位の管理センタである通知者は、イベント通知を受信した後、そのマンホールカバー移動のイベントをタイムリー処理するものであってもよいし、上位の管理センタである通知者は、そのマンホールカバー移動のイベントの処理を監視管理するものであってもよい。このとき、上位の管理センタは、下位の管理センタがマンホールカバー移動のイベントの処理をタイムリー処理しない場合のみ、このイベント通知を受けるという要望があり、従来技術のイベント通知ルールでは、このような場合のアプリケーションの要求に応えることはできない。また、すべての被通知者にイベント通知を同時に送信すると、通知者への情報干渉が発生し、リソースの無駄となる。
【0036】
本開示は、サブスクリプション要求における通知者を管理し、イベント通知の正確な送信を実現し、通知効率を向上させ、通知者への情報干渉を回避するイベント通知方法を提案する。
【0037】
図１は、本開示の実施例におけるイベント通知方法のフローチャートを示し、まず、ステップＳ１０１において、サブスクライバからのイベントサブスクリプション要求を受信し、ここで、前記イベントサブスクリプション要求に１つ以上の通知者が含まれる。前記サブスクライバは、汎用サービスエンティティに接続されたアプリケーションエンティティであってよく、例えば、動作するために何らかのデータが必要とされる場合、サブスクリプション要求をサービスエンティティに送信することができ、サブスクリプション要求には、サブスクリブするイベントまたは動作、および該イベント通知を受信するための１つ以上の通知者を含み得る。なお、前記サブスクライバは、１つまたは複数であってもよく、すなわち、複数のサブスクライバが汎用サービスエンティティにイベントサブスクリプション要求を送信してイベント通知をサブスクライブしても良い。
【0038】
次に、ステップＳ１０２では、１つ以上の通知者を１つ以上のグループに分け、ここで、各グループに１つ以上の通知者を含める。本開示の実施例によれば、前記イベントサブスクリプション要求に複数の通知者が含まれる場合、汎用サービスエンティティは、サブスクリプション要求を受信した後、全ての通知者のリスト情報を取得し、イベント通知をより正確に送信するために、通知者のタイプ、レベル、イベント通知の内容などに基づいて前記複数の通知者をグループ化することができる。本開示の別の実施例によれば、前記汎用サービスエンティティは、また、サブスクライバの指示に基づいて複数の通知者をグループ化することができる。あるいは、汎用サービスエンティティは、イベント通知効率を高めるのにより有利な他の方法に基づいて通知者をグループ化することもできる。なお、本開示は、グループ化の方法を限定しない。前記イベントサブスクリプション要求に１つの通知者が含まれる場合については、実施例を参照して詳細に説明する。
【0039】
本開示の実施例によれば、前記汎用サービスエンティティは、通知者リスト内で前記複数のグループを区別することができる。例えば、前記複数のグループを第１のグループ、第２のグループ、第３のグループ等に区分し、イベント通知を行う際に現在通知が必要なグループを確定し、確定したグループ内の通知者にイベント通知を行うようにしてもよい。本開示の実施例によれば、イベント通知を送信する前記少なくとも１つのグループは、前記複数のグループの順番に基づいて確定され得る。以下、第１のグループ、第２のグループ、第３のグループというように、異なるグループを表すことができる。なお、ここでの第１、第２は、単に異なるグループを区別するためのものであり、前記グループに対するイベント通知の順番を意味するものではない。つまり、イベント通知を行う際に、前記汎用サービスエンティティは、まずイベント通知を第１のグループの通知者に送信することを確定してもよいし、第２のグループまたは他のグループ、例えば第３のグループの通知者に送信することを確定してもよい。また、本開示の実施例によれば、前記異なるグループに含まれる通知者は、同一でなくてもよいし、同じでもよく、即ち、１つの通知者が第１のグループに含まれていてもよいし、第２のグループに含まれていてもよいし、ここに、限定されない。
【0040】
次に、ステップＳ１０３において、前記１つ以上のグループのうち少なくとも１つのグループ内の通知者にイベント通知を送信する。本開示の実施例によれば、前記汎用サービスエンティティは、まず、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、イベント通知を少なくとも１つのグループ内の通知者に送信することができる。
【0041】
図２は、本開示の一実施例によるイベント通知を送信するためのフローチャートを示す。本開示の実施例によれば、１つ以上のグループのうちの少なくとも１つのグループの通知者にイベント通知を送信することは、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するステップＳ２０１を含んでもよい。前記イベント通知ルールは、サブスクリプション要求を送信するサブスクライバによって確定されてもよい。汎用サービスエンティティは、サブスクリプション要求に基づいて、イベント通知ルール属性を作成して該イベント通知ルールを設定することができ、イベント通知ルール属性を作成することで、前記１つ以上のグループに基づいて前記複数のサブスクライバのアドレス情報を記憶する。
【0042】
例えば、本開示による一例では、前記イベントサブスクリプション要求は、アプリケーションエンティティ１からの更新データの通知の受信を要求し、通知を受信するイベント通知ルールを設定するために使用されてもよく、当該イベント通知ルールとして、例えば、更新データは第１の閾値よりも大きい。汎用サービスエンティティは、該サブスクリプション要求を受信した後、該サブスクリプション要求に対応するイベント通知ルール属性およびイベント通知リスト属性を生成することができる。汎用サービスエンティティは、アプリケーションエンティティ１からの更新データを受信した後、前記更新データがイベント通知ルールを満たす否かを判断し、イベント通知ルールを満たす場合（すなわち、更新データが第１閾値より大きい場合）、該更新データまたは該更新データに関する更新情報を、イベント通知リスト属性に格納された、前記１つ以上のグループのうちの少なくとも１つのグループにおける通知者に送信する。
【0043】
本開示の実施例によれば、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、イベント通知を送信した後、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するステップＳ２０２を、さらに含んでもよい。本開示の実施例によれば、イベント通知ルールを満たす場合にイベント通知を送信する（ステップＳ２０１）グループを初期通知グループとして表し、再通知基準を満たす場合にイベント通知を送信する（ステップＳ２０２）グループを再通知グループとして表し、前記初期通知グループが前記再通知グループと異なる。本開示の別の実施例によって、前記初期通知グループと再通知グループとが同じであっても良いし、一部が同じであっても良い。
【0044】
例えば、上記の更新データのサブスクリプション要求を受信する例において、前記汎用サービスエンティティは、アプリケーションエンティティ１の更新データを受信した後、該更新データがイベント通知ルールを満たすと確定し、初期通知グループ（例えば、第１のグループ）内の通知者にイベント通知を送信する。イベント通知を送信した後、前記汎用サービスエンティティは、再通知基準を満たすか否かをさらに判断し、再通知基準を満たす場合、再通知グループ（例えば、第２のグループ）内の通知者にイベント通知を送信する。
【0045】
本開示の実施例によれば、前記ステップＳ２０２において、再通知基準を満たすか否かを確定する前に、イベント通知を送信していない通知者があるか否かを確定し、イベント通知を送信していない通知者がある場合に再通知基準を満たすか否かを判定することが含まれてもよい。
【0046】
以下、前記再通知基準を詳しく説明する。
【0047】
本開示の一実施例によれば、前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含んでもよい。例えば、汎用サービスエンティティは、検証イベント通知間隔属性を作成することで、イベント通知ルールを満たすか否かを確定する時間間隔を設定することができる。例えば、前記検証イベント通知間隔属性は、検証イベント通知間隔が４時間として確定され、即ち、汎用サービスエンティティは、イベント通知を送信した後（例えば、第１のグループ内の通知者にイベント通知を送信した後）、イベント通知ルールを満たすか否かの検証を４時間ごとに行う。この実施例において、検証イベント通知間隔により確定された時点でイベント通知ルールを満たすか否かを確定することは、再通知基準としても良い。イベント通知ルールを満たす場合、即ち、再通知基準を満たすと確定する場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者（例えば、第２のグループ内の通知者）にイベント通知を送信する。
【0048】
本開示の別の実施例によれば、前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含んでもよい。例えば、汎用サービスエンティティは、送信通知間隔属性を作成することで、イベント通知を送信する時間間隔を設定することができる。例えば、前記送信通知間隔属性は、送信通知間隔が５時間として確定され、即ち、汎用サービスエンティティは、イベント通知を送信した後（例えば、第１のグループ内の通知者にイベント通知を送信した後）、イベント通知ルールを満たすか否かの検証を５時間ごとに行い、イベント通知ルールを満たす場合にイベントを送信する。この実施例において、送信イベント通知間隔により確定された時点でイベント通知ルールを満たすか否かを確定することは、再通知基準としても良い。汎用サービスエンティティは、送信イベント通知間隔により確定された時点でイベント通知ルールを満たすと確定し、即ち再通知基準を満たすと認める場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者（例えば、第２のグループ内の通知者）にイベント通知を送信する。
【0049】
本開示の別の実施例によれば、送信通知間隔により確定された時点で、前記再通知基準を満たすと確定する。つまり、この実施例において、送信通知時間間隔により確定された時点に達することを、再通知基準を満たす条件とする。例えば、汎用サービスエンティティは、送信通知間隔属性を作成することで、イベント通知送信の時間間隔を設定することができる。例えば、前記送信通知間隔属性は、送信通知間隔を４時間として確定し、即ち、汎用サービスエンティティは、イベント通知を送信した後（例えば、第１のグループ内の通知者にイベント通知を送信した後）、イベント通知の送信操作（例えば、第２のグループ内の通知者に送信する）を４時間ごとにトリガする。即ち、汎用サービスエンティティは、送信イベント通知間隔により確定された時点で、再通知基準を満たすと確定する場合、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者（例えば、第２のグループ内の通知者）にイベント通知を送信する。
【0050】
本開示の別の実施例によれば、前記イベント通知方法は、送信通知間隔及び検証イベント通知間隔を設定することであって、前記送信通知間隔が前記検証イベント通知間隔よりも大きい、ことを含んでもよい。この実施例において、前記再通知基準を満たすか否かを確定することは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記再通知基準を満たすと確定し、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することを含んでもよい。
【0051】
図３Ａは本開示の実施例における検証イベント通知間隔よりも大きい送信通知間隔の設定の模式図である。以下、図３Ａを参照して、この実施例において、再通知基準を確定する手順を説明する。なお、図３Ａに示す具体的な実施例において、前記イベントサブスクリプション要求に複数の通知者が含まれ、前記複数の通知者を１つ以上のグループに分ける。
【0052】
例えば、汎用サービスエンティティは、送信通知間隔属性を作成することで、イベント通知を送信する時間間隔を設定することができる。例えば、前記送信通知間隔属性は、送信通知間隔が５時間として確定されても良い。なお、汎用サービスエンティティは、検証イベント通知間隔属性を作成することで、イベント通知を検証する時間間隔を設定することができる。例えば、前記検証イベント通知間隔属性は、検証通知間隔が４時間として確定されても良い。即ち、送信通知間隔が検証イベント通知間隔よりも大きいように設定する。
【0053】
図３Ａの横軸は時間軸を示し、例えば、汎用サービスエンティティがイベント通知を初期通知グループの通知者に送信する時点を時間軸の開始点として表すことができる。これにより、前記汎用サービスエンティティは、イベント通知ルールを満たすか否かを検証する時点として、該開始点から４時間ごとの時点を設定し、イベント通知を送信する時点として、該開始点から５時間ごとの時点を設定する。
【0054】
この実施例において、図３Ａに示すように、送信通知間隔が検証イベント通知間隔よりも大きいため、前記汎用サービスエンティティは、イベント通知を送信した後（即ち、時間軸の開始点）、まず、検証イベント通知時点に達し、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たさない場合、例えば、更新データが第１の閾値以下である場合、汎用サービスエンティティは、このイベント通知の操作を終了する。汎用サービスエンティティは、イベント通知ルールを満たすと確定する場合、例えば、更新データが第１の閾値より大きい場合、汎用サービスエンティティは、送信イベント通知を待ち、即ち、この検証イベント通知時点（例えば、４時間）でイベント通知を送信しなく、送信通知間隔により確定された時点（例えば、５時間）に達してから、前記汎用サービスエンティティは、前記複数のグループのうちの少なくとも１つのグループ（例えば、再通知グループ）内の通知者にイベント通知を送信する。以上のように、前記汎用サービスエンティティは、前記グループの順番又は他の方式で前記再通知グループを確定し、さらに、前記再通知グループが初期通知グループと異なっても良く、ここで説明を省略する。
【0055】
次に、図３Ａに示すように、前記汎用サービスエンティティは、次の検証イベント通知時点までに待ち（例えば、８時間）、該時点でイベント通知ルールを満たすか否かの判断を行い、イベント通知ルールを満たす場合、次のイベント通知の送信時点で（例えば、１０時間）、前記複数のグループのうちの少なくとも１つのグループ（例えば、他の再通知グループ）内の通知者にイベント通知を送信し、このように類推する。本開示の実施例において、前記他の再通知グループが前記再通知グループ又は初期通知グループと異なっても良い。
【0056】
本開示の別の実施例によれば、前記イベント通知方法は、検証イベント通知間隔及び送信通知間隔を設定することであって、前記送信通知間隔が前記検証イベント通知間隔よりも小さい、ことをさらに含んでもよい。この実施例において、前記再通知基準を満たすか否かを確定することは、前記送信通知間隔により確定された時点で、再通知基準を満たすと確定することを含んでもよい。前記再通知基準を満たすか否かを確定することは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記送信イベント通知を待ち、前記送信通知間隔により確定された時点で、前記複数のグループのうちの少なくとも１つのグループ内の通知者に前記イベント通知を送信する。
【0057】
図３Ｂは本開示の実施例における検証イベント通知間隔よりも小さい送信通知間隔の設定の模式図である。以下、図３Ｂを参照して、この実施例において、再通知基準を確定する手順を説明する。なお、図３Ｂに示す具体的な実施例において、前記イベントサブスクリプション要求に複数の通知者が含まれ、前記複数の通知者を１つ以上のグループに分ける。
【0058】
例えば、汎用サービスエンティティは、送信通知間隔属性及び検証イベント通知間隔属性を作成し、送信通知間隔が検証イベント通知間隔よりも小さいように設定する。例えば、前記送信通知間隔属性は、送信通知間隔が５時間として確定され、前記検証イベント通知間隔属性は、検証通知間隔が６時間として確定される。即ち、送信通知間隔が検証イベント通知間隔よりも小さいように設定する。
【0059】
図３Ｂの横軸は時間軸を示し、例えば、汎用サービスエンティティがイベント通知を初期通知グループの通知者に送信する時点を時間軸の開始点として表すことができる。これにより、前記汎用サービスエンティティは、該開始点から６時間ごとの時点を、イベント通知ルールを満たすか否かを検証する時点として設定し、該開始点から５時間ごとの時点を、イベント通知を送信する時点として設定する。
【0060】
この実施例において、図３Ｂに示すように、送信通知間隔が検証イベント通知間隔よりも小さいため、前記汎用サービスエンティティは、イベント通知を送信した後（即ち、時間軸の開始点）、まず、送信イベント通知時点（例えば、５時間）に達し、前記汎用サービスエンティティは、この送信イベント通知時点が再通知基準を満たすと確定し、前記複数のグループのうちの少なくとも１つのグループ（例えば、再通知グループ）内の通知者に前記イベント通知を送信する。検証イベント通知間隔の時点に達した場合（例えば、６時間）、前記汎用サービスエンティティは、イベント通知ルールを満たすか否かを判断し、イベント通知ルールを満たす場合、前記送信イベント通知を待ち、前記送信通知時点に達した場合（例えば、１０時間）、前記複数のグループのうちの少なくとも１つのグループ（例えば、他の再通知グループ）内の通知者に前記イベント通知を送信する。本開示による実施例において、前記他の再通知グループが前記再通知グループ又は初期通知グループと異なっても良い。
【0061】
本開示の実施例によれば、前記汎用サービスエンティティは、検証イベント通知間隔属性を作成する場合、該検証イベント通知間隔属性に対応する前記検証イベント通知間隔属性を有効化するか否かを設定するための検証イベント通知有効属性を作成してもよい。
【0062】
本開示に係るイベント通知方法は、サブスクリプション要求内の通知者をグループに分け、サブスクリプション要求内の全ての通知者にイベント通知を一度に送信せずに、グループに基づいてイベント通知を行い、さらに、送信イベント通知間隔及び／又は検証イベント通知間隔を設定することによって上記のイベント通知の過程を行うことで、サブスクリプション要求内の通知者の管理を実現し、イベント通知の送信を正確にし、通知効率を向上させ、通知者への情報干渉を回避することができる。
【0063】
図４Ａは、本開示の一実施例に係るイベント通知方法を実行するためのサブスクリプションリソース構成を示す模式図であり、図４Ｂは、図４Ａに示すサブスクリプションリソース構成の別の模式図であり、図５は、図４Ａ及び図４Ｂに示すサブスクリプションリソース構成に対応するイベント通知方法のフローチャートである。以下、図４Ａ－４Ｂ及び図５を参照して、本開示の実施例によるイベント通知方法及びその実施例について詳細に説明する。
【0064】
図５に示すように、モノのインターネットは、汎用サービスエンティティ（サービスエンティティとも呼ぶ）と一連のアプリケーションエンティティとから構成され、前記アプリケーションエンティティは、各種センサデバイスであってもよく、携帯電話のようなユーザ端末であってもよく、デバイス内のソフトウェアモジュール等であってもよく、携帯電話のアプリケーション等であってもよい。前記汎用サービスエンティティは、それに接続されたアプリケーションエンティティを管理し、登録、データ伝送、タスクの実行などの動作を行う。例えば、図５に示すように、サービスエンティティは、アプリケーションエンティティ、並びにサブスクライバ１及びサブスクライバ２からのデバイス登録要求を受信し、それによって前記アプリケーションエンティティ及びサブスクライバ１及びサブスクライバ２との関連付けを確立する。サブスクリプション要求のアプリケーションにおいて、サブスクライバ（例えば、サブスクライバ１およびサブスクライバ２）は、複数の通知者を含むイベントサブスクリプション要求をサービスエンティティに送信することができる。例えば、このサブスクリプション要求は、アプリケーションエンティティからの更新データを受信することを要求するために使用されてもよく、また、サービスエンティティがある動作処理を実行することを要求するために使用されてもよく、ここではその説明を省略する。
【0065】
サブスクライバ１およびサブスクライバ２のそれぞれからの同じサブスクリプション要求を受信すると、前記サービスエンティティは、サブスクリプション要求に対応するサブスクリプションリソースを作成する。例えば、図５に示すような前記サブスクリプション要求は、マンホールカバーの移動のイベント通知を要求するために使用されてもよく、また、サブスクライバ１およびサブスクライバ２からのサブスクリプション要求には複数の通知者が含まれてもよく、例えば、サブスクライバ１からのサブスクリプション要求には通知者Ａ、通知者Ｂおよび通知者Ｃが含まれ、サブスクライバ２からのサブスクリプション要求には通知者Ｄ、通知者Ｅおよび通知者Ｆが含まれる。前記サブスクリプションリソースの構成は、図４Ａまたは図４Ｂに示される通りであってもよい。図４Ｂに示すように、前記サブスクリプションリソースは、イベント通知ルール属性、通知者リスト属性、及び検証イベント通知間隔属性を含んでもよく、ここで、図４Ａ及び図４Ｂに示すサブスクリプションリソース構成において、丸角のボックスは属性を示す。前記サブスクリプションリソースは、前記検証イベント通知間隔属性を有効にするか否かを確定するための検証イベント通知間隔有効属性を含んでもよい。図４Ａに示されるように、前記サブスクリプションリソースは、イベント通知ルール属性を含んでもよい。なお、サブスクリプションリソースは、イベント通知を送信するためのイベント通知リソースを含んでもよく、方形のボックスはリソースを示す。前記イベント通知リソースは、通知者リスト属性、検証イベント通知間隔属性及び検証イベント通知間隔有効属性というサブ属性を含んでもよい。
【0066】
本開示の実施例によれば、前記汎用サービスエンティティは、サブスクリプション要求に含まれる通知者を複数のグループ、例えば３つのグループに分け、このグループに基づいて通知者リスト内に通知者の情報を記憶する。例えば、第１のグループに、通知者Ａ、通知者Ｂ、通知者Ｃが含まれ、第２のグループに、通知者Ｄ、通知者Ｅが含まれ、第３のグループに通知者Ｆが含まれてもよい。本開示の一実施例によれば、通知者リストにおいて、例えばＡ，Ｂ，Ｃ；Ｄ，Ｅ；Ｆのように異なるグループがセミコロンで区分される。
【0067】
上記の実施例では、図５のアプリケーションエンティティは、検知したマンホールカバーが移動したか否かのデータを更新するために、更新要求をサービスエンティティに定期的に送信することができるマンホールカバーの移動センサであってもよい。サービスエンティティは、アプリケーションエンティティからの更新要求を受信し、該アプリケーションエンティティに更新応答を送信し、前記アプリケーションエンティティは、該更新応答に基づいて更新データをサービスエンティティに送信する。更新データを受信した後、前記サービスエンティティは、該更新データがイベント通知ルールを満たすか否か、例えば、マンホールカバー移動のイベントが発生したか否かを判断することができる。サービスエンティティが、更新データがイベント通知ルールを満たさなく、例えば、マンホールカバー移動のイベントが発生していないと判断した場合、イベント通知をサブスクライバに送信しない。サービスエンティティは、更新データがイベント通知ルールを満たし、例えば、マンホールカバーの移動イベントが発生したと判断する場合、イベント通知１を通知者リストの第１のグループの通知者（すなわち、通知者Ａ、通知者Ｂ、および通知者Ｃ）に送信する。なお、図５に示すサブスクライバ１は、前記通知者Ａ、通知者Ｂ、および通知者Ｃを含む。なお、上記のサブスクライバ１がサブスクライバＡ、サブスクライバＢ、及びサブスクライバＣを含むことは、例示に過ぎず、別の実施例では、サブスクライバＡ、サブスクライバＢ、及びサブスクライバＣがサブスクライバ１とは異なるデバイスであってもよく、例えば、サブスクライバ１がデバイス１、サブスクライバＡがデバイス２、サブスクライバＢがデバイス３、及びサブスクライバＣがデバイス４である。
【0068】
図５に示すように、サブスクライバ１（通知者Ａ、通知者Ｂ、および通知者Ｃを含む）は、イベント通知１を受信した後、そのイベント通知１に対応する通知応答をサービスエンティティに送信することができる。マンホールカバー移動のサブスクリプション要求において、前記通知者Ａ、通知者Ｂ及び通知者Ｃは、マンホールカバーの安全管理を担当するメカニズムに属するデバイスであってもよく、マンホールカバーの安全管理を担当するメカニズムは、マンホールカバー移動のイベント通知を受信した後、このイベントを適時に処理し、例えば、マンホールカバーの移動原因をチェックし、危険イベントの発生を避けるためにマンホールカバーを適時に位置調整することができる。
【0069】
前記サービスエンティティは、前記イベント通知１を送信した後、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記複数のグループのうちの少なくとも１つのグループ内の通知者にイベント通知２を送信し、例えば、第２のグループである。
【0070】
図５に示すように、前記サービスエンティティは、検証イベント通知間隔属性によって確定された時点で、イベント通知ルールを満たすか否かを再度判断し、イベント通知ルールを満たす場合、例えば、マンホールカバーが移動した場合に、前記再通知基準を満たすと確定する。次に、前記サービスエンティティは、前記複数のグループのうちの少なくとも１つのグループ内の通知者にイベント通知２を送信し、ここで、前記少なくとも１つのグループは、例えば、第２のグループであっても良く、即ち、通知者Ｄ及び通知者Ｅを含む。例えば、通知者Ｄと通知者Ｅは、マンホールカバーセキュリティ管理を監督するメカニズムに属するデバイスであってもよい。これにより、マンホールカバー移動イベントに基づく異なるグループに属する通知者にそれぞれイベント通知を行うことが可能となる。
【0071】
この実施例では、マンホールカバー移動に関する更新データを受信した後、サービスエンティティは、まず、マンホールカバーの移動イベントの処理を迅速に実施するために、イベント通知を第１のグループの通知者に送信する。時間が経過した後、即ち、検証イベント通知間隔により確定される時点に達した後、前記サービスエンティティは、イベント通知ルールを満たすか否かを再び判断し、マンホールカバーの移動のイベント通知ルールを依然として満たすと判断された場合、サービスエンティティは、該イベントを監視するために前記イベント通知を第２のグループの通知者に送信し、この時、第２のグループの通知者は、マンホールカバーの移動イベントが発生したことを知ることができ、さらに、第１のグループの通知者は、検証イベント通知間隔内で該イベントを処理せず、これにより、マンホールカバーのセキュリティ管理を監視するメカニズムの目的を達成する。サービスエンティティが、検証イベント通知間隔によって確定される時点で、マンホールカバーの移動のイベント通知ルールを満たさないと判断すると、イベント通知は送信されない。この場合、第１のグループの通知者がイベント通知を受信した後、該マンホールカバーの移動イベントを処理し、マンホールカバーを復元したことを示す。このとき、第２のグループの通知者については、不要な情報であるイベント通知を受信しないため、第２のグループの通知者への情報干渉が少なくなり、イベント通知を全ての通知者に送信するためのリソースの無駄が少なくなる。
【0072】
また、この実施例では、サービスエンティティは、通知者の責務に基づいて、通知者をグループ化するが、本開示による別の実施例では、他の方法でグループ化することもできる。
【0073】
本開示の別の実施例によれば、サービスエンティティは、前記再通知基準を満たすか否かの判定を別の方法で実現することができる。
【0074】
図６Ａは、本開示の別の実施例に係るイベント通知方法を実現するためのサブスクリプションリソース構成を示す図であり、図６Ｂは、図６Ａに示したサブスクリプションリソース構成の別の模式図を示し、図７は、図６Ａ及び図６Ｂに示すサブスクリプションリソース構成に対応するイベント通知方法のフローチャートを示す。
【0075】
【0076】
本開示による上述の実施例において、前記サービスエンティティは、サブスクライバ１およびサブスクライバ２のそれぞれからのサブスクリプション要求を受信した後、該サブスクリプション要求に対応するサブスクリプションリソースを作成する。前記サブスクリプションリソースの構成は、図６Ａまたは図６Ｂに示される通りであり得る。前記サブスクリプションリソースは、図６Ｂに示されるように、イベント通知ルール属性、通知者リスト属性、及び送信イベント通知間隔属性を含むことができる。ここで、前記送信イベント通知属性は、イベント通知を送信する時間間隔を設定する。図６Ａに示すように、前記サブスクリプションリソースは、イベント通知を送信するためのイベント通知リソースをさらに含み得る。前記通知者リスト属性及び送信イベント通知間隔属性を前記イベント通知リソースのサブ属性とする。図７に示すサブスクリプション要求に関する実施例は、図５で説明した方式と同様であるため、ここでの説明は省略する。
【0077】
図７に示すフローチャートでは、前記サービスエンティティは、図６Ａ及び図６Ｂに示す送信イベント通知間隔属性に基づいて、再通知要求を満たすか否かの判断を行う。前記サービスエンティティは、送信通知間隔属性により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合に、前記再通知基準を満たすと判断し、前記通知者リストに記憶された第２グループの通知者にイベント通知２を送信することで、異なる通知者に対するイベント通知の段階的な送信を実現する。
【0078】
図８Ａは、本開示の更に別の実施例によるイベント通知方法を実現するためのサブスクリプションリソース構成の概略的な図であり、図８Ｂは、図８Ａに示すサブスクリプションリソース構成の別の概略的な図であり、図９Ａは、図８Ａ及び図８Ｂに示すサブスクリプションリソース構成に対応するイベント通知方法のフローチャートであり、図９Ｂは、図８Ａ及び図８Ｂに示すサブスクリプションリソース構成に対応するイベント通知方法の更に別のフローチャートである。以下、図８Ａ－８Ｂ及び図９Ａ－９Ｂを参照して、本開示の実施例にかかるイベント通知方法及びその実施例について詳細に説明する。
【0079】
図８Ｂに示すように、前記サービスエンティティがサブスクリプション要求を受信した後に作成されたサブスクリプションリソースに、イベント通知ルール属性、通知者リスト属性、検証イベント通知間隔属性、および送信イベント通知間隔属性を含むことができる。前記サブスクリプションリソースはまた、前記検証イベント通知間隔属性を有効にするか否かを確定するための検証イベント通知間隔有効属性を含むことができる。図８Ａに示されるように、前記サブスクリプションリソースは、イベント通知を送信するためのイベント通知リソースをさらに含み得る。前記通知者リスト属性、検証イベント通知間隔属性、送信イベント通知間隔属性、検証イベント通知間隔属性をイベント通知リソースのサブ属性とすることができる。
【0080】
本開示の上述した実施例では、前記送信イベント通知間隔属性と検証イベント通知間隔属性とを用いて、送信通知間隔が検証イベント通知間隔よりも大きいように設定することができ、前記時間間隔の模式図は、図３Ａに示す。この実施例において、前記再通知基準を満たすか否かを確定することは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定し、イベント通知の送信を待ち、前記送信通知間隔により確定された時点で、前記複数のグループのうちの少なくとも１つのグループ例えば、第２のグループ内の通知者にイベント通知２を送信する。
【0081】
図９Ｂに示すように、前記サービスエンティティは、図８Ａ又は図８Ｂに示す送信イベント通知間隔属性及び検証イベント通知間隔属性を利用して、送信通知間隔が検証イベント通知間隔よりも小さいように設定し、前記時間間隔の模式図は図３Ｂに示す。この実施例において、前記再通知基準を満たすか否かを確定することは、前記送信通知間隔により確定された時点で、再通知基準を満たすと確定し、前記複数のグループのうちの少なくとも１つのグループ、例えば、第２のグループ内の通知者（即ち、通知者Ｄ及び通知者Ｅ）にイベント通知２を送信する。該イベント通知２を受信した後、前記第２のグループ内の通知者は、サービスエンティティに該イベント通知２に対応する通知応答を送信することができる。
【0082】
この実施において、前記サービスエンティティは、前記検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記送信イベント通知を待ち、さらに、前記送信通知間隔により確定された時点で、前記複数のグループのうちの少なくとも１つのグループ、例えば、第３のグループ内の通知者（即ち、通知者Ｆ）にイベント通知３を送信することができる。該イベント通知３を受信した後、前記第３のグループ内の通知者は、サービスエンティティに該イベント通知２に対応する通知応答を送信することができる。
【0083】
本開示の上記の実施例において、前記サービスエンティティは、イベント通知１（又はイベント通知２）を送信した後、それにイベント通知を送信する通知者が存在するか否かを判断し、前記通知者が存在しないと確定した場合、即ち、通知者リスト内の通知者のいずれも該イベント通知を受信した場合、サービスエンティティは、再通知基準を満たすか否かの判断を行わない。
【0084】
本開示によるイベント通知方法は、サブスクリプション要求内の通知者をグループに分けて、イベント通知をすべての通知者に一度に送信せずに、前記グループに基づいてイベント通知を行い、さらに、送信イベント通知間隔及び／又は検証イベント通知間隔を設定することで上記のグループ化してイベント通知を送信する過程を実現し、サブスクリプション要求内の通知者の管理を実現し、イベント通知の送信の正確性を実現し、通知効率を向上させ、通知者への情報干渉を回避することができる。
【0085】
本開示の実施例によれば、前記イベントサブスクリプション要求に１つの通知者のみが含まれても良く、この場合、前記１つの通知者を１つのグループに分け、例えば、第４のグループである。この実施例において、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、前記イベント通知ルールを満たすと確定し、イベント通知ルールを満たす場合、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記１つ以上の通知者にイベント通知を送信することを含む。つまり、イベント通知ルールを満たすと確定する場合、前記第４のグループ内の通知者にイベント通知を送信せず、再通知ルールを満たすか否かの判断を行い、前記第４のグループ内の通知者へのイベント通知の送信を遅延させるという効果を実現する。
【0086】
本開示の実施例によれば、前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0087】
具体的に、図１０Ａは、本開示の実施例における第４のグループ内の１つの通知者にイベント通知を送信するフローチャートを示す。図１０Ａに示すように、サブスクライバ、通知者、およびアプリケーションエンティティは、サービスエンティティにデバイス登録要求を送信することによってデバイス登録を実現する。次いで、サブスクライバは、サブスクリプション要求を前記サービスエンティティに送信することができる。前記サブスクリプション要求は、上述したように、単一リソースサブスクリプション要求であってもよく、さらに、前記イベントサブスクリプション要求には、１つの通知者が含まれてもよく、イベント通知を送信するか否かを確定するイベント通知ルール及び再通知基準が含まれてもよい。前記サービスエンティティは、受信されたサブスクリプション要求に基づいてサブスクリプションリソースを作成し、加入応答を前記サブスクリプション要求のサブスクライバに送信することもできる。
【0088】
前記アプリケーションエンティティは、検知したマンホールカバーが移動したか否かのデータを更新するために、更新要求をサービスエンティティに定期的に送信することができるマンホールカバーの移動センサであってもよい。サービスエンティティは、アプリケーションエンティティからの更新要求を受信し、該アプリケーションエンティティに更新応答を送信し、前記アプリケーションエンティティは、該更新応答に基づいて更新データをサービスエンティティに送信する。更新データを受信した後、前記サービスエンティティは、該更新データがイベント通知ルールを満たすか否かを判断することができる
【0089】
更新データがイベント通知ルールを満たすと確定する場合、前記サービスエンティティが検証イベント通知間隔により確定された時点までに待ち、前記時点に達すると、前記サービスエンティティは、イベント通知ルールを満たすか否かの判断を再度に行い、受信された更新データが依然としてイベント通知ルールを満たすと確定する場合、前記サービスエンティティは、サブスクリプション要求に含まれる通知者にイベント通知を送信し、これにより、前記第４のグループ内の１つの通知者へのイベント通知の送信を遅延させるという効果を実現する。
【0090】
本開示の実施例によれば、前記イベントサブスクリプション要求に複数の通知者が含まれることがあり、この場合、同様、前記複数の通知者を１つのグループに分け、例えば、第５のグループである。この実施例において、前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信することは、前記イベント通知ルールを満たすと確定し、イベント通知ルールを満たす場合、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記第５のグループ内の通知者にイベント通知を送信する。つまり、イベント通知ルールを満たすと確定する場合、前記第５のグループ内の複数の通知者にイベント通知を送信せず、再通知ルールを満たすか否かの判断を行い、これにより、前記第５のグループ内の複数の通知者へのイベント通知の送信を遅延させるという効果を実現する。
【0091】
図１０Ｂは、本開示の実施例における複数の第５グループにおける複数の通知者へのイベント通知を送信するためのフローチャートを示す。図１０Ｂに示されるように、前記サブスクリプション要求は、複数の通知者、例えば２つの通知者をさらに含むことができる。図１０Ｂに示すイベント通知遅延の具体的なフローチャートは、図１０Ａに示すフローチャートと同様であるため、ここで説明を省略する。なお、図１０Ｂに示す２つの通知者は、サブスクリプション要求を送信するサブスクライバを含んでいないが、これは一例であり、前記複数の通知者が前記サブスクライバ自身を含んでいてもよい。
【0092】
本開示の実施例によれば、前記イベントサブスクリプション要求は、単一リソースサブスクリプション要求及びクロスリソースサブスクリプション要求のうちの少なくとも１つであってもよい。前記単一リソースサブスクリプション要求の実現方式は、上記の図５、図７、図９Ａ、又は図９Ｂに示すように、即ち、サブスクライバが１つのアプリケーションエンティティの更新データに対する加入を要求しても良い。前記クロスリソースサブスクリプション要求は、サブスクライバが複数のアプリケーションエンティティの更新データに対する加入を要求してもよい。
【0093】
図１１は本開示の実施例におけるイベント通知方法においてクロスリソースサブスクリプションのフローチャートである。図１１に示すように、前記サブスクリプション要求はクロスリソースサブスクリプション要求である。この場合、前記イベント通知ルールは、クロスリソースイベント通知ルールであっても良い。前記サービスエンティティは、複数のアプリケーションエンティティ（図１１に２つのアプリケーションエンティティを示す）の更新データを受信した後、前記クロスリソースイベント通知ルールを満たすか否かを判断する。
【0094】
前記クロスリソースイベント通知ルールを満たすと確定する場合、前記サービスエンティティは、検証イベント通知間隔により確定された時点までに待ち、前記時点に達すると、前記サービスエンティティは、クロスリソースイベント通知ルールを満たすか否かの判断を再度行い、受信された更新データが依然として前記クロスリソースイベント通知ルールを満たすと確定する場合、前記サービスエンティティは、サブスクリプション要求に含まれる１つ以上の通知者にイベント通知を送信し、これにより、前記１つ以上の通知者へのイベント通知の送信を遅延させるという効果を実現する。
【0095】
本開示によるイベント通知方法によれば、受信された更新データがイベント通知ルールを満たす場合に、サブスクリプション要求に含まれる１つ以上の通知者にイベント通知を即時に送信するのではなく、検証イベント通知間隔により確定された時点までに待ち、その時点に達すると、イベント通知ルールを満たすか否かの判断を再度行い、イベント通知ルールを満たすと判断する場合に、イベント通知を前記１つ以上の通知者に送信することが可能になる。
【0096】
本開示の実施例によれば、サーバーデバイスがさらに提供されている。図１２は本開示の実施例におけるサーバーデバイスの模式図である。前記サーバーデバイス１００は、送受信機１０１及びプロセッサ１０２を備え、ここで、前記送受信機１０１は、サブスクライバからのイベントサブスクリプション要求を受信するように構成され、前記イベントサブスクリプション要求に１つ以上の通知者が含まれる。前記プロセッサ１０２は、前記１つ以上の通知者を１つ以上のグループに分け、各グループに１つ以上の通知者が含まれ、前記送受信機が前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するように指示するように構成される。
【0097】
本開示の実施例によれば、前記プロセッサ１０２は、さらに、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記送受信機１０１が前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するように指示するように構成される。
【0098】
本開示の実施例によれば、前記プロセッサ１０２は、さらに、前記送受信機１０１が前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するように指示した後、再通知基準を満たすか否かを確定し、再通知基準を満たす場合、前記送受信機１０１が前記１つ以上のグループのうちの少なくとも１つのグループ内の通知者にイベント通知を送信するように指示し、ここで、イベント通知ルールを満たす場合にイベント通知を送信するグループを初期通知グループとして示し、再通知基準を満たす場合にイベント通知を送信するグループを再通知グループとして示し、前記初期通知グループが前記再通知グループと異なる。
【0099】
本開示の一実施例によれば、前記再通知基準を満たすか否かを確定することは、検証イベント通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0100】
本開示の別の実施例によれば、前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、イベント通知ルールを満たすか否かを確定し、イベント通知ルールを満たす場合、前記再通知基準を満たすと確定することを含む。
【0101】
本開示の別の実施例によれば、前記再通知基準を満たすか否かを確定することは、送信通知間隔により確定された時点で、前記再通知基準を満たすと確定することを含む。
【0102】
任意選択で、上記のサーバーデバイス１００は、アプリケーションエンティティのために作成されたリソースを格納し、プロセッサ１０２によって実行されたときに上記のイベント通知方法のステップを実行する関連する命令を格納するための内蔵または外付けのメモリをさらに有してもよい。
【0103】
本開示の実施例によれば、イベント通知装置がさらに提供されている。図１３は、本開示の実施例におけるイベント通知装置の概略図である。前記イベント通知装置２００は、１つ以上のプロセッサ２０１と、１つ以上のメモリ２０２とを備え得る。ここで、前記プロセッサ２０１には、コンピュータ読み取り可能なコードが記憶され、前記コンピュータ読み取り可能なコードは、前記１つ以上のプロセッサ２０２により実行されると、上述したようなイベント通知方法を行うことができ、ここでその説明が省略される。
【0104】
本開示の実施例によれば、コンピュータ記憶媒体がさらに提供されている。ここで、前記コンピュータ記憶媒体にはコンピュータ読み取り可能なコードが記憶され、前記コンピュータ読み取り可能なコードは、１つ以上のプロセッサにより実行されると、前述のようなイベント通知方法を行うことができ、ここでその説明が省略される。
【0105】
特に定義されない限り、技術的及び科学的な用語を含む、本明細書で使用される全ての用語は、本開示が属する技術分野の当業者によって共通に理解されるものと同じ意味を有する。また、一般的に用いられる辞書に定義されているような用語は、関連技術の文脈上有する意味と一致する意味を有するものと解釈されるべきであり、本出願で明白に定義しない限り、理想的であるか、または非常に形式的な意味で解釈されるべきではない。
【0106】
以上、本開示を説明したが、本開示は上記実施例に限定されるものではない。本開示のいくつかの例示的な実施例を説明してきたが、当業者であれば、本開示の新規な教示および利点から逸脱することなく、例示的な実施例に多くの修正を加えることができることを容易に理解するであろう。したがって、そのような修正の全ては、特許請求の範囲によって定義される本開示の範囲内に含まれることが意図される。以上は本開示の説明であり、開示された特定の実施例に限定されるものと解釈されるべきではなく、開示された実施例および他の実施例に対する修正は、添付の特許請求の範囲内に含まれることが意図されることを理解されたい。本開示は、特許請求の範囲及びその均等物によって定義される。
【0107】
本出願は、２０１８年１１月２８日に出願された中国特許出願第２０１８１１４３２９９１．５号に対する優先権を主張し、その全体が本出願の一部として参照により本明細書に組み込まれる。
【符号の説明】
【0108】
１００ デバイス
１０１ 送受信機
１０２ プロセッサ
２００ 装置
２０１ メモリ
２０２ プロセッサ
１０１ 送受信機
１０２ プロセッサ
２００ 装置
２０１ メモリ
２０２ プロセッサ
【図1】
【図2】
【図3A】
【図3B】
【図4A】
【図4B】
【図5】
【図6A】
【図6B】
【図7】
【図8A】
【図8B】
【図9A】
【図9B】
【図10A】
【図10B】
【図11】
【図12】
【図13】