Systems and methods for emergency situations

Abstract

A system including a user device, operable by a user, supporting an application configured to: activate an emergency response, in response to a trigger by the user. The system further includes a data storage system, having a write once, read many architecture, communicatively connected to the user device and configured to receive the encrypted evidence data and apply a counter-signature to the encrypted evidence data; the data storage system comprising a first database and a second database, wherein the first database is accessible by the user and the second database is accessible to a certified party and inaccessible to the user. The system further includes a consortium blockchain network configured to validate the encrypted evidence data stored in the data storage system and comprising a plurality of full access nodes.

Description

SYSTEMS AND METHODS FOR EMERGENCY SITUATIONSBACKGROUND

[0001] Safety is a high concern for many. In an emergency situation, individuals, whether due to panic or other factors, may struggle to contact emergency services. Should the emergency situation warrant further investigation, individuals involved, including police officers and prosecutors, may further struggle to recollect details or events occurring during the emergency situation.

[0002] Consequently, it can be beneficial for systems and methods to provide individuals with simple and reliable methods for both contacting emergency services in the event of an emergency situation and collecting evidence during the occurrence of such an emergency situation. Furthermore, it can be beneficial for systems and methods to provide individuals with improved ability to access, identify, and categorize evidence and data that may be associated with a particular emergency or non-emergency event.

[0003] Convention systems are directed either to use by the individual or use by law enforcement - not both. Current systems, for use by an individual, do not provide direct VoIP to PSAP calling in addition to a backup call, automatic evidence recorder that starts before the 911 call connects and continues even after the call has ended, a chain of custody that is externally validated, a constitutional framework that provides 4thAmendment protection to all three parties involved (individual, witness, law enforcement), user-trained voice activation, redundant call delivery mechanism, 911 audio protection, and a Criminal Justice Information Services (CJIS)-compliant infrastructure.

[0004] The current systems used by law enforcement, while CJIS -compliant, require the officer to capture the evidence data (versus the individual) and this evidence is certified internally without any independent verification methods in place, which allows the possibility for internal tampering of the evidence. In addition, these systems do not record evidence prior to a 911 call connection. Further, these systems do not provide protection to the 911 audio call records and do not provide constitutional protection to all three parties (individual, witness, law enforcement).

[0005] Accordingly, a single integrated system may be desired to provide constitutional protection to all three parties (individual, witness, law enforcement) while providing enhanced recordingfeatures, backup call features, independent external data verification, user-trained voice activation, three-tier data protection scheme, and direct VoIP to PSAP.SUMMARY

[0006] This Summary section is neither intended to be, nor should be, construed as being representative of the full extent and scope of the present disclosure. Additional benefits, features and embodiments of the present disclosure are set forth in the attached figures and in the description hereinbelow, and as described by the claims. Accordingly, it should be understood that this Summary section may not contain all of the aspects and embodiments claimed herein.

[0007] Additionally, the disclosure herein is not meant to be limiting or restrictive in any manner. Moreover, the present disclosure is intended to provide an understanding to those of ordinary skill in the art of one or more representative embodiments supporting the claims. Thus, it is important that the claims be regarded as having a scope including constructions of various features of the present disclosure insofar as they do not depart from the scope of the methods and apparatuses consistent with the present disclosure (including the originally filed claims). Moreover, the present disclosure is intended to encompass and include obvious improvements and modifications of the present disclosure.

[0008] In one aspect, a system comprises a user device, operable by a user, supporting an application configured to: activate an emergency response, in response to a trigger by the user, comprising: capturing evidence data; connecting to an emergency service; timestamping the evidence data; encrypting the evidence data with device signature generated by the user device; transmitting user profile data to the emergency service; and transmitting user location data to the emergency service; a data storage system, having a write once, read many architecture, communicatively connected to the user device and configured to receive the encrypted evidence data and apply a counter-signature to the encrypted evidence data; the data storage system comprising a first database and a second database, wherein the first database is accessible by the user and the second database is accessible to a certified party and inaccessible to the user; and a consortium blockchain network configured to validate the encrypted evidence data stored in the data storage system and comprising a plurality of full access nodes.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.

[0010] Figure 1 representatively illustrates a personal safety system, in accordance with the present disclosure;

[0011] Figure 2 illustrates a flow chart depicting communication between a user of the personal safety system with a third party in accordance with the present disclosure;

[0012] Figure 3 representatively illustrates an evidence collection and storage function of the personal safety system in accordance with the present disclosure;

[0013] Figure 4 representatively illustrates an evidence gateway operation of the personal safety system in accordance with the present disclosure;

[0014] Figure 5 representatively illustrates access to various portions of the system, in accordance with the present disclosure;

[0015] Figure 6 representatively illustrates a third party interacting with the personal safety system in accordance with the present disclosure;

[0016] Figure 7 representatively illustrates a method of operating the personal safety system in accordance with the present disclosure;

[0017] Figure 8 representatively illustrates communication flow through the personal safety system in accordance with the present disclosure;

[0018] Figure 9 representatively illustrates backend messaging flow through the personal safety system in accordance with the present disclosure;

[0019] Figure 10 representatively illustrates a messaging sequence with a first responder portal in accordance with the present disclosure;

[0020] Figure 11 representatively illustrates a voice activation function of the personal safety system in accordance with the present disclosure;

[0021] Figure 12 representatively illustrates data flow through the personal safety system, in accordance with the present disclosure; and

[0022] Figure 13 representatively illustrates data encryption on the personal safety system, in accordance with the present disclosure.DETAILED DESCRIPTION

[0023] The following description recites various aspects and embodiments of the invention disclosed herein. No particular embodiment is intended to define the scope of the invention. Rather, the embodiments provide non-limiting examples of various configurations, and methods that are included within the scope of the claimed invention. The description is to be read from the perspective of one of ordinary skill in the art. Therefore, information that is well known to the ordinarily skilled artisan is not necessarily included.

[0024] Definitions

[0025] The following terms and phrases have the meanings indicated below, unless otherwise provided herein. This disclosure may employ other terms and phrases not expressly defined herein. Such other terms and phrases shall have the meanings they would possess within the context of this disclosure to those of ordinary skill in the art. In some instances, a term or phrase may be defined in the singular or plural. In such instances, it is understood that any term in the singular may include its plural counterpart and vice versa, unless expressly indicated to the contrary.

[0026] As used herein “E911” is meant to refer to Enhanced 911 which is a service that automatically displays the telephone number and physical location of the 911 caller on the emergency operator’s screen.

[0027] As used herein “Public Safety Answering Point (PSAP)” refers to a dispatch center staffed by emergency operators that receives 911 calls and sends fire, police, or medical services to assist the caller, depending on the nature of the emergency. PSAPs are emergency response centers.

[0028] As used herein “Voice over Internet Protocol (VoIP)” is meant to refer to communications technology for placing phone calls over Internet Protocol (IP) networks such as the Internet. Standard hardline phone systems rely on physical lines. VoIP instead converts voice calls into packets of data and sends them through an IP network. By using IP networks, VoIP calls bypass a large part of the Public Switched Telephone Network (PSTN), this can result in large cost savings, especially for long distance calls. Additionally, because VoIP is not tied to a physical phone line and can be accessed anywhere there is an adequate IP connection, VoIP gives a high level of mobility.

[0029] As used herein “IP-PBX (Private Branch Exchange)” is meant to refer to a VoIP telephone system for private companies and connects the extensions of the IP-PBX to the PSTN. Additionally, the IP-PBX connects phones within the network. This allows all the extensions usedby the company to be connected, thus extensions that are located in many different places are connected. The inter-branch calls use the company data network and bypass the PSTN, this saves on long distance charges.

[0030] As used herein “cellular equipped device” is meant to refer to a device that is configured to connect to a cellular network. Such devices include but are not limited to cellular phones; tablet devices; smartwatches, and wearables such as smart glasses, or other mobile devices configured for wireless communication. Cellular equipped devices may, in some instances, be incorporated into jewelry, clothing, and the like.

[0031] As used herein “Automatic Location Identification (ALI)” is meant to refer to a database that stores telephone numbers and the physical locations associated with those numbers. ALI records are managed by the local exchange carrier. Typically, ALI records are stored in regional ALI databases. The regional ALI databases function well for physical phone lines because physical phone lines are static and confined to a specific location. A national ALI database is available for VoIP users. The national database is a good safety precaution for VoIP due to the mobility of VoIP numbers.

[0032] As used herein “ANI” is meant to refer to Automatic Number Identification which is automatically displayed at the PSAP of the telephone number associated with the line calling 911. Each telephone number and the physical location that the line corresponds to are stored in an Automatic Location Identification (ALI) database. ALI records are managed by the local exchange carrier. During a 911 call the PSAP uses the ANI to retrieve the physical address of the phone used by the caller from the ALI database. Furthermore, the ANI functions as a callback number if the PSAP loses the connections to the distressed caller.

[0033] As used herein “Emergency Response Location (ERL)” is meant to refer to a specific geographic location where a 911 emergency response team will be directed. A PBX administrator may break down an organization’s campus or buildings into multiple distinct ERLs. This enables precise location identification rather than a generic main billing address.

[0034] As used herein “Emergency Location Identification Number (ELIN)” is meant to refer to a ten-digit number purchased from the local exchange carrier and is one method by which an organization provides specific location information to the PSAP for a 911 call. The organization assigns an ELIN to each ERL, one ELIN can be used for many phones within an ERL. The organization of ELINs to ERLS is then loaded into the regional ALI database. The ELIN takes theplace of caller’s number during a 911 call and is used to route the call to the appropriate PSAP. The ELIN is used to query the ALI database and retrieve the caller’s location. In the event of a disconnection, the PSAP can use the ELIN to call back the extension directly.

[0035] As used herein “Presence Information Data Format Location Object (PIDF-LO)” is meant to refer to an HTTP, XML tag format which includes a location object. The location information is generally described in one of two forms; geodetic or geographic location information, using latitude and longitude coordinates; or civic addresses utilizing the address system of the city in which the call is being made. Geodetic location information is readily understood by computers because the coordinates only utilize a small amount of information and need only be configured to understand the Coordinate Reference System. Civic addresses are typically more readily understood by people including emergency personnel.

[0036] As used herein “Session Initiation Protocol (SIP)” is meant to refer to a signaling protocol used for initiating, maintaining, and terminating real-time sessions that include voice, video, and messaging applications. SIP is used for signaling and controlling multimedia communication sessions in applications of Internet telephony for voice and video calls, in private IP telephone systems, in instant messaging over Internet Protocol (IP) networks as well as mobile phone calling over LTE (VoLTE). The protocol defines the specific format of messages exchanged and the sequence of communications for cooperation of the participants. SIP is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP). A call established with SIP may consist of multiple media streams, but no separate streams are required for applications, such as text messaging, that exchange data as payload in the SIP message. SIP works in conjunction with several other protocols that specify and carry the session media. Most commonly, media type and parameter negotiation and media setup are performed with the Session Description Protocol (SDP), which is carried as payload in SIP messages. SIP is designed to be independent of the underlying transport layer protocol and can be used with the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP), and the Stream Control Transmission Protocol (SCTP). For secure transmissions of SIP messages over insecure network links, the protocol may be encrypted with Transport Layer Security (TLS). For the transmission of media streams (voice, video) the SDP payload carried in SIP messages typically employs the Real-time Transport Protocol (RTP) or the Secure Real-time Transport Protocol (SRTP).

[0037] As used herein “Criminal Justice Information Services (CJTS)” is meant to refer to the largest division of the FBI and comprises several departments, including the National Crime Information Center (NCIC), Integrated Automated Fingerprint Identification System (IAFIS), and the National Instant Criminal Background Check System (NICS). CJIS monitors criminal activities in local and international communities using analytics and statistics provided by law enforcements. The CJIS databases provide a centralized source of criminal justice information to agencies around the country. CJIS databases house criminal data. CJIS requires rigorous security standards for all organizations, vendors, local agencies, and corporate networks.

[0038] Embodiments of the present technology may provide an integrated personal safety platform that combines three capabilities together: simultaneous emergency calling and evidence capture from a single trigger, redundant emergency communication that guarantees delivery even when the user cannot speak, and a constitutionally aware, three-tier evidentiary architecture that allows any authorized party — defense, prosecution, courts, or oversight bodies — to independently verify evidence integrity without trusting any single entity.

[0039] Embodiments of the present technology may be designed to simultaneously enforce constitutional protections for three distinct parties — the citizen, law enforcement, and witnesses — by technical enforcement at the infrastructure level, built from the ground up on FBI Criminal Justice Information Services (CJIS) Security Policy principles.

[0040] Embodiments of the present technology may provide an integrated, civilian-operated system that begins capturing court-grade evidence the moment a user perceives danger — before emergency services are even contacted — and preserves that evidence through an unbroken, independently verifiable chain of custody from the citizen's device through courtroom presentation.

[0041] Embodiments of the present technology may provide an integrated system that spans the entire lifecycle from personal safety trigger to emergency response to evidence preservation to law enforcement access to courtroom verification.

[0042] Embodiments of the present disclosure may provide systems and methods that can play a role in an individual’s personal protection. In the present system, a mobile application running on a mobile device such as a mobile phone may be configured to detect a trigger event indicating that an emergency situation has arisen. Detecting the trigger event may involve the mobile device executing a mobile application to monitor nearby audio signals to detect a particular spoken audiosafety phrase or receive a particular input via a user interface element of the mobile application. Once the mobile device detects the trigger event (e.g., a particular phrase spoken by an individual in proximity to the mobile device, the application is activated. Having detected the trigger event, the mobile device can initiate a telephone communication (e.g., via a VoIP communication channel or conventional voice channel) to emergency services. Based on the mobile device’s current location, the telephone communication is routed to an emergency service center (e.g., PSAP) that is closest to the mobile device. The mobile application provides the emergency service center with location information about the mobile device (e.g., one or more of a GPS location and an address that is proximate to the GPS location of the mobile device). The location information can enable the emergency service center to direct resources and assistance directly to the mobile device’s location thereby enabling rapid response to the emergency situation.

[0043] While the mobile application running on the mobile device initiates the emergency communication, the mobile application may at or about the same time (e.g., substantially simultaneously) initiate evidence collection. This may involve the mobile application recording data captured by one or more sensors of the mobile device (e.g., audio data via a microphone, visual data via one or more cameras of the mobile device, movement data via an accelerometer and / or GPS device, and the like) into a secure storage location in a memory of the mobile device. The captured data may constitute evidence associated with the emergency situation and may be used as part of an investigation or legal action that may arise as a result of, or related to, the emergency situation. The FBI CHS has established standards for capturing evidence that is admissible in court at the scene of the crime. The mobile application is compliant with those standards. Among those standards are methods for establishing and maintaining evidence of where someone was located, which can be used during the prosecution of a criminal case. These same methods could be used to prove the location of someone wrongfully accused of a crime. The application includes safeguards to protect the audio and video files from manipulation.

[0044] In addition to facilitating the contacting of emergency services and recording of evidence, the mobile application can also, upon detecting the trigger event and pursuant to the user’s preferences, automatically transmit notifications to a number of the user’s emergency contacts, where the notifications provide an indication that an emergency event has been detected along with the location details and information describing the user. The notifications may be transmitted usingtext messages or may be transmitted as alerts appearing in the corresponding mobile applications running on the mobile devices of the emergency contacts.

[0045] Data and evidence captured by the mobile device during the emergency event, as well as data captured by other sensors and / or individuals (e.g., police officer body cameras, investigators notes and reports, witness statements, multimedia data such as video, images, and sound recordings, and an individual's criminal record data) may all be incorporated into a discovery platform configured to automatically process, analyze, and categorize all uploaded data. This process may involve performing speech recognition on uploaded audio to identify key words, object recognition in visual data (e.g., video or still images) to identify objects depicted therein, and optical character recognition of handwritten evidence, such as an officer's notes or a witness statement. Once properly processed, automated artificial intelligence and machine learning systems allow system users to quickly search for and identify key pieces of evidence or information as well as evidence identified as being potentially related by the AI / ML systems. As such the discovery platform can greatly facilitate the resolution of issues (e.g., prosecution of a crime or processing of an insurance claim) in which evidence uploaded to the discovery platform is pertinent.

[0046] Embodiments of the present system may comprise a comprehensive emergency response and evidence platform that leverages modern technologies to provide real-time assistance and security to its users. To enhance the security and integrity of emergency calls / events and assets uploaded to the platform, the system may comprise a blockchain network. The blockchain network can ensure a secure, immutable ledger for all emergency -related data, and evidence, providing transparency and trustworthiness. The blockchain network may further ensure that all data related to emergencies and evidence is tamper-proof and verifiable. In addition, the blockchain network may provide a transparent system where all stakeholders can verify the authenticity of the data. Embodiments of the present system may further comprise infrastructure to ensure scalability as the user base of the system grows.

[0047] Embodiments of the present system may be configured to handle emergency calls / events, evidence and asset uploads. In various embodiments, a method for data flow may comprise an emergency event trigger at which time event details are captured. The method may further comprise data encoding, wherein event details and any associated assets (e.g., audio recordings, images) are encoded into a suitable format for data storage. The method may further comprise ablockchain transaction, wherein the encoded data is transmitted to a blockchain network, creating a new transaction. The method may further comprise a transaction confirmation, wherein blockchain confirms the transaction, ensuring the data is securely stored in an immutable ledger. The method may further comprise data verification, wherein stakeholders of the blockchain network can verify the authenticity of the data by querying the blockchain.

[0048] Embodiments of the system may further comprise a user authentication feature, wherein users of the system can log in with their mobile app, requiring open authorization or multifactor authentication. In various embodiments, a secret key may be tied to mobile phone to ensure fast authentication.

[0049] Embodiments of the present system may further comprise a data hashing function, wherein a user safety profile is hashed with the hash / checksum recorded on the blockchain network.

[0050] Embodiments of the present system may further comprise various levels of encryption. For example, an encryption level for legal use or court purposes may be utilized, wherein encryption keys will be used to deliver information to organizations, such as justice officials and law enforcement, through a First Responder Portal and ToolKit.

[0051] In this configuration, the integration of a blockchain network can significantly enhance the security, integrity, and transparency of emergency calls / events and assets uploaded to the platform. This integration will provide an immutable ledger, ensuring that all data is tamper-proof and verifiable, thereby increasing trust among users and stakeholders.

[0052] Embodiments of the present system may comprise blockchain technology or a blockchain network to record the evidence data and chain of custody of the evidence data. In one embodiment, the system may comprise two private blockchains to create an immutable and verifiable ledger of evidence (images, videos, audio, and text documents) submitted by users through mobile and other applications. Other embodiments of the system may utilize a single blockchain network.

[0053] In various embodiments, the blockchain network may comprise a private consortium blockchain network. Alternatively, the blockchain network may comprise public, private, or hybrid blockchain network.

[0054] Generally, a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains.

[0055] In a public blockchain network, the consensus process is controlled by nodes of the consensus network. For example, hundreds, thousands, even millions of entities can cooperate apublic blockchain network, each of which operates at least one node in the public blockchain network. Accordingly, the public blockchain network can be considered a public network with respect to the participating entities. In some examples, a majority of entities (nodes) must sign every block in order for the block to be valid, and added to the blockchain (distributed ledger) of the blockchain network. Example public blockchain networks include particular peer-to-peer payment networks that leverage a distributed ledger, referred to as blockchain. As noted above, the term blockchain, however, is used to generally refer to distributed ledgers without particular reference to any particular blockchain network.

[0056] In general, a public blockchain network supports public transactions. A public transaction is shared with all of the nodes within the public blockchain network, and are stored in a global blockchain. A global blockchain is a blockchain that is replicated across all nodes. That is, all nodes are in perfect state consensus with respect to the global blockchain. To achieve consensus (e.g., agreement to the addition of a block to a blockchain), a consensus protocol is implemented within the public blockchain network. Examples of consensus protocols include, without limitation, proof-of-work (POW), proof-of-stake (POS), and proof-of-authority (POA). POW is referenced further herein as a non-limiting example.

[0057] In general, a private blockchain network is provided for a particular entity, which centrally controls read and write permissions. The entity controls, which nodes are able to participate in the blockchain network. Consequently, private blockchain networks are generally referred to as permissioned networks that place restrictions on who is allowed to participate in the network, and on their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote on adding new entities, a regulatory authority can control admission).

[0058] In general, a consortium blockchain network is private among the participating entities. In a consortium blockchain network, the consensus process is controlled by an authorized set of nodes, one or more nodes being operated by a respective entity (e.g., a financial institution, insurance company). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, each of which operates at least one node in the consortium blockchain network. Accordingly, the consortium blockchain network can be considered a private network with respect to the participating entities. In some examples, each entity (node) must sign every block in order for the block to be valid, and addedto the blockchain. In some examples, at least a sub-set of entities (nodes) (e.g., at least 7 entities) must sign every block in order for the block to be valid, and added to the blockchain.

[0059] In an exemplary embodiment, the consortium blockchain network may comprise a plurality of nodes (i.e., node operators). The plurality of nodes may have various access types, such as a first access type, a second access type, and a third access type. The first access type (e.g., full node access) may have access to and operate complete ledger replicas of the blockchain with independent query rights. Examples of Full Access Node operators include organizations such as Secure Community Network and Global Shield — trusted third-party entities with no operational relationship to the system. The second access type (e.g., light client access) may have verification access but are not authorized for running full infrastructure. The third access type (e.g., via Application Programming Interface access) may have authenticated access and may comprise courts and authorized auditors.

[0060] A blockchain is a tamper-proof, shared digital ledger that records transactions in a public or private peer-to-peer network. The ledger is distributed to all member nodes in the network, and the history of asset transactions occurring in the network is permanently recorded in the block. Prior to participating in a transaction, a node on the blockchain may need to execute computations using various techniques. Under current solutions, because each blockchain is independent, a node of one blockchain cannot communicate with other chains. For example, a node cannot read data from other blockchains or exchange data with other blockchains. In addition, even if a node does not need data from other blockchains to execute a computation, performing such computations entirely on a blockchain can consume a lot of time and computational resources of the blockchain, if it requires complicated computational logics and protocols.

[0061] Utilizing a blockchain network may ensure that once evidence is recorded, it cannot be altered or deleted. Utilizing a blockchain network may further provide a way to verify the evidence data by providing cryptographic proof that the evidence data was produced by the reported user at the time of generation. Utilizing a blockchain network may further provide privacy to the user of the system by maintaining the confidentiality of user data. Utilizing a blockchain network may also provide a scalable and reliable infrastructure. The blockchain network may be configured to integrate with various mobile device applications, such as iOS and Android mobile applications.

[0062] In various embodiments, the system may comprise a mobile application, such as an iOS or Android apps, used by users to capture and submit evidence. The system may further comprise abackend architecture that interacts with a blockchain network and handles data processing. The backend architecture may comprise servers, databases, and at least on Application Programming Interface (API) that operate together to power application functionality and manage data. The backend architecture may utilize Python-based services or other suitable programming language. In general, an API is a set of rules and protocols that enable different software applications to communicate with each other and exchange data or functionality.

[0063] In various embodiments, the system may utilize a security and governance service (e.g., AWS CloudTrail) to record API activity and user actions across the system to ensure audit logs, ITAR regulations, security monitoring, immutable log storage, access control, and evidentiary chain of custody and retention is assured. The security and governance service may provide information on who, what, when, and where within the system.

[0064] In a multi-blockchain network embodiment, the system may comprise a first private blockchain network configured to store the actual evidence data, which is signed with a private key, and a second private blockchain network configured to store hashes of the evidence along with a reference ID, which is signed with auser's device-specific key. In some embodiments, AWS Blockchain Services may be utilized to host the first and second private blockchains. In the present embodiment, the first private blockchain may be configured to securely store the actual evidence data (images, videos, text documents) in an immutable ledger. The data stored in the first blockchain may include raw evidence files and metadata, such as timestamps, GPS coordinates, and device information. The data stored in the first blockchain may include a digital signature, for example, the data may be signed with a private key. Access and permissions to the first blockchain may include read / write access that is restricted to authorized backend services. Users may access the first blockchain indirectly through the mobile application and backend services.

[0065] In the present embodiment, the second private blockchain may be configured to store hashes of the evidence data along with a reference ID, providing a verifiable link between the user and the evidence without exposing the actual data. The hashes may be generated using a cryptographic hash function (e.g., SHA-256). The second blockchain may also be configured to store a reference ID, such as a unique identifier linking to the evidence in the first blockchain. The data stored in the second blockchain may include a digital signature, for example, the data may be signed with the user's device-specific private key. Access and permissions to the second blockchain may include read access that is available to authorized parties for verification purposes.Write Access to the second blockchain may be restricted to the backend when processing user submissions.

[0066] Embodiments of the present system may comprise a user device configured to capture evidence (e.g., audio and video) and generate a unique private key. The system may further comprise a backend architecture configured to processes incoming data and interact with the first and second blockchains. The system may further comprise the first blockchain configured to store signed evidence data, and the second blockchain configured to stores hashes and reference IDs of the evidence. The system may further comprise a verification module configured to verify evidence authenticity and integrity.

[0067] Embodiments of the present system may provide security and cryptography through various keys and key management. For example, a private key may be used to sign evidence stored in the first blockchain. The private key may be stored in the backend architecture with strict access controls. In addition, a user-device key may be generated on the user's mobile device upon app installation and may be used to sign the hash and reference ID stored in the second blockchain. The user-device key may be stored securely on the device and may not be transmitted or stored elsewhere.

[0068] In various embodiments, the system may be configured to sign objects. For example, the evidence data may be signed with the private key from the backend architecture (a first signature), and the hash and reference ID may be signed with the user's device key (a second signature).

[0069] In various embodiments, the system may be configured to verify signatures. For example, the backend architecture may be configured to verify the first signature to confirm data integrity. The blockchain network may be configured to verify the second signature to confirm the origin of the data.

[0070] In various embodiments, a method may comprise evidence submission. Evidence submission may comprise capturing, by the user, evidence (e.g., audio and / or video) using the mobile app. Evidence submission may further comprise generating a device-specific key pair, including a first key and a second key. Evidence submission may further comprise signing the evidence with the first key and signing the hash and reference ID with a second key. Evidence submission may further comprise transmitting the data to the backend architecture over a secure connection.

[0071] The method may further comprise hashing and storing data. Hashing data may comprise generating, by the backend architecture, a hash of the evidence data. Storing the data may comprise utilizing the first blockchain to store the signed evidence data and the second blockchain to store the signed hash and reference ID.

[0072] The method may further comprise data retrieval. Data retrieval may comprise providing access to authorized parties to retrieve evidence and verify its authenticity using the first and second blockchains. Data retrieval may further comprise verifying the data by cross-referencing the signatures of the first and second blockchains to ensure data integrity and origin.

[0073] In various embodiments, the system may comprise AWS Blockchain Services, such as an Amazon Managed Blockchain to set up and manage private blockchain networks, an AWS Key Management Service to manage cryptographic keys used by the backend architecture, and Amazon S3 for auxiliary storage. The AWS Blockchain Services may provide scalability by leveraging its infrastructure to handle varying loads. The AWS Blockchain Services may further provide reliability by utilizing its high-availability features to ensure continuous operation. The AWS Blockchain Services may further provide security by applying desired security levels to network configuration and access control.

[0074] In various embodiments, the system may support mobile application integration for various platforms, such as iOS and Android. For example, platform-specific key management may be used to store device keys (Keychain for iOS, Keystore for Android).

[0075] In various embodiments, the user mobile device may generate a unique key pair (e.g., a private key and a public key) upon app installation and securely store the private key on the device. In some embodiments, the public key can be transmitted to the backend architecture.

[0076] In various embodiments, the system supports communication and data preparation. For example, the mobile app may prepare the data for submission to the backend architecture, including signing with the device key. In addition, the mobile app may communicate with the backend architecture using a secure Application Programming Interface (API) to transmit data to the backend. The system may also be equipped for error handling, such as error handling for network issues and key management failures.

[0077] In various embodiments, the backend architecture may comprise Python components, such as a server that handles incoming requests from a mobile app., a blockchain interface module that communicates with the blockchain network, security modules that handle cryptographicoperations and key management, and data processing that manages evidence data, hashing and data storage.

[0078] The back architecture may further comprise a plurality of APIs, such as a submission API to operate as an endpoint for a mobile app to submit evidence, and a verification API to operate as an endpoint for authorized parties to verify evidence.

[0079] The backend architecture may further comprise administration tools configured to monitor and manage the blockchain networks.

[0080] Embodiments of the present technology may feature immutability. For example, properties of the blockchain network provide inherent immutability. In addition, access controls may be implemented to restrict permissions to prevent unauthorized modifications.

[0081] Embodiments of the present technology may feature verifiability. For example, the system may employ various verification processes, such as verifying that the hash of the evidence matches between the first and second blockchains to ensure evidence integrity, validating the signature with the user’s public key to verify user authenticity, and verifying the timestamps by cross-checking timestamps to confirm the time the evidence was generated.

[0082] In one embodiment, the system may perform the following steps: Step 1: User Captures Evidence. In step 1, the user uses the mobile app on iOS or Android to capture images, videos, or text documents. Once evidence capture is complete, the evidence is ready for processing. Step 2: Device Key Generation. In step 2, the app generates a unique private-public key pair specific to the user's device. The private key is securely stored on the device (Keychain for iOS, Keystore for Android). Step 3: Evidence Signing and Hashing. In step 3, the evidence data is signed with a private key, a cryptographic hash (e.g., SHA-256) of the evidence is generated, and the hash and a reference ID are signed with the user's device-specific private key. Step 4: Data Transmission to Backend architecture. In step 4, the signed evidence data, along with metadata (timestamps, GPS coordinates), and the signed hash and reference ID are transmitted to the backend architecture over a secure HTTPS connection. Step 5: Backend Verification and Processing. In step 5, the backend architecture verifies the user's signature using the public key from the device, interacts with AWS Key Management Service (KMS) to securely handle the private key, and prepares data for storage on the blockchains. Step 6: Storage on First Private Blockchain. In step 6, the signed evidence data and metadata are stored on the First Private Blockchain to ensure immutability of the actual evidence data. Step 7: Storage on Second Private Blockchain. In step 7, the signed hash andreference ID are stored on the Second Private Blockchain to provide a verifiable link between the user and the evidence without exposing the actual data. Step 8: Evidence Retrieval and Verification. In step 8, authorized parties can request access to the evidence, confirm the hash of the evidence matches between both blockchains, validate signatures using the private and public keys, and verify the timestamps to ensure that the evidence was captured at the reported time. Step 8 ensures evidence is verified as authentic and untampered.

[0083] In various embodiments, various security measures are implemented to ensure that all data transmissions are encrypted. For example, private keys are securely stored and never leave their origin location. In addition, AWS KMS is employed to manages cryptographic keys for the backend architecture. Additionally, the system employs a private blockchain to ensure data cannot be altered once stored, and cross-referencing between blockchains provides proof of integrity and origin.

[0084] Within the system, a number of different agencies that are authorized to access the system may be defined. In one implementation, an administrator of the system is responsible for creating an Agency within the Toolkit and assigns a jurisdiction boundary to the Agency.

[0085] In various embodiments, the system may comprise a main database for storing data. The database may comprise a first sub-database and a second sub-database. The first sub-data base may comprise tier-1 data comprising the user’s own content, such as a user safety card (i.e., user safety profile), audio and / or video captured by the user, and the user’s media and documents. Access to the first sub-database may require a PIN-based identity verification with multifactor authentication, modeled on financial institution standards. Access to the first sub-database may be designed for quick access to the user in an active crisis situation, but is secure enough that an abuser cannot gain access without verified identity. In an exemplary embodiment, only the user has access to the first sub-database. No other party, including law enforcement, may be able to access the first sub-database without the user’s consent.

[0086] The second sub-database may comprise tier-2 and tier-3 data. The second sub-database may be governed by AWS KMS with External Key Store (XKS). The encryption key is held exclusively by the independent third-party consortium validator.

[0087] In various embodiments, Tier-2 data may comprise data provided by the individual through their Safety Card — data that has been made available through informed consent via the system’s terms and conditions. This data becomes accessible in the context of a 911 call, through the mobileApp, and / or because it lives in the user portal. It may include audio and video evidence captured via a camera. Tier-2 evidence is capable of being accessed within several minutes of a call for service — without a subpoena — provided that law enforcement has submitted justification through the evidence controller process in the First Responder Portal. This process supports swifter due process while still protecting the 4th Amendment. The user has provided the system with their informed understanding of what data they want released to law enforcement during a call. Tier-2 data is citizen-controlled. Some individuals may choose to withhold medical information or protection orders. Others — particularly those in fear for their lives — may want protection orders to proceed to law enforcement immediately. Access to the Tier-2 data may include a dual-control session. The dual-control session may include a Full Access Node party — the external blockchain verifier holding the token, existing entirely outside of system’s infrastructure - and a certified party — either a trained system representative or a designated law enforcement agency representative who has been trained and certified as a First Responder Digital Evidence Clerk. The certified party is trained specifically to protect the integrity of the evidence and to ensure that evidence has been uploaded correctly within their agency. In various embodiments, both parties must be present and logged for the session to proceed. No unilateral access is possible.

[0088] In various embodiments, the dual-control session itself may be video recorded and time-stamped and notarized to provide a witnessed, certified record of the vault opening that complements the cryptographic audit trail. This adds a human-witnessed evidentiary layer to the existing technical proof. In some embodiments, the video recording of the dual -control session is encrypted and stored along with other data in the evidence integrity pipeline. For example, the video recording may be hashed, signed, and written to the blockchain so that the record of the vault opening is protected by the same architecture as the evidence inside the vault.

[0089] In various embodiments, Tier-3 data may include the audio of the 911 call and law enforcement communications captured within the evidentiary evidence window — ranging from approximately 8 seconds to 2 minutes of automatic contemporaneous recording initiated at the moment of a 911 event. Access to Tier-3 data may be only by subpoena, upon formal determination that a crime has occurred, initiated by a judicial official, such as a prosecutor or District Attorney's office.

[0090] In an exemplary embodiment, the 911 audio is captured automatically and encrypted immediately upon capture. It is never released to the citizen user under any circumstances — notat the time of the incident, not afterward, and not through the user portal. The 911 audio is held in second sub-database under the same external key hold architecture as Tier-2.

[0091] In various embodiments, the three-tier classification provides constitutional protection to three distinct parties:Party Constitutional Protection Architectural EnforcementCitizen / 4th Amendment — privacy and Tier One MFA; consent-governed Victim consent access; instant retrieval in crisisLaw 4th Amendment — communications Tier Three subpoena-only access;Enforcement and investigative integrity architectural inaccessibility to citizenWitnesses Privacy and identity protection Tier Three subpoena-only access;enforced at infrastructure level

[0092] In various embodiments, the system begins recording evidence before connection to 911. For example, when the user triggers the system — either by pressing an emergency button or by speaking a personally trained voice phrase — the app may immediately and simultaneously: begins recording audio and video in the background on the device, initiates a VoIP call to the nearest PSAP, sends the user's Safety Card to the First Responder Portal, sends location (GPS + civic address) to emergency services, and notifies the user's emergency contacts via SMS.Accordingly, the mobile app may start recording audio and / or video up to 10 seconds prior to the connection with the 911 operator. These five actions may execute in parallel from a single trigger. Evidence recording does not wait for the 911 connection to succeed. The system captures what is happening before, during, and after the emergency call — producing a continuous evidentiary timeline beginning at the moment the user perceives danger.

[0093] In various embodiments, the 911 call is triggered by voice-activation. The user may train a personal secret phrase by recording it in multiple intonations. The mobile app listens continuously in the background using on-device voice recognition. When the phrase is detected, the full emergency and evidence pipeline triggers automatically.

[0094] In various embodiments, the system may provide offline evidence capture. For example, if the device has no network connectivity at trigger, the system records evidence locally with on-device cryptographic signatures. When connectivity is restored, the evidence is uploaded to the backend architecture, counter-signed, and entered into the full evidence integrity pipeline. Dualtimestamp comparison provides transparency about any delay between capture and upload.

[0095] In various embodiments, the system may be configured to create two independent cryptographic signatures at the moment of evidence capture. A first signature may be a device signature, wherein the mobile device computes a hash of the evidence payload and signs it with a private key generated on the device that never leaves it. This proves which device captured the evidence. A second signature may be a backend counter-signature, wherein the backend architecture independently re-computes the hash, verifies the device signature, and adds its own counter-signature with an ingestion timestamp. A hash mismatch rejects the upload.

[0096] In various embodiments, the signing algorithms use post-quantum resistant schemes, ensuring evidence signed today remains verifiable against future quantum computing capabilities.

[0097] In various embodiments, the system may be configured to provide immutable storage and timestamp anomaly detection. For example, evidence may be stored in government cloud infrastructure using write-once, read-many (WORM) storage with compliance-mode object locks, and files may be replicated across geographically separated regions. Timestamp anomaly detection compares device creation time and backend ingestion time automatically. Any detected anomalies may be preserved alongside evidence for court interpretation and may be never discarded. Data may be retained for the duration required by applicable statutes of limitations, with a target retention of seven to ten years or longer. Evidence deletion may be a separate controlled process independent of account closure by the user.

[0098] In various embodiments, the system may be configured to validate data using a blockchain network. For example, every evidence event may be written individually — hashed and signed — to a private consortium blockchain in real time or near real time. In an exemplary embodiment, internal hash chains are not used and there is no Merkle tree roll-up step. Instead, each piece of evidence is validated independently and externally at the moment of creation.

[0099] In various embodiments, the system may be configured to provide a verification portal and court-ready reporting. For example, authorized parties may verify evidence integrity through their appropriate access tier. The system may generate human-readable chain-of-custody reportstranslating cryptographic proof into plain-language narratives for courts, juries, and non-technical audiences. Three independent proofs may be available for any piece of evidence: 1) Dual Signature Verification, which verifies which device captured it and that the system received it intact; 2) Hash Verification, which re-computes the hash and compares to the recorded value; and 3) Distributed Ledger Verification, which verifies against any independent consortium node without the system’s involvement or cooperation.

[0100] In various embodiments, the court-ready reporting may be generated to serve various parties. For example, for lawyers, the reporting may include discovery and case preparation documents for prosecutors and defense attorneys; for a judge, the reporting may include evidentiary foundation documents presented during proceedings to establish chain of custody for the record; and for juries or jury selection, the reporting may include plain-language narrative documents designed for a civilian audience during voir dire, translating the technical architecture into a story a jury can understand and trust without technical background.

[0101] In various embodiments, the system may incorporate artificial intelligence or machine learning. For example, the system architecture may include automated processing of all evidence using artificial intelligence and machine learning: speech recognition on uploaded audio, object recognition in visual data, and OCR of handwritten materials. This may enable investigators to search across all evidence types and surface related evidence automatically.

[0102] In various embodiments, the system may provide two access points to evidence for law enforcement. A first access point may comprise the First Responder Portal, wherein law enforcement may access the user’s Safety Card, user location, and associated evidence delivered directly to the First Responder Portal. A second access point may comprise a Direct API to agency system, wherein evidence and user data is transmitted simultaneously to the agency’s own Computer-Aided Dispatch (CAD) system or Records Management System (RMS).

[0103] In various embodiments, the system may be configured to receive third-party evidence. For example, third-party systems — body cameras, in-car video, surveillance cameras — may be able to submit evidence into the system’s chain of custody through a published API. Upon entry, the backend architecture signs, timestamps, and enrolls the evidence in the same integrity pipeline: WORM storage, external consortium blockchain validation, and verification portal.

[0104] In various embodiments, the system may be configured to correlate evidence from multiple devices. For example, when multiple users or devices capture evidence related to the sameincident, the system correlates that evidence into a single case through a combination of reference ID, location, time and date stamp, and jurisdiction. Each piece of evidence retains its own independent chain of custody, but the shared reference data points allow the system to recognize that multiple evidence sources belong to the same incident and organize them accordingly within a single case file.

[0105] In various embodiments, the system may comprise a built-in database search engine for correlating multi-device evidence across cases. The database search engine may comprise a dedicated search infrastructure or an Al layer to surface and organize related evidence intelligently.

[0106] In various embodiments, the system may be configured to correlate evidence across codefendants within a single case. For example, a co-defendant case may occur cross jurisdictionally and with the reference ID from the system, the evidentiary process can simplify and streamlined by cross correlating identification, time, location, and date stamping of the evidence data. These variables will provide efficiency within the blockchain evidentiary process if two defendants or multiple defendants need their evidence to be pulled for the same case. The reference ID may be a unique identifier given to every user and is systematically aligned to the user for discovery purposes and identity purposes.

[0107] In various embodiments, and referring to Figure 13, the system may perform the following steps:

[0108] Step 1: User Triggers Emergency. In step 1, the user presses the emergency button or speaks their trained voice phrase. In step 1, the system confirms location permissions and phone number verification.

[0109] Step 2: Parallel Execution. In step 2, five actions launch simultaneously: 1) background audio / video recording begins on device; 2) VoIP call initiates to nearest PSAP; 3) Safety Card and location sent to First Responder Portal and agency systems via API; 4) safety profile pushed to public safety data exchange; 5) SMS sent to emergency contacts.

[0110] Step 3: 911 Call Routing. In step 3, SIP proxy routes the call to the appropriate PSAP based on user location. The system delivers the user Safety Card, authenticates public safety API, and executes call routing.

[0111] Step 4: Fallback if Call Fails. In Step 4, the backend architecture originates a new VoIP call to PSAP, plays pre-recorded alert, and delivers the user Safety Card URL, ALI data, and ANI callback number. Dispatch proceeds without live voice contact.

[0112] Step 5: Evidence Secured at Capture. Tn step 5, evidence is hashed and signed on-device with the user's device-specific private key. Upon upload, backend counter-signs and writes evidence to WORM-locked government cloud storage. 911 audio is immediately classified as Tier Three, encrypted, and written to Database Two under external key hold. Device and backend timestamps are compared for anomaly detection. Offline evidence is stored locally with on-device signatures and uploaded when connectivity returns.

[0113] Step 6: External Consortium Blockchain Validation. In step 6, every piece of evidence is written individually — hashed and signed — to the private consortium blockchain in real time or near real time. There is no internal hash chain. There is no Merkle tree roll-up. Each piece of evidence is externally validated independently at the moment of creation. AWS CloudTrail logs are written to the blockchain simultaneously.

[0114] Step 7: Evidence Access and Verification. In step 7, Tier One data is accessible to the user via PIN-based MFA through the citizen portal. Tier Two data is accessible via dual -control session with consortium validator. Tier Three data (911 audio) is accessible only by subpoena upon formal determination of a crime. Law enforcement accesses evidence through the First Responder Portal and direct CAD / RMS API integration. Every access is logged immutably on the consortium blockchain.

[0115] Step 8 — Court-Ready Reporting The system generates human-readable chain-of-custody reports translating cryptographic proofs into plain-language narratives for courts, juries, and nontechnical audiences. The prosecutor can state: the system does not hold the decryption key. No system engineer can access this data. The reporting citizen cannot access the 911 audio. Access requires an independent third party. No single entity controls the integrity of this evidence. In an exemplary embodiment, the system may be configured to provide an output of evidence data when a request by an authorized individual from a criminal justice system (e.g., justice official or law enforcement) is sent and approved, and the system may provide the requesting party with an encrypted link of evidence that will only be available to that authorized individuals for viewing.

[0116] In various embodiments, and referring to Figure 1, a user may utilize a system for making an emergency call. The user may first download a mobile application (app) onto a mobile device, such as a cell phone, and sign up and subscribe for services offered by the system. The user may then use the system to collect evidence data on the user’s mobile device and make emergency calls. The collected evidence may be uploaded to a user portal and / or continue to be stored on the mobiledevice. Tn an emergency situation, the user may activate an emergency call to 911. Activation of the emergency call may signal the system to automatically perform various functions, such as routing the call to emergency services, recording the call, sharing a user safety card with a First Responder Portal and a Toolkit, sharing the user’s location with the First Responder Portal and Toolkit, and transmitting an SMS to a backend architecture of the system. Activation of the emergency call may also signal the system to automatically enable the mobile app to record audio and / or video and upload any recorded data to the user portal. The Toolkit may be accessed and managed by a system administrator and may be accessible via the user portal.

[0117] In various embodiments, and referring to Figure 2, the user may use the system to make contact with a first responder. For example, the user may use the mobile app to make an emergency call. The mobile app may route the emergency call via a signaling protocol, such as Session Initiation Protocol (SIP), to an Emergency Call Center. The signaling protocol may then send an event signal to a backend architecture (or a blockchain network). The backend architecture (or blockchain network) may then send an event signal to the First Responder Portal and event details to the CAD. The backend architecture (or blockchain network) may also send an SMS emergency message to a designated emergency contact.

[0118] In various embodiments, and referring to Figure 3, the system may automatically collect and store evidence data. For example, the user may employ the mobile app to record video through a camera. The camera may be one integrated into the mobile device or an external camera in communication with the mobile device. The recorded video is then transmitted to the user portal where it is stored. The user may also employ the mobile app to record audio through a microphone. The microphone may be one integrated into the mobile device or an external microphone that this in communication with the mobile device. The recorded audio is then transmitted to the user portal where it is stored. The user may also employ the mobile app to make emergency calls to a first responder, such as a 911 emergency service. The audio data from the emergency call may be recorded and transmitted to the user portal where it is stored. The user may also employ the mobile app to record personal information on a user safety card, such as Personal identification information (name, photo, physical description, date of birth), Medical information (conditions, medications, allergies, blood type, physician contacts), Emergency contacts (names, phone numbers, relationships), Threat context (active restraining orders, known threats, prior incidents, custody arrangements), and Situational notes (free-form text describing current situation orrelevant context). The information on the user safety card may be transmitted to the user portal where it is stored.

[0119] In various embodiments, and referring to Figure 4, law enforcement may request access to evidence data using the system. For example, law enforcement may submit a request for evidence data for a particular event through the First Responder Portal. This request may be forwarded to a discovery controller who can approve or deny access. If approved, the evidence data is released to the requesting law enforcement.

[0120] In various embodiments, and referring to Figure 5, portions of the system may be accessible to various entities and individuals. For example, the mobile app and user portal may be accessible to the user. The Toolkit may be accessible only to a first responder. The First Responder Portal may be accessible to a first responder and law enforcement.

[0121] In various embodiments, and referring to Figure 6, law enforcement may request access to additional information and evidence data from a specific event. For example, law enforcement may submit a request for more evidence data from an event, wherein law enforcement provides justification for the request. The request is analyzed by an Evidence Controller who is an individual who has the control to release evidence data in a particular jurisdiction and may be appointed by state statute, local statute, or national statute. . If the request is approved, a dossier is created and shared through an authenticated and encrypted page or file.

[0122] In various embodiments, and referring to Figure 7, the user may initiate an emergency call and activate various automatic functions of the system. For example, the user may initiate an emergency call by manually pressing an emergency call button within the mobile app. Alternatively, the user may initiate an emergency call by using a voice activation feature of the mobile app. Once the call is initiated, if the user’s location is unknown, the system determines the user’s location through the mobile device permission setting. Once the system determines the user’s location, the system may verify the user’s phone number. If unverified, the system will generate an error message. If the phone number is verified, the system may execute various functions in parallel. For example, the system may send an emergency SMS message to the user’s emergency contacts, send various information (such as the user safety card, user location, recorded audio and / or video) to the First Responder Portal, send various information (such as the user’s safety card, location, and reference ID) to emergency services, and call 911 to connect with an emergency operator.

[0123] In various embodiments, and referring to Figure 8, the system may incorporate Voice over IP (VoIP) for calls and communications. For example, a user initiates a call from the mobile app, it first connects through our Audio Scripts of Linphone to connect it's audio before connecting to our SIP server prior to passing the payload of the data onto the 911 integrator who will then deliver the information onto that user's 911 center, who will then deliver that information into the 911 systems and Computer Aided Dispatch.

[0124] In various embodiments, and referring to Figure 9, the mobile application may communication with a backend architecture. For example, the API may be utilized to facilitate transmission of all the front end data from the mobile devices into the backend data into the secure data storage system (e.g., GovCloud) where it resides in the database for safe keeping and then locked in the vault of the blockchain network.

[0125] In various embodiments, and referring to Figure 10, the backend architecture may communicate with a first responder and the mobile app to transmit various data. For example, data such as the emergency event, user safety card, call recording / audio data, and / or video data may be transmitted to the first responder or other desired entity.

[0126] In various embodiments, and referring to Figure 11, the user may activate an emergency call using a voice activation feature of the mobile app. The user may train the system to recognize a particular trigger word or phrase and user’s voice. For example, the user may record his / her voice in different volumes using the same word or phrase or in different environments using the same word or phrase. The designated word or phrase may then be used by the user to trigger an emergency call. The voice data used to train the system may be stored in the backend architecture and a local database. The mobile app may be configured to continuously listen for the trigger word or phrase. If the mobile app detects a match with the stored trigger word or phrase, the mobile app initiates an emergency call.

[0127] In various embodiments, and referring to Figure 12, a system 1300 may be configured to transmit data from various sources, store data, and allow access to that data. For example, the system 1300 may comprise a user device 1305, a server 1310, and a data storage system 1335. A user 1320 may operate the user device 1305. The user device 1305 may be communicatively connected to the data storage system 1335 and the server 1310.

[0128] The data storage system 1335 may comprise a first database 1340 for storing data and a second database 1345 for storing data. The data stored in the first database 1340 (also referred toas Tier 1 data) may be accessed, such as by viewing or downloading, by the user 1320 of the system 1300. The second database 1345 may comprise a first sub-database 1350 and a second sub-database 1355. Data stored in the first sub-database 1350 may be referred to as Tier 2 data and may comprise at least a portion of the data stored in the first database 1340. Data transmission from the first database 1340 to the second database 1345 may occur automatically or by a manual operation by a node party of the blockchain network. Data stored in the first sub-databased 1350 may be accessed only by a node party of the blockchain network and a certified party, wherein both the node party and the certified party must be present together to access the data. Data stored in the second sub-database 1355 may be referred to as Tier 3 data and may be accessed only by justice officials 1330 through the use of a subpoena. In an exemplary embodiment, data stored in the second database 1345 may be inaccessible to the user 1320. In addition, data stored in the first database may be accessible only to the user 1320.

[0129] The user device 1305 may enable the mobile app. The user device 1305 may comprise an audio detection device, such as a microphone. The user device 1305 may further comprise an image sensor for capturing images and / or video, such as a camera. The mobile app may utilize the microphone and camera in operation to record or otherwise capture audio and / or image data. Audio and image data (i.e., first data DI) captured by the user device in conjunction with the mobile app may be transmitted to the data storage 1335. In an exemplary embodiment, the first data DI may be transmitted to the first database 1340.

[0130] In various embodiments, the user device 1305 may be configured to communicate with the server 1310. For example, the user device, during an emergency call to 911, may transmit the audio data from the 911 call (i.e., second data D2) to the server 1310. The server 1310 may then transmit the second data D2 to the data storage system 1335. In an exemplary embodiment, the server 1310 may transmit the second data D2 to the second sub-database 1355.

[0131] In various embodiments, the data storage system 1335 may be configured to receive third data D3 from an external agency, such as a law enforcement agency 1315. Third data D3 may comprise law enforcement communications among the agency, documents / forms prepared by the law enforcement agency, and the like. In an exemplary embodiment, the third data may be stored in the second sub-database 1355.

[0132] The preceding detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments.

[0133] As used herein, the words “various” and “exemplary” means “serving as an example, instance, or illustration.” Any implementation described herein as various or exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, or detailed description.

[0134] The connecting lines shown in the various figures contained herein are intended to represent exemplary functional relationships and / or physical couplings between the various elements. It should be noted that many alternative or additional functional relationships or physical connections may be present in an embodiment of the subject matter. In addition, certain terminology may also be used herein for the purpose of reference only, and thus are not intended to be limiting, and the terms “first”, “second” and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context.

[0135] The foregoing description refers to elements or features being “connected” or “coupled” together. As used herein, “connected” and “coupled” are used interchangeably. As used herein, unless expressly stated otherwise, “connected” and “coupled” means that one element is directly or indirectly joined to (or directly or indirectly communicates with, electrically or otherwise) another element, and not necessarily mechanically. Thus, although the backpacks shown in the figures depict exemplary arrangements of elements, additional intervening elements, devices, features, or components may be present in an embodiment of the depicted subject matter.

[0136] While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or various embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, which includes known equivalents and foreseeable equivalents at the time of filing this patent application.

Claims

CLAIMSWhat is claimed is:

1. A system, comprising:a user device, operable by a user, supporting an application configured to:activate an emergency response, in response to a trigger by the user, comprising: capturing evidence data;connecting to an emergency service;timestamping the evidence data;encrypting the evidence data with device signature generated by the user device;transmitting user profile data to the emergency service; and transmitting user location data to the emergency service;a data storage system, having a write once, read many architecture, communicatively connected to the user device and configured to receive the encrypted evidence data and apply a counter-signature to the encrypted evidence data; the data storage system comprising a first database and a second database, wherein the first database is accessible by the user and the second database is accessible to a certified party and inaccessible to the user; anda consortium blockchain network configured to validate the encrypted evidence data stored in the data storage system and comprising a plurality of full access nodes.

2. The system of claim 1, wherein capturing evidence data and connection to the emergency service are performed simultaneously.

3. The system of claim 1, wherein:the evidence data comprises audio data and video data; anduser profile data comprises personal identification information of the user, medical information of the user, emergency contacts of the user, and threat context.

4. The system of claim 1, wherein activating the emergency response further comprises notifying an identified emergency contact of the user.

5. The system of claim 1, wherein the first database comprises first -tier data and the second database comprises second-tier data and third-tier data.

6. The system of claim 6, wherein the third-tier data is accessible only by a subpoena.

7. The system of claim 6, wherein the second-tier data is accessible via a dual-control session, wherein the dual-control session comprises the certified party and one full access node from the plurality of full access nodes.

8. The system of claim 6, wherein the data storage system is further configured to receive emergency call data from the emergency service and store the emergency call data in the second database, and wherein the emergency call data is third-tier data.

9. The system of claim 1, wherein the trigger is a user-trained voice recognition program.

10. The system of claim 1, wherein the trigger is a button on the user device that is manually activated by the user.

11. A method, comprising:activating an emergency response comprising:connecting a user device to an emergency service and capturing evidence data; timestamping the evidence data;encrypting the evidence data with a device signature generated by the user device;andtransmitting user profile data to the emergency service; andsecuring the evidence data in a data storage comprising:receiving the encrypted evidence data from the user device;applying a counter-signature, with a timestamp including a date and time of receipt by the data storage, to the encrypted evidence data;storing the encrypted evidence data in the data storage; andreplicating the encrypted evidence data across multiple regions of the data storage; andvalidating the evidence data comprising:recording activity of the evidence data on a blockchain network.

12. The method of claim 12, wherein activating the emergency response comprises activating the emergency response via a user-trained voice recognition program.

13. The method of claim 12, wherein activating the emergency response comprises activating the emergency response via a button on the user device by a user.

14. The method of claim 12, wherein the evidence data comprises audio data and video data.

15. The method of claim 12, wherein the data storage comprises a write once, read many architecture.

16. The method of claim 12, wherein the blockchain network is a private permissioned consortium blockchain.

17. The method of claim 10, wherein the blockchain network comprises a plurality of node operators comprising a law enforcement agency, a district attorney office, and a public defender.

18. The method of claim 18, wherein each node operator has an access type selected from a first access type, a second access type, and a third access type; wherein the first access type has access to complete ledger replicas of the blockchain.

19. The method of claim 12, wherein the data storage comprises a first tier, a second tier, and a third tier; wherein the first tier is accessible by the user via PIN -based identity verification with multifactor authentication, the second tier is inaccessible by the user, and the third tier is accessible only by a subpoena.

Images