DETAILED ACTION
Acknowledgements
Claims 1-20 are pending.
Claims 1-20 have been examined.
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 §§ 706.02(l)(1) - 706.02(l)(3) 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 USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The 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/process/file/efs/guidance/eTD-info-I.jsp.
Claims 1-2, 9-10 and 17-18 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-2, 11-12 and 17-18 of U.S. Patent No. 12,475,460. Although the claims at issue are not identical, they are not patentably distinct from each other because all the claims at issue are recited in claims 1-2, 11-12 and 17-18 of U.S. Patent No. 12,475,460.
19/357,644
12,475,460
1. A method comprising:
receiving, by one or more servers of a card processing system, a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generating, by the one or more servers, a metadata layer comprising metadata associated with the cryptographic key in response to the key request by storing the metadata layer within a distributed database of the card processing system;
validating, by the one or more servers accessing the metadata layer in the distributed database in response to a transaction request to perform a transaction comprising the cryptographic key, the cryptographic key based on the metadata from the metadata layer;
transmitting, by the one or more servers to a payment card network in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key;
generating, by the one or more servers and within the distributed database, a new metadata layer comprising new metadata associated with a new cryptographic key received from the payment card network in response to the key exchange request; and
performing, by the one or more servers in connection with the hardware security device associated with the third-party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key utilizing the new metadata layer..
2. The method of claim 1, wherein generating the metadata layer comprises:
extracting a plurality of attributes of the cryptographic key from the key request; and
generating, within the distributed database, the metadata layer comprising a plurality of fields including the plurality of attributes and a mapping of the cryptographic key to the metadata layer.
9. A card processing system comprising:
one or more non-transitory computer readable media comprising a distributed database; and
at least one processor configured to cause the card processing system to:
receive a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generate a metadata layer comprising metadata associated with the cryptographic key in response to the key request by storing the metadata layer within a distributed database of the card processing system;
validate, by accessing the metadata layer in the distributed database in response to a transaction request to perform a transaction comprising the cryptographic key, the cryptographic key based on the metadata from the metadata layer;
transmit, to a payment card network in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key;
generate, within the distributed database, a new metadata layer comprising new metadata associated with a new cryptographic key received from the payment card network in response to the key exchange request; and
perform, in connection with the hardware security device associated with the third party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key utilizing the new metadata layer.
1. A method comprising:
receiving, by one or more servers of a card processing system and from a payment card network, a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generating, by the one or more servers and within a distributed database of the card processing system, a metadata layer comprising metadata associated with the cryptographic key in response to the key request;
storing, by the distributed database, the metadata layer of the cryptographic key;
transmitting, by a key exchange system, the cryptographic key to the third-party system for storing in the hardware security device;
validating, by the one or more servers, the cryptographic key based on the metadata layer comprising the metadata associated with the cryptographic key in response to the payment card network sending a transaction request to the card processing system to perform a transaction comprising the cryptographic key;
detecting, by the one or more servers utilizing a key monitoring system of the card processing system, one or more events in connection with validating the cryptographic key or based on historical data associated with the payment card account;
in response to detecting the one or more events, generating a forced exchange message from the key monitoring system to the key exchange system, the forced exchange message comprising instructions to initiate a key exchange operation;
providing, utilizing the key exchange system, a key exchange request to the payment card network in response to the forced exchange message from the key monitoring system to the key exchange system;
generating, by the payment card network, a new cryptographic key in response to the key exchange request;
in response to receiving the new cryptographic key from the payment card network:
generating, by a key metadata system, a new metadata layer for the new cryptographic key;
storing, by the distributed database, the new metadata layer;
invalidating, by the distributed database, the metadata layer associated with the cryptographic key; and
transmitting, by the key exchange system, the new cryptographic key to the third-party system for storing in the hardware security device and removing the cryptographic key from the hardware security device; and
performing, by the one or more servers in connection with the hardware security device associated with the third-party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key.
2. The method of claim 1, wherein generating the metadata layer comprises:
extracting a plurality of attributes of the cryptographic key from the key request; and
generating, based on the plurality of attributes, the metadata layer comprising a plurality of fields associated with the cryptographic key within the distributed database.
11. A card processing system comprising:
one or more non-transitory computer readable media comprising a distributed database; and
at least one processor configured to cause the card processing system to:
receive, from a payment card network, a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generate, within the distributed database of the card processing system, a metadata layer comprising metadata associated with the cryptographic key in response to the key request;
store, by the distributed database, the metadata layer of the cryptographic key;
transmit, by a key exchange system, the cryptographic key to the third-party system for storing in the hardware security device;
validate the cryptographic key based on the metadata layer comprising the metadata associated with the cryptographic key in response to the payment card network sending a transaction request to the card processing system to perform a transaction comprising the cryptographic key;
detect, utilizing a key monitoring system of the card processing system, one or more events in connection with validating the cryptographic key or based on historical data associated with the payment card account;
in response to detecting the one or more events, generate a forced exchange message from the key monitoring system to the key exchange system, the forced exchange message comprising instructions to initiate a key exchange operation;
provide, utilizing the key exchange system, a key exchange request to the payment card network in response to the forced exchange message from the key monitoring system to the key exchange system;
generate, by the payment card network, a new cryptographic key in response to the key exchange request;
in response to receiving the new cryptographic key from the payment card network:
generate, by a key metadata system, a new metadata layer for the new cryptographic key;
store, by the distributed database, the new metadata layer:
invalidate, by the distributed database, the metadata layer associated with the cryptographic key; and
transmit, by the key exchange system, the new cryptographic key to the third-party system for storing in the hardware security device and removing the cryptographic key from the hardware security device; and
perform, in connection with the hardware security device associated with the third-party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key.
10. The card processing system of claim 9, wherein the at least one processor is further configured to cause the card processing system to generate the metadata layer by:
extracting a plurality of attributes of the cryptographic key from the key request; and
generating, within the distributed database, the metadata layer comprising a plurality of fields including the plurality of attributes and a mapping of the cryptographic key to the metadata layer.
12. The card processing system of claim 11, wherein the at least one processor is further configured to cause the card processing system to generate the metadata layer by:
determining, based on the key request, a plurality of attributes of the cryptographic key; and
generating, within the distributed database, the metadata layer comprising the plurality of attributes of the cryptographic key.
17. A non-transitory computer readable medium comprising instructions that, when executed by at least one processor, cause the at least one processor to:
receive a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generate a metadata layer comprising metadata associated with the cryptographic key in response to the key request by storing the metadata layer within a distributed database of a card processing system;
validate, by accessing the metadata layer in the distributed database in response to a transaction request to perform a transaction comprising the cryptographic key, the cryptographic key based on the metadata from the metadata layer;
transmit, to a payment card network in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key;
generate, within the distributed database, a new metadata layer comprising new metadata associated with a new cryptographic key received from the payment card network in response to the key exchange request; and
perform, in connection with the hardware security device associated with the third-party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key utilizing the new metadata layer.
17. A non-transitory computer readable medium comprising instructions that, when executed by at least one processor, cause the at least one processor to:
receive, by a card processing system and from a payment card network, a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system;
generate, by the card processing system and within a distributed database of the card processing system, a metadata layer comprising metadata associated with the cryptographic key in response to the key request;
store, by the distributed database, the metadata layer of the cryptographic key;
transmit, by a key exchange system, the cryptographic key to the third-party system for storing in the hardware security device;
validate, by the card processing system, the cryptographic key based on the metadata layer comprising the metadata associated with the cryptographic key in response to the payment card network sending a transaction request to the card processing system to perform a transaction comprising the cryptographic key;
detect, utilizing a key monitoring system of the card processing system, one or more events in connection with validating the cryptographic key or based on historical data associated with the payment card account;
in response to detecting the one or more events, generate a forced exchange message from the key monitoring system to the key exchange system, the forced exchange message comprising instructions to initiate a key exchange operation;
provide, utilizing the key exchange system, a key exchange request to the payment card network in response to the forced exchange message from the key monitoring system to the key exchange system;
generate, by the payment card network, a new cryptographic key in response to the key exchange request;
in response to receiving the new cryptographic key from the payment card network:
generate, by a key metadata system, a new metadata layer for the new cryptographic key;
store, by the distributed database, the new metadata layer;
invalidate, by the distributed database, the metadata layer associated with the cryptographic key; and
transmit, by the key exchange system, the new cryptographic key to the third-party system for storing in the hardware security device and removing the cryptographic key from the hardware security device; and
perform, by the card processing system in connection with the hardware security device associated with the third-party system, the transaction corresponding to the transaction request in response to validating the new cryptographic key
18. The non-transitory computer readable medium of claim 17, further comprising instructions that, when executed by the at least one processor, cause the at least one processor to generate the metadata layer by:
extracting a plurality of attributes of the cryptographic key from the key request; and
generating, within the distributed database, the metadata layer comprising a plurality of fields including the plurality of attributes and a mapping of the cryptographic key to the metadata layer.
18. The non-transitory computer readable medium of claim 17, further comprising instructions that, when executed by the at least one processor, cause the at least one processor to generate the metadata layer by:
extracting a version number associated with the cryptographic key and one or more timestamps associated with the cryptographic key from the key request; and
generating, within the distributed database, the metadata layer comprising the version number associated with the cryptographic key and the one or more timestamps associated with the cryptographic key.
Claim Rejections - 35 USC §101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Analysis
In the instant case, claims 1-8 are directed to a method, claims 9-16 are directed to a system, and claims 17-20 are directed to a CRM. Therefore, these claims fall within the four statutory categories of invention.
The claim(s) recite(s) processing cryptographic key services request. Specifically, the claims recite “receiving, …, a key request to store a cryptographic key for a payment card account…; generating, …, a metadata layer comprising metadata associated with the cryptographic key in response to the key request storing the metadata layer within a ...; validating,… accessing the metadata layer in the ... in response to a transaction request to perform a transaction comprising the cryptographic key, the cryptographic key based on the metadata layer; transmitting, ... in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key; generating, ..., a new metadata layer comprising new metadata associated with a new cryptographic key received from ...in response to the key exchange request; and performing, …, the transaction corresponding to the transaction request in response to validating the new cryptographic key utilizing the new metadata layer.”, which is “commercial or legal interactions” within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106) because the claims involve a series of steps for processing cryptographic key services request. Accordingly, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106), the additional element(s) of the claim(s) such as the use of servers of a card processing system, hardware security device, distributed database, key exchange system, payment card network, and storage device merely use(s) a computer as a tool to perform an abstract idea. The processors and memories are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function of processing cryptographic key services request) such that it amounts no more than mere instructions to apply the exception using a generic computer components. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using servers of a card processing system, hardware security device, distributed database, key exchange system, payment card network, and storage device to process cryptographic key services request steps amounts to no more than mere instructions to apply the exception using a generic computer components. Mere instructions to apply an exception using a generic computer components cannot provide an inventive concept. The claim is not patent eligible.
Dependent claims 2-3, 10-11 and 18 describe metadata layer of the requested cryptographic key. Dependent claims 4 and 12 describe cryptographic key validation. Dependent claims 5, 13 and 19 describe in the event of cryptographic key validation failure. Dependent claims 6-7 and 14-15 describe handling anomaly event of cryptographic key. Dependent claims 8, 16 and 20 describe invalidating the existing key transmitting out the new key to store. These claims further recite the abstract idea of certain methods of organizing human activity. This judicial exception is not integrated into a practical application because the additional element(s) of the claim(s) such as the use of servers of a card processing system, hardware security device, distributed database, key exchange system, payment card network, and storage device merely use(s) a computer as a tool to perform an abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The claims are not patent eligible.
Viewed as a whole, the combination of elements recited in the claims simply recite the concept of processing cryptographic key services request. The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field.
The use of a servers of a card processing system, hardware security device, distributed database, key exchange system, payment card network, and storage device as tools to implement the abstract idea does not render the claim patent eligible because it does not provide meaningful limitations beyond generally linking the use of an abstract idea to a particular technological environment and requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea.
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.
Claims 1-2, 9-10 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over US Grant Publication US10,909,250 B2 (“Rudzitis et al.”) in view of US Application Publication US20220100828A1 (“Dean et al.”).
Regarding claims 1, 9 and 17, Rudzitis et al. discloses:
one or more non-transitory computer readable media comprising a distributed database; (Fig. 1 item 108; col 3 lines 58-65) and
at least one processor configured to cause the card processing system to: (Fig. 1 items 102; col 3 lines 11-21)
receive a key request to store a cryptographic key for a payment card account in a hardware security device associated with a third-party system; (col 2 lines 62 – col 3 line 2)
generate a metadata layer comprising metadata associated with the cryptographic key in response to the key request by storing the metadata layer within a distributed database of the card processing system; (Fig. 1 item 110; col 1 line 65 – col 2 line 7)
validate, by accessing the metadata layer in the distributed database in response to a transaction request to perform a transaction comprising the cryptographic key, the cryptographic key based on the metadata layer; (Fig. 5 step 506 and 508; col 8 lines 35-42)
generate, within the distributed database, a new metadata layer comprising new metadata associated with a new cryptographic key received from the payment card network in response to the key exchange request; and (Fig. 1 item 110; col 1 line 65 – col 2 line 7)
perform, in connection with the hardware security device associated with the third-party system, a transaction corresponding to the transaction request in response to validating the new cryptographic key utilizing the new metadata layer. (Fig. 5 steps 514, 516 and 522; col 9 lines 1-16 & 29-31)
Rudzitis et al. does not explicitly disclose:
transmit, to a payment card network in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key;
However, Dean et al. discloses:
transmit, to a payment card network in response to a detected event associated with validating the cryptographic key, a key exchange request to exchange the cryptographic key; (¶0085)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the Key Management and Hardware Security Integration of Rudzitis et al. by including a key exchange request when key validation detected an event in accordance with the teaching of Dean et al.. This modification enables the combined system to continue process transaction as soon as a new key is received. It reduces the transaction friction while maintains the security standard.
Regarding claims 2, 10 and 18, Rudzitis et al. in view of Dean et al. discloses all limitations as described above. Rudzitis et al. further discloses:
extracting a plurality of attributes of the cryptographic key from the key request; and (col 2 lines 1-7, col 3 lines 54-56)
generating, within the distributed database, the metadata layer comprising a plurality of fields including the plurality of attributes and a mapping of the cryptographic key to the meta layer. (Fig. 1 item 110; col 1 line 65 – col 2 line 1)
Allowable Subject Matter
Claims 3-8, 11-16 and 19-20 are objected to as being dependent upon a rejected base claim, but would be allowable if the rejection(s) under 35 U.S.C. 101 set forth in this Office action, are overcome and if rewritten in independent form including all of the limitations of the base claim and any intervening claims. The reason for allowance will be furnished upon allowance of the application.
Conclusion
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170338949A1 (“Amiri”) discloses systems and methods for facilitating remote key management services in a collaborative cloud-based environment. In one embodiment, the remote key management architecture and techniques described herein provide for local key encryption and automatic generation of a reason code associated with content access. The reason code is logged by a hardware security module which is monitored by a remote client device (e.g., an enterprise client) to control a second (remote) layer of key encryption. The remote client device provides client-side control and configurability of the second layer of key encryption.
US 20220263655A1(“Murray”) discloses techniques for managing encrypted storage resources based on key-metadata. The per-key key-metadata is stored in a key management system/server (KMS) along with respective cryptographic keys. The cryptographic keys in the KMS may be data keys or wrapping keys for the data keys. The management of the storage resources is provided via a central console which is a user interface of a console server in authenticated communication with the KMS. The key-metadata associates cryptographic keys to their respective encrypted storage resources. This association is used by the console server to drive the console. The console allows an admin to view/list all encrypted storage resources and related cryptographic objects including keys and digital certificates, as well as to perform various administrative/management functions on them.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YINGYING ZHOU whose telephone number is (571)272-5308. The examiner can normally be reached 9-5.
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, John W Hayes can be reached on 571-272-6708. 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.
/YINGYING ZHOU/Primary Examiner, Art Unit 3697
Prosecution Insights