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 .
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-16 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 12314143. Although the claims at issue are not identical, they are not patentably distinct from each other because claims 1-16 of U.S. Patent No. 12314143 contain every element of claims 1-16 of the instant application and thus anticipate the claims of the instant application. Therefore, the claims of the instant application are not patentably distinct from the earlier patent claims and as such are unpatentable.
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.
Claim(s) are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sledz et al. (USPN 9632892B1).
As per claim 1, Sledz et al. discloses a method, comprising: detecting, by a first server, a loss of a connection from the first server to a second server (column 2, lines 25-33 – a failover of the client from the source cluster to the target cluster can be triggered, wherein the triggering disconnects the client from the source cluster. The dynamic IP address associated with the NFS access zone can be assigned to the target cluster. A connection can be established between the NFS client and the target cluster based on the dynamic IP address, wherein establishing the connection does not include mounting the NFS export on the target cluster.; column 7, lines 32-39 – discloses that target cluster of nodes is the first server and the source cluster of nodes is the second server);
writing data, by the first server, to a first block of a first region of persistent storage of the first server, in response to a service request from a client (column 11, lines 29-41 - FIG. 6 illustrates an example flow diagram method for an NFS client requesting a write on a target cluster after a failover event in accordance with implementations of this disclosure. Steps 602-624 are the same as steps 502-524 as described above. At 626, a write request associated with a new file can be received from the NFS client by the target cluster. At 628, a new file can be generated, wherein the new file is associated with a new target LIN, the FSID, and the access zone. The method also provides for honoring write requests associated with existing files. It can be appreciated that a write request associated with an existing file may first process a read of the file data as described with regard to FIG. 7.; column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.);
storing, by the first server, in a second region of persistent storage of the first server, a snapshot of the first region of persistent storage (column 11, lines 49-54 - a failback, a change log can be processed on the source cluster (see detailed explanation in regards to FIG. 8 below) such that any changes to the files on the target cluster can be processed while honoring any data protection processes associated with the access zone, including active snapshots.; column 12, lines 13-28 - At 804, the course cluster can receive a change log associated with a set of transactions made between the NFS client and the target cluster. It can be appreciated that the change log can track all transactions made on the target cluster after the failover including transactions performed for the plurality of clients connected to the target cluster NFS failover access zone. For example, not just read and writes, but deletions, metadata changes, policy changes, etc., can be tracked on the target cluster post failover. In one implementation, for any files created in the target cluster after the failover, a target LIN is created for the file and the mapping information is updated to include a placeholder source LIN that matches the target LIN, such that any future client request to the target cluster referencing a the placeholder source LIN is mapped to the newly generated target LIN.; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.);
overwriting a second block of the first region of persistent storage with data from the second server; and mounting, via a file system, the snapshot (column 10, lines 28-61 - (43) At 410, the source cluster can be synched to the target cluster by steps 412 and 414. At 412, the set of source files and directories can by dynamically mirrored in the target cluster as a set of mirrored files and directories, wherein the set of mirror files and directories are associated with a target access zone, wherein the target access zone is associated with the NFS export, wherein mirrored files and directories among the set of mirrored files and directories are associated with a unique target cluster LIN. It can be appreciated that not only file data but metadata, access zone configuration data, sync policy data, authentication process data, etc. can be synched. In one implementation, the access zone configuration data, authentication process data can be synced manually via a user or an administrator. At 414, a reverse LIN map can be dynamically generated and updated on the target cluster wherein unique target cluster LINs of mirrored files and directories among the set of mirrored files are directories are mapped to unique source cluster LINs of files and directories among the set of files and directories. (44) In one implementation, syncing the source cluster is based on a sync policy associated with the access zone.(45) In one implementation, the dynamically mirroring the set of source files and directories in the target cluster is based on incremental snapshots by the source cluster. In one implementation, the snapshot method is copy on write snapshots. It can be appreciated that a unique snapshot can be created on the source cluster that encompasses all the files within the NFS export specifically for the purpose of syncing the files to a target cluster. Upon first syncing the files between the source cluster and the target cluster, the entire path can be mirrored to the target cluster, and in subsequent dynamic sync operations, iterative snapshot processes can identify any newly added data to the source cluster that necessitates mirroring onto the target cluster.; overwriting is the syncing process; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.).
As per claims 3,11, Sledz et al. discloses further comprising reading a file comprising the first block, from the snapshot (column 11, lines 48-54 - In one implementation, the original file data exists on the source cluster and during a failback, a change log can be processed on the source cluster (see detailed explanation in regards to FIG. 8 below) such that any changes to the files on the target cluster can be processed while honoring any data protection processes associated with the access zone, including active snapshots.; column 12, lines 13-28 - At 804, the course cluster can receive a change log associated with a set of transactions made between the NFS client and the target cluster. It can be appreciated that the change log can track all transactions made on the target cluster after the failover including transactions performed for the plurality of clients connected to the target cluster NFS failover access zone. For example, not just read and writes, but deletions, metadata changes, policy changes, etc., can be tracked on the target cluster post failover. In one implementation, for any files created in the target cluster after the failover, a target LIN is created for the file and the mapping information is updated to include a placeholder source LIN that matches the target LIN, such that any future client request to the target cluster referencing a the placeholder source LIN is mapped to the newly generated target LIN.).
As per claims 8,16, Sledz et al. discloses wherein the first server and the second server are part of a Distributed Replicated Block Device (DRBD) system (column 1, line 65 – column 2, line 24 – files are mirrored between the source cluster of nodes and the target cluster of nodes).
As per claim 9, Sledz et al. discloses a system, comprising: a first server comprising: a processing circuit (column 12, lines 55-61 – processors); persistent storage (column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.); and memory, operatively connected to the processing circuit and storing instructions that, when executed by the processing circuit (column 13, lines 50-57 – storage device storing processor-readable instructions), cause the first server to perform a method, the method comprising: detecting a loss of a connection from the first server to a second server (column 11, lines 29-41 - FIG. 6 illustrates an example flow diagram method for an NFS client requesting a write on a target cluster after a failover event in accordance with implementations of this disclosure. Steps 602-624 are the same as steps 502-524 as described above. At 626, a write request associated with a new file can be received from the NFS client by the target cluster. At 628, a new file can be generated, wherein the new file is associated with a new target LIN, the FSID, and the access zone. The method also provides for honoring write requests associated with existing files. It can be appreciated that a write request associated with an existing file may first process a read of the file data as described with regard to FIG. 7.; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.);
writing data, by the first server, to a first block of a first region of the persistent storage of the first server, in response to a service request from a client (column 11, lines 49-54 - a failback, a change log can be processed on the source cluster (see detailed explanation in regards to FIG. 8 below) such that any changes to the files on the target cluster can be processed while honoring any data protection processes associated with the access zone, including active snapshots.; column 12, lines 13-28 - At 804, the course cluster can receive a change log associated with a set of transactions made between the NFS client and the target cluster. It can be appreciated that the change log can track all transactions made on the target cluster after the failover including transactions performed for the plurality of clients connected to the target cluster NFS failover access zone. For example, not just read and writes, but deletions, metadata changes, policy changes, etc., can be tracked on the target cluster post failover. In one implementation, for any files created in the target cluster after the failover, a target LIN is created for the file and the mapping information is updated to include a placeholder source LIN that matches the target LIN, such that any future client request to the target cluster referencing a the placeholder source LIN is mapped to the newly generated target LIN.; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.);
storing, by the first server, in a second region of the persistent storage of the first server, a snapshot of the first region (column 11, lines 49-54 - a failback, a change log can be processed on the source cluster (see detailed explanation in regards to FIG. 8 below) such that any changes to the files on the target cluster can be processed while honoring any data protection processes associated with the access zone, including active snapshots.; column 12, lines 13-28 - At 804, the course cluster can receive a change log associated with a set of transactions made between the NFS client and the target cluster. It can be appreciated that the change log can track all transactions made on the target cluster after the failover including transactions performed for the plurality of clients connected to the target cluster NFS failover access zone. For example, not just read and writes, but deletions, metadata changes, policy changes, etc., can be tracked on the target cluster post failover. In one implementation, for any files created in the target cluster after the failover, a target LIN is created for the file and the mapping information is updated to include a placeholder source LIN that matches the target LIN, such that any future client request to the target cluster referencing a the placeholder source LIN is mapped to the newly generated target LIN.; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.);
overwriting a second block of the first region of the persistent storage with data from the second server; and mounting the snapshot (column 10, lines 28-61 - (43) At 410, the source cluster can be synched to the target cluster by steps 412 and 414. At 412, the set of source files and directories can by dynamically mirrored in the target cluster as a set of mirrored files and directories, wherein the set of mirror files and directories are associated with a target access zone, wherein the target access zone is associated with the NFS export, wherein mirrored files and directories among the set of mirrored files and directories are associated with a unique target cluster LIN. It can be appreciated that not only file data but metadata, access zone configuration data, sync policy data, authentication process data, etc. can be synched. In one implementation, the access zone configuration data, authentication process data can be synced manually via a user or an administrator. At 414, a reverse LIN map can be dynamically generated and updated on the target cluster wherein unique target cluster LINs of mirrored files and directories among the set of mirrored files are directories are mapped to unique source cluster LINs of files and directories among the set of files and directories. (44) In one implementation, syncing the source cluster is based on a sync policy associated with the access zone.(45) In one implementation, the dynamically mirroring the set of source files and directories in the target cluster is based on incremental snapshots by the source cluster. In one implementation, the snapshot method is copy on write snapshots. It can be appreciated that a unique snapshot can be created on the source cluster that encompasses all the files within the NFS export specifically for the purpose of syncing the files to a target cluster. Upon first syncing the files between the source cluster and the target cluster, the entire path can be mirrored to the target cluster, and in subsequent dynamic sync operations, iterative snapshot processes can identify any newly added data to the source cluster that necessitates mirroring onto the target cluster.; the overwriting is the process of syncing; persistent storage - column 5, lines 6-8 - The operating system, using the LIN, can identify the location in block storage where the file data of the file is located.; column 13, lines 30-32 - For example, a single Node could contain, in one example, 36 disk drive bays with attached disk storage in each bay.).
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(s) 2,10 are rejected under 35 U.S.C. 103 as being unpatentable over Sledz et al. (USPN 9632892B1) in view of Liu et al. (CN102023907A).
As per claim 2, Sledz et al. fails to explicitly state wherein the mounting of the snapshot comprises mounting the snapshot by an operating system of the first server.
Sledz et al. does disclose in column 10, lines 49-61 - In one implementation, the dynamically mirroring the set of source files and directories in the target cluster is based on incremental snapshots by the source cluster. In one implementation, the snapshot method is copy on write snapshots. It can be appreciated that a unique snapshot can be created on the source cluster that encompasses all the files within the NFS export specifically for the purpose of syncing the files to a target cluster. Upon first syncing the files between the source cluster and the target cluster, the entire path can be mirrored to the target cluster, and in subsequent dynamic sync operations, iterative snapshot processes can identify any newly added data to the source cluster that necessitates mirroring onto the target cluster and column 5, lines 30-31 – the nodes of the clusters include a base operating system.
Liu et al. discloses mounting of the snapshot comprises mounting the snapshot by an operating system of the first server in the abstract - the operating system mounts the snapshot point to enter a configuration state corresponding to the snapshot point.
Accordingly, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to include operating system mounts the snapshot of Liu in the snapshot and operating system of the nodes of the clusters of Sledz et al. A person of ordinary skill in the art would have been motivated to make the modification because the operating system allows for the system to enter a configuration state corresponding to the snapshot, as disclosed in the abstract.
There is no prior art rejection for claims 4-7,12-15 because either no prior art could be found or no reason to combine with prior art found.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Yolanda L Wilson whose telephone number is (571)272-3653. The examiner can normally be reached M-F (7:30 am - 4 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, Bryce Bonzo can be reached at 571-272-3655. 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.
/Yolanda L Wilson/Primary Examiner, Art Unit 2113
Prosecution Insights