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-19 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 2/23/26 filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Current ’253 Application
Parent ‘371 patent: please note the followings:
the quoted text below may not be in the same order as the original’s; instead, for comprehension, they may be listed to match the elements of current application (on the left);
some of the text may be repeated (again, only for comprehension purpose); and
not all of the ‘371 elements may be listed (as this is a nonstatutory anticipatory rejection).
A computer-implemented method for maintaining a distributed ledger of transactions pertaining to one or more smart contracts and one or more autonomous vehicles wherein each autonomous vehicle includes a plurality of sensors that generate data indicative of respective conditions, the method comprising:
A computer-implemented method for maintaining a distributed ledger of transactions pertaining to an autonomous vehicle, the method comprising:
responsive to the generation of a smart contract, receiving, from a server, a subscription request indicating a condition of an autonomous vehicle,
monitoring, by one or more processors of an electronic device on-board the autonomous vehicle, one or more sensors associated with an autonomous vehicle;
wherein the smart contract (i) governs an autonomous vehicle system or technology employed by or mounted on the autonomous vehicle and (ii) utilizes the condition indicated in the subscription request as a trigger or decision condition;
determining, by one or more processors of an electronic device disposed at the autonomous vehicle, a subset of the plurality of sensors disposed at the autonomous vehicle that provide data relevant to the condition indicated by the subscription request of the autonomous vehicle;
identifying, by the one or more processors, a smart contract recorded to the distributed ledger related to the autonomous vehicle, wherein the smart contract includes a trigger condition or a decision condition of the smart contract associated with detecting collisions associated with the autonomous vehicle;
causing, by one or more processors, an application executing on the electronic device to begin monitoring the determined subset of the plurality of sensors associated with the autonomous vehicle;
monitoring, by one or more processors of an electronic device on-board the autonomous vehicle, one or more sensors associated with an autonomous vehicle;
detecting, using the subset of the plurality of sensors associated with the autonomous vehicle, by the one or more processors, a change in the condition of the autonomous vehicle;
detecting, by the one or more processors, a collision of the autonomous vehicle with a second vehicle;
receiving, from the second vehicle, operating data generated by one or more sensors of the second vehicle;
in response to at least one sensor of the subset of the plurality of sensors detecting the change in the condition of the autonomous vehicle, generating, by the one or more processors, a transaction describing a detected change in the condition of the autonomous vehicle
receiving, from the second vehicle, operating data generated by one or more sensors of the second vehicle;
updating, by the one or more processors, the distributed ledger to include a transaction describing the detected change in the condition of the autonomous vehicle
updating, by the one or more processors, the distributed ledger to include the transaction.
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.
Claims 1-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-19 are directed to a system, method, or product, which are/is one of the statutory categories of invention. (Step 1: YES).
The Examiner has identified independent method claim 1 as the claim that represents the claimed invention for analysis and is similar to independent system claim 12 and product claim 19. Claim 1 recites the limitations of using a software (smart contract) to govern and monitor changes in the condition of an autonomous vehicle, and record the changes in the distributed ledger.
These limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. Responsive to the generation of a smart contract, receiving a subscription request indicating an autonomous vehicle condition; smart contract governs vehicle system and uses the vehicle conditions indicated by the request as a trigger or decision; determining a subset of sensors that provide vehicle condition data relevant to the conditions indicated by the request; causing an app to begin monitoring the sensors; detecting a change in the condition; in response to sensor detecting the change in vehicle condition, generating a transaction describing a detected change; and updating the distributed ledger to include the detected change in the condition, – specifically, the claim recites “responsive to a generation of a smart contract, receiving… a subscription request indicating a condition of an autonomous vehicle, wherein the smart contract (i) governs an autonomous vehicle system or technology employed by or mounted on the autonomous vehicle and (ii) utilizes the condition indicated in the subscription request as a trigger or decision condition; determining… a subset of the plurality of sensors disposed at the autonomous vehicle that provide data relevant to the condition indicated by the subscription request of the autonomous vehicle; causing… an application… to begin monitoring the determined subset of the plurality of sensors associated with the autonomous vehicle; detecting… a change in the condition of the autonomous vehicle; in response to at least one sensor of the subset of the plurality of sensors detecting the change in the condition of the autonomous vehicle, generating… a transaction describing a detected change in the condition of the autonomous vehicle; and automatically updating… the distributed ledger to include the transaction describing the detected change in the condition of the autonomous vehicle”, recites a fundamental economic practice, directed to mitigating risk.
If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a fundamental economic practice or commercial or legal interactions, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
The “a computer system”, “an autonomous vehicle”, “a distributed ledger”, “one or more smart contracts”, “a plurality of sensors”, “one or more processors”, “a communication module”, “one or more nodes of the distributed ledger”, “a non-transitory program memory”, “a server”, and “an autonomous vehicle system or technology”, in claim 12; and the additional technical element of “a non-transitory computer readable storage medium” in claim 19, are just applying generic computer components to the recited abstract limitations. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. Claims 1 and 19 are also abstract for similar reasons. (Step 2A-Prong 1: YES. The claims recite an abstract idea)
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of: a computer such as a computer system, an autonomous vehicle, one or more processors, a server, and an autonomous vehicle system or technology; a communication device such as one or more nodes of the distributed ledger; a storage unit such as a distributed ledger, a non-transitory program memory, and a non-transitory computer readable storage medium; an electronic/electrical device such as a subset of sensors of the one or more sensors and a plurality of sensors; and software module and algorithm such as one or more smart contracts and a communication module. The computer hardware/software is/are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements, when considered separately and as an ordered combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea and are at a high level of generality. Therefore, claims 1, 12, and 19 are directed to an abstract idea without a practical application. (Step 2A-Prong 2: NO. The additional claimed elements are not integrated into a practical application)
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when considered separately and as an ordered combination, they do not add significantly more (also known as an “inventive concept”) to the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer hardware amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. Accordingly, these additional elements, do not change the outcome of the analysis, when considered separately and as an ordered combination. Thus, claims 1, 12, and 19 are not patent eligible. (Step 2B: NO. The claims do not provide significantly more)
Dependent claims further define the abstract idea that is present in their respective independent claims 1, 12, and 19 and thus correspond to Certain Methods of Organizing Human Activity, and hence are abstract for the reasons presented above.
Dependent claim 2 discloses the limitation of compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger, which further narrows the abstract idea. Note that the technical elements “one or more processors” and “distributed ledger” are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 3 discloses the limitation of transmitting, to the server, the transaction, which further narrows the abstract idea. Note that the technical element “the server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 4 discloses the limitation of the subscription request indicates one or more expected ranges of values for outputs of the subset of the plurality of sensors, the one or more expected ranges of values being associated with one or more states corresponding to the condition of the autonomous vehicle, which further narrows the abstract idea.
Dependent claim 5 discloses the limitation of detecting, by the one or more processors, that an output of a sensor of the subset of the plurality of sensors changed from a first expected range of values to a second expected range of values, which further narrows the abstract idea. Note that the technical elements “one or more processors” and “a sensor of the subset of the plurality of sensors” are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 6 discloses the limitation of a sensor of the subset of the plurality of sensors, which further narrows the abstract idea.
Dependent claim 7 discloses the limitation of receiving, from the other autonomous vehicle, operating data generated by one or more sensors of the other autonomous vehicle, which further narrows the abstract idea.
Note that the technical elements “the other autonomous vehicle” and “one or more sensors of the other autonomous vehicle” are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 8 discloses the limitation of analyzing, by the one or more processors, the operating data to determine a relative fault between a party associated with the autonomous vehicle and a party associated with the other autonomous vehicle, which further narrows the abstract idea. Note that the technical element “one or more processors” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 9 discloses the limitation of analyzing, by the one or more processors, the operating data to determine that the autonomous vehicle, and not the other autonomous vehicle, should generate the transaction, which further narrows the abstract idea. Note that the technical elements “one or more processors”, “the autonomous vehicle”, and “the other autonomous vehicle”, are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 10 discloses the limitation of the autonomous vehicle system or technology is associated with or related to: driver alertness monitoring; driver responsiveness monitoring; pedestrian detection; artificial intelligence; a back-up system; a navigation system; a positioning system; a security system; an anti-hacking measure; a theft prevention system; or remote vehicle location determination, which further narrows the abstract idea. Note that the technical elements “the autonomous vehicle system”, “; artificial intelligence”, “a back-up system”, “a navigation system”, “a positioning system”, “a security system”, and “a theft prevention system”, are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 11 discloses the limitation of receiving, from the server, a request to unsubscribe from data relating to the condition of the autonomous vehicle; and causing, by the one or more processors, the application executing on the electronic device to cease monitoring the determined subset of the plurality of sensors disposed at the autonomous vehicle, which further narrows the abstract idea. Note that the technical elements “the server”, “the electronic device”, and “one or more processors”, are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 13 discloses the limitation of compile the transaction into a block of transactions, the block being an update to the distributed ledger, which further narrows the abstract idea. Note that the technical element “the distributed ledger” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 14 discloses the limitation of transmit, to the server, the transaction, which further narrows the abstract idea. Note that the technical element “the server” is recited at a high level of generality. It does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claim 15 discloses the limitation of the change in the condition of the autonomous vehicle is indicative of a collision with another autonomous vehicle, which further narrows the abstract idea.
Dependent claim 16 discloses the limitation of receive, from the other autonomous vehicle, operating data generated by one or more sensors of the other autonomous vehicle, which further narrows the abstract idea. Note that the technical elements “the other autonomous vehicle” and “one or more sensors of the other autonomous vehicle” are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Dependent claim 17 discloses the limitation of analyze the operating data to determine a relative fault between a party associated with the autonomous vehicle and a party associated with the other autonomous vehicle, which further narrows the abstract idea.
Dependent claim 18 discloses the limitation of the autonomous vehicle system or technology is associated with or related to: driver alertness monitoring; driver responsiveness monitoring; pedestrian detection; artificial intelligence; a back-up system; a navigation system; a positioning system; a security system; an anti-hacking measure; a theft prevention system; or remote vehicle location determination, which further narrows the abstract idea. Note that the technical elements “the autonomous vehicle system or technology”, “a theft prevention system”, “ a back-up system”, “artificial intelligence”, “a navigation system”, “a positioning system”, and “a security system”, are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Thus, the dependent claims do not include any additional elements that integrate the abstract idea into a practical application or are sufficient to amount to significantly more than the judicial exception when considered both individually and as an ordered combination. Therefore, the dependent claims are directed to an abstract idea. Thus, the claims 1-19 are not patent-eligible.
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5, 7, 10-14, 16, and 18-19 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vian (20080033684) in view of Spanos (20160028552).
Regarding claim 1, Vian discloses
a computer-implemented method for [maintaining a distributed ledger of transactions] pertaining to one or more smart contracts and one or more autonomous vehicles wherein each autonomous vehicle includes a plurality of sensors that generate data indicative of respective conditions, the method comprising
([0022] The present invention relates to systems and methods for rapid development and testing of algorithms and configurations of vehicles, including manned and unmanned flight vehicles, as well as water and land-based vehicles. Many specific details of certain embodiments of the invention are set forth in the following description and in FIGS. 1-14 to provide a thorough understanding of such embodiments).
determining, by one or more processors of an electronic device disposed at the autonomous vehicle, a subset of the plurality of sensors disposed at the autonomous vehicle that provide data relevant to the condition indicated by the subscription request of the autonomous vehicle; causing, by the one or more processors, an application executing on the electronic device to begin monitoring the determined subset of the plurality of sensors associated with the autonomous vehicle
([0047] The onboard controller 414 is operatively coupled to a control module 460. The control module 460 may be located on the test vehicle 410, or alternately, may be positioned remotely from the test vehicle 410 and may communicate with the onboard controller 414 via a wireless communication link. In the embodiment shown in FIG. 5, the control module 460 includes a health management component 462 coupled to a processing component 464 that is, in turn, coupled to a communication component 466. The processing and communication components 464, 466 may have somewhat overlapping functions and capabilities. For example, in a particular embodiment, the processing component 464 may perform data collection and relatively low-level onboard processing activities, while the communication component 466 may perform relatively high-level onboard processing activities as well as communication activities. The health management and/or processing components 462, 464 are adapted to monitor the voltage level of the power source 416, the outputs of the current sensors 417 and temperature sensors 418, and to buffer, filter, and condition the signals received from the test vehicle 410 for communication to the communication component 466. In turn, the communication component 466 is configured to transmit these data to a command and control component of the development system 400 to enable health monitoring of the various systems and parameters of the test vehicle 410. In a particular embodiment, the processing component 464 may be a Robostix microcontroller and the communication component 466 may be a Connex 400xm-bt platform, both of which are commercially available from gumstix inc. of Portola Valley, Calif. In another embodiment, a microcontroller (e.g. a Robostix microcontroller) may be combined with a printed circuit board to provide these functions on-board the test vehicle 410, as described below with reference to FIGS. 13 and 14).
([0025] The command and control computer 102 operatively communicates with each of the test vehicles 110 via a communications link 105… receive video and sensor signals 104 and health monitoring signals 106 from the test vehicles 110, and to transmit appropriate command signals 108 to the test vehicles 110. A command and control software program 112 may be implemented on the command and control computer 102 to perform a variety of functions associated with monitoring and controlling the test vehicles 110 and the various components of the development system 100).
detecting, by the one or more processors using the subset of the plurality of sensors associated with the autonomous vehicle, a change in the condition of the autonomous vehicle
([0062] FIG. 11 shows a screen display 710 depicting graphs of health monitoring information for the test vehicle 610 during flight testing. A first graph 712 shows a plot of power source voltage versus flight time. Second graphs 714 show plots of the temperatures at the rotor assemblies 412 as measured by the temperature sensors 418, and third graphs 716 show plots of the rotor assemblies 412 as measured by the current sensors 417. In this way, the analysis and display component 670 may provide real-time information regarding important health characteristics of the test vehicle 610 during flight testing, which may advantageously improve test quality and reduce failures and associated downtime).
([0038] As further shown in FIG. 3, the position and dynamics data measured by the position reference system 120, and health monitoring data transmitted by the onboard sensors, are compared with predicted and desired data values at a block 314. For example, the measured positions, attitudes, and velocities of the test vehicles 110 may be compared with desired values based on a pre-programmed mission profile stored within the command-and-control computer 102. Similarly, vehicle health data, such as battery charge levels, fuel levels, pressure and temperature levels, weapons status, other expendable resource levels, and any other desired health parameters may be compared with anticipated or desired values based on the pre-programmed mission profile).
in response to at least one sensor of the subset of the plurality of sensors detecting the change in the condition of the autonomous vehicle, generating, by the one or more processors, a transaction describing a detected change in the condition of the autonomous vehicle; and
([0038] As further shown in FIG. 3, the position and dynamics data measured by the position reference system 120, and health monitoring data transmitted by the onboard sensors, are compared with predicted and desired data values at a block 314. For example, the measured positions, attitudes, and velocities of the test vehicles 110 may be compared with desired values based on a pre-programmed mission profile stored within the command-and-control computer 102. Similarly, vehicle health data, such as battery charge levels, fuel levels, pressure and temperature levels, weapons status, other expendable resource levels, and any other desired health parameters may be compared with anticipated or desired values based on the pre-programmed mission profile).
Vian does not disclose, however, Spanos teaches
[maintaining a distributed ledger of transactions] and
Automatically updating, by the one or more processors, the distributed ledger to include a transaction describing the detected change in the condition of the autonomous vehicle
([0003] Blockchain technology is most widely known as the technology behind the popular cryptocurrency, Bitcoin. A blockchain creates a history of data deposits, messages, or transactions in a series of blocks where each block contains a mathematical summary, called a hash, of the previous block. This creates a chain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain.
[0004] Although the hash, or mathematical summary, is simple to compute, there are rules imposed which require the value of the hash to be below a certain threshold value. In addition, the hash is based on a special type of mathematical function that is not reversible; you cannot predict what input can be used to produce the desired output. A valid hash is found by repeatedly adjusting a changeable value in the block, and recalculating the hash until it meets the validity requirements. The freely changeable value is called the nonce. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block. Typically, trillions of different nonces must be tried before a valid hash is found. Therefore, changing the value of previously stored data in the blockchain is computationally expensive, although not impossible.
[0005] The security of a blockchain is further increased by implementing it on a distributed network. This means a large number of users all have access to the blockchain and are all attempting to add blocks to the end of the chain by finding a nonce that produces a valid hash for a given block of data. When two blocks are found that both claim to reference the same previous block, a fork in the chain is created. Some users in the network will attempt to find the next block on one end of the fork while other users will work from the other end of the fork. Eventually one of the forks will surpass the other in length, and the longest chain is accepted by consensus as the valid chain. Therefore, anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block.
[0006] Blockchains on a distributed network with sufficiently restrictive rules for creating valid blocks are fairly secure against unauthorized changes to the data stored in them. This makes blockchains particularly useful for recording financial transactions).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vian to include [maintaining a distributed ledger of transactions] and updating, by the one or more processors, the distributed ledger to include a transaction describing the detected change in the condition of the autonomous vehicle as taught by Spanos to create a ledger/record that is difficult to corrupt. See paragraph 5 – “[0005] anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block”.
responsive to a generation of a smart contract, receiving, from a server, a subscription request indicating a condition of an autonomous vehicle, wherein the smart contract (i) governs an autonomous vehicle system or technology employed by or mounted on the autonomous vehicle and (ii) utilizes the condition indicated in the subscription request as a trigger or decision condition
([0064] Slidechain can also be used to enable smart contracts… Rather, the "smart contract" phrase should refer to the "smart" decision as to whether to enter a contract. The slidechain invention can enable information verification to assist and become an integral part of an informed "smart" decision about entering a contract. A smart contract is not only an irreversible contract but also one where reliance on knowledge of facts can replace reliance on hope and trust. Contracting parties can replace "trust" with "knowledge" of either performance or the ability to pay. If desired, parties to a smart contract in slidechain may choose reversal procedures or breach resolution procedures. These would be defined before entering into said contracts. Additionally, a smart contract may be modifiable if terms agreed to by the parties are met. Slidechain will offer the flexibility to define these terms if and when they are needed or desirable in the context of a given agreement. All of these features will be programmable, and form a central component of slidechain's enhanced utility. Certifications and written assurances of willingness to perform, to pay, a contract obligation will be replaced by actual, independently verifiable proof of such ability, with irreversibility negating the question of a party's willingness to pay (and implicitly, its willingness and ability to breach a contract regardless of its terms or complexity). In so doing the slidechain system and method will deter and repel contract parties who seek to gain advantage through nonperformance, double-dealing and other methods of dishonesty, and thus clear the field for honest commercial parties who wish to engage in business with a minimum of third-party interference or rent-seekers).”
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vian to include [maintaining a distributed ledger of transactions] and responsive to the generation of a smart contract, receiving, from a server, a subscription request indicating a condition of an autonomous vehicle, wherein the smart contract (i) governs an autonomous vehicle system or technology employed by or mounted on the autonomous vehicle and (ii) utilizes the condition indicated in the subscription request as a trigger or decision condition as taught by Spanos to create a ledger/record that is non-local for assurances of willingness to perform when the agreed conditions are met, which could potentially be independently verifiable proof. See paragraphs 5 and 64.
Regarding claim 2, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian does not disclose, however, Spanos further discloses
compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger
([0003] Blockchain technology is most widely known as the technology behind the popular cryptocurrency, Bitcoin. A blockchain creates a history of data deposits, messages, or transactions in a series of blocks where each block contains a mathematical summary, called a hash, of the previous block. This creates a chain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain.
[0004] Although the hash, or mathematical summary, is simple to compute, there are rules imposed which require the value of the hash to be below a certain threshold value. In addition, the hash is based on a special type of mathematical function that is not reversible; you cannot predict what input can be used to produce the desired output. A valid hash is found by repeatedly adjusting a changeable value in the block, and recalculating the hash until it meets the validity requirements. The freely changeable value is called the nonce. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block. Typically, trillions of different nonces must be tried before a valid hash is found. Therefore, changing the value of previously stored data in the blockchain is computationally expensive, although not impossible.
[0005] The security of a blockchain is further increased by implementing it on a distributed network. This means a large number of users all have access to the blockchain and are all attempting to add blocks to the end of the chain by finding a nonce that produces a valid hash for a given block of data. When two blocks are found that both claim to reference the same previous block, a fork in the chain is created. Some users in the network will attempt to find the next block on one end of the fork while other users will work from the other end of the fork. Eventually one of the forks will surpass the other in length, and the longest chain is accepted by consensus as the valid chain. Therefore, anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block.
[0006] Blockchains on a distributed network with sufficiently restrictive rules for creating valid blocks are fairly secure against unauthorized changes to the data stored in them. This makes blockchains particularly useful for recording financial transactions).
The motivation being
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vian to include compiling, by the one or more processors, the transaction into a block of transactions, the block being an update to the distributed ledger as taught by Spanos to create a ledger/record that is difficult to corrupt. See paragraph 5 – “[0005] anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block”.
Regarding claim 3, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian does not disclose, however, Spanos further discloses
updating the distributed ledger comprises: transmitting, to the server, the transaction
([0003] Blockchain technology is most widely known as the technology behind the popular cryptocurrency, Bitcoin. A blockchain creates a history of data deposits, messages, or transactions in a series of blocks where each block contains a mathematical summary, called a hash, of the previous block. This creates a chain where any changes made to a block will change that block's hash, which must be recomputed and stored in the next block. This changes the hash of the next block, which must also be recomputed and so on until the end of the chain.
[0004] Although the hash, or mathematical summary, is simple to compute, there are rules imposed which require the value of the hash to be below a certain threshold value. In addition, the hash is based on a special type of mathematical function that is not reversible; you cannot predict what input can be used to produce the desired output. A valid hash is found by repeatedly adjusting a changeable value in the block, and recalculating the hash until it meets the validity requirements. The freely changeable value is called the nonce. The unpredictable nature of the hash considerably increases the difficulty of finding a nonce that produces a valid hash of the block. Typically, trillions of different nonces must be tried before a valid hash is found. Therefore, changing the value of previously stored data in the blockchain is computationally expensive, although not impossible.
[0005] The security of a blockchain is further increased by implementing it on a distributed network. This means a large number of users all have access to the blockchain and are all attempting to add blocks to the end of the chain by finding a nonce that produces a valid hash for a given block of data. When two blocks are found that both claim to reference the same previous block, a fork in the chain is created. Some users in the network will attempt to find the next block on one end of the fork while other users will work from the other end of the fork. Eventually one of the forks will surpass the other in length, and the longest chain is accepted by consensus as the valid chain. Therefore, anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block.
[0006] Blockchains on a distributed network with sufficiently restrictive rules for creating valid blocks are fairly secure against unauthorized changes to the data stored in them. This makes blockchains particularly useful for recording financial transactions).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Vian to include updating the distributed ledger comprises: transmitting, to the server, the transaction as taught by Spanos to create a ledger/record that is difficult to corrupt. See paragraph 5 – “[0005] anyone who attempts to change a block must not only re-find a valid hash for each subsequent block, but must do it faster than everyone else working on the currently accepted chain. Thus, after a certain number of blocks have been chained onto a particular block, it becomes prohibitively costly to try to change that block”.
Regarding claim 4, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian further discloses
the subscription request indicates one or more expected ranges of values for outputs of the subset of the plurality of sensors, the one or more expected ranges of values being associated with one or more states corresponding to the condition of the autonomous vehicle
([0041] Next, at a block 324, a determination (or series of determinations) is made to determine whether health conditions of the one or more test vehicles 110 are unacceptable. If so, a determination is made at a block 325 to determine whether the unacceptable health condition is correctable. If so, then corrective action may be taken to adjust the efficient health conditions of the one more test vehicles 110 at a block 326, including using the health condition as a constraint in the control commands of the corresponding vehicle(s).
([0038] As further shown in FIG. 3, the position and dynamics data measured by the position reference system 120, and health monitoring data transmitted by the onboard sensors, are compared with predicted and desired data values at a block 314. For example, the measured positions, attitudes, and velocities of the test vehicles 110 may be compared with desired values based on a pre-programmed mission profile stored within the command-and-control computer 102. Similarly, vehicle health data, such as battery charge levels, fuel levels, pressure and temperature levels, weapons status, other expendable resource levels, and any other desired health parameters may be compared with anticipated or desired values based on the pre-programmed mission profile).
Regarding claim 5, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian further discloses
detecting, by the one or more processors, that an output of a sensor of the subset of the plurality of sensors changed from a first expected range of values to a second expected range of values
([0025] The command and control computer 102 operatively communicates with each of the test vehicles 110 via a communications link 105… receive video and sensor signals 104 and health monitoring signals 106 from the test vehicles 110, and to transmit appropriate command signals 108 to the test vehicles 110. A command and control software program 112 may be implemented on the command and control computer 102 to perform a variety of functions associated with monitoring and controlling the test vehicles 110 and the various components of the development system 100).
([0038] As further shown in FIG. 3, the position and dynamics data measured by the position reference system 120, and health monitoring data transmitted by the onboard sensors, are compared with predicted and desired data values at a block 314. For example, the measured positions, attitudes, and velocities of the test vehicles 110 may be compared with desired values based on a pre-programmed mission profile stored within the command-and-control computer 102. Similarly, vehicle health data, such as battery charge levels, fuel levels, pressure and temperature levels, weapons status, other expendable resource levels, and any other desired health parameters may be compared with anticipated or desired values based on the pre-programmed mission profile).
Regarding claim 7, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian further discloses
receiving, from the other autonomous vehicle, operating data generated by one or more sensors of the other autonomous vehicle
([0022] The present invention relates to systems and methods for rapid development and testing of algorithms and configurations of vehicles, including manned and unmanned flight vehicles, as well as water and land-based vehicles. Many specific details of certain embodiments of the invention are set forth in the following description and in FIGS. 1-14 to provide a thorough understanding of such embodiments).
Regarding claim 10, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
Vian further discloses
wherein the autonomous vehicle system or technology is associated with or related to: driver alertness monitoring; driver responsiveness monitoring; pedestrian detection; artificial intelligence; a back-up system; a navigation system; a positioning system; a security system; an anti-hacking measure; a theft prevention system; or remote vehicle location determination
([0026] In operation, the command and control computer 102 causes appropriate command signals 108 to be transmitted to the one or more of the test vehicles 110, directing the test vehicles 110 to perform desired activities or functions. For example, the one or more UAV test vehicles 110A may be directed to fly in a desired flight path and to collect desired information using an onboard sensor. Similarly, the UGV and other test vehicles 110B, 110C may be directed to traverse a desired ground path, collect information, or perform other desired activities. The test vehicles 110 may be commanded to move independently of one another, or alternately, two or more of the test vehicles 110 may be commanded to move in a coordinated manner, such as in flocking, swarming, or ultraswarming movements, as described more fully, for example, in Beyond Swarm Intelligence: The Ultraswarm, presented at the IEEE Swarm Intelligence Symposium by Holland et al., Jun. 8, 2005, incorporated herein by reference.).
Claim 11 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 12 is rejected using the same rationale that was used for the rejection of claim 1.
Claim 13 is rejected using the same rationale that was used for the rejection of claim 2.
Claim 14 is rejected using the same rationale that was used for the rejection of claim 3.
Claim 16 is rejected using the same rationale that was used for the rejection of claim 7.
Claim 18 is rejected using the same rationale that was used for the rejection of claim 10.
Claim 19 is rejected using the same rationale that was used for the rejection of claim 1.
Claims 6 and 15 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vian in view of Spanos, further in view of and Sasaki (20020035422).
Regarding claim 6, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
The combination of Vian and Spanos do not disclose but Sasaki does teaches
However, Sasaki teaches
the change in the condition of the autonomous vehicle is indicative of a collision with another autonomous vehicle (“Why”).
([0058] An operational condition recording apparatus according to a thirtieth aspect is based upon the operational condition recording apparatus according to any of the first to twenty-ninth aspects and is characterized in that when a collision detector of the vehicle detects collision of the vehicle, recording operation is finished immediately after the occurrence of the collision).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the combination Vian and Spanos to include the change in the condition of the autonomous vehicle is indicative of a collision with another autonomous vehicle as taught by Sasaki to provide an indication for the system to take step that can be helpful to the users. See paragraph 59.
Claim 15 is rejected using the same rationale that was used for the rejection of claim 6.
Claims 8-9 and 17 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Vian in view of Spanos, further in view of and Collopy (20100131304).
Regarding claim 8, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
The combination of Vian and Spanos do not disclose but Collopy does teaches
However, Collopy teaches
analyzing, by the one or more processors, the operating data to determine a relative fault between a party associated with the autonomous vehicle and a party associated with the other autonomous vehicle
([0075] The on-board monitoring system 125 can also be employed to assist with reconstruction of accidents. By reviewing the data gathered by real-time data gathering system 100 it is possible to determine how the vehicle was being driven prior to an accident. Data can be retrieved from the on-board monitoring system 125, buffer 270 or from the insurance provider system 135 and analyzed. The analysis can assist in determining who was at fault in the accident, whether a vehicle was speeding, cell phone usage, had the driver made a prohibited turn?, etc. Such data analysis could greatly enhance the insurance accident investigation allowing the insurance claims assessor to expeditiously assess the accident, make insurance payouts and any claims associated with the accident, forward information that might be of use to the law and legal professions, etc. The savings realized by the insurance company could be employed to offset the costs of implementing the real time monitoring system 100 to the insurance customer).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the combination Vian and Spanos to include analyzing, by the one or more processors, the operating data to determine a relative fault between a party associated with the autonomous vehicle and a party associated with the other autonomous vehicle as taught by Collopy to provide information for real time insurance analysis. See paragraph 75.
Regarding claim 9, the combination of Vian and Spanos, as shown in the rejection above, discloses the limitations of claim 1.
The combination of Vian and Spanos do not disclose but Collopy does teaches
analyzing, by the one or more processors, the operating data to determine that the autonomous vehicle, and not the other autonomous vehicle, should generate the transaction
([0075] The on-board monitoring system 125 can also be employed to assist with reconstruction of accidents. By reviewing the data gathered by real-time data gathering system 100 it is possible to determine how the vehicle was being driven prior to an accident. Data can be retrieved from the on-board monitoring system 125, buffer 270 or from the insurance provider system 135 and analyzed. The analysis can assist in determining who was at fault in the accident, whether a vehicle was speeding, cell phone usage, had the driver made a prohibited turn?, etc. Such data analysis could greatly enhance the insurance accident investigation allowing the insurance claims assessor to expeditiously assess the accident, make insurance payouts and any claims associated with the accident, forward information that might be of use to the law and legal professions, etc. The savings realized by the insurance company could be employed to offset the costs of implementing the real time monitoring system 100 to the insurance customer).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify the combination Vian and Spanos to include analyzing, by the one or more processors, the operating data to determine a relative fault between a party associated with the autonomous vehicle and a party associated with the other autonomous vehicle as taught by Collopy to provide information for real time insurance analysis. See paragraph 75.
Claim 17 is rejected using the same rationale that was used for the rejection of claim 8.
Response to Arguments
Applicant's arguments filed 2/11/26 have been fully considered but they are not persuasive.
In response to applicant's argument that:
“35 U.S.C. § 101… Claims Do Not Cover Mental Processes,”
the examiner respectfully disagrees. The examiner did not argue that the claims cover “mental processes” – such as, for example, observation, evaluation, or judgment/opinion.
In response to applicant's argument that:
“As noted in MPEP § 2106.04(a)(2)(Il)(A), examples of "fundamental economic practice" include… (listing 4 items from the MPEP, such as “mitigating settlement risk”)… It is unclear to Applicant how the examples above apply to the present claims.… Applicant respectfully requests an explanation or a rationale as to why the claims identify concepts related to any of the examples listed above or other similar examples. Otherwise, Applicant is denied a fair chance to refute the Office's blank assertions of patent ineligibility,”
the examiner respectfully disagrees with the applicant’s narrow reading of the MPEP in limiting all possible abstract ideas (for 35 U.S.C. § 101 analysis purpose) to only those seven numbered and listed in MPEP 2106.04(a)(2)(II)(A). A proper reading requires consideration of the entire MPEP 2106.04 guidance.
First, MPEP 2106.07(a)(I) states that “(e)xaminers should not go beyond those concepts that are enumerated as abstract ideas in MPEP § 2106.04 (all emphases in this reply are examiner’s),”; this is much broader than what the applicant is arguing – i.e., it does not state that examiners should not go beyond abstract ideas enumerated MPEP 2106.04(a)(2)(II)(A).
Second, MPEP 2106.04(a)(2)(II)(A), itself, clearly labeled the listed abstract ideas as “other examples of "fundamental economic principles or practices"”. It does not state that these are the only abstract ideas of MPEP § 2106.04. Thus, when the MPEP 2106.07(a)(I) states “(e)xaminers should not go beyond those concepts that are enumerated as abstract ideas in MPEP § 2106.04”, contrary to what the applicant seems to be arguing for, it means the entire MPEP § 2106.04.
If anything, MPEP § 2106.04(a) clearly states that “the Office has set forth an approach to identifying abstract ideas that distills the relevant case law into enumerated groupings of abstract ideas… By grouping the abstract ideas, the examiners’ focus has been shifted from relying on individual cases to generally applying the wide body of case law spanning all technologies and claim types.” In other words, examiners are relieved from legal analysis that often accompanied case law arguments/analysis. Instead, the examiners are directed to find proper fittings within the MPEP enumerated groupings of abstract ideas.
Within these enumerated groupings, the examiner has determined that the claims are directed towards “certain methods of organizing human activity – fundamental economic principles or practices.” See MPEP § 2106.04(a). Specifically, the examiner has determined that monitor changes in the condition of an autonomous vehicle, and record the changes in a ledger is part of the societal fundamental economic practice.
In response to applicant's argument that:
“Practical Application… independent claims 1, 12, and 19, at a minimum, recite additional elements beyond the alleged judicial exception (certain methods of organizing human activity), which integrate the alleged judicial exception into a practical application … Application describes the current problem with managing transactions associated with control state transitions in autonomous vehicles as "there is no trusted system that automatically enforces ... arrangements associated with autonomous vehicles… (reciting more of the claim language)… it is by detecting a change in condition using a subset of the plurality of sensors, in response to the detecting the change generating a transaction describing the detected change, and automatically updating the distributed ledger to include the transaction describing the detected change in the condition of the autonomous vehicle that provide a solution to the problem of managing transactions associated with control state transitions within autonomous vehicles. Applicant respectfully submits that the above limitations recite additional elements that place the claims beyond reciting any alleged certain methods of organizing human activity or mental processes and integrate any alleged certain methods of organizing human activity or mental process into a practical application (emphasis original’s),”
the examiner respectfully disagrees. First, the applicant is referring to the new USPTO guidance published in the Federal Register on January 7, 2019. Even under the guidance, the claims are still not patent eligible under 35 USC§ 101 for the very reasons recited by the applicant in the above quote. The applicant stated the claim presents a “practical application” because it, essentially “detecting a change in (vehicle) condition” and “automatically updating the distributed ledger”. Detecting changes in the vehicle condition and recording those changes in a ledger is an abstract idea. There may be “practical” purpose in doing it in the broad meaning of word; but it does not qualify as integrating the idea into a practical application under the guidance. Under the guidance, the claimed invention must improve a technology or technical field, not merely links the use of the judicial exception to a particular technological environment or field of use. Note that the applicant is not improving the vehicle sensing technology. The applicant is not improving the blockchain ledgering technology. There is no technology improvement disclosed by the claims. The disclosed technical elements are recited at a high level of generality. They do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. See Claim Rejections - 35 USC § 101 above.
In response to applicant's argument that:
“35 U.S.C. § 103… Claim 1 has been amended to recite… (reciting the amended claim),”
Applicant’s arguments have been considered but are moot because the arguments do not apply to the new analysis in view of the additional language from the reference being used in the current rejection.
In response to applicant's argument that:
“Spanos does not disclose "in response to at least one sensor of the subset of the plurality of sensors detecting the change in the condition of the autonomous vehicle, generating, by the one or more processors, a transaction describing a detected change in the condition of the autonomous vehicle (emphasis original’s),”
the examiner respectfully disagrees. The argument is not found persuasive because the applicant is arguing against the references individually. Spanos is considered in view of Vian. One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413,208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091,231 USPQ 375 (Fed. Cir. 1986). Spanos was cited by the examiner as a prior to show that blockchain is a known ledgering technology and obvious to use to record information, including vehicle information.
The examiner notes that the inclusion of the phrase “a transaction describing a detected change in the condition of the autonomous vehicle” in the Spanos analysis was because the way claim language was constructed – i.e., the particular vehicle information is being recorded in blockchain. Again, the focus of the Spanos analysis is blockchain being a known ledgering technology and obvious to use to record information.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action.
Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK H GAW whose telephone number is (571)270-0268. 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, Mike Anderson can be reached on 571 270-0508. 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.
/MARK H GAW/Examiner, Art Unit 3693
Prosecution Insights