Detailed Action
Claims 1-14, and 16-21 are pending and are 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 .
Status of Claims
Claims 1, 5, 7, 9, 12, 14, 16, and 18 are currently amended.
Claim 15 is cancelled.
Claim 21 is newly added.
Response to Remarks
35 U.S.C. § 101
Applicant argues “the claims recite limitations that cannot reasonably be performed in the human mind. For example, at least the executing a transaction related to the electronic device, generating a block which includes: block data for the transaction, and a hash field, as well as storing the block cannot reasonably be performed in the human mind. Indeed, the human mind is not capable of transmitting the signature data to the first application to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data, as recited in the claims. Similarly, the claims are not directed toward methods of organizing human activity: the claims are not directed toward fundamental economic principles or practices, commercial or legal information, or managing personal behavior. Accordingly, since the claims are not directed toward operations that could be performed in the human mind, the claims are directed toward statutory subject matter.” (Applicant Arguments, 2025-10-23). However, the question is not whether the human mind can literally perform every recited implementation detail, but whether the claim, as a whole, is directed to an abstract idea that is being carried out on generic computing components. The claims focus remains an abstract authorization/control concept, which is a classic risk mitigation scheme used in commercial interactions, even if implemented using cryptography and a blockchain. Even accepting that humans cannot mentally ‘broadcast to a blockchain’, the claims are still directed to an abstract idea, and the additional blockchain/cryptographic elements amount to applying that idea using conventional computer functionality rather than reciting a specific technological improvement. Accordingly, this contention is unpersuasive.
35 U.S.C. § 102 and § 103
Remark 1: Applicant argues “Smets and Collinge fail to disclose the presently claimed combination of features recited in independent claim 1. For example, Applicant submits that Smets and Collinge fail to disclose wherein the computer-executable instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: acquire, in the second execution environment, a signature request for a transaction generated through the first application, acquire first state data regarding a state of the electronic device in response to the signature request, determine, based on the first state data, whether a signature condition stored in the second execution environment is satisfied, generate, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment, and transmit the signature data to the first application to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data ", as recited in claim 1.” (id).
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Smets, Collinge, and Perullo) still teach the currently amended independent claims, as shown at least in paragraphs 34, 58, 65 of Perullo, and as further outlined in paragraphs 40-42, and 74-80 of this action. Indeed, Smets teaches the core secure-signing architecture in which an untrusted/first application requests a transaction signature and a trusted/second environment holds the private key, checks required conditions, and generates signature data that is returned to the requesting application. Collinge adds the state-detection and policy-gating concept by using sensed/contextual device state to determine whether the signature/authorization condition is satisfied before permitting the secure operation. Finally, Perullo teaches the blockchain-specific completion step by having the component that had obtained the necessary signature(s) broadcast the now-signed (e.g. ‘complete’) transaction to a blockchain network for posting. Accordingly, this contention is unpersuasive.
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.
Claims 1-8:
Step 1
Claims 1-8 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of controlling authorization for a transaction based on a condition, and performing an approval step if the condition passes. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. Indeed, the claims recite a condition-based transaction signing process that mitigates risk by ensuring a signature is only applied if an entity a transaction data meets a predefined policy. This mechanism supports commercial or legal interactions, such as authorizing sales or financial transactions, by preventing unauthorized or fraudulent signatures. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
An electronic device comprising:
memory storing computer-executable instructions, a first application for execution in a first execution environment and a second application for execution in a second execution environment; and
at least one processor comprising processing circuitry,
wherein the computer-executable instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:
acquire, in the second execution environment, a signature request for a transaction generated through the first application,
acquire first state data through regarding a state of the electronic device in response to the signature request,
determine, based on the first state data, whether a signature condition stored in the second execution environment is satisfied,
generate, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment, and
transmit the signature data to the first application to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Indeed, the additional elements, when considered both individually and in combination, only involve a computer performing functions that correspond to the acts required to carry out the abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 2-13 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
display, in the first execution environment, a result screen indicating whether the signature condition is satisfied through the display, based on the determination result.
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
display, in the first execution environment, a result screen indicating that the signature condition is not satisfied through the display, in response to a determination that the signature condition is not satisfied, and
terminate an operation for the transaction.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
acquire, in the first execution environment, a configuration request for configuring the signature condition and configuration information for the signature condition through the first application,
transmit the configuration request and the configuration information to the second application,
configure, in the second execution environment, the signature condition, based on the configuration information, according to the acquired configuration request, and
store the signature condition in the second execution environment.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
acquire, in the second execution environment, second state data regarding the state of the electronic device based on the configuration information, and
wherein the signature condition is configured based on the configuration information and the second state data.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
transmit, in the second execution environment, a confirm request for the signature condition to the first application,
display, in the first execution environment, a screen indicating the confirm request through the display by using the first application, and
acquire a response for the confirm request by using the first application.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the first execution environment and the second execution environment respectively include a first driver and a second driver that are capable of controlling a state detection circuit of the electronic device, and
wherein the first state data is acquired from the state detection circuit through the second driver.
Claim 8 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the first execution environment includes a rich execution environment (REE), and
wherein the second execution environment includes a trusted execution environment (TEE).
Claim 21 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the first state data comprises at least one of location information of the electronic device or connection network information of the electronic device, and
wherein the signature condition is satisfied based on the at least one of the location information of the electronic device or the connection network information of the electronic device.
Claims 9-15:
Step 1
Claims 9-15 are directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 9 recites (i.e., sets forth or describes) an abstract idea of controlling authorization for a transaction based on a condition, and performing an approval step if the condition passes. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract idea are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, managing personal behavior or relationships or interactions between people, as they recite following rules or instructions, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. Indeed, the claims recite a condition-based transaction signing process that mitigates risk by ensuring a signature is only applied if an entity a transaction data meets a predefined policy. This mechanism supports commercial or legal interactions, such as authorizing sales or financial transactions, by preventing unauthorized or fraudulent signatures. More specifically, the following underlined claim elements recite the abstract idea while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A method performed by an electronic device capable of operating a plurality of execution environments including a first execution environment and a second execution environment, the method comprising:
acquiring, in the second execution environment, a signature request for a transaction generated through a first application executed in the first execution environment;
acquiring first state data regarding a state of the electronic device in response to the signature request;
determining, based on the first state data, whether a signature condition stored in the second execution environment is satisfied;
generating, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment; and
transmitting the signature data to the first application to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 9 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Indeed, the additional elements, when considered both individually and in combination, only involve a computer performing functions that correspond to the acts required to carry out the abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 9, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea and generally link the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims
Claims 10-15 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 10 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising:
displaying, in the first execution environment, a result screen indicating whether the signature condition is satisfied through a display included in the electronic device, based on the determination result.
Claim 11 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising:
acquiring, in the first execution environment, a configuration request for configuring the signature condition and configuration information for the signature condition through the first application;
transmitting the configuration request and the configuration information to a second application executed in the second execution environment;
configuring, in the second execution environment, the signature condition, based on the configuration request and the configuration information acquired through the second application; and
storing the signature condition in the second execution environment.
Claim 12 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the configuring of the signature condition comprises:
acquiring second state data regarding the state the electronic device based on the configuration information; and
configuring the signature condition, based on the configuration information and the second state data.
Claim 13 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the configuring of the signature condition comprises:
transmitting a confirm request for the signature condition to the first application in the second execution environment;
displaying a screen indicating the confirm request through a display included in the electronic device through the first application in the first execution environment; and
acquiring a response for the confirm request.
Claim 14 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the first execution environment and the second execution environment respectively include a first driver and a second driver that are capable of controlling a state detection circuit of the electronic device, and
wherein the acquiring of the first state data comprises: deactivating the first driver and activating the second driver to acquire the first state data from the state detection circuit through the second driver.
Claims 16-20:
Step 1
Claims 16-20 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 16 recites (i.e., sets forth or describes) an abstract idea of controlling authorization for a transaction based on a condition, and performing an approval step if the condition passes. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. Also, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “mental processes” grouping of abstract ideas. The mental processes abstract idea grouping is defined as concepts performed in the human mind, and examples of mental processes recite observations, evaluations, judgments, and opinions. Claims recite a mental process when they recite limitations that can practically be performed in the human mind, with or without the use of a physical aid. The use of a physical aid to help perform a mental step does not negate the mental nature of the limitation, but simply accounts for variations in memory capacity from one person to another. Further, claims can recite a mental process even if they are claimed as being performed on a computer. See MPEP § 2106.04(a)(2), subsection III. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” and “mental processes” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. Indeed, the claims recite a condition-based transaction signing process that mitigates risk by ensuring a signature is only applied if an entity a transaction data meets a predefined policy. This mechanism supports commercial or legal interactions, such as authorizing sales or financial transactions, by preventing unauthorized or fraudulent signatures. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
An electronic device comprising:
memory storing computer-executable instructions a first application for execution in a first execution environment and a second application for execution in a second execution environment; and
at least one processor comprising processing circuitry,
wherein computer-executable instructions, when executed by the at least one processor individually or collectively, cause the electronic device to:
acquire, in the second execution environment, a signature request for a transaction generated through the first application,
acquire first state data regarding a state of the electronic device in response to the signature request,
determine, based on the first state data, whether a signature condition stored in the second execution environment is satisfied,
transmit the determination result to the first application, and
display, in the first execution environment, a result screen presenting information for the determination result and the signature condition.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 16 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Indeed, the additional elements, when considered both individually and in combination, only involve a computer performing functions that correspond to the acts required to carry out the abstract idea. Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 16, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea, and generally links the use of the judicial exception to a particular technological environment. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 17-20 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 17 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
in response to determining that the signature condition is not satisfied as a result of the determination, display the result screen including information for a signature condition that is not satisfied.
Claim 18 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
generate, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment, and
transmit the signature data to the first application to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data.
Claim 19 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
display, in the first execution environment, a configuration screen for configuring the signature condition through the first application,
acquire configuration information for a configuration request and the signature condition by receiving a user input based on the configuration screen,
transmit the configuration request and the configuration information to the second application,
configure, in the second execution environment, in response to the configuration request based on the configuration information, and
store the signature condition in the second execution environment.
Claim 20 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to:
transmit a confirm request for the signature condition from the second execution environment to the first application,
control, in the first execution environment, the display to display a screen presenting the confirm request through the first application, and
acquire a user response for the confirm request through the first application.
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-14, and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over Smets et al. (US2016/0217467) (hereinafter “Smets”) in view of Collinge et al. (US2017/0083915) (hereinafter “Collinge”) in further view of Perullo et al. (US20210374733A1) (hereinafter “Perullo”).
As per Claim 1, 9, and 16, Smets teaches:
An electronic device comprising: memory storing computer-executable instructions, a first application for execution in a first execution environment and a second application for execution in a second execution environment; (“provides for a highly flexible, simple and secure means for carrying out secure processing by utilizing the capabilities of a trusted execution environment (TEE) and a Rich execution environment (REE) within a user's mobile device. It is not necessary in the above configuration for any external system elements to be utilized in the main processing steps.” (Para. 0010); (“The mobile computing device comprises a secure communications channel between the first application and the second trusted application. The second trusted application is configured to generate one or more data items and to provide the one or more data items to the first application via the secure communications channel.” (Para. 0009); (“the first application may comprise all of the software libraries and logic required to carry out the process, and is able to simply call the second application at the appropriate time to generate the data items securely. The present disclosure therefore effectively separates the processing steps between the REE and the TEE, and improves the flexibility and security of the system. Optionally, a first one of the one or more data items comprises an authentication code for use in authenticating a process executed by the first application in the first execution environment.” (Para. 0012-0013))
at least one processor comprising processing circuitry, wherein the computer-executable instructions, when executed by the at least one processor individually or collectively, cause the electronic device to: (“the mobile computing device having at least one processor and at least one memory together providing a first execution environment and a second execution environment logically isolated from the first execution environment. The method comprises establishing a secure communications channel between a first application in the first execution environment and a second trusted application in the second execution environment. The method comprises generating one or more data items by the second trusted application and providing the one or more data items to the first application via the secure communications channel. The method comprises executing the first application in the first execution environment.” (Para. 0032); (“a mobile phone 1, acting as a proxy for a payment card 1 a. The mobile device has at least one processor 101 and at least one memory 102 together providing at least one execution environment, as described further below. These devices have firmware and applications run in at least one Rich execution environment (REE) with an operating system such as iOS, Android or Windows. Payment devices will typically be equipped with means to communicate with other elements of a payment infrastructure. These communication means may comprise antennae and associated hardware and software to enable communication by NFC and associated contactless card protocols such as those defined under ISO/IEC 14443, or they may comprise an antenna and associated hardware and software to allow local wireless networking using 802.11 protocols or any combination of the above.” (Para. 0062); (“The mobile device 1 has at least one processor and at least one memory—these are not shown explicitly in FIG. 2, but between them they provide at least two execution environments.” (Para. 0067))
acquire, in the second execution environment, a signature request for a transaction generated through the first application, (“The mobile device 1 has at least one processor and at least one memory—these are not shown explicitly in FIG. 2, but between them they provide at least two execution environments.” (Para. 0067); (“The MAC provided to the MPA 14 therefore functions as a ‘cryptographic signature’ across the UN, details of the time window during which the transaction was carried out and (optionally) the transaction amount for that particular transaction, and allows for subsequent verification of the transaction by the card issuing system (by authenticating the uniqueness of the transaction and how up-to-date the transaction information is).” (Para. 0085); (“the generation of an authentication code by the second application within the secure TEE, and its subsequent transmission to the first application to authenticate the process carried out by the first application (in the relatively less secure REE), increases the security of the system as sensitive data does not leave the TEE.” (Para. 0014))
acquire first state data . . . in response to the signature request, (“The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.). The main elements in the mobile device which are usually actively involved in the data processing associated with a payment transaction are a Mobile Payment Application (MPA) 14 which runs in the REE, and a MasterCard Trusted Payment Application (MTPA) 16 which runs in the TEE.” (Para. 0069-0070); (“the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)
determine, based on the first state data, whether a signature condition stored in the second execution environment is satisfied, (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “this allows the mobile computing device (and therefore the first application) to communicate with an external server of the payment provider or card issuer, and thereby to receive data of information relating to the process executed by the first application. In the context of a payment transaction, this received data may be used in the generation of a MAC and the authentication of the transaction by the second trusted application.” (Para. 0031); “The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.). The main elements in the mobile device which are usually actively involved in the data processing associated with a payment transaction are a Mobile Payment Application (MPA) 14 which runs in the REE, and a MasterCard Trusted Payment Application (MTPA) 16 which runs in the TEE.” (Para. 0069-0070); (“the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)
generate, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment, and (“the MTPA 16 in the TEE comprises a generic cryptographic-generation engine and provides cryptographic services to the MPA 14 to support the MPA's payment processing functionality. The MTPA 16 generates a Message Authentication Code (MAC) in the form of a cryptogram which is used to verify that a particular transaction has been successfully carried out and also to indicate whether CVM was performed successfully by the Trusted CVM App 12.” (Para. 0073); (“This separation of functionalities between the MPA 14 running in the REE and the MTPA 16 running in the TEE provides efficient and effective partitioning of tasks and data storage, without requiring a large amount of communication between the two environments. This ensures that sensitive information is retained securely within the TEE whilst the majority of the processing can be carried out by the MPA 14 in the REE.” (Para. 0074); (“The MPA 14 next outputs at Steps 125, 125 a one or more commands to the MTPA 16 to generate a cryptogram to verify the transaction; these correspond to the “generateMAC” commands shown in the figure. Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. It is therefore preferable for the cryptogram or MAC to be generated by the MTPA 16 within the TEE, however, it should be noted that it is also possible for the MTPA 16 to return to the MPA 14 the cryptographic key(s) necessary for the generation of the cryptogram by the MPA 14. The data used to generate the MAC varies depending on the type of transaction.” (Para. 0084))
transmit the signature data to the first application. (“the method further comprises retaining, by the second trusted application, the sensitive data elements within the second execution environment; and transmitting, from the second trusted application to the first application via the secure communications channel, the data elements relating only to the first application.” (Para. 0045); (“The card issuing system 5 comprises a MasterCard Digital Enablement Service (MDES 42), a digitization and tokenization platform that is in operative communication with the POI terminal via a payment network (not shown). The card issuing system also comprises a wallet service provider (henceforth referred to as a KMS (Key Management Service) Wallet 44) that is in operative communication with the mobile device and the MDES 42, and via which the MDES 42 communicates with and transmits data to the MPA 14 and the MTPA 16. Specifically, the KMS Wallet 44 communicates with the mobile device via an SSL/TLS interface which provides a secure channel of communication with the MPA 14 and MTPA 16.” (Para. 0077); (“The transaction process 200 begins when the user attempts to complete a remote transaction and a request to allow this transaction is transmitted at Step 205 to the MPA 14 from the payment gateway. This request prompts the MPA 14 to open a virtual wallet and request that the user confirms the transaction details.” (Para. 0089)).
Smets does not disclose:
“a state of the electronic device” (claim 1).
However, as per Claim 1, Collinge in the analogous art of secured payments between parties, teaches: “a state of the electronic device”. (See “the payment device 100 is a smartphone. The payment device 100 comprises a digital wallet module 102. The digital wallet module 102 comprises a wallet processor 104, a consent risk manager module 106, a communication module 108 and a payment application module 110. The consent risk manager module 106, the communication module 108 and the payment application module 110 are each operatively connected to the wallet processor 104.” (Para. 0031); “user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context.” (Para. 0009); “CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.” (Para. 0081); “CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.” (Para. 0007)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to include hardware-based components for detecting the state of a system during an authentication process. Therefore, the incentives of providing increased transaction security between the parties provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Smets does not disclose:
“to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data ” (claim 1).
However, as per Claim 1, Perullo in the analogous art of blockchain-based transaction verification, teaches: “to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data ”. (See “For example, the transaction request may include a public address (e.g., public key 258) corresponding to client device 102, a signature generated by client device 102 using private key 256).” (Para. 0065); (“Each verification institution 110 may then generate a second signature for the transaction, using the private key hosted by verification network 105. The second signature for the transaction may be transmitted by verification institution 110 to verification network 105 with the verification offer. In some examples, the second signature may represent a private key created and/or maintained by verification institution 110 (a verification provider) and/or provided via verification network 105. Accordingly, verification network 105 receives at least two signatures.” (Para. 0034); (“Transaction agent 209 may broadcast the completed transaction to blockchain network 108, such that the transaction may be posted thereto.” (Para. 0058)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Perullo to include broadcasting a signed/‘completed’ transaction to a blockchain network. Therefore, the incentives of providing preserving private-key security while enforcing state-based authorization controls provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Smets teaches:
The electronic device of claim 1, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: display, in the first execution environment, a result screen indicating whether the signature condition is satisfied through the display, based on the determination result. (“Once this has been done, the MPA 14 notifies the user at Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The cryptogram that is returned to the MPA 14 at Step 240 serves substantially the same purpose as that returned in the MST transaction, as it allows the card issuer to verify and confirm the legitimacy of the transaction in online authorization and clearing carried out by the merchant.” (Para. 0094); “At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0090)).
As per Claim 3, Smets teaches:
The electronic device of claim 2, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: display, in the first execution environment, a result screen indicating that the signature condition is not satisfied through the display, in response to a determination that the signature condition is not satisfied, and terminate an operation for the transaction. (“Once this has been done, the MPA 14 notifies the user at Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The cryptogram that is returned to the MPA 14 at Step 240 serves substantially the same purpose as that returned in the MST transaction, as it allows the card issuer to verify and confirm the legitimacy of the transaction in online authorization and clearing carried out by the merchant.” (Para. 0094); “At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0090)).
As per Claim 4, Smets teaches:
The electronic device of claim 1, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: acquire, in the first execution environment, a configuration request for configuring the signature condition and configuration information for the signature condition through the first application, transmit the configuration request and the configuration information to the second application, configure, in the second execution environment, the signature condition, based on the configuration information, according to the acquired configuration request, and store the signature condition in the second execution environment. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The second trusted application is configured to generate one or more data items and to provide the one or more data items to the first application via the secure communications channel.” (Para. 0009); “the second trusted application is configured to receive configuration data from the first application via the secure communications channel, the configuration data comprising instructions for generating the one or more data items.” (Para. 0011); “the MPA 14 subsequently begins to configure itself to carry out a contactless payment. This configuring step requires that messages be exchanged between sub-modules of the MPA 14 to ensure that the correct business logic and software algorithms are implemented to carry out an NFC-enabled transaction. Once the MPA 14 has been set up correctly to perform an NFC-enabled transaction, the MPA 14 sends a command at Step 310 via the HCE API to the mobile device MST interface to effectively shut the interface down and prevent it from broadcasting any further data to the POI terminal.” (Para. 0098)).
As per Claim 5, Smets teaches:
The electronic device of claim 4, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: acquire, in the second execution environment, second state data . . . based on the configuration information, and wherein the signature condition is configured based on the configuration information and the second state data. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.).” (Para. 0069); “In order to complete the transaction with the POI terminal, the MPA 14 generates and provides at Step 135 track data to the POI terminal (including the MAC that was generated by the MTPA 16). When the merchant wishes to demonstrate the authenticity of the transaction to the card issuer, it is the MAC that is provided for verification purposes. The MAC provided to the MPA 14 therefore functions as a ‘cryptographic signature’ across the UN, details of the time window during which the transaction was carried out and (optionally) the transaction amount for that particular transaction, and allows for subsequent verification of the transaction by the card issuing system (by authenticating the uniqueness of the transaction and how up-to-date the transaction information is).” (Para. 0085); “the process 100 begins when the user initiates a transaction by opening the payment application on the mobile device. At Step 105, the user authenticates himself by providing biometric data to the sensor, and this data is subsequently passed to the Trusted CVM App 12 to be authenticated.” (Para. 0082)).
Smets does not disclose:
“a state of the electronic device” (claim 5).
However, as per Claim 5, Collinge in the analogous art of secured payments between parties, teaches: “a state of the electronic device”. (See “the payment device 100 is a smartphone. The payment device 100 comprises a digital wallet module 102. The digital wallet module 102 comprises a wallet processor 104, a consent risk manager module 106, a communication module 108 and a payment application module 110. The consent risk manager module 106, the communication module 108 and the payment application module 110 are each operatively connected to the wallet processor 104.” (Para. 0031); “user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context.” (Para. 0009); “CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.” (Para. 0081); “CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.” (Para. 0007)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to include hardware-based components for detecting the state of a system during an authentication process. Therefore, the incentives of providing increased transaction security between the parties provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 6, Smets teaches:
The electronic device of claim 4, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: transmit, in the second execution environment, a confirm request for the signature condition to the first application, display, in the first execution environment, a screen indicating the confirm request through the display by using the first application, and acquire a response for the confirm request by using the first application. (“The transaction process 200 begins when the user attempts to complete a remote transaction and a request to allow this transaction is transmitted at Step 205 to the MPA 14 from the payment gateway. This request prompts the MPA 14 to open a virtual wallet and request that the user confirms the transaction details. At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0089-090); “The MPA 14 subsequently completes the final stages of processing and provides at Step 245 the necessary DSRP transaction data (including the cryptogram) to the payment gateway via the remote payment API. Once this has been done, the MPA 14 notifies the user st Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The MPA 14 next outputs at Steps 125, 125 a one or more commands to the MTPA 16 to generate a cryptogram to verify the transaction; these correspond to the “generateMAC” commands shown in the figure. Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. It is therefore preferable for the cryptogram or MAC to be generated by the MTPA 16 within the TEE, however, it should be noted that it is also possible for the MTPA 16 to return to the MPA 14 the cryptographic key(s) necessary for the generation of the cryptogram by the MPA 14. The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084)).
As per Claim 7, Smets teaches:
The electronic device of claim 1, wherein the first execution environment and the second execution environment respectively include a . . ., and wherein the first state data is acquired from the . . . through the . . . (“. . . a highly flexible, simple and secure means for carrying out secure processing by utilizing the capabilities of a trusted execution environment (TEE) and a Rich execution environment (REE) within a user's mobile device. It is not necessary in the above configuration for any external system elements to be utilized in the main processing steps. The above configuration also has an advantage in that it allows the most sensitive information to be retained securely within the TEE (and never released to the REE), whilst enabling the majority (if not all) of the processing to be carried out within the mobile device.” (Para. 0010); “present disclosure therefore effectively separates the processing steps between the REE and the TEE, and improves the flexibility and security of the system.” (Para. 0012); “the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)).
Smets does not disclose:
“first driver and a second driver that are capable of controlling a state detection circuit of the electronic device” (claim 7).
However, as per Claim 7, Collinge in the analogous art of secured payments between parties, teaches: “first driver and a second driver that are capable of controlling the state detection circuit”. (See “the payment device 100 is a smartphone. The payment device 100 comprises a digital wallet module 102. The digital wallet module 102 comprises a wallet processor 104, a consent risk manager module 106, a communication module 108 and a payment application module 110. The consent risk manager module 106, the communication module 108 and the payment application module 110 are each operatively connected to the wallet processor 104.” (Para. 0031); “The decision module 124 is arranged to process input information 148 available from the payment device 100 including: User actions and behavioural information 150; Transaction context information 152; Payment device information 154; Terminal data 156; Environment information 158; Proprietary check data 160; and Other information 162.” (Para. 0035-0042); “user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context.” (Para. 0009); “CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.” (Para. 0081); “CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.” (Para. 0007)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to include hardware-based components for detecting the state of a system during an authentication process, along with multiple additional components for controlling the state detection system. Therefore, the incentives of providing increased control over transaction security between the parties provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 8, Smets teaches:
The electronic device of claim 1, wherein the first execution environment includes a rich execution environment (REE), and wherein the second execution environment includes a trusted execution environment (TEE). (“provides for a highly flexible, simple and secure means for carrying out secure processing by utilizing the capabilities of a trusted execution environment (TEE) and a Rich execution environment (REE) within a user's mobile device. It is not necessary in the above configuration for any external system elements to be utilized in the main processing steps. The above configuration also has an advantage in that it allows the most sensitive information to be retained securely within the TEE (and never released to the REE), whilst enabling the majority (if not all) of the processing to be carried out within the mobile device.” (Para. 0010); “present disclosure therefore effectively separates the processing steps between the REE and the TEE, and improves the flexibility and security of the system.” (Para. 0012); “the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)).
As per Claim 10, Smets teaches:
The method of claim 9, further comprising: displaying, in the first execution environment, a result screen indicating whether the signature condition is satisfied through a display included in the electronic device, based on the determination result. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “Once this has been done, the MPA 14 notifies the user at Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The cryptogram that is returned to the MPA 14 at Step 240 serves substantially the same purpose as that returned in the MST transaction, as it allows the card issuer to verify and confirm the legitimacy of the transaction in online authorization and clearing carried out by the merchant.” (Para. 0094); “At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0090)).
As per Claim 11, Smets teaches:
The method of claim 9, further comprising: acquiring, in the first execution environment, a configuration request for configuring the signature condition and configuration information for the signature condition through the first application; transmitting the configuration request and the configuration information to a second application executed in the second execution environment; configuring, in the second execution environment, the signature condition, based on the configuration request and the configuration information acquired through the second application; and storing the signature condition in the second execution environment. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The second trusted application is configured to generate one or more data items and to provide the one or more data items to the first application via the secure communications channel.” (Para. 0009); “the second trusted application is configured to receive configuration data from the first application via the secure communications channel, the configuration data comprising instructions for generating the one or more data items.” (Para. 0011); “the MPA 14 subsequently begins to configure itself to carry out a contactless payment. This configuring step requires that messages be exchanged between sub-modules of the MPA 14 to ensure that the correct business logic and software algorithms are implemented to carry out an NFC-enabled transaction. Once the MPA 14 has been set up correctly to perform an NFC-enabled transaction, the MPA 14 sends a command at Step 310 via the HCE API to the mobile device MST interface to effectively shut the interface down and prevent it from broadcasting any further data to the POI terminal.” (Para. 0098)).
As per Claim 12, Smets teaches:
The method of claim 11, wherein the configuring of the signature condition comprises: acquiring second state data . . . based on the configuration information; and configuring the signature condition, based on the configuration information and the second state data. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.).” (Para. 0069); “In order to complete the transaction with the POI terminal, the MPA 14 generates and provides at Step 135 track data to the POI terminal (including the MAC that was generated by the MTPA 16). When the merchant wishes to demonstrate the authenticity of the transaction to the card issuer, it is the MAC that is provided for verification purposes. The MAC provided to the MPA 14 therefore functions as a ‘cryptographic signature’ across the UN, details of the time window during which the transaction was carried out and (optionally) the transaction amount for that particular transaction, and allows for subsequent verification of the transaction by the card issuing system (by authenticating the uniqueness of the transaction and how up-to-date the transaction information is).” (Para. 0085); “the process 100 begins when the user initiates a transaction by opening the payment application on the mobile device. At Step 105, the user authenticates himself by providing biometric data to the sensor, and this data is subsequently passed to the Trusted CVM App 12 to be authenticated.” (Para. 0082)).
Smets does not disclose:
“a state of the electronic device” (claim 12).
However, as per Claim 12, Collinge in the analogous art of secured payments between parties, teaches: “a state of the electronic device”. (See “the payment device 100 is a smartphone. The payment device 100 comprises a digital wallet module 102. The digital wallet module 102 comprises a wallet processor 104, a consent risk manager module 106, a communication module 108 and a payment application module 110. The consent risk manager module 106, the communication module 108 and the payment application module 110 are each operatively connected to the wallet processor 104.” (Para. 0031); “user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context.” (Para. 0009); “CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.” (Para. 0081); “CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.” (Para. 0007)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to include hardware-based components for detecting the state of a system during an authentication process. Therefore, the incentives of providing increased transaction security between the parties provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 13, Smets teaches:
The method of claim 11, wherein the configuring of the signature condition comprises: transmitting a confirm request for the signature condition to the first application in the second execution environment; displaying a screen indicating the confirm request through a display included in the electronic device through the first application in the first execution environment; and acquiring a response for the confirm request. (“The transaction process 200 begins when the user attempts to complete a remote transaction and a request to allow this transaction is transmitted at Step 205 to the MPA 14 from the payment gateway. This request prompts the MPA 14 to open a virtual wallet and request that the user confirms the transaction details. At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0089-090); “The MPA 14 subsequently completes the final stages of processing and provides at Step 245 the necessary DSRP transaction data (including the cryptogram) to the payment gateway via the remote payment API. Once this has been done, the MPA 14 notifies the user st Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The MPA 14 next outputs at Steps 125, 125 a one or more commands to the MTPA 16 to generate a cryptogram to verify the transaction; these correspond to the “generateMAC” commands shown in the figure. Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. It is therefore preferable for the cryptogram or MAC to be generated by the MTPA 16 within the TEE, however, it should be noted that it is also possible for the MTPA 16 to return to the MPA 14 the cryptographic key(s) necessary for the generation of the cryptogram by the MPA 14. The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084)).
As per Claim 14, Smets teaches:
The method of claim 9, wherein the first execution environment and the second execution environment respectively include a . . ., and wherein the acquiring of the first state data is acquiring of the first state data from the . . . through the . . .. (“. . . a highly flexible, simple and secure means for carrying out secure processing by utilizing the capabilities of a trusted execution environment (TEE) and a Rich execution environment (REE) within a user's mobile device. It is not necessary in the above configuration for any external system elements to be utilized in the main processing steps. The above configuration also has an advantage in that it allows the most sensitive information to be retained securely within the TEE (and never released to the REE), whilst enabling the majority (if not all) of the processing to be carried out within the mobile device.” (Para. 0010); “present disclosure therefore effectively separates the processing steps between the REE and the TEE, and improves the flexibility and security of the system.” (Para. 0012); “the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)).
deactivating the . . . and activating the . . . to acquire the first state data from the state detection circuit through the . . . (“The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.). The main elements in the mobile device which are usually actively involved in the data processing associated with a payment transaction are a Mobile Payment Application (MPA) 14 which runs in the REE, and a MasterCard Trusted Payment Application (MTPA) 16 which runs in the TEE.” (Para. 0069-0070); (“the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024)
Smets does not disclose:
“first driver and a second driver that are capable of controlling state detection circuit of the electronic device” (claim 14).
However, as per Claim 14, Collinge in the analogous art of secured payments between parties, teaches: “first driver and a second driver that are capable of controlling the state detection circuit”. (See “the payment device 100 is a smartphone. The payment device 100 comprises a digital wallet module 102. The digital wallet module 102 comprises a wallet processor 104, a consent risk manager module 106, a communication module 108 and a payment application module 110. The consent risk manager module 106, the communication module 108 and the payment application module 110 are each operatively connected to the wallet processor 104.” (Para. 0031); “The decision module 124 is arranged to process input information 148 available from the payment device 100 including: User actions and behavioural information 150; Transaction context information 152; Payment device information 154; Terminal data 156; Environment information 158; Proprietary check data 160; and Other information 162.” (Para. 0035-0042); “user authentication step may comprise a consumer device cardholder verification method (CDCVM). This user authentication step may be taken outside a transaction context, but may persist into a transaction context. The user consent step may be an explicit user consent made within a transaction process. The user consent may in embodiments be an implicit user consent inferred from user or device actions or user or device context.” (Para. 0009); “CDCVM data according to this approach may be considered to have three layers: CDCVM method, CDCVM quality and CDCVM integrity. Methods may include PIN, password, pattern, biometrics (fingerprint, iris, face) or combinations of methods (typically “something you are” and “something you know”). Quality may relate to number of digits of a PIN, number of characters of a password (and requirements for character types), number of dots or complexity of a pattern and false acceptance rate of a biometric.” (Para. 0081); “CDCVMs involve a user of the payment device verifying their identity on the payment device itself. During a payment transaction using CDCVM, no additional customer action is required on the POI or paper receipt to verify the customer, such as a signature or PIN. For example, the mobile device may be arranged to receive a PIN and/or comprise a biometric sensor for verifying the identity of a user. The payment device can then be used with a POI to undertake a payment transaction.” (Para. 0007)
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to include hardware-based components for detecting the state of a system during an authentication process, along with multiple additional components for controlling the state detection system. Therefore, the incentives of providing increased control over transaction security between the parties provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 17, Smets teaches:
The electronic device of claim 16, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: in response to determining that the signature condition is not satisfied as a result of the determination, display the result screen including information for a signature condition that is not satisfied. (“Once this has been done, the MPA 14 notifies the user st Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The cryptogram that is returned to the MPA 14 at Step 240 serves substantially the same purpose as that returned in the MST transaction, as it allows the card issuer to verify and confirm the legitimacy of the transaction in online authorization and clearing carried out by the merchant.” (Para. 0094); “At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0090)).
As per Claim 18, Smets teaches:
The electronic device of claim 16, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: generate, based on the determination result, signature data by executing a digital signature for the transaction with a private key stored in the second execution environment, and transmit the signature data to the first application . . . (“Once this has been done, the MPA 14 notifies the user at Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The cryptogram that is returned to the MPA 14 at Step 240 serves substantially the same purpose as that returned in the MST transaction, as it allows the card issuer to verify and confirm the legitimacy of the transaction in online authorization and clearing carried out by the merchant.” (Para. 0094); “At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0090)).
Smets does not disclose:
“to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data ” (claim 18).
However, as per Claim 18, Perullo in the analogous art of blockchain-based transaction verification, teaches: “to broadcast, in a blockchain network, the transaction signed with the private key, and the signature data ”. (See “For example, the transaction request may include a public address (e.g., public key 258) corresponding to client device 102, a signature generated by client device 102 using private key 256).” (Para. 0065); (“Each verification institution 110 may then generate a second signature for the transaction, using the private key hosted by verification network 105. The second signature for the transaction may be transmitted by verification institution 110 to verification network 105 with the verification offer. In some examples, the second signature may represent a private key created and/or maintained by verification institution 110 (a verification provider) and/or provided via verification network 105. Accordingly, verification network 105 receives at least two signatures.” (Para. 0034); (“Transaction agent 209 may broadcast the completed transaction to blockchain network 108, such that the transaction may be posted thereto.” (Para. 0058)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Perullo to include broadcasting a signed/‘completed’ transaction to a blockchain network. Therefore, the incentives of providing preserving private-key security while enforcing state-based authorization controls provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 19, Smets teaches:
The electronic device of claim 16, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: display, in the first execution environment, a configuration screen for configuring the signature condition through the first application, acquire configuration information for a configuration request and the signature condition by receiving a user input based on the configuration screen, transmit the configuration request and the configuration information to the second application, configure, in the second execution environment, in response to the configuration request based on the configuration information, and store the signature condition in the second execution environment. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The second trusted application is configured to generate one or more data items and to provide the one or more data items to the first application via the secure communications channel.” (Para. 0009); “the second trusted application is configured to receive configuration data from the first application via the secure communications channel, the configuration data comprising instructions for generating the one or more data items.” (Para. 0011); “the MPA 14 subsequently begins to configure itself to carry out a contactless payment. This configuring step requires that messages be exchanged between sub-modules of the MPA 14 to ensure that the correct business logic and software algorithms are implemented to carry out an NFC-enabled transaction. Once the MPA 14 has been set up correctly to perform an NFC-enabled transaction, the MPA 14 sends a command at Step 310 via the HCE API to the mobile device MST interface to effectively shut the interface down and prevent it from broadcasting any further data to the POI terminal.” (Para. 0098)).
As per Claim 20, Smets teaches:
The electronic device of claim 19, wherein the computer-executable instructions, when executed by the at least one processor, further cause the electronic device to: transmit a confirm request for the signature condition from the second execution environment to the first application, control, in the first execution environment, the display to display a screen presenting the confirm request through the first application, and acquire a user response for the confirm request through the first application. (“Each profile in DGI C404 comprises a compilation of personalized data. For example, each profile may relate to a specific operation or portion of a method used to generate a MAC for a particular transaction type. A profile therefore contains information regarding what rules to follow when generating a MAC; for example, whether to use an ATC, and what type of key and/or which fixed data values are to be used. The process of generating a MAC begins when the MTPA 16 is initially invoked by the MPA 14 using the setContext command—this command transfers a profile identifier to the MTPA 16, instructing the MTPA 16 how to configure itself to receive and enact subsequent commands according to that identified profile. . . The profile identifier defines which of these data are required for a particular cryptogram and the constraints on their sizes.” (Para. 0113-114, and 0118); “Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. . . The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084); “The transaction process 200 begins when the user attempts to complete a remote transaction and a request to allow this transaction is transmitted at Step 205 to the MPA 14 from the payment gateway. This request prompts the MPA 14 to open a virtual wallet and request that the user confirms the transaction details. At Step 210, the user confirms the payment details and selects a digitized card to use, initiating the processing of a DSRP transaction by the MPA 14; the user also authenticates himself at Step 215 in a similar manner to that described above with reference to FIGS. 3A and 3B. The Trusted CVM App 12 confirms that the user has been successfully authenticated and the processing of a DSRP by the MPA 14/MTPA 16 is begun.” (Para. 0089-090); “The MPA 14 subsequently completes the final stages of processing and provides at Step 245 the necessary DSRP transaction data (including the cryptogram) to the payment gateway via the remote payment API. Once this has been done, the MPA 14 notifies the user st Step 250 of the status of the transaction (via the user interface), and also provides updates at Step 250 a upon receiving confirmation at Step 255 from the remote payment API regarding the success/failure of the transaction, so that the user remains informed of the transaction progress at all times.” (Para. 0093); “The MPA 14 next outputs at Steps 125, 125 a one or more commands to the MTPA 16 to generate a cryptogram to verify the transaction; these correspond to the “generateMAC” commands shown in the figure. Upon receipt of each generateMAC command, the MTPA 16 generates and returns at Steps 130, 130 a a cryptogram (or MAC) to the MPA 14. The generation of the cryptogram may require the use of one or more cryptographic keys, which are provided to and retained by the MTPA 16 within the TEE. It is therefore preferable for the cryptogram or MAC to be generated by the MTPA 16 within the TEE, however, it should be noted that it is also possible for the MTPA 16 to return to the MPA 14 the cryptographic key(s) necessary for the generation of the cryptogram by the MPA 14. The data used to generate the MAC varies depending on the type of transaction, and the method and data inputs used to generate a MAC for an MST transaction is described later with reference to FIG. 6.” (Para. 0084)).
As per Claim 21, Smets teaches:
The electronic device of claim 1, wherein the first state data comprises at least one of . . . of the electronic device or . . . of the electronic device, and wherein the signature condition is satisfied based on the at least one of the . . . of the electronic device or the . . . of the electronic device. (“The mobile device 1 comprises a biometric sensor 10 and an additional user interface (not shown) suitable for user interaction during the transaction process. The sensor 10 and user interface are connected to a Trusted Shared-CVM (Card Verification Method) Application 12 (henceforth referred to as the Trusted CVM App), the operation and programming of which is specific to the operating system of the mobile device 1 (e.g. IOS, Android etc.). The main elements in the mobile device which are usually actively involved in the data processing associated with a payment transaction are a Mobile Payment Application (MPA) 14 which runs in the REE, and a MasterCard Trusted Payment Application (MTPA) 16 which runs in the TEE.” (Para. 0069-0070); (“the second trusted application may generate an ATC (Application Transaction Counter), or other type of unique representation of the transaction, within the secure TEE, thereby increasing the security of the payment process as sensitive data is processed and retained only within the TEE. In addition, generating a transaction authentication code (e.g. a cryptogram or Message Authentication Code MAC) within the secure TEE, which code is used to verify that a particular transaction has been successfully carried out and that cardholder verification has been performed successfully, ensures that the security of transaction is maintained and that external (or additional) verification of the transaction is not required.” (Para. 0024).
Smets does not disclose:
“location information” (claim 21).
However, as per Claim 21, Perullo in the analogous art of blockchain-based verification networks, teaches: “location information”. (See “Network 205 may be of any suitable type, including individual connections via the Internet, such as cellular or Wi-Fi networks.” (Para. 0044); “risk analyzer 264 may assess the risk associated with verifying the cryptocurrency transaction by taking in account one or more parameters that include, but are not limited to, a current location of client device 102 (e.g., at a location associated with the user).” (Para. 0062); “In some examples, verification network 105 may determine and include situational details associated with the partially-signed transaction that may be useful (to verification pool 106) in analyzing a likelihood of attempted fraud. Non-limiting examples of situational details may include a time of the transaction, a value of the transaction, a geolocation of client device 102.” (Para. 0066)).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Perullo to include location information as an input to risk analysis. Therefore, the incentives of providing limit misuse of protected keys and mitigate fraud provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Smets does not disclose:
“connection network information” (claim 21).
However, as per Claim 21, Collinge in the analogous art of verifying payment transactions, teaches: “connection network information”. (See “An SSID (Wi-Fi Access point) when shopping in a store (in that case the implicit consent would be driven by business rules where the merchant would favour the speed of the transaction at the cashier desk.” (Para. 0051); “Evaluate the spot speed and altitude of the payment device 100 to assess whether it is compliant with the acceptance environment and location as reported in the transaction data and localization information.” (Para. 0062).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Smets with the technique of Collinge to further base satisfaction of the signing/authorization condition on connection network information so that signatures are generated only when the device is connected to an expected network context. Therefore, the incentives of improving trust decisions while keeping the same secure signing and return-to-application flow provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure: US20210226769A1 (Snow), discussing “For many payment transactions, the issuer of the payment card account or another entity mandates “two factor” security—that is, the user must not only present a physical credential (e.g., a payment card or payment-enabled mobile device), but also must provide additional information to verify that the user is the person who is authorized to present the credential. The presentation of additional information is sometimes referred to in the payment card industry as a “cardholder verification method”, or “CVM”. A widely used CVM calls for the user to enter a “PIN”, i.e., a “personal identification number”. Often when a payment card (and especially a debit card) is presented to a POS terminal, the user is prompted to enter his/her PIN to satisfy a CVM requirement. There have also been many proposals for CVM requirements involving receipt of biometric information from the user.” (Para. 0003); see also “a biometric unit that may be incorporated in some embodiments of the smartphone 102 in cases where the types of cardholder verification methods to be supported by the shared CVM applet 308 are to include biometric measures such as fingerprint reading, facial recognition, voice recognition, etc. It will be appreciated that in the case of at least some of these measures, the biometric unit 328 may be at least partially constituted by conventional features of the smartphone 102, such as the microphone 220 (FIG. 2) or a digital camera (not shown). It will be appreciated that the microphone 220 may serve as an input device to receive voice signals from the user as an input to a voice recognition CVM procedure; the camera, if present, may serve as an input device to generate image input signals for a “selfie” (photograph of the user's face) as an input to a facial recognition CVM procedure. Biometric information received by the smartphone 102 via the biometric unit 328 may be provided to the CVM capture software module 316, as indicated at 330.” (Para. 0037).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697