DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. 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 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.
3. The following office action is a Final Office Action in response to the communications received on 01/29/2026.
Claims 16, 17, 21, 24, 25, 27, 34 and 35 have been amended; claims 1-15, 19, 20, 22, 23 and 36 have been canceled. Therefore, claims 16-18, 21, 24-35 and 37-39 are currently pending in this application.
Claim Rejections - 35 USC § 112
4. The following is a quotation of 35 U.S.C.112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
● Claims 16-18, 21, 24-35 and 37-39 are rejected under 35 U.S.C. 112(b), or second paragraph (pre-AIA ), as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Clam 16 recites, “the user device being configured to . . . transmit a set of haptic response parameters to the training drug delivery device, the set of haptic response parameters comprising at least parameters defining the simulated haptic responses generated by the haptic drive in response to detecting user operation of the dosage dial and the delivery activation button of the training drug delivery device” (emphasis added).
Claim 34 recites, “the training drug delivery device being configured to . . . receive a set of haptic response parameters from the user device, the set of haptic response parameters comprising at least parameters defining the simulated haptic responses generated by the haptic drive in response to detecting user operation of the dosage dial and the delivery activation button of the training drug delivery device” (emphasis added).
Claim 35 recites, “the user device being configured to . . . receive sensor indications from the training drug delivery device; transmit a set of haptic response parameters comprising at least parameters defining simulated haptic responses generated by a haptic drive of the training drug delivery device in response to detecting user operation of a dosage dial and a delivery activation button of the training drug delivery device” (emphasis added).
Accordingly, it is unclear whether the user device is retransmitting the same data—i.e., the parameters defining the simulated haptic responses—that the training drug-delivery device already generated. Note that the “haptic drive” is part of the training drug-delivery device; thus, since it has already generated simulated haptic responses in response to the user’s operation of the dosage dial and the activation button, it is unclear what haptic response parameters, which correspond to the dosage dial and the activation button, are being transmitted from the user device to the drug-delivery device.
Accordingly, each of claims 16, 34 and 35 (including their respective dependent claims) are ambiguous at least for the reason above.
Applicant is further advised to review each of the claims and make appropriate corrections if additional discrepancies are discovered. It is important to note that it is Applicant’s responsibility to fully comply with the statutory mandates of 35 U.S.C.112.
► Although Applicant’s arguments directed to section §112(b) are fully considered, the arguments are directed merely to the previously presented claims. Accordingly, none of the arguments addresses the new issue noted above, which is introduced due to the current claim amendment.
Claim Rejections - 35 USC § 103
5. 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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating
obviousness or nonobviousness.
Note that the one or more citations (paragraphs or columns) presented in this office action regarding the teaching of a cited reference(s) are exemplary only. Accordingly, such citation(s) are not intended to limit/restrict the teaching of the reference(s) to the cited portion(s) only. Applicant is required to evaluate the entire disclosure of each reference; such as additional portions that teach or suggest the claimed limitations.
● Claims 16-18, 21, 24-30, 32, 34, 35 and 37 are rejected under 35 U.S.C.103 as being unpatentable over Schuster 2016/0129182 in view of Uram 2014/0336615 and in view of Kopper 2020/0188030.
Regarding claim 16, Schuster teaches the following claimed limitations: a system comprising: a user device comprising a controller, a memory, and a wireless unit ([0026] lines 1-9; [0034]; [0056]: e.g., a system that monitors the delivery of a drug via a drug-delivery device—such as one or more types of injectors, etc., and wherein the system comprises one or more computing devices—such as a smartphone, a tablet computer, Google Glass, etc. Thus, such computing device already comprises a memory, a wireless unit and a controller—such as, a processor); and a training drug delivery device comprising a body, a cap, a dosage dial, a delivery activation button (see [0030]; [0033] lines 1-16; [0043] lines 1-12; also [0159]: e.g., the drug-delivery device, such as the injector, already comprises a body since it inherently has a housing. In addition, the delivery device comprises: (i) a cap or a cover since the system detects the removal of a cap/cover from the delivery device, (ii) a dial or a knob for setting the desired dose, (iii) a delivery activation button since the system also senses the press of a button—or the triggering of the injector—on the device. Note that the drug-delivery device above is also construed as a training drug-delivery device since it provides feedbacks or training to the user, see [0043] lines 19-27), a controller, a memory, a wireless unit for communicating with the user device ([0050] lines 1-9; [0054]; [0056]: e.g., the monitor, which includes a circuit board, can be incorporated into the delivery device during manufacture; and wherein the monitor stores calibration parameters and algorithms for analyzing data. The above demonstrates that the delivery device already incorporates a memory and a controller—such as, a processor. The monitor also incorporates a wireless communication means/unit that allows it to transmit data to a user device—such as the smartphone, tablet computer and/or Google Glass); a haptic [unit] to generate haptic responses of a real drug-delivery device [during] user operation ([0030]: e.g. the delivery device generates one or more vibrations based on the dose of the medication being administered; and this indicates the implementation of a haptic [unit] that generates haptic responses of a real drug-delivery device during user operation); and at least one sensor configured to measure (i) an attachment of the cap to the body and (ii) a depression of the delivery activation button relative to the body ([0043] lines 5-12; [0033] lines 1-16: e.g. the monitor already senses or detects various actions, including (i) the removal of a cap/cover, (ii) the press of a button or the triggering of the injector, etc. Accordingly, the above indicates that at least one sensor is configured to measure (i) an attachment of the cap to the body and (ii) a depression of the delivery activation button relative to the body); and at least one window-shaped region defined on the body, the window-shaped region comprises a dosage window ([0030]; [0043] lines 1-12: e.g., the delivery device—such as an autoinjector or insulin pen—normally includes a dosage window; and therefore, the delivery device already incorporates at least one window-shaped region defined on the body, the window-shaped region comprises a dosage window); the training drug delivery device being configured to connect, using the wireless unit of the training drug delivery device, to the user device and transmit sensor measurements of the at least one sensor to the user device ([0043] lines 1-19]; [0056]: e.g. the delivery device electronically communicates with a computing device(s)—such as, the smartphone and/or Google Glass; and thereby it transmits acquired data for display and/or further analysis, etc.); the user device being configured to connect, using the wireless unit of the user device, to the training drug delivery device, transmit a set of haptic response parameters to the training drug-delivery device, the set of haptic response parameters comprising at least parameters defining simulated haptic responses (see [0054]; [0056] lines 1-15; [0060] lines 1-18; [0061] lines 1-14: e.g. calibration parameters, including vibration data that denote one or more operational states of the delivery device, are downloaded using the smartphone; and thereby, reference vibration parameters are stored into the monitor of the drug-delivery device. Thus, the monitor uses these reference parameters in order to determine—during the usage of the drug-delivery device—is an event has occurred. The above indicates that the smartphone, which is the user device, transmits a set of haptic response parameters to the training drug-delivery device, wherein the set of haptic response parameters comprising at least parameters defining simulated haptic responses); receive the sensor measurements from the training drug-delivery device; and provide, based at least partly on the received sensor measurements, a user with feedback on handling the training drug-delivery device using augmented reality by the user device ([0056]; [0318]: e.g. the computing device—such as the smartphone or Google glass—already implements a wireless communication; and thereby it receives the data transmitted from the drug-delivery device in order to further analyze and/or display the data. In addition, based on the analysis of the data, the smartphone provides the user with further feedback(s)—such as training, warnings or alerts, etc. Moreover, the system incorporates Google Glass to display information; and this corresponds to the process of providing feedback using augmented reality. Accordingly, the user device receives the sensor measurements from the training drug-delivery device; and further provides—using at least an augmented reality—the user with feedback on handling the training drug-delivery device, based at least partly on the received sensor measurements. Note also that the content/topic of the feedback, such as feedback on handling the training drug-delivery device, is merely nonfunctional descriptive matter).
Schuster does not teach: a haptic drive powered and actively driven by the controller of the training drug-delivery device to generate simulated haptic responses that simulate actual haptic responses of several different real drug-delivery devices under user operation; and the user device causes the drug-delivery device to simulate haptic responses of several different real drug-delivery devices, wherein the user device receives a selection of the type of drug-delivery device that the user is training for; and the above set of haptic response parameters comprises at least parameters defining simulated haptic responses, which the haptic drive generates in response to detecting user operation of the dosage dial and the delivery activation button of the drug-delivery device.
However, Uram teaches an injection delivering system that comprises various components, including a drug-delivery device and a computer; the drug-delivery device incorporates an interface that is linked to its motor, so that the motor operates based on parameters received from the computer; and accordingly, the computer system transmits—to the drug-delivery device—one or more parameters that configure the operation of the drug-delivery device (e.g., parameters that configure the operation of the motor of the drug-delivery device) according to the injection procedure (see [0043]; [0046] to [0048]). For instance, the user identifies, via a drop-down menu displayed on the computer, the type of injection to be performed; and wherein, based on the information received from the user, the computer determines one or more injection parameters and transmits the parameters to the drug-delivery device; and thereby, the drug-delivery device operates according to the received parameters ([0055] lines 1-8; [0058]; [0059]).
Note that (a) the motor above corresponds to the haptic drive, which is actively driven by the interface (i.e., the controller), in order to generate simulated haptic responses of several real drug-delivery devices when the user is using/operating the delivery-device; and (b) the parameters that configure the operation of the motor of the drug-delivery device (e.g., causing the motor to run at one or more speeds based on the type of injection procedure the user has selected, etc.) correspond to the set of haptic responses parameters, which define the simulated haptic responses that the haptic drive generates when detecting the use operation.
It is further worth noting that Schuster already teaches that the system is also used for training the user regarding the proper use/operation of the drug-delivery device—such as, coaching the user regarding the proper use of the device ([0034]); wherein, based on sensor data detected as the user is operating the drug-delivery device (e.g., detecting one or more of : motion/shaking of the injector, setting of a dose, duration of vibration of motor, etc.), the system determines whether the user is properly or improperly operating the device; and thereby, the system presents the user with relevant training materials in order to train the user regarding the proper use/operation of the drug-delivery device ([0043]).
Accordingly, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Schuster in view of Uram; for example, by expanding the patient training mode—such as, incorporating at least one haptic drive—such as a motor—along with an interface that allows the haptic drive to receive one or more commands from the processor of the drug-delivery device and/or the user’s device; and the system’s algorithm is also upgraded so that the user’s device—such as the smartphone—provides the user with an option to select the type of instrument or injection procedure (e.g., injection using an autoinjector, injection using a needle-free injector, etc.); and wherein, based on the selection that the user is making, the smartphone transmits—to the drug-delivery device—relevant parameters that configure one or more components of the drug-delivery device (e.g., the activation button, the dosage knob, the electric motor, etc.) to operate according to the user’s selection (e.g., when the user selects an auto injection procedure, the smartphone transmits parameters that configure the motor of the drug-delivery device to operate at one or more speeds relevant to an autoinjector; and this causes the drug-delivery device to vibrate as an autoinjector, etc.); and furthermore, based on data detected regarding the user’s manipulation of the drug-delivery device, the smartphone provides relevant audio and/or visual information to the user (e.g., how to properly use an autoinjector if the user is incorrectly manipulating the drug-delivery device, etc.); so that, the user would have a chance to easily learn the type of haptic responses that he/she should get during actual injection of a drug(s) using one or more drug-delivery devices.
Schuster also does not teach the process of projecting projection generated by the user device onto the body of the drug-delivery device to overlay the at least one window-shaped region, wherein the projection comprises dose information of the drug-delivery device.
However, Kopper discloses a system that allows a user to manipulate a medical instrument while wearing a wearable device; wherein the system tracks the position of the instrument with respect to the wearable device; and wherein the system projects information corresponding to at least a portion of the instrument; and thereby overlays the information on the portion of the instrument ([0067]; [0080]; [0081]).
Note also that Schuster’s drug-delivery-device already includes a window region that comprises a dosage window since it is in the form of an autoinjector or an insulin pen (see [0030]).
Accordingly, given the above teaching, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Kopper; for example, by incorporating one or more tracking means that allows the system to easily track one or more positions and/or orientations of the delivery device with respect to the AR device (e.g., the Google Glass) that the user is wearing; and wherein the systems further projects and overlays, based on the position/orientation of the delivery device being tracked above, one or more pertinent visual elements (e.g., textual and/or graphic elements, etc.) on one or more corresponding portions of the delivery device (e.g., on the cap/cover region; on the window region—such as, the dosage window, etc.), so that the user would be able to easily acquire, based on the position and/or orientation of the delivery device that he/she is manipulating, one or more pertinent feedbacks regarding the task the user is performing, etc.
Schuster in view of Uram and in view of Kopper teaches the claimed limitations as discussed above per claim 16. Schuster further teaches:
Regarding claim 17, the training drug delivery device comprises at least one of the following: an injection mechanism, the dosage window for showing the selected dose, or a needle ([0030]; [0043]: e.g., the drug-delivery device—such as an autoinjector, already comprises one or more of: an injection mechanism, a dosage window, a needle, etc.);
Regarding claim 18, the at least one sensor is configured to measure: (i) a position of the training drug delivery device within an environment, (ii) an orientation of the training drug delivery device within the environment, (iii) a torque exerted on the dosage dial relative to the body, (iv) a force exerted on the injection mechanism relative to the body, (v) an attachment of the cap covering at least a part of the body, (vi) an attachment of the cap covering the needle, or (vii) an attachment of the needle to the training drug delivery device ([0036]; [0043] lines 1-19; [0160]: e.g. the system already implements one or more sensors; and thereby it detects or measures one or more actions with respect to the delivery device; such as: motion of the injector including picking it up or shaking it; verifying that the cap/cover is removed; verifying that the device is pressed against a desired site, etc. Accordingly, the above indicates the implementation of at least one sensor that measures the position of the training drug-delivery device within an environment, etc.);
Regarding claim 21, the at least one window-shaped region of the training drug delivery device comprises at least one of a drug window of the training drug delivery device or the dosage window of the training drug delivery device ([0030]: e.g., the device is already in the form of an autoinjector or an insulin pen; and therefore, it already includes one or more windows, including a dosage window);
Regarding claim 24, the set of haptic response parameters define a clicking or resistance of the dosage dial in response to being turned relative to the body of the training drug delivery device or a clicking or resistance of the injection mechanism in response to being pressed relative to the body of the training drug delivery device, the clicking or resistance of the dosage dial or the injection mechanism being provided by the haptic drive of the training drug delivery device ([0030]: e.g. turning the knob/dial on the delivery device already creates a series of discrete vibrations; and therefore, the user normally feels a resistance due to such vibrations as he/he is turning the dial to increase or decrease the dosage. Accordingly, the above indicates that the set of haptic response parameters define a resistance of the dosage dial in response to being turned relative to the body of the training drug-delivery device; and wherein such resistance is provided by the haptic drive of the training drug-delivery device);
Regarding claim 25, the training drug delivery device is configured to: detect, using the at least one sensor, a user's handling of the training drug delivery device based on one or more sensor indications comprising “(i) a position of the training drug delivery device within an environment . . . or (vi) an attachment of the needle to the training drug delivery device”; and transmit, using the wireless unit of the training drug delivery device to the user device, sensor indications corresponding to the user's handling of the training drug delivery device ([0030]; [0036]; [0043] lines 1-19; [0056]: e.g. the delivery device detects one or more actions of the user, such as (a) motion of the injector, including picking the injector up or shaking it, (b) turning the dosage knob/dial on the delivery device, (c) removing the cap/cover on the delivery device, etc., and thereby the system wirelessly transmits the information that indicates whether the device is being operated properly or not);
Regarding claim 26, the user device is configured to indicate, in response to receiving the sensor indications, to the user whether the user's handling of the training drug delivery device is correct ([0034]; [0036] lines 10-19: e.g. based on the analysis of signals received from the sensor(s), the system already provides one or more feedbacks to the user—such as, informing the user that he/she is properly—or improperly—operating the device, including additional information on the use of the device, etc.);
Regarding claim 27, detect, using the at least one sensor, a user’s handling of the training drug delivery device based on one or more sensor indications comprising (i) the torque exerted on the dosage dial relative to the body of the training drug delivery device or (ii) the force exerted on the injection mechanism relative to the body of the training drug delivery device; and transmit, using the wireless unit of the training drug delivery device to the user device, sensor indications corresponding to the user's handling of the training drug delivery device ([0030]; [0036]; [0043] lines 1-19; [0056]: e.g. as already indicated above per claim 25, the delivery device detects one or more actions of the user, including turning the dosage knob/dial on the delivery device. Accordingly, at least one sensor is utilized to detect the torque exerted on the dosage dial relative to the body of the training drug-delivery device, etc. and thereby the system wirelessly transmits the information that indicates whether the device is being operated properly or not);
Regarding claim 28, detecting the user's handling of the training drug delivery device comprises detecting, using the at least one sensor, at least one of (i) the attachment of the cap of the training drug delivery device covering at least a part of the body of the training drug delivery device, (ii) the attachment of the cap covering a needle of the training drug delivery device, or (iii) the attachment of the needle to the training drug delivery device ([0030]; [0036] lines 1-10; [0043] lines 1-19: e.g. it is already indicated above per claim 25 above that the delivery device detects one or more actions of the user, including removing the cap/cover on the delivery device, etc. Accordingly, at least one sensor is utilized to detect the attachment of the cap of the training drug-delivery device covering at least a part of the body of the training drug-delivery device);
Regarding claim 29, wherein the training drug delivery device comprises a container configured to be filled with a liquid ([0026] lines 1-5; [0030]; [0043] lines 1-5; [0332]: e.g. the delivery device, such as an autoinjector, already involves a container, which can be a replicable container; and wherein the container is filled with a liquid);
Regarding claim 30, the training drug delivery device is configured to receive a drug cartridge ([0332]; [0351] e.g., the drug-delivery device already implements a compartment for positioning a drug container or cartridge);
Regarding claim 32, wherein the haptic response of the training drug delivery device is determined based on the set of haptic response parameters received from the user device ([0056] lines 1-15; [0060] lines 1-18: [0061] lines 1-14: e.g. the smartphone corresponds to the user device; and thus, calibration parameters, including vibration data that denote one or more operational states of the delivery device, are downloaded using the smartphone in order to store reference vibration parameters in the monitor of the delivery device; and thereby the monitor in the delivery device is programmed accordingly, so that the delivery device generates one or more vibrations based on detected actions of the user. The above indicates that the haptic response—such as the vibrations—of the training drug-delivery device is based on parameters of the haptic response received from the user device).
Regarding claim 34, Schuster teaches the following claimed limitations: a training drug delivery device comprising: a body, a cap, a dosage dial, a delivery activation button ([0026] lines 1-9; [0030]; [0033] lines 1-16; [0043] lines 1-12; also [0159]: e.g. a system comprising a drug-delivery device, such as one or more injectors; and the injector comprises various components, including: (i) a body—such as a housing, (ii) a cap or a cover since the system detects the removal of a cap/cover from the delivery device, (iii) a dial or a knob for setting the desired dose, (iv) a delivery activation button since the system also senses the press of a button—or the triggering of the injector—on the device. Note that the drug-delivery device above is also construed as a training drug-delivery device since it provides feedbacks or training to the user, see [0043] lines 19-27), a controller, a memory, a wireless unit for communicating with a user device ([0050] lines 1-9; [0054]; [0056]: e.g., the monitor, which includes a circuit board, can be incorporated into the delivery device during manufacture; and wherein the monitor stores calibration parameters and algorithms for analyzing data. The above demonstrates that the delivery device already incorporates a memory and a controller—such as, a processor. The monitor also incorporates a wireless communication unit that allows it to transmit data to a user device—such as a smartphone, a tablet computer and/or Google Glass), a haptic [unit] for simulating haptic a response of a real drug delivery device [during] user operation ([0030]: e.g. the delivery device generates one or more vibrations based on the dose of the medication that the user is attempting to administer; and this indicates the implementation of a haptic unit that simulates haptic a response of a real drug-delivery device during user operation), and at least one sensor for measuring (i) an attachment of the cap to the body and (ii) a depression of the delivery activation button relative to the body ([0043] lines 5-12; [0033] lines 1-16: e.g. the monitor already senses or detects various actions, including (i) the removal of a cap/cover, (ii) the press of a button or the triggering of the injector, etc. Accordingly, the above indicates that at least one sensor is utilized to measure an attachment of the cap to the body, a depression of the delivery activation button relative to the body); and at least one window-shaped region defined on the body, the window-shaped region comprises a dosage window ([0030]; [0043] lines 1-12: e.g., note that the drug-delivery device—such as an autoinjector or insulin pen—normally includes a dosage window; and thus, the drug-delivery device already incorporates at least one window-shaped region defined on the body of the drug-delivery device, and wherein the window-shaped region comprises a dosage window); the training drug-delivery device being configured to (i) connect, using the wireless unit, to the user device, (iii) receive a set of haptic response parameters from the user device, the set of haptic response parameters comprising at least parameters defining simulated haptic responses ([0054]; [0056] lines 1-15; [0060] lines 1-18; [0061] lines 1-14: e.g. calibration parameters, including vibration data that denote one or more operational states of the delivery device, are downloaded using the smartphone; and thereby, reference vibration parameters are stored into the monitor of the drug-delivery device. Accordingly, the monitor uses these reference parameters in order to determine—during the usage of the drug-delivery device—is an event has occurred. The above indicates that the smartphone, which is the user device, transmits a set of haptic response parameters to the training drug-delivery device, wherein the set of haptic response parameters comprising at least parameters defining simulated haptic responses), (ii) transmit sensor indications of the at least one sensor to the user device, and cause information to be displayed using augmented reality provided by the user device, the information based at least partly on the sensor indications; and the information representing user feedback on handling the training drug-delivery device ([0056]; [0318]: e.g. the computing device—such as the smartphone and/or Google Glass—already implements a wireless communication with the drug-delivery device; and thereby it receives the sensor data transmitted from the drug-delivery device in order to further analyze and/or display the data; such as training, warnings or alerts, etc. In addition, the process of presenting information using Google Glass already indicates the process of displaying information to be using augmented reality. Accordingly, the system already presents information based at least partly on the sensor indications. Thus, the information represents user feedback on using the training drug-delivery device. Note that the content/topic of the feedback, such as, feedback on handling the training drug-delivery device, is merely nonfunctional descriptive matter).
Schuster does not teach a haptic drive powered and actively driven by the controller of the training drug-delivery device to generate simulated haptic responses that simulate actual haptic responses of several different real drug-delivery devices under user operation; and the set of haptic response parameters comprises at least parameters defining simulated haptic responses, which the haptic drive generates in response to detecting user operation of the dosage dial and the delivery activation button of the drug-delivery device.
However, Uram teaches an injection delivering system that comprises various components, including a drug-delivery device and a computer; the drug-delivery device incorporates an interface that is linked to its motor, so that the motor operates based on parameters received from the computer; and accordingly, the computer system transmits—to the drug-delivery device—one or more parameters that configure the operation of the drug-delivery device (e.g., parameters that configure the operation of the motor of the drug-delivery device) according to the injection procedure ([0043]; [0046] to [0048]). For instance, the user identifies, via a drop-down menu displayed on the computer, the type of injection to be performed; and wherein, based on the information received from the user, the computer determines one or more injection parameters and transmits the parameters to the drug-delivery device; and thereby, the drug-delivery device operates according to the received parameters ([0055] lines 1-8; [0058]; [0059]).
Note that (a) the motor above corresponds to the haptic drive, which is actively driven by the interface (i.e., the controller), in order to generate simulated haptic responses of several real drug-delivery devices when the user is using/operating the delivery-device; and (b) the parameters that configure the operation of the motor of the drug-delivery device (e.g., causing the motor to run at one or more speeds based on the type of injection procedure the user has selected, etc.) correspond to the set of haptic responses parameters, which define the simulated haptic responses that the haptic drive generates when detecting the use operation.
Furthermore, Schuster already teaches that the system is also used for training the user regarding the proper use/operation of the drug-delivery device—such as, coaching the user regarding the proper use of the device ([0034]); and based on sensor data detected as the user is operating the drug-delivery device (e.g., detecting one or more of: motion/shaking of the injector, setting of a dose, duration of vibration of motor, etc.), the system determines whether the user is properly or improperly operating the device; and thereby, the system presents the user with relevant training materials in order to train the user regarding the proper use/operation of the drug-delivery device ([0043]).
Accordingly, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Schuster in view of Uram; for example, by expanding the patient training mode—such as, incorporating at least one haptic drive—such as a motor—along with an interface that allows the haptic drive to receive one or more commands from the processor of the drug-delivery device and/or the user’s device; and the system’s algorithm is also upgraded so that the user’s device—such as the smartphone—provides the user with an option to select the type of instrument or injection procedure (e.g., injection using an autoinjector, injection using a needle-free injector, etc.); and wherein, based on the selection that the user is making, the smartphone transmits—to the drug-delivery device—relevant parameters that configure one or more components of the drug-delivery device (e.g., the activation button, the dosage knob, the electric motor, etc.) to operate according to the user’s selection (e.g., when the user selects an auto injection procedure, the smartphone transmits parameters that configure the motor of the drug-delivery device to operate at one or more speeds relevant to an autoinjector; and this causes the drug-delivery device to vibrate as an autoinjector, etc.); and furthermore, based on data detected regarding the user’s manipulation of the drug-delivery device, the smartphone provides relevant audio and/or visual information to the user (e.g., how to properly use an autoinjector if the user is incorrectly manipulating the drug-delivery device, etc.); so that, the user would have a chance to easily learn the type of haptic responses that he/she should get during actual injection of a drug(s) using one or more drug-delivery devices.
Schuster also does not teach the process of projecting a projection generated by the user device onto the body of the drug-delivery device to overlay the at least one window-shaped region, wherein the projection comprises dose information of the training drug-delivery device.
However, Kopper discloses a system that allows a user to manipulate a medical instrument while wearing a wearable device; wherein the system tracks the position of the instrument with respect to the wearable device; and wherein the system projects information corresponding to at least a portion of the instrument; and thereby overlays the information on the portion of the instrument ([0067]; [0080]; [0081]).
It is also worth to noting that Schuster’s drug-delivery-device already includes a window region that comprises a dosage window since it is in the form of an autoinjector or an insulin pen (see [0030]).
Accordingly, given the above teaching, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Kopper; for example, by incorporating one or more tracking means that allows the system to easily track one or more positions and/or orientations of the delivery device with respect to the AR device (e.g., the Google Glass) that the user is wearing; and wherein the systems further projects and overlays, based on the position/orientation of the delivery device being tracked above, one or more pertinent visual elements (e.g., textual and/or graphic elements, etc.) on one or more corresponding portions of the delivery device (e.g., on the cap/cover region; on the window region—such as, the dosage window, etc.), so that the user would be able to easily acquire, based on the position and/or orientation of the delivery device that he/she is manipulating, one or more pertinent feedbacks regarding the task the user is performing, etc.
Regarding claim 35, Schuster teaches the following claimed limitations: a user device comprising: a controller, a memory, and a wireless unit ([0034]; [0056]: e.g. a user device—such as a smartphone, a tablet computer and/or Google Glass—already comprises a memory, a wireless unit and a processor, i.e. a controller); the user device being configured to: connect, using the wireless unit, to a training drug delivery device; receive sensor indications from the training drug delivery device (see [0043] lines 1-19]; [0056]: e.g. a drug-delivery device, such as an injector, implements a wireless unit; and it communicates with the smartphone; and the smartphone receives sensor data transmitted from the drug-delivery device, etc.); transmit a set of haptic response parameters defining simulated haptic responses to the training drug-delivery device ([0056] lines 1-15; [0060] lines 1-18; [0061] lines 1-14: e.g. calibration parameters, including vibration data that denote one or more operational states of the delivery device, are downloaded using the smartphone in order to store reference vibration parameters in the monitor of the delivery device; and thereby the monitor in the delivery device is programmed accordingly, so that the delivery device generates one or more vibrations based on detected actions of the user. The above indicates that the smartphone transmits, to the training drug-delivery device, a set of haptic response parameters that define simulated haptic responses); and provide, based at least partly on the received sensor indications, a user with feedback on handling the training drug delivery device using augmented reality by the user device ([0056]; [0318]: e.g. the user device—such as the smartphone—already analyzes sensor data transmitted from the drug-delivery device; and thereby, based on the sensor data, the smartphone provides the user with further feedback; such as training, warnings or alerts, etc. Moreover, the system already implements Google Glass for presenting such information; and this indicates that the system already uses at least an augmented reality to present the information. Note also that the content/topic of the feedback, such as, feedback on using the training drug-delivery device, is merely nonfunctional descriptive matter); and wherein, the training drug-delivery device comprises at least one window-shaped region (see [0030]; [0043] lines 1-12: e.g., note that the drug-delivery device—such as an autoinjector or insulin pen—normally includes a dosage window; and thus, the drug-delivery device already incorporates at least one window-shaped region).
Schuster does not teach that: user device receives a selection of the type of drug-delivery device that the user is training for; a haptic drive powered and actively driven by the controller of the training drug-delivery device to generate simulated haptic responses that simulate actual haptic responses of several different real drug-delivery devices under user operation; and the set of haptic response parameters comprises at least parameters defining simulated haptic responses, which the haptic drive generates in response to detecting user operation of the dosage dial and the delivery activation button of the drug-delivery device.
However, Uram teaches an injection delivering system that comprises various components, including a drug-delivery device and a computer; the drug-delivery device incorporates an interface that is linked to its motor, so that the motor operates based on parameters received from the computer; and accordingly, the computer system transmits—to the drug-delivery device—one or more parameters that configure the operation of the drug-delivery device (e.g., parameters that configure the operation of the motor of the drug-delivery device) according to the injection procedure ([0043]; [0046] to [0048]). For instance, the user identifies, via a drop-down menu displayed on the computer, the type of injection to be performed; and wherein, based on the information received from the user, the computer determines one or more injection parameters and transmits the parameters to the drug-delivery device; and thereby, the drug-delivery device operates according to the received parameters ([0055] lines 1-8; [0058]; [0059]).
Note that (a) the motor above corresponds to the haptic drive, which is actively driven by the interface (i.e., the controller), in order to generate simulated haptic responses of several real drug-delivery devices when the user is using/operating the delivery-device; and (b) the parameters that configure the operation of the motor of the drug-delivery device (e.g., causing the motor to run at one or more speeds based on the type of injection procedure the user has selected, etc.) correspond to the set of haptic responses parameters, which define the simulated haptic responses that the haptic drive generates when detecting the use operation.
It is further worth noting that Schuster already teaches that the system is also used for training the user regarding the proper use/operation of the drug-delivery device—such as, coaching the user regarding the proper use of the device ([0034]); wherein, based on sensor data detected as the user is operating the drug-delivery device (e.g., detecting one or more of : motion/shaking of the injector, setting of a dose, duration of vibration of motor, etc.), the system determines whether the user is properly or improperly operating the device; and thereby, the system presents the user with relevant training materials in order to train the user regarding the proper use/operation of the drug-delivery device ([0043]).
Accordingly, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify Schuster in view of Uram; for example, by expanding the patient training mode—such as, incorporating at least one haptic drive—such as a motor—along with an interface that allows the haptic drive to receive one or more commands from the processor of the drug-delivery device and/or the user’s device; and the system’s algorithm is also upgraded so that the user’s device—such as the smartphone—provides the user with an option to select the type of instrument or injection procedure (e.g., injection using an autoinjector, injection using a needle-free injector, etc.); and wherein, based on the selection that the user is making, the smartphone transmits—to the drug-delivery device—relevant parameters that configure one or more components of the drug-delivery device (e.g., the activation button, the dosage knob, the electric motor, etc.) to operate according to the user’s selection (e.g., when the user selects an auto injection procedure, the smartphone transmits parameters that configure the motor of the drug-delivery device to operate at one or more speeds relevant to an autoinjector; and this causes the drug-delivery device to vibrate as an autoinjector, etc.); and furthermore, based on data detected regarding the user’s manipulation of the drug-delivery device, the smartphone provides relevant audio and/or visual information to the user (e.g., how to properly use an autoinjector if the user is incorrectly manipulating the drug-delivery device, etc.); so that, the user would have a chance to easily learn the type of haptic responses that he/she should get during actual injection of a drug(s) using one or more drug-delivery devices.
Schuster also does not teach the process of projecting projection generated by the user device onto the body of the drug-delivery device to overlay the at least one window-shaped region, wherein the projection comprises dose information of the drug-delivery device.
However, Kopper discloses a system that allows a user to manipulate a medical instrument while wearing a wearable device; wherein the system tracks the position of the instrument with respect to the wearable device; and wherein the system projects information corresponding to at least a portion of the instrument; and thereby overlays the information on the portion of the instrument ([0067]; [0080]; [0081]).
It is also worth to noting that Schuster’s drug-delivery-device already includes a window region that comprises a dosage window since it is in the form of an autoinjector or an insulin pen (see [0030]).
Accordingly, given the above teaching, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Kopper; for example, by incorporating one or more tracking means that allows the system to easily track one or more positions and/or orientations of the delivery device with respect to the AR device (e.g., the Google Glass) that the user is wearing; and wherein the systems further projects and overlays, based on the position/orientation of the delivery device being tracked above, one or more pertinent visual elements (e.g., textual and/or graphic elements, etc.) on one or more corresponding portions of the delivery device (e.g., on the cap/cover region; on the window region—such as, the dosage window, etc.), so that the user would be able to easily acquire, based on the position and/or orientation of the delivery device that he/she is manipulating, one or more pertinent feedbacks regarding the task the user is performing, etc.
Regarding claim 37, Schuster in view of Uram and in view of Kopper teaches the claimed limitations as discussed above per claim 16.
Schuster already teaches that the drug-delivery device comprises at least one window-shaped region ([0030]: e.g., the device is already in the form of an autoinjector or an insulin pen; and therefore, it already includes one or more windows).
The limitation, “simulated content of a drug”, is merely describing the content (e.g., the textual and/or pictorial elements) being presented; and therefore, the above is merely nonfunctional descriptive matter.
Thus, the limitation, “the user device is configured to project simulated content of a drug onto the at least one window-shopped region of the training drug-delivery device”, is already addressed per the modification discussed with respect to claim 16.
Particularly, Schuster is modified based on the teaching gleaned from Kopper; for example, by incorporating one or more tracking means that allows the system to easily track one or more positions and/or orientations of the drug-delivery device with respect to the AR device (e.g., the Google Glass) that the user is wearing; and wherein the systems further projects and overlays, based on the tracked position/orientation of the drug-delivery device, one or more pertinent visual elements (e.g., textual and/or graphic elements, etc.) on one or more corresponding portions of the delivery device (e.g., on the cap/cover region; on the window region, etc.), so that the user would be able to easily acquire, based on the position and/or orientation of the delivery device that he/she is manipulating, one or more pertinent feedbacks regarding the task the user is performing, etc.
Accordingly, the modified system discussed per claim 16 already addresses claim 37.
● Claim 31 and 33 are rejected under 35 U.S.C.103 as being unpatentable over Schuster 2016/0129182 in view of Uram 2014/0336615, Kopper 2020/0188030 and Baker 2015/0379899.
Regarding claim 31, Schuster in view of Uram and Kopper teaches the claimed limitations as discussed above per claim 16.
Schuster does not teach that the system further comprises a training pad for simulating a user's skin.
However, Baker teaches a system for training a user regarding a drug delivery device, such as an injector; and wherein the system also comprises a pad for simulating a human skin ([0017]; [0024]; [0039]; [0041]).
Accordingly, given the above teaching, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Baker; for example, by incorporating one or more additional components—such as a pad that simulates a human skin, etc., in order to provide the user with a further option to practice the injection process prior to injecting his/her skin; so that the user’s confidence to correctly self-administer medications using one or more drug-delivery devices (e.g. one or more injectors) is increased.
Regarding claim 33, Schuster in view of Kopper teaches the claimed limitations as discussed above per claim 16.
Although Schuster does not expressly describe that the delivery device further comprises a needle shield and a needle shield activation button, it is common to implement a needle shield in one or more type of injectors that Schuster is describing ([0043] lines 1-5).
Nevertheless, Baker teaches a system for training a user regarding a drug-delivery device, such as an injector ([0017]); wherein the injector comprises a needle shield; such as a needle shield that is activated when the user presses the injector downward after proper positioning of the injector ([0081]; [0086]: e.g., the shield moves as the result of the above action of the user; and therefore, the device already implements a drive that moves the shield); and wherein the system also comprises one or more buttons for controlling the operations of the delivery device ([0090]).
Accordingly, given the above teaching, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Baker; for example, by incorporating one or more additional components, including a needle shield that covers the needle of the injector; and wherein the needle shield is configured to be activated based on one or more conditions—such as, placing that shield portion in contact with the target area and pressing down with the correct amount of force until the needle is ejected (or optionally using a control button on the user interface), etc., so that accidental injury due to the needle is minimized since the needle shield covers the needle during normal handling of the injector.
● Claims 38 and 39 are rejected under 35 U.S.C.103 as being unpatentable over Schuster 2016/0129182 in view of Uram 2014/0336615, Kopper 2020/0188030 and Waller PCT/US2019/013017 (note: sections from the US publication, US 2020/0338276, are cited in this office-action for simplicity).
Regarding claim 38, Schuster in view of Uram and Kopper already teaches the limitation regarding the window-shaped region; such as, projecting the projection
generated by the user device onto the body to overlay the window-shaped region (see above the modification discussed with respect to claim 16).
Schuster, as modified above, does not teach the window-shaped region being a simulated window that comprises a neutral color.
However, Waller discloses an injector device that comprises one or more windows on its housing; and wherein the windows allow the user visual access to at least one color—such as, green color for indicating that the injector device is ready for use, and/or verify the unexpired content of the reservoir based on color ([0049], [0058]).
Accordingly, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to further modify the invention of Schuster in view of Waller; for example, by incorporating at least one color coded element visible through the window—such as a green color that indicates the ready status of the delivery device, etc., so that when the user is interacting with the device while wearing the Google Glass, the user would be able to easily recognize not only the state of the device, but also the superimposed information—textual/graphics—being presented to him/her ([0159]; [0318]).
Regarding claim 39, Schuster in view of Uram, Kopper and Waller teaches the claimed limitations as discussed per claim 38.
The limitation, “the neutral color comprises grey or green”, is already addressed per the modification discussed with respect to claim 38. Particularly, the color green is already being used as the neutral color.
Response to Arguments.
6. Applicant’s arguments have been fully considered (the arguments filed on 01/29/2026); however, the arguments are not persuasive at least for the following reasons:
Thus, while referring to the current amendment, Applicant asserts, “Applicant has amended independent claims 16, 34, and 35 to expedite prosecution. Applicant respectfully submits that Schuster, Uram, Kopper, Baker, and Waller, taken alone or in any combination, fail to teach or suggest, for example, (i) ‘a haptic drive that is powered and actively driven by the controller of the training drug delivery device . . . the training drug delivery device,’ as recited . . . Uram does not cure the above-noted deficiencies of Schuster . . . In Uram, the syringe motor 64 is only configured to inject a medicament according to an ‘injection protocol.’ Uram ⁋[0046]. Although an actual sound or noise might be passively generated from Uram's injector subsystem 60 during the injection process caused by the syringe motor 64, no evidence ensures that Dram's alleged ‘haptic response’ is produced by a ‘haptic drive that is powered and actively driven by the controller of the training drug delivery device,’ let alone the actively generated ‘simulated haptic responses’ are used to ‘simulate actual haptic responses of several different real drug delivery devices under user operation.’ . . . Uram does not teach or suggest ‘[a] user device being configured to ... transmit a set of haptic response parameters to the training drug delivery device . . . since Uram does not teach or suggest the claimed ‘haptic device’ for similar reasons discussed above, Uram cannot teach or suggest the claimed ‘haptic response parameters’ . . . Uram's alleged ‘haptic response parameters’ transmitted to Uram's control computer 24 merely relate to an injection protocol for operating the syringe motor . . . Uram's injection protocol cannot be read upon the claimed ‘set of haptic response parameters comprising at least parameters defining the simulated haptic responses generated by the haptic drive . . . Uram's alleged ‘haptic Responses’ are, again, passively generated—other than being simulated by a ‘haptic drive’ that is ‘powered and actively driven by a controller,’ . . . Uram accordingly does not teach or suggest the above-noted features” (emphasis added).
As an initial matter, Applicant’s arguments directed to Schuster are not relevant since the Office does not rely on Schuster to teach the newly added limitation; namely, a haptic drive that is powered and actively driven by the controller of the drug-delivery device, including the process of simulating the haptic responses of several drug-delivery devices. Instead, the Office relies on Uram to teach the above limitation.
Applicant’s arguments directed to Uram are also not persuasive since Applicant appears to fail to appreciate Uram’s teaching regarding the claimed haptic drive that is driven by the controller of the drug-delivery device. For instance, while attempting to dismiss Uram’s motor (FIG 4, label “64”) as a unit that “passively” generates sound or noise during injection, Applicant makes the conclusory assertion that “no evidence ensures that Uram's alleged ‘haptic response’ is produced by a ‘haptic drive that is powered and actively driven by the controller’ . . . [of the drug-delivery device]” (emphasis added). In contrast, even basic common sense dictates that Uram’s motor (i.e., FIG 4, label “64”) normally generates a vibration, which the user feels (i.e., haptic responses) during the injection procedure. Accordingly, the motor does correspond to the haptic drive. Moreover, the operation of the motor, which is controlled based on commands that the control system (see FIG 4, label “40”) is providing to the motor via an interface (FIG 4, label “68”), is not merely “passive”; rather, it is an active one since the injection procedure cannot take place—or cannot be achieved—without the proper operation of the moor. Thus, Applicant’s attempt to simply disregard such critical feature as “passive” is also erroneous. In fact, per Applicant’s specification, the alleged “haptic drive” is itself a motor (“The drive 55 may be e.g. a motor . . .”; see page 9 of the speciation). This confirms that Uram’s teaching is not only consistent with the feature that the claims are reciting, but also consistent with the feature that the specification is describing.
Applicant also appears to fail to appreciate the teaching or suggestion, which Uram is providing regarding simulating the haptic responses of several drug-delivery devices. For instance, the injector control subsystem (see FIG 4, label “40”) already establishes electronic communication between a computer system (FIG 4, label “20”) and the injector subsystem (FIG 4, label “60”; also [0046] lines 1-10). In addition, the computer system allows the user to specify the type of injection to be performed; wherein the user uses a keyboard and/or a drop-down menu to specify the injection to be performed ([0058]; [0059]). Of course, once the user specifies the type of injection to be performed, the computer transmits— to the injector control system—one or more relevant parameters, namely one or more injection protocols, which are determined based on the type of injection that the user specified above. The parameters essentially
configure the motor of the injection device to operate in a particular manner; such as, modifying one or more of: the injection rate, the acceleration of the motor, the deceleration of the motor, etc. ([0046] lines 31-48; [0047]; [0048]).
Thus, it is quite evident—at least to PHOSITA—that Uram’s computer (i.e., the user device) not only allows the user to select the type of injection that the user is going to perform, but also transmits—to the injection system—relevant parameters, which configures the motor (i.e., the haptic drive) of the injector to operate according to the type of injection that the user has selected. For instance, when the user is selecting a first type of injection, the computer transmits a first set of parameters that configure the motor (the haptic drive) of the injector to generate a first haptic response during use; and similarly, when the user is selecting a second type of injection, the computer transmits a second set of parameters that configure the motor of the injector to generate a second haptic response, etc.
The observation above effectively invalidates Applicant’s assertions directed to Uram. In fact, it is also noted that Applicant fails to properly construe the teaching of Uram. For instance, unlike Applicant’s assertion, it is the control computer (see FIG 4, label “24”), which transmits the “injection protocol” (i.e., the set of haptic response parameters) to the injector control system (FIG 4, label “40”). In addition, despite admitting that “Uram's ‘haptic response parameters’ . . . relate to an injection protocol for operating the syringe motor 64 . . . Uram's injection protocol is described to include ‘average injection rate, the acceleration and deceleration profile for the injection . . .” (emphasis added), Applicant still fails to provide any rationale regarding why such “injection protocol” doesn’t suggest the claimed “set of haptic response parameters”;
and therefore, Applicant’s conclusory assertions directed to Uram are not even relevant to challenge—much less negate—the Office’s obviousness findings. Nevertheless, the Office’s analysis above already demonstrates why the injection protocol suggest the claimed “set of haptic response parameters” (see discussion above).
In addition, unlike Applica’s theory, Uram is not necessarily required to teach the implementation above as applied to a dosage dial and/or an activation button. This is because the exemplary drug-delivery device, per the teaching of Uram, is a syringe; and thus, one having even basic skills readily recognizes that a syringe does not normally incorporate, for example, a dosage dial or button. Accordingly, Applicant’s assertion regarding Uram’s lack of dosage dial and/or activation button is irrelevant since Applicant fails to consider the combined teaching of the references. In particular, the primary reference—namely, Schuster—already teaches various drug-delivery devices, including an insulin pen ([0030]; [0043]), which normally incorporates a dosage dial and a drug-delivery activation button.
Of course, besides such teaching regarding a plurality of drug-delivery devices, Schuster also teaches that (a) the drug-delivery device provides pertinent training to the user—such as, providing relevant feedback to the user, and/or how to properly use the drug-delivery device, etc. ([0043]); and furthermore, (b) the drug-delivery device receives—from an external device (e.g., a smartphone)—one or more parameters that define haptic responses—such as vibrations—that indicate an occurrence of an event during the operation of the drug-delivery device ([0056]; [0060]; [0061]).
Accordingly, given Schuster’s teaching above, along with Uram’s teaching regarding the process of configuring a drug-delivery device to provide a relevant haptic response (e.g., a relevant vibration) by transmitting—to the drug-delivery device—a specific “injection protocol” (i.e., a set of haptic response parameters), etc., PHOSITA would be readily motivated to modify Schuster’s system as discussed in the office action (e.g., see the discussion above regarding the combined teaching of Schuster and Uram, including the motivation for combining the two references). So far, except for the improper piecemeal analysis (i.e., attacking a single reference at a time), Applicant fails to even consider, much less challenge, the combined teaching of the references. Also see MPEP 2145(IV) (emphasis added),
One cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., Inc., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Where a rejection of a claim is based on two or more references, a reply that is limited to what a subset of the applied references teaches or fails to teach, or that fails to address the combined teaching of the applied references may be considered to be an argument that attacks the reference(s) individually. Where an applicant’s reply establishes that each of the applied references fails to teach a limitation and addresses the combined teachings and/or suggestions of the applied prior art, the reply as a whole does not attack the references individually as the phrase is used in Keller and reliance on Keller would not be appropriate. This is because "[T]he test for obviousness is what the combined teachings of the references would have suggested to [a PHOSITA]." In re Mouttet, 686 F.3d 1322, 1333, 103 USPQ2d 1219, 1226 (Fed. Cir. 2012).
Thus, at last for the reasons discussed above, the Office concludes that the current claims are still obvious over the prior art.
Conclusion
Applicant’s amendment necessitated the new grounds of rejection presented in this final office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filled within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRUK A GEBREMICHAEL whose telephone number is (571) 270-3079. The examiner can normally be reached from 7:00 AM - 3:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, PETER VASAT can be reached on (571) 270-7625. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BRUK A GEBREMICHAEL/Primary Examiner, Art Unit 3715
Prosecution Insights