DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The present application, filed on June 06, 2025, is accepted.
Claims 1 – 20 are being considered on the merits.
Drawings
The drawings, filed on June 06, 2025, are accepted.
Specification
The specification, filed on June 06, 2025, is accepted.
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.
Claims 1 – 20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 – 20 of U.S. Patent No. 12346426. Although the claims at issue are not identical, they are not patentably distinct from each other because both applications discussed methods, systems, and apparatuses for improving computer authentication processes through computer-based authentication in a manner that uses knowledge of former devices.
U.S. Patent No. 12346426
19/230,428
1. A computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: train, using training data comprising account records from a plurality of different users, a first machine learning model to output, for a particular device, an indication of device reliability data associated with the particular device, wherein the account records are associated with a plurality of devices used by the plurality of different users to access one or more accounts in the account records; receive, from a user device, a request for access to an account associated with a user; receive, from one or more databases, account data corresponding to the account, wherein the account data indicates one or more logins originated from the user; determine, based on the account data, device history comprising a set of devices used by the user to login to the account within a predetermined period of time; provide, as input to the trained first machine learning model, the account data; receive, from the trained first machine learning model, data indicating device reliability for the set of devices; determining, based on the device history, one or more false devices that the user has not used to access the account for the predetermined period of time; generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices, wherein the set of modified device choices comprise the one or more false devices; generate an authentication question comprising at least one device choice from the modified set of device choices; generate, based on the account data and the modified set of device choices, a correct answer to the authentication question; provide the authentication question to the user device; receive, from the user device, a response to the authentication question; compare the response to the authentication question to the correct answer; and grant the user device access to the account based on the response to the authentication question matching the correct answer.
1. A computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: receive, from a user device, a request for access to an account associated with a user; determine, based on account data corresponding to the account, device history comprising a set of devices used by the user to login to the account within a predetermined period of time, and one or more false devices that the user has not used to access the account for the predetermined period of time; generate, using a machine learning model trained to output device reliability data, data indicating device reliability for the set of devices; generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices; generate an authentication question comprising at least one device choice from the modified set of device choices and at one false device from the one or more false devices; and grant the user device access to the account based on a correct response to the authentication question.
1. A computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: train, using training data comprising account records from a plurality of different users, a first machine learning model to output, for a particular device, an indication of device reliability data associated with the particular device, wherein the account records are associated with a plurality of devices used by the plurality of different users to access one or more accounts in the account records; receive, from a user device, a request for access to an account associated with a user; receive, from one or more databases, account data corresponding to the account, wherein the account data indicates one or more logins originated from the user; determine, based on the account data, device history comprising a set of devices used by the user to login to the account within a predetermined period of time; provide, as input to the trained first machine learning model, the account data; receive, from the trained first machine learning model, data indicating device reliability for the set of devices; determining, based on the device history, one or more false devices that the user has not used to access the account for the predetermined period of time; generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices, wherein the set of modified device choices comprise the one or more false devices; generate an authentication question comprising at least one device choice from the modified set of device choices; generate, based on the account data and the modified set of device choices, a correct answer to the authentication question; provide the authentication question to the user device; receive, from the user device, a response to the authentication question; compare the response to the authentication question to the correct answer; and grant the user device access to the account based on the response to the authentication question matching the correct answer.
2. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: train, using training data comprising account records from a plurality of different users, the machine learning model to output, for a particular device, an indication of the device reliability data associated with the particular device, wherein the account records are associated with a plurality of devices used by the plurality of different users to access one or more accounts in the account records.
2. The computing device of claim 1, wherein the training data comprises device information for the plurality of devices used by the plurality of different users comprising: a frequency of use for each device of the plurality of devices, a duration of use for each device of the plurality of devices, and a time lapsed since a last use for each device of the plurality of devices.
3. The computing device of claim 2, wherein the training data comprises device information for the plurality of devices used by the plurality of different users comprising: a frequency of use for each device of the plurality of devices, a duration of use for each device of the plurality of devices, and a time lapsed since a last use for each device of the plurality of devices.
3. The computing device of claim 1 wherein the training data comprises web browser information corresponding to a web browser executed by the plurality of devices used by the plurality of different users.
4. The computing device of claim 2, wherein the training data comprises web browser information corresponding to a web browser executed by the plurality of devices used by the plurality of different users.
4. The computing device of claim 1, wherein the training data comprises account information comprising: one or more questions previously presented to the plurality of different users, and responses from the plurality of different users.
5. The computing device of claim 2, wherein the training data comprises account information comprising: one or more security questions previously presented to the plurality of different users, and responses from the plurality of different users.
5. The computing device of claim 1, wherein the training data comprises transaction information indicating whether transactions conducted by the plurality of devices were fraudulent.
6. The computing device of claim 2, wherein the training data comprises transaction information indicating whether transactions conducted by the plurality of devices were fraudulent.
1. A computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, cause the computing device to: train, using training data comprising account records from a plurality of different users, a first machine learning model to output, for a particular device, an indication of device reliability data associated with the particular device, wherein the account records are associated with a plurality of devices used by the plurality of different users to access one or more accounts in the account records; receive, from a user device, a request for access to an account associated with a user; receive, from one or more databases, account data corresponding to the account, wherein the account data indicates one or more logins originated from the user; determine, based on the account data, device history comprising a set of devices used by the user to login to the account within a predetermined period of time; provide, as input to the trained first machine learning model, the account data; receive, from the trained first machine learning model, data indicating device reliability for the set of devices; determining, based on the device history, one or more false devices that the user has not used to access the account for the predetermined period of time; generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices, wherein the set of modified device choices comprise the one or more false devices; generate an authentication question comprising at least one device choice from the modified set of device choices; generate, based on the account data and the modified set of device choices, a correct answer to the authentication question; provide the authentication question to the user device; receive, from the user device, a response to the authentication question; compare the response to the authentication question to the correct answer; and grant the user device access to the account based on the response to the authentication question matching the correct answer.
7. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate, after generating the authentication question and prior to granting the user device access, and based on the account data and the modified set of device choices, a correct answer to the authentication question; provide the authentication question to the user device; receive, from the user device, a response to the authentication question; and compare the response to the authentication question to the correct answer.
8. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device that is not included in the set of devices, wherein the first device and the second device are associated with a same device manufacturer.
8. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, wherein the first device and the second device are associated with a same device manufacturer.
9. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to:generate the authentication question comprising a first device from the modified set of device choices and a second device that is not included in the set of devices, wherein the first device and the second device are associated with a similar price point.
9. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, wherein the first device and the second device are associated with a similar price point.
10. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to:generate the authentication question comprising a first device from the modified set of device choices and a second device that is not included in the set of devices, wherein the first device and the second device are available at a same period of time.
10. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to:generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, wherein the first device and the second device are available at a same period of time.
6. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: train, based on second training data comprising a history of authentication records, a second machine learning model to determine recommended reliability thresholds, wherein the history of authentication records comprise authentication questions and responses associated with different type of devices used by the plurality of different users and the corresponding scoring schemes; provide, as input to the trained second machine learning model, input data comprising the authentication question and the response to the authentication question from the user; and receive, as output from the trained second machine learning model, output data indicating a recommended threshold value associated with the user.
11. The computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: train, based on second training data comprising a history of authentication records, a second machine learning model to determine recommended reliability thresholds, wherein the history of authentication records comprise authentication questions and responses associated with different type of devices used by a plurality of different users and the corresponding scoring schemes; provide, as input to the trained second machine learning model, input data comprising the authentication question and the response to the authentication question from the user; and receive, as output from the trained second machine learning model, output data indicating a recommended threshold value associated with the user.
7. The computing device of claim 6, wherein the instructions, when executed by the one or more processors, cause the computing device to: receive user feedback information indicating whether the set of devices associated with the account data were valid candidates; and based on the user feedback information, re-train the second machine learning model to modify the recommended threshold value associated with the set of devices.
12. The computing device of claim 11, wherein the instructions, when executed by the one or more processors, cause the computing device to: receive user feedback information indicating whether the set of devices associated with the account data were valid candidates; and based on the user feedback information, re-train the second machine learning model to modify the recommended threshold value associated with the set of devices.
Claims 13 – 20 recites features similar to features within claims 1 – 11, therefore, they are rejected in a similar manner.
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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 10572653 B1 to Semichev et al., (hereinafter, “Semichev”) in view of US 20220286300 A1 to Draper et al., (hereinafter, “Draper”).
Regarding claim 1, Semichev teaches a computing device comprising: one or more processors; and memory storing instructions that, when executed by the one or more processors, [Semichev, col. 6 lines 9 – 12 discloses computer server 15 may include a computer processor 20, a computer memory 25, input/output devices 30, and communication circuitry and interface 35 for communicating 82 over communication network 60.]cause the computing device to: receive, from a user device, a request for access to an account associated with a user; [Semichev, col. 11 lines 63 – 67 discloses receiving 335 an electronic request on a computing device from an unverified customer who desires to perform one or more high-risk activities in an account of a particular customer of the plurality of customers.] generate an authentication question comprising at least one device choice from the modified set of device choices and at one false device from the one or more false devices; [Semichev, col. 6 lines 58 – 63 discloses generating the knowledge-based questions may use proprietary data known only to the financial institution or entity. The knowledge-based questions may challenge the customer to answer challenge questions about which accounts and/or account details that the customer has with the financial institution or entity.] and grant the user device access to the account based on a correct response to the authentication question. [Semichev, col. 12 lines 8 – 10discloses authenticating 355 the unverified customer to form a verified customer when the answers to the selected challenge questions are correct.], but Semichev does not teach determine, based on account data corresponding to the account, device history comprising a set of devices used by the user to login to the account within a predetermined period of time, and one or more false devices that the user has not used to access the account for the predetermined period of time; generate, using a machine learning model trained to output device reliability data, data indicating device reliability for the set of devices; generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices;
However, Draper does teach determine, based on account data corresponding to the account, device history comprising a set of devices used by the user to login to the account within a predetermined period of time, [Draper, para. 54 discloses for the factor of whether the client device previously decrypted content successfully, a numerical value of 0 can be assigned if the user has not previously decrypted content successfully, a numerical value of 0.5 can be assigned if the user has previously decrypted content successfully fewer than five times, and a numerical value of 1 can be assigned if the user has previously decrypted content successfully at least five times. Different scales and any score values can be used with each factor to determine the partial trust metric.]and one or more false devices that the user has not used to access the account for the predetermined period of time; [Draper, para. 17 discloses the partial trust metric can be created based on data available to the content sharing platform and can be used to indicate to the CDN the likelihood that the user, the media player, and/or the client device is authorized to access the requested content, as opposed to an unauthorized entity, such as those of a third party media player, a bot, a server farm, and so forth.] generate, using a machine learning model trained to output device reliability data, data indicating device reliability for the set of devices; [Draper, para. 55 discloses the target outputs can include indications of whether the client devices were authorized to obtain the requested content. In another implementation, the partial trust predicting model can be trained for a specific user based on training data associated with the user, and or the media player and/or the client device of the user.] generate, based on the data indicating device reliability for the set of devices, a set of modified device choices by excluding one or more devices having corresponding reliability levels below a threshold value, from the set of devices; [Draper, para. 55 discloses. the training inputs can be based on historical data and include factors associated with various client devices previously requesting content from authorizing data service 124 and/or CDN server 132. The target outputs can include indications of whether the client devices were authorized to obtain the requested content. In another implementation, the partial trust predicting model can be trained for a specific user based on training data associated with the user, and or the media player and/or the client device of the user.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
As per claim 2, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: train, using training data comprising account records from a plurality of different users, the machine learning model to output, for a particular device, an indication of the device reliability data associated with the particular device, [Semichev, col. 8 lines 39 – 47 discloses training the at least one machine learning model may be performed using training data taken from customer interaction database 55 of the plurality of customers of the financial institution. Training the at least one machine learning model using the training data may maximize the number of instances for a given challenge question that the customer answers correctly and may minimize the number of instances for the same given challenge questions that a fraudster answers correctly.] wherein the account records are associated with a plurality of devices used by the plurality of different users to access one or more accounts in the account records. [Semichev, col. 11 lines 34 – 40 discloses storing 305 in a database in a computer memory, account activity data identifying prior account activities performed by a plurality of customers in their respective accounts associated with a financial institution, where the database stored in the computer memory is accessible only by computing systems of the financial institution]
Regarding claim 3, modified Semichev teaches the computing device of claim 2, but Semichev does not teach wherein the training data comprises device information for the plurality of devices used by the plurality of different users comprising: a frequency of use for each device of the plurality of devices, a duration of use for each device of the plurality of devices, and a time lapsed since a last use for each device of the plurality of devices.
However, Draper does teach wherein the training data comprises device information for the plurality of devices used by the plurality of different users comprising: a frequency of use for each device of the plurality of devices, [Draper, para. 55 discloses the training inputs can be based on historical data and include factors associated with various client devices previously requesting content from authorizing data service 124 and/or CDN server 132. Para. 54 discloses for the factor of whether the client device previously decrypted content successfully, a numerical value of 0 can be assigned if the user has not previously decrypted content successfully, a numerical value of 0.5 can be assigned if the user has previously decrypted content successfully fewer than five times, and a numerical value of 1 can be assigned if the user has previously decrypted content successfully at least five times.] a duration of use for each device of the plurality of devices, and a time lapsed since a last use for each device of the plurality of devices. [Draper, para. 53 discloses The authorizing data service 124 can generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
Regarding claim 4, modified Semichev teaches the computing device of claim 2, but modified Semichev does not teach wherein the training data comprises web browser information corresponding to a web browser executed by the plurality of devices used by the plurality of different users.
However, Draper does teach wherein the training data comprises web browser information corresponding to a web browser executed by the plurality of devices used by the plurality of different users. [Draper, para. 55 discloses the training inputs can be based on historical data and include factors associated with various client devices previously requesting content from authorizing data service 124 and/or CDN server 132. Para. 64 discloses the additional factors (CDN determined factors) can include the IP address used to request the content, one or more cookies provided to CDN 130 with the content request, a client agent reported by the client device (e.g., a browser, a bot, a download manager, an app accessing the internet, etc.), the type of the requested content (e.g., popular, private, advertising, a paid video, etc.), the bitrate of the requested content, the amount of content requested in the request, and so forth.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
As per claim 5, modified Semichev teaches the computing device of claim 2, wherein the training data comprises account information comprising: one or more security questions previously presented to the plurality of different users, and responses from the plurality of different users. [Semichev, col. 8 lines 48 – 55 discloses the training data in the training dataset may include, for example, a first indication that a correct or an incorrect answer was given for each challenge question in the set of challenge questions for each respective customer interaction from the plurality of customer interactions, and a second indication of a fraud tag applied to each respective customer interaction from the plurality of customer interactions.]
As per claim 6, modified Semichev teaches the computing device of claim 2, wherein the training data comprises transaction information indicating whether transactions conducted by the plurality of devices were fraudulent. [Semichev, col. 8 lines 28 – 38 discloses Training the at least one machine learning model may include providing data including a number of correct and wrong answers given to each of the challenge questions stored in challenge question database 50 in each customer interaction from a plurality of customer interactions stored in a customer interaction database 55. Any of the customer interactions in the plurality of customer interactions stored in customer interaction database 55 may include a fraud tag indicating that the customer interaction was suspected of being a fraudulent transaction made by a fraudster.]
Regarding claim 8, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, [Semichev, col. 6 lines 58 – 67 to col. 7 lines 1 – 5 discloses generating the knowledge-based questions may use proprietary data known only to the financial institution or entity. The knowledge-based questions may challenge the customer to answer challenge questions about which accounts and/or account details that the customer has with the financial institution or entity. The information may be stored in memory 25 in a customer database, and/or information about previous interactions that the customer had with the financial institution or entity stored in customer interaction database 55. Col. 7 lines 6 – 14 discloses the authentication challenge questions may be further refined by using at least one machine learning algorithm so as to determine which challenge questions in a set of challenge questions have a better chance or probability for obtaining a correct answer from the customer and a wrong answer from a fraudster. The machine learning algorithm may apply an authentication score to each challenge question in the set. The set of challenge questions may be stored, for example, in challenge question database 50], but modified Semichev does not teach wherein the first device and the second device are associated with a same device manufacturer.
However, Draper does teach wherein the first device and the second device are associated with a same device manufacturer. [Draper, para. 27 discloses Client devices 110A-110Z may each include computing devices such as personal computers (PCs), laptops, mobile phones, smart phones, tablet computers, netbook computers, network-connected televisions, etc. In some embodiments, client devices 110A-110Z may also be referred to as “user devices.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
Regarding claim 9, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, [Semichev, col. 6 lines 58 – 67 to col. 7 lines 1 – 5 discloses generating the knowledge-based questions may use proprietary data known only to the financial institution or entity. The knowledge-based questions may challenge the customer to answer challenge questions about which accounts and/or account details that the customer has with the financial institution or entity. The information may be stored in memory 25 in a customer database, and/or information about previous interactions that the customer had with the financial institution or entity stored in customer interaction database 55. Col. 7 lines 6 – 14 discloses the authentication challenge questions may be further refined by using at least one machine learning algorithm so as to determine which challenge questions in a set of challenge questions have a better chance or probability for obtaining a correct answer from the customer and a wrong answer from a fraudster. The machine learning algorithm may apply an authentication score to each challenge question in the set. The set of challenge questions may be stored, for example, in challenge question database 50], but modified Semichev does not teach wherein the first device and the second device are associated with a similar price point.
However, Draper does teach wherein the first device and the second device are associated with a similar price point. [Draper, para. 53 discloses the authorizing data service 124 can generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
Regarding claim 10, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: generate the authentication question comprising a first device from the modified set of device choices and a second device from the one or more false devices, [Semichev, col. 6 lines 58 – 67 to col. 7 lines 1 – 5 discloses generating the knowledge-based questions may use proprietary data known only to the financial institution or entity. The knowledge-based questions may challenge the customer to answer challenge questions about which accounts and/or account details that the customer has with the financial institution or entity. The information may be stored in memory 25 in a customer database, and/or information about previous interactions that the customer had with the financial institution or entity stored in customer interaction database 55. Col. 7 lines 6 – 14 discloses the authentication challenge questions may be further refined by using at least one machine learning algorithm so as to determine which challenge questions in a set of challenge questions have a better chance or probability for obtaining a correct answer from the customer and a wrong answer from a fraudster. The machine learning algorithm may apply an authentication score to each challenge question in the set. The set of challenge questions may be stored, for example, in challenge question database 50], but modified Semichev does not teach wherein the first device and the second device are available at a same period of time.
However, Draper does teach wherein the first device and the second device are available at a same period of time. [Draper, para. 53 discloses The authorizing data service 124 can generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Draper’s system with Semichev’s system with a motivation to generate the partial trust metric based on factors (e.g., data, signals, etc.) associated with client device 110 (or the user account, media player 112, or any combination thereof). One or more factors can be accessible by authorizing data service 124, but not available to server 132. In some embodiments, the factors can include a watch history of the user, whether the user viewed the content before, whether the client device previously decrypted content successfully, whether the user is logged-in, whether the user has engaged or been suspected of engaging in an authorized activity, the user's IP address, an encryption log associated with the user, and so forth. [Draper, para. 53]
As per claim 11, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: train, based on second training data comprising a history of authentication records, [Semichev, col. 9 lines 54 – 67 discloses Any suitable function, such as the at least one machine learning model, for computing authentication score 155 may be used, which may be any function of the first (N.sub.1), second (N.sub.2), third (N.sub.3), and fourth (N.sub.4) number of instances, or any combination thereof. Any number of challenge questions may be ranked using the methods shown herein, such as 10-50 challenge questions, for example, from which any predefined number of challenge questions, such as 2-5 challenge questions, for example, may be presented to the customer when the customer requests to perform high risk activity in the customer's account. N.sub.1, N.sub.2, N.sub.3, and N.sub.4 may be based on the size of the customer interaction database, on the order of 10,000, 1,000,000 or 10,000,000 customer interaction records.] a second machine learning model to determine recommended reliability thresholds, [Semichev, col. 10 lines 1 – 7 discloses challenge question management module 42 may be configured to apply a rank 145 to each challenge question 150 in the set of challenge questions. In other embodiments, challenge question management module 42 may rank each challenge question 150 in the set of challenge questions from a highest authentication score to a lowest authentication score.] wherein the history of authentication records comprise authentication questions and responses associated with different type of devices used by a plurality of different users and the corresponding scoring schemes; [Semichev, col. 9 lines 3 – 10 discloses the model may rank the question higher (e.g., assign a higher authentication score) in the training dataset for a given customer interaction for a given challenge question if a customer answers the given challenge question correctly. Conversely, the model may apply the loss function and rank the challenge question lower (e.g., assign a lower authentication score) when a fraudster and/or criminal answers the question correctly.] provide, as input to the trained second machine learning model, input data comprising the authentication question and the response to the authentication question from the user; [Semichev, col. 8 lines 28 – 38 discloses training the at least one machine learning model may include providing data including a number of correct and wrong answers given to each of the challenge questions stored in challenge question database 50 in each customer interaction from a plurality of customer interactions stored in a customer interaction database 55. Any of the customer interactions in the plurality of customer interactions stored in customer interaction database 55 may include a fraud tag indicating that the customer interaction was suspected of being a fraudulent transaction made by a fraudster.] and receive, as output from the trained second machine learning model, output data indicating a recommended threshold value associated with the user. [Semichev, col. 9 lines 11 – 17 discloses the at least one machine learning model may include a multi-armed bandit model or a multiclass classifier neural network model, for example. In other embodiments, the machine learning models may be improved using a gradient boosting machine (GBM), a multinomial output, and/or random forest learning models.]
As per claim 12, modified Semichev teaches the computing device of claim 11, wherein the instructions, when executed by the one or more processors, cause the computing device to: receive user feedback information indicating whether the set of devices associated with the account data were valid candidates; [Semichev, col. 8 lines 48 – 55 discloses the training data in the training dataset may include, for example, a first indication that a correct or an incorrect answer was given for each challenge question in the set of challenge questions for each respective customer interaction from the plurality of customer interactions, and a second indication of a fraud tag applied to each respective customer interaction from the plurality of customer interactions.] and based on the user feedback information, re-train the second machine learning model to modify the recommended threshold value associated with the set of devices. [Semichev, col. 8 lines 56 – 63 discloses training the at least one machine learning model may occur over a predefined period such as over months or days. The training process may take one day, for example, to render new version of the model. The model may then be retrained once new customer interaction data may become available as the fraud investigation team updates the data and re-ranks the challenge questions in the set of challenge questions.]
Regarding claims 13 – 14, they recite features similar to features within claims 1 – 2, therefore, they are rejected in a similar manner.
Regarding claims 15 – 17, they recite features similar to features within claims 8 – 10, therefore, they are rejected in a similar manner.
Regarding claim 19, it recites features similar to features within claim 1, therefore, it is rejected in a similar manner.
Claims 7, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US 10572653 B1 to Semichev et al., (hereinafter, “Semichev”) in view of US 20220286300 A1 to Draper et al., (hereinafter, “Draper”) further in view of US 20230196210 A1 to Bustelo-Killam et al., (hereinafter, “Bustelo”).
Regarding claim 7, modified Semichev teaches the computing device of claim 1, wherein the instructions, when executed by the one or more processors, cause the computing device to: provide the authentication question to the user device; [Semichev, col. 12 lines 1 – 3 discloses selecting 340 a predefined number of challenge questions having the highest authentication scores based on the ranking. Col. 12 lines 4 – 5 discloses displaying 345 the selected challenge questions on a screen of the computing device.]receive, from the user device, a response to the authentication question; [Semichev, col. 12 lines 6 – 7 discloses receiving 350 answers to the selected challenge questions.], but modified Semichev does not teach wherein the instructions, when executed by the one or more processors, cause the computing device to: generate, after generating the authentication question and prior to granting the user device access, and based on the account data and the modified set of device choices, a correct answer to the authentication question; and compare the response to the authentication question to the correct answer.
However, Bustelo does teach wherein the instructions, when executed by the one or more processors, cause the computing device to: generate, after generating the authentication question and prior to granting the user device access, and based on the account data and the modified set of device choices, a correct answer to the authentication question [Bustelo, para. 19 discloses the automated client interaction system can generate a response for the client using the predicted disposition classification, disposition classification probability, and a disposition classification threshold.] and compare the response to the authentication question to the correct answer. [Bustelo, para. 19 discloses the automated client interaction system can generate and provide an automated interaction response that references the predicted disposition classification in response to determining that the disposition classification probability satisfies the disposition classification threshold. In one or more embodiments, the automated client interaction system monitors interactions between client and the automated client interaction system to compare actual client dispositions with predicted client disposition classifications and further trains the machine learning model based on this comparison.]
Therefore, it would have been obvious to one of ordinary skill within the art before the effective filling date to combine Bustelo’s system with Semichev’s system with a motivation to utilizes a trained machine learning model to predict client dispositions (e.g., contact reason or contact intent) and generate automated interaction responses for client devices. [Bustelo, para. 19]
Regarding claim 18, it recites features similar to features within claim 7, therefore, it is rejected in a similar manner.
Regarding claim 20, it recites features similar to features within claim 7, therefore, it is rejected in a similar manner.
Conclusion
Pertinent prior art made of record, however, not relied upon:
US 11743330 B1 to Gilbert et al.
“Migration of a user of a computing device to accept an updated version of a software feature to the exclusion of a prior version of the software feature is implemented without user friction. Telemetry data corresponding to use of the updated version and of the prior version is stored. The telemetry data is evaluated utilizing a trained machine learning model trained using external telemetry data with respect to use of the updated version and to use of the prior version. A migration acceptance value indicative of whether the user will accept use of the updated version to exclusion of the prior version is calculated. The migration acceptance value is compared to a threshold value determined by the trained model. If the migration acceptance value exceeds the threshold value, the prior version is excluded from the user profile.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Phuc Pham whose telephone number is (571)272-8893. The examiner can normally be reached Monday - Thursday 7:30 AM - 4:30 PM; Friday 8:00 AM - 12: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, Linglan Edwards can be reached at (571) 270-5440. 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.
/P.P./Patent Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights