DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 30-33 and 35-56 are pending in this application.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant’s submission filed on 11/17/2025 has been entered.
Claims 30-33 and 35-56 are presented for examination. Claims 30, 35, 36, 45-47, and 53-55 have been amended. Claims 1-29 and 34 are canceled.
Response to Arguments
Applicant’s arguments regarding the rejections of claims 30-56 under 35 U.S.C. 112b have been fully considered and are persuasive. The rejections have been withdrawn. However, new 35 U.S.C. 112b rejections are applied to claims 30-33 and 35-56.
Applicant's arguments regarding the 35 U.S.C. 102 rejections of claims 30-33 and 35-56 have been fully considered but are moot in light of the references being applied in the current rejection.
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.
Claims 30-33 and 35-56 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claims 30, 45-47, and 53-55 (line numbers refer to claim 30):
Line 10 recites “the computation results” and it is unclear if this refers to “the plurality of computation results”.
Claims 31-33, 35-44, 48-52, and 56 are dependent claims of claims 30 and 47 and fail to resolve the deficiencies of claims 30 and 47, so they are rejected for the same reasons as 30 and 47 are rejected for.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 30-33, 35, 37, 39-41, and 44-56 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Ditty et al. (US 20230176577 A1 hereinafter Ditty).
As per claim 30, Ditty teaches a computer-implemented method for processing data, comprising: providing multiple computing services using at least two different and disjoint hardware resources to avoid a common cause failure ([0298] In the example shown, each SOC 2002 has an associated memory system 2004. In the example shown, SOC 2002(1) accesses a respective memory system 2004(1), and SOC 2002(2) accesses a respective memory system 2004(2). In the example shown, the memory systems 2004(1), 2004(2) are separate and independent from one another so that a fault, bottleneck, or other behavior occurring in one memory system 2004 does not impact the operation of the other memory system; [0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors; [0282] Each of SoCs (100), (200), and (803) may be connected to power management integrated circuits (“PMIC”) (326) to provide independent power management. In an example non-limiting embodiment, each one of the SoCs (100), (200), and (803) can be provided with independent power supplies and associated mechanisms. The different power providing mechanisms for the different processors could be differently designed to provide additional coverage on a systematic level. In some embodiments, there will be three independent power supplies—one for each of the three independently-functioning processors); in response to a request for a computation of a single computation task, redundantly carrying out the single computation task in parallel using at least two of the multiple computing services on the at least two different and disjoint hardware resources to obtain a plurality of computation results for the single computation task ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; [0298] In the example shown, each SOC 2002 has an associated memory system 2004. In the example shown, SOC 2002(1) accesses a respective memory system 2004(1), and SOC 2002(2) accesses a respective memory system 2004(2). In the example shown, the memory systems 2004(1), 2004(2) are separate and independent from one another so that a fault, bottleneck, or other behavior occurring in one memory system 2004 does not impact the operation of the other memory system; [0328] In preferred embodiments, especially when Secondary Computer (200) comprises the same or similar hardware as Primary Computer (100), Secondary Computer (200) runs redundant diverse software to detect faults in perception and dynamic driving task; ; [0282] Each of SoCs (100), (200), and (803) may be connected to power management integrated circuits (“PMIC”) (326) to provide independent power management); and comparing the plurality of computation results with each other to assess a validity of the computation results ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; the redundancy allows error detection and error correction since the output from lockstep operations can be compared to determine if there has been a fault and potentially corrected with error correction techniques).
As per claim 31, Ditty teaches the method as recited in claim 30, wherein at least two of the multiple computing services each use different resources, the different resources including hardware resources and/or software resources ([0272] FIG. 15 illustrates the diverse, redundant processing that the SoC of the technology provides to enhance functional safety. First, as shown in FIG. 15, Hardware Acceleration Cluster (400) can perform redundant, diverse processing in both PVA (402) and DLA (401); [0187] The module can include one or more embedded programmable vision accelerators (“PVAs”); [0187] Acceleration Cluster (400) may also include one or more deep learning accelerators (“DLAs”).).
As per claim 32, Ditty teaches the method as recited in claim 30, wherein at least one of the multiple computing services is configured to carry out at least one of the following elements: a) a computer program, b) a computation task, c) evaluating an algorithm in the field of artificial intelligence or machine learning, d) inference ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0744] the neural network can be configured to perform inferencing and other processing tasks.).
As per claim 33, Ditty teaches the method as recited in claim 30, wherein at least two of the multiple computing services are redundant with one another at least in part ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs.).
As per claim 35, Ditty teaches the method as recited in claim 30, further comprising at least one of the following steps: a) scaling of resources associated with at least one computing service of the multiple computing services; b) scaling of resources associated with at least one processing unit, the scaling of the resources encompassing a decrease or an increase in the resources, and c) scaling a number of the at least one processing unit ([0305] For example, to provide scalability, one embodiment provides expansion of the structure shown to additional SOCs 2002 via expansion connector 2018 such that some or all of the SOCs can communicate with one another via expansion connector; [0683] According to one or more embodiments, the SoC can also include a safety cluster engine, comprising a plurality of processor cores; [0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs).
As per claim 37, Ditty teaches the method as recited in claim 35, further comprising: carrying out load balancing between the multiple computing services and/or between multiple processing units ([0373] change allocations of CPU cores 4006 to virtualized CPUs 4004 depending on a variety of factors including priority, load balancing; [0394] a GPU can be load balanced among different virtual machines 4002).
As per claim 39, Ditty teaches the method as recited in claim 30, further comprising: using hardware resources of at least one of the following types: a) a computer that includes one or multiple processor cores, b) a central processing unit, c) a graphics processing unit, d) a programmable logic circuit, e) a hardware circuit, f) an application- specific circuit, g) a microcontroller, h) a cloud system ([0683] According to one or more embodiments, the SoC can also include a safety cluster engine, comprising a plurality of processor cores; [0685] The Central Processing Unit complex comprises a plurality of CPU cores, implemented in some embodiments as one or more clusters of CPU cores; [0703] In preferred embodiments, the computer may include a plurality (e.g., 8 or more) SoCs and a similar number of discrete GPUs, each GPU being coupled to a microcontroller and a corresponding SoC; [0279] FIG. 15 illustrates an embodiment with a single Advanced SoC (100). Of course, vehicle (50) typically includes additional processors, ASICs, and SoCs; [0284] As illustrated in FIG. 17, the Advanced SoCs (100) are each connected to a Microcontroller (“MCU”) (803). MCU may comprise an SoC, stand-alone ASIC, or other processor; [0303] For example, processor(s) 2010 could in some implementations be located in the cloud).
As per claim 40, Ditty teaches the method as recited in claim 30, further comprising: ascertaining and/or providing and/or at least temporarily storing an identification that characterizes at least one hardware resource of the at least two different hardware resources; evaluating or validating a configuration of the at least two different hardware resources; and assessing a validity of results that are obtained using the multiple computing services ([[0219] the Advanced SoC preferably includes a Computer Vision Network-on-Chip and SRAM (“CVNAS”), for providing a high-bandwidth, low-latency SRAM for the Hardware Acceleration Cluster; [0171] The deep-learning infrastructure is capable of fast, real-time inferencing, and may use that capability to evaluate and verify the health of the processors, software, and associated hardware in Vehicle (50); [0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; the redundancy allows error detection and error correction since the output from lockstep operations can be compared to determine if there has been a fault and potentially corrected with error correction techniques).
As per claim 41, Ditty teaches the method as recited in claim 30, further comprising: ascertaining and/or monitoring an integrity of at least one of the following elements: a) at least one computing service of the multiple computing services, b) at least one hardware resource of the at least two different hardware resources, c) at least one processing unit ([0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; the redundancy allows error detection and error correction since the output from lockstep operations can be compared to determine if there has been a fault and potentially corrected with error correction techniques; [0430] the safety watchdog monitor 5010 might perform a sensor data integrity check in the case of application processes 5002 that are processing sensor data from cameras, RADAR, LIDAR, etc. If the safety watchdog monitor 5010 detects an error or fault, it may propagate an error; [0461] FIG. 38 and FIG. 39 show example error handling sequences for hardware and software error detection, respectively. The FIG. 38 hardware error handling sequence begins with the SOC 5054 hardware generating a fault (“1”); [0683] According to one or more embodiments, the SoC can also include a safety cluster engine, comprising a plurality of processor cores;).
As per claim 44, Ditty teaches the method as recited in claim 30, further comprising: shifting a geographical position of at least one of the following elements: a) at least one computing service of the multiple computing services, b) at least one hardware resource of the at least two different hardware resources, c) at least one processing unit; wherein the shifting is based on at least one of the following elements: A) a geographical position of at least one user of at least one of the multiple computing services, B) a signal propagation time between the at least one user and at least one of the multiple computing services (Fig. 4; [0710] The datacenter may be well-suited to perform other tasks, such as receiving image and object detection information collected by a vehicle and transmitted over the wireless network, executing a neural network on one or more of the GPU servers, using the image information as input, comparing the results of the neural network run on one or more of the GPU servers with the object detection information received from the vehicle, and sending a wireless control signal to the vehicle instructing the vehicle to instruct the passengers and execute a safe parking maneuver if the result of the comparison falls below a confidence threshold; [0120] FIG. 4 shows an example self-driving vehicle (50). Vehicle (50) in the example shown comprises a passenger vehicle such as a car or truck that can accommodate a human driver; [0207] In the preferred embodiment shown in FIG. 8 and FIG. 9, the Advanced SoC includes a Hardware Acceleration Cluster (400), which includes optimized hardware accelerators and a large on-chip memory. The large on-chip memory—in a preferred embodiment, 4 MB SRAM—allows the Hardware Acceleration Cluster (400) to accelerate neural networks; [0262] One or more Advanced SoC (100) can be used to control an autonomous vehicle in a variety of platforms and systems.).
As per claim 45, it is a device claim of claim 30, so it is rejected for similar reasons. Additionally, Ditty teaches a device configured to process data ([0698] Another aspect of the technology may be implemented as a computer for controlling an autonomous vehicle. In one or more embodiments, the computer may be implemented to include a first System-on-a-Chip, a second System-on-a-Chip; [0254] The SoC may be used to process data).
As per claim 46, it is a cloud system claim of claim 30, so it is rejected for similar reasons. Additionally, Ditty teaches a cloud system, comprising: at least one device configured to process data ([0168] The cloud-based, deep-learning infrastructure provides updates to self-driving vehicle (50); [0698] Another aspect of the technology may be implemented as a computer for controlling an autonomous vehicle. In one or more embodiments, the computer may be implemented to include a first System-on-a-Chip, a second System-on-a-Chip; [0254] The SoC may be used to process data).
As per claim 47, it is a computer-implemented method claim of claim 30, so it is rejected for similar reasons. Additionally, Ditty teaches a computer-implemented method for processing data for vehicles, comprising: using at least one computing service that is provided using a device configured to process data ([0698] Another aspect of the technology may be implemented as a computer for controlling an autonomous vehicle. In one or more embodiments, the computer may be implemented to include a first System-on-a-Chip, a second System-on-a-Chip; [0254] The SoC may be used to process data).
As per claim 48, Ditty teaches the method as recited in claim 47, further comprising: sending a request for computation of a computation task; and receiving at least one answer that characterizes a result of the computation ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency;).
As per claim 49, Ditty teaches the method as recited in claim 48, further comprising at least one of the following elements: a) receiving multiple answers, and comparing the multiple answers, b) receiving multiple answers, and selecting at least one of the multiple answers ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; the redundancy allows error detection and error correction since the output from lockstep operations can be compared to determine if there has been a fault and potentially corrected with error correction techniques).
As per claim 50, Ditty teaches the method as recited in claim 49, further comprising: providing a computation task for a motor vehicle, the computation task to be carried out redundantly and outside the vehicle; carrying out the computation task redundantly using redundant software resources and/or using redundant hardware resources, and outside the vehicle, using at least two computing services of the multiple computing services, the at least two computing services each being associated with at least one edge server and/or at least one cloud server, and multiple computation results being obtained (Fig. 6; [0173] FIG. 6 illustrates one embodiment wherein Vehicle (50) provides and receives information via wireless network. Cloud-based infrastructure (5000) includes a plurality of GPU powered servers (5001, 5002, . . . 500N). In the preferred embodiment shown in FIG. 6, each GPU-powered server comprises a plurality of GPUs (802); [0710] The datacenter may be well-suited to perform other tasks, such as receiving image and object detection information collected by a vehicle and transmitted over the wireless network, executing a neural network on one or more of the GPU servers, using the image information as input, comparing the results of the neural network run on one or more of the GPU servers with the object detection information received from the vehicle, and sending a wireless control signal to the vehicle instructing the vehicle to instruct the passengers and execute a safe parking maneuver if the result of the comparison falls below a confidence threshold,).
As per claim 51, Ditty teaches the method as recited in claim 50, further comprising: transferring the multiple computation results to the vehicle ([0710] The datacenter may be well-suited to perform other tasks, such as receiving image and object detection information collected by a vehicle and transmitted over the wireless network, executing a neural network on one or more of the GPU servers, using the image information as input, comparing the results of the neural network run on one or more of the GPU servers with the object detection information received from the vehicle, and sending a wireless control signal to the vehicle instructing the vehicle to instruct the passengers and execute a safe parking maneuver if the result of the comparison falls below a confidence threshold).
As per claim 52, Ditty teaches the method as recited in claim 51, further comprising: receiving the multiple computation results in the vehicle; comparing the multiple computation results; and verifying, based on the comparing, the multiple computation results or carrying out a compensation response ([0710] The datacenter may be well-suited to perform other tasks, such as receiving image and object detection information collected by a vehicle and transmitted over the wireless network, executing a neural network on one or more of the GPU servers, using the image information as input, comparing the results of the neural network run on one or more of the GPU servers with the object detection information received from the vehicle, and sending a wireless control signal to the vehicle instructing the vehicle to instruct the passengers and execute a safe parking maneuver if the result of the comparison falls below a confidence threshold).
As per claim 53, it is a device claim of claim 30, so it is rejected for similar reasons.
As per claim 54, it is a non-transitory computer-readable medium claim of claim 30, so it is rejected for similar reasons. Additionally, Ditty teaches a non-transitory computer-readable memory medium on which are stored commands method for processing data, the commands, when executed by a computer, causing the computer to perform ([0299] The memory systems 2004 at least in part constitute non-transitory memory that store program instructions the associated SOC 2002 executes to perform tasks).
As per claim 55, it is a vehicle claim of claim 30, so it is rejected for similar reasons. Additionally, Ditty teaches a vehicle that includes at least one device for processing data ([0698] Another aspect of the technology may be implemented as a computer for controlling an autonomous vehicle. In one or more embodiments, the computer may be implemented to include a first System-on-a-Chip, a second System-on-a-Chip; [0254] The SoC may be used to process data).
As per claim 56, Ditty teaches the method as recited in claim 30, wherein the method is used for at least one of the following: a) avoiding a systematic multiple failure ([0302] In the example shown, there may be plural microcontroller units 2003(a), 2003(b), with one or more units providing a fallback or redundancy for another or other units in case of failure.), b) avoiding common cause failures ([0298] In the example shown, each SOC 2002 has an associated memory system 2004. In the example shown, SOC 2002(1) accesses a respective memory system 2004(1), and SOC 2002(2) accesses a respective memory system 2004(2). In the example shown, the memory systems 2004(1), 2004(2) are separate and independent from one another so that a fault, bottleneck, or other behavior occurring in one memory system 2004 does not impact the operation of the other memory system;), c) detecting errors during an execution of a computer program ([0287] with redundancy provided through the independence of redundant computation on the plurality of Advanced SoCs. In example non-limiting embodiments, much of the functionality required to provide autonomous operation is duplicated in software or firmware between the different processors. Thus, in some implementations, similar algorithms are run in both Advanced SoCs, or even in all four processors, including the SoCs and dGPUs. In either case, all relevant inputs gathered by sensors are fed into each of the processors. Each of the processors may independently process the sensor data, and independently provides actuation information and/or control signals that may be used to control the vehicle actuators. MCU (803) receives the actuation information and/or control signals from the processors and evaluates them for consistency; [0281] In the example shown in FIG. 16, the third SoC (803) may comprise a microprocessor, including a Lock-Step (“LS”) Tricore (324) and two non-LS TriCores (325). The third SoC (803) may include a safety management unit (“SMU”) (318), and bus interfaces (320), (322). As is well known, lockstep systems are fault-tolerant computer systems that run the same set of operations at the same time in parallel; the redundancy allows error detection and error correction since the output from lockstep operations can be compared to determine if there has been a fault and potentially corrected with error correction techniques), d) providing at least one secure computing service and/or at least one secure processing unit via a cloud system and/or via at least one edge server ([0167] In a preferred embodiment, the cloud-based, deep learning infrastructure uses artificial intelligence to analyze data received from vehicles and incorporate it into up-to-date, real-time neural networks for real-time intelligent inferencing. In a preferred embodiment, the network infrastructure uses a datacenter with GPUs for deep learning as illustrated in FIG. 6.), e) enabling a secure and/or reliable execution of safety-critical software using a cloud system ([0232] verified by the Advanced SoC, ensuring that safety-critical updates are received as quickly as possible; [0398] performing drive safety critical processing; [0167] In a preferred embodiment, the cloud-based, deep learning infrastructure uses artificial intelligence to analyze data received from vehicles and incorporate it into up-to-date, real-time neural networks for real-time intelligent inferencing. In a preferred embodiment, the network infrastructure uses a datacenter with GPUs for deep learning as illustrated in FIG. 6), f) transferring safety-critical computations of a vehicle from a system of the vehicle into a remotely situated system including a cloud system and/or an edge computing system and/or at least one edge server, g) using resources of at least one edge server and/or at least one cloud server for redundantly carrying out a computation task for a vehicle outside vehicle, and assessing computation results that are obtained from the redundant carrying out of computation task including comparing the obtained computation results by a component of the vehicle ([0710] The datacenter may be well-suited to perform other tasks, such as receiving image and object detection information collected by a vehicle and transmitted over the wireless network, executing a neural network on one or more of the GPU servers, using the image information as input, comparing the results of the neural network run on one or more of the GPU servers with the object detection information received from the vehicle, and sending a wireless control signal to the vehicle instructing the vehicle to instruct the passengers and execute a safe parking maneuver if the result of the comparison falls below a confidence threshold; [0398] performing drive safety critical processing; [0167] In a preferred embodiment, the cloud-based, deep learning infrastructure uses artificial intelligence to analyze data received from vehicles and incorporate it into up-to-date, real-time neural networks for real-time intelligent inferencing. In a preferred embodiment, the network infrastructure uses a datacenter with GPUs for deep learning as illustrated in FIG. 6).
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 36 is rejected under 35 U.S.C. 103 as being unpatentable over Ditty in view of Einkauf et al. (US 20160323377 A1 hereinafter Einkauf).
As per claim 36, Ditty teaches the method as recited in claim 35.
Ditty fails to teach wherein the scaling is carried out during the use of the multiple computing services, including during the use of the at least one processing unit associated with the multiple computing services.
However, Einkauf teaches wherein the scaling is carried out during the use of the multiple computing services, including during the use of the at least one processing unit associated with the multiple computing services ([0118] the service may invoke the monitoring, aggregating, and evaluation processes that will be used to implement auto-scaling for the cluster. If no auto-scaling trigger conditions (e.g., those defined by expressions within the auto-scaling policies) are detected during execution of the given application, shown as the negative exit from 750, they may not be any changes may made to the number of instances in the MapReduce cluster during execution, as in 770. However, if one or more auto-scaling trigger conditions is detected during execution, shown as the positive exit from 750, the method may include the service adding or removing instances from one or more affected instance groups, according to the applicable auto-scaling policies; [0062] r select for use in making auto-scaling decisions, metrics that give insight into the utilization and/or behavior of resources that are heavily used by their applications; claim 1 A distributed computing system, comprising: a plurality of compute nodes, each compute node comprising at least one processor and a memory; and an interface; wherein the distributed computing system implements a distributed computing service; wherein the plurality of compute nodes are configured as a cluster of compute nodes according to a MapReduce distributed computing framework, wherein the cluster is configured to execute a distributed application).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Ditty with the teachings of Einkauf to reduce errors (see Einkauf [0024] the auto-scaling techniques described herein may be configured to consider the possibility of data loss and/or job failures when scaling (e.g., when reducing the cluster capacity). These techniques may be used to minimize job rescheduling and reduce the odds of data loss).
Claim 38 is rejected under 35 U.S.C. 103 as being unpatentable over Ditty in view of Guim Bernat et al. (US 20210144517 A1 hereinafter Guim Bernat).
As per claim 38, Ditty teaches the method as recited in claim 37, wherein the scaling and/or the carrying out of the load balancing ([0305] For example, to provide scalability, one embodiment provides expansion of the structure shown to additional SOCs 2002 via expansion connector 2018 such that some or all of the SOCs can communicate with one another via expansion connector; [0373] change allocations of CPU cores 4006 to virtualized CPUs 4004 depending on a variety of factors including priority, load balancing; [0394] a GPU can be load balanced among different virtual machines 4002).
Ditty fails to teach wherein the scaling and/or the carrying out of the load balancing is carried out based on at least one of the following elements: a) number of requests by clients, b) at least one predefinable criterion including at least one quality criterion associated with an application or a service, c) at least one safety requirement.
However, Guim Bernat teaches wherein the scaling and/or the carrying out of the load balancing is carried out based on at least one of the following elements: a) number of requests by clients ([0110] base station compute, acceleration and network resources can provide services in order to scale to workload demands on an as needed basis by activating dormant capacity (subscription, capacity on demand) in order to manage corner cases, emergencies or to provide longevity for deployed resources over a significantly longer implemented lifecycle; [0455] one of the main challenges to place processors and Accelerators in the base station to implement scalable edge cloud FaaS and AFaaS are: (1) physical space restriction; (2) low latency and scalable scheduling solutions to process client requests/functions; [0513] The load balancing component 3002 is circuitry arranged to receive an input to an A service and transmit that input into the input memory buffer of the corresponding service. The load balancing component 3002 is arranged to determine whether to add the received input into the memory buffer of the AI service, or transfer to another instance of the AI service on another node. This determination may be based on policies such as the status of the current memory buffer or inputs from the prediction component 3003. In an example, the load balancing component 3002 is arranged to respond to queries from orchestrator 3010 on the current status of the input memory buffer), b) at least one predefinable criterion including at least one quality criterion associated with an application or a service ([0486] In further examples, orchestration and coordination of a distributed workload among multiple accelerators may include aspects of load balancing, mobile access prediction, or use of telemetry, using the other techniques discussed herein. The orchestration and coordination of a distributed workload among multiple accelerators may also be based on SLA/SLO criteria and objectives, as accelerators are selected to most likely satisfy the SLA/SLO based on current or predicted execution states; [0090] these resources will benefit from service management in an edge system which provides the ability to scale and achieve local SLAs), c) at least one safety requirement ([1014] For example, in automotive use cases, safety-relevant features might never compromise their SLAs; [0090] these resources will benefit from service management in an edge system which provides the ability to scale and achieve local SLAs; [0486] The orchestration and coordination of a distributed workload among multiple accelerators may also be based on SLA/SLO criteria).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Ditty with the teachings of Guim Bernat to maintain service level agreements (see Guim Bernat [0090] these resources will benefit from service management in an edge system which provides the ability to scale and achieve local SLAs).
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over Ditty in view of Streete (US 9722855 B1).
As per claim, 42, Ditty teaches the method as recited in claim 41.
Ditty fails to teach further comprising: exchanging at least one of the following elements: a) at least one computing service of the multiple computing services, b) at least one hardware resource of the at least two different hardware resources, c) at least one processing unit, wherein the exchanging takes place when an error has been detected including when a violation of the integrity has been ascertained or detected.
However, Streete teaches further comprising: exchanging at least one of the following elements: a) at least one computing service of the multiple computing services, b) at least one hardware resource of the at least two different hardware resources, c) at least one processing unit, wherein the exchanging takes place when an error has been detected including when a violation of the integrity has been ascertained or detected (Col. 10 lines 24-28 Restoring could include reallocating services to replace services discontinued on account of the failure, and could also include reallocating services to free up a resource that needs replacement as a result of the failure; Col. 3 lines 15-16 underlying physical resources, e.g., computing devices).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Ditty with the teachings of Streete to recover from a failure (see Streete col. 10 lines 24-32 Restoring could include reallocating services to replace services discontinued on account of the failure, and could also include reallocating services to free up a resource that needs replacement as a result of the failure. The capabilities service framework 104 would work in concert with the persistence module 116, to continue delivering services to applications in fulfillment of the associated requests via redistribution of services as described above.).
Claim 43 is rejected under 35 U.S.C. 103 as being unpatentable over Ditty in view of Lee et al. (US 20060133300 A1 hereinafter Lee).
As per claim 43, Ditty teaches the method as recited in claim 30, further comprising: identifying a faulty component ([0396] when a guest ties up or causes a fault to occur in a shared resource; [0430] If the safety watchdog monitor 5010 detects an error or fault, it may propagate an error notification up to a higher level in the safety framework).
Ditty fails to teach using the faulty component, at least temporarily, to assess a state or integrity of the faulty component.
However, Lee teaches using the faulty component, at least temporarily, to assess a state or integrity of the faulty component ([0096] However, if the LSP maintains its failure state, the apparatus performs the LSP monitoring again; claim 15 an LSP monitoring section adapted to monitor whether a failure in a link or an LSP in the service providing the MPLS network has occurred with a set LSP.).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined Ditty with the teachings of Lee to recover from failure (see Lee [0092] detecting the failure and recovering the failure).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HSING CHUN LIN whose telephone number is (571)272-8522. The examiner can normally be reached Mon - Fri 9AM-5PM.
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, Aimee Li can be reached at (571) 272-4169. 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.
/H.L./Examiner, Art Unit 2195
Prosecution Insights