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 .
Original written disclosure will be referred to as “Specification” hereinafter.
This final office action is in response to the applicant’s amendment received on 3/13/2026 (hereinafter “Amendment”).
Claim Status
Claims 1 and 12 have been amended, claims 1 and 12 being independent claims.
Claim 13 has been newly added.
Claims 1-13 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-12 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Per claim 1, the claim recites in part the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine, such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction. While the Specification show support for the machine entity platform generating a continuous machine identifier (see [0041], [0062], and [0073]), the Specification does not show support that the continuous machine identifier is sent to the machine).
The claim further recites in part which machine credentials are generated using seed identification data and changing identification data that is specific to the machine and the changing identification data that changes with operation of the machine. On paragraphs [0046]- [0048] recites As discussed herein, seed identification data is used along with other changing or new machine related data (and credential for the machine) to generate a profile or machine profile … At step 352, the system 102 generates the credential for the machine. As noted, the system 102 uses data that is specific or unique to the machine to generate the credential, for example the serial number of the machine … At step 356, the machine provides seed identification data/information to the system 102. The system 102 uses the seed identification data along with the credential for the machine to create a profile for the machine. In other word, the profile for the machine is created using the seed identification data along with the machine credential, not the machine credential.
Claim 12 is rejected for the same rational as above since claim 12 is significantly similar to claim 1.
Dependent claims are rejected as they depend on claim(s) above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-13 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Per claim 1, the claim recites that the machine has two profiles, i.e., transaction profile and a profile, and machine credentials. The claim recites that 1) the transaction profile and the machine credentials are analyzed at the machine entity platform to determine if the transaction request is authentic and if the transaction is an allowable-type of transaction for the machine and 2) the profile, particularly the profile that has been updated based on either the allow response or he decline response, is used by the machine entity platform for a next transaction.
In the instant Specification, the Specification mentions transaction profile in two paragraphs. For example, paragraph [0033] describes that the transaction profile is a set of permissions and rules that define the scope of allowable (allowable-type) purchases and, this, payment behavior for the vehicle while paragraph [0036] describes transaction profile in terms of machine’s profile, i.e., the profile is used to track, authenticate, manage, and enable network interaction by the vehicle … the machine entity platform 147 generates the continuous identifier for the vehicle only after the vehicle transaction profile is confirmed by the account owner. As such, one of ordinary skill in the art would not be able to ascertain the clear differences between the recited transaction profile and the recited profile when the claim is read in view of the Specification.
Furthermore, the Specification on paragraph [0046] describe a process 350 for generating a credential for a machine that is used to generate a machine account. The paragraph recites that seed identification data is used along with other changing or new machine related data (and credential for the machine) to generate a profile or machine profile. The profile is generated based on identification data/information for the machine and the machine’s credential. The paragraph goes on to provide an example, i.e., in the example of vehicle, the VIN may be the credential or used as part of generating the credential. [0047] further recites that the system 102 uses data that is specific or unique to the machine to generate the credential while [0048] recites that the system 102 uses the seed identification data along with the credential for the machine to create a profile for the machine. As such, one of ordinary skill in the art would appreciate that the machine’s credential is some information that is specific to the machine, i.e., VIN, and that the profile is generated using seed identification data along with the credential for the machine in the Specification.
The claim, however, recites that the machine credentials are generated using seed identification data and changing identification data that is specific to the machine. The scope of the claim is unclear as one of ordinary skill in the art would not be able to distinguish clear the difference between the machine credentials and the profiles when the claim is read in view of the Specification.
The claim also recites that the continuous machine identifier is used for authentication of the machine, the profile is used for a next transaction, while reciting that machine credentials and the transaction profiles are used to determine authenticity. The scope of the claim is unclear as the claim does not clearly illuminate the differences of the continuous machine identifier, machine credentials, the profile, and the transaction profile when reading the claim in view of the Specification.
Claim 12 is rejected for the same rational as above since claim 12 is significantly similar to claim 1.
Dependent claims are rejected as they depend on claim(s) above.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-13 are rejected under 35 U.S.C. 101 because the claimed invention the claimed invention is directed to abstract idea without significantly more.
MPEP 2106 provides step(s) in determining eligibility under 35 U.S.C. § 101. Specifically, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any additional elements in the claim must integrate the judicial exception into a practical application. If not, the inquiry continues to see whether any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself. Examples of abstract ideas include mathematical concepts, mental processes, and certain methods of organizing human activities.
Step 1:
In the instant case, claims 1-11 and 13 (group I) are directed to a method (i.e., process) while claim 12 is directed to a system. Thus, the claimed invention is directed towards one of the four statutory categories under 35 USC § 101. Nevertheless, the claims also fall within the judicial exception of an abstract idea without significantly more.
Step 2A, 1st prong:
Claim 1 recites: A method comprising:
a) receiving a transaction request at a machine entity platform in communication with a machine, wherein the transaction request is compared to a transaction profile for the machine, for a transaction associated with the machine, the machine having a profile and a machine account, wherein the machine account is created using machine credentials, which machine credentials are generated using seed identification data and changing identification data that is specific to the machine and the changing identification data that changes with operation of the machine, wherein the machine account operates based on the transaction profile for allowable transactions for the machine;
b) analyzing the transaction request at the machine entity platform using the machine credentials and the transaction profile, to determine if the transaction request is authentic and if the transaction is an allowable-type of transaction for the machine, wherein the transaction request is declined if the transaction profile is violated thereby preventing unauthorized transactions;
c) authorizing, by the machine entity platform, when the transaction request is authentic and when the transaction is the allowable-type of transaction for the machine, the transaction request;
d) sending to at least one of the machine and a device in communication with the machine, when the transaction request is authorized, an allow response in response to the transaction request to allow the transaction to be completed;
e) declining, when the transaction request is not authentic or when the transaction is not the allowable-type of transaction for the machine, the transaction request;
f) sending to at least one of the machine and the device in communication with the machine, when the transaction request is declined, a decline response in response to the transaction request to prevent the transaction from completing;
g) storing, at a database on communication with the machine entity platform, either the allow response or the decline response; and
h) updating the profile based on either the allow response or the decline response to generate an updated profile, wherein the updated profile is used by the machine entity platform for a next transaction and the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine, such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction.
(Bold emphasis added on the additional element(s))
Here, claim 1 under the broadest reasonable interpretation recites a method that either authorizes a transaction request and sends an allow response when the transaction request is authentic and when the transaction of the transaction request is an allowable-type transaction, i.e., steps c)-d), or declining the transaction request and sends a decline response when the transaction request is not authentic or the transaction is not an allowable-type of transaction, i.e., steps e)-f) and storing (ledgering) either the allow or decline response, i.e., g). The claim achieves this by step a) receiving a transaction request and step b) analyzing the transaction request using a machine credentials and a transaction profile to determine whether the transaction request is authentic (i.e., checking the credentials) and if the transaction is an allowable-type (i.e., checking the profile that contains allowable type of transactions). The claim further recites step of updating the profile based on either the allow response or the decline response to update the profile. As such, the claim recites a certain method of organizing human activity, i.e., mitigating risk of a transaction and/or economic practice such as in authorizing transaction. Hence, the claim recites abstract idea. The examiner further submits that the analyzing step, i.e., in determining whether the transaction of the transaction request is authentic by using credentials and whether the transaction is an allowed type by using transaction profile is a mental activities.
The claim has been amended to recite concept of generating of a continuous machine identifier with intention of authentication in a next transaction. However, the concept also recites a certain method of organizing human activities, i.e., mitigating risk of a transaction and/or economic practice such as in authorizing transaction.
Claim 12 is a corresponding non-transitory readable storage medium for storing instructions for causing a system to perform significantly similar functions as recited in claim 1. Hence, claim 12 also recites abstract idea.
Under the Step 2A (prong 2), this judicial exception is not integrated into a practical application. Specifically, the additional elements in the claim(s), machine entity platform, machine, a device, database, communication, a non-transitory computer readable storage medium, one or more processor of a system, and system, etc., amount to no more than mere instructions to implement an abstract idea on a computer or merely uses a computer system as a tool to perform an abstract idea.
These limitation do not represent: Improvements to the functioning of a computer(s) (one or more processor and/or the system or any suggested machine that is responsible for performing the recited step(s)) (i.e., one or more processor of a system having a machine entity platform or the machine entity platform), or to any other technology or technical field - see MPEP 2106.05(a). Rather, the additional elements individually and/or in combination amounts to no more than mere instructions to implement an abstract idea on a computer system, or merely uses a computer as a tool to perform an abstract idea.
Accordingly, the claim as a whole, looking at the additional elements individually and in combination, does not integrate the judicial exception into a practical application using the considerations set forth in the 2019 PEG.
Under Step 2B, examiners should evaluate additional elements individually and in combination to determine whether they provide an inventive concept (i.e. whether the additional elements amount to significantly more than the exception itself). Here, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Specifically, the claims as a whole, taken individually and in combination, do not provide an inventive concept. As explained above with respect to the integration of the abstract idea into a practical application, the addition elements used to perform the claimed judicial exception amount to no more than mere instructions to implement an abstract idea as identified above on a computer system or merely uses a computer as a tool to perform an abstract idea. Looking at the limitations as a combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the computer of [0088] in the specification. In other words, the claim as a whole does not improve the computer component(s) or any technological process rather the claim as a whole describes mere instructions to implement an abstract idea on a computer or merely uses a computer system (see [0088]) as a tool to perform an abstract idea.
Dependent claims 2-11 further describe the abstract idea without additional elements.
Claim 13 recites that the continuous machine identifier is generated using a hash of sensor information of the machine. The concept of hash, however, is a mathematical concept, hence further recites 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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-7 and 12-13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication No. 20200058176 (“Pratz”) in view of US Patent Publication No. 20160226901 (“Baikalov”) .
Per claims 1 and 12, Pratz discloses a method comprising:
receiving a transaction request at a machine entity platform in communication with a machine, wherein the transaction request is compared to a transaction profile for a machine, for a transaction associated with a machine, the machine having a profile and machine account, wherein the machine account is created using machine credentials, which machine credentials are generated using seed identification data and changing identification data that is specific to the machine and the changing identification data that changes with operation of the machine, wherein the machine account operates based on the transaction profile for allowable transaction for the machine (see Fig. 7- Fig. 9; abstract, using authentication values generated data provided by the hardware appliances such as sensor data, log data, location data; ¶0026, hardware authentication network architecture for management of authentication and processing of hardware appliance-based requests. Hardware appliances interact with the machine entity platform for different service tasks; ¶0028, generating and updating a fingerprint access data for each of the plurality of hardware appliances which are used to permit or deny interaction requests, i.e., service requests … preconfigured threshold; ¶0029, smart contract that specifies rules; ¶0037, vehicle machine account; ¶0043, conditions set in the smart contract … machine account; ¶0047, request data; ¶0048, dynamic fingerprint value)(applicant is reminded that the recitation of the machine having a profile and a machine account, wherein the machine account is created using machine credentials, which machine credentials are generated using seed identification data and changing identification data that is specific to the machine and the changing identification data that changes with operation of the machine, wherein the machine account operates based on the transaction profile for allowable transactions for the machine does not move to distinguish over prior art as the description does not affect the step of receiving a transaction request);
analyzing the transaction request at the machine entity platform using the machine credentials and the transaction profile (i.e., rule), to determine if the transaction request is authentic and if the transaction is an allowable-type of transaction for the machine wherein the transaction request is declined if the transaction profile is violated thereby preventing unauthorized transaction (see ¶0028, preconfigured threshold; ¶0037, evaluate a request and grant or reject the request based on fingerprint access and smart contract; ¶0039, complies with smart contract and identify what task is being requested as well as authentication parameters provided to determine whether the request should be rejected or approved; ¶0041, if the request conforms with the smart contract, the request is approved; ¶0043; ¶0043, smart contract less than $50; ¶0061, is granted or rejected based on the type of request being generated, i.e., transaction amount for the request, and the fingerprint access value functions to authenticate the vehicle; ¶0063)(the applicant is reminded that thereby … is an intended result);
authorizing by the machine entity platform, when the transaction request is authentic and when the transaction is the allowable-type of transaction for the machine, the transaction request (see ¶0037, evaluate a request and grant or reject the request based on fingerprint access and smart contract; ¶0039, complies with smart contract and identify what task is being requested as well as authentication parameters provided to determine whether the request should be rejected or approved; ¶0041, if the request conforms with the smart contract, the request is approved; ¶0043; ¶0048, approve or reject; ¶0106, approve or reject);
sending to at least one of the machine and a device in communication with the machine, when the transaction request is authorized, an allowed response in response to the transaction request to allow the transaction to be completed (see ¶0041, the endorsed proposal is submitted; ¶0042; ¶0043);
declining, when the transaction request is not authentic or when the transaction is not the allowable-type of transaction, the transaction request (see ¶0046, request is rejected as failing to conform with the terms; ¶0047; ¶0048, approve or reject; ¶0049, reject scenario; ¶0085, reject any transaction; ¶0106, approve or reject);
sending to at least one of the machine and the device in communication with the machine, when the transaction request is declined, a decline response in response to the transaction request to prevent the transaction from completing (see ¶0038, recordation; ¶0049).
Pratz further teaches a non-transitory computer readable storage medium for storing instruction for execution by one or more processor for causing a system to perform function(s) (see Fig. 14; ¶0126; claim 9).
Pratz does not particularly teach storing at a database on communication with the machine entity platfor, either the response or the decline response. However, as Pratz generally teaches storing of information (see ¶0033, information is stored in a database; ¶0034, storing of information on blockchain) and teaches a response and a decline response, it would have been obvious to store at least one of the response or the decline response in any one of the storage techniques as described in Pratz for the purpose of record keeping.
Pratz does not specifically teach updating the profile based on either the response or the decline response to generate an updated profile, wherein the updated profile is used by the machine entity platform for a next transaction.
Baikalov, however, teaches updating the profile based on the response or the decline response, i.e., current data, for the purpose of use for next transaction (see ¶0013, real time updates to profile; ¶0017, the profile us used for anomaly detection processes; ¶0018, continuously updates profile using current data).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique as taught by Baikalov for the purpose of improving anomaly detection (see Baikalov: ¶0018).
Pratz/Baikalov does not particularly teach the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction.
Meganck, however, teaches wherein the machine entity platform (i.e., control center) generates a continuous machine identifier (i.e., dynamic passcode) that is trusted to uniquely identify the machine (i.e., recipient user) and sent to the machine (user) such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction (¶0022, provide the user with dynamic passcode which is used for authentication).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim the technique of dynamical passcode generation and authentication as taught by Meganck to Pratz/Baikalov as the merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The applicant is reminded that “wherein the transaction request is compared to a transaction profile for a machine, for a transaction associated with the machine, the machine having a profile and a machine account, wherein the machine account is created using machine credentials, which machine credentials are generated using seed identification data and changing identification data that is specific to the machine and the changing identification data that changes with operation of the machine, wherein the machine account operates based on the transaction profile for allowable transactions for the machine” do not move to distinguish over prior art as the descriptions do not affect the positively recited step(s) in the method claim, claim 1, nor do these descriptions affect the recited system’s function(s) in claim 12.
Similarly, the claimed expression of “wherein the updated profile is used for a next transaction and the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine, such the machine provides the continuous machine identifier for authentication of the machine in a next transaction” does not distinguish over prior art as the description does not affect the positively recited step of “updating the profile based on either the allow response or the decline response to generate an updated profile”.
As per claim 2, the combination of Pratz and Baikalov further teaches wherein the machine is associated with a set of transaction control rules that identify allowable-type of transaction for the machine (see Pratz: ¶0028; ¶0041, if the request conforms with the smartcontract, the request is approved; ¶0043; ¶0047; ¶0048, approve or reject; ¶0049; ¶0106, approve or reject).
As per claims 3 and 4, the combination of Pratz and Baikalov further teaches wherein the transaction profile include product transactions and service transactions needed by the machine, for any one of which there is a threshold interval between transactions, wherein the machine is a vehicle and the defined threshold interval is at least one of: a duration of time, a distance travelled, transaction amount, transaction frequency, merchant spending limit, daily transaction spending limit, sensor reading indicating a service need (see Pratz: ¶0038, refueling; ¶0043, toll service; ¶0049; ¶0061; ¶0074; ¶0075; ¶0079-¶0081; ¶0091, threshold).
Furthermore, the description of what the set of transaction rule includes is non-functional descriptive material as the term “include” is open-ended expression.
As per claim 5, the combination of Pratz and Baikalov further teaches wherein the transaction profile include at least one of: merchant category, transaction dollar amount limit based on merchant category, total dollar spend by merchant category in a given time period, and total dollar spend limits in a given time period (see Pratz: ¶0028; ¶0041, if the request conforms with the smartcontract, the request is approved; ¶0043; ¶0047; ¶0048, approve or reject; ¶0049; ¶0090, insurance debit amount based on miles recently travelled; ¶0106, approve or reject). Furthermore, the description of what the set of transaction rules include do not move to distinguish over prior art as the expression “include” is an open-ended expression and there is no indication that any of at least one of: i.e., merchant category, transaction dollar amount limit based on merchant category, total dollar spend by merchant category in a given time period, and total dollar spend limits in a given time period, and the claim does not require the particular description(s) is used in the recited step(s).
As per claims 6 and 7, the combination of Pratz and Baikalov further teaches wherein the machine is a vehicle and the vehicle provides identification information (see Pratz: ¶0002, vehicle; ¶0028) and the profile is augmented with the identification information to generate a dynamic profile (see Baikalov: ¶0018) wherein the identification information includes at least one of: odometer reading, location information, at least one vehicle sensor reading, device connectivity, and vehicle service history data (see Pratz: ¶0027; ¶0031).
Furthermore, the description of what is included in the identification information is non-functional descriptive material as the description does not affect the positively step(s) as the “include” is merely open-ended expression and the claim does not require the particular description(s) is used in the recited step(s).
Per claim 13, the combination of Pratz and Baikalov does not particularly teach wherein the continuous machine identifier is generated using a hash of sensor information of the machine. The claimed expression, however, does not further move to distinguish over prior art as the description does not affect the positively recited step of “updating the profile based on either the allow response or the decline response to generate an updated profile”.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Pratz” and “Baikalov” as applied to claim 8 above, and further in view of US Patent Publication No. 20150254719 (“Barfield”).
Per claim 9, while the combination of Pratz and Baikalov discloses wherein the machine is a vehicle (see Pratz: ¶0002, vehicle; ¶0028), the combination of Pratz and Baikalov does not specifically teach wherein the model predicts a possible transaction request for a future transaction based on the historical identification data from the vehicle.
Barfield, however, teaches wherein the model predicts a possible transaction request for a future transaction based on the historical identification data from the vehicle (see ¶0001, telematic; abstract, predicting that a given vehicle will engage in a transaction; ¶0018).
It would have been obvious to one of ordinary skill in the art to include the technique of modeling that predicts a possible transaction request for a future transaction as taught by Barfield to the combination of Pratz and Baikalov for potential advertising opportunities (see Barfield: ¶0018).
Claim(s) 10 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Pratz”, “Baikalov”, and “Barfield” as applied to claim 9 above, and further in view of US Patent No. 10846702 (“Farivar”).
As per claim 10, the combination of Pratz, Baikalov, and Barfield does not specifically teach that the model compares an incoming transaction request, for an incoming transaction, to the possible transaction request in order to approve the incoming transaction request and allowing the incoming transaction to be completed.
Farivar, however, teaches a model that compares an incoming transaction request, for an incoming transaction, to the possible transaction request in order to approve the incoming transaction request and allowing the incoming transaction to be completed (see col. 2, lines 39-53, perform predictive modeling on transactions and processing of ongoing transaction based on the modeling).
It would have been obvious to one of ordinary still in the art to include in the transaction approval system of the combination of Pratz, Baikalov, and Barfield the old and well known technique of comparing transaction request for incoming transaction, i.e., current transaction score, to expected transaction(s) score in order to approve the current transaction and allowing the incoming transaction to be completed since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 11, the combination of Pratz, Baikalov, Barfield, and Farivar further teaches updating the historical identification data for the vehicle upon confirmation, post-transaction, that the transaction was completed and associated goods or services were received (see Pratz: ¶0096).
Response to the Argument(s)
112 Rejections
The claims are rejected under 112 as described above in the 112 sections.
101 Rejections
The applicant asserts that a machine entity platform that analyzes the transaction and the machine entity platform that generates a continuous machine identifier that is trusted to uniquely identify the machine and set to the machine such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction significantly improves the field of transaction authentication between a machine and a machine entity platform and thus 101 rejection is moot.
In response, the examiner submits that analyzing transaction and authorizing transaction based on identifier that changes is an abstract idea, i.e., fundamental economic principle of authorizing transaction based on rules and authentication. The additional element of machine and machine entity platform merely serves as generic computer components to implement the abstract idea or apply it. The limitations do not improve upon the functioning of the machine entity platform that performs the positively recited step(s). Furthermore, the claim is replete with intended use of the updated profile and the continuous machine identifier that do not further limit the scope of the claim. Even when the intended use is considered, the claim recites abstract idea as described above and does not provide improvement on the machine entity platform performing the recited step(s) nor the machine entity platform of claim 12.
103 Rejection
The action has been updated to address the amendment. The applicant asserts that none of the references of record, alone or in combination, teach or suggest the feature of a system that updates “the profile based on either the allow response or the decline response to generate an updated profile, wherein the updated profile is used by the machine entity platform for a next transaction and the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine, such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction”. The examiner respectfully disagrees.
Pratz does not specifically teach updating the profile based on either the response or the decline response to generate an updated profile, wherein the updated profile is used by the machine entity platform for a next transaction.
Baikalov, however, teaches updating the profile based on the response or the decline response, i.e., current data, for the purpose of use for next transaction (see ¶0013, real time updates to profile; ¶0017, the profile us used for anomaly detection processes; ¶0018, continuously updates profile using current data).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim to include the technique as taught by Baikalov for the purpose of improving anomaly detection (see Baikalov: ¶0018).
Pratz/Baikalov does not particularly teach the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction.
Meganck, however, teaches wherein the machine entity platform (i.e., control center) generates a continuous machine identifier (i.e., dynamic passcode) that is trusted to uniquely identify the machine (i.e., recipient user) and sent to the machine (user) such that the machine provides the continuous machine identifier for authentication of the machine in a next transaction (¶0022, provide the user with dynamic passcode which is used for authentication).
It would have been obvious to one of ordinary skill in the art before the effective filing of instant claim the technique of dynamical passcode generation and authentication as taught by Meganck to Pratz/Baikalov as the merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Furthermore, the claimed expression of “wherein the updated profile is used for a next transaction and the machine entity platform generates a continuous machine identifier that is trusted to uniquely identify the machine and sent to the machine, such the machine provides the continuous machine identifier for authentication of the machine in a next transaction” does not distinguish over prior art as the description does not affect the positively recited step of “updating the profile based on either the allow response or the decline response to generate an updated profile”.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US Patent Publication No. 20200244652 discloses a method and system for creating an authentication stream that uses a machine identifier of the machine, a job identifier of a job, or an environmental variable secret associated with the machinel;
US Patent Publication No. 20110066493 discloses method of using behavior in approving of transaction, particularly generating a set of one or more predicted transactions that is expected and comparing the incoming transactions to the set of predicted transaction;
US Patent Publication No. 20190378220 discloses a system and method for automated remote payments between a vehicle and a refueling station. A transaction account is mapped to a vehicle identifying data in performing of the payment;
US Patent No. 10,846,702 discloses a system and methods that utilizes transaction history in performing predictive modeling to determine a predicted transaction parameter for future transaction. This predicted parameter is compared to ongoing transaction for risk analysis;
US Patent Publication No. 20200344824 discloses a system and method for utilizing data and computational information from on-vehicle and off-vehicle sources for monitoring;
US Patent Publication No. 20220215378 discloses an artificial intelligence processing systems and method for processing/facilitating payment authorization for payment transaction initiated from on-board device such as vehicle system including authentication utilizing multisensory data captured using sensors positioned in the vehicle. A neural network models are trained based on historical multisensory data in deriving authentication score.
The combination of prior art does not teach the particular combination of claim 8.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN S KIM whose telephone number is (571)270-5287. The examiner can normally be reached Monday -Friday: 7:00 - 3: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, Patrick McAtee can be reached on 571-272-7575. 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.
/STEVEN S KIM/Primary Examiner, Art Unit 3698
Prosecution Insights