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 .
This is a first office action in response to the instant application for letters patent filed on 01 December 2023. Claims 1-20 are presented for examination.
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 of the instant application is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1 and 11 of copending Application No. 18/412,307 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because the claim of the instant application is broader than the claims of application “307” which encompass the same metes, bounds, and limitations. Claim 1 of the instant application is inherent in claim 1 of application “307” with a slight difference in the generating section of the instant application that recites “generating by the tokenization service, a token for the source data, wherein the token has a token format that is specific to the namespace”.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Copending Application 18412,307:
A method for tokenizing data in a public cloud, comprising: receiving, at a tokenization service in a public cloud and from a client application, source data associated with a namespace of a plurality of namespaces; generating, by the tokenization service, a token for the source data according to a token format rule, wherein the token format rule reserves a first digit of the token and a second digit of the token, the first digit being selected to prevent the token from being identified as a payment token, and the combination of the first and second digits uniquely identifying the namespace for the source data; validating, by the tokenization service, a permission of the client application to tokenize the source data, wherein the validating comprises verifying, using a metadata table in the public cloud, that the client application is authorized for the namespace associated with the source data; encrypting, by the tokenization service, the source data using an encryption key obtained from an encryption key service in the public cloud, wherein the encryption key is specific to the namespace; associating, by the tokenization service, the token with the encrypted source data; persisting, by the tokenization service, the association between the token and the encrypted source data in a token table in the public cloud, wherein the token table is partitioned by application identifier to isolate data between different tenant; providing, by the tokenization service, the token to the client application; and persisting, by the tokenization service, the token format for the namespace, a prefix for the token, and an encryption master key identifier for the namespace in a metadata table.
2. (Original) The method of claim 1, further comprising: computing, by the tokenization service, a hash of the source data; and persisting, by the tokenization service, the hash with the token in a source hash table in the public cloud.
3. (Original) The method of claim 1, wherein the source data comprises debit card information or credit card information.
4. (Original) The method of claim 3, wherein the credit card information or the debit card information comprises a primary account number.
5. (Original) The method of claim 1, further comprising: validating, by the tokenization service, an entitlement or permission of the client application to tokenize the source data.
6. (Original) The method of claim 1, wherein a first digit of the token is reserved and prevent the token from being identified as a payment token.
7. (Original) The method of claim 1, wherein a first digit and a second digit of the token are reserved and identify the namespace for the source data.
8. (Currently Amended) The method of claim 2, wherein the association is partitioned in the token table using the namespace, and hash and the token are partitioned in the source hash table using the application identifier and/or the namespace.
9. (Cancelled).
10. (Original) The method of claim 1, wherein the step of encrypting, by the tokenization service, the source data comprises: obtaining, by the tokenization service, encryption keys from an encryption keys service; and encrypting, by tokenization service, the source data using the encryption keys.
11. (Currently Amended) A non-transitory computer readable storage medium, including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: receiving, from a client application, source data associated with one of a plurality of namespaces; generating a token for the source data according to a token format rule, wherein the token format rule reserves a first digit of the token and a second digit of the token, the first digit being selected to prevent the token from being identified as a payment token, and the combination of the first and second digits uniquely identifying the namespace for the source data; validating, by the tokenization service, a permission of the client application to tokenize the source data, wherein the validating comprises verifying, using a metadata table in the public cloud, that the client application is authorized for the namespace associated with the source data; encrypting the source data using an encryption key obtained from an encryption key service in the public cloud, wherein the encryption key is specific to the namespace; associating the token with the encrypted source data; persisting the association between the token and the encrypted source data in a token table in a public cloud, wherein the token table is partitioned by application identifier to isolate data between different tenant; providing the token to the client application; and persisting the token format for the namespace, a prefix for the token, and an encryption master key identifier for the namespace in a metadata table.
12. (Original) The non-transitory computer readable storage medium of claim 11, further including instructions stored thereon, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: computing a hash of the source data; and persisting the hash with the token in a source hash table in the public cloud.
13. (Original) The non-transitory computer readable storage medium of claim 11, wherein the source data comprises debit card information or credit card information.
14. (Original) The non-transitory computer readable storage medium of claim 13, wherein the credit card information or the debit card information comprises a primary account number.
15. (Cancelled).
16. (Original) The non-transitory computer readable storage medium of claim 11, wherein a first digit of the token is reserved and prevent the token from being identified as a payment token.
17. (Original) The non-transitory computer readable storage medium of claim 11, wherein a first digit and a second digit of the token are reserved and identify the namespace for the source data.
18. (Currently Amended) The non-transitory computer readable storage medium of claim 12, wherein the association is partitioned in the token table using the namespace, and hash and the token are partitioned in the source hash table using the application identifier and/or the namespace.
19. (Cancelled).
20. (Original) The non-transitory computer readable storage medium of claim 11, wherein the instructions that cause the one or more computer processors to encrypting the source data includes instructions, which when read and executed by one or more computer processors, cause the one or more computer processors to perform steps comprising: obtaining encryption keys from an encryption keys service; and encrypting the source data using the encryption keys.
Claims 11-20 are allowed over the prior art of record.
Claims 1-10 will be allowed upon the submission of a Terminal disclaimer by applicant.
The prior art fail to teach the combination of receiving, at a tokenization service in a public cloud and from a client application, source data associated with one of a plurality of namespaces; generating, by the tokenization service, a token for the source data, wherein the token has a token format that is specific to the namespace; encrypting, by the tokenization service, the source data; associating, by the tokenization service, the token with the encrypted source data; persisting, by the tokenization service, the association between the token and the encrypted source data in a token table in the public cloud; and providing, by the tokenization service, the token to the client application.
Furthermore, the prior art fail to teach receiving, at a tokenization service in a public cloud and from a client application, a request for source data for a token, the request comprising a namespace for the source data and an application identifier; querying, by the tokenization service, a token table with the token, the namespace, and the application identifier, wherein the token is persisted with encrypted source data in the token table and partitioned by the namespace and the application identifier; receiving, by the tokenization service, encrypted source data associated with the token from the token table; decrypting, by the tokenization service, the encrypted source data; and returning, by the tokenization service, the source data to the client application.
In another embodiment, the prior art fail to teach receiving, at a tokenization service in a public cloud and from a client application, source data, a namespace for the source data, and an application identifier; computing, by the tokenization service, a computed source hash of the source data; querying, by the tokenization service, a source hash table for the computed source hash, wherein the source hash table comprises a plurality of hashes, each hash associated with a token; returning, by the tokenization service and to the client application, a token not found indication in response to the computed source hash not being in the source hash table; and returning, by the tokenization service and to the client application, a token associated with the computed source hash in response to the computed source hash being in the source hash table.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANTZ B JEAN whose telephone number is (571)272-3937. The examiner can normally be reached 8-5 M-F.
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, Glenton B. Burgess can be reached at 5712723949. 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.
/FRANTZ B JEAN/Primary Examiner, Art Unit 2454