DETAILED ACTION
Response to Arguments
Applicant's arguments ("REMARKS") filed 22 November 2025 have been fully considered, and they are 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. §112
The rejection to claims 1-20 under 35 U.S.C. §112(b) has been withdrawn in view of the amendments indicated on p.7 of the REMARKS.
Re: Claim Rejections Under 35 U.S.C. §103
Applicant’s amendment and arguments, indicated on pp.7-8 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”) and Yuan et al., US 2024/0411909 A1 (hereinafter, “Yuan ‘909”) have been fully considered, and they are persuasive as to the previous grounds of rejection. In particular, with respect to the independent claims, Applicant argues that neither Barton ‘794 nor Yuan ‘909 discloses the limitation “building an artifact to identify a software supply chain”, as amended.
Barton ‘794 is directed to enterprise mobility management involving secure containers (i.e., data vaults) for managed applications on mobile devices, with policy-driven encryption and decryption of data. Yuan ‘909 is directed to container data protection using helper containers for encryption and decryption key management. Neither reference addresses software supply chain identification, artifact building for supply chain traceability, or related concepts such as software bills of materials (SBOM), build provenance, or supply chain security frameworks. Accordingly, 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 Adams et al., US 2020/0026510 A1 (hereinafter “Adams ‘510”).
Adams ‘510 discloses building metadata artifacts to provide ‘full visibility into software supply chain (e.g., plan, develop, compile, build, scan, test, deploy, release, run)’ (Adams ‘510, ¶28). In Adams ‘510, each software tool creates a metadata artifact in response to a software development lifecycle event, including a software build (Adams ‘510, ¶¶5, 50, 70-71). These artifacts contain information such as an artifact name, an artifact hash, a reference ID of the creating tool, and a ‘list of supply chain references’ (Adams ‘510, ¶50). Adams ‘510 further discloses that ‘most running software is assembled from a number of separate components usually involving application code, third party libraries, and run time dependencies,’ and that ‘understanding the origin and use of these components, where and which versions are used, and where they were sourced is required to be able to fully support a piece of software’ (Adams ‘510, ¶30). Each software tool supplies ‘a list of references to elements from the supply chain that it has leveraged’ (Adams ‘510, ¶57). Adams ‘510 also discusses repositories ‘containing full Virtual Machine Images and more latterly container images’ (Adams ‘510, ¶35), placing Adams ‘510 within the container-based technology domain.
Thus, Adams ‘510 discloses “building an artifact to identify a software supply chain” as recited in the amended claims. The metadata artifacts of Adams ‘510 are built/created during each phase of the software development lifecycle (including the build phase), and the express purpose of building these artifacts is to identify and trace the software supply chain (i.e., to understand the origin, composition, and provenance of software components).
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. 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).
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 … retrieving the software container … retrieve the encrypted data container to be used to execute the software container …”.
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]) …
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. 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 ...”.
Adams ‘510, however, discloses:
... building an artifact to identify a software supply chain (software tools create metadata artifacts for software development lifecycle events, including a software build, where the metadata artifacts are created to provide full visibility into the software supply chain (e.g., plan, develop, compile, build, scan, test, deploy, release, run), and where each software tool supplies a list of references to elements from the supply chain that it has leveraged; further, the metadata artifacts include an artifact name, an artifact hash, a reference ID, and a list of supply chain references [Adams ‘510, ¶¶5, 28-30, 50, 57, 70-71]) ...
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. 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).
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. 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
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-Thursday 9:00am-7: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, 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
/THEODORE C PARSONS/Primary Examiner, Art Unit 2494