Associating a designated user with a medicament delivery device

§102 §103

DETAILED ACTION This action is in reference to the communication filed on 12 MAY 2026. Amendments to claims 16-21, 23. 26-28, 30 entered and considered. Claims 16-30 are present and have been examined. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 16-19, 21-25 is/are rejected under 35 U.S.C. 102a1 as being anticipated by Brukalo et al (US 20140113553 A1, hereinafter Brukalo). In reference to claim 16, 27: Brukalo teaches: A method of a receiver of associating a designated user with a medicament delivery device configured to communicate a medicament delivery event wirelessly to the receiver (at least [fig 1, 2 and related text], comprising: and a receiver configured toa associate a designated user with a medicament delivery device configured to communicate a medicament delivery event wireless to the receiver, the receiver comprising a processing unit and a memory (at least [fig 1, 2 and related text] , said memory containing instructions operable by said processing unit whereby the receiver is operative to: receiving a wireless signal identifying a medicament delivery device communicating a medicament delivery event occurring (at least [0064] “Remote controller 200 can send commands to infusion pump 300 to dispense a fluid or medication for a pre-determined time period, rate, and/or volume. In one exemplary embodiment, a user may select from a menu of basal programs that have been programmed on infusion pump 300. In another embodiment, the user may more specifically set a basal rate, a bolus dose, and a combination thereof may be programmed as commands to infusion pump 300 from remote controller 200. Remote controller 200 can receive data from infusion pump 300 such as the status of the dispensing of medication (e.g. the dispense rate, amount of medication remaining in infusion pump 300, or the proportion of medication delivered based on the amount programmed).”); acquiring information indicating whether or not at least one neighboring receiver also has received a wireless signal identifying said medicament delivery device communicating the medicament delivery event, such that the medicament delivery event of the medicament delivery device was registered with the at least one neighboring receiver (at least [fig 12 and related text including [0074] “Confirm 642 is a command that allows the user to confirm RF connection between infusion pump 300 and a paired device, such as remote controller 200. If a pairing search is under way, confirm 642 displays a cancel command, in case the user wants to cancel the pairing search. If confirm 642 displays a confirm command, and it is not executed by the user, the pairing between infusion pump 300 and remote controller 200 is rejected. This allows a user to reject pairing with the wrong device, such as someone else's infusion pump.” i.e. ); and if not: determining that the identified medicament delivery device was used by the designated user for causing the medicament delivery event (at least [0062] “Both remote controller 200 and infusion pump 300 have a unique identification code embedded in their respective first RF module 218 and second RF module 322. This is desirable because under certain conditions, a second user with a second infusion pump 300 may be in close proximity to the first user. It would be undesirable for the first user's remote controller 200 to communicate with the second user's infusion pump 300. In order to avoid such a scenario, a user must initiate a pairing protocol before using infusion pump 300 for the first time.”). In reference to claim 17, 28: Brukalo further teaches: wherein if the acquired information indicates that a wireless signal identifying said medicament delivery device has been received at said at least one neighboring receiver, the method further comprises: requesting a confirmation from the designated user indicating whether or not the user triggered the medicament delivery event, wherein it is determined that the identified medicament delivery device was used by the designated user for causing the medicament delivery event if a confirmation is received from the user in response to the request (at least [fig 7 and related text] “Once a device is found, remote setup screen 634 is displayed, the channel over which RF communication occurs is displayed in channel 638, and the user is prompted to confirm paired remote 640 using confirm 642. Once paired remote 640 is confirmed using confirm 642, remote setup screen 644 is displayed. Remote setup screen 644 includes paired remote 646 and next 648. By highlighting next 648 and pressing second OK button 314, display 316 displays local infusion pump home screen 650.”). In reference to claim 18, 29: Brukalo further teaches: wherein the requesting and receiving of the confirmation is affected over a user interface of the receiver (at least [fig 7 and related text] “Once a device is found, remote setup screen 634 is displayed, the channel over which RF communication occurs is displayed in channel 638, and the user is prompted to confirm paired remote 640 using confirm 642. Once paired remote 640 is confirmed using confirm 642, remote setup screen 644 is displayed. Remote setup screen 644 includes paired remote 646 and next 648. By highlighting next 648 and pressing second OK button 314, display 316 displays local infusion pump home screen 650.”) In reference to claim 19: Brukalo the received confirmation further comprising an identifier of the medicament delivery device for which the designated user triggered the medicament delivery event (at least [fig 7 and related text] “Once paired remote 640 is confirmed using confirm 642, remote setup screen 644 is displayed. Remote setup screen 644 includes paired remote 646 and next 648. By highlighting next 648 and pressing second OK button 314, display 316 displays local infusion pump home screen 650. Since infusion pump 300 is now paired with remote controller 200, remote control icon 652 is displayed. When remote control icon 652 is displayed, it indicates that RF is enabled, infusion pump 300 is paired with remote controller 200, and that infusion pump 300 is ready to receive commands from remote controller 200. “ – paired remote 646 includes the identifier/serial of the device, see also fig 1 and related text where elements 200/300 show a verification pairing with the numerical serial identifier) In reference to claim 21: Brukalo further teaches: if the acquired information indicates that a wireless signal identifying said medicament delivery device has been received at said at least one neighboring receiver: informing the neighbouring device of the received confirmation (at least [fig 12 and related text including [074] “Confirm 642 is a command that allows the user to confirm RF connection between infusion pump 300 and a paired device, such as remote controller 200. If a pairing search is under way, confirm 642 displays a cancel command, in case the user wants to cancel the pairing search. If confirm 642 displays a confirm command, and it is not executed by the user, the pairing between infusion pump 300 and remote controller 200 is rejected. This allows a user to reject pairing with the wrong device, such as someone else's infusion pump.” i.e. notification). In reference to claim 22, 30: Brukalo teaches: A method of a receiver of associating a designated user with a medicament delivery device configured to communicate a medicament delivery event wirelessly to the receiver (at least [figs 1, 2, and related text], comprising: and a receiver configured toa associate a designated user with a medicament delivery device configured to communicate a medicament delivery event wireless to the receiver, the receiver comprising a processing unit and a memory (at least [fig 1, 2 and related text] , said memory containing instructions operable by said processing unit whereby the receiver is operative to: receiving a wireless signal identifying a medicament delivery device communicating a medicament delivery event (at least [0064] “Remote controller 200 can send commands to infusion pump 300 to dispense a fluid or medication for a pre-determined time period, rate, and/or volume. In one exemplary embodiment, a user may select from a menu of basal programs that have been programmed on infusion pump 300. In another embodiment, the user may more specifically set a basal rate, a bolus dose, and a combination thereof may be programmed as commands to infusion pump 300 from remote controller 200. Remote controller 200 can receive data from infusion pump 300 such as the status of the dispensing of medication (e.g. the dispense rate, amount of medication remaining in infusion pump 300, or the proportion of medication delivered based on the amount programmed).”); determining whether or not the identification of the medicament delivery device complies with a predetermined identification number pattern (at least [fig 6 and related text] “Paired infusion pump 552 includes the serial number of the paired infusion pump. After verifying that paired infusion pump 552 is correct, accept command 554 is highlighted and selected.” At [0062] “. When initiating the pairing protocol, remote controller 200 and infusion pump 300 exchange their unique identification code (e.g. serial number). In all subsequent wireless communications, the correct unique identification code must be established before exchanging data.” At [068] “ Device "pairing" is a process in which a master (remote controller 200) learns who its slave is (an infusion pump) and in which the slave (infusion pump) learns who its master (remote controller) is. All devices utilize suitable information identification, such as, for example, a fixed device-type serial number address, sound, or optical identifier. Preferably, the remote controller 200 holds one serial number of the infusion pump 300 that is paired with the controller 200; the infusion pump 300 stores one single master remote controller's serial number from which it will accept commands; and only one remote controller 200 and one infusion pump 300 may be paired at a time.”); and if so: determining that the identified medicament delivery device was used by the designated user for causing the medicament delivery event (at least [0062] “Both remote controller 200 and infusion pump 300 have a unique identification code embedded in their respective first RF module 218 and second RF module 322. This is desirable because under certain conditions, a second user with a second infusion pump 300 may be in close proximity to the first user. It would be undesirable for the first user's remote controller 200 to communicate with the second user's infusion pump 300. In order to avoid such a scenario, a user must initiate a pairing protocol before using infusion pump 300 for the first time.”). In reference to claim 23: Brukalo further teaches: the identification of the medicament delivery device being determined to comply with a predetermined identification number pattern if the identification of the medicament delivery device follows a predetermined identification number series, comprising a plurality of predetermined identification number patterns (at least [068] “ Device "pairing" is a process in which a master (remote controller 200) learns who its slave is (an infusion pump) and in which the slave (infusion pump) learns who its master (remote controller) is. All devices utilize suitable information identification, such as, for example, a fixed device-type serial number address, sound, or optical identifier. Preferably, the remote controller 200 holds one serial number of the infusion pump 300 that is paired with the controller 200; the infusion pump 300 stores one single master remote controller's serial number from which it will accept commands; and only one remote controller 200 and one infusion pump 300 may be paired at a time. “ at [fig 10 and related text] “ Remote infusion pump home screen 558 includes remote infusion pump home screen 586, indicating the serial number or friendly name of infusion pump 300 with which remote controller 200 is paired. By default, remote infusion pump home screen 586 includes the serial number of infusion pump 300 with which remote controller 200 is paired. The serial number displayed on remote infusion pump home screen 586 can be checked against the serial number printed on the back of infusion pump 300.”). In reference to claim 24: Brukalo further teaches: the identification of the medicament delivery device being determined to comply with a predetermined identification number pattern if said identification has been pre-registered with the receiver (at least [068] “ Device "pairing" is a process in which a master (remote controller 200) learns who its slave is (an infusion pump) and in which the slave (infusion pump) learns who its master (remote controller) is. All devices utilize suitable information identification, such as, for example, a fixed device-type serial number address, sound, or optical identifier. Preferably, the remote controller 200 holds one serial number of the infusion pump 300 that is paired with the controller 200; the infusion pump 300 stores one single master remote controller's serial number from which it will accept commands; and only one remote controller 200 and one infusion pump 300 may be paired at a time. “) In reference to claim 25: Brukalo further teaches: A computer program comprising computer-executable instructions for causing a receiver to perform steps recited in claim 16 when the computer-executable instructions are executed on a processing unit included in the receiver (at least [fig 5 and related text] “Remote controller 200 is schematically shown in FIG. 5 to further include the following functional components such as a first display (DIS) 202, a first navigational buttons (NAV) 216, a first radio frequency module (RF) 218, a blood glucose measurement (BGM) module 220, a first battery (BAT) 222, a wired communication port (COM) 224, a first alarm (AL) 226, a first microprocessor (MP) 228, a memory portion (MEM) 230, and a memory chip port (MCP) 232 as shown in FIG. 5. “). In reference to claim 30: Brukalo teaches: A receiver configured to of associate a designated user with a medicament delivery device configured to communicate a medicament delivery event wirelessly to the receiver (at least [figs 1, 2, and related text], comprising: and a receiver configured toa associate a designated user with a medicament delivery device configured to communicate a medicament delivery event wireless to the receiver, the receiver comprising a processing unit and a memory (at least [fig 1, 2 and related text] , said memory containing instructions operable by said processing unit whereby the receiver is operative to: receivea wireless signal identifying a medicament delivery device communicating a medicament delivery event (at least [0064] “Remote controller 200 can send commands to infusion pump 300 to dispense a fluid or medication for a pre-determined time period, rate, and/or volume. In one exemplary embodiment, a user may select from a menu of basal programs that have been programmed on infusion pump 300. In another embodiment, the user may more specifically set a basal rate, a bolus dose, and a combination thereof may be programmed as commands to infusion pump 300 from remote controller 200. Remote controller 200 can receive data from infusion pump 300 such as the status of the dispensing of medication (e.g. the dispense rate, amount of medication remaining in infusion pump 300, or the proportion of medication delivered based on the amount programmed).”); determine whether or not the identification of the medicament delivery device complies with a predetermined identification number pattern based on if it follows a predetermined identification number series comprising a plurality of predetermined identification number patterns (at least [fig 6 and related text] “Paired infusion pump 552 includes the serial number of the paired infusion pump. After verifying that paired infusion pump 552 is correct, accept command 554 is highlighted and selected.” At [0062] “. When initiating the pairing protocol, remote controller 200 and infusion pump 300 exchange their unique identification code (e.g. serial number). In all subsequent wireless communications, the correct unique identification code must be established before exchanging data.” At [068] “ Device "pairing" is a process in which a master (remote controller 200) learns who its slave is (an infusion pump) and in which the slave (infusion pump) learns who its master (remote controller) is. All devices utilize suitable information identification, such as, for example, a fixed device-type serial number address, sound, or optical identifier. Preferably, the remote controller 200 holds one serial number of the infusion pump 300 that is paired with the controller 200; the infusion pump 300 stores one single master remote controller's serial number from which it will accept commands; and only one remote controller 200 and one infusion pump 300 may be paired at a time.”); and if so: determining that the identified medicament delivery device was used by the designated user for causing the medicament delivery event (at least [0062] “Both remote controller 200 and infusion pump 300 have a unique identification code embedded in their respective first RF module 218 and second RF module 322. This is desirable because under certain conditions, a second user with a second infusion pump 300 may be in close proximity to the first user. It would be undesirable for the first user's remote controller 200 to communicate with the second user's infusion pump 300. In order to avoid such a scenario, a user must initiate a pairing protocol before using infusion pump 300 for the first time.”). 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. Claim(s) 20, 26 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brukalo in view of Finney (US 20210377726 A1). In reference to claim 20: Brukalo teaches all the limitations above. However, Brukalo does not specifically teach changing delivery schedules. Finney further teaches: if wireless signals are received identifying a plurality of medicament delivery devices communicating a medicament delivery event: providing a recommendation to the designated user to change medicament delivery schedule with an explicitly schedule proposal wherein the designated user avoids triggering medicament delivery events at a same or similar time as a plurality of users, wherein the recommendation is provided to the user over the user interface of the receiver (at least [0109, 0122] “For example, the use of time-varying broadcasts and cryptographic signatures helps reduce the risk of a patient's device associating with the wrong device. This also protects against a malicious actor trying to force a patient's non-medical device 606 to associate with another device instead of the medical device 602/604. An attacker not possessing advance knowledge of the secret keys within the medical device 602/604 cannot generate false messages that would be accepted by the patient's device. (An attacker could retransmit valid messages received via eavesdropping at a later time; the use of timestamps referenced to a shared time reference, such as an absolute clock, protects against this).” – i.e. “time varying broadcasts” would prevent the issue). Brukalo and Finney are analogous references directed at improving the connections between receiver devices and medical devices. As such, the solution of time-varying broadcasts as taught by Finney would have been an obvious one to combat the problems of cross pairing as identified as common to such medical devices as identified in both Brukalo and Finney. The time varying taught by Finney would not change the functioning of the pairing process in Brukalo, and would merely provide the option to improve said transmissions vital to provide medication delivery effectively. In reference to claim 26: Finney teaches: A non-transitory computer program product comprising a computer readable medium, the computer readable medium having the computer program according to claim 25 embodied thereon (at least [0027, 066]). One of ordinary skill in the art would have found the computer program product taught by Finney to be an equivalent substation for the computer program product taught by Brukalo as a means to execute the claimed steps. Relevant Prior Art The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 2021/0150462, to Leitermann discloses communications between neighboring receiving devices associated with devices associated with inventory items. US 20210201642, to Wicks, discloses using RFID tags associated with merchandise and in communication with more than one receiver in a retail environment. US 20210085868 to Lim discloses a means of pairing a plurality of devices for diabetes management to a plurality of other devices. Response to Arguments Applicant’s remarks as filed on 12 MAY 2026 have been fully considered. Applicant’s amendments regarding the 101 rejection are noted; the amendments presented negate the rejection and as such it is withdrawn. Applicant turns to the prior art rejection on page 6, with a recitation of exemplary claim 16 on page 7. Examiner does not find that the amendments to claim 16 overcome the prior art rejection, as the reference teaches registering the delivery device with the receiver and the amended portion of claim 16 does not appear to narrow that step effectively. As such Applicant’s remarks regarding claims 17-19, 21, 25 are not found persuasive. Applicant discusses claim 22 on page 7. Examiner finds the citations to the relevant paragraphs helpful for context, but respectfully submits Applicant is attempting to impart the specification into the claims. Applicant is encouraged to amend to incorporate the elements of [057, 058] into the claim language. Brukalo teaches a serial number identified to a device, but does not allow pairing if there is not a match with the “specified” information. Examiner finds similarly with regard to amended claim 23, and claim 30 on pages 8, 9. Again, the references to the specification are found helpful for context, but Brukalo does not limit the formatting of the serial number and teaches that a match must be present among the varied devices in range. Examiner encourages Applicant to amend the claims accordingly. As per the remarks regarding claim 20, Examiner notes that these limitations as amended appear to recite intended use/descriptive matter about the change in the schedule, in that the avoidance of a triggering is largely descriptive rather than holding patentable weight. Applicant’s remarks regarding claim 26 are found moot in view of the discussion of claim 16 above. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KATHERINE KOLOSOWSKI-GAGER whose telephone number is (571)270-5920. The examiner can normally be reached Monday - Friday. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Mamon Obeid can be reached at 571-270-1813. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /KATHERINE . KOLOSOWSKI-GAGER/ Primary Examiner Art Unit 3687 /KATHERINE KOLOSOWSKI-GAGER/Primary Examiner, Art Unit 3687