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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 11,924,224 and claims 1-20 of U.S. Patent No.12,328,321. Although the claims at issue are not identical, they are not patentably distinct from each other because the Present Application is substantially a broadened version of the unamended claims originally filed in U.S. Patent Application 17/306,524 (now U.S. Patent No. 11,924,224).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 102(a)(1) as being antedated by NIST Special Publication 800-177 Revision 1 Trustworthy Email (NISTSP 800-177r1).
As Per Claim 1: NISTSP 800-177r1 teaches: A computing platform, comprising:
- at least one processor;
- a communication interface; and
- memory storing computer-readable instructions that, when executed by the at least one processor, cause the computing platform to:
Inherent underlying hardware.
(NISTSP 800-177r1, Page iv, Section: Executive Summary, Paragraph 2, “Email is a core application of computer networking and has been such since the early days of Internet development. In those early days, networking was a collegial, research-oriented enterprise. Security was not a consideration. The past forty years have seen diversity in applications deployed on the Internet, and worldwide adoption of email by research organizations, governments, militaries, businesses and individuals. At the same time there has been an associated increase in (Internet-based) criminal and nuisance threats.”).
- receive, via the communication interface, from a message source server associated with a first domain, a first email message and a first set of authentication credentials;
- validate the first set of authentication credentials;
(NISTSP 800-177r1, Section: 2.1.2 Mail Transfer Agents (MTAs), “Email is transmitted, in a “store and forward” fashion, across networks via Mail Transfer Agents (MTAs). MTAs communicate using the Simple Mail Transfer Protocol (SMTP) described below and act as both client and server, depending on the situation. For example, an MTA can act as a server when accepting an email message from an end user's MUA, then act as a client in connecting to and transferring the message to the recipient domain's MTA for final delivery.
MTAs can be described with more specialized language that denotes specific functions:
• Mail Submission Agents (MSA): An MTA that accepts mail from MUAs (usually after authenticating the sender) and begins the transmission process by sending it to a MTA for further processing. Often the MSA and first-hop MTA is the same process, just fulfilling both roles.
• Mail Delivery Agent (MDA): An MTA that receives mail from an organization's inbound MTA and ultimately places the message in a specific mailbox. Like the MSA, the MDA could be a combined in-bound MTA and MDA component.
Mail servers may also perform various security functions to prevent malicious email from being delivered or include authentication credentials such as digital signatures (see Sender Policy Framework Section 4.3 and DomainKeys Identified Mail (DKIM) Section 4.5). These security functions may be provided by other components that act as lightweight MTAs or these functions may be added to MTAs via filters or patches.
An email message may pass through multiple MTAs before reaching the final recipient. Each MTA in the chain may have its own security policy (which may be uniform within an organization but may not be uniform) and there is currently no way for a sender to request a particular level of security for the email message. However, there is work in progress1 for specifying how a client can request the use of TLS for message transmission.”).
- inject, into a first email message associated with a first domain, a Domain Keys Identified Mail (DKIM) signature of a second domain different from the first domain, to produce a first signed message identified as originating from the second domain;
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Page 52, Lines 24-29, “
1. The mediator can alter the message-From: field to match the envelope-From:. In this case the SPF lookup would be on the mediator’s domain.
2. After making the customary modifications, which break the originators DKIM signature, the email relay can generate its own DKIM signature over the modified header and body. Multiple DKIM signatures in a message are acceptable and DMARC policy is that at least one of the signatures must authenticate to pass DMARC.”).
- send, to a message recipient server, the first signed message, wherein sending the first signed message causes the message recipient server to validate the DKIM signature of the first signed message and determine, based on validating the DKIM signature of the first signed message, that the first signed message passes Domain-based Message Authentication, Reporting and Conformance (DMARC) with respect to the second domain.
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Paragraph 2, Lines 1-2, “Another example is the use of some third-party email scanning services. In cases where email is received by a domain, and then “shunted” to a third party for scanning.”).
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Table 4-7, “
PNG
media_image1.png
271
488
media_image1.png
Greyscale
”).
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Page 52, Lines 24-29, “
1. The mediator can alter the message-From: field to match the envelope-From:. In this case the SPF lookup would be on the mediator’s domain.
2. After making the customary modifications, which break the originators DKIM signature, the email relay can generate its own DKIM signature over the modified header and body. Multiple DKIM signatures in a message are acceptable and DMARC policy is that at least one of the signatures must authenticate to pass DMARC.”).
(NISTSP 800-177r1, Page 6, Paragraph 2, “The DNS is also used as the publication method for protocols designed to protect email and combat malicious, spoofed email. Technologies such as SPF, DKIM and other use the DNS to publish policy artifacts or public keys that can be used by receiving MTAs to validate that a given message originated from the purported sending domain's mail servers. These protocols are discussed in Section 4. In addition, there are new proposals to encode end-user certificates or public keys (for S/MIME or OpenPGP) in the DNS using a mailbox as the hostname. These protocols are discussed in Section 5.3.”).
As Per Claim 2: The rejection of claim 1 is incorporated and further NISTSP 800-177r1 teaches:
- the first domain is a domain name corresponding to a first entity, and the first email message comprises information identifying an Envelope From domain of the first email message as the domain name corresponding to the first entity, and wherein the second domain is a domain name corresponding to a second entity different from the first entity, and the first email message comprises information identifying a Header From domain of the first email message as the domain name corresponding to the second entity.
(NISTSP 800-177r1, Section 4.1 Introduction, Paragraph 1, “RFC 5322 defines the Internet Message Format (IMF) for delivery over the Simple Mail Transfer Protocol (SMTP) [RFC5321], but in its original state any sender can write any envelope-From: address in the header (see Section 2.3.3). is envelope-From: address can however be overridden by malicious senders or enterprise mail administrators, who may have organizational reasons to rewrite the header, and so both [RFC 5321] and [RFC 5322] defined From: addresses can be aligned to some arbitrary form not intrinsically associated with the originating IP address. In addition, any man in the middle attack can modify a header or data content. New protocols were developed to detect these envelope-From: and message-From: address spoofing or modifications.”).
(NISTSP 800-177r1, Section 4.6.7 Mail Forwarding and Indirect Email Flows, Paragraphs 1-2, “The message authentication devices of SPF, DKIM and DMARC are designed to work directly between a sender domain and a receiver domain. The message envelope and RFC5322.From address pass through a series of MTAs and are authenticated by the receiver. The DKIM signature, message headers and message body arrive at the receiver unchanged. The email system has additional complexities as there are a variety of message forwarding activity that will very often either modify the message or change the apparent message-From: domain. For example, user@example.gov sends a message to ourgroup@example.net, which is subsequently forwarded to all members of the mail group. If the mail group software simply relays the message, the envelope-From: address denoting the forwarder differs from the message-From: address, denoting the original sender. In this case DMARC processing will rely on DKIM for authentication. If the forwarder modifies the message-From: field to match the HELO of the sending MTA (see Section 2.3.1), SPF may authenticate, but the modified header will make the DKIM signature invalid.
Another example is the use of some third-party email scanning services. In cases where email is received by a domain, and then “shunted” to a third party for scanning. The email is then sent back (via SMTP) to the original receiving domain, which may consider the incoming email as a newly seen message. This is sometimes seen in federal agencies that use one provider for email and another provider for Trusted Internet Connection (TIC) services (see Figure 4-2). Incoming mail is received by the cloud provider, then forwarded to the TIC provider for scanning. After scanning, the email message is sent back to the cloud provider. Upon the second delivery, the message appears to be spoofed, as SPF and DMARC validations will fail.”).
As Per Claim 3: The rejection of claim 2 is incorporated and further NISTSP 800-177r1 teaches:
- the second entity is an organization, and the first entity is a third-party service provider to the organization.
(NISTSP 800-177r1, Section 4.6.7 Mail Forwarding and Indirect Email Flows, Paragraphs 1-2, “The message authentication devices of SPF, DKIM and DMARC are designed to work directly between a sender domain and a receiver domain. The message envelope and RFC5322.From address pass through a series of MTAs and are authenticated by the receiver. The DKIM signature, message headers and message body arrive at the receiver unchanged. The email system has additional complexities as there are a variety of message forwarding activity that will very often either modify the message or change the apparent message-From: domain. For example, user@example.gov sends a message to ourgroup@example.net, which is subsequently forwarded to all members of the mail group. If the mail group software simply relays the message, the envelope-From: address denoting the forwarder differs from the message-From: address, denoting the original sender. In this case DMARC processing will rely on DKIM for authentication. If the forwarder modifies the message-From: field to match the HELO of the sending MTA (see Section 2.3.1), SPF may authenticate, but the modified header will make the DKIM signature invalid.
Another example is the use of some third-party email scanning services. In cases where email is received by a domain, and then “shunted” to a third party for scanning. The email is then sent back (via SMTP) to the original receiving domain, which may consider the incoming email as a newly seen message. This is sometimes seen in federal agencies that use one provider for email and another provider for Trusted Internet Connection (TIC) services (see Figure 4-2). Incoming mail is received by the cloud provider, then forwarded to the TIC provider for scanning. After scanning, the email message is sent back to the cloud provider. Upon the second delivery, the message appears to be spoofed, as SPF and DMARC validations will fail.”).
As Per Claim 4: The rejection of claim 1 is incorporated and further NISTSP 800-177r1 teaches:
- scan content of the first signed message, wherein scanning the content of the first signed message comprises executing an antispam-antivirus scan on the content of the first signed message.
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Paragraph 2, Lines 1-2, “Another example is the use of some third-party email scanning services. In cases where email is received by a domain, and then “shunted” to a third party for scanning.”).
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Table 4-7, “
PNG
media_image1.png
271
488
media_image1.png
Greyscale
”).
As Per Claim 5: The rejection of claim 1 is incorporated and further NISTSP 800-177r1 teaches:
- sending the first signed message to the message recipient server causes the message recipient server to validate the DKIM signature of the first signed message by comparing the DKIM signature of the first signed message with a public key linked to the second domain and maintained on a domain name system (DNS) server.
(NISTSP 800-177r1, Section: 4.5 DomainKeys Identified Mail (DKIM), Paragraph 2, “A DKIM signature is generated by the signing MTA using the email message body and headers and places it in the header of the message along with information for the client to use in validation of the signature (i.e., key selector, algorithm, etc.). When the receiving MTA gets the message, it attempts to validate the signature by looking for the public key indicated in the DKIM signature. The MTA issues a DNS query for a text resource record (TXT RR) that contains the encoded key.”).
As Per Claim 6: The rejection of claim 1 is incorporated and further NISTSP 800-177r1 teaches:
- sending the first signed message to the message recipient server causes the message recipient server to provide a recipient user with access to the first signed message based on the first signed message passing DMARC with respect to the second domain.
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Page 52, Lines 24-29, “
1. The mediator can alter the message-From: field to match the envelope-From:. In this case the SPF lookup would be on the mediator’s domain.
2. After making the customary modifications, which break the originators DKIM signature, the email relay can generate its own DKIM signature over the modified header and body. Multiple DKIM signatures in a message are acceptable and DMARC policy is that at least one of the signatures must authenticate to pass DMARC.”).
As Per Claim 7: The rejection of claim 6 is incorporated and further NISTSP 800-177r1 teaches:
- sending the first signed message to the message recipient server causes the message recipient server to provide the recipient user with access to the first signed message by adding the first signed message to a mail folder accessible to the recipient user without quarantining the message.
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Page 52, Lines 24-29, “
1. The mediator can alter the message-From: field to match the envelope-From:. In this case the SPF lookup would be on the mediator’s domain.
2. After making the customary modifications, which break the originators DKIM signature, the email relay can generate its own DKIM signature over the modified header and body. Multiple DKIM signatures in a message are acceptable and DMARC policy is that at least one of the signatures must authenticate to pass DMARC.”).
(NISTSP 800-177r1, Page 47, Paragraph 2, “An agency with several subdomains may wish to have a single unified policy, in which case a DMARC RR with the sp= tag is used. In this example, the domain has a policy to reject any mail from a subdomain of example.gov that fails checks, while only quarantining email that failed checks from the parent domain.”).
As Per Claim 8: The rejection of claim 6 is incorporated and further NISTSP 800-177r1 teaches:
- sending the first signed message to the message recipient server causes the message recipient server to provide the recipient user with access to the first signed message by sending the first signed message to a recipient user device.
(NISTSP 800-177r1, Section: 4.6.7 Mail Forwarding and Indirect Email Flows, Page 52, Lines 24-29, “
1. The mediator can alter the message-From: field to match the envelope-From:. In this case the SPF lookup would be on the mediator’s domain.
2. After making the customary modifications, which break the originators DKIM signature, the email relay can generate its own DKIM signature over the modified header and body. Multiple DKIM signatures in a message are acceptable and DMARC policy is that at least one of the signatures must authenticate to pass DMARC.”).
As Per Claims 9-16: Claims 9-16 are substantially a restatement of the computing platform of claims 1-8 as a method and are rejected under substantially the same reasoning.
As Per Claims 17-20: Claims 17-20 are substantially a restatement of the computing platform of claims 1-4 as a non-transitory computer-readable media and are rejected under substantially the same reasoning.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN A KAPLAN whose telephone number is (571)270-3170. The examiner can normally be reached 9:00 a.m. - 5:00 p.m..
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, Kambiz Zand can be reached on (571)272-3811. 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.
/BENJAMIN A KAPLAN/Examiner, Art Unit 2434
Prosecution Insights