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 .
Priority
The later-filed application must be an application for a patent for an invention which is also disclosed in the prior application (the parent or original nonprovisional application or provisional application). The disclosure of the invention in the parent application and in the later-filed application must be sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA 35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v. Performance Contracting, Inc., 38 F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed applications, Application No. 61/229,701; 61/354,648; 12/845,548; 13/937,127; 14/189,920; 15/366,208; 15/488,726; 15/933,954; 16/423,469, fail to provide adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35 U.S.C. 112, first paragraph for one or more claims of this application. The original specification of the present application and 16/887,374 application, and the entire disclosures of the above listed chain of priority of applications fail to support the following limitation: “the controller is configured to electronically receive the information relating to the weight of the destination container and to compare that information to the value from the memory to determine how much fluid to transfer from the source container to the destination container” (Emphasis added). This limitation was first introduced in the filing of the original claims of the 16/887,374 application. However, this issue is only just now being raised for the first time as it was missed in the ‘374 application.
The following are selected quotations from the specification that have at least one of the following words: memory, controller, weigh, and weight. Emphasis added in selected portions.
[0133] Figure 1 schematically shows an embodiment of an automated fluid transfer system 100. The system 100 can include a housing 102 enclosing a controller 104 and a memory module 106. The system 100 can also include a user interface 108, which can be, for example, external to the housing 102. The user interface 108 can also be integrated into the housing 102 in some cases. The user interface 108 can include, for example, a display, a keypad, and/or a touch screen display. The user interface 108 can be configured to receive instructions from the user, for example, regarding the amounts of fluid to be transferred and the types of fluids to be transferred. The user interface can also be configured to provide information to the user, such as error messages, alerts, or instructions (e.g., to replace an empty vial). The system 100 can also include a bar code scanner 110 in communication with the controller 104. Although in the embodiment shown, the controller 104 and memory module 106 are contained within the housing 102, a variety of other configurations are possible. For example, controller 104 can be external to the housing 102, and can be, for example contained within a second housing which also contains the user interface 108. In some embodiments, the system 100 can include a communication interface 105 configured to receive information (e.g., instructions) from a remote source such as a terminal or an automated management system, etc. In some embodiments, the communication interface can also send information (e.g., results or alerts) to the remote source. In some embodiments, the system 100 does not include a communication interface 105 and does not communicate with a remote source.
Paragraph [0133] introduces the controller and the memory for the first time. It discusses that it is the user input that the controller uses to determine the amount to transfer.
[0142] In some embodiments the system 100 can include sensors 128a-c for detecting the presence of target containers 116a-c. Sensors 128a-c can be in communication with the controller 104 so as to prevent the system 100 from attempting to transfer fluid when no target container 116a-c is connected. A variety of sensor types can be used for sensors 128a-c. For example, sensors 128a-c can be weight sensors or infrared sensors or other form of electronic eye. In some embodiments, weight sensors 128a-c can also be used to measure the weight of the target containers 116a-c after fluid has been transferred. The final weight of a target container 116a-c can be compared to an expected weight by the controller 104 to confirm that the proper amount of fluid was transferred into the target container 116a-c. Sensors 128a-c can be a variety of other sensor types, for example sensor pads or other sensor types able to detect the presence of target containers 116a-c.
Paragraph [0142] introduces weigh sensors for the first time. It discusses using the weight sensors to confirm the amount that was transferred, not the amount to transfer.
[0143] Figure 2 schematically illustrates a system 200 for automated precise transfer of fluids. System 200 can be the same as or similar to the system 100 in some regards. Some features shown in Figure 1, such as the adapters 129a-c and compatibility mechanisms 127a-c, are not shown specifically in the system 200, but it will be understood that system 200 can include corresponding features. The system 200 can include a housing 202, a controller 204, a memory 206, a user interface 208, a scanner 210, and a communication interface 205, similar to those describe above in connection with the system 100.System 100 is configured to transfer individual fluids from the source containers 114a-c to target containers 116a-c. System 200, on the other hand, is configured to transfer and combine fluids from source containers 214a-c into a common target container 216. Thus, system 200 can be used for compounding mixtures of fluids. In some embodiments, a single system can be configured both for compounding mixtures of fluids and for the transfer of individual fluids from a single-source container to a single-target container. For example, a system containing six fluid transfer stations can be configured so that transfer stations 1-3 are dedicated to compounding mixtures of fluids into a single common target container, while fluid transfer stations 4-6 can be configured to each transfer fluid from a single source container to a single target container. Other configurations are possible. In the embodiment shown in Figure 2, the system 200 can include sensors 228a-c for detecting whether or not the connectors 220a-c are connected to the common target container 216. The system 200 can also include a sensor 229 for detecting the presence of the common target container 216. In some embodiments, the sensor 229 can measure the weight of the common target container 216 and can report the weight to the controller 104. The controller 104 is then able to compare the final weight of the common target container 216 with an expected weight to confirm that the common target container 152 was filled with the correct amount of fluids.
Paragraph [0143] discusses using the weight after the fluid is transferred.
[0244] Returning now to Figure 15, the system 600 can include a user interface 692 for receiving information and commands from the user and for providing information to the user. The user interface 692 can be part of an external unit 694, or it can be integrated into or attached to the base housing 602. The user interface 692 can include, for example, a touch screen display. The user interface 692 can be in wired or wireless communication with the controller. In some embodiments, a cable 696 connects the external unit 694 to the base housing 602 and provides a communication link between the user interface 692 and the controller. In some embodiments, the controller can be contained in the external unit 694 along with the user interface 692 and the controller can send and receive signals to and from components (e.g., the motors) of the system 600 through the cable 696. The user interface 692 can be configured to receive instructions from the user regarding the amounts of fluids to be transferred by the transfer stations 604a-604f. The user interface 692 can deliver the instructions to the controller to be stored in a memory and/or used to actuate the motor(s) to transfer the desired amount of fluids.
Paragraph [0244] discusses the user inputting the amounts to be transferred which are then delivered to the controller.
[0246] The system 600 can also include a bar code scanner 698, in communication with the controller and/or memory. The bar code scanner 698 can be used to provide information about the system 600 to the controller and/or the memory. For example, the syringe 606 can include a bar code that identifies the size and type of the syringe 606. The user can scan the syringe 606 with the bar code scanner 698 and then scan a bar code associated with the transfer station 604a to inform the controller of the size of the syringe 606 that is attached to the transfer station 604a. Different sizes of syringes can hold different volumes of fluid when their plungers are withdrawn by the same distance. Thus, when the controller is tasked with filling the syringe 606 with a predetermined amount of fluid, the controller can determine how far the plunger is to be withdrawn to fill the particular type of syringe with the predetermined amount of fluid. The vials (not shown) can also include bar codes that indicate the type of fluid contained therein. The user can scan a vial and then scan the bar code associated with the particular transfer station the vial is to be installed onto. Thus, the controller can be aware of what fluids are controlled by which transfer stations to facilitate automated transfer of fluids. Other components of the system 600 can also include bar codes readable by the bar code scanner 698 for providing information about the components to the controller and/or memory. In some embodiments, the user interface 692 can be configured to allow the user to input data relating to the size of the syringe 606, the type of fluid contained in a vial, etc. instead of using the bar code scanner 698.
Paragraph [0246] discusses using a bar code scanner to determine the size of the source container which is then stored in memory. It only throws in a catch all at the end that completely undefined “other components” can include bar codes. This is not sufficient to provide support for the specifically claimed limitation.
[0250] In some embodiments, the support arm 2250 can include a weight sensor 2256, or other type of sensor, capable of determining whether an IV bag assembly (not shown in Figure 22) is connected to the target connector portion 2236. For example, the weight sensor 2256 can "feel" the weight of the TV bag as the support arm 2250 provides support thereto. The weight sensor 2256 can be in electronic communication with the controller so that the controller can confirm that an IV bag assembly is attached to the target connector portion 2236 before transferring fluid into the IV bag.
Paragraph [0250] discusses using the weight sensor to determine whether a container is attached. There is no disclosure that this is used to determine the amount to transfer.
[0251] In some embodiments, the weight sensor 2256 can be used to confirm that the correct amount of fluid was transferred to the IV bag. The controller can be configured to calculate an expected weight for the IV bag from the instructions received from the user and from information stored in a memory, e.g., the amount of fluid to be transferred, the density of the fluid to be transferred, the starting weight of the empty IV bag, etc. Once the transfer of fluid is complete the controller can measure the final weight of the IV bag using the weight sensor and can compare the final weight to the expected weight. If the final weight differs from the expected weight by more than an acceptable tolerance amount (e.g., determined by the accuracy of the weight sensor), the controller can send an error message or alert to the user interface informing the user that an error likely occurred in the fluid transfer (e.g., the wrong fluid type was transferred or the wrong amount of fluid was transferred).
Paragraph [0251] discusses using the weight sensor to confirm the correct amount of fluid was transferred. This is not a disclosure that the controller uses the weight to determine how much to transfer.
[0259] If the fluid transfer stations are properly equipped, the method 2300 can proceed to block 2308 where the controller determines whether the IV bag assembly is properly attached. In some embodiments, the system can include, for example, a weight sensor or IR sensor capable of determining whether the target connector portion for a transfer station is connected to an IV bag assembly. In some embodiments, the weight sensor and controller can determine whether the IV has been filled with a desired amount of diluent. In some embodiments, the memory can include a database or lookup table indicating which transfer stations are associated with which IV bags (which can be especially useful when multiple transfer stations are associated with a single IV bag). The information can be input by the user via the user interface or by scanning bar codes on the IV bags and transfer stations. If the controller determines that the IV bag assembly is not properly attached (e.g., no IV bag attached, or incorrect IV bag weight for desired diluent, or a wrong combination of transfer stations associated with the IV bag), the user interface can prompt the user to attach an IV bag or otherwise change the IV bag configuration. After the user makes the changes, the process 2300 can return to block 2308 to confirm that the IV bag assembly is properly attached and configured.
Paragraph [0259] discusses using the weight sensor to confirm the correct amount of fluid was transferred and whether it has been filled with the proper amount of fluid. This is not a disclosure that the controller uses the weight to determine how much to transfer.
[0261] Figure 24 is a flowchart that schematically shows an embodiment of a method 2400 for transferring an amount of fluid from a vial to an IV bag. At block 2402, the controller determines an amount of fluid to be transferred. In some embodiments, the amount can be specified directly by the fluid transfer command. In some embodiments, the amount of fluid (e.g., medication or diluent) can be affected by the desired concentration and the concentration of the fluid contained in the vial.
[0262] At block 2404, the controller determines whether the transfer amount is greater than the effective maximum volume of the syringe associated with the transfer station. In some embodiments, the memory can include a database or lookup table that stores the sizes of the syringes associated with the different transfer stations. The information can be input by the user via the user interface or by scanning bar codes on the syringes and transfer stations. In some embodiments, the effective maximum volume of a syringe is the
volume of the syringe when the plunger is substantially fully retracted. In some embodiments, the effective maximum volume of the syringe is the volume of the syringe when the plunger is retracted by the maximum amount that the actuator is able to retract.
Paragraphs [0261-262] discuss in detail a method and flow chart for determining the amount to transfer. No where does it disclose that it is the weight that is used to determine this amount.
[0270] Figure 25 is a flowchart that schematically shows an embodiment of a method 2500 for confirming the successful transfer of fluid by checking the weight of the final IV bag. At block 2502, the controller can determine an expected IV bag weight for the
final IV bag filled with the transferred fluid. The expected weight can be determined by the starting weight of the empty IV bag (or the starting weight of the IV bag with diluent), and the amount and density of fluid to be transferred into the IV bag.
[0271] At block 2504, the system can measure the actual IV bag weight. In some embodiments, the system can include a weight sensor and can automatically measure the weight of the IV bag once the fluid transfer is complete. In some embodiments, the user interface can prompt the user to weigh the IV bag and enter the weight. In some embodiments, the user interface can prompt the user that the transfer is complete and display the expected weight for the IV bag. The user can then weigh the IV bag and compare the actual weight against the displayed expected weight.
[0272] At block 2506, the controller can compare the actual IV bag weight to the expected IV bag weight. If the actual IV bag weight differs from the expected IV bag weight by more than a threshold tolerance amount, the method 2500 can determine that an error occurred during the fluid transfer and advance to block 2510. At block 2510, the controller can attempt to determine possible causes of the fluid transfer failure. Many circumstances can lead to a fluid transfer failure. For example, if the user changes the type of fluid for a fluid transfer station without properly updating the database, the IV bag can contain the correct amount of fluid but since the fluid can have a different density the final weight of the IV bag can be different from the expected amount. If the user changes the syringe size for the transfer station without properly updating the database the actuation of the plunger can transfer an amount of fluid different than intended and the final weight of the IV bag can differ from the expected weight. The controller can be configured determine possible causes for the failure based at least in part on the amount by which the actual IV bag weight differs from the expected weight. At block 2512, the user interface can inform the user of the failure and can display one or more possible causes for the failure to aid the user in trouble shooting the problem.
[0273] If the actual IV bag weight is within the threshold tolerance amount of the expected weight, the system can conclude that the fluid was transferred successfully, and the method can advance to block 2508. At block 2508, the user interface can inform the user that the fluid was transferred successfully. The threshold tolerance amount can be determined by several factors, including the precision of the weight sensors, the amount of
fluid transferred, and the accuracy provided by the syringe(s) used. It should be noted that some fluid transfer errors can go undetected by checking the weight of the IV bag. For example, if an incorrect fluid is used that has the same density as the correct fluid, the final IV bag will weigh the correct amount. However, by checking the weight of the IV bag, many errors can be detected.
Paragraphs [0270]-[0273] go into depth about how the controller uses weight to confirm successful transfer. That is how much fluid was transferred, not how much to transfer.
Additionally, see the 112(a) rejection, infra. Accordingly, the claimed limitation is not supported by the chain of priority, and therefore the priority claim must be deleted.
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 2-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over: claims 1-12 of U.S. Patent No. 9,883,987; claims 1-25 of U.S. Patent No. 11,439,570; and claims 1-23 of U.S. Patent No. 12,186,270. Although the claims at issue are not identical, they are not patentably distinct from each other because the present claims are merely broader than the patent claims and/or add obvious features thereto. See the art rejection for the obvious alarm feature and reasons for why the alarm is obvious. Similar reasoning applies here.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 2-17 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
MPEP 2163.03(V.) recites, inter alia,
While there is a presumption that an adequate written description of the claimed invention is present in the specification as filed. In re Wertheim, 541 F.2d 257, 262, 191 USPQ 90, 96 (CCPA 1976), a question as to whether a specification provides an adequate written description may arise in the context of an original claim. An original claim may lack written description support when (1) the claim defines the invention in functional language specifying a desired result but the disclosure fails to sufficiently identify how the function is performed or the result is achieved.
In this case, the claims recite, “the controller is configured to electronically receive the information relating to the weight of the destination container and to compare that information to the value from the memory to determine how much fluid to transfer from the source container to the destination container” (emphasis added).
The specification as discussed, supra, fails to describe how this function is actually performed nor does it provide explicitly support for the claimed limitation. How does the controller use the weight of the destination container to actually determine the amount of fluid to transfer. The specification makes clear that the weight is used to confirm the amount of fluid transferred was corrected, not to determine the amount based on the weight before the transferring begins. The specification also mentions using the weight sensor for determining if the destination container is present, but this also does not support how one would go about using that weight to determine the amount to transfer. The specification makes clear it is the suer inputting the amount to transfer that is then sent to the controller to control the amount transferred. Accordingly, the specification has failed to disclose how one could perform the claimed function. How is the weight of a bag to be filled used to determine the amount to fill into the container? What steps would have to be done to use this weight to determine the amount to fill? What if containers of different volumes have the same weight? What if a small container is partially filled and has the weight of a larger empty container? How is this result achieved?
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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) 18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over 2004/0087888 (DiGianfilippo, cited on the IDS) in view of 5,885,270 (Ortiz, cited on the IDS) and further in view of Miller (4,513,796).
In re claim 18, DiGianfilippo discloses an electronically controlled medical fluid transfer system (everything in fig.1) being configured to transfer medical fluids from a source container to a destination container, the medical fluid transfer system comprising:
an electronic fluid transfer station (10) comprising:
an electric motor (64);
a pump (54) being configured to be driven by the electric motor and to transfer medical fluid;
a user interface (76, 78) comprising a display (76), the user interface being configured to receive user input and to convey information to a user (para.61);
a memory (74, 122, paras.57, 114, 148) being configured to store information;
an electronic controller (20) being in electrical communication with the motor, the user interface, and the memory, the controller being configured to store a value relating to an expected weight of the destination container in the memory (para.179);
a disposable fluid transfer tubing (12, para.49) being configured to be functionally connected to the pump;
a weight sensor (30) in electronic communication with the electronic controller, the weight sensor being configured to detect information relating to the weight of the destination container (paras.50, 56);
wherein the controller is configured to electronically receive the information relating to the weight of the destination container (para.177-178, fig.11E(5)).
DiGianfilippo fails to explicitly disclose a sensor being configured to detect a presence of a connector functionally attached to the electronic fluid transfer station, and the controller is configured to notify a user when the expected weight is different from the information detected about the weight of the destination container by the sensor. However, DiGianfilippo does explicitly disclose that confirmation of the correct final container and alerting a user when the wrong one is selected is an important aspect to ensuring patient safety (para.178).
Ortiz teaches a system (figs.3, 5) having a sensor (48) being configured to detect a presence of a connector functionally attached to the electronic fluid transfer station.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the teachings of Ortiz in DiGianfilippo for the purpose of ensuring that the fluid transfer system functions as intended, i.e. the system doesn’t transfer fluid without first sensing the connector is appropriately connected, and the transfer is fully automated.
Miller discloses a system comprising a controller configured to notify a user when the expected weight is different from the information detected about the weight of the destination container by the sensor (col.6 ln. 32-48).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the teachings of Miller in DiGianfilippo for the purpose of ensuring proper operation of the system thereby increasing patient safety.
In re claim 20, DiGianfilippo discloses the medical fluid transfer system of Claim 18, further comprising an electronic scanner (82) configured to receive information about the fluid to be transferred from the source container to the destination container so that such information can be stored in the memory (has all of the structure required to perform the function recited).
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over 2004/0087888 DiGianfilippo in view of Ortiz, Miller, and further in view of Iwatschenko (4,625,494).
In re claim 19, DiGianfilippo fails to explicitly disclose the medical fluid transfer system of Claim 18, wherein the controller is configured to stop the transfer of fluid from the source container to the destination container when an air sensor detects the presence of air in the fluid transfer tubing.
Iwatschenko teaches another system wherein the controller is configured to stop the transfer of fluid from the source container to the destination container when an air sensor detects the presence of air in the fluid transfer tubing (claim 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to utilize the teachings of Iwatschenko in DiGianfilippo for the purpose of providing an air free container thereby increasing storage life and reducing the possibility of contamination thereby increasing patient safety.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Timothy P. Kelly whose telephone number is (571)270-7615. The examiner can normally be reached from 8:30 a.m. to 4:30 p.m. (ET) on Monday, Thursday, and Friday.
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, Craig M Schneider can be reached at (571) 272-3607. 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.
/Timothy P. Kelly/Primary Examiner, Art Unit 3753