DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The following is a Final Office Action in response to communications received March 10, 2026. Claim(s) 6, 12, 18 and 20 have been canceled. Claims 1, 7 and 13 have been amended. New claim(s) 24 has been added. Therefore, claims 1-5, 7-11, 13-17, 19 and 21-24 are pending and addressed below.
Priority
Application 17549305 filed 12/13/2021 and having 1 RCE-type filing therein is a Continuation of 15286148, filed 10/05/2016, now abandoned 15286143 Claims Priority from Provisional Application 62237292 , filed 10/05/2015
Applicant Name/Assignee: SWOOP IP HOLDINGS LLC
Inventor(s): Killoran JR, John; Killoran, Patrick L; Matthews, Wauker
Response to Amendment/Arguments
Claim Rejections - 35 USC § 101
Applicant's arguments filed 04/23/2025 have been fully considered but they are not persuasive.
In the remarks applicant argues that the previous Office Action mischaracterizes the claim limitations as being directed toward a sales activity in the category of methods of organizing human activity. Applicant argues the amended limitations recite a commercial objective implemented on computer components and recite a particular security protocol for SMTP-based authorization that governs whether the commerce system will accept and act upon the message. The protocol requires sender authorization using DKIM or SPF tied to RFC 5322 domain and requires extracting a lookup token form the RFC 5322 header address field and resolving that the lookup token before decoding and validating the token. Applicant points to the specification ¶ 0085, 0135, 0147-0149, arguing the limitations define a standards tethered message processing pipeline that constrains how data authorization is carried in an email and how it is retrieved for processing. The system permits proceeding to decoding, validation and execution (spec ¶ 135, 0147-0149) .
[0085] DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing
aspects in that it operates on the RFC 5322 message -- the transported mail's header
and body -- not the SMTP envelope defined in RFC 5321. Hence, the DKIM signature
survives basic relaying across multiple MTAs. DKIM allows the signer to distinguish
its legitimate mail stream. This ability to distinguish legitimate mail from potentially
forged mail has benefits for recipients of e-mail as well as senders, and "DKIM
awareness" is programmed into some e-mail software.
Wherein the specification discloses applying existing technology to mitigate risk.
[00135] The short token lookup is not necessarily required in this system, as the
transactions may be processed with the long token either in the address field, another
field, or in the body of the response email. The use of the short lookup token may
lessen the one-to-one correlation between the token and the actual offer and/or
transaction details, as that correlation may be more direct in the long token
embodiment.
Wherein the specification discloses applying existing technology to for use in a transaction process.
[0014 7] Returning to Figure 9A, the communication unit 167 registers the
customer 150 as a full-customer 150a and shares the information with the parameter
unit 171 at step 920. The parameter unit 171 is updated and the parameters set at
step 925. The information is shared with the communication unit 167 at step 930.
This shared information may include a payment request. The communication unit
167 shares the payment request at step 940 with the payment processor 160. The
payment processor 160 charges the full-customer's credit card or bank account at
step 945. The funds are transferred at step 950 to the banking unit 172 of the ecommerce
system 140 and held in the sub-customer's 150a account at step 955. The
banking unit 172 updates the parameter unit 171 sharing the information at step
960. The parameter unit 171 updates at step 965 and shares the information with the
communication unit 167 at step 970. The communication unit 167 may generate a
gift card message at step 975 and share that notification with the sub-customer 150b
informing the sub-customer 150b of the gift and notifying the full-customer 150a that
the message has been sent at steps 980 and 990.
Wherein the specification discloses applying existing technology for communication for performing a transaction process.
[00148] Figure l0Ais a transactional flow diagram 1000 that illustrates how the
e-commerce system 140 manages bank accounts or redemption accounts based on
deposits made from one customer account 150a to another 150b by messaging. In flow
1000, the parameter unit 171 is triggered at step 1005 based on a set of criteria and
shares information at step 1010 with the communication unit 167. This trigger may
be the result of multiple factors such as an account running low on funds or a timed
alert, for example.
Wherein the specification discloses applying existing technology to manage bank accounts criteria.
[00149] The full-customer 150a is already registered in this discussion, as
opposed to the discussion of Figure 9, with the e-commerce system 140 and therefore
does not need to visit a webpage and fill out information. In the case where
registration may be required, registration may also occur by a method described in
Figure 7B.
Wherein the specification discloses applying existing technology for use in a commercial activity.
The process of CosmoKey addresses a specific problem rooted in technology (e.g. vulnerability of license-authorization software to hacking) with a specific technical process that departs from previous approaches in solving the technical problem. The process of CosmoKey addresses a specific problem rooted in technology (e.g. vulnerability of license-authorization software to hacking) with a specific technical process that departs from previous approaches in solving the technical problem. Applicant argues the amendments address the lack of technical disclosure found in the previous Office action analysis by providing technical implementation of the “mailto link” or “token”. The newly recited RFC 5322 header address field short token extraction and token store resolution provide technical implementation details that anchor the claims in a concrete computer network security technique rather than an abstract idea. Applicant submits that in light of Federal Circuit guidance the claim limitations are not directed toward an abstract idea under step 2A prong 1. Applicant’s argument is not persuasive. The specification para 0157, makes clear that the focus of the invention of to perform risk mitigation and transaction flow of how a full customer may set parameters for a sub- customer to access their account and make payments allowing one customer to provide payment for another customer, applicable within the business of gift cards delivered and spend gift card. The full customer may provide an email of sub-customer where the full customer access their account and sets parameters for the sub-customer limiting the amount to be spent within a time period. The claim limitations when considered as a whole in light of the specification is directed toward transmitting stored funds, receiving request to transmit stored fund, authenticating sender, decoding token, validating gift parameters and transmitting stored if parameters validated. The amended limitation “extracting, by the processor, a short lookup token from an RFC 5322 e-mail header address field of the response message: and resolving, by the processor, the short lookup token to the token retrieved from a token store and on a condition that the e-mail address of the sender is authenticated” merely adds an authentication element for risk mitigation and to the controlled transaction process and does not change that as a whole the claimed subject matter is directed toward an authentication and validation process for risk mitigation in performing a transaction that debits accounts. The rejection is maintained.
In the remarks applicant argues that the claim limitations recite a specific improvement that integrate any alleged abstract idea into a practical application. Applicant points to CosmoKey Sols. GmbH & Co KG v Duo Sec LLC which the court found improvement in technology in an authentication process. Applicant provides no explanation as to the relevance of CosmoKey as it pertains to the current application. The process of CosmoKey addresses a specific problem rooted in technology (e.g. vulnerability of license-authorization software to hacking) with a specific technical process that departs from previous approaches in solving the technical problem. Applicant’s argument does not identify what technology is improved upon or how the extraction of a token from a header improves technology or if the claims are analogous to CosmoKey what technical problem is being solved by applying mailto protocol, STMP protocol or SPF protocol that goes beyond the ordinary application of existing technology to authenticate email senders. The rejection is maintained.
In the remarks applicant argues that the determined “sales activity” abstract concept of the previous Office Action does not reflect the amended claimed subject matter. The amended claims require protocol constrained SMTP authorization mechanism that is rooted in specific email authentication using DKIM and/or SPF which request authenticated domains and RFC 5322 from domain, extracting a token from an RFC 5322 email header address. This resolves the lookup token via a token store before decoding/validation. The specification ties DKIM and RFC 5322 message structure placing token identifiers in header address fields such as “to” field and performing lookup to retrieve token used including embedding the lookup token in the fields, authenticating, resolving the associated long token and decoding/processing is patent eligible. Applicant’s argument is not persuasive, the extracting steps is high level lacking technical details and therefore, can be performed using any data extraction means. Furthermore, applicant has not explained how extracting data content (token) that is for use in a transaction improves upon computer technology or solves a problem rooted in technology. As discussed in the previous Office action DKIM or SPF authentication is existing technology for use in authentication to mitigate risk. The claimed limitations do not improve DKIM/SPF protocol technology. The rejection is maintained.
In the remarks applicant points to CosmoKey, arguing the ordered authentication techniques improves security and therefore is patent eligible. Applicant argues the amended limitations do not claim authorization in the abstract by claim a particular protocol gated authorization path dependent on authenticated SMTP provenance and RFC 5322 header address field token with token store resolution. Applicant is repeating arguments above, see response above. The rejection is maintained.
In the remarks applicant argues that as a whole the claimed subject matter is not directed toward a sales activity as determined in the previous office action. The amended claim is not a generalized transfer concept but rather recites a particular computer implemented message authorization protocol that determines whether the system will honor an incoming authorization request transmitted over SMTP. The claim is anchored in protocol gated execution and not a financial objection and does not simply transfer funds. Claim claimed requires the authorization message to arrive as an SMTP message generated by activation of mailto link and requires a sequence of steps that are meaningful in authenticating the sender using DKIM/SPF requiring a specified relationship between authenticated domain and the RFC 5322 “from” domain, extracting the lookup token from the RFC 5322 email header address field and resolving the short lookup token via a token store before decoding. The limitations are not incidental data gathering or post solution activity. Applicant’s argument is not persuasive. DKIM and SPF are known email authentication mechanism designed for email security. SPF is a protocol is a way for a domain to list all servers they send emails from validating the message source, whereas DKIM verifies message content has not been tampered with since sent. The claim limitations merely apply these existing technologies for use in authenticating to mitigate risk in receiving a transaction message. With respect to RFC 5322 is merely a format standard that defines the syntax and structure of text based email messages established in 2008. The RFC 5322 specifies that a message consist of a header section (field name, field body-To, From, Cc, Bcc-sender recipient address, date; subject and body) which are standards in email configuration. The specification discloses that the token located in the “to”, “Cc”, “Bcc” fields of the email can be sent as a mailto link (url). This is not an improvement in technology but merely applying technology for authentication to mitigate risk and applying a format standard in the transmission via a link a token in the email response header as a link that is extracted and applied for payment processing. The application of known technology to authenticate the sender of a transaction token embedded in a URL/emailto link is not improvement but simply using known communication protocol to mitigate risk for a transaction. Accordingly, the inclusion of the SMTP/SPF protocol, RFC 5322 formatting and a transaction token in the mailto link/url in the email address field is merely providing information and authentication of information to mitigate risk and for use in a transaction process. Applicant’s argument is not persuasive.
[00132] A token may be located within the To: Cc: or Bee fields of a response
email. This token may take the form of a short token, for example. The e-commerce
system 140 may generate the short token that is located in the To: field, or any other
field, for example, as part of the email address. When the vendor system 130 requests
that the token generator 141 generate a mailto link with the identifiers and token,
the token generator 141 may generate a "short lookup token" and the "long token"
encoded with the identifiers. The short lookup token may be associated with the long
token and may be required or otherwise needed to access the information in the long
token index. The short token index may be sent in an email to the customer device
150 as a mailto link. The customer using the customer device 150 selects the mailto
link and generates the response email addressed to the e-commerce system 140. The
short lookup token may be built into the address of the response email. The short lookup token may be of the form:
In the remarks applicant argues the amended limitation provide technical implementation of the mailto link or token claimed by providing specific token handling architecture where the system extracts the short lookup token from the RFC 5322 header address field and performs token store resolution to retrieve the operative token before decoding for use in the transaction. Applicant argues that by locating the token in the header address field in a short lookup token form, how the token is obtained for decoding (extracting) resolution via a token store, the limitations and specification underscore the particular email message format and token indirection technique designed for secure processing and not a business abstraction. The examiner respectfully disagrees with the premise of applicant’s argument. As discussed above, the claim limitations merely apply a known authentication protocol (SMTP/SPF) in its ordinary capacity to mitigate risk and to transmit token data for use in a transaction that is then applied in the claimed transaction. The format applied RFC 5322 specifies that a message consist of a header section (field name, field body-To, From, Cc, Bcc-sender recipient address, date; subject and body) which are standards in email configuration and not directed toward improving email formats. Instead it is merely applied to perform email transmission to a designated address. The Mailto link/url containing the token is merely applying standard technology at a high level in order to transmit token. The specification and claim limitations makes clear that the token is merely a tool that provides conditions and parameters to apply in processing a payment. Url/mailto link payment tokens where the tokens once transmitted are extracted and decoded in order to retrieve information for processing payments, are not a an inventive concept of the applicant as such use of technology has been prevalent since early 2000’s. The details related to the tokens transmitted in the mailto link and then extracted are still high level with expected results. The limitations merely set forth that the tokens are in the mailto link and then extracted without any details as to how the tokens are embedded in the link or how the tokens are extracted beyond what is already being implemented in the industry for use in transactions. The rejection is maintained.
In the remarks applicant argues that the when considered in light of the ARP’s guidance Desjardins decision, the recitations of SMTP/DKIM -SPF/RFC 5322/token-store mechanics governing authorization based on the ordered combination recited the claim is directed toward security protocol for authentication and safety SMTP authorization messages not an abstract idea. Accordingly the amended claims under step 2A prong 2 and 2B are patent eligible. The examiner respectfully disagrees. As discussed above, the inclusion of SMTP (mail server that sends/relays outgoing emails) the email authentication protocol (DKIM -SPF) to mitigate risk and applies standard format (RFC 5322) which includes email address fields for which the mailto link/URL is set forth containing the payment token for extraction and use in retrieving conditions/criteria for payment processing that is executed, merely limits the transaction process within a particular technical environment. The use of SMTP, DKIM-SPF, RFC 5322 and mailto links with tokens does not provide any indications of patent eligibility under 2A prong 2 or provide unconventional technical processes or provide significantly more than applying existing technology to perform the abstract idea of risk mitigation and a sales activity. The rejection is maintained.
In the remarks applicant argues that under step 2A prong 2, improves security in SMTP driven authorization where the SMTP, DKIM and SPF operate together to implement a specific security control plane for SMTP authorization. Applicant argues the authentication requirements is more than an ancillary check appended to an abstract transaction, as it is the gate that determine whether the system will treat the message as trusted authorization instruction. The claim’s authentication gating is a computer technique to prevent spoofed or forged authorization. The limitations therefore, integrate the claimed workflow into a practical application requiring specific message format and token retrieval architecture not generic token decoding. Applicant argues the extraction of the token from the RFC 5322 email header address field and the resolving the token to the operative token retrieved from the token store before decoding. Applicant argues the association of the short lookup token and long token as claimed including the embedding the short token in the To/Cc/Bcc address fields, receiving and authenticating emails using the short token to determine the long token and decoding the long token to complete the transaction are real-world email message handling rather that an abstract commercial objective. The examiner respectfully disagrees. The claim limitations do not use the short token to authenticate emails, instead the claims recite known authentication protocol to perform the authentication to mitigate risk. The token is merely embedded in the mailto link, where the mailto link provides the URL address and has token data embedded in the link, which as discussed above is merely applying known technology for use in a transaction process. With respect to the short token associated with the long token, the specification discloses the purpose of using the short token is to allow for less convoluted field in the email address. This is a common application/use of short token. As evidence the examiner provides US Pub No. 2003/0100320 A1 by Ranjan – para 0065 “embedded links within web pages or other units of information from a server computer to a remote display device. … allows potentially lengthy embedded links to be represented by very short tokens in order to decrease the amount of information transferred from a server computer to a remote display device at the cost of maintaining link-token/unit-of-information address associations in the server computer and the cost of processing selected link tokens transmitted to the server computer from remote electronic display devices into URLs or other address-like specifiers of units of information corresponding to link tokens.”; WO 2016057092 A1 by Scoda – para 0008 “communicate a reference to the content using a relatively short token. The token includes a special character and is introduced … as a hyperlink. Upon selection of the hyperlink, the content is retrieved based on the token and included special character, … [0009] Accordingly, using the tokens, the size of the communicated reference(s) can be reduced, particularly when multiple URLs would otherwise have been required to communicate references to content associated with multiple items responsive to a search request.”; US Patent No. 9,135,412 B1 by Talvensnari et al- Abstract “ short token that enables the first computing device to access the resource. … the short token may be used to receive a long token that can be used to send application programming interface (API) requests…”, col 1 lines 32-58 “the remote server may generate a short token (e.g., a six to eight character alphanumeric code) upon configuration of the one or more asset(s), … the local server may use the short token to initiate a connection to the remote server…. The remote server may verify the short token and may provide a long token to the local server. For example, the long token may be a 32 or 64 character token that provides improved security as compared to the short token.”. The rejection is maintained.
In the remarks applicant argues the claim limitation require authorization request as a message via SMTP where the sender authentication is via DKIM/SPF protocol with a relationship between authenticated domains and RFC 5322 format “from” domain. Applicant argues this is a gate that determines whether the system will treat the message as authorized. The present application explains DKIM verification in context of RFC 5322 message structure (e.g. standard email data fields) including the relationship between DKIM signatures and message header/body integrity pointing to para 0085, para 0103-0105 of the specification to prevent spoofing/forged authorizations. The amendments further integrate the claimed workflow into a practical application by requiring specific message format and token retrieval architecture not just generic token decoding. The extraction of the short lookup token from the email header address field and resolving the short token to the operative token retrieved from the token store before decoding is specific at a concrete protocol level constraint the defines how the authorization material is transported and processed in email environment. The short lookup token and “long token association embedded in the To/Cc/Bcc address fields are applied to complete the process pointing to para 0135, para 0147-0149 of the current specification. These processes tether the claimed subject matter to real-world email message handling and lookup behavior rather than commercial processes in a particular environment. The header address field short token indirection is not using DKIM/SPF in its ordinary capacity. Instead the short lookup token appearing in the RFC 5322 header and token-store resolution constrains token exposure forcing authorization to occur rather than consuming sensitive token material from unstructured email content. Applicant’s argument is not persuasive. The application of email transmission using SMTP (standard communication protocol used for mail transmission) for transmitting a generated mailto link that contains the token is not impacted because the email contained a mailto link with an embedded token. Generating email offers using Mailto email headers, is a protocol widely used in HTML whose syntax allows embedding of tokens directly into the URL to set the “To, Cc, and Bcc” fields. This is not an inventive concept of the applicant, as evidence see US Pub No. 2015/0332365 A1 by Kassemi et al-para 0153, US Pub No. 2012/0324113 A1 by Prince et al – para 0237; US Pub No. 2012/0117239 A1 by Holloway et al- para 0198. With respect to the argument that protocol DKIM/SPF as claimed is not being applied in its ordinary capacity, the examiner disagrees. The claim limitations makes clear that the application of the DKIM/SPF is to authentication the email received, such application of DKIM/SPF is well established in the industry. As discussed above, the argued protocol SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are two email authentication mechanisms designed to prevent email spoofing and ensure the legitimacy of email senders. With respect to the short lookup token associated with a long token that is extracted, extraction of tokens from email header addresses is also established technology. Applying an id token/authentication (short lookup token) that is transmitted associated with a payment token is not an inventive concept of the applicant. (see AU 2015203621 A1 by Light et al -para 0059-0063; US Patent No. 9,916,579 Watson et al- “a token lookup request based on the transaction data, the secured transaction data comprising a payment card token in place of at least a portion of the payment card data, the token lookup request comprising the merchant identifier and the consumer identifier; transmit, by a processer to a payment gateway server, the secured transaction data and the payment processing token lookup request”, such correlations between short lookup tokens and long tokens is not an inventive concept of the applicant. – see US Pub No. 2015/0295901 A1 by Woodward et al- para 0044; US Patent No. 9,135,412 B1 by Talvensaari et al- “he short token may be provided to the second computing device to access the resource and to receive a long token generated by the second computing device”; CN 100591037 C by Nanda et al –“short token message wherein said token message is a compact version of the sequence table or a long token message comprises a full version of the sequence table”. The short and long token operations are not part of the DKIM or SPF protocol process, instead a separate operation and therefore, does not improve tokenization or the capability of DKIM or SPF protocol. With respect to the embedding of the token into the mailto link, this process is not part of the DKIM or SPF protocol or the email formatting of data fields using standard RFC 5322 format “from” domain. Accordingly the application is merely applying established technology to transmit embedded data in a mailto link. The claim limitations do not improve upon DKIM/SPF technology, tokenization, the technical field of tokens, mailto links or RFC 5322 formatting standard. Instead the limitations merely apply established technology to mitigate fraud and to perform a transaction. The rejection is maintained.
In the remarks applicant argues the claim 24 reinforces the practical application discussed above by requiring the short lookup token in the header address field as part of the email address pointing to the specification para 0149. The short lookup token eliminates the need for the token to be located in the body and is not mere presentation choice, but a concrete constraint on message structure tied to security objective of reducing token exposure in message content and implemented in RFC 5322 address field handling and token store resolution. Applicant’s argument is not persuasive. Email address fields that provide URL address/IP address information used for email message transmissions is not a practical application as the address in the email address field of standard RFC 5322 email format is not an improvement in email transmissions. Furthermore, mailto/email url address which embedded data including tokens are not an inventive concept of the application as such use of technology is established in the industry. (see US Pub No. 2015/032365 A1 by Kassemi et al; para 0135, GB 2505322 A by Shaw- “Application may embed the token in a content request URL 708 sent to a Content Server”; US Pub No. 2013/0125228 A1 by Do et al – para 0047-0049; US Pub No. 2015/0106955 A1 by Soelberg et al- para 0029; US Pub No. 2014/0317517 A1 by Aoki – para 0033, para 0035. The rejection is maintained.
In the remarks applicant points to the CosmoKey decision, repeating argument addressed above in light of step 2A prong 2 for analysis. See response above, the rejection is maintained.
In the remarks applicant argues that under step 2B, the claimed subject matter is patent eligible. The requirement of 2B is not whether the building blocks was previously known in isolation, but instead whether the ordered combination is unconventional. Applicant argues the combination of limitations with the amended incorporation of data extraction provide a specific implementation constraint protocol level arrangement that the previous Office action fails to analyze as a whole. The examine respectfully disagrees. The previous Office action found that the combination of utilizing SMTP for transferring email messages, in combination with the established technology of generating at a short token and mailto link that contains the generated token is well established technology. The specification and limitations do not provide any technical details as to how the token is generated or how the mailto link generated contains the generated token, instead the operations can be performed by any known means are high level with expected outcomes. The combination of limitations of transmitting the message using SMTP to transfer the email message that includes a mailto link in the email address header field that is authenticated using DKIM/SPF authentication protocol to prevent fraud is well established in email transmission technology and does not provide significantly more than a field of use for transmitting email technology. The combination of limitations where the generated token is extracted from the email header address where the email data fields are formatted in standard format (RFC 5322) lacks any details of how the token in extracted as a technical process and therefore, the extraction of the token is well-understood in the art. The combination of applying the extracted token to retrieve a token from a token store that is then decoded for use in a transaction where the content of the token are validated and the conditions of the token content for performing a transaction are compared and validated where based on the validated conditions a payment is executed focusing on the use of the technology in performing the validation conditions of the decoded token for use in executing a transaction. As a whole the combination of steps merely confine the mitigation of risk into a particular field of use with well-established technology being applied in its ordinary compacity and then performing a transaction according to transaction parameter from a stored token that is decoded in order to analyze parameters of the token for performing a payment. Accordingly the technology and combination of operations of the technology does not provide significantly more than applying established technology to mitigate risk and to perform a commercial activity. The rejection is maintained.
In the remarks applicant argues that the placing of token identifiers in email header address fields (To field) where the token identifier is associated with a long token and is applied to retrieve the long token that is decoded and used for safely carrying out and resolving authorization material in SMTP messages is not conventional. Applicant argues the well-established protocol DKIM/SPF does not establish that the claimed ordered combination is routine, as the use of DKIM/SPF gated processing together with RFC 5322 header address field short token extraction and token store resolution as mechanisms for retrieving operative token prior to decoding is not conventional. Applicant’s argument is not persuasive. The combination of the transmission of the email message via SMTP and the application of risk mitigation protocol (DKIM/SPF) to prevent fraud is a conventional use of technology. The embedding of a token within a mailto link is not part of the DKIM/SPF protocol or impacts the operations of email transmissions using SMTP. With respect to the embedding of tokens within mailto/url links that are inputted into the standard email format RFC 5322 header address field, such embedding of tokens within email addresses is known in the art where the embedded tokens when received at the email destination are extracted in order to retrieve associated tokens from a database is also well established in the art as evidenced above in the response. Such retrieved tokens once retrieved being decoded and the content analyzed to determine the limitations applied for a transaction is also well established application of technology. Applicant in the argument admits that the use of SMTP for email transmission, use of DKIM/SPF protocol and lookup token generation that is transmitted and then extracted to retrieve a long token is “ used for safely carrying out and resolving authorization material in SMTP messages” and not directed toward the technology itself. The rejection is maintained.
In the remarks applicant points to the CosmoKey decision, repeating argument addressed above in light of step 2B for analysis. See response above, the rejection is maintained.
In the remarks applicant argues that the claim requires a particular interplay between authentication and token retrieval/decoding that changes the system behavior as the system does not accept the raw token placed in a message body but requires the token to be embedded in a mailto link in the email address header for extraction used to retrieve the operative token from the token stored that is decoded and content analyzed for use in executing a payment which addresses message handling and spoofing exposures arising in SMTP authorization. Applicant’s argument is not persuasive. Applicant has not explained how the system behavior is changed when applying SMTP to transmit email messages and applying DKIM/SPF protocol in its ordinary capacity for preventing fraud. The extraction of the lookup token used to retrieve a stored and then decoded associated long token is not part of the spoofing prevention process of DKIM/SPF protocol but instead a separate process for constraining the transaction itself, by restricting the transaction a time window spend limit and applying a vendor identifier when the vender identifier is in a whitelist specified by the full customer and if transaction restrictions are met executing the payment. The rejection is maintained.
In the remarks applicant argues that under step 2B, the limitations recite concrete standards tethered to massage format requirements (RFC 5322 header address field), indirection architecture (lookup token) and a specific retrieval mechanism (token-store resolution) that constrains how authorization data is handled prior to decoding and validation satisfying 2B requirements. The examine respectfully disagrees. The claimed lookup token is not an architecture, rather it is coded data that has been embedded within a mailto link. The mailto link is inserted within the standard email address field providing the designation address for the email message. The embedded token is associated with a token stored that is used to retrieve the stored token. The lookup token has no other function beyond being applied to retrieve the stored token. The retrieved token is decoded and then the content which contains parameters to control the transaction is analyzed and applied to determine conditions for executing the payment which is then executed. As discussed above, these operations are well established and conventional and do not provide significantly more than applying technology to implement the abstract idea. The rejection is maintained.
In the remarks applicant argues pointing to Ex parte Desjardins decision, which the when applied to the current application in light of the specification provides technical details of improvement to technology. Applicant argues that the claim limitations when considered as a whole requires a computer system and therefore satisfies step 2A requirements. The requirement of STMP message generated by activation of mailto link and authenticating using DKIM/SPF protocol where the email requires standard RFC 5322 formatting header address field “from”, the extracting a lookup token from the header and resolving the lookup token via a token store by retrieving associated token that is decoded and validated are limiting requirements that define when the system is permitted to proceed and how the system must obtain the authorization token. The amended limitations provide the RFC 5322 header address field extraction of the lookup token and token resolution process, reciting specific protocol constrained security technique, thereby providing technical constraints to the “sales activity” label. Applicant’s argument is not persuasive and has been addressed above. With respect to Desjardins, the specification merely recites applying established fraud prevention protocol (DKIM/SPF) determine who sent the message and authorize the message for transmission and does not recite any processes or intention to improve upon DKIM/SPF protocol. The specification further explains that the purpose of the generating the token is for use in a transaction process where the short token is associated with a long token which contains the constrains to apply for a transaction payment. The specification does not disclose any process for improving upon the generation of tokens, or generation of mailto links or embedding of tokens within mailto links, the transmission of email messages or the extraction of tokens, or decoding of tokens or any other underlying technology. Rather the specification describes how such established technology can be applied to prevent fraud and to perform a transaction. Desjardins is not applicable. The rejection is maintained.
Applicant argues that based on arguments above, claims 1-5, 7-11, 13-17 and 19-24 is patent eligible under 101. The examiner respectfully disagrees. See response above. The rejection is maintained.
Claim Rejections - 35 USC § 103
Applicant’s arguments with respect to claim(s) 1-5, 7-11, 13-17 and 19-24 have been considered but are moot because the new ground of rejection with a new reference has been applied in the current Office action.
In the remarks applicant argues the prior art references fail to teach RFC 5322 header token extraction and token store resolution in the submitted amendments. Applicant’s argument is moot as a new reference has been applied in light of the submitted amendment. See rejection below.
Applicant's arguments filed 04/23/2025 have been fully considered but they are not persuasive.
In the remarks applicant argues the prior art references fail to teach “domain alignment”. The examiner respectfully disagrees. The prior art Kassemi explicitly teaches applying alignment between DKIM signing domain or SPF authenticated domain in the from domain of the message. The prior art explicitly teaches limitation alignment [DKIM signature check and SPF records] between a DKIM-signing domain or an SPF authenticated domain and From domain of the response message ((Kassemi) in at least Abstract wherein the prior art teaches “performing an SPF and DKIM validation of the received SMTP email”; Col 2 lines 52-64 wherein the prior art teaches “The e-commerce system may further perform a Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) validation and process the transaction, on a condition that the SPF and DKIM validation are approved”, Col 8 lines 7-13 wherein the prior art teaches “The DomainKeys Identified Mail (DKIM)/Sender Policy Framework (SPF) check module 147 serves to authenticate received emails, using DKIM and/or SPF protocols. For example, SPF allows a domain owner to add a file or record on the server that the recipient server cross-checks.”, Col 11 lines 20-30 wherein the prior art teaches “performs an SPF/DKIM check on the email, to check for valid DKIM signatures and SPF records (step 708). These are used to detect whether incoming messages have been mimicked…. system may determine a confirmation is needed when the DKIM is Undefined and the SPF is either Pass or Undefined (step 711). In this scenario, the e-commerce”. The rejection is maintained.
In the remarks applicant argues the prior art references fail to teach “intra-system transfer without contacting an external payment network” limitation. The examiner respectfully disagrees. The prior art Kassemi explicitly teaches a system where the benefits are issued by an external system and transmitted by bulk to the full customer who sends offers to the sub-customer which is then redeemed by the sub-customer from the full customer. The external system which issues the bulk offers is not contacted for payment. Instead the full customer provides the value.
In the remarks applicant argues reason to combine the prior art references do not provide a reasoned rationale to combine in the simple substitution obviousness rationale. The examiner respectfully disagrees. Applicant has not explained how substituting one transaction offer for another is not an obvious substitution when the offers of Leining and Kassemi and their use of offers where known in the art. Simply stating that obviousness through substitution is not a reasoned rationale is not sufficient. The rejection is maintained.
In the remarks applicant points to claim(s) 4, 10, 16, 19 and 21-23 arguing the rejection is improper because the rejection of the independent claim is invalid. The examine respectfully disagrees. See response above. The rejection is maintained.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim(s) 1-5, 7-11, 13-17, 19 and 21-24 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
In reference to claims 1-5, 7-11, 13-17, 19 and 21-24:
Independent claims 1, 7 and 13 recites the limitation “extracting, by the processor, a short lookup token from an RFC 5322 e-mail header address field of the response message: … “ which is new matter. The original presentation of the written description has position of applying RFC 5322 standard email field formats which inherently defines message format including line length limits, a header address fields – (To, From, Subject, date, and message ID fields) and message body (actual content of message recipient sees), syntax rules, envelope -containing routing information including sender and recipient addresses, attachments. However, there is no possession of an extracting step.
[00132] A token may be located within the To: Cc: or Bee fields of a response
email. This token may take the form of a short token, for example. The e-commerce
system 140 may generate the short token that is located in the To: field, or any other
field, for example, as part of the email address. When the vendor system 130 requests
that the token generator 141 generate a mailto link with the identifiers and token,
the token generator 141 may generate a "short lookup token" and the "long token"
encoded with the identifiers. The short lookup token may be associated with the long
token and may be required or otherwise needed to access the information in the long
token index. The short token index may be sent in an email to the customer device
150 as a mailto link. The customer using the customer device 150 selects the mailto
link and generates the response email addressed to the e-commerce system 140. The
short lookup token may be built into the address of the response email. The short
lookup token may be of the form:
[00133] payment-id-7 4E4DE00-51E2-457B-8COB-
648640EF232D@payments.atpay.com, for example.
[00134] When the customer using customer device 150 sends the email and the
e-commerce system 140 receives the email and authenticates the customer's email
address, the e-commerce system 140 may also determine using the short lookup token
included in email address of the e-commerce system 140 the long token associated
therewith. When the long token is determined, the e-commerce system 140 decodes
the long token and processes the payment. The use of the short token allows for a less
convoluted field in the email address and eliminates the need for the token to be
located in the body field.
[00135] The short token lookup is not necessarily required in this system, as the
transactions may be processed with the long token either in the address field, another
field, or in the body of the response email. The use of the short lookup token may
lessen the one-to-one correlation between the token and the actual offer and/or
transaction details, as that correlation may be more direct in the long token
embodiment.
[00139]… Opening the web
browser 155 triggers a request from communication unit 167 for a mailto link and
token at step 610. The request may be a series of requests or require the e-commerce
system 140 to tally an amount due of the customer. E-commerce system 140 may also
require a lookup of other required information. The communication unit 167 shares
the request with the URL translator 182 at step 620. The URL translator 182
translates the URL link at step 625 and shares the corresponding link and token with
the communication unit 167 at step 630. This token may be a short token that
corresponds to a longer token. The communication unit 167 shares the link and token
with the browser 155 at step 640, triggering the messaging unit 159 at step 650 to
generate the response message with the token at step 655. The opening of the browser
155 may not be visible to the customer on customer device 150. The response message
is addressed and sent to the e-commerce system 140 communication unit 167 with
the token at step 660. The token may be located anywhere in any field of the message .
. The communication unit 167 authenticates the message at step 670 and shares the
token with the token manager 165 to decode the token at step 675. If the token is a
short token, it may need to be matched with a corresponding long token. The long
token may require additional decoding (not shown). If either the authentication or
the token decoding does not meet requirements, the customer via customer device
150 may receive a response message requesting an additional confirmation or a URL
link that navigates the customer device 150 to a signup URL and/or checkout….
However, there is no possession of an “extracting…token…” process as claimed, therefore, Independent claims 1, 7 and 13 contain new matter. Dependent claims 2-5, 6-11, 14-17, 19 and 21-24 based on dependency are also directed toward new matter and rejected under 112(a).
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-5, 7-11, 13-17 and 19-23 are rejected under 35 U.S.C. § 101 because the instant application is directed to non-patentable subject matter. Specifically, the claims are directed toward at least one judicial exception without reciting additional elements that amount to significantly more than the judicial exception. The rationale for this determination is in accordance with the guidelines of USPTO, applies to all statutory categories, and is explained in detail below.
In reference to Claims 1-5 and 19-23:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a method, as in independent Claim 1 and the dependent claims. Such methods fall under the statutory category of "process." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The claimed invention is directed to an abstract idea without significantly more. Method claim 1 recites a method steps to 1) granting a sub-customer restricted access to an account 2) generating a token including parameters related to transaction data 3) generating mailto link generating messages 4) transmitting offer 5) receiving message 6) authenticating address of sender 7) requiring domain alignment between DKIM signing domain or SPF authenticated domain and from domain of response message (8) extracting lookup token from email address field and resolving token to retrieve the token from token store (9) decoding token if authenticated (10) validating parameters of gift (11) extracting transaction amount (12) comparing amount to remaining balance of time window spend limit of allowance established by full customer (13) determining vendor identifier in whitelist (14) performing a transaction (15) executing transfer that debit full customer account and credits sub-customer account.
The specification para 0157, makes clear that the focus of the invention of to perform a transaction flow of how a full customer may set parameters for a sub-customer to access their account and make payments allowing one customer to provide payment for another customer, applicable within the business of gift cards delivered and spend gift card. The full customer may provide an email of sub-customer where the full customer access their account and sets parameters for the sub-customer limiting the amount to be spent within a time period.
When considered as a whole the claimed subject matter in light of the specification is directed toward transmitting stored funds, receiving request to transmit stored fund, authenticating sender, extracting and resolving short token, decoding token, validating gift parameters and transmitting stored if parameters validated. Such concepts can be found in the abstract category of sales activity. These concepts are enumerated in Section I of the 2019 revised patent subject matter eligibility guidance published in the federal register (84 FR 50) on January 7, 2019) is directed toward abstract category of methods of organizing human activity.
STEP 2A Prong 2: The identified judicial exception is not integrated into a practical application because the claims fail to provide indications of patent eligible subject matter that integrate the alleged abstract idea into a practical application. The additional elements recited in the claim beyond the abstract idea include “a processor”, “processor of the e-commerce system”, “SMTP”, “DomainKeys Identified Mail (DKIM) or Sender Policy Framework(SPF) protocols” and “e-commerce system”
The claimed “processor of the e-commerce system” performing the operations of “transmitting… a message”; the claimed “processor” performing the operations “receiving …the response message”, “extracting …lookup token” and “extracting an amount …”; The additional element “SMTP” is applied for sending email and relaying email messages between servers from email clients to mail servers; which According to MPEP 2106.05(d) II (see also MPEP 2106.05(g)) the courts have recognized the following computer functions are claimed in a merely generic manner (e.g., at a high level of generality) where technology is merely applied to perform the abstract idea or as insignificant extra-solution activity.
Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014)
Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93
Electronically scanning or extracting data from a physical document, Content Extraction and Transmission, LLC v. Wells Fargo Bank, 776 F.3d 1343, 1348, 113 USPQ2d 1354, 1358 (Fed. Cir. 2014) (optical character recognition)
The claim limitations (transmitting, receiving, extracting, sending email and relaying email messages) are recited at a high level of generality without details of technical implementation and thus are insignificant extra solution activity.
The additional element “processor” is applied to perform the operations of “granting…a sub-customer restricted access to an account…”, “generating a token…unique to the sub-customer for a transaction”, “generating…a mailto link…that contains the token” “authenticating …an email address of a sender…”, “decoding…the token…”, “validating…parameters…”, “extracting an amount of the transaction…”, “comparing the amount to a remaining balance…”, “determining …identifier is in whitelist…”, “performing the transaction”, “executing …transfer that debits an external account …and credits an internal account…maintained by e-commerce system” which are steps/operations for performing a transaction process flow .
The additional element “DomainKeys Identified Mail (DKIM) or Sender Framework (SPF) protocol” are applied “for email authentication that allows owners to sign their emails to help verify the email sent by the domain, whereas SPF is known technology to protect domains from being misused by malicious actors who send emails that appear to come from legitimate sources by verifying sender’s IP address”
The functions are is recited at a high-level of generality such that it amounts to no more than applying the exception using generic computer components. Taking the claim elements separately, the operation performed by the processor at each step of the process is purely in terms of results desired and devoid of implementation of details. This is true with respect to the limitations “authenticating” and “decoding” as the claimed limitations do not provide any technology to perform the recited functions. The claim limitations do not recite any technical on how the authenticating or the decoding process is performed as it related to technology. Rather the limitations of authenticating merely apply a known technology to authenticate a sender and a decoding step a token for the purpose of validating gift parameters, both of which are directed not toward technology but rather a sales activity. Technology is not integral to the process as the claimed subject matter is so high level that any generic programming could be applied and the steps could be performed by any known means within the technical environment claimed. Furthermore, the claimed functions do not provide an operation that could be considered as sufficient to provide a technological implementation or application of/or improvement to this concept (i.e. integrated into a practical application).
When the claims are taken as a whole, as an ordered combination, the combination of limitations 1-4 apply a processor and processor of an e-commerce system at a high level with expected outcomes of granting a sub-customer access to a full customer account by generating a transaction token and mailto link containing the token in a message where the message is transmitted to the full customer- which is directed toward generating and transmitting transaction tokens in a message for a transaction process. The combination of 1-4 is not directed toward any indications of patent eligibility. The combination of limitations 5 and 6-7, are directed toward applying SMTP for sending email messages and applying at a high level of generality a processor and DKIM/SPF protocols for authenticating an email address requiring domain alignment lacking any technical description with an expected outcome in combination with the message of limitations 1-4. The combination of limitations 8-13 is directed toward in combination with the authentication of the email sender of transaction message containing the token that is extracted and resolved of limitation 1-7, the resolving includes in light of the specification retrieving the associated token that is decoded and then validating the token parameters comprises extracting and comparing token data to parameters established by full customer and vendor identifiers against whitelist- which is directed toward an authentication and validation of token data for a transaction flow process using generic processors and as a tool to perform the transaction flow process. The combination of limitations 1-13 and 14-15 merely applies the processor at a high level to execute the transaction according to the parameters of the combination of limitations 1-13. The combination of parts are not dependent upon each other as a technical process but rather the abstract idea is applying technology to perform the operations of the abstract idea. The combinations of parts is not directed toward any technical process or technological technique or technological solution to a problem rooted in technology. Accordingly when the claims are taken as a whole, as an ordered combination, the combination of steps not integrate the judicial exception into a practical application as the claim process fails to impose meaningful limits upon the abstract idea. This is because the claimed subject matter fails to provide additional elements or combination or elements to apply or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception. The functions recited in the claims recite the concept of sending messages using a processor, where the message is authenticated and the stored funds information transmitted using a token is validated based on conditions in order for a customer to receive a stored funds of the full customer.
The integration of elements do not improve upon technology or improve upon computer functionality or capability in how computers carry out one of their basic functions. The SMTP is not part of the method process but instead is merely the known technology for transmitting email messages that the processors received information from. The SMTP does not perform any functions of the process beyond transmitting email messages. As discussed above, the “decoding” step is silent with respect to any technical process beyond an expected result. There is no indication in the claim limitations as to “how” the decoding of the token validates parameters of the stored funds.
The integration of elements do not provide a process that allows computers to perform functions that previously could not be performed. The integration of elements do not provide a process which applies a relationship to apply a new way of using an application. The instant application, therefore, still appears only to implement the abstract idea to the particular technological environments apply what generic computer functionality in the related arts. The steps are still a combination made to receiving, authenticating, validating and transferring gifts and does not provide any of the determined indications of patent eligibility set forth in the 2019 USPTO 101 guidance. The additional steps only add to those abstract ideas using generic functions, and the claims do not show improved ways of, for example, an particular technical function for performing the abstract idea that imposes meaningful limits upon the abstract idea. Moreover, Examiner was not able to identify any specific technological processes that goes beyond merely confining the abstract idea in a particular technological environment, which, when considered in the ordered combination with the other steps, could have transformed the nature of the abstract idea previously identified. The analysis concludes, it concluded that the claims still “simply recite high level function directed toward applying technology to mitigate risk in a transaction process” (e.g., granting access to an account, generate token and mailto link, transmitting stored funds offer, receiving request to transmit stored funds, authenticating the sender, decoding a token in the message, validating stored funds parameters and transferring the stored funds based on parameters validated) and “do not purport to improve any underlying technology.” The claim limitations are not an attempt to apply/use a judicial exception to effect a particular treatment for a condition. The claim limitations are not directed toward applying the judicial exception with or by use of a particular machine, as a generic processor performing a sales/transaction activity at a high level of generality to implement the transaction/transfer is not a particular machine. The claim limitations are not directed toward the transformation/reduction of a particular article to a different state or thing. The claim limitations simply confine the claimed abstract idea to a particular technical environment - see MPEP 2106.05(e) and Vanda Memo. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract subject matter include a “processor of the e-commerce system”, “SMTP”, “DomainKeys Identified Mail (DKIM) or Sender Policy Framework(SPF) protocols” and “e-commerce system”. The processor to perform high level functions “granting”, “generating”, “receiving”, “transmitting”, “receiving”, “authenticating”, “decoding”, “validating”, “extracting”, “comparing”, “determining”, “performing the transaction” and “executing …transfer [of funds]”–is purely functional and generic. Nearly every “processor” is capable of performing the basic functions required by the method steps . . . As a result, none of the processor recited by the method claims fails to offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
The additional elements “SMTP” is a software tool used for transmitting emails and is applied lacking any technical disclosure operating in its intended design. The claimed protocols “DomainKeys Identified Mail (DKIM) or Sender Policy Framework(SPF) protocols” which include description of operations used for authenticating e-mail address of a sender and requiring domain alignment are applied in their ordinary capacity for its intended design in the industry is high level in a manner encompassing any means for implementation.
Taking the claim elements separately, the function performed by the computer at each step of the process are performed at a high level of generally and is purely conventional amounting to no more than mere instructions to apply the abstract operations. Using a processor to decode a token is insignificant, as the token is not applied in the gift processor and is not relevant to any technical process. The SMTP communication protocol used transmit the received message does not perform any of the method process or apply any weight to the technical process of the method steps. It is merely the communication protocol applied to transmit messages. The functions for generating the token and the use of the DKIM/SPF are not dependent upon each other as a technical process. The claim limitations do not recite any processes related to the creation or technical implementation of the “mailto link” or the “token” contained in the message. The applicant did not invent SMTP, DKIM or SPF protocols and does not apply the protocol beyond its original intended function as it was designed to be applied. When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “granting”, “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring).
Utilizing SMTP for transferring email messages, in combination with the established technology of generating at a short token and mailto link that contains the generated token is well established technology. The specification and limitations do not provide any technical details as to how the token is generated or how the mailto link generated contains the generated token, instead the operations can be performed by any known means are high level with expected outcomes. The combination of limitations of transmitting the message using SMTP to transfer the email message that includes a mailto link in the email address header field that is authenticated using DKIM/SPF authentication protocol to prevent fraud is well established in email transmission technology and does not provide significantly more than a field of use for transmitting email technology and fraud prevention in emails. The combination of limitations where the generated token is extracted from the email header address where the email data fields are formatted in standard format (RFC 5322) lacks any details of how the token in extracted as a technical process and therefore, the extraction of the token is well-understood in the art. The combination of applying the extracted token to retrieve a token from a token store that is then decoded for use in a transaction where the content of the token are validated and the conditions of the token content for performing a transaction are compared and validated where based on the validated conditions a payment is executed focusing on the use of the technology in performing the validation conditions of the decoded token for use in executing a transaction. As a whole the combination of steps merely confine the mitigation of risk into a particular field of use with well-established technology being applied in its ordinary compacity and then performing a transaction according to transaction parameter from a stored token that is decoded in order to analyze parameters of the token for performing a payment. Accordingly the technology and combination of operations of the technology does not provide significantly more than applying established technology to mitigate risk and to perform a commercial activity. The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The Specification discloses:
[0002]…"invention is a system and method that aids management of electronic gift cards, shared accounts and payment processor integration with using email, SMS and social media based payments.
[0008] A system and method for gift cards, account controls, and payment processor integration with email payment in an e-commerce system are disclosed…
[0080] Generally, SPF is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is being sent from a host authorized by that domain's administrators. The list of authorized sending hosts for a domain may be published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Sender Policy Framework is described in IETF publication RFC 7208, which is incorporated by reference as if fully set forth.
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[00137] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer readable storage medium for execution by a general purpose computer or a processor….
With respect to generating a mailto link that generates a message, the specification discloses with respect to the generating mailto links applying tools or being implemented by a token generation but is silent with respect to any details of technical process that goes beyond its application.:
[0099]…The email service provider 170 may further include a tool for generating mailto links, graphic buttons, and tokens….
[00132] … When the vendor system 130 requests that the token generator 141 generate a mailto link with the identifiers and token,…
With respect to application of DKIM
“Identify Based Email Sender Authentication for Span Mitigation” by Hameed et al (2013); Email Authentication is Here, but Has it arrived yet? By Lawton (2005); “Blocking Foxy Phishing Emails with Historical Information” by Wu et al (2010). “Domainkeys Idntified Mail (DKIM) Signatures by dkim.org (2007)
US Pub No. 2005/0130638 A1 by Schrader- para 0021 wherein the prior art teaches conventional link processes.
NPL articles: The Full mailto Link Syntax by Mailto link syntax (2008); “Mailto link with auto link generation” by Stackoverflow (2014); “I like sharepoint” by InfoPath (2010/2013)
The specification para 0063 discloses the tokens as “site tokens …used for website transactions’, “email tokens for minimum of clicks email payments” and “universal tokens for email validation”. The specification discloses in para 0079 that “any known validation/authentication protocol may be used and the use of the DKIM/SPF protocol is used only to enhance the understanding of the reader using a specific …validation/authentication protocol” (see also para 0091). The specification describes the full customer setting parameters for sub-customers to access their accounts and make payments…providing payment for another customer on a limited basis (para 0142). The specification makes clear that the parameters of the token are not directed toward any underlying technology but rather toward a transaction permission of one customer for another.
With respect to the use of DKIM/SPF protocols for authentication, such use is known in the art and commonly applied in this aspect.
An Extension of the Sender Domain Authentication DKIM by Yoshiki et al; DomainKeys Identified Mail (DKIM) Signatures by RFC 4871; Secure Emails in XML Format Using Web Services by Liao
The specification discloses the general operation and use of SMTP, DkIM and SPF:
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0082] The sender address is transmitted at the beginning of the SMTP dialog If the server rejects the sender, the unauthorized client should receive a rejection message, and if that client was a relaying message transfer agent (MTA), a bounce message to the original sending address may be generated. If the server accepts the sender, and subsequently also accepts the recipients and the body of the message, it should insert a Return-Path field in the message header in order to save the sender address.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[0084] More specifically, both, signing and verifying modules are usually part of a mail transfer agent (l\lITA). The signing organization may be a direct handler of the message, such as the author, the originating sending site or an intermediary along the transit path, or an indirect handler such as an independent service that provides assistance to a direct handler. In most cases, the signing module acts on behalf of the author organization or the originating service provider by inserting a DKIM-Signature: header field. The verifying module typically acts on behalf of the receiver organization.
[0085] DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message -- the transported mail's header and body -- not the SMTP envelope defined in RFC 5321. Hence, the DKIM signature survives basic relaying across multiple MTAs. DKIM allows the signer to distinguish its legitimate mail stream. This ability to distinguish legitimate mail from potentially forged mail has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software
.
[0086] The "DKIM-Signature" header field, by way of example, may include a list of "tag=value" parts. Tags are short, usually only one or two letters. The most relevant ones are b for the actual digital signature of the contents (headers and body) of the mail message, bh for the body hash, d for the signing domain, and s for the selector. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64. The receiving SMTP server uses the
domain name and the selector to perform a DNS lookup.
With respect to domain alignment and DKIM:
“Forensic Analysis of E-mail address Spoofing” by Gupta et al
US Patent No. 10,277,628 B1 by Jakobsson -Col 9 lines 19-40; US Pub No. 2014/0280624 A1 by Dillingham et al- para 0068, EP 2709046 A1 by Dreller et al. -para 0006-0007, para 0033, para 0040-0041, para 0058, para 0061;
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 2-5 and 19-23 these dependent claim have also been reviewed with the same analysis as independent claim 1. Claim 2 is directed toward message transmitted as an email- insignificant extra solution activity. Claim 3 is directed toward message transmitted as SMS – insignificant extra solution activity. Claim 4 is directed toward message transmitted as social media post- insignificant extra solution activity. Claim 5 is directed toward validating email address of sender – well known and understood technology -see EP 2709046 A1 by Dreller et al. -para 0006-0007, para 0033, para 0040-0041, para 0058, para 0061. Dependent claim 19 is directed toward authenticating by verifying domain DMARC alignment and DKIM signing domain or SPF and rejecting message when alignment fails – well known technology -See EP 2709046 A1 by Dreller et al. -para 0006-0007, para 0033, para 0040-0041, para 0058, para 0061. Dependent claim 20 is directed toward mailto link places token in RFC 5322 email header address and decoding resolves short token to long token – well understood and routine use of technology; US Pub No. 2016/0300220 A1 by Sethi –para 0047; US Pub No. 2016/0180334 A1 by Kasemi et al- para 0151; US Patent No. 9,135,412 B1 by Talvensaari et al-Col 7 lines 27-33; US Pub No. 2015/0178819 A1 by Kassemi – para 0076, para 0107; Dependent claim 21 is directed toward the token carries expiration timestamp and rejecting transaction at expiration- directed toward a transaction rule for risk mitigation. Dependent claim 22 is directed toward extracting and parsing header data from token- mere data manipulation. Dependent claim 23 is directed toward whitelist vendor identifier, merchant category code, graphic region- directed toward risk mitigation.
The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 1. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 2-5 and 19-23 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to claim 7-11:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a system, as in independent Claim 7 and the dependent claims. Such systems fall under the statutory category of "machine." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The functions of system claim 7 corresponds to steps of method claim 1. Therefore, claim 7 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The functions of system claim 7 corresponds to steps of method claim 1. Therefore, claim 7 has been analyzed and rejected as failing to provide limitations that are indicative of integration into a practical application, as previously discussed with respect to claim 1.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract idea include a system comprising a memory, a communication interface and a processor communicatively coupled to the memory in communication with the interface–is purely functional and generic. Nearly every computer system for implementing a process will include a “processor”, “communication interface” and “memory” coupled for implementing a process “granting”, “generating”, “transmitting”, “receiving”, “authenticating”, “decoding”, “validating” and “transferring” gift . –is purely functional and generic. Nearly every “processor” is capable of performing the basic functions required by the system functions . . . As a result, none of the processor recited by the method claims fails to offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
Taking the claim elements separately, the function performed by the computer at each step of the process are performed at a high level of generally and is purely conventional amounting to no more than mere instructions to apply the abstract operations. Using a processor to decode a token is insignificant, as the token is not applied in the gift processor and is not relevant to any technical process. The SMTP communication protocol used transmit the received message does not perform any of the method process or apply any weight to the technical process of the method steps. It is merely the communication protocol applied to transmit messages. The functions for generating the token and the use of the DKIM/SPF are not dependent upon each other as a technical process. The claim limitations do not recite any processes related to the creation or technical implementation of the “mailto link” or the “token” contained in the message. The applicant did not invent SMTP, DKIM or SPF protocols and does not apply the protocol beyond its original intended function as it was designed to be applied. When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “granting”, “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring). Utilizing SMTP for transferring email messages, in combination with the established technology of generating at a short token and mailto link that contains the generated token is well established technology. The specification and limitations do not provide any technical details as to how the token is generated or how the mailto link generated contains the generated token, instead the operations can be performed by any known means are high level with expected outcomes. The combination of limitations of transmitting the message using SMTP to transfer the email message that includes a mailto link in the email address header field that is authenticated using DKIM/SPF authentication protocol to prevent fraud is well established in email transmission technology and does not provide significantly more than a field of use for transmitting email technology and fraud prevention in emails. The combination of limitations where the generated token is extracted from the email header address where the email data fields are formatted in standard format (RFC 5322) lacks any details of how the token in extracted as a technical process and therefore, the extraction of the token is well-understood in the art. The combination of applying the extracted token to retrieve a token from a token store that is then decoded for use in a transaction where the content of the token are validated and the conditions of the token content for performing a transaction are compared and validated where based on the validated conditions a payment is executed focusing on the use of the technology in performing the validation conditions of the decoded token for use in executing a transaction. As a whole the combination of steps merely confine the mitigation of risk into a particular field of use with well-established technology being applied in its ordinary compacity and then performing a transaction according to transaction parameter from a stored token that is decoded in order to analyze parameters of the token for performing a payment. Accordingly the technology and combination of operations of the technology does not provide significantly more than applying established technology to mitigate risk and to perform a commercial activity. The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The Specification discloses:
[0002]…"invention is a system and method that aids management of electronic gift cards, shared accounts and payment processor integration with using email, SMS and social media based payments.
[0008] A system and method for gift cards, account controls, and payment processor integration with email payment in an e-commerce system are disclosed…
[0080] Generally, SPF is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is being sent from a host authorized by that domain's administrators. The list of authorized sending hosts for a domain may be published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Sender Policy Framework is described in IETF publication RFC 7208, which is incorporated by reference as if fully set forth.
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[00137] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer readable storage medium for execution by a general purpose computer or a processor….
With respect to generating a mailto link that generates a message, the specification discloses with respect to the generating mailto links applying tools or being implemented by a token generation but is silent with respect to any details of technical process that goes beyond its application.:
[0099]…The email service provider 170 may further include a tool for generating mailto links, graphic buttons, and tokens….
[00132] … When the vendor system 130 requests that the token generator 141 generate a mailto link with the identifiers and token,…
With respect to application of DKIM
“Identify Based Email Sender Authentication for Span Mitigation” by Hameed et al (2013); Email Authentication is Here, but Has it arrived yet? By Lawton (2005); “Blocking Foxy Phishing Emails with Historical Information” by Wu et al (2010). “Domainkeys Idntified Mail (DKIM) Signatures by dkim.org (2007)
US Pub No. 2005/0130638 A1 by Schrader- para 0021 wherein the prior art teaches conventional link processes.
NPL articles: The Full mailto Link Syntax by Mailto link syntax (2008); “Mailto link with auto link generation” by Stackoverflow (2014); “I like sharepoint” by InfoPath (2010/2013)
With respect to domain alignment and DKIM:
“Forensic Analysis of E-mail address Spoofing” by Gupta et al
US Patent No. 10,277,628 B1 by Jakobsson -Col 9 lines 19-40; US Pub No. 2014/0280624 A1 by Dillingham et al- para 0068, EP 2709046 A1 by Dreller et al. -para 0006-0007, para 0033, para 0040-0041, para 0058, para 0061;
The specification para 0063 discloses the tokens as “site tokens …used for website transactions’, “email tokens for minimum of clicks email payments” and “universal tokens for email validation”. The specification discloses in para 0079 that “any known validation/authentication protocol may be used and the use of the DKIM/SPF protocol is used only to enhance the understanding of the reader using a specific …validation/authentication protocol”(see also para 0091). The specification describes the full customer setting parameters for sub-customers to access their accounts and make payments…providing payment for another customer on a limited basis (para 0142). The specification makes clear that the parameters of the token are not directed toward any underlying technology but rather toward a transaction permission of one customer for another.
With respect to the use of DKIM/SPF protocols for authentication, such use is known in the art and commonly applied in this aspect.
An Extension of the Sender Domain Authentication DKIM by Yoshiki et al; DomainKeys Identified Mail (DKIM) Signatures by RFC 4871; Secure Emails in XML Format Using Web Services by Liao
The specification discloses the general operation and use of SMTP, DkIM and SPF:
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0082] The sender address is transmitted at the beginning of the SMTP dialog If the server rejects the sender, the unauthorized client should receive a rejection message, and if that client was a relaying message transfer agent (MTA), a bounce message to the original sending address may be generated. If the server accepts the sender, and subsequently also accepts the recipients and the body of the message, it should insert a Return-Path field in the message header in order to save the sender address.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[0084] More specifically, both, signing and verifying modules are usually part of a mail transfer agent (l\lITA). The signing organization may be a direct handler of the message, such as the author, the originating sending site or an intermediary along the transit path, or an indirect handler such as an independent service that provides assistance to a direct handler. In most cases, the signing module acts on behalf of the author organization or the originating service provider by inserting a DKIM-Signature: header field. The verifying module typically acts on behalf of the receiver organization.
[0085] DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message -- the transported mail's header and body -- not the SMTP envelope defined in RFC 5321. Hence, the DKIM signature survives basic relaying across multiple MTAs. DKIM allows the signer to distinguish its legitimate mail stream. This ability to distinguish legitimate mail from potentially forged mail has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software
.
[0086] The "DKIM-Signature" header field, by way of example, may include a list of "tag=value" parts. Tags are short, usually only one or two letters. The most relevant ones are b for the actual digital signature of the contents (headers and body) of the mail message, bh for the body hash, d for the signing domain, and s for the selector. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64. The receiving SMTP server uses the
domain name and the selector to perform a DNS lookup.
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The functions of system claim 7 corresponds to steps of method claim 1. Therefore, claim 7 has been analyzed and rejected as failing to provide additional elements that amount to an inventive concept –i.e. significantly more than the recited judicial exception. Furthermore, as previously discussed with respect to claim 1, the limitations when considered individually, as a combination of parts or as a whole fail to provide any indication that the elements recited are unconventional or otherwise more than what is well understood, conventional, routine activity in the field.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 8-12 these dependent claim have also been reviewed with the same analysis as independent claim 7. Claim 8 is directed toward message transmitted as an email- insignificant extra solution activity. Claim 9 is directed toward message transmitted as SMS – insignificant extra solution activity. Claim 10 is directed toward message transmitted as social media post- insignificant extra solution activity. Claim 11 is directed toward comparing sender email address to email address of sub suction set by full customer- a common business practice. The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 7. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 8-11 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
In reference to Claims 13-17:
STEP 1. Per Step 1 of the two-step analysis, the claims are determined to include a non-transitory computer readable storage medium, as in independent Claim 13 and the dependent claims. Such mediums fall under the statutory category of "manufacture." Therefore, the claims are directed to a statutory eligibility category.
STEP 2A Prong 1. The instructions of medium claim 13 corresponds to steps of method claim 1. Therefore, claim 13 has been analyzed and rejected as being directed toward an abstract idea of the categories of concepts directed toward methods of organizing human activity previously discussed with respect to claim 1.
STEP 2A Prong 2: The instructions of medium claim 13 corresponds to steps of method claim 1. Therefore, claim 13 has been analyzed and rejected as failing to provide limitations that are indicative of integration into a practical application, as previously discussed with respect to claim 1.
STEP 2B; The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed above with respect to concepts of the abstract idea into a practical application. The additional elements beyond the abstract idea include a non-transitory computer readable mediums comprising instructions executed by a process or a system to execute the method claimed–is purely functional and generic. Nearly every non-transitory computer readable medium instructions executed by a generic process is capable of performing the basic functions required by the system functions . . . As a result, none of the instruction executed by a processor recited by the medium claims fails to offers a meaningful limitation beyond generally linking the use of the method to a particular technological environment, that is, implementation via computers.
Taking the claim elements separately, the function performed by the computer at each step of the process are performed at a high level of generally and is purely conventional amounting to no more than mere instructions to apply the abstract operations. Using a processor to decode a token is insignificant, as the token is not applied in the gift processor and is not relevant to any technical process. The SMTP communication protocol used transmit the received message does not perform any of the method process or apply any weight to the technical process of the method steps. It is merely the communication protocol applied to transmit messages. The functions for generating the token and the use of the DKIM/SPF are not dependent upon each other as a technical process. The claim limitations do not recite any processes related to the creation or technical implementation of the “mailto link” or the “token” contained in the message. The applicant did not invent SMTP, DKIM or SPF protocols and does not apply the protocol beyond its original intended function as it was designed to be applied. When the claims are taken as a whole, as an ordered combination, the combination of steps does not add “significantly more” by virtue of considering the steps as a whole, as an ordered combination. All of these computer functions are generic, routine, conventional computer activities that are performed only for their conventional uses. See Elec. Power Grp. v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016). Also see In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303, 1316 (Fed. Cir. 2011) ("Absent a possible narrower construction of the terms “granting”, “generating”, “transmitting”, “intercepting”, identifying”, “determining”, “replacing” and “routing' ... are functions can be achieved by any general purpose computer without special programming"). None of these activities are used in some unconventional manner nor do any produce some unexpected result. Applicants do not contend they invented any of these activities. In short, each step does no more than require a generic computer to perform generic computer functions.
As to the data operated upon, "even if a process of collecting and analyzing information is 'limited to particular content' or a particular 'source,' that limitation does not make the collection and analysis other than abstract." SAP America, Inc. v. Invest Pic LLC, 898 F.3d 1161, 1168 (Fed. Cir. 2018). Considered as an ordered combination, the computer components of Applicant’s claimed functions add nothing that is not already present when the steps are considered separately. The sequence of data reception-analysis modification-transmission is equally generic and conventional. See Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715 (Fed. Cir. 2014) (sequence of receiving, selecting, offering for exchange, display, allowing access, and receiving payment recited as an abstraction), Inventor Holdings, LLC v. Bed Bath & Beyond, Inc., 876 F.3d 1372, 1378 (Fed. Cir. 2017) (sequence of data retrieval, analysis, modification, generation, display, and transmission), Two-Way Media Ltd. v. Comcast Cable Communications, LLC, 874 F.3d 1329, 1339 (Fed. Cir. 2017) (sequence of processing, routing, controlling, and monitoring).
Utilizing SMTP for transferring email messages, in combination with the established technology of generating at a short token and mailto link that contains the generated token is well established technology. The specification and limitations do not provide any technical details as to how the token is generated or how the mailto link generated contains the generated token, instead the operations can be performed by any known means are high level with expected outcomes. The combination of limitations of transmitting the message using SMTP to transfer the email message that includes a mailto link in the email address header field that is authenticated using DKIM/SPF authentication protocol to prevent fraud is well established in email transmission technology and does not provide significantly more than a field of use for transmitting email technology and fraud prevention in emails. The combination of limitations where the generated token is extracted from the email header address where the email data fields are formatted in standard format (RFC 5322) lacks any details of how the token in extracted as a technical process and therefore, the extraction of the token is well-understood in the art. The combination of applying the extracted token to retrieve a token from a token store that is then decoded for use in a transaction where the content of the token are validated and the conditions of the token content for performing a transaction are compared and validated where based on the validated conditions a payment is executed focusing on the use of the technology in performing the validation conditions of the decoded token for use in executing a transaction. As a whole the combination of steps merely confine the mitigation of risk into a particular field of use with well-established technology being applied in its ordinary compacity and then performing a transaction according to transaction parameter from a stored token that is decoded in order to analyze parameters of the token for performing a payment. Accordingly the technology and combination of operations of the technology does not provide significantly more than applying established technology to mitigate risk and to perform a commercial activity. The ordering of the steps is therefore ordinary and conventional. The analysis concludes that the claims do not provide an inventive concept because the additional elements recited in the claims do not provide significantly more than the recited judicial exception.
According to 2106.05 well-understood and routine processes to perform the abstract idea is not sufficient to transform the claim into patent eligibility. As evidence the examiner provides:
The Specification discloses:
[0002]…"invention is a system and method that aids management of electronic gift cards, shared accounts and payment processor integration with using email, SMS and social media based payments.
[0008] A system and method for gift cards, account controls, and payment processor integration with email payment in an e-commerce system are disclosed…
[0080] Generally, SPF is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is being sent from a host authorized by that domain's administrators. The list of authorized sending hosts for a domain may be published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Sender Policy Framework is described in IETF publication RFC 7208, which is incorporated by reference as if fully set forth.
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[00137] The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a non-transitory computer readable storage medium for execution by a general purpose computer or a processor….
With respect to generating a mailto link that generates a message, the specification discloses with respect to the generating mailto links applying tools or being implemented by a token generation but is silent with respect to any details of technical process that goes beyond its application.:
[0099]…The email service provider 170 may further include a tool for generating mailto links, graphic buttons, and tokens….
[00132] … When the vendor system 130 requests that the token generator 141 generate a mailto link with the identifiers and token,…
With respect to application of DKIM
“Identify Based Email Sender Authentication for Span Mitigation” by Hameed et al (2013); Email Authentication is Here, but Has it arrived yet? By Lawton (2005); “Blocking Foxy Phishing Emails with Historical Information” by Wu et al (2010). “Domainkeys Idntified Mail (DKIM) Signatures by dkim.org (2007)
US Pub No. 2005/0130638 A1 by Schrader- para 0021 wherein the prior art teaches conventional link processes.
NPL articles: The Full mailto Link Syntax by Mailto link syntax (2008); “Mailto link with auto link generation” by Stackoverflow (2014); “I like sharepoint” by InfoPath (2010/2013)
With respect to domain alignment and DKIM:
“Forensic Analysis of E-mail address Spoofing” by Gupta et al
US Patent No. 10,277,628 B1 by Jakobsson -Col 9 lines 19-40; US Pub No. 2014/0280624 A1 by Dillingham et al- para 0068, EP 2709046 A1 by Dreller et al. -para 0006-0007, para 0033, para 0040-0041, para 0058, para 0061;
The specification para 0063 discloses the tokens as “site tokens …used for website transactions’, “email tokens for minimum of clicks email payments” and “universal tokens for email validation”. The specification discloses in para 0079 that “any known validation/authentication protocol may be used and the use of the DKIM/SPF protocol is used only to enhance the understanding of the reader using a specific …validation/authentication protocol”(see also para 0091). The specification describes the full customer setting parameters for sub-customers to access their accounts and make payments…providing payment for another customer on a limited basis (para 0142). The specification makes clear that the parameters of the token are not directed toward any underlying technology but rather toward a transaction permission of one customer for another.
With respect to the use of DKIM/SPF protocols for authentication, such use is known in the art and commonly applied in this aspect.
An Extension of the Sender Domain Authentication DKIM by Yoshiki et al; DomainKeys Identified Mail (DKIM) Signatures by RFC 4871; Secure Emails in XML Format Using Web Services by Liao
The specification discloses the general operation and use of SMTP, DkIM and SPF:
[0081] The Simple Mail Transfer Protocol (SMTP) permits any computer to send an email claiming to be from any source address. SPF allows the owner of an Internet domain to specify which computers are authorized to send email with sender addresses in that domain, using Domain Name System (DNS) records. Receivers verifying the SPF information in TXT records may reject messages from unauthorized sources before receiving the body of the message.
[0082] The sender address is transmitted at the beginning of the SMTP dialog If the server rejects the sender, the unauthorized client should receive a rejection message, and if that client was a relaying message transfer agent (MTA), a bounce message to the original sending address may be generated. If the server accepts the sender, and subsequently also accepts the recipients and the body of the message, it should insert a Return-Path field in the message header in order to save the sender address.
[0083] Generally, DKIM is an email validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain is authorized by that domain's administrators. A digital signature included with the message may be validated by the recipient using the signer's public key published in the DNS. DKIM is the result of merging DomainKeys and Identified Internet Mail. Prominent email service providers implementing DKIM include Yahoo, Gmail, AOL and FastMail. Any mail from these organizations should carry a DKIM signature.
[0084] More specifically, both, signing and verifying modules are usually part of a mail transfer agent (l\lITA). The signing organization may be a direct handler of the message, such as the author, the originating sending site or an intermediary along the transit path, or an indirect handler such as an independent service that provides assistance to a direct handler. In most cases, the signing module acts on behalf of the author organization or the originating service provider by inserting a DKIM-Signature: header field. The verifying module typically acts on behalf of the receiver organization.
[0085] DKIM is independent of Simple Mail Transfer Protocol (SMTP) routing aspects in that it operates on the RFC 5322 message -- the transported mail's header and body -- not the SMTP envelope defined in RFC 5321. Hence, the DKIM signature survives basic relaying across multiple MTAs. DKIM allows the signer to distinguish its legitimate mail stream. This ability to distinguish legitimate mail from potentially forged mail has benefits for recipients of e-mail as well as senders, and "DKIM awareness" is programmed into some e-mail software
.
[0086] The "DKIM-Signature" header field, by way of example, may include a list of "tag=value" parts. Tags are short, usually only one or two letters. The most relevant ones are b for the actual digital signature of the contents (headers and body) of the mail message, bh for the body hash, d for the signing domain, and s for the selector. The default parameters for the authentication mechanism are to use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64. The receiving SMTP server uses the
domain name and the selector to perform a DNS lookup.
According to Cybersource, “A Beauregard claim named after In re Beauregard, 53 F.3d 1583 (Fed.Cir.1995) is a claim to a computer readable medium (e.g., a disk, hard drive, or other data storage device) containing program instructions for a computer to perform a particular process.” In connection with the Beauregard claim, the Federal Circuit held that even though the claim is directed to a manufacture, the claim is not "truly drawn to a specific" computer readable medium, but rather is directed toward the method of detecting credit card fraud over the Internet. Simply reciting the use of a computer to execute an algorithm that can be performed entirely in the human mind will not change the analysis. The Beauregard claim was then treated as a method claim. This claim was determined not to meet the machine or transformation test. Although the claim altered data, "[t]he mere manipulation or reorganization of data, however, does not satisfy the transformation prong." Furthermore, the "incidental use" of a computer did not allow the claim to meet the machine portion of the test. The court noted that even though the method may require the use of a computer, methods that can be performed mentally, or which are the equivalent of human mental work, are unpatentable abstract ideas "even when performed by a computer"
The instant application, therefore, still appears to only implement the abstract ideas to the particular technological environments using what is generic components and functions in the related arts. The claim is not patent eligible.
The instructions of medium claim 13 corresponds to steps of method claim 1. Therefore, claim 13 has been analyzed and rejected as failing to provide additional elements that amount to an inventive concept –i.e. significantly more than the recited judicial exception. Furthermore, as previously discussed with respect to claim 1, the limitations when considered individually, as a combination of parts or as a whole fail to provide any indication that the elements recited are unconventional or otherwise more than what is well understood, conventional, routine activity in the field.
The remaining dependent claims—which impose additional limitations—also fail to claim patent-eligible subject matter because the limitations cannot be considered statutory. In reference to claims 14-17 these dependent claim have also been reviewed with the same analysis as independent claim 13. Claim 14 is directed toward message transmitted as an email- insignificant extra solution activity. Claim 15 is directed toward message transmitted as SMS – insignificant extra solution activity. Claim 16 is directed toward message transmitted as social media post- insignificant extra solution activity. Claim 17 is directed toward comparing sender email address to email address of sub suction set by full customer- a common business practice. The dependent claim(s) have been examined individually and in combination with the preceding claims, however they do not cure the deficiencies of claim 13. Where all claims are directed to the same abstract idea, “addressing each claim of the asserted patents [is] unnecessary.” Content Extraction & Transmission LLC v. Wells Fargo Bank, Nat 7 Ass ’n, 776 F.3d 1343, 1348 (Fed. Cir. 2014). If applicant believes the dependent claims 14-17 are directed towards patent eligible subject matter, they are invited to point out the specific limitations in the claim that are directed towards patent eligible subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries 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.
Claim(s) 1-3, 5 and 20; Claims 7-9 and 11; Claims 13-15 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,311,406 B2 by Kassemi et al. (Kassemi), in view of WO 2007/062065 by Leining (Leining) and further in view of WO 2015199977 A1 by Whitehouse (Whitehouse) and US Pub No. 2004/0215721 A1 by Szeto et al. (Szeto)
In reference to Claim 1:
Kassemi teaches:
(Currently Amended) A method for improving security of an e-commerce system utilizing Simple Mail Transfer Protocol (SMTP) ((Kassemi) in at least Abstract)
granting, by a processor, a sub-customer (customer of vendor) restricted access to an account of a full- customer, wherein the account stores funds [rewards/points] that are accessible to the e-commerce system ((Kassemi) in at least Col 8 lines 19-56, lines 64-67 wherein the prior art teaches offers include reward points frequent flyer miles or bitcoin, Col 9 lines 19-25 and lines 40-53 wherein the prior at teaches vendor sever create tokens for product/offer use by vendor [full-customer] server, Col 10 lines 13-23, Col 13 lines 28-55, Col 17 lines 9-28, Col 19 lines 35-Col 20 lines 1-6);
generating, by the processor, a token that is unique to the sub-customer, wherein the token includes parameters that are defined by the full-customer and comprises at least a sub-customer identifier and an allowance identifier ((Kassemi) in at least Col 6 lines 56-Col 7 lines 1-10 wherein the prior art teaches generating token including customer identifier):
generating, by the processor, a mailto link that when activated generates a response message that contains the token ((Kassemi) in at least Col 8 lines 29-56, Col 9 lines 1-14, lines 25-53);
transmitting, by the processor of the e-commerce system, message to a full-customer [vendor/merchant], wherein the message includes the mailto link and a token ((Kassemi) in at least Abstract; Col 2 lines 52-64);
receiving, by the processor, the response message via SMTP from an e-mail address of the full-customer, the response message indicating a request to transmit a portion of the funds to the sub-customer [customer of vendor] ((Kassemi) in at least Abstract; Fig. 2 ref # 203-204; FIG. 3 ref # 302; FIG. 21- 23; FIG. 24 ref #2401; Col 1 lines 25-32, Col 1 lines 64-Col 2 lines 1-3, Col 2 lines 52-64, Col 3 lines 8-26, Col 4 lines 14-20, lines 35-43, , Col 19 lines 3-Col 20 lines 1-6; Claim 1)
authenticating, by the processor, an email address of a sender of the response message using at least one of DomainKeys Identified Mail (DKIM) or Sender Policy Framework (SPF) protocols and requiring domain alignment [DKIM signature check and SPF records] between a DKIM-signing domain or an SPF authenticated domain and From domain of the response message ((Kassemi) in at least Abstract; Col 2 lines 52-64, Col 6 lines 33-40, Col 8 lines 7-13, Col 9 lines 60-Col 10 lines 1-4, Col 11 lines 20-30 wherein the prior art teaches checking valid DKIM signatures and SPF records); and…
on a condition that the e-mail address of the sender is authenticated ((Kassemi) in at least Col 11 lines 20-Col 12 lines 1-13 wherein the prior art teaches checking valid DKIM signatures and SPF records);
decoding, by the processor, the token to form a decoded token ((Kassemi) in at least abstract; Col 4 lines 45-52, Col 7 lines 60-67, Col 11 lines 46-52, Col 12 lines 30-32, Col 14 lines 5-10);
validating, by the processor, the parameters included in the decoded token, the validating including …an amount of the transaction from the decoded token and … balance of a time-window spend limit of the allowance established by the full-customer for the sub-customer and, when the decoded token further carries a vendor identifier, determining that the vendor identifier is in a whitelist [list] specified by the full-customer; ((Kassemi) in at least Abstract; FIG. 5-6; Col 3 lines 1-10 wherein the prior art teaches token includes an amount field for transaction and teaches list of recipients transmitted with respect to bulk field; Col 6 lines 43-52, Col 7 lines 15-18, lines 25-28 wherein the prior art teaches token includes expiration date, and value; Col 8 lines 33-38, Col 10 lines 37-52, Col 11 lines 45-72, Col 17 lines 15-20, Col 19 lines 47-53, Col 21 lines 20-25; Claim 1) and
on a condition that the parameters are validated, performing, by the processor, the transaction by executing an intra-system transfer that debits an internal account of the full-customer and credits an internal account of the sub-customer maintained by the e-commerce system without contracting an external payment network. ((Kassemi) in at least FIG. 19, Col 2 lines 65-Col 3 lines 1-15, Col 17 lines 34-42, Col 18 lines 25-36,Col 19 lines 3-10, lines 52-Col 20 lines 1-6, Col 20 lines 26-43)
Kassemi does not explicitly teach:
…wherein the account stores funds [rewards/points] that are accessible to the e-commerce system
extracting, by the processor, a short lookup token from an RFC 5322 e-mail header address field of the response message: and resolving, by the processor, the short lookup token to the token retrieved from a token store;
validating including extracting an amount of the transaction from the decoded token and comparing the amount to a remaining balance of a time-window spend limit of the allowance established by the full-customer for the sub- customer …
Leining teaches:
granting, by a processor, a sub-customer (customer of vendor) restricted access to an account [collaborative account] of a full- customer, wherein the account stores funds that are accessible to the e-commerce system ((Leining) in at least Fig. 3A-B; page 3 lines 4-13, page 4 lines 3-8, page 5 lines 5-12, lines 25-28, lines 33-35, page 12 lines 1-17, page 13 lines 11-22, page 14 lines 14-16, lines 23-pge 15 lines 1-5) ;
generating, by the processor, a … link that when activated generates a response message that contains the token (offer code) ((Leining) in at least page 13 lines 1-10)
According to KSR, simple substitution of one known element for another to obtain predictable results is common sense rationale supports a conclusion of obviousness. The prior art reference Kassemi contained an offer which differed from the claimed device by the substation of another type of offer. The prior art Leining provides evidence that the offers of Kassemi and the claim limitations and their use where known in the art. Accordingly, based on the common sense rationale of simple substitution, one of ordinary skill in the art could have substituted one known advertising offer for another and the substitution would have been predictable.
Furthermore, under KSR, common sense rationale includes that known work in one field of endeavor may prompt variations of it for use in the same field of endeavor based on the design incentives or other market forces if the variations are predictable. The scope and content as it relates to advertising offers of the prior art Kassemi and Leining included similar advertising offers. The prior art Leining provides design incentives/market forces for collaborative credit accounts provided to customers (sub-customer) that are internal cards of the merchant (full customer of the bank of the collaborative cards) in order to use these cards to track user behavior and incentives customers to return that would prompted adaptation of the known advertising campaign offer variations. Therefore, the prior art provides teaching that the difference between the claimed invention and the prior references Kassemi and Leining were encompassed in known variations or in a principle known in the art. Therefore, common sense dictates that one of ordinary skill in the art in view of the identified design incentives/market forces could have implemented the claimed variation of the prior art and the claimed variations would have been predictable to one of ordinary skill in the art.
Both Kassemi and Leining are directed toward vender advertising campaign that entails email campaign providing funding offers to customers. Leining teaches the motivation that it is known that such campaign offers can include merchant charge cards in order to encourage consumers to return to a merchant. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the advertising campaigned offered to merchants of Kassemi to include credit/charge account of Leining as an offer in an advertising campaign as taught by Leining since Leining teaches the motivation that it is known that such campaign offers can include merchant charge cards in order to encourage consumers to return to a merchant.
Szeto teaches:
extracting, by the processor, a short lookup token from an RFC 5322 e-mail header address field of the response message: and resolving, by the processor, the short lookup token to the token retrieved from a token store ((Szeto) in at least abstract; para 0037, para 0042, para 0052, para 0054, para 0058-0059 wherein the prior art teaches token resolution, para 0064, para 0068-0069, para 0075);
Although Szeto does not explicitly recite the standard email format “to” header and body of the message format as RFC 5322 email format, RFC 5322 established 2008, defines the Internet Message Format (IMF), which specifies the structure of email messages, including headers and body content. The “To” header is a critical component of this format, as it identifies the recipient(s) (s) of the message. RFC 5322 is the standard that defines the format of email messages, including headers, fields and message structure. According to KSR, in light of the prior art teaching of email message data fields which include address headers, body of the message ect… and in light of knowledge generally available to one of ordinary skill in the art, the prior art provides some teaching, suggestion and/or motivation that would have led one of ordinary skill in the art to modify the reference to include the email standard (RFC 5322) for message format defining email message structures with a reasonable expectation of success to arrive at the claimed limitation.
Both Kassemi and Szeto are directed toward email transmission includes transmitting tokens for use in a transaction process. Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the mailto and token application process of Kessami to prevent fraud to include the lookup token embedded in the email message URL in the header message of Szeto to include extracting the token embedded in the message header and token resolution since Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated.
Whitehouse teaches:
validating including extracting an amount of the transaction from the decoded token and comparing the amount to a remaining balance of a time-window spend limit of the allowance established by the full-customer for the sub- customer …((Whitehouse) in at least FIG. 8; page 13 para 0028, page 22 para 0047, page 27 para 0057, page 28 para 0059, page 30 para 0061, page 31 para 0062, page 48 para 0093, page 50 para 0099, page 51 para 0100)
Both Kassemi and Whitehouse are directed toward applying tokens and decrypting tokens providing payment information in transactions. Whitehouse teaches the motivation reading the token content in order to allow the payer to verify the payment, where the verification checks whether token has expired and other token data including balance check that is decremented upon redemption. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify details of the token application for payment of Kassemi to include validating conditions for use as taught by Whitehouse since Whitehouse teaches the motivation reading the token content in order to allow the payer to verify the payment, where the verification checks whether token has expired and other token data including balance check that is decremented upon redemption.
In reference to Claim 2:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 2
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
wherein the message is transmitted as an email message. ((Kassemi) in at least Abstract)
In reference to Claim 3:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 3
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein the message is transmitted as a Short Message Service (SMS) message.
Whitehouse teaches:
wherein the message is transmitted as a Short Message Service (SMS) message. ((Whitehouse) in at least page 36 para 72)
According to KSR, simple substitution of one known element for another to obtain predictable results is common sense rationale supports a conclusion of obviousness. The prior art reference Kassemi contained an offer which differed from the claimed device by the substituted medium for transmitting/receiving tokens. The prior art Whitehouse provides evidence that the medium applied to transmitting tokens/offers to parties include alternatives to email and that mediums for transmitting tokens their use where known in the art. Accordingly, based on the common sense rationale of simple substitution, one of ordinary skill in the art could have substituted one known medium for another and the substitution would have been predictable.
Both Kassemi and Whitehouse teach communicating utilizing SMS message protocol. Whitehouse teaches the motivation of using SMS messages for transmitting tokens as an alternative medium to email. It would have been obvious to one having ordinary skill at the time of effective filing the invention to expand the SMS message content of Kassemi to include gift offer messages as taught by Whitehouse since Whitehouse teaches the motivation of using SMS messages for transmitting tokens as an alternative medium to email
In reference to Claim 5:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 5
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
wherein the validating further includes comparing the email address of the sender of the response message to a stored email address of the full-customer. ((Kassemi) in at least ((Kassemi) in at least Abstract; Fig. 2 ref # 203-204; FIG. 3 ref # 302; FIG. 21- 23; FIG. 24 ref #2401; Col 2 lines 43-52, Col 4 lines 21-26, Col 7 lines 11-12, Col 10 lines 1-14, lines 62-63; Claim 1, Claim 4 )
In reference to Claim 21:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 21.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein the token carries an expiration timestamp and the method further comprises rejecting the transaction when a Date header of the response message exceeds the expiration timestamp.
Whitehouse teaches:
wherein the token carries an expiration timestamp and the method further comprises rejecting the transaction when a Date header of the response message exceeds the expiration timestamp. ((Whitehouse) in at least page 30 para 0061, page 34 para 0069-0070, page 48 para 0093)
Both Kassemi and Whitehouse are directed toward applying tokens and decrypting tokens providing payment information in transactions. Whitehouse teaches the motivation of generating a token where the token is timestamp for use in the authentication structure of the process. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the use of time related to the token of Kassemi to include timestamp as taught by Whitehouse since Whitehouse teaches the motivation of generating a token where the token is timestamp for use in the authentication structure of the process.
In reference to Claim 20:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 20
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein the mailto link places a short lookup token in an RFC 5322 e-mail header address field of the response message, and the decoding includes resolving the short lookup token to a long token retrieved from a token store.
Szeto teaches:
wherein the mailto link places a short lookup token in an RFC 5322 e-mail header address field of the response message, and the decoding includes resolving the short lookup token to a long token retrieved from a token store.((Szeto) in at least abstract; para 0037, para 0042, para 0052, para 0054, para 0058-0059 wherein the prior art teaches token resolution, para 0064, para 0068-0069, para 0075, ;
Although Szeto does not explicitly recite the standard email format “to” header and body of the message format as RFC 5322 email format, RFC 5322 established 2008, defines the Internet Message Format (IMF), which specifies the structure of email messages, including headers and body content. The “To” header is a critical component of this format, as it identifies the recipient(s) (s) of the message. RFC 5322 is the standard that defines the format of email messages, including headers, fields and message structure. According to KSR, in light of the prior art teaching of email message data fields which include address headers, body of the message ect… and in light of knowledge generally available to one of ordinary skill in the art, the prior art provides some teaching, suggestion and/or motivation that would have led one of ordinary skill in the art to modify the reference to include the email standard (RFC 5322) for message format defining email message structures with a reasonable expectation of success to arrive at the claimed limitation.
Both Kassemi and Szeto are directed toward email transmission includes transmitting tokens for use in a transaction process. Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the mailto and token application process of Kessami to prevent fraud to include the lookup token embedded in the email message URL in the header message of Szeto to include extracting the token embedded in the message header and token resolution since Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated.
In reference to Claim 7:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 7.
(Currently Amended) A system for improving security of an e-commerce system utilizing Simple Mail Transfer Protocol (SMTP) ((Kassemi) in at least FIG. 1), the system comprising:
a memory ((Kassemi) in at least Col 4 lines 62-Col 5 lines 1-5);
a communication interface ((Kassemi) in at least Col 6 lines 8-33, Col 20 lines 56-63); and
one or more processors communicatively coupled to the memory and the communication interface ((Kassemi) in at least Col 4 lines 62-Col 5 lines 1-5, Col 5 lines 37-40, Col 5 lines 65-Col 6 lines 1-33, Col 20 lines 46-55);
wherein the one or more processors are collectively ((Kassemi) in at least Col 4 lines 62-Col 5 lines 1-5, Col 5 lines 37-40, Col 5 lines 65-Col 6 lines 1-33, Col 20 lines 46-55) configured to:
grant a sub-customer restricted access to an account of a full-customer, wherein the account stores funds that are accessible to the e-commerce system ((Kassemi) in at least Col 8 lines 19-56, lines 64-67 wherein the prior art teaches offers include reward points frequent flyer miles or bitcoin, Col 9 lines 19-25 and lines 40-53 wherein the prior at teaches vendor sever create tokens for product/offer use by vendor [full-customer] server, Col 10 lines 13-23, Col 13 lines 28-55, Col 17 lines 9-28, Col 19 lines 35-Col 20 lines 1-6);
generate a token that is unique to the sub-customer for a transaction, wherein the token includes parameters that are defined by the full-customer and comprises at a sub-customer identifier and an allowance identifier ((Kassemi) in at least Col 6 lines 56-63, Col 7 lines 1-10, wherein the prior art teaches generating token including customer identifier lines 15-18, Col 21 lines 22-25):
generate a mailto link that when activated generates a response message that contains the token ((Kassemi) in at least Col 8 lines 29-56, Col 9 lines 1-14, lines 25-53);
transmit, using the communication interface, a message to the full-customer, wherein the message includes the mailto link ((Kassemi) in at least Abstract; Col 2 lines 52-64);
receive, using the communication interface, the response message via SMTP from an email address of the full-customer, the response message indicating a request to transfer a portion of the funds to the sub-customer [customer of vendor] ((Kassemi) in at least Abstract; Fig. 2 ref # 203-204; FIG. 3 ref # 302; FIG. 21- 23; FIG. 24 ref #2401; Col 1 lines 25-32, Col 1 lines 64-Col 2 lines 1-3, Col 2 lines 52-64, Col 3 lines 8-26, Col 4 lines 14-20, lines 35-43, , Col 19 lines 3-Col 20 lines 1-6; Claim 1);
authenticate an e-mail address of a sender of the response message using at least one of DomainKeys Identified Mail (DKIM) or Sender Policy Framework (SPF) protocols and requiring domain alignment between DKIM signing domain or an SPF authenticated domain and a From domain of the response message ((Kassemi) in at least Abstract; Col 2 lines 52-64, Col 6 lines 33-40, Col 8 lines 7-13, Col 9 lines 60-Col 10 lines 1-4, Col 11 lines 20-30 wherein the prior art teaches checking valid DKIM signatures and SPF records); and
on a condition that the e-mail address of the sender is authenticated ((Kassemi) in at least Abstract; Col 6 lines 8-33, Col 8 lines 4-12, Col 11 lines 63-Col 12 lines 1-32, Col 14 lines 5-14):
decode the token to form a decoded token((Kassemi) in at least abstract; Col 4 lines 45-52, Col 7 lines 60-67, Col 11 lines 46-52, Col 12 lines 30-32, Col 14 lines 5-10);
perform a validation of parameters included in the decoded token, the validation including … an amount of the transaction from the decoded token and comparing the amount to a remaining balance of a time-window spend limit of the allowance established by the full-customer for the sub-customer and, when the decoded token further carries a vendor identifier, determining that the vendor identifier is in a whitelist [approved list] specified by the full-customer; ((Kassemi) in at least Abstract; FIG. 5-6; FIG. 19, Col 2 lines 65-Col 3 lines 1-15 wherein the prior art teaches token includes an amount field for transaction and teaches list of recipients transmitted with respect to bulk field; Col 6 lines 43-52, Col 7 lines 15-18, lines 25-28 wherein the prior art teaches token includes expiration date, and value; Col 8 lines 33-38, Col 10 lines 37-52, Col 11 lines 45-72, Col 17 lines 15-20, lines 34-42, Col 18 lines 25-36, Col 19 lines 3-10, lines 47-53-Col 20 lines 1-6, , Col 21 lines 20-25; Claim 1) and
when the parameters are successfully validated, perform the transaction, by executing an intra-system transfer that debits an internal account of the full-customer and credits an internal account of the sub-customer maintained by the e-commerce system without contracting an external payment network. ((Kassemi) in at least FIG. 19, Col 2 lines 65-Col 3 lines 1-15, Col 17 lines 34-42, Col 18 lines 25-36,Col 19 lines 3-10, lines 52-Col 20 lines 1-6, Col 20 lines 1-6 lines 26-43)
Kassemi does not explicitly teach:
…wherein the account stores funds [rewards/points] that are accessible to the e-commerce system
extract a short lookup token from an RFC 5322 e-mail header address field of the response message: and resolve the short lookup token to the token retrieved from a token store
extracting an amount of the transactions from the decoded token and comparing the amount to a remaining balance of a time-window spend limit of the allowance…
Leining teaches:
granting, by a processor, a sub-customer (customer of vendor) restricted access to an account [collaborative account] of a full- customer, wherein the account stores funds that are accessible to the e-commerce system ((Leining) in at least Fig. 3A-B; page 3 lines 4-13, page 4 lines 3-8, page 5 lines 5-12, lines 25-28, lines 33-35, page 12 lines 1-17, page 13 lines 11-22, page 14 lines 14-16, lines 23-pge 15 lines 1-5) ;
generating, by the processor, a … link that when activated generates a response message that contains the token (offer code) ((Leining) in at least page 13 lines 1-10)
According to KSR, simple substitution of one known element for another to obtain predictable results is common sense rationale supports a conclusion of obviousness. The prior art reference Kassemi contained an offer which differed from the claimed device by the substation of another type of offer. The prior art Leining provides evidence that the offers of Kassemi and the claim limitations and their use where known in the art. Accordingly, based on the common sense rationale of simple substitution, one of ordinary skill in the art could have substituted one known advertising offer for another and the substitution would have been predictable.
Furthermore, under KSR, common sense rationale includes that known work in one field of endeavor may prompt variations of it for use in the same field of endeavor based on the design incentives or other market forces if the variations are predictable. The scope and content as it relates to advertising offers of the prior art Kassemi and Leining included similar advertising offers. The prior art Leining provides design incentives/market forces for collaborative credit accounts provided to customers (sub-customer) that are internal cards of the merchant (full customer of the bank of the collaborative cards) in order to use these cards to track user behavior and incentives customers to return that would prompted adaptation of the known advertising campaign offer variations. Therefore, the prior art provides teaching that the difference between the claimed invention and the prior references Kassemi and Leining were encompassed in known variations or in a principle known in the art. Therefore, common sense dictates that one of ordinary skill in the art in view of the identified design incentives/market forces could have implemented the claimed variation of the prior art and the claimed variations would have been predictable to one of ordinary skill in the art.
Both Kassemi and Leining are directed toward vender advertising campaign that entails email campaign providing funding offers to customers. Leining teaches the motivation that it is known that such campaign offers can include merchant charge cards in order to encourage consumers to return to a merchant. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the advertising campaigned offered to merchants of Kassemi to include credit/charge account of Leining as an offer in an advertising campaign as taught by Leining since Leining teaches the motivation that it is known that such campaign offers can include merchant charge cards in order to encourage consumers to return to a merchant.
Szeto teaches:
extracting, by the processor, a short lookup token from an RFC 5322 e-mail header address field of the response message: and resolving, by the processor, the short lookup token to the token retrieved from a token store ((Szeto) in at least abstract; para 0037, para 0042, para 0052, para 0054, para 0058-0059 wherein the prior art teaches token resolution, para 0064, para 0068-0069, para 0075, ;
Although Szeto does not explicitly recite the standard email format “to” header and body of the message format as RFC 5322 email format, RFC 5322 established 2008, defines the Internet Message Format (IMF), which specifies the structure of email messages, including headers and body content. The “To” header is a critical component of this format, as it identifies the recipient(s) (s) of the message. RFC 5322 is the standard that defines the format of email messages, including headers, fields and message structure. According to KSR, in light of the prior art teaching of email message data fields which include address headers, body of the message ect… and in light of knowledge generally available to one of ordinary skill in the art, the prior art provides some teaching, suggestion and/or motivation that would have led one of ordinary skill in the art to modify the reference to include the email standard (RFC 5322) for message format defining email message structures with a reasonable expectation of success to arrive at the claimed limitation.
Both Kassemi and Szeto are directed toward email transmission includes transmitting tokens for use in a transaction process. Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the mailto and token application process of Kessami to prevent fraud to include the lookup token embedded in the email message URL in the header message of Szeto to include extracting the token embedded in the message header and token resolution since Szeto teaches the motivation implementing a mechanism for preventing email headers from being forged inserting into the email header a token that provides additional information usable to distinguish between legitimate/illegitimate email messages and teaches a token resolution process where the token inserted into the email url header is extracted for comparison to tokens stored and maintained by the token module where if the comparison finds the token stored matches the data of the stored token is validated.
Whitehouse teaches:
validating including extracting an amount of the transaction from the decoded token and comparing the amount to a remaining balance of a time-window spend limit of the allowance established by the full-customer for the sub- customer …((Whitehouse) in at least FIG. 8; page 13 para 0028, page 22 para 0047, page 27 para 0057, page 28 para 0059, page 30 para 0061, page 31 para 0062, page 48 para 0093, page 50 para 0099, page 51 para 0100)
Both Kassemi and Whitehouse are directed toward applying tokens and decrypting tokens providing payment information in transactions. Whitehouse teaches the motivation reading the token content in order to allow the payer to verify the payment, where the verification checks whether token has expired and other token data including balance check that is decremented upon redemption. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify details of the token application for payment of Kassemi to include validating conditions for use as taught by Whitehouse since Whitehouse teaches the motivation reading the token content in order to allow the payer to verify the payment, where the verification checks whether token has expired and other token data including balance check that is decremented upon redemption.
In reference to Claim 8:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 7. Kassemi further discloses the limitations of dependent claim 8.
System claim 8 functions corresponds to the step of method claim 2. Therefore, claim 8 has been analyzed and rejected as previously discussed with respect to claim 2
In reference to Claim 9:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 7. Kassemi further discloses the limitations of dependent claim 9.
System claim 9 functions corresponds to the step of method claim 3. Therefore, claim 9 has been analyzed and rejected as previously discussed with respect to claim 3
In reference to Claim 11:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 7. Kassemi further discloses the limitations of dependent claim 11.
(Previously Presented) The system of claim 7 (see rejection of claim 7 above),
wherein validation further includes comparing the email address of the sender of the response message to a stored email address of the full-customer. ((Kassemi) in at least ((Kassemi) in at least Abstract; Fig. 2 ref # 203-204; FIG. 3 ref # 302; FIG. 21- 23; FIG. 24 ref #2401; Col 2 lines 43-52, Col 4 lines 21-26, Col 7 lines 11-12, Col 10 lines 1-14, lines 62-63, claim 1, Claim 4 )
In reference to Claim 13:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 13
Non-transitory computer readable medium claim 13 instructions executed by a processor correspond to the method steps of method claim 1. The additional limitations recited in claim 13 that go beyond the limitations of claim 1 include the non-transitory computer readable medium that when executed by a processor ((Kassemi) in at least Col 20 lines 56-63)
implement the instructions corresponding to the steps of claim 1. Therefore, claim 13 has been analyzed and rejected as previously discussed with respect to claim 1.
In reference to Claim 14:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 13. Kassemi further discloses the limitations of dependent claim 14.
Medium claim 14 instructions executed corresponds to the step of method claim 2. Therefore, claim 14 has been analyzed and rejected as previously discussed with respect to claim 2
In reference to Claim 15:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 13. Kassemi further discloses the limitations of dependent claim 15.
Medium claim 15 instructions executed corresponds to the step of method claim 3. Therefore, claim 15 has been analyzed and rejected as previously discussed with respect to claim 3
In reference to Claim 17:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 13. Kassemi further discloses the limitations of dependent claim 17.
Medium claim 17 instructions executed corresponds to the step of method claim 5 Therefore, claim 17 has been analyzed and rejected as previously discussed with respect to claim 5
Claim(s) 4 as applied to claim 1 above, Claim 10 applied to claim 7 above, Claims 16 applied to claim 13 above is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,311,406 B2 by Kassemi et al. (Kassemi) ) in view of WO 2007/062065 by Leining (Leining) in view of WO 2015199977 A1 by Whitehouse (Whitehouse) in view of US Pub No. 2004/0215721 A1 by Szeto et al. (Szeto) and further in view of US Pub No. 2013/0346302 A1 by Purves et al. (Purves)
In reference to Claim 4:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 4
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein the message is transmitted as a social media post.
Purves teaches:
wherein the message is transmitted as a social media post. ((Purves) in at least para 0316)
Both Kassemi and Purves teach vendors providing to customers products. Purves teaches the motivation of vendors utilizing social media post to users/customers in order to specify a social media feed of a third party on which to post a promotion directed toward their own brand and services. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the means of communicating to customers products for customers to select to include posting promotions on social media as taught by Purves since . Purves teaches the motivation of vendors utilizing social media post to users/customers in order to specify a social media feed of a third party on which to post a promotion directed toward their own brand and services.
In reference to Claim 10:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 7. Kassemi further discloses the limitations of dependent claim 10.
System claim 10 functions corresponds to the step of method claim 4. Therefore, claim 10 has been analyzed and rejected as previously discussed with respect to claim 4
In reference to Claim 16:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 13. Kassemi further discloses the limitations of dependent claim 16.
Medium claim 16 instructions executed corresponds to the step of method claim 4. Therefore, claim 16 has been analyzed and rejected as previously discussed with respect to claim 4.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,311,406 B2 by Kassemi et al. (Kassemi) ) in view of WO 2007/062065 by Leining (Leining) in view of WO 2015199977 A1 by Whitehouse (Whitehouse) in view of US Pub No. 2004/0215721 A1 by Szeto et al. (Szeto) as applied to claim 1 above, and further in view of EP 2709046 A1 by Dreller et al. (Dreller)
In reference to Claim 19:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 19
(Previously Presented) The method of claim 1 (see rejection of claim 1 above), wherein authenticating further includes
verifying Domain-based Message Authentication, Reporting, and Conformance … alignment between the From domain and at least one of a DKIM-signing domain or an SPF-authenticated domain and rejecting the response message when the alignment fails. ((Kassemi) in at least Abstract; Col 2 lines 52-64, Col 6 lines 33-40, Col 8 lines 7-13, Col 9 lines 60-Col 10 lines 1-4, Col 11 lines 20-30 wherein the prior art teaches checking valid DKIM signatures and SPF records)
Kassemi does not explicitly teach:
DMARC
Dreller teaches:
verifying Domain-based Message Authentication, Reporting, and Conformance DMARC alignment between the From domain and at least one of a DKIM-signing domain or an SPF-authenticated domain and rejecting the response message when the alignment fails. ((Dreller) in at least FIG. 2; para 0040-0041, para 0043, para 0045, para 0069, para 0081)
Both Kassemi and Dreller are directed toward applying DKIM signatures and SPF validation of emails. Dreller teaches the motivation of reducing email fraud by applying DMARC validation mechanisms. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the details of validation of DKIM signatures of Kassemi to include the DMARC details as taught by Driller since Dreller teaches the motivation of reducing email fraud by applying DMARC validation mechanisms.
Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,311,406 B2 by Kassemi et al. (Kassemi) ) in view of WO 2007/062065 by Leining (Leining) in view of WO 2015199977 A1 by Whitehouse (Whitehouse) in view of US Pub No. 2004/0215721 A1 by Szeto et al. (Szeto) as applied to claim 1 above, and further in view of “Message Header Field for Indicating Message Authentication Status” by rfc-editor (RFC)
In reference to Claim 22:
The combination of Kassemi, Leining and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 22.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein extracting the token comprises parsing a To header of the response message in accordance with RFC 5322.
RFC teaches:
wherein extracting the token comprises parsing a To header of the response message in accordance with RFC 5322. ((RFC) in at least page 8, page 12, page 14, page 40-41)
Both Kassemi and RFC are directed toward extracting data from messages. RFC teaches the motivation of applying parsers for easy data field extraction with the application of RFC 5322 format rules in messages. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the extraction of data process of Kassemi to include RFC extraction details since RFC teaches the motivation of applying parsers for easy data field extraction with the application of RFC 5322 format rules in messages.
Claim(s) 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. 10,311,406 B2 by Kassemi et al. (Kassemi) ) in view of WO 2007/062065 by Leining (Leining) in view of WO 2015199977 A1 by Whitehouse (Whitehouse) in view of US Pub No. 2004/0215721 A1 by Szeto et al. (Szeto) as applied to claim 1 above, and further in view of US Patent No. 8,793,806 B1 by Truong et al. (Truong)
In reference to Claim 23:
The combination of Kassemi, Leining, Szeto and Whitehouse discloses the limitations of independent claim 1. Kassemi further discloses the limitations of dependent claim 23.
(Previously Presented) The method of claim 1 (see rejection of claim 1 above),
Kassemi does not explicitly teach:
wherein the whitelist comprises at least one of a vendor identifier, a merchant category code, and a geographic region
Truong teaches:
wherein the whitelist comprises at least one of a vendor identifier, a merchant category code, and a geographic region ((Truong) in at least Col 5 lines 6-52)
Both Kassemi and Truong teach generating tokens with customized list for application of tokens. Truong teaches the motivation that such customized whitelist can include content which includes demographics or any other content. It would have been obvious to one having ordinary skill at the time of effective filing the invention to modify the list for restrictions of Kassemi to include the customized list options as taught by Truong since Truong teaches the motivation that such customized whitelist can include content which includes demographics or any other content.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US Pub No. 2012/0059886 A1 by Shuster; US Pub No. 2014/0279444 A1 by Kassemi et al; US 2012/0185542 A1 by Vyrros et al.
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 MARY M GREGG whose telephone number is (571)270-5050. The examiner can normally be reached M-F 9am-5pm.
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, Christine Behncke can be reached at 571-272-8103. 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.
/MARY M GREGG/Examiner, Art Unit 3695
/CHRISTINE M Tran/Supervisory Patent Examiner, Art Unit 3695
Prosecution Insights