DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This Office action is in response to correspondence received March 16, 2026.
Claims 1, 12, and 20 are amended. Claims 1, 3-12, and 14-22 are pending and have been examined.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on March 16 has been entered.
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, 3-12, and 14-22 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim(s) 1, 12, and 20, which are similar in scope, recite(s):
forecasting multiple scenarios, generate forecasts; ; provide a plurality of data files each comprising a plurality of assumption metrics used for forecasting, each of the data files being associated with different scenarios or with the same scenario with different assumption metrics; and responsive to receiving a request to evaluate an entity determine, based on settings at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise a default data file; determine at least one entity interrelated to the entity, the at least one entity at least in part owned by one or more owners common to the entity; generate, at least two forecasts based on the entity, the at least one entity, and the at least two data files,; and provide an output comparing the at least two forecasts to one another.
These steps are mental process steps of judgment and observation. Data files under a broadest reasonable interpretation are simply collections of data like a table or a row of data. Assumption metrics are another way of saying various assumptions before performing analysis like boundary conditions, all performable mentally. Receiving a request is observing something someone asks. Determining interrelation is looking at two things and determining that there are common owners. Generating forecasts is putting inputs into equations and reading the outputs, which can then be compared. Default file is under a broadest reasonable interpretation information that has been designated default by someone and under a broadest reasonable interpretation is merely information. Automated steps are those that are chosen in advance and followed mentally, as in rules. All of this can be performed mentally and therefore these steps describe a mental process.
This judicial exception is not integrated into a practical application. The additional elements alone and in combination are generic computing components that amount to instructions to apply the abstract idea to a computer. The combination of elements is a generic computing component and receiving from a user interface, which amounts to using a computer with an interface to perform the steps and receive information, something known that all generic computers can do. See MPEP 2106.05(f)(1-2). In combination and taking the claims as a whole, they amount to no more than largely an abstract idea, where the steps are performed using certain kinds of computer architecture and nothing more. This amounts to instructions to apply it. Therefore, as these are “apply it” elements, they are not a practical application of an abstract idea. The additional elements are:
Claim 1:
A system for the system comprising: a processor; a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the system to:
provide a forecast tool configured to
provide a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device
in the forecast tool,
, using the forecast tool
to the mobile application, via the mobile application server,
Claim 12:
a forecast tool configured to
providing a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device
in the forecast tool,
using the forecast tool
And providing to the mobile application, via the mobile application server, an output comparing the at least two forecasts to one another.
Claim 20:
A non-transitory computer readable medium for forecasting multiple scenarios, the non-transitory computer readable medium comprising computer executable instructions for
providing a forecast tool configured to
providing a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device;
in the forecast tool,
using the forecast tool,
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the reasoning from the practical application step is carried over. For the same reasons that instructions to apply the abstract idea to a computer are not a practical application, they are not significantly more.
Claims , 3-11, 14-19, 21, and 22 further describe the abstract idea with further forecasting steps that can be performed mentally. Claims 9 and 18 describe that the data files are associated with a data model trained using machine learning which merely describes an association between data files and a data model trained, it does not recite the machine learning model actively and therefore also further describes the abstract idea of claims 1 and 12.
Therefore, claims 1, 3-12, and 14-22 are rejected under 35 USC 101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 3-8, 12, 14-17, and 20-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Homann et al., US PGPUB 20060224425 A1 (“Homann”), in view of Amerasinghe, US PGPUB 20070208608 (“Amerasinghe”).
Per claims 1, 12, and 20, which are similar in scope, Homann teaches A system for forecasting multiple scenarios, the system comprising: a processor a memory coupled to the processor, the memory storing computer executable instructions that when executed by the processor cause the system to:
Homann then teaches provide a forecast tool configured to generate forecasts in par 051: “As depicted in computer architecture 100, computer system 101 includes user-interface 111 and model processing modules 112. User-interface 111 is configured to interface between a computer system user and computer system 101. User-interface 111 can provide an interface for the computer system user to enter data (e.g., selecting formal operations to perform on models of business) into model processing modules 112 and to view results of model processing modules 112.”
Homann then teaches to the forecast tool via a mobile application deployed on a mobile device in par 043: “Likewise, a computer system may include a single physical device (such as a mobile phone or Personal Digital Assistant "PDA") where internal modules (such as a memory and processor) work together to perform operations on electronic data.”
Homann then teaches provide a plurality of data files each comprising a plurality of assumption metrics used for forecasting, each of the data files being associated with different scenarios or with the same scenario with different assumption metrics in Table 1 and Par 073 and Fig 3: “Depicted in FIG. 3, schema 300 includes model data format 301. Generally, model data format 301 can be described as indicated in Table 2. TABLE-US-00002 TABLE 2 Name Data Type Description ID int Key to the model and is used to relate other data entities to this model. Name varchar(150) A unique name that identifies the model. OwnerID int Points to the owner of the model. An owner can own many models. IsTemplate bit Controls the ability of a modeler to modify this model. If this field is true, it means that this model is to be used as a template for other models and can thus be used to compare the derived models, even after properties are changed by modelers in the derived models. There- fore, this model cannot be changed by normal editors of models.” The model as shown in Fig 3 is the forecast. The assumption metrics are properties. Description ID is the scenario. Data type is data files. See also for data files par 075 sourcing type which teaches that different data is sourced.
Then Homann teaches and responsive to receiving a request to evaluate an entity determine, based on the settings in the forecast tool, at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise the default data file in par 101: “Method 500 includes an act of comparing the first instance of the structured business model to the second instance of the structured business model (act 503). For example, comparison module 113 can compare (e.g., using compare operator 233) capability model 122 to best practices capability model 123. Alternately, comparison module 113 can compare capability model 122 to proposed acquisition capability model 124. Comparison can include comparing individual business capabilities from different models to one another.” Then see par 5: “Unfortunately, interactions and interdependencies between business functions (whether in the same or different corporations) are often not well defined and/or not well documented. That is, a high level view of a business is often not well connected to the myriad of details of how the business operates.”
Per In response to receiving a request, Homann teaches in par 0123 that: “Method 900 includes an act of receiving an indication that a business architecture including a set of business components is to be modeled (act 901). For example, computer system 101 can receive an indication that a set of services are to be modeled.” See par 040: “In further other embodiments, a computer system receives an indication that a business architecture including a set of business components is to be modeled.”
For based on the settings of the forecast tool see par 051: “User-interface 111 is configured to interface between a computer system user and computer system 101. User-interface 111 can provide an interface for the computer system user to enter data (e.g., selecting formal operations to perform on models of business) into model processing modules 112 and to view results of model processing modules 112.”
Then, Homann teaches determine at least one entity interrelated to the entity, the at least one entity at least in part owned by one or more owners common to the entity in par 60: “Compose operator 231 (e.g., implemented at composition module 118) represents that one or more of capability models 202, 203, and 204 can be composed together resulting in capability model 211. Composition can include combining capability models or portions of capability models together to form a new, different, and/or combined capability model. For example, a commercial lending capability, a residential lending capability, and credit checking capability can be combined to create a mortgage application processing capability.
In par 5: “Unfortunately, interactions and interdependencies between business functions (whether in the same or different corporations) are often not well defined and/or not well documented. That is, a high level view of a business is often not well connected to the myriad of details of how the business operates.”
Then, Homann teaches generate, using the forecasting tool, at least two forecasts based on the entity, the at least one entity, and the at least two data files, in par 63: “Compare operator 233 (e.g., implemented at comparison module 113) represents that capability model 211 and capability model 212 can be compared. Capability model 211 and capability model 212 can the same (e.g., modeled in accordance with the same schema) or similarly typed capability models. For example, a shipping capability of a first business architecture can be compared to the shipping capability of a second business architecture. The results of a comparison can reveal differences and similarities in compared models. For example, comparing the shipping capabilities of the first and second business architecture can reveal that one of the shipping capabilities does not support cross-docking.”
Then. Homann teaches and provide, to the mobile application, an output comparing the at least two forecasts to one another in par 51: “User-interface 111 can provide an interface for the computer system user to enter data (e.g., selecting formal operations to perform on models of business) into model processing modules 112 and to view results of model processing modules 112.”
Under a broadest reasonable interpretation, the forecasting which is not defined in Applicant’s claims is taught by modeling. Forecasting is undefined in the specification and can reasonably be inferred to modeling or describing data.
Homann does not teach provide a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access; via the mobile application server,
Amerasinghe teaches a system that enables users to generate and manage forecasts. See abstract.
Amerasinghe teaches provide a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access; via the mobile application server in pars 0157-0159: “The present invention may be implemented using various architecture schemes, including a "zero footprint" architecture, a client-server architecture, and a "mobile web client" architecture. Notably, the software components that are used for each of these different architectures perform substantially the same functions in each architecture--only the location of the software components are changed.
An exemplary "zero footprint" architecture 662 is shown in FIG. 32. The reason this architecture is referred to a "zero footprint" is because there is no software component corresponding to the forecast and revenue management system that resides on the clients (except for an operating system and client browser software). Zero-footprint architecture 662 includes an enterprise data system 663, including a web server 664, an application server 665, and a database server 666.
The web server provides a network interface 667 that is used to handle network bi-directional network communications with various clients 668, including personal computers (PCs), laptop computers, and workstations, all of which are enabled to access the enterprise data system via a network 670 and the web server. Various business logic software components 674 are run application server 665 to enable and control the interaction between the clients, the forecast and revenue management software, and the data for the system, which are stored in a database 672 hosted on database server 666. In one embodiment, the application server further includes an object manager 676 and a data manager 678, which enable access to a data stored on database 672.” Laptop teaches mobile because it is portable.
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the mobile application for forecast generation teaching of Homann with the client server architecture teaching of Amerasinghe because one would be motivated for the data and applications to be stored on a server which would allow for more security and control of the software and data as none of it resides on the mobile device. This would allow for easier updates to software instead of having to send updates to individual workstations, which would require some level of compliance (even minimal – turning them on) to perform by individuals possessing them. Therefore, for these reasons one would be motivated to modify Homann with Amerasinghe.
Per claims 3 and 14, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann further teaches wherein the default data file incorporates a plurality of other data files, applying multiple different scenarios or assumptions to the at least two forecasts in Table 1: “Models Models serve to group capabilities into distinct groups that describe a single business. Models can contain all the capabilities defined for the business as well as how any defined capabilities relate to each other in terms of hierarchical decomposition and process flow relationships. Models facilitate the segmentation of data in a repository into distinct business models which can be compared with one another but are separate from each other. Further, while capability data is defined within a model, other data elements of the data model are outside of the model and facilitate the comparison of different models with one another.”
Per claims 4 and 15, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann further teaches wherein the at least two forecasts each comprise a comparison of at least two stages of a multi-stage forecast in pars 101-102: "Method 500 includes an act of comparing the first instance of the structured business model to the second instance of the structured business model (act 503). For example, comparison module 113 can compare (e.g., using compare operator 233) capability model 122 to best practices capability model 123. Alternately, comparison module 113 can compare capability model 122 to proposed acquisition capability model 124. Comparison can include comparing individual business capabilities from different models to one another.
Method 500 includes an act of identifying any differences between the existing business architecture and the second business architecture (act 504). For example, comparison module 113 can identify any differences between capability model 122 and best practices capability model 123. Alternately, comparison module 113 can identify any differences between capability model 122 and proposed acquisition capability model 124."
Per claims 5 and 21, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann further teaches wherein the at least two forecasts are further based on at least one dependent transaction in par 92: “This entity is assumed to be read-only by modelers because the modeling tools rely on the value of these entries to visualize service levels. Some values for service level types include "Duration", "Throughput", "Monetary Cost", "Time Cost" and "Concurrency".”
Per claims 6 and 22, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 5 and 12, above. Homann further teaches wherein the at least one entity and the entity are different children entities within a single parent entity in par 5: “Unfortunately, interactions and interdependencies between business functions (whether in the same or different corporations) are often not well defined and/or not well documented. That is, a high level view of a business is often not well connected to the myriad of details of how the business operates. For example, a manager or owner may hold knowledge of how a business is assembled in a way that is difficult to communicate in a uniform manner (e.g., informally "in heir head"). Thus, other managers (e.g., in other divisions of a corporation) or employees may have difficulty accessing such knowledge and even if they could access the knowledge, it is unlikely that it would be in a context that would be valuable to them.”
Per claims 7 and 16, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann further teaches wherein the instructions further cause the system to: determine that a refresh criterion has been satisfied in par 67: “Thus, within example mapping 400 it can be determined if existing service components provide support for a proposed new business capability. For example, the addition of proposed capability component 408 (as depicted by the dashed border) can be simulated in business capability model 401.”
Then, Homann teaches and in response to determining the satisfied refresh criteria, update the data files by rolling over the plurality of assumption metrics in par 67: “In response, mappings between business capability model 401 and service model 452 can be updated.”
Per claims 8 and 17, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann further teaches wherein the instructions further cause the system to: automatically apply compliance data files of the plurality of data files having compliance assumption metrics to the at least two forecasts in par 110: “Method 700 includes an act of accessing a structured business model of first business components representing a valid business architecture, the first business components having corresponding first property values that indicate compliance with one or more constraints, the structured business model being structured in accordance with a data model (act 701). For example, computer system 101 can access process flow model 142 having one or more process flow components representing a (an existing or simulated) business architecture that is valid based on specified criteria. Process flow model 142 can include a configuration of process flow components that adhere to industry best practices or some other set of rules that is advantageous to a business”
Then, Homann teaches and in response to the compliance data files indicating a breach, updating the output to indicate the breach in par 115: “It may be that compliance with a constraint is indicated when a second property value matches a first property value, such as, for example, when both the first and second property value equal 2. However, it may also that compliance with a constraint is indicated when a second property value is within a specified threshold of the first property value, such as, for example, within 10% of the first property value. It may also be that compliance with a constraint is indicated when a second property value is within a specified range, such as, for example, between 50 and 100. Results of checking constraints can be presented at user-interface 111 and/or transferred to some other computer system as results 161.”
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Homann et al., US PGPUB 20060224425 A1 (“Homann”), in view of Amerasinghe, US PGPUB 20070208608 (“Amerasinghe”), further in view of Jones et al., US PGPUB 20190164015 A1 (“Jones”).
Per claims 9 and 18, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 1 and 12, above. Homann does not teach wherein the data files are associated with a data model trained using machine learning.
Jones teaches machine learning techniques for evaluating entities. See abstract.
Jones teaches wherein the data files are associated with a data model trained using machine learning in par 035: “. According to an embodiment, the method may further include, at 245, verifying the output of the entity risk model to produce verified data points and, at 250, training the entity risk model using the verified data points to improve the accuracy of the output of the entity risk model and/or country risk model. In an embodiment, the method may also include identifying, by a relationship model, a relationship between one or more entities based on the collected data. According to certain embodiments, the method may include, at 255, outputting the risk score for the entity and/or the risk score for the countries to a device of an end user.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the forecasting teaching of Homann with the machine learning teaching of Jones because Jones teaches in par 016-017: “The accuracy of credit ratings as a reflection of the actual risk of doing business with potential debtors or issuers is dubious, as there have been several examples of defaults and financial disasters not detected by traditional credit ratings. Further, there is currently no capability to automatically generate and monitor the risk associated with an entity. Therefore, there is a need for improving the manner in which companies and/or institutions are evaluated or rated.
Given the deficiencies in how corporations and institutions are rated, as discussed above, example embodiments provide an artificial intelligence and machine learning enabled method for evaluating and rating the credit risk and/or non-credit risk associated with companies or institutions.” The problems in the art are identified by Jones and would motivate one ordinarily skilled in the art to combine Jones with Homann. In other words, because of the problems in credit ratings, which would be a part of the corporations and other entities described in par 05 of Homann, one would be motivated to improve this analysis with the teachings of Jones, which would provide more reliable information for the forecasting analysis of Homann. Therefore, one would be motivated to combine Homann with Jones.
Claim(s) 10 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Homann et al., US PGPUB 20060224425 A1 (“Homann”), in view of Amerasinghe, US PGPUB 20070208608 (“Amerasinghe”), further in view of Kim et al., US PGPUB 20230095016 (“Kim”).
Per claims 10 and 19, which are similar in scope, Homann and Amerasinghe teach the limitations of claims 8 and 17, above. Homann does not teach wherein the at least two forecasts comprise forecasts for a cross-trade between the at least one entity and the entity, and the compliance data files comprise assumption metrics for both the entity and the at least one entity for at least one of diversification criteria, single security weightings criteria, or loan to value criteria.
Kim teaches using machine learning to predict future trades. See abstract.
Kim teaches wherein the at least two forecasts comprise forecasts for a cross-trade between the at least one entity and the entity, and the compliance data files comprise assumption metrics for both the entity and the at least one entity for at least one of diversification criteria, single security weightings criteria, or loan to value criteria in par 037: “In example embodiments relating to electronic trading platforms, “intelligent” opening and/or closing cross trade order execution predictions are sent to client devices. One example implementation provides real-time predictions and another example implementation provides batch predictions. The description provides a detailed intelligent closing cross application example that demonstrates how very large amounts of data may be analyzed for each of many possible data transaction objects, e.g., trade requests in the example application, to identify a subset of those data transaction objects, e.g., trade requests, that merit processing resources because they have a higher probability of being executed a future execution time, e.g., at a closing cross auction.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to modify the forecasting teaching of Homann with the trade prediction teaching of Kim because Kim teaches in par 037 the following advantages: “That subset of data transaction objects and each data transaction object's corresponding probability of execution, e.g., trader orders with a predicted high likelihood of execution at closing cross, are of significant interest to end users. The advantageous results include less data communicated over data communication networks to end users and lower consumption of other computer system resources like memory storage capacity, data processing capacity, and power. In addition, the computer system performance is improved in terms of faster processing speed, faster data communication speed, lower power consumption, and the like.” One would be motivated because it would deliver the most relevant information (trades most likely to happen) which would prevent too much information being transmitted. Further fewer computing resources would be used. This would motivate one ordinarily skilled in the art because one would want only relevant information that could be used to determine fraud and breach and to use only the computer resources necessary. For these reasons one would be motivated to modify Homann with Kim.
Claim(s) 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Homann et al., US PGPUB 20060224425 A1 (“Homann”), in view of Amerasinghe, US PGPUB 20070208608 (“Amerasinghe”), further in view of Pitt, US PGPUB 20140101006 A1 (“Pitt”).
Per claim 11, Homann and Amersinghe teach the limitations of claim 1, above. Homann does not teach wherein, to provide the output, the instructions cause the processor to: receive a request to generate a configured report, the configured report collating at least some of a plurality of transactions associated with the entity
and generate a report, the report showing the at least some of the plurality of transactions as an entry, the entry being expandable to show details of the at least some of the plurality of transactions as an entry.
Pitt teaches a tax visualization program to analyze among other things compliance risk for pass through entities. See abstract.
Pitt teaches wherein, to provide the output, the instructions cause the processor to: receive a request to generate a configured report, the configured report collating at least some of a plurality of transactions associated with the entity in par 084: “FIG. 6 depicts a visualization of interpreting node information. Right-clicking on a node provides additional information and menu choices for enhancing available data for that node. Additional information can be obtained through the drop-down menu, such as preparer node, address nodes, and the like. Expansion of the nodes can also be chosen by the user as shown in FIGS. 7A through 7E, which provide examples of expanding nodes, for additional information about the entities including common addresses among related entities as well as common preparers. Right clicking on an entity results in the display of a menu as shown in FIG. 7A, where "Expanded Node" can be chosen and displayed as shown in FIG. 7B, or node addresses can be shown as in FIG. 7C.”
Pitt then teaches and generate a report, the report showing the at least some of the plurality of transactions as an entry, the entry being expandable to show details of the at least some of the plurality of transactions as an entry in par 083: “Color/pattern coding can provide pertinent information relative to asset size, level of income, shelter activity, tax haven or other characteristics. Shapes indicate the type of entity represented and line characteristics can indicate positive/negative numbers or income amount. Graphs can be further interpreted by accessing "drill down" screen menus for additional linked information within the social network such as amounts and payee/payer addresses. FIG. 5A depicts a requested entity by a bold outline, FIG. 5B depicts the graphical output of FIG. 5A and indicates BRTF total assets of >$10,000,000 and a 1040 taxpayer with a TPI of greater than $250K. FIG. 5C denotes partnerships as ovals and the parallelogram as an unknown entity ("XTIN"). Line interpretation is shown in FIG. 5D where dotted lines indicate a negative overall income, where the thicker the line, the greater the loss, and a bold line indicates net positive income. Right clicking on a line produces menu choices, such as K-1 data, hide amounts, and the like, as shown in FIG. 5E. Payer and payee information designated by the link and addresses, income amounts, and the like can also be shown using the right click feature.”
It would have been obvious to one ordinarily skilled in the art before the effective filing date of the claimed invention to model and compliance teaching of Homann with the entity interrelated determination teaching of Pitt because Pitt teaches in par 008: “Dealing with the potential tax compliance issues is hampered by the sheer volume of transactions, requiring a technological approach to focus on the critical few targets of interest to a government taxing agency.” As this would increase the ability to follow compliance, which is related to Homann’s teachings of modeling, one would be motivated to combine Homann with Pitt for this reason.
Therefore, claims 1, 3-12, and 14-22 are rejected under 35 USC 103.
Response to Remarks:
35 USC 112
Applicant has overcome 112 rejection through amendment. Examiner is grateful for Applicant referencing the sources for amendments, this speeds prosecution.
35 USC 101
Applicant argues:
Applicant respectfully submits that the amended claims should not be classified as a "mental process" as the claim limitations cannot be practically performed in the human mind. For example, it would be erroneous to suggest that the claimed steps "provid[ing] a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device" and "provid[ing] to the mobile application, via the mobile application server, an output comparing the at least two forecasts to one another" could be performed in the human mind since they involve operations that are prime examples of processes that cannot be practically performed by a human and are rooted in a specific computing architecture.
Applicant reminds the Examiner that, per the August 2025 Memorandum on "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101", the mental process grouping is not without limits. Specifically, the August 2025 Memorandum states that: "a claim does not recite a mental process when it contains limitation(s) that cannot practically be performed in the human mind, for instance when the human mind is not equipped to perform the claim limitation(s) [emphasis added].
In the present claims, the human mind is simply not equipped to perform the claim
limitations. Moreover, Applicant submits that even if, for the sake of argument, claims 1, 12, and 20 are considered to "involve" an abstract idea, this does not mean that claims 1, 12, and 20 recite an abstract idea and should be considered eligible for at least that reason.
First, nearly the entirety of the claim is an abstract idea. So, there is little leftover to consider. The steps of forecasting are done by pen and paper or mentally, and the arguments here lean on additional elements that no one would consider a mental process step. Instead they are considered in 2B. They are separable both in 101 analysis and just practically as one has to conceive of the steps to tell the computer what to do. And here, as there is no improvement to a computer or other technology shown or argued, those steps exist in the mental process realm. Examiner and Applicant will have to agree to disagree on these steps being performed in the human mind. It is not clear what step is too difficult for the human mind to do as Applicant did not elaborate, and that could be an area for Applicant to elaborate in future responses. At any rate, an alternative rejection would be that this is a certain method of organizing human activity – commercial interaction- as it is evaluating business. Applicant argues they are rooted in specific computer architecture but the claims instead show mentions of computer architecture that could be swapped for other computers. Therefore, it’s not rooted; it’s applied onto the mental process. For these reasons, the mental process finding is maintained.
Applicant argues:
According to MPEP 2106.04(d) in Prong 2 of Step 2A, examiners are meant to evaluate whether the claim as a whole integrates the exception into a practical application of that exception. Moreover, as set forth in MPEP 2106.04(d)(II), the Examiner needs to consider the limitations of the claims in combination as well as individually.
As indicated above, claims 1, 12, and 20 as amended include "provid[ing] a mobile
application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device ...
responsive to receiving a request to evaluate an entity determin[ing], based on settings in the forecast tool, at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise a default data file; ... generat[ing], using the forecast tool, at least two forecasts based on the entity, the at least one entity, and the at least two data files; and provid[ing] to the mobile application, via the mobile application server, an output comparing the at least two forecasts to one another," which clearly ties the claimed methods, computer readable medium, and system to the manner in which the forecasts are generated and the manner in which the output is provided.
From a computing perspective, "determining, based on settings in the forecast tool, at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise a default data file" improves the functionality of the associated system in general. For example, as noted in paragraph [00106], "Two different forecasts enable comparison of different scenarios. With default data file configurations of the tool 22, this can enable forecasting with little user input or queries to generate the forecasts for rapid evaluation of scenarios that the enterprise has deemed may be broadly applicable or are repeated situations." Additionally, the specific computer architecture of "a forecast tool configured to generate forecasts; ... [and] a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device" cannot be considered as "generic" and indeed improves the functionality of system in general by making the forecast tool accessible on mobile devices. For example, as noted in paragraph [0097], "In the example embodiment shown in FIG. 9, the enterprise platform 16 includes at least part of the forecast tool 22, an authentication server 126, for authenticating users to access resources 18a, 19a ,of the enterprise, and a mobile application server 128 to facilitate a mobile application to access the forecast tool 22 that can be deployed on mobile devices 12." For at least these reasons, Applicant respectfully submits that claims 1, 12, and 20 as amended are eligible at Step 2A - Prong 2.
Applicant’s argument amounts to running software on a computer improves the computer. Applicant does not elaborate as to how that is the case. Examiner disagrees, this is just using a computer to run the abstract idea, which neither improves nor worsens the computer. Applicant argues that these are not generic devices. Examiner disagrees, they are mobile application and server and as shown in the prior art laptop teaches mobile (as well as any smartphone), and server is anything that these devices interact with over the internet that hosts something, like a web application server. Further this kind of architecture is similar to the mobile unit and server which perform the functionalities of an abstract idea in TLI Communications, see MPEP 2106.05(f)(2). This section explains how even though this combination of devices (essentially the same as what Applicant claims here) performs the abstract idea steps, this is just apply it as there is no detail as to how these steps are performed (technical detail) by the devices—only that they perform them. Because this has been addressed in the guidance by a precedential decision, Applicant’s arguments are unpersuasive.
Prior Art Remarks:
Applicant argues:
Firstly, in the rejection of claims 1, 12, and 20 as previously presented, the Examiner fails to demonstrate that Homann discloses or suggests "determin[ing] at least one entity interrelated to the entity, the at least one entity at least in part owned by one or more owners common to the entity." The rejection appears to omit any mention of this feature, which is also present in the pending claims. The Examiner is respectfully reminded that a rejection for anticipation under section 102 requires that each and every limitation of the claimed invention be disclosed in a single prior art reference. In addition, the reference must be enabling and describe the applicant's claimed invention sufficiently to have placed it in possession of a person of ordinary skill in the field of the invention. See, for example, in re Paulsen, 30 F.3d 1475, 1478-79 (Fed. Cir. 1994).
Examiner appreciates the attention to this oversight as this was inadvertently left out. As Homann teaches this, the rejection would still stand as the reference teaches this but the clarity of the record needed to be improved.
provid[ing] a forecast tool configured to generate forecasts;
provid[ing] a mobile application server in communication with the forecast tool,
wherein the mobile application server facilitates access to the forecast tool via a mobile
application deployed on a mobile device;
provid[ing] a plurality of data files each comprising a plurality of assumption
metrics used for forecasting, each of the data files being associated with different
scenarios or with the same scenario with different assumption metrics; and
responsive to receiving a request to evaluate an entity
determin[ing], based on settings in the forecast tool, at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data
files comprise a default data file;
determin[ing] at least one entity interrelated to the entity, the at least one entity at least in part owned by one or more owners common to the entity;
generat[ing], using the forecast tool, at least two forecasts based on the entity, the at least one entity, and the at least two data files; and
provid[ing] to the mobile application, via the mobile application server, an output comparing the at least two forecasts to one another.
Homann describes a method of comparing and contrasting models of business.
Firstly, in the rejection of claims 1, 12, and 20 as previously presented, the Examiner fails to demonstrate that Homann discloses or suggests "determin[ing] at least one entity interrelated to the entity, the at least one entity at least in part owned by one or more owners common to the entity." The rejection appears to omit any mention of this feature, which is also present in the pending claims. The Examiner is respectfully reminded that a rejection for anticipation under section 102 requires that each and every limitation of the claimed invention be disclosed in a single prior art reference. In addition, the reference must be enabling and describe the applicant's claimed invention sufficiently to have placed it in possession of a person of ordinary skill in the field of the invention. See, for example, in re Paulsen, 30 F.3d 1475, 1478-79 (Fed. Cir. 1994).
Secondly, in the rejection of claims 1, 12, and 20 as previously presented, the Examiner asserts on page 9 of the Final Office Action that "Homann teaches ... responsive to receiving a request to evaluate an entity determine at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise the default data file." As support for this assertion, the Examiner cites paragraph [0101] of Homann. However, paragraph [0101] of Homann merely describes how "comparison module 113 can compare (e.g., using7
compare operator 233) capability model 122 to best practices capability model 123. Alternately, comparison module 113 can compare capability model 122 to proposed acquisition capability model 124." There is nothing in this passage, or anywhere else in Homann, that teaches or suggests "responsive to receivinq a request to evaluate an entity determin[ing] ... at least two data files" (emphasis added). The word "request" does not even appear in Homann. Moreover, Applicant respectfully submits that Homann certainly does not disclose or suggest "determin[ing], based on settings in the forecast tool, at least two data files of the plurality of data files for evaluating the entity, wherein the at least two data files comprise a default data file" as recited in claims 1, 12, and 20 as presently amended.
This is a similar issue as above, Examiner is always willing to clarify the record, see above in rejection.
Finally, Applicant respectfully submits that Homann fails to disclose or suggest the specific computing architecture recited in claims 1, 12, and 20 as presently amended. For example, Homann is altogether silent regarding "a mobile application server in communication with the forecast tool, wherein the mobile application server facilitates access to the forecast tool via a mobile application deployed on a mobile device" or "provid[ing] to the mobile application, via the mobile application server, an output comparing the at least two forecasts to one another."
Examiner agrees that Homann does not teach the server aspect and this is why there is a 103 now.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RICHARD W. CRANDALL whose telephone number is (313)446-6562. The examiner can normally be reached M - F, 8:00 AM - 5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Anita Coupe can be reached at (571) 270-3614. 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.
/RICHARD W. CRANDALL/ Primary Examiner, Art Unit 3619
Prosecution Insights