Technical Field

[1] The present invention generally relates to activity tracking and in particular to a computer system and a computer implemented method for determining fulfilment of an obligation to a user.

Background

[2] Any obligation that is meant to be fulfilled to a user may be tracked through issuance of an obligation document to the user. In industrial parlance, such an obligation document is known as a job ticket and the user is a customer and the obligation may be resolution of some grievance or initiation of a new service. In medical parlance, such an obligation document may be called a prescription for medication and the user is generally a patient. In case of catering services, such an obligation document may be a food coupon and the obligation in that scenario is provision of a meal to a customer or an employee etc. In any case, the obligation document acts as a reference to track the status of fulfilment of the obligation.

[3] However, such a process flow is prone to abuse, through for example, issuance of spurious obligation documents, unauthorized reuse of the same document and closing the obligation without actually fulfilling the obligation to the user. The current technology has allowed in some respects for the obligation to be tracked much more efficiently by implementing the obligation tracking in digital form, allowing the obligation to be revisited even long after the same has been closed. But even the digital implementation is still susceptible to abuse through hacking, man-in-the -middle and brute force attacks.

[4] It is therefore desirable to have a computer system and a computer implemented method for determining fulfilment of an obligation to the user, which does not suffer from above mentioned deficiencies.

[5] Throughout this specification, unless the context requires otherwise, the words “comprise”,“comprises” and“comprising” will be understood to imply the inclusion of a stated step or element or group of steps or elements but not the exclusion of any other step or element or group of steps or elements. [6] Any one of the terms:“including” or“which includes” or“that includes” as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others.

[7] Any discussion of the background art throughout the specification should in no way be considered as an admission that such background art is prior art nor that such background art is widely known or forms part of the common general knowledge in the field in Australia or worldwide.

[8] The terms used in the present invention in relation to cryptography and related algorithms, for example, hash operation, hash value, digital signature, public key, private key, verification, encryption, decryption, AES256-GCM, Elliptic Curve Integrated Encryption Scheme (ECIES), Elliptic Curve Digital Signature Algorithm (ECDSA), Digital Signature Algorithm (DSA), RSA, etc., should be interpreted under the context of cryptography and related industrial practice.

Summary

[9] There is provided a computer-implemented method for use in determining fulfilment of an obligation to a user. The method comprises obtaining from a data interface a first set of data in relation to the obligation, performing a first hash operation on the first set of data to determine a first hash value, performing a second hash operation on the first hash value to determine a second hash value, generating a first data record including the second hash value and a fulfilment indication value, the fulfilment indication value indicating if the obligation is fulfilled and storing the first data record including the second hash value and the fulfilment indication value in a ledger for use in determining fulfilment of the obligation to the user.

[10] The invention applies the first hash operation to the first set of data, which may be for example a prescription issued from a doctor to a patient, to determine the first hash value, and subsequently applies the second hash operation to the first hash value to determine the second hash value. The second hash value is to be used as an reference to locate the first data record including the fulfilment indication value in the ledger in order to determine if the obligation is fulfilled or not. The use of the first hash operation and the second hash operation enables fast generation of the second hash value and makes it extremely hard if not impossible to recover the first set of data from the second hash value due to mathematical properties of the hash operation. This effectively prevents the first set of data, for example the prescription, from being disclosed to a third party even if the third party is able to access the ledger. [11] The computer-implemented method may further comprise generating an encryption key, encrypting the first set of data using the encryption key to determine a first encrypted set of data, generating a second data record that associates the encryption key with the first encrypted set of data and sending via the data interface the second data record to a storage device associated with the user to store the second data record to determine the obligation to the user.

[ 12] The step of generating the second data record may further comprise performing a third hash operation on the first encrypted set of data to determine a third hash value and storing the third hash value in association with the encryption key in the second data record.

[13] The step of obtaining the first set of data may further comprise receiving from the data interface a second set of data representing the obligation, the second set of data being provided by an issuer, determining a first private key of a first pair of keys associated with the issuer, the first pair of keys including a first public key and the first private key, receiving from the data interface a second public key of a second pair of keys associated with the user, the second pair of keys including the second public key and a second private key, applying a cryptographic process to the second set of data and the second public key to generate a digital signature based on the first private key associated with the issuer and generating the first set of data including the second set of data, the second public key and the digital signature.

[14] The computer-implemented method may further comprise encrypting the first set of data using the second public key associated with the user to determine a second encrypted set of data.

[15] The computer-implemented method may further comprise receiving a sequence number associated with the user, generating a third data record that associates the sequence number with the second encrypted set of data, and storing the third data record in the ledger.

[16] The step of generating the third data record may further comprise performing a fourth hash operation on the second encrypted set of data to determine a fourth hash value and storing the sequence number in association with the fourth hash value in the third data record.

[17] The method may further comprise generating a fourth data record including the second hash value and the third hash value and storing the fourth data record in the ledger. [18] The computer-implemented method may further comprise generating a fifth data record including the first encrypted set of data, the third hash value, the second encrypted set of data and the fourth hash value and storing the fifth data record in a database.

[19] The computer-implemented method may further comprise storing the second data record in the ledger.

[20] The ledger may be a blockchain.

[21] There is provided a computer-implemented method for determining fulfilment of an obligation to a user, the method comprising obtaining from a data interface a first set of data in relation to the obligation, performing a first hash operation on the first set of data to determine a first hash value, performing a second hash operation on the first hash value to determine a second hash value, identifying from a ledger a first data record including the second hash value and a fulfilment indication value, determining the fulfilment indication value from the first data record and determining if the obligation is fulfilled based on the fulfilment indication value and the first hash value.

[22] The step of determining if the obligation is fulfilled may further comprise, if the fulfilment indication value is equal to the first hash value, generating a first indication indicating the obligation is fulfilled and if the fulfilment indication value is not equal to the first hash value, generating a second indication to fulfil the obligation, receiving from the data interface a third indication indicating that the obligation is fulfilled and in response to receipt of the third indication, replacing the fulfilment indication value in the first data record with the first hash value to indicate that the obligation is fulfilled.

[23] The step of obtaining the first set of data in relation to the obligation may further comprise receiving a second data record that associates an encryption key with a first encrypted set of data, the first encrypted set of data being generated by encrypting the first set of data using the encryption key and decrypting the first encrypted set of data using the encryption key to determine the first set of data.

[24] The second data record may include the encryption key and a third hash value that is generated by performing a third hash operation on the first encrypted set of data, and decrypting the first encrypted set of data may further comprise identifying from a database a fifth data record that associates the third hash value with the first encrypted set of data and determining the first encrypted set of data from the fifth data record. [25] The first set of data may include a second set of data representing the obligation, the second set of data being provided by an issuer, a second public key associated with the user and a digital signature.

[26] The computer-implemented method may further comprise determining a digital challenge, sending the digital challenge to a computing device associated with the user for the computing device to generate a response based on the digital challenge and a second private key associated with the user, receiving the response from the computing device associated with the user, extracting from the first set of data the second public key associated with the user and verifying, based on the digital challenge and the second public key associated with the user, that the response is generated using the second private key associated with the user.

[27] The computer-implemented method may further comprise receiving from the data interface a first public key associated with the issuer, extracting from the first set of data the digital signature, extracting from the first set of data the second set of data representing the obligation, verifying, based on the second set of data and the first public key associated with the issuer, that the digital signature is generated by applying a cryptographic process to the second set of data and the second public key associated with the user based on a first private key associated with the issuer.

[28] There is provided a computer system for use in determining fulfilment of an obligation to a user, the computer system comprising, a memory unit configured to store machine -readable instructions and a processor operably connected with the memory unit, the processor obtaining the machine-readable instructions from the memory unit, and being configured by the machine- readable instructions to obtain from a data interface a first set of data in relation to the obligation, perform a first hash operation on the first set of data to determine a first hash value, perform a second hash operation on the first hash value to determine a second hash value, generate a first data record including the second hash value and a fulfilment indication value, the fulfilment indication value indicating if the obligation is fulfilled and store the first data record including the second hash value and the fulfilment indication value in a ledger for use in determining fulfilment of the obligation to the user.

[29] The processor may be further configured to generate an encryption key, encrypt the first set of data using the encryption key to determine a first encrypted set of data, generate a second data record that associates the encryption key with the first encrypted set of data and send via the data interface the second data record to a storage device associated with the user to store the second data record to determine the obligation to the user.

[30] For generating the second data record, the processor may be further configured to perform a third hash operation on the first encrypted set of data to determine a third hash value and store the third hash value in association with the encryption key in the second data record.

[31] There is provided a computer system for determining fulfilment of an obligation to a user, the computer system comprising a memory unit configured to store machine -readable instructions and a processor operably connected with the memory unit, the processor obtaining the machine-readable instructions from the memory unit, and being configured by the machine- readable instructions to obtain from a data interface a first set of data in relation to the obligation, perform a first hash operation on the first set of data to determine a first hash value, perform a second hash operation on the first hash value to determine a second hash value, identify from a ledger a first data record including the second hash value and a fulfilment indication value, determine the fulfilment indication value from the first data record and determine if the obligation is fulfilled based on the fulfilment indication value and the first hash value.

[32] For determining if the obligation is fulfilled, the processor may be further configured to, if the fulfilment indication value is equal to the first hash value, generate a first indication indicating the obligation is fulfilled and if the fulfilment indication value is not equal to the first hash value, generate a second indication to fulfil the obligation, receive from the data interface a third indication indicating that the obligation is fulfilled and in response to receipt of the third indication, replace the fulfilment indication value in the first data record with the first hash value to indicate that the obligation is fulfilled.

[33] For obtaining the first set of data in relation to the obligation, the processor may be further configured to receive a second data record that associates an encryption key with a first encrypted set of data, the first encrypted set of data being generated by encrypting the first set of data using the encryption key and decrypt the first encrypted set of data using the encryption key to determine the first set of data.

[34] The second data record may include the encryption key and a third hash value that is generated by performing a third hash operation on the first encrypted set of data, and for decrypting the first encrypted set of data, the processor may be further configured to identify from a database a fifth data record that associates the third hash value with the first encrypted set of data and determine the first encrypted set of data from the fifth data record.

Brief Description of Drawings

[35] At least one embodiment of the present invention will be described with reference to the accompanying drawings, in which:

[36] Figure 1 is an exemplary system in which the various embodiments may be implemented in accordance with the present invention;

[37] Figure 2 illustrates computer-implemented method for use in determining fulfilment of an obligation to a user in accordance with an embodiment of the present invention;

[38] Figure 3 illustrates an example prescription in accordance with an embodiment of the present invention;

[39] Figure 4 illustrates an example fulfilment receipt in accordance with an embodiment of the present invention;

[40] Figure 5 illustrates a computer-implemented method for determining fulfilment of an obligation to a user in accordance with an embodiment of the present invention;

[41] Figure 6 illustrates an example system for determining fulfilment of an obligation to a user in accordance with the present invention;

[42] Figure 7 illustrates an example of a signed prescription in accordance with an embodiment of the present invention;

[43] Figure 8 illustrates an exemplary first encrypted set of data in accordance with an embodiment of the present invention;

[44] Figure 9 illustrates an exemplary third hash value in accordance with an embodiment of the present invention;

[45] Figure 10 illustrates an exemplary prescription note in accordance with an embodiment of the present invention;

[46] Figure 11 illustrates a second encrypted set of data in accordance with an embodiment of the present invention; [47] Figure 12 illustrates an exemplary digital challenge in accordance with an embodiment of the present invention; and

[48] Figure 13 illustrates an exemplary response to the digital challenge in accordance with an embodiment of the present invention.

[49] It should be noted that the same numeral represents the same or similar elements throughout the drawings.

Description of Embodiments

[50] A skilled addressee would appreciate that the present invention is not limited to the scenario described with reference to the exemplary system and may be equally applicable to different scenarios without departing from the scope of the present invention.

System Description

[51] Figure 1 illustrates an exemplary system 100 in which the various embodiments described herein may be implemented. Figure 1 illustrates a client device 102 associated with a user. The client device 102 may be selected from a group comprising mobile handheld devices (such as mobile phones, PDA and tablet PCs etc.), desktop PCs and notebooks etc. The client device 102 is connected with a network 106. The network 106 may be one of but not limited to a Local Area Network (LAN) or a Wide Area Network (WAN). The network 106 may be implemented using a number of protocols, such as but not limited to, TCP/IP, 3GPP, 3GPP2, LTE, IEEE 802.x etc.

[52] Further connected to the network 106 is an issuer device 104 associated with an issuer of the obligation document. The issuer may be for example a doctor and the obligation document in that case may be a prescription. In another scenario, the issuer may be a traffic policeman and the obligation document may be a parking ticket. The issuer device 104 may be a portable computing device, a desktop computer or a server stack. The issuer device 104 includes a memory unit 1042 configured to store machine readable instructions. The machine- readable instructions may be loaded into the memory unit 1042 from a non-transitory machine- readable medium, such as but not limited to CD-ROMs, DVD-ROMs and Flash Drives. Alternately, the machine-readable instructions may be loaded in a form of a computer software program into the memory unit 1042. The memory unit 1042 in that manner may be selected from a group comprising EPROM, EEPROM and Flash memory. [53] Further, the issuer device 104 includes a processor 1044 operably connected with the memory unit 1042. In various embodiments, the processor 1044 is one of, but not limited to, a general-purpose processor, an application specific integrated circuit (ASIC) and a field- programmable gate array (FPGA). The issuer device 104 includes a data interface 1046 operably connected with the processor 1044 for transmission of data between the issuer device 104 and any other external device connected with the issuer device 104, through a wired or wireless connection. In that manner, the data interface 1046 may include several ports such as a Universal Serial Bus (USB) port, an Ethernet port, a wireless communication interface, e- SATA and SCSI etc.

[54] Further connected to the network 106 is a provider device 110 associated with a provider that fulfils the obligation to the user. The provider in reference to the above example is a pharmacist and the obligation is provision of medication to the user as per the obligation document being the prescription. As another example, where the issuer is a traffic policeman, the provider may be a transport authority and the obligation is issuance of a receipt that the parking ticket has been paid for. The provider device 110 may be a portable computing device, a desktop computer or a server stack. The provider device 110 includes a memory unit 1102 configured to store machine readable instructions. The machine -readable instructions may be loaded into the memory unit 1102 from a non-transitory machine -readable medium, such as but not limited to CD-ROMs, DVD-ROMs and Flash Drives. Alternately, the machine- readable instructions may be loaded in a form of a computer software program into the memory unit 1102. The memory unit 1102 in that manner may be selected from a group comprising EPROM, EEPROM and Flash memory.

[55] Further, the provider device 110 includes a processor 1104 operably connected with the memory unit 1102. In various embodiments, the processor 1104 is one of, but not limited to, a general-purpose processor, an application specific integrated circuit (ASIC) and a field- programmable gate array (FPGA). The provider device 110 also includes a data interface 1 106 operably connected with the processor 1104 for transmission of data between the provider device 110 and any other external device connected with the provider device 110, through a wired or wireless connection. In that manner, the data interface 1106 may include several ports such as a Universal Serial Bus (USB) port, an Ethernet port, a wireless communication interface, e-SATA and SCSI etc. [56] Further connected to the network 106 is a database 108. The database 108 may be maintained on a cloud-based storage or a local storage. In several embodiments, the database 108 includes an array of databases. The database 108 may also be a distributed database, distributed along several nodes providing peer to peer functionalities. In any manner, the database 108 is envisaged to be capable of providing the data to any of the computing devices connected with the network 106 when data is queried appropriately using applicable security and other data transfer protocols.

[57] A ledger 112 is also connected to the network 106. The ledger 112 can be a distributed ledger. The term“distributed ledger” here refers to a database of transactions maintained in form of identical copies along a plurality of computing devices (or nodes) connected through a network. Whenever a new transaction is added, a record of the transaction is copied into all the copies of the database across all of the connected nodes subject to a rule-based consensus (the rule may be for example that a simple majority should verify the transaction). In this manner, even if one of the copies of the database is corrupted or tampered with, other copies on other nodes would serve to negate the effects of corruption or tampering. For the purpose of the invention, the ledger 112 includes a collection of several nodes storing identical copies of the database discussed above. The ledger 112 may be coded as a Blockchain, such as the Blockchain used in Ethereum platform.

Embodiment A

[58] Figure 2 illustrates computer-implemented method 200 for use in determining fulfilment of an obligation to a user in accordance with an embodiment of the present invention.

[59] The computer implemented method 200 depicts a scenario where a fulfilment receipt is issued by the issuer for an obligation. At step 210 the processor 1044 obtains from the data interface 1046 a first set of data in relation to the obligation. The first set of data can be the obligation document, for example, a prescription issued from a doctor to a patient. An example prescription 300 is shown in Figure 3. The example prescription 300 shown in Figure 3 includes for example, the name of the medication, dosage instruction, the patient’s contact information, the doctor’s contact information, etc. The example prescription 300 is for description purposes only and may include other information in other embodiments. The first set of data is stored in the client device 102 associated with the user. For example, the obligation document is stored in a USB drive or a mobile phone of the user. [60] At step 220, the processor 1044 performs a first hash operation on the first set of data to determine a first hash value. Further, at step 230, the processor 1044 performs a second hash operation on the first hash value to determine a second hash value. The hash operation that can be used in the present invention includes, but not limited to, CRC-16, CRC-32, MD2, MD4, MD5, SHA-256, etc.

[61] At step 240, the processor 1044 generates a first data record, as referred to as fulfilment receipt below. The first data record includes the second hash value and a fulfilment indication value. The fulfilment indication value indicates if the obligation is fulfilled or not. The first data record is used by the provider (particularly, the provider device 110) to determine fulfilment of the obligation. For that purpose, at step 250, the processor 1044 stores the first data record including the second hash value and the fulfilment indication value in the ledger 112 for use in determining fulfilment of the obligation to the user. The fulfilment indication value can be NULL or a value that is not equal to the first hash value when the fulfilment receipt is created as described above. As can be seen from the above, the first data record or the fulfilment receipt can be identified in the ledger 112 by querying the ledger 112 with the second hash value as an identifier. An example 400 of the first data record, i.e., fulfilment receipt, is shown in Figure 4. The first data record 400 includes a“Second Hash Value” field and a“Fulfilment Indication Value” field. The second hash value determined as above is stored in the“Second Hash Value” field, and the“Fulfilment Indication Value” field is initialised to be NULL, which means the obligation (i.e., the prescription 300 in this example) identified by the second hash value is not fulfilled.

[62] A method for determining fulfilment of an obligation to a user is described below with reference to Figure 5. Figure 5 illustrates a computer-implemented method 500 for determining fulfilment of an obligation to a user in accordance with an embodiment of the present invention.

[63] The user presents the first set of data to the provider, particularly, the provider device 110. For example, the patient sends the first set of data stored in the USB drive or mobile phone of the patient to the provider device 110 operated by a pharmacist. At step 510 the processor 1104 of the provider device 110 obtains from the data interface 1106 the first set of data in relation to the obligation. It should be noted that the first set of data used in method 500 is the first set of data used in method 200.

[64] At step 520, the processor 1104 performs the first hash operation used in method 200 on the first set of data to determine the first hash value. Further at step 530, the processor 1104 performs the second hash operation used in method 200 on the first hash value to determine the second hash value. At step 540, the processor 1104 identifies the first data record 400 from the ledger 112 using the second hash value as an identifier. As described above, the first data record 400 includes the second hash value and the fulfilment indication value. At step 550, the processor 1104 determines the fulfilment indication value from the first data record 400 identified, which is NULL in this example. At step 560, the processor 1104 determines if the obligation is fulfilled based on the fulfilment indication value and the first hash value. For example, if the fulfilment indication value is NULL or more generally is not equal to the first hash value, it is determined that the obligation is not fulfilled. On the other hand, if the fulfilment indication value is equal to the first hash value, it is determined that the obligation is fulfilment. If the obligation is not fulfilled, the provider will then fulfil the obligation, for example, release the medication to the patient as per the prescription 300 and replace the fulfilment indication value in the“Fulfilment Indication Value” field of the first data record 400 with the first hash value to indicate that the obligation has been fulfilled. This way, if the user presents the first set of data to the provider again, the provider will know that the obligation has been fulfilled and will not fulfil the obligation again.

[65] The use of the first hash operation and the second hash operation enables the fast generation of the second hash value and makes it extremely hard if not impossible to recover the first set of data (for example, the prescription in this example) from the second hash value due to mathematical properties of the hash operation. This effectively prevents the first set of data from being disclosed to a third party even if the third party is able to access the ledger 112. However, in the above example, the first set of data is the prescription 300 in plain text and is stored in the client device 102 (for example, a USB drive or a mobile phone) of the user, this is not secure, and the privacy of the user is not protected properly if a third party manages to access the client device 102 of the user.

Embodiment B

[66] Figure 6 illustrates an example system 600 for determining fulfilment of an obligation to a user in accordance with the present invention. Although the system 600 is described with reference to a scenario where the obligation to the user is provision of medication as per a prescription, the system 600 can also be applied to other scenarios without departing from the scope of the present invention. [67] As shown in the system 600, the patient visits the doctor for medical services. The doctor diagnoses the patients and generates the prescription 300 in a digital format at his or her device, i.e., the issuer device 104 shown in Figure 1. As an example, the digital prescription 300 can be implemented by a computer programming language, for example, JSON object. Essentially, the prescription 300 is a set of data representing the obligation. In order to enhance security of the process and make sure that privacy of the patient is protected properly, the processor 1044 of the issuer device 104 performs additional steps described below to generate the first set of data with a digital signature in relation to the provision of medication.

[68] Specifically, the processor 1044 receives from the data interface 1046 the prescription 300 (also referred to as a second set of data).

[69] The processor 1044 further receives from the data interface 1046 a public key associated with the patient. The public key associated with the patient is one of a pair of keys associated with the patient. The pair of keys include the public key and a private key. In an embodiment, the processor 1044 searches a public database for the public key of the patient or receives the public key from the user’s device.

[70] The pair of keys used in the present invention are known in the art to be asymmetric cryptographic keys and are determined using a number of algorithms, such as (Rivest-Shamir- Adleman) RSA Algorithm, Diffie Hellman Algorithm, and Elliptic Curve Cryptography (ECC) algorithms.

[71] In another embodiment, the public key of the patient can also be included in the prescription 300 when the prescription 300 is created by the issuer device 104. Therefore, upon receipt of the prescription 300 at the processor 1044, the processor 1044 receives the public key of the patient at the same time.

[72] In other embodiments, the processor 1044 may receive the public key of the patient via the data interface 1046 from other sources without departing from the scope of the invention.

[73] The processor 1044 also determines a private key associated with the doctor (i.e., the issuer). The private key associated with the doctor is one of a pair of keys associated with the doctor. The pair of keys include the private key and a public key. Particularly, the processor 1044 retrieves the private key associated with the doctor from a secure storage device that only the doctor is able to authorise the processor 1044 to access. [74] The processor 1044 applies a cryptographic process to the prescription 300 and the public key of the patient to generate a digital signature based on the private key associated with the doctor. The cryptographic process used in the present invention is for example Digital Signature Algorithm (DSA), Elliptic Curve Digital Signature Algorithm (ECDSA) and RSA.

[75] The processor 1044 then generates, at step 602, the first set of data in relation to the obligation, the first set of data including the prescription 300, the public key of the patient and the digital signature. The first set of data is also referred to as signed prescription. The signed prescription 700 is shown in Figure 7. As shown in Figure 7, the signed prescription 700 includes a“Signature” segment representing the digital signature, a“Raw” segment including the original prescription 300 and the public key of the patient.

[76] As described above with reference to method 200, the processor 1044 performs the first hash operation on the signed description 700 at step 608 to determine the first hash value, i.e., the Pre-digest in Figure 6. The processor 1044 also performs at step 610 the second hash operation on the Pre-digest to determine the second hash value, i.e., Post-digest in Figure 6. At step 640, the processor 1044 further generates the first data record 400 (i.e., the fulfilment receipt) including the second hash value and the fulfilment indication value. The processor 1044 stores the first data record 400 (i.e., fulfilment receipt) including the second hash value and the fulfilment indication value in the ledger 112 for use in determining fulfilment of the obligation to the user.

[77] At step 611, an encryption key, i.e., One-Time-Password (OTP), is generated by the issuer device 104. An example of the OTP is as follows:

{

"key":

"0xlaf833d6fd3ce7cl9l8ce4df6cb5ec956b25755440004b240fa8e4f3e d3d4a39", "iv": "0x8b2c66bc0f2edee3c0b85 l253892lcef6e33de5efc59505c"

}

[78] At step 612, the processor 1044 encrypts the signed prescription 700 (i.e., the first set of data) using the encryption key (i.e., OTP). As a result, a first encrypted set of data, i.e., “Blob” in Figure 6 is determined. The encryption algorithm used here is for example AES256- GCM. Figure 8 illustrates an exemplary first encrypted set of data (i.e., Blob) 800 in accordance with an embodiment of the present invention. [79] The processor 1044 generates a second data record that associates the encryption key with the first encrypted set of data. The second data record is also referred to as prescription note. The processor 1044 sends via the data interface 1046 the prescription note to the client device 102 associated with the patient to store the prescription note. The client device 102 can be for example a USB drive or a mobile phone of the patient.

[80] Upon receipt of the prescription note at the client device 102, the patient presents the prescription note stored in the client device 102 to the pharmacist (particularly, the provider device 110 in order for the pharmacist to determine the fulfilment of the prescription to the user. However, as shown in Figure 8, Blob 800 is a very long alphanumeric string, it will use the limited storage space of the client device 102 if stored on the client device 102, which may be the mobile phone of the patient with a limited memory space. Therefore, at step 614, the processor 1044 performs a third hash option on the first encrypted set of data 800, i.e., Blob, to determine a third hash value as a reference to Blob, i.e. Blob-ref in Figure 6. Figure 9 illustrates an example of the third hash value 900. As shown in Figure 9, the third hash value 900 (i.e., Blob-ref) is much shorter than the first encrypted set of data 800.

[81] At step 622, the processor 1044 stores the encryption key (i.e, OTP) and the third hash value 900 (i.e., Blob-ref) instead of Blob 800 in the prescription note (i.e., the second data record) to associate the encryption key with the third hash value 800 (i.e., Blob-ref). Figure 10 illustrates an exemplary prescription note 1000 in accordance with an embodiment of the present invention. The prescription note 1000 includes an“OTP” segment containing the encryption key and a“Blob-ref’ segment containing the third hash value 800 (i.e., Blob-ref), and only needs a relatively small memory space to be stored. The patient presents the prescription note 1000 to the pharmacist to fulfil the prescription.

[82] At step 603, the client device 102 used by the patient determines a sequence number for the prescription 300 based on the private key of the patient. For example, the client device 102 obtains the private key of the patient with authorisation from the patient and performs a hash operation on the private key of the patient to determine a hash value as the sequence number of the prescription. The client device 102 also sends the sequence number to the issuer device 104, and the issuer device 104 receives the sequence number from the client device 102. When a subsequent prescription is created, the client device 102 performs a hash operation on the sequence number to determine a further sequence number for the subsequent prescription. This way, the client device 102 is able to determine a series of sequence numbers for prescriptions created for the patient, and all the sequence numbers based on the private key of the patient.

[83] At step 604, the processor 1044 encrypts the signed prescription 700, i.e., the first set of data, using the public key of the patient. The algorithm used for encryption may be for example Elliptic Curve Integrated Encryption Scheme (ECIES). The result of the encryption is a second encrypted set of data, also referred to as Myblob in Figure 6. Figure 11 illustrates the second encrypted set of data 1100, i.e., Myblob, in accordance with an embodiment of the present invention. The processor 1044 generates a third data record and stores the sequence number and the second encrypted set of data 1100 in the third data record. The third data record is also referred to as my issuance receipt in Figure 6. The processor 1044 further stores the third data record in the ledger 112.

[84] However, as shown in Figure 11, the Myblob is also a very long alphanumeric string, this means storing the third data record in the ledger 112 will use a relatively large memory space especially when there are millions of third data records to be stored in the ledger 112. Therefore, at step 606, the processor 1044 performs a fourth hash operation on the second encrypted set of data 1100, i.e., Myblob, to determine a fourth hash value, i.e., Myblog-ref in Figure 6, as a reference to the second encrypted set of data 1100. Myblog-ref is much shorter than Myblof as a result of the hash operation. At step 616, the processor 1044 stores the sequence number and the fourth hash value (i.e., Myblob-ref) in the third data record in order for them to be associated with each other. The third data record (i.e., my issuance receipt) is for the patient to identify in the ledger 112 the prescription(s) issued to the patient.

[85] At step 618, the processor 1044 generates a fourth data record, and stores the second hash value (i.e., Post-digest in Figure 6) and the third hash value 900 (i.e., Blob-ref) in the fourth data record in order for them to be associated with each other. The processor 1044 further stores the fourth data record in the ledger 112. The fourth data record is also referred to as issuance receipt. The fourth data record (i.e., issuance receipt) is for the doctor to identify in the ledger 112 the prescription(s) issued from the doctor.

[86] At step 620, the processor 1044 generates a fifth data record and stores the first encrypted set of data 800 (i.e., Blob), the third hash value 900 (i.e., Blob-ref), the second encrypted set of data 1100 (i.e., MyBlob) and the fourth hash value (i.e., Myblob-ref) in the fifth data record. The processor 1044 further stores the fifth data record in a database 108. Therefore, the third hash value 900 (i.e., Blob-ref) or the fourth hash value (i.e., Myblob-ref) acts as an index to locate the fifth data record in the database 108 in determining if the obligation is fulfilled or not.

[87] At step 624, the patient presents the prescription note 1000 to the pharmacist, particularly, the provider device 110. For example, if the prescription note 1000 is stored on the patient’s client device 102, the patient sends the prescription note 1000 from the client device 102 to the provider device 110 via an email, SMS message, etc. The provider device 110, more specifically, the processor 1104, receives the prescription note 1000 from the client device 102.

[88] As described above, in one example, the prescription note 1000 (i.e. the second data record) includes the encryption key (i.e., OTP) and the first set encrypted set of data 800 (i.e., Blob), which is generated by encrypting the first set of data 700 (i.e., the signed prescription) using the encryption key. In this case, the processor 1104 directly extracts from the prescription note 1000 the first encrypted set of data 800 (i.e., Blob) and the encryption key. The processor 1104 further decrypts at step 630 the first encrypted set of data 800 (i.e., Blob) using the encryption key to determine the first set of data 700 (i.e., the signed prescription).

[89] In another example, the prescription note 1000 (i.e . the second data record) includes the encryption key (i.e., OTP) and the third hash value 900 (i.e., Blob-ref), as shown in Figure 10. As described above, the third hash value 900 (i.e., Blob-ref) is generated by performing the third hash operation on the first encrypted set of data 800 (i.e., Blob). In this case, the processor 1104 extracts from the prescription note 1000 the third hash value 900 (i.e., Blob-ref) and the encryption key (i.e., OTP). At step 628, the processor 1104 searches the database 108 by the third hash value 900 (i.e., Blob-ref) to identify from the database 108 a target data record that associates the third hash value 900 (i.e., Blob-ref) and the first encrypted set of data 800 (i.e., Blob). The target data record is the fifth data record described above with reference to step 620. The processor 1104 determines the first encrypted set of data 800 (i.e., Blob) from the target data record, and decrypts at step 630 the first encrypted set of data 800 (i.e., Blob) using the encryption key (i.e., OTP) to determine the first set of data 700 (i.e., the signed prescription). As a result, the processor 1104 obtains via the data interface 1106 the first set of data 700.

[90] As described above and shown in Figure 7, the first set of data 700 includes the second set of data 300 representing the prescription as shown in Figure 3, the digital signature associated with the doctor and the public key associated with the patient. [91] As described with reference to method 500, the processor 1104 performs at step 634 the first hash operation on the first set of data 700 to determine the first hash value (i.e., Pre digest). The processor 1104 further performs the second hash operation (not shown in Figure 6) on the first hash value (i.e., Pre-digest) to determine the second hash value (i.e., Post-digest). The processor 1104 identifies from the ledger 112 the first data record 400 (i.e., fulfilment receipt) including the second hash value and a fulfilment indication value. The processor 1104 determines the fulfilment indication value from the first data record 400 and determines if the obligation is fulfilled based on the fulfilment indication value and the first hash value (i.e., Pre digest).

[92] Specifically, if the processor 1104 determines that the fulfilment indication value is equal to the first hash value (i.e., Pre-digest), the processor 1104 generates a first indication indicating the obligation is fulfilled. The first indication can be for example a first message to the pharmacist that is operating the provide device 110 prompting that the prescription has been fulfilled previously. As a result of the message, the pharmacist will not release the medication to the patient. On the other hand, if the fulfilment indication value is not equal to the first hash value, for example, the fulfilment indication value is NULL, the processor 1104 generates a second indication to fulfil the obligation. The second indication can be for example a second message to the pharmacist prompting that the prescription has not been fulfilled and needs to be fulfilled. At the same time, the prescription is also displayed on a display of the provider device 110. In response to the second message, the pharmacist releases the medication to the patient as per the prescription displayed. Once the medication is released to the patient, the pharmacist inputs a third indication to the provide device 110 via the data interface 1106 (for example, a keyboard, a computer mouse, a touch screen, a voice input unit, etc.) of the provider device 110. The third indication indicates that the prescription has been fulfilled. The processors 1104 receives from the data interface 1106 the third indication. In response to receipt of the third indication, the processor 1104 replaces the fulfilment indication value (initially, NULL) in the first data record 400 (i.e., fulfilment receipt) with the first hash value (i.e., Pre-digest) to indicate that the obligation is fulfilled. This way, if the patient presents the same prescription note to the same or a different pharmacist again, the provider device 110 of the pharmacist will recognise that the prescription 300 associated with the prescription note has been fulfilment previously, and the pharmacist will not release the medication to the patient again. Also, as the prescription note only includes the encrypted prescription as shown in Figure 8 or its hash value as shown in Figure 9 instead of the original prescription 300, even if the prescription note is accessed by an unauthorised third party, the third party is not able to know what the original prescription 300 is. This effectively protects privacy of the patient.

[93] To further enhance security of the system 600, the following steps are also performed by the provider device 110 to verity that the prescription is prescribed to the patient by the doctor before releasing the medication to the patient.

[94] At step 623, the processor 1104 of the provider device 110 determines a digital challenge, i.e., challenge nonce in Figure 6. Figure 12 illustrates an exemplary digital challenge 1200 in accordance with an embodiment of the present invention. The digital challenge 1200 includes a“Signature” segment to contain a digital signature, and a“Nonce” segment to contain a random alphanumeric string. The processor 1104 sends the digital challenge 1200 to the client device 102 associated with the patient for the client device 102 to generate a response based on the private key associated with the patient and the digital challenge 1200. In this example, the digital signature contained in the“Signature” segment of the digital challenge 1200 is a digital signature of the random alphanumeric string, which is generated by the pharmacist, particularly, the provider device 110. However, in other examples, the digital challenge 1200 may only include the“Nonce” segment containing the random alphanumeric string without the “Signature” segment.

[95] There are different ways of generating the response, an example is described here for description purposes only. For example, upon receipt of the digital challenge 1200 at the client device 102, the client device 102 flips the last 4 digits of the alphanumeric string in the“Nonce” segment to determine a new alphanumeric string. Further, the client device 102 generates a digital signature of the new alphanumeric string with the private key of the patient using a digital signature algorithm, e.g., Elliptic Curve Digital Signature Algorithm (ECDSA). This way, the client device 102 generates a response including the new alphanumeric string and the digital signature of the new alphanumeric string. Figure 13 illustrates an exemplary response 1300 to the digital challenge 1200 in accordance with an embodiment of the present invention. As shown in Figure 13, the response 1300 includes a“Nonce” segment to contain the new alphanumeric string and a“Signature” segment to contain the digital signature of the new alphanumeric string.

[96] The client device 102 sends the response 1300 to the provider device 110 and the processor 1104 of the provider device 110 receives the response 1300 from the client device 102 [97] The processor 1 104 also extracts the public key of the patient from the first set of data 700 (i.e., the signed prescription) obtained at step 630. The processor 1104 verifies, based on the digital challenge 1200 and the public key associated with the patient, that the response 1300 is generated using the private key associated with the patient. Specifically, the processor 1104 flips the last four digits of the alphanumeric string in the response 1300 and determines if the resulting alphanumeric string is the same as the original alphanumeric string in the digital challenge 1200. Also, the processor 1104 uses the public key of the patient to determine if the digital signature of the alphanumeric string in the“Nonce” segment of the response 1300 is generated by the private key of the patient. For example, the processor 1104 applies a digital signature algorithm, e.g., Elliptic Curve Digital Signature Algorithm (ECDSA) to verify that the digital signature of the alphanumeric string in the“Nonce” segment of the response 1300 is generated by using a key corresponding to the public key of the patient, namely, the private key of the patient, which only the patient has access to. If both conditions are met, i.e., the resulting alphanumeric string is the same as original string in the digital challenge 1200 and the digital signature of the alphanumeric string in the“Nonce” segment of the response 1300 is generated by the private key of the patient, it is determined that that the prescription is prescribed to the patient. As a result, the processor 1104 generates at step 625 a message (i.e., Patent identity receipt in Figure 6) to indicate that the identity of the patient is verified. This effectively prevents an unauthorised party from using the prescription note 100 of the patient to obtain the medication from the pharmacist because the unauthorised party does not have the private key of the patient to correctly respond to the digital challenge 1200. In other words, the digital response generated by the unauthorised party will not be verified by the pharmacist.

[98] At step 636, the processor 1104 receives from the data interface 1106 the public key associated with the doctor (i.e., the issuer). For example, the processor 1104 searches a public key database for the pubic key of the doctor by the doctor’s contact information contained in the first set of data 700 (i.e., the signed prescription) obtained at step 630. The processor 1104 extracts from the first set of data 700 (i.e., the signed prescription) the digital signature contained in the“Signature” segment of the first set of data 700 (i.e., the signed prescription). The processor 1104 also extracts from the first set of data 700 (i.e., the signed prescription) the second set of data 300 (i.e., the prescription) representing the obligation and the public key associated with the patient.

[99] Then the processor 1104 verifies, based on the second set of data 300 (i.e., the prescription) and the public key associated with the doctor, that the digital signature is generated by applying the cryptographic process to the second set of data 300 (i.e., the prescription) and the public key associated with the patient based on the private key associated with the doctor. For example, the processor 1104 applies Digital Signature Algorithm (DSA) or Elliptic Curve Digital Signature Algorithm (ECDSA) or RSA to verify that the digital signature in the signed prescription 700 is generated by using a key corresponding to the public key of the doctor, namely, the private key of the doctor, which only the doctor has access to. This means that the prescription 300 is prescribed by the doctor.

[100] The person skilled in the art of the cryptography would understand in light of the above description how the public -private key pair verification/mateh process is performed. Once it is verified that the prescription is prescribed to the patient by the doctor, the processor 1104 proceeds to determine if the prescription is fulfilled or not, as described above with reference to step 634.

Smart Contract

[101] The system 100 or 600 may be implemented using smart contract capabilities in a Blockchain-based platform, for example, Ethereum. The fulfilment receipt 400 (i.e., the first data record) of a prescription that involves the doctor, the patient and the pharmacist (or more generally, the issuer, the user and the provider, respectively) are represented by three state variables in a smart contract, as depicted in Table 1. As described above, the fulfilment receipt 400 can be identified on the Blockchain using the second hash value, i.e., the Post-digest. The three state variables here are “ issued ^r “ location” and ‘ fulfilment indication value”. Combinations of the values of the state variables represent different state of the prescription.

[102] “Issued” is a Boolean and indicates whether the prescription or the obligation document has been issued or not.

[103] “ Location” represents the location of the first set encrypted set of data 800, i.e., Blob, in the database 108. Therefore,“ Location” is the third hash value 900 (i.e., Blob-ref) of Blob 800.

[104] “fulfilment indication value” represents whether the obligation has been fulfilled or not.

Table 1

[105] At the start of a transaction, the value of the“ issue ’ is“false”, the value of the “ location” is NULL and the value of the“ulfilment indication value” is NULL. In this case, the doctor generates a prescription (and thus the prescription note). Once the prescription (or the prescription note) is issued by the doctor, the processor 1044 of the issuer device 104 changes the value of“ issued” from“false” to“true” and the value of location from NULL to blob-ref (or the third hash value) 900. In that manner, the first set encrypted set of data 800, i.e., Blob, can be accessed using the blob-ref (or the third hash value) 900.

[106] When the patient approaches the pharmacist, the provider device 110, or the processor 1104 identifies the fulfilment receipt 400 on the Blockchain using the second hash value, i.e., Post-digest. The processor 1104 checks for the values of the three state variables. In that manner, the prescription 300 would be fulfilled only when the value of“issued” is true, the value of“ location” is blob-ref and the value of‘ fulfilment indication value” is NULL. If the value of‘ fulfilment indication value” is not NULL, particularly, if it is equal to the first hash value (i.e., Pre-digest) it means that the prescription 300 (or the obligation) has been fulfilled previously. In this case, the pharmacist will not provide the medication to the patient again. Once satisfied that the obligation has not been fulfilled, the pharmacist fulfils the prescription 300 by providing medication to the patient. The processor 1104 also changes the value of “fulfilment indication value” from NULL to the first hash value, i.e., Pre-digest, to indicate that the prescription 300 has been fulfilled.

[107] It should be understood that the techniques of the present disclosure might be implemented using a variety of technologies. For example, the methods described herein may be implemented by a series of computer executable instructions residing on a suitable computer readable medium. Suitable computer readable media may include volatile (e.g. RAM) and/or non-volatile (e.g. ROM, disk) memory, carrier waves and transmission media. Exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data steams along a local network or a publically accessible network such as the Internet. [108] It should also be understood that, unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "controlling" or "obtaining" or "computing" or "storing" or "receiving" or "determining" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that processes and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer · system memories or registers or other such information storage, transmission or display devices.