▶ 京東方科技集團股▲ふん▼有限公司の特許一覧 ▶ 北京京▲東▼方技▲術▼▲開▼▲発▼有限公司の特許一覧
特表2022-547726イベント通知方法、システム、サーバデバイス、コンピュータ記憶媒体
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2022-11-15
(54)【発明の名称】イベント通知方法、システム、サーバデバイス、コンピュータ記憶媒体
(51)【国際特許分類】
H04L 67/55 20220101AFI20221108BHJP
H04L 67/12 20220101ALI20221108BHJP
H04L 67/566 20220101ALI20221108BHJP
H04Q 9/00 20060101ALI20221108BHJP
【ＦＩ】
H04L67/55
H04L67/12
H04L67/566
H04Q9/00 301B
H04Q9/00 311K
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2022516700
(86)(22)【出願日】2020-09-14
(85)【翻訳文提出日】2022-03-15
(86)【国際出願番号】 CN2020115074
(87)【国際公開番号】W WO2021052289
(87)【国際公開日】2021-03-25
(31)【優先権主張番号】201910872383.4
(32)【優先日】2019-09-16
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
(71)【出願人】
【識別番号】510280589
【氏名又は名称】京東方科技集團股▲ふん▼有限公司
【氏名又は名称原語表記】ＢＯＥ ＴＥＣＨＮＯＬＯＧＹ ＧＲＯＵＰ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｎｏ．１０ Ｊｉｕｘｉａｎｑｉａｏ Ｒｄ．，Ｃｈａｏｙａｎｇ Ｄｉｓｔｒｉｃｔ，Ｂｅｉｊｉｎｇ １０００１５，ＣＨＩＮＡ
(71)【出願人】
【識別番号】519385216
【氏名又は名称】北京京▲東▼方技▲術▼▲開▼▲発▼有限公司
【氏名又は名称原語表記】ＢＥＩＪＩＮＧ ＢＯＥ ＴＥＣＨＮＯＬＯＧＹ ＤＥＶＥＬＯＰＭＥＮＴ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｒｏｏｍ ４０７，Ｂｕｉｌｄｉｎｇ １，Ｎｏ．９ Ｄｉｚｅ Ｒｏａｄ，ＢＤＡ，Ｂｅｉｊｉｎｇ，１００１７６，ＣＨＩＮＡ
(74)【代理人】
【識別番号】100108453
【弁理士】
【氏名又は名称】村山 靖彦
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(72)【発明者】
【氏名】▲趙▼ 君杰
(72)【発明者】
【氏名】▲蘇▼ 京
(72)【発明者】
【氏名】王 新安
(72)【発明者】
【氏名】▲陳▼ 少▲ベイ▼
(72)【発明者】
【氏名】▲張▼ 乾
(72)【発明者】
【氏名】▲趙▼ ▲硯▼秋
【テーマコード（参考）】
5K048
【Ｆターム（参考）】
5K048BA34
5K048DA02
5K048EB10
5K048EB13
(57)【要約】
本開示は、イベント通知方法、システム、サーバデバイス、コンピュータ記憶媒体を提供する。前記イベント通知方法は、イベント通知を受信するための少なくとも１つの受信側を含む、定期購読者からの定期購読要求を受信するステップと、監視時間間隔内に、連続イベント通知ルールを満たすか否かを決定するステップと、前記連続イベント通知ルールを満たしている場合、前記定期購読要求のイベント通知を前記少なくとも１つの受信側に送信するステップとを含む。
【特許請求の範囲】
【請求項1】
イベント通知を受信するための少なくとも１つの受信側を含む、定期購読者からの定期購読要求を受信するステップと、監視時間間隔内に、連続イベント通知ルールを満たすか否かを決定するステップと、
前記連続イベント通知ルールを満たしている場合、前記定期購読要求のイベント通知を、前記少なくとも１つの受信側に送信するステップと、を含む、イベント通知方法。
【請求項2】
前記監視時間間隔内に、少なくとも１つの監視データを取得するステップをさらに含み、連続イベント通知ルールを満たすか否かを決定するステップは、
前記少なくとも１つの監視データのうちのそれぞれが、イベント通知ルールを満たすか否かを決定するステップを含む、請求項１に記載のイベント通知方法。
【請求項3】
前記監視時間間隔内に、少なくとも１つの監視データを取得するステップをさらに含み、連続イベント通知ルールを満たすか否かを決定するステップは、
前記少なくとも１つの監視データのうちのそれぞれが、イベント通知ルールを満たすか否かを決定するステップと、
イベント通知ルールを満たす監視データの数を決定するステップと、
前記数がカウント閾値以上である場合、連続イベント通知ルールを満たすと決定するステップと、を含み、
前記カウント閾値は、前記監視時間間隔内に受信された監視データの数に基づいて決定されている、請求項１に記載のイベント通知方法。
【請求項4】
前記監視時間間隔内に、少なくとも１つの監視データを取得するステップとをさらに含み、連続イベント通知ルールを満たすか否かを決定するステップは、
前記少なくとも１つの監視データのうちのそれぞれが、イベント通知ルールが満たすか否かを決定するステップと、
イベント通知ルールを満たす前記監視データの時間間隔に基づいて、イベント通知ルールを満たす時間の長さを決定するステップと、
前記時間の長さと前記監視時間間隔との比例が時間閾値以上である場合、連続イベント通知ルールを満たすと決定するステップと、を含み、
前記時間閾値が１以下である、請求項１に記載のイベント通知方法。
【請求項5】
前記イベント通知ルールは、前記監視データが監視閾値よりも大きいことと、
前記監視データが監視閾値に等しいことと、
前記監視データが監視閾値よりも小さくことと、
前記監視データが監視閾値以上であることと、
前記監視データが監視閾値以下であることと、のうちいずれか１つを含む、請求項２～４のいずれか一項に記載のイベント通知方法。
【請求項6】
前記監視時間間隔内に、少なくとも１つの監視データを取得するステップをさらに含み、連続イベント通知ルールを満たすか否かを決定するステップは、
イベント通知ルールを満たすと決定した場合、前記少なくとも１つの監視データが監視データルールを満たすか否かを決定して、監視結果を取得するステップと、
前記監視結果に基づいて、前記連続イベント通知ルールを満たすか否かを決定するステップと、を含む、請求項１に記載のイベント通知方法。
【請求項7】
前記イベント通知ルールは、定期購読されたリソースの属性を更新することと、定期購読されたリソースのサブリソースを作成することと、定期購読されたリソースのサブリソースを削除することと、定期購読されたコンテナリソースのコンテンツインスタンスサブリソースを取得することと、特定リクエスターの操作要求を受信することと、特定タイプの操作要求を受信することと、のうち少なくとも１つを含み、前記監視データルールは、監視データが監視閾値よりも大きいことと、監視データが監視閾値に等しいことと、監視データが監視閾値よりも小さくことと、監視データが監視閾値以上であることと、監視データが監視閾値以下であることと、のうちいずれか１つを含む、請求項６に記載のイベント通知方法。
【請求項8】
監視データルールを満たすか否かを決定して、監視結果を取得するステップは、前記少なくとも１つの監視データのうちのそれぞれが、監視データルールを満たすか否かを決定するステップと、
当該監視データが監視データルールを満たす場合、監視データルールを満たす監視結果を取得し、当該監視データが監視データルールを満たさない場合、監視データルールを満たさない監視結果を取得するステップと、を含む、請求項６に記載のイベント通知方法。
【請求項9】
連続イベント通知ルールを満たすか否かを決定するステップは、監視データルールを満たす監視結果の数を決定するステップと、
監視データルールを満たす監視結果の数がカウント閾値以上である場合、連続イベント通知ルールを満たすと決定するステップと、を含み、
前記カウント閾値は、前記監視時間間隔内に受信された監視データの数に基づいて決定される、請求項８に記載のイベント通知方法。
【請求項10】
連続イベント通知ルールを満たすか否かを決定するステップは、監視データルールを満たす監視結果に対応する時間の長さを決定するステップと、
前記時間の長さと前記監視時間間隔との比例が時間閾値以上である場合、連続イベント通知ルールを満たすと決定するステップであって、前記時間閾値が１以下であるステップと、を含む、請求項８に記載のイベント通知方法。
【請求項11】
監視時間間隔の開始時点及び終了時点を決定するステップであって、イベント通知ルールを満たす時点を前記開始時点として決定し、前記監視時間間隔と決定された開始時点とに基づいて、前記終了時点を決定するステップをさらに含む、請求項６に記載のイベント通知方法。
【請求項12】
監視時間間隔の開始時点及び終了時点を決定するステップであって、イベント通知ルールを満たす時点を前記終了時点として決定し、前記監視時間間隔と決定された終了時点とに基づいて、前記開始時点を決定するステップ、をさらに含む、請求項６に記載のイベント通知方法。
【請求項13】
監視時間間隔の開始時点及び終了時点を決定するステップであって、イベント通知ルールを満たす時点を中間時点として決定し、前記監視時間間隔と決定された中間時点とに基づいて、前記開始時点及び終了時点を決定し、前記中間時点が前記開始時点と終了時点との間にあるステップ、をさらに含む、請求項６に記載のイベント通知方法。
【請求項14】
前記定期購読要求には、前記監視時間間隔がさらに含まれ、前記イベント通知方法は、定期購読リソースを作成するステップをさらに含み、
前記定期購読リソースは、
前記監視時間間隔を決定するための監視時間間隔属性と、
イベント通知を前記少なくとも１つの受信側に送信するか否かを決定するための連続イベント通知ルール属性と、
前記少なくとも１つの受信側のアドレス情報を記憶するためのイベント通知リスト属性と、を含む、請求項１に記載のイベント通知方法。
【請求項15】
トランシーバーとプロセッサを備えるサーバデバイスであって、前記トランシーバーは、イベント通知を受信するための少なくとも１つの受信側を含む、定期購読者からの定期購読要求を受信するように構成され、
前記プロセッサは、監視時間間隔内に、連続イベント通知ルールを満たすか否かを決定するように構成され、
前記トランシーバーは、前記連続イベント通知ルールを満たす場合、前記定期購読要求のイベント通知を前記少なくとも１つの受信側に送信するようにさらに構成されている、サーバデバイス。
【請求項16】
定期購読装置と、サーバデバイスと、監視装置とを備えるイベント通知システムであって、前記定期購読装置は、イベント通知を受信するための少なくとも１つの受信側を含む定期購読要求を、サーバデバイスに送信するように構成され、
前記サーバデバイスは、
定期購読装置からの定期購読要求を受信し、
少なくとも１つの監視データを取得し、
監視時間間隔内に、連続イベント通知ルールを満たすか否かを決定し、
前記連続イベント通知ルールを満たす場合、前記定期購読要求のイベント通知を前記少なくとも１つの受信側に送信するように構成され、
前記監視装置は、監視データを前記サーバデバイスに送信するように構成される、イベント通知システム。
【請求項17】
コンピュータ読み取り可能なコードが記憶されているコンピュータ記憶媒体であって、前記コンピュータ読み取り可能なコードが１つ又は複数のプロセッサによって実行される場合、請求項１～１４のいずれか一項に記載のイベント通知方法が実行される、コンピュータ記憶媒体。
【発明の詳細な説明】
【技術分野】
【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】
前記定期購読要求には定期購読条件が含まれてもよく、これによって、当該定期購読条件（例えば、煙感知器が鳴る）を満たす場合、サーバデバイスがイベント通知を送信する。前記定期購読条件は、イベント通知ルールと呼ばれてもよく、つまり、イベント通知ルールを満たすと決定された場合、サーバデバイスがイベント通知を送信する。
【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】
１００ サーバデバイス
１０１ トランシーバー
１０２ プロセッサ
２００ イベント通知システム
２０１ 定期購読装置
２０２ サーバデバイス
２０３ 監視装置
１０１ トランシーバー
１０２ プロセッサ
２００ イベント通知システム
２０１ 定期購読装置
２０２ サーバデバイス
２０３ 監視装置
【図1A】
【図1B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12A】
【図12B】
【図13】
【図14】
【国際調査報告】