DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Election/Restrictions
Applicant’s election without traverse of Group II (claims 19-34) in the reply filed on 03/16/2026 is acknowledged.
Claims 1-18 and 35-46 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to nonelected inventions, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on 03/16/2026.
Priority
Application 18858935 is a national-stage application of PCT/EP2022/060757 filed on 04/22/2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 10/22/2024 and 07/23/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Specification
The specification is objected to because: the use of the terms Intel, ARM, Nvidia, and Blu-ray, which are trade names or marks used in commerce, has been noted in this application. See in particular pages 19 and 23. The terms should be accompanied by the generic terminology; furthermore, the terms should be capitalized wherever they appear or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 19, 21, 25, and 29 are objected to because of the following informalities:
In claims 19 and 21, “behavior; operating” should read “behavior; and operating”; “ceased; ceasing” should read “ceased; and ceasing”; and “started; starting” should read “started; and starting” for clarity.
Claim 21 recites “starting execution of one or more third additional executables” even though the claim only recites “determining one or more second additional executables… to be started.” It appears that “starting execution of one or more third additional executables” should read “starting execution of the one or more second additional executables”.
In claim 25, “executables; permanently” should read “executables; or permanently”.
In claim 29, “the first and second transition trigger” should read “the first and second transition triggers”.
Appropriate correction is required.
Claim Interpretation
Claim 19 recites “determining one or more first additional executables of the second set of interdependent executables” and “starting execution of the one or more first additional executables”. Claim 21 recites “receiving… second data from one or more executables of the second set of interdependent executables;” and “determining one or more executables of the second set of interdependent executables… to be ceased”. In view of pages 10 and 12 of the specification, the “one or more first additional executables” and each instance of “one or more executables of the second set of interdependent executables” as quoted above are interpreted as referring to non-exclusive subsets of the second set of interdependent executables. In other words, the first additional executables, the executables sending second data, and the executables to be ceased may refer to the same, some of the same, or completely different executables.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 29 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 29 recites the limitations “the first and second transition trigger” and “the received first or second data”. There is insufficient antecedent basis for these limitations in the claim. Second data and a second transition trigger have not been previously recited in claim 29 or claim 19, upon which claim 29 depends. Therefore, the limitations render the claim indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 34 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim does not fall within at least one of the four categories of patent eligible subject matter because the claim is directed to “a computer program” which, under a broadest reasonable interpretation and in light of pages 29-31 of the specification, can be interpreted as software (software per se). The court has found that software, expressed as code or a set of instructions detached from any medium is an idea without physical embodiment, does not fall within any statutory category. See Microsoft Corp. v. AT&T Corp., 550 U.S. 437, 449, 82 USPQ2d 1400, 1407 (2007); see also Benson, 409 U.S. 67, 175 USPQ2d 675 (An "idea" is not patent eligible). Thus, a product claim to a software program that does not also contain at least one structural limitation (such as a "means plus function" limitation) has no physical or tangible form, and thus does not fall within any statutory category. See MPEP 2106.03.
This rejection can be overcome by amending “A computer program” to “A non-transitory computer-readable medium” as supported by page 30, lines 21-34 of the specification.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 19-24, 26-29, and 33-34 are rejected under 35 U.S.C. 103 as being unpatentable over Oliver et al. (US 20230089528 A1, effectively filed 09/14/2021; hereafter “Oliver”) in view of Theobald (US 10168699 B1, effectively filed 11/23/2021).
Regarding claim 19, Oliver discloses
A method for operating a robotic system, the robotic system… operably connected to memory and processing circuitry (See an automotive computer system comprising “one or multiple processing cores” (processing circuitry) and memory [0164] for executing software components to accomplish autonomous driving features; see [0158] and [0011]. See also [0009], [0013], and [0267]. See also claims 1, 8, and 9.), the method comprising:
operating the robotic system in a first non-deterministic and adaptable behavior by executing a first set of interdependent executables, each executable of the first set of executables implementing a functional element of the first non-deterministic and adaptable behavior (See an “initial configuration [of] an automotive computer system as described, wherein the active mode is MODE A” (first non-deterministic and adaptable behavior) [0287]. “A mode is characterized by a so-called mode definition, comprising… a set of references to software components [interdependent executables] from the set of defined software components, wherein when a mode is active, all listed software components of said mode are running in one or more processing cores of the set of processing cores of the computer system” [0171-0173]. A person of ordinary skill in the art would recognize that needing to run the specified list of software components for a mode (see Table 2) is an indication that each software component (executable) implements a functional element of the mode, particularly because unneeded software components are de-initialized and corresponding resources un-registered [0179-0186]. The non-deterministic and adaptable behaviors/modes include “motorway driving,” “urban driving, parking, off-road driving, or traffic jam driving” [0014] performed by functions including lane centering assistance (LCA), collision avoidance system (CAS), traffic sign recognition (TSR), autopilot, automatic parking system (APS), and adaptive cruise control (ACC); see [0011] and [0013]. See also [0158] and [0276].);
receiving, by a first monitoring executable associated with the first non-deterministic and adaptable behavior, first data… (See “wherein said first function running in processing core C1 is configured to detect a[n] input [first data], for example, the selection of an entry in a menu on a touch screen;” the first function monitors for an input [0287]. This first function begins the transition from MODE A to MODE B [0287], so the first function is associated with the first non-deterministic and adaptable behavior (MODE A). The first function is an executable or is contained within an executable: “first, second, third, and/or fourth functions are implemented in software components, …wherein said software components are included in the set of software components in the computer system, and wherein at least one or more of said software components are included in the set of software components for each transition definition in said computer system” [0132]. The second, third, and fourth functions could also be considered a first monitoring executable. See also Figs. 1-4, [0133], and [0198-0205].);
analyzing the received first data (See “wherein said first function running in processing core C1 is configured to detect a[n] input, for example, the selection of an entry in a menu on a touch screen, wherein said entry allows activating a trajectory planning function” [0287]. See also [0199-0205].);
generating, by the first monitoring executable associated with the first non-deterministic and adaptable behavior, based on the analyzing the received first data, a first transition trigger (See “wherein said first function running in processing core C1 is configured to detect a[n] input, for example, the selection of an entry in a menu on a touch screen, wherein said entry allows activating a trajectory planning function, causing said first function to send a request [generate a first transition trigger] to said second function to transition to mode MODE B, via an m0-message, wherein the type of said m0-message is REQUEST, and wherein the reference to MODE B and the optional activation point in time T1 are provided, following the workflow depicted in FIG. 1” [0287]. See also [0199-0206].);
transitioning, based on the first transition trigger, the robotic system into a second non-deterministic and adaptable behavior (After a series of processes triggered by the m0-message of the first function above, fourth functions “compute the changes in the configuration of the processing cores so that the software components which have to run in the new mode, MODE B, can be activated, wherein said computation is based on the current active mode, MODE A, and… wherein each said fourth function execute said computed changes” to transition from MODE A to MODE B [0290-0300]. MODE B is the second non-deterministic and adaptable behavior. See also Fig. 4, [0158], [0175-0186], and [0198-0262], and in particular [0235-0243].);
operating the robotic system in the second non-deterministic and adaptable behavior by executing a second set of interdependent executables by: determining one or more executables of the first set of interdependent executables of the first non-deterministic and adaptable behavior to be ceased; ceasing execution of the one or more executables of the first set of interdependent executables of the first non-deterministic and adaptable behavior determined to be ceased (The fourth functions “compute [determine] the changes in the configuration of the processing cores… based on the specific actions in the mode transition definition” from the first behavior to the second behavior [0290]. Those actions can include “de-initializ[ing] a software component of the set of software components in the current, old, mode” (first behavior) [0179-0180]. For example, based on Table 3, the transitions from MODE B to MODE C and MODE C to MODE A include deinitializing (ceasing execution) software components SWC3 or SWC4 (executables) [0278-0285]. See also [0179-0186], [0235-0262], [0290-0300], and Table 2.); and / or
determining one or more first additional executables of the second set of interdependent executables of the second non-deterministic and adaptable behavior to be started; starting execution of the one or more first additional executables associated with the second non-deterministic and adaptable behavior to be started (The fourth functions “compute [determine] the changes in the configuration of the processing cores so that the software components which have to run in the new mode, MODE B, can be activated, wherein said computation is based on the current active mode, MODE A, and wherein said computation is additionally based on the specific actions in the mode transition definition T-AB, and… wherein the fourth function running in processing core C1 computes necessary changes, wherein said changes comprise initialize SWC3… and wherein each said fourth function execute said computed changes” [0290-0300]. See also [0179-0186], [0235-0262], [0278-0284], and Table 3.).
However, Oliver does not explicitly teach “the robotic system comprising one or more sensors and actuators operably connected to memory and processing circuitry,” and “receiving, by a first monitoring executable associated with the first non-deterministic and adaptable behavior, first data from one or more executables of the first set of interdependent executables.”
Theobald, in the same field of endeavor (autonomous mobile robots), teaches
the robotic system comprising one or more sensors and actuators operably connected to memory and processing circuitry (See a mobile robot 20 having a sensor system 30 comprising at least two sensors 38 and drive system 34 “in signal communication” with controller 36 comprising memory 54 and processing device 56 in Fig. 9 [col. 4, line 41 to col. 5, line 9]. Drive system 34 includes wheels 50 “driven by at least one motor” and/or “a plurality of motorized… track systems 52” [col. 6, lines 4-29]. Note the communication system 32 may also include sensors, e.g., a receiver 42 [col. 5, lines 10-23].),
operating the robotic system in a first non-deterministic and adaptable behavior… (See “the mobile robot 20 may be configured as an autonomous mobile robot that performs one [or] more of its tasks” by determining and performing the operations “necessary to complete the task based on, for example, its current location, surrounding obstacles, its operating environment 22, the type of task to be performed, etc. The mobile robot 20 may also adapt to unknown, new and/or changing operating environments” [col. 4, lines 3-15]. Because these variables (e.g., obstacles and operating environment) are non-deterministic, the behavior of the mobile robot 20 is non-deterministic and adaptable. See also col. 1, line 66 to col. 2, line 14 and col. 8, lines 1-43.)
receiving, by a first monitoring executable associated with the first non-deterministic and adaptable behavior, first data from one or more executables of the first set of interdependent executables (“While the mobile robot 20 is performing its task(s)” [col. 8, lines 44-53], “the mobile robot 20 senses the presence of the individual 26. The sensor system 30, for example, may provide the controller 36 with sensor data which indicates the individual 26 is at a certain location” [col. 8, lines 54-61]. See software execution in col. 6, lines 37-52. See also col. 8, lines 1-32; col. 8, line 62 to col. 9, line 7; and col. 10, lines 53-65.);
analyzing the received first data (See “the mobile robot 20 senses the presence of the individual 26. The sensor system 30, for example, may provide the controller 36 with sensor data which indicates the individual 26 is at a certain location” [col. 8, lines 54-61]. See also col. 4, line 48; col. 8, lines 1-32; col. 8, line 62 to col. 9, line 7; col. 10, lines 53-65; and claim 1.);
generating, by the first monitoring executable associated with the first non-deterministic and adaptable behavior, based on the analyzing the received first data, a first transition trigger (See “The controller 36, for example, may utilize sensor data [received first data] to determine the distance between the mobile robot 20 and the individual 26” and/or “an estimated time of arrival (ETA) of the mobile robot 20 to the individual 26. When the determined distance and/or ETA is equal to or below a value, the mobile robot may acknowledge the presence of the individual 26” [col. 10, lines 53-65]. This threshold distance/ETA is therefore a first transition trigger. See software execution in col. 6, lines 37-52. See also claim 1.);
transitioning, based on the first transition trigger, the robotic system into a second non-deterministic and adaptable behavior (Based on the sensor data, “the mobile robot 20 acknowledges the presence of the individual” [col. 8, line 62 to col. 9, line 19]. “The mobile robot 20, for example, may repetitively… signal the individual 26 that it is aware of the individual’s 26 presence until that individual 26 leaves the common region 28” [col. 9, lines 13-19]. “In some embodiments, the acknowledgement of step 1406 may be paired with one or more maneuvers,” such as “Stopping mobile robot 20 movement” [col. 10, lines 38-52]. The acknowledgement and avoidance maneuvers are clearly a second non-deterministic and adaptable behavior different than performing the initial robot task and adaptive to the encounter with the individual 26. See “where the mobile robot 20 temporarily paused task performance to let the individual 26 pass, the mobile robot 20 may resume performance of its task(s) after or at the end of the encounter” [col. 10, lines 23-37]. See also col. 3, lines 4-14; col. 7, lines 17-41; col. 8, lines 1-20; col. 9, line 20 to col. 10, line 22.).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the autonomous vehicle control method of Oliver to use sensor data from a robot as taught by Theobald. One of ordinary skill in the art would have been motivated to make this modification to sense an encounter with a person worried about colliding with the mobile robot 20 so that the mobile robot 20 can “convey how the mobile robot 20 will operate during the encounter” (Theobald; col. 3, line 49 to col. 4, line 2).
Regarding claim 20, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
further comprising starting a second monitoring executable associated with the second non-deterministic and adaptable behavior (See “wherein said first function running in processing core C1 is configured to detect [monitor for] a[n] input, for example, the selection of an entry in a menu on a touch screen” [0287]. This first function begins the transition from MODE A to MODE B [0287], so the first function is associated with the second non-deterministic and adaptable behavior (MODE B). Multiple instances of each of the first, second, third, and fourth functions can run at the same time [0198-0199], so a second instance of the first function is a second monitoring executable. See “first, second, third, and fourth functions, running on one or more processing cores of the computer system, to execute the mode transition at runtime” [0198]. In addition, the second, third, or fourth functions can also be a second monitoring executable; they monitor for messages and conditions as shown in Figs. 2-4 and described in [0208-0266] associated with the transition between modes (first to second behaviors). To run on a processing core, the functions have been started. Executable: see the “first, second, third, and/or fourth functions are implemented in software components, …wherein said software components are included in the set of software components in the computer system, and wherein at least one or more of said software components are included in the set of software components for each transition definition in said computer system” [0132]. Furthermore, since the functions can be software components listed in a mode transition definition, the functions can be (re)initialized or (re)configured (started) like the other software components when transitioning between modes; see [0179-0186]. See also [0010], [0269], and [0286]. See also virtualization in [0169-0170].).
Regarding claim 21, Oliver/Theobald discloses the limitations of claim 20 as addressed above, and Oliver additionally discloses
further comprising: receiving, by the second monitoring executable associated with the second non-deterministic and adaptable behavior, second data… (As stated with regard to claim 20 above, multiple instances of the first function can run at the same time [0198-0199] and, as a software component [0132], the first function may be (re)initiated or (re)configured as part of a mode transition [0179-0186], so a second instance or occurrence of the first function is a second monitoring executable. See “wherein said first function running in processing core C1 is configured to detect a[n] input [second data], for example, the selection of an entry in a menu on a touch screen” [0287]. The first function monitors for an input to transition between modes, so the first function is associated with the second non-deterministic and adaptable behavior (MODE B) [0287]. See Fig. 5 and [0269] for multiple mode switches. See also the second, third, and fourth functions receiving messages from each other or the first functions in Figs. 2-4 and [0208-0266]. See also [0132-0133] and [0198-0205].);
analyzing the received second data (See “wherein said first function… is configured to detect a[n] input, for example, the selection of an entry in a menu on a touch screen, wherein said entry allows activating a trajectory planning function” [0287]. A person of ordinary skill in the art would recognize that activating a corresponding mode/function based on receiving the selection of the same entry or a different entry would comprise analyzing the input (second data). See also [0199-0205].);
generating, by the second monitoring executable associated with the second non-deterministic and adaptable behavior, based on the analyzing the received second data, a second transition trigger (See “wherein said first function running in processing core C1 is configured to detect a[n] input, for example, the selection of an entry in a menu on a touch screen, wherein said entry allows activating a trajectory planning function, causing said first function to send a request [generate a second transition trigger] to said second function to transition [modes], via an m0-message” [0287]. See also the second, third, and fourth functions sending messages (generating transition triggers) in Figs. 2-4 and [0208-0266] for completing the mode transition. See Fig. 5 and [0269] for multiple mode switches. See also Fig. 1, [0132-0133], [0186], [0198-0206], and [0269].);
transitioning, based on the second transition trigger, the robotic system into a third non-deterministic and adaptable behavior (See Fig. 5 and [0269] for multiple mode switches. After a series of processes triggered by the m0-message of the first function(s) above, fourth functions “compute the changes in the configuration of the processing cores so that the software components which have to run in the new mode [the third non-deterministic and adaptable behavior] can be activated, wherein said computation is based on the current active mode [the second behavior], and… wherein each said fourth function execute said computed changes” to transition between modes [0290-0300]. According to the example given in Table 3, the system can transition from MODE B (second behavior) to MODE C (third behavior). See also Fig. 1, Fig. 4, [0158], [0175-0186], and [0198-0262], and in particular [0235-0243].);
operating the robotic system in the third non-deterministic and adaptable behavior by executing a third set of interdependent executables by: determining one or more executables of the second set of interdependent executables of the second non-deterministic and adaptable behavior to be ceased; ceasing execution of the one or more executables of the second set of interdependent executables of the second non-deterministic and adaptable behavior (The fourth functions “compute [determine] the changes in the configuration of the processing cores… based on the specific actions in the mode transition definition” from the second behavior to the third behavior [0290]. Those actions can include “de-initializ[ing] a software component of the set of software components in the current, old, mode” (second behavior) [0179-0180]. For example, based on Table 3, the transition from MODE B (second behavior) to MODE C (third behavior) includes deinitializing (ceasing execution) software component SWC3 (executable) [0280]. See also [0179-0186], [0235-0262], and Table 2.); and / or
determining one or more second additional executables of the third set of interdependent executables of the third non-deterministic and adaptable behavior to be started; starting execution of one or more third additional executables associated with the third non-deterministic and adaptable behavior (The fourth functions “compute [determine] the changes in the configuration of the processing cores so that the software components which have to run in the new mode [third behavior] can be activated, wherein said computation is based on the current active mode [second behavior] and wherein said computation is additionally based on the specific actions in the mode transition definition… and wherein each said fourth function execute said computed changes” [0290-0300]. In the example shown in Table 3, transitioning from MODE B (second behavior) to MODE C (third behavior) according to the mode transition definition T-BC involves initializing executable SWC4 [0281]. See also [0179-0186], [0235-0262], [0278-0284], and Table 3.).
Regarding claim 22, Oliver/Theobald discloses the limitations of claim 21 as addressed above, and Oliver additionally discloses
further comprising starting a third monitoring executable associated with the third non-deterministic and adaptable behavior (See “wherein said first function running in processing core C1 is configured to detect [monitor for] a[n] input, for example, the selection of an entry in a menu on a touch screen” [0287]. This first function begins the transition between modes (non-deterministic and adaptable behaviors) [0198-0207], so the first function is associated with the third non-deterministic and adaptable behavior. In the example shown in Table 3 and Fig. 5, MODE B 120 (second behavior) can transition to MODE C 140, so MODE C is a third non-deterministic and adaptable behavior [0277], although other modes could also be the third behavior. Multiple instances of each of the first, second, third, and fourth functions can run at the same time [0198-0199], so a third instance of the first function is a third monitoring executable. See “first, second, third, and fourth functions, running on one or more processing cores of the computer system, to execute the mode transition at runtime” [0198]. In addition, the second, third, or fourth functions can also be a third monitoring executable; they monitor for messages and conditions as shown in Figs. 2-4 and described in [0208-0266] associated with the transition between modes (second to third behaviors). To run on a processing core, the functions have been started. Executable: see the “first, second, third, and/or fourth functions are implemented in software components, …wherein said software components are included in the set of software components in the computer system, and wherein at least one or more of said software components are included in the set of software components for each transition definition in said computer system” [0132]. Furthermore, since the functions can be software components listed in a mode transition definition, the functions can be (re)initialized or (re)configured (started) like the other software components when transitioning between modes; see [0179-0186]. See also [0010], [0269], and [0286]. See also virtualization in [0169-0170].).
Regarding claim 23, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
further comprising: obtaining, from a configuration file, a first set of dependencies between the first monitoring executable and the first set of interdependent executables (See a stored configuration file of mode transition definitions comprising “a list of specific actions, which need to be executed during the transition to perform the transition from the set of software components in the past active mode to the set of software components in the future active mode” in [0174-0178] and [0193-0197]. The list of specific actions includes “de-initializ[ing] a software component of the set of software components in the current, old, mode” [0180]; “initializ[ing] a software component of the set of software components in the new mode” [0182]; and/or “(re)configur[ing] software services like error handlers, monitoring systems, watchdogs, and/or middleware, to the new set of software components in the new mode” [0185]. The first function (first monitoring executable), after receiving a request to transition modes, “selects the corresponding transition definition of the set of transition definitions” [0199], and fourth functions execute the actions obtained from the transition definition to perform the transition [0238-0243]. Therefore, the list of specific actions of a mode transition comprises a first set of dependencies between the first monitoring executable and the first set of interdependent executables. See also mode definitions in [0171-0173] and Table 2. See also Fig. 4, Fig. 5, Table 3, [0179-0186], [0290-0300], and claim 1.); and
wherein the determining one or more executables of the first set of interdependent executables of the first non-deterministic and adaptable behavior to be ceased is based on the obtained first set of dependencies (The first function (first monitoring executable), after receiving a request to transition modes, “selects the corresponding transition definition of the set of transition definitions” [0199]. After further processing, “fourth functions compute [determine] the necessary changes in the configuration… wherein said changes in the configuration comprise a list of specific actions according to said transition definition” [0238-0239], including “de-initializ[ing] a software component of the set of software components [first set of interdependent executables] in the current, old, mode” (e.g., first behavior) [0180]. Therefore, the determining of executables to be ceased is based on the first set of dependencies comprised in the mode transition definition. See also Fig. 4, Tables 2 and 3, [0174-0186], [0193-0197], [0278-0285], [0290-0300], and claim 1.).
Regarding claim 24, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
further comprising: obtaining, from a configuration file, a second set of dependencies between the second monitoring executable and the second set of interdependent executables (See a stored configuration file of mode transition definitions comprising “a list of specific actions, which need to be executed during the transition to perform the transition from the set of software components in the past active mode to the set of software components in the future active mode” in [0174-0178] and [0193-0197]. The list of specific actions includes “de-initializ[ing] a software component of the set of software components in the current, old, mode” [0180]; “initializ[ing] a software component of the set of software components in the new mode” [0182]; and/or “(re)configur[ing] software services like error handlers, monitoring systems, watchdogs, and/or middleware, to the new set of software components in the new mode” [0185]. The first function, after receiving a request to transition modes, “selects the corresponding transition definition of the set of transition definitions” [0199], and fourth functions execute the actions obtained from the transition definition to perform the transition [0238-0243]. Multiple instances of each of the first, second, third, and fourth functions can run at the same time [0198-0199], so a second instance of the first function is a second monitoring executable. In addition, the second, third, or fourth functions can also be a second monitoring executable; they monitor for messages and conditions as shown in Figs. 2-4 and described in [0208-0266] associated with the transition between modes. Therefore, the list of specific actions of a mode transition comprises a second set of dependencies between the second monitoring executable and the second set of interdependent executables. See also mode definitions in [0171-0173] and Table 2. See Fig. 5 and [0269] for multiple mode switches. See also Fig. 4, Table 3, [0179-0186], [0290-0300], and claim 1.); and
wherein the determining one or more first additional executables of the second set of interdependent executables of the second non-deterministic and adaptable behavior to be started is based on the obtained second set of dependencies (The first function, after receiving a request to transition modes, “selects the corresponding transition definition of the set of transition definitions” [0199]. After further processing, “fourth functions compute [determine] the necessary changes in the configuration of the processing core on which said fourth function[s] are running, so that the software components, which have to run on the processing core according to the new mode can be activated [started], and wherein said changes in the configuration comprise a list of specific actions according to said transition definition” [0238-0239], including “initializ[ing] a software component of the set of software components in the new mode” (e.g., second behavior) [0182]. Therefore, the determining of executables to be started is based on the second set of dependencies comprised in the mode transition definition. See also Fig. 4, Tables 2 and 3, [0174-0186], [0193-0197], [0278-0285], [0290-0300], and claim 1.).
Regarding claim 26, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
wherein an executable comprises one or more sensor modules, one or more actuator modules and / or one or more behavior algorithm modules (See “Automotive systems generally comprise a repertory of critical and non-critical functions, among which those comprised in the so-called Advanced Driver Assistance Systems, ADAS, in modern automotive systems may require the execution of a large number of software components. ADAS functions include, for example, a plurality of autonomous driving features, like lane centering assistance, LCA, collision avoidance system, CAS, traffic sign recognition, TSR, or autopilot. Software components, fully or partially implementing those functions, may run simultaneously in one or multiple of said processing cores, within a single host or distributed among multiple hosts” [0011-0012]. A software component (executable) may therefore comprise one or more sensor modules, one or more actuator modules and / or one or more behavior algorithm modules since the listed ADAS functions require analysis and/or control of sensors and sensor data, actuators/propulsion systems, and behaviors of a vehicle. See also [0013-0016] and [0276].).
Regarding claim 27, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver/Theobald additionally teaches
further comprising: obtaining the first set of interdependent executables and the first monitoring executable from the memory of the robotic system and / or via a network from a remote storage (See “The controller 36 [of robot 20] may be implemented with hardware or a combination of hardware and software. The hardware may include memory 54 and at least one processing device 56… The memory 54 is configured to store software (e.g., program instructions) for execution by the processing device 56, which software execution may control and/or facilitate performance of one or more operations such as those described in the methods below” [Theobald; col. 6, lines 30-52]. The software components (executables) of Oliver include the first set of interdependent executables and the first monitoring executable—see the mode definition comprising “a set of references to software components from the set of defined software components” [0173] and “first, second, third, and/or fourth functions are implemented in software components, …wherein said software components are included in the set of software components in the computer system” [0132]. In combination, Oliver/Theobald teaches the software components (executables) are stored in the memory of the robotic system. The executables are obtained from the memory when they are executed/initialized by a processor. See also [0164-0169], [0179-0186], [0278-0285], and claim 1 of Oliver.).
Regarding claim 28, Oliver/Theobald discloses the limitations of claim 20 as addressed above, and additionally teaches
further comprising: obtaining the second set of interdependent executables and the second monitoring executable from the memory of the robotic system and / or via a network from a remote storage (See “The controller 36 [of robot 20] may be implemented with hardware or a combination of hardware and software. The hardware may include memory 54 and at least one processing device 56… The memory 54 is configured to store software (e.g., program instructions) for execution by the processing device 56, which software execution may control and/or facilitate performance of one or more operations such as those described in the methods below” [Theobald; col. 6, lines 30-52]. The software components (executables) of Oliver include the second set of interdependent executables and the second monitoring executable—see the mode definition comprising “a set of references to software components from the set of defined software components” [0173] and “first, second, third, and/or fourth functions are implemented in software components, …wherein said software components are included in the set of software components in the computer system” [0132]. In combination, Oliver/Theobald teaches the software components (executables) are stored in the memory of the robotic system. The executables are obtained from the memory when they are executed/initialized by a processor. See also [0164-0169], [0179-0186], [0278-0285], and claim 1 of Oliver.).
Regarding claim 29, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and additionally teaches
wherein the generating the first and second transition trigger comprises determining that the received first or second data match a preconfigured trigger condition (See “First functions, customModeHandler, may receive a request to execute a transition from a current mode to a new mode, for example by means of a human-machine interface, or as a result of an automated algorithm… After receiving said request, said first function selects the corresponding transition definition” [0199]. The request (first or second data) is determined to match a corresponding transition definition (preconfigured trigger condition). Then, “The transition request… is then communicated to second functions, with the transmission of an m0-message” (generating the transition trigger) [0206]. See also [0287].).
Regarding claim 33, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Theobald additionally discloses
A robotic system comprising one or more sensors and actuators operably connected to memory and processing circuitry (See a mobile robot 20 having a sensor system 30 comprising at least two sensors 38 and drive system 34 “in signal communication” with controller 36 comprising memory 54 and processing device 56 in Fig. 9 [col. 4, line 41 to col. 5, line 9]. Drive system 34 includes actuators: wheels 50 “driven by at least one motor” and/or “a plurality of motorized… track systems 52” [col. 6, lines 4-29]. Note the communication system 32 may also include sensors, e.g., a receiver 42 [col. 5, lines 10-23].).
Oliver/Theobald teaches “the robotic system being configured to carry out the method of claim 19” (see the rejection of claim 19 above). Therefore, the combination of Oliver/Theobald as a whole teaches the claim.
Regarding claim 34, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
A computer program comprising instructions, which when executed by a robotic system (See an automotive computer system comprising “one or multiple processing cores” and memory [0164] for executing software components to accomplish autonomous driving features of a vehicle (robotic system); see [0158] and [0011]. See also [0009] and [0012-0013]. See also claims 1, 8, and 9.).
See also “The memory 54 is configured to store software (e.g., program instructions) for execution by the processing device 56, which software execution may control and/or facilitate performance of one or more operations” [col. 6, lines 30-52] in Theobald.
Oliver/Theobald teaches “causes the robotic system to carry out the method of claim 19” (see the rejection of claim 19 above). Therefore, the combination of Oliver/Theobald as a whole teaches the claim.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Oliver in view of Theobald, and further in view of Xiong and Huang (US 20190205145 A1; “Xiong”).
Regarding claim 25, Oliver/Theobald discloses the limitations of claim 19 as addressed above. However, Oliver/Theobald does not explicitly teach “wherein ceasing execution comprises one of: temporarily suspending the one or more executables; permanently suspending the one or more executables.”
Xiong, in the same field of endeavor (controlling switches in robot behavior), teaches
wherein ceasing execution comprises one of: temporarily suspending the one or more executables; permanently suspending the one or more executables (Xiong discloses controlling a robot by switching between tasks. See “In this embodiment, the switching front the current task to the new task is implemented by interrupting the current task and executing the new task, and resuming the current task after the new task terminates [temporary suspension]. In other embodiments, the switching from the current task to the new task can be implemented by terminating the current task and executing the new task, and executing the next task after the new task completes” (permanent suspension) [0040-0041]. In Xiong, a task is equivalent to a software component/executable and a state is equivalent to a mode/behavior; see [0028], [0051-0052], and Fig. 2. See also [0019-0020] and [0032-0039].).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the autonomous vehicle control method of Oliver/Theobald to temporarily or permanently suspend executables as taught by Xiong. One of ordinary skill in the art would have been motivated to make this modification because “the stability of the operation of the robot 201 can be improved, and the efficiency of the robot 201 to execute tasks can be improved” (Xiong, [0042]).
Claims 30-32 are rejected under 35 U.S.C. 103 as being unpatentable over Oliver in view of Theobald, and further in view of Mallavarapu (US 20220164224 A1, filed 11/23/2021).
Regarding claim 30, Oliver/Theobald discloses the limitations of claim 19 as addressed above, and Oliver additionally discloses
wherein executing the first set of interdependent executables comprises: …executing at least one of the first set of interdependent executables in the isolated runtime environment (See “The computer system may additionally comprise virtualization mechanisms… provid[ing] a virtual [runtime] environment, or virtual machine, wherein software components may execute in similar conditions as if they would execute directly running in the abstracted hardware components,” which are implemented, for example, through hypervisors and containers [0169]. The virtualization mechanisms thus comprise an isolated runtime environment in which software components (executables) run. Note that transitioning between modes can include the actions of “initializ[ing] a software component of the set of software components in the new mode” [0182] and “(re)configur[ing] the runtime system of one or multiple processing cores to execute the set of software components in the new mode” [0184], where the software components are run in the processing cores [0173]. See also [0140-0143], [0164], [0170], [0179-0186], [0238], [0242], [0270-0275].)
However, Oliver/Theobald does not explicitly teach “instantiating an isolated runtime environment.”
Mallavarapu, in the same field of endeavor (controlling the execution of code blocks for a client robot), teaches
wherein executing the first set of interdependent executables comprises: instantiating an isolated runtime environment (See “The runtime environment can be: a local computing system (e.g., mobile device, laptop, etc.), a remote computing system (e.g., cloud computing system, etc.), a bare metal machine (e.g., processor, thread, etc.), a virtual machine, a container, and/or any other suitable computing system. Each runtime environment can execute one or more runs (e.g., in one or more processes). The runtime environment can be newly initialized each time a run is initialized or continued” [0100]. Since the runtime environment may be unique to a run, particularly in the cases of a virtual machine and a container, the runtime environment is an isolated runtime environment. See also [0086], [0128], [0170], and claims 1 and 6.); and
executing at least one of the first set of interdependent executables in the isolated runtime environment (See “Each runtime environment can execute one or more runs (e.g., in one or more processes)” [0100] by “executing a code block of the set [of code blocks]” [claim 1]. A code block is an executable; see [0033] and [0052]. See also [0086], [0099], [0128], [0138-0141], and [0170].).
A run in Mallavarapu is similar to a mode in Oliver and a behavior in Theobald. A code block in Mallavarapu is similar to a software component in Oliver. In both Oliver and Mallavarapu, executables can be run in isolated virtual machines or containers.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to have modified the autonomous vehicle control method of Oliver/Theobald to instantiate an isolated runtime environment when beginning or continuing a run as taught by Mallavarapu. One of ordinary skill in the art would have been motivated to make this modification for the benefit of enabling “Shutting down the computing environment (e.g., the runtime environment, the process, etc.) functions to release the run's computing resources, such that other runs or applications can utilize said computing resources” when a run is complete or suspended (Mallavarapu, [0159]).
Regarding claim 31, Oliver/Theobald/Mallavarapu discloses the limitations of claim 30 as addressed above, and Mallavarapu further teaches
wherein the step of ceasing execution further comprises terminating the isolated runtime environment (See “The runtime environment can be newly initialized each time a run is initialized or continued, and shut down (e.g., torn down) each time a run is suspended” [0100]. See also [0085] and [0158-0159].).
Regarding claim 32, Oliver/Theobald/Mallavarapu discloses the limitations of claim 30 as addressed above, and Mallavarapu further teaches
wherein the isolated runtime environment is associated with an isolated runtime configuration comprising one or more of: a security access policy, a processing resource utilization restriction and a memory utilization restriction for the isolated runtime environment (See “The run parameters can include… computing environment [configuration] parameters (e.g., identifier; configuration, such as machine provider, orchestrator, container type, image location, etc.; access credentials; etc.)… Initiating a workflow can include: optionally provisioning a computing environment according to the computing environment parameters” [0132]. “Computing environment” is used interchangeably with “runtime environment” [0159]. Access credentials are used to validate requests to continue a run [0166-0168], which is a security access policy. Additionally, see run storage in the runtime environment in Fig. 10. “The run storage can be: a stack (e.g., FILO stack, FIFO stack, etc.), a buffer, a memory space… and/or be otherwise configured” [0093], where “storage configurations can include: the number of values permitted in the shared storage (e.g., the buffer length), a value cutoff (e.g., used to determine whether a writing run should be suspended)” [0182]. Therefore, the isolated runtime configuration comprises a memory utilization restriction. See also [0093], [0128], [0159], [0177], and [0188].).
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Nott and Marks (US 20210200581 A1) discloses control and interruption of robotic processes via trigger events or conditions based on configuration files.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Moya Ly whose telephone number is (571)272-5832. The examiner can normally be reached Monday-Friday 10:00 am-6:00 pm ET.
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, Ramon Mercado can be reached at (571) 270-5744. 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.
/MOYA LY/Examiner, Art Unit 3658
/Ramon A. Mercado/Supervisory Patent Examiner, Art Unit 3658
Prosecution Insights