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 .
DETAILED ACTION
This action is response to the Applicant’s Remarks filed on 01/15/2026.
Claims 1-20 are pending in this Office Action. Claims 1, 11 and 20 are independent claims.
Response to Arguments
Applicant’s arguments filed 01/15/2026 with respect to claims 1-20 have been fully and respectfully considered.
As per the Applicant’s argument that “”Kolawa does not disclose at least "generating a database schema including a first set of one or more data fields requested in the one or more read requests collected during the test execution, the database schema defining a configuration of the secondary database that is a partial copy of a primary database" as recited in amended claim 1. Desantis does not remedy the deficiencies of Kolawa.””,
The Examiner respectfully agreed and incorporated a new reference “Database Advanced Replication” published by ORACLE (Abbreviated as “OraAdvRep”). OraAdvRep described how a master database or master materialized view as a whole or a part being replicated to a secondary site as a database or materialized view. OraAdvRep seems to be a reference similar to the instant application.
In combining with Kolawa, Kolawa in view OraAdvRep seems reasonably teaching the subject matter as currently amended.
Claim Rejections - 35 U.S.C. § 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 11-13 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over
Kolawa et al.: “METHOD AND SYSTEM FOR TESTING DATA SOURCES AND DATABASE ORIENTED SOFTWARE APPLICATIONS” (United States Patent US 7010546 B1, DATE PUBLISHED 2006-03-07; and DATE FILED 2003-07-22, hereafter “Kolawa”), in view of
Urbano, Randy: “Oracle® Database Advanced Replication” (10g, Release 1 (10.1) December 2003 ORACLE®, hereafter “OraAdvRep”).
As per claim 1, Kolawa teaches a method comprising:
monitoring a test execution of a first application prior to deployment of the first application (See col. 2, lines 10-13 and col. 1, lines 49-50, building test suites, executing the test suites and monitoring the interaction of the software application with the database; and mission critical applications require thorough testing prior to deployment as testing generally taking place prior to deployment) and
collecting one or more read requests generated by the first application prior to the first application requesting any data from a secondary database (See col. 2, lines 7-8 and col. 5, lines 34-35, a data repository for storing database structures and SQL queries; and prototyped queries 103 can be stored in DRR (Data & Reports Repository) for use within the software application and for load testing. Here the stored prototype queries for load testing reads on queries collected, load testing teaches at least reading data from a secondary database for testing and storing queries for application to use reads on collecting queries prior to requesting any data from a secondary database because the first application has not requested data from the secondary database).
Kolawa teaches “read requests collected during the test execution” as described above.
However, Kolawa does not explicitly teach generating a database schema including a first set of one or more data fields requested in the one or more read requests collected during the test execution, the database schema defining a configuration of the secondary database that is a partial copy of a primary database.
On the other hand, OraAdvRep teaches generating a database schema including a first set of one or more data fields requested in the one or more read requests collected during the test execution, the database schema defining a configuration of the secondary database that is a partial copy of a primary database (See Page 3-41, creating the following read-only materialized view at a remote materialized view site:
CREATE MATERIALIZED VIEW oe.customers_mv1 AS
SELECT customer_id, cust_last_name, c.cust_address.postal_code
FROM oe.customers_sub@orc1.world c;
Here customer_id, cust_last_name, and c.cust_address.postal_code teaches data fields requested, the materialized view customers_mv1 teaches the database schema of a secondary database, the (default) remote materialized view database site, and customers_sub[@orc1.world] teaches the schema customers_sub of the primary database orc1.world, and materialized view customers_mv1 at the remote site is a partial copy of the schema customers_sub of the primary database orc1.world).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine OraAdvRep’s teaching with Kolawa because Kolawa is dedicated to testing different data sources and database oriented software applications, OraAdvRep is dedicated to replicating data from a master database to another master or a non-master site, and a combined teaching would have enabled Kolawa to utilize OraAdvRep’s replication architecture with materialized serving as the secondary database to appreciate all the inherited features and benefits of using materialized.
Kolawa and in view of OraAdvRep furth teaches the following:
causing an update of the secondary database based on the database schema (See OraAdvRep: Page 2-42, Synchronous data propagation occurs when an application updates a local replica of a table, and within the same transaction also updates at least one other replica of the same table. Here the table reads on the database schema),
wherein the secondary database is updated to include data copied from the first set of one or more data fields of the primary database (See OraAdvRep: Figure 2-8 and Page 2-43, whenever an application makes a DML change to a local replicated table and the replication group is using synchronous row-level replication, the change is synchronously propagated to the other master sites in the replication environment using internal triggers. The data fields employee_id, last_name and department_id of the Employee table at the secondary database is updated to include the corresponding data fields data of the primary database).
As per claim 2, Kolawa in view of OraAdvRep teaches the method of claim 1, further comprising:
after the update of the secondary database, receiving at least one further read request generated by the first application after the first application is deployed (See Kolawa: col. 6, lines 2024, using the software tool of the present invention is capable of detecting software errors by detecting problems in database records and building suitable tests from the prototyping phase through coding phase, and after deployment of the software application in which detecting software errors by detecting problems in database records teaches receiving at least one further read request generated by the first application after the first application is deployed; and OraAdvRep (See Pages 3-2 and 1-8, Whereas in multi-master replication tables are continuously updated by other master sites, materialized views are updated from one or more masters through individual batch updates, known as a refreshes, from a single master site or master materialized view site; and materialized views offload queries from the master site or master materialized view site and users can query the local materialized view instead. Here the secondary database, the local materialized view at the remote site, is being updated after each time the master site is updated, and the master site redirects queries to local materialized view site when the master site is queried that includes before or after the master site and then the materialized view site are updated); and
sending data from the secondary database in response to the at least one further read request to the first application (See Pages 3-2 and 1-8, Whereas in multi-master replication tables are continuously updated by other master sites, materialized views are updated from one or more masters through individual batch updates, known as a refreshes, from a single master site or master materialized view site; and materialized views offload queries from the master site or master materialized view site and users can query the local materialized view instead. Here the secondary database, the local materialized view at the remote site, is being updated after each time the master site is updated, and the master site redirects queries to local materialized view site when the master site is queried that includes before or after the master site and then the materialized view site are updated).
As per claim 3, Kolawa in view of OraAdvRep teaches the method of claim 1, wherein the update of the secondary database includes one or more of: adding at least one data field included in the database schema to the secondary database (See OraAdvRep: using user-defined datatypes, then the attributes of column objects can be logged in the materialized view log. For example, the oe.customers table has the cust_address.postal_code attribute, which can be logged in the materialized view log by issuing the following statement:
ALTER MATERIALIZED VIEW LOG ON oe.customers ADD (cust_address.postal_code);); or
removing from the secondary database at least one data field that is absent from the database schema.
As per claims 11-13, the claims recite a computing system comprising:
a processor configured to execute instructions to cause the computing system (See Kolawa: col. 3, lines 56-60, a processor is inherent to a web site and the servers that make up the World Wide Web) to perform the steps of the methods as recited in claims 1-3 above, respectively, and rejected under 35 U.S.C. § 103 as being unpatentable over Kolawa in view of OraAdvRep.
Accordingly, claims 11-13 are rejected along the same rationale that rejected claims 1-3, respectively.
As per claim 20, the claim recites a non-transitory computer readable medium having instructions stored thereon, wherein the instructions are executable by a processor of a computing system (See Kolawa: col. 3, lines 15-17 and 56-60, Users access 15 and browse the Web using a web browser that generally resides and is executed on the user's computer. The computer residing web browser reads on the instructions stored thereon) to cause the computing system to perform the steps of the methods as recited in claim 1 above and rejected under 35 U.S.C. § 103 as being unpatentable over Kolawa in view of OraAdvRep.
Accordingly, claim 20 is rejected along the same rationale that rejected claim 1.
Claims 4-8, 10, 14-17 and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over
Kolawa in view of OraAdvRep, as applied to claims 1-3 and 11-13 above, and further in view of
Meissner et al.: “ZERO DOWNTIME UPGRADE OF SYSTEMS WITH DATABASE-SIDE REPLICATION” (United States Patent publication US 20200159852 A1, DATE PUBLISHED 2020-05-21; and DATE FILED 2018-11-21, hereafter “Meissner”).
As per claim 4, concerning the method of claim 1, further comprising: monitoring an execution of a second application and collecting one or more read requests generated by the second application, Kolawa in view of OraAdvRep teaches the method of claim 1, further comprising: monitoring an execution of an application (See Kolawa: col. 2, lines 10-13 and col. 1, lines 49-50, monitoring the interaction of the software application with the database; and mission critical applications require thorough testing prior to deployment as testing generally taking place prior to deployment).
However, Kolawa in view of OraAdvRep does not explicitly teach a second application and collecting one or more read requests generated by the second application.
On the other hand, as an analogous art on database-side replication, Meissner teaches the method of claim 1, further comprising: an execution of a second application and collecting one or more read requests generated by the second application (See [0028] and [0050], the replication instruments the database with triggers, and logging tables. The triggers read data written to the database, analyzes the data, and stores data in logging tables. The logging tables are read by the replication software, reading the data from the database, and writing the data to another database; and the clone table is created in the target (consumer-side) database, and uses the same structure as defined in the source-side. Here the processes after storing data in the logging table as underlined above is interpreted the second application).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Meissner’s teaching with Kolawa in view of OraAdvRep because Kolawa is dedicated to testing different data sources and database oriented software applications, OraAdvRep is dedicated to replicating data from a master database to another master or a non-master site, Meissner is dedicated to minimizing downtime during upgrade of an application in systems with database-side replication, and a combined teaching would have enabled Kolawa in view of OraAdvRep to replicating database changes symmetrically to target nodes without or minimizing the need of downtime.
Kolawa and in view of OraAdvRep and further in view of Meissner furth teaches the following:
generating the database schema to include a union of the first set of one or more data fields and a second set of one or more data fields requested in the one or more read requests collected during the execution of the second application (See OraAdvRep: Page 3-11, creating a complex materialized view by executing UNION ALL set operation:
CREATE MATERIALIZED VIEW hr.mview_employees AS
SELECT employees.employee_id, employees.email
FROM hr.employees@orc1.world
UNION ALL
SELECT new_employees.employee_id, new_employees.email
FROM hr.new_employees@orc1.world; and Meissner: [0005], the application accessed data in the first database system; actions through which data was replicated to in the second database system; the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system);
wherein the secondary database is updated to include data copied from the union of the first set of one or more data fields and the second set of one or more data fields of the primary database (See OraAdvRep: Figure 2-8 and Page 2-43, whenever an application makes a DML change to a local replicated table and the replication group is using synchronous row-level replication, the change is synchronously propagated to the other master sites in the replication environment using internal triggers. The data fields employee_id, last_name and department_id of the Employee table at the secondary database is updated to include the corresponding data fields data of the primary database; and Meissner: [0005], the application accessed data in the first database system; actions through which data was replicated to in the second database system; the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system).
As per claim 5, Kolawa in view of OraAdvRep and further in view of Meissner teaches the method of claim 4, further comprising:
storing a first application-specific metadata identifying the first set of one or more data fields associated with the first application (See Meissner: [0005], after completion of the upgrade, switching an upgraded version of the application to the source-side green access schema for interacting with the one or more source-side clone data components, a); and
storing a second application-specific metadata identifying the second set of one or more data fields associated with the second application (See Meissner: [0005], [0028] and [0050], the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system; a data schema of the first database system includes a trigger for copying data from an original clone data component to at least one source-side data component; and the one or more source-side data components include one or more of a clone column, and a clone table; The logging tables are read by the replication software, reading the data from the database, and writing the data to another database; and the clone table is created in the target (consumer-side) database, and uses the same structure as defined in the source-side.).
As per claim 6, Kolawa in view of OraAdvRep and further in view of Meissner teaches the method of claim 5, further comprising:
obtaining a third application-specific metadata identifying a third set of one or more data fields associated with a third application (See Meissner: [0005] and [0023], the application accessed data in the first database system; actions through which data was replicated to in the second database system; the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system, and one or more data stores of the server system 104 store one or more databases that reads on a third; and OraAdvRep: Figure 2-8 and Page 2-43, whenever an application makes a DML change to a local replicated table and the replication group is using synchronous row-level replication, the change is synchronously propagated to the other master sites in the replication environment using internal triggers. The data fields employee_id, last_name and department_id of the Employee table at the secondary database is updated to include the corresponding data fields data of the primary database;); and
generating the database schema to include a union of the data fields identified in the first, second and third application-specific metadata (See Meissner: [0005], the application accessed data in the first database system; actions through which data was replicated to in the second database system; the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system; and OraAdvRep: Figure 2-8, Page 2-43, and Page 3-11, creating a complex materialized view by executing UNION ALL set operation:
CREATE MATERIALIZED VIEW hr.mview_employees AS
SELECT employees.employee_id, employees.email
FROM hr.employees@orc1.world
UNION ALL
SELECT new_employees.employee_id, new_employees.email
FROM hr.new_employees@orc1.world;whenever an application makes a DML change to a local replicated table and the replication group is using synchronous row-level replication, the change is synchronously propagated to the other master sites in the replication environment using internal triggers. The data fields employee_id, last_name and department_id of the Employee table at the secondary database is updated to include the corresponding data fields data of the primary database;);
wherein the secondary database is updated to include data copied from the union of the data fields identified in the first, second and third application-specific metadata (See Meissner: [0005], the application accessed data in the first database system; actions through which data was replicated to in the second database system; the replication system triggers switching of replication of data, and removing the consumer-side blue access schema based on post-upgrade statements received from the deploy tool; the source-side green access schema includes a replication trigger for replicating data to the second database system; and OraAdvRep: Figure 2-8 and Page 2-43, whenever an application makes a DML change to a local replicated table and the replication group is using synchronous row-level replication, the change is synchronously propagated to the other master sites in the replication environment using internal triggers. The data fields employee_id, last_name and department_id of the Employee table at the secondary database is updated to include the corresponding data fields data of the primary database;).
As per claim 7, Kolawa in view of OraAdvRep and further in view of Meissner teaches the method of claim 1, further comprising:
after the update of the secondary database, monitoring an execution of a fourth application and collecting one or more read requests generated by the fourth application (See Meissner: [0005] [0023] and [0050], after completion of the upgrade, switching replication of data from the first database system to the consumer-side green access schema; and one or more data stores of the server system 104 store one or more databases. Here the replication is the requested after upgrade executed and plural databases reads on a fourth; and the clone table is created in the target (consumer-side) database, and uses the same structure as defined in the source-side. Here the creating target table using the same structure of the source table teaches creating table schema that includes all columns from the source table);
determining that at least one data field in the fourth set of one or more data fields requested in the one or more read requests collected during the execution of the fourth application is absent from the database schema (See OraAdvRep: Page 6-15, If a materialized view log already exists on the oe.customers table, you can add these columns by issuing the following statement:
ALTER MATERIALIZED VIEW LOG ON oe.orders ADD (customer_id,order_total);); and
generating a notification indicating that at least one data field requested by the fourth application is absent from the database schema (See OraAdvRep: Page 6-15, Columns orders.customer_id and customers.customer_id are referenced as part of the equi-join clause. Because customers.customer_id is a primary key column, it is logged by default, but orders.customer_id is not a primary key column and so must be added to the materialized view log. Also, the column orders.order_total is an additional filter column and so must be logged. Therefore, add orders.customer_id and orders.order_total the materialized view log for the oe.orders table.).
As per claim 8, Kolawa in view of OraAdvRep and further in view of Meissner teaches the method of claim 7, further comprising:
prohibiting deployment of the fourth application (See Meissner: [0003], minimizing downtime during upgrade of an application during upgrade of an application in systems with database-side replication. To minimize downtime, as a smaller number of applications deployed is suggested and that exclude a deployment of a fourth application).
As per claim 10, Kolawa in view of OraAdvRep and further in view of Meissner teaches the method of claim 1, wherein the first application is deployed after the secondary database is updated (See Meissner: [0041] and [0002], the deploy tool runs the blue-green upgrade procedure, computes, which tables are migrated using a clone table and during a lifecycle of the application and/or database, one or more maintenance operations may be required. Example maintenance operations include upgrading, patching and testing.).
As per claims 14-17 and 19, the claims recite a computing system comprising:
a processor configured to execute instructions to cause the computing system (See Kolawa: col. 3, lines 56-60, a processor is inherent to a web site and the servers that make up the World Wide Web) to perform the steps of the methods as recited in claims 4, (5 and 6), 7-8 and 10 above, respectively, and rejected under 35 U.S.C. § 103 as being unpatentable over Kolawa in view of OraAdvRep and further in view of Meissner.
Accordingly, claims 14-17 and 19 are rejected along the same rationale that rejected claims 4, (5 and 6), 7-8 and 10, respectively.
Claims 9 and 18 are rejected under 35 U.S.C. § 103 as being unpatentable over
Kolawa in view of OraAdvRep, as applied to claims 1-3 and 11-13 above, and further in view of
Desantis et al.: “CUSTOMIZING BACKUP AND RESTORE OF DATABASES” (United States Patent publication US 20150317208 A1, DATE PUBLISHED 2015-11-05; and DATE FILED 2014-04-30, hereafter “Desantis”).
As per claim 9, Kolawa in view of OraAdvRep does not explicitly teach the method of claim 1, for each read request generated by the first application, parsing the read request to ignore any constants in the read request and to identify a requested data field.
However, Desantis teaches for each read request generated by the first application, parsing the read request to ignore any constants in the read request and to identify a requested data field (See Desantis: [0032], the query processor 250 processes queries received by the database system. Processing a query may comprise parsing the query, generating an execution plan for the query, and executing the query. In an embodiment, one or more database queries may be executed to determine the backup dataset that is being backed up by the backup manager 230).
It would have been obvious to a person of ordinary skill in the computer art before the effective filing date of the claimed invention to combine Desantis’ teaching with Kolawa in view of OraAdvRep because Kolawa is dedicated to testing different data sources and database oriented software applications, OraAdvRep is dedicated to replicating data from a master database to another master or a non-master site, Desantis is dedicated to backing up and restoring databases and more specifically to customizing backup and restore of databases, and a combined teaching would have enabled Kolawa in view of OraAdvRep to enhance data security of database by backing up and restoring databases
during different phases of database application deployment.
Kolawa and in view of OraAdvRep and further in view of Desantis furth teaches the following:
identifying the first set of one or more data fields as a union of all requested data fields identified from the one or more read requests (See Desantis: Page 7, claim 6 and [0033], specifying a database query comprising a select clause that specifies a subset of columns of the database table to be included; and the restore manager 240 restores the database from a given backup file. The restore manager 240 analyzes the content of a backup file to determine the database objects to be restored from the backup file. The restore manager 240 also determines from the backup file whether the restore is from the output of an incremental backup or the output of a full backup. If the restore is from an output of a full backup, the restore command restores the full content of each database object from the backup file. In some embodiments, if the database object is already present in the database while the restore manager 240 is performing a restore from a full backup, restore manager 240 throws an error or logs a warning message. Alternatively, the restore manager 240 may replace the existing database object with the new database object obtained from the backup file; and Kolawa: col. 45, lines 43-50, creating patterns of relational structure for the schema to be detected in the database; profiling the interaction of the software application with the database; and verifying that the schema of the database adheres to the created patterns of relational structure, responsive to the profiling interaction of the software application with the database).
As per claim 18, the claim recites a computing system comprising:
a processor configured to execute instructions to cause the computing system (See Kolawa: col. 3, lines 56-60, a processor is inherent to a web site and the servers that make up the World Wide Web) to perform the steps of the methods as recited in claim 9 and rejected under 35 U.S.C. § 103 as being unpatentable over Kolawa in view of OraAdvRep and further in view of Desantis.
Accordingly, claim 18 is rejected along the same rationale that rejected claim 9.
Related Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure can be found in the PTO-892 Notice of Reference Cited.
Conclusions
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.
The Examiner has cited particular columns and line numbers in the references applied to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. SEE MPEP 2141.02 [R-5] VI. PRIOR ART MUST BE CONSIDERED IN ITS ENTIRETY, INCLUDING DISCLOSURES THAT TEACH AWAY FROM THE CLAIMS: A prior art reference must be considered in its entirety, i.e., as a whole, including portions that would lead away from the claimed invention. W.L. Gore & Associates, Inc. v. Garlicky, Inc., 721 F.2d 1540, 220 USPQ 303 (Fed. Cir. 1983), cert. denied, 469 U.S. 851 (1984) In re Fulton, 391 F.3d 1195, 1201,73 USPQ2d 1141, 1146 (Fed. Cir. 2004). >See also MPEP §2123.
In the case of amending the Claimed invention, Applicant is respectfully requested to indicate the portion(s) of the specification which dictate(s) the structure relied on for proper interpretation and also to verify and ascertain the metes and bounds of the claimed invention.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KUEN S LU whose telephone number is (571)272-4114. The examiner can normally be reached on M-F, 8-19, Mid-Flex 2 hours.
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, Mr. Ajay Bhatia can be reached on 5712723906. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
KUEN S LU /Kuen S Lu/
Art Unit 2156
Primary Patent Examiner
February 1, 2026