DETAILED ACTION
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 19 May 2026 has been entered.
Response to Arguments
Applicant’s arguments and amendments (“REMARKS”) filed 19 May 2026 have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Claims 1, 11, and 20 were amended. Claims 1, 11, and 20 are independent. Claims 1-20 are currently pending.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendments and arguments, indicated on pp.8-9 of the REMARKS, in response to the rejection of the claims under 35 U.S.C. §103 with respect to Barton et al., US 2014/0108794 A1 (hereinafter, “Barton ‘794”), Yuan et al., US 2024/0411909 A1 (hereinafter, “Yuan ‘909”), and Adams et al., US 2020/0026510 A1 (hereinafter “Adams ‘510”) have been fully considered, and they are partially persuasive as to the previous grounds of rejection.
Specifically, with respect to the independent claims, Applicant argues that the combination of Barton ‘794, Yuan ‘909, and Adams ‘510 fails to disclose the limitations “building an artifact to identify a software supply chain implementing a scanning engine to implement one or more of the artifact, component data, and software bill of materials (“SBOM”) data … the software container formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data”, as amended in the independent claims.
While the amendments appear to overcome the previous citations to the references, the Examiner finds that the newly added limitations are disclosed by newly cited portions of Adams ‘510, where Adams ‘510 is already a reference of record. Adams ‘510 was previously relied upon in the Final Rejection to disclose “… building an artifact to identify a software supply chain …”. Adams ‘510 further discloses the subject matter added by Applicant’s amendment. Thus, Applicant’s arguments and amendments have necessitated new ground(s) of rejection presented in this Office Action. A new ground of rejection has been asserted over newly cited portions of Adams ‘510.
With respect to the recited “scanning engine”, Adams ‘510 discloses that the tools used across the phases of the software supply chain, which include a scan phase, are linked to provide full visibility into the software supply chain (Adams ‘510, ¶28). Adams ‘510 further discloses that scan process artifacts may include quality scan results, security scan results, and risk scan results (Adams ‘510, ¶29), and that each software tool creates a metadata artifact in response to software development lifecycle events, including the completion of a test or scan (Adams ‘510, ¶¶50, 70-71). Accordingly, Adams ‘510 discloses a “scanning engine” that builds an artifact identifying the software supply chain.
With respect to the recited “component data”, Adams ‘510 discloses that most running software is assembled from a number of separate components, such as application code, third-party libraries, and run-time dependencies, and that the origin of those components is tracked (Adams ‘510, ¶30). Adams ‘510 further discloses that software artifacts may include code, binaries, libraries, and packages (Adams ‘510, ¶31), and that compile process artifacts may include dependency information (Adams ‘510, ¶29).
With respect to the recited “software bill of materials (“SBOM”) data”, Adams ‘510 discloses that the recordable artifacts created by the software tools include large data artifacts such as a build bill of materials and scan results (Adams ‘510, ¶55), and that each software tool supplies a list of references to the elements of the supply chain that it has leveraged (Adams ‘510, ¶57). A build bill of materials listing the elements from which software is built, together with a list of supply chain references, corresponds to the “software bill of materials (“SBOM”) data”.
With respect to “the software container formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data”, Adams ‘510 discloses that the components and code used to build it can be identified (Adams ‘510, ¶32), that build process artifacts may include build definitions and package signatures (Adams ‘510, ¶29), and that the recorded artifacts are used to verify that software has followed the correct creation process and has met appropriate quality and security levels before deployment (Adams ‘510, ¶¶42-43). Yuan ‘909, on the other hand, discloses that containers may be stored as images from which new active instances are instantiated (Yuan ‘909, ¶28), and that the application container 321 is provided from a docker image (Yuan ‘909, ¶¶6, 59). Thus, the combination of Barton ‘794, Yuan ‘909, and Adams ‘510 discloses a software container that is formed based on the artifacts and component data recorded in the software supply chain.
The Examiner further notes that the amended claims recite “one or more of the artifact, component data, and software bill of materials (“SBOM”) data”. Because Adams ‘510 teaches each of the listed items, as explained above, the limitation is met regardless of whether it is interpreted as requiring any one of the listed items or at least one of each.
See Claim Rejections – 35 USC §103 below for further details.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-11, 16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Barton et al., US 2014/0108794 A1 (hereinafter, “Barton ‘794”), in view of Yuan et al., US 2024/0411909 A1 (hereinafter, “Yuan ‘909”), and further in view of Adams et al., US 2020/0026510 A1 (hereinafter “Adams ‘510”).
As per claim 1: Barton ‘794 discloses:
A method, comprising: identifying an input to a software (identifying data that is input/used/read or output/generated/written by a managed application 610, where the managed application 610 is wrapped using a secure application wrapper 520 [Barton ‘794, ¶¶74, 124-126, 141, 152; Figs.6-8]);
storing the input and the output in a data container (storing data into secure container, also referred to as data vault, where the data is input/used/read or output/generated/written by a managed application 610 [Barton ‘794, ¶¶74, 116, 124, 152, 161; Figs.6-7]), the data container being configured to be stored in a storage volume, the storage volume also being configured to store the software (a managed partition of memory 510 configured to store secure containers and the managed applications [Barton ‘794, ¶¶70, 74; Fig.5]);
determining a state associated with the data container (determining configurations for the secure container based on policy information, where the configuration comprises encryption policies, read/write policies, data sharing policies, etc. (i.e., a “state”) [Barton ‘794, ¶¶6, 123-129, 145]);
encrypting the data container using a key to generate an encrypted data container (encrypting the secure container using a key [Barton ‘794, ¶¶93, 116, 119, 128]); and
retrieving the software (identifying and accessing the managed application and the corresponding encrypted secure container [Barton ‘794, ¶¶49, 69, 136, 145, 189-190]), a version being determined by the state (determining identifying data associated with the corresponding secure container, such as resource identifiers or container identifiers, based on the configurations indicated in the policy information [Barton ‘794, ¶¶145, 152, 176, 180, 197]), when a query is received from a platform to retrieve the encrypted data container to be used to execute the software (receiving a user request from a mobile device platform 502 to access data within an encrypted secure container, where the data is used by the managed application during execution [Barton ‘794, ¶¶6, 69, 74, 136, 145, 189]),
As stated above, while Barton ‘794 discloses managed applications, where the managed applications are wrapped using a secure application wrapper, the wrapped managed applications are not explicitly disclosed to be “software containers”. While ‘application containers’ are disclosed in Barton ‘794 (see Barton ‘794, ¶¶95, 107), the disclosed ‘application containers’ are not disclosed within the context of wrapped managed applications. Specifically, Barton ‘794 does not explicitly disclose the limitations: “… identifying an input to a software container and an output generated by the software container … configured to store the software container … building an artifact to identify a software supply chain implementing a scanning engine to implement one or more of the artifact, component data, and software bill of materials (“SBOM”) data … retrieving the software container … retrieve the encrypted data container to be used to execute the software container … the software container formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data”.
Yuan ‘909, however, discloses:
… identifying an input to a software container and an output generated by the software container (implementing application containers 321, where inputs and outputs associated with the application containers 321 are identified and stored in separate containers 322, 323 [Yuan ‘909, ¶¶36-37, 42, 49-50; Figs.3-5]) … configured to store the software container (the application container 321 and containers 322, 323 are implemented by the container engine 320 and stored within the memory of host device 310 [Yuan ‘909, ¶¶36, 60, 68; Fig.3])
…
… retrieving the software container … retrieve the encrypted data container to be used to execute the software container (identifying and retrieving the application container 321 and containers 322, 323, where the application container is executed using the data within containers 322, 323 [Yuan ‘909, ¶¶37, 40-41, 47, 67; Figs.3-4]) … the software container (the application container 321 is a virtualized computing environment that is stored as an image, such as a docker image of the application container 321, where a new active instance of the application container 321 is instantiated from the image [Yuan ‘909, ¶¶6, 28, 59; Fig.3]).
Barton ‘794 and Yuan ‘909, are analogous art because they are from the same field of endeavor, namely that of using secure containers to protect data during execution by associated software. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 and Yuan ‘909 before them, to modify the method in Barton ‘794 to include the teachings of Yuan ‘909, namely to implement the managed applications of Barton ‘794, which are wrapped using a secure wrapper, to be secure applications containers, as disclosed in Yuan ‘909, where the secure application containers are stored as, and instantiated from, corresponding container images. A motivation for doing so would be to further increase the protection of data executed by software by implementing a secure software container for managing and executing the corresponding software (see Yuan ‘909, ¶¶2, 36-37).
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “... building an artifact to identify a software supply chain implementing a scanning engine to implement one or more of the artifact, component data, and software bill of materials (“SBOM”) data ... the software container formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data.”
Adams ‘510, however, discloses:
... building an artifact to identify a software supply chain implementing a scanning engine to implement one or more of the artifact, component data, and software bill of materials (“SBOM”) data (software tools create metadata artifacts for software development lifecycle events, including a software build and the completion of a test or scan, where the metadata artifacts provide full visibility into the software supply chain (e.g., plan, develop, compile, build, scan, test, deploy, release, run); the scan tools of the supply chain generate scan process artifacts comprising quality, security, and risk scan results (i.e., a “scanning engine”); the recordable artifacts include a build bill of materials and scan results (i.e., “SBOM data”); and software is assembled from separate components comprising application code, third party libraries, and run time dependencies, whose origins, versions, and sources are traced (i.e., “component data”) [Adams ‘510, ¶¶5, 28-31, 50, 55, 57, 70-71]) ...
... the software container formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data (identifying, for a piece of running software, the components and code used to build it, where build process artifacts comprise build definitions and package signatures, and where the traceability records are used at deployment time to verify that the software followed the correct creation process and met appropriate quality and security levels [Adams ‘510, ¶¶29-32, 42-43]).
Barton ‘794 (modified by Yuan ‘909) and Adams ‘510, are analogous art because they are from the same field of endeavor, namely that of managing and securing software during the software development lifecycle. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909) and Adams ‘510 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909) to include the teachings of Adams ‘510, namely to build a metadata artifact that identifies elements of the software supply chain, as disclosed in Adams ‘510, for the managed applications and secure containers of Barton ‘794 (modified by Yuan ‘909), where the metadata artifact is built by the scan tools of the software supply chain and comprises scan results, a build bill of materials, and component data identifying the components, libraries, and dependencies of the software; and further to form the software container of Barton ‘794 (modified by Yuan ‘909) based on the artifact, component data, and build bill of materials identified by the software supply chain, as disclosed in Adams ‘510. A motivation for doing so would be to provide traceability throughout the software lifecycle from software development to software deployment, and to enable the identification of the origins and composition of software components, including where and which versions are used and where they were sourced, in order to fully support and secure the software (see Adams ‘510, ¶¶3, 27-28, 30, 42-43).
As per claim 2: Barton ‘794 in view of Yuan ‘909, and further in view of Adama ‘510 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Furthermore, Barton ‘794 discloses:
further comprising continually validating data integrity of the data container (secure container features comprise a logging feature, where all security events are logged and reported to the backend, and where data wiping may be triggered if data tampering is detected [Barton ‘794, ¶94]).
As per claim 3: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 3 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the data container is read write (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write) [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]).
As per claim 4: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 4 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the storage volume comprises a virtual storage device (a managed partition of memory 510 configured to store secure containers and the managed applications, where partitions may be virtual partitions of a virtual storage device [Barton ‘794, ¶¶43, 50, 70, 74; Fig.5]).
As per claim 5: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 5 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the storage volume comprises a physical storage device (a managed partition of memory 510 configured to store secure containers and the managed applications, where partitions may be physical partitions of a physical storage device [Barton ‘794, ¶¶69-70, 74; Fig.5]).
As per claim 6: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 6 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the storage volume comprises a storage appliance (a managed partition of memory 510 configured to store secure containers and the managed applications, where partitions may be physical partitions of a physical storage device, such as a physical memory of a mobile device [Barton ‘794, ¶¶69-70, 74; Fig.5])
As per claim 7: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 7 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the storage volume comprises a storage service (a managed partition of memory 510 configured to store secure containers and the managed applications, where storage partitions may be part of a service [Barton ‘794, ¶¶63, 66-67, 69-70, 78; Fig.5])
As per claim 8: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 8 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the encrypted data container is used to run the software container on a device using a secure runtime environment (receiving a user request from a mobile device platform 502 to access data within an encrypted secure container, where the data is used by the managed application during execution in a secure environment [Barton ‘794, ¶¶6, 70, 74, 189, 197]).
As per claim 9: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 9 is dependent upon. Furthermore, Barton ‘794 discloses:
further comprising selecting the version of the encrypted data container when the query is received (receiving a user request from a mobile device platform 502 to access data within an encrypted secure container, where the data is used by the managed application during execution, and where identifying data associated with the corresponding secure container is determined, such as resource identifiers or container identifiers, based on the configurations indicated in the policy information [Barton ‘794, ¶¶6, 69, 74, 136, 145, 152, 176, 189, 197]).
As per claim 10: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 1, as stated above, from which claim 10 is dependent upon. Furthermore, Barton ‘794 discloses:
further comprising selecting the version of the encrypted data container when the query is received (receiving a user request from a mobile device platform 502 to access data within an encrypted secure container, where the data is used by the managed application during execution, and where the encrypted data container is corresponds to a managed application based on a specific identifier [Barton ‘794, ¶¶6, 69, 74, 123, 136, 145, 180, 189]), the state being used to determine the version to be retrieved and returned in response to the query (determining identifying data associated with the corresponding secure container, such as resource identifiers or container identifiers, based on the configurations indicated in the policy information [Barton ‘794, ¶¶145, 152, 176, 180, 197]).
As per claim 11: Claim 11 defines a system that recites substantially similar subject matter as the method of claim 1. Specifically, claim 11 is directed to a system comprising a processor and storage volume configured to store a software container, a data container, and an encrypted data container, where the processor is configured to perform the method of claim 1, including to build an artifact to identify a software supply chain implementing a scanning engine to implement one or more of the artifact, component data, and software bill of materials (“SBOM”), and where the software container is formed based on one or more of the artifact, component data, and software bill of materials (“SBOM”) data. Thus, the rejection of claim 1 is equally applicable to claim 11.
As per claim 16: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 16 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the output is generated by an application run by the software (identifying data that is input/used/read or output/generated/written by a managed application 610, where the managed application 610 is wrapped using a secure application wrapper 520; storing data into secure container, also referred to as data vault, where the data is input/used/read or output/generated/written by a managed application 610 [Barton ‘794, ¶¶74, 116, 124-126, 141, 152, 161; Figs.6-8]) is run in the container runtime using the input and the output unpacked from the encrypted data container (receiving a user request from a mobile device platform 502 to access data within an encrypted secure container, where the data is used by the managed application during execution [Barton ‘794, ¶¶6, 69, 74, 136, 145, 189]).
As stated above, Barton ‘794 does not explicitly disclose the limitation: “… an application run by the software container when the software container …”.
Yuan ‘909, however, discloses:
… an application run by the software container when the software container (implementing application containers 321, where inputs and outputs associated with the application containers 321 are identified and stored in separate containers 322, 323; identifying and retrieving the application container 321 and containers 322, 323, where the application container is executed using the data within containers 322, 323 [Yuan ‘909, ¶¶36-37, 40-42, 47, 49-50, 67; Figs.3-5]) …
Barton ‘794 (modified by Adams ‘510) and Yuan ‘909, are analogous art because they are from the same field of endeavor, namely that of using secure containers to protect data during execution by associated software. For the reasons stated in claim 1, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Adams ‘510) and Yuan ‘909 before them, to modify the method in Barton ‘794 (modified by Adams ‘510) to include the teachings of Yuan ‘909.
As per claim 18: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 18 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the encrypted data container comprises an operation type, the operation type being read write (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write) [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]).
As per claim 19: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 19 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the data container comprises an operation type, the operation type being read write (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write) [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]).
As per claim 20: Claim 20 defines a non-transitory computer readable medium that recites substantially similar subject matter as the method of claim 1. Specifically, claim 20 is directed to a non-transitory computer readable medium having one or more computer program instructions configured to perform the method of claim 1. Thus, the rejection of claim 1 is equally applicable to claim 20.
Claims 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Barton ‘794, in view of Yuan ‘909, and further in view of Adams ’510, and further in view Smith, IV et al., US 2020/0192689 A1 (hereinafter, “Smith ‘689”).
As per claim 12: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 12 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the data container comprises an operation type, the operation type being a (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]).
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “… operation type being a copy-on-write operation type …”.
Smith ‘689, however, discloses:
… operation type being a copy-on-write operation type (a method of copying and migrating containers, where the method comprises creating a copy of the container using a copy-on-write operation to perform synchronization between containers when data differences occur in containers when they are modified [Smith ‘689, ¶¶Abstract, 11, 51, 54-55]) …
Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689, are analogous art because they are from the same field of endeavor, namely that of managing data within secure containers. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) to include the teachings of Smith ‘689, namely to modify the policy information of Barton ‘794 such that it comprises container configurations which indicate a copy-on-write policy, as disclosed in Smith ‘689, where a copy of the associated container is generated when data differences due to data modification is detected. A motivation for doing so would be to maintain the integrity and consistency of data within a container by using copy-on-write operations to perform synchronization operations when data differences are detected (see Smith ‘689, ¶¶6-11).
As per claim 13: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 13 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the data container comprises an operation type, the operation type being a (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]),
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “… operation type being a copy-on-write operation type, the copy-on-write operation type being further configured to generate a copy of the data container to be stored in the storage volume when the data container is modified …”.
Smith ‘689, however, discloses:
… operation type being a copy-on-write operation type, the copy-on-write operation type being further configured to generate a copy of the data container to be stored in the storage volume when the data container is modified (a method of copying and migrating containers, where the method comprises creating a copy of the container using a copy-on-write operation to perform synchronization between containers when data differences occur in containers when they are modified [Smith ‘689, ¶¶Abstract, 11, 51, 54-55]) …
Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689, are analogous art because they are from the same field of endeavor, namely that of managing data within secure containers. For the reasons stated in claim 12, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) to include the teachings of Smith ‘689.
As per claim 14: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 14 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the encrypted data container comprises an operation type, the operation type being a (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write) [Barton ‘794, ¶¶6, 74, 123-129, 141, 145]).
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “… operation type being a copy-on-write operation type …”.
Smith ‘689, however, discloses:
… operation type being a copy-on-write operation type (a method of copying and migrating containers, where the method comprises creating a copy of the container using a copy-on-write operation to perform synchronization between containers when data differences occur in containers when they are modified [Smith ‘689, ¶¶Abstract, 11, 51, 54-55]) …
Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689, are analogous art because they are from the same field of endeavor, namely that of managing data within secure containers. For the reasons stated in claim 12, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) to include the teachings of Smith ‘689.
As per claim 15: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 15 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the encrypted data container comprises an operation type, the operation type being a (determining configurations for the container based on policy information, where the container may be encrypted or unencrypted based on the policy information (or mode), and where the configuration comprises operation types such as read/write [Barton ‘794, ¶¶6, 74, 123-129, 141, 145])
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “… operation type being a copy-on-write operation type, the copy-on-write operation type being further configured to generate a copy of the … data container to be stored in the storage volume when the data container is modified …”.
Smith ‘689, however, discloses:
… operation type being a copy-on-write operation type, the copy-on-write operation type being further configured to generate a copy of the … data container to be stored in the storage volume when the data container is modified (a method of copying and migrating containers, where the method comprises creating a copy of the container using a copy-on-write operation to perform synchronization between containers when data differences occur in containers when they are modified [Smith ‘689, ¶¶Abstract, 11, 51, 54-55]) …
Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689, are analogous art because they are from the same field of endeavor, namely that of managing data within secure containers. For the reasons stated in claim 12, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Smith ‘689 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) to include the teachings of Smith ‘689.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Barton ‘794, in view of Yuan ‘909, and further in view of Adams ‘510, and further in view Jayanthi et al., US 10,732,951 B1 (hereinafter, “Jayanthi ‘951”).
As per claim 17: Barton ‘794 in view of Yuan ‘909, and further in view of Adams ‘510 discloses all limitations of claim 11, as stated above, from which claim 15 is dependent upon. Furthermore, Barton ‘794 discloses:
wherein the storage volume is configured to tag the data container and the encrypted data container with metadata identifying the (a data vault, which may be encrypted or unencrypted based on mode and policy information, can be considered a logical interface into which any or all persistent data read/written by a mobile application will be redirected, where the vault may comprise metadata associated with data stored within the vault (name, size, access times, etc.) [Barton ‘794, ¶¶116-118, 124-128])
As stated above, Barton ‘794 in view of Yuan ‘909 does not explicitly disclose the limitation: “… container with metadata identifying the state.”
Jayanthi ‘951, however, discloses:
… container with metadata identifying the state (Each of the container images may be associated with respective metadata, where metadata may include data about or otherwise associated with a container image. Examples of the respective metadata may include respective application types of the container images; respective application versions of the container images; respective application vendors of the container images; respective generation dates of the container images; respective last access dates of the container images; respective encryption status of the container images; respective compression status of the container images; and respective copyright information of the container images [Jayanthi ‘951, Col.4 lines 29-40]).
Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Jayanthi ‘951, are analogous art because they are from the same field of endeavor, namely that of managing data within secure containers. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) and Jayanthi ‘951 before them, to modify the method in Barton ‘794 (modified by Yuan ‘909 and Adams ‘510) to include the teachings of Jayanthi ‘951, namely to modify the container metadata of Barton ‘794 such that the metadata comprises other types of policy information associated with the container, where the other types of policy information comprises state information such as respective encryption status of the container images; respective compression status of the container images; and respective copyright information of the container images, etc., as disclosed in Jayanthi ‘951. A motivation for doing so would be to use tagged container metadata information to better facilitate the identification, deployment, and management of a plurality of containers (see Jayanthi ‘951, Col.1 line 29-Col.2 line 22).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Kalinichenko et al., US 20190251278 A1: The second server generates the software containers by executing the application software module in separate processes and storing each of the encrypted data sets in a separate container. Client computing devices authenticate to the second server to access a software container.
Yankovskiy et al., US 20210103664 A1: dynamically allocating encrypted storage for containers/applications in a containerized environment. In various aspects, one is able to specify the amount of encrypted storage desired/required in a storage/host volume to be allocated to a container on-demand.
Seewald et al., US 20200057863 A1: enable scalable and secure data retrieval between microservices by using microservice attributes to encrypt container-based data stores.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Friday 9:00am-5:30pm 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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/Examiner, Art Unit 2494
/KAVEH ABRISHAMKAR/Primary Examiner, Art Unit 2494
Prosecution Insights