Method, System, and Computer-Readable Storage Medium for Secure Authorization

Abstract

The embodiments presented herein generally relate to techniques for enabling a user of a mobile electronic device to wirelessly control one or more functions of an implantable medical device system. The techniques presented herein establish a secure (encrypted) communication channel between the implantable medical device system and a central system associated with the manufacturer of the implantable medical device system, and use the secure communication channel to authorize the user to wirelessly control one or more functions of the implantable medical device system via the mobile electronic device.

Description

[0001] This application is a divisional application of a Chinese patent application with an application date of January 19, 2017, an application number of 201780008478.0, and an invention title of "Security Authorization in an Implantable Medical Device System".

[0002] Cross - reference to related applications

[0003] This application claims the priority of U.S. Provisional Application No. 62 / 288,053, entitled "Security Authorization in an Implantable Medical Device System", filed on January 28, 2016, the content of which is incorporated herein by reference. Technical Field

[0004] The present invention generally relates to wireless communication in an implantable medical device system. Background Art

[0005] Implantable medical device systems including one or more implantable components provide a wide range of therapeutic benefits to recipients. Over the years, the types of implantable medical device systems and the range of functions performed thereby have increased. For example, many implantable medical device systems now typically include one or more instruments, devices, sensors, processors, controllers, or other functional mechanical or electrical components that are permanently or temporarily implanted within a recipient. These functional components perform the diagnosis, prevention, monitoring, treatment, or management of diseases or injuries or their symptoms, or research, replacement, or modification of anatomical structures or physiological processes. Summary of the Invention

[0006] In one aspect, a method is provided. The method includes: establishing an indirect secure communication channel between an implantable medical device system and a central system associated with a manufacturer of the implantable medical device system via an intermediate mobile device; and using the indirect secure communication channel to authorize a user to wirelessly control one or more functions of the implantable medical device system via an external device. Brief Description of the Drawings

[0007] Embodiments of the present invention are described herein in conjunction with the accompanying drawings, wherein:

[0008] Figure 1 is a schematic diagram illustrating a cochlear implant system according to an embodiment presented herein.

[0009] Figure 2 is a block diagram of an external device operating with a cochlear implant system according to an embodiment presented herein.

[0010] Figure 3 is a block diagram of a sound processing unit of a cochlear implant system according to an embodiment presented herein.

[0011] Figure 4 is a flowchart illustrating communication according to an embodiment presented herein; and

[0012] Figure 5 is a flowchart of a method according to an embodiment presented herein. DETAILED DESCRIPTION

[0013] Smartphones, remote controls, and other mobile electronic devices are commonly used, and these devices are increasingly becoming an integral part of many people's daily lives. As such, it may be desirable to enable the recipient of an implantable medical device system (such as the recipient of a cochlear implant system) to wirelessly control the settings of the implantable medical device system using a smartphone, remote control, or other mobile electronic device (e.g., using a standard wireless communication protocol). To permit control of the implantable medical device system, a short-range wireless connection between the control entity and the system should be ensured. However, conventional short-range wireless communication protocols (such as Low Energy (LE) (BLE), etc.) use encryption mechanisms that may be compromised, thereby exposing all communications between the controller and the implantable medical device system to a potential malicious third party and potentially allowing the third party to gain control of the implantable medical device system. is a registered trademark owned by the SIG.

[0014] As such, presented herein are techniques for enabling a user of a mobile electronic device (e.g., a recipient, caregiver, clinician, surgeon, etc.) to use the mobile electronic device to control one or more parameters, settings, operations, etc. (collectively referred to herein and generally known as "functions") of an implantable medical device system. As further described below, the techniques presented herein establish / create a secure (encrypted) communication channel between the implantable medical device system and a central system associated with the manufacturer of the implantable medical device system, and use the secure communication channel to authorize the user to wirelessly control one or more functions of the implantable medical device system via an external device.

[0015] The secure communication channel between the implantable medical device system and the central system is referred to herein as an "indirect" secure communication channel because the encrypted communication is relayed between the implantable medical device system device and the central system via an intermediate mobile electronic device. That is, there is no direct connection between the implantable medical device system and the central system because the implantable medical device system lacks the ability to access a telecommunications network or a computing network (i.e., the implantable medical device system does not include a telecommunications interface or a network interface). As a result, the first part of the indirect secure channel (i.e., the part between the intermediate mobile electronic device and the implantable medical device system) covers a short-range wireless channel (running on top of it), while the second part of the indirect secure channel (i.e., the part between the intermediate mobile electronic device and the central system) covers one or more telecommunications network links and / or computing network links (e.g., local area network (LAN), wide area network (WAN), etc.), which are collectively referred to herein and are generally referred to as network links. The indirect secure channel is an additional channel beyond any encryption mechanism already used on the short-range wireless channel and / or the network links.

[0016] As described below, the techniques presented herein utilize a two-stage process / sequence to enable a mobile electronic device to control the functions of an implantable medical device system. The first stage is referred to herein as the encryption stage and is used to establish an indirect secure channel between the implantable medical device system and the central system. The second stage is referred to herein as the authorization stage and uses the indirect secure channel to authorize a user to control one or more functions of the implantable medical device system via the mobile electronic device.

[0017] There are many types of implantable medical device systems, which include one or more implantable components. However, for the sake of illustration only, the techniques presented herein are mainly described herein with reference to one type of implantable medical device system (i.e., a cochlear implant system). It should be appreciated that the techniques presented herein can be used with other implantable medical device systems, which include, for example, other partially and fully implantable auditory prostheses, such as auditory brainstem stimulators, bone conduction devices, hybrid devices, implantable acoustic devices (such as middle ear implants and direct acoustic cochlear stimulators), and / or other implantable medical devices (such as implantable pacemakers, defibrillators, functional electrical stimulators, pain relief stimulators, visual prostheses, implantable sensors, and / or other systems having functional implantable components configured to diagnose, prevent, monitor, treat, or manage a disease or injury or its symptoms, or other systems having functional implantable components configured to study, replace, or modify an anatomical structure or a physiological process).

[0018] Figure 1FIG. 0 is a schematic diagram of an exemplary cochlear implant system 100 configured to implement aspects of the present invention. As shown, cochlear implant system 100 includes an external component 108 configured to be attached to a recipient and an implantable component 104 configured to be implanted beneath the recipient's skin / tissue 101. Cochlear implant system 100 operates in conjunction with a mobile electronic device 106, which is referred to herein simply as external device 106.

[0019] In this example, implantable component 104 is a cochlear implant, and external component 108 includes a behind-the-ear (BTE) sound processing unit 110 (such as a mini or micro BTE) and an external coil 112. Sound processing unit 110 includes one or more sound input elements 111 (e.g., microphones, pickup coils, etc.) for receiving sound signals, a power source ( Figure 1 (not shown in FIG.) and a sound processor ( Figure 1 (also not shown in FIG.). The sound processor is configured to process the electrical signals generated by the one or more sound input elements 111.

[0020] Sound processing unit 110 is electrically connected to external coil 112 via a cable or lead 113. External coil 112 is an external radio frequency (RF) coil. Generally, a magnet ( Figure 1 (also not shown in FIG.) may be fixed relative to the external coil. Further details of sound processing unit 110 are provided below with reference to Figure 3 FIG.

[0021] Figure 1 FIG. illustrates an example where external component 108 includes a BTE and a separate external coil 112. However, it should be appreciated that external component 108 may alternatively be: a component having a generally cylindrical shape (sometimes referred to herein as a “button” device) configured to magnetically couple to the recipient's head; an in-the-ear unit configured to be located in the recipient's ear canal, etc.

[0022] As noted, cochlear implant system 100 operates in conjunction with external device 106, further details of which are shown in Figure 2 FIG. As further described below, both external device 106 and sound processing unit 110 include short-range wireless transceivers configured for wireless communication according to a short-range wireless standard (i.e., via a short-range wireless link / connection). In certain embodiments, the short-range wireless transceiver is a transceiver that communicates using short-wavelength ultra-high frequency (UHF) radio waves in the industrial, scientific, and medical (ISM) frequency band of 2.4 to 2.485 gigahertz (GHz). is Registered trademarks owned by SIG. Thus, the external device 106 and the sound processing unit 110 communicate via a short-range coupled wireless link / channel 115.

[0023] The cochlear implant 104 includes an implant body 114, a lead region 116, and an elongated intracochlear stimulation assembly 118. The elongated stimulation assembly 118 is configured to be at least partially implanted in the recipient's cochlea and includes a plurality of intracochlear stimulation contacts 128. The stimulation contacts 128 together form a contact array 126 and may include electrical contacts and / or optical contacts. The stimulation assembly 118 extends through an opening in the cochlea (e.g., cochleostomy, round window, etc.) and has a proximal end connected to a stimulator unit in the implant body 114 via the lead region 116 that extends through the recipient's mastoid bone.

[0024] The cochlear implant 104 also includes an internal RF coil 120, a magnet fixed relative to the internal coil, a stimulator unit, and a closely coupled wireless transceiver located in the implant body 114. A magnet in the cochlear implant 104 adjacent to the external coil 112 facilitates the operational alignment of the external coil 112 with the internal coil 120 in the implant body. The operational alignment of the coils 112 and 120 enables the internal coil 120 to receive power and data transcutaneously from the external coil 112 via a closely coupled RF link 130. The external coil 112 and the internal coil 120 are typically wire antenna coils.

[0025] Figure 1 A central system 122 associated with an external entity (i.e., an entity other than the recipient), such as a manufacturer of the cochlear implant system 100, a local distributor of the cochlear implant system 100, a clinic or other medical institution, a licensee, etc., is also illustrated. However, for ease of explanation only, the techniques presented herein are described with reference to a central system 122 directly or indirectly controlled (e.g., subject to the control of a third party) by the manufacturer of the cochlear implant system 100. In Figure 1 the example, the central system 122 is a cloud-based software platform (the cloud). In the specific illustrative example presented herein, the cloud-based software platform 122 is sometimes referred to herein as the "manufacturer cloud-based software platform" or simply the "manufacturer cloud". As shown, the manufacturer cloud 122 includes one or more servers 124 and one or more database systems 132.

[0026] As further described below, the external device 106 is a mobile electronic device, such as, for example, a remote control device (remote controller), a smart phone, etc. The external device 106 has the ability to communicate with the manufacturer cloud 122 via one or more network links (e.g., a telecommunications network, a wireless local area network, a wide area network, etc.) connection 117. It should be appreciated that the manufacturer cloud 122 may include one or more additional components / devices that implement the cloud's network connectivity. These components are well known in the art and, for the sake of illustration, have been omitted from Figure 1 for clarity.

[0027] Figure 2 is a block diagram of an arrangement where the external device 106 is a smart phone. It should be appreciated that Figure 2 this is merely illustrative and the external device 106 is not limited to Figure 2 the example arrangement shown in

[0028] The external device 106 first includes an antenna 136 and a telecommunications interface 138, which are configured for communication over a telecommunications network. The telecommunications network over which the radio antenna 136 and radio interface 138 communicate can be, for example, a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Time Division Multiple Access (TDMA), or other types of networks.

[0029] As Figure 2 shown, the external device 106 also includes a wireless local area network interface 140 and a short-range wireless interface / transceiver 142 (e.g., infrared (IR) or transceiver). is a registered trademark owned by SIG. The wireless local area network interface 140 allows the external device 106 to connect to the Internet, while the short-range wireless transceiver 142 enables the external device 106 to wirelessly communicate (i.e., receive data directly from or send data to another device via a wireless connection), such as via a 2.4 gigahertz (GHz) link. As further described below, the short-range wireless transceiver 142 is used to wirelessly connect the external device 106 to the sound processing unit 110. It should be appreciated that any other interfaces known now or developed later, including but not limited to Institute of Electrical and Electronics Engineers (IEEE) 802.11, IEEE 802.16 (WiMAX), fixed line, Long Term Evolution (LTE), etc., may also or alternatively form part of the external device 106.

[0030] In Figure 2In the example, the external device 106 also includes an audio port 144, one or more sound input components (such as a microphone 146), a speaker 148, a display screen 150, a subscriber identity module or subscriber identification module (SIM) card 152, a battery 154, a user interface 156, one or more processors 158, and a memory 160. Stored in the memory 160 is a medical device control application (logic) 162.

[0031] The display screen 150 is an output device, such as a liquid crystal display (LCD), which is used to present visual information to the cochlear implant recipient. The user interface 156 can take many different forms and can include, for example, a keypad, a keyboard, a mouse, a touch screen, a display screen, etc. The memory 160 can include any one or more of the following: read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical memory storage devices, optical memory storage devices, or other physical / tangible memory storage devices. One or more processors 158 are, for example, microprocessors or microcontrollers that execute the instructions of the medical device control application 162 stored in the memory 160.

[0032] Figure 3 is a functional block diagram illustrating the elements of a sound processing unit 110 according to an example embodiment. Figure 3 Shown are a short-range wireless transceiver 170, a closely coupled wireless transceiver (i.e., an RF encoder / coil driver) 178 connected to the RF coil 112 ( Figure 1 ), a user interface 165 including at least one user input device (e.g., a button), and an optional display (e.g., a digital display), one or more processors 172, one or more sound input elements 176 (e.g., a microphone pick-up coil, an audio input port, a universal serial bus (USB) port, etc.), and a rechargeable battery 180 (such as an integrated or removable lithium-ion (LiIon) battery. The sound processing unit 110 also includes a memory 184, which includes external control logic 186, a serial number 188, and a nonce 190.

[0033] The closely coupled wireless transceiver 178 is configured to transmit power and / or data to and / or receive data from the cochlear implant 104 transcutaneously via a closely coupled RF link 130 ( Figure 1 ). As used herein, closely coupled wireless communication refers to communication that requires close proximity between the communication transceivers. In a particular example, closely coupled communication refers to communication between transceivers that are within approximately ten (10) centimeters (cm) of each other and / or inductively coupled to each other. Although Figure 1 and Figure 3Illustrated is the use of an RF link, but it should be appreciated that alternative embodiments may use other types of closely coupled links (e.g., infrared (IR), capacitive, etc.).

[0034] Memory 184 may include any one or more of the following: read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical memory storage devices, optical memory storage devices, or other physical / tangible memory storage devices. One or more processors 172 may be one or more microprocessors or microcontrollers that execute instructions of an external control logic 186 stored in memory 160.

[0035] One or more processors 172 also include a sound processor that is configured to convert a sound signal received via one or more sound input elements 176 into an encoded signal and evoke a perception of the sound signal, the encoded signal representing a stimulation signal for transmission to a recipient. The encoded signal generated by the sound processor is transmitted to the cochlear implant 104 via a closely coupled RF link 130.

[0036] As described elsewhere herein, the external device 106 is configured to allow a user (e.g., a recipient, a caregiver, a clinician, a surgeon, etc.) to control the functions of the cochlear implant system 100. This control is enabled at least in part via one or more processors 158 ( Figure 2 ) executing a medical device control application 162 and one or more processors 172 ( Figure 3 ) executing an external control logic 186. For ease of explanation only, embodiments of the present invention are generally described with reference to operations performed by the external device 106 and the sound processing unit 110, without specifically referring to operations performed by one or more processors 158, one or more processors 172, the medical device control application 162, and / or the external control logic 186.

[0037] Figure 4 is a flow chart that illustrates the communication exchanged between the manufacturer cloud 122 and the external device 106 and between the sound processing unit 110 and the external device 106 according to embodiments presented herein. Generally speaking, the techniques presented herein address the network security issues of the cochlear implant system 100 by: (1) ensuring communication between the sound processing unit 110 and the manufacturer cloud 122; and (2) ensuring that only intended users can access and be able to control the cochlear implant system 100 from the external device.

[0038] The techniques presented herein solve these two cybersecurity components via a two-stage process. The first stage (encryption stage) is used to verify the authenticity of the sound processing unit 110 and the manufacturer cloud-based software platform 122 with respect to each other and establish / create an indirect secure channel between the sound processing unit 110 and the manufacturer cloud 122. The indirect secure channel is generally shown by the bi-directional arrow 119 in Figure 1 as shown.

[0039] The second stage (authorization stage) ensures that only intended users can access and be able to control the cochlear implant system 100 from the external device 106. More specifically, the second stage (1) identifies the user at the external device 106; (2) determines whether the identified user should be allowed to control the sound processing unit 110; and (3) determines the level of control that the user should be granted via the cochlear implant system 100. Each of these stages is described below with reference to Figure 4 as follows.

[0040] As noted above, the sound processing unit 110 does not have the ability to directly connect to the manufacturer cloud 122 (i.e., no telecommunications and / or wireless local area network interface). However, the sound processing unit 110 has the ability to wirelessly communicate with the external device 106 via a short-range wireless link. Thus, the techniques presented herein use the external device 106 (as opposed to an intermediate relay device (e.g., a modem)) to forward communications between the sound processing unit 110 and the manufacturer cloud 122 and vice versa. Communications between the sound processing unit 110 and the external device 106 are sent via the short-range wireless channel 115, while communications between the external device 106 and the manufacturer cloud 122 are sent via the network connection 117.

[0041] The identification information required for the encryption process is initially stored in the sound processing unit 110. This identification information can include, for example, the serial number of the sound processing unit 112 and a series of randomly generated information / data bytes, which are sometimes referred to as "nonce data" or simply "nonce". This nonce initially stored in the sound processing unit 110 is specific to the sound processing unit and is thus referred to herein as the "sound processing unit nonce". As noted above, the serial number shown by the reference numeral 188 in Figure 3 and also the sound processing unit nonce shown by the reference numeral 190 in Figure 3 are stored in the sound processing unit 110 in an irreversible manner during the manufacturing process.

[0042] With reference to Figure 4and for the first stage of encrypting the secure communication sent between the sound processing unit 110 and the manufacturer cloud 122, the sound processing unit 110 sends the stored identification information to the external device 106. Sending the stored identification information to the external device 106 is represented by arrow 240 in Figure 4 In some embodiments, the external device 106 is configured to request identification information from the sound processing unit 110. For the sake of illustration, the request, which has been omitted from Figure 4 , for example, in response to a user input, in response to a command received from the manufacturer cloud, etc., may be automatically sent when connected to the sound processing unit.

[0043] The identification information received at the external device 106 (e.g., serial number and sound processing unit nonce) cannot be used by the external device 106, and the external device 106 sends the identification information to the manufacturer cloud 122. Sending the identification information from the external device 106 to the manufacturer cloud 122 is represented by arrow 242 in Figure 4 .

[0044] The manufacturer cloud 122 uses the identification information to identify the specific sound processing unit 110, and uses a pre - existing encryption key to encrypt the received sound processing unit nonce. The pre - existing key used to encrypt the received sound processing unit nonce is a predetermined key known to both the manufacturer cloud 122 and the sound processing unit 110 (i.e., a predetermined encryption key pair stored in the sound processing unit 110 during manufacturing and known / accessible to the manufacturer cloud 122). The manufacturer cloud 122 can obtain the pre - existing encryption key from, for example, one of the database systems in the database system 132.

[0045] Additionally, when the manufacturer cloud 122 generates its own random nonce, it also encrypts it using the pre - existing encryption key. The nonce generated by the manufacturer cloud 122 is specific to the manufacturer cloud 122 and is thus referred to herein as "cloud nonce data" or simply "cloud nonce". As further described below, the randomly generated cloud nonce will be used to generate a "secondary encryption key" that does not depend on the pre - existing key pair known to both the manufacturer cloud 122 and the sound processing unit 110. The encrypted sound processing nonce and the encrypted cloud nonce (each encrypted using the pre - existing encryption key known to both the manufacturer cloud 122 and the sound processing unit 110) form an encrypted data block to generate an encrypted authentication message, which, as shown by arrow 244, is sent to the external device 106.

[0046] The encrypted authentication message cannot be interpreted by the external device 106 because it is not familiar with the encryption scheme between the sound processing unit 110 and the manufacturer cloud 122 (i.e., does not know the pre - existing key pair). Thus, as shown by arrow 246, the external device 106 passes the encrypted authentication message to the sound processing unit 110.

[0047] Upon receiving the encrypted authentication message, the sound processing unit 110 is configured to perform encryption processing to decrypt the encrypted authentication message using the same pre - existing key pair described above. This process may take a relatively long period of time (e.g., 10 seconds to 12 seconds) because the pre - existing key pair is complex (i.e., complex encryption algorithm) and because the sound processing unit 110 has limited available power and computing capabilities. That is, the sound processing unit 110 is a battery - powered device configured to be worn by the recipient. As such, the sound processing unit 110 has constraints that limit the amount of power and processing capabilities that can be allocated to cryptographic processing, such that the pre - existing encryption key 111 is suitable for low - power devices.

[0048] If the sound processing unit 110 successfully decrypts the received encrypted authentication message, the sound processing unit determines that it is communicating with the manufacturer cloud 122 (i.e., not being spoofed or intercepted). That is, by decrypting the encrypted authentication message, the sound processing unit 110 verifies the authenticity of the manufacturer cloud to know that it is communicating with the genuine manufacturer cloud. As a result, the sound processing unit 110 now has the cloud nonce. Then, the sound processing unit 110 is configured to randomly generate a new encryption key using the cloud nonce that can be used for future communication with the manufacturer cloud 122. This randomly generated encryption key is sometimes referred to herein as the secondary encryption key and is a randomly generated block of binary data.

[0049] The sound processing unit 110 encrypts the secondary encryption key again using the same pre - existing key pair described above (i.e., the sound processing unit 110 generates an encrypted payload that includes the secondary encryption key), and as shown by arrow 248, sends it to the external device 106. Again, since the secondary encryption key is encrypted, the external device 106 cannot interpret the received payload. Thus, as shown by arrow 250, the external device 106 sends the encrypted payload (secondary encryption key) to the manufacturer cloud 122.

[0050] Upon receiving the encrypted payload, the manufacturer cloud 122 decrypts the secondary encryption key using the same pre - existing key pair described above. Receiving the secondary encryption key enables the manufacturer cloud 122 to determine / verify that the sound processing unit 110 is genuine. As a result, the manufacturer cloud 122 can generate a response message and send it to the sound processing unit 110, which indicates that the secondary encryption key has been accepted. This response message is shown in Figure 4 by arrow 252 (i.e., a message from the manufacturer cloud 122 to the external device 106) and arrow 254 (i.e., a message from the external device 106 to the sound processing unit 110).

[0051] The manufacturer cloud 122's acceptance of the secondary encryption key indicates that the manufacturer cloud has accepted using the secondary encryption key to encrypt communications sent to the sound processing unit 110. That is, after accepting the secondary encryption key, the manufacturer cloud 122 is configured to encrypt all communications destined for the sound processing unit 110 using the secondary encryption key, and vice versa. Since the receiving device (either the manufacturer cloud 122 or the sound processing unit 110) has the secondary encryption key, the encrypted communications can be decrypted and recovered.

[0052] Communications 240 through 254 illustrate the first (encryption) phase of the technique proposed herein. At the end of the encryption phase, both the sound processing unit 110 and the manufacturer cloud 122 have verified the authenticity of the other party, are able to communicate securely with each other via the intermediate relay device, and the intermediate device cannot intercept any communications transmitted between the sound processing unit 110 and the manufacturer cloud 122.

[0053] As noted, the encryption phase ensures that the sound processing unit 110 and the manufacturer cloud 122 can communicate with each other. However, an important part of this communication is the generation of the secondary encryption key and its use to support the pre - existing encryption key (i.e., replacing the pre - existing encryption key with the secondary encryption key). More specifically, as described above, some of the initial setup communications between the manufacturer cloud 122 and the sound processing unit 110 are encrypted using the pre - existing encryption key. However, also as described above, this pre - existing encryption key is complex and the associated encryption algorithm may take a relatively long period of time (e.g., 10 seconds to 12 seconds) to execute at the battery - powered sound processing unit 110. Moreover, this delay is a result of the low - power nature of the sound processing unit 110 and the limited processing resources available at the sound processing unit, making the pre - existing encryption key unsuitable for low - power devices.

[0054] Thus, as described above, to avoid significant latency each time a communication is sent to or received from the manufacturer cloud 122, the sound processing unit 110 generates a secondary encryption key that is computationally less expensive than a pre-existing encryption key. The sound processing unit 110 then sends the secondary encryption key to the manufacturer cloud 122 for subsequent use. However, without using the pre-existing encryption key, the secondary encryption key cannot be securely shared between the two parties. In other words, expensive cryptography is used to establish the initial communication. However, once the initial communication is established and the manufacturer cloud 122 and the sound processing unit 110 have verified each other's authenticity, the manufacturer cloud 122 and the sound processing unit 110 use less expensive cryptography for subsequent communications (i.e., the pre-existing encryption key is initially used to establish and securely share the secondary encryption key).

[0055] The concept of replacing computationally expensive encryption keys (i.e., pre-existing encryption keys) with computationally inexpensive encryption keys (i.e., secondary encryption keys) is a result of the computational capabilities and low power availability of the sound processing unit 110. In communications between devices with ample power and computational capabilities, there is no need or desire to switch to computationally less expensive encryption keys. In fact, such a change runs counter to typical network security techniques that attempt to use increasingly sophisticated encryption mechanisms to prevent cyberattacks.

[0056] Specifically returns Figure 4 , the second phase of the techniques presented herein involves authenticating the user at the external device 106 and determining the level of control (if any) that the user can exert on the cochlear implant system 100 from the external device 106. Initially, as Figure 4 shown in block 256 of, the external device 106 (i.e., the medical device control application 162) identifies the user. In one example, a personal identification number (PIN) code is included on a PIN card that is provided to the user by the sound processing unit 110 (e.g., inside the boxed packaging of the sound processing unit). The PIN code is unique to the sound processing unit 110 and is written to the memory 164 of the sound processing unit 110 during the manufacturing process ( Figure 3 ). Since the user owns the PIN card, the PIN code is known only to the sound processing unit 110, the manufacturer cloud 122, and the user.

[0057] In other examples, user login credentials can be used as an identification mechanism. In such examples, the user will log in to a secure user authentication system provided by the manufacturer cloud 122.

[0058] At 256, the external device 106 can prompt the user via the user interface 156 ( Figure 2) Enter the PIN code. As shown by arrow 258, the external device 106 forwards the PIN code entered by the user to the manufacturer cloud 122. As noted, the manufacturer cloud 122 knows the PIN code associated with a particular sound processing unit 110 during manufacturing (e.g., the manufacturer cloud 122 is integrated with a manufacturing system database that stores the PIN codes of the devices used in manufacturing). If the PIN code entered by the user matches the PIN code associated with the particular sound processing unit 110 during manufacturing (i.e., the entered PIN code matches the known PIN from the manufacturing system database), then the manufacturer cloud 122 responds to the external device 106 with a session key that can be used to request an access token. The session key is sent to the external device 106 as indicated by arrow 260 in Figure 4 which is shown by arrow 260.

[0059] Upon receiving the session key, the external device 106 issues a control request to the manufacturer cloud 122. The control request, shown by arrow 262 in Figure 4 , requests the ability to control one or more aspects of the sound processing unit 110. The control request includes several pieces of information, which include the serial number of the sound processing unit 110, the level or type of requested / desired access control, and the session key received from the manufacturer cloud 122. The session key serves as an authenticity check operation to verify that the external device 106 is authorized to make a request to access the sound processing unit 110.

[0060] Upon receiving the control request 262, the manufacturer cloud 122 evaluates the level / type of control requested by the external device 106. The requested level of control can take several different forms and can be based on, for example, one or more user inputs. For example, different levels of control can be granted to recipients, clinicians, and / or surgeons. The level of control can be determined based on a variety of factors, which include the input received at the external device 106. For example, for an elevated access level, it may be required that the user enter additional information that identifies themselves as a clinician or surgeon, and this information is evaluated at the manufacturer cloud 122 (e.g., by comparing the entered information with one or more clinician / surgeon databases).

[0061] Return Figure 4 , if the manufacturer cloud 122 determines that it cannot grant the level of control requested in the control request, the manufacturer cloud is configured to deny the external device 106 access to the sound processing unit 110. In such an example, the manufacturer cloud 122 can also prompt the external device 106 to issue a new control request with a different requested level of access.

[0062] If the manufacturer cloud 122 determines that the control level requested in the control request can be granted, the manufacturer cloud is configured to send a token to the external device 106 that indicates that the external device has been granted the requested access to the sound processing unit 110. More specifically, the manufacturer cloud 122 will send a message, as Figure 2 shown by arrow 264 in, which includes an encrypted access token and an expiration date for the access token. The encrypted access token is encrypted using the secondary encryption key (described above), and as such, the external device 106 cannot decrypt the access token. However, the expiration date associated with the access token is not encrypted and allows the external device 106 to know when the token expires and when the external device 106 will need to issue another control request to obtain a new access token.

[0063] As shown by arrow 266, the external device 106 passes the encrypted access token to the sound processing unit 110. Once decrypted by the sound processing unit 110, the access token provides instructions to the sound processing unit 110 to grant the external device 106 access to one or more functions. The specific access level to be granted is identified as part of the access token. The sound processing unit 110 is also provided with the expiration date for the access token, and the expiration date is stored within the sound processing unit. As such, the access token is forced to expire by the sound processing unit 110 at the expiration date. Substantially, the expiration date notifies the sound processing unit that the external device is authorized for a specified period of time and has a specified level of functionality.

[0064] As shown by arrow 268, after receiving and decrypting the access token, the sound processing unit 110 responds to the external device with a message indicating that the access token has been accepted and the requested level of functionality has been unlocked to the sound processing unit 110. Thus, at the end of this authorization phase, the sound processing unit 110 has secure (encrypted) communication between itself and the manufacturer cloud 122, and the authorized user can control one or more functions of the sound processing unit via the external device 106.

[0065] As noted above, an aspect of the second (authorization) phase is that it relies on the secondary encryption key determined during the first (encryption) phase, such that access control is offloaded to the manufacturer cloud 122. That is, the manufacturer cloud 122 is operated as an agent for the sound processing unit 110 in terms of authorization control. In this way, user authorization determination can utilize the processing power and information available at the manufacturer cloud 122, rather than relying solely on the limited processing and information accessible to the sound processing unit 110.

[0066] The embodiments of the present invention have been mainly described above with reference to the cochlear implant system 100 including the external sound processing unit 110. It should be appreciated that the embodiments of the present invention can also be implemented in a cochlear implant system without external components or other implantable medical device systems. For example, the embodiments of the present invention can be implemented in a fully implantable cochlear implant, where all components of the cochlear implant are configured to be implanted under the skin / tissue of the recipient. Since all components of such a cochlear implant are implantable, the cochlear implant is configured to operate for at least a limited period of time without external components. In such an example, the operations of the sound processing unit 110 described above may be performed by implantable components that at least include one or more processors, memories, and wireless transceivers for direct or indirect communication with the external device 106.

[0067] Figure 5 is a flowchart of a method 300 according to an embodiment presented herein. The method 300 begins at 302, where an indirect secure communication channel is established between the implantable medical device system and a central system associated with the manufacturer of the implantable medical device system via an intermediate mobile electronic device. At 304, the indirect secure communication channel is used to authorize a user to wirelessly control one or more functions of the implantable medical device system.

[0068] In summary, the techniques presented herein allow for granting controlled access to an implantable medical device system on a per-user basis by identifying and authenticating the user via a secure channel formed between the implantable medical device system and the central system. The techniques presented herein also allow the device manufacturer to control the level of functionality that a particular user can access on the device.

[0069] Embodiments are described herein with reference primarily to a cochlear implant system and a headset device that operates as a temporary security proxy device for authentication pairing between an external controller and an implantable component. However, as noted above, embodiments of the present invention may be used in other implantable medical device systems that utilize different external components other than a headset device. In such embodiments, the external component is a device that is coupled / attached to a recipient to form a tightly coupled link with the implantable component, which includes other partially and fully implantable auditory prostheses such as auditory brainstem stimulators, bone conduction devices, hybrid devices, implantable acoustic devices (such as middle ear implants and direct acoustic cochlear stimulators), and / or other implantable medical devices (such as implantable pacemakers, defibrillators, functional electrical stimulators, pain relief stimulators, visual prostheses, implantable sensors, and / or other systems having functional implantable components configured to diagnose, prevent, monitor, treat, or manage a disease or injury or its symptoms or, other systems having functional implantable components configured to study, replace, or modify an anatomical structure or physiological process).

[0070] It should be appreciated that the embodiments presented herein are not mutually exclusive.

[0071] The invention described and claimed herein is not limited to the scope of the specific preferred embodiments disclosed herein, since these embodiments are intended to illustrate rather than limit several aspects of the invention. Any equivalent embodiments are intended to be within the scope of the invention. Indeed, various modifications of the invention, in addition to those described and recited herein, will become apparent to those skilled in the art from the foregoing description. These modifications are also intended to fall within the scope of the appended claims.

Claims

1. A method for security authorization, comprising: receiving, at a central system via an intermediate electronic device, identification information from an implantable medical device system; generating, at the central system, an encrypted verification message using the identification information; sending the encrypted verification message to the implantable medical device system via the intermediate electronic device, wherein the implantable medical device system verifies the authenticity of the central system by decrypting the encrypted verification message; establishing an indirect secure communication channel between the central system and the implantable medical device system via the intermediate electronic device; and using the indirect secure communication channel to authorize a user to wirelessly control one or more functions of the implantable medical device system via the intermediate electronic device.

2. The method according to claim 1, wherein the intermediate electronic device cannot decrypt any communication transmitted between the implantable medical device system and the central system over the indirect secure communication channel.

3. The method according to claim 1, wherein the implantable medical device system communicates with the intermediate electronic device via a short-range wireless communication channel, and wherein the central system communicates with the intermediate electronic device via one or more network links.

4. The method according to claim 1, wherein establishing the indirect secure communication channel between the implantable medical device system and the central system comprises: negotiating a secondary encryption key between the implantable medical device system and the central system using a pre-existing encryption key known to both the implantable medical device system and the central system, the secondary encryption key being used to encrypt communications sent over the indirect secure communication channel between the implantable medical device system and the central system.

5. The method according to claim 1, wherein the identification information includes the serial number of components of the implantable medical device system, and implantable medical device system nonce data, and wherein the implantable medical device system nonce data includes a series of randomly generated information / data bytes.

6. The method according to claim 5, wherein generating the encrypted verification message using the identification information comprises: using the implantable medical device system nonce data to generate an encrypted verification message including nonce data specific to the central system.

7. The method according to claim 6, further comprising: encrypting the implantable medical device system nonce data using a pre-existing encryption key known to both the implantable medical device system and the central system; randomly generating the nonce data specific to the central system; encrypting the nonce data specific to the central system using the pre-existing encryption key; and sending, via the intermediate electronic device, the encrypted implantable medical device system nonce data and the encrypted nonce data specific to the central system in the encrypted verification message to the implantable medical device system.

8. The method according to claim 7, further comprising: At the implantable medical device system, use the pre - existing encryption key to decrypt the nonce data specific to the central system; Generate a secondary encryption key based on the nonce data specific to the central system; Use the pre - existing encryption key to encrypt the secondary encryption key; And Send the encrypted secondary encryption key to the central system via the intermediate electronic device.

9. The method according to claim 8, further comprising: At the central system, use the pre - existing encryption key to decrypt the secondary encryption key to extract the secondary encryption key; And Configure the central system to use the secondary encryption key for future communication with the implantable medical device system.

10. The method according to claim 9, further comprising: Generate a response message indicating that the secondary encryption key has been accepted for future use by the central system; Use the secondary encryption key to encrypt the response message; And Send the encrypted response message to the implantable medical device system via the intermediate electronic device.

11. A system comprising an implantable medical device system, a central system, and an intermediate electronic device, wherein the central system is configured to: Receive identification information from the implantable medical device system via the intermediate electronic device; Use the identification information to generate an encrypted authentication message; and Send the encrypted authentication message to the implantable medical device system via the intermediate electronic device, wherein the implantable medical device system verifies the authenticity of the central system by decrypting the encrypted authentication message, wherein the central system is configured to establish an indirect secure communication channel with the implantable medical device system via the intermediate electronic device, and wherein the indirect secure communication channel can be used by an authorized user to wirelessly control one or more functions of the implantable medical device system via the intermediate electronic device.

12. The system according to claim 11, wherein the intermediate electronic device cannot decrypt any communication transmitted between the implantable medical device system and the central system on the indirect secure communication channel.

13. The system according to claim 11, wherein the implantable medical device system is configured to communicate with the intermediate electronic device via a short - range wireless communication channel, and wherein the central system is configured to communicate with the intermediate electronic device via one or more network links.

14. The system according to claim 11, wherein, in order to establish the indirect secure communication channel between the implantable medical device system and the central system, the implantable medical device system is configured to: Negotiate a secondary encryption key using a pre - existing encryption key known to both the implantable medical device system and the central system, the secondary encryption key being used to encrypt communications sent on the indirect secure communication channel between the implantable medical device system and the central system.

15. The system according to claim 11, wherein the identification information includes the serial numbers of the components of the implantable medical device system, and the implantable medical device system nonce data, and wherein the implantable medical device system nonce data includes a series of randomly generated information / data bytes.

16. The system according to claim 15, wherein in order to use the identification information to generate the encrypted authentication message, the central system is configured to: Use the implantable medical device system nonce data to generate an encrypted authentication message that includes nonce data specific to the central system.

17. One or more non-transitory computer-readable storage media, comprising instructions that, when executed by a processor of a central system, cause the processor to: Receive identification information from an implantable medical device system via an intermediate electronic device; Use the identification information to generate an encrypted authentication message; Send the encrypted authentication message to the implantable medical device system via the intermediate electronic device, wherein the implantable medical device system authenticates the authenticity of the central system by decrypting the encrypted authentication message; Establish an indirect secure communication channel with the implantable medical device system via the intermediate electronic device, and Use the indirect secure communication channel to authorize a user to wirelessly control one or more functions of the implantable medical device system via the intermediate electronic device.

18. The one or more non-transitory computer-readable storage media according to claim 17, wherein the instructions are operable to establish the indirect secure communication channel with the implantable medical device system, and the one or more non-transitory computer-readable storage media include instructions that are operable to: Negotiate a secondary encryption key using a pre-existing encryption key known to both the implantable medical device system and the central system, the secondary encryption key being used to encrypt communications sent over the indirect secure communication channel between the implantable medical device system and the central system.

19. The one or more non-transitory computer-readable storage media according to claim 17, wherein the identification information includes the serial numbers of the components of the implantable medical device system, and the implantable medical device system nonce data, and wherein the implantable medical device system nonce data includes a series of randomly generated information / data bytes.

20. The one or more non-transitory computer-readable storage media according to claim 19, wherein the instructions are operable to use the identification information to generate encrypted authentication information, and the encrypted authentication information includes instructions that are operable to: Use the implantable medical device system nonce data to generate encrypted authentication information that includes nonce data specific to the central system.

Images