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 November 12, 2025, has been entered.
Response to Amendment
Claims 1 and 23 have been canceled. Claims 4-10, 12-16, 20-22, and 24 have been canceled. Claim 27 is new. Claim 27 is withdrawn below based on election by original presentation. Claims 1-3, 11, 17-19, 23, 25, and 26 are pending and are provided to be examined upon their merits.
Election/Restrictions
Newly submitted claim 27 is directed to an invention that is independent or distinct from the invention originally claimed for the following reasons: Claim 27 is directed towards an on-skin infusion device comprising a glucose sensor, a bolus information interface, and a closed-loop control device. This is separate and distinct from the previous claims 1-3, 11, 17-19, 23, 25, and 26 which were directed to a computer method, where the computer received blood glucose values and bolus information for a period of time from an on-body infusion device.
Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable.
In the instant case, subcombination I has separate utility such as a computer method for receiving blood glucose values and bolus information relating to a time period. Subcombination I can be practiced separately from subcombination II of an on-skin infusion device comprising a pump, glucose sensor, a bolus information interface, and a closed loop control device as subcombination I computer does not require an on-skin infusion device and interfaces to perform receive values in a time period.
Subcombination II has separate utility such as an on-skin infusion device comprising a pump drive system, glucose sensor interface, bolus information interface, and a closed loop control device. Subcombination II can be practiced separately from subcombination I computer method of receiving blood glucose values and bolus information using an on-body infusion device as subcombination II does not require a computer to receive such information. See MPEP § 806.05(d).
Since Applicant has received an action on the merits for the originally presented invention, this invention has been constructively elected by original presentation for prosecution on the merits. Accordingly, claim 27 is withdrawn from consideration as being directed to a non-elected invention. See 37 CFR 1.142(b) and MPEP §821.03.
Response to Arguments
Applicant’s arguments with respect to claims 1-3, 11, 17-19, 23, 25, and 26 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A response is provided below in bold where appropriate.
Applicant argues 35 USC §101 Rejection, starting pg. 6 of Remarks:
Claim Rejections -35 U.S.C. § 101
Claims 1-3, 9-11, 17-19, and 23-26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The Applicant respectfully traverses this rejection.
The claim amendments have caused the 35 USC 101 Rejection to be withdrawn, rendering the arguments moot.
Applicant argues 35 USC §103 Rejection, starting pg. 9 of Remarks:
Claim Rejections - 35 U.S.C. § 103
Claims 1-3, 23, and 26 are rejected under 35 U.S.C. § 103 as being unpatentable over US 2018/0174675 to Roy. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
In reviewing Claim 1, it is unclear as to what figure Applicant is claiming for performing the functions. A computer implemented method is claimed, but the computer is never used in the claim. Applicant is requested to provide the figure of the system they are claiming. For example, in Claim 1, what role does the computer play in the steps and where is it communicating with the on-body device (which figure is being claimed)? The Examiner thanks Applicant in advance.
The Office cites paragraph [0128] of Roy as relevant to the claimed receiving closed-loop control device but the discussion in cited paragraph [0128] does not say the closed-loop control device of an on-skin infusion device receives the claimed blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time as recited in the claim. In fact, the discussion in Roy's paragraph [0128] is directed to: "The mathematical model may then be optimized to identify an estimated carbohydrate ratio for the input meal size that results in an average estimated postprandial peak sensor glucose value at the estimated postprandial peak time following a meal event equal to a desired target postprandial peak sensor glucose value (e.g., 180 mg/dl)."
Claim 1 does not recite “on-skin infusion device.” Claim 1 recites “on-body infusion device.”
Roy teaches a device secured to the body, therefore, and on-body infusion device. Further, there is no teaching of an “on-skin infusion device” in Applicant’s specification.
The above illustrates why it would be helpful for Applicant to point to the figure they are claiming that shows their computer and infusion device.
At page 17 of the Office Action, the Office lists the claim language of: generating a meal size propensity record regarding the person based on the received blood glucose values and the received bolus information relating to the period of time; and quotes language from Applicant's specification that supports the claim language ending on page 18 of the Office Action. After the quoted language, the Office concludes the detailed claim language is merely: "Therefore, the propensity record based on glucose and bolus information and is the likelihood a person will ingest a number of grams of carbohydrates."
However, Claim 1 recites, in part:
generating a meal size propensity record regarding the person based on the received blood glucose values and the received bolus information relating to the period of time and using a bolus probability density as a proxy for meal occurrence likelihood, wherein the bolus probability density is a continuous probability distribution based on the received bolus information.
The Office quotes Roy's paragraph [0008] as relevant. Roy's paragraph [0008] states "a control system coupled to the actuation arrangement, the sensing arrangement, and the data storage element to predict a future meal based at least in part on the historical meal data and a current time of day." But that does not disclose the claimed probability densities, and particularly, does not disclose or suggest using a bolus probability density as a proxy for meal occurrence likelihood, wherein the bolus probability density is a continuous probability distribution based on the received bolus information as recited in claim 1.
Applicant has amended their claims to add bolus probability density. However, nothing is done with this in the claim.
Additional prior art is cited that teaches the above.
The Office then cites Roy's paragraph [0037] as relevant because it describes a personalized meal library that may be used to "predict the most likely meal content and serving sizes for a meal at the current time (or an anticipated meal in the future) based on the user's historical meal data and the current contextual situation." But the discussion of the "most likely meal content" continues in Roy's paragraph [0037] by stating, "a user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct."
The Office, at page 19, under the header Estimated carbohydrate amount (meal size) determined (based on) bolus process and quotes Roy's paragraph [0132] with emphasis on "Such a GUI display may also include indication of the estimated carbohydrate ratio and estimated carbohydrate amount determined by the personalized bolus process 1100 for review, modification, and/or confirmation."
Applicant above appears to be reviewing Roy’s teachings?
Claim 1 further recites, "determining, based on the received blood glucose values, the received bolus information, and the meal size propensity record regarding the person, a dosage amount of insulin for the person."
At page 20 of the Office Action, the Office asserts that the above claim language is again disclosed in Roy's paragraphs [0037] and [0134] disclose or suggest this claimed feature. The Office analogizes the Roy's personal meal library as a record that include a meal size based on predicted most likely meal (meal size propensity record). However, Roy's paragraph [0132] with reference to FIG. 11 states, "In this regard, the estimated carbohydrate amount for the input meal size is multiplied by the carbohydrate ratio for the input meal size to obtain a corresponding bolus dosage to be administered." This not the same as the above quoted text from claim 1. In addition, the cited portions do not disclose or suggest all of the elements recited in the above quoted language from claim 1. Hence, for at least this additional reason, claim 1 is patentable, and the rejection of claim 1 under 35 U.S.C. § 103 in view of Roy be withdrawn.
Applicant has amended their claims, requiring additional prior art.
At pages 22 and 23 of the final Office Action, the Office asserts that claim 3 is obvious in view of Roy's disclosure at paragraphs [0125] and [0126].
Claim 3 recites, determining the meal size propensity record based on a first time period, wherein the first time period corresponds to a beginning of ingestion of a meal.
Roy does not disclose a propensity record explicitly tied to an alignment of a time-period-specific generation and a beginning of ingestion of a meal. The temporal precision of aligning the propensity record to the beginning of meal ingestion that when coupled with the features recited in independent claim 1 on which claim 3 depends is absent from Roy's qualitative meal logging approach disclosed in Roy's paragraphs [0125] and [0126].
Roy teaches an initial setup monitoring period where a patient estimates or inputs meal sizes when logging meal events. This teaches meal size propensity record based on a first time period.
Hence, claim 3 is patentable for the reasons stated above with respect to independent claim 1 and these additional remarks.
Based on the above, the Examiner maintains Roy teaches the claim element.
At pages 23 and 24 of the final Office Action, the Office asserts that claim 23 is obvious in view of Roy's disclosure at paragraphs [0038], [0123] and [0125].
Claim 23 recites, receiving carbohydrate announcements for the person regarding the period of time; and generating the meal size propensity record based on the bolus information and the carbohydrate announcements, wherein the bolus information includes bolus events distributed within the period of time.
In contrast to the claimed method of claim 23, Roy's personalized bolus process converts qualitative meal sizes to carbohydrate amounts using historical data. The fusion of bolus events with carbohydrate announcements to form multi-dimensional meal size likelihoods through density-based processing exceeds Roy's qualitative meal library and simple historical data conversion.
It appears Applicant is arguing that what Roy teaches exceeds what they can do? Density is not taught in Claim 23.
Hence, claim 23 is patentable for the reasons stated above with respect to independent claim 1 and these additional remarks.
The Examiner maintains Roy teaches Claim 23 based on the cited teachings of Roy.
Claims 10 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (8) of the Office Action in view of Pub. No. US 2017/0049386 to Abraham et al. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
Claim 10 has been canceled. Therefore, the rejection of it is moot.
At page 26 of the Office Action, the Office admits the combined references do not teach using bolus probability density as a proxy for meal occurrence. Since section (8) of the Office Action only relies on the single Roy reference, the Applicant assumes that when the Office states, "The combined references teach meal and using bolus. They also teach meal size. They do not teach using bolus probability density as a proxy for meal occurrence" that Office is referring to Roy and Abraham. But the Office goes on to assert that Abraham teaches a probability density that can be used for predicting meals and insulin needs.
However, claim 11 depends on claim 1, and recites, generating the bolus
probability density by aggregating bolus events for the person that are included in the bolus information..
Abraham computes meal probability per interval by counting meal boluses.
However, the claims recite a continuous bolus probability density over a shorter interval, then uses it as a proxy for meals.
Abraham's simple interval-based counting fundamentally differs from Applicant's sophisticated continuous probability distribution function generation through kernel smoothing, wrapping, and replication. The use of this density as a proxy for meal occurrence represents a novel technical insight not suggested by the prior art's discrete counting approach.
Applicant is reminded of piecemeal analysis…
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant appears to be arguing amended Claim 1.
Claims 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (8) of the Office Action in view of Pub. No. US 2019/0252079 to Constantin et al. Section 8 of the Office Action lists Roy as the only reference of record. Applicant is addressing the rejection of claims 17 and 19 as being rejected over the combination of Roy and Constantin. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
Claims 17 and 19 recite additional details, such as alert threshold modifications based on meal probability; and change classifier feature threshold based on kernel smoothed density; reduce threshold for associating missed bolus with meal, that are not disclosed or suggested by the combination of Roy and Constantin.
Constantin does not overcome the above described deficiencies of Roy with respect to independent claim 1. Hence, claims 17 and 19 are patentable and the rejection of claims 17 and 19 under 35 U.S.C. § 103 in view of Roy and Constantin should be withdrawn.
Applicant is reminded of piecemeal analysis…
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The Examiner respectfully maintains the rejection is appropriate.
Claim 18 is rejected under 35 U.S.C. § 103 as being unpatentable over the combined references in section (10) above in further view of CA 3001448 to Stahl. As best understood, the references cited in Section 10 are the Roy reference (cited in Section (8)) and Constantin. The Applicant understands the current 35 U.S.C. § 103 rejection to be in view of the combination of Roy, Constantin and Stahl. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
Claim 18 depends from claim 17 and further recites "wherein taking into account the meal size propensity record comprises changing a threshold for a feature in a machine-learning classifier based on a kernel smoothed density estimate in the meal size propensity record." The Examiner acknowledges that the combined base references (Roy and Constantin) teach meal size and threshold, but expressly admits that these references do not teach kernel smoothed density estimate. The Examiner relies on Stahl to cure this admitted deficiency, asserting that Stahl teaches using kernel smoothing techniques (specifically, a quadratic Epaneichnikov kernel) and that it would have been obvious to include kernel smooth density estimates in the combined references because smoothing aids in threshold analysis of glycemic events.
Applicant respectfully submits that claim 18 is not obvious because Stahl does not teach or suggest the claimed feature of changing a threshold for a feature in a machine- learning classifier based on a kernel smoothed density estimate in a meal size propensity record, and the combination of references fails to render this specific limitation obvious. First, Stahl's disclosure of kernel smoothing is directed to an entirely different technical context-specifically, estimating insulin action models using locally-weighted least squares with kernel-based weighting to describe heterogeneous glucose-lowering effects across different glucose ranges. Stahl teaches applying kernel techniques to model insulin action dynamics (i.e., the physiological response to insulin over time), not to generating meal size propensity records or modulating machine-learning classifier thresholds based on such records. The Examiner has not identified any teaching or suggestion in Stahl that kernel smoothing should be applied to bolus probability density to create a meal size propensity record, nor that such a record should then be used to dynamically adjust classifier thresholds. The mere fact that Stahl uses kernel smoothing in a completely different context (insulin action modeling) does not render obvious the claimed application of kernel smoothed density estimates to classifier threshold modulation in the specific architecture disclosed in the present application.
For at least these reasons, Applicant respectfully submits that claim 18 recites patentably distinct subject matter over the cited combination of Roy, Constantin, and Stahl, and respectfully requests that the rejection of claim 18 be withdrawn.
Stahl is analogous prior art, used to teach kernel smoothed density estimate.
Applicant is reminded of piecemeal analysis…
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
The Examiner respectfully maintains the rejection is appropriate.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over the
combined references in section (8) above in further view of Pub. No. US 2017/0049386 to Abraham et al. in view of Pub. No. US 2018/0169334 to Grosman et al. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
Claim 24 has been canceled. Therefore, the rejection of it is moot and should be withdrawn.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over the
combined references in section (8) above in further view of Pub. No. US 2021/0060246 to Weydt et al. The Applicant respectfully traverses the rejection, and requests reconsideration and withdrawal of the rejection.
The Office at page 40 of the final Office Action, the Office states, "Constantin et al. teaches diabetes. They do not teach gesture." However, the summary of the rejection states claim 25 is rejected over "the combined references in section (8) above in further view of Pub. No. US 2021/0060246 to Weydt et al." Section (8) of the final Office Action lists only the Roy reference. Constantin is not referenced. Also, it is unclear what the plural pronoun they, when used in the context of the single prior art reference Roy, is referring to. Applicant assumes that "they" in this context refers to only the Roy reference, and not to Constantin or the combination of Roy and Constantin. Applicant addresses the rejection of claim 25 under 35 U.S.C. § 103 as being unpatentable over Roy et al. in view of Weydt et al. (US 2018/0075200 A1).
Claim 25 recites, "receiving a gesture of the person with diabetes, wherein
generating the meal size propensity record is further based on the gesture," which is an integration of gesture inputs into meal detection and propensity record generation itself. In contrast, Weydt detects additional food via hand movement to adjust insulin. Weydt's reactive dosing adjustment based on detected gestures differs fundamentally from the claimed integration of gesture signals into the foundational propensity record creation process, enabling the gesture data to inform all downstream meal detection, timing, and dosing determinations.
Hence, for this reason, claim 25 is patentable and the rejection of claim 25 under 35 U.S.C. § 103 in view of the combined references in section (8) of the final Office Action (i.e., Roy) and further in view of Wyedt et al. should be withdrawn.
The prior art is analogous prior art only used to teach gesture. The Examiner respectfully maintains the rejection is appropriate.
Claim 27
Independent claim 27 recites additional features and similar functions as
independent claim 1 that are patentable and that distinguishes from the prior art's server- based architectures.
This was restricted out by original presentation. But also there is no teaching of a skin device.
Claim Interpretation
Claim 1 recites “closed-loop control circuitry” where there is no teaching of closed-loop control circuitry. For examination purposes this is interpreted to be a “closed loop controller” or “closed-loop control device” (paras. [0008] and [0060] of the specification).
From the specification…
“FIG. 1A shows an example of a closed-loop diabetes treatment system 100. The closed-loop diabetes treatment system 100 can be used with one or more other examples described herein. The closed-loop diabetes treatment system 100 includes a glucose sensor 102 that is configured to sense or estimate the blood glucose level of a person with diabetes one or more times (e.g., on an ongoing basis, and/or at regular intervals). In some implementations, the glucose sensor 102 includes a CGM and/or a BGM. The closed-loop diabetes treatment system 100 includes an insulin injection device 104 that is configured for injecting (e.g., automatically injecting) one or more bolus amounts of insulin into the person. For example, the insulin injection device 104 can include an insulin pump coupled to a subcutaneous member that is in fluid communication with tissue or vasculature of the person so as to be able to deliver insulin into the person's body. The closed-loop diabetes treatment system 100 includes a closed-loop control device 106 that is coupled to, or otherwise configured to communicate with, the glucose sensor 102 and the insulin injection device 104. The closed-loop control device 106 includes, or has access to, a meal size propensity record regarding the person with diabetes. The closed-loop control device 106 is configured to receive blood glucose values (e.g., from the glucose sensor 102) and bolus information regarding the person (e.g., from the insulin injection device 104). The closed-loop control device 106 is configured to determine, based on the blood glucose values, the bolus information, and the meal size propensity record, an amount of insulin for the person. For example, this determination can involve calculating how much insulin the closed-loop diabetes treatment system 100 should inject into the person at a given time, or over a period of time. The closed-loop control device 106 is configured to cause the determined amount of insulin to be injected into the person. For example, this can be done by controlling the insulin injection device 104 to deliver the determined amount of insulin in form of one or more boluses.” [0060]
Therefore, the closed-loop control device is coupled (attached) to the sensor and injection device.
Claim 1 recites “in a closed-loop control circuitry of an on-body infusion device,” where there is no teaching of “on-body infusion device.”
From the specification…
“FIG. 12 is a perspective view of an example of an infusion pump system 1200. The infusion pump system 1200 can be portable and have a plunger engagement device 1201 to serve as a reusable pump apparatus (rather than a disposable pump device). In such circumstances, the infusion pump system 1200 may comprise a reusable device that houses the control circuitry and the pump drive system within a single housing construct. In some implementations, the infusion pump system 1200 can include a reusable pump device that houses both controller circuitry and a pump drive system. The infusion pump system 1200 can include a housing that defines a cavity in which a fluid cartridge can be received (not shown for simplicity). For example, the infusion pump system 1200 can be adapted to receive a fluid cartridge in the form of a carpule that is preloaded with insulin or another medicine. The pump drive system can act upon the fluid cartridge to controllably dispense medicine through an infusion set 1202 and into the user's tissue or vasculature. In this embodiment, the user can wear the infusion pump system 1200 on the user's skin under clothing or in the user's pocket while receiving the medicine dispensed through the infusion set 1202. Any of multiple possible mechanisms for delivering medicament (e.g., insulin) can be used. In some implementations, the plunger engagement device 1201 of the infusion pump system 1200 may include a retention spring (not shown) that once activated biases the plunger of the fluid cartridge towards a piston rod of the drive system to increase dosage accuracy.” [0135]
Therefore, the “infusion device” is interpreted as an “infusion pump system” that can be worn on the user’s skin, under clothing, or in a user’s pocket.
35 USC § 101 Analysis
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, 11, 17-19, 23, 25, and 26 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Claims 1-3, 11, 17-19, 23, 25, and 26 are directed to a method, which is a statutory category of invention. (Step 1: YES).
The Examiner has identified method Claim 1 as the claim that represents the claimed invention for analysis.
Claim 1 recites the limitations of:
A computer-implemented method of performing closed-loop insulin therapy, the method comprising:
receiving, in a closed-loop control circuitry of an on-body infusion device, blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time;
generating, a meal size propensity record regarding the person based on the received blood glucose values and the received bolus information relating to the period of time and using a bolus probability density as a proxy for meal occurrence likelihood, wherein the bolus probability density is a continuous probability distribution based on the received bolus information;
determining, based on the received blood glucose values, the received bolus information, and the meal size propensity record regarding the person, a dosage amount of insulin for the person; and
causing, by the control circuitry of the on-body infusion device, in response to the determination, administering of the dosage amount of insulin via a pump drive system of the on-body infusion device to the person.
These above limitations, under their broadest reasonable interpretation, cover performance of the limitation as certain methods of organizing human activity. The claim recites elements, in bold above, which covers performance of the limitation as managing person behavior (e.g., receiving blood glucose values of a person, generating a meal size propensity record regarding the person, determining a dosage amount of insulin for the person, causing the amount of insulin to be administered to the person. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation as a managing personal behavior, then it falls within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. Claim 1 is abstract. (Step 2A-Prong 1: YES. The claims are abstract)
In as much as the claim is receiving values and information, generating a meal size propensity record, determining an amount of insulin for a person, the claim is also abstract under as a mental process, which can be performed in the mind of a person, with pen and paper. Therefore, the claims are abstract as a mental process. See also MPEP 2106.04(a)(2) III C where using a computer to perform a mental process has been shown to be abstract.
However, the claim recites:
“determining, based on the received blood glucose values, the received bolus information, and the meal size propensity record regarding the person, a dosage amount of insulin for the person; and
causing, by the control circuitry of the on-body infusion device, in response to the determination, administering of the dosage amount of insulin via a pump drive system of the on-body infusion device to the person.
The above provides a practical application of determining an amount of insulin and administering the insulin dosage via a pump drive system to a person. This is interpreted as providing additional element of a practical application and significantly more. Therefore Claim 1 rejection is withdrawn.
Claims 2, 3, 11, 17-19, 23, 25, and 26 overcome 35 USC 101 for the reasons given above for their independent claim.
Claim Rejections - 35 USC § 112
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 1-3, 11, 17-19, 23, 25, and 26 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “A computer-implemented method of performing closed- loop insulin therapy, the method comprising: receiving, in a closed-loop control circuitry of an on-body infusion device, blood glucose values and bolus information…causing by the control circuitry of the on-body infusion device, in response to the determination, administrating of the dosage amount of insulin via a pump drive system…” where the computer is supposed to perform the insulin therapy (preamble), it is indefinite as to how the computer is performing the closed-loop therapy since the control circuitry of an on-body device is receiving the values and information and administering the dosage. It is also indefinite as to a computer implemented method where the computer is not doing anything in the claim, what is the computer doing? For examination purposes, the computer is somehow communicating with an on-body insulin device to receive and transmit information.
Claim 1 recites “… and using a bolus probability density as a proxy for meal occurrence likelihood, wherein the bolus probability density is a continuous probability distribution based on the received bolus information;” where using a bolus probability density as a proxy for meal occurrence likelihood is indefinite as nothing is done with the proxy for meal occurrence likelihood. It is indefinite as to why it is in the claim. The claim determines a dosage amount based on received blood glucose values, received bolus information, and meal propensity record, not on meal occurrence likelihood.
Claims 2, 3, 11, 17-19, 23, 25, and 26 are further rejected as they depend from their independent Claim 1.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 U.S.C. §112(a) or §112 1st paragraph issues that can arise when claims are amended without support in the specification. The Examiner thanks the Applicant in advance.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 11, 23, and 26 are rejected under 35 U.S.C. 103 as being unpatentable over Pub. No. US 2018/0174675 to Roy et al. and in view of Pub. No. US 2017/0049386 to Abraham et al.
Regarding claim 1
A computer-implemented method of performing closed-loop insulin therapy, the method comprising:
receiving, in a closed-loop control circuitry of an on-body infusion device, blood glucose values and bolus information regarding a person with diabetes, the blood glucose values and the bolus information relating to a period of time;
{
From Applicant’s specification on closed-loop control circuitry on an on-body infusion device….
“… For example, the insulin injection device 104 can include an insulin pump coupled to a subcutaneous member that is in fluid communication with tissue or vasculature of the person so as to be able to deliver insulin into the person's body. The closed-loop diabetes treatment system 100 includes a closed-loop control device 106 that is coupled to, or otherwise configured to communicate with, the glucose sensor 102 and the insulin injection device 104…” [0060]
Therefore, the closed-loop device is somehow coupled or configured to communicate with the glucose sensor and injection device.
}
Roy et al. teaches:
Insulin infusion for diabetic’s condition (person with diabetes)…
“Continuous insulin infusion provides greater control of a diabetic's condition, and hence, control schemes are being developed that allow insulin infusion pumps to monitor and regulate a user's blood glucose level in a substantially continuous and autonomous manner, for example, overnight while the user is sleeping. Regulating blood glucose level is complicated by variations in the response time for the type of insulin being used along with each user's individual insulin response. Furthermore, a user's daily activities and experiences may cause that user's insulin response to vary throughout the course of a day or from one day to the next. Thus, it is desirable to account for the anticipated variations or fluctuations in the user's insulin response caused by the user's activities or other condition(s) experienced by the user.” [0004]
Infusion device secured to the body (on-body infusion device)…
“Turning now to FIG. 1, one exemplary embodiment of an infusion system 100 includes, without limitation, a fluid infusion device (or infusion pump) 102, a sensing arrangement 104, a command control device (CCD) 106, and a computer 108. The components of an infusion system 100 may be realized using different platforms, designs, and configurations, and the embodiment shown in FIG. 1 is not exhaustive or limiting. In practice, the infusion device 102 and the sensing arrangement 104 are secured at desired locations on the body of a user (or patient), as illustrated in FIG. 1. In this regard, the locations at which the infusion device 102 and the sensing arrangement 104 are secured to the body of the user in FIG. 1 are provided only as a representative, non-limiting, example. The elements of the infusion system 100 may be similar to those described in U.S. Pat. No. 8,674,288, the subject matter of which is hereby incorporated by reference in its entirety.” [0041]
PNG
media_image1.png
472
444
media_image1.png
Greyscale
Sensing, infusion device cooperatively configured (coupled/communicate) to use closed-loop system…
“In some embodiments, the sensing arrangement 104 and/or the infusion device 102 are cooperatively configured to utilize a closed-loop system for delivering fluid to the user. Examples of sensing devices and/or infusion pumps utilizing closed-loop systems may be found at, but are not limited to, the following U.S. Pat. Nos. 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153 or United States Patent Application Publication No. 2014/0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, the sensing arrangement 104 is configured to sense or measure a condition of the user, such as, blood glucose level or the like. The infusion device 102 is configured to deliver fluid in response to the condition sensed by the sensing arrangement 104. In turn, the sensing arrangement 104 continues to sense or otherwise quantify a current condition of the user, thereby allowing the infusion device 102 to deliver fluid continuously in response to the condition currently (or most recently) sensed by the sensing arrangement 104 indefinitely. In some embodiments, the sensing arrangement 104 and/or the infusion device 102 may be configured to utilize the closed-loop system only for a portion of the day, for example only when the user is asleep or awake.” [0047]
Contextual data such as time added to physiological response that includes use of bolus and sensor glucose measurement…
“…Based on the input activity, the bolus dosage or closed-loop controls may be adjusted to account for the user's predicted physiological response to the input activity based on the user's historical physiological response to that particular type of activity using the user's historical sensor glucose measurement data. Additional contextual information (e.g., time of day, day of week, geographic location, and the like) may also be incorporated to further refine the user's predicted physiological response. Bolus dosages or closed-loop control parameters may then be adjusted to account for the activities that the user is or is likely to be engaged in.” [0039]
One example of using (receiving) glucose measurement values and bolus dosages and example of related to periods of time…
“For example, in one or more embodiments, a mathematical model of the patient's postprandial glucose response to meals having the input meal size is created using the patient's historical sensor glucose measurement values for postprandial periods following the respective meal events, historical meal bolus dosages of insulin associated with the respective meal events, and historical closed-loop or basal insulin deliveries for postprandial and/or preprandial periods surrounding the respective meal events. An average or nominal glucose rate of appearance for the input meal size may be determined based on the historical sensor glucose measurement values and utilized to determine an estimated postprandial peak in the patient's sensor glucose value following a meal event. The mathematical model may then be optimized to identify an estimated carbohydrate ratio for the input meal size that results in an average estimated postprandial peak sensor glucose value at the estimated postprandial peak time following a meal event equal to a desired target postprandial peak sensor glucose value (e.g., 180 mg/dL). In other embodiments, a heuristic statistical analysis may be performed on the patient's historical meal, delivery, and measurement data to identify a carbohydrate ratio for the input meal size that is likely to achieve a desired postprandial glucose response. It should be noted that in some embodiments, the historical data sets utilized to determine the carbohydrate ratio may be further filtered or limited to be context-specific, for example, to particular periods of the day (e.g., meal events corresponding to a morning period between 6:00 A.M. and 12:00 P.M.), a particular day of the week, a particular geographic location, and/or the like.” [0128]
generating, a meal size propensity record regarding the person based on the received blood glucose values and the received bolus information relating to the period of time and using a bolus probability density as a proxy for meal occurrence likelihood, wherein the bolus probability density is a continuous probability distribution based on the received bolus information;
{
From Applicant’s specification on meal size propensity record…
“…The computer-implemented method further comprises generating the meal size propensity record based on the blood glucose values and the bolus information. The computer-implemented method further comprises generating multiple meal size propensity records corresponding to different days of a week for the person…” [0010]
“Some examples herein refer to a meal size propensity record. A meal size propensity record is a computer-readable document that indicates a meal size propensity for at least one person. The meal size propensity record can pertain to an individual person with diabetes or to multiple persons (e.g., a population). For example, the meal size propensity record can correspond to actual data that was collected for the person or population. As another example, the meal size propensity record can correspond to data that was simulated for the person or population. The meal size propensity record can, at least in part, indicate a likelihood that a person will ingest a meal of a given size (e.g., having a particular number of grams of carbohydrates). For example, the meal size propensity record can indicate a probability density for one or more meal sizes. The meal size propensity record can be tangibly embodied in a computer-readable storage medium.” [0058]
Therefore, the propensity record based on glucose and bolus information and is the likelihood a person will ingest a number of grams of carbohydrates.
}
Sensing current measurement value (glucose) and predict a future meal and adjust closed-loop control parameter (bolus) in advance of future meal…
“An embodiment of an infusion system is also provided. The infusion system includes an actuation arrangement operable to deliver fluid to a patient, the fluid influencing a physiological condition of the patient, a sensing arrangement to provide a current measurement value indicative of the physiological condition of the patient, a data storage element to maintain historical meal data for the patient, and a control system coupled to the actuation arrangement, the sensing arrangement, and the data storage element to predict a future meal based at least in part on the historical meal data and a current time of day, automatically adjust a closed-loop control parameter in advance of the future meal in a manner that is influenced by the future meal, and automatically operate the actuation arrangement to deliver the fluid to the patient based at least in part on the current measurement value and the adjusted closed-loop control parameter.” [0008]
Personalized meal bolus dosage amount by predict the meal content and serving sizes relating to contextual information such as time…
“In one or more embodiments, the personalized meal bolus dosage amount or control information associated with the closed-loop operating mode may be further adjusted or modified to account for the particular nutritional content of the meal (or meal type) being consumed. To facilitate meal type adjustments and reduce the user burden, a personalized meal library is created for an individual user based on his or her meal history, and recommended or suggested meals can be prioritized based on correlations to current contextual information (e.g., time of day, day of week, geographic location, etc.). Once sufficient historical meal data for a user exists, a personalized library of likely meal content can be created, with machine learning being utilized to predict the most likely meal content and serving sizes for a meal at the current time (or an anticipated meal in the future) based on the user's historical meal data and the current contextual situation (e.g., the current time of day, current day of week, current geographic location, etc.). A user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct. Based on the validation or modification of the predicted meal content, the user's historical meal data or prediction model can be dynamically updated in a manner that allows for the accuracy of the predicted meal content to improve over time.” [0037]
Estimated carbohydrate amount (meal size) determined by (based on) bolus process…
“Still referring to FIG. 11, once a carbohydrate ratio and estimated carbohydrate amount associated with the input meal size for the current operating context are determined, the personalized bolus process 1100 continues by calculating or otherwise determining a meal bolus dosage amount using the carbohydrate ratio and the estimated carbohydrate amount and operating the infusion device to administer the meal bolus dosage amount (tasks 1112, 1114). In this regard, the estimated carbohydrate amount for the input meal size is multiplied by the carbohydrate ratio for the input meal size to obtain a corresponding bolus dosage to be administered. The command generation application 610 is then commanded, signaled, or otherwise instructed to operate the motor 532 of the infusion device 502 to deliver the calculated bolus dosage of insulin. In some embodiments, the calculated meal bolus dosage may be automatically administered; however, in other embodiments, a notification of the calculated meal bolus dosage may be generated or otherwise provided on a GUI display for review, modification, and/or confirmation by the patient. Such a GUI display may also include indication of the estimated carbohydrate ratio and estimated carbohydrate amount determined by the personalized bolus process 1100 for review, modification, and/or confirmation. In this regard, some embodiments may allow the patient to override the personalized bolus process 1100 and modify one or more of the carbohydrate ratio, the carbohydrate amount, or the bolus dosage amount. In such scenarios, the patient modifications may be utilized to update or otherwise adjust the models for estimating the patient's carbohydrate ratio and/or carbohydrate amount to be associated with the input meal size for subsequent iterations of the personalized bolus process 1100.” [0132]
See Probability below.
determining, based on the received blood glucose values, the received bolus information, and the meal size propensity record regarding the person, a dosage amount of insulin for the person; and
Personalized meal library (record) with bolus and meal size based on predicted most likely meal (meal size propensity record)…
“In one or more embodiments, the personalized meal bolus dosage amount or control information associated with the closed-loop operating mode may be further adjusted or modified to account for the particular nutritional content of the meal (or meal type) being consumed. To facilitate meal type adjustments and reduce the user burden, a personalized meal library is created for an individual user based on his or her meal history, and recommended or suggested meals can be prioritized based on correlations to current contextual information (e.g., time of day, day of week, geographic location, etc.). Once sufficient historical meal data for a user exists, a personalized library of likely meal content can be created, with machine learning being utilized to predict the most likely meal content and serving sizes for a meal at the current time (or an anticipated meal in the future) based on the user's historical meal data and the current contextual situation (e.g., the current time of day, current day of week, current geographic location, etc.). A user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct. Based on the validation or modification of the predicted meal content, the user's historical meal data or prediction model can be dynamically updated in a manner that allows for the accuracy of the predicted meal content to improve over time.” [0037]
Personalized bolus process and prospective closed-loop process (therefore, using meal size), improve glucose management and determine bolus dosage corresponding to meal size…
“It should be noted that the personalized bolus process 1100 may be performed in concert with the prospective closed-loop control process 900 and the event pattern control process 1000 to improve the patient's glucose management. In this regard, as described above, the prospective closed-loop control process 900 automatically increases the insulin delivery rate or insulin on board in advance of the meal. The personalized bolus process 1100 may then be initiated automatically at the predicted meal time or in response to the event pattern control process 1000 detecting the occurrence of a meal. The personalized bolus process 1100 then determines a personalized, context-specific meal bolus dosage corresponding to the meal size that was automatically identified, detected, or predicted. The patient may then simply confirm the detected meal size and trigger administration of the meal bolus amount with as little as a single user input without any carbohydrate counting or other manual interaction. Additionally, by virtue of the prospective closed-loop adjustments and the carbohydrate ratio that is personalized and specific to the current meal size and operational context, variations in the rate of glucose appearance, non-homogeneity of meals, and other factors can be accounted for or otherwise mitigated to improve efficacy of postprandial glucose management.” [0134]
causing, by the control circuitry of the on-body infusion device, in response to the determination, administering of the dosage amount of insulin via a pump drive system of the on-body infusion device to the person.
Example of infusion device and pump…
“The various tasks performed in connection with the personalized bolus process 1100 may be performed by hardware, firmware, software executed by processing circuitry, or any combination thereof. For illustrative purposes, the following description refers to elements mentioned above in connection with FIGS. 1-8. In practice, portions of the personalized bolus process 1100 may be performed by different elements of an infusion system, such as, for example, an infusion device 102, 200, 502, 802, a client computing device 106, 806, a remote computing device 108, 814, and/or a pump control system 520, 600. It should be appreciated that the personalized bolus process 1100 may include any number of additional or alternative tasks, the tasks need not be performed in the illustrated order and/or the tasks may be performed concurrently, and/or the personalized bolus process 1100 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown and described in the context of FIG. 11 could be omitted from a practical embodiment of the personalized bolus process 1100 as long as the intended overall functionality remains intact.” [0124]
Roy et al. teaches library with bolus and meal size. They do not explicitly teach meal size propensity record. However, one of ordinary skill in the art would recognize that a library of related data for a person is a record.
It would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s filing to modify Roy et al. with the knowledge available to such an artisan that a library made up of a person information would be a record. This would have been known work in the field of endeavor prompting variations of it in the same field based on use of maintaining information about a user and would provide predictable results.
Probability
Roy et al. teaches bolus and meal. They do not teach bolus probability as a proxy for meal.
Abraham et al. also in the business of bolus and meal teaches:
Meal probability for interval determined based on number of meal bolus indications within that interval (density of bolus for time interval)…
“The patient modeling process 200 also calculates or otherwise determines a meal probability associated with the respective segments based on the patient's bolus history (task 210). In this regard, the server 106 analyzes the meal bolus indications associated with the patient to determine a meal probability distribution for the patient that represents the relative probability of the patient consuming a meal at a particular time of day. In one embodiment, the server 106 divides the period of a day into a plurality of intervals, with a respective meal probability associated with each interval being determined based on the number of meal bolus indications having an associated timestamp within that interval relative. For example, FIG. 4 depicts an exemplary meal distribution 400 with respect to the time of day divided into 30 minute intervals, resulting in 48 different intervals over a 24-hour period. The corresponding meal probability for each interval may be determined by dividing the number of meal boluses classified or assigned to that respective interval by the total number of meal boluses. Thereafter, each meal or non-meal segment may be assigned a corresponding meal probability value based on the corresponding intervals overlapped or concurrent to a respective segment.” [0047]
In practice, particular length or duration may be shorter or longer than 10 minutes to achieve desired level of granularity…
“In one embodiment, meal bolus instances for a patient are grouped into 10 minute intervals, resulting in 144 different intervals over a 24-hour period. For example, for a meal segment 302 spanning from 11:30 AM to 12:30 PM, the server 106 may determine a meal probability associated with that meal segment 302 as a sum of the number of instances of meal boluses with the six ten minute intervals encompassed by the meal segment (e.g., the 11:30 AM-11:40 AM interval, the 11:40 AM-11:50 AM interval, the 11:50 AM-12:00 PM interval, and so on) and then dividing the resultant sum by the total number of instances of meal boluses in the patient's history. It should be noted that 10 minute intervals are depicted and described for purposes of explanation, but in practice, the meal probability intervals are not limited to any particular length or duration, and may be shorter or longer than 10 minutes to achieve a desired level of granularity.” [0048]
Interval can be any desired level of granularity (therefore, continuous)…
“In one embodiment, meal bolus instances for a patient are grouped into 10 minute intervals, resulting in 144 different intervals over a 24-hour period. For example, for a meal segment 302 spanning from 11:30 AM to 12:30 PM, the server 106 may determine a meal probability associated with that meal segment 302 as a sum of the number of instances of meal boluses with the six ten minute intervals encompassed by the meal segment (e.g., the 11:30 AM-11:40 AM interval, the 11:40 AM-11:50 AM interval, the 11:50 AM-12:00 PM interval, and so on) and then dividing the resultant sum by the total number of instances of meal boluses in the patient's history. It should be noted that 10 minute intervals are depicted and described for purposes of explanation, but in practice, the meal probability intervals are not limited to any particular length or duration, and may be shorter or longer than 10 minutes to achieve a desired level of granularity.” [0048]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Roy et al. the ability to use bolus probability density as a proxy for meal occurrence as taught by Abraham et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Abraham et al. who teaches the benefits of bolus information for determining meals associated with meal bolus.
The combined references teach determining a meal probability based on meal bolus. They do not explicitly teach continuous. However, Abraham et al. also teaches intervals to achieve a desired level (para. [0048]) and the benefits of continuous monitoring (para. [0005]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s filing to modify the combined references with the knowledge available to such an artisan that continuous measurements of meals and bolus could be made. This would have been known work in the field of endeavor prompting variations of it in the same field based on use of determining meals based on bolus information and would provide predictable results.
Regarding claim 2
The computer-implemented method of claim 1, wherein determining the dosage amount of insulin comprises determining, based on the blood glucose values, the bolus information, and the meal size propensity record, a timing of a meal ingested by the person, and selecting the dosage amount of insulin based on the determined timing of the meal.
Roy et al. teaches:
Using historical data, predict meal content and size for current time or anticipated future…
“In one or more embodiments, the personalized meal bolus dosage amount or control information associated with the closed-loop operating mode may be further adjusted or modified to account for the particular nutritional content of the meal (or meal type) being consumed. To facilitate meal type adjustments and reduce the user burden, a personalized meal library is created for an individual user based on his or her meal history, and recommended or suggested meals can be prioritized based on correlations to current contextual information (e.g., time of day, day of week, geographic location, etc.). Once sufficient historical meal data for a user exists, a personalized library of likely meal content can be created, with machine learning being utilized to predict the most likely meal content and serving sizes for a meal at the current time (or an anticipated meal in the future) based on the user's historical meal data and the current contextual situation (e.g., the current time of day, current day of week, current geographic location, etc.). A user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct. Based on the validation or modification of the predicted meal content, the user's historical meal data or prediction model can be dynamically updated in a manner that allows for the accuracy of the predicted meal content to improve over time.” [0037]
Regarding claim 3
The computer-implemented method of claim 1, further comprising:
determining the meal size propensity record based on a first time period, wherein the first time period corresponds to a beginning of ingestion of a meal.
Roy et al. teaches:
Example of initial period and providing meal size…
“The illustrated personalized bolus process 1100 allows a patient to define meal sizes qualitatively, such as, for example, small, medium, large, extra large, and/or the like. In exemplary embodiments, personalized bolus process 1100 is implemented once sufficient historical meal data and corresponding patient measurement data has been obtained and stored in the database 816. For example, for an initial setup monitoring period, the patient may estimate or input meal sizes when logging meal events while also manually interacting with a bolus wizard or other feature of the infusion device 102, 200, 502, 802 or a client application 808 on the client device 106, 806 to configure and administer boluses for the contemporaneous meal events. In this regard, during the initial setup monitoring period, the patient may define or designate meals with a particular qualitative meal size while also performing carbohydrate counting and providing indication of the estimated carbohydrate amounts associated with those meals. Once the elapsed duration of the monitoring period is greater than a threshold setup period (e.g., 2 weeks) or a sufficient number of meal events have been logged or otherwise documented, the personalized bolus process 1100 may be enabled.” [0125]
“The personalized bolus process 1100 begins by receiving or otherwise obtaining an indication of a meal size for the meal to be bolused (task 1102). In one or more exemplary embodiments, the personalized bolus process 1100 is initiated when the patient interacts with a bolus wizard feature of a particular application 608, 610, 808 used to administer meal boluses. For example, the client application 808 at the client device 806 may generate or otherwise provide a bolus wizard GUI display that includes selectable GUI elements corresponding to different qualitative meal sizes, with the patient manipulating the client device 806 to select the meal size to be assigned to the current meal. In yet other embodiments, the personalized bolus process 1100 is automatically initiated in response to detecting a meal event pattern (e.g., task 1010) to calculate a meal bolus dosage based on the predicted meal, where the input meal size corresponds to the predicted meal size based on the patient's historical meal data, as described above.” [0126]
Regarding claim 11
The computer-implemented method of claim 1, further comprising generating the bolus probability density by aggregating bolus events for the person that are included in the bolus information.
Roy et al. teaches:
Patients historical bolus dosages (plural) used to convert selected meal size into probable carbohydrate amount…
“FIGS. 14-15 depict one exemplary sequence of GUI displays that may be presented on an electronic device in accordance with one or more of the processes of FIGS. 9-13 described above. For example, FIG. 14 depicts a meal size GUI display 1400 that may be presented by the client application 808 on the computing device 806 to enable the patient to input the size of a meal to be bolused for. In some embodiments, the meal size GUI display 1400 is automatically presented at a predicted meal time or when the probability of a meal being consumed at the current time is greater than a threshold probability (e.g., greater than 75%). In other embodiments, the meal size GUI display 1400 is automatically presented in response to detecting a meal event pattern. In yet other embodiments, the meal size GUI display 1400 may be presented as part of a bolus wizard feature of the client application 808 in lieu of presenting a GUI display for inputting carbohydrate counts. The meal size GUI display 1400 includes a list 1402 of GUI elements corresponding to different qualitative meal sizes, which are selectable by a user to input or otherwise indicate the size of the meal to be bolused. As described above, the patient's historical meal data and potentially other factors or data (e.g., time of day, day of week, geographic location, historical glycemic response, historical bolus dosages, and the like) may be utilized to convert the selected meal size indicated by the patient into a probable carbohydrate amount to be bolused for.” [0161]
The combined references teach meal and using bolus. They also teach meal size. They do not teach using bolus probability density as a proxy for meal occurrence.
Abraham et al. also in the business of meal and using bolus teaches:
Meal based on bolus information…
“In exemplary embodiments, the events to be detected are meals occurring during monitoring of a patient's glucose levels and corresponding operation of an insulin infusion device. In this regard, a patient-specific meal detection model is employed to calculate or otherwise determine a metric indicative of whether or not a meal corresponding to a current analysis interval has occurred based on a subset of glucose measurement statistics that have been identified as predictive of or correlative to consumption of a meal by the patient based on the patient's historical meal and bolus information. For some patients, the meal detection model may also incorporate a meal probability metric for the current analysis interval that reflects the likelihood of the patient consuming a meal contemporaneously or concurrently to the current analysis interval based on the patient's historical meal distribution. Values for the predictive subset of glucose measurement statistics are calculated based on glucose measurement data corresponding to the current analysis interval and a meal probability metric for the current analysis interval is also determined, and the respective correlation coefficients from the meal detection model are applied to the current values for the predictive subset of glucose measurement statistics and the current meal probability to obtain a meal consumption metric value. The meal consumption metric value is then utilized to determine whether a meal has been consumed during the current analysis interval.” [0031]
Number of meal boluses per interval (#meal bolus/time period = meal bolus density) and meal based on the meal boluses/interval (bolus density)….
“The patient modeling process 200 also calculates or otherwise determines a meal probability associated with the respective segments based on the patient's bolus history (task 210). In this regard, the server 106 analyzes the meal bolus indications associated with the patient to determine a meal probability distribution for the patient that represents the relative probability of the patient consuming a meal at a particular time of day. In one embodiment, the server 106 divides the period of a day into a plurality of intervals, with a respective meal probability associated with each interval being determined based on the number of meal bolus indications having an associated timestamp within that interval relative. For example, FIG. 4 depicts an exemplary meal distribution 400 with respect to the time of day divided into 30 minute intervals, resulting in 48 different intervals over a 24-hour period. The corresponding meal probability for each interval may be determined by dividing the number of meal boluses classified or assigned to that respective interval by the total number of meal boluses. Thereafter, each meal or non-meal segment may be assigned a corresponding meal probability value based on the corresponding intervals overlapped or concurrent to a respective segment.” [0047]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use probability density for meal occurrence as taught by Abraham et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Abraham et al. who teaches the benefits of using bolus information to determine meal probability. The combined references benefit by using their bolus information for determining probability of a meal which benefits their forecasting of insulin needs.
The combined references teach bolus density. They also teach using historical boluses. They do not literally teach aggregating bolus.
Abraham et al. also in the business of meal and using bolus teaches:
Example of number of meal bolus (aggregating) into intervals (therefore, bolus probability density)…
“The patient modeling process 200 also calculates or otherwise determines a meal probability associated with the respective segments based on the patient's bolus history (task 210). In this regard, the server 106 analyzes the meal bolus indications associated with the patient to determine a meal probability distribution for the patient that represents the relative probability of the patient consuming a meal at a particular time of day. In one embodiment, the server 106 divides the period of a day into a plurality of intervals, with a respective meal probability associated with each interval being determined based on the number of meal bolus indications having an associated timestamp within that interval relative. For example, FIG. 4 depicts an exemplary meal distribution 400 with respect to the time of day divided into 30 minute intervals, resulting in 48 different intervals over a 24-hour period. The corresponding meal probability for each interval may be determined by dividing the number of meal boluses classified or assigned to that respective interval by the total number of meal boluses. Thereafter, each meal or non-meal segment may be assigned a corresponding meal probability value based on the corresponding intervals overlapped or concurrent to a respective segment.” [0047]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of Constantin et al. the ability to have a number of meal bolus (aggregate) as taught by Abraham et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Abraham et al. who teaches the benefits of determining meal bolus in a time interval, and this helps to determine the meal based on the bolus. The combined references benefits as they are also forecasting meals.
Regarding claim 23
The computer-implemented method of claim 1, further comprising:
receiving carbohydrate announcements for the person regarding the period of time; and
Roy et al. teaches:
Example of carbohydrate announcements for the time…
“Once the meal content is identified, the bolus dosage amount, bolus dosage schedule, or closed-loop control information may be modified or adjusted to account for the nutritional characteristics of the meal. For example, for a meal earlier in the day including relatively fast acting carbohydrates (e.g., a high carbohydrate breakfast), the bolus dosage amount may be increased (e.g., by scaling the carbohydrate amount by a value greater than one) while also automatically modifying the closed-loop control settings to suspend insulin delivery for at least a minimum suspension threshold amount of time. Conversely, for a relatively high fat meal late in the day (e.g., a high fat dinner), the bolus dosage amount may be decreased while also modifying the closed-loop control settings to increase insulin delivery for a postprandial time period (e.g., by temporarily decreasing the glucose target for the closed-loop control).” [0038]
generating the meal size propensity record based on the bolus information and the carbohydrate announcements, wherein the bolus information includes bolus events distributed within the period of time.
Example of determine bolus amount with meal size…
“FIG. 11 depicts an exemplary personalized bolus process 1100 suitable for implementation by an infusion device (or a control system associated therewith) to determine a bolus amount in a personalized manner that reduces the burden associated with carbohydrate counting. In this regard, personalized bolus process 1100 allows for the patient to qualitatively define the size, content, or other aspects of a meal, with the qualitative user input being converted into a corresponding quantitative representation based on the patient's historical data. The quantitative representation is then utilized to determine a meal bolus dosage without requiring carbohydrate counting or other manual calculations or estimations.” [0123]
Database (record) with patient historical meal data and measurement data, including meal size and bolus data and estimated carbohydrate amounts…
“The illustrated personalized bolus process 1100 allows a patient to define meal sizes qualitatively, such as, for example, small, medium, large, extra large, and/or the like. In exemplary embodiments, personalized bolus process 1100 is implemented once sufficient historical meal data and corresponding patient measurement data has been obtained and stored in the database 816. For example, for an initial setup monitoring period, the patient may estimate or input meal sizes when logging meal events while also manually interacting with a bolus wizard or other feature of the infusion device 102, 200, 502, 802 or a client application 808 on the client device 106, 806 to configure and administer boluses for the contemporaneous meal events. In this regard, during the initial setup monitoring period, the patient may define or designate meals with a particular qualitative meal size while also performing carbohydrate counting and providing indication of the estimated carbohydrate amounts associated with those meals. Once the elapsed duration of the monitoring period is greater than a threshold setup period (e.g., 2 weeks) or a sufficient number of meal events have been logged or otherwise documented, the personalized bolus process 1100 may be enabled.” [0125]
Example of bolus information during a day (within a period of time)…
“Once the meal content is identified, the bolus dosage amount, bolus dosage schedule, or closed-loop control information may be modified or adjusted to account for the nutritional characteristics of the meal. For example, for a meal earlier in the day including relatively fast acting carbohydrates (e.g., a high carbohydrate breakfast), the bolus dosage amount may be increased (e.g., by scaling the carbohydrate amount by a value greater than one) while also automatically modifying the closed-loop control settings to suspend insulin delivery for at least a minimum suspension threshold amount of time. Conversely, for a relatively high fat meal late in the day (e.g., a high fat dinner), the bolus dosage amount may be decreased while also modifying the closed-loop control settings to increase insulin delivery for a postprandial time period (e.g., by temporarily decreasing the glucose target for the closed-loop control).” [0038]
Regarding claim 26
The computer-implemented method of claim 3, further comprising:
receiving another meal size propensity record that is based on a second time period of different length than the first time period, and
Roy et al. teaches:
Example or updated over time…
“…A user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct. Based on the validation or modification of the predicted meal content, the user's historical meal data or prediction model can be dynamically updated in a manner that allows for the accuracy of the predicted meal content to improve over time.” [0037] Inherent with over time and improve accuracy is longer time.
Another example…
“It should be noted that the historical meal data utilized to determine the future meal probabilities may be filtered to account for the current day of the week, the current geographic location of the patient, or potentially other factors. For example, continuing the above example, there may be 70 days worth of patient history accounted for by the patient's historical meal data, but with only 10 of those days corresponding to the current day of the week. The historical meal data for those 10 days may then be utilized to determine meal probabilities for the current day of the week as described above.” [0098]
determining another amount of insulin for the person based on the other meal size propensity record.
Example of bolus based on historical response…
“… Based on the input activity, the bolus dosage or closed-loop controls may be adjusted to account for the user's predicted physiological response to the input activity based on the user's historical physiological response to that particular type of activity using the user's historical sensor glucose measurement data. Additional contextual information (e.g., time of day, day of week, geographic location, and the like) may also be incorporated to further refine the user's predicted physiological response. Bolus dosages or closed-loop control parameters may then be adjusted to account for the activities that the user is or is likely to be engaged in.” [0039]
Claims 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (12) in view of Pub. No. US 2019/0252079 to Constantin et al.
Regarding claim 17
The computer-implemented method of claim 1, further comprising taking into account the meal size propensity record before issuing an alert regarding the person based on a missed bolus event being associated with a meal, wherein a relatively lower threshold for the alert is used when a current meal probability is relatively higher, and a relatively higher threshold for the alert is used when a current meal probability is relatively lower.
Roy et al. teaches:
Example of alert…
“FIG. 6 depicts an exemplary embodiment of a pump control system 600 suitable for use as the pump control system 520 in FIG. 5 in accordance with one or more embodiments. The illustrated pump control system 600 includes, without limitation, a pump control module 602, a communications interface 604, and a data storage element (or memory) 606. The pump control module 602 is coupled to the communications interface 604 and the memory 606, and the pump control module 602 is suitably configured to support the operations, tasks, and/or processes described herein. In various embodiments, the pump control module 602 is also coupled to one or more user interface elements (e.g., user interface 230, 540) for receiving user inputs (e.g., target glucose values or other glucose thresholds) and providing notifications, alerts, or other therapy information to the user.” [0069]
The combined references teach alert and threshold. They do not teach details of alert with threshold.
Constantin et al. also in the business of threshold and alert teaches:
Alert/alarm based on thresholds and responsive to eating…
“A decision support system may use a variety of sources of information to determine guidance, such as patterns or other information relating to eating behavior (e.g., number of meals per day, meal size distribution across meals and snacks, size of treatments for hypoglycemic excursions, or the number of repeat treatments for a hypoglycemic event), insulin dose information (e.g., bolus and basal dose patterns, pump settings or injection patterns, number of boluses per day, amount of trend adjustment, pre-meal bolus patterns, behavior around correction boluses, number of correction boluses per day, behavior patterns (presence and accuracy of carb-counting, incidence of action or inaction in response to hyperglycemia or need for a correction bolus, conditions, thresholds or triggers for corrections (e.g., glucose level, combination of trend and level, food or other factors), awareness of insulin on board, timing of insulin, “pre-bolus” patterns before meals and duration thereof, errors in insulin delivery or therapeutic intervention, exercise timing, exercise duration, and exercise intensity, physiological response to activity), physiological factors (patterns in response to insulin or carbohydrates or other foods, tendency to “rebound” to a hyperglycemic state after a low glucose, impact of illness or medication on insulin sensitivity or glucose levels), responsiveness to guidance (time to acknowledge alert or alarm, behavior in response to alert or alarm (e.g., eating or sleeping or exercise), and glycemic outcomes (e.g., percentage of time below one or more glucose concentration thresholds (e.g., below 70 mg/dL, below 50 mg/dL), percentage of time above one or more glucose concentrations threshold (e.g. above 180 mg/DL, above 250 mg/DL), and number of events below or above one or more thresholds,) disease stage and/or treatment type (e.g., Type I honeymoon period, Type II prediabetic stage, Type II oral medication stage, Type II basal insulin stage), etc. Additional example inputs are described below.” [0304]
Warning based on eating or drinking patterns, where alert is given if food consumption exceeds expectations, you may need more insulin (therefore, lower threshold for insulin as more is needed based on dating/drinking pattern)…
“An insight may take the form of a personalized guidance message that has particular relevance to a presently-occurring event or pattern. The personalized guidance message may be based on information that is learned about the patient, which may be embodied or reflected by one or more models of the patient. In an example, a system may detect patterns that precede hypoglycemic and hyperglycemic events and alert the user with enough time to take action. In another example, a therapy adjustment may set a context-driven alarm: for example, when a therapy adjustment is made, such as an increase in basal rate, which may be determined to increase the risk of a night-time low glucose level, a low-glucose alert may be made more sensitive at night for a specified period of time, such as the next two weeks, or a personal guidance message reminding a user of the potential for a low night-time glucose level may be delivered each night, or more frequently or under a broader set of conditions than prior to the adjustment. In another example, it may be determined that a treatment decision or therapy event (e.g. forgetting to dose insulin before a meal, e.g. missed “pre-bolus”) may justify increased vigilance (e.g. checking of CGM data or awareness of a potential need to deliver therapy) during a time window following the decision or event, which may be communicated via a guidance message, or during the window a guidance message may be delivered under a broader set of conditions (e.g. lower threshold for providing event-driven guidance). In some examples, event-drive alerts may be set based on cumulative glycemic risk or glycemic exposure, e.g. food or caloric or carbohydrate consumption may be tracked and an insulin/glycemic imbalance may be detected, which may be communicated via personal guidance (“Your food or beverage consumption may have exceeded expectations”) or may form the basis for a personal guidance message (“You may need more insulin based on eating or drinking patterns.”) In some examples, a personal guidance message may provide a range of choices that are stratified by risk and rewards.” [0353]
“Exemplary outputs are as illustrated in FIG. 15, e.g., a recommendation of a type, amount, and timing of a meal bolus 235a, a recommendation of a type, amount, and timing of a correction bolus 235b, a recommendation of a type, amount, and timing of a meal 235c, a change in the user interface 235d, e.g., providing an alert or an alarm at a time determined to be effective for user, or a pre-event or situational decision 235e, e.g., a decision to be made before sleep, a meal, exercise, driving, activity, or the like. Other exemplary outputs include a permanent or temporary change to a basal rate setting, a recommendation for rescue carbs, or the like. Specific outputs, and the way the same may change according to the decision-support application/functionality, are discussed in the Outputs section below.” [0495]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use thresholds with alerts as taught by Constantin et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Constantine et al. who teaches the benefits of giving alerts for insulin based eating patterns.
The combined references teach alert/alarm for thresholds related to meals, such as hyperglycemic and hypoglycemic events. They do not explicitly teach lower threshold when meal probability is higher and higher threshold when meal probability is lower. However, one of ordinary skill in the art would recognize that thresholds would be different based on different meal probabilities.
It would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s filing to modify the combined references with the knowledge available to such an artisan that hyperglycemia and hypoglycemia are to be avoided and can be controlled by meals. This would have been known work in the field of endeavor prompting variations of it in the same field based on use of preventing medical events caused by meals and insulin would provide predictable results.
Regarding claim 19
The computer-implemented method of claim 17, wherein taking into account the meal size propensity record comprises reducing a threshold for associating the missed bolus event with the meal.
Roy et al. teaches:
Example of alert…
“FIG. 6 depicts an exemplary embodiment of a pump control system 600 suitable for use as the pump control system 520 in FIG. 5 in accordance with one or more embodiments. The illustrated pump control system 600 includes, without limitation, a pump control module 602, a communications interface 604, and a data storage element (or memory) 606. The pump control module 602 is coupled to the communications interface 604 and the memory 606, and the pump control module 602 is suitably configured to support the operations, tasks, and/or processes described herein. In various embodiments, the pump control module 602 is also coupled to one or more user interface elements (e.g., user interface 230, 540) for receiving user inputs (e.g., target glucose values or other glucose thresholds) and providing notifications, alerts, or other therapy information to the user.” [0069]
The combined references teach alert and threshold. They do not teach details reducing a threshold with missed bolus.
Constantin et al. also in the business of threshold and alert teaches:
Alert/alarm based on thresholds and responsive to eating…
“A decision support system may use a variety of sources of information to determine guidance, such as patterns or other information relating to eating behavior (e.g., number of meals per day, meal size distribution across meals and snacks, size of treatments for hypoglycemic excursions, or the number of repeat treatments for a hypoglycemic event), insulin dose information (e.g., bolus and basal dose patterns, pump settings or injection patterns, number of boluses per day, amount of trend adjustment, pre-meal bolus patterns, behavior around correction boluses, number of correction boluses per day, behavior patterns (presence and accuracy of carb-counting, incidence of action or inaction in response to hyperglycemia or need for a correction bolus, conditions, thresholds or triggers for corrections (e.g., glucose level, combination of trend and level, food or other factors), awareness of insulin on board, timing of insulin, “pre-bolus” patterns before meals and duration thereof, errors in insulin delivery or therapeutic intervention, exercise timing, exercise duration, and exercise intensity, physiological response to activity), physiological factors (patterns in response to insulin or carbohydrates or other foods, tendency to “rebound” to a hyperglycemic state after a low glucose, impact of illness or medication on insulin sensitivity or glucose levels), responsiveness to guidance (time to acknowledge alert or alarm, behavior in response to alert or alarm (e.g., eating or sleeping or exercise), and glycemic outcomes (e.g., percentage of time below one or more glucose concentration thresholds (e.g., below 70 mg/dL, below 50 mg/dL), percentage of time above one or more glucose concentrations threshold (e.g. above 180 mg/DL, above 250 mg/DL), and number of events below or above one or more thresholds,) disease stage and/or treatment type (e.g., Type I honeymoon period, Type II prediabetic stage, Type II oral medication stage, Type II basal insulin stage), etc. Additional example inputs are described below.” [0304]
Warning based on eating or drinking patterns, where alert is given if food consumption exceeds expectations, you may need more insulin (therefore, lower threshold for insulin as more is needed based on dating/drinking pattern)…
“An insight may take the form of a personalized guidance message that has articular relevance to a presently-occurring event or pattern. The personalized guidance message may be based on information that is learned about the patient, which may be embodied or reflected by one or more models of the patient. In an example, a system may detect patterns that precede hypoglycemic and hyperglycemic events and alert the user with enough time to take action. In another example, a therapy adjustment may set a context-driven alarm: for example, when a therapy adjustment is made, such as an increase in basal rate, which may be determined to increase the risk of a night-time low glucose level, a low-glucose alert may be made more sensitive at night for a specified period of time, such as the next two weeks, or a personal guidance message reminding a user of the potential for a low night-time glucose level may be delivered each night, or more frequently or under a broader set of conditions than prior to the adjustment. In another example, it may be determined that a treatment decision or therapy event (e.g. forgetting to dose insulin before a meal, e.g. missed “pre-bolus”) may justify increased vigilance (e.g. checking of CGM data or awareness of a potential need to deliver therapy) during a time window following the decision or event, which may be communicated via a guidance message, or during the window a guidance message may be delivered under a broader set of conditions (e.g. lower threshold for providing event-driven guidance). In some examples, event-drive alerts may be set based on cumulative glycemic risk or glycemic exposure, e.g. food or caloric or carbohydrate consumption may be tracked and an insulin/glycemic imbalance may be detected, which may be communicated via personal guidance (“Your food or beverage consumption may have exceeded expectations”) or may form the basis for a personal guidance message (“You may need more insulin based on eating or drinking patterns.”) In some examples, a personal guidance message may provide a range of choices that are stratified by risk and rewards.” [0353]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to adjust insulin based on eating patterns as taught by Constantin et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Constantine et al. who teaches the benefits of adjusting insulin based on hyperglycemic events.
The combined references teach alert/alarm for thresholds related to meals, such as hyperglycemic and hypoglycemic events. They do not explicitly teach lower threshold with missed bolus. However, one of ordinary skill in the art would recognize that thresholds would be different based on hyperglycemic events that could occur with missed bolus.
It would have been obvious to one of ordinary skill in the art before the effective filing date of Applicant’s filing to modify the combined references with the knowledge available to such an artisan that hyperglycemia and hypoglycemia are to be avoided and can be controlled by meals and insulin. This would have been known work in the field of endeavor prompting variations of it in the same field based on use of preventing medical events caused by meals and would provide predictable results.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (13) above in further view of CA 3001448 to Stahl.
Regarding claim 18
The computer-implemented method of claim 17, wherein taking into account the meal size propensity record comprises changing a threshold for a feature in a machine-learning classifier based on a kernel smoothed density estimate in the meal size propensity record.
Roy et al. teaches:
Example of machine learning…
“… Once sufficient historical meal data for a user exists, a personalized library of likely meal content can be created, with machine learning being utilized to predict the most likely meal content and serving sizes for a meal at the current time (or an anticipated meal in the future) based on the user's historical meal data and the current contextual situation (e.g., the current time of day, current day of week, current geographic location, etc.). A user notification may be provided that includes or otherwise indicates the predicted meal content and size to the user (or an ordered listing of the most likely combinations of meal content and sizes), thereby allowing the user to quickly and conveniently confirm the meal content and size, and without any carbohydrate counting or browsing a list or library of meals when the prediction is correct. Based on the validation or modification of the predicted meal content, the user's historical meal data or prediction model can be dynamically updated in a manner that allows for the accuracy of the predicted meal content to improve over time.” [0037]
The combined references teach meal size and threshold. They do not teach kernel smoothed density estimate.
Stahl also in the business of insulin effects teaches:
Insulin action from different time sections…
“In an embodiment of the present invention, the insulin action can be estimated from a record including N different sections of combined insulin dose and glucose data from an individual. An example of collected data can be seen in Fig. 1. These data sections may represent different time frames, e.g. each section represents a specific time section of the day and the entire record covers such sections from couple of weeks or months of data.” (pg. 13, 2nd para.)
A black-box Finite Impulse Response (FIR) model is considered to describe the insulin action, allowing for heterogeneous effects of the insulin action across the glucose range, i.e., higher or lower glucose-lowering effect depending on the current glucose level….” (pg.13, para. 3)
Using kernel to estimate the model based on sampling…
“The sampling interval is generally five minutes, but other sampling schemes may also be considered. To estimate the model, e.g., locally-weighted least squares using a quadratic Epaneichnikov kernel or some other kernel may be employed.” (pg. 14, top para)
“In order to keep the estimate smooth, e.g., second-order regularization may also be considered, utilizing e.g. a Gaussian prior for Gb. To reduce the model size, the parameters may be regularized by the 1-norm. To fulfill the physiological requirements of glucose-lowering response to insulin, the parameters are constrained to non-positive numbers, and the start and end of the insulin action are enforced to zero…” (pg. 14, second para.)
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use a kernel smooth density estimate as taught by Stahl since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Stahl who teaches the benefits of smoothing data for analysis. The combined references benefit by smoothing as the smoothing aids in threshold analysis of glycemic events.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over the combined references in section (12) above in further view of Pub. No. US 2021/0060246 to Weydt et al.
Regarding claim 25
The computer-implemented method of claim 23, further comprising receiving a gesture of the person with diabetes, wherein generating the meal size propensity record is further based on the gesture.
Constantin et al. teaches diabetes. They do not teach gesture.
Weydt et al. also in the business of diabetes teaches:
Additional food (meal size) based on additional hand movement (gesture)…
“In some cases, one or more processors 28 may determine the amount of insulin to take and timing at which to take the insulin based on a prediction of what patient 12 will eat. However, patient 12 may add on “tag along” foods, such as desert or drinks. One or more processors 28 may determine, based on movement detected by wearable device 22, whether patient 12 has already injected himself or herself with insulin using injection device 30 to ensure that patient 12 does not inject himself or herself more than once. Also, one or more processors 28 may determine whether patient 12 is having additional food not accounted for (e.g., based on additional hand movements beyond those expected for a basic meal) to adjust the amount of insulin the patient is to take.” [0125]
It would have been obvious to one of ordinary skill in the art before the effective filing date to include in the method and system of the combined references the ability to use gestures as taught by Weydt et al. since the claimed invention is merely a combination of old elements and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Further motivation is provided by Weydt et al. who teaches the benefits of using gestures for determining meal size and the combined references benefit as this improves compliance with recording meal information.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KENNETH BARTLEY whose telephone number is (571)272-5230. The examiner can normally be reached Mon-Fri: 7:30 - 4:00 EST.
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, SHAHID MERCHANT can be reached at (571) 270-1360. 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.
/KENNETH BARTLEY/Primary Examiner, Art Unit 3684