Patent Application
20170046944
This description relates to wireless communications systems and methods, and in particular to systems and methods in which multiple parties are alerted to an event.
Alert systems today can be as simple as a door bell to a more sophisticated system that transfers data, audio or images. Such systems rely on communications to transmit alerts either by wire or wireless from a trigger point to a base system. For example a conventional wireless door bell usually has a trigger button and a base station installed at a location where the alerts can be heard. In such a setting a door bell is unlikely to be heard if the user is away from the range of the base system. Also, in the example of a conventional door bell, the alert takes the form of a sound that will be heard by all users in a vicinity of the door base station. Thus, the alert lacks privacy where only selected users are desired to receive a particular alert. Furthermore, such an alert system does not provide confirmation that someone is responding to it. Such issues can be inconvenient in a residential setting, but take on even more importance when an alert system is used in an office or other business areas such as restaurants or hospitals.
According to an example embodiment is a multi-device alert notification system that includes a trigger device that has a low energy wireless transmitter for broadcasting an alert message in unlicensed spectrum for mobile user devices when activated, and a remote server system storing information that identifies the trigger device, the remote server being configured to receive, through a network, an alert notification message from each of a plurality of mobile user devices, each alert notification message indicating that the mobile user device has received the alert message from the trigger device and including a unique trigger device identifier and a unique user identifier associated with the mobile user device. The remote server system receives, through the network, an alert acceptance request message from one of the mobile user devices that includes the unique trigger device identifier and the unique user identifier associated with the mobile user device and sends notification messages to at least the mobile user devices that did not send the alert acceptance request message indicating that the alert message from the trigger device has been accepted by one of the plurality of mobile user devices.
According to example embodiments is a method for notifying multiple devices of a received alert, including receiving at a server system, through a network, an alert notification message from each of a plurality of mobile user devices, each alert notification message indicating that the mobile user device has received an alert message from a trigger device and including a unique trigger device identifier and a unique user identifier associated with the mobile user device. The method also includes receiving at the server system, through the network, an alert acceptance request message from one of the mobile user devices that includes the unique trigger device identifier and the unique user identifier associated with the mobile user device; and sending, from the server system, notification messages to at least the mobile user devices that did not send the alert acceptance request message, the notification messages indicating that the alert message from the trigger device has been accepted by one of the plurality of mobile user devices.
According to example embodiments, there is also provided a method of processing alert notifications at a mobile user device, including: receiving, in unlicensed spectrum through a low energy wireless receiver, an alert message broadcast from a trigger device, the alert message comprising a unique trigger device identifier; sending, to a remote server system, a user notification when the alert message is received from the trigger device; and sending, to the remote server system, a further user notification when the mobile user device receives a user input indicating user acceptance of the alert message.
Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, and in which:
Similar reference numerals may have been used in different figures to denote similar components.
In at least some example embodiments, trigger devices 100 and mobile devices 300 each incorporate a low energy communications radio for communication in open, unlicensed frequency spectrum such as the ISM spectrum. In some example embodiments, the low energy communications radio is a Bluetooth™ compliant low energy device. As known in the art, Bluetooth low energy devices can be defined in different roles. Two roles, which are capable of making two-way communications and thus can operate in a connectable role manner, include the “peripheral” and “central” device roles. A device that can make a two-way connection can act as a peripheral role device that is an advertiser (e.g. sends out advertising information in the form of advertising packets) and operates as a slave in a connection. This could be, for example, a health thermometer or a heart rate sensor. A central device is a device that can make connections to other devices and which scans for advertising information from advertisers and can initiate connections; such a device operates as a master in one or more connections. Examples of devices that are capable of performing the central device role are smart phones and computers. Thus, two types of Bluetooth low energy device roles used for establishing two-way connections are the peripheral and the central roles.
Two Bluetooth device roles that are only capable of making one-directional communication include the “broadcaster” device role and the “observer” device role. A broadcaster, for example, is a non-connectable advertiser such as a temperature sensor that broadcasts the current temperature. A one-directional Observer scans for advertising information, but cannot initiate connections—for example, a remote display that receives the temperature data from a temperature broadcaster and presents it visually.
In both the broadcaster and peripheral roles the same type of advertising information is transmitted with the exception of one specific flag in the advertising packet that indicates if the advertiser device is connectable or non-connectable. A peripheral role device can store its data according to the Bluetooth Smart Technology specifications. In this manner a peripheral role device implements a GENERIC ATTRIBUTE PROFILE (GATT) Server, which defines the architecture for how data is stored and exchanged between two or more devices.
In example embodiments, the trigger device 100 is a dedicated trigger device such that its primary function is to provide a trigger signal upon the occurrence of a predetermined trigger action—for example the device 100 in
The bus 318 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, video bus, or the like. The CPU 310 may comprise any type of electronic data processor. The memory 320 may comprise any type of system memory such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), a combination thereof, or the like. In an embodiment, the memory 320 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.
The I/O interface 314 may provide interfaces to couple input and output devices to the bus 318. Examples of input and output devices may include a display (with or without touch screen capability), a mouse, touchpad, speaker, microphone, accelerometer and keyboard.
The network interface 312 may allow the device 300 to communicate via one or more networks 315, which may include wired and wireless communications links. In an embodiment, the network interface 312 provides access to a wireless wide area network (WAN) and/or to a cellular network, such as Long Term Evolution (LTE), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), and Global System for Mobile Communications (GSM) networks, and to WiFi networks. In an embodiment, the device 300 is coupled to a local-area network or a wide-area network for data processing and communications with remote devices, such as other processing units, the Internet, remote storage facilities, or the like.
In the illustrated embodiment, Bluetooth radio 316 allows mobile device 300 to communicate with trigger devices 100 as will be explained in greater detail below. In example embodiments, the trigger device 100 is configured to operate as a Bluetooth central device or Bluetooth observer device.
In example embodiments, device 300 includes applications stored in memory 320 that provide instructions for the CPU 310 to enable to device 300 to perform its intended functions. Such applications may be preloaded on the device 300 or downloaded to the device through one or more of the device interfaces. In an example embodiment these applications include notification application 321D that configures the device 300 to perform the user device-side functions described herein that relate to notification system 100.
User device 300 may for example take the form of a smart phone, tablet computer or other mobile communications device, or could be a stationary user computer.
In example embodiments, remote server 200 and notification servers 400 could have an internal processing system 301 similar to that shown in
In example embodiments, trigger devices 100 are each associated with a unique user group 210 that is tracked and maintained as user group data 212 by remote server 200. Each user group 210 for a trigger device 100 includes subscribers that includes an owner mobile device 300-O and typically will also include a plurality of follower mobile devices 300-F. An example of creating a user group for a trigger device 100 will now be described according to example embodiments with reference to
As an initial step, the device user is required to set up a “Notification System Account”. Any number of different procedures can be used to set up an account—in the illustrated embodiment interface screen 400 includes a user selectable “Create New Account” option 401. In response to user selection of “Create New Account” option 401, the device 300 displays the user interface screen 550 (
When remote server 200 receives the request it creates and stores a user account record that includes the provided information for the newly created account. The remote server 200 then sends an email message to the user's email address that includes an authentication link. On the device side, as shown in
Once a user selects the displayed ID record 703, device 300 sends an information request over network 315 to server 200 that includes ID information for both device 300 and the trigger device 100. Server 200 responds over network 315 with additional information about the trigger device 100 that indicates whether trigger device 100 is registered with the server and “owned” by a user or not. As shown in
Returning to
As shown in
Each user device 300-O/300-F stores a local list of trigger devices 100 that the device is registered with as an owner or follower that is used to populate the Device List interface 701.
Operation of notification system 90 according to example embodiments will now be described in greater detail. As noted above, in example embodiments, the trigger device 100 of the alert notification system 90 is equipped with a Bluetooth low energy radio 120 that acts as a Bluetooth peripheral or broadcaster. The trigger device 100 includes one or more trigger elements 110 that are electrically connected to a microcontroller (MCU) 121 of the trigger device 100. The trigger elements 110 may for example be elements that are activated mechanically, magnetically or by other means. Once the trigger element 110 of a trigger device 100 is activated, the trigger device starts broadcasting for a predetermined time (Alert Period) of short duration, and goes back to inactive state till the trigger element 110 is activated again. The trigger device 100 can transmit short data packets to a coverage area 150 and, if configured as a peripheral, also receive short data packets. In example embodiments, the information broadcast by the trigger device 100 takes the form of short advertising data packets 500 (see
As noted above, each trigger device 100 is identified uniquely by a device identifier 704. The device identifier 704 can be the peripheral local name. In example embodiments, a group of trigger devices can also share an identifier [chiekoo bell, chiekoo charm, . . . Etc.] (unique shared identifier 705), which for example may be limited to 16 bytes in length. In example embodiments, the trigger device 100 always broadcasts its shared unique identifier 705 and device identifier 704 when it is triggered as part of advertising packet transmissions. In this regard,
In an example embodiment, the unique device identifier 704, shared ID 705 and custom data 706 used for each trigger device 100 is configured when the device is being assembled and provided prior to device deployment to the database maintained by remoter server 200. In one example, the unique device identifier 704 is formed from a combination of a selected part of the MAC address 502 for the trigger device 100 and part or all of a model number for the trigger device 100. In some embodiments where a trigger device 100 includes multiple trigger elements 110, the trigger device 100 may have plurality of unique device identifiers 704 each corresponding to a specific trigger element 110 such that user devices 300 can distinguish which trigger element has been activated. In some examples, a trigger device 100 may have only one unique device identifier 704, with trigger element specific information included in custom device data 706.
In some example embodiments, the MAC advertisement address 502 may be used as the unique device identifier—however some user devices 300 may be configured by the device operating system to hide the MAC address 502, in which case use of the actual advertisement packet data space 503 as described above to send a device readable unique trigger device identified provides an efficient solution. By way of example, Apple iOS, at the time of writing this disclosure, hides the address field 502 from high level applications. Accordingly, in at least some example embodiments, the trigger device 100 does not rely on the MAC address as described in BLE transmission protocol to identify a trigger device 100 directly but instead sends a unique identifier 704 in the advertisement packet 503. In some examples, the device unique identifier 704 is the long name of the device 100 identified by standard byte “0x09” (“Type Local Name”) or shortened name of the device identified by standard byte “0x08” in a Bluetooth advertisement packet.
As noted above, in example embodiments a trigger device 100 will transmit alert notifications 500 in the form of bursts of two successive advertisement packets 503-1, 503-2 when trigger element 110 is activated, one packet including unique device identifier 704, and the other packet including the shared identifier 705. In example embodiments the shared identifier 705 is used to distinguish peripheral or broadcast devices that are part of or intended to be part of notification system 90 from other third party devices. Accordingly, the notification application 321D on device 300 can use the shared identifier to quickly determine if a received advertisement packet can be ignored or must be processed further.
As indicated at Action 251, once a alert notification 500 broadcast from a trigger device 100 with a known shared unique identifier 705 is found, the user device 300 compares the unique device identifier 704 with records saved in a local database or, via network 315, a remote database 212. If a matching record found, the user device 300 then determines, as indicated by Action 252, if the received alert is a new alert or subsequent packets in an already received alert. In this regard, user device 300 compares a time stamp of the received alert packets with the time of the last alert time stamp recorded by device 300 to determine if the differences is less than or greater than a known alert transmission period. If the time difference is outside of the known alert period (i.e. the amount of time that trigger device 100 repeatedly sends packets 503-1, 503-2 for a specific trigger event, which could for example be several seconds to allow a sleeping device to wake up; in at least some example embodiments the alert period is less than one minute), then the user device 300 will determine that it is handling a new alert notification, otherwise the user device 300 will conclude that the alert notification is already being processed. In the event that received alert is determined to be a new alert notification, the user device 300 will record a time stamp and device identifier locally (Action 255) and also send an alert notification over network 315 (Action 256) to remote server 200 which in turn logs the new alert request (Action 257), including updating an alert history record for the trigger device 100 in remote user group database 212 (Action 258). The alert history record at least contains a timestamp, unique trigger device identifier 704 and one or both of a user device identifier for user device 300 or an user account identifier for the person using the device 300 (user device identifier or user account identifier being interchangeably referred to as user identifier in this document).
As noted above, in example embodiments multiple user devices 300 are located within the Bluetooth coverage area 150 of a trigger device 100. Accordingly, for every new alert notification 500, a request to log an alert history record on a remote server 200 (Actions 256, 257, 258) will be initiated by each user device 300 that detects the new alert notification 500. In example embodiments, the remote server 200 compares the last timestamp for the alert received from a particular trigger device 100, identified by its device identifier 704, with current time in the remote server 200. If the difference between the last time stamp and current time is greater than a predetermined alert period then the remote server will log the record with the current time on the server 200 as the time stamp of the record. The remote server 200 continues to log each new alert from different requesting user devices 300 and aggregates these new alerts such that they can be identified together as aggregated new alerts all associated with originating alert notification 500.
Turning again to the functionality of user devices 300, after detecting a new alert notification as per Action 252, the user device 300 issues a local notification (Action 253) to alert a user of the device of the new notification alert 500. Such an alert can, for example, take the form of one or more of an audible alert, a physical (vibration) alert, or a visible alert. In this regard,
If however, the remote server 200 determines, in response to an “alert acceptance request” 520 that the alert has not been accepted by another user and has not expired, the remote server 200 will assign the alert to the requesting user device 300 with the result that the user acceptance will be logged in database 212 and a reply message 510 to the requesting user device 300 will be sent that advises the device of its acceptance. The user device 300 will in turn inform its user—for example dialog box 285 could include the message “Acceptance of this alert by you is confirmed”.
In addition to sending a specific message to the accepting user device, in example embodiments, the remote server 200 may also send remote notification to inform all other users—owner and followers—of trigger device 100 that the alert 500 has been accepted by a user (Actions 264, 265 and 266). In order to inform all other users—owner and followers—that alert 500 has been accepted, alert acceptance notification messages 530 are prepared by the remote server 200 for each of the user devices 300-O, 300F that are identified as part of the user group for the trigger device 100. In some example embodiments the alert acceptance notifications are only generated for user devices 300 in the user group that originally advised the server 200 that they received the corresponding alert message 500. Each alert acceptance notification message 530 includes information identifying the trigger device 100, a user identifier to identify the intended recipient, and may also include the user identifier for the accepting device. The structure and delivery method used for acceptance notification message 530 may vary depending on type of operating system installed on the receiving user device 300. For example if the operating system is the Apple iOS™ then remote server 200 prepares acceptance notification message 530 as a data packet that is then sent over network 315 to an Apple remote notification server 400 which in turn will send (push) the packet 540 to the end user device 300 over network 315 using a remote notification protocol (Action 266). The notification messages 530 sent by the remote server 200 to matching operating system remote notification servers 400 will reach the intended recipient user devices as long as such users are signed up for such notifications with their corresponding remote notification server 400. This sign up will be performed by the application 321D on the user device 300 at least once before using the system 90.
In example embodiments, the device application 321D maintains a log of all alerts received by the device 300 and who has accepted the alerts. In this regard,
In some example embodiments, alert acceptance notifications 530 may be sent directly to devices 300 rather than through notification servers 400.
An example application of alert notification system will be described with reference to
In the embodiment of
In some examples location 2000 is a establishment with change rooms and trigger devices 100 can be used by change room occupants to summon a change room attendant. In some examples location 2000 is a restaurant and trigger devices 100 can be used by diners to call a server to their table. In some examples location 2000 is a stadium or entertainment venue and trigger devices 100 can be used by customers to call a server to their location. In some examples location 2000 is a health care facility and trigger devices 100 can be used by residents or patients to call personnel server to their location. In some examples location 2000 is a residence and trigger devices 100 can be used as door bells, with the residents using their smart phones as user devices 300. In some example embodiments, the trigger elements 110 include motion sensors.
The information logged at server 200 can be periodically used to determine employee performance and customer service metrics. In some example's additional alerts could be provided so that server 200 automatically notifies owner user device 200 if services thresholds are not being met—for example when new alerts are not claimed by any user for a predetermined duration, or if some users are logged as responding to too few or too many alerts within predefined durations.
While the present disclosure is described, at least in part, in terms of methods, a person of ordinary skill in the art will understand that the present disclosure is also directed to the various components for performing at least some of the aspects and features of the described methods, be it by way of hardware components, software or any combination of the two. Accordingly, the technical solution of the present disclosure may be embodied in the form of a software product. A suitable software product may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer readable medium, including DVDs, CD-ROMs, USB flash disk, a removable hard disk, or other storage media, for example. The software product includes instructions tangibly stored thereon that enable a processing device (e.g., a personal computer, a server, or a network device) to execute examples of the methods disclosed herein.
The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described example embodiments are to be considered in all respects as being only illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, features suitable for such combinations being understood within the scope of this disclosure.
All values and sub-ranges within disclosed ranges are also disclosed. Also, while the systems, devices and processes disclosed and shown herein may comprise a specific number of elements/components, the systems, devices and assemblies could be modified to include additional or fewer of such elements/components. For example, while any of the elements/components disclosed may be referenced as being singular, the embodiments disclosed herein could be modified to include a plurality of such elements/components. The subject matter described herein intends to cover and embrace all suitable changes in technology.
Certain adaptations and modifications of the described embodiments can be made. Therefore, the above discussed embodiments are considered to be illustrative and not restrictive.
