Method and device for automated provisioning of data from multiple sensors within an emergency services network

Abstract

The embodiment of the invention relates to a method and a system for automatic provisioning of data from a plurality of sensors in an emergency service network. A method at a supplemental data provider within an emergency service network, the method comprising: receiving a message at the supplemental data provider, the message comprising an identifier and event data; in response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource associated with the identifier; receiving an access request for supplemental data associated with the resource from an emergency service provider; and in response to receiving the access request, providing a response with the supplemental data.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511293791.6 (22) Application Date 2020.04.03 (62) Divisional Application Data 202080097591.2 2020.04.03 (71) Applicant Blackberry Ltd. Address Ontario, Canada (72) Inventors R. F. Suzuki Taku S. McCann (74) Patent Agency King & Wood Mallesons, Beijing 11256 Patent Attorney Wu Yankun (51) Int.Cl. H04W 4 / 90 (2018.01) H04W 4 / 80 (2018.01) H04W 4 / 02 (2018.01) H04L 67 / 12 (2022.01) H04L 67 / 02 (2022.01) (54) Invention Title: Method and System for Automatic Provisioning of Data from Multiple Sensors within an Emergency Service Network (57) Abstract: Embodiments of this disclosure relate to a method and system for automatic provisioning of data from multiple sensors within an emergency service network. A method at a supplementary data provider within an emergency service network, the method comprising: receiving a message at the supplementary data provider, the message including an identifier and event data; in response to receiving the message, creating a resource at the supplementary data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency service provider for supplementary data associated with the resource; and in response to receiving the access request, providing a response having the supplementary data. Claims 1 page, Description 28 pages, Drawings 6 pages, CN 121174131 A 2025.12.19 CN 1 21 17 41 31 A 1. A method at a supplemental data provider within an emergency services network, the method comprising: receiving a message at the supplemental data provider, the message including an identifier and event data; in response to receiving the message, creating a resource at the supplemental data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency services provider for supplemental data associated with the resource; and in response to receiving the access request, providing a response having the supplemental data. Claims 1 / 1 Page 2 CN 121174131 A Method and System for Automatic Supply of Data from Multiple Sensors within an Emergency Service Network

[0001] Divisional Application Description

[0002] This application is a divisional application of Chinese Patent Application No. 202080097591.2, filed on April 3, 2020, entitled "Method and System for Automatic Supply of Data from Multiple Sensors within an Emergency Service Network".Technical Field

[0003] This disclosure relates to emergency service response, and more particularly to the supply of supplemental data to emergency service providers. Background Art

[0004] Emergency services are typically contacted using emergency numbers (such as 911 in North America or 112 in Europe) and other options. However, such services were initially built on heterogeneous and isolated networks such as analog or voice systems, and therefore next-generation 911 (NG911) or next-generation 112 (NG112) systems are being introduced. These next-generation systems allow emergency service IP networks to deliver voice, video, text, and data calls to public safety answering points.

[0005] With the advent of such next-generation services, emergency service providers can benefit from access to supplemental data, for example, from Internet of Things (IoT) endpoints, in response strategies and execution. However, current NG112 or NG911 emergency platforms do not support access to data that is relevant to a specific event and originates from IoT devices and sensors. In order to utilize data from such IoT devices and sensors deployed near or related to the event area, there is a need to enhance the emergency service architecture to efficiently identify and access these data sources.

[0006] The present disclosure will be better understood with reference to the accompanying drawings, in which:

[0007] Figure 1 is a block diagram from the European Telecommunications Standards Institute (ETSI) illustrating an emergency services team accessing a pre-deployed Internet of Things (IoT) device;

[0008] Figure 2 is a block diagram illustrating an example next-generation 112 architecture;

[0009] Figure 3 is a block diagram illustrating an example next-generation 911 architecture;

[0010] Figure 4 is a block diagram illustrating the role of a clearinghouse in an emergency 911 architecture;

[0011] Figure 5 is a block diagram illustrating an example emergency services architecture model according to an embodiment of the present disclosure;

[0012] Figure 6 is a data flow diagram illustrating the data flow when the device initiating an emergency call identifies a supplementary data provider;

[0013] Figure 7 is a data flow diagram illustrating the data flow when an enhanced supplementary data repository identifies a supplementary data provider;

[0014] Figure 8 is a data flow diagram illustrating the data flow when an emergency services provider identifies a supplementary data provider;

[0015] Figure 9 is a block diagram of a simplified electronic device according to one embodiment that can be used with the methods and systems described herein; and

[0016] Figure 10 is a block diagram of a mobile device that can be used with the methods and systems described herein.Specification 1 / 28 Page 3 CN 121174131 A Detailed Description

[0017] This disclosure provides a method at a supplementary data provider within an emergency services network, the method comprising: receiving a message at the supplementary data provider, the message including an identifier and event data; in response to receiving the message, creating a resource at the supplementary data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency services provider for supplementary data associated with the resource; and in response to receiving the access request, providing a response having the supplementary data.

[0018] This disclosure also provides a supplementary data provider within an emergency services network, the supplementary data provider comprising: a processor; and a communication subsystem, wherein the supplementary data provider is configured to: receive a message including an identifier and event data; in response to receiving the message, creating a resource at the supplementary data provider based on the event data, the resource being associated with the identifier; receiving an access request from the emergency services provider for supplementary data associated with the resource; and in response to receiving the access request, providing a response having the supplementary data.

[0019] This disclosure also provides a computer-readable medium for storing instruction code that, when executed by a processor of a supplemental data provider within an emergency services network, causes the supplemental data provider to: receive a message including an identifier and event data; in response to receiving the message, create a resource at the supplemental data provider based on the event data, the resource being associated with the identifier; receive an access request from the emergency services provider for supplemental data associated with the resource; and in response to receiving the access request, provide a response with the supplemental data.

[0020] Currently, there is no universal or standardized solution for sharing relevant data generated by Internet of Things (IoT) devices or other data sources with emergency services. Such data sources can be connected to public or private communication networks and cloud-based applications, but are not available for emergency platforms such as Next Generation 911 (NG911) or Next Generation 112 (NG112).

[0021] Specifically, ETSI has established the Emergency Communications Special Committee (SC) (EMTEL), which has studied use cases involving IoT devices in emergency supply. The group released technical report ETSIEMTEL TR 103 582 in July 2019: “Study of use cases and communications involving IoT devices in provision of emergency situations” v.1.1.1, which includes eight use cases and their derived requirements.

[0022] Multiple deployed IoT devices, sensors, or actuators are not intended or designed for public safety purposes and do not require dedicated emergency features or connectivity to perform their primary functions while operating for consumer- or business-oriented applications in domains such as smart cities or buildings, automotive, transportation, home or industrial IoT, connected to healthcare or agriculture, and other options.

[0023] In one use case, an emergency services team can access pre-deployed IoT device controls or data. According to this disclosure, an emergency services team includes members who manage and coordinate emergency services operations and may include members of emergency personnel in or near the incident area. Examples include first responders, such as firefighters, police, technical and medical personnel, etc. For example, refer now to FIG1. ​​In the embodiment of FIG1, IoT devices (such as mobile phone 112, alarm system 114, temperature monitoring system 116, camera 118, and other options for IoT devices) can communicate with IoT network 122 via access point 120. In this case, IoT service platform 130 and devices may be pre-deployed to communicate with emergency service decision-makers 140. Therefore, in emergency situations, in private or public buildings or in areas with pre-deployed IoT-based security systems, IoT devices and building security systems can provide additional useful information to emergency service teams.

[0024] Various use cases exist for such pre-deployed devices. For example, the NG112 system is an EU framework designed to aggregate multiple emergency call technologies, Public Safety Answering Point (PSAP) models, routing strategies, and other options through an emergency services network. NG112 is primarily based on the Long-Term Defined (LTD) European Emergency Number Association (EENA) architecture. Specification 2 / 28 pages 4 CN 121174131 A

[0025] An example of the NG112 architecture is shown with reference to Figure 2. In the example of Figure 2, User Equipment (UE) 210 communicates with an access network 212 that supports Voice over Internet Protocol (VoIP). Similarly, UE 220 communicates with a traditional access network 222. As used herein, the UE can be a cellular phone, landline phone, mobile device, or any other electronic device with wired and / or wireless communication capabilities.

[0026] The VoIP-enabled access network 212 communicates with the Border Control Function (BCF) 230 to access the Emergency Services IP Network (ESInet) 240. The legacy access network 222 communicates with the Legacy Network Gateway (LNG) 232 to access the ESInet 240.

[0027] The UE and the access network form part of a different initiating network, while the Emergency Services Network, including the Border Control Function 230 or the Legacy Network Gateway 232, forms part of the PSAP domain. The PSAP domain provides a Location Information Server (LIS) interface 234 to the location node 236.

[0028] The Emergency Services Network 240 includes various functional blocks, including a Log and Record (L / R) entity 242, an Emergency Services Routing Agent (ESRP) 244, an Emergency Call Routing Function (ECRF) 246, and multiple PSAPs (designated PSAP-1 250, PSAP-2 252, and PSAP-N 254). The L / R entity may also provide auditing capabilities, for example, for post-event analysis of emergencies.

[0029] Similarly, an example of a next-generation 911 system is shown with reference to FIG3. In the embodiment of FIG3, the initiating service environment 310 may access the Call Information Database (CIDB) 312 or the Location Information Service (LIS) 314. Similarly, the initiating service environment 316 may also access the CIDB 312 or the LIS 314.

[0030] The initiating service environment 310 may make Internet Protocol (IP) calls to the NG911 Core Services Network 320. Such a core service network 320 may include access to a legacy E911 selective router 322 and an E911 Automatic Location Information (ALI) database 324.

[0031] In the embodiment of FIG3, various functional elements are shown, including a Location Authentication Function (LVF) 330, an Emergency Service Routing Agent / Policy Routing Function (ESRP / PRF) 332, a legacy PSAP gateway (LPG) 334, a legacy network gateway / legacy selective router gateway (LNG / LSRG) 336, an ECRF with a PSAP boundary 338, and security functions 340.

[0032] In addition, PSAP 350 may include a call receiver system, map display, computer-aided dispatching (CAD), logging and reporting, and other functions.

[0033] The system may also include a Graphical Information System (GIS) 352 and an extended emergency network 354. The extended emergency network 354 may include various entities in a particular country. For example, in the United States, these entities may include the Department of Homeland Security, the Federal Emergency Management Agency (FEMA), city halls, etc.

[0034] The core service network 320 can also access other radio networks 360 or wired networks (not shown).

[0035] Utilizing the environment of Figure 2 or Figure 3, emergency services currently allow the use of additional data from mobile devices. For example, the National Emergency Numbering Association (NENA) provides detailed functional and interface specifications for IP-based multimedia telecommunications systems to support the delivery of emergency calls by emergency service IP networks. This standard is published as NENA-STA-010 “NENA i3 Next Generation 9-1-1 Standard”.

[0036] The NENA i3 call interface is a Session Initiation Protocol (SIP) interface and is defined, for example, in Internet Engineering Task Force (IETF) RFC 3261: “SIP Session Initiation Protocol”.Using this interface, a call can include one or more forms of media, including but not limited to audio, video, and / or text. SIP can be used to call back 911 callers and is a calling protocol between agents within ESInet.

[0037] The MESSAGE method provides an extension to SIP to allow the transmission of instant messages and is also used to carry Universal Alert Protocol (CAP) messages. The MESSAGE method is used to initiate non-interactive calls. The MESSAGE request carries content in the form of a Multipurpose Internet Mail Extensions (MIME) body portion. Using SIP, initiating an emergency call may require header fields in INVITE and MESSAGE. Information in the header fields may include an identity for providing a claim of the caller's identity, a Uniform Resource Identifier (URI) request specification 3 / 28 page 5 CN 121174131 A, "To" and "From the" fields, and other possibilities. As used herein, a URI includes a string that explicitly identifies a specific resource and follows a predefined set of syntax rules, but also maintains scalability through a separately defined hierarchical naming scheme.

[0038] Various call information may also be provided. For example, additional data may be available. Various standards for providing additional data include NENA-STA-012.2-2017 "NENA Standard for NG9-1-1 Additional Data"; APCO NENA 2.105.1-2017 "NG9-1-1 Emergency Incident Data Document (EIDD)"; or IETF RFC 7852 "Additional Data Related to an Emergency Call"; and other options. Specifically, with the implementation of NG911, telecommunications personnel and emergency responders will obtain various forms of additional data in addition to the primary call data from SIP INVITE and MESSAGE, as well as primary street addresses and / or geodetic data. Additional data relates to three entities typically associated with an emergency call: the caller making the emergency call, the location of the emergency call, and the call itself. The call information header included in the SIP INVITE or MESSAGE method may include a URI pointing to an externally hosted source of referenced additional data, or may include data by value in the call.As described below, when additional data is passed "by reference", it is retrieved via a Secure Hypertext Transfer Protocol (HTTPS) or Hypertext Transfer Protocol (HTTP) GET operation issued against the Additional Data Repository (ADR) for the reference (where the additional data is stored). Data collected by PSAP while processing a call is captured in an Emergency Event Data Document (EIDD) and passed to other agencies involved in the event.

[0039] In other cases, call information may include a call identifier. In this case, an emergency call may include a voice call, a video call, a text call, a non-interactive call, and other options. The first entity to process the call is the NG911 Emergency Platform, which assigns the call identifier. The call identifier may be in the form of a Uniform Resource Name (URN) consisting of the following: a prefix "urn:nena:uid:callid", a unique string containing alphanumeric characters, a ":" character, and an element identifier of the element that first processes the call. For example, this could be "urn:nena:uid:callid:a56e556d871:bcf.state.pa.us". The call identifier is added to the SIP MESSAGE using a call information header field, with the purpose of “nena-CallId”. For example, such a URN can be defined in IETF RFC 8141: “Uniform Resource Name (URN)”.

[0040] The call information may also contain an incident tracking identifier. The incident tracking identifier may be generated and assigned locally by the first entity in the NG911 emergency platform that handles the emergency call or declares the incident. The incident identifier is added to the SIP MESSAGE using a call information header field, with the purpose of “nena-IncidentId”. The incident tracking identifier is a URN formed by the following: the prefix “urn:nena:uid:incidentid”, a unique string containing alphanumeric characters, a “:” character, and the element identifier of the entity that first declares the incident. For example, the URN may be “urn:nena:uid:incidentid:a56e556d924:bcf.state.pa.us”. This string is typically unique for each incident that the element handles over time. One way to create a unique string is to use timestamps with a suffix that distinguishes multiple events if they can be created at the same time.

[0041] Exchange

[0042] As used herein, an exchange is a standards-compliant Location Information Server (LIS) and Additional Data Repository (ADR) that emergency personnel can access via a portal or through integration with existing equipment and software of PSAP.An example of such a clearinghouse is the RapidSOS clearinghouse, as described in RapidSOS – Karen Marquez's “RapidSOS Clearinghouse” (April 2019).

[0043] Referring now to Figure 4, Figure 4 illustrates an example of a clearinghouse within the NG911 architecture. In the example of Figure 4, a device such as user equipment 410, wearable device 412, IoT device 414, or connected vehicle 416 can send relevant data to the 911 call recipient and first responder on page 4 / 28 of the specification, CN 121174131 A, when a PSAP callback is made to the clearinghouse. In particular, such a device can communicate with a location center 420, which can locate the location of the device reported by the device. The location center 420 can provide a Phase 2 Fix to an operator location database 422, which can forward the Phase 2 Fix to a location database 424. The Phase 2 Fix can then be provided to the 911 center 430.

[0044] The device may further communicate with an access point 440, such as a cellular tower, which may use triangulation to determine the location of the device. In the case of a cellular tower, the access point will communicate with the wireless operator 442 and provide data to a selective router 444.

[0045] The selective router 444 may provide the cellular tower address to a local location database 424 and establish a voice path with the 911 center 430.

[0046] The location database 424 may forward the cellular tower information to the 911 center 430.

[0047] In addition to the above information, the device location and additional emergency data may be provided to the exchange 460 via a robust, secure IP path. The device location information may include latitude and longitude coordinates, building address, floor plan, contact information, company name, caller information, and other such information.

[0048] For example, and depending on the device, other data may be provided, including name, age, gender, membership identifier, key health information, or other such information about the device owner. In another example, additional data may include information about the vehicle that triggered the emergency call. The amount and type of data collected may depend on the privacy rules of the region or country where the device is located.

[0049] However, as can be seen from Figure 4, all information provided to the 911 center through the exchange or through other databases is associated with the physical device or the caller who initiated the 911 call.

[0050] Additional Database

[0051] The additional data repository (whether part of the exchange or independent of the exchange) is a database that stores additional data as a functional element in the i3 NENA NG911 architecture.Similar principles apply to the EENA NG112 architecture.

[0052] The ADR contains information that can be associated with an emergency call or the caller, and is managed and obtained from outside the ESInet. A device, initiating network, or caller can operate the ADR, or it can provide data to a third party operating the ADR.

[0053] All initiating networks and service providers should provide at least a minimum set of information corresponding to the information available in a traditional 911 system, which must be populated in the ADR when delivered by reference, or provided in the ontology of the SIP transaction when delivered by value. Access networks should provide the same minimum set of information.

[0054] Some ADRs are referred to as “identity-searchable” ADRs (IS-ADRs) and have an optional feature that allows the repository to be searched by the caller’s identity (e.g., the caller’s Uniform Resource Identifier (URI)). This functionality is required when data is stored by an entity not in the path of the calling or access network. This may occur, for example, when personal medical data provided by the caller is stored by an entity trusted by the called party to preserve such data.

[0055] The availability of additional data for a given call is indicated by various techniques. For example, a first technique may be through additional data call information headers within the initial message of a SIP transaction. These headers may contain additional data by value or by reference.

[0056] A second technique may be through additional caller data that can be retrieved by querying IS-ADR.

[0057] A third technique may be through a URI assigned to additional location data, which can be discovered along with an associated additional data service URN.

[0058] A fourth technique may be utilizing the presence of additional data blocks by value and / or by reference in the elements transmitting location information. This may include the presence of Information Data Format Location Object (PIDF-LO).

[0059] The above techniques may be used individually or in combination with each other. The acquisition of additional data may be carried out through various mechanisms.

[0060] In a first mechanism, the acquisition of additional data may be performed “by reference”. In this scenario, the call information header can be included in the caller's SIP INVITE or MESSAGE method, including a URI pointing to an externally hosted ADR. Additional data can then be retrieved via an HTTPS GET operation against the referenced ADR. Location information within the SIP transaction can also include additional data by reference.

[0061] A second mechanism can include retrieving additional data "by value." In this mechanism, the call information header can include a "content ID" URL pointing to the SIP transaction content containing the XML document with additional data. Location information can also include additional data by value.

[0062] A third mechanism for obtaining additional data may include a “query” method. In this case, additional data is retrieved by querying resources using information associated with the call. For example, such information may include an ADR for additional data at a location or an IS-ADR for additional data of the caller.

[0063] Devices such as those within vehicles equipped with telematics and medical monitoring equipment capable of making emergency calls may have the ability to respond to ADR queries or may publish data to an external ADR that will respond to a request to dereference. A service provider such as a telematics service provider may provide a reference to the ADR rather than a reference to the device. Other devices may also provide ADRs for emergency calls.

[0064] IS-ADRs may provide web services. When a query is made using the caller's From address or P-Asserted-Identity (retrieved from a SIP header field), IS-ADR may return a response, which may include, but is not limited to: an XML document containing the caller's additional data (by value); a URI that can be used to dereference the caller's additional data; an HTTP 333 response (iterative reference) instructing the client to redirect the additional data query to the resource specified in the response; and / or an indication that no data was found for the provided From or P-Asserted-Identity URI.

[0065] In the foregoing, the transaction dereferencing the additional data URI is generally protected. For example, it may be protected by Transport Layer Security (TLS). The dereferencing entity (which may be ESRP, PSAP, or a response authority) uses its credentials to derefer the additional data URI. The initiating network or service provider may use any credentials, as long as the field listed in the URI is the same as the SubjectAltName field in the credentials.

[0066] ADR will generally accept credentials traceable to a PSAP Credential Authority (PCA). In some cases, ESInet entities may only accept credentials for ADRs signed by a Credential Authority (CA) recognized by common web browsers.

[0067] ADRs may host sensitive data, the disclosure of which may be subject to legal, regulatory, privacy and confidentiality requirements and / or local policies. All ADR queries originating from ESInet typically involve authentication via credentials traceable to the PCA. If PCA traceable authentication fails, the ADR may provide less sensitive data. All ADRs typically provide data for any valid query. Call status ADRs may limit the length of time data is provided after the associated emergency call has ended.

[0068] Authorization Framework

[0069] To provide the above, an authorization framework may exist.For example, the OAuth 2.0 authorization framework is described in IETF RFC 6749, “OAuth 2.0 Authorization Framework”.

[0070] The OAuth 2.0 authorization framework enables third-party applications to obtain limited access to an HTTP service on behalf of a resource owner by coordinating approved interactions between resource owners in an HTTP service or by allowing the third-party application to obtain access rights in its own name.

[0071] An authorization grant is a credential that represents the resource owner’s authorization to access a protected resource used by a client to obtain an access token. The framework defines four types of authorization: authorization code; implicit; resource owner cryptographic credentials; and client credentials, as well as extensibility mechanisms for defining other types.

[0072] When the scope of authorization is limited to protected resources under the client’s control or to protected resources previously deployed with an authorization server, client credentials or other forms of client authentication can be used as authorization permission. Client credentials are typically used as authorization licenses when the client acts on its own behalf, such as when the client is also the owner of a resource, or when the client requests access to a protected resource based on prior authorization with an authorization server.

[0073] If the client is a confidential entity, the client and the authorization server establish a client authentication mechanism that suits the security requirements of the authorization server. The authorization server may, but is not necessarily, accept any form of client authentication that meets its security requirements. Confidential clients are typically issued or have a set of client credentials created for authentication with the authorization server. Examples of such credentials may include passwords, public / private key pairs, and other options.

[0074] Supplemental IoT Data

[0075] While the above examples provide examples of using supplemental data with next-generation emergency services, none of the above architectures offer a general or standardized solution for sharing relevant data generated by deployed IoT devices or other data sources that are not on the communication path between the device calling the emergency service and the emergency service provider. In particular, there is no general or standardized way to identify and select data sources other than the device initiating the emergency call or session and to efficiently provide selected data relevant to a specific event to the emergency service.

[0076] In order to utilize data from IoT devices and sensors deployed near or related to the event area, it is necessary to enhance the emergency service architecture to efficiently identify and access these data sources. These data sources may belong to or be managed by private companies or authorities, by local administrations or individuals, and may belong to different networks and be outside the emergency call path.Therefore, this document defines appropriate functional architectures and dedicated processes to allow access to data sources and the data they generate for emergency purposes, in addition to their primary or routine operations.

[0077] Furthermore, in the embodiments described below, registration, identification, and selection of IoT data sources are provided. Specifically, methods for registering data sources, such as deployed IoT sensors or devices, for use in emergency situations are provided. Such mechanisms allow for the proper identification of the characteristics and capabilities of IoT devices to select relevant devices for specific events. For example, there is currently no universal (or standardized) solution available to characterize the appropriate information about the data sources used in the registration discovery process for commercial or emergency infrastructure. Similarly, there is no universal (or standardized) solution that allows for the selection of relevant data sources, such as based on queries to servers containing data source information.

[0078] Further embodiments are described as allowing data derived from selected IoT data sources to be available to the emergency services platform and allowing the platform to access such data. Mechanisms for identifying and accessing IoT data relevant to a specific emergency are described.

[0079] In another embodiment, credential management is provided. In particular, the next-generation 911 NENAI3 standard assumes the use of TLS between the emergency services operator and the ADR and will supply long-term credentials. If such credentials are linked to a malicious or unauthorized entity, that entity may be able to access the ADR or other data sources. Therefore, the embodiments described below provide a mechanism for specifying and restricting the scope of access authorization.

[0080] Architecture Model

[0081] Referring now to FIG5, FIG5 illustrates an example architecture model for providing additional data to an emergency services platform. Specifically, in emergency situations including smart cities, smart buildings, or enterprises, data from multiple IoT devices (such as security cameras, thermostats, or other sensors located near the emergency caller or associated with the signal event) can provide useful information for building a common operational picture (COP) for emergency services operators and first responders, and can improve situational awareness of the event. As used herein, a COP is a general overview of the event created by evaluating and fusing information from multiple sources and shared among appropriate command, control, and coordination teams to support joint decision-making, for example, in the context of situational awareness, as described on page 7 / 28 of the situational awareness document 9 CN 121174131 A.

[0082] Data sources that may be considered for emergency purposes include, but are not limited to, building sensors such as temperature, air conditioning, leak detection, power, lighting, etc.; enterprise cameras; factory or industrial control sensors such as cameras, gas detectors, infrared sensors, radio frequency identification (RFID), etc.; sensors applied in IoT networks, using private or commercial IoT platforms, telematics data provided by vehicles or road infrastructure, alarms, embedded sensors or other devices; nursery or hospital sensors related to patient care (such as biometric devices, etc.), or sensors related to management; consumer sensors such as wearable devices, cameras, microphones, etc.; and / or links to smartphones or other devices. These supplementary data sources that may be used for emergency purposes may be connected to different communication networks using different technologies and may be owned or controlled by different individuals or administrators.

[0083] Therefore, as used herein, supplementary data (SD) is a dataset generated by devices including IoT devices, sensors and other data sources that may be relevant to a specific event. SD is typically initiated by sources other than the device that initiated the emergency call. SD sources may be located near the event site and may be associated with the event in different ways. For example, the sensor could be a water level sensor along the same flooded river or tributary. The correlation between SD and the event can be established by different entities within the emergency architecture. For example, the correlation can be established based on strategies or established criteria disclosed herein. SD can supplement additional data derived from devices or users that have initiated an emergency call or session.

[0084] These data sources can be registered or enrolled as described below so that they can be further accessed for emergency purposes in addition to their normal operation for commercial applications. Registration of data sources for emergency services does not presuppose that these data sources have the ability to initiate emergency calls or emergency data / non-interactive sessions only, or are associated with or connected to devices with the same ability to initiate emergency calls.

[0085] Thus, the embodiments described herein provide a framework that enables other data sources not directly involved in an emergency call or event (such as pre-deployed IoT devices or sensors, telematics or environmental data sources, or other devices located or dispatched to the vicinity of the event) to share supplemental data deemed relevant to emergency services. Such data (referred to herein as supplemental data (SD)) is therefore supplemental to the data available for emergency services provided by the calling device or ADR described above.

[0086] According to the embodiment of FIG5, a sufficient set of information characterizing each SD source can be recorded in a repository (hereinafter referred to as the Data Source Information Repository (DSIR)).The DSIR can then be queried by other entities involved in emergency handling, including the device that initiated the emergency call (DOEC), the Enhanced Additional Data Repository (E-ADR), the Supplemental Data Provider (SDP), or the Emergency Service Platform (ESP), to identify, access, and retrieve relevant data as necessary. In this case, the ESP may be the PSAP responsible for incident response via ESInet.

[0087] Thus, in the embodiment of FIG5, the DOEC 510 interfaces with the DSIR 520, one or more SDPs 530, and the E-ADR 540.

[0088] The DOEC 510 is a device, such as a smartphone or IoT device, that initiates an emergency call or a call to the ESP 550, for example by calling an emergency number based on the operating area, or by sending an emergency call message to the URN of a SIP call or alarm. The device may be able to derive its location when initiating the call. For example, an emergency location service calculates the device location locally using techniques such as those defined in ETSI EMTEL TS103 393 "Advanced Mobility Location for Emergency Calls".

[0089] The DOEC may provide additional information, including location information, to the ADR or E-ADR or to the ESP. The DOEC may also provide address information, such as the URI of the ADR, E-ADR, or SDP, to the ESP in the call information header. In some cases, the SDP address may be pre-configured in the DOEC. The DOEC may also provide additional information during a call or during call setup using the SIP INVITE, re-INVITE, SIP UPDATE, or SIP INFO methods. In this case, SIP re-INVITE is a SIPINVITE sent as part of an existing conversation, as described on page 8 / 28 of the specification, CN 121174131 A.

[0090] The DOEC 510 communicates with the DSIR 520 through the IE3 interface as defined below. The DSIR 520 is an entity that stores and provides information about data sources that can be accessed for emergency service purposes. For example, the DSIR may include the location of the IoT device, the data type generated by the IoT device, and information that allows the location and retrieval of the data, including the URI of the SDP where the data is stored (possibly a URI pointing to a data resource in the SDP), and other options.

[0091] In some embodiments, the DSIR 520 may be a centralized DSIR. In other embodiments, the DSIR 520 may be distributed.

[0092] In some cases, one or more DSIR distributed components of the DSIR or DSIR distributed components may be part of the ESP 550.In other embodiments, the DSIR 520 or one or more DSIR distributed components may be owned or managed by a government or emergency services administrator or a commercial entity. In some embodiments, the DSIR or one or more DSIR distributed components may be owned or managed by a commercial entity such as a private company.

[0093] In some implementations, access to data related to IoT resources may be subject to specific restrictions based on information confidentiality or privacy. Such restrictions may be documented in the DSIR.

[0094] Because data sources may be outside the emergency infrastructure involved in the event and may belong to a private company or independent organization, these data sources may need to be registered with emergency authorities to be listed in the DSIR.

[0095] In some cases, the DSIR 520 may be accessed as a web service via an application programming interface (API). In some cases, the DSIR may be an IoT DSIR. Specifically, in this case, the DSIR may refer to an IoT data source. In other cases, the DSIR may be an emergency DSIR, in which case the DSIR may refer to a data service accessible for emergency service purposes. In some cases, the API that allows access to the DSIR may also provide result codes and messages indicating success and / or failure.

[0096] The DOEC 510 can further communicate with one or more SDPs 530 via an IE4 interface, as described below. Each SDP is a resource server or web service. An SDP can reside on a gateway in an IoT platform, server, or cloud. An SDP stores SDs that may be associated with a specific event. For example, data may include temperature values ​​obtained from a thermostat located near the event or DOEC. In normal operation, this data may be used for commercial or private purposes. The SDP storing the event-related SD and associated resources can be identified and located via information records in the DSIR 520.

[0097] Therefore, an SD may include data from IoT devices / sensors and can be provided to the ESP by commercial or private applications on the IoT platform. In this framework, the SD can be accessed via an SDP. As used herein, an SDP is a functional entity that provides SDs to the ESP. An SDP can be an IoT platform, server, gateway, device, web service, and other options.

[0098] An SDP can provide an API to create resources to provide SDs associated with a specific event for the ESP and later delete those resources. When the SD is no longer needed, the ESP can call the API to delete the resource. Alternatively, SDP may delete the resource after a period of inactivity or after a certain time since its creation. The API that allows access to SDP may also provide result codes with messages indicating success and / or failure.

[0099] For example, resources can be created using the HTTPS PUT or POST method and accessed using the HTTPS GET method, as described below. Resources created in the SDP can be uniquely identified by the SD identity. The resource is associated with data related to a specific event. The SDP can determine which data to share with the ESP based on configured policies when creating the resource, for example, according to regulatory compliance or privacy protection rules, to avoid unnecessary data or privacy breaches. The SDP can also request the data source corresponding to the SD (e.g., IoT devices or sensors) to provide the latest data so that the SDP can provide the latest information when the ESP requests access.

[0100] Alternatively, some data resources registered by the DSIR can be accessed without the client accessing the SDP creating the resource. In this case, it is assumed that the resource already exists in the SDP, for example as a data record in the SDP, and can be accessed directly using a resource reference, such as a URI provided by the DSIR. In some examples, the resource under consideration can be created by the SDP administrator when the corresponding data source is registered in the DSIR or at other times. As described above, access to resources can be performed using the HTTPS GET method.

[0101] Furthermore, while the number of (IoT) data sources and IoT networks is increasing and the amount of related data is increasing, aggregating all SDs available for emergency purposes into a single repository may be inefficient or impractical. To address this issue, the reference architecture of Figure 5 supports multiple SDPs or a distributed SDP. The ESP will access one or more SDPs 530 identified by DSIR 520.

[0102] Based on the architecture disclosed above, if a resource is requested to be created for the ESP to access data, the SDP 530 provides the data to the ESP via the resource. The SD can be accessed via an API targeting the resource. Alternatively, an explicit resource creation step may not be necessary, such as if the resource is pre-configured in the data source registry in the DSIR within the SDP.

[0103] Data accessed via the SDP can be restricted to a subset of the data held by the SDP. For privacy or other policy reasons, in some cases, only this subset of data may be provided to the ESP.

[0104] As described above, additional data related to emergency calls, locations, callers, and other such additional data can be stored in and served by the ADR or E-ADR. Meanwhile, data provided via SDP includes data from one or more other sources. The ESP uses this data as a supplement to the data provided by the DOEC, ADR, or E-ADR to complement the COP of the emergency.

[0105] The DOEC 510 can further communicate with the E-ADR 540 via the IE2 interface, as described below.E-ADR is an ADR with enhanced features according to this embodiment. In addition to storing and providing “additional data” characterized as relating to the location or caller in a conventional ADR described above, E-ADR can also identify one or more SD sources related to a specific event that occurs by querying DSIR 520. Furthermore, E-ADR can request the corresponding SDP to create resources for ESP 550 to access SD. SDP can provide APIs as defined in this disclosure for the creation and subsequent deletion of resources.

[0106] DOEC 510 can further communicate with ESP 550 via an IE1 interface, as described below. ESP 550 provides services to public safety agencies such as police, fire, or medical services, which can be contacted by dialing dedicated access numbers (such as 911 in North America or 112 in Europe) and other such numbers around the world, or by sending emergency messages to URNs such as urn:service:sos. Next-generation emergency services are typically accessible via ESInet, which includes call routers such as ECRF, PSAP, or emergency call centers. In the context of this disclosure, ESP 550 receives an emergency call from DOEC 510 and accesses one or more SDPs that provide access to emergency-related SDs to supplement COPs, which will be used to provide an appropriate emergency response.

[0107] Furthermore, as shown in FIG5, one or more of DOEC 510, ESP 550, and E-ADR 540 can use the IE6 interface to communicate with an authorization server (AS) 560. AS 560 authorizes access to resources hosted in SDP 530. For example, DOEC and E-ADR request authorization to create resources related to a specific event in the SDP. ESP 550 requests authorization to access SDs in SDP 530. When ESP 550 determines that an SD is no longer needed, ESP 550 may request AS 560 to authorize the deletion of the resource.

[0108] Access authorization can be granted before ESP 550 accesses SDP 530 to obtain data related to a specific event. Security can be enhanced by limiting the scope of authorization specific to the resource (i.e., the SD to be shared with the ESP) and the duration of the authorization to short values.

[0109] The authorization server can grant an access token to the ESP 550 to allow the ESP to access resources corresponding to the SD on the SDP. The scope of the access token is limited to data resources related to a specific event, identified by the SD identity defined above.

[0110] In one or more embodiments supported by FIG5, DSIR 520 may use the IE3 interface to communicate with DOEC 510, E-ADR 540, or ESP 550.

[0111] In similar embodiments, SDP 530 may use the IE4 interface to communicate with DOEC 510 or E-ADR 540, and ESP 550 may use the IE5 interface to communicate with E-ADR 540 or SDP 530.

[0112] These interfaces are described in more detail below.

[0113] Based on FIG5, various SD collections can be provided to emergency service providers using the architecture and interfaces described herein. Using the architecture of FIG5, various scenarios can be implemented as different embodiments depending on the entity that determines the SDP(s) associated with the event, for example, by querying the DSIR, or from pre-configured information, depending on the scenario further described below.

[0114] Specifically, in the first scenario, DOEC 510 determines the SDP associated with the event. This embodiment is described below with reference to FIG. 6. In the second embodiment, E-ADR can determine the SDP associated with the event, as provided in FIG. 7 below. In the third embodiment, ESP 550 queries DSIR 520 and determines the SDP. This third embodiment is described below with reference to FIG. 8.

[0115] In each of the three embodiments, DSIR stores information related to data sources registered for use in emergency purposes. These data sources may be owned or managed by one or more data providers.

[0116] For each registered data source, DSIR includes multiple data service features to enable DOEC, E-ADR, or ESP to perform appropriate queries, searches, and selections when an emergency call is triggered at the time of an event.

[0117] Further, it is assumed that the URI stored in DSIR is used to refer to data or records corresponding to the data source selected in the corresponding SDP, or may refer to the SDP itself. ESP may store credentials required for querying the SDP. Otherwise, ESP will request access authorization from the authorization server.

[0118] DOEC determines (multiple) SDPs

[0119] Referring now to FIG6. In the embodiment of FIG6, DOEC 610 determines an SDP associated with an event. Specifically, in FIG6, DOEC 610 may communicate with various entities, including E-ADR 612, first SDP 614, second SDP 615, DSIR 616, and ESP 618.

[0120] In the embodiment of FIG6, DSIR 616 includes a set of recorded SDP data source attributes, as shown in box 620.

[0121] Once an emergency is triggered, as shown in box 622, the process proceeds to box 624, where DOEC 610 assigns an SD identity. An SD identity is a locally unique identifier for an SD associated with an emergency. In one case, an SD identity includes a locally determined identifier, for example, a URN based on the name or address of the organization to which DOEC 610 belongs, and a random value and / or a timestamp. Other identities are possible. The identity also identifies resources created on one or more SDPs for sharing an SD with ESP 618.

[0122] After assigning an SD identity, DOEC 610 sends a SIPINVITE / MESSAGE 630 with call information to ESP 618. The call information includes the SD identifier assigned at box 624, and the address 612 of the E-ADR, or a known SDP 614 or 615. Message 630 thus initiates an emergency call or session to ESP 618. The call information header of the call or session initiation message includes the SD identity and the address of (multiple) SDPs. If the DOEC has prior knowledge of the URI, the address can be the URI of the relevant SDP. Alternatively, the address can be the URI pointing to a resource at the DOEC.

[0123] ESP 618 uses the SD identity and URI to access the SD. Among other options, the call information header may also include a URI for accessing additional data in E-ADR 612.

[0124] If the DOEC does not have prior knowledge of the URI of the SDP resource, the DOEC 610 will send message 632 to DSIR 616 to identify one or more SDPs associated with the event. Message 632 may carry information including the DOEC's location and the type of emergency, such as police, fire.

[0125] DSIR 616 may then send a response 634 with a series of information, including, for example, the URI of the SD source, the DOEC location and data list, and other information. In the example of Figure 6, two SDPs are identified.

[0126] If the DOEC has a pre-configured URI for the SDP resource, then message 632 and response 634 are optional.

[0127] The DOEC 610 then requests the creation of a resource in the SDP with the first identity. The resource is referenced by the SD identity with the first SDP. The ESP can then access the resource to obtain the SD. Event data such as timestamps, locations, or data lists can be provided. An example of a data list is provided in the interface description below.

[0128] Before the DOEC 610 requests the creation of a resource in SDP 614, it can establish a secure connection with the AS and request an access token. The scope of the access token is requested to the resource (not shown) identified by the SD identity.In some cases, DOEC 610 includes an access token in the request to create the resource. This request is sent from DOEC 610 to SDP 614 as message 640.

[0129] SDP 614 verifies the access token, and if successful, SDP creates the resource identified by the SD identity and sends response 642. Response 642 indicates whether the resource was successfully created or whether the data is unavailable, or other result codes.

[0130] Since response 634 includes two URIs of the SD source, the process of creating the resource can be repeated on a second SD source. In the example of Figure 6, DOEC 610 sends message 650 to SDP 615 to create the resource. Message 650 may include an SD identifier, event data such as location and data list, and any access tokens.

[0131] SDP 615 may then send response 652 to indicate whether the resource was successfully created or whether the data is unavailable, or send other result codes.

[0132] ESP 618 can then send an access request to DOEC 610 for the resource identified by the SD identifier, as shown in message 660. In response, DOEC 610 sends a response 662 with an indication of whether the resource was successfully created, and the URL of the various SDPs on which the resource was created. If the resource was not created, response 662 may indicate this, or contain other result codes.

[0133] If DOEC 610 provides SDP information in message 630, ESP 618 skips message 660 and response 662.

[0134] ESP 618 can then access the resource identified by the SD identity of the first identified SDP and receive information about the data provided by the first SDP in the already created resource. ESP accesses the data based on this information. Before accessing the first SDP, ESP may establish a secure channel with AS to obtain an access token. The scope of the access token is limited to data related to a specific event, identified by the SD identity (not shown). Access request 670 from ESP may include the access token. SDP 614 verifies the access token, and if verification is successful, sends a response 672 with information about the SD to ESP 618. If the access token is not successfully verified by SDP 614, response 672 may indicate this, or contain other result codes.

[0135] Similarly, ESP 618 may send an access request 680 to SDP 615, and SDP 615 may send a response 682 with a URI and dereferenced data to ESP 618. If the access request is rejected by SDP 615, response 682 may indicate this, or contain other result codes.

[0136] Thus, the embodiment of FIG. 6 provides a scenario in which DOEC 610 determines the SDP.

[0137] E-ADR determines (multiple) SDPs

[0138] In another embodiment, the E-ADR may determine one or more SDPs associated with an event. Refer now to FIG7. In the embodiment of FIG7, DOEC 710 communicates with E-ADR 712. Additionally, two SDPs are shown, namely SDP 714 and SDP 715.

[0139] DSIR 716 and ESP 718 also form part of the emergency network.

[0140] In the embodiment of FIG7, DSIR 716 includes SD source information 720.

[0141] When DOEC 710 signals an emergency, as shown in box 722, the process proceeds to box 724, where DOEC assigns SD identities. An SD identity is a locally unique identifier for an SD associated with an emergency event. The SD identity may include locally determined identifiers, such as a URN based on the name or address of the organization to which the DOEC belongs, and a random value and / or a time stamp. However, in other embodiments, the SD identity may include other data for uniquely identifying the SD.

[0142] The SD identity also identifies the SD and one or more resources(s) created in one or more SDPs for sharing the SD with the ESP 718.

[0143] The DOEC may then initiate an emergency call or session to the ESP 718, as shown in message 730. The call information header of the call or session initiation message includes the SD identity and the address (URI) of the E-ADR 712.

[0144] The DOEC 710 may also provide additional device data to the E-ADR 712 in message 732. Such additional data may include the DOEC's location information and the SD identity or event identifier.

[0145] Once E-ADR 712 receives message 732, it can initiate a query to DSIR 716 to discover supplemental data sources. Query 734 can provide information such as location, emergency type, and other options.

[0146] In response to receiving query 734, DSIR 716 can send response 736. Response 736 can include the URIs of one or more SDPs. In the example of Figure 7, two SDPs are identified. If the query cannot be answered by DSIR 716, response 736 can indicate this or contain other result codes.

[0147] E-ADR 712 can then create a resource for the first SDP to be identified. This resource is referenced by the SD identity in the first SDP 714. This resource is created using message 740, which includes the SD identity, event data such as location, a data list, and other information.

[0148] Furthermore, before E-ADR 712 requests the creation of a resource on SDP 714, it can establish a second secure connection with the AS to request an access token. The scope of the access token is limited to data associated with a specific event, identified by the SD identity. E-ADR 712 includes the access token in message 740. The first SDP 714 verifies the access token, and if verified, SDP 714 creates the resource identified in the SD identity and sends response 742. Response 742 may indicate success, data unavailable, or other result codes.

[0149] Similarly, if two SDPs are identified in message 732, E-ADR 712 may create a resource as shown in message 750 at SDP 715. Response 752, indicating whether the resource was successfully created or data is unavailable, may be sent back to E-ADR 712, or may contain other result codes.

[0150] ESP 718 can access E-ADR 712 using message 760 to obtain additional data and receive the URI of the SDP resource. A response to message 760 is provided as response 762 and includes the URIs of the first and second SDPs in the example of FIG. 7.

[0151] ESP 718 can then access the resource identified by the SD identity in the first identified SDP, as shown in access request 770. ESP accesses the data based on the received information. Before accessing the first SDP, ESP can establish a secure connection with AS and obtain an access token. The scope of the access token is limited to data resources related to a specific event, identified by the SD identity. Access requests from ESP 718 may include the access token.

[0152] First SDP 714 verifies the access token and responds to ESP 718 using response message 772 containing information about the data. If SDP 714 does not verify the access token, response 772 may indicate this or contain other result codes.

[0153] Similarly, ESP 718 can access resources identified by the SD identity in the second identified SDP, as shown in access request message 780 for SDP 715. Again, a token can be used for such access requests.

[0154] In response to message 780, SDP 715 responds with message 782 providing information about the data. If SDP 715 cannot grant access, response 782 can indicate this or contain other result codes.

[0155] The embodiment of FIG. 7 thus provides a scenario for E-ADR to determine an SDP.

[0156] ESP Determines SDP Specification 13 / 28 pages 15 CN 121174131 A

[0157] In another embodiment, ESP can determine one or more SDPs associated with an event. Referring now to FIG. 8.In the embodiment of FIG8, once a given data source has been registered in the DSIR, the corresponding SDP record typically contains valid data and is available for querying. In this case, the data can be updated asynchronously by the data provider based on, for example, associated devices and other options.

[0158] In the embodiment of FIG8, DOEC 810 communicates with E-ADR 812.

[0159] Furthermore, in the embodiment of FIG8, two data sources are shown, namely SDP 814 and SDP 815.

[0160] In the embodiment of FIG8, SDP data source information is registered at DSIR 816, as shown in box 820.

[0161] When the event shown in box 822 occurs, DOEC 810 triggers an emergency call or session to an emergency number or toward an emergency URN. The emergency call process is initiated by DOEC using message 830 toward ESP 818.

[0162] In this case, message 830 is a SIP INVITE, or for non-interactive calls, message 830 may be a SIP MESSAGE. Other methods may be used for the above alternatives. The message header includes additional information by value and / or a reference to the E-ADR.

[0163] DOEC 810 may provide additional call-related data, such as location or caller (e.g., device-based location), to E-ADR 812 in message 832. In an alternative embodiment, if DOEC is enabled for this feature, the information is provided to a conventional ADR.

[0164] Furthermore, in some embodiments, if the URI of the data recorded in the E-ADR or ADR is provided by the E-ADR or ADR and is unknown to DOEC when message 830 is sent, message 832 may need to be sent before message 830.

[0165] If the additional data information is included by reference in message 830, ESP 818 may retrieve or dereference the corresponding data by performing an HTTPS GET request 840 or similar message to the E-ADR or ADR for the URI(s) received in the SIP transaction. In response, ESP 818 may receive response 842, which provides the corresponding dereferenced data. If the E-ADR or ADR cannot provide corresponding dereference data, response 842 may indicate this or contain other result codes.

[0166] ESP 818 may then query DSIR 816 to determine one or more SDPs associated with the event signaled by the emergency call. Request 850 may include data such as indications of proximity to the event location (e.g., maximum distance or relevant geographic area), sensor type or data type, and other such information.

[0167] In response to message 850, DSIR 816 sends response 852 providing a URI that provides SDPs or supplementary data.If DSIR 816 cannot provide the requested data, response 852 may indicate this, or contain other result codes.

[0168] Subsequently, ESP 818 may query the corresponding data by executing an HTTPS GET request 860 or a similar message to SDP 814 for the URI(s) received in the DSIR response 852.

[0169] SDP 814 may then provide the URI and dereferenced data in response 862. If SDP 814 cannot provide the URI and dereferenced data, response 862 may indicate this, or contain other result codes.

[0170] Similarly, ESP 818 may utilize an HTTPS GET request or a similar message to SDP 815 at message 870, and receive the URI and dereferenced data as message 872 in response. If SDP 815 cannot provide the URI and dereferenced data, response 872 may indicate this, or contain other result codes.

[0171] IoT for Emergency (IE) Architecture Interface

[0172] In the embodiment of FIG5, and for the messaging of FIG6 through 8, various entities utilize IoT Emergency (IE) interfaces to communicate with other entities. These are labeled IE1 through IE6 in FIG5. Each interface is described below.

[0173] IE1 Interface

[0174] The IE1 interface is the interface between the DOEC 510 and ESP 550 from FIG5, used to signal emergency calls based on protocols such as IMS and ISDN. SD identity is added to the call header of the SIP INVITE, re-INVITE, INFO, UPDATE, or MESSAGE method, or as an information element of the DOEC setup message.

[0175] Depending on which embodiment of FIG6 through 8 is used, it may be necessary to add SD identity. In the case of SIP signaling, SD identity can be added according to one of the following options.

[0176] In the first option, the SD identity can be added as a new header parameter for the SIP transaction. For example, this SD identity can be added in IETF RFC 3261 "SIP Session Initiation Protocol" for INVITE, or IETF RFC 3428 "SIP Instant Messaging Extensions" for MESSAGE, and other options.

[0177] In the second option, the SD identity can be added as a new parameter to the "Call Message" header, as defined in IETF RFC 3261, for example. This is shown in bold in Table 1 below, for example.

[0178]

[0179]

[0180] Table 1: Call Information Header Parameters for SD Identity in SIPINVITE

[0181] In the third option, the SD identity can be added as a new block of "Additional Data" specified for an emergency call in IETF RFC 7852 "Additional Data Related to Emergency Calls". For example, this is shown in bold in the example in Table 2 below. Specification 15 / 28 pages 17 CN 121174131 A

[0182]

[0183]

[0184] Table 2: New Additional Data Block for SD Identity

[0185] In the fourth option, the SD identity can be added as new information to a block within the "Additional Data" block. For example, the SD identity can be added to the "Service Information" block defined in IETF RFC 7852.

[0186] In the fifth option, the SD identity can be added by embedding a CAP message as an additional data block, as described in the IETF draft-ietf-ecrit-data-only-ea-20 "Non-interactive Emergency Calls". In this case, for example, the information can be in "". <incidents>"Transmission in CAP element. Specification 16 / 28 pages 18 CN 121174131 A

[0187] The IE1 interface can also be used to transmit the relevant SDP URI (if DOEC knows it) or other information known to DOEC that can help ESP retrieve SD. Options similar to the above options can be specified to enhance the relevant SIP protocol methods to transmit such information.

[0188] IE2 interface

[0189] The IE2 interface is the interface between DOEC 510 and E-ADR 540. It is based on the interface defined in EENA STA-010.3 "NENA i3 Standard for Next Generation 9-1-1". For example, a device enabled for a given E-ADR 540 provides location information to the E-ADR. DOEC 510 can also provide SD identity to E-ADR 540.

[0190] " The IE2 interface enhances the existing interface between the DOEC and the ADR. The existing interface allows the device to provide the ESP with additional data it possesses, such as the caller's number and location information. With the enhanced IE2 interface, the DOEC can provide the SD identity, event description, and caller's number and location information. The additional information enables the E-ADR to determine the SDP by querying the DSIR and request the identified SDP to create resources to share the SD with the ESP. The protocol for the interface can be based on HTTPS, Co-op Application Protocol (COAP), or Message Queuing Telemetry Transport (MQTT), among other options. An example of HTTPS with content type JavaScript Object Notation (JSON) is shown below with reference to Table 3.

[0191]

[0192] Table 3: Supplemental data for HTTPS with content type JSON

[0193] IE3 Interface

[0194] The IE3 interface is used to query the DSIR 520 for information about the SDP 530 that stores data related to a specific event. The DOEC, ESP, E-ADR, or SDP can use the IE3 interface to access the DSIR to obtain the URI of the SDP for a specific event.

[0195] The IE3 interface is used to query the DSIR for information about SD sources and / or SDPs that store data that may be related to a specific event. DOEC, E-ADR, or ESP can access the DSIR to obtain the URI of the SDP and / or the SD resource selected based on criteria provided by the requesting entity.

[0196] Queries to the DSIR can be implemented using various tools, such as RESTful web services / APIs (e.g., HTTP or HTTPS queries or OpenAPI), Remote Procedure Call (RPC) or GraphQL APIs, Structured Query Language (SQL), or other languages, depending on the DSIR implementation chosen.

[0197] Information about registered data sources stored by DSIR may include a description of additional data information according to IETF RFC 7852. Information stored by DSIR may include more information or extensions for additional parameters that may be necessary or beneficial in determining the relevant data source, including but not limited to DataInfo.SensorFunction indicating temperature, humidity, gas detectors, smoke detectors, and other options. Specification 17 / 28 pages 19 CN 121174131 A

[0198] When used in DSIR, geographic information may be encoded according to the Existence Information Data Format Location Object (PIDF-LOL) scheme, as provided in IETF RFC 5491 "GEOPRIV Existence Information Data Format Location Object (PIDF-LOL) Usage Classification, Considerations, and Recommendations". This encoding can encode complex shapes. For example, the ESP tool can encode an event location as an "Incident-area.xml" XML file as a geographic shape surrounded by circles, polygons, etc., through which SD sources located within that shape can be queried. Other encoding methods may be used.

[0199] Examples of pseudocode for querying data sources under a certain criterion are shown with reference to Table 4 below.

[0200]

[0201]

[0202] Table 4: Example Pseudocode for Querying Data Sources

[0203] The query may return a list of URIs pointing to SDP / data records that match the indicated criterion (if any), or an empty list otherwise. In some embodiments, the DSIR may return the number of identified data sources and / or the number of identified data records corresponding to the query. If any of these numbers exceed a certain threshold, the DSIR may limit the amount of information returned to the indicated threshold, for example, a first list containing the number of elements corresponding to the threshold. In addition, the requester may request more information, such as a second list that is a continuation of a previously obtained list, or refine the query to select fewer data sources.

[0204] The query may return a file such as an XML file or a JSON object to provide information stored in the DSIR about the retrieved data sources, including some or all of the information used to register the data sources, so that the requester can further evaluate the relevance of the data sources and, for example, manually or according to a certain strategy, select or prioritize information downwards. In some cases, information prioritization can be done automatically, or it can be assisted by graphical display of the source on PSAP CAD and other options.

[0205] For example, the pseudocode for the strategy used to construct the query can be specified as shown below with respect to Table 5. Specification 18 / 28 pages 20 CN 121174131 A

[0206] Specification 19 / 28 pages 21 CN121174131 A

[0207] Specification 20 / 28 Page 22 CN 121174131 A

[0208]

[0209] Table 5: Example pseudocode for the strategy of constructing queries

[0210] The returned URI corresponding to the SD resource selected by the DSIR can be one of a plurality of URIs. In a first embodiment, the returned URI can be a URI pointing to a data record that can be further retrieved from the SDP, such as: https: / / api.sdp1.com / directory-1 / data-source-1. In a second embodiment, the returned URI can be a URI pointing to the SDP, wherein the resource should be created before the data is retrieved, such as: https: / / api.sdp1.com / sd / .

[0211] In some embodiments, a single (absolute) identity can be used to identify a resource within the SDP. In this case, a separate identity can be provided to identify the SDP and the location of the resource within the SDP. An identity can be a relative name or a local name.

[0212] Support for the returned URI in the embodiments may depend on the embodiments and implementation options of the relevant entities, and is generally implemented consistently between the ESP and each SDP.

[0213] For the embodiments described above for IE3, it is assumed that the DSIR client stores appropriate credentials to access a given DSIR. In the case of a distributed DSIR, the same or different sets of credentials may be used for each of the multiple DSIR components.

[0214] IE4 Interface

[0215] The IE4 interface provides an API to request one of the identified SDPs 530 to create a resource for the ESP 550 to access data related to a specific event. The SDP 530 may store data about IoT devices for normal business operations. Upon receiving a request to create a resource with SD identity via IE4, the SDP 530 may select a subset of data that can be shared with the ESP 550 according to a configured policy and make it available through the created resource. This interface may be based on HTTPS or HTTP protocols. In some embodiments, the resource may be created using the PUT or POST method.

[0216] Therefore, a key feature of the IE4 interface is that it provides an API that enables clients (DOEC, E-ADR, SDP, or ESP) to create resources within the SDP. The created resources are used to share SD for a specific event with the ESP. Resources are identified by an SD identity. A request to create a resource may include the SD identity, event data (such as the event's timestamp), the event's location, a list of data to be shared through the resource, and an access token. The access token may include an authorization scope limited to the SD identity.

[0217] When the SDP receives a request, it verifies whether the access token is correctly signed and whether the token is scoped to the SD identity. If the token is successfully verified, the SDP can determine whether data source information is provided. If this information is provided, the SDP can determine whether the data source can be shared with the ESP based on the policy configured in the SDP. If the SDP determines that the data source can be shared, the SDP identifies and stores data asset information including at least one attribute of the data, which can be used by the ESP associated with the data source. For example, the data asset information may describe the data type, such as video stream, integer or character type, the time of data capture, and other options.

[0218] The SDP may also request the data source (e.g., an IoT device or sensor) corresponding to the data asset to provide up-to-date data so that the SDP can provide the latest information when the ESP requests access. In one embodiment, the data source may subscribe to commands or topics (update requests), and the SDP may utilize MQTT or a similar protocol to publish commands or topics to refresh the data.

[0219] If no data source information is provided in the request, the SDP can search for and identify data sources to be shared with the ESP based on the location information and timestamp information included in the request. For example, the SDP may find data sources provided by sensors close to the location information. The validity of the relevant data may be time-sensitive compared to the indicated timestamp (e.g., the data age does not exceed a timestamp threshold). The SDP determines whether the data source can be shared with the ESP according to the policy configured in the SDP. If the SDP determines that the data source can be shared with the ESP, the SDP identifies and stores the data asset information associated with the data source.

[0220] The protocol for the interface can be based on HTTPS, COAP, MQTT or similar protocols. The following table 6 shows an example of HTTPS with a content type of JSON to create a resource with SD identity equal to 202002101422-12345678.

[0221]

[0222] Table 6: Example HTTPS for Creating Resources

[0223] IE5 Interface

[0224] The IE5 interface provides an API for the ESP 550 to access specific resources to obtain an SD associated with a specific event from the SDP. In one embodiment, it is based on the HTTPS GET method applied to resources identified by an SD identity on the SDP 530.

[0225] In some embodiments, IE5 can also provide an API for the ESP 550 to delete resources based on the HTTPS DELETE method.

[0226] In some embodiments, the interfaces for accessing the SDP 530 and E-ADR 540 are based on the same IE5 principles and specifications. In other embodiments, different interfaces may be specified for accessing the SDP 530 and E-ADR.540.

[0227] A key feature of the IE5 interface is that it enables the ESP to access the SD associated with a specific event from the SDP. The ESP provides the address information (e.g., URI) of the SDP via E-ADR, DSIR, or DOEC, and, depending on the scenario, provides the SD identity or the SD's URI, as described above. The ESP can obtain an access token from the AS and include the token in the request to access a resource on the SDP identified by the SD identity.

[0228] When the target resource is specified as the SD identity shown in the examples in Table 7 below, the SDP responds using information from the data that becomes available through that resource. The data is based on asset information that the SDP has already identified and stored.

[0229] The protocol for the interface can be based on HTTPS, COAP, MQTT, or similar protocols. An example of HTTPS with JSON content type is shown in the examples in Table 7 below. In response to a GET message sent to a resource (identified by SD identity 202002101422-12345678), the ESP receives hyperlinks to two other SDPs and an SD description available from the SDPs. An HTTPS GET request is sent to that SDP. The ESP may send subsequent HTTPS GET requests to the other two SDPs and two specific media assets identified for the SD identity.

[0230]

[0231] Table 7: Example HTTPS GET for obtaining supplementary data

[0232] Using the example in Table 7 above, if the target resource is indicated as an SD URI in the request, the SDP will provide the SD in the response.

[0233] IE6 Interface

[0234] The IE6 interface is an interface for various entities, including DOEC 510, E-ADR 540, SDP 530, or ESP550, to access the authorization server 560. In one embodiment, the interface is based on the OAuth 2.0 protocol. However, this is merely an example, and other protocols can be used.

[0235] Through the IE6 interface, a requesting entity can obtain an access token to access resources in a resource server. For example, DOEC and E-ADR can request authorization to create a resource related to a specific event in SDP 530. SDP 530 can request authorization to create a resource in another SDP.

[0236] ESP 550 can request authorization to access an SD shared by the SDP acting as a resource server. When ESP 550 determines that the SD is no longer needed, ESP 550 can request authorization to delete the resource. The scope of authorization or access tokens requested via the OAuth 2.0 protocol can be limited to resources identified by the SD to prevent access to event-irrelevant data in the SDP. The type of authorization granted is the client credentials as described above.

[0237] Before accessing the SDP, the client can obtain an access token. It is assumed that DOEC, E-ADR, SDP, and ESP can establish a secure channel with the AS.

[0238] Before requesting to create a resource in the SDP, the E-ADR or DOEC can request the AS to issue an access token limited to the SD identity and create operation. For tokens issued with a limited scope, the validity period can be set to a short value. The token can be included in the authorization header of an HTTPS POST or PUT message.

[0239] Before requesting access to the SD from the SDP, the ESP can request the AS to issue an access token limited to the SD identity and read operation. For tokens issued with a limited scope, the validity period can be set to a short value. The token can be included in the authorization header of an HTTPS GET message.

[0240] Before requesting to delete a resource identified by the SD identity, the ESP can request the AS to issue an access token limited to the SD identity and delete operation. For tokens issued with a limited scope, the validity period can be set to a short value. The token may be included in the authorization header of the HTTPSDELETE message.

[0241] Registering the data source with the emergency service

[0242] Registration of an ESP (such as ESP 550) for supplemental data access for emergency purposes typically involves providing a set of information related to the corresponding data source and storing that information in a DSIR (such as DSIR 520). The DSIR can then be further queried to identify a subset of data sources corresponding to one or more search criteria, such as, but not limited to, the location of the event, sensors, or data types of interest.

[0243] Data source registration may be performed according to a process established between the data provider and the emergency service agency or mandate representative. For example, this may involve the public safety / emergency service agency (or mandate representative) identifying and agreeing to the SD provider in advance. It may also involve selecting a set of data sources that the emergency service may be interested in from the provider's network or platform. It may further involve providing a list of the selected data sources and related information so that the data sources can be logged into the DSIR (this may be an automated process) and further retrieved according to the embodiments described above. It may also involve providing sufficient information about the encoding format of the data that the ESP can access. This encoding format can be specified according to one of several encoding methods, such as XML, JSON, ASN.1, or other formats. The selected encoding format can be stored as an indication of the DSIR, and this indication can be used when retrieving data. In other embodiments, the selected encoding format can be indicated by the SDP when the data is retrieved (this allows for more flexible data format adaptation). According to embodiments, the encoding format can be associated with specific...The data source is defined, and multiple data sources associated with a given SDP are associated with multiple data sources recorded within the DSIR. Other embodiments are possible.

[0244] In some embodiments, the discovery process can be used to automatically find available data sources in the provider's network, thereby facilitating or automating the process of registering data source information to the DSIR. Such a discovery process may require the definition of discovery strategies on both the provider side (e.g., regarding which data sources and corresponding data can be shared) and the emergency service side (e.g., regarding how to select which data sources and corresponding data are of interest for emergency purposes). The discovery process may be based on modeling the data source or data according to different formats (e.g., XML, JSON, ASN.1) or technologies (e.g., in some examples, semantic interoperability technologies using appropriate representations and dictionaries, ontology-based technologies such as oneM2M Smart Device Templates (SDT), ETSI Smart Application Reference (SAREF)).

[0245] The registration operation may require authentication between the SD provider and the emergency management platform (e.g., ESP), or mutual authentication between the two parties. This may require a cooperation / interoperability protocol between the two parties. The SD provider may be provided with credentials required to perform the registration of the SD source.

[0246] Information related to the data source stored by the DSIR may include part or all of the additional data information, such as, but not limited to, data structures, data blocks, data elements, or fields as defined by IETF RFC 7852, with possible extensions for supplementary information that may be added.

[0247] Some information, such as data provider information and service information, may be common to the data source set. The provision of a subset of information (e.g., data provider ID, data provider contact URI, etc.) may be mandatory for the registration process and / or enforced by the registration process or policy. Whether the provision of information is mandatory may depend on the data source type or other conditions.

[0248] Specific information or process requirements may apply to the registration of consumer devices or data sources owned or managed by individuals rather than businesses or organizations. Specific verification processes can be enforced based on user or device-related information (e.g., disallowing device registration using an anonymous universal set instruction manual page 24 / 28 26 CN 121174131 A Integrated Circuit Card (UICC) or Subscriber Identity Module (SIM),) based on the acquired device type authentication, or based on other attributes to ensure a minimum level of trust in the associated data.

[0249] Hardware

[0250] The server, IoT device, SDP, and electronic device performing the above methods can be any electronic device or network node. Such electronic device or network node can include any type of computing device, including but not limited to smartphones.Mobile devices such as cellular phones. Examples may also include fixed or mobile user devices, such as IoT devices, endpoints, home automation devices, medical devices in hospital or home environments, inventory tracking devices, environmental monitoring devices, energy management devices, infrastructure management devices, vehicles or vehicle equipment, fixed electronic devices, etc. Vehicles include motor vehicles (e.g., cars, sedans, trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmanned aerial vehicles, unmanned aerial vehicle systems, drones, helicopters, etc.), spacecraft (e.g., space shuttles, space shuttles, space capsules, space stations, satellites, etc.), ships (e.g., ships, small boats, hovercraft, submarines, etc.), rail vehicles (e.g., trains and trams, etc.), pedestrians and bicycles, etc., including any combination of any of the above items, whether currently existing or future.

[0251] A simplified diagram of a network element or electronic device is shown with respect to FIG9.

[0252] In FIG9, device 910 includes processor 920 and communication subsystem 930, wherein processor 920 and communication subsystem 930 cooperate to perform the methods of the embodiments described above. In some embodiments, the communication subsystem 920 may include multiple subsystems, for example, for different radio and wired technologies.

[0253] The processor 920 is configured to execute programmable logic, which may be stored on the device 910 along with data and is shown as memory 940 in the example of FIG. 9. Memory 940 may be any tangible, non-transitory computer-readable storage medium. Computer-readable storage media may be tangible or transient / non-transitory media, such as optical (e.g., CD, DVD, etc.), magnetic (e.g., magnetic tape), flash drives, hard disk drives, or other memories known in the art.

[0254] Alternatively or in addition to memory 940, the device 910 may access data or programmable logic from external storage media, for example, via the communication subsystem 930.

[0255] The communication subsystem 930 allows the device 910 to communicate with other devices or network elements and may vary depending on the type of communication being performed. Furthermore, the communication subsystem 930 may include a variety of communication technologies, including any wired or wireless communication technologies.

[0256] In one embodiment, communication between various elements of device 910 can be via internal bus 960. However, other forms of communication are also possible.

[0257] Furthermore, if the electronic device, IoT device, or DOEC has user equipment capabilities, an example electronic device is described below with respect to FIG10.

[0258] Electronic device 1000 may include a bidirectional wireless communication device having voice or data communication capabilities or both. Electronic device 1000 may have the ability to communicate with other computer systems. Depending on the exact functionality provided, for example, electronic...The device may also be referred to as a data messaging device, two-way pager, wireless email device, smartphone, cellular phone with data messaging capability, wireless internet device, wireless device, mobile device, embedded cellular modem, or data communication device. Electronic device 1000 may also have wired communication capabilities (e.g., USB or Ethernet).

[0259] Where electronic device 1000 is also capable of two-way communication via cellular, it may incorporate a communication subsystem 1011, including a receiver 1012 and a transmitter 1014, and associated components such as one or more antenna elements 1016 and 1018, a local oscillator (LO) 1013, and a processing module such as a digital signal processor (DSP) 1020. It will be clear to those skilled in the art that the specific design of the communication subsystem 1011 will depend on the network in which the communication electronic device is intended to operate. Specification 25 / 28 pages 27 CN 121174131 A

[0260] Network access requirements will also vary depending on the type of network 1019. In some networks, network access is associated with a subscriber or user of electronic device 1000. Electronic devices may require an embedded or removable User Identity Module (RUIM) or Subscriber Identity Module (SIM) card or UMTS SIM (USIM) to operate on a network. The USIM / SIM / UIM interface 1044 typically resembles a card slot into which a USIM / SIM / RUIM card can be inserted and ejected. The USIM / SIM / UIM card may have memory and store many key configurations 1051, as well as other information 1053 such as identification and subscriber-related information.

[0261] Once the required network registration or activation process has been completed, the electronic device 1000 can send and receive communication signals via network 1019. As shown in FIG10, network 1019 may include multiple base stations communicating with the mobile device.

[0262] Signals received by antenna 1016 through communication network 1019 are input to receiver 1012, which can perform common receiver functions such as signal amplification, downconversion, filtering, and channel selection. Analog-to-digital (A / D) conversion of the received signals allows for more complex communication functions, such as demodulation and decoding, to be performed in DSP 1020. In a similar manner, the signal to be transmitted is processed, including modulation and encoding, for example by the DSP 1020, and is input to the transmitter 1014 for digital-to-analog (D / A) conversion, up-conversion, filtering, amplification, and transmission via antenna 1018 through communication network 1019. The DSP 1020 not only processes the communication signal but also provides receiver and transmitter control. For example, the gain of the communication signal applied to receiver 1012 and transmitter 1014 can be adaptively controlled by an automatic gain control algorithm implemented in the DSP 1020.

[0263] Electronic device 1000 typically includes a processor 1038 that controls the overall operation of the device. Communication functions (including data and voice communication) are performed via a communication subsystem 1011. The processor 1038 also interacts with other device subsystems, such as a display 1022, flash memory 1024, random access memory (RAM) 1026, auxiliary input / output (I / O) subsystem 1028, serial port 1030, one or more keyboards or keypads 1032, speaker 1034, microphone 1036, other communication subsystems 1040 such as a short-range communication subsystem or a DSRC subsystem, and any other device subsystem typically designated as 1042. Serial port 1030 may include a USB port, an onboard diagnostic (OBD) port, or other ports known to those skilled in the art.

[0264] Some of the subsystems shown in FIG10 perform communication-related functions, while other subsystems may provide "resident" or on-device functionality. It is worth noting that, for example, some subsystems (such as keyboard 1032 and display 1022) can be used for both communication-related functions (such as inputting text messages for transmission over a communication network) and device-resident functions (such as a calculator or task list).

[0265] The operating system software used by processor 1038 can be stored in persistent memory such as flash memory 1024, which can alternatively be read-only memory (ROM) or a similar storage element (not shown). Those skilled in the art will understand that the operating system, a particular device application, or a portion thereof can be temporarily loaded into volatile memory such as RAM 1026. Received communication signals can also be stored in RAM 1026.

[0266] As shown, flash memory 1024 can be divided into different areas for both computer program 1058 and program data storage 1050, 1052, 1054, and 1056. These different storage types indicate that each program can allocate a portion of flash memory 1024 for its own data storage requirements. In addition to its operating system functions, processor 1038 can also enable the execution of software applications on the electronic device. A predetermined set of applications controlling basic operations (e.g., including potential data and voice communication applications) will typically be installed on the electronic device 1000 during manufacturing. Other applications may be installed subsequently or dynamically.

[0267] Applications and software can be stored on any computer-readable storage medium. Computer-readable storage media can be tangible or transient / non-transient media, such as optical (e.g., CDs, DVDs, etc.), magnetic (e.g., magnetic tape), or other memories known in the art.

[0268] One software application may be a Personal Information Manager (PIM) application that has the ability to organize and manage data items related to the user of the electronic device, such as, but not limited to, emails, messages, calendar events, voicemails, appointments, and user manuals.Page 26 / 28 28 CN 121174131 A Service Project. Other applications (including productivity applications, messaging applications, social media applications, games, etc.) can also be loaded onto the electronic device 1000 via network 1019, auxiliary I / O subsystem 1028, serial port 1030, short-range communication subsystem 1040 or any other suitable subsystem 1042 and installed by the user in RAM 1026 or non-volatile memory (not shown) for execution by processor 1038. This flexibility in application installation increases the functionality of the device and can provide enhanced on-device functionality, communication-related functionality, or both.

[0269] In data communication mode, received signals such as text messages or web page downloads will be processed by communication subsystem 1011 and input to processor 1038, which can further process the received signals to output to display 1022, or alternatively to auxiliary I / O device 1028.

[0270] Users of the electronic device 1000 can also, for example, use a keyboard 1032 in conjunction with a display 1022 and possible auxiliary I / O devices 1028 to compose data items such as messages. The keyboard 1032 can be a full alphanumeric keypad or a telephone keypad (physical or virtual, etc.). Such combined items can then be transmitted over a communication network via the communication subsystem 1011.

[0271] In the case of providing voice communication, the overall operation of the electronic device 1000 is similar, except that the received signal can generally be output to the speaker 1034 and the signal used for transmission can be generated by the microphone 1036. Alternative voice or audio I / O subsystems (such as a voice message recording subsystem) can also be implemented on the electronic device 1000. Although the voice or audio signal output is preferably accomplished primarily through the speaker 1034, the display 1022 can also be used to provide, for example, an indication of the caller's identity, the duration of the voice call, or other voice call-related information.

[0272] The serial port 1030 in FIG. 10 can be implemented in an electronic device that may require synchronization with a user's desktop computer (not shown), but it is an optional device component. Such a port 1030 allows the user to set preferences via external devices or software applications, and can extend the capabilities of the electronic device 1000 by providing information or software downloads to the electronic device 1000 instead of via a wireless or wired communication network. As those skilled in the art will understand, the serial port 1030 can also be used to connect the electronic device to a computer to act as a modem or to charge the battery on the electronic device.

[0273] Other communication subsystems 1040 can further provide communication between the electronic device 1000 and different systems or devices, which are not necessarily similar devices. For example, subsystem 1040 may include infrared devices and associated circuitry and components or Bluetooth™ or Bluetooth.TM Low Energy Communication Module to provide communication with similarly enabled systems and devices.

[0274] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to the elements of the technology of this application. This written description can enable those skilled in the art to make and use embodiments having alternative elements having elements that also correspond to the elements of the technology of this application. Therefore, the intended scope of the technology of this application includes other structures, systems, or methods that are not different from the technology of this application described herein, and also includes other structures, systems, or methods that are not substantially different from the technology of this application described herein.

[0275] Although operations are depicted in a specific order in the drawings, this should not be construed as requiring such operations to be performed in the specific order shown or sequentially, or to perform all the operations shown to obtain the desired result. In some cases, multitasking and parallel processing may be employed. Furthermore, the separation of various system components in the above implementations should not be construed as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated in a single signal software product or packaged into multiple software products.

[0276] Furthermore, the technologies, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations may be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component (whether electrical, mechanical, or otherwise). Other examples of changes, substitutions, and alterations are those that can be determined and made by those skilled in the art.

[0277] While the above detailed description has shown, described, and pointed out the basic novelty features of this disclosure applicable to various implementations (pages 27 / 28, CN 121174131 A), it should be understood that various omissions, substitutions, and alterations of the form and details of the illustrated systems may be made by those skilled in the art. Furthermore, the order of method steps does not imply their order of appearance in the claims.

[0278] When sending / receiving messages to / from an electronic device, such operations may not be immediate or directly from a server. They may be delivered synchronously or asynchronously from servers or other computing system infrastructure supporting the devices / methods / systems described herein. The aforementioned steps may include, in whole or in part, synchronous / asynchronous communication to / from the device / infrastructure. Furthermore, communication from the electronic device can be to one or more endpoints on the network. These endpoints can be served by servers, distributed computing systems, stream processors, etc. Content Delivery Networks (CDNs) can also provide communication to electronic devices. For example, in addition to a typical server response, the server can provide or instruct the CDN to provide data for the electronic device to download at a later time (e.g., subsequent activity of the electronic device). Therefore, data can...Send directly from a server or other infrastructure (such as a distributed infrastructure or CDN) that is part of or separate from the system.

[0279] Typically, storage media may include any or some combination of the following: semiconductor memory devices, such as dynamic or static random access memory (DRAM or SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; disks, such as fixed, floppy, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CD) or digital video discs (DVD); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such computer-readable or machine-readable storage media(s) are considered part of an article(s). An article(s) or article(s) may refer to any single or multiple components manufactured. One or more storage media may be located in a machine that executes machine-readable instructions, or at a remote site from which machine-readable instructions can be downloaded via a network for execution.

[0280] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be carried out without some of these details. Other implementations may include modifications and variations of the foregoing details. The appended claims are intended to cover such modifications and variations. Instruction Manual 28 / 28 Page 30 CN 121174131 A Figure 1 Figure 2 Instruction Manual Appendix 1 / 6 Page 31 CN 121174131 A Figure 3 Figure 4 Instruction Manual Appendix 2 / 6 Page 32 CN 121174131 A Figure 5 Figure 6 Instruction Manual Appendix 3 / 6 Page 33 CN 121174131 A Figure 7 Instruction Manual Appendix 4 / 6 Page 34 CN 121174131 A Figure 8 Figure 9 Instruction Manual Appendix 5 / 6 Page 35 CN 121174131 A Figure 10 Instruction Manual Appendix 6 / 6 Page 36 CN 121174131 A Abstract The present disclosure relates to method and device for automated provisioning of data from multiple sensors within an emergency services network. A method at a Supplementary Data Providerwithin an emergency services network, the method including receiving a message at the Supplementary Data Provider, the message including an identifier and incident data; responsive to receiving the message, creating a resource at the Supplementary Data Provider based on the incident data, the resource being associated with the identifier; receiving an access request from an Emergency Services Provider for Supplementary Data associated with the resource; and responsive to receiving the access request, providing a response with the Supplementary Data.< / incidents>

Claims

1. A method at a supplemental data provider within an emergency services network, the method comprising: A message is received at the supplementary data provider, the message including an identifier and event data; In response to receiving the message, a resource is created at the supplementary data provider based on the event data, the resource being associated with the identifier; Receive access requests from the emergency service provider for supplemental data associated with the resource; as well as In response to receiving the access request, a response with the supplementary data is provided.

Images