SECURE DATA SYNCHRONIZATION BETWEEN OFFLINE AND ONLINE SYSTEMS

Abstract

Maintaining transaction security in a distributed system and the distributed system. The distributed system comprises an online system, an offline system, and a removable storage device. The online system comprises online sub-systems in communication via a communications network, each storing an online ledger. The offline system is unconnected to the network and the online system and comprises an offline sub-system storing an offline ledger. The removable storage device stores a copy of the online ledger. In operation, the copy of the online ledger is accessed when the device is connected to the offline sub-system; upon determining that the copy of the online ledger and the offline ledger are versions of the same ledger the offline ledger is updated with reference to the online ledger thereby achieving synchronisation between the offline ledger and the online ledger.

Claims

1. A method for maintaining transaction security in a distributed system, wherein the distributed system comprises an online system, an offline system, and a removable storage device, the online system comprising at least three online sub-systems in communication via a communications network, and that each stores an online ledger comprising cryptographically-linked entries indicating earlier data transactions, the offline system comprising an offline sub-system and being unconnected to the network and the online system, the offline sub-system storing an offline ledger that is a full or partial copy of the online ledger, and the removable storage device having a data store configured to store a copy of the online ledger and to interface with at least one online sub-system and with the offline sub-system independently, the method comprising: accessing, at the offline sub-system, the copy of the online ledger stored by the removable storage device when the device is connected to the offline sub-system and unconnected to the network and the online system; determining that the copy of the online ledger stored by the removable storage device and the offline ledger are versions of the same ledger; and in response to determining that the copy of the online ledger and the offline ledger are versions of the same ledger: updating the offline ledger with reference to the online ledger thereby achieving synchronization between the offline ledger and the online ledger.

2. The method of claim 1, comprising terminating interaction with the removable storage device if it is determined that the copy of the online ledger and the offline ledger are not versions of the same ledger.

3. The method of claim 1, comprising authorizing the user, and permitting data operations to be performed by the authorized user only when synchronization is achieved between the offline and online ledger.

4. The method of claim 3, wherein authorizing the user comprises: determining a user identity credential; and comparing the identity credential of the user with predetermined authorization data, wherein the user is an authorized user if the identity credential matches the authorization data.

5. The method of claim 4, wherein the offline ledger comprises the authorization data.

6. The method of claim 1, comprising: checking that a most recent data transaction in the copy of the online ledger is a valid transaction for synchronizing the ledger with the offline sub-system, and in response: performing the step of determining that the copy of the online ledger stored by the removable storage device and the offline ledger are versions of the same ledger.

7. The method of claim 6, comprising: if the most recent data transaction is not a valid transaction for synchronizing the ledger, terminating interaction with the removable storage device; and creating a data record that is separate from the offline ledger indicating the identity of the removable storage device and/or user.

8. The method of claim 1, comprising: generating, by the offline sub-system, a data record that is separate from the ledger in the removable storage device to indicate the synchronization was successful; converting the record to a transaction in the online ledger when the removable storage device is connected to one of the online sub-systems; and validating the transaction at two other online sub-systems at least.

9. The method of claim 1, comprising, at one of the online sub-systems: performing one or more transactions in response to a request from the user; propagating the performed transaction to and receive validation of the transaction from at least the two other online sub-systems via the communications network; and storing the transaction as an entry or part of an entry of the online ledger in response to receiving the validations.

10. A system for maintaining transaction security between online and offline sub-systems, the system comprising: an online system comprising three online sub-systems in communication via a communications network, and that each stores an online ledger comprising cryptographically-linked entries indicating earlier data transactions; an offline system comprising an offline sub-system and being unconnected to the network and the online system, the offline sub-system storing an offline ledger that is a full or partial copy of the online ledger; and a removable storage device having a data store configured to store a copy of the online ledger and configured to interface with at least one online sub-system and the offline sub-system independently, and, and wherein the system is configured to perform an operation, comprising: accessing, at the offline sub-system, the copy of the online ledger stored by the removable storage device when the device is connected to the offline sub-system and unconnected to the network and the online system; determining that the copy of the online ledger stored by the removable storage device and the offline ledger are versions of the same ledger; and in response to determining that the copy of the online ledger and the offline ledger are versions of the same ledger; updating the offline ledger with reference to the online ledger thereby achieving synchronization between the offline ledger and the online ledger.

11. The system according to claim 10, wherein each online sub-system comprises: an online sub-system data store storing the online ledger; a user interface for receiving input from a user; a communications module for communication with at least two other online sub-systems via a communications network that each store the online ledger and are configured to validate transactions performed by any online sub-system connected to the network; a device interface for interacting with the removable storage device; and a processor in communication with each of the data store, the user interface, the device interface, and the communications module.

12. The system according to claim 11, wherein the processor is configured to: perform one or more transactions in response to a request from the user; propagate the performed transaction to and receive validation of the transaction from at least the two other online sub-systems via the communications network; and store the transaction as an entry or part of an entry of the online ledger in response to receiving the validations.

13. The system according to claim 10, wherein the offline sub-system comprises: an offline sub-system data store storing the offline ledger; an interface for receiving input from a user; a device interface for interacting with the removable storage device; and a processor configured, at least, to: access the copy of the online ledger stored by the removable storage device when the device is connected to the offline sub-system and unconnected to the network and the online system; determine that the copy of the online ledger stored by the removable storage device and the offline ledger are versions of the same ledger; and in response to determining that the copy of the online ledger and the offline ledger are versions of the same ledger: update the offline ledger with reference to the online ledger thereby achieving synchronization between the offline ledger and the online ledger.

14. The system according to claim 10 comprising a plurality of offline sub-systems and/or a plurality of removable storage devices.

15. The system according to claim 10, wherein the offline sub-system is a wind turbine controller or a power plant controller.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] One or more embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0030] FIG. 1 shows a typical power network architecture according to an embodiment of the invention;

[0031] FIG. 2 shows a system according to an embodiment of the invention;

[0032] FIG. 3 shows an online sub-system of the system of FIG. 2 in more detail;

[0033] FIG. 4 shows an offline sub-system of the system of FIG. 2 in more detail:

[0034] FIG. 5 shows a removable storage device of the system of FIG. 2 in more detail;

[0035] FIG. 6 shows an example data architecture for use in the removable storage device of FIG. 5; and

[0036] FIG. 7 shows a method according to an embodiment of the invention.

DETAILED DESCRIPTION

[0037] To provide setting for the invention, FIG. 1 illustrates a typical architecture in which a wind power plant (WPP) is connected to a main transmission grid as part of a wider power network. As will be understood by the skilled reader, a WPP comprises at least one wind turbine generator (WTG), and is also known as a wind park or a wind farm.

[0038] The example shown is representative only and the skilled reader will appreciate that other specific architectures are possible, in relation to both wind power plants and power plants for other renewable energy sources. Thus, the invention also relates to renewable energy power plants in general, rather than being specific to wind power plants as in the illustrated embodiment.

[0039] The diagram of FIG. 1 should only be taken as a representation of a power network. Alternative configurations of power network and power plants are known and it is expected that other known components may be incorporated in addition to or as alternatives to the components shown and described in FIG. 1. Such changes would be within the capabilities of the skilled person. For example, substations or extra transformers would be expected to be incorporated in the wind power plant depending upon the number of turbines included in the plurality of wind turbines.

[0040] FIG. 1 shows a power network 10 and an online system 30. The power network 10 is considered to be an offline system. An online system generally is a wide-area computer network including at least three online computer terminals or sub-systems connected and capable of communicating a particular type of data via a communications network. In contrast, an offline system is a local network unconnected to the online system comprising one or more offline sub-systems that are generally unconnected to one another, or at least are unable to communicate the same data between themselves. By unconnected, it is meant that there is no direct data connection between the systems such as a wire or wireless network, and data transfer can only be enacted by physical devices that connect to one of the systems at a time.

[0041] The power network 10 incorporates a WPP 12. The WPP 12 includes a plurality of WTGs 14. A single WTG would also be possible. Each of the plurality of WTGs 14 converts wind energy into electrical energy, which is transferred from the WTGs 14 to a main transmission network or main grid 16, as active current, for distribution. A collector network 18 extends between the WPP 12 and the main grid 16.

[0042] The online system 30 includes a central server 32, an independent verifier or verification system 34, and a user terminal 36 connected to one another via a communications network 38. These sub-systems, i.e. the central server 32, independent verifier 34, and user terminal 36, will be referred to as ‘online sub-systems’ hereafter. The roles and configuration of the online sub-systems will be discussed in more detail later. The communications network 38 is a wide area communications network such as the internet and permits the communication of the central server 32, independent verifier 34, user terminal 36, and any other sub-systems connected to the communications network 38. The central server 32 is centralised computer system that stores data relating to authorised users of the online system 30 and power network 10. The central server 32 enables changes to the data to be made centrally and may be part of more than one online system 30, thereby retaining a plurality of different data sets for a plurality of different online systems 30. The independent verifier 34 is an independent sub-system for providing de-centralization so no overall control of the online system is held by any particular sub-system and that provides verification of information. The independent verifier 34, which is provided as one of the initial set of sub-systems, ensures by its independence that the other initial sub-systems and subsequently added sub-systems can be trusted. The independent verifier 34 is independent by virtue of being operated by a different operator to any of the other sub-systems. The independent verifier 34 may be set by its operator to operate automatically to perform its function or may be operated by the operator. The user terminal 36 is a computer terminal accessible by a user to whom the data relating to authorisation relates.

[0043] Considering the power network 10, each of the WTGs 14 is associated with a respective WTG controller 20. In some embodiments, a set of WTGs may share a single, semi-centralised WTG controller, such that there are fewer WTG controllers than WTGs. WTG controllers 20 can be considered to be computer systems capable of operating a WTG 14 in the manner described herein.

[0044] During operation of the WPP 12, the WTG controllers 20 operate to implement control commands received from a power plant controller (PPC) 22 or operate autonomously to control the WTGs 14. The PPC 22 may also directly control the WTGs 14 or to an aspect of their functionality.

[0045] The PPC 22 is connected to the collector network 18 and is also connected directly to the WPP 12. The role of the PPC 22 is to act as a command and control interface between the WPP 12 and a grid operator or transmission system operator (TSO) 24. The TSO 24 is responsible for indicating or translating the needs and requirements of the main grid 16 to the PPC 22. The PPC 22, in its role as command and control interface, interprets the power delivery demands requested of it by the TSO 24 and manages the WTGs 14 in the WPP 12 in order to satisfy those requirements, whilst taking into account other operative factors such as grid faults and sudden changes in output or measured grid voltage.

[0046] The PPC 22 is a suitable computer system for carrying out the controls and commands as described above. The PPC 22 is equipped to measure a variety of parameters including a representative power output that will be supplied to the main grid 16 by the WPP 12 at a point of intersection between the grid 16 and the collector network 18.

[0047] The PPC 22 communicates control commands to the WTG controllers 20, or directly to the WTGs 14, in a suitable manner. It will be noted that FIG. 1 is a schematic view, so the way in which the control commands are transferred is not depicted explicitly. However, it will be appreciated that suitable cabling may be provided to interconnect the PPC 22 and the WTGs 14 or WTG controllers 20. The interconnections may be direct or ‘point to point’ connections, or may be part of a local area network (LAN) operated under a suitable protocol (CAN-bus or Ethernet for example). Also, it should be appreciated that rather than using cabling, the control commands may be transmitted wirelessly over a suitable wireless network, for example operating under WiFi™ or ZigBee™ standards (IEEE802.11 and 802.15.4 respectively).

[0048] As illustrated in FIG. 1 and as described above, however, the PPC 22 and WTG controllers 20 are unconnected to the wide-area communications network of the ‘online’ system 30 and are isolated from it. The PPC 22 and WTG 20 can therefore be considered to be part of an ‘offline’ system 26, as they are isolated from the communications network that connects the central server 32, independent verifier 34, and user system 36. The PPC 22 and WTG controllers 20 are maintained offline for security purposes, so that the data and information stored therein cannot be accessed remotely and so that they cannot be operated remotely. In effectively keeping the controllers ‘offline’, security of the information therein is maintained and the controllers cannot be subjected to remote network-based attack. Accordingly, the data in the PPC 22 or WTG controller 20 cannot be accessed, unless a user accesses it directly at the PPC 22 or WTG controller 20.

[0049] There is still a need to access the controllers 20, 22 to enable maintenance to be performed and data to be accessed. Therefore, individual users may be authorised to access the PPC 22 and WTG controllers 20. As the PPC 22 and WTG controllers 20 are computer systems, the user may input login credentials that are then verified against a list of authorised users. If the user's login credentials are correct, they are allowed to access the relevant system and make use of the system and data therein. For example, the user may extract data or edit settings relating to how the PPC 22 and/or the WTG controllers 20 are to act in certain situations. It will be appreciated that to permit a user to input login credentials, the PPC 22 and WTG controllers 20 have a user terminal comprising at least input means and a display connected to a processor and data store.

[0050] In the art, a centralised list of users and their authorizations is maintained in a dedicated database. Each time an update is made to the list, a manual update of the list of authorizations in each offline system is also required. This leaves the possibility open that an unauthorised user may access a controller before the update is performed. Furthermore, if the online sub-systems do not update quickly enough, there may be differences in who is allowed to access which systems. There is still also the possibility that all systems of the art may be tampered with.

[0051] In the present invention, the integrity of the data is maintained in the online system 30 and offline system 26 by the provision of a block chain or other ledger comprising cryptographically linked entries. Data is recorded in blocks that are linked cryptographically to one another, and data written to a block must be verified by other sub-systems in order to be accepted as a valid transaction. To link the blocks of the chain together, each block has a cryptographic hash that refers to the previous block number. Each block comprises a block number, a hash, a time stamp, and any associated data, i.e. transactions. A transaction may be the addition, deletion, or amendment of data. Each of the PPC 22, controllers 20, central server 32, independent verifier 34, and user terminal 36 are considered to be sub-systems.

[0052] In the context of FIG. 1, the data in the system is authorisation data, i.e. which users are permitted to access which sub-systems and the credentials they use to access these sub-systems. The authorisation data may also comprise who has accessed which sub-system and when the sub-system was accessed, for example by a timestamp or other metadata. In alternative embodiments, the data may be a different form of data other than authorisation data. For example, the invention is equally applicable to protect the integrity of any kind of data that can be accessed and altered or copied.

[0053] The provision of a block chain ensures that all data is linked to the earlier data, eliminating the possibility that data can be tampered with. As all the data is cryptographically linked and is confirmed by other subsystems as well as reconfirmed each time new blocks are created, the block chain provides for a highly secure data set in the online system 30.

[0054] In combination with the block chain, a link between online and offline systems 30, 26 is provided in the form of a removable storage device 40. The interaction of online and offline sub-systems via the removable storage device 40 and block chain is described below with reference to the system shown in FIG. 2 and the sub-systems of FIGS. 3 to 5. The system shown in FIG. 2 is a generalised version of the system of FIG. 1.

[0055] The system 5 of FIG. 2 comprises an online system 30, an offline system 26, and a removable storage device 40, such as a USB pen drive or a transportable hard drive. The online system 30 comprises a plurality of online sub-systems 42. The offline system 26 comprises a plurality of offline sub-systems 44. The removable storage device 40 is capable of interacting with at least one of the plurality of online sub-systems 42 and at least one of the plurality of offline sub-systems 44. The online and offline sub-systems 42, 44 may be referred to as nodes of the system 5. Although three online sub-systems 42 and three offline sub-systems 44 are shown here, in other embodiments one or more online sub-systems 42 may be provided, and one or more offline sub-systems 44 may be provided. Similarly, although only a single removable storage device 40 is illustrated, a plurality of removable storage devices 40 may be provided. In general, it is envisaged that each user of the system 5 will be provided with a removable storage device 40.

[0056] The removable storage device 40 is provided to ensure that the authorisation data at each offline sub-system 44 are up to date before a user is permitted to access that sub-system 44, so as to maintain the integrity of the data. The removable storage device 40 is configured to interact with at least one of the online sub-systems 42 in order to store a copy of the block chain. The removable storage device 40 is also configured to interact with at least one of the offline sub-systems 44, in order to permit the data in that offline sub-system 44 to be updated so that the block chain is synchronized across the system 5. It is important to note that the removable storage device 40 may only interact with one sub-system 42, 44 at any time, so that the offline system 26 remains offline. In other words, the sub-systems interact or interface with the removable storage device independently.

[0057] Effectively, therefore, the removable storage device 40 acts as a go-between or buffer between systems, linking the offline and online systems 30, 26 without providing a physical connection that would make the offline system 26 online. The removable storage device 40 ferries or transports the important data stored in the block chain from the online system 30 to the offline system 26 to allow the offline system 26 to be intermittently updated. Through this transfer and the use of an untamperable, verifiable ledger, the integrity and security of the data in the entire system 5 is maintained.

[0058] An example online sub-system 42 is illustrated in FIG. 3. The online sub-system 42 comprises a central processor 46 in communication with a data store 48, a user interface 50, a communications module 52, and a device interface 54. The user interface 50 is configured to receive input commands from and communicate output data to a user 51. The communications module 52 is configured for communication with other online sub-systems 42 via the network 38. The device interface 54 is configured for interaction with the removable storage device 40. The processor 46 carries out operations based on user input to the user interface 50, device input to the device interface 54, communications received via the communications module 52, or data or software stored in the data store 48.

[0059] For example, the online sub-system 42 may comprise the user terminal 36. In this embodiment, the user interface 50 may comprise a monitor and input device such as a keyboard and mouse of the terminal 36. The communications module 52 may comprise a wired or wireless internet connection, and the device interface 54 may comprise a USB or HDMI port for receiving a corresponding interface of the removable storage device 40.

[0060] An example offline sub-system 44 is illustrated in FIG. 4. The offline sub-system 44 is the same as the online sub-system 42 with the exception of the communications module 52. The offline sub-system 44 does not require a communications module 52 as it does not need to connect with other offline sub-systems 44 over the communications network 38. Alternatively, the offline sub-system could have identical hardware to an online sub-system 42, but with the communications module 52 rendered inactive. Therefore, it can be seen that online sub-systems 42 can become offline sub-systems 44. The offline sub-system 44 may comprise a means for communicating commands to other offline systems 44 over a local network as described in reference to FIG. 1 above. Therefore, the offline sub-system 44 comprises a central processor 46 in communication with a data store 48, a user interface 50, and a device interface 54. As before, the user interface 50 is configured to receive input commands from and communicate output data to a user, the device interface 54 is configured for interaction with the removable storage device 40, and the processor 46 carries out operations based on user input to the user interface 50, device input to the device interface 54, or data or software stored in the data store 48.

[0061] The processors 46 of the online sub-systems 42 and the offline sub-systems 44 may operate a service that act to allow data to be received and handled in more than one way, acting as the interface between the main operational parts of the sub-systems and the databases that are in use. For example, in online sub-systems 42, the service may operate so as to act either as a proxy. i.e. as an intermediary for data or requests, or to validate transactions and to manipulate data in the data store. Running such a service prevents data storage where it is not necessary, and only permits the transactions that are validated and can be stored in the block chain to be stored. In this way, the service regulates access to the stored data in the block chain to maintain data integrity.

[0062] An example removable storage device 40 is illustrated in FIG. 5. The removable storage device 40 comprises a data store 58 and a device interface 60 for communicating with corresponding device interfaces 54 of the online and offline sub-systems 42, 44. The data in the store 58 of the device 40 is capable of being transferred via the device interface 60. The main purpose of the device interface 60 is to permit the copying of the block chain to the removable storage device 40. The data store 58 is large enough to store the entire block chain. The removable storage device may have an FAT32 file system. It is envisaged that the removable storage device is a USB pen drive, or a transportable hard drive. However, any transferrable and transportable storage device that remains offline when connected to the offline system 44 may form the removable storage device 40.

[0063] An example data architecture 80 for use in the data store 58 in the removable storage device 40 is shown in FIG. 6. The data architecture 80 may also be the structure of a block of the block chain. The removable storage device 40 may comprise a plurality of blocks in the form of the architecture of FIG. 6.

[0064] The architecture 80 comprises a header portion 82, an operations portion 84, and a data portion 86. The header portion 82 is split into two parts 88, 90, the first part 88 recording blocks of the block chain and the second part 90 providing a record of the corresponding hash signatures of the blocks. The header 82 therefore comprises a record of transactions and the blocks for which those transactions form a part. The operations portion 84 indicates what the transaction was, i.e. what data operation was performed in the transaction. The data operation may be updating data, deleting data, or amending data. The data portion 86 of the architecture 80 is what data the operation was performed on and the result.

[0065] The operation of the system 5 and its various sub-systems 42, 44 and removable storage device 40 will now be described with reference to FIGS. 1 to 5.

[0066] Initially, the system 5 comprises a master node and at least two other online nodes. The master node and the two other online nodes are online sub-systems 42 such as those in FIG. 2. All online nodes have a unique key that identifies it as the master node and is used for validating transactions. The key is an alphanumeric string that may act as an address for the node. The key may be based on the Bech32 address format, and is generally 90 characters long at most. The master node, which in FIG. 1 is represented by the central server 32, is the node at which data originates, and where nodes can be assigned. At least one of the online nodes may be a user terminal, and at least one node may be an independent verifier 34, also referred to as a system integrator. An independent verifier 34 is provided as a node to ensure that the system 5 is de-centralized and that no overall control is held by any particular node, thereby further ensuring the integrity of the data in the block chain and the subsequent verification of data. The master node is a validator and enables the implementation of the Proof of Authority consensus algorithm. Any changes to data made at online nodes are validated by the master node. This is particularly useful in identifying systems where data is corrupted because the master node maintains an overview of the data and the changes being made in all connected systems. The master node also maintains a table detailing the statuses of sub-systems, i.e. nodes, within the system, both online and offline. In doing so, the last synchronization of each sub-system can be recorded, further improving data integrity.

[0067] To be considered a node, each other sub-system 42, 44 requires a valid key. The key is assigned by the master node, and is valid once it has been validated by other nodes within the system 5. The assignation of keys by the master node is recorded as a transaction in the block chain.

[0068] At least three entries are therefore provided initially in the block chain, with one entry per online sub-system 42 that has been assigned a key and therefore designated as a node. These entries are stored as transactions in the first block of the block chain. The reference in the hash of the first block to the previous block is a null field.

[0069] For online sub-systems 42, assigning a key to a node is performed via the communications network 38 that links the online sub-systems 42. For offline sub-systems 44, each sub-system 44 is assigned a key by the master node that is validated by the online nodes 42. This key, once valid, can be exported to the offline sub-system 42 using a storage device. The storage device may be the removable storage device 40. Thus, to be a node, the offline sub-system 42 has to initially interact with a storage device to receive its validated key and the transactions of the block chain prior to its key.

[0070] In general, therefore, the creation of an online node is performed using the following method: [0071] Assign key for online node at master node; [0072] Create transaction for key assignation in block chain; [0073] Validate key transaction at other online nodes; [0074] Transmit key transaction and existing block chain to online node for storage in data store.

[0075] For offline nodes, the following method is performed: [0076] Assign key for offline node at master node; [0077] Create transaction for key assignation in block chain: [0078] Validate key transaction at online nodes: [0079] Export copy of block chain with key transaction to removable storage device; [0080] Connect removable storage device to offline sub-system; [0081] Transfer copy of block chain and key to offline sub-system data store.

[0082] Once at least one offline node is operational, the removable storage device 40 may be used to enable access to it, or to otherwise permit data operations to be performed on it.

[0083] In general use, separate from the offline system, the online system 30 operates as a conventional online block chain system. Transactions created at online nodes, i.e. user terminals that are online sub-systems, are signed by the online node using a cryptographic, private key. Once signed, the transactions are propagated through the system to other online nodes for validation.

[0084] Propagation through the online system 30 is achieved using the transmission control protocol and by a gossip protocol. A gossip protocol is a protocol that spreads information between adjacent nodes to ensure the fastest receipt of information at a node. Propagation in this way ensures that online nodes receive the transaction as soon as possible. The use of the proxy to pass information on here ensures quick data progression, as well as protecting against data duplication.

[0085] Transactions are stored in blocks of the block chain. Each block is cryptographically linked to the previous entries and to the master node and other nodes. The link is achieved using a hash pointer. New blocks are created whenever there is a new operation or transaction to be done in the system (i.e. insert, update, or delete). Each operation, or set of operations, will be added to a block, along with the data related to that operation. The new block will be linked to the previous operations, in order to keep the change log as much updated as possible.

[0086] In order to maintain the integrity of the data at each offline sub-system 44, the block chain stored in the offline sub-system 44 is updated using the removable storage device 40 to provide synchronization. The offline sub-system 44 will be intermittently updated by a user visiting the sub-system 44 with the removable storage device 40. The synchronization may be performed to synchronize the data, or the synchronization may be a step to permit a data operation to be performed. In other words, the updating of the block chain in an offline node 44 may be performed for the purpose of updating the block chain or to enable another action to be performed so that the action is dependent upon successful synchronization.

[0087] In any case, to synchronize the block chains, the removable storage device 40 stores a copy of the block chain in its most recent form. To do this, the removable storage device 40 interfaces with an online sub-system 42 and copies the block chain to its data store 58 prior to any interaction with an offline sub-system 44. In some embodiments, a transaction may be created to indicate that the block chain is being copied to the removable storage device 40 and that synchronization of an offline sub-system 44 is permitted. The transaction may indicate which storage device 40 (if there is more than one) is copying the block chain and which offline sub-system 44 (if there is more than one) is being synchronized so that the master node can update its table of statuses of the nodes.

[0088] The removable storage device 40 is disconnected from the online node once the copy of the block chain ledger is stored therein, and can be transported to the offline sub-system 44 or node to permit the block chains to be synchronized at least. The removable storage device 40 interface connects to the offline sub-system 44 device interface 54, and the offline sub-system 44 processor 46 operates to update its block chain.

[0089] Initially, the offline sub-system 44 may check that the most recent transaction in the block chain is a valid transaction permitting the offline sub-system 44 to be updated. In this case, if no valid transaction is identified that fulfils this requirement, the offline sub-system 44 may terminate its connection with the removable storage device 40, and prevent any further action by the user. The offline sub-system 44 may also create a record indicating which removable storage device 40 or user did not fulfil the requirement so that at the next valid synchronization, the master node can be made aware of this fault. A valid transaction permitting the offline sub-system to be updated, is a transaction that has been validated by the required number of online sub-systems in the correct way and has not been added or tampered with, and one that indicates that the removeable storage device is allowed to interact with the offline sub-system and to update its ledger if the correct authorizations are found. The valid transaction may be generated by connecting an online sub-system and the removeable storage device, submitting a request to allow interaction between the device and the offline sub-system, granting the request by the online sub-system, validating the request by two other online sub-systems, creating a new entry in the ledger indicating the transacting granting the request, and then disconnection of the device and online sub-system.

[0090] The offline sub-system 44 also checks to ensure that the block chain is the correct block chain, so that the data integrity is maintained throughout the system 5. This is achieved by the offline sub-system 44 by comparing its block chain with the copy on the removable storage device 40. If the part of the block chain in the offline sub-system 44 is replicated exactly in the copy of the block chain, then the offline sub-system 44 can proceed with synchronization because the block chain is the correct block chain, and the data has not been tampered with.

[0091] The processor 46 of the offline sub-system 44 updates its block chain by reading the data from the removable storage device 40 and storing it in its own block chain in the same order. Once synchronization is complete, the block chain in the offline sub-system 44 will match the copy of the block chain in the removable storage device 40, and will match the online block chain up to the point at which the removable storage device 40 copied the block chain.

[0092] The offline sub-system 44 may also perform a comparison of the timestamp of the most recent transaction in the copy of the block chain with the current time, to determine how recently the removable storage device was updated. If the most recent transaction is very old, the offline sub-system 44 may refuse to synchronize or refuse access until a more recent transaction is provided in the block chain. This would reduce the possibility that a user may lose their authorisation shortly after updating their removable storage device but still attempt to gain access using their removable storage device at a later date. The offline sub-system is therefore effectively applying a time-out to the data synchronization.

[0093] The offline sub-system 44 may restrict access to a user, prevent a user from performing certain data operations, or restrict any action being performed by the user at the sub-system until the synchronization is complete.

[0094] For example, in the authorisation system of FIG. 1, the PPC 22, operating as an offline sub-system 44, may prevent all access to any user until it has been synchronized. Once synchronized, the PPC 22 may permit a user to enter user privilege details such as a user ID and password to access the PPC 22. The PPC 22 can subsequently check the user privilege details against the newly updated authorisation block chain to ensure that the (1) the user is permitted to access the system using their user privilege details and (2) the user privilege details entered by the user at the user interface 50 match the most recent version of the user privilege details for that user found in the block chain. If these requirements are fulfilled, the user is permitted access. If not, the user is denied access.

[0095] In some embodiments, the offline sub-system 44 may generate a data record in the removable storage device 40 indicating that the synchronization was successful. When the removable storage device 40 next returns to the online system 30, the data record may be verified by the master node and two other online nodes to create a transaction. The record may also be used to prevent the removable storage device 40 being used to update another offline sub-system 44 where the removable storage device 40 is required to reconnect with the online system 44 before connecting to another offline sub-system 44.

[0096] FIG. 7 represents a general method 700 for the interaction between the removable storage device 40 and the online and offline systems 30, 26, in line with the interaction described above.

[0097] At step 702, a transaction is created at an online sub-system 42 to permit the removable storage device 40 to synchronize an offline sub-system 44.

[0098] At step 704, the transaction is validated by at least two other online sub-systems 42, including the master node.

[0099] At step 706, the removable storage device 40 is connected to the online sub-system 42 and updates its data store 58 to store a copy of the most recent version of the block chain.

[0100] At step 708, the removable storage device 40 is disconnected from the online sub-system 42.

[0101] At step 710, the removable storage device 40 is connected to the offline sub-system 44.

[0102] At step 712, the offline sub-system 44 accesses the copy of the online block chain stored by the removable storage device 40.

[0103] At step 714, the offline sub-system 44 checks the most recent data transaction in the copy of the online block chain in the removable storage device 40. The check is performed to determine that that most recent transaction is a valid transaction for permitting synchronization of the block chain with the offline sub-system 44. If the check does identify that the most recent transaction is valid and permits synchronization, and optionally was made within a predetermined recent time frame, the method progresses to step 716. Otherwise, the process terminates at step 718 and the offline sub-system 44 stops communication with the removable storage device 40.

[0104] At step 716, the offline sub-system 44 determines that the cryptographically-linked entries stored in its partial or full version of the block chain are also present and match the entries in the copy of the block chain stored by the removable storage device 40. In other words, a check is made to see if the copy of the block chain contains an initial n blocks that are an exact replica of the partial block chain stored in the offline sub-system 44. This may be thought of as determining that there is a consensus between the block chains, and/or determining that the copy of the block chain stored by the removable storage device and the block chain in the offline sub-system are versions of the same block chain, the copy of the block chain in the removable storage device being more contemporary. If one or more entries do not match in any way, or if there is an errant additional entry anywhere in or before the blocks of the copy that are meant to match the block chain of the offline system 44, then the process terminates and proceeds to step 718 as there has been a corruption or tampering of the data, or the block chains are not the same and therefore cannot be used to update. If the initial n entries of the copy do match the partial block chain of the offline sub-system 44, step 720 is performed.

[0105] At step 720, the block chain in the offline sub-system 44 is synchronized with the copy in the removable storage device 40. The offline sub-system 44 processor 46 reads the entries in the copy and writes them to the offline sub-systems 44 data store 48, beginning from the oldest transaction that is not already found in the offline sub-system 44 block chain and progressing to the newest transaction so that no data is missed or written out of order.

[0106] At step 722, the user 51 is authorised to perform data operations at the user interface 50 of the offline sub-system 44. The user 51 may be authorised by the offline sub-system 44, by the offline sub-system 44 requesting the user 51 to identify themselves by inputting user privilege details, identifying the user based on those details, and comparing the user's identity with authorisation data. In some embodiments such as in the authorisation system of FIG. 1, the authorisation data is part of the block chain. If the user 51 is permitted to access the system 44, the method progresses to step 724, where the user 51 is permitted to perform data operations. Otherwise, step 722 may repeat, or the process may be terminated.

[0107] Once data operations have been performed, the removable storage device 40 is removed at step 726 and the process terminates.

[0108] Although not illustrated here, the method may also comprise creating, by the offline sub-system 44, a data record that is separate from the block chain in the removable storage device 40 to indicate the synchronization was successful, converting the record to a transaction in the online block chain when the removable storage device 40 is connected to one of the online sub-systems 42; and validating the transaction at at least two other online sub-systems 42.

[0109] It will be appreciated that various changes and modifications can be made to the present invention without departing from the scope of the present application.