Patent Description:
Many Alarm Receiving Centers (ARC) for personal safety or care are based on technology that expects alarm events to be sent in as two parts. One with data and one with a voice call. The data parts generally minimally consist of who have trigged the alarm and what has happened. Additional information like position, text message and such are sometimes added.

There are an escalating number of alarm devices on the market. Said devices are utilized by broader groups of people and on a much higher requirement on short time from purchase to fully functional. Many ARC software are not possible to add and remove subscribers without manual steps making it impractical to turn to a broader customer groups that is used to buy a device or service and have it functional within minutes even on weekends.

Also the new type of devices in IOT are often not capable of doing telephone calls in PSTN (Public Switched Telephone Network), but are able to establish voice call over IP, VoIP, for example SIP or other VoIP technologies. The communication of the data part are also evolving quicker than the ARC software installations manage, making it hard for modern devices to connect to older installations of ARC software.

Further, the ARC software license models are often focused on number of subscribers, potentially making the business case for cheap subscriptions for large number of subscribers not feasible. The document <CIT> describes methods, systems, and apparatuses for asserting support for telematics capabilities in a vehicle emergency call system.

One object of the following disclosure is to present solutions of the problems of adapting old alarm receiving equipment of an Alarm Receiving Center, ARC, to more modern alarm sending devices.

According to one aspect of a provided solution, a method and embodiments of said method are disclosed, wherein said method is configured for grouping received alarm calls generated by or in connection to the same alarm event. Said alarm call is a voice call or/and data/text message, and said method is performed by an Alarm Receiving Centre, ARC, for enabling the reception of alarm calls sent by means of VoIP or SIP. Said method comprises the steps of receiving an alarm call, assigning an identified ARC Subscriber Identity to the alarm call, and checking if said ARC Subscriber Identity is already active by a current alarm call. If subscriber Identity is not active, i.e. in use; the method continues by creating a group and an alarm event docket, said group and docket being identified by the ARC Subscriber Identity. If the ARC Subscriber Identity is in use, the method continues by adding the alarm call to the group and corresponding alarm event docket identified by the ARC Subscriber Identity, and forwarding the group and alarm event docket by using the ARC Subscriber Identity to ARC staff/operator presentation unit GUI via a PSTN connection by means of the ARC Subscriber Identity, the forwarding comprising converting or bridging the alarm call between SIP/VoIP and PSTN formats.

According to another aspect of a provided solution, a receiving interface device and embodiments of said device are disclosed, wherein said device is configured to perform a method for grouping received alarm calls generated by or in connection to the same alarm event, wherein said alarm call is a voice call or/and data/text message. Said receiving interface device being a part of an Alarm Receiving Centre, ARC, for enabling the reception of alarm calls sent by means of VoIP or SIP. Said receiving interface device comprises said device comprising a processor in a processing circuitry is operative to perform the steps of the method configured for grouping received alarm calls generated by or in connection to the same alarm event.

According to another aspect of a provided solution, a computer program comprises computer program code which, when run in a processor of a receiving interface device being a part of an Alarm Receiving Centre, ARC, causes the ARC to perform the steps of the method configured for grouping received alarm calls generated by or in connection to the same alarm event.

According to another aspect of a provided solution, a computer program product storing a computer program comprising computer program code which, when run in a processor of a receiving interface device being a part of an Alarm Receiving Centre, ARC, causes the ARC to perform the steps of the method configured for grouping received alarm calls generated by or in connection to the same alarm event.

The foregoing, and other, objects, features and advantages of the present invention will be more readily understood upon reading the following detailed description in conjunction with the drawings in which:.

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular circuits, circuit components, techniques, etc. in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present invention with unnecessary detail.

<FIG> is a schematic illustration of an old fashioned alarm receiving center.

The Alarm Receiving Center( ARC) <NUM> comprises a central computer <NUM> for controlling the reception of alarm calls and route them to one of the ARC personal having one or more Graphical User Interfaces, GUIs <NUM>, <NUM> comprising displays <NUM> for displaying alarm messages and information related to each alarm call or alarm message. A GUI further comprises a phone <NUM> comprising a microphone and headset or equivalent, for handling voice calls. The central computer <NUM> routes incoming calls on an voice call input port <NUM> connected to a PSTN line <NUM> and data messages on a data input port <NUM> connected to a data line <NUM>. The central computer is able to handle the incoming data and calls by means of ARC software <NUM>, which is run and executed on a processor that will receive instructions and data from a read-only memory and/or a random access memory.

The ARC software <NUM> is also configured to handle one or more databases (DBs) <NUM>. The central computer is configured to store data and to collect data from said DBs by means of ARC software <NUM>.

The ARC software <NUM> routes the data via a data connection <NUM> to the display <NUM> and voice calls via a call connection <NUM> to the phone <NUM>.

The ARC <NUM> is configured to receive PSTN alarm calls from subscriber devices <NUM>, e.g. a phone, via a PSTN network <NUM>.

The ARC <NUM> is further configured to receive alarm calls via the Internet <NUM> transporting and routing data packets, wherein any of the transporter used may be, but not limited to UDP, TCP, SMS, HTTP, FTP, SIP, Serial port, and any of the protocol used may be, but not limited to IP, SIA, SOS_V4, CID, SCAlP, ESPA. The alarm calls are generated by a number of remote connectable devices, such as user equipment (UE), <NUM>, e.g. smartphones and other devices connectable to mobile telecommunications network, fire alarms <NUM>, surveillance devices <NUM> (both with or without cameras or video cameras), and Internet of Things (IoT) devices <NUM> configured to send both Voice over IP (VoIP) calls and text message alarm calls.

Many ARCs <NUM> for personal safety or care are based on technology that expects alarm events to be sent in as two parts.

The data parts generally minimally consist of who have trigged the alarm and what has happened. Additional information like position, text message and such are sometimes added. The "who" part is some kind of identifier that depending on systems and operators which may be called AlarmID, User ID, CallerID, Calling ID, etc. are also common names.

The ARC has a subscriber database <NUM> with mappings of Subscriber ID to telephone number expected as CallerID.

There are an escalating number of alarm devices on the market, they are utilized by broader groups of people and on a much higher requirement on short time from purchase to fully functional. Many ARC software are not possible to add and remove subscribers without manual steps making it impractical to turn to a broader customer groups that is used to buy a device or service and have it functional within minutes even on weekends.

Also the new type of devices in loT are often not capable of doing telephone calls in PSTN (Public Switched Telephone Network), but are able to establish voice call over IP, for example SIP or other VoIP technologies. The communication of the data part are also evolving quicker than the ARC software installations manage, making it hard for modern devices to connect to older installations of ARC software.

Thirdly the ARC software license models are often focused on number of subscribers, potentially making the business case for cheap subscriptions for large number of subscribers not feasible.

<FIG> is illustrating an alarm receiving center according to the invention.

One object of the following disclosure is to present solutions of the problems of adapting old alarm receiving equipment of an Alarm Receiving Center (ARC) to more modern alarm sending devices. Said object is achieved by means of a receiving interface device <NUM> and a method which will be described hereafter in more detail.

A receiving interface device <NUM>, integrated with the ARC <NUM>, is able to handle the incoming data and calls by means of interface software <NUM>, which is run and executed on a processor of a processing circuitry <NUM> that will receive instructions and data from a read-only memory and/or a random access memory. The receiving interface device <NUM> could also be considered to be a server application and/or a PSTN interface of an Alarm Receiving Centre, ARC. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), and flash memory devices; magnetic disks such internal hard disks and removable disks; magneto-optical disks; and CD-ROM (Compact Disc Read-Only Memory) disks. Any of the foregoing may be supplemented by, or incorporated in, specially - designed ASICs (Application Specific Integrated Circuits).

The software <NUM> is also configured to handle one or more databases, DBs, <NUM>. The receiving interface device <NUM> is configured to store data and to collect data from said DBs by means of interface software <NUM>, which is described and explained here below. With this mapping the software <NUM> can combine the incoming data message with the incoming telephone call and present them for the ARC personnel in a GUI <NUM>, <NUM>.

<FIG> is a flowchart of a method for grouping received alarm calls.

The method performed by a server application for grouping received alarm calls generated by or in connection to the same alarm event, said alarm call being a voice call or/and data/text message. Said server application being an PSTN interface of an Alarm Receiving Centre, ARC, for enabling the reception of alarm calls sent by means of VoIP or SIP. The method comprises the steps of:.

The method will now be described step by step with reference to <FIG> and <FIG>. The interface device <NUM> is configured to wait for incoming alarm calls in step S110:.

In step S110, the receiving interface device <NUM> is in a standby mode for the method, waiting for an alarm call to be received. When an alarm call is received, the receiving interface device <NUM> performs S140:.

The received alarm call has a caller identity, which the interface device <NUM> is configured to check if a corresponding ARC Subscriber Identity in the stored the database <NUM>. The subscriber database <NUM> comprises mappings of an.

ARC SubscriberlD to telephone number expected as caller identity, CallerlD. The interface device <NUM> is further configured to perform S150:.

The interface device <NUM> is configured to check in the database <NUM> whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use. For each caller identity and subscriber Identity in the database <NUM> it is recorded whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use and when a ARC Subscriber Identity was activated and inactivated. The interface device <NUM> is configured to update whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use and when an ARC Subscriber Identity was activated and inactivated. If the identified ARC subscriber Identity is not in use, No, the interface device <NUM> is configured to perform step S160:.

Thus, the interface device <NUM> is configured to register an alarm by creating a group and an alarm event docket, said group and alarm event docket being identified by the ARC Subscriber Identity. Said group and alarm event docket are stored by the interface device <NUM> to be used if a new alarm call is received, S110, which is identified and assigned the same ARC subscriber identity. In that case, when the interface device <NUM> performs S150 (checking if said ARC Subscriber Identity is already active by a current alarm call?), the result of the test is yes. When the test in S150 is yes, the alarm is already registered in the alarm receiving center by the interface device <NUM>, and the interface device is configured to perform step S170:.

In this way is every received alarm call grouped to an existing alarm and registered in an alarm event docket by means of the interface device <NUM>. When an received alarm call has been handled by the interface device and organized in a group and alarm event docket, the interface device is configured to perform step S180:.

The docket comprises information, e.g. who have trigged the alarm and what has happened. Additional information like position, text message and such are sometimes added to the docket. Said docket is preferably stored in the database <NUM>.

<FIG> is a flowchart of an embodiment of the method for grouping received alarm calls.

In step S110, the receiving interface device <NUM> is in a standby mode for the method, waiting for an alarm call to be received. When an alarm call is received, the receiving interface device <NUM> performs S120:.

The received alarm call has a caller identity, which the interface device <NUM> is configured to check if a corresponding Subscriber Identity in the stored the database <NUM>. The subscriber database <NUM> comprises mappings of an ARC SubscriberlD to a telephone number expected to be a caller identity, CallerlD. If no ARC subscriber identity is found, No, the interface device <NUM> is configured to perform S122:.

If a corresponding ARC subscriber identity is found, yes, the interface device <NUM> is configured to perform S130:.

If data message is received on a data message input port, yes, the interface device <NUM> is configured to perform a method S200. Or if data message is not received, No, the interface device <NUM> is configured to perform S140:.

The interface device <NUM> is further configured to perform S150:.

The interface device <NUM> is configured to check in the database <NUM> whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use. For each caller identity and ARC subscriber Identity in the database <NUM> it is recorded whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use and when an ARC Subscriber Identity was activated and inactivated. The interface device <NUM> is configured to update whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use and when an ARC Subscriber Identity was activated and inactivated. If the identified subscriber Identity is not in use, No, the interface device <NUM> is configured to perform step S160:.

In this way is every received alarm call grouped to an existing alarm and registered in an alarm event docket by means of the interface device <NUM>. When a received alarm call has been handled by the interface device and organized in a group and alarm event docket, the interface device is configured to perform step S180:.

Thus, with this mapping and grouping of the incoming data message and the incoming telephone call and present them for the ARC personnel in the GUI <NUM>, <NUM>.

<FIG> is a flowchart illustrating an embodiment of step S160 in the invented method. Said step S160 is situated between step S150 and S180 as illustrated in <FIG>.

The method may further comprise, if the alarm call comprises an alarm message, then at creating, S160, a group and an alarm event docket, the step S162 is performed:.

The receiving interface device <NUM> is therefore configured to add information from an alarm message belonging to the ARC subscriber identity and additional information belonging to the ARC subscriber identity from information sources and servers to the alarm event docket for enabling the ARC operator to find additional information about the actual alarm event. Some ARC subscriber identity in the database <NUM> is stored together with one or more addresses and/or links to information sources and servers having additional information about the caller of an alarm call. The interface device <NUM> is configured to use said links and addresses to be able to get said information.

<FIG> is a flowchart illustrating an embodiment of step S180 in the invented method. Said step S180 is situated between steps S160, S170 and S110 as illustrated in <FIG>.

The step of forwarding, S180, the group and alarm event docket further comprises a step <NUM>:.

The interface device <NUM> is configured to convert or bridge the alarm call between Session Initiation Protocol supported voice over IP (SIP/voip) format and Public Switched Telephone Network format (PSTN).

The interface device <NUM> may be configured to route a received call through a certain line <NUM> or <NUM> to the central computer <NUM> (see <FIG>), by changing the A-number of the call, such as the CaIIID or DialerlD, to match the expected CalllD or Dialer! D for the used ARC Subscriber ID for the specific alarm event.

<FIG> is a flowchart of a method S200 for handling data messages received on data message input port, said method comprising the steps of:.

The method will now be described step by step with reference to <FIG> and <FIG>.

As the data message does not contain any regular CallerlD, the interface device <NUM> is not able to find a corresponding ARC Subscriber ID in the database <NUM> of the ARC Subscriber ID. The interface device <NUM> is configured to perform step S210:.

The interface device S200 is configured to search for an ARC Subscriber Identity in the database <NUM>. For each ARC subscriber Identity in the database <NUM>, it is recorded whether the ARC subscriber Identity is active, i.e. in use, or inactive, i.e. not in use and when an ARC Subscriber Identity was activated and inactivated. Thus, the interface device S200 is configured to select the ARC subscriber identity that has been inactivated for a time, e.g. such as a day. The longer time the ARC subscriber identity has been inactivated the better it is. A long time without being used is an indication that the ARC Subscriber Identity is more or less free to use.

The interface device S200 is then configured to perform steps S220 and S230:.

Thus, the interface device <NUM> is configured to register the received data message by creating a group and an alarm event docket, said group and alarm event docket being identified by the ARC Subscriber Identity.

The interface device S200 is then configured to perform step S240:.

Said group and alarm event docket are stored by the interface device <NUM> in the database <NUM>.

Thus, with this mapping and grouping of the incoming data message, it is forwarded via the central computer <NUM> and presented for the ARC personnel in the GUIs <NUM>, <NUM>.

The invention may be implemented in digital electronically circuitry, or in computer hardware, firmware, software, or in combinations of them. Apparatus of the invention may be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by a programmable processor; and method steps of the invention may be performed by a programmable processor executing a program of instructions to perform functions of the invention by operating on input data and generating output.

The invention may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language.

Generally, a processor will receive instructions and data from a read-only memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), and flash memory devices; magnetic disks such internal hard disks and removable disks; magneto-optical disks; and CD-ROM (Compact Disc Read-Only Memory) disks. Any of the foregoing may be supplemented by, or incorporated in, specially -designed ASICs (Application Specific Integrated Circuits).

It is therefore provided a receiving interface device <NUM> configured to perform a method S100 for grouping received alarm calls generated by or in connection to the same alarm event. Said alarm call is a voice call or/and data/text message, and said receiving interface device <NUM> is a part of an Alarm Receiving Centre, ARC, <NUM> for enabling the reception of alarm calls sent by means of VoIP or SIP. Said receiving interface device comprises said device comprising a processor in a processing circuitry <NUM> being operative to perform the steps of the method S100 as described above.

It is further provided a computer program comprising computer program code which, when run in a processor of a receiving interface device being a part of an Alarm Receiving Centre, ARC, <NUM> causes the ARC to perform the steps of the method S100 as described above.

A computer program product storing a computer program comprising computer program code which, when run in a processor of a receiving interface device being a part of an Alarm Receiving Centre, ARC, <NUM> causes the ARC to perform the steps of the method S100 as described above.

Claim 1:
Method for grouping received alarm calls generated by or in connection to the same alarm event, said alarm call being a voice call or/and data/text message, said method being performed by an Alarm Receiving Centre, ARC, for enabling reception of alarm calls sent by means of Voice over Internet Protocol, VoIP, or Session Initiation Protocol, SIP, wherein said method comprises the steps of:
- receiving (S110) an alarm call;
- assigning (S140) an identified ARC Subscriber Identity to the alarm call;
- checking (S150) if said ARC Subscriber Identity is already active by a current alarm call;
if ARC subscriber Identity is not in use:
- creating (S160) a group and an alarm event docket, said group and docket being identified by the ARC Subscriber Identity; or,
if the ARC Subscriber Identity is in use:
- adding (S170) the alarm call to the group and corresponding alarm event docket identified by the ARC Subscriber Identity;
- forwarding (S180) the group and alarm event docket by using the ARC Subscriber Identity to ARC staff presentation unit Graphical User Interface, GUI, via a Public Switched Telephone Network, PSTN, connection by means of the ARC Subscriber Identity, the forwarding comprising converting or bridging the alarm call between SIP/VoIP and PSTN formats.