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 .
This Office Action is in response to Application No. 19/220,728 filed on 05/28/2025.
Claims 1-20 have been examined and are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/28/2025, is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claims 1, 3-5, 7-8, 10-12, 14-15, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Spies et al. ( U.S. Pub. 2009/0172804 A1; Hereinafter “Spies”) in view of Jueneman et al. (U.S Pub. 2008/0130895 A1; Hereinafter “Jueneman”).
PNG
media_image1.png
556
780
media_image1.png
Greyscale
Regarding claim 1, Spies teaches a method performed by a sending messaging gateway, the method comprising (Spies teaches message processing applications installed on a gateway at a sending organization. Spies explains that message processing applications may regulate both transmission and reception of email and may be used at the sender and recipient. See Spies para [0094-0095], [0112], and Fig. 3-4.):
obtaining, by the sending messaging gateway, a public key associated with a recipient messaging gateway (Spies para [0121]: “the message processing applications 32 may obtain the IBE public key of the recipient (Q) and public parameter information (e.g., P and sP)”, Spies teaches that the sending gateway obtains cryptographic public key information associated with the recipient side. Specifically, the gateway message processing applications obtain the recipient’s IBE public key and public parameter information before encrypting the message. See Spies para [0121] and Fig. 7. Spies additionally teaches that encryption may be directed to an organization or organizational domain rather than an individual recipient. The sender may generate the public key identity from the domain or subdomain portion of the recipient’s address, and the receiving gateway obtains the corresponding private key using the credentials of the organization. See Spies para [0167], Thus, Spies teaches public-key information associated with the recipient organization and processed by the recipient organization’s gateway);
encrypting, by the sending messaging gateway, a message using encryption scheme to generate an encrypted message (Spies teaches that the sending organization’s gateway uses encryption engine 18 to encrypt outgoing email. See Spies para [0095]. Spies more specifically teaches that, when encryption is indicated by policy or sender information, the gateway obtains the recipient public key and uses the gateway encryption engine to encrypt the message for the recipient. See Spies para [0120-0121] and Fig. 7.); and
transmitting, by the sending messaging gateway, the encrypted message to the recipient messaging gateway (Spies expressly teaches that outgoing email from organization A is encrypted by the sending gateway and received by gateway services at organization B. See Spies para [0095] [0122]. Spies also teaches that, after gateway processing, the encrypted or unencrypted message is sent through the sending organization’s firewall to the recipient over communications network 14. See Spies para [0126]. Spies further teaches that the message is received over network 14 by the recipient’s organization and processed at the recipient’s gateway. See Spies para [0127-0131]. Accordingly, Spies teaches transmitting the encrypted message from a sending messaging gateway to a recipient messaging gateway.).
Spies does not expressly identify this public key information as being contained in a public certificate; determining, by the sending messaging gateway based on evaluating the public certificate, whether the public certificate contains a predefined capability indicator signifying support, by the recipient messaging gateway, for an enhanced encryption scheme; responsive to determining that the public certificate contains the predefined capability indicator, selecting, by the sending messaging gateway, the enhanced encryption scheme; responsive to determining that the public certificate does not contain the predefined capability indicator, selecting, by the sending messaging gateway, a legacy encryption scheme.
However, in an analogue art, Jueneman teaches a public key certificates associated with recipients (Jueneman teaches obtaining and examining public key certificates associated with recipients. Jueneman teaches that an X.509 certificate containing public keys may be published in an LDAP directory or other certificate repository for customary distribution. See Jueneman para [0069-0070]. Jueneman further teaches scanning certificates in a recipient certificate store to identify certificates containing cryptographic capability attributes. See Jueneman para [0173-0175].);
determining, by the sending messaging gateway based on evaluating the public certificate, whether the public certificate contains a predefined capability indicator signifying support, by the recipient messaging gateway, for an enhanced encryption scheme (Jueneman teaches scanning recipient certificates for an SMIMECapabilities object identifier identifying whether the recipient is capable of accepting AES-encrypted email. See Jueneman para [0173]. Jueneman also teaches examining certificates for a custom ECCKeyAttribute extension indicating support for enhanced ECC cryptographic processing. See Jueneman para [0174-0175]. Jueneman further teaches that the SMIMECapabilities attribute can identify supported: AES-128, AES-192, or AES-256; SHA-2 functions; ECC key-establishment schemes; and key-derivation functions. See Jueneman para [0141].);
responsive to determining that the public certificate contains the predefined capability indicator, selecting, by the sending messaging gateway, the enhanced encryption scheme (Jueneman teaches that when the plug in finds an SMIMECapabilities OID indicating AES support, the certificate is registered with a custom cryptographic service provider rather than the Microsoft default cryptographic provider. See Jueneman para [0173]. Jueneman further expressly teaches overriding the symmetric key algorithm based on the SMIMECapabilities attribute. When the attribute is present and specifies an AES key length, the corresponding AES key length is selected and used. See Jueneman para [0178].);
responsive to determining that the public certificate does not contain the predefined capability indicator, selecting, by the sending messaging gateway, a legacy encryption scheme (Jueneman teaches a cryptographic architecture having: a Microsoft default or legacy cryptographic service provider; and a custom cryptographic service provider supporting enhanced encryption. See Jueneman para [0173] and the legacy/default CSP architecture of the disclosed system. Jueneman teaches that the certificate is changed to point to the custom provider when the capability OID is found. Therefore, when the capability indicator is not found, the certificate remains associated with the Microsoft default cryptographic service provider. Jueneman further teaches that the legacy or default provider handles RSA and other legacy cryptographic operations, while the special provider handles enhanced ECC cryptographic operations. See Jueneman para [0065-0067]. Jueneman teaches that only certificates containing the enhanced capability indicator are reassigned from the Microsoft default CSP to the custom enhanced CSP. Therefore, a certificate lacking the indicator remains processed by the default, legacy CSP. See Jueneman para [0065], [0173], and [0175].).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the secure email gateway system of Spies, as taught by Jueneman, to obtain a recipient side public certificate, determine whether the certificate includes a predefined cryptographic capability indicator, select enhanced encryption when the indicator is present, and retain legacy encryption when the indicator is absent, because doing so would allow the sending gateway to use stronger encryption with recipient gateways that support it while maintaining backward compatibility and successful message delivery to recipient gateways supporting only legacy encryption (Jueneman, para. [0005]).
Furthermore, Spies also teaches the hardware components of claims 8 and 15 such as a non-transitory computer-readable medium storing instructions, a network interface configured to communicate over a network; one or more processors; and a memory storing instructions that, when executed by the one or more processors, cause the system to perform operations comprising (Spies teaches gateway 48 coupled through firewall 34 to communications network 14 and coupled to organization network 38 and mail server 42. Spies teaches gateway equipment implementing message processing applications, an encryption engine, a decryption engine, a database controller, and other processes. See Spies para [0097-0112] and Fig. 4. ).
Regarding claims 3, 10, and 17, Spies in view of Jueneman teaches the independent claim 1. Jueneman teaches wherein the public certificate is an X.509 certificate, wherein the predefined capability indicator is located within an extensions section of the X.509 certificate (Jueneman teaches creating an X.509 certificate containing RSA and ECC public keys, with the ECC public key included in a unique certificate extension. See Jueneman para [0069]. Jueneman also teaches an X.509 ECCKeyAttribute extension containing enhanced-key information. See Jueneman para [0120], [0136-0140], and [0175]. The extension includes cryptographic Key Usage, Extended Key Usage, subject-key identification, and key-container information. Jueneman further teaches searching certificates for the SMIMECapabilities OID and the custom ECCKeyAttribute extension. See Jueneman para [0173-0175].).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the secure email gateway system of Spies, as taught by Jueneman, to obtain a recipient side public certificate, because doing so would allow the sending gateway to use stronger encryption with recipient gateways that support it while maintaining backward compatibility and successful message delivery to recipient gateways supporting only legacy encryption (Jueneman, para. [0005]).
Regarding claims 4 and 11, Spies in view of Jueneman teaches the dependent claim 3. Jueneman teaches wherein the predefined capability indicator comprises a specific bit within a Key Usage extension being set to a predefined value (Jueneman teaches that the ECCKeyAttribute extension includes Key Usage and Extended Key Usage fields. See Jueneman para [0136-0137]. Jueneman further provides the ASN.1 definition of an ECCKeyUsage bit string containing predefined bits for: digital signature; nonrepudiation; key agreement; encipher only; and decipher only. See Jueneman para [0140].).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the secure email gateway system of Spies, as taught by Jueneman, to obtain a recipient side public certificate, because doing so would allow the sending gateway to use stronger encryption with recipient gateways that support it while maintaining backward compatibility and successful message delivery to recipient gateways supporting only legacy encryption (Jueneman, para. [0005]).
Regarding claims 5, 12, and 18, Spies in view of Jueneman teaches the dependent claim 3. Jueneman teaches wherein the predefined capability indicator comprises the presence of a predefined Object Identifier (OID) within one of: a custom extension or a Certificate Policies extension (Jueneman teaches searching a recipient certificate for an SMIMECapabilities OID specifying whether the recipient is capable of accepting AES-encrypted email. See Jueneman para [0173]. Jueneman also teaches a custom ECCKeyAttribute extension and object identifiers associated with Extended Key Usage and email protection. See Jueneman para [0140-0141].).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the secure email gateway system of Spies, as taught by Jueneman, to obtain a recipient side public certificate, because doing so would allow the sending gateway to use stronger encryption with recipient gateways that support it while maintaining backward compatibility and successful message delivery to recipient gateways supporting only legacy encryption (Jueneman, para. [0005]).
Regarding claims 7, 14, and 20, Spies in view of Jueneman teaches the independent claim 1. Jueneman teaches wherein the legacy encryption scheme comprises using Advanced Encryption Standard (AES) in Cipher Block Chaining (CBC) mode for content encryption and Rivest-Shamir-Adleman (RSA) encryption with Public-Key Cryptography Standards (PKCS) #1 v1.5 padding for key encryption (Jueneman: para [0096], [0109],“The legacy key wrapping field (7,A) contains an internal structure known to the LCS implementation. The Flags and Padding block (7,B) contains 1176 bits, and may contain application specific version numbers and other information as may be required. In order to be a valid RSA encryption result, the higher order bit must be a 1.”).
Therefore, It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the secure email gateway system of Spies, as taught by Jueneman, to obtain a recipient side public certificate, because doing so would allow the sending gateway to use stronger encryption with recipient gateways that support it while maintaining backward compatibility and successful message delivery to recipient gateways supporting only legacy encryption (Jueneman, para. [0005]).
Claims 2, 9 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Spies et al. ( U.S. Pub. 2009/0172804 A1; Hereinafter “Spies”) in view of Jueneman et al. (U.S Pub. 2008/0130895 A1; Hereinafter “Jueneman”) and Eisner et al. (U.S Pub. 2014/0341217 A1; Hereinafter “Eisner”).
Regarding claims 2, 9, and 16, Spies in view of Jueneman teaches the independent claim 1.
Spies in view of Jueneman does not teach the complete synchronized local certificate cache arrangement.
However, in the related art, Eisner teaches wherein obtaining the public certificate comprises retrieving the public certificate from a local certificate cache maintained by the sending messaging gateway, wherein the local certificate cache is synchronized with a central certificate repository storing public certificates for a plurality of messaging gateways, wherein a messaging gateway comprises the recipient messaging gateway (Einer teaches that each gateway includes a local keystore configured to store the gateway’s private key and certificates for other remote gateways with which the local gateway communicates. Eisner further teaches keeping the keystore current to account for additions and deletions of gateway participants and changes to individual certificates, including certificate expiration. See Eisner para [0096]. Eisner further teaches that, when a new gateway joins the network, the new gateway’s certificate is distributed to the other participating gateways, and the keystores of those gateways are updated with the new certificate. In the self-signed certificate implementation, certificates may be distributed through a centralized distribution facility so that the gateway keystores are updated. In the PKI implementation, a certificate authority provides a central location for certificate storage and distribution. See Eisner para [0097]. Thus, Eisner teaches synchronizing or updating the local gateway keystores from a centralized certificate-distribution facility or central certificate storage location containing certificates for multiple participating gateways. Eisner also teaches that, before a secure gateway message is transmitted, the gateway looks up the recipient’s certificate, validates the certificate, and encrypts the gateway message using the intended recipient’s public key. See Eisner para [0093]–[0094].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to further modify the secure email gateway system of Spies, as modified by Jueneman, to maintain recipient gateway certificates in a local gateway keystore and update that keystore from a centralized certificate storage or distribution facility, as taught by Eisner, because doing so would provide efficient local access to recipient certificates while keeping the locally stored certificates current as gateways are added or removed and as certificates are replaced or expire, and reduced the risk of encrypting messages using obsolete or invalid recipient gateway certificates (Eisner, para. [0005]).
Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Spies et al. ( U.S. Pub. 2009/0172804 A1; Hereinafter “Spies”) in view of Jueneman et al. (U.S Pub. 2008/0130895 A1; Hereinafter “Jueneman”) and Schiffman et al. (U.S Pub. 2021/0377007 A1; Hereinafter “Schiffman”).
Regarding claims 6, 13, and 19, Pies in view of Jueneman teaches the independent claim 1.
Spies in view of Jueneman does not teach wherein the enhanced encryption scheme comprises using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) for content encryption and Rivest-Shamir-Adleman (RSA) encryption with Optimal Asymmetric Encryption Padding (OAEP) for key encryption.
However, in the related art, Schiffman teaches wherein the enhanced encryption scheme comprises using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) for content encryption and Rivest-Shamir-Adleman (RSA) encryption with Optimal Asymmetric Encryption Padding (OAEP) for key encryption (Schiffman teaches an Advanced Encryption Standard (AES), such as AES in Galois/Counter Mode (GCM), and a secure pseudo random number generator may be used to randomly generate a CEK 100 and an initialization vector for the content (represented as “CONTENT.sub.IV” in FIG. 10) is generated. Schiffman also teaches a message M is encrypted under CEK with the content initialization vector (CIV) using AES-GCM to generate the ciphertext 1006 (represented as “C” in FIG. 10). Schiffman further teaches PEK are encrypted using RSA-OAEP under the printers public key (N,E), ), see Schiffman para [057-061], fig. 10. ).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to further modify the secure email gateway system of Spies, as modified by Schiffman, to use Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) for content encryption and Rivest-Shamir-Adleman (RSA) encryption with Optimal Asymmetric Encryption Padding (OAEP) for key encryption, it would verify that the content has not been tampered with or corrupted and provide resistance to attacks (Schiffman, para. [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170163607 A1 - Establishing a communication event using secure signaling
US 20130061289 A1- A secure messaging interface enables submission of messages to a messaging gateway via secure means over TLS
US 20030202663 A1- A message-oriented middleware solution for securely transmitting messages and files across public networks unencumbered by intervening network barriers implemented as security measures
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=10250698 - Performance Comparison of Hybrid Encryption Models.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Odd-Monday: 8:00 AM 4:00 PM, Tuesday & Wednesday: 9:00 AM 3:00 PM. Even-Monday: 8:00 AM 4:00 PM, Tuesday through Thursday: 9:00 AM 1:00 PM.
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, Alexander Lagor can be reached at (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/ALEXANDER LAGOR/Supervisory Patent Examiner, Art Unit 2437
Prosecution Insights