Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim 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-20 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-7 recite a method (process), claims 8-14 recite a system (machine) and claims 15-20 recite non-transitory computer-readable memory (manufacture) and therefore fall into a statutory category. The Examiner is interpreting the system and non-transitory computer-readable memory perform the steps of the method for examination purposes.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
The claims as a whole recites a manner of organizing the processing of recalls for vehicle based on the analysis of received, which under its broadest reasonable interpretation covers concepts performed in Certain Methods of Organizing Human Activity and Mental Processes. The abstract idea is as follows:
(Claim 1) A [computer-implemented] method for identifying vehicles requiring safety recalls [using a distributed ledger], the method comprising, [via one or more processors]:
(Claim 8) [A computer system configured to] identify vehicles requiring safety recalls [using a distributed ledger, the computer system comprising one or more processors configured to:]
(Claim 15) [A non-transitory computer-readable memory storing instructions thereon for] identifying vehicles requiring safety recalls [using a distributed ledger, that when executed one or more processors, cause the one or more processors to:]
receiving, by a third-party organization, identification information for a vehicle part that needs to be replaced due to a safety recall;
monitoring a distributed ledger that records current vehicle part information for a plurality of vehicles to identify vehicles associated with the third-party organization having the vehicle part that needs to be replaced, [wherein the distributed ledger is maintained by a plurality of participants in a distributed ledger network according to a set of consensus rules];
in response to identifying a vehicle associated with the third-party organization having the vehicle part that needs to be replaced, identifying contact information associated with the vehicle;
and transmitting, via the contact information, a notification indicating that the identified vehicle requires a safety recall.
Where the portions not bracketed recite the abstract idea.
The recited abstract idea above recites concepts performed in either commercial or legal interactions (including legal obligations or business relations) or managing personal behavior or interactions between people (including following rules or instructions) or concepts capable of being performed in the human mind or via pen and paper (including an observation, evaluation, judgment, opinion) but for the recitation of generic computing components. In the present application concepts reciting a manner of organizing the processing of recalls for vehicle based on the analysis of collected information. (See paragraphs 3-5 and 7-8)
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in either commercial or legal interactions or managing personal behavior or interactions between people, it falls under the Certain Methods of Organizing Human Activity grouping of abstract ideas. See MPEP 2106.04. Further, if a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in the human mind or via pen and paper, it falls under the Mental Processes grouping of abstract ideas. See Id.
Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?):
The examiner views the following as the additional elements:
Computer-implemented. (See paragraphs 154)
A distributed ledger. (See paragraphs 141-142)
One or more processors. (See paragraph 186)
A computer system. (See paragraph 63)
A non-transitory computer-readable memory. (See paragraph 186)
Instructions. (See paragraph 186)
A distributed ledger network. (See paragraph 143)
There is no indication that the computing elements are anything but generic hardware and /or software.
Referring to “wherein the distributed ledger is maintained by a plurality of participants in a distributed ledger network according to a set of consensus rules” the examiner views as a results-oriented solution lacking details and therefore equivalent to mere instructions to apply the abstract idea using generic computing components. (See MPEP 2106.05 (f) and paragraph 143 of the Specification).
The above additional elements and/or results oriented steps are mere instructions to implement an abstract idea using generic computing components within a computing environment and do not provide for a practical application. (See MPEP 2106.05(f))
Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?):
As noted above, the claims as a whole merely describes a method that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
Dependent claims 2 and 6-7 further define the abstract idea as identified. Therefore claims 2 and 6-7 are considered to be patent ineligible.
Dependent claim 3 further defines the abstract idea as identified. Additionally, the claims recite the generic client device (See paragraph 159) and user interface (See paragraph 159) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 3 is considered to be patent ineligible.
Dependent claim 4-5, 11-12, and 18-19 further defines the abstract idea as identified. Additionally, the claims recite the generic distributed ledger (See paragraphs 141-142) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 4-5, 11-12, and 18-19 are considered to be patent ineligible.
Dependent claims 9 and 13-14 further define the abstract idea as identified. Additionally, the claims recite the generic one or more processors (See paragraph 186) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 9 and 13-14 are considered to be patent ineligible.
Dependent claim 10 further defines the abstract idea as identified. Additionally, the claims recite the generic one or more processors (See paragraph 186), client device (See paragraph 159) and user interface (See paragraph 159) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 10 is considered to be patent ineligible.
Dependent claims 16 and 20 further define the abstract idea as identified. Additionally, the claims recite the generic instructions (See paragraph 186) and one or more processors (See paragraph 186) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 16 and 20 are considered to be patent ineligible.
Dependent claim 17 further defines the abstract idea as identified. Additionally, the claims recite the generic instructions (See paragraph 186) one or more processors (See paragraph 186), client device (See paragraph 159), and user interface (See paragraph 159) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claim 17 is considered to be patent ineligible.
Dependent claim 18-19 further define the abstract idea as identified. Additionally, the claims recite the generic instructions (See paragraph 186), one or more processors (See paragraph 186), and distributed ledger (See paragraphs 141-142) for merely implementing the abstract idea using generic computing components which does not integrate the abstract idea into a practical application or adds significantly more. Therefore claims 18-19 are considered to be patent ineligible.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 4-6, 8, 11-13, 15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Mullins et al. (US 20210035120) in view of Nagla et al. (US 20180018723).
Referring to claims 1, 8, and 15,
Mullins, which is directed to an adaptive and verifiable bill of materials, teaches
(Claim 1) 1. A computer-implemented method for identifying vehicles requiring safety recalls using a distributed ledger, the method comprising, via one or more processors:
(Claim 8) A computer system configured to identify vehicles requiring safety recalls using a distributed ledger, the computer system comprising one or more processors configured to:
(Claim 15) A non-transitory computer-readable memory storing instructions thereon for identifying vehicles requiring safety recalls using a distributed ledger, that when executed one or more processors, cause the one or more processors to:
(Mullins paragraph 15 teaching the public identifier and associated public attributes (e.g., a public key) are published to a public platform so that the information can be accessed by anyone, typically in the form of a distributed ledger (DLT), such as a blockchain. The DLT also provides assurances regarding data integrity. The private key is securely stored and kept private. Mullins paragraph 24-31 teaching for a device manufacturer, such as Tesla, to manufacture a vehicle with verified parts, each verifiable part needs to be traceable back to its supplier and/or manufacturer. Suppliers can provide this information, for example, by assigning a DID to each part and registering the DIDs on a public DLT (or a private DLT). Each part that is registered on the DLT can include attributes including, but not limited to: part serial number; part creation date; part provisioned date; quality assurance data; warranty expiration; and part status (e.g., recalled). FIG. 2 illustrates an exemplary part registration process 200 for a part manufacturer 210 (or a parts supplier) to verify one or more parts 220-A through 220-C, according to an embodiment. As shown in FIG. 2, for each part 220-A through 220-C, the part manufacturer 210 registers a DID for the given part with corresponding public attributes (e.g., a public key) with a public distributed ledger 240 (e.g., the identifier registry 140 of FIG. 1). Mullins paragraphs 37-38 teaching upon completing this process for all verifiable parts, the device manufacturer can then apply the part registration process 200 of FIG. 2 for the manufactured device to their newly manufactured device. The device manufacturer can generate a DID for the vehicle and register its public attributes (e.g., a vehicle identification number) on a DLT, such as a public DLT or a private DLT. While a car manufacturer, for example, can optionally build an application for vehicle owners that could access a private DLT, public DLTs work best in some embodiments because claims can be verified by anyone (a public ledger is often considered more open and reusable than a private DLT; however, a privately owned ledger can technically work, although the use of the private DLT would be scoped to only those entities that can access it). The private key could then be stored within the device, such as on a trusted execution environment. The last step in this process is to capture the list of all the installed verifiable parts, for example, by issuing a verifiable claim that declares all of the verifiable parts that were installed. The verifiable claim would be issued by the device manufacturer and stored on the device. One advantage of using a verifiable claim here provides the benefit of ensuring data integrity. Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies). Mullins paragraphs 65-66 teaching one or more embodiments of the disclosure provide improved methods, apparatus and computer program products for providing and verifying adaptive and verifiable bills of materials. The foregoing applications and associated embodiments should be considered as illustrative only, and numerous other embodiments can be configured using the techniques disclosed herein, in a wide variety of different applications. It should also be understood that the disclosed adaptive and verifiable bill of materials techniques, as described herein, can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device such as a computer. As mentioned previously, a memory or other storage device having such program code embodied therein is an example of what is more generally referred to herein as a “computer program product.)
receiving, by a third-party organization, identification information for a vehicle part that needs to be replaced due to a safety recall; (Mullins paragraph 41 teaching FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected.)
monitoring a distributed ledger that records current vehicle part information for a plurality of vehicles to identify vehicles associated with the third-party organization having the vehicle part that needs to be replaced, (Mullins paragraph 24-31 teaching for a device manufacturer, such as Tesla, to manufacture a vehicle with verified parts, each verifiable part needs to be traceable back to its supplier and/or manufacturer. Suppliers can provide this information, for example, by assigning a DID to each part and registering the DIDs on a public DLT (or a private DLT). Each part that is registered on the DLT can include attributes including, but not limited to: part serial number; part creation date; part provisioned date; quality assurance data; warranty expiration; and part status (e.g., recalled). FIG. 2 illustrates an exemplary part registration process 200 for a part manufacturer 210 (or a parts supplier) to verify one or more parts 220-A through 220-C, according to an embodiment. As shown in FIG. 2, for each part 220-A through 220-C, the part manufacturer 210 registers a DID for the given part with corresponding public attributes (e.g., a public key) with a public distributed ledger 240 (e.g., the identifier registry 140 of FIG. 1). Mullins paragraphs 37-38 teaching upon completing this process for all verifiable parts, the device manufacturer can then apply the part registration process 200 of FIG. 2 for the manufactured device to their newly manufactured device. The device manufacturer can generate a DID for the vehicle and register its public attributes (e.g., a vehicle identification number) on a DLT, such as a public DLT or a private DLT. While a car manufacturer, for example, can optionally build an application for vehicle owners that could access a private DLT, public DLTs work best in some embodiments because claims can be verified by anyone (a public ledger is often considered more open and reusable than a private DLT; however, a privately owned ledger can technically work, although the use of the private DLT would be scoped to only those entities that can access it). The private key could then be stored within the device, such as on a trusted execution environment. The last step in this process is to capture the list of all the installed verifiable parts, for example, by issuing a verifiable claim that declares all of the verifiable parts that were installed. The verifiable claim would be issued by the device manufacturer and stored on the device. One advantage of using a verifiable claim here provides the benefit of ensuring data integrity. Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies).)
in response to identifying a vehicle associated with the third-party organization having the vehicle part that needs to be replaced, identifying contact information associated with the vehicle; (Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies).)
and transmitting, via the contact information, a notification indicating that the identified vehicle requires a safety recall. (Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies). The Examiner is interpreting that Mullins suggests using contact information for the purposes of provisioning an alert for display to a user for informing them regarding a recall affecting their vehicle.)
Mullins does not teach or suggest wherein the distributed ledger is maintained by a plurality of participants in a distributed ledger network according to a set of consensus rules;
However Nagla, which is directed to a vehicle record platform using blockchain technology, teaches wherein the distributed ledger is maintained by a plurality of participants in a distributed ledger network according to a set of consensus rules; (Nagla paragraph 123 teaching in this example, logic that may be utilized to increase the blockchain's resilience to tampering may include “majority consensus rules”, where a validation may be based on the integrity of a “longest” blockchain; cross-validation by multiple nodes to authorize an activity to modify the blockchain; using suitable encryption and cryptographic techniques (e.g., public/private key pairs, hashing, “proof of work” generation); among others. For example, if a new “block” being proposed by one of the entities does not conform to one or more rules and/or requirements, the block may be rejected and/or subject to further scrutiny before it can be accepted and properly inserted into the blockchain. Nagla paragraph 128 teaching a potential advantage to limiting the participating entities to authorized entities 102, 104, 106, 108, 110, and 112 (or another small group of entities such as mortgage companies, regulators, satellite offices) is that the number of nodes in the distributed network may be reduced (e.g., restricted, limited) in comparison to publicly distributed (or accessible) ledgers, and the financial institutions themselves may also be inherently more trustworthy than any number of unknown third parties. Accordingly, any consensus process, where different nodes on the distributed network must agree on any changes made to the ledger, may be simplified and overall performance of the ledger (e.g., transaction speed) may be increased over public distributed ledgers. For example, a more rigorous consensus process may be applied in view of common standards enforced across the entities, or the ledger may be constructed and configured such that greater efficiencies may be obtained during access, traversal, and modification, etc.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claimed manner of using a DLT for monitoring and processing recalls for parts of a vehicle as taught in Mullins to incorporate wherein the distributed ledger is maintained by a plurality of participants in a distributed ledger network according to a set of consensus rules as taught in Nagla with the motivation of improving the blockchain’s resiliency to tampering. (Nagla paragraphs 123 and 128)
Referring to claims 4, 11, and 18,
Mullins further teaches wherein upon receiving a replacement part, an update is broadcasted to the distributed ledger indicating the replacement part installed within the vehicle. (Mullins paragraph 24-31 teaching for a device manufacturer, such as Tesla, to manufacture a vehicle with verified parts, each verifiable part needs to be traceable back to its supplier and/or manufacturer. Suppliers can provide this information, for example, by assigning a DID to each part and registering the DIDs on a public DLT (or a private DLT). Each part that is registered on the DLT can include attributes including, but not limited to: part serial number; part creation date; part provisioned date; quality assurance data; warranty expiration; and part status (e.g., recalled). FIG. 2 illustrates an exemplary part registration process 200 for a part manufacturer 210 (or a parts supplier) to verify one or more parts 220-A through 220-C, according to an embodiment. As shown in FIG. 2, for each part 220-A through 220-C, the part manufacturer 210 registers a DID for the given part with corresponding public attributes (e.g., a public key) with a public distributed ledger 240 (e.g., the identifier registry 140 of FIG. 1). Mullins paragraph 37 teaching now that a manufactured device has been provisioned in a way that is verifiable, verification of the manufactured device and its constituent parts can be performed instantaneously. When a manufacturer of a manufactured device, such as Tesla, is assembling disparate parts 220 together, for each verifiable part, the device manufacturer can query the distributed ledger 240 of the corresponding supplier using the verification process 300 of FIG. 3 to ensure that the part is genuine and/or defect free. Upon completing this process for all verifiable parts, the device manufacturer can then apply the part registration process 200 of FIG. 2 for the manufactured device to their newly manufactured device. The device manufacturer can generate a DID for the vehicle and register its public attributes (e.g., a vehicle identification number) on a DLT, such as a public DLT or a private DLT. While a car manufacturer, for example, can optionally build an application for vehicle owners that could access a private DLT, public DLTs work best in some embodiments because claims can be verified by anyone (a public ledger is often considered more open and reusable than a private DLT; however, a privately owned ledger can technically work, although the use of the private DLT would be scoped to only those entities that can access it). Mullins paragraphs 42-49 teaching if it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies). Device BOM Updates In some embodiments, the described adaptive and verifiable device BOM infrastructure allows new parts to be installed on a device in a cryptographically verifiable manner by the OEM or third parties. FIG. 5 is a flow chart illustrating an exemplary implementation of a device BOM update process 500, according to one or more embodiments. In the example of FIG. 5, when a new part is installed by an OEM or a third party during step 510, then, upon installation of the new part, the installer can revoke the original claim and issue a new claim with the latest BOM information during step 520. If a new part is installed by a third party, for example, then, upon installation, the service center could issue a new verifiable claim that cites: the DID of the service center; the DID of the mechanic; and the DID of the part. The device imports the new verifiable claim during step 530. Upon importing the new claim, the device determines if the repair shop and mechanic are certified and/or if the part is compatible with the device during step 540. If it is determined during step 540 that the repair shop and/or mechanic are certified and/or that the part is compatible with the device, the device verifies the repair shop and mechanic and/or certifies that the part is compatible with the device during step 550. This verification could be done by the device, for example, by invoking calls to a server setup by the OEM. Another approach to perform this verification step would be for the OEM to issue verifiable claims to the third party repair shops and mechanics with a claim regarding their certification.)
Referring to claims 5, 12, and 19,
Mullins further teaches, wherein each time a vehicle part is replaced within a vehicle of the plurality of vehicles, a transaction is broadcasted to the distributed ledger indicating up-to-date vehicle part information for the vehicle for the distributed ledger to maintain up-to-date records of vehicle parts within the plurality of vehicles. (Mullins paragraph 24-31 teaching for a device manufacturer, such as Tesla, to manufacture a vehicle with verified parts, each verifiable part needs to be traceable back to its supplier and/or manufacturer. Suppliers can provide this information, for example, by assigning a DID to each part and registering the DIDs on a public DLT (or a private DLT). Each part that is registered on the DLT can include attributes including, but not limited to: part serial number; part creation date; part provisioned date; quality assurance data; warranty expiration; and part status (e.g., recalled). FIG. 2 illustrates an exemplary part registration process 200 for a part manufacturer 210 (or a parts supplier) to verify one or more parts 220-A through 220-C, according to an embodiment. As shown in FIG. 2, for each part 220-A through 220-C, the part manufacturer 210 registers a DID for the given part with corresponding public attributes (e.g., a public key) with a public distributed ledger 240 (e.g., the identifier registry 140 of FIG. 1). Mullins paragraph 37 teaching now that a manufactured device has been provisioned in a way that is verifiable, verification of the manufactured device and its constituent parts can be performed instantaneously. When a manufacturer of a manufactured device, such as Tesla, is assembling disparate parts 220 together, for each verifiable part, the device manufacturer can query the distributed ledger 240 of the corresponding supplier using the verification process 300 of FIG. 3 to ensure that the part is genuine and/or defect free. Upon completing this process for all verifiable parts, the device manufacturer can then apply the part registration process 200 of FIG. 2 for the manufactured device to their newly manufactured device. The device manufacturer can generate a DID for the vehicle and register its public attributes (e.g., a vehicle identification number) on a DLT, such as a public DLT or a private DLT. While a car manufacturer, for example, can optionally build an application for vehicle owners that could access a private DLT, public DLTs work best in some embodiments because claims can be verified by anyone (a public ledger is often considered more open and reusable than a private DLT; however, a privately owned ledger can technically work, although the use of the private DLT would be scoped to only those entities that can access it). Mullins paragraphs 42-49 teaching if it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies). Device BOM Updates In some embodiments, the described adaptive and verifiable device BOM infrastructure allows new parts to be installed on a device in a cryptographically verifiable manner by the OEM or third parties. FIG. 5 is a flow chart illustrating an exemplary implementation of a device BOM update process 500, according to one or more embodiments. In the example of FIG. 5, when a new part is installed by an OEM or a third party during step 510, then, upon installation of the new part, the installer can revoke the original claim and issue a new claim with the latest BOM information during step 520. If a new part is installed by a third party, for example, then, upon installation, the service center could issue a new verifiable claim that cites: the DID of the service center; the DID of the mechanic; and the DID of the part. The device imports the new verifiable claim during step 530. Upon importing the new claim, the device determines if the repair shop and mechanic are certified and/or if the part is compatible with the device during step 540. If it is determined during step 540 that the repair shop and/or mechanic are certified and/or that the part is compatible with the device, the device verifies the repair shop and mechanic and/or certifies that the part is compatible with the device during step 550. This verification could be done by the device, for example, by invoking calls to a server setup by the OEM. Another approach to perform this verification step would be for the OEM to issue verifiable claims to the third party repair shops and mechanics with a claim regarding their certification.)
Referring to claims 6, 13, and 20,
Mullins further teaches further comprising: receiving, from a vehicle manufacturer, identification information for a set of vehicles requiring safety recalls; (Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies).
comparing the identified vehicles from the distributed ledger to the set of vehicles from the vehicle manufacturer to verify that the set of vehicles from the vehicle manufacturer require safety recalls. (Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies).
Claims 2-3, 9-10, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over Mullins et al. (US 20210035120) in view of Nagla et al. (US 20180018723) and Misra et al. (US 20150127191).
Referring to claims 2, 9, and 16,
Mullins further teaches further comprising: after a threshold time period, monitoring the distributed ledger to identify remaining vehicles associated with the third-party organization still having the vehicle part that needs to be replaced; (Mullins paragraphs 41-42 teaching FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies). Mullins paragraph 44 teaching in some embodiments, the described adaptive and verifiable device BOM infrastructure allows new parts to be installed on a device in a cryptographically verifiable manner by the OEM or third parties. FIG. 5 is a flow chart illustrating an exemplary implementation of a device BOM update process 500, according to one or more embodiments. In the example of FIG. 5, when a new part is installed by an OEM or a third party during step 510, then, upon installation of the new part, the installer can revoke the original claim and issue a new claim with the latest BOM information during step 520.)
Mullins in view of Nagla does not teach or suggest and determining a completion percentage for the safety recalls based upon the remaining vehicles associated with the third-party organization still having the vehicle part that needs to be replaced.
However, Misra, which is directed to a reputation-based and condition-based vehicular network, teaches and determining a completion percentage for the safety recalls based upon the remaining vehicles associated with the third-party organization still having the vehicle part that needs to be replaced. (Misra paragraphs 157-159 teaching at 1210, the computing system receives recall or maintenance information from one or more customer vehicles via a wireless connection. Specifically, the information received from each vehicle may specify (i) whether service has been performed on the vehicle to address the recall or maintenance that is the subject a particular manufacturer initiative or maintenance program and (ii) a status of the maintenance unit or subsystem of the vehicle that is the subject of the particular manufacturer initiative or maintenance program. As would be understood by one of ordinary skill in the art, based on the teachings and disclosure herein, a car controller may store information on (i) and (ii), above. In arrangements, the computing system may receive this information directly from vehicles. In arrangements, the computing system may receive this information from one or more authorized vehicles, as described in relation to the process 1100 of FIG. 11. At 1220, the computing system accesses a mapping of vehicle locations and corresponding recall and/or maintenance status values. The computing system may generate this information directly from the data received at 1210 or the computing system may pass the data received at 1210 to another system or third-party service, which then generates the mapping and returns it to the computing system. In arrangements, the mapping depicts vehicle locations on a map and an indication of whether a given type of recall and/or maintenance has been performed on those vehicles. A human or computer analyzes the mapping accessed at 1220, to determine geographic regions in which a relatively large percentage of eligible vehicles have not had recall or maintenance work performed. Accordingly, at 1230, the manufacturer deploys a recall or maintenance resource in a region based on the mapping. For example, in arrangements, the manufacturer deploys an authorized vehicle in a region in which a relatively large percentage of eligible vehicles have not had recall or maintenance work performed. The authorized vehicle then travels the roads of the region and broadcasts recall or maintenance information for a set of vehicles as described in relation to process 1100 of FIG. 11.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claimed manner of using a DLT for monitoring and processing recalls for parts of a vehicle as taught in Mullins in view of Nagla to incorporate and determining a completion percentage for the safety recalls based upon the remaining vehicles associated with the third-party organization still having the vehicle part that needs to be replaced as taught in Misra with the motivation of assessing the effectiveness of a recall for a particular subsystem of a vehicle. (Misra paragraphs 157-159)
Referring to claims 3, 10, and 17,
Misra further teaches further comprising: providing an indication of the completion percentage to a client device for display on a user interface. (Misra paragraphs 157-159 teaching at 1210, the computing system receives recall or maintenance information from one or more customer vehicles via a wireless connection. Specifically, the information received from each vehicle may specify (i) whether service has been performed on the vehicle to address the recall or maintenance that is the subject a particular manufacturer initiative or maintenance program and (ii) a status of the maintenance unit or subsystem of the vehicle that is the subject of the particular manufacturer initiative or maintenance program. As would be understood by one of ordinary skill in the art, based on the teachings and disclosure herein, a car controller may store information on (i) and (ii), above. In arrangements, the computing system may receive this information directly from vehicles. In arrangements, the computing system may receive this information from one or more authorized vehicles, as described in relation to the process 1100 of FIG. 11. At 1220, the computing system accesses a mapping of vehicle locations and corresponding recall and/or maintenance status values. The computing system may generate this information directly from the data received at 1210 or the computing system may pass the data received at 1210 to another system or third-party service, which then generates the mapping and returns it to the computing system. In arrangements, the mapping depicts vehicle locations on a map and an indication of whether a given type of recall and/or maintenance has been performed on those vehicles. A human or computer analyzes the mapping accessed at 1220, to determine geographic regions in which a relatively large percentage of eligible vehicles have not had recall or maintenance work performed. Accordingly, at 1230, the manufacturer deploys a recall or maintenance resource in a region based on the mapping. For example, in arrangements, the manufacturer deploys an authorized vehicle in a region in which a relatively large percentage of eligible vehicles have not had recall or maintenance work performed. The authorized vehicle then travels the roads of the region and broadcasts recall or maintenance information for a set of vehicles as described in relation to process 1100 of FIG. 11.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claimed manner of using a DLT for monitoring and processing recalls for parts of a vehicle as taught in Mullins in view of Nagla to incorporate further comprising: providing an indication of the completion percentage to a client device for display on a user interface as taught in Misra with the motivation of displaying information to a user pertaining to the effectiveness of a recall for a particular subsystem of a vehicle. (Misra paragraphs 157-159)
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Mullins et al. (US 20210035120) in view of Nagla et al. (US 20180018723) and Shanton et al. (US 20220044253).
Referring to claims 7 and 14,
Mullins further teaches in response to determining that one of the identified vehicles from the distributed ledger is not included in the set of vehicles from the vehicle manufacturer, (Mullins paragraphs 40-42 teaching with the disclosed adaptive and verifiable device BOM infrastructure in place, device/part recalls, for example, can be quickly detected. The disclosed adaptive and verifiable device BOM infrastructure also facilitates new operational dynamics such as automatically preventing an owner from operating a device if a critical recall has occurred. FIG. 4 is a flow chart illustrating an exemplary implementation of a part registry update process 400, according to some embodiments of the disclosure. In the example of FIG. 4, a part manufacturer 210 (or supplier) initially updates the public attributes of a specific part on their DLT during step 410 to reflect a recall of the specific part. A test is performed by the device comprising the specific part during step 420 to determine if a recall has been issued for the specific part. In this manner, the next time that the device performs the parts verification process 400, the recall would be detected. If it is determined during step 420 that a recall has been issued for the specific part, then the device applies predefined recall policy logic during step 430 to determine how to proceed and/or operate. For example, for non-critical recalls, an alert can be displayed to the user. For critical recalls, the user could be restricted from operating the device. In a further variation, an OEM (original equipment manufacturer) can monitor DLTs of one or more part suppliers for recalls, and upon detecting a recall, the OEM can update the status of an issued verifiable claim (e.g., change status to a suspended state). When the device then attempted to verify the status of a parts claim, for example, using the part verification process 400, the device would detect the status change and take an appropriate action (e.g., implementing one or more predefined application policies).
Mullins in view of Nagla does not teach or suggest communicating with the vehicle manufacturer to provide the vehicle manufacturer with identification information for the identified vehicle not included in the set of vehicles and to determine a reason for the identified vehicle not being included in the set of vehicles from the vehicle manufacturer.
However, Shanton, which is directed to determining the disposition of a vehicle having an unresolved recall notice, teaches communicating with the vehicle manufacturer to provide the vehicle manufacturer with identification information for the identified vehicle not included in the set of vehicles and to determine a reason for the identified vehicle not being included in the set of vehicles from the vehicle manufacturer. (Shanton paragraph 24 teaching Recall Investigation VIN Attribute Tool (RIVAT) system 145 may be used to perform the automated investigation of the status of a vehicle with respect to an outstanding recall. For example, a vehicle that is subject to a recall may be identified and the RIVAT system 145 may determine based on information from the integration layer 130 whether the vehicle is known to have resolved the recall by undergoing the repair related to the recall. Further, the RIVAT system 145 may identify vehicles that have unresolved recall repairs and attempt to resolve/account for the unresolved recall repair by, for example, explaining why the recall repair is unresolved, identifying information for notifying the current owner of the recall, and so forth. The RIVAT system 145 is described in more detail with respect to FIG. 2. Shanton paragraph 27 teaching in use, the system 100 may be used to compile information, perform recall investigation, and generate and report compliance information with respect to the recall. The enterprise internal systems and data sources 105 may provide internal information including, for example, customer, vehicle, and component information through the data lake 110 to the integration layer 130. The data lake 110 may be used to provide information either by requesting or automatically transmitting (e.g., via batch data load, an application programming interface request, a file transfer protocol request, or the like) the data from data lake 110 to integration layer 130. Vendor data sources 120 may compile information related to vehicles that have been sold by the automotive manufacturer. The data from vendor data sources 120 may have an associated vehicle identification number (VIN) for each vehicle such that the integration layer 130 may uniquely identify each vehicle and associate disparate information about the same vehicle. The vendor data sources 120 may also provide information to integration layer 130 via, for example, file transfer protocol request, application programming interface request, batch data load, or the like. The regulatory rules and other compliance rules may be stored in or provided via regulatory rules 115, which may populate recall database 125 with the regulatory compliance information and rules. The recall database 125 may store data on the regulatory rules as well as compliance information provided by the RIVAT system 145. The recall database 125 may be used by integration layer 130 to generate or identify vehicles that have unresolved recall repairs as well as all associated internal data received through the data lake 110 and vendor data sources 120. After performing the initial data alignment processing as well as source level outcome processing, the integration layer 130 may feed all such data into RIVAT system 145 for cross vendor outcome processing and final outcome processing. The RIVAT system 145 may process the integration layer 130 aligned information from vendor data sources 120, data lake 110, and recall database 125 to generate a disposition of the identified vehicle as discussed in more detail herein. Once a disposition is determined, the RIVAT system 145 may provide the disposition information to the enterprise internal systems and data sources 105, the recall database 125, and the regulatory agencies 140. Shanton paragraph 31 teaching the vendor level outcome rules 220 may then be applied by the integration layer 130 to the aligned vendor data 215. The vendor level outcome rules 220 may assign dispositions (i.e., vendor level predicted dispositions) to the vehicle based on the vehicle, the customer, and/or the part classifications. For example, a vehicle may be classified as destroyed and the customer may be classified as Incorrect Owner Incorrect Address based on Vendor A Data 205a and Vendor A outcome rules 220a in combination with the contact information of the customer for the VIN of the vehicle stored in the recall database 125. Other vendor dispositions for that VIN may be different depending on the data received from the vendor. Other examples may be that the owner sold the vehicle and no lead is provided; that the owner's address is identified based on, for example, state registration data; that the vehicle has been stolen; that the vehicle has been identified but the owner is unknown; that the part to be repaired is not present in the vehicle and the vehicle is destroyed; and so forth. The vendor level outcome options may be limited to a list of vehicle, customer, and/or part classifications normalized into each vendor data 205 by the vendor alignment rules 210. The vendor level outcome data (i.e., vendor predicted disposition of the VIN) may be stored as outcome vendor data 225. Each vendor may result in a different vehicle, customer, and/or part level outcomes as outcome vendor data 225a, 225b, through 225n. Shanton paragraphs 33-34 the outcome vendor data 225 may be analyzed collectively for each vehicle. An initial check may be performed to confirm whether the recall repair has been performed on the VIN based on the recall database 125 data. In some embodiments, the automotive manufacturer may solicit vendor data for a VIN and while waiting for the vendors to provide data, the owner of the vehicle may appear for recall repair, which updates the recall database 125 with information indicating the VIN is no longer an unresolved recall repair. At such point, processing for that VIN may stop as the recall repair is resolved. Should the check indicate that the recall repair for the VIN remains unresolved, processing continues. For example, the RIVAT system 145 may apply the cross vendor rules 230 to data from each vendor level outcome data 225 that includes the VIN being analyzed. The cross vendor rules 230 may utilize vehicle, customer/owner, and/or part classification data from each vendor (i.e., the predicted disposition stored as the outcome vendor data 225) to make a final determination of the vehicle, customer, and/or part classifications of the vehicle being analyzed. The cross vendor rules 230 may assign a weight to the predicted determinations based on, for example, the age of the data, the source of the data, and the like. For example, data that was collected months ago may be given a lower weight than data that was collected more recently. As another example, data from sources such as state agencies may be given a higher weight than data from other sources that may be deemed less reliable. Upon applying the cross vendor rules 230, the RIVAT system 145 may determine a final vehicle, customer, and/or part classification of the vehicle. FIG. 10 illustrates an example table 1000 indicating vehicle, customer, and part classifications from Vendors A through E. As shown, the selected part classification 1005 is selected from the data provided by Vendor C after the collective outcome vendor data 225 from each vendor is analyzed. As further shown in the example of table 1000, the selected vehicle classification 1010 is from Vendor D, and the selected customer classification 1015 is from Vendor E. As such, the classification for each of the part, customer, and vehicle may be selected from data from differing vendors. After the final cross vendor vehicle, customer, and/or part dispositions are determined, such as those selected and shown in FIG. 10, a final outcome disposition may be created and include a category and/or subcategory explanation for the unresolved recall repair, an indication that the unresolved recall repair has been resolved, or a plan for resolving the unresolved recall repair. The selected vehicle classification, part classification, customer classification, or some combination thereof may be determinative for the final outcome disposition. In some embodiments, a hierarchical listing of classifications may be used to generate the final disposition. As an example, a selected vehicle classification of destroyed may fall near the top of the hierarchical listing such that any VIN having a vehicle classification of destroyed may be reported as destroyed without further analysis. As another example, a selected part classification of modified, indicating the part has been modified or replaced in the vehicle, may also be reported as a final outcome disposition, but it may fall further down the hierarchical listing than a destroyed vehicle classification because it may be more determinative that the vehicle is no longer on the road than that the part was modified in the vehicle. While examples have been provided throughout this description, any appropriate hierarchical listing and set of classifications may be created for use with RIVAT system 145. The final outcome disposition may also include an associated certainty value to indicate a confidence of RIVAT system 145 that the final outcome disposition is correct. Once the RIVAT system 145 makes a final outcome determination of the disposition of the vehicle, the final outcome disposition is stored as a VIN determination 235 for the vehicle. In some embodiments, the VIN determination 235 may be used to perform further activities or analysis. For example, an indication that the vehicle owner and address is identified may be used in a plan for resolving the unresolved recall repair. For example, the automotive manufacturer may use the customer information to provide notice to the owner of the recall so the owner may have the repair performed on the vehicle. The final outcome disposition of the vehicle may be provided to any regulatory agencies 140 for compliance. Other information from the RIVAT system 145 including the owner's identified address, for example, may be provided to the recall database 125 and the enterprise internal systems and data sources 105.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the claimed manner of using a DLT for monitoring and processing recalls for parts of a vehicle as taught in Mullins in view of Nagla to incorporate communicating with the vehicle manufacturer to provide the vehicle manufacturer with identification information for the identified vehicle not included in the set of vehicles and to determine a reason for the identified vehicle not being included in the set of vehicles from the vehicle manufacturer as taught in Shanton with the motivation of informing a vendor regarding a unresolved recall repair and enabling the vendor to make a final disposition regarding the status for compliance purposes. (Shanton paragraphs 24, 27, 31, and 34)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
O’Brien et al. (US 20190303843) – directed to tracking an item in a distributed environment.
Fournier et al. (US 20170154338) – directed to measure and ensuring compliance with vehicle recalls or mandatory service updates.
Dey et al. (US 20190378352) – directed to monitoring of vehicle conditions in a blockchain.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J MONAGHAN whose telephone number is (571)270-5523. The examiner can normally be reached on Monday- Friday 8:30 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached on (571) 270-1833. 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.
/Michael J. Monaghan/Examiner, Art Unit 3629