Patent Description:
Medical devices, diagnostic devices, or other types of devices may be embedded computing devices, constrained devices, or other computing devices that include processors, memory, and/or other computing elements, and that can present a user interface on a screen or other display. Such devices may execute software, such as firmware, operating systems, and/or applications, that can render the user interface and/or determine content to present within the user interface.

Conventionally, content for a user interface of a device can be defined within software code executed by the device. For example, firmware of a device may be hard-coded to display specific text in association with specific user interface elements. Accordingly, to change text strings or other user interface content displayed by such a device, a new version of device software that includes altered lines of code defining the user interface content changes can be created and tested, be delivered to the device, and be installed on the device.

However, conventional methods of changing user interface elements by creating and installing new software versions on devices can lead to delays, inconsistencies between devices, and other issues. For example, if firmware of a device is hard-coded to use a particular text string in a user interface, changing that text string in the user interface may require a new version of the firmware to be installed on the device that has been coded to include an altered version of the text string. Although the change to the text string in the firmware code may be relatively small, for instance to change a single word or to fix a typographical error in some cases, it may take weeks or months for the new firmware code version to be fully tested for compliance with rules and regulations that apply to the device. For example, regulations for medical devices may require exhaustive testing for new firmware versions, such that a manufacturer may have to go through such testing even if the only change relative to a previous firmware version is an adjustment of user interface text. This process may be further lengthened if a manufacturer produces multiple types and/or models of devices, and has to individually re-code and test software for each device type and/or model in order to make user interface changes that are consistent across the devices.

Additionally, conventional software updates may have to be delivered to devices and installed on the devices. Installing new software, such as a new firmware version that includes changes to user interface text or other user interface content, on a device may involve a reboot of the device. Accordingly, users may be unable to use a device for its primary purpose during a firmware update or other software update that includes changes to user interface content.

Hard-coding specific user interface content into device software can also delay device production and/or shipping of the devices to end-users. For example, a manufacturer may have to delay shipping a device until corresponding device software that includes specific user interface content in numerous languages that users may potentially use has been fully coded and tested. In many cases users of a particular device may be likely to only view user interface content in one or two of those languages, such that waiting to ship the device until software with hard-coded text in numerous languages is ready can lead to delays and increase the size of software code stored in memory on the device.

<CIT> describes methods and apparatus for widget intercommunication in a wireless communication environment. In particular the described aspects relate to dynamically exchanging content between application graphical user interface widgets executed on a widget runtime model.

The example systems and methods described herein may be directed toward mitigating or overcoming one or more of the deficiencies described above.

Software of devices, such as medical devices or other constrained devices configured to implement specific functions, can use content files to determine text strings or other content values to present in association with user interface elements. Devices can download or receive relevant content files, such as new versions of previously-stored content files or new content files containing text in different languages, from a remote content file repository. The software of the devices can accordingly update content values presented in user interfaces based on newly received content files, without the software being re-coded, re-tested, and/or re-validated, and/or without restarting the software or rebooting the devices.

According to a first aspect, a method includes presenting, via software executing on a medical device configured to perform patient monitoring operations, a user interface comprising a patient data element and user interface elements different to the patient data element. The patient data element present patient data that is locally determined via the patient monitoring operations performed by the medical device. The user interface elements comprise at least one of a button, a label, or a logo. The software associates individual user interface elements of the user interface with corresponding content identifiers. First content values, predefined in a default content file stored in a memory of the medical device, are displayed on the individual user interface elements. At a first time, the software determines first content values to display on the individual user interface elements based on the default content file stored in the memory of the medical device. The method also includes loading a second content file into the memory of the medical device during execution of the software. The second content file is provided by a content file repository remote from the medical device, and defines second content values that correspond to the content identifiers. The method further includes updating, via the software executing on the medical device, the content values displayed on the user interface elements based at least in part on the second content values indicated by the second content file. The content values displayed on the user interface elements are updated, based at least in part on the second content values defined by the second content file, without upgrading the software, restarting the software on the medical device, or rebooting the medical device.

According to a second aspect, a medical device includes one or more processors and memory. The memory stores computer-executable instructions associated with software that, when executed by the one or more processors, cause the one or more processors to perform operations. The operations include presenting a user interface comprising a patient data element and user interface elements different from the patient data element. The patient data element presents patient data that is locally determined via patient monitoring operations performed by the medical device. The user interface elements comprise at least one of a button, a label, or a logo. Individual user interface elements of the user interface are associated with corresponding content identifiers. First content values, predefined in a default content file stored in a memory of the medical device, are displayed on the individual user interface elements. At a first time, content values, displayed on the user interface elements are determined based on the default content file stored in the memory. The operations also include loading a second content file into the memory. The second content files are provided by a content file repository remote from the medical device, and defines second content values that correspond to the content identifiers and are associated with the user interface elements. The operations further include updating the content values displayed on the individual user interface elements based at least in part on the second content file. The content values displayed on the user interface elements are updated, based at least in part on the second content values indicated by the second content file, without upgrading the software, restarting the software on the medical device, or rebooting the medical device.

<FIG> shows an example of a system <NUM> for remotely updating user interface content on one or more devices <NUM>. The devices <NUM> can include at least one communication interface <NUM> that allows the device to be in at least occasional data communication with a content file repository <NUM> via a network <NUM>, and/or include data ports, memory card slots, or other interfaces that allow data from the content file repository <NUM> to be provided to the devices <NUM> via intermediate computing devices, removable storage units, or other data delivery mechanisms. The content file repository <NUM> can store content files <NUM>, such as content files <NUM> containing text strings, icons or other graphical elements, audio data, animation data, and/or other types of content that can be presented via user interfaces associated with the devices <NUM>. As described further below, the content file repository <NUM> can transmit content files <NUM> to the devices <NUM> via the network <NUM>, and/or the devices <NUM> can receive content files <NUM> provided by the content file repository <NUM> via intermediate computing devices, removable storage units, or other data delivery mechanisms. The devices <NUM> can accordingly use content files <NUM>, provided by the content file repository <NUM>, to adjust content presented by the devices <NUM> via user interfaces, for example without installing new software that includes hard-coded changes to user interface content, without restarting software executed by the devices <NUM>, and/or without rebooting the devices <NUM>.

Each of the devices <NUM> can be a computing device that includes at least one processor <NUM> and memory <NUM>. The devices <NUM> can also each include the communication interface <NUM> that allows the devices <NUM> to communicate with the content file repository <NUM> via the network <NUM>, and/or other interfaces by which the devices <NUM> can receive content files <NUM> from other computing devices, removable storage units, and/or other data delivery mechanisms. The processor <NUM> of each device can perform at least some data processing to implement functions of the device, and/or to present information via a user interface as described herein.

As described further below, the devices <NUM> may be embedded and/or constrained devices, such as medical devices or other specialized computing devices designed to perform specific functions. For instance, in some examples, the devices <NUM> can be "smart" medical or diagnostic devices, such vision screening devices, cameras, otoscopes, blood pressure monitors, other types of patient monitoring devices, medical screening devices, and/or other types of devices. In other examples, the devices <NUM> can be other types of sensors, smart devices, Internet of Things (IoT) devices, or other devices. The devices <NUM>, such as device 102A, device 102B, and device 102C shown in <FIG>, can include instances of the same type of device or include multiple types of devices. For example, the devices <NUM> can include one or more models of a particular device type, or include multiple models and/or device types.

The memory <NUM> of a device can store computer-implemented instructions and/or other data associated with software <NUM> executed by the processor <NUM> of the device. As described further below, such data stored in the memory <NUM> of a device can include code and data associated with the software <NUM> itself, as well as one or more separate content files <NUM> that can be used by the software <NUM>. The software <NUM> can include firmware of the device, an operating system of the device, one or more applications that the device can execute, or other types of software that can be executed by the device. As described further below, the device can be a medical device, or other embedded or constrained device, that may have a smaller amount of memory than a general purpose computer or other types of computing devices. Accordingly, the size of the memory <NUM> of the device may be sufficient to store data associated with device firmware and/or primary applications associated with specific functions of the device as well as a limited number of content files <NUM>, such as up to five content files <NUM> or any other maximum number of content files <NUM>. However, the size of the memory <NUM> may not be sufficient to store additional data beyond the firmware and/or primary applications associated with specific functions of the device and the limited number of content files <NUM>.

The software <NUM> that executes on a device can be configured to use one or more content files <NUM>, stored in the memory <NUM> of the device, to present information via a user interface. The content files <NUM> can be default content files <NUM>, and/or content files <NUM> provided by the content file repository <NUM> that are loaded into memory <NUM> of the device via the network <NUM> and/or other data delivery mechanisms.

As described herein, individual devices <NUM> can download or receive one or more specific content files <NUM> from the content file repository <NUM>, such as content files <NUM> containing text strings in different languages, updated versions of text strings that change words, phrases, web links, and/or other text, new or alternate graphical elements, new or alternate audio data, new or alternate animation data, or any other type of content. As an example, if the content file repository <NUM> stores a set of content files <NUM> that includes content file 110A, content file 110B, and content file 110C, the device 102A may download content file 110B from the content file repository <NUM> and store content file 110B in the memory <NUM> of device 102A as shown in <FIG>. The software <NUM> of each device can use such downloaded content files <NUM> to display corresponding content in a user interface, without the software <NUM> itself being updated, re-installed, or restarted, and/or without the device being rebooted.

The content file repository <NUM> can be a server, database, cloud computing element, or other data storage location that can store and maintain content files <NUM>, and that can transfer individual content files <NUM> to individual devices <NUM> over the network <NUM>. For example, the content file repository <NUM> may have an Application Programming Interface (API) or other interface that allows devices <NUM> to query the content file repository <NUM> for content files <NUM> and/or to receive content files <NUM> from the content file repository <NUM>.

The content file repository <NUM> can be owned or operated by an entity that manufactures the devices <NUM>, and/or sells or otherwise provides the devices <NUM> to users. The entity, such as a manufacturer of the devices <NUM>, can generate new and/or updated content files <NUM> over time, and can load the content files <NUM> to the content file repository <NUM>. Accordingly, the devices <NUM> can receive new or updated content files from the content file repository <NUM> over the network <NUM> after the devices <NUM> have been sold or deployed in the field. For example, over time the entity may develop new content files <NUM> that contain text strings in different languages, and/or create new versions of previously-existing content files <NUM> that alter text strings or other content values provided in the content files <NUM>. The entity can add the new or updated content files <NUM> to the content file repository <NUM>, such that the new or updated content files <NUM> become available to the devices <NUM>.

In some examples, one or more default content files <NUM> may initially be loaded into the memory <NUM> of a device when the device is manufactured or provisioned before being shipped or deployed in the field. However, in some situations the device may overwrite a default content file stored in the memory <NUM> with another content file received from the content file repository <NUM>. For instance, the device may receive a newer version of a default content file from the content file repository <NUM>, and overwrite the default content file with the newer version received from the content file repository <NUM>. In other situations, the device may store a content file received from the content file repository <NUM> in the memory <NUM> in addition to default content file previously stored in the memory <NUM>. For instance, if a default content file stored in the memory <NUM> is an English content file containing English text strings, the device may receive a separate Spanish content file containing Spanish text strings from the content file repository <NUM>, and store the Spanish content file in the memory <NUM> in addition to the default English content file.

Similarly, in some situations a device may overwrite any other content file previously-stored in the memory <NUM> of the device with another content file received from the content file repository <NUM>. For instance, at a first time, a device may receive a first version of a content file from the content file repository <NUM>, and store the first version of the content file in the memory <NUM>. At a second time, the device may receive a second version of the content file from the content file repository <NUM>, and replace the first version of the content file with the second version of the content file in the memory <NUM>. In other situations, the device may store a content file received from the content file repository <NUM> in the memory <NUM> in addition to one or more other content files previously received from the content file repository <NUM>.

The devices <NUM> can, in some examples, be embedded devices or constrained devices that are designed to perform specific functions. For example, the devices <NUM> can be medical devices that are configured to perform particular patient monitoring or diagnostic functions. The processor <NUM>, memory <NUM>, and/or other computing resources of such embedded devices or constrained devices may be less powerful and/or more limited than computing resources of general purpose computers, smartphones, or other types of computing devices. For instance, while a general purpose computer may have a relatively large hard drive, such that users can store large amounts of user data or install numerous applications, the memory <NUM> of the devices <NUM> may be smaller and/or be sized to store relatively small amounts of data that the devices <NUM> use to perform specific operations. Accordingly, the memory <NUM> of each of the devices <NUM> may be limited in size, and have enough space to store a relatively small number of content files <NUM>, such as one content file, two content files, three content files, or any other relatively small number of content files, in addition to the software <NUM> and/or other data stored in the memory <NUM>.

As a non-limiting example, if the device 102A is a type of patient monitoring device, the memory <NUM> of device 102A may be sized to store software <NUM> and data that device 102A uses to implement specific patient monitoring operations. The memory <NUM> of the device 102A may also have sufficient space to store up to five content files <NUM>, or any other relatively small maximum number of content files <NUM>, in addition to the software <NUM> and/or other data that device 102A uses to implement the patient monitoring operations. However, in some situations the content file repository <NUM> may store tens or hundreds of different content files <NUM>, such that the memory <NUM> of device 102A may only have enough space to store a relatively small percentage of the total number of content files <NUM> available from the content file repository <NUM>.

As discussed above, the devices <NUM> can have at least one communication interface <NUM>, such as a network interface or other data communication interface, that allows the devices <NUM> to connect to the network <NUM>. The network <NUM> can include the Internet and/or other data networks. Different types of devices <NUM> may have different types of communication interfaces. For example, some devices <NUM> can have Ethernet, Wi-Fi®, cellular, and/or other wired or wireless data connections that allow the devices to directly connect to the network <NUM> and communicate with the content file repository <NUM>. However, other devices <NUM> may have Bluetooth® connections, or other wired or wireless connections, by which the devices <NUM> can connect to Internet-connected computers or other intermediate devices that can connect to the network <NUM>. In these examples, such devices <NUM> can access the network <NUM> and the content file repository <NUM> when the devices <NUM> are tethered to, or are otherwise connected to, other intermediate devices that have connections to the network <NUM>.

In some examples, communication interfaces of some devices <NUM> may also, or alternately, include a memory card reader, Universal Serial Bus (USB) port, or other removable storage interface, by which the devices <NUM> can receive content files <NUM> that have been downloaded from the content file repository <NUM> by other devices <NUM>, computers, or other computing elements. For example, an Internet-connected computer may download a content file from the content file repository <NUM>, and load the content file onto a removable storage unit, such as a USB flash drive or a memory card. A user may then physically transfer the removable storage unit to one of the devices <NUM> and attach the removable storage unit to a removable storage interface of the device, such that the memory <NUM> of the device can receive the content file downloaded from the content file repository <NUM> via the removable storage unit. As another example, an Internet-connected computer may download a content file from the content file repository <NUM>, and a user may then connect the Internet-connected computer to one of the devices <NUM> via an Ethernet cable, a USB cable, a Bluetooth® connection, or other data interface, such that the memory <NUM> of the device can receive a copy of the content file that the Internet-connected computer downloaded from the content file repository <NUM>.

Individual devices <NUM> can include, or be associated with, at least one input element <NUM>, such as a camera, a scanner, a sensor, or other type of input element. Different types of devices <NUM> may have different types of input elements. For example, a vision screening device may have one or more input elements that include a camera or other optical input sensor, while a blood pressure monitor may have one or more input elements that include a blood pressure sensor. In some examples, the input elements of a device can also include a keyboard, mouse, touchscreen, buttons, switches, and/or other user input devices that a user can use to operate the device.

Individual devices <NUM> can also include, or be associated with, at least one output element <NUM>, such as a screen, a speaker, a printer, or other type of output element. The output element <NUM> associated with a device can present a user interface. As described herein, content of the user interface presented via the output element <NUM> can be based, at least in part, on one or more content files <NUM> stored in the memory <NUM> of the device, such as a content file received from the content file repository <NUM>.

Different types of devices <NUM> may have different types of output elements. For example, some devices <NUM> may have integrated screens, speakers, printers, and/or other types of output devices. Accordingly, such devices <NUM> can directly present user interface content via such integrated output elements, for instance by displaying user interface information on an integrated screen or by printing user interface information via an integrated printer. However, other devices <NUM> may connect to external output elements, such as external monitors, external printers, external devices, or other external output elements. As an example, a device without an integrated screen may use the communication interface <NUM> of the device to pair with a mobile phone, such that the device can use a screen of the mobile phone as the output element <NUM>, and the device can display a user interface via the screen of the mobile phone.

In some examples, content files <NUM> that are stored at the content file repository <NUM>, and/or can be stored on and used by the devices <NUM>, can be data files, such as JavaScript Object Notation (JSON) files, Extensible Markup Language (XML) files, comma-separated value (CSV) files, or other types of data files. In other examples, the content files <NUM> can be other types of data elements, such as database data, binary data, data objects, a binary large object (BLOB), or other types of data elements or data structures.

A content file can include attribute-value pairs or other data that indicate specific content values associated with corresponding user interface elements. For example, user interface elements that can be rendered, displayed, or presented by the software <NUM> can be associated with corresponding content identifiers. User interface elements can include buttons, labels, fields, and/or other user interface elements. A content file can indicate specific content values associated with one or more content identifiers, such as text strings, graphics, audio data, animation data, or other content values. Accordingly, the software <NUM> can be configured to determine content identifiers of particular user interface elements that are to be presented in a user interface, locate content values associated with those content identifiers in one or more content files <NUM>, and use the content values from the content files <NUM> to present the particular user interface elements.

For example, a particular content file may include a set of text strings that may be displayed in user interfaces of one or more devices <NUM>. Each of the text strings in the content file may be associated with a corresponding content identifier. Code of software <NUM> that executes on one or more devices <NUM> can reference content identifiers in association with individual user interface elements, such that the software <NUM> can use content identifiers to retrieve the corresponding text strings from the content file. For instance, software <NUM> executing on device 102A may determine that a confirmation button is to be rendered in a user interface shown on a screen of device 102A. Code of the software <NUM> may be configured to identify situations in which a confirmation button is to be displayed in the user interface, but may not indicate specific text to display within the confirmation button. However, the code of the software <NUM> may indicate that the confirmation button is associated with a particular content identifier. The device 102A may have content file 110B in memory <NUM>, as shown in <FIG>. Content file 110B may indicate that a text string of "OK" is associated with the particular content identifier that is also associated with the confirmation button. Accordingly, the software <NUM> can use the particular content identifier to retrieve the "OK" text string from the content file 110B, and render a confirmation button that displays the "OK" text string.

Different content files <NUM> may indicate different values for the same content identifier. For instance, while content file 110B may indicate that a text string of "OK" is associated with the particular content identifier discussed in the example above, content file 110A may indicate that a text string of "Okay" is associated with the same content identifier. Accordingly, if device 102A had content file 110A in memory <NUM> instead of content file 110B in the example discussed above, the software <NUM> could have retrieved the "Okay" text string from content file 110A and rendered a confirmation button that displayed the "Okay" text string instead of the "OK" text string. Other examples of differences between content files <NUM> are discussed further below with respect to <FIG>.

As discussed above, in some examples the devices <NUM> may include different devices types and/or device models. However, the user interfaces associated with different device types and/or model types may have the same or similar types of user interface elements. For example, user interfaces associated with devices produced by the same manufacturer may include the same, or similar, types of buttons, icons, messages, graphics, sounds, animations, and/or other user interface elements. Accordingly, in some examples, content files <NUM> that include content values that may be used by multiple models and/or types of devices <NUM> can be provided by the content file repository <NUM>.

As a non-limiting example, a manufacturer may produce vision screening devices and blood pressure monitors. Although vision screening devices and blood pressure monitors may be designed to perform different medical tasks, the user interfaces associated with the vision screening devices and blood pressure monitors may have some consistent user interface elements, such as identical confirmation buttons. The vision screening devices and blood pressure monitors may have been shipped with default content files <NUM> that cause the devices to display "Okay" in confirmation buttons. However, if the manufacturer later chooses to change its user interface style from using "Okay" to using "OK" across all of its devices, the manufacturer can add a new content file to the content file repository <NUM> that includes an "OK" text string instead of an "Okay" text string. The vision screening devices and blood pressure monitors can, opportunistically and without impacting usability of the devices, download the new content file from the content file repository <NUM> such that the new content file causes the software <NUM> of the vision screening devices and blood pressure monitors to each begin displaying "OK" in confirmation messages in accordance with the manufacturer's updated user interface style. In this example, although the software <NUM> of the vision screening devices and blood pressure monitors may be different, and implement different medical tasks, the new content file can alter the text of confirmation messages displayed in user interfaces by the software <NUM> without changes to the software <NUM> itself.

In some examples, content files <NUM> stored at the content file repository <NUM> may contain a master set of text files, or other types of content, that can be used by any device. For instance, a most recent version of a content file that can be downloaded or received by any device can include a master set of <NUM> text strings. The software <NUM> of different devices may be configured to use different subsets of that master set of text strings. For example, software <NUM> of device 102A may be configured to use content identifiers that correspond to a subset of <NUM> text strings, within the master set of <NUM> text strings, to retrieve content values to display in a user interface of device 102A. However, software <NUM> of device 102B may be configured to use content identifiers that correspond to a different subset of <NUM> text strings, within the master set of <NUM> text strings, to retrieve content values to display in a user interface of device 102B. In this example, device 102A and device 102B may each receive the same content file from the content file repository <NUM> that includes the most recent master set of text files, but device 102A and device 102B may use different subsets of those text files in corresponding user interfaces.

In other examples, some content files <NUM> available at the content file repository <NUM> may be specific to certain types and/or models of devices. For instance, if a user interface for a particular type of device may use a text string that is specific to that type of device, and that user interfaces of other types of devices may not be likely to use, the text string may be included within a content file associated with that particular type of device. Accordingly, instances of that type of device may download or receive the device-specific content file from the content file repository <NUM>, while other types of devices may not download or receive the device-specific content file from the content file repository <NUM>. In some examples, such device-specific content files <NUM> may be downloaded, received, and/or used by devices <NUM> in addition to, or instead of, one or more other content files <NUM> that include master sets of text files or other content values that may be used by multiple types or models of devices.

The content files <NUM> stored at the content file repository <NUM> may be associated with version numbers. As a non-limiting example, content file 110A and content file 110B may both contain English text strings, but content file 110B may be a more recent version of content file 110A that includes changes or corrections to English text strings that were included in content file 110A. In these examples, devices <NUM> and/or the content file repository <NUM> may compare version numbers of content files <NUM> currently stored in memory <NUM> by individual devices <NUM> against the version numbers of corresponding content files <NUM> stored at the content file repository <NUM>. Accordingly, the content file repository <NUM> can provide the most recent versions of content files <NUM> to individual devices <NUM>, and/or can avoid providing devices <NUM> with content files <NUM> if the devices <NUM> already have the most recent versions of the content files <NUM>. In some examples, when a new version of a content file is added to the content file repository <NUM>, an older version of the content file can be archived or removed from the content file repository <NUM>, such that only the most recent version of the content file is available to devices <NUM> at the content file repository <NUM>.

Different content files <NUM> stored at the content file repository <NUM> may also be associated with different languages. For example, content file 110B may include a set of English text strings, and content file 110C may include a set of Spanish text strings. In this example, devices <NUM> that are located in English-speaking countries, or for which user preference settings indicate that users of the devices <NUM> want to read user interface elements in English, can download, receive, and/or use content file 110B. However, other devices <NUM> that are located in Spanish-speaking countries, or for which user preference settings indicate that users of the devices <NUM> want to read user interface elements in Spanish, can download, receive, and/or use content file 110C. In this example, the software <NUM> of a device located in an English-speaking country may be identical to the software <NUM> of a similar device located in a Spanish-speaking country, and may associate the same content identifiers with the same user interface elements. However, a device that receives and uses content file 110B can use an English version of a text string to display a particular user interface element, while another device that receives and uses content file 110C can use a corresponding Spanish version of the text string to display the same particular user interface element.

Individual devices <NUM> may determine which language-specific content files <NUM> to obtain from the content file repository <NUM> based on user settings, device location data, Internet Protocol (IP) address information, and/or other data. In some examples, a device may display a user interface with content presented in a default or currently-selected language, based on a current content file stored in memory <NUM> of the device. However, a user can use the user interface to select a preference for a different language. The device can accordingly request the most recent version of a content file corresponding to the user-selected language from the content file repository <NUM>, such that the device can begin using the user-selected language to display content in the user interface.

In other examples, a device may include a Global Positioning System (GPS) sensor or other type of location sensor that can indicate a location of the device, and/or an IP address, a business or registration address, or other data may indicate a location of the device. If location data associated with the device indicates that the device is currently located in a particular country or area, the device may request the most recent version of a content file corresponding to a language frequently spoken in that country or area. Accordingly, the device can use a local language content file to automatically begin using the local language to display content in the user interface, and/or to make settings to change the user interface to the local language available to be selected by users. As a non-limiting example, a particular device may be provisioned at a factory with the only content file in memory <NUM> of the device being a default English-language content file, but the device may later be shipped to Paris, France. If GPS data, IP address data, device registration data, and/or other location data indicates that the device has been moved to France, the device may automatically request a most-recent French-language content file from the content file repository <NUM>, as it may be likely that users of the device in France will want to read French text in the user interface of the device.

In some examples, the devices <NUM> can be configured to periodically or occasionally query the content file repository <NUM>, via the network <NUM>, to determine whether the content file repository <NUM> stores any content files <NUM> that are relevant to the devices <NUM> and that the devices <NUM> should download. For example, the devices <NUM> can query the content file repository <NUM> to determine whether the content file repository <NUM> stores new versions of content files <NUM> already stored in memory <NUM> by the devices <NUM>. As another example, the devices <NUM> can query the content file repository <NUM> to determine whether the content file repository <NUM> stores any other content files <NUM> that may be relevant to the devices <NUM>, such as content files <NUM> associated with particular languages as described above.

The devices <NUM> can be configured to query the content file repository <NUM> for new relevant content files <NUM> once per hour, once per day, once per week, or on any other scheduled basis. The devices <NUM> can also, or alternately, be configured to query the content file repository <NUM> in response to trigger events. For instance, a device may query the content file repository <NUM> when the device is powered on, when the device becomes connected to the network <NUM>, and/or in response to a user instruction to check for updates to content files <NUM>. As another example, if one or more new content files <NUM> are added to the content file repository <NUM>, the content file repository <NUM> may send a notification to the devices <NUM> over the network <NUM>. The notification may instruct the devices <NUM> to query the content file repository <NUM> at the next opportunity for each device, for instance to determine whether the new content files <NUM> are relevant to the individual devices <NUM>.

In some examples, the devices <NUM> can be configured to query the content file repository <NUM> and/or download content files <NUM> during periods in which the devices <NUM> are otherwise idle, but have a connection to the network <NUM>. For instance, if a device is a patient monitoring device or other type of medical device, the device may wait for an idle period during which the device is not actively being used for medical tasks, and then query the content file repository <NUM> and/or download content files <NUM> during the idle period if the device is connected to the network <NUM>.

While devices <NUM> may query the content file repository <NUM> and/or download content files <NUM> during times when the devices <NUM> have direct or indirect connections to the network <NUM> as described above, in some examples content files <NUM> can also be delivered to devices <NUM> via removable storage units. For example, a computer or other separate device can query the content file repository <NUM> for new content files <NUM>, download new content files <NUM>, and transfer downloaded content files <NUM> to a USB flash drive, memory card, or other removable storage unit. The removable storage unit can then be transferred to one or more devices <NUM> that do not have network connections, such that the devices <NUM> can receive downloaded content files <NUM> via the removable storage unit. Similarly, a computer or other separate device can query the content file repository <NUM> for new content files <NUM>, download new content files <NUM>, and transfer downloaded content files <NUM> to devices <NUM> via local wired or wireless data connections.

In some examples, the content files <NUM> provided by the content file repository <NUM> can be encrypted, and/or can be transferred to the devices <NUM> over secure network connections. Accordingly, devices <NUM> may perform decryption operations and/or validation operations on downloaded content files. For instance, the software <NUM> of a device may be configured to use a decryption key or other cipher to decrypt a received content file, and/or verify that the received content file matches a hash code. Additionally, if a received content file is a replacement for a content file already stored in memory <NUM> of a device, the device can be configured to verify that a version number of the newly received content file is greater than the version number of the current content file before overwriting the current content file with the new content file in the memory <NUM>.

In some examples, individual devices <NUM> may each store a local master content file in memory <NUM>, and may update the local master content file based on new or updated content files <NUM> received from the content file repository <NUM>. For example, a device may have a local master content file that includes a series of attribute-value pairs defining content values associated with content identifiers. In this example, the device may receive a first content file from the content file repository <NUM> that includes additional content identifiers and corresponding content values. Accordingly, the device can edit its local master content file to add the additional content identifiers and corresponding additional content values based on the newly received first content file. If the device later receives a second content file from the content file repository <NUM> that adjusts the content values associated with any of the content identifiers in the local master content file, such as any of the content identifiers that were initially in the local master content file or that were added to the local master content file based on the first content file, the device can edit corresponding entries in the local master content file based on the second content file.

After a device receives a new content file from the content file repository <NUM>, the software <NUM> of the device can use the new content file to determine content to present in a user interface of the device. For example, as discussed above, the software <NUM> can be configured to display user interface elements that are associated with content identifiers, based on separate content files <NUM> stored in the memory <NUM> of the device that indicates content values that correspond to the content identifiers associated with the user interface elements. Accordingly, as soon as the device receives a new content file that includes content values associated with those content identifiers, the software <NUM> can use the new content file to retrieve content values associated with user interface elements, and present those content values in a user interface. Because the software <NUM> itself has not changed, the software <NUM> can use new content values provided in a newly received content file almost immediately, without the device being rebooted, without the software <NUM> being restarted, and without a new version of the software <NUM> being installed on the device. In some examples, the software <NUM> may be configured to wait until the device is in an idle state before updating user interface elements based on a newly received content file, to avoid confusing a user by adjusting user interface elements while the device is in active use.

Overall, the systems and methods described herein can allow user interfaces associated with devices <NUM> to be updated based on new or different content files <NUM>, without developing or installing new versions of software <NUM> for the devices <NUM>, and without the devices <NUM> being rebooted or restarting the software <NUM>. As a non-limiting example, to update a text string displayed in a user interface button presented by a device, a manufacturer of the device can generate a new content file that includes an updated text string, and can upload the new content file to the content file repository <NUM>. The software <NUM> of the device can check the content file repository <NUM> for new content files, and accordingly download the new content file. The software <NUM> of the device can directly use the new content file to identify the updated text string, and use the updated text string to present the updated text string in association with the user interface button, without the software <NUM> itself being updated or restarting, and without the device being rebooted.

Accordingly, the text displayed on the user interface button can be updated via a new content file, without the software <NUM> having to be re-coded, re-tested, deployed to the device, and installed on the device. The text displayed on the user interface button can also be updated via a new content file, without the device having to be restarted or rebooted. For some types of devices <NUM>, such as medical devices, that may have relatively stringent standards for developing and testing new software versions, the systems and methods described herein can allow user interface changes to be implemented more quickly than by re-coding software <NUM> to include hard-coded changes to user interface elements. For instance, because the software <NUM> of a device can be configured to determine content values for user interface elements based on content files <NUM>, the software <NUM> can update user interface content based on new content files <NUM> without changes to the software <NUM> itself that might require testing.

In some examples, the systems and methods described herein can also allow devices <NUM> to be provisioned with a single default content file, or other relatively small set of default content files <NUM>, before being shipped or deployed in the field. For instance, a device can be shipped with a default English-language content file, but may not have any other content files <NUM>. When a manufacturer develops additional content files <NUM>, such as an updated English-language content file and/or content files for other languages, devices <NUM> that have already been shipped and deployed in the field can receive those content files <NUM> from the content file repository <NUM>. Accordingly, a device manufacturer may not have to wait to ship devices <NUM> until user interface content in numerous languages is ready.

Additionally, the systems and methods described herein can reduce bandwidth usage by the devices <NUM>. For instance, individual content files <NUM> may be relatively small in size, relative to new versions of the software <NUM>. Accordingly, by releasing user interface updates via relatively small content files <NUM> instead of hard-coding user interface changes into new versions of software <NUM>, devices <NUM> can use less bandwidth over the network <NUM> to download the content files <NUM>, relative to bandwidth the devices <NUM> might otherwise use to download updated versions of the software <NUM>.

Examples of content files <NUM> and how software <NUM> of devices <NUM> can receive and use content files <NUM> are discussed further below with respect to <FIG>, <FIG>, and <FIG>. For example, <FIG> shows various example content files <NUM>, and <FIG> show how a user interface of a device may change based on the use of different content files <NUM>.

<FIG> shows an example <NUM> of content files <NUM> that can be stored at the content file repository <NUM>, and/or that can be used by software <NUM> of devices <NUM> to present user interfaces. For example, devices <NUM> may store one or more of the content files <NUM> by default, and/or receive one or more of the content files <NUM> from the content file repository <NUM>. The content files <NUM> can include, for example, content file 110A, content file 110B, and content file 110C. In example <NUM>, content file 110A can be a first version of an English-language content file, while content file 110A can be a second version of an English-language content file. Content file 110C can be a Spanish-language content file. Devices <NUM> can use, and the content file repository <NUM> can store and provide, other content files <NUM>, such as content files <NUM> that contain text strings for other languages, content files <NUM> that contain images or other graphical data, audio data, animation data, and/or other types of user interface content.

The content files <NUM> can be structured data files, such as JSON files, XML files, CSV files, or other files that include one or more data pairs. Each data pair can associate a content identifier <NUM> with a corresponding content value <NUM>. Each content identifier <NUM> can be a number, alphanumeric character, or any other identifier that the software <NUM> of one of more devices <NUM> associates with one or more user interface elements. Individual content files <NUM> may include the same or different content identifiers. If different content files <NUM> include the same content identifier <NUM>, the different content files <NUM> may associate that content identifier <NUM> with the same or different content value <NUM>. Overall, different content files <NUM> stored at the content file repository <NUM> can include one or more differing content values.

As an example, content file 110A can be a first version of an English-language content file that indicates that content identifier "<NUM>" is associated with a content value of "Okay," and that content identifier "<NUM>" is associated with a content value of "Hello. " Accordingly, any devices <NUM> that store content file 110A by default, or have received content file 110A from the content file repository <NUM>, can display "Okay" in one or more buttons, labels, fields, or other user interface elements that software <NUM> of the devices <NUM> associates with content identifier "<NUM>. " Such devices <NUM> can similarly use content file 110A to display "Hello" in one or more buttons, labels, fields, or other user interface elements that software <NUM> of the devices <NUM> associates with content identifier "<NUM>.

However, content file 110B can be a second version of an English-language content file that can be loaded into the content file repository <NUM> as a replacement for content file 110A. Content file 110B may include at least some different content values relative to content file 110A, such as associating "OK" with content identifier "<NUM>" instead of "Okay" and associating "Welcome" with content identifier "<NUM>" instead of "Hello. " Any devices <NUM> that previously stored and used content file 110A may download content file 110B when the devices <NUM> next query the content file repository <NUM>, or may receive content file 110B via a removable storage unit. Such devices <NUM> can overwrite content file 110A with content file 110B, or update a local master content file based on content file 110B, in memory <NUM> of the devices <NUM>. Accordingly, in response to receiving content file 110B, software <NUM> of the devices <NUM> can change from displaying "Okay" in user interface elements associated with content identifier "<NUM>" based on content file 110A, to displaying "OK" in the user interface elements associated with content identifier "<NUM>" based on content file 110B. Similarly, in response to receiving content file 110B, software <NUM> of the devices <NUM> can change from displaying "Hello" in user interface elements associated with content identifier "<NUM>" based on content file 110A, to displaying "Welcome" in the user interface elements associated with content identifier "<NUM>" based on content file 110B.

As another example, content file 110C can be a Spanish-language content file that can be used by software <NUM> of devices <NUM> instead of English-language content files 110A and 110B. Content file 110C can indicate that particular content identifiers are associated with Spanish-language text strings. Accordingly, any devices <NUM> that store content file 110C by default, or have received content file 110C from the content file repository <NUM>, can display Spanish-language text strings in buttons, labels, fields, or other user interface elements that software <NUM> of the devices <NUM> associates with the corresponding content identifiers.

For example, while English-language content files 110A and 110B may indicate that content identifier "<NUM>" is associated with the English word "Yes," the Spanish-language content file 110C may instead indicate that content identifier "<NUM>" is associated with the Spanish word "Sí. " Accordingly, if software <NUM> of a device indicates that a user interface element, such as user-selectable button, is associated with a content identifier of "<NUM>," the software <NUM> can use the Spanish-language content file 110C to render the user interface element to display "Sí," rather than using an English-language content file to render the user interface element to display "Yes.

In some examples, a device may be provisioned with English-language content file 110A by default. When newer English-language content file 110B becomes available at the content file repository <NUM>, the device may download or receive content file 110B. Software <NUM> of the device can begin using content file 110B to display English user interface content, without a new version of the software <NUM> being installed or the device being rebooted. Additionally, or alternately, if GPS data, IP address data, device registration data, or other location data indicates that a particular device is located in Mexico or another location where Spanish is predominantly spoken, or if user input indicates a Spanish-language user preference, the device can download the Spanish-language content file 110C from the content file repository <NUM>, or otherwise receive content file 110C. Accordingly, software <NUM> of the device may begin using content file 110B to display Spanish user interface content, without a new version of the software <NUM> being installed or the device being rebooted.

Accordingly, as shown in <FIG>, a device may use different content files <NUM> to display different content values in a user interface. An example of software <NUM> using different content files <NUM> to adjust a user interface is discussed further below with respect to <FIG>.

<FIG> show an example <NUM> of software <NUM> of a device displaying different user interface content based on different content files <NUM>. As described above, the software <NUM> may be configured to display various user interface elements in different situations, such as buttons, labels, fields, and/or other user interface elements. For example, the software <NUM> for a patient monitoring device can be configured to display a chart <NUM>, a title bar <NUM>, a logo <NUM>, a first button <NUM>, and a second button <NUM>.

The chart <NUM> may, for example, display patient data measured or received by the patient monitoring device, such as blood pressure measurements over time or any other type of patient data. The software <NUM> may be configured to render the chart <NUM> based on operations of the device without use of a content file.

However, the software <NUM> can be configured to render other user interface elements, such as the title bar <NUM>, the logo <NUM>, the first button <NUM>, and the second button <NUM> based on content values indicated in one or more content files. For instance, the software <NUM> can be configured to associated each of the title bar <NUM>, the logo <NUM>, the first button <NUM>, and the second button <NUM> with one or more content identifiers, as shown in <FIG>. In some examples, the software <NUM> may associate a particular user interface element, such as the title bar <NUM>, with multiple content identifiers. In these examples, the software <NUM> can render a user interface element by concatenating different text strings, or otherwise combining multiple content values, associated with the multiple content identifiers in one or more content files <NUM>.

For example, as shown in <FIG>, the software <NUM> of the device can use one or more content files <NUM> to determine content values associated with the content identifiers the software <NUM> associates with the title bar <NUM>, the logo <NUM>, the first button <NUM>, and the second button <NUM>. For example, the software <NUM> may determine that a content file indicates that content values corresponding to the content identifiers of the title bar <NUM> are "Patient" and "Monitoring," and can combine those content values to display "Patient Monitoring" in the title bar <NUM> of the user interface. Similarly, the software <NUM> may determine that the same content file, or one or more other content files, indicates that the content value corresponding to the content identifier of the first button <NUM> is "Menu" and that the content value corresponding to the content identifier of the second button <NUM> is "Back," and accordingly render the first button <NUM> to display "Menu" and the second button <NUM> to display "Back" as shown in <FIG>. The software <NUM> can also use a content file that contains image data to retrieve an image corresponding to the content identifier of the logo <NUM>, and display that image as the logo <NUM> in the user interface as shown in <FIG>.

At a later point in time, the device may query the content file repository <NUM> for updated versions of the content files the device currently stores in memory <NUM>, and may download such new content files. The new content files may include different content values for some of the content identifiers that the software <NUM> associates with user interface elements. Accordingly, the software <NUM> of the device can change the content of the user interface based on the new content files.

For example, a new content file may indicate that the content value corresponding to the content identifier of the first button <NUM> is "Options," and that the content value corresponding to the content identifier of the second button <NUM> is "Home. " Accordingly, the software <NUM> may use the new content file to change the first button <NUM> from displaying "Menu" (as shown in <FIG> based on a previous content file) to displaying "Options" (as shown in <FIG> based on the new content file), and change the second button <NUM> from displaying "Back" (as shown in <FIG> based on a previous content file) to displaying "Home" (as shown in <FIG> based on the new content file).

In this example, the functionality of the first button <NUM> coded in the software <NUM> may be to present a menu of user-selectable options if a user selects the first button <NUM>, and the functionality of the second button <NUM> coded in the software <NUM> may be to display a home screen of the device. Although the software <NUM> can use different content files to change the text displayed on the first button <NUM> and the second button <NUM> as shown in <FIG>, the functionality of the first button <NUM> and the second button <NUM> coded in the software <NUM> can remain unchanged when the software <NUM> begins using a different content file to determine the content values to present in association with the first button <NUM> and/or the second button <NUM>.

As another example, the software <NUM> of the device can have used a first content file containing image data to retrieve a first image corresponding to the content identifier of the logo <NUM>, and to display that first image as the logo <NUM> in the user interface as shown in <FIG>. However, if at a later point in time the device downloads or receives a new content file containing a second image corresponding to the content identifier of the logo <NUM>, the software <NUM> of the device can change to displaying the second image as the logo <NUM> in the user interface as shown in <FIG>. Accordingly, although the software <NUM> itself can remain the same, the new content file can cause the software <NUM> to change the image displayed as the logo <NUM> without the software <NUM> being upgraded, the software <NUM> restarting, or the device rebooting.

Accordingly, as shown in <FIG>, the software <NUM> of a device can alter the content displayed in a user interface based on different content files <NUM>. <FIG>, discussed further below, shows an example process by which a device can obtain such different content files <NUM> from the content file repository <NUM>.

<FIG> shows a flowchart <NUM> of an example process a device can use to download and use new content files. In this example process, the device can be configured to at least occasionally have access to the network <NUM> and the content file repository <NUM>. For example, the communication interface <NUM> of the device can provide a wired or wireless data connection to a router or other network access point, such that the device can have a direct connection to the network <NUM>. As another example, the communication interface <NUM> of the device can allow the device to be paired or tethered to a second device that has a connection to the network <NUM>, such that the device can access the network <NUM> and the content file repository <NUM> when the device has a network connection via the second device.

The operations shown in <FIG> can be implemented by a computing device, such as one of the devices <NUM>. For example, a computing device can use one or more processors to perform the operations shown in <FIG>, based on computer-executable instructions executed by the one or more processors. The computing device that executes the operations shown in <FIG> can be a medical device or other types of embedded or constrained device that may be configured to perform specific functions, and that may have limited processing power and/or memory relative to general purpose computers or other types of computing devices. An example system architecture for such a computing device is discussed further below with respect to <FIG>.

At block <NUM>, the device can be powered on. Powering on the device can cause the software <NUM> of the device, such as firmware and/or applications, to boot or otherwise begin executing. The software <NUM> may accordingly begin presenting a user interface via the output element <NUM> associated with the device at block <NUM>, and can determine content values to present in association with user interface elements based on at least one content file stored in memory <NUM> of the device. After the device is powered on at block <NUM>, users may use the device for monitoring operations, diagnostic operations, or other operations of functions the device is configured to perform. In some examples, users can access and/or view information via the user interface presented at block <NUM> during use of the device, and/or interact with the device via the user interface presented at block <NUM>.

At block <NUM>, the device can determine whether the device is idle and has an active network connection. In some examples, the device can be configured to perform the operations of block <NUM> on a predefined schedule, such as once an hour, once a day, once a week, or on any other scheduled basis. The device can also, or alternately, be configured to perform the operations of block <NUM> in response to trigger events, such as the device being first powered on at block <NUM> (and before the device enters active use), the device becoming connected to the network <NUM>, the device receiving a user instruction to check for updates to content files <NUM>, or the device receiving a notification of new content files <NUM> from the content file repository <NUM>.

If the device is not idle (Block <NUM> - No), for instance if the device is in active use by a user, the device can return to block <NUM> to continue displaying the user interface and/or continue other operations of the device. Similarly, if the device is idle but does not have an active network connection (Block <NUM> - No), the device can return to block <NUM> to continue displaying the user interface and/or continue other operations of the device. In some situations, if the device is idle, the device may enter a low-power state and/or temporarily cease displaying the user interface, but may remain ready to resume displaying the user interface when the device is next in active use.

However, if the device is idle and has an active network connection (Block <NUM> - Yes), the device can query the content file repository <NUM> via the network <NUM> at block <NUM> to determine whether a new relevant content file <NUM> is available at the content file repository <NUM>. A relevant content file can be a replacement for a content file that is already stored in memory <NUM> of the device, or a content file associated with a language or other type of content that is likely to be used by the device to present a user interface.

For example, the device can query the content file repository <NUM> to determine if the content file repository <NUM> has a newer version of a content file that is currently stored in memory of the device. For instance, if the memory <NUM> stores a first version of an English-language content file, the device can determine at block <NUM> whether a newer version of the English-language content file is available at the content file repository <NUM>.

As another example, the device can query the content file repository <NUM> to determine if another content file that is relevant to the device is available at the content file repository <NUM>. For instance, if the memory <NUM> of the device stores an English-language content file, but location information, user settings, or other data indicates that the device is located in an area where a different language is predominantly spoken, the device can query the content file repository <NUM> to determine whether a content file associated with that different language is available. As a non-limiting example, the device may determine or estimate a location of the device based on GPS coordinates, an IP address assigned to the device, device registration data, and/or other data. The device may use that location information to determine a language that corresponds to the location of the device, or provide the location information to the content file repository <NUM>, such that the device can determine whether the content file repository <NUM> stores a content file associated with the language that corresponds to the location of the device.

If a new relevant content file is not available at the content file repository <NUM> (Block <NUM> - No), the software <NUM> of the device can continue using one or more content files <NUM> already stored in the memory <NUM> of the device to present the user interface at block <NUM>. At later points in time, the device may automatically perform checks for new relevant content files <NUM> at the content file repository <NUM>, for instance at later times when the device is again idle and has a network connection.

If a new relevant content file is available at the content file repository <NUM> (Block <NUM> - Yes), the device can download the new relevant content file to memory <NUM> at block <NUM>. The software <NUM> of the device can use the content file downloaded at block <NUM> to present the user interface at block <NUM>, for instance by changing and/or determining content displayed in association with one or more user interface elements based on corresponding content values indicated in the newly downloaded content file. The software <NUM> itself can continue to execute without modification, but can use the newly downloaded content file to determine content values to present in association with user interface elements. For example, the software <NUM> can directly use the content file newly downloaded at block <NUM> to determine content values to present in association with corresponding user interface elements, without the software <NUM> itself being reloaded or upgraded, and without the device being restarted. At later points in time, the device may again automatically perform a check for additional new relevant content files <NUM> at the content file repository <NUM>, for instance at later times when the device is again idle and has a network connection.

<FIG> shows an example system architecture <NUM> for a computing device <NUM> associated with the systems and methods described herein. The computing device <NUM> can be a server, computer, or other type of computing device that executes one or more portions of the systems and methods described herein. In some examples, the computing device <NUM> can be a server or other computing device that stores and/or implements the content file repository <NUM>. In other examples, the computing device <NUM> can be an example of one of the devices <NUM> that can receive content files <NUM> from the content file repository <NUM> and can use the content files <NUM> to present user interfaces.

The computing device <NUM> can include memory <NUM>. In various examples, the memory <NUM> can include system memory, which may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. The memory <NUM> can further include non-transitory computer-readable media, such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. System memory, removable storage, and non-removable storage are all examples of non-transitory computer-readable media. Examples of non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium which can be used to store desired information and which can be accessed by the computing device <NUM>. Any such non-transitory computer-readable media may be part of the computing device <NUM>.

The memory <NUM> can store modules and data <NUM>. The modules and data <NUM> can include modules and/or data that can be utilized by the computing device <NUM> to perform or enable performing any action taken by the computing device <NUM>. Such modules and data can include a platform, operating system, and applications, and data utilized by the platform, operating system, and applications. For example, if the computing device <NUM> hosts the content file repository <NUM>, the modules and data <NUM> can include the content files <NUM>, modules and data for uploading new content files <NUM> to the content file repository <NUM>, modules and data that allow devices to query the content file repository <NUM> for relevant content files <NUM> and to download content files <NUM>, and/or other modules and data. As another example, if the computing device <NUM> is one of the devices <NUM>, the modules and data <NUM> can include one or more content files <NUM> stored by the device, the software <NUM> that implements functions of the device and/or that presents a user interface based on the content files <NUM>, modules and data for querying the content file repository <NUM> for new relevant content files <NUM> and/or to download or receive new relevant content files <NUM>, and/or other modules and data.

The computing device <NUM> can also have processor(s) <NUM>, communication interfaces <NUM>, a display <NUM>, output devices <NUM>, input devices <NUM>, and/or a drive unit <NUM> including a machine readable medium <NUM>.

In various examples, the processor(s) <NUM> can be a central processing unit (CPU), a graphics processing unit (GPU), both a CPU and a GPU, or any other type of processing unit. Each of the one or more processor(s) <NUM> may have numerous arithmetic logic units (ALUs) that perform arithmetic and logical operations, as well as one or more control units (CUs) that extract instructions and stored content from processor cache memory, and then executes these instructions by calling on the ALUs, as necessary, during program execution. The processor(s) <NUM> may also be responsible for executing computer applications stored in the memory <NUM>, which can be associated with types of volatile (RAM) and/or nonvolatile (ROM) memory.

The communication interfaces <NUM> can include transceivers, modems, interfaces, antennas, telephone connections, and/or other components that can transmit and/or receive data over networks, telephone lines, or other connections.

The display <NUM> can be a liquid crystal display, or any other type of display commonly used in computing devices. For example, a display <NUM> may be a touch-sensitive display screen, and can then also act as an input device or keypad, such as for providing a soft-key keyboard, navigation buttons, or any other type of input.

The output devices <NUM> can include any sort of output devices known in the art, such as a display <NUM>, speakers, a vibrating mechanism, and/or a tactile feedback mechanism. Output devices <NUM> can also include ports for one or more peripheral devices, such as headphones, peripheral speakers, and/or a peripheral display.

The input devices <NUM> can include any sort of input devices known in the art. For example, input devices <NUM> can include a microphone, a keyboard/keypad, and/or a touch-sensitive display, such as the touch-sensitive display screen described above. A keyboard/keypad can be a push button numeric dialing pad, a multi-key keyboard, or one or more other types of keys or buttons, and can also include a joystick-like controller, designated navigation buttons, or any other type of input mechanism.

The machine readable medium <NUM> can store one or more sets of instructions, such as software or firmware, that embodies any one or more of the methodologies or functions described herein. The instructions can also reside, completely or at least partially, within the memory <NUM>, processor(s) <NUM>, and/or communication interface(s) <NUM> during execution thereof by the computing device <NUM>. The memory <NUM> and the processor(s) <NUM> also can constitute machine readable media <NUM>.

Claim 1:
A method comprising:
presenting, via software (<NUM>) executing on a medical device (<NUM>) configured to perform patient monitoring operations, a user interface comprising a patient data element (<NUM>) and user interface elements (<NUM>, <NUM>, <NUM>, <NUM>) different from the patient data element (<NUM>), wherein:
the patient data element (<NUM>) presents patient data that is locally determined via the patient monitoring operations performed by the medical device (<NUM>);
the user interface elements (<NUM>, <NUM>, <NUM>, <NUM>) comprise at least one of: a button (<NUM>); a label; and a logo (<NUM>);
the software (<NUM>) associates individual user interface elements (<NUM>, <NUM>, <NUM>, <NUM>), of the user interface with corresponding content identifiers (<NUM>);
first content values (<NUM>), predefined in a default content file (<NUM>) stored in a memory (<NUM>) of the medical device (<NUM>), are displayed on the individual user interface elements (<NUM>, <NUM>, <NUM>, <NUM>); and
at a first time, the software (<NUM>) determines first content values (<NUM>) to display on the respective user interface elements (<NUM>, <NUM>, <NUM>, <NUM>), based on the default content file (110A) stored in the memory (<NUM>) of the medical device (<NUM>);
loading a second content file (110B) into the memory (<NUM>) of the medical device (<NUM>) during execution of the software (<NUM>), wherein the second content file (110B):
is provided by a content file repository (<NUM>) remote from the medical device (<NUM>), and
defines second content values (<NUM>) that correspond to the content identifiers (<NUM>) associated with the respective user interface elements (<NUM>, <NUM>, <NUM>, <NUM>); and
updating, via the software (<NUM>) executing by the medical device (<NUM>), the content values (<NUM>) displayed on the user interface elements (<NUM>, <NUM>, <NUM>, <NUM>) based at least in part on the second content values (<NUM>) defined by the second content file (110B),
wherein the content values (<NUM>) displayed on the respective user interface elements (<NUM>, <NUM>, <NUM>, <NUM>) are updated, based at least in part on the second content values (<NUM>) defined by the second content file (110B), without upgrading the software (<NUM>), restarting the software (<NUM>) on the medical device (<NUM>), or rebooting the medical device (<NUM>).