DETAILED ACTION
Claim 13 interpreted under 35 USC §112(f).
Claim 15 rejected under 35 USC §101.
Claims 1-3, 5, and 11-15 rejected under 35 USC §103.
Claims 4 and 6-10 objected to as allowable dependent claims.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “ a response module,” “query module,” “execution data generation module,” “a first target control unit determination module,” and “an execution module” that are “configured to” perform functions in claim 13.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claim 15
Claim 15 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim is drawn to signals per se. A transitory signal, while physical and real, "does not possess concrete structure" and "is not composed of matter." MPEP 2106.03. The present specification does not defined the bounds of “computer-readable storage medium,” so the broadest reasonable interpretation may include transitory embodiments. Specification, ¶ 282. Accordingly, claim 15 is directed to non-statutory subject matter because the claimed “computer-readable storage medium” is interpreted to include transitory signal embodiments.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 5, and 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Jentz et al., U.S. PG-Publication No. 2019/0137940 A1, in view of Kirchhof-Falter et al., U.S. PG-Publication No. 2009/0198389 A1 (hereinafter Kirchhof), further in view of Hu et al., U.S. PG-Publication No. 2024/0286566 A1.
Claim 1
Jentz discloses a vehicle sleep and wake-up method, applied to an in-vehicle terminal. Jentz discloses “methods for waking a control module of a vehicle system.” Jentz, ¶ 16. The method is applied to a control system 190 (i.e., in-vehicle terminal) that “may include a plurality of control modules” that “communicate with each other over a controller area network (CAN).” Id. at ¶ 24. Control system 190 is “communicatively coupled to other vehicles or infrastructures via wireless network 131 and the internet (e.g., the cloud).” Id. at ¶ 32. Jentz discloses an “alarm wake system” including “a wake manager that receives the requested alarm wake up times from the requesting features and selects an alarm wake up time, and a timer that is set for the selected alarm wake up time by the wake manager.” Upon the “timer elapsing at the selected alarm wake up time, the control module may be awoken while the vehicle remains off to perform the requesting features.” Jentz, ¶ 16. Requesting features of a control module “may request an alarm wake during the vehicle key-off period in order to perform afterrun tasks a duration after the vehicle is shutdown.” Id. at ¶ 56. The CAN “may be switched to a listening mode so that other control modules that are not performing afterrun tasks may be kept off (or switched off after their afterrun tasks are completed).” Id. at ¶ 59.
Jentz discloses receiving a work group request in response to triggering for a function scenario, wherein the work group request comprises … an execution instruction, and a runtime. Figure 5 illustrates “method 500 for requesting, arbitrating, and scheduling a control module alarm wake during a vehicle key-off period.” At 506, the method “includes maintaining control module power and performing afterrun tasks” (afterrun tasks → work group request). Afterrun tasks “may maintain a power relay of [a] control module in the ‘on’ position” (control module performing after run task → target work group). Aftterrun tasks “include performing diagnostics, uploading vehicle data to the cloud, and downloading control strategies and calibrations from the cloud.” The afterrun tasks are “performed by features of the control module … some duration after the vehicle key-off event, when conditions may be more favorable” (conditions more favorable → triggering for a function scenario). Id. at ¶¶ 56-59; FIG. 5; See Also ¶ 86 (“transmitting a request to run each of the requesting features,” “each requesting feature may begin evaluating its entry conditions”). A control module “may be awoken in order to execute one or more afterrun tasks,” wherein requesting features include “software features, such as executable instructions stored on a memory of the control module” (i.e., execution instruction) that may request a future-wake up time to perform their function (future wake up time → runtime). Id. at ¶¶ 50-52.
Jentz discloses executing the execution data on the first target control unit. Jentz discloses at 506, the method “includes maintaining control module power and performing afterrun tasks” (performing afterrun tasks → executing the execution data). Further, a CAN “may be switched to a listening mode so that other control modules that are not performing afterrun tasks may be kept off (or switched off after their afterrun tasks are completed).” Afterrun tasks “may be performed by features of the control module.” Id. at ¶ 59. If the entry conditions are met, the method “includes performing the feature.” Id. at ¶ 88.
Jentz does not expressly disclose querying a remaining duration of a target work group, and generating execution data according to the execution instruction, the runtime, and the remaining duration.
Kirchhof discloses querying a remaining duration of a target work group. Kirchhof discloses methods “for controlling/regulating at least one task with the help of a control program that monitors a runtime of the at least one task.” Kirchhof, ¶ 14. The effective runtime of the at least one task is monitored. The method comprises functions of a “minimum runtime” that “specifies a lower limit for the expected task runtime” and a “maximum runtime” that specifies an upper limit for the expected task runtime.” The minimum and maximum runtimes enable a “simple calculation of a time span within which the task runtime is expected” (i.e., runtime). The maximum runtime “may additionally be advantageously used to estimate an anticipated remaining runtime” (i.e., remaining duration). Id. at ¶¶ 17-18; See Also ¶ 73 (calculating runtime), ¶ 95 (calculating remaining runtime). Further, the method is implemented in a CAN controller. Id. at ¶ 26.
Kirchhof discloses generating execution data according to the execution instruction, the runtime, and the remaining duration. Kirchhof calculates the current status of the tasks using a “free cycle time” derived from Tpre = Sum (Tmax – Tleff), wherein Tpre is the ‘remaining duration’ of a task calculated from the maximum runtime Tmax and the current runtime Tleff. The free cycle time Tfree is added to the Tmax to determine Tguard which is the “runtime … provided by the control program.” This specific task runtime is used to determine whether the task has exceeded, or overrun, its expectation, causing a guardian to terminate the task (i.e., generate execution data). Id. at ¶¶ 88-99.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the CAN sleep and wake-up method of Jentz to incorporate the remaining task duration and maximum task duration as taught by Kirchhof. One of ordinary skill in the art would be motivated to integrate the remaining task duration and maximum task duration into Jentz, with a reasonable expectation of success, in order to “provide trapping mechanisms as a function of the processing time … in order to be able to reliably design safety-critical systems,” wherein “particular safety-related functions may be improved in a motor vehicle.” See Id. at ¶¶ 8, 28.
Jentz does not expressly disclose wherein the in-vehicle terminal stores a work group configuration table sent by a cloud; wherein the work group request comprises a work group identifier; a target work group corresponding to the work group identifier; and determining a first target control unit from the work group configuration table according to a target work group corresponding to the work group identifier.
Hu discloses wherein the in-vehicle terminal stores a work group configuration table sent by a cloud; wherein the work group request comprises a work group identifier; a target work group corresponding to the work group identifier; and determining a first target control unit from the work group configuration table according to a target work group corresponding to the work group identifier. Hu discloses “methods for managing energy consumption” in a vehicle that “involves the power management service translating the abstract request from an abstract form into the concrete activation request by identifying a destination associated with the resource associated with the abstract request.” Hu, ¶ 4. The power management service 104 abstracts resources “such that the software entities 114 can request a particular resource 106, 108 I nan abstract format (e.g., by identifying a particular device, component, system, subsystem, service or the like) and allows the power management service 104 to translate the abstract resource request from an abstract form into a physical, tangible, or concrete form.” The service translates “an abstract resource activation request by mapping the abstract identification” (i.e., work group identifier) “by mapping the abstract identification of the requested resource to a particular hardware resource” (mapping → based on a configuration table). Id. at ¶ 20. A software entity may “provide a resource activation request … that identifies one or more resources … onboard the vehicle.” Id. at ¶ 22. The requesting software entity 114 “may identify the requested resource(s) … in an abstract form, such as, for example, by a name or other identifier associated with the respected resource.” The service 104 then “translates, maps, or otherwise convers the abstract resource identifier … into a … a specific hardware address, physical address, network address and/or the like associated with the respective resource.” Id. at ¶ 31.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the CAN sleep and wake-up method of Jentz-Kirchhof to incorporate the mapping of an identifier to a particular vehicle resources taught by Hu. One of ordinary skill in the art would be motivated to integrate the mapping of an identifier to a particular vehicle resources into Jentz-Kirchhof, with a reasonable expectation of success, in order to improve efficiency through interoperability: “software entities 114 may be designed, developed or otherwise configured to request resources that is independent of the underlying physical configuration … or platform associated with a respective vehicle … thereby providing interoperability of software entities 114 across different vehicle platforms and/or different configurations of resources.” See Hu, ¶ 20.
Claim 2
Jentz discloses wherein after the step of executing the execution data on the first target control unit, the method further comprises: generating execution result information; and broadcasting the execution result information. When it is determined that “the afterrun tasks are complete …, each feature may set a ‘run done’ flag at the startup/shutdown controller to indicate completion.” Jentz, ¶¶ 60-62, 65.
Claim 3
Jentz discloses wherein the step of generating execution data according to the execution instruction, the runtime, and the remaining duration comprises: combining the runtime and the remaining duration to generate the execution data according to the execution instruction when the vehicle switches from a sleep state to a wake-up state, wherein the execution data are used for waking up the vehicle. Jentz discloses that the “control module may have a wake input that allows the control module to be returned to the awake mode based on an input from one of more sensors.” The control module “may be awoken in order to execute one or more afterrun tasks, including diagnostic and non-diagnostic features.” Jentz, ¶ 50.
Jentz discloses monitoring working states corresponding to work groups of the vehicle and controlling the work groups of the vehicle to sleep when the vehicle switches from the wake-up state to the sleep state. Once shutdown is initiated, a CAN “may be switched to a listening mode so that other control modules that are not performing afterrun tasks may be kept off (or switched off after their afterrun tasks are completed).” Id. at ¶ 59.
Claim 5
Kirchhof discloses wherein when the function scenario is a scenario of subsequently entering a work group, the state corresponding to the execution instruction is an entry state, and the step of combining the runtime and the remaining duration to generate the execution data according to the execution instruction comprises: superimposing the runtime on the remaining duration in the entry state to update the remaining duration; and determining the updated remaining duration as the execution data. Kirchhof discloses querying a remaining duration of a target work group. Kirchhof discloses methods “for controlling/regulating at least one task with the help of a control program that monitors a runtime of the at least one task.” Kirchhof, ¶ 14. The effective runtime of the at least one task is monitored. The method comprises functions of a “minimum runtime” that “specifies a lower limit for the expected task runtime” and a “maximum runtime” that specifies an upper limit for the expected task runtime.” The minimum and maximum runtimes enable a “simple calculation of a time span within which the task runtime is expected” (i.e., runtime). The maximum runtime “may additionally be advantageously used to estimate an anticipated remaining runtime” (i.e., remaining duration). Id. at ¶¶ 17-18; See Also ¶ 73 (calculating runtime), ¶ 95 (calculating remaining runtime). Further, the method is implemented in a CAN controller. Id. at ¶ 26.
Claim 13
Claim 13 is rejected utilizing the aforementioned rationale for Claim 1; the claim is directed to an apparatus comprising modules performing the method.
Claim 14
Claim 14 is rejected utilizing the aforementioned rationale for Claim 1; the claim is directed to a system performing the method.
Claim 15
Claim 15 is rejected utilizing the aforementioned rationale for Claim 1; the claim is directed to a medium storing instructions corresponding to the method.
Claims 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Jentz et al., U.S. PG-Publication No. 2019/0137940 A1, in view of Kirchhof-Falter et al., U.S. PG-Publication No. 2009/0198389 A1 (hereinafter Kirchhof), further in view of Hu et al., U.S. PG-Publication No. 2024/0286566 A1, further in view of Palanisamy et al., U.S. PG-Publication No. 2016/0007138 A1.
Claim 11
Palanisamy discloses wherein the cloud is configured to perform the following steps:
receiving a work group creation instruction, wherein the work group creation instruction comprises grouping conditions and function identifiers. Palanisamy discloses “methods for he coordinated grouping of machine devices for receipt of group based services.” The method uses “server capability servers (SCS)” to “manage the create and modification of device groupings … to implement the necessary grouping operations at the appropriate [user equipment] UEs.” One disclosed application of the method is in machine type communications for “vehicle diagnostics.” Id. at ¶ 2. The SCS “may also be called an M2M server.” Id. at ¶ 45. The functions of the M2M service layer 22 may be implemented … in the cloud.” Id. at ¶¶ 557-558. The SCS determine to create a group and generates/transmits a group request to implement the group operation. The request may “create a new group of devices that may be serviced as a group,” or “modify an existing group of devices to add a new device.” Id. at ¶¶ 8-9. The method determines “whether the UEs or devices identified in the request may be provisioned to receive the requested service” (i.e., grouping conditions). Id. at ¶ 10. The request may “’identify the particular … service that is requested” ” (i.e., function identifier) “along with information identifying the particular devices that are to be included in the group.” Id. at ¶¶ 9; See Also ¶¶ 16-17 (“request may comprise … a group identifier associated with a particular service and a particular group of devices”).
Palanisamy discloses grouping control units of the in-vehicle terminal according to the grouping conditions to obtain work groups. The disclosure states that “it may be operationally efficient to use … services in connection with several devices that are housed in or traveling in the same vehicle.” Id. at ¶ 4. The request is used “to create a new group of devices that may be services as a group.” Id. at ¶ 9.
Palanisamy discloses associating the work groups with the function identifiers to generate the work group configuration table. The method “configures or provisions the identified UEs 214 … and allocates one or more internal group identifier(s) associated with the provisioned service(s),” wherein the internal group identifiers “are used within the core network to identify particular services and the UEs 214 associated with the service” (associating services with devices → associating function identifiers with work groups). The core network “maintains the group identifiers for use in future processing and modification of the services.” (maintains the associations → work group configuration table). Id. at ¶ 79.
Palanisamy discloses sending the work group configuration table to the in-vehicle terminal. The “coordinated grouping for grouped based services often involves the automated configuration of UEs including wireless base stations such as, for example eNBs” (e.g., in-vehicle terminal). The eNB 2100 “may receive [a] request to create or alter an existing grouping of nodes with which the eNB 2100 communicates.” Id. at ¶¶ 566-567.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify CAN sleep and wake-up method of Jentz-Kirchhof -Hu to incorporate the creation and modification of group device identifiers taught by Palanisamy. One of ordinary skill in the art would be motivated to integrate the creation and modification of group device identifiers into Jentz-Kirchhof -Hu, with a reasonable expectation of success, in order to improve efficiency by reducing manual provisioning and improving coordinated group creation/modification: prior art methods require “relevant machine and servicing core network devices must be individually provisioned with the appropriate information so that the relevant devices may be serviced as a group,” and “when modifications to an existing group of devices are needed, the impacted devices must be individually provisioned in order to implement the modifications.” See Palanisamy, ¶¶ 6-7.
Claim 12
Palanisamy discloses wherein the cloud is further configured to perform the following steps: receiving a modification instruction for the control units of the in-vehicle terminal, wherein the modification instruction comprises control unit modification parameters; modifying the work group configuration table according to the control unit modification parameters to update the work group configuration table; and sending the updated work group configuration table to the in-vehicle terminal. Palanisamy discloses “methods for he coordinated grouping of machine devices for receipt of group based services.” The method uses “server capability servers (SCS)” to “manage the create and modification of device groupings … to implement the necessary grouping operations at the appropriate [user equipment] UEs.” One disclosed application of the method is in machine type communications for “vehicle diagnostics.” Id. at ¶ 2. The SCS “may also be called an M2M server.” Id. at ¶ 45. The functions of the M2M service layer 22 may be implemented … in the cloud.” Id. at ¶¶ 557-558. The SCS determine to create a group and generates/transmits a group request to implement the group operation. The request may “create a new group of devices that may be serviced as a group,” or “modify an existing group of devices to add a new device.” Id. at ¶¶ 8-9.
Allowable Subject Matter
Claims 4 and 6-10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See Abadie, U.S. PG-Publication No. 2022/0245085 A1 (disclosing methods for “dialoguing with a computer on an on-board bus of a vehicle,” that is “useful for updating on-board computers, whilst at the same time allowing real-time programs to be executed for operating the vehicle,” ¶¶ 1-2).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK D MILLS whose telephone number is (571)270-3194. The examiner can normally be reached M-F 10-6 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, KEVIN YOUNG can be reached at (571)270-3180. 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.
/FRANK D MILLS/Primary Examiner, Art Unit 2194 July 11, 2026
Prosecution Insights