WO2013020045A2

WO2013020045A2 - Cloud calibration of a test device

Info

Publication number: WO2013020045A2
Application number: PCT/US2012/049511
Authority: WO
Inventors: Pingyi Yan; Zeming M. GAO
Original assignee: Coentre Ventures Llc
Priority date: 2011-08-03
Filing date: 2012-08-03
Publication date: 2013-02-07
Also published as: WO2013020045A3

Abstract

In some examples, a computing device may receive a request for calibration over a network, such as from a test device or another device. The request may include at least one identifier. The computing device may determine, based at least in part on the identifier, calibration information corresponding to a substance for use with the test device. The computing device may send, to the test device, or to an intermediary device, the calibration information corresponding to the substance. In some instances, the identifier received with the calibration request may identify a particular batch of reagent, and the calibration information may be batch-specific calibration information that corresponds to the particular batch of reagent. In some implementations, the computing device may be included in a cloud tooling platform able to provide services remotely to one or more devices.

Description

CLOUD CALIBRATION OF A TEST DEVICE

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of, and priority to, U.S. Provisional Patent Application No. 61/514,503, filed August 3, 2011, which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

[0002] This disclosure relates to the technical field of performing remote operations over a network.

BACKGROUND

[0003] Medical devices may be used to diagnose, identify, monitor or otherwise determine medical conditions or other health related information. For example, medical devices may be used in the diagnosis, cure, mitigation, treatment or prevention of diseases or other medical conditions in humans or other animals. As one example, an in vitro diagnostic (IVD) test device may be used to test a specimen derived from a human or animal body for determining health related information. In some examples, IVD test devices or other types of test devices may be used to test the reaction of a specimen to a substance, such as a reagent. For instance, a reagent may include a material or compound that is introduced to a system, such as to determine whether a reaction occurs. Thus, health related information can be determined by examining a reaction of a specimen to a reagent.

[0004] Calibration of medical devices may be performed to enable the medical device to determine accurately health related information. For instance, in the case of a test device that uses a reagent, the reagents may vary widely in molecular types and combinations from one type of test to another. Further, there can be significant variation in reagent properties for the same test, and even from batch to batch of reagents produced by the same manufacturer. Thus, manufacturers may draw samples from a particular batch of a reagent and perform testing in order to determine calibration curves or other calibration parameters for the particular batch of the reagent. [0005] The batch-dependent calibration information determined by the manufacturer may then enable various test devices that use the particular batch of the reagent to provide accurate tests. For example, the calibration data for a particular batch of reagent may be stored on an integrated circuit or similar device, referred to as a "calibration chip," and the calibration chip may be delivered to a user (e.g., a medical professional, a patient, a family member of the patient, in-home caregiver, etc.) of a test device along with the corresponding batch of the reagent.

[0006] According to some conventional techniques, a plurality of test units (e.g., strips, receptacles, vials, etc.) of a reagent from a particular batch are shipped to a user, along with a calibration chip containing corresponding calibration data that is included with the shipment. Before using the received reagent to run actual tests, the user of the test device may use the calibration chip to calibrate the test device for use with the received batch of reagent. For example, the test device may read the calibration chip and run a calibration program to calibrate the test device for use with the corresponding batch of reagent.

SUMMARY

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] Some implementations provide techniques and arrangements for remote calibration of medical devices. For example, a computing device may receive a calibration request over a network from a test device. The calibration request may include at least one identifier. The computing device may determine, based at least in part on the identifier, calibration information corresponding to a substance for use with the test device. The computing device may send, to the test device, the calibration information corresponding to the substance. In some instances, the identifier received from the test device may identify a particular batch of reagent as the substance, and the calibration information may be batch-specific calibration information that corresponds to the particular batch of reagent.

[0009] In some implementations, the computing device may be included in a cloud tooling platform that is able to provide services remotely to one or more devices. For example, the cloud tooling platform may enable machine-to-machine interaction to provide services such as providing calibration information for one or more remote devices, providing signal processing and/or signal analysis for one or more remote devices, providing software of firmware updates for one or more remote devices, and/or providing a cloud user interface for remotely interacting with one or more devices.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items or features.

[0011] FIG. 1 illustrates an example framework for calibration of a test device according to some implementations.

[0012] FIG. 2 illustrates an example system architecture to enable calibration of a remote test device according to some implementations.

[0013] FIG. 3A illustrates an example system architecture to enable remote calibration of a test device according to some implementations.

[0014] FIG. 3B illustrates an example system architecture to enable calibration of a test device using an intermediary device according to some implementations.

[0015] FIG. 4 illustrates select components of an example test device according to some implementations.

[0016] FIG. 5 illustrates select components of one or more example computing devices of a service provider according to some implementations.

[0017] FIG. 6 is a flow diagram illustrating an example process for calibration of a device that may be executed by a computing device of a service provider according to some implementations.

[0018] FIG. 7 is a flow diagram illustrating an example process that may be executed to calibrate a test device according to some implementations.

[0019] FIG. 8 is a flow diagram illustrating an example process for calibration of a device that may be executed by a computing device of a service provider according to some implementations. [0020] FIG. 9 is a flow diagram illustrating an example process for calibration that of a test device may be executed at least partially using a mobile communication device according to some implementations.

[0021] FIG. 10 illustrates an example system architecture to enable remote signal processing for a device according to some implementations.

[0022] FIG. 11 illustrates an example system architecture to enable provision of a cloud user interface according to some implementations.

[0023] FIG. 12 illustrates an example system architecture to enable cloud-based interaction with a device according to some implementations.

DETAILED DESCRIPTION

[0024] This disclosure includes techniques and arrangements for enabling remote calibration of a device, such as a medical device, a measuring device or other test device. For instance, the test device may employ a substance for testing specimens. In some examples, the user of the test device may wish to calibrate the test device for use with a particular reagent or other substance, such as a particular batch of reagent or other substance to be used with the test device. The test device may send a calibration request over a network to a computing device of a service provider. The calibration request may include one or more identifiers. In some examples, the one or more identifiers may include an identifier of the particular batch of the reagent, such as a batch number or other batch identifier provided by the manufacturer of the reagent. In other examples, the one or more identifiers may include an identifier of the test device such as a serial number of the test device, or the like, that may be associated with a particular user account. As still another example, the one or more identifiers may include an identifier of the user such as a user ID, user account number, user name, or the like. For instance, the service provider may cross- reference the identifier of the device and/or the identifier of the user to determine a particular batch of reagent that has been provided to the user for use with the test device.

[0025] When the service provider receives the calibration request from the test device, the service provider may use the one or more identifiers to determine a particular batch of reagent for which the test device is to be calibrated. In some examples, the service provider computing device may send calibration information corresponding to the particular batch of reagent to the test device in response to receiving the calibration request. The test device may receive the calibration information corresponding to the particular batch of reagent, and may execute one or more calibration programs on the test device to calibrate the test device for the particular batch of reagent. Alternatively, the test device may use the calibration information during operation of the test device.

[0026] In other examples, the service provider computing device may run one or more calibration programs based on an identification of the test device and the particular batch of reagent. For instance, the calibration request received from the test device may include one or more readings from the test device based upon introduction of a sample of the reagent to the test device. The service provider computing device may run one or more calibration programs based on the readings from the test device and calibration information for the particular batch of reagent. The service provider computing device may send to the test device calibration setting information to be applied for calibrating the test device for use with the particular batch of reagent. Accordingly, this implementation may take advantage of the additional computing resources available to the service provider computing device for running advanced calibration programs that may not be able to run on the test device.

[0027] The techniques herein may be employed with a variety of different types of test devices and reagents for providing a variety of different types of analysis, diagnostics, assessments, and so forth. Non-limiting examples of tests that may be performed by test devices using substances, such as reagents, may include: blood coagulation, glucose levels, liver enzymes levels, electrolyte levels (such as calcium, sodium and potassium) and other analyte detection, presence of human immunodeficiency virus (HIV), blood gas levels, pregnancy, and tests for the presence of drugs, or other biological agents.

[0028] Additionally, in some examples, the service provider computing device may be included in a cloud tooling platform able to provide services remotely to one or more devices. The cloud tooling platform may provide services such as remote calibration, remote signal processing and analysis, and provision of a cloud user interface for remote or diverse devices.

[0029] For discussion purposes, some example implementations are described in the environment of calibrating a test device that uses reagents for testing. However, the implementations herein are not limited to the particular examples provided, and may be extended to calibration of other types of devices, apparatuses and systems, as will be apparent to those of skill in the art in light of the disclosure herein.

Example Framework

[0030] FIG. 1 illustrates an example framework 100 for remote calibration of a test device 102 according to some implementations. In some examples, rather than using a calibration chip to perform calibration of the test device 102, the remote calibration techniques herein may include accessing calibration information remotely, such as over one or more networks 104. Accordingly, the test device 102 may be able to communicate over the one or more networks 104 with one or more service provider computing devices 106 of a service provider 108. Furthermore, while a single test device 102 is shown in this example, in other examples, a plurality of separate test devices 102 may be able to communicate with the service provider computing device

106 to enable remote calibration of the plurality of test devices 102.

[0031] In some examples, the one or more networks 104 may include a local area network (LAN), a wide area network (WAN), such as the Internet, or any combination thereof, and may include both wired and wireless communication technologies, or any combination thereof, including cellular technologies, Wi-Fi technologies, near-field technologies, and so forth. The test device 102 and the service provider computing device 106 may communicate and interact with one another using any combination of suitable communication and networking protocols, such as Internet protocol (IP), transmission control protocol (TCP), hypertext transfer protocol (HTTP), and the like. For example, the test device 102 may send electronic communications to the service provider computing device 106 and may receive electronic communications from the service provider computing device 106 over the one or more networks 104. Likewise, the service provider computing device 106 may send electronic communications to the test device 102 and may receive electronic communications from the test device 102 over the one or more networks 104.

[0032] In some examples, the service provider 108 may be the same entity as a reagent provider 110 that manufactures or otherwise provides a testing substance, such as a reagent 112, for use by the test device 102. In other examples, the service provider 108 may be a separate entity from the reagent provider 110. Thus, the service provider 108 may provide a service to one or more reagent providers 110 and to one or more users 114 of one or more of the test devices 102. For example, the reagent provider 110 may provide the reagent 110 to a user 114 of the test device 102. The reagent provider 110 may further provide calibration information 116 to the service provider computing device 106. As a result, the service provider 108 may provide calibration services to the user 114 of the test device 102 to enable remote calibration of the test device 102.

[0033] As mentioned above, in some cases, the user 1 14 may calibrate the test device 102 for use with one or more particular reagents 112, such as a particular batch of reagent 112. Depending at least in part on the type of the test device 102, the user 114 may be any of a medical professional, a patient, a family member of a patient, a caregiver of a patient, or any other person using the test device 102. In some examples, the reagent provider 110 may manufacture or otherwise provide the reagent 112 from a particular batch of the reagent 112 to the user 114 for use with the test device 102. Prior to providing the reagent 112 to the user 114 for use with the test device 102, the reagent provider 110 may test the reagent 112 to determine the calibration information 116 for the reagent 112. For instance, the reagent provider 110 may draw one or more samples from the particular batch of the reagent 112 and may perform testing of the one or more samples in order to determine applicable calibration curves or other calibration parameters for the particular batch of reagent 112 with respect to one or more types of test devices 102. In some examples, a calibration curve is a plot of how the response of the test device 102 and/or the reagent 110 changes according to a concentration of an analyte or other substance to be measured. One or more calibration curves and/or other calibration parameters for the particular batch of reagent 112 may be included in the calibration information 116 provided by the reagent provider 110 to the service provider computing device 106.

[0034] The test device 102 may include a device calibration module 118 that may be activated by the user 114 to perform the calibration process. For example, suppose that the user 114 has received the reagent 112, such as a plurality of reagent units, from the reagent provider 110. The user 114 may desire to calibrate the test device 102 for use with the reagent 112. The user 114 may make one or more inputs to the test device 102 to initiate the device calibration module 118 on the test device 102. The device calibration module 118 may send a calibration request 120 over the network 104 to the service provider computing device 106. Depending on the type of the test device 102 and the type of calibration module 118 being executed, the user 114 may introduce a sample of the reagent 112 to the test device 102 before, during or after initiating the calibration request 120.

[0035] Further, the calibration request 120 may include one or more identifiers 122. In some examples, an identifier 122 may identify the reagent 112. For instance, the identifier may by an identification number associated with the particular batch of reagent 112. The identifier 122 for the reagent 112 may be used to identify the corresponding calibration information 116. In other examples, the identifier 122 may additionally, or alternatively, identify the test device 102 and/or the user 114. In the case that the identifier 122 only identifies the test device 102 and/or the user 114, rather than the batch of the reagent 112, the identity of the test device 102 and/or the user 114 may be correlated or cross-referenced by the service provider computing device 106 with other information, such as user account information (not shown in FIG. 1), to identify the particular calibration information 116 that is to be used for calibrating the test device 102.

[0036] The service provider computing device 106 may include a service provider calibration module 124. As one example, the service provider calibration module 124 may receive calibration requests and provide a calibration service. In some examples, the service provider calibration module 124 receives the calibration request 120 and, based at least in part on the one or more identifiers 122, identifies the calibration information 116 that corresponds to the reagent 112 provided to the test device 102. Accordingly, in response to the calibration request 120, the service provider computing device 106 may send calibration information 126 to the test device 102. In some cases, the calibration information 126 may be the same as the calibration information 116, while in other cases, the calibration information 126 may contain more or less information than the calibration information 116. For example, the calibration information 116 received from the reagent provider 110 may include a plurality of calibration curves for a particular reagent or reagent batch, in which each calibration curve applies to a different type of test device 102. Thus, in this case, the calibration information 126 sent by the service provider computing device 106 may include the calibration curve and other information for the particular type of the test device 102 that sends the calibration request 120.

[0037] The device calibration module 118 at the test device 102 may receive the calibration information 126 and may use the calibration information 126 to perform calibration of the test device 102 with respect to the particular reagent 1 12 that has been introduced to the test device 102, or that will be used with the test device 102. Thus, in this example, the test device 102 may receive the calibration information 126 and use the received calibration information 126 when executing one or more calibration programs or instructions included in the device calibration module 118. Alternatively, the calibration information 126 may be used when the test device 102 is being used for testing a specimen.

[0038] In other examples, the service provider calibration module 124 on the service provider computing device 106 may perform at least some of the calibration operations. For example, based at least in part on the identifier 122, the service provider calibration module 124 may identify the test device 102 and determine calibration settings for the particular test device 102. For instance, the service provider calibration module 124 may identify a model number for the test device 102, a type of the test device 102, or the like. Furthermore, in this example, the calibration request 120 may include additional readings from the test device 102 obtained based on introduction of the reagent 112 to the test device 102. The service provider calibration module 124 may execute suitable calibration operations or instructions on the service provider computing device 106 to process the calibration information 116 and the calibration request 120 to obtain a set of calibration parameters and/or calibration instructions. The set of calibration parameters and/or calibration instructions may then be transmitted to the test device 102 to calibrate the test device 102 for use with the particular reagent 112. Thus, this example enables utilization of advanced calibration programs and/or techniques, which may take advantage of the additional computing resources provided by the service provider computing devices 106, and which may not be present on the test device 102.

Example Architecture

[0039] FIG. 2 illustrates an example architecture of a system 200 to enable calibration of the test device 102 according to some implementations. In some examples, the test device 102 may include any type of medical device, measuring device, diagnostic device, analysis device, or the like, that uses a reagent, reactant, solvent, enzyme, or other substance, during operation, and that includes a calibration capability for using the test device with the reagent or other substance. Additionally, while FIG. 2 illustrates an example user 114 and test device 102, the described techniques can of course be used with any number of users 114 and test devices 102. In addition, a single user 114 may use a plurality of test devices 102.

[0040] In the illustrated example, the test device 102 is able to communicate with the service provider computing device 106 over the one or more networks 104, as described above. For instance, the test device 102 may communicate with the service provider computing device 106 to access or receive the calibration information 126 over the one or more networks 104. In addition, as described above, the reagent provider 110 may provide calibration information 116 to the service provider 108 over the one or more networks 104. For example, a reagent provider computing device 202 may provide the calibration information 116 to the service provider computing device 106. Alternatively, in other examples, the service provider 108 and the reagent provider 110 may be the same entity, and the service provider computing device 106 may be the same as, or may include the reagent provider computing device 202. Other variations will also be apparent to those of skill in the art having the benefit of the disclosure herein.

[0041] In some examples, the service provider computing device(s) 106 may be part of a cloud tooling platform that enables machine -to-machine (M2M) communication and interaction. Additional details of cloud tooling platforms are discussed below. Thus, in some cases, the service provider computing device(s) 106 may include one or more servers located at a data center, server farm, or other single physical location. In other cases, the service provider computing device(s) 106 may include multiple computing devices 106 located in diverse locations that are physically remote from one another. Further, in some implementations, the services provided by the service provider 108 may be distributed on a plurality of different service provider computing devices 106 in a plurality of diverse locations, or alternatively, concentrated on a single computing device 106 at a single location.

[0042] In some implementations, the device calibration module 118, or other suitable application or module on the test device 102, may communicate with the service provider calibration module 124 on the service provider computing device 106 to obtain the calibration information 126 from the service provider 108. In other examples, the service provider calibration module 124 may expose programmatic interfaces or APIs (application programming interfaces) that the device calibration module 118 on the test device 102 can use to obtain the calibration information 126. [0043] The test device 102 may include one or more communication interfaces 204 that may be used to communicate with the service provider computing device 106 for accessing and interacting with one or more modules of the service provider 108. The one or more communication interfaces 204 may support both wired and wireless connection to various networks, such as cellular networks, radio communications, Wi- Fi networks, short-range or near-field networks (e.g., Bluetooth®, RFID), infrared signals, local area networks, wide area networks, the Internet, and so forth. For example, the communication interface 204 may allow the test device 102 to access a wireless communication network and/or the Internet, and receive calibration information from the service provider 108 or other network location. In some examples, the communication interface(s) 204 include a cellular network chip (e.g., a subscriber identity module) that may be built-in or added on to the test device 102.

[0044] In some examples, the test device 102 may further include a user interface module 206 for presenting a user interface 208 on a display 210 that may be part of, or associated with, the test device 102. Additionally, the test device 102 may include a device calibration program 211 that may perform calibration of the test device 102, such as under control of the calibration module 118. For instance, the device calibration program 211 may be part of the device calibration module 118 or may be separate therefrom. The device calibration program 211 may receive the calibration information 126 as an input, and may use the calibration information 126 when calibrating the test device 102. For example, the calibration information 126 may include a calibration curve for the reagent 112 or other substance to be used with the test device 102. In some implementations, the user interface module 206, the device calibration module 118, and/or the device calibration program 211 may be separate modules or applications. In other implementations, the user interface module 206, the device calibration module 118, and the device calibration program 211 may all be part of the same module or computer program for presenting the user interface 208 and calibrating the test device 102. For example, the user interface module 206, the device calibration module 118, and the device calibration program 211 may represent different functionalities of the same module.

[0045] The user interface module 212 may present one or more interfaces for displaying information related to calibrating the test device 102, and may further present information related to using the test device 102 for testing. For example, the test device may include one or more test programs 212 that are executed on the test device during use of the test device 102. Thus, the user interface 208 may be any suitable type of interface to enable a user to interact with the test device 102 to calibrate and use the test device 102. Examples of suitable technologies for providing the user interface 208 include any of HTML (hypertext markup language), JavaScript®, CSS (Cascading Style Sheets), widgets, C, C+, Java, or any combination thereof, or any other suitable technology, programming language, or graphics rendering software.

[0046] The test device 102 may further include a reagent receiver 214 and one or more sensors 216. For example, depending on the type of the test device 102, the reagent 112 may be packaged in a plurality of reagent units 218, such as one or more reagent strips, vials, trays, ampoules, slides, or the like. The reagent receiver 214 may receive one of the reagent units 218 during use of the test device 102. As one example, during calibration, the reagent receiver 214 may receive one of the reagent units 218 or a designated calibration reagent unit to be used during calibration. The sensor(s) 216 may be calibrated based at least in part on the reagent unit 218 (or designated calibration reagent unit) and the calibration information 126 received from the service provider 108, as discussed above. In some examples, the sensor(s) 216 may be optical sensors, while in other examples, the sensor(s) 216 may be any of numerous other types of sensors, such as chemical, biological, electrical, ultrasonic, temperature, and so forth.

[0047] In addition, in some examples, a batch identifier 220 may be provided with the reagent 112. For instance, the batch identifier 220 may be an identification number or identification code that the user 114 may enter into the user interface 208 to be included with the calibration request 120. As another example, the batch identified 220 may be encoded as a barcode, magnetic strip or other machine-readable indicia that may be scanned by a scanner, reader or the like included with the test device 102. As still another example, an RFID (radiofrequency identification) tag may be embedded in one or more of the reagent units 118 to provide an identification of the batch of reagent corresponding to the particular reagent unit 118. The test device 102 may include an RFID reader having the ability to read the RFID tag for determining the batch identifier 220. Numerous other variations will be apparent to those of skill in the art in light of the disclosure herein.

[0048] The service provider 108 may include the service provider calibration module 124 as described above. For example, a service provider calibration module 124 may receive the calibration request 120 from the test device 102 and in response may send (or make available for download) the calibration information 126 to the test device 102 over the network(s) 104. Further, in some examples, the service provider calibration module 124 may expose programmatic interfaces or APIs that the test device 102 can use to obtain calibration information 126 with minimal device or user interaction.

[0049] In the illustrated example, the service provider computing device 106 includes a batch identification module 222 that may be executed to identify a particular batch of a reagent corresponding to a calibration request 120. In some examples, the batch identification module 222 may be included as part of the service provider calibration module 124, while in other examples, the batch identification module may be a separate module. For instance, the batch identification module 222 may identify batch-specific calibration information 224 included in the calibration information 116. In some examples, the batch identification module 222 may merely identify the batch-specific calibration information 224 based on a batch identifier 220 included with the identifier(s) 122 provided in the calibration request 120.

[0050] In other examples, as mentioned above, the batch identification module 222 may identify a batch corresponding to batch-specific calibration information 224 based at least in part on user information 226 and/or device information 228. For instance, the service provider 108 may maintain user information 226, which may include information related to one or more user accounts 230, such as user contact information, a reagent purchase history, a test device 102 associated with a particular user account 230, and the like. Furthermore, the device information 228 may include a list of device-unique serial numbers or other device identifiers that may be used to correlate a particular device with the user information 226, such as to identify a particular user account 230 corresponding to a particular test device 102. Accordingly, when the identifier(s) 122 identifies at least one of a user 114 or a test device 102, the batch identification module 222 may determine from the user information 226 a reagent purchase history. For example, if the user account shows that a particular batch of reagent 112 was recently purchased by a particular user 114 from which a calibration request 120 is received, the particular batch of reagent may be identified using that information, and thereby, the correct batch-specific calibration information 224 may be identified. Various other techniques for identifying a batch of reagent and the corresponding batch-specific calibration information 224 will be apparent to those of skill in the art having the benefit of the disclosure herein.

[0051] In some implementations, a cloud calibration technique may enable calibration of one or more remote test devices 102. For instance, a reagent provider 110 may assign an identification number or other batch identifier 220 to a batch of reagent 112 and may further associate the batch identifier 220 with the corresponding calibration information 116 provided to the service provider 108. Accordingly, the calibration information may be identified as batch-specific calibration information 224 based on the batch identifier 220. The batch-specific calibration information 224 may be stored in a storage associated with the service provider computing device 106, or the like, such as part of a cloud tooling platform. In some examples, as discussed additionally below, a cloud tooling platform may include one or more interconnected server systems, which may communicate over the Internet, cellular networks, and other communications networks.

[0052] In some cases, the batch identifier 220 for each batch of reagent 112 may be printed on or otherwise provided with each batch of reagent 112, such as on packaging of reagent units 218 of the batch. The test device 102 may be able to read or otherwise transmit the identification number to a cloud tooling platform, such as the service provider computing device 106 in the illustrated example of FIG. 2. In response, the service provider computing device 106 may send the batch-specific calibration information 224 corresponding to the batch identifier 220 to the test device 102. The test device 102 may then execute the device calibration program 211, such as under control of the device calibration module 118, to calibrate one or more sensors 216 on the test device 102 for use with the particular batch of reagent 112. For example, the batch-specific calibration information 224 received from the service provider computing device 106 may be, at least in part, raw calibration data that is input to the device calibration program 211. The device calibration program 211 may execute based on the batch-specific calibration information 224 to calibrate the test device 102 for use with the particular batch of substance corresponding to the batch- specific calibration information 224.

[0053] In some examples, the batch identifier 220 may be first entered into the test device 102 and then transmitted to the service provider 108 from the test device

102. In some cases, based on the batch identifier 220 and user account information

230, the service provider computing device 106 may identify the batch of reagent 112 and may further identify the particular test device 102, such as based on a purchase history, user account information 230, and the like. Alternatively, the identifier(s) 122 included with the calibration request 120 may include an identifier of the test device 102 and/or the user 114 to enable the service provider computing device 106 to recognize automatically the identity of the test device 102. Accordingly, in some examples of the remote calibration technique herein, a calibration chip is not used, significantly reducing the costs over conventional techniques. Instead, the batch identifier 220, such as an identification number (e.g., a character string), a barcode 232, a magnetic strip, an RFID tag, or the like, may be provided with the reagent 112 delivered to the user 114. For instance, the identification number, the barcode 232, and/or the magnetic strip may be printed on the packaging of the reagent 112 and/or the RFID tag may be included with the packaging. Further, the test device 102 may include an identifier reader 234, such as a barcode reader, a magnetic strip reader, an RFID reader, or other device able to electronically read the identifier (e.g., using optical character recognition) to determine automatically the batch identifier 220 without requiring manual user entry.

[0054] As one alternative, rather than having an identifier reader 234 included with the test device 102, a conventional smart phone or other mobile device 236 having network connectivity may be used instead. For instance, the test device 102 and the mobile device 236 may be registered with the service provider 108 and both associated with the same user account 230. The mobile device 236 may then be used to read the barcode 232 or a code number containing the reagent batch identifier 220. For example, the mobile device 236 may include a camera or other mechanism capable of electronically detecting or reading the barcode 232 or recognizing a character string using optical character recognition. The mobile device 236 may then transmit the batch identifier 220 to the service provider computing device 106 based at least in part on the prior registration. Additional details of registering a mobile device 236 with a cloud tooling platform are discussed below.

[0055] Accordingly, rather than the test device 102 transmitting the calibration request 120, the mobile device 236 may transmit the calibration request 120 to the service provider computing device 106. In response, service provider calibration module 124 on the service provider computing device 106 may transmit the batch- specific calibration information 224 corresponding to the barcode 232 or code number to the test device 102 based on the association of the mobile device 236 and the particular test device 102 with the same user account 230. The test device 102 may receive the batch-specific calibration information 224 and may apply the calibration parameters and/or calibration instructions (commands or settings) on the test device 102.

[0056] Because more and more mobile devices 236 are able to scan or obtain an image of a barcode 232 or identification number, the above technique may further reduce the cost of the test device 102 by eliminating the identifier reader 234 from the test device 102. In addition, employing a mobile device 236 with the test device 102 may result in additional benefits, such as that offered by a cloud user interface, as described additionally below. For example, the user interface presented on the mobile device 236 may communicate with service provider computing device, which may in turn communicate with the test device 102. Accordingly, as discussed additionally below, a user of the test device, a medical professional, or the like, may use a mobile device 236 to control remotely the test device 102, such as for causing the test device 102 to request the calibration information 126 and/or for performing other functions.

[0057] FIG. 3A illustrates an example architecture of a system 300 to enable remote calibration of the test device 102 according to some implementations. In the illustrated example, the service provider computing device 106 may be or may be part of a cloud tooling platform, and may have one or more device calibration programs 302 stored there on to remotely perform calibration of the test device 102, which may include determining device calibration settings. As one example, the service provider computing device 106 may include a separate device calibration program 302 for each different type of test device 102 for which the service provider 108 provides a calibration service.

[0058] The service provider calibration module 124 may receive the calibration request 120, including the identifier(s) 122, as described above. In addition, depending on the type of the test device 120, the calibration request 120 may further include one or more device readings 304. For example, the user 114 may place a reagent unit 218 (or a designated calibration reagent unit) into the reagent receiver 214 and may obtain one or more device readings 304 that may be included with the calibration request 120, or that may be sent to the service provider computing device 106 separately from the calibration request 120.

[0059] In response to receiving the calibration request 120, the batch identification module 222 may identify the correct batch-specific calibration information 224. In this example, the batch of the reagent 112 may be identified in any of the manners discussed above, such as based on the batch identifier 220, a barcode 232, information from a mobile device 236, a user identity, a device identity, or the like. In some examples, the batch identification module 222 may further identify at least the type of the test device 102. Based on the identification of the type of test device 102 and the batch-specific calibration information, the service provider calibration module 124 may execute a corresponding device calibration program 302 to process the batch-specific calibration data according to the type of the test device 102, and thereby obtain a set of calibration parameters and/or calibration instructions (e.g., commands).

[0060] Further, in some cases, the device calibration program 302 may take into consideration device readings 304 received from the test device 102. For example, the calibration may be performed interactively such that the test device 102 sends a calibration request to the service provider computing device 106; the service provider computing device 106 sends an instruction to the test device 102 in response to the calibration request; the test device 102 performs an operation, such as taking a reading of the reagent or other substance in response to the received instruction; the test device 102 sends a device reading 304 or other information to the service provider computing device 106; the service provider computing device 106 performs one or more calibration operations based on the device reading 302. A plurality of interactions between the test device 102 (and/or an intermediary device) and the service provider computing device 106 may take place during the calibration process. In some cases, calibration instructions sent to the test device 102 may be provided sequentially, such as in response to each reading 304 received from the test device. In other examples, the service provider computing device 106 may send the calibration information following completion of running one or more calibration programs 302 on the service provider computing device 106.

[0061] Following execution of the device calibration program 302, the service provider calibration module 124 may send the obtained calibration parameters and/or calibration instructions (commands) as one or more calibration settings 306 to be applied to the test device 102. The test device 102 receives the batch-specific calibration information 224, which may include the calibration setting(s) 306, calibration parameters, and/or calibration instructions (commands) and may deploy these on the test device 102. [0062] The implementations of FIG. 3A may take advantage of the cloud computing aspect of the cloud tooling platform. For example, with the device calibration program(s) 302 hosted and executed on the service provider computing device(s) 106, individual test devices 102 may be manufactured without significant computing power. Thus, the test devices 102 may be thin components with minimal computing resources, which potentially lowers the manufacturing cost of the test devices 102. In addition, the system of FIG. 3 A may also enable the development and execution of highly advanced device calibration programs, which may not be possible or economical to be hosted and executed on each test device 102. For instance, in some cases, the test device 102 may be unable to execute the device calibration program(s) 302. Furthermore, storing the calibration program(s) 302 on service provider computing device(s) 106 also makes it easier to protect the intellectual property associated with the calibration program(s) 302 and makes it easier to modify or update the calibration program(s) 302, as discussed additionally below with respect to cloud tooling.

[0063] FIG. 3B illustrates an example system architecture 310 to enable calibration of the test device 102 using an intermediary device 312 according to some implementations. In this example, an intermediary device 312, such as a cellular phone, smart phone, tablet computing device, laptop computing device, or other suitable computing device, may be used as intermediary between the test device 102 and the service provider computing device 106 for any of the communications and interactions discussed above. Accordingly, the intermediary device 312 may include one or more processors 314, one or more computer-readable media 316, and one or more communication interfaces 318. Details of types of processors, computer- readable media, and communication interfaces that may be used with some implementations of the intermediary device 312 are discussed additionally below with respect to FIGS. 4 and 5.

[0064] The intermediary device 312 may further include a graphic user interface

(GUI) 320 to communicate over the networks 104 with the service provider computing device 106 and/or the test device 102. For example, the GUI 320 may be, or may be provided by, any of a browser, a dedicated application, a mobile device application (mobile app), or the like, that is maintained on the computer-readable media 316 and executed on the one or more processors 314. Additionally, in some examples, the intermediary device 312 may include a GUI 322 to access the test device 102 locally. For example, the GUI 322 may enable a user 114 to access the test device 102 through a near- field connection, a local Wi-Fi connection, such as may be provided by a wireless router, or optionally, by a direct wired connection 324.

[0065] The intermediary device 312 may further include an identifier reader 326 for reading an identifier 220, as discussed above. For example, depending on the type of the identifier 220, the identifier reader 326 may be configured to read one or more of the barcode 232, an RFID tag 328, a character string 330, a magnetic strip 332, or any other type of identifier that may be read electronically. Alternatively, the intermediary device 312 may include a keyboard, keypad, or other input device (not shown in FIG. 3B) to enable the user 114 to manually input the identifier 220.

[0066] In some examples, the intermediary device 312 may send the one or more identifiers 122 to the service provider computing device(s) 106 as part of a calibration request 120, as discussed above with respect to FIGS. 2 and 3 A. In response, in the case that that test device 102 runs a device calibration program 211 on the test device, the intermediary device 312 may receive the calibration information 126, such as calibration data that may be the input of a device calibration program that is executed on the test device 102, and that may include a calibration curve and other calibration parameters. The intermediary device 312 may then pass on or otherwise transfer the calibration information 126 to the test device 102. For instance, in some examples, the test device 102 may not have network connectivity. Thus, in some situations, the intermediary device 312 may serve to connect the test device to the network, while in other situations, the intermediary device 312 may merely transfer the received calibration information 126 to the test device 102, such as over the wired connection 324 using the GUI 322.

[0067] As another example, such as in the case of FIG. 3A, in which the service provider computing device 106 executes a device calibration program 302 on the service provider computing device 106, the intermediary device 312 may receive one or more device readings 304 from the test device 102, and may send the device reading(s) 304 to the service provider computing device 106. The service provider computing device 106 may receive the device reading(s) 304 and the identifier(s) 122, may execute a device calibration program 302 on the service provider computing device 106, and may return calibration information 126 to the intermediary device

312 or the test device 102. For example, the calibration information 126 in this case may be the output of the device calibration program 302 executed on the service provider computing device 106, and may include device settings, such as device calibration parameters and calibration instructions that may be used to directly calibrate the test device 102.

[0068] Furthermore, in the case that the device calibration program 302 executed on the service provider computing device 106 interactively calibrates the test device 102 based on one or more readings received from the test device 102, the intermediary device may transfer the device readings 304 to the service provider computing device 106, and may transfer instructions from the service provider computing device 106 to the test device 102. Additionally, in an alternative implementation, the intermediary device 312 may include at least one of the device calibration program 211 or the device calibration program 302 for execution on the intermediary device 312. Other variations will also be apparent to those of skill in the art in light of the disclosure herein.

Example Test Device

[0069] FIG. 4 illustrates select example components of the test device 102 that may be used to implement the functionality described above according to some implementations. In a very basic configuration, the test device 102 includes, or accesses, components such as at least one control logic circuit, central processing unit, or other type of processor 402 and one or more computer-readable media 404. In some examples, each processor 402 may itself comprise one or more processors or processing cores. Alternatively, in other examples, the test device 102 may be a thin component having minimal processing resources merely sufficient to execute a test program during use of the test device 102, while a calibration program may be executed remotely on the service provider computing device 106 of the cloud tooling platform, as discussed above.

[0070] Depending on the configuration of the test device 102, the computer- readable media 404 may be an example of tangible non-transitory computer storage media and may include volatile and nonvolatile memory and/or removable and nonremovable media implemented in any type of technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Such computer-readable media may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other computer-readable media technology, or any other medium that can be used to store information and which can be accessed by the processor 402 directly or through another computing device. Accordingly, the computer-readable media 404 may include computer storage media able to store and maintain instructions, modules or components executable by the processor 402.

[0071] The computer-readable media 404 may be used to store any number of functional components that are executable by the processor 402. In some implementations, these functional components comprise instructions or programs that are executable by the processor 402 and that, when executed, implement operational logic for performing the actions attributed above to the test device 102. Functional components of the test device 102 maintained in the computer-readable media 404 may include the device calibration module 118, executable by the processor 402, such as for sending a calibration request, receiving calibration information and calibrating the test device 102 for use with a particular batch of reagent or other substance.

Additional functional components stored in the computer-readable media 404 may include the user interface module 206, as described above, which may be executed by the processor 402 for presenting the user interface 208 to enable a user to interact with the test device 102, such as during calibration or operation. Other functional components may include the device calibration program 211 that is used to calibrate the test device when the calibration information 126 is received as an input, and one or more test programs 212 that are used during operation of the test device 102 for determining health related information. Depending on the type of the test device 102, the computer-readable media 404 may also optionally include other functional components, such as other modules, applications, programs, drivers and so forth.

[0072] The computer-readable media 404 may also store data, data structures, and the like that are used by the functional components. For example, data stored by the computer-readable media 404 may include the calibration information 126 received from the service provider to be used with a particular batch of reagent or other substance. As mentioned above, in some implementations, the calibration information 126 may be raw calibration data that is the input to the device calibration program 211 that is executed on the test device 102. In other implementations, the calibration information may be processed calibration settings or instructions that are output by another device and provided to the test device 102. The test device 102 may also maintain other data, which may include, for example, data produced by or used by the test programs 212, data used by the user interface module 206, and so forth. Further, in some implementations, the test device 102 may include many other logical, programmatic and physical components, of which those described are merely examples that are related to the discussion herein.

[0073] FIG. 4 further illustrates the display 210, which may be passive, emissive or any other form of display. In some examples, the display may include any suitable type of display, such as a liquid crystal display, plasma display, light emitting diode display, organic light emitting diode display, and so forth. Additionally, in some examples, the display 210 may have a touch sensor associated therewith to enable touch inputs from a user. Further, in other examples, the test device 102 may not include a display.

[0074] The test device 102 may further include the one or more communication interfaces 204, the reagent receiver 214 for receiving the reagent or other substance, the one or more sensors 216, and the barcode reader 234 discussed above. The test device 102 may further be equipped with various other input/output (I/O) components 406. Such I/O components 406 may include various user controls (e.g., buttons, a joystick, a keyboard, a keypad, a mouse, etc.), speakers, a microphone, a camera, bar scanner, connection ports, and so forth. For example, the test device 102 may include suitable drivers configured to accept input from a keypad, keyboard, or other user controls and devices included as the I/O components 406. For instance, the user controls may include navigational keys, a power on/off button, selection keys, and so on. Additionally, depending on the type, the test device 102 may include various other components that are not shown, examples of which may include removable storage, a power source, such as a battery or power control unit and so forth.

Example Computing Device(s)

[0075] FIG. 5 illustrates select components of one or more service provider computing devices 106 that may be used to implement the functionality of the service provider 108 according to some implementations. Services of the service provider

108 may be hosted on one or more servers or other types of service provider computing devices 106 that may be embodied in any number of ways. For instance, in the case of a server, the service provider 108 may be implemented on a single server, a cluster of servers, a server farm or data center, a cloud hosted computing service, and so forth, although other computer architectures (e.g., a mainframe architecture) may also be used. Further, while the figures illustrate the components of the service provider 108 as being present in a single location, it is to be appreciated that these components may be distributed across different computing devices and locations in any manner. Generally, the calibration services provided by the service provider 108 may be implemented by one or more computing devices, with the various functionalities described above distributed in various ways across the different computing devices. The computing devices may be located together or separately, and organized, for example, as virtual servers, server banks and/or server farms. The described functionality may be provided by the servers of a single entity or enterprise, or may be provided by the servers and/or services of multiple entities or enterprises. As mentioned above, in some examples, the service provider 108 may be the same entity as the reagent provider 110, while in other examples, the service provider 108 may be a separate entity from the reagent provider 110.

[0076] As illustrated in FIG. 5, an example service provider computing device

106 includes one or more processors 502, one or more computer-readable media 504, and one or more communication interfaces 506. The processor(s) 502 may be a single processing unit or a number of processing units, and may include single or multiple computing units, or multiple processing cores. The processor(s) 502 can be configured to fetch and execute computer-readable instructions stored in the computer-readable media 504 or other computer-readable media.

[0077] The computer-readable media 504 may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules or other data. Such computer-readable media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, solid state storage, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store desired information and that can be accessed by a computing device. Depending on the configuration of the computing device 106, the computer-readable media 504 may be a type of computer storage media and may be a tangible non-transitory storage media.

[0078] The computer-readable media 504 may be used to store any number of functional components that are executable by the processors 502. In many implementations, these functional components comprise instructions or programs that are executable by the processors 502 and that, when executed, implement operational logic for performing the actions attributed above to the service provider 108. Functional components of the service provider 108 that may be executed on the processors 502 for implementing a service for providing calibration information 202 to test devices 102 include the service provider calibration module 124, the batch identification module 222, and optionally, the device calibration program(s) 302. Additional functional components stored in the computer-readable media 504 may include an operating system 508 for controlling and managing various functions of the service provider computing device 106.

[0079] In addition, the computer-readable media 504 may include, or the service provider computing device 106 may access, data that may include the calibration information 116, which may include the batch-specific calibration information 224. The data may further include the device information 228, such as for identifying test devices 102. The data may further include the user information 226, including information for one or more user accounts 230. The service provider computing device 106 may also include many other logical, programmatic and physical components, of which those described above are merely examples that are related to the discussion herein.

[0080] The communication interface(s) 506 may include one or more interfaces and hardware components for enabling communication with various other devices, such as the test devices 102, over the network(s) 104. For example, communication interface(s) 506 may facilitate communication through one or more of the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi, WiMax, radio) and wired networks. Various different approaches to implementations described herein can be implemented in various environments. For instance, the network(s) 104 may include any suitable network, including an intranet, the Internet, a cellular or wireless network, a LAN, WAN, VPN or any other network or combination thereof. Components used for such a system can depend at least in part upon the type of network and/or environment selected. Protocols and components for communicating via such networks are well known and will not be discussed herein in detail.

[0081] Service provider computing devices 106 may further be equipped with various input/output devices 510. Such I/O devices 510 may include a display, various user interface controls (e.g., buttons, mouse, keyboard, touch screen, etc.), audio speakers, connection ports and so forth. [0082] Various instructions, methods and techniques described herein may be considered in the general context of computer-executable instructions, such as program modules stored on computer storage media and executed by the processors herein. Generally, program modules include routines, programs, objects, components, data structures, etc., for performing particular tasks or implementing particular abstract data types. These program modules, and the like, may be executed as native code or may be downloaded and executed, such as in a virtual machine or other just- in-time compilation execution environment. Typically, the functionality of the program modules may be combined or distributed as desired in various implementations. An implementation of these modules and techniques may be stored on computer storage media or transmitted across some form of communication media.

Example Processes

[0083] FIGS. 6-9 illustrate example processes for calibration of a test device according to some implementations. These processes, as well as the other processes described herein, are illustrated as a collection of blocks in logical flow diagrams, which represent a sequence of operations, some or all of which can be implemented in hardware, software or a combination thereof. In the context of software, the blocks represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures and the like that perform particular functions or implement particular abstract data types. The order in which the operations are described should not be construed as a limitation. Any number of the described blocks can be combined in any order and/or in parallel to implement the process, or alternative processes, and not all of the blocks need be executed. For discussion purposes, the processes are described with reference to the architectures, environments and frameworks described in the examples herein, although the processes may be implemented in a wide variety of other architectures, environments or frameworks.

[0084] FIG. 6 is a flow diagram illustrating an example process 600 that may be executed by a computing device of a service provider in connection with calibration of a test device according to some implementations. [0085] At 602, the computing device receives at least one identifier. For example, the computing device may receive one or more identifiers over a network from at least one of a test device or a mobile communication device. In some examples, the identifier may include at least one of a reagent batch identifier, an identifier of a user of a test device, or an identifier of the test device. In the case that the identifier is an identifier of a particular batch of reagent, the identifier may have been read electronically by either the test device or by the mobile communication device (i.e., an intermediary device).

[0086] At 604, the computing device determines, based at least in part on the identifier, calibration information corresponding to a substance to be used with a device. For example, the computing device may identify a particular batch of a reagent to be used with the test device based at least in part on the received identifier. The computing device may further identify batch-specific calibration information that corresponds to the particular batch of reagent.

[0087] At 606, the computing device sends the calibration information to the device. For example, the computing device may send the calibration information, such as a reagent calibration curve, and/or one or more calibration parameters, to a test device that will be using the particular batch of reagent that corresponds to the calibration information. In some embodiments, calibration information includes calibration data as an input of a device calibration program locally installed on the test device. The test device runs the calibration program in accordance with the received calibration data to result in proper calibration settings of the test device. The calibration information may be sent to the test device either directly or indirectly from the computing device on the server side. For example, the calibration information may be first sent to an intermediary local computing device (such as a cell phone), and then transferred from the intermediary device to the test device (such as through wireless communication, a cable or a removable medium). In other examples, the calibration data received may be the output of a device calibration program executed on the service provider computing device 106. Thus, the calibration data may be used to directly calibrate the test device 102.

[0088] FIG. 7 is a flow diagram illustrating an example process 700 that may be executed in connection with calibrating a test device according to some implementations . [0089] At 702, a device sends an identifier to a computing device over a network. In some examples, the device may be a test device that sends at least one identifier to a service provider computing device. In other examples, the device may be a cellular or mobile communication device that sends the identifier to the computing device. In some cases, the test device or the mobile communication device may electronically read an identifier of a batch of reagent, which is then sent over the network to the computing device.

[0090] At 704, a test device receives, based at least in part on the identifier, calibration information corresponding to a reagent. For example, the test device may receive calibration information corresponding to a particular batch of the reagent. As illustrated above, the calibration information may be received either directly or indirectly at the test device.

[0091] At 706, the test device applies a least one calibration parameter to the test device based at least in part on the received calibration information. For example, the test device may execute a calibration program using the received calibration information.

[0092] FIG. 8 is a flow diagram illustrating an example process 800 that may be executed by a computing device of a service provider in connection with calibration of a test device according to some implementations.

[0093] At 802, the computing device identifies batch-specific calibration data based at least in part on a received identifier. In some examples, the identifier may identify the batch of reagent for which calibration is desired. In other examples, the identifier may identify at least one of a user, a test device, or a user account. The computing device may cross-reference the one or more identifiers to identify batch- specific calibration information.

[0094] At 804, the computing device identifies a test device and determines calibration requirements for the test device. For example, the computing device may identify the test device based at least in part on a received identifier, or by cross- referencing other received information with user account information.

[0095] At 806, the computing device executes a calibration program suitable to the identified test device to obtain one or more calibration parameters and/or calibration instructions. For example, the computing device may execute a device calibration program on the computing device to determine one or more calibration settings for the test device based at least in part on the batch-specific calibration information. In this embodiment, the calibration instructions, parameters or settings may be an output of running a cloud-based calibration program installed at a server computer and then transmitted to the test device to be implemented.

[0096] At 808, the computing device sends the one or more calibration parameters and/or instructions to the test device. For example, the computing device may send the calibration information to the test device based at least in part on the user account information.

[0097] At 810, the test device receives and executes the one or more calibration parameters and/or instructions on the test device. For example, the test device may receive and apply the calibration settings determined by the calibration program executing on the cloud tooling platform.

[0098] FIG. 9 is a flow diagram illustrating an example process 900 that may be executed at least in part by a mobile communication device and/or a test device according to some implementations.

[0099] At 902, a user may register a test device and a mobile communication device with a cloud tooling platform to be associated with the same user account. For example, the user may register a cell phone or other mobile device and at least one test device with the cloud tooling platform for association with the user's account with the cloud tooling platform.

[00100] At 904, the mobile device electronically reads an identifier of a batch of reagent. For example, in the case that the identifier is a barcode the mobile device may be used to scan, capture or read an image of the barcode. Alternatively, in the case that the identifier is a string of characters, such as an identification number, the mobile device may electronically read the string of characters such as by using optical character recognition. Thus, the mobile device may be an intermediary device between the test device and the service provider computing device 106.

[00101] At 906, the mobile device sends the identifier to the cloud tooling platform. In some examples, the mobile device may send the identifier to the cloud tooling platform using, at least in part, a cellular network connection. The cloud tooling platform may automatically identify the user account associated with the mobile device based at least in part upon the registration of the mobile device with the cloud tooling platform.

[00102] At 908, the test device receives, from the cloud tooling platform, calibration data corresponding to the particular batch of the reagent based on the identifier sent by the mobile device and based at least in part on the identity association of the mobile device and the test device with the same user account at the cloud tooling platform. For example, following identification of the user account based on the registration of the mobile device, the cloud tooling platform may identify a test device to which to send the calibration data. The calibration information may be sent to the test device either directly or indirectly from the cloud tooling platform. For example, the calibration information may be first sent to the mobile device, and then transferred to the test device (through wireless, a cable or a removable medium). In this mode, the mobile device may or may not be tied with the test device to the same account. For example, the local computing device may first transmit the batch identifier and the test device information to the computing device on the cloud tooling platform, and then receive the calibration information therefrom. It may be up to the operator of the test device and the mobile device to decide to apply the received calibration information to the correct test device.

[00103] At 910, the test device applies the calibration data corresponding to the particular batch of the reagent to the test device. For example, the test device may execute one or more calibration programs based at least in part on the received calibration data. Alternatively, the cloud tooling platform may run a cloud-based calibration program using the received calibration information as input and generate a calibration output in the form of instructions, parameters or settings to be sent to the test device to be applied. In some embodiments, the calibration may be programmed as an interactive calibration process involving one or more reading-instruction exchanges between the test device and the cloud.

[00104] The example processes described herein are only examples of processes provided for discussion purposes. Numerous other variations will be apparent to those of skill in the art in light of the disclosure herein. Further, while the disclosure herein sets forth several examples of suitable frameworks, architectures and environments for executing the processes, implementations herein are not limited to the particular examples shown and discussed.

Cloud Tooling Platform

[00105] The development of M2M (machine -to-machine interaction) has opened some exciting applications. With M2M, machines (including all devices or equipment) are more and more interconnected to provide networked access, collaborative functions and device management. As the Internet connects computers, M2M may connect machines to one another. However, M2M has so far focused on connectivity of machines, which is in parallel to the Internet, which initially focused on the connectivity of computers.

[00106] According to some examples herein, cloud tooling may include a system of general tooling of virtually all kinds of devices, machines and equipment through a networked cloud. Thus, in some examples, the word "tooling" may include designing, making, connecting, operating, updating or processing (e.g., signals or data received therefrom) of a device, machine, equipment, or a component thereof. Additionally, in some examples, the word "cloud" may include one or more interconnected server systems, which may communicate over the Internet, cellular networks, and other communications networks. Further, in some examples, the word "device" may be used in a broad and general sense to include a device, apparatus, machine, equipment, or a component thereof, and may be used for any purpose including consumer, personal, home, business, and all industries.

[00107] In some examples, the concept of cloud tooling may be in parallel to cloud computing. For instance, cloud tooling may reach new dimensions beyond M2M, just as cloud computing may extend beyond the original Internet. Thus, the fulfillment of cloud tooling may be as revolutionary as cloud computing.

[00108] Some implementations herein may include a system that comprises a cloud-based platform which remotely interfaces with a variety of devices, and which allows the devices to interface with each other through the cloud (e.g., over one or more networks). Each device may be enabled to connect to the cloud-based platform for communication and other interfaces.

[00109] The communication from the device to the cloud tooling platform may be as simple as passing identity information to enable the cloud tooling platform to recognize the device, which may have a unique identifier recognizable at the cloud tooling platform. The communication from the cloud tooling platform to the device may be data-rich in order to deliver product updates, processed data, applications, programs, and instructions from the platform to the device. In some implementations, the communication from the device to the cloud tooling platform may also be data- rich in order to deliver device information, such as information for device configuration, status and history, and acquired data such as measurements and user inputs. With the data communicated from the device, the cloud tooling platform may perform data collection, signal processing, diagnosis, data pulling and statistics, and give the device tooling recommendations and instructions. In addition to the data communications, application programming interfaces (API) may be installed on servers in the cloud tooling platform and in some cases on the devices as well to ensure proper device interfacing over the cloud.

[00110] As discussed below in further detail, the cloud tooling platform herein may extend to all kinds of devices including home electronics; personal electronics; medical devices, including both hospital/clinic and home applications; and devices, equipment and components used in all types of businesses and industries, such as healthcare, energy, transportation, retail, finance, education, information technology, communication technology, asset management, logistics, manufacturing and other industrial applications.

[00111] The connection may be either on-demand or always-on. The connection may function in the background non-intrusively. In one implementation, the communications between the cloud tooling platform and the devices may be based on cellular networks, such as CDMA networks (e.g., 2G, 3G, 4G and beyond) used for cell phones, or other wireless communications. In some examples, each device may include a built-in chip or module and/or a removable/interchangeable chip or module to enable cellular network communications. The chip may include identity recognition abilities, such as a Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM). In some examples, the chips, modules or other cellular communication interfaces may not be featured-rich like that found in a cell phone, but may merely be sufficient to be able to conduct data exchanges.

[00112] In some types of applications, the cloud tooling platform provides downloadable application programs (apps) to extend the functionality of electronic devices connected to the cloud tooling platform. Each electronic device may or may not have its own user interface for downloading and installing the apps. Further, an application platform may be open to third-party developers to develop and submit apps.

[00113] In some implementations, an intermediary device such as a smart phone, a tablet or a cellular network-enabled device may provide a user interface and/or control for one or more functions or one or more electronic devices connected to the cloud tooling platform. For example, the intermediary device may present a user interface for downloading and installing the apps to an electronic device that does not have its own user interface to do the same. In some instances, the intermediary device may further be used as a cloud-based universal remote control of one or more other cloud- connected electronic devices. Multiple applications of the cloud tooling platform are described herein.

Cloud Signal Processing

[00114] Some electronic devices herein may have a signal acquisition function and on-board signal processing ability. These electronic devices may include a signal acquisition unit (e.g., a sensor), a built-in processor, such as a microprocessor, a supporting circuit, firmware and/or software. Although these electronic devices continue to benefit from the increasing processing power of microprocessors, cloud tooling of these electronic devices provides additional applications and economics. In this disclosure, the term "signal processing" may include either of pre A/D conversion (analog signal processing) or post A/D conversion (digital signal processing). For example, "signal processing" performed on a server is typically post A/D conversion (digital signal processing). The present disclosure defines "signal processing" as a computational process that performs useful operations on signals, in either discrete or continuous time, to make the signal more meaningful for practical applications such as medical imaging or medical diagnoses. Signals of interest can include sound, images, time-varying measurement values and sensor signals. Examples may include biological data, such as electrocardiograms, control system signals, telecommunication transmission signals, such as radio signals, and many others. The signals are analog or digital electrical representations of time-varying or spatial- varying physical quantities. In accordance with the present disclosure, in the context of signal processing, only analog and digital signals that are representations of analog physical quantities are considered "signals." The signal processing herein may involve complex techniques such as filtering, smoothing, spectrum analysis, modulation, wavetable synthesis, feature extraction, pattern recognition, and prediction, and a straightforward A/D conversion only in itself is not considered an example of "signal processing."

[00115] In some examples, the term "data analysis," when mentioned herein in comparison to "signal processing," may include further operations (such as historical, statistical and demographic analysis) performed on the results of signal processing. Further, the digital nature of "data" does not necessarily imply that a "signal" is necessarily analog in contrast.

[00116] FIG. 10 illustrates an example architecture of a system 1000 to enable remote signal processing according to some implementations. In some examples, the system 1000 includes a cloud tooling platform 1002, such as one or more service provider computing devices 1004. In some examples, each service provider computing device 1004 may include components similar to those described above with respect to the service provider computing devices 106, such as one or more processors, one or more computer-readable media, one or more communication interfaces, one or more I/O components, and so forth. For example, one or more processors 1006 may correspond to any of the one or more processors 502 described above, and one or more computer readable media 1008 may correspond to any of the one or more computer-readable media 504 described above. The service provider computing devices 1004 may further include one or more communication interface(s), such as communication interfaces 506 discussed above (not shown in FIG. 10) and one or more I/O components, such as I/O devices 510 discussed above (not shown in FIG. 10). Accordingly, the description of these components need not be repeated here.

[00117] One or more electronic devices 1010 may be connected for communication to the cloud tooling platform 1002 via one or more networks 1012, which may encompass any of the one or more networks 104 described above. Optionally one or more user computing devices 1014 may be connected for communication with the cloud tooling platform 1002 through the one or more networks 1012.

[00118] The service provider computing device 1004 of the cloud tooling platform 1002 may include one or more servers that host cloud tooling functionalities such as one or more advanced signal processing programs or modules 1016; optionally, one or more data analysis modules 1018 (e.g., both single patient and demographic analysis modules); optionally, one or more device updating modules 1020; and optionally one or more user accounts 1022. Thus, the service provider computing device 1004 may communicate with the one or more electronic devices 1010 over the one or more networks 1012 for performing signal processing and other services, as discussed additionally below.

[00119] Each electronic device 1010 may include one or more processors 1024 and one or more computer-readable media 1026, which in some examples, may be the same as, or similar to, the processors 402 and computer readable media 404 discussed above, respectively. The electronic device 1010 may include a signal acquisition module 1028 for acquiring a signal; a basic signal processing module 1030; and basic device settings & controls 1032. The electronic device 1010 may further include one or more communication interfaces (not shown in FIG. 10), which may be the same as or similar to the communication interfaces 204 discussed above for signal/data communication with the cloud tooling platform 1002 over the one or more networks 1012.

[00120] The optional user computing device 1014 may include one or more processors 1034 and one or more computer readable media 1036, which may correspond to any of the processors and computer-readable media discussed above, respectively. The user computing device 1014 may further include one or more communication interfaces and one or more I/O components (not shown in FIG. 10), which may the same as or similar to any of the communication interface and I/O components described above. The user computing device 1014 may include a graphical user interface (GUI) 1038 to access web programs and data. The user computing device 1014 may further include a GUI 1040 to access a local electronic device 1010, such as to access menus and interfaces to set up or operate a local electronic device 1010, such as through near- field communication, wired connection, a local Wi-Fi access point, or the like. Along with the electronic device 1010, the user computing device 1014 may be designed and configured to be a substitute or extension of the display, keyboard and processor of the electronic device 1010, significantly simplifying the electronic device 1010. The user computing device 1014 may further receive and maintain electronic communications, such as user notifications 1042. In some examples, the user computing device 1014 may be any of a personal computer, a tablet, a cell phone, a laptop, or any other computing device that has network access and communication capabilities.

[00121] In some examples, the cloud tooling platform 1002 may perform remote signal processing for the one or more electronic devices 1010. For example, each electronic device 1010 may be registered to receive remote signal processing as a service from the cloud tooling platform 1002. Subsequently, the electronic device

1010 may acquire a signal 1044. The acquired signal 1044 may be any of the example signals discussed above, or any other signal for which the electronic device

1010 does not include sufficient capability to process locally. The electronic device 1010 may transmit the signal 1044 from the electronic device 1010 to the cloud tooling platform 1002 as a processor request 1046. The cloud tooling platform 1002 may receive the signal 1044 transmitted from the electronic device 1010. The service provider computing device 1004 may employ a suitable advanced signal processing module 1016 to process the received signal 1044 at the cloud tooling platform 1002. The cloud tooling platform 1002 may find use in the field of medical imaging. Ultrasound imaging, for example, requires highly sophisticated signal processing algorithms and computing power to form medically meaningful images from the ultrasound signals received by an ultrasound transducer (a PZT or cMUT transducer, for example). Using the cloud tooling platform 1002, a compact and modular ultrasound device (corresponding to the electronic device 1010) may be made without a digital imaging module and further without an integrated display. The modular ultrasound device may have a standardized data port to transmit the signals after preliminary processing to the cloud tooling platform 1002, which forms the ultrasound images using a cloud-based algorithm and sends the images back to the user end where the ultrasound device is located to be displayed on a standard computer display. The service provider computing device 1004 may store the processed signal results, at least temporarily, and may return at least part of the processing result as a signal processing result 1048 sent to the requesting device 1010. In some examples, the electronic device 1010 may be cellular network-enabled and may communicate directly with the cloud tooling platform 1002 over a cellular network.

[00122] Further, in some examples, the system 1000 may be used to perform remote signal processing of a distributed device system. For example, one application of the cloud signal processing described herein is to use the cloud tooling platform

1002 to collectively process the signals of a distributed device system that has multiple devices 1010. As an example, the plurality of devices 1010 may be registered for use with the cloud tooling platform, as discussed above. As each device

1010 separately acquires signals 1044, the devices 1010 may send the acquired signals 1044 to the cloud tooling platform 1002. The service provider computing device 1004 may process the signals 1044 as they are received using one or more of the advanced signal processing modules 1016. As one example, the electronic devices 1010 may each send different types of signals to the cloud tooling platform

1002, which may employ different signal processing modules 1016 for processing the different types of signals received from the different types of electronic devices 1010. The service provider computing device 1004 may at least temporarily store the processing results, and may return at least at least part of the processing results to at least one of the respective plurality of electronic devices 1010. As discussed above, the electronic devices 1010 may each be cellular network-enabled and may thus communicate directly with the cloud signal processing platform 1002 over a cellular network, or the like.

[00123] In one implementation, each electronic device 1010 in the distributed device system 1000 may communicate independently with the cloud signal processing platform 1002 and may send respective acquired signals 1044 directly to the cloud tooling platform 1002 for signal processing. In another implementation, the distributed device system 1000 may have a multilayered distribution in which one or more lower level devices 1010 send signals to an upper level device 1010, which aggregates the received signals 1044 and sends the aggregated signals 1044 to the cloud tooling platform 1002 for cloud signal processing. At least some of the electronic devices 1010 in the distributed device system 1000 may be able to communicate with the cloud tooling platform 1002 directly, such as over a cellular network.

[00124] One example application of the system 1000 may include a distributed sensor system comprising a large number of sensors distributed over a wide area or many areas. Each sensor that directly communicates with the cloud tooling platform 1002 may have an identity and a location registered with the cloud tooling platform 1002, such as through the user accounts 1022.

[00125] Further, the cloud tooling platform 1002 may control one or more of the electronic devices 1010. For instance, in addition to cloud signal processing, the cloud tooling platform 1002 may also exert control over one or more of the individual electronic devices 1010. For example, the control may be exerted as a response to the results of signal processing at the cloud tooling platform 1002. For example, the service provider computing device 1004 may perform analysis of the processed signal, such as using a data analysis module 1018, for determining how to control one or more of the electronic devices 1010. The service provider computing device 1004 may apply intelligently differentiated control over a plurality of different electronic devices 1010 devices according to their respective acquired signals, locations, intended purposes, and so forth. [00126]

[00127] For still another example application, the distributed device system 1000 may be a transportation system that includes multiple vehicles (such as high-speed trains) traveling at various speeds at various locations. Each vehicle may be equipped with an electronic device 1010 that includes a GPS locator, speedometer, and/or the visual and audio signals of the driver. Each electronic device 1010 may be cellular network-enabled to be able to communicate directly with the cloud tooling platform 1002. Centralized signal processing by the cloud tooling platform 1002, together with the cloud device control techniques described herein may vastly improve the dispatching and logistics of the transportation system to increase operational efficiency and safety.

[00128] In order to work together as the system 1000, the electronic devices 1010 and the cloud tooling platform 1002 may comply with a shared standard to guarantee compatibility. Suitable software such as for providing APIs may be installed on the service provider computing device(s) 1004 of the cloud tooling platform 1002, and in some cases on the electronic devices 1010 as well to ensure that the information flow and command chain work collaboratively.

[00129] Furthermore, in some examples, a cloud user interface may be employed with the cloud tooling platform 1002. Thus, in addition to cloud signal processing and/or cloud device control, accessory devices such as user computing devices 1014 may be registered and connected to the cloud tooling platform 1002 to provide a rich graphic user interface to a user 1052 to enable control of one or more of the electronic devices 1010 and/or or a system of multiple electronic devices 1010. Optionally, the cloud tooling platform 1002 may push information such as user notifications 1042 to the user 1052 through the user computing device 1014. In some examples, the notifications 1042 may include a text message sent to the user computing device 1014 based on a user account 1022. For example, the user account may be identified through a software client installed on the user computing device 1014. Alternatively, the text message may be sent directly if the user computing device 1014 has a subscriber ID (e.g., a cell phone number) or a hardware ID associated with the user account 1022.

[00130] In addition to receiving pushed information such as notifications 1042, the user computing device 1014 may provide the graphical user interface (GUI) 1038 to access web programs and data, and the GUI 1040 to access a local electronic device's 1010 operation menu, setup menu, or the like. For example, the user may access user data stored on the service provider computing device 1004 through the user computing device 1014. As an alternative, the user 1052 may user the GUI 1038 to access a user interface module 1054 that is hosted on the service provider computing device 1004 to access the operation menu and/or set up menu to control one or more of the electronic devices 1010. As another example, in the case that the user computing device 1014 is a mobile communication device, the user 1052 may use an application program (app) (not shown in FIG. 10) installed on the user computing device 1014 to connect to the service provider computing device 1004 to access the user interface module 1054 for controlling one or more of the electronic devices 1010. All this can be done through the cloud, instead of relying on cable connections or wireless local connections with the one or more electronic devices 1010.

[00131] As mentioned above, a user 1052 may register or otherwise associate an electronic device 1010 with a user account 1022 on the cloud tooling platform 1002. Thus, for management of electronic devices 1010, received signals, processed data, users, and user computing devices 1014, a procedure may be in place to associate electronic devices 1010 with their respective user computing devices 1014 and user accounts 1022. As one example, the cloud tooling platform 1002 may open a user account 1022 for a user 1052 who registers with a personal identity and a device identity, and optionally a cell phone number. The cloud tooling platform may associate an account number (or an account ID) with the personal identity, and may associate the account number with the device identity of the each electronic device 1010. The cloud tooling platform 1002 may further associate the account number with the optional cell phone number of the user 1052. Further, the cloud tooling platform 1002 may receive a signal from each electronic device 1010 associated with a particular respective device identity. The cloud tooling platform 1002 may process the received signal and store the processing results as data records associated with the respective user account 1022. The cloud tooling platform 1002 may further accept a logon request by the user 1052 from the user computing device 1014 and may provide access to the respective user account 1022 and the data records associated with the user account 1022 upon a successful logon.

[00132] The advanced signal processing algorithms/programs and/or modules 1016 hosted on the service provider computing device 1004 are for more sophisticated and more complex signal processing than may be possible or economical for the processor 1024 on-board of the electronic device 1010 itself to carry out. In essence, this is cloud computing applied in cloud tooling. For example, the cloud signal processing of signals received from the electronic devices 1010 may include several benefits, such as enhancing the signal processing power of the electronic devices 1010 to a whole new level; enabling more powerful signal processing algorithms and programs to be used, which would not be supported by the on-board processors 1024 of the electronic devices 1010; significantly reducing the amount of product updating and product redesigns, reducing the number of outdated products, and increasing the life span of the products in service; and reducing the level of difficulties in both operation and maintenance of the electronic devices 1010.

[00133] Furthermore, some implementations herein may make it possible to use some types of professional devices at home for the first time by miniaturizing the electronic devices 1010 by the virtue of hosting the bulkier signal processing unit on the cloud tooling platform 1002, and also by the virtue of allowing a professional to monitor the operation of the electronic device 1010 from a remote location, such as through the user computing device 1014. Furthermore, some implementations herein may make it easier to control and manage a company's intellectual property in the advanced signal processing algorithms, methodologies and programs by hosting them only on the cloud tooling platform 1002, thereby limiting access to these technologies. In addition, some implementations provide centralized control over multiple devices distributed over different locations.

[00134] Together with the fact that the cloud tooling platform 1002 may be able to support a large number of devices (e.g., many millions) at the same time, the system 1000 brings in new economies to the industry of signal processing devices. The system 1000 is further augmented by other optional cloud tooling features, such as data analysis (e.g., both single patient analysis and demographic analysis) provided by the data analysis module(s) 1018, device updates provided by the device update module(s) 1020, and user access provided by the user interface module(s) 1054.

[00135] Among the optional features, historical analysis of the data of a patient may assist in extracting patterns and making useful diagnosis and predictions. Such analysis processing may be beyond the capability of the processor 1024 and computer-readable media 1026 (e.g., memory) on the electronic device 1010. Furthermore, demographic analysis of many patients of various backgrounds and demographics may be provided, which is even further beyond the capability of the processor 1024 and other resources onboard the electronic device 1010.

[00136] Additionally, device updating by device updating module(s) 1020 may be performed by the system 1000. Both software and firmware of the electronic devices 1010 may be updated through the cloud tooling platform 1002. For example, when the electronic devices 1010 are enabled to connect with the cloud tooling platform 1002 through a cellular network, product updates can be delivered to the electronic devices 1010 automatically with virtually no user involvement. Although the user 1052 may still choose or change delivery schedules and policies if so desired, there is no technical reason for the user to have to set up the network connections with the device.

[00137] As a result, it is not necessary for the user of an electronic device 1010 to face the difficulties of setting up a local network, checking why there is no connection, searching for update downloads that match the product, downloading the found updates, installing the downloaded updates, hoping the update works, and repeating the above. For a vast majority of consumers, none of these steps is a trivial task, and such hassles are a reason why product software and firmware updates have not gained popularity outside of the computer world. In fact, even in the computer and consumer electronics world, typical consumers avoid performing product updates manually, and to a particularly higher degree when it comes to updating firmware and bios.

[00138] In the system 1000 described herein, a cellular network connection and cloud tooling functions may operate hand-in-hand to provide advantageous services. When the electronic devices 1010 are enabled to connect with the cloud tooling platform 1002 automatically, such as through a cellular network, additional aspects of a cloud user interface of the electronic devices 1010 are provided. Although it is possible to design the electronic devices 1010 to access the cloud tooling platform 1002 through any Internet connections such as Wi-Fi or LAN, or indirect Internet connections, such as through a Bluetooth® connection of another Internet-enabled device, the use of a connection through cellular networks may be employed in some examples.

[00139] For instance, cellular networks such as CDMA (code division multiple access) networks, GSM (Global System for Mobile Communications) networks, and the like, enjoy setup-free, trouble-free and always-on network connection. For example, with a CDMA chip/card installed, a user may merely turn the electronic device 1010 on to get a network connection. This is in contrast to local network connections that are usually difficult to setup, unreliable, and frequently employ re- setups and re-connections. Furthermore, each cellular network chip/card/module usually has a unique subscriber ID that is assigned by the either the issuer/carrier or the manufacturer. As a result, an electronic device 1010 that has such a chip/card/module installed or built-in has a meaningful identity that is tied to the chip/card/module (and and thereby to its owner). Such identification may be useful for the cloud tooling platform 1002 to perform smooth tooling actions on the electronic device 1010, process signals and data, and further manage the results.

[00140] For example, with the chip/card/module ID, the signal 1044 received from the electronic device 1010 can be automatically associated with a proper user account 1022 to allow for authorized data processing, authorized user access, and return of the processing result to the electronic device 1010. Furthermore, with the chip/card/module ID and the always-on network connection, product updates can be delivered to the electronic devices 1010 automatically with virtually no user involvement. Such automation and reliability may be very difficult to achieve using the other types of networking and interconnection means. What is more, in addition to the cloud tooling actions performed by the cloud tooling platform 1002 on the electronic device 1010, the user interface available through a user computing device 1014, either web-based or app-based, may also take advantage of the chip/card/module identification to associate electronic devices 1010 with their respective user accounts 1022.

Cloud User Interface for Mobile Communication Devices

[00141] When each electronic device 1010 is enabled to connect with the cloud tooling platform 1002 through a cellular network, additional aspects of cloud user interfaces for the electronic devices 1010 are available. For example, the electronic devices 1010 may be remotely controlled and interacted with, such as by the provision of the user interface module 1054 on the cloud tooling platform 1002 and/or by the provision of an application based user interface on the user computing device 1014, particularly in the case that the user computing device 1014 is a cell phone, smart phone, or other cellular-communication-enabled device. [00142] Although it is possible to design the electronic devices 1010 to access the cloud tooling platform 1002 through any Internet connections such as Wi-Fi or LAN, or indirect Internet connections through Bluetooth connection with another Internet- enabled device, using a cellular network or similar wireless connection has significant advantages as discussed above. One application of a cellular network in cloud tooling is the creation of cellular network-based cloud user interfaces for the electronic devices 1010. For example, an electronic device 1010 may be manufactured or enabled for cellular network connection. In addition, the electronic device 1010 may be enabled for communication with a central or specified cloud tooling platform 1002 to receive therefrom data and instructions that operate and control the electronic device 1010. Furthermore, the electronic device 1010 may be associated with a cell phone of other cellular enabled computing device of a user, such as through a user account 1022 on the cloud tooling platform 1002 to authorize the cell phone to send data and instructions to the electronic device 1010.

[00143] Manufacturing such an electronic device 1010 may entail cooperative agreement between the manufacturer and the owner/operator of the cloud tooling platform 1002 (if they are different parties). Interfacing such a cellular-enabled electronic device 1010 with a cell phone over a cellular network-based cloud may also employ coordinated programming. Programs, such as to implement application programming interfaces (APIs), may be installed on servers of the cloud tooling platform 1002 and in some cases on the electronic device 1010 and the cell phone of the user as well.

[00144] Accordingly, implementations herein may convert any electronic device

1010 to a smart device, including dumb or thin devices that do not have much processing power for a user interface, much less a rich graphical user interface like that provided by a cell phone or a mobile device such as a tablet. The cloud user interface herein may be not only a rich graphical user interface, but may also include smart functionalities extended by a smart phone or a smart mobile device.

Additionally, to facilitate provision of a cloud user interface for one or more electronic devices 1010, the cloud tooling platform 1002 may also have other server hosted cloud tooling capabilities such as the following:

[00145] signal processing, data analysis and device updating;

[00146] user modules including user accounts and user interfaces; and

[00147] the ability to support and interact with mobile apps. [00148] These cloud tooling capabilities further augment the functionalities and economies of the electronic devices 1010 networked to the cloud tooling platform 1002, as discussed herein.

[00149] In principle, with the prerequisite cooperative agreement between the device manufacturer and the platform owner/operator, any device can potentially be designed to interactively communicate through a cloud tooling platform 1002 with a cell phone or other cellular enabled computing device, and may thereby be converted to a smart device to enjoy the ease of operations and extended functionalities. Because multiple devices may be controlled by the same cell phone (or other computing device with cellular network capabilities), this not only yields better user experiences and richer functions, but also better economics.

[00150] This is different from web-based telemedicine systems known in the prior art, such as the GluCoMo™ glucose monitoring system (available from Artificial Life, Inc., Hong Kong, China) which uses a smart phone to assist the operation of a medical device. In the existing systems, the medical device itself is not directly connected to a network, particularly not directly connected through a cellular network, and much less to the cloud tooling platform 1002, which has cloud computing and cloud tooling functions that may be performed in connection to the medical device. For example, in some existing systems, the medical device may communicate with the user's cell phone using a cable connector such as USB or near- field communication technology such as Bluetooth® or Infrared (IR).

[00151] On the other hand, implementations herein employ cloud tooling functions such as using a cell phone or a mobile device enabled for cellular network connection as a cloud user interface for operating and controlling other devices through a cellular network (in contrast to a near-field communication such as Bluetooth®). Further, implementations herein may include cloud tooling functions such as advanced signal processing programs and remote device software/firmware updating hosted on a server of the cloud tooling platform 1002.

[00152] FIG. 11 illustrates an example architecture of a system 1100 to enable provision of cloud-based user interfaces for cellular-enabled devices according to some implementations. The system 1100 may include a cell phone or other cellular- enabled device 1102 (such as a tablet or other computing device enabled for cellular network connection). The cellular-enabled device 1102 may present a cloud user interface for an electronic device 1010 that is enabled to connect to a cellular network. [00153] The cellular-enabled device 1102 may include one or more processors 1104 and one or more computer readable media 1106, which may correspond to any of the processors and computer-readable media discussed above, respectively. The cellular-enabled device 1102 may include the graphical user interface (GUI) 1038 to access web programs and data; the GUI 1040 to access an electronic device 1010 locally; and user notifications 1042, as discussed above.

[00154] In the illustrated example, the cellular-enabled device 1102 includes a cellular network interface 1108 that may communicate with one or more cellular towers 1110. Further, the electronic device 1010 also includes a cellular network interface 1112. The cellular network interfaces 1108 and 1112 may communicate with the cellular towers 1110 utilizing any type of cellular-radio-based communication protocols such as GSM (Global System for Telecommunications), UMTS (Universal Mobile Telecommunication system), CDMA (Code Division Multiple Access), D-AMPS (Digital Advanced Mobile Telecommunications device System), TDMA (Time Division Multiple Access), iDEN (Integrated Digital Enhanced Network), GPRS (General Packet Radio Service), EDGE (Enhanced Data rates for GSM Evolution), WCDMA (Wideband Code Division Multiple Access), and their variants. The cellular-enabled device 1102 may further include one or more mobile applications 1114 that may interact with the user interface module(s) 1054 to present a user interface on the cellular-enabled device 1102 for controlling one or more electronic devices 1010.

[00155] The electronic device 1010 in this example may include the basic device settings & controls 1032. The electronic device 1010 may further include any of the other components discussed with reference to FIG. 10, such as the signal acquisition module 1028 and the basic single processing module 1030, which are not illustrated in FIG. 11 for clarity.

[00156] A user 1052 may employ the GUI 1038 or the mobile app 1114 to view a user interface to set up and control the electronic device 1010. For instance, a user may user the GUI 1038 or the mobile app 1114 as a cloud user interface to control at least one function of the electronic device 1010. For example, the GUI 1038 may interact with the user interface module 1054 to present a user interface to control the electronic device 1010. Similarly, the mobile app 1114 may interact with the user interface module 1054 to present a user interface for controlling the electronic device

1010. In response to instructions received from the cellular-enabled device 1102, the cloud tooling platform 1002 may send instructions to the electronic device 1010 based on an association between the electronic device 1010 and the cellular-enabled device 1102 established at the cloud tooling platform 1002. Thus, by associating the cellular-enabled device 1102 with the electronic device 1010 using identity-based authorizations and tying these authorizations to a user account 1002 on the cloud tooling platform 1002, the interaction may be permitted. An example technique for associating a cellular-enabled device 1102 with an electronic device 1010 on the cloud tooling platform 1002 is discussed additionally below.

[00157] In some examples, the cellular-enabled device 1102 may be used as a remote controller of a medical device as the electronic device 1010. Thus, the GUI 1038 and/or mobile app 1114 may be used to access the operation menu and setup menu of the electronic device 1010 through the cloud. The remote control of the electronic device 1010 may be effected through the cloud tooling platform 1002, and is thus the cellular-enabled device 1102 may serve as a cloud-based universal remote control, in contrast to conventional universal controllers that use near-field wireless communications such as Bluetooth® or IR. For example, the cellular-enabled device 1102 may be used to control at least one function of the electronic device 1010.

[00158] In the system 1100 of FIG. 11, the electronic device 1010 can be produced without a communication interface for a short distance or near-field wireless communications, thus saving manufacturing costs. In addition, with the simplicity of a setup-free and always-on connection, the clumsy and confusing local networking setups may also be avoided. However, the ability to control remotely an electronic device 1010 over the cloud, can either be a powerful feature or a cause of security concern. It is noted, however, that there is inherent security built in to the solution provided herein. For example, only the one or more electronic devices 1010 and the authorized cellular-enabled device 1102 (typically owned by the same person or entity) are explicitly authorized to perform inquisitive and invasive operations. The authorization may be controlled by managing user accounts 1022, which tie together hardware IDs, subscriber's IDs and registered personal IDs, and which allow such operations by cellular-enabled devices 1102 on electronic device 1010 only if both the cellular-enabled device 1102 and the electronic device 1010 are tied to the same account.

[00159] Furthermore, different levels of authorization may be given to different cellular-enabled devices 1102. For example, a patient-level authorization may be given to a cellular-enabled device 1102 owned by a patient or by a designated family member or guardian, while a doctor-level authorization may be given to a cellular- enabled device 1102 of a doctor of the patient. Additionally, depending on the type of the electronic device 11 10, a family-level authorization may be given to a cellular- enabled device 1102 owned by a regular family member, and a friend-level authorization may be given to a cellular-enabled device 1102 that belongs to a friend. Each different level prescribes different layers of authorizations for accessing information and performing operations.

[00160] To prevent unwanted intrusion from a lost cell phone, or the like, a cellular-enabled device 1 102 that has a certain high level of authorization (such as the patient-level, the doctor-level, and the family-level authorization) may further utilize a password or challenge code for confirmation when requesting access. As the service provider computing device 1004 receives a request from a pre-authorized cellular- enabled device 1102, the service provider computing device 1004 may send a prompt for the user to enter the password or the challenge code for confirmation. A successful confirmation of an entry may be good for access for a single session, for a certain period of time, or the like.

[00161] In one implementation, the above described access, operations and controls may be performed through the mobile application program (app) 1114, which may be downloaded from the cloud tooling platform 1002, or other source, and which is installed on the cellular-enabled device 1102. The mobile app 1114 may be provided by the manufacturer of the electronic device 1010, the owner of the cloud tooling platform 1002, or any third party developer.

[00162] With the above-described cloud tooling design, not only are the operations and functions of the electronic device 1010 significantly enhanced by using cellular- enabled device 1102, but also the development of better user interfaces. Additionally, it is likely that more advanced functions can be employed by developing apps 1114 without having to resort into frequent hardware-based product generation update cycles.

[00163] In some examples, the cellular-enabled device 1102 may be provided with the cloud user interface to enable remote setup and/or control of the electronic device

1010. For example, the cloud tooling platform 1002 may open a user account 1002 for a user who registers with a personal identity, a device identity, and a cell phone number (or a mobile chip/card/module ID of a mobile device), as discussed above with respect to FIG. 10. The cloud tooling platform 1002 may associate an account number (or an account ID) with the personal identity, the device identity and the cell phone number of the user. The cloud tooling platform 1002 may receive a logon request 1118 from the cellular-enabled device 1102 with the registered cell phone number. Based on confirmation of the registered phone number, the cloud tooling platform 1002 may accept the logon request from the cellular-enabled device 1102 of the user and provide access to the user account. The cloud tooling platform 1002 may receive an instruction or user input 1120 from the cellular-enabled device 1102, wherein the instruction or the user input 1120 specifies an electronic device 1010 to receive the instruction or user input 1120. The cloud tooling platform 1002 may check the record of electronic devices 1010 associated with the same user account 1022, and may deliver the instruction or the user input 1120 to the specified electronic device 1010 only if the device identifier is found among the devices associated with the user account. Upon receipt of the instruction or user input 1120 from the cloud tooling platform 1002, the electronic device 1010 may execute the instruction or accept the user input. In some cases, the above operation can be completed only if the electronic device 1010 is registered with the cloud tooling platform 1002. The registration of the electronic device 1010 with the cloud tooling platform 1002 authorizes the cloud tooling platform 1002 to provide operational instructions and user input to the electronic device 1010.

[00164] Using the technique described above, the cellular-enabled device 1102 may present a GUI to access the operation menu and/or setup menu for the electronic device 1010. The GUI may be accessed either through a browser (e.g., provided by GUI 1038) or through the mobile app 1114 installed on the cell phone, either of which may interact with the user interface module(s) 1054 for presenting the GUI and controlling the electronic device 1010. All of this can be done through the cloud, instead of relying on direct cable or a near-field wireless local connection with the electronic device 1010 through the GUI 1040 to access the device locally. In other words, the cellular-enabled device 1102 does not need to be local to the electronic device 1010 to setup, control, operate or otherwise interact with the electronic device 1010.

[00165] In addition to serving as the cloud user interface of the electronic device

1010, the cellular-enabled device 1102 may perform other functions in relation to the electronic device 1010. For example, the cloud tooling platform 1002 may push information, such as notifications 1042, to the cellular-enabled device 1102. The cellular-enabled device 1102 may also provide the graphical user interface 1038 to access web programs and data on the cellular-enabled device 1102.

Cloud Tooling of Medical Devices

[00166] Devices that may especially benefit from the above-described cloud signal processing and/or cloud user interface are personal medical care devices, such as stethoscopes, fetal stethoscopes, fetal heart monitors, electrocardiography devices (such as a Holier monitor), breathing machines for home use, hearing aids, personal GPS locators, in vitro diagnostic (IVD) medical devices, and so forth.

[00167] These medical devices, among many others, can significantly benefit from the advanced cloud signal processing described herein because the acquired signals may yield more data despite high signal-to-noise (S/N) ratios, and may enable more accurate signal interpretation by using more sophisticated signal processing algorithms. Without cloud signal processing, although better signal processing algorithms are often available on a theoretical basis, they are not developed due to the limited processing power of the individual devices.

[00168] In addition, by removing or reducing expensive new product updating cycles, the resultant economics would encourage even faster development of improved algorithms. Previously, there is often not sufficient motivation for such developments due to the hindrance of product cycles.

Stethoscope Example

[00169] As one example, both acoustic stethoscopes and electronic stethoscopes can be used in the implementations herein for cloud signal processing and cloud user interface. For instance, a stethoscope may be used for listening to the sound of a heart, and may also be used to listen to other bio activities such as intestinal motion, blood flow in the arteries and veins, breathing and so forth.

[00170] For instance, as discussed above with respect to FIG. 10, when the electronic device 1010 is a stethoscope, a patient signal may be sent to for cloud signal processing on the service provider computing device 1004, which uses advanced signal processing algorithms or modules 1016 having highly effective filtering methods for signal processing. In some embodiments, the stethoscope

(electronic device 1010) uses a contact microphone to pick up the acoustic signal from a user's heart and does not use traditional tube portions, which produce a characteristic sound effect that is familiar to doctors' trained ears. Without good sound processing, such a stethoscope may be found inadequate by doctors. Existing electronic or digital stethoscopes employ rather costly solutions to solve this problem, using hardware and/or software. With the cloud tooling platform 1002, for example, the stethoscope (electronic device 1010) may have little or no built-in signal processing, but instead may send the signals picked up by the microphone to either a user computing device (such as a smartphone, a tablet) or a cloud-based computing device which has signal processing capability to not only simulate an acoustic effect acceptable to doctors, but may also perform other signal analyses for nontraditional diagnoses. This may result in a high quality digital stethoscope that is cheap and simple enough for home use. The processed signals may be stored by the service provider computing device 1004 in connection with the user account 1022 associated with the patient or family, and are accessible by the patient, a family member or a doctor. The cloud tooling platform 1002 may also host an expert system that uses a knowledge base of expert doctors. The stored patient data may be checked against the expert system for diagnosis. Furthermore, as discussed above with respect to FIG. 11, a cellular-enabled device 1102, such as a cell phone, may present a user interface (e.g., an app-based user interface) to access and/or operate the stethoscope. The cellular-enabled device 1 102 may also be used as a sound monitor of the stethoscope, such as for receiving a portion of the processed signal as sound. In addition, the cellular-enabled device 1102 may locally host a version of the expert system to perform self-diagnosis at home.

Fetal Stethoscope (Fetal Heart Monitor) Example

[00171] As another example, similar to that of a regular stethoscope, implementations herein may also be used in connection with a fetal stethoscope/heart monitor. For instance, fetal stethoscopes may face more challenges on signal processing than the regular stethoscopes in order to extract fetal heart acoustic signals from a noisy background. This makes the cloud signal processing techniques described herein even more useful for fetal stethoscope. For example, the filtering of the signal processing may be adjusted in order to capture an evasive fetal heart sound.

Such processing adjustment may either be done by a doctor using a user interface through the user computing device 1014 (e.g., a personal computer, a tablet or a cell phone), or by the patient or a family member using a user computing device 1014 or a cellular-enabled device 1102, such as a cell phone or other mobile device having network communication capability.

Electrocardiography Example

[00172] As still another example, electrocardiography (ECG or EKG) is an interpretation of the electrical activity of the heart of a patient over a period of time, as detected by electrodes attached to the outer surface of the skin of the patient and recorded by a device external to the body. The recording produced by this noninvasive procedure is termed an electrocardiogram. The real-time tracing of an electrocardiogram and accurate interpretation thereof may employ complicated data processing and reading, and interpretation by professional personnel. For example, an expert system may be used as a reference to assist signal tracing and interpretation. Typically, electrocardiography may be difficult to employ at home for home care or attached to the body for mobile personal use. For example, when used at home, a copy of the voluminous expert system has to be delivered to the home user along with the ECG machine, and often the expert system has to be run on a personal computer, which may be configured to work along with the ECG machine.

[00173] Electrocardiography therefore is an ideal candidate to benefit from the cloud signal processing described herein. With cloud signal processing, electrocardiography may be more ready than ever for home use or mobile personal use because the electrocardiography device may be miniaturized by the virtue of hosting the bulky signal processing unit on the cloud. Further, extensive signal processing can be performed by powerful server computers in the cloud. Additionally, a medical professional may be able to monitor the operation of the electrocardiography device from a remote location using the implementations herein.

[00174] Further, in addition to the above-described functions that can be performed using a cell phone, the cell phone may also be used for monitoring the user's mobility, and for sending a location signal to the cloud tooling platform 1002 to be processed in combination with electrocardiography signal.

Breathing Machine Example

[00175] A breathing machine, such as a respirator, may automatically determine air delivery based on monitoring a status of a patient's breathing. Although the monitoring and adjustments can be reasonably done by a home-use breathing control unit, the breathing machine can benefit from the cloud tooling platform 1002, which may provide assistance to, or even replace, the computational decision-making unit of the home machine. For example, in the case that the electronic device 1010 is a breathing machine, a monitoring unit of the breathing machine may monitor the breathing condition of the patient, send signals to the cloud tooling platform 1002, which may determine the proper air supply, and which then sends instructions to the breathing machine for automatic control. In this mode, the breathing machine at home may be provided without a computational decision-making unit.

[00176] Alternatively, the breathing machine may have its own automatic control unit, but may from time to time receive overriding instructions from the cloud tooling platform 1002 for enabling automatic breathing control. The instructions may either be given by an expert program automatically or by a doctor manually after reviewing the real-time data of the patient through a networked user computing device 1014 in communication with the cloud tooling platform 1002. As in the other applications described herein, the cell phone or cellular-enabled device 1102 can provide a user interface to a medical professional, a family member, or a patient for giving or receiving operations, instructions, controls, notifications, alarms and records.

Hearing Aid Example

[00177] One of the biggest challenges faced by hearing aids is personalized optimization. High-end hearing aids all offer some type of personalized optimization, typically performed at a store or hospital by a professional using a monitoring and calibration device. Once the user buys the hearing aid and goes home, however, any subsequent personalized optimization is mostly up to the user. Although the user may visit the store or hospital again for recalibration when an overall shift of the user's hearing ability occurs, the real use for calibration is not over the long-term, but rather ad hoc refinements that may be used from time to time due to changing environments or conditions. For example, the optimized settings for a hearing aid in a quiet room may be very different from that in a noisy restaurant. From indoor to outdoor, home to conference rooms, sidewalks to public transportation, each environment may employ a unique refinement to the optimization. This is typically out of reach for current hearing aids. [00178] According to some implementations herein, when the electronic device 1010 is a hearing aid, with the cloud signal processing, this situation may be vastly improved, and further creates opportunities for additional applications. Thus, personalized optimization of a hearing aid may include receiving a monitoring signal at the cloud tooling platform 1002 from a hearing aid device. For example, the monitoring signal may include a sample of an input signal (i.e., what the hearing aid hears at its built-in microphone) and/or a sample of an output signal (i.e., a post- amplification signal or what the user hears from the hearing aid's speaker). The cloud tooling platform 1002 may process the received monitoring signal at the service provider computing device 1004 with reference to a stored user profile of the hearing aid's user using one or more signal processing modules 1016, as discussed above. An analysis program 1018 may determine an optimized setting of the hearing aid. The cloud tooling platform 1002 may transmit the optimized setting to the hearing aid to instruct the hearing aid to adjust its settings according to the optimized setting.

[00179] In order to carry out the above technique, the hearing aid may be enabled for cellular network communications. Further, compatible programming may be used for data communications and/or API's between the hearing aid and the cloud tooling platform 1002. In some examples, the above technique for optimizing a hearing aid may be performed automatically without participation of a person. The initiation of the process may be scheduled to start periodically, may be started automatically upon detection of a significant change of environment or ambient noise condition, or may be initiated manually by the user. For instance, to conserve power of the hearing aid, a threshold may be established such that the hearing aid does not send a monitoring signal to the cloud tooling platform 1002 until a change in ambient noise level reaches a predetermined threshold.

[00180] Alternatively, the above process may also be executed with the participation of a person, such as a medical professional, the hearing aid user, a family member, or another person near the user. For example, after determining an optimized setting of the hearing aid, the cloud tooling platform 1002 may present the determined optimized setting as a recommendation to the user's cell phone, and instruct the user to adjust the hearing aid manually, thus omitting the operation of sending the instructions to the hearing aid.

[00181] In another implementation, the operation of determining an optimized setting for the hearing aid may be performed interactively with a feedback loop, such that after the hearing aid has received the optimized settings and adjusted its settings, the cloud tooling platform 1002 may present a prompt for user feedback on the user's cell phone to ask the user to evaluate the result of the new setting. The cloud tooling platform 1002 may then reevaluate the monitoring signal along with the user feedback and attempt to make an improved determination of the new optimized setting. This can be repeated until the user is satisfied.

Wearable Personal Monitor Example

[00182] FIG. 12 illustrates an example architecture of a system 1200 to enable use of a wearable personal monitor 1202 according to some implementations herein. The wearable personal monitor 1202 may be a small wearable object that attaches closely to a human body to provide digital personal service. The wearable personal monitor may provide any combination of the following digital services: personal identification; GPS location; body part movement determination (e.g., using an accelerometer); fall alert (e.g., using an accelerometer); body temperature; pulse reading; and so forth. The wearable personal monitor 1202 may include one or more processors 1204 and one or more computer readable media 1206, which may correspond to any of the processors and computer-readable media discussed above, respectively. The wearable personal monitor 1202 may further include a cellular network interface 1208, and may include at least basic device settings & controls 1210. The wearable personal monitor 1202 may further include other modules, sensors and the like, such as a signal acquisition module 1028 and a basic signal processing module 1030, as discussed above. The system 1200 may further include the cloud tooling platform 1002 and the cellular-enabled device 1102 (or additionally, or alternatively, the user computing device 1014).

[00183] In a basic reading operation executed by the wearable personal monitor

1202, the wearable personal monitor 1202 transmits a signal 1212 (e.g., personal identification, GPS location, body part movement, fall alert, body temperature, pulse reading, etc.) to the cloud tooling platform 1002 where the signal may be processed, used and stored in a personal account associated with a person who wears the personal monitor. The transmission may be started manually (e.g., by pushing a button on the wearable personal monitor), may be triggered automatically by an event (e.g., a detection of a fall, the wearer's body reaching a certain temperature level or pulse rate, etc.), may be transmitted periodically, or a combination thereof. For example, a session of continuous transmission of the signal 1212 may be started and stopped manually.

[00184] The signal 1212 (or information 1214 related to the signal) may be received from the cloud tooling platform 1002 by an authorized cell phone or cellular- enabled device 1102. The authorization can be performed as discussed above through identity-based registration. For example, there may be an authorization to the wearer's cell phone, the cell phone of the wearer's family member, and/or the cell phone or a computing device 1014 of a medical professional, such as a doctor or nurse. The transmission of the signal 1212 or information 1214 related to the signal from the cloud tooling platform 1002 to the cell phone or cellular-enabled device 1102 may be either pushed automatically by the service provider computing device 1004, or pulled from the service provider computing device 1004 by the user 1052 of the cellular-enabled device 1102. Further, as discussed above, in some examples, the signal 1212 may be processed at the cloud tooling platform 1002 using one or more signal processing modules 1016, and optionally analyzed using one or more data analysis modules. Thus, rather than merely sending the signal to the cellular-enabled device 1102, in some examples, an analysis result (e.g., information 1214 related to the signal) may be sent to the cellular-enabled device 1102 and/or the user computing device 1014. An optimal transmission mode may be selected according to the nature of the signal 1212 and the relevant event.

[00185] In some examples, the transmitting and receiving of the data related to the signal 1212 may be via a cellular network. To accomplish this, the wearable personal monitor 1202 may be enabled to at least transmit data over the cellular network, such as to a tower 1110, and optionally also to receive data over the cellular network.

[00186] In a basic writing operation, an authorized cell phone or cellular-enabled device 1102 may receive an entry of new information or modified information through a user interface provided by the cell phone or the cellular-enabled device 1102, as discussed above with respect to FIG. 1 1. The cellular-enabled device 1102 may transmit the entered information 1216 to the service provider computing device 1004, which in turn may pass the information 1216 to the wearable personal monitor 1202 to update or rewrite the information contained therein.

[00187] In addition to the simplicity and reliability of the always-on cellular network, a wearable personal monitor able to communicate in this manner with a cell phone or cellular-enabled device 1102 also enables remote reading and/or writing by someone who is at a location away from the wearer of the digital emulate. This may not be possible in configurations that use LAN networking, short distance communications or near-field communications. When worn by a patient, the wearable personal monitor 1202 may significantly improve the safety of the patient and may also help a hospital or medical professional (e.g., doctors, nurses, etc.) identify, monitor and manage patients.

[00188] In one implementation, the wearable personal monitor 1202 is a personal identifier and transmits personal identification information to the service provider computing device 1004. As one example, the wearable personal monitor 1202 may be worn by a hospitalized patient and may contain the patient's personal identification and, optionally, medical conditions, such as allergy history and medicine warnings, treatment and drug administration records. A medical professional may check the information contained in the wearable personal monitor 1202 using an authorized cell phone or a special cellular-enabled device 1102 for such purpose.

[00189] The wearable personal monitor 1202 itself can be very simple and small and does not have to have a large display for viewing information, nor many buttons for operation. Further the processing and computing capabilities of the wearable personal monitor 1202 may also be minimal, as most or all signal processing and analysis may be performed on the service provider computing device 1004.

[00190] Accordingly, when a patient or other wearer is wearing the wearable personal monitor 1202, the wearable personal monitor may sense one or more bodily conditions of the patient as described above. Thus, when in a reading mode, in response to one of the triggers described above, the wearable personal monitor 1202 may initiate a transmission of the signal 1212 from the wearable personal monitor

1202 to the service provider computing device 1004. In some examples, the service provider computing device 1004 may perform signal processing on the signal 1212, as discussed above. The service provider computing device 1004 may send the received signal 1212 or information 1214 about the signal to an authorized cell phone or cellular-enabled device 1102. The cellular-enabled device 1102 may display the received signal 1212 or the information 1214 related to the signal on the authorized cell phone or cellular-enabled device 1102. As mentioned above, the initiation of sending the signal 1212 from the personal monitor 1202 may be done by pushing a button on the wearable personal monitor 1202 or by any of the other triggers discussed above. The displaying of the signal 1212 or the information 1214 related to the signal may be initiated by the service provider computing device 1004 or the cellular-enabled device 1 102 automatically upon receiving the signal transmitted from the wearable personal monitor 1202, or manually by the user 1052 of the cell phone or cellular-enabled device 1 102.

[00191] As another example, a user may set up or control the wearable personal monitor 1202 worn by the patient when in a writing mode. For example, the user 1052 may initiate a user input session on an authorized cell phone or cellular-enabled device 1102. The user 1052 may enter information on the authorized cell phone or cellular-enabled device 1102, such as to set up or control the wearable personal monitor 1202. The cellular-enabled device 1102 may transmit the entered information 1216 from the authorized cell phone or the cellular-enabled device 1102 to the service provider computing device 1004. In response, the service provider computing device 1004 may send the received entered information 1216 to the wearable personal monitor 1202 to instruct the wearable personal monitor 1202, such as to update the digital content stored therein, or to perform other functions. The initiation of the user input session may be done through a web user interface 1038 or an app 1114 installed on the cell phone or the cellular-enabled device 1102.

IVD Medical Device Example

[00192] As described above, an IVD medical or test device is a medical device that tests the reaction of a human body specimen to a reagent for the purpose of providing health related information such as: concerning a physiological or pathological state; concerning a congenital abnormality; concerning the safety and compatibility of treatment with potential recipients; for monitoring therapeutic measures; and so forth. IVD tests are traditionally run in hospital pathology laboratories and pharmacies, but home use of IVD devices for enabling tests to be conducted by patients themselves are on the rise.

[00193] Depending on the type of the test, an IVD test device may or may not have a great amount of computing power and therefore may or may not be greatly benefited by the cloud computing aspect of the cloud tooling implementations described herein.

However, other features of the cloud tooling are still important for cloud-based IVD testing. These features may include storing test data at the cloud tooling platform

1002, such as a patient test record history and analysis, determining diagnostic and drug recommendations based on analysis of the stored history and for performing multiple user data aggregation and statistical analysis. Additional features enabled by the cloud tooling platform 1002 may include enabling software/firmware updating of the test device; remote or interactive use of the test device (e.g., reading of the test device results) using a cell phone, cellular-enabled device 1102, or user computing device 1014; remote access and control of the test device by an authorized user using a cell phone, a cellular-enabled device 1102, or a user computing device 1014; and telemedicine applications through remote access by a medical professional using a cellular-enabled device 1 102 or a user computing device 1014.

[00194] This disclosure provides various example implementations, as described and as illustrated in the drawings. However, this disclosure is not limited to the implementations described and illustrated herein, but can extend to other implementations, as would be known or as would become known to those skilled in the art. Reference in the specification to "one implementation," "this implementation," "these implementations" or "some implementations" means that a particular feature, structure, or characteristic described is included in at least one implementation, and the appearances of these phrases in various places in the specification are not necessarily all referring to the same implementation.

Conclusion

[00195] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the claims.

Claims

1. A method comprising:

under control of one or more processors configured with executable instructions,

receiving an identifier;

determining, based at least in part on the identifier, calibration information corresponding to a substance to be used with a device; and

sending the calibration information to at least one of:

the device, or

an intermediary device able to pass the calibration information to the device.

2. The method as claimed in claim 1, wherein the device is network-enabled, and the calibration information is directly sent to the device.

3. The method as claimed in claim 1, wherein:

the calibration information is first sent to the intermediary device, which is network-enabled; and

the calibration information is subsequently transferred from the intermediary device to the device.

4. The method as claimed in claim 1, wherein the calibration information comprises at least one of:

calibration data which is an input of a calibration program installed and executed on the device; or

calibration instructions or parameters that are an output of a calibration program installed and executed at a computing device located remotely from the device.

5. The method as claimed in claim 1, wherein:

the substance is a reagent; and

the calibration information is batch-specific calibration information corresponding to a particular batch of the reagent.

6. The method as claimed in claim 1, wherein:

the identifier includes an identifier of a particular batch of the substance; and the calibration information is batch-specific calibration information corresponding to a particular batch of the substance.

7. The method as claimed in claim 1, wherein the identifier includes an identifier of the device, the method further comprising:

identifying a user account corresponding to the identifier; and

determining a particular batch of the substance based at least in part on the identified user account, the calibration information corresponding to the particular batch of the substance.

8. The method as claimed in claim 1, wherein the identifier includes an identifier of at least one of a user or a user account, the method further comprising:

identifying a user account corresponding to the identifier; and

9. The method as claimed in claim 1, wherein determining the calibration information further comprises:

determining a type of the device; and

executing, on a computing device remote from the device, a device calibration program to determine at least one calibration setting to include with the calibration information sent to the device or the intermediary device.

10. The method as claimed in claim 1, wherein:

the device is a test device; and

the identifier is received from at least one of the test device, the intermediary device, or a different device.

11. The method as claimed in claim 7, wherein the intermediary device or the different device comprises at least one of:

a cellular phone;

a smart phone; or

a tablet computing device.

12. A system comprising:

one or more processors; and

one or more computer-readable media maintaining one or more modules that, when executed by the one or more processors, cause the one or more processors to perform operations including:

sending an identifier to a computing device over a network;

receiving, based at least in part on the identifier, calibration information corresponding to a reagent; and

applying at least one calibration parameter to a test device based at least in part on the received calibration information.

13. The system as claimed in claim 12, the operations further comprising, prior to sending the identifier, reading the identifier, by the test device, by electronically reading at least one of: a barcode; a radiofrequency identification tag; a magnetic strip; or a printed character string, wherein the test device sends the identifier to the computing device.

14. The system as claimed in claim 12, the operations further comprising, further comprising, prior to sending the identifier, reading the identifier by electronically reading at least one of: a barcode or a printed character string using a different device from the test device, wherein the different device sends the identifier to the computing device.

15. The system as claimed in claim 12, the operations further comprising in response to receiving the calibration information, executing a calibration program on the test device to apply the at least one calibration parameter.

16. The system as claimed in claim 12, wherein:

the identifier identifies a particular batch of the reagent; and

the calibration information corresponds to the particular batch of the reagent.

17. The system as claimed in claim 12, the operations further comprising:

accessing a user interface on a cellular-enabled device; and

controlling at least one function of the test device via the user interface.

18. The system as claimed in claim 17, wherein the user interface on the cellular- enabled device communicates, at least in part over a cellular network, with a module on a computing device to control the at least one function of the test device.

19. One or more computer-readable media maintaining instructions executable by one or more processors to perform operations comprising:

receiving, from a device, a request for calibration, the request including at least one identifier;

determining, based at least in part on the identifier, batch-specific calibration information; and

sending, to the device, in response to the request, the batch-specific calibration information.

20. The one or more computer-readable media as claimed in claim 19, wherein the batch-specific calibration information corresponds to a particular batch of a reagent to be used with the device.

21. The one or more computer-readable media as claimed in claim 20, wherein the identifier is an identifier of the particular batch of the reagent.

22. The one or more computer-readable media as claimed in claim 19, wherein determining the batch-specific calibration information further comprises:

identifying a calibration program corresponding to the device; and

executing the calibration program based at least in part on the batch-specific calibration information.

23. The one or more computer-readable media as claimed in claim 19, wherein the device is an in vitro diagnostic test device.

24. A system comprising:

one or more processors;

one or more computer-readable media maintaining one or more modules executable by the one or more processors, the one or more modules comprising at least one of:

a signal processing module to receive a signal from a device, perform signal processing of the signal, and sending a result of the signal processing to at least one of the device, or a user computing device to be viewed.

25. The system as claimed in claim 24, further comprising a data analysis module to analyze the result of the signal processing prior to sending the result of the signal processing to at least one of the device or the user computing device.

26. The system as claimed in claim 24, wherein the signal is received from the device, at least in part, via a cellular network.

27. The system as claimed in claim 24, further comprising a user interface module for interacting with a computing device and the electronic device to enable the computing device to control at least one function of the electronic device.

28. A method comprising:

associating an electronic device and a mobile device with a user account held at a server;

receiving, at the server, from the mobile device a communication to control at least one function of the electronic device; and

based at least in part on association of the electronic device with the user account, sending an instruction to the electronic device to control the at least one function.

29. The method as claimed in claim 28, wherein the instruction is sent to the electronic device, at least in part, over a cellular network.

30. The method as claimed in claim 28, wherein:

the communication to control the at least one function further comprises information entered via the mobile device; and

the instruction includes an instruction to update data of the electronic device based at least in part on the information.

31. The method as claimed in claim 28, further comprising:

receiving a signal from the electronic device;

performing signal processing to determiner information related to the signal; and

based at least in part on the association with the user account, sending the information related to the signal to at least one of the mobile device or the electronic device.