(57)【要約】  通知を行う方法、装置及びシステムを提供する。前記方法は、イベント通知基準を決定ことと、参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信することとを含み、前記参加者情報は、参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール特徴の少なくとも一つを含む。本開示の実施例において、予約サービス側が上記参加者情報を満たす参加者を検知した後、被通知者へ通知メッセージを送信する。よって前記参加者に基づく通知サービスを実現し、ユーザ区別化の要求を満たす。
2019531527.tif 000002
【特許請求の範囲】
【請求項１】
イベント通知基準を決定することと、
参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信することと、を含み、
前記参加者情報は、参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール特徴の少なくとも一つを含む、
通知を行う方法。
【請求項２】
前記のイベント通知基準を決定することは、
予約リソースから前記イベント通知基準を決定すること、あるいは、
イベント通知基準セットから前記イベント通知基準を決定すること、を含む
請求項１に記載の方法。
【請求項３】
予約者が送信した予約リソース作成要求を受信することと、
前記イベント通知基準を含む予約リソースを作成することと、をさらに含む
請求項２に記載の方法。
【請求項４】
参加者情報が前記イベント通知基準を満たすか否かを判断することは、
前記参加者情報が特徴値とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定すること、を含む
請求項１に記載の方法。
【請求項５】
前記イベント通知基準を決定するように、予約者が送信した予約要求を受信すること、をさらに含む
請求項１に記載の方法。
【請求項６】
前記参加者情報を含む操作要求を受信すること、あるいは、
前記参加者情報を含む登録要求を受信すること、をさらに含む
請求項１ないし５のいずれか一項に記載の方法。
【請求項７】
参加者情報が前記イベント通知基準を満たすか否かを判断することは、
前記参加者情報が判断特徴と異なるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定すること、あるいは、
前記参加者情報が判断特徴と同等であるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定すること、をさらに含む
請求項１ないし６のいずれか一項に記載の方法。
【請求項８】
参加者情報が前記イベント通知基準を満たすか否かを判断することは、
参加者情報が判断特徴と異なる参加者の数を統計することと、
前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、
前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、を含む
請求項１ないし６のいずれか一項に記載の方法。
【請求項９】
前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、
前記参加者の数が第１閾値以上であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、
前記参加者の数が第２閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、
前記参加者の数が第１閾値以上かつ第２閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、を含む
請求項８に記載の方法。
【請求項１０】
前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、
持っている参加者情報は判断特徴と同じである参加者の数を統計することと、
前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、
ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、を含む
請求項１ないし６のいずれか一項に記載の方法。
【請求項１１】
前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、
前記参加者の数が第３閾値以上であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、
前記参加者の数が第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、
前記参加者の数が第３閾値以上かつ第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、を含む
請求項１０に記載の方法。
【請求項１２】
前記判断特徴は、識別子、ロール、識別子特徴及びロール特徴の少なくとも一つを含む、
請求項７ないし１１のいずれか一項に記載の方法。
【請求項１３】
イベント通知基準を決定するように配置される決定ユニットと、
参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信するように配置される通知ユニットと、を含み、
前記参加者情報は、参加者識別子、参加者識別子特徴、及び参加者ロール、参加者ロール識別子特徴の少なくとも一つを含む
通知を行う装置。
【請求項１４】
前記決定ユニットは、予約リソースまたはイベント通知基準セットから前記イベント通知基準を決定するように配置される、
請求項１３に記載の装置。
【請求項１５】
予約者が送信した予約リソース作成要求を受信するように配置される第１受信ユニットと、
前記イベント通知基準を含む予約リソースを作成するように配置される予約リソース作成ユニットと、をさらに含む
請求項１４に記載の装置。
【請求項１６】
前記通知ユニットは、前記参加者情報が特徴値とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するように配置される
請求項１３に記載の装置。
【請求項１７】
前記イベント通知基準を決定するように、予約者が送信した予約要求を受信するように配置される第２受信ユニットをさらに含む
請求項１３に記載の装置。
【請求項１８】
前記第１受信ユニットは、さらに、前記参加者情報を含む操作要求を受信するように配置され、あるいは、前記参加者情報を含む登録要求を受信するように用いられる
請求項１３ないし１７のいずれか一項に記載の装置。
【請求項１９】
前記通知ユニットは、
前記参加者情報が判断特徴と異なるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するように、あるいは、
前記参加者情報が判断特徴と同等であるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するように配置される
請求項１３に記載の装置。
【請求項２０】
前記通知ユニットは、
持っている参加者情報が判断特徴と異なる参加者の数、あるいは、持っている参加者情報が判断特徴と同じである参加者の数を統計し、
前記参加者の数が前記イベント通知基準を満たすか否かを判断し、
前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するように配置される
請求項１３に記載の装置。
【請求項２１】
前記判断特徴は、識別子、ロール、識別子特徴及びロール特徴の少なくとも一つを含む
請求項１９または２０に記載の装置。
【請求項２２】
請求項１３ないし２１のいずれか一項に記載の装置である予約サービス装置と、
前記予約サービス装置へ予約作成要求を送信するように配置される予約装置と、
前記予約サービス装置へ操作要求を送信するように配置される参加者装置と、
前記予約サービス装置からの通知を受信するように配置される被通知者装置と、を含む
通知を行うシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示の実施例は、通知を行う方法、装置及びシステムに関する。
【背景技術】
【０００２】
インターネット・オブ・シングス（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）技術の進展に伴い、各インターネット・オブ・シングスの応用分野は迅速に進展し、多くのプライベートプロトコルが登場する。各プライベートプロトコルの間で完全な交換性がないため、インターネット・オブ・シングス技術の進展を妨げる恐れがある。
【０００３】
インターネット・オブ・シングス通信プロトコルにおいて予約通知の仕組みが定義され、予約者が被予約者へ予約要求を送信し、イベントが発生すると被通知者へ通知を送信する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本開示の実施例は、通知を行う方法、装置及びシステムを提供する。
前記通知を行う方法は、
イベント通知基準を決定することと、参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信することと、を含み、前記参加者情報は、参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール特徴の少なくとも一つを含む。
【０００５】
例えば、前記のイベント通知基準を決定することは、予約リソース又はイベント通知基準セットから前記イベント通知基準を決定することを含んでもよい。
例えば、予約リソースから前記イベント通知基準を決定するか、あるいは、
イベント通知基準セットから前記イベント通知基準を決定する。
例えば、
前記イベント通知基準を含む予約リソースを作成することをさらに含む。
【０００６】
例えば、前記の予約リソースを作成する前に、予約者が送信した予約リソース作成要求を受信することをさらに含む。
【０００７】
例えば、参加者情報が前記イベント通知基準を満たすか否かを判断することは、
前記参加者情報が特徴値とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することを含む。
例えば、前記イベント通知基準を決定するように、予約者が送信した予約要求を受信することをさらに含む。
【０００８】
例えば、前記通知を行う方法は、前記参加者情報を含む操作要求を受信することをさらに含む。
【０００９】
例えば、前記通知を行う方法は、前記参加者情報を含む登録要求を受信することをさらに含む。
【００１０】
例えば、参加者情報が前記イベント通知基準を満たすか否かを判断することは、前記参加者情報が判断特徴と異なるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することを含む。
【００１１】
例えば、参加者情報が前記イベント通知基準を満たすか否かを判断することは、前記参加者情報が判断特徴と同等であるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することを含む。
【００１２】
例えば、参加者情報が前記イベント通知基準を満たすか否かを判断することは、持っている参加者情報が判断特徴と異なる参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、を含む。
【００１３】
例えば、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数が第１閾値以上であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数が第２閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数は第１閾値以上、かつ第２閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定することを含む。
【００１４】
例えば、前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、持っている参加者情報が判断特徴と同じである参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、を含む。
【００１５】
例えば、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数が第３閾値以上であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数が第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数が第３閾値以上、かつ第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定することを含む。
【００１６】
例えば、前記判断特徴は、識別子、ロール、識別子特徴とロール特徴の少なくとも一つを含む。
【００１７】
例えば、前記識別子は、予約者識別子、被予約者識別子、被通知者識別子、参加者識別子、予約者プリセット識別子、被予約者プリセット識別子、被通知者プリセット識別子と参加者プリセット識別子の少なくとも一つを含み、前記ロールは、予約者ロール、被予約者ロール、被通知者ロール、参加者ロール、予約者プリセットロール、被予約者プリセットロール、被通知者プリセットロールと参加者プリセットロールの少なくとも一つを含み、前記識別子特徴は、予約者識別子特徴、被予約者識別子特徴、被通知者識別子特徴、参加者識別子特徴、予約者プリセット識別子特徴、被予約者プリセット識別子特徴、被通知者プリセット識別子特徴と参加者プリセット識別子特徴の少なくとも一つを含み、前記ロール特徴は、予約者ロール特徴、被予約者ロール特徴、被通知者ロール特徴、参加者ロール特徴、予約者プリセットロール特徴、被予約者プリセットロール特徴、被通知者プリセットロール特徴と参加者プリセットロール特徴の少なくとも一つを含む。
【００１８】
本開示の実施例は、さらに、イベント通知基準を決定するための決定ユニットと、参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信するための通知ユニットと、を備える通知を行う装置を提供し、前記参加者情報は、参加者識別子、参加者識別子特徴、及び参加者ロール、参加者ロール識別子特徴の少なくとも一つを含む。
【００１９】
例えば、具体的には、決定ユニットは、予約リソースまたはイベント通知基準セットから前記イベント通知基準を決定するために用いられる。
【００２０】
例えば、前記装置は、前記イベント通知基準を含む予約リソースを作成するための予約リソース作成ユニットをさらに含む。
【００２１】
例えば、前記装置は、予約リソースを作成する前に、予約者が送信した予約リソース作成要求を受信するための第１受信ユニットをさらに含む。
【００２２】
例えば、前記通知ユニットが、具体的には、前記参加者情報が特徴値とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【００２３】
例えば、前記装置は、前記イベント通知基準を決定するように、予約者が送信した予約要求を受信するための第２受信ユニットをさらに含む。
【００２４】
例えば、前記第１受信ユニットは、前記参加者情報を含む操作要求を受信するためにも用いられる。
【００２５】
例えば、具体的には、前記通知ユニットは、前記参加者情報が判断特徴と異なるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【００２６】
例えば、具体的には、前記通知ユニットは、前記参加者情報が判断特徴と同等であるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【００２７】
例えば、具体的には、前記イベント通知ユニットは、持っている参加者情報が判断特徴と異なる参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【００２８】
例えば、具体的には、前記通知ユニットが、持っている参加者情報が判断特徴と同じである参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【００２９】
例えば、前記判断特徴は、識別子、ロール、識別子特徴とロール特徴の少なくとも一つを含む。
【００３０】
例えば、前記識別子は、予約者識別子、被予約者識別子、被通知者識別子、参加者識別子、予約者プリセット識別子、被予約者プリセット識別子、被通知者プリセット識別子と参加者プリセット識別子の少なくとも一つを含み、前記ロールは、予約者ロール、被予約者ロール、被通知者ロール、参加者ロール、予約者プリセットロール、被予約者プリセットロール、被通知者プリセットロールと参加者プリセットロールの少なくとも一つを含み、前記識別子特徴は、予約者識別子特徴、被予約者識別子特徴、被通知者識別子特徴、参加者識別子特徴、予約者プリセット識別子特徴、被予約者プリセット識別子特徴、被通知者プリセット識別子特徴と参加者プリセット識別子特徴の少なくとも一つを含み、前記ロール特徴は、予約者ロール特徴、被予約者ロール特徴、被通知者ロール特徴、参加者ロール特徴、予約者プリセットロール特徴、被予約者プリセットロール特徴、被通知者プリセットロール特徴と参加者プリセットロール特徴の少なくとも一つを含む。
【００３１】
本開示の実施例は、
前記いずれかの予約サービス装置である装置と、
前記予約サービス装置へ予約作成要求を送信するように配置される予約装置と、
前記予約サービス装置へ操作要求を送信するように配置される参加者装置と、
前記予約サービス装置からの通知を受信するように配置される被通知者装置と、
を含む、通知を行うためのシステムを提供する。
【００３２】
本開示の実施例は、通知を行う方法、装置及びシステムを提供し、特定の参加者に基づいて予約通知を実現する。具体的には、予約サービス側は、特定の参加者がイベント通知基準を満たすことを検知した後、被通知者へ通知メッセージを送信し、前記特定の参加者は、参加者情報が参加者識別子と参加者ロールの少なくとも一つを含む参加者である。このように、前記特定参加者に基づく通知サービスを実現し、ユーザ区別化の要求を満たす。
【００３３】
本開示の実施例又は従来技術の技術案をより明確に説明するために、以下、実施例の説明に必要となる図面を簡潔に説明する。以下説明する図面は明らかに本発明のいくつかの実施例に過ぎず、本開示を制限するためのものではない。当業者にとっては、創造的な作業を行わない前提で、これらの図面から他の図面を得ることもできる。
【図面の簡単な説明】
【００３４】
【図１】図１は、本開示の少なくとも一つの実施例に係る予約通知のためのシステムのハードウェアの模式的なブロック図である。
【図２】図２は、本開示の少なくとも一つの実施例に係る通知を行う方法のフローチャットである。
【図３】図３は、本開示の少なくとも一つの実施例に係る予約サービスのための装置の模式的なブロック図である。
【図４】図４は、本開示の少なくとも一つの実施例に係る予約通知の手順の模式図である。
【図５】図５は、本開示の少なくとも一つの実施例に係る予約通知の手順の模式図である。
【図６】図６は、本開示の少なくとも一つの実施例に係る予約通知の手順の模式図である。
【図７】図７は、本開示の少なくとも一つの実施例に係る例示的な予約リソースの構成模式図である。
【図８】図８は、本開示の少なくとも一つの実施例に係る通知を行う方法のフローチャットである。
【発明を実施するための形態】
【００３５】
本開示の目的、技術案と利点をより明確にするために、以下、実施例を挙げて本開示についてさらに詳細に説明する。説明する実施例は、明らかに本開示の一部の実施例に過ぎず、全ての実施例ではない。本開示における実施例に基づいて、当業者が創造的な労働を払わずに得られる全ての他の実施例も本開示が保護する範囲に属する。
【００３６】
現在、関連技術において、予約者が予約サービス側（被予約者または通知者とも呼ばれる）へ予約要求を送信する。該予約要求は、イベントが発生すると、予約サービス側がメッセージを被通知者に送信することを指示できる。予約者と被通知者は、同じエンティティでもよいし、異なるエンティティでもよい。イベント発生基準は、被予約リソース下に定義されている（例えば、被予約リソース下で＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースを作成し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソースのｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａパラメータにはイベント通知基準を含む）。イベント通知基準を満たす時、予約サービス側は被通知者へ通知を送信する。例えば、イベント通知基準のパラメータは、テーブル１に列挙されるパラメータを含むが、それらに限らない。
【００３７】
【表１】
2019531527.tif 000003
【００３８】
現在の予約仕組みは、参加するエンティティ（例えば、予約者、参加者、被通知者など）の異なる状況を考慮していない。実際の応用において、被通知者が特定の参加者に基づいて対応する動作を実行したい時（例えば、ある参加者がある操作を実行する時）、予約サービス側は、被通知者へメッセージを送信することができる。従来の予約通知の仕組みは、これらの方面の要求を満たせない。前記特定の参加者は、予約者、被予約者と被通知者以外のその他参加者と理解してもよい。該その他参加者は、更新、削除、作成などのような操作を実行できる。無論、前記参加者と、前記予約者、被予約者または被通知者と同じエンティティであってもよいし、異なるエンティティであってもよい。
【００３９】
本開示の実施例は、通知を行う方法、装置及びシステムを提供し、特定の参加者に基づいて通知、例えば予約を実現する。具体的には、予約サービス側が、特定の参加者を検知した後、被通知者へ通知メッセージを送信する。よって参加者に基づく通知サービスを実現し、ユーザ区別化の要求を満たす。
【００４０】
具体的には、本開示の実施例は、通知（Ｎｏｔｉｆｙ）を行う方法、装置及びシステムを提供し、特定の参加者に基づいて通知を実現する。具体的には、予約サービス側が、特定の参加者がイベント通知基準側を満たすことを検知した後、被通知者へ通知メッセージを送信する。例えば、予約サービス側が、特定の参加者情報がイベント通知基準を満たすことを検知した後、被通知者へ通知メッセージを送信する。
【００４１】
例えば、前記イベント通知基準はイベント通知条件（ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ ｃｏｎｄｉｔｉｏｎｓ）であり、イベント通知基準は、一つまたは複数のサブ条件を含むイベント通知基準セットであってもよい。参加者情報がイベント通知基準を満たすか否かを判断する時、参加者情報が前記サブ条件のいずれかを満たすか、または、全てのサブ条件を満たすかを判断することができる。
【００４２】
例えば、前記参加者情報は、参加者識別子、参加者ロール、参加者ロール特徴、参加者識別子特徴の少なくとも一つを含む。
【００４３】
このように、前記特定参加者に基づく通知サービスを実現し、ユーザ区別化の要求を満たす。
以下、予約を応用シナリオとして、予約手順における通知を行う方法、装置及びシステムを説明する。
【００４４】
図１は、本開示の実施例に係る通知を行うためのシステム１００のハードウェアの模式的なブロック図である。図１に示すように、システム１００は、予約デバイス１０１、参加者デバイス１０４、被通知者デバイス１０６及び予約サービスデバイス１５０（予約サービスデバイスは、通知を行う通知デバイスである）を含んでもよい。システム１００における各デバイスは、ネットワーク１６０によって接続可能である。システム１００の各デバイスの間は、直接または間接に相互通信でき、例えば、システム１００の各デバイスは、ネットワーク１６０によって、データ及び／又は信号を相互送受信できる。
【００４５】
ネットワーク１６０は、独立な機能を有する一般物の相互接続を実現できるネットワークであってもよい。ネットワーク１６０は、無線ネットワークであってもよく、無論、ネットワーク１６０は、有線ネットワークを含んでもよい。例えば、ネットワーク１６０は、インターネット及び／又は電気通信網に基づくインターネット・オブ・シングス（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）であってもよい。各ユーザは、電子タグを適用して一般物をインターネット・オブ・シングスに接続することができる。よって、インターネット・オブ・シングス上では、各一般物の具体位置を検出できる。インターネット・オブ・シングスにより、中央コンピュータを使用して各機器とデバイスに対して統括管理と制御を行うことができ、例えば、家庭のデバイス（例えば、スマート冷蔵庫、インテリジェント電子レンジなど）、車などの機器またはデバイスに対してリモート制御を行い、その位置を捜索することなどができる。
【００４６】
予約サービスデバイス１５０（すなわち、通知デバイス）は、プロセッサとメモリを備えるコンピュータ・デバイスであってもよい。例えば、予約サービスデバイス１５０は、サーバーであってもよい。無論、予約サービスデバイス１５０は、デスクトップ・コンピュータ、ノートパソコン、スマートフォン、タブレット型コンピュータ、その他プロセッサとメモリを含むデバイスであってもよい。図１は、予約サーバー１５０はプロセッサ１５２とメモリ１５４を含むことを示す。
【００４７】
プロセッサ１５２は、データ信号を処理でき、各種計算構成、例えば複合命令セットコンピュータ（ＣＩＳＣ）構成、縮小命令セット・コンピュータ（ＲＩＳＣ）構成または複数種類の命令セットの組み合わせを実施する構成、を含むことができる。いくつかの実施例において、プロセッサ１５２は、マイクロプロセッサ、例えばＸ８６プロセッサまたはＡＲＭプロセッサであってもよく、あるいは、デジタル・シグナル・プロセッサ（ＤＳＰ）などであってもよい。プロセッサ１５２は、所望の機能を実行するように、予約サービスデバイス１５０におけるその他コンポーネントを制御することができる。
【００４８】
メモリ１５４は、プロセッサ１５２が実行する命令及び／又はデータを保存することができる。例えば、メモリ１５４は、一つまたは複数のコンピュータ・プログラムプロダクトを含むことができ、前記コンピュータ・プログラムプロダクトは、各種形式のコンピュータ読み取り可能な記憶媒体、例えば揮発性メモリ及び／又は不揮発性メモリを含むことができる。前記揮発性メモリは、例えば、ランダム・アクセス・メモリ（ＲＡＭ）及び／又はキャッシュメモリ（ｃａｃｈｅ）などを含むことができる。前記不揮発性メモリは、例えば、読み取り専用メモリ（ＲＯＭ）、ハードディスク、フラッシュメモリなどを含むことができる。前記コンピュータ読み取り可能な記憶媒体には、一つまたは複数のコンピュータ・プログラム命令を記憶することができ、プロセッサ１５２は、下記の予約通知の機能及び／又はその他所望の機能を実現するように、前記プログラム命令を実行することができる。前記コンピュータ読み取り可能な記憶媒体には、各種アプリケーション・プログラムと各種データ、例えば前記アプリケーション・プログラムが使用及び／又は生成する各種データなどを記憶することもできる。
【００４９】
予約デバイス１０１は、プロセッサとメモリを含むコンピュータ・デバイスであってもよい。例えば、予約デバイス１０１は、テレビ、デスクトップ・コンピュータ、ノートパソコン、スマートフォン、タブレット型コンピュータ、ゲームコントローラー、音楽プレーヤ（例えばｍｐ３プレーヤなど）、その他プロセッサとメモリを含む端末（例えば、携帯端末、スマート・ターミナル）であってもよい。いくつかの実施例において、予約デバイス１０１は、プロセッサ、メモリ、及び例えばその他入力デバイスと出力デバイスなどその他部品を含むことができる。
【００５０】
参加者デバイス１０４は、プロセッサとメモリを含むコンピュータ・デバイスであってもよい。例えば、参加者デバイス１０４は、テレビ、インテリジェント家電機器、電気自動車、デスクトップ・コンピュータ、ノートパソコン、スマートフォン、タブレット型コンピュータ、その他プロセッサとメモリを含む端末（例えば、携帯端末、スマート・ターミナル）であってもよい。いくつかの実施例において、参加者デバイス１０４は、プロセッサ、メモリ、及び例えば入力デバイスと出力デバイスなどその他部品を含むことができる。
【００５１】
被通知者デバイス１０６は、プロセッサとメモリを含むコンピュータ・デバイスであってもよい。例えば、被通知者デバイス１０６は、テレビ、インテリジェント家電機器、電気自動車、デスクトップ・コンピュータ、ノートパソコン、スマートフォン、タブレット型コンピュータ、ゲームコントローラー、音楽プレーヤ（例えばｍｐ３プレーヤなど）、及びその他プロセッサとメモリを含む端末（例えば、携帯端末、スマート・ターミナル）であってもよい。いくつかの実施例において、被通知者デバイス１０６は、プロセッサ、メモリ、及び例えば入力デバイスと出力デバイスなどその他部品を含むことができる。
【００５２】
いくつかの実施例において、予約者と被通知者は、同じエンティティであってもよいし、異なるエンティティであってもよい。参加者と予約者は、同じエンティティであってもよいし、異なるエンティティであってもよい。同じエンティティであれば、該エンティティは予約者と参加者ロールを同時に有するエンティティであり、予約と第三者操作を同時に行うことができる。無論、予約者、被通知者と参加者は、互いに異なるエンティティであってもよい。
【００５３】
いくつかの実施例において、予約者は予約デバイス１０１を操作し、予約サービスデバイス１５０へ予約作成要求を送信する。曖昧さが発生しない場合、本開示の実施例に係る前記予約者は、予約デバイス１０１、操作予約デバイス１０１の予約者、あるいは下記の予約デバイス１０１に取付られている予約装置４０４を指してもよい。
【００５４】
操作者は参加者デバイス１０４を操作し、予約サービスデバイス１５０へ操作要求を送信することができる。無論、参加者デバイス１０４は、他人から干渉がない場合、自動的に予約サービスデバイス１５０へ操作要求を送信することもできる。曖昧さが発生しない場合、本開示の実施例に係る前記参加者は、参加者デバイス１０４、操作参加者デバイス１０４の操作者、あるいは下記の参加者デバイス１０４に取付られている参加者装置４０２を指してもよい。
【００５５】
被通知者は被通知デバイス１０６を操作することができ、例えば、被通知者は、被通知デバイス１０６により予約サービスデバイス１５０からの通知を読み取ることができる。曖昧さが発生しない場合、本開示の実施例に係る前記被通知者は、被通知デバイス１０６、被通知デバイス１０６を操作する被通知者、あるいは下記の被通知デバイス１０６に取付られている被通知者装置４０６を指してもよい。
【００５６】
サービス提供者は予約サービスデバイス１５０を操作し、被通知者へ通知を送信することができる。無論、予約サービスデバイス１５０は、他人から干渉がない場合、イベント通知基準を満たす時に自動的に被通知者へ通知を送信することもできる。曖昧さが発生しない場合、本開示の実施例に係る前記予約サービス側は、予約サービスデバイス１５０、予約サービスデバイス１５０を操作するサービス提供者、あるいは下記の予約サービスデバイス１５０に取付られている予約サービス装置３００（予約サービス装置は、通知を行う通知装置である）を指してもよい。
【００５７】
いくつかの実施例において、システム１００の各デバイスは、必要に応じて、表示装置（例えばＬＣＤ、ＯＬＥＤまたは投影装置）、入力装置（例えばタッチ装置、キーボード、マイクロホン、マウスなど）、スピーカまたは振動装置などを含んでもよい。
【００５８】
本開示の実施例は、予約シナリオにおいて通知を行う方法を提供し、図８に示すように、該方法は、
イベント通知基準を決定することを含むステップＳ１００１と、参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信することを含むステップＳ１００２と、前記参加者情報が前記イベント通知基準を満たす場合、被通知者へ通知を送信することを含むステップＳ１００３と、を含み、前記参加者情報は、参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール識別子の少なくとも一つを含む。
【００５９】
上記本開示の実施例に係る方法は、参加者情報、特に参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール識別子などの少なくとも一つの参加者情報とイベント通知基準のマッチング関係に基づいて通知を行うか否かを決定し、より多くのユーザまたは参加者の通知要求を満たす。
【００６０】
例えば、前記のイベント通知基準を決定することは、予約リソースまたはイベント通知基準セットから前記イベント通知基準を決定することを含んでもよい。
【００６１】
例えば、いくつかの実施例において、イベント発生基準が、予約リソース下に定義されている。すなわち、予約リソースにはイベント通知基準（すなわち、イベント通知条件、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ）を含み、一つの予約リソースは該リソース下のイベント通知基準に対応することができる。イベント通知基準を決定する時、前記予約リソースから前記イベント通知基準を決定することができる。例えば、前記予約リソースにおけるイベント通知基準を、決定する必要があるイベント通知基準として直接に選択する。
【００６２】
また、例えば、他のいくつかの実施例において、イベント通知基準は、予約リソースに含まれることではなく、予約リソース外のイベント通知基準セットの中に独立に設定されており、前記イベント通知基準セットは、一つまたは複数のイベント通知基準を含むことができる。イベント通知基準を決定する時、前記イベント通知基準セットから一つまたは複数のイベント通知基準を、決定する必要があるイベント通知基準として決定することができる。
【００６３】
予約リソースからイベント通知基準を決定することは、該イベント通知基準を含む前記予約リソースから該イベント通知基準を取得してもよいし、取得せずに予約リソースにおけるイベント通知基準を直接にマッチングしてもよい。無論、前記参加者情報を取得する時に該イベント通知基準を満たすか否かを判断するように、直接にイベント通知基準セットから一つまたは複数のイベント通知基準を取得してもよいし、イベント通知基準セットにおけるイベント通知基準を直接にマッチングしてもよい。
【００６４】
いくつかの実施形態において、前記予約リソースは、予約者が送信した予約リソース作成要求を受信した後、該予約リソース作成要求に対して作成した予約リソースであってもよい。例えばＡＥまたはＣＳＥより＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース作成要求を起こす時、対応する被予約者は、前記＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース作成要求に応じてイベント通知基準を含む予約リソースを作成する。予約者が送信した予約リソース要求を受信する時、該予約リソース要求のために、作成済みの予約リソースから該予約リソース要求とマッチングして対応する予約リソースを決定してもよい。
【００６５】
例えば、前記の前記イベント通知基準を決定することは、予約者が送信した予約要求を受信した後に行うことができる。例えば、参加者、予約者がＵＰＮＰ ＣＰで、被予約者がＵＰＮＰ Ｃｌｉｅｎｔで、被通知者がＵＰＮＰ Ｄｅｖｉｃｅである時、予約者は被予約者へ被予約者のＵＲＬ、サービス識別子及び被通知者のＵＲＬを持つ予約要求を送信し、被予約者が該予約要求を受信すると、該予約者に予約リソースをマッチングし、前記予約リソースは、予め配置したイベント通知基準に応じて決定することができ、その後、参加者は、被予約者へａｃｔｉｏｎ要求を送信し、被予約者が該ａｃｔｉｏｎ要求を受信する時、該ａｃｔｉｏｎ要求において参加者の情報（例えば参加者ＩＤ）を持っており、被予約者が該ａｃｔｉｏｎ要求を受信した後、該参加者情報が予め配置した通知基準を満たすか否かを判断する（例えば参加者のＩＤが該通知基準を満たすか否かを判断する）。該参加者情報が予め配置した通知基準を満たす場合、被通知者へ通知を送信する。
【００６６】
注意すべきなのは、本開示のいくつかの実施例において、前記参加者は、予約者、被予約者と被通知者以外のその他参加者と理解してもよい。
【００６７】
いくつかのインターネット・オブ・シングス通信プロトコル（例えばＭ２Ｍプロトコル）において、情報インターラクションの次元から、発信元（Ｏｒｉｇｉｎａｔｏｒ）と受信者（Ｒｅｃｅｉｖｅｒ）を定義した。要求を起こす側は、発信元（Ｏｒｉｇｉｎａｔｏｒ）と呼ばれ、発信元は、ＡＥ（アプリケイションエンティティ）またはＣＳＥ（公共サービスエンティティ）であってもよく、要求を受信する側は、受信者（Ｒｅｃｅｉｖｅｒ）と呼ばれ、受信者は、ＣＳＥであってもよい。
【００６８】
例えば、発信元が＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース作成要求を起こすと、発信元はリソース予約者となり、予約者（ｓｕｂｓｃｒｉｂｅｒ）と略称し、対応する受信者は被予約者となる。しかし、あるインターネット・オブ・シングスプロトコルにおいて、被予約者の定義がないため、Ｈｏｓｔｉｎｇ ＣＳＥを使用して被予約者を示す。また、例えば、発信元が登録要求を起こすと、発信元が登録者となり、対応する受信者が被登録者となる。
【００６９】
また、例えば、発信元が操作要求を起こすと、発信元が操作要求側（要求者と略称）となり、受信者が操作要求受信者となる。前記登録者、予約者、操作要求者は、同じエンティティが異なる動作を実行する時の異なるロールであってもよいし、異なる動作を実行する異なるエンティティであってもよい。本実施例において、前記参加者、予約者、被予約者、被通知者は、同じエンティティが異なる動作を実行する時の異なるロールであってもよいし、異なる動作を実行する異なるエンティティであってもよく、前記参加者は、登録要求を送信する場合、登録者となり、前記参加者は、操作要求を送信する場合、操作要求者となる。
【００７０】
参加者情報が前記イベント通知基準を満たすか否かを判断することはオプションであり、具体的には、前記参加者情報は特徴値（ｓｐｅｃｉｆｉｅｄ ｖａｌｕｅ）とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定することを含む。
【００７１】
例えば、前記特徴値は具体値であり、該具体値は、前記予約リソースに配置されてもよいし、前記予約リソース外に配置されてもよい。前記参加者情報がイベント通知基準を満たすと判断する時に前記予約リソースに提供する。前記具体値は、データタイプを指す値、データ構造を指す値、データコンテンツを指す値などであってもよく、例えば、該具体値は、識別子のコンテンツ特徴（例えば１１１１−２２）であってもよい。例えば、前記の前記参加者情報は特徴値（ｓｐｅｃｉｆｉｅｄ ｖａｌｕｅ）とマッチングするか否かを判断することは、該参加者情報は該特徴値と等しいか、該特徴値より大きいか、該特徴値より小さいか否かを判断することと、あるいは参加者情報の数は該特徴値の数より大きいか、該特徴値のデータと等しいか、該特徴値のデータより小さいか否かを判断することと、などを含み、応用シナリオによって、前記参加者情報と特徴値とをマッチングするマッチング方式を配置する。例えば、参加者数がある特定値を超える時に被通知者に通知したい場合、参加者の識別子数を判断するようにマッチング方式を配置し、該識別子数は該特定値より大きい場合、被通知者に通知するようにしてもよい。
【００７２】
なお、識別子は具体値であってもよく、具体的な数値、符号またはそれらの組み合わせであってもよい。例えばエンティティＡの識別子は１１１１−２２であり、エンティティＢ的識別子は２２２２−１１であり、識別子を比較すると、両方の識別子が異なる。
【００７３】
識別子特徴は識別子の特徴であり、識別子の構造特徴、及び／又は識別子のコンテンツ特徴であってもよい。例えばエンティティＡの識別子はＡＡＡＡ−ＡＡであり、エンティティＢの識別子はＡＡＡＡ−ＢＢであり、両方の識別子の構造がいずれもＸＸＸＸ−ＹＹの形式であるため、両方の構造特徴は同じである。識別子ＡＡＡＡ−ＡＡに単種類の文字Ａを含み、識別子ＡＡＡＡ−ＢＢは二種類の文字ＡとＢを含むため、これら二つの識別子の識別子コンテンツ特徴は異なることになる。
【００７４】
ロールとロール特徴も類似しており、ロールはロール自身を指し、ロール特徴はロールが備える特徴を指し、ここでは詳細な説明を省略する。
【００７５】
予約応用シナリオに基づいて、上述方法は、イベント通知基準を決定する前に、予約者が送信した予約要求を受信することをさらに含む。このようにすると、前記予約要求に基づいて、イベント通知基準を決定することができる。予約要求を受信した後、該予約要求に対応する予約リソースを決定でき、例えばローカルから予め用意した予約リソースを取得できるまたは予約リソースを作成できるため、通常、決定した予約リソースにイベント通知基準を含む。よって、前記イベント通知基準を決定する時、予約リソースからイベント通知基準を取得することができる。
【００７６】
以下、予約要求を受信した後に予約リソースを作成することを例として、本開示の実施例に係る通知を行う方法の具体的なフローを説明する。
【００７７】
図２は、本開示の上記の一つの実施例に係る通知を行う方法２００の模式的なフローチャットである。いくつかの実施例において、方法２００は、図２に示す一部または全てのステップ（例えば、ステップ２０２、２０４、２０６及び２０８の一部または全て）を含んでもよい。無論、方法２００は、その他図２に図示しないステップを含んでもよい。
【００７８】
ステップＳ２０２は、予約者からの予約作成要求（すなわち、予約リソース作成要求または＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース作成要求）を受信することを含む。
【００７９】
ステップＳ２０４は、イベント通知基準を含む予約リソースを作成することを含む。
【００８０】
ステップＳ２０６は、参加者情報が前記イベント通知基準を満たすか否かを判断し、前記参加者情報は、参加者識別子（ｉｄｅｎｔｉｆｉｅｒ、ＩＤ）、参加者ロール、参加者識別子特徴、参加者ロール特徴の少なくとも一つを含む。
【００８１】
ステップＳ２０８は、前記参加者情報が前記イベント通知基準を満たす場合、被通知者へ通知を送信し、ＮＯの場合、フローを終了することを含む。
【００８２】
前記方法２００は、
被予約者が予約リソースを作成した後、被予約者が前記参加者情報を含む操作要求を受信すること、あるいは、被予約者が前記参加者情報を含む登録要求を受信することをさらに含む。具体的には、前記操作要求は、前記参加者（すなわち、操作要求者）からの操作要求であり、前記登録要求は、前記登録者からの登録要求である。実際のシナリオにおいて、監視が必要となるのは登録者、被登録者と被通知者以外のその他デバイスの操作状況であることを考慮すると、被予約者は、参加者からの操作要求を受信する時、前記操作要求に持つ参加者情報（例えば操作要求者のＩＤ、この際に参加者は操作要求者となる）に応じて、前記イベント通知基準を満たすか否かを判断するように配置されることができる。
【００８３】
実際のシナリオにおいて、新たなデバイスが登録を行うか否かを把握する必要があることを考慮すると、被予約者は、登録者からの登録要求を受信する時、前記登録要求に持つ参加者情報（例えば登録者のＩＤ、この際に参加者は登録者となる）に応じて、前記イベント通知基準を満たすか否かを判断するように配置されることができる。
【００８４】
いくつかのインターネット・オブ・シングスプロトコル（例えばＭ２Ｍプロトコル）において、前記登録者と前記予約者は、同一エンティティが異なる動作を実行する時の異なるロールであってもよい。
【００８５】
例えば、ある特定エンティティＡ（登録者）がエンティティＢ（被登録者）へ登録要求を起こして登録成功後、エンティティＡはエンティティＢへ予約リソース作成要求を送信することができ、この際にエンティティＡは予約者であり、エンティティＢは被予約者であり、エンティティＢはエンティティＡのために予約リソースを作成すれば、予約が成功となる。
【００８６】
例えば、エンティティＡはエンティティＢへ登録要求と予約リソース作成要求を送信し、登録成功かつ予約成功後、さらにエンティティＤはエンティティＢへ登録する時、前記エンティティＤのＩＤは既に登録したデバイスのＩＤと等しいか否かを判断することができ、すなわち、エンティティＤのＩＤはエンティティＡのＩＤ（この際に、エンティティＡのＩＤが特徴値、ｓｐｅｃｉｆｉｅｄ ｖａｌｕｅである）と等しいか否かを判断し、等しくない場合、被通知者に新たなデバイス登録があることを通知する。
【００８７】
また、例えば、エンティティＡがエンティティＢへ登録要求と予約リソース作成要求を送信し、登録成功かつ予約成功後、エンティティＣはエンティティＢへ登録要求を送信して登録成功後、またエンティティＢへ操作要求を送信する時、前記エンティティＣの操作要求に持つＩＤは１０（この際に数値１０は特徴値、ｓｐｅｃｉｆｉｅｄ ｖａｌｕｅである）より大きいか否かを判断し、１０より大きい場合、被通知者に１０個のデバイスが操作動作の実行を要求することを通知することができる。
【００８８】
さらに、操作要求を受信した後、被予約者が前記参加者へ前記操作要求の応答を送信し、または前記登録者へ前記登録要求の応答を送信する。
【００８９】
例えば、前記操作要求は、作成要求、取得要求、更新要求、削除要求またはその他タイプの要求であってもよい。前記操作要求は、前記参加者の情報（参加者情報と略称）を含むことができる。例えば、前記参加者情報は、参加者識別子（ｉｄｅｎｔｉｆｉｅｒ、ＩＤ）、参加者ロール、参加者識別子特徴、参加者ロール特徴の少なくとも一つを含む。
【００９０】
いくつかの実施例において、全ての参加者は、ロールまたはロール特徴に応じて分類することができる。参加者情報が参加者ロールであることを例として、全ての参加者を管理者、一般ユーザ、ＶＩＰユーザ、その他ユーザなどのカテゴリーに分けることができる。前記参加者ロールは、該参加者は管理者、一般ユーザ、ＶＩＰユーザまたはその他ユーザであることを示す。該参加者のロール特徴は該ユーザの身分となる。
【００９１】
いくつかの実施例において、各参加者識別子はアプリケイションエンティティ識別子（ａｐｐｌｉｃａｔｉｏｎ ｅｎｔｉｔｙ ＩＤ、ＡＥ−ＩＤ）、公共サービスエンティティ識別子（ｃｏｍｍｏｎ ｓｅｒｖｉｃｅ ｅｎｔｉｔｙ ＩＤ、ＣＳＥ−ＩＤ）またはリソース識別子（ｒｅｓｏｕｒｃｅ ＩＤ）などの一つであってもよい。前記参加者識別子は、該参加者がアプリケイションエンティティ識別子、公共サービスエンティティ識別子またはリソース識別子であること、及びその具体的な番号を記録する。例えば、前記参加者識別子は１２３４ＡＢＣである。
【００９２】
いくつかの実施例において、参加者情報は参加者識別子特徴であってもよく、例えば、参加者識別子が１２３４ＡＢＣである場合、その識別子特徴は四桁連続の数字+三桁連続のアルファベットである。
【００９３】
いくつかの実施例において、ステップＳ２０４では、前記予約リソースを作成することは、前記予約リソース作成要求に応答し、前記予約リソースを作成ことと、前記予約リソースのイベント通知基準を設定することを含む。例えば、イベント通知基準の判断特徴（この際に前記判断特徴は前記特徴値であり、すなわちｓｐｅｃｉｆｉｅｄ ｖａｌｕｅである）を設定することができる。判断特徴は、識別子、ロール、識別子特徴とロール特徴の少なくとも一つを含むことができる。前記識別子は、予約者識別子、被予約者識別子、被通知者識別子、参加者識別子、予約者プリセット識別子、被予約者プリセット識別子、被通知者プリセット識別子と参加者プリセット識別子の少なくとも一つを含むことができる。前記ロールは、予約者ロール、被予約者ロール、被通知者ロール、参加者ロール、予約者プリセットロール、被予約者プリセットロール、被通知者プリセットロール及び参加者プリセットロールの少なくとも一つを含むことができる。前記識別子特徴は、予約者識別子特徴、被予約者識別子特徴、被通知者識別子特徴、参加者識別子特徴、予約者プリセット識別子特徴、被予約者プリセット識別子特徴、被通知者プリセット識別子特徴と参加者プリセット識別子特徴の少なくとも一つを含むことができる。前記ロールは、予約者ロール特徴、被予約者ロール特徴、被通知者ロール特徴、参加者ロール特徴、予約者プリセットロール特徴、被予約者プリセットロール特徴、被通知者プリセットロール特徴及び参加者プリセットロール特徴の少なくとも一つを含むことができる。
【００９４】
例えば、判断特徴を予約者識別子、プリセット識別子または被通知者識別子に設定することができる。また、例えば、判断特徴を予約者ロール、プリセットロールまたは被通知者ロールに設定することができる。また、例えば、判断特徴は、予約者識別子および予約者ロール、あるいは、予約者プリセット識別子および予約者プリセットロール、あるいは、被通知者識別子および被通知者ロールを含むことができる。無論、判断特徴は、その他特徴値に設定してもよいが、本開示はこれを限定しない。
【００９５】
ステップＳ２０６には、いくつかの実施例において、前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、前記参加者情報は判断特徴と異なるか否かを判断することと、前記参加者情報は前記判断特徴と異なる場合、前記参加者情報が前記イベント通知基準を満たすと決定することとを含む。
【００９６】
例えば、判断特徴は予約者識別子であってもよく、前記参加者識別子は前記予約者識別子と異なるか否かを判断し、前記参加者識別子は前記予約者識別子と異なる（例えば、参加者ＩＤ≠予約者ＩＤ）場合、前記参加者情報が前記イベント通知基準を満たすと判断することができる。前記予約者識別子は、予約者からの予約作成要求から取得することができる。
【００９７】
また、例えば、判断特徴は予約者ロールであってもよく、前記参加者ロールは前記予約者ロールと異なるか否かを判断し、前記参加者ロールは前記予約者ロールと異なる（例えば、参加者ロール≠予約者ロール）場合、前記参加者情報が前記イベント通知基準を満たすと判断することができる。前記予約者ロールは、予約者からの予約作成要求から取得することができる。
【００９８】
ステップＳ２０６において、他のいくつかの実施例において、前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、前記参加者情報は判断特徴と同じか否かを判断することと、前記参加者情報は前記判断特徴と同じである場合、前記参加者情報が前記イベント通知基準を満たすと決定することとを含む。
【００９９】
例えば、判断特徴はプリセット識別子であってもよく、前記参加者識別子は前記プリセット識別子と同じか否かを判断し、前記参加者識別子は前記プリセット識別子と同じ（例えば、参加者ＩＤ=プリセットＩＤ）である場合、前記参加者情報が前記イベント通知基準を満たすと判断する。
【０１００】
また、例えば、判断特徴はプリセットロールであってもよく、前記参加者ロールは前記プリセットロールと同じか否かを判断し、前記参加者ロールは前記プリセットロールと同じ（例えば、参加者ロール=プリセットロール）である場合、前記参加者情報が前記イベント通知基準を満たすと判断する。
【０１０１】
ステップＳ２０６には、前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、持っている参加者情報は判断特徴と異なる参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、をさらに含むことができる。
【０１０２】
いくつかの実施例において、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数が第１閾値以上であるか否かを判断することと、前記参加者の数が前記第１閾値以上である場合、前記参加者の数が前記イベント通知基準を満たすと決定することと、を含む。
【０１０３】
例えば、参加者は、ロール（管理者、一般ユーザ、ＶＩＰユーザ、その他ユーザ等）に応じて分類を行うことができる。前記判断特徴がロールにおけるＶＩＰユーザに設定され（すなわち、判断特徴が「ＶＩＰユーザ」に設定される）、第１閾値が１５に設定されるとする。予約サービス装置３００へ操作要求を送信する、“ＶＩＰユーザ”ロールを有する参加者の数が１５以上である時（すなわち、「ＶＩＰユーザ」ロールを有する参加者の数≧第１閾値１５）、イベント通知基準を満たすため、被通知者へ通知を送信することができる。
【０１０４】
他のいくつかの実施例には、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数は第２閾値以下であるか否かを判断することと、前記参加者の数は前記第２閾値以下である場合、前記参加者の数が前記イベント通知基準を満たすと決定することと、を含む。
【０１０５】
例えば、前記判断特徴がロールにおけるＶＩＰユーザに設定され（すなわち、判断特徴が「ＶＩＰユーザ）に設定される）、第２閾値が２５に設定されるとする。予約サービス装置３００へ操作要求を送信する、「ＶＩＰユーザ」ロールを有する参加者の数は２５以下である時（すなわち、「ＶＩＰユーザ」ロールを有する参加者の数≦第２閾値２５）、イベント通知基準を満たすため、被通知者へ通知を送信することができる。
【０１０６】
さらに他の実施例には、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数は第１閾値以上かつ第２閾値以下であるか否かを判断することと、前記参加者の数は前記第１閾値以上かつ前記第２閾値以下である場合、前記参加者の数が前記イベント通知基準を満たすと決定することと、を含む。
【０１０７】
例えば、前記判断特徴がロールにおけるＶＩＰユーザに設定され（すなわち、判断特徴が「ＶＩＰユーザ」に設定される）、第１閾値が１５に設定され、第２閾値が２５に設定されるとする。予約サービス装置３００へ操作要求を送信する「ＶＩＰユーザ」ロールを有する参加者の数は１５以上かつ２５以下である時（すなわち、第１閾値１５≦「ＶＩＰユーザ」ロールを有する参加者の数≦第２閾値２５）、イベント通知基準を満たすため、被通知者へ通知を送信することができる。
【０１０８】
あるいは、ステップＳ２０６には、前記参加者情報が前記イベント通知基準を満たすか否かを判断することは、持っている参加者情報は判断特徴と同じである参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定することと、を含む。例えば、前記参加者の数が前記イベント通知基準を満たすか否かを判断することは、前記参加者の数は第３閾値以上であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数は第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、あるいは、前記参加者の数は第３閾値以上かつ第４閾値以下であるか否かを判断し、ＹＥＳの場合、前記参加者の数が前記イベント通知基準を満たすと決定すること、を含む。
【０１０９】
なお、前記イベント通知基準は、前記第１閾値、第２閾値、第３閾値及び／又は第４閾値を含むことができる。前記イベント通知基準を設定すると同時に前記第１閾値、第２閾値、第３閾値及び／又は第４閾値を設定することができる。無論、前記第１閾値、第２閾値、第３閾値及び／又は第４閾値の具体的な数値は、予約者、予約サービス側または被通知者によって設定されることができ、本開示はこれを限定しない。
【０１１０】
本開示の実施例は、
予約者からの予約要求を受信し、イベント通知基準を取得することと、
参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信することと、
を含む、さらに別な通知を行う方法を提供する。
さらに、前記方法は、前記予約要求を受信した後、前記イベント通知基準を含む予約リソースを作成または直接取得することをさらに含む。
イベント通知基準を取得することは、前記予約リソースに含まれるイベント通知基準を取得することを含む。
【０１１１】
例えば、前記参加者は登録者を含み、前記方法は、前記登録者から前記参加者情報を含む登録要求を受信することをさらに含む。あるいは、前記参加者は要求者を含み、前記方法は、前記第三者参加者からの操作要求を受信することをさらに含む。
【０１１２】
例えば、前記参加者情報は、参加者識別子、参加者識別子特徴、参加者ロール、参加者ロール識別子の少なくとも一つを含む。
【０１１３】
図３は、本開示の実施例に係る予約サービス装置３００の模式的なブロック図である。該予約サービス装置３００は、被通知者へ通知を行うために用いられ、イベント通知基準を決定ための決定ユニット３１０と、参加者情報が前記イベント通知基準を満たすか否かを判断し、ＹＥＳの場合、被通知者へ通知を送信するための通知ユニット３２０を含み、前記参加者情報は、参加者識別子、参加者識別子特徴、及び参加者ロール、参加者ロール特徴識別子の少なくとも一つを含む。
【０１１４】
例えば、決定ユニット３１０は、具体的には、予約リソースまたはイベント通知基準セットから前記イベント通知基準を決定するために用いられてもよい。
【０１１５】
例えば、前記予約サービス装置３００は、前記イベント通知基準を含む予約リソースを作成するための予約リソース作成ユニット３３０をさらに含む。
【０１１６】
例えば、前記予約サービス装置３００は、予約リソースを作成する前に、予約者が送信した予約リソース作成要求を受信するための第１受信ユニット３４０をさらに含む。
【０１１７】
例えば、前記通知ユニット３２０は、具体的には、前記参加者情報は特徴値とマッチングするか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【０１１８】
例えば、前記予約サービス装置３００は、前記イベント通知基準を決定するように、予約者が送信した予約要求を受信するための第２受信ユニット３５０をさらに含む。
【０１１９】
例えば、前記第１受信ユニット３４０は、前記参加者情報を含む操作要求を受信することにも用いられる。
【０１２０】
例えば、前記通知ユニット３２０は、具体的には、前記参加者情報は判断特徴と異なるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられてもよい。
【０１２１】
例えば、前記通知ユニット３２０は、具体的には、前記参加者情報は判断特徴と同等であるか否かを判断し、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【０１２２】
また、例えば、前記通知ユニット３２０は、具体的には、持っている参加者情報は判断特徴と異なる参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、前記参加者の数が前記イベント通知基準を満たす場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【０１２３】
あるいは、前記通知ユニット３２０は、具体的には、持っている参加者情報は判断特徴と同じである参加者の数を統計することと、前記参加者の数が前記イベント通知基準を満たすか否かを判断することと、ＹＥＳの場合、前記参加者情報が前記イベント通知基準を満たすと決定し、被通知者へ通知を送信するために用いられる。
【０１２４】
例えば、前記判断特徴は識別子、ロール、識別子特徴とロール特徴の少なくとも一つを含む。例えば、前記判断特徴は特徴値のあるタイプである。
【０１２５】
例えば、前記識別子は、予約者識別子、被予約者識別子、被通知者識別子、参加者識別子、予約者プリセット識別子、被予約者プリセット識別子、被通知者プリセット識別子及び参加者プリセット識別子の少なくとも一つを含み、前記ロールは、予約者ロール、被予約者ロール、被通知者ロール、参加者ロール、予約者プリセットロール、被予約者プリセットロール、被通知者プリセットロールと参加者プリセットロールの少なくとも一つを含み、前記識別子特徴は、予約者識別子特徴、被予約者識別子特徴、被通知者識別子特徴、参加者識別子特徴、予約者プリセット識別子特徴、被予約者プリセット識別子特徴、被通知者プリセット識別子特徴と参加者プリセット識別子特徴の少なくとも一つを含み、前記ロール特徴は、予約者ロール特徴、被予約者ロール特徴、被通知者ロール特徴、参加者ロール特徴、予約者プリセットロール特徴、被予約者プリセットロール特徴、被通知者プリセットロール特徴と参加者プリセットロール特徴の少なくとも一つを含む。
【０１２６】
予約サービス装置３００の各ユニットは、図２に示す方法２００の機能またはステップを実行するように配置されることができ、本開示には詳細な説明を省略する。例えば、予約サービス装置３００の各ユニットは、図１に示す予約サービスデバイス１５０におけるプロセッサ１５２がメモリ１５４に記憶されているプログラム命令を実行することで実現されることができるとともに、方法２００における各ステップ、およびその他図２に図示しないステップを実行することができる。
【０１２７】
本開示の実施例は、上記の予約サービス装置３００と、前記予約サービス装置へ予約作成要求を送信し前記予約サービス装置から前記予約作成要求の応答を受信するように配置される予約装置と、前記予約サービス装置へ操作要求を送信し前記予約サービス装置から前記操作要求の応答を受信するように配置される参加者装置と、前記予約サービス装置からの通知を受信するように配置される被通知者装置と、を含む、予約を通知するシステムを提供する。
【０１２８】
前記予約サービス装置３００は、予約サービスデバイス１５０に設定されることができ、前記予約装置は、前記予約デバイス１０１に設定されることができ、前記参加者装置は、参加者デバイス１０４に設定されることができ、前記被通知者装置は、被通知者デバイス１０６に設定されることができる。
【０１２９】
図４は、本開示の実施例に係る予約通知の手順の模式図である。
【０１３０】
まず、予約装置４０４は、予約サービス装置３００へ予約リソース作成要求を送信し（ステップ４１０）、例えば、ｃｒｅａｔｅ ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞要求を送信する。前記予約リソース作成要求は、予約者情報（例えば、予約者識別子、予約者ロールなど）を含むことができる。前記予約作成要求に応答し、予約サービス装置３００が前記予約リソースを作成し、具体的には、被予約リソース下で＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞を作成し、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞はｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａを含み、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａはｆｉｘｅｄＩＤパラメータを含む。例えば、前記予約リソースは、イベント通知基準ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａを含む（ステップ４１２）。
【０１３１】
予約サービス装置３００は、予約装置４０４へ予約作成要求の応答を送信する（ステップ４１４）。
【０１３２】
参加者装置４０２は、予約サービス装置３００へ操作要求、例えば、ｃｒｅａｔｅ、ｒｅｔｒｉｅｖｅ、ｕｐｄａｔｅ、ｄｅｌｅｔｅなどの操作の要求を送信する（ステップ４１６）。該操作要求は、参加者情報（例えば、参加者識別子または参加者ロールなど）を含むことができる。
【０１３３】
予約サービス装置３００は、参加者装置４０２へ操作要求の応答を送信する（ステップ４１８）。
【０１３４】
予約サービス装置３００は、参加者情報が前記イベント通知基準を満たすか否かを判断する。例えば、予約サービス装置３００は、前記参加者情報は判断特徴と異なるか否かを判断する（ステップ４２０）。前記参加者情報は前記判断特徴と異なる場合、予約サービス装置３００は、前記参加者情報が前記イベント通知基準を満たすと判断する（ステップ４２２）。予約サービス装置３００は、前記被通知者装置４０６へ通知を送信する（ステップ４２４）。被通知者装置４０６は、予約サービス装置３００へ該通知に対する応答を送信する（ステップ４２６）。
【０１３５】
例えば、予約サーバーは、操作要求を受信した後、例えば、ＡＥ−ＩＤ、ＣＳＥ−ＩＤまたはｒｅｓｏｕｒｃｅＩＤなどを含む、操作要求送信者のＩＤを検知し、予約リソースプリセットｆｉｘｅｄＩＤと比較し、同じであれば、通知（Ｎｏｔｉｆｙ）を被通知者に送信する。被通知者の通知に対する応答を受信する。
【０１３６】
図５は、本開示の実施例に係る他の予約通知の手順の模式図である。
【０１３７】
まず、予約装置４０４は、予約サービス装置３００へ予約リソース作成要求を送信し（ステップ５１０）、すなわち、予約者は、被予約者へ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞作成要求を送信する。前記予約作成要求に応答し、予約サービス装置３００は、前記予約リソースを作成し、具体的には、被予約リソース下でロール数（ｒｏｌｅＮｒ）パラメータを含む＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞サブリソースを作成し、ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａパラメータは、比較パラメータ（すなわち、ｒｏｌｅＮｒＢｉｇｇｅｒ、ｒｏｌｅＮｒＳｍａｌｌｅｒサブパラメータ）を含む。
【０１３８】
例えば、前記予約リソースは、イベント通知基準ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａを含む（ステップ５１２）。予約サービス装置３００は、予約装置４０４へ予約作成要求の応答を送信し（ステップ５１４）、すなわち、被予約者は、予約者へ＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞作成要求の応答を送信する。参加者装置４０２は、予約サービス装置３００へ操作要求を送信し（ステップ５１６）、例えば、参加者は、被予約者へｃｒｅａｔｅ／ｒｅｔｒｉｅｖｅ／ｕｐｄａｔｅ／ｄｅｌｅｔｅのいずれかの要求を送信する。予約サービス装置３００は、参加者装置４０２へ操作要求の応答を送信し（ステップ５１８）、例えば、被予約者は、参加者へｃｒｅａｔｅ／ｒｅｔｒｉｅｖｅ／ｕｐｄａｔｅ／ｄｅｌｅｔｅのいずれかの要求の応答を送信する。
【０１３９】
予約サービス装置３００は、参加者情報が前記イベント通知基準を満たすか否かを判断する。例えば、予約サービス装置３００は、前記参加者情報は判断特徴と同じか否かを判断する（ステップ５２０）。前記参加者情報は前記判断特徴と同じである場合、予約サービス装置３００は、前記参加者情報が前記イベント通知基準を満たすと判断する（ステップ５２２）。予約サービス装置３００は、前記被通知者装置４０６へ通知を送信する（ステップ５２４）。被通知者装置４０６は、予約サービス装置３００へ該通知に対する応答を送信する（ステップ５２６）。
【０１４０】
例えば、被予約者は、要求を受信した後、ｒｏｌｅＩＤと保持しているｒｏｌｅＩＤが異なると検知する時、ロール数をプラス１し（すなわち、＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞／ｒｏｌｅＮｒをプラス１する）、その後、ロール数は第１比較パラメータより大きいか否かを判断し（すなわち、ｒｏｌｅＮｒはｒｏｌｅＮｒＢｉｇｇｅｒより大きいか否かを判断する）、あるいは、ロール数は第２比較パラメータより小さいか否かを判断し（すなわち、ｒｏｌｅＮｒはｒｏｌｅＮｒＳｍａｌｌｅｒより小さいかを判断する）、ＹＥＳの場合、被予約者は被通知者へＮｏｔｉｆｙ要求を送信し、被通知者は被予約者へＮｏｔｉｆｙ応答を送信する。
【０１４１】
図６は、本開示の実施例に係るさらに他の予約通知の手順の模式図である。まず、予約装置４０４は、予約サービス装置３００へ予約リソース作成要求を送信する（ステップ６１０）。前記予約リソース作成要求に応答し、予約サービス装置３００は、イベント通知基準を含む前記予約リソースを作成する（ステップ６１２）。予約サービス装置３００は、予約装置４０４へ予約作成要求の応答を送信する（ステップ６１４）。
【０１４２】
参加者装置４０２は、予約サービス装置３００へ操作要求を送信する（ステップ６１６）。該操作要求は、参加者情報（例えば、参加者識別子または参加者ロールなど）を含むことができる。予約サービス装置３００は、参加者装置４０２へ操作要求の応答を送信する（ステップ６１８）。
【０１４３】
予約サービス装置３００は、参加者情報が前記イベント通知基準を満たすか否かを判断する。例えば、予約サービス装置３００は、持っている参加者情報は判断特徴と異なる参加者の数を統計する（ステップ６１９）。例えば、予約サービス装置３００にアクセスする全ての参加者において、予約サービス装置３００は、持っている参加者情報は判断特徴と異なる参加者の数を記録するが、持っている参加者情報は判断特徴と同じであるその他参加者の数は対象外となる。予約サービス装置３００は、前記参加者の数が前記イベント通知基準を満たすか否かを判断する（ステップ６２０）。前記参加者の数が前記イベント通知基準を満たす場合、予約サービス装置３００は、前記参加者情報が前記イベント通知基準を満たすと決定する（ステップ６２２）。予約サービス装置３００は、前記被通知者装置４０６へ通知を送信する（ステップ６２４）。被通知者装置４０６は、予約サービス装置３００へ該通知に対する応答を送信する（ステップ６２６）。
【０１４４】
予約通知の例は下記通りである。例えば、予約者は、家族のエネルギー消費（例えば電力量）を管理するように、予約デバイス１０１（または予約装置４０４）により予約サービス装置３００（例えば、エネルギー管理プラットフォーム）へエネルギー通知サービスを予約する。予約者家族の家電機器はいずれも参加者デバイス１０４となることができ、いずれも予約サービスデバイス１５０におけるエネルギー管理プラットフォームへ登録することができ、登録する目的の一つは、ユーザ端末がエネルギー管理プラットフォームにより家電機器を制御および管理できるようにすることである。登録完了後、予約者は、予約デバイス１０１により予約サービス装置３００（例えば、エネルギー管理プラットフォーム）へエネルギー通知サービスを予約することができる。該予約の通知サービスは、１晩で１０台以上の家電機器が電力量を消費した場合、別の家族メンバー（予約者と異なる被通知者）へエネルギー消費通知を送信することである。家電機器は電力量を消費した後にエネルギー管理プラットフォームへ更新要求を送信し、エネルギー管理プラットフォーム上の対応するリソースの数値を変更するよう要求するため、１晩で第１０台以上家電機器がエネルギー管理プラットフォーム上のリソース数値を変更する時、エネルギー管理プラットフォームは、家族メンバー（被通知者）に通知することになる。
【０１４５】
図７は、本開示の実施例に係る例示的な予約リソースの構造模式図である。参加者は被予約者へ登録した後、コンテナリソース（＜ｃｏｎｔａｉｎｅｒ＞リソース）を含むアプリケイションエンティティリソース（図７に示す＜ＡＥ＞リソース）を生成する。コンテナリソースは、情報コンテンツを保存できるコンテンツ実例リソース（図７に示す＜ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅ＞）を含む。
【０１４６】
予約者は被予約者へ予約要求を送信する時（例えば、該要求は、アプリケイションエンティティリソース＜ＡＥ＞を予約するよう指示する）、被予約者は、アプリケイションエンティティリソース／コンテナリソース下で（すなわち、図７における＜ＡＥ＞／＜ｃｏｎｔａｉｎｅｒ＞リソース下で）予約リソース（すなわち、図７における＜ｓｕｂｓｃｒｉｐｔｉｏｎ＞リソース）を作成する。該予約リソースは、イベント通知基準（ｅｖｅｎｔＮｏｔｉｆｉｃａｔｉｏｎＣｒｉｔｅｒｉａ），被通知者アドレス（ｎｏｔｉｆｉｃａｔｉｏｎＵＲＩ）、グループ識別子（ｇｒｏｕｐＩＤ）、通知転送アドレス（ｎｏｔｉｆｉｃａｔｉｏｎＦｏｒｗａｒｄｉｎｇＵＲＩ）、予約者アドレス（ｓｕｂｓｃｒｉｂｅｒＵＲＩ）などを含む。予約リソースは、その他図７に示さないコンテンツ項目を含んでもよいが、本開示はこれを限定しない。
【０１４７】
本開示の実施例に係る通知を行う方法、装置及びシステムは、特定の参加者に基づいて予約通知を実現する。予約サービス側で特定の参加者を検知した後、被通知者へ通知メッセージを送信し、参加者に基づく通知サービスを実現し、ユーザ区別化の要求を満たす。
【０１４８】
本書では、第１と第２などのような関係用語は、あるエンティティまたは操作を別のエンティティまたは操作を区別するだけのために用いられ、必ずしもこれらのエンティティまたは操作の間であらゆるこの実際的な関係または順番が存在することを求めるまたは暗示することはない。それに、用語“含む”、“備える”あるいはそれらのあらゆる変形は、排他性のない「含むこと」を意味し、よって一連要素を含む手順、方法、物品またはデバイスは、それらの要素だけではなく、明確に列挙されないその他要素も含み、あるいは、この手順、方法、物品またはデバイスが固有の要素も含む。さらに多くの制限がない場合、“一つの……を含む”という表現で限定される要素は、前記一つの要素を含む手順、方法、物品またはデバイスには他にも同じ要素を含むことを除外しない。
【０１４９】
当業者は、本開示の趣旨及び範囲を逸脱することなく本開示に対して様々な修正及び変更を行うことができることは明らかである。したがって、本開示のこれらの修正及び変更は特許請求の範囲及びその同等技術の範囲に属す場合、本開示もこれらの修正及び変更を含むことを意図する。
【０１５０】
上記は本開示の具体的な実施形態に過ぎず、本開示の保護範囲はこれに限らず、任意の当業者は、本開示が開示した技術範囲内で、容易に想到できる変更または置換は、全て本開示の保護範囲にあるべきである。よって、本開示の保護範囲は前記請求項の保護範囲に従うべきである。
【０１５１】
本開示は、２０１６年７月２９日に出願した中国特許出願第２０１６１０６１７８６８.５号と２０１６年８月１２日に出願した中国特許出願第２０１６１０６６５７３１.７号の優先権を主張し、上記中国特許出願が開示した内容は、全て本開示の一部として取り込まれる。
【符号の説明】
【０１５２】
１０１  予約デバイス
１０４  参加者デバイス
１０６  被通知者デバイス
１５０  予約サービスデバイス
１５２  プロセッサ
１５４  メモリ
１６０  ネットワーク
３００  予約サービス装置
３３０  予約リソース作成ユニット
３２０  イベント通知ユニット
３４０  第１受信ユニット
３５０  第２受信ユニット
４０２  参加者装置
４０４  予約装置
４０６  被通知者装置。
【図１】
2019531527.tif 000004
【図２】
2019531527.tif 000005
【図３】
2019531527.tif 000006
【図４】
2019531527.tif 000007
【図５】
2019531527.tif 000008
【図６】
2019531527.tif 000009
【図７】
2019531527.tif 000010
【図８】
2019531527.tif 000011
【国際調査報告】
2019531527.tif 000012
2019531527.tif 000013
2019531527.tif 000014
2019531527.tif 000015