DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/09/2026 has been entered.
Claims 1-3, 5-7, 13-15 and 17-20 remain pending in this application.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-3, 5-7, 13-15 and 17-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1:
Claims 1-3, 5-7 are drawn to a non-transitory medium which is within the four statutory categories (i.e. manufacture). Claims 13-15, 17-20 are drawn to a system which is within the four statutory categories (i.e. machine).
Step 2A, Prong 1:
Claims 1 and 13 have been amended to recite and provided below with markings separating abstract elements from the additional limitations, wherein the bolded style represent the additional limitations beyond abstract idea, and remaining limitations are directed to the abstract idea as discussed below:
“output a request to one or more devices for application data, wherein the request includes access information specific to one or more user application;
receive the application data from the one or more devices via the one or more applications;
identify diabetes-related alarms and/or notifications of a diabetes treatment program that correspond to periods of time or one or more events from the application data;
communicate with a blood glucose sensor to obtain blood glucose data;
identify a condition for generating diabetes-related alarms and/or notifications based on the obtained glucose data;
switch alarm and/or notification parameters of a personal diabetes management device related to the identified diabetes-related alarms and/or notifications of the diabetes treatment program from a first state to a second state according to the user application data;
command the personal diabetes management device to execute the alarms and/or notifications related to the diabetes treatment program according to the second state for the duration of the periods of time of the one or more events based on the identified condition”
Claims 1 and 13 are specifically directed to the abstract idea (See limitations not bolded above) of “certain methods of organizing human activities”, based on managing personal behavior and interactions between people (such as user following rules and instructions) regarding identifying and switching diabetes-related alarm and/or notification parameters according to the user application data.
After considering all claim elements, both individually and in combination and in ordered combination, it has been determined that the claims do not amount to significantly more than the abstract idea itself.
The dependent claims also correspond to certain methods of organizing human activity (user following rules and instructions), such as claims 2 and 14 recite “when generating the request for application data, access user preference settings; in the user preference settings, identify a preset time to generate the request for application data; and generate the request for the application data at the pre-set time”, claim 6 recites “identify a condition that requires generation of an alarm; access the adjusted alarm and/or notification parameters; determine based on the adjusted alarm and/or notification parameters a form of the alarm to be generated in response to the identified condition”, claim 19 recites “receive location data as part of the application data, wherein the location data includes a location name; and in response to a change in location data, modify the adjusted alarm and/or notification parameters related to the identified diabetes-related alarms and notifications of the diabetes treatment program”, claim 20 recites “receive, from the paired device, user preferences related to the alarm and notification parameters; and adjust the alarm and/or notification parameters based on the received user preferences”. These limitations correspond to managing personal behavior and interactions between people (such as user following rules and instructions) regarding identifying and switching diabetes-related alarm and/or notification parameters according to user application data with recitations of generic computing devices (such as a blood glucose device and a paired (smart) device.
The mere nominal recitation of a generic processor, blood glucose sensor device and paired smart device does not take the claims out of the methods of organizing human interactions grouping. The current specification recites “FIG. 1 illustrates an example of a device operable to provide the example processes and techniques described herein. The device 110 may be personal diabetes management device that may have a processor 116, a memory 118, a wireless communication interface 112, and a user interface device 114. Of course, the device 110 may be another device such as a wearable drug delivery device, a wearable blood glucose sensor, or other devices, such as accessory devices, that assist with management of a diabetes treatment plan. For ease of discussion, the device 110 may be referred to as a personal diabetes management (PDM) device.” in [0012], and “In an example, the processor 116 may be operable to establish a connection with one or more of the smart device 173, the laptop 175, or the wearable fitness device 177 via the wireless communication interface 112. A smart device 173 may be a smartphone, a smart wearable device, a smart digital assistant device, or the like….” in [0016]. Therefore, the devices recited in the current claims are directed to generic computing devices.
Claims recite “output a request and receive user agenda information from one or more devices…”, and the current specification recites “In an example, the processor 116 may be operable to establish a connection with one or more of the smart device 173, the laptop 175, or the wearable fitness device 177 via the wireless communication interface 112. A smart device 173 may be a smartphone, a smart wearable device, a smart digital assistant device, or the like. For example, the wireless communication interface 112 may be a Bluetooth® transceiver, or a transceiver operable according to IEEE 802.11 family of communication protocols and may be operable to establish, under control of the processor 116, a wireless communication link 188 with a paired, receiving device, such as the smart device 173, the laptop 175, or the wearable fitness device 177. For example, an artificial pancreas application 120, via the processor, may request via the wireless communication interface 112 a pairing with a receiving device. The pairing request may include an authentication code that indicates to the receiving device, such as 173, 175 or 177, that the request is from a verified device (i.e., the PDM 110). In response to the pairing request, a wireless communication link 188 may be established with the receiving device 173, 175 or 177, which is now a paired device, for receipt of user agenda information.” in [0016]. Therefore, the one or more devices correspond to generic computing devices that perform generic computing functions, such as receiving and outputting information.
Claims 2-3, 5-7, 14-15 and 17-20 are ultimately dependent from claims 1, 13 and include all the limitations of claims 1, 13. Therefore, claims 32- recite the same abstract idea. Claims 2-3, 5-7, 14-15 and 17-20 describe a further limitation regarding the basis for identifying and adjusting diabetes-related alarms and/or notifications. These are all just further describing the abstract idea recited in claims 1, 13, without adding significantly more.
Thus, claims recite an abstract idea.
Step 2A, Prong 2:
This judicial exception is not integrated into a practical application. In particular, claims recite the additional elements of “a processor; a memory coupled to the processor and operable to store programming code, an artificial pancreas application and data; a wireless communication interface operable to wirelessly communicate with a paired device and communicatively coupled to the processor;”, “using processor to perform the identifying, adjusting and executing steps”, “communicate with a blood glucose sensor to obtain blood glucose data” and “command the personal diabetes management device to execute the alarms and/or notifications related to the diabetes treatment program according to the second state for the duration of periods of time of the one or more events based on the identified condition” within claims 1, 13 and the following within the dependent claims: “populate the request with an authentication code that indicates to the paired device that the request for application data is from a verified device” (claims 3 and 15), “format the form of the notification as synthesized speech for output as a spoken notification” (claims 5 and 17), “format the form of the alarm as synthesized speech for output as a spoken alarm” (claim 7), “populate the request with indicators from the user preference settings of computer applications executing on the paired device that have agenda information included in the user agenda information” (claim 14), “request a pairing via the wireless communication interface with a receiving device, the request including an authentication code that indicates to the receiving device that the request is from a verified device; and establish a wireless communication link with the receiving device for receipt of application data” (claim 15), “a speaker communicatively coupled to the processor, wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to: format the outputted notification or the outputted alarm as synthesized speech; and forward the synthesized speech to the speaker” (claim 17) are hardware and software elements, these limitations are not enough to qualify as “practical application” being recited in the claims along with the abstract idea since these elements are merely invoked as a tool to apply instructions of the abstract idea in a particular technological environment, and mere instructions to apply/execute/automate an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular field or technological environment do not provide practical application for an abstract idea (MPEP 2106.05(f) & (h)).
Claims recite the additional elements of “output a request to one or more devices for application data, …; receive the application data from the one or more devices via the one or more applications;…”, and one or more devices are directed to hardware elements (generic computing devices) and “receiving the application data from the one or more devices via the one or more applications” corresponds to mere instructions to apply/execute/automate an abstract idea in a particular technological environment. Therefore, these additional elements do not provide practical application for an abstract idea.
Claims also recite another additional limitation beyond abstract idea, including a function such as outputting alarms/notifications is an insignificant extra-solution activity (see MPEP 2106.05 (g)), which does not provide a practical application for the abstract idea.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a processor to perform outputting a request, receiving application data, communicating with a blood glucose sensor to obtain blood glucose data, identifying a treatment program, identifying a condition for generating diabetes related alarms and/or notifications based on the obtained blood glucose data, switching alarm/notification parameters, commanding the diabetes management device to execute the alarms and/or notifications…, steps amounts to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept.
The claims are not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claims 1-3, 5-7, 13-15 and 17-10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Mayou et al. (hereinafter Mayou) (US 9940846 B2).
Claim 1 has been amended now to recite a non-transitory computer readable medium embodied with programming code executable by a processor, and the processor when executing the programming code is operable to perform functions, including functions to:
output a request to one or more devices for application data, wherein the request includes access information specific to one or more user applications (Mayou teaches “…The system includes an input receiver configured to receive at least one of context information, behavior information, or physiological information for a user over a period of time…” in col. 5, lines 20-30, “…Context information can include daily routine information (may change especially from weekdays to weekends) from calendaring application…” in col. 25, lines 22-38, “…The systems and methods may also obtain information from personal calendar or social media sites the person is associated with…” in col. 39, lines 36-38);
receive the application data from the one or more devices via the one or more applications (Mayou teaches “…contextual and or behavioral inputs are captured…” in col. 25, lines 1-21, “…Context information can include daily routine information…from calendaring application…” in col. 25, lines 22-38, “…The systems and methods may also obtain information from personal calendar or social media sites the person is associated with…” in col. 39, lines 36-38);
identify diabetes-related alarms and/or notifications of a diabetes treatment program that correspond to periods of time of one or more events from the application data (Mayou teaches “…determining behavior or contextual information (204); comparing the behavior or contextual information with a goal or criteria (206); adjusting the reporting format based on the comparison (208) and providing a report in the adjusted format …” in col. 11, lines 21-34, “…the inputs are processed to determine behavioral and/or contextual information about the patient…” in col. 27, lines 13-35 and “A user inputs data into their personal calendar which is registered to communicate the calendar data to the monitoring device. Upon analyzing the calendar data via, for example, key word searching, the system identifies that the user's upcoming events includes exercise, such as a planned yoga class. The monitoring system may see this class recurring weekly. Accordingly, the monitoring system may adapt to the exercise patterns and make recommendations such as, “Would you like to start your temp basal rate now if you plan on exercising in 1 hour?” one hour prior to the scheduled class. As another recommendation, the system may present the user a message such as, “Consider eating a snack now if you are going to exercise in 1 hour.” The message may be selected based on previous exercise patterns from similar activities. In some implementations, the input information may be obtained from social media calendars or events planning systems, such as Facebook™ events or Evite™ invitations.” in col. 28, lines 29-47);
communicate with a blood glucose sensor to obtain blood glucose data (Mayou discloses “…an electronic device for monitoring a glucose concentration in a host is provided. The device includes a continuous glucose sensor, wherein the continuous glucose sensor is configured to substantially continuously measure a glucose concentration in the host, 5 and to provide continuous sensor data associated with the glucose concentration in the host …” in col. 5, lines 1-7);
identify a condition for generating diabetes-related alarms and/or notifications based on the obtained blood glucose data (Mayou discloses “The sensor electronics module 12 may, as noted, couple ( e . g . , wirelessly and the like ) with one or more devices , such as any or all of display devices 14 , 16 , 18 , and 20 . The display devices 14 , 16 , 18 , and / or 20 may be configured for 20 processing and presenting information , such sensor information transmitted by the sensor electronics module 12 for display at the display device . The display devices 14 , 16 , 18 , and 20 can also trigger alarms based on the analyte sensor data .” in col. 9, lines 17-25);
switch alarm and/or notification parameters of a personal diabetes management device related to the identified diabetes-related alarms and/or notifications of the diabetes treatment program from a first state to a second state according to the application data (Mayou teaches “…a method of adjusting an interface format / style ( e . g . , graph , display of sensor data , buttons , alarms , default screens , and preferences for inter action ) of physiological information based on behavioral and / or contextual information.” in col. 10, lines 50-54, “…behavioral and/or contextual information about the user/patient is determined… the system may determine the patient is in a certain social situation such as in a work meeting or out to dinner with friends based on GPS and/or calendar information. As yet another example, the system may determine the patient is exercising or driving via input from an accelerometer, calendar, and/or GPS). In each of these examples, the context and behavior can be associated with the physiological information without actually requiring the user to input the determined information.” in col. 13, lines 25-26, 39-47, and “…Environmental adjustments may also be provided such as if the user is determined to be outside most of the time (context) a brighter contrast may be used for a trend screen display. Other adjustments can include providing higher level of discretion (adjustment) when detecting the location a work meeting (context), providing a basic, high-level report to a user determined to be overwhelmed with data or to a newly diagnosed user…: in col. 17, lines 19-27, and col. 17, lines 30-35); and
command the personal diabetes management device to execute the alarms and/or notifications related to the diabetes treatment program according to the a second state for the duration of the periods of time of the one or more events based on the identified condition (Mayou discloses “FIG. 5 is a process flow diagram of a method of determining goals or criteria for use in one or more aspects described. The process adaptive goal setting process 500 shown in FIG. 5 may be implemented in whole or in part using a continuous monitoring system such as the devices shown and described in FIG. 1. The adaptive goal setting process 500 may be implemented as a server process in data communication with a continuous monitoring device. The adaptive goal setting process 500 may be implemented in hardware such as via a field programmable gate array or application specific integrated circuit or a microcontroller specifically configured to implement one or more aspect of the adaptive goal setting process 500 described. The goals or criteria determined by the adaptive goal setting process 500 can be provided for use in one or more of the processes described such as block 206 of the adaptive reporting process 200 and/or block 602 of the adaptive guidance process 600.” In col. 29, lines 22-39).
Claim 2 has been amended to recite the non-transitory computer readable medium of claim 1, further embodied with programming code executable by a processor, and the processor when executing the programming code is further operable to perform functions, including functions to:
when generating the request for application data, access user preference settings (Mayou teaches “…At block 402, contextual and or behavioral inputs are captured…. Context information can include daily routine information (may change especially from weekdays to weekends) from calendaring application…” in col. 25, lines 1-43);
in the user preference settings, identify a preset time to generate the request for application data; and generate the request for the user agenda information at the pre-set time (Mayou teaches “…A user inputs data into their personal calendar which is registered to communicate the calendar data to the monitoring device. Upon analyzing the calendar data via, for example, key word searching, the system identifies that the user's upcoming events…” in col. 28, lines 28-32, “…The adjustments may provide a set of 30 adaptations that are continuously applied ( once adjusted , until the next adjustment ) and / or that are applied depending on the behavior or context identified at any particular time ( a profile of adjustments that depend on real - time context / behavior )..” in col. 17, lines 30-35, “…The reporting may be adapted to provide an initial loud alarm during evening hours and progressively increase volume over a period of time..” in col. 17, lines 51-53).
Claim 3 has been amended to recite the non-transitory computer readable medium of claim 1, further embodied with programming code executable by a processor, and the processor when executing the programming code is further operable to perform functions, including functions to:
populate the request with an authentication code that indicates to the one or more devices that the request for application data is from a verified device (Mayou; col. 39, lines 36-42).
Claim 5 recites the non-transitory computer readable medium of claim 1, further embodied with programming code executable by a processor, and the processor when executing the programming code is further operable to perform functions, including functions to: format the form of the notification as synthesized speech for output as a spoken notification (Mayou; col. 15, lines 58-65 and col. 16, lines 60-64).
Claim 6 recites the non-transitory computer readable medium of claim 1, further embodied with programming code executable by a processor, and the processor when executing the programming code is further operable to perform functions, including functions to:
identify a condition that requires generation of an alarm (Mayou teaches “Analysis of the specific characteristics of the patient’s condition can be useful in identifying other trends or anomalies with the specific patient…” in col. 18, lines 5-9);
access the adjusted alarm and/or notification parameters (Mayou teaches “…the monitoring device may be configured to connect with a pre-determined set of devices,…” in col. 14, line 61 to col. 15, line 15);
determine based on the adjusted alarm and/or notification parameters a form of the alarm to be generated in response to the identified condition (Mayou teaches “Organizing the adapted reporting may include identifying a hierarchy of reporting beginning with basic reporting and escalating to a more critical/complex report…” in col. 17, lines 43-58); and
output the generated alarm based on the determined form of the alarm (Mayou; col. 17, lines 43-58).
Claim 7 recites the non-transitory computer readable medium of claim 6, further embodied with programming code executable by a processor, and the processor when executing the programming code is further operable to perform functions, including functions to: format the form of the alarm as synthesized speech for output as a spoken alarm (Mayou; col. 16, lines 26-29).
As per claim 13, the amendments to system claim 13 reflect the same changes made to medium claim 1, and is therefore rejected for the same reasons given above for medium claim 1 in addition to the reasons given in the prior Office Action.
Claim 14 recites the device of claim 13, wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to:
in response to a generate request user preference setting, identify a preset time to generate the request for user agenda information (Mayou; “…A user inputs data into their personal calendar which is registered to communicate the calendar data to the monitoring device. Upon analyzing the calendar data via, for example, key word searching, the system identifies that the user's upcoming events…” in col. 28, lines 28-32); and
populate the request with indicators from the user preference settings of computer applications executing on the paired device that have agenda information included in the user agenda information (Mayou; col. 25, lines 22-30 and col. 28, lines 16-47 and “…A user inputs data into their personal calendar which is registered to communicate the calendar data to the monitoring device. Upon analyzing the calendar data via, for example, key word searching, the system identifies that the user's upcoming events…” in col. 28, lines 28-32).
Claim 15 has been amended to recite the device of claim 13, wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to:
request a pairing via the wireless communication interface with a receiving device, the request including an authentication code that indicates to the receiving device that the request is from a verified device (Mayou; col. 39, lines 36-42); and
establish a wireless communication link with the receiving device for receipt of application data (Mayou; col. 39, lines 36-42).
Claim 17 recites the device of claim 13, further comprising:
a speaker communicatively coupled to the processor (Mayou; col. 15, lines 58-65 and col. 16, lines 60-64),
wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to:
format the outputted notification or the outputted alarm as synthesized speech (Mayou; col. 16, lines 26-29); and
forward the synthesized speech to the speaker (Mayou; col. 16, lines 26-29).
Claim 18 has been amended to recite the device of claim 13, wherein the application data includes: accelerometer data, gyroscope data, global positioning data, Wi-Fi location data, available Bluetooth devices, dates and times of business-related events of a user of a requesting device, dates and times of social events, fitness data related to fitness-related activities, dates and times listed in emails, dates and times listed in text messages, or location names associated with a location of a device that receives the request from the requesting device (Mayou; col. 3, lines 41-47, col. 13, lines 39-44, col. 28, lines 44-47 and col. 28, line 61 to col. 29, line 6).
Claim 19 has been amended to recite the device of claim 13, wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to:
receive location data as part of the application data, wherein the location data includes a location name (Mayou; col. 28, line 61 to col. 29, line 6); and
in response to a change in location data, modify the adjusted alarm and/or notification parameters related to the identified diabetes-related alarms and notifications of diabetes treatment program (Mayou; col. 28, line 61 to col. 29, line 6, col. 30, lines 35-42).
Claim 20 recites the device of claim 13, wherein the processor, when executing the artificial pancreas application, is further operable to perform functions, including functions to:
receive, from the paired device, user preferences related to the alarm and notification parameters (Mayou; col. 23, lines 32-38, col. 23, line 59 to col. 24, line 3); and
adjust the alarm and/or notification parameters based on the received user preferences (Mayou; col. 23, lines 32-38, col. 23, line 59 to col. 24, line 3).
Response to Arguments
Applicant's arguments filed 11/24/2025 have been fully considered but they are not persuasive. Applicant’s arguments will be addressed below in the order in which they appear.
Arguments about 35 USC 101 rejection:
Step 2A, prong 1: Applicant argues that claim 1 is not directed to an abstract idea of certain methods of organizing human activity, since the claims is not directed to any one of fundamental economic principles, commercial or legal interactions, or managing personal behavior or relationships. Applicant argues that, instead, claim 1 is directed to programming code operable to adjust alarms and/or notifications associated with diabetes based on user agenda information.
In response, Examiner submits that the programming code executable by a processor is not part of the abstract idea rejection. Claim 1 is directed to an abstract idea of managing personal behavior and interactions between people (such as user following rules and instructions) regarding identifying and adjusting diabetes-related alarms and notifications according to user preference settings, with a recitation of generic devices such as a processor and a generic personal diabetes management device. The features of a programming code executable by a processor, and the processor executing the programming code to perform functions such as outputting a request, receive data, identify alarms/notifications, switching the alarms/notifications parameters and command the personal diabetes management device to execute the alarms/notifications correspond to mere instructions to apply/execute/automate an abstract idea in a particular technological environment.
Step 2A, prong 2: Applicant argues that claim 1 provides for a practical application in the form of improving personal diabetes management device alarm and notification capabilities, switching alarm/notification parameters form a first setting to a second setting according to the application data.
In response, Examiner submits that the claims are directed to changing (switching) the alarms/notifications parameters, so that the alarm/notification state changes (e.g. using a speaker, a vibration mechanism, or a light) based on the application data (such as GPS-location, calendar), but the claims are not directed to or recite any improvement on how the alarms/notification settings being changed, or any other technological improvement. The limitation of “switch alarm and/or notification parameters of a personal diabetes management device related to the identified diabetes-related alarms and/or notifications of the diabetes treatment program from a first state to a second state according to the application data” corresponds to mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components are not sufficient to amount to significantly more than the judicial exception.
Applicant argues that the technological improvement is improving the personal diabetes management device by dynamically adapts alarms/notification and intelligently modify its alarm behavior (volume, type and timing) in real-time based on the contextual information rather than static, pre-programmed settings. Applicant argues that claims recite a technological improvement similar to the claims of McRO.
In response, Examiner submits that changing/adapting the type, volume, timings of the alarms/notifications based on the application data, corresponds to mere instructions to apply the exception using generic computer components, and changing/adapting the alarms/notifications type, volume, timings may provide minimized disruption for the patient, however does not provide any improvement of the personal diabetes management device. The adjustments to the alarms/notifications are simply instructing the device the type of notification and timing should be provided to the patient, which does not have any effect of the device’s functionality.
The McRO, Inc. v. Bandai decision indicates: "...the claimed improvement here is allowing computers to produce “accurate and realistic lip synchronization and facial expressions in animated characters” that previously could only be produced by human animators…this computer automation is realized by improving the prior art through “the use of rules, rather than artists, to set the morph weights and transitions between phonemes…When looked at as a whole, claim 1 is directed to a patentable, technological improvement over the existing, manual 3-D animation techniques. The claim uses the limited rules in a process specifically designed to achieve an improved technological result in conventional industry practice. Alice, 134 S. Ct. at 2358 (citing Diehr, 450 U.S. at 177). Claim 1 of the ’576 patent, therefore, is not directed to an abstract idea.”. The current claims however, may provide less disruption to the patient /user, by changing the alarm types, volumes etc., but do not provide a technological improvement over the existing diabetes management devices.
Step 2B: Applicant argues that the combination of claim elements provides an inventive concept of dynamic alarm and/or notification parameters modifications of a personal diabetes management device according to application data.
In response, Examiner submits that, under current Office guidelines, patentability with respect to 35 U.S.C. 101 is not evaluated through the lens of 35 U.S.C. 103(a). Although novelty and non-obviousness may provide a useful clue in identifying limitations that are not conventional or routine in the field (79 Fed. Reg. 74624), claims that overcome rejections under 35 U.S.C. 102 or 103 are not necessarily statutory in nature.
Therefore, Applicant’s arguments are not persuasive and claims are rejected under 35 U.S.C. §101 as being directed to non-statutory subject matter.
Arguments about 35 USC 102 rejection:
Applicant argues that Mayou does not teach “switch alarm and/or notification parameters of a personal diabetes management device related to the identified diabetes-related alarms and/or notifications of the diabetes treatment program from a first state to a second state according to the application data”.
In response, Examiner submits that Mayou teaches “…a method of adjusting an interface format / style ( e . g . , graph , display of sensor data , buttons , alarms , default screens , and preferences for inter action ) of physiological information based on behavioral and / or contextual information.” in col. 10, lines 50-54, “…behavioral and/or contextual information about the user/patient is determined… the system may determine the patient is in a certain social situation such as in a work meeting or out to dinner with friends based on GPS and/or calendar information. As yet another example, the system may determine the patient is exercising or driving via input from an accelerometer, calendar, and/or GPS). In each of these examples, the context and behavior can be associated with the physiological information without actually requiring the user to input the determined information.” in col. 13, lines 25-26, 39-47, and “…Environmental adjustments may also be provided such as if the user is determined to be outside most of the time (context) a brighter contrast may be used for a trend screen display. Other adjustments can include providing higher level of discretion (adjustment) when detecting the location a work meeting (context), providing a basic, high-level report to a user determined to be overwhelmed with data or to a newly diagnosed user…: in col. 17, lines 19-27, and “The adjustments may provide a set of 30 adaptations that are continuously applied ( once adjusted , until the next adjustment ) and / or that are applied depending on the behavior or context identified at any particular time ( a profile of adjustments that depend on real - time context / behavior ) .” in col. 17, lines 30-35.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DILEK B COBANOGLU whose telephone number is (571)272-8295. The examiner can normally be reached 8:30-5:00 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, Obeid Mamon can be reached at (571) 270-1813. 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.
/DILEK B COBANOGLU/ Primary Examiner, Art Unit 3687
Prosecution Insights