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 Office action is in response to the arguments and remarks, filed on 6/29/2026, in which claim(s) 1-8 is/are presented for further examination.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-8, filed on 6/29/2026, have been fully considered but they are not persuasive. Accordingly, this action has been made FINAL.
Applicant argues:
PNG
media_image1.png
386
610
media_image1.png
Greyscale
See the middle of page 12 to the bottom of page 12 of applicant’s remarks, filed on 6/29/2026.
The examiner respectfully disagrees. Applicant argues that Plenderlith does not disclose “… the integration device 100 has a first server 101, a first storage 102, second servers 103, and second storages 104. The first server 101, the first storage 102, the second servers 103, and the second storages 104 are coupled in a manner that allows communication to and from one another”.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., a “first server”, a “first storage”, “second servers” and “second storages”) are not recited in any of rejected claim(s) 1-8. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Applicant argues:
PNG
media_image2.png
170
592
media_image2.png
Greyscale
See the top of page 15 of applicant’s remarks, filed on 6/29/2026.
The examiner would like to point out the that claim 1 recites “An integration device, comprising a processor and a memory and being configured to hold communication to and from a plurality of devices”. The claim has not defined the “processor” as a “first server”, the memory” as a “first storage”, the “plurality of devices” as the “second servers and second storages”. The examiner would also like to point out that the Office action does not cite Plenderlith, Fig. 1 for disclosing claim 1. Plenderleith, Fig. 10 discloses processors 1010A, 1010B … 1010N, where at least one of the processors is interpreted to be the “processor” claimed, system memory 1020, which is being interpreted as the “memory” claimed and electronic device(s) 1060, which is plural, which is being interpreted as the “plurality of devices” claimed.
Applicant argues:
PNG
media_image3.png
476
898
media_image3.png
Greyscale
See the top of page 16 of applicant’s remarks, filed on 6/29/2026.
The examiner respectfully disagrees. The examiner would like to point out that the claim language recites “the plurality of devices each including a database”. There is no requirement in the claim language that the entire contents of the database need be at each of the “plurality of devices”. Plenderleith, Col. 2, lines 6-16 discloses different tables of a database and/or data from a single table of a database can be distributed across multiple database instances, where each database instance is of the same database and includes data from the database. Plenderleith, Col. 2, lines 35-63 discloses migrating a database running on a single server that has multiple tables to multiple databases on multiple servers, which discloses multiple servers each with the same database in the single server and storing data therefrom. Thus, the combination of Plenderleith and Nhan discloses “the plurality of devices each including a database” as recited.
Applicant argues:
PNG
media_image4.png
564
896
media_image4.png
Greyscale
See the middle of to the bottom of page 16 of applicant’s remarks, filed on 6/29/2026.
The examiner respectfully disagrees. The examiner would like to note the last Office action did not rely on Nhan disclosing “a second integrated table is generated by associating the table name, the changed-to DB name, and the DB area ID with one another for each database”.
Plenderleith, Col. 6, lines 11-26 discloses each database instance 122A-122N has a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100), where the disclosed database instance identifiers are interpreted as the “changed-to DB name(s) with one another for each database”.
Plenderleith, Col. 10, lines 42-58 discloses the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 [i.e., interpreted as the “DB area ID”] that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure [i.e., interpreted as the “second integrated table”] that associates an identifier of a particular table with an identifier of a database instance [i.e., which discloses “associating the table names with one another for each database”] 122 (e.g., its network address, its unique identifier within the context of the database service 110, or the like), where the rough layout schema/schema name must be obtained/acquired to know how to format the tables on the second database instance, the database instance identifier/table name must be obtained/acquired to know what table(s) to copy to the second database instance and the table location data/where the table(s) are located/network address/DB area ID must be obtained/acquired to know where to retrieve the table(s) from to copy to the second database instance, which discloses “associating the DB area ID with one another for each database”.
Nhan, Col. 25, lines 12-46 discloses the remote name of the “Orders” table has been changed to “Table B,” the schema region 150 is updated to reflect the remote name change, see name table name of “Orders” is changed to “Table B” for schema region 150. This discloses “by associating a changed-to schema name” as recited.
Note: Where the schema name, the table name and the DB area ID are stored does not patentably distinguish the invention. The same result occurs no matter where this data is stored. The table generated on the second database instance with its corresponding )
Thus, the combination of Plenderleith and Nhan discloses “a second integrated table is generated by associating a changed-to schema name, the table name, the changed-to DB name, and the DB area ID with one another for each database” as recited.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Plenderleith, US 11,461,322 B1 (hereinafter “Plenderleith”) in view of Nhan et al., US 11,232,120 B1 (hereinafter “Nhan”).
Claims 1, 7 and 8
Plenderleith discloses an integration device, comprising a processor and a memory and being configured to hold communication to and from a plurality of devices, the processor being configured to execute a program, the memory being configured to store the program (Plenderleith, Fig. 10, see processors 1010A, 1010B … 1010N, system memory 1020 and electronic device(s) 1060 [i.e., “plurality of devices”]), the plurality of devices each including a database (Plenderleith, Col. 2, lines 6-16, see different tables of a database and/or data from a single table of a database can be distributed across multiple database instances; and Plenderleith, Col. 2, lines 35-63, see a database partitioning service may migrate a database running on a single server that has multiple tables to multiple databases on multiple servers [i.e., the multiple servers each with a database correspond to the “plurality of devices each including a database”] with a single table per database or a proper subset of the tables per database),
wherein each of the plurality of devices includes a first table, a second table, and a third table (Plenderleith, Col. 2, lines 35-63, see a database running on a single server that has multiple tables to multiple databases on multiple servers with a single table per database or a proper subset of the tables per database; Plenderleith, Col. 6, lines 27-50, see a first database instance 122A and a second database instance 122B may be a master-failover pair, a primary database and a read replica [i.e., where a replica means a copy, where, when the first database instance has 3 tables the second database instance also has 3 tables]; and Plenderleith, Fig. 1, see in “source” database instance 122A, table ‘A’ 124A, table ‘B’ 124B and table ‘C’ 124C),
wherein the first table includes a DB name which is a name of the database (Plenderleith, Col. 6, lines 11-26, see each database instance 122A-122N may have a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100) the database instance 122A-122N during interactions between the user and the database service 110 interfaces), and storage location information about storage location of the database in the each of the plurality of devices (Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address, its unique identifier within the context of the database service 110, or the like)),
wherein the second table includes a schema name which is a name of a schema for managing one or more tables in the each of the plurality of devices (Plenderleith, Col. 10, lines 10-20, see the database partitioning service 126 may provide a rough layout schema to another system (e.g., the database migration service) to indicate how the database is to be created, e.g., in terms of placing the table A 124A on a first database instance 122B, table B 124B on a second database instance 122C, and the like, where the “name of a schema” is however the system knows how to call/retrieve the rough layout schema to place the table on the second database instance), a table name or table names indicating a name or names of the one or more tables (Plenderleith, Col. 11, lines 16-37, see the statement handler 134 may use these table names as lookup keys into a cache of table location data to identify a network address associated with each table (or another other unique identifier, such as a hostname, that can be used by the provider network to route traffic to the database instance hosting the table)), and a DB area ID used to uniquely identify a DB area which is a storage area of a file in the database (Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address, its unique identifier within the context of the database service 110, or the like [i.e., “DB area ID used to uniquely identify a DB area which is a storage area of a file in the database”])),
wherein the third table (Plenderleith, Col. 10, lines 10-20, see the database partitioning service 126 may provide a rough layout schema to another system (e.g., the database migration service) to indicate how the database is to be created, e.g., in terms of placing the table A 124A on a first database instance 122B, table B 124B on a second database instance 122C, and the like) includes the DB area ID and a relative file path of the file (Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address [i.e., “relative file path of the file”], its unique identifier within the context of the database service 110, or the like)), and
wherein the processor is configured to execute:
mount processing in which a virtual volume is created for each database and mounted to the storage location information (Plenderleith, Col. 2, lines 35-63, see a database partitioning service may migrate a database running on a single server that has multiple tables to multiple databases on multiple servers with a single table per database or a proper subset of the tables per database, which discloses creating databases on the multiple servers; and Plenderleith, Col. 26, lines 44-63, see a user, via a virtual computing system 992 and/or on another customer device 990, may mount and access virtual data store 916 volumes via storage service 910 acting as a storage virtualization service, and these volumes may appear to the user as local (virtualized) storage 998);
first generation processing in which, from the first table of each of the plurality of devices, the DB name and the storage location information are acquired, the DB name is changed so as to differ from one database to another database, and a first integrated table is generated by associating a changed-to DB name and the storage location information with each other for each database (Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address, its unique identifier within the context of the database service 110, or the like));
second generation processing in which, from the second table of each of the plurality of devices, the schema name, the table name, and the DB area ID are acquired (Plenderleith, Col. 10, lines 10-20, see the database partitioning service 126 may provide a rough layout schema to another system (e.g., the database migration service) to indicate how the database is to be created, e.g., in terms of placing the table A 124A on a first database instance 122B, table B 124B on a second database instance 122C, and the like), a second integrated table is generated the table name, the changed-to DB name, and the DB area ID with one another for each database (Plenderleith, Col. 6, lines 11-26, see each database instance 122A-122N may have a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100) the database instance 122A-122N during interactions between the user and the database service 110 interfaces; and Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address, its unique identifier within the context of the database service 110, or the like), where the rough layout schema/schema name must be obtained/acquired to know how to format the tables on the second database instance, the database instance identifier/table name must be obtained/acquired to know what table(s) to copy to the second database instance and the table location data/where the table(s) are located/network address/DB area ID must be obtained/acquired to know where to retrieve the table(s) from to copy to the second database instance; Note: Where the schema name, the table name and the DB area ID are stored does not patentably distinguish the invention. The same result occurs no matter where this data is stored. The table generated on the second database instance with its corresponding ); and
third generation processing in which, from the third table of each of the plurality of devices, the DB area ID and the relative file path of the file are acquired, and a third integrated table is generated by associating the changed-to DB name, the DB area ID, and the relative file path with one another for each database (Plenderleith, Col. 6, lines 11-26, see each database instance 122A-122N may have a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100) the database instance 122A-122N during interactions between the user and the database service 110 interfaces; and Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table with an identifier of a database instance 122 (e.g., its network address [i.e., “relative file path”], its unique identifier within the context of the database service 110, or the like)).
Plenderleith does not appear to explicitly disclose the schema name is changed so as to differ from one database to another database;
by associating a changed-to schema name.
Nhan discloses the schema name is changed so as to differ from one database to another database (See below);
by associating a changed-to schema name (Nhan, Col. 25, lines 12-46, see the remote name of the “Orders” table has been changed to “Table B,” the schema region 150 is updated to reflect the remote name change, see name table name of “Orders” is changed to “Table B” for schema region 150).
Plenderleith and Nhan are analogous art because they are from the same field of endeavor such as transferring/moving data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Plenderleith and Nhan before him/her, to modify the database name changing of Plenderleith to include the schema name changing of Nhan because it would allow multiple copies of the same data to exist and be modified at the same time.
The suggestion/motivation for doing so would have been by storing relationships between different data sets in a database, relationships between data sets can be leveraged to assist users in analyzing the data, Nhan, Col. 1, lines 57-62.
Therefore, it would have been obvious to combine Nhan with Plenderleith to obtain the invention as specified in the instant claim(s).
Claim(s) 7 and 8 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale.
With respect to claim 8, Plenderleith discloses a non-transitory computer-readable recording medium having recorded thereon an integration program (Plenderleith, Fig. 10, see system memory 1020).
Claim 2
With respect to claim 2, the combination of Plenderleith and Nhan discloses wherein the integration device is configured to execute:
input processing in which input of a query including the changed-to schema name and the table name is received (See below);
first acquisition processing in which, based on the query input in the input processing, the second integrated table is searched in order to acquire the changed-to DB name and the DB area ID (See below);
second acquisition processing in which, based on the changed-to DB name acquired through the first acquisition processing, the first integrated table is searched in order to acquire the storage location information (See below);
third acquisition processing in which, based on the changed-to DB name and the DB area ID that are acquired through the first acquisition processing, the third integrated table is searched in order to acquire the relative file path (See below);
opening processing in which, based on the storage location information acquired through the second acquisition processing and the relative file path acquired through the third acquisition processing, an absolute file path is generated, and a specific file specified by the absolute file path is opened (See below);
fifth generation processing in which, by associating the changed-to DB name, the DB area ID, and a file descriptor of the specific file opened through the opening processing with one another, DB area information is generated (See below); and
search processing in which, based on the DB area information generated through the fifth generation processing, a search for the specific file is executed on the DB area identified by the DB area ID in the virtual volume associated with the database that is identified by the changed-to DB name (Plenderleith, Fig. 6, steps 605 “Receive database statement originated by client”, 610 “Identify tables and network address(es) of database instance(s) hosting the referenced tables”, 615 “Statement involves only one table? N”, 625 “Construct statement involving a single table”, 640 “Send statement [based on result data]”, 645 “Receive result”, 655 “Construct result” and 660 “Send result to client”, where the system must resolve the correct database name with the accompanying file path in order to return the result to the user/requestor; and Plenderleith, Col. 3, lines 21-42, see an application that utilizes ones of these tables can be insulated from the underlying data placement changes via use of a database proxy. The application may simply connect to the database proxy as if it were the database itself, and the proxy may intelligently send database statements to the necessary database server instance(s). For example, a database query involving a first table may be sent to a first database server instance hosting that table, while a database query involving a second table may be sent to a second database server instance hosting that second table [i.e., through via the “changed-to DB name”, “DB area ID” and finding the “relative file path”, “absolute file path” in the “DB area ID”, searching that area for the “specific file” and retrieving data therefrom]. Moreover, in some embodiments, for database statements involving multiples tables, such as those utilizing “JOIN” clauses, the database proxy may intelligently interact with multiple database server instances to gather needed information from these tables and perform the combination of the data, e.g., on its own, via use of one of the database server instances, via use of a test database instance, or the like. Accordingly, in some embodiments an application's code beneficially does not need to be updated due to the movement of the tables from a single database to multiple databases; instead, the database proxy can simply accommodate the data movement on its own).
Claim 3
With respect to claim 3, the combination of Plenderleith and Nhan discloses wherein the processor is configured to execute determination processing for determining whether the DB area information is already generated (Plenderleith, Col. 10, lines 10-20, see the database migration service launches and configures the necessary database instances 122B-122N with the table data obtained for the source database instance, where a check should be made as to whether the configuration process needs to be repeated so as not to overwrite previous data), and
wherein, when it is determined in the determination processing that the DB area information is yet to be generated, the processor is configured to execute the first acquisition processing, the second acquisition processing, the third acquisition processing, the opening processing, and the fifth generation processing, and, when it is determined in the determination processing that the DB area information is already generated, the processor is configured to avoid executing the first acquisition processing, the second acquisition processing, the third acquisition processing, the opening processing, and the fifth generation processing (Plenderleith, Col. 10, lines 21-41, see redirecting activities to an already created instance of the tables/database, which means all of the generation steps can be avoided/bypassed).
Claim 4
With respect to claim 4, the combination of Plenderleith and Nhan discloses wherein, in the first generation processing, the processor is configured to generate the first integrated table from the first table of each of the plurality of devices by associating, for each database, the changed-to DB name, the storage location information, and conversion processing in which a conversion program for converting data is prescribable, with one another, and
wherein, in the search processing, in a case in which the conversion program is prescribed with respect to the changed-to DB name, the processor is configured to convert data in the specific file with use of the conversion program (Plenderleith, Col. 10, lines 3-9, see initiating the data migration service, which would require setting up steps and conversion steps should the source database instance tables need to be converted to a different format based on the system the database is partitioned over).
Claim 5
With respect to claim 5, the combination of Plenderleith and Nhan discloses wherein a fourth table including a DB buffer name and the DB area ID is included, the DB buffer name being a name of a DB buffer which serves as a buffer area for the DB area, and
wherein the processor is configured to execute fourth generation processing in which, from the fourth table of each of the plurality of devices, the DB buffer name and the DB area ID are acquired, the DB buffer name is changed so as to differ from one database to another database, and a fourth integrated table is generated by associating the changed-to buffer name, the table name, the changed-to DB name, and the DB area ID with one another for each database (Plenderleith, Col. 20, lines 33-48, the state may include database properties such as the existence of a temporary table [i.e., in the “DB buffer”] or prepared statement (e.g., a SQL template) that was created during the connection (that may need to be referenced later); Plenderleith, Col. 6, lines 11-26, see each database instance 122A-122N may have a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100) the database instance 122A-122N [i.e., through via the “table name”, “DB buffer name”, “DB area ID”, and “changed-to DB name”] during interactions between the user and the database service 110 interfaces; and Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table [i.e., “table name” changed to “changed-to DB name”] with an identifier of a database instance 122 (e.g., its network address, its unique identifier [i.e., “DB buffer” and “DB area ID”] within the context of the database service 110, or the like)).
Claim 6
With respect to claim 6, the combination of Plenderleith and Nhan discloses wherein a fourth table including a DB buffer name and the DB area ID is included, the DB buffer name being a name of a DB buffer which serves as a buffer area for the DB area, and
wherein the processor is configured to execute:
fourth generation processing in which, from the fourth table of each of the plurality of devices, the DB buffer name and the DB area ID are acquired, the DB buffer name is changed so as to differ from one database to another database, and a fourth integrated table is generated by associating the changed-to buffer name, the table name, the changed-to DB name, and the DB area ID with one another for each database (See below);
fourth acquisition processing in which, based on the changed-to DB name and the DB area ID, the fourth integrated table is searched in order to acquire the changed-to DB buffer name (See below); and
sixth generation processing in which DB buffer information is generated by associating the changed-to DB name, the DB area ID, and the changed-to DB buffer name with one another (Plenderleith, Col. 3, lines 21-42, see an application that utilizes ones of these tables can be insulated from the underlying data placement changes via use of a database proxy. The application may simply connect to the database proxy as if it were the database itself, and the proxy may intelligently send database statements to the necessary database server instance(s). For example, a database query involving a first table may be sent to a first database server instance hosting that table, while a database query involving a second table may be sent to a second database server instance hosting that second table [i.e., through via the “DB buffer name”, “DB area ID”, and “changed-to DB name”]. Moreover, in some embodiments, for database statements involving multiples tables, such as those utilizing “JOIN” clauses, the database proxy may intelligently interact with multiple database server instances to gather needed information from these tables and perform the combination of the data, e.g., on its own, via use of one of the database server instances, via use of a test database instance, or the like. Accordingly, in some embodiments an application's code beneficially does not need to be updated due to the movement of the tables from a single database to multiple databases; instead, the database proxy can simply accommodate the data movement on its own; Plenderleith, Col. 20, lines 33-48, the state may include database properties such as the existence of a temporary table [i.e., in the “DB buffer”] or prepared statement (e.g., a SQL template) that was created during the connection (that may need to be referenced later); Plenderleith, Col. 6, lines 11-26, see each database instance 122A-122N may have a database instance identifier, which can be a user-supplied name that uniquely identifies (e.g., within the entire provider network 100, or within a portion or region of the provider network 100) the database instance 122A-122N [i.e., through via the “table name”, “DB buffer name”, “DB area ID”, and “changed-to DB name”] during interactions between the user and the database service 110 interfaces; and Plenderleith, Col. 10, lines 42-58, see the database partitioning service 126 updates at circle (2B) a data structure with table location data 128 that indicates, for each table (or for individual records, or collections of records), where that table is located (or record(s) are located). For example, the table location data 128 may be a mapping data structure that associates an identifier of a particular table [i.e., “table name” changed to “changed-to DB name”] with an identifier of a database instance 122 (e.g., its network address, its unique identifier [i.e., “DB buffer” and “DB area ID”] within the context of the database service 110, or the like)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
– Orson et al., 12182113 for managing database systems using human-readable declarative definitions.
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.
Point of Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P EST.
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, Apu Mofiz can be reached at (571) 272-4080. 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.
HUBERT G. CHEUNG
Assistant Examiner
Art Unit 2161
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2161Date: August 25, 2026
/APU M MOFIZ/Supervisory Patent Examiner, Art Unit 2161
Prosecution Insights