DETAILED ACTION
Claims 1-11 are currently 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 .
Claim Objections
Claim 1 is objected to because of the following informalities: the claim recites “the values” when the previous recitation is “current value”. Appropriate correction is required.
Claim 1 is objected to because of the following informalities: the claim recites “the simulation time” when it is the first recitation. Appropriate correction is required.
Claim 2 is objected to because of the following informalities: the claim recites “a pause command” when it is not the first recitation. Appropriate correction is required.
Claim 2 is objected to because of the following informalities: the claim recites “a specific simulation time” when it is not the first recitation. Appropriate correction is required.
Claim 5 is objected to because of the following informalities: the claim recites “a current value” multiple times when it is not the first recitation. Appropriate correction is required.
Claim 5 is objected to because of the following informalities: the claim recites “a pause command” when it is not the first recitation. Appropriate correction is required.
Claim 5 is objected to because of the following informalities: the claim recites “a specific simulation time” when it is not the first recitation. Appropriate correction is required.
Claim 6 is objected to because of the following informalities: the claim recites “a pause command” when it is not the first recitation. Appropriate correction is required.
Claim 6 is objected to because of the following informalities: the claim recites “a specific simulation time” when it is not the first recitation. Appropriate correction is required.
Claim 6 is objected to because of the following informalities: the claim recites “a new value” when it is not the first recitation. Appropriate correction is required.
Claim 7 objected to because of the following informalities: the claim recites “signal values” when the previous recitation is “the sets of signal values”. Appropriate correction is required.
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.
Claims 1-5 and 9-11 are rejected under 35 U.S.C. 103 as being unpatentable over Luenstroth et al USPPN 2018/0039566, in view of Yunt et al USPAT 8,131,523.
Regarding claim 1, Luenstroth teaches A method for simulating a program, the program being modeled as a plurality of blocks in a block diagram, (Abstract, [0009], the computer program models the plurality of bocks in the block diagram)
the block diagram comprising at least one signal emitted by one of the blocks and at least one parameter that influences a value of the signal, (Abstract, [0013], [0018], [0024], the inputs and outputs are monitored and influenced by the blocks that contain variables used to calculate output variables)
the block diagram being executed in a technical computing environment, ([0009], the block diagram is executed in the technical computing environment)
the technical computing environment comprising a model editor and a simulation environment, the method being executed by at least one processor of a host computer, the method comprising: ([0009], [0018], the TCE contains Matlab/Simulink which are a model editor and simulation environment run on a host computer)
opening the block diagram in the model editor; ([0011], [0015], [0018]-[0019], the simulation is opened and run in the model editor to see exchanged signals)
simulating the block diagram for a first time span in the simulation environment, comprising periodically executing at least some of the blocks and periodically logging a current value of the signal; ([0011], [0015], [0018]-[0019], the simulation is opened and run in the model editor to see exchanged signals; [0015], [0052], all values are logged)
displaying the values of the signal as a function of the simulation time;([0015], [0052], all values are also displayed; [0050], [0059]-[0060], the signals are displayed with the current timestep and simulation time)
receiving a new value for the at least one parameter; ([0047]-[0048], [0060], [0067], signals are modified and new outputs are calculated)
simulating the block diagram for a second time span in the simulation environment, comprising periodically executing at least some of the blocks and periodically logging a current value of the signal; and ([0010], [0017]-[0019],a second compiler is used to run the simulation again)
displaying both the values of the signal from the first time span and the values of the signal from the second time span, wherein the values from the second time span are displayed graphically different from those of the first time span. ;([0015], [0018], [0052], all values are also displayed; [0050], [0059]-[0060], the signals are displayed with the current timestep and simulation time)
Luenstroth does not explicitly teach receiving a pause command at a specific simulation time;
Yunt teaches receiving a pause command at a specific simulation time; (Column 37 Lines 10-17, a pause command pauses the debugger at a specific time)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Luenstroth with Yunt as the references deal with block diagram simulation, in order to implement a system that is configured for using a pause command to step back in simulation time with timespans that overlap, at different timesteps that can be repeated. Yunt would modify Luenstroth by using a pause command to step back in simulation time with timespans that overlap, at different timesteps that can be repeated. The benefit of doing so is the users can follow the block diagram at a pace of their choice and the system can check for changes in delay time before the method is executed. (Yunt Column 37 Lines 10-17)
Regarding claim 2, the combination of Luenstroth and Yunt teach the limitations of claim 1. Luenstroth does not explicitly recite wherein receiving a pause command at a specific simulation time further comprises stepping back from the specific simulation time, so that the first time span and the second time span overlap at least partially.
Yunt teaches wherein receiving a pause command at a specific simulation time further comprises stepping back from the specific simulation time, so that the first time span and the second time span overlap at least partially. (Column 37 Lines 10-17, Figure 12B, the system is paused for debugging and the time spans overlap; See figure reproduced below where although they are in different timesteps, the time lines overlap so that data can be exchanged in multi-tasking mode)
PNG
media_image1.png
738
1276
media_image1.png
Greyscale
See motivation of claim 1.
Regarding claim 3, the combination of Luenstroth and Yunt teach the limitations of claim 1. Luenstroth teaches wherein simulating the block diagram in the simulation environment comprises executing the block diagram in a Model-in-the-loop simulation mode. ([0049], model in the loop simulation is used)
Regarding claim 4, the combination of Luenstroth and Yunt teach the limitations of claim 1. Luenstroth teaches wherein simulating the block diagram in the simulation environment comprises generating source code and executing at least some of the blocks periodically is done via executing the source code in a Software-in-the-Loop simulation mode. (Abstract, [0006], [0015], [0025], software in the loop simulation is used)
Regarding claim 5, the combination of Luenstroth and Yunt teach the limitations of claim 4. Luenstroth teaches wherein simulating the block diagram in the simulation environment comprises logging a current value of the signal at a first period ({0011], [0015], [0018]-[0019], the simulation is opened and run in the model editor to see exchanged signals; [0015], [0052], all values are logged)
Luenstroth does not explicitly recite logging a current value of all state variables at a second period, wherein the second period is a multiple of the first period, and wherein receiving a pause command at a specific simulation time further comprises stepping back from the specific simulation time in steps that correspond to the second period.
Yunt teaches logging a current value of all state variables at a second period, wherein the second period is a multiple of the first period, and wherein receiving a pause command at a specific simulation time further comprises stepping back from the specific simulation time in steps that correspond to the second period. (Column 37 Lines 10-17, Figure 12B, the system is paused for debugging and the time spans overlap which allows the engineer to step through the simulation at either the first or second timestep, all variables are logged)
See motivation of claim 1.
In regards to claim 9, it is the computer readable medium embodiment of claim 1 with similar limitations to claim 1, and is such rejected using the same reasoning found in claim 1.
See Luenstroth [0026] and [0047] for additional computer readable medium and program recitation.
In regards to claim 10, it is the computer system embodiment of claim 1 with similar limitations to claim 1, and is such rejected using the same reasoning found in claim 1.
See Luenstroth [0027] for additional computer components
Regarding claim 11, the combination of Luenstroth and Yunt teach the limitations of claim 9. Luenstroth teaches wherein the memory is a nonvolatile memory, a hard disk or solid state disk. ([0027], a computer system is provided which comprises a processor, a random access memory, a graphics controller connected to a display, a serial interface connected to at least one human input device, and a nonvolatile memory, in particular a hard disk or a solid-state disk.)
Claims 6-8 are rejected under 35 U.S.C. 103 as being unpatentable over Luenstroth et al USPPN 2018/0039566, in view of Yunt et al USPAT 8,131,523, and in further view of Ciolfi et al. USPPN 2005/0216248.
Regarding claim 6, the combination of Luenstroth and Yunt teach the limitations of claim 1. Luenstroth does not explicitly teach wherein receiving a pause command at a specific simulation time, receiving a new value for the at least one parameter, and simulating the block diagram for a further time span are repeated multiple times,
Yunt teaches wherein receiving a pause command at a specific simulation time, receiving a new value for the at least one parameter, and simulating the block diagram for a further time span are repeated multiple times, (Column 37 Lines 10-17, Figure 12B, the system is paused for debugging and the values from the .1 second task update the 1 second task that simulates for a further timespan that is repeated multiple times)
See motivation of claim 1.
The combination of Luenstroth and Yunt does not explicitly recite and wherein the sets of signal values resulting from simulations with different parameter are stored in separate buffers.
Ciolfi teaches wherein the sets of signal values resulting from simulations with different parameter are stored in separate buffers. (Claim 21, [0075], [0120], [0175], the data is stored separately into partitioned memory)
It would have been obvious to one of ordinary skill in the art, before the effective filing date, to combine the teachings of Luenstroth and Yunt with Ciolfi as the references deal with block diagram simulation, in order to implement a system that stores results in different buffers and deletes selected data. Ciolfi would modify Luenstroth and Yunt by storing results in different buffers and deleting selected data. The benefit of doing so is the system supports selective memory restoration for parts of the model as it is indexing the origin of the model. Additionally, the deleting of data allows the user to customize their block palette. (Ciolfi [0173], [0076])
Regarding claim 7, the combination of Luenstroth, Yunt and Ciolfi teach the limitations of claim 6. Luenstroth teaches further comprising displaying a graphical user interface indicating the available sets of signal values, receiving a choice of one or more sets of signal values, and displaying the chosen sets of display values. (Figures 1 and 7, [0009], [0018], [0025], [0063], [0075], a graphical user interface displays values for the Matlab/Simulink compiler; Figures 4, [0005], [0019], [0075], based on the selected block values, values for each of the blocks after the simulation are displayed)
Regarding claim 8, the combination of Luenstroth, Yunt and Ciolfi teach the limitations of claim 6. The combination of Luenstroth and Yunt does not explicitly recite further comprising displaying a graphical user interface indicating the available sets of signal values, receiving an indication of a set of signal values to discard, and deleting the indicated set of signal values. ([0076], [0079], selected blocks are deleted in the Simulink and Matlab programs)
See motivation of claim 1.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Englehart USPPN 2008/0040703: Also teaches block diagram simulation that allows the simulation to be paused and resumed by the user.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL COCCHI whose telephone number is (469)295-9079. The examiner can normally be reached 7:15 am - 5:15 pm CT Monday - Thursday.
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.
/MICHAEL EDWARD COCCHI/Primary Examiner, Art Unit 2188
Prosecution Insights