Prosecution Insights
Last updated: July 17, 2026
Application No. 17/365,093

AUTHENTICATION TO MEDICAL DEVICE VIA MOBILE APPLICATION

Non-Final OA §103§112
Filed
Jul 01, 2021
Examiner
AFRIFA-KYEI, ANTHONY D
Art Unit
2686
Tech Center
2600 — Communications
Assignee
Mozarc Medical US LLC
OA Round
9 (Non-Final)
65%
Grant Probability
Moderate
9-10
OA Rounds
0m
Est. Remaining
78%
With Interview

Examiner Intelligence

Grants 65% of resolved cases
65%
Career Allowance Rate
358 granted / 553 resolved
+2.7% vs TC avg
Moderate +13% lift
Without
With
+13.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 11m
Avg Prosecution
31 currently pending
Career history
589
Total Applications
across all art units

Statute-Specific Performance

§101
0.7%
-39.3% vs TC avg
§103
94.4%
+54.4% vs TC avg
§102
1.5%
-38.5% vs TC avg
§112
1.3%
-38.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 553 resolved cases

Office Action

§103 §112
Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis 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. Status of Claims In the amendment filed on February 3rd, 2026, claims 1-5, 8-10, 32, 35, 36, and 41 have been amended, claims 6, 7, 11-31, 33, 34 and 42 have been cancelled and new claims 43-46 has been added. Therefore, claims 1-5, 8-10, 32, 35-41 and 43-46 are pending for examination. Claim Rejections - 35 USC § 112 The following is a quotation of the first paragraph of 35 U.S.C. 112(a): (a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention. The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112: The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention. Claims 1-5, 8-10, 32, 35-41, 43-46 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 has been amended to now read as, “A dialysis system, comprising: a dialysis apparatus configured to filter toxins from at least one bodily fluid of a patient; a transceiver; a processor; a display; and a memory wherein instructions are encoded within the memory to instruct the processor to: render, on the display, a graphical user interface (GUI) configured to permit a user to interact with the dialysis apparatus via at least one user input associated with a plurality of functions of the dialysis apparatus, the plurality of functions being associated with effectuating treatment of the patient; restrict access to at least one function of the plurality of functions of the dialysis apparatus to at least one authorized user; receive, via a secure link between the transceiver and a mobile device associated with a user, upon the user authenticating with an application loaded on the mobile device, cryptographic authentication information from the mobile device, the mobile device being distinct from the dialysis system; wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device; authenticate the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified; grant access, to the user, when the user has been authenticated, via the GUI presented on the display, to the at least one function for which access is restricted to the at least one authorized user; and modify operation of the dialysis apparatus based at least in part on the at least one user input controlling, via the user interface on the display, the at least one function of the dialysis apparatus to effectuate treatment of the patient according to the at least one user input.” The amended limitations, “wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device; authenticate the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified” are not supported or elaborated within the specifications. The specifications recite In any embodiment, the instructions can include receiving from a trusted certificate authority cryptographic certificates for one or more mobile devices, and storing the cryptographic certificates in the local database. [P-31] In any embodiment, the instructions can include receiving from the certificate authority a certificate revocation for a stored cryptographic certificate. [P-32] In any embodiment, authenticating the mobile device can include determining that the mobile device has a certificate issued by the trusted certificate authority and is not expired. The term "Bluetooth low energy (BLE)" refers to a wireless communication protocol that is similar to, but independent of, traditional Bluetooth, that permits devices to communicate over short distances with lower energy. Although BLE is independent of Bluetooth, the two protocols can be supported by a single device, and can use a single antenna.[P-33] The term "certificate authority" refers to a cloud or network-based service that issues cryptographic certificates. [P-56] A trusted certificate authority is a CA that a device trusts to provide valid certificates and certificate data. This could be a well-known public CA, or a special- purpose or local CA setup for a local network.[P-57] A "cryptographic certificate" refers a data structure that can be verified via cryptographic methods. For example, the cryptographic certificate can include a cryptographic key of a pre-determined size, which can be verified via a hash algorithm.[P-59] In block 368, the patient can operate a control to get the BLE/NFC certification for the machine. This control can be the control used for the actual authentication to the device, and can be used to initiate communication. In one example, the mobile application includes a certificate or other security key that can be used to cryptographically verify the identity of the mobile device. Following off-page connector 2, this certificate or security key can be provided via a technology such as BLE or NFC to the medical device for authentication of the mobile device, and consequently, authentication of the operator of the mobile device. Biomedical device authentication[P-105] In block 416, the user taps the mobile device against the NFC authenticator on the machine. As described above, this NFC authenticator could be indicated by a placard, an icon, or some other visual indicator representing the spot where the NFC or BLE authentication can take place. The user taps the mobile device against this spot, and the authentication proceeds. The medical device can then open an NFC or BLE session with the mobile device, and establish communication. Once the two devices have established, for example, a secure link, the medical device can retrieve from the mobile device the appropriate key or security token to authenticate. The medical device then cryptographically verifies this key or token, for example, using a previously provisioned certificate on the medical device[P-109] None of the cited passages recite or elaborate on the claimed limitations, “wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device; authenticate the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified” Thereby, the claimed disclosure is not supported by the specifications. Dependent claims 2-5, 8-10 are rejected for the same rationale. Claim 32 has been amended to now read as, “A method comprising: render, on a display of a dialysis apparatus, a graphical user interface (GUI) configured to permit a user to interact with the dialysis apparatus via at least one user input associated with a plurality of functions of the dialysis apparatus, the plurality of functions being associated with effectuating treatment of a patient; wherein the dialysis apparatus is configured to filter toxins from at least one bodily fluid of a patient; restricting access to one or more functions of the a plurality of functions of [[a]] the dialysis apparatus to at least one authorized user; receiving, via a secure link between a transceiver of the dialysis apparatus and a mobile device associated with a user, upon the user authenticating with an application loaded on the mobile device, cryptographic authentication information from the mobile device, the mobile device being distinct from the dialysis apparatus; wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application: cryptographically verifying the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device ;authenticating the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified; granting, to the user, when the user has been authenticated, access, via the GUI presented on the display, to the one or more functions for which access is restricted to the at least one authorized user; and modifying operation of the dialysis apparatus based at least in part on the at least one user input controlling, via the GUI on the display, the one or more functions of the dialysis apparatus to effectuate treatment of the patient according to the at least one user input.” The amended limitations, “wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device; authenticate the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified” are not supported or elaborated within the specifications. The specifications recite In any embodiment, the instructions can include receiving from a trusted certificate authority cryptographic certificates for one or more mobile devices, and storing the cryptographic certificates in the local database. [P-31] In any embodiment, the instructions can include receiving from the certificate authority a certificate revocation for a stored cryptographic certificate. [P-32] In any embodiment, authenticating the mobile device can include determining that the mobile device has a certificate issued by the trusted certificate authority and is not expired. The term "Bluetooth low energy (BLE)" refers to a wireless communication protocol that is similar to, but independent of, traditional Bluetooth, that permits devices to communicate over short distances with lower energy. Although BLE is independent of Bluetooth, the two protocols can be supported by a single device, and can use a single antenna.[P-33] The term "certificate authority" refers to a cloud or network-based service that issues cryptographic certificates. [P-56] A trusted certificate authority is a CA that a device trusts to provide valid certificates and certificate data. This could be a well-known public CA, or a special- purpose or local CA setup for a local network.[P-57] A "cryptographic certificate" refers a data structure that can be verified via cryptographic methods. For example, the cryptographic certificate can include a cryptographic key of a pre-determined size, which can be verified via a hash algorithm.[P-59] In block 368, the patient can operate a control to get the BLE/NFC certification for the machine. This control can be the control used for the actual authentication to the device, and can be used to initiate communication. In one example, the mobile application includes a certificate or other security key that can be used to cryptographically verify the identity of the mobile device. Following off-page connector 2, this certificate or security key can be provided via a technology such as BLE or NFC to the medical device for authentication of the mobile device, and consequently, authentication of the operator of the mobile device. Biomedical device authentication[P-105] In block 416, the user taps the mobile device against the NFC authenticator on the machine. As described above, this NFC authenticator could be indicated by a placard, an icon, or some other visual indicator representing the spot where the NFC or BLE authentication can take place. The user taps the mobile device against this spot, and the authentication proceeds. The medical device can then open an NFC or BLE session with the mobile device, and establish communication. Once the two devices have established, for example, a secure link, the medical device can retrieve from the mobile device the appropriate key or security token to authenticate. The medical device then cryptographically verifies this key or token, for example, using a previously provisioned certificate on the medical device[P-109] None of the cited passages recite or elaborate on the claimed limitations, “wherein the cryptographic authentication information comprises a cryptographic item associated with the mobile device that is configured to authenticate the mobile device and is different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device; authenticate the mobile device as being associated with the at least one authorized user based at least in part the cryptographic authentication information being cryptographically verified” Thereby, the claimed disclosure is not supported by the specifications. Dependent claims 35-41, 43-46 are rejected for the same rationale Claim Rejections - 35 USC § 103 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. Claim(s) 1-3, 8-10, 32, 35, 37, 38 and 41 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flakne et al. (WO 2020120061 A1) in view of Fukazawa et al. (JP 6652267 B1), Merics et al. (US 20210093764 A1) Maguire et al. (CA 2904619 A1) and Beatson et al. (US 20140365782 A1). In regards to claim 1, Flakne teaches a medical device, comprising a medical apparatus, a transceiver (for near field communication), a processor (to decode and process authentication information), and a memory (for storing authentication information) (Page 5, line 30-Page 6, line 9). Flakne further elaborates, the instructions are encoded within the memory to instruct the processor to determine that a mobile device has communicatively coupled to the transceiver, to authenticate the mobile device, and to grant access to one or more functions of the medical device if the authentication is successful (Page 4, lines 5-9; Page 7, line 21- Page 8, line 6). Flakne fails to teach communicating by the gateway by the transceiver to receive an indication that user-specific authentication information from a mobile device has communicatively coupled to the transceiver and has been authenticated by the gateway and authenticate a user of the mobile device upon the user-specific authentication information being verified; and grant access, to the user via a display of the medical device, to one or more functions of the medical device if when the user has been authenticated. Fukazawa on the other hand teaches communicating by the gateway by the transceiver to receive an indication that user-specific authentication information from a mobile device has communicatively coupled to the transceiver and has been authenticated by the gateway and authenticate a user of the mobile device upon the user-specific authentication information being verified (Page 19, Appendix 8), i.e. the remote medical assistance device is connected to a second storage device that stores in advance a user ID and a password of a user who can use a specific terminal, an attribute of the user ID, and a face image of the user ID in association with each other, At the time of login processing of a predetermined terminal (the gateway being the login portal). A face image of the user of the terminal and a user ID taken by the predetermined terminal are received. Acquiring a face image associated with the accepted user ID from the second storage device, performing face authentication on the accepted face image and the acquired face image. If the attribute of the received user ID is a specific medical worker, the password authentication is requested to the predetermined terminal after the face authentication is successful, and the login is permitted if the password authentication is successful. If the attribute of the user ID included in the received information is other than the specific medical worker, login is permitted after the face authentication has succeeded. Thereafter, granting access, to the user via a display of the medical device, to one or more functions of the medical device if when the user has been authenticated (Page 21, Appendix C1-D1), i.e. in response to a request from the second terminal and the connection-established first terminal, display information for displaying the medical care information on the screen of the first terminal is generated, after the user is authenticated. It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Fukazawa’s teaching with Flakne’s teaching in order to enable the secure access and transfer of medical data from one medical device to an authorized external device. Falkne modified fails to teach the medical device being a dialysis apparatus, as well as the authentication of the mobile device involving cryptographic authentication information configured to authenticate the mobile device. Merics on the other hand teaches a medical device such as a dialysis machine configured to filter toxins from at least one bodily fluid of a patient (Paragraphs 23, 24) A dialysate container 124 is connected to the dialysis machine 102 via a dialysate supply line 126. A drain line 128 and an ultrafiltration line 129 also extend from the dialysis machine 102. The dialysate supply line 126, the drain line 128, and the ultrafiltration line 129 are fluidly connected to the various dialysate components and dialysate lines inside the housing 103 of the dialysis machine 102 that form part of the dialysate circuit. During hemodialysis, the dialysate supply line 126 carries fresh dialysate from the dialysate container 124 to the portion of the dialysate circuit located inside the dialysis machine 102. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer 110, that form the dialysate circuit. As will be described below, as the dialysate passes through the dialyzer 110, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line 128. When ultrafiltration is performed during treatment, a combination of spent dialysate (described below) and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line 129.[P-23] The dialyzer 110 serves as a filter for the patient's blood. The dialysate passes through the dialyzer 110 along with the blood, as described above. A semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) within the dialyzer 110 separates blood and dialysate passing through the dialyzer 110. This arrangement allows the dialysate to collect toxins from the patient's blood. The filtered blood exiting the dialyzer 110 is returned to the patient. The dialysate exiting the dialyzer 110 includes toxins removed from the blood and is commonly referred to as “spent dialysate.” The spent dialysate is routed from the dialyzer 110 to a drain.[P-24] Merics further teaches the restriction to one or more functions of the plurality of functions of the dialysis machine to the authorized user, enabling the user to access the dialysis machine once the user’s mobile device and/or access card has been authenticated and verified via encryption authentication (Paragraphs 7, 30, 36, 37, 46, 48) Various implementations of the system described herein are described. For example, the biometric security module that is embedded on the secure access card may include the biometric sensor that obtains the biometric data from the requesting user and the biometric verification module that performs processing to verify the biometric data obtained from the requesting user. Alternatively, in another implementation, the biometric verification module is located remotely from the secure access card. After the biometric validation module verifies the biometric data in relation to the template biometric data of the authorized user, access to the dialysis machine is granted to the requesting user. The requesting user may be a service technician, and for which access granted to the requesting user includes access allowing the requesting user to service the dialysis machine and/or the requesting user may be a patient or caregiver of the patient, and for which access granted to the requesting user includes enabling the dialysis machine to obtain medical records of the patient. In an implementation, the dialysis machine receives a download over a network of a prescription of the patient for a treatment to be performed by the dialysis machine.[P-7] Additionally and/or alternatively, the dialysis machine 102 may include a network communication module 109. The network communication module 109 allows the dialysis system 100 to communicate with remote servers, computer systems, databases and/or other medical devices over a network such as a local area network (LAN) or the Internet. The network communication module 109 allows the dialysis system 100 to communicate with other medical devices, computer systems, servers, and/or databases associated with one or more medical facilities. The network communication module 109 may enable communication over the network using wired and/or wireless connections. For example, the network communication module 109 may enable communication using WiFi communication protocols and infrastructure and/or may enable communication using wireless mobile telecommunication networks. The system described herein may use appropriate encryption and security standards and protocols in connection with the transmission of sensitive and/or protected data in accordance with all statutory and regulatory requirements.[P-30] The operable range of the NFC initiator and NFC target may be in the order of inches (e.g., 0-6 inches). In some implementations, the transfer of data is initiated upon the NFC initiator and the NFC target making physical contact with each other. In some implementations, the NFC initiator and/or the NFC target can include a motion sensor (e.g., an accelerometer) to assist in identifying the occurrence of physical contact between the modules. It is noted that in other short-range communication protocol implementations, such as WiFi and/or Bluetooth, the operable range may be larger (e.g. 10 feet or more).[P-36] The NFC initiator is sometimes part of another electronic device such as a mobile phone, a computer, or as in this example, a medical device. The NFC initiator can have an independent power source or it can receive power from a power source that provides power to the electronic device. The NFC initiator can include a loop antenna that uses magnetic induction to generate an RF field.[P-37] For example, suppose that the patient associated with the secure access card 105, John Doe, has a medical condition that requires an atypical dialysis treatment. Perhaps John's treatment requires an abnormally low dialysate flow rate. The secure access card 105 is used to biometrically authenticate the user John Doe when the secure access card 105 is in proximity to the dialysis system 100, as further discussed elsewhere herein. After biometric proximity authentication, the dialysis system 100 receives the patient identification information from the secure access card 105, accesses remote data storage, and uses the received patient identification information to identify medical information related to John Doe. The medical information includes John Doe's medical history, treatment prescriptions, and treatment parameters; in particular, the treatment prescription includes instructions for causing the dialysis machine 102 to employ the abnormally low dialysate flow rate that John Doe requires. Such information is obtained (e.g. downloaded) and provided to the control unit 101, and the control unit 101 causes the appropriate treatment to be administered to John Doe. For example, the control unit 101 can cause the dialyzer 110 to operate a pump (e.g., a dialysate pump) such that the required dialysate flow rate is achieved.[P-46] After enrollment processing of the authorized user 401 by the enrollment module 410, an access-requesting user 401′ may request access to a medical device, such as the dialysis machine 102, by presenting the secure access card 102, which access request requires biometric acquisition and verification by the authentication module 420 according to an implementation of the system described herein. The authentication by the authentication module 420 may be initiated when the requesting user 401′ brings the secure access card 102 into proximity of the dialysis machine 102. At that time, the secure access card 102 may pair with the dialysis machine 102, and information, such as ID information 402, associated with the authorized user 401 of the secure access card 102 may be transmitted. An embedded biometric sensor 422 of the secure access card 102, such as the fingerprint sensor 220, may be activated and a biometric/fingerprint scan of the user 401′ acquired using the embedded biometric sensor 422. Identifying features of the biometric data scanned by the sensor 422 are extracted at a feature extraction module 424 that may, for example, be performed on the secure access card 105. Using the ID information 402, the biometric template data for the authorized user 401 that has been previously stored is obtained from the database 430. The stored biometric data is matched to the scanned/acquired biometric data in a verification module 426. In various implementations, the verification module 426 may be located/processed on the secure access card 105, at the dialysis machine 102, and/or at a remote site, and a result 440, e.g. either a positive or negative match, is determined. The result 440 may be used to determine whether access to the dialysis machine 102 by the requesting user 401′ is granted or denied.[P-48] Here we see Merics teaching access to a dialysis machine and manipulate said machine, upon authentication using encryption protocols to validate a mobile device that may contain access card key credentials. Merics then teaches the display, a graphical user interface configured to permit a user interact with the dialysis system via at least one user input associated with a plurality of functions of the dialysis apparatus, the plurality of functions being associated with effectuating treatment of the patient, where upon authenticated, the display to the one or more functions for which access is restricted to the at least one authorized user (Paragraphs 26) The dialysis machine 102 includes a user interface with input devices such as a touch screen 118 and a control panel 120. The touch screen 118 and the control panel 120 allow the operator to input various different treatment parameters to the dialysis machine 102 and to otherwise control the dialysis machine 102. The touch screen 118 displays information to the operator of the dialysis system 100. The touch screen 118 can also indicate whether the secure access card 105 is in within communication range of the dialysis machine 102.[P-26] Here, we see the ability to modify operation of the dialysis apparatus based at least in part on the at least one user input controlling, via GUI on the display, the one or more functions of the dialysis apparatus to effectuate treatment of the patient according to the at least one user input. Therefore, it would have been obvious to one of ordinary skill in the art during the filing date of the said invention to combine Merics’ teaching with Flaknes modified’s teaching in order to have a more effective and secure means to access and communicate with medical devices using remote devices. Flakne modified’s teaching fails to teach the user interface using a mobile application to further enable authentication of the mobile device by the medical device. Maguire on the other hand teaches the user-specific authentication of a mobile device for access to a computing device to control; upon the authentication of the mobile device, it is paired with the remote computing device and granted access to control functions (plurality) of the computing device, up until which prior to authentication are restricted (Paragraphs 4, 5, 30, 68, 69; Fig 5A-D), i.e. A mobile computing device such as a smartphone, tablet computer, or laptop computer may include functionality for determining its location, direction, or orientation, such as a GPS receiver, compass, altimeter, accelerometer, or gyroscope. Such a device may also include functionality for wireless communication over any conventional technology, such as, by way of example and not limitation, BLUETOOTH, near-field communication (NFC), radio frequency (e.g., RFID), infrared (IR), Wi-Fi, pager, or cellular (e.g., 2G, 3G, 4G). Such a device may also include one or more cameras, scanners, touchscreens, microphones, or speakers. Mobile computing devices may also execute software applications, such as games, web browsers, or social-networking applications. With social-networking applications, users may connect, communicate, and share information with other users in their social networks.[P-4] In particular embodiments, a portable, networked computing device("PND") provides seamless and portable network connectivity for a user's devices in a device cloud. In particular embodiments, the PND may be a stand-alone small (e.g., key-fob-sized) device; in other embodiments, the PND may be integrated into one of the user's devices (e.g., a smartphone or tablet computing device). The PND may be designed to take advantage of any available network connection in order to act as a network access point for devices that may not include all of the same capabilities. A PND may be paired with one or more devices, with which it may communicate directly, in a peer-to-peer fashion, by low- power radio when it is within a threshold proximity with the PND-paired device(s). The PND itself may monitor network availability and/or link quality and turn on one or more of its own additional radios on an as-needed basis (conserves power and may reduce cost). For example, when the PND detects that WiFi signals are becoming weak, it may activate its cellular radio to seamlessly provide network connectivity to paired devices within proximity of the PND. [P-5] PND 110 may also store user-specific authentication and authorization credentials, payment credentials (e.g., smart card chip), telephony identifiers (e.g., SIM card), configuration settings, preferences, favorites lists/bookmarks, applications, or any other data to enable PND 110 to facilitate personalized and secure computing in conjunction with the PND-paired devices. In particular embodiments, certain PND-paired devices (e.g., home security system, a safe, a gun locker, a bicycle chain, a laptop security cable) may comprise additional components for security purposes (e.g., sensors and logic to perform biometric identification). [P-30] As discussed above, by pairing a device with PND 110, the user may be able to activate, control, and otherwise use devices in the device cloud. By connecting with the PND, one or more devices in the device cloud may be used to communicate with and control (actively or automatically) one or more other devices in the device cloud. A control interface may be provided on one device ("the control device") to control other devices in the device cloud. In particular embodiments, the control device may only provide controls for particular "controllable" devices in the device cloud, e.g., those that are sensed within a threshold proximity, those that include a remote interaction interface by which the device can receive and process commands for remote control, those for which the user of PND 110 has been granted authorization to control the device, or those that are available (e.g., powered on, connected to a network, operational, and/or enabled for remote control). [P-68] FIGS. 5A-D illustrate an example user interface (UI) 500 for controlling devices in a device cloud. In the example illustrated in FIGS. 5A-D, UI 500 is displayed on the screen of user 101's smartphone 120. In particular embodiments, UI 500 may be displayed on a home screen of smartphone 120, or even in a locked-screen interface (thereby being available for use without requiring user 101 to unlock smartphone 120). [P-69] In addition, Maguire teaches wherein a secure link between the transceiver of one device and a mobile device associated with the user, upon authenticating with an application loaded on the mobile device, via cryptographic authentication, and further verifying the mobile device, thereafter enabling access of the user via device pairing (Paragraphs 54) In step 440, the new device may provide information to PND 110. For example, a device belonging to user 101 may have established its own network connectivity settings (e.g., Wi-Fi service set identifiers (SSIDs), encryption configuration settings and passwords) prior to pairing with PND 110, which it may then share with PND 110 upon pairing with PND 110.[P-54] With Maguire teaching using mobile application to establish access and further communication between a mobile device and another device upon authentication of device using cryptographic settings or authentication, it would be obvious to one of ordinary skill in the art to use the same protocol to enable a secure connection and authentication between a mobile device and a medical device such as a dialysis apparatus. It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Maguire’s teaching with Flakne modified’s teaching in this case substituting the computing device with the medical device, in order to enable a more secure access method and further remote control protocols of medical computing devices by an authorized external device. Flakne modified fails to specify the device cryptographic authentication data being different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device Beatson on the other hand teaches the device cryptographic authentication data being different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device (Claim 3) The mobile device and methods for authenticating a user to a mobile device as recited in claim 2 where said mobile device is connected, through a network to a remote computer; said mobile device and said remote computer achieving mutual remote authentication through the following steps: a) Remote computer requests active user to authenticate to said mobile device using said biometric verification and said PIN b) After mutual authentication, mobile device communicates encrypted data, including a user credential over said network using a symmetrical encryption key, which is a function of at least one of the one-way hashed value of said password (generated following a PIN and biometric match) and said mobile device ID c) Mobile device communicates at least said mobile device ID, encrypted with said symmetrical encryption key, to said remote computer d) Remote computer calculates said symmetrical encryption key from a stored value of the said password hash, decrypts at least said mobile device ID and authenticates it as a legitimate mobile device on said network e) Remote computer acknowledges the legitimacy of said network communication by encrypting the hashed password using said symmetrical key and communicates this data to said mobile device. f) Mobile device decrypts said data, tests the said hashed password for authenticity and in response to said test, acknowledges remote computer legitimacy to remote computer and grants it access to said mobile device. g) Remote computer checks said mobile device system configuration to see if said configuration complies with network security policy, changes said configuration in response to its acceptability and, if appropriate, releases said user credential to said remote computer application. h) In the absence of said active mobile device responding to said remote computer request, remote computer gains access to said mobile device and modifies said mobile device according to enterprise security policy. [Cl-3] Here see Beatson teaching a method for authentication of a user to a mobile device using biometric user credentials and a pin, which are followed up by the authentication of the mobile device to the user, to which hereafter the device is allowed access to a computer device or vice versa, upon mutual authentication. Beatson teaches cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device, i.e. remote computer calculates said symmetrical encryption key from a stored value of the said password hash, decrypts at least said mobile device ID and authenticates it as a legitimate mobile device on said network. It would have been obvious during the time of the filing date of the said invention to combine Beatson’s teaching with Flakne modified’s teaching in order to have a more secure and trusting two step verification before allowing access between two separate devices In regards to claim 2, Flakne modified teaches the instructions determine if authentication failed, and denying access to one or more functions of the medical device (Page 5, line 30-Page 6, line 9), i.e. granting access to the external mobile device to an implanted medical device if and only if the authentication information matches the authentication information stored in the implanted medical device, otherwise the external device is denied access to the medical device (dialysis apparatus). In regards to claim 3, Flakne modified via Meric teaches the dialysis apparatus is a hemodialysis apparatus (Paragraphs 23, 24) A dialysate container 124 is connected to the dialysis machine 102 via a dialysate supply line 126. A drain line 128 and an ultrafiltration line 129 also extend from the dialysis machine 102. The dialysate supply line 126, the drain line 128, and the ultrafiltration line 129 are fluidly connected to the various dialysate components and dialysate lines inside the housing 103 of the dialysis machine 102 that form part of the dialysate circuit. During hemodialysis, the dialysate supply line 126 carries fresh dialysate from the dialysate container 124 to the portion of the dialysate circuit located inside the dialysis machine 102. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer 110, that form the dialysate circuit. As will be described below, as the dialysate passes through the dialyzer 110, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line 128. When ultrafiltration is performed during treatment, a combination of spent dialysate (described below) and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line 129.[P-23] The dialyzer 110 serves as a filter for the patient's blood. The dialysate passes through the dialyzer 110 along with the blood, as described above. A semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) within the dialyzer 110 separates blood and dialysate passing through the dialyzer 110. This arrangement allows the dialysate to collect toxins from the patient's blood. The filtered blood exiting the dialyzer 110 is returned to the patient. The dialysate exiting the dialyzer 110 includes toxins removed from the blood and is commonly referred to as “spent dialysate.” The spent dialysate is routed from the dialyzer 110 to a drain.[P-24] In regards to claim 8, Flakne modified via Merics teaches the one or more functions comprises initiating a dialysis session(Paragraphs 19, 21) FIG. 1 shows a dialysis system 100 configured to wirelessly communicate with a short-range wireless device, such as a secure access card 105. As further discussed in detail herein, the secure access card 105 may include biometric authentication technology that includes biometric sensing, scanning and/or other biometric processing performed on/by the secure access card 105. In an implementation, the biometric authentication may be fingerprint authentication. The dialysis system 100 may include a dialysis machine 102, e.g. a hemodialysis machine. In the hemodialysis machine implementation, as illustrated, the dialysis machine 102 is connected to a disposable blood component set 104 that partially forms a blood circuit. It is noted that the system described herein may be implemented in connection with other types of dialysis machines or medical devices, including peritoneal dialysis machines. During a hemodialysis treatment, an operator connects arterial and venous patient lines 106, 108 of the blood component set 104 to a patient. The blood component set 104 includes an air release device 112, which contains a self-sealing vent assembly that allows air but does not allow liquid to pass. As a result, if blood passing through the blood circuit during treatment contains air, the air release device 112 will vent the air to atmosphere.[P-19] The operator uses a blood pump module 134 to operate the blood pump 132. The blood pump module 134 includes a display window, a start/stop key, an up key, a down key, a level adjust key, and an arterial pressure port. The display window displays the blood flow rate setting during blood pump operation. The start/stop key starts and stops the blood pump 132. The up and down keys increase and decrease the speed of the blood pump 132. The level adjust key raises a level of fluid in an arterial drip chamber.[P-21] In regards to claim 9, Flakne modified teaches one or more functions comprise modifying one or more treatment parameters (Page 19, lines 15-20). In regards to claim 10, Flakne modified teaches the one or more functions comprise access to a function of the medical apparatus (Page 19, line 8-12). In regards to claim 32, Flakne teaches a method performed by a medical device, comprising connecting to a mobile device via a transceiver; receiving authentication information from the mobile device; authenticating the mobile device (Page 5, line 30-Page 6, line 9). Thereafter providing access to one or more access-controlled functions of the medical device if the mobile device is authenticated (Page 4, lines 5-9; Page 9, line 21- Page 8, line 6). Flakne fails to teach communicating by the gateway by the transceiver to receive an indication that user-specific authentication information from a mobile device has communicatively coupled to the transceiver and has been authenticated by the gateway and authenticate a user of the mobile device upon the user-specific authentication information being verified; and grant access, to the user via a display of the medical device, to one or more functions of the medical device if when the user has been authenticated. Fukazawa on the other hand teaches communicating by the gateway by the transceiver to receive an indication that user-specific authentication information from a mobile device has communicatively coupled to the transceiver and has been authenticated by the gateway and authenticate a user of the mobile device upon the user-specific authentication information being verified (Page 19, Appendix 8), i.e. the remote medical assistance device is connected to a second storage device that stores in advance a user ID and a password of a user who can use a specific terminal, an attribute of the user ID, and a face image of the user ID in association with each other, At the time of login processing of a predetermined terminal (the gateway being the login portal). A face image of the user of the terminal and a user ID taken by the predetermined terminal are received. Acquiring a face image associated with the accepted user ID from the second storage device, performing face authentication on the accepted face image and the acquired face image. If the attribute of the received user ID is a specific medical worker, the password authentication is requested to the predetermined terminal after the face authentication is successful, and the login is permitted if the password authentication is successful. If the attribute of the user ID included in the received information is other than the specific medical worker, login is permitted after the face authentication has succeeded. Thereafter, granting access, to the user via a display of the medical device, to one or more functions of the medical device if when the user has been authenticated (Page 21, Appendix C1-D1), i.e. in response to a request from the second terminal and the connection-established first terminal, display information for displaying the medical care information on the screen of the first terminal is generated, after the user is authenticated. It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Fukazawa’s teaching with Flakne’s teaching in order to enable the secure access and transfer of medical data from one medical device to an authorized external device. Falkne modified fails to teach the medical device being a dialysis apparatus, as well as the authentication of the mobile device involving cryptographic authentication information configured to authenticate the mobile device Merics on the other hand teaches a medical device such as a dialysis machine configured to filter toxins from at least one bodily fluid of a patient (Paragraphs 23, 24) A dialysate container 124 is connected to the dialysis machine 102 via a dialysate supply line 126. A drain line 128 and an ultrafiltration line 129 also extend from the dialysis machine 102. The dialysate supply line 126, the drain line 128, and the ultrafiltration line 129 are fluidly connected to the various dialysate components and dialysate lines inside the housing 103 of the dialysis machine 102 that form part of the dialysate circuit. During hemodialysis, the dialysate supply line 126 carries fresh dialysate from the dialysate container 124 to the portion of the dialysate circuit located inside the dialysis machine 102. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer 110, that form the dialysate circuit. As will be described below, as the dialysate passes through the dialyzer 110, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line 128. When ultrafiltration is performed during treatment, a combination of spent dialysate (described below) and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line 129.[P-23] The dialyzer 110 serves as a filter for the patient's blood. The dialysate passes through the dialyzer 110 along with the blood, as described above. A semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) within the dialyzer 110 separates blood and dialysate passing through the dialyzer 110. This arrangement allows the dialysate to collect toxins from the patient's blood. The filtered blood exiting the dialyzer 110 is returned to the patient. The dialysate exiting the dialyzer 110 includes toxins removed from the blood and is commonly referred to as “spent dialysate.” The spent dialysate is routed from the dialyzer 110 to a drain.[P-24] Merics further teaches the restriction to one or more functions of the plurality of functions of the dialysis machine to the authorized user, enabling the user to access the dialysis machine once the user’s mobile device and/or access card has been authenticated and verified via encryption authentication (Paragraphs 7, 30, 36, 37, 46, 48) Various implementations of the system described herein are described. For example, the biometric security module that is embedded on the secure access card may include the biometric sensor that obtains the biometric data from the requesting user and the biometric verification module that performs processing to verify the biometric data obtained from the requesting user. Alternatively, in another implementation, the biometric verification module is located remotely from the secure access card. After the biometric validation module verifies the biometric data in relation to the template biometric data of the authorized user, access to the dialysis machine is granted to the requesting user. The requesting user may be a service technician, and for which access granted to the requesting user includes access allowing the requesting user to service the dialysis machine and/or the requesting user may be a patient or caregiver of the patient, and for which access granted to the requesting user includes enabling the dialysis machine to obtain medical records of the patient. In an implementation, the dialysis machine receives a download over a network of a prescription of the patient for a treatment to be performed by the dialysis machine.[P-7] Additionally and/or alternatively, the dialysis machine 102 may include a network communication module 109. The network communication module 109 allows the dialysis system 100 to communicate with remote servers, computer systems, databases and/or other medical devices over a network such as a local area network (LAN) or the Internet. The network communication module 109 allows the dialysis system 100 to communicate with other medical devices, computer systems, servers, and/or databases associated with one or more medical facilities. The network communication module 109 may enable communication over the network using wired and/or wireless connections. For example, the network communication module 109 may enable communication using WiFi communication protocols and infrastructure and/or may enable communication using wireless mobile telecommunication networks. The system described herein may use appropriate encryption and security standards and protocols in connection with the transmission of sensitive and/or protected data in accordance with all statutory and regulatory requirements.[P-30] The operable range of the NFC initiator and NFC target may be in the order of inches (e.g., 0-6 inches). In some implementations, the transfer of data is initiated upon the NFC initiator and the NFC target making physical contact with each other. In some implementations, the NFC initiator and/or the NFC target can include a motion sensor (e.g., an accelerometer) to assist in identifying the occurrence of physical contact between the modules. It is noted that in other short-range communication protocol implementations, such as WiFi and/or Bluetooth, the operable range may be larger (e.g. 10 feet or more).[P-36] The NFC initiator is sometimes part of another electronic device such as a mobile phone, a computer, or as in this example, a medical device. The NFC initiator can have an independent power source or it can receive power from a power source that provides power to the electronic device. The NFC initiator can include a loop antenna that uses magnetic induction to generate an RF field.[P-37] For example, suppose that the patient associated with the secure access card 105, John Doe, has a medical condition that requires an atypical dialysis treatment. Perhaps John's treatment requires an abnormally low dialysate flow rate. The secure access card 105 is used to biometrically authenticate the user John Doe when the secure access card 105 is in proximity to the dialysis system 100, as further discussed elsewhere herein. After biometric proximity authentication, the dialysis system 100 receives the patient identification information from the secure access card 105, accesses remote data storage, and uses the received patient identification information to identify medical information related to John Doe. The medical information includes John Doe's medical history, treatment prescriptions, and treatment parameters; in particular, the treatment prescription includes instructions for causing the dialysis machine 102 to employ the abnormally low dialysate flow rate that John Doe requires. Such information is obtained (e.g. downloaded) and provided to the control unit 101, and the control unit 101 causes the appropriate treatment to be administered to John Doe. For example, the control unit 101 can cause the dialyzer 110 to operate a pump (e.g., a dialysate pump) such that the required dialysate flow rate is achieved.[P-46] After enrollment processing of the authorized user 401 by the enrollment module 410, an access-requesting user 401′ may request access to a medical device, such as the dialysis machine 102, by presenting the secure access card 102, which access request requires biometric acquisition and verification by the authentication module 420 according to an implementation of the system described herein. The authentication by the authentication module 420 may be initiated when the requesting user 401′ brings the secure access card 102 into proximity of the dialysis machine 102. At that time, the secure access card 102 may pair with the dialysis machine 102, and information, such as ID information 402, associated with the authorized user 401 of the secure access card 102 may be transmitted. An embedded biometric sensor 422 of the secure access card 102, such as the fingerprint sensor 220, may be activated and a biometric/fingerprint scan of the user 401′ acquired using the embedded biometric sensor 422. Identifying features of the biometric data scanned by the sensor 422 are extracted at a feature extraction module 424 that may, for example, be performed on the secure access card 105. Using the ID information 402, the biometric template data for the authorized user 401 that has been previously stored is obtained from the database 430. The stored biometric data is matched to the scanned/acquired biometric data in a verification module 426. In various implementations, the verification module 426 may be located/processed on the secure access card 105, at the dialysis machine 102, and/or at a remote site, and a result 440, e.g. either a positive or negative match, is determined. The result 440 may be used to determine whether access to the dialysis machine 102 by the requesting user 401′ is granted or denied.[P-48] Here we see Merics teaching access to a dialysis machine and manipulate said machine, upon authentication using encryption protocols to validate a mobile device that may contain access card key credentials. Merics then teaches the display, a graphical user interface configured to permit a user interact with the dialysis system via at least one user input associated with a plurality of functions of the dialysis apparatus, the plurality of functions being associated with effectuating treatment of the patient, where upon authenticated, the display to the one or more functions for which access is restricted to the at least one authorized user (Paragraphs 26) The dialysis machine 102 includes a user interface with input devices such as a touch screen 118 and a control panel 120. The touch screen 118 and the control panel 120 allow the operator to input various different treatment parameters to the dialysis machine 102 and to otherwise control the dialysis machine 102. The touch screen 118 displays information to the operator of the dialysis system 100. The touch screen 118 can also indicate whether the secure access card 105 is in within communication range of the dialysis machine 102.[P-26] Here, we see the ability to modify operation of the dialysis apparatus based at least in part on the at least one user input controlling, via GUI on the display, the one or more functions of the dialysis apparatus to effectuate treatment of the patient according to the at least one user input. Therefore, it would have been obvious to one of ordinary skill in the art during the filing date of the said invention to combine Merics’ teaching with Flaknes modified’s teaching in order to have a more effective and secure means to access and communicate with medical devices using remote devices. Flakne modified’s teaching fails to teach the user interface using a mobile application to further enable authentication of the mobile device by the medical device. Maguire on the other hand teaches the user-specific authentication of a mobile device for access to a computing device to control; upon the authentication of the mobile device, it is paired with the remote computing device and granted access to control functions (plurality) of the computing device, up until which prior to authentication are restricted (Paragraphs 4, 5, 30, 68, 69; Fig 5A-D), i.e. A mobile computing device such as a smartphone, tablet computer, or laptop computer may include functionality for determining its location, direction, or orientation, such as a GPS receiver, compass, altimeter, accelerometer, or gyroscope. Such a device may also include functionality for wireless communication over any conventional technology, such as, by way of example and not limitation, BLUETOOTH, near-field communication (NFC), radio frequency (e.g., RFID), infrared (IR), Wi-Fi, pager, or cellular (e.g., 2G, 3G, 4G). Such a device may also include one or more cameras, scanners, touchscreens, microphones, or speakers. Mobile computing devices may also execute software applications, such as games, web browsers, or social-networking applications. With social-networking applications, users may connect, communicate, and share information with other users in their social networks.[P-4] In particular embodiments, a portable, networked computing device("PND") provides seamless and portable network connectivity for a user's devices in a device cloud. In particular embodiments, the PND may be a stand-alone small (e.g., key-fob-sized) device; in other embodiments, the PND may be integrated into one of the user's devices (e.g., a smartphone or tablet computing device). The PND may be designed to take advantage of any available network connection in order to act as a network access point for devices that may not include all of the same capabilities. A PND may be paired with one or more devices, with which it may communicate directly, in a peer-to-peer fashion, by low- power radio when it is within a threshold proximity with the PND-paired device(s). The PND itself may monitor network availability and/or link quality and turn on one or more of its own additional radios on an as-needed basis (conserves power and may reduce cost). For example, when the PND detects that WiFi signals are becoming weak, it may activate its cellular radio to seamlessly provide network connectivity to paired devices within proximity of the PND. [P-5] PND 110 may also store user-specific authentication and authorization credentials, payment credentials (e.g., smart card chip), telephony identifiers (e.g., SIM card), configuration settings, preferences, favorites lists/bookmarks, applications, or any other data to enable PND 110 to facilitate personalized and secure computing in conjunction with the PND-paired devices. In particular embodiments, certain PND-paired devices (e.g., home security system, a safe, a gun locker, a bicycle chain, a laptop security cable) may comprise additional components for security purposes (e.g., sensors and logic to perform biometric identification). [P-30] As discussed above, by pairing a device with PND 110, the user may be able to activate, control, and otherwise use devices in the device cloud. By connecting with the PND, one or more devices in the device cloud may be used to communicate with and control (actively or automatically) one or more other devices in the device cloud. A control interface may be provided on one device ("the control device") to control other devices in the device cloud. In particular embodiments, the control device may only provide controls for particular "controllable" devices in the device cloud, e.g., those that are sensed within a threshold proximity, those that include a remote interaction interface by which the device can receive and process commands for remote control, those for which the user of PND 110 has been granted authorization to control the device, or those that are available (e.g., powered on, connected to a network, operational, and/or enabled for remote control). [P-68] FIGS. 5A-D illustrate an example user interface (UI) 500 for controlling devices in a device cloud. In the example illustrated in FIGS. 5A-D, UI 500 is displayed on the screen of user 101's smartphone 120. In particular embodiments, UI 500 may be displayed on a home screen of smartphone 120, or even in a locked-screen interface (thereby being available for use without requiring user 101 to unlock smartphone 120). [P-69] In addition, Maguire teaches wherein a secure link between the transceiver of one device and a mobile device associated with the user, upon authenticating with an application loaded on the mobile device, via cryptographic authentication, and further verifying the mobile device, thereafter enabling access of the user via device pairing (Paragraphs 54) In step 440, the new device may provide information to PND 110. For example, a device belonging to user 101 may have established its own network connectivity settings (e.g., Wi-Fi service set identifiers (SSIDs), encryption configuration settings and passwords) prior to pairing with PND 110, which it may then share with PND 110 upon pairing with PND 110.[P-54] With Maguire teaching using mobile application to establish access and further communication between a mobile device and another device upon authentication of device using cryptographic settings or authentication, it would be obvious to one of ordinary skill in the art to use the same protocol to enable a secure connection and authentication between a mobile device and a medical device such as a dialysis apparatus. It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Maguire’s teaching with Flakne modified’s teaching in this case substituting the computing device with the medical device, in order to enable a more secure access method and further remote control protocols of medical computing devices by an authorized external device. Flakne modified fails to specify the device cryptographic authentication data being different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device Beatson on the other hand teaches the device cryptographic authentication data being different from cryptographic information associated with the user; wherein the application is configured to permit the transceiver to access the cryptographic authentication information in response to the user authenticating with the application; cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device (Claim 3) The mobile device and methods for authenticating a user to a mobile device as recited in claim 2 where said mobile device is connected, through a network to a remote computer; said mobile device and said remote computer achieving mutual remote authentication through the following steps: a) Remote computer requests active user to authenticate to said mobile device using said biometric verification and said PIN b) After mutual authentication, mobile device communicates encrypted data, including a user credential over said network using a symmetrical encryption key, which is a function of at least one of the one-way hashed value of said password (generated following a PIN and biometric match) and said mobile device ID c) Mobile device communicates at least said mobile device ID, encrypted with said symmetrical encryption key, to said remote computer d) Remote computer calculates said symmetrical encryption key from a stored value of the said password hash, decrypts at least said mobile device ID and authenticates it as a legitimate mobile device on said network e) Remote computer acknowledges the legitimacy of said network communication by encrypting the hashed password using said symmetrical key and communicates this data to said mobile device. f) Mobile device decrypts said data, tests the said hashed password for authenticity and in response to said test, acknowledges remote computer legitimacy to remote computer and grants it access to said mobile device. g) Remote computer checks said mobile device system configuration to see if said configuration complies with network security policy, changes said configuration in response to its acceptability and, if appropriate, releases said user credential to said remote computer application. h) In the absence of said active mobile device responding to said remote computer request, remote computer gains access to said mobile device and modifies said mobile device according to enterprise security policy. [Cl-3] Here see Beatson teaching a method for authentication of a user to a mobile device using biometric user credentials and a pin, which are followed up by the authentication of the mobile device to the user, to which hereafter the device is allowed access to a computer device or vice versa, upon mutual authentication. Beatson teaches cryptographically verify the cryptographic authentication information of the mobile device against a prestored digital certificate provisioned by a certificate authority and associated with the mobile device, i.e. remote computer calculates said symmetrical encryption key from a stored value of the said password hash, decrypts at least said mobile device ID and authenticates it as a legitimate mobile device on said network. It would have been obvious during the time of the filing date of the said invention to combine Beatson’s teaching with Flakne modified’s teaching in order to have a more secure and trusting two step verification before allowing access between two separate devices In regards to claim 35, Flakne modified via Meric teaches the dialysis apparatus is a hemodialysis apparatus (Paragraphs 23, 24) A dialysate container 124 is connected to the dialysis machine 102 via a dialysate supply line 126. A drain line 128 and an ultrafiltration line 129 also extend from the dialysis machine 102. The dialysate supply line 126, the drain line 128, and the ultrafiltration line 129 are fluidly connected to the various dialysate components and dialysate lines inside the housing 103 of the dialysis machine 102 that form part of the dialysate circuit. During hemodialysis, the dialysate supply line 126 carries fresh dialysate from the dialysate container 124 to the portion of the dialysate circuit located inside the dialysis machine 102. As noted above, the fresh dialysate is circulated through various dialysate lines and dialysate components, including the dialyzer 110, that form the dialysate circuit. As will be described below, as the dialysate passes through the dialyzer 110, it collects toxins from the patient's blood. The resulting spent dialysate is carried from the dialysate circuit to a drain via the drain line 128. When ultrafiltration is performed during treatment, a combination of spent dialysate (described below) and excess fluid drawn from the patient is carried to the drain via the ultrafiltration line 129.[P-23] The dialyzer 110 serves as a filter for the patient's blood. The dialysate passes through the dialyzer 110 along with the blood, as described above. A semi-permeable structure (e.g., a semi-permeable membrane and/or semi-permeable microtubes) within the dialyzer 110 separates blood and dialysate passing through the dialyzer 110. This arrangement allows the dialysate to collect toxins from the patient's blood. The filtered blood exiting the dialyzer 110 is returned to the patient. The dialysate exiting the dialyzer 110 includes toxins removed from the blood and is commonly referred to as “spent dialysate.” The spent dialysate is routed from the dialyzer 110 to a drain.[P-24] In regards to claim 37, Flakne modified via Merics teaches the one or more functions comprises initiating a dialysis session(Paragraphs 19, 21) FIG. 1 shows a dialysis system 100 configured to wirelessly communicate with a short-range wireless device, such as a secure access card 105. As further discussed in detail herein, the secure access card 105 may include biometric authentication technology that includes biometric sensing, scanning and/or other biometric processing performed on/by the secure access card 105. In an implementation, the biometric authentication may be fingerprint authentication. The dialysis system 100 may include a dialysis machine 102, e.g. a hemodialysis machine. In the hemodialysis machine implementation, as illustrated, the dialysis machine 102 is connected to a disposable blood component set 104 that partially forms a blood circuit. It is noted that the system described herein may be implemented in connection with other types of dialysis machines or medical devices, including peritoneal dialysis machines. During a hemodialysis treatment, an operator connects arterial and venous patient lines 106, 108 of the blood component set 104 to a patient. The blood component set 104 includes an air release device 112, which contains a self-sealing vent assembly that allows air but does not allow liquid to pass. As a result, if blood passing through the blood circuit during treatment contains air, the air release device 112 will vent the air to atmosphere.[P-19] The operator uses a blood pump module 134 to operate the blood pump 132. The blood pump module 134 includes a display window, a start/stop key, an up key, a down key, a level adjust key, and an arterial pressure port. The display window displays the blood flow rate setting during blood pump operation. The start/stop key starts and stops the blood pump 132. The up and down keys increase and decrease the speed of the blood pump 132. The level adjust key raises a level of fluid in an arterial drip chamber.[P-21] In regards to claim 38, Flakne modified teaches one or more functions comprise modifying one or more treatment parameters (Page 19, lines 15-20). In regards to claim 41, Flakne modified teaches the one or more functions comprise communicating with a patient associated with the medical device (Page 5, lines 23-26; Page 11, lines 20-24), i.e. prompting the patient to respond to specific requests associated with the medical device. Claim(s) 4 and 36 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flakne et al. (WO 2020120061 A1) in view of Fukazawa et al. (JP 6652267 B1), Maguire et al. (CA 2904619 A1) and Beatson et al. (US 20140365782 A1) as applied above in claims 1 and 32, in further view of Kapoor (US 20130158423 A1). In regards to claim 4, Flakne modified fails to teach the medical device is selected from a group consisting of: an insulin pump, a sleep apnea machine, a pulse oximeter, an external neural stimulator, intravenous (IV) equipment, a noninvasive blood pressure measuring device, and a smart thermometer. Kapoor on the other hand teaches the medical device is selected from a group consisting of: an insulin pump (Paragraph 82), a sleep apnea machine (Paragraph 80), a pulse oximeter (Paragraph 82), an external neural stimulator, intravenous (IV) equipment (Paragraph 82), a noninvasive blood pressure measuring device (Paragraph 55, 82), and a smart thermometer (Paragraph 82). It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Kapoor’s teaching with Flakne modified’s teaching in order to enable the secure access and transfer of medical data from one medical device to an authorized external device. In regards to claim 36, Flakne modified fails to teach the medical device is selected from a group consisting of: an insulin pump, a sleep apnea machine, a pulse oximeter, an external neural stimulator, intravenous (IV) equipment, a noninvasive blood pressure measuring device, and a smart thermometer. Kapoor on the other hand teaches the medical device is selected from a group consisting of: an insulin pump (Paragraph 82), a sleep apnea machine (Paragraph 80), a pulse oximeter (Paragraph 82), an external neural stimulator, intravenous (IV) equipment (Paragraph 82), a noninvasive blood pressure measuring device (Paragraph 55, 82), and a smart thermometer (Paragraph 82). It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Kapoor’s teaching with Flakne’s teaching in order to enable the secure access and transfer of medical data from one medical device to an authorized external device. Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flakne et al. (WO 2020120061 A1) in view of Fukazawa et al. (JP 6652267 B1), Merics et al. (US 20210093764 A1) Maguire et al. (CA 2904619 A1) and Beatson et al. (US 20140365782 A1), as applied above in claims 1, in further view of Aganyan et al. (US2019024400 A1) In regards to claim 5, Flakne modified fails to teach wherein authenticating the mobile device comprises two-factor verification. Aganyan on the other hand teaches wherein authenticating the mobile device comprises two-factor verification (Paragraph 54). It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Aganyan’s teaching with Flakne modified’s teaching in order to enable the secure trustworthy method to enable the access and transfer of medical data from one medical device to an authorized external device. Claim(s) 39 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flakne et al. (WO 2020120061 A1) in view of Fukazawa et al. (JP 6652267 B1), Merics et al. (US 20210093764 A1) Maguire et al. (CA 2904619 A1) and Beatson et al. (US 20140365782 A1) as applied above in claim 32, in further view of Walton, III (US 20160042126 A1). In regards to claim 39, Flakne modified fails to teach the one or more functions comprise accessing a treatment history. Walton on the other hand teaches one or more functions comprise accessing a treatment history (Paragraph 11). It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Walton’s teaching with Flakne modified’s teaching in order to effectively monitor a patient’s treatment, and continue the patient’s treatment accordingly passed of their past history. Claim(s) 40 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flakne et al. (WO 2020120061 A1) in view of Fukazawa et al. (JP 6652267 B1), Merics et al. (US 20210093764 A1), Maguire et al. (CA 2904619 A1) and Beatson et al. (US 20140365782 A1) as applied above in claim 32, in further view of Peeters (CA 2554007 C). In regards to claim 40, Flakne modified fails to teach the one or more functions comprises retrieving one or more patient alerts. Peeters on the other hand teaches the one or more functions comprises retrieving one or more patient alerts (Paragraph 58). It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to combine Peeter’s teaching with Flakne modified’s teaching in order to effectively monitor a patient’s treatment, and continue the patient’s treatment accordingly passed of their past history. Allowable Subject Matter Claims 43-46 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, as well as 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph rejections are overcome. Claims 43 reads as follows, “The dialysis system of claim 1, wherein authenticating comprises validating a certificate chain to a trusted certificate authority, confirming certificate expiry, and checking revocation status for the digital certificate prior to establishing the secure link to determine certificate status before deriving a session key that is cryptographically bound to a device identifier and a role-based access level with an enforced expiration time window.” During the time of the filing date of the said invention, there was no prior art that taught the scope of the invention in its entirety in conjunction with its parent claim. Claim 45 is objected for the same rationale. Claim 44 reads as follow, “The dialysis machine of claim 1, wherein the processor is further configured to record, in a local data store, an authentication record including at least a certificate identifier, validation outcome, access level granted, and a timestamp.” During the time of the filing date of the said invention, there was no prior art that taught the scope of the invention in its entirety in conjunction with its parent claim. Claim 46 is objected for the same rationale. Response to Arguments The applicant has amended the independent claim language to specify the apparatus and process being a dialysis apparatus and encryption authentication protocol. The examiner has addressed the limitations above under new grounds of rejection above. Regarding the applicant’s arguments pertaining to One of ordinary skill would not find it obvious to combine Flakne and Fukazawa; specifically because, Flakne focuses their teaching with the use of local communication techniques (near field communication, Medical Implant Communication Service (MICS) and Bluetooth) because it is assumed that an authorized user (the patient in which the IMD is implanted) would be co-located with the IMD that is implanted in the patient. Whereas, Fukazawa focuses on establishing a "Computer Controlling connection" for remote care of a patient. As a result, Fukazawa assumes that the authorized user is remote from the device that the authorized user is attempting to communicate with (the "second terminal" of the patient). The examiner disagrees. Flakne et al, (WO 2020120061 A1) disclosure encompasses a method for establishing an access of an external device to an implantable medical device (3), comprising the steps of: Allowing the implantable medical device (3) to assume an activated mode by letting a user (P) of the implantable medical device (3) apply a magnetic field (B) to the implantable medical device (3), wherein in the activated mode the implantable medical device (3) is enabled to receive authentication information for authenticating the user (P) of the implantable medical device (3), and providing authentication information (A) to the implantable medical device (3), when the latter is in the activated mode to establish said access. The main purpose of Flakne’s teaching is to provide secure communications between an external device (e.g. a programming and/or data display device) and an implantable medical device (IMD) is important to ensure that the person using the external device is known and/or authorized by the patient. Furthermore it is important to acknowledge Fukazawas teaching focuses on a screen for sharing patient information between medical staff and two-way communication using moving images. The home medical care support device includes a connection management unit that controls establishment of a connection for direct communication between a first terminal and a second terminal, and a medical management unit that manages medical information regarding a patient who receives a remote medical care. Prepare. The medical care management unit generates display information for displaying medical care information on the screen of the first terminal in response to a request from the first terminal that has been connected to the second terminal. We see both inventive entities focusing on connecting medical system devices using secure modes of communication. Due to this related functional operations by both inventive entities, despite the vast different uses of both inventions, given the parallel functional operation of both inventions, enables the obvious motive to combine both inventive entities in order to further enable more secure access to transfer medical data from one device to another authorized device, Furthermore, regarding the applicant’s arguments pertaining to, one of ordinary skill would not find it obvious to combine Flakne and Merics. As mentioned above, Flakne et al, (WO 2020120061 A1) disclosure encompasses a method for establishing an access of an external device to an implantable medical device (3), comprising the steps of: Allowing the implantable medical device (3) to assume an activated mode by letting a user (P) of the implantable medical device (3) apply a magnetic field (B) to the implantable medical device (3), wherein in the activated mode the implantable medical device (3) is enabled to receive authentication information for authenticating the user (P) of the implantable medical device (3), and providing authentication information (A) to the implantable medical device (3), when the latter is in the activated mode to establish said access. The main purpose of Flakne’s teaching is to provide secure communications between an external device (e.g. a programming and/or data display device) and an implantable medical device (IMD) is important to ensure that the person using the external device is known and/or authorized by the patient In addition, Merics disclosure focuses on A dialysis system may include a dialysis machine (e.g., a hemodialysis (HD) machine or a peritoneal dialysis (PD) machine) that is configured to communicate with a secure access card having onboard biometric processing capabilities and using a wireless connection established according to a wireless communication protocol. Implementations of the wireless connection may include a short-range wireless technology protocol, such as, for example, Near Field Communication (NFC), WiFi and/or Bluetooth technology protocols. The secure access card may include biometric security features, such as a biometric sensor and/or a biometric verification module, to provide and control secure biometric access to the dialysis machine when the secure access card is brought into proximity of the dialysis machine. Once again we see wireless communication protocols for the purpose of access a medical device or system. With the commonality around both inventions, it would have been obvious to one of ordinary skill in the art to combine Merics teaching with Fakne in order to enhance the security protocol before enabling access from one device to another. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is 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 ANTHONY D AFRIFA-KYEI whose telephone number is (571)270-7826. The examiner can normally be reached Monday-Friday 10am-7pm. 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, BRIAN ZIMMERMAN can be reached at 571-272-3059. 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. /ANTHONY D AFRIFA-KYEI/Examiner, Art Unit 2686 /BRIAN A ZIMMERMAN/Supervisory Patent Examiner, Art Unit 2686
Read full office action

Prosecution Timeline

Show 20 earlier events
Jul 07, 2025
Final Rejection mailed — §103, §112
Oct 07, 2025
Request for Continued Examination
Oct 10, 2025
Response after Non-Final Action
Nov 03, 2025
Non-Final Rejection mailed — §103, §112
Jan 21, 2026
Interview Requested
Feb 03, 2026
Response Filed
Mar 27, 2026
Final Rejection mailed — §103, §112
May 26, 2026
Response after Non-Final Action

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12672796
Fall Risk Assessment for a User
2y 0m to grant Granted Jul 07, 2026
Patent 12676037
GATE SYSTEM, GATE APPARATUS, CONTROL METHOD THEREFOR, AND PROGRAM
1y 11m to grant Granted Jul 07, 2026
Patent 12668197
VEHICULAR CABIN MONITORING SYSTEM
2y 2m to grant Granted Jun 30, 2026
Patent 12657976
GATE SYSTEM, GATE APPARATUS, CONTROL METHOD THEREFOR, AND PROGRAM
1y 10m to grant Granted Jun 16, 2026
Patent 12638301
DATABASE GENERATION METHOD, DATABASE GENERATION DEVICE, NON-TRANSITORY COMPUTER READABLE STORAGE MEDIUM, DATA ANALYSIS METHOD, AND DATA ANALYSIS DEVICE
2y 4m to grant Granted May 26, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

9-10
Expected OA Rounds
65%
Grant Probability
78%
With Interview (+13.1%)
2y 11m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 553 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month