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 .
DETAILED ACTION
1. Claims 1 - 20 are pending. Claims 1, 9, 17 are independent.
2. This application was filed on 12-19-2024.
Double Patenting
3. 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 obviousness-type 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 Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
4. Initially it should be noted that the present application is a continuation application of application 17/130574, now Patent No. 12,212,681, having the same inventive entity. The Assignee in both applications is the same. The entire disclosures of the instant application and the patent are identical.
Claims 1 - 20 are rejected under the judicially created doctrine of nonstatutory obviousness-type double patenting as being unpatentable over Claims 1 - 16 of U.S. Patent No. 12,212,681. Although the conflicting claims are not identical, they are not patentably distinct from each other.
Claims 1, 9, 17 of the instant application (18/988512) are almost the same as Patent (12,212,681) Claims 1, 13, 16. Claim 1 of the 12,212,681 Patent as shown in the table below contains every element of Claim 1 of the instant application and as such the difference is not enough to distinguish the two claims. Claims 1, 9, 17 of the instant application are anticipated by claim limitations recited in patent claims ‘681, therefore are not patently distinct from the earlier patent claims and as such are unpatentable over obvious-type double patenting. A later patent/application claim is not patentably distinct from an earlier claim, if the later claim is unpatentable over the earlier claim.
Application 18/988512
Claim 1
Patent (12,212,681)
Claim 1
“receiving, by at least one processor from a user device, a request for execution of a network operation, the request comprising a first identifier associated with the user device”
“receiving, at a computing system, a first request from a user device, the first request comprising at least card data and data indicating that a secure identifier does not exist at the user device” and “generating, by the computing system, a globally unique identifier for the user”
“extracting, by the at least one processor, using the first identifier, a plurality of attributes of the network operation and user device attributes”
“generating, by the computing system, a globally unique identifier for the user”
“extracting, by the at least one processor, a second identifier previously generated uniquely for the user device”
“extracting, by the computing system, from the secure identifier, the globally unique identifier and the secure message authentication code purported to be associated with the user device”
“executing, by the at least one processor, a defined cryptographic protocol using the second identifier and a selected cryptographic key used to generate the first identifier to generate a first authentication code”
“generating, by the computing system, a secure message authentication code using the globally unique identifier as an input to a cryptographic protocol”
“in response to determining that the first authentication code matches a second authentication code parsed from the first identifier”
“validating the secure identifier by comparing the true secure message authentication code with the secure message authentication code associated with the user device”
“executing, by the at least one processor, a machine learning model using the user device attributes associated with the request and user device attributes associated with a previously known request, the machine learning model configured to predict a likelihood of fraud using mismatched attributes”
“validating the user device by comparing a first set of device attributes collected from the user device during the second request with a second set of device attributes collected from the user device prior to the second request, wherein the comparing is based at least in part on a machine learning model analysis of the first set of device attributes in view of the second set of device attributes that determines that a combination of attribute matches and attribute mismatches is an indicative of fraud”
“in response to determining that the first authentication code matches a second authentication code parsed from the first identifier”
“validating the secure identifier by comparing the true secure message authentication code with the secure message authentication code associated with the user device”
“in response to determining that a prediction of likelihood of fraud fails to satisfy a security threshold, rejecting, by the at least one processor, the request to execute the network operation”
“validating the user device by comparing a first set of device attributes collected from the user device during the second request with a second set of device attributes collected from the user device prior to the second request, wherein the comparing is based at least in part on a machine learning model analysis of the first set of device attributes in view of the second set of device attributes that determines that a combination of attribute matches and attribute mismatches is an indicative of fraud” and “processing the second request, by the computing system, based at least in part on a determination that the secure identifier is valid and the user device is a valid user device”
Claim Rejections - 35 USC § 103
5. 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.
6. Claims 1 - 20 are rejected under 35 U.S.C. 103 as being unpatentable over Neafsey et al. (US Patent No. 10,122,721) in view of Idnani et al. (US PGPUB No. 20170353859) and further in view of Patel et al. (US PGPUB No. 20200294056).
Regarding Claims 1, 9, 17, Neafsey discloses a method for fraud detection in network operations, the method comprising:
a) receiving, by at least one processor from a user device, a request for execution of a network operation, the request comprising a first identifier associated with the user device; (see Neafsey col 1, lines 48-51: encrypting, by the server, a first identifier associated with a registered user of the mobile device and communicating the encrypted first identifier to the mobile device; col 7, lines 24-31: application requests communication (a request) with lock device, request for communication being transmitted to the lock device; in response to the request for communication, the lock device transmit a challenge to the mobile device, and for the application, that seeks to verify that the mobile device and/or associated application is authorized to at least communicate with the lock device; (a request))
b) extracting, by the at least one processor, using the first identifier, a plurality of attributes of the network operation and user device attributes; (see Neafsey col 1, lines 60-64: server extracts from the communicated third data set the first and second identifiers, and the extracted first and second identifiers are compared to verify that the second identifier is related to the first identifier) and
c) extracting, by the at least one processor, a second identifier previously generated uniquely for the user device. (see Neafsey col 1, lines 60-64: server extracts from the communicated third data set the first and second identifiers, and the extracted first and second identifiers are compared to verify that the second identifier is related to the first identifier)
Neafsey does not specifically disclose for d) executing a defined cryptographic protocol using a second identifier and a selected cryptographic key used to generate a first identifier to generate a first authentication code, and for e) in response to determining that the first authentication code matches a second authentication code parsed from the first identifier, and for f) executing a machine learning model using user device attributes associated with a request and user device attributes, the machine learning model configured to predict a likelihood of fraud using mismatched attributes.
However, Idnani discloses:
d) executing, by the at least one processor, a defined cryptographic protocol using the second identifier and a selected cryptographic key used to generate the first identifier to generate a first authentication code; (see Idnani paragraph [0036], lines 4-13: VSA (vendor specific attributes) includes a key-hash message authentication code (HMAC) signature, which may be calculated using, for example, the SSID, BSSID, and other known attributes (i.e., known to the IoT device and the gateway device); such an HMAC signature approach may be further enhanced by provisioning the gateway device and IoT devices, with a long string of random characters that may then be used to extract a random “initialization vector” (IV), which may be used for the calculation of an HMAC signature calculation; (cryptographic operations)) and
e) in response to determining that the first authentication code matches a second authentication code parsed from the first identifier: (see Idnani paragraph [0036], lines 19-22: gateway device may then use the information in the vendor-specific attribute(s) to calculate the HMAC signature, and may consider the IoT device to be an authentic IoT device if the received HMAC is validated; (validated: performing operation, not validated rejecting operation)) and
f) executing, by the at least one processor, a machine learning model using the user device attributes associated with the request and user device attributes associated with a previously known request, the machine learning model configured to predict a likelihood of fraud using mismatched attributes. (see Idani paragraph [0036], lines 4-22: VSA (vendor specific attributes) includes a key-hash message authentication code (HMAC) signature, which may be calculated using, for example, the SSID, BSSID, and other known attributes (i.e., known to the IoT device and the gateway device); such an HMAC signature approach may be further enhanced by provisioning the gateway device and IoT devices, with a long string of random characters that may then be used to extract a random “initialization vector” (IV), which may be used for the calculation of an HMAC signature calculation; (cryptographic operations); gateway device may then use the information in the vendor-specific attribute(s) to calculate the HMAC signature, and consider the IoT device to be an authentic IoT device if the received HMAC is validated; (selected: device attributes to determine a likelihood that attribute matches and attribute mismatches are attributable to transaction fraud))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for d) executing a defined cryptographic protocol using a second identifier and a selected cryptographic key used to generate a first identifier to generate a first authentication code, and for e) in response to determining that the first authentication code matches a second authentication code parsed from the first identifier, and for f) executing a machine learning model using user device attributes associated with a request and user device attributes, the machine learning model configured to predict a likelihood of fraud using mismatched attributes as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-22)
Neafsey in view of Idnani does not disclose for g) in response to determining that a prediction of likelihood of fraud fails to satisfy a security threshold, rejecting request to execute network operation.
However, Patel discloses:
g) in response to determining that a prediction of likelihood of fraud fails to satisfy a security threshold, rejecting, by the at least one processor, the request to execute the network operation. (see Patel paragraph [0016], lines 1-24: analyzing data using secured computations may include identifying an exact SSN match with an SSN value (baseline) and generating alerts if there is a mismatch based on pre-defined attributes, such as account attributes (e.g., even if the encrypted SSN value matches an unencrypted SSN value, a transmission may be fraudulent unless one or more other attributes in the transmission, such as name, address, and telephone number, match attributes associated with an account of a user whose SSN value is in the transmission) (combination of attribute matching results indicate fraud); if a distance between an SSN does not match an expected distance or does not satisfy one or more distance thresholds (e.g., the distance is too close or too far away from an expected value or is not within a distance range), then a device may determine that an attempt to access information may be fraudulent; paragraph [0024], lines 23-40: risk score may indicate a higher risk of fraud when more of the personal data inputs are within respective proximity thresholds or ranges of proximity thresholds of the like data stored in the one or more databases, and may indicate a lower risk of fraud when fewer of the personal data inputs are within respective proximity thresholds of the like data stored in the one or more databases; When the one or more remote servers determine that the risk score indicates that the risk of fraud is too high (e.g., exceeds a risk threshold), the remote servers may prevent one or more actions, such as the creation or modification of an account, or a transaction using the personal data inputs)
A combination of matches of a comparison of a set of attributes and mismatches of a comparison of a set of attributes is to be utilized as an indication of a fraud conclusion.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey in view of Idnani for g) in response to determining that a prediction of likelihood of fraud fails to satisfy a security threshold, rejecting request to execute network operation as taught by Patel. One of ordinary skill in the art would have been motivated to employ the teachings of Patel for the benefits achieved from a system that utilizes a combination of matches of attributes and mismatches of attributes as an indication of fraud. (see Patel paragraph [0016], lines 1-24; paragraph [0024], lines 23-40)
Regarding Claims 2, 10, 18, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose the user device attributes comprise data indicative of one or more of: a user device identifier, a user device manufacturer, an internet protocol address associated with the user device, transport layer security fingerprint data associated with the user device, an operating system type and/or operating system version executed by the user device during the request, and a web browser type and/or web browser version used by the user device during the request.
However, discloses wherein the user device attributes comprise data indicative of one or more of: a user device identifier, a user device manufacturer, an internet protocol address associated with the user device, transport layer security fingerprint data associated with the user device, an operating system type and/or operating system version executed by the user device during the request, and a web browser type and/or web browser version used by the user device during the request. (see Idnani paragraph [0069], lines 1-5: IoT system may register with the account of an end-user, any IoT devices that have a source IP address that matches a source IP address of other IoT devices registered to the end-user; (selected: an internet (IP) protocol address of the user device); (selected: an internet protocol address associated with the user device))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for the user device attributes comprise data indicative of one or more of: a user device identifier, a user device manufacturer, an internet protocol address associated with the user device, transport layer security fingerprint data associated with the user device, an operating system type and/or operating system version executed by the user device during the request, and a web browser type and/or web browser version used by the user device during the request as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-22)
Regarding Claims 3, 11, 19, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose the plurality of attributes of the network operation comprise data indicative of at least one of a card number, a name on card, or an email used in the network operation.
However, Patel discloses wherein the plurality of attributes of the network operation comprise data indicative of at least one of a card number, a name on card, or an email used in the network operation. (see Patel paragraph [0031]: when the remote computer system 214 receives the one or more data inputs 210 (e.g., account information and/or user information, such as a Social Security Number, payment card information (analogous to card number), a person's name, an address, personal health information, or the like), the information may be encrypted; (selected: a card number, payment card information))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for the plurality of attributes of the network operation comprise data indicative of at least one of a card number, a name on card, or an email used in the network operation as taught by Patel. One of ordinary skill in the art would have been motivated to employ the teachings of Patel for the benefits achieved from a system that utilizes a combination of matches of attributes and mismatches of attributes as an indication of fraud. (see Patel paragraph [0016], lines 1-24; paragraph [0024], lines 23-40)
Regarding Claims 4, 12, 20, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose the request for execution of the network operation comprises at least card data and one or more request parameters, wherein the one or more request parameters comprise a request amount, a request type, a request origination location, an internet protocol address of the user device, an identity of a user associated with the request, or a combination thereof.
However, Idnani discloses wherein the request for execution of the network operation comprises at least card data and one or more request parameters, wherein the one or more request parameters comprise a request amount, a request type, a request origination location, an internet protocol address of the user device, an identity of a user associated with the request, or a combination thereof. (see Idnani paragraph [0031]: when the remote computer system 214 receives the one or more data inputs 210 (e.g., account information and/or user information, such as a Social Security Number, payment card information, a person's name, an address, personal health information, or the like), the information may be encrypted; (selected: a card number); paragraph [0069], lines 1-5: IoT system may register with the account of an end-user, any IoT devices that have a source IP address that matches a source IP address of other IoT devices registered to the end-user; (request parameter selected: an internet protocol address associated with the user device))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for the request for execution of the network operation comprises at least card data and one or more request parameters, wherein the one or more request parameters comprise a request amount, a request type, a request origination location, an internet protocol address of the user device, an identity of a user associated with the request, or a combination thereof as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-13)
Regarding Claims 5, 13, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose a cryptographic protocol comprising a secure hash-based message authentication code generation protocol.
However, Idnani discloses wherein the defined cryptographic protocol comprises a secure hash-based message authentication code generation protocol. (see Idnani paragraph [0036], lines 4-13: VSA (vendor specific attributes) includes a key-hash message authentication code (HMAC) signature, which may be calculated using, for example, the SSID, BSSID, and other known attributes (i.e., known to the IoT device and the gateway device); such an HMAC signature approach may be further enhanced by provisioning the gateway device and IoT devices, with a long string of random characters that may then be used to extract a random “initialization vector” (IV), which may be used for the calculation of an HMAC signature calculation; (cryptographic operations, cryptographic protocol))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for a cryptographic protocol comprising a secure hash-based message authentication code generation protocol as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-13)
Regarding Claims 6, 14, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose for a) determining the security threshold, and for b) evaluating the predicted likelihood of fraud against the security threshold, wherein the request rejected upon determining that the predicted likelihood exceeds security threshold.
However, Patel discloses further comprising:
a) determining, by the machine learning model, the security threshold; b) evaluating, by the machine learning model, the predicted likelihood of fraud against the security threshold, wherein the request is rejected upon determining that the predicted likelihood exceeds the security threshold. (see Patel paragraph [0016], lines 1-24: analyzing data using secured computations may include identifying an exact SSN match with an SSN value (baseline) and generating alerts if there is a mismatch based on pre-defined attributes, such as account attributes (e.g., even if the encrypted SSN value matches an unencrypted SSN value, a transmission may be fraudulent unless one or more other attributes in the transmission, such as name, address, and telephone number, match attributes associated with an account of a user whose SSN value is in the transmission) (combination of attribute matching results indicate fraud); if a distance between an SSN does not match an expected distance or does not satisfy one or more distance thresholds (e.g., the distance is too close or too far away from an expected value or is not within a distance range), then a device may determine that an attempt to access information may be fraudulent; paragraph [0024], lines 23-40: risk score may indicate a higher risk of fraud when more of the personal data inputs are within respective proximity thresholds or ranges of proximity thresholds of the like data stored in the one or more databases, and may indicate a lower risk of fraud when fewer of the personal data inputs are within respective proximity thresholds of the like data stored in the one or more databases; When the one or more remote servers determine that the risk score indicates that the risk of fraud is too high (e.g., exceeds a risk threshold), the remote servers may prevent one or more actions, such as the creation or modification of an account, or a transaction using the personal data inputs)
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for a) determining the security threshold, and for b) evaluating the predicted likelihood of fraud against the security threshold, wherein the request rejected upon determining that the predicted likelihood exceeds security threshold as taught by Patel. One of ordinary skill in the art would have been motivated to employ the teachings of Patel for the benefits achieved from a system that utilizes a combination of matches of attributes and mismatches of attributes as an indication of fraud. (see Patel paragraph [0016], lines 1-24; paragraph [0024], lines 23-40)
Regarding Claims 7, 15, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose for a) determining whether the extracted secure message authentication code satisfies a formatting requirement, and for b) when the requirement is determined not to be satisfied, determining that secure identifier is not an actual secure identifier, and rejecting transaction as not including a valid secure identifier, and for c) when the requirement is determined to be satisfied, performing the extracting.
However, Idnani discloses:
wherein prior to parsing the second authentication code, the method further comprising:
a) determining, by the at least one processor, whether the parsed second authentication code satisfies a formatting requirement for second authentication codes; (see Idnani paragraph [0036], lines 4-13: VSA (vendor specific attributes) includes a key-hash message authentication code (HMAC) signature, which may be calculated using, for example, the SSID, BSSID, and other known attributes (i.e., known to the IoT device and the gateway device, device attributes); such an HMAC signature approach may be further enhanced by provisioning the gateway device and IoT devices, with a long string of random characters that may then be used to extract a random “initialization vector” (IV), which may be used for the calculation of an HMAC signature calculation; (cryptographic operations)) )
b) when the formatting requirement is determined not to be satisfied by the parsed second authentication code, determining that the first identifier is not an actual first identifier, and rejecting the request as not including a valid first identifier; (see Idnani paragraph [0036], lines 19-22: gateway device then use the information in the vendor-specific attribute(s) to calculate the HMAC signature, and consider the IoT device to be an authentic IoT device if the received HMAC is validated; (validated: performing operation, not validated rejecting operation)) and
c) when the formatting requirement is determined to be satisfied by the parsed second authentication code, performing the extracting. (see Idnani paragraph [0036], lines 19-22: gateway device may then use the information in the vendor-specific attribute(s) to calculate the HMAC signature, and may consider the IoT device to be an authentic IoT device if the received HMAC is validated; (validated: performing operation, not validated rejecting operation))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for a) determining whether the extracted secure message authentication code satisfies a formatting requirement, and for b) when the requirement is determined not to be satisfied, determining that secure identifier is not an actual secure identifier, and rejecting transaction as not including a valid secure identifier, and for c) when the requirement is determined to be satisfied, performing the extracting as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-13)
Regarding Claims 8, 16, Neafsey-Idnani-Patel discloses the method of claim 1.
Neafsey does not specifically disclose for a) collecting a first set of device attributes from user device; b) accessing a second set of device attributes collected prior to the transaction, the second set of one or more device attributes mapped to the second identifier, and for c) when a comparison of the first set of device attributes with the second set of device attributes indicates a device attribute match, determining that the user device is a valid user device, and for e) processing the transaction based at least in part on the determination that the first message authentication code matches the second message authentication code parsed from the first identifier.
However, Idani discloses further comprising:
a) collecting, by the at least one processor during the request, a first set of one or more user device attributes from the user device; b) accessing, by the at least one processor, a second set of one or more user device attributes collected by the at least one processor prior to the request, the second set of one or more device attributes mapped to the second authentication code in a data store; (see Idnani paragraph [0036], lines 4-22: VSA (vendor specific attributes) includes a key-hash message authentication code (HMAC) signature, which may be calculated using, for example, the SSID, BSSID, and other known attributes (i.e., known to the IoT device and the gateway device); such an HMAC signature approach may be further enhanced by provisioning the gateway device and IoT devices, with a long string of random characters that may then be used to extract a random “initialization vector” (IV), which may be used for the calculation of an HMAC signature calculation; parameters such as the index and/or possibly length of the IV may be communicated through a vendor-specific attribute in a Wi-Fi beacon; (attributes collected); (cryptographic operations)) and
e) processing, by the at least one processor, the request based at least in part on the determination that the first authentication code matches the second authentication code parsed from the first identifier, and further based on the user device being the valid user device. (see Idnani paragraph [0036], lines 19-22: gateway device may then use the information in the vendor-specific attribute(s) to calculate the HMAC signature, and may consider the IoT device to be an authentic IoT device if the received HMAC is validated; (validated: performing operation, not validated rejecting operation))
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for a) collecting a first set of device attributes from user device; b) accessing a second set of device attributes collected prior to the transaction, the second set of one or more device attributes mapped to the second identifier, and for c) when a comparison of the first set of device attributes with the second set of device attributes indicates a device attribute match, determining that the user device is a valid user device, and for e) processing the transaction based at least in part on the determination that the first message authentication code matches the second message authentication code parsed from the first identifier as taught by Idnani. One of ordinary skill in the art would have been motivated to employ the teachings of Idnani for the benefits achieved from a system that enables secure data processing utilizing additional information such as device attributes. (see Idnani paragraph [0036], lines 4-22)
Neafsey does not specifically disclose for c) inputting the first set of one or more user device attributes and the second set of one or more user device attributes into the machine learning model to cause the machine learning model to determine a likelihood that attribute matches and attribute mismatches are attributable to fraud, and for d) determining that the user device requesting the request is a valid user device based on the likelihood that the attribute matches and attribute mismatches are not attributable to fraud.
However, Patel discloses:
c) inputting, by the at least one processor, the first set of one or more user device attributes and the second set of one or more user device attributes into the machine learning model to cause the machine learning model to determine a likelihood that attribute matches and attribute mismatches are attributable to fraud; d) determining, by the at least one processor, that the user device requesting the request is a valid user device based on the likelihood that the attribute matches and attribute mismatches are not attributable to fraud. (see Patel paragraph [0016], lines 1-24: analyzing data using secured computations may include identifying an exact SSN match with an SSN value (baseline) and generating alerts if there is a mismatch based on pre-defined attributes, such as account attributes (e.g., even if the encrypted SSN value matches an unencrypted SSN value, a transmission may be fraudulent unless one or more other attributes in the transmission, such as name, address, and telephone number, match attributes associated with an account of a user whose SSN value is in the transmission) (combination of attribute matching results indicate fraud); if a distance between an SSN does not match an expected distance or does not satisfy one or more distance thresholds (e.g., the distance is too close or too far away from an expected value or is not within a distance range), then a device may determine that an attempt to access information may be fraudulent; paragraph [0024], lines 23-40: risk score may indicate a higher risk of fraud when more of the personal data inputs are within respective proximity thresholds or ranges of proximity thresholds of the like data stored in the one or more databases, and may indicate a lower risk of fraud when fewer of the personal data inputs are within respective proximity thresholds of the like data stored in the one or more databases; When the one or more remote servers determine that the risk score indicates that the risk of fraud is too high (e.g., exceeds a risk threshold), the remote servers may prevent one or more actions, such as the creation or modification of an account, or a transaction using the personal data inputs)
A combination of matches of a comparison of a set of attributes and mismatches of a comparison of a set of attributes is to be utilized as an indication of a fraud conclusion.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Neafsey for c) inputting the first set of one or more user device attributes and the second set of one or more user device attributes into the machine learning model to cause the machine learning model to determine a likelihood that attribute matches and attribute mismatches are attributable to fraud, and for d) determining that the user device requesting the request is a valid user device based on the likelihood that the attribute matches and attribute mismatches are not attributable to fraud as taught by Patel. One of ordinary skill in the art would have been motivated to employ the teachings of Patel for the benefits achieved from a system that utilizes a combination of matches of attributes and mismatches of attributes as an indication of fraud. (see Patel paragraph [0016], lines 1-24; paragraph [0024], lines 23-40)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLTON JOHNSON whose telephone number is (571)270-1032. The examiner can normally be reached Work: 12-9PM (most days).
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, Shewaye Gelagay can be reached at 571-272-4219. 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.
/CJ/
May 18, 2026
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights