Accurate estimation of remaining battery charge in mobile carts

Abstract

Systems and methods for monitoring and managing electronic devices are discussed herein. An authentication request for access to an electronic secure compartment of an electronic device is received from a user. Authentication data is obtained from the user. An authentication request including a device identifier of the electronic secure compartment and the authentication data is sent to a cloud-based authentication service. Upon receiving an indication of an association between the user and the electronic secure compartment from a cloud-based service provider, access to the electronic secure compartment is provided.

Description

[0001] priority

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application Serial No. 63 / 034,467, filed on June 4, 2020, and U.S. Provisional Patent Application Serial No. 63 / 066,976, filed on August 18, 2020, the entire contents of which are incorporated herein by reference. Technical Field

[0003]

[0013] Embodiments described herein relate generally to functional monitoring of electronic devices and, in some embodiments, more specifically to electronic telemetry-based monitoring of electronic devices, including accurate estimation of remaining battery charge in a mobile cart. Background Art

[0004] Electronic devices such as computer carts, electronic cabinets, electronic tables, etc. may include various electronic components. The electronic components may have operating limits that may vary based on the use of the electronic device. It may be desirable to monitor the operating status and use of the electronic device to determine when the electronic components may need to be serviced. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the drawings, which are not necessarily drawn to scale, the same reference numerals may describe similar components in different views. Similar reference numerals with different letter suffixes may represent different instances of similar components. The drawings generally illustrate various embodiments discussed in this document by way of example and not by way of limitation.

[0006] Figure 1 is a block diagram of an example of an environment and system for electronic telemetry-based monitoring of electronic devices, according to an embodiment.

[0007] Figure 2 is a block diagram of data network entities for electronic telemetry-based monitoring of electronic devices, according to an embodiment.

[0008] Figure 3 is a block diagram of an example of a sensor network for electronic telemetry-based monitoring of electronic devices, according to an embodiment.

[0009] Figure 4 An example of a method for electronic telemetry-based monitoring of an electronic device according to an embodiment is shown.

[0010] Figure 5 An example of a system for associating a user with an electronic device according to an embodiment is shown.

[0011] Figure 6 An example of a system for accurate estimation of remaining battery charge in a mobile cart is shown, in accordance with an embodiment.

[0012] Fig. 7A is a flow diagram of an example of a process for access control of a mobile cart, according to an implementation.

[0013] Figure 7B is a flow diagram of an example of a process for binding an endpoint to a mobile cart, according to an implementation.

[0014] Figure 8 An example of a method for associating a user with an electronic device according to an embodiment is shown.

[0015] Fig. 9 An example of a method for electronic telemetry-based monitoring of an electronic device according to an embodiment is shown.

[0016] Fig.10 is a block diagram illustrating an example of a machine upon which one or more embodiments may be implemented. DETAILED DESCRIPTION

[0017] Data collected from sensors located on machines can be used to make decisions about the function of machines in a factory setting to increase production, decide when to replace a part due to a predicted failure, etc. With the revolution of the Internet of Things (IoT), the push for automation improvements using remote connections to sensors through the Internet is even greater. However, limiting this technology to machine-to-machine or machine-to-technician communication loses the potential of the Internet of Things. Using machine data to support future sales, enhance relationships with customers, improve products, and improve the customer experience with manufacturers and products through predictive maintenance based on the actual number of cycles or time until a part will fail can greatly reduce customer downtime because maintenance can be performed proactively according to the customer's schedule rather than after the part fails and the product no longer functions.

[0018] Along with these predictive indicators comes the benefit of using sensor data to determine if a component is over-designed or under-designed based on the actual use of the product by customers. If a component is too robust, the cost may be reduced, whereas, it may be necessary to increase costs to improve a component that fails prematurely, which will ultimately be cheaper than replacing a poorly designed part or a customer field return. However, without knowing the actual use and environment that the product may experience, everything the engineer develops will be guesswork. Through sensor data and data analytics, usage patterns and other analyses can be used to improve products, reduce costs, increase sales, and improve the customer experience from a contactless point of view. The customer does not have to do anything to provide the data that the designer needs - it can all be handled automatically. Moreover, with the improvements made in engineering, sales, and customer experience, the value of the product is now many times more than the data benefits of the product itself alone. The present disclosure describes technologies for implementing sensor-based customer enhanced experiences.

[0019] According to various techniques of the present disclosure, one or more sensors may be placed in or around a product. By way of specific, non-limiting example, a product may be a medical cart for electronic medical record (EMR) data entry or medication delivery (e.g., aspirin or other non-narcotic medications). Sensors may be used to monitor the temperature of a room, the air pressure of a room, the voltage of the cart's onboard battery, the current supplying power to an onboard inverter that provides 50 or 60-Hz 120 or 230-VAC to a user's computer and monitor attached to the cart.

[0020] In some example implementations, the charge and discharge cycles of a battery may be counted so that the state of health (SoH) of the battery may be determined. For example, a typical lithium iron phosphate (lifetime) battery chemistry may have approximately 1800 available charge / discharge cycles before the battery may need to be replaced. As another example, if the room is dark, it may not be desirable for bright lights on the cart's display or floor to disturb a sleeping patient. In accordance with the present disclosure, sensors that interact with the room (e.g., light sensors) may control the lighting on the cart's display or external cart floor lighting based on the ambient lighting of the room. Similarly, the floor lighting may be dimmed appropriately. These are just a few examples of the number and types of sensors that may be used to provide what may be valuable customer insights into the use of a product as well as other benefits that are not directly related to the basic use of the product, such as a medical record / medication delivery cart.

[0021] Next, the data can be transmitted from the sensor to a database for collection. In some example implementations, Wi-Fi may be a suitable transmission method for hospitals, businesses, and homes. Message Queuing Telemetry Transport (MQTT) is a method of organizing data into small packets for transmission on low-power devices that rely on battery power, and is well suited for machine-to-machine information exchange. Using MQTT and a publish-subscribe model can keep network and power overhead to a minimum.

[0022] For example, devices that only need to hear what is going on will get the message, and devices will only send their information when they need to. For example, a Wi-Fi transmitter in a cart might only power up and send information when something changes (voltage, current, battery cycle, etc.), eliminating the old method of polling the device for information. This means that the device (in this case, the cart) is always listening for requests to send information to the server. In a publish-subscribe model, the cart might wake up its Wi-Fi transmitter when something needs to be said, and then go back to sleep. Those things that need to hear what is going on are always listening and are not limited by power or bandwidth, and can then act accordingly when information is received.

[0023] Once the information is received, the data can be stored, acted upon, discarded, or whatever is needed for the given sensor information. For example, in one implementation, a battery charge / discharge cycle count may approach the maximum number of charge and discharge cycles for a battery chemistry before the battery will need to be replaced. The sensor count information may be published, and the data may then be saved to a database in the "cloud" (e.g., Amazon Web Services (AWS), Microsoft Azure, etc.). An application connected to a company's customer relationship manager (CRM) software (e.g., Salesforce) makes decisions based on the data about what should happen.

[0024] For example, in the event that a battery charge / discharge cycle count approaches its limit of 1800 cycles, the cycle count sensor information may be sent to the cloud system and then to the CRM system. The CRM system may be triggered to automatically send a message to the hospital customer that the battery on cart number A123456 needs to be replaced within the next 7 days and has been ordered to be installed at 2:00 PM on Thursday. If this time is not convenient, please reply with an alternate date and time. At the same time, the service provider may be notified by the CRM system what work needs to be performed, a map to the hospital, the location of the cart, and the tracking number of the battery that was automatically ordered by the CRM system in dialogue with the Enterprise Resource Planning (ERP) system, and that the part is on the way.

[0025] After the battery is replaced, a sensor on the cart might let the CRM system know that everything is OK. An invoice or warranty paperwork might be generated, as well as a thank you note to the customer letting them know that everything is OK. All of this happens with the downtime predicted to the customer, and without the potential upset of a customer calling in saying their cart is broken, and then having customer service guess what might be wrong with the cart, and then talking to customer and technical support or even an engineer about what happened to help resolve the issue. By adding sensors, databases, connecting the databases to the CRM and ERP systems, and through the internet, a powerful customer experience is created.

[0026] Ultimately, the benefits of this customer contactless experience are a great customer experience, increased technical capabilities regarding product improvements based on real data, and ultimately reduced costs for design and manufacturing organizations throughout the product life cycle. Other benefits that are not directly related to the product, but can certainly be achieved, are the use of sensor data for non-cart-informed decisions. For example, nurse workflow improvement studies conducted by hospital managers based on sensors on carts can be implemented. Sensors that indicate motion and non-motion, work surface location, room lighting, and others can be used to indicate nurses' work habits on an overall scale across the organization or down to the individual. These are just two simple examples of what can be done with sensor data to improve usefulness and customer satisfaction.

[0027] Figure 1 1 is a block diagram of an example of an environment 100 and system 130 for accurately estimating remaining battery charge in a mobile cart according to an embodiment. The environment 100 may include an electronic device 105 (e.g., an electronic computer cart, an electronic storage cabinet, an electronic table, etc.) that includes various sensors 115 (e.g., an ambient light sensor, an air quality sensor, a radioactivity sensor, a radiation sensor, an illumination sensor, a magnetic field sensor, a sit-to-stand work surface height sensor, a height adjustment cycle sensor, a vibration sensor, an inertial sensor, a power on / off state sensor, a voltage sensor, a temperature sensor, a current sensor, a battery cycle sensor, a drawer state sensor, a contact sensor, a barometric pressure sensor, a fault state sensor, a wireless networked operation sensor, an odometer, a decibel meter, an oxygen sensor, a motion sensor, a pressure sensor, an ultrasonic sensor, etc.) configured in a sensor array that is communicatively coupled (e.g., via a sensor network, a wired connection, a wired network, a wireless network, a shortwave radio, a near field communication, etc.) to a sensor controller 110. Figure 3 A more detailed example of a sensor controller is shown.The electronic device may operate in a variety of locations such as, for example, a medical treatment facility.

[0028] The sensor controller 110 may collect sensor data from the sensors and may transmit the sensor data to a cloud computing platform via a network 120 (e.g., the Internet, a cellular network, a wired network, a wireless network, etc.). The sensor data may be received by a network management server 125 (e.g., a single server, a server cluster, a system on a chip (SoC), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a cloud computing platform service, etc.) via the network 120. In an example, the network management server 120 may operate within a cloud computing platform, and the cloud computing platform may facilitate the transmission of the sensor data directly to the network management server 125 via the network 120.

[0029] The network management server 125 may be communicatively coupled (e.g., via a wired network, a wireless network, a shared bus, etc.) to the system 130. In an example, the system 130 may be a telemetry-based device monitoring engine. The system 130 may include various components, such as an input / output controller 135, an operating state detector 140, a comparator 145, an instruction set generator 145, a data communication router 155, and a database 160. The components of the system 130 may be implemented in a single computing device (e.g., a server, an FPGA, an ASIC, a SOC, a virtual server, etc.), or may be distributed across multiple computing devices (e.g., a server cluster, a cloud computing platform, a virtual server cluster, etc.).

[0030] The input / output controller 135 may obtain a sensor data set from a sensor array included in the electronic device 105. In an example, the sensor data set may be collected from the sensor array by the sensor controller 110 of the electronic device 105. The electronic device 105 may then transmit the sensor data set to a cloud service platform of a cloud computing platform. The input / output controller 135 may obtain the sensor data set from the cloud service platform. The input / output controller 135 may process (e.g., format, standardize, translate, etc.) the sensor data to be used as input by other components in the system 130.

[0031] By way of example and not limitation, the sensor data set may include sensors read from: ambient light sensors, air quality sensors, radioactivity sensors, radiation sensors, lighting sensors, magnetic field sensors, sit-to-work surface height sensors, height adjustment cycle sensors, vibration sensors, inertial sensors, power on / off status sensors, voltage sensors, temperature sensors, current sensors, battery cycle sensors, drawer status sensors, contact sensors, atmospheric pressure sensors, fault status sensors, wireless networking operation sensors, odometers, decibel meters, oxygen sensors, motion sensors, pressure sensors, ultrasonic sensors, etc. In an example, a battery cycle sensor may observe the number of charge cycles that a battery in the electronic device 105 has completed. In another example, a voltage sensor may observe the voltage level of the input power and internal power of the electronic device 105. In another example, an ambient light sensor may observe the ambient light of the environment in which the electronic device 105 operates. In another example, a height adjustment cycle sensor may observe the number of times a lift mechanism or corresponding motor is activated. The foregoing examples represent non-limiting examples of sensor data that may be included in the sensor data set. It will be readily appreciated that the sensor data set may include various sensor data in different combinations. The sensor data set may be stored in the database 160.

[0032] The operating state detector 140 can work in conjunction with the comparator 145 to determine the operating state of a component (e.g., a battery, a motor, a controller, a mechanism, an electronic part, etc.) of the electronic device 105 based on an evaluation of the sensor data set. In an example, the sensor array can include a cycle sensor for the component (e.g., a battery charge cycle sensor, a lift mechanism cycle sensor, etc.). The evaluation of the sensor data set can include comparing the number of cycles of the component observed by the cycle sensor with a cycle threshold for the component. When it is determined that the number of cycles is at least equal to the cycle threshold, the operating state of the component can be determined to be end-of-life (e.g., should be replaced, etc.). For example, a battery included in the electronic device 105 can have a rated duty cycle of 1800 charging cycles, and an observation from a battery cycle sensor in the electronic device 105 indicating that the battery has completed 1850 charging cycles can be compared with the rated duty cycle of 1800 cycles to determine that the battery is at or near end-of-life.

[0033] In an example, the operating state detector 140 can work in conjunction with the comparator 145 to predict future failures of a component based on an evaluation of the sensor data set. In an example, the evaluation can include a comparison of the sensor data set with a predicted failure model of the component. For example, the training data can be used to generate (e.g., train, etc.) a machine learning model or other predictive model to determine a sensor data set that can indicate a future failure of a component. The sensor data set can be provided as an input to a predictive model, which can then generate an input including the probability of failure of a component and a predicted time before such a failure may occur. The predictive model can be stored in a database 160.

[0034] The instruction set generator 150 may generate the instruction set based on the operating state of the component. The data communication router 155 may determine the recipient computing device to receive the instruction set based on the device identifier of the electronic device 105 and the task associated with the instruction set. The input / output controller 135 may send the instruction set to the recipient computing device. In an example, the input / output controller 135 may format or otherwise modify the output for transmission to a specific recipient computing device. For example, the instruction set may be translated into a script file, an executable file, etc. based on the input requirements of the recipient computing device.

[0035] In an example, the task may be part fulfillment, and the instruction set may include instructions to send an electronic order for a replacement part to a supplier of the part, and the recipient computing device may be an order processing computing system of the supplier. In another example, the task may be a part replacement instruction set, and the part replacement instruction set may include instructions to send an electronic service work order to a service provider of the electronic device 105 based on a device identifier of the electronic device 105, and the recipient computing device may be a work order processing system of the service provider.

[0036] In another example, the recipient device may be a portable device associated with the device identifier, and the set of instructions may include instructions to cause the portable device to display operating data of the electronic device 105, the operating data of the electronic device 105 including the operating status of the components. In another example, the recipient device may be a computing device associated with the owner of the electronic device 105 based on the device identifier, and the set of instructions may include instructions to cause the computing device associated with the owner to store operating data of the electronic device 105, the operating data of the electronic device 105 including the operating status of the components. In yet another example, the recipient device may be a customer relationship management computing device, and the set of instructions may include instructions to cause the customer relationship management computing device to store operating data of the electronic device 105 in a record associated with the owner of the electronic device 105 based on the device identifier, the operating data of the electronic device 105 including the operating status of the components.

[0037] Automatic remote detection of the operating status of the electronic device 105 and transmission of instructions can reduce downtime of the electronic device 105 by scheduling replacement parts, service, and parameter changes before actual part failure. This can be critical in a healthcare environment, as equipment downtime can jeopardize patient health and safety as well as the health and safety of medical professionals.

[0038] Figure 2 is a block diagram of a data network entity 200 for accurately estimating remaining battery charge in a mobile cart, according to an embodiment. Figure 1 As described in , the data network entity 200 can send and receive data (eg, sensor data, instructions, etc.).

[0039] The data network entity 200 may include an end-user system 205, a supplier system 210, a service provider system 215, etc. The end-user system may include various systems, including electronic devices (e.g., electronic device 105, etc.), end-user support systems, etc. The supplier system 210 may include various systems, including enterprise resource planning (ERP) systems, databases, customer relationship management (CRM) systems, department systems, etc. The end-user system 205, the supplier system 210, and the service provider system 215 may be communicatively coupled via a cloud service platform 220. In an example, the cloud service platform 220 may include a network management server (e.g., such as Figure 1 In another example, the network management server may be a member of the end user system 205, the supplier system 210, and / or the service provider system 215.

[0040] The electronic device may send (e.g., via a wireless network, a wired network, a cellular network, etc.) a sensor data set to the cloud service platform 220. The sensor data set may describe the operating state of one or more components of the electronic device. The sensor data set may be evaluated to determine whether one or more components are operating outside normal operating conditions, or whether there is an operating state indicating that remediation (e.g., component replacement, parameter adjustment, etc.) may be required. Based on the evaluation, instructions may be sent to one or more systems in the end-user system 205, the supplier system 210, and the service provider system 215. Instructions may be designed to mitigate any anomalies in the operating state of one or more components, either individually or in combination. In an example, instructions may cause a record of the operating state to be created in one or more systems in the end-user system 205, the supplier system 210, and the service provider system 215. These records may be accessed in the future when troubleshooting problems with one or more components, future research and development of one or more components, and analysis of operating trends of one or more components.

[0041] Figure 3 is a block diagram of an example of a sensor network 300 for accurately estimating remaining battery charge in a mobile cart, according to an embodiment. The sensor network 300 may provide Figure 1 and Figure 2 Features described in .

[0042] The sensor network 300 may include a sensor controller 305. The sensor controller 305 may include various components, including a processor 310 (e.g., Figure 5 , etc.), memory 315 (e.g., as described in Figure 5 , elements 504, 506, etc. described in, for example, Figure 5 ), onboard sensors 325 (e.g., embedded physical sensors, embedded logical sensors, etc.), and input / output controllers 330 (e.g., as Figure 5 Components 512, 528, etc. described in ).

[0043] The sensor network 300 may include a sensor array, which may include an onboard sensor 325, a first sensor 335, a second sensor 340, and an additional n sensors 345. The sensors may be communicatively coupled (e.g., via a wired network, a wireless network, a shared bus, a cellular network, a shortwave radio, etc.) to the sensor controller 305 via an input / output controller.

[0044] The memory 315 may include instructions for causing the processor 310 to collect sensor data (e.g., sensor readings, etc.) from the sensors of the sensor array, and may store the sensor data in the storage device 320. The network transceiver 350 may send the sensor data to the cloud service platform via the network 355. The network transceiver 350 may communicate with the network 355 via a wired network, a wireless network, a cellular network, a shortwave radio, etc. In an example, the network transceiver 350 may use MQTT and a publish-subscribe model to reduce network utilization and power consumption.

[0045] The network transceiver 350 can receive instructions from a cloud service platform, which can be placed in the storage device 320 and the memory 315. When the instructions are executed, the instructions can cause the processor 310 to perform operations to adjust (e.g., via the input / output controller 330, etc.) operating parameters of the electronic device including the sensor controller 305. For example, ambient light sensor data can be sent to the cloud service platform, and instructions to adjust the lighting device of the electronic device can be received when a signal is received from an external device. For example, a signal can be received from a smart lighting switch in a hospital room, and when a signal indicating that the ambient lighting of the hospital room has been reduced is received, an instruction to reduce or turn off the floor lighting component of the electronic device can be triggered. In another example, the instructions can include a lighting schedule, and the power of the lighting component can be adjusted based on the lighting schedule.

[0046] Figure 4 An example of a method 400 for accurately estimating remaining battery charge in a mobile cart according to an embodiment is shown. The method 400 may provide Figures 1 to 3 Features described in .

[0047] The information can be obtained from a sensor array included in an electronic device via a cloud service platform (e.g., by Figure 1 405). In an example, the sensor array may include at least one sensor selected from the group consisting of: a power state sensor, a voltage sensor, a current sensor, a battery temperature sensor, an ambient temperature sensor, a battery capacity sensor, and a battery cycle sensor. In an example, the electronic device may be located in a medical treatment facility.

[0048] The evaluation of the sensor data set can be based on Figure 1 145, etc.) as described in the foregoing) to determine (for example, by Figure 1 The operating state of a component of the electronic device (e.g., at operation 410) may be determined by the operating state detector 140 described in the foregoing description. In an example, the sensor array may include a cycle sensor for the component, and the evaluation of the sensor data set used to determine the operating state of the component may include comparing the number of cycles of the component observed by the cycle sensor with a cycle threshold value of the component. When it is determined that the number of cycles is at least equal to the cycle threshold value, the operating state of the component may be determined to be end-of-life.

[0049] In an example, a future failure of a component may be predicted based on an evaluation of the sensor data set, and the evaluation may include a comparison of the sensor data set to a predictive failure model of the component. The set of instructions may include instructions for mitigating the future failure.

[0050] The component may be generated based on its operating state (e.g., by Figure 1 , instruction set generator 150, etc.) (e.g., at operation 415).

[0051] A recipient computing device may be determined (e.g., by a data communications router 155, etc.) to receive the set of instructions (e.g., at operation 420) based on a device identifier of the electronic device and a task associated with the set of instructions. In an example, the recipient device may be a portable device associated with the device identifier, and the set of instructions may include instructions to cause the portable device to display operating data of the electronic device, the operating data of the electronic device including operating states of components. In another example, the recipient device may be a computing device associated with an owner of the electronic device based on the device identifier, and the set of instructions may include instructions to cause the computing device associated with the owner to store operating data of the electronic device, the operating data of the electronic device including operating states of components. In yet another example, the recipient device may be a customer relationship management computing device, and the set of instructions may include instructions to cause the customer relationship management computing device to store operating data of the electronic device in a record associated with the owner of the electronic device based on the device identifier, the operating data of the electronic device including operating states of components.

[0052] The instruction set may be sent (e.g., via Figure 1 425). In an example, the set of instructions may include instructions to send an electronic order for a replacement part to a supplier of the part, and the recipient computing device may be an order processing computing system of the supplier. In another example, the set of instructions may include instructions to send an electronic service work order to a service provider of the electronic device based on a device identifier of the electronic device, and the recipient computing device may be a work order processing system of the service provider.

[0053] In an example, a fulfillment instruction set and a record creation instruction set may be generated based on an operational state of a component. An owner of the electronic device may be determined based on a device identifier of the electronic device. One or more fulfillment recipient computing devices that receive the instruction set may be determined based on the device identifier and a task associated with the instruction set. At least a subset of the fulfillment instruction set may be sent to one or more fulfillment recipient computing devices, and the record creation instruction set may be sent to an owner support computing device of the owner and a customer relationship management computing device of a supplier of the electronic device.

[0054] In an example, a sensor data set may be collected from a sensor array. The sensor data set may describe an operational state of a component of the mobile electronics cart device. The sensor data set may be sent to a cloud service platform via a transceiver. An instruction set may be received via a transceiver based on an evaluation of the sensor data set, and the instruction set may be used to adjust an operational parameter of the component. In an example, the instruction set may include instructions to adjust an operational parameter of the component based on a signal from a device external to the mobile electronics cart device. In an example, the sensor array may include an ambient light sensor, and the instruction set may include instructions to adjust a power level applied to a lighting component of the mobile electronics cart device based on a signal received from a device external to the mobile electronics cart device.

[0055] Figure 5 An example of a system 500 for associating a user with an electronic device according to an embodiment is shown. The problem to be solved is how to securely allow a user to access an appliance, whether fixed or mobile, such as a drawer on a medication delivery cart or similar structure using a single sign-on (SSO) method, where a badge reader used by the user is not connected to the drawer system, but to a thick client, thin client, or zero client. The user's application runs on the thick client, thin client, or zero client. The SSO authentication system can be a Security Access Markup Language (SAML) or similar federated authentication method that allows users to access applications on the thick client, thin client, or zero client.

[0056] Historically, access to a drawer system is accomplished by connecting a fat client to a drawer system running an application, and when authenticated, a user can select a drawer via an application on the fat client and through a connection such as a universal serial bus (USB), a command to open the drawer is sent to the drawer system connected to the fat client, and the transaction is completed. The problem to be solved is the case where a thin client or zero client runs a federated authentication service such as SAML, where the server may be located thousands of miles away from the thin client or zero client, and the drawer system is located on a cart where the thin client or zero client is located, but the thin client or zero client may or may not be the same thin client or zero client that was once associated with the drawer system but was moved to another cart or replaced for maintenance reasons. System 500 and corresponding methods associate a fat client, thin client, or zero client with a drawer system that physically resides on the same structure, such as a cart, where a user (e.g., a nurse) needs to open a drawer on the same cart, where the user's application is running on a fat client, thin client, or zero client that also physically resides on the same structure as the drawer system, such as a cart, where the user is in order to perform tasks associated with the application running on the fat client, thin client, or zero client and the drawer system.

[0057] The system 500 and corresponding method may have several elements, including:

[0058] 1) Drawer systems or other appliances that are not directly controlled by an application running on a thick client, thin client, or zero client.

[0059] 2) A user using personally identifiable information stored on an access card (RFID), facial recognition, fingerprint recognition, or any other identification method of the user connected to a fat client, thin client, or zero client near the drawer system or appliance. A federated authentication method, such as SAML, that utilizes the personal identification method of 2 running on a fat client, thin client, or zero client near the drawer system or appliance.

[0060] 3) A cloud-based database that stores user information related to access to drawers or appliances.

[0061] 4) A cloud-based database that stores a unique identification of the cart or structure, such as a serial number or other unique number associated with the cart or structure. The cart or structure is connected to the cloud via Wi-Fi, Ethernet or other communication methods.

[0062] 5) A cloud based database with associations of users and unique cart or structure identifiers with drawers or appliances attached. For one user, the database association could be many carts or structures. Or there could be many users associated with one cart or structure associated with a drawer system or appliance. Or there could be many users associated with many carts or structures associated with attached drawers or appliances.

[0063] 6) A connection between a fat client, thin client, or zero client and a cart or structure, where the connection is a physical connection via USB or other communication method. This connection provides an authentication signal to the cart or structure, but another confirmation is required to ensure that the fat client, thin client, or zero client is physically close to the user and the drawer or appliance.

[0064] 7) A connection from a cloud based database that associates a specific user with the unique ID of the cart or structure and drawer system or appliance to which it is attached. Note that manual prompting for the unique ID of the cart drawer system and the unique ID of the thick, thin or zero client is not desirable due to data entry errors, spoofing or accidental duplication during application launch. The automatic ID method is desirable to be hidden from the user and those attempting to spoof the system.

[0065] like Figure 5As shown, when a user uses a badge or other biometric identification and indicates that it is desired to access a drawer or appliance, the user is authenticated on a fat client, thin client or zero client using SAML or a similar method, and if authenticated, an authentication message is sent to a cart or structure containing a drawer system via a USB or a similar direct connection between the fat client, thin client or zero client. Because the fat client, thin client or zero client may have been moved to another cart or structure, a way to ensure that the drawer system or appliance to which the user is allowed to access is maintained. For example, if initially approved for drawer system A, and the fat client, thin client or zero client is moved to a cart or structure B with a different drawer system or appliance that the user is not authorized to access, the opening process must be stopped and access is denied. This is achieved through an independent communication channel from a cloud-based database that associates the user with a drawer system unique ID of a cart or structure based on the cloud.

[0066] During the access request and subsequent authentication, the application running on the fat client, thin client or zero client sends the SAML information about the user to the cart or structure. The cart then sends the user-cart unique ID pair to the cloud-based user-cart association database. This is done securely. If the user-cart credential matches what is in the database, a message is returned to the cart that the user, cart and drawers attached to the cart are all in the same physical location and access to the drawer can be completed by the user selecting the desired drawer to be unlocked. If the user-cart pair credential does not match what is associated as indicated in the database, a message is returned to the cart that the association between the cart-drawer system associated with the fat client, thin client or zero client does not match, indicating that the drawer is not physically attached to the user's fat client, thin client or zero client or the user is not nearby, and drawer access is denied.

[0067] This ensures that there is always a physical association with the user, the fat client, thin client, or thick client that the user is logged into, and the cart drawer system that is physically attached to the user's fat client, thin client, or thick client.

[0068] Figure 6 An example of a system 600 for accurately estimating remaining battery charge time in a mobile cart is shown in accordance with an embodiment. The problem to be solved is to display an accurate representation of the remaining time of battery charge in a near instantaneous time frame to a user of a power system that provides alternating current (AC) or direct current (DC) power to a user device, such as a computer, monitor, or other peripheral device, where the actual load seen by the power source (e.g., a battery located on a mobile cart) is unknown.

[0069] There are a number of methods for determining the remaining battery charge time, such as monitoring the current drawn from the power system to the load over a period of time, and calculating the remaining charge time for the battery. The problem is that the loads may vary instantaneously, or not change at all, or not exist for a period of time. The remaining charge time for the battery may vary greatly because of these load variations to the point where the user has no confidence in the information, and therefore may unnecessarily leave the device connected to a charging source, or, in the case of replaceable batteries, may replace the battery prematurely, causing the user to do more work to keep what should be a relatively low-touch task of maintaining the battery level of the device from being an overly complex and time-consuming task. Conversely, the user may leave the battery connected for too long and run out of charge during the critical time when the device is needed.

[0070] System 600 and corresponding methods use the power of big data so that load information on a collection of devices that share similar use cases is used to seed the expected load of the device so that at the initial turn-on of the device, there is a highly likely load estimate in the device power system memory, which is used to calculate the battery remaining charge time. Shortly after power-up, the information seeded to the device power system by the cloud is updated with near real-time load information so that the battery remaining charge time is accurate without the need for aggregate information from the population of similar devices in the cloud. The load of this individual device is then stored in the cloud in a time series to be included with other similar devices to provide future startup information on subsequent power-ups until the device can calculate its own remaining charge time in near real-time. The benefit to the user is an almost instantaneous actual indication of the remaining time on the battery charge, without having to wait 10 seconds to 30 seconds or more, compared to other systems currently in use.

[0071] like Figure 6 As shown, to address the problem that when a device is first used there is no aggregate information about the load of all devices collected over a period of time, the devices are seeded from the factory with an estimated load profile based on the expected use case of a typical system of devices typically seen by consumers loaded with these types of products. Then, as the device becomes more prolific in the population of devices, the aggregate load data of similar devices is seeded into the power system so that at the next power-up the remaining battery charge time is displayed based on the aggregate data until the actual remaining battery charge time can be calculated and displayed, and the cycle repeats. The idea is that as the population increases and a large amount of load data is collected, the accuracy increases to the point of seeding, which represents near real-time information with a high probability of accuracy.

[0072] Fig. 7A is a flow diagram of an example of a process 700 for access control of a mobile cart, according to an implementation. Figure 7B700 and 705 may provide examples of processes 705 for binding an endpoint to a mobile cart according to an embodiment. Figures 1 to 6 Features described in .

[0073] At operation 702, a user may wish to access a drawer on a mobile cart. At operation 704, the user presses a drawer access button on a cart control unit (CCU) graphical user interface (GUI). At operation 706, a service or daemon polls the CCU universal serial bus (USB) connector for an action response and receives an unlock request. At decision 708, a determination is made as to whether an active user session exists. If not, at operation 710, a warning message is displayed on the endpoint (e.g., on the mobile cart via the GUI) requesting a user login, and the process continues to operation 702.

[0074] If it is determined at operation 708 that there is an active user session, then at operation 712 the user is authenticated using a user identifier (ID). At decision 714, it is determined whether the user has been authenticated. If not, then at operation 716, drawer access is denied. If it is determined at decision 714 that the user is authenticated, then at decision 718, it is determined whether the user and the endpoint are in the same security group. If not, then at operation 716, drawer access is denied. If it is determined at decision 718 that the user and the endpoint are in the same security group, then at operation 720, the proxy passes the endpoint name, user name, and authentication method to the CCU, and the process continues at 722 to the binding process (e.g., as shown in FIG. 1 ). Figure 7B described in ).

[0075] Steering Figure 7B, the agent passes the endpoint name, user name, and authentication method to the CCU from operations 720 to 722. For example, the computer name of the nurse user of the cart to be bound to the computer can be stored in the cart CCU electrically erasable programmable read-only memory (EEPROM). The CCU will use this to verify that the cart has been bound to the computer and that the logged-in user (e.g., nurse user, etc.) has been authorized to access the drawer on the cart. At decision 738, it is determined by the CCU whether any endpoints are bound to the cart. If not, then at operation 740, the endpoint is bound to the CCU. This mechanism binds the computer to a different (e.g., unbound, new, etc.) cart. For example, when the agent (e.g., nurse's computer, etc.) sends the computer name to the CCU for the first time, the CCU will store the name in the EEPROM only if the EEPROM is empty. If it is determined at decision 738 that the endpoint is bound to the cart, then at decision 742, it is determined whether the current endpoint is bound to the cart. If not, at decision 746 it is determined whether the user is an administrator and is allowed to rebind the cart. If not, processing continues back to 724 and access to the drawer is denied at operation 716 as described in Figure 716. If at decision 746 it is determined that rebinding is allowed, then at operation 748 the endpoint is bound to the CCU. This mechanism allows a user to rebind a computer to a cart. For example, when an administrator user enters with a badge, the agent sends a command to the CCU to overwrite the current computer name into the EEPROM. If a normal user enters the CCU with a badge and the computer does not match, it will deny access to the drawer. If it is an administrator user, they can rebind and / or allow access. When it is determined at decision 742 that the endpoint is bound to the CCU, or is bound to the CCU at one of operations 740 or 748, at operation 744 the CCU calls the drawer access token and processing continues at 726 as described. Fig. 7A Process 700 described in .

[0076] Back to Fig. 7A Description, Figure 7B The binding process 705 described in 705 calls for a drawer access token at operation 744, which is received at 726. At operation 750, a token for drawer access is returned, and the CCU grants access to the drawer of the cart. At operation 728, if approved, the CCU sends a response to the agent to unlock the drawer. At operation 732, the user exits the CCU via the GUI, or the user's session expires. At operation 734, the agent sends a message to the CCU to lock the drawer of the cart. At operation 736, the endpoint returns to the exited or locked state. For subsequent drawer access requests, process 700 continues at operation 702.

[0077] Figure 8An example of a method 800 for associating a user with an electronic device according to an embodiment is shown. The method 800 may provide Figures 1 to 6 , Fig. 7A and Figure 7B Features described in .

[0078] At operation 805, an authentication request for accessing the electronic secure compartment of an electronic device is received from a user. In an example, the authentication request is received via a graphical user interface of a control unit included in the electronic device. At operation 810, authentication data is obtained from the user. At operation 815, an authentication request including a device identifier of the electronic secure compartment and authentication data is sent to a cloud-based authentication service. In an example, the authentication request includes an identifier of the user's computing device, a user name of the user, and an authentication method for the authentication request. At operation 820, after receiving an indication of the association between the user and the electronic secure compartment from a cloud-based service provider, access to the electronic secure compartment is provided. In an example, an access token is requested using the user's authentication data and an endpoint name, and after verifying the access token, access to the electronic secure compartment is provided. In another example, the indication of the association between the user and the electronic secure compartment includes an electronically stored record in the memory of the electronic device, which identifies that the electronic device is bound to the user's computing device.

[0079] In an example, it is determined that the electronic device is not bound to the user's computing device. The cloud-based service provider can verify that the user is authorized to bind the electronic device to the computing device. After verification, the electronic device is bound to the computing device, and after determining that the electronic device is bound to the computing device, access to the electronic secure compartment is provided.

[0080] In an example, the cloud-based service provider may determine that the session time for the user has expired and the electronic device is placed in a locked state, preventing access to the electronic secure compartment.

[0081] Fig. 9 An example of a method 900 for electronic telemetry-based monitoring of an electronic device according to an embodiment is shown. The method 900 may provide Figures 1 to 6 , Fig. 7A and Figure 7B Features described in .

[0082] At operation 905, a sensor data set is obtained from a sensor array included in an electronic device via a cloud service platform. At operation 910, a battery runtime status of a component of the electronic device is determined based on an evaluation of the sensor data set. At operation 915, an instruction set is generated based on the battery runtime status of the component. In an example, the instruction set modifies the power consumption of the electronic device. At operation 920, the instruction set is sent to a recipient computing device.

[0083] Newly installed devices may not have immediate sensor data available, so data from other devices can be used to establish an estimated runtime state for the electronic device. In an example, it is determined that the sensor data set cannot be used to determine the battery runtime state. Identify the configuration of the electronic device. Retrieve historical sensor data from a set of electronic devices connected to a cloud service platform based on the configuration, and calculate the battery runtime state of the electronic device using the historical sensor data. When the electronic device has collected enough sensor data, the runtime state can be recalculated. In an example, a second sensor data set can be obtained from a sensor array included in the electronic device, and the battery runtime state can be recalculated using the second sensor data set.

[0084] In an example, a charge time of the electronic device is calculated based on a battery runtime state and an electrical draw on a battery of the electronic device. The charge time can be output for display in a graphical user interface. In an example, the electrical draw is determined based on a load profile of the electronic device. In an example, a use case of the electronic device is determined. A group of peer electronic devices that share the use case connected via a cloud service platform are identified. Load data of the group of peer devices is evaluated to establish a load profile.

[0085] Fig.10 A block diagram of an example machine 1000 is shown, on which any one or more of the techniques (e.g., methods) discussed herein can be performed. In alternative embodiments, the machine 1000 can be operated as an independent device or can be connected (e.g., networked) to other machines. In a networked deployment, the machine 1000 can operate in a server-client network environment with the capabilities of a server machine, a client machine, or both. In an example, the machine 1000 can act as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 1000 can be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web application, a network router, a switch or a bridge, or any machine capable of (sequentially or otherwise) executing instructions specifying the actions to be taken by the machine. In addition, although only a single machine is shown, the term "machine" should also be considered to include any collection of machines that execute a set (or multiple sets) of instructions individually or jointly to execute any one or more of the methods such as cloud computing, software as a service (SaaS), and other computer cluster configurations discussed herein.

[0086] As described herein, examples may include logic or multiple components or mechanisms, or may be operated by logic or multiple components or mechanisms. A circuit set is a collection of circuits implemented in a tangible entity including hardware (e.g., simple circuits, gates, logic, etc.). Circuit set members may change over time and with potential hardware changes. A circuit set includes members that can perform specified operations individually or in combination when in operation. In an example, the hardware of a circuit set may be designed to perform specified operations (e.g., hardwired) invariably. In an example, the hardware of a circuit set may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) to encode instructions for specified operations, and the variably connected physical components include computer-readable media that are physically modified (e.g., magnetically, electrically, removably placed particles of constant mass, etc.). When connecting physical components, the potential electrical properties of the hardware composition are changed, such as being changed from an insulator to a conductor or from a conductor to an insulator. Instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create members of a circuit set in hardware via variable connections to perform parts of specified operations when in operation. Thus, when the apparatus is in operation, the computer-readable medium is communicatively coupled to other components of the circuit set members. In an example, any component of the physical component may be used in more than one member of more than one circuit set. For example, in operation, an execution unit may be used in a first circuit of a first circuit set at one point in time and reused by a second circuit in the first circuit set or by a third circuit in the second circuit set at a different time.

[0087] The machine (e.g., computer system) 1000 may include a hardware processor 1002 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 1004, and a static memory 1006, some or all of which may communicate with each other via an interconnect (e.g., a bus) 1008. The machine 1000 may also include a display unit 1010, an alphanumeric input device 1012 (e.g., a keyboard), and a user interface (UI) navigation device 1014 (e.g., a mouse). In an example, the display unit 1010, the input device 1012, and the UI navigation device 1014 may be a touch screen display. The machine 1000 may additionally include a storage device (e.g., a drive unit) 1016, a signal generating device 1018 (e.g., a speaker), a network interface device 1020, and one or more sensors 1021 such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The machine 1000 may include an output controller 1028, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0088] The storage device 1016 may include a machine-readable medium 1022 having stored thereon one or more sets of data structures or instructions 1024 (e.g., software) that implement or are used by any one or more of the techniques or functions described herein. The instructions 1024 may also reside, in whole or in part, within the main memory 1004, within the static memory 1006, or within the hardware processor 1002 during execution of the instructions by the machine 1000. In an example, one or any combination of the hardware processor 1002, the main memory 1004, the static memory 1006, or the storage device 1016 may constitute a machine-readable medium.

[0089] Although the machine-readable medium 1022 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (eg, a centralized or distributed database, and / or associated caches and servers) configured to store one or more instructions 1024 .

[0090] The term "machine-readable medium" may include any medium capable of storing, encoding, or carrying instructions for execution by the machine 1000 and causing the machine 1000 to perform any one or more of the techniques of the present disclosure, or capable of storing, encoding, or carrying data structures used by such instructions or data structures associated with such instructions. Non-limiting machine-readable medium examples may include solid-state memory and optical and magnetic media. In an example, a machine-readable medium may exclude transient propagation signals (e.g., non-transitory machine-readable media). Specific examples of non-transitory machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0091] The instructions 1024 may also be sent or received over the communication network 1026 using a transmission medium via the network interface device 1020 using any of a number of transmission protocols (e.g., frame relay, Internet Protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), a mobile telephone network (e.g., a cellular network), a plain old telephone (POTS) network, and a wireless data network (e.g., a wireless network known as a wireless network). The Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards, known as The IEEE 802.16 family of standards for 4G and 5G wireless communications, the IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, the 3rd Generation Partnership Project (3GPP) standards for 4G and 5G wireless communications, including: the 3GPP Long Term Evolution (LTE) family of standards, the 3GPP LTE Advanced family of standards, the 3GPP LTE Advanced Professional family of standards, the 3GPP New Radio (NR) family of standards, etc. In an example, the network interface device 1020 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communication network 1026. In an example, the network interface device 1020 may include multiple antennas to communicate wirelessly using at least one of single-input multiple-output (SIMO) technology, multiple-input multiple-output (MIMO) technology, or multiple-input single-output (MISO) technology. The term "transmission medium" should be taken to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the machine 1000, and includes digital or analog communication signals or other intangible media to facilitate the communication of such software.

Claims

1. A system for monitoring an electronic device including a sensor array mounted at a location, comprising: at least one processor; and a memory including instructions that, when executed by the at least one processor, cause the at least one processor to perform operations to: obtaining a sensor data set from the sensor array included in the electronic device via a cloud service platform; determining a battery runtime status of a component of the electronic device based on an evaluation of the sensor data set; determining a use case for the electronic device; identifying a set of peer electronic devices connected via the cloud service platform that share the use case; evaluating load data of the set of peer electronic devices to establish a load profile such that load information on the set of peer electronic devices sharing the use case is used for an expected load on the electronic device such that upon initial power-on of the electronic device, the expected load is used to calculate a remaining battery charge time; generating an instruction set based on a battery runtime status of the component and the load profile; and The instruction set is sent to the electronic device.

2. The system according to claim 1, wherein: The set of instructions modifies power consumption of the electronic device.

3. The system of claim 1 , wherein the memory further comprises instructions that, when executed by the at least one processor, cause the at least one processor to perform operations to: determining that the sensor data set cannot be used to determine a battery runtime state; identifying a configuration of the electronic device; Based on the configuration, retrieving historical sensor data from a set of electronic devices connected to the cloud service platform; as well as The battery runtime status of the electronic device is calculated using the historical sensor data.

4. The system of claim 3, wherein the memory further comprises instructions that, when executed by the at least one processor, cause the at least one processor to perform operations to: obtaining a second sensor data set from the sensor array included in the electronic device; and The battery runtime state is recalculated using the second sensor data set.

5. The system of claim 1 , wherein the memory further comprises instructions that, when executed by the at least one processor, cause the at least one processor to perform operations to: calculating a charge time for the electronic device based on the battery runtime status and an electrical draw on a battery of the electronic device calculated using a load profile for the electronic device; and The charging time is output for display in a graphical user interface.

6. A method for monitoring an electronic device including a sensor array mounted at a location, comprising: obtaining a sensor data set from the sensor array included in the electronic device via a cloud service platform; determining a battery runtime status of a component of the electronic device based on an evaluation of the sensor data set; determining a use case for the electronic device; identifying a set of peer electronic devices connected via the cloud service platform that share the use case; evaluating load data of the set of peer electronic devices to establish a load profile such that load information on the set of peer electronic devices sharing the use case is used for an expected load on the electronic device such that upon initial power-on of the electronic device, the expected load is used to calculate a remaining battery charge time; generating an instruction set based on a battery runtime status of the component and the load profile; and The instruction set is sent to the electronic device.

7. The method according to claim 6, wherein: The set of instructions modifies power consumption of the electronic device.

8. The method according to claim 6, further comprising: determining that the sensor data set cannot be used to determine a battery runtime state; identifying a configuration of the electronic device; Based on the configuration, retrieving historical sensor data from a set of electronic devices connected to the cloud service platform; as well as The battery runtime status of the electronic device is calculated using the historical sensor data.

9. The method according to claim 8, further comprising: obtaining a second sensor data set from the sensor array included in the electronic device; as well as The battery runtime state is recalculated using the second sensor data set.

10. The method according to claim 6, further comprising: calculating a charge time for the electronic device based on the battery runtime status and an electrical draw on a battery of the electronic device calculated using a load profile for the electronic device; as well as The charging time is output for display in a graphical user interface.

Images