WO2019144400A1 - A system and a method for use in data exchange - Google Patents

A system and a method for use in data exchange Download PDF

Info

Publication number
WO2019144400A1
WO2019144400A1 PCT/CN2018/074445 CN2018074445W WO2019144400A1 WO 2019144400 A1 WO2019144400 A1 WO 2019144400A1 CN 2018074445 W CN2018074445 W CN 2018074445W WO 2019144400 A1 WO2019144400 A1 WO 2019144400A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
data exchange
terminal system
server
template
Prior art date
Application number
PCT/CN2018/074445
Other languages
French (fr)
Inventor
Alan COWARD
Original Assignee
Waysun Technology Development Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Waysun Technology Development Limited filed Critical Waysun Technology Development Limited
Priority to PCT/CN2018/074445 priority Critical patent/WO2019144400A1/en
Publication of WO2019144400A1 publication Critical patent/WO2019144400A1/en

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/22Payment schemes or models
    • G06Q20/223Payment schemes or models based on the use of peer-to-peer networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/06Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]

Definitions

  • the invention relates to a data exchange system, and in particular, a system, a device, and a method for use in data exchange using Blockchain.
  • Blockchain may be used as a peer-to-peer distributed ledger of transactions updated through the consensus of the peer nodes. It is at the application layer of the OSI model.
  • a Blockchain comprises a series of block linked together in chronological order.
  • the structure of a block generally comprises a block header, links to previous blocks, the time stamp, nonce, data counter, data, and other attributes.
  • the size of a block is variable depending on the type and design.
  • a link or reference to a previous block is also included in the block unless it's a first or genesis block.
  • a genesis block was typically crafted at the time the Blockchain was started.
  • Blockchain technology can provide a platform which automates auditing and makes an application transparent yet secure. It is adapted to provide data integrity, immutability, and high availability services.
  • the present invention relates to a data exchange system and method, particularly to a system, device, or method of data exchange using Blockchain.
  • the present invention may also overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.
  • a data exchange server for receiving authenticated data
  • a sender terminal system for sending authenticated data to the data exchange system
  • a recipient terminal system for receiving the data from the data exchange server
  • sender terminal system submits the data template for Blockchain record
  • the recipient terminal system receives the data template, and downloads the data file from the data exchange;
  • the sender terminal system is adapted to provide an interface for generating the data template for the recipient terminal system.
  • the sender terminal system is adapted to provide a web interface to upload data to the data into a selected data template and any associated documents.
  • the sender terminal system is adapted to automatically invoke an application programming interface to send data into a selected data template and any associated documents.
  • the sender terminal system is adapted to generate a hash digest with the data.
  • the sender terminal system is adapted to generate a hash digest with the data at individual line item level.
  • the sender terminal system is adapted to generate a hash digest for any associated documents.
  • sender terminal system is adapted to submit the hash digest to a private Blockchain process.
  • the sender terminal system is adapted to send the data, any documents and the hash digest to the exchange.
  • the sender terminal system is adapted to send the hash digest and a notification to the recipient terminal system
  • the recipient terminal system is adapted to receive and alter the data template for rendering the data for display.
  • the sender terminal system is adapted to receive a confirmation notice of the successful transmission of data and data template.
  • the recipient terminal system is adapted to download the data from the data exchange server through a web interface.
  • the recipient terminal system is adapted to fetch the data through an application programming interface.
  • the recipient terminal system is adapted to verify the hash digest of the data.
  • the sender terminal system is adapted to perform an instant audit that the data has been received as transmitted.
  • the recipient terminal system is adapted to send all or part of the data to another recipient terminal system using the hash digest in recorded in the private Blockchain process.
  • the sender terminal system or the recipient terminal system is adapted to provide a BlockTree function, wherein the BlockTree function is adapted to provide both sender terminal system and recipient terminal system with visual representation of an end to end transmission of the data along with an identifier of each recipient terminal of the data.
  • the data exchange server is adapted to manage a network for private Blockchain processes and operational status of participants in the network.
  • the data exchange server is adapted to receive the data along with a hash digest of the data sent from the sender terminal system.
  • the data exchange server is adapted to submit the hash digest into a public Blockchain process.
  • the data exchange server is adapted to identify the recipient terminal system who is permitted receive the data and documents and provide access thereof.
  • the data exchange server is adapted to manage access permissions such as time delays of the recipient terminal system, or time delays of public access of the data.
  • the data exchange server is adapted to manage download protocols to recipient terminal system.
  • the data exchange server is adapted to maintain backup of the data and the corresponding data template.
  • the data template comprises a hash digest of the data.
  • the data template comprises instructions code for manipulating the data.
  • the data template comprises identifiers of the data.
  • a recipient terminal system receives the data template, and downloads the data file from the data exchange;
  • a electron server for data exchange comprising:
  • a network module for receiving authenticated data from a sender terminal system, and a data template for Blockchain record
  • a central processing unit for receiving request from a recipient terminal system for downloading the data and data template
  • a logic processing unit for performing Blockchain process in recording the data template
  • the recipient may render the data for use with the data template.
  • Fig. 1 is a schematic diagram showing a data exchange system in accordance to an embodiment of the present invention
  • Fig. 2 is a schematic diagram showing an extended data exchange system of Fig. 1;
  • Fig. 3 is a schematic diagram showing an architecture of a data exchange server of the data exchange system of Fig. 1;
  • Fig. 4 is a schematic diagram of a process of a terminal system of the data exchange system of Fig. 1;
  • Fig. 5 is a schematic diagram of a process of a data exchange server of the data exchange system of Fig. 1;
  • Fig. 6 is a schematic diagram of a process of the data exchange system of Fig. 1.
  • the inventors have, through their own research, trials and experiments, devised that a data exchange platform can facilitate the exchange and distribution of structured data and associated documents between known participants using a combination of standard and Blockchain technologies.
  • a data exchange system may be used for offline data exchange associated with a Blockchain.
  • the method comprising the steps of storing, in a memory of an integrated circuit card, a structured data set associated with a Blockchain network, wherein the structured data set includes at least a network identifier, an unspent output hash, an output index, an output value, and a key pair.
  • the system may carry out the step of receiving, by a receiving device of the integrated circuit card, at least the network identifier and a transaction amount from an electronic point of sale device; and validating, by a validation module of the integrated circuit card, the stored structured data set as including the network identifier and an output value greater than or equal to the received transaction amount.
  • the system then electronically transmits, by a transmitting device of the integrated circuit card, at least the unspent output hash and the output index to the electronic point of sale device; and receives, by the receiving device of the integrated circuit card, at least a destination address from the electronic point of sale device; such that it can generates, by a generation module of the integrated circuit card, transaction data, wherein the transaction data includes at least the received destination address and a payment amount based on at least the transaction amount; and electronically transmits, by the transmitting device of the integrated circuit card, the transaction data to the electronic point of sale device.
  • a method comprising the step of intercepting, by a proxy server over a network, a data request from a first computing device that is directed to a web server; and modifying the data request to include user profile information.
  • the proxy server sends the modified data request to the web server and the information to the web server for controlling a manner for how data sent to the web server is cached in the web server.
  • the proxy server is adapted to receive a response from the web server.
  • the response to the proxy server includes information for controlling a manner for how data received from the web server is cached in the proxy server.
  • the proxy server then catches the data received from the web server in the proxy server; and sends at least a portion of the cached data from the proxy server to the first computing device.
  • the system is incapable of resolving the issues of authenticity, accuracy, trust, accountability, instant auditability, accessibility and priority. It is believed that the platform may only be useful for regular data transactions in environments with agreed data format standards.
  • a computer system may communicate with a distributed Blockchain computing system.
  • the Blockchain computing system includes multiple computing nodes.
  • the data exchange server stores an order book and a plurality of digital wallets associated with different clients.
  • the computer system receives new data transaction requests that are added to the order book.
  • a match is identified between data transaction requests and hashes associated with the digital wallets associated with the respective data transaction requests are generated.
  • the counterparties receive the hashes of the other party along with information on the match and each party causes Blockchain transactions to be added to the Blockchain of the Blockchain computing system.
  • the computing system then monitors the Blockchain to determine if both sides of the match have been added to the Blockchain.
  • the inventors devise that it is more preferable to use the combination of standard and Blockchain technologies to provide a data exchange system or method that is applicable to any situation where accuracy, accountability and auditability are key elements in the management of risk, whether financial/commercial, reputational or regulatory.
  • Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein.
  • an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein.
  • the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.
  • a system 10 comprising a custodian or sender terminal system 22 for sending data to a central server or data exchange server 20, and data template or smart contract to a fund manager or recipient terminal system 24.
  • the central server or data exchange server 20 is adapted to submit the cryptograph mapping of the data file and the cryptographic mapping of the template or smart contract to a Blockchain record.
  • the Blockchain record may be a public Blockchain record or a private Blockchain record.
  • the fund manager or recipient terminal system 24 may then download the data file from the central server or data exchange server 20.
  • the fund manager or recipient terminal system 24 is adapted to verify the data file and the template or smart contract with the Blockchain record.
  • the fund manager or recipient terminal system 24 will render the data file into a displayable format in accordance with the template or smart contract.
  • the system 10 of the present invention provides a data exchange server 20 comprising a central processing unit 33, memory 34 associate with the central processing unit, one or more logic processing unit 35, and a communication module 36.
  • the communication module is adapted to receiving data from one or more local terminal system.
  • the central processing unit is adapted to process general services, such as receiving and handling request, locating data in the memory, sending data to the terminal system.
  • the logic processing unit is adapted to handle authentication process, and Blockchain process.
  • the data exchange server has an array of logical processing unit running parallel to increase the performance of Blockchain functions.
  • the data exchange server 20 is in the form of a software application or data exchange server application running in a dedicate computer server system.
  • the server is a single machine or a network of server module each providing different functionalities.
  • the data exchange server 20 or data exchange server application is designed to be installed on inside institutional firewalls.
  • the server or server application is as a Business to Business (B2B) service.
  • B2B Business to Business
  • the institution may have only a small number of nodes and terminals, the server or server application can also be easily deployed to a hosted service.
  • the data exchange server 20 or server application may comprises a number of modules to provide a variety of services.
  • the server or server application has a web service module to provide a web interface for a terminal system to upload and download data.
  • the web interface may accept data with html and json protocol.
  • the server or server application may also provide application programming interface (API) in the form of remote procedural call (RPC) .
  • API application programming interface
  • the terminal system may directly invoke a service such as uploading and downloading data remotely through the API.
  • One implementation of such API is through the Enterprise Java Bean, DCOM, or . NET platform.
  • the data exchange server 20 or server application is designed to be completely managed by the participant as that ensures the ongoing accountability and reliability of the system and underpins the benefits of Blockchain.
  • the server or the hardware system running the server application is preferably installed with logic processing unit.
  • the server may comprise one or more of specially implemented processor to facilitate the Blockchain function, such as Graphical Processing Units (GPU) , Field-Programmable Gate Array (FPGA) , or Application-Specific Integrated Circuit (ASIC) for handling the Blockchain and authentication functionalities.
  • the logic progressing is typically designed for handling cryptography functions, such as hashing or cryptographic mapping function, private public key /public key processing, encryption and decryption.
  • the ASIC can be designed to handle SHA256, scrypt, or X11 processes.
  • the logic process unit is mainly design to enhance the efficiency in handling the proof of work (PoW) or proof of stake (PoS) process.
  • the server may also include a parallel computing platform and any necessary application programming interface (API) model which may be involve in the Blockchain operations.
  • API application programming interface
  • the logic processing unit is a detachable module simple to enhance the performance of the server or server application. Without the logic processing unit, the server or server application may still able to carry out the Blockchain function with a longer processing time.
  • the Blockchain functions are delegate to a cloud system or service, such as Amazon Web Service.
  • the server or server application is adapted to provide individual accounts for multiple users within the same wallet. This allows for a participant offering services to multiple parties to use the server or server application in a manner that reflects its normal operating processes allowing autonomy and provide Chinese walls between different areas within the same business.
  • a management module 37 may also be included to facilitate other services in relation to the data exchange server 20.
  • the optional management module 37 may include features such as a billing engine, a data source for product/service identifiers and/or an additional database for storing specific information.
  • the management module 37 may be implemented as a component of the data exchange server 20 or it may be provided as an external component or in a separate server arranged to cooperate with the data exchange server 20 during a transaction or an exchange of data using the services provided by the central server.
  • the management module 37 may be deployed based on different requirements or applications.
  • the management module 37 may include a database for storing information relating to price of a product as well as a billing engine.
  • the database may be managed by a financial institution and shared among multiple institutions.
  • the price information may be retrieved by the data exchange server 20, the billing engine may generate the necessary bill (s) for settlement, and subsequently the data exchange server 20 may process the data associated with the product, the price information, and the billing record to record the transaction in the Blockchains.
  • the management module 37 may include a database for storing information for on-boarding clients across multiple systems/companies, which may be accessible by each of these companies and may be useful in the data exchange process.
  • such embodiment may be valuable in a know-your-customer (KYC) environment between financial institutions.
  • KYC know-your-customer
  • different financial institutions may track past transactions recorded in the Blockchain to avoid money-laundering.
  • system 10 comprises three the following elements:
  • the local User server based application is adapted to carry out the following steps:
  • BlockTree This functionality may be referred to as a ‘BlockTree’ which may allow the users to visually inspect all the elements in the Blockchain or the transactions being recorded.
  • the data exchange is adapted to carry out the following steps:
  • the data exchange server 20 or server application is adapted to receive data from terminal system, and parse the received data.
  • the data received from the terminal system 22 is either text (comma separated values or *. csv files) or binary data (e.g. excel files) .
  • the data exchange server 20 or server application is adapted to parse these text or binary data upon uploaded from the terminal system 22 in JavaScript Object Notation (JSON) format to be hashed; data is extracted from the text or binary file, read by the parser and saved to a database in JSON format. This data, individual lines of data and the total message, is then hashed separately in a SHA256 hashing function. Alternatively, electronic data recorded in any hashable format may also be supported by the data exchange system.
  • JSON JavaScript Object Notation
  • the data template is encrypted and can only be read by the target recipient terminal system 24.
  • the text or binary data is rather meaningless to anyone without the template.
  • the data template is compiled as a smart contract comprises codes or rules in parsing or displaying the data.
  • the sender terminal system 22 may provide different data template or smart contract for each recipient terminal system 24 containing different set of codes or rules to parse and display the text or binary data stored in the data exchange server 20. This will allow different recipient terminal system 24 to access the same text or binary data differently.
  • the data exchange server 20 or server application is adapted to receive the upload data authenticated.
  • the sender terminal system 22 is adapted to digitally sign each and every data file upload to the data exchange server 20 or server application.
  • the data file is hashed with a certificate of authenticity before uploading to the data exchange server.
  • all the terminal systems 22, 24 have to be approved by the data exchange server 20 or server application before participating in any activities with the data exchange server 20.
  • the data exchange server 20 or server application, or a third party authentication authorisation may issue a private key to the terminal system 22, 24 for signing data file. This may be the same key for the digital wallet of the terminal system 22, 24. However, preferably, the private key to access the digital wallet on the data exchange server 20 or service application is different to that of signing data file.
  • the data exchange server 20 or server application will keep a copy of the data signature private key for each terminal system 20.
  • the logic processing unit of the data exchange server 20 is adapted to handle the authentication of the digitally signed document.
  • the protection of the data may be important for environments where documents support or carry additional risk to the data, in the health and medical areas for instance.
  • the data exchange server 20 or server application carries a Blockchain wallet that allows for the hash digest to be uploaded to the associated private Blockchain.
  • the uploading data will not submit for Blockchain process. Instead, the data will be stored as it is.
  • the data file is protected by other security measures to ensure the integrity and authenticity of the data.
  • the data file may be digitally signed or provided with a MD5 hash digest. These security measures are carried out in the sender terminal server 22 before the data file is sent or uploaded to the data exchange server 20.
  • the template or smart contract for the recipient will be submitted to the Blockchain process.
  • the template or smart contract may contain encrypted information such that only the recipient may able to read the template or smart contract.
  • encryption of the template or smart contract, or their content is optional. As the template or smart contract is typically smaller in size, it is more efficient when undergoing the Blockchain process.
  • the data file is encrypted with the instructions to decrypt stored in the template or smart contract.
  • the data exchange server 20, or server application has a distributer ledger recording the template or smart contract using Blockchain data structure.
  • the Blockchain data structure 30 comprises a genesis block 32 and a series of blocks 33.
  • Each block comprises a header 42, a previous hash 44, a timestamp 46, a sender 48, a recipient 50, a payload 52, and control data 54.
  • the control data 54 can be a hash, parity, or both for error detection and correction.
  • the genesis block may have an arbitrary value for the timestamp and nonce.
  • the payload 52 typically contains data message, transaction record, and /or smart contract.
  • the payload 52 mere contain a pointer or reference to the record or data file in a database.
  • the data exchange server 20, or server application provides the functions and features including the Blocktree Visualisation tool.
  • the tool provides a visual depiction of a 'Blocktree' which is a navigable user interface for viewing parties that have sent, received and forwarded a transaction.
  • Blocktree Visualisation tool allows senders and receivers to see a visual representation as to where data has been delivered and/or onforwarded across the network in real time. It also allows recipients to see where their data originated and where it has gone to. In this way the App provides all parties instant end to end transparency and auditability.
  • a software application can also take documents and data received and reconfigure that message into a new message that meets their commercial or operational requirements. In doing so, the recipient will ‘break’ the hash for the full received message, select and extract original data elements which retain their original hash, and place them, perhaps with additional data, into a new message which in turn will be hashed and those hashed placed in the private and public Blockchain. In this way, individual elements of the data onforwarded without change will retain their original hash and therefore authenticity as to point of origination.
  • the Blocktree Visualisation tool will continue to track those elements through the network even though they have been inserted into new messages.
  • Blocktree Visualisation is supported by a log that carries the same information in a manner that can be formally interrogated and downloaded into audit and compliance systems.
  • Messages can also be tagged for key words at the time the template version is set up by the User at the sender terminal system 22. These tags can then be used to search and manage past transactions. For instance for a specific recipient, product or version of a template.
  • a user can define what the recipient is allowed to see when they send a data file and template.
  • the user can define at the send terminal system individual products which the recipient will be able to see as part of their transaction even if the recipient has additional products on their recipient list which are related to the transaction.
  • the data exchange server 20 or server application allows the User to tailor what each addressee is permitted to see of the data in the template. For instance, if a template contains information on fifty products and it is sent to multiple addressees, commercial considerations may require that different addressees only have access to a different subset of those fifty products. This can be set up using the App at the time the template and distribution list is established by the User and managed on an ongoing basis.
  • Data can be moved between the data exchange server 20 or server application and internal systems and between the exchange and App/internal systems by API. While an API automates the upload from internal systems and the download from the exchange, the App still has oversight of the transactions that are anchored in that App/account.
  • the template can assist the data exchange system 20 to transparency and auditability while keeping the contents of the data secured.
  • Each company or industry segment will have a range of such standard formats for a myriad of tasks within their organisation/industry.
  • One example is for the transmission of key fund information and data, especially daily pricing data by wealth management industry participants.
  • Another is the freight forwarding industry where bills of loading pass through many parties as the cargo passes along the logistics channels.
  • the first step in the process is to identify these templates and introduce them to the network. Once included in the application menu and by the exchange these templates then form the basis for the data transactions.
  • the sender terminal system 22 or recipient system 24 can be a Personal Computer such as a desktop or a laptop computer.
  • the sender terminal system 22 or recipient system 24 can be a smart device such as a smart phone or tablet.
  • the sender terminal system 22 or recipient system 24 can be a server of a computer network of an institution or organisation. The server can handle a large amount of data and transaction for the entire institution or organisation. For such server, a logic processing unit may be present to facilitate any authentication, hashing, encryption, or decryption.
  • an extended data exchange system 12 comprising a custodian 42 for sending data file and data template or smart contract for Blockchain record to a central server 40.
  • the sender custodian 42 also sends the Blockchain record of the data template or smart contract to a fund manager 44.
  • the custodian 42 comprises the functionalities of a sender terminal system 22 for uploading data files;
  • the central server 40 comprises the functionalities of a data exchange 20; and
  • the fund manager 44 comprises the functionalities of a recipient terminal system 24.
  • the central server 40 is adapted to submit the cryptograph mapping of the data file and the cryptographic mapping of the template or smart contract to a Blockchain record.
  • the Blockchain record may be a public Blockchain record or a private Blockchain record.
  • the fund manager 44 may then download the data file from the central server 40.
  • the fund manager 44 is adapted to verify the data file and the template or smart contract with the Blockchain record.
  • the fund manager 44 will render the data file into displayable format in accordance with the template or smart contract.
  • the fund manager 44 is also adapted to submit data to the central server 40.
  • the fund manager is provided with the functionalities of a sender terminal system 22 and may submit the template or smart contract to the central server 40 for Blockchain record or transaction.
  • the fund manager may also comprises a data exchange server 20 or server application, such that another system, Accounts Administration System 45 may submit data files, template pr smart contract to the fund manager 44 for other recipient terminal systems 24 such as Platform 46, Distributor System 47, Researcher System 48, and Data House System 49 to download the data files therefrom.
  • the Accounts Administration System 45 comprises the functionalities of a sender terminal system 22, a data exchange system 20, and the recipient terminal system 24.
  • the Accounts Administration System 45 may comprise a number of hardware module or subsystem, each carrying out a separate functionality.
  • the account manager comprises a computer system with a first software application for the sender terminal system 22, a second software application for data exchange system 20, and a third software application for the recipient terminal system 24.
  • the sender terminal system 22 and the recipient terminal system 24 are client system using the services provided by the data exchange server 20.
  • the sender terminal system 22 connects to the data exchange server 20 through a web page in step 102 while the data exchange server 20 provides the web services.
  • the sender terminal server 20 is adapted to upload text or binary data file to the data exchange server in step 104.
  • the user may define the rules for accessing the data file as in step 106.
  • the user defined rules can be in the form of a data template or smart contract.
  • the sender terminal system 22 may directly send the template to the recipient terminal system. In another embodiment, the sender terminal system 22 may forward the data file along with the template or smart contract to the data exchange server 20 as shown in step 108.
  • the sender terminal system 22 comprises a local database as shown in step 110.
  • the sender terminal system 22 may retrieve a set of data from the local database to send to the data exchange server 20.
  • the sender terminal system 22 is associated with a database management server for retrieving data from a database in order to send the set of data to the data exchange server 20.
  • the terminal system 22 may sort the data in accordance with the rules defined by the user as shown in step 112. Then the data, and the template /smart contract are hashed locally as shown in step 114. The granularity of hashing can be defined in the template or smart contract.
  • the hash digest of the template or smart contract may be exported to the end user via API as shown in step 118. Also the hash digest may be submitted to the public Blockchain as shown in step 116 and export to end user via API as shown in step 118.
  • the sender server may save the data in text or binary format 122 as shown in Fig. 5.
  • the data file is digitally signed.
  • the sender terminal system 22 then hash the text or binary format using one of the cryptographic bit mapping or hashing algorithm such as MD5 or SHA256.
  • the hash may then be submitted to the private Blockchain ledger of the data exchange server 20 or to a public Blockchain as shown in step 125.
  • the data and the hash digest are uploaded to the data exchange server 20 to export to the customer or recipient terminal system 24 as shown in step 126.
  • the customer or recipient terminal system 24 then downloads or receives the data, and verifies the integrity of the data through the Blockchain record, hash digest, digital signature, or any combination of these data as shown in step 128.
  • the data exchange server 20 is adapted to carries out a number of functions. While data, files, and documents are hashed and /or signed for authentication and accuracy purposes, the actual data itself is never committed to the Blockchain.
  • the underpinning assumption of the data exchange server 20 is that the data can more efficiently protected by normal means, and submitting data to a decentralised public ledger is not secured and inefficiency.
  • the rationale is that Blockchain, whilst incredibly secure has real scalability issues both in terms of data quantity and number of participants due to the massive energy consumption required to drive Blockchain.
  • a private Blockchain is very reliable, however initially, private networks can be small and there may be an asymmetric relationship between parties in the network. For instance, would a bank like JP Morgan accept an error had occurred supported by a Blockchain driven by small businesses and servers, or would a small business accept that they had erred because the evidence came from a Blockchain dominated by large banks.
  • Fig. 6 shows an embodiment of a process of the present invention.
  • the process starts when the sender terminal system 22 or client server initiates a request to upload data to the data exchange server 20 through a browser application in step 130.
  • the server terminal system 22 will send encrypted raw data, documents, reports from the backend to the data exchange server 20 as shown in step 131.
  • this process is handled by the central processing unit and the network module of the sender terminal system.
  • the sender terminal system 22 uploads data to the data exchange server 20
  • the sender terminal system is adapted generate a hash for the metadata such as data template or smart contract to record on a private Blockchain as shown in step 134.
  • the sender terminal system 22, recipient terminal system 24, and the data exchange server 20 are all adapted to participate in the Blockchain protocol.
  • the sender terminal systems 22, and the recipient terminal systems 24, even together, have less processing power than the data exchange servers 20.
  • the solution of the PoW and /or PoS search is random.
  • a more powerful machine will provide a better probability of finding the solution of the hash.
  • the data exchange server 20 will in general have a better chance of finding the solution because it has more computation power.
  • the records ledger maintained in a private Blockchain system is typically smaller and hence the difficulty in searching a solution for the PoW/PoS is significant lower than that of a public Blockchain network.
  • the central server or data exchange server 20 receives and stores the data file.
  • the data exchange server 20 will verify the integrity and authenticity of the data file with the hash or digital signature provided.
  • the data exchange server 20 will keep a Blockchain record of the template or smart contract.
  • the data server 20 may submit the Blockchain record transaction to a public Blockchain as shown in step 137.
  • the data exchange server 20 may submit each and every Blockchain record transaction to a public Blockchain.
  • the data exchange server 20 will rearrange or bundle the records together before sending to the public Blockchain. For example, the data exchange server 20 may collect one hundred records, subjected them into one or more hashing functions, and submit the resulting hash or hash digest to the public Blockchain.
  • the client server or the recipient terminal system 24 downloads the data file from the central server or data exchange server 20.
  • the recipient system 24 uses the template or smart contract provided by the sender terminal system 22 to render the data file in display or operational form.
  • the recipient terminal system 24 may downloads the private Blockchain records from the data exchange server 20 to verify the integrity and authenticity of the data, and the data template or smart contract as shown in step 136.
  • the exchange server 20 will generate a download transaction record of such action and subject the transaction record in the private Blockchain.
  • the data exchange server 20 is adapted to operate with a wide range of data and document permission profiles.
  • the data exchange server 20 is adapted to allow options where a message is solely between two parties to one where the contents are completely available to every member of the network.
  • Each of these levels can then be fine tuned to set parameters as to when they can be seen by various parties. For instance, where there are commercial considerations as to when information has to be available those with commercial dependencies, i.e. payments, may need to see information before it becomes available to the remainder of the network.
  • the data exchange server 20 or server application is adapted to provide network oversight and management.
  • adding participants to the private Blockchain network requires an existing participant to nominate them. Each participant is then given a private Blockchain identifier. This full function is managed through the data exchange server 20 or server application.
  • identifiers used to identify products and services, such as a type of medical procedure, a car part, and so forth. Where these identifiers are highly standardised and managed, for instance in the supermarket bar code environment, these identifiers can be uploaded to the data exchange server 20 or server application for downloading into the templates to speed template construction and reduce inaccuracies.
  • the smart contact will contain code to direct the receiver such as the data exchange server 20 or recipient terminal system 24 to download the required identifiers when rendering the data file. This also ensures the data exchange server 20 can actively check the quality of data being sent via the templates or smart contract. Where no single standardised identifier exists, the data exchange server 20 or server application can accept pre-determined identifiers and even custom ones.
  • the data exchange server 20 or server application is adapted to include a function for nominating identifiers to the data exchange server which can then follow an agreed protocol to approve and promulgate those identifiers to the network.
  • the data exchange server 20 Because the data is distributed through the data exchange server 20, the data exchange server 20 will have a record of which participants are connected or not. This is the one of the network administration element held by the data exchange server 20. While it can inform a member that the reason their data is not uploading is that it is not connected to the data exchange server, the data exchange server cannot undertake any maintenance activity on the connected terminal systems 22, 24. That responsibility rests solely with the members own IT admin staff.
  • the data exchange server is not a database in the normal view; it does not store data in the template structure but as strings of data referenced by the sender, date time group and hash. Therefore, adding a template to the network is not a database change, it is merely setting the search parameters for managing and searching. This methodology also affects the way data can be mined.
  • Managing the transaction on the data exchange server 20 is an important feature of the data exchange server. Loading is relevant to both quantity of transactions and the size of those transactions. For instance, in most industries documents, even in PDF form are relatively small whereas in the health field X-rays and items such as MRI scans are considerable larger. It is therefore essential that any implementation of a platform addresses these key issues.
  • One of the tools in managing the data exchange server 20 or server application is a real time view of the transactions going through the data exchange server at any given time.
  • this requirement data exchange server the data exchange server to identify where parties are senders (uploading) and receiving (downloading) .
  • This visibility has allowed building an accounting tool that not only informs the participant as to their usage but also provides the basis for a more sophisticated account management and invoicing tool.
  • the data exchange system 10 of an embodiment of the present invention By far and away the largest potential impact for the data exchange system 10 of an embodiment of the present invention is the on-boarding of retail clients through intermediaries.
  • the data exchange platform enables a freer way to lower risk and facilitate a more efficient on-boarding process.
  • the data exchange system 10 is adapted to handle medical and health data.
  • the terminal system 22, 24 can a medical device or a module thereof.
  • the data exchange system 10 is utilised in Supply Chain Management.
  • the communication of essential information to multiple parties in the supply chain in order to meet national and international delivery timetables for the distribution of product or the provision of inputs to just in time manufacturing.
  • the data exchange system 10 is particularly valuable where multiple parties require access to different elements of the same overall information and documents that facilitate sign off for the next stage of the process.
  • the data exchange system 10 is adapted to handle data and records in the Insurance Industry. With global insurers having to have individual businesses in multiple countries, there are major issues in collecting and distributing information across multiple 'federated' entities where national regulatory regimes alter definitions and account for things differently.
  • the data exchange system 10 is adapted to handle smart contract type templates to enable harmonisation of meaning and therefore to drive massive efficiencies in the global reporting requirements of parent companies and the easier distribution of information into disparate regulatory regimes.
  • the data exchange server 20 or server application is adapted to data and transaction in project management.
  • the management of global projects often require the coordination of management of the design, purchase request, manufacture and delivery via numerous intermediaries in multiple jurisdictions. While modern management software can meet the requirements for core contractors the broader ecosystem remains a major issue.
  • the data exchange system 10 of the present invention can provide a communications infrastructure that guarantees the accuracy of communications between disparate parties in the complex environment.
  • the data exchange server 20 or server application is adapted to data and transaction in retail sale warranty management
  • the data exchange system 10 is considered for a process whereby warranties are registered at point of sale and automatically communicated to the manufacturer or a representative distributor.
  • the data exchange server 20 or server application is adapted to data and transaction associate with government organisation.
  • the data exchange system 10 can ensure that communications and information is traceable and auditable immediately.
  • the embodiments described with reference to the Figures can be implemented as an application programming interface (API) or as a series of libraries for use by a developer or can be included within another software application, such as a terminal or personal computer operating system or a portable computing device operating system.
  • API application programming interface
  • program modules include routines, programs, objects, components and data files assisting in the performance of particular functions, the skilled person will understand that the functionality of the software application may be distributed across a number of routines, objects or components to achieve the same functionality desired herein.

Abstract

A data exchange system and method comprising: a data exchange server for receiving authenticated data; a sender terminal system for sending authenticated data to the data exchange server; a recipient terminal system for receiving the data from the data exchange server; a data template for rending the data; wherein the sender terminal system submits the data template for Blockchain record; and the recipient terminal system receives the data template, and downloads the data file from the data exchange server; such that the recipient may render the data for use with the data template.

Description

A SYSTEM AND A METHOD FOR USE IN DATA EXCHANGE TECHNICAL FIELD
The invention relates to a data exchange system, and in particular, a system, a device, and a method for use in data exchange using Blockchain.
BACKGROUND
Blockchain may be used as a peer-to-peer distributed ledger of transactions updated through the consensus of the peer nodes. It is at the application layer of the OSI model.
A Blockchain comprises a series of block linked together in chronological order. The structure of a block generally comprises a block header, links to previous blocks, the time stamp, nonce, data counter, data, and other attributes. The size of a block is variable depending on the type and design. A link or reference to a previous block is also included in the block unless it's a first or genesis block. A genesis block was typically crafted at the time the Blockchain was started.
Blockchain technology can provide a platform which automates auditing and makes an application transparent yet secure. It is adapted to provide data integrity, immutability, and high availability services.
SUMMARY OF THE INVENTION
The present invention relates to a data exchange system and method, particularly to a system, device, or method of data exchange using Blockchain.
Other advantages will become apparent when taken into consideration with the following specification and drawings.
The present invention may also overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.
It is a first aspect of the present invention to provide a data exchange system comprising:
a data exchange server for receiving authenticated data;
a sender terminal system for sending authenticated data to the data exchange system;
a recipient terminal system for receiving the data from the data exchange server;
a data template for rending the data;
wherein the sender terminal system submits the data template for Blockchain record; and
the recipient terminal system receives the data template, and downloads the data file from the data exchange;
such that the recipient may render the data for use with the data template.
Preferably, the sender terminal system is adapted to provide an interface for generating the data template for the recipient terminal system.
Preferably, the sender terminal system is adapted to provide a web interface to upload data to the data into a selected data template and any associated documents.
Preferably, the sender terminal system is adapted to automatically invoke an application programming interface to send data into a selected data template and any associated documents.
Preferably, the sender terminal system is adapted to generate a hash digest with the data.
Preferably, the sender terminal system is adapted to generate a hash digest with the data at individual line item level.
Preferably, the sender terminal system is adapted to generate a hash digest for any associated documents.
Preferably, sender terminal system is adapted to submit the hash digest to a private Blockchain process.
Preferably, the sender terminal system is adapted to send the data, any documents and the hash digest to the exchange.
Preferably, the sender terminal system is adapted to send the hash digest and a notification to the recipient terminal system
Preferably, the recipient terminal system is adapted to receive and alter the data template for rendering the data for display.
Preferably, the sender terminal system is adapted to receive a confirmation notice of the successful transmission of data and data template.
Preferably, the recipient terminal system is adapted to download the data from the data exchange server through a web interface.
Preferably, the recipient terminal system is adapted to fetch the data through an application programming interface.
Preferably, the recipient terminal system is adapted to verify the hash digest of the data.
Preferably, the sender terminal system is adapted to perform an instant audit that the data has been received as transmitted.
Preferably, the recipient terminal system is adapted to send all or part of the data to another recipient terminal system using the hash digest in recorded in the private Blockchain process.
Preferably, the sender terminal system or the recipient terminal system is adapted to provide a BlockTree function, wherein the BlockTree function is adapted to provide both sender terminal system and recipient terminal system with visual representation of an end to end transmission of the data along with an identifier of each recipient terminal of the data.
Preferably, the data exchange server is adapted to manage a network for private Blockchain processes and operational status of participants in the network.
Preferably, the data exchange server is adapted to receive the data along with a hash digest of the data sent from the sender terminal system.
Preferably, the data exchange server is adapted to submit the hash digest into a public Blockchain process.
Preferably, the data exchange server is adapted to identify the recipient terminal system who is permitted receive the data and documents and provide access thereof.
Preferably, the data exchange server is adapted to manage access permissions such as time delays of the recipient terminal system, or time delays of public access of the data.
Preferably, the data exchange server is adapted to manage download protocols to recipient terminal system.
Preferably, the data exchange server is adapted to maintain backup of the data and the corresponding data template.
Preferably, the data template comprises a hash digest of the data.
Preferably, the data template comprises instructions code for manipulating the data.
Preferably, the data template comprises identifiers of the data.
In a second aspect of the present invention, there is provided a method for data exchange, comprising the steps of:
sending authenticated data to a data exchange system from a sender terminal system;
submitting the data template for Blockchain record;
wherein a recipient terminal system receives the data template, and downloads the data file from the data exchange;
such that the recipient may render the data for use with the data template.
In a third aspect of the present invention, there is provided a electron server for data exchange, comprising:
a network module for receiving authenticated data from a sender terminal system, and a data template for Blockchain record;
a central processing unit for receiving request from a recipient terminal system for downloading the data and data template;
a logic processing unit for performing Blockchain process in recording the data template;
wherein the recipient may render the data for use with the data template.
BRIEF DESCRIPTION OF THE FIGURES
Fig. 1 is a schematic diagram showing a data exchange system in accordance to an embodiment of the present invention;
Fig. 2 is a schematic diagram showing an extended data exchange system of Fig. 1;
Fig. 3 is a schematic diagram showing an architecture of a data exchange server of the data exchange system of Fig. 1;
Fig. 4 is a schematic diagram of a process of a terminal system of the data exchange system of Fig. 1;
Fig. 5 is a schematic diagram of a process of a data exchange server of the data exchange system of Fig. 1; and
Fig. 6 is a schematic diagram of a process of the data exchange system of Fig. 1.
DESCRIPTION OF THE INVENTION
The inventors have, through their own research, trials and experiments, devised that a data exchange platform can facilitate the exchange and distribution of structured data and associated documents between known participants using a combination of standard and Blockchain technologies.
In one example embodiment, a data exchange system may be used for offline data exchange associated with a Blockchain. The method comprising the steps of storing, in a memory of an integrated circuit card, a structured data set associated with a Blockchain network, wherein the structured data set includes at least a network identifier, an unspent output hash, an output index, an output value, and a key pair.
The system may carry out the step of receiving, by a receiving device of the integrated circuit card, at least the network identifier and a transaction amount from an electronic point of sale device; and validating, by a validation module of the integrated circuit card, the stored structured data set as including the network identifier and an output value greater than or equal to the received transaction amount. The system then electronically transmits, by a transmitting device of the integrated circuit card, at least the unspent output hash and the output index to the electronic point of sale device; and receives, by the receiving device of the integrated circuit card, at least a destination address from the electronic point of sale device; such that it can generates, by a generation module of the integrated circuit card, transaction data, wherein the transaction data includes at least the received destination address and a payment amount based on at least the transaction amount; and electronically transmits, by the transmitting device of the integrated circuit card, the transaction data to the electronic point of sale device.
However, it was found that this method may be designed to increase the efficient of transaction which need real-time validation, which may be not efficient in generic data exchange or file exchange.
In another example, there is a method comprising the step of intercepting, by a proxy server over a network, a data request from a first computing device that is directed to a web server; and modifying the data request to include user profile information.
The proxy server sends the modified data request to the web server and the information to the web server for controlling a manner for how data sent to the web server is cached in the web server. The proxy server is adapted to receive a response from the web server. The response to the proxy server includes information for controlling a manner for how data received from the web server is cached in the proxy server. The proxy server then  catches the data received from the web server in the proxy server; and sends at least a portion of the cached data from the proxy server to the first computing device.
However, the system is incapable of resolving the issues of authenticity, accuracy, trust, accountability, instant auditability, accessibility and priority. It is believed that the platform may only be useful for regular data transactions in environments with agreed data format standards.
In yet another example, a computer system may communicate with a distributed Blockchain computing system. The Blockchain computing system includes multiple computing nodes. The data exchange server stores an order book and a plurality of digital wallets associated with different clients.
The computer system receives new data transaction requests that are added to the order book. A match is identified between data transaction requests and hashes associated with the digital wallets associated with the respective data transaction requests are generated. The counterparties receive the hashes of the other party along with information on the match and each party causes Blockchain transactions to be added to the Blockchain of the Blockchain computing system. The computing system then monitors the Blockchain to determine if both sides of the match have been added to the Blockchain.
However, such system is not able to provide a data exchange server to cope with the exchange of generic data.
Without wishing to be bound by theory, the inventors devise that it is more preferable to use the combination of standard and Blockchain technologies to provide a data exchange system or method that is applicable to any situation where accuracy, accountability and auditability are key elements in the management of risk, whether financial/commercial, reputational or regulatory.
The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are  possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.
In one embodiment of the present invention as shown in Fig. 1, there is provide a system 10 comprising a custodian or sender terminal system 22 for sending data to a central server or data exchange server 20, and data template or smart contract to a fund manager or recipient terminal system 24. The central server or data exchange server 20 is adapted to submit the cryptograph mapping of the data file and the cryptographic mapping of the template or smart contract to a Blockchain record. The Blockchain record may be a public Blockchain record or a private Blockchain record. The fund manager or recipient terminal system 24 may then download the data file from the central server or data exchange server 20. The fund manager or recipient terminal system 24 is adapted to verify the data file and the template or smart contract with the Blockchain record. The fund manager or recipient terminal system 24 will render the data file into a displayable format in accordance with the template or smart contract.
Referring to Fig. 2, the system 10 of the present invention provides a data exchange server 20 comprising a central processing unit 33, memory 34 associate with the central processing unit, one or more logic processing unit 35, and a communication module 36. The communication module is adapted to receiving data from one or more local terminal system. The central processing unit is adapted to process general services, such as receiving and  handling request, locating data in the memory, sending data to the terminal system. The logic processing unit is adapted to handle authentication process, and Blockchain process. In one embodiment, the data exchange server has an array of logical processing unit running parallel to increase the performance of Blockchain functions.
In one embodiment, the data exchange server 20 is in the form of a software application or data exchange server application running in a dedicate computer server system. In one embodiment, the server is a single machine or a network of server module each providing different functionalities.
The data exchange server 20 or data exchange server application is designed to be installed on inside institutional firewalls. The server or server application is as a Business to Business (B2B) service. In one implementation, the institution may have only a small number of nodes and terminals, the server or server application can also be easily deployed to a hosted service.
In one embodiment, the data exchange server 20 or server application may comprises a number of modules to provide a variety of services. For example, the server or server application has a web service module to provide a web interface for a terminal system to upload and download data. The web interface may accept data with html and json protocol. In addition, the server or server application may also provide application programming interface (API) in the form of remote procedural call (RPC) . The terminal system may directly invoke a service such as uploading and downloading data remotely through the API. One implementation of such API is through the Enterprise Java Bean, DCOM, or . NET platform.
The data exchange server 20 or server application is designed to be completely managed by the participant as that ensures the ongoing accountability and reliability of the system and underpins the benefits of Blockchain. To enhance the performance of Blockchain process, the server or the hardware system running the server application is preferably installed with logic processing unit.
For example, the server may comprise one or more of specially implemented processor to facilitate the Blockchain function, such as Graphical Processing Units (GPU) ,  Field-Programmable Gate Array (FPGA) , or Application-Specific Integrated Circuit (ASIC) for handling the Blockchain and authentication functionalities. The logic progressing is typically designed for handling cryptography functions, such as hashing or cryptographic mapping function, private public key /public key processing, encryption and decryption. Depending on the implementation, the ASIC can be designed to handle SHA256, scrypt, or X11 processes. In particular, when the data exchange service 20 or server application participate in any public Blockchain function, the logic process unit is mainly design to enhance the efficiency in handling the proof of work (PoW) or proof of stake (PoS) process. The server may also include a parallel computing platform and any necessary application programming interface (API) model which may be involve in the Blockchain operations.
In one embodiment, the logic processing unit is a detachable module simple to enhance the performance of the server or server application. Without the logic processing unit, the server or server application may still able to carry out the Blockchain function with a longer processing time. In another implementation, the Blockchain functions are delegate to a cloud system or service, such as Amazon Web Service.
In one embodiment, the server or server application is adapted to provide individual accounts for multiple users within the same wallet. This allows for a participant offering services to multiple parties to use the server or server application in a manner that reflects its normal operating processes allowing autonomy and provide Chinese walls between different areas within the same business.
Additionally or optionally, a management module 37 may also be included to facilitate other services in relation to the data exchange server 20. For example, the optional management module 37 may include features such as a billing engine, a data source for product/service identifiers and/or an additional database for storing specific information.
Preferably, the management module 37 may be implemented as a component of the data exchange server 20 or it may be provided as an external component or in a separate server arranged to cooperate with the data exchange server 20 during a transaction or an exchange of data using the services provided by the central server.
The management module 37 may be deployed based on different requirements or applications. For example, the management module 37 may include a database for storing information relating to price of a product as well as a billing engine. The database may be managed by a financial institution and shared among multiple institutions.
When upon a transaction of such product is initiated by any of these financial institutions, the price information may be retrieved by the data exchange server 20, the billing engine may generate the necessary bill (s) for settlement, and subsequently the data exchange server 20 may process the data associated with the product, the price information, and the billing record to record the transaction in the Blockchains.
In an alternative example, the management module 37 may include a database for storing information for on-boarding clients across multiple systems/companies, which may be accessible by each of these companies and may be useful in the data exchange process.
Advantageously, such embodiment may be valuable in a know-your-customer (KYC) environment between financial institutions. For example, different financial institutions may track past transactions recorded in the Blockchain to avoid money-laundering.
In one embodiment, the system 10 comprises three the following elements:
(a) formal data templates are agreed by senders and receivers and integrated into the exchange and local sender/receiver application;
(b) a local User server based application; and
(c) a data exchange.
Preferably, the local User server based application is adapted to carry out the following steps:
enabling individual views of the data templates to be tailored by senders and receivers, and as such providing an interface for generating the data template for the recipient terminal system 24;
providing for automated through an application programming interface call or other means, and manual through a web interface uploading of data into the selected template and any associated documents;
hashing the data at both individual line item and whole of message level;
hashing associated documents if required;
saving the hashes to a private Blockchain;
sending the data, documents and hashes to the exchange;
sending the hash and notification to selected receivers;
allowing recipients to alter the template view they require;
receiving confirmations of the success of the transmission of data, data template, documents or hash digests;
allowing for downloading of the data and documents from the exchange manually through a web interface to the app or by API directly into the receiver’s systems or recipient terminal system 24;
checking the hash digest of the downloaded data to provide an instant audit, ensuring its authenticity and accuracy;
providing the sender with an instant audit that the message and data has been received as transmitted;
allowing the receiver to onforward all or part of the data and/or documents to other recipients using the same Blockchain message string; and
providing both sender and recipient visual representation of the end to end transmission of all data elements along with their receipt and onforwarding by participants in  the network. This functionality may be referred to as a ‘BlockTree’ which may allow the users to visually inspect all the elements in the Blockchain or the transactions being recorded.
Preferably, the data exchange is adapted to carry out the following steps:
managing the network including the private Blockchain and operational status of the individual participants;
receiving the hash digest, documents and data from the sender;
placing the hash digest into a public Blockchain to add a significant level of accountability and reliability to the limited private Blockchain utilised by the network’s participants;
identifying the recipients who should receive the data and documents and providing access;
managing associated permissions such as time delays between recipients and time delays for ‘public’ access of initially limited access data within the network;
managing the download protocols to recipients or recipient terminal system 24; and
backing up data or storing third party copies of all data for future accountability and auditability purposes.
The data exchange server 20 or server application is adapted to receive data from terminal system, and parse the received data. In one embodiment, the data received from the terminal system 22 is either text (comma separated values or *. csv files) or binary data (e.g. excel files) . The data exchange server 20 or server application is adapted to parse these text or binary data upon uploaded from the terminal system 22 in JavaScript Object Notation (JSON) format to be hashed; data is extracted from the text or binary file, read by the parser and saved to a database in JSON format. This data, individual lines of data and the total message, is then hashed separately in a SHA256 hashing function. Alternatively, electronic data recorded in any hashable format may also be supported by the data exchange system.
In another embodiment, the data template is encrypted and can only be read by the target recipient terminal system 24. The text or binary data is rather meaningless to anyone without the template. In one embodiment, the data template is compiled as a smart contract comprises codes or rules in parsing or displaying the data. The sender terminal system 22 may provide different data template or smart contract for each recipient terminal system 24 containing different set of codes or rules to parse and display the text or binary data stored in the data exchange server 20. This will allow different recipient terminal system 24 to access the same text or binary data differently.
In another embodiment, the data exchange server 20 or server application is adapted to receive the upload data authenticated. The sender terminal system 22 is adapted to digitally sign each and every data file upload to the data exchange server 20 or server application. In one embodiment, the data file is hashed with a certificate of authenticity before uploading to the data exchange server.
In one embodiment, all the  terminal systems  22, 24 have to be approved by the data exchange server 20 or server application before participating in any activities with the data exchange server 20. During the approval process, the data exchange server 20 or server application, or a third party authentication authorisation may issue a private key to the  terminal system  22, 24 for signing data file. This may be the same key for the digital wallet of the  terminal system  22, 24. However, preferably, the private key to access the digital wallet on the data exchange server 20 or service application is different to that of signing data file. The data exchange server 20 or server application will keep a copy of the data signature private key for each terminal system 20. In one embodiment, the logic processing unit of the data exchange server 20 is adapted to handle the authentication of the digitally signed document.
The protection of the data may be important for environments where documents support or carry additional risk to the data, in the health and medical areas for instance.
In one preferred embodiment, the data exchange server 20 or server application carries a Blockchain wallet that allows for the hash digest to be uploaded to the associated private Blockchain.
In one embodiment, the uploading data will not submit for Blockchain process. Instead, the data will be stored as it is. Preferably, the data file is protected by other security measures to ensure the integrity and authenticity of the data. The data file may be digitally signed or provided with a MD5 hash digest. These security measures are carried out in the sender terminal server 22 before the data file is sent or uploaded to the data exchange server 20. However, the template or smart contract for the recipient will be submitted to the Blockchain process. In one embodiment, the template or smart contract may contain encrypted information such that only the recipient may able to read the template or smart contract. In other embodiment, encryption of the template or smart contract, or their content is optional. As the template or smart contract is typically smaller in size, it is more efficient when undergoing the Blockchain process. In one embodiment, the data file is encrypted with the instructions to decrypt stored in the template or smart contract.
The data exchange server 20, or server application has a distributer ledger recording the template or smart contract using Blockchain data structure. In one embodiment as shown in Fig. 3, the Blockchain data structure 30 comprises a genesis block 32 and a series of blocks 33. Each block comprises a header 42, a previous hash 44, a timestamp 46, a sender 48, a recipient 50, a payload 52, and control data 54. The control data 54 can be a hash, parity, or both for error detection and correction. Depending on the implementation and the type of PoW /PoS protocol, the genesis block may have an arbitrary value for the timestamp and nonce.
The payload 52 typically contains data message, transaction record, and /or smart contract. In one embodiment, the payload 52 mere contain a pointer or reference to the record or data file in a database.
In a preferred embodiment, the data exchange server 20, or server application provides the functions and features including the Blocktree Visualisation tool. The tool provides a visual depiction of a 'Blocktree' which is a navigable user interface for viewing parties that have sent, received and forwarded a transaction. The visualisation also notes any changes in documents uploaded in a forwarded transaction by colour coding (orange=changes detected green=no change detected) by comparing the hash of each product to detect if any underlying data has been changed.
In this way the Blocktree Visualisation tool allows senders and receivers to see a visual representation as to where data has been delivered and/or onforwarded across the network in real time. It also allows recipients to see where their data originated and where it has gone to. In this way the App provides all parties instant end to end transparency and auditability.
A software application can also take documents and data received and reconfigure that message into a new message that meets their commercial or operational requirements. In doing so, the recipient will ‘break’ the hash for the full received message, select and extract original data elements which retain their original hash, and place them, perhaps with additional data, into a new message which in turn will be hashed and those hashed placed in the private and public Blockchain. In this way, individual elements of the data onforwarded without change will retain their original hash and therefore authenticity as to point of origination. The Blocktree Visualisation tool will continue to track those elements through the network even though they have been inserted into new messages.
The Blocktree Visualisation is supported by a log that carries the same information in a manner that can be formally interrogated and downloaded into audit and compliance systems.
Messages can also be tagged for key words at the time the template version is set up by the User at the sender terminal system 22. These tags can then be used to search and manage past transactions. For instance for a specific recipient, product or version of a template.
In a preferred embodiment a user can define what the recipient is allowed to see when they send a data file and template. In one example, the user can define at the send terminal system individual products which the recipient will be able to see as part of their transaction even if the recipient has additional products on their recipient list which are related to the transaction.
The data exchange server 20 or server application allows the User to tailor what each addressee is permitted to see of the data in the template. For instance, if a template contains information on fifty products and it is sent to multiple addressees, commercial considerations  may require that different addressees only have access to a different subset of those fifty products. This can be set up using the App at the time the template and distribution list is established by the User and managed on an ongoing basis.
Data can be moved between the data exchange server 20 or server application and internal systems and between the exchange and App/internal systems by API. While an API automates the upload from internal systems and the download from the exchange, the App still has oversight of the transactions that are anchored in that App/account.
In a preferred embodiment, the template can assist the data exchange system 20 to transparency and auditability while keeping the contents of the data secured.
In large corporations and highly regulated or interconnected industries, there is a high reliance on standard data and messaging formats in order to do business across networks in an efficient and effective manner. Many of these have standardised or common data formats and requirements for such activities.
Each company or industry segment will have a range of such standard formats for a myriad of tasks within their organisation/industry. One example is for the transmission of key fund information and data, especially daily pricing data by wealth management industry participants. Another is the freight forwarding industry where bills of loading pass through many parties as the cargo passes along the logistics channels.
The first step in the process is to identify these templates and introduce them to the network. Once included in the application menu and by the exchange these templates then form the basis for the data transactions.
In one embodiment, the =template may have fifty data fields laid out in a set pattern, however each sender and recipient can adjust their view of the template to suit their systems and working environment. From this view senders can then fill in what data they decide to forward in this particular edition of the template. In this way a sender may actually have multiple versions of the same template used for different recipients, where some data could be commercially confidential, or for different points in a supply chain. In the same way, recipients may customise what they download and when.
In a preferred embodiment, the sender terminal system 22 or recipient system 24 can be a Personal Computer such as a desktop or a laptop computer. In another embodiment, the sender terminal system 22 or recipient system 24 can be a smart device such as a smart phone or tablet. In yet another embodiment, the sender terminal system 22 or recipient system 24 can be a server of a computer network of an institution or organisation. The server can handle a large amount of data and transaction for the entire institution or organisation. For such server, a logic processing unit may be present to facilitate any authentication, hashing, encryption, or decryption.
In one embodiment of the present invention as shown in Fig. 3, there is provided an extended data exchange system 12 comprising a custodian 42 for sending data file and data template or smart contract for Blockchain record to a central server 40. At the same time, the sender custodian 42 also sends the Blockchain record of the data template or smart contract to a fund manager 44.
Hence, the custodian 42 comprises the functionalities of a sender terminal system 22 for uploading data files; the central server 40 comprises the functionalities of a data exchange 20;and the fund manager 44 comprises the functionalities of a recipient terminal system 24.
The central server 40 is adapted to submit the cryptograph mapping of the data file and the cryptographic mapping of the template or smart contract to a Blockchain record. The Blockchain record may be a public Blockchain record or a private Blockchain record. The fund manager 44 may then download the data file from the central server 40. The fund manager 44 is adapted to verify the data file and the template or smart contract with the Blockchain record. The fund manager 44 will render the data file into displayable format in accordance with the template or smart contract.
In the extended model, the fund manager 44 is also adapted to submit data to the central server 40. In this scenario, the fund manager is provided with the functionalities of a sender terminal system 22 and may submit the template or smart contract to the central server 40 for Blockchain record or transaction. The fund manager may also comprises a data exchange server 20 or server application, such that another system, Accounts Administration System 45 may submit data files, template pr smart contract to the fund manager 44 for other  recipient terminal systems 24 such as Platform 46, Distributor System 47, Researcher System 48, and Data House System 49 to download the data files therefrom.
Hence, the Accounts Administration System 45 comprises the functionalities of a sender terminal system 22, a data exchange system 20, and the recipient terminal system 24. The Accounts Administration System 45 may comprise a number of hardware module or subsystem, each carrying out a separate functionality. In another embodiment, the account manager comprises a computer system with a first software application for the sender terminal system 22, a second software application for data exchange system 20, and a third software application for the recipient terminal system 24.
The sender terminal system 22 and the recipient terminal system 24 are client system using the services provided by the data exchange server 20. In one embodiment as shown in Fig. 4, the sender terminal system 22 connects to the data exchange server 20 through a web page in step 102 while the data exchange server 20 provides the web services. The sender terminal server 20 is adapted to upload text or binary data file to the data exchange server in step 104. The user may define the rules for accessing the data file as in step 106. The user defined rules can be in the form of a data template or smart contract. The sender terminal system 22 may directly send the template to the recipient terminal system. In another embodiment, the sender terminal system 22 may forward the data file along with the template or smart contract to the data exchange server 20 as shown in step 108.
In one embodiment, the sender terminal system 22 comprises a local database as shown in step 110. The sender terminal system 22 may retrieve a set of data from the local database to send to the data exchange server 20. In another embodiment, the sender terminal system 22 is associated with a database management server for retrieving data from a database in order to send the set of data to the data exchange server 20.
After the sender terminal system 22 retrieved the data from the database from step 110, the terminal system 22 may sort the data in accordance with the rules defined by the user as shown in step 112. Then the data, and the template /smart contract are hashed locally as shown in step 114. The granularity of hashing can be defined in the template or smart contract. The hash digest of the template or smart contract may be exported to the end user  via API as shown in step 118. Also the hash digest may be submitted to the public Blockchain as shown in step 116 and export to end user via API as shown in step 118.
With the data retrieved from the database in step 110, the sender server may save the data in text or binary format 122 as shown in Fig. 5. In one embodiment, the data file is digitally signed. The sender terminal system 22 then hash the text or binary format using one of the cryptographic bit mapping or hashing algorithm such as MD5 or SHA256. The hash may then be submitted to the private Blockchain ledger of the data exchange server 20 or to a public Blockchain as shown in step 125. The data and the hash digest are uploaded to the data exchange server 20 to export to the customer or recipient terminal system 24 as shown in step 126. The customer or recipient terminal system 24 then downloads or receives the data, and verifies the integrity of the data through the Blockchain record, hash digest, digital signature, or any combination of these data as shown in step 128.
In another embodiment, the data exchange server 20 is adapted to carries out a number of functions. While data, files, and documents are hashed and /or signed for authentication and accuracy purposes, the actual data itself is never committed to the Blockchain. The underpinning assumption of the data exchange server 20 is that the data can more efficiently protected by normal means, and submitting data to a decentralised public ledger is not secured and inefficiency. The rationale is that Blockchain, whilst incredibly secure has real scalability issues both in terms of data quantity and number of participants due to the massive energy consumption required to drive Blockchain.
This applies to both the data exchange server 20 or the server application. In one preferred embodiment of the present invention, the efficiency and power consumption issues are dealt with the use of private and public Blockchain. A private Blockchain is very reliable, however initially, private networks can be small and there may be an asymmetric relationship between parties in the network. For instance, would a bank like JP Morgan accept an error had occurred supported by a Blockchain driven by small businesses and servers, or would a small business accept that they had erred because the evidence came from a Blockchain dominated by large banks.
While technically both these scenarios should not call the Blockchain into question, the commercial reality may be different. There may also be an issue of onus of proof  on the Exchange or data exchange server 20, which is effectively a distribution hub for the data and documents.
It is therefore preferable to add another layer of auditability by taking the hashes generated inside the data exchange server 20 or server application and placing them in a public Blockchain. This is a unique approach to Blockchain management.
Fig. 6 shows an embodiment of a process of the present invention. The process starts when the sender terminal system 22 or client server initiates a request to upload data to the data exchange server 20 through a browser application in step 130. The server terminal system 22 will send encrypted raw data, documents, reports from the backend to the data exchange server 20 as shown in step 131. Typically, this process is handled by the central processing unit and the network module of the sender terminal system. While the sender terminal system 22 uploads data to the data exchange server 20, the sender terminal system is adapted generate a hash for the metadata such as data template or smart contract to record on a private Blockchain as shown in step 134.
In one embodiment, the sender terminal system 22, recipient terminal system 24, and the data exchange server 20 are all adapted to participate in the Blockchain protocol. However, the sender terminal systems 22, and the recipient terminal systems 24, even together, have less processing power than the data exchange servers 20. The solution of the PoW and /or PoS search is random. However, a more powerful machine will provide a better probability of finding the solution of the hash. Hence, the data exchange server 20 will in general have a better chance of finding the solution because it has more computation power. Further, the records ledger maintained in a private Blockchain system is typically smaller and hence the difficulty in searching a solution for the PoW/PoS is significant lower than that of a public Blockchain network.
In step 132, the central server or data exchange server 20 receives and stores the data file. The data exchange server 20 will verify the integrity and authenticity of the data file with the hash or digital signature provided. In step 135, the data exchange server 20 will keep a Blockchain record of the template or smart contract. The data server 20 may submit the Blockchain record transaction to a public Blockchain as shown in step 137. The data exchange server 20 may submit each and every Blockchain record transaction to a public  Blockchain. In another embodiment, the data exchange server 20 will rearrange or bundle the records together before sending to the public Blockchain. For example, the data exchange server 20 may collect one hundred records, subjected them into one or more hashing functions, and submit the resulting hash or hash digest to the public Blockchain.
In step 133, the client server or the recipient terminal system 24 downloads the data file from the central server or data exchange server 20. The recipient system 24 then uses the template or smart contract provided by the sender terminal system 22 to render the data file in display or operational form. The recipient terminal system 24 may downloads the private Blockchain records from the data exchange server 20 to verify the integrity and authenticity of the data, and the data template or smart contract as shown in step 136. When the server or the recipient terminal system 24 downloads the data file from the data exchange server 20, the exchange server 20 will generate a download transaction record of such action and subject the transaction record in the private Blockchain.
Preferably, the data exchange server 20 is adapted to operate with a wide range of data and document permission profiles. In this way, the data exchange server 20 is adapted to allow options where a message is solely between two parties to one where the contents are completely available to every member of the network. Each of these levels can then be fine tuned to set parameters as to when they can be seen by various parties. For instance, where there are commercial considerations as to when information has to be available those with commercial dependencies, i.e. payments, may need to see information before it becomes available to the remainder of the network.
In another embodiment, the data exchange server 20 or server application is adapted to provide network oversight and management.
In one embodiment, adding participants to the private Blockchain network requires an existing participant to nominate them. Each participant is then given a private Blockchain identifier. This full function is managed through the data exchange server 20 or server application.
Within the template or smart contract, there are likely to be identifiers used to identify products and services, such as a type of medical procedure, a car part, and so forth.  Where these identifiers are highly standardised and managed, for instance in the supermarket bar code environment, these identifiers can be uploaded to the data exchange server 20 or server application for downloading into the templates to speed template construction and reduce inaccuracies. In another embodiment, the smart contact will contain code to direct the receiver such as the data exchange server 20 or recipient terminal system 24 to download the required identifiers when rendering the data file. This also ensures the data exchange server 20 can actively check the quality of data being sent via the templates or smart contract. Where no single standardised identifier exists, the data exchange server 20 or server application can accept pre-determined identifiers and even custom ones.
In another embodiment of the present invention, there is a need to manage situations where new, ‘interim’ or custom identifiers are used from time to time which are not sourced from the central identification agency. The data exchange server 20 or server application is adapted to include a function for nominating identifiers to the data exchange server which can then follow an agreed protocol to approve and promulgate those identifiers to the network.
Because the data is distributed through the data exchange server 20, the data exchange server 20 will have a record of which participants are connected or not. This is the one of the network administration element held by the data exchange server 20. While it can inform a member that the reason their data is not uploading is that it is not connected to the data exchange server, the data exchange server cannot undertake any maintenance activity on the connected  terminal systems  22, 24. That responsibility rests solely with the members own IT admin staff.
The data exchange server is not a database in the normal view; it does not store data in the template structure but as strings of data referenced by the sender, date time group and hash. Therefore, adding a template to the network is not a database change, it is merely setting the search parameters for managing and searching. This methodology also affects the way data can be mined.
Managing the transaction on the data exchange server 20 is an important feature of the data exchange server. Loading is relevant to both quantity of transactions and the size of those transactions. For instance, in most industries documents, even in PDF form  are relatively small whereas in the health field X-rays and items such as MRI scans are considerable larger. It is therefore essential that any implementation of a platform addresses these key issues.
One of the tools in managing the data exchange server 20 or server application is a real time view of the transactions going through the data exchange server at any given time. In turn, this requirement data exchange server the data exchange server to identify where parties are senders (uploading) and receiving (downloading) . This visibility has allowed building an accounting tool that not only informs the participant as to their usage but also provides the basis for a more sophisticated account management and invoicing tool.
Further industrial application of embodiments of the present invention is provided.
By far and away the largest potential impact for the data exchange system 10 of an embodiment of the present invention is the on-boarding of retail clients through intermediaries. The administrative gap between advisers, particularly independent ones, through the middle office platform which has to establish the identity and risk associated with that client under their regulatory obligations, and the asset manager who has to take final responsibility for managing the money invested by that client, is large and the associated risk high. The data exchange platform enables a freer way to lower risk and facilitate a more efficient on-boarding process.
In another embodiment of the present invention, the data exchange system 10 is adapted to handle medical and health data. The management of doctor qualifications, continuing professional development, medical practice authorisations and practice locations across a national medical service. Utilised by medical practices, professional bodies, government agencies, insurers and payment systems.
Transmission of semi sensitive information pertaining to payments across the medical system. Utilised by medical practitioners, practices, specialists, laboratories, hospitals, insurers, and government agencies. The management of medical devices, including prosthesis, through the manufacturing and delivery and monitoring stage. In one embodiment, the  terminal system  22, 24 can a medical device or a module thereof.
In a preferred embodiment of the present invention, the data exchange system 10 is utilised in Supply Chain Management. The communication of essential information to multiple parties in the supply chain in order to meet national and international delivery timetables for the distribution of product or the provision of inputs to just in time manufacturing. The data exchange system 10 is particularly valuable where multiple parties require access to different elements of the same overall information and documents that facilitate sign off for the next stage of the process.
In yet another application of an embodiment of the present invention, the data exchange system 10 is adapted to handle data and records in the Insurance Industry. With global insurers having to have individual businesses in multiple countries, there are major issues in collecting and distributing information across multiple 'federated' entities where national regulatory regimes alter definitions and account for things differently. The data exchange system 10 is adapted to handle smart contract type templates to enable harmonisation of meaning and therefore to drive massive efficiencies in the global reporting requirements of parent companies and the easier distribution of information into disparate regulatory regimes.
In another application of the present invention, the data exchange server 20 or server application is adapted to data and transaction in project management. The management of global projects often require the coordination of management of the design, purchase request, manufacture and delivery via numerous intermediaries in multiple jurisdictions. While modern management software can meet the requirements for core contractors the broader ecosystem remains a major issue. The data exchange system 10 of the present invention can provide a communications infrastructure that guarantees the accuracy of communications between disparate parties in the complex environment.
In an application of the present invention, the data exchange server 20 or server application is adapted to data and transaction in retail sale warranty management A major inefficiency in modern retailing, particularly in white goods and electronic sales, is the management of factory warranties and the associated consumer issues arising from it. The data exchange system 10 is considered for a process whereby warranties are registered at point of sale and automatically communicated to the manufacturer or a representative distributor.
In an application of the present invention, the data exchange server 20 or server application is adapted to data and transaction associate with government organisation. A large number of use cases exist where a government require that communications remain traceable across multi party information networks. The data exchange system 10 can ensure that communications and information is traceable and auditable immediately.
These embodiments may be advantageous in that the system may be useful in applications electronic data exchange and in particular for exchange of generic data using Blockchain technology to maintain data security and integrity.
Although not required, the embodiments described with reference to the Figures can be implemented as an application programming interface (API) or as a series of libraries for use by a developer or can be included within another software application, such as a terminal or personal computer operating system or a portable computing device operating system. Generally, as program modules include routines, programs, objects, components and data files assisting in the performance of particular functions, the skilled person will understand that the functionality of the software application may be distributed across a number of routines, objects or components to achieve the same functionality desired herein.
It will also be appreciated that where the methods and systems of the present invention may be either wholly implemented by computing system or partly implemented by computing systems then any appropriate computing system architecture may be utilised. This will include stand alone computers, network computers and dedicated hardware devices. Where the terms “computing system” and “computing device” are used, these terms are intended to cover any appropriate arrangement of computer hardware capable of implementing the function described. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the invention as shown in the specific embodiments without departing from the spirit or scope of the invention as broadly described. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.
Any reference to prior art contained herein is not to be taken as an admission that the information is common general knowledge, unless otherwise indicated.

Claims (55)

  1. A data exchange system comprising:
    a data exchange server for receiving authenticated data;
    a sender terminal system for sending authenticated data to the data exchange server;
    a recipient terminal system for receiving the data from the data exchange server;
    a data template for rending the data;
    wherein the sender terminal system submits the data template for Blockchain record; and
    the recipient terminal system receives the data template, and downloads the data file from the data exchange server;
    such that the recipient may render the data for use with the data template.
  2. A data exchange system according to Claim 1, wherein the sender terminal system is adapted to provide an interface for generating the data template for the recipient terminal system.
  3. A data exchange system according to Claim 1 or Claim 2, wherein the sender terminal system is adapted to provide a web interface to upload data to the data into a selected data template and any associated documents.
  4. A data exchange system according to Claim 1 or Claim 2, wherein the sender terminal system is adapted to automatically invoke an application programming interface to send data into a selected data template and any associated documents.
  5. A data exchange system according to any one of Claims 1 to 4, wherein the sender terminal system is adapted to generate a hash digest with the data.
  6. A data exchange system according to any one of Claims 1 to 5, wherein the sender terminal system is adapted to generate a hash digest with the data at individual line item level.
  7. A data exchange system according to any one of Claims 1 to 6, wherein the sender terminal system is adapted to generate a hash digest for any associated documents.
  8. A data exchange system according to any one of Claims 5 to 7, wherein the sender terminal system is adapted to submit the hash digest to a private Blockchain process.
  9. A data exchange system according to any one of Claims 5 to 8, wherein the sender terminal system is adapted to send the data, any documents and the hash digest to the exchange.
  10. A data exchange system according to any of one of Claims 5 to 9, wherein the sender terminal system is adapted to send the hash digest and a notification to the recipient terminal system
  11. A data exchange system according to any one of Claims 1 to 10, wherein the recipient terminal system is adapted to receive and alter the data template for rendering the data for display.
  12. A data exchange system according to any of one of Claims 1 to 11, wherein the sender terminal system is adapted to receive a confirmation notice of the successful transmission of data and data template.
  13. A data exchange system according to any of one of Claims 1 to 12, wherein the recipient terminal system is adapted to download the data from the data exchange server through a web interface.
  14. A data exchange system according to any of one of Claims 1 to 13, wherein the recipient terminal system is adapted to fetch the data through an application programming interface.
  15. A data exchange system according to any of one of Claims 5 to 13, wherein the recipient terminal system is adapted to verify the hash digest of the data.
  16. A data exchange system according to any one of Claims 1 to 15, wherein the sender terminal system is adapted to perform an instant audit that the data has been received as transmitted.
  17. A data exchange system according to any of one of Claims 8 to 16, wherein the recipient terminal system is adapted to send all or part of the data to another recipient terminal system using the hash digest in recorded in the private Blockchain process.
  18. A data exchange system according to any of one of Claims 1 to 17, wherein the sender terminal system or the recipient terminal system is adapted to provide a Blocktree function, wherein the Blocktree function is adapted to provide both sender terminal system and recipient terminal system with visual representation of an end to end transmission of the data along with an identifier of each recipient terminal of the data.
  19. A data exchange system according to any of one of Claims 1 to 18, wherein the data exchange server is adapted to manages a network for private Blockchain processes and operational status of participants in the network.
  20. A data exchange system according to any of one of Claims 1 to 18, wherein the data exchange server is adapted to receive the data along with a hash digest of the data sent from the sender terminal system.
  21. A data exchange system according to Claim 20, wherein the data exchange server is adapted to submit the hash digest into a public Blockchain process.
  22. A data exchange system according to Claim 20, wherein the data exchange server is adapted to identify the recipient terminal system who is permitted receive the data and documents and provide access thereof.
  23. A data exchange system according to any one of Claims 1 to 22, wherein the data exchange server is adapted to manage access permissions such as time delays of the recipient terminal system, or time delays of public access of the data.
  24. A data exchange system according to any one of Claims 1 to 23, wherein the data exchange server is adapted to manage download protocols to recipient terminal system.
  25. A data exchange system according to any one of Claims 1 to 24, wherein the data exchange server is adapted to maintain backup of the data and the corresponding data template.
  26. A data exchange system according to any one of Claims 1 to 25, wherein the data template comprises a hash digest of the data.
  27. A data exchange system according to any one of Claims 1 to 26, wherein the data template comprises instructions code for manipulating the data.
  28. A data exchange system according to any one of Claims 1 to 27, wherein the data template comprises identifiers of the data.
  29. A method for data exchange, comprising the steps of:
    sending authenticated data to a data exchange system from a sender terminal system;
    submitting the data template for Blockchain record;
    wherein a recipient terminal system receives the data template, and downloads the data file from the data exchange;
    such that the recipient may render the data for use with the data template.
  30. A method of data exchange according to Claim 29, wherein the sender terminal system is adapted to provide an interface for generating the data template for the recipient terminal system.
  31. A method of data exchange according to Claim 29 or Claim 30, wherein the sender terminal system is adapted to provide an interface to upload data to the data into a selected data template and any associated documents.
  32. A method of data exchange according to any one of Claims 29 to 31, wherein the sender terminal system is adapted to generate a hash digest with the data.
  33. A method of data exchange according to Claims 32, wherein the sender terminal system is adapted to submit the hash digest to a private Blockchain process.
  34. A method of data exchange according to any of one of Claims 29 to 34, wherein the sender terminal system is adapted to send the hash digest and a notification to the recipient terminal system
  35. A method of data exchange according to any one of Claims 29 to 34, wherein the recipient terminal system is adapted to receive and alter the data template for rendering the data for display.
  36. A method of data exchange according to any of one of Claims 29 to 36, wherein the sender terminal system is adapted to receive a confirmation notice of the successful transmission of data and data template.
  37. A method of data exchange according to any of one of Claims 29 to 36, wherein the recipient terminal system is adapted to download the data from the data exchange server through a web interface, or fetch the data through an application programming interface.
  38. A method of data exchange according to any of one of Claims 34 to 38, wherein the recipient terminal system is adapted to verify the hash digest of the data.
  39. A method of data exchange according to any one of Claims 34 to 38, wherein the sender terminal system is adapted to perform an instant audit that the data has been received as transmitted.
  40. A method of data exchange any of one of Claims 34 to 39, wherein the recipient terminal system is adapted to send all or part of the data to another recipient terminal system using the hash digest in recorded in the private Blockchain process.
  41. A method of data exchange according to any of one of Claims 29 to 40, wherein the sender terminal system or the recipient terminal system is adapted to provide a Blocktree function, wherein the Blocktree function is adapted to provide both sender terminal system and recipient terminal system with visual representation of an end to end transmission of the data along with an identifier of each recipient terminal of the data.
  42. A method of data exchange according to any of one of Claims 29 to 42, wherein the data exchange server is adapted to manages a network for private Blockchain processes and operational status of participants in the network.
  43. A method of data exchange according to any of one of Claims 29 to 43, wherein the data exchange server is adapted to receive the data along with a hash digest of the data sent from the sender terminal system.
  44. A method of data exchange according to Claim 43, wherein the data exchange server is adapted to submit the hash digest into a public Blockchain process.
  45. A method of data exchange according to Claim 42, wherein the data exchange server is adapted to identify the recipient terminal system who is permitted receive the data and documents and provide access thereof.
  46. A method of data exchange according to any one of Claims 29 to 46, wherein the data exchange server is adapted to manage access permissions such as time delays of the recipient terminal system, or time delays of public access of the data.
  47. A method of data exchange according to any one of Claims 29 to 47, wherein the data exchange server is adapted to manage download protocols to recipient terminal system.
  48. A method of data exchange according to any one of Claims 29 to 48, wherein the data exchange server is adapted to maintain backup of the data and the corresponding data template.
  49. A server for data exchange, comprising:
    a network module for receiving authenticated data from a sender terminal system, and a data template for Blockchain record;
    a central processing unit for receiving request from a recipient terminal system for downloading the data and data template;
    a logic processing unit for performing Blockchain process in recording the data template;
    wherein the recipient may render the data for use with the data template.
  50. A server for data exchange according to Claims 49, wherein the data template comprises instructions code for manipulating the data.
  51. A data exchange system according to Claim 1, further comprising a management module arranged to facilitate additional services in relation to the data exchange.
  52. A data exchange system according to Claim 52, wherein the management module includes a database accessible from the sender terminal system, the recipient terminal system and/or the data exchange server.
  53. A data exchange system according to Claim 52, wherein the management module includes a billing engine.
  54. A data exchange system according to Claim 1, wherein the Blockchain record facilitates multiple financial institutions to track transaction histories associated with a product.
  55. A data exchange system according to Claim 54, wherein the Blockchain record is further arranged to prevent money-laundering activities.
PCT/CN2018/074445 2018-01-29 2018-01-29 A system and a method for use in data exchange WO2019144400A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/074445 WO2019144400A1 (en) 2018-01-29 2018-01-29 A system and a method for use in data exchange

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2018/074445 WO2019144400A1 (en) 2018-01-29 2018-01-29 A system and a method for use in data exchange

Publications (1)

Publication Number Publication Date
WO2019144400A1 true WO2019144400A1 (en) 2019-08-01

Family

ID=67395739

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/074445 WO2019144400A1 (en) 2018-01-29 2018-01-29 A system and a method for use in data exchange

Country Status (1)

Country Link
WO (1) WO2019144400A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111597269A (en) * 2020-05-21 2020-08-28 昆明大棒客科技有限公司 Block chain-based contract implementation method, device and equipment
US10984402B2 (en) * 2018-11-01 2021-04-20 Clinton Taylor System for providing a peer-to-peer behavioral data exchange in a decentralized marketplace
WO2021122596A1 (en) * 2019-12-19 2021-06-24 Swiss Cyber Gate Ag Method and computer system for provable file transfer
WO2022235561A1 (en) * 2021-05-04 2022-11-10 Symphony Communication Services Holdings Llc Secure database with user-defined schemas

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017146333A1 (en) * 2016-02-22 2017-08-31 (주)코인플러그 Forgery/tampering verification system and method for financial institution certificates based on blockchain
US20170310653A1 (en) * 2016-04-22 2017-10-26 Sony Corporation Client, server, method and identity verification system
CN107493162A (en) * 2017-07-25 2017-12-19 中国联合网络通信集团有限公司 The implementation method and device of block chain node

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017146333A1 (en) * 2016-02-22 2017-08-31 (주)코인플러그 Forgery/tampering verification system and method for financial institution certificates based on blockchain
US20170310653A1 (en) * 2016-04-22 2017-10-26 Sony Corporation Client, server, method and identity verification system
CN107493162A (en) * 2017-07-25 2017-12-19 中国联合网络通信集团有限公司 The implementation method and device of block chain node

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10984402B2 (en) * 2018-11-01 2021-04-20 Clinton Taylor System for providing a peer-to-peer behavioral data exchange in a decentralized marketplace
WO2021122596A1 (en) * 2019-12-19 2021-06-24 Swiss Cyber Gate Ag Method and computer system for provable file transfer
CN111597269A (en) * 2020-05-21 2020-08-28 昆明大棒客科技有限公司 Block chain-based contract implementation method, device and equipment
WO2022235561A1 (en) * 2021-05-04 2022-11-10 Symphony Communication Services Holdings Llc Secure database with user-defined schemas

Similar Documents

Publication Publication Date Title
US11775945B2 (en) Secure real-time product ownership tracking using distributed electronic ledgers
US11741052B2 (en) Method and system for real-time collaboration and annotation-based action creation and management
US10970274B2 (en) System and method for electronic data capture and management for audit, monitoring, reporting and compliance
US20180075536A1 (en) Multiparty reconciliation systems and methods
CN110458562B (en) Bill reimbursement method, device and equipment and computer storage medium
US11240028B2 (en) Trust service engine for external blockchain verification
EP3844655B1 (en) Managing user authorizations for blockchain-based custom clearance services
AU2017222708A1 (en) Electronic document platform
US11372695B2 (en) Blockchain-based import custom clearance data processing
WO2019144400A1 (en) A system and a method for use in data exchange
EP3841491B1 (en) Blockchain-based smart contract pools
EP3844942B1 (en) Blockchain-based message services for time-sensitive events
EP3844654B1 (en) Blockchain-based document registration for custom clearance
Soundarya et al. A counterfeit solution for pharma supply chain
US20220036323A1 (en) Electronic wallet allowing virtual currency expiration date
US20210217100A1 (en) Storage management based on message feedback
Ahmad et al. GDPR compliance verification through a user-centric blockchain approach in multi-cloud environment
Jumani et al. Blockchain and big data: Supportive aid for daily life
Zhang et al. A review of blockchain solutions in supply chain traceability
KR102453918B1 (en) Automation system for import-export procedure
CN112507012A (en) Block chain-based bulk commodity cross-border trade process optimization system and method
Lu et al. Design of enterprise financial information management system based on blockchain technology
US20210097463A1 (en) Decentralized Resource Management System
CN111209337A (en) Financial report generation system, method, device, equipment and medium based on block chain
US20230419302A1 (en) Api for incremental and periodic crypto asset transfer

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18903021

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18903021

Country of ref document: EP

Kind code of ref document: A1