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 .
Status of the Claims
Claims 1-21 are presented for examination. Examiner has established objections for claims 2, 9, and 16; § 101 rejection for claims 1-21; and grounds of § 102 rejection for claims 1-21 in the instant Office action.
Claim Objections
Claims 2, 9, and 16, are objected to because of the following informality:
. . . the record data includes a portion of a Universally Unique Identifier (UUID) corresponding to the payment instrument.
There should be no capital letters in words of the claim language. Applicant could amend claims 2, 9, and 16, to recite:
. . . the record data includes a portion of a universally unique identifier (UUID) corresponding to the payment instrument.
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-21 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-7 is a series of steps, which is method (i.e., a process) and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 8-14 is a system, which is also one of the statutory categories of invention. Still further, the claimed invention of claims 15-21 is a non-transitory which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-21 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-21, however, recite an abstract idea of dynamic generation of security codes used in fulfilling a payment authorization request. The creation of dynamic generation of security codes used in fulfilling a payment authorization request, as recited in the independent claims 1, 8, and 15, belongs to certain methods of organizing human activity (i.e., commercial interactions) that are found by the courts to be abstract ideas. The limitations in independent claims 1, 8, and 15, which set forth or describe the recited abstract idea, are found in the following steps:
“dynamically generating a reference dynamic verification value corresponding to the payment instrument, wherein the reference dynamic verification value is dynamically generated by processing the record data, the secret code, and a current time interval through a hashing algorithm” (claims 1, 8, and 15);
“comparing the dynamic verification value to the reference dynamic verification value” (claims 1, 8, and 15); and
“fulfilling the authorization request when the dynamic verification value matches the reference dynamic verification value” (claims 1, 8, and 15).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 8 and 15 recite additional elements:
“one or more processors” (claim 8);
“memory storing thereon instructions that, as a result of being executed by the one or more processors, cause the system to [execute method steps]” (claim 8); and
“a non-transitory computer-readable storage medium storing thereon executable instructions that, as a result of being executed by one or more processors of a computer system, cause the computer system to [execute method steps]” (claim 15).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Further, the following limitations recite insignificant extra solution activity (e.g., data gathering):
“receiving an authorization request associated with a payment instrument, wherein the authorization request includes record data and a dynamic verification value corresponding to the payment instrument” (claims 1, 8, and 15); and
“obtaining a secret code associated with the payment instrument, wherein the secret code is obtained using the record data” (claims 1, 8, and 15).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 1, 8, and 15, here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations).
Conclusion of Step 2A Analysis: The additional elements/limitations in independent claims 1, 8, and 15, which set forth or describe the recited abstract idea are not patent eligible either alone or in combination. Further, the combination of these additional elements and the limitations which set forth or describe the recited abstract idea is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements and the limitations which set forth or describe the recited abstract idea do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Therefore, independent claims 1, 8, and 15, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1, 8, and 15, (see above under Step 2A – Prong 2) are described by Applicant’s Specification in following terms:
[0102] FIG. 7 illustrates a computing system architecture 700, including various components in electrical communication with each other, in accordance with some embodiments. The example computing system architecture 700 illustrated in FIG. 7 includes a computing device 702, which has various components in electrical communication with each other using a connection 706, such as a bus, in accordance with some implementations. The example computing system architecture 700 includes a processing unit 704 that is in electrical communication with various system components, using the connection 706, and including the system memory 714. In some embodiments, the system memory 714 includes read-only memory (ROM), random-access memory (RAM), and other such memory technologies including, but not limited to, those described herein. In some embodiments, the example computing system architecture 700 includes a cache 708 of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor 704. [] Using modules, methods and services such as those described herein, the processor 704 can be configured to perform various actions. In some embodiments, the cache 708 may include multiple types of cache including, for example, level one (L1) and level two (L2) cache. The memory 714 may be referred to herein as system memory or computer system memory. The memory 714 may include, at various times, elements of an operating system, one or more applications, data associated with the operating system or the one or more applications, or other such data associated with the computing device 702.
[0103] Other system memory 714 can be available for use as well. The memory 714 can include multiple different types of memory with different performance characteristics. The processor 704 can include any general purpose processor and one or more hardware or software services, such as service 712 stored in storage device 710, configured to control the processor 704 as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor 704 can be a completely self-contained computing system, containing multiple cores or processors, connectors (e.g., buses), memory, memory controllers, caches, etc. In some embodiments, such a self-contained computing system with multiple cores is symmetric. In some embodiments, such a self-contained computing system with multiple cores is asymmetric. In some embodiments, the processor 704 can be a microprocessor, a microcontroller, a digital signal processor (“DSP”), or a combination of these and/or other types of processors. In some embodiments, the processor 704 can include multiple elements such as a core, one or more registers, and one or more processing units such as an arithmetic logic unit (ALU), a floating point unit (FPU), a graphics processing unit (GPU), a physics processing unit (PPU), a digital system processing (DSP) unit, or combinations of these and/or other such processing units.
[0114] Software and/or data associated with software can be stored in the non-volatile memory and/or the drive unit. In some embodiments (e.g., for large programs) it may not be possible to store the entire program and/or data in the memory at any one time. In such embodiments, the program and/or data can be moved in and out of memory from, for example, an additional storage device such as storage device 710. Nevertheless, it should be understood that for software to run, if necessary, it is moved to a computer readable location appropriate for processing, and for illustrative purposes, that location is referred to as the memory herein. Even when software is moved to the memory for execution, the processor can make use of hardware registers to store values associated with the software, and local cache that, ideally, serves to speed up execution. As used herein, a software program is assumed to be stored at any known or convenient location (from non-volatile storage to hardware registers), when the software program is referred to as “implemented in a computer-readable medium.” A processor is considered to be “configured to execute a program” when at least one value associated with the program is stored in a register readable by the processor.
This is a description of general-purpose computer. Thus, individually, the additional elements of independent claims 8 and 15 are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Further, the additional limitations of “receiving” and “obtaining” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “receiving” and “obtaining” information were considered as insignificant extra-solution activity in Step 2A - Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network), the additional limitations of independent claims 1, 8, and 15, “receive” and “obtain” information over a network in a merely generic manner. The courts have recognized “receiving” and “obtaining” information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 1, 8, and 15, are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1, 8, and 15, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-7 depend on independent claim 1; dependent claims 9-14 depend on independent claim 8; and dependent claims 16-21 depend on independent claim 15. The elements in dependent claims 2-7, 9-14, and 16-21, which set forth or describe the abstract idea, are:
“the record data includes a portion of a universally unique identifier (UUID) corresponding to the payment instrument” (claims 2, 9, and 16: further narrowing the recited abstract idea);
“receiving a request to enable generation of dynamic verification values for the payment instrument, wherein the request includes the secret code and the record data; storing the secret code and the record data; and transmitting a response, wherein when the response is received at a user device, the user device uses the record data and the secret code to generate new dynamic verification values” (claims 3, 10, and 17: insignificant extra solution activity);
“the payment instrument is associated with a static verification value, and the dynamic verification value and the static verification value have a same format” (claims 4, 11, and 18: further narrowing the recited abstract idea);
“the dynamic verification value is generated as a result of the record data being obtained from the payment instrument through a wireless communications session” (claims 5, 12, and 19: further narrowing the recited abstract idea);
“comparing the dynamic verification value to a static verification value associated with the payment instrument when the dynamic verification value does not match the reference dynamic verification value; and fulfilling the authorization request when the dynamic verification value matches the static verification value” (claims 6, 13, and 20: further narrowing the recited abstract idea); and
“the secret code is a shared secret generated through a secure communications session with an application executing on a user device, and wherein the shared secret is generated in response to detection of the payment instrument through the application” (claims 7, 14, and 21: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 2-7, 9-14, and 16-21, do not correct the deficiencies of independent claims 1, 8, and 15, and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-21 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. § 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under § 151, or in an application for patent published or deemed published under § 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-21 are rejected under 35 U.S.C. § 102(a)(2) as being anticipated by Sahota (US 2020/0090183 A1).
As to Independent Claims 1, 8, and 15
Sahota shows:
one or more processors and memory storing thereon instructions (Sahota: page 4, ¶ 39; and Fig. 6, label 615) that, as a result of being executed by the one or more processors, cause the system to:
receiving an authorization request associated with a payment instrument, wherein the authorization request includes record data and a dynamic verification value corresponding to the payment instrument (Sahota: page 4, ¶¶ 38-39);
obtaining a secret code associated with the payment instrument, wherein the secret code is obtained using the record data (Sahota: page 4, ¶¶ 38-39);
dynamically generating a reference dynamic verification value corresponding to the payment instrument, wherein the reference dynamic verification value is dynamically generated by processing the record data, the secret code, and a current time interval through a hashing algorithm (Sahota: page 3, ¶ 29; page 4, ¶ 39; and Fig. 6, label 645);
comparing the dynamic verification value to the reference dynamic verification value (Sahota: page 4, ¶ 39; and Fig. 6, label 650); and
fulfilling the authorization request when the dynamic verification value matches the reference dynamic verification value (Sahota: page 4, ¶ 39; and Fig. 6, label 655).
As to claims 2, 9, and 16: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows that the record data includes a portion of a universally unique identifier (UUID) corresponding to the payment instrument (Sahota: page 4, ¶ 38).
As to claims 3, 10, and 17: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows receiving a request to enable generation of dynamic verification values for the payment instrument, wherein the request includes the secret code and the record data (Sahota: page 4, ¶ 38); storing the secret code and the record data (Sahota: page 4, ¶ 38); and transmitting a response, wherein when the response is received at a user device, the user device uses the record data and the secret code to generate new dynamic verification values (Sahota: page 4, ¶ 39).
As to claims 4, 11, and 18: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows that the payment instrument is associated with a static verification value, and wherein the dynamic verification value and the static verification value have a same format (Sahota: claims 21 and 24).
As to claims 5, 12, and 19: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows that the dynamic verification value is generated as a result of the record data being obtained from the payment instrument through a wireless communications session (Sahota: page 2, ¶ 26; and page 4, ¶ 39).
As to claims 6, 13, and 20: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows comparing the dynamic verification value to a static verification value associated with the payment instrument when the dynamic verification value does not match the reference dynamic verification value (Sahota: page 4, ¶ 39; and claims 21 and 24); and fulfilling the authorization request when the dynamic verification value matches the static verification value (Sahota: page 4, ¶ 39; and claims 21 and 24).
As to claims 7, 14, and 21: Sahota shows all the elements of claims 1, 8, and 15. Sahota also shows that the secret code is a shared secret generated through a secure communications session with an application executing on a user device (Sahota: page 4, ¶ 39), and that the shared secret is generated in response to detection of the payment instrument through the application (Sahota: page 4, ¶ 39).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Warner (US 2017/0169426 A1) discloses: “[0049] Following block 508 is block 510. Block 510 includes a dynamic security code verification process, which may be performed by the dynamic validation service module 204. In some embodiments, the verification process may involve duplicating the process performed in the payment card to generate the dynamic security code and comparing the result of the code generation process performed by the dynamic validation service module 204 with the received dynamic security code value to confirm that the two match.”
Hammad (US 2013/0226802 A1) discloses: “[0006] To address the above problems, a dCVV or a dynamic card verification value can be used. The dCVV can be generated using an algorithm which uses at least a counter and input data such as an account number, expiration date, and other information. The counter can increase by one each time a transaction is conducted. The dCVV can be independently generated by either a portable consumer device or POS terminal at the front end of a transaction and can be sent to a back end computer. The counter may be sent from the merchant to the back end computer so that it knows the current counter value associated with the portable consumer device. In other cases, the counter may simply be present at the back end computer. In the latter case, the counter increments every time the back end computer sees a transaction. The back end computer, using a similar algorithm to the one that generated the dCVV at the front end, the counter value, and input data, can independently generate a second dCVV. If the received dCVV and the generated dCVV match, the transaction can be considered authentic. If the dCVVs do not match, this may indicate that the transaction is fraudulent.”
Manessis (US 2009/0055893 A1) discloses: “A method is disclosed, which includes receiving a message including an account identifier and a first verification value. The method uses the account identifier to select a dynamic verification value process from at least two dynamic verification value processes. Then, using the selected dynamic verification value process, a second verification value is determined. Next, the method determines if the first verification value and the second verification value match or are within an expected range.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday - Friday, 10 am - 6 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691
Prosecution Insights