ACCESS CONTROL FOR A HARD ASSET

Abstract

A system and method for granting access to the hard asset. The method can include capturing biometric information associated with a first soft asset. The method can include receiving location information in view of the location of the first soft asset relative to the hard asset. The method can include granting, by the processor to the first soft asset, access to the hard asset when the biometric information and the location information are valid

Description

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application No. 62/146,084, filed Apr. 10, 2015, the entire contents of which are incorporated by reference.

BACKGROUND

As a company grows, a number of assets a company manages may increase. For example, with growth the company may increase its inventory, personnel, tools, vehicles, buildings, real estate, equipment, and so forth. Additionally, as a number of personal devices such as computers, cellphones, tablets, and so forth used by employees, contractors, and customers continue to increase, management of assets used and/or owned by a company may become increasingly difficult to track. A company may use asset-tracking systems (ATS) or, in a medical setting, a medical management system (MMS), to keep track of their assets. Where those assets include computing devices that provide access to confidential and/or sensitive data (such as available within a medical management system), authenticated access to the assets becomes a desired feature, in addition to tracking locations of the assets.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure in which like components may be labeled with corresponding numbering; and, wherein:

FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) according to various examples.

FIG. 2 is a diagram of an authentication system to authenticate access to the MMS of FIG. 1 according to one example.

FIG. 3 is a flowchart of an exemplary method for validating credentials through the authentication system according to one example.

FIG. 4 is a flowchart of an exemplary method for creating of a biometric for use in the authentication system according to one example.

FIG. 5 is a flowchart of an exemplary method for updating a biometric being used in the authentication system according to one example.

FIG. 6 is a flowchart of an exemplary method for deleting a biometric being used in the authentication system according to one example.

FIG. 7 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system according to one example.

FIG. 8 is a flowchart of an exemplary method for validating a biometric captured for use in the authentication system, according to another example.

FIG. 9 is a flowchart of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one example.

FIG. 10 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to one example.

FIG. 11 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to another example.

FIG. 12 is a flowchart of an exemplary method for authenticating a medical staff member for access to the MMS according to another example.

FIG. 13 is a flowchart of an exemplary method for authenticating an operator of a medical cart for access to the MMS according to one example.

FIG. 14 is a flowchart of an exemplary method for authenticating a first soft asset for access to an application according to one example.

FIG. 15 illustrates a block diagram of one implementation of a computer system.

Reference will now be made to the exemplary examples illustrated, and specific language will be used herein to describe the same. It will be understood that no limitation of the scope of the disclosure is thereby intended.

DETAILED DESCRIPTION

Assets of all kinds may be tracked and may be secured by providing selective access to authorized individuals through authentication of those individuals. The authentication may include second factor authentication, which may be required before an individual gains access to confidential or sensitive information available through a database accessible through the asset. The individuals may be an employee of any organization, military personnel in a military enterprise setting, government workers at any level in government, and medical personnel in a medical facility setting, or the like. When the term “asset” is referred to herein, it may be with relation to an asset accessible by any of these types of employees or personnel that may have access to confidential or sensitive information through different kinds of assets, such as mobile devices, computers, work stations and the like. For clarity and simplified explanation, the present disclosure is primarily described with reference to medical assets in a medical setting.

A medical asset may include equipment such as a medical cart, ventilators, an IV pole, a tablet computer, a battery pack, all in one (AIO) personal computer, and so forth. A military asset may include a mobile or stationary computer, a radio system, a workstation and a weapons system and the like. A government asset may include a mobile or stationary computer, a workstation, an authentication pad and the like. Because some assets involve computing devices (such as a medical cart, a tablet or personal computer), these assets may provide access to confidential or sensitive patient information records in a medical setting, a military setting, a government setting and in a business setting. Securing access to the assets becomes a challenge when the assets may be distributed throughout a medical facility such as a hospital, nursing home or medical clinic (or a military or government facility) and are generally difficult to keep under constant observation.

Accordingly, the asset may function in conjunction with a server or remote computing device to authenticate access of a medical staff member (MSM) (or other user) to an asset and to a medical server or database that stores patient or medical information. The MSM may be a physician, a physician's assistant, a nurse, a medical technician, or a specimen collector, for example. In one example, the medical asset may validate the identification of the MSM for access to the medical database through one or more authentication methods.

In another example, other users may be military or government personnel such as, for example, officers of certain rank, soldiers, sailors, airmen or marines of certain rank, and government employees of certain general schedule (GS) rank. Additionally, or alternatively, personnel may be categorized by position. For example, in the military, personnel may be assigned to positions such as S1, personnel staff, commander, captain, executive officer (XO), S2, S3, S4, S6 and other command or staff members. In the government, personnel may similarly be assigned to a position, which could be a position of leadership, management, committee head or chair, and the like. These personnel may be authenticated through a computing system integrated within an asset or as a standalone workstation or the like for access to personnel records, or mission or planning documents, and/or to other confidential, sensitive records or information that may carry varying levels of security levels for authorized access. Accordingly, the “MSM” referred to herein may also be understood to refer to military or government personnel or other business or organization personnel as would be apparent to one of ordinary skill in the art having the benefit of this disclosure.

The asset may layer together several authentication methods to strengthen the accuracy and security of the authentication to access the hardware of the asset and/or a database application or program. This layering may be to require second factor authentication to include, but not be limited to, any combination of: a biometric, username, password, personal identification code (PIN) number, use of a rotation security code such as an RSA token, a swipe card or key fob, a secret shape, a gesture, and location information correlation of a medical staff member (MSM) or other user, a patient or other third party, and/or the asset. The biometric may include facial recognition, fingerprint recognition, iris recognition, palm print recognition, and so forth.

In one example, an asset includes a processing device and hardware with which to capture a biometric. The asset, with optional input from a remote server, may authenticate an identity of a MSM with biometric recognition upon the MSM attempting to access the medical database via the asset. The asset may also receive a first location of the MSM from a real-time location system (RTLS) and retrieve a second location of a patient from the RTLS. The asset may further correlate the first location and the second location as being co-located, e.g., within a threshold distance of each other or in a same room or designated location. Based on a combination of the biometric authentication and the location correlation of the MSM and the patient, the asset may grant access, by the MSM, to identified data records of the patient within the medical database according to a security access level authorized to the MSM. Alternatively, or additionally, the correlation may further include a location of the asset that correlates to the location of the MSM before access is granted, which may allow the MSM to access a patient's information even when not co-located with the patient.

In another example, the asset, with optional input from a remote server, may validate credentials received from a user through an input source to provide access to an authentication system used to authenticate access to a medical database server. Once past the credentials authentication, the asset may perform second factor authentication to increase security. In one example, the asset may capture a biometric of the user through a biometric capturing device as directed by the processing device. The asset may send the biometric captured of the user to an authentication server over a network in which is stored one or more biometrics for the user. The asset may then receive a validation from the authentication server authenticating the user based on the biometric meeting a threshold match with a stored biometric, and grant a level of access to records of the medical database server according to a security access level associated with the user.

FIG. 1 illustrates a communication flow of asset and management information in a medical management system (MMS) 100 according to various examples, in addition to aspects of a real-time location system (RTLS) that works with the MMS 100 for authentication as will be explained with reference to FIG. 2.

The communication flow may originate in a location such as a room 110, and may include beacon devices 102 and data sent from an asset 104 (e.g., a medical cart is shown). The asset 104 may be coupled with an asset tag device 105A or may include an asset tag manager 105B that runs on the asset 104 to determine a location of the asset 104. The data (including the location) may flow through a communication hub 106 (or other network device) and arrive at a server 108 (such as a medical database and/or an authentication server). In some examples, the data also, or alternatively, flows through a communications network 115, where the communications network 115 may include the communication hub 106. The data flow may also flow in the reverse direction from the server 108 and/or the communication hub 106 to the asset 104, e.g., in response to a request for medical information or records on a patient. The data may include asset and/or management data, medical information, patient information, authentication data, and other personal and security-related information and the like.

The MMS 100 may include one or more assets 104 as shown in FIG. 2. The beacon devices 102 may be fixed locations and may provide a location identifier (ID) for assets 104 to detect, such that the assets 104 may determine a current location, which the assets may transmit through the communication hub 106 to the server 108. The beacon device 102 may identify or be associated with any type of location, including a room, a hallway, a common or conference room, and/or a grid location.

The beacon device 102 may include a circuit board within a housing, the circuit board containing a processor (or discrete logic or controller or microcontroller), memory (potentially non-volatile and/or volatile memory), a battery (or other power source), and a transceiver primarily for transmitting. The beacon device 102 may be programmed to transmit a beacon signal containing data to identify the beacon device to other devices, such as to the asset tag device 105A or to the asset tag manager 105B running on a host machine of the asset 104.

In one example, the beacon device 102 may communicate with the asset tag device 105A and/or the asset tag manager 105B through a personal area network (PAN), such as, e.g., with Bluetooth® technology developed by the Bluetooth Special Interest Group (SIG). In another example, the PAN may be created with Bluetooth® low energy (BLE) technology (also developed by Bluetooth SIG) that may be used to track the assets 104. For example, a BLE-based beacon may be associated with an asset in the MMS 100 to communicate asset and/or management information of the asset.

In another example, the beacon device 102 may be an active or passive radio frequency identification (RFID) tag that transmits a unique RFID number. The RFID number or identifier may be correlated at the server 108 with a certain location such as may have been pre-programmed at the server 108 or within a distributed MMS 100. In this example, the asset tag device 105A and/or the asset tag manager 105B may be or include an interrogator that interrogates the RFID tag of the beacon device 102 to determine the RFID number or identifier of the beacon device 102. When the beacon device 102 is an active RFID tag, the asset tag device 105A and/or the asset tag manger 105B may receive the actively transmitted RFID number of identifier as transmitted by the beacon device 102.

The asset tag device 105A (e.g., a non-integrated asset tag device) may be implemented in hardware and include a circuit board within a housing, the circuit board containing a processor, memory (potentially non-volatile and/or volatile memory), a battery, and radio frequency (RF) circuitry. The RF circuitry may be a third-party integrated circuit, such as an RF module, e.g., a Bluetooth® chip, an RFID interrogator and/or receiver or the like. The asset tag device may be performed by processing logic comprising hardware, software, firmware or any combination thereof.

The asset tag manager 105B (e.g., an integrated asset tag device) may be a software program (including instructions) that may utilize a processor, memory, transceiver and the like of a host machine of the asset 104, such as the medical cart (all-in-one (AIO), any medical device in which the asset tag is integrated, or any device when used in non-medical applications.

The beacon device 102, and the located assets 104, may be tracked with a real-time location system (RTLS) that determines the location of whatever is tagged (or otherwise tracked by identifying a location of beacon devices 102 in proximity of the assets 104). The tracked entities may include an asset or equipment, a MSM and/or patient(s), for example. The communications hub 106 may be wired or wireless and may direct data between the assets and to (and from) the assets 104 and the server 108.

In one example, the beacon device may broadcast a location ID to any device located within the room 110. In this example, when the asset 104 receives the location ID from the beacon device 102, the asset 104 may determine its location. Alternatively, or additionally, the asset 104 may measure a received signal strength indication (RSSI) from the beacon device 102 to determine a location of the device within a radius or area for which the beacon device is designated.

For example, the asset 104 may use the received location ID from the beacon device 102 to determine that the asset 104 is located in an identified room. The asset 104 may also use the RSSI to determine a location of the asset 104 within the room, such as within a threshold of location accuracy (e.g., within X distance from the beacon device 102). In one example, a room may include multiple beacon devices 102. The asset 104 may receive multiple location IDs from the multiple beacon devices 102 and use the RSSI of the different location IDs to determine the location of the asset 104 within the room. For example, the asset 104 may use the RSSI of the different location IDs to triangulate the location of the asset 104 in the room. In another example, the beacon device 102 may be located at different locations. For example, the beacon device 102 may be located in a hallway, in a lobby, in a stairwell, in a room, in a parking lot, and so forth.

When the asset 104 determines its location, the asset 104 may communicate asset information (such as location information, asset management information, and so forth) to a closest communication hub 106. In one example, the communication hub 106 may be a device (such as a communication plate) mounted to a wall. In another example, the communication hub 106 may be integrated into a construction of a location. For example, the communication hub 106 may be integrated into a floor, ceiling, or wall of a facility, for example. In another example, the communication hub 106 may be software on the server 108.

In one example, the communication hub 106 may be located at a different location than the room 110 (such as a central location on the floor where the device is located or a central location in the building where the device is located). When the communication hub 106 receives the asset information from the asset 104, the communication hub 106 may relay the information to a server 108. In one example, the communication hub 106 may receive information from different devices. When the communication hub 106 receives the information from the different devices, the communication hub 106 may aggregate the data and send the aggregated asset information to the server 108.

One advantage of the asset 104 determining its location and sending the asset management information to the communication hub 106 may be to enable the beacon device 102 to be small and low energy. For example, because the beacon device 102 broadcasts the location ID, the beacon device 102 may consume little power (such as a 1-2 mAh per day) and may be powered by a small battery for an extended period of time. The asset 104 may have a separate power supply that may be recharged more easily than the beacon device 102. Another advantage of the asset 104 communicating the asset information may be that the asset 104 may select the information of the asset 104 to be communicated to the communication hub 106 and communicate the information in real-time and directly to the communication hub 106 to reduce communication interference from multiple devices.

In one example, the MMS 100 may track the assets 104 in real-time or substantially real-time. For example, the asset 104 may continuously communicate asset and management information to the communication hub 106.

In another example, the MMS 100 may track the assets on a periodic basis. For example, the asset 104 may communicate asset and management information to the communication hub 106 on a periodic basis. In another example, the communication hub 106 may transmit a request to the asset 104 to communicate the asset and management information. When the asset 104 receives the request, the asset 104 may communicate the asset and management information to the communication hub 106.

In one example, the MMS may include an implementation system to map a facility where assets may be managed, e.g., determine a schematic or layout of the facility. In another example, the implementation system may include software to determine a schematic or layout of the facility, including rooms, stairway objects, hallway objects, and so forth, based on a digital plan and/or a computer-assisted built plan within the software. In another example, a user may use a scanner, such as a three-dimensional (3D) scanner and walk around the facility collecting layout information, where the software may use the information from the scanner to determine the layout of the facility.

With further reference to FIG. 1, when the implementation software has determined a layout of the facility, the software may associate the beacon devices 102 and/or the communication hub 106 may be associated with the layout of the facility. For example, the beacon devices 102 and/or the communication hubs 106 in a facility may have a unique ID. When the facility layout is determined, the implementation software may receive input from an input device (such as a mouse, a keyboard, a stylus, a touch screen, and so forth) associating the different unique IDs with locations on the facility layout.

In another example, locations in the facility layout may have unique IDs associated with the location. In this example, an assistance device (such as a scanner or a communication device) may be taken to one or more locations in the facility, where the location ID may be selected, the assistance device may scan or communicate with the beacon device 102 and/or the communication hub 106, and the beacon device 102 and/or the communication hub 106 may be associated with the location ID. In another example, when a device is located at a facility location, the assistance device may scan the location for the beacon devices 102 and/or the communication hubs 106 (such as by using by using Bluetooth® scanning) and associate the beacon device 102 and/or the communication hub 106 scanner in the location with a location ID. For example, a user may walk into a room with a first location ID, use a tablet with Bluetooth® capabilities to scan the room for the beacon devices 102 and/or the communication hubs 106, and the software may associate the beacon devices 102 and/or the communication hubs 106 detected by the tablet with the first location ID. The user may repeat this process for multiple locations in the facility.

In another example, the beacon devices 102 may have a predefined number or identifier (ID). When a layout of the building is compiled, the user may use a graphical user interface (GUI) to select which beacon device is located in each room, hallway, conference room and the like.

An advantage of the implementation of the MMS 100 may be to enable integration of the MMS into a preexisting facility, e.g., the MMS may be installed in a preexisting facility and the implementation system may map the preexisting facility. Another advantage of the MMS may be that the installation and implementation of the MMS may enable quick and efficient installation as the MMS may be installed and configured for a facility without invasively installing an asset management system. Another advantage of the MMS may be that the system may avoid interference by other devices by using the implementation system to determine optimal locations of the beacon devices 102 and/or the communication hubs 106.

FIG. 2 is a diagram of an authentication system 200 to authenticate access to the MMS 100 of FIG. 1, including a medical database, according to one example. In this example, the authentication system 200 may include multiple assets 104, a medical database server 250, a real-time location system (RTLS) 220 and an authentication server 230. The medical database server 250 may include a medical database 254 including patient records 255 and other personal and confidential information needing authenticated, or secured, access by medical staff members (MSMs).

The RTLS 220 may include multiple beacons and/or tags with which are associated location identifier (IDs) as discussed with reference to FIG. 1, which may be stored in the location IDs database 222. The RTLS 220 may further include a staff locations database 224 to store and track locations of the MSMs based on tags (or other locater) positioned in badges, bracelets and the like worn by the MSMs. The RTLS may further include a patient locations database 226 to store and track locations of patients within a medical facility, such as with tags (or other locator) positioned in badges, bracelets (or other device that is attached to the patient), or attached to a bed or other equipment of the patient, such as an IV tower.

Each of the assets 104 (such as a medical cart and the like previously listed) may include hardware and software that provides the ability to locate and/or confirm locations of individuals and other assets, and to authenticate MSMs and other users for access to a medical application and/or database. In FIG. 2, an exemplary asset is shown as Asset_n, which may include, but not be limited to a processing device 202, a scanner 211 (or interrogator as may be needed to locate passive RFID tags), biometric hardware 213, a biometric capturer 214, a global positioning system (GPS) device 218, and/or other location determining hardware and/or software.

The biometric capturer 214 may be integrated within or work in conjunction with the processing device 202 (or include instructions executed by the processing device) and the biometric hardware 213 to capture a biometric of a user. As will be discussed in more detail, the biometric may be validated against one or more stored biometrics, or may be captured as an initial biometric for a new user against which future authentication attempts are compared.

The processing device 202 may include, but not be limited to, a locator 212, a correlator 206, and an authenticator 216. The locator 212 may work with the scanner 211, the GPS device 218, and/or the RTLS 220 to determine the location of a patient, an MSM, its own location or that of another asset. The locator 212 may work according to RFID or BLE-based technology, based on GPS, Wi-Fi® developed by the Wi-Fi Alliance, or cellular technology, and/or based on received signal strength (RSSI), for example. The locations of MSMs, the patient and/or the asset may be used, whole or in part, for authenticating MSMs for access to the asset 104, and thus the medical database 254.

The correlator 206 may perform correlations between these locations, e.g., between the locations of the MSM requesting access to the asset and medical database, a patient for which the MSM requests information and/or the asset 104 located in a room or the proximity of the patient. For example, the correlator 206 may determine whether the MSM is co-located with the patient (e.g., within the same room) and/or whether the asset 104 itself is co-located in the same room with the patient. Given a location, the asset 104 (with optional input from the RTLS 220), may determine in what room of the medical facility that location resides. In this way, the asset 104 may correlate, at least at a room or area level, the locations of the MSM, a patient and the asset 104.

The authenticator 216 may run the general authentication process at the asset level using one or more authentication tools as will be explained in more detail, which may include second factor authentication of the MSM (or user) wanting to access the asset, and the medical database 254 including the patient records 255. The authentication may also include results of the location correlation performed by the correlator 206, and thus improve the accuracy and security of the authentication of the user. In one example, at least one form of authentication includes validation of a biometric captured by the biometric capturer 214 and biometric hardware 213 of the asset. The authenticator 216 may run any series of authentications using the one or more authentication tools, which may be driven by an algorithm or group of algorithms. After successful validation of an identity of the MSM, and passing the authentication, the authenticator 216 may grant access by the MSM to the medical database server 250 (e.g., via the one or more authentication tools).

In one example, the authentication server 230 may include, but is not to be limited to, the processing device 202, an account manager 234, a staff accounts database 238, an access codes database 242, a biometrics database 244, and a security access level database 246. In one example, the authentication server 230 and the medical database server 208 may be located on different servers or may be two separate databases on a single server. In another example, the authentication server 230 and the medical database server 208 may be integrated as a single server, and so reference to one or the other may be more for the benefit to ease explanation than to require that certain processes be executed by one, or that certain data be stored by one, as compared to the other. For example, even if separate, the authentication server 230 may act as a gatekeeper to access by MSMs to the medical database 254 located on the medical database server 208.

In one example, the processing device 202 of the authentication server 230 may be the same as the processing device 202 of the asset 104. In other words, the authentication server 230 may perform the same locating, correlating and/or authenticating functions across the communications network 115 on behalf of the asset 104, e.g., such that processes requiring more processing power and/or access to the above-listed databases may be performed in the same location. In another example, one or more process may be performed by the processing device 202 at the asset 104 and one or more other process may be performed by the processing device of the authentication server 230. When authentication is completed, the authentication server 230 may send a positive validation indication to the asset 104, which may then grant access to the MSM that has been authenticated.

In one example, the account manager 234 may create a security access account for each new medical staff member (MSM) (such as a doctor, nurse, aide and the like) wanting access to the medical database 254. The account manager 234 may then set up access codes for each MSM such as a username, password, PIN and swipe card ID, secret shape, gesture, badge tap and the like which may be stored in the access codes database 242. The account manager 234 may further coordinate the capture of a biometric of the new MSM by the asset (or other computer within the medical facility) to begin a baseline against which to compare future biometrics. If set up with facial or iris recognition or the like, the account manager may request to obtain more than one image, such as from different angles or in differing lighting conditions, on which to build a set of baseline images against which to compare future biometric validations. The authentication server 230 may store the captured and updated biometrics in the biometrics database 244.

The account manager 234 may further be directed to set a certain security access level for each MSM and store the security access levels in the security access level database 246 in relation to the corresponding staff accounts database 238. Each security access level may dictate a certain level of access to patient records 255 and personal information permitted by corresponding MSMs (or officers, enlisted, government personnel of differing positions). For example, different individuals may have different security access levels, which may mean access to less or more information or access to information of a different quality, e.g., less or more confidential or sensitive.

In one example, a doctor may access complete patient information, including treatment information, medication charts, personal information, and so forth. In this example, a nurse's aide may have limited access to the patient information and be limited to accessing treatment information and medical carts. Furthermore, a specimen collector or medical technician may have further limited information as may be dictated on a need to know basis according to their respective job descriptions.

In another example, a commander in the military, the S1 and personnel staff may access entire records of military personnel within their unit, while other personnel within the unit may only access their own personal record(s). In a further example, a leader of a government agency may access data records of personnel within their stewardship but those personnel may only be able to access their own data record(s). Similarly, personnel with certain positions or clearance levels may be provided access to differing levels of confidential or sensitive strategy and planning documents based on security level granted to those personnel.

Returning to a medical setting, patient information and/or security level information may be associated with facial recognition information. In this example, doctors may access soft assets, such as patient information, by providing a device in the MMS 100 with facial recognition information.

In one example, the identity of the individual may be tied to the location of the device. For example, when a doctor enters a room in a hospital with an asset 104 like a medical cart with an integrated computer system, the medical cart may determine the identity of the doctor using facial recognition and the location of the medical cart. In one example, the medical cart may authenticate the identity of the doctor. When the identity is confirmed, the medical cart may determine the location of the doctor. When the doctor is located in a patient's room that the doctor is treating, the medical cart may display a patient's information to the doctor. When the doctor is located in a patient's room that the doctor is not treating or in another location that is not the patient's room the medical cart may deny access to the patient information. In another example, when the doctor is not located in the patient's room, the medical cart may request additional security information prior to providing the doctor with access to the patient information.

In another example, when the asset 104 enters a location, such as the patient's room, the device may determine the location of the device, the identity of the individual, and determine the security access level of the individual. Based on the location information, identify information, and security access level, the asset 104 may access patient information and provide the user of the device with the patient information in view of their security access level.

In another example, the device can also use facial recognition to determine the identity of the patient. For example, when the doctor enters the patient's room, the device may determine what patient is assigned to that room and then use facial recognition to verify that an individual in that room is the assigned person.

In another example, the asset 104 may access facial recognition information for individuals using the MMS 100. In this example, the asset 104 may communicate with a communications hub 106 of the authentication system 200 requesting facial recognition information of the doctor. The communications hub 106 may access the authentication server 230 in which is stored the facial recognition information and communicate the facial recognition information back to the device. In another example, the asset 104 may directly access the authentication server 230 without need to access the communications hub 106. In either case, the asset 104 may access the security access level (via the communications hub or directly) as stored in the security access levels database 246.

When a user (or MSM) enters a room with an asset 104, the asset 104 may authenticate the ID of the user. In one example, the asset 104 may authenticate the ID of the user using a biometric sensor such as a facial recognition scanner, a fingerprint scanner, a voice recognition scanner, and so forth. In another example, the asset 104 may authenticate the ID of the user using a non-biometric authentication method such as a personal identification number (PIN) code, an RFID badge, a magnetic strip badge, a secret shape, a gesture and so forth.

When the asset 104 determines the location of the device and the ID of the user, the asset 104 may determine an access level of the user for that location. For example, the device may determine that the user is a doctor working at a hospital that is treating a patient located in the room where the device is located. The device may then determine that the doctor has full access to the patient's medical information and provide the user with access to this information. In another example, the user may be a nurse located in the patient's room. When the asset 104 determines that the user is a nurse located in the patient's room, the asset 104 can determine that the nurse has limited access to the patient's medical records and provide the limited information.

In another example, the asset 104 may determine the patient assigned to a location and automatically pull up the patient information when the device authenticates the user's ID and the location of the device. When the asset 104 leaves the location and/or the user of the device changes, the asset 104 may restrict access to the patient information until the location of the device and the ID of the user may be determined. In one example, a doctor may enter a patient room with the asset 104. The asset 104 may determine that the doctor is allowed access to the patient's information while located in the room and automatically display the patient information to the doctor while the doctor is in the room. When the doctor or the device leaves the room the access to the patient information ceases. In this example, the doctor may be making rounds to different patient's rooms and at the rooms the asset 104 may automatically provide the doctor access to the patient information while the doctor is located in the patient's room.

Facial identification may be used as a biometric interface to login to an asset 104. The asset login process may allow for integration with a single sign-on (SSO) security server. Components used for the facial identification may include a central biometric data store, an enrollment application and a biometric capture application. The biometric enrollment application may be executed by the account manager 234 and may have the ability to associate a staff account with biometric data. The biometric capture application may authenticate captured biometric data against the biometrics stored in the biometrics database 244 and can login using credentials stored in the access codes database 242. The biometric can be full face utilizing streaming image capture via an internal or external camera. Networking communication for facial recognition may be used for authentication to a common biometric server.

Authentication of a user with biometric data may occur when the asset 104 sends biometric-captured data to the authentication server 230. This authentication may have two results, valid or invalid. When the biometric is determined to be valid the staff account may be logged into the asset 104. When the biometric is determined to be invalid, the asset may not be logged in and continue the cycle for authentication.

In one example, images stored in the biometrics database 244 for facial recognition may be either native or mirrored. In one example, the mirrored image an image in a reversed orientation (e.g., a mirrored reflection). In another example, the native and mirrored images may be mixed between each other. In another example, the native and mirrored images may not be mixed between each other. Biometric identification may fail when a face was enrolled from a mirrored image, and later a non-mirrored face image is used for recognition (or vice versa). For example, some cameras or devices can be configured to produce mirrored images or may even produce them by default, and different cameras or configurations may be used during enrollment and identification. In one embodiment, the face images can have a uniform orientation, where all images are either native or mirrored, e.g., but not mixed between each other.

Authentication in video mode may be used together with a liveness detector, which may be integrated within the authenticator 216, and which checks that the image for which a biometric is captured is a live person (not a photo, for example). This prevents granting access to an asset with an image of the subject. Detection of “liveness” may include, but not be limited to, detecting blinking of eyes, moving the head around, tilting the head, moving the head closer to or further from the camera, and/or slightly changing facial expression. Liveness may also be detected using other sensors such as a microphone where the user speaks a given phrase or using voiceprint identification.

When the authentication server 230 has a positive result from the supplied biometric, the asset 104 may be logged in with the associated user database account. When the authentication server 230 has a negative result from the supplied biometric, the asset 104 may not be logged in and can continue the cycle for biometric authentication. When a biometric is authenticated against the biometrics database 244, and the MSM's account is disabled, the asset may not be logged in.

In one example, the authentication system 200 may include a layered authentication of a user. For example, the authentication system 200 may perform a first layer or primary security authorization, such as a facial recognition authentication. Based on the first layer security authorization, the security system may perform one or more additional activities, such as, for example: (1) a second layer authentication and/or a third layer authentication, such as discussed previously; (2) provide access to the medical database server 250 to which the asset 104 is connected; (3) request additional information; (4) reject a request to access the medical database server 250; and/or (5) to perform other predetermined actions.

When layering in authentication as discussed above, greater or fewer layers of authentication may be used depending on the level of accuracy (or strength) with which the user is identified at each subsequent layer and/or a level of confidentiality of the information attempting to be accessed. When some doubt exists or authentication is performed with a weaker method, a next layer may increase the difficulty of spoofing or hacking the authentication. For example, a first layer may be a username and password, a second layer may be a PIN number, a third layer may be a random security code (like an RSA token), a fourth layer may be a biometric, and a fifth layer may include further second factor authentication, where these layers may have their orders changed in various examples. By way of further example, when the first layer provides 50% accuracy, then the MSM may add a second layer of authentication. When the second layer increases the accuracy to 75%, the MSM may add additional layers until accuracy reaches a predetermined level, such as 85% or 90% or the like.

In one example, the authentication system may enable a user to access a device or a database using a single sign-on (SSO), such as with use of facial recognition authentication. FIG. 3 is a flowchart 300 of an exemplary method for validating credentials through the authentication system 200 according to one example.

In the present example, an asset 104 may perform a set of two authentications either in parallel or serially. A user may input credentials (such as username/pas sword, PIN, access card, or the like) into a keyboard or other input device (302). The authenticator 216 may then determine whether the credentials are captured (304) and validate the credentials at the authentication server 130, with a check with stored access codes in the access codes database 242.

The asset 104 may further prompt the user to provide a biometric for authentication (312), or some other form of identification. The authenticator 216 may then determine whether the biometric is captured (314) and then validate the biometric at the authentication server 130, with a check with stored biometrics in the biometrics database 244.

The authenticator 216 may then determine whether a valid response is received from the authentication server for the credential validation and the biometric validation (318). The asset 104 may then retrieve an operating system credential and send the operating system credential to a third party single sign-on (SSO) server 330. An operating system credential (e.g., an SSO credential) may include a username and password, a PIN or other authentication identifier obtained by the operation system. In some examples, a positive validation by the authentication server 130 may act as SSO credential for access to applications and software of the asset.

The asset 104 may further get user environment settings from a cloud server 350 or the like (324). The asset 104 may then set an environment for user access to certain applications or features available through the asset based on the validation of the biometric, the SSO credentials, and/or the operation system credential. Part of the access granted may include access to software or an application through which the medical database 254 is accessed and queried.

In one example, the authentication system 200 may automatically log a user out after a period of inactivity or when the user may not be adjacent the asset 104 for a threshold period of time. When the user may be logged out, the authentication system may retain a previous state of the system for a threshold period of time. For example, when a user may be logged out, the authentication system 200 may maintain the last known system configuration for 10 minutes. When the same user logs back into the system within 10 minutes, the authentication system 200 may bring back up the last known system configuration. When the user logs back in after the 10 minutes have expired, the authentication system 200 may be reset to a default configuration.

In another example, the authentication system 200 may anticipate when a user may use a device. For example, the authentication system 200 may use a camera to monitor when the user (e.g., through facial recognition) is approaching the device and may automatically log the user in and configure the device based on user preferences.

FIG. 4 is a flowchart 400 of an exemplary method for creating of a biometric for use in the authentication system 200 according to one example. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (410). The asset 104 may then select an account appropriate for the user (420), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (430) and continue to attempt capture until successful (430). Upon successful capture, the asset may create the biometric and send the captured biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (440).

FIG. 5 is a flowchart 500 of an exemplary method for updating a biometric being used in the authentication system 200 according to one example. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (510). The asset 104 may then select an account appropriate for the user (520), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (530) and continue to attempt capture until successful (530). Upon successful capture, the asset may update the biometric (e.g., a previously captured or stored biometric) and send the updated biometric for storage in the biometrics database 144, e.g., in conjunction with user's staff account (540). Updating a biometric recognizes that a biometric may change over time, such as facial features may change with fluctuating weight or age in the example of facial recognition.

The updating the biometric process may also involve authenticating an identity of the user associated with the stored (or stale) biometric before updating or replacing the stored biometric with an updated biometric. The authentication as disclosed elsewhere herein may include a primary authentication, and alternatively, a primary authentication and a second factor authentication such as layered authentication approaches to increase the accuracy and the security of making updates to the biometrics. (See FIG. 9 for more details and an alternative example.)

FIG. 6 is a flowchart 600 of an exemplary method for deleting a biometric being used in the authentication system 200 according to one example. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (610). The asset 104 may then select an account appropriate for the user (620), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether to delete a biometric and continue to operate until successful deletion (630). The asset 104 may then direct the authentication server to delete the biometric from the biometrics database 144 (640). Deletion of a biometric may occur such as based on an account of a user being removed, deleted or changed, or in the case a staff account needs to be recreated from scratch, including creation of access codes and biometrics. The biometric may also be removed when an active database changes, which may include a different list of authorized users.

FIG. 7 is a flowchart 700 of an exemplary method for validating a biometric captured for use in the authentication system 200 according to one example. The asset 104 may load one or more medical database accounts from the staff accounts database 138 (710). The asset 104 may then select an account appropriate for the user (720), such as based on credentials as validated in the method of FIG. 3. The asset 104 may then determine whether a biometric has been captured (730) and continue to attempt capture until successful (730). The asset 104 may then request the authentication server 230 to validate the captured biometric with one or more biometrics stored in the biometrics database 144 (740). The asset 104 may then determine whether the biometric is valid (750), e.g., based on receipt of a valid or invalid response from the authentication server 230. When valid, the asset 104 may alert or inform the user of successful validation (760), and thus grant access to the user. When invalid, the asset 104 may alert or inform the user of the failure (770), and optionally prompt the user for a different biometric or other form of authentication.

FIG. 8 is a flowchart 800 of an exemplary method for validating a biometric captured for use in the authentication system 200, according to another example. After a user (e.g., a medical staff member) logs in with a keyboard (or the like) (810), the asset 104 may determine whether biometric validation is available (820). If not, the asset 104 may prompt the user for other authentication (830) and validate the other form of authentication (840), which may be another biometric, a username/password, PIN, access card or the like. If yes, the asset 104 may attempt to capture a biometric of the user until successful (850). The asset 104 may then request the authentication server 230 to validate the biometric as done in the method of FIG. 7 (860). When the authentication server returns a response that the biometric is valid, the asset may alert or inform the user that the biometric is valid (870). When the authentication server returns a response that the biometric is invalid, the asset 104 may prompt the use to create another biometric (or try again to capture the same biometric again) that may be used for comparison for later authentications of the user (880).

FIG. 9 is a flowchart 900 of an exemplary method for validating a biometric and for handling a stored biometric that has become stale, according to one example. The asset 104 may determine whether a biometric has been captured (910), until successfully capturing the biometric (910). The asset 104 may then direct the authenticator 216 (at the asset or at the authentication server 230) to validate the biometric based on comparison with one or more biometrics stored in the biometrics database 244 in relation to the user's staff account (920).

The asset may then determine whether the biometric is valid (930) based on a response from validating the biometric in step 920. When the asset determines that the biometric is not valid, the asset may restart the authentication process with attempting again to capture the biometric (or a different type of biometric) (910). When the asset determines that the biometric is valid, the asset may determine whether the biometric is more than a certain number of days old (for example older than a week, a fort night, etc.) (940). When the biometric is older than the certain number of days, the asset 104 may alert the user to update (or replace) the biometric (950) as performed in FIG. 5. The asset 104 may then also receive a login credential of the user (960) for a layered authentication before granting the user access to the medical database.

With further reference to step (940) in FIG. 9, a weighting may be applied to a biometric which may change (e.g., decrease) as the biometric ages. The weighting may also be adjusted based on verified lighting conditions or other factors that may affect the reliability of a captured biometric.

In one example, the facial recognition system may malfunction or be unable to authenticate the user. For example, the facial recognition system may not be able to communicate with the authentication server 230 to access facial recognition information. In one example, when an asset 104 is at a location where the communications network 115 is not available, then a login or badge tap may be used for authentication. In one example, when the login or badge tap may be used for authentication, the user may be granted limited access to the asset 104 or information available through the asset. For example, the user may not be able to login to patient records but could generally access the authentication system 200 for diagnostics, troubleshooting and the like. In another example, the user may be restricted to only accessing power assistance systems to move the cart to a location where the communications network 115 is available. In another example, an asset 104 may backup facial recognition information on the asset 104 and may use the backup facial recognition information to authenticate a user. One advantage of the asset 104 using the facial recognition system may be to provide a standalone authentication system. Another advantage of the asset 104 using the facial recognition system may be to save time by eliminating a manual login for authentication.

In one example, facial recognition may be used in combination with location information to authenticate an identity of a user. For example, an asset 104 may determine an identity of the user using the facial recognition system and then determine, based on the location of the asset 104, when the user is authorized to access the asset 104 or information on the device. For example, the facial recognition may authenticate the user but the asset 104 may be in a restricted area and deny access to the device and/or information on the asset 104.

FIG. 10 is a flowchart 1000 of an exemplary method for authenticating a medical staff member for access to the MMS according to one example. An asset may detect that a medical staff member (MSM) has entered a patient room (1004) and update a location of the MSM based on method disclosed above (1008). The MSM may attempt to access the asset (e.g., an all-in-one PC, a tablet, a medical cart or the like) (1012). To authenticate the MSM's access, the asset may capture a biometric (1016) and receive second factor authentication (1020). The asset (and/or the authentication server) may then determine whether the biometric and the second factor authentication are valid (1024). If the authentication is not valid, the asset denies access by the MSM (1028). If the authentication is valid, the asset grants access by the MSM to the asset (1032).

The asset may continue to detect the MSM attempting to access patient health record software (1036). In response to the detection, a single sign-on (SSO) server may retrieve the MSM's credential for the health record software on behalf of the asset (1040). The asset may determine whether the MSM's credentials are valid (1044). If not valid, the asset may deny access to the health record software (1028). If valid, the asset may grant access by the MSM to the health record software with a proper security access level corresponding to the MSM's security access rights. The asset may then request patient data from a medical database (e.g., as stored in a medical database) (1052). The asset may, in one example, then determine whether the patient corresponding to the requested patient data is located at the MSM's location (1056). If the MSM is not co-located with the patient, no records are returned, e.g., access may be denied (1060). If the MSM is co-located with the patient, the MSM may provide access to the patient health data according to the MSM's security access level.

FIG. 11 is a flowchart 1100 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to another example. An asset may authenticate the identification (ID) of a medical staff member (MSM) with biometric recognition (1110). The asset may then receive a first location of the MSM from a real-time location system (RTLS) or from data provided by the RTLS (1120). The asset may also receive a second location of a patient from the RTLS (1130). The asset may then correlate the first location with the second location to generate a first correlation, in determining whether the MSM is co-located with the patient (1140). The asset may also correlate the second location with a location of the asset to generate a second correlation (1150). The asset may then determine whether a positive correlation has been provided for the first correlation, and alternatively, for both the first and second correlations (1160). If not, the method may loop back to block 1120. If yes, the asset may grant access to medical records of the patient in accordance with the security access level of the authenticated MSM (1170).

FIG. 12 is a flowchart 1200 of an exemplary method for authenticating a medical staff member for access to the MMS 100 of FIG. 1 according to another example. An asset may validate credentials received from a user (such as a medical staff member) through the asset (1210). The asset may capture a biometric of the user through a biometric capturing device (1220). The asset may then send the captured biometric to an authentication server (1230). The asset may then receive a validation of the captured biometric from the authentication server (1240). The asset may then grant a level of access to records of the medical database server according to a security access level associated with the user (1250). The method of FIG. 12 may be combined with the method of FIG. 11 in alternative examples.

FIG. 13 is a flowchart 1300 of an exemplary method for authenticating an operator of a medical cart for access to the MMS 100 of FIG. 1 according to one example. As used herein, a hard asset can refer to a tangible and physical item or object, such as medical carts, intravenous (IV) poles; ventilators, tablets, medical devices, batteries, battery packs, power chargers, carts, computing tablets, all in one (AIO) personal computers (PCs), and so forth and so forth. The hard asset can be associated or coupled with an asset tag or a location ID beacon. In one example, the asset tag can receive location information from a location ID beacon, associate asset information with the location information, and send the information to a communication hub.

A hard asset can also refer to a fixed location, such as: a room in a facility, a floor of a building, a location of a building in an industrial park, a geographic location, and so forth. In another example, the hard asset can be a movable or variable location, such as a make-shift military post or a forward operating post. The hard asset can be associated or coupled with an asset tag or a location ID beacon. In one example, the asset tag can receive location information from a location ID beacon, associate asset information with the location information, and send the information to a communication hub.

As used herein, a soft asset can refer to human resources, such as patients, doctors, janitor, family members, or relatives. In another example, the soft asset can be information, including: epidemic information, such as tracking information of individuals that come in contact with an infectious Ebola; locations of individuals; patient information, such as medication prescriptions or treatment protocol; doctor's treatment or patient notes; facial recognition, such as patient tagging information using facial recognition; individual's security level access information; and so forth. The soft asset can be associated or coupled with an asset tag or a location ID beacon. In one example, the asset tag can receive location information from a location ID beacon, associate asset information with the location information, and send the information to a communication hub.

A processing device of a medical cart may capture biometric information of an operator of the medical cart (1310). A first asset tag device may be carried by the operator. The first asset tag device may define a first soft asset. The processing device may receive first location information for the first soft asset from a real-time location system (RTLS) over a network (1320). The processing device may receive second location information for a hard asset from the RTLS over the network (1330). The hard asset may be associated with at least one of a second asset tag device carried by the medical cart or an asset tag manager executing on the processing device of the medial cart. The processing device may determine whether a location factor for the operator is valid using the first location information and the second location information and whether the biometric information is valid (1340). The location factor may be indicative of a relative proximity of the first soft asset to the hard asset. If not, the method may loop back to block 1320. If yes, the processing device may grant access to the hard asset (1350).

In one example, the second asset tag device or the asset tag manager may wirelessly receive a beacon identifier from a beacon device and send sending the beacon identifier and an asset tag identifier associated with the asset to the RTLS system over the network. In another example, the first asset tag device may wirelessly receive a beacon identifier from a beacon device and sending the beacon identifier and an asset tag identifier associated with the first soft asset to the RTLS system over the network.

In one example, the processing device may receive an access request for a software product executing on the processing device that requires valid credentials for access (1360). As used herein, a software product may refer to an operating system (OS), an application, or a virtual machine. The processing device may perform a single sign-on (SSO) operation with a server responsive to the request (1370). The server may retrieve a credential stored in a database associated with the server, validate the operator with the stored credential, and return an indication of the security access level for the operator. The processing device may determine whether the biometric information is valid and determine whether the location factor is valid. If not, the method may loop back to block 1370. If yes, the processing device may grant access to the to the software product with the security access level.

In one example, the software product may receive a request to access information related to a second soft asset. The information related to the second soft asset may include medical records of a patient. The processing device may determine that a second location factor for the second soft asset is valid. The second location factor may be indicative of a relative proximity of the second soft asset to the first soft asset. Accordingly, the processing device may grant access to the information related to the second soft asset responsive to the determining that the second location factor is valid.

In one example, the SSO operation may access an entry of a directory managed by a directory server using an identifier for the operator, the entry containing the credential for the first soft asset.

In one example, the location factor for the operator may be determined to be valid by determining a distance between the hard asset and the first soft asset using the first location information and the second location information and comparing the distance to a distance threshold, where the location factor for the operator is valid when the distance is less than the distance threshold.

In one example, the second soft asset may be a patient or a room. In another example, the first soft asset may be a member of medical personnel. In another example, the first soft asset may be a member of medical personnel, the second soft asset may be a patient, and the hard asset is the medical cart. The medical cart may receive a request to access a secured dispensing bin for the patient. The processing device may determine that a second location factor for the second soft asset is valid. The second location factor may be indicative of a relative proximity of the patient to at least one of the member of medical personal or the medical cart. The processing device may grant access to the secured dispending bin responsive to the determining that the second location factor is valid.

In one example, the processing device further may include a display for presenting a graphical user interface (GUI) to the operator. The operator may have access to a software product executing on the processing device using the GUI. The GUI and the software product may be customizable.

In one example, the first soft asset may be a member of medical personnel, the second soft asset may be a patient, and the hard asset may be the medical cart. The processing device may receive an indication that a member of medical personnel has entered a room in which the medical cart resides. The processing device may determine that a second location factor for the second soft asset is valid. The second location factor may be indicative of a relative proximity of the patient to at least one of the member of the medical personal or the medical cart. The processing device may grant access to medical records associated with the patient responsive to the determining that the second location factor is valid.

In one example, the hard asset may be associated or coupled with an asset tag or a beacon device. In one example, the biometric information may be facial recognition information. The facial recognition information may include multiple images tracking an activity of the first soft asset.

FIG. 14 is a flowchart 1400 of an exemplary method for authenticating a first soft asset for access to an application according to one example. In one example, a processor may capture biometric information associated with a first soft asset (1410). A hard asset associated with the processor may receive from at least one beacon device, location information in view of the location of the first soft asset relative to the hard asset (1420). The processing device may determine whether the location information is valid and whether the biometric information is valid (1430). If not, the method may loop back to block 1420. If yes, the processor may grant access to the hard asset (1440).

In an example, the processor may receive from the first soft asset a request for information related to a second soft asset (1450). The processor may perform a single sign-on (SSO) operation to a server to retrieve one or more credentials of the first soft asset from a database associated with the server with respect to an application executed by the processor that provides information related to the second soft asset (1460). The processor may determine whether the one or more credentials of the first soft asset are valid with respect to the second soft asset (1470). If not, the method may loop back to block 1460. If yes, the processor may grant access to the application (1480).

In an example, the SSO operation may access an entry in a directory managed by a directory server, using an identifier of an operator of the processor, the entry containing the one or more credentials of the first soft asset.

In an example, the processor may provide to the first soft asset, a security access level to the information related to the second soft asset.

In an example, an application may receive from the first soft asset, a request for the information related to the second soft asset, the request including the location information of the first soft asset relative to the hard asset. The application may provide to the first soft asset, access to the information related to the second soft asset responsive to a location of the first soft asset relative to a location of the second soft asset.

In an example, the location of the first soft asset relative to the location of the second soft asset may be determined in view of the location of the first soft asset relative to the hard asset and the location of the second soft asset relative to the hard asset.

In an example, the request for the information related to the second soft asset further includes a security access level of the first soft asset provided by the processor. Providing access to the information related to the second soft asset may be further in view of the security access level of the first soft asset is equal to or greater than a level to access the information related to the second soft asset.

FIG. 15 illustrates a diagrammatic representation of a machine in the exemplary form of a computer system 1500 within which a set of instructions for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In alternative implementations, the machine may be connected (e.g., networked) to other machines in a LAN, an intranet, an extranet, or the Internet. The machine may operate in the capacity of a server or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a server, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” may also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed in the present disclosure.

The exemplary computer system 1500 includes a processing device (processor) 1502, a main memory 1504 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM) or Rambus DRAM (RDRAM), etc.), a static memory 1506 (e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device 1518, which communicate with each other via a bus 1530.

Processing device 1502 represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processing device 1502 may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processing device 1502 may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processing device 1502 is configured to execute instructions 1526 for performing the operations and steps discussed herein.

The computer system 1500 may further include a network interface device 1534. The computer system 1500 also may include a video display unit 1508 (e.g., a liquid crystal display (LCD), a cathode ray tube (CRT), or a touch screen), an alphanumeric input device 1510 (e.g., a keyboard), a cursor control device 1514 (e.g., a mouse), and a signal generation device 1516 (e.g., a speaker).

The data storage device 1518 may include a machine-readable storage medium 1524 on which is stored one or more sets of instructions 1526 (e.g., software) embodying any one or more of the methodologies or functions described herein. The instructions 1526 may also reside, completely or at least partially, within the main memory 1504 and/or within the processing device 15302 during execution thereof by the computer system 1500, the main memory 1504 and the processing device 1502 also constituting computer-readable storage media. The instructions 1526 may further be transmitted or received over a communications network 115 via the network interface device 1534.

While the machine-readable storage medium 1524 is shown in an exemplary implementation to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” may also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” may accordingly be taken to include, but not be limited to, solid-state memories, optical media, and magnetic media.

In the foregoing description, numerous details are set forth. It may be apparent, however, to one of ordinary skill in the art having the benefit of this disclosure, that the present disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present disclosure.

Some portions of the detailed description have been presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those that may use physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “segmenting”, “analyzing”, “determining”, “enabling”, “identifying,” “modifying” or the like, refer to the actions and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The disclosure also relates to an apparatus for performing the operations herein. This apparatus may be specially constructed for the purposes, or it may include a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions.

The words “example” or “exemplary” are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “example’ or “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the words “example” or “exemplary” is intended to present concepts in a concrete fashion. As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X includes A or B” is intended to mean any of the natural inclusive permutations. That is, if X includes A; X includes B; or X includes both A and B, then “X includes A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Moreover, use of the term “an example” or “one example” or “an implementation” or “one implementation” throughout is not intended to mean the same example or implementation unless described as such.

Reference throughout this specification to “one example” or “an example” means that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. Thus, the appearances of the phrase “in one example” or “in an example” in various places throughout this specification are not necessarily all referring to the same example. In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.”

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other implementations may be apparent to those of skill in the art upon reading and understanding the above description. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A method comprising:

capturing, by a processing device of a medical cart, biometric information of an operator of the medical cart;

receiving, by the processing device, first location information for a first soft asset device from a real-time location system (RTLS) over a network, wherein a first asset tag device is associated with a first soft asset;

receiving, by the processing device, second location information for a hard asset from the RTLS over the network, the hard asset associated with at least one of a second asset tag device;

determining, by the processing device, that a location factor is valid using the first location information and the second location information, the location factor being indicative of a relative proximity of the first soft asset to the hard asset;

determining, by the processing device, that the biometric information is valid; and

granting, by the processing device, access to the hard asset when the biometric information is valid and the location factor is valid.

2. The method of claim 1, further comprising:

wirelessly receiving, by the first asset tag device, a beacon identifier from a beacon device; and

sending, to the RTLS system over the network, the beacon identifier and an asset tag identifier associated with the first soft asset.

3. The method of claim 1, further comprising:

wirelessly receiving, by the second asset tag device or an asset tag manager, a beacon identifier from a beacon device; and

sending, to the RTLS system over the network, the beacon identifier and an asset tag identifier associated with a second soft asset.

4. The method of claim 1, further comprising:

receiving, by the processing device, an access request for a software product executing on the processing device that requires valid credentials for access;

performing, by the processing device, a single sign-on (SSO) operation with a server responsive to the access request, wherein the server retrieves a credential stored in a database associated with the server, validates the operator with the credential, and returns an indication of a security access level for the operator; and

granting, by the processing device, access to the software product with the security access level responsive to the determining that the biometric information is valid and the determining that the location factor is valid.

5. The method of claim 4, wherein performing the SSO operation comprises accessing an entry of a directory managed by a directory server using an identifier first soft asset, wherein the entry comprises the credential.

6. The method of claim 4, further comprising:

receiving, at the software product, a request to access information related to a second soft asset, wherein the information comprises medical records of a patient;

determining, by the processing device, that a second location factor for the second soft asset is valid, the second location factor being indicative of a proximity of the second soft asset to the first soft asset; and

granting, by the processing device, access to the information related to the second soft asset when the second location factor is valid.

7. The method of claim 6, wherein the second soft asset is a patient or a room.

8. The method of claim 4, wherein:

the first soft asset is a member of medical personnel,

a second soft asset is a patient,

the hard asset is the medical cart, and

the method further comprises: receiving, at the medical cart, a request to access a secured dispensing bin for the patient; determining, by the processing device, that a second location factor for the second soft asset is valid, the second location factor being indicative of a proximity of the patient to at least one of the member of medical personal or the medical cart; and granting, by the processing device, access to the secured dispending bin responsive to the determining that the second location factor is valid.

9. The method of claim 4, wherein the first soft asset is a member of medical personnel, the second soft asset is a patient, and the hard asset is the medical cart, wherein the method further comprises:

receiving, by the processing device, an indication that the member of medical personnel has entered a room in which the medical cart resides;

determining, by the processing device, that a second location factor for the second soft asset is valid, the second location factor being indicative of a relative proximity of the patient to at least one of the member of the medical personal or the medical cart; and

granting, by the processing device, access to medical records associated with the patient when the second location factor is valid.

10. The method of claim 1, wherein the determining that the location factor for the operator is valid comprises:

determining a distance between the hard asset and the first soft asset using the first location information and the second location information; and

comparing the distance to a distance threshold, wherein the location factor for the operator is valid when the distance is less than the distance threshold.

11. The method of claim 1, wherein the first soft asset is a member of medical personnel.

12. The method of claim 1, wherein:

the processing device further comprises a display for presenting a graphical user interface (GUI) to the operator, the operator having access to a software product executing on the processing device using the GUI, and

the GUI and the software product are customizable.

13. An apparatus comprising:

a processing device disposed in a medical cart, the processing device to execute an asset tag manager;

radio frequency (RF) circuitry coupled to the processing device to communicate information comprising receiving location information regarding the asset tag manager and a first asset tag device carried by an operator of the medical cart, wherein the first asset tag device is associated with a first soft asset; and

a battery coupled to the processing device and the RF circuitry,

wherein the processing device is further to execute an authentication tool to: capture biometric information of the operator of the medical cart; receive, using the RF circuitry, first location information for the first soft asset from a real-time location system (RTLS) over a network; receive, using the RF circuitry, second location information for a hard asset from the RTLS over the network, the hard asset associated with at least one of a second asset tag device coupled to the medical cart or the asset tag manager executing on the processing device of the medical cart; determine that a location factor first soft asset is valid using the first location information and the second location information, the location factor being indicative of a proximity of the first soft asset to the hard asset; determine that the biometric information is valid; and grant access to the hard asset responsive when the biometric information being valid and the location factor are valid.

14. The apparatus of claim 13, wherein the processing device is further to:

receive an access request for a software product executing on the processing device that requires valid credentials for access;

perform a single sign-on (SSO) operation with a server responsive to the access request, wherein the server retrieves a credential stored in a database associated with the server, validates the operator with the credential, and returns an indication of a security access level for the operator; and

grant access to the software product with the security access level when the biometric information being valid and the location factor are valid.

15. The apparatus of claim 14, wherein the processing device is further to:

receive, at the software product, a request to access information related to a second soft asset, wherein the information related to the second soft asset comprises medical records of a patient;

determine that a second location factor for the second soft asset is valid, the second location factor being indicative of a relative proximity of the second soft asset to the first soft asset; and

grant access to the information related to the second soft asset responsive to the second location factor being valid.

16. The apparatus of claim 15, wherein:

the first soft asset is a member of medical personnel,

the second soft asset is a patient,

the hard asset is the medical cart, and

the processing device is further to: receive, at the medical cart, a request to access a secured dispensing bin for the patient; determine that a second location factor for the second soft asset is valid, the second location factor being indicative of a relative proximity of the patient to at least one of the member of medical personal or the medical cart; and grant access to the secured dispending bin responsive to the second location factor being valid.

17. A method comprising:

capturing, by a processor, biometric information associated with a first soft asset;

receiving, by a hard asset associated with the processor, location information from at least one beacon device in view of the location of the first soft asset relative to the hard asset; and

granting, by the processor to the first soft asset, access to the hard asset when the biometric information and the location information are valid.

18. The method of claim 17, further comprising:

receiving, by the processor from the first soft asset, a request for information related to a second soft asset;

performing, by the processor, a single sign-on (SSO) operation to a server to retrieve one or more credentials of the first soft asset from a database associated with the server with respect to an application executed by the processor that provides information related to the second soft asset; and

granting, by the processor to the first soft asset, access to the application responsive to the processor determining that the one or more credentials of the first soft asset are valid with respect to the second soft asset.

19. The method of claim 18, wherein performing the SSO operation further comprises accessing an entry in a directory managed by a directory server, using an identifier of an operator of the processor, the entry comprising the one or more credentials of the first soft asset.

20. The method of claim 18, further comprising providing, to the first soft asset, a security access level to the information related to the second soft asset.

21. The method of claim 18, further comprising:

receiving, from the first soft asset, a request for the information related to the second soft asset, the request comprising the location information of the first soft asset relative to the hard asset; and

providing, to the first soft asset, access to the information related to the second soft asset responsive to a location of the first soft asset relative to a location of the second soft asset.

22. The method of claim 21, wherein the location of the first soft asset relative to the location of the second soft asset is determined in view of the location of the first soft asset relative to the hard asset and the location of the second soft asset relative to the hard asset.

23. The method of claim 21, wherein:

the request for the information related to the second soft asset further comprises a security access level of the first soft asset provided by the processor; and

providing access to the information related to the second soft asset is further in view of the security access level of the first soft asset is equal to or greater than a level to access the information related to the second soft asset.