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
Response to Arguments
In communications filed on 5/18/2026, claims 1-5, 7-13, and 15-20 are presented for examination. Claims 1, 9, and 17 are independent.
Amended claim(s): 1, 5, 9, 13, 17, and 20.
Applicants’ arguments, see Applicant Arguments/Remarks filed 5/18/2026, with respect to claim(s) rejected under prior art have been considered but are moot in view of new ground(s) of rejection necessitated by Applicants’ amendment to the claim(s).
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.
Claim(s) 1-5, 7-13, and 15-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20220070151 A1 (hereinafter ‘Chauhan’) in view of US 20140138435 A1 (hereinafter ‘Khalid’) in view of US 20170116603 A1 (hereinafter ‘Bogard’) in view of US 20090260064 A1 (hereinafter ‘McDowell’).
As regards claim 1, Chauhan (US 20220070151 A1) discloses A system for device authentication verification via electronic communication, the system comprising: a processing device; (Chauhan, ¶4-¶5, i.e., system/method of user and device authentication)
a non-transitory storage device containing instructions when executed by the processing device, causes the processing device to perform the steps of: receive an interaction from a resource container, wherein the interaction is associated with an application; (Chauhan: Fig. 12, ¶168, i.e., interaction of user with an application for authentication with an application server)
However, Chauhan does not but in analogous art, Khalid (US 20140138435 A1) teaches: wherein the resource is a bank card (Kahlid: Fig. 1, ¶13-¶15, i.e., information transferred between a contactless card and a user’s mobile device via NFC)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Chauhan to include information transferred between a contactless card and a user’s mobile device via NFC as taught by Khalid with the motivation to transfer account and transaction information to the mobile device (Kahlid: Fig. 1, ¶13-¶15)
Chauhan et al combination further teaches: transmit a token from an authorization hub to a user device; (Chauhan: Fig. 12, ¶168, i.e., receiving a token from the application server)
transmit, via the application, a near field communication (NFC) request to the user device; (Chauhan: Fig. 12, ¶168, i.e., receiving user data through an NFC or Bluetooth interface. See also, Khalid: Fig. 1, ¶13-¶15, ¶43, i.e., information transferred between a contactless card and a user’s mobile device via NFC)
receive user data from the resource container associated with a user, wherein the user data is received via a NFC device embedded in the resource container, and wherein the NFC device emits NFC signals; (Chauhan: Fig. 12, ¶168, i.e., receiving user data through an NFC or Bluetooth interface. See also, Khalid: Fig. 1, ¶13-¶15, i.e., information transferred between a contactless card and a user’s mobile device via NFC)
validate the user data using the authorization hub; and (Chauhan: ¶168, i.e., verifying user data by the application server)
However, Chauhan does not but in analogous art, Bogard (US 20170116603 A1) teaches: encrypt the user data using the token; (Bogard, Figs. 5-7, ¶159-¶164, ¶178, i.e., storing the user specific data using the device specific “app” (i.e., token) provided to the user device by the authentication/provider computer wherein the app performs encryption/decryption of user data) store an identifier of the user device such that the user device is electronically stored as a verified user device. (Bogard: Figs. 7, 10, ¶192-195, i.e., the provider/authentication computer storing the user ID, device ID, token, etc)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Chauhan to include providing a device specific “app” to enable user device to securely store user data and to register the user device in the provider/authentication computer system as taught by Bogard with the motivation to provide secure NFC based transactions (Bogard: ¶25)
Chauhan et al combination further teaches: in the authorization hub, and wherein storing the user device as the verified user device further comprises bypassing verification of future interactions associated with the user device. (McDowell: Figs. 2-3, ¶10, i.e., device IDs are registered in advance with the transaction server and during subsequent transaction if the device IDs match with the stored device IDs then no verification is required)
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to modify Chauhan et al to include registering device devices with a transaction system in advance to avoid subsequent verification as taught by McDowell with the motivation to dictate the eligibility and scope of transactions allowed by a device (McDowell: ¶23)
Claims 9 and 17 recite substantially the same features as recited in claim 1 above and are rejected based on the same rationale discussed in the rejection.
As regards claim 2, Chauhan et al combination teaches the system of claim 1, wherein the authorization hub is configured to: manage access control policies, wherein the access control policies define user access permissions; (Chauhan: Fig. 2, ¶53-¶55, i.e., the management of access/permission policies) authenticate the user data, wherein authenticating the user data comprises validating the user data associated with the NFC signals; and (Chauhan: Fig. 12, ¶168, i.e., authentication via prompting of the nfc interface) authorize the interaction, wherein authorizing the interaction comprises comparing the user data with the access control policies to determine an access level associated with the user device. (Chauhan: ¶74, i.e., level of access is based on strength of the authentication)
Claims 10 and 18 recite substantially the same features as recited in claim 2 above and are rejected based on the same rationale discussed in the rejection.
As regards claim 3, Chauhan et al combination teaches the system of claim 1, wherein executing the instructions further causes the processing device to: receive the NFC signals emitted from the NFC device; (Chauhan: Fig. 12, ¶168, i.e., authentication via prompting of the nfc interface) generate a user prompt, wherein the user prompt requests the user to enter a user input via the user device; (Chauhan: Fig. 12, ¶168, i.e., authentication via prompting of the nfc interface) receive the user input, wherein the user input comprises a personal identification number (PIN) associated with the user; and (Chauhan: Fig. 12, ¶168, i.e., authentication via prompting of the nfc interface and receiving credential data) validate the user input using the authorization hub. (Chauhan: ¶168, i.e., verifying user data by the application server)
Claims 11 and 19 recite substantially the same features as recited in claim 3 above and are rejected based on the same rationale discussed in the rejection.
As regards claim 4, Chauhan et al combination teaches the system of claim 1, wherein the interaction further comprises a resource transaction, and wherein the resource transaction exceeds a threshold value. (Chauhan: ¶160-¶168)
Claim 12 recites substantially the same features as recited in claim 4 above and is rejected based on the same rationale discussed in the rejection.
As regards claim 5, Chauhan et al combination teaches the system of claim 1, wherein encrypting the user data using the token further comprises: requesting, via the application, the token from the authorization hub; (Chauhan: Fig. 12, ¶168, i.e., receiving a token from the application server in response to authentication) generating, via the authorization hub, the token, wherein the token may be configured to encrypt the user data; (Chauhan: Fig. 12, ¶168, i.e., receiving a token from the application server in response to authentication. See also, Bogard, Figs. 5-7, ¶159-¶164, ¶178, i.e., storing the user specific data using the device specific “app” (i.e., token) provided to the user device by the authentication/provider computer) transmitting the token from the authorization hub to the application; and (Chauhan: Fig. 12, ¶168, i.e., receiving a token from the application server in response to authentication) encrypting the user data using the token generated by the authorization hub. (Bogard, Figs. 5-7, ¶159-¶164, ¶178, i.e., storing the user specific data using the device specific “app” (i.e., token) provided to the user device by the authentication/provider computer wherein the app performs encryption/decryption of user data)
Claims 13 and 20 recite substantially the same features as recited in claim 5 above and are rejected based on the same rationale discussed in the rejection.
As regards claim 7, Chauhan et al combination teaches the system of claim 1, wherein validating the user data further comprises determining the user data received from the resource container matches a user database, wherein the user database includes information associated with the user. (Bogard: Figs. 7, 10, ¶192-195, i.e., the provider/authentication computer storing the user ID, device ID, token, etc)
Claim 15 recites substantially the same features as recited in claim 7 above and is rejected based on the same rationale discussed in the rejection.
As regards claim 8, Chauhan et al combination teaches the system of claim 1, wherein executing the instructions further causes the processing device to: receive a new interaction from a new resource container, wherein the new resource container is associated with the user, and wherein the new interaction is received via NFC signals; and (Chauhan: Fig. 12, ¶168, i.e., interaction of user with an application for authentication with an application server wherein receiving user data through an NFC or Bluetooth interface) validate the new resource container via the verified user device. (Chauhan: ¶168, i.e., verifying user data by the application server)
Claim 16 recites substantially the same features as recited in claim 8 above and is rejected based on the same rationale discussed in the rejection.
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 SYED A ZAIDI whose telephone number is (571)270-5995. The examiner can normally be reached Monday-Thursday: 5:30AM-5:30PM.
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, Jeffrey Nickerson can be reached at (469) 295-9235. 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.
/SYED A ZAIDI/Primary Examiner, Art Unit 2432
Prosecution Insights