WO2025085970A1

WO2025085970A1 - Communications systems and methods

Info

Publication number: WO2025085970A1
Application number: PCT/AU2024/051129
Authority: WO
Inventors: Clint BETTS; M Bradley DAVIS; Rodan D'ROZARIO; Nathaniel JACOBS; Andrew NAPIER
Original assignee: Gologic Group Pty Ltd
Current assignee: Gologic Group Pty Ltd
Priority date: 2023-10-27
Filing date: 2024-10-25
Publication date: 2025-05-01
Anticipated expiration: 2026-04-27

Abstract

A secure communications method for selecting a secure communication medium is implemented in a secure digital-ledger technology based communication system. The method comprises 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 determines, using a processor of the server and accessing a secure database, whether the legacy address is associated with a secure communications account. 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. The method comprises, upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

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. This often results in various systems operating in parallel, including new and old. Furthermore, in many cases, it is not fast or easy to identify which other users use a secure messaging system, resulting in communications being sent unsecured by default.

[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 selecting a secure communication medium, 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; determining, using a processor of the server and accessing a secure database, whether the legacy address is associated with a secure communications account, wherein 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; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

[0011] Advantageously, the server is able to function as an automatic router, that routes communications associated with a legacy address to a secure communications account, without requiring a sender to know whether the recipient has a secure communications account.

[0012] The method may comprise: upon determining that a further legacy address is not associated with a secure communications account, sending the communication, or a derivative thereof, to a further recipient using a legacy communications system and the further legacy address.

[0013] Such configuration may enable the method to automatically fall back to legacy communications when recipients do not have a secure communications account.

[0014] The method may comprise: upon determining that a further legacy address is not associated with a secure communications account, sending a notification communication to a further recipient indicating that the communication has been received, using the legacy communications system and the further legacy address. [0015] Such configuration may enable the method to notify the recipient of the communication using legacy communications. The recipient may then 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 converting the communication from one format to another. As an illustrative example, a scan or image may be converted from an image format suitable for faxing, to a document format (e.g. PDF) suitable for display on a computing device, or vice versa.

[0021] 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.

[0022] 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).

[0023] The notification communication may be, at least partly, automatically generated. [0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] The communication may be encrypted.

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

[0030] 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.

[0031] 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. [0032] The communication may be encrypted prior to being received by a server.

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

[0034] As such, end-to-end encryption may be provided between the sender and recipient.

[0035] According to an example, the communication is received from a sender.

[0036] 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.

[0037] 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 communications is sent using the secure communications system.

[0038] 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.

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

[0040] 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.

[0041] According to one or all embodiments, the sender is authenticated. [0042] 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.

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

[0044] The sender and recipient may be verified prior to allocation of a user ID.

[0045] The method may include verifying the sender and/or recipient using a phone number, fax number, and/or email address.

[0046] 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.

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

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

[0049] 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.

[0050] 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.

[0051] The method may include storing at least part of the communication on a data store. The communication may be stored on the data store in an encrypted manner. [0052] The data store may encrypt data using AES-256 encryption.

[0053] 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.

[0054] The method may include generating, using the at least one processor, a cryptographic hash of at least part of the communication.

[0055] The cryptographic hash, or a derivative thereof, may be stored, on a distributed ledger, for example on a blockchain.

[0056] 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.

[0057] 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.

[0058] The event item may include a timestamp.

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

[0060] 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.

[0061] 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. [0062] 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.

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

[0064] The method may include validating one or more interactions with the message using the blockchain.

[0065] 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 and immutable database; 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; determining, using the processor and the secure database, whether the legacy address is associated with a secure communications account, wherein 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; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

[0066] 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 of a secure digital-ledger technology based communication system, a communication associated with a recipient, the recipient associated with a legacy address; determine, using a processor of the communication system and the secure database, whether the legacy address is associated with a secure communications account, wherein the legacy address and the secure communications account are immutably associated with one another on the secure database of the secure digitalledger technology based communication system; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

[0067] 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.

[0068] 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

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

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

[0071] Figure 2 illustrates an embodiment of a screenshot of a message creation interface of the system of Figure 1.

[0072] Figure 3 illustrates an embodiment of a screenshot of a secure inbox screen of the system of Figure 1.

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

[0074] Figure 5 illustrates an embodiment of part of a communications systema.

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

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

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

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

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

[0080] Figure 11 shows an embodiment of a communications system. [0081] Figure 12 is a block diagram of an example embodiment of a computing device.

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

Detailed Description

[0083] 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.

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

[0085] The communications system 100 includes one or more servers 105 (with associated databases, not shown), through which communications may be routed to both legacy communications systems, when needed, and to secure communications systems when available.

[0086] The secure communications system of the present disclosure uses distributed ledger technology (DLT).

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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. [0092] 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.

[0093] 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.

[0094] 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.

[0095] 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.

[0096] 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.

[0097] As illustrated in Figure 1 of the drawings, 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] The user IDs 130 are associated with public and private encryption keys, to enable encryption and authentication of messages transmitted within 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 known in the art of asymmetric encryption.

[0103] The user IDs 130 are 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.

[0104] The linking of legacy addresses to user IDs 130 enables communication directed to a legacy address to be redirected to secure communications. 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, further communication may be secure using the user ID 130. Otherwise, the communication is either provided to the legacy address, or stored on the server 105, until the recipient either creates a user ID 130 or associates a user ID 130 with the legacy address.

[0105] When the sender 110a wishes to send a communication to a recipient 110b, the sender 110a initially creates a message comprising data to be sent at their computing device 115. The data may include documents, images, audio, text, files, or any suitable data.

[0106] The message is then encrypted using either a public key of the server 105 or recipient 110b, or a key (shared secret) shared between the sender 110a and the server 105 or recipient 110b, to ensure that the initial communication is secure. Encrypting the message using the key of the server may, however, not be suitable for sensitive communications, as a breach of the server 105 may expose the sensitive communication.

[0107] 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.

[0108] The message is then uploaded to the server 105, together with a legacy address (e.g. phone number, fax number, etc) of the desired recipient.

[0109] Upon receipt of the message, the server 105 determines whether the legacy address is associated with a user ID 130 (i.e. a secure communications account).

[0110] 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. [0111] 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:

[0112] 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.

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

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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.

[0123] 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. [0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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 may be forwarded to the recipient 110b using communication associated with the user ID 130. This thus provides end to end encryption between the sender 110a and recipient 110b.

[0130] If the legacy address is not associated with any user ID 130, the server 105 may send the communication to the recipient 110b using a legacy communications system (e.g. SMS or fax), or send a notification of receipt of the communication using the legacy communications system, and provide details as to how to create a user ID 130 and retrieve the communication.

[0131] In particular, the server 105 is coupled with a plurality of legacy communications systems using respective communications gateways, including an SMS gateway 120a, and a fax gateway 120b. 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), and the fax gateway 120b is configured to generate faxes and send same to a fax machine 125b associated with the legacy address (i.e. a fax number).

[0132] The server 105 determines the type of legacy communication, e.g. SMS or fax, and sends the communication or 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. [0133] 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.

[0134] In case the communication is sent using the legacy communication system, the server 105 may convert the communication from one format to another. As an illustrative example, a document or message may be converted to an image format suitable for faxing prior to being forward to the fax gateway 120b.

[0135] In case a notification is sent, rather than the communication itself, the communication is stored on server 105, and the notification is 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).

[0136] The notification is then sent to the recipient 110b using one of the legacy communications systems, e.g. SMS using the SMS gateway 120a.

[0137] 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.

[0138] As will be readily understood from the above description, the server 105 functions as an automatic router, that routes communications associated with a legacy address to secure communications using a user ID 130, when available, while automatically falling back to legacy communications when recipients 110b do not have user ID 130. This is achieved without requiring the sender 110a to know whether the recipient 110b has a user ID 130 or not.

[0139] As outlined above, in case of sensitive information, it may be undesirable for the server 105 to be able to decrypt the communication, as a breach of the server 105 may expose the sensitive information.

[0140] In such case, initial communication with the server 105 may comprise partial or less sensitive information. Once the recipient 110b generates the user ID 130, details of the recipient’s and sender’s user IDs 130 and public keys may be made available to each other, enabling end-to-end communication for all future communications. In other words, to avoid potential exposure of sensitive information, initial communication may avoid sensitive information, and instead function solely as a notification and/or end-to-end encryption initiation procedure.

[0141] Furthermore, if the server 105 decrypts and re-encrypts important communication, the sender 110a has no way of verifying that the recipient 110b has actually received the message as originally sent.

[0142] As such, and once the user IDs 130 and public keys are shared between the sender 110a and recipient 110b, the recipient 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.

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

[0144] When wishing to send a communication to one or more recipients 110b, the sender 110a may create a message using a message creation interface. [0145] Figure 2 illustrates an embodiment of a screenshot 200 of a message creation interface. The message creation interface in Figure 2 is for creating SMS messages, but the skilled addressee will readily appreciate that similar interfaces may be used for creating fax messages.

[0146] The message creation interface including a from address field 205, to enable the sender 110a to determine what number a message is sent from. This may be relevant where an organisation is able to send messages from different numbers depending on purpose. The from address field 205 may comprise a free text field, a drop down menu, or the like.

[0147] The message creation interface further includes a to address field 210, to enable the sender 110a to enter a phone number (i.e. a legacy address) of a recipient 110b. The from address field 205 may similarly comprise a free text field, a drop down menu, or the like.

[0148] An add recipient button 210a is associated with the to address field 210, to enable the sender 110a to send the message to multiple recipients. Each time the add recipient button 210a is selected, a further to address field 210 may be provided.

[0149] An enable smart routing radio button 215 is provided, to enable the sender 110a to choose whether routing to secure communications is to be used where available or not. This may be beneficial where both sensitive communications (e.g. medical data) and non-sensitive data (e.g. appointment reminders) are sent.

[0150] A message text filed 220 is provided, to enable the sender 110a to enter details of the message. This may be typed manually. In other embodiments, one or more template messages may be used.

[0151] Finally, a schedule message radio button 225 is provided, to enable the sender to schedule sending of the message. In case the radio button 225 is selected, one or more options regarding the scheduling of the message may be provided. [0152] If the message is sent by legacy systems, i.e. SMS, the SMS gateway 120a generates and sends a text message to the phone 125a. In case secure communications are used, the recipient 110b may log into a secure inbox. The secure inbox may be provided by the server 105 and/or a secure application on a user device 125a (e.g. a secure app).

[0153] Figure 3 illustrates an embodiment of a screenshot 300 of a secure inbox screen.

[0154] The secure inbox screen includes a plurality of messages elements 305, representing messages between the sender 110a and recipient 110b, arranged in chronological order.

[0155] The secure inbox screen may be similar for the sender 110a and recipient 110b. Furthermore, the secure inbox screen may enable the sender 110a and/or recipient 110b to move between communications with different other users. This way the sender 110a and recipient 110b are able to view conversations independently.

[0156] 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.

[0157] 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.

[0158] At step 410, it is determined whether the legacy address is associated with a secure communications account. This may be performed using a look-up table, or any other suitable means. [0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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.

[0165] 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.

[0166] 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.

[0167] 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. [0168] 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.

[0169] 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.

[0170] 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.

[0171] 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.

[0172] The data store 510 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. [0173] To implement an event- sourcing database, several core technologies are typically needed:

[0174] 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.

[0175] 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.

[0176] 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.

[0177] 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. [0178] 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.

[0179] 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.

[0180] 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.

[0181] 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. [0182] 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.

[0183] 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.

[0184] 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.

[0185] 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.

[0186] The pointer 605 points to the actual contents of the encrypted message, such as encrypted text, images, sound, files, etc.

[0187] 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.

[0188] 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.

[0189] 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. [0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] The recipient 110b then accesses the server 505, and requests a copy of the message. The recipient 110b 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.

[0196] 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 110b (and not another recipient 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.

[0197] 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.

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

[0199] 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.

[0200] 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.

[0201] 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.

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

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] The communications system 500 enables both 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.

[0208] This is achievable as the senders and recipients 110a, 110b respectively, 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.

[0209] 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.

[0210] 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.

[0211] 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.

[0212] 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.

[0213] 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.

[0214] 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. [0215] 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.

[0216] 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.

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

[0218] 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.

[0219] 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.

[0220] 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.

[0221] 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. [0222] The recipient may be authenticated using any suitable means, including using a digital signature.

[0223] 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.

[0224] 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).

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

[0226] 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.

[0227] 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.

[0228] The communications 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.

[0229] Similarly, the communications 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.

[0230] 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.

[0231] 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.

[0232] 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.

[0233] 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).

[0234] 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.

[0235] 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.

[0236] 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.

[0237] 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.

[0238] 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. [0239] 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.

[0240] Advantageously, the methods and systems described above enable automatic (smart) routing of communications associated with legacy address (e.g. SMS or fax) to secure communications systems, where available, while communications may be sent using legacy communications systems otherwise.

[0241] This may in turn simplify the process for transitioning from legacy communications systems in a seamless manner, communications may be generated in the same manner regardless of how they are ultimately received.

[0242] Furthermore, the methods and systems enable users to select what sort of communications they send on legacy (insecure) systems. For example, in case of sensitive communications, the user may require that secure communications are used to retrieve the message, and in such case a notification is provided on the legacy system (the notification not including the sensitive information).

[0243] 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.

[0244] 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.

[0245] 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. [0246] 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.

[0247] 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.

[0248] 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 selecting a secure communication medium, 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; determining, using a processor of the server and accessing a secure database, whether the legacy address is associated with a secure communications account, wherein 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; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

2. The method of claim 1, comprising: upon determining that a further legacy address is not associated with a secure communications account, sending the communication, or a derivative thereof, to a further recipient using a legacy communications system and the further legacy address.

3. The method of claim 1 or claim 2, comprising: upon determining that a further legacy address is not associated with a secure communications account, generating and sending a notification communication to a further recipient indicating that the communication has been received, using the legacy communications system and the further legacy address.

4. The method of claim 3, wherein the notification comprises one or more of: a text message, a fax message, an email communication, and physical communication.

5. The method of claim 3 or claim 4, wherein the notification communication is automatically generated, and includes a link to a secure communications system, wherein the link comprises a Uniform Resource Identifier (URI) and/or a Uniform Resource Locator (URL).

6. The method of any one of the preceding claims, wherein the communication comprises one or more of: a message, text, an image, a combination of text and image, documents, audio, and electronic files.

7. The method of any one of the preceding claims, comprising converting the communication from one format to another.

8. The method of claim 7, wherein the converting comprises converting the communication from an image format suitable for faxing, to an electronic document format suitable for display on a computing device.

9. The method of any one of the preceding claims, comprising: receiving, on the data interface of the server, a request to authenticate the recipient; and authenticating the recipient using a key associated with the recipient, wherein the communication is provided to the recipient upon authenticating the recipient.

10. The method of claim 10, wherein the key comprises a key of a public / private key pair.

11. 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.

12. The method of any one of the preceding claims, comprising: determining a type of legacy communication, and wherein sending the communication comprises using a selected legacy communications system of a plurality of legacy communications systems according to the determined type of communication.

13. The method of any one of the preceding claims, comprising: generating the secure communications account for the recipient.

14. The method of claim 13, wherein generating the secure communications account comprises verifying an identity of the recipient, the secure communications account is generated upon verifying the identity of the recipient.

15. The method of any one of the preceding claims, wherein the communication is encrypted.

16. The method of claim 15, comprising decrypting the received communication, and subsequently encrypting the communication using a key associated with the secure communications account.

17. The method of any one of the preceding claims, comprising providing end-to- end encryption between a sender sending the communication and the recipient of the communication.

18. The method of any one of the preceding claims, wherein a sender sending the communication is associated with a secure communications account, an identity of the sender is verified, and the identity of the sender is authenticated using a key associated with the sender.

19. 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 is sent using the secure communications system.

20. The method of any one of the preceding claims, wherein a sender and/or the recipient is authenticated 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, comprising storing at least part of the communication on a data store.

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

23. A secure digital-ledger technology based communications system comprising: at least one computing device including: a data interface; a secure and immutable database; 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; determining, using the processor and accessing the secure database, whether the legacy address is associated with a secure communications account, wherein the legacy address and the secure communications account are immutably associated with one another on the secure database of the secure digitalledger technology based communication system; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.

24. 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 of a secure digital-ledger technology based communication system, a communication associated with a recipient, the recipient associated with a legacy address; determine, using a processor and accessing a secure and immutable database, whether the legacy address is associated with a secure communications account, wherein 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; and upon determining that the legacy address is associated with a secure communications account, sending, on the data interface and using the secure communications account, the communication, or a derivative thereof, to the recipient.