DETAILED ACTION
This action is in response to the submission filed on 2/24/2023. Claims 1-17 are presented for examination.
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 .
Drawings
The drawings are objected to because Figures 1-8 contain text which is blurry and difficult to read. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Applicant is directed towards 37 CFR § 1.84 - Standards for drawings:
(3) Numbers, letters, and reference characters must measure at least .32 cm. ( 1/8 inch) in height. They should not be placed in the drawing so as to interfere with its comprehension. Therefore, they should not cross or mingle with the lines. They should not be placed upon hatched or shaded surfaces. When necessary, such as indicating a surface or cross section, a reference character may be underlined and a blank space may be left in the hatching or shading where the character occurs so that it appears distinct.
Claim Rejections - 35 USC § 112
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.
Claims 1-17 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.
Claims 1, 9, 13 and 17 recite the phrase “substantially simultaneously”. The term “substantially” in claims 1, 9, 13 and 17 is a relative term which renders the claim indefinite. The term “substantially” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention.
Claims 1, 13 and 17 recite “the transmission of state data by the requesting entity” and “the transmission of state data by an entity that has previously joined the simulation”.
First, “the transmission” lacks antecedent support. Second, it is unclear where the state data of either entities is being transmitted to. It is unknown if the state date of the requesting entity is being transmitted to entities inside of the simulation or elsewhere. Similarly, it is unclear where the state data of the entity that has previously joined the simulation is being transmitted to, such as to entities inside or outside of the simulation or elsewhere.
Claims 2-12 and 14-16 are rejected by virtue of their dependency.
Any application of prior art is the Examiner’s best interpretation of the claimed subject matter.
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.
Claims 1-6, 8-10, 12-14, and 16-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “A Distributed Architecture for Multiplayer Interactive Applications on the Internet” (“Diot”).
Regarding claims 1 and 17, Diot teaches:
A computer-implemented method for development and testing of multi-component systems and/or interacting components thereof via simulation, wherein the simulation comprises at least two entities exchanging state data with one another (Diot: Abstract; page 7, “DIS (distributed interactive simulation)”), and wherein the method comprises:
an entity requesting to join a simulation (Diot: page 7, “Participants can join and leave a MiMaze session dynamically.”); and the requesting entity joining the simulation in such a way that the transmission of state data by the requesting entity takes place substantially simultaneously with the transmission of state data by an entity that has previously joined the simulation (Diot: page 7, “DIS (distributed interactive simulation): An IEEE standard (see references [6, 71) that describes the format of the packets that should be exchanged between simulation entities in a distributed simulation, and that defines the protocol to handle these packets”).
Regarding claim 2, Diot teaches::
The method according to claim 1, wherein the requesting entity joins the simulation in such a way that the time at which the requesting entity transmits its state data for the first time after receiving permission to join is delayed by a first delay interval (Diot: Figure 3, t0, t1, tb, “transmission delay”, “Playout delay”, “Synchronization delay”).
Regarding claim 3, Diot teaches:
The method according to claim 1, wherein the requesting entity joins the simulation in such a way that the time at which the state data are transmitted to an entity that has already joined the simulation is delayed by a second delay interval (Diot: Figure 3, t0, t1, tb, “transmission delay”, “Playout delay”, “Synchronization delay”).
Regarding claim 4, Diot teaches:
The method according to claim 1, wherein the first transmission of the state data of an entity after receiving permission to join takes place at the beginning of a predefined, constant time interval for the transmission of state data (Diot: Figure 3, t0, t1, tb, “transmission delay”, “Playout delay”, “Synchronization delay”; page 9, “In MiMaze time is divided into fixed length periods, and a bucket is associated with each period. All ADUs received by a player that were issued by senders during a given period are stored by the receiver in the bucket corresponding to that interval. At the end of every bucket interval, all PDUs in that bucket are used by the entity to compute its local view of the global state. Buckets are computed 100 ms after the end of the sampling peri- od during which ADUs have been issued (100 ms is the playout delay4). In other words, to compute a new global state, an entity computes all the ADUs available in the “current” bucket.”).
Regarding claim 5, Diot teaches:
The method according to claim 4, wherein subsequent transmissions of the state data take place at time intervals which respectively correspond to this predefined, constant time interval for the transmission of state data (Diot: page 9, “In MiMaze time is divided into fixed length periods, and a bucket is associated with each period. All ADUs received by a player that were issued by senders during a given period are stored by the receiver in the bucket corresponding to that interval. At the end of every bucket interval, all PDUs in that bucket are used by the entity to compute its local view of the global state. Buckets are computed 100 ms after the end of the sampling peri- od during which ADUs have been issued (100 ms is the playout delay4). In other words, to compute a new global state, an entity computes all the ADUs available in the “current” bucket.”).
Regarding claim 6, Diot teaches:
The method according to claim 1, wherein an entity calculates one or more steps of the simulation locally between a first and a subsequent second transmission of state data; and wherein: the entity performs the local calculation via such state data (Diot: Figure 3; page 9, “All ADUs issued at the same time (by various game entities) are computed together to evaluate the state of the game. All session entities display to their own player the same game state simultaneously. In MiMaze time is divided into fixed length periods, and a bucket is associated with each period. All ADUs received by a player that were issued by senders during a given period are stored by the receiver in the bucket corresponding to that interval. At the end of every bucket interval, all PDUs in that bucket are used by the entity to compute its local view of the global state. Buckets are computed 100 ms after the end of the sampling peri- od during which ADUs have been issued (100 ms is the playout delay4). In other words, to compute a new global state, an entity computes all the ADUs available in the “current” bucket.”) and/or extrapolation of such state data of another entity that the entity has received as a result of the first transmission of state data, and/or the local calculation comprises a predefined number of steps, and the local calculation of a step takes place within a predefined, constant time interval and/or corresponds to a predefined, constant time interval in the simulated test environment.
Regarding claim 8, Diot teaches:
The method according to claim 1, wherein receiving permission to join the simulation causes the requesting entity to transmit its state data for the first time after receiving permission to join (Diot: Fig. 3, “Player X entity (where the state is computed)”, “Remote player Y entity”, “transmission delay”, “Playout delay”, “Synchronization delay” ).
Regarding claim 9, Diot teaches:
The method according to claim 1, wherein a transmission time is determined for an entity, at which time the entity is to transmit state data for the first time after receiving permission to join the simulation, and the transmission time is determined in such a way that the transmission of the state data takes place substantially simultaneously with the transmission of the state data by another entity (Diot: Fig. 3, “Player X entity (where the state is computed)”, “Remote player Y entity”, “transmission delay”, “Playout delay”, “Synchronization delay” ).
Regarding claim 10, Diot teaches:
The method according to claim 9, wherein the transmission time is determined as a function of a predefined, constant time interval for transmitting state data (Diot: Figure 3; page 9, “All ADUs issued at the same time (by various game entities) are computed together to evaluate the state of the game. All session entities display to their own player the same game state simultaneously. In MiMaze time is divided into fixed length periods, and a bucket is associated with each period. All ADUs received by a player that were issued by senders during a given period are stored by the receiver in the bucket corresponding to that interval. At the end of every bucket interval, all PDUs in that bucket are used by the entity to compute its local view of the global state. Buckets are computed 100 ms after the end of the sampling peri- od during which ADUs have been issued (100 ms is the playout delay4). In other words, to compute a new global state, an entity computes all the ADUs available in the “current” bucket”) and/or of a signal propagation time for transmitting state data.
Regarding claim 12, Diot teaches:
The method according to claim 1, wherein an entity is run on a personal computer (PC), a test bed, a server, and/or in a cloud, and/or exchanges a request to join a simulation, permission to join a simulation, and/or state data with another entity via a heterogeneous, Internet-like network infrastructure (Diot: page 8, “With a server architecture, the amount of data transferred on the network is in the best case equal to the amount of data transferred with a distributed architecture. It is high- er when multicast is not used, or when TCP is used to collect data. Minimum delays. In a centralized architecture, information reaches its destination through the server. Depending on net- work topology and the routing tree structure, this can increase the network delay up to two times the delays in a distributed architecture. In a distributed architecture, information crosses the network only once to reach its final destinations”; Figure 4. “MBone architecture during the evaluation. Network delays are the averages measured from droopy (located at INRlA Sophia Antipolis). All locations are in France”).
Regarding claim 13, Diot teaches:
A simulation system for development and testing of multi-component systems and/or interacting components thereof via simulation, wherein the simulation comprises at least two entities exchanging state data with one another (Diot: Abstract; page 7, “DIS (distributed interactive simulation)”), and the simulation system comprises:
at least two simulation devices interacting with one another (Diot: Figure 2, “MiMaze communication architecture showing the session management server used by participant when joining a session, and the fully distributed communication once the ,game has started”; Figure 4);
wherein the at least two simulation devices are configured to:
make requests by an entity to join the simulation (Diot: page 7, “Participants can join and leave a MiMaze session dynamically”); and
allow the requesting entity to join the simulation in such a way that the transmission of state data by the requesting entity takes place substantially simultaneously with the transmission of state data by an entity that has previously joined the simulation (Diot: page 7, “DIS (distributed interactive simulation): An IEEE standard (see references [6, 71) that describes the format of the packets that should be exchanged between simulation entities in a distributed simulation, and that defines the protocol to handle these packets”).
Regarding claim 14, Diot teaches:
The simulation system according to claim 13, wherein the at least two simulation devices interacting with one another are further configured to allow the requesting entity to join the simulation in such a way that the time at which the requesting entity transmits its state data for the first time after receiving permission to join the simulation is delayed by a first delay interval (Diot: Fig. 3, “Player X entity (where the state is computed)”, “Remote player Y entity”, “transmission delay”, “Playout delay”, “Synchronization delay” ), and/or the time at which the state data are transmitted to an entity that has already joined the simulation is delayed by a second delay interval.
Regarding claim 16, Diot teaches:
The simulation system according to claim 13, wherein the at least two simulation devices are personal computer (PC)-based, test bed-based, server-based, and/or cloud-based, and are communicatively connected via a heterogeneous, Internet-like network infrastructure (Diot: page 8, “With a server architecture, the amount of data transferred on the network is in the best case equal to the amount of data transferred with a distributed architecture. It is high- er when multicast is not used, or when TCP is used to collect data. Minimum delays. In a centralized architecture, information reaches its destination through the server. Depending on net- work topology and the routing tree structure, this can increase the network delay up to two times the delays in a distributed architecture. In a distributed architecture, information crosses the network only once to reach its final destinations”; Figure 4. “MBone architecture during the evaluation. Network delays are the averages measured from droopy (located at INRlA Sophia Antipolis). All locations are in France”).
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 11 is rejected under 35 U.S.C. 103 as being unpatentable over “A Distributed Architecture for Multiplayer Interactive Applications on the Internet” (“Diot”) in view of “Distributed Co-Simulation Framework for Hardware- and Software-In-The-Loop Testing of Networked Embedded Real-Time System” (“Pieper”).
Regarding claim 11, Diot does not teach but Pieper does teach:
The method according to claim 1, wherein at least one entity comprises a component of a vehicle, an aircraft, and/or an automation present as a model-in-the-loop (MIL), software-in-the-loop (SIL), and/or hardware-in-the-loop (HIL), and the entity influences a behavior of a virtual model of the vehicle, the aircraft, and/or the automation via the component during the simulation (Pieper: 3.3. Software- and Hardware-In-The-Loop Testing, “SIL and HIL testing for the development of chassis control systems. They implement a model of the vehicle dynamics in Matlab/Simulink/Stateflow and couple it with control algorithms or the production module”).
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined Diot (directed to simulation joining) and Pieper (directed to SIL and HIL testing) and arrived at joining a simulation using SIL and HIL testing. One of ordinary skill in the art would have been motivated to make such a combination “a distributed co-simulation framework which operates on a network centric abstraction level...It synchronizes the components of the SUT, coordinates their data exchange and includes fault-injection to validate the dependability” (Pieper: Abstract).
Allowable Subject Matter
Claims 7 and 15 contain allowable subject matter.
The claims will be allowable if the rejections under 35 USC 112 are overcome.
The independent claims will be in condition for allowance when the allowable dependent claims are incorporated into the independent claims, in addition to overcoming the 112 rejections.
The closest prior art of record, Diot and Pieper, joining a simulation using SIL and HIL testing. However, these references and the remaining prior art of record, alone or in combination, fails to disclose or suggest
(claim 7 )
“a coordination entity receiving the state data from at least two entities; and
the coordination entity transmitting the received state data as combined state data to the at least two entities;
wherein the combined state data are transmitted at a time after the state data of the at least two entities have been received, processed, and/or supplemented by the coordination entity;
and wherein the combined state data transmitted to a respective entity at least contains such state data that are necessary for the local performance of the simulation by the respective entity”,
(claim 15)
“wherein the at least two simulation devices interacting with one another are further configured to exchange state data between at least two entities such that a coordination entity receives state data from at least two entities and transmits the received state data as combined state data to the at least two entities at a time after the state data of the at least two entities have been received, processed, and/or supplemented by the coordination entity”,
in combination with the remaining elements and features of the claimed invention. It is for these reasons that the applicant’s invention defines over the prior art of record.
Additional References Cited
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and are cited in the attached PTOL-892.
“Geographically distributed real-time co-simulation of electric vehicle” (“Alfonso”): a distributed real-time co-simulation environment merging simulation models and testing facilities for developing and verifying electric vehicles. This environment has been developed in the framework of the XILforEV project and the presented case is focused on a ride control with a real suspension installed on a test bench in Spain, which uses real-time information from a complete vehicle model in Germany.
“Closed-loop platoon simulation with cooperative intelligent transportation systems based on vehicle-to-X communication” (“Meyer”): a method for virtual testing and calibration of in-vehicle C-ITS using a high fidelity vehicle platoon model is presented. Multiple closed-loop controlled vehicles and the mutual interferences between them are simulated in a common 3D environment alongside other traffic. Each high fidelity vehicle model individually simulates the longitudinal and lateral response, the generation of sensor data plus the exchange of vehicle-to-vehicle data. As a proof of concept, a model-in-the-loop simulation for a Cooperative Adaptive Cruise Control (CACC) was conducted. The simulation environment included five high fidelity vehicle models forming a platoon, coupled with CACC controller models under test.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NITHYA J. MOLL whose telephone number is (571)270-1003. The examiner can normally be reached Monday-Friday 10am-6pm 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, Rehana Perveen can be reached at 571-272-3676. 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.
/NITHYA J. MOLL/Primary Examiner, Art Unit 2189
Prosecution Insights