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 .
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.
Step 1 of the Subject Matter Eligibility Test entails considering whether the claimed subject matter falls within the four statutory categories of patentable subject matter identified by 35 U.S.C. 101: Process, machine, manufacture, or composition of matter.
Claims 1-20 are directed to a method (process) and a system (machine or manufacture), respectively. As such, the claims are directed to statutory categories of invention.
If the claim recites a statutory category of invention, the claim requires further analysis in Step 2A. Step 2A of the Subject Matter Eligibility Test is a two-prong inquiry. In Prong One, examiners evaluate whether the claim recites a judicial exception.
Claim(s) 1, 7 and 15 recites abstract limitations, which are emphasized (bolded) below:
1. A vehicle health record system comprising: a plurality of application programming interfaces configured to interface with a plurality of data sources to automatically access and 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;
a raw data lake configured to receive and store the ingested vehicle data;
a server coupled to the plurality of application programming interfaces and the raw data lake, the server configured to receive the ingested vehicle data and perform processes selected from the group consisting of: removing personal identification information from the ingested data, normalizing, and formatting the data, and to store the processed vehicle data in a normalized data lake;
the server being configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain; and
the server being configured to enable authorized access to the processed vehicle data in the blockchain.
7. A vehicle health record system comprising: an application programming interface logic module configured to interface with a plurality of data sources to automatically access and 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;
a raw data lake configured to receive and store the ingested vehicle data;
a server coupled to the application programming interface logic module and the raw data lake, the server having logic configured to: access the vehicle data in the raw data lake; perform processes selected from the group consisting of: removing personal identification information from the ingested data, normalizing, formatting the data, storing the processed vehicle data in a normalized data lake;
the server further having logic configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain, enable authorized access to the processed vehicle data in the blockchain by authorized users.
15. A vehicle health record method comprising: automatically interfacing with a plurality of data sources to automatically access and 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;
storing the ingested vehicle data in a raw data lake;
removing personal identification information from the ingested vehicle data, normalizing the data, and generating pre-processed vehicle data;
storing the pre-processed vehicle data in a normalized data lake;
storing a version of the pre-processed vehicle data in a plurality of data records of a blockchain, the vehicle data being automatically propagated to all copies of the blockchain; and
enabling authorized access to the vehicle data in the blockchain.
These limitations, as drafted, are a process that, under its broadest reasonable interpretation, as drafted, are a process that, under its broadest reasonable interpretation, cover performance of the limitations in the mind, or by a human using pen and paper, and therefore recite mental processes, nothing in the claim element precludes the aforementioned steps from practically being performed in the human mind, or by a human using pen and paper. The mere recitation of a generic computer does not take the claim out of the mental process grouping. Thus, the claim recites an abstract idea.
If the claim recites a judicial exception in step 2A Prong One, the claim requires further analysis in step 2A Prong Two. In step 2A Prong Two, examiners evaluate whether the claim recites additional elements that integrate the exception into a practical application of that exception.
The claim(s) recite additional elements of: which are emphasized (underlined) below:
1. A vehicle health record system comprising: a plurality of application programming interfaces configured to interface with a plurality of data sources to automatically access and 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;
a raw data lake configured to receive and store the ingested vehicle data;
a server coupled to the plurality of application programming interfaces and the raw data lake, the server configured to receive the ingested vehicle data and perform processes selected from the group consisting of: removing personal identification information from the ingested data, normalizing, and formatting the data, and to store the processed vehicle data in a normalized data lake;
the server being configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain; and
the server being configured to enable authorized access to the processed vehicle data in the blockchain.
7. A vehicle health record system comprising: an application programming interface logic module configured to interface with a plurality of data sources to automatically access and 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;
a raw data lake configured to receive and store the ingested vehicle data;
a server coupled to the application programming interface logic module and the raw data lake, the server having logic configured to: access the vehicle data in the raw data lake; perform processes selected from the group consisting of: removing personal identification information from the ingested data, normalizing, formatting the data, storing the processed vehicle data in a normalized data lake;
the server further having logic configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain, enable authorized access to the processed vehicle data in the blockchain by authorized users.
15.A vehicle health record method comprising: automatically interfacing with a plurality of data sources to automatically access and 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;
storing the ingested vehicle data in a raw data lake;
removing personal identification information from the ingested vehicle data, normalizing the data, and generating pre-processed vehicle data;
storing the pre-processed vehicle data in a normalized data lake;
storing a version of the pre-processed vehicle data in a plurality of data records of a blockchain, the vehicle data being automatically propagated to all copies of the blockchain; and
enabling authorized access to the vehicle data in the blockchain.
The additional elements include:
… a plurality of application programming interfaces configured to interface with a plurality of data sources to automatically
… a raw data lake configured to receive and store the ingested vehicle data…
… a server coupled to the application programming interface logic module and the raw
… a normalized data lake
… a blockchain
amounts to merely indicating functions of the plurality of application programming interface(s), data lake(s), server(s), and blockchain(s) are recited at a high-level of generality such that it amounts no more than mere instructions to apply the exception using a generic computer component, alternatively the limitation(s) amount to merely indicating a field of use or technological environment in which to apply a judicial exception and cannot integrate the judicial exception into a practical application (see MPEP 2106.05(h)). The claimed components are recited at a high level of generality and are merely invoked as tool to perform the abstract idea.
The functions of the additional elements;
… storing the processed vehicle data
… storing the processed vehicle data in a normalized data lake
… the server further having logic configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain
… the server being configured to store the processed vehicle data in a plurality of data records of a blockchain, the processed vehicle data being automatically propagated to all copies of the blockchain
… storing the ingested vehicle data in a raw data lake
… storing a version of the pre-processed vehicle data in a plurality of data records of a blockchain, the vehicle data being automatically propagated to all copies of the blockchain
amounts to extra-solution activity (i.e. activity incidental to the primary process that is merely a nominal or tangential addition to the claim, see MPEP 2106.05(g)). The monitoring/receiving/transmitting/collecting/storage functions are recited at a high level of generality (i.e. as a general means of gathering, storing and transmitting vehicle data), and amounts to data gathering and storage, which are forms of extra-solution activity. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
If the additional elements do not integrate the exception into a practical application in step 2A Prong Two, then the claim is directed to the recited judicial exception, and requires further analysis under Step 2B to determine whether they provide an inventive concept (i.e., whether the additional elements amount to significantly more than the exception itself).
With respect to the functions of the computing elements (additional elements identified above), use of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TLI Communications LLC v. AV Auto, LLC, 823 F.3d 607, 613, 118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
Additionally/alternatively, with respect to the functions of gathering and storing data, the Symantec, TLI, OIP Techs. and buySAFE court decisions cited in MPEP 2106.05(d)(II) indicate that mere collecting, receiving or transmitting data over a network is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here). Further, prior art Kronenberg (US 2010/0082179 A1), discloses that various combinations of sensors, detectors, processors, cameras, and other monitoring means known in the art can be used to monitor driving parameters of vehicles (see [0044]). With respect to the storage and retrieval functions, The Versata and OIP Techs court decisions cited in MPEP 2106.05(d)(II) indicate that storing and retrieving data in memory is a well‐understood, routine, conventional function when it is claimed in a merely generic manner (as it is here).
Moreover, the specification demonstrates the well-understood, routine, conventional nature of additional elements as it describes the additional elements as well-understood or routine or conventional (or an equivalent term), as a commercially available product, or in a manner that indicates that the additional elements are sufficiently well-known that the specification does not need to describe the particulars of such additional elements to satisfy 35 U.S.C. §112(a).
Thus, even when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea.
Claims 2, and 8 further recites the creation of AI-based derivative products and services based on processed data, which at this level of breadth merely amounts to apply it. The recitation of claim limitations that attempt to cover any solution to an identified problem with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, does not integrate a judicial exception into a practical application or provide significantly more because this type of recitation is equivalent to the words “apply it”. See Electric Power Group, LLC v. Alstom, S.A., 830 F.3d 1350, 1356, 119 USPQ2d 1739, 1743-44 (Fed. Cir. 2016); Intellectual Ventures I v. Symantec, 838 F.3d 1307, 1327, 120 USPQ2d 1353, 1366 (Fed. Cir. 2016); Internet Patents Corp. v. Active Network, Inc., 790 F.3d 1343, 1348, 115 USPQ2d 1414, 1417 (Fed. Cir. 2015).
Claim(s) 3-4, 9-10, 13-14, 16-17 and 20 act to further defining previously recited abstract ideas (e.g., further characterization of data processing, further characterization of user authorization for access to data, creation of derivative products and services) without reciting any further additional elements beyond those identified above with respect to the independent claims. For the reasons described above with respect to the independent claims this judicial exception is not meaningfully integrated into a practical application, or significantly more than the abstract idea.
Claims 5-6, 11-12, 18-19 further recites a machine learning model (apply it), used in the further processing data (abstract concepts), which when recited at this level of breadth merely act to apply the abstract idea.
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), 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, the processed **** data being automatically propagated to all copies of the blockchain; and
(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. ....)
the server being configured to enable authorized access to the processed *** data in the blockchain.
(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), 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), 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), 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), 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), 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), 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), 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.
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