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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1 and 5-15 is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-8 of U.S. Patent No. US-12229234-B2 (hereinafter “Pat ‘234”). Although the claims at issue are not identical, they are not patentably distinct from each other.
Per claim 1 (independent):
Claim 1 of Pat ‘234 anticipates all of the limitations in claim 1 of the instant application.
Claims / App Language
Pat ‘234 Language
1
A data management system for securely managing data transactions, the system comprising a computing system which incorporates:
(i) a public key distribution system which is configured to distribute a public key of a public/private key pair for each respective party using the system;
(ii) a trusted storage system which is in communication with the public key distribution system, the trusted storage system being configured to store a record for each respective party using the system, each record comprising a unique identifier and a public key for a respective party using the system; and
(iii) a verification system which is in communication with the public key distribution system and the trusted storage system, the verification system being configured to check the identity of a party seeking to participate in a transaction involving an exchange of data, wherein:
(a) if the verification system is not able to verify the identity of the party seeking to participate in the transaction, the verification system prevents the transaction from being carried out, and
(b) if the verification system is able to verify the identity of the party seeking to participate in the transaction, the verification system permits the transaction to be carried out and the trusted storage system stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction, and wherein the verification system is configured to check the identity of a party based on the result of a biometric check.
1
A data management system for securely managing data transactions, the system comprising a computing system which incorporates:
(i) a public key distribution system which is configured to distribute a public key of a public/private key pair for each respective party using the system;
(ii) a trusted storage system which is in communication with the public key distribution system, the trusted storage system being configured to store a record for each respective party using the system, each record comprising a unique identifier and a public key for a respective party using the system; and
(iii) a verification system which is in communication with the public key distribution system and the trusted storage system, the verification system being configured to check the identity of a party seeking to participate in a transaction involving an exchange of data, wherein:
(a) if the verification system is not able to verify the identity of the party seeking to participate in the transaction, the verification system prevents the transaction from being carried out, and
(b) if the verification system is able to verify the identity of the party seeking to participate in the transaction, the verification system permits the transaction to be carried out and the trusted storage system stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction, and wherein the verification system is configured to check the identity of a party based on the result of a biometric check:
further wherein the verification system is configured to calculate a trust score which is indicative of a level of trust between a first party and a second party based on a public key of the second party,
...
Per claim 5 (dependent on claim 1):
Claim 1 of Pat ‘234 anticipates all of the limitations in claim 5 of the instant application.
Per claim 6 (dependent on claim 1):
Claim 2 of Pat ‘234 anticipates all of the limitations in claim 6 of the instant application.
Per claim 7 (dependent on claim 6):
Claim 3 of Pat ‘234 anticipates all of the limitations in claim 7 of the instant application.
Per claim 8 (dependent on claim 6):
Claim 4 of Pat ‘234 anticipates all of the limitations in claim 8 of the instant application.
Per claim 9 (dependent on claim 6):
Claim 5 of Pat ‘234 anticipates all of the limitations in claim 9 of the instant application.
Per claim 10 (independent):
Claim 6 of Pat ‘234 anticipates all of the limitations in claim 10 of the instant application.
Claims / App Language
Pat ‘234 Language
10
A data management method for securely managing data transactions, the method comprising:
(i) distributing, using a public key distribution system, a public key of a public/private key pair for each respective party involved in a transaction;
(ii) storing a unique identifier and a public key for each respective party in a trusted storage system; and
(iii) checking the identity of a party seeking to participating in a transaction involving an exchange of data, wherein: if the identity of the party seeking to participate in the transaction cannot be verified, the method prevents the transaction from being carried out; but if the identity of the party seeking to participate in the transaction can be verified, the method permits the transaction to be carried out, and the method stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction
6
A data management method for securely managing data transactions, the method comprising:
(i) distributing, using a public key distribution system, a public key of a public/private key pair for each respective party involved in a transaction;
(ii) storing a unique identifier and a public key for each respective party in a trusted storage system; and
checking the identity of a party seeking to participating in a transaction involving an exchange of data, wherein: if the identity of the party seeking to participate in the transaction cannot be verified, the method prevents the transaction from being carried out; but if the identity of the party seeking to participate in the transaction can be verified, the method permits the transaction to be carried out, and the method stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction,
wherein the method further comprises: providing a trusted agent which is identified by a trusted agent identifier, the trusted agent identifier being pseudonymous or anonymous with respect to a party seeking to participate in a transaction;
...
Per claim 11 (dependent on claim 10):
Claim 6 of Pat ‘234 anticipates all of the limitations in claim 11 of the instant application.
Per claim 12 (dependent on claim 11):
Claim 6 of Pat ‘234 anticipates all of the limitations in claim 12 of the instant application.
Per claim 13 (dependent on claim 12):
Claim 6 of Pat ‘234 anticipates all of the limitations in claim 13 of the instant application.
Per claim 14 (dependent on claim 12):
Claim 7 of Pat ‘234 anticipates all of the limitations in claim 14 of the instant application.
Per claim 15 (dependent on claim 12):
Claim 8 of Pat ‘234 anticipates all of the limitations in claim 15 of the instant application.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 10 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by CHU et al., US- 20210176075-A1 (hereinafter “CHU ‘075”).
Per claim 10 (independent):
CHU ‘075 discloses: A data management method for securely managing data transactions, the method comprising:
(i) distributing, using a public key distribution system, a public key of a public/private key pair for each respective party involved in a transaction
(FIG. 1, [0036], a "blockchain" may mean and/or correspond to a distributed ledger technology that allows nodes in a network to record and manage a ledger, e.g. a common ledger, recording transaction information (securely managing data transactions); [0042], Based on a blockchain, a cryptographic communication system 10 may verify electronic devices 100, 200, and 300 (each respective party), and may verify transactions between the electronic devices 100, 200, and 300; [0044], The first electronic device 100 may execute a blockchain wallet. The first electronic device 100 may generate a private key SK1, a public key PK1 (a public key of a public/private key pair), a transaction 110, and a certificate 120 ... The public key PK1 may be known to/accessible by all the components/electronic devices 200, 300, and 410 to 440 in the cryptographic communication system 10 (distributing the public key, using a public key distribution system, via the blockchain network 400); [0048], The first electronic device 100 may output the transaction 110 and the certificate 120 to the blockchain network 400.);
(ii) storing a unique identifier and a public key for each respective party in a trusted storage system (FIG. 1, [0044], The public key PK1 may be known to/accessible by all the components/electronic devices 200, 300, and 410 to 440 in the cryptographic communication system 10; [0048], The first electronic device 100 may output the transaction 110 and the certificate 120 to the blockchain network 400 (a trusted storage system); [0047], The certificate 120 (each record) may include at least the following information: an ID (a unique identifier) of the first electronic device 100 and the public key PK1 (a public key) of the first electronic device 100 (for each respective party).);
(iii) checking the identity of a party seeking to participating in a transaction involving an exchange of data (FIG. 1, [0042], Based on a blockchain, a cryptographic communication system 10 may verify electronic devices 100, 200, and 300, and may verify transactions between the electronic devices 100, 200, and 300 – check the identity of a party seeking to participate in a transaction involving an exchange of data),
wherein: if the identity of the party seeking to participate in the transaction cannot be verified, the method prevents the transaction from being carried out; but
but if the identity of the party seeking to participate in the transaction can be verified, the method permits the transaction to be carried out, and
the method stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction
(FIG. 6, [0079], The first electronic device 100 of FIG. 1 may output the transaction 110a of FIG. 4 and the certificate 120a of FIG. 5 in a case of intending to register the first electronic device 100's own identity information at a distributed ledger (the blockchain network 400 of FIG. 1; with which a verification system communicates the transactions and the public keys ); [0080], the transaction 110a_1 and the certificate 120a_1 may be identical to the transaction 110a and the certificate 120a; [0081], The verification operation associated with the transaction 110a_1 and the certificate 120a_1 may include an operation of determining whether the transaction 110a_1 and the certificate 120a_1 are generated from the first electronic device 100, and an operation of determining whether information of the transaction 110a_1 and information of the certificate 120a_1 coincide, that is, the transaction 110a_1 and the certificate 120a_1 is compared with the transaction 110a and the certificate 120a respectively for determining whether they coincide; [0082], When the verification succeeds (if the identity of the party seeking to participate in the transaction can be verified), the node 410 may generate a block including the transaction 110a_1 – which means permitting the transaction to be carried out. When the verification fails (if the identity of the party seeking to participate in the transaction cannot be verified), the node 410 may revoke (that is, preventing the transaction from being carried out) the transaction 110a_1 and the certificate 120a_1 received from the first electronic device 100 ... "verification success" may mean ... coinciding ... "verification fail" may mean ... not coinciding; Note that the transaction (a record of the transaction) and the certificate (a record of the party) should be stored in the blockchain network 400 for future comparisons).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, 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-3 is/are rejected under 35 U.S.C. 103 as being unpatentable over CHU ‘075 in view of Lindemann, US-20190164156-A1 (hereinafter “Lindemann ‘156”).
Per claim 1 (independent):
CHU ‘075 discloses: A data management system for securely managing data transactions, the system comprising a computing system which incorporates:
(i) a public key distribution system which is configured to distribute a public key of a public/private key pair for each respective party using the system
(FIG. 1, [0036], a "blockchain" may mean and/or correspond to a distributed ledger technology that allows nodes in a network to record and manage a ledger, e.g. a common ledger, recording transaction information (securely managing data transactions); [0042], Based on a blockchain, a cryptographic communication system 10 (a data management system) may verify electronic devices 100, 200, and 300 (each respective party), and may verify transactions between the electronic devices 100, 200, and 300; [0044], The first electronic device 100 may execute a blockchain wallet. The first electronic device 100 may generate a private key SK1, a public key PK1 (a public key of a public/private key pair), a transaction 110, and a certificate 120 ... The public key PK1 may be known to/accessible by all the components/electronic devices 200, 300, and 410 to 440 in the cryptographic communication system 10 (distributing the public key using the system via the blockchain network 400); [0048], The first electronic device 100 may output the transaction 110 and the certificate 120 to the blockchain network 400.);
(ii) a trusted storage system which is in communication with the public key distribution system, the trusted storage system being configured to store a record for each respective party using the system, each record comprising a unique identifier and a public key for a respective party using the system (FIG. 1, [0044], The public key PK1 may be known to/accessible by all the components/electronic devices 200, 300, and 410 to 440 in the cryptographic communication system 10; [0048], The first electronic device 100 may output the transaction 110 and the certificate 120 (storing a record for each respective party using the system) to the blockchain network 400 (a trusted storage system); [0047], The certificate 120 (each record) may include at least the following information: an ID (a unique identifier) of the first electronic device 100 and the public key PK1 (a public key) of the first electronic device 100.);
(iii) a verification system which is in communication with the public key distribution system and the trusted storage system, the verification system being configured to check the identity of a party seeking to participate in a transaction involving an exchange of data (FIG. 1, [0042], Based on a blockchain, a cryptographic communication system 10 may verify electronic devices 100, 200, and 300, and may verify transactions between the electronic devices 100, 200, and 300 – check the identity of a party seeking to participate in a transaction involving an exchange of data.), wherein:
(a) if the verification system is not able to verify the identity of the party seeking to participate in the transaction, the verification system prevents the transaction from being carried out, and
(b) if the verification system is able to verify the identity of the party seeking to participate in the transaction, the verification system permits the transaction to be carried out and
the trusted storage system stores a transaction record comprising a record of the transaction and a record of the party participating in the transaction
(FIG. 6, [0079], The first electronic device 100 of FIG. 1 may output the transaction 110a of FIG. 4 and the certificate 120a of FIG. 5 in a case of intending to register the first electronic device 100's own identity information at a distributed ledger (the blockchain network 400 of FIG. 1; with which a verification system communicates the transactions and the public keys ); [0080], the transaction 110a_1 and the certificate 120a_1 may be identical to the transaction 110a and the certificate 120a;[0081], The verification operation associated with the transaction 110a_1 and the certificate 120a_1 may include an operation of determining whether the transaction 110a_1 and the certificate 120a_1 are generated from the first electronic device 100, and an operation of determining whether information of the transaction 110a_1 and information of the certificate 120a_1 coincide, that is, the transaction 110a_1 and the certificate 120a_1 is compared with the transaction 110a and the certificate 120a respectively for determining whether they coincide; [0082], When the verification succeeds (if the verification system is able to verify the identity of the party), the node 410 may generate a block including the transaction 110a_1 – which means permitting the transaction to be carried out. When the verification fails (if the verification system is not able to verify the identity of the party), the node 410 may revoke (that is, preventing the transaction from being carried out) the transaction 110a_1 and the certificate 120a_1 received from the first electronic device 100 ... "verification success" may mean ... coinciding ... "verification fail" may mean ... not coinciding; Note that the transaction (a record of the transaction) and the certificate (a record of the party) should be stored in the blockchain network 400 for future comparisons.).
CHU ‘075 does not disclose but Lindemann ‘156 discloses: wherein the verification system is configured to check the identity of a party based on the result of a biometric check (FIG. 2, [0101], Behavioral or other techniques may be used to continuously measure an assurance level which indicates the current assurance that an authorized user is in possession of the device; [0102], For example, the biometric gait of the user (the result of a biometric check) may be measured using an accelerometer or other type of sensor in combination with software and/or hardware designed to generate a gait "fingerprint" from the user's normal walking pattern; [0106], a non-intrusive privacy-preserving authenticator (NIPPA) 210 including an assurance calculator 212 for determining the current assurance level (check the identity of a party) based on input from non-intrusive authentication mechanisms 230 ( e.g., location, gait measurements, etc – e.g., the biometric gait) and one or more explicit user authentication devices 220-221.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 with the calculation of an assurance level based on the non-intrusive authentication mechanism including the biometric gait in order to authenticate a user as taught by Lindemann ‘156 because it would allow for the non-intrusive use of biometric information (i.e., without requiring any explicit user authentication) to verify a user’s identity while also ensuring accurate identification [0101]. Additionally, Lindemann ‘156 is analogous to the claimed invention because it teaches an architecture for providing non-intrusive privacy-protecting authentication in terms of making transactions with the relying party [FIG. 2].
Per claim 2 (dependent on claim 1):
CHU ‘075 in view of Lindemann ‘156 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
CHU ‘075 does not disclose but Lindemann ‘156 discloses: The system of claim 1, wherein the computing system comprises: a liveness score generator which is configured to generate a liveness score for a party based on at least one of: behavioural data, biometric data or behavioural biometric data generated following the use of the computing system by the party, or the length of time since the party successfully accessed a biometrically gated system of the computing system or the real time web of trust graph representing the parties to the system ([0102], Following the legitimate user state, the assurance level (a liveness score for a party) may be measured based on a combination of the elapsed time since explicit user authentication and other variables which indicate that the authorized user is in possession of the device (e.g., based on non-intrusive input detected from device sensors). For example, the biometric gait (behavioural data, biometric data or behavioural biometric data) of the user may be measured using an accelerometer or other type of sensor in combination with software and/or hardware designed to generate a gait "fingerprint" from the user's normal walking pattern.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 with the calculation of an assurance level based on the non-intrusive authentication mechanism including the biometric gait in order to authenticate a user as taught by Lindemann ‘156 because it would allow for the non-intrusive use of biometric information (i.e., without requiring any explicit user authentication) to verify a user’s identity while also ensuring accurate identification [0101].
Per claim 3 (dependent on claim 1):
CHU ‘075 in view of Lindemann ‘156 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
CHU ‘075 discloses: The system of claim 1, wherein the trusted storage system is a blockchain or a distributed ledger, or other data storage medium providing the properties of integrity, authenticity and optionally non-repudiation of data (FIG. 1, [0044], The public key PK1 may be known to/accessible by all the components/electronic devices 200, 300, and 410 to 440 in the cryptographic communication system 10; [0048], The first electronic device 100 may output the transaction 110 and the certificate 120 to the blockchain network 400 (a blockchain)).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over CHU ‘075 in view of Lindemann ‘156 and Pogorelik et al., US-20190114626-A1 (hereinafter “Pogorelik ‘626”).
Per claim 4 (dependent on claim 1):
CHU ‘075 in view of Lindemann ‘156 discloses the elements detailed in the rejection of claim 1 above, incorporated herein by reference.
CHU ‘075 in view of Lindemann ‘156 does not disclose but Pogorelik ‘626 discloses: The system of claim 1, wherein the system further comprises:
a trusted agent which is in communication with the verification system, the trusted agent being identified by a trusted agent identifier which is pseudonymous or anonymous with respect to a party using the system or a computing system of the system, wherein the trusted agent is configured to provide an output to the verification system in relation to a transaction on behalf of a party using the system or a computing system of the system
(FIG. 8 and 9A, [0059], the prepare direct transaction approval flow 900A, the system 800 will validate the available amount of money (for a transaction) in the shadow wallet 808 and create a signed message to the peer wallet 810; [0060], The flow begins with the client 604 (a party using the system) initiating a payment to the client 610 by specifying that the client will make a payment in the original wallet (902). The original wallet 806 will communicate this payment to the API proxy 804 (904) (a trusted agent), where a trusted agent identifier restricts direct access by providing a pseudonymous identifier, e.g., an API function, and the API proxy will communicate a pay message to the shadow wallet 808 inside the TEE (906); [0061], Once the pay request is made, the shadow wallet 808 (the verification system) inquires (by receiving an output from the API proxy 804; See FIG. 8) whether there is enough money for the payment (908) (in relation to a transaction on behalf of a party using the system) ... A trusted direct transaction between the original wallet 806 and the peer wallet 810 is commenced (914); FIG. 10, [0075], the API proxy 804 of the trusted coin wallet framework 802 (FIG. 8) ... The message processor 1002 (of the API proxy 804) processes the various messages (identified by a trusted agent identifier) sent by the API proxy 804 to the various entities of the system 800, including the blockchain infrastructure 602, the original wallet 806, the trusted shadow wallet 808, and the peer trusted wallet 810.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 in view of Lindemann ‘156 with the preparation of a trusted direct transaction approval between peers based on the trusted coinwallet framework including the API proxy and the trusted shadow wallet as taught by Pogorelik ‘626 because it would reduce blockchain transaction delay caused by fake money in transactions [0019][0035]. Additionally, Pogorelik ‘626 is analogous to the claimed invention because it teaches a system for reducing blockchain transaction delay, including the trusted coinwallet framework [0049].
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over CHU ‘075 in view of Pogorelik ‘626 and Agrawal et al., US-20210279731 -A1 (hereinafter “Agrawal ‘731”).
Per claim 11 (dependent on claim 10):
CHU ‘075 discloses the elements detailed in the rejection of claim 10 above, incorporated herein by reference.
CHU ‘075 does not disclose but but Pogorelik ‘626 discloses: The method of claim 10, wherein the method further comprises: providing a trusted agent which is identified by a trusted agent identifier, the trusted agent identifier being pseudonymous or anonymous with respect to a party seeking to participate in a transaction;
and wherein the method further comprises:
(i) providing, on behalf of the party, an output from the trusted agent in relation to the transaction
(FIG. 8 and 9A, [0059], the prepare direct transaction approval flow 900A, the system 800 will validate the available amount of money (for a transaction) in the shadow wallet 808 and create a signed message to the peer wallet 810; [0060], The flow begins with the client 604 (a party seeking to participate in a transaction) initiating a payment to the client 610 by specifying that the client will make a payment in the original wallet (902). The original wallet 806 will communicate this payment to the API proxy 804 (904) (a trusted agent), where a trusted agent identifier restricts direct access by providing a pseudonymous identifier, e.g., an API function, and the API proxy will communicate a pay message to the shadow wallet 808 inside the TEE (906); [0061], Once the pay request is made, the shadow wallet 808 (the verification system) inquires (by receiving an output from the API proxy 804; See FIG. 8) whether there is enough money for the payment (908) (in relation to the transaction) ... A trusted direct transaction between the original wallet 806 and the peer wallet 810 is commenced (914); FIG. 10, [0075], the API proxy 804 of the trusted coin wallet framework 802 (FIG. 8) ... The message processor 1002 (of the API proxy 804) processes the various messages (identified by a trusted agent identifier) sent by the API proxy 804 to the various entities of the system 800, including the blockchain infrastructure 602, the original wallet 806, the trusted shadow wallet 808, and the peer trusted wallet 810.).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 with the preparation of a trusted direct transaction approval between peers based on the trusted coinwallet framework including the API proxy and the trusted shadow wallet as taught by Pogorelik ‘626 because it would reduce blockchain transaction delay caused by fake money in transactions [0019][0035].
CHU ‘075 in view of Pogorelik ‘626 does not disclose but Agrawal ‘731 discloses:
(ii) performing pattern recognition on a party;
(iii) generating pattern recognition data; and
(iv) verifying the generated pattern recognition data at the trusted agent by transmitting a query based on the generated pattern recognition data to the trusted agent
(FIG. 3, [0075], for early detection of and response to a merchant data breach through machine-learning analysis (generating pattern recognition data). The method 300 may be executed by one or more servers (the trusted agent) ... receiving transaction data associated with a plurality of transactions between one or more financial device holders and one or more merchants (between many parties) in step 302 ... receiving fraudulent transaction data representative of one or more previously identified data-breach incidents, in step 304. For example, if a data breach was self-reported by a merchant, the fraudulent transaction data may include transaction data associated with transactions for the reporting merchant that occurred around and/or after the time of data breach. Moreover, if the data breach was previously detected by the system's data breach detection models (performing pattern recognition on a party and generating pattern recognition data), transactions associated with one or more detected breaches may be used as a baseline for future breach determinations. In this manner, the predictive models can continuously be improved to provide more efficient and accurate determinations of data breach (verifying the generated pattern recognition data); [0076], This dataset may be used as a comparison to the first model input dataset for the detection models. Because the second model input dataset (pattern recognition data) includes transaction data associated with one or more breach incidents, the patterns and metrics (performing pattern recognition on a party) associated with fraud can be determined and applied to the first model input dataset to detect fraud ... The machine-learning prediction models may be then employed to determine a likelihood of breach of each analyzed merchant in step 310 (verifying the generated pattern recognition data based on the generated pattern recognition data).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 in view of Pogorelik ‘626 with the machine-learning prediction models to determine a likelihood of breach of each analyzed merchant based on transaction data between financial device holders and merchants as taught by Agrawal ‘731 because it would quickly and efficiently detect merchant breaches and provide preventative measures, such as automatic notifications of breach events and/or seizing of accounts [0003-0004]. Additionally, Agrawal ‘731 is analogous to the claimed invention because it teaches a method for early detection of and response to a merchant data breach through machine-learning analysis [0019].
Per claim 12 (dependent on claim 11):
CHU ‘075 in view of Pogorelik ‘626 and Agrawal ‘731 discloses the elements detailed in the rejection of claim 11 above, incorporated herein by reference.
CHU ‘075 in view of Pogorelik ‘626 does not disclose but Agrawal ‘731 discloses: The method of claim 46, wherein the method further comprises:
(i) training a pattern recognition model for a party by repeatedly:
(ii) performing pattern recognition on a party;
(iii) generating pattern recognition data; and
(iv) verifying the generated pattern recognition data at the trusted agent by transmitting a query based on the generated pattern recognition data to the trusted agent, wherein the pattern recognition data is historical data and wherein the training data is live data
(FIG. 3, [0075], for early detection of and response to a merchant data breach through machine-learning analysis (generating pattern recognition data). The method 300 may be executed by one or more servers (the trusted agent) ... receiving transaction data (the training data) associated with a plurality of transactions between one or more financial device holders and one or more merchants (between many parties) in step 302 ... receiving fraudulent transaction data representative of one or more previously identified data-breach incidents, in step 304. For example, if a data breach was self-reported by a merchant, the fraudulent transaction data may include transaction data associated with transactions for the reporting merchant that occurred around and/or after the time of data breach. Moreover, if the data breach was previously detected (that is, live data – by interpreting transaction data in real time, that is how a typical neural network works.) by the system's data breach detection models (performing pattern recognition on a party and generating pattern recognition data), transactions associated with one or more detected breaches may be used as a baseline (used as the training data) for future breach determinations – clearly, the pattern recognition data would be cumulative data reflecting the past (and the present). In this manner, the predictive models (a pattern recognition model) can continuously be improved to provide more efficient and accurate determinations of data breach – training the pattern recognition model for a party by repeatedly; [0076], This dataset may be used as a comparison to the first model input dataset for the detection models. Because the second model input dataset (pattern recognition data) includes transaction data associated with one or more breach incidents, the patterns and metrics (performing pattern recognition on a party) associated with fraud can be determined and applied to the first model input dataset to detect fraud ... The machine-learning prediction models may be then employed to determine a likelihood of breach of each analyzed merchant in step 310 (verifying the generated pattern recognition data based on the generated pattern recognition data).).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have modified CHU ‘075 in view of Pogorelik ‘626 with the machine-learning prediction models to determine a likelihood of breach of each analyzed merchant based on transaction data between financial device holders and merchants as taught by Agrawal ‘731 because it would quickly and efficiently detect merchant breaches and provide preventative measures, such as automatic notifications of breach events and/or seizing of accounts [0003-0004].
Allowable Subject Matter
Claim(s) 5-9 and 13-15 is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANGSEOK PARK whose telephone number is (571)272-4332. The examiner can normally be reached Monday-Friday 7:30-5:30 and Alternate Fridays 9:00 am-5:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PHILIP CHEA can be reached at (571)272-3951. 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.
/SANGSEOK PARK/Primary Examiner, Art Unit 2499