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 .
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.
Claim Objections
Claims 1 and 11 are objected to because of the following informalities:
In claim 1, “a user” is cited 3 times. It is believed the second and third instance of “a user” in lines 3 and 8 is in error for “the user.”
In claim 11, “a user” is cited 3 times. It is believed the second and third instance of “a user” in lines 3-4 and 8 is in error for “the user.”
Appropriate correction is required.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-3 and 11, 19 and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dalforno (US 2017 /0185953).
Regarding claim 1, Dalforno teaches an ambulatory infusion pump system (Figs. 1 and 2), comprising: a pump mechanism configured to deliver insulin to a user (¶51, 206, Fig. 2, the processor can use CGM data to deliver insulin to a user via a pump); a communications interface configured to receive data indicative of glucose levels of a user from one or more continuous glucose monitoring (CGM) sensors (¶34, receivers 110-113 receive CGM data from 102 and 104 via a wireless communication interfaces); a memory configured to store characteristics for each of a plurality of types of CGM sensors (¶42, the server 130 may include, for a given patient having an account at secure server 130, the identity of the sensor assembly 101 including the type or version of the sensor 102; the identity of the transmitter 104 including the type or version of the transmitter 104; the identity of the receiver 112 including the type or software version of that receiver; and/or the identity of other devices or components which can be used with the continuous glucose monitoring system, ¶43, For example, the compatibility rules may indicate
for each type of receiver (for example, by receiver model, receiver version, software version of the receiver software, and/or the like), the types of transmitters (by transmitter model, transmitter version, software version of the transmitter software, and/or the like) that can operate properly with the corresponding receiver. Moreover, the compatibility rules may indicate for each type of transmitter, the types of sensors (by sensor model, sensor version, and/or the like) that can operate properly with the corresponding transmitter); at least one processor 206 configured to: receive an indication that a user will be using a type of sensor from the plurality of types of sensors (¶77-¶79, At 522, the server 130 may determine the types of sensors that can be used with the selected transmitter. For example, the secure server 130 may, given the transmitter
selection information obtained at 520, access a set of rules that map the selected transmitter to one or more compatible sensors. At 525, the server 130 may generate a user interface
view to enable presentation and/or selection of sensors, At 530, the server 130 may receive a selection of a sensor. For example, the patient's smartphone 112 including controlled ordering application 136D may present the UI view including the list of sensors generated at 525. A user
may then select one of the sensors being displayed. Figs. 7A-D, Figs, 8A-8D); access the stored characteristics in memory for the type of sensor (¶42, type or version of sensor is stored, ¶43, sensor model, sensor version is stored. In Fig. 1, transmitter 104 receive info from CGM 102 and sends info to receivers, such as 110-113.); and configure the system to interface with the type of sensor based on the stored characteristics (When user reorders a new sensor, as discussed, the system reestablishes communications with the new sensor to provide communications as shown in Fig. 1, by accessing the stored characteristics of the sensor. As discussed in ¶43, the types of sensors that are compatible with and can operate properly with each transmitter are stored in the system. ¶81, compatibility of sensors and transmitters and associated data is discussed in ¶81. Thus, Dalforno teaches a transmitter may be configured to interface with multiple different types of CGMs.).
Regarding claim 2, Dalforno teaches the invention as claimed and discussed above and Dalforno further teaches a user interface, and wherein the indication that the user will using the type of sensor is received through the user interface ((¶77-¶79, At 522, the server 130 may determine the types of sensors that can be used with the selected transmitter. For example, the secure server 130 may, given the transmitter selection information obtained at 520, access a set of rules that map the selected transmitter to one or more compatible sensors. At 525, the server 130 may generate a user interface view to enable presentation and/or selection of sensors, At 530, the server 130 may receive a selection of a sensor. For example, the patient's smartphone 112 including controlled ordering application 136D may present the UI view including the list of sensors generated at 525. A user may then select one of the sensors being displayed. Figs. 7A-D, Figs, 8A-8D).
Regarding claim 3, Dalforno teaches the invention as claimed and discussed above and Dalforno further teaches the at least one processor is further configured to display a menu on the user interface including the plurality of types of sensors and the indication is provided by the user selecting the type of sensor (¶77-¶79).
Regarding claim 11, Dalforno teaches an ambulatory infusion pump system (Figs. 1 and 2), comprising: a pump mechanism configured to deliver insulin to a user (¶51, 206, Fig. 2, the processor can use CGM data to deliver insulin to a user via a pump); a communications interface configured to receive data indicative of glucose levels of a user from one or more continuous glucose monitoring (CGM) sensors (¶34, receivers 110-113 receive CGM data from 102 and 104 via a wireless communication interfaces); a memory configured to store characteristics for each of a plurality of types of CGM sensors (¶42, the server 130 may include, for a given patient having an account at secure server 130, the identity of the sensor assembly 101 including the type or version of the sensor 102; the identity of the transmitter 104 including the type or version of the transmitter 104; the identity of the receiver 112 including the type or software version of that receiver; and/or the identity of other devices or components which can be used with the continuous glucose monitoring system, ¶43, For example, the compatibility rules may indicate
for each type of receiver (for example, by receiver model, receiver version, software version of the receiver software, and/or the like), the types of transmitters (by transmitter model, transmitter version, software version of the transmitter software, and/or the like) that can operate properly with the corresponding receiver. Moreover, the compatibility rules may indicate for each type of transmitter, the types of sensors (by sensor model, sensor version, and/or the like) that can operate properly with the corresponding transmitter); a user interface configured to display a menu screen enabling a user to select a type of CGM sensor from a list of the plurality of types of CGM sensors (¶77-¶79, At 522, the server 130 may determine the types of sensors that can be used with the selected transmitter. For example, the secure server 130 may, given the transmitter
selection information obtained at 520, access a set of rules that map the selected transmitter to one or more compatible sensors. At 525, the server 130 may generate a user interface
view to enable presentation and/or selection of sensors, At 530, the server 130 may receive a selection of a sensor. For example, the patient's smartphone 112 including controlled ordering application 136D may present the UI view including the list of sensors generated at 525. A user
may then select one of the sensors being displayed. Figs. 7A-D, Figs, 8A-8D); and at least one processor 206 configured to interface with the type of sensor based on the stored characteristics (When user reorders a new sensor, as discussed, the system reestablishes communications with the new sensor to provide communications as shown in Figs. 1 and 2, by accessing the stored characteristics of the sensor.).
Regarding claim 19, Dalforno teaches the invention as claimed and discussed above and Dalforno further teaches the user interface is part of an ambulatory infusion pump containing the pump mechanism (The interface can be output on many different receiver devices, such as 111-113. One example is 111, which is a dedicated medical device. A pump, which is discussed, is a dedicated medical device).
Regarding claim 20, Dalforno teaches the invention as claimed and discussed above and Dalforno further teaches the user interface is part of a remote control device (The interface can be output on many different receiver devices, such as 111-113. Each of the devices is a remote control device).
Claim Rejections - 35 USC § 103
Claims 4, 5, 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Dalforno (US 20170185953) in view of Alles (US 20240148971).
Regarding claims (4,5) and (12,13), Dalforno teaches the invention as discussed above for claims 1 and 11. Claims (4 and 5) depend from claim 1 and claims (12 and 13) depend from claim 11. As discussed above, Dalforno teaches the system is configured for different types of sensors to be used. Dalforno doesn’t teach the stored characteristics include an activation protocol required to activate each of the plurality of types of sensors for use with the system, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes activating the type of sensor according to the corresponding activation protocol and the at least one processor is further configured to provide instructions to the user to guide the user through one or more steps of the activation protocol.
Alles teaches a wearable ambulatory infusion pump system (200, Fig, 2) including a pump 204, a CGM 206 and a smartphone 200 similar to Dalforno. In Figs. 5-7, Alles teaches an activation protocol required to activate a sensors for use with the system and the at least one processor is further configured to provide instructions to the user to guide the user through one or more steps of the activation protocol.
The proposed modification to Dalforno is to provide an application protocol taught by Alles for each of the types of sensors taught by Dalforno so that each of sensors can be configured for use when they are replaced. As discussed above, Dalforno teaches a system configurable to operate with different types of sensors and storing characteristics for each of the types of sensors. Alles is being relied upon to teach the characteristics stored for each type of sensor include an activation protocol.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make the systems of Dalforno in claims 1 and 11 have the stored characteristics include an activation protocol required to activate each of the plurality of types of sensors for use with the system, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes activating the type of sensor according to the corresponding activation protocol and the at least one processor is further configured to provide instructions to the user to guide the user through one or more steps of the activation protocol, as taught by Alles, in order to allow a user of the system Dalforno to activate a new type of sensor after ordering a replacement.
Claims 6, 7, 8, 14, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Dalforno (US 2017/0185953) in view of Strickland (US 2012/0165614).
Regarding claims (6, 7, 8) and (14, 15, 16), Dalforno teaches the invention as discussed above for claims 1 and 11. Claims (6, 7 and 8) depend from claim 1 and claims (14, 15 and 16) depend from claim 11. As discussed above, Dalforno teaches the system is configured for different types of sensors to be used and hence, communication with different types of sensors. Dalforno doesn’t teach the stored characteristics include a communication protocol employed by each of the plurality of types of sensors to transmit data to the communications interface, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes configuring the communications interface to communicate with the type of sensor according to the corresponding communication protocol, the stored characteristics include a type of data transmitted by each of the plurality of types of sensors to the communications interface, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes processing the data based on the type of data transmitted by the type of sensor, the stored characteristics include one or more authentication protocols required by each of the plurality of types of sensors, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes implementing the one or more authentication protocols required by the type of sensor.
Strickland teaches a wearable ambulatory infusion pump system ( Fig, 2) including a pump 204, a CGM 200 and a handheld device 104 similar to Dalforno. Strickland teaches the devices can use different communication protocols including open protocols (¶25) and proprietary protocols (¶26). Strickland teaches different devices can communicate different types of data (Fig. 6 teaches the use of a standard communication extension with a first types of data and Fig. 7 teaches the use of a private extension that sends different types of data as compared to the standard extension. Figs. 6 and 7, show how each extension is implemented to allow proper communications of data). Strickland teaches the use of some functions, such as upgrading firmware on a device (¶66) require additional security verifications, which is discussed with respect to Fig. 8.
The proposed modification to Dalforno is to provide communication protocols, data types and authentication protocols for each of the types of sensors taught by Dalforno so that each of different types of sensors can be configured for use when they are replaced. As discussed above, Dalforno teaches a system configurable to operate with different types of sensors and storing characteristics for each of the types of sensors. Strickland is being relied upon to teach the characteristics stored for each type of sensor include communication protocols, authentication protocols and data types.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make the system Dalforno in claims 1 and 11 have the stored characteristics include a communication protocol employed by each of the plurality of types of sensors to transmit data to the communications interface, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes configuring the communications interface to communicate with the type of sensor according to the corresponding communication protocol, the stored characteristics include a type of data transmitted by each of the plurality of types of sensors to the communications interface, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes processing the data based on the type of data transmitted by the type of sensor, the stored characteristics include one or more authentication protocols required by each of the plurality of types of sensors, and wherein configuring the system to interface with the type of sensor based on the stored characteristics includes implementing the one or more authentication protocols required by the type of sensor, as taught by Strickland, in order to allow the sensors to operate properly in the system, i.e., establish communications, communicate sensor specific data and operate securely.
Claims 9, 10, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Dalforno (US 2017/0185953) in view of Mastrototaro (US 2007/0100222).
Regarding claims 9, 10, 17 and 18, Dalforno teaches the invention as discussed above for claims 1 and 11. Claim 9 and 10 depend from claim 1 and claims 17 and 18 depend from claim 11. As discussed above, Dalforno teaches the system is configured for different types of sensors to be used and hence, communication and operation of the system with different types of sensors. Dalforno doesn’t teach the stored characteristics include a warmup period required by each of the plurality type of sensors following insertion before the type of sensor can reliably transmit data, and wherein configuring the system to interface with the type of sensor includes coordinating communications with the type of sensor according to the warmup period and the stored characteristics include a time interval between communications of data indicative of a glucose level for each type of sensor, and wherein configuring the system to interface with the type of sensor includes coordinating communications with the type of sensor based on the time interval.
Mastrototaro teaches a system for monitoring glucose and delivering insulin (Fig. 1A-H, ¶70-¶73). In ¶73, it is taught the sensor may preferably be a real-time sensor. As used herein, the terms "real-time" and "real-time sensor" refer to a sensor that senses values substantially continuously over an extended period of time and makes such values available for use as the values are being sensed and collected rather than having to download substantially all the collected values at a later time for use. For example, a real-time blood glucose sensor might sense glucose values every 10 seconds over an extended period of 24 hours, and make the values available (e.g., processing, charting and displaying) every 5 minutes so that that users of an insulin pump have the flexibility to fine-tune and start or stop insulin delivery upon demand. Patients may thus use their pumps to make substantially immediate therapy adjustments based upon real-time continuous glucose readings displayed every 5 minutes and by viewing a graph with 24-hour glucose trends. Thus, it is important to know when the time interval for communications of data to know when data can be output to a user. In ¶111, it is taught It is possible that a sensor will need to receive regulated power for a defined duration before it can generate a stable signal, in other words it must warm up. And, if regulated power is removed from the sensor, the sensor must warm up again when the power is restored before measurements can be used. Alternatively, it is possible that each time the sensor is warmed up, new reference measurements must be input and paired with a processed sensor signal to create new reference values, which are stored in the reference memory. Reference values are needed to calibrate the processed sensor signal into sensor measurements. Furthermore, periodic reference values may be needed, and if a stable (warmed up) processed sensor signal is not available when a new reference values is needed, then a new reference measurement may have to be collected when the processed sensor signal is available and stable. In the mean time the processed sensor signal cannot be used to generate a sensor measurement. Thus, the warm up characteristics are needed to use the sensor properly in the system.
The proposed modification to Dalforno is to provide time interval and warm up data for each of the types of sensors taught by Dalforno so that each of different types of sensors can be configured for use when they are replaced. As discussed above, Dalforno teaches a system configurable to operate with different types of sensors and storing characteristics for each of the types of sensors. Mastrototaro is being relied upon to teach the characteristics stored for each type of sensor include warm up data and time interval data because this data is needed to properly use a particular sensor in the system.
With respect to claims 9 and 17, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make the system of Dalforno of claims 1 and 11 have a warmup period required by each of the plurality type of sensors following insertion before the type of sensor can reliably transmit data, and wherein configuring the system to interface with the type of sensor includes coordinating communications with the type of sensor according to the warmup period, as taught by Mastrototaro, in order to know when the data from the sensor can be reliably used.
With respect to claims 10 and 18, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to make the system of Dalforno of claims 1 and 11 have the stored characteristics include a time interval between communications of data indicative of a glucose level for each type of sensor, and wherein configuring the system to interface with the type of sensor includes coordinating communications with the type of sensor based on the time interval., as taught by Mastrototaro, in order to properly utilize and output the data from the sensor.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAVID OLYNICK whose telephone number is (571)272-2355. The examiner can normally be reached M-F: 7:30 am-5 pm (ET).
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, Phuttiwat Wongwian can be reached at (571) 270-5426. 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.
/DAVID P. OLYNICK/ Primary Examiner, Art Unit 3741