DETAILED ACTION
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 .
Response to Amendment
Applicant’s response filed 10/22/2025 has been considered and entered. Accordingly, claims 1-8, 11-15, and 18-20 are pending in this application. Claims 9, 10, 16, and 17 are cancelled; claims 1, 12, and 19 are currently amended; claims 2-8, 11, 13-15, 18, and 20 are original.
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, 11-15, 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Spillane et al. (previously presented)(US 2017/0264684 A1), hereinafter Spillane, in view of Mandadi et al. (previously presented) (US 2017/0300552 A1), hereinafter Mandadi, and further in view of Taivalsaari (US 2004/0243999 A1).
As to claim 1, Spillane discloses a method, comprising:
determining to back up file system data from a source system to a storage system (Figs. 3, 6-7; [0021], Lines 20-24; [0041], [0124], A determination is made to backup file system data from one file system to another, e.g. from a primary cluster to a secondary cluster.), wherein the storage system maintains a tree data structure that enables the backed up file system data to be located (Figs. 2, 8; [0021], Lines 20-24, [0055]; [0060], File system tree data is maintained and implemented on a secondary cluster enabling backed up file system data to be located, e.g. in the case of a failover ([0040].).);
serializing a portion of the tree data structure and the file system data into a first flat set of data (Figs. 1, 2, 6-7; [0051], [0074], [0123]-[0124], A exo-clone file, i.e. a first flat set of data, is generated containing changes in a file system. The file thus serializing a portion of the tree data structure [0055] and data [0056] of at least the portion of the file system that has changes since a previous exo-clone file, i.e. a second flat set of data, was generated.), wherein a first data block associated with the first flat set of data includes a file pointer to a first data block associated with a second flat set of data corresponding to a previous back up of the file system data (Figs. 1-2, [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address offset thereto.), , and wherein the file pointer is to a second data block that includes serialized tree data for a root node or an intermediate node of the tree data structure (Figs. 1-2, [0060], [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address with and offset of zero thereto. Since the blocks correspond to the file system tree, at least one block must correspond to a root or intermediate node, and as such it would have been obvious that the first block, which can be any block as claimed, can correspond to the root node or an intermediate node of the tree data structure.); and
sending to the storage system, the first flat set of data (Figs. 3, 6-7; [0124], Exporting an exo-clone file.).
Spillane does not specifically disclose determining to archive the file system data that was backed up, that the second flat set of data corresponds to a previous archive, and archiving to an archival storage, the first flat set of data.
Spillane does however disclose that an exo-clone file (flat set of data) “is just a regular file that can be easily transmitted, stored, backed up, shared, or distributed with other third-party (non-VDFS) systems. For example, an organization can back up a volume to S3 by merely uploading periodically taken exo-clones of that volume to S3 as regular files” ([0036]) and that a user can schedule incremental backups to a cloud storage ([0042]). Thus, it is highly suggested that flat sets of data are intended to also act as archives performed on a periodic basis, i.e. in accordance with some policy, when being used to store with third-party (non-VDFS) systems as desired by a user; and that a user has control on where to store their backups ([0089])
However, Mandadi discloses a method, comprising:
determining to archive file system data from a source system to a storage system ([0035], “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”), wherein the storage system maintains a tree data structure that (Figs. 4A, 5; [0035], [0037] ; [0046]-[0047]; Versioned hierarchical data structures, such as a file directory, are archived by taking snapshots periodically at different points in time and storing them in archive storage service 270.) enables the backed up file system data to be located ([0033]); and
archiving to an archival storage, the first flat set of data ([0035], [0047]; “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane with the teachings of Mandadi by modifying Spillane to more explicit determine to archive the exo-clone files in addition to having backed up the flat data to a second cluster, in a manner similar to the archival of file directories via snapshots of Mandadi. In doing so for an archive purpose and the files now being the same but archival, the determining then being to archive file system data that was backed up from a source system to a storage system, the data blocks now corresponding to a previous archive of the file system, and performing archiving as claimed. Said artisan would have been motivated to do so in order to utilize control given to users to determine where and how to store the data generated (Spillane, [0036], [0042], [0089]) to additionally provide for archival storage for historical retrieval of data (Mandadi, [0033]), e.g. as an incremental backup of a VDFS volume such as the secondary cluster (Spillane, Fig. 3; [0042]) in addition to active backup in clusters of Spillane (Spillane, Fig. 3; [0040]).
Spillane, as previously modified with Mandadi, does not explicitly disclose the file offset, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer.
However, Taivalsaari discloses replacing pointers with offsets to allow a file to be stored and easily relocated in memory ([0030]-[0031], [0038]).
Similar to the application files of Taivalsaari, Spillane discloses that the exo-clone files thereof are stored in-memory of a cluster and are for use with applications on the cluster ([0081]). Also, the exo-clone files are intended to be transferred to other clusters for use ([0048]), and thus needing to be stored in-memory there as well, which may or may not be the same memory location.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane, as previously modified with Mandadi, with the teachings of Taivalsaari, by further modifying Spillane such that the pointers in the files of Spillane are replaced with offsets like is done in the files of Taivalsaari. In doing so, rendering obvious file offsets, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer as claimed. Said artisan would have been motivated to do so in order to more easily relocate the exo-files in different memory locations of different clusters they are transferred to (Taivalsaari, [0038]).
As to claim 12, Spillane discloses a non-transitory computer readable storage medium and comprising computer instructions that, when executed, cause processing circuitry to ([0127], [0137]):
determine to back up file system data from a source system to a storage system (Figs. 3, 6-7; [0021], Lines 20-24; [0041], [0124], A determination is made to backup file system data from one file system to another, e.g. from a primary cluster to a secondary cluster.), wherein the storage system maintains a tree data structure that enables the backed up file system data to be located (Figs. 2, 8; [0021], Lines 20-24, [0055]; [0060], File system tree data is maintained and implemented on a secondary cluster enabling backed up file system data to be located, e.g. in the case of a failover ([0040].).);
serialize a portion of the tree data structure and the file system data into a first flat set of data (Figs. 1, 2, 6-7; [0051], [0074], [0123]-[0124], A exo-clone file, i.e. a first flat set of data, is generated containing changes in a file system. The file thus serializing a portion of the tree data structure [0055] and data [0056] of at least the portion of the file system that has changes since a previous exo-clone file, i.e. a second flat set of data, was generated.), wherein a first data block associated with the first flat set of data includes a file pointer to a first data block associated with a second flat set of data corresponding to a previous back up of the file system data (Figs. 1-2, [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address offset thereto.), , and wherein the file pointer is to a second data block that includes serialized tree data for a root node or an intermediate node of the tree data structure (Figs. 1-2, [0060], [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address with and offset of zero thereto. Since the blocks correspond to the file system tree, at least one block must correspond to a root or intermediate node, and as such it would have been obvious that the first block, which can be any block as claimed, can correspond to the root node or an intermediate node of the tree data structure.); and
sending to the storage system, the first flat set of data (Figs. 3, 6-7; [0124], Exporting an exo-clone file.).
Spillane does not specifically disclose determining to archive the file system data that was backed up, that the second flat set of data corresponds to a previous archive, and archiving to an archival storage, the first flat set of data.
Spillane does however disclose that an exo-clone file (flat set of data) “is just a regular file that can be easily transmitted, stored, backed up, shared, or distributed with other third-party (non-VDFS) systems. For example, an organization can back up a volume to S3 by merely uploading periodically taken exo-clones of that volume to S3 as regular files” ([0036]) and that a user can schedule incremental backups to a cloud storage ([0042]). Thus, it is highly suggested that flat sets of data are intended to also act as archives performed on a periodic basis, i.e. in accordance with some policy, when being used to store with third-party (non-VDFS) systems as desired by a user; and that a user has control on where to store their backups ([0089])
However, Mandadi discloses a method, comprising:
determining to archive file system data from a source system to a storage system ([0035], “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”), wherein the storage system maintains a tree data structure that (Figs. 4A, 5; [0035], [0037] ; [0046]-[0047]; Versioned hierarchical data structures, such as a file directory, are archived by taking snapshots periodically at different points in time and storing them in archive storage service 270.) enables the backed up file system data to be located ([0033]); and
archiving to an archival storage, the first flat set of data ([0035], [0047]; “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane with the teachings of Mandadi by modifying Spillane to more explicitly determine to archive the exo-clone files in addition to having backed up the flat data to a second cluster, in a manner similar to the archival of file directories via snapshots of Mandadi. In doing so for an archive purpose and the files now being the same but archival, the determining then being to archive file system data that was backed up from a source system to a storage system, the data blocks now corresponding to a previous archive of the file system, and performing archiving as claimed. Said artisan would have been motivated to do so in order to utilize control given to users to determine where and how to store the data generated (Spillane, [0036], [0042], [0089]) to additionally provide for archival storage for historical retrieval of data (Mandadi, [0033]), e.g. as an incremental backup of a VDFS volume such as the secondary cluster (Spillane, Fig. 3; [0042]) in addition to active backup in clusters of Spillane (Spillane, Fig. 3; [0040]).
Spillane, as previously modified with Mandadi, does not explicitly disclose the file offset, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer.
However, Taivalsaari discloses replacing pointers with offsets to allow a file to be stored and easily relocated in memory ([0030]-[0031], [0038]).
Similar to the application files of Taivalsaari, Spillane discloses that the exo-clone files thereof are stored in-memory of a cluster and are for use with applications on the cluster ([0081]). Also, the exo-clone files are intended to be transferred to other clusters for use ([0048]), and thus needing to be stored in-memory there as well, which may or may not be the same memory location.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane, as previously modified with Mandadi, with the teachings of Taivalsaari, by further modifying Spillane such that the pointers in the files of Spillane are replaced with offsets like is done in the files of Taivalsaari. In doing so, rendering obvious file offsets, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer as claimed. Said artisan would have been motivated to do so in order to more easily relocate the exo-files in different memory locations of different clusters they are transferred to (Taivalsaari, [0038]).
As to claim 19, Spillane discloses a system, comprising:
a processor configured to ([0127]):
determine to back up file system data from a source system to a storage system (Figs. 3, 6-7; [0021], Lines 20-24; [0041], [0124], A determination is made to backup file system data from one file system to another, e.g. from a primary cluster to a secondary cluster.), wherein the storage system maintains a tree data structure that enables the backed up file system data to be located (Figs. 2, 8; [0021], Lines 20-24, [0055]; [0060], File system tree data is maintained and implemented on a secondary cluster enabling backed up file system data to be located, e.g. in the case of a failover ([0040].).);
serialize a portion of the tree data structure and the file system data into a first flat set of data (Figs. 1, 2, 6-7; [0051], [0074], [0123]-[0124], A exo-clone file, i.e. a first flat set of data, is generated containing changes in a file system. The file thus serializing a portion of the tree data structure [0055] and data [0056] of at least the portion of the file system that has changes since a previous exo-clone file, i.e. a second flat set of data, was generated.), wherein a first data block associated with the first flat set of data includes a file pointer to a first data block associated with a second flat set of data corresponding to a previous back up of the file system data (Figs. 1-2, [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address offset thereto.), and wherein the file pointer is to a second data block that includes serialized tree data for a root node or an intermediate node of the tree data structure (Figs. 1-2, [0060], [0062], Blocks which are duplicates of previous exo-clone files are reclaimed and instead a pointer used to point to an address of a data block in the previous exo-clone files, i.e. an address with and offset of zero thereto. Since the blocks correspond to the file system tree, at least one block must correspond to a root or intermediate node, and as such it would have been obvious that the first block, which can be any block as claimed, can correspond to the root node or an intermediate node of the tree data structure.); and
sending to the storage system, the first flat set of data (Figs. 3, 6-7; [0124], Exporting an exo-clone file.); and
a memory coupled to the processor and configured to provide the processor with instructions ([0127]).
Spillane does not specifically disclose determining to archive the file system data that was backed up, that the second flat set of data corresponds to a previous archive, and archiving to an archival storage, the first flat set of data.
Spillane does however disclose that an exo-clone file (flat set of data) “is just a regular file that can be easily transmitted, stored, backed up, shared, or distributed with other third-party (non-VDFS) systems. For example, an organization can back up a volume to S3 by merely uploading periodically taken exo-clones of that volume to S3 as regular files” ([0036]) and that a user can schedule incremental backups to a cloud storage ([0042]). Thus, it is highly suggested that flat sets of data are intended to also act as archives performed on a periodic basis, i.e. in accordance with some policy, when being used to store with third-party (non-VDFS) systems as desired by a user; and that a user has control on where to store their backups ([0089])
However, Mandadi discloses a method, comprising:
determining to archive file system data from a source system to a storage system ([0035], “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”), wherein the storage system maintains a tree data structure that (Figs. 4A, 5; [0035], [0037] ; [0046]-[0047]; Versioned hierarchical data structures, such as a file directory, are archived by taking snapshots periodically at different points in time and storing them in archive storage service 270.) enables the backed up file system data to be located ([0033]); and
archiving to an archival storage, the first flat set of data ([0035], [0047]; “archival management may determine when snapshots of a hierarchical data structure should be captured, provision appropriate storage locations in archive storage service 270, and direct archive worker nodes (not illustrated) to perform the read, write, and other operations to generate and place the snapshots in archive storage service 270.”).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane with the teachings of Mandadi by modifying Spillane to more explicitly determine to archive the exo-clone files in addition to having backed up the flat data to a second cluster, in a manner similar to the archival of file directories via snapshots of Mandadi. In doing so for an archive purpose and the files now being the same but archival, the determining then being to archive file system data that was backed up from a source system to a storage system, the data blocks now corresponding to a previous archive of the file system, and performing archiving as claimed. Said artisan would have been motivated to do so in order to utilize control given to users to determine where and how to store the data generated (Spillane, [0036], [0042], [0089]) to additionally provide for archival storage for historical retrieval of data (Mandadi, [0033]), e.g. as an incremental backup of a VDFS volume such as the secondary cluster (Spillane, Fig. 3; [0042]) in addition to active backup in clusters of Spillane (Spillane, Fig. 3; [0040]).
Spillane, as previously modified with Mandadi, does not explicitly disclose the file offset, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer.
However, Taivalsaari discloses replacing pointers with offsets to allow a file to be stored and easily relocated in memory ([0030]-[0031], [0038]).
Similar to the application files of Taivalsaari, Spillane discloses that the exo-clone files thereof are stored in-memory of a cluster and are for use with applications on the cluster ([0081]). Also, the exo-clone files are intended to be transferred to other clusters for use ([0048]), and thus needing to be stored in-memory there as well, which may or may not be the same memory location.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Spillane, as previously modified with Mandadi, with the teachings of Taivalsaari, by further modifying Spillane such that the pointers in the files of Spillane are replaced with offsets like is done in the files of Taivalsaari. In doing so, rendering obvious file offsets, wherein the first data block associated with the first flat set of data includes the file offset in place of a pointer as claimed. Said artisan would have been motivated to do so in order to more easily relocate the exo-files in different memory locations of different clusters they are transferred to (Taivalsaari, [0038]).
As to claim 2, the claim is rejected for the same reasons as claim 1 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the storage system determines to archive the file system data according to an archive policy (Spillane, [0042], [0124], Lines 1-6; Regarding scheduled backups and performing periodically; Mandadi, [0047], Archiving performed periodically.).
As to claim 3, the claim is rejected for the same reasons as claim 2 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the archive policy indicates the file system data is to be backed up according to a schedule (Spillane, [0042], [0124], Lines 1-6; Regarding scheduled backups and performing periodically; Mandadi, [0047], Archiving performed periodically.).
As to claims 4, 13, and 20, the claims are rejected for the same reasons as claims 1, 12, and 19 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the tree data structure includes one or more nodes associated with a first backup and one or more nodes associated with one or more previous backups (Spillane, Figs. 1-2; [0051], [0059]-[0060], [0062]; A tree data structure maintained by a storage system will include nodes corresponding to all of a file system tree. This includes both currently changed for a first backup and any previously changed for previous backups. When compared in a snapshot, differences are determined, and those to previous backups are maintained, with respect to a current backup, by pointing to the corresponding block addresses of previous backups.).
As to claims 5 and 14, the claims are rejected for the same reasons as claims 4 and 13 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the portion of the tree data structure corresponds to the one or more nodes associated with the first backup (Spillane, Figs. 1-2; [0051], [0059]-[0060], [0062]; A tree data structure maintained by a storage system will include nodes corresponding to all of a file system tree. This includes both currently changed for a first backup and any previously changed for previous backups. When compared in a snapshot, differences are determined, and those to previous backups are maintained, with respect to a current backup, by pointing to the corresponding block addresses of previous backups.).
As to claims 6 and 15, the claims are rejected for the same reasons as claims 5 and 14 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the first backup is an incremental backup of the source system (Spillane, [0022], [0067], [0089]; Exo-clone files capture differences in volumes from one point in time to another, providing incremental backups of a source system.).
As to claim 7, the claim is rejected for the same reasons as claim 1 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the previous archive of the file system data is an incremental snapshot archive of a previous backup (Spillane, [0022], [0067], [0089]; Exo-clone files capture differences in volumes from one point in time to another via snapshots, providing incremental backups of a source system. As previously modified with Mandadi, the backups can also then be archived, e.g. by performing an archive of the second cluster which is the backup of the source first cluster. Thus, periodic archiving thereof includes previous archives which are incremental snapshots of previous backups.).
As to claim 8, the claim is rejected for the same reasons as claim 1 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein the previous archive of the file system data is a full snapshot archive of a previous backup (Spillane, [0022], [0049], [0067], [0089]; Exo-clone files capture differences in volumes from one point in time to another via snapshots, providing incremental backups of a source system. The ban exo-clone can be “a first exo-clone”. Obviously a first exo-clone, which is generated from a full snapshot, will have no differences since there is no previous backup, and thus would naturally be stored as a full snapshot with subsequent ones being only differences. As previously modified with Mandadi, the backups can also then be archived, e.g. by performing an archive of the second cluster which is the backup of the source first cluster. Thus, periodic archiving thereof includes previous archives which would include a first, full, snapshot from a first backup.).
As to claims 11 and 18, the claims are rejected for the same reasons as claims 1 and 12 above. In addition, Spillane, as previously modified with Mandadi and Taivalsaari, discloses wherein a second data block associated with the first flat set of data includes a second file offset to a third data block associated with the first flat set of data (Fig. 1, #s1004, 1010, 1020; [0052], [0056], A second data block holding a pointer to file data of a third data block in the exo-clone file, e.g. #1020.).
Response to Arguments
Applicant's arguments filed 10/22/2025 have been fully considered but they are not fully persuasive. For Examiner’s response, see discussion below:
(a) At pages 7-8, with respect to the rejection of claim 1 under 35 USC §103, Applicant argues that Rawat teaches away from the using only the file offset in place of a pointer as now claimed in amended claim 1, and similarly 12 and 19 since Rawat discloses the combined use of a storage location with offset as the pointer to a given node.
As to (a), Examiner agrees that Rawat does not disclose only using an offset as claimed, though disagrees in that Rawat does not necessarily teach away from the claimed subject matter since any offset is only useful upon establishing a reference point for the offset, which the storage location pointer performs. However, the point is moot, since a new reference, Taivalsaari, more explicitly replaces pointers with offsets in a file to render the claimed features obvious as set forth in the updated rejection above as necessitated by Applicant’s amendments.
(b) Applicant’s arguments, see page 8, with respect to the dependent claims, are moot in view of the updated rejection to claim 1 as set forth above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kyle (US 6,785,895 B1) discloses using offsets in place of pointers to reference chunks of data to allow for a data structure containing the chunks to be resized without destroying the chunk references (Fig. 2; Col. 5, Lines 40-45; Col. 7, Lines 21-23).
Grachev et al. (US 2012/0159633 A1) discloses using file-relative offsets instead of pointers to link data structures loaded in memory ([0027]).
Rajagopal et al. (US 2005/0229246 A1) discloses a flat data structure (buffer) having pointers replaced by offsets relative to the start of the data structure (Fig. 4; [0096]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES E RICHARDSON whose telephone number is (571)270-1917. The examiner can normally be reached Mon-Fri 9:00-5:30.
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, Robert Beausoliel can be reached at (571) 272-3645. 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.
/James E Richardson/Primary Examiner, Art Unit 2167
Prosecution Insights