DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
A preliminary amendment was filed on 8/23/24 canceling claims 1-37, added new claims 38-57. Thus, claims 38-57 are presented for examination.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 102
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 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.
Claims 38-42, 48-50, 56, and 57 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Krishan (U.S. 11,290,549).
With respect to claim 38, Krishan teaches a method performed by a first service communication proxy (SCP) node in a communications network, wherein the first SCP node is configured to operate as a SCP between a client node and one or more server nodes operating service instances of a first service (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200]. The discovery or service request may identify at least one service for which NF discovery is being requested (either directly by the consumer NF or indirectly in the case of delegated discovery) – see Krishan, Figs. 3 and 8, elements 101, 100, 200; col. 15, lines 21-29), the method comprising:
receiving a first service request from the client node, requesting the first service (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 24-25); and
sending service information to the client node, the service information comprising an indication of the service instances of the first service that are operating on the one or more server nodes (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
With respect to claim 39, Krishan teaches the invention described in claim 38, including the method wherein the indication of the service instances of the first service comprises: an indication of all service instances of the first service and/or an indication of all sets of service instances of the first service (in step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 15, lines 46-56).
With respect to claim 40, Krishan teaches the invention described in claim 38, including the method wherein the step of sending service information to the client node is performed responsive to the step of receiving a first service request from the client node (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 23-25).
With respect to claim 41, Krishan teaches the invention described in claim 38, including the method wherein the step of sending service information to the client node is performed responsive to the first SCP node being unable to select a service instance from the service instances to provide the first service to the client node (in step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In line 2 of the message flow diagram, the consumer NF that sent the discovery request sends a service request to SCP 101A requesting service from a producer NF in location 2. SCP 101A determines the selected service endpoint of producer NF in location 2 is unavailable, for example, due to lack of connectivity, and determines that there is a producer NF instance in location 3 that is capable of providing the service. Accordingly, in line 3 of the message flow diagram, SCP 101A forwards the service request to one of the producer NF instances on producer NFs 208 in location 3 that is capable of providing the service. – see Krishan, Fig. 8; col. 15, lines 46-54 and col. 8, lines 47-57).
With respect to claim 42, Krishan teaches the invention described in claim 38, including the method wherein the step of sending service information to the client node comprises sending the service information in a service response message (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 23-25).
With respect to claim 48, Krishan teaches a method performed by a client node in a communications network (in 5G networks, consumer [Network Functions] 200 and 202 reside in location 1 – see Krishan, Fig. 2, element 200; col. 7, line 58 – col. 8, line 3), the communications network comprising a first service communication proxy (SCP) node configured to operate as a SCP between the client node and one or more server nodes operating service instances of a first service (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200]. The discovery or service request may identify at least one service for which NF discovery is being requested (either directly by the consumer NF or indirectly in the case of delegated discovery) – see Krishan, Figs. 3 and 8, elements 101, 100, 200; col. 15, lines 21-29), the method comprising:
sending a first service request to the first SCP node, requesting the first service (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 24-25); and
receiving service information from the first SCP node, the service information comprising an indication of the service instances of the first service that are operating on the one or more server nodes (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
With respect to claim 49, Krishan teaches the invention described in claim 48, including the method wherein the indication of the service instances of the first service comprises: an indication of all service instances of the first service and/or an indication of all sets of service instances of the first service (in step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 15, lines 46-56).
With respect to claim 50, Krishan teaches the invention described in claim 48, including the method wherein the service information is received in a service response message (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 23-25).
With respect to claim 56, Krishan teaches the invention described in claim 48, including the method wherein: the first SCP node and the client node are deployed in independent deployment units (); and/or the client node and one or more of the server nodes are deployed in independent deployment units (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200] – see Krishan, Fig. 3, elements 101, 100, 200; col. 15, lines 21-28).
With respect to claim 57, Krishan teaches a client node in a communications network (in 5G networks, consumer [Network Functions] 200 and 202 reside in location 1 – see Krishan, Fig. 2, element 200; col. 7, line 58 – col. 8, line 3), the communications network comprising a first service communication proxy (SCP) node configured to operate as a SCP between the client node and one or more server nodes operating service instances of a first service (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200]. The discovery or service request may identify at least one service for which NF discovery is being requested (either directly by the consumer NF or indirectly in the case of delegated discovery) – see Krishan, Figs. 3 and 8, elements 101, 100, 200; col. 15, lines 21-29), the client node comprising:
a memory comprising instruction data representing a set of instructions (a memory – see Krishan, col. 14, line 32); and
a processor configured to communicate with the memory and to execute the set of instructions, wherein the set of instructions, when executed by the processor, cause the processor (at least one processor – see Krishan, col. 14, line 31) to:
send a first service request to the first SCP node, requesting the first service (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 24-25); and
receive service information from the first SCP node, the service information comprising an indication of the service instances of the first service that are operating on the one or more server nodes (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
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 46, 47, and 52-54 are rejected under 35 U.S.C. 103 as being unpatentable over Krishan and further in view of Kerl et al. (U.S. 10,027,559).
With respect to claim 46, Krishan teaches the invention described in claim 38, including a method performed by a first service communication proxy (SCP) node in a communications network, wherein the first SCP node is configured to operate as a SCP between a client node and one or more server nodes operating service instances of a first service (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200]. The discovery or service request may identify at least one service for which NF discovery is being requested (either directly by the consumer NF or indirectly in the case of delegated discovery) – see Krishan, Figs. 3 and 8, elements 101, 100, 200; col. 15, lines 21-29), the method comprising: receiving a first service request from the client node, requesting the first service (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 24-25); and sending service information to the client node, the service information comprising an indication of the service instances of the first service that are operating on the one or more server nodes (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
Krishan does not explicitly teach the method wherein the service information comprises an indication of an estimated throttling and/or an estimated percentage of traffic abatement to apply to traffic sent to a first service instance of the first service on a first server node.
However, Kerl teaches the method wherein the service information comprises an indication of an estimated throttling (determining, in accordance with the client input throttling instructions, a networking configuration option for a particular category of network traffic; categorizing each packet of network traffic directed to a service instance; and reducing a rate of network traffic to the service instance by throttling a transfer rate of each packet queue in accordance with a transfer rate specified in the network configuration option for the category of network traffic stored in the packet queue – see Kerl, col. 23, line 43 – col. 24, line 16) and/or an estimated percentage of traffic abatement to apply to traffic sent to a first service instance of the first service on a first server node.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Krishan in view of Kerl in order to enable the method wherein the service information comprises an indication of an estimated throttling and/or an estimated percentage of traffic abatement to apply to traffic sent to a first service instance of the first service on a first server node. One would be motivated to do so in order to enable clients of the distributed systems to obtain unified or consolidate views of the networking-related status of resources of interest (Kerl, col. 3, lines 45-48).
With respect to claim 47, the combination of Krishan and Kerl teaches the invention described in claim 46, including the method wherein the first service instance is selected by the first SCP to provide the first service to the client node (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
The combination of references is made under the same rationale as claim 46 above.
With respect to claim 52, the combination of Krishan and Kerl teaches the invention described in claim 48, including the method further comprising: determining, from the service information and overload information obtained in response to previous service requests, that all the service instances of the first service are overloaded (determining, in accordance with the client input throttling instructions, a networking configuration option for a particular category of network traffic; categorizing each packet of network traffic directed to a service instance; and reducing a rate of network traffic to the service instance by throttling a transfer rate of each packet queue in accordance with a transfer rate specified in the network configuration option for the category of network traffic stored in the packet queue – see Kerl, col. 23, line 43 – col. 24, line 16).
The combination of references is made under the same rationale as claim 46 above.
With respect to claim 53, the combination of Krishan and Kerl teaches the invention described in claim 52, including the method further comprising: in response to the determination that all the service instances are overloaded: performing overload abatement based on request throttling (determining, in accordance with the client input throttling instructions, a networking configuration option for a particular category of network traffic; categorizing each packet of network traffic directed to a service instance; and reducing a rate of network traffic to the service instance by throttling a transfer rate of each packet queue in accordance with a transfer rate specified in the network configuration option for the category of network traffic stored in the packet queue – see Kerl, col. 23, line 43 – col. 24, line 16); and/or blocking traffic from a User Equipment (UE).
The combination of references is made under the same rationale as claim 46 above.
With respect to claim 54, the combination of Krishan and Kerl teaches the invention described in claim 53, including the method wherein the throttling is optimized by the Client node (determining, in accordance with the client input throttling instructions, a networking configuration option for a particular category of network traffic; categorizing each packet of network traffic directed to a service instance; and reducing a rate of network traffic to the service instance by throttling a transfer rate of each packet queue in accordance with a transfer rate specified in the network configuration option for the category of network traffic stored in the packet queue – see Kerl, col. 23, line 43 – col. 24, line 16).
The combination of references is made under the same rationale as claim 46 above.
Claim 55 is rejected under 35 U.S.C. 103 as being unpatentable over Krishan in view of Kerl and further in view of Das et al. (U.S. 12,407,561).
With respect to claim 55, Krishan teaches the invention described in claim 48, including a method performed by a client node in a communications network (in 5G networks, consumer [Network Functions] 200 and 202 reside in location 1 – see Krishan, Fig. 2, element 200; col. 7, line 58 – col. 8, line 3), the communications network comprising a first service communication proxy (SCP) node configured to operate as a SCP between the client node and one or more server nodes operating service instances of a first service (Fig. 8 is a flow chart illustrating an exemplary process performed by [Service Communications Proxy] 101 and [Network Function Repository Function] 100 in performing optimized routing as described herein. Referring to FIG. 8, in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer [Network Function 200]. The discovery or service request may identify at least one service for which NF discovery is being requested (either directly by the consumer NF or indirectly in the case of delegated discovery) – see Krishan, Figs. 3 and 8, elements 101, 100, 200; col. 15, lines 21-29), the method comprising: sending a first service request to the first SCP node, requesting the first service (in step 800, a discovery request or a service request with a 3gpp-Sbi-Discovery header is received from a consumer NF – see Krishan, Fig. 8; col. 15, lines 24-25); and receiving service information from the first SCP node, the service information comprising an indication of the service instances of the first service that are operating on the one or more server nodes (in step 812, for the case of non-delegated discovery, SCP 101 may forward the discovery response including the list of service profiles of producer NF instances to a consumer NF that sent the initial discovery request to SCP 101. In step 808, a list of service profiles is created at the NRF using the unhealthy endpoint and service name identification information provided in the discovery request. For example, in NRF 100 may generate an initial list of service profiles of endpoints based on the service identifier (outside of the custom headers in the discovery request message) and exclude or remove service profiles of endpoints from the list service profiles that have service name and endpoint combinations that are indicated by SCP 101 as being unhealthy. In step 810, the discovery response with the list of service profiles is transmitted to the SCP – see Krishan, Fig. 8; col. 16, lines 1-5; col. 15, lines 46-56).
Krishan does not explicitly teach the method wherein the method is performed as part of an overload mitigation with indirect communication procedure.
However, Kerl teaches the method wherein the method is performed as part of an overload mitigation with indirect communication procedure (determining, in accordance with the client input throttling instructions, a networking configuration option for a particular category of network traffic; categorizing each packet of network traffic directed to a service instance; and reducing a rate of network traffic to the service instance by throttling a transfer rate of each packet queue in accordance with a transfer rate specified in the network configuration option for the category of network traffic stored in the packet queue – see Kerl, col. 23, line 43 – col. 24, line 16).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Krishan in view of Kerl in order to enable the method wherein the method is performed as part of an overload mitigation with indirect communication procedure. One would be motivated to do so in order to enable clients of the distributed systems to obtain unified or consolidate views of the networking-related status of resources of interest (Kerl, col. 3, lines 45-48).
The combination of Krishan and Kerl does not explicitly teach that utilizes the model D, 3GPP architecture.
However, Das teaches that utilizes the model D, 3GPP architecture (in the indirect communication with delegated discovery (also named as model D in 3GPP specifications), the SCP, upon receiving a service request from the NFc, performs the NF discovery, access token request procedure, and requests service – see Das, col. 5, lines 19-23).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Krishan and Kerl in view of Das in order to enable that utilizes the model D, 3GPP architecture. One would be motivated to do so in order to enable the [Network Repository Function] may notify about newly registered, updated, or deregistered [service-producing Network Function] entities along with its [Network Function] services to a subscribed [service-consuming Network Function] or [Service Communication Proxy] (Das, col. 4, lines 1-3).
Allowable Subject Matter
Claims 43-45 and 51 are objected to as being dependent upon rejected base claims, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Alicia Baturay whose telephone number is (571) 272-3981. The examiner can normally be reached at 7am – 4pm, Mondays – Thursdays, Eastern Time.
Examiner interviews are available via telephone, in person, or video conferencing using a USPTO-supplied, web-based collaboration tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) form at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wing Chan can be reached on (571) 272-7493. The fax 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.
/Alicia Baturay/
Primary Examiner, Art Unit 2441
November 20, 2025