Response to an Amendment
This office action is a response to a communication made 08/21/2025.
Claims 17-20 are new.
Claims 1-11 and 15-16 are currently amended.
Claims 1-20 are pending for this application.
Response to Arguments
Applicant’s arguments, see remarks on page 1, filed 08/21/2025, with respect to claims 1, 6-7, 9-11, 15-16 have been fully considered and are persuasive. The objection of claims 1, 6-7, 9-11, 15-16 has been withdrawn.
Applicant: Applicant’s arguments, see remarks on page 1-2, filed 08/21/2025, applicant argues that “Asveren does not teach or suggest “assigning, at the centralized identifier range allocator, a new identifier range to the application pod in response to the received request” recited in claim 1.
Examiner: Applicant's arguments filed 08/21/2025 have been fully considered but they are not persuasive. Examiner respectfully disagrees.
Asveren teaches assigning, at the centralized identifier range allocator, a new identifier range to the application pod in response to the received request because ¶0050, teaches the cloud network 102 includes a Kubernetes system 104 including a Kubernetes master node/control plane 105 as centralized identifier, ¶0057, teaches Container network interface (CNI) (i.e. application pod) service 216 adds network interfaces in response to requests made via the CNI Add API 217, ¶0059, teaches the invocation of a request for an additional interface, for example a CNI ADD request is an API call via the CNI ADD API. The request, invocation or call including the IP Address of the interface being a parameter of this API call, ¶0135, teaches the invocation or call requesting the allocation of an additional IP address (i.e. new identifier range) and specifying the IP address, wherein each allocation recorded as a identifier range.
Claim Rejections - 35 USC § 103
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.
Claim(s) 1-7 and 9-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asveren et al. (US 2021/0328858), hereinafter “Asveren” in view of Mildh (US 2022/0286841).
With respect to claim 1, Asveren discloses a method, comprising:
determining, at an application pod, Responsibility of allocation or deallocation of individual protocol identifier (¶0129, teaches the first network interface including first Internet Protocol (IP) (i.e. protocol identifier) address. the allocation of the first network interface to the first Pod being known to the first Kubelet (e.g., Kubelet 209) managing the first node);
receiving, at a centralized identifier allocator (¶0020, teaches allocating (i.e. range allocator) by the Kubernetes system an external network interface including an Internet Protocol address for use by the first Pod, ¶0050, teaches the cloud network 102 includes a Kubernetes system 104 including a Kubernetes master node/control plane 105 as centralized identifier), a request from the application pod (¶0057, teaches a Pod may directly request an additional network interface by invoking or calling the CNI service 216 via the CNI Add API 217 exposed by the CNI service Plugin), the request including an address of the application pod (¶0059, teaches The request, invocation or call including the IP Address of the interface being a parameter of this API call);
assigning, at the centralized identifier allocator (¶0050, teaches the cloud network 102 includes a Kubernetes system 104 including a Kubernetes master node/control plane 105 as centralized identifier), a new identifier range to the application pod in response to the received request (¶0057, teaches Container network interface (CNI) service 216 adds network interfaces in response to requests made via the CNI Add API 217, ¶0059, teaches the invocation of a request for an additional interface, for example a CNI ADD request is an API call via the CNI ADD API. The request, invocation or call including the IP Address of the interface being a parameter of this API call, ¶0135, teaches the invocation or call requesting the allocation of an additional IP address (i.e. new identifier range) and specifying the IP address, wherein each allocation recorded as a identifier range);
sending, from the centralized identifier allocator to a database (¶0050, teaches the cloud network 102 includes a Kubernetes system 104 including a Kubernetes master node/control plane 105 as centralized identifier, ¶0115, teaches communicating or sending messages between Pods, kubelets, and/or applications, ¶0145, teaches the IP address allocation (i.e. range allocator) table is maintained or managed by the master node (e.g., master node 105) and stored in memory of master node 105 and/or in the database 134), the new identifier range to update the database (¶0058, teaches CNI plug-in Daemons on the other nodes update inter-node network connectivity properly to reflect (i.e. update) the failed node status, ¶0082, teaches the Standby SBC Pod (i.e. new identifier range) 212 begins monitoring the Active SBC Pod 202 for an indication of a failure condition, ¶0187, teaches after initialization of said first Pod allocating by the Kubernetes system a second network interface including a second Internet Protocol address for use by the first Pod).; and
responding, from the centralized identifier allocator to the application pod, with the new identifier range (¶0070, teaches the Active SBC Pod 202 generates a request message 3016 for an additional network interfaces (i.e. new identifier range) for the SBC Active Pod 202 within the namespace: workspace-1 (e.g., IP address and/or ports for the Active SBC Pod 202) to use for communications, e.g., a network interface that can be used for communicating with external entities such as UE 1 114 or NE 1 118 which are external to the Kubernetes system 104. While in the example, a single additional network interface is requested multiple network interfaces, may be and in some embodiments are requested, ¶0082, teaches the Standby SBC Pod (i.e. new identifier range) 212 begins monitoring the Active SBC Pod 202 for an indication of a failure condition, ¶0187, teaches after initialization of said first Pod allocating by the Kubernetes system a second network interface including a second Internet Protocol address for use by the first Pod).
However, Asveren does not explicitly teaches range allocator.
Mildh ¶0196, teaches the Donor DU 106 has been pre-configured with a range of IP addresses it can allocate, ¶0211 teaches transmit a message to a donor CU node 108 requesting allocation of a range of IP addresses for allocating to wireless nodes.
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Asveren’s allocating by the Kubernetes system as centralized identifier with range allocator of Mildh, in order to allocate large contiguous blocks instead of many smaller ones, reducing fragmentation (Mildh, ¶0179).
For claim 17, it is a non-transitory computer readable medium claim corresponding to the method of claim 1. Therefore claim 17 is rejected under the same ground as claim 1.
With respect to claim 2, Asveren in view of Mildh discloses the method of claim 1, further comprising an internal discovery function (Asveren, ¶0005, teaches A Pod is the basic execution unit of a Kubernetes application, ¶0207, teaches entities are entities which are internal (i.e. internal discovery) and/or external to the Kubernetes system).
With respect to claim 3, Asveren in view of Mildh discloses the method of claim 1, wherein the database is an in-memory database shared by a microservice using the application pod and at least another microservice (Asveren, ¶0019, teaches migrating and/or changing the allocation of network interface(s) or Internet Protocol address(es) of network interface(s) from one Pod to another Pod in a Kubernetes system, ¶0050, teaches each compute node including a processor and memory, the memory including instructions, e.g., software instructions, which when executed by the processor controls the node to perform one or more functions, ¶0130, teaches SBC services include the manipulation of IP communications signaling and media streams, providing a variety of functions (i.e. microservices) such as security in which the services protect against Denial of Service (DoS) and Distributed DoS (DDoS) attacks, safeguard against toll fraud and service theft, and provide media and signaling encryption to ensure confidentiality and protect against impersonation/masquerade; Multivendor interoperability functions in which the services normalize SIP (Session Initiation Protocol) signaling stream headers and messages to mitigate multivendor incompatibilities ¶0145, teaches stored in memory of master node 105 and/or in the database 134, ¶0176, teaches the Active Pod component 726 is configured to perform the functions/operations discussed in connection with Pod 202 of FIG. 2 and of Pods operating in an active mode of operation in connection with methods described herein as well as the functions/steps described in connection with Active instances of applications on a node such as Pod 202 ).
With respect to claim 4, Asveren in view of Mildh discloses the method of claim 1, further comprising requesting the identifier range an application pod, for transactions and sessions (Asveren, ¶0052, teaches kubernetes worker node 1 106 includes an Active Instance 202, e.g., an Active Session Border Controller Pod 202 which includes a set of containers or workloads that collectively form a software application that provides session border controller services, ¶0078, teaches the Active SBC Pod 202 generates message 3034 which includes identification (i.e. ID) information about the additional network interface assigned to the Active SBC Pod 202 including the Node-Id, namespace, network interface name, and IP address/port number which in this example are Node Id: Node 1, namespace: workspace-1, network interface name: net-0, IP address/port number: IP-1, port 1. Operation proceeds from step 3032 to step 3036, ¶0106, teaches the Standby SBC Pod 212 communicates the message 3100 to via the CNI Add API 217 to the CNI Plug-in service 216 requesting that the network interface IP address and port number IP-1, port 1 previously used by the failed Active SBC Pod 202 be assigned, allocated or migrated to the Standby SBC Pod 212 for the Standby SBC Pod 212's use so that the Standby SBC Pod 212 can take over the servicing of requests from the failed Active SBC Pod 202).
With respect to claims 5 and 18, Asveren in view of Mildh discloses the method of claim 1, further comprising application pods for at least two microservices requesting respective new identifier ranges (Asveren, ¶0112, teaches the SBC defined service which has two instances an Active SBC instance (i.e. first microservice) or Pod and a Standby SBC instance (i.e. second microservice) or Pod to provide redundancy for the overall service, ¶0106, teaches the Standby SBC Pod 212 communicates the message 3100 to via the CNI Add API 217 to the CNI Plug-in service 216 requesting that the network interface IP address and port number IP-1, port 1 previously used by the failed Active SBC Pod 202 be assigned, allocated or migrated to the Standby SBC Pod 212 for the Standby SBC Pod 212's use so that the Standby SBC Pod 212 can take over the servicing of requests from the failed Active SBC Pod 202, Mildh, ¶0211 teaches transmit a message to a donor CU node 108 requesting allocation of a range of IP addresses for allocating to wireless nodes).
With respect to claims 6 and 19, Asveren in view of Mildh discloses the method of claim 1, further comprising requesting a new range when a previously-allocated range is used up at the application pod (Asveren, ¶0106, teaches the Standby SBC Pod 212 communicates the message 3100 to via the CNI Add API 217 to the CNI Plug-in service 216 requesting that the network interface IP address and port number IP-1, port 1 previously used by the failed Active SBC Pod 202 be assigned, allocated or migrated to the Standby SBC Pod 212 for the Standby SBC Pod 212's use so that the Standby SBC Pod 212 can take over the servicing of requests from the failed Active SBC Pod 202, ¶0135, teaches the invocation or call requesting the allocation of an additional IP address (i.e. new range) and specifying the IP address).
With respect to claims 7 and 20, Asveren in view of Mildh discloses the method of claim 1, further comprising:
receiving a death notification, and redistributing the new identifier range to one or more standby pods (Asveren, ¶0013, teaches the Standby instance for a real time session/communication service after detecting that the Active instance for the real time session/communication service is down, e.g., has experienced a software failure or crash (i.e. death notification). This use case requires that the Internet Protocol address used by the failed Active instance be migrated (i.e. redistribution) to the Standby instance for the real time session/communications service, ¶0106, teaches the Standby SBC Pod 212 communicates the message 3100 to via the CNI Add API 217 to the CNI Plug-in service 216 requesting that the network interface IP address and port number IP-1, port 1 previously used by the failed Active SBC Pod 202 be assigned, allocated or migrated to the Standby SBC Pod 212 for the Standby SBC Pod 212's use so that the Standby SBC Pod 212 can take over the servicing of requests from the failed Active SBC Pod 202).
With respect to claim 9, Asveren in view of Mildh discloses the method of claim 1, further comprising creating one or more new pods to handle sessions of a crashed pod (Asveren, ¶0020, teaches upon failure of the first Pod, changing allocation of the external network interface from the first Pod to the second Pod (i.e. creating new pod)).
With respect to claim 10, Asveren in view of Mildh discloses the method of claim 1, further comprising sending dynamic changes to a set of pods in a given namespace (Asveren, ¶0070, teaches the Active SBC Pod 202 generates a request message 3016 for an additional network interfaces for the SBC Active Pod 202 within the namespace: workspace-1 (e.g., IP address and/or ports for the Active SBC Pod 202) to use for communications, e.g., a network interface that can be used for communicating with external entities such as UE 1 114 or NE 1 118 which are external to the Kubernetes system 104).
With respect to claim 11, Asveren in view of Mildh discloses the method of claim 1, further comprising stream control transmission (SCTP) (Asveren, ¶0057, teaches a Kube-proxy 220 which is a network proxy which reflects services as defined in the Kubemetes API on each node and can do simple TCP, UDP, and SCTP stream forwarding or round robin TCP, UDP, and SCTP forwarding across a set of backends).
With respect to claim 12, Asveren in view of Mildh discloses the method of claim 1, further comprising enabling use in public and private clouds (Mildh, ¶0449, teaches a public, private or hosted network).
With respect to claim 13, Asveren in view of Mildh discloses the method of claim 1, further comprising migrating a session to a new pod (Asveren, ¶0105, teaches allocated or migrated to the Standby SBC Pod).
With respect to claim 14, Asveren in view of Mildh discloses the method of claim 1, further comprising migrating a transaction to a new pod (Asveren, ¶0140, teaches the migration procedure to change the allocation of the second IP address from the first Pod to the second Pod is performed).
With respect to claim 15, Asveren in view of Mildh discloses the method of claim 1, further comprising providing ID ranges for at least one of a central unit (CU) X2 interface app, Access and Mobility Management Function (AMF) Next Generation Application Protocol (NGAP) microservice, El interface app or gNodeB-CU-control plane (CP) microservice (Mildh, ¶0052, teaches a donor central unit (CU) node), ¶0069, DU (F1-U,)) ¶0069, teaches Administration and Maintenance (OAM), ¶0437, teaches the functions may be implemented by one or more applications (i.e. E1 app) 4320, ¶0475, teaches 5G 5th Generation as NGAP), ¶0121, teaches the gNB-CU IP) .
With respect to claim 16, Asveren in view of Mildh discloses the method of claim 1, further comprising avoiding duplicate identifier allocation across multiple container or POD instances (Mildh, ¶0193, teaches signaling for IP address allocation to IAB nodes, while avoiding the need to allocate the IP address by the Donor CU, meaning that the Donor CU is not required to know anything about the IP network topology. The solution may also allow the allocation of multiple IP addresses to IAB nodes).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Asveren in view of Mildh, and further in view of Gujar et al. (US 11822970B2), hereinafter “Gujar”.
With respect to claim 8, Asveren in view of Mildh discloses the method of claim 1. However, Asveren in view of Mildh remain silent on where in the request further comprises a request for allocation of a range of 1000 IDs in 1 message.
Gujar discloses further where in the request further comprises a request for allocation of a range of 1000 ID in 1 message (See Fig. 3, step 310, 320 and 330, Col-4, II. 54-58, teaches At 310 in FIG. 3 , node-A 110A retrieves batch of IDs 124A from shared pool 172 to cache-A 122A. For example in FIG. 2 , the IDs may be retrieved to service future ID allocation requests from a distributed firewall controller (i.e., ID consumer). In this case, the IDs may be used for uniquely identifying firewall rules 262 across cluster 102, Col-8, II. 38-43, teaches node-A 110A simply has to retrieve a new batch of IDs (i.e. 1000 ID range) from shared pool 172 the next time it receives a new ID allocation request. In practice, shared pool 172 may be sufficiently large (e.g., 2^30) to meet the ID consumption requirement within cluster 102).
Therefore, it would be obvious to one of ordinary skill in the art before the effective filing date of the invention to modify Asveren’s in view of Mildh’s system with where in the request further comprises a request for allocation of a range of 1000 ID in 1 message of Gujar, in order to optimize the range assignment when done in bulk and easier to track ranges if they are allocated in a single request (Gujar, Col-6, II. 1-4).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US11336739B1 teaches the first message instructs the first server group to reduce a first resource allocation level associated with a network-accessible computing resource, while the second message instructs the second server group to increase a second resource allocation level associated with the resource. The resource allocation levels designate respective proportions of the network-accessible computing resource shared among the server groups. Request traffic associated with providing services via the on-demand computing services environment is transferred from the first server group to the second server group after decreasing the first resource allocation level and increasing the second resource allocation level.
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 GOLAM MAHMUD whose telephone number is (571)270-0385. The examiner can normally be reached Mon-Fri 8.00-5.00pm.
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, Umar Cheema can be reached on 5712703037. 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.
/GOLAM MAHMUD/Examiner, Art Unit 2458
/UMAR CHEEMA/Supervisory Patent Examiner, Art Unit 2458