DETAILED ACTION
1. Claims 1-20 have been presented for examination.
Notice of Pre-AIA or AIA Status
2. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
PRIORITY
3. Acknowledgment is made that this application is continuation of PCT/CN2020/142237 filed 12/31/2020
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d), to CHINA 202010231581.5 filed 03/27/2020.
Information Disclosure Statement
4. The information disclosure statements (IDS) submitted on 2/15/23 and 6/14/23 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the Examiner has considered the IDS’ as to the merits.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
5. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. abstract idea) without anything significantly more.
i) In view of Step 1 of the analysis, claim(s) 1 is directed to a statutory category as a process, claim 9 is directed to a statutory category as a machine, and claim 20 is directed to an article of manufacture as a computer-readable storage medium, which each represent a statutory category of invention. Therefore, claims 1-20 are directed to patent eligible categories of invention.
ii) In view of Step 2A, Prong One, claims 1, 9 and 20 recite the abstract idea of determining a state of a model based on data which constitutes an abstract idea based on Mental Processes based on concepts performed in the human mind, or with the aid of pencil and paper.
As per claim 1, and similarly recited in claims 9 and 20, the limitation of “determining, based on the first data set, a second indicator similar to the first indicator;” and "determining a first model based on one or more second models associated with the second indicator, wherein the first model is configured to detect a status of the first indicator, the status of the first indicator comprising one of an abnormal state or a normal state, the second models being configured to detect a status of the second indicator, the status of the second indicator comprising one of an abnormal state or a normal state;” would be analogous to a person evaluating data and determining if there is a normal or abnormal state and thus fall under Mental Processes. Thus, the claims recite the abstract idea of a mental process performed in the human mind, or with the aid of pencil and paper.
As to claim 9, other than reciting “at least one processor,” nothing in the claim element precludes the step from practically being performed in the mind.
Dependent claims 2-8 and 10-19 further narrow the abstract ideas, identified in the independent claims.
iii) In view of Step 2A, Prong Two, the judicial exception is not integrated into a practical application. In claim 9, the additional element of “at least one processor”, and the “computer-readable storage medium”, in claim 20, merely uses a computer device as a tool to perform the abstract idea. (MPEP 2106.05(f)) The limitation in claim 1, and similarly recited in claims 9 and 20 of “obtaining a first data set of a first indicator” are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. See MPEP (2106.05(f)) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a mental process) does not integrate a judicial exception into a practical application. (MPEP 2106.05(f)(2)) Additionally the limitation of “obtaining a first data set of a first indicator” in claims 1, 9, and 20, alternatively can be viewed as insignificant extra-solution activity, specifically pertaining to mere data gathering/output necessary to perform the abstract idea (MPEP 2106.05(g)) and is not sufficient to integrate the judicial exception into a practical application. This is akin to selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display, which has been identified as extra solution activity. Therefore, the judicial exception is not integrated into a practical application.
Dependent claims 2-8, 10-19 further narrow the abstract ideas, identified in the independent claims and do not introduce further additional elements for consideration beyond those addressed above.
iv) In view of Step 2B, claims 1, 9 and 20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. In claim 9, the additional element of “at least one processor”, and the “computer-readable storage medium”, in claim 20, merely uses a computer device as a tool to perform the abstract idea. (MPEP 2106.05(f)) The limitation in claim 1, and similarly recited in claims 9 and 20 of “obtaining a first data set of a first indicator” are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. See MPEP (2106.05(f)) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a mental process) does not integrate a judicial exception into a practical application. (MPEP 2106.05(f)(2)) Additionally the limitation of “obtaining a first data set of a first indicator” in claims 1, 9, and 20, alternatively can be viewed as an insignificant extra-solution activity, specifically pertaining to mere data gathering/output necessary to perform the abstract idea (MPEP 2106.05(g)) and is not sufficient to integrate the judicial exception into a practical application. This is akin to selecting information, based on types of information and availability of information in a power-grid environment, for collection, analysis and display, which has been identified as extra solution activity. Therefore, the claim as a whole does not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements, when considered alone or in combination, do not amount to significantly more than the judicial exception. As stated in Section I.B. of the December 16, 2014 101 Examination Guidelines, “[t]o be patent-eligible, a claim that is directed to a judicial exception must include additional features to ensure that the claim describes a process or product that applies the exception in a meaningful way, such that it is more than a drafting effort designed to monopolize the exception.”
The dependent claims include the same abstract ideas recited as recited in the independent claims, and merely incorporate additional details that narrow the abstract ideas and fail to add significantly more to the claims.
Dependent claim 2 and 13 further defines the performance of the model the which merely narrows the abstract idea identified as a mental process.
Dependent claim 3 and 14 further defines the use of an algorithm to detect an anomaly which merely narrows the abstract idea identified as a mental process. The claimed inputting representing mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. See MPEP (2106.05(f)) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a mental process) does not integrate a judicial exception into a practical application. (MPEP 2106.05(f)(2)) Additionally the limitation alternatively can be viewed as an insignificant extra-solution activity, specifically pertaining to mere data gathering/output necessary to perform the abstract idea (MPEP 2106.05(g)) and is not sufficient to integrate the judicial exception into a practical application.
Dependent claim 4 and 15 further defines the selection of an attribute which merely narrows the abstract idea identified as a mental process.
Dependent claim 5 and 16 further defines the satisfying of a rule which merely narrows the abstract idea identified as a mental process.
Dependent claim 6 and 17 further defines the matching of an attribute the which merely narrows the abstract idea identified as a mental process.
Dependent claim 7 and 18 further defines determining performance based on an algorithm which merely narrows the abstract idea identified as a mental process. The claimed inputting representing mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. See MPEP (2106.05(f)) Use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., a mental process) does not integrate a judicial exception into a practical application. (MPEP 2106.05(f)(2)) Additionally the limitation alternatively can be viewed as an insignificant extra-solution activity, specifically pertaining to mere data gathering/output necessary to perform the abstract idea (MPEP 2106.05(g)) and is not sufficient to integrate the judicial exception into a practical application.
Dependent claim 8 and 19 further defines a filter and rule which merely narrows the abstract idea identified as a mental process.
Dependent claim 10 further recites determining a similarity of data which merely narrows the abstract idea identified as a mental process.
Dependent claim 11 further recites determining a similarity of data which merely narrows the abstract idea identified as a mental process.
Dependent claim 12 further defines the types of data which merely narrows the abstract idea identified as a mental process.
v) Accordingly, claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without anything significantly more.
Appropriate correction is required.
vi) As per claim 20 it is further rejected because the applicant has provided evidence that the applicant intends the term "computer-readable storage medium" to include non-statutory matter. The applicant describes a computer-readable storage medium as including open ended language and thus it is reasonable to interpret it to include all possible mediums, including non-statutory mediums (see paragraph [0085]) The words "storage" and/or "recording" are insufficient to convey only statutory embodiments to one of ordinary skill in the art absent an explicit and deliberate limiting definition or clear differentiation between storage media and transitory media in the disclosure. As such, the claim(s) is/are drawn to a form of energy. Energy is not one of the four categories of invention and therefore this/these claim(s) is/are not statutory. Energy is not a series of steps or and thus is not a process. Energy is not a physical article or object and as such is not a machine or manufacture. Energy is not a combination of substances and therefore not a composition of matter. The Examiner suggests amending the claim(s) to read as a "non-transitory machine-readable storage medium".
Appropriate correction is required.
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.
6. Claims 1-20 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.
i) The term “similar” in claim 1 is a relative term which renders the claim indefinite. The term “similar” 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. This rejection further applies to claims 9-11 and 20.
Appropriate correction is required.
All claims dependent upon a rejected base claim are rejected by virtue of their dependency.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
7. Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being clearly anticipated by U.S. Patent Publication No. 20190258251.
Regarding Claim 1: The reference discloses A modeling method, comprising:
obtaining a first data set of a first indicator, and determining, based on the first data set, a second indicator similar to the first indicator; and ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). Examiner Notes the collating of errors reads on the claimed similar indicators.)
determining a first model based on one or more second models associated with the second indicator, wherein the first model is configured to detect a status of the first indicator, the status of the first indicator comprising one of an abnormal state or a normal state, the second models being configured to detect a status of the second indicator, the status of the second indicator comprising one of an abnormal state or a normal state. ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). [0457] “Upon resolution of the fault, such as by a hardware reboot/restart (“7”), the local safety watchdog monitor 5010 detects the fault has been resolved (“8”) and reports same to the L1SS safety supervisor 5014(1) (“9”), which in turn reports the error resolution to the L2SS safety supervisor 5014(2) (“10”).” Examiner notes the errors read on the claimed abnormal state and the resolved fault reads on the normal state.)
Regarding Claim 2: The reference discloses The method according to claim 1, wherein the determining the first model comprises: determining, as the first model, a model with optimal performance in the one or more second models associated with the second indicator. ([0185] Platform (100) includes an Acceleration Cluster (400) that can consist of a variety of different hardware accelerators, each optimized for a different function or category of functions. [0186] For example, in certain non-limiting embodiments, Acceleration Cluster (400) may include a module for performing computer vision algorithms, for lane detection as well as redundant object detection at moderate distances. The module can include one or more embedded programmable vision accelerators (“PVAs”), which can be optimized for perception tasks from sensor data (e.g., data from cameras, RADAR, LIDAR) received from one or more sensors (e.g., cameras, RADAR, LIDAR) via I/O (170).)
Regarding Claim 3: The reference discloses The method according to claim 1, comprising:
inputting the first data set into the second model and processing the first data set based on a data preprocessing algorithm and a feature selection algorithm that are included in the second model, to obtain a first feature set; ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). The Examiner notes the error list reads on the claimed feature set)
filtering the first feature set according to a feature filter rule to obtain a second feature set, wherein a quantity of features in the second feature set is less than a quantity of features in the first feature set; and ([0443] In some instances, the L2SS safety supervisor 5014(2) may be directly notified by hardware that a fault has occurred. In such instances, the L2SS safety supervisor 5014(2) may inform the L1SS safety supervisor 5014(1) of the detected error so the L1SS safety supervisor can inform the virtual machines 4002 and associated application processes 5002. Additionally, the second level(s) L2SS safety supervisor 5014(2) may perform some filtering and processing on the error/failure reports it receives from the L1SS safety supervisor 5014(1), and may take corrective action itself in certain limited instances (e.g., certain kinds of local memory resets). In general however, the L2SS safety supervisor 5014(2) in the example embodiment acts as an error router by communicating with and reporting detected errors/failures to a third safety level L3SS 5014(3) safety supervisor executing in a different partition existing on a different processor on different silicon in a different package—in this case a safety microcontroller 5020.)
processing the second feature set by using an anomaly detection algorithm in the second model and determining performance of the second model based on a processing result of the anomaly detection algorithm. ([0443] In some instances, the L2SS safety supervisor 5014(2) may be directly notified by hardware that a fault has occurred. In such instances, the L2SS safety supervisor 5014(2) may inform the L1SS safety supervisor 5014(1) of the detected error so the L1SS safety supervisor can inform the virtual machines 4002 and associated application processes 5002. Additionally, the second level(s) L2SS safety supervisor 5014(2) may perform some filtering and processing on the error/failure reports it receives from the L1SS safety supervisor 5014(1), and may take corrective action itself in certain limited instances (e.g., certain kinds of local memory resets). In general however, the L2SS safety supervisor 5014(2) in the example embodiment acts as an error router by communicating with and reporting detected errors/failures to a third safety level L3SS 5014(3) safety supervisor executing in a different partition existing on a different processor on different silicon in a different package—in this case a safety microcontroller 5020. Examiner notes the error reporting reads on the claimed anomaly detection. Examiner notes that errors and/or failures denote a performance determination)
Regarding Claim 4: The reference discloses The method according to claim 3, further comprising selecting a feature that matches an attribute of the first indicator based on the feature filter rule. ([0546] An image feature tracker 3150 is always running in some example non-limiting embodiments. The image feature tracker 3150 supports both advanced trajectory estimation 3030a as well as object tracking 3010, and is therefore broken out as a separate module in FIG. 42. Feature tracker 3150 can operate on LIDAR images, optical images, RADAR images, and/or other sensed perceptions. See also [0491] The example non-limiting embodiments may also be constrained longitudinally by a set of rules, conventions and/or practical considerations. One example convention is traffic lights. A traffic light rule insists that the ego-vehicle stop and wait at a certain point until a certain condition becomes true (i.e., the traffic light turns green). These rules, conventions, and practical considerations may be referred to as wait conditions affordance and are handled by wait condition perception 3014 in example non-limiting embodiments.)
Regarding Claim 5: The reference discloses The method according to claim 3, the method further comprising: determining that the anomaly detection algorithm included in the second model satisfies an anomaly detection algorithm filter rule. ([0277] 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.)
Regarding Claim 6: The reference discloses The method according to claim 5, wherein an anomaly detection algorithm is selected that matches the attribute of the first indicator. ([0443] In some instances, the L2SS safety supervisor 5014(2) may be directly notified by hardware that a fault has occurred. In such instances, the L2SS safety supervisor 5014(2) may inform the L1SS safety supervisor 5014(1) of the detected error so the L1SS safety supervisor can inform the virtual machines 4002 and associated application processes 5002. Additionally, the second level(s) L2SS safety supervisor 5014(2) may perform some filtering and processing on the error/failure reports it receives from the L1SS safety supervisor 5014(1), and may take corrective action itself in certain limited instances (e.g., certain kinds of local memory resets). In general however, the L2SS safety supervisor 5014(2) in the example embodiment acts as an error router by communicating with and reporting detected errors/failures to a third safety level L3SS 5014(3) safety supervisor executing in a different partition existing on a different processor on different silicon in a different package—in this case a safety microcontroller 5020. Examiner notes the error reporting reads on the claimed anomaly detection.)
Regarding Claim 7: The reference discloses The method according to claim 2, further comprising:
determining a second model that satisfies an anomaly detection algorithm filter rule in the second models associated with the second indicator; ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”).)
inputting the first data set into the second model that satisfies the anomaly detection algorithm filter rule and processing the first data set based on a data preprocessing algorithm and a feature selection algorithm in the second model that satisfies the anomaly detection algorithm filter rule to obtain a first feature set; and ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”).)
processing the first feature set using an anomaly detection algorithm in the second model that satisfies the anomaly detection algorithm filter rule, and determining performance of the second model based on a processing result of the anomaly detection algorithm. ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). Examiner notes that errors and/or failures denote a performance determination)
Regarding Claim 8: The reference discloses The method according to claim 7, further comprising: filtering the first feature set according to a feature filter rule. ([0443] In some instances, the L2SS safety supervisor 5014(2) may be directly notified by hardware that a fault has occurred. In such instances, the L2SS safety supervisor 5014(2) may inform the L1SS safety supervisor 5014(1) of the detected error so the L1SS safety supervisor can inform the virtual machines 4002 and associated application processes 5002. Additionally, the second level(s) L2SS safety supervisor 5014(2) may perform some filtering and processing on the error/failure reports it receives from the L1SS safety supervisor 5014(1), and may take corrective action itself in certain limited instances (e.g., certain kinds of local memory resets). In general however, the L2SS safety supervisor 5014(2) in the example embodiment acts as an error router by communicating with and reporting detected errors/failures to a third safety level L3SS 5014(3) safety supervisor executing in a different partition existing on a different processor on different silicon in a different package—in this case a safety microcontroller 5020.)
Regarding Claim 9: The reference discloses An electronic device, comprising: at least one processor; and a memory coupled to the at least one processor and configured to store instructions that, when executed by the at least one processor, cause the electronic device to: obtain a first data set of a first indicator; determine, based on the first data set, a second indicator having an attribute similar to the first indicator; and determine a first model based on one or more second models associated with the second indicator, wherein the first model is configured to detect a status of the first indicator, the status of the first indicator comprising one of an abnormal state or a normal state, the second models are configured to detect the status of the second indicator, and the status of the second indicator comprising one of an abnormal state or a normal state. (See rejection for claim 1)
Regarding Claim 10: The reference discloses The electronic device according to claim 9, wherein the instructions, when executed by the at least one processor, cause the electronic device to determine a second data set similar to the first data set, and use an indicator corresponding to the second data set as the second indicator. ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). Examiner Notes the collating of errors reads on the claimed similar indicators.)
Regarding Claim 11: The reference discloses The electronic device according to claim 10, wherein the instructions, when executed by the at least one processor, cause the electronic device to determine the second data set whose feature vector similar to a feature vector of the first data set. ([0456] 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”). This hardware fault is detected by conventional SOC hardware checkers (e.g., registers, parity checkers, etc.) (“2”). A hardware error collator collates the detected error(s) with other hardware error detections (“3”) and signals the error(s) to a hardware security module (HSM) on the SOC (“4”). The HSM is able to directly signal the hardware error to the L3SS safety supervisor 5014(3) via the error signal pin 5072, and provides an interrupt notification to the L2SSsafety supervisor 5014(2) (“5b”), which in turn also communicates the error status to the L3SS safety supervisor 5014(3) via the SPI bus 5070 (“5c”). In the example shown, the L2SS safety supervisor 5014(2) informs the L1SS safety supervisor 5014(1) of the hardware error (“6”), which in turn notifies the safety watchdog monitors 5010 running on the virtual machines/partitions 4002 (“7”). Examiner Notes the errors reads on the claimed similar feature vector as they share the same feature of being an error.)
Regarding Claim 12: The reference discloses The electronic device according to claim 11, wherein a feature in the feature vector of the first data set and the feature vector of the second data set each include at least one of a value change trend, a value periodicity, and a value fluctuation feature. ([0541] The example non-limiting embodiments may perform basic lane detection 3160 using one or more neural networks trained on manually labeled datasets. Auto-labeled datasets generated by driving could substitute for the center path, which provides data for self-calibration and for path following but manual labeling may assist in lane width recognition. A labeling procedure may be used that is directed towards path affordance. That is, when labeling, it is possible to label valid paths in an image. This can be done for example by annotating each valid path with two polylines indicating the parallel sides of a path (see FIG. 44). The intent is to keep the polylines smooth so that the area between the two polylines has a path with that direction. It is possible to train a neural network to provide data about this in an image, such as the directionality of the paths at each point, and whether a point is on a lane edge. It is also possible to define a periodic function that goes from one in the center of a path down to zero at edges between the paths. In cases of forks and intersections, there may be multiple paths, providing some additional encoding complexity. One example design handles different angular sectors of travel separately. Another example explicitly identifies such areas (e.g., an intersection) and uses some more freeform path estimation for those areas or to explicitly estimate the fork path of a fork (e.g., regardless of whether it is visually well supported by explicit markings).)
Regarding Claim 13: The reference discloses The electronic device according to claim 9, wherein the instructions, when executed by the at least one processor, cause the electronic device to determine, as the first model, a model with optimal performance in the second models associated with the second indicator. (See rejection for claim 2)
Regarding Claim 14: The reference discloses The electronic device according to claim 13, wherein the instructions, when executed by the at least one processor, the electronic device to: input the first data set into the second model and process the first data set based on a data preprocessing algorithm and a feature selection algorithm that are included in the second model to obtain a first feature set; filter the first feature set according to a feature filter rule to obtain a second feature set, wherein a quantity of features in the second feature set is less than a quantity of features in the first feature set; and process the second feature set by using an anomaly detection algorithm in the second model and determine performance of the second model based on a processing result of the anomaly detection algorithm. (See rejection for claim 3)
Regarding Claim 15: The reference discloses The electronic device according to claim 14, wherein a feature that matches an attribute of the first indicator is selected based on the feature filter rule. (See rejection for claim 4)
Regarding Claim 16: The reference discloses The electronic device according to claim 14, wherein the instructions, when executed by the at least one processor, cause the electronic device to determine, that the anomaly detection algorithm comprised in the second model satisfies an anomaly detection algorithm filter rule. (See rejection for claim 5)
Regarding Claim 17: The reference discloses The electronic device according to claim 16, wherein an anomaly detection algorithm that matches the attribute of the first indicator is selected based upon the anomaly detection algorithm filter rule (See rejection for claim 6)
Regarding Claim 18: The reference discloses The electronic device according to claim 13, wherein the instructions, when executed by the at least one processor, cause the electronic device to: determine a second model that satisfies an anomaly detection algorithm filter rule in the second models associated with the second indicator; input the first data set into the second model that satisfies the anomaly detection algorithm filter rule and process the first data set based on a data preprocessing algorithm and a feature selection algorithm in the second model that satisfies the anomaly detection algorithm filter rule to obtain a first feature set; and process the first feature set by using an anomaly detection algorithm in the second model that satisfies the anomaly detection algorithm filter rule and determine performance of the second model based on a processing result of the anomaly detection algorithm. (See rejection for claim 7)
Regarding Claim 19: The reference discloses The electronic device according to claim 18, wherein the instructions, when executed by the at least one processor, cause the electronic device to filter the first feature set according to a feature filter rule. (See rejection for claim 8)
Regarding Claim 20: The reference discloses A computer-readable storage medium including instructions that, when executed on a computer, cause the computer to: obtain a first data set of a first indicator; determine, based on the first data set, a second indicator similar to the first indicator; and determine a first model based on one or more second models associated with the second indicator, wherein the first model is configured to detect a status of the first indicator, the status of the first indicator comprises an abnormal state or a normal state, the second models being configured to detect a status of the second indicator, and the status of the second indicator comprising one of an abnormal state or a normal state. (See rejection for claim 1)
Conclusion
8. All Claims are rejected.
9. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
i) U.S. Patent Publication No. 20110141895 which teaches aspects of anomaly detection and state determinations.
ii) Xie, Xiaochen, Wei Sun, and Kie Chung Cheung. "An advanced PLS approach for key performance indicator-related prediction and diagnosis in case of outliers." IEEE Transactions on Industrial Electronics 63.4 (2015): 2587-2594 which teaches the aspect of system diagnosis using key performance indicators.
iii) Yu, Guang, et al. "Unsupervised online anomaly detection with parameter adaptation for KPI abrupt changes." IEEE Transactions on Network and Service Management 17.3 (2019): 1294-1308 which teaches the aspect of key performance indicators in anomaly detection.
iv) Shi, Jia, Gang He, and Xinwen Liu. "Anomaly detection for key performance indicators through machine learning." 2018 International Conference on Network Infrastructure and Digital Content (IC-NIDC). IEEE, 2018 which teaches the aspect of key performance indicators in anomaly detection.
10. Any inquiry concerning this communication or earlier communications from the examiner should be directed to Saif A. Alhija whose telephone number is (571) 272-8635. The examiner can normally be reached on M-F, 10:00-6:00.
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, Renee Chavez, can be reached at (571) 270-1104. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300. Informal or draft communication, please label PROPOSED or DRAFT, can be additionally sent to the Examiners fax phone number, (571) 273-8635.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
SAA
/SAIF A ALHIJA/Primary Examiner, Art Unit 2186
Prosecution Insights