Patent Application 17143244 - FLEXIBLE DISCRETE EVENT SIMULATOR - Rejection
Appearance
Patent Application 17143244 - FLEXIBLE DISCRETE EVENT SIMULATOR
Title: FLEXIBLE DISCRETE EVENT SIMULATOR
Application Information
- Invention Title: FLEXIBLE DISCRETE EVENT SIMULATOR
- Application Number: 17143244
- Submission Date: 2025-05-15T00:00:00.000Z
- Effective Filing Date: 2021-01-07T00:00:00.000Z
- Filing Date: 2021-01-07T00:00:00.000Z
- National Class: 703
- National Sub-Class: 002000
- Examiner Employee Number: 94021
- Art Unit: 2188
- Tech Center: 2100
Rejection Summary
- 102 Rejections: 0
- 103 Rejections: 2
Cited Patents
The following patents were cited in the rejection:
- US 0174273đ
- US 0104215đ
- US 0199372đ
Office Action Text
DETAILED ACTION This action is in response to the amendments filed on Apr. 23rd, 2025 A summary of this action: Claims 1, 3-4, 6, 8, 12-19, 21-25, 27 have been presented for examination. Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite Claims 1, 3-4, 6, 8, 12-19, 21-25, 27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of both a mathematical concept and mental process without significantly more. Claim(s) 1, 3-4, 6, 8, 12-17, 21-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perez, âDiscrete Event Simulation: A Population Growth Exampleâ, Mar. 2016, Microsoft, MSDN Magazine, Vol. 31, No. 3, URL: download(dot)microsoft(dot)com/download/8/b/f/8bfccbb0-3d14-4495-9586-e41a6c1557cd/mdn_1603dg(dot)pdf taken in view of previously cited Saucier et al., âComputer Generation of Statistical Distributionsâ, Mar. 2000 Claims 18-19 and 27 are not rejected under § 102/103 This action is Final Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Arguments/Amendments Regarding the § 102/103 Rejection Given the cancellation of significant amounts of subject matter in the dependent claims, the claim scope is now broad enough that a new grounds of rejection is presented below under § 102/103 as was necessitated by the amendments. Regarding the priority denial The priority denial is maintained in part, and withdrawn in part, in view of the amendments. No remarks were submitted for consideration. Regarding the claim objections These are mostly maintained. The amendments did not address a substantial number of the objections, and no remarks outside of the amendments were submitted for consideration. Regarding the § 112(b) Rejection This is maintained. With respect to the remarks, âx is the variable of integrationâ â this does not define what âxâ is, i.e. what values would POSITA plug into âxâ to perform the integration with when practicing this claim, or trying to determine what the scope of this claim is. The Examiner suggests cancelling the claim, and the disclosure sheds no light on this variable, as previously noted in the rejection. Regarding the § 101 Rejection This is maintained, and updated as necessitated by amendment. With respect to the remarks, the Examiner respectfully disagrees â the present claims are not drawn to any particular technological implementation, but rather to the abstract idea itself. Furthermore, these remarks do not even submit what the improvement to technology is, i.e. its left unalleged, but for a bare assertation that itâs an improvement. ¶¶ 6-8 of the instant disclosure merely convey that there are problems in the mathematics itself (in the statistical analysis). Furthermore, the present amendments remove even any hint of any particular software implementation, let alone any particular software implementation that is significantly more then what is well-understood, routine, and conventional in the field of use (see the prior rejection for the 2B WURC consideration). With respect to the § 102/103 remarks, MPEP § 2106.05(I): âAs made clear by the courts, the "ânoveltyâ of any element or steps in a process, or even of the process itself, is of no relevance in determining whether the subject matter of a claim falls within the § 101 categories of possibly patentable subject matter." Intellectual Ventures I v. Symantec Corp., 838 F.3d 1307, 1315, 120 USPQ2d 1353, 1358 (Fed. Cir. 2016) (quoting Diamond v. Diehr, 450 U.S. at 188â89, 209 USPQ at 9). See also Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a claim for a new abstract idea is still an abstract idea. The search for a § 101 inventive concept is thus distinct from demonstrating § 102 novelty."). In addition, the search for an inventive concept is different from an obviousness analysis under 35 U.S.C. 103.â Claim Objections Claims 1, 3-4, 6, 8, 12-26 are objected to because of the following informalities: The claims recite several modules, e.g. âevent moduleâ â the Examiner notes that in view of the instant disclosure and the context of the claims, these are software modules âexecutable by the electronic processorâ, but to ensure clarity the Examiner suggests amending them to include the âsoftwareâ modifier, or another similar term, e.g. âevent software modulesâ Claim 4 recites âthe population generator moduleâ but only depends upon claim 1, not claim 3. Claim 1 does not have this element. The Examiner suggests using the articles âaâ/âanâ for the first recitation Claim 15 recites âthe sampling point Xâ, however as this is a first recitation the Examiner suggests using the articles âaâ/âanâ Claim 19 recites âVarâ, however the claim does not define what this is. The Examiner infers this variable is the same as claim 18, i.e. âvarianceâ, and suggests amending the claim to reflect this (see ¶ 71 to clarify on this inference: âVar stands for varianceâ) The claims have numerous issues with antecedent basis. The Examiner suggests amending the claims such that the first recitation of each distinct element uses articles such as âaâ/âanâ, later recitations referring back to the same distinct element uses articles such as âtheâ/âsaidâ, to use disambiguating modifiers (e.g., first, second, etc.) when there are multiple distinct elements with the same base term, and that the use of modifiers for each distinct element is kept consistent. Below is a non-exhaustive list of examples of these issues: âevent modules⊠event modulesâŠâ â the second recitation, given the context of the claim, refers back to the first, but the claim does not explicitly do so. The Examiner suggests using the articles âtheâ/âsaidâ âmembersâŠmembersâ, wherein the second recitation does not explicitly refer back to the first but the context of the claim indicates it is intended to. The Examiner suggests using the articles âtheâ/âsaidâ âinvoking event modules of the plurality of event modulesâ â at issue is that this is unclear if this is invoking only some of the event modules, or all of them. Given the context of the claim, the Examiner suggests using a more disambiguating phrase, e.g. invoking at least one or more pre-coded event modules of the plurality of pre-coded event modules âinstructions readableâŠâ is thrice recited without disambiguation or reference between these elements. Given the context of the claims, the Examiner suggests one single recitation of âinstructions readable and executable by the electronic processor to perform operations comprising: perform a discrete event simulation (DES) method comprising⊠implementing a user interface (UI) operating in conjunction with the display and the at least one user input device for user review of the members of the at least one population class and user review of the output DES data;âŠâ and so on â i.e. the Examiner suggests making the claim more clearly reflect itâs a set of steps/operations to be performed by the processor. Claim 4 recites âattributes of the membersâ however claim 1 already recites âattributes of the membersâ â similar suggestion as above Appropriate correction is required. Priority Applicantâs claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows: The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994). The disclosure of the prior-filed applications, Application No. 62/957,943 and 62/959,390, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. At issue is that the particular combination recited in the present claims is not sufficiently described in either the â943 or the â390 provisional applications on their own, but rather draw upon an undisclosed particular combination of the features of these two separately filed provisional application. See MPEP § 2163(II)(A): âFor example, in Hyatt v. Dudas, 492 F.3d 1365, 1371, 83 USPQ2d 1373, 1376-1377 (Fed. Cir. 2007), the examiner made a prima facie case by clearly and specifically explaining why applicantâs specification did not support the particular claimed combination of elements, even though applicantâs specification listed each and every element in the claimed combination. The court found the "examiner was explicit that while each element may be individually described in the specification, the deficiency was lack of adequate description of their combination" and, thus, "[t]he burden was then properly shifted to [inventor] to cite to the examiner where adequate written description could be found or to make an amendment to address the deficiency." Id.; see also Stored Value Solutions, Inc. v. Card Activation Techs., 499 Fed. Appâx 5, 13-14 (Fed. Cir. 2012) (non-precedential) (Finding inadequate written support for claims drawn to a method of processing debit purchase transactions requiring three separate authorization codes because "the written description [did] not contain a method that include[d] all three codes" and "[e]ach authorization code is an important claim limitation, and the presence of multiple authorization codes in [the claim] was essential".).â Also see MPEP 2163(I): "An applicant shows that the inventor was in possession of the claimed invention by describing the claimed invention with all of its limitations using such descriptive means as words, structures, figures, diagrams, and formulas that fully set forth the claimed invention. Lockwood v. Amer. Airlines, Inc., 107 F.3d 1565, 1572, 41 USPQ2d 1961, 1966 (Fed. Cir. 1997)." See the present independent claim 1, and dependent claim 27. Claim 1 recites: âperform M outer loops where M is an integer greater than one, each outer loop including: for each parameter of the system model, randomly drawing a value for the parameter with replacement from a set of discrete sampling points distributed over the PDF associated with the parameter; and running the DES method N times using the system model with the randomly drawn values for the parameters of the system model wherein N is an integer greater than one, wherein the output DES data are annotated by the randomly drawn values for the parametersâ This feature is solely described in the â390 provisional application, e.g. see claim 1, see fig. 1-2 and their accompanying descriptions. The â943 provisional application does not sufficiently describe the particular presently claimed combination, e.g. see the â943 claim 1, and fig. 1 to fig. 3, e.g. the present claims recite: ârandomly drawing a value for the parameter with replacement from a set of discrete sampling points distributed over the PDF associated with the parameterâ whereas the â943 ¶ 22 recites only: âIn generating each member, the attributes are selected using the corresponding attribute PDFs defined in the parameter file 22, by drawing random numbers from the random number generator 14 of the DES controller 10â which does sufficiently describe what is presently claimed. Claim 27 recites âThe discrete event simulator of claim 1 wherein the event modules of the plurality of event modules comprise object-oriented programming (OOP) objects grouped into module groups, wherein the module groups have group-level class definitions and event modules belonging to a module group inherit the group-level class definitions of the module group to which the event modules belong.â â this feature is only sufficiently described in the â943 provisional application, e.g. ¶ 25 and elsewhere. The â390 provisional application is silent as to such a feature, e.g. it does not described object-oriented programming objects, nor does it describe event modules, let alone the remaining portions of the particular combination of elements recited in the present claims. In addition, claim 1 also recites: storing: a plurality of event modules readable and executable by the electronic processor to define events that transform attributes of members of at least one population class in accord with probabilistic event models defined by event model parameter files; application programming interfaces (APIs) defining flow of members of the at least one population class amongst the event modules; - this is not sufficiently described in the â390 application. Rather, this is in the â943 application â i.e. there is not sufficient support in either one of these provisional alone for the particular combination (of the two Provisionals) now presently claimed. As such, for at least the above reasons, the present claim 1 and its dependents are not sufficiently described by either provisional application on its own, and therefore the present claims 1 and dependents thereof do not receive the benefit of priority to either of the provisional applications, as neither provisional application, taken on its own, sufficiently describe the ordered particular combinations recited in each of the present independent claims. Claim Rejections - 35 USC § 112(b) The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.âThe specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. Claim 15 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 15 recites an equation. In said equation, there is a lowercase âxâ â the lowercase âxâ is not defined in the instant disclosure as to what it is. See ¶ 14 and ¶ 52. Thus, the claim is indefinite because the variable is undefined to POSITA. As a point of clarity, the Examiner notes that POSITA may have recognized this equation as being in substantially similar form as the well-known equation defining a cumulative distribution function in statistics, and as such speculated that this was the CDF equation. Under this speculative interpretation, which should be adopted should the § 112(b) rejection be reversed given that the disclosure provided no details on what âxâ is, a ground of rejection has been entered below under § 103. Else should this rejection be affirmed, then the § 103 rejection would be withdrawn in view of MPEP § 2143.03(I): âHowever, an examiner should not simply speculate about the meaning of the claim language and then enter an obviousness rejection in view of that speculative interpretation. In re Steele, 305 F.2d 859,134 USPQ 292 (CCPA 1962) (The "considerable speculation" by the examiner and the Board as to the scope of the claims did not provide a proper basis for an obviousness rejection.). A claim should not be rejected over prior art just because it is indefinite. Ionescu, 222 USPQ at 540 (citing Steele).â. 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-4, 6, 8, 12-19, 21-25, 27 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of both a mathematical concept and mental process without significantly more. Step 1 Claim 23 is directed towards the statutory category of a process. Claim 1 is directed towards the statutory category of an apparatus. Claim 12 is directed towards the statutory category of an article of manufacture. Claims 12 and 23, and the dependents thereof, are rejected under a similar rationale as representative claim 1, and the dependents thereof. Step 2A â Prong 1 The claims recite an abstract idea of both a mental process and mathematical concept. See MPEP § 2106.04: â...In other claims, multiple abstract ideas, which may fall in the same or different groupings, or multiple laws of nature may be recited. In these cases, examiners should not parse the claim. For example, in a claim that includes a series of steps that recite mental steps as well as a mathematical calculation, an examiner should identify the claim as reciting both a mental process and a mathematical concept for Step 2A Prong One to make the analysis clear on the record.â To clarify, see the USPTO 101 training examples, available at https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility. The mathematical concept recited in claim 1 is: incrementing a timepoint for the DES until a stopping criterion is met; - math calculations in textual form, i.e. adding/incrementing a number to another number wherein the DES method simulates a system represented by a system model having parameters with associated probability density functions (PDFs), and the non- transitory storage medium further stores instructions readable and executable by the electronic processor to perform M outer loops where M is an integer greater than one, each outer loop including: for each parameter of the system model, randomly drawing a value for the parameter with replacement from a set of discrete sampling points distributed over the PDF associated with the parameter; and running the DES method N times using the system model with the randomly drawn values for the parameters of the system model wherein N is an integer greater than one, - math calculations/equations/relationships in textual form, but for the mere instructions to do it on a computer. To clarify on the BRI of the simulating with PDFs, see ¶¶ 49-51: âIn approaches disclosed herein, Monte Carlo simulation is used to specify a set of parameter values drawn from a discrete set of possible parameter values, e.g. defined as a set of percentiles. This set of Monte Carlo-generated parameter values is used to perform a certain number of simulation iterations (e.g., user specified), and outputs information about both the values of the parameters (selected by the Monte Carlo sampling for the simulation) and the outputs (e.g., used to estimate variance). By the combination of using Monte Carlo sampling, and more specifically Monte Carlo sampling⊠Since all calculations (e.g. expectation or variance) are done on only those model outputs (Y) that were generated by the same model input (X), it can be challenging to produce simulations with the same set of input parameter values with few iterations for a large number of input parametersâ â then see ¶¶ 52-53; also see ¶¶69-72 With respect to the randomly drawing, this is akin to âi. performing a resampled statistical analysis to generate a resampled distribution, SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163-65, 127 USPQ2d 1597, 1598-1600 (Fed. Cir. 2018), modifying SAP America, Inc. v. InvestPic, LLC, 890 F.3d 1016, 126 USPQ2d 1638 (Fed. Cir. 2018);â as discussed in MPEP § 2106.04(a)(2)(I)(C). To clarify on this, the Examiner notes the opinion of SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161: ââŠTo remedy those deficiencies, the patent proposes a technique that "utilizes resampled statistical methods for the analysis of financial data," which do not assume a normal probability distribution. Id ., col. 1, line 65 through col. 2, line 3. One such method is a bootstrap method, which estimates the distribution of data in a pool (a sample space) by repeated sampling of the data in the pool. Id ., col. 10, lines 20-38. A sample space in a bootstrap method can be defined by selecting a specific investment or a particular period of time. Id ., col. 12, lines 62-66. Data samples are drawn from the sample space "with replacement": samples are drawn from the sample space and then returned to the pool before the next sample is drawn. Id ., col. 10, lines 60-62, col. 11, lines 18-20.â Claim 12 recites a similar mathematical concept as claim 1, and as such is rejected under a similar rationale. To clarify, in claim 12 the limitations as below are the math concept: performing M outer loops where M is an integer greater than one, each outer loop including: for each parameter, randomly drawing a value for the parameter with replacement from a set of discrete sampling points distributed over the PDF associated with the parameter; and running N simulations of the system using the system model with the randomly drawn values for the parameters wherein N is an integer greater than one Claim 23 is rejected under a similar rationale as claims 1 and 12 for the similar recitations. Under the broadest reasonable interpretation, the claim recites a mathematical concept â the above limitations are steps in a mathematical concept such as mathematical relationships, mathematical formulas or equations, and mathematical calculations. If a claim, under its broadest reasonable interpretation, is directed towards a mathematical concept, then it falls within the Mathematical Concepts grouping of abstract ideas. In addition, as per MPEP § 2106.04(a)(2): âIt is important to note that a mathematical concept need not be expressed in mathematical symbols, because "[w]ords used in a claim operating on data to solve a problem can serve the same purpose as a formula." In re Grams, 888 F.2d 835, 837 and n.1, 12 USPQ2d 1824, 1826 and n.1 (Fed. Cir. 1989). See, e.g., SAP America, Inc. v. InvestPic, LLC, 898 F.3d 1161, 1163, 127 USPQ2d 1597, 1599 (Fed. Cir. 2018)â See MPEP § 2106.04(a)(2). To clarify, see the USPTO 101 training examples, available at https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility. The mental process recited in claim 1 is: incrementing a timepoint for the DES until a stopping criterion is met; - a mental process, of a person simply providing a mental judgement of a timescale with time increments/points, e.g. from 0 to 60 seconds a person would readily be able to judge to use 1 second timepoints, e.g. 1 second, 2 second, etc. at increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs; - a mental process, but for the mere instructions to do it on a computer, e.g. a person mentally observing information about members of a population class, e.g. âa patient (i.e. a member of a patient class) and a surgeon (i.e., a member of a doctor class) and/or a hospital (i.e. a member of a medical institution class)â (¶ 34), and mentally evaluating said information so as to process said information, e.g. suppose itâs a âsurgery eventâ, a person would readily be able to mentally evaluate so as to determine/â define that the patient processed by the surgery event then flows to a post-operative recovery event and to a surgery reimbursement claim request event.â As discussed in ¶ 34, but for the mere instruction to do this analysis on a computer wherein the DES method simulates a system represented by a system model having parameters with associated probability density functions (PDFs), and the non- transitory storage medium further stores instructions readable and executable by the electronic processor to perform M outer loops where M is an integer greater than one, each outer loop including:âŠrunning the DES method N times using the system model with the randomly drawn values for the parameters of the system model wherein N is an integer greater than one, - a mental process, but for the mere instructions to do it on a computer. For example, a person observes table(s) of information, specifically table(s) of the randomly drawn values of each simulation run (e.g. on the display of a computer or on paper). The person then makes some simple calculations using physical aids such as pen, paper, and/or a calculator to perform the simulation. E.g. see ¶¶ 4-6 which discuss an example of a âtrucking fleetâ, wherein ââŠFor the illustrative trucking fleet model, as an example, the fuel efficiency of trucks of the fleet may be represented by a random variable having a Gaussian PDF. The mean of the Gaussian PDF represents the average fuel efficiency of all trucks in the fleet, while the variance of the Gaussian PDF represents the "spread" or "variation" of fuel efficiency amongst the trucks of the fleet. In this example, switching from a more expensive grade of diesel fuel that provides higher fuel efficiency to a less expensive grade of diesel fuel that provides lower fuel efficiency could be simulated by adjusting two or three model parameters: the price of diesel fuel, the mean of the Gaussian PDF of the random variable representing truck fuel efficiency, and possibly also the variance of the Gaussian PDF.A first set of simulations can then be run using the first set of parameters in order to model trucking fleet operations using the more expensive grade of diesel fuel; and likewise a second set of simulations can then be run using the second set of parameters in order to model trucking fleet operations using the less expensive grade of diesel fuelâŠâ â now suppose that the trucking fleet only has 3 trucks (e.g. a local landscaping company). A person would readily be able to use a computer as a tool to obtain the results of the random drawing with replacement math concept, e.g. as a table (or a table per each of the three trucks). Suppose the simulation was only run 3 times for each case (the cheap fuel, and the expensive fuel) â thus, 6 tables, each table have 3 rows (2 tables per truck; 1 table per case per truck; 3 rows representing the 3 runs per case per truck). A person would then readily be able to evaluate such data, e.g. by using a calculator, or pen and paper, or both, to mentally evaluate what the average value for each table is, thus performing an example of the simulation under the BRI. wherein the output DES data are annotated by the randomly drawn values for the parameters. â a mental process, e.g. a person observing output data of the math calculations, e.g. on the display of a computer or in a table on paper, and annotating the data, e.g. suppose the output data is already in tabular form on paper, wherein each row in the table corresponds to a single simulation run. The person would readily be able to annotate such a table, such as by adding in a column for each parameter, and in the row for a particular run writing down what the drawn values were (after having observed what they were, e.g. on the display of a computer). To clarify, and in view of Example 45 of the Oct. 2019 PEG, appendix I, page 21: âscientists and engineers have been solving the Arrhenius equation in their minds since it was first proposed in 1889.â - see Murthy, K. P. N. "Monte Carlo: Basics." arXiv preprint cond-mat/0104215 (2001). § 1 ¶¶ 3-8. Also see § 9 including: âGenerate once for all, a fairly long sequence of random numbers from a random physical process. Employ this in all your Monte Carlo calculations. This is a safe procedure. Indeed tables of random numbers were generated and employed in the early days of Monte Carlo practice, see for example [3]...Tables of random numbers are useful if the Monte Carlo calculations are carried out manuallyâŠâ â note reference # 3 is from 1927, before the invention of digital computers. Claims 12 and 23 are rejected under a similar rationale as claim 1 for their similar recitations. Under the broadest reasonable interpretation, these limitations are process steps that cover mental processes including an observation, evaluation, judgment or opinion that could be performed in the human mind or with the aid of physical aids but for the recitation of a generic computer component. If a claim, under its broadest reasonable interpretation, covers a mental process but for the recitation of generic computer components, then it falls within the "Mental Process" grouping of abstract ideas. A person would readily be able to perform this process either mentally or with the assistance of physical aids. See MPEP § 2106.04(a)(2). To clarify, see the USPTO 101 training examples, available at https://www.uspto.gov/patents/laws/examination-policy/subject-matter-eligibility. In particular, with respect to the physical aids, see example # 45, analysis of claim 1 under step 2A prong 1, including: âNote that even if most humans would use a physical aid (e.g., pen and paper, a slide rule, or a calculator) to help them complete the recited calculation, the use of such physical aid does not negate the mental nature of this limitation.â; also see example # 49, analysis of claim 1, under step 2A prong 1: âMoreover, the recited mathematical calculation is simple enough that it can be practically performed in the human mind. Even if most humans would use a physical aid, like a pen and paper or a calculator, to make such calculations, the use of a physical aid would not negate the mental nature of this limitation.â As such, the claims recite an abstract idea of both a mental process and mathematical concept. Step 2A, prong 2 The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d). The following limitations are merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the âUse of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly moreâ: Claim 1: A discrete event simulator for performing DES, the discrete event simulator comprising: an electronic processor; a display operatively connected with the electronic processor; at least one user input device operatively connected with the electronic processor and a non-transitory storage medium storing: - in particular, note that this is merely stored data a plurality of event modules readable and executable by the electronic processor to define events that transform attributes of members of at least one population class in accord with probabilistic event models defined by event model parameter files; application programming interfaces (APIs) defining flow of members of the at least one population class amongst the vent modules; and instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising: âŠat increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs;⊠- the use of a generic API and generically describes âevent modulesâ are considered as part of the mere instructions to use a computer as a tool. Claim 12: A discrete event simulator comprising: an electronic processor; a display operatively connected with the electronic processor; at least one user input device operatively connected with the electronic processor; and a non-transitory storage medium storing instructions readable and executable by an electronic processor to perform a simulation method for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the simulation method comprising: Claim 23 - A discrete event simulation (DES) method for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the simulation method comprising: using a computer,⊠simulation results for each simulation are stored in the non-transitory storage medium To clarify, the Examiner notes that the above are considered as part of the mere instructions to do it on a computer, including the use of a computer store data in its ordinary capacity. The following limitations are adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g): Claim 1 â the âstoringâŠâ of the data is considered as a insignificant pre-solution activity of mere data storage Should the following limitation: Claim 1 - at increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs; - not be considered as part of the abstract idea, but for the mere instructions to do it on a computer, then this would be considered as a nominal/tangential portion of the claimed invention with no link to the primary process of the claimed invention (i.e. the simulation itself), also an âinsignificant computer implementationâ as discussed in MPEP § 2106.05(g) Claim 1 - and instructions readable and executable by the electronic processor to implement a user interface (UI) operating in conjunction with the display and the at least one user input device for user review of the members of the at least one population class and user review of the output DES data; - mere data displaying. Claim 12 now has a similar recitation and is rejected under a similar rationale. Claim 1 - and responsive to the stopping criterion being met, outputting DES data comprising attributes of the members of the at least one population class at least at the time increment at which the stopping criterion is met â mere data outputting Claim 12 - and simulation results for each simulation are stored in the non- transitory storage medium annotated by the randomly drawn values for the parameters, - mere data storage The similar limitation in claim 23 is rejected under a similar rationale. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. See MPEP § 2106.04(d). The claimed invention does not recite any additional elements that integrate the judicial exception into a practical application. Refer to MPEP §2106.04(d). Step 2B The claimed invention does not recite any additional elements/limitations that amount to significantly more. The following limitations are merely reciting the words "apply it" (or an equivalent) with the judicial exception, or merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea, as discussed in MPEP § 2106.05(f), including the âUse of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application or provide significantly moreâ: Claim 1: A discrete event simulator for performing DES, the discrete event simulator comprising: an electronic processor; a display operatively connected with the electronic processor; at least one user input device operatively connected with the electronic processor and a non-transitory storage medium storing: - in particular, note that this is merely stored data a plurality of event modules readable and executable by the electronic processor to define events that transform attributes of members of at least one population class in accord with probabilistic event models defined by event model parameter files; application programming interfaces (APIs) defining flow of members of the at least one population class amongst the vent modules; and instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising: âŠat increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs;⊠- the use of a generic API and generically describes âevent modulesâ are considered as part of the mere instructions to use a computer as a tool. Claim 12: A discrete event simulator comprising: an electronic processor; a display operatively connected with the electronic processor; at least one user input device operatively connected with the electronic processor; and a non-transitory storage medium storing instructions readable and executable by an electronic processor to perform a simulation method for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the simulation method comprising: Claim 23 - A discrete event simulation (DES) method for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the simulation method comprising: using a computer,⊠simulation results for each simulation are stored in the non-transitory storage medium To clarify, the Examiner notes that the above are considered as part of the mere instructions to do it on a computer, including the use of a computer store data in its ordinary capacity. The following limitations are adding insignificant extra-solution activity to the judicial exception, as discussed in MPEP § 2106.05(g): Claim 1 â the âstoringâŠâ of the data is considered as a insignificant pre-solution activity of mere data storage Should the following limitation: Claim 1 - at increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs; - not be considered as part of the abstract idea, but for the mere instructions to do it on a computer, then this would be considered as a nominal/tangential portion of the claimed invention with no link to the primary process of the claimed invention (i.e. the simulation itself), also an âinsignificant computer implementationâ as discussed in MPEP § 2106.05(g) Claim 1 - and instructions readable and executable by the electronic processor to implement a user interface (UI) operating in conjunction with the display and the at least one user input device for user review of the members of the at least one population class and user review of the output DES data; - mere data displaying. Claim 12 now has a similar recitation and is rejected under a similar rationale. Claim 1 - and responsive to the stopping criterion being met, outputting DES data comprising attributes of the members of the at least one population class at least at the time increment at which the stopping criterion is met â mere data outputting Claim 12 - and simulation results for each simulation are stored in the non- transitory storage medium annotated by the randomly drawn values for the parameters, - mere data storage The similar limitation in claim 23 is rejected under a similar rationale. In addition, the following are also considered as well-understood, routine, and conventional activities, as discussed in MPEP § 2106.05(d): Claim 1 - storing: a plurality of event modules readable and executable by the electronic processor to define events that transform attributes of members of at least one population class in accord with probabilistic event models defined by event model parameter files; application programming interfaces (APIs) defining flow of members of the at least one population class amongst the event modules;- this is considered WURC in view of: MPEP § 2106.05(d)(II): âi. 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); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) ("Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired resultââa result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink." (emphasis added)); iii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;â Pegden et al., US 8,156,468, see the âBackground of the inventionâ section including âOver the 50 year history of discrete event simulation, the growth in applications has been facilitated by some key advances in modeling that have simplified the process of building, running, analyzing and viewing modelsâ and its discussion of object-oriented programming including: ââŠWithin this framework, objects are implemented by coding one or more methods that change the state of an object. Derived objects may override (i.e., replace) methods that are inherited from its parent class, or extend the behavior by adding additional methods. The roots of these ideas date back to the early 1960s with the Simula 67 simulation modeling tool. That tool was created by Kristen Nygaard and Ole-Johan Dahl (1962) of the Norwegian Computing Center in Oslo to model the behavior of ships. Nygaard and Dahl introduced the basic concepts of creating classes of objects that own their data and behavior, and could be instantiated into other objects. This was the birth of modern object-oriented programmingâŠ.â And as continued in col. 3: âA number of products have been introduced to Support an object orientation, to date they have all been simply the direct application of OOP languages to developing objects for use in simulation modelingâŠâ â also see col. 4: âUnlike existing object-oriented tools that require programming to implement new objects, SimioTM objects can be created with simple graphical process flows that require no programming.â Should clarification on this be required, the Examiner notes that this Pegden reference itself was subject to a § 101 analysis including WURC findings at the Federal Circuit, see Simio, LLC v. FlexSim Software Prods., Inc., 983 F.3d 1353 (Fed. Cir. 2020). For relevance, the Examiner also notes that the instant disclosure, ¶ 63 states âFlexSimâ may be used as a software tool in the instant invention For additional WURC evidence, also see the journal publication related to this Pegden reference - Pegden, C. Dennis. "SIMIO: a new simulation system based on intelligent objects." 2007 winter simulation conference. IEEE, 2007. See §§ 1-2 including: âObjects are built using the concepts of object orientation. However unlike other object oriented simulation systems, the process of building an object is very simple and completely graphicalâ and see § 3 including: âMany popular programming languages such as C++, C#, and Java are all built around the basic principles of object oriented programming (OOP). In this programming paradigm software is constructed as a collection of cooperating objects that are instantiated from classes. These classes are designed using the core principles of abstraction, encapsulation, polymorphism, inheritance, and compositionâŠâ and § 4 including: âThe Simio object framework is built on the same basic principles as object oriented programming languages; however these principles are applied within a modeling framework and not a programming framework⊠Wasadikar, Amit, "Developing An Object-oriented Approach For Operations Simulation In Speedes" (2005). Electronic Theses and Dissertations. 414. University of Central Florida. § 1.2 including: âAn Object-Oriented Simulation consists of a set of objects that interact with each other over time [1]. The strength of Object-Oriented Simulation lies in producing independent, component based code that can be changed, enhanced, and reused easily. In Object-Oriented Simulation (OOS), the complex logic of the model can be embedded into implementation classes, and a real-world entity can be represented using simulation objects. Features of Object- Oriented Programming like Encapsulation, Data Hiding, Inheritance, and Reusability are significant in such simulation techniques [2]âŠâ, also § 1.2 including: âThe property of reusing the attributes and behavior from base class to child class is called Inheritance.â Dagkakis, Georgios, Ioannis Papagiannopoulos, and Cathal Heavey. "ManPy: an openâsource software tool for building discrete event simulation models of manufacturing systems." Software: Practice and Experience 46.7 (2016): 955-981. § 4.2: âDiscrete event simulation is traditionally an appropriate paradigm where object-oriented (OO) programming can be used [48]âŠâ Rendle, âA Brief History of the Future of the APIâ, May 2020, Presentation at QCON London 2020, Recording at www(dot)infoq(dot)com/presentations/api-history/ - âWe had to create application programming interfaces. We had to create ways that if we made a piece of software, whether that was an order management, stock control, usually finance back in those days, banks were early adopters. They had lots of different applications dealing with different things. Those applications needed to be able to talk to each other. They had to create APIs. We've been using APIs, as programmers. Pretty much everything we use could be considered an API⊠Then everything we interact with, whether that's a database, or a messaging system, or a queue, that has an API that we talk to as well. Then of course, we got the higher-level APIs now of talking to other services in service oriented architecture or microservicesâŠâ Walkowiak, Tomasz, and Jacek Mazurkiewicz. "Availability of discrete transport system simulated by SSF tool." 2008 Third International Conference on Dependability of Computer Systems DepCoS-RELCOMEX. IEEE, 2008. § 1 including: âWe propose to use the SSF (Scalable Simulation Framework) [2] instead of dedicated system elaboration. Our previous works [5][7][9][11] perfectly show that is very hard to prepare the simulator which includes all aspects of discrete transport. The SSF is a base for SSFNet [3] a popular simulator of computer networks.â â then see § 4 for its description of SSF including: âSSF is an object-oriented API - a collection of class interfaces with prototype implementations. It is available in C++ and Java. SSFAPI defines just five base classes: Entity, inChannel, outChannel, Process, and Event. The communication between entities and delivery of events is done by channels (channel mappings connects entities). [3]â Fan, Su-Ling, H. P. Tserng, and Ming-Teh Wang. "Development of an object-oriented scheduling model for construction projects." Automation in construction 12.3 (2003): 283-302. § 4 including: âObject-oriented modeling is a new way of problem solving for the abstraction problems that exist in the real world⊠The implementation of object-oriented methodology is widely applied in the computer-integrated constructionâŠ.â See the instant disclosure, ¶ 63: âThis may entail operations such as loading a commercial discrete event simulation (DES) or other probabilistic simulation software package (e.g. AnyLogic simulation tool available from AnyLogic;âŠâ â then see Lebedev, AnyLogic Dynamic Simulation Presentation, February, 13, 2019, URL: anylogic(dot)com/upload/presentations/munich-feb-2019/anylogic-and-anylogic-cloud-presentation(dot)pdf â see slide 13-14, 28-29 Teo, Yong Meng, and Yew Kwong Ng. "SPaDES/Java: object-oriented parallel discrete-event simulation." Proceedings 35th Annual Simulation Symposium. SS 2002. IEEE, 2002. Abstract, § 1 Penn, US 2004/0199372, ¶¶ 7-12 Claim 1 - at increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs;- this is considered WURC in view of the above discussed evidence Claim 1 - and instructions readable and executable by the electronic processor to implement a user interface (UI) operating in conjunction with the display and the at least one user input device for user review of the members of the at least one population class and user review of the output DES data; - and the similar limitation in claim 12- WURC in view of MPEP § 2106.05(d): âiv. Presenting offers and gathering statistics, OIP Techs., 788 F.3d at 1362-63, 115 USPQ2d at 1092-93;â as well as the Oct. 2019 PEG appendix I, page 35, for example 46: âSimilarly, limitation (c) is just a nominal or tangential addition to the claim, and displaying data is also well-knownâ Claim 12 - and simulation results for each simulation are stored in the non- transitory storage medium annotated by the randomly drawn values for the parameters, - this is considered WURC in view of the above discussed evidence, including MPEP § 2106.05(d)(II): âiii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;â Claim 23 - simulation results for each simulation are stored in the non- transitory storage medium - this is considered WURC in view of the above discussed evidence, including MPEP § 2106.05(d)(II): âiii. Electronic recordkeeping, Alice Corp. Pty. Ltd. v. CLS Bank Int'l, 573 U.S. 208, 225, 110 USPQ2d 1984 (2014) (creating and maintaining "shadow accounts"); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93;â The claimed invention is directed towards an abstract idea of both a mathematical concept and a mental process without significantly more. Regarding the dependent claims Claim 3 is further specifying data that is stored as part of the insignificant extra-solution activity of mere data storage, wherein claim 3 does not even require the population generator modules to be executed, i.e. this is simply stored information, and the storage of information is WURC in view of the above discussed evidence including MPEP § 2106.05(d)(II). Furthermore, should it be found that claim 3 is to be construed such as to require the execution, the step performed by claim 3 would be nothing more than part of the abstract idea itself, i.e. reciting a step in the math concept of math calculations in textual form, as well as a mental process (of a person mentally observing PDFs, e.g. on paper or the display of a computer, e.g. ¶ 39: âAt an operation 96, the user can review the members 20 via the UI 42.â, and then generating data for other members based on those PDFs, e.g. by copying the PDFs; wherein the PDFs are recited in such generality that these may be readily represented by histograms/bars charts with a few data points, e.g. 5, thus being simple enough for a person to mentally perform this step), but for the mere instructions to do it on a computer. A person would also readily be able to modify a simple PDF of a few values, e.g. of 5 values in a table, such as by writing in a 6th value. Claim 4 is akin to claim 3 of simply adding data stored, but does not actually require the execution of the stored data (the Examiner notes that there is no âpopulation generator moduleâ in claim 1, i.e. this is merely part of the stored data), and thus claim 4 is rejected under a similar rationale as claim 3. Should claim 4 be construed to require these steps to be performed rather than just part of stored code, then this would be an insignificant extra-solution activity of mere data gathering that is WURC in view of Saucier, Richard. "Computer generation of statistical distributions." Army Research Laboratory (2000). § 3 and its subsections. Also see: Murthy, K. P. N. "Monte Carlo: Basics." arXiv preprint cond-mat/0104215 (2001). § 9, include seeing § 9.2 Johansen, Adam M., Ludger Evers, and N. Whiteley. "Monte carlo methods." International encyclopedia of education (2007). ww(dot)warwick(dot)ac(dot)uk/fac/sci/statistics/staff/academic-research/johansen/teaching/mcm-2007(dot)pdf. See § 1.4 Claim 6 is further limiting what data is output in the insignificant extra-solution activity of mere data outputting that is WURC in view of the above evidence. Claim 8 is considered part of the mental process, but for the mere instructions to do it on a computer as was discussed above with respect to claim 1, should claim 8 not be found to be part of the mental process then this is generally linking to a particular field of use of surgery, rather then other fields, e.g. trucking, as discussed in ¶ 47, and other fields, as discussed in ¶ 4: âBy way of a few nonlimiting illustrative examples, systems amenable to simulation include roadway traffic systems (e.g. roadway networks, trucking fleets), aviation networks (e.g., airports, airline hub networks), computer networks (e.g. modeling data flow to study possible bottlenecks or the like), manufacturing facilities (e.g. modeling assembly lines), medical services (e.g. services delivery and reimbursement), financial systems (e.g. stock markets), and so forth.â As a further point of clarity, see US PGPUB 2021/0174273, include seeing its corresponding PTAB appeal # 2024-001718 Claim 13 is further limiting the math concept to particular mathematical relationships of ânon-uniform, non-multinomial distributionâ, followed by math calculation in textual form of the âselectingâŠâ, wherein this is recited in such generality that this is also a mental step, e.g. a person observing a histogram or similar such plot showing the distribution, dividing the distribution according to percentiles, â e.g. 10th, 25th, 50th, 75th, and 90thâ (¶ 52) such as by drawings lines with pen and paper on the chart, or doing something similar in a tabular form of the data (akin to a principle/president of a school observing a table of student grades and mentally judging who will receive honors at graduation by judging who the top 10% of students are). Claim 14 is further limiting both the math concept and the mental process Claim 15 is further limiting the math concept and mental process in a manner similar to claim 13 and rejected under a similar rationale, wherein the Examiner notes that the equation recited is the well-known equation of the CDF (cumulative distribution function) integral, see: NIST, Engineering Statistics Handbook, § 1.3.6.2, URL: www(dot)itl(dot)nist(dot)gov/div898/handbook/eda/section3/eda362(dot)htm, accessed via Wayback Machine with archive date Mar. 21st, 2019, see the equation of the âCumulative Distribution Functionâ Claim 16 is further limiting the math concept and adding in another math calculation in textual form, wherein this is recited in such generality that for a small distribution (e.g. 10 points, in table), a person would readily be able to mentally perform such a step by a mental evaluation. Claim 17 is further limiting the math concept, then reciting math calculations in textual form, wherein the calculations are recited with such generality that a person may readily performed these mentally with physical aids, e.g. observe a table of values representing said distribution (e.g. 10 points), and calculating the value mentally, with pen and paper, of which has the highest probability of occurrence, e.g. if 2 of the 10 points are 0.5, and the rest are other values, then 0.5 has a probability of 2/10=1/5. Claim 18 is reciting math calculations in textual form, wherein such math calculations are readily performed mentally using physical aids such as pen, paper, and a calculator. Claim 19 is reciting another math calculation in textual form, wherein such a calculation is also readily able to be performed mentally with physical aids, e.g. a pen, paper, and a calculator, for a small set of data As a point of clarity, the equations recited in claims 18-19, taken together, form a law of mathematics in statistics. To clarify, this is the law of total variance. See Dorsman, Stochastic Simulation, Fall 2018 Lecture Notes, University of Amsterdam, staff(dot)fnwi(dot)uva(dot)nl/j(dot)l(dot)dorsman/Downloads/StochSim1819/Slides_Stoch_Sim_JLD_variance_reduction(dot)pdf â see slide 30 for its equation for the âLaw of Total Varianceâ See MPEP § 2106.04(b): â"Likewise, Einstein could not patent his celebrated law that E=mc2; nor could Newton have patented the law of gravity." Id. Nor can one patent "a novel and useful mathematical formula," Parker v. Flook, 437 U.S. 584, 585, 198 USPQ 193, 195 (1978);â â and this is not even a novel formula, but rather one of the fundamental laws of the mathematics of statistics Claim 20 is merely adding the same additional elements to claim 12 as was recited in claim 1, i.e. claim 20 is rejected under a similar rationale as the similar recitations in claim 1. Claims 21 is generally linking to a particular field of use/technological environment by specifying a number of parameters â see ¶ 51: âHowever, for a large, complex model with dozens, hundreds, or more parameters,â and ¶ 48 â wherein the instant disclosure does not even describe such models with any details. Furthermore, see Gottschalk v. Benson, 409 U.S. 63, 175 USPQ 673 (1972) and Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1139, 120 USPQ2d 1473, 1474 (Fed. Cir. 2016) as discussed in MPEP § 2106.04(a)(2)(III). Also see âThe use of a physical aid (e.g., pencil and paper or a slide rule) to help perform a mental step (e.g., a mathematical calculation) does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. For instance, in CyberSource, the court determined that the step of "constructing a map of credit card numbers" was a limitation that was able to be performed "by writing down a list of credit card transactions made from a particular IP address." In making this determination, the court looked to the specification, which explained that the claimed map was nothing more than a listing of several (e.g., four) credit card transactions. The court concluded that this step was able to be performed mentally with a pen and paper, and therefore, it qualified as a mental process. 654 F.3d at 1372-73, 99 USPQ2d at 1695â in MPEP § 2106.04(a)(2)(III)(B) - wherein the presently claimed invention is readily applicable with a simple system model with only a small number of parameters, e.g. a dozen, or fewer (e.g. 2), with small numbers of N and M, e.g. N = 2, M = 2 Claim 22 is rejected under a similar rationale as claim 8 as discussed above Claims 24-25 as rejected under similar rationale as claim 21 as discussed above Claim 27 is rejected under a similar rationale as similar recitations in the independent claims, i.e. an insignificant extra-solution activity of an insignificant computer implementation, as well as part of the mere instructions to do it on a computer, wherein this is WURC in view of the evidence discussed above for claim 1 The claimed invention is directed towards an abstract idea of both a mathematical concept and a mental process without significantly more. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1, 3-4, 6, 8, 12-17, 21-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perez, âDiscrete Event Simulation: A Population Growth Exampleâ, Mar. 2016, MicroSoft, MSDN Magazine, Vol. 31, No. 3, URL: download(dot)microsoft(dot)com/download/8/b/f/8bfccbb0-3d14-4495-9586-e41a6c1557cd/mdn_1603dg(dot)pdf taken in view of previously cited Saucier et al., âComputer Generation of Statistical Distributionsâ, Mar. 2000 Regarding Claim 1 Perez teaches: A discrete event simulator for performing DES, the discrete event simulator comprising: an electronic processor; a display operatively connected with the electronic processor; at least one user input device operatively connected with the electronic processor and a non-transitory storage medium (Perez, see the article starting on page 32, in particular see the C# code in the âImplementation sectionâ, and the title â this is C# code for discrete event simulation on a computer; and fig. 12 shows an example of the results on the display of the computer storing: a plurality of event modules readable and executable by the electronic processor to define events that transform attributes of members of at least one population class in accord with probabilistic event models defined by event model parameter files; application programming interfaces (APIs) defining flow of members of the at least one population class amongst the event modules; (Perez, fig. 5 which shows âThe Structure of the Simulation Applicationâ wherein the âEventsâ folder shows there are âEventâ modules, wherein these are modules of the parent class of the population âindividualâ, e.g. the âMethodsâ such as âFindCoupleâ, âEndRelationâ (fig. 6, as methods these are API calls); to clarify see fig. 7-8, and the section âimplementationâ ¶¶ 1-4, include seeing in fig. 7-8 the use of probability distributions for the event models, e.g. the âExponentialâ âdistributionâ and âNormalâ âdistributionsâ â the Examiner notes the âGive Birth Methodâ in fig. 8 is an event module for the âFemaleâ class of fig. 5 to clarify that the APIs are used for defining flow of members â see fig. 10 for when these APIs are called, wherein this occurs for a plurality of âTimeâ increments (the âwhileâŠâ loop); and for each member of the population class, i.e. the inner âforâŠâ loop, e.g. for it first checks for whether the individual is âfemaleâ and âPregnantâ and if so calls the âGiveBirthâ event module through the API; then it is to âCheck whether someone starts a relationship this yearâ, etc.) and instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising: (Perez, as discussed above) incrementing a timepoint for the DES until a stopping criterion is met; (Perez, as discussed above, fig. 10, the âWhileâŠâ loop which increments until the âTimeâ stopping criterion) at increments of the timepoint, invoking event modules of the plurality of event modules to process members of the at least one population class in accord with flow of the members of the at least one population class amongst the event modules of the plurality of event modules as defined by the APIs; (Perez, fig. 10, as discussed above) and responsive to the stopping criterion being met, outputting DES data comprising attributes of the members of the at least one population class at least at the time increment at which the stopping criterion is met; (Perez, fig. 10 as discussed above; then see fig. 11-12; should further clarification be sought see the accompanying description of these figures â wherein in fig. 11 this is the code for âViewing the Population over Timeâ till â1000â time increments, then afterwords present the results in the âConsoleâ in fig. 12) and instructions readable and executable by the electronic processor to implement a user interface (UI) operating in conjunction with the display and the at least one user input device for user review of the members of the at least one population class and user review of the output DES data; (Perez, fig. 12 as discussed above; to clarify see the last few paragraphs of the Implementation section on page 39: âFinally, the Execute method, shown in Figure 10, is where all simulation logic occurs. Iterations in the outer loop represent years that go by in the simulation. The inner loop goes through events that might occur to those individuals in that particular year. To see how the population evolves over time, I set up a new console application, shown in Figure 11. Figure 12 shows the population after 1,000 years.â) wherein the DES method simulates a system represented by a system model having parameters with associated probability density functions (PDFs), and the non- transitory storage medium further stores instructions readable and executable by the electronic processor to perform M outer loops where M is an integer greater than one, each outer loop including: (Perez, as discussed above, fig. 10 for its âWhileâŠâ loop) for each parameter of the system model, randomly drawing a value for the parameter âŠfrom a set of discrete sampling points distributed over the PDF associated with the parameter; (Perez, as discussed above, the random drawing occurs during the events of Perez in the simulation, e.g. see fig. 7-8 as discussed above) and running the DES method N times using the system model with the randomly drawn values for the parameters of the system model wherein N is an integer greater than one, wherein the output DES data are annotated by the randomly drawn values for the parameters. (Perez, fig. 10 as discussed above, the âForâŠâ loop for each individual in the population) While Perez does not teach that the random drawing is with replacement (i.e. the bootstrap method), this would have been obvious when Perez was taken in view of Saucier: ⊠with replacement⊠(Perez, as discussed above; taken in view of Saucier, § 3.5 ¶¶ 1-2: âOne very simple technique for generating distributions is to sample from a given set of data. The simplest technique is to sample with replacement, which effectively treats the data points as independent. The generated distribution is synthetic data set in which some fraction of the original data is duplicated. The bootstrap method (Diaconis and Efron 1983) uses this technique to generate bounds on statistical measures for which analytical formulas are not known. As such, it can be considered as a Monte Carlo simulation (see section 3.7)â It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings from Perez on a C# demo of discrete event simulation which drew values from various PDFs with the teachings from Saucier on methods for generating random numbers including the bootstrapping method with replacement. The motivation to combine would have been that âIt is simple and fastâ (Perez, § 3.5 ¶ 2). Regarding Claim 3 Perez teaches: The discrete event simulator of claim 1 further storing: a population generator module readable and executable by the electronic processor to generate the members of the at least one population class by, for each population class, processing a population class parameters file defining probability density functions (PDFs) for attributes of the population class to generate members of the population class with attributes distributed over the generated members in accord with the PDFs for the attributes of the population class. (Perez, as discussed above - there are population classes for âIndividualâ, âMaleâ, and âFemaleâ (fig. 5) â then see fig. 11, as discussed on the last page in the last column: âA uniform sample is generated to first determine if the new individual will be female or male, each with a probability of 50 percent (0.5). The ChildrenCount value is decremented by 1, indicating that this woman has one less child to give birth to. The rest of the code relates to individual initialization and resetting some variables.â â i.e. the members of the population classes are first generated based on defined PDFs) Regarding Claim 4 Perez teaches: The discrete event simulator of claim further storing a single random number generator, wherein the population generator module draws random numbers from the single random number generator in generating the members of the at least one population class and the event modules draw random numbers from the single random number generator in processing the members of the at least one population class. (Perez, as discussed above, is using the stored single random number generator of C# for its drawing steps; to clarify the Examiner notes Perezâs code does not have a custom random number generator, but rather is merely doing function calls in C#, thus POSITA would readily have inferred it was using the stored random number generator of C# and calling to it Should Perez be found not to teach a single random number generator, then see Saucier, abstract: âSince most of these distributions rely upon a good underlying uniform distribution of random numbers, several candidate generators are presented along with selection criteria and test resultsâ then § 2 ¶ 2: âThis report describes various ways to obtain distributions, how to estimate the distribution parameters, descriptions of the distributions, choosing a good uniform random number generator, and some illustrations of how the distributions may be used.â Then § 3 ¶ 1: âWe should point out that all of these methods presume that we have a supply of uniformly distributed random numbers in the half-closed unit interval [0, 1). These methods are only concerned with transforming the uniform random variate on the unit interval into another functional form.â, e.g. see § 5.1.16 which provides the source code for the normal RNG using solely the âuniformâ RNG as its source, in other words Perez teaches using a single stored âuniformâ RNG for generating a variety of different distributions, with âtransformingâŠâ the output of the uniform RNG to generate various non-uniform distributions â wherein POSITA would have been motivated to use Perezâs technique because âMoreover, it allows the userâprogrammer to specify an arbitrary function or procedure to use for generating distributions that are not already in the collection. It is also shown that it is very easy to extend the collection to include new distributions.â (Perez, § 1 ¶ 2) Regarding Claim 6 Perez teaches: The discrete event simulator of claim 1wherein the output DES data further comprises attributes of the members of the at least one population class at one or more time increments prior to the time increment at which the stopping criterion is met. (Perez, fig. 11-12; note the caption of fig. 11 states that this for âViewing the Population over timeâ and clarified on page 39: âTo see how the population evolves over time, I set up a new console application, shown in Figure 11. Figure 12 shows the population after 1,000 years.â â POSITA would have been suggested to have view this at other time increments as well, e.g. by using similar lines such as the âforeachâ and âConsole.WriteLineâ, but doing this for time increments before the 1000, or at least would have found it obvious to do so because in doing so one would more readily be able to see the evolution over time of the population (e.g. by displaying it as a chart). Regarding claim 8 Perez teaches: The discrete event simulator of claim 1 wherein: the at least one population class includes at least a patients population class; and the plurality of pre coded event modules includes one or more medical diagnosis modules belonging to a medical diagnosis module group, one or more medical surgery event modules belonging to a medical surgery module group, and one or more medical insurance reimbursement event modules belonging to a medical insurance reimbursement module group. (Perez, section âDiscrete Event Simulation: ¶ 3: âObjects represent elements of the real system. They have properties, they relate to events, they consume resources, and they enter and leave queues over time. In the airplane takeoff and landing scenario mentioned earlier, the objects would be airplanes. In a health care system, objects might be patients or organs.â Then ¶ 5: âEvents are things that can occur in the system, especially to objects, such as the landing of an airplane, the arrival of a product at a warehouse, the appearance of a particular disease and so forth.â Then ¶6: âResources are elements that provide services to objects (for example, a landing strip in an airport, storage cells in a warehouse and doctors in a clinic).â Then ¶ 7: âQueues can have a maximum capacity and they can have different calling approaches: first-in-first-out (FIFO), last-in-first-out (LIFO), or based on some criteria or priority (disease progression, fuel consumption and the like).â Then ¶ 8: âTime (as it happens in real life) is essential in simulation. To measure time, a clock is started at the beginning of a simulation and can then be used to track particular periods of time (departure or arrival time, transportation time, time spent with certain symptoms, and so on).â In view of these suggestions of Perez, POSITA would have found been suggested to have applied Perezâs technique to simulate âpatientsâ working with âdoctors in a clinicâ for diagnosis of a âdiseaseâ and monitoring its âprogressionâ; To further clarify, the Examiner takes Official Notice that doctors monitoring a disease progression would also be working on treatment options for said disease, wherein such treatment options routinely include surgery depending on the disease progression and severity, and wherein medical insurance re-imburses for the cost of the treatment; e.g. if the disease is an infected tooth (the root of the tooth being infected), surgery is routinely performed to remove the disease, e.g. a root canal or a tooth extraction, and insurance would be checked for reimbursement of costs of said treatment; e.g. if the disease is advanced gangrene or frostbite, amputation may be performed Thus, POSITA would have found it obvious to arrive at what is claimed â because by following Perezâs suggestion to use DES simulation for simulating patients with a disease and the progression of the disease, along with provided services by doctors as suggested by Perez, POSITA would have found it obvious that those services would have included surgery (the official notice above) and the billing practices, e.g. medical reimbursement from insurance companies/organizations (e.g. Medicare/Medicaid) common in at least the US health care system, and would have included those services in the simulation to make the simulation more complete and more realistic as âSimulation is a technique in which a real-life system or process is emulated by a designed modelâ (Perez, ¶ 2, page 32) As a second point of obviousness of this limitation, Perezâs DES simulation is demoed on population modeling with females having events for âGetting pregnantâ and âHaving a childâ â the Examiner takes Official Notice that there are several steps between those two; e.g. the doctors visits, and that routinely surgery is performed during this process, e.g. a C-section, and routinely billed to insurance â and thus, POSITA would have also found it obvious to have improved the granularity of Perezâs simulation by simulating addition events during the process of a female giving birth, e.g. simulating the event that some females medically require a C-section, and that insurance typically reimburses for such an event. POSITA would have desired to improve the granularity because âSimulation is a technique in which a real-life system or process is emulated by a designed modelâ (Perez, ¶ 2, page 32), and in real-life not all pregnancies go well. Regarding Claim 12. This is rejected under a similar rationale as claim 1 above. Regarding Claim 13. Perez teaches: The discrete event simulator of claim 12 wherein the simulation method further comprises: for each parameter whose PDF is a non-uniform, non-multinomial distribution, selecting the set of discrete sampling points for the parameter as values for which the cumulative density function (CDF) corresponding to the PDF have percentile values belonging to a set of predefined percentile values. (Perez, as discussed above, uses a variety of non-uniform unimodal (not multi-nominal) distributions, e.g. fig. 1-3; fig. 7-8 which use âNormalâ and âExponentialâ and âPoissonâ distributions, e.g. for the normal distribution as discussed on page 36: âFifty percent of the distribution lies to the left of the mean and 50 percent to the right.â; as to the CDF, page 34, col.2, ¶ 2: âThe sum of all probabilities [the CDF] must be 1, and each individual probability must be between 0 and 1.â, then see fig. 8 which samples from âNormalâ âDistributionsâ, i.e. it is sampling from 0 % to 100% of the normal distribution) to further clarify on the CDF, also see Saucier, § 5.1.8 on page 20: âExamples of probability density functions and cumulative distribution functions are shown in Figures 19 and 20, respectively.â â wherein fig. 20 shows that the summation is to â1â for the CDF; similarly see § 5.1.16 and its figures for a âNormal (Gaussian)â distribution Regarding Claim 14 This claim is rejected under a similar rationale as claim 13 above, as there are two predefined percentile values in Perez of 0 and 100%. Regarding Claim 15. Perez in view of Saucier teaches: The discrete event simulator of claim 12 wherein the simulation method further comprises: for each parameter whose PDF is a non-uniform, non-multinomial distribution, selecting the set of discrete sampling points for the parameter to correspond to a set of predefined percentile values wherein the parameter value corresponding to a given predefined percentile value PV represented as a decimal value is given by the sampling point X satisfying the equation:⊠(Perez, as discussed above for claim 13; then see Saucier § 3.1 fig. 1 which shows a normal PDF on the lower half, and its associated CDF in the upper half; wherein the equation on page 3, ¶ 1 is the equation claimed â to be particular, the claimed equation is appears to be (note the § 112(b) rejection above) merely reciting the equation that defines a CDF from a PDF, i.e. the integral of the PDF from negative infinity to âxâ, x being the upper side of the PDF. As a point of clarity, this is a speculative claim interpretation in view of the above § 112(b) rejection, i.e. the Examiner is speculating that POSITA would have recognized the equation in claim 15 as encompassing, but not limited to, the equation for a CDF. See MPEP § 2143.03(I) Regarding Claim 16. Perez teaches: The discrete event simulator f claim 12 wherein the simulation method further comprises: for each parameter whose PDF is a uniform distribution over an interval, selecting the set of discrete sampling points for the parameter the set of D discrete sampling points that divide the uniform distribution into D+1 equal pieces. (Perez, see the table in fig. 1 which gives the âProbability of a Relationship endingâ then see page 38: âThe EndRelation method is basically a translation of the probability table for determining the chance of a relationship ending. It uses a uniform random variable, which produces a random value in the range [0, 1] equivalent to producing an acceptance percentage. The distributions dictionary is created in the simulation class (described shortly) and holds pairs (event, probability distribution), thus associating every event with its distribution:â â see the code following this section to clarify Regarding Claim 17. Perez in view of Saucier teaches: The discrete event simulator of claim 12 wherein the simulation method further comprises: for each parameter whose PDF is a multinomial distribution, selecting the set of discrete sampling points for the parameter as the single value with highest probability of occurrence in the multinomial distribution. (Perez, as discussed above, which uses several different types of distributions; as taken in further view of Saucier § 5.1.26: âExamples of a user-specified bimodal probability density and the corresponding distribution are shown in Figures 55 and 56, respectively.â â and see the âSource Codeâ including its sampling point range from âMinâ to âMaxâ) wherein POSITA would have been motivated to use Perezâs technique because âMoreover, it allows the userâprogrammer to specify an arbitrary function or procedure to use for generating distributions that are not already in the collection. It is also shown that it is very easy to extend the collection to include new distributions.â (Perez, § 1 ¶ 2) Regarding Claim 21. Perez teaches: The discrete event simulator of claim 12 wherein the system model has hundreds of parameters. (Perez, pages 32-33, section âDiscrete Event Simulationâ, also page 32 ¶¶ 1 -2, i.e. while Perez gives a simple example application with only a limited number of parameters, to do so for hundreds of parameters would have been obvious because this would have been in the routine experimentation POSITA would have performed when applying DES simulations to more complex systems, e.g. a simple example: âIn the airplane takeoff and landing scenario mentioned earlier, the objects would be airplanes.â â page 32, last paragraph; wherein when POSITA was tasked with creating a DES simulation of all aircraft takeoff and landings across the country, e.g. for the US Federal Aviation Administration (FAA), POSITA would have readily recognized that the system would have needed to have hundreds, if not thousands, of parameters, and POSITA would have found it obvious to try apply DES to such a simulation See MPEP § 2144.05(II), including: âIn re Williams, 36 F.2d 436, 438, 4 USPQ 237 (CCPA 1929) ("It is a settled principle of law that a mere carrying forward of an original patented conception involving only change of form, proportions, or degree, or the substitution of equivalents doing the same thing as the original invention, by substantially the same means, is not such an invention as will sustain a patent, even though the changes of the kind may produce better results than prior inventions.")â Regarding Claim 22. This is rejected under a similar rationale as claim 8 above, in view of Perezâs suggestion as discussed above in the section âDiscrete Event Simulationâ Regarding Claim 23. This is rejected under a similar rationale as claim 1 above. Regarding Claim 24. This is rejected under a similar rationale as claim 21 above. Regarding Claim 25. This is rejected under a similar rationale as claim 21 above. 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 DAVID A. HOPKINS whose telephone number is (571)272-0537. The examiner can normally be reached Monday to Friday, 10AM to 7 PM EST. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examinerâs supervisor, Ryan Pitaro can be reached at (571) 272-4071. 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. /David A Hopkins/Primary Examiner, Art Unit 2188