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 .
DETAILED CORRESPONDENCE
Acknowledgements
The Amendment of claims 1, 11 and 15, filed on 09/12/2025 is acknowledged.
Claims 1-2 and 5-21 were pending.
Claims 22-24 are newly added, therefore
Claims 1-2, 5 and 8-24 are hereby examined.
Examiner’s Response to Remarks/Argument
35 USC § 103
The Applicant’s remarks/response and amendment filed in response to the Non-Final Office Action mailed out on 09/12/2025, have been considered, and found not persuasive by the Examiner.
On page 14 of 16, applicant asserts that [… Assuming arguendo that Nagasundaram/Patterson disclose encrypting the token that comprises a channel identifier as one of data elements to form a cryptogram, Nagasundaram does not describe providing the channel indicator twice in the same authorization request message --- where a first instance of the channel indicator, which is selected by a user and provided by a processing network computer, is encrypted in the cryptogram and a second instance of the channel indicator is provided by a biller and included outside of the cryptogram]. Examiner respectfully disagrees, as Nagasundaram teaches in this limitation in ¶¶ 0010, 0026, 0032-0033 and 0050, as disclosed below.
Applicant further assert that [Nagasundaram does not describe that the payload authorization request message includes 5 pieces of information "(1) the token, (2) the token cryptogram including (i) the encrypted token and (ii) the encrypted payment channel indicator, and (3) a channel indicator in an unencrypted form." ] In this instance, the authorization request message consist of (1) the token, (2) the token cryptogram, which is taught by Nagasundaram in {see at least ¶¶ 0033, 0062, 0075, 0101}, what the cryptogram contains does not have patentable weight as these are as they are nonfunctional descriptive material. Therefore, as prior art teaches the authorization request message includes a token, a cryptogram and a channel indicator, is sufficient in art.
Additionally, applicant also assert that “Nagasundaram does not describe that the determination as to whether the token is being used in a correct payment channel is performed by comparing the unencrypted channel indicator received in the authorization request message generated by the biller and the decrypted payment channel indicator decrypted from the token cryptogram generated by the processing network computer (i.e., a different entity). That is, Nagasundaram does not describe "validating, by the processing network computer, the token cryptogram by comparing the channel indicator received in the authorization request message and the decrypted payment channel indicator decrypted from the token cryptogram, to determine whether the token is being used in a correct payment channel." Examiner respectfully disagrees, as this limitation
is taught by Nagasundaram in several paragraphs, for example, ¶¶ 0026, 0051, 0114 “…the token requestor device 120 may receive the token response message and may handle the response by generating a token confirmation message comprising authentication information. The authentication information may include any relevant information to allow the token issuer to validate the identity of the token requestor device. For example, the token confirmation message may comprise pre-designated information associated with the received token, a token requestor identifier, and any other information that allows the token issuer computer 160 to confirm that the token requestor device 120 is authentic and is the entity intended for the token. For example, the token requestor device 120 may include authentication information such as the data type of the token included in the token response, a token requestor identifier, the channel properties of the received transaction token, a token purpose that the transaction token is meant to be used for, and/or any other information that may be used to validate the identity of the token requestor and/or token requestor device. For instance, the token requestor device may indicate a portion of the PAN that the transaction token is associated with, the token requestor device 120, an identifier associated with an e-commerce transaction channel, and an indicator associated with the transaction being a payment token…”,…”, and ¶ 0146 “…This information interpreted from the contextual information stored in the transaction token may be utilized to determine whether the token is being processed in the appropriate context. For example, the token interpretation module 131 may interpret that the token is meant to be utilized only in e-commerce transactions, despite the token being currently processed at a point-of-sale terminal. This discrepancy may indicate a misused token and prevent a token from being validated. In some embodiments, the token interpretation module may rely on information stored in token legend which may be stored in a token legend database 134, to help interpret whether the information contained within the transaction token”, and also Fig. 4 step 403-408, ¶ 0180 “…The transaction token may be verified when the token issuer computer 160 compares the determined contextual information with the environment surrounding the current transaction associated with the transaction token…”}.
And finally, Applicant declares that “Even if the references were combined, all of the features of claim 1 would not have been archived. At least based on the foregoing, Applicant respectfully submits that claim 1 is patentable because the cited art, taken singularly or in combination, does not teach or suggest each and every feature of claim 1. Claims 11 and 15 recite similar features and are patentable at least for the similar reasons. Examiner respectfully disagrees with this conclusion as these limitation are taught by Nagasundaram.
As regards the argument that Nagasundaram does not disclose the feature of claim 9 and 10. Accordingly, the rejection is improper, and its withdrawal is respectfully requested. Examiner disagrees with this characterization because the Applicant specification does not exactly support the API includes data fields including a token data field for the token, a token cryptogram data field, and a postal code data field, however, the request body may contain these features as disclosed in the Applicant specification ¶ 0084, therefore, the teaching of Nagasundaram in ¶¶ 0026, 0050, 0110 and 0114, is sufficient in art. Therefore, the 103 rejection is hereby maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 3
U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 8-11, 13-15, 17-18 and 23 are rejected under 35 U.S.C. 103 as being unpatentable over Nagasundaram et al., (US 20150112870 A1), in view of Patterson (US 20160232527 A1) and Sheets (US 20150324736 A1).
With respect to claims 1, 11, and 15, Nagasundaram teaches a method and a processing network computer {Fig. 1, e.g., transaction processing system 100} comprising:
a processor {see at least ¶ 0012}, and
a non-transitory computer readable medium, the non-transitory computer readable medium comprising instructions, executable by the processor, to cause the
processing network computer to {see at least ¶ 0012}, the method comprising:
receiving, by a processing network computer, data associated with a payment instrument selected by a user using a user computing device for an interaction involving a bill, the payment instrument being associated with a token or a token reference identifier usable to identify the token, the token being associated with a token domain {see at least ¶ 0033 “…For example, a payment processor may receive a transaction token [e.g., token cryptogram] that was generated using a transaction token format that includes information regarding who issued the token, what device the consumer used to request, store, and/or provide the token for a transaction, what merchant received the token, what transaction channel was used for the transaction, who is responsible for verifying the token, and any other suitable information associated with the transaction token. Accordingly, the transaction token format may maintain[[s]] context and identity persistence from the start of a transaction process (i.e., token issuance) to the end (i.e., payment authorization and settlement). Thus, an inheritance tree may be updated as a token passes through various entities in a transaction processing system and any actions are performed on the transaction token or for the transaction”}.
retrieving, by the processing network computer the token {see at least ¶ 0033}.
transmitting, by the processing network computer, the token and the token cryptogram including the encrypted token and the encrypted payment channel indicator to a biller computer [e.g., Merchant], which uses the token and the token cryptogram to initiate processing of the bill, by generating an authorization request message comprising (1) the token, (
PNG
media_image1.png
12
8
media_image1.png
Greyscale
) the token cryptogram including […], and (3)_a channel indicator in an unencrypted form {see at least ¶¶ 0032-0033 “…a payment processor may receive a transaction token that was generated using a transaction token format that includes information regarding who issued the token, what device the consumer used to request, store, and/or provide the token for a transaction, what merchant received the token, what transaction channel was used for the transaction, who is responsible for Verifying the token, and any other suitable information associated with the transaction token. Accordingly, the transaction token format may maintain context and identity persistence from the start of a transaction process (i.e., token issuance) to the end (i.e., payment authorization and settlement). Thus, an inheritance tree may be updated as a token passes through various entities in a transaction processing system and any actions are performed on the transaction token or for the transaction.”, and also ¶¶ 0062, 0156 “…the merchant-specific information may be translated and included in the updated transaction token that is transmitted to a payment network for transaction processing…”}.
receiving, by the processing network computer, the authorization request
message comprising the token, the token cryptogram […], and the channel indicator {see at least ¶¶ 0033, 0062, 0075, 0101}.
validating, by the processing network computer, the token cryptogram by comparing the channel indicator received in the authorization request message and the […] payment channel indicator […], to determine whether the token is being used in a correct payment channel indicator {see at least ¶¶ 0010, 0026 “…the transaction token may include a format that may comprise data elements including a system identifier, an account issuer identifier, a data type identifier, a channel identifier, a token purpose identifier, a token verifier identifier, information about the channel properties associated with the transaction token, and a token payload or account substitute…”, and also ¶¶ 0028, 0050 “…transaction parameter information may include at least one of a token type identifier, a channel identifier, channel properties, expiration information, and transaction restriction information. A token type identifier may indicate what kind of sensitive information is associated with the token, such as a financial account identifier (e.g., PAN), personally identifiable information, or personal health information. A channel identifier may indicate what transaction channels the token is meant to be processed over or the channel that the token has been processed over, or both…”, and ¶¶ 0051, 0054, 0114 “…the token requestor device 120 may receive the token response message and may handle the response by generating a token confirmation message comprising authentication information. The authentication information may include any relevant information to allow the token issuer to validate the identity of the token requestor device. For example, the token confirmation message may comprise pre-designated information associated with the received token, a token requestor identifier, and any other information that allows the token issuer computer 160 to confirm that the token requestor device 120 is authentic and is the entity intended for the token. For example, the token requestor device 120 may include authentication information such as the data type of the token included in the token response, a token requestor identifier, the channel properties of the received transaction token, a token purpose that the transaction token is meant to be used for, and/or any other information that may be used to validate the identity of the token requestor and/or token requestor device. For instance, the token requestor device may indicate a portion of the PAN that the transaction token is associated with, the token requestor device 120, an identifier associated with an e-commerce transaction channel, and an indicator associated with the transaction being a payment token…”, and Fig. 4 step 403-408, ¶ 0180 “…The transaction token may be verified when the token issuer computer 160 compares the determined contextual information with the environment surrounding the current transaction associated with the transaction token…”}.
retrieving, by the processing network computer, a credential associated with the token {see at least ¶ 0068 “…The token requestor 120 may be configured to communicate with the merchant computer 130, the acquirer computer 140, the payment network computer 150, and the issuer computer 170 through a transaction channel 180. The transaction channel 180 may be, for example, a proximity or contactless transaction channel, an e-commerce transaction channel, a contact-based transaction channel (e.g., magnetic stripe, etc.), etc.”, and also ¶ 0089 “The channel identifier 204 can identify the transaction channel(s) that can process the transaction token. For example, the channel identifier may inform a merchant as to whether the token is limited to e-commerce transactions, point of sale transactions, mobile transactions, or mobile point of sale transactions, or any combination thereof…”}.
modifying, by the processing network computer, the authorization request message to include the credential associated with the token, wherein contents of the modified authorization request message indicate whether or not the token is being used in the correct payment channel {see at least ¶¶ 0068, 0089}, and
transmitting a modified authorization request message including the credential to an authorizing entity computer, which authorizes the interaction based on the contents of the modified authorization request message indicating that the token is being used in the correct payment channel {see at least ¶ 0032 “…a merchant may receive a transaction token during a transaction where the transaction token includes information about the specific purpose of the transaction token. For example, the information in the transaction token may indicate that the transaction token is a high value token (e.g., one that is used for payment) or a low value token… A merchant can thus determine if the transaction token is a high value token or a low value token. The merchant may also include additional merchant-specific information in the token and may reformat the transaction token if desired. As such, in some embodiments, the transaction token format may provide enough space so that a merchant may modify or customize a transaction token for their own purposes”, and also ¶¶ 0063, 0129 “…the token verifier computer 160 may process the verification request and make a determination as to the status of the underlying transaction token. For example, the token verifier computer 160 may check whether the transaction token is being utilized in the e-commerce transaction channel as indicated it should be in the token verification request. If the transaction token is not being utilized in an e-commerce transaction, the token verifier computer 160 may recognize immediately that the transaction token may be fraudulent. The token verifier computer 160 may verify as many data fields associated with the transaction token as necessary and/or desired to make a decision about the validity of the token”, and ¶ 0136 “At step 409, the token subscriber computer 130 may send the verification confirmation message to the token verifier computer 160 to indicate that the token status has been checked and that the token subscriber successfully received the verification response. As explained in relation to FIG. 3, the confirmation message may include authentication information to allow the system to verify that the correct
subscriber received the verification response}.
Nagasundaram does not explicitly disclose,
transmitting, by the processing network computer, the token and the token cryptogram including the encrypted token and the encrypted payment channel indicator … by generating an authorization request message comprising (1) the token, ( ) the token cryptogram including (i) the encrypted token and (ii) the encrypted payment channel indicator […];
generating, by the processing network computer, a token cryptogram, by encrypting the token and a payment channel indicator indicating the token domain;
retrieving, by the processing network computer, the token that corresponds with the credential from the authorization response message;
modifying, by the processing network computer, the authorization response message to include the token that corresponds with the credential
decrypting, by the processing network computer, the token cryptogram to obtain a decrypted payment channel indicator.
However, Patterson discloses:
transmitting, by the processing network computer, the token and the token cryptogram including the encrypted token and the encrypted payment channel indicator […] by generating an authorization request message comprising (1) the token, (2) the token cryptogram including (i) the encrypted token and (ii) the encrypted payment channel indicator […] {see at least ¶ 0042 “…The token requestor 120 may be configured to communicate with the resource provider computer 130 through a transaction channel 180. The transaction channel 180 may be, for example, a proximity or contactless transaction channel, an e-commerce transaction channel…”, ¶ 0059 “…The cryptogram may have been generated using an encryption key that resides on the communication device…”}
generating, by the processing network computer, a token cryptogram, by encrypting the token and a payment channel indicator indicating the token domain {see at least ¶ 0002 “…For example, instead of having ubiquitous properties, tokens are intentionally restricted. These restrictions are known as domain restrictions. The purpose of domain restrictions is to protect both the consumer and merchant from fraudulent and inappropriate purchases. Tokens are issued with domain restrictions based on the nature of the token requestor…”, ¶ 0042 “… The token requestor 120 may be configured to communicate with the resource provider computer 130 through a transaction channel 180. The transaction channel 180 may be, for example, a proximity or contactless transaction channel, an e-commerce transaction channel, a contact-based transaction channel…”,¶ 0025 “…A token request message may include information usable for identifying a payment account or digital wallet, and/or information for generating a payment token. For example, a token request message may include payment credentials, mobile device identification information (e.g. a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other Suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key), ¶ 0059 “…Prior to this, the resource provider computer receives the token and the cryptogram from a communication device used by a user. The communication device may be a mobile phone, which may function as a payment device. The cryptogram may have been generated using an encryption key that resides on the communication device. The encryption key may be used to encrypt data from the resource provider computer (e.g., a terminal ID, date and time of the transaction, etc.) and data from the communication device (e.g., a device ID, the token, the token expiration date, etc.) to form the cryptogram., ¶¶ 0060-0062, 0079 “…the processing network computer 150 may receive and may then determine that the first authorization request message contains the token. It may also send the token and any other pertinent information to the token issuer 160. Other pertinent information may include any channel indicators or transaction characteristics such as transaction amount. Such information can be used to the token issuer 160 to determine if the token that is being used is within the domain restrictions set for that token”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the computing device of Patterson to preserve associated token attributes/format of a token in a payment transaction. Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request. Patterson is merely relied upon to illustrate the functionality of protecting transaction data with an encrypted cryptogram in a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, as well as protecting transaction data with an encrypted cryptogram and are implemented through well-known computer technologies, combining their features as outlined above, would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram as well as Patterson, would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson.
Nagasundaram in view of Patterson does not explicitly disclose decrypting, by the processing network computer, the token cryptogram to obtain a decrypted payment channel indicator.
However, Sheets discloses decrypting, by the processing network computer, the token cryptogram to obtain a decrypted payment channel indicator {see at least ¶ 0040 “A “payment request may include a message comprising a request to process or initiate a payment. For example, the payment request may be sent from mobile device associated with a consumer in relation to a purchase transaction associated with goods or services provided by a merchant. The payment request may include any relevant information to the transaction including payment information (e.g., account identifiers, personal information, etc.), transaction information (e.g., merchant information, items being purchased, etc.), device information (e.g., mobile device phone number, secure element identifier, etc.), routing information (e.g., internet protocol (IP) address of a destination computer, identifier for destination computer, bank identification number (BIN), etc.), and any other relevant information to a payment transaction. For example, a payment request may include encrypted payment information for a transaction and may be sent to a third party computer that is configured to authenticate the payment request, validate a public key certificate, decrypt the encrypted payment information, extract a public key from the validated certificate, re-encrypt the decrypted payment information, and send the re-encrypted payment information to a transaction processor for initiation of a payment transaction.”, and also ¶¶ 0045-0046, 0050 “In some embodiments, the security value may include a cryptogram. For example, a cryptogram may be generated per transaction based on a derived algorithm that is specific to a consumer device and/or issuer account and may be validated at a payment processor or an issuer of the account for each transaction…”, and ¶¶ 0173-0174}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson to include the elements of decryption of Sheets to have a secured transaction message. Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, and Patterson discloses protecting transaction data with an encrypted cryptogram. Sheets is merely relied upon to illustrate the functionality of a decryption of an encrypted transaction message. Because both having a computing one device configured to perform actions for processing a payment authorization request, and protecting transaction data with an encrypted cryptogram, as well as having a decryption of an encrypted transaction message and are implemented through well-known computer technologies, combining their features as outlined above would be reasonable, according to of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson, as well as Sheets would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson/Sheets.
With respect to claim 2, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Nagasundaram discloses, wherein the processing network
computer receives the token reference identifier {¶¶ 0090-0091}, and the method further comprises: retrieving the token from a token service computer using the token reference identifier {see at least ¶ 0090 “The purpose identifier 205 may identify the purpose of the transaction token. Examples of purpose identifiers may include a non-transactable token identifier (NTTID), a limited use token identifier (LUTID), a payment token identifier (PTID), an ecosystem specific token identifier (ESTID), and an actionable payment/transaction identifier (TTID). A NTTID purpose identifier may identify the transaction token as a non-transactable token that may be stored on a merchant system or other system instead of a real account number… A TTID purpose indicator may identify a transaction token identifier that includes a transaction identifier instead of a payment account identifier…”, and also ¶ 0091 “A token verifier identifier 206 may identify a party that can verify the transaction token. A token verifier may receive requests from entities in the transaction ecosystem and provide a status or other indicator of the transaction token as being active, on hold, or revoked…”}.
With respect to claim 5, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Nagasundaram discloses, wherein the processing network computer receives the authorization request message comprising the token from the […] {see at least ¶ 0033 “…a payment processor may receive a transaction token that was generated using a transaction token format that includes information regarding who issued the token, what device the consumer used to request, store, and/or provide the token for a transaction, what merchant received the token, what transaction channel was used for the transaction, who is responsible for verifying the token, and any other suitable information associated with the transaction token, and also ¶ 0035}.
With respect to claim 8, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Nagasundaram discloses wherein the processing network
computer transmits the token to the biller computer via an API {see at least ¶ 0080 “the token issuer 160 may communicate with the merchant computer 130 through the use of merchant APIs…”}.
With respect to claim 9, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 8 above.
Furthermore, Nagasundaram discloses wherein the API includes data fields including a token data field for the token, a token cryptogram data field, and a postal code data field {see at least ¶¶ 0026, 0050, 0110 “…Accordingly, the contextual information within the transaction token format may be interpreted according to a mapping of data fields stored in a token legend. For instance, the token issuer may generate the transaction token to indicate a payment network (“40 for payment processor A), a token issuer (“01 f0” for token issuer computer 160), a data type (“d01' for PAN), channel restrictions associated with an e-commerce transaction ("00" for e-commerce transaction), a token purpose (“00051 for payment token identifier), a token verifier ("0000 for same entity as token issuer), channel properties (“1234 for the zip code of the token requestor device 120), and the token payload ("0012:0034”
representing a numeric token)” and ¶ 0114}.
With respect to claim 10, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 9 above.
Furthermore, Nagasundaram discloses wherein the API includes data fields
including a token data field for the token, a token cryptogram data field, and a postal
code data field {see at least ¶¶ 0026, 0050, 0110, 0114}.
With respect to claim 13, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 11 above.
Furthermore, Nagasundaram discloses, wherein the token is a substitute for the
credential {see at least ¶ 0008 “Tokenization involves the replacement or exchange of original payment credentials (i.e., a primary account number (PAN)) with a substitute identifier (i.e., a transaction token). The substitute identifier may be used as a replacement for the original payment credentials to initiate a transaction or manage payment activity…”, and also ¶¶ 0025-0028 “…Traditional transaction tokens… are "dummy" substitute values for payment credentials”, and ¶ 0042}.
With respect to claim 14, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 11 above.
Furthermore, Nagasundaram discloses, wherein the token has a same format as the credential {see at least ¶¶ 0008, 0025-0028, 0042}.
With respect to claim 17, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 15 above.
Furthermore, Nagasundaram discloses wherein the processor computer stores the token reference identifier associated with the token, and wherein the processor computer transmits the token reference identifier to the processing network computer, which uses the token reference identifier to retrieve the token and then uses the token to process the bill {see at least ¶¶ 0033, 0035-0036, 0044 0071 “…the consumer may use their mobile device to obtain a token that is stored by a remote server computer of a mobile wallet provider…”}.
With respect to claim 18, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 15 above.
Furthermore, Nagasundaram discloses wherein the processor computer stores the token, and wherein the processor computer transmits the token to the processing network computer, which uses the token to process the bill {see at least ¶¶ 0033, 0035-
0036, 0044 0071}.
With respect to claim 23, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Patterson discloses receiving, by the processing network computer from the authorizing entity computer, the authorization response message {see at least ¶ 0075 “…In some embodiments, the payment network computer 150 may forward an authorization
request received from the acquirer computer 140 to the issuer computer 170 via a communication channel. The payment network computer 150 may further forward an authorization response message received from the issuer computer 170 to the acquirer
computer 140”}.
retrieving, by the processing network computer, the token that corresponds with the credential from the authorization response message {see at least ¶¶ 0083-0084}.
modifying, by the processing network computer, the authorization response message to include the token that corresponds with the credential {see at least ¶¶ 0083-0085 “…after the token issuer 160 receives the real account identifier, the token issuer 160 may send back the token corresponding to the real account identifier. After the processing network computer 150 receives the token from the token issuer 160, the processing network computer 150 may modify the first authorization response message received from the authorizing computer 170 to replace the real account identifier with the token”}, and
transmitting a modified authorization response message including the token to the biller computer that completes processing of the bill {see at least ¶¶ 0085-0086 “…the first authorization response message comprising the token is forwarded to the transport computer 140. After the transport computer 140 receives the first authorization response message, it then sends the first authorization response message to the resource provider computer 130”, and also ¶ 106}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson to include the elements of decryption of Sheets to have a secured transaction message. Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, and Patterson discloses protecting transaction data with an encrypted cryptogram. Sheets is merely relied upon to illustrate the functionality of a decryption of an encrypted transaction message. Because both having a computing one device configured to perform actions for processing a payment authorization request, and protecting transaction data with an encrypted cryptogram, as well as having a decryption of an encrypted transaction message and are implemented through well-known computer technologies, combining their features as outlined above would be reasonable, according to of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson, as well as Sheets would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson/Sheets.
Claim 22, is rejected under 35 U.S.C. 103 as being unpatentable over Nagasundaram et al., (US 20150112870 A1), in view of Barbara Patterson (US 20160232527 A1) and Sheets (US 20150324736 A1), further in view of Ravinathan (US 20210312431 A).
With respect to claim 22, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above. However
the combination of Nagasundaram and Patterson in view of Sheets does
not disclose the subject matter of claim 22.
However, Ravinathan discloses, further comprising: storing, the processing network computer in a data storage, a cryptographic key pair, wherein the token cryptogram is generated by encrypting the token and the payment channel indicator using a first key of the cryptographic key pair, and is decrypted using a second key of the cryptographic key pair {see at least ¶ 0029 “…For instance, each computing device may each have their own private key for respective cryptographic key pairs, and may each be a blockchain wallet for use in transactions with the blockchain associated with the blockchain network. Computing devices may be any type of device suitable to store and utilize a blockchain wallet, such as a desktop computer, laptop computer, notebook computer, tablet computer, cellular phone, smart phone, smart watch, smart television, wearable computing device, implantable computing device, etc.,”, ¶ 0050 “The computing system 200 may include an account database 206. The account database 206 may be configured to store one or more account profiles 208 using a suitable data storage format and schema. The account database 206 may be a relational database that utilizes structured query language for the storage, identification, modifying, updating, accessing, etc. of structured data sets stored therein. Each account profile 208 may be a structured data set configured to store data related to a transaction account for which the integrated circuit payment card 102 may be used to fund an electronic payment transaction, and may include data based thereon. For instance, an account profile 208 may include a payment account number for a fiat-based transaction account as well as a private key for a cryptographic key pair used when cryptocurrency is used to fund transactions initiated for that transaction account and any other additional data, such as unspent transaction outputs, cryptocurrency amounts, a public key of the issuing financial institution's cryptographic key pair, an application transaction counter, application cryptograms, etc.,”, and also ¶ 0062}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Ravinathan to have a cryptographic key pair secured transaction in the payment transaction computer of Nagasundaram . Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Ravinathan is merely relied upon to illustrate the functionality of having a cryptographic key pair secured transaction in the payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a cryptographic key pair secured transaction in the payment transaction and are implemented through well-known computer technologies, combining their features as outlined above would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Ravinathan would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson/Sheets/Ravinathan.
Claims 16, 19-21 and 24, are rejected under 35 U.S.C. 103 as being unpatentable over Nagasundaram et al., (US 20150112870 A1), in view of Barbara Patterson (US 20160232527 A1) and Sheets (US 20150324736 A1), further in view of Mohsenzadeh (US 20130268434 A1).
With respect to claim 16, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 15 above, but does not explicitly disclose, however, Mohsenzadeh discloses, further comprising, receiving the bill from the biller computer, prior to receiving the request to pay the bill {see at least ¶ 0012 “… include presenting one or more bills from the biller using the billing software to a customer of the biller through an aggregator presentment and payment network (APPN) as well as receiving payment information by the billing software from an aggregator presentment and payment network APPN for the customer of the biller and causing the crediting of payment to the customer's account using the billing software…” and also ¶ 0013}, and
presenting the bill to an application on the user computing device {see at least
Fig.5A-Fig. 9B, ¶ 0017 “…the billing software generates an electronic message that includes bill information and sends the electronic message to a mobile device such that the electronic message can be selected from the group consisting of a SMS message, text message, or voice message. The billing software may generate a second electronic message and sends the second electronic message to a mobile device, the second electronic message provides a hyperlink to a website managed by the billing software
for a customer to view a bill…”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Mohsenzadeh. One would have been motivated to do so, in order to have a bill payment service in the payment transaction computer of Nagasundaram . Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Mohsenzadeh is merely relied upon to illustrate the functionality of a biller computer interfacing in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller computer interfacing are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Mohsenzadeh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson/Sheets/Mohsenzadeh.
With respect to claim 19, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 15 above.
Furthermore, Mohsenzadeh discloses, further comprising: providing an interface to the user computing device that allows a user of the user computing device to select the credential from a list of different types of credentials {see at least Fig.5A-Fig. 9B, ¶ 0017 “…Further, the billing software receives and stores payment information associated with a customer of the biller wherein payment information can be selected from the group consisting of credit card information, debit card, information, prepaid card information, banking card information or ACH information. In addition, the billing software receives payment instructions in a third electronic message from a mobile device across a communication network and processes the payment based on payment instructions and payment information…”}.
Therefore, it would have been obvious before the effective filing date of the
claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Mohsenzadeh. One would have been motivated to do so, in order to have a bill payment service in the payment transaction computer of Nagasundaram . Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Mohsenzadeh is merely relied upon to illustrate the functionality of a biller computer interfacing in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller computer interfacing are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Mohsenzadeh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over
Nagasundaram/Patterson/Sheets/Mohsenzadeh.
With respect to claim 20, the combination of Nagasundaram and Sheets in view of Mohsenzadeh teaches all the subject matter as disclosed in claim 15 above.
Furthermore, Mohsenzadeh discloses, further comprising: presenting a user interface on the user computing device that allows a user of the user computing device to select a biller from a list of different billers. {see at least ¶ 0014 “… the one or more communication interfaces is selected from the group consisting of web, IVR, SMS, WAP, mobile software application or a combination thereof. Moreover, the one or more gateway interfaces provide network interfaces to payment networks and the one or more gateways process payment transactions for a channel such that the payment networks are selected from the group consisting of an aggregator presentment and payment network (APPN), an electronic funds transfer (EFT) network, credit card network and an Automated Clearing House (ACH) network…”, and also ¶ 0019 “…wherein provisioning one or more billers on the billing software includes selecting one or more billing models associated with the bill presentment and bill payment capability as well as configuring payor workflow of the bill presentment and payment capability based on the selected billing model. Further, the system includes one or more communication interfaces coupled to the billing software to provide the bill presentment and bill payment capability to one or more billers”}, and
receiving, through the user interface, a user input selecting the biller associated with the biller computer {see at least ¶¶ 0014, 0019}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Mohsenzadeh. One would have been motivated to do so, in order to have a bill payment service in the payment transaction computer of Nagasundaram . Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Mohsenzadeh is merely relied upon to illustrate the functionality of a biller computer interfacing in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller computer interfacing are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Mohsenzadeh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over
Nagasundaram/Patterson/Sheets/Mohsenzadeh.
With respect to claim 21, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Nagasundaram discloses, wherein one or more tokens are used to pay a plurality of bills at a plurality of biller computers, the token is one of the one or more tokens (see at least ¶ 0042 “…a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction. The token may also be used to represent the original credential in other systems where the original credential would typically be provided…”}, and
Mohsenzadeh further disclose the biller computer is one of the plurality of biller computers {see at least ¶¶ 0009, 0013 “…The system may include a billing software executing on one or more computer servers as well as one or more communication interfaces coupled to a billing software providing a bill presentment and bill payment capability to one or more customers of the billers. The system may further include one or more gateway interfaces coupled to the billing software…”, and also ¶ 0016}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Mohsenzadeh. One would have been motivated to do so, in order to have a bill payment service in the payment transaction computer of Nagasundaram .
Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Mohsenzadeh is merely relied upon to illustrate the functionality of a biller computer interfacing in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller computer interfacing are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Mohsenzadeh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram/Patterson/Sheets/Mohsenzadeh.
With respect to claim 24, the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 1 above.
Furthermore, Mohsenzadeh discloses, wherein the user selects the payment instrument through a user interface provided on the user computing device {see at least Fig.5A-Fig. 9B, ¶ 0017 “…Further, the billing software receives, and stores payment information associated with a customer of the biller wherein payment information can be selected from the group consisting of credit card information, debit card, information, prepaid card information, banking card information or ACH information…”}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller computer of Mohsenzadeh. One would have been motivated to do so, in order to have a bill payment service in the payment transaction computer of Nagasundaram . Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Mohsenzadeh is merely relied upon to illustrate the functionality of a biller computer interfacing in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller computer interfacing are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Mohsenzadeh would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over
Nagasundaram/Patterson/Sheets/Mohsenzadeh.
Claim 12, is rejected under 35 U.S.C. 103 as being unpatentable over Nagasundaram et al., (US 20150112870 A1), in view of Barbara Patterson (US 20160232527 A1) and Sheets (US 20150324736 A1), further in view of Hanan et al., (US 20100030675 A1).
With respect to claim 12 the combination of Nagasundaram and Patterson in view of Sheets teaches all the subject matter as disclosed in claim 11 above, but does not explicitly disclose, however Hanan discloses, wherein the non- transitory computer readable medium further comprises a biller directory which includes addresses of billers and biller identifiers {see at least ¶ 0022 “…a system and method for billers to set up a registry of payment preferences. For example, a biller may register with a payor hub by providing information relating to payment preferences (e.g., payment address, payment type (e.g., check, ACH, wire, etc.), payment due date, etc.). The payors may then access the registry and schedule payments accordingly. In some embodiments, payments may automatically be carried out according to information in the biller's registry…”, and also ¶¶ 0035-0038 {“Payors 130 may register company details, account details and their billers 120 (e.g., regular vendors, service providers, etc.) in a central registry (e.g., storage 140) maintained by the host (e.g., a sponsoring bank). The host (e.g., sponsoring bank) may invite the stored billers 120 (e.g., vendors, etc.) to participate. Billers 120 may also register themselves and their payors 130 in the service to view and download the payment information“}.
Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art, to modify the processing processor computer of Nagasundaram in view of the encrypted cryptogram of Patterson, and the elements of decryption of Sheets, to include the elements of a biller registry of Hanan. One would have been motivated to do so, in order to have a biller registry in a bill payment transaction. Furthermore, Nagasundaram discloses having a computing device configured to perform actions for processing a payment authorization request, Patterson discloses protecting transaction data with an encrypted cryptogram, and Sheets discloses having a decryption of an encrypted transaction message. Hanan is merely relied upon to illustrate the functionality of having a biller registry in the same or similar context of a payment transaction. Because both having a computing device configured to perform actions for processing a payment authorization request, protecting transaction data with an encrypted cryptogram, and having a decryption of an encrypted transaction message, as well as having a biller registry are implemented through well-known computer technologies in the same or similar context, combining their features as outlined above using such well-known computer technologies (i.e., conventional software/hardware configurations), would be reasonable, according to one of ordinary skill in the art. Moreover, since the elements disclosed by Nagasundaram in view of Patterson and Sheets, as well as Hanan would function in the same manner in combination as they do in their separate embodiments, it would be reasonable to conclude that their resulting combination would be predictable. Accordingly, the claimed subject matter is obvious over Nagasundaram /Patterson/Sheets/Hanan.
Conclusion
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.
The prior art made of record and not relied upon:
Bayan et al. (US 20240179003 A1), Distributed Tokenization
Authentication - relates generally to tokenization processes, although not limited thereto. More specifically, the present invention relates to techniques for providing decentralized tokenization with mapping data devoid of sensitive data.
2) Dooley et al. (US 20180232725 A1), Patent Tokenization using Separate Token Vault – relate to, among other things, payment token processes that separate the role of a token vault from a token service provider. The token service provider continues to provide front-end token services, while the decoupled token vault assumes responsibilities that include, among other things, allocation of payment tokens to payment account identifiers of payment instruments (e.g., credit cards, debit cards, bank accounts, etc.) during token enrollment and detokenization to obtain the payment account identifiers of the payment tokens during the processing of payment transactions.
3) Powell et al. (US 20150127547 A1), Network Token System – relates to providing, along with a token, a token assurance level and data used to generate the token assurance level. At the time a token is issued, steps may be taken to ensure that the token is replacing a PAN that was legitimately being used by a token requestor.
4) O’Connell et al. (US 20210201283 A1), System for Resolving Poor Patron Experience - relates generally to the field of retail operations, and more specifically to methods and apparatus for improved transaction processing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT IDIAKE whose telephone number is (571)272-1284. The examiner can normally be reached on Mon-Fri from 10:30AM to 7:30PM ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PATRICK MCATEE, can be reached at telephone number (571)272-1284. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated-interview-request-air-form
/V.I./Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698