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 .
Status of Claims
This Final Office Action is in reply to the application filed on 18 May 2026.
Claims 1-20 are currently pending and have been examined.
Information Disclosure Statement
The Information Disclosure Statement filed on 18 May 2026 has been considered. An initialed copy of the Form 1449 is enclosed herewith.
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 and therefore directed to non-statutory subject matter.
Under Step 1, the claims 1-14 recite a method (i.e. a process) and claims 15-20 recite a system (i.e. an apparatus). Thus, the claims fall within one of the four statutory categories. See MPEP 2106.03.
Under Step 2A Prong 1, the claims are analyzed to determine whether the claims recite any judicial exceptions including certain groupings of abstract ideas (i.e., mathematical concepts, certain methods of organizing human activity such as a fundamental economic practice, or mental processes).
Claim 1 recites the abstract idea, determining one or more policies associated with the first workspace, the one or more policies each comprising operating parameters for the first workspace and an enforcement level parameter; determining a policy check of the first plan, the policy check indicating that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more policies and indicating the enforcement parameter for the violated policy; prior to an apply of the first plan, notifying a user of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy, thereby enabling the user to remediate the first workspace prior to enactment of the proposed changes, reducing policy-change-induced misconfigurations across the computing infrastructure.
Under their broadest reasonable interpretation, the limitations can be considered as belonging to methods of organizing human activity abstract idea category since they are directed to steps for managing information technology resource by determining that proposed changes to the configuration of a workspace would violate a policy and notifying a user of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy and enabling the user to remediate the first workspace prior to enactment of the proposed changes. This is a method of managing enterprise IT service activities. Thus, the claim recites an abstract idea. See MPEP 2106.02 (a)(2) II, C.
Claim 10 recites the abstract idea, receiving a proposed change to a first policy group associated with at least one of the plurality of workspaces, the first policy group including one or more policies each comprising operating parameters for the at least one of the plurality of workspaces; determining a policy check of the proposed change, the policy check comprising: determining one or more workspaces of the plurality associated with the first policy group that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; and prior to enacting the proposed change to the first policy group, notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; wherein determining one or more workspaces that maintain a configuration of API- manageable resources that violate the proposed change includes making the determination without applying the proposed change to a test environment constructed from historical configuration states, thereby enabling the user to remediate the determined workspaces prior to enactment of the proposed change, reducing policy-change-induced misconfigurations across the computing infrastructure..
Under their broadest reasonable interpretation, the limitations can be considered as belonging to methods of organizing human activity abstract idea category since they are directed to steps for managing information technology resource by determining one or more workspaces associated with the first policy group that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group and notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group and enabling the user to remediate the determined workspaces prior to enactment of the proposed change. This is a method of managing enterprise IT service activities. Thus, the claim recites an abstract idea. See MPEP 2106.02 (a)(2) II, C.
Claim 15 recites the abstract idea, determine a first policy group associated with the first cloud workspace, the first policy group including one or more policies each comprising operating parameters for the first workspace, each of the one or more policies including an enforcement level parameter indicating an enforcement priority of a policy relative to one or more other policies; prior to applying the plan, determine a policy check of the planned run, the policy check indicating that the plan, when applied, would violate a policy in the first policy group associated with the first cloud workspace and indicating the enforcement parameter for the violated policy; prior to applying the plan, notify an owner of the first policy group of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy; thereby enabling the user to remediate the first workspace prior to enactment of the plan, reducing policy-change-induced misconfigurations across the computing infrastructure.
Under their broadest reasonable interpretation, the limitations can be considered as belonging to methods of organizing human activity abstract idea category since they are directed to steps for managing information technology resource by determine a policy check of the planned run, the policy check indicating that the plan, when applied, would violate a policy in the first policy group associated with the first cloud workspace and indicating the enforcement parameter for the violated policy and an owner of the first policy group of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy and enabling the user to remediate the first workspace prior to enactment of the plan. This is a method of managing enterprise IT service activities. Thus, the claim recites an abstract idea. See MPEP 2106.02 (a)(2) II, C.
Dependent claims 2 and 16 recite, based on the enforcement level parameter of the violated policy indicated by the policy check, validating the first plan without receiving input from the notified user. Dependent claims 3 and 17 recite, based on the enforcement level parameter of the violated policy indicated by the policy check, requesting approval to validate the first plan. Dependent claims 4 and 18 recite, based on the enforcement level parameter of the violated policy indicated by the policy check, rejecting the first plan. Dependent claims 5 and 19 recite, determining a second plan of proposed changes to the configuration of API-manageable resources maintained by the first workspace; prior to an apply of the second plan, determining a second policy check of the second plan, the policy check indicating that the proposed changes to the configuration maintained by the first workspace would not violate a policy in the one or more policies; and prior to an apply of the second plan, notifying the user of the second policy check. Dependent claim 6 recites, wherein the one or more policies are included in a first policy group associated with the first workspace. Dependent claims 7 and 20 recite, determining one or more additional policy groups associated with the first workspace, the one or more additional policy groups each including one or more policies comprising operating parameters for the first workspace and enforcement level parameters; wherein the policy check further indicates that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more additional policy groups associated with the first workspace and further indicates the enforcement parameter for the violated policy; and notifying the user of the policy check by indicating the violated policy in the one or more additional policy groups and the enforcement level parameter of the violated policy. The dependent claims merely narrow how the abstract idea may be performed and describe the information or data recited in the abstract idea identified in claims 1 and 15.
Dependent claim 11 recites, wherein the policy check further comprises: determining a conflict between the proposed change and one or more other policies in the first policy group, wherein the conflict indicates that the one or more other policies would be violated by a configuration of API-manageable resources in compliance with the proposed change; and wherein notifying the user of the policy check further includes indicating the conflict. Dependent claim 12 recites, wherein the one or more workspaces are further associated with a second policy group including one or more policies each comprising operating parameters for the one or more workspaces, and wherein: determining the policy check of the proposed change further comprises: determining a conflict between the proposed change and one or more other policies in the second policy group, wherein the conflict indicates that the one or more other policies would be violated by a configuration of API-manageable resources in compliance with the proposed change; and the method further comprises: prior to enacting the proposed change, notifying the user of the policy check by indicating the conflict between the proposed change and the one or more other policies in the second policy group. Dependent claim 13 recites, enacting the proposed policy without receiving instructions from the owner of the first policy group based on the enforcement level parameter of the proposed policy and based on the enforcement level parameters of the one or more other policies in the first policy group where compliance with the proposed policy would cause a policy violation. Dependent claim 14 recites, requesting approval from the policy group holder to enact the proposed policy based on the enforcement level parameter of the proposed policy and based on the enforcement level parameters of the one or more other policies in the first policy group where compliance with the proposed policy would cause a policy violation. The dependent claims merely narrow how the abstract idea may be performed and describe the information or data recited in the abstract idea identified in claim 10.
Under Step 2A Prong 2 the claims are analyzed to determine whether the claims recite additional elements that integrate the judicial exception into a practical application.
With respect to claim 1, the judicial exception is not integrated into a practical application. In particular claim 1 recites the additional element, queuing a run on a first workspace of the plurality workspaces, the queued run including a first plan of proposed changes to a configuration of API-manageable resources maintained by the first workspace within the computing infrastructure which amounts to mere data storage recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g).
Dependent claims 2-7 do not recite any additional elements. Dependent claim 8 recites, wherein the API-manageable resources are one or more of hardware resources, software resources, and network resources. Dependent claim 9 recites, wherein the computing infrastructure is a cloud computing infrastructure. However, the additional elements of claims 8 and 9 are directed to describing the type of computing resources and computing infrastructure that they amount to generally linking the use of the judicial exception to a particular technological environment.
Claims 10-14 do not recite any additional elements that integrate the judicial exception into a practical application.
Claims 15-20 recites the additional elements, an IT infrastructure comprising cloud resources including one or more of hardware resources, software resources, and network resources; an IT infrastructure controller networked with the IT infrastructure, the controller comprising: a processor; and computer readable non-transitory memory including computer executable instructions, the instructions executable by the processor. These computing components are recited at a high level of generality and used as tools to perform the abstract idea identified above, such that it amounts to no more than mere instructions to apply the exception of using generic computers. See MPEP 2106.05(f).
Claim 15 also recites the additional element, queue a run on a first cloud workspace of the one or more cloud workspaces, the run including a plan for applying a configuration of cloud resources to the IT infrastructure which amounts to mere data storage recited at a high level of generality, and thus are insignificant extra-solution activity. See MPEP 2106.05(g).
The additional claim elements are not indicative of integration into a practical application, because the claims do not involve improvements to the functioning of a computer, or to any other technology or technical field (MPEP 2106.05(a)), the claims do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition (Vanda Memo), the claims do not apply the abstract idea with, or by use of, a particular machine (MPEP 2106.05(b)), the claims do not effect a transformation or reduction of a particular article to a different state or thing (MPEP 2106.05(c)), and the claims do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Thus, the additional elements do not impose any meaningful limits on practicing the abstract idea and the claims are directed to an abstract idea.
Even when viewed in combination, these additional elements fail to integrate the recited abstract idea into any practical application since they do not impose any non-generic meaningful limits on practicing the abstract idea. Thus, the claimed invention is directed to an abstract idea.
Under Step 2B the claims are analyzed to determine whether the claims recite additional elements that amount to an inventive concept (aka “significantly more”) than the recited judicial exception.
As a whole, claims 1-20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to mere instructions to apply the exception using generic computer components. For the queue a run on a first cloud workspace of the one or more cloud workspaces, the run including a plan for applying a configuration of cloud resources to the IT infrastructure (Claim 1 and Claim 15) steps that were considered extra-solution activity in Step 2A, Prong Two, this has been re-evaluated in Step 2B and determined to be well understood, routine, and conventional in the field. The Versata and OIP Techs. court decisions indicate that storing information in memory is well‐understood, routine, and conventional functions when it is claimed in a merely generic manner (as it is here). For these reasons, there is no inventive concept. See MPEP 2106.05(d), subsection II.
Considered as an ordered combination, the additional elements of the claim do not add anything further than when they are considered separately. Thus, under Step 2B, the claims are ineligible as the claims do not recite additional elements which result in significantly more than the abstract idea itself.
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.
Claim(s) 1-6, 8-9, 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto et al (US 2020/0183739 A1) in view of Shetty et al (US 2015/0026673 A1).
Claim 1: Hashimoto discloses a method of information technology (IT) resource management in a plurality of workspaces, each configured to maintain a different configuration of application programming interface (API) manageable resources within a computing infrastructure, the method comprising (see [0063]: first information technology infrastructure 130a and/or the second information technology infrastructure 130b may be configured and/or reconfigured to achieve any information technology objective including, for example, support for multi-tier software applications, self-service clusters, software demonstrations, disposable environments (e.g., production environments, staging environments, and/or the like), software defined networking, resource schedulers, multi-cloud deployment, and/or the like. [0070]: FIG. 1B, the plan engine 160 may include one or more workspaces including, for example, a first workspace 165a, a second workspace 165b, and a third workspace 165c. See Fig. 1A):
queuing a run on a first workspace of the plurality of workspaces, the queued run including a first plan of proposed changes to a configuration of API-manageable resources maintained by the first workspace within the computing infrastructure (see [0158]: information technology infrastructure controller 110 may respond by queuing a corresponding plan. The first user 145a and/or the second user 145b may also queue a plan, for example, after editing one or more variables associated with the first workspace);
determining one or more policies associated with the first workspace, the one or more policies each comprising operating parameters for the first workspace and an enforcement level parameter (see [0117]: as part of the multitier validation, the execution plan 190 may be validated against requirements classified as advisory, mandatory, and/or semi-mandatory. For example, the structural validity of the execution plan 190 may be classified as a mandatory requirement. By contrast, the policy compliance of the execution plan 190 may be classified as a semi-mandatory requirement whereas the cost quota compliance of the execution plan 190 may be classified as an advisory requirement. As noted, while advisory requirements and semi-mandatory requirements may be overridden, a mandatory requirement must be satisfied before the configurations associated with the execution plan 190 may be applied at the first information technology infrastructure 130a);
determining a policy check of the first plan, the policy check indicating that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more policies and indicating the enforcement parameter for the violated policy (see [0116]: Alternatively, the information technology infrastructure controller 110 may determine that the configurations associated with the execution plan 190 do not comply with at least one policy (325-N). [0117] In the event the information technology infrastructure controller 110 determines that the execution plan 190 fails to pass any portion of the multitier validation, the information technology infrastructure controller 110 may determine if the failed requirement is mandatory (329). In some example embodiments, as part of the multitier validation, the execution plan 190 may be validated against requirements classified as advisory, mandatory, and/or semi-mandatory (hence, enforcement parameter));
prior to an apply of the first plan, notifying a user of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy (see [0086] Referring again to FIG. 1B, the validation engine 170 may be configured to validate the execution plan 190 before the information technology infrastructure controller 110 applies the corresponding configurations to the information technology infrastructure. [0007] In some variations, a user interface may be generated to display, at a client, a result of validating the execution plan. The user interface may be further configured to display a first indication corresponding to the structural validity of the execution plan, a second indication of whether the execution plan violates the first policy, and/or a third indication of whether the execution plan satisfy the cost quota);
thereby enabling the user to remediate the first workspace prior to enactment of the proposed changes, reducing policy-change-induced misconfigurations across the computing infrastructure (see [0119]: By contrast, if the information technology infrastructure controller 110 determines that the execution plan 190 failed a non-mandatory requirement that is not overridden (331-N), the information technology infrastructure controller 110 may prevent the one or more configurations associated with the execution plan 190 from being applied at the first information technology infrastructure 130a (330).).
Hashimoto discloses at [0090]: Applying a requirement that is classified as advisory may merely trigger a notification (e.g., an informative output displayed at the first client 120a and/or the second client 120b) indicative, for example, of the configurations associated with the execution plan 190 as failing to comply with the requirement. Hashimoto does not explicitly disclose notifying a user of the policy check by indicating the enforcement level parameter of the violated policy but Shetty in the same field of endeavor teaches, notifying a user of the policy check by indicating the enforcement level parameter of the violated policy (see [0029] In case of a violation of a mandatory clause of the deployment descriptor 36 the customer is notified and exception approvals are sought to ignore violation and continue with the install).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the execution plan validation of Hashimoto, notifying a user of the policy check by indicating the enforcement level parameter of the violated policy as taught by Shetty “to ensure that a software installation does not break a customer's business policy, and to embed into a software installer a Policy Infrastructure that will interpret and enforce a customer's business policies in the installation process while ensuring that the prerequisites for the software have been met” (Shetty, [0005]).
Claim 15: Hashimoto discloses an information technology (IT) resource management system comprising: an IT infrastructure comprising cloud resources including one or more of hardware resources, software resources, and network resources; an IT infrastructure controller networked with the IT infrastructure, the controller comprising: a processor; and computer readable non-transitory memory including computer executable instructions, the instructions executable by the processor to cause the processor to: (see [0063]: first information technology infrastructure 130a and/or the second information technology infrastructure 130b may be configured and/or reconfigured to achieve any information technology objective including, for example, support for multi-tier software applications, self-service clusters, software demonstrations, disposable environments (e.g., production environments, staging environments, and/or the like), software defined networking, resource schedulers, multi-cloud deployment, and/or the like. [0026]: Similarly, computer systems are also described that may include one or more processors and one or more memories coupled to the one or more processors. A memory, which can include a non-transitory computer-readable or machine-readable storage medium. See Fig. 1A):
establish one or more cloud workspaces configured for maintaining a configuration of cloud resources (see [0089]: For example, each of the first workspace 165a, the second workspace 165b, and the third workspace 165c may be associated with attributes including, for example, environment, application type, region, cloud, and/or the like);
queue a run on a first cloud workspace of the one or more cloud workspaces, the run including a plan for applying a configuration of cloud resources to the IT infrastructure (see [0082]: to apply the configurations associated with the execution plan 190 to the first information technology infrastructure 130a, the information technology infrastructure controller 110 may traverse the corresponding dependency graph. For instance, the information technology infrastructure controller 110 may perform a depth-first traversal of the dependency graph in order to determine the resources that the execution plan 190 indicates as requiring provisioning, modification, and/or de-provisioning. The information technology infrastructure controller 110 may further identify, based on the dependency graph, independent resources that may be provisioned, modified, and/or de-provisioned in parallel. [0158]: information technology infrastructure controller 110 may respond by queuing a corresponding plan. The first user 145a and/or the second user 145b may also queue a plan, for example, after editing one or more variables associated with the first workspace);
determine a first policy group associated with the first cloud workspace, the first policy group including one or more policies each comprising operating parameters for the first workspace, each of the one or more policies including an enforcement level parameter indicating an enforcement priority of a policy relative to one or more other policies ([0089]: That is, the validation engine 170 may identify the policies and/or cost quotas that are applicable to a workspace by at least filtering a broader set of policies and/or cost quotas based on the attributes of the workspace. [0117]: as part of the multitier validation, the execution plan 190 may be validated against requirements classified as advisory, mandatory, and/or semi-mandatory. For example, the structural validity of the execution plan 190 may be classified as a mandatory requirement. By contrast, the policy compliance of the execution plan 190 may be classified as a semi-mandatory requirement whereas the cost quota compliance of the execution plan 190 may be classified as an advisory requirement. As noted, while advisory requirements and semi-mandatory requirements may be overridden, a mandatory requirement must be satisfied before the configurations associated with the execution plan 190 may be applied at the first information technology infrastructure 130a);
prior to applying the plan, determine a policy check of the planned run, the policy check indicating that the plan, when applied, would violate a policy in the first policy group associated with the first cloud workspace and indicating the enforcement parameter for the violated policy (see [0116]: Alternatively, the information technology infrastructure controller 110 may determine that the configurations associated with the execution plan 190 do not comply with at least one policy (325-N). [0117] In the event the information technology infrastructure controller 110 determines that the execution plan 190 fails to pass any portion of the multitier validation, the information technology infrastructure controller 110 may determine if the failed requirement is mandatory (329). In some example embodiments, as part of the multitier validation, the execution plan 190 may be validated against requirements classified as advisory, mandatory, and/or semi-mandatory (hence, enforcement parameter));
prior to applying the plan, notify an owner of the first policy group of the policy check by indicating the violated policy (see [0086] Referring again to FIG. 1B, the validation engine 170 may be configured to validate the execution plan 190 before the information technology infrastructure controller 110 applies the corresponding configurations to the information technology infrastructure. [0007] In some variations, a user interface may be generated to display, at a client, a result of validating the execution plan. The user interface may be further configured to display a first indication corresponding to the structural validity of the execution plan, a second indication of whether the execution plan violates the first policy, and/or a third indication of whether the execution plan satisfy the cost quota),
thereby enabling the user to remediate the first workspace prior to enactment of the plan, reducing policy-change-induced misconfigurations across the computing infrastructure (see [0119]: By contrast, if the information technology infrastructure controller 110 determines that the execution plan 190 failed a non-mandatory requirement that is not overridden (331-N), the information technology infrastructure controller 110 may prevent the one or more configurations associated with the execution plan 190 from being applied at the first information technology infrastructure 130a (330).).
Hashimoto discloses at [0090]: Applying a requirement that is classified as advisory may merely trigger a notification (e.g., an informative output displayed at the first client 120a and/or the second client 120b) indicative, for example, of the configurations associated with the execution plan 190 as failing to comply with the requirement. Hashimoto does not explicitly disclose notifying an owner of the first policy group of the policy check by indicating the enforcement level parameter of the violated policy but Shetty in the same field of endeavor teaches, notifying a user of the policy check by indicating the enforcement level parameter of the violated policy (see [0029] In case of a violation of a mandatory clause of the deployment descriptor 36 the customer is notified and exception approvals are sought to ignore violation and continue with the install).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the execution plan validation of Hashimoto, notifying an owner of the policy check by indicating the enforcement level parameter of the violated policy as taught by Shetty “to ensure that a software installation does not break a customer's business policy, and to embed into a software installer a Policy Infrastructure that will interpret and enforce a customer's business policies in the installation process while ensuring that the prerequisites for the software have been met” (Shetty, [0005]).
Claims 2 and 16: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claims 1 and 15 above. Hashimoto further teaches, based on the enforcement level parameter of the violated policy indicated by the policy check, validating the first plan without receiving input from the notified user (see [0119]: f the information technology infrastructure controller 110 determines that the execution plan 190 failed a non-mandatory requirement that is overridden (331-Y), the information technology infrastructure controller 110 may apply, to the first information technology infrastructure 130a, the one or more configurations associated with the execution plan 190).
Claims 3 and 17: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claims 1 and 15 above. Shetty further teaches, based on the enforcement level parameter of the violated policy indicated by the policy check, requesting approval to validate the first plan (see [0029] in case of a violation of a mandatory clause of the deployment descriptor 36 the customer is notified and exception approvals are sought to ignore violation and continue with the install).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the execution plan validation of Hashimoto as modified by Shetty, based on the enforcement level parameter of the violated policy indicated by the policy check, requesting approval to validate the first plan as taught by Shetty “to ensure that a software installation does not break a customer's business policy, and to embed into a software installer a Policy Infrastructure that will interpret and enforce a customer's business policies in the installation process while ensuring that the prerequisites for the software have been met” (Shetty, [0005]).
Claims 4 and 18: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claims 1 and 15 above. Hashimoto further discloses based on the enforcement level parameter of the violated policy indicated by the policy check, rejecting the first plan (see [0090]: applying a requirement that is classified as mandatory and/or semi-mandatory may prevent the configurations associated with the execution plan 190 from being applied at the first information technology infrastructure 130a in the event the configurations fail to satisfy the requirement).
Claims 5 and 19: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claims 1 and 15 above. Hashimoto further discloses, determining a second plan of proposed changes to the configuration of application programming interface (API) manageable resources maintained by the first workspace; prior to an apply of the second plan, determining a second policy check of the second plan, the policy check indicating that the proposed changes to the configuration maintained by the first workspace would not violate a policy in the one or more policies; and prior to an apply of the second plan, notifying the user of the second policy check (See Hashimoto discloses the capability to implement numerous execution plans. [0098]: Referring again to FIG. 1B, the state controller 180 may also maintain a run log 187 tracking, for example, various runs of one or more execution plans including, for example, the execution plan 190. As used herein, “running” the execution plan 190 may include generating the execution plan 190, validating the execution plan 190, applying the configurations associated with the execution plan 190, canceling the execution plan 190, discarding the execution plan 190, and/or the like. Accordingly, each run of an execution plan may be associated with a run status including, for example, planning, planned, error, confirmed, applying, applied, canceled, discarded, pending, policy checking, policy checked, policy override, and/or the like. The run log 187 may be configured to track the runs of one or more execution plan including, for example, by storing a corresponding run status for each of the runs. [0092]: According to some example embodiments, the information technology infrastructure controller 110 may be configured to implement the execution plan 190 based at least on the execution plan 190 having been successfully validated by the validation engine 170. The validation engine 170 may be configured to provide an indication of the execution plan 190 as having been successfully or unsuccessfully validated by the validation engine 170. Alternatively and/or additionally, the validation engine 170 may provide an indication of the execution plan 190 as having passed or failed each of the first policy 175a, the second policy 175b, the first quota 175c, the second quota 175d, and/or the like).
Claim 6: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claim 1 above. Hashimoto further discloses, wherein the one or more policies are included in a first policy group associated with the first workspace (see [0089]: That is, the validation engine 170 may identify the policies and/or cost quotas that are applicable to a workspace by at least filtering a broader set of policies and/or cost quotas based on the attributes of the workspace).
Claim 8: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claim 1 above. Hashimoto further discloses, wherein the API-manageable resources are one or more of hardware resources, software resources, and network resources (see Fig. 1, element 135a, 135b, 135c. [0021]).
Claim 9: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claim 1 above. Hashimoto further discloses, wherein the computing infrastructure is a cloud computing infrastructure (see [0022] multi-cloud deployment, [0089]: cloud workspaces).
Claim 7 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hashimoto and Shetty as applied to claims 6 and 15 above, and further in view of Rachamadugu et al (US 2015/0378700 A1).
Claims 7 and 20: The combination of Hashimoto and Shetty discloses the claimed invention as applied to claims 6 and 15 above. Hashimoto and Shetty do not expressly disclose determining one or more additional policy groups associated with the first workspace, the one or more additional policy groups each including one or more policies comprising operating parameters for the first workspace and enforcement level parameters; wherein the policy check further indicates that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more additional policy groups associated with the first workspace and further indicates the enforcement parameter for the violated policy; and notifying the user of the policy check by indicating the violated policy in the one or more additional policy groups and the enforcement level parameter of the violated policy. However, Rachamadugu which also discloses a method and system of validating deployment plans teaches, determining one or more additional policy groups associated with the first workspace, the one or more additional policy groups each including one or more policies comprising operating parameters for the first workspace and enforcement level parameters; wherein the policy check further indicates that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more additional policy groups associated with the first workspace and further indicates the enforcement parameter for the violated policy; and notifying the user of the policy check by indicating the violated policy in the one or more additional policy groups and the enforcement level parameter of the violated policy (see [0020] In step 204, application director 106 generates a deployment plan 128 based on blueprint 126 to deploy application 108 in a specific cloud environment (e.g., deployment environments 112). [0026] To determine which policies 136 are applicable to the deployment, application director 106 retrieves policies while traversing through the hierarchy of domain objects of deployment object 402, starting with a first domain object (e.g., object 404-1). In one embodiment, at step 304, application director 106 retrieves any policies 136 specifying a deployment domain that match a current domain object. For example, as shown in FIG. 4, on a first pass, application director 106 retrieves policies P1 and P2 that specify the domain of “deployment plan.” A policy 136 may target a particular deployment domain in order to control the deployment based on data from that domain. For example, a policy P may be a maximum memory policy, i.e., that, in any deployment, no node may have more than particular amount (e.g., 1024 MB) of RAM. To enforce such a policy P1, data would be needed from deployment plan 128, i.e., from the deployment plan domain. In another example, a policy P2 may be a maximum VM count policy, i.e., that no deployment may exceed a particular number of VMs. See Fig. 4. [0035] At step 314, application director 106 determines whether the deployment plan is compliant with all of the plurality of policies 136. In one embodiment, execution of a policy 136 may generate an indication (i.e., “COMPLIANT” or “NON-COMPLIANT”) of whether the deployment plan is compliant with that policy. The indications from executing all of the plurality of policies 136 may be aggregated and use to consider whether compliance has been determined. If so, application director 106 may proceed to execute the deployment, as in step 208 of method 200 described earlier. Otherwise, at step 316, application director 106 may raise an error indicating the deployment plan does not comply with at least one of the plurality of policies 136 associated with the deployment plan).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Hashimoto and Shetty with the system and method of determining one or more additional policy groups associated with the first workspace, the one or more additional policy groups each including one or more policies comprising operating parameters for the first workspace and enforcement level parameters; wherein the policy check further indicates that the proposed changes to the configuration maintained by the first workspace would violate a policy in the one or more additional policy groups associated with the first workspace and further indicates the enforcement parameter for the violated policy; and notifying the user of the policy check by indicating the violated policy in the one or more additional policy groups and the enforcement level parameter of the violated policy as taught by Rachamadugu because it would “determine which policies are applicable to the deployment” and “for defining nested policies in a system based on a domain object reference, without having to change the underlying framework that executes the policies” (Rachamadugu, [0026], [0036]).
Claims 10-14 are rejected under 35 U.S.C. 103 as being unpatentable over Hamlin et al (US 2022/0417284 A1) in view of Stitt et al (US 2022/0078228 A1).
Claim 10: Hamlin discloses a method of information technology (IT) resource management in a plurality of workspaces, each configured for to maintain a different configuration of application programming interface (API) manageable resources within a computing infrastructure, the method comprising (see Fig. 2, [0055]: Moreover, applications 210A-N may discover all other participants (e.g., hardware 206A and enumerated/supported capabilities, etc.) that are registered into platform framework 200 using API 205. For example, if hardware 206A includes graphics subsystem 107, application 210A may use API 205 to obtain the firmware version, frame rate, operating temperature, integrated or external display, etc. that hardware 206A provides to platform framework 200, also via API 205. [0062] In some implementations, a containerized workspace and/or an application executed therewithin may participate as a producer (e.g., 207A-N/206A-N) or as a consumer (e.g., 210A-N) of platform framework 200. Particularly, IHS 100 may be employed to instantiate, manage, and/or terminate a secure workspace. In some embodiments, the construction of a workspace for a particular purpose and for use in a particular context may be orchestrated remotely from the IHS 100 by a workspace orchestration service. In some embodiments, portions of the workspace orchestration may be performed locally on IHS 100.):
receiving a proposed change to a first policy group associated with at least one of the plurality of workspaces, the first policy group including one or more policies each comprising operating parameters for the at least one of the plurality of workspaces (see [0075]: For example, a thermal policy provided by an operating system of the IHS may specify a temperature threshold or other type of temperature condition that will trigger throttling of the processing resources of the IHS, which may include the main processors and various other processors and/or controllers. Another thermal policy may be specified by the BIOS (workspace) of the IHS and may specify its own temperature thresholds for triggering resource throttling. [0087] In this manner, a variety of platform polices may be modified by various policy editors 405 of an IHS. As indicated at 475 of Fig. 4 and 340 of Fig. 3, policy editors 405 may submit modifications to a platform policy to a platform policy library 425, or in some embodiments, may submit modifications directly to the platform framework policy manager 420);
determining a policy check of the proposed change (see [0088]: this token that is presented by a policy editor 405 may be validated as having been provided to the policy editor 405 by a trusted platform resource, thus authorizing the policy editor to submit platform policy modifications. Upon receiving a platform policy update, the platform policy library 425 may submit such a token to a trusted resource of the IHS, such as the embedded controller 120 described with regard to FIG. 1, in order to validate that the token was generated by this trusted resource).
Hamlin, does not expressly disclose the policy check comprising: determining one or more workspaces of the plurality of workspaces associated with the first policy group that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; and prior to enacting the proposed change to the first policy group, notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; wherein determining one or more workspaces that maintain a configuration of API- manageable resources that violate the proposed change includes making the determination without applying the proposed change to a test environment constructed from historical configuration states, thereby enabling the user to remediate the determined workspaces prior to enactment of the proposed change, reducing policy-change-induced misconfigurations across the computing infrastructure but Stitt in the same field of endeavor teaches, determining one or more workspaces of the plurality of workspaces associated with the first policy group that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group (see [0116]: In some embodiments, the cloud infrastructure provisioning platform 302 can determine one or more policy files that have been received from the client computer 301 and/or retrieved from a policy database. The policy file can be a policy as code file that, when executed, can determine whether or not a current provisioning activity is consistent with the established policies. [0117]: Administrators can then have the ability via the policy file to approve significant changes or to prevent specific workspaces from exceeding predetermined thresholds or policy limits. [0127]: providing a policy file to a cloud infrastructure provisioning platform 404 to evaluate whether or not a current cloud infrastructure being provisioned is consistent with one or more policies included in the policy file.)
and prior to enacting the proposed change to the first policy group, notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; wherein determining one or more workspaces that maintain a configuration of API- manageable resources that violate the proposed change includes making the determination without applying the proposed change to a test environment constructed from historical configuration states, thereby enabling the user to remediate the determined workspaces prior to enactment of the proposed change, reducing policy-change-induced misconfigurations across the computing infrastructure (see [0044]: The policy file can include any suitable policy that can be verified by the policy check platform prior to the cloud infrastructure provisioning platform implementing the changes to the existing cloud infrastructure (e.g., by adding the specified resources). The policy file can be a policy as code document and can include one or more imports. The client computer can provide a particular configuration plan and a policy file together or separately at any suitable point in time. [0122]: For example, the policy can be a Boolean value (e.g., True if the infrastructure is consistent with the policy file or False if the infrastructure is not consistent with the policy file). [0124]: cloud infrastructure provisioning platform 302 receives the policy check result and performs any suitable processing with and/or based on the policy check result. For example, the cloud infrastructure provisioning platform 302 can modify the policy check result by formatting the policy check result into a human readable format. The cloud infrastructure provisioning platform 302 can then, in some embodiments, provide the policy check result to the client computer 301 via the API 304).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the policy validation of Hamlin, determining one or more workspaces of the plurality of workspaces associated with the first policy group that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; and prior to enacting the proposed change to the first policy group, notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration of API-manageable resources that violate the proposed change to the first policy group; wherein determining one or more workspaces that maintain a configuration of API- manageable resources that violate the proposed change includes making the determination without applying the proposed change to a test environment constructed from historical configuration states, thereby enabling the user to remediate the determined workspaces prior to enactment of the proposed change, reducing policy-change-induced misconfigurations across the computing infrastructure as taught by Stitt because it would “proactively prevent provisioning of out-of-policy infrastructure” (Stitt, [0118]).
Claim 11: The combination of Hamlin and Stitt discloses the claimed invention as applied to claim 10 above. Hamlin further teaches, wherein the policy check further comprises: determining a conflict between the proposed change and one or more other policies in the first policy group, wherein the conflict indicates that the one or more other policies would be violated by a configuration of API-manageable resources in compliance with the proposed change (see [0075]); and wherein notifying the user of the policy check further includes indicating the conflict (see [0083]: participants that have registered as users of the logging policy are notified of changes made by any authorized editors 405 of the logging policy.)
Claim 12: The combination of Hamlin and Stitt discloses the claimed invention as applied to claim 10 above. Hamlin further teaches wherein the one or more workspaces are further associated with a second policy group including one or more policies each comprising operating parameters for the one or more workspaces, (see [0084]: A containerized workspace, such as described with regard to FIG. 2, that is a policy editor 405, may modify the network policy to restrict the IHS to use of a specific encrypted network while highly protected data is being accessed via the workspace. [0087] In this manner, a variety of platform polices may be modified by various policy editors 405 of an IHS. As indicated at 475 of Fig. 4 and 340 of Fig. 3, policy editors 405 may submit modifications to a platform policy to a platform policy library 425, or in some embodiments, may submit modifications directly to the platform framework policy manager 420) and wherein: determining the policy check of the proposed change further comprises:
determining a conflict between the proposed change and one or more other policies in the second policy group, wherein the conflict indicates that the one or more other policies would be violated by a configuration of API-manageable resources in compliance with the proposed change; and the method further comprises: prior to enacting the proposed change, notifying the user of the policy check by indicating the conflict between the proposed change and the one or more other policies in the second policy group (see [0086]: For instance, a security application that is a policy editor 405 may specify various types of presence detection thresholds within a user presence detection policy that is to be utilized by the IHS. Another application that is a policy editor 405 may issue a user presence detection policy modification that specifies that certain hardware is not allowed for use, such as prohibiting use of a camera or of an external display of the IHS based on a change in privacy settings. In another example, a workspace that is a policy editor 405 may specify a certainty threshold that must be met in order to generate an indication of user proximity, where the workspace may issue a changed in proximity requirements in response to the user accessing protected data. [0089] The platform framework core 415 may then proceed, at 495 of FIG. 4 and at 360 of FIG. 3, to provide each of the registered consumers with a notification of the updated platform policy and a location of the updated policy. The consumer 410 may then retrieve the updated policy, in some cases using a communication handle provided in the notification of the update. Using the communication handle, the consumer 410 may retrieve the updated policy, thus allowing the consumer 410 to be provided policy updates from policy editors 405 that the consumer 410 is not otherwise configured to interface with).
Claim 13: The combination of Hamlin and Stitt d discloses the claimed invention as applied to claim 10 above. Hamlin further teaches, enacting the proposed policy without receiving instructions from the owner of the first policy group based on the enforcement level parameter of the proposed policy and based on the enforcement level parameters of the one or more other policies in the first policy group where compliance with the proposed policy would cause a policy violation (see [0083]: or instance, in embodiments where the platform policies include a logging policy, a diagnostic application operating on the IHS may modify the logging policy in response to detecting an error condition, or in response to initiating diagnostic operations. Through the modifications to the logging policy, the diagnostic application policy editor 405 may signal various platform framework 418 participants to initiate increased logging protocols that will generate logging outputs that can be collected by the diagnostic application. Once sufficient logging has been conducted or the error condition has been resolved, the diagnostic application may modify the logging policy to revert to prior logging levels.).
Claim 14: The combination of Hamlin and Stitt discloses the claimed invention as applied to claim 10 above. Stitt further teaches, requesting approval from the policy group holder to enact the proposed policy based on the enforcement level parameter of the proposed policy and based on the enforcement level parameters of the one or more other policies in the first policy group where compliance with the proposed policy would cause a policy violation (see [0117]: Administrators can then have the ability via the policy file to approve significant changes or to prevent specific workspaces from exceeding predetermined thresholds or policy limits. In some embodiments, policies can be enforced based on the type of infrastructure created, how it is used, and which devices, users, organizations, etc. have access to the infrastructure.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the policy management of Hamlin, requesting approval from the policy group holder to enact the proposed policy based on the enforcement level parameter of the proposed policy and based on the enforcement level parameters of the one or more other policies in the first policy group where compliance with the proposed policy would cause a policy violation as taught by Stitt because it would because it would “proactively prevent provisioning of out-of-policy infrastructure” (Stitt, [0118]).
Response to Arguments
Applicant's arguments regarding the 35 USC 101 rejections have been fully considered but they are not persuasive.
Applicant argues that,
“The human mind is not equipped to perform multiple elements of the claims. For example, the human mind, even with the aid of a generic computer, cannot practically manage workspace runs in an IT infrastructure that includes one or more workspaces with changing resource configurations. Given enough time, a human mind might be able to perform one or more of the recited steps of the claims in isolation, but not in combination, and not in a manner that would include managing workspace resources as claimed.”
However, the examiner disagrees with the Applicant. In the Office Action, the examiner did not consider the limitations to fall under the mental process grouping of abstract ideas. Examiner maintains that the claims fall under belonging to methods of organizing human activity abstract idea category. As recited in the claim limitations, the steps are directed to a process of managing information technology resources by evaluating policies and configurations associated with workspaces and notifying a user of the policy check by indicating the violated policy and the enforcement level parameter of the violated policy and enabling the user to remediate the workspace prior to enactment of the proposed changes. As emphasized in the Applicant’s disclosure:
[0055]: In one or more embodiments, the method 700 further includes, at operations 708-712, determining a policy check of the proposed change. In various embodiments, the policy check includes, at operation 708, determining one or more workspaces associated with the first policy group that maintain a configuration of resources that violate the proposed change. In one or more embodiments, the policy check includes, at operation 712, prior to enacting the proposed change to the first policy group, notifying a user of the policy check by indicating the one or more workspaces that maintain a configuration that violates the proposed change to the first policy group. In one or more embodiments notification can occur via, a policy check notification, such as the notification 500 depicted in FIG. 5 and described above.
[0056]: In one or more embodiments, the method 700 optionally includes, at operation 716 resolving policy violations based on enforcement parameters. As described above, in various embodiments, the policy check can validate the proposed change where the enforcement level parameter of the violated policy indicates that the policy is low priority or optional. In some embodiments, where the enforcement level parameter allows, the policy check will validate the proposed change based on receiving approval from a user for the resulting policy violation. In such embodiments, the policy violations can be considered “resolved” in that the violations have been noted by a user and approved for implementation. As such, in one or more embodiments, the method 700 optionally includes, at operation 724, applying the proposed change to the first policy group.
The claimed subject matter merely uses the computer to evaluate the proposed configuration changes and policy changes to enable a user to approve any implementation or resolve any violations.
Applicant argues that,
With respect to Step 2A, Prong Two, even if the claimed invention does recite an abstract idea (which it does not), the claimed invention is directed to an improvement to the field of provisioning infrastructure in an IT environment. As recited in newly-amended claims 1, 10 and 15, and described in the specification, the invention facilitates deployment, testing and maintenance of new system configurations, and prevents misconfigurations in workspaces that might otherwise be implemented in a multiple-workspace computing infrastructure. See, e.g., claim 1, reciting: "...thereby enabling the user to remediate the first workspace prior to enactment of the proposed changes, reducing policy-change-induced misconfigurations across the computing infrastructure," and similar improvements as recited in claims 10 and 15. Also see instant specification p. 8, lines 5-8 and p. 13, lines 9-12. Enfish and the MPEP recognize that claims directed to an improvement in technology or a technical field are patent eligible. See Enfish, LLC v. Microsoft Corp., 822 F.3d 1327, 1339 (Fed. Cir. 2016) and MPEP §§ 2106.04(d)(1). Consequently, even if the claims recite an abstract idea (which they do not), the claimed invention integrates the abstract idea into a practical application based on its technological improvements, and is therefore directed to eligible subject matter.
However, the examiner disagrees with the Applicant’s assertions. The limitations, "...thereby enabling the user to remediate the first workspace prior to enactment of the proposed changes, reducing policy-change-induced misconfigurations across the computing infrastructure," do not impose meaningful limits on the claims. These limitations only recite the outcome of “notifying a user of the policy check” and do not include any technical details about how the “enabling the user to remediate the first workspace prior to enactment of the proposed changes” and “reducing policy-change-induced misconfigurations across the computing infrastructure” are accomplished or improve technology. As indicated in the rejection above, even when viewed in combination, the additional elements of the claims do not integrate the recited judicial exception into a practical application and do not provide an inventive concept.
Applicant’s arguments with respect to the prior art rejection of claims 10-14 have been considered but are moot. Applicant amended claim 10 to include the limitations, wherein determining one or more workspaces that maintain a configuration of API- manageable resources that violate the proposed change includes making the determination without applying the proposed change to a test environment constructed from historical configuration states in light of the claim amendments a new ground of rejection has been made.
Applicant argues that “Shetty merely teaches that for a mandatory clause of the deployment descriptor, a customer is notified. Although the "clause" is described as mandatory, no parameter indicating a level of enforcement is provided to the customer”. However, the examiner disagrees with the Applicant. Shetty discloses at [0023]: The solution provided by embodiments of the invention aims to use a policy repository 44 to store all the policies written by the user. The policies stored in the policy repository 44 are written to suit the Business Requirements (BR). These policies are preferably based on the deployment descriptor 36 schema used. Shetty discloses that the mandatory clause is included in the deployment descriptor which is written by the user (see [0028]). Therefore, an exception approval message to the user indicates to the user of a violation of the mandatory clause. Examiner maintains that Shetty teaches the feature of providing the enforcement level to the user.
Applicant argues that, “Further, one of ordinary skill in the art would not have been motivated to modify the system of Hashimoto to include prior user notification of an enforcement level parameter. As noted in the Office Action at p. 14, Hashimoto already displays an indication of structural validity of the execution plan and whether the plan violates a first policy. One of ordinary skill would not have been motivated to include the additional enforcement level parameter as the supposedly- motivating objectives of "(ensuring) that a software installation does not break a customer's business policy...while ensuring that the prerequisites for the software have been met" as described by Shetty and argued in the Office Action are already met by Hashimoto.” However, the examiner disagrees with the Applicant. Hashimoto discloses the classification of policies (see [0090]) but does not expressly disclose that the indication of the violations of a first policy is based on whether the first policy is mandatory or not. It would be obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include in the execution plan validation of Hashimoto, notifying a user of the policy check by indicating the enforcement level parameter of the violated policy as taught by Shetty “to ensure that a software installation does not break a customer's business policy, and to embed into a software installer a Policy Infrastructure that will interpret and enforce a customer's business policies in the installation process while ensuring that the prerequisites for the software have been met”.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 MAAME BALLOU whose telephone number is (571)270-1359. The examiner can normally be reached Monday-Friday 9am-5pm.
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, Lynda Jasmin can be reached at 571-272-6782. 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.
MAAME BALLOU
Examiner
Art Unit 3629
/MAAME BALLOU/Examiner, Art Unit 3629
/SANGEETA BAHL/Primary Examiner, Art Unit 3626
Prosecution Insights