WO2025085969A1 - Communications systems and methods - Google Patents

Abstract

A secure communications method for providing secure digital communications to users of a legacy communications system is described. The method comprises, in a secure digital-ledger technology based communication system, receiving, on a data interface of a server of the communication system, a communication associated with a recipient, the recipient associated with a legacy address. The method stores the communication on a secure immutable data store associated with the server, and sends a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address. The method comprises enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

Description

Communications Systems and Methods

Cross-Reference to Related Applications

[0001] The present application claims priority from Australian Provisional Patent Application No 2023903445 filed on 27 October 2023, and from Australian Provisional Patent Application No 2023903444 filed on 27 October 2023, the contents of which are incorporated herein by reference.

Technical Field

[0002] The present disclosure broadly relates to the communication of data and, more particularly, to a system for, and a method of, secure data communication that accommodates legacy addresses.

Background

[0003] Many industries, such as the healthcare industry, have long had strict requirements regarding communications, to ensure sensitive information remains protected. This has resulted in the slow adoption of digital communications technology for the communication of sensitive information, as it has lacked the security required for such sensitive information. As an illustrative example, ordinary email is generally not considered sufficiently secure for sending sensitive information, as it is vulnerable to interception.

[0004] More recently, secure messaging systems have been introduced for such purposes, where secure messages are sent between parties using one or more secure messaging providers. These systems require the senders and recipient(s) to log into the system to send and receive messages. The channels to and from the system (i.e. between the sender and the system, and between the recipient and the system) are encrypted, thereby preventing unauthorised interception of data. [0005] One problem with such currently existing secure messaging systems is that both parties in the communication need to use the secure messaging system. During deployment of secure messaging systems, when many users have not yet created an account, secure communication is problematic. In particular, if a recipient does not have a secure messaging account, it is not possible to send secure communications. This often results in various systems operating in parallel, including new and old.

[0006] Furthermore, similar communications problems exist in other industries, particularly where sensitive information is being handled, including in the banking and finance sectors, education, and legal industries.

[0007] As such, there is clearly a need for improved communications systems and methods.

[0008] Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application.

Summary

[0009] The present disclosure relates to communications systems and methods, which may at least partially overcome at least one of the abovementioned disadvantages or provide the consumer with a useful or commercial choice.

[0010] With the foregoing in view, the present disclosure in one form, resides broadly in a secure communications method for providing secure digital communications to users of a legacy communications system, the method comprising: in a secure digital-ledger technology based communication system: receiving, on a data interface of a server of the communication system, a communication associated with a recipient, the recipient associated with a legacy address; storing the communication on a secure immutable data store associated with the server; sending a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

[0011] Advantageously, the system enables communications to be held in escrow until the recipient creates a secure communications account, at which time they may access the communications in a secure manner. This further alleviates the need for a sender to keep track of whether a user has created a secure communications account or not.

[0012] This is particularly useful when a secure communications system is being deployed, as it alleviates the need to know account details for other users, and in particular users that have not yet created a secure communications account.

[0013] The method may include enabling the recipient to generate the secure communications account.

[0014] The method may comprise: determining that the legacy address is not associated with a secure communications account, wherein the notification includes instructions regarding how to generate a secure communications account. [0015] Such configuration may enable the method to notify the recipient of the communication using legacy communications, upon which the recipient may create a secure communications account to access the communication.

[0016] The communication may comprise a message.

[0017] The communication may comprise text. The communication may comprise images.

[0018] The communication may comprise a combination of text and images.

[0019] The communication may include one or more of documents, images, audio, text, or files.

[0020] The method may include generating the notification communication. The notification communication may comprise a text message, fax message, email communication, physical communication, or any other suitable communication.

[0021] In one or all embodiments, the notification communication may include a link to a secure communications system. The link may be selectable by the user. In one or all embodiments, the link comprises a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).

[0022] The notification communication may be, at least partly, automatically generated.

[0023] The recipient may be authenticated when requesting the communication. The recipient may be authenticated using a key associated with the recipient. The key may, for example, comprise a key of a public / private key pair.

[0024] The legacy address may comprise a telephone number (e.g. for SMS communications), a fax number, an email address, a street address (e.g. for postage), or any other suitable legacy address. [0025] The method may include determining a type of legacy communication, wherein communications are sent using a selected legacy communications system of a plurality of legacy communications systems according to the determined type of communication. This enables a single system to work with multiple communications systems, e.g. fax and SMS.

[0026] The method may include generating the secure communications account for the recipient. The method may include verifying an identity of the recipient, and generating the secure communications account upon verifying the identity of the recipient.

[0027] The communication may be encrypted.

[0028] The method may include decrypting the received communication, and subsequently encrypting the communication using a key associated with the secure communications account.

[0029] In one or all embodiments, such decryption of the communication at the server is only performed on initial communication. Subsequent communication may be encrypted end-to-end.

[0030] Communications may be encrypted using a key of the recipient, a key of a sender, or a shared secret. The shared secret may be generated using keys of the sender and recipient.

[0031] The communication may be encrypted prior to being received by a server.

[0032] The method may further include encrypting, at a computing device of the sender, the message.

[0033] Subsequently, end-to-end encryption may be provided between the sender and recipient. [0034] According to an example, the communication is received from a sender.

[0035] According to an example, the sender is associated with a secure communications account. An identity of the sender may be verified by the system.

The identity of the sender may be authenticated using a key associated with the sender.

[0036] According to an example, the method includes determining that the legacy address is associated with a secure communications account of a secure communications system of a plurality of secure communications systems, wherein the communication on the data store is associated with the secure communications system.

[0037] Such configuration enables the method to work with a variety of secure communications systems, and without requiring a sender to check each of a plurality of communications systems.

[0038] The method may include authenticating the recipient, wherein the communication is provided to the recipient upon authenticating the recipient.

[0039] The recipient may be authenticated using a digital signature. The digital signature may be generated using public key private key cryptography. The digital signature may comprise an electronic, encrypted stamp of authentication.

[0040] According to one or all embodiments, the sender is authenticated.

[0041] The sender may be authenticated using a digital signature. The digital signature may be generated using public key private key cryptography. The digital signature may comprise an electronic, encrypted stamp of authentication.

[0042] The sender and receiver may be associated with user identifiers (IDs). Public and private keys may be associated with the user IDs.

[0043] The sender and receiver may be verified prior to allocation of a user ID. [0044] The method may include verifying the sender and/or recipient using a phone number, fax number, and/or email address.

[0045] The method may include receiving identity documents of the sender and/or recipient, such as a driver’s license, and performing an identity check based thereon.

[0046] The method may include performing third-party verification of an identity of the sender and/or recipient.

[0047] Different levels of verification may be used based upon a role of the sender and/or recipient.

[0048] The user ID may be published on an online directory. The online directory may include other details of the user, such as a name, address or the like. The online directory may be searchable.

[0049] The user ID may be associated with one or more of a fax number, a mobile number and an email address. Such configuration enables messages to be sent to a user using a fax number, a mobile number and an email address, without necessarily knowing the user ID.

[0050] The communication may be stored on the data store in an encrypted manner.

[0051] The data store may encrypt data using AES-256 encryption.

[0052] The server may comprise one or more server devices collaborating to function as a server. In particular, the one or more server devices may include multiple computing devices operating in a cloud environment.

[0053] The method may include generating, using the at least one processor, a cryptographic hash of at least part of the communication. [0054] The cryptographic hash, or a derivative thereof, may be stored, on a blockchain.

[0055] The method may include generating an event item relating to the communication, wherein a cryptographic hash of the event item is stored on the blockchain.

[0056] The event item may include a cryptographic hash of the communication. The communication may be encrypted, and the event item may include a cryptographic hash of the encrypted communication.

[0057] The event item may include a timestamp.

[0058] The event item may include an event identifier. For example, the event identifier is unique across a plurality of events.

[0059] The method may include generating event items relating to interactions with the communication. For example, cryptographic hashes of the event items are also stored on the blockchain.

[0060] The events may include or be associated with metadata. The metadata may include (but not be limited to) timestamp data, a sender identifier and a recipient identifier.

[0061] The interactions may include delivering a communication (e.g. a message) to an inbox of the recipient, the recipient viewing a communication, and the recipient sharing a communication.

[0062] The method may include validating the message by regenerating the cryptographic hash.

[0063] The method may include validating one or more interactions with the message using the blockchain. [0064] According to another embodiment, the disclosure resides broadly in a secure digital-ledger technology based communications system comprising: at least one computing device including: a data interface; a secure immutable data store a processor coupled to the data interface; and a memory, coupled to the processor, the memory including instruction code executable by the processor for: receiving, on the data interface, a communication associated with a recipient, the recipient associated with a legacy address; storing the communication on the secure immutable data store; sending a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

[0065] According to yet another embodiment, the disclosure resides broadly in a non- transitory computer-readable medium including instruction code stored thereon, the instruction code when executed by one or more processors, cause the one or more processors to: receive, on a data interface, a communication associated with a recipient, the recipient associated with a legacy address; store the communication on a secure immutable data store of a secure digitalledger technology based communication system; send a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enable the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

[0066] Any of the features described herein can be combined in any combination with any one or more of the other features described herein within the scope of the disclosure.

[0067] Throughout this specification the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Brief Description of Drawings

[0068] Embodiments of the disclosure are now described by way of example with reference to the accompanying drawings in which:

[0069] Figure 1 illustrates an embodiment of a communications system.

[0070] Figure 2 illustrates an embodiment of a screenshot of a messaging application, including a notification.

[0071] Figure 3 illustrates an embodiment of a screenshot of a secure message screen.

[0072] Figure 4 illustrates an embodiment of a communications method.

[0073] Figure 5 illustrates part of an embodiment of a communications system. [0074] Figure 6 illustrates an embodiment of a simplified schematic of a message payload of the communications system of Figure 5.

[0075] Figure 7 illustrates an embodiment of a simplified schematic of a sent event item of the communications system of Figure 5.

[0076] Figure 8 illustrates an embodiment of a delivered event item of the communications system of Figure 5.

[0077] Figure 9 illustrates an embodiment of a simplified schematic of a portion of the blockchain of the communications system of Figure 5.

[0078] Figure 10 illustrates an embodiment of a communications method.

[0079] Figure 11 shows an embodiment of a communications system.

[0080] Figure 12 is a block diagram of an example embodiment of a computing device.

[0081] In the drawings, like reference numerals designate similar parts.

Detailed Description

[0082] Embodiments of communications systems and methods are described below that provide confidentiality, auditability and authentication when parties communicate data, such as documents or other communications, with each other remotely.

[0083] Figure 1 illustrates an embodiment of a communications system 100.

[0084] The communications system 100 includes one or more servers 105 (with associated databases, not shown), through which secure communications may be transmitted. [0085] The secure communications system of the present disclosure uses distributed ledger technology (DLT).

[0086] Distributed ledger technology (DLT) refers to the technological infrastructure and protocols that enable simultaneous access, validation, and record updating across a networked database. DLT underpins blockchains and allows users to see any changes and identify who made them. This reduces the need for data audits, ensures data reliability, and restricts access to only those who require it. DLT is a database distributed across multiple locations, such as countries, institutions, or sites. In a DLT, records are stored sequentially in a continuous ledger.

[0087] Blockchain is a specific type of DLT that stores data in cryptographically linked blocks. Each block connects to the one before and after it, forming an irreversible chain of data. Once data is added to a block, it cannot be changed or deleted without the network's consensus. This means that all data handled by the system becomes secure and immutable.

[0088] Within the context of a secure messaging system supported by a computer system, the term "legacy communication system" refers to older or traditional communication platforms and methods that are not inherently designed to support modem security features such as encryption, authentication, or secure transmission protocols. These systems include: a. Ordinary email systems (e.g., SMTP-based email services without encryption or with outdated security practices). b. Fax machines or traditional paper-based communications. c. Unencrypted text messaging (SMS). d. Older voice communication systems, such as landlines or non-secure VoIP systems. e. Basic file-sharing systems that lack encryption or secure access controls.

[0089] Legacy systems typically lack the ability to ensure the protection of sensitive information, making them vulnerable to interception, unauthorized access, or data breaches. As a result, they are insufficient for handling secure communications, especially in industries such as healthcare, finance, and legal sectors. In a secure messaging context, these systems need to be replaced or integrated with newer technologies that provide the necessary security.

[0090] Referring to Figure 1 of the drawings, the system supports a secure communication platform that enables secure messaging using distributed ledger technology (DLT), for example blockchain. The secure communication system is configured to interface with legacy communication systems, and supports various secure ways of contacting users and enabling secure access to messages.

[0091] The combination of an event- sourcing database with blockchain recording of event-hashes presents a novel and powerful approach to building a secure communication system, particularly in industries like healthcare where privacy and security are critical. In this system, every action, or "event," in the communication process — such as sending, receiving, or accessing a message — is logged in an eventsourcing database. Each event is stored as a separate record, preserving a detailed history of every change or interaction. This approach ensures that the system maintains a complete and accurate log of all activities, which can be reconstructed at any time to understand exactly how the communication evolved.

[0092] What makes this method especially secure and innovative is the integration of blockchain technology to record the hashes of these events. A hash is a cryptographic representation of data that is unique to the event. By storing these hashes on a blockchain, which is a decentralized and tamper-proof ledger, the system creates an immutable record of all events. This means that even if someone tried to alter the data in the event-sourcing database, the hashes stored on the blockchain would not match, immediately revealing any tampering. This combination of event- sourcing and blockchain ensures that all communications are both securely logged and verifiable, providing a level of transparency and integrity that is essential in industries like healthcare.

[0093] In the medical industry, where protecting patient data is paramount, this system offers a strong guarantee that sensitive communications, such as those involving medical records, diagnoses, or consultations, are handled with the highest level of security. The ability to audit every step of the communication process — without any risk of the data being altered or tampered with — ensures compliance with strict privacy regulations like HIPAA, while also building trust between patients, healthcare providers, and regulators.

[0094] The use of an event- sourcing database is critical in this setup because it not only captures every change as a distinct event but also allows the system to maintain a clear historical record without ever overwriting data. This differs from traditional databases, where changes might overwrite previous information, potentially obscuring the original data. In a secure communication system, having this complete event history is essential for auditing and ensuring that no unauthorized alterations have taken place.

[0095] Blockchain also plays an important role in improving security when it comes to storing user addresses within the system. By storing the hashed addresses on the blockchain, the system ensures that these addresses — such as email addresses or other identifiers — cannot be altered or tampered with. This prevents malicious actors from interfering with the communication process, such as rerouting sensitive information to unauthorized parties. The blockchain’s decentralized nature makes it virtually impossible to manipulate stored data without detection, adding an additional layer of protection. The use of blockchain for address storage ensures that the integrity of the communication channel is maintained at all times, reinforcing trust and security in a domain where patient confidentiality and data protection are absolutely vital. [0096] The servers 105 include or are coupled to a data store 105a, which stores secure communications in escrow, which is particularly useful when a recipient does not have a secure communications account.

[0097] The data store 105a may be implemented using a secure database, for example an event- sourcing database. Implementing an event- sourcing database requires specific technologies and architectural components that capture and store changes to data as discrete events, rather than simply updating records in place. Event-sourcing ensures that every state change is recorded as a series of immutable events, allowing a complete history of operations to be reconstructed. This fits perfectly into a blockchain-based messaging system by offering traceability, consistency, and secure auditing, which are critical for secure communications, especially in sectors like healthcare.

[0098] To implement an event- sourcing database, several core technologies are typically needed:

[0099] 1. Event Store: This is the core component where events are logged and stored. Specialized databases like EventStoreDB or Apache Kafka are often used to handle high volumes of event data. These technologies are designed to capture, store, and replay events efficiently, ensuring that each action in the system is represented as an immutable event. In a messaging system, every action — whether it's sending, receiving, or accessing a message — would be stored as an event in the event store. This allows the system to keep an accurate historical record.

[0100] 2. Command and Query Responsibility Segregation (CQRS): To fully leverage the benefits of event sourcing, CQRS is often used. This architectural pattern separates the operations that modify data (commands) from those that read data (queries). For example, in a messaging system, sending a message would be a command that generates an event, while retrieving the message history would involve querying the event store to reconstruct the state. This allows for more efficient performance and scalability, as the system can optimize how it handles read and write operations. [0101] 3. Event Handlers: Event handlers are responsible for reacting to the events captured by the event store. In a messaging system, event handlers would trigger actions such as sending notifications to recipients or updating the status of a message. Event handlers also enable the system to respond in real time to new events, making it possible to track and act upon changes as they occur.

[0102] 4. Projections: Since event-sourcing databases store each event separately, they rely on projections to create views of the current state of the system. A projection aggregates events to present the user with a summary or snapshot of the current data, such as a complete conversation history in a messaging system. Projections are important because they allow for efficient querying of data without having to replay the entire event log for every request.

[0103] In the context of a blockchain-based messaging system, the event- sourcing database fits in as the core storage mechanism for all state changes. Every interaction with a message — whether it's created, sent, received, or read — generates an event that is stored in the event- sourcing database. Each of these events can be hashed and recorded on the blockchain to create a tamper-proof audit trail. Blockchain complements event sourcing by ensuring that even though the event data is stored centrally (in the event store), the integrity and history of those events are verifiable through the blockchain.

[0104] For example, when a message is sent in the system, the sending action is logged as an event in the event-sourcing database. The system then generates a hash of this event, which is recorded on the blockchain. This ensures that the event cannot be tampered with without detection, as any mismatch between the stored event and the hash on the blockchain would indicate tampering.

[0105] Blockchain -based identity and address storage can also be integrated into the event-sourcing architecture. When users interact with the system — such as when they authenticate to access a message — their identity and actions are recorded as events. By storing these interactions as immutable events and verifying them against the blockchain, the system ensures that all user actions are secure and can be audited. Blockchain enhances the security of the communication system by providing a decentralized layer of trust and verification, ensuring that no events, such as message alterations or access logs, can be manipulated without being detected.

[0106] In summary, an event- sourcing database is implemented using technologies like event stores (e.g., EventStoreDB, Apache Kafka), CQRS for efficient data management, event handlers to trigger actions, and projections to query current data states. In a blockchain-based messaging system, event sourcing works in tandem with blockchain to ensure secure, immutable communication records and user interactions, offering high transparency, security, and auditability.

[0107] In particular, a sender 110a interacts with the server 105 using a computing device 115, such as a personal computer. The one or more servers 105 function in part as a web server, and provide user interfaces with which the sender 110a interacts.

[0108] Initially, the sender 110a creates a user ID 130, which is used with interactions with the communications system 100. The user IDs 130 are verified by the system 100, providing a verifiable trust mechanism when sending or receiving data through the system 100.

[0109] In particular, the sender 110a interacts with the one or more servers 105, to generate the ID 130. This process may include uploading identity documents, such as a driver’s license, performing an identity check, and/or performing third-party verification. The sender 110a also enters communications details, such as a phone number, fax number, email address, or similar, which are also used for verification.

The server 105 verifies access to these communications, e.g. by sending codes or other messages to the phone number, fax number or email address, such codes later being entered into the user interface to verify access to the communications.

[0110] Different levels of verification may be used based upon a role of the sender 110a. As an illustrative example, basic user access may be provided upon verification of a mobile phone number. Advanced verification may, on the other hand, be required when sensitive information is being dealt with.

[0111] Other users, being recipients 110b, may similarly create user IDs 130. As such, recipients 110b may function as senders 110a, and when both a sender 110a and recipient 110b have IDs 130, secure communication between a sender 110a and recipient 110b may be utilised.

[0112] The user IDs 130 are associated with public and private encryption keys, to enable encryption and authentication of messages with the system 100 and between users (i.e. between senders 110a and recipients 110b). The public key is published in association with the user ID 130, and the private key is kept private by the recipient 110b, as is well known in the art of asymmetric encryption.

[0113] The user IDs 130 may be linked to one or more legacy addresses, such as a phone number, fax number, email address or the like. When legacy addresses are linked to a user ID 130, access to or ownership of the legacy address may be verified. For example, in the case of a mobile phone number, a code may be sent to that number (e.g. by SMS), wherein the user is required to provide that code for verification.

[0114] The linking of legacy addresses to user IDs 130 enables notifications regarding secure communications to be sent using legacy systems, such as SMS or fax. In particular, when communications associated with a legacy address are received at the server 105, the server 105 may determine whether the legacy address is associated with a user ID 130. If it is, a notification may be sent to the legacy address informing the recipient 110b of the secure communication, upon which the recipient 110b may log into the system to view the communication. Otherwise, a notification is sent to the legacy address, informing the user to create a user ID 130 to access the communication. The communication will generally include a link or instructions regarding how to create the account (and thus user ID 130). [0115] In some embodiments, the notification is sent to the recipient via a legacy communications system using a standard email or SMS message. The notification does not contain any sensitive information but simply informs the recipient that a message has been received and provides instructions on how to access it securely. For example, the notification might state: "You have received a secure message. Please click the following link to log in and view the message securely," along with a link to a secure portal.

[0116] Once the notification is sent, the system provides several ways for enabling the recipient to access the stored communication securely. Some example embodiments include: a. Secure Web Portal: The recipient is directed to a secure website where they can log in using their credentials (username/password). If the recipient does not yet have an account, the system may prompt them to create one, after which they can authenticate and view the communication. b. One-Time Password (OTP): The system sends the recipient a one-time password via a separate channel (e.g., SMS or email), which they must enter on the secure portal to verify their identity before accessing the message. This adds an additional layer of security. c. Multi-Factor Authentication (MFA): The system could require the recipient to authenticate using multi-factor authentication. This might involve entering their credentials along with a second form of verification, such as a code sent to their mobile device, or biometric verification. d. Download via Encrypted Link: In some cases, the recipient might receive a secure, time-limited, encrypted link in the notification. This link would redirect them to the stored communication, and they could access it directly after authentication. e. Secure Mobile App: If the secure communications system includes a mobile app, the recipient may access the message through the app, which uses built-in encryption and requires authentication before displaying the message. The app may use biometric features like fingerprint or facial recognition for added security.

[0117] These methods ensure that the recipient can access the sensitive communication securely, while the notification remains simple and non-sensitive, routed through legacy systems.

[0118] In some embodiments, the use of blockchain enhances one or more steps of the communications method, offering increased security, transparency, and trust: a. Storing the Communication on a Blockchain or Storing Proof of the Communication:

Rather than storing the actual communication on a traditional server, the system could store a hash or proof of the communication on a blockchain. This creates a tamper-proof, verifiable record that the communication exists and has not been altered. The actual message could still be stored off-chain, but the blockchain would provide an immutable record of the communication, ensuring data integrity. When the recipient accesses the communication, the system can verify that it hasn’t been modified since it was originally sent. b. Sending the Notification with Blockchain Verification:

The system could use blockchain technology to create a verifiable audit trail of notifications. For instance, each time a notification is sent to a recipient, the system could log the event on the blockchain. This log would be transparent, allowing both parties (the sender and recipient) to see a timestamped record of when the notification was generated and sent, which can help resolve disputes if a recipient claims not to have received the notification. This would ensure accountability and trust, particularly in sensitive or high-stakes communications. c. Blockchain for Authentication and Access Control:

Blockchain can be used to manage the authentication and access control when the recipient attempts to access the stored communication. Instead of relying on centralized authentication systems, blockchain-based decentralized identity verification could be implemented. This could involve the recipient using a digital identity stored on the blockchain, which would allow them to securely authenticate without needing to rely on traditional usernames or passwords. For example, the recipient could use a self- sovereign identity (SSI) model, where their identity is cryptographically verified via the blockchain, giving them control over their credentials and ensuring privacy. d. Secure Access Through Smart Contracts:

The access to the stored communication can be controlled by smart contracts on the blockchain. A smart contract could automatically determine whether the recipient is authorized to view the communication, based on predefined rules or permissions. Once the recipient meets the authentication criteria (e.g., logging in via blockchain-based identity), the smart contract would grant access to the communication, triggering the secure transfer of the message. e. Blockchain-Based Notification System with Tokenization: Blockchain can also facilitate a more secure notification process through tokenization. The system could issue a token that represents the notification, and this token would be sent to the recipient's blockchain address. The recipient can then use this token to retrieve the stored communication, ensuring that the message is accessed securely and by the correct party. This method can help ensure that only the intended recipient, who controls the private key for the token, can access the communication. f. Audit Trail and Transparency:

Each interaction with the communication (e.g., the storing, notification, and access steps) could be logged on the blockchain to provide a transparent and immutable audit trail. This would ensure that every action in the communication process is verifiable, including the time the communication was sent, when the notification was issued, and when the recipient accessed the communication. This audit trail can be useful in industries like healthcare, finance, or legal sectors, where proving compliance and maintaining security are crucial.

[0119] In these embodiments, benefits of using blockchain include that blockchain’s cryptographic features ensure that the communication and its handling are secure and tamper-resistant. Furthermore an immutable, time-stamped audit trail for all steps in the communication process is provided, and authentication via blockchain eliminates reliance on centralized systems, improving security and reducing the risk of breaches. Another benefit is that logging notifications and access events on the blockchain ensures that both the sender and recipient are accountable, as all actions are recorded transparently.

[0120] By integrating blockchain into the communication process, the system gains additional layers of security, privacy, and trustworthiness, which are especially beneficial when handling sensitive information.

[0121] When the sender 110a wishes to send a communication to a recipient 110b, the sender 110a initially checks to see whether the recipient 110b is associated with a user ID 130. If the recipient 110b is associated with a user ID 130, the sender 110a may send encrypted communication directly between the sender 110a and recipient 110b, and without using the server 105. In such case, the message is encrypted using a public key of the recipient 110b, or a key (shared secret) shared between the sender 110a and the recipient 110b. The message may comprise data in the form of documents, images, audio, text, files, or any suitable data.

[0122] If the recipient 110b is not associated with a user ID 130 (or is not associated with a user ID 130 with a sufficient level of security), the sender 110a sends the message to the server 105 together with a legacy address (e.g. phone number, fax number, etc) of the desired recipient. In such case, the message is encrypted using either a public key of the server 105 or a key (shared secret) shared between the sender 110a and the server 105, to ensure that the initial communication is secure.

[0123] The private key of the sender 110a may further be used to sign the message, enabling the server 105 to authenticate the origin of the message, and that it hasn’t been tampered with. Alternatively, an encrypted communications channel between the sender 110a and the server 105, e.g. comprising transport layer security or the like, may be used to authenticate the sender 110a.

[0124] Upon receipt of the message, the server 105 stores the message on the data store 105a. In case the legacy address is associated with a user ID 130 (i.e. a secure communications account), the server associates the message with that user ID 130. This may be using a secure inbox associated with the server 105, wherein the recipient 110b logs onto the server 105 to view their secure inbox.

[0125] The legacy address and the secure communications account are immutably associated with one another on the secure database of the secure digital-ledger technology based communication system.

[0126] A blockchain system guarantees the immutability and security of the association between a legacy communication address (such as a phone number) and a secure communications account by leveraging several key features of both blockchain and event- sourcing databases. Here’s how the process ensures the database of addresses is secure and the associations are immutable: [0127] When a legacy communication address, such as a phone number, is linked to a secure communications account, this association is treated as an event in the eventsourcing database. The database captures the event (e.g., the act of linking a phone number to a secure account), stores it as a distinct, immutable record, and generates a cryptographic hash of the event data. This hash is then recorded on the blockchain.

[0128] Key factors contributing to the security and immutability of the address database include the following:

[0129] 1. Immutability via Event- Sourcing: Event- sourcing databases are designed to be append-only, meaning that once an event is stored (such as the association of a legacy address with a secure account), it cannot be altered or deleted. If changes or updates are required, they are stored as new events rather than modifying existing records. This ensures a complete and transparent historical record of all changes to the address associations. Because each event is stored separately, the system can always reconstruct the full history of associations, making it impossible to retroactively change an event without leaving a trace.

[0130] 2. Blockchain’s Tamper-Proof Nature: The blockchain adds an additional layer of security by storing the cryptographic hash of each event. This hash represents a unique, fixed-length identifier generated from the data contained in the event (in this case, the legacy address and its association with the secure communications account). Once the hash is stored on the blockchain, it becomes part of a decentralized and distributed ledger. The blockchain is designed to be tamper-proof, meaning that once data is written to the blockchain, it cannot be changed without the consensus of the entire network, which is practically impossible. This ensures that any attempt to alter the event data in the event- sourcing database would immediately be detected because the altered data would not match the original hash stored on the blockchain.

[0131] 3. Decentralized Verification: Blockchain operates as a decentralized system, meaning that the stored event hashes are replicated across multiple nodes in the network. Any modification to the blockchain must be verified by a majority of these nodes, which makes it exceedingly difficult for a single actor or attacker to change or manipulate the data. This decentralized consensus mechanism ensures that the original association between the legacy address and the secure communications account remains secure and verifiable.

[0132] 4. Proof of Integrity with Hashes: The cryptographic hash of the event acts as a proof of integrity for the association between the legacy address and the secure communications account. If someone were to alter the event in the database (for instance, by trying to link the phone number to a different account), the new event data would generate a completely different hash. This discrepancy would be immediately visible, as the hash stored on the blockchain would no longer match the altered event. As a result, the blockchain guarantees that any changes or tampering are instantly detectable, further protecting the integrity of the data.

[0133] 5. Event Transparency and Auditability: By combining event-sourcing with blockchain, the system creates a fully transparent and auditable log of every action related to the legacy addresses and secure communications accounts. Every time a new address is linked or an association is changed, a new event is recorded and a corresponding hash is stored on the blockchain. This allows any party involved in the system to audit the history of events and verify that no tampering or unauthorized changes have occurred.

[0134] 6. Prevention of Unauthorized Access: In addition to the blockchain’s tamperproof nature, encryption and authentication mechanisms ensure that only authorized parties can modify or update the address associations. Blockchain-based identity management can also be employed to securely verify the identity of users before allowing them to make changes to their address associations, adding another layer of security to the system.

[0135] The database of addresses in a blockchain-based messaging system is highly secure because the event- sourcing database records every change as an immutable event, and the blockchain ensures that these events are tamper-proof through its decentralized, cryptographic hashing mechanism. The system creates an immutable and verifiable association between legacy communication addresses and secure communications accounts by combining these technologies. Any attempt to alter this data would be instantly detected, as the altered events would no longer match the original hashes stored on the blockchain. This guarantees that the address database remains secure, transparent, and reliable, making it particularly suitable for industries like healthcare where privacy and data integrity are critical.

[0136] If the legacy address is associated with a user ID 130, the communication is sent to the recipient using the user ID 130, i.e. in a secure manner electronically. This may be using a secure inbox associated with the server 105, wherein the recipient 110b logs onto the server 105 to view their secure inbox.

[0137] The method therefore supports the selection of a communication medium. For example, when a legacy address is used, the message can be sent to the recipient via a legacy communications system, or the message can be sent to the recipient via the secure communications system utilising DLT.

[0138] Because the database is a secure database forming part of the DLT-based (e.g. blockchain-based) communication system, the contact information and digital messaging method are both handled securely using DLT. In this way, the system provides an alternative communication method that is very secure, and at the same time accommodates legacy addresses, providing secure support (within the secure DLT- based database) of the legacy addresses and contact information.

[0139] To determine whether a legacy address is associated with a secure communications account, in one embodiment the method uses a centralized or distributed directory that maps legacy addresses, such as email addresses or phone numbers, to corresponding secure communications accounts. When a communication is received, the system queries this directory to see if there is a match, and if a secure account is found, the communication can then be routed through the secure messaging platform. [0140] In a blockchain-enabled system, legacy addresses may be stored as hashed or encrypted entries within the blockchain itself, linking them to secure accounts. The system searches the blockchain by hashing the legacy address and checking for an associated secure account, leveraging the decentralized and tamper-resistant nature of blockchain technology.

[0141] In another embodiment, the method uses public/private key cryptography, where each legacy address is paired with a secure public/private key. When a communication is received, the system looks for a public key associated with the legacy address and encrypts the message with this key before sending it securely. The recipient, using the associated private key, can then decrypt the message. Additionally or alternatively, the system may use a real-time verification protocol, sending a verification request to the legacy communication channel (such as an email or SMS) to check if the user has a secure account. If the recipient responds or authenticates themselves by logging into the secure system, the legacy address is confirmed as associated with a secure account.

[0142] A secure communication platform according to embodiments described herein may offer API integrations that allow external systems to check whether a legacy address is tied to a secure account. In this case, the system queries the API, which confirms the association and enables secure messaging. In other scenarios, metadata from the communication itself can be compared with records in the secure system to identify a match. If the metadata matches, the system determines that the legacy address is associated with a secure account. These various methods enable a communication system to seamlessly transition legacy communications into secure environments, ensuring that sensitive information is protected.

[0143] In case the communication is encrypted using a key associated with the server 105, the server 105 may decrypt the communication and re-encrypt it using a key associated with the user ID 130 of the recipient. [0144] In case the communication is encrypted using a key of the recipient 110b, the server 105 is unable to decrypt the message, and the communication is saved at the data store 105a in its original encrypted form. This thus provides end to end encryption between the sender 110a and recipient 110b.

[0145] The server 105 then sends a notification to the recipient 110b using a legacy communications system (e.g. SMS or fax), informing the recipient 115b of the message, and in case a user ID is not present, providing details as to how to create a user ID 130 and retrieve the communication. Repeated notifications may be sent to the recipient 110b using the legacy communications system, in particular where the message stored on the data store 105a requires urgent attention. In this regard, the server 105 may receive notification that a message to an unspecified recipient 110b has not been accessed within an acceptable time which may prompt the server 105 to send further communications to the recipient 110b requesting the recipient 110b to create a user ID 130 such that they can retrieve the communication. Acceptable times may be defined by the sender 110a during generation of the communication.

[0146] In particular, the server 105 is coupled with legacy communications systems using respective communications gateways, including an SMS gateway 120a. The SMS gateway 120a is configured to generate SMS messages and send same to a cellular telephone 125a associated with the legacy address (i.e. a phone number).

[0147] The server 105 may determines the type of legacy communication, e.g. SMS or fax, and send the notification using the determined legacy communications system. This enables the system 100 to work with multiple communications systems, e.g. fax and SMS, in a similar manner.

[0148] The type of communication may be determined in any suitable way. As an illustrative example, the legacy address may identify the type of communication through a prefix. For example, SMS:<number> may be used to identify SMS (text) messages, and fax:<number> may identify fax communications. In other embodiments, however, such determination may be made according to one or more implicit rules. For example, plain text may be implicitly intended for SMS messages, and pdf documents may be implicitly intended for fax.

[0149] The server 105 may convert the notification from one format to another for communication on the legacy communications network. As an illustrative example, a document or message may be converted to an image format suitable for faxing prior to being forward to a fax gateway.

[0150] The notification may be automatically generated at the server 105, e.g. using a template. The notification may include a link, selectable by a user, for generating a user ID 130 and accessing the communication. The link may comprises a Uniform Resource Identifier (URI) or Uniform Resource Locator (URL).

[0151] The notification is then sent to the recipient 110b using the SMS gateway 120a.

[0152] To receive the communication, the recipient 110b follows a link in the notification (e.g. by clicking on it), which directs the recipient 110b to the server 105, and in particular a user interface / web page thereof. Here the recipient 110b may either create a user ID 130, or associate a user ID 130 with the legacy address. This process is similar to that described above, and includes verification and authentication of the recipient.

[0153] As will be readily understood from the above description, the server 105 functions to provide an escrow for messages until the recipient 130 creates an appropriate account. This is achieved without requiring the sender 110a to know whether the recipient 110b has a user ID 130 or not, or when the recipient 110b creates a user ID 130.

[0154] As the server 105 decrypts and re-encrypts the communication, the sender 110a has no way of verifying that the recipient 110b has actually received the message as originally sent. [0155] As such, once user IDs 130 and public keys are shared between the sender 110a and recipient 110b, the recipient 110b may re-encrypt the communication and send it back to the sender 110a. This enables the sender 110a to confirm that the communication received by the recipient 110b is the same as what was sent, but also enables the communication to be stored in a shared inbox on the server 105 and/or data store 105 a.

[0156] Examples illustrating use of the system 100 are now provided.

[0157] When a communication is sent to one or more recipients 110b, a notification is sent to the one or more recipients 110b using a legacy communications system (e.g.

SMS). .

[0158] Figure 2 illustrates an embodiment of a screenshot 200 of a messaging application, including a notification 205. The messaging application may comprise a generic messaging application for receiving and displaying SMS messages, such as the messaging applications routinely provided on mobile devices.

[0159] The notification 205 includes descriptive text and instructions on how to access the message, including a hyperlink 210. The hyperlink 210 may link to an account generation screen of the system 100, and is selectable by the recipient 110b.

[0160] Once the recipient 110b creates an account, a secure inbox is generated and the communication is provided in the inbox. The secure inbox may be provided by the server 105 and/or a secure application on a user device (e.g. a secure app).

[0161] In case multiple communications are in escrow, each is moved to the secure inbox, and is selectable by the recipient for viewing once the recipient 110b logs in and is authenticated.

[0162] Figure 3 illustrates an embodiment of a screenshot 300 of a secure message screen. [0163] The secure message screen is for displaying the message (communication) from the sender 110a, and includes an image element 305, a button 310 linking to files of the communication, and text elements 315.

[0164] Figure 4 illustrates an embodiment of a communications method 400. The communications method 400 may be similar or identical to the method performed by the system 100.

[0165] At step 405, a communication associated with a recipient is received on a data interface. The message (and recipient) is associated with a legacy address, such as a phone or fax number of the recipient.

[0166] At step 410, the communication is stored on a data store. The data store may be accessible from the Internet.

[0167] At step 415, a notification is sent to the recipient indicating that communication has been received. The notification is sent to the recipient using a legacy communications system (e.g. SMS) and the legacy address.

[0168] In case the legacy address is associated with a secure communications account, the communication, or a derivative thereof, is sent to the recipient, on the data interface and using the secure communications account at step 415.

[0169] In case the legacy address is not associated with a secure communications account, a communication is sent to the recipient using the legacy address and a legacy communications system at step 420. The communication may comprise the communication received from the sender, or a derivative thereof. Alternatively, the communication may comprise a notification, requesting the recipient to create a secure communications account to access the message.

[0170] In some embodiments, when the system determines that a legacy address (associated with an intended recipient of a communication) is not associated with a secure communications account, the system generates and sends a notification communication to the recipient through the legacy communications system. The notification informs the recipient that a communication has been received but does not contain the sensitive content itself. Instead, it provides details and instructions for accessing the secure message.

[0171] In some embodiments, the system identifies that a recipient's legacy address, such as an email address or phone number, is not associated with a secure communications account. Upon this determination, the system generates a notification communication. This notification informs the recipient that a message has been received but does not contain any sensitive information. Instead, it provides details and instructions for accessing the secure message.

[0172] The system sends this notification via the legacy communications system, which might be an email or SMS. The notification includes general information, such as the identity of the sender and the fact that a secure message awaits. It also provides a link or instructions that guide the recipient to a secure portal or platform, where they can access the message. The system requires the recipient to authenticate themselves, either by logging in or by using a one-time password, ensuring that only the intended recipient can view the message.

[0173] In cases where higher security is necessary, the system adds extra layers of verification, such as sending a separate PIN or code to the recipient. This ensures that even if the notification message is intercepted, the sensitive content remains protected and inaccessible without proper authentication. By handling notifications this way, the system ensures that sensitive information is never transmitted over insecure channels, encouraging secure interaction even when the recipient initially lacks a secure communications account.

[0174] The secure communications system described herein employs Distributed Ledger Technology (DLT), such as blockchain, to develop messaging applications that provide enhanced privacy and security. Blockchain-based messaging systems improve security through several key features, including decentralization, encryption, immutability, and transparent identity verification. These systems enable users to communicate directly, eliminating the need for third-party intermediaries, thereby reducing the risk of data breaches and privacy violations.

[0175] Blockchain technology utilizes cryptographic techniques to safeguard data, rendering it difficult for unauthorized parties to access sensitive information. The immutable nature of blockchain ensures that once data is recorded, it cannot be altered. Users can securely create and manage their digital identities by associating them with a public key on the blockchain, ensuring that only verified parties can send and receive messages.

[0176] All participants in the blockchain network maintain a copy of the blockchain, which enhances the resilience of the system against attacks and data loss.

Consequently, the secure communication system described ensures robust recordkeeping, as all user activity is recorded on the blockchain and cannot be deleted.

[0177] The method 400 further comprises enabling the recipient to subsequently access communication that is stored on the data store using a secure communications account in step 420. In case the recipient already has an account, the recipient may simply log into their account to access their secure inbox and thereby the communication. Alternatively, the recipient may create an account and/or associate their account with the legacy address.

[0178] In one or all embodiments, and as outlined in further detail below, a hash of the communication may be made, and stored on a blockchain, for example. This may enable verification of the communication, by comparing a hash of the communication with the hash on the blockchain, without needing to put the communication itself on the blockchain.

[0179] In one or all embodiments, once the message has been created, it is hashed, at the computing device 115 of the sender, using a known hash algorithm that takes messages and converts them to a binary string of fixed size, such that the hash is representative of the message. As an illustrative example, Secure Hash Algorithm 3 (SHA-3) may be used to generate a binary string of 224, 256, 384, or 512 bits.

[0180] Hashes of communications are then stored on a blockchain, enabling anyone to subsequently take the communication, generate a hash using the same known hash algorithm, and compare the hash, to verify that the communication has not been altered or replaced.

[0181] Figure 5 illustrates part of an embodiment of a communications system 500. The communications system 500 includes a server 505, which may be similar or identical to the server 105, associated with a data store 510 and blockchain 515, including a plurality of event hashes 515a.

[0182] The data store 510 may be implemented using a secure database, for example an event- sourcing database as described elsewhere herein.

[0183] The system 500 includes an event system, to enable an audit trail of actions associated with communications to be maintained, such as the communication (e.g. message) being sent, delivered, and read.

[0184] When a communication, e.g. in the form of a message, is received at the server 505, the message is stored on the data store 510 and a payload of the communication is generated, for use by an event system, as outlined below.

[0185] Figure 6 illustrates an embodiment of a simplified schematic of a message payload 600. The message payload 600 may be similar or identical to the message payloads used by the systems 100, 500.

[0186] The message payload 600 includes a message location pointer 605, which comprises a pointer (e.g. a URL) to a location on the data store 510, together with a hash of the message, and a hash of the encrypted message. [0187] The pointer 605 points to the actual contents of the encrypted message, such as encrypted text, images, sound, files, etc.

[0188] The message payload 600 may further include a digital sender’s signature (not shown), to enable any entity to authenticate the message. In particular, the digital signature comprises a signature of the message using the sender’s private key, which can be verified using the sender’s public key, which is publicly available.

[0189] When a notification is sent to the recipient 110b, indicating that the message is able to be accessed, a ‘sent’ event is then generated corresponding to the ‘sending’ of the message to the recipient, including the pay load 600, which event item is hashed and stored on the blockchain 515 as an event hash 515a.

[0190] Figure 7 illustrates an embodiment of a simplified schematic of a sent event item 700. The sent event item 700 may be similar or identical to a ‘sent’ event used by the systems 100, 500.

[0191] The sent event item 700 comprises a unique event identifier 705, an event name 710, specifying the type of event (in this case a ‘sent’ event), and a timestamp 715 relating to when the message was sent. These parameters are common across all events, as illustrated in further detail below.

[0192] The sent event item 700 further includes a transaction ID 720, a from element 725, a to element 730, a payload element 735 and a payload type 740.

[0193] The transaction ID 720 is a unique identifier used to identify a particular message. The from and to elements 725, 730 are used to identify who the message is from and who the message is to (i.e. sender and recipient). These elements may include email addresses or similar identifiers associated with public and private keys (for encryption purposes), and may be similar or identical to the user ID 130 of Figure 1. The payload element 735 includes the message payload, which may be similar or identical to the message payload 600. Finally, the payload type 740 identifies how to interpret the payload, and may include version numbering, or any suitable indicator of how to interpret the payload.

[0194] Such configuration is particularly useful as it allows for easy expansion of event types (through different event names), but also expansion of pay load formats through the addition of new pay load types.

[0195] The sent event item 700 is then hashed, again using the known hash algorithm to generate an event hash 515a, which is stored on the blockchain 515.

[0196] The recipient 110b then accesses the server 505, and requests a copy of the message. The recipient is then provided the encrypted message, and can proceed to decrypt the message on their portable computing device 115 with their private key, and without needing to share their private key with the server 505.

[0197] The private key of the recipient may similarly be used for authentication with the server 505, enabling the server 505 to verify that the recipient (and not another user 110b) that has accessed the message. Alternatively, an encrypted communications channel between the sender and the server, e.g. comprising transport layer security or the like, may be used to authenticate the recipient.

[0198] The recipient’s interactions with the message, including receipt thereof, are also recorded on the blockchain 515 as events. In particular, a cryptographic hash of an event associated with each interaction is generated by the server, hashed and stored on the blockchain as an event hash 515a.

[0199] Figure 8 illustrates an embodiment of a delivered event item 800.

[0200] The delivered event item 800 includes an event identifier 705, an event name 710, specifying the type of event (in this case a ‘delivered’ event), and a timestamp 715 relating to when the message was delivered. [0201] The structure of the delivered event item 800 may be applied to a variety of other events, such as ‘read’ events, by simply changing the event name. Furthermore, extended structures may be provided where any suitable data is concatenated to the event, which can be recognised through the event name 710.

[0202] The blockchain 515 generally comprises a plurality of blocks, wherein event hashes 515a are stored as blocks on the blockchain 515. The blockchain 515 may, for example, comprise an Ethereum blockchain. Furthermore, while the term “blockchain” is used in singular, the skilled addressee will readily appreciate that any number of blockchains may be used together as a distributed ledger.

[0203] Figure 9 illustrates an embodiment of a simplified schematic of a portion of the blockchain 515.

[0204] The blockchain includes blocks 905, which are linked to each other in a chain using a blockchain hash 910, comprising a hash of the previous block 905. The use of a chain of hashes, comprising hashes of the previous blocks 905, prevents blocks 905 in the blockchain from being replaced, as this would break the chain of hashes.

[0205] The blocks 905 further include an event hash 915, comprising a hash of the message or transaction. The event hash 915 may be similar or identical to the event hash 515a of Figure 5.

[0206] When an event is initially created, the event hash 915 comprises a hash of the event, as outlined above. This enables any user to determine that the event has not been modified or replaced. Furthermore, the event may include hashes of a message residing off the blockchain, thereby enabling a user to determine that the message has also not changed.

[0207] While not illustrated, the skilled addressee will readily appreciate that any suitable type of data may also be stored in the blocks 905, but is not shown in the simplified schematic for the sake of clarity. For example, timestamps, headers and the like may be stored in the block and outside of the event hash 915.

[0208] The communications system 500 enables senders and recipients 110a, 110b respectively, to communicate with each other in a secure manner, while maintaining an auditable record on a blockchain 515. By storing hashes of messages and all associated events that follow it, including those by the recipient, an audit of all transactions can be made, while maintaining confidentiality of the data.

[0209] This is achievable as the users 110a, 110b are able to identify themselves before both sending and receiving data, and that communications are encrypted end-to end, meaning that even if the server 505 is compromised, data is not leaked.

[0210] In some cases, however, messages may be sent without encryption. As an illustrative example, messages comprising non-sensitive data may be sent in unencrypted form. In such case, the use of the blockchain 515 is still beneficial as it provides transparency and enables verification that messages have not been tampered with.

[0211] Furthermore, in addition to providing the data store 510 for storing communications, the data store 510 may be used for secure file storage. In such case, end-to-end encryption need not be used between a sender and recipient, but instead encryption to and from the data store 510 may be used. For example, AES-256 encryption may be used when communicating directly with the data store to access a file.

[0212] While the above embodiments illustrate senders and recipients 110a, 110b connecting directly to the server 105, 505 and data store 510, in other embodiments, third party systems (not illustrated) provide access to the server 105, 505 and/or data store 510. [0213] In one or all embodiments, the third party systems comprise Secure Message Delivery (SMD) systems in the healthcare industry. In such case, the system 100, 500 may support messages according to the Clinical Document Architecture (CDA) standard, and be used for eReferrals, specialist letters, prescriptions, lab results, diagnoses outcomes, discharge summaries and similar. The skilled addressee will, however, readily appreciate that any suitable third-party systems may be used, and in any industry, including outside of the healthcare industry.

[0214] Furthermore, in such case third party systems are used, the various interactions described above as occurring on the computing devices 115, such as encryption, may be performed by the third-party system.

[0215] Figure 10 illustrates an embodiment of a communications method 1000. The communications method 1000 may be similar or identical to methods performed by the systems 100, 500.

[0216] At step 1005, a message is generated, the message associated with one or more recipients. The message may be associated with one or more recipients using user IDs of the recipients, or other identifiers or addresses of the recipients.

[0217] The message may include any type of data, such as text, images, audio, files, etc. In one or all embodiments, the message comprises an eReferral, a specialist letter, a prescription, lab results, a diagnosis outcome, or a discharge summary. In other embodiments, the message comprises an invoice, a quote, a letter, or any other suitable document or data.

[0218] The message may be encrypted. The message may be encrypted using end-to- end encryption.

[0219] A sender may be authenticated prior to or upon receipt of the message therefrom. This may be performed using a digital signature of the sender, or any suitable method. [0220] At step 1010, a cryptographic hash of the message is generated. In one or all embodiments, multiple cryptographic hashes of the message are generated, including a hash of the message prior to encryption, and a hash of the message once encrypted.

[0221] The hash is generated according to a known hash algorithm, such as the Secure Hash Algorithm 3 (SHA-3) to generate a binary string of 224, 256, 384, or 512 bits. By using a known (and pre-defined) algorithm, others are able to rehash the message, and compare the hash with that generated above.

[0222] At step 1015, a recipient of the one or more recipients is authenticated. This may, for example, be in response to a request from the recipient to access the message. In one or all embodiments, the recipient is notified of the presence of a message, enabling the recipient to request access to same.

[0223] The recipient may be authenticated using any suitable means, including using a digital signature.

[0224] Upon authentication of the recipient, the message is provided to the recipient in step 1020. The (encrypted) message may be stored on a data store, and a link to the message may be provided to the recipient.

[0225] At step 1025, an event associated with provision of the message is generated. The event includes a (or multiple) hashes of the message, an event identifier, a timestamp, and details of the sender and recipient(s).

[0226] At step 1030, a cryptographic hash of the event is generated, similarly using a known hash algorithm.

[0227] At step 1035, the hash is stored on the blockchain. This enables parties to independently verify that the message has been provided to the recipient. [0228] By storing the hash on the blockchain, information from the message, as well as the senders and recipients, may remain confidential, while providing the ability to audit already known information.

[0229] The method 1000 may include validating the message using the blockchain. The message may be validated by generating a hash of the message, generating the event including the hash of the message, hashing the event, and comparing the hash of the event with a hash recorded on the blockchain.

[0230] Similarly, the method 1000 may include generating further events relating to interactions with the message, and storing hashes of same on the blockchain. These further events may be validated by regenerating the hash and comparing the hash to the corresponding value found on the blockchain.

[0231] In one or all embodiments, some of the user IDs 130 may be published on an online directory of the system 100, 500 and publicly available to anyone. In such case, details of the recipient 110b, such as name and other details, may be published on the directory, to enable persons to easily search for user IDs 130. In such case, secure communication may be initiated directly using the user ID.

[0232] However, some or all of the user IDs 130 may be private, requiring the recipient 110b to provide their user ID 130 to other parties for communications. Such configuration is useful when recipients 110b wish to minimise or avoid cold contact.

[0233] Referring to Figure 11 of the drawings, a communications system 1100 includes one or more servers 1110 that provide a secure communication platform 1112, through which secure communications may be made by sending secure messages from a sender to a recipient. The servers 1110 include or are coupled to a data store 1114, which stores secure communications and/or related data.

[0234] A sender interacts with the secure communication platform 1112 on the server 1110 using a user computing device 1120, such as a personal computer. In one or all embodiments the one or more servers 1110 function in part as a web server, and the secure communication platform 1112 provides user interfaces with which the sender interacts. In one or all embodiments a user’s computing device 1120 may run an application program 1122 configured to connect the user’s computing device 1120 to the platform 1112 via a network 1150 (for example a large area network, LAN, the internet, or other digital communication network, or a combination of interconnected communication networks).

[0235] In other embodiments the communication system 1100 may be configured to operate in a different type of configuration, for example a client-server architecture where the server 1110 may be a server host, and the platform 1112 may comprise the server software that provides the functionality of the communication system 1100.

[0236] The computing devices 1120 are in communication with the server 1110 over the network 1150. In an exemplary embodiment, the application program 1122 is provided by the server 1110 and is accessed by the users of the system from a user computing device 1120 via an online web application, thereby accessing the services provided by the platform 1112.

[0237] Figure 12 is a block diagram of an example embodiment of a computing device 1200 that can be used in the system described herein, for example as a user computing device 1120 and/or as one or more of the servers 1110 illustrated in Figure 11 of the drawings. Each computing device 1200 includes a processor 1210, storage 1220, memory 1230, and a communication interface 1240 (also referred to as a “data interface” herein) for communicating with other computing devices. The various components of the computing device 1200 are interconnected via a bus 1250. This configuration may be implemented using a bespoke computing device, or in one or all embodiments standard devices such as a mobile phone, tablet, desktop computer or laptop may be used. [0238] While the terms “sender”, “recipient” and “user” are used here, the skilled addressee will readily appreciate that an organisation (with multiple associated individuals) may be associated with a user ID 130, rather than an individual. This is particularly relevant where hospitals, pathologists, medical centres, law firms, accountancy firms, or the like communicate, which have multiple individuals (e.g. doctors, lawyers or other staff), each having access to the system 100, 500.

[0239] While much of the above description describes a recipient either having an account or not, the skilled address will appreciate that there may be accounts with different levels of verification. As an illustrative example, a recipient may generate a basic account with only minimal verification, or a more secure account with further verification.

[0240] In such case, the sender may determine what level of account security is required to access the communication. For example, marketing may be received with a basic account, whereas sensitive health information may require a more secure account.

[0241] In such case, having an account that is not sufficiently secure may be treated much like a non-existent account (i.e. the message is held in escrow), the difference being that the more secure account need not be created from scratch.

[0242] Similarly, while the above description describes a single secure communication system, the system may integrate with a number of third-party secure communication systems. In such case, it may be determined if the legacy address is associated with a secure communications account of a secure communications system of a plurality of secure communications systems. The communications may then be sent using the secure communications system with which the legacy address is associated.

[0243] Such configuration enables the method to work with a variety of secure communications systems, and without requiring a sender to check each of a plurality of communications systems. [0244] Advantageously, the methods and systems described above enable communications to be held in escrow until the recipient creates a secure communications account, at which time they may access the communications in a secure manner. This further alleviates the need for a sender to keep track of whether a user has created a secure communications account or not.

[0245] This is particularly useful when a secure communications system is being deployed, as it alleviates the need to know account details for other users, and in particular users that have not yet created a secure communications account.

[0246] Furthermore, the methods and systems described above enable confidentiality, auditability and authentication to be provided when parties communicate data, such as documents or other communications, with each other remotely.

[0247] By storing the cryptographic hash of the message interactions on the blockchain, an immutable record of the message activity is able to be provided, without storing or disclosing the message on the blockchain. This may in turn enable auditing to be performed in a transparent manner, without compromising the data of the message.

[0248] By enabling every action to be validated on the blockchain through a peer-to- peer network, sensitive data may be sent and received without the risk of data tampering, which in turn breaks down the barriers of distrust.

[0249] Furthermore, the methods and systems may be used with end-to-end encryption, meaning that even if there is a leak and/or other compromise of a server of the system, sensitive data will not be leaked.

[0250] Reference throughout this specification to ‘one embodiment’ or ‘an embodiment’ means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. Thus, the appearance of the phrases ‘in one embodiment’ or ‘in an embodiment’ in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more combinations.

[0251] It will be understood to persons skilled in the art that many modifications may be made without departing from the spirit and scope of the disclosure.

Claims

CLAIMS:

1. A secure communications method for providing secure digital communications to users of a legacy communications system, the method comprising: in a secure digital-ledger technology based communication system: receiving, on a data interface of a server of the communication system, a communication associated with a recipient, the recipient associated with a legacy address; storing the communication on a secure immutable data store associated with the server; sending a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

2. The method of claim 1, comprising enabling the recipient to generate the secure communications account.

3. The method of claim 1 or claim 2, comprising: determining that the legacy address is not associated with a secure communications account, wherein the notification includes instructions regarding how to generate a secure communications account.

4. The method of any one of the preceding claims, wherein the communication comprises one or more of the following: a message, text, images, documents, audio, and electronic files.

5. The method of any one of the preceding claims, comprising generating the notification communication, wherein the notification communication comprises one or more of the following: a text message, a fax message, an email communication, and a physical communication.

6. The method of any one of the preceding claims, wherein the notification communication includes a link to a secure communications system, wherein one or more of the following conditions apply: the link is selectable by the user; the link comprises a Uniform Resource Identifier (URI); the link comprises a Uniform Resource Locator (URL); the notification communication is at least partly automatically generated.

7. The method of any one of the preceding claims, wherein the recipient is authenticated when requesting the communication, the recipient is authenticated using a key associated with the recipient, and wherein the key comprises a key of a public / private key pair.

8. The method of any one of the preceding claims, wherein the legacy address comprises one or more of: a telephone number, a fax number, an email address, and a street address.

9. The method of any one of the preceding claims, comprising determining a type of legacy communication, wherein communications are sent using a selected legacy communications system of a plurality of legacy communications systems according to the determined type of communication, thereby supporting multiple communications system types.

10. The method of any one of the preceding claims, comprising generating the secure communications account for the recipient, said generating comprising: verifying an identity of the recipient, and generating the secure communications account upon verifying the identity of the recipient.

11. The method of any one of the preceding claims, wherein the communication is encrypted, and the method includes decrypting the received communication, and subsequently encrypting the communication using a key associated with the secure communications account.

12. The method of claim 11, wherein decryption of the communication at the server is performed on initial communication, and subsequent communication is encrypted end-to-end.

13. The method of any one of the preceding claims, wherein communications are encrypted using a key of the recipient, a key of a sender, or a shared secret, wherein the shared secret is generated using keys of the sender and recipient.

14. The method of any one of the preceding claims, wherein the communication is encrypted prior to being received by a server.

15. The method of any one of the preceding claims, wherein the communication is encrypted at a computing device of the sender.

16. The method of any one of the preceding claims, wherein the communication is received from a sender, and wherein one or more of the following conditions apply: the sender is associated with a secure communications account; an identity of the sender is verified by the system; the identity of the sender is authenticated using a key associated with the sender.

17. The method of any one of the preceding claims, comprising determining that the legacy address is associated with a secure communications account of a secure communications system of a plurality of secure communications systems, wherein the communication on the data store is associated with the secure communications system.

18. The method of any one of the preceding claims, comprising authenticating the recipient, wherein the communication is provided to the recipient upon authenticating the recipient.

19. The method of claim 18, wherein the recipient is authenticated using a digital signature, wherein the digital signature is generated using public key private key cryptography, and wherein the digital signature comprises an electronic, encrypted stamp of authentication.

20. The method of any one of the preceding claims, comprising authenticating the sender using a digital signature generated using public key private key cryptography, wherein the digital signature comprises an electronic, encrypted stamp of authentication.

21. The method of any one of the preceding claims, wherein the communication is stored on the data store in an encrypted manner.

22. The method of any one of the preceding claims, comprising generating, using the at least one processor, a cryptographic hash of at least part of the communication, and wherein the cryptographic hash, or a derivative thereof, is stored, on a blockchain.

23. The method of claim 22, comprising generating an event item relating to the communication, wherein a cryptographic hash of the event item is stored on the blockchain, and wherein the event item includes a cryptographic hash of the communication.

24. The method of any one of the preceding claims, wherein the communication is encrypted, and the event item includes a cryptographic hash of the encrypted communication.

25. A secure digital-ledger technology based communications system comprising: at least one computing device including: a data interface; a secure immutable data store a processor coupled to the data interface; and a memory, coupled to the processor, the memory including instruction code executable by the processor for: receiving, on the data interface, a communication associated with a recipient, the recipient associated with a legacy address; storing the communication on the secure immutable data store; sending a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enabling the recipient to subsequently access the communication that is stored on the data store using a secure communications account.

26. A non-transitory computer-readable medium including instruction code stored thereon, the instruction code when executed by one or more processors, cause the one or more processors to: receive, on a data interface, a communication associated with a recipient, the recipient associated with a legacy address; store the communication on a secure immutable data store of a secure digitalledger technology based communication system; send a notification to the recipient indicating that the communication has been received, using a legacy communications system and the legacy address; and enable the recipient to subsequently access the communication that is stored on the data store using a secure communications account.