DETAILED ACTION
This action is in response to the amendments filed on Ov. 17th, 2025. A summary of this action:
Claims 1-26 have been presented for examination.
Claims 1-26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite
An examiner’s suggested amendment is provided below, along with notice that such an amendment would likely require further search as well as further consideration of art of record outside of cursory review of the after final process (should it be adopted)
Claim(s) 1-4, 7-16, 19-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over MathWorks Automotive Advisory Board (MAAB), “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB ® , Simulink ® , and Stateflow ® Version 3.0”, Aug. 2012, URL: www(dot)mathworks(dot)com/solutions/mab-guidelines/previous-versions(dot)html, in view of Bagge et al., “Interfacing Concepts Why Declaration Style Shouldn’t Matter”, 2010, and in further view of Ciolfi et al., US 2010/0153910
Claim(s) 5-6, 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over MathWorks Automotive Advisory Board (MAAB), “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB ® , Simulink ® , and Stateflow ® Version 3.0”, Aug. 2012, URL: www(dot)mathworks(dot)com/solutions/mab-guidelines/previous-versions(dot)html, in view of Bagge et al., “Interfacing Concepts Why Declaration Style Shouldn’t Matter”, 2010, and in further view of Ciolfi et al., US 2010/0153910, and in further view of MathWorks, “Simulink, Dynamic System Simulation for MATLAB, Using Simulink, Version 3”, 1999, accessed via URL: wcsp(dot)eng(dot)usf(dot)edu/courses/DSPLab/sl_using(dot)pdf
Claims 1-4, 7, 9-16, 19, 21-26 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090.
Claims 5-6, 17-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090 in view of MathWorks, “Simulink, Dynamic System Simulation for MATLAB, Using Simulink, Version 3”, 1999, accessed via URL: wcsp(dot)eng(dot)usf(dot)edu/courses/DSPLab/sl_using(dot)pdf
Claims 8 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090 in view of Resmerita et al., US 2012/0310620
This action is Final
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments/Amendments
Regarding the declaration
With respect to #1, these remarks indicate agreement about a general characterization of who POSITA would have been with what the Examiner previously stated (Non-final Act. at 6, # 1). The Examiner was pointing this point out previously in view of MPEP § 716: “MPEP 716: "Although factual evidence is preferable to opinion testimony, such testimony is entitled to consideration and some weight so long as the opinion is not on the ultimate legal conclusion at issue. While an opinion as to a legal conclusion is not entitled to any weight, the underlying basis for the opinion may be persuasive. In re Chilowsky, 306 F.2d 908, 134 USPQ515 (CCPA 1962)"”
With respect to # 2, similar as # 1 above. Again, the Examiner notes that one must be careful in separating the underlying factual basis from opinion on the ultimate legal conclusion when evaluating declarations.
With respect to # 3, at issue is the breath of “rate-based” under the BRI, as compared to “Those blocks execute according to sample times are compatible with the time-based solver, which may be rate-based.” As discussed in these remarks. “Rate-based” on page 20, ¶ 2 and later on page 21: “a rate-based executable entity scheduled to execute once every time
unit, e.g., second, millisecond, microsecond” [note in particular the lack of link to the time unit being sample time] – then page 25: “In some embodiments, executable entities may be triggered through one or more 10 explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers.” – POSITA would reasonably infer triggering something using a periodic time would be “rate-based” even though it was not being executed according to sample times, i.e. at issue is the breadth of “rate-based” includes being triggered by a periodic timer.
To clarify, see page 11, last paragraph of the instant disclosure: “the call style is a discrete sample time” – this is not what the claim recites, but rather a distinctly different broader term.
Such a dispute over claim construction is readily resolvable, “Because applicant has the opportunity to amend the claims during prosecution, giving a claim its broadest reasonable interpretation will reduce the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Yamamoto, 740 F.2d 1569, 1571 (Fed. Cir. 1984)” MPEP § 2111, and see its discussion of In re Prater, 415 F.2d 1393, 1404-05, 162 USPQ 541, 550-51 (CCPA 1969) to clarify on lack of express recitation in the claim itself, i.e. in view of these remarks for the intended claim language, the Examiner suggests amending the claims to more clearly reflect what these remarks allege this should be construed as (see the § 112(b) rejection below for the suggested amendments).
With respect to # 4, see rejections below for how the newly amended subject matter is treated.
With respect to # 5, the Examiner respectfully disagrees – if a block executes/is called because it receives an “EventA” signal, it is an event-based call. If a more narrow claim construction is intended, the Examiner suggests amending the claims themselves to expressly reflect it (to clarify, again the modifying term that is of import to claim construction is “based”, i.e. any and all call styles based on an event). As expressly shown in the MAAB guidelines, with an “Event” going into a rising edge trigger port.
With respect to # 6, see # 4 and # 5 above, i.e. “rate-based call style” is interpreted as any call style wherein the block executes based on a rate, e.g. “Task4ms” [a task executing every 4 milliseconds]. See § 112(b) rejection below for more clarification.
The remarks generally indicate a very particular definition of what the conjunction of “based” and “rate”/”event” are, when taken in a phrase with “call-style”, however these remarks do not reflect any particular express definition, nor is one found readily in the specification. As the Examiner has previously stated, if there is an intended narrower construction for these terms, e.g. executing at sample times to call the block/entity, then the claims should expressly reflect that given the breadth of the terms used in the claim. See § 112(b) rejection below for more clarification, along with a suggested amendment.
Regarding the § 112 Rejection
Maintained, updated as necessitated by amendment. See rejection below for clarification.
With respect to the remarks, first see above. Then, see the rejection, for these remarks merely choose some passages of the specification, and the specification provides no express limiting definition, but rather indicates (e.g. page 25, ¶ 2 and other cited portions in the rejection, as well as the declaration) that, for example, a triggered block may be called/executed by a function call, i.e. a function-call call-style (call style merely being the style in how it is to be called/executed). See the rejection below for clarification, wherein the Examiner does expressly acquiesce that there is a distinction between elements (iii) and (iv) in view of the present amendments, and provides a suggested path of amendment to remedy this issue.
To clarify, as noted above several times, it is the breadth of “based” that causes the § 112(b) issue, i.e. an event-based call style is any call style based on an “Event”; similar with rate-based, i.e. any call style based on a “rate”. “Sample time” is an example of this, but as page 11 so distinctly points out, the particular word choice would be: “the call style is a discrete sample time” to limit it to sample time expressly.
Also, as the premise of the § 112(b) rejection is claim construction, and this is what is in dispute, see MPEP § 2111.01(I and III): “Under a broadest reasonable interpretation (BRI), words of the claim must be given their plain meaning, unless such meaning is inconsistent with the specification. The plain meaning of a term means the ordinary and customary meaning given to the term by those of ordinary skill in the art at the relevant time. The ordinary and customary meaning of a term may be evidenced by a variety of sources, including the words of the claims themselves, the specification, drawings, and prior art. However, the best source for determining the meaning of a claim term is the specification - the greatest clarity is obtained when the specification serves as a glossary for the claim terms. Phillips v. AWH Corp., 415 F.3d 1303, 1315, 75 USPQ2d 1321, 1327 (Fed. Cir. 2005) (en banc) ("[T]he specification ‘is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term.’" (quoting Vitronics Corp. v. Conceptronic Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996))…. "[T]he ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Phillips v. AWH Corp.,415 F.3d 1303, 1313, 75 USPQ2d 1321, 1326 (Fed. Cir. 2005) (en banc); Sunrace Roots Enter. Co. v. SRAM Corp., 336 F.3d 1298, 1302, 67 USPQ2d 1438, 1441 (Fed. Cir. 2003); Brookhill-Wilk 1, LLC v. Intuitive Surgical, Inc., 334 F.3d 1294, 1298, 67 USPQ2d 1132, 1136 (Fed. Cir. 2003) ("In the absence of an express intent to impart a novel meaning to the claim terms, the words are presumed to take on the ordinary and customary meanings attributed to them by those of ordinary skill in the art… The ordinary and customary meaning of a term may be evidenced by a variety of sources, including the words of the claims themselves, the specification, drawings, and prior art. However, the best source for determining the meaning of a claim term is the specification – the greatest clarity is obtained when the specification serves as a glossary for the claim terms… Phillips v. AWH Corp., 415 F.3d 1303, 1317, 75 USPQ2d 1321, 1329 (Fed. Cir. 2005) ("Although we have emphasized the importance of intrinsic evidence in claim construction, we have also authorized district courts to rely on extrinsic evidence, which "consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises.")
Regarding the § 102/103 Rejection
Maintained, and updated as necessitated by amendment.
With respect to the remarks, the Examiner respectfully disagrees. MAAB shows an “Event[]” and a “Task2ms”/”Task4ms” call style (i.e. ones based on events/rates, respectively), which is later used to invoke execution of a rising edge trigger.
Also, see the below § 112(b) rejection for its suggested amendment that would overcome the art of record, but require further consideration of a new grounds of rejection in view of other art of record.
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.
Claims 1-26 are 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. Dependent claims inherit the deficiencies of the claims they depend upon.
To clarify, “Similarly, the double inclusion of an element by members of a Markush group is not, in itself, sufficient basis for objection to or rejection of claims. Rather, the facts in each case must be evaluated to determine whether or not the multiple inclusion of one or more elements in a claim renders that claim indefinite.” (MPEP § 2173.05(h)).
The independent claims (using claim 1 as representative) recite: “…the scheduling logic implements a first call style that is different than a second call style used to invoke execution of the one or more executable entities as the unit and the first call style and the second call style are one of: (i) rate-based, (ii) event-based, (iii) function-call, or (iv) triggered based on a falling edge and/or a rising edge; and”
This is indefinite in view of the disclosure and the declaration of Nikhil Ranade (Apr. 2025), the instant disclosure, and the Embedded Coder’s User Guide for Simulink R2011b (for evidence of plain meaning, MPEP § 2111.01).
The core issue of this rejection is that the claim requires the use of two different call styles, and enumerates a listing of four styles to be selected from (note: “are one of”).
Thus, the claim requires each of these four styles to be fully distinct, as any combination of the elements on this list are within the scope of the claims.
However, when given a fair reading in view of the disclosure, wherein the exemplary environment is Simulink from MathWorks (the assignee) – see page 43-44 of the instant disclosure, note the drawings for the GUIs also indicate this as POSITA would have readily recognized the artistic style of Simulink’s GUIs in the depictions, an issue of § 112(b) arises on the exclusionary scope of the “different” requirement express in selecting two elements in the list.
To clarify, at issue is that this is a closed grouping of alternatives, wherein the claim requires two selections from said list, one for each call style, and that each call style must be distinct from the other call style.
See the following particular citations below to clarify on this rejection and claim construction:
Instant page 10: “116. For example, the subsystems 118, 120, and 122 may be event-triggered subsystems that listen for an event, such as an initialize event, a reset event, and a termination event.” Instant disclosure, page 24: “Exemplary call styles that may be presented include Edge Trigger, Function Call, and Implicit Task. Edge Trigger may refer to a call style that utilizes a rising, e.g., 0 to 1, and/or falling, e.g., 1 to 0, control signal, event, or other data” – to clarify on the punctuation for reading this sentence, simply change the most interior nested comma delimited phrases to have parenthesis: “Exemplary call styles that may be presented include Edge Trigger, Function Call, and Implicit Task. Edge Trigger may refer to a call style that utilizes a rising (e.g., 0 to 1) and/or falling (e.g., 1 to 0) control signal, event, or other data” - i.e. an edge trigger is a “rising…and/or falling” edge of a “control signal, event, or other data”. Declaration ¶ 22: “A Triggered Subsystem executes once each time a trigger event occurs on the control signal (sometimes called the trigger signal)… The blocks contained in a Triggered Subsystem are time-based blocks.”
Thus, triggered based on a rising/falling edge includes being an event-based call-style, as it would be called by an event, thus the call-style was based on an event.
Page 25: “In some embodiments, executable entities may be triggered through one or more explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers.” Declaration, ¶ 22: “A Triggered Subsystem executes once each time a trigger event occurs on the control signal (sometimes called the trigger signal).”
The “event” in this case may be a “periodic timer”, so an example of rate-based, thus the call style was based on an event which was a rate/periodic timer, i.e. once each time unit the periodic timer provides a signal. Page 21, ¶ 3 of the disclosure: “For example, suppose a component includes a rate-based executable entity scheduled to execute once every time unit, e.g., second, millisecond, microsecond, etc.,”
Declaration, ¶ 11: “The Simulink blocks included in the Function-Call or Triggered subsystems are rate-based blocks… The Simulink blocks are executed according to this rate-based schedule when the condition specified by the Function-Call or Triggered subsystem is met.” Declaration, ¶ 23: “The function-call initiator can invoke the Function-Call subsystem zero, once, or multiple times per time step of the model by outputting the scalar value zero, once, or multiple times.”
Thus, “rate-based” also includes “function-call”. Page 21, ¶ 3 of the disclosure: “For example, suppose a component includes a rate-based executable entity scheduled to execute once every time unit, e.g., second, millisecond, microsecond, etc.,”
Thus, while a “(iv) triggered based on a falling edge and/or a rising edge;” is distinct from “(iii) function-call”, in the embodiments of this claim wherein it is a “rate-based” and “event-based” call styles, these are not “different” under the BRI.
Similar to when it is an “event-based” and “(iv) triggered based on a falling edge and/or a rising edge”.
Similar to when it is an “function-call” and “rate-based”.
And per page 26: “explicit events, such as function calls or messages” – “function-call” and “event-based” does not have a clear distinction.
The Examiner suggests amending the claim to be more express, i.e. as discussed above the “function-call” and “(iv) triggered based on a falling edge and/or a rising edge” are distinct/different from each other, but triggered includes triggering from events (page 26), for the term “different” requires an exclusionary scope, and at issue is there is not a clear line of demarcation of what is excluded and what is not.
As to “rate-based”, the Examiner suggests amending this to more clearly reflect what was implied in the remarks (Nov. 2025, # 3) and found at page 38: “the call style is a discrete sample time”.
With respect to “event-based”, the Examiner suggests deleting this term, given that it would still cause a § 112(b) issue for the reasons discussed above, or narrow it expressly such as to “messages” (pages 9, 25, 47).
Should this suggestion be adopted, the Examiner notes that this would likely overcome the § 103 rejection of record, however further consideration outside of the cursory review of the after final process would be required, for it appears likely that it would necessitate by the amendment a new grounds of rejection under § 103 would be required, in particular over MathWorks, “Embedded Coder”, “User’s Guide”, for MATLAB & Simulink version R2011b in view of Clune, US 8,036,871. In MathWorks, generally see pages 13-54 to 13-55; 13-60 to 13-62, and in Clune generally see the prior citations of record, e.g. col. 6 to col. 8. Also, col. 9 ¶ 2.
Should further clarification on the plain meaning of these terms be sought (MPEP § 2111.01(III)), see:
MathWorks, “Embedded Coder”, “User’s Guide”, for MATLAB & Simulink version R2011b, page 6-64: “The Trigger block parameter Trigger type is function-call”
MathWorks, “Function-Call Subsystem”, accessed on Aug. 12th, 2025, URL: mathworks(dot)com/help/simulink/slref/functioncallsubsystem(dot)html -“A Trigger type of function-call makes the block a Function-Call port block that accepts function-call events.” – in its description of the Ports of the Function-Call Subsystem.
MathWorks, “Using Simulink”, Version 5, 2002, page 4-33: “You can create a triggered subsystem whose execution is determined by logic internal to an S-function instead of by the value of a signal. These subsystems are called function-call subsystems. For more information about function-call subsystems, see “Function-Call Subsystems” in the “Implementing Block Features” section of Writing S-Functions.”
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-4, 7-16, 19-26 is/are rejected under 35 U.S.C. 103 as being unpatentable over MathWorks Automotive Advisory Board (MAAB), “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB ® , Simulink ® , and Stateflow ® Version 3.0”, Aug. 2012, URL: www(dot)mathworks(dot)com/solutions/mab-guidelines/previous-versions(dot)html, in view of Bagge et al., “Interfacing Concepts Why Declaration Style Shouldn’t Matter”, 2010, and in further view of Ciolfi et al., US 2010/0153910
Then see: MPEP § 2131.01: “However, a 35 U.S.C. 102 rejection over multiple references has been held to be proper when the extra references are cited to: (A) Prove the primary reference contains an "enabled disclosure;"”) – see the references cited below (and discussed in detail in the rejection) to prove enablement of this combination of prior art, which are part of the grounds of rejection in view of 2131.01:
DeGroot, US 6,182,227
Clune, US 8,036,871
MathWorks, “Embedded Coder”, “User’s Guide”, for MATLAB & Simulink version R2011b
Wikipedia, article on “Thunk”, accessed via the WayBack Machine with an archive date of Mar. 22nd, 2016, URL: en(dot)wikipedia(dot)org/wiki/Thunk
Regarding Claim 1
MAAB teaches:
A computer-implemented method comprising: (MAAB, § 3 describes the “Software Environment” for the guidelines)
accessing, from a memory, a model component, the model component including one or more executable entities, each executable entity comprising a subsystem, a sub-model, or a group of model elements configured to be invoked as a unit using a particular call style, wherein the model component defines a functional behavior; (MAAB, § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.”
Then see the figure in § 5.3 – the lower levels below the trigger layer comprise model components with executable entities, e.g. see § 5.3.4 for its description of the “Structure Layer” including its figures which give examples of model “Component[s]” visually. To clarify on the BRI, the Examiner notes that MAAB is describing models in Simulink, which is the exemplary modeling environment of the instant disclosed invention (page 43, ¶ 3 of the instant disclosure; as well as pages 43-44, and page 16 ¶ 1) – i.e. the use of such a model in Simulink would have included accessing it in memory
PNG
media_image1.png
282
377
media_image1.png
Greyscale
PNG
media_image2.png
548
520
media_image2.png
Greyscale
As a point of clarity, the MAAB guidelines are for use with Simulink, which is the exemplary programming language in the instant disclosure. Instant disclosure, Pages 43-44, paragraph split between the pages. See instant figures as well.
To clarify, note in the fig. above for the structured layer example, they show that “event” based call style from the trigger layer is used to invoke execution using the particular call style of a rising edge trigger (see the symbol at the top of components K and I).
providing, by one or more processors coupled to the memory, an interface associated with the model component, wherein the interface includes one or more entry points for the one or more executable entities included in the model component; linking scheduling logic to the one or more entry points of the interface, wherein the scheduling logic is included within a model that includes the model component, and the scheduling logic implements a first call style that is different than a second call style used to invoke execution of the one or more executable entities and the first call style and the second call style are one of: (i) rate-based, (ii) event-based, (iii) function-call, or (iv) triggered based on a falling edge and/or a rising edge; and(MAAB, § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.” Then § 5.3.3: “A trigger layer indicates the processing timing [example of linked scheduling logic included in the model – see the figures to clarify] by using Triggered Subsystem or Function-Call Subsystem. The blocks should set Priority, if needed. The priority value must be displayed as a Block Annotation. The user should be able to understand the priority-based order without having to open the block.” – then, see the figures in §§ 5.3.1 and 5.3.3 as reproduced below, wherein the Examiner provided clarifying annotations;
to clarify, § 7.1.9: “The Trigger port is also the function-call block.” – i.e. the second call style is trigger/function call; and the first call style is rate-based (e.g. “8ms” or “Task4ms”) or an “Event”)
and also note the “Event” based call style as well, which later invokes execution of a triggered on a rising edge call style
PNG
media_image3.png
782
837
media_image3.png
Greyscale
PNG
media_image4.png
361
819
media_image4.png
Greyscale
MAAB does not explicitly teach:
translating the first call style implemented by the scheduling logic included in the model to the second call style associated with the one or more executable entities to execute the one or more executable entities of the model component as included in the model consistent with the second call style associated with the one or more executable entities, the translating performed without altering the functional behavior of the model component;
wherein an execution schedule for the one or more executable entities of the model component, based on the scheduling logic linked to the one or more entry points included in the interface associated with the model component as included in the model, is at least one of generated and utilized during execution of at least the model component, or implemented in code generated for at least the model component.
MAAB, in view of Bagge, teaches: translating the first call style implemented by the scheduling logic included in the model to the second call style associated with the one or more executable entities to execute the one or more executable entities of the model component as included in the model consistent with the second call style associated with the one or more executable entities, the translating performed without altering the functional behavior of the model component;(MAAB, § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.” Then § 5.3.3: “A trigger layer indicates the processing timing [example of scheduling logic] by using Triggered Subsystem or Function-Call Subsystem. The blocks should set Priority, if needed. The priority value must be displayed as a Block Annotation. The user should be able to understand the priority-based order without having to open the block.” – then, see the figures in §§ 5.3.1 and 5.3.3 as discussed above
As taken in view of Bagge, page 38, second to last paragraph: “In this paper, we show how this is solved in Magnolia by separating the implementation signature from the use signature, allowing different call styles to be used independently of the implementation style [example of translating without altering the functional behavior/”implementation”]. By letting the compiler translate between different call styles, we gain increased flexibility for program processors – of both the human and software variety. We call these translations functionalization and mutification.”
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 MAAB on the “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB” (MAAB, title) including its teachings on “ Control models are organized using the following hierarchical structure” (MAAB, § 5.3 and its subsections) with the teachings from Bagge on “letting the compiler translate between different call styles” (Bagge, page 38) The motivation to combine would have been that “By letting the compiler translate between different call styles, we gain increased flexibility for program processors – of both the human and software variety. We call these translations functionalization and mutification.” (Bagge, page 38).
MAAB, in view of Bagge, does not explicitly teach:
wherein an execution schedule for the one or more executable entities of the model component, based on the scheduling logic linked to the one or more entry points included in the interface associated with the model component as included in the model, is at least one of generated and utilized during execution of at least the model component, or implemented in code generated for at least the model component.
MAAB, in view of Bagge and in further view of Ciolfi teaches: wherein an execution schedule for the one or more executable entities of the model component, based on the scheduling logic linked to the one or more entry points included in the interface associated with the model component as included in the model, is at least one of generated and utilized during execution of at least the model component, or implemented in code generated for at least the model component. (MAAB, § 5.3.3 as discussed above including: “A trigger layer indicates the processing timing by using Triggered Subsystem or Function-Call Subsystem“, see the “Rationale” which shows that it includes being intended for use in “Code Generation” – to clarify, § 2.3.8: “Code generation: Generation of code that is efficient and effective for embedded systems… Fast software changes… Robustness of generated code”; then see § 15, page 133 for the “Real-Time Workshop”: “Real-Time Workshop is an automatic C language code generator for Simulink. It produces C code directly from Simulink block diagram models and automatically builds programs that can be run in real-time in a variety of environments” – see the other clarifying citations of MAAB above for the scheduling logic linked to entry points in the interface, as was taken in view of Bagge above including Bagge page 38, second to last paragraph for the translating step
In further view of Ciolfi, ¶¶ 61-62: “The need for explicit execution control of subgraphs arises in many situations where explicit ordering ( often referred to as sequencing or scheduling) of the subgraphs enables supervisory control. For example, one subgraph may represent activities to be performed at initialization and another subgraph may represent run-time behavior. In the example of FIG. 3A, the initialization subgraph defined by the init Function-Call Subsystem is executed when the system starts up or is reset while running. Within a subgraph that is explicitly controlled, it may further be desired that data dependencies are satisfied ensuring each block within the subgraph is operating on current (e.g., up-to-date) information… (1) modeling of systems where there needs to be explicit scheduling of subsystems by elements of a block-diagram, which can be referred to as supervisory control, and” – then see ¶ 77: “Referring to FIG. 11, a left-to-right ordering means that Chart2 1110 must be placed before Chartl 1105 in the sorted list. The sorted list may be a data structure [example of a generated execution schedule] that is used by a simulation or code generation engine to generate execution lists…” – see ¶¶ 141-143 to clarify, including: “Code generation is performed by using the sorted list and the results of initialization to create an intermediate representation that is transformed to generated code such as C or C++. Alternatively, hardware can be synthesized from the model by producing code that conforms to a hardware description language HDL such as Verilog.”
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 MAAB on the “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB” (MAAB, title) including its teachings on “ Control models are organized using the following hierarchical structure” (MAAB, § 5.3 and its subsections) with the teachings from Ciolfi on “Exemplary embodiments allow subgraph execution control within a graphical modeling or graphical programming environment” (Ciolfi, abstract). The motivation to combine would have been that "While the behavior of Simulink 7.3 and other conventional types of graphical environments is welI defined, there may be a need to ensure data dependencies are satisfied during model execution, while also allowing for explicit execution control. To enable explicit execution control, while satisfying data dependencies, an exemplary embodiment employs a novel semantic via a Control Signal Split block. In general, a Control Signal Split ( or equivalently a Control Signal Branch block) block can accept a control-signal and then in turn execute one or more destination blocks. A Control Signal Split block can be realized in an embodiment as a Function-Call Split block." (Ciolfi, ¶ 52) - to clarify, see Ciolfi, ¶ 5.
An additional motivation to combined would have been: "The use of control signal group and ungroup blocks can provide models with the capability to have control signals cross hierarchical boundaries of the model, enable parallel compilation of components ( e.g., subsystems) in the model, allow for independent verification of components of the model and provide uses with improved development workflows ( e.g., when many people are working on a model)." (Ciolfi, ¶ 102)
With respect to enablement:
A declaration, as discussed above, was made of record wherein its underlying rationale is, at its heart, attempting to address the enablement and written description considerations underlying a § 103 rejection, specifically the question: Would POSITA, before the effective filing date of the instant invention have arrived at the presently claimed invention in view of the combination of prior art relied upon and the rationales supporting that combination? Wherein the § 112(a) considerations are whether or not POSITA would have been able to “arrive at” the instant claimed invention based on 1) whether the combination of prior art relied upon sufficiently describes the claimed invention (§ 112(a) for written description)? Then question 2) whether the combination of prior art relied upon sufficiently describes the claimed invention in a manner that POSITA would have been able to arrive at the presently claimed invention without undue experimentation (§ 112(a) for enablement)?
As such, and given the nature of the declaration, the Examiner has now included an enablement consideration of the combination of prior art relied upon, including the MAAB reference. See:
MPEP § 2141.03(I): “"A person of ordinary skill in the art is also a person of ordinary creativity, not an automaton." KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 421, 82 USPQ2d 1385, 1397 (2007). "[I]n many cases a person of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle." Id. at 420, 82 USPQ2d 1397. Office personnel may also take into account "the inferences and creative steps that a person of ordinary skill in the art would employ." Id. at 418, 82 USPQ2d at 1396.”
MPEP 2145: “A conclusion of obviousness requires that the reference(s) relied upon, together with the knowledge of a person skilled in the art, be enabling in that it put the public in possession of the claimed invention. In re Hoeksema, 399 F.2d 269, 273, 158 USPQ 596, 600 (CCPA 1968) (citing In re Le Grice, 301 F.2d 929, 936, 133 USPQ 365, 372 (CCPA 1962
MPEP 2145(X)(B): “In re O’Farrell, 853 F.2d 894, 903, 7 USPQ2d 1673, 1681 (Fed. Cir. 1988) (citations omitted) (The court held the claimed method would have been obvious over the prior art relied upon because one reference contained a detailed enabling methodology, a suggestion to modify the prior art to produce the claimed invention, and evidence suggesting the modification would be successful.).
MPEP § 2121.01: “Elan Pharm., Inc. v. Mayo Found. For Med. Educ. & Research, 346 F.3d 1051, 1054, 68 USPQ2d 1373, 1376 (Fed. Cir. 2003) (At issue was whether a prior art reference enabled one of ordinary skill in the art to produce Elan’s claimed transgenic mouse without undue experimentation. Without a disclosure enabling one skilled in the art to produce a transgenic mouse without undue experimentation, the reference would not be applicable as prior art.).”
MPEP § 2143.02(II): “Obviousness does not require absolute predictability, but at least some degree of predictability is required. Evidence showing there was no reasonable expectation of success may support a conclusion of nonobviousness… In re O’Farrell, 853 F.2d 894, 903, 7 USPQ2d 1673, 1681 (Fed. Cir. 1988) (The court held the claimed method would have been obvious over the prior art relied upon because one reference contained a detailed enabling methodology, a suggestion to modify the prior art to produce the claimed invention, and evidence suggesting the modification would be successful.).” wherein 2143.02(III) clarifies: “Whether an art is predictable or whether the proposed modification or combination of the prior art has a reasonable expectation of success is determined at the time the invention was made for pre-AIA obviousness analysis. For obviousness analysis under the AIA , the relevant time is "before the effective filing date of the claimed invention.” And MPEP § 2145, example 1: “The claims at issue in PharmaStem Therapeutics, Inc. v. Viacell, Inc., 491 F.3d 1342, 83 USPQ2d 1289 (Fed. Cir. 2007),… There had been ample suggestion in the prior art that the claimed method would have worked. Absolute predictability is not a necessary prerequisite to a case of obviousness. Rather, a degree of predictability that one of ordinary skill would have found to be reasonable is sufficient. The Federal Circuit concluded that "[g]ood science and useful contributions do not necessarily result in patentability." Id. at 1364, 83 USPQ2d at 1304.”
MPEP § 2164.01: “See also United States v. Telectronics, Inc., 857 F.2d 778, 785, 8 USPQ2d 1217, 1223 (Fed. Cir. 1988) ("The test of enablement is whether one reasonably skilled in the art could make or use the invention from the disclosures in the patent coupled with information known in the art without undue experimentation."). A patent need not teach, and preferably omits, what is well known in the art. In re Buchner, 929 F.2d 660, 661, 18 USPQ2d 1331, 1332 (Fed. Cir. 1991); Hybritech, Inc. v. Monoclonal Antibodies, Inc., 802 F.2d 1367, 1384, 231 USPQ 81, 94 (Fed. Cir. 1986), cert. denied, 480 U.S. 947 (1987); and Lindemann Maschinenfabrik GMBH v. American Hoist & Derrick Co., 730 F.2d 1452, 1463, 221 USPQ 481, 489 (Fed. Cir. 1984)”
MPEP § 2163(II)(A)(3)(a): “See also Capon v. Eshhar, 418 F.3d 1349, 1357, 76 USPQ2d 1078, 1085 (Fed. Cir. 2005) ("The ‘written description’ requirement must be applied in the context of the particular invention and the state of the knowledge…. As each field evolves, the balance also evolves between what is known and what is added by each inventive contribution.")” MPEP § 2164.05(a): “The state of the art for a given technology is not static in time. It is entirely possible that a disclosure which would not have been enabled if filed on January 2, 1990 might be enabled if the same disclosure had been filed on January 2, 1996. Therefore, the state of the prior art must be evaluated for each application based on its filing date.”
For example, see ¶ 19 of the declaration (Apr. 2025 from Nikhil Ranade) which discusses the drawing and singularly attacks the drawing for being a drawing, rather then what it would fairly suggest POSITA to arrive at in the technology of the field of endeavor. MPEP §2163(II)(A)(3): “See, e.g., Vas-Cath, 935 F.2d at 1565, 19 USPQ2d at 1118 ("drawings alone may provide a ‘written description’ of an invention as required by Sec. 112 "); In re Wolfensperger, 302 F.2d 950, 133 USPQ 537 (CCPA 1962) (the drawings of applicant’s specification provided sufficient written descriptive support for the claim limitation at issue); Autogiro Co. of Am. v. United States, 384 F.2d 391, 398, 155 USPQ 697, 703 (Ct. Cl. 1967) ("In those instances where a visual representation can flesh out words, drawings may be used in the same manner and with the same limitations as the specification."); Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1406”
Wherein these drawings are sufficient written description support; so, this shifts to the second part of the § 112(a) consideration which is the question to enablement under the Wands Factors. As an initial matter, the Examiner presumes the MAAB guidelines are enabled, as they are industry standard guidelines for the use of Simulink in the automotive field so thus POSITA would expect and presume them to be enabled. The Examiner is just going to clarify on this more explicitly because prior remarks also implied an enablement consideration (final-rejection, Nov. 2024, response to remarks pages 12-15). However, below the Examiner has provided additional extrinsic evidence to further demonstrate that MAAB is enabled; and thus, per MPEP § 2131.01 has entered them into the grounds of rejection.
The particular Wands Factor that best shows this is enabled is (C) The state of the prior art as demonstrated by the below evidence (MPEP § 2164.01(a)). Such evidence also demonstrates the level of skill, and the predictability, MAAB on its own provides evidence of direction (at its industry guidelines), etc.
There are no claims to consider in MAAB (Wands factor A), so that is not considered. Wands factor for working examples, MPEP § 2164.02: “The specification need not contain an example if the invention is otherwise disclosed in such manner that one skilled in the art will be able to practice it without an undue amount of experimentation. In re Borkowski, 422 F.2d 904, 908, 164 USPQ 642, 645 (CCPA 1970). Allergan, Inc. v. Sandoz Inc., 796 F.3d 1293, 1310, 115 USPQ2d 2012, 2023 (Fed. Cir. 2015)” – and subsection I: “When considering the factors relating to a determination of non-enablement, if all the other factors point toward enablement, then the absence of working examples will not by itself render the invention non-enabled.”
In addition, with respect to working examples the Examiner notes that Wands factor is moot for a § 103 rejection, because if there was a working example of the entre claimed invention in ordered combination in the prior art it would be a § 102 rejection, not a § 103 rejection.
With respect to the quantity of experimentation, see the below evidence as well, which shows the core alleged feature in question (the translating of one call style to a second different call style) is not only taught by Bagge as relied upon in the rejection, but a well-known topic to POSITAs in the field of complier design (note the “generating code…” and other such limitations). Thus, it is simple routine experimentation with conventional methods in the knowledge of POSITA, rather than undue experimentation, to POSITA.
State of the art, and other considerations as noted above:
Clune, US 8,036,871. Col. 6, lines 35-45, then see line 60 to col. 7 line 5, in particular: “The time-based entity generator block 42 generates an entity every second. The #d output signal 43 from the EntityGenerator block is incremented after every entity departure. The update in #d signal sends a trigger signal which is 65 received at the input port 45 of the function call generation delay component block 44” – as reflected in claims 1 and 6; to summarize it col. 4 lines 20-30: “generating a trigger signal with a rising or falling edge or the event generation component may generate a function call event” – so even if this claim was limited to using a trigger to do a function-call, it would have still been rejected in view of Clune; as was cited in the Apr. 2024 non-final rejection, page 52, citing to col. 6, ¶ 3 to further clarify: “The function call generation delay component block 20 converts a signal-based event or a function-call input into one or more function calls that may be used to invoke function- 40 call subsystems, state chart systems and/or blocks, such as, for example STATEFLOW systems (STATEFLOW is also produced by The Math Works, Inc.) or other blocks that accept function-call inputs” – see fig. 5A to clarify; and col. 4, lines 35-50.
MathWorks, “Embedded Coder”, “User’s Guide”, for MATLAB & Simulink version R2011b, page 13-61, in particular note the “Scheduler”, and further note the accompanying description discusses the use of a “wrapper subsystem” (pages 13-60 to 13-61); i.e. the “Scheduler” would have readily been recognized for how a “trigger layer” (MAAB Guidelines, as cited and discussed in the declaration) would be implemented by POSITA, or a user, with Simulink 2011; wherein in particular note the top of the scheduler indicates this is a triggered block; and connected to a “wrapper subsystem”, wherein page 13-54 then states: “You can use function-call subsystems within a wrapper subsystem to represent multiple runnables in a single AUTOSAR Software Component, and export each function-call subsystem as an AUTOSAR runnable”; and note page 13-57 for its figure, in particular note the input port is “RPort_DE1” and an “R_Port_DE1 Error Status” (same as in the figure on 13-60 to 13-61), output port includes “PPort_DE3” (same as fig. on 13-60 to 13-61), wherein these are function call subsystems.
In other words, when POSITA performed the routine experimentation to make and use what MAAB discloses, and turns to the user guide of Simulink (as would be readily expected to do in routine experimentation), they would have found that for having “Multiple Runnables” with “Function-call subsystems” in the hierarchical manner discussed in MAAB for use in the AUTOSAR industry standard, that the closest suggestion in the user guide for how to do this in their routine experimentation would have been to setup the model in the manner discussed in this part of the user guide (to clarify; the Examiner also notes that the user guide is silent as to the term “trigger layer”), wherein in doing so the “triggering layer” (MAAB)/”Scheduler” (Embedded Code User Guide) is a scheduling logic linked to entry points of the interface, wherein the scheduling logic implements a first call style of a triggered call style, and wherein the scheduling logic then schedules function-call blocks (second call style) for execution; which is what the MAAB guidelines would have readily suggested POSITA to do in their routine experimentation.
PNG
media_image5.png
427
772
media_image5.png
Greyscale
To clarify on the BRI of these features, contrast page 13-61 figure as re-produced above with Fig. 3 in the instant disclosure (in particular, note the schedule, # 322, as discussed on pages 12-13; further note the symbol on the scheduler block is identical in both; wherein page 6-5 of the Embedded coders user guide indicates this symbol is a “Stateflow chart”; page 13, instant disclosure: “state chart (Scheduler)”):
PNG
media_image6.png
650
1003
media_image6.png
Greyscale
As a further point of clarity, in the Embedded coder’s user guide, page 6-62, take particular note of a “func”, i.e. a function call being input into a trigger port explicitly, and clarifies on 6-64: “The Trigger block parameter Trigger type is function-call”):
PNG
media_image7.png
365
516
media_image7.png
Greyscale
Amount of experimentation
As a further point of clarity, as noted above the question of enablement, especially given the present context (specifically, it’s a 2012 reference applied to a claim with an effective filing date of 2016; and the enablement consideration is under obviousness with a combination of prior art), the Examiner notes that a person familiar with complier design/programming (i.e. POSITA as discussed in more detail above) would have readily known from their own knowledge how to achieve such functionality of converting between call-styles (of note is that the rejection relied upon Bagge for this feature expressed in the claim as “translating…”, and the declaration makes no mention of this), because such knowledge is well-known in complier design.
Specifically, it’s called a “thunk” subroutine.
DeGroot, US 6,182,227, col. 13, last paragraph: “In general, a thunk is compiler generated code executed between the callers code and the calling code. Typically, thunks in the prior art have been utilized to convert calling conventions between the caller code and the calling code.”
Wikipedia, article on “Thunk”, accessed via the WayBack Machine with an archive date of Mar. 22nd, 2016, URL: en(dot)wikipedia(dot)org/wiki/Thunk – ¶ 1: “Thunks are primarily used to represent an additional calculation that a subroutine needs to execute, or to call a routine that does not support the usual calling mechanism.” – then in functional programming: “This is done in source code by wrapping an argument expression in an anonymous function that has no parameters of its own. This prevents the expression from being evaluated until a receiving function calls the anonymous function, thereby achieving the same effect as call-by-name.” – to clarify, the section Interoperability: “Thunks have been widely used to provide interoperability between software modules whose routines cannot call each other directly, as in the following cases. The routines have different calling conventions or use different representations for arguments…. A compiler (or other tool) can solve this problem by generating a thunk that automates the additional steps needed to call the target routine, whether that is transforming arguments, copying them to another location, or switching the CPU mode…”
To further clarify on the “thunk”, MPEP § 2114(IV): “When determining whether a computer-implemented functional claim would have been obvious, examiners should note that broadly claiming an automated means to replace a manual function to accomplish the same result does not distinguish over the prior art. See Leapfrog Enters., Inc. v. Fisher-Price, Inc., 485 F.3d 1157, 1161, 82 USPQ2d 1687, 1691 (Fed. Cir. 2007) ("Accommodating a prior art mechanical device that accomplishes [a desired] goal to modern electronics would have been reasonably obvious to one of ordinary skill in designing children’s learning devices. Applying modern electronics to older mechanical devices has been commonplace in recent years."); In re Venner, 262 F.2d 91, 95, 120 USPQ 193, 194 (CCPA 1958); see also MPEP § 2144.04. Furthermore, implementing a known function on a computer has been deemed obvious to one of ordinary skill in the art if the automation of the known function on a general-purpose computer is nothing more than the predictable use of prior art elements according to their established functions. KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417, 82 USPQ2d 1385, 1396 (2007) see also MPEP § 2143, Exemplary Rationales D and F. Likewise, it has been found to be obvious to adapt an existing process to incorporate Internet and Web browser technologies for communicating and displaying information because these technologies had become commonplace for those functions. Muniauction, Inc. v. Thomson Corp., 532 F.3d 1318, 1326-27, 87 USPQ2d 1350, 1357 (Fed. Cir. 2008).”
Thus, the Examiner also submits that should it be found that the combination of prior art relied upon, including Bagge, does not teach the translation of calling styles, then the Examiner’s rationale to reject the claim for that limitation would have been in view of DeGroot and/or Wikipedia as cited above, with the motivation to combine would for DeGroot have been that “For efficiency reasons, in one embodiment, the thunk is generated in assembly level code so as to minimize the execution time” (DeGroot, col. 13, as cited above); the motivation to combine for Wikipedia would have been that “provide interoperability between software modules whose routines cannot call each other directly” (Wikipedia, as cited above); wherein in addition to a TSM, the KSR rationale of Combining Prior Art Elements According to Known Methods To Yield Predictable Results is readily applicable as well given the well-known nature of this feature.
Regarding Claim 2
MAAB teaches: The computer-implemented method of claim 1, wherein the scheduling logic linked to the one or more entry points is described textually. (MAAB, § 5.3.3 – see the figure which shows the scheduling logic is textually described)
Regarding Claim 3
MAAB teaches:
The computer-implemented method of claim 1, wherein the interface is a graphical interface that includes one or more graphical affordances associated with the entry points for the one or more executable entities, the computer- implemented method further comprising: (MAAB, § 5.3.3 shows that the entry point is visibly depicted– to clarify on port, see MAAB § 7.1.6: “For Trigger port blocks and Enable port blocks, match the name of the signal triggering the subsystem.”; to clarify on the BRI of the graphical affordance of access point/call site, see fig. 3 as discussed on page 12: “One or more of the access points may be implemented as call sites from which the executable entities of the model component 116 may be called for execution….access points 313 and 315…” and see fig. 3 – which is similar to how MAAB visibly depicts its entry points)
presenting on a display, by the one or more processors, the model component and the graphical interface, wherein the scheduling logic is described by one or more model elements presented on the display, the one or more model elements connected to the one or more graphical affordances included in the graphical interface. (MAAB, § 5.3.3 as discussed above for its figure, as taken in view of § 7.1.16, wherein these figures also show how the scheduling logic is textually presented on the display and connected by the arrow to the graphical affordance
to clarify that these would have been presented, note 1) the GUI in § 7.1.16, and 2) also note that the “Rationale” includes “Readability”, as clarified on in § 2.3.8, wherein § 7.1 provides a substantial details on “Diagram Appearance” in “Simulink” – i.e. these diagrams in MAAB are depicting part of how to visually depict the model, and its layers and other components/elements, in Simulink)
Regarding Claim 4
MAAB teaches: The computer-implemented method of claim 3, wherein the one or more graphical affordances included in the graphical interface of the model component is one or more of a port, an access point or a call site. (MAAB, § 5.3.3 shows that the entry point is visibly depicted as a access point/call site/port – to clarify on port, see MAAB § 7.1.6: “For Trigger port blocks and Enable port blocks, match the name of the signal triggering the subsystem.”; to clarify on the BRI of the graphical affordance of access point/call site, see fig. 3 as discussed on page 12: “One or more of the access points may be implemented as call sites from which the executable entities of the model component 116 may be called for execution….access points 313 and 315…” and see fig. 3 – which is similar to how MAAB visibly depicts its entry points
Regarding Claim 7
MAAB teaches: The computer-implemented method of claim 1, further comprising: partitioning the model component to identify the one or more executable entities, wherein the partitioning is performed automatically or under user direction. (MAAB, § 5.1 title: “Simulink® and Stateflow® Partitioning”, also see § 5.2: “To allow partitioning of the model into discreet units [example of identified executable entities], every level of a model must be designed with building blocks of the same type (i.e. only Subsystem or only basic blocks).”
Regarding Claim 8
MAAB, in view of Bagge and Ciolfi, teaches: The computer-implemented method of claim 1, wherein an execution relationship exists between at least two of the one or more executable entities, the computer-implemented method further comprising: determining whether the scheduling logic linked to the one or more entry points satisfy the execution relationship between the at least two of the one or more executable entities. (MAAB, § 5.3.3: including “A trigger layer indicates the processing timing by using Triggered Subsystem or Function-Call Subsystem. The blocks should set Priority, if needed…. The priority value must be displayed as a Block Annotation. The user should be able to understand the priority-based order without having to open the block.” Wherein this visually depicts an order of the execution relationship of “Priority = 1”, “2”, “3”, then “4”
as taken in view of Ciolfi, ¶ 74: “The sorted-list of blocks is generated when analyzing the model by using data dependencies among the blocks. The sorted-list [example of the generated execution schedule with the scheduling logic] is then used to create block function execution lists that are used to run the model…. Switching the ordering of Chart1 1005 and Chart2 1010 in the sorted-list will change the result, or answer when FCSS 1015 has blocks with state inside it. Since there are no data dependencies between Chart1 1005 and Chart2 1010, the order is inferred from block priorities when block priorities are specified; otherwise, the block names are used.
The rationale to combine is the same as discussed above with respect to claim 1.
Regarding Claim 9
MAAB, in view of Bagge and Ciolfi, teaches: The computer-implemented method of claim 1, wherein a relationship exists between execution of a given executable entity of the one or more executable entities and a communication of data with the given executable entity, the computer-implemented method further comprising: determining whether the scheduling logic linked to the one or more entry points satisfies the relationship between the execution of the given executable entity and the communication of data with the given executable entity. (MAAB, § 5.3.4: “In case of Type A [using the trigger layer], use a Block Annotation at an Inport block and display its sample time to clarify execution timing of the signal”, wherein as visibly depicted in the figure the “signal” is a data input from the model – i.e .there is a relationship between the “execution” of the given entity and the communication of input data with the given entity
As taken in view of Ciolfi, ¶ 61: “The need for explicit execution control of subgraphs arises in many situations where explicit ordering ( often referred to as sequencing or scheduling) of the subgraphs enables supervisory control. For example, one subgraph may represent activities to be performed at initialization and another subgraph may represent run-time behavior. In the example of FIG. 3A, the initialization subgraph defined by the init Function-Call Subsystem is executed when the system starts up or is reset while running. Within a subgraph that is explicitly controlled, it may further be desired that data dependencies are satisfied ensuring each block within the subgraph is operating on current (e.g., up-to-date) information.”, e.g. ¶ 47: “Simulink 7 .3 will ensure that the output of function of src 125 is executed prior to the output function of chart 105. On a given time-step chart 105 may choose to run f 130 and then immediately run the output and update methods of g 135. In this case, f 130, will see the previous value of output s2 147 (because g's output method has yet to be invoked). g 135 will see the current value of output sl 155 (because f 130 was previously executed).”
The rationale to combine is the same as the one discussed above with respect to claim 1.
Regarding Claim 10
MAAB, in view of Bagge and Ciolfi, teaches:
The computer-implemented method of claim 1, wherein the model component is included in a model, the computer-implemented method further comprising: scheduling an exchange of data between the model and the model component, wherein the exchange of data is coordinated with the execution schedule for the one or more executable entities. (MAAB, § 5.3.4: “In case of Type A [using the trigger layer], use a Block Annotation at an Inport block and display its sample time to clarify execution timing of the signal”, wherein as visibly depicted in the figure the “signal” is a data input from the model
As taken in view of Ciolfi, ¶ 61: “The need for explicit execution control of subgraphs arises in many situations where explicit ordering ( often referred to as sequencing or scheduling) of the subgraphs enables supervisory control. For example, one subgraph may represent activities to be performed at initialization and another subgraph may represent run-time behavior. In the example of FIG. 3A, the initialization subgraph defined by the init Function-Call Subsystem is executed when the system starts up or is reset while running. Within a subgraph that is explicitly controlled, it may further be desired that data dependencies are satisfied ensuring each block within the subgraph is operating on current (e.g., up-to-date) information.”, e.g. ¶ 47: “Simulink 7 .3 will ensure that the output of function of src 125 is executed prior to the output function of chart 105. On a given time-step chart 105 may choose to run f 130 and then immediately run the output and update methods of g 135. In this case, f 130, will see the previous value of output s2 147 (because g's output method has yet to be invoked). g 135 will see the current value of output sl 155 (because f 130 was previously executed).”
The rationale to combine is the same as the one discussed above with respect to claim 1.
Regarding Claim 11
MAAB, in view of Bagge and Ciolfi, teaches: The computer-implemented method of claim 1, wherein a constraint exists on a given executable entity of the one or more executable entities, the computer-implemented method further comprising: determining whether the scheduling logic linked to the one or more entry points satisfy the constraint on the given executable entity. (MAAB, § 5.3.3 as discussed above including: “A trigger layer indicates the processing timing by using Triggered Subsystem or Function-Call Subsystem…”
As taken in view of Ciolfi, ¶¶ 129-130: “Threading may introduce a new constraint on data signals, such as the need to ensure deterministic execution… In FIG. 23 did not require a synchronization block between fl 2312 and f3 2316 which is running in a different thread because fl will have finished execution before f3 starts running. This synchronization is achieved by 2329 which executes its bottom branch fl 2312 prior to executing is right-most branch 2331… The sync block 2320 is a Function-Call Synchronization ( or more generally a Control Signal Synchronization) block that is used to synchronize the child thread containing f3 with the main thread 2328. The Function-Call Subsystem f4 2318, cannot start processing until both f2 2134 and f3 2316 is complete. If Function-Call Subsystem f2 2314 finishes before f3 2316 is complete, then the sync block 2320 will cause the main thread 2328 to wait for the child thread 2330 of f2 2314”
The rationale to combine is the same as the one discussed above with respect to claim 1.
Regarding Claim 12
MAAB, in view of Bagge and Ciolfi, teaches:
The computer-implemented method of claim 1, wherein the model component includes a first hierarchical level and a second hierarchical level, the one or more executable entities include a first executable entity with a first entry point and a second executable entity with a second entry point, the first executable entity is at the first hierarchical level, the second executable entity is at the second hierarchical level, and the computer-implemented method further comprising: aggregating the first entry point for the first executable entity with the second entry point for the second executable entity. (MAAB, § 5.3.1: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level… Trigger layer… Structure layer… Data flow layer”, then see §§ 5.3.4: “A subsystem of a structure layer should be an atomic subsystem”, then see § 5.2 “Subsystem Hierarchies” and § 5.2.1 “Similar block types on the model levels” which describes: “To allow partitioning of the model into discreet units, every level of a model must be designed with building blocks of the same type (i.e. only Subsystem or only basic blocks). The blocks listed in this rule are used for signal routing. You can place them at any level of the model.”; then see § 5.2.2: “Blocks in a Simulink diagram should be grouped together into subsystems based on functional decomposition of the algorithm, or portion thereof, represented in the diagram…” – to clarify, see the figure in § 5.3.1 which visually depicts two levels in the Structure layer of executable entities, to be specific the first level is the block around the smaller blocks, and the second level is the smaller blocks that were “grouped together” into the larger block
As taken in view of Ciolfi, ¶ 142: “…If the Function-Call Split block is connected to a Function- Call Subsystems, then the object will aggregate the runtime methods of both subsystems”
The rationale to combine is the same as the one discussed above with respect to claim 1.
Regarding Claim 13
Claim 13 is rejected under a similar rationale as claim 1, wherein MAAB, in view of Ciolfi and Bagge, teaches: One or more non-transitory computer-readable media, having stored thereon instructions that when executed by a computing device, cause the computing device to perform operations comprising: (MAAB, § 3 describes the “Software Environment” for the guidelines)
Regarding Claim 14
This claim is rejected under a similar rationale as claim 2.
Regarding Claim 15
This claim is rejected under a similar rationale as claim 3.
Regarding Claim 16
This claim is rejected under a similar rationale as claim 4.
Regarding Claim 19
This claim is rejected under a similar rationale as claim 7 as discussed above.
Regarding Claim 20
This claim is rejected under a similar rationale as claim 8 as discussed above.
Regarding Claim 21
This claim is rejected under a similar rationale as claim 9 as discussed above.
Regarding Claim 22
This claim is rejected under a similar rationale as claim 10 as discussed above.
Regarding Claim 23
This claim is rejected under a similar rationale as claim 11 as discussed above.
Regarding Claim 24
This claim is rejected under a similar rationale as claim 12 as discussed above.
Regarding Claim 25
Claim 13 is rejected under a similar rationale as claim 1, wherein MAAB, in view of Ciolfi and Bagge, teaches: An apparatus comprising: a memory storing a model component, the model component including one or more executable entities and defining a functional behavior; and one or more processors coupled to the memory, the one or more processors configured to: (MAAB, § 3 describes the “Software Environment” for the guidelines; MAAB, § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.”
Then see the figure in § 5.3 – the lower levels below the trigger layer comprise model components with executable entities, e.g. see § 5.3.4 for its description of the “Structure Layer” including its figures which give examples of model “Component[s]” visually. To clarify on the BRI, the Examiner notes that MAAB is describing models in Simulink, which is the exemplary modeling environment of the instant disclosed invention (page 43, ¶ 3 of the instant disclosure; as well as pages 43-44, and page 16 ¶ 1))
Regarding Claim 26
This claim is rejected under a similar rationale as claim 12 as discussed above.
Claim(s) 5-6, 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over MathWorks Automotive Advisory Board (MAAB), “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB ® , Simulink ® , and Stateflow ® Version 3.0”, Aug. 2012, URL: www(dot)mathworks(dot)com/solutions/mab-guidelines/previous-versions(dot)html, in view of Bagge et al., “Interfacing Concepts Why Declaration Style Shouldn’t Matter”, 2010, and in further view of Ciolfi et al., US 2010/0153910, and in further view of MathWorks, “Simulink, Dynamic System Simulation for MATLAB, Using Simulink, Version 3”, 1999, accessed via URL: wcsp(dot)eng(dot)usf(dot)edu/courses/DSPLab/sl_using(dot)pdf
Regarding Claim 5
MAAB, as was taken in view of Bagge and Ciolfi above, does not explicitly teach:
The computer-implemented method of claim 1, further comprising:
presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the one or more executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the one or more executable entities.
MAAB, as was taken in view of Bagge and Ciolfi above, and in further view of MathWorks, teaches: presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the one or more executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the one or more executable entities. (MAAB, as was discussed above including § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.” Then § 5.3.3: “A trigger layer indicates the processing timing [example of linked scheduling logic included in the model – see the figures to clarify] by using Triggered Subsystem or Function-Call Subsystem. The blocks should set Priority, if needed. The priority value must be displayed as a Block Annotation. The user should be able to understand the priority-based order without having to open the block.” – then, see the figures in §§ 5.3.1 and 5.3.3 as reproduced below, wherein the Examiner provided clarifying annotations; to clarify, § 7.1.9: “The Trigger port is also the function-call block.” – i.e. the second call style is trigger/function call; and the first call style is rate-based (e.g. “8ms” or “Task4ms”) or an “Event”;
As taken in view of Mathworks, page 7-9, section “Creating a Triggered Subsystem”, wherein this shows the dialog box reproduced below which lists “Trigger Type” wherein the type is the call style, e.g. “rising” or “function-call” may be selected by the user, wherein the “rising” signal is also an example of an event-based call style when read in view of page 8-106: “Resets the states to their initial conditions when a trigger event (rising, falling, or either) occurs in the reset signal.” – see page 7-2 to clarify: “A triggered subsystem executes once each time a “trigger event” occurs. A trigger event can occur on the rising or falling edge of a trigger signal, which can be continuous or discrete.” - to clarify on the BRI, page 10 line 23 of the instant disclosure: “event-triggered subsystems” and page 25 ¶ 2: “explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers”
PNG
media_image8.png
200
400
media_image8.png
Greyscale
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 MAAB, as was modified above, on the “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB” (MAAB, title) including its teachings on “ Control models are organized using the following hierarchical structure” (MAAB, § 5.3 and its subsections) with the teachings MathWorks on user interfaces associated with triggered subsystems. The motivation to combine would have been that “Simulink encourages you to try things out. You can easily build models from scratch, or take an existing model and add to it. Simulations are interactive, so you can change parameters “on the fly” and immediately see what happen… After you define a model, you can simulate it, using a choice of integration methods, either from the Simulink menus or by entering commands in MATLAB’s command window. The menus are particularly convenient for interactive work,…” (MathWorks, page 1-2 to 1-3).
Regarding Claim 6
MAAB, as was taken in view of Bagge and Ciolfi above, does not explicitly teach:
The computer-implemented method of claim 3, further comprising:
presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the one or more executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the one or more executable entities;
and determining whether to expose, in the graphical interface, a given entry point for a given executable entity of the one or more executable entities based on one or more selections entered in the dialog window.
MAAB, as was taken in view of Bagge and Ciolfi above, and in further view of MathWorks, teaches: The computer-implemented method of claim 3, further comprising: presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the one or more executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the one or more executable entities; and determining whether to expose, in the graphical interface, a given entry point for a given executable entity of the one or more executable entities based on one or more selections entered in the dialog window. (MAAB, as was discussed above including § 5.3: “Control models are organized using the following hierarchical structure. Details on each layer are provided in the latter rules … Top layer / root level … Trigger layer … Structure layer …Data flow layer …Use of the Trigger level is optional. In the diagram below “Type A” shows the use of a trigger level while “Type B“ shows a model without a trigger level.” Then § 5.3.3: “A trigger layer indicates the processing timing [example of linked scheduling logic included in the model – see the figures to clarify] by using Triggered Subsystem or Function-Call Subsystem. The blocks should set Priority, if needed. The priority value must be displayed as a Block Annotation. The user should be able to understand the priority-based order without having to open the block.” – then, see the figures in §§ 5.3.1 and 5.3.3 as reproduced below, wherein the Examiner provided clarifying annotations; to clarify, § 7.1.9: “The Trigger port is also the function-call block.” – i.e. the second call style is trigger/function call; and the first call style is rate-based (e.g. “8ms” or “Task4ms”) or an “Event”;
As taken in view of Mathworks, page 7-9, section “Creating a Triggered Subsystem”, wherein this shows the dialog box reproduced below which lists “Trigger Type” wherein the type is the call style, e.g. “rising” or “function-call” may be selected by the user, wherein the “rising” signal is also an example of an event-based call style when read in view of page 8-106: “Resets the states to their initial conditions when a trigger event (rising, falling, or either) occurs in the reset signal.” – see page 7-2 to clarify: “A triggered subsystem executes once each time a “trigger event” occurs. A trigger event can occur on the rising or falling edge of a trigger signal, which can be continuous or discrete.” - to clarify on the BRI, page 10 line 23 of the instant disclosure: “event-triggered subsystems” and page 25 ¶ 2: “explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers”
With respect to exposing an entry point based on the selection, page 7-9: “Simulink uses different symbols on the Trigger and Subsystem blocks to indicate [expose] rising and falling triggers (or either) [based on the selection]. This figure shows the trigger symbols on Subsystem blocks”, in addition the Examiner notes that when POSITA took MAAB, § 6.3.5 for its visual depiction of a function call symbol on a subsystem in view of MathWorks teachings on page 7-9, a skilled person would have found it obvious, that when “function-call” was selected as the “Trigger type” to have used the symbol style of MAAB because this would have been “Combining Prior Art Elements According to Known Methods To Yield Predictable Results” as discussed in MPEP § 2143 as this would have merely been using the symbol shown in MAAB to perform its same function of depicting a function call subsystem visually in Simulink when the trigger type was set to “function call” by the selection of MathWorks
PNG
media_image8.png
200
400
media_image8.png
Greyscale
PNG
media_image9.png
49
195
media_image9.png
Greyscale
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 MAAB, as was modified above, on the “CONTROL ALGORITHM MODELING GUIDELINES USING MATLAB” (MAAB, title) including its teachings on “ Control models are organized using the following hierarchical structure” (MAAB, § 5.3 and its subsections) with the teachings MathWorks on user interfaces associated with triggered subsystems. The motivation to combine would have been that “Simulink encourages you to try things out. You can easily build models from scratch, or take an existing model and add to it. Simulations are interactive, so you can change parameters “on the fly” and immediately see what happen… After you define a model, you can simulate it, using a choice of integration methods, either from the Simulink menus or by entering commands in MATLAB’s command window. The menus are particularly convenient for interactive work,…” (MathWorks, page 1-2 to 1-3).
Regarding Claim 17
This claim is rejected under a similar rationale as claim 5 above.
Regarding Claim 18
This claim is rejected under a similar rationale as claim 6 above.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-4, 7, 9-16, 19, 21-26 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090.
Claims 5-6, 17-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090 in view of MathWorks, “Simulink, Dynamic System Simulation for MATLAB, Using Simulink, Version 3”, 1999, accessed via URL: wcsp(dot)eng(dot)usf(dot)edu/courses/DSPLab/sl_using(dot)pdf
Claims 8 and 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 11, 12-14, 17-18, 19, 31-33, 41 of U.S. Patent No. 11,244,090 in view of Resmerita et al., US 2012/0310620
Claims 13 and 20, and the dependents thereof, are rejected under a similar rationale as claim 1, and the dependents thereof.
Although the claims at issue are not identical, they are not patentably distinct from each other because these claimed inventions are obvious variations of each other, including:
Instant claim 1 recites a feature of “providing…an interface…” – this is an obvious variation of the “adaptation layer” feature in claim 11 of the ‘090, wherein the ‘090 claim 11 clarifies: “where the one or more adjustable attributes include an entry point for invoking execution of the at least one of the plurality of executable entities;”
Instant claim 1 recites a “linking scheduling logic… translating the first call style implemented by the scheduling logic” feature – this is an obvious variation of claim 11 of the ‘090 recitation of “binding to the entry point…logic… wherein at least a portion of the logic explicitly included in the graphical model and linked to the one or more graphical affordances implements a first call style that differs from a second call style associated with the at least one of the plurality of executable entities and the first call style or the second call style includes at least one of: (i) rate-based, (ii) event-based, (iii) function-call, or (iv) triggered;”
To clarify on the negative limitation in instant claim 1, this would have been obvious/inferred because the ‘090 claim 1 does not recite a step of altering the functional behavior of the model component
Instant claims 1, 13, and 25 are rejected in view of claims 11, 31, and 41 of the ‘090, as being obvious variations – specifically, a computer-implemented method, a computer implementing the method, and a computer readable storage medium storing instructions for the method for implementation are obvious variations of each other to a skilled person.
Instant independent claims require that one of the four call styles is triggered based on a rising/falling edge, however this is not required to be selected in the group (i.e. note it’s a list of 4 items, and only 2 of them need to be picked)
Regarding Claims 5 and 17
Claim 17 is rejected under a similar rationale as claim 5:
While the ‘090 claimed invention does not recite the following limitation, the ‘090 claimed invention, when taken in view of MathWorks, teaches: The computer-implemented method of claim 1, further comprising: presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the executable entities. (The ‘090 claimed invention, as taken in view of Mathworks, page 7-9, section “Creating a Triggered Subsystem”, wherein this shows the dialog box reproduced below which lists “Trigger Type” wherein the type is the call style, e.g. “rising” or “function-call” may be selected by the user, wherein the “rising” signal is also an example of an event-based call style when read in view of page 8-106: “Resets the states to their initial conditions when a trigger event (rising, falling, or either) occurs in the reset signal.” – see page 7-2 to clarify: “A triggered subsystem executes once each time a “trigger event” occurs. A trigger event can occur on the rising or falling edge of a trigger signal, which can be continuous or discrete.” - to clarify on the BRI, page 10 line 23 of the instant disclosure: “event-triggered subsystems” and page 25 ¶ 2: “explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers”
PNG
media_image8.png
200
400
media_image8.png
Greyscale
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 the ‘090 claimed invention with the teachings from MathWorks on user interfaces associated with triggered subsystems. The motivation to combine would have been that “Simulink encourages you to try things out. You can easily build models from scratch, or take an existing model and add to it. Simulations are interactive, so you can change parameters “on the fly” and immediately see what happen… After you define a model, you can simulate it, using a choice of integration methods, either from the Simulink menus or by entering commands in MATLAB’s command window. The menus are particularly convenient for interactive work,…” (MathWorks, page 1-2 to 1-3).
Regarding Claims 6 and 18
Claim 18 is rejected under a similar rationale as claim 6:
While the ‘090 claimed invention does not recite the following limitation, the ‘090 claimed invention, when taken in view of MathWorks, teaches: The computer-implemented method of claim 3, further comprising:
presenting a dialog window providing a user interface element for either (i) selecting a given call style for a first executable entity of the executable entities of the model component or (ii) aggregating an entry point for the first executable entity with an entry point for a second executable entity of the executable entities; and determining whether to expose, in the graphical interface, a given entry point for a given executable entity of the executable entities based on one or more selections entered in the dialog window.(The ‘090 claimed invention, As taken in view of MathWorks, page 7-9, section “Creating a Triggered Subsystem”, wherein this shows the dialog box reproduced below which lists “Trigger Type” wherein the type is the call style, e.g. “rising” or “function-call” may be selected by the user, wherein the “rising” signal is also an example of an event-based call style when read in view of page 8-106: “Resets the states to their initial conditions when a trigger event (rising, falling, or either) occurs in the reset signal.” – see page 7-2 to clarify: “A triggered subsystem executes once each time a “trigger event” occurs. A trigger event can occur on the rising or falling edge of a trigger signal, which can be continuous or discrete.” - to clarify on the BRI, page 10 line 23 of the instant disclosure: “event-triggered subsystems” and page 25 ¶ 2: “explicit events, such as function calls or messages, or implicit events, such as trigger signals or periodic timers”
With respect to exposing an entry point based on the selection, page 7-9: “Simulink uses different symbols on the Trigger and Subsystem blocks to indicate [expose] rising and falling triggers (or either) [based on the selection]. This figure shows the trigger symbols on Subsystem blocks”
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 the ‘090 claimed invention with the teachings from MathWorks on user interfaces associated with triggered subsystems. The motivation to combine would have been that “Simulink encourages you to try things out. You can easily build models from scratch, or take an existing model and add to it. Simulations are interactive, so you can change parameters “on the fly” and immediately see what happen… After you define a model, you can simulate it, using a choice of integration methods, either from the Simulink menus or by entering commands in MATLAB’s command window. The menus are particularly convenient for interactive work,…” (MathWorks, page 1-2 to 1-3).
Regarding Claims 8 and 20
Claim 20 is rejected under a similar rationale as claim 8:
While the ‘090 claimed invention does not recite the following limitation, the ‘090 claimed invention, when taken in view of Resmerita, teaches: The computer-implemented method of claim 1, wherein an execution relationship exists between at least two of the one or more executable entities, the computer-implemented method further comprising: determining whether the scheduling logic linked to the one or more entry points satisfy the execution relationship between the at least two of the one or more executable entities. (Resmerita, see the abstract: “…The application software has tasks of different priority and a set of instructions. An access point is defined for each task at an instruction representing an entry point of a task, a termination point of a task, an access to shared memory, an access to a register of the target hardware platform, and/or a system call or a driver function call, thus dividing the tasks into consecutive instruction blocks…”; see ¶¶ 47-53 including: “…An "access point" as mentioned above is a line of source code representing Either [0048] (a) the beginning of a task, i.e. the first line of program code of the unit,[0049] (b) an end of a task, i.e., a return instruction from the task…” – i.e. there are “consecutive…blocks” with an execution relationship between the blocks [e.g. a “consecutive” relationship]
see ¶ 62: “FIG. 4b illustrates, as an example, the execution of the two tasks T and T' on the target platform: T is triggered at time t0 and T' is triggered at time t1 . As task T' is assumed to have higher priority, it preempts the execution [example of determining the scheduling logic satisfies an execution relationship, and using the results of the determination] of the first part of the code of task T (assumingthatt1 <t0 +1\ 1). Thus, the value of the global variable v provided by T' at time t2 (t2=t1 +112 ) is read by the first task T at time t4 (t4 =t0 +01 +l\2 +1\ 3). The smaller boxes within the rectangles representing the tasks T and T' schematically illustrate the execution of single lines of code in the source code of each task… It should be noted that the position in the source code ( at the beginning of the second SEB of each task) and the corresponding time when that line of code is executed are independent as the scheduling of the tasks determines when a task is interrupted and when it resumes its execution.”
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 ‘090 claimed invention with the teachings from Resmerita on “Computer-based simulation of a real time system which includes an application software to be executed on a target hardware platform (hardware and operating system) The application software has tasks of different priority and a set of instructions. An access point is defined for each task at an instruction representing an entry point of a task…” (Resmerita, abstract) The motivation to combine would have been that “It is accordingly an object of the invention to provide a simulation method and device which overcome the above-mentioned disadvantages of the heretofore-known devices and methods of this general type and which provides for improved simulation that exhibits timing behavior as close to the execution platform behavior as possible, but is much faster than an instruction set simulator”
To clarify, also see ¶ 33: “…Control engineers are often provided with a plant simulator ( e.g., a MATLAB/Simulink model), which simulates the behavior of the plant as good as necessary by executing a software program on a personal computer or on a specialized real-time computer…”
Application # 17/536,660
U.S. Patent No. 11244090
Regarding Claim 1
A computer-implemented method comprising:
accessing, from a memory, a model component, the model component including one or more executable entities, each executable entity comprising a subsystem, a sub-model, or a group of model elements configured to be invoked as a unit using a particular call style, wherein the model component defines a functional behavior;
providing, by one or more processors coupled to the memory, an interface associated with the model component, wherein the interface includes one or more entry points for the one or more executable entities included in the model component;
linking scheduling logic to the one or more entry points of the interface, wherein the scheduling logic is included within a model that includes the model component, and the scheduling logic implements a first call style that is different than a second call style used to invoke execution of the one or more executable entities as the unit and the first call style and the second call style are one of: (i) rate-based, (ii) event-based, (iii) function-call, or (iv) triggered based on a falling edge and/or a rising edge; translating the first call style implemented by the scheduling logic included in the model to the second call style associated with the one or more executable entities to execute the one or more executable entities of the model component as included in the model consistent with the second call style associated with the one or more executable entities, the translating performed without altering the functional behavior of the model component;
wherein an execution schedule for the one or more executable entities of the model component, based on the scheduling logic linked to the one or more entry points included in the interface associated with the model component as included in the model, is at least one of generated and utilized during execution of at least the model component, or implemented in ode generated for at least the model component.
Regarding Claim 11.
A method comprising:
for a graphical model component that includes executable entities, partitioning the graphical model component into the plurality of executable entities;
automatically identifying based on an analysis of the graphical model component one or more adjustable attributes of at least one of the plurality of executable entities, where the one or more adjustable attributes include an entry point for invoking execution of the at least one of the plurality of executable entities;
establishing, by one or more processors, an adaptation layer for the graphical model component, where the adaptation layer includes one or more access points that correspond to the one or more the adjustable attributes of the at least one of the plurality of executable entities;
presenting the one or more access points included in the adaptation layer through one or more graphical affordances included within a graphical model;
binding to the entry point, by the one or more processors, logic explicitly included in the graphical model and linked to the one or more graphical affordances which correspond to the one or more adjustable attributes of the at least one of the plurality of executable entities, wherein at least a portion of the logic explicitly included in the graphical model and linked to the one or more graphical affordances implements a first call style that differs from a second call style associated with the at least one of the plurality of executable entities and the first call style or the second call style includes at least one of:
(i) rate-based, (ii) event-based, (iii) function-call, or (iv) triggered;
and at least one of utilizing the logic explicitly included in the graphical model and linked to the one or more graphical affordances to generate an execution schedule for the at least one of the plurality of executable entities,
or generating code for the graphical model component, wherein the generated code includes one or more code sections implementing the logic explicitly included in the graphical model and linked to the one or more graphical affordances to generate the execution schedule for the at least one of the plurality of executable entities.
Regarding Claim 2
The computer-implemented method of claim 1, wherein the scheduling logic linked to the one or more entry points is described textually.
Regarding Claim 14.
The method of claim 11, wherein the logic explicitly included in the graphical model and linked to the graphical affordances is user-specified. – it would have been obvious to have the user specify via text input
Regarding Claim 3
The computer-implemented method of claim 1, wherein the interface is a graphical interface that includes one or more graphical affordances associated with the entry points for the one or more executable entities, the computer-implemented method further comprising:
presenting on a display, by the one or more processors, the model component and the graphical interface, wherein the scheduling logic is described by one or more model elements presented on the display, the one or more model elements connected to the one or more graphical affordances included in the graphical interface.
Regarding Claim 11.
… where the one or more adjustable attributes include an entry point for invoking execution of the at least one of the plurality of executable entities;
establishing, by one or more processors, an adaptation layer for the graphical model component, where the adaptation layer includes one or more access points that correspond to the one or more the adjustable attributes of the at least one of the plurality of executable entities;
presenting the one or more access points included in the adaptation layer through one or more graphical affordances included within a graphical model;
binding to the entry point, by the one or more processors, logic explicitly included in the graphical model and linked to the one or more graphical affordances which correspond to the one or more adjustable attributes of the at least one of the plurality of executable entities, wherein at least a portion of the logic explicitly included in the graphical model and linked to the one or more graphical affordances…
Regarding Claim 17.
The method of claim 14, wherein the user-specified logic is included in a parent model that includes the graphical model component, and the user-specified logic is graphically connected to the graphical affordances through which the access points are exposed.
Regarding Claim 4
The computer-implemented method of claim 3, wherein the one or more graphical affordances included in the graphical interface of the model component is one or more of a port, an access point or a call site.
Regarding Claim 17.
The method of claim 14, wherein the user-specified logic is included in a parent model that includes the graphical model component, and the user-specified logic is graphically connected to the graphical affordances through which the access points are exposed.
Regarding Claim 7
The computer-implemented method of claim 1, further comprising:
partitioning the model component to identify the one or more executable entities, wherein the partitioning is performed automatically or under user direction.
Regarding Claim 11.
…partitioning the graphical model component into the plurality of executable entities…
Regarding Claim 9
The computer-implemented method of claim 1, wherein a relationship exists between execution of a given executable entity of the one or more executable entities and a communication of data with the given executable entity, the computer-implemented method further comprising:
determining whether the scheduling logic linked to the one or more entry points satisfies the relationship between the execution of the given executable entity and the communication of data with the given executable entity.
Regarding Claim 13.
The method of claim 12, further comprising: coordinating the execution schedule with an exchange of data with the graphical model component. – a skilled person would have found claim 9 to be an obvious variation of the ‘090 claim 13, because this is “coordinating the execution section with an exchange of data” – i.e. they would have found obvious, or at least inferred, to have ensured that the execution of the entity and communication of data were coordinated correctly
Regarding Claim 10.
The computer-implemented method of claim 1, wherein the model component is included in a model, the computer-implemented method further comprising:
scheduling an exchange of data between the model and the model component, wherein the exchange of data is coordinated with the execution schedule for the one or more executable entities.
Regarding Claim 13.
The method of claim 12, further comprising:
coordinating the execution schedule with an exchange of data with the graphical model component.
Regarding Claim 11.
The computer-implemented method of claim 1, wherein a constraint exists on a given executable entity of the one or more executable entities, the computer-implemented method further comprising:
determining whether the scheduling logic linked to the one or more entry points satisfy the constraint on the given executable entity.
Regarding Claim 13.
The method of claim 12, further comprising: coordinating the execution schedule with an exchange of data with the graphical model component. – a skilled person would have found claim 11 to be an obvious variation of the ‘090 claim 13, because this is “coordinating the execution section with an exchange of data” – which they would have inferred, or at least found obvious, included constraints on the coordination which were satisfied
Regarding Claim 12.
The computer-implemented method of claim 1, wherein the model component includes a first hierarchical level and a second hierarchical level, the one or more executable entities include a first executable entity with a first entry point and a second executable entity with a second entry point, the first executable entity is at the first hierarchical level, the second executable entity is at the second hierarchical level, and the computer- implemented method further comprising:
aggregating the first entry point for the first executable entity with the second entry point for the second executable entity.
Regarding Claim 19.
The method of claim 11, wherein the graphical model component is included in a model having hierarchical levels and the graphical model component is included in a second graphical model component that is in a higher hierarchical level than the graphical model component, the method further comprising:
aggregating a given access point of the graphical model component with an access point of the second graphical model component that includes the graphical model component.
To clarify, claim 11: “…include an entry point for invoking execution of the at least one of the plurality of executable entities;
establishing, by one or more processors, an adaptation layer for the graphical model component, where the adaptation layer includes one or more access points that correspond to the one or more the adjustable attributes of the at least one of the plurality of executable entities…”
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID A. HOPKINS whose telephone number is (571)272-0537. The examiner can normally be reached Monday to Friday, 10AM to 7 PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Pitaro can be reached at (571) 272-4071. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/David A Hopkins/Primary Examiner, Art Unit 2188