DETAILED ACTION
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 Sept. 5th, 2025 has been entered.
This action is in response to the amendments filed on Sept. 5th, 2025. A summary of this action:
Claims 1, 3-4, 6, 8, 12-17, 19, 21-25 have been presented for examination.
Claims 1 and 15 are objected to because of informalities
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-17, 19, 21-25 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, 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 in view of Shewchuk, John P., and T-C. Chang. "An approach to object-oriented discrete-event simulation of manufacturing systems." 1991 Winter Simulation Conference Proceedings.. IEEE Computer Society, 1991.
Claim(s) 8 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 in view of Shewchuk, John P., and T-C. Chang. "An approach to object-oriented discrete-event simulation of manufacturing systems." 1991 Winter Simulation Conference Proceedings.. IEEE Computer Society, 1991 in view of official notice
As a point of clarity, this was a minor typographical mistake – the prior rejection at pages 50-51 relied upon official notice explicitly, as noted by the bolded “Official Notice” statements, followed by the obviousness rationale, with nearly 2 pages discussion this in detail in the rejection so as to ensure the Applicant had due notice of the rejection’s rationale for purposes of responding, but the heading of the rejection was not updated to reflect this as a minor clerical mistake. It has been remedied.
Claim(s) 12-17, 19, and 21-24 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 and in further view of AGLIO, GIANLUCA, and FEDERICO FOLGHERAITER. "Real-time validation of discrete event simulation models in a real-time framework: statistical techniques and harmonic analysis approach." (2017) as taken in view of Grassmann, Winfried K. "Factors affecting warm-up periods in discrete event simulation." Simulation 90.1 (2014): 11-23.
This action is non-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 priority denial
Maintained. No remarks submitted.
Regarding the claim objections
Some withdrawn, some maintained, in view of the amendments. New objections below.
Regarding the § 112(b) Rejection
Maintained.
With respect to the remarks, the Examiner notes that that § 112(b) is a matter of law, wherein the claim is to set forth the metes and bounds of exactly what is claimed.
It is not a question of written description nor enablement under § 112(a), as these remarks imply.
Furthermore, this is not the variable of integration as alleged, rather it is part of the interval of integration, i.e. the range over which the function is to be integrated (e.g. if the function is y=mx for a straight line with an origin at 0, and the interval was from 0->5, then the integration would be the area under the curve y=mx+b for x = 0->5).
In other words, the interval of integration for claim 15 is from negative infinity to the sampling point X (note the capital).
But, at issue for claim 15 is that the variable “x” (lowercase) is entirely undefined, leaving the metes and bounds left to solely the speculation of POSITA.
To clarify for claim construction, MPEP § 2106.05(h): “iii. Limiting the use of the formula C = 2 (pi) r to determining the circumference of a wheel as opposed to other circular objects, because this limitation represents a mere token acquiescence to limiting the reach of the claim, Flook, 437 U.S. at 595, 198 USPQ at 199;” – i.e. the broad claim is C=2(pi)r, wherein C = circumference of a circle, r = radius of the circle, and pi is the well-known constant value.
The narrow claim: C=2(pi)r, wherein C = circumference of a wheel, r= radius of the wheel. The only distinction is in what the variables are defined in the claim as, but they do further limit the scope of such a claim to determining the circumference of a wheel instead of any circular objects.
At issue for claim 15 is that its entirely indefinite for this equation because it does not recite what “x” is at all, placing no limit that is definite per the requirements of § 112(b) – MPEP § 2171: “Two separate requirements are set forth in 35 U.S.C. 112(b) and pre-AIA 35 U.S.C. 112, second paragraph, namely that: (A) the claims must set forth the subject matter that the inventor or a joint inventor regards as the invention; and (B) the claims must particularly point out and distinctly define the metes and bounds of the subject matter to be protected by the patent grant. The first requirement is a subjective one because it is dependent on what the inventor or a joint inventor for a patent regards as his or her invention. Note that although pre-AIA 35 U.S.C. 112, second paragraph, uses the phrase "which applicant regards as his invention," pre-AIA 37 CFR 1.41(a) provides that a patent is applied for in the name or names of the actual inventor or inventors. The second requirement is an objective one because it is not dependent on the views of the inventor or any particular individual, but is evaluated in the context of whether the claim is definite — i.e., whether the scope of the claim is clear to a hypothetical person possessing the ordinary level of skill in the pertinent art. Although an essential purpose of the examination process is to determine whether or not the claims define an invention that is both novel and nonobvious over the prior art, another essential purpose of patent examination is to determine whether or not the claims are precise, clear, correct, and unambiguous. The uncertainties of claim scope should be removed, as much as possible, during the examination process”
Regarding the § 101 Rejection
Maintained, updated as necessitated by amendment.
With respect to the remarks, regarding Wikipedia at page 11, these remarks are entirely moot because arguments cannot take the place of evidence when evidence is required, and because neither the claims nor the disclose are directed towards an improvement in DES simulation technology - ¶ 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; MathWorks Simulation
Software available from MathWorks Inc., FlexSim available from FlexSim Software Products Inc., or so forth) onto the computer 120, and constructing a system model 132 of the system to be simulated in accord with the syntax and formatting of the chosen commercial simulation software package” – i.e. this is merely using commonplace, commercially available software in its ordinary capacity.
MPEP § 2145: “Rebuttal evidence and arguments can be presented in the specification, In re Soni, 54 F.3d 746, 750, 34 USPQ2d 1684, 1687 (Fed. Cir. 1995), by way of an affidavit or declaration under 37 CFR 1.132, e.g., Soni, 54 F.3d at 750, 34 USPQ2d at 1687; In re Piasecki, 745 F.2d 1468, 1474, 223 USPQ 785, 789-90 (Fed. Cir. 1984), or otherwise presented during prosecution. See, e.g., MPEP §§ 714 to 716 et seq. However, arguments presented by applicant cannot take the place of factually supported objective evidence. See, e.g., In re Schulze, 346 F.2d 600, 602, 145 USPQ 716, 718 (CCPA 1965); In re De Blauwe, 736 F.2d 699, 705, 222 USPQ 191, 196 (Fed. Cir. 1984).”
As a point of further clarity, the improvement consideration is not made in Sept. 2025 for this instant application, but rather on the date it was effectively filed (note the prior denial) of Jan. 2021, i.e. its arguments instead of evidence where evidence is required from the specification – MPEP § 2106.05(a): “That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. The specification need not explicitly set forth the improvement, but it must describe the invention such that the improvement would be apparent to one of ordinary skill in the art… Any such evidence submitted under 37 CFR 1.132 must establish what the specification would convey to one of ordinary skill in the art and cannot be used to supplement the specification. See, e.g. MPEP § 716.09 on 37 CFR 1.132 practice with respect to rejections under 35 U.S.C. 112(a). For example, in response to a rejection under 35 U.S.C. 101, an applicant could submit a declaration under § 1.132 providing testimony on how one of ordinary skill in the art would interpret the disclosed invention as improving technology and the underlying factual basis for that conclusion.” – and attorney argument is not the same as a 1.132 declaration.
Furthermore, these remarks do not even submit what the improvement to DES simulation is, but rather merely state that it’s an improvement, i.e. they are simply stating the conclusion for the improvement analysis, with no detail on what the improvement even is.
With respect to the remarks, starting at page 15, regarding ¶¶ 6-7 of the instant disclosure, first the Examiner notes these remarks solely point to claim 1, whereas the other independent lack numerous features of claim 1, and the remarks do not address the other claims (i.e. the rejections for the other independents are unargued), then see ¶¶ 48-51 as well, then see SAP v. InvestPic in MPEP § 2106.04(a)(I)(C): “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);” – to clarify, see the opinion of SAP: “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. The patent also describes using a "bias parameter" to "specif[y] the degree of randomness in the resampling process." Id ., col. 11, lines 55-58. In order to "perform a resampled statistical analysis," a client "may specify a number of parameters including an investment or investments (e.g., a portfolio) to be analyzed, a financial function, a sample size, a period, a type of plot and a bias parameter, which controls the randomness of the resampling process." Id ., col. 2, lines 50-56… We have already noted that limitation of the claims to a particular field of information—here, investment information—does not move the claims out of the realm of abstract ideas. Dependent method claims 2-5, 7, and 10 add "limitations . . . [that] require[] the resampling method to be a bootstrap method." SAP, 260 F. Supp. 3d at 715 . Likewise, "[c]laims 8 and 9 add limitations that the statistical method is a jackknife method and a cross validation method." Id. at 716 . Because bootstrap, jackknife, and cross-validation methods are all "particular methods of resampling," those features simply provide further narrowing of what are still mathematical operations. They add nothing outside the abstract realm... There is, in short, nothing "inventive" about any claim details, individually or in combination, that are not themselves in the realm of abstract ideas. In the absence of the required "inventive concept" in application, the claims here are legally equivalent to claims simply to the asserted advance in the realm of abstract ideas—an advance in mathematical techniques in finance. Under the principles developed in interpreting § 101 , patent law does not protect such claims, without more, no matter how groundbreaking the advance” – or, to summarize this, MPEP § 2106.05(I): “An inventive concept "cannot be furnished by the unpatentable law of nature (or natural phenomenon or abstract idea) itself." Genetic Techs. Ltd. v. Merial LLC, 818 F.3d 1369, 1376, 118 USPQ2d 1541, 1546 (Fed. Cir. 2016)… 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.”
To clarify, while these remarks recite several times the entire claim language as the improvement, see MPEP § 2106.05(a): “That is, the claim must include the components or steps of the invention that provide the improvement described in the specification. However, the claim itself does not need to explicitly recite the improvement described in the specification (e.g., "thereby increasing the bandwidth of the channel")” – which, for the alleged improvement would be: “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 parameter” – see SAP v. InvestPic opinion as noted above, for its discussion of “bootstrapping” as including steps of drawings samples from a “sample space” “with replacement” with some “degree of randomness in the resampling process”, wherein SAP stated this was a “math operation”, and MPEP § 2106.04(a)(2)(I)(C) lists it in “examples of math calculations” (note: “"performing" a mathematical operation may also be considered mathematical calculations when the broadest reasonable interpretation of the claim in light of the specification encompasses a mathematical calculation” in this section)).
Thus, as “An inventive concept "cannot be furnished by the unpatentable law of nature (or natural phenomenon or abstract idea) itself." Genetic Techs. Ltd. v. Merial LLC, 818 F.3d 1369, 1376, 118 USPQ2d 1541, 1546 (Fed. Cir. 2016).” (MPEP § 2106.05(I)) and MPEP § 2106.05(a): “It is important to note, the judicial exception alone cannot provide the improvement.” – what provides/furnishes the alleged improvement is the judicial exception alone, and Synopsys, Inc. v. Mentor Graphics Corp., 839 F.3d 1138, 1151, 120 USPQ2d 1473, 1483 (Fed. Cir. 2016) ("a new abstract idea is still an abstract idea") (MPEP § 2106.04(I)).
See the rejection below for further clarification.
Regarding the § 102/103 Rejection
Withdrawn, with a new grounds presented below as necessitated by amendment. Newly cited art is relied upon, and thus the features previously not rejected under § 102/103 are now rejected in view of the newly cited art.
Claim Objections
Claims 1 and 15 are objected to because of the following informalities:
Claim 15 recites “the sampling point X”, however as this is a first recitation the Examiner suggests using the articles “a”/”an”
Preamble of the claim 1 recite the acronym “DES”, but this acronym is only spelled out for what it is in the body of the claim. The Examiner suggests “discrete event simulation (DES)” in the preamble, and later recitation then may simple recite “DES”
Independent claim recite “wherein the event software modules of the plurality of event software modules comprise object-oriented programming (OOP) objects grouped into module groups, wherein the module groups have group-level class definitions and event software modules belonging to a module group inherit the group-level class definitions of the module group to which the event software modules belong” – this limitation adds another “event software modules” element, but does not disambiguate from the prior recitations. In view of the context of this limitation, the Examiner suggests the modifier “group”, i.e. “group event software models belonging to a modules group…”
Claim 1 recites “a first set of instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising:…” followed by a series of steps, and then recites: “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 at third set of 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:…” – such an ordering of series of steps is informal. See MPEP § 608.01(m): “Where a claim sets forth a plurality of elements or steps, each element or step of the claim should be separated by a line indentation, 37 CFR 1.75(i). There may be plural indentations to further segregate subcombinations or related steps. In general, the printed patent copies will follow the format used but printing difficulties or expense may prevent the duplication of unduly complex claim formats” – the Examiner suggests amending the claim to more clearly follow the formatting discussed in MPEP §608.01(m).
Claim 1 has an obvious typographical mistake – “at third set of instructions” with the article “at” instead of “a”
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 1 recites “a plurality of event software 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, wherein the event software modules of the plurality of event software modules comprise object-oriented programming (OOP) objects grouped into module groups, wherein the module groups have group-level class definitions and event software modules belonging to a module group inherit the group-level class definitions of the module group to which the event software 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– 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(1): "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-17, 19, 21-25 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, except where otherwise noted.
Step 2A – Prong 1
The claims recite an abstract idea of both a mental process and mathematical concept.
As a point of clarity, the focus of the claimed advance of this claimed invention is the statistical sampling strategy recited in the present claims, as discussed in detail below, as used with “Monte Carlo sampling” (¶¶ 58-61, in particular note ¶ 61), wherein the advance is the application of this technique as compared to the typical “Latin hypercube sampling” technique (¶¶ 48-50).
It claims no inventive concept in the performance of the DES simulation itself (¶ 63, describing a litany of commercially available software packages readily able to perform this act in their ordinary capacity).
As to the use of object-oriented programming (see claim 1, see MPEP §2111.01(III)) for DES simulations – this is not an inventive concept. POSITA would have known this, for it is well-known that object-oriented programming first language was specifically for DES simulation, i.e. the concept of object-oriented programming originated with DES simulation.
Wikipedia, article on Simula, URL: Wikipedia(dot)org/wiki/Simula, accessed electronically on Dec. 10th, 2025, which further clarifies on this, noting “Simula 67 introduced objects,[1]: 2, 5.3 classes,[1]: 1.3.3, 2 inheritance, subclasses[1]: 2.2.3 and an implementation of the polymorphism,[1]: 1.3.3 virtual procedures,[1]: 2.2.3 coroutines,[1]: 9.2 and discrete event simulation,[1]: 14.2 and featured garbage collection.[1]: 9.1 Other forms of subtyping (besides inheriting subclasses) were introduced in Simula derivatives. Simula is considered the first object-oriented programming language.” – in in the history section clarifies: “By May 1962, the main concepts for a simulation language were established; SIMULA I, a specialized programming language designed for simulating discrete event systems, was born. Simula 67 was formally standardized on the first meeting of the Simula Standards Group (SSG) in February 1968…”
To clarify – in the history section: “In November 2001, Dahl and Nygaard were awarded the IEEE John von Neumann Medal by the Institute of Electrical and Electronics Engineers "For the introduction of the concepts underlying object-oriented programming through the design and implementation of SIMULA 67". In April 2002, they received the 2001 A. M. Turing Award by the Association for Computing Machinery (ACM), with the citation: "For ideas fundamental to the emergence of object oriented programming, through their design of the programming languages Simula I and Simula 67." Dahl and Nygaard died in June and August of that year, respectively,[13] before the ACM Turing Award Lecture[14] that was scheduled to be delivered at the November 2002 OOPSLA conference in Seattle.”
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]…”
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 – see the section “Discrete Event Simulation”, including the last two paragraphs, which discusses that the very concept of object-oriented programming was “first…introduce[ed]” for simulation programming in the context of discrete event simulation in the languge “Simula”
Holmevik, “The History of Simula”, University of Chile, 1995, URL: users(dot)dcc(dot)uchile(dot)cl/~cgutierr/cursos/LP/SimulaHistory(dot)html – see ¶ 1, then in “PULLING THE THREADS TOGETHER” see ¶ 1: “Monte Carlo simulation had proved to be a serviceable tool for analysis of these modelsand when the Ferranti MERCURY was eventually installed at NDRE in late summer of 1957,Nygaard and his team immediately started to write computer simulation programs… In January 1962Nygaard wrote to his colleague, the French operations research specialist, Charles Salzmann: The status on the Simulation Language (Monte Carlo Compiler)…” - i.e. the inventor of Simula even also knew about Monte Carlo simulation
Nance, Richard E. "A history of discrete event simulation programming languages." History of programming languages---II. 1996. 369-427. § 8.1.1.1 ¶¶ 1-4: “Discrete event simulation utilizes a mathematicalnogical model of a physical system that portrays state changes at precise points in simulated time… Monte Carlo simulation, the name given by John von Neumann and Stanislaw M. Ulam [Morgenthaler 1961, p. 368] to reflect its gambling similarity, utilizes models of uncertainty where representation of time is unnecessary. The term is originally attributed to "a situation in which a difficult non probablistic problem is solved through the invention of a stochastic process that satisfies the relations of the deterministic problem" [Morgenthaler 1961 ]. A more recent characterization is that Monte Carlo is "the method of repetitive trials" [Shreider 1966, p.1 ]. Typical of Monte Carlo simulation is the approximation of a definite integral by 'circumscribing the region with a known geometric shape, then generating random points to estimate the area of the region through the proportion of points falling within the region boundaries…” and § 8.1.1.2: “The impact of the object-oriented paradigm, and the subsequent clamor over object-oriented programming languages, first represented by SIMULA, would appear in hindsight to contradict this opinion, which accurately represented the attitude of the programming language research community at that time…” and § 8.3.2, last paragraph: “The technical contributions of SIMULA are impressive, almost awesome. Dahl and Nygaard, in their attempt to create a language where objects in the real world could be accurately and naturally described, introduced conceptual advances that would be heralded as a paradigmatic shift almost two decades later. Almost lost in the clamor over the implementation of abstract data types, the class concept, inheritance, the coroutine concept, and quasi-parallel execution were the solution of significant problems in the extension of ALGOL 60. The creation, deletion, and set manipulation operations on objects are but one example. A second is that the sharing of attribute values by interacting processes required a means for breaking down the scoping restrictions of ALGOL 60.”
Pegden US 8,156,468 (note ¶ 63 in the instant disclosure for “FlexSim) for its background section, as discussed in Simio, LLC v. FlexSim Software Prods., Inc., 983 F.3d 1353 (Fed. Cir. 2020)
Nor is the inventive concept APIs for software, 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…”
Rather, the focus of the claimed advance lies sole in the sampling technique used, wherein it is recited as “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” – see “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…. Because bootstrap, jackknife, and cross-validation methods are all "particular methods of resampling," those features simply provide further narrowing of what are still mathematical operations. They add nothing outside the abstract realm. See Mayo, 566 U.S. at 88-89 (stating that narrow embodiments of ineligible matter, citing mathematical ideas as an example, are still ineligible); buySAFE, 765 F.3d at 1353 (same).”
In sum, the focus of the presently claimed advance is a “math operation[]”, which is a math calculation (SAP, as quoted above). MPEP §2106.04(a)(2)(I)(C): “That is, a claim does not have to recite the word "calculating" in order to be considered a mathematical calculation. For example, a step of "determining" a variable or number using mathematical methods or "performing" a mathematical operation may also be considered mathematical calculations when the broadest reasonable interpretation of the claim in light of the specification encompasses a mathematical calculation” – which is a math concept. MPEP § 2106.04(a)(2)(I): “The mathematical concepts grouping is defined as mathematical relationships, mathematical formulas or equations, and mathematical calculations” which is not eligible subject matter with an integration of the math concept into a practical application or amounting to significantly more.
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 at third set of 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, as discussed in detail below, the act of the random drawing with replacement in the manner recited is a math calculation/performing a math operation in textual form; and the running of the DES method is merely reciting textually statistical math calculations with PDFs, e.g. ¶ 47: “For a trucking fleet simulation as a non-limiting example, the prices of more expensive and less expensive grades of diesel can be represented by corresponding probability density functions (PDFs) capturing the expected pricing variation due to market forces (e.g., based on historical data for diesel pricing), and likewise the mean (and possibly variance) of the PDFs representing fuel efficiency of the respective grades of diesel can themselves be represented by PDFs (for example, based on variation in fuel efficiency amongst trucks in some test runs). Then, the models are re-run using the different sets of parameters a sufficient number of times to capture the statistical variation of the results due to the uncertainties in the pricing and fuel efficiency PDF mean parameters.” – and the Examiner notes that the claim requires the system model to be associated with said PDFs and parameters of said PDFs (further noting that PDFs are probability density functions, see Merriam Webster Dictionary, definition of “probability density function”, accessed electronically on Dec. 10th, 2025, URL: merriam-webster(dot)com/dictionary/probability%20density%20function “a function of a continuous random variable whose integral over an interval gives the probability that its value will fall within the interval”, i.e. math equations/relationships in textual form, and PDF mean is the result of mathematically calculating the mean of the distribution; see ¶ 63 to further clarify incl.: “Parameters defining random variables might, for example, include the mean and variance parameters of a Gaussian PDF of a random variable for the fuel economies of the trucks of the fleet.” – i.e. the claimed parameters of the PDFs are, under the BRI consistent with the disclosure, merely mathematical metrics resulting from math calculations with math equations/relationships of probability density functions; these are not parameters in a particular data structure)
To further 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.
perform a statistical analysis on the simulation results including computing a variance Var(E[YIX]) due to uncertainty in the values of the parameters, where X is the set of parameters of the system model, Y is the simulation results, and E stands for expectation. – math calculation in both textual form and with a math equation expressly recited in the claim. Also, “expectation” as recited herein is a math calculation/operation - ¶ 51 to clarify: “calculations (e.g. expectation or variance)” , wherein, per page 25, this is part of the “law of total variance” which is a law of the mathematics of statistics (for clarity, the Examiner does not consider this as a law of nature, rather its akin to other mathematical laws, e.g. the commutative, associate, and distributive laws/principles of algebra, e.g. (2*3)*3 = 3*3*2 for an example of the associative law of multiplication).
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/in a computer environment
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.” And the BRI (MPEP § 2111.01(III)) - 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, wherein a person is readily able to use a calculator to calculate the variance, or use a computer as a tool to do this.
To clarify, claims 12 and 19 taken together recite the law of total variance. See ¶ 71 of the instant disclosure, and in view of MPEP § 2111.01(III) also 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”
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 software 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, wherein the event software modules of the plurality of event software modules comprise object-oriented programming (OOP) objects grouped into module groups, wherein the module groups have group-level class definitions and event software modules belonging to a module group inherit the group-level class definitions of the module group to which the event software modules belong; application programming interfaces (APIs) defining flow of the members of the at least one population class amongst the event software modules;
and a first set of instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising:
… at increments of the time point, invoking one or more event software modules of the plurality of event software modules to process one or more members of the at least one population class in accord with flow of the members of the at least one population class amongst the one or more invoked event software modules of the plurality of event software 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.
… and a second set of instructions readable and executable by the electronic processor… and the non- transitory storage medium further stores at third set of instructions readable and executable by the electronic processor to
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:… wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor to implement…. wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor - - also, the data storage recitation is part of the mere instructions to use a computer as a tool
Claim 23 - A discrete event simulation (DES) system for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the DES system configured to perform a simulation method comprising:,… simulation results for each simulation are stored in the non-transitory storage medium… wherein the computer is further programmed to…
To clarify, the Examiner notes that the above are considered as part of the mere instructions to do it on a computer with commonplace existing software (e.g. ¶ 63), 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):
The data “storing…” steps are in the independents are mere data gathering, also see MPEP § 2106.05(a): “Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality: …vii. Providing historical usage information to users while they are inputting data, in order to improve the quality and organization of information added to a database, because "an improvement to the information stored by a database is not equivalent to an improvement in the database’s functionality," BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1287-88, 127 USPQ2d 1688, 1693-94 (Fed. Cir. 2018); and”
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).
The Examiner also notes that the use of OOP/object oriented program in the manner claimed is considered as an insignificant computer implementation for a similar rationale, as it is tangential to the primary process with the random drawing and performance of the simulation itself.
Claim 1 – a second set of 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.
Should the following limitation be considered not part of the abstract idea, but do it on a computer, then the Examiner notes it would be considered as mere instructions to “apply it” on a computer using commonplace, commercially available software (¶ 63 of the instant disclosure) as well as an insignificant application of the abstract idea, and furthermore as an insignificant computer implementation (MPEP § 2106.05(g).
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 software 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, wherein the event software modules of the plurality of event software modules comprise object-oriented programming (OOP) objects grouped into module groups, wherein the module groups have group-level class definitions and event software modules belonging to a module group inherit the group-level class definitions of the module group to which the event software modules belong; application programming interfaces (APIs) defining flow of the members of the at least one population class amongst the event software modules;
and a first set of instructions readable and executable by the electronic processor to perform a discrete event simulation (DES) method comprising:
… at increments of the time point, invoking one or more event software modules of the plurality of event software modules to process one or more members of the at least one population class in accord with flow of the members of the at least one population class amongst the one or more invoked event software modules of the plurality of event software 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.
… and a second set of instructions readable and executable by the electronic processor… and the non- transitory storage medium further stores at third set of instructions readable and executable by the electronic processor to
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:… wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor to implement…. wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor - - also, the data storage recitation is part of the mere instructions to use a computer as a tool
Claim 23 - A discrete event simulation (DES) system for simulating a system represented by a system model having parameters with associated probability density functions (PDFs), the DES system configured to perform a simulation method comprising:,… simulation results for each simulation are stored in the non-transitory storage medium… wherein the computer is further programmed to…
To clarify, the Examiner notes that the above are considered as part of the mere instructions to do it on a computer with commonplace existing software (e.g. ¶ 63), 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):
The data “storing…” steps are in the independents are mere data gathering, also see MPEP § 2106.05(a): “Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality: …vii. Providing historical usage information to users while they are inputting data, in order to improve the quality and organization of information added to a database, because "an improvement to the information stored by a database is not equivalent to an improvement in the database’s functionality," BSG Tech LLC v. Buyseasons, Inc., 899 F.3d 1281, 1287-88, 127 USPQ2d 1688, 1693-94 (Fed. Cir. 2018); and”
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).
The Examiner also notes that the use of OOP/object oriented program in the manner claimed is considered as an insignificant computer implementation for a similar rationale, as it is tangential to the primary process with the random drawing and performance of the simulation itself.
Claim 1 – a second set of 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.
Should the following limitation be considered not part of the abstract idea, but do it on a computer, then the Examiner notes it would be considered as mere instructions to “apply it” on a computer using commonplace, commercially available software (¶ 63 of the instant disclosure) as well as an insignificant application of the abstract idea, and furthermore as an insignificant computer implementation (MPEP § 2106.05(g), wherein this is WURC in view of ¶ 63, and the additional evidence as cited below.
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]…”
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 – see the section “Discrete Event Simulation”, including the last two paragraphs, which discusses that the very concept of object-oriented programming was “first…introduce[ed]” for simulation programming in the context of discrete event simulation in the languge “Simula”
See Wikipedia, article on Simula, URL: Wikipedia(dot)org/wiki/Simula, accessed electronically on Dec. 10th, 2025, which further clarifies on this, noting “Simula 67 introduced objects,[1]: 2, 5.3 classes,[1]: 1.3.3, 2 inheritance, subclasses[1]: 2.2.3 and an implementation of the polymorphism,[1]: 1.3.3 virtual procedures,[1]: 2.2.3 coroutines,[1]: 9.2 and discrete event simulation,[1]: 14.2 and featured garbage collection.[1]: 9.1 Other forms of subtyping (besides inheriting subclasses) were introduced in Simula derivatives. Simula is considered the first object-oriented programming language.” – in in the history section clarifies: “Simula 67 was formally standardized on the first meeting of the Simula Standards Group (SSG) in February 1968”
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 time point, invoking one or more event software modules of the plurality of event software modules to process one or more members of the at least one population class in accord with flow of the members of the at least one population class amongst the one or more invoked event software modules of the plurality of event software modules as defined by the APIs;- this is considered WURC in view of the above discussed evidence
Claim 1 - and a second set of 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;” – and the similar recitation in claim 23 is rejected under a similar rationale
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 (the Examiner noting a distinction in the generality of this drawing step and its use of a random number generator, i.e. example 38, when contrasted with the more particularly recited step in the independent claims, i.e. SAP v. InvestPic as discussed above) 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).
The Examiner further notes that in statistics the term “quartile” is commonly used to refer to the 25%, 50%, and 75%, i.e. the first quartile, the second quartile, and the third quartile – i.e. this is merely limiting the sampling space to a portion of the distribution such as the first quartile (the lower 25% of the PDF), which is merely further limiting the math concept in textual form with more math calculations of determining/calculating the percentile values, i.e. ¶ 65: “computed by solving Equation (2) for X with the value of the CDF set to the decimal value of the percentile” – and see equations 1-2
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 appears to be in the same form as 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”
As a point of distinction, to clarify on the § 112(b), note that the NIST equation has a “mu” and “dmu” [the “d\mu”] in it, integrating (the “int”) over the range of negative infinity to “x”, i.e. its integrating over the curve from (typically) 0-1, producing the chart shown
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.
Also, as this is a uniform distribution, the Examiner notes that an ideal coin would flip with a normal distribution, i.e. 50/50 chance of heads/tails each flip. Similar with an ideal die used in a dice roll, e.g. 1/6 (for a 6-sided die) chance of the die landing on one particular face each roll.
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 19 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
As a point of clarity, the equations recited in claims 12 and 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
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
In other words, its merely generally linking to large data sets/things having hundreds of parameters, instead of a much smaller amount.
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
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, 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 in view of Shewchuk, John P., and T-C. Chang. "An approach to object-oriented discrete-event simulation of manufacturing systems." 1991 Winter Simulation Conference Proceedings.. IEEE Computer Society, 1991.
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 software 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 the members of the at least one population class amongst the event software 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 a first set of 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 time point, invoking one or more event software modules of the plurality of event software modules to process one or more members of the at least one population class in accord with flow of the members of the at least one population class amongst the one or more invoked event software modules of the plurality of event software 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 a second set of 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 at third set of 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).
While Perez, in view of Saucier, does not explicitly teach the following, it would have been obvious in view of Shewchuk teaches:
wherein the event software modules of the plurality of event software modules comprise object-oriented programming (OOP) objects grouped into module groups wherein the module groups have group-level class definitions and event software modules belonging to a module group inherit the group-level class definitions of the module group to which the event software modules belong; (See Perez, as was discussed above for the event software modules
as taken in view of Shewchuk, abstract and § 1 ¶ 1 – then see § 1 last three paragraphs: “…The modelling task consists of defining data structures (arrays, files) and transforming the interaction of real-world objects to operations on data within these structures… Once suitable object class libraries have been developed, the modelling task becomes straightforward: the objective is simply to manipulate objects so as to emulate the manner in which the real-world objects interact… The goal of generality is addressed through the concept of inheritance, a mechanism by which existing objects can easily and systematically be modified to provide new objects. The object class library then provides the general facilities (object classes) required for simulation modelling: through inheritance, existing classes can be modified to create the "custom" objects required for various applications… Though object-oriented programming techniques can be used for developing event modelling, network modelling, or data-driven simulation software, the focus here is on the event orientation. This is because the event model is both the easiest to implement in object-oriented fashion and probably has the most to benefit from this approach” – see § 2 including fig. 1 to further clarify, then see § 4.2 including: “class calendar: used for creating an event calendar object. The event calendar maintains event time, event code, and an object pointer (address) for each event posted to the calendar… In a simulation program, a single object instance is required from classes timer, calendar, pLList, and rvGen. These objects are called Clock, EventCal, objectlist, and rvGenerator respectively….” And § 5: “…The simulation is driven by pulling events off the
calendar, advancing system time, and executing the events… For example, consider the task
of posting events to the event calendar. The usual approach is to post the attribute (i.e. dynamic) data representing the state of the system to the event calendar along with the event time and event code, a practice which encourages us to think in terms of data manipulation. In the object-oriented approach, only the identification (address) of the object upon which the event is based (e.g. machine for end-of-machine-service event) needs to be posted along with the event time and event code.”
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 with the teachings from Shewchuk on the use of OOP techniques in DES. The motivation to combine would have been that “Though object-oriented programming techniques can be used for developing event modelling, network modelling, or data-driven simulation software, the focus here is on the event orientation. This is because the event model is both the easiest to implement in object-oriented fashion and probably has the most to benefit from this approach” (Shewchuk, § 1 last paragraph).
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 the 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 3 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 software 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 25.
See 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.")”
Claim(s) 8 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 in view of Shewchuk, John P., and T-C. Chang. "An approach to object-oriented discrete-event simulation of manufacturing systems." 1991 Winter Simulation Conference Proceedings.. IEEE Computer Society, 1991 in view of official notice
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 event software modules includes one or more medical diagnosis modules belonging to a medical diagnosis module group, one or more medical surgery event software modules belonging to a medical surgery module group, and one or more medical insurance reimbursement event software 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 – wherein, as the official notice was not traversed in a timely manner (see the final rejection, wherein it was first taken), so see MPEP § 2144.03(C): “If applicant does not traverse the examiner’s assertion of official notice or applicant’s traverse is not adequate, the examiner should clearly indicate in the next Office action that the common knowledge or well-known in the art statement is taken to be admitted prior art because applicant either failed to traverse the examiner’s assertion of official notice or that the traverse was inadequate. See Ahlert, 424 F.2d at 1091, 165 USPQ at 420.”
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 – wherein, as the official notice was not traversed in a timely manner (see the final rejection, wherein it was first taken), so see MPEP § 2144.03(C): “If applicant does not traverse the examiner’s assertion of official notice or applicant’s traverse is not adequate, the examiner should clearly indicate in the next Office action that the common knowledge or well-known in the art statement is taken to be admitted prior art because applicant either failed to traverse the examiner’s assertion of official notice or that the traverse was inadequate. See Ahlert, 424 F.2d at 1091, 165 USPQ at 420.”
Claim(s) 12-17, 19, and 21-24 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 and in further view of AGLIO, GIANLUCA, and FEDERICO FOLGHERAITER. "Real-time validation of discrete event simulation models in a real-time framework: statistical techniques and harmonic analysis approach." (2017) as taken in view of Grassmann, Winfried K. "Factors affecting warm-up periods in discrete event simulation." Simulation 90.1 (2014): 11-23.
Regarding Claim 12.
This is rejected under a similar rationale as claim 1 above (except this claim lacks a feature not found in Perez, to which Shewchuk was relied upon, thus Shewchuk is not relied upon for this claim 12 as there is no express recitation of the feature that Shewchuk was relied upon for in claim 12), wherein the combination relied on does not explicitly teach the following feature, but this feature would have been obvious when the prior combination was taken in further view of Grassman:
wherein the non-transitory storage medium further stores instructions readable and executable by the electronic processor to perform a statistical analysis on the simulation results including computing a variance Var(E[YIX]) due to uncertainty in the values of the parameters, where X is the set of parameters of the system model, Y is the simulation results, and E stands for expectation. (Perez, as was taken in combination above, for the performance of the DES simulations in the manner recited above,
as take in further view of Grassman, abstract: “In this paper, we discuss the factors affecting the initialization bias in discrete event simulation…If starting in a typical state is inconvenient, warm-up periods should be used, and methods to find optimal warm-up periods are discussed…” and § 1 ¶ 1: “Discrete event simulation is probably the most effective way to find equilibrium expectations in complex stochastic systems. However, unless a discrete event simulation starts in a state that is chosen according to the equilibrium probabilities, an initialization bias results…To reduce the bias, one only collects data after a certain warm-up period of length τ. The question now arises as to what is a good value for τ, a question that has been addressed in many papers.” And page 12, ¶ 2: “In this paper, we find the optimal value of τ before starting the simulation, and the symbol τ * is reserved for this case.”
Then see § 2 including: “Our observation is that the initializations with the lowest MSE(R(T)) are deterministic. There are theoretical arguments for this. For this purpose, let Biasi(R(T)), Vari(R(T)) and MSEi(R(T)) be the bias, the variance and the MSE of R
(T), given the starting state is i. As is well known from statistics, the MSE can be split into a bias part and a variance part as follows (see, e.g., Pawlikowski3)..” (page 12 last paragraph), then see page 13 ¶¶ 1-2, including in particular equations 2-6, and noting “This follows immediately
from the law of total variance (see, e.g., Parsen30), which for our case takes the following form, Var(R(T)) is the variance obtained by selecting state i with probability pi as starting state, and E(R(T)) is the corresponding expectation…” – then, see page 13 last paragraph, incl.: “In order to find out how an increase of τ affects the bias, the variance and the MSE, we calculate the derivative of Bias(R(τ, T)), Var(R(τ, T)) and MSE(R(τ, T)) with respect to τ. We denote these derivatives by Bias0(R(τ, T)), Var0(R(τ, T)) and MSE0(R(τ, T)). To decide whether or not to increase τ from 0 to some positive value, we set τ =0 and obtain for any deterministic initialization, where E(R(0))=R(0):…”
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 the DES simulation system of Perez, as was taken in combination, as discussed above, with the teachings from Grassman on choosing a value of a warm-up period in DES simulation (Grassman, abstract and § 1 as cited above) The motivation to combine would have been that § 8 of Grassman: “…Although better decisions are possible if sample functions are used, we still obtained a number of important results. In particular, we showed that for well-selected starting states, no warm-up period should be used if the objective is to minimize the MSE of the time average. In some cases, finding good starting states is costly or inconvenient, and in this case, warm-up periods are often necessary. In general, the warm-up period should be increased if the variance of the time average increases when compared with the square of the bias of the time average…”.
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 of 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 19
Rejected in view of Grassman as cited to and relied upon above. To clarify, these two claims together merely express calculating the law of total variance, and Grassman teaches a series of calculations of DEM simulation results “from the law of total variance” as noted above and clarified on, i.e. Grassman is within the scope of this claim.
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 12 above.
Regarding Claim 24.
This is rejected under a similar rationale as claim 21 above.
Conclusion
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
Prosecution Insights