WO2018128581A1

WO2018128581A1 - A transaction management method

Info

Publication number: WO2018128581A1
Application number: PCT/SG2017/050007
Authority: WO
Inventors: Yi Kai KONG; Chia How CHENG
Original assignee: Aimazing Pte Ltd
Current assignee: Aimazing Pte Ltd
Priority date: 2017-01-06
Filing date: 2017-01-06
Publication date: 2018-07-12
Anticipated expiration: 2019-07-06

Abstract

Described herein is a transaction management method comprising receiving incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined, extracting transaction digest from the incoming sound signals of at least one of the plurality of frequencies and verifying existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated into the transaction digest by the client device. The transaction management method further comprises updating a blockchain with the transaction digest in response to existence of the merchant code being verified. Wherein transaction between the merchant and the client is effected upon update of the blockchain with the transaction digest.

Description

A TRANSACTION MANAGEMENT METHOD

TECHNICAL FIELD

This invention relates generally to a transaction management method.

Background

Existent systems and methods for effecting transactions, for example point-of-sales systems, require dedicated equipment set-up and a controlled environment in order for the system to function. For example, the use of card payment systems require the purchase of EDC or POS machines. Such systems are typically subjected to middleman transaction fees and may have a minimum transaction amount requirement before transaction can be effected. Further, the cards used with the payment system can be easily stolen and cloned. Other more progressive systems like QR code-based systems also requires some form of QR code scanner. Further, scanning errors are not uncommon in poor lighting or when the QR codes are on surfaces which are reflective or damaged. Additionally, QR codes and some other machine readable codes are exposed to atagging where the original QR code is replaced with one that has been embedded with viruses. There is therefore a need for a method and system for addressing the foregoing problems. Summary

In accordance with a first aspect of the invention, there is disclosed a transaction management method comprising receiving incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being predefined, extracting transaction digest from the incoming sound signals received over at least one of the plurality of frequencies and verifying existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated into the transaction digest by the client device. The merchant code is indicative of a merchant and the client code being indicative of a client. The transaction management method further comprises updating a blockchain with the transaction digest in response to existence of the merchant code being verified. Wherein transaction between the merchant and the client is effected upon update of the blockchain with the transaction digest.

In accordance with a second aspect of the invention, there is disclosed a machine-readable medium having stored therein a plurality of programming instructions, which when executed, the instructions cause the machine to receive incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined, extract transaction digest from the incoming sound signals received over at least one of the plurality of frequencies and verify existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated into the transaction digest by the client device. The merchant code is indicative of a merchant and the client code being indicative of a client. The plurality of programming instructions, when executed, further cause the machine to update a blockchain with the transaction digest in response to existence of the merchant code being verified. Wherein transaction between the merchant and the client is effected upon update of the blockchain with the transaction digest.

In accordance with a third aspect of the invention, there is disclosed a transaction management method comprising receiving incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being predefined, extracting transaction digest from the incoming sound signals received over at least one of the plurality of frequencies and verifying existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated into the transaction digest by the client device. The merchant code is indicative of a merchant and the client code being indicative of a client. Wherein transaction between the merchant and the client is effected upon existence of the merchant code being verified. Brief Description of the Drawings

FIG. 1 shows a process flow of a transaction management method according to an aspect of the invention;

FIG. 2 shows a system block diagram of a transaction management system in accordance with an aspect of the invention- for implementing the transaction management method of FIG. 1 ;

FIG. 3 illustrates exemplary look-up tables for generating/encoding and decoding incoming sound signals and outgoing sound signals of the transaction management system of FIG. 3; FIG. 4 illustrates an auto-encoder for data compression and decompression in the transaction management method of FIG. 4;

FIG. 5 shows a structure of a blockchain of the transaction management method of FIG. 1 ; FIG. 6 illustrates a structure of a Merkel tree for generating a Merkel from multiple transactions for capture as a transaction digest in a transaction data block of the blockchain of FIG. 5; and

FIG. 7 illustrates a structure of a chain of transactions based upon the blockchain of FIG. 5.

Detailed Description

An exemplary embodiment of the present invention, a transaction management method 100 for being performed by a transaction management system 20 is described hereinafter with reference to FIGS. 1 to 7.

Implementations of the present disclosure are generally directed to the transaction management method 100 and the transaction management system to provide a comprehensive platform system to facilitate delivery of services in, but not limited, business-to-business (B2B), business-to-consumer (B2C), consumer-to-consumer (C2C), business-to-government (B2G) and government-to-business (G2C) arrangements. The B2B applies also to individuals requiring operating in a business framework. The services provided can be adapted through a choice of B2B gateway services. The services can be aggregated by and channeled through third-parties. Implementations of the transaction management method 100 support diversified business possibilities and service delivery between businesses facilitated by best-of-breed platform of the transaction management system 20. The transaction management method 100 sets the stage for the next service-oriented revolution, referred variously as service ecosystems, future business value networks, and other forms of hubs and communities, underpinned by an Internet-scale infrastructure, to provide a level playing field for supply and demand of transaction and transaction management services on the Internet across a multitude of devices and computing systems.

An exemplary system architecture of the transaction management system 20 that can execute implementations of the present disclosure, can include one or more of a client device 22 associated with a client and a merchant system 24. As shown in FIG. 1, the transaction management system 20 further comprises a distributed ledger system 26 in data communication with the merchant system 24. The merchant system 24 can communicate with the distributed ledger system 26 over a network 28. In some implementations, the transaction management system 20 may represent a client/server system supporting multiple merchant system 24 including one or more clients (e.g., the client device 22) that are connect! vely coupled for communication with one another over the network 28. The client device 22, also referred to hereinafter as a user computing device, can represent various forms of processing devices including, but not limited to, a desktop computer, a laptop computer, a handheld computer, a personal digital assistant (PDA), a smartphone, a smart tablet, a cellular telephone, a network appliance, a camera, a smart phone, an enhanced general packet radio service (EGPRS) mobile phone, a media player, a navigation device, an email device, a game console, or a combination of any two or more of these data processing devices or other data processing devices.

The merchant system 24 can represent various forms of server systems including, but not limited to a web server, an application server, a proxy server, a network server, or a server farm which interacts and communicates with the client device 22 at node devices, for example a merchant device 30. The merchant device 30 may be a smart device similar to the client device 22 or may be a point-of-sales (POS) device that is standalone or in data communication to a central controller managing multiple POS devices. The network 28 can be a large computer network, such as a local area network (LAN), wide area network (WAN), the Internet, a cellular network, or a combination thereof connecting any number of mobile clients, fixed clients, and/or servers. In some implementations, each client (e.g., user computing device 22) can communicate with one or more of the control computer systems 26 via a virtual private network (VPN), Secure Shell (SSH) tunnel, or other secure network connection. In some implementations, the network 32 can include the Internet, a wireless service network and may include the Public Switched Telephone Network (PSTN). In other implementations, the network 28 may include a corporate network (e.g., an intranet) and one or more wireless access points.

In an exemplary embodiment of the transaction method 100, the merchant system 24 receives incoming sound signals 32 transmitted in at least one of a plurality of frequencies 34 from the client device 22 in a step 110. The plurality of frequencies 34 are pre-defined while the incoming sound signals 32 are received via the merchant device 30. Next, transaction digest 36 is extracted from the incoming sound signals 32 received over at least one of the plurality of frequencies 34 in a step 112. Existence of a merchant code 38 in the transaction digest 36 is then verified by the merchant system 24, for example by the merchant device 30, in a step 114. The transaction digest 36 further comprises a client code 40 being incorporated into the transaction digest 36 by the client device 22. The merchant code 38 is indicative of a merchant and identity thereof, while the client code 40 is indicative of a client and the identity thereof. Following the step 114, a blockchain 42 is updated with the transaction digest 36 in a step 116 in response to existence of the merchant code 38 being verified. The blockchain 42 is then broadcasted to the distributed ledger system 26 in a step 118 in response to the blockchain 42 being updated 42. Transaction between the merchant and the client is effected upon update of the blockchain 42 with the transaction digest 36. In some instances, transaction between the merchant and the client may be effected upon existence of the merchant code 38 being verified. Preferably, the step 114 of verifying existence of the merchant code 38 in the transaction digest 36 can comprise a step 120 of verifying validity of the merchant code 38 against a whitelist, also known as whitelist data. In the step 116 of updating the blockchain 42 with the transaction digest 36 in response to one or more of existence of the merchant code 38 in the transaction digest 36 being verified, existence of client code 40 in the transaction digest 36 being verified and validity of at least one of transaction data 46 and the client code 40 against at least one of the blockchain 42 and the whitelist data may be verified prior to updating the blockchain 42 with the transaction digest 36 in a step 122. The transaction data 46 being contained in the transaction digest 36 is indicative of the nature of transaction, for example, transaction amount, transaction conditions and transaction schedule.

Fundamentally, validity of the transaction digest 36 may be verified in response to the client code 40 being approved for transaction. Hence, in such an electronic transaction, the merchant code 38 functions as a public key while the client code 40 functions as a private key. Further, the step 116 of updating the blockchain 42 with the transaction digest 36 comprises a step 130 of determining a current block digest from the blockchain 42, appending the current block digest to the transaction digest 36 to obtain a transaction data block 50 in a step 132, and updating the blockchain 42 with the transaction datablock 59 to thereby obtain an updated blockchain in a step 134. Once the updated blockchain is obtained, a ledger of the distributed ledger system 26 is updated with at least one of the transaction datablock 50 and the updated blockchain in the 118. It is preferred that the transaction digest 36 further comprises indication of at least one of date and time whereat the client code 40 is being incorporated into the transaction digest 36, for example, a timestamp. It is also preferred that the transaction digest 36 is compressed and encrypted, for example via RSA, prior to generating the incoming sound signals 32 therefrom.

To obtain the transaction digest 36, the merchant system 24, preferably via the merchant device 30, transmits outgoing sound signals 54 generated from merchant data in at least one of the plurality of frequencies 34 to the client device 22 in a step 140. Preferably, the merchant data comprises the merchant code 38 being extractable from the outgoing sound signals 54 and processable with the client code 40 by the client device 22 for generating the transaction digest 36 therefrom. The merchant data may further comprise at least a portion of the transaction data 46. It is preferred that the merchant data be compressed and processed with a hash function prior to generating the outgoing sound signals 54 therefrom. Preferably, the hash function utilises one or more of MD5, SHA1 , SHA256, SHA3, BLAKE and BCRYPT functions.

It is preferred that each of the client device 22 and the merchant system 24, via the merchant device 30, comprises a sound transducer assembly for transducing between sound and electrical signals. The sound transducer assembly can comprises a microphone for receiving sound signals and at least one speakers to generating sound signals. Preferably, segments of each of the transaction digest 36 and the merchant data are being transmitted as signal wave at least one of sequentially and superpositioned via the plurality frequencies 34 in the steps 110 and 140. Preferably, the sound signals, in the form of mechanical sound waves such as the incoming sound signals 32 and the outgoing sound signals 54, are below 22kHz. However, a further preferred sound bandwidth of 6kHz to 20kHz is utilized for the plurality of frequencies 34 with each of a plurality of characters in a predefined dataset having one or more specific frequencies being associated therewith. The sound signals, for example the incoming sound signals 32 and the outgoing sound signals 54, may be represented as sine waves that may be transmitted and received in various modes as shown in FIG. The sound signals or sine waves may be based on a single wave in mode 1 as represented in Table 1 of FIG. 3, sequence of waves in mode 2 as represented in Table 2 of FIG. 3 or superpositioning of waves in mode 3 as represented in Table 3 of FIG. 3. General Utilisation

The transaction management method 100 enables one handheld device to transmit messages to other handheld devices via mechanical sound waves for effecting transaction thereby. As most typical handheld devices, such as smart phones and smart tabs, have a microphone and a speaker, using sound waves to transmit small amount of data comparing with QR code and Near Field Communication will render the transaction management system 20 platform- independent and economical. FIG. 1 illustrates these features in the form of a workflow where the Client utilizes the transaction management method 100 and the transaction management system 20 to send the merchant a transaction and to register the transaction via storing the transaction to the distributed ledger system 26.

In accordance with the afore-described transaction management method 100, the merchant sends his public key hash, for example in the form of an account address, to the client. The client then uses his private key to sign public key hash with a timestamp provided by merchant to enable the client to declare to whom he intends to make a payment transaction to. The client passes the signed public hash key to the merchant via sound wave. The merchant then checks whether the digital signature contains his public key hash before proceeding to broadcast the client's signature, pre-signed public hash key, to the distributed ledger system 26. The transaction management system 20 will then check whether the merchant is on the whitelist and verify if this transaction is valid.

Every role (i.e. the client, the merchant and the distributed ledger system 26) in ecosystem follows an Elliptic Curve Digital Signature Algorithm (ECDSA) to generate public/private key pairs. Ideally, Hence, the client is able to complete the transaction even when offline. In order to make transmission of sound signals, also known as sound waves, fast and reliable, the transaction management system 20 further comprises an autoencoder 62 shown employing an artificial neural network to perform high performance wave data compression. Before transmitting data x as sound waves, for example as incoming sound signals 32 or outgoing sound signals 54, data x is processed, encoded and compressed, into data z by the pre-trained autoencoder 62 before data z is transmitted at sound waves. The recipient of the sound waves will then extract data z from the received sound waves before the like autoencoder 62 n a recipient device decodes the exracted data z into data x'. Through the distributed ledger system 26, the blockchain 32 provides an ordered and timestamped record of transactions between merchant and client. Therefore the blockchain 32 used by the transaction management system 20 protects against double spending and modification of previous transaction records. As clients and merchants have to request permission in order to join this ecosystem of distributed ledger system 26, member(s) of the distributed ledger system 26 vote to determine whether an individual is able to join the ecosystem to become a valid node in the distributed ledger system 26. Each node in a network of nodes of the distributed ledger system 26 independently stores the block chain 32 containing only data blocks, for example the transaction data blocks 50, validated by that node. When several nodes all have the same data blocks in their blockchain 32, they are considered to be in consensus. The validation rules these nodes follow in order to maintain consensus are called consensus rules. In a simplified version of the blockchain 32, data of one or more new transactions is collected into the transaction data part of a data block. Copies of each transaction are hashed to obtain a digest before the digests are paired, hashed, paired again, and hashed again until a single eventual digest remains to represent a Merkle root 64 of a Merkle tree 66.

The Merkle root is stored in a data block header. Each data block also stores the hash, or digest, of the previous data block's header to thereby chain the data blocks together. This ensures that a transaction cannot be modified without having the other data blocks in the blockchain 32 modified as well.

As the transactions, as represented by the datablocks, are also chained together, each transaction spends electronic currency previously received in one or more earlier transactions, thereby resulting in the input of one transaction being the output of a previous transaction.

An electronic currency is a chain of digital signatures. Therefore, each payer transfers the currency to another by digitally signing a hash of the previous transaction and the public key of a payee before adding these to the end of the currency. The payee can then verify the signatures to verify the chain of ownership of the electronic currency. The transaction management method 100 is further implementable through a machine- readable medium having stored therein a plurality of programming instructions, which when executed, the instructions cause the machine to receive incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined, extract transaction digest from the incoming sound signals of at least one of the plurality of frequencies and verify existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated into the transaction digest by the client device. The merchant code is indicative of a merchant and the client code being indicative of a client. The plurality of programming instructions, when executed, further cause the machine to update a blockchain with the transaction digest in response to existence of the merchant code being verified. Wherein transaction between the merchant and the client is effected upon update of the blockchain with the transaction digest.

Aspects of particular embodiments of the present disclosure address at least one aspect, problem, limitation, and/or disadvantage associated with existing computer-implemented methods and systems. While features, aspects, and/or advantages associated with certain embodiments have been described in the disclosure, other embodiments may also exhibit such features, aspects, and/or advantages, and not all embodiments need necessarily exhibit such features, aspects, and/or advantages to fall within the scope of the disclosure. It will be appreciated by a person of ordinary skill in the art that several of the above-disclosed structures, components, or alternatives thereof, can be desirably combined into alternative structures, components, and/or applications. In addition, various modifications, alterations, and/or improvements may be made to various embodiments that are disclosed by a person of ordinary skill in the art within the scope of the present disclosure, which is limited only by the following claims.

Claims

1. A transaction management method comprising:

receiving incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined; extracting transaction digest from the incoming sound signals received over at least one of the plurality of frequencies;

verifying existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated thereinto by the client device, the merchant code being indicative of a merchant and the client code being indicative of a client; and

updating a blockchain with the transaction digest in response to existence of the merchant code being verified,

wherein transaction between the merchant and the client is effected upon update of the blockchain with the transaction digest.

The transaction management method as in claim 1 , verifying existence of a merchant code in the transaction digest comprising verifying validity of the merchant code contained in the transaction digest.

The transaction management method as in claim 1 , updating the blockchain with the transaction digest in response to existence of the merchant code being verified comprising:

verifying validity of at least one of transaction data and the client code against at least one of the blockchain and whitelist data prior to updating the blockchain with the transaction digest, the transaction data being contained in the transaction digest.

The transaction management method as in claim 3, updating the blockchain with the transaction digest in response to existence of the merchant code being verified comprising:

determining a current block digest from the blockchain;

appending the current block digest to the transaction digest to obtain a transaction data block; and

updating the blockchain with the transaction datablock to thereby obtain an updated blockchain.

The transaction management method as in claim 4, further comprising:

updating a ledger with at least one of the transaction datablock and the updated blockchain.

The transaction management method as in claim 1, the transaction digest further comprising indication of at least one of date and time whereat the client code is being incorporated into the transaction digest.

The transaction management method as in claim 1, the transaction digest being compressed prior to generating the incoming sound signals therefrom.

The transaction management method as in claim 1, further comprising:

transmitting outgoing sound signals generated from merchant data in at least one of the plurality of frequencies to the client device, the merchant data comprising the merchant code being extractable from the outgoing sound signals and processable with the client code by the client device for generating the transaction digest therefrom.

The transaction management method as in claim 8, the merchant data being compressed prior to generating the outgoing sound signals therefrom.

The transaction management method as in claim 8, the merchant code being processed with a hash function prior to generating the merchant data therewith.

The transaction management method as in claim 10, the hash function utilises more of MD5, SHA1, SHA256, SHA3, BLAKE and BCRYPT functions.

12. The transaction management method as in claim 1, the blockchain being updated further in response to existence of client code in the transaction digest being verified.

13. The transaction management method as in claim 12, the transaction digest being verified in response to the client code being approved for transaction.

14. The transaction management method as in claim 12, the merchant code functioning as a public key while the client code functioning as a private key.

15. The transaction management method as in claim 1, segments of each of the transaction digest and the merchant data being transmitted as signal wave at least one of sequentially and superpositioned via the plurality frequencies.

The transaction management method as in claim 15, each of a plurality of characters in a predefined dataset having one or more specific frequencies being associated therewith.

A machine-readable medium having stored therein a plurality of programming instructions, which when executed, the instructions cause the machine to:

receive incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined; extract transaction digest from the incoming sound signals received over at least one of the plurality of frequencies;

verify existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated thereinto by the client device, the merchant code being indicative of a merchant and the client code being indicative of a client; and

update a blockchain with the transaction digest in response to existence of the merchant code being verified,

The machine readable medium of claim 17, the plurality of programming instructions when executed, further cause the machine to:

verify validity of the merchant code contained in the transaction digest.

transmit outgoing sound signals generated from merchant data in at least one of the plurality of frequencies to the client device, the merchant data comprising the merchant code being extractable from the outgoing sound signals and processable with the client code by the client device for generating the transaction digest therefrom. The machine readable medium of claim 17, the plurality of programming instructions when executed, further cause the machine to:

determine a current block digest from the blockchain;

append the current block digest to the transaction digest to obtain a transaction data block;

update the blockchain with the transaction datablock to thereby obtain an updated blockchain; and

update a ledger with at least one of the transaction datablock and the updated blockchain.

A transaction management method comprising:

receiving incoming sound signals transmitted in at least one of a plurality of frequencies from a client device, the plurality of frequencies being pre-defined; extracting transaction digest from the incoming sound signals received over at least one of the plurality of frequencies; and

verifying existence of a merchant code in the transaction digest, the transaction digest further comprising a client code being incorporated thereinto by the client device, the merchant code being indicative of a merchant and the client code being indicative of a client,

wherein transaction between the merchant and the client is effected upon existence of the merchant code being verified.

The transaction management method as in claim 21, further comprising: