DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claims 14-16 are objected to because of the following informalities: claims 14-16 all depend from claim 15. However, this appears to be a typo as claim 14 should depend from claim 13, claim 15 should depend from claim 13, and claims 16 should depend from claim 1, similar to the dependencies of claims 30-32.
Appropriate correction is required.
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-32 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-32 is/are directed towards a statutory category they are directed to either a process, machine, manufacture, or composition of matter (Step 1, Yes).
Claim 1 recites, in part, the limitations of […] and i. receive by […] an outcome request […]; ii. process the outcome request to determine if the outcome request is valid or not valid; and iii. […]. These limitations, individually and in combination, describe or set forth the abstract idea in claim 1 (substantially similar to claim 17). The Examiner notes that the specific limitations that describe or set forth the abstract idea in Step 2A Prong 1 can be identified either individually or in combination (see p. 54 of 2019 Revised Patent Subject Matter Eligibility Guidance).
Under the broadest reasonable interpretation, the claims recite limitations that can be practically performed in the human mind or by a human using pen and paper. The Examiner notes that “[c]laims can recite a mental process even if they are claimed as being performed on a computer,” and that “courts have found requiring a generic computer or nominally reciting a generic computer may still recite a mental process even though the claim limitations are not performed entirely in the human mind” (see p. 8 of the October 2019 Update: Subject Matter Eligibility). The Examiner also notes that “both product claims (e.g., computer system, computer-readable medium, etc.) and process claims may recite mental processes” (see p. 8 of the October 2019 Update: Subject Matter Eligibility). The mere nominal recitation of the additional elements identified below do not take the claims out of the mental process grouping. Thus, the claims recite a mental process.
The claims also recite limitations that are considered a fundamental economic principle or practice (e.g., relating to commerce and economy), commercial interactions, business relations, managing personal behavior or relationships or interactions between people. The Examiner notes that certain activity between a person and a computer may fall within the certain methods of organizing human activity grouping (see p. 5 of the October 2019 Update: Subject Matter Eligibility).
Therefore, the claims fall under the following enumerated groupings of abstract ideas: mental processes (e.g., concepts performed in the human mind (including an observation, evaluation, judgment, or opinion)), and/or certain methods of organizing human activity (e.g., fundamental economic principles or practices (including hedging, insurance, mitigating risk), commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; business relations), or managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)) (Step 2A, Prong 1, Yes).
Claim 1 recites the additional elements of “one or more driving simulator pods”, “a simulated driver cockpit, comprising: simulated vehicle controls; one or more displays”, “a driving simulator pod computer”, “a session server”, “an outcome engine”, “an operations user interface”, “a plurality of data stores”, “one or more processors”, and “a non-transitory computer-readable medium”. These additional elements, when considered individually or in combination, are not integrated into a practical application because they are all recited at a high level of generality and are merely used as tools to implement or perform the steps of the abstract idea. The additional elements when considered alone and in combination amount to no more than using generic computing components to apply the judicial exception. The recitations “implement the outcome request if valid” is insignificant extra-solution activity i.e., data gathering and/or data output. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application (Step 2A Prong 2, No). Thus, the claim is directed to an abstract idea.
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed with respect to Step 2A - Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using generic computer components and the insignificant extra-solution activity of implementing a valid outcome request is no more than data gathering and/or data output. The same analysis applies here in step 2B and does not provide an inventive concept (Step 2B, No).
The dependent claims fail to add “significantly more” because they merely represent further use of generic computers for routine data-processing functions related to steps/rules for generating modified game content based on user interaction with content in another game (Claims 2-16 and 18-32).
For these reasons, there is no inventive concept. The claims are not patent eligible. Even when viewed as a whole, nothing in the claims add significantly more to the abstract idea.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-9, 11-25, and 27-32 is/are rejected under 35 U.S.C. 102(a)(1)/102(a)(2) as being anticipated by Deakins et al. (US 2018/0366022 A1) (henceforth, “Deakins”).
Regarding claims 1 and 17, Deakins teaches A driving simulation system and method, comprising:
a. one or more driving simulator pods, the one or more driving simulator pods comprising: a simulated driver cockpit, comprising: simulated vehicle controls; one or more displays providing a simulated driving environment to a driver of the one or more driving simulator pods, and a driving simulator pod computer; b. a session server; c. an outcome engine; d. an operations user interface; e. a plurality of data stores; f. one or more processors (figs. 1 and 6-8); and
g. a non-transitory computer-readable medium storing thereon instructions that, when executed by the one or more processors, cause the system to: i. receive by the outcome engine an outcome request associated with at least one of the one or more driving simulator pods (e.g., determining to have met milestone in Step 208 of Fig. 3); ii. process the outcome request to determine if the outcome request is valid or not valid (e.g., successfully meet criteria, Step 210 of Fig. 3); and iii. implement the outcome request if valid (e.g., green status assigned in Step 212).
Regarding claims 2 and 18, Deakins teaches if the outcome request is determined to be valid, determining whether the outcome request is or is not impactful to a driver associated with the driving simulator pod associated with the outcome request, and if determined to be impactful, requiring confirmation of the outcome request prior to implementing the outcome request (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 3 and 19, Deakins teaches the outcome engine generating a state graph of all states that the driving simulator pod associated with the outcome request can be in, wherein the outcome engine queries a state data store of one of the plurality of data stores for all state information of the driving simulator pod associated with the outcome request (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 4 and 20, Deakins teaches the outcome engine generating a plan for implementing the outcome request based on the state graph and state information, wherein the outcome engine analyzes all available paths of the state graph and generates the plan taking the least amount of time and/or steps (Fig. 3).
Regarding claims 5 and 21, Deakins teaches executing the generated plan, comprising: a. completing a first step of the generated plan; and b. determining if the outcome request is achieved (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 6 and 22, Deakins teaches recording a state change of the driving simulator pod associated with the outcome request after completing the first step of the generated plan in the state data store (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2 and central server in Para. 62).
Regarding claims 7 and 23, Deakins teaches if it is determined that the outcome request is not achieved, then the system further comprises: a. the outcome engine generating a new state graph of the driving simulator pod associated with the outcome request; b. generating a new plan based on the new state graph and state information; c. completing a first step of the generated new plan; d. determining if the outcome request is achieved; and wherein if it is determined the outcome request is not achieved repeating 7(a)-7(d), until the outcome request is achieved (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 8 and 24, Deakins teaches recording a state change of the driving simulator pod associated with the outcome request after completing the first step of each new generated plan in the state data store (e.g., simulations in a central server or remote server in Para. 59 and Para. 62).
Regarding claims 9 and 25, Deakins teaches the outcome request is input via the operations user interface (Fig. 6).
Regarding claims 11 and 27, Deakins teaches a driver web portal comprising a web based portal wherein a driver of one or more of the driving simulator pods of the driving simulation system can access the driving simulation system and interact with a simulation center, their account, and/or their driver data (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2 and central server in Para. 62).
Regarding claims 12 and 28, Deakins teaches the plurality of data stores comprises one or more of a driver data store, a state data store, a static data store, and/or a simulation center data store (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 13 and 29, Deakins teaches validating the outcome request comprises: a. determining if a state change of the outcome request is impactful to the driver of the one or more driving simulator pods associated with the outcome request; b. if it is determined that the state change of the outcome request is impactful to the driver, generating a state graph by the outcome engine; c. based on the state graph, determining by the outcome engine if there is a valid plan to implement the state change of the outcome request; and d. if it is determined there is a valid plan, marking the outcome request as validated and return the plan for confirmation and implementation (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 14 and 30, Deakins teaches wherein if it is determined by the outcome engine that there is not a valid plan then marking the outcome request as not validated and returning a reason for the failed validation for confirmation (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 15 and 31, Deakins teaches wherein if it is determined that the state change of the outcome request is not impactful to the driver then marking the outcome request as validated and return plan for confirmation and implementation (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Regarding claims 16 and 32, Deakins teaches wherein a first outcome request can be linked to a second outcome request by a trigger event, wherein upon the occurrence of the trigger event the second outcome request is implemented (e.g., steps in fig. 3, including, meeting the milestone task, yes, partially, no in step 210, displaying results in step 220 and Fig. 2).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 10 and 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Deakins in view of Tulewicz et al. (US 2021/0291061 A1) (henceforth, “Tulewicz”).
Regarding claims 10 and 26, Deakins fails to explicitly teach a spectator module and a spectator display, wherein the spectator module is programmed to drive the spectator display to allow a broadcast of a simulated event or race of one or more driving simulator pods of the driving simulation system, wherein the spectator display is remote of the one or more driving simulator pods.
However, in a related disclosure, Tulewicz teaches players may stream video output from the video game to respective groups of spectators (see abstract). More particularly, Tulewicz teaches a video streaming service, wherein, the video streaming service 120, in turn, provides respective game video streams 115A and 115B to respective spectator groups 130A and 130B (i.e., a spectator module in Para. 25 and Fig. 1). Tulewicz states “creates a more realistic experience, for example as compared to inserting a static (i.e., non-changing) image into the character's face” (Para. 19). As such, it would have been obvious to one of ordinary skill in the art before the effective date of the invention to modify the driving simulator of Deakins to include the streaming service features of Tulewicz in order to provide a more enjoyable user experience, as beneficially taught by Tulewicz.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure and is listed on the attached Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHASE E LEICHLITER whose telephone number is (571)270-7109. The examiner can normally be reached Monday-Friday (9-5).
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, David Lewis can be reached at (571)272-7673. 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.
/CHASE E LEICHLITER/Primary Examiner, Art Unit 3715