DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This is the final office action in response to the applicant’s remarks/arguments filed on November 20, 2025.
Claims 1 and 9 have been amended; claims 5 and 18 have been canceled.
Claims 1-4, and 6-17, and 19 are pending and have been examined.
Priority
The applicant's claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. The applicant has not complied with one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 119(e) as follows:
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AlA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994)
The disclosure of the prior-filed application, Application No. 62/126,297, fails to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AlA 35 U.S.C. 112, first paragraph for one or more claims of this application.
Claim 6 recites “wherein the server computer maintains the private ledger including a series of blocks of transactions that include a hash output as a reference to a prior transaction block in the series of blocks of transactions.” The prior-filed application fails to provide adequate support for this limitation. The prior-filed application discloses: “The owner can transfer the coin by digitally signing a hash of the previous transaction (involving the bitcoin) and the public key of the next owner and adding these to the end of the coin” (see paragraph [0006] of the specification), and “[i]n this simplified depiction, the ledger 120 includes a column of public keys and a column of account balances, though of course in various embodiments the ledger can include different types of data (e.g., a column of account PANs or account IDs instead of public keys, an issuer identifier, a set of policies or restrictions associated with the particular account, etc.)” (see paragraph [0036] of the specification). The prior-filed application does not disclose that the server computer maintains a private ledger including a series of blocks of transactions that contain a hash output as a reference to a prior transaction block in the series of blocks of transactions.
Therefore, the limitation of claim 6, “wherein the server computer maintains the private ledger including a series of blocks of transactions that include a hash output as a reference to a prior transaction block in the series of blocks of transactions,” could not receive the benefit of an earlier filing date of 02/27/2015 of Application No. 62/126,297. The priority date for the limitation should be the same as the parent application (Application No. 15/054,993) filing date of 02/26/2016.
Responses to Argument/Remarks
Claim Objections:
The amended claims have overcome the claim objections, and the claim objections have been withdrawn.
35 U.S.C. § 112:
The 112(d) rejection has been withdrawn because claim 18 has been canceled.
35 U.S.C. § 101:
The applicant contends that the amended claim as a whole integrates a judicial exception into a practical application by providing improvements on technology and a technical field based on the specification. The examiner respectfully disagrees.
First, claim 1 of the instant application recites processing a transaction. Specifically, the identified limitations fall within the “Certain Method of Organizing Human Activity” grouping of abstract ideas in Step 2A Prong 1.
Additionally, the paragraph [0013] of the specification merely describes: “Embodiments of the invention introduce a system that provides some benefits of traditional fiat currencies – such as well-known and easy to use payment procedures -- together with some benefits of digital currencies (e.g., increased data security), while reducing the downsides of these digital currencies.” The examiner would like to point out that utilizing a public key as an identifier and signing a transaction via a private key to increase data security is for mitigating risks, a process related to fundamental economic principles or practices, a concept as part of the abstract idea of “Certain Method of Organizing Human Activity.” Additionally, utilizing a public key as an identifier and signing a transaction via a private key have been implemented for some time, a practice that merely improves the identified abstract idea itself but does not improve the function of a computer, technology, or a technical field.
The paragraph [0014] discloses a private ledger that is privately managed. First, each financial institution/entity maintaining a private leger is commonly implemented. Additionally, it is a common knowledge that a blockchain ledger could be implemented as a public ledger or a private ledger based on the business requirements.
The paragraphs [0018], [0020], [0041], and [0080] generally disclose utilizing a public key instead of a real account number in transaction requests and authorization messages to protect the real account number, such as the PAN and/or the issuer account identifier. The examiner would like to point out that replacing a real account number with a derived number is a widely used method for protecting the real account information and for mitigating the risk of leaking the real account number during the processing of a transaction. One example is replacing the real account number with a tokenized account number during the processing of a transaction. Mitigating risks is related to fundamental economic principles or practices, a concept as part of the abstract idea of “Certain Method of Organizing Human Activity.” Additionally, utilizing a public key as an account identifier to determine the balance associated with a sender is one of the commonly known features of the blockchain network. The examiner would like to point out that these functions are regular business procedures for maintaining account data associated with payment instruments and that they do not improve the function of a computer, technology, or a technical field.
The paragraph [0064] discloses utilizing a network interface of the access device to allow the access device to communicate with other entities. The network interface is a regular component included in a device to enable the communication, and it cannot integrate the judicial exception into a practical application.
Furthermore, the additional elements, such as an access device/a point of sale device at a location of a merchant, a device communication interface, a processing module, a network interface, a user device, a payment device, a processor, a computer readable medium, a server computer comprising a centralized transaction verification and accounting module (TVAM), and a private ledger, perform the steps of providing transaction data, receiving signed transaction data and a public key, generating an authorization request message, transmitting the authorization request message, and managing key pairs of accounts. The additional elements in these steps are used as tools to perform the identified abstract idea. To use these computer components as tools to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than computer(s) performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field; the claim does not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition; the claim does not apply the abstract idea with, or by use of, a particular machine; the claim does not effect a transformation or reduction of a particular article to a different state or thing; and the claim does not apply or use the abstract idea in some other meaningful ways beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Therefore, the claim does not, for example, purport to improve the functioning of a computer. Nor does it effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claim 1 is directed to an abstract idea.
35 U.S.C. § 103:
The applicant has stated that the pooled MBC account database of Kurnai stores the new private/public key pairs which are created as a result of the performance of the transaction in col. 5, lines30-40 of Kurnai. The examiner would like to point out that Kurnai does disclose a centralized transaction verification and accounting module (i.e., a financial institution computing system) configured to manage private keys of accounts in a private ledger. (See Fig. 1; col. 5, line 23 – col. 6, line 6, “[t]he pooled MBC account 126 is a database of addresses, private keys, and public keys associated with MBC that has been transferred to the financial institution 102. The financial institution 102 maintains the contents of the pooled MBC account 126 in secrecy such that entities and people outside of the financial institution 102 do not have knowledge of the addresses, private keys, and public keys associated with the MBC transferred to the financial institution 102. Through the pooled MBC account 126, the financial institution 102 maintains the MBC from customers 104 received during deposit transactions and initiates transfers of MBC to customers 104 during withdrawal transactions. In some arrangements, the financial institution 102 may maintain a plurality of pooled MBC accounts (i.e., a plurality of separate databases) containing MBC of a plurality of customers”; col. 11, lines 25-38; and claim 1, “storing, by an MBC transaction processor of a plurality of processors, a plurality of public and private key pairs in a pooled MBC account database … in response to receiving the recipient account and the amount of funds to transfer from the account balance processor, identifying, by the MBC transaction processor, one or more public and private key pairs of the plurality of public and private key pairs in the pooled MBC account database with a total value of the one or more public and private key pairs more than the amount of funds to transfer.”)
The applicant further contends that there is no teaching or suggestion that a generated message that includes a signed transaction data and a public key of the user is transmitted by an access device to a server computer that comprises a centralized transaction verification and accounting module (TVAM) configured to manage private and public key pairs of accounts in a private ledger. The examiner respectfully disagrees.
Wheeler discloses transmitting the generated authorization request message including the signed transaction data and (the unique identifier associated with the user) to a sever computer that comprises a centralized transaction verification and accounting module (TVAM) configured to manage public keys of accounts in a private ledger. (See paragraphs [0111]-[0115]; Fig. 3; paragraphs [0120-[0123]; paragraphs [0159]-[0161]; Figs. 60-63; paragraphs [320]-[321]; paragraphs [0324]-[0326]; and paragraphs [0366]-[0367].)
Wheeler further discloses wherein the unique identifier associated with the user is a public key of the user. (See paragraph [0129], “[i]n some embodiments of the present invention, the unique identifier may actually be the public key from the device or a hashed version of the public key”; paragraph [0132], “[p]referably, the public key is associated particularly with the unique identifier of the account. In some embodiments, the public key itself (or a hashed value of the public key) is used as the unique identifier assigned to the account.” Therefore, Wheeler discloses that the unique identifier, which is the public key of the user, is included in the signed message from the user and in the authentication request message.)
Kurani, an analogous art of processing transactions, discloses a centralized transaction verification and accounting module (i.e., a financial institution computing system) configured to manage private keys of accounts in a private ledger. (See Fig. 1; col. 5, line 23 – col. 6, line 6; col. 11, lines 25-38; and claim 1.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Kurnai in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system as modified, one of ordinary skill in the art would have been motivated to manage the private keys of accounts in secrecy, so that the private keys can be protected from being accessed by unauthorized entities.
The applicant’s amendments have overcome the 35 U.S.C. § 103 rejection. However, there are new grounds of rejection necessitated by the applicant’s amendments as detailed in the 35 U.S.C. § 103 rejection section. Hence, the applicant’s arguments with respect to the claim rejection have been considered but are moot in view of the new grounds of rejection. A new reference is introduced.
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-4, 6-17, and 19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract ideas without significantly more.
In this instance, claims 1-4, 6-8, 17, and 19 are directed to a method; claims 9-16 are directed to an access device. Therefore, these claims fall within the four statutory categories of invention.
Claim 1 as a whole is directed toward the abstract idea of processing a transaction. In particular, the claim recites providing transaction data, receiving signed transaction data and a public key, generating an authorization request message, and transmitting the generated authorization request. In other words, the claim falls under the “Certain Method of Organizing Human activity” grouping of abstract ideas in Step 2A Prong One (MPEP 2106.04(a)(d)) because the claim involves the steps of processing a transaction, a process related to fundamental economic practices and/or commercial interactions. 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).
Claim 1 recites “[a] method comprising: providing, on a device communication interface of an access device that is a point of sale device at a location of a merchant, transaction data to a user device that is a payment device associated with a user, wherein the user device signs the transaction data, wherein the access device comprises a network interface configured for communication with a centralized transaction verification and accounting module (TVAM); receiving, by the access device, signed transaction data signed by the user device and a public key of the user from the user device, wherein the access device is configured to use the public key associated with the user; generating, by a processing module of the access device, an authorization request message including the signed transaction data signed by the user device and the public key of the user, wherein the authorization request message that is constructed includes data identifying the authorization request message as corresponding to a signed transaction; and transmitting, by the access device, the generated authorization request message including the signed transaction data and the public key of the user to a server computer that comprises the centralized transaction verification and accounting module (TVAM) configured to manage private and public key pairs of accounts in a private ledger, wherein the public key associated with the user in the private ledger is configured to be updatable; wherein an issuer account identifier associated with the payment device is configured to be accessed from the ledger managed by the TVAM based on the signed transaction data signed by the user device.”
This judicial exception is not integrated into a practical application because, when analyzed under Step 2A Prong Two (MPEP 2106.04(d)), the use of the non-underlined additional elements of claim 1 — a device communication interface, a processing module, an access device/a point of sale device at a location of a merchant, a network interface for communicating with a centralized transaction verification and accounting module (TVAM), a user device, a payment device, a server computer comprising the centralized transaction verification and accounting module (TVAM), and a private ledger — performs the steps of providing transaction data, receiving the signed transaction data and a public key, generating an authorization request message, transmitting the authorization request message, and managing key pairs of accounts. The identified additional elements in these steps are used as tools to perform the identified abstract idea. To use these computer components as tools to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than computer components performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field; the claim does not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or medical condition; the claim does not apply the abstract idea with, or by use of, a particular machine; the claim does not effect a transformation or reduction of a particular article to a different state or thing; and the claim does not apply or use the abstract idea in some other meaningful ways beyond generally linking the use of the abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception. Therefore, the claim does not, for example, purport to improve the functioning of a computer. Nor does it effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea. Claim 1 as a whole, judging from the additional elements individually and in combination, does not integrate the judicial exception into a practical application. The non-underlined additional elements above merely serve as tools to perform the abstract idea. Therefore, the claim as a whole fails to recite a practical application of the abstract idea.
Claim 1 does not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under Step 2B (MPEP 2106.05), the additional elements, of a device communication interface, a processing module, an access device/a point of sale device at a location of a merchant, a network interface for communicating with a centralized transaction verification and accounting module (TVAM), a user device, a payment device, a server computer comprising the centralized transaction verification and accounting module (TVAM), and a private ledger to perform the steps of “providing … transaction data; receiving … signed transaction data … and public key; generating … an authentication request message; and transmitting … the generated authorization request message … to manage private and public key pairs of accounts,” amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. The use of these additional elements does nothing more than employing the computer as a tool to automate and/or implement the abstract idea. The use of a computer or processor to merely automate and/or implement the abstract idea cannot provide significantly more than the abstract idea itself. As discussed above, the additional elements, when considered individually and in combination, fail to recite significantly more than the abstract idea.
Accordingly, claim 1 is rejected as being directed toward patent-ineligible subject matter.
Claim 9 recites the abstract idea similar to that discussed above in connection with claim 1. The cited new additional elements of a processor and a computer readable medium do not recite a practical application or significantly more than the abstract idea.
Claims 2-4, 6-8, 10-17, and 19 have also been considered for subject-matter eligibility. However, these claims fail to recite patent-eligible subject matter for the following reasons:
Claim 2 recites the characteristics of the provided transaction data, which is an additional element. The additional element fails to recite patent-eligible subject matter as it simply recites information included in the abstract idea. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claims 3 and 11 disclose the additional element of wherein the signed transaction data comprises transaction encrypted using a private key of the user that is associated with the public key of the user. Encryption is a commonly used method for protecting data. Encrypting the transaction using a private key generally links the use of the judicial exception to a particular technological environment or field of use. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components and/or generally links the use of the judicial exception to a particular technological environment or field of use.
Claim 4 recites the characteristics of the private key, which is an additional element. The additional element fails to recite patent-eligible subject matter as it simply recites the type of a private key. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 6 recites the abstract idea of maintaining a series of blocks of transactions, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional elements of a private ledger and a server computer do not recite a practical application or significantly more than the abstract idea because the additional elements do not pertain to an improvement to the functioning of a computer or to another technology, and the additional elements merely further recite additional instructions to implement the abstract idea on the computer components.
Claim 7 recites the abstract idea of receiving an authorization response message, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional element of the access device does not recite a practical application or significantly more than the abstract idea because the additional element does not pertain to an improvement to the functioning of a computer or to another technology, and the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 8 recites an additional element of wherein the authorization response message for the transaction includes the public key of the user. The additional element fails to recite patent-eligible subject matter as it simply recites information included in the abstract idea. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 10 recites an additional element of wherein the access device comprises a device reader. The additional element simply describes a component included in the previously identified additional element of the access device. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 12 recites the abstract idea of signing the transaction data, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional element of a payment device of the user does not recite a practical application or significantly more than the abstract idea because the additional element does not pertain to an improvement to the functioning of a computer or to another technology, and the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claims 13 recites the abstract idea of providing the transaction data as plaintext transaction data, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional element of a device of a merchant does not recite a practical application or significantly more than the abstract idea because the additional element does not pertain to an improvement to the functioning of a computer or to another technology, and the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 14 recites the abstract idea of receiving a transaction authorization when the signed transaction data was signed and that a current balance is sufficient, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. The additional element of the access device does not recite a practical application or significantly more than the abstract idea because the additional element does not pertain to an improvement to the functioning of a computer or to another technology, and the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 15 discloses an additional element of wherein the device communication interface is configured to communicate with the user device via a long-range communication protocol, a short-range communication protocol, or a mid-range communication protocol. The additional element describes how the previously identified additional element of the device communication interface communicates with the user device. This additional element is used in its ordinary capacity. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 16 discloses an additional element of wherein the device communication interface comprises a QR code interface, a contactless interface, a contact interface or a Bluetooth interface. The additional element describes what type of interfaces the previously identified additional element of the device communication interface may comprise. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
Claim 17 discloses the abstract idea of identifying the authorization request message as corresponding to the signed transaction by a fake PAN, which falls under the “Certain Method of Organizing Human Activity” grouping of abstract ideas. No new additional elements are cited.
Claim 19 discloses an additional element of wherein the generated authorization request message does not include the issuer account identifier. The additional element fails to recite patent-eligible subject matter as it simply recites information included in the abstract idea. The additional element is insufficient to integrate the abstract idea into a practical application because the additional element does not pertain to an improvement to the functioning of a computer or to another technology. The additional element does not offer significantly more than the abstract idea, because the additional element merely further recites additional instructions to implement the abstract idea on the computer components.
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, 3-4, 9-14, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Wheeler et al. (US 20030115151 A1) in view of Carlson (US 20080319905 A1), and further in view of Kurani (US 11176524 B1) and Azen et al. (US 20130185214 A1).
Claims 1 and 9:
Wheeler discloses the following:
an access device comprising a processor and a computer readable medium, the computer readable medium comprising code, executable by the processor to implement a method comprising: providing, on a device communication interface of an access device that is a point of sale device at a location of a merchant, transaction data to a user device that is a payment device associated with a user, wherein the user device signs the transaction data, wherein the access device […] configured for communication with a centralized transaction verification and account module (TVAM). (See Fig. 60; paragraph [0319], “[i]n this example, an account holder comprising a purchaser 6002 possesses a device in the form of a card 6050, such as an IC card, which is capable of being used at a point of sale location. A point of sale card reader 6052 includes an alphanumeric keypad 6056, a display 6054, and, in this case, a thumbprint reader 6058. The point of sale card reader 6052 is in communication via data connector 6064 with a merchant cash register/terminal 6060, which has its own display 6062. The point of sale card reader 6052 is also in communication with a standard financial network 6008, which is in communication with and has the capability of correctly routing communications between merchants and various financial institutions represented, in this example, s by financial institutions 6012,6022,6032”; paragraphs [0322]-[0326], “[w]ith particular regard to FIG. 62, the purchaser 6002 initiates (Step 6202) a transaction with a merchant when the purchaser 6002 requests to pay for an item at the merchant cash register/terminal 6060. The merchant ‘rings up’ (Step 6204) the item on the merchant cash register/terminal 6060 and the total balance due is displayed to the purchaser 6002 on the display 6062. To pay, the purchaser 6002 inserts (Step 6206) the card 6050 into the point of sale card reader 6052 (or brings the card 6050 into proximity to the card reader 6052 if both the card reader 6052 and the card 6050 are equipped for contactless proximity communications in accordance with ISO/IEC Standard 14443, which is incorporated herein by reference)…. Next, the merchant cash register/terminal 6060 transmits (Step 6210) the balance due to the point of sale card reader 6052 via data connector 6064. The point of sale card reader 6052 displays (Step 6212) the balance due on display 6054…. In this regard, upon receipt of data representing the message, the card 6050 originates (Step 6226) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 6050. The card 6050 then outputs (Step 6228) the digital signature, which is received by the point of sale card reader 6052. The point of sale card reader 6052 then transmits (Step 6230) the message and the digital signature therefor in an EC to the financial institution 6012 (via financial network 6008) and waits (Step 6232) for a response from the financial institution 6012. In this case, the EC is used for transaction authentication purposes…. Using this public key, the financial institution 6012 attempts to authenticate (Step 6306) the message. If the message does not authenticate (in Step 6308), then the financial institution 6012 responds (Step 6310) to the merchant (via financial network 6008 and point of sale card reader 6052) with a rejection of the message”; and paragraph [0142], “[t]he device preferably includes a device interface comprising a port--including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port--or some other physical interface for communicating with an external electronic apparatus, whether contact or contactless.” One of ordinary skill in the art knows that a device/terminal must have a processing unit/processor and memory storing software, so that the device/terminal can perform the required functionalities via the execution of the stored software by the processing unit/processor.)
receiving, by the access device, signed transaction data signed by the user device and (a unique identifier associated with the user) from the user device, wherein the access device is configured to use (the unique identifier associated with the user). (See paragraphs [0111]-[0115], “[a]s shown, the account holder 202 comprises a person who possesses a device 250, which securely protects a unique private key of a public-private key pair therein…. Each communication is electronic, and each electronic communication (‘EC’) 206 from the account holder 202 to the account authority 212 includes an electronic message (M) that is digitally signed by the account holder 202 using the private key retained within the device 250…. The message preferably includes the unique identifier (acctID) 216 of the account of the account holder 202 and an instruction (i1) for the account authority 212 to perform in relation to the account”; Figs. 60-62; and paragraphs [0322]-[0324], “[t]o pay, the purchaser 6002 inserts (Step 6206) the card 6050 into the point of sale card reader 6052 (or brings the card 6050 into proximity to the card reader 6052 if both the card reader 6052 and the card 6050 are equipped for contactless proximity communications in accordance with ISO/IEC Standard 14443, which is incorporated herein by reference)…. Next, the merchant cash register/terminal 6060 transmits (Step 6210) the balance due to the point of sale card reader 6052 via data connector 6064. The point of sale card reader 6052 displays (Step 6212) the balance due on display 6054…. The display 6054 prompts (Step 6220) the purchaser 6002 to provide Factor B and C entity authentication information, such as a PIN and right thumbprint, using the alphanumeric keypad 6056 and thumbprint scanner 6058--but only if he approves of the proposed transaction (including amount of the purchase and the use of the selected account(s) for payment)…. In this regard, upon receipt of data representing the message, the card 6050 originates (Step 6226) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 6050. The card 6050 then outputs (Step 6228) the digital signature, which is received by the point of sale card reader 6052. The point of sale card reader 6052 then transmits (Step 6230) the message and the digital signature therefor in an EC to the financial institution 6012 (via financial network 6008) and waits (Step 6232) for a response from the financial institution 6012. In this case, the EC is used for transaction authentication purposes.”)
generating, a processing module of the access device, an authorization request message (i.e., an EC) including the signed transaction data signed by the user device and (the unique identifier associated with the user), wherein the authorization request message that is constructed includes data identifying the authorization request message as corresponding to a signed transaction. (See paragraphs [0111]-[0115], “[a]s shown, the account holder 202 comprises a person who possesses a device 250, which securely protects a unique private key of a public-private key pair therein…. Each communication is electronic, and each electronic communication (‘EC’) 206 from the account holder 202 to the account authority 212 includes an electronic message (M) that is digitally signed by the account holder 202 using the private key retained within the device 250”; paragraph [0142]; Figs. 60-63; and paragraphs [0322]-[0334], “[t]he display 6054 prompts (Step 6220) the purchaser 6002 to provide Factor B and C entity authentication information, such as a PIN and right thumbprint, using the alphanumeric keypad 6056 and thumbprint scanner 6058--but only if he approves of the proposed transaction (including amount of the purchase and the use of the selected account(s) for payment)…. In this regard, upon receipt of data representing the message, the card 6050 originates (Step 6226) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 6050. The card 6050 then outputs (Step 6228) the digital signature, which is received by the point of sale card reader 6052. The point of sale card reader 6052 then transmits (Step 6230) the message and the digital signature therefor in an EC to the financial institution 6012 (via financial network 6008) and waits (Step 6232) for a response from the financial institution 6012. In this case, the EC is used for transaction authentication purposes.” By the broadest reasonable interpretation, the unique identifier included in the message (M) could act as data identifying the authorization request message as corresponding to a transaction. Any applications/instructions/procedures used to perform the disclosed functionalities can act as a processing module.)
transmitting, by the access device, the generated authorization request message including the signed transaction data and (the unique identifier associated with the user) to a sever computer that comprises a centralized transaction verification and accounting module (TVAM) configured to manage public keys […] of accounts in a private ledger managed by the TVAM, wherein the public key associated with the user in the private ledger is configured to be updatable. (See paragraphs [0111]-[0115], “[t]he message preferably includes the unique identifier (acctID) 216 of the account of the account holder 202 and an instruction (i1) for the account authority 212 to perform in relation to the account”; Fig. 3; paragraphs [0120-[0123], “[t]he three-party ABDS system 300 differs from the two-party ABDS system 200 (from FIG. 2) in that the message and digital signature from the account holder 302 to the account authority 312 is communicated first to the intermediate party 310 by means of an EC 305. The intermediate party 310 then forwards the same message and digital signature in another EC 315 to the account authority 312”; paragraphs [0159]-[0161], “[a]s stated previously, in some circumstances, the particular resource 7440,7450,7460 is not only protected but also maintained by the account authority 7412 (for example, if the account authority 7412 is a financial institution and the resource is a bank account of the account holder 7402)”; Figs. 60-63; paragraphs [320]-[321], “[w]ith reference to FIG. 61, each account in database 6014 includes a unique account identifier comprising an account number 6116. Each account number 6116 identifies, within the account database 6014, account information 6140, including customer-specific information 6142 and account-specific information 6144…. The account-specific information 6144 includes, for example, the current account balance, available credit, closing date and balance of current statement, and associated account identifiers. The public key information 6118 of the account of the purchaser 6002 includes the public key corresponding to the private key retained within the card 6050”; paragraphs [0324]-[0326], “[t]he point of sale card reader 6052 then transmits (Step 6230) the message and the digital signature therefor in an EC to the financial institution 6012 (via financial network 6008) and waits (Step 6232) for a response from the financial institution 6012. In this case, the EC is used for transaction authentication purposes…. Using this public key, the financial institution 6012 attempts to authenticate (Step 6306) the message…. For example, even though the message authenticated, the purchaser 6050 may not have enough money or credit associated with the account for the financial institution 6012 to approve the transaction. Thus, making such a determination typically involves accessing the relevant portion(s) of the account record and confirming that the funds are available…. If the determination in Step 6314 is positive, then the financial institution 6012 performs (Step 6316) the instruction (i1). In this example, the instruction (i1) from the purchaser 6002 is to pay the merchant the specified amount of funds from the specified account for the purchase of the product”; and paragraphs [0366]-[0367], “[e]ach account authority 7122,7132 then deactivates the associated account [acctID(b); acctID(c1); acctID(c2)] (or at least deactivates the use of the account by means of the particular device 7151 and public key 7128) until the account holder 7102 associates a new public key (PuK2-new) therewith…. The Central Key Authority 7190 then preferably communicates the new public key (PuK2-new) 7138 to each of the appropriate account authorities 7122,7132 for association therewith and reactivation of the respective accounts [acctID(b); acctID(c1); acctID(c2)].” The software/applications/instructions of the financial institution, which perform the same functionalities as claimed, could be interpreted as a centralized transaction verification and accounting module (TVAM) included in a computing device.)
Wheeler further discloses wherein the unique identifier associated with the user is a public key of the user. (See paragraph [0129], “[i]n some embodiments of the present invention, the unique identifier may actually be the public key from the device or a hashed version of the public key”; paragraph [0132], “[p]referably, the public key is associated particularly with the unique identifier of the account. In some embodiments, the public key itself (or a hashed value of the public key) is used as the unique identifier assigned to the account.” Therefore, Wheeler discloses that the unique identifier, which is the public key of the user, is included in the signed message from the user and in the authentication request message.)
Wheeler discloses that an access device communicates with financial institution(s). One of ordinary skill in the art knows that a device must include a network interface in order to communicate via a network. The examiner introduces another reference, Azen, that discloses wherein the access device comprises a network interface configured for communication with a server comprising modules. (See Figs. 1-3; paragraph [0033], “[i]t is envisioned that a merchant POS terminal or register 125 may be any component, application or system operable to receive data in payment for goods or services such as, but not limited to a cash register, a desktop computer, a laptop computer, a personal digital assistant, a tablet computer, a scanner, a cellular ‘smart’ phone, or the like”; paragraph [0040], “[o]nce the digital signatures and associated purchase request data are received at SonicPay Service server 105, the digital signature of the consumer may be verified and the consumer's stored profile may be queried for associated stored value accounts in the account database 120”; paragraphs [0046]-[0047], “[t]he PCD 110 and POS 125 may also comprise a SonicPay module 118 and a SonicPOS module 117, respectively, for transmitting and receiving payment requests, respectively, from the wireless communication hardware 112A, 112B and/or the cellular radio transceivers 116A, 116B…. Further, the SonicPOS module 117 may be configured to interface with cellular radio transceiver 116B, via a radio API 115B for receiving and transmitting purchase transaction authorization or confirmation data as well as other information to exemplary server 105, as depicted in the system 100 embodiment”; and paragraphs [0050]-[0051].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Azen in the Wheeler system. Moreover, in order to improve the transaction process of the Wheeler system, one of ordinary skill in the art would have been motivated to include a network interface in a POS access device, so that the transaction information can be effectively transmitted to another entity for authorization.
Wheeler in view of Azen does not explicitly disclose a centralized transaction verification and accounting module configured to manage private keys of accounts in a private ledger and wherein an issuer account identifier associated with the payment device is configured to be accessed from the ledger managed by a TVAM based on the signed transaction data signed by the user device.
Carlson, an analogous art of processing transactions, discloses wherein an issuer account identifier associated with the payment device is configured to be accessed from the ledger managed by a software module/application based on the signed transaction data signed by the user device. (See paragraphs [0029]-[0030], “[a] portable wireless device according to an embodiment of the invention may be a mobile cellular phone, a PDA, and the like, capable of wireless transmission of a pseudo primary account identifier, in lieu of a user's real account identifier such as a primary account identifier (PAI) or a user's real primary account number (PAN)…. In some embodiments, the pseudo primary account identifier may be of any length or type as long as it resembles the format of a real primary account identifier, such as a credit card number, debit card number, gift card number, and the like”; paragraphs [0046]-[0048], “[t]he acquirer can then forward the authorization request message to the payment processing network using the transaction processing network. The payment processing network, having previously generated or received the pseudo primary account identifier and stored the relationship to a primary account identifier, may then convert the pseudo primary account identifier in the authorization request message back to the real primary account identifier. Conversion of the pseudo primary account identifier to the real primary account identifier can be done through any suitable means, such as a mathematical operation, a database table look up, generating the primary account identifier based on the pseudo primary account identifier, or any other means that are well known”; and paragraph [0074], “[i]f a pseudo primary account identifier is successfully retrieved 406, the process moves to step 408 where the pseudo primary account number is transmitted to the acquirer. The acquirer then transmits the pseudo primary account identifier to the payment processing network 410. The payment processing network will then convert the pseudo primary account identifier back to the primary account identifier and further transmit the request to the issuer 412.” A real PAN or a credit card number includes an issuer account identifier. A pseudo primary account identifier is a fake PAN, and it is a substitute for a real PAN. The real PAN with an issuer account identifier is determined based on the pseudo primary account identifier.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Carlson in the Wheeler system. Moreover, in order to improve the transaction process of the Wheeler system, one of ordinary skill in the art would have been motivated to determine a real PAN/issuer account identifier based on the transaction, so that the transaction can be further validated based on the real PAN/issuer account identifier.
The combination of Wheeler, Azen, and Carlson discloses the claimed invention but does not explicitly disclose a centralized transaction verification and accounting module configured to manage private keys of accounts in a private ledger.
Kurani, an analogous art of processing transactions, discloses a centralized transaction verification and accounting module (i.e., a financial institution computing system) configured to manage private keys of accounts in a private ledger. (See Fig. 1; col. 5, line 23 – col. 6, line 6, “[t]he financial institution 102 includes a pooled MBC account 126 (i.e., a database of private key/public key pairs)…. The pooled MBC account 126 is a database of addresses, private keys, and public keys associated with MBC that has been transferred to the financial institution 102. The financial institution 102 maintains the contents of the pooled MBC account 126 in secrecy such that entities and people outside of the financial institution 102 do not have knowledge of the addresses, private keys, and public keys associated with the MBC transferred to the financial institution 102”; col. 11, lines 25-38, “[t]he deposit customer 202 uses a MBC client (e.g., a MBC wallet application running on customer computing system 108) to initiate the transfer of MBC to the financial institution 102. After the transaction, the financial institution 102 stores the private key and public key pair in the pooled account 126”; and claim 1, “storing, by an MBC transaction processor of a plurality of processors, a plurality of public and private key pairs in a pooled MBC account database … in response to receiving the recipient account and the amount of funds to transfer from the account balance processor, identifying, by the MBC transaction processor, one or more public and private key pairs of the plurality of public and private key pairs in the pooled MBC account database with a total value of the one or more public and private key pairs more than the amount of funds to transfer.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Kuran in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system as modified, one of ordinary skill in the art would have been motivated to manage the private keys of accounts in secrecy, so that the private keys can be protected from being accessed by unauthorized entities.
Examiner’s Note: The limitation of “wherein an issuer account identifier associated with the payment device is configured to be accessed from the private ledger managed by the TCAM based on the signed transaction data signed by the user device” is not a positively recited step. Additionally, based on the specification (see paragraph [0026] of the specification), the issuer account identifier is determined by the server computer, not by the access device. Additionally, claim 9 recites “wherein the user device signs the transaction data.” The recited user device is out of scope of the claimed access device. Furthermore, claim 9 recites “a server computer that comprises a centralized transaction verification and accounting module (TAVM) configured to manage private and public key pairs of accounts in a private ledger.” The recited server computer and a centralized transaction verification and accounting module (TAVM) are out of scope of the claimed access device.
Claims 3 and 11:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses wherein the signed transaction data comprises transaction data encrypted using a private key of the user that is associated with the public key of the user. (See paragraph [0004], “[t]he origination of a digital signature generally comprises: (1) the calculation of a message digest--such as a hash value; and (2) the subsequent encryption of the message digest. The message digest is encrypted by an electronic device generally using a private key of a public-private key pair used in asymmetric cryptography”; paragraph [0013], “generating a digital signature for an electronic message using a private key of the public-private key pair, the electronic message including an instruction and the unique identifier”; paragraphs [0111]-[0115], “[a]s shown, the account holder 202 comprises a person who possesses a device 250, which securely protects a unique private key of a public-private key pair therein…. Each communication is electronic, and each electronic communication (‘EC’) 206 from the account holder 202 to the account authority 212 includes an electronic message (M) that is digitally signed by the account holder 202 using the private key retained within the device 250”; Fig. 3; paragraphs [0120]-[0123], “[t]he three-party ABDS system 300 differs from the two-party ABDS system 200 (from FIG. 2) in that the message and digital signature from the account holder 302 to the account authority 312 is communicated first to the intermediate party 310 by means of an EC 305. The intermediate party 310 then forwards the same message and digital signature in another EC 315 to the account authority 312”; and paragraph [0324], “[i]n this regard, upon receipt of data representing the message, the card 6050 originates (Step 6226) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 6050.” One of ordinary skill in the art knows that the signing includes hashing and encrypting.)
Claim 4:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses wherein the private key is an elliptic curve cryptography (ECC) key. (See paragraph [0147], “[f]urthermore, the device preferably originates digital signatures in accordance with an elliptical curve digital signature algorithm (ECDSA) as specified in Federal Information Processing Standards Publication 186-2, Digital Signature Standard, US DOC/NBS, Jan. 11, 1994 (hereinafter ‘FIPS PUB 186-2’), which is incorporated herein by reference.” One of ordinary skill in the art knows that the Elliptic Curve Digital Signature Algorithm (ECDSA) is a digital signature algorithm that uses keys derived from elliptic curve cryptography (ECC).)
Claim 10:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses wherein the access device comprises a device reader. (See Fig. 60 and paragraph [0319].)
Claim 12:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses wherein the signed transaction data is signed by the payment device associated with the user. (See paragraph [0107], “[i]n some embodiments, the ‘account holder’ is, itself, a device that is capable of generating a digital signature using a private key retained therein; the private key corresponding with a public key associated with an account upon which the device is authorized to act”; paragraph [0324], “[i]n this regard, upon receipt of data representing the message, the card 6050 originates (Step 6226) a digital signature for the message by first calculating a hash value for the data and then encrypting the hash value using the private key retained within the card 6050.”)
Claim 13:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler discloses wherein the transaction data is provided as plaintext transaction data by a device of a merchant. (See paragraphs [0322]-[0324].)
Claim 14:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses wherein the access device received a transaction authorization when it is determined that the signed transaction data was signed using the private key of the user and that a current balance is sufficient for authorizing the transaction. (See paragraph [0122], “[u]pon receipt of the EC 315, the account authority 312 attempts to authenticate the message and the sender of EC 305 using the public key of the public-private key pair, which is retrieved from the account database 314 based on the unique identifier [acctID] 316 from the message. If the authentication is successful, the account authority 312 performs [or attempts to perform] the instruction [i1] of the message as if the account holder 302 were presenting the instruction [i1] in person”; Fig. 63; and paragraphs [0324]-[0326], “[t]he point of sale card reader 6052 then transmits (Step 6230) the message and the digital signature therefor in an EC to the financial institution 6012 (via financial network 6008) and waits (Step 6232) for a response from the financial institution 6012. In this case, the EC is used for transaction authentication purposes.… Using this public key, the financial institution 6012 attempts to authenticate (Step 6306) the message…. For example, even though the message authenticated, the purchaser 6050 may not have enough money or credit associated with the account for the financial institution 6012 to approve the transaction. Thus, making such a determination typically involves accessing the relevant portion(s) of the account record and confirming that the funds are available…. If the determination in Step 6314 is positive, then the financial institution 6012 performs (Step 6316) the instruction (i1). In this example, the instruction (i1) from the purchaser 6002 is to pay the merchant the specified amount of funds from the specified account for the purchase of the product…. The financial institution 6012 also notifies (Step 6318) the merchant (via financial network 6008 and point of sale card reader 6052) of the approval of the transaction.”)
Examiner’s Note: Claim 14 recites “wherein the access device receives a transaction authorization when it is determined that the signed transaction data was signed using the private key of the user and that a current balance is sufficient for authorizing the transaction.” The step of receiving a transaction authorization happens only when the transaction data is validated. This is a contingent limitation. See Ex parte Schulhauser, Appeal 2013-007847 (PTAB April 28, 2016), MPEP § 2111.04.
Claim 17:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler discloses the authorization request message corresponding to the signed transaction. (See paragraphs [0111]-[0115]; Figs. 60-63; and paragraphs [0322]-[0324].)
Carlson further discloses wherein the data identifying the authorization request message as corresponding to the signed transaction is a fake PAN that can be used to conduct a payment transaction. (See paragraphs [0029]-[0030]; paragraph [0074], “[i]f a pseudo primary account identifier is successfully retrieved 406, the process moves to step 408 where the pseudo primary account number is transmitted to the acquirer. The acquirer then transmits the pseudo primary account identifier to the payment processing network 410. The payment processing network will then convert the pseudo primary account identifier back to the primary account identifier and further transmit the request to the issuer 412.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Carlson in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system, one of ordinary skill in the art would have been motivated to utilize a fake PAN in the authorization request for the transaction, so that the sensitive information can be protected from being compromised.
Claim 19:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Carlson further discloses wherein the generated authorization request message does not include the issuer account identifier. (See paragraphs [0029]-[0030]; paragraph [0074], “[i]f a pseudo primary account identifier is successfully retrieved 406, the process moves to step 408 where the pseudo primary account number is transmitted to the acquirer. The acquirer then transmits the pseudo primary account identifier to the payment processing network 410. The payment processing network will then convert the pseudo primary account identifier back to the primary account identifier and further transmit the request to the issuer 412.” A pseudo primary account identifier is not a real PAN, and it is a substitute for a real PAN. The real PAN with an issuer account identifier is determined based on the pseudo primary account identifier. The generated authorization request message of the merchant includes a pseudo primary account identifier instead of the real PAN.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Carlson in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system as modified, one of ordinary skill in the art would have been motivated to include a pseudo primary account identifier, not a real PAN/issuer account identifier in the authorization request message, so that the real PAN/issuer account identifier can be protected.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Wheeler et al. (US 20030115151 A1) in view of Carlson (US 20080319905 A1), and further in view of Kurani (US 11176524 B1), Azen et al. (US 20130185214 A1), and Wang et al. (US 7635084 B2).
Claim 2:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler discloses providing transaction data to the user device. (See paragraphs [0322]-[0324].)
None of Wheeler, Carlson, Kuran, and Azen explicitly discloses wherein the provided transaction data includes the public key of the user.
However, Wang, an analogous of processing a transaction, discloses wherein the provided transaction data includes the public key of the user. (See Fig. 2; col. 4, line 25 – col. 5, line 3, “requesting device 202 may initiate a transaction approval process with PEAD 200 by transmitting to PEAD 200, via communication port 204, a transaction request pertaining to a proposed transaction…. The proposed transaction may be, for example, a sale transaction of a particular item for a certain amount of money. The transaction request itself may include, for example, the transaction ID, the merchant's name, the merchant's ID, the time of the proposed purchase, and the like…. The data pertaining to proposed transaction(s) may then be reviewed by the user, either on a screen 208 of requesting device 202 or optionally on a display screen provided with PEAD 200 (not shown in FIG. 2). If the user approves the transaction, e.g., a purchase of an item for a given amount of money, the user may then signify his approval by activating a switch 210 on PEAD 200, which causes an approval message to be created with the user's identification data, encrypted and transmitted back to requesting device 202 via path 212”; and claim 1, “[i]n a portable electronic authorization device (PEAD) with inaccessible storage of a user's private key … receiving at said portable electronic authorization device first digital data, said first digital data representing said transaction request and including the user's public key; performing approval and encryption of the transaction approval solely within the PEAD utilizing a private key stored within the PEAD accessed using the user's public key without transmission of the private key to the remote electronic transaction system or entry of the private key by the user to the PEAD.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Wang in the Wheeler system as modified. Moreover, in order to improve the practicality of the Wheeler system as modified, one of ordinary skill in the art would have been motivated to provide the user device with the public key of the user in the transaction data, so that the user device can encrypt/sign the transaction by a private key based on the received public key.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Wheeler et al. (US 20030115151 A1) in view of Carlson (US 20080319905 A1), and further in view of Kurani (US 11176524 B1), Azen et al. (US 20130185214 A1), and Garzik (“Public versus Private Blockchains,” October 2015).
Claim 6:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler discloses wherein the server computer maintains a private ledger including a list of transactions. (See paragraph [0111], “[p]referably, the account is identifiable within the account database 214 based on a unique identifier [acetID] 216, such as an account number. Further, the account authority 212 maintains an association between the account and the public key 218, which corresponds with the private key that is securely retained within the device 250 of the account holder 202”; paragraphs [0159]-[0161], “[a]s stated previously, in some circumstances, the particular resource 7440,7450,7460 is not only protected but also maintained by the account authority 7412 [for example, if the account authority 7412 is a financial institution and the resource is a bank account of the account holder 7402]”; Fig. 11; paragraphs [0194]-[0195], “[t]he account-specific information 1144 includes, for example, the account status, account balance, available credit, if any, asset holdings, pending transactions, capital gains for the year, associated account identifiers, and the like”; Fig. 19; and paragraphs [0218]-[0219].)
None of Wheeler, Carlson, Kuran, and Azen explicitly discloses a private ledger including a series of blocks of transactions that include a hash output as a reference to a prior transaction block in the series of blocks of transactions.
However, Garzik, an analogous art of processing a transaction via a private ledger, discloses a private ledger including a series of blocks of transactions that include a hash output as a reference to a prior transaction block in the series of blocks of transactions. (See page 3, “[h]owever, in most cases, financial institutions are willing to build their own private blockchains or are investigating the unspecified blockchain solutions…. Citigroup has built three private blockchains and an internal currency with a prime focus on payments and eliminating counterparty risks when dealing with smaller local banks”; page 7, “[i]mmutability and finality of transactions in blockchain systems are achieved by splitting transactions into time-ordered blocks and calculating the cryptographic hash of each of these blocks…. Each block header contains a reference to the previous block (except for the first block, which is hardcoded into the protocol)”; and Section 2.2 Access to Blockchain Data, page 10, “[a] private blockchain is a blockchain, in which direct access to blockchain data and submitting transactions is limited to a predefined list of entities.” These citations indicate that a bank/financial institution could implement a private blockchain to store a series of blocks of transactions linked together via a reference to the previous block.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of Garzik in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system as modified, one of ordinary skill in the art would have been motivated to implement a private blockchain structure as a private ledger to store transactions, so that the private ledger can have secure features of the blockchain and can be accessed only by the authorized entities.
Claims 7-8 are rejected under 35 U.S.C. 103 as being unpatentable over Wheeler et al. (US 20030115151 A1) in view of Carlson (US 20080319905 A1), and further in view of Kurani (US 11176524 B1), Azen et al. (US 20130185214 A1), and McCarthy (US 20150161596 A1).
Claim 7:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler discloses receiving, at the access device, an authorization response message for a transaction. (See Fig. 3; paragraphs [0120]-[0123], “[a]gain, it should be noted that no ‘identity’ information needs to be included in the EC 305 by the account holder 302 under this system 300”; Figs. 50-54; paragraph [0297]; and paragraphs [0324]-[0326], “[u]sing this public key, the financial institution 6012 attempts to authenticate (Step 6306) the message…. For example, even though the message authenticated, the purchaser 6050 may not have enough money or credit associated with the account for the financial institution 6012 to approve the transaction. Thus, making such a determination typically involves accessing the relevant portion(s) of the account record and confirming that the funds are available…. The financial institution 6012 also notifies (Step 6318) the merchant (via financial network 6008 and point of sale card reader 6052) of the approval of the transaction.”)
None of Wheeler, Carlson, Kuran, and Azen explicitly discloses the authorization response message for a transaction that does not include sensitive information.
However, McCarthy, an analogous art of processing transactions, discloses receiving, at the access device, an authorization response message for the transaction that does not include sensitive information. (See paragraph [0037], “[e]ach response message (with a PAN in the PAN field) from the issuer system 112 may be evaluated to determine if the transaction is one for which a token was provided to the transaction processing system by the merchant system 120. If so, the transaction processing system 124 requests from the tokenization service 150 the token corresponding to the PAN, places the token in the PAN field in lieu of the PAN, and returns that message to the merchant system 120. Alternatively, the transaction processing system could retain and store the token when it processes the original authorization request message (e.g., store the token in association with the transaction identifier), and then reinsert the token into the authorization response message when it is to be returned to the merchant system 120 (thus eliminating the need for the transaction processing system to again request the token from the tokenization service).”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of McCarthy in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system, one of ordinary skill in the art would have been motivated to exclude the user’s sensitive information from the authorization response message, so that the sensitive data can be protected.
Claim 8:
Wheeler in view of Carlson, Kuran, Azen, and McCarthy discloses the limitations shown above.
Wheeler discloses an authorization response message for the transaction. (See paragraphs [0111]-[0115], “[t]he message preferably includes the unique identifier [acctID] 216 of the account of the account holder 202 and an instruction [i1] for the account authority 212 to perform in relation to the account”; paragraph [0297]; Figs. 60-63; paragraph [0320]; and paragraphs [0324]-[0326], “[u]sing this public key, the financial institution 6012 attempts to authenticate (Step 6306) the message…. For example, even though the message authenticated, the purchaser 6050 may not have enough money or credit associated with the account for the financial institution 6012 to approve the transaction. Thus, making such a determination typically involves accessing the relevant portion(s) of the account record and confirming that the funds are available…. The financial institution 6012 also notifies (Step 6318) the merchant (via financial network 6008 and point of sale card reader 6052) of the approval of the transaction.”)
Wheeler further discloses wherein the unique identifier is the public key of the user. (See paragraph [0129], “[i]n some embodiments of the present invention, the unique identifier may actually be the public key from the device or a hashed version of the public key”; paragraph [0132], “[p]referably, the public key is associated particularly with the unique identifier of the account. In some embodiments, the public key itself (or a hashed value of the public key) is used as the unique identifier assigned to the account.”)
McCarthy further discloses including identification information for identifying user account in the authorization response message. (See paragraph [0037], “[i]f so, the transaction processing system 124 requests from the tokenization service 150 the token corresponding to the PAN, places the token in the PAN field in lieu of the PAN, and returns that message to the merchant system 120. Alternatively, the transaction processing system could retain and store the token when it processes the original authorization request message (e.g., store the token in association with the transaction identifier), and then reinsert the token into the authorization response message when it is to be returned to the merchant system 120 (thus eliminating the need for the transaction processing system to again request the token from the tokenization service).”)
Wheeler further discloses utilizing the public key as the unique identifier for identifying user account. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of McCarthy in the Wheeler system as modified. Moreover, in order to improve the security of the Wheeler system, one of ordinary skill in the art would have been motivated to include in the authorization response message the identification information, such as the public key, without revealing sensitive information, so that the customer and merchant can be informed of the transaction status and that the sensitive information is protected.
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Wheeler et al. (US 20030115151 A1) in view of Carlson (US 20080319905 A1), and further in view of Kurani (US 11176524 B1), Azen et al. (US 20130185214 A1), and White (US 20110112898 A1).
Claim 15:
Wheeler in view of Carlson, Kuran, and Azen discloses the limitations shown above.
Wheeler further discloses an access device comprising a device communication interface to communicate with the user device. (See paragraphs [0141]-[0142], “[t]he device preferably includes a device interface comprising a port--including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port--or some other physical interface for communicating with an external electronic apparatus, whether contact or contactless”; Fig. 60; paragraph [0319]; and paragraph [0322].)
None of Wheeler, Carlson, Kuran, and Azen explicitly discloses a long-range communication protocol, a short-range communication protocol, or a mid-range communication protocol.
However, White, an analogous art of processing a transaction, discloses a long-range communication protocol, a short-range communication protocol, or a mid-range communication protocol. (See paragraph [0013], “[a]s the mobile device 108 comes into range of the local or short range wireless communications protocol of the scanner 104, the scanner 104 and/or POS 102 may determine that a ‘discoverable’ mobile device is within range of the scanner 104”; paragraph [0023]; and paragraph [0029].)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include the subject matter of White in the Wheeler system as modified. Moreover, in order to improve the flexibility of the Wheeler system, one of ordinary skill in the art would have been motivated to implement different communication protocols to communicate with the user device, so that the communication between the user device and the access device can take place based on one of the communication protocols.
Claim 16:
Wheeler in view of Carlson, Kuran, Azen, and White discloses the limitations shown above.
Wheeler further discloses wherein the device communication interface comprises a QR code interface, a contactless interface, a contact interface, or a Bluetooth interface. (See paragraphs [0141]-[0142], “[t]he device preferably includes a device interface comprising a port--including a wireless communications port, a serial port, a USB port, a parallel port, or an infrared port--or some other physical interface for communicating with an external electronic apparatus, whether contact or contactless”; Fig. 60; paragraph [0319], “[a] point of sale card reader 6052 includes an alphanumeric keypad 6056, a display 6054, and, in this case, a thumbprint reader 6058. The point of sale card reader 6052 is in communication via data connector 6064 with a merchant cash register/terminal 6060, which has its own display 6062. The point of sale card reader 6052 is also in communication with a standard financial network 6008, which is in communication with and has the capability of correctly routing communications between merchants and various financial institutions represented, in this example, s by financial institutions 6012,6022,6032”; and paragraph [0322], “[t]o pay, the purchaser 6002 inserts (Step 6206) the card 6050 into the point of sale card reader 6052 (or brings the card 6050 into proximity to the card reader 6052 if both the card reader 6052 and the card 6050 are equipped for contactless proximity communications in accordance with ISO/IEC Standard 14443, which is incorporated herein by reference).”)
Conclusion
The prior art, made of record and not relied upon, is considered pertinent to the applicant’s disclosure.
Ronca et al. (US 20150365283 A1) disclose processing transaction requests and storing the quantity of cryptocurrency in a database.
Dent et al. (US 20150220921 A1) disclose providing a user device with a proxy number in place of the actual account number in the transaction data and processing the transaction based on the proxy number.
Patterson (US 20090076938 A1) discloses utilizing derived account identifiers, instead of the real account identifier, for payment transactions.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHUNLING DING, whose telephone number is (571)270-3605. The examiner can normally be reached 9:30 - 7:30 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, an applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Neha Patel, can be reached at 571-270-1492. 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.
/CHUNLING DING/Primary Examiner, Art Unit 3699