DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1 – 20 are pending for examination.
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/10/24 and 10/22/24 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
The information disclosure statement filed 04/25/24 fails to comply with 37 CFR 1.98(a)(2), which requires a legible copy of each cited foreign patent document; each non-patent literature publication or that portion which caused it to be listed; and all other information or that portion which caused it to be listed. It has been placed in the application file, but the information referred to therein has not been considered.
There are no copy of three CN documents and therefore, the three CN documents are not considered.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claim 10, limitation “capable of” is indefinite. The limitation must be precise.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
As to claim 1, the claim recites
A method, comprising:
storing, by a controller module executing on a computer system, a function map for an operational entity managed by the controller module, wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity to different lifecycle stages of the operational entity;
implementing, by the controller module, at least a portion of an operational scenario for a target computer environment that includes the operational entity, wherein the implementing includes: receiving an instruction to cause the operational entity to be transitioned from a first state to a second state;
identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and
issuing a control API call to invoke the function.
Step 2A:
Prong 1: the limitations of wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity;
implementing, by the controller module, at least a portion of an operational scenario for a target computer environment that includes the operational entity, wherein the implementing includes: receiving an instruction to cause the operational entity to be transitioned from a first state to a second state;
identifying, based on the function map, a function invokable to transition the operational entity to the second state;
Prong 2:
The additional element of storing, by a controller module executing on a computer system, a function map for an operational entity managed by the controller module; issuing a control API call to invoke the function merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
The additional element in different lifecycle stages of the operational entity; a current lifecycle stage of the operational entity merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. MPEP 2106.05(h).
Thus, these additional elements do not integrate the judicial exception into a practical application.
Step 2B:
The additional element of storing, by a controller module executing on a computer system, a function map for an operational entity managed by the controller module; issuing a control API call to invoke the function merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
The additional element in different lifecycle stages of the operational entity; a current lifecycle stage of the operational entity merely link the use of the judicial exception to a particular technological environment or field of use, thus does not integrate the judicial exception into a practical application. MPEP 2106.05(h).
Accordingly, the additional elements do not amount to significantly more than the abstract idea.
As to claim 2. The method of claim 1, wherein the operational entity implements a different set of a plurality of functions of the control API than another operational entity controlled by the controller module are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 3. The method of claim 1, wherein the instruction defines a unique identifier associated with the operational entity, and wherein the method further comprises: accessing, based on the unique identifier, a blueprint that corresponds to the operational entity, wherein the blueprint specifies the current lifecycle stage of the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 4. The method of claim 1, further comprising:
generating, by the controller module, the function map, wherein the generating includes: invoking a describe function implemented by the operational entity are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process; and
receiving, from the operational entity, a response that identifies the functions of the control API that are implemented by the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d), wherein the function map is generated based on the response are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 5. The method of claim 1, further comprising: generating, by the controller module, the function map wherein the generating includes receiving, from the operational entity, a broadcast that identifies the functions of the control API that are implemented by the operational entity, wherein the function map is generated based on the broadcast merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 6. The method of claim 1, wherein the controller module is part of a hierarchy of controller modules, wherein the hierarchy includes an orchestrator controller module at a top level of the hierarchy that is executable to issue a set of instructions to a set of controller modules at one or more other levels of the hierarchy, and wherein the set of controller modules includes the controller module merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 7. The method of claim 6, wherein the instruction is received from the orchestrator controller module, and wherein the method further comprises: sending, by the controller module to the orchestrator controller module, a message that indicates that the instruction was implemented successfully merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 8. The method of claim 1, wherein the implementing further includes:
receiving, by the controller module, another instruction that identifies an operation to be performed by a different operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d);
determining, by the controller module based on the other instruction, that the different operational entity is controlled by a different controller module are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process; and
routing, by the controller module, the other instruction to the different controller module merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 9. The method of claim 1, further comprising: identifying, by the controller module, which operational entities of the target computer environment to manage, wherein the identifying includes accessing operational entity information defining unique identifiers that correspond to a particular set of operational entities that includes the operational entity are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 10. The method of claim 1, wherein the operational scenario includes starting up a database service having one or more database servers capable of performing database transactions on behalf of users of the computer system are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 11. The method of claim 1, wherein the control API call is issued to a routing layer and does not specify whether the operational entity is remote relative to a local environment of the controller module, wherein the routing layer is operable to make a determination on whether the operational entity is within the local environment or remote to the local environment and use the determination to perform a routing operation in relation to the operational entity are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 12. This is a non-transitory computer-readable medium claim of claim 1. See rejection for claim 1 above. Further, non-transitory computer-readable medium having program instructions stored thereon are additional elements that merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea.
As to claim 13. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise:
receiving an instruction identifying an operation to be performed by a different operational entity that is managed by the computer system; and
issuing a control API call to invoke a function to cause the different operational entity to perform the operation, and wherein the different operational entity implements a different set of functions of the control API than the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 14. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise:
generating the function map are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process, including receiving a communication from the operational entity that identifies the functions of the control API that are implemented by the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d), wherein the function map is generated based on the communication are functions that can be reasonably carried out in the human mind with the aid of pen and paper, through observation, evaluation, judgment, opinion, thus it is reasonable to identify these limitation as reciting a mental process.
As to claim 15. The non-transitory computer-readable medium of claim 12, wherein the operations further comprise:
identifying which operational entities of the target computer environment to manage, wherein the identifying includes accessing operational entity information defining unique identifiers that correspond to a particular set of operational entities that includes the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 16. The non-transitory computer-readable medium of claim 12, wherein the instruction is received from a orchestrator controller module as part of implementing the operational scenario, and wherein the operational scenario includes updating a server from a first version to a second version merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 17. This is a system of claim 1. See rejection for claim 1 above.
Further, additional elements at least one processor; and memory having program instructions stored thereon merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea.
As to claim 18. The system of claim 17, wherein the operations further comprise: receiving an instruction identifying an operation to be performed by a different operational entity that is managed by the system; and issuing a control API call to invoke a function to cause the different operational entity to perform the operation, and wherein the different operational entity implements a different set of functions of the control API than the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 19. The system of claim 17, wherein the operations further comprise: prior to the function map mapping the functions to the different lifecycle stages, receiving, from the operational entity, a communication that identifies the functions of the control API that are implemented by the operational entity; and updating the function map based on the communication merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
As to claim 20. The system of claim 17, wherein the instruction defines a unique identifier associated with the operational entity merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, and wherein the operations further comprise: accessing, based on the unique identifier, a blueprint that corresponds to the operational entity, wherein the blueprint specifies the current lifecycle stage of the operational entity merely recite insignificant extra solution activity such as gathering, displaying, updating, transmitting and storing data which does not integrate the judicial exception into a practical application. See MPEP 2106.05(d).
.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1 – 2, 7 – 8, 12- 13, 16 – 18, and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 – 4, 6, 8 - 9 of U.S. Patent No. 12,001,284 (hereinafter 284).
Claims 1, 2, 7, 8, 12 of instant application 18/646,194 (hereinafter 194)
Claims 1, 3, 4, 6, 8 of Patent No. 12,001,284 (hereinafter 284)
1.A method, comprising:
storing, by a controller module executing on a computer system, a function map for an operational entity managed by the controller module, wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity to different lifecycle stages of the operational entity;
implementing, by the controller module, at least a portion of an operational scenario for a target computer environment that includes the operational entity, wherein the implementing includes:
receiving an instruction to cause the operational entity to be transitioned from a first state to a second state;
identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and
issuing a control API call to invoke the function.
2.. The method of claim 1, wherein the operational entity implements a different set of a plurality of functions of the control API than another operational entity controlled by the controller module.
7. The method of claim 6, wherein the instruction is received from the orchestrator controller module, and wherein the method further comprises: sending, by the controller module to the orchestrator controller module, a message that indicates that the instruction was implemented successfully.
8. The method of claim 1, wherein the implementing further includes: receiving, by the controller module, another instruction that identifies an operation to be performed by a different operational entity; determining, by the controller module based on the other instruction, that the different operational entity is controlled by a different controller module; and routing, by the controller module, the other instruction to the different controller module.
12. A non-transitory computer-readable medium having program instructions stored thereon that are capable of causing a computer system to perform operations comprising: storing a function map for an operational entity managed by the computer system, wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity to different lifecycle stages of the operational entity; implementing at least a portion of an operational scenario for a target computer environment that includes the operational entity, wherein the implementing includes: receiving an instruction to cause the operational entity to be transitioned from a first state to a second state; identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and issuing a control API call to invoke the function.
1. A method, comprising:
performing, by a first controller module executing on a computer system, a discovery procedure that includes: identifying a set of components within a hierarchy of a target computer environment that is to be managed by the first controller module, wherein the set of components includes an operational entity, and wherein the first controller module is operable to manage the operational entity by changing a state of the operational entity; and communicating with the operational entity to discover, from the operational entity, which functions of a control application programming interface (API) are supported by the operational entity; and storing, by the first controller module, a function map for the operational entity that maps discovered functions of the control API that are implemented by the operational entity to different lifecycle stages of the operational entity; implementing, by the first controller module, a portion of an operational scenario for the target computer environment, wherein the implementing includes:
receiving, from a second controller module that controls the first controller module, an instruction to cause the operational entity to be transitioned from a first state to a second state;
identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and
issuing a control API call to invoke the function.
3. The method of claim 2, wherein the operational entity implements a different set of the plurality of functions of the control API than another operational entity controlled by the first controller module.
4. The method of claim 1, further comprising:
sending, by the first controller module to the second controller module, a message specifying a result that indicates whether the instruction was performed successfully.
7. The method of claim 1, wherein identifying the set of components within the hierarchy includes: accessing, by the first controller module, operational entity information defining unique identifiers that correspond to the set of components within the hierarchy that are to be controlled by the first controller module.
6. The method of claim 1, wherein the implementing further includes:
receiving, by the first controller module, another instruction that specifies an operation and another operational entity for performing the operation; determining, by the first controller module based on the other instruction, that the other operational entity is controlled by another controller module; and
routing, by the first controller module, the other instruction to the other controller module.
8. A non-transitory computer readable medium having program instructions stored thereon that are capable of causing a computer system to implement a first controller module that is capable of performing operations comprising: performing a discovery procedure that includes: identifying a set of components within a hierarchy of a target computer environment that is to be managed by the first controller module, wherein the first controller module is operable to manage an operational entity included in the identified set of components by changing a state of the operational entity; and communicating with the operational entity to discover, from the operational entity, which functions of a control application programming interface (API) are supported by the operational entity; and storing a function map for the operational entity that maps discovered functions of the control API that are implemented by the operational entity to different lifecycle stages of the operational entity; implementing a portion of an operational scenario for the target computer environment, wherein the implementing includes: receiving, from a second controller module that controls the first controller module, an instruction to cause the operational entity to be transitioned from a first state to a second state; identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and issuing a control API all to invoke the function.
Although the claims at issue are not identical, they are not patentably distinct from each other.
Claim 1 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 11 of U.S. Patent No. 12,001,284 (hereinafter 284).in view of Stefanov et al., (US PUB 2018/0145884 hereinafter Stefanov).
Claim 1 of instant application 18/646,194 (hereinafter 194)
Claim 11 of Patent No. 12,001,284 (hereinafter 284) in
1.A method, comprising:
storing, by a controller module executing on a computer system, a function map for an operational entity managed by the controller module, wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity to different lifecycle stages of the operational entity;
implementing, by the controller module, at least a portion of an operational scenario for a target computer environment that includes the operational entity, wherein the implementing includes:
receiving an instruction to cause the operational entity to be transitioned from a first state to a second state (284 teaches n instruction specifying an operation to be performed by an operational entity as part of an operational scenario, wherein the controller module is operable to manage the operational entity by changing a state of the operational entity would mean changing a first state to a second/another state of the operational entity);
identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state; and
issuing a control API call to invoke the function.
11. A method, comprising:
receiving, by a controller module from an orchestrator controller module within a hierarchy that includes controller modules and operational entities, an instruction specifying an operation to be performed by an operational entity as part of an operational scenario, wherein the controller module is operable to manage the operational entity by changing a state of the operational entity;
communicating, by the controller module, with the operational entity to discover a set of functions implemented by the operational entity from a plurality of functions supported by a control application programming interface (API) that allows for a given operational entity's state to be changed;
storing, by the controller module, a function map for the operational entity that maps the set of functions to different lifecycle stages of the operational entity; determining, by the controller module based on the function map and a current lifecycle stage of the operational entity, whether the set of functions includes a function invokable to cause the operational entity to perform the operation; and
responsive to determining a particular function invokable to cause the operational entity to perform the operation, the controller module invoking the particular function.
284 does not but teaches Stefanov teaches issuing a control API call to invoke the function (“..In response to the API call 505, the lifecycle manager 470 creates (e.g., defines) a state machine modeling the lifecycle states and state transitions specified in the received lifecycle definition (e.g., such as the example lifecycle definition illustrated in Table 1)....” para. 0072) and (“...Assuming the selected operation is verified (e.g., the “enable” operation is permitted for the AD User resource when in the “created” lifecycle state), the lifecycle manager 470 then sends an example message 530 (e.g., a REST API call 525) to the service provider 410 to instruct the service provider 410 to execute the selected operation. In response to the message 530, the service provider 410 invokes any appropriate XaaS functionality to execute the selected operation.” Para. 0074).
It 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 was made to modify 284 by applying the teachings of Stefanov because Stefanov teaches the same field of the invention of lifecycle management of web applications (title, para. 0003 and figure 4). Stefanov provides the API call for invoking a function as a basic requirement to communicate between functions and/or components in a computing system.
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.
Claims 1 – 5, 12, 14, 17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Fiebig et al., (US PAT 9,286,060 hereinafter Fiebig) in view of Stefanov et al., (US PUB 2018/0145884 hereinafter Stefanov).
Fiebig is provided by applicant in IDS filed 04/25/2024.
As to claim 1, Fiebig teaches a method, comprising:
Storing (“Preferably, the lifecycle management system comprises a registry which stores a description of the at least one computing component, wherein the description comprises a lifecycle property which indicates the current lifecycle state of the computing component....” col. 5 lines 55 - 65), by a controller module executing on a computer system (“...the registry 10 that is performing the lifecycle management...” col. 10 lines 25 – 30. Note: registry is controller module), a function map for an operational entity managed by the controller module (“...Design-time monitoring refers to the monitoring of metadata 20′ in a registry 10 (cf. FIG. 2) representing SOA, API and/or other assets 20.” Col. 9 lines 27 – 37. Note: asset is operational entity) and (“...With this lifecycle model 100 an approval user or group can define a grace period before the considered asset 20 is finally retired. For not being limited to a fixed time period, the condition 300 of the conditional approval has a fulfillment annotation that maps to a parameter of the policy attached to the transition between “Retirement Pending” and “Retired”. The parameter defines the grace period of the asset retirement” col. 10 lines 5 – 12), wherein the function map maps functions of a control application programming interface (API) that are implemented by the operational entity to different lifecycle stages of the operational entity (“Nevertheless, the present invention is not restricted to lifecycle management, but the concept of conditional approvals may also be applied e.g. to consumer management in a SOA and/or API management registry 10...” col. 10 lines 45 - 53);
implementing, by the controller module, at least a portion of an operational scenario for a target computer environment that includes the operational entity (“...A lifecycle transition request assigning a requested target lifecycle state of the lifecycle model to the at least one computing component is received...” abstract) and (“As already mentioned further above, the at least one computing component may be a Service-oriented architecture, SOA, asset, such as a Web service...” col. 6 lines 25 – 30. Note: Web service and/or asset are target environments), wherein the implementing includes:
receiving an instruction to cause the operational entity to be transitioned from a first state to a second state (“...For example, in the event of a request to change the lifecycle state of an asset from “In Production” to “Retired” (also referred to as the “out of production” lifecycle state), the approver may be fine with the requested change...” col. 7 lines 40 - 55);
identifying, based on the function map and a current lifecycle stage of the operational entity, a function invokable to transition the operational entity to the second state (“...In the lifecycle model 100 of FIG. 4, the conditional approval can move a given asset 20 to the “Retirement Pending” state 100f if the given asset 20 is supposed to be retired, i.e. put out of production. The “Retirement Pending” state 100f is another example of the additional conditional lifecycle state explained further above and has a transition to the “Retired” state mod that is annotated with a policy 200 that considers the invocation and/or usage of the given asset 20...” col. 9 line 60 – col. 10 line 12) and (“In this example, runtime invocations of the asset 20 are monitored. Such a monitoring can be performed e.g. by integrating runtime enforcement points...” col. 10 lines 25 – 30); and
Fiebig does not but Stefanov teaches issuing a control API call to invoke the function (“..In response to the API call 505, the lifecycle manager 470 creates (e.g., defines) a state machine modeling the lifecycle states and state transitions specified in the received lifecycle definition (e.g., such as the example lifecycle definition illustrated in Table 1)....” para. 0072) and (“...Assuming the selected operation is verified (e.g., the “enable” operation is permitted for the AD User resource when in the “created” lifecycle state), the lifecycle manager 470 then sends an example message 530 (e.g., a REST API call 525) to the service provider 410 to instruct the service provider 410 to execute the selected operation. In response to the message 530, the service provider 410 invokes any appropriate XaaS functionality to execute the selected operation.” Para. 0074).
It 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 was made to modify Fiebig by applying the teachings of Stefanov because Stefanov teaches the same field of the invention of lifecycle management of web applications (title, para. 0003 and figure 4). Stefanov provides the API call for invoking a function as a basic requirement to communicate between functions and/or components in a computing system.
As to claim 2, Fiebig modified by Stefanov teaches The method of claim 1, Fiebig teaches wherein the operational entity implements a different set of a plurality of functions of the control API than another operational entity controlled by the controller module (“...FIG. 4 illustrates another variation of the lifecycle model 100 discussed further above, which comprises the lifecycle states “Under development” 100a, “In Testing” 100b, “In Production” 100c, and “Retired”...” col. 9 lines 60 – 65).
As to claim 3, Fiebig modified by Stefanov teaches The method of claim 1, Fiebig teaches wherein the instruction defines a unique identifier associated with the operational entity, and wherein the method further comprises:
accessing, based on the unique identifier, a blueprint that corresponds to the operational entity, wherein the blueprint specifies the current lifecycle stage of the operational entity (“...wherein the description comprises a lifecycle property that indicates the current lifecycle state of the computing component.” Claim 5).
As to claim 4, Fiebig modified by Stefanov teaches The method of claim 1, Fiebig teaches further comprising:
generating, by the controller module, the function map, wherein the generating includes:
invoking a describe function implemented by the operational entity; and
receiving, from the operational entity, a response that identifies the functions of the control API that are implemented by the operational entity, wherein the function map is generated based on the response (“...With this lifecycle model 100 an approval user or group can define a grace period before the considered asset 20 is finally retired. For not being limited to a fixed time period, the condition 300 of the conditional approval has a fulfillment annotation that maps to a parameter of the policy attached to the transition between “Retirement Pending” and “Retired”. The parameter defines the grace period of the asset retirement” col. 10 lines 5 – 12).
As to claim 5, Fiebig modified by Stefanov teaches the method of claim 1, Fiebig teaches further comprising:
generating, by the controller module, the function map, wherein the generating includes receiving, from the operational entity, a broadcast that identifies the functions of the control API that are implemented by the operational entity, wherein the function map is generated based on the broadcast (“... The approval offers the approving group or user three options. The “Direct Approval” option follows the transaction requested by the user (from “In Testing” 100b to “In Production” 100c) and moves the asset to the “In Production” state 100c, so that it can be productively used by third parties....” col. 8 lines 40 - 55).
As to claim 12, this is a non-transitory computer-readable medium claim of claim 1. See rejection for claim 1 above. Further, Fiebig teaches non-transitory computer-readable medium having instructions (“...non-transitory computer readable storage medium...” col. 15 lines 5 – 20).
As to claim 14, this claim recites similar scope of claim 5. See rejection for claim 5 above.
As to claim 17, this is a non-transitory computer-readable medium claim of claim 1. See rejection for claim 1 above. Further, Fiebig teaches at least one processor (“...at least one processor and a memory...” col. 15 lines 5 – 20).
As to claim 20, this claim recites similar scope of claim 3. See rejection for claim 3 above.
Claims 6 - 7 are rejected under 35 U.S.C. 103 as being unpatentable over Fiebig in view of Stefanov, as applied to claim 1, and further in view of Phillips Phillips et al., (US PUB 2018/0150294 hereinafter Phillips).
As to claim 6, Fiebig modified by Stefanov teaches The method of claim 1, Fiebig and Stefanov do not but Phillips teaches wherein the controller module is part of a hierarchy of controller modules (“...A GIT repository typically includes a tree structure where each commit or submission of changed code creates a new node in the tree. The master is the repository's main branch where the integration or synchronization occurs in the workflow...” para. 0006), wherein the hierarchy includes an orchestrator controller module at a top level of the hierarchy that is executable to issue a set of instructions to a set of controller modules at one or more other levels of the hierarchy, and wherein the set of controller modules includes the controller module (“..However, in some other aspects, the distributed source control system 104 includes a centralized remote repository...” para. 0026) and (“...The source control system 104 also includes an orchestration engine 110, which may be part of or separate from the source control system 104, to orchestrate changes to the software...” para. 0028).
It 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 was made to modify Fiebig and Stefanov by applying the teachings of Phillips because Phillips would provide a storage system including hierarchy to control a system with branches (para. 0009).
As to claim 7, Fiebig modified by Stefanov teaches The method of claim 6, Fiebig teaches wherein the instruction is received from the orchestrator controller module, and wherein the method further comprises:
sending, by the controller module to the orchestrator controller module, a message that indicates that the instruction was implemented successfully (“..If no errors are found, the method 400 proceeds to OPERATION 432 for indicating the build was successful with no errors.” Para. 0043).
It 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 was made to modify Fiebig and Stefanov by applying the teachings of Phillips because Phillips would provide a successful message for the system to continue execution (para. 0043)
Claims 10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Fiebig in view of Stefanov, as applied to claim 1, and further in view of Panteleenko et al., (US PUB 2014/0095553 hereinafter Panteleenko).
As to claim 10, Fiebig modified by Stefanov teaches The method of claim 1, Fiebig and Stefanov do not but Panteleenko teaches wherein the operational scenario includes starting up a database service having one or more database servers capable of performing database transactions on behalf of users of the computer system (“..one or more database server instances executing the one or more other processes...” abstract) and (“..A database server may comprise multiple database server instances, some or all of which are running on separate computers” para. 0009).
It 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 was made to modify Fiebig and Stefanov by applying the teachings of Panteleenko because Panteleenko would provide multiple database servers to execute multiple concurrent operations on the database (para. 0010).
As to claim 16, Fiebig modified by Stefanov teaches The non-transitory computer-readable medium of claim 12, Fiebig modified by Stefanov do not but Panteleenko teaches wherein the instruction is received from a orchestrator controller module as part of implementing the operational scenario, and wherein the operational scenario includes updating a server from a first version to a second version (“..where part of the block contains an updated version of the data and the other part contains an older version of the data...” para. 0011).
It 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 was made to modify Fiebig and Stefanov by applying the teachings of Panteleenko because Panteleenko would provide multiple database servers to execute multiple concurrent operations on the database (para. 0010).
Allowable Subject Matter
Claims 8 – 9, 11, 13, 15, 18 – 19 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 and if they are overcome 101 rejection and Terminal Disclaimer is filed and approved.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
Czyzewicz et al., (US PUB 2013/0311905 hereinafter Czyzewicz), discloses a method for global Internet identity repository and management system, wherein repository management system includes graph storages for communicating with the web services (title, abstract and figures 1 – 31).
Sweet, (US PUB 20180309747), discloses a container manager in the management of the containers, particularly in a cloud bursting context (title, abstract and figures 1 – 7).
Barkett, (US PUB 2013/0346587), discloses a method for adaptively manage service requests within a multi-server system (title, abstract and figures 1 – 9).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/PHUONG N HOANG/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights