Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This is the initial office action based on the application filed on August 06, 2024. Claims 1-20 are presented for examination
Status of Claims
3. Claims 1-20 are pending, of which claims, of which claim 1, claim 8 and claim 15 are in independent form.
Priority
4. No priority has been considered for this application
Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
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 claims at issue 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); and 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 a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form 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 http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Instant application
U.S. Patent No 12,321,479
1. A method comprising:
receiving at a service, a contents file describing an image file to be mounted and mount information for the image file, wherein the service runs as a privileged process in user space of an operating system;
generating by the service, an image binary file based on the contents file;
determining, by a processing device, whether the image binary file is valid using the mount information; and in
response to determining that the image binary file is valid, sending a request to kernel space of the operating system to mount the image binary file.
1. A method, comprising:
creating, by a computing device executing a kernel-based operating system, a content-addressed object store containing files of a filesystem;
generating, by the computing device, a metadata file that describes characteristics of the files of the filesystem that are in the content-addressed object store; generating, by the computing device in a kernel of the kernel-based operating system, a Merkle tree of the metadata file and a Merkle tree of the content-addressed object store, wherein the Merkle tree of the metadata file contains hashes of blocks of the metadata file and the Merkle tree of the content-addressed object store contains hashes of blocks of the files in the content-addressed object store;
verifying, by the computing device in the kernel of the kernel-based operating system, that a digest corresponding to the metadata file matches an expected digest for the metadata file and digests corresponding to the files in the content-addressed object store match expected digests for the files in the content-addressed object store; and
mounting, by the computing device, the metadata file to a location in the filesystem.
8. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to:
receive at a service, a contents file describing an image file to be mounted and mount information for the image file, wherein the service runs as a privileged process in user space of an operating system;
generate, by the service, an image binary file based on the contents file;
determine whether the image binary file is valid using the mount information; and
in response to determining that the image binary file is valid, send a request to kernel space of the operating system to mount the image binary file.
16. A computing device, comprising: a memory; and a processor device coupled to the memory, the processor device to:
create a content-addressed object store containing files of a filesystem; generate a metadata file that describes characteristics of the files of the filesystem that are in the content-addressed object store;
generate a Merkle tree of the metadata file and a Merkle tree of the content-addressed object store, wherein the Merkle tree of the metadata file contains hashes of blocks of the metadata file and the Merkle tree of the content-addressed object store contains hashes of blocks of the files in the content-addressed object store;
verify that a digest corresponding to the metadata file matches an expected digest for the metadata file and digests corresponding to the files in the content-addressed object store match expected digests for the files in the content-addressed object store; and
mount the metadata file to a location in the filesystem.
15. A non-transitory computer-readable medium having instructions stored thereon which when executed by a processing device, cause the processing device to:
receive at a service, a contents file describing an image file to be mounted and mount information for the image file, wherein the service runs as a privileged process in user space of an operating system;
generate, by the service, an image binary file based on the contents file;
determine, by the processing device, whether the image binary file is valid using the mount information; and in
response to determining that the image binary file is valid, send a request to kernel space of the operating system to mount the image binary file.
20. A non-transitory computer-readable storage medium that includes computer-executable instructions that, when executed, cause one or more processor devices to:
create a content-addressed object store containing files of a filesystem; generate a metadata file that describes characteristics of the files of the filesystem that are in the content-addressed object store;
generate a Merkle tree of the metadata file and a Merkle tree of the content-addressed object store, wherein the Merkle tree of the metadata file contains hashes of blocks of the metadata file and the Merkle tree of the content-addressed object store contains hashes of blocks of the files in the content-addressed object store;
verify that a digest corresponding to the metadata file matches an expected digest for the metadata file and digests corresponding to the files in the content-addressed object store match expected digests for the files in the content-addressed object store; and
mount the metadata file to a location in the filesystem.
5. Claim 1, claim 8 and claim 15 rejected on the ground of nonstatutory double patenting over claim 1 of U.S. Patent No. 12,321,479 since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent. The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows:
Claim 1 of U.S. Patent No. 12,321,479 teaches includes all the features of claim 1, claim 8 and claim 15 of the instant application. Both applications teach mount a filesystem when the file system is valid. This is a non-statutory double patenting rejection.
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.
6. Claim 6 recites the limitation "the image file payload" There is insufficient antecedent basis for this limitation in the claim. Appropriated correction is requested.
7. Claim 13 recites the limitation "the image file payload" There is insufficient antecedent basis for this limitation in the claim. Appropriated correction is requested.
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 of this title, 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.
8. Claim 1-20 rejected under 35 U.S.C. 103 as being obvious over Scrivano, US 20220317987, (herein after Scrivano), in view of Gerraty, US 8161012, (herein after Gerraty) and further in view of Quinlan, US 20030028508, (herein after Quinlan).
Claim 1 rejected Scrivano teaches a method comprising (Scrivano, abstract and summary):
receiving at a service, a contents file describing an image file to be mounted and mount information for the image file, wherein the service runs as a privileged process in user space of an operating system (Scrivano, US 20220317987, figs. 3A and 3B, and para [0027-0028], The FUSE 222B may begin fetching the files that the container image 305 is comprised of from the registry server 130 as a background process in order to build (the base layers of) the container image 305 locally (e.g., within the currently empty lower layers of the overlay mount 224). This is desirable as the higher level logic for retrieving container images is ideally located in user-space. While fetching the container image 305, the FUSE 222B may also act as a proxy between the container 115 and the underlying container image 305. In this way, while the container image 305 is not fully built locally, the FUSE 222B may manage requests from the container 115 to access files. To handle pending file requests, in some embodiments, the FUSE 222B may emulate the overlay mount 224 so if the container 115 wishes to write a file, the FUSE 222B may write the file in the upper (write) layer at the appropriate location, or it may attempt to write to the overlay mount 224 through the overlay FS 222A.);
generating by the service, an image binary file based on the contents file (Scrivano, US 20220317987, figs. 3A and 3B, and para [0027-0028], Once the FUSE 222B determines that all of the files that the container image 305 is comprised of have been retrieved or requested, it may process any pending file requests as described above, thereby resulting in the entire container image 305 being locally stored. At this point, the base layers of container image 305 (i.e., a set of underlying directories corresponding to the container image 305) may be built in the overlay mount 224 and the FUSE 222B may instruct the overlay mount 224 to use the underlying base layers to run the container 115. At the same time, the FUSE 222B may unmount itself (i.e., detach itself from the file system view), so that the container 115 may be exposed to the underlying overlay mount 224 which now comprises the complete base layers of the container image 305.. Para [0029-0030].);
Scrivano does not explicitly teach
determining, by a processing device, whether the image binary file is valid using the mount information;
in response to determining that the image binary file is valid, sending a request to kernel space of the operating system to mount the image binary file
However, Gerraty teaches
determining, by a processing device, whether the image binary file is valid using the mount information (Gerraty, US 8161012, column 1, line 35 to 67, When the network device kernel mounts the file system contained in the ISO image, the kernel also establishes the integrity of the ISO image file itself using a digital signature calculated for the ISO image file according to a hashing algorithm. Because alterations of any of the component files of an ISO image would also compromise the integrity of ISO image file itself, verifying the ISO image using the associated digital signature ensures, at a high probability, that the component files have not been modified); and
in response to determining that the image binary file is valid, sending a request to kernel space of the operating system to mount the image binary file (Gerraty, column 1, line 35 to 67, If the calculated signature matches a certified, pre-calculated signature, the network device locates, in a file system data structure, the file system mounted from the ISO image and marks that file system as verified.).
It would have obvious to one having ordinary skill in the art before the effecting filling date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Gerraty into Scrivano’s invention to verify archive file of an entire file system when archive file is mounted by the network device as suggested by Gerraty (abstract and summary).
The Office would like to use prior Quinlan to back up Scrivano and Gerraty to further teach limitation
mount(Quinlan, US 20030028508, para [0010-0011], To avoid this need to specify a file system, UNIX employs a concept known as mounting, in which an entire first file system is placed (or "mounted", to use the UNIX terminology) with its hierarchical tree structure intact in a directory of a second file system, so that all files can be referenced from within a single file system. Thus, the file system 102 of FIG. 1 can be placed in subdirectory b (the "mount point") to create the single file system 200 shown in FIG. 2. In this single file system 200, file r can be referenced as/a/d/r, and file x as/b/x, without any need to specify a file system. Para [0012-0013], To summarize, mounting a file system logically associates it with another file system so that it can be referenced from within the other file system, while unmounting a file system logically dissociates it from another file system so that it can no longer be referenced from within the other file system. The term "mount operation", as used generically herein, refers to either of these operations, as well as any other operation that changes the logical association of a first file system with a second file system (as by moving the mount point within the second file system or to a different file system).
It would have obvious to one having ordinary skill in the art before the effecting filling date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Quinlan into Scrivano, Gerraty’s invention to control performance of file system mounting operation such as UNIX system operation in computer system. A file system installation request is received from user and authority of user is verified. The requested system is installed, when the user authority is recognized as suggested by Quinlan (abstract and summary).
Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Scrivano, Gerraty and Quinlan teach the method of claim 1, wherein the mount information comprises(Scrivano, para [0019-0028]. Quinlan, para [0034-0037 and 0039-0042].):
a destination mount namespace for the image file (Scrivano, fig. 2A and para [0019], The host OS 221 may use namespaces to isolate the resources of containers from each other. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).) ; and
a mount target location for the image file (Gerraty, column 8, line 15 to 25, The kernel uses the data in mount list entries 43 to determine, for example, the name of the device that an associated file system uses, the name of the file system, and the location, in the routing engine 12 directory hierarchy, of the file system relative to the root. In some embodiments, virtual file system list 42 is a table, tree, or other data structure. Root file system 46, as the root file system and thus first in virtual file system list 42, is associated with mount list entry 43A. The file system stored by KERNEL.iso 50, KERNEL file system 47, is mounted on root file system 46 and is associated with mount list entry 43B. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Scrivano, Gerraty and Quinlan teach the method of claim 2, wherein determining whether the image binary file is valid comprises (Scrivano, para [0019-0028]. Quinlan, para [0034-0037 and 0039-0042].):
determining whether the destination mount namespace is owned by a user requesting the image file to be mounted; determining whether the mount target location is owned by the user requesting the image file to be mounted; and determining that the image binary file is valid if the destination mount namespace and the mount target location are owned by the user requesting the image file to be mounted (Scrivano, para [0025], The container engine 222 may further comprise a file system in user space (FUSE) whose higher level logic may be implemented in user-space and may allow non-privileged users to create their own file systems without editing the code of the kernel. This is achieved by running the file system code in user space while a FUSE module provides a “bridge” to the actual kernel interfaces. The FUSE may allow the container engine 222 to perform a “lazy image pull” where a container is created before a container image the container is to be based on is locally available (e.g., stored within the overlay FS 222A). The container image is loaded on demand when the container wants to access the container image. As discussed, traditional methods of performing a lazy image pull require the FUSE to exist for the lifetime of the container, even after the container image is fully fetched locally. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Scrivano, Gerraty and Quinlan teach the method of claim 3, wherein the mount information further comprises an expected checksum of the image file (Gerrarty, column 6, line 10-18, Operating system 24 further comprises verified execution module 26 ("veriexec 26"), which kernel 25 uses to verify the file integrity of files managed by virtual file system 32. In operation, kernel 25 or one of daemons 22 sends veriexec 26 a manifest file comprising manifest entries that map a file path in a file system to a digital fingerprint for the file that has been calculated a priori with a hashing algorithm. Examples of well-known hashing algorithms include, for example, MD5, SHA1, SHA256, RMD160, and others. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
Claim 5 is rejected for the reasons set forth hereinabove for claim 4, Scrivano, Gerraty and Quinlan teach the method of claim 4, wherein determining whether the image binary file is valid further comprises (Scrivano, para [0019-0028]. Quinlan, para [0034-0037 and 0039-0042].):
generating a checksum for the image binary file; comparing the checksum to the expected checksum; and determining that the image binary file is valid if the checksum and the expected checksum match (Gerraty, column 6, line 18 to 28, When a file that has an entry in the manifest is read or executed, veriexec 26 calculates, using the same hashing algorithm with which the pre-calculated fingerprint was generated, a digital fingerprint for the file and compares the calculated fingerprint with the fingerprint in the manifest entry. Different fingerprints indicate that the file has been corrupted. Veriexec 26 may respond to a corrupted file by warning the kernel or a user; by preventing the file from executing or being read; or, in some cases, by locking down router 10 to prevent corrupted operation of the router. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
Claim 6 is rejected for the reasons set forth hereinabove for claim 1, Scrivano, Gerraty and Quinlan teach the method of claim 1, wherein the contents file specifies (Scrivano, para [0019-0028]. Quinlan, para [0034-0037 and 0039-0042].):
a name of the image file; a location of the image file; and a location of the image file payload (Scrivano, para [0028-0030], More specifically, upon receiving a request from the container 115 to access a file, the FUSE 222B may determine whether the requested file is one of the files that the container image 305 is comprised of, and if so may determine whether the requested file has already been fetched from the registry server 130 and locally stored. If the FUSE 222B determines that the requested file is part of the container image 305 and has been locally stored, then it may retrieve the file from the overlay mount 224 and provide it to the container 115. If the FUSE 222B determines that the requested file is part of the container image 305 and that it has not been locally stored, it may fetch the requested file from the registry server 130 and store it in the overlay mount 224 (e.g., within the appropriate base layer being constructed in the overlay mount 224). Once the requested file(s) has been written to the overlay mount 224, the FUSE 222B may provide it to the container 115. If the FUSE 222B determines that the requested file is not part of the container image 305, the FUSE 222B may determine that the container wants to create a new file. Thus, the FUSE 222B may create an empty file in the upper (write) layer of the overlay mount 224. While there are no active requests for files from the container 115, the FUSE 222B may continue fetching the files that the container image 305 is comprised of and storing them locally to build the base layers for the container image 305 within the overlay mount 224. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
Claim 7 is rejected for the reasons set forth hereinabove for claim 1, Scrivano, Gerraty and Quinlan teach the method of claim 1, wherein the contents file comprises text information describing the image file (Gerraty, column 1, line 40-44, a network device uses file systems to store and organize files on a storage medium. File systems include files and metadata (e.g., directories, directory records, and attributes) that enable a user of the file system to efficiently locate and access the files on the storage medium. Quinlan, para [0034-0037], FIG. 4 shows the various profiles used by security manager 316 to control access to protected resources. As shown in the figure, these profiles, which are maintained in the security database 318, include data set profiles 402 and resource profiles 404. Each data set 402 profile may be either a discrete profile or a generic profile. Each discrete profile 402 controls access to a single data set that has unique security requirements (such as, for example, a file system), while each generic profile 402 controls access to multiple data sets that have common security requirements. Fig. 7 and para [0039-0042], allows the mount to occur (step 706).).
As per claim 8, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 9, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 10, this is the system claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 11, this is the system claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 12, this is the system claim to method claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 13, this is the system claim to method claim 6. Therefore, it is rejected for the same reasons as above.
As per claim 14, this is the system claim to method claim 7. Therefore, it is rejected for the same reasons as above.
As per claim 15, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above.
As per claim 16, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above.
As per claim 17, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above.
As per claim 18, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above.
As per claim 19, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above.
As per claim 20, this is the medium claim to method claim 7. Therefore, it is rejected for the same reasons as above.
Inquiry
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630.
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, Lewis Bullock can be reached at 5712723759. 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.
/DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Prosecution Insights