Detailed Action
The present application is being examined under the pre-AIA first to invent provisions.
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 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.
Claims 20-39, as originally filed, are currently pending and have been considered below. Claim 20, 35 and 39 are independent claim.
Priority
This application is a CON of 18/529,586 12/05/2023 PAT 12278812
18/529,586 is a CON of 18/471,786 09/21/2023 PAT 12470547
18/471,786 is a CON of 17/715,610 04/07/2022 PAT 11799847
17/715,610 is a CON of 16/893,023 06/04/2020 PAT 11329973
16/893,023 is a CON of 16/422,715 05/24/2019 PAT 10749859
16/422,715 is a CON of 15/887,873 02/02/2018 ABN
15/887,873 is a CON of 14/982,981 12/29/2015 PAT 9954854
14/982,981 is a CON of 13/794,878 03/12/2013 PAT 9251531
13/794,878 has PRO 61/740,731 12/21/2012.
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 obviousness-type 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); and 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 a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claims 20, 35 and 39 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 of U.S. Patent No. 9,251,531 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the U.S. Patent No. 9,251,531 B2 contains every element of claims of the instant application. A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a 35 patent claim to a species within that genus). “ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
Claim 20, 35 and 39 of current application No. 19/081,047 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 of U.S. Patent No. 9,251,531 B2 in view of Purves (US Patent Application Publication No. 2013/0054454 A1) in view of Stafford (US Patent Application Publication No. 2009/0271321 A1).
This is a non-provisional non-statutory double patenting rejection because the conflicting claims have been patented.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
.
Claim 20-39 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Purves (US Patent Application Publication No. 2013/0054454 A1) in view of Stafford (US Patent Application Publication No. 2009/0271321 A1).
Regarding Claim 20, Purves discloses a computer-implemented method, comprising:
scanning, via a third party client executed by a third party device, an information code associated with an officially verifiable electronic representation (OVER) file from a device of a user, wherein the OVER file is associated with a credential of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server);
transmitting, via the third party client, information embedded within the information code to an application gateway for verification of the credential (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device);
receiving, via the third party client, a status indicator from the application gateway (Purves, ¶[0075], other API calls may be called by the merchant server to obtain information including address, nick name, indicator for default/primary address, indicator for current/primary loyalty program);
Purves does not appear to disclose the following limitation that Stafford discloses:
displaying, via the third party client, the status indicator received from the application gateway (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request); and
determining, via the third party client, a validity of the OVER File based on the status indicator (Stafford, ¶[0054], validating credential information about an entity. ¶[0135], all released information is water marked and has a validity date associated).
Purves in view of Stafford are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “authentication and authorization based on user credential”. It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the invention of Purves in view of Stafford to include the idea of authentication mechanism that relies upon associating and transmitting user credential to the authorization server or the issuer to make sure the user provided log in information is valid. This overcomes the vulnerabilities of static password.
Regarding claim 21, Purves in view of Stafford discloses the method of claim 20, further comprising:
determining, via the application gateway, whether the OVER file is stored in an OVER file database (Purves, ¶[0110], querying a database. Stafford, ¶[0026], access to a database); and
generating, via the application gateway, the status indicator based on the determination (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request).
Regarding claim 22, Purves in view of Stafford discloses the method of claim 21, further comprising:
updating, via an issuing agency database, the OVER file database (Purves, ¶[0110], querying a database. Stafford, ¶[0026], access to a database).
Regarding claim 23, Purves in view of Stafford discloses the method of claim 20, wherein the information embedded within the information code comprises user-generated information (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device).
Regarding claim 24, Purves in view of Stafford discloses the method of claim 23, further comprising:
determining, via the application gateway, whether the user-generated information matches information stored in an OVER file database (Purves, ¶[0110], querying a database. Stafford, ¶[0026], access to a database); and
generating, via the application gateway, the status indicator based on the determination (Stafford, ¶[0054], validating credential information about an entity. ¶[0135], all released information is water marked and has a validity date associated).
Regarding claim 25, Purves in view of Stafford discloses the method of claim 23, wherein the user-generated information comprises a password, biometric information, or location information, or combinations thereof (Purves, ¶[0065]- ¶[0069], the customer may enter their username and password. Stafford, ¶[0069], along with submission of their private key and password).
Regarding claim 26, Purves in view of Stafford discloses the method of claim 20, further comprising:
receiving, via the third party client, an image of the credential associated with the OVER file from the application gateway (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server); and
displaying, via the third party client, the image of the credential associated with the OVER file (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request).
Regarding Claim 27, Purves in view of Stafford discloses the method of claim 20, wherein the information embedded within the information code comprises a credential identifier (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding Claim 28, Purves in view of Stafford discloses the method of claim 20, further comprising:
requesting, via the third party client, generation of the OVER file based on the credential of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding claim 29, Purves in view of Stafford discloses the method of claim 20, further comprising:
requesting, via the third party client, delivery of the OVER file to an OVER file storage client (Purves, ¶[0075], other API calls may be called by the merchant server to obtain information including address, nick name, indicator for default/primary address, indicator for current/primary loyalty program).
Regarding Claim 30, Purves in view of Stafford discloses the method of claim 20, wherein the information embedded within the information code comprises a device identifier associated with the device of the user or an application executed by the device of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding Claim 31, Purves in view of Stafford discloses the method of claim 30, wherein the device identifier is configured to increase security of the OVER file by tying the OVER file to the device of the user or the application executed by the device of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding claim 32, Purves in view of Stafford discloses the method of claim 20, wherein the information code comprises a quick- response code, a one dimensional bar code, or an alpha numeric bar code, or combinations thereof (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device).
Regarding Claim 34, Purves in view of Stafford discloses the method of claim 20, wherein the information code is scanned via radio transmission or electronic transmission broadcast over a network (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding Claim 35, Purves discloses an apparatus, comprising:
a processor (Purves, Fig-25); and
a memory storing a third party client that, when executed by the processor, causes the apparatus to (Purves, Fig-25):
scan an information code associated with an officially verifiable electronic representation (OVER) file from a device of a user, wherein the OVER file is associated with a credential of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server);
transmit information embedded within the information code to an application gateway for verification of the credential (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device);
receive a status indicator from the application gateway, wherein the status indicator (Purves, ¶[0075], other API calls may be called by the merchant server to obtain information including address, nick name, indicator for default/primary address, indicator for current/primary loyalty program);
Purves does not appear to disclose the following limitation that Stafford discloses:
display the status indicator received from the application gateway (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request);
determine a validity of the OVER file based on the status indicator (Stafford, ¶[0054], validating credential information about an entity. ¶[0135], all released information is water marked and has a validity date associate); and
Purves does not appear to disclose the following limitation that Stafford discloses:
display an image of the credential associated with the OVER file based on the determination (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request).
Purves in view of Stafford are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “authentication and authorization based on user credential”. It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the invention of Purves in view of Stafford to include the idea of authentication mechanism that relies upon associating and transmitting user credential to the authorization server or the issuer to make sure the user provided log in information is valid. This overcomes the vulnerabilities of static password.
Regarding Claim 36, Purves in view of Stafford discloses the apparatus of claim 35, wherein the information embedded within the information code comprises a device identifier associated with the device of the user or an application executed by the device of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding Claim 37, Purves in view of Stafford discloses the method of claim 30, wherein the device identifier is configured to increase security of the OVER file by tying the OVER file to the device of the user or the application executed by the device of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server).
Regarding Claim 38, Purves in view of Stafford discloses the method of claim 20, wherein the information code comprises a quick- response code, a one dimensional bar code, or an alpha numeric bar code, or combinations thereof (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device).
Regarding Claim 39, Purves discloses a system comprising:
a third party device comprising a processor and a memory storing a third party client that, when executed by the processor, causes the third party device to:
scan an information code associated with an officially verifiable electronic representation (OVER) file from a device of a user, wherein the OVER file is associated with a credential of the user (Purves, ¶[0055], a user may input username and password credential into the wallet widget. ¶[0068], a user may input login credential at the merchant site or application on their client device. The client device may take the login credential and generate an authentication request for transmission to merchant server. ¶[0070], the user credential may be authenticated by the wallet server);
transmit information embedded within the information code to an application gateway for verification of the credential (Purves, ¶[0098], the checkout page response is embedded with code that causes client to initiate a second request to a wallet server. ¶[0102], a user may be required to provide a user name/password combination and a one time code generated by their mobile device);
receive a status indicator from the application gateway, wherein the status indicator (Purves, ¶[0075], other API calls may be called by the merchant server to obtain information including address, nick name, indicator for default/primary address, indicator for current/primary loyalty program);
an application gateway configured to:
determine whether the OVER file is stored in an OVER file database (Purves, ¶[0110], querying a database); and
generate the status indicator based on the determination (Purves, ¶[0075], other API calls may be called by the merchant server to obtain information including address, nick name, indicator for default/primary address, indicator for current/primary loyalty program).
Purves does not appear to disclose the following limitation that Stafford discloses:
display the status indicator received from the application gateway (Stafford, ¶[0026], method of facilitating the verification of characteristics of an entity. ¶[0027], receiving a release request, decrypting encrypted releasable data and transmitting verified entity characteristics data relating to the entity to the originator of the release request);
determine a validity of the OVER file based on the status indicator; and display an image of the credential associated with the OVER file based on the determination (Stafford, ¶[0054], validating credential information about an entity. ¶[0135], all released information is water marked and has a validity date associated); and
Purves in view of Stafford are analogous art because they are from the “same field of endeavor” and are from the same “problem solving area”. Namely, they pertain to the field of “authentication and authorization based on user credential”. It would have been obvious to a person of ordinary skill in the art at the time the invention was made to modify the invention of Purves in view of Stafford to include the idea of authentication mechanism that relies upon associating and transmitting user credential to the authorization server or the issuer to make sure the user provided log in information is valid. This overcomes the vulnerabilities of static password.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (see PTO-Form 892).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WASIKA NIPA whose telephone number is (571)272-8923. The examiner can normally be reached on M-F, 8 am to 5 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Pwu can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/WASIKA NIPA/ Primary Examiner, Art Unit 2433
Prosecution Insights