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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/16/2026 has been entered.
Status of Claims
Claims 1-4, 6-11, 13-18 and 20-23 are currently pending in the Application. Claims 5,12 and 19 are currently cancelled.
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, 15 and 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg et al. (US Patent No. 5,600,832; Date of Patent: Feb. 4, 1997) in view of Pickering (US PGPUB No. 2006/0085456; Pub. Date: Apr. 20, 2006) amd Olson et al. (European Patent Application: EP 0534466 A2; Pub. Date: 1993-03-31).
Regarding independent claim 1,
Eisenberg discloses a computer-implemented method, comprising:creating, using a context manager (CM), a new context; See Col. 36, lines 18-23, (Disclosing a method for providing a versioned database management system for allowing parts of said system to be versioned according to different variant hierarchies. Users may interact with a system via individual versioned data management system (VDMS) host sessions associated with its own context comprising a set of current variables, whose identity for a given user is preserved from one session to the next, i.e. creating, using a context manager (CM), a new context (e.g. sessions are created when a new user interacts with the system. The creation of new session necessarily results in the creation of a new context).)
deploying, using the CM, a new configuration-variant; See Col. 12, lines 4-10, (Variants may be created to represent differences between environments, models, releases, effective times or users. Variants may be created either upon requests or automatically at the working variant level, i.e. deploying, using the CM, a new configuration-variant;)
assigning, using the CM, the new context for use by users connecting to a database schema of the new context; See Col. 12, lines 27-34, (Variant domains allow different parts to be versioned using different sets of variant IDs. An example is provided where the system may be embodied as a payroll application having a four-level versioning scheme associated with production, integration, test and user levels. Note Col. 6, lines 7-15 wherein a context is defined as a collection of values for environmental variables of a session. Each session utilizes one particular context referred to as a current context, i.e. assigning, using the CM, the new context for use by users connecting to a database schema of the new context;)
and removing configuration entries for domains assigned to the new context from a domain context map persistency of the CM, See Col. 12, lines 4-10, (Disclosing a method for providing a versioned database management system for allowing parts of said system to be versioned according to different variant hierarchies. Variants may be created to represent differences between environments, models, releases, effective times or users. Variants may be created either upon requests or automatically at the working variant level.) See Col. 234, lines 55-62, (The system may utilize variant maps to perform a plurality of actions on the plurality of variants including DRAWDOWN, CANCEL, RENAME, etc. The CANCEL data action may delete a created variant either by changing the revision time stamp so that the variant is no longer current or by physically deleting the variant, i.e. a domain context map persistency of the CM.) See Col. 49, lines 29-37, (Variants are organized into groups wherein individual variants within said group may be promoted within the hierarchy. The specification of the group may then be updated to reflect the new variant ID following the promotion, i.e. removing configuration entries for domains assigned to the new context.)
wherein the domain context map persistency stores which contexts are to be considered within a domain; See Col. 3, lines 51-67, (Variant maps identify configurations of versions of parts. Each variant map comprises a set of variant IDs belonging to different variant domains. Changes made to individual configurations are simultaneously made in any other configuration identified by a variant map which includes the same variant ID. The variant map stores a plurality of variant IDs indicating configurations of versions of parts of the database system. A configuration consists of parts belonging to a combination of variant domains, i.e. wherein the domain context map persistency stores which contexts are to be considered within a domain.)
and cleaning up, using the CM, the new context. See Col. 4, lines 1-6, (The variants of the variant map may be drawn down and promoted in order to maintain data integrity of configurations of versions of parts in different variant domains.) See Col. 42, lines 38-45, (The system may perform data integrity checking in response to actions such as the adding of a new entity or a deletion of a relationship for a particular variant map, i.e. cleaning up, using the CM, the new context.)
Eisenberg does not disclose the step determining, using the CM, to phase out use of the new configuration-variant, wherein determining, using the CM, to phase out use of the new configuration-variant, comprises: switching, using the CM, a context state of the new context to phase-out, comprising: processing existing data objects within the new context until they are considered closed;
and upon a determination that the existing data objects are closed and the context state of the new context is phase-out: setting, using the CM, the context state of the new context to merge, wherein no data object is processed any longer with the new context, wherein data of objects created within a merge context are migrated to a new default context;
Pickering discloses the step of determining, using the CM, to phase out use of the new configuration-variant, See Paragraph [0038], (Disclosing a method for managing an append-only relational database including a process for obtaining a most valid view of said database and adding temporality to an existing non-temporal relational database via conversion. A Converter may choose to perform a conversion of an original non-temporal data record to a temporal data record in a temporal database at an arbitrary time, i.e. determining, using the CM, to phase out use of the new configuration-variant, (e.g. the Converter initiates the conversion from an original database context to a temporal database context)
wherein determining, using the CM, to phase out use of the new configuration-variant, comprises: switching, using the CM, a context state of the new context to phase-out, comprising: processing existing data objects within the new context until they are considered closed; See Paragraphs [0039]-[0040], (During conversion, the temporal and non-temporal databases may be run in parallel until the conversion is fully complete. Non-temporal records may be updated during parallel running until conversion in complete. When conversion is fully complete, non-temporal records that do not have a corresponding new temporal data record are deleted, archived or ignored in further operation of the temporal database, i.e. switching, using the CM, a context state of the new context to phase-out (e.g. by parallel running both temporal and non-temporal databases during conversion), comprising: processing existing data objects within the new context until they are considered closed (e.g. after conversion, non-temporal records without a corresponding new temporal data record are ignored in further operation of the temporal database.);
and upon a determination that the existing data objects are closed and the context state of the new context is phase-out: setting, using the CM, the context state of the new context to merge, wherein no data object is processed any longer with the new context, wherein data of objects created within a merge context are migrated to a new default context; See Paragraph [0040], (Disclosing a method for managing an append-only relational database including a process for obtaining a most valid view of said database and adding temporality to an existing non-temporal relational database via conversion. When the conversion is fully complete, pre-existing data records may be deleted, archived or ignored as if they were no longer present in further operation of the now fully temporal database, i.e. upon a determination that the existing data objects are closed and the context state of the new context is phase-out: setting, using the CM, the context state of the new context to merge, wherein no data object is processed any longer with the new context (e.g. data records of the converted database may be ignored when the conversion to temporality is completed).) See Paragraph [0033], (When a non-temporal database is converted into a temporal one, future updates may be captured within a time-oriented context, i.e. wherein data of objects created within a merge context are migrated to a new default context (e.g. Note [0039] wherein objects created during the conversion process may be updated in both the temporal and non-temporal database contexts).)
Eisenberg and Pickering are analogous art because they are in the same field of endeavor, database configuration. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg to include the method of shifting contexts for a database system via a conversion process as disclosed by Pickering. Paragraphs [0039]-[0040] of Pickering discloses that during conversion, the system may still make the underlying datastore available by parallel running of both the temporal and non-temporal databases. This allows the system to continue operating during the conversion which minimizes downtime for the system.
Eisenberg-Pickering does not disclose the step wherein processing the existing data objects comprises creating a successor data object in the new context in response to determining that a predecessor data object associated with the successor data object was created in the new context;
Olson discloses the step wherein processing the existing data objects comprises creating a successor data object in the new context in response to determining that a predecessor data object associated with the successor data object was created in the new context; See Pg. 5, lines 36-39, (Disclosing a database application for implementing a change definition language allowing for alterations to a database definition (catalog). The system provides a change mechanism to be employed alongside SQL module 23 to make changes to catalog 21 and alter the database definition.) See Pg. 16, lines 7-20, (The system may process changes to an existing catalog during a change session wherein the system may determine compatibility of a change to an object such as a table. The system may reconcile differences between the existing object and implements the requested change, i.e. wherein processing the existing data objects comprises creating a successor data object in the new context (e.g. by reconciling the differences between an existing object and the changes to be performed) in response to determining that a predecessor data object associated with the successor data object was created in the new context (e.g. the existing object is determined to be incompatible with an incoming change to the catalog);)
Eisenberg, Pickering and Olson are analogous art because they are in the same field of endeavor, database configuration. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg-Pickering to include the method of resolving inconsistencies during database design updates as disclosed by Olson. Pg. 3, lines 32-40 of Olson discloses that the system allows a team of users to fully tailor an application to a customer's intent by allowing users to make performance-enhancing changes to the way data is physically stored. This represents an improvement in database system technologies based on the description of the performance-enhancing changes.
Regarding independent claim 8,
The claim is analogous to the subject matter of independent claim 1 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding independent claim 15,
The claim is analogous to the subject matter of independent claim 1 directed to a computer system and is rejected under similar rationale.
Regarding dependent claim 21,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Eisenberg further discloses the step wherein small deltas of the new configuration-variant are stored in one or more multi-version tables. See Col. 13, line 64 - Col. 14, line 10, (FIG. 1 illustrates a computer system comprising disk storage configured to store hierarchy information, variant maps, context, promote groups and version data for access by VDMS 100, i.e. wherein small deltas of the new configuration-variant are stored in one or more multi-version tables (e.g. Note Col. 14, lines 46-49 wherein variants are stored as a single row in a relational table).)
Regarding dependent claim 22,
The claim is analogous to the subject matter of dependent claim 21 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding dependent claim 23,
The claim is analogous to the subject matter of dependent claim 21 directed to a computer system and is rejected under similar rationale.
Claim(s) 2, 9 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg in view of Pickering and Olson as applied to claim 1 above, and further in view of Iskender et al. (US PGPUB No. 2023/0066989; Pub. Date: Mar. 2, 2023).
Regarding dependent claim 2,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Pickering further discloses the step wherein, creating, using a CM, a new context, comprises: setting a context state to prepare; See Paragraph [0024], (Conversion of a database to a temporal database may allow access to the original non-temporal database via parallel running until the conversion is complete, i.e. creating, using a CM, a new context, comprises: setting a context state to prepare (e.g. the initialization of the conversion operation triggers the parallel running which is executed over the full execution of the conversion).)
Eisenberg-Pickering-Olson does not disclose the step of creating a database schema for the new context;
creating a database view in the database schema;
and configuring a database interface to connect to the database schema for user sessions of users using the new context.
Iskender discloses the step of creating a database schema for the new context; See Paragraph [0021], (The schema change operation creates a new database object having a new physical name. Note [0015] wherein the transformation operation provides a new table format having a new schema format, i.e. creating a database schema for the new context.)
creating a database view in the database schema; See Paragraph [0018], (Database objects may include indexes, tables, materialized views, etc., i.e. creating a database view in the database schema (e.g. Note [0015] wherein a database object is associated with a schema and may comprise a view).)
and configuring a database interface to connect to the database schema for user sessions of users using the new context. See FIG. 7, (FIG. 7 illustrates method 700 comprising step 780 wherein after completing a schema change operation, the system directs subsequent database queries using the newly created schema of the new database object, i.e. configuring a database interface to connect to the database schema for user sessions of users using the new context.)
Eisenberg, Pickering, Olson and Iskender are analogous art because they are in the same field of endeavor, network configuration. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg- Pickering-Olson to include the method of performing schema change operations for different network contexts as disclosed by Iskender. Paragraph [0016] of Iskender discloses that the system of performing schema changes while keeping database tables live does not require downtime, does not impact queries on tables, does not require an end user to manually implement schema changes, allows for multiple different schema changes at the same time, etc.
Regarding dependent claim 9,
The claim is analogous to the subject matter of dependent claim 2 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding dependent claim 16,
The claim is analogous to the subject matter of dependent claim 2 directed to a computer system and is rejected under similar rationale.
Claim(s) 3, 10 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg in view of Pickering and Olson as applied to claim 1 above, and further in view of Sheehan et al. (US PGPUB No. 2010/0023934; Pub. Date: Jan. 28, 2010).
Regarding dependent claim 3,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Pickering further discloses the step wherein deploying, using the CM a new configuration-variant, comprises: setting a context state of the new context to deployment; See Paragraph [0040], (When the conversion is fully complete, the system processes data objects according to the temporal database and non-temporal data records are ignored, i.e. setting a context state of the new context to deployment (e.g. once the conversion is complete, the new context would be the only one in use).)
Eisenberg-Pickering-Olson does not disclose the step of configuring a deploy tool to use the new context;
upon completion of the deploying, configuring the context state of the new context to restricted use.
Sheehan discloses the step of configuring a deploy tool to use the new context; See Paragraph [0069], (Disclosing a method for managing applications operated within a virtual environment. The system comprises update manager 204 configured to consolidate the current version of an application package 202 and various sets of customized resources 206. Update manager 204 may create a customized application package containing resources that may be executed within a virtual environment 212, i.e. configuring a deploy tool to use the new context (e.g. users may update a configuration of an application, which generates a new package for execution).)
upon completion of the deploying, configuring the context state of the new context to restricted use. See Paragraph [0067], (The system manages a plurality of customized resources including configuration resources having metadata that may restrict the user to change certain portions of the configuration resource, i.e. upon completion of the deploying, configuring the context state of the new context to restricted use.)
Eisenberg, Pickering, Olson and Sheehan are analogous art because they are in the same field of endeavor, application configuration management. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg-Pickering-Olson to include the method of restricting editing privileges of users for configuration resources as disclosed by Sheehan. Doing so would allow the system to manage which users are able to modify configuration information for a plurality of applications available to the user. Thereby ensuring that users are only allowed access to information that is relevant to their position or expertise within the virtual environment.
Regarding dependent claim 10,
The claim is analogous to the subject matter of dependent claim 3 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding dependent claim 17,
The claim is analogous to the subject matter of dependent claim 3 directed to a computer system and is rejected under similar rationale.
Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg in view of Pickering and Olson as applied to claim 1 above, and further in view of Lu et al. (US PGPUB No. 2021/0342337; Pub. Date: Nov. 4, 2021).
Regarding dependent claim 7,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Eisenberg-Pickering-Olson does not explicitly disclose the step cleaning up the new context, comprises: setting a context state of the new context to clean-up;
deleting the new configuration-variant;
removing the new context from configuration tables;
and deleting the database schema of the new context.
Lu discloses the step wherein cleaning up the new context, comprises: setting a context state of the new context to clean-up; See Paragraph [0874], (Entity definitions comprise a schema that includes entries indicating a cleanup state such as "active", "stale", etc., i.e. wherein cleaning up the new context, comprises: setting a context state of the new context to clean-up.)
deleting the new configuration-variant; See Paragraph [0885], (A remove policy may be applied to the item definition to determine if it is to be removed from a collection, i.e. deleting the new configuration-variant.)
removing the new context from configuration tables; See Paragraph [0680], (Machine data identified by information of the entity definition may be ingested, stored and searched using the data input and query system, i.e. removing the new context from configuration tables.)
and deleting the database schema of the new context. See Paragraph [0885], (A remove policy may be applied to the item definition to determine if it is to be removed from a collection. Note [0872] wherein entity definitions are associated with particular predefined schema, i.e. deleting the database schema of the new context (e.g. via the removal policy).)
Regarding dependent claim 14,
The claim is analogous to the subject matter of dependent claim 7 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Claim(s) 4, 11 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg in view of Pickering and Olson as applied to claim 1 above, and further in view of Varghese et al. (US PGPUB No. 2019/0149414; Pub. Date: May 16, 2019) and Kolazhi et al. (US PGPUB No. 2020/0364043; Pub. Date: Nov. 19, 2020).
Regarding dependent claim 4,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Eisenberg-Pickering-Olson does not disclose the step wherein assigning, using the CM, a context for use by users connecting to a database schema for the new context, comprises: specifying usage criteria of the new context, wherein the usage criteria comprises: IDs of users that will use the new context to create new data objects when starting new processes;
Varghese discloses the step wherein assigning, using the CM, a context for use by users connecting to a database schema for the new context, comprises: specifying usage criteria of the new context, wherein the usage criteria comprises: IDs of users that will use the new context to create new data objects when starting new processes; See Paragraph [0023], (Disclosing a system comprising synchronous imaging of one or more computing nodes having associated configuration information which include current and/or desired operating system type, brand, and/or version, current and/or desired software stack(s), user IDs, permissions, etc., i.e. specifying usage criteria of the new context, wherein the usage criteria comprises: IDs of users that will use the new context to create new data objects when starting new processes (e.g. user IDs associated with a particular configuration of a computing node).)
Eisenberg, Pickering, Olson and Varghese are analogous art because they are in the same field of endeavor, application configuration management. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg-Pickering-Olson to include the method of specifying user IDs as part of a configuration of a computing node as disclosed by Varghese. Doing so would allow individual computing nodes to identify which of the plurality of users will be granted access to a computing node. This ensures that only specific or authorized users are able to use specific elements of the system.
Eisenberg-Pickering-Varghese does not disclose the step wherein the usage criteria comprises: a percentage of new data objects to be created using the new context.
Kolazhi discloses the step wherein the usage criteria comprises: a percentage of new data objects to be created using the new context. See Paragraph [0030], (Disclosing a system for managing host process requests to a service according to a plurality of control versions of a configuration. A new configuration may be assigned a proportion of requests to be accepted at a particular host. i.e. a percentage of new data objects to be created using the new context (e.g. the percentage of requests processed according to the new configuration).)
Eisenberg, Pickering, Olson, Varghese and Kolazhi are analogous art because they are in the same field of endeavor, configuration management. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg-Pickering-Olson-Varghese to include the method of allowing a new configuration to accept a proportion of requests that may be modified over time as disclosed by Kolazhi. Paragraphs [0016]-[0017] of Kolazhi discloses the following technical advantages of the method: (1) improving the availability and performance of computer systems during deployment of new configurations by gradually increasing the exposure of configuration changes on a host-by-host basis; (2) improving the accuracy of configuration testing by isolating the testing of a change to one configuration from changes to other configurations; (3) improving the accuracy of configuration testing by producing independent streams of metrics for a control configuration and a candidate configuration; (4) improving the availability of individual computer systems by performing local rollback of problematic configurations; (5) preventing fleet-wide service outages by using centralized monitoring of configuration changes with potential fleet-wide rollback; Which represent technical improvements.
Regarding dependent claim 11,
The claim is analogous to the subject matter of dependent claim 4 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding dependent claim 18,
The claim is analogous to the subject matter of dependent claim 4 directed to a computer system and is rejected under similar rationale.
Claim(s) 6, 13 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Eisenberg in view of Pickering and Olson as applied to claim 1 above, and further in view of Hansen et al. (US PGPUB No. 2023/0205506; Pub. Date: Jun. 29, 2023).
Regarding dependent claim 6,
As discussed above with claim 1, Eisenberg-Pickering-Olson discloses all of the limitations.
Eisenberg-Pickering-Olson does not disclose the step of migrating, to a default context, data of data objects created while the new context is in the context state of merge.
Hansen discloses the step of migrating, to a default context, data of data objects created while the new context is in the context state of merge. See Paragraph [0045], (Disclosing a system for executing a function that builds a software instance definition object. Creating or updating a new software interface may create a new software instance definition object. A fix command may fix any part of the default or template instance that does not match the corresponding software instance definition, i.e. migrating (e.g. via fixing), to a default context (e.g. the template representing a default configuration), data of data objects created while the new context is in the context state of merge (e.g. the new portions that do not match the default template).)
Eisenberg, Pickering, Olson and Hansen are analogous art because they are in the same field of endeavor, application management. It would have been obvious to anyone having ordinary skill in the art before the effective filing date to modify the system of Eisenberg-Pickering-Olson to include the method of modifying a default context as part of a process of creating a new software definition as disclosed by Hansen. Doing so would allow the system to update a default template with additional information in order to maintain coherency for a particular software instance as modifications are made.
Regarding dependent claim 13,
The claim is analogous to the subject matter of dependent claim 6 directed to a non-transitory, computer readable medium and is rejected under similar rationale.
Regarding independent claim 20,
The claim is analogous to the subject matter of dependent claim 6 directed to a computer system and is rejected under similar rationale.
Examiner’s Input
The following represents prior art determined to be relevant to at least independent claims 1, 8 and 15 but not relied upon in the prior art rejections discussed above:
Chittigala et al.(US PGPUB No. 2018/0101373; Pub. Date: Apr. 12, 2018)
Chittigala is directed to a system for operating system management. FIG.4 illustrates method 400 of managing an operating system update for a shared pool of configurable computing resources having a plurality of logical partitions (LPARS). The method comprises step 450 of establishing a set of successor files on a set of surrogate nodes to succeed a set of original files on the set of original nodes which includes generating a reproduction of a set of original files which includes creating a new logical partition for each original node of the set of original nodes and replicating the system configuration of each original node on a corresponding surrogate node.
Paragraphs [0066], [0068] & [0070] describe the following steps of method 400:
At step 460, the method creates a set of successor overlay links comprising pointers, indicators, addresses, mappings, etc. that that designate the location of data files on a physical memory space.
At step 462, the system invalidates original overlay links and validates the successor overlay links.
At step 470, the operating system traffic network is routed to utilize the set of successor overlay links.
The process of FIG. 4 of Chittigala is relevant to at least the following limitations of independent claim 1:
a computer-implemented method, comprising:creating, using a context manager (CM), a new context;
deploying, using the CM, a new configuration-variant;
assigning, using the CM, the new context for use by users connecting to a database schema of the new context;
determining, using the CM, to phase out use of the new configuration-variant, wherein determining, using the CM, to phase out use of the new configuration-variant, comprises: switching, using the CM, a context state of the new context to phase-out, comprising: processing existing data objects within the new context until they are considered closed, wherein processing the existing data objects comprises creating a successor data object in the new context in response to determining that a predecessor data object associated with the successor data object was created in the new context;
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 8 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant’s amendments necessitated the new grounds of rejection presented in this Office Action.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Fernando M Mari whose telephone number is (571)272-2498. The examiner can normally be reached Monday-Friday 7am-4pm.
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, Ann J. Lo can be reached at (571) 272-9767. 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.
/FMMV/Examiner, Art Unit 2159
/ALBERT M PHILLIPS, III/Primary Examiner, Art Unit 2159
Prosecution Insights