DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amended claims filed on 09/19/2025.
Claims 1, 7, 16 and 18 are currently amended.
Claims 3-6, 8, 13, 15, 17, 19 and 20 are canceled.
Claims 1, 2, 7, 9-12, 14, 16, and 18 are currently pending and have been examined.
Response to Arguments
Applicant's arguments filed 09/19/2025 have been fully considered but they are not persuasive.
Applicant argues that the claims amendments overcome the prior art rejection. Examiner asserts that prior art rejection has been amended and the newly cited Rathbun reference addresses claim amendments.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 9-12 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claim 9 depends on canceled claim 8. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Claims 10-12 are further rejected as they depend on claim 9.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 7, 9-12, 14, 16, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ithabathula US (2019/0164165 A1) in view of Hitchcock et al. (US 10,979,430 B1) and further in view of Rathbun (US 8,572,701)
Regarding claim 1
Ithabathula teaches:
detecting, by a first computing device of a trusted computing system, an input event indicating that an individual at the first computing device wishes to authenticate their identity via a cardless authentication process; (See Ithabathula [0070] The process of FIG. 3 may be similar to that of FIG. 2, except that in some embodiments, rather than a push notification, the communications from the mobile computing device may be tied to a transaction at interactive kiosk via a one-time code generated at the kiosk and conveyed directly wirelessly to the mobile computing device, for example, in virtue of physical proximity of the mobile computing device placing the mobile computing device within wireless range of the interactive kiosk. In some embodiments, the operations of the process 150 may be the same as those described above, in which case the same element numbers are used and the description above is incorporated.
generating, by the first computing device, an authentication request comprising a request identifier and a device identifier for the first computing device, the authentication request further specifying at least one of: (i) a required trust level, or (ii) a required capability for authenticating the individual; (See Ithabathula [0050 and 0071]
Next, in response to a transaction being initiated, for example, by the user pressing a physical token, the interactive kiosk may generate a one-time code, as indicated by block 152. In some embodiments, the one-time code may be a relatively high entropy value that is difficult to guess and that expires after some duration of time, like less than 15 minutes. Some embodiments may generate a pseudorandom value for the generated code, in some cases appending a unique identifier of the interactive kiosk to that pseudorandom value to avoid namespace conflicts with generated codes from other interactive kiosks that happen to generate the same pseudorandom value during the same duration of time in which the random values are valid.)
transmitting, by the first computing device, the authentication request, to a server of the trusted computing system (See Ithabathula [0072] Some embodiments may then send the account identifier and the generated code, and in some cases, a transaction identifier, to the account management application, as indicated by block 154. Further, some embodiments may display or otherwise wirelessly convey the code, as indicated by block 156, to the mobile computing device which may sense the code, as indicated by block 160. In some cases, sensing the code may include receiving an NFC wireless transmission via an antenna of the mobile computing device, receiving a code encoded in Bluetooth™ transmission or Wi-Fi™ transmission, or optically sensing the code via a camera of the mobile computing device and extracting the code from a machine-readable image within the display of the user interface of the interactive kiosk (e.g., in operation 156) captured by the camera of the mobile computing device. In some embodiments account management application may request authentication w/ code and account id., as indicated by block 158.
displaying, by the first computing device, a unique identifier comprising the request identifier for the authentication request on a display of the first computing device, wherein the unique identifier is embedded in at least one of a QR code or a one-time passcode; (See Ithabathula [0072] Some embodiments may then send the account identifier and the generated code, and in some cases, a transaction identifier, to the account management application, as indicated by block 154. Further, some embodiments may display or otherwise wirelessly convey the code, as indicated by block 156, to the mobile computing device which may sense the code, as indicated by block 160. In some cases, sensing the code may include receiving an NFC wireless transmission via an antenna of the mobile computing device, receiving a code encoded in Bluetooth™ transmission or Wi-Fi™ transmission, or optically sensing the code via a camera of the mobile computing device and extracting the code from a machine-readable image within the display of the user interface of the interactive kiosk (e.g., in operation 156) captured by the camera of the mobile computing device. In some embodiments account management application may request authentication w/ code and account id., as indicated by block 158.
receiving, by an authentication provider module executed on a non-trusted, the request identifier from a mobile device of the individual; (See Ithabathula [0072] (fig. 3 156, 158) [0072] In some cases, sensing the code may include receiving an NFC wireless transmission via an antenna of the mobile computing device, receiving a code encoded in Bluetooth™ transmission or Wi-Fi™ transmission, or optically sensing the code via a camera of the mobile computing device and extracting the code from a machine-readable image within the display of the user interface of the interactive kiosk (e.g., in operation 156) captured by the camera of the mobile computing device. In some embodiments account management application may request authentication w/ code and account id., as indicated by block 158.
authenticating, by the authentication provider module, and independent of the trusted computing system, the identity of the individual including verifying a first authentication token issued to the authentication provider module by a trusted identity provider of the trusted computing system; (See Ithabathula [0074] Again, and in some cases concurrently, upon sensing the code, some embodiments of the mobile computing devices client authentication application may present the user interfaces described above by which a user may configure access scope, as indicated by block 116, and sense biometric attributes, as described by block 120 The mobile computing device may verify the sensed attribute, as indicated by block 124 and, then, send a result, a device identifier, and the code, as indicated by block 124. The authentication application may receive these values, as indicated by block 162 and determine whether the received code matches a code associated with any of a plurality of request for authentication received within a threshold duration of time. Some embodiments may select the corresponding request from among the plurality of pending requests in the course of determining whether the code matches one of these requests, as indicated by block 164. Some embodiments may periodically expire pending requests older than a threshold age, e.g., by deleting a record of the older pending request from a list of pending requests interrogated to identify matches. Upon determining that there is no match, some embodiments may proceed to deny access as indicated by block 128. Alternatively, some embodiments may proceed to determine whether the device identifier of the mobile computing device matches a device identifier identified in block 112, as indicated by block 156. Upon determining that there is no match, some embodiments may proceed to deny access, as indicated by block 128. Alternatively, upon determining that the device identifiers match, some embodiments may determine whether to authenticate the user based on the result of the biometric verification, as indicated by block 126. Upon determining that the user's sensed biometric attribute was not determined to match those previously supplied, some embodiments may proceed to block 128 and deny access. Alternatively, upon determining that the biometric attribute was determined to match, some embodiments may proceed to instruct the account management application to authorize access to the secure resource, as indicated by block 132.
generating, by the authentication provider module, an authentication response comprising at least the request identifier and a customer identifier of the individual, the authentication response including the first authentication token issued by the trusted identity provider; (See Ithabathula [0074] as indicated by block 124 and, then, send a result, a device identifier, and the code, as indicated by block 124. … Alternatively, upon determining that the device identifiers match, some embodiments may determine whether to authenticate the user based on the result of the biometric verification, as indicated by block 126. Upon determining that the user's sensed biometric attribute was not determined to match those previously supplied, some embodiments may proceed to block 128 and deny access. Alternatively, upon determining that the biometric attribute was determined to match, some embodiments may proceed to instruct the account management application to authorize access to the secure resource, as indicated by block 132.
responsive to receiving the response, authenticating the identity of the individual at the first computing device. (See Ithabathula [0074] (fig. 3 132-134) [0074] Alternatively, upon determining that the biometric attribute was determined to match, some embodiments may proceed to instruct the account management application to authorize access to the secure resource, as indicated by block 132. As described above, users may be alerted to denied access, as described by block 130, or users may be provided access within the configured scope, as indicated by block 134 via the interactive kiosk and receive the secured resources, as indicated by block 136.
However, Ithabathula does not specifically teach: the server maintaining an authentication request queue accessible by authentication provider modules external to the trusted computing system; and transmitting the authentication response to an authentication response queue on the server of the trusted computing system.
However Hitchcock teaches at least at (Col 17 Lines 45-48) Similarly, the computer-facilitated service may add the request to a queue, whereby the remote authentication providers of the computing devices and/or other services may access the queue to obtain the request.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
However Hitchcock does not specifically teach transmitting the authentication response to an authentication response queue on the server of the trusted computing system; However Rathbun teach at least at (Col 13 lines 16-25) Process 700 may also include updating the queue (block 780). For example, after determining that the authentication is successful and/or after transmitting the authentication response, authentication server 140 may update the queue associated with the user. In one implementation, updating the queue may include indicating that the authentication request is no longer pending and/or that the authentication request has been successfully approved by the user. In another implementation, updating the queue may include removing the authentication request from the queue.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of authenticating via a mobile device as taught by Rathbun in order to allow a user to access a list and any other representation of pending authentication requests in the queue of the user. (Rathburnk (Col 1 lines 61-64)
Regarding claim 2
Ithabathula teaches:
wherein the first computing device is an Automated Teller Machine or a kiosk. (See Ithabathula [0059] In some embodiments, this may include a user inserting their ATM card into a card reader at an ATM machine, inserting their credit card into a credit card reader on an ATM or vending machine, or the other examples described above. In response, the interactive kiosk may read an account identifier from the presented token, as indicated by block 104 and send the account identifier to an account management application, as indicated by block 106.
Regarding claim 7
Ithabathula teaches:
wherein the unique identifier is embedded in a QR code and further comprising: (See Ithabathula [0045] For example, some embodiments may be configured to capture an image of a QR code, a barcode, or other machine-readable image on the display 38 that encodes a one-time code associated with a given presentation of the physical token 16. In some embodiments, the client authentication application 48 may receive an image captured by the camera 59 of that machine-readable image and extract the one-time code from the image, for example, by detecting reference features and, responsive to spatial arrangements of the reference features, executing perspective affine transforms and scaling transforms to normalize the image before implementing edge detection algorithms and classifying positions of edges in transformed images as designating values in a sequence of values of a one-time code associated with presentation of the physical token 16.
responsive to scanning the QR code, automatically executing a mobile banking application on the mobile device and initiating an authentication process in the mobile banking application. [0072] Some embodiments may then send the account identifier and the generated code, and in some cases, a transaction identifier, to the account management application, as indicated by block 154. Further, some embodiments may display or otherwise wirelessly convey the code, as indicated by block 156, to the mobile computing device which may sense the code, as indicated by block 160. In some cases, sensing the code may include receiving an NFC wireless transmission via an antenna of the mobile computing device, receiving a code encoded in Bluetooth™ transmission or Wi-Fi™ transmission, or optically sensing the code via a camera of the mobile computing device and extracting the code from a machine-readable image within the display of the user interface of the interactive kiosk (e.g., in operation 156) captured by the camera of the mobile computing device. In some embodiments account management application may request authentication w/ code and account id., as indicated by block 158.
Regarding claim 9
Ithabathula does not specifically teach: obtaining details of the authentication request from the authentication request queue using the request identifier.
However, Hitchcock Teaches:
obtaining details of the authentication request from the authentication request queue using the request identifier. (Col 17 Lines 45-48) Similarly, the computer-facilitated service may add the request to a queue, whereby the remote authentication providers of the computing devices and/or other services may access the queue to obtain the request.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
Regarding claim 10
Ithabathula does not specifically teach: wherein the step of authenticating, by the authentication provider module, the identity of the individual comprises: responsive to receiving, at the authentication provider module, the details of the authentication request, transmitting a notification to the mobile device requesting the individual to confirm that they are attempting to authenticate their identity at the first computing device.
However, Hitchcock Teaches:
wherein the step of authenticating, by the authentication provider module, the identity of the individual comprises: responsive to receiving, at the authentication provider module, the details of the authentication request, transmitting a notification to the mobile device requesting the individual to confirm that they are attempting to authenticate their identity at the first computing device. (Col 17 lines 17-48) Based at least in part on the entries specified in the user's customer profile, the computer-facilitated service may select 414 one or more authentication methods to be performed by one or more computing devices and/or other services utilized by the user. For instance, the computer-facilitated service may select one or more computing devices and/or other services utilized by the user from the user's customer profile. The computer-facilitated service may evaluate the entries corresponding to the selected one or more computing devices and/or other service to select the authentication methods that may be executed by the selected one or more computing devices and/or other services. In some instances, the computer-facilitated service may select an authentication method and identify any computing devices or other services that may execute the selected authentication method. From these identified devices or services, the computer-facilitated service may select a subset of computing devices and services that are to perform the authentication method selected. The computer-facilitated service may transmit 416 the request to perform additional authentication of the user using the selected one or more methods to the selected computing devices and/or services. It should be noted that the computer-facilitated service may use alternate methods to cause the remote authentication providers to perform the selected authentication method. For instance, the computer-facilitated service may transmit the request to perform the selected authentication methods to a server, which may provide the request to the remote authentication providers. Similarly, the computer-facilitated service may add the request to a queue, whereby the remote authentication providers of the computing devices and/or other services may access the queue to obtain the request.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
Regarding claim 11
Ithabathula does not specifically teach: responsive to the individual responding to the notification transmitted to the mobile device, receiving, at the authentication provider module, a confirmation notification that the individual wishes to authenticate their identity at the first computing device.
However, Hitchcock Teaches:
responsive to the individual responding to the notification transmitted to the mobile device, receiving, at the authentication provider module, a confirmation notification that the individual wishes to authenticate their identity at the first computing device. (Col 18 lines 30-52) As noted above, in response to a request from a computer-facilitated service to perform an authentication method selected by the computer-facilitated service, a computing device or other service may utilize its authentication provider to execute the selected authentication method to determine whether the user can be authenticated and generate an authentication decision. In some embodiments, if the authentication provider cannot execute the selected authentication method, the authentication provider selects an alternative authentication method and authenticates the user utilizing this method. The authentication provider may provide an authentication decision generated using this alternative authentication method to the computer-facilitated service, which may determine whether the utilized method is acceptable. Accordingly, FIG. 5 shows an illustrative example of a process 500 for authenticating a user using an authentication method specified by a computer-facilitated service and providing an authentication decision to the computer-facilitated service in accordance with at least one embodiment. The process 500 may be performed by an authentication provider of a computing device or other service selected by a computer-facilitated service to perform a selected authentication method.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
Regarding claim 12
Ithabathula does not specifically teach: determining, by the authentication provider module, that the authentication request requires multi-factor authentication to be performed; and responsive to said determining, requesting the individual to perform biometric authentication at the mobile device when sending the notification.
However, Hitchcock Teaches:
determining, by the authentication provider module, that the authentication request requires multi-factor authentication to be performed; and (Col 16 lines 43-57) If the user is authenticated by the authentication provider of the computer-facilitated service, the computer-facilitated service may determine 408 whether additional authentication is required for the user. For instance, based at least in part on the resources selected by the user, the computer-facilitated service may require additional authentication before enabling the user to access these resources. Alternatively, the user's customer profile may specify that additional authentication is required for the user in order to enable the user to access the requested resources. In some instances, the computer-facilitated service may require additional authentication for all requests. If the computer-facilitated service determines that no additional authentication is required, the computer-facilitated service may enable 410 the user to access the requested resources.
responsive to said determining, requesting the individual to perform biometric authentication at the mobile device when sending the notification. (Col 18 lines 30-52) As noted above, in response to a request from a computer-facilitated service to perform an authentication method selected by the computer-facilitated service, a computing device or other service may utilize its authentication provider to execute the selected authentication method to determine whether the user can be authenticated and generate an authentication decision. In some embodiments, if the authentication provider cannot execute the selected authentication method, the authentication provider selects an alternative authentication method and authenticates the user utilizing this method. The authentication provider may provide an authentication decision generated using this alternative authentication method to the computer-facilitated service, which may determine whether the utilized method is acceptable. Accordingly, FIG. 5 shows an illustrative example of a process 500 for authenticating a user using an authentication method specified by a computer-facilitated service and providing an authentication decision to the computer-facilitated service in accordance with at least one embodiment. The process 500 may be performed by an authentication provider of a computing device or other service selected by a computer-facilitated service to perform a selected authentication method.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
Regarding claim 14
Ithabathula teaches:
providing a second authentication token, issued by a trusted identity provider module of the trusted computing system, to the authentication provider module; (See at least Ithabathula [0072] Some embodiments may then send the account identifier and the generated code, and in some cases, a transaction identifier, to the account management application, as indicated by block 154. Further, some embodiments may display or otherwise wirelessly convey the code, as indicated by block 156, to the mobile computing device which may sense the code, as indicated by block 160. In some cases, sensing the code may include receiving an NFC wireless transmission via an antenna of the mobile computing device, receiving a code encoded in Bluetooth™ transmission or Wi-Fi™ transmission, or optically sensing the code via a camera of the mobile computing device and extracting the code from a machine-readable image within the display of the user interface of the interactive kiosk (e.g., in operation 156) captured by the camera of the mobile computing device. In some embodiments account management application may request authentication w/ code and account id., as indicated by block 158.
when transmitting the response to the authentication request to the server, providing the second authentication token; and (See at least Ithabathula [0074] (fig 3, 124 and 162) [0074] Again, and in some cases concurrently, upon sensing the code, some embodiments of the mobile computing devices client authentication application may present the user interfaces described above by which a user may configure access scope, as indicated by block 116, and sense biometric attributes, as described by block 120 The mobile computing device may verify the sensed attribute, as indicated by block 124 and, then, send a result, a device identifier, and the code, as indicated by block 124. The authentication application may receive these values, as indicated by block 162 and determine whether the received code matches a code associated with any of a plurality of request for authentication received within a threshold duration of time.
authenticating, by the server, the second authentication token to authenticate the authentication provider module. (See at least Ithabathula [0074] (fig 3, 164, 166, and 126) [0074] Some embodiments may select the corresponding request from among the plurality of pending requests in the course of determining whether the code matches one of these requests, as indicated by block 164. Some embodiments may periodically expire pending requests older than a threshold age, e.g., by deleting a record of the older pending request from a list of pending requests interrogated to identify matches. Upon determining that there is no match, some embodiments may proceed to deny access as indicated by block 128. Alternatively, some embodiments may proceed to determine whether the device identifier of the mobile computing device matches a device identifier identified in block 112, as indicated by block 156. Upon determining that there is no match, some embodiments may proceed to deny access, as indicated by block 128. Alternatively, upon determining that the device identifiers match, some embodiments may determine whether to authenticate the user based on the result of the biometric verification, as indicated by block 126. Upon determining that the user's sensed biometric attribute was not determined to match those previously supplied, some embodiments may proceed to block 128 and deny access. Alternatively, upon determining that the biometric attribute was determined to match, some embodiments may proceed to instruct the account management application to authorize access to the secure resource, as indicated by block 132. As described above, users may be alerted to denied access, as described by block 130, or users may be provided access within the configured scope, as indicated by block 134 via the interactive kiosk and receive the secured resources, as indicated by block 136.
Regarding claim 16
Ithabathula does not specifically teach: monitoring, by the first computing device, the authentication response queue for responses to authentication requests generated by the first computing device.
However, Hitchcock Teaches:
monitoring, by the first computing device, the authentication response queue for responses to authentication requests generated by the first computing device. (Col 17 lines 17-48) Based at least in part on the entries specified in the user's customer profile, the computer-facilitated service may select 414 one or more authentication methods to be performed by one or more computing devices and/or other services utilized by the user. For instance, the computer-facilitated service may select one or more computing devices and/or other services utilized by the user from the user's customer profile. The computer-facilitated service may evaluate the entries corresponding to the selected one or more computing devices and/or other service to select the authentication methods that may be executed by the selected one or more computing devices and/or other services. In some instances, the computer-facilitated service may select an authentication method and identify any computing devices or other services that may execute the selected authentication method. From these identified devices or services, the computer-facilitated service may select a subset of computing devices and services that are to perform the authentication method selected. The computer-facilitated service may transmit 416 the request to perform additional authentication of the user using the selected one or more methods to the selected computing devices and/or services. It should be noted that the computer-facilitated service may use alternate methods to cause the remote authentication providers to perform the selected authentication method. For instance, the computer-facilitated service may transmit the request to perform the selected authentication methods to a server, which may provide the request to the remote authentication providers. Similarly, the computer-facilitated service may add the request to a queue, whereby the remote authentication providers of the computing devices and/or other services may access the queue to obtain the request.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the cross-device multifactor authentication for interactive kiosks of Ithabathula in view of service initiated use authentication via delegated methods as taught by Hitchcock in order to allow a service may determine whether additional authentication is required in order to enable the user to access the requested resources. (Hitchcock (Col 2 lines 11-14)
Regarding claim 18
Ithabathula teaches:
generating the response to the authentication request as a set of data comprising at least the request identifier and a customer identifier for the individual. [0074] Again, and in some cases concurrently, upon sensing the code, some embodiments of the mobile computing devices client authentication application may present the user interfaces described above by which a user may configure access scope, as indicated by block 116, and sense biometric attributes, as described by block 120 The mobile computing device may verify the sensed attribute, as indicated by block 124 and, then, send a result, a device identifier, and the code, as indicated by block 124. The authentication application may receive these values, as indicated by block 162 and determine whether the received code matches a code associated with any of a plurality of request for authentication received within a threshold duration of time. Some embodiments may select the corresponding request from among the plurality of pending requests in the course of determining whether the code matches one of these requests, as indicated by block 164. Some embodiments may periodically expire pending requests older than a threshold age, e.g., by deleting a record of the older pending request from a list of pending requests interrogated to identify matches. Upon determining that there is no match, some embodiments may proceed to deny access as indicated by block 128. Alternatively, some embodiments may proceed to determine whether the device identifier of the mobile computing device matches a device identifier identified in block 112, as indicated by block 156. Upon determining that there is no match, some embodiments may proceed to deny access, as indicated by block 128. Alternatively, upon determining that the device identifiers match, some embodiments may determine whether to authenticate the user based on the result of the biometric verification, as indicated by block 126. Upon determining that the user's sensed biometric attribute was not determined to match those previously supplied, some embodiments may proceed to block 128 and deny access. Alternatively, upon determining that the biometric attribute was determined to match, some embodiments may proceed to instruct the account management application to authorize access to the secure resource, as indicated by block 132. As described above, users may be alerted to denied access, as described by block 130, or users may be provided access within the configured scope, as indicated by block 134 via the interactive kiosk and receive the secured resources, as indicated by block 136.
Prior Art of Record Not Currently Relied Upon
Li et al. (US 2018/047288 A1) Teaches: method for making payment for a service at a service station.
Jain et al. (US 2022/00145517 A1) Teaches: Self federation in authentication systems.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
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, Ryan Donlon can be reached at 571-270-3602. 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692