(例如，实体2)可以独立于请求发起方(例如，实体1)的订阅请求或者由于具有能够改变通 知接收方(例如，实体3)的配置的权限的另一实体而具有能够向通知接收方(例如，实体3) 发送通知的权限。例如，当仅应用方法1时，如果托管实体(例如，实体2)具有能够向通知接 收方(例如，实体3)发送通知的权限，则托管实体(例如，实体2)可以向通知实体(例如，实体 3)发送通知。然而，例如，由于具有能够改变通知接收方(例如，实体3)的配置的权限的另一 实体(例如，实体4 )，托管实体(例如，实体2)可以获得能够向通知接收方(例如，实体3)发送 通知的权限。因此，请求发起方(例如，实体1)有可能在没有许可的情况下，使用通过另一实 体(例如，实体4)的请求而获得的权限。在这种情况下，有必要具有一种使托管实体(例如， 实体2)拒绝对应的请求的方法。
[0187] 为了解决上述问题，在根据本发明的方法2中增加托管实体(例如，实体2)验证请 求发起方(例如，实体1)是否具有针对通知接收方(例如，实体3)的权限（或访问权限）的过 程。如果请求发起方（例如，实体1)不具有针对通知接收方（例如，实体3)的权限（访问权 限），则托管实体(例如，实体2)拒绝从请求发起方(例如，实体1)接收的订阅请求并且能够 向请求发起方(例如，实体1)发送包括失败结果的响应消息。相反，如果请求发起方(例如， 实体1)具有针对通知接收方(例如，实体3)的权限(访问权限），则托管实体(例如，实体2)准 许订阅请求并且能够向请求发起方(例如，实体1)发送包括成功结果的响应消息。
[0188] 作为另一个示例，能够验证通知接收方(例如，实体3)是否具有代表另一实体配置 订阅以便接收通知的权限。
[0189] 图16示出了根据本发明的订阅和通知过程的示例。如果必要，能够同时应用根据 本发明的方法1和方法2。图16示出了同时应用根据本发明的方法1和方法2的示例。然而，这 仅是示例。可以独立地应用根据本发明的方法1和方法2。
[0190] 参照图16,为了解决上述订阅/通知过程的问题，附加地验证请求发起方(例如，实 体1)是否具有对通知接收方(例如，实体3)的权限[S1607]。因此，当托管实体(例如，实体2) 从请求发起方(例如，实体1)接收订阅请求时，托管实体(例如，实体2)不仅检查请求发起方 (例如，实体1)是否具有能够订阅托管实体(例如，实体2)的权限[S1504]，而且还检查托管 实体(例如，实体2)是否具有能够向通知接收方(例如，实体3)发送通知的权限[S1506]。另 外，验证请求发起方(例如，实体1)是否具有针对通知接收方(例如，实体3)的权限（或者能 够发送通知消息的权限或能够配置用于发送通知消息的订阅的权限）[S1607]。可以在请求 发起方(例如，实体1)和通知接收方(例如，实体3)彼此不同时，执行根据步骤S1506的验证 和根据步骤S1607的验证。在图16的示例中，虽然描述了以S1504、S1506和S1607的顺序执行 步骤，但是这仅是示例。执行每一个步骤的顺序不限于该顺序。因此，如果必要，可以按照与 所描述的顺序不同的顺序来执行步骤S1506和步骤S1607。
[0191]如果同时应用方法1和方法2,则请求发起方(例如，实体1)可以预先给通知接收方 (例如，实体3)设置两个特权以便给托管实体(例如，实体2)配置用于向通知接收方(例如， 实体3)发送通知的订阅资源。第一特权是托管实体(例如，实体2)的能够向通知接收方(例 如，实体3)发送通知的特权，并且第二特权是请求发送方(例如，实体1)的能够将通知接收 方(例如，实体3)配置为通知目标的特权(例如，实体1的用于请求通知的权限）。并且，如上 所述，托管实体(例如，实体2)可以在检查请求发送方(例如，实体1)和托管实体(例如，实体 2) 是否具有针对通知接收方(例如，实体3)的权限之后，准许订阅。通过由通知接收方(例 如，实体3)拥有的特权信息，托管实体(例如，实体2)可以检查请求发起方(例如，实体1)的 权限和通知接收方(例如，实体3)的权限。
[0192] 如果应用根据本发明的方法2,则能够避免在没有许可的情况下使用已经被设置 给托管实体(例如，实体2)的针对通知接收方(例如，实体3)的权限的问题。因此，能够避免 在没有许可的情况下使用权限而造成的托管实体(例如，实体2)与通知接收方(例如，实体 3) 之间的网络负荷增大和系统容量减小的问题。
[0193] 并且，如果应用根据本发明的方法1和/或方法2,则能够在针对订阅请求的请求发 起方(例如，实体1)和通知接收方(例如，实体3)彼此不同时防止订阅/通知机制被恶意使 用。
[0194] 方法3(由通知接收方进行订阅验证)
[0195] 在根据本发明的方法1和方法2的情况下，由于托管实体(例如，实体2)有必要执行 获得在通知接收方(例如，实体3)中配置的特权信息的处理以便附加地执行验证处理（例 如，S1506和S1607)，因此这可能是低效的。为了改进上述问题，根据本发明的方法3提出了 托管实体(例如，实体2)请求通知接收方(例如，实体3)在托管实体不执行附加的验证处理 的情况下执行附加的验证处理(例如，S1506和S1607 )，通知接收方(例如，实体3)执行附加 的验证处理并且将附加的验证处理的结果返回至托管实体(例如，实体2)。
[0196] 仅当托管实体(例如，实体2)成功地获得关于通知接收方(例如，实体3)的最新权 限的信息时，可以由托管实体(例如，实体2)根据方法1和方法2来检查权限。如果没有获得 信息，则不能进行成功的验证，并且获得关于对通知接收方(例如，实体3)的权限的信息的 处理可能是对托管实体(例如，实体2)的负担。因此，当应用方法1和/或方法2时，如果由托 管实体(例如，实体2)(通知发送方)执行验证，则可能难以获得关于权限的信息，或者可能 导致针对获得/检查对应权限的开销。相反，在应用方法3的情况下，由于具有关于权限的信 息的通知接收方(例如，实体3)执行验证，因此能够更高效地执行验证。
[0197] 假设预先给通知接收方(例如，实体3)设置关于权限的信息。由于通知消息与请求 消息（例如，通知请求)相对应，因此通知消息能够包括被配置为生成和发送通知消息的托 管实体(例如，实体2)的识别信息(例如，fr)。因此，通知接收方(例如，实体3)可以基于包括 在通知消息中的托管实体(例如，实体2)的识别信息和关于预先设置给通知接收方的权限 的信息来验证托管实体(例如，实体2)是否具有能够向通知接收方(例如，实体3)发送通知 消息的权限。这样做，通知接收方(例如，实体3)可以执行与本发明的方法1相对应的操作。
[0198] 并且，通知消息可以包括订阅创建方(或请求发起方）（例如，实体1)的识别信息以 便使得通知接收方(例如，实体3)能够执行与本发明的方法2相对应的操作。并且，可以将用 于存储要包括在通知消息中的订阅创建方(或请求发起方）的识别信息的属性信息添加至 订阅资源。例如，订阅资源可以包括用于指示已经创建了订阅资源的实体或设备的识别信 息的属性信息（例如，创建方属性）。在本说明书中，为了清楚，用于指示已经创建了订阅资 源的实体或设备的识别信息的属性信息（例如，创建方属性)可以被称为创建方属性信息。 例如，创建方属性信息可以包括已经创建了创建方的实体或设备的地址信息（例如，URI)。 因此，如果订阅创建方(或请求发起方）（例如，实体1)向托管实体(例如，实体2)发送订阅请 求消息，则托管实体(例如，实体2)可以基于包括在订阅请求消息中的订阅创建方(或请求 发起方）（例如，实体1)的识别信息（例如，fr)来配置创建方属性信息（例如，创建方属性）。 然后，当发送通知信息时，托管实体(例如，实体2)可以按照在通知消息中包括订阅创建方 (或请求发起方）（例如，实体1)的识别信息的方式发送通知消息。因此，通知接收方(例如， 实体3)可以基于包括在通知消息中的订阅创建方(或请求发起方）（例如，实体1)的识别信 息和关于预先配置的权限的信息来验证订阅创建方(或请求发起方）（例如，实体1)是否具 有能够向通知接收方(例如，实体3)发送通知消息的权限(或者订阅创建方是否具有对通知 接收方的访问权限或订阅创建方是否具有能够配置用于向通知接收方发送通知消息的订 阅的权限）。这样做，通知接收方(例如，实体3)可以执行与本发明的方法2相对应的操作。
[0199] 在根据本发明的方法3中，发送至通知接收方(例如，实体3)的通知消息可以通过 通知事件的发生而生成并发送，或者可以针对托管实体(例如，实体3)而生成以独立于通知 事件的发生请求验证。如果请求发起方(例如，实体1)和通知接收方(例如，实体3)彼此不 同，则发送至通知接收方(例如，实体3)的通知消息可以包括用于指示验证请求的参数信息 (例如，verificationRequest)以根据本发明检查权限。例如，如果通知接收方(例如，实体 3)根据本发明的方法3发送通知消息，贝lj参数信息（例如，ver if i cationRequest)可以被配 置为特定的值(例如，真）。
[0200] 图17示出了根据本发明的验证和通知过程的示例。图17示出了根据本发明的方法 3的示例。参照图17的示例，为了验证，托管实体(例如，实体2)可以响应于来自通知接收方 (例如，实体3)的至少一个或更多个通知消息(或者，NOTIFY请求)来接收响应。例如，所接收 到的响应可以与在准许订阅之后首先接收到的通知消息的响应消息相对应。与图15和图16 的示例相比，根据图17的示例，托管实体(例如，实体2)成功地检查请求发起方(例如，实体 1)的权限（例如，检查请求发起方(例如，实体1)是否具有针对订阅目标资源或订阅资源的 权限）[S1704]并且托管实体(例如，实体2)可以响应于订阅请求立刻向请求发起方(例如， 实体1)发送确认[S1706]。在步骤S1706中发送的确认可以指示托管实体(例如，实体2)已经 临时接受订阅请求。托管实体(例如，实体2)可以临时准许订阅请求或在内部存储相关信 息，直到检查了从通知接收方(例如，实体3)接收的响应是否包括成功的验证结果[S1716]。
[0201] 在步骤S1706中，托管实体(例如，实体2)可以告知请求发起方(例如，实体1)订阅 准许过程的状态信息。例如，在非拦截模式下(例如，参照与图9至图11相关的描述），托管实 体(例如，实体2)在步骤S1706中创建/准许订阅，并且在成功执行验证之后在步骤S1718中 重新确认验证。或者，在验证失败之后，可以在步骤S1720中删除/拒绝/取消订阅。作为另一 个示例，在拦截模式的情况下(例如，参照与图7和图8相关的描述），托管实体(例如，实体2) 在步骤S1706中推迟准许订阅，并且托管实体(例如，实体2)可以在成功执行验证之后在步 骤S1718中准许订阅，或者在验证失败之后在步骤S1720中拒绝订阅。步骤S1706是可选的。 [0202]在步骤S1708中，托管实体(例如，实体2)可以向作为通知目标的通知接收方（例 如，实体3)发送通知消息。如上所述，在步骤S1708中发送至通知接收方(例如，实体3)的通 知消息可以通过通知事件的发生而生成并发送，或者通知消息可以独立于通知事件的发生 来针对托管实体(例如，实体2)生成以请求验证。托管实体(例如，实体2)向通知接收方(例 如，实体3)发送通知消息，并且请求对通知消息的响应。在这种情况下，通知接收方(例如， 实体3)检查托管实体(例如，实体2)是否具有能够向通知接收方发送通知的权限。如果托管 实体不具有能够向通知接收方发送通知的权限，则通知接收方可以在步骤S1714中发送失 败响应消息。在这种情况下，托管实体(例如，实体2)通过失败响应消息来检查结果并且稍 后可以删除对应的订阅资源。可以告知请求发起方(例如，实体1)删除了对应的订阅资源。 [0203]在步骤S1708中，托管实体(例如，实体2)可以确定请求发起方(例如，实体1)是否 与通知接收方(例如，实体3)相同。例如，托管实体(例如，实体2)可以基于请求发起方(例 如，实体1)的识别信息和通知接收方(例如，实体3)的识别信息来确定请求发起方(例如，实 体1)是否与通知接收方(例如，实体3)相同。例如，可以从订阅请求的fr信息获得请求发起 方(例如，实体1)的识别信息(或地址信息）。例如，可以从订阅资源的通知目标属性信息(例 如，notif icationURI)获得或提取/推断通知接收方（例如，实体3)的识别信息（或地址信 息）。如果请求发起方(例如，实体1)和通知接收方(例如，实体3)彼此不同，则托管实体(例 如，实体2)可以发送通信消息。
[0204]在步骤S1708中，如果通知目标不是请求发起方(例如，实体1)(或者，如果请求发 起方(例如，实体1)和通知接收方(例如，实体3)彼此不同），则托管实体(例如，实体2)可以 在通过通知事件的发生而生成的通知消息中包括请求发起方(例如，实体1)的识别信息以 及作为通知发送方的托管实体(例如，实体2)的识别信息。为此，请求发起方(或订阅创建 方）（例如，实体1)的识别信息可以存储在托管实体(例如，实体2)中作为订阅资源的一部分 (例如，创建方属性信息或创建方属性）。在步骤S1708中，仅当通知事件实际发生时，不需要 发送通知消息（或NOTIFY请求消息），但是为了验证可以任意地发送通知消息（或NOTIFY请 求消息）。例如，可以在步骤S1706之后执行步骤S1708。
[0205]在步骤S1708中，如果通知目标不是请求发起方(例如，实体1)(或者，如果请求发 起方(例如，实体1)和通知接收方(例如，实体3)彼此不同），则通知消息可以进一步包括指 示针对根据本发明检查权限的验证请求的参数信息（例如，verificationRequest)。例如， 参数信息（例如，verificationRequest)可以具有特定的数据类型(例如，布尔型）。并且，例 如，如果托管实体(例如，实体2)向通知接收方(例如，实体3)发送用于检查权限的通知消息 以便执行订阅验证，则可以将参数信息配置为特定的值(例如，真）。例如，如果参数信息(例 如，￥61^行〇31：；[0111^911681：)被配置为特定的值(例如，真），则通知接收方(例如，实体3)可以 将通知消息识别为验证请求。作为另一个示例，如果参数信息（例如， verificationRequest)被配置为特定的值(例如，假），则通知接收方(例如，实体3)可以根 据一般通知过程(例如，由于通知事件的发生)将通知消息识别为请求消息。
[0206] 通知接收方(例如，实体3)可以验证托管实体(例如，实体2)是否具有能够向通知 接收方发送通知消息的权限和/或订阅创建方(或请求发起方）（例如，实体1)是否具有能够 向通知接收方发送通知消息的权限(或者能够配置用于向通知接收方发送通知消息的订阅 的权限）[S1710，S1712]。验证过程可以分别与图15中的步骤S1506和图16中的步骤S1607相 对应。在图17中，如有必要，可以改变执行S1710和S1712的顺序。
[0207] 在步骤S1716中，托管实体(例如，实体2)将步骤S1706识别为临时准许或成功接收 订阅请求，直到托管实体检查来自通知接收方(例如，实体3)的验证结果为成功为止。因此， 虽然发生通知事件，但是托管实体可以不向通知接收方(例如，实体3)发送通知消息（或通 知请求）。例如，托管实体(例如，实体2)接收订阅请求，创建订阅资源并且然后可以在步骤 S1708中发送通知消息。在这种情况下，由于所创建的订阅资源，可以发生通知事件。但是， 由于检查针对订阅请求的权限尚未完成，因此虽然通过发生的通知事件生成了通知消息， 但是可以忽略该通知消息或者可以不将该通知消息发送给通知接收方(例如，实体3)。关于 订阅准许状态的信息可以作为订阅资源的一部分存储在托管实体(例如，实体2)中。
[0208] 如果在步骤S1714中接收到包括验证成功的结果的响应，则托管实体(例如，实体