DETAILED ACTION
The communication is in response to the application filed 03/21/2024 in which claims 1-20 are pending in the application. Claims 1, 8 and 14 are independent form.
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 .
Claim Objections
Claims 6, 7, 13 and 19-20 are objected to because of the following informalities:
Claims 6, 13, and 19 recite the limitation “an attestation that that particular virtual data volume …” in line 1 of the claim, which should be “an attestation that particular virtual data volume …”
Appropriate correction is required.
Claims 7 and 20 recite the limitation “in response to the computer determining that that particular virtual data volume is mounted…” in line 2 of claim, which should be “in response to the computer determining that particular virtual data volume is mounted….”
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov (US 20110153697), in view of Bathen (US 20190036778 A1).
As per claim 1, Nickolov discloses:
A computer-implemented method for virtual data volume management, the computer-implemented method comprising: [0021] “Various aspects described or referenced herein are directed to different methods, systems, and computer program products for facilitating manipulation of a file system on a virtual storage volume of a distributed computing system.”
……a plurality of volume identifiers, a plurality of mount point information and a plurality of API keys corresponding to a plurality virtual data volumes to be mounted on a plurality of disc devices;
[0710] “pool_name: name of the zpool to create on the dst volume.” [0711] mountpoint: mountpoint of the root dataset of the created zpool. Valid values may be: an absolute path, e.g. /mnt/mypool, legacy and none.” [0260] , “such a request may be provided via a management interface (e.g., visual, command-line, API, etc.)” and 1108, “the virtual appliance may provide its Host Name and/or other authentication credentials (e.g., MAC Address, key provided by DHCP, etc.)” [0410] “the operation of attaching the volume may include configuring a reference to an external storage device (physical or virtual), including specifying a device address (e.g., IP address), logical unit number (LUN), disk target, RFC-1737 universal resource name, etc”
Under BRI, “a plurality of volume identifiers” reads any type of identification that can assigned volume which Nikolov disclose in [0710], “a plurality of mount point information” reads a specific location to attach a volume which is disclose in [0711], “a plurality of API keys” reads any authentication credentials that passes through an interface which is disclose in [0260] and [1108].
retrieving, by the computer, a plurality of device identifiers corresponding to the plurality of disc devices where a plurality of virtual data volumes will be mounted using the plurality of API keys that correspond to the plurality of volume identifiers…. [1108] “virtual appliance determines the IP address of Web Server 1106 (which, in the specific example embodiment is the same as the IP address of the DHCP Server), and sends a request to the Web Server to access the virtual appliance's configuration file. In at least one embodiment, the virtual appliance may provide its Host Name and/or other authentication credentials (e.g., MAC Address, key provided by DHCP, etc.) to the Web Server which, for example, may be used (1) to identify the requesting virtual appliance, and (2) validate and/or authenticate the identity of the requesting virtual appliance
Under BRI, “retrieving, by the computer, a plurality of device identifiers corresponding to the plurality of disc devices where a plurality of virtual data volumes will be mounted using the plurality of API keys that correspond to the plurality of volume identifiers” encompass any identification that is assigned to a device such [0318] “identifiers of the source and/or target volumes (e.g., LUN, volume name, iSCSI target, etc.)”. When retrieving the device id by using API keys which further encompasses authentication creds which is requested and returns the device configuration as disclose in Nickolov [1108] (See Fig 11).
mounting, by the computer, the plurality of virtual data volumes on the plurality of disc devices based on the plurality of device identifiers corresponding to the plurality of disc devices and the plurality of mount point information corresponding to the plurality of volume identifiers…. [0154] …. “Once instantiated, one or more virtual volumes may be automatically attached, inserted or connected to a given filer appliance to be managed by the filer appliance. The filer appliance may dynamically and/or automatically carry out operations in connection with management of the virtual volume.” [0345] “…. Filer Operation Procedure attaches the source volume to the appropriate filer appliance. [0346] providing a volume identification (e.g., during configuration at block 906) [0347] connecting the desired volume to the filer appliance instance (e.g., connecting to the volume via iSCSI interface) [0348] instructing the system in which the filer appliance operates to provide the appliance with access to the volume [0349] creating a symbolic link to the volume [0350] presenting the volume (or its symbolic link) as a volume to be used with the filer instance[0351] place a lock the source volume, so that the volume will not be modified during the operation [0352] etc. [0353] “…..the Filer Operation Procedure attaches the destination volume to the appropriate filer appliance.”
Nickolov does not explicitly disclose a “receiving, by a computer, a smart contract that includes a plurality of volume identifiers, a plurality of mount point information and a plurality of API keys corresponding to a plurality virtual data volumes to be mounted on a plurality of disc devices;”
However, Bathen discloses a “receiving, by a computer, a smart contract that includes a plurality of volume identifiers, a plurality of mount point information and a plurality of API keys corresponding to a plurality virtual data volumes to be mounted on a plurality of disc devices;” [0008] “Another example embodiment may include an apparatus that includes a processor configured to perform one or more of identify one or more data volume management policies from a plurality of different parties, store the one or more data volume management policies in a smart contract stored on a blockchain…”
Both Nickolov and Bathen are in similar field of endeavor, as they are both in data processing and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Nickolov and with the teachings of Bathen to have smart contacts to include a plurality of volume identifiers, a plurality of mount point information and a plurality of API keys corresponding to a plurality virtual data volumes to be mounted on a plurality of disc devices.
Motivation to combine would be to improve the system reliability by having a dedicated smart contract, that include set of rule and or policies that are needed to properly function within a virtual data volume management to further specify which volumes should go which devices at which mounting point.
As per claim 8, it has similar limitation as claim 1, therefore is rejected under the same rationale.
As per claim 14, it has similar limitation as claim 1, therefore is rejected under the same rationale.
Claims 2, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov (US 20110153697), in view of Bathen (US 20190036778 A1), in view of Soman (US 20220091869 A1).
As per claim 2 Nickolov and Bathen disclose a method of claim 1 detailed above.
Nickolov further disclose “verifying, by the computer, that each of the plurality of virtual data volumes corresponding to the plurality of volume identifiers is mounted at a correct mount point on each of the plurality of disc devices corresponding to the plurality of device identifiers based on the plurality of mount point information corresponding to the plurality of volume identifiers included in the smart contract;” [0256] “the managing entity may monitor or track the status of the volume operation(s), and collect status information from the filer appliance(s). When it has been detected that the volume operation(s) have been successfully completed, the managing entity may automatically release the filer appliance(s) and the volumes, and may also communicate the operation status to the initator.”
Nickolov in view of Bathen does not explicitly disclose “running, by the computer, a container application workload on a virtual server instance in a host node to provide a service of an entity using the plurality of virtual data volumes mounted on the plurality of disc devices ensuring secure execution of the container application workload by the virtual server instance in the host node corresponding to a virtual private cloud of a public cloud environment in response to verifying that each of the plurality of virtual data volumes corresponding to the plurality of volume identifiers is mounted at the correct mount point on each of the plurality of disc devices corresponding to the plurality of device identifiers.”
However, Soman discloses “running, by the computer, a container application workload on a virtual server instance in a host node to provide a service of an entity [0003] “utilizes application storage volumes (ASVs), which are centrally stored and managed containers, such as virtual disks, containing one or more applications. The ASVs can be mounted or attached to a virtual machine to quickly and efficiently deliver contained applications to the virtual machine” using the plurality of virtual data volumes mounted on the plurality of disc devices ensuring secure execution of the container application workload by the virtual server instance in the host node corresponding to a virtual private cloud of a public cloud environment in response to verifying that each of the plurality of virtual data volumes corresponding to the plurality of volume identifiers is mounted at the correct mount point on each of the plurality of disc devices corresponding to the plurality of device identifiers.” [0038] “The storage device 208 may be located on a server, which may be different than or the same as the host server 210. The master volume 204 and ASV 214 in the storage 208 may be accessible to the VM 200 over a network, such as a LAN (local area network) or a WAN. The storage device 208 would also normally contain numerous other writeable volumes (assigned to other users), although only one writeable volume 204 is illustrated, and any of the writeable volumes could be mounted to a VM hosted on the host server 210. The storage device 208 would also normally contain numerous ASVs, although only one ASV 214 is illustrated, and any of the ASVs could be mounted and shared by any number of VMs hosted on the host server 210. For example, the ASV 214 can be mounted in read-only mode on multiple VMs, delivering to each VM the contained application(s).” [0044] “Hence, when a mounted application is executed on a VM 200, the execution takes place from the ASV 214 in the storage device 208. The agent 212 can operate as a filter driver and intercept calls to the mounted application from the OS 202 and direct them to the ASV virtual disk 214.”
Under BRI, “container application workloads” encompass the application storage volume (ASV) which Soman disclose in [0003] which simply manage and store application within a container, “virtual server instance in the host node” encompass the virtual machine which is disclose [0038] which “VM 200” is the virtual server and “host server 210” is the host node. The “virtual private cloud” (VPC) encompasses any shared network storage in where information is shared across multiple VM while maintain its own assigned volume which is disclose [0038].
Nickolov, Bathen and Soman are in similar field of endeavor, as they are all in data processing and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Nickolov, with the teachings of Bathen, and with the teachings of Soman to have a container application workload on a virtual server instance in a host node to provide a service of an entity using the plurality of virtual data volumes mounted on the plurality of disc devices ensuring secure execution of the container application workload by the virtual server instance in the host node corresponding to a virtual private cloud of a public cloud environment in response to verifying that each of the plurality of virtual data volumes corresponding to the plurality of volume identifiers is mounted at the correct mount point on each of the plurality of disc devices corresponding to the plurality of device identifiers.[0256 Nickolov]
Motivation to combine would be to improve the system performance of deploying by confirming all the virtual data volume is mounted to a specific point before running the container application workload.
As per claim 9, it has similar limitation as claim 2, therefore is rejected under the same rationale.
As per claim 15, it has similar limitation as claim 2, therefore is rejected under the same rationale.
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov (US 20110153697), in view of Bathen (US 20190036778 A1), in view of Soman (US 20220091869 A1), in view of Baker et al (US 11930045 B1).
As per claim 3 Nickolov, Bathen, and Soman discloses a method of claim 2 detailed above.
Soman further discloses “retrieving, by the computer, the smart contract that includes a workload section provided by the entity and an environment section provided by a cloud administrator in response to starting the virtual server instance;” [0017] “The produced ASV can then be assigned (e.g. by an administrator) to a particular virtual machine at the time the user requests their virtual desktop in order to deliver the applications in the ASV to the virtual machine.”[0021] “Like ASVs, a writeable volume can be maintained in a central location from where it is accessed by a VM to which it is assigned to write and read data to/from the writable volume without changing the physical location of the writeable volume… ” [0034] “an administrator can manage ASVs and writeable volumes (e.g., 214, 204, 224) via a volume manager 206. For example, the administrator may be able to access the manager 206 via an interface and perform operations on user desktops such as assigning ASVs and writeable volumes to users' virtual desktops or unassigning previously assigned ASVs and writeable volumes from users' virtual desktops. In various embodiments, the manager 206 may reside on an enterprise server or be cloud-based” [0035] “The administrator can then assign an ASV (e.g., 214) to one or more user desktops in order to deploy the applications in the ASV (e.g., 214) to the selected user's 240 desktop. ….. When an ASV is assigned to a user's virtual desktop, each time the user logs into the virtual desktop, the assigned ASV can be mounted to the virtual machine to provide the contained applications in the virtual desktop.”
Bathen further discloses “determining, by the computer, whether the smart contract is valid based on performing a validation of the smart contract;” [0033] “Referring to FIG.2, the process may include generating and executing smart contracts for the tiering/ILM context to be enacted on the network system…. The smart contract may be enacted to undergo a review process and may be deployed on the blockchain 240. The monitoring engine 250 tracks data volume IO (i.e., file IO, object reads/writes, etc.), …. the monitor 250 is responsible for validating the state of the system, and checking if it does indeed reflect the state in the blockchain. [0039] “The method may also include validating signatures and executing the smart contract via one or more blockchain member nodes….”
Nickolov, Bathen, and Soman does not discloses:
“retrieving, by the computer, the plurality of device identifiers assigned to the entity from virtual private cloud information of the entity using the plurality of API keys corresponding to the plurality of volume identifiers included in the smart contract in response to the computer determining that the smart contract is valid based on performing the validation of the smart contract.”
However, Baker discloses
“retrieving, by the computer, the plurality of device identifiers assigned to the entity from virtual private cloud information of the entity using the plurality of API keys corresponding to the plurality of volume identifiers included in the smart contract in response to the computer determining that the smart contract is valid based on performing the validation of the smart contract.” [col 6 lines 32-38] “…. additional examples include enabling users to store their API key as a secret in the cloud data platform, configure an integration object that permits use of this API key and access to the remote API, and create a standard or relatively-standard Java or Python function that uses the stored credential to make the call using a standard API (e.g., a request). [col 8 lines 32-36, lines 40-42] “the compute service manager 108 is further coupled to the execution platform 110, which provides multiple computing resources that execute various data storage and data retrieval tasks. The execution platform 110 is coupled to cloud storage platform 104. The cloud storage platform 104 comprises multiple data storage devices 120-1 to 120-N…… For example, the data storage devices 120-1 to 120-N can be part of a public cloud infrastructure or a private cloud infrastructure.” [col 10 lines 28-34] “As shown in FIG. 2, the compute service manager 108 includes an access manager 202 and a credential management system 204 coupled to access data storage device 206, which is an example of the metadata database(s) 112. Access manager 202 handles authentication and authorization tasks for the systems…”
Under BRI, “virtual private cloud information” encompasses a cloud platform/environment that just store assignment for an entity which Baker disclose [col 6 line 32-38]. “the plurality of device identifiers assigned to the entity from virtual private cloud information of the entity using the plurality of API keys corresponding to the plurality of volume identifiers” which encompasses a search/access of the device resource using the credential management system which Baker disclose [col 8 lines 32-36, lines 40-42] and [col 10 lines 28-34]
Nickolov, Bathen, Soman, and Baker are in similar field of endeavor, as they are all in data processing and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Nickolov, with the teachings of Bathen, with the teachings of Soman, and with the teachings of Baker by the computer, to retrieve, the smart contract that includes a workload section provided by the entity and an environment section provided by a cloud administrator in response to starting the virtual server instance; determining, by the computer, whether the smart contract is valid based on performing a validation of the smart contract; retrieving, by the computer, the plurality of device identifiers assigned to the entity from virtual private cloud information of the entity using the plurality of API keys corresponding to the plurality of volume identifiers included in the smart contract in response to the computer determining that the smart contract is valid based on performing the validation of the smart contract.
Motivation to combine would be to improve the system reliability by securing virtual data volume management by preventing unauthorized workload to have access to the preapproved policy within the cloud.
As per claim 10, it has similar limitation as claim 3, therefore is rejected under the same rationale.
As per claim 16, it has similar limitation as claim 3, therefore is rejected under the same rationale.
Claims 4, 5, 11, 12, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov (US 20110153697), in view of Bathen (US 20190036778 A1), in view of Soman (US 20220091869 A1), in view of Baker et al (US 11930045 B1) in view of Hussain et al(US 20160162438 A1)
As per claim 4 Nickolov, Bathen, Soman and Baker discloses a method of claim 3 detailed above.
Nickolov further teaches “determining, by the computer, whether a number of the plurality of virtual data volumes corresponding to the plurality of volume identifiers included in the smart contract matches a number of the plurality of disc devices corresponding to the plurality of device identifiers assigned to the entity;” [0254] “… the managing entity may automatically select the appropriate filer appliance (or appliances) to perform the desired volume operation(s) (e.g., volume resize operation), may automatically and dynamically configure the selected filer appliance(s) to access the selected volume(s), and may direct the filer appliance(s) to perform the desired operation(s). [0305] “the runtime system 750 may configure the filer appliance 754 to access the volume 776a as the filer's source volume. It may further configure the filer appliance 764 to access the volume 776c as its destination volume.” [0346] providing a volume identification (e.g., during configuration at block 906) [0347] connecting the desired volume to the filer appliance instance (e.g., connecting to the volume via iSCSI interface) [0348] instructing the system in which the filer appliance operates to provide the appliance with access to the volume [0349] creating a symbolic link to the volume [0350] presenting the volume (or its symbolic link) as a volume to be used with the filer instance [0410] “the operation of attaching the volume may include configuring a reference to an external storage device (physical or virtual), including specifying a device address (e.g., IP address), logical unit number (LUN), disk target, RFC-1737 universal resource name, etc”
Nickolov, Bathen, Soman, and Baker does not explicitly disclose
“performing, by the computer, a mapping of each respective virtual data volume of the plurality of virtual data volumes to a corresponding disc device of the plurality of disc devices where a particular virtual data volume will be mounted in response to the computer determining that the number of the plurality of virtual data volumes corresponding to the plurality of volume identifiers included in the smart contract does match the number of the plurality of disc devices corresponding to the plurality of device identifiers assigned to the entity.”
However, Hussain discloses “performing, by the computer, a mapping of each respective virtual data volume of the plurality of virtual data volumes to a corresponding disc device of the plurality of disc devices where a particular virtual data volume will be mounted in response to the computer determining that the number of the plurality of virtual data volumes corresponding to the plurality of volume identifiers included in the smart contract does match the number of the plurality of disc devices corresponding to the plurality of device identifiers assigned to the entity.” [0031] “the NVMe storage proxy engine 204 organizes and maps the remote storage devices to one or more logical or virtual volumes/blocks in the NVMe namespaces, to which the VMs 110 can access and perform I/O operations as if they were local storage volumes. Here, each volume is classified as logical or virtual since it maps to one or more physical storage devices either locally attached to or remotely accessible by the NVMe controller 102 via the storage access engine 208…. In some embodiments, the virtual volume includes a meta-data mapping table between the logical volume and the remote storage devices 122, wherein the mapping table translates an incoming (virtual) volume identifier and a logical block addressing (LBA) on the virtual volume to one or more corresponding physical disk identifiers and LBAs on the storage devices.”
Nickolov, Bathen, Soman, Baker and Hussain are in similar field of endeavor, as they are all in data processing and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Nickolov, with the teachings of Bathen, with the teachings of Soman, with the teachings of Baker and with the teachings of Hussain to have the computer to perform a mapping of each respective virtual data volume of the plurality of virtual data volumes to a corresponding disc device of the plurality of disc devices where a particular virtual data volume will be mounted in response to the computer determining that the number of the plurality of virtual data volumes corresponding to the plurality of volume identifiers included in the smart contract does match the number of the plurality of disc devices corresponding to the plurality of device identifiers assigned to the entity.
Motivation to combine would be to improve the system reliability by improving the security of the virtual volume management by ensuing that the data volume are mounted to the correct device based on the validation of the contract/policy. Which would further reduce any errors or unauthorized access that may occur within the container environment.
As per claim 11, it has similar limitation as claim 4, therefore is rejected under the same rationale.
As per claim 17, it has similar limitation as claim 4, therefore is rejected under the same rationale.
As per claim 5
Nickolov further disclose “selecting, by the computer, the corresponding disc device of the plurality of disc devices to mount the particular virtual data volume based on the mapping of each respective virtual data volume of the plurality of virtual data volumes to the corresponding disc device of the plurality of disc devices where that particular virtual data volume will be mounted;” [0305] “the runtime system 750 may configure the filer appliance 754 to access the volume 776a as the filer's source volume. It may further configure the filer appliance 764 to access the volume 776c as its destination volume….” [0470] “…one or more filer application templates may be used for handling one or more of the volume operations to be performed. In at least one embodiment, one or more of the filer application templates may be preconfigured to perform specific tasks and/or operations.” [0471] “one or more filer appliances/applications may be utilized for facilitating file access to online (e.g., in use, mounted, attached, etc.) virtual storage volumes…”
Under BRI, the limitation discuss above just reads a process where a system uses a set of information to where that information should be mounted.
Nickolov further disclose “mounting, by the computer, that particular virtual data volume on the corresponding disc device at a specified mount point in mount point information that corresponds to a volume identifier of that particular virtual data volume within the smart contract.” [0459] … “In one embodiment, the operation may include creating a link to the desired volume and configuring the filer instance to use the link as its source volume. For example, in at least one embodiment, the operation of attaching the volume may include configuring a reference to an external storage device (physical or virtual), including specifying a device address (e.g., IP address), logical unit number (LUN), disk target, RFC-1737 universal resource name, etc.”
As per claim 12, it has similar limitation as claim 5, therefore is rejected under the same rationale.
As per claim 18, it has similar limitation as claim 5, therefore is rejected under the same rationale.
Claims 6, 7, 13, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nickolov (US 20110153697 A1), in view of Bathen (US 20190036778 A1), in view of Soman (US 20220091869 A1), in view of Baker et al (US 11930045 B1) in view of Hussain et al(US 20160162438 A1), in view of Johnson et al (“Parma: Confidential Containers via Attested Execution Policies” March 7th 2023)
As per claim 6 Nickolov, Bathen, Soman, Baker and Hussain disclose a method of claim 5 detailed above.
Nickolov further disclose “determining, by the computer, whether the mounting of that particular virtual disc volume was successful on the corresponding disc device;” [0256] “the managing entity may monitor or track the status of the volume operation(s), and collect status information from the filer appliance(s). When it has been detected that the volume operation(s) have been successfully completed, the managing entity may automatically release the filer appliance(s) and the volumes, and may also communicate the operation status to the initator.”
Under BRI, “determining, by the computer, whether the mounting of that particular virtual disc volume was successful on the corresponding disc device” which reads a system that monitor and record the status of the completion of the mount point which Nickolov disclose in [0256].
Nickolov, Bathen, Soman, Baker and Hussain does not explicitly disclose
“performing, by the computer, using an attestation container , an attestation that that particular virtual data volume is mounted on a correct disc device at the specified mount point in accordance with the smart contract based on information retrieved from a metadata partition of the corresponding disc device where that particular virtual data volume was mounted in response to the computer determining that the mounting of that particular virtual disc volume was successful on the corresponding disc device.”
However, Johnson discloses “performing, by the computer, using an attestation container , an attestation that that particular virtual data volume is mounted on a correct disc device at the specified mount point in accordance with the smart contract based on information retrieved from a metadata partition of the corresponding disc device where that particular virtual data volume was mounted in response to the computer determining that the mounting of that particular virtual disc volume was successful on the corresponding disc device.” (Page 2, See Fig 1) “the execution policy is a component of the utility VM that is attested at initialization time. It describes all of the actions the user has explicitly allowed the guest agent to take within the container group. In (a) we see an example of a successful mount action, in which a layer of a container image has a dm-verity root hash which matches a hash enumerated in the policy” (Page 8 col 2, See Table 1) “First we have actions which pertain to the creation of containers. By ensuring that any device mounted by the guest has a dm verity root hash [18] that is listed in the policy, and that they are combined into overlay filesystems [31] in layer orders that coincide with specific containers, we first establish that the container file systems are correct. We can then start the container, further ensuring that the environment variables and start command comply with policy and that mounts from the UVM to the container are as expected (along with other container specific properties). Other actions proceed in a similar manner, constraining the control which the container shim has over the guest agent….” (Page 9 col 1) “A novel feature of our implementation is the ability for a policy to manipulate its own metadata state (maintained by the guest agent). This provides an attested mechanism for the execution policy to build a representation of the state of the container group, allowing for more complex interactions. For example, in the rule shown in Listing 1, the enforcement point for mounting a device creates a metadata entry for the device which will be used to prevent other devices from being mounted to the same target path.”
Under BRI, “attestation container” encompass a function to perform an integrity validation of the mounting information which Johnson disclose on (Page 2), “based on information retrieved from a metadata partition of the corresponding disc device where that particular virtual data volume was mounted” which reads a device that stores configuration metadata “hash” from where the data was mounted which Johnson disclose (Page 8, col 2, See Table 1) and (Page 9, col 1)
Nickolov, Bathen, Soman, Baker, Hussain, Johnson are in similar field of endeavor, as they are all in data processing and, therefore, are combinable/modifiable.
Therefore, it would have been obvious to one the ordinary skills in the art before the effective filing data of the claimed inventions to modify the teaching of Nickolov, with the teachings of Bathen, with the teachings of Soman, with the teachings of Baker, with the teachings of Hussain and with the teachings of Johnson to have the computer performs using an attestation container , an attestation that that particular virtual data volume is mounted on a correct disc device at the specified mount point in accordance with the smart contract based on information retrieved from a metadata partition of the corresponding disc device where that particular virtual data volume was mounted in response to the computer determining that the mounting of that particular virtual disc volume was successful on the corresponding disc device.
Motivation to combine would be to improve the system performance by determining that the correct volume data was mounted on that particular device to further initiate an attestation container which provide a sense of confidentially of the container workload that any unauthorized workloads cannot access the container.
As per claim 13, it has similar limitation as claim 6, therefore is rejected under the same rationale.
As per claim 19, it has similar limitation as claim 6, therefore is rejected under the same rationale.
As per claim 7
Johnson further discloses “determining, by the computer, whether that particular virtual data volume is mounted on the correct disc device at the specified mount point in accordance with the smart contract based on performing the attestation;” (Page 6, col 2) “The file system driver enforces integrity checking upon an access to the file system, ensuring that the host system software cannot tamper with the data and container images. In Parma, a container file system is expressed as an ordered sequence of layers, where each layer is mounted as a separate device and then assembled into an overlay filesystem [31]. First, Parma verifies as each layer is mounted that the dm verity root hash [18] for the device matches a layer that is enumerated in the policy.”
Johnson further discloses “determining, by the computer, whether another disc device exists in the plurality of disc devices in response to the computer determining that that particular virtual data volume is mounted on the correct disc device at the specified mount point in accordance with the smart contract based on performing the attestation;” (Page 5, col 2) “guest agent mounts the container’s root filesystem into the UVM; the root filesystem comprises the container layers and a writeable scratch layer. In doing so, the container shim (i) attaches each container layer (in the OCI specification) to the UVM and (ii) creates and attaches to the UVM a writeable sandbox virtual hard drive. The container layer and sandbox devices are then mounted by the guest agent into the UVM as an overlay root filesystem. Finally, the guest agent creates a runtime bundle that contains the overlay filesystem path and configuration data (compiled using the OCI runtime specification.)” (Page 6 col 2) “when the container shim requests the mounting of an overlay filesystem that assembles multiple layer devices, Parma verifies that the specific order ing of layers is explicitly laid out in the execution policy for one or more containers”
Soman further teaches “running, by the computer, the container application workload of the entity on the virtual server instance in the host node to provide the service of the entity [0003] “utilizes application storage volumes (ASVs), which are centrally stored and managed containers, such as virtual disks, containing one or more applications. The ASVs can be mounted or attached to a virtual machine to quickly and efficiently deliver contained applications to the virtual machine” using the plurality of virtual data volumes mounted on the plurality of disc devices ensuring the secure execution of the container application workload by the virtual server instance in the host node corresponding to the virtual private cloud of the entity in the public cloud environment in response to the computer determining that another disc device does not exist in the plurality of disc devices.” [0036] “The same process can be repeated with numerous applications to capture each application on one ASV 214. The process of application capture can be automated. This may be performed using a file system filter driver, which can redirect file and registry open/create requests from one volume to another. During capture, a writable virtual disk can be attached to (mounted on) the staging machine and all file/registry creation and modifications made during the application installation process can be intercepted by the filter driver and redirected to the writable virtual disk, such that when the application is completely installed on the staging machine, all of the application content is captured on that disk. [0038] “The storage device 208 may be located on a server, which may be different than or the same as the host server 210. The master volume 204 and ASV 214 in the storage 208 may be accessible to the VM 200 over a network, such as a LAN (local area network) or a WAN. The storage device 208 would also normally contain numerous other writeable volumes (assigned to other users), although only one writeable volume 204 is illustrated, and any of the writeable volumes could be mounted to a VM hosted on the host server 210. The storage device 208 would also normally contain numerous ASVs, although only one ASV 214 is illustrated, and any of the ASVs could be mounted and shared by any number of VMs hosted on the host server 210. For example, the ASV 214 can be mounted in read-only mode on multiple VMs, delivering to each VM the contained application(s).”
Under BRI, “container application workloads” encompass the application storage volume (ASV) which Soman disclose in [0003], “virtual server instance in the host node” encompass the virtual machine which is disclose [0038] which “VM 200” is the virtual server and “host server 210” is the host node. The “virtual private cloud” (VPC) encompasses any shared network storage in where information is shared across multiple VM while maintain its own assigned volume which is disclose [0038].
As per claim 20, it has similar limitation as claim 7, therefore is rejected under the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Matsuda; Kazumitsu et al (US 7263574 B2) disclose a computer implemented virtual tape system enables making definition of a virtual tape volume of another medium with the same volume serial number
Mimatsu, Yasuyuki et al. (US 20050010733 A1) disclose a disk array has storage regions provided to store the management information for each disk volume of the backup data, and an interface is provided through which the management information for each disk volume.
Idei, Hideomi (US 20040117398 A1) disclose reduce data accesses to disks by providing a cache memory within storage devices, retaining the data read from the disks in the cache memory.
Goodman; Daniel I. et al. (US 10013218 B2) disclose a disk partitioning, a single storage device is divided into multiple logical storage units referred to as partitions, thereby treating one physical storage device as if it were multiple disks.
Takeuchi; Shinya et al. (US 20060010289 A1) disclose refining the plurality of logical volume data to one or more logical volume data based on the plurality of logical volume data, allocation destination candidate data.
Liu; Fuming et al (US 20080082748 A1) disclose logical volumes located in different array groups are designated so that logical volumes belonging to array groups other than the array groups to which the designated logical volumes belong are taken as data migration destinations.
Coles; Alistair et al. (US 20140040886 A1) disclose a secure operation system initiates a secure operation associated with a virtual machine hosted at a secured host.
Magowan; James Robert et al. (US 20230068221 A1) discloses securing pods in a container orchestration environment.
Beck; Michael (US 20190158275 A1) disclose a first access policy for a first digital attestation including data characterizing an attestation affecting an execution of a smart contract can be received.
Pascual; Sergio Lopez (US 20210263759 A1) disclose a virtual machine may be created at the application node and may include an associated memory for use during execution of the virtual machine. An encryption key may be received and the memory may be encrypted. An encrypted container image and may be mounted within the virtual machine.
Ranganathan; Vidya et al (US 20230342478 A1) disclose a method that determine whether the workload has valid attestation.
Xing; Bin (US 20230273991 A1) disclose a system to receive a new workload by a trusted execution environment virtual machine (TVM).
YANG; Ziye (US 20220391494 A1) disclose managing the shared data can include attesting a key for a confidential container to verify that the confidential container is part of the TEE for a pod.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ASHMEED ACHILLE whose telephone number is (571)272-9437. The examiner can normally be reached Monday-Friday 7am -4pm.
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, PIERRE VITAL can be reached at (571)272-4215. 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.
/A.A./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights