DETAILED ACTION
Claim 11 objected to for minor informalities.
Claims 1-19 rejected under 35 USC § 103.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
Claim 11 objected to because of the following informalities:
The least restrictive claim "should be presented as claim 1." 37 CFR 1.75(g). Claim 11 objected to because it is less restrictive than claim 1. Appropriate correction is required.
Appropriate correction is required.
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, 11, and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Park et al., U.S. PG-Publication No. 2023/0153029 A1 (hereinafter PARK), in view of Kiffmeier et al., U.S. PG-Publication No. 2014/0215270 A1 (hereinafter KIFFMEIER).
Claim 1
PARK discloses a flash driver control method performed in a microcontroller unit (MCU) including a flash memory and a flash driver configured to perform a memory job on the flash memory. ¶ 0114: The memory driver accesses external memory and memory inside the microcontroller. ¶ 0115: The flash driver FIs “reads and writes to a flash memory.” ¶ 0122: The architecture connects application software, the runtime environment, the nonvolatile memory manager NVM, the memory Interface MemIf, flash EEPROM emulation Fee, and the flash driver FIs.
PARK discloses executing a third task that executes a third main function for requesting execution of a third memory job, the third task being terminated when a third memory job completion response is received. ¶ 0190: The architecture requests the ReadBlock service from the basic software. ¶ 0147: After the read operation for all requested blocks completes, NVM sends the NVM JobFinished completion function to the state manager software component. ¶ 0197: Upon the completion function call, the architecture recognizes read completion and checks success. ¶ 0059: The runnable is “scheduled by an operating system (OS).” ¶ 0060: Individual software component functions execute through the runnable.
PARK also performs block writes and reports their completion in ¶ 0146. However, PARK does not expressly disclose: executing a first task that executes a first main function for performing a first memory job, the first task being terminated when the flash driver is idle; and executing a second task that executes a second main function for performing a second memory job, the second task being terminated when the flash driver is idle.
KIFFMEIR discloses executing a first task that executes a first main function for performing a first memory job, the first task being terminated when the flash driver is idle. ¶ 0059, Table 2: MEMIF_IDLE means: “The underlying abstraction module or device driver is currently idle.” ¶ 0058, Table 1: MemIf_GetStatus returns underlying module status; MemIf_GetJobResult separately returns the asynchronous job result.
KIFFMEIR discloses executing a second task that executes a second main function for performing a second memory job, the second task being terminated when the flash driver is idle. ¶ 0028: Separate first and second memory operations execute as first and second asynchronous jobs. ¶ 0027: Memory status identifies whether the relevant memory resources are idle or in use.
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 flash job completion handling of PARK to incorporate the separate driver status query taught by KIFFMEIER, retaining the first and second task activations until the flash driver is idle and then terminating those activations. One of ordinary skill in the art would be motivated to integrate that status query into PARK, with a reasonable expectation of success, in order to reduce the risk of prematurely handing control to a dependent flash operation by making the preceding task’s termination reflect the driver’s availability, as supported by KIFFMEIER at ¶ 0027 and ¶ 0059, Table 2.
Claim 11
PARK discloses a flash driver control method performed in an MCU including a flash driver configured to perform a memory job on a flash memory and a first core using the flash driver. ¶ 0114: The memory driver access external memory and memory inside the microcontroller. ¶ 0115: The flash driver Fis “reads and writes to a flash memory.” ¶ 0122: The application and runtime connect through the memory manager, memory interface, and flash emulation layer to the flash driver.
PARK does not expressly disclose executing a first task that executes a first main function for performing a first memory job of the first core through the flash driver, the first task being terminated when the flash driver is idle; and executing a second task that executes a second main function for performing a second memory job of the first core through the flash driver, the second task being terminated when the flash driver is idle.
KIFFMEIER discloses executing a first task that executes a first main function for performing a first memory job of the first core through the flash driver, the first task being terminated when the flash driver is idle. ¶ 0059, Table 2: MEMIF_IDLE means: “The underlying abstraction module or device driver is currently idle.” ¶ 0058, Table 1: GetStatus returns module status: GetJobResult separately returns the asynchronous job result.
KIFFMEIER discloses executing a second task that executes a second main function for performing a second memory job of the first core through the flash driver, the second task being terminated when the flash driver is idle. ¶ 0028: First and second memory operations execute as respective asynchronous jobs. ¶ 0059, Table 2: The status model distinguishes idle, busy, and internal management activity.
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 flash job completion handling of PARK to incorporate the separate driver status query taught by KIFFMEIER, retaining the first and second task activations until the flash driver is idle and then terminating those activations. One of ordinary skill in the art would be motivated to integrate that status query into PARK, with a reasonable expectation of success, in order to reduce the risk of prematurely handling control to a dependent flash operation by making the preceding task’s termination reflect the driver’s availability, as supported by KIFFMEIER at ¶ 0027 and ¶ 0059, Table 2.
Claim 13
PARK discloses wherein the memory job includes a read operation, a write operation, an erase operation, or at least one combination thereof for data or code performed by the flash driver accessing the flash memory. ¶ 0115: FIs “reads and writes to a flash memory.” ¶ 0146: The write block service performs data writes for the respective blocks and reports completion.
Claims 2-4, 6-8, 10, 12, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over PARK, in view of KIFFMEIER, further in view of Caccamo et al., U.S. Patent No. 10,649,914 B1 (hereinafter CACCAMO).
Claim 2
CACCAMO discloses wherein the MCU includes a multi-core MCU including a first core and a second core. Col.12 ln. 16-26: The MPC5777M MCU contains two application cores and another core for peripheral operations.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed inventio not modify the MCU execution platform of PARK-KIFFMEIER to incorporate the architecture with multiple application cores, local task memories, and scheduled memory transfers taught by CACCAMO. One of ordinary skill in the art would be motivated to integrate that architecture into PARK-KIFFMEIER, with a reasonable expectation of success, in order to reduce memory access conflicts and improve predictability of task execution by scheduling shared memory accesses and executing loaded task images from local memory, as taught by CACCAMO at col. 7, ll. 19-25.
Claim 3
CACCAMO discloses wherein each of the first core and the second core includes one or more flash memories including one or more data flash memories and one or
more code flash memories. Col.4, ll. 28-37: Multiple application cores connect to flash memory 106, which stores executable by those cores. Col. 7, ll.1-18: Flash persistently stores “application and/or operating system code, read-only data,” and initialization values. Permanent task images are loaded from flash at boot. Col. 6, ll. 33-48: Task partitioning involves “each task being assigned to a specific core.” Each core has its own task set. Col. 13, ll. 4-17: Task code and data images are organized using source files, compiler directives, a linker section, and task descriptions.
Claim 4
PARK discloses wherein each of the first, second, and third memory jobs includes a read operation, a write operation, an erase operation, or at least one combination thereof for data or code performed by the flash driver accessing the flash memory. ¶ 0115: The flash driver (Fis) “reads and writes to a flash memory.” ¶ 0122: The memory management architecture includes the application, runtime environment, nonvolatile memory manager, memory interface, flash emulation layer, and flash driver. ¶ 0146: A write block request causes a “data write operation for each block,” followed by completion feedback. ¶ 0147: A read block request causes a “data read operation for each block,” followed by completion feedback.
Claim 6
CACCAMO discloses wherein the first memory job and the second memory job are performed in the first core. Col. 6, ll. 33-48: Task partitioning involves “each task being assigned to a specific core;” each core has a set of tasks. Col. 4, ll. 28-37: Application cores connect to flash memory 106, which stores instructions executable by those cores for operating system and task procedures.
Claim 7
CACCAMO discloses wherein the first memory job is performed on data of a data flash memory of the first core, and the second memory job is performed on code of
a code flash memory of the first core. Col. 7, ll.1-18: Flash persistently stores “application and/or operating system code, read-only data” and initialization values. Task images are stored in flash and loaded into main memory at boot. Col. 6, ll.33-46: Task partitioning involves “each task being assigned to a specific core;” each core has a task set. Col. 13, ll.4-17: Task code and data images are organized using source files, compiler directives, a linker section, and task descriptors.
Claim 8
CACCAMO discloses wherein the first memory job or the second memory job is performed in the first core, and the third memory job is performed in the second core. Col.6, ll. 33-46: Task partitioning involves “each task being assigned to a specific core;” each core has a task set. Col.4, ll. 28-37: Application cores connect to flash memory 106 and execute instructions for operating system and task procedures.
Claim 10
CACCAMO discloses wherein the first memory job is performed on data of a data flash memory of the first core, the second memory job is performed on code of a code flash memory of the first core, and the third memory job is performed on data of a data flash memory of the second core or is performed on code of a code flash memory of the second core. Col.7 ll. 1-18: Flash stores “application and/or operating system code, read-only data” and initialization values. Task images are stored in flash and loaded into main memory at boot. Col. 6, ll. 33-46: Tasks are assigned to particular cores, with a task set for each core. Col. 13, ll. 4-17: Source files, compiler directives, a linker section, and task descriptors organize task code and data images.
Claim 12
CACCAMO discloses wherein the flash memory includes a data flash memory and a code flash memory. Col. 7, ll. 1-18: Flash persistently stores “application and/or operating system code, read-only data” and initialization values. Permanent task images are loaded into main memory at boot.
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 flash memory organization of PARK-KIFFMEIER to incorporate the persistent code and initialization data image arrangement taught by CACCAMO. One of ordinary skill in the art would be motivated to integrate that arrangement into PARK-KIFFMEIER, with a reasonable expectation of success, in order to preserve executable code and initialization data across power cycles and make them available at startup by retaining the images in flash for boot loading, as supported by CACCAMO at col. 7, ll. 1-18.
Claim 15
CACCAMO discloses wherein the first memory job is performed on data of a data flash memory of the first core, and the second memory job is performed on code of a code flash memory of the first core. Col. 7, ll. 1-18: Flash stores “application and/or operating system code, read-only data” and initialization values; task images are loaded from flash at boot. Col. 6, ll. 33-46: Tasks are assigned to particular cores, with a task set for each core.
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 first and second memory jobs of PARK-KIFFMEIER to incorporate the loading of persistent initialization data and program code from flash taught by CACCAMO. One of ordinary skill in the art would be motivated to integrate that allocation of flash read operations into PARK-KIFFMEIER, with a reasonable expectation of success, in order to restore the first core’s executable program and initialization state after a power cycle by loading both from persistent flash images at startup, as supported by CACCAMO at col. 7, ll. 1-18.
Claims 5 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over PARK, in view of KIFFMEIER, further in view of Toku, U.S. PG-Publication No. 2020/0019436 A1 (hereinafter TOKU).
Claim 5
TOKU discloses wherein the first task, the second task, and the third task have a same priority and are executed as background tasks or extended tasks such that
no preemption occurs among the first task, the second task, and the third task. ¶ 0216: In operation mode M4, tasks RTS1, RTS2, and RTS3 have “a same high priority” and execute sequentially in the stated order on one core. ¶ 0220: Explaining mode M4, the last task “needs to wait for the execution of the other tasks being ended.”
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 scheduling of the three flash tasks of PARK-KIFFMEIER to incorporate the equal priority sequential execution policy taught by TOKU. One of ordinary skill in the art would be motivated to integrate that policy into PARK-KIFFMEIER, with a reasonable expectation of success, in order to reduce the execution time of the active task by giving it the core’s available processing resources without alternative execution with its peers, as taught by TOKU at ¶ 0225.
Claim 14
TOKU discloses wherein the first task and the second task have a same priority and are executed as background tasks or extended tasks such that no preemption occurs between the first and second tasks. ¶ 0216: Mode M4 executes tasks having “a same high priority” sequentially in their stated order. ¶ 0220: The last task “needs to wait for the execution of other tasks being ended.”
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 scheduling of the three flash tasks of PARK-KIFFMEIER to incorporate the equal priority sequential execution policy taught by TOKU. One of ordinary skill in the art would be motivated to integrate that policy into PARK-KIFFMEIER, with a reasonable expectation of success, in order to reduce the execution time of the active task by giving it the core’s available processing resources without alternative execution with its peers, as taught by TOKU at ¶ 0225.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over PARK, in view of KIFFMEIER, further in view of CACCAMO, further in view of Pala et al., U.S. PG-Publication No. 2022/0116213 A1 (hereinafter PALA).
Claim 9
PALA discloses wherein the first core includes a host core, and the second core includes an HSM core. ¶ 0073: Computing device 202 includes application executing “host cores” 202a and a physically separate “HSM code” 202b that performs cryptographic functions and key management. ¶ 0071: Computing core 202b can perform the function of HSM 206 or its computing core, permitting the separate HSM to be omitted.
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 processor architecture of PARK-KIFFMEIER-CACCAMO to incorporate the host core and protected HSM core arrangement taught by PALA, with the third memory job implemented as a protected key read by the HSM core. One of ordinary skill in the art would be motivated to integrate that arrangement into PARK-KIFFMEIER-CACCAMO, with a reasonable expectation of success, in order to protect cryptographic keys against direct host access by performing the key read within the HSM’s protected memory environment, as taught by PALA at ¶ 0075.
Claims 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Park et al., U.S. PG-Publication No. 2023/0153029 A1 (hereinafter PARK), in view of Kiffmeier et al., U.S. PG-Publication No. 2014/0215270 A1 (hereinafter KIFFMEIER), further in view of Pala et al., U.S. PG-Publication No. 2022/0116213 A1 (hereinafter PALA).
Claim 16
PARK discloses a computing device including a flash driver configured to perform a memory job on a flash memory. ¶ 0114: The memory driver accesses external memory and memory inside the microcontroller. ¶ 0115: The flash driver FIs “reads and writes to a flash memory.” ¶ 0122: The architecture connects application software, the runtime environment, the nonvolatile memory manager NVM, the memory Interface MemIf, flash EEPROM emulation Fee, and the flash driver FIs.
PARK discloses one or more processors. ¶ 0213: Computer readable instructions control “at least one processing element” to implement the disclosed method.
PARK discloses a communication interface configured to communicate with an external device. ¶ 0096: Supplies external device drivers and interfaces for peripherals including communication.
PARK discloses a memory configured to load thereon a computer program executed by the one or more processors. ¶ 0214: The executable code may be recorded on a medium including RAM.
PARK discloses a non-transitory storage configured to store therein the computer program. ¶ 0214: The code may be recorded in ROM or flash memory.
PARK discloses wherein the computer program includes instructions to perform. ¶ 0213: Computer readable instructions implement the disclosed embodiments.
PARK does not expressly disclose a first task that executes a first main function for performing a first memory job of the first core, the first task being terminated when the flash driver is idle; and a second task that executes a second main function for performing a second memory job of the first core, the second task being terminated when the flash driver is idle.
KIFFMEIER discloses a first task that executes a first main function for performing a first memory job of the first core, the first task being terminated when the flash driver is idle. ¶ 0059, Table 2: MEMIF_IDLE means: “The underlying abstraction module or device driver is currently idle.” ¶ 0058, Table 1: GetStatus returns module status independently of GetJobResult.
KIFFMEIER discloses a second task that executes a second main function for performing a second memory job of the first core, the second task being terminated when the flash driver is idle. ¶ 0028: First and second memory operations execute as respective asynchronous jobs. ¶ 0059, Table 2: Distinguishes idle, busy, and internal management states.
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 flash job completion handling of PARK to incorporate the separate driver status query taught by KIFFMEIER, retaining the first and second task activations until the flash driver is idle and then terminating those activations. One of ordinary skill in the art would be motivated to integrate that status query into PARK, with a reasonable expectation of success, in order to reduce the risk of prematurely handling control to a dependent flash operation by making the preceding task’s termination reflect the driver’s availability, as supported by KIFFMEIER at ¶ 0027 and ¶ 0059, Table 2.
PARK-KIFFMEIER does not expressly disclose a multi-core MCU including a first core and a second core using the flash driver; and a third task that executes a third main function for requesting that the second core perform a third memory job of the second core, the third task being terminated when a third memory job completion response is received from the second core.
PALA discloses a multi-core MCU including a first core and a second core using the flash driver. ¶ 0064: Computing device 202 may be a microcontroller. ¶ 0073: Computing device 202 includes host cores 202a and HSM core 202b.
PALA discloses a third task that executes a third main function for requesting that the second core perform a third memory job of the second core, the third task being terminated when a third memory job completion response is received from the second core. ¶ 0099: The key loader requests HSM key loading through the HSM driver. ¶ 0104: Loading copies the key from HSM nonvolatile memory into volatile memory. ¶ 0113: Loading is executed “asynchronously by HSM B1” when the key is not already loaded. ¶ 0107: The HSM reports the “key loaded” state through its driver.
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 MCU architecture and requested memory job execution of PARK-KIFFMEIER to incorporate the host and HSM loading request and response arrangement taught by PALA, retaining the third requesting task until the HSM reports completion of its flash key load and then ending the task. One of ordinary skill in the art would be motivated to integrate that arrangement into PARK-KIFFMEIER, with a reasonable expectation of success, in order to protect cryptographic keys against direct host access by executing the key read within HSM’s protected memory environment, as taught by PALA at ¶ 0075.
Claim 17
PALA discloses wherein the first core includes a host core, and the second core includes an HSM core. ¶ 0073: Identifies host cores 202a and HSM core 202b.
Claim 18
PALA discloses wherein the one or more processors are configured to
perform the first memory job on data of a data flash memory of the first core, the second memory job on code of a code flash memory of the first core, and the third memory job on data of a data flash memory of the second core or on code of a code flash memory of the second core. ¶ 0062: Core 202a has associated storage 204 for data DAT and program PRG. ¶ 0063: Storage 204 may include RAM 204a and flash EEPROM 204b. ¶ 0076: Host application PRG executed on host cores 202a. ¶ 0104: The HSM loads a key from its nonvolatile memory into volatile memory.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over PARK, in view of KIFFMEIER, further in view of PALA, further in view of Toku, U.S. PG-Publication No. 2020/0019436 A1 (hereinafter TOKU).
Claim 19
TOKU discloses wherein the first task, the second task, and the third task have a same priority and are executed as background tasks or extended tasks such that no preemption occurs among the first task, the second task, and the third task. ¶ 0216: Mode M4 executed three tasks having “a same high priority” sequentially on one core. ¶ 0220: The last task “needs to wait for the execution of the other tasks being ended.”
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 scheduling of the three first core tasks of PARK-KIFFMEIER-PALA to incorporate the equal priority sequential execution policy taught by TOKU. One of ordinary skill in the art would be motivated to integrate that policy into PARK-KIFFMEIER-PALA, with a reasonable expectation of success, in order to reduce the execution time of the active task by fiving it the core’s available processing resources without alternative execution with its peers, as taught by TOKU at ¶ 0225.
Conclusion
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 9-5:30 CT.
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 September 26, 2026
Prosecution Insights