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 Claims
This action is in response to the amendment filed 18 September 2025. Claims 1, 8, and 15 have been amended. Claims 1-20 are currently pending and have been examined.
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.
Claims 1-20 are rejected on the ground of nonstatutory double patenting over claims 1-20 of U.S. Patent No. 11.170 071 B2 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows:
18/772,759
11,107,071
A method for facilitating transactions, the method comprising, by a merchant subsystem:
interfacing with a computing device to initialize a transaction;
providing transaction data to the computing device; issuing, to a commercial entity subsystem, a request to validate the merchant subsystem;
receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on
at least a portion of the transaction data,
at least a portion of validation data generated by the commercial entity subsystem in conjunction with validating the merchant subsystem, and
at least a portion of secure data gathered at the computing device; and
utilizing the encrypted secure data to complete the transaction.
A method for providing a transaction between a merchant subsystem and an electronic device, the method comprising, at a commercial entity subsystem:
receiving, from the merchant subsystem, a challenge request that includes a merchant identifier that is associated with (1) the merchant subsystem, and (2) a merchant online resource of the electronic device, wherein the challenge request includes a signature established using a merchant key associated with the merchant subsystem; obtaining the merchant key based on the merchant identifier; validating the signature using the merchant key;
indicating to the electronic device that the merchant online resource is valid; receiving validation data and secure data from the electronic device;
validating the electronic device based on the validation data;
encrypting, using the merchant key, the secure data to establish encrypted secure data; and
providing the encrypted secure data to the electronic device to cause the electronic device to execute the transaction with the merchant subsystem.
Although the claims at issue are not identical, they are not patentably distinct from each other because it is clear the all the elements of present application to be found in the patented application. The difference between the present application and the patented application is in fact that the patent includes many more elements and is thus much more specific. Thus, the invention of the patent is in effect a “species” of the “generic” invention of the present application. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010,2015-16 (Fed. Cir.1993). Since the present application’s claims are anticipated by the claims of the patented application.
Claims 1-20 are rejected on the ground of nonstatutory double patenting over claims 1-20 of U.S. Patent No. 12,039,525 B2 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
18,772,759
12,039,525
A method for facilitating transactions, the method comprising, by a merchant subsystem:
interfacing with a computing device to initialize a transaction;
providing transaction data to the computing device; issuing, to a commercial entity subsystem, a request to validate the merchant subsystem;
receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on
at least a portion of the transaction data,
at least a portion of validation data generated by the commercial entity subsystem in conjunction with validating the merchant subsystem, and
at least a portion of secure data gathered at the computing device; and
utilizing the encrypted secure data to complete the transaction.
A method for facilitating transactions, the method comprising, by a computing device:
interfacing with a merchant subsystem to cause the merchant subsystem to issue, to a commercial entity subsystem, a request to validate the merchant subsystem;
receiving, from the merchant subsystem, transaction data in conjunction with initializing a transaction;
receiving, from the commercial entity subsystem, first validation data that indicates the commercial entity subsystem has validated the merchant subsystem in response to the request; generating a package that includes
(i) at least a portion of the transaction data received from the merchant subsystem, (ii) at least a portion of the first validation data received from the commercial entity subsystem, and (iii) secure data gathered at the computing device;
identifying an encryption key that is accessible to the commercial entity subsystem; encrypting the package using the encryption key to produce an encrypted package;
providing the encrypted package to the commercial entity subsystem; receiving encrypted secure data from the commercial entity subsystem in response to the commercial entity subsystem accessing and authenticating at least a portion of the package; and
providing the encrypted secure data to the merchant subsystem to complete the transaction.
Although the claims at issue are not identical, they are not patentably distinct from each other because it is clear the all the elements of present application to be found in the patented application. The difference between the present application and the patented application is in fact that the patent includes many more elements and is thus much more specific. Thus, the invention of the patent is in effect a “species” of the “generic” invention of the present application. It has been held that the generic invention is “anticipated” by the “species”. See In re Goodman, 29 USPQ2d 2010,2015-16 (Fed. Cir.1993). Since the present application’s claims are anticipated by the claims of the patented application.
Furthermore, there is no apparent reason why applicant was prevented from presenting claims corresponding to those of the instant application during prosecution of the application which matured into a patent. See In re Schneller, 397 F.2d 350, 158 USPQ 210 (CCPA 1968). See also MPEP § 804.
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.
Step 1: The claims 1-7 are a method, claims 8-14 are a medium and claims 15-20 are a system. Thus, each independent claim, on its face, is directed to one of the statutory categories of 35 U.S.C. §101. However, the claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2-Prong 1: Independent claims (1,8 and 15) recite interfacing to initializing a transaction, providing transaction data, issuing a request to validate , receiving encrypted secure data receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on (i) at least a portion of the transaction data, (ii) at least a portion of validation data generated by the commercial entity subsystem in conjunction with validating the merchant subsystem, and (iii) at least a portion of secure data gathered at the computing device; and utilizing the encrypted secure data to complete the transaction. These limitation as drafted, are a process, that under its broadest reasonable interpretation, cover commercial interaction or legal interaction, validation or marketing activity for the recitation of generic computer components. That is other than receiving “ a computing device” nothing in the claims element preclude the step from practically being performed by a certain interaction or activity between a person and a computer. For example, but for the “computing device” language, the claims encompasses the user issuing validating the merchant subsystem to utilizing to complete a transaction, which is a method of managing interactions between people. The mere nominal recitation of a generic computing device does not take the claim out of the methods of organizing human interactions grouping. Thus, the claim recites an abstract idea.
Step 2-Prong 2: The claims as a whole merely describes how to generally “apply” the concept of validating data generating by the commercial entity subsystem in a computer environment. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform an existing medical records update process. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea.
Step 2B: As noted previously, the claim as a whole merely describes how to generally “apply” the concept of validating the merchant subsystem in a computer environment. Thus, even when viewed as a whole, nothing in the claim adds significantly more (i.e., an inventive concept) to the abstract idea. The claim is ineligible.
Dependent claims 2-7 , 9-14, and 17-20, these claims recite limitation that futher define the same abstract idea noted in the claims 1,8 and 16. These claims do not contain any futher additional element per step 2A prong 2. Therefore, the considered patent ineligible for that same reason above.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 are rejected under 35 U.S.C. 102(a1) as being anticipated by Khan et al (US Pub., 2015/0095238 A1)
With respect to claim 1, Khan teaches a method for facilitating transactions, the method comprising, by a merchant subsystem(paragraph [0029], discloses merchant subsystem):
interfacing with a computing device to initialize a transaction (Fig. 5 and paragraph [0046], discloses process 500 may begin step 502 where electronic device 100 may encrypt card data [initialize a truncation] ) ;
providing transaction data to the computing device (Fig. 6, 660, discloses receive potential transaction data) ;
issuing, to a commercial entity subsystem, a request to validate the merchant subsystem(Fig. 6 paragraph [0054], discloses commercial entity subsystem 400 may populate a table 430 to associated a merchant key 157 with merchant resource (e.g., application 113 or website) for enabling a secure commerce creditanl data commucation (e.g., an online-based communication between device and merchant subsystem system and paragraph [0057], discloses at step 611, process 600 may include receiving intent and authentication by a user device for to utilized specific credential for carryout a financial transaction for a particular merchant);
receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on
at least a portion of the transaction data,
at least a portion of validation data generated by the commercial entity
subsystem in conjunction with validating the merchant subsystem, and
at least a portion of secure data gathered at the computing device (paragraph [0058], discloses process 600 may include device 100 generating, encrypted and transmitting commercial entity subsystem 400 for use by commercial entity subsystem …, paragraph [0059], discloses encrypted commercial entity credential data [validation data] 663, along any additional information such as some of potential transaction data 660 [at least portion of transaction data] credential data identification of merchant, identification of the prices and/or identification of the product server or any other suitable information …), and wherein the encrypted secured data is encrypted using merchant key assocted with the merchant subsystem (Fig. 8, encrypting with the commercial entity , the credential information using the identider merchant key, paragraph [0062], discloses the credential data transmitted .., creditanl data of encrypted merchant creditanl data .., the merchant transaction data may be encrypted with merchant key and paragraph [0083], discloses the commercial entity subsystem may encrypted the credential information from data suing merchet key, processing may include transmitting with the commercial entity second data to at least one or merchant and electronic device where ith second data may include the credential information encrypted the identified merchant key…, paragraph [0085], dislcies transmitting with the electronic device to commercial entity the generated second data [which is encrypted with merchant key] and the identified merchant information device 100 may transmit to commercial entity subsystem 400
the generated second data (e.g., encrypted commercial entity credential data 663) and the identified merchant data as commercial entity transaction data ; and
utilizing the encrypted secure data to complete the transaction(paragraph [0069], discloses process 600 is able to be completed, not only may commercial entity subsystem 400 be satisfied that the financial transaction is between a known device 100 (e.g., due to shared access information (e.g., 155a, 155b, 156k, 151k, and/or 158k)) and a known merchant subsystem 200 (e.g., due to a known merchant key 157), but merchant subsystem 200 may also be satisfied that the financial transaction is being conducted with a trusted device 100 (e.g., due to the received communication data 670/671 being encrypted with a merchant key 157 from a trusted commercial entity subsystem), wherein utilizing encrypted secure data to complete the transaction included decrypting the encrypted secure data (paragraph [0069], discloses financial transaction between a known device 100 (e.g., due to shared access information.., and a known merchant subsystem .., financial transaction is being conducted with a trusted device to the received communication data being encrypted with the merchant key from a trusted commercial entity subsystem) .
With respect to claim 2, Khan teaches elements of claim 1, furthermore , Khan teaches the method wherein validating the merchant subsystem comprises: providing, to the commercial entity subsystem, a challenge request that includes a merchant identifier that is associated with (1) the merchant subsystem(paragraph [0069], discloses commercial entity subsystem may configured to provide a validation check after receiving commercial entity transaction data …, commercial entity subsystem may determine the received commercial entity data identifies a merchant whose merchant key has expired or has otherwise been terminated or not recognize) , and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature established using a merchant key associated with the merchant subsystem, to cause the commercial entity subsystem to: obtain the merchant key based on the merchant identifier, and validate the signature using the merchant key (paragraph [0061], discloses establish commercial entity subsystem 400 as the creator of such encrypted merchant credential data 667 and/or may let merchant subsystem 200 ensure that encrypted merchant credential data 667 has not been modified after being signed and paragraph [0065], discloses merchant subsystem may retrieve the corresponding merchant privet key …).
With respect to claim 3, Khan teaches elements of claim 2, furthermore , Khan teaches the method wherein, prior to receiving the challenge request, the commercial entity subsystem receives, during a registration process with the merchant subsystem, (1) the merchant identifier, and (2) the merchant key(paragraph [0054], discloses a merchant may be required to register as a member of a program run by the commercial entity of commercial entity subsystem .., a merchant may obtain multiple certificate and thus may hod more than one identify , such a unique merchant identifier provide by merchant subsystem…, ) .
With respect to claim 4, Khan teaches elements of claim 2, furthermore , Khan teaches the method wherein the transaction data includes a validation session identifier: established between the computing device and the merchant subsystem in conjunction with initializing the transaction, and provided by the merchant subsystem to the commercial entity subsystem in the challenge request (paragraph [0081], discloses a time stamp that may have been generated and included in data by commercial entity subsystem .., analyzed by merchant subsystem as portion of data ..such analysis (e.g., comprising of the time stamp to them which data was received [session identifier]).
With respect to claim 5, Khan teaches elements of claim 1, furthermore , Khan teaches the method wherein the secure data includes: payment credential data to be used in a financial transaction, or health data to be used in a health transaction(paragraph [0024], discloses a secure element of an electronic device may be used for securely conducting an online financial transaction between the electronic device and a merchant. The credential may be encrypted by the secure element using an access key not available to any non-secure portion of the electronic device. That encrypted credential and information identifying the merchant for a proposed online financial transaction ( e.g., merchant information obtained by the device via a merchant application or via a merchant's website) may be transmitted by the electronic device to a commercial entity that may also have access to the access key).
With respect to claim 6, Khan teaches elements of claim 1, furthermore , Khan teaches the method wherein the encrypted secure data is encrypted with a merchant key associated with the merchant subsystem(paragraph [0034], disclose utilize an appropriate merchant key for providing a layer of security to a commercial credential data and paragraph [0047], discloses commercial entity subsystem 400.., re-encrypted from the have been that has been re-encrypted using a merchant key known to both …).
With respect to claim 7, Khan teaches elements of claim 1, furthermore , Khan teaches the method wherein the secure data enables the commercial entity subsystem to validate the computing device (paragraph [0033], disclose commercial entity subsystem 400 may be response for managing of access key . .. Commercial entity subsystem 400 may store its version of access key 155b in a secure element of commercial entity subsystem 400. An access SSD of NFC component 120 with access key 155b may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110 of device 100, such as a biometric input component) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction ( e.g., with a credential of a credential SSD of NFC component 120)).
With respect to claim 8, Khan teaches a non-transitory computer readable storage medium configured to store instructions that when executed by at least one processor included in merchant subsystem, cause the merchant subsystem to facilitating transactions (paragraph [0029], discloses merchant subsystem, processor and memory), by carrying out steps that include:
interfacing with a computing device to initialize a transaction (Fig. 5 and paragraph [0046], discloses process 500 may begin step 502 where electronic device 100 may encrypt card data [initialize a truncation] ) ;
providing transaction data to the computing device (Fig. 6, 660, discloses receive potential transaction data) ;
issuing, to a commercial entity subsystem, a request to validate the merchant subsystem(Fig. 6 paragraph [0054], discloses commercial entity subsystem 400 may populate a table 430 to associated a merchant key 157 with merchant resource (e.g., application 113 or website) for enabling a secure commerce creditanl data commucation (e.g., an online-based communication between device and merchant subsystem system and paragraph [0057], discloses at step 611, process 600 may include receiving intent and authentication by a user device for to utilized specific credential for carryout a financial transaction for a particular merchant);
receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on
at least a portion of the transaction data,
at least a portion of validation data generated by the commercial entity
subsystem in conjunction with validating the merchant subsystem, and
at least a portion of secure data gathered at the computing device (paragraph [0058], discloses process 600 may include device 100 generating, encrypted and transmitting commercial entity subsystem 400 for use by commercial entity subsystem …, paragraph [0059], discloses encrypted commercial entity credential data [validation data] 663, along any additional information such as some of potential transaction data 660 [at least portion of transaction data] credential data identification of merchant, identification of the prices and/or identification of the product server or any other suitable information …) and wherein the encrypted secured data is encrypted using merchant key assocted with the merchant subsystem (Fig. 8, encrypting with the commercial entity , the credential information using the identider merchant key, paragraph [0062], discloses the credential data transmitted .., creditanl data of encrypted merchant creditanl data .., the merchant transaction data may be encrypted with merchant key and paragraph [0083], discloses the commercial entity subsystem may encrypted the credential information from data suing merchet key, processing may include transmitting with the commercial entity second data to at least one or merchant and electronic device where ith second data may include the credential information encrypted the identified merchant key…, paragraph [0085], dislcies transmitting with the electronic device to commercial entity the generated second data [which is encrypted with merchant key] and the identified merchant information device 100 may transmit to commercial entity subsystem 400
the generated second data (e.g., encrypted commercial entity credential data 663) and the identified merchant data as commercial entity transaction data ); and
utilizing the encrypted secure data to complete the transaction(paragraph [0069], discloses process 600 is able to be completed, not only may commercial entity subsystem 400 be satisfied that the financial transaction is between a known device 100 (e.g., due to shared access information (e.g., 155a, 155b, 156k, 151k, and/or 158k)) and a known merchant subsystem 200 (e.g., due to a known merchant key 157), but merchant subsystem 200 may also be satisfied that the financial transaction is being conducted with a trusted device 100 (e.g., due to the received communication data 670/671 being encrypted with a merchant key 157 from a trusted commercial entity subsystem), wherein utilizing encrypted secure data to complete the transaction included decrypting the encrypted secure data (paragraph [0069], discloses financial transaction between a known device 100 (e.g., due to shared access information.., and a known merchant subsystem .., financial transaction is being conducted with a trusted device to the received communication data being encrypted with the merchant key from a trusted commercial entity subsystem) .
With respect to claim 9, Khan teaches elements of claim 8, furthermore , Khan teaches the non-transitory computer readable storage medium wherein validating the merchant subsystem comprises: providing, to the commercial entity subsystem, a challenge request that includes a merchant identifier that is associated with (1) the merchant subsystem(paragraph [0069], discloses commercial entity subsystem may configured to provide a validation check after receiving commercial entity transaction data …, commercial entity subsystem may determine the received commercial entity data identifies a merchant whose merchant key has expired or has otherwise been terminated or not recognize) , and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature established using a merchant key associated with the merchant subsystem, to cause the commercial entity subsystem to: obtain the merchant key based on the merchant identifier, and validate the signature using the merchant key (paragraph [0061], discloses establish commercial entity subsystem 400 as the creator of such encrypted merchant credential data 667 and/or may let merchant subsystem 200 ensure that encrypted merchant credential data 667 has not been modified after being signed and paragraph [0065], discloses merchant subsystem may retrieve the corresponding merchant privet key …).
With respect to claim 10, Khan teaches elements of claim 9, furthermore , Khan teaches the non-transitory computer readable storage medium wherein, prior to receiving the challenge request, the commercial entity subsystem receives, during a registration process with the merchant subsystem, (1) the merchant identifier, and (2) the merchant key(paragraph [0054], discloses a merchant may be required to register as a member of a program run by the commercial entity of commercial entity subsystem .., a merchant may obtain multiple certificate and thus may hod more than one identify , such a unique merchant identifier provide by merchant subsystem…, ) .
With respect to claim 11, Khan teaches elements of claim 9, furthermore , Khan teaches the non-transitory computer readable storage medium wherein the transaction data includes a validation session identifier: established between the computing device and the merchant subsystem in conjunction with initializing the transaction, and provided by the merchant subsystem to the commercial entity subsystem in the challenge request (paragraph [0081], discloses a time stamp that may have been generated and included in data by commercial entity subsystem .., analyzed by merchant subsystem as portion of data ..such analysis (e.g., comprising of the time stamp to them which data was received [session identifier]).
With respect to claim 12, Khan teaches elements of claim 9, furthermore , Khan teaches the non-transitory computer readable storage medium wherein the secure data includes: payment credential data to be used in a financial transaction, or health data to be used in a health transaction(paragraph [0024], discloses a secure element of an electronic device may be used for securely conducting an online financial transaction between the electronic device and a merchant. The credential may be encrypted by the secure element using an access key not available to any non-secure portion of the electronic device. That encrypted credential and information identifying the merchant for a proposed online financial transaction ( e.g., merchant information obtained by the device via a merchant application or via a merchant's website) may be transmitted by the electronic device to a commercial entity that may also have access to the access key).
With respect to claim 13, Khan teaches elements of claim 8, furthermore , Khan teaches the non-transitory computer readable storage medium wherein the encrypted secure data is encrypted with a merchant key associated with the merchant subsystem(paragraph [0034], disclose utilize an appropriate merchant key for providing a layer of security to a commercial credential data and paragraph [0047], discloses commercial entity subsystem 400.., re-encrypted from the have been that has been re-encrypted using a merchant key known to both …).
With respect to claim 14, Khan teaches elements of claim 8, furthermore , Khan teaches the non-transitory computer readable storage medium wherein the secure data enables the commercial entity subsystem to validate the computing device (paragraph [0033], disclose commercial entity subsystem 400 may be response for managing of access key . .. Commercial entity subsystem 400 may store its version of access key 155b in a secure element of commercial entity subsystem 400. An access SSD of NFC component 120 with access key 155b may be configured to determine intent and local authentication of a user of device 100 (e.g., via one or more input components 110 of device 100, such as a biometric input component) and, in response to such a determination, may be configured to enable another particular SSD for conducting a payment transaction ( e.g., with a credential of a credential SSD of NFC component 120)).
With respect to claim 15, Khan teaches a merchant subsystem configured to facilitating transactions, the merchant subsystem (paragraph [0029], discloses merchant subsystem) comprising:
at least one processor(paragraph [0029], discloses merchant processor); and
at least one memory storing instructions that, when executed by the at least one processor (paragraph [0029], discloses merchant memory components) cause the merchant subsystem to carry out steps that includes:
interfacing with a computing device to initialize a transaction (Fig. 5 and paragraph [0046], discloses process 500 may begin step 502 where electronic device 100 may encrypt card data [initialize a truncation] ) ;
providing transaction data to the computing device (Fig. 6, 660, discloses receive potential transaction data) ;
issuing, to a commercial entity subsystem, a request to validate the merchant subsystem(Fig. 6 paragraph [0054], discloses commercial entity subsystem 400 may populate a table 430 to associated a merchant key 157 with merchant resource (e.g., application 113 or website) for enabling a secure commerce creditanl data commucation (e.g., an online-based communication between device and merchant subsystem system and paragraph [0057], discloses at step 611, process 600 may include receiving intent and authentication by a user device for to utilized specific credential for carryout a financial transaction for a particular merchant);
receiving encrypted secure data from the computing device, wherein the encrypted secure data is based on
at least a portion of the transaction data,
at least a portion of validation data generated by the commercial entity subsystem in conjunction with validating the merchant subsystem, and
at least a portion of secure data gathered at the computing device (paragraph [0058], discloses process 600 may include device 100 generating, encrypted and transmitting commercial entity subsystem 400 for use by commercial entity subsystem …, paragraph [0059], discloses encrypted commercial entity credential data [validation data] 663, along any additional information such as some of potential transaction data 660 [at least portion of transaction data] credential data identification of merchant, identification of the prices and/or identification of the product server or any other suitable information …) and wherein the encrypted secured data is encrypted using merchant key assocted with the merchant subsystem (Fig. 8, encrypting with the commercial entity , the credential information using the identider merchant key, paragraph [0062], discloses the credential data transmitted .., creditanl data of encrypted merchant creditanl data .., the merchant transaction data may be encrypted with merchant key and paragraph [0083], discloses the commercial entity subsystem may encrypted the credential information from data suing merchet key, processing may include transmitting with the commercial entity second data to at least one or merchant and electronic device where ith second data may include the credential information encrypted the identified merchant key…, paragraph [0085], dislcies transmitting with the electronic device to commercial entity the generated second data [which is encrypted with merchant key] and the identified merchant information device 100 may transmit to commercial entity subsystem 400the generated second data (e.g., encrypted commercial entity credential data 663) and the identified merchant data as commercial entity transaction data ).
utilizing the encrypted secure data to complete the transaction(paragraph [0069], discloses process 600 is able to be completed, not only may commercial entity subsystem 400 be satisfied that the financial transaction is between a known device 100 (e.g., due to shared access information (e.g., 155a, 155b, 156k, 151k, and/or 158k)) and a known merchant subsystem 200 (e.g., due to a known merchant key 157), but merchant subsystem 200 may also be satisfied that the financial transaction is being conducted with a trusted device 100 (e.g., due to the received communication data 670/671 being encrypted with a merchant key 157 from a trusted commercial entity subsystem), wherein utilizing encrypted secure data to complete the transaction included decrypting the encrypted secure data (paragraph [0069], discloses financial transaction between a known device 100 (e.g., due to shared access information.., and a known merchant subsystem .., financial transaction is being conducted with a trusted device to the received communication data being encrypted with the merchant key from a trusted commercial entity subsystem) .
With respect to claim 16, Khan teaches elements of claim 15, furthermore , Khan teaches the merchant subsystem wherein validating the merchant subsystem comprises: providing, to the commercial entity subsystem, a challenge request that includes a merchant identifier that is associated with (1) the merchant subsystem(paragraph [0069], discloses commercial entity subsystem may configured to provide a validation check after receiving commercial entity transaction data …, commercial entity subsystem may determine the received commercial entity data identifies a merchant whose merchant key has expired or has otherwise been terminated or not recognize) , and (2) a merchant online resource of the computing device, wherein the challenge request includes a signature established using a merchant key associated with the merchant subsystem, to cause the commercial entity subsystem to: obtain the merchant key based on the merchant identifier, and validate the signature using the merchant key (paragraph [0061], discloses establish commercial entity subsystem 400 as the creator of such encrypted merchant credential data 667 and/or may let merchant subsystem 200 ensure that encrypted merchant credential data 667 has not been modified after being signed and paragraph [0065], discloses merchant subsystem may retrieve the corresponding merchant privet key …).
With respect to claim 17, Khan teaches elements of claim 2, furthermore , Khan teaches the merchant subsystem wherein, prior to receiving the challenge request, the commercial entity subsystem receives, during a registration process with the merchant subsystem, (1) the merchant identifier, and (2) the merchant key(paragraph [0054], discloses a merchant may be required to register as a member of a program run by the commercial entity of commercial entity subsystem .., a merchant may obtain multiple certificate and thus may hod more than one identify , such a unique merchant identifier provide by merchant subsystem…, ) .
With respect to claim 18, Khan teaches elements of claim 16, furthermore , Khan teaches the merchant subsystem wherein the transaction data includes a validation session identifier: established between the computing device and the merchant subsystem in conjunction with initializing the transaction, and provided by the merchant subsystem to the commercial entity subsystem in the challenge request (paragraph [0081], discloses a time stamp that may have been generated and included in data by commercial entity subsystem .., analyzed by merchant subsystem as portion of data ..such analysis (e.g., comprising of the time stamp to them which data was received [session identifier]).
With respect to claim 19, Khan teaches elements of claim 15, furthermore , Khan teaches the merchant subsystem wherein the secure data includes: payment credential data to be used in a financial transaction, or health data to be used in a health transaction(paragraph [0024], discloses a secure element of an electronic device may be used for securely conducting an online financial transaction between the electronic device and a merchant. The credential may be encrypted by the secure element using an access key not available to any non-secure portion of the electronic device. That encrypted credential and information identifying the merchant for a proposed online financial transaction ( e.g., merchant information obtained by the device via a merchant application or via a merchant's website) may be transmitted by the electronic device to a commercial entity that may also have access to the access key).
With respect to claim 20, Khan teaches elements of claim 15, furthermore , Khan teaches the merchant subsystem wherein the encrypted secure data is encrypted with a merchant key associated with the merchant subsystem(paragraph [0034], disclose utilize an appropriate merchant key for providing a layer of security to a commercial credential data and paragraph [0047], discloses commercial entity subsystem 400.., re-encrypted from the have been that has been re-encrypted using a merchant key known to both …).
Prior art:
Khan et al (US Pub., 2015/0095238 A1) discloses systems, methods, and computer-readable media for securely conducting online payments with a secure element of an electronic device are provided. In one example embodiment, a method includes, inter alia, at an electronic device, generating first data that includes payment card data, generating second data by encrypting the first data and merchant information with a first key, transmitting to a commercial entity subsystem the generated second data, receiving third data that includes the first data encrypted with a second key that is associated with the merchant information.
Response to Arguments
Applicant's arguments of 35 U.S.C 101 rejections with respect to claim 1-20 filed on 18 September 2025 have been fully considered but they are not persuasive. Applicant arguments of the pending claims are not “directed to” abstract idea. The claims recite specific technological operations performed by defined system. For instance, independent claim 1 recites … is not persuasive. The steps as described in the claim (interfacing with a computing device to initialize a transaction, etc.) are rejection under 35 U.S.C. § 101 because they appear to be directed to the abstract idea of a business method or financial transaction performed on generic computer components, rather than a specific technical improvement to a computing device or technology.
The claimed method is a process for conducting financial transactions using generic computers which is well-known activities and considered abstract. The described steps (initializing a transaction, providing data, validating an entity, receiving and utilizing secure data) are fundamental business practices or data processing steps that can, in principle, be performed by a human (albeit more slowly) or on paper. The use of "a computing device," "commercial entity subsystem," and "merchant subsystem" without further technical limitations suggests the use of generic technology. The encryption and decryption steps, while technical in nature, may be considered well-understood, routine, and conventional activities when implemented on a generic computer.
In order to overcome the 35 U.S.C 101 rejection, an applicant should need to demonstrate that the claims are directed to a specific, non-generic technological improvement, perhaps by:
Claiming a specific, unconventional method of encryption or decryption that improves the function of the computer itself, rather than just applying a known method.
Specifying a particular, non-generic machine or a novel configuration of hardware components that is integral to the process, not just "a computing device".
Clearly articulating how the claimed invention solves a specific technical problem in a non-abstract way, such as improving the efficiency or security of the system in a way that is not well-understood, routine, or conventional.
Applicants’ arguments of the limitation are not simply fundamental economic practice or organizing human activity, but instead recite a technical solution for improving security of electronic transaction through subsystem validation and encryption techniques tied to particular device see Enfish, LLC v. Microsoft Corp, 822 F.3d.1327, 1336 (Fed. Cir.2016)(claims directed to a specific improvement in computer functionality are not abstract) is not persuasive.
Enfish is an example of something the courts found not to be abstract. The instant Application lacks the self-referential table of Enfish which proved to the element that was determined to be non-abstract. Therefore, Enfish is not applicable to the instant case. Examiner used Alice/ Mayo two-part analysis used in the rejection above to determine that the claims are ineligible.
Applicants arguments of the specific combination of elements in not a mere recitation of generic computer functions, but instead represents an inventive arrangement that improves the security of electronic payment transactions. See DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245,1259 (Fed. Cir. 2014) (claims that recite a solution “necessarily rooted in computer technology” are patent-eligible) is not persuasive.
In the holding from DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1257 (Fed. Cir. 2014) case, the claimed invention is rotted in a computer technology that doesn't just apply an old business practice on the internet; instead, it provides a unique, technical method where a user clicking a hyperlink on a host website was directed to a hybrid web page that combined the host's "look and feel" with product information from a third-party merchant.
However, the claims at issue conducts financial transactions using generic computers which is well-known activities and considered abstract. The described steps (initializing a transaction, providing data, validating an entity, receiving and utilizing secure data) are fundamental business practices or data processing steps that can, in principle, be performed by a human (albeit more slowly) or on paper.
Thus, the Examiner maintains the rejection of said claims under 35 U.S.C. 101, and Applicant’s arguments are considered to be non-persuasive.
Applicant's arguments of 35 U.S.C 103 rejections with respect to claim 1-20 filed on 18 September 2025 have been fully considered but they are not persuasive. Applicants arguments of the cited portion of Khan is directed to data that is being sent between the electronic device 100 and commercial entity subsystem and not “encrypted secure data from the computing device” is not persuasive.
Khan teaches wherein the encrypted secured data is encrypted using merchant key assocted with the merchant subsystem (Fig. 8, encrypting with the commercial entity , the credential information using the identider merchant key, paragraph [0062], discloses the credential data transmitted .., creditanl data of encrypted merchant creditanl data .., the merchant transaction data may be encrypted with merchant key and paragraph [0083], discloses the commercial entity subsystem may encrypted the credential information from data suing merchet key, processing may include transmitting with the commercial entity second data to at least one or merchant and electronic device where ith second data may include the credential information encrypted the identified merchant key…, paragraph [0085], dislcies transmitting with the electronic device to commercial entity the generated second data [which is encrypted with merchant key] and the identified merchant information device 100 may transmit to commercial entity subsystem 400 the generated second data (e.g., encrypted commercial entity credential data 663) and the identified merchant data as commercial entity transaction data ).
Therefore, Kahan teaches address the transaction between the electronic device and merchant subsystem and addressed the limitation of wherein the encrypted secured data is encrypted using merchant key assocted with the merchant subsystem as cited above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SABA DAGNEW whose telephone number is (571)270-3271. The examiner can normally be reached 9-6:45.
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, Waseem Ashraf can be reached at (571) 270 -3948. The fax phone number for the organization where this application or proceeding