DETAILED ACTION
Claims 1-13 are pending. Claims 1 and 11 have been amended.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This non-final office action is in response to the applicant’s response received on 01/27/2026, for the final office action mailed on 10/28/2025.
Examiner’s Notes
Examiner has cited particular columns and line numbers, paragraph numbers, or figures in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant, in preparing the responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04/03/2025 has been entered.
Response to Arguments
Applicant's arguments filed 01/27/2026 have been fully considered but they are not persuasive.
Applicant argues McNamara’s resource sidecar does not read on the claimed container, see applicant’s remarks pp. 7-8. Examiner respectfully disagrees as McNamara teaches in [column 21, lines 27-36], “In an embodiment, the instant innovation uses Symmetric Endpoint Encryption. All messages are symmetrically encrypted at workload endpoints (via Sidecars), and at the SAMI Session Manager using either the ephemeral symmetric secret or session token specific to messages and endpoints. Message contents remain secret in transit and at rest, and reliance on public key infrastructure such as, by way of non-limiting example, Transport Layer Security, for encryption in transit is unnecessary, thereby reducing the amount of cryptographic key material that must be managed.
Applicant further argues De Oliviera does not teach access to first data and second data, see applicant’s remarks pp. 8. Examiner respectfully disagrees Oliveira teaches allowing access by the container to second data provided by any of the plurality of containers having the respective credentials see Oliveira paragraph [0034-0035] in which personal data (i.e., second data) is provided to the application by granting it access (i.e., allowing access by the container) to such personal data. Since the user is allowing access to their personal data to a given application/container then the personal data is being provided via to the application/container. Combined with McNamara this data can be brokered by a session manager.
Applicant's arguments filed 01/27/2026 have been fully considered but they are moot in view of new ground(s) rejection.
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.
Claim(s) 1-8 and 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over McNamara Jr. (US-PAT-NO: 11,716,312 B1) hereinafter McNamara, in further view of Peddada et al. (US-PGPUB-NO: 2023/0246845 A1) hereinafter Peddada and de Oliveira et al. (US-PGPUB-NO: 2017/0169249 A1) hereinafter de Oliveira.
As per claim 1, McNamara teaches a method for a secured deployment of plurality of containers in one or more edge servers, the method comprising: retrieving, by the secure element manager, a secret identifier from a secure element, the secure element manager encrypting the secret identifier with the second version of the ephemeral key to generate an encrypted secret identifier (see McNamara [column 37 lines 1-6], showing the Session Manager encrypting a session invitation session to the resource sidecar), retrieving, by the container, the encrypted secret identifier from the secure element manager (see McNamara [column 37, lines 1-6], showing the sidecar (i.e., container), receiving an encrypted invitation message), the container decrypting the encrypted secret identifier with the first version of the ephemeral key to generate a decrypted secret identifier(see McNamara [column 37, lines 8-11, showing the Sidecar using their ephemeral symmetric secret to decrypt the invitation message), accessing, by the container, the secure element using the decrypted secret identifier (see McNamara [column 37, lines 11-16], showing access being granted via permissions), retrieving, by the container, credentials generated by the secure element in order to connect with a message broker (see McNamara [column 37, lines 23-26], showing the sidecar responding with new alias ID to the session manager).
McNamara does not explicitly teach deploying a container of the plurality of containers in the edge server of the one or more edge servers; negotiating, by the container, with a secure element to agree on an ephemeral key, by exchanging messages containing values derived from a shared secret that was established by each of the secure element manager and the container and storing a first version of the ephemeral key in the container and a second version of the ephemeral key in the secured element manager. However, Peddada teaches deploying a container of the plurality of containers (see Peddada paragraph [0053], “To sum up, a software automation or CI/CD pipeline can compile, build, test, and deploy the source code into an environment such as production server 150”) in the edge server of the one or more edge servers (see Peddada paragraph [0099], “In current environments, data exists and is connected across multiple data centers, the edge, and public and private clouds. A data center can frequently communicate across these multiple sites, both on-premises and in the cloud”); negotiating, by the container (see Peddada paragraph [0037], “In the depicted embodiment, container 209 includes various software modules, including an ephemeral encryption key generator 222, key agreement module 224”), with a secure element to agree on an ephemeral key, by exchanging messages containing values derived from a shared secret that was established by each of the secure element manager and the container (see Peddada paragraph [0037], “Upon receiving secret 212, ephemeral encryption key generator 222 generates an ephemeral key pair composed of an ephemeral public key 225 and an ephemeral private key 223. The key pair is “ephemeral” in that it is generated specifically for secret 212 and may be used for a single execution of the establishment process for symmetric key 227. In other embodiments, keys may be reused when creating symmetric keys.”) and storing a first version of the ephemeral key in the container and a second version of the ephemeral key in the secured element manager (see Peddada paragraph [0038], “Key agreement module 224 utilizes ephemeral private key 223 and a data center public key 235 to generate symmetric key 227”).
McNamara and Peddada are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify McNamara’s teaching a platform for optimizing secure communication with Peddada’s teaching of a secret protection during software development life cycle to incorporate generating a third value based on a first and second key in order to create stronger security amongst communication between entities and apply the teaching of McNamara for deployment of container onto an edge server to provide a more secure communication between the container and server.
McNamara modified with Peddada do not explicitly teach connecting, by the container using credentials, with a message broker, such that the container provides first data and allows access via the message broker to the first data by any of the plurality of containers having respective credentials for connecting with the message broker, and/or such that the message broker allows access by the container to second data provided by any of the plurality of containers having the respective credentials. However, de Oliveira teaches connecting, by the container using credentials, with a message broker, such that the container provides first data and allows access via the message broker to the first data by any of the plurality of containers having respective credentials for connecting with the message broker, and/or such that the message broker allows access by the container to second data provided by any of the plurality of containers having the respective credentials (see de Oliveira paragraph [0034], “In some implementations, the application marketplace 106 enables users to browse applications that operate using the cloud-platform of the present disclosure. In some examples, the application marketplace 106 can be provided by the provider of the cloud-platform. In some examples, the application marketplace 106 can be provided as a third-party application marketplace (e.g., an “App Store”). In some implementations, applications from the application marketplace 106 declare (e.g., in a catalog broker) the data schema (scope) to which they require access (e.g., the OAuth scope that the application requires). Accordingly, and before interacting with and granting access to personal data, the user 130 is able to determine, which personal data the application would be granted access to”).
McNamara, Peddada and de Oliveira are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify McNamara’s teaching a platform for optimizing secure communication and Peddada’s teaching of a secret protection during software development life cycle with de Oliveira’s teaching of end user control of personal data in the cloud to incorporate the use of an access token to grant container access in the cloud system in order to secure personal data from misuse, hacking and other situations that may damage end-user trust.
As per claim 2, McNamara modified with Peddada and de Oliveira teaches wherein the container provides a policy identifier to the secure element manager that interrogates the secure element with the policy identifier, wherein the secure element generates the secret identifier based on a policy identified by the policy identifier (see McNamara [column 37, lines 8-22], showing session parameter, permissions and constraints being used on each session).
As per claim 3, McNamara modified with Peddada and de Oliveira teaches wherein said policy specifies operation rules that define conditions to perform operations on the secure element (see McNamara [column 37, lines 8-22], showing session parameter, permissions and constraints being used on each session).
As per claim 4, McNamara modified with Peddada and de Oliveira teaches wherein said policy further specifies a set of access rules that defines conditions to access the secure element (see McNamara [column 37, lines 8-22], showing session parameter, permissions and constraints being used on each session) and the secret identifier is not generated by the secure element if at least one access rule is not satisfied by the secure element (see McNamara [column 37, lines 37-41], showing the client sidecar rejecting session conditions and closing the session (i.e., not generating a secret identifier).
As per claim 5, McNamara modified with Peddada and de Oliveira teaches wherein the policy is associated with metadata and the secret identifier is not generated by the secure element if the metadata do not satisfy at least one metadata rule of a set of metadata rules that defines conditions to access the secure element and that is implemented by the secure element (see McNamara [column 21, lines 4-12], showing the use of metadata in order to do identity proofing and reinforcing the initial identity, using pattern analysis to reveal anomalous session transaction. Pattern mismatches produces security alerts to operators).
As per claim 6, McNamara modified with Peddada and de Oliveira teaches wherein the secure element manager further generates a role identifier associated with the secret identifier that is retrieved by the container and used by the container with the decrypted secret identifier for accessing the secure element (see McNamara [column 39, lines 37-49], showing a Machine ID used which includes role and successful decryption of the session).
As per claim 7, McNamara modified with Peddada and de Oliveira teaches wherein the role identifier is not encrypted (see McNamara [column 34, lines 42-55], showing the Machine ID and Machine Alias ID are not encrypted but correlate to encrypted correlated IDs for the Machine ID and the Machine Alias ID).
As per claim 8, McNamara modified with Peddada and de Oliveira teaches wherein the secure element sends the generated role identifier and secret identifier to the secure element manager via a secured session (see McNamara [column 34-55], showing the correlated IDs and Machine ID are obtained during a limited time session).
As per claim 9, McNamara modified with Peddada and de Oliveira teaches use of random number generators (see McNamara [column 16, lines 44-50], showing use of random number generator as a key for the encryption). McNamara modified with Peddada and de Oliveira teaches wherein the negotiation between the container and the secure element manager includes the following steps: the container sending a first message containing a first value derived from a first random secret to the secure element manager, receiving a second message containing a second value derived from a second random secret from the secure element manager, and computing the ephemeral key as a function of a third value derived from the second value and the first random secret (see Peddada paragraph [0041], “Package generator 228 encapsulates information such as encrypted secret 229, metadata 215, and ephemeral public key 225 in a package, and then generates a cryptographic hash of the bytes in the package to produce cryptographic hash 238, which is then sent to the signature generator 237. Signature generator 237 uses signing private key 234 to sign cryptographic hash 238, thus creating package signature 239. Package signature 239 is sent back to package generator 228, which appends the signature to the package that was hashed, and returns the result as signed package 214. (References to “signing a package” herein should be understood to referring to signing a hash of the contents of such a package.)”).
As per claim 10, McNamara modified with Peddada and de Oliveira teaches wherein the secure element manager encrypts the secret identifier with the ephemeral key based on a symmetric encryption algorithm (see McNamara [column 21, lines 27-36], showing the use of Symmetric Endpoint Encryption).
As per claim 11, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the non-transitory claim to method claim 1. Therefore, it is rejected for the same reasons as above.
Claim(s) 13 is rejected under 35 U.S.C. 103 as being unpatentable over McNamara (US-PAT-NO: 11,716,312 B1), Peddada (US-PGPUB-NO: 2023/0246845 A1) and Oliveira (US-PGPUB-NO: 2017/0169249 A1), in further view of Le Saint et al. (US-PGPUB-NO: 20210258162 A1) hereinafter Le Saint.
As per claim 13, McNamara modified with Peddada and Oliveira do not explicitly teach wherein the shared secret was established by: each of the secure element manager and the container independently selecting respective information; each of the secure element manager and the container modifying the respective selected information using a negotiated process; each of the secure element manager and the container exchanging the respective information that it modified over a secure channel; and each of the secure element manager and the container using the respective information that it modified and the information that it received by the exchange over the secure channel. However, Le Saint teaches wherein the shared secret was established by: each of the secure element manager and the container independently selecting respective information (see Le Saint paragraph [0176], “User device 1002 may provide the ephemeral mobile public key (ePubM) to a server computer 1004. The server computer may use the ephemeral mobile public key (ePubM) and a server private key (PrivS) to generate a shared secret (Z.sup.0) using an elliptic curve Diffie-Hellman function (ECDH)”); each of the secure element manager and the container modifying the respective selected information using a negotiated process (see Le Saint paragraph [0176], “The shared secret may be known by both the user device and the server computer at both ends of the secure channel. The shared secret can be based on server negotiated parameters, algorithm, and/or server certificate choices. In some embodiments, the shared secret (Z.sup.0) can include the the second (response) shared secret discussed herein. The shared secret be used to produce a new recurring shared secret (Z.sup.n or Next Z) for each subsequent transaction. In some embodiments, the next shared secret can be derived using a negotiated key derivation function (e.g., AES) with static known but randomized, obfuscated, or white-box crypto protected parameters.”); each of the secure element manager and the container exchanging the respective information that it modified over a secure channel (see Le Saint paragraph [0176], “User device 1002 may provide the ephemeral mobile public key (ePubM) to a server computer 1004”) and (see Le Saint [0178], “For example, the encrypted response data can include the encrypted server certificate (CertS*) and encrypted data (Data*). The data (e.g., key derivation parameters) may be obfuscated using the random configuration before being encrypted”); and each of the secure element manager and the container using the respective information that it modified and the information that it received by the exchange over the secure channel (see Le Saint FIG. 10, Server Computer 1004 using the ePubM data exchanged from the User Device 1002 and the User Device 1002 using the DataCertS exchanged from the Server Computer 1004).
McNamara, Peddada, Oliveira and Le Saint are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify McNamara’s teaching a platform for optimizing secure communication, Peddada’s teaching of a secret protection during software development life cycle and Oliveira’s teaching of end user control of personal data in the cloud with Le Saint’s teaching of efficient method for securely generating a cryptogram to incorporate exchanging information using a negotiated algorithm so both ends are using secure channels to exchange information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Le Saint et al. (US-PAT-NO: 10,389,533 B2) teaches a method for secure cryptogram generation.
Todd et al. (US-PGPUB-NO: 2022/0138325 A1) teaches secure enclave pathing configuration for data confidence fabrics.
Agrawal et al. (US-PGPUB-NO: 2012/0036362 A1) teaches secret-key exchange for wireless and sensor networks.
Akiona et al. (US-PGPUB-NO: 2022/0206772 A1) teaches scalable, robust, and secure multi-tenant edge architecture for mission-critical applications.
Nix (US-PGPUB-NO: 2022/0209944 A1) teaches secure server digital signature generation for post-quantum cryptography key encapsulation.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST.
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, Bradley Teets can be reached on (571) 272-3338. 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.
/LENIN PAULINO/Examiner, Art Unit 2197 /BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197