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 .
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.
Claim 1-6, 12-16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-4, 9-12 of U.S. Patent No. 12309139. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims rearrange the limitations of the claims of US 12309139. See the mapping below.
Present application
USPN 12309139
1. A computer-implemented method for code authentication using a wallet card and a virtual wallet of a user device, the method comprising:
receiving, at an enterprise server and from the user device, a request to access an account on the enterprise server;
2. (out of order) The method of claim 1, further comprising
receiving, at the security server, and from the enterprise server, a request to pre-screen the user device for code authentication using the virtual wallet on the user device;
responsive to receiving the request, generating, at the security server, a pre-screening communication channel link for establishing communication with the user device;
sending the pre-screening communication channel link to the enterprise server for transmission to the user device;
sending, to a security server from the enterprise server, a request to push a code to the wallet card of the virtual wallet of the user device;
responsive to the request, determining by the security server, a valid screening condition of the user device;
generating, by a code generator of the security server, the code; and
pushing the code to the wallet card of the virtual wallet of the user device;
receiving, at the security server, and from the user device, a confirmation that the code was written to the wallet card of the virtual wallet of the user device;
responsive to verifying that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet,
authenticating-the user device for accessing the enterprise server.
(Also claim 13).
7. The method of claim 1, wherein the verifying that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet is performed by the enterprise server.
(Claim 17 as well).
8. The method of claim 1, further comprising sending, to the enterprise server, and from the security server a confirmation that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet.
(Claim 18 as well).
1. A computer-implemented method for pre-screening and authenticating a user device for passcode authentication using a virtual wallet on the user device, the method comprising:
receiving, at a security server, and from an enterprise server, a request to pre-screen the user device for passcode authentication using the virtual wallet on the user device;
responsive to receiving the request, generating, at the security server, a pre-screening communication channel link for establishing communication with the user device;
sending the pre-screening communication channel link to the enterprise server for transmission to the user device;
responsive to activation of the pre-screening communication channel link by the user device, probing, by a device screener of the security server, the user device to detect one or more security issue conditions, comprising: a SIM swap on the user device within a selectable period; and a porting of the user device to a new carrier within a selectable period; responsive to a determination that no security issue conditions are detected at the user device: sending, to the enterprise server an indication of a clear pre-screening result;
receiving, at the security server, and from the enterprise server, a request to push a wallet card to the virtual wallet on the user device;
responsive to receiving the-request to push the wallet card to the virtual wallet on the user device:
generating, by a wallet card generator of the security server, the wallet card; and
pushing the wallet card to the virtual wallet on the user device; receiving, at the security server, and from the enterprise server, a request to push a passcode to the wallet card;
responsive to the request to push the passcode to the wallet card:
generating, by a code generator of the security server, a code; and
pushing the code to the virtual wallet on the user device;
responsive to confirming, at the security server, that the passcode received from the wallet card matches the code pushed to the virtual wallet on the user device, transmitting a match indication to the enterprise server to initiate authentication of the user device for accessing the enterprise server.
Also claim 10.
3. The method of claim 2, further comprising: responsive to a determination that one or more security issue conditions are detected at the user device:
sending, to the enterprise server, an indication of a failed pre-screening result; and
preventing a code from being pushed to the user device.
responsive to activation of the pre-screening communication channel link by the user device, probing, by a device screener of the security server, the user device to detect one or more security issue conditions, comprising one or more of:
an indication that the user device is jailbroken;
an indication that the user device is located in a geographic region that differs by more than a selectable distance from a determined residence region associated with the user device;
a SIM swap on the user device within a selectable period; and
a porting of the user device to a new carrier within a selectable period;
responsive to a determination that no security issue conditions are detected at the user device, sending, to the enterprise server, an indication of a clear pre-screening result.
responsive to the determining the valid screening condition:
12. The method of claim 11, further comprising:
responsive to a determination that one or more security issue conditions are detected at the user device:
sending, to the enterprise server, an indication of a failed pre-screening result; and preventing a code from being pushed to the user device.
11. The method of claim 10, further comprising receiving, at the security server, and from the enterprise server, a request to pre-screen the user device for passcode authentication using the virtual wallet on the user device;
responsive to receiving the request, generating, at the security server, a pre-screening communication channel link for establishing communication with the user device;
sending the pre-screening communication channel link to the enterprise server for transmission to the user device; responsive to activation of the pre-screening communication channel link by the user device, probing, by a device screener of the security server, the user device to detect one or more security issue conditions, comprising: a SIM swap on the user device within a selectable period; and a porting of the user device to a new carrier within a selectable period; responsive to a determination that no security issue conditions are detected at the user device, sending, to the enterprise server, an indication of a clear pre-screening result.
3. The method of claim 2, further comprising:
responsive to a determination that one or more security issue conditions are detected at the user device:
sending, to the enterprise server, an indication of a failed pre-screening result; and
preventing a code from being pushed to the user device.
2. The method of claim 1, further comprising: responsive to a determination that one or more security issue conditions are detected at the user device:
sending, to the enterprise server, an indication of a failed pre-screening result;
and
preventing a code from being pushed to the user device.
4. The method of claim 2, wherein the request to pre-screen the user device for code authentication using the virtual wallet is responsive to a request by the user device to access an account on the enterprise server.
5. The method of claim 2, further comprising performing, by the security server, a process to enroll the enterprise server for code authentication using the virtual wallet.
(Also claim 15).
9. The method of claim 1, further comprising performing, by the security server, a process to enroll the enterprise server for passcode authentication using the virtual wallet.
6. The method of claim 1, wherein the verifying that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet is performed by the security server.
(Also claim 17).
10 … responsive to confirming, at the security server, that the passcode received from the wallet card matches the generated code pushed to the virtual wallet:
transmitting a match indication to the enterprise server to initiate authentication of the pre-screened user device for accessing the enterprise server.
10. The method of claim 1, wherein the code is a one-time-passcode (OTP).
Also claim 19.
3. The method of claim 1, wherein the code is a one-time-passcode (OTP).
Also claim 19.
11. The method of claim 1, wherein the code is valid for a selectable period.
Also claim 20.
4. The method of claim 1, wherein the code is valid for a selectable period.
Also claim 20.
Claim Rejections - 35 USC § 103
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.
Claim(s) 12, 16-17, 1, 5, 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran, US 20160292673 A1 (hereafter referred to as Chandrasekaran) in view of Kohli, WO 2019/240875 A1 (hereafter referred to as Kohli).
Claim 12, Chandrasekaran teaches a system for code authentication using a wallet card and a virtual wallet of a user device (abstract), the system comprising:
a security server in communication with an enterprise server and the user device (p. 50, “security check” engine, “The financial institution application 258 may then initiate a security check on the devices. The security check generates a security confidence rating to confirm that the device requesting the new credit card to be implemented on the digital wallet and the device associated with the digital wallet are both devices associated with the user and are both not corrupted with viruses, malware, or the like.”); a processor; and a memory having programming instructions stored thereon, which, when executed by the processor (p. 52, “while only one network system 206 is illustrated in FIG. 1, it is understood that multiple network systems may make up the system environment 200. The network system 206 generally comprises a communication device 236, a processing device 238, and a memory device 240. The network system 206 comprises computer-readable instructions 242 stored in the memory device 240, which in one embodiment includes the computer-readable instructions 242 of a network application 244.”), cause the processor to:
receive a request to access an account on the enterprise server using the user device (p. 41, "The user system 204 is a computing that allows a user 202 to interact with the financial institution to apply for a credit card, access online banking applications, and utilize a digital wallet for transaction completion." And p. 49, "the financial institution application 258 may receive request for virtual credit card to be on digital wallet.");
receive, at the security server, a request to push a code to the wallet card (in combination with Kohli) of the virtual wallet of the user device (p. 46, "receive request for virtual credit card to be on digital wallet, contact user system 204 for security confidence " And p. 49, "the financial institution application 258 may receive request for virtual credit card to be on digital wallet.");
responsive to the request to push the code, determine by the security server, a valid screening condition of the user device ( p. 50, "The financial institution application 258 may then initiate a security check on the devices. The security check generates a security confidence rating to confirm that the device requesting the new credit card to be implemented on the digital wallet and the device associated with the digital wallet..." And p. 38, "FIG. 2 illustrates only one example of an embodiment of the system environment 200, and it will be appreciated that in other embodiments one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or servers.");
responsive to a determination of the valid screening condition (no security issues):
generate, by a code generator of the security server, the code (p. 53, "the network application 244 provides, in some embodiments, token creation and distribution. In some embodiments the network application 244 may create and distribute a token for storage on the user system 204 and financial institution server 208."); and
push the code to the wallet card of the virtual wallet of the user device (p. 53, "the network application 244 provides, in some embodiments, token creation and distribution. In some embodiments the network application 244 may create and distribute a token for storage on the user system 204 and financial institution server 208.");
receive, at the security server, and from the user device, a confirmation that the code was written to the wallet card (in combination with Kohli) of the virtual wallet of the user device (p. 74, "prior to uploading the new card to the user's digital wallet, the system may request a re-entry of the username and password of the user that is used for online banking session log in. In some embodiments, the authorization is the indication that the user has selected the new credit card to be implemented on his/her digital wallet.");
responsive to verification that the code written to the wallet card (in combination with Kohli) of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet, authenticate the user device to access the account on the enterprise server .
Chandrasekaran does not specifically teach separate enterprise server and security server. However, Chandrasekaran teaches an equivalent embodiment comprising separate servers for financial services and security check services (p. 38, "one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or servers." And specialized communication from the distributive network, p. 28, "a distributive network system with specialized data feeds associated with the
distributive network and specific triggering events associated with the data feeds for authorizing and instantly integrating a newly approved credit card into a digital wallet."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to separate the functionality of the enterprise server and security server from Chandrasekaran for the alternative embodiment comprising separate server for different functionality. The motivation would have been separating the server functionality is an obvious variation.
Chandrasekaran does not specifically teach a wallet card. However, in the same field of endeavor, Kohli teaches a wallet card for providing access to a service using a virtual wallet (pages 10-11, “When the user 108 selects the option to subscribe with his/her virtual wallet application 116, the service provider 102 (and, in particular, the computing device 200 associated therewith) is configured to solicit from the user 108, through the subscription interface (or another interface), a selection of the specific virtual wallet application 116 associated with the user 108 and/or an identifier associated with the virtual wallet application 116 (e.g., a phone number for the user 108, an email address, a device identifier (ID), etc.), and/or a provisioned link associated with a hosted application (e.g., when the virtual wallet application 116 is integrated with the hosted application (e.g., via an SDK, etc.), etc.).”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chandrasekaran by incorporating a wallet card from Kohli to transform the virtual card into subscription cards that facilitate payment for subscription services. The motivation would have to provide a different card for online services without exposing a virtual credit card.
Claim 1 is a method similar to the system of claim 12 above. Claim 1 is rejected on a similar rationale as claim 12.
Claim 5 is a method similar to the system of claim 16 above. Claim 5 is rejected on a similar rationale as claim 16.
Claim 6, Chandrasekaran-Kohli teaches the method of claim 1, wherein the verifying that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet is performed by the security server (Chandrasekaran, p. 74, "prior to uploading the new card to the user's digital wallet, the system may request a re-entry of the username and password of the user that is used for online banking session log in. In some embodiments, the authorization is the indication that the user has selected the new credit card to be implemented on his/her digital wallet." And p. 38, “FIG. 2 illustrates only one example of an embodiment of the system environment 200, and it will be appreciated that in other embodiments one or more of the systems, devices, or servers may be combined into a single system, device, or server, or be made up of multiple systems, devices, or servers.”).
Claim 17, Chandrasekaran-Kohli teaches the system of claim 12, wherein the security server is used to verify that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet (Chandrasekaran, p. 74, "prior to uploading the new card to the user's digital wallet, the system may request a re-entry of the username and password of the user that is used for online banking session log in. In some embodiments, the authorization is the indication that the user has selected the new credit card to be implemented on his/her digital wallet.").
Claim 7 is a method similar to the system of claim 17 above. Claim 7 is rejected on a similar rationale as claim 17.
Claim(s) 18 and 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran and Kohli as applied to claims 12 and 1 above, and further in view of Belleville et al., US 20200364697 A1 (hereafter referred to as Belleville).
Claim 18, Chandrasekaran-Kohli teaches the system of claim 12, wherein the programming instructions further cause the processor to send, to the enterprise server, and from the security server a confirmation that the code written to the wallet card of the virtual wallet of the user device matches the code pushed to the wallet card of the virtual wallet (Chandrasekaran, p. 50, “As such, the security check and subsequently generated security confidence rating ensures that misappropriation of the new credit card cannot occur. As such, the security check may, in some embodiments, provide code and/or access information about the requesting device and digital wallet device, based on the identifier of each device.” The security check provides code/token information and then the enterprise server can further compare the codes. And p. 51, “As such, once the financial institution application 258 determines a security rating for the requesting device is above the required threshold, the financial institution application 258 may generate and/or push a token to the requesting device, such as the user system 204 via system network feeds and nodes through the network 201.” See also p. 74, “prior to uploading the new card to the user's digital wallet, the system may request a re-entry of the username and password of the user that is used for online banking session log in. In some embodiments, the authorization is the indication that the user has selected the new credit card to be implemented on his/her digital wallet.”).
Claim 8 is a method similar to the system of claim 18 above. Claim 8 is rejected on a similar rationale as claim 18.
Claim(s) 10 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran and Kohli as applied to claims 12 and 1 above, and further in view of Sims et al., US 20180211249 A1 (hereafter referred to as Sims).
Claim 19, Chandrasekaran teaches the system of claim 12, as cited above. Chandrasekaran does not specifically teach wherein the code is a one-time-passcode (OTP). However, in the same field of endeavor, Sims teaches the code is a one-time-passcode (OTP) (p. 25, "standard processes ask the customer to perform a step up authentication. In some cases, this step-up authentication may include running of an OTP or CVV widget."). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chandrasekaran to substitute OTP from Sims to improve adaptability for different credit card providers. The motivation would have been to not expose credentials from multiple third parties to the wallet service.
Claim 10 is a method similar to the system of claim 19 above. Claim 10 is rejected on a similar rationale as claim 19.
Claim(s) 20 and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Chandrasekaran and Kohli as applied to claim 11 above, and further in view of “Official Notice”.
Claim 20, Chandrasekaran-Kohli teaches the system of claim 11, as cited above. Chandrasekaran does not specifically teach wherein the code is valid for a selectable period. "Official Notice" is taken a code that is valid for a selectable time period is well known in the art. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Chandrasekaran-Kohli to substitute "well-known" selectable time period to improve security while giving the recipient a chance to respond. The motivation would have been to deliver a spontaneous security check and but not waste resources by providing a time period that is long enough to be effective for the recipient.
Claim 11 is a method similar to the system of claim 20 above. Claim 11 is rejected on a similar rationale as claim 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Chester et al., US 12141266 B2, teaches the processes may utilize AE locker (e.g., keychain) sync across various devices through an AE subsystem, which may be assured by SEP, and/or AE or device passcode as an additional (e.g., third) factor, and/or using existing credentials in a digital wallet, and/or may not rely on biometrics but instead may rely on multiple levels of passwords/passcodes and physical device access as authentication factors.
Ratnakaram et al, US 20210195411 A1, teaches an intelligence-Based System for Detecting SIM-Swap Fraud.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PATRICE L WINDER whose telephone number is (571)272-3935. The examiner can normally be reached M-F 10am-6pm.
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, KAMAL B DIVECHA can be reached at (571)272-5863. 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.
/Patrice L Winder/Primary Examiner, Art Unit 2453
Prosecution Insights