NL2015959B1 - User device, server, responder device and methods for handling alarm messages. - Google Patents
User device, server, responder device and methods for handling alarm messages. Download PDFInfo
- Publication number
- NL2015959B1 NL2015959B1 NL2015959A NL2015959A NL2015959B1 NL 2015959 B1 NL2015959 B1 NL 2015959B1 NL 2015959 A NL2015959 A NL 2015959A NL 2015959 A NL2015959 A NL 2015959A NL 2015959 B1 NL2015959 B1 NL 2015959B1
- Authority
- NL
- Netherlands
- Prior art keywords
- message
- server
- responder
- user
- receiving
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
- G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
- G08B25/014—Alarm signalling to a central station with two-way communication, e.g. with signalling back
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
- G08B27/001—Signalling to an emergency team, e.g. firemen
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
- G08B25/005—Alarm destination chosen according to a hierarchy of available destinations, e.g. if hospital does not answer send to police station
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
- G08B25/01—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems characterised by the transmission medium
- G08B25/016—Personal emergency signalling and security systems
-
- G—PHYSICS
- G08—SIGNALLING
- G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
- G08B25/00—Alarm systems in which the location of the alarm condition is signalled to a central station, e.g. fire or police telegraphic systems
- G08B25/14—Central alarm receiver or annunciator arrangements
Landscapes
- Business, Economics & Management (AREA)
- Emergency Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Alarm Systems (AREA)
Abstract
A user device comprises an input interface, a data transmitter, a data receiver, an output interface, and a processor. The processor is operative to use the input interface to determine that a user needs help, to use the data transmitter to transmit an alarm message to the server upon determining that the user needs help, to use the data receiver to receive a first confirmation message, the first confirmation message confirming that the alarm message has been received by the server, to use the output interface to generate a first output signal upon receiving the first confirmation message, to use the data receiver to receive a second confirmation message, the second confirmation message confirming that help has been dispatched, and to use the output interface to generate a second output signal upon receiving the second confirmation message, the second output signal being different than the first output signal.
Description
User device, server, responder device and methods for handling alarm messages
Field of the invention [0001] The invention relates to a user device for transmitting an alarm message to a server, a server for receiving an alarm message from a user device and a responder device for receiving a dispatch message from a server.
[0002] The invention further relates to a method of transmitting an alarm message to a server, a method of receiving an alarm message from a user device, and a method of receiving a dispatch message from a server.
[0003] The invention also relates to one or more computer program products enabling a computer system to perform one or more of such methods.
Background of the invention [0004] GB 2492058A discloses a method that comprises detecting a state of progress from a radio terminal to a remote terminal via a radio network and sending one or more call progress messages to the user terminal to inform a user of the state of the progress of the communication. The user terminal may, for example, be a telecare terminal and the remote terminal may, for example, be a telecare call center. This method addresses the problem of long loop delays in the network when there is an emergency (either generated by an alarm at the user terminal or by a user pressing a button to connect urgently to the call center).
[0005] A drawback of this method is that only the communication between user terminal and the call center is automated and the user is only informed of the progress of the call between the user terminal and the call center.
Summary of the invention [0006] As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a device, a method or a computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system." Functions described in this disclosure may be implemented as an algorithm executed by a processor/microprocessor of a computer. Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied, e.g., stored, thereon.
[0007] Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a computer readable storage medium may include, but are not limited to, the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of the present invention, a computer readable storage medium may be any tangible medium that can contain, or store, a program for use by or in connection with an instruction execution system, apparatus, or device.
[0008] A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
[0009] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java(TM), Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
[0010] Aspects of the present invention are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor, in particular a microprocessor or a central processing unit (CPU), of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer, other programmable data processing apparatus, or other devices create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
[0011] These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
[0012] The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
[0013] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of devices, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
[0014] It is a first object of the invention to provide a user device for transmitting an alarm message to a server, which helps provide a user with more information on the progress of an alarm triggered by the user when used in a networked system.
[0015] It is a second object of the invention to provide a server for receiving an alarm message from a user device, which helps provide a user with more information on the progress of an alarm triggered by the user when used in a networked system.
[0016] It is a third object of the invention to provide a responder device for receiving a dispatch message from a server, which helps provide a user with more information on the progress of an alarm triggered by the user when used in a networked system.
[0017] It is a fourth object of the invention to provide a method of transmitting an alarm message to a server, which helps provide a user with more information on the progress of an alarm triggered by the user when used by a user device in a networked system.
[0018] It is a fifth object of the invention to provide a method of receiving an alarm message from a user device, which helps provide a user with more information on the progress of an alarm triggered by the user when used by a server in a networked system.
[0019] It is a sixth object of the invention to provide a method of receiving a dispatch message from a server, which helps provide a user with more information on the progress of an alarm triggered by the user when used by a responder device in a networked system.
[0020] According to the invention, the first object is realized in that the user device comprises an input interface; a data transmitter for transmitting messages to said server, a data receiver for receiving messages from said server, an output interface for providing at least one of visible, audible and tactual output to said user, and a processor operative to use said input interface to determine that a user needs help, e.g. to receive a command to send an alarm from said user, to use said data transmitter to transmit an alarm message to said server upon determining that said user needs help, e.g. upon receiving said command from said user, to use said data receiver to receive a first confirmation message from said server, said first confirmation message confirming that said alarm message has been received by said server, to use said output interface to generate a first output signal upon receiving said first confirmation message, to use said data receiver to receive a second confirmation message from said server, said second confirmation message confirming that help has been dispatched, and to use said output interface to generate a second output signal upon receiving said second confirmation message, said second output signal being different than said first output signal.
[0021] The inventor has recognized that by the user device not only providing a confirmation to the user that the server has received the alarm message, but by the user device also providing a confirmation to the user that help has been dispatched, the user device provides a stepwise progress feedback of a larger part of the alarm handling process, thereby reducing anguish experienced by the user. Furthermore as additional advantage, no persons are necessary to accept alarm calls from users and to call responders to ask them to attend to alarms.
[0022] Said processor may be operative to use said output interface to generate said first and second output signals as at least one of: different light elements, different colors of the same light element, different sounds and different vibrations. This allows the user to understand the generated output signals more easily than when the output signals are text messages. This is beneficial, for example, when the user is elderly and/or hurt.
[0023] Said processor may further be operative to use said data receiver to receive a further confirmation message from said server, said further confirmation message confirming that at least one responder device has received a dispatch message related to said alarm message, and to use said output interface to generate a further output signal upon receiving said further confirmation message, said further output signal being different than said first output signal and said second output signal. By having the user device further provide a confirmation to the user that at least one responder device has received a dispatch message related to the alarm message, which is provided in between the other two confirmations, the user device provides progress of an even larger part of the alarm handling process.
[0024] According to the invention, the second object is realized in that the server comprises a data receiver for receiving messages from a plurality of user devices and a plurality of responder devices, a data transmitter for transmitting messages to said plurality of user devices and said plurality of responder devices, and a processor operative to use said data receiver to receive an alarm message from a user device, to use said data transmitter to transmit a first confirmation message to said user device upon receiving said alarm message, said first confirmation message confirming that said alarm message has been received by said server, to use said data transmitter to transmit a dispatch message to at least one responder device, said dispatch message comprising an identifier associated with said user device, to use said data receiver to receive an acceptance message from at least one of said at least one responder device, and to use said data transmitter to transmit a second confirmation message to said user device upon receiving said acceptance message, said second confirmation message confirming that help has been dispatched.
[0025] In order for the user device to provide a user with more information on the progress of an alarm triggered by the user, the server needs to transmit more confirmation messages to the user devices. At least one of the confirmation messages transmitted by the server to the user device is based on one or more confirmation messages received by the server from one or more responder devices.
[0026] Said processor may be operative to use said data transmitter to transmit said dispatch message to a plurality of responder devices and to use said data receiver to receive said acceptance message from one of said plurality of responder devices and said processor may further be operative to use said data transmitter to transmit an information message to all of said plurality of responder devices except said one responder device from which said acceptance message was received, said information message indicating that said dispatch message can or should be ignored. By informing the responder devices from which no acceptance message was received that said dispatch message can or should be ignored, they can remove this alarm from the user interfaces provided to the responders on these responder devices so that these responders can focus their attention on the alarms that need their attention.
[0027] Said processor may further be operative to transmit an access control message to an access control device associated with at least one of said user device and a location of said user device, said access message comprising information allowing said access control device to grant access to said responder. By transmitting this access control message, the risk that the responder cannot access the premises of the user of the user device, who triggered the alarm, is reduced. Said access control message may comprise an identifier of at least one of a responder device and a responder currently using said responder device.
[0028] According to the invention, the third object is realized in that the responder device comprises a data receiver for receiving messages from a server, an output interface for providing information to a responder, an input interface for receiving a command from said responder, a data transmitter for transmitting messages to said server, and a processor operative to use said data receiver to receive a dispatch message from said server, said dispatch message comprising an identifier associated with a user device, to use said output interface to display information to said responder based on said dispatch message, to use said input interface to receive a command to accept said dispatch message from said responder, and to use said data transmitter to transmit an acceptance message to said server upon receiving said command to accept said dispatch message from said responder.
[0029] In order for the user device to provide a user with more information on the progress of an alarm triggered by the user, a responder device provides an input interface and output interface to a responder of the responder device asking the responder to accept (and optionally to decline) a dispatch request/message and transmits this information to the server, which then transmits this information to the user device, which in turn generates output signals based on this information. The responder device may automatically decline the dispatch request/message if the responder does not provide input in response to the generated output within a predetermined amount of time, for example.
[0030] Said processor may further be operative to use said data receiver to receive further information associated with said user device from said server after transmitting said acceptance message to said server. This further information may comprise a location of said user device, an address of a user of said user device or information allowing an access control signal to be generated, for example. By transmitting certain information only to responder devices that have accepted the corresponding dispatch message, network bandwidth usage can be reduced and/or access to personal data can be controlled better.
[0031] Said processor may further be operative to use at least one of said output interface and a further output interface to generate an access control signal based on at least one of said dispatch message and further information received after said processor transmitted said acceptance message to said server. This access control signal may be a bar code that can be displayed on the responder device or may be a signal that can be transmitted wirelessly to an access control device, for example. This is beneficial when the access control device itself is not connected to a network, for example.
[0032] In another aspect of the invention, the system of the invention comprises a plurality of user devices of the invention, a server of the invention and a plurality of responder devices of the invention.
[0033] According to the invention, the fourth object is realized in that the method of transmitting an alarm message to a server comprises the steps of using an input interface to determine that a user needs help, e.g. to receive a command to send an alarm from a user, using a data transmitter to transmit an alarm message to a server upon determining that said user needs help, e.g. upon receiving said command from said user, using a data receiver to receive a first confirmation message from said server, said first confirmation message confirming that said alarm message has been received by said server, generating a first visible, audible or tactual output signal upon receiving said first confirmation message, using said data receiver to receive a second confirmation message from said server, said second confirmation message confirming that help has been dispatched, and generating a second visible, audible or tactual output signal upon receiving said second confirmation message, said second output signal being different than said first output signal.
[0034] Said first and second output signals may be generated as at least one of: different light elements, different colors of the same light element, different sounds and different vibrations.
[0035] Said method may further comprise the steps of using said data receiver to receive a further confirmation message from said server, said further confirmation message confirming that at least one responder device has received a dispatch message related to said alarm message, and using said output interface to generate a further output signal upon receiving said further confirmation message, said further output signal being different than said first output signal and said second output signal.
[0036] According to the invention, the fifth object is realized in that the method of receiving an alarm message from a user device comprises the steps of using a data receiver to receive an alarm message from a user device, using a data transmitter to transmit a first confirmation message to said user device upon receiving said alarm message from said user device, said first confirmation message confirming that said alarm message has been received, using said data transmitter to transmit a dispatch message to at least one responder device, said dispatch message comprising an identifier associated with said user device, using said data receiver to receive an acceptance message from at least one of said at least one responder device, and using said data transmitter to transmit a second confirmation message to said user device upon receiving said acceptance message from said at least one of said at least one responder device, said second confirmation message confirming that help has been dispatched.
[0037] Said step of using said data transmitter to transmit a dispatch message to at least one responder device may comprise using said data transmitter to transmit said dispatch message to a plurality of responder devices, said step of using said data receiver to receive an acceptance message from at least one of said at least one responder device may comprise using said data receiver to receive said acceptance message from one of said plurality of responder devices and said method may further comprise the step of using said data transmitter to transmit an information message to all of said plurality of responder devices except said one responder device from which said acceptance message was received, said information message indicating that said dispatch message can or should be ignored.
[0038] Said method may further comprise the step of transmitting an access control message to an access control device associated with at least one of said user device and a location of said user device, said access message comprising information allowing said access control device to grant access to said responder. Said access control message may comprise an identifier of at least one of a responder device and a responder currently using said responder device.
[0039] According to the invention, the sixth object is realized in that the method of receiving a dispatch message from a server comprises the steps of using a data receiver to receive a dispatch message from a server, said dispatch message comprising an identifier associated with a user device, using an output interface to display information to a responder based on said dispatch message, using an input interface to receive a command to accept said dispatch message from said responder, and using a data transmitter to transmit an acceptance message to said server upon receiving said command to accept said dispatch message from said responder.
[0040] Said method may further comprise the step using said data receiver to receive further information associated with said user device from said server after transmitting said acceptance message to said server.
[0041] Said method may further comprise the step of using at least one of said output interface and a further output interface to generate an access control signal based on at least one of said dispatch message and further information received after transmitting said acceptance message to said server.
[0042] Said methods may be performed by software running on a programmable device. This software may be provided as a computer program product.
[0043] A non-transitory computer-readable storage medium stores at least one software code portion, the software code portion, when executed or processed by a user device, being configured to perform executable operations comprising: using an input interface to determine that a user needs help, e.g. to receive a command to send an alarm from a user, using a data transmitter to transmit an alarm message to a server upon determining that said user needs help, e.g. upon receiving said command from said user, using a data receiver to receive a first confirmation message from said server, said first confirmation message confirming that said alarm message has been received by said server, generating a first visible, audible or tactual output signal upon receiving said first confirmation message, using said data receiver to receive a second confirmation message from said server, said second confirmation message confirming that help has been dispatched, and generating a second visible, audible or tactual output signal upon receiving said second confirmation message, said second output signal being different than said first output signal.
[0044] A non-transitory computer-readable storage medium stores at least one software code portion, the software code portion, when executed or processed by a server, being configured to perform executable operations comprising: using a data receiver to receive an alarm message from a user device, using a data transmitter to transmit a first confirmation message to said user device upon receiving said alarm message from said user device, said first confirmation message confirming that said alarm message has been received, using said data transmitter to transmit a dispatch message to at least one responder device, said dispatch message comprising an identifier associated with said user device, using said data receiver to receive an acceptance message from at least one of said at least one responder device, and using said data transmitter to transmit a second confirmation message to said user device upon receiving said acceptance message from said at least one of said at least one responder device, said second confirmation message confirming that help has been dispatched.
[0045] A non-transitory computer-readable storage medium stores at least one software code portion, the software code portion, when executed or processed by a responder device, being configured to perform executable operations comprising: using a data receiver to receive a dispatch message from a server, said dispatch message comprising an identifier associated with a user device, using an output interface to display information to a responder based on said dispatch message, using an input interface to receive a command to accept said dispatch message from said responder, and using a data transmitter to transmit an acceptance message to said server upon receiving said command to accept said dispatch message from said responder.
Brief description of the Drawings [0046] These and other aspects of the invention are apparent from and will be further elucidated, by way of example, with reference to the drawings, in which: • Fig. 1 is a block diagram of the system of the invention; • Fig.2 is a block diagram of a first embodiment of the system of the invention; • Fig.3a is a first part of a flow diagram of an embodiment of the methods for handling an alarm message. • Fig.3b is a second part of a flow diagram of the embodiment of Fig.3a. • Fig.4 illustrates a first example screen of a user interface for responding to an alarm on a responder device; • Fig.5 is a flow diagram of a method of providing a user interface on a responder device; • Fig.6 is a flow diagram of a first embodiment of the method of Fig. 5; • Fig.7 is a flow diagram of a second embodiment of the method of Fig. 5; • Fig.8 is a flow diagram of a third embodiment of the method of Fig. 5; • Fig.9 is a flow diagram of a fourth embodiment of the method of Fig. 5; • Fig. 10 is an example of a hierarchical structure for use by the method of Fig. 5. • Fig. 11 is a first example screen of a user interface provided on a responder device; • Fig. 12 is a second example screen of a user interface provided on a responder device; • Fig. 13 is a third example screen of a user interface provided on a responder device; • Fig. 14 is a fourth example screen of a user interface provided on a responder device; • Fig. 15 is a fifth example screen of a user interface provided on a responder device; and • Fig. 16 is a block diagram of an exemplary data processing system for performing the methods of the invention.
[0047] Corresponding elements in the drawings are denoted by the same reference numeral.
Detailed description of the Drawings [0048] A system for handling alarm messages comprises a plurality of user devices 1, a server 21 and a plurality of responder devices 31, see Figs. 1 and 2. User device 1 comprises an input interface 3, a data transmitter 5 for transmitting messages to the server 21, a data receiver 7 for receiving messages from the server 21, an output interface 9 for providing at least one of visible, audible and tactual output to the user, and a processor 11. The processor 11 is operative to use the input interface 3 to determine that a user needs help, to use the data transmitter 5 to transmit an alarm message to the server 21 upon determining that said user needs help, to use the data receiver 7 to receive a first confirmation message from the server 21, the first confirmation message confirming that the alarm message has been received by the server 21, to use the output interface 9 to generate a first output signal, e.g. using light element 15a, upon receiving the first confirmation message, to use the data receiver 7 to receive a second confirmation message from the server 21, the second confirmation message confirming that help has been dispatched, and to use the output interface 9 to generate a second output signal, e.g. using light element 15b, upon receiving the second confirmation message, the second output signal being different than the first output signal.
[0049] Server 21 comprises a data receiver 23 for receiving messages from a plurality of user devices 1 and a plurality of responder devices 31, a data transmitter 25 for transmitting messages to the plurality of user devices 1 and the plurality of responder devices 31, and a processor 27. The processor 27 is operative to use the data receiver 23 to receive an alarm message from a user device 1, to use the data transmitter 25 to transmit a first confirmation message to the user device 1 upon receiving the alarm message, the first confirmation message confirming that the alarm message has been received by the server 21, to use the data transmitter to transmit a dispatch message to at least one responder device 31, the dispatch message comprising an identifier associated with the user device 1, to use the data receiver 23 to receive an acceptance message from at least one of the at least one responder device 31, and to use the data transmitter 25 to transmit a second confirmation message to the user device 1 upon receiving the acceptance message, the second confirmation message confirming that help has been dispatched.
[0050] Responder device 31 comprises a data receiver 33 for receiving messages from a server 21, an output interface 35 for providing information to a responder, an input interface 37 for receiving a command from the responder, a data transmitter 39 for transmitting messages to the server 21, and a processor 41. The processor 41 is operative to use the data receiver 33 to receive a dispatch message from the server 21, the dispatch message comprising an identifier associated with a user device 1, to use the output interface 35 to display information to the responder based on the dispatch message, to use the input interface 37 to receive a command to accept the dispatch message from the responder, and to use the data transmitter 39 to transmit an acceptance message to the server 21 upon receiving the command to accept the dispatch message from the responder.
[0051] In Fig.2, user devices 1a and 1b and responder devices 31a and 31b are shown. In user device 1a, the input interface 3 comprises an alarm button 13. In another embodiment, the input interface 3 may additionally or alternatively comprise sensors and/or circuitry operative to determine when an alarm should be automatically generated, e.g. a fall sensor. In responder device 31a, the input interface 37 and the output interface 35 are combined into one touchscreen interface 43. In the embodiment shown in Fig.2, the processor 11 is operative to use the output interface 9 to generate the first and second output signals as different light elements 15a, 15b and 15c. Alternatively, less or more than three light elements may be used. In another embodiment, the processor 11 may additionally or alternatively be operative to use the output interface 9 to generate the first and second output signals as different colors of the same light element, different sounds (e.g. different in pattern, length and/or pitch), different vibrations (e.g. different in pattern, length and/or intensity) and/or different screen icons/images.
[0052] User device 1 may be a dedicated device for sending alarms, e.g. a device that can be worn around the user’s neck or wrist, or it may be a general purpose device with dedicated software, e.g. a smartphone or a smartwatch. Processor 11 of user device 1 may be a dedicated processor or a general purpose processor, e.g. from Qualcomm or ARM. If processor 11 is a general purpose processor, it may run a general purpose operating system, e.g. Android or iOS. Responder device 31 is preferably a general purpose device with dedicated software, e.g. a smartphone or a tablet, but it can also be a dedicated device. Processor 41 of responder device 31 may be a dedicated processor or a general purpose processor, e.g. from Qualcomm or ARM. If processor 41 is a general purpose processor, it may run a general purpose operating system, e.g. Android or iOS.
[0053] Server 21 may comprise one or more devices. Server 21 may be a server farm, for example. Server 21 may comprise one or more computers, one or more network switches and/or routers and one or more network storage devices, for example. Server 1 may comprise a storage facility 29, which may be part of a computer or a network storage device, for example. The storage facility 29 may comprise one or more hard drives and/or one or more solid state storage components. The processor 27 of server 21 may run a Linux or other Unix-based operating system, for example. Server 21 may store a database on the storage facility 29, e.g. using MySQL software running on the processor 27. Server 21 may comprise scripting software to handle alarms and/or to ensure continuous timeline control. Processor 27 of server 1 may comprise one or more dedicated processors and/or one or more general purpose processors, e.g. from Intel or AMD.
[0054] User device 1, server 21 and responder device 31 may further comprise hardware components typical for such devices/systems, e.g. a battery and/or a power connector. Data transmitter 5 and data receiver 7 of user device 1 may be combined into one hardware component, i.e. a transceiver. Communication between user device 1 and server 21 may be direct, e.g. using a mobile cellular data network like GPRS, UMTS or LTE, or indirect via an access point near the user device 1. If the communication is indirect, the user device 21 and the access point may communicate for example wirelessly via a proprietary data protocol, e.g. using the 868Mhz frequency band, Wi-Fi or Bluetooth. Preferably, the data transmitter 5 and the data receiver 7 are power efficient in order to increase the time after which a battery of the user device 1 needs to be recharged or replaced. The access point and the server 21 may communicate for example using a mobile cellular data network or a fixed data network, e.g. fiber, CATV/DOCSIS or ADSL/VDSL. Communication from user device 1 to server 21 may use a different communication technology than communication from server 21 to user device 1.
[0055] Data transmitter 39 and data receiver 33 of responder device 31 may be combined into one hardware component, i.e. a transceiver. Communication between responder device 31 and server 21 may take place using similar technologies as communication between user device 1 and server 21. The responder device 31 is preferably a mobile device. If a responder device 31 is used only intramural, the use of access points may be sufficient. If a responder device 31 is (also) used intermural, use of a mobile cellular data network is preferable. Preferably, the data transmitter 39 and the data receiver 33 are power efficient in order to increase the time after which a battery of the responder device 31 needs to be recharged or replaced. Communication from responder device 31 to server 21 may use a different communication technology than communication from server 21 to responder device 31.
[0056] Data transmitter 25 and data receiver 23 of server 21 may be combined into one hardware component, i.e. a transceiver, e.g. if they are part of the same computer. Data transmitter 25 and data receiver 23 may each comprise multiple hardware components, e.g. if a different technology is used to communicate between user device 1 and server 21 than to communicate between responder device 31 and server 21, if different user devices 1 and/or different responder devices 31 use different technologies to communicate and/or if server 1 comprises multiple devices (e.g. computers).
[0057] In the same or in a different embodiment, the processor 11 of the user device 1 is further operative to use the data receiver 7 to receive a further confirmation message from the server 21, the further confirmation message confirming that at least one responder device 31 has received a dispatch message related to the alarm message, and to use the output interface 9 to generate a further output signal, e.g. using light element 15c, upon receiving the further confirmation message, the further output signal being different than the first output signal and the second output signal.
[0058] In the same or in a different embodiment, the processor 27 of the server 21 is operative to use the data transmitter 25 to transmit the dispatch message to a plurality of responder devices 31 and to use the data receiver 23 to receive the acceptance message from one of the plurality of responder devices 31 and the processor 27 is further operative to use the data transmitter 25 to transmit an information message to all of the plurality of responder devices 31 except the one responder device from which the acceptance message was received, the information message indicating that the dispatch message can or should be ignored.
[0059] In the same or in a different embodiment, the processor 27 of the server 21 is further operative to transmit an access control message to an access control device associated with at least one of the user device and a location of the user device, the access message comprising information allowing the access control device to grant access to the responder. The access control device may be a lock of a door, for example. The access control device may be connected to the Internet, for example. The access control message may comprise an identifier of at least one of a responder device 31 and a responder currently using the responder device 31. The identifier may comprise data allowing face recognition or may comprise a public key associated with the responder device 31 or the responder. In the latter case, the access control device may transmit a message encrypted using the public key to the responder device 31 and only grant access if the message can be returned decrypted. Alternatively, the access control message may comprise for example a passkey and the access control device may only grant access to the responder if the responder or the responder device 31 can provide the same passkey.
[0060] In the same or in a different embodiment, the processor 41 of the responder device 31 is further operative to use the data receiver 33 to receive further information associated with the user device 1 from the server 21 after transmitting the acceptance message to the server 21. The processor 41 of the responder device 31 may be operative to use at least one of the output interface 35 and a further output interface to generate an access control signal based on at least one of the dispatch message and further information received after the processor 41 transmitted the acceptance message to the server 21. The access control signal may be a screen image comprising a bar code or other pattern which allows an access control device with an optical scanner/camera to read the access control signal, for example. The further output interface may be a (second) display or a wireless transmitter, for example.
[0061] Server 21 may alternatively or additionally be used for continuous timeline control. In this embodiment, server 21 further comprises the storage facility 29 and the processor 27 is (further) operative to use the data transmitter 25 to transmit a message identifying at least a first responsibility (e.g. “Team A” or “Team B”) to a first responder device 31a (e.g. “Team A” if the first responder using the first responder device 31a is part of this team), to use the data receiver 23 to receive a message from the first responder device 31a indicating that a first responder has accepted the first responsibility, to create an association of a first type (e.g. representing that the responder is on duty with respect to this responsibility) between the first responder and the first responsibility on the storage facility 29, to obtain an identifier identifying a second responder having an association of the first type with the first responsibility from the storage facility 29, the second responder being different than the first responder, to use the data transmitter 25 to transmit a message to a second responder device 31b of the second responder indicating that the second responder’s duty with respect to the first responsibility has ended, and to remove an association of the first type between the first responsibility and the second responder on the storage facility 29.
[0062] In the same or in a different embodiment, the processor 27 of the server 21 is further operative to determine from the storage facility 29 whether the second responder has the first type of association with any responsibility and to use the data transmitter 25 to transmit a message to the second responder device 31b indicating that the second responder’s shift has ended if the second responder does not have the first type of association with any responsibility.
[0063] In the same or in a different embodiment, the processor 27 of the server 21 is further operative to use the data receiver 23 to receive a message from the second responder device 31b indicating that the second responder wants to end the second responder’s shift, to determine from the storage facility 29 at least one responsibility having an association of the first type with the second responder (i.e. the one or more responsibilities currently assigned to the second responder), to determine from the storage facility 29 at least one responder having an association of a second type (i.e. a responder that can have a first type of association with this responsibility, or in other words a responder that can be assigned to this responsibility, e.g. has appropriate capabilities and/or an appropriate work site) with the at least one responsibility, and to use the data transmitter 25 to transmit a message to at least one responder device 31 of the at least one responder identifying the at least one responsibility, which allows the at least one responder device 31 to ask the at least one responder to take over the at least one responsibility.
[0064] Figs. 3a and 3b show an embodiment of the method of handling an alarm of the invention. Step 51 comprises the user device 1 using an input interface to determine that a user needs help (e.g. the user presses a button or a fall is detected). Step 53 comprises the user device 1 using a data transmitter to transmit an alarm message to a server 21 upon determining that said user needs help. This alarm message optionally comprises the location of the user or of the user device 1. Step 55 comprises the user device 1 generating a visible, audible or tactual output signal Oi after the alarm message has been transmitted to the server 21 confirming to the user that the alarm message has been transmitted. Step 81 comprises the server 21 using a data receiver to receive the alarm message from the user device 1. Step 83 comprises the server 21 using a data transmitter to transmit a confirmation message Ci to the user device 1 upon receiving the alarm message from the user device 1, the confirmation message Ci confirming that the message has been received by the server. Step 57 comprises the user device 1 using a data receiver to receive the confirmation message Ci from the server 21. Step 59 comprises the user device 1 generating a visible, audible or tactual output signal 02 upon receiving the confirmation message Ci. Step 61 comprises the user device 1 using its data transmitter to transmit a confirmation message C2 to the server 21 confirming that the user device has received the confirmation message ci. Step 85 comprises the server 21 using its data receiver to receive the confirmation message C2.
[0065] Step 87 comprises the server 21 using its data transmitter to transmit a dispatch message to at least one responder device 31, the dispatch message comprising an identifier, e.g. client name and/or location, associated with the user device 1. The server 21 may transmit the dispatch message to all responder devices with a certain responsibility or only to the responder device with this certain responsibility that is nearest to the user. Step 101 comprises the responder device(s) 31 using a data receiver to receive the dispatch message from the server 21. Step 103 comprises the responder device(s) 31 using a data transmitter to transmit a confirmation message c3 to the server 21 confirming that the responder device(s) 31 have received the dispatch message. Step 89 comprises the server 31 using its data receiver to receive the confirmation message c3from the responder device(s) 31. Step 91 comprises the server 31 using its data transmitter to send a confirmation message c4 to the user device 1 confirming that the responder device(s) have received the alarm/dispatch message. Step 63 comprises the user device 1 receiving the confirmation message c4 from the server 21. Step 65 comprises the user device 1 generating a visible, audible or tactual output signal o3 upon receiving the confirmation message c4. Step 67 comprises the user device 1 using its data transmitter to transmit a confirmation message C5 to the server 21 confirming that the user device has received the confirmation message c4. Step 93 comprises the server 21 using its data receiver to receive the confirmation message c5 from the user device 1.
[0066] Continuing in Fig. 3b, step 105, performed after step 103 in this embodiment, comprises the responder device(s) 31 using an output interface to display information to one or more responders based on the dispatch message. An example of such an output interface is shown in Fig.4. This output interface is shown on touch screen 43 of responder device 31 in the embodiment of Fig.4. A field 121 shows the name and address of the client who triggered the alarm. A field 123 indicates a team/responsibility in which the user device, the user of the user device or the alarm message has been classified, e,g, “Team A”. Step 107 comprises the responder device(s) 31 using an input interface to allow at least one of the one or more responders to provide a command to accept the dispatch message, e.g. by using button 125 labelled “Accept”. The responder(s) may be able to decline the dispatch message by using button 127 labelled “Decline”. Step 109 comprises the responder device(s) 31 using its data transmitter to transmit an acceptance message to the server 21 upon receiving the command to accept the dispatch message from a responder. Step 95 comprises the server 21 using its data receiver to receive an acceptance message from at least one of the responder device(s) 31. If the server 21 receives multiple acceptance messages from multiple responder devices 31 in step 95, it preferably uses only one of the acceptance messages, e.g. the one received first or the one from the responder device that is nearest to the user.
[0067] Step 97 comprises the server 21 using its data transmitter to transmit a confirmation message Ceto the user device 1 upon receiving the acceptance message from the at least one of the responder device(s) 31, the confirmation message Ce confirming that help has been dispatched. Step 69 comprises the user device 1 using its data receiver to receive the confirmation message c6from the server 21. Step 71 comprises the user device 1 generating a visible, audible or tactual output signal o4 upon receiving the confirmation message ce. Output signals Oi 02, 03 and o4 are sufficiently different so that the user can distinguish between them. Step 73 comprises the user device 1 using its data transmitter to transmit a confirmation message C7 to the server 21 confirming that the user device has received the confirmation message Ce. Step 98 comprises the server 21 using its data receiver to receive the confirmation message C7 from the user device 1. Step 99 comprises the server 21 using its data transmitter to transmit an information message to the responder device(s) 31, preferably only to the one(s) from which no acceptance message was received or used, informing these responder device(s) that another responder has accepted the dispatch message and/or which other responder has accepted the dispatch message. Step 111 comprises these responder device(s) 31 using their data receiver to receive the information message from the server 21. The server 21 may then remove this dispatch message from the output interface if not already done so and/or inform the responder in the output interface that another responder will attend to the alarm. The server 21 may indicate in the output interface which other responder is attending to the alarm.
[0068] Fig.5 shows a method of providing a user interface on a responder device for ensuring continuous timeline control. The method comprises at least six steps. A step 131 comprises providing a first user interface to a first responder device allowing a first responder to accept a first responsibility, e.g. a “Team A” responsibility. A step 133 comprises using a data receiver to receive a message from the first responder device indicating that the first responder has accepted the first responsibility. A step 135 comprises creating an association of a first type between the first responder and the first responsibility on a storage facility, e.g. representing that the first responder is from now on handling care requests with regard to this first responsibility. A step 137 comprises obtaining an identifier identifying a second responder having an association of the first type with the first responsibility from the storage facility, the second responder being different than the first responder. In Fig.5, step 137 is performed after step 135. In this case, an identifier identifying the first responder may also be obtained in step 137 and then discarded. Step 137 may alternatively be performed before or in parallel to step 135. In this case, the identifier identifying the first responder is typically not obtained.
[0069] A step 139 comprises providing a second user interface to a second responder device informing the second responder, who may or may not have previously asked his duty with respect to the first responsibility to be ended, that his duty with respect to the first responsibility has ended. A step 141 comprises removing an association of the first type between the first responsibility and the second responder on the storage facility. In Fig.5, step 141 is performed after step 139. However, step 141 may alternatively be performed before or in parallel to step 139. The first user interface and the second user interface may be the same user interface. For example, Fig. 12 shows a user interface which informs a responder in field 221a that his duty with respect to the responsibility “Team A” has ended. The same user interface allows the responder to take on this responsibility again using “Take on” button 219 associated with field 211 labelled “Team A”. The method of Fig. 5 may be performed by a service provider or by a server, for example. A user interface may be provided to a responder device as an app/application or as webpages, for example.
[0070] Fig. 6 shows an embodiment of the method of Fig. 5. A shift comprises one or more responsibilities. When a responder has ended his shift, this means that he can go home and/or perform activities for which he does not need to be on call. When a responder’s shift is not automatically ended, he can request his shift to be ended. A step 155 comprises using a data receiver to receive a message from the second responder device indicating that the second responder wants to end his shift. A step 157 comprises determining from the storage facility at least one responsibility having an association of the first type with the second responder, i.e. the responsibilities currently assigned to the second responder. A step 159 comprises determining from the storage facility at least one responder having an association of a second type with the at least one responsibility, i.e. one or more responders that may be able to take over this responsibility or these responsibilities. A step 161 comprises providing at least one user interface to at least one responder device of the at least one responder asking the at least one responder whether the at least one responder accepts the at least one responsibility. Steps similar to steps 133, 135, 137, 139 and 141 may be performed after step 161 if the responder or one of the responders accepts a responsibility in step 161. An example of the user interface provided in step 161 is shown in Fig.14.
[0071] A step 163 comprises determining, after a time period At has passed, whether the at least one responder has accepted the at least one responsibility. If at least one of the at least one responsibility has not been accepted by any of the at least one responder within this time period At, the method further comprises a step 165, similar to step 159, of determining from the storage facility a further responder having an association of a second type with the at least one of the at least one responsibility, i.e. one or more further responders that may be able to take over this responsibility or these responsibilities, and a step 167, similar to step 161, of providing a further user interface to a further responder device of the further responder asking the further responder whether the further responder accepts the at least one of the at least one responsibility.
[0072] A step 151 comprises determining from the storage facility whether the second responder has the first type of association with any responsibility. A step 153 comprises using the second user interface to inform the second responder that the second responder’s shift has ended if the second responder does not have the first type of association with any responsibility. An example of the user interface provided in step 153 is shown in Fig. 13.
[0073] In the same or in a different embodiment, a check is performed whether all responsibilities have been assigned to a responder, see Fig. 7. Step 169 comprises verifying whether a responsibility has an association of the first type with at least one responder for each of a plurality of responsibilities. A step 171 comprises determining from the storage facility a further responder having an association of a second type with the responsibility, e.g. a further responder who is part of that team, for each responsibility without an association of the first type with at least one responder, i.e. for each responsibility that is currently not assigned. A step 173 comprises providing a further user interface to a further responder device of the further responder asking the further responder whether the further responder accepts the responsibility. An example of the user interface provided in step 173 is shown in Fig. 15.
[0074] A step 175, similar to step 163, comprises determining, after a time period At has passed, whether the further responder has accepted the responsibility. If the further responder has not accepted the responsibility within the time period At, the method further comprises a step 177, similar to step 171, of determining from the storage facility another responder having an association of a second type with the responsibility and a step 179, similar to step 173, of providing another user interface to another responder device of the other responder asking the other responder whether the other responder accepts the responsibility.
[0075] In the same or in a different embodiment, the method of Fig. 5 is used in a method of handling alarm messages, see Fig. 8. For example, the method of Fig. 5 may be used together with the method shown in Figs. 3a and 3b. As shown in Fig.8 and Fig. 3a, a step 81 comprises using a data receiver to receive an alarm message from a user device. Optional steps 83 and 85 are performed after step 81. Steps 181 and 183 are performed between steps 81 and 87. A step 181 comprises determining a responsibility based on the alarm message, e.g. it is determined that the user is a client of Team A. A step 183 comprises obtaining an identifier identifying at least one responder having an association of the first type with the responsibility from the storage facility, e.g. it is determined who from Team A is on duty. As shown in Fig.8 and Fig. 3a, a step 87 comprises using a data transmitter to transmit a dispatch message to at least one responder device of the at least one responder. The first responsibility may be associated on the storage facility with a user of a user device for transmitting an alarm message, e.g. clients may be allocated to different teams and this allocation may be stored in a database or in a file.
[0076] In the same or in a different embodiment, a step 185 comprises determining that a responder is occupied, see Fig.9. A step 187 comprises temporarily removing or temporarily hiding the association of the first type between the responder and the first responsibility on the storage facility. A responder may be determined to be occupied when he is attending to an urgent alarm, e.g. relating to a person that has difficulty breathing, a person that has an epileptic seizure or an aggressive person. A responder is generally not considered to be occupied when he is attending to a normal request for help (e.g. a request for water) or a normal call for help (e.g. a call for assistance going to the bathroom or getting out of bed). These steps can be included in the method of handling alarm messages of Figs. 3a and 3b. Steps 185 and 187 can be performed between steps 95 and 97, which are shown in Fig. 3b. Step 185 may comprise determining that the responder is occupied upon receiving an acceptance message from a responder device, the acceptance message being sent by the responder device in response to a dispatch message received by the responder device, and/or determining that the responder is occupied upon receiving a notification from an access control device indicating that the responder has accessed a property under control of the access control device, e.g. the room or house of a certain client. Temporarily hiding or temporarily removing an association may involve storing a flag, e.g. by setting an attribute value to 1, in the metadata associated with a responder, for example. This flag can be removed as soon as the responder is determined to be no longer occupied, e.g. by setting the attribute value to 0.
[0077] When another responder has to be found to take over or take on a certain responsibility, other responders may be asked one at a time or multiple responders may be asked at the same time. Preferably, a certain order is followed in which other responders are asked. This certain order can be reflected in a hierarchy as shown in Fig. 10. This hierarchy is preferably stored on the storage facility 29 and directly consulted, e.g. stored in a database or as one or more files. Fig. 10 reflects the second type of association between responsibilities and responders. Whether a responder has a first type of association with a responsibility, i.e. whether he is currently assigned to this responsibility, can be stored in metadata associated with the nodes of the hierarchy.
[0078] When another responder has to be found to take over or take on a certain responsibility, preferably, the most specialized responders 201a-201c, 202a-202c and 203a-203c of lowest level 207 are asked first. For example, responders 201a-201c may be part of Team A, responders 202a-202c may be part of Team B and responders 203a-203c may be part a Respiration team. Responders may have multiple responsibilities. In an embodiment, a person can be listed twice in the hierarchy of Fig. 10, e.g. once as responder 201a and once as responder 203a. If multiple responders are asked at the same time, these responders are preferably of the same level. In the example shown in Fig. 10, only the lowest level 207 comprises multiple responders per responsibility.
[0079] If no responder of lowest level 207 accepts a request to accept a certain responsibility, a responder from mid-level 206 is asked. For example, if none of responders 201b and 201c is able or willing to take over responsibility for Team A from responder 201 a, responder 201 is asked. Responder 201 may be the team leader for Team A, for example. Similarly, responder 202 may be the team leader for Team B and responder 203 may be the team leader for the Respiration team. If responder 201 is not able or willing to accept this responsibility, e.g. being assigned to handle alarms/care requests from Team A clients, this may be escalated to responder 200 of highest level 205. Responder 200 may be a manager responsible for a building or geographical region, for example. If responder 200 is not able or willing to accept this responsibility, it may even be escalated to an emergency service, e.g. a 112 or 911 caller helpline.
[0080] Fig. 11 shows a first example of a user interface screen provided on a responder device 31. The touchscreen 43 displays a list of the responsibilities in the shift of the responder currently using/logged in to the responder device 31. A first label 211 displaying “Team A” is associated with a button 215 which the responder can use to request this responsibility to end. A responsibility can only end if another or sufficient other responders are currently assigned to this responsibility. It may be detected before the user interface is provided that a responsibility has another or sufficient other responders assigned. In this case, the button associated with the responsibility may be labelled “End” instead of the “Request end” and it is then no longer needed to provide a user interface to other responders asking them to take over this responsibility. A second label 213 displaying “Respiration” is associated with a button 217 which the responder can use to request this responsibility to end. Furthermore, a button 218 labelled “Request end of shift” is provided. If the responder presses this button, the method of Fig. 6 is performed.
[0081] Fig. 12 shows a second example of a user interface screen provided on a responder device 31 with a touchscreen 43. This screen might be shown after a responder has pressed the button 215 on the screen shown in Fig. 11 and another responder was found to take over the responder’s Team A responsibility. Field 221a indicates to the responder “Your Team A responsibility has ended”. Compared to Fig.11, the first label 211 has moved from the list of the responsibilities in the shift of the responder to a list of responsibilities that the responder can take on. The first label 211 is now associated with a button 219 which the responder can press to take on the Team A responsibility again. If the responder presses this button 219, the method of Fig. 5 is performed.
[0082] Fig. 13 shows a third example of a user interface screen provided on a responder device 31 with a touchscreen 43. This screen might be shown after the responder has pressed the button 217 or the button 218 on the screen shown in Fig. 12 and another responder was found to take over the responder’s Respiration responsibility. Field 221b indicates to the responder “Your shift has ended”. This screen could be shown in step 153 of Fig. 6, for example.
[0083] Fig. 14 shows a fourth example of a user interface screen provided on a responder device 31 with a touchscreen 43. This screen might be shown to a another responder if the responder presses button 215 shown in Fig.11. Field 223a indicates to the other responder “James Becker wants to ends his Team responsibility. Can you take over this responsibility?”. The other responder can press button 225 to accept this request or button 227 to decline this request. This screen could be shown in step 161 of Fig. 6, for example.
[0084] Fig.15 shows a fifth example of a user interface screen provided on a responder device 31 with a touchscreen 43. This screen could be shown in step 173 of Fig. 7, for example. Field 223b indicates to the responder “Warning: Team A responsibility is unassigned! Can you take on this responsibility?”. Despite the fact that a responder cannot end a responsibility before it has been taken over or end a shift before all responsibilities in the shift have been taken over, it may happen that a responsibility is temporarily unassigned. This is detected by frequent checks and preferably results in a screen such as the one shown in Fig. 15 being shown on one or more responder devices. The responder can press button 225 to accept this request or button 227 to decline this request. If the responder presses button 227, the same or a similar screen is shown to a further responder.
[0085] Fig. 16 depicts a block diagram illustrating an exemplary data processing system that may perform the method as described with reference to Figs. 3a, 3b, 5, 6, 7, 8 and 9.
[0086] As shown in Fig. 16, the data processing system 300 may include at least one processor 302 coupled to memory elements 304 through a system bus 306. As such, the data processing system may store program code within memory elements 304. Further, the processor 302 may execute the program code accessed from the memory elements 304 via a system bus 306. In one aspect, the data processing system may be implemented as a computer that is suitable for storing and/or executing program code. It should be appreciated, however, that the data processing system 300 may be implemented in the form of any system including a processor and a memory that is capable of performing the functions described within this specification.
[0087] The memory elements 304 may include one or more physical memory devices such as, for example, local memory 308 and one or more bulk storage devices 310. The local memory may refer to random access memory or other non-persistent memory device(s) generally used during actual execution of the program code. A bulk storage device may be implemented as a hard drive or other persistent data storage device. The processing system 300 may also include one or more cache memories (not shown) that provide temporary storage of at least some program code in order to reduce the number of times program code must be retrieved from the bulk storage device 310 during execution.
[0088] Input/output (I/O) devices depicted as an input device 312 and an output device 314 optionally can be coupled to the data processing system. Examples of input devices may include, but are not limited to, a keyboard, a pointing device such as a mouse, or the like. Examples of output devices may include, but are not limited to, a monitor or a display, speakers, or the like. Input and/or output devices may be coupled to the data processing system either directly or through intervening I/O controllers.
[0089] In an embodiment, the input and the output devices may be implemented as a combined input/output device (illustrated in Fig. 16 with a dashed line surrounding the input device 312 and the output device 314). An example of such a combined device is a touch sensitive display, also sometimes referred to as a “touch screen display” or simply “touch screen”. In such an embodiment, input to the device may be provided by a movement of a physical object, such as e.g. a stylus or a finger of a user, on or near the touch screen display.
[0090] A network adapter 316 may also be coupled to the data processing system to enable it to become coupled to other systems, computer systems, remote network devices, and/or remote storage devices through intervening private or public networks. The network adapter may comprise a data receiver for receiving data that is transmitted by said systems, devices and/or networks to the data processing system 300, and a data transmitter for transmitting data from the data processing system 300 to said systems, devices and/or networks. Modems, cable modems, and Ethernet cards are examples of different types of network adapter that may be used with the data processing system 300.
[0091] As pictured in Fig. 16, the memory elements 304 may store an application 318. In various embodiments, the application 318 may be stored in the local memory 308, the one or more bulk storage devices 310, or separate from the local memory and the bulk storage devices. It should be appreciated that the data processing system 300 may further execute an operating system (not shown in Fig. 16) that can facilitate execution of the application 318. The application 318, being implemented in the form of executable program code, can be executed by the data processing system 300, e.g., by the processor 302. Responsive to executing the application, the data processing system 300 may be configured to perform one or more operations or method steps described herein.
[0092] Various embodiments of the invention may be implemented as a program product for use with a computer system, where the program(s) of the program product define functions of the embodiments (including the methods described herein). In one embodiment, the program(s) can be contained on a variety of non-transitory computer-readable storage media, where, as used herein, the expression “non-transitory computer readable storage media” comprises all computer-readable media, with the sole exception being a transitory, propagating signal. In another embodiment, the program(s) can be contained on a variety of transitory computer-readable storage media. Illustrative computer-readable storage media include, but are not limited to: (i) non-writable storage media (e.g., read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive, ROM chips or any type of solid-state non-volatile semiconductor memory) on which information is permanently stored; and (ii) writable storage media (e.g., flash memory, floppy disks within a diskette drive or hard-disk drive or any type of solid-state random-access semiconductor memory) on which alterable information is stored. The computer program may be run on the processor 302 described herein.
[0093] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
[0094] The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the implementations in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present invention. The embodiments were chosen and described in order to best explain the principles and some practical applications of the present invention, and to enable others of ordinary skill in the art to understand the present invention for various embodiments with various modifications as are suited to the particular use contemplated.
Claims (15)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NL2015959A NL2015959B1 (en) | 2015-12-15 | 2015-12-15 | User device, server, responder device and methods for handling alarm messages. |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
NL2015959A NL2015959B1 (en) | 2015-12-15 | 2015-12-15 | User device, server, responder device and methods for handling alarm messages. |
Publications (1)
Publication Number | Publication Date |
---|---|
NL2015959B1 true NL2015959B1 (en) | 2017-06-29 |
Family
ID=55858857
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
NL2015959A NL2015959B1 (en) | 2015-12-15 | 2015-12-15 | User device, server, responder device and methods for handling alarm messages. |
Country Status (1)
Country | Link |
---|---|
NL (1) | NL2015959B1 (en) |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6028514A (en) * | 1998-10-30 | 2000-02-22 | Lemelson Jerome H. | Personal emergency, safety warning system and method |
US20080122609A1 (en) * | 2006-11-29 | 2008-05-29 | Motorola, Inc. | Solution for automatically providing emergency responders with detailed information useful for responding to an emergency |
US20140025724A1 (en) * | 2012-07-19 | 2014-01-23 | Thomas Benjamin Granger | Personal safety communication system |
-
2015
- 2015-12-15 NL NL2015959A patent/NL2015959B1/en active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6028514A (en) * | 1998-10-30 | 2000-02-22 | Lemelson Jerome H. | Personal emergency, safety warning system and method |
US20080122609A1 (en) * | 2006-11-29 | 2008-05-29 | Motorola, Inc. | Solution for automatically providing emergency responders with detailed information useful for responding to an emergency |
US20140025724A1 (en) * | 2012-07-19 | 2014-01-23 | Thomas Benjamin Granger | Personal safety communication system |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10462277B2 (en) | Method and device for providing function of mobile terminal | |
KR102386398B1 (en) | Method for providing different indicator for image based on photographing mode and electronic device thereof | |
US10736510B2 (en) | Medical bracelet standard | |
US11862310B2 (en) | Proximity-based mobile-device updates of electronic health records | |
US10310717B2 (en) | Real-time problem reporting and alert system | |
TW201633226A (en) | Social reminders | |
US10602357B2 (en) | Mobile device-based community corrections supervision system | |
US11152085B2 (en) | Using sensors and location to trigger events and share data | |
JP2018509944A (en) | Wearable device connected to caregiver | |
US9754465B2 (en) | Cognitive alerting device | |
JP2021524961A (en) | Automated smartwatch assistance in case of cardiac arrest | |
US11138861B2 (en) | Easily customizable inhabitant behavioral routines in a location monitoring and action system | |
EP2830263B1 (en) | Electronic device and method for managing group e-mail | |
CN108322903A (en) | Emmergency call method, device, system and electronic equipment | |
US10856144B2 (en) | Method, server, and terminal for transmitting and receiving data | |
NL2015959B1 (en) | User device, server, responder device and methods for handling alarm messages. | |
NL1041620B1 (en) | Method of providing a user interface and server. | |
CN105989218A (en) | Information processing method and device | |
EP3280149B1 (en) | Method for providing additional contents at terminal, and terminal using same | |
TWI581648B (en) | Methods and systems for transmitting signals between electronic devices | |
JP7251476B2 (en) | CENTRAL PROCESSING UNIT AND METHOD OF MONITORED PERSON MONITORING SUPPORT SYSTEM AND MONITORED PERSON MONITORING SUPPORT SYSTEM | |
CN108431878A (en) | The convenient method and apparatus for transmitting neighbouring healthiness alarm via Local wireless network | |
TWI622024B (en) | Smart image-type monitoring alarm device | |
JP7264066B2 (en) | Monitored Person Monitoring Support System | |
JP5483631B2 (en) | Business support device, information communication terminal, and program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PD | Change of ownership |
Owner name: ZETACOM HOLDING B.V.; NL Free format text: DETAILS ASSIGNMENT: CHANGE OF OWNER(S), ASSIGNMENT; FORMER OWNER NAME: ASSIST BEHEER B.V. Effective date: 20191029 |