CA3099190A1

CA3099190A1 - Decentralized and automated data storage, processing and sharing system and related process

Info

Publication number: CA3099190A1
Application number: CA3099190A
Authority: CA
Inventors: Marc Guerin
Original assignee: Nuutok Entreprise Inc
Current assignee: Nuutok Entreprise Inc
Priority date: 2018-05-03
Filing date: 2019-05-02
Publication date: 2019-11-07
Also published as: WO2019210420A1

Abstract

A computer-implemented process and a decentralized and automated data storage, processing and sharing system are provided. The system comprises a plurality of local units, comprising a local primary server located on premise of said given client and a local backup server remotely located on a different premise. The primary local server stores proprietary files and operational data relating to the configuration and operation of the server; and runs an operating system (OS); server-related applications, and client-specific applications. A central system periodically receives, for each of the local units, the operational data from the local primary server and from the local backup server, and automatically performs remote management; maintenance; and surveillance of the local units, based on the operational data received, without storing or accessing the proprietary files on the local primary servers and on the local backup servers.

Description

DECENTRALIZED AND AUTOMATED DATA STORAGE, PROCESSING
AND SHARING SYSTEM AND RELATED PROCESS
TECHNICAL FIELD OF THE INVENTION
[0001] The present invention relates to systems and methods for storage, processing, and sharing of data. More particularly, the invention relates to a system comprising a plurality of local units located on different client sites, each unit including paired primary and backup servers, and method of remotely managing, commissioning, maintaining and/or monitoring the local servers via automated processes.
BACKGROUND

[0002] Centralized and hyperconverged storage systems are known in the art and are commonly used, for example, as cloud computing systems. In such systems, data and applications are stored using central server farms, or server clusters, remotely from the premises of clients and/or end-users, and without them knowing where their data and/or applications reside in the cloud. Hence, in order to access, store and/or update their proprietary data, companies must connect to remote central storage servers through internet networks and transfer their data over the networks, which can result in delays and security breaches, and therefore negatively impact the overall performance of local computer devices belonging to the client. Moreover, the storage of proprietary data pertaining to thousands of different companies and clients, in central server farms operated by a cloud service provider raises confidentiality and security concerns.

[0003] Also known in the art are Network-attached storage (NAS) servers, which consists of local storage servers storing proprietary data locally. Known NAS
manufacturers include QNAP, Synology, Thecus, as examples only. Such systems however usually offer little or no automation of data management processes, maintenance, monitoring, redundancy etc. and therefore regularly require manual intervention. As for data redundancy, some NAS providers offer to store proprietary data in their centralized system, which suffer from the same drawbacks as "conventional" cloud-based service and storage providers.

[0004] In view of the above, there is a need for an improved data storage and processing system which, by virtue of its design and components, would overcome or at least minimize some of the above-discussed prior art concerns.
SUMMARY OF THE INVENTION

[0005] According to a first aspect, a computer-implemented process is provided.
The process is performed in a decentralized and automated data storage, processing and sharing system, wherein the system comprises a plurality of local units, each associated with a given client and comprising a local primary server located on premise of said given client; a local backup server remotely located on a different premise, paired to the local primary server, and a central system remotely located from the plurality of local units. The primary local server stores proprietary files and operational data relating to the configuration and operation of the primary local server; and runs an operating system (OS); server-related applications, and client-specific applications. The local backup server is used for backing up the proprietary files and/or the client-specific applications and the operational data of the local primary server. The central system periodically receives, for each of the local units, the operational data from the local primary server and from the local backup server, and automatically performs at least one of remote management;
maintenance; and surveillance of the local units, based on the operational data received, without storing or accessing the proprietary files on the local primary servers and on the local backup servers. In possible implementations, at least some of the local units comprise additional local primary units and/or additional local backup servers.

[0006] According to a preferred embodiment, the local primary server and the local backup server cannot communicate with each other unless authorized by the central system.

[0007] Thus preferably, the central system authorizes, for the plurality of local units, the backing up process from the local primary server to the local backup server.
The local primary server and the local backup server both send respective communication requests to the central system, preferably at a specific date/time, and upon the central system receiving the respective communication requests, the central system authenticates the local primary server and the local backup server as a valid pair of servers from the same local unit. A secured communication channel can then be established between the local primary server and the backup primary server to perform data synchronization therebetween. The communication between both servers is thus only possible during the backup process, the backup server remaining isolated from the local primary server outside of the backup period.

[0008] Preferably, in case of failure of the local primary server, the local backup server takes over functions of the local primary server, upon receiving instruction from an authorized user login into the local backup server and requesting a changeover.

[0009] In possible implementations, the communication requests include identification information of the local primary server or of the local backup server, including: a unique identifier, a password, a MAC address and a Secure Socket Layer (SSL) certificate. Once authorized by the central system, the local primary server and the local backup server preferably communicate with one another via a Peer to Peer (P2P) connection or a secure relay connection.

[0010] In possible implementations, the central system manages access to the primary server for both local processing devices, which are part of the same local area network (LAN), and for external processing devices, not connected to the LAN.

[0011] The central system determines, based on public IP addresses of local or external processing devices, the routes the local or external processing device must use to communicate with the primary server, said routes including one of:
a LAN connection; an hybrid LAN/VPN connection; a proprietary VPN connection; a private VPN connection; and a P2P connection.

[0012] For at least some of the local primary servers that are not provided with networking functions, the central system can perform routing functions. The central system may also remotely manage firewall access of the primary local servers for connecting local and/or remote processing devices thereto.

[0013] When the route determined by the central system is a VPN connection, a Secure Shell (SSH) tunnel and/or Secure Socket Layer (SSL) tunnel connection can be established within the VPN connection, based on an IP address of the local or external processing device requesting access to one of the local primary servers.

[0014] In a possible implementation, a software robot continuously receives the operational data from the local primary servers and from the backup primary servers of the plurality of local units, analyses the operational data and automatically triggers updates, maintenance operations, an installation processes in some of the local primary servers and/ or local backup servers, depending on whether the operational data meets predetermined criteria. Preferably, the update, maintenance or installation process is first authorized by the local primary server and/or local backup server, or by an authorized user of the local unit concerned.
For example, the central system can automatically send a message to an authorized user (such as an email or a SMS text message), including a confirmation request that needs to be accepted by the authorized user for the update, maintenance and/or installation process to be executed.

[0015] In possible implementation, local computer devices, upon being identified as authorized devices of one of the local units, can provide access to shared drives of the local primary server of said local unit, via the central system, to external processing devices.

[0016] In a preferred implementation, the central system comprises a VPN
server, an Authentication, Authorization and Accounting server, (for example a RADIUS
server) and a P2P server. The VPN server manages secure VPN connections between the local primary server and the central system, and between the local backup server and the central system, for receiving communication requests from the primary and backup servers. The RADIUS server authenticates the local primary server and the local backup server as a valid pair of servers from the same local unit. The P2P server opens secured P2P communication channel between pairs of primary and backup servers to perform data synchronization therebetween, when scheduled.

[0017] In another preferred implementation, in the decentralized and automated data storage and sharing system, the RADIUS server authenticates the local primary server, or the local backup server, based on identification information sent by the primary and backup servers, the identification information including: a unique identifier, a password, a MAC address and a(n) Secure Socket Layer (SSL) certificate. Preferably, the RADIUS server determines, based on a public IP
address of local or external processing devices, the route said local or external processing device are allowed to use to connect to the primary server, said route including one of: a LAN connection; an hybrid LAN/VPN connection; a proprietary VPN connection; a private VPN connection; and a P2P connection.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Other objects, advantages and features will become more apparent upon reading the following non-restrictive description of embodiments thereof, given for the purpose of exemplification only, with reference to the accompanying drawings in which:

[0019] Figure 1 is a schematic diagram of a decentralized and automated data storage, processing and sharing system, according to an exemplary embodiment.

[0020] Figures 2 and 3 are schematic representations of a local primary server and a local backup server, according to possible embodiments.

[0021] Figure 4 is schematic representation of a central system, according to a possible embodiment.

[0022] Figure 5 is a schematic diagram illustrating the flow of communications between external processing devices, a local primary server and some of the components of the central system.

[0023] Figure 6 is a schematic diagram illustrating access to local primary servers pertaining to different clients/LAN, by different processing devices.

[0024] Figure 7 is a schematic diagram illustrating a decentralized and automated data storage, processing and sharing system, according to a possible embodiment, in which the central system performs routing functions for the local primary server.

[0025] Figure 8 is a schematic diagram illustrating a decentralized and automated data storage, processing and sharing system, according to a possible embodiment, wherein the local primary server is provided with networking/routing capabilities.

[0026] Figure 9A is a schematic diagram illustrating the different modules installed on local primary and backup servers, according to possible embodiments. Figure 9B is a flow chart illustrating communications between the different modules of the local and backup servers, paired in a local unit.

[0027] Figure 10 is a schematic diagram illustrating the connection sequence when an external processing device connects to a local primary server of a local unit.

[0028] Figure 11 is a flow chart diagram illustrating the steps for determining routes for communicating with a local primary server, depending the components and configurations of the local unit.

[0029] Figures 12A, 12B, 12C and 12D are screenshots from custom applications for managing operations of the servers of local units. Figures 12A and 12B
show table summarizing updates automatically applied on a local primary server, and backups completed for a given local unit. Figure 12C shows a window allowing an authorized user to manage the access of a computing device to primary servers, virtual servers running on the primary server, and folders and/or drives of the primary server. Figure 12D is a message window allowing an authorized user to switch roles of the local primary server and local backup server.
DETAILED DESCRIPTION

[0030] In the following description, the same numerical references refer to similar elements. The embodiments, geometrical configurations, materials mentioned and/or dimensions shown in the figures or described in the present description are embodiments only, given solely for exemplification purposes.

[0031] Moreover, although the embodiments of the data storage, processing and sharing system and corresponding parts/components thereof consist of certain configurations as explained and illustrated herein, not all components are essential and thus should not be taken in their restrictive sense. It is to be understood, as also apparent to a person skilled in the art, that other suitable components and applications may be used.

[0032] Referring to Figure 1, a decentralized and automated system 10, for storing, processing and sharing data is schematically illustrated, according to an exemplary embodiment. The system comprises several local units 20, 20' and 20", each associated to a given client, and a central system 40 in communication with each of the local units. A "client" can be a company, an enterprise, an association and even an individual having needs for storing its data and/or applications. A
"client"
can thus refer to an individual or a group of individuals acting as the operator(s) generating and using proprietary data stored in one of the local units 20, 20', 20" of the system 10.

[0033] Each local unit comprises at least one local primary server and at least one local backup server. In Figure 1, local unit 20, pertaining to company A, comprises local primary server 100 and local backup server 200. Three local processing devices 50 can access files and applications running on the local primary server 100. Another local unit 20', pertaining to company B, includes local primary unit 100', local backup server 200', two local processing devices 50', and networking/routing device 130'/150'. An external device 60' can access the local primary server 100'. Yet another local unit 20", pertaining to company C, includes two local primary servers 100", two local backup servers 200", and local processing device 50", part of the same LAN as the primary servers 100". In this example, external devices 60" has access to local primary servers 100". It is also possible for external device 60' to have access to local primary server 100, from company A, and to local primary server 100', from company B, if device 60' runs a custom-based/wizard mobile app, and if it has been granted access by authorized users of primary servers 100 and 100', via the central system 40. Of course, the system of the invention can include a different number of local units, from hundreds to thousands, and each local unit can have a different confirmation, with more or less primary servers, backup servers, routers, etc.

[0034] A local processing device, generally identified by reference number 50, refers to a device that is connected/part of the same LAN as the local primary server, and which communicates directly with the local primary server, without the central system being involved. An external processing device is a device which is not connected to the same LAN as the local primary server, and therefore requires the central system to be involved to determine communication routes and protocols to be used for the external device to communicate with a local primary server.
In use, a given local primary server, such as server 100, is thus connected to one or more local computer(s) 50, via wired or wireless LAN connections, to access the proprietary files and applications stored on the server 100. External processing devices are generally identified by reference number 60. A "processing device"
can include desktops, laptops, tablets, smartphones and the likes.

[0035] A local unit comprises a minimum of two servers, consisting in a local primary server and a local backup server, the local backup server being paired to the local primary server. In some embodiments, local units can include additional local primary servers and/or additional local backup servers. By "local", it is meant that the servers or devices are located on premises pertaining or relating to the client, such as in its headquarters, offices or branches, or in employees' houses or apartments, or in a place rented by the client. In other words, the primary server(s) and backup server(s) of a given client can be physically accessed and/or moved by the clients, as opposed to cloud-based servers, where clients do not know where their data/applications are physically located and cannot access the cloud-servers.

[0036] The local primary server(s) comprises a computer-readable memory storing proprietary files, such as text-based, sound, image and/or video, spreadsheets, software libraries, presentations documents, computer-assisted drawing (CAD) files, etc. The local primary server may also store and execute client-specific/proprietary applications, such as text processing applications, calculating and graphic tools, sound, video and image editing applications, ERPs, accounting and/or inventory software applications, software compilers, etc. The local primary server thus includes one or more processors for executing the operating system (OS), the client-specific applications and any other server-related or networking applications. The term "proprietary files" or "proprietary data" is used to define client data, i.e. data generated and owned by a specific client, and not related to the operation, function and/or management of the primary and/or backup servers of the corresponding local unit. "Proprietary files or data" also extends to databases and data stored therein relating to data generated and owned by a specific client.

[0037] The local primary server also stores operational data relating to its own configuration and operation, as well as an operating system (OS) and server-related applications, such as networking applications for example. The term "operational data" (also referred to as "functional data"), refers to non-proprietary data, i.e. data not generated and used by a specific client in the execution of personal or work-related tasks, but instead generated and/or used to monitor or manage operation of the local server, either locally, or remotely, by the central system 40. Operational data can include computer code files generated by the operating system (OS) of the primary server, system parameter files, user configuration files, executable files or applications files installed on the local primary server and/or local backup server, log files, registry files, etc.

[0038] A schematic representation of a local primary server 100 is illustrated in Figure 2. Local primary server 100 includes storage means or memory 110, for storing the proprietary files and applications, as well as the OS and any server-related files and applications. Local primary server 100 comprises processor(s) 120, for executing/processing the files and applications; network controller 130, to connect the primary server to a local network (i.e. a LAN) and firewall 140, to monitor and control incoming/outgoing data traffic on the server. The local primary server 100 is also connected to router 150, to access the internet and communicate with the remote system 40. As can be appreciated, local primary servers are more than simple Hard Disk Drives (HDD).

[0039] According to possible exemplary embodiments, the local primary server can comprise from 4TB to 16TB of storage capacity; a motherboard; caching memory;
such as 64MB to 128MB; Random-Access Memory (RAM), such as between 4GB
and 64GB; optional Solid State Drive (SSD), such as 128MB, 256GB, 6TB or 38TB; multi-core processor(s); a custom-OS; server status indicators, such as color LEDs; one or more networking components, such as Small Form Factor Pluggable Transceivers (SFP+), of 2Gb or 10Gbe. The local servers 100, 200 can also support Virtual Machines (VM), including Windows, Linux and/or Unix VMs.
The local primary servers therefore preferably include hypervisor and/or virtualization technologies, to create and run virtual machines. Hence, a local primary server 100 can operate as a host machine running one or more guest machine(s) having similar characteristics than the local primary server 100.
Each one of the guest machines can be remotely managed by the central system 40.
The configurations provided above are only exemplary, and local primary servers may include less or more components and capacities than those listed above.

[0040] A local backup server can comprise any of the components listed the previous paragraph and is typically remotely located on a different premise from the local primary server it is paired with. As illustrated in Figure 3, a local backup server 200 thus comprises at least computer-readable memory 110 and processor(s) 120 for backing up the proprietary files and/or the client-specific applications and the functional data of the local primary server, as well as a network controller 130, and a firewall 140. Network controllers 130 can include an LTE Card, a Wi-Fi card, a microwave transmitter, a PCI or PCI Express card, or the like. The backup server 200 is also connected to the internet via a router 150, to communicate with the remote center 40. The local backup server is preferably physically away from its paired local primary server, to prevent both servers from being damaged or inaccessible, in case of disasters, such as a fire, a flood, an explosion, or extended power outage.

[0041] The central system 40 is remotely located from the plurality of local units.
The central system 40 can also be referred to a "network operational center".
The central system comprises one or more central servers, applications, APIs, and software routines that periodically receives and analyses, for each local unit, the operational files/data sent by the plurality of local primary and backup servers, from the many different local units. The central system automatically performs remote management; maintenance; and/or surveillance of the local servers from the local units, based on the operational files and data received, without storing or accessing the proprietary data on the local primary servers and on the local backup servers. By "automatically", it is meant that the monitoring, maintenance and commissioning is done by software robots, without human intervention.

[0042] Referring to Figure 4, possible components of the central system 40 are illustrated. The central system 40 can be located in a single site or building, or it can be distributed in more than one location. As shown in Figure 4, the central system includes several databases 470 and central servers 400, including one or more Virtual Private Network (VPN) server(s) 420, such that communications between the local primary servers and/or backup servers, and also between external processing devices and the primary servers, transit via encrypted connections. The central system 40 also includes an authentication, authorization and accounting (AAA) server 460, coupled to a database 472, to manage and connect both external and internal processing devices to the different local units. In a preferred embodiment, a Remote Authentication Dial-In User Service (RADIUS) server 460 and a RADIUS database 472 are used. The RADIUS server is used to authenticate users in general, and local primary server/ backup server as a valid pair of servers from the same local unit. The AAA server also manages access to the plurality of local primary servers, by internal and/or external processing devices. The central system 40 also includes a Peer-to-Peer (P2P) server 450 and related applications, to manage connections between local primary and backup server. The P2P server manages and authorizes a secured P2P communication channel to be temporarily created between the local primary server and the backup primary server, to perform data synchronization/backup from the primary to the backup server, using SSH and/or SSL communication channels. The server 450 may also include a Session Transversal Utilities for NAT (Network Address Translator) STUN/ Traversal Using Relay (TURN) server component, that allows establishing a connection between the local primary server and its paired local backup server, when the P2P connection cannot be established. In such cases, the communication between the two paired servers transits via server 450.

[0043] The central system also preferably includes a Broker/HTTPS termination server 430 and related applications, to decrypt incoming data from the different local servers and prepare/send the data to the other servers/applications of the central system. The central system also preferably includes a DNS server 440, that contains a database of public IP addresses and hostnames, to translate hostnames in IP addresses. The central system 40 may also include an Admin server 410, which functions is to manage data exchanges between the different servers/applications of the central system. Of course, the central system may include additional components, such as routers and/or switches (collocated or not).
The different servers of the central system can be physical servers and/or virtual servers.

[0044] The system 10 is therefore "decentralized" in that the local units are dispersed on premises of the different clients using the system, and is "automated"
in that most of the monitoring, maintenance and access for data sharing is managed automatically by software robots run by the servers of the central system, without requiring, for most operations, skilled technicians at the central system to log in to the local servers, for installing updates, adding new users, and/or providing access to specific shared drives. A custom application runs on the local servers, and allows end-users, with limited or no experience in IT, to authorize or request server-related tasks (such as software updates, installation of new applications, user and/or shared drive management, etc.). Local and external processing devices can use installed Wizard application and/or mobile/web-based Wizard applications, from their devices, to view and/or manage server operations, as well as user access and file sharing. For example, Figure 12A shows a screenshot of a table or log file summarizing the different surveillance, maintenance, updates and backup performed on a local primary server, and initiated by the central system. Figure 12B shows a table or log file of the backup process performed for a given local unit. Figure 12C is a screenshot of a window allowing an authorized user, having a custom/local unit management application (or "wizard app") installed on his computing device, to provide access to primary servers, virtual machines as well as folders and drives/shares. Figure 12D is a message window allowing an authorized user (typically a server administrator) to switchover roles of the primary to the backup server, by a simple confirmation/click button.

[0045] In addition, according to a preferred implementation of the system and process, in order to increase secure access of the files and applications residing on the backup server, the local primary server and the local backup server cannot communicate with each other unless authorized by the central system. That is, it is not possible for an authorized user of the local primary server to log in and/or request a backup of the files/applications from the primary server to the backup server, unless the primary and backup servers are first authenticated as an authorized pair by the central system 40. More preferably, the local primary server and the local backup server are not part of the same Local Area Network (LAN) and cannot communicate with each other unless authorized by the central system.

[0046] Figure 5 schematically illustrates the flow of communications between external processing device 60 or 60' and a local primary server 100 of a given local unit. External processing device has a local unit/wizard application installed thereon, while the mobile phone 60' has a mobile app wizard application. The connection process begins with the obtention of the public IP address of devices (local or external), in order for the central system to geographically position the device. If the user is away from the office, then the device is considered to be an external processing device, and the central system will instruct the device, via the custom application, to connect to the local primary server via a VPN
connection.
The connection between the local primary server 100 and the central system is made via a VPN connection that typically remains active, and the connection between the processing device 60 or 60' will depend on the type of device, and more specifically on the application used for the connection request. In case of a tablet, PC, laptop or other similar device, connection parameters, including the local primary server ID, public IP, VPN IP and LAN IP, are retrieved by the central system, which returns the parameters via a crypted channel, provided the user/device has previously been authenticated as a valid user of the system.
For authentication purposes, the unique identifier, password, MAC address and a Secure Socket Layer (SSL) certificate are provided. Routers 482 of the central system directs the request to the AAA server 460 (such as a RADIUS server), to authenticate credentials of external processing device 60. If the parameters/credential of the processing device are found in the server's registry of authorized users/devices, the processing device 60 can initiate a VPN
connection to the central system, using the connection parameters received from the central system.

[0047] In the case of a mobile device 60', the connection is made via the Broker/HTTPS server 430, and the mobile device communicates with the local primary server via a SSL tunnel for a portion of the route. The device 60 or 60' will then have access to the shares (i.e. shared drives) of the local primary server and will be able to map the different connection drives. It is also possible for a local computer device, upon being identified as an authorized device of one of the local units, to provide access to shared drives of the local primary server, via the central system 40, to external processing devices 60 or 60'. The access request is made via the custom/wizard application. Advantageously, authorized users can share drives of the local primary server without requiring an IT technician to be involved in the process, as explained previously with reference to Figure 12C.

[0048] Still referring to Figure 5, in some cases, the central system 40 establishes, when the route determined is a VPN connection, a Secure Shell (SSH) tunnel and/or Secure Socket Layer (SSL) tunnel connection within the VPN connection, based on the IP address of the local or external processing device requesting access one of the local primary servers.

[0049] With reference to Figure 6, automation of the overall connection process is shown. Figure 6 also shows how the central system 40 manages access to the primary server(s) for both local processing devices 50 part of the same local area network (LAN), and for external processing devices 60 which are not connected to the LAN; and how a local processing device 50 can access local primary servers on different LANs. The central system can determine, based on a public IP
address of the local or external processing devices 50, 60, routes that the local or external processing device(s) must use to communicate with the local primary server, the route(s) including one of: LAN connection(s); hybrid LAN/VPN connection(s);
proprietary VPN connection(s); private VPN connection(s); and P2P
connection(s).

[0050] More specifically, an external processing device 60 first logs in to a custom-application (also referred to as a "wizard" app or "mobile app", depending on the type of device), to connect to the Administrator (Admin) server 410 of the central system 40, requesting its public IP address from the Admin server 410. The Admin server, via the AAA server, identifies/authenticates the external processing device 60 as an authorized user/device of the system. Then, the communications with the local primary server will be established as previously described in Figure 5, using REST though HTTPs protocol for mobile devices, and REST through VPN for processing device provided with the local unit management/wizard application.
When the device is a "local" processing device 50, i.e. a device connected to the same LAN as the primary server, the user must also first login via the custom-application (or "wizard" app) installed on his device and request its public IP to the central system. In response, after the AAA server has determined the location of the device (within the same LAN than the primary server, external LAN or mobile connection), the Admin servers provides to the internal processing device the public IP address of the local primary server; and parameters of the local primary servers to which the local processing device 50 can access. Depending on the access level of the user/type of device, the VPN and LAN IPs will be returned to device 50 by the Admin server 410. Using these parameters (local primary server host name, public IP, VPN IP and LAN IP), the local processing device 50 can communicate directly with the local primary server 100, via the LAN network.
In cases where the local processing device 50 requires access to local primary servers 100' (from LAN B) or 100"_(from LAN C), from different local units, VPN
connections are established between the primary servers B and C, and processing devices 50.

[0051] Referring to Figure 7, a possible implementation of a local unit, for a given client, is provided. In this case, the local primary server 100 is located on a premise of the company, such in their main headquarters for example, and the local backup server 200 is in another premise, remote from the first one. The local primary server 100 is not provided with any system-specific routing and/or networking functions, such that the central system 40 handles all communications between the external processing devices 60, 60' and the local primary server 100. In such case, a VPN connection is established and maintained between the local primary server and servers of the central system and communications from the external processing devices 60, 60' are made using REST HTTPS protocol and/or proprietary or private VPN connections.

[0052] Another possible implementation of a local unit is shown in Figure 8, wherein the local primary server 100 is coupled to a router 150, programmed and configured to manage access to/from external processing device 60'. In this case, the user access and rights database in maintained in the local primary server, and traffic can flow straight from the local primary server to the remote users, via router 150, without transiting through servers of the central system. In this implementation, mobile external processing device 60 can still access the local primary server without going through router 150, using SSL connections via the Broker/HTTPS termination server. However, laptops, tablets and desktop devices 60' can access the local primary server 100 via router 150, by establishing VPN
connections via router 150.

[0053] Referring now to Figure 9A, the different software modules installed on the local primary server 100 and on its paired backup server are schematically illustrated. The first module 102 is a "web service" module whose function is to interact with mobile/web-based applications for accessing servers of the system 10. The web service module 102 in turn communicates with the "communication module" 106, whose function is to interact with different devices, including not only mobile devices, but also local and external processing devices. The communication module 106 has direct access to the different files stored on the primary server, via the "local file system and logical volume manager" (i.e.
ZFS) 108, which allows bypassing, when possible, legacy file server applications (such as NTFS or SAMBA). The "local file system and logical volume manager module"
108 controls location, storage and retrieval of data in the memory of the primary server 100, and provides improved performances over existing technologies such as NTFS or SAMBA, since it avoids unnecessary/overhead processes such as log and status reporting. Accesses to the files are synchronized and managed by the "synchronisation module" (nuusync) 104. Given that the backup server is typically not accessed directly by end users, the web service layer 102 can be optional and/or latent on the backup server 200. As illustrated by the arrow SSH
(LAN) /
P2P transport , communications between the local primary server 100 and the backup server 200 are made between the "local system and logical volume manager" modules of both servers, via a P2P connection if possible, and otherwise via a SSH or SSL connection (via the STUN/TURN server), if the P2P connection is cannot be established.

[0054] Referring to Figure 9B, the backup process from the local primary server 100 to the local backup server 200 will be explained in more detail. The two servers 100 and 200 are preferably both programmed to send backup requests to the central system, at the same time, preferably each day. The backup requests, similar to any other communication requests, include identification information of the local primary server or of the local backup server, i.e.: a unique identifier, a password, a MAC address and a Secure Socket Layer (SSL) certificate. When receiving a backup request from one of the servers of a pair, the central system waits until receiving the second backup request from the other server of the pair.

When both requests have been received, the central system, via the AAA server, automatically verifies whether the local primary and backup servers form a registered pair, based on the information (hostname, IP address, MAC address, SSL certificate) in the registry of the AAA database, and if so, sends instructions to both servers for them to establish a Peer to Peer (P2P) connection. More specifically, the P2P connection is initiated by the backup server, and terminated by the backup server once the backup process(es) has been successfully completed. If the P2P connection fails and/or cannot be established, the central server is used as a relay between the two servers, by establishing a secure relay connection, via the STUN/TURN server. Once the backup process is completed, the two servers (primary and backup) are isolated once again from one another, until the next scheduled backup.

[0055] On the end of the central system, a software robot, continuously receives the operational data from the local primary servers and from the backup primary servers of the plurality of local unit. The operational data sent by the local primary and backup servers is orchestrated by the "scheduler" sub-module, which is part of the "synchronization" module 104. The software robot of the central system analyses the operational data received from the plurality of servers from the different local units, and automatically triggers updates, maintenance operations or installation processes, depending on whether the operational data meet predetermined criteria. For example, if a new version of the OS running on one of the local primary servers is available, and the OS needs to be updated, the software robot automatically sends a message (such as an email, a SMS, etc.) to an authorized administrator of the server, to request confirmation that the update can be performed. The confirmation request needs to be accepted for the update, maintenance and/or installation process to be executed. Once the confirmation is acknowledge/authorized, the central system automatically executes the required operation (update, installation, maintenance, etc.) on the local primary server, without requiring any human intervention, not at the central system's end, and not at the local primary server's end.

[0056] In addition, in case of failure of the local primary server, the local backup server can take over functions of the local primary server, upon receiving instructions from an authorized user, that logs in to the local backup server and requests a changeover, via a simple process, as illustrated in Figure 120.

[0057] Referring now to Figure 10, the connection sequence of an external processing device to a local primary server 100 is illustrated. The device 60 logs in to the wizard application and requests access to the local primary server 100.
The DNS server 440 at the central system returns the public IP address of the device.
Given that the processing device is a mobile device, it must connect to the Broker/HTTPS termination server. The device 60 then sends its identification, password, and access token (such as a JSON Web Token) to the Broker/HTTPS
termination server 430. The Broker server 430 communicates with the Authentication database 474 to confirm credentials of the user/device. If successfully authenticated, the internal DNS server 440b will send the Broker/HTTPS termination server 430 the private IP address of the local primary server, in order for the Broker server 430 to establish an HTTP/REST
connection with the local primary server, to allow communications from the external processing device 60 to transit through this secured route.

[0058] Now referring to Figure 11, a flow chart of the steps performed by servers and APIs at the central system to configure a private router to increase speed and security of the communications with a local primary server. The router is preferably from a selected manufacturer. The flow chart illustrates the different steps conducted on the different servers of the central system to be able to manage the different connection scenarios, and automatically configure a router associated to a local primary server, without requiring any manual configuration from a skilled IT
technician.

[0059] The initial step is for a user of a given processing device (local or external), to login the custom/wizard application of the system. The Admin server 410 at the central system verifies whether the device 50 or 60 is in local mode access or not, and if the client (device) is allowed to connect to the local primary server outside of the LAN of the server. If the clients IP address is associated to a LAN IP
address of a local primary server, the device is considered a "local processing device"
and can access the local primary server. If not, routing is established as explained with reference to Figure 10. If the processing device 50 is on the same network as the local primary server, then a verification is made as to whether or not the backup server of the client/local unit has a hybrid LANNPN. If the backup server cannot be accessed via a hybrid LANNPN connection, then a verification is made as if the client/local unit's router is managed by the central system or not. If yes, then communications between the processing device and the local primary server are made using the central system's proprietary VPN connection. If the client/local unit has its own private VPN, the Adm in server 410 obtains information on the local primary server, connects to the primary server to obtain parameters of the client's router, configures the private VPN, disconnects the proprietary VPN and uses the private VPN connection to connect the processing device to the local primary server. As can be appreciated, the routing configuration, whether via an existing router or a proprietary router 150, is transparent to the end user and does not require any technician or human intervention.

[0060] As can be appreciated, the data storage, processing and sharing system comprises one or more pairs of local primary server and local backup servers (part of local unit) in communication with a central system 40, which remotely manages the local servers. Hence, the local units are in data communication with the central system and cooperates therewith, whereby the proprietary data storage and processing is decentralized form the central system. The architecture and components of the system advantageously offer clients control over the storage of their proprietary data (control over the location where the proprietary data is stored) and high-performance (i.e. efficiency and responsiveness), resulting from the local storage/processing of the data. The system provides hyperconvergence and automation of the redundancy of proprietary data, as well as automated remote management, maintenance and monitoring (without access to the proprietary data by the central unit of the system).

[0061] Advantageously, the central system also manages data communication between remote processing devices (such as desktop computers, laptop computers, electronic tablets, smartphones or the like) and the primary local servers. Such management is performed using user authentication and secure protocols (e.g. VPN and HTTPS). The central system also manages remote access to local primary servers of distinct local units.
[0064] Several alternative embodiments and examples have been described and illustrated herein. The embodiments of the invention described above are intended to be exemplary only. A person of ordinary skill in the art would appreciate the features of the individual embodiments, and the possible combinations and variations of the components. A person of ordinary skill in the art would further appreciate that any of the embodiments could be provided in any combination with the other embodiments disclosed herein. It is understood that the invention could be embodied in other specific forms without departing from the central characteristics thereof. The present examples and embodiments, therefore, are to be considered in all respects as illustrative and not restrictive, and the invention is not to be limited to the details given herein. Accordingly, while the specific embodiments have been illustrated and described, numerous modifications come to mind. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.

Claims

CLAIMS:

1. A computer-implemented process performed in a decentralized and automated data storage, processing and sharing system, wherein:
the system comprises a plurality of local units, each associated to a given client and comprising a local primary server located on premise of said given client; a local backup server remotely located on a different premise, paired to the local primary server, and a central system remotely located from the plurality of local units;
the primary local server storing proprietary files and operational data relating to the configuration and operation of the primary local server; and running an operating system (OS); server-related applications, and client-specific applications;
the local backup server backing up the proprietary files and/or the client-specific applications and the operational data of the local primary server;
and the central system periodically receiving, for each of the local units, the operational data from the local primary server and from the local backup server, and automatically performing at least one of remote management; maintenance;
and surveillance of the local units, based on the operational data received, without storing or accessing the proprietary files on the local primary servers and on the local backup servers.

2. The computer-implemented process according to claim 1, wherein for any given one of the local units, the local primary server and the local backup server cannot communicate with each other unless authorized by the central system.

3. The computer-implemented process according to claim 1 or 2, wherein the central system authorizes, for the plurality of local units, the backing up process from the local primary server to the local backup server, the local primary server and the local backup server both sending respective communication requests to the central system, and upon the central system receiving the respective communication requests, the central system authenticates the local primary server and the local backup server as a valid pair of servers from the same local unit and allows a secured communication channel to be established between the local primary server and the backup primary server to perform data synchronization therebetween.

4. The computer-implemented process according to any one of claims 1 to 3, wherein the communication requests includes identification information of the local primary server or of the local backup server, said identification information including: a unique identifier, a password, a MAC address and a Secure Socket Layer (SSL) certificate.

5. The computer-implemented process according to any one of claims 1 to 4, wherein, once authorized by the central system, the local primary server and the local backup server communicate with one another via a Peer to Peer (P2P) connection or a secure relay connection.

6. The computer-implemented process according to any one of claims 1 to 5, wherein the central system manages access to the primary server for local processing devices part of the same local area network (LAN), and for external processing devices not connected to the LAN.

7. The computer-implemented process according to claim 6, wherein the central system determines, based on a public IP address of the local or external processing devices, the route said local or external processing device must use to communicate with the local primary server, said route including one of: a LAN
connection; an hybrid LANNPN connection; a proprietary VPN connection; a private VPN connection; and a P2P connection.

8. The computer-implemented process according to claim 6 or 7, wherein the central system performs routing functions for at least some of the local primary servers that are not provided with networking functions, the central system also remotely managing firewall access of said primary local servers for connecting local and/or remote processing devices to the local primary server.

9. The computer-implemented process according to any one of claims 6 to 8, wherein the central system establishes, when the route determined is a VPN
connection, a Secure Shell (SSH) tunnel and/or Secure Socket Layer (SSL) tunnel connection within the VPN connection, based on an IP address of the local or external processing device requesting access one of the local primary servers.

10. The computer-implemented process according to any one of claims 1 to 9, wherein the central system comprises a software robot that continuously receives the operational data from the local primary servers and from the backup primary servers of the plurality of local units, the software robot analyses said operational data and automatically triggers one of: an update, a maintenance or an installation process in some of the local primary servers and/ or local backup servers, depending on whether the operational data meet predetermined criteria.

11. The computer-implemented process according to claim 10, wherein said update, maintenance or installation process must first be authorized by said local primary server and/or local backup server.

12. The computer-implemented process according to claim 10 or 11, wherein the central system automatically sends a message to an authorized user of the local primary server and/or local backup server, including a confirmation request that needs to be accepted for the update, maintenance and/or installation process to be executed.

13. The computer-implemented process according to any one of claims 1 to 12, wherein a local computer device, upon being identified as authorized devices of one of the local units, provides access to shared drives of the local primary server of said local unit, via the central system, to external processing devices.

14. The computer-implemented process according to any one of claims 1 to 13, wherein in case of failure of the local primary server, the local backup server takes over functions of the local primary server, upon receiving instruction from an authorized user login in to the local back server and requesting a changeover.

15. A decentralized and automated data storage, processing and sharing system, comprising:
a plurality of local units, each associated to a given client and comprising:
a local primary server located on premise of said given client;
the primary local server comprising:
computer-readable memory storing: proprietary files; client-specific applications, operational data relating to the configuration and operation of the primary local server; an operating system (OS) and server-related applications; and one or more processors for executing the operating system, client-specific applications and server-related applications; and a local backup server remotely located on a different premise, the local backup server comprising computer-readable memory and processor(s) for backing up the proprietary files and/or the client-specific applications and the functional data of the local primary server; and a central system remotely located from the plurality of local units; the central system comprising one or more central servers and a software robot that periodically analyses, for each local unit, the operational data sent from the local primary server and from the local backup server for the plurality of local units, and automatically performs at least one of remote management; maintenance; and surveillance of the local units, based on the operational data, without storing or accessing the proprietary data on the local primary servers and on the local backup servers.

16. The decentralized and automated data storage and sharing system according to claim 15, wherein for any given one of the local units, the local primary server and the local backup server are not part of the same LAN and cannot communicate with each other unless authorized by the central system.

17. The decentralized and automated data storage and sharing system according to claim 15 or 16, wherein at least some of the local units comprises additional local primary units and/or additional local backup servers.

18. The decentralized and automated data storage and sharing system according to any one of claim 15 to 17, wherein the central system comprises a VPN server, an Authentication, Authorization and Accounting server and a P2P
server, the VPN server managing secure VPN connections between the local primary server and the central system, and between the local backup server and the central system, for receiving communication requests from the primary and backup servers, the AAA server authenticating the local primary server and the local backup server as a valid pair of servers from the same local unit and the P2P
server opening a secured P2P communication channel between the local primary server and the backup primary server to perform data synchronization therebetween.

19. The decentralized and automated data storage and sharing system according to claim 18, wherein the AAA server is a Remote Authentication Dial-In User Service (RADIUS) server, which authenticates the local primary server or of the local backup server based on identification information sent by the primary and backup servers, the identification information including: a unique identifier, a password, a MAC address and an Secure Socket Layer (SSL) certificate.

20. The decentralized and automated data storage and sharing system according to claim 19, wherein if a P2P connection cannot be established between the local primary server and the local backup server, the RADIUS server validates security credentials of the local primary server and of the local backup server, and the P2P server establishes a STUN/TURN connection via the central P2P server, such that backup data from the local primary server transits through the central system and then to the local backup server.

21. The computer-implemented process according to any one of claims 15 to 20, wherein the central system manages access to the primary server for local processing devices part of the same local area network (LAN) and for external processing devices not connected to the LAN.

22. The computer-implemented process according to any one of claims 15 to 21, wherein the AAA server determines, based on a public IP address of local or external processing devices, the route said local or external processing device are allowed to use to connect to the primary server, said route including one of :
a LAN
connection; an hybrid LANNPN connection; a proprietary VPN connection; a private VPN connection; and a P2P connection.