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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 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.
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 1-6, 8-13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Moyer (US 20210318914 A1) hereafter Moyer in view of Bumbulis (US 20170357683 A1), hereafter Bumbulis.
Regarding claim 1, Moyer teaches:
A method of managing a custom resource in a container orchestration (CO) system, the method comprising: (Claim 1. A method for facilitating communication between a multi-cluster management (MCM) system and a cluster managed by the MCM system, the method comprising:)
receiving, from a manager at a management cluster of the CO system, an intent identifier that has been set in the manager as a current intent identifier associated with intended current state of the custom resource, the management cluster including a controller configured to manage the custom resource, the management cluster storing the intent identifier in a database in association with the custom resource; ([0018] With respect to intent channel 202, each time a user 110 initiates a management operation on cluster 104 via UI 108, a service 112 responsible for handling the operation can construct a data structure (such as, e.g., a Kubernetes custom resource definition (CRD)) that defines/declares a “desired state” of cluster 104 in accordance with the management operation and can pass the constructed data structure … [0030] In response to the API invocation, intent service 204 can create an intent object that includes (1) the data structure constructed by service 112, (2) a unique intent ID… .see also [0022-0023] E.N: Moyer teaches am intent ID associated with a desired state and teaches determining which intent represents the latest desired state. [0013] MCM system 102 includes a user interface (UI) 108 that is accessible by a set of users 110 (e.g., information technology (IT) staff, application developers, etc.) of organization 106. In addition, MCM system 102 includes a number of software services 112(1)-(M) that implement, in cooperation with cluster-side service extensions 114(1)-(N), various functionalities/features for managing clusters 104(1)-(N)… . see also [0033] E.N.: Moyer’s cluster side service extension reacts to the Kubernetes object representing the desired state and performs the associated management operations )
after the intent identifier is received, receiving, from the manager at the management cluster, a request that updates state of the custom resource; ([0027] Starting with block 302 of workflow 300 in FIG. 3A, a service 112 of MCM system 102 can receive (via, e.g., UI 108) a user request/command to execute a management operation on cluster 104. Examples of such management operations include creating/updating/deleting a namespace, setting an access policy, starting or canceling an inspection scan, and so on. E.N.: Moyer teaches management request that change mange state)
executing, by the controller of the management cluster, a management process for the custom resource in the CO system in response to the match and the request. ([0034] Upon receiving the intent objects, intent agent 208 can apply each intent object to cluster 104 (block 360). In certain embodiments, this step can involve extracting the data structure (e.g., Kubernetes CRD) encapsulated in each intent object and persisting that data structure/CRD as a new Kubernetes object in Kubernetes data store 220. This, in turn, can cause a service extension on cluster 104 that is associated with service 112 (i.e., the service that originally constructed the data structure at block 304) to access the newly created Kubernetes object from data store 220 and take one or more actions for executing the corresponding management operation on the cluster)
Moyer does not appear to explicitly teach: an intent identifier that has been set in the manager as a current intent identifier , determining, at the management cluster, a match between an intent identifier in the request and the intent identifier stored in the database; and
However, Bumbulis teaches: [0031] Metastore 134 may store a directory of available storage units as well as storage cluster configuration information. The storage cluster configuration information may define “epochs” which specify a primary storage unit and secondary storage units. Management host 130 and each storage unit of cluster 120 are aware of the current epoch [0039] FIG. 5 also shows the configuration of the current epoch (i.e., epoch 0) stored within metastore 234, and the storage of the metadata E=0 to denote the current epoch in each of primary storage unit 222, secondary storage unit 224 and secondary storage unit 226. Also shown in association with each storage unit are local memory buffers associated with the keys 0, 2, 4, 6, . . ..; see also [0037-0042].
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Moyer’s intent based cluster management system to use Bumbulis’s current identifier validation technique such that an identifier associated with a management request is compared with a stored current identifier before the request is processed. One would have been motivated to make such combination to prevent stale or out of order management request from being executed after a newer intended state has become current. Bumbulis method of maintain a current epoch identifier and comparing the epoch identified in an incoming request with the stored current epoch identifier, with a nonmatching request being ignored or rejected. Applying Bumbulis’s current identifier comparison to Moyer’s intent IDs would have predictable ensured that only management request corresponding to the currently valid intent are processed. See Bumbulis [0031-0032] [0037-0041].
Regarding claim 2, Moyer teaches:
The method of claim 1, wherein the intent identifier stored in the database comprises a first intent identifier, the request comprises a first request, and the management process comprises a first management process, the method further comprising: (See [0013][0018][0030][0033] See note of claim 1)
receiving, from the manager at the management cluster, a second intent identifier that has been set in the manager as an updated current identifier for the custom resource, the second intent identifier being different from the first intent identifier. ([0036] It should be appreciated that workflows 300 and 350 of FIGS. 3A and 3B are illustrative and various modifications are possible. For example, although workflow 300 assumes that a new intent object is created in response to each user request/command to execute a management operation on cluster 104, in some cases the requested management operation may apply to a cluster object that is already associated with an intent object maintained in intent data store 206. See also [0022][0030] E.N.: each created intent object has a unique ID, alter intent object has a different intent ID. Moyer teaches the multiple intent IDs and identifies the later intent as the latest desired state.)
executing, by the controller of the management cluster, a second management process for the custom resource in the CO system in response to the other match and the second request. ([0034] Upon receiving the intent objects, intent agent 208 can apply each intent object to cluster 104 (block 360). In certain embodiments, this step can involve extracting the data structure (e.g., Kubernetes CRD) encapsulated in each intent object and persisting that data structure/CRD as a new Kubernetes object in Kubernetes data store 220. This, in turn, can cause a service extension on cluster 104 that is associated with service 112 (i.e., the service that originally constructed the data structure at block 304) to access the newly created Kubernetes object from data store 220 and take one or more actions for executing the corresponding management operation on the cluster)
Moyer does not appear to explicitly teach: replacing, by the management cluster, the first intent identifier with the second intent identifier in the database; after the second intent identifier is received, receiving, from the manager at the management cluster, a second request that updates the state of the custom resource; determining, at the management cluster, another match between an intent identifier in the second request and the second intent identifier stored in the database; and
However, Bumbulis teaches: [0058] A new cluster of storage units is defined at S1650. The new cluster includes a primary storage unit and at least on secondary storage unit. The new cluster may be associated with a new epoch and the configuration thereof may be stored in metastore 234. FIG. 18 illustrates new configuration information stored in metastore 234 in association with new epoch 0. The new configuration information indicates that storage unit 234 is now the primary storage unit of the cluster, and that storage unit 228 has been added to the cluster. See also [0040][0059][0060]
Same motivation as claim 1
Regarding claim 3, Moyer teaches:
The method of claim 2, wherein the management cluster stops the first management process in response to replacement of the first intent identifier with the second intent identifier. ([0027] Starting with block 302 of workflow 300 in FIG. 3A, a service 112 of MCM system 102 can receive (via, e.g., UI 108) a user request/command to execute a management operation on cluster 104. Examples of such management operations include creating/updating/deleting a namespace, setting an access policy, starting or canceling an inspection scan, and so on. E.N.: Moyer teaches management process that can be stop/cancel)
Regarding claim 4, Moyer teaches:
The method of claim 1, wherein the manager executes in a datacenter and the management cluster executes in a site remote from the datacenter. ([0012] In one set of embodiments, MCM system 102 may be deployed on one or more physical or virtual machines that are located on-premises with respect to organization 106, such as at a data center that is owned and operated by the organization. In other embodiments, MCM system 102 may be hosted in a public or private cloud and maintained by, e.g., a third-party SaaS (Software-as-a-Service) provider. Similarly, each Kubernetes cluster 104 may be deployed on-premises with respect to organization 106 or hosted off-premises in a public or private cloud environment.)
Regarding claim 5, Moyer teaches:
The method of claim 4, wherein the custom resource comprises a workload cluster configured to execute at the site or another site remote from the datacenter. ([0012] In other embodiments, MCM system 102 may be hosted in a public or private cloud and maintained by, e.g., a third-party SaaS (Software-as-a-Service) provider. Similarly, each Kubernetes cluster 104 may be deployed on-premises with respect to organization 106 or hosted off-premises in a public or private cloud environment.)
Regarding claim 6, Bumbulis teaches:
The method of claim 1, wherein the request comprises a first request, the method further comprising: receiving, from the manager at the management cluster, a second request that updates the state of the custom resource; ([0046] It will now be assumed that a second write request including a second key-value pair is received at S310 by primary storage unit 222 as shown in FIG. 12. Again, the value of the pair is persisted at S320 in the key-value store of primary storage unit 222. FIG. 12 illustrates such storage of the value “c” within the local buffer of primary storage unit 222, and updating of its list of durable values (e.g., D: 0, 2).)
determining, by the management cluster, that a difference between an intent identifier in the second request and the intent identifier stored in the database; and dropping, by the management cluster, the second request in response to the difference. ([0040] Next, at S320, the key-value pair of the write request and an identifier of the client are persisted in a key-value store of the primary storage unit. FIG. 6 illustrates such storage of the value “a” within the local buffer of primary storage unit 222. Primary storage unit 222 maintains lists of globally-durable (i.e., GD) and locally durable (i.e., D) key-value pairs as also shown in FIG. 6 (i.e., D: 0). According to some embodiments, the epoch identified in the incoming write request is compared against the current epoch identifier stored at the primary storage unit. If the epochs do not match, the write request is ignored and/or rejected.)
Regarding claim 8, Moyer teaches the elements of claim 1 as outlined above. Miriyala also teaches:
A non-transitory computer readable medium comprising instructions to be executed in a computing device to cause the computing device to carry out a method of managing a custom resource in a container orchestration (CO) system, the method comprising: (Claim 8. A non-transitory computer readable storage medium having stored thereon program code executable by a computer system running a multi-cluster management (MCM) system, the program code embodying a method for facilitating communication between the MCM system and a cluster managed by the MCM system, the method comprising)
Regarding claim 9, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 11, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 15, Moyer teaches the elements of claim 1 as outlined above. Miriyala also teaches:
A computer system, comprising. (Claim 15. A computer system executing a multi-cluster management system, the computer system comprising: a processor; and a non-transitory computer readable medium having stored thereon program code that, when executed by the processor, causes the processor to:)
Regarding claim 16, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 19, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Moyer (US 20210318914 A1) in view of Bumbulis (US 20170357683 A1) and in further view of Miriyala (US 20230104568 A1) hereafter Miriyala.
Regarding claim 7, Moyer does not appear to explicitly teach:
The method of claim 1, wherein the custom resource comprises a workload cluster, wherein the management process comprises deployment of the workload cluster, wherein the CO system comprises a data center and a plurality of sites, the management cluster disposed in the data center, the workload cluster disposed in the plurality of sites, the workload cluster executing containerized network functions (CNFs).
However, Miriyala teaches: ([0036] In some examples, each of data center(s) 10 may represent one of many geographically distributed network data centers, which may be connected to one another via service provider network 7, dedicated network links, dark fiber, or other connections. As illustrated in the example of FIG. 1, data center(s) 10 may include facilities that provide network services for customers. A customer of the service provider may be a collective entity such as enterprises and governments or individuals. For example, a network data center may host web services for several enterprises and end users. Other exemplary services may include data storage, virtual private networks, traffic engineering, file service, data mining, scientific- or super-computing, and so on. Although illustrated as a separate edge network of service provider network 7, elements of data center(s) 10 such as one or more physical network functions (PNFs) or virtualized network functions (VNFs) may be included within the service provider network 7 core.)
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Moyer and Miriyala before them, to include Miriyala’s distributed workload cluster architecture. One would have been motivated to make such combination to manage and deploy containerized network functions across distributed sites as taught by Miriyala. See [0277-0278][0090-0093].
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Conclusion
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 CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m 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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights