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 .
Response to Arguments
Applicant’s arguments with respect to the 35 U.S.C. 101 rejection as set forth in the previous office action have been fully reviewed and found to be persuasive; the 35 U.S.C. 101 rejection has been withdrawn accordingly.
Applicant’s arguments with respect to claim(s) 1 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
In response to Applicant's arguments filed 04/23/2026, as set forth in page [8 of 12]:
In response to applicant's arguments against the references individually, 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). This limitation is taught by a combination of Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1).
It should be noted that both Michaelis and Ernst disclose management/processing of incoming data. As such the combination of their teachings as impermissible hindsight between two references of inapplicably related fields with regards to an improper combination is not found to be persuasive.
Applicant relies upon a strict interpretation of Michaelis wherein “it may be desirable… to erase…”, as argued on page [9 of 12]. Michaelis merely discloses an alternative consideration but does not specifically disclose a system which teaches away from retaining records. Relying upon this alternative consideration of Michaelis alone, improperly strips the disclosure to a narrow interpretation that does not include the full teachings of Michaelis as it relates to [0284] one or more conditions for retaining and/or deleting information related to a task (such as one or more cryptographic blocks, one or more localized channels, chain code used to validate proposals, etc.).
Additionally, an interpretation of Michaelis to include “preventing observation or access” does not fail in the face of an “open-marketplace” reference. The restriction/access to informational records is mutually applicable to the distribution and retention of data records.
Regarding an argument that Michaelis “disfavors” blockchain storage system as a way to show Michaelis teaches away from the recited claim limitation(s) is not found to be persuasive. Michaelis discloses [0328] Data lake 2002 is digital data storage system, comprising a raw data storage system 2004, a metadata storage system 2006, and a normalized metadata storage system 2008. Each of the aforementioned distributed storage systems may comprise a blockchain storage system.
Arguments directed toward Iwaki are found to be unpersuasive at this time. Iwaki is merely being relied upon for teaching a consideration for removing personal data and not for teaching the limitation(s) including the server, as disclosed by Michaelis (e.g., server 2012).
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 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.
Claim(s) 1 2 5 7-8 11 13-16 18 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1).
Regarding claim 1, Michaelis (US-20230214370-A1) discloses:
A **** record system comprising:
a plurality of application programming interfaces (e.g. network interfaces) configured to interface with a plurality of data sources (e.g. observational data sources 2010) to automatically access and ingest **** data ****, the data being selected from the group consisting of **** data (e.g., observational data);
(Michaelis [005] Data provided to a data lake may comprise digitized photos, video, or audio information, social media account data, email, financial information, or almost any kind of digital information; [0325] FIG. 20 is a functional block diagram of one embodiment of a system 2000 for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data. System 2000 may be used to receive observational data, comprising raw data and metadata, and to store the raw data on one database, and the metadata on another database, with an identifier stored in association with the raw data … The metadata may be cleansed and/or normalized ... Michaelis [0349] FIG. 21 is a functional block diagram of one embodiment of many of the entities of system 2000, i.e., raw data storage system 2004, metadata storage system 2006, normalized metadata storage system 2008, training computer 2014, ingest server 2012, labeling computer 2020 administrator node 2022, neural network managing node 2026, and model registry 2024. Michaelis [0352] Network interface 2104 is coupled to processor(s) 2100, comprising circuitry for sending and receiving packetized data to/from other nodes and entities in system 2000, typically via wide-area network 2018. Such circuity is well-known in the art.)
a raw data lake configured to receive and store the ingested **** data;
(Michaelis [0328] Data lake 2002 is digital data storage system, comprising a raw data storage system 2004, a metadata storage system 2006, and a normalized metadata storage system 2008. Each of the aforementioned distributed storage systems may comprise a blockchain storage system.)
a server (e.g., server 2012) coupled to the plurality of application programming interfaces (e.g., network interfaces) and the raw data lake (e.g., raw data storage 2004 of Data lake 2002), the server configured to receive the ingested *** data and perform processes selected from the group consisting of: ****, normalizing, and formatting the data, and to store the processed **** data in a normalized data lake (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database. normalized metadata storage 2008 of Data lake 2002);
(Michaelis [0328] Data lake 2002 is digital data storage system, comprising a raw data storage system 2004, a metadata storage system 2006, and a normalized metadata storage system 2008. … [0329] An ingest server 2012 receives “observational data” from a plurality of data sources 2010A -2010n, such as digital data from mobile phones, fixed or mobile cameras, other databases, or from almost any source of digital data. The observational data is typically provided to ingest server 2012 over wide-area network 2018; [0334] After the raw data has been stored in raw data storage system 2004 and its associated metadata stored in metadata storage system 2006, in some embodiments, the metadata may be labeled in accordance with modern labeling techniques in order to identify data of interest contained within the raw data; [0335] In one embodiment, the metadata may be “cleansed” or “normalized” by ingest server 2012 in order to, for example, reduce/eliminate polysemes, delete duplicates, account for localization differences, etc. It should be understood that multiple instances of ingest server 2012 may be employed to perform data cleansing, and may be co-located with a server that performed the original ingest, or be located separately together with metadata storage system 2006 or normalized metadata storage system 2008. The normalized metadata may then be stored in normalized metadata storage system 2008.)
the server being configured to store the processed **** data in a plurality of data records of a blockchain **** and managed by a peer-to-peer computer network [0033], **** a previous block in the chain, a timestamp, ****, the processed **** data being automatically propagated to all copies of the blockchain [0036];
****; and
(Michaelis [0033, 0036] A resource may be stored in a single database or distributed on a network of computers, such as a peer-to-peer network or on a blockchain network… Resource 108 may be stored by a single entity, for example, a digital file stored in a single database, or a communication link to a remote vehicle, or, in the case of a digital file, resource 108 may be stored across a distributed storage system such as distributed storage network 118. Distributed storage network 118 may comprise a peer-to-peer network or a blockchain network comprising a plurality of storage nodes)
(Michaelis [0036] In the case of a blockchain network, each storage node 120 stores an encrypted copy of either a portion or an entire digital file(s) provided by resource 108, and tracks attributes of such files, such as a data and time of creation, modification or storage, an origination identifier describing a resource that generated the file(s), etc. Generally, when a majority of storage nodes 120 agree that valid data has been provided by resource 108, an immutable, linked, cryptographic “block” of data is produced and added to a chain of pre-existing blocks to form a blockchain. A storage node 120 may include the valid data directly in the cryptographic “block”, or maintain separate “blocks” whereby one “block” contains the valid data’s meta-data and cryptographic signature, and another “block” the actual valid data. The “blocks” may reside on the same blockchain, or on two distinct blockchains.)
(Michaelis [0328] Data lake 2002 is digital data storage system, comprising a raw data storage system 2004, a metadata storage system 2006, and a normalized metadata storage system 2008. Each of the aforementioned distributed storage systems may comprise a blockchain storage system. ....)
Trim US-20200302562-A1 discloses in a similar invention field of endeavor relating to vehicles, a consideration for a plurality of blockchains being managed by authority “…that are securely linked together as a chain via cryptographic hashes…, each data record in the chain containing a cryptographic hash of a previous block in the chain, a timestamp, and transaction data,… and the data in any given data record cannot be altered retroactively without altering all subsequent data records in the chain”;
(Trim [0024] According to one embodiment, blockchain ledger 120 at “A” can be an immutable ledger and can be provided by a blockchain ledger. Blockchain ledger 120 at “A” can include a list of records called blocks, which can be linked together using cryptography. Each block of blockchain ledger 120 at “A” can include a cryptographic hash of transaction data (that is, a digital fingerprint), a cryptographic hash of a previous block, a timestamp, and the transaction data. The hash of the transaction data can include a Merkle tree root hash. Blockchain ledger 120 can be resistant to modification of data. Blockchain ledger 120 can be configured so that once a block of data is recorded into blockchain ledger 120 the data cannot be altered retroactively without alteration of all subsequent blocks. According to one embodiment, alteration of blockchain ledger 120 can be restricted and can be permissible, e.g. only on consensus of blockchain network members. Each block of a blockchain ledger 120 can contain include a cryptographic hash of transaction data, a cryptographic hash of a previous block, a timestamp, and the transaction data. A previous block hash can link the blocks together and prevent any block from being altered or a block from being inserted between two existing blocks and accordingly each subsequent block strengthens the verification of the previous block and, hence, the entire blockchain. The described process renders the blockchain tamper evident leading the attribute of immutability.)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a blockchain that is securely linked together as a chain via cryptographic hashes, each data record in the chain containing a cryptographic hash of a previous block in the chain, a timestamp, and transaction data, and the data in any given data record cannot be altered retroactively without altering all subsequent data records in the chain with a reasonable expectation for success, as taught by Trim, for the benefit of rendering [0024] the blockchain tamper evident leading the attribute of immutability.
the server being configured to enable authorized access to the processed *** data in the blockchain by authorized users via the peer-to-peer computer network [0033, 0036].
(Michaelis [0033, 0036] Systems, methods and apparatus are described for authorizing access to resources using distributed ledger technology … If all of the conditions listed in the authorization record are satisfied, the requesting entity is granted access to the resource … A resource may be stored in a single database or distributed on a network of computers, such as a peer-to-peer network or on a blockchain network… Resource 108 may be stored by a single entity, for example, a digital file stored in a single database, or a communication link to a remote vehicle, or, in the case of a digital file, resource 108 may be stored across a distributed storage system such as distributed storage network 118. Distributed storage network 118 may comprise a peer-to-peer network or a blockchain network comprising a plurality of storage nodes)
(Michaelis [0388] At block 2258, after some time, an authorized user of system 2000 may wish to validate the integrity of a particular neural network model, or correct one or more deficiencies of a particular neural network model (for example, an inability to correctly identify an object in numerous digital images). Such a user may form a query using a computer, smartphone or some other computing device and send the query to normalized metadata storage system 2008. ... Michaelis [0042] ... Well-known public key encryption techniques may be used to authenticate the user, using a private/public key combination...)
Michaelis discloses a system for managing (receiving, processing, storing) data in a data lake with integrated blockchain. Michaelis also discloses that the data management system can be applied to any data type. Ernst, in a similar field of endeavor, discloses a similar data management application in the field of vehicle health data.
Ernst (US-20160110934-A1) discloses in a similar invention field of endeavor, a consideration for “…vehicle health … ingest vehicle data associated with a plurality of automotive vehicles, the data being selected from the group consisting of vehicle identification number (e.g., VIN), vehicle build data (e.g., model, year, trim), department of motor vehicle data (e.g., government data), vehicle parts data (e.g., trim), vehicle maintenance data (e.g., maintenance records), vehicle repair data (e.g., safety recall data), collision data (e.g., collision sensor communication), insurance claim data (insurance premium payments clue), vehicle diagnostic data (e.g., onboard diagnostic capabilities), recall data (e.g., recall data), vehicle pricing data (e.g. sale price), and connected car data (e.g., market indicators)”,
(Ernst [0014] Input values are combined and weighted in such a way as to create a single output value that can be compared to other vehicles of a similar nature. [0067] …the system receives information to identify a vehicle as an instance of a known type or classification of vehicle (320). For example, specific vehicle information may include a model, year of manufacture, and information about the trim level, options, conditions, and owner. Often, much of this information may be encoded in a Vehicle Identification Number (“VIN”), so a preferred embodiment receives a bulk of the specific vehicle information as a VIN. [0062] … database 212 (including vehicle data such as make, model, year, mileage, location, maintenance records, etc., 213; and owner data 214), and safety recall data 215 (e.g., manufacturer and government data)… a vehicle collision sensor or critical status alert [0074] insurance premium payments clue, driver's license/registration renewals, and vehicle safety or smog inspection renewals… a vehicle's native onboard diagnostics capabilities [0065] Other information may include list prices, actual sale prices, or market indicators such as supply and demand of the vehicle.)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include vehicle health … ingest vehicle data associated with a plurality of automotive vehicles, the data being selected from the group consisting of vehicle identification number, vehicle build data, department of motor vehicle data, vehicle parts data, vehicle maintenance data, vehicle repair data, collision data, insurance claim data, vehicle diagnostic data, recall data, vehicle pricing data, and connected car data with a reasonable expectation for success, as taught by Ernst, for the benefit of enabling the system of Michaelis to provide [0005] a system and method for increasing a vehicle owners' likelihood of having maintenance and repair work performed on-time, and at a qualified service center… and extend (or be extended by) conventional data collection, analysis, optimization and predictor systems support features, and service center schedule-matching so that any combination is unequivocally better than traditional offerings.
The combination of Michaelis and Ernst disclose a data management system for collection, processing and storage of vehicle health data, and contemplates the removal of sensitive data (see [0254]) but does not explicitly disclose the removal of personal information as claimed. Iwaki, in a similar field of endeavor, discloses the removal of personal information from ingested data.
Iwaki (US-20200302782-A1) discloses in a similar invention field of endeavor, a consideration for “…removing personal identification information from the ingested data”,
([0027] For example, the classification unit 50 deletes the personal information stored in the buffer storage unit 51 after the transmission unit 30 transmits the personal information of the buffer storage unit 51 to the off-vehicle server)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include removing personal identification information from the ingested data with a reasonable expectation for success, as taught by Iwaki, for the benefit of protecting owner/user information and privacy.
Regarding claim 2, the modified system of Michaelis (US-20230214370-A1) discloses 2. The vehicle health record system of claim 1, wherein the server is configured to enable creation of AI-based derivative products and services based on the processed vehicle data.;
(Michaelis [0030-32; FIG.20] generation of neural network 2016.; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 5, the modified system of Michaelis (US-20230214370-A1) discloses 5. The vehicle health record system of claim 1, further comprising machine learning models used to analyze the data in the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database. normalized metadata storage 2008 of Data lake 2002) lake to gain insight and generate value-added information and derivative products and services.;
(Michaelis [0328] Data lake 2002 is digital data storage system, comprising a raw data storage system 2004, a metadata storage system 2006, and a normalized metadata storage system 2008... Michaelis [0329] An ingest server 2012 receives “observational data” from a plurality of data sources 2010A -2010n, such as digital data from mobile phones, fixed or mobile cameras, other databases, or from almost any source of digital data. The observational data is typically provided to ingest server 2012 over wide-area network 2018, Michaelis [0030-32; FIG.20] neural network 2016.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 7, (The limitation(s) is/are similar in scope to those disclosed in the system/method of claim(s) 1 and are therefore rejected under the same premise, for more information please see the rejection in re claim(s) 1.
Regarding Claim 8, the modified system of Michaelis (US-20230214370-A1) discloses 8. The vehicle health record system of claim 7, wherein the server is configured to enable creation of AI-based derivative products and services based on the processed vehicle data.;
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 14, the modified system of Michaelis (US-20230214370-A1) discloses 14. The vehicle health record system of claim 8, further comprising a second application programming interface logic module coupled to the server to enable efficient and easy authorized access to the AI-based derivative products and services.;
(Michaelis [0030-32; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data; [0388] At block 2258, after some time, an authorized user of system 2000 may wish to validate the integrity of a particular neural network model, or correct one or more deficiencies of a particular neural network model (for example, an inability to correctly identify an object in numerous digital images). Such a user may form a query using a computer, smartphone or some other computing device and send the query to normalized metadata storage system 2008. ... Michaelis [0042] ... Well-known public key encryption techniques may be used to authenticate the user, using a private/public key combination...)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 11, the modified system of Michaelis (US-20230214370-A1) discloses 11. The vehicle health record system of claim 7, further comprising machine learning models used to analyze the data in the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database. normalized metadata storage 2008 of Data lake 2002) lake to gain insight and generate value-added information and derivative products and services.;
(Michaelis [0030-32; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data; ; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used. )
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 13, the modified system of Michaelis (US-20230214370-A1) discloses 13. The vehicle health record system of claim 7, further comprising a second application programming interface logic module coupled to the server to enable efficient and easy authorized access to the blockchain data records.;
(Michaelis [0030-32; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data; (Michaelis [0388] At block 2258, after some time, an authorized user of system 2000 may wish to validate the integrity of a particular neural network model, or correct one or more deficiencies of a particular neural network model (for example, an inability to correctly identify an object in numerous digital images). Such a user may form a query using a computer, smartphone or some other computing device and send the query to normalized metadata storage system 2008. ... Michaelis [0042] ... Well-known public key encryption techniques may be used to authenticate the user, using a private/public key combination...; see also [0096] [0100])
Regarding claim 15, the limitation(s) is/are similar in scope to those disclosed in the system/method of claim(s) 1 and are therefore rejected under the same premise, for more information please see the rejection in re claim(s) 1.
Regarding claim 16, the modified system of Michaelis (US-20230214370-A1) discloses 16. The vehicle health record method of claim 15, further comprising enabling creation of derivative products and services based at least in part on the pre-processed vehicle data stored in the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake;
(Michaelis [0030-32; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 18, the modified system of Michaelis (US-20230214370-A1) discloses 18. The vehicle health record method of claim 15, further comprising building and training machine learning models to analyze the data in the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake to gain insight and generate value-added information and derivative products and services.;
(Michaelis [0030-32; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Regarding claim 20, the modified system of Michaelis (US-20230214370-A1) discloses 20. The vehicle health record method of claim 18, further comprising providing authorized access via a second application programming interface logic module coupled to the server for efficient and easy authorized access to the blockchain data records and the AI-based derivative products and services.;
(Michaelis [0030-32, 0257; FIG.20] neural network 2016… a system for managing data for use in machine learning applications, and for providing lineage and proof of integrity of the data, …Localized authorization nodes 1520 in localized blockchain authorization network 1508); [0388] At block 2258, after some time, an authorized user of system 2000 may wish to validate the integrity of a particular neural network model, or correct one or more deficiencies of a particular neural network model (for example, an inability to correctly identify an object in numerous digital images). Such a user may form a query using a computer, smartphone or some other computing device and send the query to normalized metadata storage system 2008. ... Michaelis [0042] ... Well-known public key encryption techniques may be used to authenticate the user, using a private/public key combination...)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Claim(s) 3 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 1 above and further in view of Gujjar (US-20140277921-A1).
Regarding claim 3, the modified system of Michaelis (US-20230214370-A1) discloses 3. The vehicle health record system of claim 1, further comprising a *** database used to identify and build relationship connections between data in the normalized data(e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used.)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Gujjar (US-20140277921-A1) discloses in a similar invention field of endeavor, a consideration for the database being “…a graph database”,
(Gujjar [0030] In particular, storage 28 may be used for storing the databases 26 and algorithms/models/heuristics 16. [0057] The user interface 255 displays a fix effectiveness chart 256 (e.g., histogram) similar to the chart described in FIG. 7 that includes various parts associated with the selected symptom and the percentage of effectiveness and ineffectiveness of fixes or corrective-actions associated with those parts. The user interface 255 may include graphical representations 258 of particular entries 260 associated with particular part-issue combinations falling under the selected symptom. The graphical representations 258 may group common part-issue combinations (e.g., for a particular aircraft) together (e.g., entries 262, 264). The graphical representations 258 include follow-up entries 260 (e.g., entry 266) linked to a particular entry 260…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a graph database used to identify and build relationship connections between data with a reasonable expectation for success, as taught by Gujjar, for the benefit of providing a visual user interface for quickly and efficiently organizing and presenting collected information.
Regarding claim 4, the modified system of Michaelis (US-20230214370-A1) discloses The vehicle health record system of claim 1, further comprising a *** database used to enable fast and efficient retrieval of similar data points from the normalized data(e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake.;
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used; see also [00342-00343] expedited utilization of stored data)
(Ernst [0014] [0062] [0067] [0074] collection of vehicle data; [0002] The invention relates to automated electronic financial or business practice arrangement. More specifically, the invention relates to a computerized arrangement which enables people to obtain information from their automobile, learn about its state of functionality (for instance, needing regularly maintenance and/or unplanned repair), and automatically be connected with the best-fit match service provider that meets their schedule requirements and repair provider requirements.)
Gujjar (US-20140277921-A1) discloses in a similar invention field of endeavor, a consideration for the data base being a “…a graph database”,
([0030] In particular, storage 28 may be used for storing the databases 26 and algorithms/models/heuristics 16. [0057] The user interface 255 displays a fix effectiveness chart 256 (e.g., histogram) similar to the chart described in FIG. 7 that includes various parts associated with the selected symptom and the percentage of effectiveness and ineffectiveness of fixes or corrective-actions associated with those parts. The user interface 255 may include graphical representations 258 of particular entries 260 associated with particular part-issue combinations falling under the selected symptom. The graphical representations 258 may group common part-issue combinations (e.g., for a particular aircraft) together (e.g., entries 262, 264). The graphical representations 258 include follow-up entries 260 (e.g., entry 266) linked to a particular entry 260…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a graph database used to identify and build relationship connections between data with a reasonable expectation for success, as taught by Gujjar, for the benefit of providing a visual user interface for quickly and efficiently organizing and presenting collected information.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 5 above and further in view of Lora (US-20190251759-A1).
Regarding claim 6, the modified system of Michaelis (US-20230214370-A1) discloses 6. The vehicle health record system of claim 5, wherein the machine learning models comprises a machine learning model logic configured to provide **results**;
(Michaelis [0004] Once a model has been trained, it may be applied to a neural network to interpret new data to infer results based on the new data.; see also [0337]-[0342] )
Lora (US-20190251759-A1) discloses in a similar invention field of endeavor, a consideration for the model being able to generate outputs that “…provide predictive repair and maintenance recommendations”,
(Lora [0013] a software module performing ingress and aggregation of vehicle data for a plurality of vehicles and storing the vehicle data in a central storage…; a software module predicting future vehicle events by application of one or more machine learning models to the vehicle data…, an opportunity genie presenting predicted future vehicle events for each vehicle in the plurality of vehicles and cost estimates for performing currently needed and predicted repairs...
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include wherein the machine learning models comprises a machine learning model logic configured to provide predictive repair and maintenance recommendations with a reasonable expectation for success, as taught by Lora, for the benefit of utilizing artificial intelligence to identify and predict required maintenance and repairs, allowing a user to address vehicle health conditions before experiencing unwanted operational conditions.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 7 above and further in view of Gujjar (US-20140277921-A1).
Regarding claim 9, the modified system of Michaelis (US-20230214370-A1) discloses 9. The vehicle health record system of claim 7, further comprising a *** database used to identify and build relationship connections between data in the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake.;
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used; see also [00342-00343] expedited utilization of stored data)
Gujjar (US-20140277921-A1) discloses in a similar invention field of endeavor, a consideration for the database being “…a graph database”,
(Guijjar [0030] In particular, storage 28 may be used for storing the databases 26 and algorithms/models/heuristics 16. [0057] The user interface 255 displays a fix effectiveness chart 256 (e.g., histogram) similar to the chart described in FIG. 7 that includes various parts associated with the selected symptom and the percentage of effectiveness and ineffectiveness of fixes or corrective-actions associated with those parts. The user interface 255 may include graphical representations 258 of particular entries 260 associated with particular part-issue combinations falling under the selected symptom. The graphical representations 258 may group common part-issue combinations (e.g., for a particular aircraft) together (e.g., entries 262, 264). The graphical representations 258 include follow-up entries 260 (e.g., entry 266) linked to a particular entry 260…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a graph database used to identify and build relationship connections between data with a reasonable expectation for success, as taught by Gujjar, for the benefit of providing a visual user interface for quickly and efficiently organizing and presenting collected information.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 7 above and further in view of Koch (US-20140277902-A1).
The modified system of Michaelis (US-20230214370-A1) discloses 10. The vehicle health record system of claim 7, further comprising a *** database used to enable fast and efficient retrieval of similar data points from the normalized data (e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake.;
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used; see also [00342-00343] expedited utilization of stored data)
Koch (US-20140277902-A1) discloses in a similar invention field of endeavor, a consideration for the database being “…a vector database”,
(Koch [0085] The characteristics of these types of fleet applications can be summarized as a list with each variable annotated in time, such as the following Data Vector List that may be stored in a database or other data store: [Vehicle, location, driver, depot, inventory list, delivery stop list, vehicle fuel, vehicle capacity, vehicle condition, route and schedule, loading time, stop and delivery time for each scheduled stop, status (e.g., not started, route in process, at service stop, route completed, stopped at terminal)]…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a vector database with a reasonable expectation for success, as taught by Koch, for the benefit of a specialized database designed to store, manage, and query high-dimensional vector data.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 7 above and further in view of Lora (US-20190251759-A1).
Regarding claim 12, the modified system of Michaelis (US-20230214370-A1) discloses 12. The vehicle health record system of claim 7, wherein the machine learning models comprises a machine learning model logic configured to provide **outputs**.;
(Michaelis [0004] Once a model has been trained, it may be applied to a neural network to interpret new data to infer results based on the new data.; see also [0337]-[0342] )
Lora (US-20190251759-A1) discloses in a similar invention field of endeavor, a consideration for the model being able to generated outputs that “…provide predictive repair and maintenance recommendations”,
([0013] a software module performing ingress and aggregation of vehicle data for a plurality of vehicles and storing the vehicle data in a central storage…; a software module predicting future vehicle events by application of one or more machine learning models to the vehicle data…, an opportunity genie presenting predicted future vehicle events for each vehicle in the plurality of vehicles and cost estimates for performing currently needed and predicted repairs...
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include wherein the machine learning models comprises a machine learning model logic configured to provide predictive repair and maintenance recommendations with a reasonable expectation for success, as taught by Lora, for the benefit of utilizing artificial intelligence to identify and predict required maintenance and repairs, allowing a user to address vehicle health conditions before experiencing unwanted operational conditions.
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 15 above and further in view of Gujjar (US-20140277921-A1) and Koch (US-20140277902-A1).
The modified system of Michaelis (US-20230214370-A1) discloses 17. The vehicle health record method of claim 15, further comprising:
using *** database techniques to identify and build relationship connections between data in the normalized data(e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake; and
using *** database techniques to enable fast and efficient retrieval of similar data points from the normalized data lake.;
(Michaelis [0004] Once a model has been trained, it may be applied to a neural network to interpret new data to infer results based on the new data.; see also [0337]-[0343] )
Gujjar (US-20140277921-A1) discloses in a similar invention field of endeavor, a consideration for the database being “…a graph database”,
([0030] In particular, storage 28 may be used for storing the databases 26 and algorithms/models/heuristics 16. [0057] The user interface 255 displays a fix effectiveness chart 256 (e.g., histogram) similar to the chart described in FIG. 7 that includes various parts associated with the selected symptom and the percentage of effectiveness and ineffectiveness of fixes or corrective-actions associated with those parts. The user interface 255 may include graphical representations 258 of particular entries 260 associated with particular part-issue combinations falling under the selected symptom. The graphical representations 258 may group common part-issue combinations (e.g., for a particular aircraft) together (e.g., entries 262, 264). The graphical representations 258 include follow-up entries 260 (e.g., entry 266) linked to a particular entry 260…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a graph database used to identify and build relationship connections between data with a reasonable expectation for success, as taught by Gujjar, for the benefit of providing a visual user interface for quickly and efficiently organizing and presenting collected information.
Koch (US-20140277902-A1) discloses in a similar invention field of endeavor, a consideration for the database being “…a vector database”,
([0085] The characteristics of these types of fleet applications can be summarized as a list with each variable annotated in time, such as the following Data Vector List that may be stored in a database or other data store: [Vehicle, location, driver, depot, inventory list, delivery stop list, vehicle fuel, vehicle capacity, vehicle condition, route and schedule, loading time, stop and delivery time for each scheduled stop, status (e.g., not started, route in process, at service stop, route completed, stopped at terminal)]…)
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include a vector database with a reasonable expectation for success, as taught by Koch, for the benefit of a specialized database designed to store, manage, and query high-dimensional vector data.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Michaelis (US-20230214370-A1), Trim US-20200302562-A1, and Ernst (US-20160110934-A1), in view of Iwaki (US-20200302782-A1), as applied to claim 15 above and further in view of Lora (US-20190251759-A1).
The modified system of Michaelis (US-20230214370-A1) discloses 19. The vehicle health record method of claim 15, further comprising building and training machine learning models to analyze the data in the normalized data(e.g., [0325] The metadata may be cleansed and/or normalized and stored in the same or a different database) lake to provide ***outputs***.;
(Michaelis [0030-32; FIG.20] neural network 2016; [0341] The model file, the associated fingerprint and unique identifier of the model file, and an identification of the normalized metadata and associated raw data and original metadata objects used in any training run may be stored in, for example, model registry 2024 as a “lineage” of the model file, i.e., a history of when and how the model was trained, and an identification of the raw data, original metadata and normalized metadata used; see also [00342-00343] expedited utilization of stored data)
Lora (US-20190251759-A1) discloses in a similar invention field of endeavor, a consideration for the outputs being able to “…provide predictive repair and maintenance recommendations”,
([0013] a software module performing ingress and aggregation of vehicle data for a plurality of vehicles and storing the vehicle data in a central storage…; a software module predicting future vehicle events by application of one or more machine learning models to the vehicle data…, an opportunity genie presenting predicted future vehicle events for each vehicle in the plurality of vehicles and cost estimates for performing currently needed and predicted repairs...
It would have been obvious to one of ordinary skill in the art before the time the instant application was effectively filed to adapt the modified system of Michaelis to include wherein the machine learning models comprises a machine learning model logic configured to provide predictive repair and maintenance recommendations with a reasonable expectation for success, as taught by Lora, for the benefit of utilizing artificial intelligence to identify and predict required maintenance and repairs, allowing a user to address vehicle health conditions before experiencing unwanted operational conditions.
Conclusion
It should be noted that there exists prior art which is pertinent to significant though unclaimed features of the defined invention or directed to the state of art. The following is a brief description of relevant prior art cited but not applied:
Parasol (US-20240265752-A1) discloses in a similar invention, a consideration for [0016] FIG. 1 is a block diagram illustrating non-limiting exemplary architecture of a marketplace server for managing data relating to connected-cars in accordance with embodiments of the present invention. System 100 may include a server 110 implementing the data marketplace and connected via network 30 to a plurality of clients 40A-40D. Vehicle related data, possibly obtained for various sensors may be stored in raw format on a plurality of vehicle related data sources 10A-10N and are accessed by server 110 via a secured data link 20. Server 110 may include a processing records module 130 implemented by a computer readable code running on computer processor 120. Processing records module 130 may include a data collector 132, a normalization module 134 and a data anonymization module that are configured to collect, normalize and anonymize respectively the data arriving from the plurality of vehicle related data sources 10A-10N, thus creating a processed records data lake 160 storing vehicle related data.
See PTO-892: Notice of references cited.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW JOHN MOSCOLA whose telephone number is (571)272-6944.
The examiner can normally be reached M-F 7:30-5:30.
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, Abby Flynn can be reached on (571) 272-9855. 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.
/M.J.M./Examiner, Art Unit 3663
/ABBY J FLYNN/Supervisory Patent Examiner, Art Unit 3663
Prosecution Insights