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 .
Status of Claims
Claims 1-18 are pending. Claims 1-18 have been amended as per Applicants' request.
Papers Submitted
It is hereby acknowledged that the following papers have been received and placed of record in the file:
Amended Claims as filed on May 23, 2024
Information Disclosure Statement
The information disclosure statement (IDS) submitted on May 23, 2023 is/are in compliance with the provisional of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 9 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.
The term “pure convenience” in claim 9 is a relative term which renders the claim indefinite. The term “pure convenience” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. To what degree convenience does pure convenience refer to also what is convenience to one person might not be convenience to another, therefore examiner is unable to ascertain the scope of what “pure convenience” is referring to.
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.
Claim 1-7, 10-14, and 16-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iuliano et al. (US 2021/0224123) (hereinafter Iuliano) (published July 22, 2021) in view of Decker et al. (US 2018/0039445) (hereinafter Decker) (published February 08, 2018) and KIMURA et al. (US 2018/0329692) (hereinafter Kimura) (published November 15, 2018).
Regarding Claims 1, 16, 17, and 18, taking claim 16 as exemplary, Iuliano discloses a processing device; and a memory,
“This is illustrated in a simple example in FIG. 1 which shows a shared memory 100 partitioned into a plurality of memory portions 101 and a SIMD processor 102 having five processing elements 109-113 configured to process in parallel a workgroup ‘A’ comprising five tasks 103-107” (Iuliano [0100])
wherein each of a plurality of functions of the vehicle is configured to execute a corresponding one of a plurality of applications in a corresponding one of a plurality of memory portions of the shared memory, and
“There is provided a memory subsystem for use with a single-instruction multiple-data (SIMD) processor comprising a plurality of processing units configured for processing one or more workgroups each comprising a plurality of SIMD tasks, the memory subsystem comprising” (Iuliano [0006] each workgroup would be a function and each task an application)
“a shared memory partitioned into a plurality of memory portions for allocation to tasks that are to be processed by the processor” (Iuliano [0007])
wherein the processing device includes: a processor; and a data storage storing instructions that, when executed by the processor, cause the processing device to:
“There is provided a memory subsystem configured to perform a method as described herein. There is provided computer program code for performing a method as described herein. There is provided a non-transitory computer readable storage medium having stored thereon computer readable instructions that, when executed at a computer system, cause the computer system to perform a method as described herein” (Iuliano [0083])
for each function of the functions: register the function for a memory allocation service;
“There is provided a memory subsystem for use with a single-instruction multiple-data (SIMD) processor comprising a plurality of processing units configured for processing one or more workgroups each comprising a plurality of SIMD tasks, the memory subsystem comprising” (Iuliano [0006] each workgroup would be a function)
“a resource allocator configured to, in response to receiving a memory resource request for first memory resources in respect of a first-received task of a workgroup, allocate to the workgroup a block of memory portions sufficient in size for each task of the workgroup to receive memory resources in the block equivalent to the first memory resources” (Iuliano [0008])
determine a location and a size of the corresponding one of the memory portions of the shared memory for the function by applying an allocation algorithm;
“a resource allocator configured to, in response to receiving a memory resource request for first memory resources in respect of a task, allocate to the task a contiguous virtual memory block and cause the translation unit to associate the task with a plurality of physical addresses of memory portions each corresponding to a region of the virtual memory block, said memory portions collectively embodying the complete virtual memory block” (Iuliano [0047])
“On receiving a memory request in respect of a first task of a workgroup, the resource allocator checks the current window for a position in which the contiguous block of memory to be reserved for the workgroup can fit. This will be termed a “fine check”. The resource allocator identifies unallocated memory portions using the fine status array 207. The resource allocator may start at the lowest address of the current window and scan in the direction of increasing memory address so as to identify the lowest possible starting position for the block and minimise fragmentation of the shared memory. Any suitable algorithm for identifying a contiguous set of memory portions which can accommodate the block of memory may be used” (Iuliano [0127])
execute the corresponding one of the applications of the function on the corresponding one of the memory portions; and
“Execution of the workgroup may then be performed 906, with each task using its allocated shared memory resources of the block allocated to the workgroup” (Iuliano [0145])
wherein the allocation algorithm allocates dynamically the corresponding one of the memory portions.
“An allocation mechanism is typically provided to allow processing tasks running on the different processing units to each request one or more areas of the shared memory. This enables the shared memory to be dynamically assigned for use by the tasks being performed at the processing units” (Iuliano [0003])
But does not explicitly state a vehicle comprising: and the plurality of functions being vehicle functions and after the corresponding one of the applications of the function is executed, disconnect the function from the memory allocation service.
Decker discloses a vehicle comprising: and the plurality of functions being vehicle functions.
“Another example aspect of the present disclosure is directed to a system for tracking memory allocation within shared memory in a vehicle. The system includes one or more processors and one or more memory devices” (Decker [0005])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043])
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the memory allocation system of Iuliano for use in the vehicle computing environment disclosed by Decker, such that the functions executed by Iuliano correspond to vehicle functions executing within a vehicle. Iuliano teaches a dynamically allocated shared-memory subsystem that allocates, manages, and deallocates memory for processing tasks to improve memory utilization and reduce fragmentation. Decker teaches that a vehicle includes one or more processors and shared memory used by multiple vehicle components and processes. A person of ordinary skill in the art would have recognized that Iuliano's dynamic shared-memory allocation techniques are equally applicable to Decker's vehicle computing environment because the underlying problem of efficiently allocating shared memory among multiple concurrently executing software functions is the same regardless of whether the computing system is a general-purpose processor or a vehicle computing platform. The combination would have merely involved applying the known memory allocation techniques of Iuliano to the known vehicle system of Decker according to their established functions, yielding the predictable result of dynamically allocating shared memory among vehicle functions while improving memory utilization, reducing fragmentation, and permitting efficient execution of multiple vehicle applications.
Kimura discloses after the corresponding one of the applications of the function is executed, disconnect the function from the memory allocation service.
“When the FaaS system 42 detects an event, the FaaS system 42 loads the function program corresponding to the detected event to a memory and executes the function. After executing the function, the FaaS system 42 may remove the function program from the memory. Thus, instead of being previously activated and brought in a standby state, the function is automatically activated when an event occurs and is executed only for a short time” (Kimura [0054])
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify the system in the combination of Iuliano and Decker to incorporate the function lifecycle management taught by Kimura, such that after a corresponding vehicle function has been executed, the function is disconnected from the memory allocation service by removing it from memory. Kimura teaches that a Function-as-a-Service (FaaS) system loads a function into memory only when an event occurs, executes the function, and then removes the function from memory after execution, thereby avoiding unnecessary occupation of memory resources. A person of ordinary skill in the art would have recognized that applying Kimura's post-execution function removal technique to the dynamically allocated shared-memory system of Iuliano operating within Decker's vehicle computing environment would have predictably improved memory efficiency by releasing allocated memory after a vehicle function completes execution, making that memory available for subsequent vehicle functions. The combination would have merely involved applying the known memory management technique of Kimura to the known dynamic memory allocation system of Iuliano in the known vehicle computing environment of Decker according to their established functions, yielding the predictable result of disconnecting completed vehicle functions from the memory allocation service, reducing unnecessary memory usage, and improving the availability of shared memory resources for other vehicle applications.
Regarding Claim 2, Iuliano and Decker further discloses wherein all of the vehicle functions are configured to send a request concerning the shared memory.
“The resource allocator 201 is operable to receive requests to allocate memory resources to tasks executing at the processing units 301 of the computer system. Each of the tasks or processing units could be a requestor 205. One or more of the processing units may be SIMD processors configured to execute a workgroup of tasks in parallel. Each task of a workgroup may request an allocation of memory from the resource allocator—depending on the particular architecture of the system, such a request could be made on behalf of the task (e.g. by a work scheduler on assigning the task to a parallel processor) or by the task itself” (Iuliano [0108] each of the functions/workgroups would have tasks requesting memory from the resource allocator)
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 3, Iuliano and Decker further discloses wherein at least two of the vehicle functions are configured to allocate the corresponding one of the memory portions by applying the allocation algorithm.
“The shared memory comprises an existing block of memory portions 508 allocated to a workgroup B (the respective memory portions are marked ‘B’ in the figure). Consider the point at which a first memory request is received in respect of a task 509 of a second workgroup A. On receiving a memory request for task 509 a block 514 of memory portions (marked ‘A’) is allocated to the shared memory as shown in the figure. Thus, as described above, the allocation of the block of memory portions for the whole workgroup is performed in response to receiving the first request for memory in respect of the tasks of the workgroup” (Iuliano [0117] see fig. 5)
“Any suitable algorithm for identifying a contiguous set of memory portions which can accommodate the block of memory may be used” (Iuliano [0127])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 4, Iuliano and Decker further discloses wherein the vehicle functions configured to allocate the corresponding one of the memory portions provide a full shared memory implementation.
“Allocated portions of the shared memory may be accessed by the processing units by means of input/output arbiter 204. The I/O arbiter 204 arbitrates access to the shared memory between a plurality of units (e.g. processing units or other units that are able to access the shared memory) which submit access requests (e.g. read/writes) over interface 211 (which may comprise one or more hardwired links between which the I/O arbiter arbitrates)” (Iuliano [0104])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 5, Iuliano and Decker further discloses wherein at least one of the vehicle functions that is configured to send the request registers for the memory allocation service with at least one of the vehicle functions that is configured to allocate the corresponding one of the memory portions.
“a resource allocator configured to, in response to receiving a memory resource request for first memory resources in respect of a first-received task of a workgroup, allocate to the workgroup a block of memory portions sufficient in size for each task of the workgroup to receive memory resources in the block equivalent to the first memory resources” (Iuliano [0008] the vehicle function configured to allocate memory portions is the resource allocator and the vehicle functions requesting the allocation are the workgroups)
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 6, Iuliano and Decker further discloses wherein all of the vehicle functions are configured to allocate the corresponding one of the memory portions and provide a full shared memory implementation.
“a resource allocator configured to, in response to receiving a memory resource request for first memory resources in respect of a first-received task of a workgroup, allocate to the workgroup a block of memory portions sufficient in size for each task of the workgroup to receive memory resources in the block equivalent to the first memory resources” (Iuliano [0008])
“Allocated portions of the shared memory may be accessed by the processing units by means of input/output arbiter 204. The I/O arbiter 204 arbitrates access to the shared memory between a plurality of units (e.g. processing units or other units that are able to access the shared memory) which submit access requests (e.g. read/writes) over interface 211 (which may comprise one or more hardwired links between which the I/O arbiter arbitrates)” (Iuliano [0104])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 7, Iuliano and Decker further discloses comprising if two or more of the vehicle functions are registered simultaneously and each of the two or more of the vehicle functions is configured to allocate the memory portion, applying a prioritizing algorithm to determine a single dominating vehicle function that applies the allocation algorithm.
“Any suitable mechanism for prioritising memory requests may be implemented. For example, the resource allocator could be configured to preferentially service requests from the same requestor 205 from which the initial request which led to the block being allocated was received. A requestor could be preferred by increasing the frequency at which its memory requests are serviced relative to other requestors. A requestor could be preferred by, following allocation of a block, repeatedly servicing memory requests received from that same requestor until a memory request is received in respect of a task belonging to a different workgroup. The resource allocator may use the data structure 206 described above to identify which memory requests correspond to workgroups for which a memory block has already been reserved, and hence which memory requests should be prioritised” (Iuliano [0123] the resource allocator is the single dominating vehicle function)
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 10, Iuliano and Decker further discloses comprising wherein a centralized software separate from the vehicle functions applies the allocation algorithm.
“a resource allocator configured to, in response to receiving a memory resource request for first memory resources in respect of a first-received task of a workgroup, allocate to the workgroup a block of memory portions sufficient in size for each task of the workgroup to receive memory resources in the block equivalent to the first memory resources” (Iuliano [0008] the resource allocator is separate from the workgroups)
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 11, Iuliano further discloses comprising wherein the centralized software determines non-continuous locations of the memory portions.
“The plurality of memory portions associated with a task do not need to be contiguous in the shared memory. However, from the point of view of the task, the task will receive an allocation of a contiguous block of memory. This is achieved by the resource allocator being configured to allocate to a task a contiguous virtual block of memory when that same task is in fact associated at the translation unit with a potentially non-contiguous set of memory portions” (Iuliano [0151])
Regarding Claim 12, Iuliano further discloses comprising wherein the centralized software determines continuous locations of the memory portions.
“The resource allocator may be configured to allocate the block as a contiguous block of memory portions” (Iuliano [0009])
Regarding Claim 13, Iuliano and Decker further discloses comprising wherein the size of each of the memory portions is determined dynamically based on a corresponding one of the vehicle functions.
“The resource allocator is configured to allocate memory resources to the entire workgroup on first receiving an allocation request in respect of a task of that workgroup. An allocation request typically indicates the size of the memory resources required—for example, a task might require a certain number of bytes or memory portions” (Iuliano [0110] the size is dynamic based on the workgroup/function)
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Regarding Claim 14, Iuliano, Kimura, and Decker further discloses comprising, for each vehicle function of the vehicle functions, after the disconnecting the vehicle function from the memory allocation service, removing an allocation to the corresponding one of the memory portions of the shared memory.
“The resource allocator may be configured to deallocate the slice of shared memory allocated to each task as soon as processing of that task completes at the processing unit (i.e. without waiting for the entire workgroup to complete). This ensures that memory portions which are no longer required are released as soon as possible for use by other tasks” (Iuliano [0116])
“When the FaaS system 42 detects an event, the FaaS system 42 loads the function program corresponding to the detected event to a memory and executes the function. After executing the function, the FaaS system 42 may remove the function program from the memory. Thus, instead of being previously activated and brought in a standby state, the function is automatically activated when an event occurs and is executed only for a short time” (Kimura [0054])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
Claim 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iuliano (published July 22, 2021), Decker (published February 08, 2018), and Kimura (published November 15, 2018) as applied to claim 7 above, and further in view of MITSUTANI (US 2020/0301460) (hereinafter Mitsutani) (published September 24, 2020).
Regarding Claim 8, the combination of Iuliano, Decker, and Kimura disclosed the method of claim 7 but does not explicitly state wherein the prioritizing algorithm includes a ranking of the multiple two or more of the vehicle functions, starting with one of the vehicle function functions that is most relevant for vehicle safety and/or security.
Mitsutani discloses wherein the prioritizing algorithm includes a ranking of the multiple two or more of the vehicle functions, starting with one of the vehicle function functions that is most relevant for vehicle safety and/or security.
“Regarding the priority ranks, by assigning a high priority rank to the category of vehicle safety, the supply of power (electric energy) or energy (electric energy) for implementing functions, performances, etc. necessary for the safety, which is required of the vehicle, can be performed with higher priority” (Mitsutani [0121])
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify the system in the combination of Iuliano, Decker, and Kimura to prioritize vehicle functions according to the priority ranking disclosed by Mitsutani, including ranking vehicle functions such that functions most relevant to vehicle safety and/or security receive the highest priority. Mitsutani teaches assigning higher priority to vehicle safety functions so that the resources necessary to implement safety-related functions are provided before lower-priority functions. A person of ordinary skill in the art would have recognized that incorporating such a priority ranking into the vehicle computing environment of Decker and the dynamic memory allocation techniques of Iuliano would allow limited computing and memory resources to be preferentially allocated to safety- and security-critical vehicle functions. The combination would have merely involved applying the known prioritization scheme of Mitsutani to the known vehicle memory management system resulting from the combination of Iuliano and Decker according to its established function, yielding the predictable result that memory resources are allocated first to vehicle functions having the greatest relevance to vehicle safety and/or security while maintaining efficient dynamic memory allocation for other vehicle functions.
Regarding Claim 9, Mitsutani further discloses wherein the ranking ends with at least one of the vehicle functions that is a pure convenience function.
“In the example of FIG. 2, the priority ranks from “P1” for the highest priority to “P8” for the lowest priority are defined for the categories including safety, security, compliance, basic performance (system startup, normal traveling), parts protection, marketability (power, quietness, driving stability, nominal fuel efficiency, advanced devices), economics, and added value” (Mitsutani [0048] the added value rank would only contain convenience functions)
Claim 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iuliano (published July 22, 2021), Decker (published February 08, 2018), and Kimura (published November 15, 2018) as applied to claim 14 above, and further in view of Bernat et al. (US 2020/0133492) (hereinafter Bernat) (published April 30, 2020).
Regarding Claim 15, the combination of Iuliano, Decker, and Kimura disclosed the method of claim 7 but does not explicitly state comprising, for each vehicle function of the vehicle functions, erasing all data stored in the corresponding one of the memory portions.
Bernat, Iuliano, and Decker discloses comprising, for each vehicle function of the vehicle functions, erasing all data stored in the corresponding one of the memory portions.
“Upon relocating/deallocating the data at fragment 760, the storage system 750 may perform garbage collection on the formerly pinned erase block to delete the data stored at the erase block and make the erase block available for storage of new data” (Bernat [0235] upon deallocation the data is erased/deleted)
“The resource allocator may be configured to deallocate the slice of shared memory allocated to each task as soon as processing of that task completes at the processing unit (i.e. without waiting for the entire workgroup to complete). This ensures that memory portions which are no longer required are released as soon as possible for use by other tasks” (Iuliano [0116])
“One of the vehicles can be an aircraft 600. The aircraft 600 can include one or more computing device(s) 602 as described in reference to FIG. 5. The one or more computing device(s) 602 can include shared memory. The aircraft 600 can include a first component 604. The first component 604 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a first process. The first process can use the shared memory. The aircraft 600 can include a second component 606. The second component 606 can include one or more computing device(s) as described in reference to FIG. 5 and/or can access the one or more computing device(s) 602 for running a second process. The second process can use the shared memory” (Decker [0043] the vehicle functions are the processes)
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify the system in the combination of Iuliano, Decker, and Kimura to erase data stored in the memory portion allocated to a vehicle function when it is being deallocated, as taught by Bernat. Bernat teaches performing garbage collection after data has been relocated or deallocated to delete the data stored in the memory block and make the memory available for subsequent use. A person of ordinary skill in the art would have recognized that incorporating Bernat's data erasure technique into the dynamic shared-memory management of Iuliano as applied to the vehicle computing environment of Decker would ensure that memory allocated to completed vehicle functions is cleared before being reused by subsequent functions. The combination would have merely involved applying the known memory cleanup technique of Bernat to the known dynamic memory allocation system resulting from the combination of Iuliano and Decker according to its established function, yielding the predictable result of removing residual data from deallocated memory, improving memory availability for subsequent allocations, and preventing stale data from remaining in reused memory portions.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kanai et al. (US 2004/0268083) discloses the use of the main memory as shared memory to facilitate communication between two threads.
Fang et al. (US 2021/0192867) discloses a controller capable of managing shared memory resources including providing memory allocation provided for data collection operations, buffering and caching of parameter values.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIDNEY LI whose telephone number is (571)270-5967. The examiner can normally be reached Monday to Friday 10:00 AM to 6:00 PM.
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, Arpan P Savla can be reached at (571) 272-1077. 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.
/S.L./Examiner, Art Unit 2137
/PRASITH THAMMAVONG/Primary Examiner, Art Unit 2137
Prosecution Insights