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
2. This action is in response to the application filed May 23, 2025.
3. Claims 1-20 have been examined and are pending with this action.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
4. Claims 7 and 9-10 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Le Saint et al. (US 2020/0177583 A1).
As per claim 7, Le Saint teaches an authentication method comprising:
generating, by an authentication server, an authentication token to authenticate a user on an application in response to an authentication request (see Le Saint, [0006]: “The primary device may then generating the cryptogam by encrypting data pertaining to the request for authorization using the decrypted cryptogram key”; [0071]: “To request authorization to use an account associated with a user, primary device 401 may provide a token or an account identifier to access device 460”; [0081]: “In some embodiments, authorization server 580 can be a token server that manages and provisions tokens to communication devices. The provision request may include the device ID of primary device 501, an account identifier to identify the account for which the account credentials are being requested, and device data such as the device ID of secondary device 512.”; and [0082]: “authentication server 580 can generate a shared key for primary device 501 and account credentials for the account. In some embodiments, the shared key can be generated using a protocol such as elliptic curve Diffie-Hellman. The account credentials may include a token that can be used as a substitute for the account identifier and/or a cryptogram key that can be used by primary device to generate a cryptogram when requesting authorization to use the account”);
partitioning the authentication token to create a first token portion and a second token portion (see Le Saint, [0094]: “The secondary device assisted credential storage techniques described above need not be limited to just using one secondary device, and can also be extended to multiple secondary devices. In some embodiments, the primary device can be provisioned with a different set of account credentials (e.g., token and/or cryptogram key) for each secondary device in a set of secondary devices registered with the authorization server. For example, a different token and/or a different cryptogram key can be generated by the authorization server for each secondary device”; [0096]: “As another example, a token can be split into two portions, and the first token portion can be encrypted using a first key-encryption key derived from the device data of a first secondary device, and the second token portion can be encrypted using a second key-encryption key derived from the device data of a second secondary device.”; and [0123]: “The cryptogram key can be partitioned into a first portion and a second portion”);
selecting a first user device and a second user device from a stored list of two or more devices associated with the user based on the authentication request (see Le Saint, [0076]: “In FIG. 4B, a user may be operating primary device 401 in the presence of an additional communication device that has previously been registered with authorization server 480. The additional communication device can be a secondary device 412 acting as a credential device that provides credential data to primary device 401”; [0077]: “The scenario in FIG. 4C is similar to that of FIG. 4B except that a third communication device (may be referred to as a “tertiary device”) previously registered with authorization server 480 is acting as a user interface device to control or instruct primary device”; Claim 1 rejection above);
transmitting the first token portion to the first user device and the second token portion to the second user device (see Le Saint, [0081]: “In some embodiments, authorization server 580 can be a token server that manages and provisions tokens to communication devices.”; [0084]: “At step 536, authentication server 580 sends the encrypted account credentials and the shared key associated with primary device 501 to primary device 501. At step 538, primary device 501 stores the shared key on primary device 501. In some embodiments, primary device 501 may also store the encrypted account credentials, or part of the encrypted account credentials (e.g., only the encrypted token, only the encrypted cryptogram key, a portion of the encrypted token, a portion of the encrypted cryptogram key, or portions of both) on primary device 501… At step 542, secondary device 512 stores the encrypted account credentials (e.g., full or partial) received from primary device 501 on secondary device 512… authentication server 580 may send the portion of the account credentials to be stored on secondary device 512 directly to secondary device 512, and may omit sending that portion of the account credentials to primary device 501.”; and [0123]: “In some embodiments, the primary device may also receive a toke”);
receiving an input of the first token portion and the second token portion (see Le Saint, [0096]: “As another example, a token can be split into two portions, and the first token portion can be encrypted using a first key-encryption key derived from the device data of a first secondary device, and the second token portion can be encrypted using a second key-encryption key derived from the device data of a second secondary device”; and [0120]: “Once the primary device and secondary device have been provision, the primary device may interact with an access device to request authorization to use an account associated with the user of the primary device. At block 1208, the primary device may receive credential data of the secondary device. The credential data may include the device data of the secondary device that was used to derive the key-encryption key such as the device ID of the secondary device. If any part of the encrypted cryptogram key and/or encrypted token is stored on the secondary device, the primary device may also receive the encrypted cryptogram key and/or encrypted token from the secondary device as part of the credential data of the secondary device”); and
transmitting instructions to authenticate the user (see Le Saint, [0072]: “if the recent device data (e.g., device IDs and/or contextual data) received from primary device 401 is similar to the historic interaction activity pattern for the time of day, then the confidence that primary device 401 is being operated by its authorized user would be high, and authorization server 480 may grant authorization to use the user's account”; and [0091]: “If the regenerated cryptogram matches the cryptogram received from primary device 601, the authorization server can grant the authorization to use the account”).
As per claim 9, which depends on claim 7, Le Saint further teaches wherein the authentication request associated with the user is received from a third user device of the two or more devices (see Le Saint, [0077]: “FIG. 4C illustrates another scenario in which an additional communication device is used to increase the confidence that the user using primary device 401 is an authorized user, according to some embodiments. The scenario in FIG. 4C is similar to that of FIG. 4B except that a third communication device (may be referred to as a “tertiary device”) previously registered with authorization server 480 is acting as a user interface device to control or instruct primary device 401. In FIG. 4C, the user is initiating the request for authorization to use the account associated with the user from tertiary device 413 instead of primary device 401”).
As per claim 10, which depends on claim 7, Le Saint further teaches wherein the application comprises a graphical user interface (GUI) to provide a display to the user, the GUI comprising an authentication input field (see Le Saint, [0077]: “Tertiary device 413 can be used, for example, to provide an alternative user interface that what is available on primary device 401, when it is more convenient for the user to physically interact with tertiary device 412, or if the primary device 401 does not have its own user interface. The presence of the third communication device further increases the confidence that the user is an authorized user because the user is in possession of three devices associated with the account holder.”).
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.
5. Claims 1-6, 8, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Le Saint et al. (US 2020/0177583 A1) in view of Rossman et al. (US 2019/0268342 A1).
INDEPENDENT:
As per claim 1, Le Saint teaches an authentication method comprising:
receiving, from an application in communication with an authentication server, an authentication request associated with a user (see Le Saint, [0033]: “The server computer may be coupled to a database and may include any hardware, software, other logic, or combination of the preceding for servicing the requests from one or more client computers. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers”; [0039]: “An “authorization request message” may be an electronic message that is sent to request authorization for a transaction. The authorization request message can be sent to a transaction processing network and/or an issuer of a transaction card (e.g., a payment card)… ”; and [0070]: “a user may operate a primary device 401 to communicate with an access device 460 to perform a security sensitive operation such as requesting authorization to use an account associated with a user of the primary device 401”);
generating, by the authentication server, an authentication token to authenticate the user on the application (see Le Saint, [0006]: “The primary device may then generating the cryptogam by encrypting data pertaining to the request for authorization using the decrypted cryptogram key”; [0071]: “To request authorization to use an account associated with a user, primary device 401 may provide a token or an account identifier to access device 460”; [0081]: “In some embodiments, authorization server 580 can be a token server that manages and provisions tokens to communication devices. The provision request may include the device ID of primary device 501, an account identifier to identify the account for which the account credentials are being requested, and device data such as the device ID of secondary device 512.”; and [0082]: “authentication server 580 can generate a shared key for primary device 501 and account credentials for the account. In some embodiments, the shared key can be generated using a protocol such as elliptic curve Diffie-Hellman. The account credentials may include a token that can be used as a substitute for the account identifier and/or a cryptogram key that can be used by primary device to generate a cryptogram when requesting authorization to use the account”);
partitioning the authentication token to create a first token portion and a second token portion (see Le Saint, [0094]: “The secondary device assisted credential storage techniques described above need not be limited to just using one secondary device, and can also be extended to multiple secondary devices. In some embodiments, the primary device can be provisioned with a different set of account credentials (e.g., token and/or cryptogram key) for each secondary device in a set of secondary devices registered with the authorization server. For example, a different token and/or a different cryptogram key can be generated by the authorization server for each secondary device”; [0096]: “As another example, a token can be split into two portions, and the first token portion can be encrypted using a first key-encryption key derived from the device data of a first secondary device, and the second token portion can be encrypted using a second key-encryption key derived from the device data of a second secondary device.”; and [0123]: “The cryptogram key can be partitioned into a first portion and a second portion”);
transmitting the first token portion to the first user device and the second token portion to the second user device (see Le Saint, [0081]: “In some embodiments, authorization server 580 can be a token server that manages and provisions tokens to communication devices”; [0084]: “At step 536, authentication server 580 sends the encrypted account credentials and the shared key associated with primary device 501 to primary device 501. At step 538, primary device 501 stores the shared key on primary device 501. In some embodiments, primary device 501 may also store the encrypted account credentials, or part of the encrypted account credentials (e.g., only the encrypted token, only the encrypted cryptogram key, a portion of the encrypted token, a portion of the encrypted cryptogram key, or portions of both) on primary device 501… At step 542, secondary device 512 stores the encrypted account credentials (e.g., full or partial) received from primary device 501 on secondary device 512… authentication server 580 may send the portion of the account credentials to be stored on secondary device 512 directly to secondary device 512, and may omit sending that portion of the account credentials to primary device 501”; and [0123]: “In some embodiments, the primary device may also receive a token”);
receiving, from the application, an input of the first token portion and the second token portion (see Le Saint, [0096]: “As another example, a token can be split into two portions, and the first token portion can be encrypted using a first key-encryption key derived from the device data of a first secondary device, and the second token portion can be encrypted using a second key-encryption key derived from the device data of a second secondary device”; and [0120]: “Once the primary device and secondary device have been provision, the primary device may interact with an access device to request authorization to use an account associated with the user of the primary device. At block 1208, the primary device may receive credential data of the secondary device. The credential data may include the device data of the secondary device that was used to derive the key-encryption key such as the device ID of the secondary device. If any part of the encrypted cryptogram key and/or encrypted token is stored on the secondary device, the primary device may also receive the encrypted cryptogram key and/or encrypted token from the secondary device as part of the credential data of the secondary device”); and
transmitting instructions to the application to authenticate the user (see Le Saint, [0072]: “if the recent device data (e.g., device IDs and/or contextual data) received from primary device 401 is similar to the historic interaction activity pattern for the time of day, then the confidence that primary device 401 is being operated by its authorized user would be high, and authorization server 480 may grant authorization to use the user's account”; and [0091]: “If the regenerated cryptogram matches the cryptogram received from primary device 601, the authorization server can grant the authorization to use the account”).
Le Saint does not explicitly teach determining, based on a priority order of two or more user devices associated with the user, that a first user device has a higher priority than a second user device.
Rossman explicitly teach determining, based on a priority order of two or more user devices associated with the user, that a first user device has a higher priority than a second user device (see Rossman, [0027]: “The request or call can be received to an API for the environment, for example, and can relate to a task to be performed using the one or more resources. A component receiving the request, directly or indirectly, can determine 304 that at least one quorum rule applies for the task or type of access corresponding to the request. In some embodiments a quorum manager or other such service can maintain a list or mapping of quorum rules for specific tasks, resources, access, etc.”; and [0040]: “If order matters, the token also can include information about the order, or at least indicate that the signatures or requests were received in the appropriate order. A resource or service receiving the token with a request can determine how to process the request based on the information”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Le Saint in view of Rossman by implementing, determining, based on a priority order of two or more user devices associated with the user, that a first user device has a higher priority than a second user device. One would be motivated to do so because Le Saint teaches in paragraph [0058], “Interaction activity pattern 300 may provide a correlation between each time period of the day (e.g., early morning, morning, midday, afternoon, evening, etc.) and device data associated with the communication devices that interacted with each other during the particular time period. Although the time of day 310 shown in FIG. 3 is divided into five different time periods, it should be understood that in some embodiments, a finer granularity of time periods (e.g., each hour of the day representing a time period) or a coarser granularity of time periods (e.g., morning, day, and night) can be used”, and in paragraph [0076], “In FIG. 4B, a user may be operating primary device 401 in the presence of an additional communication device that has previously been registered with authorization server 480. The additional communication device can be a secondary device 412 acting as a credential device that provides credential data to primary device 401”.
As per claim 15, Le Saint teaches an authentication method comprising:
generating an authentication token to authenticate a user of an application in response to an authentication request (see Claim 1 rejection above);
partitioning the authentication token to create a first token portion and a second token portion (see Claim 1 rejection above);
selecting a first user device and a second user device from the stored list of the two or more devices based on the comparison of the metadata (see Claim 1 rejection above);
transmitting the first token portion to the first user device and the second token portion to the second user device (see Claim 1 rejection above);
receiving an input of the first token portion and the second token portion (see Claim 1 rejection above); and
transmitting instructions to authenticate the user (see Claim 1 rejection above).
Le Saint does not explicitly teach comparing metadata from the authentication request to metadata from a stored list of two or more devices associated with the user.
Rossman teaches comparing metadata from the authentication request to metadata from a stored list of two or more devices associated with the user (see Rossman, [0026]: “Various quorum criteria can be specified that are compared against metadata for the signatories, approving signatures, or received requests to determine whether those criteria are satisfied.”; and [0040]: “the quorum token or quorum metadata can travel with the information for the request for at least a portion of the processing for the request. Such functionality enables the identity of the signatories to be tracked at each level of the processing, making those parties culpable for the actions but also enabling each of those parties to audit each of the actions taken under their signature. Further, in at least some embodiments one of the possible signatories can deny the action or indicate that the request should not be authorized, which can cause the request to be denied or at least limit the type(s) of functionality available for processing the request”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Le Saint in view of Rossman by implementing, comparing metadata from the authentication request to metadata from a stored list of two or more devices associated with the user. One would be motivated to do so because Rossman teaches in paragraph [0040], “Such functionality enables the identity of the signatories to be tracked at each level of the processing, making those parties culpable for the actions but also enabling each of those parties to audit each of the actions taken under their signature”.
DEPENDENT:
As per claims 2, 8, and 16, which respectively depend on claims 1, 7, and 15, Rossman teaches further comprising:
determining an order of tokens based on the priority order (see Rossman, [0040]: “If order matters, the token also can include information about the order, or at least indicate that the signatures or requests were received in the appropriate order. A resource or service receiving the token with a request can determine how to process the request based on the information”); and
determining that the input of the first token portion and the second token portion matches the order prior to transmitting instructions to authenticate the user (see Rossman, [0040]: “the quorum token or quorum metadata can travel with the information for the request for at least a portion of the processing for the request. Such functionality enables the identity of the signatories to be tracked at each level of the processing, making those parties culpable for the actions but also enabling each of those parties to audit each of the actions taken under their signature. Further, in at least some embodiments one of the possible signatories can deny the action or indicate that the request should not be authorized, which can cause the request to be denied or at least limit the type(s) of functionality available for processing the request”).
As per claim 3, which depends on claim 1, further teaches wherein the two or more user devices comprise a third user device associated with the user, and the determining based on the priority order comprises determining that the first user device and the second user device have a higher priority than the third user device (Implicit: see Claim 1 rejection above).
As per claims 4 and 18, which respectively depend on claims 1 and 15, further teaches wherein the application comprises a graphical user interface (GUI) to provide a display to the user, the GUI comprising an authentication input field (see Claim 10 rejection above), and
the priority order is based on a probability that the user is in possession of each of the two or more user devices (see Le Saint, [0049]: “A user may also develop a pattern of connecting the smart phone to a wireless speaker to play music around dinner time each evening. Such behavioral pattern of how the communication device is operated and how the communication device interacts with other devices can be tracked over time to establish an interaction activity pattern of the communication device”; [0050]: “Mobile device 101 may interact with a different communication device at different times, and/or simultaneously interact with more than one communication device at a time”; and [0057]: “This interaction activity pattern can be learned over time, and can be used as a digital persona to authenticate the user and the communication devices of the user as discussed further below”; and [0068]: “the authorization server can utilize the interaction activity pattern to provide enhance authentication for the user and his/her communication devices. In some embodiments, the authorization server may also analyze trends in correlations between the device data and the different time periods to account for shifts in the user's behavior over time, and adjust or update the interaction activity pattern accordingly”).
As per claims 5, 13, and 19, which respectively depend on claims 1, 7, and 15, Rossman teaches further comprising:
designating an order of the first token portion and the second token portion such that, when input, the order of the first token portion and the second token portion corresponds to the authentication token (see Rossman, [0040]: “If order matters, the token also can include information about the order, or at least indicate that the signatures or requests were received in the appropriate order. A resource or service receiving the token with a request can determine how to process the request based on the information”); and
prior to transmitting instructions to authenticate the user, determining that the input of the first token portion and the second token portion matches the order (see Rossman, [0040]: “the quorum token or quorum metadata can travel with the information for the request for at least a portion of the processing for the request. Such functionality enables the identity of the signatories to be tracked at each level of the processing, making those parties culpable for the actions but also enabling each of those parties to audit each of the actions taken under their signature. Further, in at least some embodiments one of the possible signatories can deny the action or indicate that the request should not be authorized, which can cause the request to be denied or at least limit the type(s) of functionality available for processing the request”).
As per claims 6, 14, and 20, which respectively depend on claims 5, 13, and 19, Le Saint teaches further comprising displaying the order of the first token portion and the second token portion in the application (see Le Saint, [0097]: “and the second secondary device may provide the first portion of account credentials and device data of the second secondary device to the primary device. The primary device, having knowledge of the mapping of which portion of the account credentials are stored on which secondary device, can then use the device data received from the first secondary device to decrypt the portion of the account credentials received from the second secondary device, and use the device data received from the second secondary device to decrypt the portion of the account credentials received from the first secondary device”; [0128]: “User interface 1406 can include any combination of input and output elements to allow a user to interact with and invoke the functionalities of portable communication device 1401. In some embodiments, display screen 1407 may be part of user interface 1406”).
As per claim 17, which depends on claim 15, further teaches wherein the authentication request associated with the user is received from a third user device of the two or more devices (see Claim 9 rejection above).
6. Claims 11 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Le Saint et al. (US 2020/0177583 A1) and Rossman et al. (US 2019/0268342 A1), and still further in view of Pathak et al. (US 2018/0060395 A1)
As per claim 11, which depends on claim 7, although Rossman teaches further comprising: comparing, metadata from the authentication request to metadata from the stored list of the two or more devices (see Claim 15 rejection above), neither Le Saint nor Rossman explicitly teach the comparing being performed by a machine learning algorithm.
Pathak teaches comparing being performed by a machine learning algorithm (see Pathak, [0067]: “Completion model training 950 may apply different types of machine learning techniques to generate and update query completion model(s) 920. For instance, the information related to a prior query (e.g., execution metadata, including the query execution plan, execution costs, etc., and table metadata, including number of rows in access tables) may be used to generate feature vectors that create a feature space for performing comparisons with newly received queries, in one embodiment”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Le Saint and Rossman in view of Pathak so that the comparing being performed by a machine learning algorithm. One would be motivated to do so because machine learning is well-known, widely-implemented, routine, and conventional for processing outputs and predictions based on inputs such as request events.
As per claims 12, which depends on claim 11, Le Saint further teaches wherein the selecting comprises selecting, by maximizing a score, the first user device and the second user device that contain the highest probability that the user is in possession (see Le Saint, [0157]: “Transaction processing network 1784 then forwards the authorization response message back to acquirer 1774. In some embodiments, transaction processing network 1084 may decline the transaction even if issuer or host processing system 1772 has authorized the transaction, for example depending on a value of a fraud risk score or depending if limited-use account parameters are verified by CBP 1780.”).
Conclusion
7. For the reasons above, claims 1-20 have been rejected and remain pending.
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Won/Primary Examiner, Art Unit 2443
