WO2021146801A1

WO2021146801A1 - Secure data transfer system

Info

Publication number: WO2021146801A1
Application number: PCT/CA2021/050056
Authority: WO
Inventors: Kevin HERKENDAAL
Original assignee: Datacast360 Inc.
Priority date: 2020-01-21
Filing date: 2021-01-20
Publication date: 2021-07-29

Abstract

This disclosure describes a Data Transfer System (DTS) exemplary of an embodiment of the present invention, designed to deliver one or more packages of data such as documents and multimedia files to users securely and with assurances of arrival of the data at the correct destination. The exemplary system provides a method for a sending user or client to transmit a POD to a receiving user or client of the DTS, and of verifying locations of departure and arrival points of the POD. The documents are encrypted and cannot be decrypted by the server.

Description

Secure Data Transfer System

TECHNICAL FIELD

[0001] The present application relates generally to a data transfer system, and in particular, to a highly secure bidirectional data exchange system that utilizes encryption.

BACKGROUND ART

[0002] Prior to about 1986, businesses had limited means of reliably transferring or delivering documents to an intended recipient. The few available methods included postal services and other local and global courier services. Postal services were a trusted form of delivery although often quite slow compared to couriers. Couriers, on the other hand, were highly trusted due to waybill tracking, concentrated delivery, and relatively quick speed of delivery although couriers were often quite expensive in comparison to regular postal services.

[0003] The advent of digital technology, and ubiquitous and affordable data networks, allowed the transfer of information that would have previously required physical delivery using hardcopy documents. Initially facsimile or fax particularly in its digital form, allowed analog signal from a scanner to be digitized, compressed, and transmitted at relatively high data rates across standard phone lines. This provided a reliable, much faster and convenient alternative to mailing documents in physical form for businesses and individuals.

[0004] Further advances in digital technology, particularly email with its ability to attach documents, and other file transfer services have vastly improved the ease, speed and cost of sending information across vast physical distances.

[0005] Unfortunately, the ease provided by such advances in digital transmission of information is increasingly exploited for nefarious purposes such as spam, malware, email scams, email spoofing where the email message header is designed to make the message appear to come from a known or trusted source and email phishing that mislead the recipient about the true message origin.

[0006] Such undesirable activities have created significant concern associated with the effect of privacy breaches, identity theft and misappropriation of other private data, which may be potentially damaging to the true owner of the data.

[0007] Many conventional approaches exist that attempt to provide a secure mechanism for the use and exchange of data privately. Usernames and passwords are often used for authentication but these can be stolen and reused by unauthorized users. The unauthorized users may even be in a different country or continent. Data breaches that involve financial data such as credit card or bank details, personal health information, and even trade secrets have become increasingly more common.

[0008] Accordingly, common methods typically used to send and receive documents between businesses have become outdated, insecure, or highly labor intensive. The most common methods used today for most data transfers remain email, fax, courier and postal services.

[0009] With respect to email, it is well known that anyone with the username and password for an email account can intercept the contents of the email. Some of the major email service providers state clearly, in their terms of service, that every email sent or received from their email servers may be scanned. In addition, email content may be unwittingly stored outside of the borders of the sender by the actions of the email service provider.

[0010] A significant drawback of fax is related to quality, which can at worst, lead to faxed documents that are unreadable. Moreover, by just transposing a digit when dialing a recipient’s number, the sender can deliver protected or proprietary information to an unintended recipient. [0011] Postal and courier systems often allow tracking of items or documents in transit, door-to-door and vary delivery times based on price. However, the drawbacks to these systems include cost and environmental degradation resulting from the extensive use of cars, trucks, and fuel, packaging and labor costs.

[0012] All of the above methods are also typically vulnerable to interception and often do not conform to strict standards for security and privacy. The contents of the documents can easily be read by anyone who can intercepts the documents in transit.

[0013] Accordingly, there is a need for improved systems and methods that safely and securely exchange data between a sender and the intended recipient, and mitigate at least some of the problems noted above.

SUMMARY OF INVENTION

[0014] In accordance with one aspect of the present invention there is provided a server system for securely transmitting at least one piece of data such as a document or a multimedia file from a first device associated with a sender to a second device associated with a recipient. The server system includes a processor in communication with memory, a communication interface, and an input interface. The memory includes processor executable instructions that when executed cause the processor, to perform the steps of: authenticating the sender and the first device; receiving a package of data (POD) having an encrypted version of the at least piece of data from the first device; notifying the recipient that the POD is awaiting retrieval; authenticating the recipient and the second device; upon receipt of a request from the recipient using the second device to download the POD before a predetermined maximum time after the notifying, sending the POD to the second device; and deleting the POD from the server system; and otherwise deleting the POD from the server system upon expiry of the predetermined maximum time.

[0015] In accordance with another aspect of the present invention there is provided, a method for securely transmitting at least one piece of data from a first device associated with a sender to a second device associated with a recipient, using a server system. The method includes, at a server system, authenticating the sender and the first device; receiving a package of data (POD) comprising an encrypted version of the at least one piece of data from the first device; notifying the recipient that the POD is awaiting retrieval and authenticating the recipient and the second device. The method also includes, upon receipt of a request from the recipient using the second device to download the POD before a predetermined maximum time after the notifying, sending the POD to the second device; and deleting the POD from the server system; and otherwise simply deleting the POD from the server system upon expiry of the predetermined maximum time.

[0016] In accordance with yet another aspect of the present invention there is provided, a sender device for use by a sender to securely send documents. The device includes: a processor in communication with memory, a communication interface, and an input interface. The memory includes processor executable instructions that when executed cause the processor, to perform the steps of: assembling at least one piece of data into a package of data (POD); adding a manifest to the POD; authenticating the sender and the device with the server system; selecting a recipient from a plurality of users registered on the server system; receiving a public key for the selected recipient; encrypting the POD with the public key, thereby hiding the name and content of each of the at least one piece of data; and transmitting the encrypted POD to the server system.

[0017] In accordance with another aspect of the present invention there is provided a recipient device for use by a recipient to receive documents in a secure manner. The device includes a processor in communication with memory, a communication interface, and an input interface. The memory includes processor-executable instructions that when executed, cause the processor to perform the steps of: receiving notification from the server system that a message includes a package of data (POD) encrypted using the public key, is awaiting retrieval; authenticating the recipient with the server system; authenticating the device with the server system; receiving the encrypted POD; and decrypting the POD on the device, using a private key corresponding to the public key.

BRIEF DESCRIPTION OF DRAWINGS

[0018] In the figures, which illustrate by way of example only, embodiments of the present invention,

[0019] FIG. 1A is a simplified schematic block diagram of a system enabling secure exchange of data among client computing devices interconnected to a server system via a data network, exemplary of an embodiment of the present invention;

[0020] FIG. 1B is a schematic block diagram of a system enabling secure exchange of data among client computing devices via a cloud service, exemplary of another embodiment of the present invention;

[0021] FIG. 2 is a simplified block diagram illustrating components of an exemplary embodiment of one of the computing devices device of FIG. 1 A;

[0022] FIG. 3 is another simplified schematic diagram depicting components of the server in the system of FIG. 1A;

[0023] FIG. 4 is a schematic block diagram illustrating stages in an exemplary process undertaken by the exemplary sender device, to prepare a package of data (POD) for secure transmission using the system of FIG. 1A;

[0024] FIG. 5 is a flowchart depicting steps involved in an exemplary process executed by the server of FIG. 1A;

[0025] FIG. 6 is a flowchart depicting steps involved in an exemplary process executed by the a sender using a device in the system of FIG. 1A or FIG. 1B; and

[0026] FIG. 7 is a flowchart depicting steps involved in another exemplary process executed by a recipient using another device, in the system of FIG. 1A or FIG. 1B. DESCRIPTION OF EMBODIMENTS

[0027] A description of various embodiments of the present invention is provided below. In this disclosure, the use of the word “a” or “an” when used herein in conjunction with the term “comprising” may mean “one,” but it is also consistent with the meaning of “one or more,” “at least one” and “one or more than one.” Any element expressed in the singular form also encompasses its plural form. Any element expressed in the plural form also encompasses its singular form. The term “plurality” as used herein means more than one, for example, two or more, three or more, four or more, and the like. Directional terms such as “top”, “bottom”, “upwards”, “downwards”, “vertically” and “laterally” are used for the purpose of providing relative reference only, and are not intended to suggest any limitations on how any article is to be positioned during use, or to be mounted in an assembly or relative to an environment.

[0028] The terms “comprising”, “having”, “including”, and “containing”, and grammatical variations thereof, are inclusive or open-ended and do not exclude additional, un-recited elements and/or method steps. The term “consisting essentially of” when used herein in connection with a composition, use or method, denotes that additional elements, method steps or both additional elements and method steps may be present, but that these additions do not materially affect the manner in which the recited composition, method, or use functions. The term “consisting of” when used herein in connection with a composition, use, or method, excludes the presence of additional elements and/or method steps.

[0029] In addition, the terms “first”, “second”, “third” and the like are used for descriptive purposes only and cannot be interpreted as indicating or implying relative importance.

[0030] In the description of the invention, it should also be noted that the terms “mounted”, “linked” and “connected” should be interpreted in a broad sense unless explicitly defined and limited otherwise. For example, it could be fixed connection, or assembled connection, or integrally connected; either hard-wired or soft-wired; it may be directly connected or indirectly connected through an intermediary. For technical professionals, the specific meanings of the above terms in the invention may be understood in context.

[0031] In the drawings illustrating embodiments of the present invention, the same or similar reference labels correspond to the same or similar parts. In the description of the invention, it should be noted that the meaning of “a plurality of” means two or more unless otherwise specified; The directions or positions of the terms “up”, “down”, “left”, “right”, “inside”, “outside”, “front end”, “back end”, “head”, “tail”, the orientation or positional relationship shown in the drawings is merely for the convenience of describing the invention and simplifying the description rather than indicating or implying that the indicated device or element must have a particular orientation and be constructed and operated in a particular orientation, and therefore cannot be used as a limitation of the invention.

[0032] This disclosure describes a Data Transfer System (DTS) exemplary of an embodiment of the present invention, designed to deliver one or more packages of data (POD) to business users securely and with assurances of arrival at the correct destination. The exemplary system provides a method for a sending user or client to transmit a POD to a receiving user or client of the DTS, and of verifying exact locations of departure and arrival points of the POD.

[0033] The contents of the POD are encrypted using recipient’s public encryption key and transferred through a secure socket layer (SSL) or transport layer security (TLS) tunnel to the verified recipient. Upon arrival, the content of the POD is decrypted and verified and the sender and recipient are notified that the POD arrived exactly as sent and to the correct verifiable destination. Overall System Diagram

[0034] FIG. 1A is a simplified schematic block diagram of a system 100 exemplary of an embodiment of the present invention. System 100 includes a server system including a server 102 in data communication with a number of devices 104-1, 104-2, 104-3, ... , 104-n (individually and collectively “devices 104”) which may be wired or wireless computing devices such as desktop computers, laptops, tablets, smart phones, other handheld devices and the like.

[0035] Devices 104 are in data communication server 102 over a data network 108 such as the Internet, a wide area network (WAN), a campus area network (CAN), a local area network (LAN), a metropolitan area network (MAN) or similar networks which may be a wired network, a wireless network or a combination thereof.

[0036] A number of users 106-1, 106-2, 106-3, ..., 106-n (individually and collectively “users 106”) use devices 104-1, 104-2, 104-3, ... , 104-n respectively to send or receive data from other users via the network 108 and server 102.

[0037] The data communication between the device 104 and server 102 may typically take place using an encrypted link such as SSL/TLS. Of course, in alternate embodiments, other cryptographically or otherwise secured channels may be used for data communication between devices 104 and server 102.

[0038] Server software 116 executes on server 102. Server software 116 may include several components including: a presentation layer software component 110 (e.g., a Webserver); a middle layer or logic layer component 112 which typically contains the proprietary logic or custom rules to be implemented by server 102; and a database 114 which may be considered a persistence layer component, which stores persistent data for use in multiple sessions. The database 114 may be a conventional relational database management system (RDBMS) such as one of the many commercially available databases, including but not limited to, Oracle™, Microsoft SQL Server™, IBM DB2™, MySQL ™ and the like.

[0039] Server 102 may be in data communication with a certificate server 118.

[0040] Server software 116 may additionally include or have access to one or more databases or registries (not specifically illustrated) of data used for verification, devices identification and authentication, including but not limited to: a geo-code database, internet protocol (IP) address verification data, whitelists and blacklists and other known trusted public addresses. As will be elaborated later, destination identifiers are verified by software running on devices 104 by cross-referencing with server 102.

[0041] Server software 116 also includes, or has access to, hardware identifiers on components on devices 104 for use in registration of devices and maintaining a registry or database of resisted devices, as well as for use in tracking data delivery to registered devices. These may include media access control (MAC) addresses, IP addresses, and the like.

[0042] Server software 116 may also include a billing component for transaction credits and contracts.

[0043] FIG. 1B is a simplified schematic block diagram of another system 100’ exemplary of an embodiment of the present invention. System 100’ includes a cloud service system having a cloud server 130, in data communication with a number of devices 104-4, 104-5 used by users 106-4, 106-5 respectively. The devices 104-4, 104- 5 may be wired or wireless computing devices such as desktop computers, laptops, tablets, smart phones, other handheld devices and the like.

[0044] Cloud server 130 may include many hardware components and associated software services including, a cloud storage 124, a web application 122 (which may be an Azure™ web app), a transaction database 126, an application database 128, a portal web app 120, and a website 129. [0045] An identity server 140 in data communication with the components of the cloud server 130 described above, provides identity related services to the client devices 104. In the depicted embodiment, the identity server 140 includes an identity server web app 132, an identity server administrator 134, an identity database 136 and an identity server application programming interface (API) 138.

[0046] In a variation of the above embodiment, some or all of the components of the identity server 140 may be part of the same cloud server 130.

[0047] As may be appreciated by those skilled in the art, the cloud service 130 may be part of a cloud computing platform that allows access to computing resources or services such as servers, storage, networking, and software over the internet or “the cloud” from a cloud service provider. One common example of a cloud-computing platform is the Azure™ platform from Microsoft Corporation. Other platforms include Oracle Cloud Platform™, Google Firebase™, SAP Cloud Platform™, IBM Cloud™, Amazon AWS™, Salesforce App Cloud™, Pivotal Cloud Foundry™ and the like.

Server Hardware

[0048] FIG. 2 depicts a simplified block diagram of an embodiment of server 102. Other servers within the cloud server 130 or identity server 140 depicted in FIG. 1B typically have a similar hardware architecture and will not be separately described.

[0049] Server 102 includes a processor 202 such as, but not limited to, a microprocessor or a central processing unit (CPU), a memory 204, and interface circuit 206 adapted to provide a means of communication between processor 202 and memory

204

[0050] Interface circuit 206 also interconnects input and output (I/O) components such a display 214, a network adapter 216, and a storage medium 210. Optionally interface circuit 206 also interconnects a printer 212 and one or more additional peripherals 218a to 218c (individually and collectively, peripherals 218). Suitable peripherals 218 include, but are not limited to a keyboard, a camera, a scanner, a touch panel, a joystick, an electronic mouse, touch screen, track-pad, and other input or pointing devices, and any combination thereof. In other embodiments, the interface circuit does not interconnect a printer. In other embodiments, the interface circuit does not interconnect any peripherals.

[0051] Memory 204 may be in the form of volatile memory or a combination of volatile and non-volatile memory, including, but not limited to, dynamic or static random access memory (RAM), read-only memory (ROM), flash memory, solid state memory and the like.

[0052] Interface circuit 206 includes a system bus for coupling any of the various computer components 210, 212, 214, 216, 218 to the processor 202. Suitable interface circuits include, but are not limited to, Industry Standard Architecture (ISA), Micro Channel Architecture (MCA), Extended Industry Standard Architecture (EISA), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCI-X), Accelerated Graphics Port (AGP), Peripheral Component Interconnect Express (PCIe).

[0053] Storage medium 210 can be any suitable storage medium including, but not limited to, a hard disk drive (HDD), a solid state drive (SSD), EEPROM, CD-ROM, DVD, and any other suitable data storage element or medium. Storage medium 210 is readable by processor 202. Display 214 can be any suitable display including, but not limited to, a touch screen.

[0054] Network adapter 216 in server 102 facilitates wired or wireless connections to an Ethernet, Wi-Fi™, Bluetooth™, cellular network or other suitable network, thereby enabling connection to shared or remote drives, one or more networked computer resources, other networked devices, I/O peripherals and the like. [0055] It will be understood by persons of skill in the art, that the presentation layer, logic layer and persistent layer are logical abstractions and a jut one or two software components may contain all of the necessary processor executable instructions by server 102. Conversely, many more than the components illustrated in FIG. 1A may be involved in implementing the software running on server 102 depending on the choice of hardware and software for implementation.

[0056] It should be readily understood by persons having skill in the art that server 102 may be implemented on many types of computer systems including a stand-alone computer, an interconnected cluster of two or more computing devices, a server farm, or on as on-demand delivery of compute power, database storage, applications, and other information technology (IT) resources through a cloud service platform available via the internet or similar network. The illustration in FIG. 1A and FIG. 2 are only simplified examples and in no way limiting.

Device Hardware

[0057] FIG. 3 depicts a simplified block diagram of an exemplary embodiment of one of the devices 104 of FIG. 1A. As depicted, each device 104 includes a processor 302 such as, but not limited to, a microprocessor, a central processing unit (CPU), a microcontroller or the like, a memory 304, an input 308, a battery 320, and a display 314. Processor 302 and memory 304 communicate with each other through an interface circuit 306. Interface circuit 306 also interconnects components including, but not limited to, a wireless network interface 316, a storage medium 310, an input-output (I/O) interface 322, a camera 326 and an audio codec 312. Audio codec 312 in turn connects to one of more microphones 318 and one or more speakers 324.

[0058] Wireless network interface 316 includes one or more of a wireless LAN transceiver (e.g. Wi-Fi™ transceiver), an infrared transceiver, a Bluetooth™ transceiver, and a cellular telephony transceiver. I/O interface 322 may include one or more wired power and communication interfaces such as a USB port. [0059] Input 308 may be a keypad or keyboard, a touch panel, a multi-touch panel, a touch display or multi touch display having a software keyboard or keypad displayed thereon.

[0060] Devices 104 also contain complementary network adapters therein for connecting with a suitable network, and are further equipped with browser or other thin- client or rich-client software. As contemplated in this embodiment, network adapter 216 comprises a network interface card that allows wired or wireless communication with other computers through a network such as data network 108. In other embodiments, the network adapter does not include a wireless network interface card. In yet other embodiments, the network adapter communicates with the network via a wired connection.

[0061] Devices 104 may run any of the standard operating systems including Windows® family of operating systems, macOS™, iOS™, Android™, Linux®, and Java™ and the like.

General Operation

[0062] In operation, a transmitting user (e.g., user 106-1) registers his device (e.g., device 104-1) on the system 100 and then transmits one or more documents using the exemplary embodiment of a method or process described below, to a recipient (e.g., user 106-2) who retrieves the documents on her registered device (e.g., device 104-2).

[0063] Prior to transmission of documents, each user and each associated device are registered on system 100. That is, in the above example, user 106-1 has creates account and registers his device 104-1 on server 102, and user 106-2 also creates an account and registers her device 104-2 on server 102.

[0064] In one embodiment, upon registration, server 102 creates a device authentication code for each device registered therein and stores each authentication code on database 114. [0065] In one specific embodiment, a device authentication procedure executed by server 102, for a given device, utilizes a minimum of five (5) hardware or software identifiers to create an authentication code unique to the device. Of course, in other embodiments, more or fewer parameters or identifiers may be utilized to construct the device authentication code.

[0066] During device authentication, a current authentication code is obtained for a current device attempting to connect to server 102, and a match must be found in database 114 with a stored authentication code corresponding to a registered device. Otherwise, the device authentication process is declared to have failed and the device must be re-authenticated. A device that fails re-authentication may be denied access to server 102.

[0067] To transmit documents or other data, the user 106-1 first creates a package of data (POD) and readies it for transmission. This preparation of the package is schematically illustrated in FIG. 4.

[0068] As depicted data in the form of one or more source documents 402-1, 402-2, 402-3 (individually and collectively “documents 402”) are assembled together and an internal shipping manifest 404 is added to prepare a package of data (POD) 406.

[0069] Software on the sender’s device 104-1 connects to server 102 via SSL/TLS tunnel and requests an outgoing POD transmission.

[0070] Server 102 verifies the sender using user name and password. Server 102 also performs device authentication at the time of user login. An authentication token is provided to server 102 by device 104-1. Server 102 checks the authentication token provided and if the authentication token has not expired, then the device 104-1 is allowed access to server 102 and software 116. If the authentication token has expired then re-authentication takes place. [0071] In this exemplary embodiment, server 102 also verifies the geo-location of the sender’s device 104-1.

[0072] Successful verification of the sender entails at least some, and typically all, of the following: (a) successful authentication of user 106-1 via a user name and password or similar scheme; (b) the unique ID of device 104-1 generated by server 102 matches the corresponding device authentication code stored in database 114 (thereby authenticating the device); and (c) ensuring the geo-location of device 104-1 is in a permissible area. After verification of the sender, server 102 retrieves one or more public keys of the intended recipient(s) of the POD (e.g., the public keys of device 104- 2) and sends the keys to the sender’s device 104-1. After the POD is closed, the keys are retrieved from the server 102 and sent to the device 104-1 on request for each recipient chosen from the address book.

[0073] In this embodiment, server 102 does not use received GPS (global positioning system) coordinates as its exclusive method of verification of delivery point since GPS receivers may not exist on some devices or can be turned off, and may even be spoofed in a browser.

[0074] After the transmitting user 106-1 submits the POD 406 via a send command (e.g., by clicking a “Finish” button on the local software), local software on the device 104-1 will begin the process of preparing the POD for transmission.

[0075] As shown in FIG. 4 the preparation process includes taking a hash value for all documents 402 inside the POD 406 as well as collecting various metadata regarding the documents 402 such as number of pages, size of documents, and type of documents. These items are added to the internal shipping manifest 404 for each POD 406 including a server generated unique internal identifier for each POD 406 being transported. [0076] The POD 406 is then compressed to form a compressed POD 410. Many compression schemes, which may be lossless or lossy, are well known and will be familiar to persons of skill in the art.

[0077] Documents that require accuracy are compressed using lossless compression schemes while image and video data may be compressed using known compression standards such as one of the JPEG, MPEG or other image, audio or video compression standards that may be lossy. JPEG standards for example, now include lossless additions, to the initial set of lossy image compression standards.

[0078] Asymmetric public key encryption schemes may be employed by system 100 or system 100’ for encryption. In a typical asymmetric key encryption system, a recipient device generates pair of keys or codes sometimes known as public-private key pair. Any sender can then encrypt messages to the recipient using the recipient’s public key. However only the holder of the paired private key (corresponding to the public key used in the encryption) can decrypt the encrypted message. The security of the encryption scheme thus depends on the secrecy of the private key. That is, the recipient device keeps its private key secret while providing the public key to the transmitter so that only the recipient can decrypt messages encrypted with the public key. The compressed POD 410 is encrypted using public keys 408 of the recipient device 104-2 to create an encrypted POD 412.

[0079] As may be appreciated, external packing list 414 is not encrypted or compressed. Server 102 needs to read external packing list 414 to determine where to send the compressed POD 410. The external manifest or packing list 414 goes as an attachment to the compressed and encrypted POD 412, after the compression and encryption steps are competed.

[0080] In some embodiments, the compression step may be omitted. Users 106 do not directly manage the keys 408 on their devices 104. The software executing on devices 104 automatically manages the keys 408 whereas the users 106 need not know anything about the management of the keys. In other words, user intervention is not required in the managing of keys or the encryption process.

[0081] As noted earlier, compressed POD 410 is to be encrypted by device 104-1 after obtaining the public keys 408 corresponding to the recipient device 104-2 from server 102. The recipient device 104-2 would be able to decrypt the encrypted POD 412 upon successful receipt, using its private key corresponding to the public key used for encryption.

[0082] As will become apparent, after receiving the public key(s), software executing on device 104-1 creates hash values and collect metadata for the one or more documents residing inside the POD. Once these values have been collected by server 102 the POD will be compressed and then encrypted by device 104-1 using the public key(s) of recipient device 104-2. In one embodiment, the POD 410 is encrypted using 4096 bits.

[0083] The encrypted POD 412 will have hash values created and metadata collected for use by server 102 to help track the POD during transport and delivery.

[0084] After the POD is compressed and encrypted, new values for the size and its unique identifier (ID) are added to an external packing list 414. The contents of external packing list 414 include a hash value of the encrypted POD 412 for verification of delivery purposes. Other necessary for billing and transmission, such as service options and recipients, are added to external packing list 414.

[0085] When the hashes and metadata have been collected, the information will be sent to server 102 verifying that the POD is ready for transport to the intended recipient(s).

[0086] Following the preparation of the POD for transport, sending user 106-1 provides a command (e.g., such as clicking “Send” button on software executing locally) using device 104-1. Server 102 then receives the encrypted POD 412 and external packing list 414 over a secure channel (e.g. SSL/TLS connection) established between device 104-1 and server 102.

[0087] As may be appreciated, the encryption and decryption processes may be automatically handled by the devices 104 and server 102 of system 100 without user intervention.

[0088] A delivery notification will be sent by server 102 that signals the intended recipient(s) (i.e. , device 104-2 and/or recipient user 106-2) that a message or encrypted POD has been received and is awaiting delivery.

[0089] In one embodiment, software executing on the recipient’s device periodically checks for messages by connecting to server 102 via a secure tunnel (e.g. SSL/TLS tunnel) and looking for delivery notifications. In specific embodiments, 256-bit SSL/TLS tunnels are used between devices 104 and server 102. Of course, in other embodiments other secure communication channels can be used. In alternative embodiments, rather than an asynchronous polling-based approach, the notification may be a message sent directly to the recipient device, prior to the recipient device connecting to server 102. Devices that are not connected to server 102 may receive emails or SMS messages to inform or alert users to login for incoming messages.

[0090] Upon connecting to server 102, the recipient’s device 104-2 will have its geo location and unique hardware ID or device authentication code verified.

[0091] After successful verification of recipient device 104-2 by server 102 of system 100 the encrypted POD 412 will be transmitted to the recipient device 104-2.

[0092] After arrival on the device 104-2, software thereon will verify hash values and metadata taken after encryption on the sender’s end. [0093] Once that data integrity is established, the software on the recipient device 104-2 will decrypt the encrypted POD 412 using its private own key. The decrypted packet will then be decompressed.

[0094] Server 102 may verify further metadata and hash values taken prior to POD encryption on the sender’s device 104-1. If the values match then the recipient user 106-2 is informed of successful receipt of a POD.

[0095] After successful receipt of POD by intended recipient(s), metadata and hash data not needed for billing and data integrity checking purposes are disposed from server 102.

[0096] Notification of completed transaction is sent to sender user 106-1, SSL/TLS tunnels are closed and charges are applied.

Server operation

[0097] FIG. 5 depicts a flowchart for a process 500 that generally depicts one exemplary operation of the steps taken by server 102 when processing a request to transmit a package of data or POD.

[0098] As depicted, initially when a user wants to send a document server 102 receives user credentials (502) in the form of user name and password.

[0099] At step 504, server 102 obtains device identifier parameters. In this embodiment, a device authentication code is computed from the parameters of the device, and checked against stored corresponding data in database 114.

[00100] At step 506, server 102 obtains device geo-location coordinates.

[00101] At step 508, if server 102 successfully authenticates the sender, the process

500 continues to step 510 but otherwise terminates. [00102] In one embodiment, successful authentication of the sender (step 508), entails fulfilment of the following criteria:

[00103] (i) the sending user’s credentials (e.g., user name and password) must match an existing entry in database 114;

[00104] (ii) the device authentication code must match the corresponding code entry; and

[00105] (iii) the geo-location coordinates for the sender device must be within a permissible boundary that may be stored in database 114 or elsewhere in a manner accessible to server 102.

[00106] In other embodiments, other criteria may be used.

[00107] In step 509, server 102 sends a list of registered recipients to the sending device 104-1 and receives a selected one of the list of registered recipients.

[00108] In step 510, server 102 obtains and transmits one or more public keys of the selected recipient device (e.g., 104-2) to the sender.

[00109] In some embodiments, encryption keys have an average life span of seven (7) days before the device would have to create new keys. System 100 or system 100’ will only transport keys to or from fully authenticated devices 104. Newly created encryption key for the device(s) 104 would be verified, signed, and transported to server 102 immediately when the devices and users authenticate. The keys will be auto managed without user intervention using our certificate server and software that generates keys on the device.

[00110] The sender device uses the public keys to encrypt a POD, for example as illustrated in FIG. 4, and transmits the encrypted POD to server 102. [00111] In step 512, server 102 receives an encrypted POD from the sender device and provides notification to the recipient device (step 512). As noted above, in specific embodiments, a predetermined minimum number of parameters such as five (5) hardware or software ID’s is fed to an algorithm to create the current authentication code unique to the sender device to compare against the stored authentication code.

[00112] A notification is provided by server 102 to the recipient device that a message or POD is waiting for delivery or downloading at step 514. In the depicted embodiment, server 102 checks if a predetermined period has elapsed since the notification or receipt of the POD.

[00113] Upon successful authentication of the recipient and receipt of a request from the recipient user 106-2 using the recipient device 104-2 (step 518) to download the POD, server 102 checks if a predetermined time after the notification or receipt of POD has elapsed (step 516) indicating a timeout.

[00114] If a timeout has occurred, the POD and related data deleted is from server 102 (step 522).

[00115] Otherwise, if the recipient is authenticated (step 518) the encrypted POD is transmitted to the recipient device (step 520). Other related data such as those in the external packing list 414 may also be sent to the recipient device. After the POD is successfully downloaded onto the recipient device, the POD and related data deleted is from server 102 (step 522). The exemplary process 500 then terminates.

Sender operation

[00116] FIG. 6 depicts a flowchart of a process 600 depicting steps involved in an exemplary process executed by a sender device 106-1 using device 104-1 in the system of FIG. 1A to securely send documents. The processor of the device 104-1 executes software containing processor executable instructions that when executed cause the processor, to perform the steps depicted. [00117] Initially at step 602, device 104-1 registers itself and/or sending user 106-1 on server 102, if not already registered. Upon registration, server 102 associates the sender user 106-1 with device 104-1.

[00118] At step 604, device 104-1 performs the step of assembling at least one piece of data, which may be in the form of one or more documents, multimedia files such as video, audio or image files, and the like, into a package of data (POD).

[00119] At step 606, device 104-1 authenticates the sending user 106-1 and the sending device 104-1 with server 102.

[00120] At step 608, device 104-1 receives a list of registered users that can be valid recipients, from a plurality of users registered on server 102.

[00121] At step 610, device 104-1 selects a recipient from the list of plurality of users registered on server 102 that were received at step 606.

[00122] At step 610, device 104-1 receives a public key for the selected recipient from server 102.

[00123] At step 612, the device 104-1 performs the step encrypting the POD with the public key, thereby hiding the name and content of each piece of data assembled into the POD.

[00124] At step 612, the device 104-1 transmits the encrypted POD to server 102. [00125] Process 600 then terminates.

Receiver operation

[00126] FIG. 7 depicts a flowchart of a process 700 depicting steps involved in an exemplary process executed by the recipient user 106-2 using device 104-2 in the above exemplary scenario of transmitting documents from device 104-1 to device 104-2 securely. The processor of the device 104-2 executes local software (i.e. , application, app or the like) containing processor executable instructions that when executed cause its processor, to perform the steps depicted.

[00127] At step 702 device 104-2 receives notification from server 102 that a message comprising a package of data (POD) encrypted using its own public key, is awaiting retrieval.

[00128] At step 704, device 104-2 connects to server 102 and authenticates the recipient user 106-2.

[00129] At step 706, device 104-2 authenticates the device with server 102. As noted above, this may involve five (5) or more hardware keys to create a unique authentication code device 104-2 as well geolocation checks.

[00130] At step 708, the user and device having been authenticated, device 104-2 receives the encrypted POD.

[00131] At step 710, the recipient device 104-2 decrypts the POD on the device, using a private key corresponding to the public key used for encryption.

[00132] At step 712, the recipient device 104-2 may check for the integrity of the POD using a manifest.

[00133] At step 714, the recipient device 104-2 may decompress the POD, if the original POD was compressed.

[00134] At step 716 the recipient device 104-2 may send a acknowledgment of safe receipt.

[00135] The process 700 then terminates.

Advantages [00136] There are many advantages offered by the present invention and the exemplary embodiments described above.

[00137] Firstly, the above exemplary embodiments do not solely rely on username and password. Many conventional data exchange systems even for encrypted data transfer use username and password authentication and on occasion third party authentication such as RSA (Rivest-Shamir-Adleman) encryption. Such systems do not verify that the device is an authorized device allowed to access the system - specifically the server in the system. Embodiments of the present invention verify or authenticate the device hardware itself as well as its location to insure the POD is delivered exactly to the correct place and device. As a further advantage, the described embodiments can easily ensure that data does not cross national boundaries to prevent potentially violating security or regulatory compliance.

[00138] Secondly, after sending devices and their location are verified, users wishing to send a document to a recipient may create a new POD but receive public keys necessary for encryption only after selecting a recipient name from the server’s address book as depicted in step 509 of process 500. This enhances the security of the data transfer mechanism by ensuring that both sender and receiver are verified first.

[00139] Thirdly, unlike traditional data transfer systems, system 100 (or system 100’) stores public encryption keys for registered devices on server 102 (or cloud server 130) and delivers them as requested to authenticated devices.

[00140] Although the use of encryption for documents is known, as noted above, keys on system 100 (or system 100’) have a predetermined lifespan (e.g., average of a seven days) after which they expire.

[00141] Newly created encryption key for registered devices are verified, signed, and transported to server 102 (or cloud server 130) immediately when the devices and users authenticate. In addition, keys will be auto-managed without user intervention using a certificate server (e.g., certificate server 118) and software on devices 104 that generate keys on the respective device.

[00142] As a result, key management and security requires no intervention, understanding, or knowledge by users 106. By providing end-to-end encryption and automating the encryption process on the client devices 104, manual trust verification processes are eliminated and there is virtually no risk of interception of pre-shared keys.

[00143] Moreover, server 102 only collects metadata and hash values of documents inside a POD and all metadata is created by the devices 104 and not by server 102. Advantageously, this prevents potential violation of the privacy for anyone transmitting documents through system 100 (or system 100’) as server 102 (or cloud server 130) cannot decrypt or view the contents of a POD. Server 102 (or cloud server 130) will only collect metadata and hash values necessary for billing and transmission purposes.

[00144] Data necessary for billing and transmission, such as service options and recipients, are added to external packing list 414. After the POD 406 is compressed and encrypted and the new values for the size and unique ID are added to the external packing list 414.

[00145] Server 102 (or cloud server 130) will not be able to access any other information about the contents encrypted POD 412 or even see the names of the documents inside the encrypted POD 412. This means that a document being transmitted by some other systems could be named “Smith, John: Colonoscopy 10/10/2017” and could be seen as a violation of that person’s privacy simply because the information in the name of the document could be considered confidential. Server 102 however cannot see any privacy related information regarding what is inside the encrypted POD 412, as server 102 does not have access to the private keys.

[00146] Advantageously, this would naturally meet or exceed privacy regulations without any need for user intervention. No one in system 100 other than the intended recipient can access anything inside the encrypted POD 412. Privacy concerns are thus eliminated for transmissions between sender and receiver.

[00147] As noted above, once the POD is ready the sender’s device (e.g., 104-1) will contact server 102 (or cloud server 130) via a secure tunnel (e.g., SSL/TLS tunnel) and send a request to transmit the package of encrypted POD and external packing list to server 102 (or cloud server 130).

[00148] The package will remain on our server 102 (or cloud server 130) for a predetermined maximum specified time until delivery. Server 102 (or cloud server 130) may also decide the service level required for each item and prioritize the use of bandwidth and resources accordingly.

[00149] In one embodiment, POD 406 or compressed POD 410 is encrypted at 4096 bits or higher and sent inside an AES 256 SSL/TLS tunnel. Because only verified devices 104 can connect to server 102 (or cloud server 130), and can only connect using SSL/TLS tunnels, security will be in excess of standard industry procedures.

[00150] This will result in extremely secure transmission that is almost impossible to break using today’s technology for a non-state actor. Even if the SSL/TLS tunnel is breached, the encrypted POD will require centuries to decrypt. Unauthorized access to server 102 (or cloud server 130) will only reveal encrypted data.

[00151] In some embodiments, critical and urgent notifications will be made using email or SMS messages depending on the recipient device to let the user know that to login to server 102 (or cloud server 130) and retrieve an awaiting POD.

[00152] A recipient device will use the software and private keys to decrypt the encrypted POD 412. Once the POD 412 is decrypted, it will also be decompressed. Information on the internal packing list or manifest 404 containing such as hash values and the like, will be checked against the received POD to ensure data integrity. This allows for a very high degree of confidence that the transported data has not been tampered with.

[00153] In some embodiments, acknowledgement of successfully delivered POD is made and triggers events on server 102 (or cloud server 130) and on the client devices 104. The server will receive a signal telling it to delete the POD and any related data such as hash values collected during sending and receiving. The user’s device 104 may pop up a message within a local software (e.g., app) indicating that a new downloaded POD is available to open.

[00154] Having thus described, by way of example only, embodiments of the present invention, it is to be understood that the invention as defined by the appended claims is not to be limited by particular details set forth in the above description of exemplary embodiments as many variations and permutations are possible without departing from the scope of the claims.

Claims

What is claimed is:

1. A server system for securely transmitting at least one piece of data from a first device associated with a sender to a second device associated with a recipient, the server system comprising: a processor in communication with memory, a communication interface, and an input interface, wherein the memory includes processor executable instructions that when executed, cause the processor to perform the steps of: a) authenticating the sender and the first device; b) receiving a package of data (POD) comprising an encrypted version of said at least one piece of data from the first device; c) notifying the recipient that the POD is awaiting retrieval; d) authenticating the recipient and the second device; and e) upon receipt of a request from the second device to download the POD before a predetermined maximum time after said notifying, sending the POD to said second device, and deleting the POD from the server system; and otherwise deleting the POD from the server system upon expiry of said predetermined maximum time.

2. A server system of claim 1 , wherein prior to said authenticating the sender and the first device, the processor executable instructions when executed, further cause the processor to perform the steps of: a) registering the sender and the first device on the server system, and associating the sender with the first device; and b) registering the recipient and the second device on the server system, and associating the recipient with the second device.

3. The method of claim 1, wherein the server system comprises one or more cloud servers.

4. The method of claim 1, wherein said piece of data includes at least one item selected from the group consisting of: a document, a multimedia file, an audio file, a video file, and an image file.

5. A method for securely transmitting at least one piece of data from a first device associated with a sender to a second device associated with a recipient using a server system, the method comprising: a) authenticating the sender and the first device; b) receiving a package of data (POD) comprising an encrypted version of said at least one piece of data from the first device; c) notifying the recipient that the POD is awaiting retrieval; d) authenticating the recipient and the second device; e) upon receipt of a request from the second device to download the POD before a predetermined maximum time after said notifying, sending the POD to said second device; and deleting the POD from the server system; and otherwise deleting the POD from the server system upon expiry of said predetermined maximum time.

6. The method of claim 5, further comprising receiving acknowledgement of receipt of the POD from the second device prior to said deleting.

7. The method of claim 5, further comprising receiving a send command prior to said receiving said POD.

8. The method of claim 5, further comprising registering said first and second devices on said server system prior to said authenticating said sender.

9. The method of claim 5, wherein the at least one piece of data is encrypted via asymmetric encryption having a public key and a corresponding private key, and wherein the private key is inaccessible to the server system, so that the server system cannot decrypt the at least one piece of data.

10. The method of claim 5, wherein said receiving the POD is accomplished via a secure socket layer (SSL) tunnel established between the first device and the server system.

11. The method of claim 5, wherein said sending the POD to the second device is accomplished via one of a secure socket layer (SSL) tunnel and a transport layer security (TLS) tunnel established between the second device and the server system.

12. The method of claim 5, wherein said authenticating said first device or said second device involves using hardware and software parameters of said first device or said second device respectively.

13. The method of claim 10, wherein at least five (5) of said hardware and software parameters associated with said first or second device are used for authenticating said first device or said second device respectively.

14. The method of claim 5, wherein the second device has an associated private key and public key, the first device encrypts the at least one piece of data using the public key and the second device decrypts the POD using a private key.

15. A device for use by a sender to securely send data, the device comprising: a processor in communication with memory, a communication interface, and an input interface, wherein the memory includes processor executable instructions that when executed cause the processor to perform the steps of: a) assembling at least one piece of data into a package of data (POD); b) adding a manifest to the POD; c) authenticating the sender and the device with a server system; d) selecting a recipient from a plurality of users registered on the server system; e) receiving a public key for the selected recipient; f) encrypting the POD with the public key, thereby hiding the name and content of each of said at least one piece of data; and g) transmitting the encrypted POD to the server system.

16. The device of claim 15, wherein the processor further performs the step of registering the device on a server system, the server system associating the sender with the device prior to said authenticating.

17. The device of claim 15, wherein the processor further performs the step of providing at least five (5) hardware and software parameters associated with the device for said authenticating the device with the server system.

18. The device of claim 15, wherein the processor further performs the step of compressing the POD prior to said encrypting.

19. The device of claim 15, wherein the processor further performs the step of adding a manifest to the POD prior to said encrypting.

20. The device of claim 19, wherein the processor further performs the step of adding padding to the POD prior to adding the manifest.

21. The device of claim 15, wherein said encrypting utilizes 4096 bit encryption.

22. A device for use by a recipient to securely receive data from a server system, the device comprising: a processor in communication with memory, a communication interface, an input interface, wherein the memory includes processor executable instructions that when executed cause the processor to perform the steps of: a) receiving notification from the server system that a message comprising a package of data (POD) encrypted using the public key, is awaiting retrieval; b) authenticating the recipient with the server system; c) authenticating the device with the server system; d) receiving the encrypted POD; and e) decrypting the POD on the device, using a private key corresponding to the public key.

23. The device of claim 22, wherein the instructions cause the processor to register the device on a server system, prior to said receiving said notification, so that the server system associates the recipient with the device.

24. The device of claim 22, wherein the message includes a manifest, and wherein the processor further performs the step of examining the manifest to verify the data integrity of the POD.

25. The device of claim 22, wherein the processor further performs the step of acknowledging safe receipt of the POD.

26. The device of claim 15, wherein the processor further performs the step of providing at least five (5) hardware and software parameters associated with the device for said authenticating the device with the server system.