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 .
Claims 1-20 are pending.
Claim Objections
Claims 7 and 15 are objected to because of the following informalities:
There is a typographical error in the claims. For the purpose of this office action the Examiner is interpreting the claim to read:
“… identify the first plurality of network resources assigned to the first plurality…”.
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 of this title, 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 1, 3, 8, 9, 11, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Chamatry et al. (US 2024/0163727), in view of Desai et al. (US 2020/0389816)(“Desai”), and in further in view of Kwon et al. (US 2023/0189077)(“Kwon”).
As per claim 1, Chamatry teaches an apparatus, comprising:
a memory (i.e., “memory coupled to the one or more data processors”, see ¶0018), comprising:
information on one or more network resources configured for allocation in one or more containerized clusters (see for example, ¶0077, “Kubernetes control compute and storage resources…”, where impliedly the control of computer/storage resources requires stored knowledge of information on available compute and storage resources. Also see for example, Fig. 11, ref. 1102 and ¶0111, i.e., “Monitor one or more processing resources being assigned to one or more container in a plurality of containers of a cloud native radio access”, which further suggests using system memory to store one or more network/processing resources for monitoring and allocation purposes);… and
a processor communicatively coupled to the memory (i.e., “memory coupled to the one or more data processors”, see ¶0018) and configured to:
…determine that one or more network resources are available for allocation to one or more pods (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”, which impliedly requires a determination of available resources for allocation to newly added pods);
divide the one or more network resources into a first plurality of network resources and a second plurality of network resources (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”, which also impliedly comprises a division of available resources to each new pod);
generate a first pod in the one or more containerized clusters… (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”); and
generate a second pod in the one or more containerized clusters … (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”, which anticipates adding a second pod).
As per claim 1, Chamatry does not expressly teach the generated pods being assigned to a particular group of cell identifiers (IDs) (i.e., “a memory comprising … one or more cell identifiers (IDs), each cell ID corresponding to at least one cell configured to be associated with at least one pod in the one or more containerized clusters … determine that the one or more network resources are available for allocation to the one or more cell IDs; … assign the first plurality of network resources to a first plurality of cell IDs; assign the second plurality of network resources to a second plurality of cell IDs.”)
Nevertheless, in the same art of cloud-based management of wireless networks, Desai teaches assigning cell identifiers (IDs) (e.g., one or more APs, which are impliedly associated with an ID, e.g., AP/cell ID) to pods (see for example, Fig. 3, and ¶0025-0026, “the access points within each site can by dynamically and automatically grouped into RF neighborhoods (RFNs) … Management service can include one or more pods … belonging to a specific RFN. For example, … pod 134 can receive telemetry from RFN 128 (e.g., for AP 114 and AP 116”. Also see ¶0035 and ¶0041, “Each RFN can have one or more APs within a threshold distance and/or signal strength. Like FIGS. 1 and 4, the RFNs can be in communication with network 516 through load balancer service, which can direct telemetry from an RFN to a certain pod based on the AP's RFN_ID 560.”).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to similarly assign the subscriber handling pods to respective sets of cells or APs (i.e., AP/cell ids), or in other words configuring the memory/processor of Chamatry to “store one or more cell identifiers (IDs), each cell ID corresponding to at least one cell configured to be associated with at least one pod in the one or more containerized clusters … determine that the one or more network resources are available for allocation to the one or more cell IDs; … assign the first plurality of network resources to a first plurality of cell IDs; assign the second plurality of network resources to a second plurality of cell IDs.”. The obvious motivation for doing so would have been for organizational efficiencies, such as easier tracking and management of AP or cell resources within a particular geographic zone or neighborhood.
Secondly, Chamatry does not expressly teach, prior to determining that the one or more network resources are available for allocation, determining whether the one or more network resources are unassigned.
Nevertheless, in the same art cloud radio access networking, Kwon teaches determining that one or more network resources are available for allocation to containers based on determining one or more network resources are idle/unassigned (see ¶0040, i.e., “Thus, the server 232a may allocate the idle resource, left after allocating the resource 233a for processing the first cell site 210a, to the resource 233b for processing at least one RU included in the second cell site 210b, minimizing or reducing idle resources”, also see ¶0062, i.e., “container-based scaling out or scaling in…”).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to similarly pool one or more unassigned/idle resources for allocation to the generated/scaled-out pods in Chamatry. The obvious motivation for doing so would have been to minimize or reduce idle resources.
As per claim 3, Chamatry further teaches wherein the processor is further configured to:
identify the first plurality of network resources assigned to the first pod and the second plurality of network resources assigned to the second pod (see Fig. 11, ref. 1102, and ¶0111, i.e., “monitoring of one or more processing resources being assigned to one or more containers (e.g., a pod 604) in a plurality of containers”);
unassign the first plurality of network resources from the first pod (i.e., “change, based on the determining, the assignment of one or more processing resources.”, see Fig. 11, ref. 1104, in view of Fig. 7A, and ¶0111, which anticipates the change resulting in reduction or scale-in of pod resources);
unassign the second plurality of network resources from the second pod (see Fig. 11, ref. 1104, in view of Fig. 7A, and ¶0111, which anticipates the change resulting in reduction or scale-in of a plurality of pods “assigned to one or more containers (e.g., a pod 604) in a plurality of containers”, e.g., the second pod);
…
determine that … network resources are available for reallocation to the first pod and the second pod (also see Fig. 11, ref. 1102, and ¶0111, “change, based on the determining, the assignment of one or more processing resources.”, see Fig. 11, ref. 1104, which when viewed in combination with Fig. 7b and ¶0090, anticipates, at a later point in time, performing a scale-out operation of resources for pods, e.g., determine that … network resources are available for reallocation back to the first and second pod if needed);
divide the … network resources into a third plurality of network resources and a fourth plurality of network resources (also see Fig. 11, ref. 1102, and ¶0111, “change, based on the determining, the assignment of one or more processing resources.”, see Fig. 11, ref. 1104, which when viewed in combination with Fig. 7b and ¶0090, anticipates at a later point in time, performing a scale-out operation of resources for pods, e.g., divide the plurality of unassigned network resources into a third plurality of network resources and a fourth plurality of network resources);
assign the third plurality of network resources to the first pod; assign the fourth plurality of network resources to the second pod (i.e., “change, based on the determining, the assignment of one or more processing resources.”, see Fig. 11, ref. 1104, which when viewed in combination with Fig. 7b and ¶0090, anticipates at a later point in time, performing a scale-out operation of resources for pods, e.g., assign to the third plurality of network resources to the first pod and a fourth plurality of resources to the second pod); and
update the first pod in the one or more containerized clusters …; and update the second pod in the one or more containerized clusters… (Also see Fig. 11, ref. 1104, where impliedly the changes are reflected by updating the first and second pods).
As previously noted, Chamatry does not expressly teach each pod being associated with a plurality of cell IDs (i.e., “identify the first plurality of network resources assigned to the first plurality of cell IDs and the second plurality of network resources assigned to the second plurality of cell IDs; unassign the first plurality of network resources from the first plurality of cell IDs; unassign the second plurality of network resources from the second plurality of cell IDs;…
determine that the plurality of unassigned network resources are available for reallocation to the first plurality of cell IDs and the second plurality of cell IDs; … assign the third plurality of network resources to the first plurality of cell IDs; assign the fourth plurality of network resources to the second plurality of cell IDs; update the first pod in the one or more containerized clusters comprising the first plurality of cell IDs; and update the second pod in the one or more containerized clusters comprising the first plurality of cell IDs”).
Nevertheless, in the same art as noted above, Desai teaches assigning cell identifiers (IDs) (e.g., one or more APs) to particular pods (see for example, Fig. 3, and ¶0025-0026).
The same motivation for combining Chamatry and Desai in claim 1, applies equally well to claim 8.
Furthermore, Chamatry does not expressly teach the step of “combin[ing] the first plurality of network resources and the second plurality of network resources into a plurality of unassigned network resources” from which unassigned resources can be allocated (i.e., determine that the plurality of unassigned network resources are available for reallocation to the first plurality of cell IDs and the second plurality of cell IDs; divide the plurality of unassigned network resources network resources into a third plurality of network resources and a fourth plurality of network resources”).
Nevertheless, in the same art as noted above, Kwon teaches the idea of using a resource pool (e.g., a combination of a plurality unassigned network resources) for managing and assigning resources in a cloud/container environment upon request (see ¶0120, also see ¶0062, “container-based scaling out or scaling in may be performed.”).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, following scale-in by the first and second pod in Chamatry (see “scale-in”, ¶0081 and ¶0090), to release the resources into a similar pool (i.e., a combined set of unassigned resources, as claimed) to thereafter accommodate later scale-out events. The obvious motivation for doing so would have been to easily manage and deploy unused, released, or idle resources in Chamatry.
As per claim 8, Chamatry further teaches wherein the processor is further configured to:
identify the first plurality of network resources assigned to the pod and the second plurality of network resources assigned to the second pod (i.e., “one or more pods 604 may be associated with a predetermined processing capacity”, see ¶0086, which anticipates identifying the network resources/processing capacities of each pod. Also see Fig. 11, ref. 1102, and ¶0111, i.e., “monitoring of one or more processing resources being assigned to one or more containers (e.g., a pod 604) in a plurality of containers”);
unassign the first plurality of network resources from the first pod (i.e., “change, based on the determining, the assignment of one or more processing resources.”, see Fig. 11, ref. 1104, in view of Fig. 7A, and ¶0111, which anticipates the change resulting in reduction or scale-in of pod resources);
unassign the second plurality of network resources from the second pod (see Fig. 11, ref. 1104, in view of Fig. 7A, and ¶0111, which anticipates the change resulting in reduction or scale-in of a plurality of pods “assigned to one or more containers (e.g., a pod 604) in a plurality of containers”, e.g., the second pod);
…
determine that the plurality of … network resources are available for reallocation to a third pod, a fourth pod, and a fifth pod (i.e., “free up capacity and release it”, see ¶0081, where impliedly the network resources are thus available for allocation to other pods, e.g., third pod, fourth pod, fifth pod, etc.);
divide the plurality of … network resources into a third plurality of network resources, a fourth plurality of network resources, and a fifth plurality of network resources (see ¶0040 and ¶0080, which anticipates a “scale-out” or increasing to any number of subscriber handling pods (e.g., dividing, third plurality of network resources, a fourth plurality of network resources, and a fifth plurality of network resources) at a later time);
assign the third plurality of network resources to the third pod; assign the fourth plurality of network resources to the fourth pod; assign the fifth plurality of network resources to the fifth pod; generate a third pod in the one or more containerized clusters …; generate a fourth pod in the one or more containerized clusters …; and generate a fifth pod in the one or more containerized clusters … (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”, which anticipates assigning resources to, and generating, any number of pods, e.g., a third pod, fourth pod, fifth pod, etc., as needed. Alternatively, if not anticipated by the plural use of “pods” in ¶0080, similar to a duplication of parts, see MPEP §2144.05.VI.B, the addition of third, fourth, or fifth pods has no patentable significance unless a new and unexpected resource is produced. Here, however, using the scale-out processes in Chamatry to create a third, fourth, fifth pod, or any number of pods, does not result in an unexpected result).
As previously noted, Chamatry does not expressly teach each pod being associated with a plurality of cell IDs (i.e., “… identify the first plurality of network resources assigned to the first plurality of cell IDs and the second plurality of network resources assigned to the second plurality of cell IDs; unassign the first plurality of network resources from the first plurality of cell IDs; unassign the second plurality of network resources from the second plurality of cell IDs;
… determine that the plurality of unassigned network resources are available for reallocation to a third plurality of cell IDs, a fourth plurality of cell IDs, and a fifth plurality of cell IDs; assign the third plurality of network resources to the third plurality of cell IDs; assign the fourth plurality of network resources to the fourth plurality of cell IDs; assign the fifth plurality of network resources to the fifth plurality of cell IDs; generate a third pod in the one or more containerized clusters comprising the third plurality of cell IDs; generate a fourth pod in the one or more containerized clusters comprising the fourth plurality of cell IDs; and generate a fifth pod in the one or more containerized clusters comprising the fifth plurality of cell IDs.”).
Nevertheless, in the same art as noted above, Desai teaches assigning cell identifiers (IDs) (e.g., one or more APs) to particular pods (see for example, Fig. 3, and ¶0025-0026).
The same motivation for combining Chamatry and Desai in claim 1, applies equally well to claim 8.
Furthermore, Chamatry does not expressly teach the step of “combin[ing] the first plurality of network resources and the second plurality of network resources into a plurality of unassigned network resources” from which unassigned resources can be allocated (i.e., determine that the plurality of unassigned network resources are available for reallocation …; divide the plurality of unassigned network resources…”).
Nevertheless, in the same art as noted above, Kwon teaches the idea of using a resource pool (e.g., a combination of a plurality unassigned network resources) for managing and assigning resources in a cloud/container environment upon request (see ¶0120, also see ¶0062, “container-based scaling out or scaling in may be performed.”).
The same motivation for combining Chamatry and Kwon in claim 3, applies equally well to claim 8.
Claims 9, 11, 16, and 17 are rejected under the same rationale as claims 1, 3 and 8 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
Claims 2, 4, 5, 10, 12-13, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chamatry, Desai and Kwon, in further view of Nagaprakash et al. (US 2022/0329486)(“Nagaprakash”).
As per claim 2, Chamatry further teaches wherein the processor is further configured to:
…identify the first plurality of network resources assigned to the first pod and the second plurality of network resources assigned to the second pod (i.e., “one or more pods 604 may be associated with a predetermined processing capacity”, see ¶0086, which anticipates identifying the network resources/processing capacities of each pod);
unassign the first plurality of network resources from the first pod (see “scale-in”, see ¶0081 and ¶0090);
unassign the second plurality of network resources from the second pod (see “scale-in”, see ¶0081 and ¶0090);
…
determine that the plurality of … network resources are available for reallocation to a third pod and a fourth pod (i.e., “free up capacity and release it”, see ¶0081, where impliedly the network resources are thus available for other pods);
divide the plurality of … network resources into a third plurality of network resources and a fourth plurality of network resources (see ¶0040 and ¶0080, which anticipates a “scale-out (e.g., increase) subscriber handling pods” at a later time, which impliedly comprising a division of available resources for each new pod, e.g., third and fourth plurality of network resources);
assign the third plurality of network resources to the third pod; assign the fourth plurality of network resources to the fourth pod; generate a third pod in the one or more containerized clusters …; generate a fourth pod in the one or more containerized clusters … (see ¶0040 and ¶0080, i.e., “scale-out (e.g., increase) subscriber handling pods”, which anticipates assigning resource and generating any number of pods, e.g., a third and fourth pod); and
deactivate the first pod and the second pod (see “scale-in”, ¶0081 and ¶0090).
As previously noted, Chamatry does not expressly teach each pod being associated with a plurality of cell IDs (i.e., …identify the first plurality of network resources assigned to the first plurality of cell IDs and the second plurality of network resources assigned to the second plurality of cell IDs; unassign the first plurality of network resources from the first plurality of cell IDs; unassign the second plurality of network resources from the second plurality of cell IDs; …
determine that the plurality of unassigned network resources are available for reallocation to a third plurality of cell IDs and a fourth plurality of cell IDs; … assign the third plurality of network resources to the third plurality of cell IDs; assign the fourth plurality of network resources to the
fourth plurality of cell IDs; generate a third pod in the one or more containerized clusters comprising the third plurality of cell IDs; generate a fourth pod in the one or more containerized
clusters comprising the fourth plurality of cell IDs …).
Nevertheless, in the same art as noted above, Desai teaches assigning cell identifiers (IDs) (e.g., one or more APs) to particular pods ((see for example, Fig. 3, and ¶0025-0026).
The same motivation for combining Chamatry and Desai in claim 1, applies equally well to claim 2.
Furthermore, Chamatry does not expressly teach the step of “combin[ing] the first plurality of network resources and the second plurality of network resources into a plurality of unassigned network resources” from which unassigned resources can be allocated (i.e., determine that the plurality of unassigned network resources are available for reallocation …; divide the plurality of unassigned network resources…”).
Nevertheless, in the same art as noted above, Kwon teaches the idea of using a resource pool (e.g., a combination of a plurality unassigned network resources) for managing and assigning resources in a cloud/container environment upon request (see ¶0120, also see ¶0062, “container-based scaling out or scaling in may be performed.”).
The same motivation for combining Chamatry and Kwon in claim 3, applies equally well to claim 2.
Finally, the combination of Chamatry, Desai, and Kwon, does not expressly teach the concept of a maintenance window as claimed (i.e., “during a maintenance window, identify the first plurality…”).
Nevertheless, in the same art of autoscaling, Nagaprakash teaches the ability to making autoscaling decisions at configurable time windows (see ¶0087, read as during a maintenance window).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to similarly perform autoscaling in Chamatry (see ¶0081 or ¶0090) during a similar configurable time window. The obvious motivation for doing so would have been to ensure regular maintenance and redistribution of resources if needed.
As per claim 4, the combination of Chamatry, Desai, and Kwon does not expressly teach wherein the first pod and the second pod are updated outside of a maintenance window.
Nevertheless, in the same art as noted above, Nagaprakash further suggests the ability to perform scaling of Kubernetes pods in response to certain events (e.g., “in response to determining that the number of connections to devices serviced by at least one of network configuration controllers 570 is greater than the maximum number of connections” see ¶0087, read as outside of a maintenance window).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to similarly perform the scaling actions in Chamatry (see ¶0081 or ¶0090) response to certain events. The obvious motivation for doing so would have been to allow the system in Chamatry to easily react to certain network events that require resource scaling.
As per claim 5, the combination of Chamatry, Desai, and Kwon does not expressly teach wherein the first pod and the second pod are updated during a maintenance window.
Nevertheless, in the same art as noted above, Nagaprakash teaches the ability to making autoscaling decisions at configurable time windows (see ¶0087, read as during a maintenance window).
The same motivation for combining Chamatry, Desai, Kwon, and Nagaprakash in claim 2, applies equally well to claim 5.
Claims 10, 12-13, and 18-20 are rejected under the same rationale as claims 2, 4, and 5 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
Allowable Subject Matter
Claims 6-7 and 14-15 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brendan Higa whose telephone number is (571)272-5823. The examiner can normally be reached Monday - Friday 8:30 AM - 5:00 PM.
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, James Hwang can be reached at (571) 272-4036. 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.
/BRENDAN Y HIGA/Primary Examiner, Art Unit 2441