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 .
This is Non-Final Office Action in response to application filed on April 11, 2025 in which claims 1-20 are presented for examination.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claims recite “obtaining/obtain, by a computing system, one or more hint bits for a B-tree index page of a database; determining/determine, by the computing system and using the one or more hint bits, that a threshold amount of tuples of the B-tree index page are dead; and generating/generate, by the computing system and using the B-tree index page, a list of dead tuples; determining/determine, by the computing system and based on each tuple in the list of dead tuples, a transaction identifier; deleting/delete, by the computing system and from the B-tree index page, each tuple in the list of dead tuples; and generating/generate, by the computing system and using the transaction ID, a write-ahead logging record for the deletion of each tuple in the list of dead tuples”. This judicial exception is not integrated into a practical application because the steps can be performed manually in human mind. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the claim here merely uses generic “processor”, “computing system” or “processing hardware” as a tool to perform the otherwise mental processes. See October Update at Section I(C)(ii). Thus, the limitations recite concepts that fall into the “mental process” grouping of abstract ideas.
ANALYSIS under Revised Guidance of 2019 PEG:
Statutory Category:
The claims 1-20 are directed to one of the four statutory category (claims 1-9 a method or a process, claims 10-18 a system or a machine and claims 19-20 a non-transitory computer readable medium).
Step 2A – Prong 1: Judicial Exception Recited?
The claim 1 recites the limitations of “obtaining, by a computing system, one or more hint bits for a B-tree index page of a database, each hint bit of the one or more hint bit representing a status of a corresponding tuple of the B-tree index page; determining, by the computing system and using the one or more hint bits, that a threshold amount of tuples of the B-tree index page are dead; and responsive to determining that the threshold amount of tuples of the B-tree index page are dead: generating, by the computing system and using the B-tree index page, a list of dead tuples; determining, by the computing system and based on each tuple in the list of dead tuples, a transaction identifier; deleting, by the computing system and from the B-tree index page, each tuple in the list of dead tuples; and generating, by the computing system and using the transaction ID, a write-ahead logging record for the deletion of each tuple in the list of dead tuples.” The limitations, as drafted, are steps or processes that, under their broadest reasonable interpretation, cover performance of the limitations in mind. That is, nothing in the claim 1 precludes the processes (the steps …) from practically being performed in the human mind. The claim 1 encompasses the limitations of the processes or steps of “obtaining, determining, generating, determining, deleting and generating a write-ahead logging” The user manually use the data and does not take the claimed limitations out of the mental processes, which is one of the groupings of abstract ideas. Thus, the claim 1 recites an abstract idea under one of groupings of abstract idea, mental processes (concepts performed in the human mind including an evaluation, judgment, opinion, observation).
Step 2A – Prong 2: integrated into a practical application? Claim 1 does not recite any additional elements that integrate the abstract idea into a practical application.
Step 2B: The claim does not provide an incentive concept. Claim 1 recites: obtaining hint bit for B-tree index page by a generic computing system and generating a list of dead tuples, deleting each tuple in the list of dead tuples and generating a write-ahead logging. The claim basically recites a known data structure “B-tree index page” and a known data techniques: “hint bits”, “dead tuples”, “thresholds” and “write-ahead logging. Each step is described functionally, without a new data structure, a new algorithm, a specific memory layout, a concurrency or locking improvement, or a demonstrated performance mechanism. Furthermore, the claim does not specify” how hint bits are encoded or updated, how the threshold is calculated, how logging is reduced, reordered, or optimized, or how index-page behavior is altered at a low level. Instead, it describes what to do, not how it is technically done in a non-conventional way. In conclusion, the additional elements merely recite well-understood, routine, and conventional database operations performed by a generic computing system. Accordingly, these recitations do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to the abstract idea.
Claims 10 and 19 are rejected due to the similar analysis of claim 1. Claims 2-9, 11-18 and 20 do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element in claims 2-9, 11-18 and 20 represent a further mental process step. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer component, then it falls within the “mental processes” group of abstract ideas. Each additional step is considered an abstract idea (mental process step) and does not integrate the judicial exception into a practical application. An additional abstract idea (mental process step) is not sufficient to amount to significantly more than the judicial exception. Therefore, claims 1-20 are not patent eligible.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Dietterich et al. (US 20180060369 A1) in view of Shuf et al. (US 6886085 B1) and further in view of Birka et al. (US 20230008732 A1).
Regarding claim 1, Dietterich discloses a computer-implemented method comprising:
determining, by the computing system (host system of Fig.1, Dietterich), that a threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0054]-[0056], Dietterich, i.e., determining when to permanently remove garbage data (e.g., data that is no longer referenced or obsolete corresponding “tuples of page are dead”) when the amount of garbage data reaches a threshold); and
responsive to determining that the threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0038], Dietterich):
generating, by the computing system and using the B-tree index page (host system of Fig.1 and ¶[0019], Dietterich), a list of dead tuples (step 420 of Fig.4 and ¶[0038]-[0039], Dietterich, i.e., generating delete invalid tuple set “dead tuples”);
determining, by the computing system and based on each tuple in the list of dead tuples, a transaction identifier (¶[0035]-[0038], Dietterich, i.e., tuple transaction including tuple identifier “TID”);
deleting each tuple in the list of dead tuples (¶[0043]-[0044], Dietterich, i.e., performing on delete operations such as delete tuples); and
Dietterich, however, does not explicitly disclose obtaining one or more hint bits for a B-tree index page of a database and generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Shuf discloses obtaining one or more hint bits for a B-tree index page of a database (col.15, lines 23-37, Shuf, i.e., state of an appropriate hint bit is obtained and examined for the page), each hint bit of the one or more hint bit representing a status of a corresponding tuple of the B-tree index page (Fig.14; col.11, line 37 to col.12, line 21 and col.15, lines 23-37, Shuf, i.e., conditions under which hint bits are set) and generating a write back logging record (col.16, lines 10-48, Shuf).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having both Dietterich and Shuf before them to cooperate the hint bits of Shuf into Dietterich, as taught by Shuf. One of ordinary skill in the art would be motivated to integrate hint bits of the stack pages into Dietterich, with a reasonable expectation of success, in order to enhance virtual memory management using garbage collection (col.5, line 62 to col.6, line 8, Shuf).
Modified Dietterich, however, does not explicitly disclose generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Birka discloses generating, by the computing system and using the transaction ID (system 100 and using indicator of position in the log “transaction ID”), a write-ahead logging record for the deletion of each tuple in the list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka, generating a write-ahead log in which transactions are recorded before the changes to the data stored in the database are made permanent).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having the modified Dietterich and Birka before them to cooperate the write-ahead log of Birka into the modified Dietterich, as taught by Birka. One of ordinary skill in the art would be motivated to integrate write-ahead log using hint bits of the stack pages into the modified Dietterich, with a reasonable expectation of success, in order to enhance database system, specifically frees up resources in the database system (¶[0014], Birka).
Regarding claim 2, Dietterich/Shuf/Birka combination discloses wherein determining the transaction ID comprises determining, for each respective tuple in the list of dead tuples, an ID of a transaction that deleted the respective tuple (¶[0031]-[0033] and [0053]-[0054], Dietterich).
Regarding claim 3, Dietterich/Shuf/Birka combination discloses determining, by the computing system, that a second B-tree index page of the database is evicted from a shared buffer cache (col.6, line 65 to col.7, line 5 and col.15, lines 23-37, Shuf); and responsive to determining that the second B-tree index page is evicted from the shared buffer cache: generating a second list of dead tuples; determining, by the computing system and based on each tuple in the second list of dead tuples, a second transaction identifier (¶[0037], [0041]-[0043], [0061] and [0089], Birka); deleting each tuple in the second list of dead tuples; and generating a second write-ahead logging record for the deletion of each tuple in the second list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 4, Dietterich/Shuf/Birka combination discloses pushing a buffer tag uniquely identifying the second B-tree index page of the database into a queue (col.16, line 64 to col. 17, line 7, Shuf); reading the buffer tag (¶[0036]-[0037], Birka); and responsive to reading the buffer tag, retrieving the second B-tree index page (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 5, Dietterich/Shuf/Birka combination discloses determining that a second B-tree index page of the database is full and has at least one dead tuple (¶[0043]-[0045], Birka); and responsive to determining that the second B-tree index page is full and has at least one dead tuple: generating a second list of dead tuples (¶[0043]-[0045], Birka); determining a second transaction identifier (¶[0043]-[0045], Birka); deleting each tuple in the second list of dead tuples (¶[0043]-[0045], Birka); and generating, by the computing system and using the second transaction identifier, a second write-ahead logging record for the deletion of each tuple in the second list of dead tuples (¶[0037, [0041] and [0061], Birka).
Regarding claim 6, Dietterich/Shuf/Birka combination discloses determining that a second threshold amount of tuples of a plurality of B-tree index pages are dead (¶[0043], [0061] and [0089], Birka); and deleting each tuple in the list of dead tuples is further based on determining that the second threshold amount of tuples of the plurality of B-tree index pages are dead (¶[0043], [0061] and [0089], Birka).
Regarding claim 7, Dietterich/Shuf/Birka combination discloses wherein determining that the second threshold amount of tuples of the plurality of B-tree index pages are dead comprises comparing a current cumulative count of dead tuples with a past cumulative count of dead tuples (¶[0053]-[0056], Dietterich).
Regarding claim 8, determine that the threshold amount of tuples of a second B-tree index page are dead; responsive to determining that the threshold amount of tuples of the second B-tree index page are dead, generating a second list of dead tuples; while generating the second list of dead tuples (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka), determine that a threshold amount of time has passed; and responsive to determining that the threshold amount of time has passed, halt generation of the second list of dead tuples (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 9, Dietterich/Shuf/Birka combination discloses wherein: the B-tree index page is stored at a shared buffer cache; and the shared buffer cache stores a plurality of B-tree index pages for a plurality of databases (¶[0046] and [0056]-[0057], Dietterich).
Regarding claim 10, Dietterich discloses a system (system of Fig.1, Dietterich) comprising: data processing hardware; and memory hardware in communication with the data processing hardware, the memory hardware storing instructions that when executed on the data processing hardware cause the data processing hardware to: determining, by the computing system (host system of Fig.1, Dietterich), that a threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0054]-[0056], Dietterich, i.e., determining when to permanently remove garbage data (e.g., data that is no longer referenced or obsolete corresponding “tuples of page are dead”) when the amount of garbage data reaches a threshold); and
responsive to determining that the threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0038], Dietterich):
generating, by the computing system and using the B-tree index page (host system of Fig.1 and ¶[0019], Dietterich), a list of dead tuples (step 420 of Fig.4 and ¶[0038]-[0039], Dietterich, i.e., generating delete invalid tuple set “dead tuples”);
determining, by the computing system and based on each tuple in the list of dead tuples, a transaction identifier (¶[0035]-[0038], Dietterich, i.e., tuple transaction including tuple identifier “TID”);
deleting each tuple in the list of dead tuples (¶[0043]-[0044], Dietterich, i.e., performing on delete operations such as delete tuples); and
Dietterich, however, does not explicitly disclose obtaining one or more hint bits for a B-tree index page of a database and generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Shuf discloses obtaining one or more hint bits for a B-tree index page of a database (col.15, lines 23-37, Shuf, i.e., state of an appropriate hint bit is obtained and examined for the page), each hint bit of the one or more hint bit representing a status of a corresponding tuple of the B-tree index page (Fig.14; col.11, line 37 to col.12, line 21 and col.15, lines 23-37, Shuf, i.e., conditions under which hint bits are set) and generating a write back logging record (col.16, lines 10-48, Shuf).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having both Dietterich and Shuf before them to cooperate the hint bits of Shuf into Dietterich, as taught by Shuf. One of ordinary skill in the art would be motivated to integrate hint bits of the stack pages into Dietterich, with a reasonable expectation of success, in order to enhance virtual memory management using garbage collection (col.5, line 62 to col.6, line 8, Shuf).
Modified Dietterich, however, does not explicitly disclose generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Birka discloses generating, by the computing system and using the transaction ID (system 100 and using indicator of position in the log “transaction ID”), a write-ahead logging record for the deletion of each tuple in the list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka, generating a write-ahead log in which transactions are recorded before the changes to the data stored in the database are made permanent).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having the modified Dietterich and Birka before them to cooperate the write-ahead log of Birka into the modified Dietterich, as taught by Birka. One of ordinary skill in the art would be motivated to integrate write-ahead log using hint bits of the stack pages into the modified Dietterich, with a reasonable expectation of success, in order to enhance database system, specifically frees up resources in the database system (¶[0014], Birka).
Regarding claim 11, Dietterich/Shuf/Birka combination discloses wherein determining the transaction ID comprises determining, for each respective tuple in the list of dead tuples, an ID of a transaction that deleted the respective tuple (¶[0031]-[0033] and [0053]-[0054], Dietterich)
Regarding claim 12, Dietterich/Shuf/Birka combination discloses determining, by the computing system, that a second B-tree index page of the database is evicted from a shared buffer cache (col.6, line 65 to col.7, line 5 and col.15, lines 23-37, Shuf); and responsive to determining that the second B-tree index page is evicted from the shared buffer cache: generating a second list of dead tuples; determining, by the computing system and based on each tuple in the second list of dead tuples, a second transaction identifier (¶[0037], [0041]-[0043], [0061] and [0089], Birka); deleting each tuple in the second list of dead tuples; and generating a second write-ahead logging record for the deletion of each tuple in the second list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 13, Dietterich/Shuf/Birka combination discloses pushing a buffer tag uniquely identifying the second B-tree index page of the database into a queue (col.16, line 64 to col. 17, line 7, Shuf); reading the buffer tag (¶[0036]-[0037], Birka); and responsive to reading the buffer tag, retrieving the second B-tree index page (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 14, Dietterich/Shuf/Birka combination discloses determining that a second B-tree index page of the database is full and has at least one dead tuple (¶[0043]-[0045], Birka); and responsive to determining that the second B-tree index page is full and has at least one dead tuple: generating a second list of dead tuples (¶[0043]-[0045], Birka); determining a second transaction identifier (¶[0043]-[0045], Birka); deleting each tuple in the second list of dead tuples (¶[0043]-[0045], Birka); and generating, by the computing system and using the second transaction identifier, a second write-ahead logging record for the deletion of each tuple in the second list of dead tuples (¶[0037, [0041] and [0061], Birka).
Regarding claim 15, Dietterich/Shuf/Birka combination discloses determining that a second threshold amount of tuples of a plurality of B-tree index pages are dead (¶[0043], [0061] and [0089], Birka); and deleting each tuple in the list of dead tuples is further based on determining that the second threshold amount of tuples of the plurality of B-tree index pages are dead (¶[0043], [0061] and [0089], Birka)
Regarding claim 16, Dietterich/Shuf/Birka combination discloses wherein determining that the second threshold amount of tuples of the plurality of B-tree index pages are dead comprises comparing a current cumulative count of dead tuples with a past cumulative count of dead tuples (¶[0053]-[0056], Dietterich).
Regarding claim 17, determine that the threshold amount of tuples of a second B-tree index page are dead; responsive to determining that the threshold amount of tuples of the second B-tree index page are dead, generating a second list of dead tuples; while generating the second list of dead tuples (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka), determine that a threshold amount of time has passed; and responsive to determining that the threshold amount of time has passed, halt generation of the second list of dead tuples (¶[0036]-[0037], [0041]-[0043], [0061] and [0089], Birka).
Regarding claim 18, Dietterich/Shuf/Birka combination discloses wherein: the B-tree index page is stored at a shared buffer cache; and the shared buffer cache stores a plurality of B-tree index pages for a plurality of databases (¶[0046] and [0056]-[0057], Dietterich).
Regarding claim 19, Dietterich discloses a non-transitory computer-readable storage medium encoded with instructions that, when executed by one or more processors of a computing system (system of Fig.1, Dietterich), cause the one or more processors to: determining, by the computing system (host system of Fig.1, Dietterich), that a threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0054]-[0056], Dietterich, i.e., determining when to permanently remove garbage data (e.g., data that is no longer referenced or obsolete corresponding “tuples of page are dead”) when the amount of garbage data reaches a threshold); and
responsive to determining that the threshold amount of tuples of the B-tree index page are dead (¶[0016] and [0038], Dietterich):
generating, by the computing system and using the B-tree index page (host system of Fig.1 and ¶[0019], Dietterich), a list of dead tuples (step 420 of Fig.4 and ¶[0038]-[0039], Dietterich, i.e., generating delete invalid tuple set “dead tuples”);
determining, by the computing system and based on each tuple in the list of dead tuples, a transaction identifier (¶[0035]-[0038], Dietterich, i.e., tuple transaction including tuple identifier “TID”);
deleting each tuple in the list of dead tuples (¶[0043]-[0044], Dietterich, i.e., performing on delete operations such as delete tuples); and
Dietterich, however, does not explicitly disclose obtaining one or more hint bits for a B-tree index page of a database and generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Shuf discloses obtaining one or more hint bits for a B-tree index page of a database (col.15, lines 23-37, Shuf, i.e., state of an appropriate hint bit is obtained and examined for the page), each hint bit of the one or more hint bit representing a status of a corresponding tuple of the B-tree index page (Fig.14; col.11, line 37 to col.12, line 21 and col.15, lines 23-37, Shuf, i.e., conditions under which hint bits are set) and generating a write back logging record (col.16, lines 10-48, Shuf).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having both Dietterich and Shuf before them to cooperate the hint bits of Shuf into Dietterich, as taught by Shuf. One of ordinary skill in the art would be motivated to integrate hint bits of the stack pages into Dietterich, with a reasonable expectation of success, in order to enhance virtual memory management using garbage collection (col.5, line 62 to col.6, line 8, Shuf).
Modified Dietterich, however, does not explicitly disclose generating a write-ahead logging record for the deletion of each tuple in the list of dead tuples.
Birka discloses generating, by the computing system and using the transaction ID (system 100 and using indicator of position in the log “transaction ID”), a write-ahead logging record for the deletion of each tuple in the list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka, generating a write-ahead log in which transactions are recorded before the changes to the data stored in the database are made permanent).
It would have been obvious to a person having ordinary skill in the art before the effective filing date, having the modified Dietterich and Birka before them to cooperate the write-ahead log of Birka into the modified Dietterich, as taught by Birka. One of ordinary skill in the art would be motivated to integrate write-ahead log using hint bits of the stack pages into the modified Dietterich, with a reasonable expectation of success, in order to enhance database system, specifically frees up resources in the database system (¶[0014], Birka).
Regarding claim 20, Dietterich/Shuf/Birka combination discloses determining, by the computing system, that a second B-tree index page of the database is evicted from a shared buffer cache (col.6, line 65 to col.7, line 5 and col.15, lines 23-37, Shuf); and responsive to determining that the second B-tree index page is evicted from the shared buffer cache: generating a second list of dead tuples; determining, by the computing system and based on each tuple in the second list of dead tuples, a second transaction identifier (¶[0037], [0041]-[0043], [0061] and [0089], Birka); deleting each tuple in the second list of dead tuples; and generating a second write-ahead logging record for the deletion of each tuple in the second list of dead tuples (¶[0037], [0041]-[0043], [0061] and [0089], Birka).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Horsnell et al. (US 20250209007 A1) disclose cache-line retention hint information for conditional write instruction.
Astolfi (US 12271625 B1) discloses key-value engine.
He et al. (US 20240370426 A1) disclose adaptive auto garbage collector in MVCC database system.
Zuo et al. (US 20240078179 A1) disclose efficient write-back for journal truncation.
Campbell et al. (US 20220050792 A1) disclose determining page size via page table cache.
Chinthekindi et al. (US 11093387 B1) disclose garbage collection based on transmission object models.
Hopcroft et al. (US 10733164 B2) disclose updating a bit vector search index.
Varadarajan et al. (US 20200142878 A1) disclose staging anchor trees for improved concurrency and performance in page range index management.
Ma et al. (US 20170277635 A1) disclose conditional data caching transactional memory in a multiple processor system.
Yu et al. (US 20080082721 A1) disclose data cache virtual hint way prediction and applications thereof.
Zwilling et al. (US 7395278 B2) disclose transaction consistent copy-on-write database.
Noel et al. (US 6804766 B1) disclose method for managing pages of a designated memory object according to selected memory management policies.
Kuiper (US 6324631 B1) discloses method and system for detecting and coalescing free areas during garbage collection.
Karkhanis et al. (US 6085296 A) disclose sharing memory pages and page tables among computer processes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANH B THAI whose telephone number is (571)272-4029. The examiner can normally be reached Mon-Friday 7-4: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, Tony Mahmoudi can be reached at 571-272-4078. 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.
/HANH B THAI/Primary Examiner, Art Unit 2163
February 4, 2026