DETAILED CORRESPONDENCE
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 .
Acknowledgement
This communication is in response to the amendment filed on May 13, 2026. Claims 1-20 are currently pending and have been fully examined.
Response to Arguments
With respect to the rejections under 35 USC 101, Applicant argues, on page 10-11 of remarks, that the Office Action overgeneralizes the Claims and does not evaluate character of the claims as a whole. Specifically, Applicant states that characterization of claims as being directed to "validating a sender of a message based on the message content, and executing a payment transaction when the sender is validated." is too high-level and does not account for the claim language as amended. Applicant further refers to the Appeals Review Panel's precedential decision in Ex parte Desjardins, confirming that the 101 analysis must evaluate the claim as a whole and the significance of the additional elements relative to the invention.
The examiner respectfully notes that Applicant’s above remark is interpreted as Applicant believing that the amendment to claim 1 overcomes the previous 101 analysis by introducing additional elements. The examiner respectfully disagrees with Applicants argument and notes that the amendment to claim 1, for example:
…the email message originating from a responder and being generated in response to selection of a mailto hyperlink, the email message including a token inserted by the mailto hyperlink into a predefined location within a message body of the email message, wherein the mailto hyperlink is configured to address the email message to an email address associated with the payment server and to include the token in the predefined location within the message body;
merely describes an email message and its content, which further describes the abstract idea and does not even recite an additional element that could amount to more than the abstract idea. Claim 11 recites similar amendment and therefore the same analysis of claim 1 applies to claim 11.
Applicant concludes, on page 11, that the amended claims recite a specific ordered arrangement of email-client functionality, mailto-based message generation, predefined body-token placement, server-side parsing, token decoding, sender-address binding, and payment execution.
The examiner respectfully notes that the functionality noted by Applicant consists of steps either executable by human activity (parsing, decoding, address binding, payment executing) or automated steps using technology as a tool such as, server-side parsing, and mailto-based message generation. For example, inserting a hidden code or token in a message that would require decoding by the receiver is a concept that can be applied to paper secret notes. The use of a mailto hyperlink merely automates generation of the secret note.
Applicant further argues, on pages 12-13, that under Desjardins, the amended claims integrate abstract idea into a practical application. Applicant further argues that the additional limitations are not generic computer components appended to an abstract concept, and that they define the specific way the claimed payment authorization is initiated, structured, transmitted, parsed, and validated in an email communication environment.
The examiner respectfully disagrees and notes that, although not recited in the claim, according to the Specification, the selection of a mailto hyperlink in this application is performed by a user (human) by clicking on the hyperlink. In addition, the additional elements such as a payment server, do not perform any specific functions that suggest requiring a non-generic computing device. For example, parsing a message for extracting data from the message, comparing addresses, and executing a payment transaction, are all activities that can be performed by a human on message data written on a piece of paper. Using a payment server merely automates the processes and does not integrate into a practical application.
Applicant further argues, on pages 13 and 14, that the claims recite a concrete email-response architecture in which a mailto hyperlink creates a structured authorization email addressed to the payment server and containing a token in a known body location, and that the provided architecture improves electronic payment system. The examiner respectfully disagrees and notes that the structured email argued by Applicant is merely a way for structuring data, but it is not clear what “architecture” Applicant is referring to as provided by the claims, because no technological architecture is provided by the claims to overcome the abstract idea.
Applicant in multiple places, including on page 14, refers to Desjardins analysis. The examiner respectfully disagrees with the comparison between the present Application and Desjardins and notes that Desjardins subject matter involves training a machine learning model which is different from the present Application and therefore, the comparison is incommensurable, because the two Applications lack a common basis.
Applicant, on pages 15- 17, refers to the Federal Circuit's decision in CosmoKey Solutions GmbH & Co. KG v. Duo Security LLC, 15 F.4th 1091 (Fed. Cir. 2021), as supporting eligibility of the present Application. The Federal Circuit analysis of Cosmokey states that “the claims and written description suggest that the focus of the claimed advance is activation of the authentication function, communication of the activation within a predetermined time, and automatic deactivation of the authentication function, such that the invention provides enhanced security and low complexity with minimal user input.” The Federal Circuit further discusses: “The ’903 patent claims and specification recite a specific improvement to authentication that increases security, prevents unauthorized access by a third party, is easily implemented, and can advantageously be carried out with mobile devices of low complexity… the ’903 patent discloses a technical solution to a security problem in networks and computers. While authentication of a user’s identity using two communication channels and a mobile phone was known at the time of the invention, nothing in the specification or anywhere else in the record supports the district court’s suggestion that the last four claim steps—including (1) “as a criterion for deciding whether the authentication to the transaction shall be granted or denied, having the authentication device check whether a predetermined time relation exists between the transmission of the user identification and a response from the second communication channel”; (2) “ensuring that the authentication function is normally inactive and is activated by the user only preliminarily for the transaction”; followed by (3) “ensuring that said response from the second communication channel includes information that the authentication function is active”; and (4) “thereafter ensuring that the authentication function is automatically deactivated,” are conventional.”
Contrary to Applicant’s argument that the present claims are analogous to CosmoKey, the examiner does not see the claims analogous because a similar analysis performed by the Federal Circuit on CosmoKey does not apply to the present claims. This is because, for example, neither of steps of the present claim 1 can be identified as “non-conventional” as concluded by the Federal Circuit with respect to CosmoKey’s claim steps. The steps of claim 1, for example, include steps:
receiving, by a payment server comprising a processor and memory, an email message over a communication network, the email message originating from a responder and being generated in response to selection of a mailto hyperlink, the email message including a token inserted by the mailto hyperlink into a predefined location within a message body of the email message, wherein the mailto hyperlink is configured to address the email message to an email address associated with the payment server and to include the token in the predefined location within the message body;
parsing, by the processor, the email message to extract the token from the predefined location within the message body;
decoding, by the processor, the token to retrieve transaction information including an intended responder email address, a transaction amount, and a requestor identity;
comparing, by the processor, the intended responder email address from the token with an actual sender address of the email message to authenticate the responder;
upon confirming a match between the intended responder email address and the actual sender address of the email message, executing, by the processor, a payment instruction by transmitting the transaction amount and requestor identity to a payment processing system,
wherein the transaction is executed based solely on the receipt and validation of the email message, without requiring the responder to access a web interface, enter login credentials, or perform multi-step authentication,
thereby reducing the latency, complexity, and vulnerability of conventional browser-based payment authorization mechanisms.
The examiner respectfully does not find any non-conventional steps in the above claim, and therefore notes that the comparison between the present claims and CosmoKey is incommensurable.
With respect to dependent claims, Applicant argues, on page 18, that dependent claims are not directed to a disembodied business concept. The examiner respectfully disagrees and notes that the dependent claims further describe the abstract idea recited in the independent claims and therefore are ineligible.
Applicant further argues, on page 19, that the amended claims recite significantly more than any alleged abstract idea under Step 2B, because “the claimed payment server does not merely receive data and make a decision. It receives a particular email message generated by selection of a mailto hyperlink, where the token is inserted by the mailto hyperlink into a predefined location within the message body. The payment server parses that predefined location, decodes the token to retrieve specific transaction information, compares a token-encoded intended responder email address with an actual sender address, and executes payment only after the address match is confirmed.”
The examiner respectfully disagrees and notes that as stated above, the claim recitations merely describe conventional steps that are taken to receive an input, extract data from the input by parsing, compare the extracted data with stored data and make ma decision based on the comparison results. The details about the content of the message does not make the claim eligible or make claim steps non-conventional.
With respect to the rejections under 35 USC 103, Applicant, on pages 21-24, merely argues that the cited prior art does not teach the amended claim features. The examiner respectfully notes that the amended claim portions are taught by a newly cited prior art and therefore Applicant’s arguments are moot in light of new grounds of rejection.
Applicant further, on page 25, argues that the prior position that extracting the token from a predefined location merely indicates an intended use is also no longer applicable to the amended claims. The examiner respectfully notes that the “extracting” feature is rejected by citing prior art. Therefore, even when not interpreted as intended use, the claim recitation is taught by cited prior art.
Applicant further argues, on pages 26-27, that the proposed combination of Malcolm and Seliger would not yield the claimed invention. The examiner respectfully notes that this argument is moot in light of new grounds of rejection.
Applicant further argues, on page 28, that the rejection maps Malcolm's digital certificate and transaction data to the claimed token and that the mapping is not consistent with the amended claims, because the claims require that the decoded token includes an intended responder email address, and that the payment server compares that intended responder email address with the actual sender address of the email message to authenticate the responder.
The examiner respectfully disagrees and notes that the digital certificate of Malcolm provides the same features claimed with respect to the token. For example, Malcolm on Page 6 Lines 13-20, Page 29 Lines 17-28 teaches that digital certificate data is encrypted before sending and decrypted (decoded) by recipient and provides sender identity and specifies payment amount: Page 44 Line 29- Page 45 Line 7) In addition, the newly cited art of Killoran teaches, at least in [0034], [0038] and Claim 1, that hyperlink includes email address and transaction information.)
The examiner notes that Applicant’s argument with respect to Seliger and Labrou, on pages 29-31, is moot in light of new grounds of rejection.
The examiner notes that Applicant’s argument with respect to dependent claims 4 and 12, on page 32, is moot in light of new grounds of rejection.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claims 1-9 is directed to a method (process.) Claim 10 is directed to a non-transitory computer-readable medium (product,) and claims 11-20 are directed to a system (product.) Therefore, these claims fall within the four statutory categories of invention.
Claims 1-20 are directed to the abstract idea of validating a sender of a message based on the message content, as explained in detail below. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
Analysis
In the following analysis, bolded text indicates abstract idea and the rest of the text indicates additional elements. Independent claims 1, 10 and 11, recite:
receiving, by a payment server comprising a processor and memory, an email message over a communication network, the email message originating from a responder and being generated in response to selection of a mailto hyperlink, the email message including a token inserted by the mailto hyperlink into a predefined location within a message body of the email message, wherein the mailto hyperlink is configured to address the email message to an email address associated with the payment server and to include the token in the predefined location within the message body;
parsing, by the processor, the email message to extract the token from the predefined location within the message body;
decoding, by the processor, the token to retrieve transaction information including an intended responder email address, a transaction amount, and a requestor identity;
comparing, by the processor, the intended responder email address from the token with an actual sender address of the email message to authenticate the responder;
upon confirming a match between the intended responder email address and the actual sender address of the email message, executing, by the processor, a payment instruction by transmitting the transaction amount and requestor identity to a payment processing system,
wherein the transaction is executed based solely on the receipt and validation of the email message, without requiring the responder to access a web interface, enter login credentials, or perform multi-step authentication,
thereby reducing the latency, complexity, and vulnerability of conventional browser-based payment authorization mechanisms.
Specifically claims 1, 10 and 11 recite the abstract idea of validating a sender of a message based on the message content, and executing a payment transaction when the sender is validated. Therefore the claims recite a fundamental economic principle or practice grouped within the “certain methods of organizing human activity” grouping of abstract ideas in prong one of step 2A of the Alice/Mayo test (See MPEP 2106) because the claims involve a series of steps for validating a sender of a message based on the message content, and executing a payment transaction when the sender is validated. Accordingly, the claims recite an abstract idea (See pages 7, 10, Alice Corporation Pty. Ltd. v. CLS Bank International, et al., US Supreme Court, No. 13-298, June 19, 2014; MPEP 2106).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test, the additional elements of over a communication network, a payment server comprising a processor and memory, a payment processing system, a web interface, merely use one or more computers as tool to perform the abstract idea. The use of a payment server, a payment processing system, a processor and a memory, does not integrate the abstract idea into a practical application because it requires no more than one or more computing devices 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 (MPEP 2106.05(a)), and the claims do not apply or use the abstract idea in some other meaningful way 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 (MPEP 2106.05(e) and Vanda Memo). Therefore, the claims do not, for example, purport to improve the functioning of a computer. Nor do they 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 claims are directed to an abstract idea.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106), the additional elements of a payment server, a payment processing system, a processor and a memory, amount to no more than using computing devices or processors to automate and/or implement the abstract idea.
As discussed above, taking the claim elements separately, these additional elements perform the steps or functions that correspond to the actions required to perform the abstract idea. Viewed as a whole, the combination of elements recited in the claims merely recite the abstract idea.
Dependent claims 2 and 13, recite:
generating the token by the payment server in response to a request from the requestor received through a web-based user interface.
The judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106), the additional elements of a web-based user interface, merely use one or more computers as tool to perform the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106), the additional element amount to no more than using computing devices or processors to automate and/or implement the abstract idea.
Dependent claim 3, recites:
wherein the token comprises a digitally signed, encrypted string that includes a cryptographic hash of the responder's email address and a timestamp,
which further describes the abstract idea.
Dependent claims 4 and 12, recite:
wherein the parsing of the email message comprises identifying the token within a predetermined delimiter or markup tag in the email body that was populated by the mailto hyperlink,
which further describes the abstract idea.
Dependent claim 5, recites:
wherein the processor executes the payment instruction without invoking a login protocol or session management mechanism,
which further describes the abstract idea.
Dependent claims 6 and 15, recite:
storing a transaction log entry including the responder's email address, requestor identifier, transaction amount, and timestamp in a database maintained by the payment server.
The judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106), the additional elements of a database maintained by the payment server, merely use one or more computers as tool to perform the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106), the additional element amount to no more than using computing devices or processors to automate and/or implement the abstract idea.
Dependent claims 7 and 16, recite:
transmitting confirmation messages to both the requestor and the responder upon completion of the financial transaction,
which further describes the abstract idea.
Dependent claim 8, recites:
rejecting the transaction and sending a failure notification to the responder when the token is expired or already used,
which further describes the abstract idea.
Dependent claim 9, recites:
the token includes metadata indicating an expiration time, and the processor determines whether the token remains valid based on a current time value,
which further describes the abstract idea.
Dependent claim 14, recites:
the memory stores a public key and private key pair used to encrypt and decrypt the token,
which further describes the abstract idea.
Dependent claim 17, recites:
the processor is further configured to verify the validity of the token based on an expiration value encoded within the token payload,
which further describes the abstract idea.
Dependent claim 18, recites:
maintain a user profile for the requestor including a public payment page URL used to initiate generation of transaction tokens,
The judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A of the Alice/Mayo test (See MPEP 2106), the additional elements of a public payment page, merely use one or more computers as tool to perform the abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because, when analyzed under step 2B of the Alice/Mayo test (See MPEP 2106), the additional element amount to no more than using computing devices or processors to automate and/or implement the abstract idea.
Dependent claim 19, recites:
the processor is configured to reject the transaction and transmit a rejection message when the email address extracted from the token does not match the sender of the received email,
which further describes the abstract idea.
Dependent claim 20, recites:
the transaction is completed based on a single email response action by the responder without requiring any multi-step challenge- response authentication sequence,
which further describes the abstract idea.
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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-6, 8-12, 14-15, 17, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Malcolm (Australian Patent Publication No. AU2008201232A1), in view of Killoran (US Patent Publication No. 2012/0253897 )
With respect to claims 1, 10 and 11 Malcolm, which like the present Application provides payment related tokens via messages, teach:
receiving, by a payment server comprising a processor and memory, an email message over a communication network, the email message originating from a responder… (a supplier (i.e., payment server) receives an email message from a customer (i.e. responder): Page 5 Lines 22-30, Page 28 Line 24 -Page 29 Line 16, the message includes digital certificate and transaction data (token): Page 29 Lines 17-28)
parsing, by the processor, the email message to extract the token from … the message … (message is analyzed (parsed) to extract the digital certificate and transaction data: Page 29 Lines 17-28, Page 35 Lines 1-25, Page 47 Lines 9-15)
decoding, by the processor, the token to retrieve transaction information including an intended responder email address, a transaction amount and a requestor identity; (data is encrypted before sending and decrypted by recipient: Page 6 Lines 13-20, Page 29 Lines 17-28) digital certificate provides sender identity and specifies payment amount: Page 44 Line 29- Page 45 Line 7, email address is extracted from the message: Page 97 Lines 11-22)
comparing, by the processor, the intended responder email address from the token with an actual sender address of the email message to authenticate the responder; (compare the received data with account entries to determine account validity using text matching techniques: Page 35 Lines 11-18, Page 43 Lines 1-14, Page 65 Lines 5-11, if a match is found between received hash (hash from actual sender) and the hash produced by recipient (intended hash), the recipient can trust the sender (authenticate): Page 45 Lines 8-26)
upon confirming a match between the intended responder email address and the actual sender address of the email message, executing, by the processor, a payment instruction by transmitting the transaction amount and requestor identity to a payment processing system, (if a match is found the transaction is taking place (executed): Page 45 Lines 8-26, Page 73 Lines 18-24, Page 99 Lines 14-19)
wherein the transaction is executed based solely on the receipt and validation of the email message, without requiring the responder to access a web interface, enter login credentials, or perform multi-step authentication, (username and password are stored in a database for further access (without logging in): Page 31 Line 14-Page 32 Line 24, transaction is taking place based on stored identifying data without further checks: Page 38 Lines 16-30, Page 40 Lines 14-21)
thereby reducing the latency, complexity, and vulnerability of conventional browser-based payment authorization mechanisms. (Page 20 Line 29-Page 21 Line 6)
The examiner notes that the claim recitation “thereby reducing the latency….” Indicates intended result of the claimed features and therefore does not further limit the scope of the claim.
Malcolm does not explicitly teach; however, Killoran which like the present Application provides inserting data into email messages using mailto hyperlink, teaches:
…email message generated in response to selection of a mailto hyperlink, (an email message is generated when mailto hyperlink is selected: [0023], [0033])
the email message including a token inserted by the mailto hyperlink into a predefined location within a message body of the email message, wherein the mailto hyperlink is configured to address the email message to an email address associated with the payment server and to include the token in the predefined location within the message body; (mailto indicates destination address: [0034], Claim 1, the email message includes parameters such as Uniform Resource Identifiers (URIs) or hyperlinks (tokens) that are defined according to the mailto URI scheme and entered into message body: [0023], [0033], FIGs. 3, 5, 9, [0037], [0045], [0071])
In addition, Killoran teaches:
…retrieve transaction information including an intended responder email address, a transaction amount and a requestor identity; (hyperlink includes email address, [0034], transaction information: [0038], 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 incorporate the system of Killoran for inserting links including transaction information into the email message using mailto hyperlinks, into the system of Malcolm for verifying a transaction based on a digital certificate received by email, to embed the digital certificate into a mailto hyperlink in the email, in order to automatically obtain parameters associated with the transaction. (Killoran: Abstract, [0004])
The examiner notes that although taught by the prior art, the following claim recitations do not have patentable weight:
The claim recitation: “email message generated in response to selection of a mailto hyperlink…” indicates not-positively recited claim language and therefore does not further limit the scope of the claim because “generating” the email message is not positively recited as a claimed function.
The claim recitation: “the email message including a token inserted by the mailto hyperlink into a predefined location within a message body of the email message,” indicates not-positively recited claim language and therefore does not further limit the scope of the claim because “inserting” the token is not positively recited as a claimed function.
With respect to claim 3, Malcolm and Killoran teach the limitations of claim 1.
Moreover, Malcom teach:
wherein the token comprises a digitally signed, encrypted string that includes a cryptographic hash of the responder's email address and a timestamp, (Page 45 Lines 8-26, Page 88 Lines 4-19, Page 76 Lines 12-23)
With respect to claims 4 and 12, Malcolm and Killoran teach the limitations of claims 1 and 11.
Moreover, Malcom teach:
wherein the parsing of the email message comprises identifying the token within a predetermined delimiter or markup tag in the email body, (data extracted from email content which is in mark-up language: Page 35 Lines 11-18)
Moreover, Killoran teach:
email body that was populated by the mailto hyperlink. ( [0023], [0033]-[0034], FIGs. 3, 5, 9, [0037], [0045], [0071])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the system of Killoran for inserting links including transaction information into the email message using mailto hyperlinks, into the system of Malcolm for verifying a transaction based on a digital certificate received by email, to embed the digital certificate into a mailto hyperlink in the email, in order to automatically obtain parameters associated with the transaction. (Killoran: Abstract, [0004])
With respect to claim 5, Malcolm and Killoran teach the limitations of claim 1.
Moreover, Malcom teach:
wherein the processor executes the payment instruction without invoking a login protocol or session management mechanism, (username and password are stored in a database for further access (without logging in): Page 31 Line 14-Page 32 Line 24, transaction is taking place based on stored identifying data without further checks: Page 38 Lines 16-30, Page 40 Lines 14-21)
With respect to claims 6 and 15, Malcolm and Killoran teach the limitations of claims 1 and 11.
Moreover, Malcom teach:
storing a transaction log entry including the responder's email address, requestor identifier, transaction amount, and timestamp in a database maintained by the payment server. (Page 46 Line 26- Page 47 Line 8)
With respect to claim 8, Malcolm and Killoran teach the limitations of claim 1.
Moreover, Malcom teach:
rejecting the transaction and sending a failure notification to the responder when the token is expired or already used. (transaction rejected: Page 47 Line 26 - Page 48 Line 26, denial notification is sent to the user: Page 42 Lines 4-11.)
With respect to claim 9 , Malcolm and Killoran teach the limitations of claims 1 and 11.
Moreover, Malcom teach:
the token includes metadata indicating an expiration time, and the processor determines whether the token remains valid based on a current time value. (digital certificate contains expiration date: Page 44 Lines 22-28, determine if expiry date of the digital certificate is passed: Page 47 Lines 15-19)
With respect to claim 14, Malcolm and Killoran teach the limitations of claim 11.
Moreover, Malcom teach:
the memory stores a public key and private key pair used to encrypt and decrypt the token, (Page 45 Lines 3-7, keys are stored on a data tree: Page 86 Line 19-Page 87 Line 1, Page 111 Lines 1-10)
With respect to claim 17, Malcolm and Killoran teach the limitations of claim 11.
Moreover, Malcom teach:
verify the validity of the token based on an expiration value encoded within the token payload. (digital certificate contains expiration date: Page 44 Lines 22-28, determine if expiry date of the digital certificate is passed: Page 47 Lines 15-19)
With respect to claim 19, Malcolm and Killoran teach the limitations of claim 11.
Moreover, Malcom teach:
reject the transaction and transmit a rejection message when the email address extracted from the token does not match the sender of the received email. ((if a match is found the transaction is taking place (executed): Page 45 Lines 18-26, Page 73 Lines 18-24, Page 99 Lines 14-19, transaction rejected: Page 47 Line 26 - Page 48 Line 26.)
With respect to claim 20, Malcolm and Killoran teach the limitations of claim 11.
Moreover, Malcom teach:
the transaction is completed based on a single email response action by the responder without requiring any multi-step challenge- response authentication sequence, (username and password are stored in a database for further access (without logging in): Page 31 Line 14-Page 32 Line 24, transaction is taking place based on stored identifying data without further checks: Page 38 Lines 16-30, Page 40 Lines 14-21)
Claims 2, 7, 13, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Malcolm, in view of Killoran, as applied to claims 1, 10 and 11 above, further in view of Labrou (US Patent Publication No. 2005/0027543)
With respect to claims 2 and 13, Malcolm and Killoran teach the limitations of claims 1 and 11.
Malcolm and Killoran do not explicitly teach; however, Labrou, which like the present Application provides executing transactions between a merchant and a customer via a third party payment server, teach:
generating the token by the payment server in response to a request from the requestor received through a web-based user interface. (secure transaction server (STS) generates token in response to a request from Merchant transaction server (MTS) (requestor): [0218]-[0220], STS and MTS communicate via an interface: [0325])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate token generation based on a request from a merchant, as taught by Labrou , into the system of Malcolm and Killoran for verifying a transaction based on an embedded token received via a message, in order to enable the merchant server to manage a secure customer transaction via a secure third party. (Labrou: Abstract, [0006])
With respect to claims 7 and 16, Malcolm and Killoran teach the limitations of claims 1 and 11.
Malcolm and Killoran do not explicitly teach; however, Labrou teach:
transmitting confirmation messages to both the requestor and the responder upon completion of the financial transaction. ([0050], [0214])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate token generation based on a request from a merchant, as taught by Labrou , into the system of Malcolm and Killoran for verifying a transaction based on an embedded token received via a message, in order to enable the merchant server to manage a secure customer transaction via a secure third party. (Labrou: Abstract, [0006])
With respect to claim 18, Malcolm and Killoran teach the limitations of claim 11.
Malcolm and Killoran do not explicitly teach; however, Labrou teach:
maintain a user profile for the requestor including a public payment page URL used to initiate generation of transaction tokens. (merchant’s web-accessible site (public payment page): [0038], [0042], [0053])
The examiner notes that the claim recitation “used to initiate generation of transaction tokens,” indicates intended use of the public payment page and therefore does not further limit the scope of the claim.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate token generation based on a request from a merchant, as taught by Labrou , into the system of Malcolm and Killoran for verifying a transaction based on an embedded token received via a message, in order to enable the merchant server to manage a secure customer transaction via a secure third party. (Labrou: Abstract, [0006])
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Nanda (US 2010/0293385 ) teaches embedding tokens into email message body. Oborne (US 2012/0316992 ) teaches extracting payment tokens from email messages. Dixon (US 2014/0006778) teaches extracting a transaction token and a message originator identifier from the message payload. Bohannon (US 2011/0184793) teaches inserting into a field of email message an email address for the intended recipient, and inserting into the body of the email message HTML code including a URI.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SIMA ASGARI whose telephone number is (571)272-2037. The examiner can normally be reached M-F 9am-6pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Patrick McAtee can be reached at (571)272-7575. 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.
/SIMA ASGARI/Examiner, Art Unit 3698
/PATRICK MCATEE/Supervisory Patent Examiner, Art Unit 3698
Prosecution Insights