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 .
Status of Claims
This communication is a Final Office Action in response to Applicant’s amendment for application number 18/413,071 received on 01/16//2026.
In accordance with Applicant’s amendment, claims 1-20 are amended. Claims 1-20 are currently pending and have been examined.
Response to Amendment
Applicant’s amendment necessitated the new ground(s) of rejection set forth in this Office Action.
Response to Arguments
Response to §112(f) arguments – Applicant’s arguments with respect to the claim interpretation applied to the claims have been considered. Upon further review, the following is determined:
Regarding the “processing device” and the “destination platform”, Applicant’s arguments have been considered and are persuasive. Therefore, the claim interpretations under 35 USC 112(f) are withdrawn.
With respect to the “communication device”, upon review of Applicant’s arguments and the specification, the following is accepted as evidence of enough structure for the “communication device”: [0036] Further, the server computer may include a communication device. This is to be the interpretation given to “communication device”.
Response to §112(b)/(a) arguments – Applicant’s arguments with respect to the §112 rejections previously applied to the claims have been considered and are persuasive. The rejections are withdrawn.
Response to §101 arguments – But for the following, Applicant’s arguments with respect to the §101 rejections previously applied to the claims are primarily raised in support of the amendments to claims 1, 4, 11, and 14. The amendments and supporting arguments are believed to be fully addressed in the updated §101 rejections below.
Applicant argues (Remarks at pg. 29): “The applicant further submits that the currently amended claims 1 and 11 require physical devices, namely the processing device and the communication device, so under Ex parte Schmid, Appeal No. 2012-002155 (PTAB Dec. 26, 2014) and Ex parte Steiner, Appeal No. 2012-0012381 (PTAB April 23, 2015) the claims are eligible under section 35 USC 101.”. In response, Examiner preliminarily notes that neither Ex Parte Schmid or Ex Parte Steiner are precedential or informative. Even assuming arguendo, the claims are not deemed to be patent eligible in view of Ex Parte Schmid because the claims are not analogous to a physical garment that ensures that the "abstract idea" of transmitting infant data is not preempted. Therefore, the claims are not deemed patent eligible in view of Ex Parte Schmid. Even assuming arguendo, the claims are not deemed to be patent eligible in view of Ex Parte Steiner. The claims are not analogous to "a machine for implementing a presence technology service among interconnected communication devices (i.e., a presence service)." The claims do not recite any particular machine to perform the steps of the abstract idea. Therefore, the claims are not patent eligible in view of these PTAB decisions.
Applicant argues (Remarks at pg. 30): “The applicant submits that this ordered arrangement of additional elements and corresponding operations constitutes an improvement in the technical field of facilitating an exit procedure of a project from a cloud service provider, and not in a method of organizing human activity. The currently amended claims 1 and 11 address a technical problem identified in the specification, namely that manual cloud exit assessments lack established procedures and metrics and may not effectively track changes in outsourced infrastructure and platform elements. The currently amended claims 1 and 11 provides a technical solution to this technical problem by initiating of the API interrogation process which decrypts the client credential, test a connection to the API, iterates through used resources within the defined scope to collect data to build the resource inventory, and maps the used resources to the services, and receiving the server information which include the at least one metadata comprising data associated with names, types, kinds, and versions of the used resources via the API interrogation process, analyzing the server information and the at least one project data, analyzing at least one project resource information associated with the at least one project resource identified based on the analyzing of the server information and the at least one project data, based on the at least one assessment rule, determining and analyzing the at least one risk score, and generating and transmitting at least one of the exit strategy and the exit plan.”. In response, Examiner respectfully disagrees and notes that, as noted in the instant Office Action, the additional elements fail to integrate the abstract idea into a practical application, add significantly more to the claims, or represent an improvement to technology because the they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), or insignificant extra-solution activity, or provide nothing more than mere instructions to implement an abstract idea on a generic computer. See 101 rejections below for further details.
Applicant argues (Remarks at pg. 33): “The applicant submits that in Enfish (Enfish, LLC v. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016)), Federal Circuit held that the claims satisfied § 101 under Mayo/Alice because they recited a "specific improvement to the way computers operate," i.e., an improved database configuration that permitted faster and more efficient searching. (Enfish, 822 F.3d at 1330-33, 1336, 1339). The applicant further submits that in Core Wireless (Core Wireless Licensing S.A.R.L. v. LG Elecs., Inc., 880 F.3d 1356 (Fed. Cir. 2018)), the claims specified a "particular manner of summarizing and presenting information in electronic devices" that "improve[d] the efficiency of using" the devices (Core Wireless, 880 F.3d at 1362-63).
The applicant further submits that, in view of Enfish (specific improvement to computer operation) and Core Wireless (particular manner that improves device efficiency), the limitations "initiating, using the processing device, an application programming interface (API) interrogation process based on the at least one client data, wherein the API interrogation process decrypts the client credential further associated with the at least one project and tests a connection to an application programming interface (API) of the cloud service provider, wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider, wherein the resource inventory comprises at least one project resource associated with the at least one project;" and "receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources;", as recited in the currently amended claims 1 and 11, recite a particular manner of acquiring and using the server information that provides a technological improvement. In particular, the currently amended claims 1 and 11 requires the initiating of the API interrogation process which decrypts the client credential, tests a connection to the API, iterates through used resources within the defined scope to collect data to build the resource inventory, and maps the used resources to the services, for receiving of the server information which includes the at least one metadata comprising data associated with names, types, kinds, and versions of the used resources, via the API interrogation process, rather than receiving unconditionally. Therefore, the currently amended claims 1 and 11 constraints the obtaining of the server information by requiring that the server information is received via the API interrogation process, and then the at least one project resource information comprised in the server information is analyzed based on at least one assessment rule, which is consistent with the type of particularized implementation recognized as eligible in Enfish and Core Wireless.”. In response, Examiner respectfully disagrees and notes that the present claims do not provide an analogous improvement to the computer to that of Enfish, specifically because the present claims do not improve the computer itself. The improvements of a self-referential table provide a specific benefit to the functioning of the computer, which is not the case in the claims of the instant application. The present claims are directed to Metal Processes, which is not an improvement to the computer itself. Rather, this is an improvement to the abstract idea associated with Mental Processes. Furthermore, Examiner notes that the present claims do not provide an analogous improvement to the computer to that of Core Wireless, specifically because the present claims do not improve the graphical user interface itself. The improvements of Core Wireless provide a specific benefit the user interface for electronic devices, which is not the case with the instant claims. The present claims are directed to facilitating an exit procedure of a project from a cloud service provider, which is not an improvement to the computer itself. The claims do not improve a problem rooted in computer technology because the computer is being used as a tool to receive, process and transmit information, and to generating a strategy and plan/recommendations using said information.
Applicant argues (Remarks at pg. 34): “An example of the PTAB holding this position is seen in Ex parte Thomas, where the PTAB reverses the Examiner's rejection of claims under 35 U.S.C. § 101 because the examiner has not addressed that functionality in the claims entails an improvement in EHR technology. The PTAB in re. Ex parte Thomas states, "The Examiner has not addressed whether this functionality, viewed in light of Appellant's Specification, entails an improvement in EHR technology. And, as such, the Examiner has not established that claim 1 fails to integrate the asserted abstract idea into a practical application. Therefore, we do not sustain the Examiner's rejection of independent claim 1 under 35 U.S.C. § 101. " (see pp. 13 Exparte Thomas, Appeal 2019-002450, Application 14/318,500).”. In response, Examiner preliminarily notes that the PTAB decision is neither informative, precedential, or binding. However, even assuming arguendo, the present claims are not analogous to that of Id. The present claims are not directed to the integration of applications running on devices being operated by members of a medical practice with the EHR. Therefore, Examiner respectfully disagrees with Applicant's assertion that the present claims are directed to statutory subject matter in view of Thomas.
Applicant argues (Remarks at pg. 35): “Further, an example of the PTAB holding this position is also seen in Exparte Ambuj, where the PTAB reverses the Examiner's rejection of claims under 35 U.S.C. § 101 because the Examiner has not addressed whether the functionality described in the claims entails a technological improvement or an improvement in a technical field. The PTAB in re. Ex parte Ambuj states, "But, the Examiner has not addressed whether the functionality described above (i.e., storing a base key at a mobile device that can be used to provide cryptographic security for mobile payments conducted by the mobile device without requiring the receiving of ephemeral keys from a payment processor over a constantly maintained, secure communication channel), viewed in light of Appellant's Specification, entails a technological improvement or an improvement in a technical field. And, as such, the Examiner has not established that claim 1 fails to integrate the asserted abstract idea into a practical application. " (see pp. 17 Exparte Ambuj, Appeal 2021-003831, Application 15/203,722).”. In response, Examiner preliminarily notes that the PTAB decision is neither informative, precedential, or binding. However, even assuming arguendo, the present claims are not analogous to that of Id. The present claims are not directed to cryptographic security without ephermeral keys. Therefore, Examiner respectfully disagrees with Applicant's assertion that the present claims are directed to statutory subject matter in view of Ambuj.
Applicant argues (Remarks at pgs. 36-37): “The applicant submits that the ordered combination of the limitations "initiating, using the processing device, an application programming interface (API) interrogation process based on the at least one client data, wherein the API interrogation process decrypts the client credential further associated with the at least one project and tests a connection to an application programming interface (API) of the cloud service provider, wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider, wherein the resource inventory comprises at least one project resource associated with the at least one project;" and "receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources;", "analyzing, using the processing device, the server information and the at least one project data;", "identifying, using the processing device, the at least one project resource associated with the at least one project based on the analyzing of the server information and the at least one project data, wherein the at least one project resource is configured for implementing the at least one project;", "analyzing, using the processing device, at least one project resource information associated with the at least one project resource based on at least one assessment rule, wherein the server information comprises the at least one project resource information;", "determining, using the processing device, at least one risk score corresponding to the at least one project resource based on the analyzing of the at least one project resource information, wherein the at least one risk score represents a severity of a risk associated with the at least one project resource;", "analyzing, using the processing device, the at least one risk score;", and "generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project;", as recited in the currently amended claims 1 and 11, are additional elements that provides "significantly more": (1) initiating the API interrogation process which decrypts the client credential, tests a connection to the API, iterates through used resources within the defined scope to collect data to build the resource inventory, and maps the used resources to the services, and receiving via the API interrogation process, the server information which include the at least one metadata comprising data associated with names, types, kinds, and versions of the used resources; (2) analyzing the at least one project resource information comprised in the received server information based on at least one assessment rule and determining a risk score that represents a severity of risk associated with the at least one project resource; and (3) generating, based on the analyzing of the at least one risk score, at least one of an exit strategy and an exit plan. This specific arrangement is not a mere application of a judicial exception on a generic computer. Any assertion that this arrangement is "well-understood, routine, and conventional" must be supported by evidence. See Berkheimer v. HP Inc., 881 F.3d 1360, 1369 (Fed. Cir. 2018) ("Whether something is well-understood, routine, and conventional to a skilled artisan at the time of the patent is a factual determination.").”. In response, Examiner reminds Applicant that as documented in par. [0050] of the Office Action mailed 11/06/2025, the extra solution activities for receiving or transmitting data over a network have been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)).
Applicant argues (Remarks at pgs. 38-39): “While, the office has neither provided a citation nor a statement as per MPEP 2106.07(a), the Office has failed to meet the burden of formulating the rejections under Step 2B as to the additional elements (i.e., "initiating, using the processing device, an application programming interface (API) interrogation process based on the at least one client data, wherein the API interrogation process decrypts the client credential further associated with the at least one project and tests a connection to an application programming interface (API) of the cloud service provider, wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider, wherein the resource inventory comprises at least one project resource associated with the at least one project;" and "receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources;", "analyzing, using the processing device, the server information and the at least one project data;", "identifying, using the processing device, the at least one project resource associated with the at least one project based on the analyzing of the server information and the at least one project data, wherein the at least one project resource is configured for implementing the at least one project;", "analyzing, using the processing device, at least one project resource information associated with the at least one project resource based on at least one assessment rule, wherein the server information comprises the at least one project resource information;", "determining, using the processing device, at least one risk score corresponding to the at least one project resource based on the analyzing of the at least one project resource information, wherein the at least one risk score represents a severity of a risk associated with the at least one project resource;", "analyzing, using the processing device, the at least one risk score;", and "generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project;") being well-understood, routine or conventional as per the Berkheimer memorandum, which is codified in MPEP 2106.05(d).”. In response, Examiner respectfully disagrees and reminds Applicant that as documented in the Office Action mailed 11/06/2025, the eligibility analysis is consistent with the examination guidelines, including formulating a rejection for lack of subject matter eligibility (MPEP 2106.07(a)), including: Step 2A, Prong 1: abstract ideas recited by the claims as identified by the Examiner, with an explanation of why the claims recite said abstract ideas (e.g., Mental Processes); Step 2A, Prong 2: analysis to determine if the additional elements recited by the claims integrate the abstract idea into a practical application; and Step 2B: analysis to determine if the additional elements recited by the claims add significantly more. See 101 rejections of the instant office action for updated analysis necessitated by the amendments to Applicant’s claims.
Applicant argues (Remarks at pg. 39): “Tomer, where the PTAB solely reverses the Examiner's rejection of claims under 35 U.S.C. § 101 because the Examiner does not produce a finding that the arrangement of decision engines carrying out reinforcement machine learning models, was well understood, routine, and conventional to a skilled artisan at the time of filing. The PTAB in re. Ex parte Tomer states, "We do not see afinding by the Examiner that the combination of limitations recited in claim 1, and specifically, the arrangement of decision engines carrying out reinforcement machine learning models, was well understood, routine, and conventional to a skilled artisan at the time offiling. (See, e.g., Answer 7.) We decline to undertake this analysis and make that finding offact in the first instance. Therefore, we will reverse this rejection of claim 1." (see pp. 12 Exparte Tomer, Appeal 2021-002766, Application 15/294,866).”. In response, Examiner preliminarily notes that the PTAB decision is neither informative, precedential, or binding. However, even assuming arguendo, the present claims are not analogous to that of Id. The present claims are not directed to an arrangement of decision engines carrying out reinforcement machine learning models. Therefore, Examiner respectfully disagrees with Applicant's assertion that the present claims are directed to statutory subject matter in view of Tomer.
Applicant argues (Remarks at pgs. 39-40): “Further, an example of the PTAB holding this position is also seen in Exparte Myungjun, where the PTAB reverses the Examiner's rejection of claims under 35 U.S.C. § 101 because the Examiner fails to provide adequate factual findings to comply with the Berkheimer requirement. The PTAB in re. Ex parte Myungjun states, "Because the Examiner fails to provide sufficient factual findings to support the Berkheimer analysis, the Examiner has not provided one or more of the specific four types of evidence required by Berkheimer. See Berkheimer, 881 F.3d at 1369; Berkheimer Memorandum at 3-4. As a result, the Examiner fails to provide adequate factual findings to comply with the Berkheimer requirement, and the Examiner has erred with respect to Step 2B of the Guidance. Accordingly, we are constrained by the record to reverse the Examiner's rejection of claim 1 under 35 U.S.C. § 101 on procedural grounds." (see pp. 10-11 Ex parte Myungjun, Appeal 2023-002545, Application 15/287,388).”. In response, Examiner preliminarily notes that the PTAB decision is neither informative, precedential, or binding. However, even assuming arguendo, the present claims are not analogous to that of Id. The present claims are not directed to controlling, with at least one processor, a scanner to modify a pattern pitch to produce one or more metrology targets having the best metrology target design on a sample. Therefore, Examiner respectfully disagrees with Applicant's assertion that the present claims are directed to statutory subject matter in view of Myungjun.
Applicant argues (Remarks at pg. 40): “Further, an example of the PTAB holding this position is also seen in Exparte Devaraya, where the PTAB reverses the Examiner's rejection of claims under 35 U.S.C. § 101 because the Examiner does not provide factual support to show that some of the additional recitations of claims are well-understood, routine, and conventional. The PTAB in re. Ex parte Devaraya states, "We further note that the Examiner does not provide factual support to show that some of the additional recitations such as the claimed instructions for determining a computational effect to propagate the change to a value are well-understood, routine, and conventional. Final Act. 10 11, 13-14. The conclusion that "an element (or combination of elements) represents well-understood, routine, conventional activity . . must be based upon a factual determination that is supported. "Robert W. Bahr, Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), USPTO, p. 3, available at https:/ www.uspto.gov sites default files documents memo-berkheimer-20180419.PDF (Apr. 19, 2018). Thus, even if the additional recitations are considered only under the step 2B analysis i.e., setting aside whether they integrate the underlying abstract idea into a patent-eligible abstract idea the Examiner's finding and analysis are insufficient. Accordingly, we do not sustain the Examiner's patent eligibility rejection under 35 U.S.C. § 101 of claim 2, and claims 5, 6, 8-13, and 15 20, which have similar recitations and are similarly rejected. " (see pp. 11-12 Exparte Devaraya, Appeal 2022-004825, Application 16/166,924).”. In response, Examiner preliminarily notes that the PTAB decision is neither informative, precedential, or binding. However, even assuming arguendo, the present claims are not analogous to that of Id. The present claims are not directed to representing unified graph and hierarchy relationships. Therefore, Examiner respectfully disagrees with Applicant's assertion that the present claims are directed to statutory subject matter in view of Devaraya. Furthermore, Examiner directs Applicant to the 101 rejections of the instant office action, as well as the office action mailed 11/06/2025. Specifically, Examiner points Applicant to the Step 2A, Prong 2 for the analysis of the additional elements to the determine if they integrate the abstract idea into a practical application, and Step 2B, for the analysis of the additional elements to determine if they add significantly more to the claims, including computing additional elements, as well as well-understood, routine, and conventional steps recited in the claims – in alignment with the 2019 Revised Patent Subject Matter Eligibility Guidance.
Accordingly, the 101 rejections are maintained and updated to address Applicant’s amendments.
Response to §103 arguments – Applicant’s arguments (Remarks at pgs. 14-16) with respect to the §103 rejections previously applied to the original claims are primarily raised in support of the amendments to independent claims 1/11 and dependent claims 4/14. The amendments and supporting arguments are believed to be fully addressed in the updated §103 rejections below.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
From claims 1/11:
The limitations include the following terms modified by functional language and not modified by sufficient structure: communication device. The interpretation to these claim limitations is applicable to claims 2-10, and 12-20 as dependent claims. When looking at the Specification, the following is disclosed: [0036] Further, the server computer may include a communication device. This is to be the interpretation given to “communication device”.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 non-patentable subject matter. The claims are directed to an abstract idea without significantly more. The judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception as further set forth in MPEP 2106.
Step 1: The claimed invention is analyzed to determine if it falls outside one of the four statutory categories of invention. See MPEP 2106.03
Claim(s) 1-10 is/are directed to a method (i.e., Process), and claim(s) 11-20 is/are directed to a system (i.e., Machine). Therefore, claims 1-20 are directed to patent eligible categories of invention. Accordingly, the claims satisfy Step 1 of the eligibility inquiry.
Step 2A, Prong 1: In prong one of step 2A, the claim(s) is/are analyzed to evaluate whether they recite a judicial exception. See MPEP 2106.04
Independent claims 1, and 11 recite a method, and a system for facilitating an exit procedure of a project from a cloud service provider. As drafted, the limitations recited by the independent claims fall under the “Mental Processes” abstract idea grouping by setting forth activities that could be performed mentally by a human (including an observation, evaluation, judgment, opinion) (see MPEP § 2106.04(a)(2), subsection III).
Independent claim 1 recites the following abstract limitations: generating, using a processing device, a data request based on the confirmation; initiating, using the processing device, an application programming interface (API) interrogation process based on the at least one client data, wherein the API interrogation process decrypts the client credential further associated with the at least one project and tests a connection to an application programming interface (API) of the cloud service provider. wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider, wherein the resource inventory comprises at least one project resource associated with the at least one project; analyzing, using the processing device, the server information and the at least one project data; identifying, using the processing device, the at least one project resource associated with the at least one project based on the analyzing of the server information and the at least one project data, wherein the at least one project resource is configured for implementing the at least one project; analyzing, using the processing device, at least one project resource information associated with the at least one project resource based on at least one assessment rule, wherein the server information comprises the at least one project resource information; determining, using the processing device, at least one risk score corresponding to the at least one project resource based on the analyzing of the at least one project resource information, wherein the at least one risk score represents a severity of a risk associated with the at least one project resource; analyzing, using the processing device, the at least one risk score; generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project. But for the additional elements – underlined – recited in the limitations, the steps in the claims could be accomplished mentally, such as by human observation, evaluation, judgement, opinion or with the help of pen and paper.
Independent claim(s) 11 recite(s) a system for executing steps that are largely similar to the limitations of claim 1. Therefore, the same analysis applies to claim 11. Dependent claims 2/12 further narrow the abstract idea and introduce further additional elements for consideration under said steps.
Dependent claims 3-10, and 13-20 further narrow the abstract idea and do not introduce further additional elements for consideration under said steps.
Step 2A, Prong 2: An evaluation is made whether a claim recites any additional element, or combination of additional elements, that integrate the judicial exception into a practical application of the exception. See MPEP 2106.04(d).
Regarding the computing additional elements, namely communication device, at least one client device, and plurality of resources comprised in the server from the dependent claims 1/11, these additional elements have been evaluated but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (generic computing environment). See MPEP 2106.05(f) and 2106.05(h). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment (generic computing environment).
With respect to the limitations for receiving, using a communication device, at least one client data from at least one client device associated with a client, wherein the at least one client data comprises a client credential associated with the client and at least one project data associated with at least one project; transmitting, using the communication device, an access request to a server associated with a cloud service provider, wherein the access request is based on the client credential; receiving, using the communication device, a confirmation corresponding to the access request from the server; transmitting, using the communication device, the data request to the server; receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources; and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device from claims 1/11, these limitations fail to integrate the abstract idea into a practical application because they amount to insignificant extra-solution activity. See MPEP 2106.05(g).
With respect to the limitations for initiating, using the processing device, an application programming interface (API) interrogation process, and tests a connection to an application programming interface (API) of the cloud service provider from claims 1/11, these limitations provide nothing more than mere instructions to implement an abstract idea on a generic computer, which doesn’t integrate the abstract idea into a practical application. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
With respect to the destination platform from claims 2/12, the destination platform has been evaluated but fails to integrate the abstract idea into a practical application because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (generic computing environment). See MPEP 2106.05(f) and 2106.05(h). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment (generic computing environment).
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
Step 2B: The claims are analyzed to determine whether any additional element, or combination of additional elements, is/are sufficient to ensure that the claims amount to significantly more than the judicial exception. This analysis is also termed a search for "inventive concept." See MPEP 2106.05.
Regarding the computing additional elements, namely communication device, at least one client device, and plurality of resources comprised in the server from the dependent claims 1/11, these additional element(s) has/have been evaluated, but fail to add significantly more to the claims because they amount to using generic computing elements (computer hardware) or instructions/software (engine) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (network computing environment, the internet, online) and does not amount to significantly more than the abstract idea itself. Applicant’s specification recites the computing additional elements at a high level of generality. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
With respect to the limitations for receiving, using a communication device, at least one client data from at least one client device associated with a client, wherein the at least one client data comprises a client credential associated with the client and at least one project data associated with at least one project; transmitting, using the communication device, an access request to a server associated with a cloud service provider, wherein the access request is based on the client credential; receiving, using the communication device, a confirmation corresponding to the access request from the server; transmitting, using the communication device, the data request to the server; receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources; and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device from claims 1/11, these limitations fail to add significantly more because they amount to insignificant extra-solution activity. See MPEP 2106.05(g). Additionally, these extra-solution activities have been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) - Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network)).
With respect to the limitations for initiating, using the processing device, an application programming interface (API) interrogation process, and tests a connection to an application programming interface (API) of the cloud service provider from claims 1/11, these limitations provide nothing more than mere instructions to implement an abstract idea on a generic computer, which doesn’t add significantly more to the claims. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception.
With respect to the destination platform from claims 2/12, the destination platform has been evaluated but fails to add significantly more to the claims because it amount to using generic computing elements (computer hardware) or instructions/software (engine) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment (network computing environment, the internet, online) and does not amount to significantly more than the abstract idea itself. Applicant’s specification recites the computing additional elements at a high level of generality. Therefore, the additional elements merely describe generic computing elements or computer-executable instructions (software) merely serve to tie the abstract idea to a particular operating environment, which does not add significantly more to the abstract idea. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976; Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015).
Dependent claims 3-10, and 13-20 recite the same abstract ideas (“Mental Processes”) as the independent claims along with further steps/details falling under the scope of the abstract idea itself, along with the same or substantially same additional elements addressed above, which does not add significantly more to the judicial exception.
Accordingly, claims 1-20 are rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 7-8, 11-12, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Dzierzanowski et al. (US 20220237565 A1, hereinafter “Dzierzanowski”), in view of Davies (US 20200327467 A1, hereinafter “Davies”), in further view of Ahamparam et al. (US 20030135399 A1, hereinafter “Ahamparam”), in further view of Jerimi (WO 2022016093 A1, hereinafter “Jemiri”).
Regarding claims 1/11: Dzierzanowski teaches:
a method ([0004] A system, method, and computer readable medium (collectively, the “system”) is disclosed for project accountability services.);
a system ([0004] A system, method, and computer readable medium (collectively, the “system”) is disclosed for project accountability services.);
receiving, using a communication device, at least one client data from at least one client device associated with a client, wherein the at least one client data comprises a client credential associated with the client and at least one project data associated with at least one project; ([Fig. 1B] User Interface 110, Computing Device, Browser, Smart Phone 112, and Computational Environment 114; Fig. 3A: Step 306 – Perform Project Member Verification(s) and Attestation by Digital Signatures; [0004] receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0110] With combined reference to FIGS. 1A, 4A, and 3A, via the user interface 110, and upon access approved via role and policy based Active Directory entity credential authentication 402, process 300 is invoked upon receipt of a request to preserve a project (step 302).);
transmitting, using the communication device, an access request to a server associated with a cloud service provider, wherein the access request is based on the client credential; ([0004] A system, method, and computer readable medium (collectively, the “system”) is disclosed for project accountability services. In various embodiments, the system may comprise a processor and a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor, cause the processor to perform operations comprising receiving a user validation data, validation the user based on the user validation data to generate a validated user, receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0071] With additional reference to FIG. 1B, user interface module 110 comprises a user interface, which may include various computing devices configured to communicate via cloud network 150. In various embodiments, module 110 comprises a computing device 112 and/or a computational environment 114 which may take the form of a computer or processor, or a set of computers/processors, although other types of computing units may be used. Exemplary computing devices and supporting user interfaces include browsers, servers, clustered and/or pooled servers, laptops, notebooks, handheld computers, personal digital assistants, cellular phones, smart phones, or any other device capable of receiving data over networks.);
receiving, using the communication device, a confirmation corresponding to the access request from the server; ([0110] With combined reference to FIGS. 1A, 4A, and 3A, via the user interface 110, and upon access approved via role and policy based Active Directory entity credential authentication 402);
generating, using a processing device, a data request based on the confirmation; ([0110] With combined reference to FIGS. 1A, 4A, and 3A, via the user interface 110, and upon access approved via role and policy based Active Directory entity credential authentication 402, process 300 is invoked upon receipt of a request to preserve a project (step 302).);
transmitting, using the communication device, the data request to the server; ([0004] validation the user based on the user validation data to generate a validated user, receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0154] The various system components discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data; [0176] Cloud” or “Cloud computing” includes a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing may include location-independent computing, whereby shared servers provide resources, software, and data to computers and other devices on demand.; [0177] As used herein, “transmit” may include sending electronic data from one system component to another over a network connection. Additionally, as used herein, “data” may include encompassing information such as commands, queries, files, data for storage, and the like in digital or any other form.);
initiating. using the processing device, an application programming interface (API) interrogation process based on the at least one client data, ([Abstract] A system for project accountability services comprises a processor and a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor, cause the processor to perform operations comprising receiving a user validation data, validation the user based on the user validation data to generate a validated user, receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0048] In this regard, the system identifies to the user what aspects of the taxonomy are based on law and regulation, which aspects are not legal or instituted from a regulatory perspective, and which aspects are provided merely as guidance. Guidance may include, for example, industry best practices, pending law and regulation and/or directional statements from varied institutions.; [0049] In various embodiments, the machine-readable symbolic tokens, text and project-specific information, entity ethical principles, policy, and guidance, combined by Natural Language Processing (NLP) techniques via software traverses the graphic structure, constructing explanation and audit trails for meaningful human oversight. The system supports API queries to the graphic structure and NLP outcomes for reporting and review processes.; [0059] For a given project instance, and all associated and necessary information, this knowledge may be captured and codified as a Digital Evidence Bag (DEBs) within a Digital Evidence Cabinet (DEC), and then stored chronologically on the Forensic-Chain. Timestamps for chronological determination are highly accurate with integrity. Programmatically, the Forensic-Chain may be accessible via an API provided by the system such as, for example over HTTP via a RESTful API.; [0126] Header 500 is created as a combination of public and private data fields provided by the entity to the system. The system generates the header data schema is created in 500, and header data schema is then forwarded via an API call 502.;
wherein the API interrogation process decrypts the client credential further associated with the at least one project ([0004] A system, method, and computer readable medium (collectively, the “system”) is disclosed for project accountability services. In various embodiments, the system may comprise a processor and a tangible, non-transitory memory configured to communicate with the processor, the tangible, non-transitory memory having instructions stored thereon that, in response to execution by the processor, cause the processor to perform operations comprising receiving a user validation data, validation the user based on the user validation data to generate a validated user, receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0170] One skilled in the art will also appreciate that, for security reasons, any databases, systems, devices, servers, or other components of the system may consist of any combination thereof at a single location or at multiple locations, wherein each database or system includes any of various suitable security features, such as firewalls, access codes, encryption, decryption, compression, decompression, and/or the like.);
and tests a connection to an application programming interface (API) of the cloud service provider, ([0008] In various embodiments, the system may capture, via a project schema, a project member information comprising at least one of a name, a title, a role, an employee status, an organization, an email address, a phone number, a supervisor name, and a contribution. The system may capture, via the first evidence block, at least one of a design criterion, a development document, a design document, a development assumption, a risk assessment document, an optimization criteria, a model parameter, a decision support method, a model objective function, an influence and relevance diagram, or a first user defined custom field. The system may capture, via the second evidence block, at least one of a code base, a model snapshot, a production snapshot, a training data, a data associated with a quality assurance process, a test data, a data associated with a verification and validation process, a data availability, a data definition, or a second user defined custom field.; [0038] The system may increase data reliability or accuracy by enabling data filtering functions and reliability testing.; [0059] For a given project instance, and all associated and necessary information, this knowledge may be captured and codified as a Digital Evidence Bag (DEBs) within a Digital Evidence Cabinet (DEC), and then stored chronologically on the Forensic-Chain. Timestamps for chronological determination are highly accurate with integrity. Programmatically, the Forensic-Chain may be accessible via an API provided by the system such as, for example over HTTP via a RESTful API.);
receiving, using the communication device and via the API interrogation process, a server information from the server based on the data request, ([0004] validation the user based on the user validation data to generate a validated user, receiving a request for service from the validated user, and providing, in response to the request for service, a project assessment and requirement accountability service comprising a knowledge catalog, an assessment process module, an accountability process module, an attestation process module, an evidence record, a project accountability schema, and a cryptographic key manager.; [0131] In various embodiments, secure key management is performed by device 560. A calling API 562 queries FIPS 140-3 and/or FIPS 140-4 Hardware Security Modules (HSMs), depending upon the specific request for entity or system encryption and/or signing keys. HSMs provide enhanced security controls and the preventative measures against key compromise. Cryptographic key material is controlled within legal jurisdiction of the data and oversight thereof, for the entity utilizing the service, if so, required by nation-state law. Each subscribing entity controls the full lifecycle of cryptographic key assets via m-of-n Key Signing Officers (KSO) ownership and key management lifecycle controls, anti-collusion, and business continuity functions. There may be multiple instances of Entity HSMs 564 and System HSMs 566, depending upon the legal and privacy jurisdiction operational requirements. As a result, from the API based request from calling API 562, return API 568 returns the requested cryptographic asset. Calling API 562 and return API 568 may be coded to the Public Key Crypto Standard (PKCS #7 and #11).; [0133] With additional reference to FIG. 6, a functional block diagram of a high integrity and reliable timestamp generation method is illustrated in accordance with various embodiments. In various embodiments, an application API call interacts with the timestamp agent 600 (tsAgent). An API request/response method 602 enables communication between the requesting timestamp agent 600 and the responding timestamp service 604. The timestamp service 604, when invoked, may return a value in JSON message formatted by the ISO 8602 Universal Coordinated Time (UTC) standard, or if several subservices are unavailable, a unique nonce value.);
wherein the server information comprises a plurality of resource information associated with a plurality of resources comprised in the server, wherein the plurality of resource information characterizes the plurality of resources, ([0139] Audit 702 includes audit processes for assessing algorithmic capabilities designed to optimize the efficient allocation of resources for goods and services); [0151] a resource and performance monitoring tool, such as, for example, Node Application Metrics (“appmetrics”); [0168] The firewall may include any hardware and/or software suitably configured to protect CMS components and/or enterprise computing resources from users of other networks.; [0176] Cloud” or “Cloud computing” includes a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. Cloud computing may include location-independent computing, whereby shared servers provide resources, software, and data to computers and other devices on demand.);
analyzing, using the processing device, the server information and the at least one project data; ([0067] system 100 infrastructure components 140 may include, for example, immutable storage, reporting, analytic tools, time sources, and or the like.; [0084] In various embodiments, knowledge catalog 200 is organized by an ontology at the highest level, then incorporates taxonomy constructs further defining actionable knowledge, and described earlier as an Ontology, Taxonomy and Symbolic Reasoning or OTSR structure. This knowledge is represented for system 100 processing symbolically, textually, and numerically, and drives interactions with project teams. Symbolic analysis may be performed by system 100 based upon symbolic human and machine-readable representations of a problem that uses logic and inference to solve problems.);
Dzierzanowski doesn’t teach:
wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider,
wherein the resource inventory comprises at least one project resource associated with the at least one project;
wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources;
identifying, using the processing device, the at least one project resource associated with the at least one project based on the analyzing of the server information and the at least one project data, wherein the at least one project resource is configured for implementing the at least one project;
analyzing, using the processing device, at least one project resource information associated with the at least one project resource based on at least one assessment rule, wherein the server information comprises the at least one project resource information;
determining, using the processing device, at least one risk score corresponding to the at least one project resource based on the analyzing of the at least one project resource information, wherein the at least one risk score represents a severity of a risk associated with the at least one project resource;
analyzing, using the processing device, the at least one risk score;
generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project;
and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device.
Davies teaches:
wherein the API interrogation process further iterates through used resources within a defined scope to collect data to build a resource inventory and maps the used resources to services of the cloud service provider, ([0046] the module 110 follows a pre-defined workflow ensuring that each element (Milestone, Task, Asset) are assigned, tracked and delivered according to the approved plan.; [0056] Additionally, the module 110 receives assets from the parties. The module 110 ensures that all assets related to the delivery of the project are appropriately classified, stored and shared. The module 110 utilizes, in one embodiment, a secure cloud storage environment with associations to the project and usage rights allowing assets to be suitable displayed as ‘part of the project’. In some embodiments, each asset is classified according to the type of file, owner, relation to other versions of the asset, purpose and relevance to the project (e.g. Input/WIP/Draft/Complete/Approved). In additional embodiments, received assets are moved from Instant Messages, Incoming APIs, Emails and direct upload to the correct workroom with version management, showing owner/updater etc. Additionally, outgoing assets, in some embodiments, are moved from the “workroom” to outgoing communication based on the correct version date and owner.);
wherein the resource inventory comprises at least one project resource associated with the at least one project; ([0056] The module 110 ensures that all assets related to the delivery of the project are appropriately classified, stored and shared.);
wherein the server information further comprises at least one metadata comprising data associated with names, types, kinds, and versions of the used resources; ([0056] The module 110 ensures that all assets related to the delivery of the project are appropriately classified, stored and shared. The module 110 utilizes, in one embodiment, a secure cloud storage environment with associations to the project and usage rights allowing assets to be suitable displayed as ‘part of the project’. In some embodiments, each asset is classified according to the type of file, owner, relation to other versions of the asset, purpose and relevance to the project (e.g. Input/WIP/Draft/Complete/Approved). In additional embodiments, received assets are moved from Instant Messages, Incoming APIs, Emails and direct upload to the correct workroom with version management, showing owner/updater etc. Additionally, outgoing assets, in some embodiments, are moved from the “workroom” to outgoing communication based on the correct version date and owner.);
identifying, using the processing device, the at least one project resource associated with the at least one project based on the analyzing of the server information and the at least one project data, wherein the at least one project resource is configured for implementing the at least one project; ([0043] In some embodiments the module 110 uses an understanding of the project type, client history and available resource(s) 105 to recommend a team with the highest likelihood of success. Potential combinations of resources are compared using output from the success forecasting service.);
analyzing, using the processing device, at least one project resource information associated with the at least one project resource based on at least one assessment rule, wherein the server information comprises the at least one project resource information; ([0047] The module 110 analyzes the impacts and is able to assess to see any changes to end delivery date and recommend new target dates to following resource(s) 105 task delivery. Based on the resource(s) 105 responses to recommended changes, the plan can either be delivered to plan or delivered to the new date (requiring client change management.);
determining, using the processing device, at least one risk score corresponding to the at least one project resource based on the analyzing of the at least one project resource information, wherein the at least one risk score represents a severity of a risk associated with the at least one project resource; ([0057] The module 110 is continuously, and in some embodiments automatically, processing the updates and assets from the parties through a task progress monitoring system 309. The task progress monitoring system 309 evaluates the progress and risk for a given task and, in some embodiments the overall project. The task progress monitoring system 309 is constantly assessed while a task is active and can trigger targeted communications to the client 101 or resource(s) 105, the more detailed escalation and change asset management service 312 if concerns are identified, when a task is completed this service triggers a project process check 320 and hand off to the next task/project close out functionality. For example, the task progress monitoring system 309 may provide schedule assessment, resource engagement, client 101 sentiment, resource(s) 105 sentiment, task completion, dependency risk, and the like. Based on the assessment of the task progress monitoring system 309, the module 110 can determine an appropriate reaction to the client 101 and the resource(s) 105 actions. The module 110 is able to process a sentiment issues 314 determined by the task progress monitoring system 309 process an escalation assessment 322 (FIG. 6), wherein an escalation risk score is calculated, and a determination is made if a third-party intervention is required. The module 110 is able to determine where a task is delayed 318, how the delay affects the overall project, and if this delay results in an adjustment to the escalation 322 of the project.);
analyzing, using the processing device, the at least one risk score; ([0067] Based on the escalation risk score, the module 110 assess 605 the escalation method. The module 110 is able to escalate to the client 606A, the personnel 606B, or a “Human-in-Loop” Project Manager 606C.; [0073] In some embodiments, the module 110 uses an integral understanding of client, resource(s) and project performance to forecast future performance. All resources, clients and projects are assessed and scored on completion of a project. These scores are then assessed to establish the likely outcome of a specific team of resources/client/project type. Indicators such as new to client, no shared experience, new project type are outputted in addition to an overall success forecast (in effect a risk measure.));
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine Dzierzanowski with Davies’ feature(s) listed above. One would’ve been motivated to do so in order to incorporate inputs into a project detailing functionality protocol. This includes, but not limited to the project type 704, the project cases 706, including specific questions for a Hiring Manager, different configurations for the project type, required input files, Project Tasks and dependencies, required resources 708, and price expectations 710 (Davies; [0069]). By incorporating the teachings of Davies, one would’ve been able to allocate resources based on project needs.
Davies doesn’t teach:
generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project;
and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device.
Ahamparam teaches:
generating, using the processing device, at least one of an exit strategy and an exit plan based on the analyzing of the at least one risk score, ([0042] a risk profile or "report card" may be generated which prioritizes various classifications of risk identified above, and benchmarks these risks against the industry best in class scores to offer a more accurate prediction of the project's success. The business unit may then use this report to facilitate risk mitigation planning, identified as step 330 in FIG. 3, discussed further below.; [0056] In accordance with this aspect of the present invention, value planning provides an early warning mechanism for projects that are likely to sub-perform, allowing quick terminations and redirection of project funds. Additionally, value planning provides early identification of "game changer" opportunities, allowing resources to be redirected to high-potential projects.; [0057] In an exemplary embodiment, with momentary reference back to FIG. 1, integrated governance 130 includes a holistic framework for managing a project based on complexity, potential business impact and risk scores.; [0078] Advancement through the checkpoints includes achieving specific entry and exit criteria and meeting relevant business metrics (i.e., risk, value, and knowledge) in order, for example, to obtain next-round funding or termination.; [0081] an exit criteria is established as illustrated in step 530. In general, the exit criteria may consist of, for example, three gateways: the fail or stop gateway; the fast fail or risk mitigation gateway; and the continuation gateway.).; [0088] The system may be implemented in hardware and/or software, so the system may include a host server or other computing systems including a processor for processing digital data, a memory coupled to said processor for storing digital data, an input digitizer coupled to the processor for inputting digital data, an application program stored in said memory and accessible by said processor for directing processing of digital data by said processor, a display coupled to the processor and memory for displaying information derived from digital data processed by said processor and a plurality of databases, said databases including client data, merchant data, financial institution data and/or like data that could be used in association with the present invention. As those skilled in the art will appreciate, user computer will typically include an operating system (e.g., Windows NT, 95/98/2000, Linux, Solaris, etc.) as well as various conventional support software and drivers typically associated with computers. User computer can be in a home or business environment with access to a network. In an exemplary embodiment, access is through the Internet through a commercially-available web-browser software package.).);
wherein at least one of the exit strategy and the exit plan provides a structured assessment output comprising recommendations indicative of feasibility of the exit procedure for the at least one project; ([0037] Preparation step 310 generally includes aligning the project with a particular business unit's goals. Preparation activities may include assigning liaisons within various business units, including identification of points of contact and key personnel, and performing due diligence. Other activities may include identification of a particular business unit problem and suggestions for resolution of the problem involving a particular project. Market research may be used in support and planning could also include discussions relating to how resolution of the problem adds value to the business unit or related customers. Implementation issues may also be discussed at this stage.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Ahamparam’s feature(s) listed above. One would’ve been motivated to do so in order to focus managers on the value drivers, metrics and practices that will maximize the return on project (Ahamparam; [0056]). By incorporating the teachings of Ahamparam, one would’ve been able to generate an exit strategy based on a risk score.
Ahamparam doesn’t teach:
and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device.
Jemiri teaches:
and transmitting, using the communication device, at least one of the exit strategy and the exit plan to the at least one client device. ([0065] Close-out Phase - this is the phase where the project is completed. This phase include project close-out reports, final invoice, project post mortem/lesson learned work shop, project punch list items, project commissioning, project operation manual, contractor/vendor/supplier demobilization, etc. The invoice tracker 130 Divedln subsystem 120 can be utilize during this phase to create various close-out reports.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so in order to run a report to determine the actual value of various resources used during the project (Jemiri; [0140]). By incorporating the teachings of Jemiri, one would’ve been able to communicate the exit strategy.
Regarding claims 2/12: Dzierzanowski doesn’t teach:
obtaining, using the processing device, one or more destination platform information associated with one or more destination platforms based on at least one of the exit strategy and the exit plan;
transmitting, using the communication device, the one or more destination platform information to the at least one client device;
receiving, using the communication device, a destination platform indication corresponding to the one or more destination platforms from the at least one client device,
wherein the destination platform indication is associated with a destination platform;
and transmitting, using the communication device, the at least one project data to a destination server associated with the destination platform based on the destination platform indication.
Jemiri further teaches:
obtaining, using the processing device, one or more destination platform information associated with one or more destination platforms based on at least one of the exit strategy and the exit plan; (Fig. 2: Client 220, Client 221, Server(s) 210, Server(s) 211, Communications Network 240; [0008] FIG. 2 depicts exemplary environments for implementing embodiments of the collaborative, multi-user platform in accordance with embodiments of the present disclosure.; [0044] Exemplary embodiments of the present disclosure relate to a collaborative, multi-user platform that is focused on supplier diversity and ESG planning and supply chain localization, connecting large enterprises and government agencies with small and diverse business on all phases of supply chain lifecycle - from strategic sourcing to project/contract close-out.; [0057] The GUIs can be rendered on display devices and can include data output areas to display information to the users as well as data entry areas to receive information from the users. For example, data output areas of the GUIs can output information associated with projects; [0059] The platform 100 can be integrated with the “Microsoft Teams” tool from Microsoft, Inc., which can be used for communication between potential project participants, project participants at all project stages; [0065] Close-out Phase - this is the phase where the project is completed. This phase include project close-out reports, final invoice, project post mortem/lesson learned work shop, project punchlist items, project commissioning, project operation manual, contractor/vendor/supplier demobilization, etc.; [0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier.);
transmitting, using the communication device, the one or more destination platform information to the at least one client device; ([0130] FIG. 19 is a flowchart illustrating an exemplary process 1900 for interaction between users, Project Owners, Prime Vendors and Suppliers within a defined "Project". A project owner creates a project with a list of resources and saves the project. A new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined. Via the collaborative communication channel, the project own transmits documents about the project and collects statistics from surveys of participants and fills in quantities for the resources need for the project and the project data is saved.; [0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier. The GUIs 2800 and 2850 can provide tabs for viewing information about resources and can include a labor tab, an equipment tab, and a materials tab. The GUIs 2800 and 2850 can list information about the resources including item names, diverse/non-diverse status and quantities and costs, and can provide graphics and/or charts for illustrating the information. The GUIs 2800 and 2850 can include options for creating, editing, and/or removing an item from the list of items for the resources. The GUI 2850 can also include options for optimizing a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history. The GUI 2850 can also include a start option and a finish option. The start option allows the supplier to officially start the project and run a report to determine the planned value for various resources tracked by the diversity planner and team optimizer subsystem. The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.);
receiving, using the communication device, a destination platform indication corresponding to the one or more destination platforms from the at least one client device, ([0140] The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier.);
wherein the destination platform indication is associated with the destination platform; ([0140] The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier.);
and transmitting, using the communication device, the at least one project data to a destination server associated with the destination platform based on the destination platform indication. (Fig. 2: Client 220, Client 221, Server(s) 210, Server(s) 211, Communications Network 240, Database(s) 230; [0130] Via the collaborative communication channel, the project own transmits documents about the project and collects statistics from surveys of participants and fills in quantities for the resources need for the project and the project data is saved.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so, so that a new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined (Jemiri; [0130]). By incorporating the teachings of Jemiri, one would’ve been able to communicate the exit strategy.
Regarding claims 7/17: Dzierzanowski doesn’t teach:
wherein the at least one project data comprises a sync interval data for scheduling the assessment of the cloud platform, wherein the transmitting of the data request is further based on the sync interval data.
Jemiri teaches:
wherein the at least one project data comprises a sync interval data for scheduling the assessment of the cloud platform, wherein the transmitting of the data request is further based on the sync interval data. ([0169] After the AI and ML models have been trained, the models are tested or validated to evaluate 4710 the trained AI and ML models, and a feedback loop is formed to analyze errors 4712 in the outputs of the trained AI and ML models and adjust or optimize the trained models 4708.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so, so that an ensemble of AI and ML algorithms are trained and deployed in the platform 100 and can be structured to be implemented in a tiered hierarchical structure (Jemiri; [0169]). By incorporating the teachings of Jemiri, one would’ve been able to capture sync interval data and transmit it in the feedback loop.
Regarding claims 8/18: Dzierzanowski doesn’t teach:
wherein the at least one project data comprises an exit strategy value for performing a risk assessment of the at least one project resource,
wherein the analyzing of the at least one project resource information is further based on the exit strategy value.
Jemiri teaches:
wherein the at least one project data comprises an exit strategy value for performing a risk assessment of the at least one project resource, ([0105] General resource report - data by all resources at the start of the project and current time/after the completion of the project will be presented (depend on the report's time).; [0140] The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.);
wherein the analyzing of the at least one project resource information is further based on the exit strategy value. ([0140] The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so in order to optimize a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history (Jemiri; [0140]). By incorporating the teachings of Jemiri, one would’ve been able to analyze resources as part of the exit strategy.
Claims 3-6, and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Dzierzanowski et al. (US 20220237565 A1, hereinafter “Dzierzanowski”), in view of Davies (US 20200327467 A1, hereinafter “Davies”), in further view of Ahamparam et al. (US 20030135399 A1, hereinafter “Ahamparam”), in further view of Jerimi (WO 2022016093 A1, hereinafter “Jemiri”), as applied to claims 1/11 above, in further view of MacInnis et al. (US 20230049749 A1, hereinafter MacInnis”).
Regarding claims 3/13: Dzierzanowski further teaches:
identifying, using the processing device, at least one high risk resource from the at least one project resource based on the analyzing of the at least one risk score, ([0143] Risk Analysis 710 captures methods to support a risk-based approach for AI/ML systems. Risks for AI/ML models may be differentiated between use that creates (i) an unacceptable risk, (ii) a high risk, (iii) low or minimal risk.);
wherein the at least one high risk resource is characterized by a high risk score; ([0143] Risk Analysis 710 captures methods to support a risk-based approach for AI/ML systems. Risks for AI/ML models may be differentiated between use that creates (i) an unacceptable risk, (ii) a high risk, (iii) low or minimal risk.);
Dzierzanowski doesn’t teach:
obtaining, using the processing device, at least one alternative resource information associated with at least one alternative resource for the at least one high risk resource;
and transmitting, using the communication device, the at least one alternative resource information to the at least one client device.
MacInnis teaches:
obtaining, using the processing device, at least one alternative resource information associated with at least one alternative resource for the at least one high risk resource; ([0037] Additionally, based on the risk score, the computing system can use the risk score to determine a resource provisioning amount that the organization is authorized to provide to the organization or employee. The computing system can then provide an output to indicate how much of the resource can be provided to the organization or employee. For example, the computing system can include a graphical user interface that displays a message indicating an amount in dollars that the organization or employee can receive.);
and transmitting, using the communication device, the at least one alternative resource information to the at least one client device. ([0037] Additionally, based on the risk score, the computing system can use the risk score to determine a resource provisioning amount that the organization is authorized to provide to the organization or employee. The computing system can then provide an output to indicate how much of the resource can be provided to the organization or employee. For example, the computing system can include a graphical user interface that displays a message indicating an amount in dollars that the organization or employee can receive.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with MacInnis’ feature(s) listed above. One would’ve been motivated to do so in order to improve the effectiveness with which risk is estimated and appropriate resources are provisioned (MacInnis; [0038]). By incorporating the teachings of MacInnis, one would’ve been able to obtain and communicate additional resources.
Regarding claims 4/14: Dzierzanowski teaches:
wherein the at least one project comprises at least one financial project associated with a financial sector in a region, ([0037] In this regard, the system has the capability to cross many sectors, such as financial services, healthcare, consumer, eCommerce, payments, risk management, and government (civilian, military, and other levels of secrecy classifications), yet is unlimited in terms of application domains, as AI/ML models have unbounded levels of applicability to problem spaces. In addition, the system substantiates the decision support capabilities in manual, augmented or fully automated implementation scenarios.; [0047] In various embodiments, the lower interfaces, process, and domain taxonomies (i.e., financial, healthcare, environmental, government civilian/military/classified) of Algorithmic Impact Assessments (AIA ), Societal Impact Assessments (SIA), Model Risk Management (MRM), Privacy Impact Assessments (PIA), legal and regulatory frameworks sourced globally are generated by the system for the particular entity (e.g., financial services, healthcare, consumer, eCommerce, payments, government etc.). Specific examples may include the EU Artificial Intelligence Act, US Government and State level legislation, FTC, FDA regulations, and privacy related assessments. For example, Article 22 of the General Data Protection Regulation (GDPR) and the European Data Protection Board (EDPB) have established conditions and guidance in relation to AI/ML systems that make decisions and are codified.; [0040] The system may approach address deployment challenges, including but not limited to US domestic and international legislative, legal, data privacy, regulatory and compliance requirements, risk frameworks, algorithmic audit, including privacy, cybersecurity, societal/social considerations, and the like. The system may include a record of data engineering decisions, data usage and archival purposes, retrieval with integrity assurance, re-usable executable components, investigation, audit, legal interrogatives, litigation, and defense support, reporting, research, model analytical analysis, and longitudinal model effectiveness studies (i.e., bias and drift analysis).);
wherein the method further comprises: receiving, using the communication device, a financial data associated with the at least one project from the at least one client device, wherein the financial data corresponds to the region; ([0037] the system has the capability to cross many sectors, such as financial services, healthcare, consumer, eCommerce, payments, risk management, and government (civilian, military, and other levels of secrecy classifications), yet is unlimited in terms of application domains, as AI/ML models have unbounded levels of applicability to problem spaces. In addition, the system substantiates the decision support capabilities in manual, augmented or fully automated implementation scenarios.; [0038] the system may eliminate or reduce record manipulation, improve record reliability, along with enabling enhanced automation features. In this regard, the system may also reduce the cost of development or system processing time for project accountability, change control and model auditing, reduce network utilization, and/or reduce data storage overhead. The system may increase data reliability or accuracy by enabling data filtering functions and reliability testing.; [0040] The system may approach address deployment challenges, including but not limited to US domestic and international legislative, legal, data privacy, regulatory and compliance requirements, risk frameworks, algorithmic audit, including privacy, cybersecurity, societal/social considerations, and the like. The system may include a record of data engineering decisions, data usage and archival purposes, retrieval with integrity assurance, re-usable executable components, investigation, audit, legal interrogatives, litigation, and defense support, reporting, research, model analytical analysis, and longitudinal model effectiveness studies.);
analyzing, using the processing device, the financial data and the at least one project resource information; ([0067] system 100 infrastructure components 140 may include, for example, immutable storage, reporting, analytic tools, time sources, and or the like.; [0068] In one or more embodiments, the system may facilitate access and versioning of remote sourced data, on-prem, local data sources, and meta-data assets, including data Access Control Lists (ACLs). The system data provenance feature addresses the prevalence and danger of data cascades, whereby data gathering, and collection upstream may have serious consequences downstream (during model development, production, and inference). In addition, data cascades may occur because of data source brittleness and model drift.; [0073] Computational environment 114 may incorporate computational notebooks and or browsers as a key element of a computation environment that provides the ability to capture a computational narrative (supplement developer code and data with analysis, algorithmic transparency, hypothesis, requirements, and compliance/regulatory chronicles). System features may include reproducibility, documentation, versioning, and provenance (code, parameters, and data) that enables developers with collaborative functionality, observability and visualization, workflow, providing reactivity (development, testing, code changes and data modifications), performing peer/audit reviews for accountability and compliance purposes.; [0138] In various embodiments with renewed reference to FIG. 1C and with additional reference to FIG. 7 a block diagram of subprocesses 700 of a post prod process module 186 reporting activities 188 is illustrated. Post prod process 186 invokes a series of methods in reporting activities 188, which further describes the postproduction subprocesses described in 700. Process 700 describes, but is not limited to, Audit 702 resources, Legal Actions 704 support, entity Reporting 706 capabilities, methods for Model Studies 708, and AI/ML Risk Analysis 710 methods by the entity.; [0139] Audit 702 provides AI/ML model, algorithmic and data related audit capabilities as an essential process for legal, regulatory, compliance, enforcement, and other requirements for entities. In various embodiments, the system capabilities for Audit 702 supports auditor activities that require a scoping, mapping, artifact collection, review process and risk analysis, reporting and mitigation design process. Additionally, in various embodiments, Audit 702 includes audit processes for assessing algorithmic capabilities designed to optimize the efficient allocation of resources for goods and services, thereby further assessing trust of AI/ML model outcomes as implemented.; [0154] The various system components discussed herein may include one or more of the following: a host server or other computing systems including a processor for processing digital data; a memory coupled to the processor for storing digital data; an input digitizer coupled to the processor for inputting digital data; an application program stored in the memory and accessible by the processor for directing processing of digital data by the processor; a display device coupled to the processor and memory for displaying information derived from digital data processed by the processor; and a plurality of databases. Various databases used herein may include client data; merchant data; financial institution data; and/or like data useful in the operation of the system. As those skilled in the art will appreciate, user computer may include an operating system (e.g., WINDOWS®, UNIX®, LINUX®, SOLARIS®, MACOS®, etc.) as well as various conventional support software and drivers typically associated with computers.).
Dzierzanowski doesn’t teach:
generating, using the processing device, a resource layer value corresponding to each of the at least one project resource based on the analyzing of the financial data and the at least one project resource information, wherein the resource laver value corresponds to alignment of the at least one project resource with a resource requirement of the at least one project;
and determining, using the processing device, at least one project layer value associated with the at least one project based on the resource layer value, wherein the at least one project layer value corresponds to a usage of at least one resource of a platform, wherein the generating of at least one of the exit strategy and the exit plan is further based on the at least one project layer value.
MacInnis teaches:
generating, using the processing device, a resource layer value corresponding to each of the at least one project resource based on the analyzing of the financial data and the at least one project resource information, ([0032] The organizational data can, in some implementations, be held as one or more object databases. For example, multiple object classes can be defined in the object databases. Example object classes include employees, devices, job candidates, benefits policies, documents, pay instances, time cards, and/or other objects. For each object, values can be provided and maintained for one or more attributes, such as location, role, salary, etc. Links can be made between different objects. For example, one or more device objects can be associated with employee objects.);
wherein the resource laver value corresponds to alignment of the at least one project resource with a resource requirement of the at least one project; ([0028] In particular, in some implementations, the organizational management platform can include tools which enable users (e.g., organizations such as corporate users) to perform payroll with respect to their employees, contractors, and/or other payees. In some implementations, performing payroll can include management, generation, and/or processing of timesheets, wage calculations, paychecks, direct deposits, and/or tax payments. For example, the organizational management platform can perform payroll by facilitating allocation of resources such as fungible currencies from one or more resource pools or accounts associated with the organizational management platform to various employees, contractors, and/or parties on behalf of the organization (e.g., as compensation for work or activities performed for the organization). Thus, performance of payroll can include transfer or allocation of resources to various parties on behalf of the organization, by means of the organizational management platform.);
and determining, using the processing device, at least one project layer value associated with the at least one project based on the resource layer value, ([0042] The computing system can determine a risk score associated with provisioning the resource to the entity. The risk score can be based at least in part on performance of one or more risk evaluation operations on the organizational data. The one or more risk factors can be respectively associated with one or more risk factor values that can be used to determine the risk score associated with a particular entity. Further, the risk score can be based at least in part on performance of one or more risk evaluation operations on the organizational data including the one or more risk factors of the entity.; [0043] In some embodiments, the risk score can be based at least in part on a sum total of the one or more risk factor values. Further, the risk score associated with high risk can be associated with a sum total of the one or more risk factor values that is high. A risk score associated with low risk can be associated with a sum total of the one or more risk factor values that is low. For example, the risk score associated with the highest risk can have a total value of one hundred (100), the risk score associated with the lowest risk can have a total value of zero (0), and the risk scores associated with intermediate levels of risk can have a total value between one (1) and ninety-nine (99).; [0044] A risk factor associated with an amount of collateral that is available to the entity can have a corresponding risk factor value that is inversely related and/or inversely proportional to the risk score. For example, an entity with a large amount of available collateral can have a low risk factor value to indicate that an entity with a greater amount of collateral presents a lower risk score.; [0045] In some embodiments, the one or more risk factors can be weighted based at least in part on the identity of the entity. The one or more risk factor values respectively associated with the one or more risk factors can have different weights. The one or more risk factors that are more heavily weighted can have a greater impact on the risk score than the one or more risk factors that are less heavily weighted. For example, a risk factor associated with an amount of collateral available to the entity can be weighed more heavily than a risk factor associated with a number of times the entity has previously repaid resources (e.g., funds) that were provisioned to the entity.; [0046] The computing system can determine a resource provisioning amount based at least in part on the risk score. The resource provisioning amount can include an amount of the resource authorized to be provisioned to the entity. The computing system can determine the resource provisioning amount based at least in part on whether the risk score is below a risk threshold. For example, if the risk threshold is twenty percent (20%), then the resource provisioning amount can zero (0) if the risk score is greater than or equal to the threshold (e.g., a risk score of thirty percent (30%)). In some embodiments, if the risk score exceeds the risk threshold, the computing system can determine that the resource provisioning amount is zero (0) and that the entity will not receive any resources. In some embodiments, if an amount of the resource that was requested in the resource request data was specified and/or indicated (e.g., a request for five hundred dollars ($500.00)), the computing system can determine a resource provisioning amount that is constrained by the requested amount (e.g., a resource provisioning amount that is not greater than the requested amount). In some embodiments, if an amount of the resource that was requested in the resource request data was not specified and/or indicated, the computing system can determine a resource provisioning amount that is not constrained by the resource request data.);
wherein the at least one project layer value corresponds to a usage of at least one resource of a platform, ([0083] Furthermore, the disclosed technology may also provide benefits including improvements in computing resource usage efficiency, security, and ease of use.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with MacInnis’ feature(s) listed above. One would’ve been motivated to do so, so that if no resources were previously remitted to or by the entity, the risk factor associated with the amount of the resource that was previously remitted to or by the entity can be determined to have no effect on the risk score or have the effect of increasing the risk score. (MacInnis; [0054]). By incorporating the teachings of MacInnis, one would’ve been able to obtain and assign a value to the resources and projects.
MacInnis doesn’t teach:
wherein the generating of at least one of the exit strategy and the exit plan is further based on the at least one project layer value.
Jemiri teaches:
wherein the generating of at least one of the exit strategy and the exit plan is further based on the at least one project layer value.
([0140] The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so in order to include a start option and a finish option (Jemiri; [0140]). By incorporating the teachings of Jemiri, one would’ve been able to generate an exit strategy based on the project and resources value.
Regarding claims 5/15: Dzierzanowski doesn’t teach:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on a rating grid associated with a regional banking federation in the region;
generating, using the processing device, at least one graphical representation based on the analyzing of at least one of the exit strategy and the exit plan, wherein the at least one graphical representation represents the at least one project value;
and transmitting, using the communication device, the at least one graphical representation to the at least one client device.
Jemiri teaches:
generating, using the processing device, at least one graphical representation based on the analyzing of at least one of the exit strategy and the exit plan, wherein the at least one graphical representation represents the at least one project value; ([0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier. The GUIs 2800 and 2850 can provide tabs for viewing information about resources and can include a labor tab, an equipment tab, and a materials tab. The GUIs 2800 and 2850 can list information about the resources including item names, diverse/non-diverse status and quantities and costs, and can provide graphics and/or charts for illustrating the information. The GUIs 2800 and 2850 can include options for creating, editing, and/or removing an item from the list of items for the resources. The GUI 2850 can also include options for optimizing a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history. The GUI 2850 can also include a start option and a finish option. The start option allows the supplier to officially start the project and run a report to determine the planned value for various resources tracked by the diversity planner and team optimizer subsystem. The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.);
and transmitting, using the communication device, the at least one graphical representation to the at least one client device. ([0130] FIG. 19 is a flowchart illustrating an exemplary process 1900 for interaction between users, Project Owners, Prime Vendors and Suppliers within a defined "Project". A project owner creates a project with a list of resources and saves the project. A new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined. Via the collaborative communication channel, the project own transmits documents about the project and collects statistics from surveys of participants and fills in quantities for the resources need for the project and the project data is saved.; [0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier. The GUIs 2800 and 2850 can provide tabs for viewing information about resources and can include a labor tab, an equipment tab, and a materials tab. The GUIs 2800 and 2850 can list information about the resources including item names, diverse/non-diverse status and quantities and costs, and can provide graphics and/or charts for illustrating the information. The GUIs 2800 and 2850 can include options for creating, editing, and/or removing an item from the list of items for the resources. The GUI 2850 can also include options for optimizing a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history. The GUI 2850 can also include a start option and a finish option. The start option allows the supplier to officially start the project and run a report to determine the planned value for various resources tracked by the diversity planner and team optimizer subsystem. The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Jemiri’s feature(s) listed above. One would’ve been motivated to do so, so that a new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined (Jemiri; [0130]). By incorporating the teachings of Jemiri, one would’ve been able to communicate the graphical representation.
Jemiri doesn’t teach:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on a rating grid associated with a regional banking federation in the region;
Ahamparam teaches:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on a rating grid associated with a regional banking federation in the region; ([0025] each funding database would be further defined by specific metrics and criteria. For example, the mandatory database 240 may be defined as those projects which are contractual, legal, or regulatory-base obligations, or the failure of which carries significant, immediate, and quantifiable loss of business. Such obligations may include banking regulations, SEC regulations, customer privacy issues and the like. Attractive database 255 may be defined as those projects that carry at least a positive 5-year net present value. Finally, unattractive database 270 may be defined as those projects having no net present value and no revenue growth potential.; [0032] Examples include those projects that may focus on mail time improvements, risk modeling, workgroup computing, operations automation, and improvements in asset and inventory management.; [0057] In an exemplary embodiment, with momentary reference back to FIG. 1, integrated governance 130 includes a holistic framework for managing a project based on complexity, potential business impact and risk scores.; [0078] Advancement through the checkpoints includes achieving specific entry and exit criteria and meeting relevant business metrics (i.e., risk, value, and knowledge) in order, for example, to obtain next-round funding or termination.; [0081] In an exemplary embodiment, an exit criteria is established as illustrated in step 530. In general, the exit criteria may consist of, for example, three gateways: the fail or stop gateway; the fast fail or risk mitigation gateway; and the continuation gateway. The fail or stop gateway is activated when the project is not on track with the predefined value proposition and/or when unforeseen and undesirable risks develop. In this case, the project may be terminated. The fast fail or risk mitigation gate is enacted when there appear risks that may jeopardize the viability of the project, but are determined manageable with the intervention of a risk mitigation plan. In this case, the various steps associated with the risk mitigation plan will be enacted in attempting to save the plan. If risk mitigation fails, the plan is aborted as described above. If mitigation is successful, the plan proceeds to the continuation gateway as described below. In accordance with a further aspect of this embodiment, mitigation and failure determinations should be made quickly so as to minimize project disruptions and/or loss. The continuation gateway is utilized where the project is on track with a solid value plan and controllable risks, and/or when the plan has been successfully mitigated as described above.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Ahamparam’s feature(s) listed above. One would’ve been motivated to do so, so that project risk of all types may be identified and allocated across a particular business unit or across an entire enterprise (Ahamparam; [0026]). By incorporating the teachings of Ahamparam, one would’ve been able to use regulation to analyze the exit strategy and exit plan.
Regarding claims 6/16: Dzierzanowski doesn’t teach:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on an escape rating grid;
generating, using the processing device, at least one graphical representation based on the analyzing of at least one of the exit strategy and the exit plan, wherein the at least one graphical representation represents the at least one project value; and
transmitting, using the communication device, the at least one graphical representation to the at least one client device.
Jemiri teaches:
generating, using the processing device, at least one graphical representation based on the analyzing of at least one of the exit strategy and the exit plan, wherein the at least one graphical representation represents the at least one project value; ([0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier. The GUIs 2800 and 2850 can provide tabs for viewing information about resources and can include a labor tab, an equipment tab, and a materials tab. The GUIs 2800 and 2850 can list information about the resources including item names, diverse/non-diverse status and quantities and costs, and can provide graphics and/or charts for illustrating the information. The GUIs 2800 and 2850 can include options for creating, editing, and/or removing an item from the list of items for the resources. The GUI 2850 can also include options for optimizing a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history. The GUI 2850 can also include a start option and a finish option. The start option allows the supplier to officially start the project and run a report to determine the planned value for various resources tracked by the diversity planner and team optimizer subsystem. The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.);
and transmitting, using the communication device, the at least one graphical representation to the at least one client device. ([0130] FIG. 19 is a flowchart illustrating an exemplary process 1900 for interaction between users, Project Owners, Prime Vendors and Suppliers within a defined "Project". A project owner creates a project with a list of resources and saves the project. A new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined. Via the collaborative communication channel, the project own transmits documents about the project and collects statistics from surveys of participants and fills in quantities for the resources need for the project and the project data is saved.; [0140] FIG. 28A-B are GUIs 28002850 of forms for the project owner and the supplier in the Diversity Planning and Team Optimizer subsystem 120 in accordance with embodiments of the present disclosure. The GUI 2800 can be generated by the subsystem 120 for the project owner and the GUI 2850 can be generated by the subsystem 120 for the supplier. The GUIs 2800 and 2850 can provide tabs for viewing information about resources and can include a labor tab, an equipment tab, and a materials tab. The GUIs 2800 and 2850 can list information about the resources including item names, diverse/non-diverse status and quantities and costs, and can provide graphics and/or charts for illustrating the information. The GUIs 2800 and 2850 can include options for creating, editing, and/or removing an item from the list of items for the resources. The GUI 2850 can also include options for optimizing a team based on diversity and options to view or access project requests, pre-bid reports, contracts, and/or a history. The GUI 2850 can also include a start option and a finish option. The start option allows the supplier to officially start the project and run a report to determine the planned value for various resources tracked by the diversity planner and team optimizer subsystem. The finish option allows the supplier to officially finish (close-out) the project and run a report to determine the actual value of various resources used during the project, which are tracked by the diversity planner and team optimizer subsystem. These options allow users to run a variance report to understand the trend in the change of supplier diversity level throughout the project lifecycle.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine Dzierzanowski, Davies, Ahamparam, Jemiri and MacInnis with Jemiri’s feature(s) listed above. One would’ve been motivated to do so, so that a new collaborative communication channel is established for the project (e.g., in Microsoft Teams) through which the project owner, supplier, and/or the prime vendor can communicate with each other, and one or more team leaders are determined (Jemiri; [0130]). By incorporating the teachings of Jemiri, one would’ve been able to communicate the graphical representation.
Jemiri doesn’t teach:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on an escape rating grid;
Ahamparam teaches:
analyzing, using the processing device, at least one of the exit strategy and the exit plan based on an escape rating grid; ([0056] In accordance with this aspect of the present invention, value planning provides an early warning mechanism for projects that are likely to sub-perform, allowing quick terminations and redirection of project funds. Additionally, value planning provides early identification of "game changer" opportunities, allowing resources to be redirected to high-potential projects. Value planning also focuses managers on the value drivers, metrics and practices that will maximize the return on project.; [0057] integrated governance 130 includes a holistic framework for managing a project based on complexity, potential business impact and risk scores.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Ahamparam’s feature(s) listed above. One would’ve been motivated to do so, so that project risk of all types may be identified and allocated across a particular business unit or across an entire enterprise (Ahamparam; [0026]). By incorporating the teachings of Ahamparam, one would’ve been able to use an escape grid (e.g., value planning) to analyze the exit strategy and exit plan.
Claims 9-10, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dzierzanowski et al. (US 20220237565 A1, hereinafter “Dzierzanowski”), in view of Davies (US 20200327467 A1, hereinafter “Davies”), in further view of Ahamparam et al. (US 20030135399 A1, hereinafter “Ahamparam”), in further view of Jerimi (WO 2022016093 A1, hereinafter “Jemiri”), as applied to claims 1/11 above, in further view of Lee et al. (US 20120179511 A1, hereinafter Lee”).
Regarding claims 9/19: Dzierzanowski doesn’t teach:
receiving, using the communication device, at least one feedback associated with at least one of the exit strategy and the exit plan from the at least one client device;
tuning, using the processing device, the at least one assessment rule based on the at least one feedback;
and generating, using the processing device, at least one tuned assessment rule based on the tuning, wherein the analyzing of the at least one project resource information is further based on the at least one tuned assessment rule.
Lee teaches:
receiving, using the communication device, at least one feedback associated with at least one of the exit strategy and the exit plan from the at least one client device; ([0017] Cluster (final) preparation (phase 4) –The purpose of cluster preparation phase is to complete preparations for the cluster to go live with the template systems and to complete the plan for transitioning to a day-to-day business operation. Typical activities in the cluster preparation phase include: ongoing project and change management; finalizing RICEF programs; final data conversion; market cutover simulation; market acceptance testing; cluster regression tests; deliver super and end-user training; completion check; and plan and prep for go live and support phase. Examples of key deliverable/results for the cluster preparation phase include: data converted; cut over checklist; contingency plan; production readiness review; legacy retirement plan; and execution of regression test. Cluster go live and support (phase 5) –The purpose of the go live and support phase is to transition the target market to use the template systems for day-to-day business operations (complete the transition from pre-production environment to a live, stable, productive operation). Typical activities for the go live and support phase include: ongoing project and change management; plan for continuous improvement; plan and preparation for sustain phase; post cluster go-live support; production support; systems monitoring; and system management; and a completion check. Examples of key deliverable/results for the cluster go live and support phase include: production ready systems environment; production capable end users; and production capable support help. Sustain (phase 6)--The purpose of the sustain phase is to implement a framework for maintaining and improving the performance of the production system.; [0152] A blueprint project 702 consists of 9 phases--evaluation, project preparation, business blueprint, realization (protocycling), realization (test preparation), realization (testing), final preparation, go-live and support, and sustain.; [0165] The model refiner 132 uses several types of machine learning for calibration of the estimation models including supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, transduction, and learning to learn. Supervised learning is accomplished with a priori (previously available labeled examples) data to determine new attributes, and offers the highest accuracy of the available learning techniques. A supervised learning algorithm generates a function that maps inputs to desired outputs. One standard formulation, of the supervised learning task, is the classification problem. An example of a leaning classification task in an embodiment of the invention is the identification of which attributes are relevant to a given dimension through regression analysis of weighting factors. In unsupervised learning, the modeling of a set of inputs is accomplished without a priori data (labeled examples). Semi-supervised learning combines both labeled and unlabeled examples to generate an appropriate function or classifier. Reinforcement learning utilizes an algorithm that learns a policy of how to act given an observation of its operating environment. Every action has some impact on the relevant operating environment, and the environment provides feedback that guides the learning algorithm. Transduction learning shares similarities to supervised learning, but does not explicitly construct a function. Instead, transduction learning tries to predict new outputs based on training inputs, training outputs, and test inputs that are available while training Finally, learning to learn is an algorithm that learns its own inductive bias based on previous experience.);
tuning, using the processing device, the at least one assessment rule based on the at least one feedback; ([0162] FIG. 1C is an embodiment of the invention that facilitates the self-calibration and refinement of project estimation models for packaged software applications. The self-calibration and refinement is carried out by the estimation system architecture 100' with the addition of a publication and subscription engine 138 to the estimation system 100 of FIG. 1A. The publication and search engine 138 publishes the resultant model (case), with all related data including the answers to the form-based questionnaires 112, scenarios with generated schedules (Gantt charts), staffing projections, costing, benefits, pricing reports, to the knowledge repository 130 that holds cases and historical data, and to stake holders 140 for their review. Stakeholders 140 include practitioners in the field for which the case was generated, as well as research and development teams in the field of interest. The model refiner 132 analyzes the case data stored and provided by the knowledge repository 130, and updates (validates and calibrates) the estimation models and parameters in the estimation knowledge base 134. The stakeholders use the published implementation project plans (cases) as guidelines for future implementations of project plans. The publish button 1050 (or an equivalent user interface selection option) in FIG. 10 of the estimated project plan rendered as Gantt chart 1000 is a possible mechanism for the user to initiate the publication process.; [0164] The estimation system (100, 100' as seen in FIGS. 1A and 1C, respectively) of embodiments of the invention utilizes the server 1304 as a communication channel/network for gathering information for calibrating and refining the estimation models. Within the estimation knowledge base 106 is an estimation knowledge discoverer and collector 128, which connects to various sources 136 (including empirical data from the project plan and cost estimation report 126, historical data--internal cases prior to implementation of embodiments of the present invention, and data from external sources, --the Web (Internet), packaged application software vendors (ISV), information from existing installations--data mining (crawler)), and collects knowledge and information relevant to estimation, including historical data of prior estimation cases contained within a knowledge repository 130. The collected knowledge and data is culled and analyzed by a model refiner 132. If validated, certain knowledge (in the form of rules and ontology) is learned by the model refiner 132, which, in turn, conveys the newly found knowledge to the estimation models as parameters that are represented in the estimation knowledge base 106.; [0165] Every action has some impact on the relevant operating environment, and the environment provides feedback that guides the learning algorithm.);
and generating, using the processing device, at least one tuned assessment rule based on the tuning, wherein the analyzing of the at least one project resource information is further based on the at least one tuned assessment rule. ([0165] Every action has some impact on the relevant operating environment, and the environment provides feedback that guides the learning algorithm.; [0165] The model refiner 132 uses several types of machine learning for calibration of the estimation models including supervised learning, unsupervised learning, semi-supervised learning, reinforcement learning, transduction, and learning to learn. Supervised learning is accomplished with a priori (previously available labeled examples) data to determine new attributes, and offers the highest accuracy of the available learning techniques. A supervised learning algorithm generates a function that maps inputs to desired outputs. One standard formulation, of the supervised learning task, is the classification problem. An example of a leaning classification task in an embodiment of the invention is the identification of which attributes are relevant to a given dimension through regression analysis of weighting factors. In unsupervised learning, the modeling of a set of inputs is accomplished without a priori data (labeled examples). Semi-supervised learning combines both labeled and unlabeled examples to generate an appropriate function or classifier. Reinforcement learning utilizes an algorithm that learns a policy of how to act given an observation of its operating environment. Every action has some impact on the relevant operating environment, and the environment provides feedback that guides the learning algorithm. Transduction learning shares similarities to supervised learning, but does not explicitly construct a function. Instead, transduction learning tries to predict new outputs based on training inputs, training outputs, and test inputs that are available while training Finally, learning to learn is an algorithm that learns its own inductive bias based on previous experience.; [0086] As a result of the summarized invention, a solution is technically achieved for generating financial benefit estimations and reports in response to the implementation of packaged software applications employing normative and constructive estimation models to determine and support decisions for estimated costs, estimated values, resource allocations, and project schedules.).
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Lee’s feature(s) listed above. One would’ve been motivated to do so in order to address issues related to business transformation as related to the value determination of IT implementations of packaged software applications (Lee; [0169]). By incorporating the teachings of Lee, one would’ve been able to update the assessment rules based on feedback received.
Regarding claims 10/20: Dzierzanowski doesn’t teach:
using the processing device, at least one market practice information associated with the at least one assessment rule, wherein the at least one market practice information represents one or more characteristics of at least one cloud service provided by at least one second cloud service provider;
tuning, using the processing device, the at least one assessment rule based on the at least one market practice information;
and generating, using the processing device, at least one tuned assessment rule based on the tuning, wherein the analyzing of the at least one project resource information is further based on the at least one tuned assessment rule.
Lee teaches:
using the processing device, at least one market practice information associated with the at least one assessment rule, wherein the at least one market practice information represents one or more characteristics of at least one cloud service provided by at least one second cloud service provider; (Fig. 13: Server, Subscription, Subscriber, Publisher; [0015] Market initiation (phase 0)--The purpose of the market initiation phase is to complete the basic activities necessary to launch the template system's implementation project in the target markets. Each market initiation implementation project will have its own unique objectives, scope, priorities, and timeline. Typical activities in the market initiation phase include: market initiation planning; market data cleansing, standardization, and mapping workshops; infrastructure planning and deployment; local support organization planning and implementation; market application and system landscape integration; ongoing project and change management; and completion check. Sample key deliverables/results include: early adoption of data standards; local area network (LAN)/wide area network (WAN) deployment strategy; market application and system landscape strategy; and local support organization design. An alternative name for phase 0 is the evaluation phase.; [0076] The method of embodiments of the present invention also include: pricing policies for the implementation of the packaged software solution are based on the calculated financial benefit of the IT solutions; wherein the pricing policies comprise value based pricing, and hybrid pricing; wherein value based pricing is based on the level of financial benefit derived from the implementation of the IT solutions; and wherein the hybrid pricing is a combination of pricing components comprising cost-plus, market based, and value based pricing, where the total price is based on the weighted contribution of each of the pricing components.; [0188] The value model, of embodiments of the present invention, captures business impact at the measurable metric level and translates it into business value of generic value drivers such as revenue growth, margin improvement, and increased capital efficiency. For this purpose, the model provides a hierarchical structure of value drivers and metrics. FIG. 16 illustrates an embodiment of a hierarchical structure 1600 that is referred to as a value driver tree, where the root 1602 is the shareholder value or profitability, and the leaf nodes are measurable operational metrics. The leaf metrics nodes are connected to the root through multiple layers of performance indicators and value drivers. The initial framework of a value driver tree can be derived from a standard such as the metrics tree associated with the APQC Process Classification Framework. The skeleton metrics tree is customized for a specific business in practice.; [0165] Every action has some impact on the relevant operating environment, and the environment provides feedback that guides the learning algorithm.);
tuning, using the processing device, the at least one assessment rule based on the at least one market practice information; ([0076] The method of embodiments of the present invention also include: pricing policies for the implementation of the packaged software solution are based on the calculated financial benefit of the IT solutions; wherein the pricing policies comprise value based pricing, and hybrid pricing; wherein value based pricing is based on the level of financial benefit derived from the implementation of the IT solutions; and wherein the hybrid pricing is a combination of pricing components comprising cost-plus, market based, and value based pricing, where the total price is based on the weighted contribution of each of the pricing components.);
and generating, using the processing device, at least one tuned assessment rule based on the tuning, wherein the analyzing of the at least one project resource information is further based on the at least one tuned assessment rule. ([0118] Embodiments of the invention provide a method and system for estimating and generating implementation project plans for packaged software applications employing normative and constructive estimation models to determine and support decisions for estimated costs, estimated values, resource allocations, and project schedules. In particular, embodiments of the invention provide multi-dimensional implementation project plans, rule-based estimation of service project phase duration, utilization of an estimation knowledge base that externalizes estimation parameters, Gantt chart generation of multi-dimensional implementation project plans, and overlapping, grouping, and clustering of rollouts in project plans.; [0130] FIG. 2A illustrates a user interface plan estimation form-based questionnaire 200 with the sector and industry tab 202 selected. The user can select one or more sectors and industries that will be taken into account in the present packaged application project to be estimated. The sector and industry takes a hierarchical form. A basic hierarchy is stored in the estimation knowledge base 134 and loaded up to the user interface through the object controller 120. The sector and industry hierarchy may be updated through the estimation knowledge base 134, and the updated map can be dynamically loaded up to the user view 102. Additionally, in this form 200, one or more questions related to the sector and industry may be presented to the user for input.; [0137] In the estimation system 100, the estimation rules may be configured through the estimation knowledge base 134.
It would have been obvious to one of ordinary skill in the art, at the time of applicant’s invention, to combine modified Dzierzanowski with Lee’s feature(s) listed above. One would’ve been motivated to do so in order to load the rule data set up from the estimation knowledge base 134 to the rule-based duration estimator 116 (Lee; [0137]). By incorporating the teachings of Lee, one would’ve been able to update the assessment rules based on market information and use them to estimate resources.
Accordingly, claims 1-20 are rejected under 35 U.S.C. 103.
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 GABRIEL J TORRES CHANZA whose telephone number is (571)272-3701. The examiner can normally be reached Monday thru Friday 8am - 5pm ET.
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, Brian Epstein can be reached on (571)270-5389. 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.
/G.J.T./Examiner, Art Unit 3625
/BRIAN M EPSTEIN/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights