Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for 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 that, in preparing responses, the applicant fully consider the references cited in their 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.
Drawings
Replacement Sheets for the Drawings were received on December 2, 2024. The Replacement Sheets have been entered and the Drawings are accepted by the Examiner.
Claim Objections
Claim 8 is objected to for reciting the acronym “OCI” without previously indicating the full meaning of the term. Applicant is reminded an acronym should be written in full the first time it is used to particularly point out and distinctly claim the invention. For clarity of the record, the Examiner has interpreted “OCI” to mean “Open Container Initiative (OCI)”.
Appropriate correction is required.
Claim 11 is objected to because of the following informalities:
In line 7, “a storage volume” is unclear if it is referring to the storage volume previously recited in claim 11, line 2 or a different storage volume. If it is referring to the same storage volume, it should be amended to recite “the storage volume”. If it is referring to a different storage volume, a modifier should be added to clarify, e.g. “a second storage volume”.
In line 7, “the storage” is unclear whether it is referring to the storage volume previously recited in claim 11, line 2, or in claim 11, line 7.
Claim 14 is objected to because of the following informalities:
In lines 1-2 “an application” is unclear if it is referring to the application previously recited in claim 11 or a different application. If it is referring to the same application, it should be amended to recite “the application”. If it is referring to a different application, a modifier should be added to clarify, e.g. “a second application”.
In line 2, “the application” is unclear whether it is referring to the application previously recited in claim 11, or “an application” previously recited in claim 14.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 13 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 13 recites the limitation "the software container" in line 2. There is insufficient antecedent basis for this limitation in the claim.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-7 and 9-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 3, 4-7, 9-11, 13, 16-17, and 19-20 of copending Application No. 18/740,466 in view of Knierim (U.S. Pub. No. 2024/0386091). The claims of the instant application and the claims of the reference application are compared in Table 1 below, with differences between the claims in bold. Unless indicated otherwise, the claims of the instant application have been compared to the claim of the same number in the reference application.
Regarding claims 1, 11 and 20 of the instant application, claims 1, 11 and 20 of the reference application recite limitations which, though not identical, are not patentably distinct from limitations of the instant claims, differing only in an “application” as recited by the instant claims vs. a “software container” as recited in the reference claims. However, Knierim teaches an application may be implemented within a software container ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0065] – “the application program is executed in at least one container on a container runtime environment of a host computer”).
It would have been obvious to one of ordinary skill in the art to have modified the application recited by the claims of the instant application to be implemented within a software container as recited by the claims of the reference application as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003] and [0065]).
Claims 2, 4-7, 9-10, 12, 16-19 recite additional limitations that are substantially the same or identical to the limitations recited in claims 3, 4-7, 9-10, 13, 16-17, and 19 of the reference application as indicated in Table 1 and are rejected as well.
Regarding claim 3 of the instant application, claim 1 of the reference application as modified in view of Knierim teaches all the limitations, including “wherein the application is containerized in a software container”. Specifically, Knierim teaches wherein the application is containerized in a software container (see Knierim: [0003], [0065]). For the same reasons presented above with respect to claim 1, it would have been obvious to one of ordinary skill in the art to use a software container which containerizes the application, i.e., to provide isolation to the application software executing within the container and improve security (see Knierim: [0003] and [0065]).
Regarding claims 13 and 14 of the instant application, claim 16 of the reference application, as modified in view of Knierim with respect to claim 11, fails to teach “the input is configured to be received” by the application fails to teach “the software container is mounted and executed in the runtime environment”. However, Knierim further teaches “the input is configured to be received” by the application ([0080] – “Inputs and outputs of an application program executed in the secondary container 19 can be redirected to the process mounted in the main container 18 using the container runtime environment 13 and input/output redirects.”) and “the software container is mounted and executed in the runtime environment” ([0007] – “Containers or their processes are assigned execution privileges when the container instance is started. To avoid successful attacks from being carried out, these application execution rights can be minimized so that the container is only assigned the rights required to operate the application. Conventionally, read-only mounts are permitted to minimize execution rights, or a mandatory access control is set up for file systems”; [0079] – “The file system therefore remains in the main container 18, e.g. set to read-only, and can be mounted in the secondary container 19 for writing”).
It would have been obvious to one of ordinary skill in the art to have modified the reference claims such that the input is received by the application run by the software container and that the software container is mounted in the runtime environment as taught by Knierim. Setting the access privileges of the software container such that an application in the software container is able to receive its input and mounting the software container in the runtime environment according to the methods of Knierim would provide for improved security and isolation of the application (see Knierim: [0003], [0023], and [0065]).
Claim 15 of the instant application similarly differs from claim 16 of the reference application as modified in view of Knierim as applied to claim 11 in that the reference claim fails to recite the software container being mounted in the container runtime. For the same reasons presented with respect to instant claims 13 and 14 above, it would have been obvious to modify the software container of reference claim 16 to be mounted in a container runtime as taught by Knierim (see Knierim: [0007] and [0079]), where mounting the software container in the runtime environment according to the methods of Knierim would provide for improved security and isolation of the application (see Knierim: [0003], [0023], and [0065]).
This is a provisional nonstatutory double patenting rejection.
Claim 8 is provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/740,466 in view of Knierim (U.S. Pub. No. 2024/0386091) and further in view of Church et al. (U.S. Pub. No. 2018/0088935), hereinafter Church. The claims of the instant application and the claims of the reference application are compared in Table 1 below, with differences between the claims in bold. Unless indicated otherwise, the claims of the instant application have been compared to the claim of the same number in the reference application.
Regarding claim 8 of the instant application, claim 1 of the reference application as modified in view of Knierim fails to teach “storing the data container in an OCI standards-based container registry”. However, Church teaches “storing the data container in an OCI standards-based container registry” ([0025] – “software packages that are implemented using software containers may be stored in software registry 170 using container images, which may include all components and dependencies required to run a particular software package in a software container. A container image may be a file format used to package the components and dependencies of a containerized software package, such as Docker container images, Open Container Initiative (OCI) based images, and/or any other container image format.”; [0047] – “software containers (e.g., Docker containers, Open Container Initiative (OCI) based containers, and/or any other software container implementation)”; [0051]-[0054] and [0063]– an application (e.g., a WordPress container) may require an SQL database container for storing data, which may be obtained from the container registry/repository; [0082] – “container images may be hosted by a software registry (e.g., software registries 170 of FIG. 1 or 270 of FIG. 2B) to provide a central repository for distributing container images to software developers. Examples of container images include Docker container images, container images based on the Open Container Initiative (OCI), and/or any other container image format. The Open Container Initiative (OCI), for example, is a collaborative effort by the software industry to develop an open, vendor-neutral, and portable implementation of software containers, to ensure that compliant software containers are portable across all major operating systems and platforms that are also compliant. The OCI implementation is based on the implementation of Docker containers.”).
It would have been obvious to one of ordinary skill in the art to have modified the reference claims to include storing the data container in an OCI standards-based container registry as taught by Church. Using an OCI standards-based container registry would facilitate software development and distribution, as well as runtime-based application configuration (see Church: [0024], [0054], [0060]-[0061], and [0082]).
This is a provisional nonstatutory double patenting rejection.
Table 1: Claim comparison of the instant application with reference application 18/740,466
Claim
18/740,458 (instant)
18/740,466 (reference)
1
A method, comprising:
identifying an input to an application and an output generated by the application;
storing the input and the output in a data container, the data container being configured to be stored in a storage volume, the storage volume also being configured to store the application;
determining a state associated with the data container; and
retrieving the application and a version of the data container, the version being
determined by the state, when a query is received from a platform to retrieve the
application and to execute the application in a runtime environment.
A method, comprising:
identifying an input to a software container and an output generated by the software container;
storing the input and the output in a data container, the data container being configured to be stored in a storage volume, the storage volume also being configured to store the software container;
determining a state associated with the data 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;
encrypting the data container using a key to generate an encrypted data container; and
retrieving the software container and the encrypted data container, a version being determined by the state, when a query is received from a platform to retrieve the encrypted data container to be used to execute the software container in a container runtime, the software container formed based on one or more of the artifact, component data, and software bill of materials ("SBOM") data.
2
The method of claim 1, wherein the data container is read-write.
See claim 3: The method of claim 1, wherein the data container is read write.
3
The method of claim 1, wherein the application is containerized in a software container.
See claim 1
4
The method of claim 1, wherein the storage volume comprises a virtual storage device.
The method of claim 1, wherein the storage volume comprises a virtual storage device.
5
The method of claim 1, wherein the storage volume comprises a physical storage device.
The method of claim 1, wherein the storage volume comprises a physical storage device.
6
The method of claim 1, wherein the storage volume comprises a storage appliance.
The method of claim 1, wherein the storage volume comprises a storage appliance.
7
The method of claim 1, wherein the storage volume comprises a storage service.
The method of claim 1, wherein the storage volume comprises a storage service.
8
The method of claim 1, further comprising storing the data container in an OCI standards-based container registry.
See claim 1
9
The method of claim 1, further comprising selecting the version of the data container when the query is received.
The method of claim 1, further comprising selecting the version of the encrypted
data container when the query is received.
10
The method of claim 1, further comprising selecting the version of the data container when the query is received, the state being used to determine the version to be retrieved and returned in response to the query.
The method of claim 1, further comprising selecting the version of the encrypted data container when the query is received, the state being used to determine the version to be retrieved and returned in response to the query.
11
A system, comprising:
a storage volume configured to store an application and a data container, the data container being configured to store an input and an output generated by the application when executed in a runtime environment; and
a processor configured to identify the input to the application and the output generated by the application,
to store the input and the output in the data container, the data container being configured to be stored in a storage volume, the storage volume also being configured to store the application,
to determine a state associated with the data container, and
to retrieve the application and a version of the data container, the version being determined by the state, when a query is received from a platform to retrieve the application and to execute the application in the runtime environment.
A system, comprising:
a storage volume configured to store a software container, a data container, and an encrypted data container, the data container and the encrypted data container being configured to store an input and an output to be used with the software container; and
a processor configured to identify an input to the software container and an output generated by the software container,
to store the input and the output in the data container, the data container being configured to be stored in the storage volume, the storage volume also being configured to store the software container,
to determine a state associated with the data container, 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") data, to encrypt the data container using a key to generate an encrypted data container,
to retrieve the software container and the encrypted data container, a version being determined by the state, when a query is received from a platform to retrieve the encrypted data container to be used to execute the software container in a container runtime, the software container formed based on one or more of the artifact, component data, and software bill of materials ("SBOM") data.
12
The system of claim 11, wherein the data container comprises an operation type, the 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.
See claim 13: The system of claim 11, wherein the data container comprises an operation type, the 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.
13
The system of claim 11, wherein the input is configured to be received by the application at runtime when the software container is mounted and executed in the runtime environment.
See claim 16: The system of claim 11, wherein the output is generated by an application run by the software container when the software container is run in the container runtime using the input and the output unpacked from the encrypted data container.
14
The system of claim 11, wherein the input is configured to be received by an application being executed when a software container containerizing the application is mounted and executed in the runtime environment.
See claim 16: The system of claim 11, wherein the output is generated by an application run by the software container when the software container is run in the container runtime using the input and the output unpacked from the encrypted data container.
15
The system of claim 11, wherein the output is generated by the application when the application is stored in a software container, the software container being mounted and executed in a container runtime.
See claim 16: The system of claim 11, wherein the output is generated by an application run by the software container when the software container is run in the container runtime using the input and the output unpacked from the encrypted data container.
16
The system of claim 11, wherein the output is generated by the application, the application being stored in a software container.
The system of claim 11, wherein the output is generated by an application run by the software container when the software container is run in the container runtime using the input and the output unpacked from the encrypted data container.
17
The system of claim 11, wherein the storage volume is configured to tag the data container with metadata identifying the state.
The system of claim 11, wherein the storage volume is configured to tag the data container and the encrypted data container with metadata identifying the state.
18
The system of claim 11, wherein the data container comprises an operation type.
See claim 19: The system of claim 11, wherein the data container comprises an operation type, the operation type being read write.
19
The system of claim 11, wherein the data container comprises an operation type, the operation type being read write.
The system of claim 11, wherein the data container comprises an operation type,
the operation type being read write.
20
A non-transitory computer readable medium having one or more computer program instructions configured to perform a method, the method comprising:
identifying an input to an application and an output generated by the application;
storing the input and the output in a data container, the data container being configured to be stored in a storage volume, the storage volume also being configured to store the application;
determining a state associated with the data container; and
retrieving the application and a version of the data container, the version being determined by the state, when a query is received from a platform to retrieve the application and to execute the application in a runtime environment.
A non-transitory computer readable medium having one or more computer program instructions configured to perform a method, the method comprising:
identifying an input to a software container and an output generated by the software container;
storing the input and the output in a data container, the data container being configured to be stored in a storage volume, the storage volume also being configured to store the software container;
determining a state associated with the data 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;
encrypting the data container using a key to generate an encrypted data container; and
retrieving the software container and the encrypted data container, a version being
determined by the state, when a query is received from a platform to retrieve the encrypted data container to be used to execute the software container in a container runtime, the software container formed based on one or more of the artifact, component data, and software bill of materials ("SBOM") data.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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-2, 4-7, 9-11, and 18-20 are rejected under 35 U.S.C. 102(a)(1) and (a)(2) as being anticipated by Barton et al. (U.S. Pub. No. 2014/0108794), hereinafter Barton.
Regarding claim 1, Barton teaches A method, comprising:
identifying an input to an application and an output generated by the application (identifying data that is read/used (“input”) or written/generated (“output”) by a managed application 610: FIG 6-8; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0124]-[0126] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy. Depending on settings or definitions specified by the policies, managed applications can be constrained to exchange files and/or data only with other applications within the set of managed application 610. For example, API calls from the application specifying file reads or writes can be intercepted by injected code of the application or the "wrapping" of the application. The policy for that application may be read, and the read or write operation specified is diverted to an encrypted vault (e.g., the private vault or the shared vault), depending on the settings in the policy (or the absence of settings in the policy). In various embodiments, code injected into the application or code "wrapping" the application may intercept API calls made by an application. Based on the intercepted API call, the policy for the application may be consulted, and the API call may be blocked, allowed, redirected further based on the policy. […] the above process can be applied for moving files into and/or out of a protected data vault, as described herein. Essentially, any operation used to move data into and/or out of an application can make use of the above technique.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”);
storing the input and the output in a data container (storing data into a secure container (also referred to as data vault) where the data is read/used (“input”) or written/generated (“output”) by a managed application 610: Figs.6-7; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0116] – “As illustrated in FIGS. 5 and 6, various embodiments described herein provide an encrypted data vault (also referred variously herein as a secure container, container, data vault, vault or private data vault) for use with, for example, one or more managed applications of a mobile device. An encrypted data vault can be considered a logical interface into which any or all persistent data read/written by a mobile application (which would otherwise end up in a writeable file in the app sandbox) will be redirected.”; [0124] – “Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”; [0161] – “At step 809, the mobile device may store the data, which is now encrypted, within a container (e.g., the container specified by the policy, as determined in step 803), such as those illustrated in any of FIGS. 5-7 (e.g., container 528 of FIG. 5, the app private data vaults or shared data vaults of FIG. 6, and vaults 715, 720 of FIG. 7).”), the data container being configured to be stored in a storage volume, the storage volume also being configured to store the application (a managed partition 510 of memory (“storage volume”) is configured to store the secure containers and the managed applications 610 (corresponding to secure native apps 514 shown in FIG. 5, as managed apps may be wrapped with wrapper 520, see [0087] and [0174]): Fig. 5; [0070] – “The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition)”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522, and the like. The data stored in the secure data container 528 may include files, databases, and the like. The data stored in the secure data container 528 may include data restricted to a specific secure application 530, shared among secure applications 532, and the like.”);
determining a state associated with the data container (determining configuration(s) (“state”(s)) for the secure container(s) based on the application’s policy, where the configuration comprises encryption policies, read/write policies, data sharing policies, etc.: [0006] – “Data stored in a secure container may be encrypted according to a policy.”; [0123] – “Applications written with this awareness can utilize any number of data vaults, which they can identify explicitly with vault name identifiers or resource names. However applications will not always be written with such awareness. Correspondingly, the policies can be used to configure a default data vault for each application. The default data vault of an application is used for the transparent redirection of all application file I/O”; [0124] – “Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application”; [0125] – “settings or definitions specified by the policies, […] The policy for that application may be read, and the read or write operation specified is diverted to an encrypted vault (e.g., the private vault or the shared vault), depending on the settings in the policy”; [0127] – “managed applications can be assigned to different groups. In such cases, policies may include records of groups and group members. The flow of files and/or data between applications can thus be further restricted to members of particular groups. For example, each group may be provided with its own shared vault.”; [0128] – “Applications may be assigned to a default vault as dictated by policy. In some variations, applications that share the same group may inherit the same default data vault”; [0129] – “if policy does not dictate that an application is configured into a shared group or dictate a default vault for the application, then all data may be redirected to the application's corresponding private vault (private vaults as illustrated in FIG. 6). However if an application were configured into a shared group, data may be redirected to the shared vault. Even when some data is redirected to the shared vault, Particular data types, such as data designated for special private directories like /tmp, would continue to flow to the application's private vault.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions […] the container can be configured to be accessed only by applications that are authorized to access the container. As one example, the access manager can enable managed applications installed on the mobile device to access data stored in the container and to prevent unmanaged applications from accessing the data stored in the container.”; [0179] – “the mobile device may configure one or more secure containers. For example, one or more secure containers may be defined by the policy for the managed application. In some instances, the policy may include a definition of a private container (e.g., an app private data vault as illustrated in FIG. 6) and/or a shared container (e.g., a shared data vault as illustrated in FIG. 6). Based on the policy, the mobile device may determine whether the containers have been properly created and configured on the mobile device“); and
retrieving the application and a version of the data container (identifying and accessing the managed application and its corresponding secure container: [0049] – “a first server 106a that receives requests from a client machine 240 First server 106a may acquire an enumeration of applications available to the client machine 240 […]. First server 106a can then present a response to the client's request using a web interface, and communicate directly with the client 240 to provide the client 240 with access to an identified application.”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502 […] The enterprise may choose to implement policies to manage the mobile device 504. […] The policies may be mobile device management policies, mobile application management policies, mobile data management policies, or some combination”; [0136]-[0137] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user. […] Based on those policies, the application management framework that is delivered with the managed application may configure itself (e.g., with the client agent's assistance). For example, one or more default vaults may be selected for use and the policy-aware interception layer may be configured to target the selected vaults.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, (1) which application or other component of the mobile device is requesting access […] whether the requesting application or other component provides a correct certificate or credentials, (6) whether the user of the mobile device provides correct credentials, (8) other conditions, or any combination thereof. A user's credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like. Hence, by using the access manager, the container can be configured to be accessed only by applications that are authorized to access the container. As one example, the access manager can enable managed applications installed on the mobile device to access data stored in the container”; [0189] – “After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device.”; [0190] – “authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”), the version being determined by the state (determining the data identifying the corresponding secure container, such as a resource identifier or container identifier (“version”), based on the configuration (“state”) indicated in the policy: [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as […] (4) geographical position of the mobile device […] Hence, by using the access manager, the container can be configured to be accessed only by applications that are authorized to access the container”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”; [0155] – “the policy may specify multiple containers that can be used by the application when needing to store data. For example, a managed application may store to a first container when at a particular geographic location (or other first criteria) but to a second container when at a different geographic location (or other second, but different, criteria).”; [0176] – “The policies included in the policy information that was obtained at step 1003 may define what secure containers are to be used as well as their resource names or identifiers”; [0180] – “the policy-aware interception layer may be configured with information linking the identifiers or resource identifiers for the secure containers to one or more API calls that will be issued by the application during execution and may be configured with the locations of the keys that will be used when encrypting/decrypting data to/from the application. In such a way, the policy-aware interception layer may intercept such calls and redirect the calls to the appropriate secure container in accordance with the policy and without the application being aware of the interception (see, e.g. FIG. 7)”; [0197] – “The policy information may include one or more secure container identifiers that will be used in connection with reading/writing or otherwise processing data when the application is executed by the mobile device. The secure containers may be, for example, an identifier for a private data vault and/or a shared data vault.”), when a query is received from a platform to retrieve the application and to execute the application in a runtime environment (receiving a user request (“query”) from a mobile device 502 (“platform”) to access data within a secure container, where the data is used by the managed application during execution (i.e., at “runtime”), where the runtime environment is the infrastructure (hardware/software) that supports execution of the application (e.g., the hardware/software of the mobile device on which the app executes): [0006] – “each managed application may be assigned its own private data vault and/or may be assigned a shared data vault that is accessible to at least one other managed application. As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers.”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522,The secure applications may have a dual-mode option 540. The dual mode option 540 may present the user with an option to operate the secured application in an unsecured or unmanaged mode”; [0136] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, […], (6) whether the user of the mobile device provides correct credentials […] A user' s credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like.”; [0189]-[0190] – “when a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device. […] At step 1101, the mobile device may transmit a message in connection with authenticating a user, application or mobile device with an access gateway. For example, the message may be in connection with an initial authentication process that authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”).
Regarding claim 2, Barton teaches The method of claim 1. Barton further teaches wherein the data container is read-write ([0006]-[0007] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers. […] intercepting a read or write operation from a managed application executing on the mobile device; accessing, based on the read or write operation, a secure container that is a logical interface into which read or write operations are redirected”).
Regarding claim 4, Barton teaches The method of claim 1. Barton further teaches wherein the storage volume comprises a virtual storage device (managed partition 510 of memory (“storage volume”) is configured to store secure containers and the managed applications, where partitions may be virtual partitions of memory (“virtual storage device”): Fig. 5; [0070] – “The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] as used herein, a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition).”; [0043] – “client machine 240 may be a virtual machine”; [0050] and [0059] – “Each virtual machine 332 may include a virtual disk 32 6A-C (generally 326) and a virtual processor 32 8A-C (generally 328.) The virtual disk 326, in some embodiments, is a virtualized view of one or more physical disks 304 of the virtualization server 301, or a portion of one or more physical disks 304 of the virtualization server 301”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device”).
Regarding claim 5, Barton teaches The method of claim 1. Barton further teaches wherein the storage volume comprises a physical storage device (managed partition 510 of memory (“storage volume”) is configured to store secure containers and the managed applications, where partitions may be physical partitions of physical memory (“physical storage device”): Fig. 5; [0070] – “The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] as used herein, a partition may refer to a physically partitioned portion of memory (physical partition)”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0053] – “Physical memory 316 in the hardware layer 310 may include any type of memory. Physical memory 316 may store data, and in some embodiments may store one or more programs, or set of executable instructions.”).
Regarding claim 6, Barton teaches The method of claim 1. Barton further teaches wherein the storage volume comprises a storage appliance (a managed partition 510 (“storage volume”) of memory is configured to store secure containers and the managed applications, where partitions may be physical partitions of a physical memory, such as a physical memory of a mobile device (“storage appliance”): Fig. 5; [0069]-[0070] – “The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] as used herein, a partition may refer to a physically partitioned portion of memory (physical partition)”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”).
Regarding claim 7, Barton teaches The method of claim 1. Barton further teaches wherein the storage volume comprises a storage service (data vault services are used to access, e.g., read and write, to the secure container storing data for the app, thus providing a “storage service”, wherein the services are part of the application/wrapper of the applications, which are in the managed partition (“storage volume”): FIG. 5; [0069]-[0070] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502 […] The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition).”; [0131]-[0132] – “Enterprises may create (or adapt) their native mobile applications using tools and SDKs associated with the enterprise mobility management solution they have chosen to deploy. In preparing their app for deployment, they certainly have the freedom to (re)write specific application logic to utilize encrypted data vault services exposed by the SDK as needed for their application. However, in some embodiments, an application may be used with standard file system APIs of the platform for which the applications were originally developed. As such, the application's file access services may be redirected to one or more data vaults dictated by policy rather than rewriting their application.”; [0133] – “When taking the policy-driven approach, the application developer need not worry about the specifics of how to interface with the private vault services. Instead, by integrating the header files, libraries, and run-time support of the framework code with the application, all file system APIs called by the application may be intercepted by a policy-aware interception layer that, in some embodiments, forms a part of the managed application. For example, the policy-aware interception layer may be formed by framework or wrapper code that is included in the application.”; [0139] – “When the data vault is private to the application, the data vault services layer may directly use the mobile platform's file I/O functions to read and write encrypted version of the data.”).
Regarding claim 9, Barton teaches The method of claim 1. Barton teaches the method further comprising selecting the version of the data container when the query is received (receiving a user request (“query”) from a mobile device 502 to access data within a secure container (also referred to as a data vault), where the data is used by the managed application during execution, and where the secure container corresponds to a managed application based on a specific resource/container identifier (“version”) in the policy for the application retrieved in response to the user request: [0006] – “each managed application may be assigned its own private data vault and/or may be assigned a shared data vault that is accessible to at least one other managed application. As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522,The secure applications may have a dual-mode option 540. The dual mode option 540 may present the user with an option to operate the secured application in an unsecured or unmanaged mode”; [0123] – “Applications written with this awareness can utilize any number of data vaults, which they can identify explicitly with vault name identifiers or resource names. However applications will not always be written with such awareness. Correspondingly, the policies can be used to configure a default data vault for each application. The default data vault of an application is used for the transparent redirection of all application file I/O”; [0136]-[0137] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user […] Based on those policies, the application management framework that is delivered with the managed application may configure itself (e.g., with the client agent's assistance). For example, one or more default vaults may be selected for use and the policy-aware interception layer may be configured to target the selected vaults.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, […], (6) whether the user of the mobile device provides correct credentials […] A user' s credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like.”; [0176] – “The policies included in the policy information that was obtained at step 1003 may define what secure containers are to be used as well as their resource names or identifiers”; [0179] – “the mobile device may configure one or more secure containers. For example, one or more secure containers may be defined by the policy for the managed application. In some instances, the policy may include a definition of a private container (e.g., an app private data vault as illustrated in FIG. 6) and/or a shared container (e.g., a shared data vault as illustrated in FIG. 6). Based on the policy, the mobile device may determine whether the containers have been properly created and configured on the mobile device“; [0180] – “the policy-aware interception layer may be configured with information linking the identifiers or resource identifiers for the secure containers to one or more API calls that will be issued by the application during execution and may be configured with the locations of the keys that will be used when encrypting/decrypting data to/from the application. In such a way, the policy-aware interception layer may intercept such calls and redirect the calls to the appropriate secure container in accordance with the policy and without the application being aware of the interception (see, e.g. FIG. 7)”; [0189]-[0190] – “when a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device. […] At step 1101, the mobile device may transmit a message in connection with authenticating a user, application or mobile device with an access gateway. For example, the message may be in connection with an initial authentication process that authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”; [0197] – “The policy information may include one or more secure container identifiers that will be used in connection with reading/writing or otherwise processing data when the application is executed by the mobile device.”).
Regarding claim 10, Barton teaches The method of claim 1. Barton teaches the method further comprising selecting the version of the data container when the query is received, the state being used to determine the version to be retrieved and returned in response to the query (receiving a user request (“query”) from a mobile device 502 to access data within a secure container (also referred to as a data vault), where the data is used by the managed application during execution, and where the secure container corresponds to a managed application based on a specific resource/container identifier (“version”) in the policy for the application retrieved in response to the user request, where the policy indicates a configuration (“state”) for the secure container: [0006] – “each managed application may be assigned its own private data vault and/or may be assigned a shared data vault that is accessible to at least one other managed application. As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522,The secure applications may have a dual-mode option 540. The dual mode option 540 may present the user with an option to operate the secured application in an unsecured or unmanaged mode”; [0123] – “Applications written with this awareness can utilize any number of data vaults, which they can identify explicitly with vault name identifiers or resource names. However applications will not always be written with such awareness. Correspondingly, the policies can be used to configure a default data vault for each application. The default data vault of an application is used for the transparent redirection of all application file I/O”; [0136]-[0137] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user […] Based on those policies, the application management framework that is delivered with the managed application may configure itself (e.g., with the client agent's assistance). For example, one or more default vaults may be selected for use and the policy-aware interception layer may be configured to target the selected vaults.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, […], (6) whether the user of the mobile device provides correct credentials […] A user' s credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like.”; [0176] – “The policies included in the policy information that was obtained at step 1003 may define what secure containers are to be used as well as their resource names or identifiers”; [0179] – “the mobile device may configure one or more secure containers. For example, one or more secure containers may be defined by the policy for the managed application. In some instances, the policy may include a definition of a private container (e.g., an app private data vault as illustrated in FIG. 6) and/or a shared container (e.g., a shared data vault as illustrated in FIG. 6). Based on the policy, the mobile device may determine whether the containers have been properly created and configured on the mobile device“; [0180] – “the policy-aware interception layer may be configured with information linking the identifiers or resource identifiers for the secure containers to one or more API calls that will be issued by the application during execution and may be configured with the locations of the keys that will be used when encrypting/decrypting data to/from the application. In such a way, the policy-aware interception layer may intercept such calls and redirect the calls to the appropriate secure container in accordance with the policy and without the application being aware of the interception (see, e.g. FIG. 7)”; [0189]-[0190] – “when a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device. […] At step 1101, the mobile device may transmit a message in connection with authenticating a user, application or mobile device with an access gateway. For example, the message may be in connection with an initial authentication process that authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”; [0197] – “The policy information may include one or more secure container identifiers that will be used in connection with reading/writing or otherwise processing data when the application is executed by the mobile device.”).
Regarding claim 11, Barton teaches A system, comprising:
a storage volume configured to store an application and a data container (a managed partition 510 of memory (“storage volume”) is configured to store the secure containers, also referred to as data vaults, and the managed applications 610 (corresponding to secure native apps 514 shown in FIG. 5, as managed apps may be wrapped with wrapper 520, see [0087] and [0174]): Fig. 5; [0070] – “The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition)”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522, and the like. The data stored in the secure data container 528 may include files, databases, and the like. The data stored in the secure data container 528 may include data restricted to a specific secure application 530, shared among secure applications 532, and the like.”), the data container being configured to store an input and an output generated by the application when executed in a runtime environment (storing data into a secure container (also referred to as data vault) where the data is read/used (“input”) or written/generated (“output”) by a managed application 610 during execution (i.e., at “runtime”), where the runtime environment is the infrastructure (hardware/software) that supports execution of the application (e.g., the hardware/software of the mobile device on which the app executes: Figs.6-7; [0006] – “each managed application may be assigned its own private data vault and/or may be assigned a shared data vault that is accessible to at least one other managed application. As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers.”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0116] – “As illustrated in FIGS. 5 and 6, various embodiments described herein provide an encrypted data vault (also referred variously herein as a secure container, container, data vault, vault or private data vault) for use with, for example, one or more managed applications of a mobile device. An encrypted data vault can be considered a logical interface into which any or all persistent data read/written by a mobile application (which would otherwise end up in a writeable file in the app sandbox) will be redirected.”; [0124] – “Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”; [0161] – “At step 809, the mobile device may store the data, which is now encrypted, within a container (e.g., the container specified by the policy, as determined in step 803), such as those illustrated in any of FIGS. 5-7 (e.g., container 528 of FIG. 5, the app private data vaults or shared data vaults of FIG. 6, and vaults 715, 720 of FIG. 7)”.); and
a processor (processor 203; [0035] – “One or more aspects may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein. […] executed by a processor in a computer or other device”) configured to identify the input to the application and the output generated by the application (identifying data that is read/used (“input”) or written/generated (“output”) by a managed application 610: FIG 6-8; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0124]-[0126] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy. Depending on settings or definitions specified by the policies, managed applications can be constrained to exchange files and/or data only with other applications within the set of managed application 610. For example, API calls from the application specifying file reads or writes can be intercepted by injected code of the application or the "wrapping" of the application. The policy for that application may be read, and the read or write operation specified is diverted to an encrypted vault (e.g., the private vault or the shared vault), depending on the settings in the policy (or the absence of settings in the policy). In various embodiments, code injected into the application or code "wrapping" the application may intercept API calls made by an application. Based on the intercepted API call, the policy for the application may be consulted, and the API call may be blocked, allowed, redirected further based on the policy. […] the above process can be applied for moving files into and/or out of a protected data vault, as described herein. Essentially, any operation used to move data into and/or out of an application can make use of the above technique.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”), to store the input and the output in the data container (storing data into a secure container (also referred to as data vault) where the data is read/used (“input”) or written/generated (“output”) by a managed application 610: Figs.6-7; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device.”; [0116] – “As illustrated in FIGS. 5 and 6, various embodiments described herein provide an encrypted data vault (also referred variously herein as a secure container, container, data vault, vault or private data vault) for use with, for example, one or more managed applications of a mobile device. An encrypted data vault can be considered a logical interface into which any or all persistent data read/written by a mobile application (which would otherwise end up in a writeable file in the app sandbox) will be redirected.”; [0124] – “Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”; [0161] – “At step 809, the mobile device may store the data, which is now encrypted, within a container (e.g., the container specified by the policy, as determined in step 803), such as those illustrated in any of FIGS. 5-7 (e.g., container 528 of FIG. 5, the app private data vaults or shared data vaults of FIG. 6, and vaults 715, 720 of FIG. 7).”), the data container being configured to be stored in a storage volume, the storage volume also being configured to store the application (a managed partition 510 of memory (“storage volume”) is configured to store the secure containers and the managed applications 610 (corresponding to secure native apps 514 shown in FIG. 5, as managed apps may be wrapped with wrapper 520, see [0087] and [0174]): Fig. 5; [0070] – “The operating system of the mobile device may be separated into a managed partition 510 and an unmanaged partition 512. The managed partition 510 may have policies applied to it to secure the applications running on and data stored in the managed partition. The applications running on the managed partition may be secure applications. […] a partition may refer to a physically partitioned portion of memory (physical partition), a logically partitioned portion of memory (logical partition), and/or a virtual partition created as a result of enforcement of one or more policies and/or policy files across multiple apps as described herein (virtual partition)”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522, and the like. The data stored in the secure data container 528 may include files, databases, and the like. The data stored in the secure data container 528 may include data restricted to a specific secure application 530, shared among secure applications 532, and the like.”), to determine a state associated with the data container (determining configuration(s) (“state”(s)) for the secure container(s) based on the application’s policy, where the configuration comprises encryption policies, read/write policies, data sharing policies, etc.: [0006] – “Data stored in a secure container may be encrypted according to a policy.”; [0123] – “Applications written with this awareness can utilize any number of data vaults, which they can identify explicitly with vault name identifiers or resource names. However applications will not always be written with such awareness. Correspondingly, the policies can be used to configure a default data vault for each application. The default data vault of an application is used for the transparent redirection of all application file I/O”; [0124] – “Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application”; [0125] – “settings or definitions specified by the policies, […] The policy for that application may be read, and the read or write operation specified is diverted to an encrypted vault (e.g., the private vault or the shared vault), depending on the settings in the policy”; [0127] – “managed applications can be assigned to different groups. In such cases, policies may include records of groups and group members. The flow of files and/or data between applications can thus be further restricted to members of particular groups. For example, each group may be provided with its own shared vault.”; [0128] – “Applications may be assigned to a default vault as dictated by policy. In some variations, applications that share the same group may inherit the same default data vault”; [0129] – “if policy does not dictate that an application is configured into a shared group or dictate a default vault for the application, then all data may be redirected to the application's corresponding private vault (private vaults as illustrated in FIG. 6). However if an application were configured into a shared group, data may be redirected to the shared vault. Even when some data is redirected to the shared vault, Particular data types, such as data designated for special private directories like /tmp, would continue to flow to the application's private vault.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions […] the container can be configured to be accessed only by applications that are authorized to access the container. As one example, the access manager can enable managed applications installed on the mobile device to access data stored in the container and to prevent unmanaged applications from accessing the data stored in the container.”; [0179] – “the mobile device may configure one or more secure containers. For example, one or more secure containers may be defined by the policy for the managed application. In some instances, the policy may include a definition of a private container (e.g., an app private data vault as illustrated in FIG. 6) and/or a shared container (e.g., a shared data vault as illustrated in FIG. 6). Based on the policy, the mobile device may determine whether the containers have been properly created and configured on the mobile device“), and to retrieve the application and a version of the data container (identifying and accessing the managed application and its corresponding secure container: [0049] – “a first server 106a that receives requests from a client machine 240 First server 106a may acquire an enumeration of applications available to the client machine 240 […]. First server 106a can then present a response to the client's request using a web interface, and communicate directly with the client 240 to provide the client 240 with access to an identified application.”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502 […] The enterprise may choose to implement policies to manage the mobile device 504. […] The policies may be mobile device management policies, mobile application management policies, mobile data management policies, or some combination”; [0136]-[0137] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user. […] Based on those policies, the application management framework that is delivered with the managed application may configure itself (e.g., with the client agent's assistance). For example, one or more default vaults may be selected for use and the policy-aware interception layer may be configured to target the selected vaults.”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, (1) which application or other component of the mobile device is requesting access […] whether the requesting application or other component provides a correct certificate or credentials, (6) whether the user of the mobile device provides correct credentials, (8) other conditions, or any combination thereof. A user's credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like. Hence, by using the access manager, the container can be configured to be accessed only by applications that are authorized to access the container. As one example, the access manager can enable managed applications installed on the mobile device to access data stored in the container”; [0189] – “After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device.”; [0190] – “authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”), the version being determined by the state (determining the data identifying the corresponding secure container, such as a resource identifier or container identifier (“version”), based on the configuration (“state”) indicated in the policy: [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as […] (4) geographical position of the mobile device […] Hence, by using the access manager, the container can be configured to be accessed only by applications that are authorized to access the container”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container.”; [0155] – “the policy may specify multiple containers that can be used by the application when needing to store data. For example, a managed application may store to a first container when at a particular geographic location (or other first criteria) but to a second container when at a different geographic location (or other second, but different, criteria).”; [0176] – “The policies included in the policy information that was obtained at step 1003 may define what secure containers are to be used as well as their resource names or identifiers”; [0180] – “the policy-aware interception layer may be configured with information linking the identifiers or resource identifiers for the secure containers to one or more API calls that will be issued by the application during execution and may be configured with the locations of the keys that will be used when encrypting/decrypting data to/from the application. In such a way, the policy-aware interception layer may intercept such calls and redirect the calls to the appropriate secure container in accordance with the policy and without the application being aware of the interception (see, e.g. FIG. 7)”; [0197] – “The policy information may include one or more secure container identifiers that will be used in connection with reading/writing or otherwise processing data when the application is executed by the mobile device. The secure containers may be, for example, an identifier for a private data vault and/or a shared data vault.”), when a query is received from a platform to retrieve the application and to execute the application in the runtime environment receiving a user request (“query”) from a mobile device 502 (“platform”) to access data within a secure container, where the data is used by the managed application during execution (i.e., at “runtime”), where the runtime environment is the infrastructure (hardware/software) that supports execution of the application (e.g., the hardware/software of the mobile device on which the app executes): [0006] – “each managed application may be assigned its own private data vault and/or may be assigned a shared data vault that is accessible to at least one other managed application. As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers.”; [0069] – “The user may access such enterprise resources 504 or enterprise services 508 using a mobile device 502”; [0074] – “The secure applications may access data stored in a secure data container 528 in the managed partition 510 of the mobile device. The data secured in the secure data container may be accessed by the secure wrapped applications 514, applications executed by a secure application launcher 522, virtualization applications 526 executed by a secure application launcher 522,The secure applications may have a dual-mode option 540. The dual mode option 540 may present the user with an option to operate the secured application in an unsecured or unmanaged mode”; [0136] – “When a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies and/or encryption and decryption keys for this specific application and user”; [0145] – “One or more policies can limit access to a container's file system based on various settings or definitions such as, for example, […], (6) whether the user of the mobile device provides correct credentials […] A user' s credentials can comprise, for example, a password, one or more answers to security questions (e.g., What is the mascot of your high school?), biometric information (e.g., fingerprint scan, eye-scan, etc.), and the like.”; [0189]-[0190] – “when a user executes a managed application on the mobile device, the user is typically challenged to authenticate their corporate identity along with passwords and other factors as dictated by corporate policy. After having strongly authenticated the user, device, and application, the access manager components of the system may verify that the user is entitled to the application and download the configured policies for this specific application and user. Keys and other data that are needed to access/provide secure containers may also be downloaded to the mobile device. […] At step 1101, the mobile device may transmit a message in connection with authenticating a user, application or mobile device with an access gateway. For example, the message may be in connection with an initial authentication process that authenticates a user prior to allowing a managed application, which is executing on a mobile device, access to enterprise resources (e.g., a message transmitted to cause the mobile device or user to log into the enterprise to access the enterprise resources). In others, the message may be in connection with authenticating the user or mobile device prior to allowing a managed application to be downloaded.”).
Regarding claim 18, Barton teaches The system of claim 11. Barton further teaches wherein the data container comprises an operation type ([0006]-[0007] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers. […] intercepting a read or write operation from a managed application executing on the mobile device; accessing, based on the read or write operation, a secure container that is a logical interface into which read or write operations are redirected”; [0123]-[0129] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read and consult the policy 706 stored by the mobile device associated with the application 705. […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written and consult the policy 706.”).
Regarding claim 19, Barton teaches The system of claim 11. Barton further teaches wherein the data container comprises an operation type, the operation type being read write ([0006]-[0007] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers. […] intercepting a read or write operation from a managed application executing on the mobile device; accessing, based on the read or write operation, a secure container that is a logical interface into which read or write operations are redirected”; [0123]-[0129] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read and consult the policy 706 stored by the mobile device associated with the application 705. […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written and consult the policy 706.”).
Regarding claim 20, Barton teaches A non-transitory computer readable medium having one or more computer program instructions configured to perform a method ([0035] – “One or more aspects may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein”; Claim 17 – “One or more non-transitory computer-readable media storing instructions configured to, when executed, cause at least one computing device to”), the method comprising: the method of claim 1.
Accordingly claim 20 is rejected as being anticipated by Barton for the same reasons presented with respect to claim 1 above.
Claim Rejections - 35 USC § 103
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 3 and 13-16 are rejected under 35 U.S.C. 103 as being unpatentable over Barton in view of Knierim (U.S. Pub. No. 2024/0386091).
Regarding claim 3, Barton teaches The method of claim 1, but fails to expressly teach wherein the application is containerized in a software container.
However, Knierim teaches wherein the application is containerized in a software container ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0065] – “To execute an application, or more precisely an application program, in a container-virtualized environment, the application program is executed in at least one container on a container runtime environment of a host computer.”).
Barton and Knierim are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton such that the application is containerized in a software container as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003] and [0065]).
Regarding claim 13, Barton teaches The system of claim 11. Barton further teaches wherein the input is configured to be received by the application at runtime (Fig. 7; [0006] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers”; [0008] – “a secure container to be used when the managed application is executing […] wherein the secure container is a logical interface into which read or write operations are redirected and in which data is in an encrypted form; intercepting a read or write operation from the managed application while the managed application is executing on the mobile device; and accessing, based on the read or write operation, the secure container”; [0141] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read and consult the policy 706 stored by the mobile device associated with the application 705. If the policy 706 specifies that the identified type of data is stored in the private data vault 715, the policy-aware interception layer 710 may obtain the data from the private data vault 715. […] The policy-aware interception layer 710 then may decrypt the data (using an encryption key, such as one obtained via the access gateway) and return the data to the application 705”).
Barton fails to teach when the software container is mounted and executed in the runtime environment.
However, Knierim teaches when the software container is mounted and executed in the runtime environment ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0005] – “In order to be able to start a container on the host system, a container image is required which also contains the binary programs and libraries required for the application software in addition to the application software, also known as the application program. A container, or more precisely a container instance, is created on the host system from the container image and executed on the runtime environment.”; [0006] – “Conventionally, container instances are operated using a runtime environment such as “Docker” on the host system”; [0007] – “Containers or their processes are assigned execution privileges when the container instance is started. To avoid successful attacks from being carried out, these application execution rights can be minimized so that the container is only assigned the rights required to operate the application. Conventionally, read-only mounts are permitted to minimize execution rights, or a mandatory access control is set up for file systems.”; [0065] – “To execute an application, or more precisely an application program, in a container-virtualized environment, the application program is executed in at least one container on a container runtime environment of a host computer.”; [0079] – “If an operation or process that is to be executed with privileges is recognized by the kernel module or an eBPF program, its execution in the main container is prevented by the privilege control unit 15, 16, if specified in the privilege rule R, or delayed if a program to be executed has been specified. The process thus remains inside the main container 18 in a waiting state. At the same time, the privilege control unit 15, 16 starts the secondary container 19 with the required privileges as specified in the rule and shares the defined shared resources 14, i.e. namespaces. If mount options, i.e. options for mounted file systems or memory areas, are to be changed, the mounts to be changed are mounted in a new mount namespace in accordance with the privilege rule R. The file system therefore remains in the main container 18, e.g. set to read-only, and can be mounted in the secondary container 19 for writing and can therefore be changed.”; [0080] – “Inputs and outputs of an application program executed in the secondary container 19 can be redirected to the process mounted in the main container 18 using the container runtime environment 13 and input/output redirects. This means that the user executing the application program can carry out operations as usual without realizing that the operation has been executed in a secondary container 19.”).
Barton and Knierim are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton such that the application is containerized in a software container that is mounted and executed in a runtime environment as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003], [0023] and [0065]).
Regarding claim 14, Barton teaches The system of claim 11. Barton further teaches wherein the input is configured to be received by an application being executed (Fig. 7; [0006] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers”; [0008] – “a secure container to be used when the managed application is executing […] wherein the secure container is a logical interface into which read or write operations are redirected and in which data is in an encrypted form; intercepting a read or write operation from the managed application while the managed application is executing on the mobile device; and accessing, based on the read or write operation, the secure container”; [0141] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read and consult the policy 706 stored by the mobile device associated with the application 705. If the policy 706 specifies that the identified type of data is stored in the private data vault 715, the policy-aware interception layer 710 may obtain the data from the private data vault 715. […] The policy-aware interception layer 710 then may decrypt the data (using an encryption key, such as one obtained via the access gateway) and return the data to the application 705”).
Barton fails to expressly teach when a software container containerizing the application is mounted and executed in the runtime environment.
However, Knierim teaches when a software container containerizing the application is mounted and executed in the runtime environment ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0005] – “In order to be able to start a container on the host system, a container image is required which also contains the binary programs and libraries required for the application software in addition to the application software, also known as the application program. A container, or more precisely a container instance, is created on the host system from the container image and executed on the runtime environment.”; [0006] – “Conventionally, container instances are operated using a runtime environment such as “Docker” on the host system”; [0007] – “Containers or their processes are assigned execution privileges when the container instance is started. To avoid successful attacks from being carried out, these application execution rights can be minimized so that the container is only assigned the rights required to operate the application. Conventionally, read-only mounts are permitted to minimize execution rights, or a mandatory access control is set up for file systems.”; [0065] – “To execute an application, or more precisely an application program, in a container-virtualized environment, the application program is executed in at least one container on a container runtime environment of a host computer.”; [0079] – “If an operation or process that is to be executed with privileges is recognized by the kernel module or an eBPF program, its execution in the main container is prevented by the privilege control unit 15, 16, if specified in the privilege rule R, or delayed if a program to be executed has been specified. The process thus remains inside the main container 18 in a waiting state. At the same time, the privilege control unit 15, 16 starts the secondary container 19 with the required privileges as specified in the rule and shares the defined shared resources 14, i.e. namespaces. If mount options, i.e. options for mounted file systems or memory areas, are to be changed, the mounts to be changed are mounted in a new mount namespace in accordance with the privilege rule R. The file system therefore remains in the main container 18, e.g. set to read-only, and can be mounted in the secondary container 19 for writing and can therefore be changed.”; [0080] – “Inputs and outputs of an application program executed in the secondary container 19 can be redirected to the process mounted in the main container 18 using the container runtime environment 13 and input/output redirects. This means that the user executing the application program can carry out operations as usual without realizing that the operation has been executed in a secondary container 19.”).
Barton and Knierim are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton such that the application is containerized in a software container that is mounted and executed in a runtime environment as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003], [0023] and [0065]).
Regarding claim 15, Barton teaches The system of claim 11. Barton further teaches wherein the output is generated by the application (Fig. 7; [0124]-[0126] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written and consult the policy 706. If the policy 706 specifies that the identified type of data is to be stored in the private data vault 715, the policy-aware interception layer 710 may encrypt the data and store the data in the private data vault 715.”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/ generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container”).
Barton fails to expressly teach when the application is stored in a software container, the software container being mounted and executed in a container runtime.
However, Knierim teaches when the application is stored in a software container, the software container being mounted and executed in a container runtime ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0005] – “In order to be able to start a container on the host system, a container image is required which also contains the binary programs and libraries required for the application software in addition to the application software, also known as the application program. A container, or more precisely a container instance, is created on the host system from the container image and executed on the runtime environment.”; [0006] – “Conventionally, container instances are operated using a runtime environment such as “Docker” on the host system”; [0007] – “Containers or their processes are assigned execution privileges when the container instance is started. To avoid successful attacks from being carried out, these application execution rights can be minimized so that the container is only assigned the rights required to operate the application. Conventionally, read-only mounts are permitted to minimize execution rights, or a mandatory access control is set up for file systems.”; [0065] – “To execute an application, or more precisely an application program, in a container-virtualized environment, the application program is executed in at least one container on a container runtime environment of a host computer.”; [0079] – “If an operation or process that is to be executed with privileges is recognized by the kernel module or an eBPF program, its execution in the main container is prevented by the privilege control unit 15, 16, if specified in the privilege rule R, or delayed if a program to be executed has been specified. The process thus remains inside the main container 18 in a waiting state. At the same time, the privilege control unit 15, 16 starts the secondary container 19 with the required privileges as specified in the rule and shares the defined shared resources 14, i.e. namespaces. If mount options, i.e. options for mounted file systems or memory areas, are to be changed, the mounts to be changed are mounted in a new mount namespace in accordance with the privilege rule R. The file system therefore remains in the main container 18, e.g. set to read-only, and can be mounted in the secondary container 19 for writing and can therefore be changed.”; [0080] – “Inputs and outputs of an application program executed in the secondary container 19 can be redirected to the process mounted in the main container 18 using the container runtime environment 13 and input/output redirects. This means that the user executing the application program can carry out operations as usual without realizing that the operation has been executed in a secondary container 19.”).
Barton and Knierim are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton such that the application is containerized in a software container that is mounted and executed in a runtime environment as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003], [0023] and [0065]).
Regarding claim 16, Barton teaches The system of claim 11. Barton further teaches wherein the output is generated by the application (Fig. 7; [0124]-[0126] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written and consult the policy 706. If the policy 706 specifies that the identified type of data is to be stored in the private data vault 715, the policy-aware interception layer 710 may encrypt the data and store the data in the private data vault 715.”; [0152] – “the managed application may be a virtualized application and the policy may specify a container that will store the data used/ generated by the virtualized application. Accordingly, as the virtualized application generates data, the data is stored to the container”).
Barton fails to expressly teach the application being stored in a software container.
However, Knierim teaches the application being stored in a software container ([0003] – “Software containers, referred to below as containers for short, therefore represent a lightweight type of virtualization of a runtime environment on a host computer, also known as a host system, and encapsulate an application operated in a container from the underlying host system.”; [0005] – “In order to be able to start a container on the host system, a container image is required which also contains the binary programs and libraries required for the application software in addition to the application software, also known as the application program. A container, or more precisely a container instance, is created on the host system from the container image and executed on the runtime environment.”; [0065] – “To execute an application, or more precisely an application program, in a container-virtualized environment, the application program is executed in at least one container on a container runtime environment of a host computer.”).
Barton and Knierim are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton such that the application is containerized in a software container as taught by Knierim. Implementing applications in software containers provides isolation of the application from the host system and from other software executing on the host system and therefore improves security of the application (see Knierim: [0003] and [0065]).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Barton in view of Church et al. (U.S. Pub. No. 2018/0088935), hereinafter Church.
Regarding claim 8, Barton teaches The method of claim 1, but fails to expressly teach further comprising storing the data container in an OCI standards-based container registry.
However, Church teaches storing the data container in an OCI standards-based container registry ([0025] – “software packages that are implemented using software containers may be stored in software registry 170 using container images, which may include all components and dependencies required to run a particular software package in a software container. A container image may be a file format used to package the components and dependencies of a containerized software package, such as Docker container images, Open Container Initiative (OCI) based images, and/or any other container image format.”; [0047] – “software containers (e.g., Docker containers, Open Container Initiative (OCI) based containers, and/or any other software container implementation)”; [0051]-[0054] and [0063]– an application (e.g., a WordPress container) may require an SQL database container for storing data, which may be obtained from the container registry/repository; [0082] – “container images may be hosted by a software registry (e.g., software registries 170 of FIG. 1 or 270 of FIG. 2B) to provide a central repository for distributing container images to software developers. Examples of container images include Docker container images, container images based on the Open Container Initiative (OCI), and/or any other container image format. The Open Container Initiative (OCI), for example, is a collaborative effort by the software industry to develop an open, vendor-neutral, and portable implementation of software containers, to ensure that compliant software containers are portable across all major operating systems and platforms that are also compliant. The OCI implementation is based on the implementation of Docker containers.”).
Barton and Church are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications using managing data of secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton to store the data container in an OCI standards-based container registry as taught by Church. Using an OCI standards-based container registry would facilitate software development and distribution, as well as runtime-based application configuration (see Church: [0024], [0054], [0060]-[0061], and [0082]).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Barton in view of Grummon et al. (U.S. Patent No. 6,341,341), hereinafter Grummon.
Regarding claim 12, Barton teaches The system of claim 11. Barton further teaches wherein the data container comprises an operation type ([0006] – “As the managed application executes, calls for access to the data may be intercepted and redirected to the secure containers”; [0008] – “a secure container to be used when the managed application is executing […] wherein the secure container is a logical interface into which read or write operations are redirected and in which data is in an encrypted form; intercepting a read or write operation from the managed application while the managed application is executing on the mobile device; and accessing, based on the read or write operation, the secure container”; [0123]-[0129] – “A policy may designate an encrypted data vault for data being processed in connection with the respective application such as, for example, data specified by read and write operations from the application. Accordingly, read and write operations to/from the application may be processed in accordance with the respective policy.”; [0141]-[0142] – “the application 705 (representative of any of the applications of the managed set 610 of FIG. 6 or any application 514 of FIG. 5) issues read operations 708 and write operations 707 to persistent space on the mobile device. Here, read and write operations are intercepted by the policy-aware interception layer 710 and directed to an appropriate encrypted vault. For read operations 708, the policy-aware interception layer 710 may inspect the type of data to be read and consult the policy 706 stored by the mobile device associated with the application 705. […] In the case of write operations 707, the policy-aware interception layer 710 may inspect the type of data to be written and consult the policy 706.”).
Barton fails to expressly teach the 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.
However, Grummon teaches the 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 (Col. 3, lines 12-15 – “a "copy-on-write" procedure where an unmodified copy of data in the read-write container is copied to a read-only backup container every time is there is a request to modify data in the read-write container”; Col. 1, lines 14-40 – “Data is stored in a volume set by filling all of the volume's partitions in one disk drive before using volume partitions in another disk drive. […] The on-line storage devices on a computer are configured from one or more disks into logical units of storage space referred to herein as "containers." Examples of containers include volume sets, stripe sets, mirror sets, and various Redundant Array of Independent Disk (RAID) implementations. A volume set comprises one or more physical partitions, i.e., collections of blocks of contiguous space on disks, and is composed of space on one or more disks. Data is stored in a volume set by filling all of the volume's partitions in one disk drive before using volume partitions in another disk drive.”).
Barton and Grummon are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely storing data of an application in a separate data container. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the teachings of Barton to incorporate the teachings of Grummon such that the data container comprises a copy-on-write operation type. Doing so would accurately maintain a snapshot of the data container and enable backup processes to access and back-up an unchanging, read-only copy of the data at the instant the snapshot was created (see Grummon: Col. 3, lines 5-19).
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Barton in view of Jayanthi et al. (U.S. Pub. No. 2018/0121485), hereinafter Jayanthi.
Regarding claim 17, Barton teaches The system of claim 11. Barton further teaches wherein the storage volume is configured to tag the data container with metadata identifying the ([0116]-[0119] – “provide an encrypted data vault (also referred variously herein as a secure container, container, data vault, vault or private data vault) for use with, for example, one or more managed applications of a mobile device. An encrypted data vault can be considered a logical interface into which any or all persistent data read/written by a mobile application (which would otherwise end up in a writeable file in the app sandbox) will be redirected. The contents of the vault may themselves be written into file(s) held inside an app sandbox. The contents of all files and the file metadata itself (name, size, access times, etc.) may be all encrypted. […] The shared data vault may include encrypted files and/or data objects accessible to each of the managed applications 610. In some examples, each managed application may also be associated with a respective private data vault.”; [0123]-[0129] – “Applications written with this awareness can utilize any number of data vaults, which they can identify explicitly with vault name identifiers or resource names. However applications will not always be written with such awareness. Correspondingly, the policies can be used to configure a default data vault for each application. The default data vault of an application is used for the transparent redirection of all application file I/O […] Each managed application may be associated with a respective policy […] A policy may designate an encrypted data vault for data being processed in connection with the respective application […] The policy for that application may be read, and the read or write operation specified is diverted to an encrypted vault (e.g., the private vault or the shared vault), depending on the settings in the policy”; the secure container (also referred to as a data vault), is configured to be encrypted or unencrypted based on mode and a policy, can be considered a logical interface into which any or all persistent data read/written by a mobile application will be redirected, where the secure container/data vault may comprise metadata associated with data stored within the vault (name, size, access times, etc.).)
Barton fails to expressly teach the metadata identifying the state.
However, Jayanthi teaches the metadata identifying the state ([0011] – “a mapping of a respective unique identifier of container images of a software container and respective metadata of the container images may be generated.”; [0023] – “Each of the container images may be associated with respective metadata. As used herein, “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.”).
Barton and Jayanthi are considered to be analogous art to the claimed invention because they are reasonably pertinent to the problem faced by the inventor of securely running applications and managing data within secure containers. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the container metadata of Barton to identify the state, e.g. the configuration i.e., state, indicated by the policy of Barton, such as an encryption status, compression status, etc., as taught by Jayanthi. Doing so would facilitate better identification, deployment, and management of a plurality of containers (see Jayanthi: [0007]-[0011]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rao (U.S. Pub. No. 2019/0095254) teaches using a separate data container storing input data and output data for a plurality of stateless containers of binaries, each comprising executable instructions to provide a different version of a function component of a content management system, such that the binaries may be managed independently of the input and output data (see [0008] and [0034]).
SCHNEIDER et al. (U.S. Pub. No. 2025/0103370) teaches a container is software used to deploy and run a software application that is more lightweight than a virtual machine and supports portability across different computing environments by packaging the application together with the runtime environment need to execute the application (see [0003]-[0005]).
Suarez et al. (U.S. Patent No. 10,261,782) teaches a software container registry service which applies tags, i.e., metadata tags, to container images of a registry such that the metadata may be queried, where the tags may indicate a version of the container image (see Col. 10, line 44-Col. 11, line 36).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8:00 am - 4:00 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights