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 action is responsive to communication received on 10/15/2024. The applicant has submitted 20 claims for examination, all claims are currently pending.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,153,635. Although the claims at issue are not identical, they are not patentably distinct from each other because claims of the instant application 18/915,884 recite a broader claim set than US 12,153,635. See table below.
18/915,884
US 12,153,635
1. One or more non-transitory media having instructions that, when executed by one or more processors, cause the one or more processors to facilitate a plurality of operations, the operations comprising:
detecting via a listener component associated with the one or more processors a set of triggering events;
determining via an assembler component associated with the one or more processors that a preset amount of time has passed following a time associated with the detecting; in response to the determining, communicating with a searchable data storage system via a runtime component associated with the one or more processors, wherein the communicating comprises:
(a) initiating a query via the runtime component to the searchable data storage system; and (b) in response to the query, receiving data indicating a first set of information in a first standardized format associated with a data-interoperability concept; and transforming via the one or more processors the extracted information to a second standardized format outside of the first standardized format according to the data-interoperability concept.
1. One or more non-transitory media having instructions that, when executed by one or more processors associated with a Consolidated Document Architecture (CDA) assembler external to and coupled via a network to a Fast Healthcare Interoperability Resources (FHIR)-enabled system, cause the one or more processors to facilitate a plurality of operations, the operations comprising:
identifying, by a listener component of the CDA assembler, a triggering event;
in response to the identifying, initiating creation of a CDA document, at least by: presenting a script builder user interface via the CDA assembler; and receiving via the script builder user interface a request for generation of the CDA document; generating, by a script builder tool of the CDA assembler using a template script, an executable script that includes: script instructions indicating data to include in the CDA document, the data associated with a FHIR resource and with the FHIR-enabled system; and script data indicating at least one mapping of the FHIR resource to a CDA resource to include in the CDA document; and executing the executable script, by a runtime component of the CDA assembler, to perform:
(a) initiating a FHIR Application Programming Interface (API) call to the FHIR-enabled system to locate the data within the FHIR-enabled system based on one or both of the script instructions and the script data, wherein initiating the FHIR API call causes querying of the FHIR-enabled system for the data and locating the data within the FHIR-enabled system responsive to the querying; (b) applying the at least one mapping, to the data received responsive to the querying, based on one or both of the script instructions and the script data and in response to the locating of the data; (c) compiling the data based on the applying; and (d) creating the CDA document based on the compiling, wherein the CDA document is created in a CDA format.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Chen US 2015/0310176 and further in view of Emanuel US 2017/0103163.
Regarding claims 1, 8 and 15, Chen teaches one or more non-transitory media having instructions that, when executed by one or more processors, cause the one or more processors to facilitate a plurality of operations, the operations comprising: detecting via a listener component(events center 300 fig1(a)) associated with the one or more processors a set of triggering events comprising(Fig 1a show a workflow healthcare event response and communication center, external to the health data sources, where the data sources are HL7 and support event trigger actions for data retrieval and generation of CDA documents, fig 1(a), ¶s31,32)
[0031] The present teaching may be implemented in architecture as shown in FIG. 1(a), as one possible embodiment. In this embodiment, a Health Data Sources 110 comprises various healthcare entities, such as an array of HIE vendors, organizations, and regional subnet works, that will exchange or transfer Electronic Health Records (EHR) in a trust frame work. EHRs can be created, managed, and consulted by authorized providers and staff across more than one health care organization. EHRs may include information about a patient's medical history, diagnoses, medications, immunization dates, allergies, radiology images, and lab and test results. EHRs may also include real-time, patient-centered records. A single EHR may bring together information about a patient from current and past doctors, emergency facilities, school and workplace clinics, pharmacies, laboratories, and medical imaging facilities.
[0032] The trust frame work is established by, for example, authorized entities that provide trust assurance of data maintenance and use, as supported by their contact agreements. The trust frame work of the Health Data Sources 110 allows trusted secure exchange of EHR and other clinical information. In one example, the EHR is exchanged in the form of secured messages by Health Information Service Providers (HISP). In another example, the EHR is exchanged in the form of documents in the health information exchange (HIE), using document formats, such as, for example, Continuity of Care Document (CCD), Clinical Document Architecture (CDA), Electronic Data Interchange (EDI) and Health Level 7 documents (HL7).
determining via an assembler component associated with the one or more processors that a preset amount of time has passed following a time associated with the detecting(message and events from entities source health data sources trigger workflows to create documents after some time such as after discharge event, ¶s70-73,82,),
[0070] In summary, by allowing messages from one entity to trigger events and workflows in one or more other entities, the present teaching provides a mechanism to enable timely collaboration among different entities based on real-time data content.
[0071] The event center 300 includes a message processor 310 operable to process raw messages received from different entities in the health data source 110 and to extract meaningful content based on the raw message.
[0072] The message processor 310 is operable to identify the source entity of the raw message, such as whether the raw message is from hospital A or hospital B, or Lab X or Lab Y. The message processor 310 is also operable to identify the type of the raw message, such as whether it is an ADT message, a PDI message, a message that includes a CCD document, a message that includes a CDA document, a message that includes an EDI document or any other types of message. The message processor 310 may determine the source entity and the message type typically by analyzing the header portion of the raw message.
[0073] The message processor 310 may further extract meaningful content from the body of the raw message based on the source entity and message type of a received raw message. More specifically, the message processor 310 may apply appropriate message format rules that are specific to the source entity to extract meaningful content from the raw message.
[0082] In another example, a hospital sends patient discharge instruction (PDI) HL7 messages shortly after a patient is discharged. A patient discharge event may be identified by the message types, for example, by the value within the HL7 segment OBR-21. In another example, a hospital may send discharge instructions in a HL7 message. For some hospitals, the PDI is contained within the Discharge Summary (which can take up to 72 hours to be sent out) and in others it is a separate message that is sent much closer to the actual discharge. Even in those hospitals in which the PDI is included in a Discharge Summary, having the more prompt PDI notification is seen as a benefit to physicians that have follow-up care responsibilities in the event of post-discharge complications upon a patient's discharge.
in response to the determining, communicating with a searchable data storage system via a runtime component associated with the one or more processors, wherein the communicating comprises: (a) initiating a query via the runtime component to the searchable data storage system(system provides for retrieval of health record information from various data sources as part of workflows that include generating report, for example a discharge summary, ¶s 74,75,82)
[0074] Moreover, the message processor 310 may also provide Application Programming Interface (API) as a mechanism for defining a new message types and for extracting meaningful contents from messages of the new message type.
[0075] Hospitals typically follow the HL7 message standard when sending out ADT messages. HL7 is a medical health informatics standard which provides a framework (and related standards) for the exchange, integration, sharing, and retrieval of electronic health information. Health information that is common across organizations (for example, patient demographics and patient events such as admission, discharge, and transfer) has a specified format and codes that can be incorporated into all EMRs.
[0082] In another example, a hospital sends patient discharge instruction (PDI) HL7 messages shortly after a patient is discharged. A patient discharge event may be identified by the message types, for example, by the value within the HL7 segment OBR-21. In another example, a hospital may send discharge instructions in a HL7 message. For some hospitals, the PDI is contained within the Discharge Summary (which can take up to 72 hours to be sent out) and in others it is a separate message that is sent much closer to the actual discharge. Even in those hospitals in which the PDI is included in a Discharge Summary, having the more prompt PDI notification is seen as a benefit to physicians that have follow-up care responsibilities in the event of post-discharge complications upon a patient's discharge.
Chen does not teach and (b) in response to the query, receiving data indicating a first set of information in a first standardized format associated with a data-interoperability concept; and transforming via the one or more processors the extracted information to a second standardized format outside of the first standardized format according to the data-interoperability concept.
Emanuel in the same field of endeavor as the invention teaches a system for exchange of health record data and generation of health record documents using CDA templates. Emmanuel teaches and (b) in response to the query, receiving data indicating a first set of information in a first standardized format associated with a data-interoperability concept FHIR uses RESTful API requests(i.e. calls,) to exchange data… i.e queries data from FHIR sources, ¶s 31 45, 47, 49 see api calls(read resource) as defined by FHIR HL7 RESTful API )
[0031] In another exemplary embodiment, another advantage of storing data in HIEs based on the Referent Index is that a provider using one EHR system can request information to be sent in its native information exchange format (e.g., as C-CDA document or FHIR resource) from the HIE where the data area based on aggregate information that originated from other EHR systems sending C-CDA documents, HL7 Version 2 messages, or NCPDP SCRIPT transactions. FIG. 5 illustrates how an EHR may request summary of information from an HIE that aggregates information received using a variety of information exchange formats that are mapped to a consistent Referent Index in a consistent HIE Database that follow the canonical structure of the data (i.e., Referent Index).
[0045] In an embodiment, the runtime components consist of a general-purpose Information Exchange Hub (IExHub) that enables EHR systems to exchange protected health information (content) independent of information exchange formats (e.g., HL7 CDA, FHIR, Version 2.X, NIEM, etc.). The IExHub is a set of Java-based RESTful services implemented with an Apache Tomcat web/application server which converts local data into standard-based formats, such as Continuity of Care (CCD) documents based on Consolidated CDA (C-CDA) templates, Fast Health Interoperability Resources (FHIR) and other information exchange formats. The IExHub is also used to transform C-CDA documents into FHIR profiles or other equivalent information exchange formats so that EHR systems can send and receive in their preferred information exchange format.
[0047] In an additional embodiment, another runtime component is a sample EHR Application (IExApp) reference implementation that demonstrates how XML queries, inserts, and persistence (accounting for disclosures and data provenance) may be implemented. We envision that this architecture promotes the separation of concerns that enable the development of verifiable real-time software systems.
[0049] The IExHub executes the maps created by the IExBench. It maintains and keeps the mapping file provided by the EHR sample application persistent across the system and strings together the local data map to the Referent Index and from the Referent Index map to the desired information exchange format map. The IExHub supports bi-directional exchange through its RESTful services that provide data transformation services to EHR systems that want to exchange data in different formats without loss of information.
and transforming via the one or more processors the extracted information to a second standardized format outside of the first standardized format according to the data-interoperability concept(use of mapping models to map data to from FHIR to CDA formatted documents using CDA templates. , ¶s47,50,51)
[0047] In an additional embodiment, another runtime component is a sample EHR Application (IExApp) reference implementation that demonstrates how XML queries, inserts, and persistence (accounting for disclosures and data provenance) may be implemented. We envision that this architecture promotes the separation of concerns that enable the development of verifiable real-time software systems.
[0050] Additional exemplary embodiments may include implementation support for HL7 Version 2 to enable semantic interoperability for the exchange of clinical laboratory results and orders required by Meaningful Use. Other enhancements may include extending model-driven standard specifications (e.g., CDA templates, FHIR resources) derived UML models describing interoperability requirements (e.g., Quality Improvement and Clinical Knowledge (QUICK), Biomedical Research Integration Domain Group (BRIDG)) to ensure that CDA templates and FHIR profiles stay equivalent to meet United States-specific interoperability requirements.
[0051] Another area of enhancement is to use MDHT to generate both implementation guides and mapping models for run-time. Once an analysis model is used to create templates or profiles, the model information is sufficient to generate a map from the domain-specific model (e.g., HL7 DAM, Federal Health Information Model (FHIM), Clinical Information Modeling Initiative (CIMI)) to the information exchange format (e.g., CDA, FHIR). This enhancement assumes that the MDMI runtime allows for a new Referent Index to be imported into the Map Editor to be used to map local EHR data to the Referent Index based on the standard UML model (e.g., HL7 DAM, FHIM, or CIMI).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chen’s system for executing workflows for generation of healthcare documents with the use of CDA templates for generating the healthcare documents. The reason for this modification would be to provide a system to automatically trigger creation and delivery healthcare documents using the latest FHIR exchange standard.
Regarding claims 2, 9 and 16, Chen teaches wherein at least a portion of the set of triggering events is associated with an activity of an individual, and wherein the individual is associated with the first set of information (discharge event triggering workflow to generate reports, ¶82).
[0082] In another example, a hospital sends patient discharge instruction (PDI) HL7 messages shortly after a patient is discharged. A patient discharge event may be identified by the message types, for example, by the value within the HL7 segment OBR-21. In another example, a hospital may send discharge instructions in a HL7 message. For some hospitals, the PDI is contained within the Discharge Summary (which can take up to 72 hours to be sent out) and in others it is a separate message that is sent much closer to the actual discharge. Even in those hospitals in which the PDI is included in a Discharge Summary, having the more prompt PDI notification is seen as a benefit to physicians that have follow-up care responsibilities in the event of post-discharge complications upon a patient's discharge.
Regarding claims 3, 10 and 17, Chen teaches wherein the preset amount of time corresponds to a number of hours following a healthcare event or encounter associated with the individual( triggering notification at a predefined time inherently requires internal or global time/clock, such an internal/global clock inherently defined in hours, minutes, seconds , predefined means it is defined in workflow prior to the time the event occurs that triggers notification as part of executing workflow, ¶58 ).
[0058] In one embodiment of the present teaching, the delivery engine 500 delivers the notification immediately. In another embodiment of the present teaching, the delivery engine batch delivers the notification in a predefined time. For example, a physician prefers to receive all non-urgent notifications at the end of the day, instead of receiving them upon its occurrence. In another embodiment of the present teaching, a subscriber would receive statistics of a certain event on a weekly or monthly basis. The delivery engine 500 may include a Notifications Queue to store and manage its notifications and deliveries.
Regarding claims 4, 11 and 18, Emanuel teaches wherein the query requests that the searchable data storage system locate the first set of information within the searchable data storage system(xml based queries to various health record databases, ¶s31,47).
[0031] In another exemplary embodiment, another advantage of storing data in HIEs based on the Referent Index is that a provider using one EHR system can request information to be sent in its native information exchange format (e.g., as C-CDA document or FHIR resource) from the HIE where the data area based on aggregate information that originated from other EHR systems sending C-CDA documents, HL7 Version 2 messages, or NCPDP SCRIPT transactions. FIG. 5 illustrates how an EHR may request summary of information from an HIE that aggregates information received using a variety of information exchange formats that are mapped to a consistent Referent Index in a consistent HIE Database that follow the canonical structure of the data (i.e., Referent Index).
[0047] In an additional embodiment, another runtime component is a sample EHR Application (IExApp) reference implementation that demonstrates how XML queries, inserts, and persistence (accounting for disclosures and data provenance) may be implemented. We envision that this architecture promotes the separation of concerns that enable the development of verifiable real-time software systems.
Regarding claims 5 and 12, Emmanual teaches wherein the receiving comprises extracting the first set of information in the first standardized format from the searchable data storage system(extracting data from a data store in C-CDA format, ¶54).
[0054] In a non-limiting example, the IEX transformation engine 112 collects information from one or more clients accessing the interface server 104 through a web browser 108 session. The information transmitted from a user may comprise documents formatted in a C-CDA format and will be stored in a C-CDA data store 116 for later transformation actions. The IEX engine 112 may retrieve documents from the C-CDA data store 116 and begin the process of parsing the C-CDA formatted documents to place the information in a transitional, parsed C-CDA form and save the parsed C-CDA document elements into a parsed C-CDA data store 120. The parsed C-CDA document elements may be operated upon immediately, or may be retrieved from the parsed C-CDA data store 120 at a later time to transform the input C-CDA document into another document format. By way of example and not of limitation, the C-CDA document elements may be transformed into an XDS formatted document and saved in an XDS data store 124 for later retrieval and transmission to a user session operational on one, or more than one, web browser 108 connected to the ELXR system 100.
Regarding claims 6 and 13, Emanuel teaches wherein the operations further comprise causing, via the one or more processors, electronic writing to a data structure disparate from the runtime component and from the searchable data storage system(mapping templates map from one format to another CDA to FHIR etc, ¶51).
[0051] Another area of enhancement is to use MDHT to generate both implementation guides and mapping models for run-time. Once an analysis model is used to create templates or profiles, the model information is sufficient to generate a map from the domain-specific model (e.g., HL7 DAM, Federal Health Information Model (FHIM), Clinical Information Modeling Initiative (CIMI)) to the information exchange format (e.g., CDA, FHIR). This enhancement assumes that the MDMI runtime allows for a new Referent Index to be imported into the Map Editor to be used to map local EHR data to the Referent Index based on the standard UML model (e.g., HL7 DAM, FHIM, or CIMI).
Regarding claim 19, Emanuel teaches wherein the receiving comprises extracting the first set of information in the first standardized format from the searchable data storage system(extracting data from a data store in C-CDA format, ¶54).
[0054] In a non-limiting example, the IEX transformation engine 112 collects information from one or more clients accessing the interface server 104 through a web browser 108 session. The information transmitted from a user may comprise documents formatted in a C-CDA format and will be stored in a C-CDA data store 116 for later transformation actions. The IEX engine 112 may retrieve documents from the C-CDA data store 116 and begin the process of parsing the C-CDA formatted documents to place the information in a transitional, parsed C-CDA form and save the parsed C-CDA document elements into a parsed C-CDA data store 120. The parsed C-CDA document elements may be operated upon immediately, or may be retrieved from the parsed C-CDA data store 120 at a later time to transform the input C-CDA document into another document format. By way of example and not of limitation, the C-CDA document elements may be transformed into an XDS formatted document and saved in an XDS data store 124 for later retrieval and transmission to a user session operational on one, or more than one, web browser 108 connected to the ELXR system 100.
and wherein the operations further comprise causing, via the one or more processors, electronic writing to a data structure disparate from the runtime component and from the searchable data storage system(mapping templates map from one format to another CDA to FHIR etc, ¶51).
[0051] Another area of enhancement is to use MDHT to generate both implementation guides and mapping models for run-time. Once an analysis model is used to create templates or profiles, the model information is sufficient to generate a map from the domain-specific model (e.g., HL7 DAM, Federal Health Information Model (FHIM), Clinical Information Modeling Initiative (CIMI)) to the information exchange format (e.g., CDA, FHIR). This enhancement assumes that the MDMI runtime allows for a new Referent Index to be imported into the Map Editor to be used to map local EHR data to the Referent Index based on the standard UML model (e.g., HL7 DAM, FHIM, or CIMI).
Regarding claims 7, 14 and 20 Chen teaches wherein the operations further comprise: detecting, at the listener component, a prescribed time(workflow may be triggered based on a prescribed time such as a particular event related to patient, ¶36).
[0036] A healthcare entity in the Health Data Sources 110 may proactively communicate with other healthcare entities in the trust frame work by sending standardized secure messages upon occurrence of a real-life event. For example, a hospital 110-a may want to send messages upon the occurrence of a patient event, such as, when the patient is admitted, discharged or transferred from the hospital 110-a, (ADT messages). The hospital 110-a may also want to send messages upon creation of an important document relate to a patient, such as, for example, a patient discharge summary (PDS) that includes a record of the patient hospital care and recommended follow up care.
and initiating, by the runtime component and in response to detecting the prescribed time, execution of an executable script configured to facilitate the communicating(predefined workflows for creating documents are executed to generate CDA documents, ¶s114,150).
[0114] FIG. 4(a) shows an exemplary system diagram of a workflow system 400, according to an embodiment of the present teaching. The workflow system 400 may process a received event, for example, by activating a pre-defined workflow associated with the received event. In one embodiment of the present teaching, an activated workflow in the workflow system 400 may automatically outputs notifications at a predetermined time based on the business process and schedules associated with the activated workflow.
[0150] FIG. 6 shows exemplary workflow diagrams, according to an embodiment of the present teaching. First, hospital A sends a PDI message to the Healthcare Event Response and Communication Center 120. Upon receiving the message, the event center 300 of the Healthcare Event Response and Communication Center 120 creates a PDI event from hospital A, which activates a PDI notification workflow for hospital A in the workflow system 400. The PDI notification workflow is predefined to send the PDI document to the primary care provider, Dr. Strong. The workflow system further examines the recipient rules for Dr. Strong, whose preference is set to receive PDI documents right away. As a result, the PDI document is delivered, hospital A's PDI notification workflow ends.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights