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 .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 20-38 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “3rd Generation Partnership Project, Technical Specification Group Core Network and Terminals, 5G System, Technical Realization of Service Based Architecture, Stage 3 (Release 17)”, 3GPP Standard, Technical Specification, 3GPP TS 29.500, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre, vol. CT WG4, no V17.0.0, 24 September 2020, pp 1-82, hereinafter referred to as D1.
Regarding claims 20, 25, 29, 34, and 38, D1 discloses system functionality achieved by a set of NFs providing services to other authorized NFs to access their services, which comprises:
receiving, by said first NF instance, a service request for a service provided by an NF service instance of said first NF instance; transmitting, by said first NF instance, in reply to said service request, a congestion error indicating that there is an error upon detecting a congestion error with said NF service instance of said first NF instance (Referring to section 6.3.3.4.1 and 6.4.1, A NF service producer may include one or more LCI header(s) in a service response or in a notification/callback request message sent to a NF service consumer (transmitting by said first NF instance in reply to a service request a congestion error indicating that there is an error upon detecting a congestion error with said NF service of said first NF instance). An NF service produce may report LCI with different scopes. Overload control enables an NF service producer, an NF service consumer or an SCP becoming or being overloaded to gracefully reduce its incoming signaling load, by instructing NF server consumers to reduce sending service requests or by instructing NF service producers to reduce sending notification requests (receiving a service request for a service provided by an NF service instance), respectively, according to its available signaling capacity to successfully process the requests. An NF service producer, NF service consumer or SCP is in overload when it operates over its signaling capacity (a congestion error with said NF service instance). When being instructed by a NF service consumer to apply overload control, the NF service producer shall perform the signaling reduction towards the NF service consumer only for the notifications or callback requests according to the overload scope, and not for any NF services which may be produced by the same NF, even when the overload scope is on NF instance level or NF set level.)
Regarding claims 21, D1 discloses determining, by said first NF instance, that there is a congestion error for said NF service instance of said first NF instance (Referring to section 6.3.3.4.1 and 6.4.1, An NF service producer, NF service consumer or SCP is in overload when it operates over its signaling capacity (a congestion error with said NF service instance). When being instructed by a NF service consumer to apply overload control, the NF service producer shall perform the signaling reduction towards the NF service consumer only for the notifications or callback requests according to the overload scope, and not for any NF services which may be produced by the same NF, even when the overload scope is on NF instance level or NF set level.)
Regarding claims 22, D1 discloses determining, by said first NF instance, that there is said congestion error for said NF service instance of said first NF instance based on at least one of: a congestion of said NF service instance for said requested service; a risk to congestion of said NF service instance for said requested service (Referring to section 6.3.3.4.1 and 6.4.1, An NF service producer, NF service consumer or SCP is in overload (congestion of said NF Service stance) when it operates over its signaling capacity (a congestion error with said NF service instance). When being instructed by a NF service consumer to apply overload control, the NF service producer shall perform the signaling reduction towards the NF service consumer only for the notifications or callback requests according to the overload scope, and not for any NF services which may be produced by the same NF, even when the overload scope is on NF instance level or NF set level.)
Regarding claims 23, D1 discloses wherein said congestion error is comprised by any of: a message indicating that the service request is rejected due to excessive traffic which may lead to an overload situation of said NF service instance; a message indicating that said NF service instance experiences congestion (Referring to section 6.3.3.4.1 and 6.4.1, A NF service producer may include one or more LCI header(s) in a service response or in a notification/callback request message sent to a NF service consumer (transmitting by said first NF instance in reply to a service request a congestion error indicating that there is an error upon detecting a congestion error with said NF service of said first NF instance, a message). An NF service produce may report LCI with different scopes. Overload control enables an NF service producer, an NF service consumer or an SCP becoming or being overloaded to gracefully reduce its incoming signaling load, by instructing NF server consumers to reduce sending service requests or by instructing NF service producers to reduce sending notification requests (receiving a service request for a service provided by an NF service instance), respectively, according to its available signaling capacity to successfully process the requests.)
Regarding claims 24, D1 discloses receiving, by said first NF instance, a further service request for a different service provided by a different NF service instance of said first NF instance, wherein said congestion error has been detected for said NF service instance; providing, by said first NF instance, in reply to said further service request, said requested different service via said different NF service instance (Referring to section 6.3.3.4.1 and 6.4.1, An NF service producer, NF service consumer or SCP is in overload when it operates over its signaling capacity (a congestion error with said NF service instance). When being instructed by a NF service consumer to apply overload control, the NF service producer shall perform the signaling reduction towards the NF service consumer only for the notifications or callback requests according to the overload scope, and not for any NF services (a further service for a different service provided by a different NF service instance, providing in replay to said request said different service via said different NF service instance) which may be produced by the same NF, even when the overload scope is on NF instance level or NF set level. Thereby, providing the further service as the NF service producer still permits service despite the overload condition.)
Response to Arguments
Applicant's arguments filed 24 December 2025 have been fully considered but they are not persuasive.
On page 8 of the remarks, regarding claim 20, the Applicant argues D1 does not disclose the congestion error indicating that there is an error upon detecting a congestion error. The Examiner respectfully disagrees. The claim recites, “transmitting . . . a congestion error indicating that there is an error upon detecting a congestion error with said NF service instance of said first NF instance.” The claim does not recite a positive recitation directed towards “detecting a congestion error” but rather “upon” some future event. The term “upon” is defined as to be something that will occur very soon after or on the occasion of. Therefore, the claim limitation (upon detecting . . .) is merely a statement of some future intended-use and is not given patentable weight. The claim does not recite a positive limitation in which the method detects and determines a congestion error but rather at some future point in time there may or may not be a detection. Therefore, the claim term is not afforded patentable weight and is taught in light of the prior art.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Landais et al. (US 2021/0306907 A1) - One method may include transmitting, from a network function (NF) service consumer, overload control information (OCI) comprising scope information to a network function (NF) service producer or service communication proxy (SCP). The scope information may include at least one of: scope set to a notification uniform resource identifier (URI), or scope set to one of network function (NF) service instance, network function (NF) service set, network function (NF) instance, or network function (NF) set, and optionally a service name.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONALD L MILLS whose telephone number is (571)272-3094. The examiner can normally be reached Monday through Friday from 9-5 PM EST.
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, Yemane Mesfin can be reached at 571-272-3927. 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.
DONALD L. MILLS
Primary Examiner
Art Unit 2462
/Donald L Mills/ Primary Examiner, Art Unit 2462
Prosecution Insights