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 .
In the event a determination of the status of the application as subject to AIA 35 U.S.C. 102, 103, and 112 (or as subject to pre-AIA 35 U.S.C. 102, 103, and 112) is incorrect, any correction of the statutory basis for a rejection will not be considered a new ground of rejection if the prior art relied upon and/or the rationale supporting the rejection, would be the same under either status.
Notice of Claim Interpretation
Claims in this application are not interpreted under 35 U.S.C. 112(f) unless otherwise noted in an office action.
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.
Claims 1, 4-7, 9, 12, 13, 16, 17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav et al. (US 12,204,419), subsequently referred to as ‘419, in view of Hun et al. (KR 10-2014-0082544) as supported by its translation, Yadav et al. (US 2023/0297477), subsequently referred to as ‘477, and Guise (Data Protection: Ensuring Data Availability).
All references to Hun are to its translation.
In regards to claims 1, 13, and 17, ‘419 teaches an apparatus, comprising:
one or more memories storing processor-executable code (“The computing device may include one or more processors, memory (e.g., random access memory), and persistent storage (e.g., disk drives, solid state drives, etc.). The persistent storage may store computer instructions, e.g., computer code, that (when executed by the processor(s) of the computing device) cause the computing device to perform the functions of the host (100) described herein and/or all, or a portion, of the methods illustrated in FIGS. 2A-3B.”, Col. 4, lines 40-48); and
one or more processors coupled with the one or more memories and individually or collectively operable to execute the code (id.) to cause the apparatus to:
copy, by a data management system at a first time and as part of a metadata backup operation, metadata from a first storage location to a second storage location, the copy of the metadata comprising a backup of the metadata, the metadata comprising information associated with first backup data stored at the data management system (“In Step 608, backup metadata is generated using the file system metadata and a copy of the backup metadata is stored with the file data to generate the full image backup. In one or more embodiments, the data protection agent may generate backup metadata based on the backup and the file system metadata. The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the backup metadata.”, Col. 40, lines 32-40), wherein the first backup data comprises a first backup of one or more target computing objects for which the data management system is configured to provide a backup and recovery service (“In Step 606, file data included in the virtual hard disk file associated with the VM is written to the backup storage.”, Col. 40, lines 22-23; “Initially, in Step 600, obtain a full image backup generation request associated with a virtual machine (VM) from a data protection manager.”, Col. 39, lines 13-15), wherein the metadata is generated by one or more applications used to obtain the first backup data (“The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the backup metadata.”, Col. 40, lines 37-40);
execute, by the data management system, the one or more applications to obtain second backup data, wherein the second backup data comprises a second backup of the one or more target computing objects, and wherein the one or more applications generate additional metadata associated with the second backup data after the first time at which the metadata is copied to the second storage location (“Initially, in Step 620, obtain an incremental image backup generation request associated with a virtual machine (VM) from a data protection manager. In one or more embodiments, the data protection agent may obtain a request to generate an incremental image backup from the data protection manager associated with the VM.”, Col. 42, lines 7-12; “In Step 632, incremental backup metadata is generated using the updated file system metadata and a copy of the incremental backup metadata is stored with the changed blocks to generate the incremental image backup. In one or more embodiments, the data protection agent may generate incremental backup metadata based on the backup and the updated file system metadata. The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the incremental backup metadata.”, Col. 44, lines 43-52);
store one or more incremental metadata changes, the one or more incremental metadata changes associated with changes to the metadata since the first time based at least in part on the additional metadata generated by the one or more applications (“In Step 632, incremental backup metadata is generated using the updated file system metadata and a copy of the incremental backup metadata is stored with the changed blocks to generate the incremental image backup. In one or more embodiments, the data protection agent may generate incremental backup metadata based on the backup and the updated file system metadata. The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the incremental backup metadata.”, Col. 44, lines 43-52); and
copy, at a second time and as part of an incremental metadata backup operation, the one or more incremental metadata changes to the second storage location (“In Step 632, incremental backup metadata is generated using the updated file system metadata and a copy of the incremental backup metadata is stored with the changed blocks to generate the incremental image backup. In one or more embodiments, the data protection agent may generate incremental backup metadata based on the backup and the updated file system metadata. The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the incremental backup metadata.”, Col. 44, lines 43-52), wherein the one or more incremental metadata changes are stored in the second storage location with a timestamp (“In one or more embodiments, the backup metadata repository (126) may include one or more data structures that include information regarding backups of the data generated on the host (100, FIG. 1A). The information may include, for example, for each backup, a backup identifier, a backup generation timestamp, and a storage location included in the backup storage.”, Col. 10, lines 33-39).
‘419 fails to teach that the metadata is stored in accordance with a non-relational database storage format;
store the one or more incremental metadata changes in a temporary storage location while executing the one or more application to obtain the second backup data, wherein the temporary storage location provides for execution of the one or more applications during metadata backup operations; and
wherein copying the one or more incremental metadata changes are from the temporary storage location and while executing the one or more applications to obtain the second backup data, wherein the timestamp indicates the second time at which the one or more incremental metadata changes are copied from the temporary storage location to the second storage location as part of the incremental metadata backup operation.
Hun as supported by its translation teaches that the metadata is stored in accordance with a non-relational database storage format (“As shown in FIG. 2, the first cluster 120 generates snapshot data for NoSQL metadata, temporarily stores the snapshot data in a directory space (/ database / snapshot / SubDirectories), and transmits the snapshot data to the second cluster 140 do.”, page 2, paragraph 10);
store the one or more incremental metadata changes in a temporary storage location (“As shown in FIG. 2, the first cluster 120 generates snapshot data for NoSQL metadata, temporarily stores the snapshot data in a directory space (/ database / snapshot / SubDirectories), and transmits the snapshot data to the second cluster 140 do.”, page 2, paragraph 10); and
wherein copying the one or more incremental metadata changes are from the temporary storage location (“As shown in FIG. 2, the first cluster 120 generates snapshot data for NoSQL metadata, temporarily stores the snapshot data in a directory space (/ database / snapshot / SubDirectories), and transmits the snapshot data to the second cluster 140 do.”, page 2, paragraph 10)
in order “to provide a speed and flexibility to a distributed data management system” (page 2, paragraph 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine ‘419 with Hun as supported by its translation such that the metadata is stored in accordance with a non-relational database storage format;
store the one or more incremental metadata changes in a temporary storage location; and
wherein copying the one or more incremental metadata changes are from the temporary storage location
in order “to provide a speed and flexibility to a distributed data management system” (id.).
‘419 in view of Hun as supported by its translation fails to teach store, while executing the one or more applications to obtain the second backup data, one or more incremental metadata changes, wherein the temporary storage location provides for execution of the more or more applications during metadata backup operations; and
copy, while executing the one or more applications to obtain the second backup data, the one or more incremental metadata changes,
that the timestamp indicates the second time at which the one or more incremental metadata changes are copied from the temporary storage location to the second storage location as part of the incremental metadata backup operation.
‘477 teaches that the timestamp indicates the second time at which the one or more incremental metadata changes are copied to the second storage location as part of the incremental metadata backup operation (“Alternatively, the backup time stamp (126) may reflect a date and/or time at or on which the given backup operation had completed.”, paragraph 0049).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try where the timestamp indicates the second time at which the one or more incremental metadata changes are copied from the temporary storage location to the second storage location as part of the incremental metadata backup operation since both Yadav’s use a timestamp for backup operations, ‘477 teaches two times that the time stamp can reflect (paragraph 0049), and one of ordinary skill in the art could have used either times in the time stamp and would have had a similar expectation of success.
‘419 in view of Hun as supported by its translation and ‘477 fails to teach store, while executing the one or more applications to obtain the second backup data, one or more incremental metadata changes, wherein the temporary storage location provides for execution of the more or more applications during metadata backup operations; and
copy, while executing the one or more applications to obtain the second backup data, the one or more incremental metadata changes.
Guise teaches store, while executing the one or more applications to obtain the second backup data, one or more incremental changes (“As even the most basic of systems become required for 24 ×7 availability, online backups have been becoming the only option for many companies. Such organizations can no longer afford to shut an application down for hours for a backup if it means an end customer will refuse to wait or a vital business process is paused for the duration.”, page 151, paragraph 9), wherein the temporary storage location provides for execution of the more or more applications during metadata backup operations (“Feature-rich operating systems with tight backup integration points may offer the ability to perform filesystem snapshots, presenting the snapshots as quiesced point in time copies to the backup application.”, page 151, paragraph 6); and
copy, while executing the one or more applications to obtain the second backup data, the one or more incremental changes (“As even the most basic of systems become required for 24 ×7 availability, online backups have been becoming the only option for many companies. Such organizations can no longer afford to shut an application down for hours for a backup if it means an end customer will refuse to wait or a vital business process is paused for the duration.”, page 151, paragraph 9)
in order to provide granular recovery options (page 151, paragraph 10).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine ‘419 with Hun as supported by its translation, ‘477, and Guise to include store, while executing the one or more applications to obtain the second backup data, one or more incremental metadata changes, wherein the temporary storage location provides for execution of the more or more applications during metadata backup operations; and
copy, while executing the one or more applications to obtain the second backup data, the one or more incremental metadata changes
in order to provide granular recovery options (id.).
In regards to claims 4, 16, and 20, ‘419 further teaches that, to copy the metadata from the first storage location to the second storage location, the one or more processors are individually or collectively operable to execute the code to cause the apparatus to:
obtain a full backup of the metadata at the first time (“Initially, in Step 600, obtain a full image backup generation request associated with a virtual machine (VM) from a data protection manager.”, Col. 39, lines 13-15).
Guise further teaches that the first time is based at least in part on a first periodicity for full backups of the metadata (“Weekly Full Backups with Daily Incrementals”, Table 12.1 title).
In regards to claim 5, Guise further teaches that copying the one or more incremental changes from the temporary storage location to the second storage location comprises:
obtaining an incremental backup of the data at the second time, wherein the second time is based at least in part on a second periodicity for incremental backups of the data, and wherein the first periodicity is greater than the second periodicity (“Weekly Full Backups with Daily Incrementals”, Table 12.1 title).
In regards to claim 6, ‘419 further teaches that the full backup of the metadata comprises a backup of all entries of a first metadata table in the first storage location at the first time (“In Step 604, file system metadata associated with the VM is obtained. As discussed above, the storage of the host may include file system metadata repository that stores information associated with files of VMs included in the file system of the host generated by user and/or VMs of the host during the performance of computer implemented services. The data protection agent may obtain file system metadata associated with the VM from the file system metadata repository.”, Col. 40, lines 5-12).
Guise further teaches the method further comprising:
obtaining a second full backup of all entries of the first table in the first storage location at a third time (“Weekly Full Backups with Daily Incrementals”, Table 12.1 title).
In regards to claim 7, ‘419 further teaches that the full backup of the metadata comprises a backup of all entries of a first metadata table in the first storage location at the first time (“In Step 604, file system metadata associated with the VM is obtained. As discussed above, the storage of the host may include file system metadata repository that stores information associated with files of VMs included in the file system of the host generated by user and/or VMs of the host during the performance of computer implemented services. The data protection agent may obtain file system metadata associated with the VM from the file system metadata repository.”, Col. 40, lines 5-12).
Guise further teaches the method further comprising:
obtaining a second full backup of all entries of a second table in the first storage location at the first time (“It’s worth noting that a common configuration ‘default’ in many organizations using fulls and incrementals is to run the full backup for everything on the same day.”, page 143, paragraph 4); and
obtaining a second incremental backup of the second table at a third time (“Weekly Full Backups with Daily Incrementals”, Table 12.1 title), wherein the second incremental backup comprises changes to the second metadata table after the first time and before the third time (“Each incremental backup is shown pointing back to the backup taken on the day before it, which indicates it only processes the data that has changed since the last backup.”, page 143, paragraph 6).
In regards to claim 9, Guise further teaches obtaining a second timestamp associated with restoration of the data (“The incremental that was taken immediately following the full backup depends on the full backup in order to offer complete restoration capabilities. The incremental taken after the first incremental requires the first incremental (which in turn requires the full backup) in order to provide complete restoration capabilities.”, page 155, paragraph 1);
identifying, in the second storage location, a full backup of the data that is associated with a third timestamp that is before the second timestamp and is closest to the second timestamp than other timestamps associated with other full backups of the data in the second storage location, wherein the full backup comprises all entries associated with the data (“The incremental that was taken immediately following the full backup depends on the full backup in order to offer complete restoration capabilities. The incremental taken after the first incremental requires the first incremental (which in turn requires the full backup) in order to provide complete restoration capabilities.”, page 155, paragraph 1);
identifying, in the second storage location, one or more incremental backups of the data associated with respective timestamps that are after the third timestamp of the full backup and before the second timestamp, wherein the one or more incremental backups comprise changes to the metadata since the full backup (“The incremental that was taken immediately following the full backup depends on the full backup in order to offer complete restoration capabilities. The incremental taken after the first incremental requires the first incremental (which in turn requires the full backup) in order to provide complete restoration capabilities.”, page 155, paragraph 1); and
restoring the metadata to a state of the metadata at the second timestamp based at least in part on the full backup of the metadata and the one or more incremental backups of the metadata (“The incremental that was taken immediately following the full backup depends on the full backup in order to offer complete restoration capabilities. The incremental taken after the first incremental requires the first incremental (which in turn requires the full backup) in order to provide complete restoration capabilities.”, page 155, paragraph 1).
In regards to claim 12, Hun as supported by its translation further teaches that the metadata comprises non-structured query language metadata (“The first cluster stores and updates the NoSQL metadata.”, abstract).
Claims 2, 3, 14, 15, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Yadav et al. (US 12,204,419) in view of Hun et al. (KR 10-2014-0082544) as supported by its translation, Yadav et al. (US 2023/0297477), Guise (Data Protection: Ensuring Data Availability), and Bhatnagar et al. (US 10,992,768).
In regards to claims 2, 14, and 18, ‘419 in view of Hun as supported by its translation, ‘477, and Guise teaches claims 1, 13, and 17. ‘419 in view of Hun as supported by its translation, ‘477, and Guise fails to teach the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to:
delete, after the second time, the one or more incremental metadata changes from the temporary storage location based at least in part on copying the one or more incremental metadata changes to the second storage location.
Bhatnagar teaches the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to:
delete, after the second time, the one or more incremental metadata changes from the temporary storage location based at least in part on copying the one or more incremental metadata changes to the second storage location (“Responsive to determining that the size of the given cloud object part is the same as the size of the given portion of the at least one snapshot, the checkpointing information in the checkpointing cache may be updated to indicate that the given portion of the at least one snapshot has been successfully copied to the cloud storage and the given portion of the at least one snapshot may be removed from the resume snapshot differential.”, Col. 15, lines 17-24).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine ‘419 with Hun as supported by its translation, ‘477, Guise, and Bhatnagar such that the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to:
delete, after the second time, the one or more incremental metadata changes from the temporary storage location based at least in part on copying the one or more incremental metadata changes to the second storage location
in order to reduce storage space utilization.
In regards to claims 3, 15, and 19, ‘419 further teaches that the one or more processors are individually or collectively further operable to execute the code to cause the apparatus to:
store one or more second incremental metadata changes, the one or more second incremental metadata changes associated with changes to the metadata after the second time and before a third time based at least in part on further execution of the one or more applications (“In Step 632, incremental backup metadata is generated using the updated file system metadata and a copy of the incremental backup metadata is stored with the changed blocks to generate the incremental image backup. In one or more embodiments, the data protection agent may generate incremental backup metadata based on the backup and the updated file system metadata. The data protection manager may generate and include checksums (discussed below) associated with the files included in the backup and include the checksums in the incremental backup metadata.”, Col. 44, lines 43-52; “In Step 622, a checkpoint of the VM is generated. In one or more embodiments, the data protection agent may generate or initiate generation of a checkpoint of the VM associated with the image backup. In one or more embodiments, a VM checkpoint may refer to a differencing file or snapshot that captures the state, data, and/or hardware configuration of a VM in operation. The checkpoint may insure that the image of the VM is good and will not change during the generation of the backup.”, Col. 42, lines 53-61); and
copy, at the third time, the one or more second incremental metadata changes to the second storage location (“In Step 634, the incremental backup metadata and a copy of the backup is provided to indexing engine for indexing. In one or more embodiments, the data protection agent sends the incremental backup metadata and a copy of the backup to the indexing engines (not shown in FIGS. 1A-1C).”, Col. 45, lines 56-60), wherein the one or more second incremental metadata changes are stored with a second timestamp that indicates the third time (“In one or more embodiments, the backup metadata repository (126) may include one or more data structures that include information regarding backups of the data generated on the host (100, FIG. 1A). The information may include, for example, for each backup, a backup identifier, a backup generation timestamp, and a storage location included in the backup storage.”, Col. 10, lines 33-39).
Hun as supported by its translation further teaches store the one or more second incremental metadata changes in the temporary storage location after the one or more incremental metadata changes are deleted from the temporary storage location (“As shown in FIG. 2, the first cluster 120 generates snapshot data for NoSQL metadata, temporarily stores the snapshot data in a directory space (/ database / snapshot / SubDirectories), and transmits the snapshot data to the second cluster 140 do.”, page 2, paragraph 10); and
copying, at the third time, the one or more second incremental metadata changes from the temporary storage location (“As shown in FIG. 2, the first cluster 120 generates snapshot data for NoSQL metadata, temporarily stores the snapshot data in a directory space (/ database / snapshot / SubDirectories), and transmits the snapshot data to the second cluster 140 do.”, page 2, paragraph 10).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav et al. (US 12,204,419) in view of Hun et al. (KR 10-2014-0082544) as supported by its translation, Yadav et al. (US 2023/0297477), Guise (Data Protection: Ensuring Data Availability), and Crawford et al. (US 2014/0351534).
In regards to claim 8, ‘419 further teaches obtaining, from the first storage location, the additional metadata generated by the one or more applications and a first timestamp associated with the additional metadata, wherein the timestamp is based at least in part on the first timestamp (“The protection policy may be a data structure that specifies backup requirements (e.g., a backup schedule specifying points in time to generate backups, backup storage information associated with one or more backup storages to store the backup and/or portions of the backup, etc.).”, Col. 39, lines 35-40).
‘419 in view of Hun as supported by its translation, ‘477, and Guise fails to teach calibrating a clock associated with the second storage location based at least in part on the first timestamp obtained from the first storage location; and
generating, based at least in part on the calibrated clock, one or more second timestamps for storage with one or more second incremental metadata changes performed at one or more third times.
Crawford teaches calibrating a clock associated with the second storage location based at least in part on the first timestamp obtained from the first storage location (“The clock of the primary storage controller may also have a drift 606 (e.g., the time shown by the clock may potentially drift, i.e., deviate, by 0.05 second during the elapsed time).”, paragraph 0046); and
generating, based at least in part on the calibrated clock, one or more second timestamps for storage with one or more second incremental metadata changes performed at one or more third times (“To calculate the time with which to timestamp the point-in-time copy, the host timestamp on last host I/O operation 602 is added to the time elapsed in the primary storage controller 102 since the last host I/O operation 604, and the drift 606 is subtracted.”, paragraph 0046)
in order that “disaster recovery from the mirrored copies of the data is significantly faster” (paragraph 0024).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine ‘419 with Hun as supported by its translation, ‘477, Guise, and Crawford to include calibrating a clock associated with the second storage location based at least in part on the first timestamp obtained from the first storage location; and
generating, based at least in part on the calibrated clock, one or more second timestamps for storage with one or more second incremental metadata changes performed at one or more third times
in order that “disaster recovery from the mirrored copies of the data is significantly faster” (id.).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Yadav et al. (US 12,204,419) in view of Hun et al. (KR 10-2014-0082544) as supported by its translation, Yadav et al. (US 2023/0297477), Guise (Data Protection: Ensuring Data Availability), and Subramanyam et al. (US 2019/0005059).
In regards to claim 11, ‘419 in view of Hun as supported by its translation, ‘477, and Guise teaches claim 1. ‘419 in view of Hun as supported by its translation, ‘477, and Guise fails to teach that the metadata and the one or more incremental metadata changes are stored in a sorted strings table format in the second storage location, the sorted strings table format indexed by respective timestamps associated with each entry of the sorted strings table format. Subramanyam teaches that the metadata and the one or more incremental metadata changes are stored in a sorted strings table format in the second storage location, the sorted strings table format indexed by respective timestamps associated with each entry of the sorted strings table format (“In scenario 1000, backup system 301 uses timestamps for data entries within SSTables rather than ancestor information to determine whether an SSTable should be stored to data repository 321.”, paragraph 0055) which “mitigates the storage space inefficiencies caused when incrementally backing up a compaction based database system” (paragraph 0025). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine ‘419 with Hun as supported by its translation, ‘477, Guise, and Subramanyam such that the metadata and the one or more incremental metadata changes are stored in a sorted strings table format in the second storage location, the sorted strings table format indexed by respective timestamps associated with each entry of the sorted strings table format which “mitigates the storage space inefficiencies caused when incrementally backing up a compaction based database system” (id.).
Response to Arguments
Applicant's arguments filed 5 March 2026 have been fully considered but they are not persuasive. While Guise does recognize disadvantages of online backups, such disadvantages are insufficient to constitute “teaching away” from the obviousness combination. Guise is merely recognizing tradeoffs between offline and online backups. Guise does teach using a filesystem snapshot for online backups (page 151, paragraph 6), which is in addition to Hun’s teaching of storing snapshot data temporarily in directory space (page 2, paragraph 10).
Conclusion
THIS ACTION IS MADE FINAL. 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 NATHAN SADLER whose telephone number is (571)270-7699. The examiner can normally be reached Monday - Friday 8am - 5pm.
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, Reginald Bragdon can be reached at (571)272-4204. 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.
/Nathan Sadler/Primary Examiner, Art Unit 2139 24 March 2026