DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on May 5, 2026 has been entered.
Response to Amendment
The amendments filed on May 5, 2026 have been entered. Claims 22, 27, and 33-35 have been amended. Claims 1-21 were previously cancelled. Claims 22-35 remain pending in the application.
Response to Arguments
Applicant’s arguments filed on May 5, 2026 in response to the Final Office Action dated January 5, 2026 have been fully considered.
Applicant argues, in pages 9 and 10 of the Remarks, “Ericsson fails to teach this feature because, while Ericsson describes creating and storing an nfSubscriptionId at the NRF when a subscription is established, Ericsson does not disclose including that NRF-generated subscription identifier in the notification request transmitted to the callback URI. Instead, Ericsson's notification payload is limited to event-related information, such as the affected NF instance and the type of event. This describes the condition of the network function rather than identifying the specific administrative subscription record that triggered the notification. The mere existence of a subscription identifier within the NRF's internal data structures is insufficient to meet the claimed feature, which expressly requires that the subscription context included in the notification itself contain a subscription identifier generated by the NRF for the created subscription. Because Ericsson does not transmit such an NRF-generated subscription identifier as part of the notification, it cannot teach or anticipate the amended claim”.
In response, Examiner would like to draw the attention of the application into the purpose of the invention of Ericsson. As mentioned in Section 2. Reason for Change of Ericsson, the novelty of Ericsson is that it enables adding more subscription criteria in addition to subscription for newly registered NF instance. Therefore, there are different and distinct subscription requests for newly registered NF instance, profile change/deregistration of already registered NF instance as explained in Section 5.2.2.5.1. Subscription for newly registered NF instance is identified by SubscriptionID and subscriptions for already registered NF instance for various events like profile change, deregistration are identified by respective nfSubscritptionID. All of those IDs are created by the NRF. When an occurring event matches the condition for triggering notification as per the criteria set by the SubscriptionID or respective nfSubscritptionID, the notification is sent. When notification is sent for newly registered NF instance, it corresponds to the SubscriptionID since both NF service consumer and the NRF are in sync with the SubscriptionID during the creation of that particular subscription. Similar analysis applies to the respective nfSubscriptionID. Ericsson mentions some of the relevant elements of the POST notification without giving the exhaustive list of the elements. It is well known in the Art that HTTP push notification generally includes subscription identifier unless it is obvious to identify the subscription identifier even without sending it. Since Ericsson does not explicitly mentions subscription ID, a second reference is applied that teaches a HTTP POST notification includes subscription ID.
Applicant' s arguments regarding subscription ID with respect to claim 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Examiner’s Note about the Format of 35 U.S.C. 102/103 Rejections
Generally, limitations of a claim are reproduced identically and followed by examiner’s explanation with citation from prior art in Italic enclosed by a parenthesis, (), for each limitation. In examiner’s explanation, the mapping of the key elements of a limitation to the disclosed elements of prior art is shown by stating the disclosed element immediately followed by the claimed element inside a parenthesis. Specific quotation from prior art is delineated with quotation mark, ““. If primary art fails to teach a limitation or part of the limitation, the limitation or the part of the limitation is placed inside double square brackets, [[ ]], for better understandability, and appropriate secondary art(s) is/are applied later addressing the deficiency of the primary art.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 22-35 are rejected under 35 U.S.C. 103 as being unpatentable over Ericsson (an NPL with Title: “Pseudo-CR on Subscription to NF Profile changes” and Document ID: C4-181348: 3GPP TSG CT4 Meeting #82), hereinafter, Ericsson, in view of Zhu et al. (US PGUB No. US 20240259857 A1), hereinafter, Zhu.
Regarding claim 22:
Ericsson teaches:
A method performed by a first network function implementing a Network Repository Function, NRF, comprising (Fig. 5.2.2.5.2-1 shows NRF (first network function)):
- receiving, from a second network function, one or more subscription requests for subscribing one or more events associated with a third network function, wherein each of the one or more subscription requests comprises a first parameter indicating a subscription condition and a second parameter indicating a common callback Uniform Resource Identifier, URI, wherein receiving the one or more subscription requests for subscribing the one or more events further comprising (Fig. 5.2.2.5.2-1 shows receiving from NF service consumer (second network function) subscription request. Section 5.2.2.5.2 discloses subscription for notification of NF instance (third network function). It also disclose the subscription request includes type of notification (first parameter) and callback URI (second parameter) as stated “The NF Service Consumer shall send a POST request to the resource URI representing the "subscriptions" collection resource. The request body shall include the data indicating the type of notifications that the NF Service Consumer is interested in receiving; it also contains a callback URI, where the NF Service Consumer shall be prepared to receive the actual notification from the NRF”. Also see Section 5.2.2.6.2 discussing notification for event of NF instance):
receiving a first subscription request including the first parameter indicating a first subscription condition and the second parameter indicating the common callback URI and creating a first subscription according to the first subscription request, including assigning a first subscription ID for the first subscription (Fig. 5.2.2.5.2-1 shows receiving subscription request (first subscription request). Section 5.2.2.5.2 discloses the subscription request includes type of notification (first subscription condition) and callback URI (common callback URI). Fig. 5.2.2.5.2-1 shows assigning subscriptionID (first subscription ID)); and
- receiving a second subscription request including the first parameter indicating a second subscription condition and the second parameter indicating the common callback URI and creating a second subscription according to the second subscription request, including assigning a second subscription ID for the second subscription (Section 2. discloses the purpose the invention is to add more subscription criteria in addition to subscription for newly registered NF instance. Therefore, there are plurality of distinct subscription requests for newly registered NF instance, profile change/deregistration of already registered NF instance as explained in Section 5.1.1.5.1. Fig. 5.2.2.5.3-1 shows receiving subscription request (second subscription request). Section 5.2.2.5.3 discloses the subscription request includes part of the profile (second subscription condition) and callback URI (common callback URI) as stated “The NF Service Consumer shall send a POST request to the resource URI representing the "nf-subscriptions" collection resource. The request body shall include the data indicating which parts of the profile of the NF Instance should trigger a notification, and/or the indication to be notified when the NF Instance is deregistered; it also contains a callback URI, where the NF Service Consumer shall be prepared to receive the actual notification from the NRF (see NFStatusNotify operation in 5.2.2.6”). Fig. 5.2.2.5.3-1 shows assigning nfSubscriptionID (second subscription ID)); and
- transmitting a notification request for notifying the one or more event to the second network function according to the common callback URI, wherein the notification request includes a third parameter indicating a subscription context regarding the subscription request, wherein the subscription context relates to a created subscription and [[includes at least one of the first subscription ID]] and the first subscription condition or [[at least one of the second subscription ID]] and the second subscription condition, depending on which of the first or second subscription condition occurs and wherein the subscription context includes a subscription identifier generated by the NRF for the created subscription (Fig. 5.2.2.6.2-1 shows transmitting notification to the NF service consumer. Section 5.2.2.6.2 discloses the notification includes subscription context including NFinstanceID and registration event in case of subscription notification for new NF instance and NFinstanceID and profile change event in case of subscription notification for profile change of already registered NF instance as stated “The NRF shall send a POST request to the callback URI. For notifications of newly registered NF Instances, the request body shall include the data associated to the newly registered NF, and its services, according to the criteria indicated by the NF Service Consumer during the subscription operation. These data shall contain, among others, the NFInstanceID of the NF Instance, an indication of the event being notified ("registration"), and the services offered by the NF Instance. For notifications of changes of the profile of a NF Instance, the request body shall include the NFInstancceID of the NF Instance whose profile was changed, an indication of the event being notified ("profile change"), and the new profile data. For notifications of deregistration of the NF Instance from NRF, the request body shall include the NFInstanceID of the deregistered NF Instance, and an indication of the event being notified ("deregistration").” . The SubscriptionID, nfSubscriptionID, NFinstanceID (subscription identifier) are generated by the NRF).
Ericsson does not explicitly teach notification request includes at least one of the first subscription ID or at least one of the second subscription ID.
Zhu discloses notification request includes at least one of the first subscription ID or at least one of the second subscription ID (paragraph 0148 discloses the HTTP POST notification includes subscription ID, event etc.).
It would have been obvious to one of ordinary skill in the art before the effective fling date of the claimed invention to modify Ericsson to incorporate the teaching of Zhu about including subscription ID in the POST notification. One would be motivated to do that to that to decern different notifications for different subscription conveniently (See Section 5.2.2.5.1 of Ericsson).
As to claim 23, the rejection of claim 22 is incorporated. Ericsson in view of Zhu teach all the limitations of claim 22 as shown above.
Ericsson further teaches wherein the subscribed event is a network function profile change of the third network function and wherein the subscription condition includes that the third network function is added into or removed from a network function set (Section 5.2.2.6.2 discloses profile change event as stated “For notifications of changes of the profile of a NF Instance, the request body shall include the NFInstancceID of the NF Instance whose profile was changed, an indication of the event being notified ("profile change"), and the new profile data.”. Section 5.2.2.5.3 discloses NF instance deregistration as state “The request body shall include the data indicating which parts of the profile of the NF Instance should trigger a notification, and/or the indication to be notified when the NF Instance is deregistered”. Also see Table 6.1.3.1-1).
As to claim 24, the rejection of claim 22 is incorporated. Ericsson in view of Zhu teach all the limitations of claim 22 as shown above.
Ericsson further teaches wherein:- the common callback URI includes a notification endpoint of the second network function and an optional notification correlation ID (Section 5.2.2.5.2 states “The request body shall include the data indicating the type of notifications that the NF Service Consumer is interested in receiving; it also contains a callback URI, where the NF Service Consumer shall be prepared to receive the actual notification from the NRF (see NFStatusNotify operation in 5.2.2.6).”).
As to claim 25, the rejection of claim 22 is incorporated. Ericsson in view of Zhu teach all the limitations of claim 22 as shown above.
Ericsson further teaches wherein:- the second network function and the third network function are a service consumer and a service producer respectively for a specific service (Fig. 5.2.2.5.2-1 shows NF service consumer. Section 5.2.2.5.2 discloses NF instance (service producer).).
As to claim 26, the rejection of claim 22 is incorporated. Ericsson in view of Zhu teach all the limitations of claim 22 as shown above.
Ericsson further teaches wherein: - the third network function belongs to one or more network function sets; wherein the first subscription condition is that the third network function is added into or removed from a first set of the one or more network function sets; and wherein the second subscription condition is that the third network function is added into or removed from a second set of the one or more network function sets (Section 5.2.2.5.2 discloses NF instance in NF instances (network function sets). Also Fig. 6.1.3.1-1 and Table 6.1.3.1-1).
Regarding claim 27:
Claim 27 is recites similar limitation as claim 22 in the perspective of the second network function. Accordingly, it is rejected under similar rationale.
Claim 28 is recites similar limitation as claim 23 in the perspective of the second network function. Accordingly, it is rejected under similar rationale.
As to claim 29, the rejection of claim 27 is incorporated. Ericsson in view of Zhu teach all the limitations of claim 27 as shown above.
Ericsson further teaches further comprising:- finding the related subscription data within the subscription request according to the received subscription context; and - handling the notified data within the notification request accordingly (see section 5.2.2.6.2 discloses sending notification data as per the subscription request).
Claim 30 is recites similar limitation as claim 24 in the perspective of the second network function. Accordingly, it is rejected under similar rationale.
Claim 31 is recites similar limitation as claim 25 in the perspective of the second network function. Accordingly, it is rejected under similar rationale.
Claim 32 is recites similar limitation as claim 26 in the perspective of the second network function. Accordingly, it is rejected under similar rationale.
Regarding claim 33:
Claim 33 is directed towards a first network function performing the method of claim 22. Accordingly, it is rejected under similar rationale.
Regarding claim 34:
Claim 34 is directed towards a second network function performing the method of claim 27. Accordingly, it is rejected under similar rationale.
Regarding claim 35:
Claim 35 is directed towards computer readable medium comprising computer readable code, which when run on an apparatus, causes the apparatus to perform the method of claim 22. Accordingly, it is rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KAMAL M HOSSAIN whose telephone number is (571)270-3070. The examiner can normally be reached 9:30-5:30 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John Follansbee can be reached at (571)272-3964. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
June 12, 2026
/KAMAL M HOSSAIN/ Primary Examiner, Art Unit 2444
Prosecution Insights