Smart contract, service controlled by voice commands, and user device

Abstract

The present disclosure proposes a concept where a smart contract receives a transaction related to at least one voice command from a user device. The received transaction comprises the voice command and a user device identifier. The smart contract searches, in a blockchain network, for an already registered transaction related to the same voice command, but having an older timestamp than the received transaction. In case of a negative search result, the smart contract registers the received transaction with its associated timestamp in the blockchain network. A Service Controlled By Voice Commands (SCBVC) receives an encrypted message comprising the voice command(s) from the user device. The encrypted message further comprises information on a timestamp associated with the voice command(s) and a user device identifier. The SCBVC decrypts the received encrypted message and verifies the decrypted message based on searching for a transaction related to the voice command(s) and registered on the blockchain network by the smart contract.

Description

[0001] SMART CONTRACT, SERVICE CONTROLLED BY VOICE COMMANDS,

[0002] AND USER DEVICE

[0003] Field

[0004] The present disclosure generally relates to the field of smart contracts, and, more particularly, to smart contracts for anti-replay testing and ensuring that a device or service only accepts voice input from authorized persons.

[0005] Background

[0006] When a user is successfully authorized to use a personal user device or service, input may be provided in a discrete manner such as typing commands. Sometimes, also voice or verbal commands can be an option. This makes sense for visually impaired people or people wearing Virtual Reality (VR) headsets, for example.

[0007] A problem with verbal commands is that anybody can hear them and repeat them against the user device or the service authorized for the user. Once the user device or service becomes operational, there is little that may be done to prevent unauthorized people from giving verbal commands themselves alongside the authorized user. Even in case some voice biometric security is in place, a replay of recorded commands could still be used.

[0008] Thus, there is a demand for means that allow recognizing fraudulent or unauthorized voice input.

[0009] Summary

[0010] This demand is addressed by methods and apparatuses in accordance with the appended claims.

[0011] According to a first aspect, the present disclosure provides a method for a smart contract deployed on a blockchain network. The method may be a computer-implemented method. A smart contract may be understood a self-executing contract with terms of an agreement between two parties directly written into lines of computer-executable code. The code and the agreements contained in the smart contract may exist across a distributed, decentralized blockchain network. Smart contracts may permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. They may render transactions traceable, transparent, and irreversible. Each party involved in a smart contract agrees to the terms encoded in the contract. When predefined conditions are met, the contract may automatically enforce and execute the agreed-upon terms. An example platform for implementing smart contracts is the Ethereum blockchain, which was specifically created to support such applications by including a robust programming language. However, other blockchain platforms may also support smart contracts.

[0012] A blockchain is a distributed database or ledger that is shared among nodes of a computer network. As a database, a blockchain stores information electronically in digital format. A key feature is its structure; it organizes data into blocks, which are then linked together in a chain through cryptographic principles, hence the name "blockchain."

[0013] The proposed method includes the smart contract (e.g., being executed on a Virtual Machine of the blockchain network) receiving a transaction (or request) related to a voice command from a user device. A smart contract transaction may refer to a process of executing the terms of the smart contract on the blockchain network. The voice command from the user device may refer to an instruction or command that a user gives to a device (e.g., smartphone, tablet PC, wearable, smart TV, etc.) using their voice.

[0014] The received transaction comprises information on the voice command and a user device identifier (user device ID). The voice command may be in audio format or text format after a speech-to-text conversion, for example. The user device ID may be a unique alphanumeric string associated with the user device (e.g., mobile device or any other electronic device). It serves as a means to identify the user device distinctively on a network or within systems.

[0015] Optionally, the received transaction may comprise a session identifier (session ID) associated with the voice command. The session ID may be a unique piece of data that the user device may generate to identify a specific user's voice command session. A voice command session may be a time period during which a user is authenticated with the user device or a Service Controlled By Voice Commands (SCBVC), for example. The session ID may improve identifying and / or searching for registered transactions.

[0016] Further optionally, the received transaction may comprise a hash of the voice command, a hash of the user device ID, and / or a hash of both the voice command and the user device ID. A hash may be understood as a function that converts an input (e.g., voice command, user device ID, voice command + user device ID) into a fixed-size string of bytes. The output, typically a 'digest', represents virtually any amount of (input) data in a unique way. The optional hash(es) may improve user privacy.

[0017] The proposed method further includes searching, in the blockchain network, for an already registered transaction related to the same voice command but having an older timestamp than the received transaction. Optionally, the proposed method includes searching, in the blockchain network, for an already registered transaction having the same session ID and the same hash, but an older timestamp than the (newly) received transaction. In case of a negative search result (i.e., no already registered transaction related to the same voice command (e.g., having the same session ID and the same hash) but with an older timestamp than the received transaction), the proposed method further includes the smart contract registering the (newly) received transaction with its associated timestamp in the blockchain network. Registering the (newly) received transaction may comprise selecting the transaction from a transaction pool and form it into a new block. In the case of smart contract transactions, this may include executing the smart contract code within the context of the blockchain's virtual machine (e.g., Ethereum Virtual Machine for Ethereum). This execution may change the state stored in the blockchain based on the logic of the smart contract. The newly created block, containing the transaction and its resulting state change, may be proposed to the blockchain network. The network nodes may reach consensus according to the blockchain's protocol, validating the block and adding it to the blockchain.

[0018] In case of a positive search result (i.e., previously registered transaction having the same session ID and the same hash, but an older timestamp than the (newly) received transaction), the method may further include issuing some sort of alert message to the user device and / or a Service Controlled By Voice Commands (SCBVC). SCBVC may be understood as a tech- nology that allows users to interact with devices, applications, or systems through spoken commands rather than traditional input methods like typing or clicking.

[0019] In some embodiments, the received transaction or a part thereof is signed with the private key of the user device. For example, as part of the transaction, the user device ID may comprise a signature of a data blob composed of a timestamp of the voice command, the session ID, and the voice command. The signature may verify that the transaction or the part thereof was created by the rightful owner of the private key, effectively proving the identity of the sender without revealing the private key itself. Signing the transaction or the part thereof with the private key may also ensure that the transaction cannot be altered by anyone else after it has been signed. If any part of the transaction were changed after signing, the digital signature would no longer be valid, and the network may reject the transaction.

[0020] Once the transaction is verified, it can be included in a block of the blockchain network. When the block is added to the blockchain, smart contract execution may be triggered according to the transaction's instructions, and the result may be recorded on the blockchain. Thus, in some embodiments, the smart contract registering the received transaction comprises including the received transaction with its associated timestamp in a block of the blockchain network.

[0021] According to a further aspect, the present disclosure provides an apparatus for a smart contract deployed on a blockchain network. The apparatus comprises processing circuitry configured to

[0022] - receive a transaction related to a voice command from a user device, the received transaction comprising information on the voice command and a user device identifier,

[0023] - search, in the blockchain network, for an already registered transaction related to the same voice command but having an older timestamp than the received transaction, and

[0024] - in case of a negative search result, register the received transaction with its associated timestamp in the blockchain network.

[0025] The information on the voice command and the user device ID may include a session ID associated with the voice command and / or a hash of both the voice command and the user device ID, for example. The skilled person having benefit from the present disclosure will appreciate that the apparatus and / or the processing circuitry may be a single hardware entity or a distributed hardware infrastructure of a blockchain network. This network may comprise numerous com- puters / servers, often referred to as nodes, which may be spread across different locations globally. Each node in the blockchain network may contribute to the execution and verification of the smart contract by running the blockchain's software.

[0026] According to a further aspect, the present disclosure provides a method for a SCBVC. The method may be a computer-implemented method. As mentioned before, the SCBVC may be understood as a technology or service that allows users to interact with devices, applications, or systems through spoken commands rather than traditional input methods like typing or clicking.

[0027] The proposed method includes receiving an encrypted message comprising a voice command from a user device (e.g., smartphone, tablet PC, wearable, smart TV, etc.). The voice command may be in audio format or in text format (e.g., speech-to-text converted), for example. The encrypted message further comprises information on a timestamp associated with the voice command, and a user device ID. Optionally, the encrypted message comprises information on a session ID associated with the voice command, the timestamp associated with the voice command, and the user device ID. For example, the user device ID may comprise a signature of a data blob composed of a timestamp of the voice command, the session ID (optionally), and the voice command. The proposed method includes decrypting the received encrypted message and verifying the decrypted message based on searching for a transaction related to the voice command and registered on a blockchain network by a smart contract deployed on the blockchain network.

[0028] In some embodiments, the encrypted message is encrypted based on a public key of a Decentralized Identifier (DID) of the SCBVC. A DID is a type of identifier that enables a verifiable, self-sovereign identity that does not rely on a centralized authority or intermediary for verification or authentication. DIDs are stored on decentralized networks, such as blockchains or distributed ledgers, ensuring no single point of failure or control. DIDs are designed to be verifiable. They may use cryptographic proofs that allow others to verify the authenticity of the DID and the integrity of the information associated with it. A DID typically comprises a unique identifier that is linked to a DID document. This document contains the metadata necessary to interact with the DID, such as cryptographic keys, authentication protocols, and service endpoints for communication. The DID document is what enables the secure and verifiable interactions that are central to the concept of decentralized identity.

[0029] In some embodiments, the encrypted message is decrypted (at the SCBVC) using the private key of the SCB VC’s DID.

[0030] In some embodiments, searching for the transaction related to the voice command comprises searching for a registered transaction on the blockchain network having the same session ID, the same hash of both the voice command and the user device ID, and having the timestamp of the voice command.

[0031] In some embodiments, verifying the decrypted message comprises comparing a hash associated with the decrypted message with a hash associated with the registered transaction.

[0032] In some embodiments, the proposed method further includes executing the voice command if the decrypted message is successfully verified.

[0033] According to a further aspect, the present disclosure provides an apparatus for a SCBVC.

[0034] The apparatus comprises processing circuitry configured to

[0035] - receive an encrypted message comprising a voice command from a user device, the encrypted message further comprising information on a timestamp associated with the voice command and a user device identifier (and optionally on a session identifier associated with the voice command),

[0036] - decrypt the received encrypted message, and

[0037] - verify the decrypted message based on searching for a transaction related to the voice command and registered on a blockchain network by a smart contract deployed on the blockchain network.

[0038] The skilled person having benefit from the present disclosure will appreciate that the apparatus and / or the processing circuitry may be a single hardware entity (computer / server) or a distributed hardware infrastructure. According to a further aspect, the present disclosure provides a method for a user device. The method may be a computer-implemented method. The proposed method includes send- ing / transmitting a transaction related to a voice command from the user device to a smart contract deployed on a blockchain network. The transmitted transaction comprises information on the voice command and a user device ID. The proposed method further includes sending an encrypted message comprising the voice command from the user device to the SCBVC. The encrypted message further comprises information on a timestamp of the voice command and the user device ID.

[0039] In some embodiments, the transaction and the encrypted message further comprise a session ID associated with the voice command.

[0040] In some embodiments, the transaction further comprises a hash of the voice command and the user device ID.

[0041] In some embodiments, the proposed method further comprises signing the transaction with the private key of the user device before sending the transaction to the smart contract.

[0042] In some embodiments, the proposed method further comprises encrypting the message using a public key of a DID of the SCBVC before sending it to the SCBVC.

[0043] In some embodiments, the proposed method further comprises authenticating a user to the user device based on biometric authentication. Common types of biometric authentication may include fingerprint recognition, facial recognition, iris recognition, or voice recognition, for example.

[0044] In some embodiments, the proposed method further comprises recording the voice command of the authenticated user and converting the recorded voice command from voice to text before sending the transaction to the to the smart contract.

[0045] According to a further aspect, the present disclosure provides a user device (e.g., smartphone, tablet PC, wearable, smart TV, etc.) comprising processing circuitry configured to - send a transaction related to a voice command from the user device to a smart contract deployed on a blockchain network, the transaction comprising information on the voice command and a user device ID; and

[0046] - send an encrypted message comprising the voice command from the user device to the SCBVC, the encrypted message further comprising information on a timestamp of the voice command, and the user device ID.

[0047] Brief description of the Figures

[0048] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

[0049] Fig. 1 schematically shows an overview of system according to an embodiment of the present disclosure;

[0050] Fig. 2 illustrates a flowchart of a method for a user device;

[0051] Fig. 3 illustrates a flowchart of a method 300 for a smart contract; and

[0052] Fig. 4 illustrates a flowchart of a method for an SCBVC.

[0053] Detailed Description

[0054] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

[0055] Throughout the description of the figures same or similar reference numerals refer to same or similar elements and / or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification. When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.

[0056] If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0057] A high-level finding of the proposed concept is that a user device (e.g., a wearable) associated with a user may transform the user’s vocal commands to an encrypted signal that is then sent to a targeted service controlled by voice commands (SCBVC). The user device is authorized by the user to do this and the user device is able to “connect” with the target service (in case there are multiple potential target services in the vicinity). The SCBVC may register its public DID on a blockchain so anybody or anything can look it up by its public DID. This may also provide access to the corresponding DID document holding public keys that can be used to verify digital signatures from the SCBVC and / or to encrypt data that only the SCBVC can decrypt. The SCBVC has access to the same blockchain as the user device. The user may authenticate to his / her user device through various existing biometric authentication methods and the user device may be temper-proof. The user device may process and encrypt the vocal commands from the user only. The encrypted commands may then be sent to a smart contract on a blockchain for anti-replay testing and transaction storing. The SCBVC can decrypt the commands and check the blockchain for validness.

[0058] More details of proposed concept and the involved entities will be described in more detail in the following. Fig. 1 schematically shows an overview of system 100 according to an embodiment of the present disclosure. System 100 comprises at least one user device 110, a smart contract 120 deployed on a blockchain network 122, and at least one server hosting a SCBVC 130.

[0059] User device 110 is associated with user 112. User device 110 is an electronic device configured to capture voice commands of user 112. Examples of such devices include smartphones and tablets. Virtually all modem smartphones and tablets come equipped with built-in voice assistants. Users can activate these assistants with a voice command to make calls, send messages, set reminders, and more. As another example, smart speakers may be designed primarily for voice interaction. They can play music, provide news updates, control smart home devices, and assist with a wide range of queries and commands. As another example, wearable devices, such as smartwatches and fitness trackers, may allow users to use voice commands to send texts, make calls, set reminders, and access various functionalities without needing to use their smartphones. As another example, laptops and desktops may support voice commands through digital assistants. As another example, smart home devices like thermostats, lights, and security cameras can be controlled via voice commands through integration with broader smart home ecosystems supported by SCBVC 130. As another example, many modern vehicles come equipped with voice-controlled infotainment systems that allow drivers to navigate, make calls, send messages, and control media playback without taking their hands off the wheel. Some smart TVs and streaming devices come with remote controls that have built-in microphones for voice commands, enabling users to search for content, control playback, and even manage smart home devices through the TV.

[0060] User device 110 may capture one or more voice commands 114 for the SCBVC 130 through microphones, process the voice command(s) 114 either locally or on a remote server (depending on the device and the complexity of the command), and execute a corresponding action, providing user 112 with an efficient and often hands-free way to interact with technology.

[0061] Before capturing the voice command(s) 114, user device 110 may be configured to authenticate user 112, for example, based on biometric authentication, such as iris-scan, fingerprint, walking-behavior, etc. Once authorized, user 112 may use user device 110 to capture and process his / her voice commands 114. For capturing one or more voice commands 114, user device 110 may be configured to initiate a related voice command session. The voice command session may refer to a temporary and interactive information exchange between user device 110 (or user) and SCBVC 130. It may begin when the voice command(s) 114 is initiated and may end when the voice command^) 114 is terminated. User device 110 may assign a unique session ID to each voice command session of the user. Depending on the use case, a voice command session may only last for as long as the voice command(s) (usually a few seconds), or it may cover a predetermined time frame, etc. The voice command session may last as long as user 112 is authenticated with user device 110, for example.

[0062] User device 110 is further configured to assign a timestamp to one or more captured voice commands 114 or assign the timestamp to the related voice command session. The timestamp may be a sequence of characters or encoded information identifying when the voice command (session) started or ended, usually giving date and time of day, sometimes accurate to a small fraction of a second. The timestamps can be represented in various formats, such as Coordinated Universal Time (UTC), local time zones, or Unix time (the number of seconds that have elapsed since the Unix epoch, 00:00:00 UTC on 1 January 1970, not counting leap seconds).

[0063] For example, user device 110 may connect to the server hosting the SCBVC 130 using an internet connection to access the SCBVC’s public key(s). Organizations or services may publish their DID or a link to their DID document on their official website, particularly on pages dedicated to privacy policy, contact information, or blockchain initiatives. If a DID method used by the SCBVC is associated with a specific blockchain, blockchain explorers may be used that support DIDs (e.g., DID of user device 110) to search for transactions related to the company's DID As such, the SCBVC’s public DID may be found on an identity blockchain together with the accompanying DID document that holds the SCBVC’s public key(s). The skilled person having benefit from the present disclosure will appreciate that there may be many other ways of obtaining the SCBVC’s public key(s).

[0064] User device 110 is further configured to encrypt a message containing the user’s captured voice command using the public key of the SCBVC. This encryption may involve creating a data blob (timestampSessionldCommands) including the timestamp of the voice com- mand(s), the session ID, and the related voice command(s). The term "blob" stands for Binary Large Object and may refer to a collection of binary data stored as a single entity. Blobs may be used to store data such as images, audio files, multimedia objects, and executable code that do not fit naturally into traditional database fields. User device 110 may further sign the data blob composed of the timestamp, the session ID, and the related voice command^) using the user device’s 110 private key. The private key may be a built-in private key, for example. The signature of the data blob may be referred to as deviceSigna- ture timestampSessionldCommands. The signature may act as user device ID and verify that the data blob was created by the rightful owner of the private key, effectively proving the identity of user device 110 without revealing the private key itself. Signing the data blob with the private key may also ensure that the data blob cannot be altered by anyone else after it has been signed. If any part of the data blob were changed after signing, the digital signature (user device ID) would no longer be valid. The skilled person having benefit from the present disclosure will appreciate that also differently created user device IDs may be used.

[0065] The encryption of the message at user device 110 may further involve encrypting the timestamp, the session ID, the related voice command(s), and the user device ID (deviceSig- nature timestampSessionldCommands) with the public key of the SCBVC according to

[0066] E(timestamp, sessionld, commands, deviceSignature timestampSessionldCommands), where E(.) denotes the encryption.

[0067] This encrypted message may then be sent from user device 110 to SCBVC 130.

[0068] User device 110 may be further configured to generate and send a transaction 118 related to the voice command(s) from the user device 110 to the smart contract 120 deployed on the blockchain network 122. The smart contract 120 may be accessed by both the user device 110 and SCBVC 130. The transaction 118 sent from user device 110 to the smart contract 120 may comprise the session ID associated with the voice command(s), and a hash of both the user device ID (deviceSignature timestampSessionldCommands) and the voice command^). That is, the transaction 118 may comprise sessionld + H(deviceSignature_timestampSessionIdCommands, commands), where H(.) denotes the hash. The skilled person having benefit from the present disclosure will appreciate that the session ID and the hash may be beneficial but not necessary for the working principle of the present disclosure. Further, transaction 118 may have associated therewith a transaction timestamp which may be essentially equivalent to the timestamp of the voice command(s).

[0069] The smart contract 120 (e.g., being executed on a Virtual Machine of the blockchain network) receives the transaction 118 related to the voice command(s) from user device 110. Upon receipt of the transaction 118, the smart contract 120 searches, in the blockchain network 122, for an already registered (previous) transaction having the same session ID and the same hash (e.g., H(deviceSignature_timestampSessionIdCommands, commands)), but an older transaction timestamp than the (newly) received transaction 118. In case of a negative search result (i.e., no registered transaction is found having the same session ID and the same hash, but an older transaction timestamp), the smart contract 120 registers the (newly) received transaction 118 with its associated transaction timestamp in the blockchain network. Every transaction is typically associated with a timestamp. This timestamp records when the transaction was added to the blockchain 122.

[0070] However, in case of a positive search result (i.e., previously registered transaction is found having the same session ID and the same hash, but an older transaction timestamp than the (newly) received transaction), the smart contract 120 may issue an alert message to the user device 110 and / or SCBVC 130. The alert message may indicate a replay attempt, for example.

[0071] After or before having sent transaction 118 to the smart contract 120, user device 110 may be configured to also send the encrypted message 116 comprising the captured voice command^) of the voice command session to SCBVC 130. As explained above, the encrypted message 116 may be of the form

[0072] E(timestamp, sessionld, commands, deviceSignature timestampSessionldCommands) and may thus further comprise information on the session ID, the timestamp of the captured voice command(s), and the user device ID. The information on the user device ID may come in form of the data blob signature (deviceSignature timestampSessionldCommands). Again, the skilled person having benefit from the present disclosure will appreciate that acknowledging the session ID may be beneficial but not necessary for the working principle of the present disclosure.

[0073] SCBVC 130 may receive the encrypted message 116 from user device 110. As mentioned above, the encryption may be based on the public key of the DID of SCBVC 130. Accordingly, SCBVC 130 may decrypt the encrypted message 116 using the private key of the SCBVC’s DID. This decryption may reveal the original content of the message 116 for SCBVC 130.

[0074] E-1[E(timestamp, sessionld, commands, deviceSignature timestampSessionldCommands)] = timestamp, sessionld, commands, deviceSignature_timestampSessionIdCommands, where E-1(.) denotes the decryption.

[0075] SCBVC 130 may use the decrypted message (i.e., the original content) to build a hash of both the decrypted user device ID (deviceSignature timestampSessionldCommands) and the decrypted voice command(s).

[0076] SCBVC 130 may verify the decrypted message by searching for the registered transaction related to the voice command(s) 114 which was registered on the blockchain network by smart contract 120. Searching for the registered transaction related to the voice command(s) may comprise searching for a registered transaction on the blockchain network having the same session ID as the decrypted session ID, the same hash as the hash of both the decrypted user device ID and the decrypted voice command(s), and also having a transaction timestamp equivalent to the decrypted timestamp of the voice command(s). When such a transaction is found, SCBVC 130 may positively verify the decrypted message and execute the decrypted voice command(s) from user device 110 or user 112. When such a transaction is not found, SCBVC 130 may not execute the decrypted voice command(s) from user device 110 or user 112.

[0077] The individual functions of user device 110, smart contract 120, and SCBVC 130 may be summarized by the flowcharts illustrated in Fig. 2 to 4. Fig- 2 illustrates a flowchart of method 200 for user device 110.

[0078] Method 200 includes sending 202 transaction 118 related to a voice command from user device 110 to smart contract 120 deployed on the blockchain network. Transaction 118 may comprise the session ID associated with the voice command(s). The transaction 118 may further comprise the hash of both voice command(s) and the data blob signature as user device ID (H(deviceSignature_timestampSessionIdCommands, commands)). Method 200 further includes sending 204 the encrypted message 116 comprising the voice command(s) from user device 110 to SCBVC 130. Encrypted message 116 may further comprise information on the session ID, a timestamp of the voice command(s), and the data blob signature as user device ID.

[0079] Fig- 3 illustrates a flowchart of method 300 for smart contract 120.

[0080] At 302, smart contract 110 receives the transaction 118 related to the voice command(s) from user device 110. The received transaction 118 may comprises a session ID associated with the voice command(s), and a hash of both voice command(s) and the data blob signature as user device ID (H(deviceSignature_timestampSessionIdCommands, commands)). At 304, smart contract 110 searches, in the blockchain network, for an already registered transaction e.g., having the same session ID, the same hash, but an older timestamp than the received transaction. In case of a negative search result, smart contract 120 registers the received transaction 118 with its associated timestamp in the blockchain network at 306.

[0081] Fig. 4 illustrates a flowchart of method 400 for SCBVC 130.

[0082] At 402, SCBVC 130 receives the encrypted message 116 comprising the voice command(s) from user device 110. The encrypted message 116 may further comprise information on the session ID associated with the voice command(s), the timestamp associated with the voice command(s), and the data blob signature as an example of the user device ID. At 404, SCBVC 130 decrypts the received encrypted message. At 406, SCBVC 130 verifies the decrypted message based on searching for a registered transaction related to the voice command^). The proposed solution still requires spoken words. The SCBVC 130 still needs to receive and recognize the spoken commands. The user device 110 may process the user’s voice commands using text-to-speech once it is authorized to do so using one or multiple biometric authentication steps. The smart contract 120, before committing the data to the blockchain, searches for replay attempts based on blockchain transaction timestamp and the smart contract input. The SCBVC 130 can then use the registered smart contract transaction for validating the user’s commands.

[0083] In the following, some examples of the proposed concept are presented:

[0084] An example (e.g., example 1) relates to a method for a smart contract deployed on a blockchain network, the method comprising the smart contract receiving a transaction related to at least one voice command from a user device, the received transaction comprising information on the voice command and a user device identifier, the method comprising searching, in the blockchain network, for an already registered transaction related to the same voice command but having an older timestamp than the received transaction, and in case of a negative search result, the method comprising the smart contract registering the received transaction with its associated timestamp in the blockchain network.

[0085] Another example (e.g., example 2) relates to a previous example (e.g., example 1) or to any other example, further comprising that the received transaction comprises a session identifier associated with the voice command, and searching for the already registered transaction comprises searching for an already registered transaction having the same session identifier.

[0086] Another example (e.g., example 3) relates to a previous example (e.g., one of the examples 1 or 2) or to any other example, further comprising that the received transaction comprises a hash of the voice command and the user device identifier, and searching for the already registered transaction comprises searching for an already registered transaction having the same hash.

[0087] Another example (e.g., example 4) relates to a previous example (e.g., one of the examples 1 to 3) or to any other example, further comprising, in case of a positive search result, issuing an alert message to the user device and / or a Service Controlled By Voice Commands, SCBVC. Another example (e.g., example 5) relates to a previous example (e.g., one of the examples 1 to 4) or to any other example, further comprising that the received transaction or a portion thereof is signed with the private key of the user device.

[0088] Another example (e.g., example 6) relates to a previous example (e.g., one of the examples 1 to 5) or to any other example, further comprising that the user device identifier comprises a signature of a data blob composed of a timestamp of the voice command, the session identifier, and the voice command.

[0089] Another example (e.g., example 7) relates to a previous example (e.g., one of the examples 1 to 6) or to any other example, further comprising that the smart contract registering the received transaction comprises including the received transaction with its associated timestamp in a block of the blockchain network.

[0090] An example (e.g., example 8) relates to an apparatus for a smart contract deployed on a blockchain network, the apparatus comprising processing circuitry configured to receive a transaction related to a voice command from a user device, the received transaction comprising information on the voice command and a user device identifier, search, in the blockchain network, for an already registered transaction related to the same voice command but having an older timestamp than the received transaction, and in case of a negative search result, register the received transaction with its associated timestamp in the blockchain network.

[0091] An example (e.g., example 9) relates to a method for a Service Controlled By Voice Commands, SCBVC, the method comprising receiving an encrypted message comprising a voice command from a user device, the encrypted message further comprising information on a timestamp associated with the voice command and a user device identifier, decrypting the received encrypted message, and verifying the decrypted message based on searching for a transaction related to the voice command and registered on a blockchain network by a smart contract deployed on the blockchain network.

[0092] Another example (e.g., example 10) relates to a previous example (e.g., example 9) or to any other example, further comprising that the encrypted message is encrypted based on a public key of a Decentralized Identifier, DID, of the SCBVC. Another example (e.g., example 11) relates to a previous example (e.g., one of the examples 9 or 10) or to any other example, further comprising that the encrypted message is decrypted using the private key of the SCBVC’s DID.

[0093] Another example (e.g., example 12) relates to a previous example (e.g., one of the examples 9 to 11) or to any other example, further comprising that searching for the transaction related to the voice command comprises searching for a registered transaction having the same timestamp.

[0094] Another example (e.g., example 13) relates to a previous example (e.g., one of the examples 9 to 12) or to any other example, further comprising that the encrypted message comprises information on a session identifier associated with the voice command, and searching for the transaction related to the voice command comprises searching for a registered transaction having the same session identifier.

[0095] Another example (e.g., example 14) relates to a previous example (e.g., one of the examples 9 to 13) or to any other example, further comprising that verifying the decrypted message comprises comparing a hash associated with the decrypted message with a hash associated with the registered transaction.

[0096] Another example (e.g., example 15) relates to a previous example (e.g., one of the examples 9 to 14) or to any other example, further comprising executing the voice command if the decrypted message is successfully verified.

[0097] An example (e.g., example 16) relates to an apparatus for a SCBVC, the apparatus comprising processing circuitry configured to receive an encrypted message comprising a voice command from a user device, the encrypted message further comprising information on a timestamp associated with the voice command and a user device identifier, decrypt the received encrypted message, and verify the decrypted message based on searching for a transaction related to the voice command and registered on a blockchain network by a smart contract deployed on the blockchain network. An example (e.g., example 17) relates to a method for a user device, the method comprising sending a transaction related to a voice command from a user device to a smart contract deployed on a blockchain network, the transaction comprising information on the voice command and a user device identifier, and sending an encrypted message comprising the voice command from the user device to the SCBVC, the encrypted message further comprising information on a timestamp of the voice command and the user device identifier.

[0098] Another example (e.g., example 18) relates to a previous example (e.g., example 17) or to any other example, further comprising that the transaction and the encrypted message further comprise a session identifier associated with the voice command.

[0099] Another example (e.g., example 19) relates to a previous example (e.g., one of the examples 17 or 18) or to any other example, further comprising that the transaction further comprises a hash of the voice command and the user device identifier.

[0100] Another example (e.g., example 20) relates to a previous example (e.g., one of the examples 17 to 19) or to any other example, further comprising signing the transaction or a portion thereof with the private key of the user device before sending the transaction to the smart contract.

[0101] Another example (e.g., example 21) relates to a previous example (e.g., example 20) or to any other example, further comprising that signing the transaction or a portion thereof comprises signing a data blob composed of a timestamp of the voice command, the session identifier, and the voice command.

[0102] Another example (e.g., example 22) relates to a previous example (e.g., one of the examples 17 to 21) or to any other example, further comprising encrypting the message using a public key of a DID of the SCBVC before sending it to the SCBVC.

[0103] Another example (e.g., example 23) relates to a previous example (e.g., one of the examples 17 to 22) or to any other example, further comprising authenticating a user to the user device based on biometric authentication. Another example (e.g., example 24) relates to a previous example (e.g., one of the examples 17 to 23) or to any other example, further comprising recording the voice command of the authenticated user, and converting the recorded voice command from voice to text before sending the transaction to the to the smart contract.

[0104] An example (e.g., example 25) relates to a user device, comprising processing circuitry configured to send a transaction related to a voice command from a user device to a smart contract deployed on a blockchain network, the transaction comprising information on the voice command and a user device identifier, and send an encrypted message comprising the voice command from the user device to the SCBVC, the encrypted message further comprising information on a timestamp of the voice command and the user device identifier.

[0105] The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0106] Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machine-executable, processor-executable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0107] It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and / or be broken up into several substeps, -functions, -processes or -operations.

[0108] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

[0109] The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

Claims1. A method for a smart contract deployed on a blockchain network, the method comprising the smart contract receiving a transaction related to at least one voice command from a user device, the received transaction comprising information on the voice command and a user device identifier; searching, in the blockchain network, for an already registered transaction related to the same voice command but having an older timestamp than the received transaction; and in case of a negative search result, the smart contract registering the received transaction with its associated timestamp in the blockchain network.

2. The method of claim 1, wherein the received transaction comprises a session identifier associated with the voice command, and searching for the already registered transaction comprises searching for an already registered transaction having the same session identifier.

3. The method of claim 1, wherein the received transaction comprises a hash of the voice command and the user device identifier, and searching for the already registered transaction comprises searching for an already registered transaction having the same hash.

4. The method of claim 1, further comprising in case of a positive search result, issuing an alert message to the user device and / or a Service Controlled By Voice Commands, SCBVC.

5. The method of claim 1, wherein the received transaction or a portion thereof is signed with the private key of the user device.

6. The method of claim 1, wherein the user device identifier comprises a signature of a data blob composed of a timestamp of the voice command, the session identifier, and the voice command.

7. The method of claim 1, wherein the smart contract registering the received transaction comprises including the received transaction with its associated timestamp in a block of the blockchain network.

8. A method for a Service Controlled By Voice Commands, SCBVC, the method comprising receiving an encrypted message comprising a voice command from a user device, the encrypted message further comprising information on a timestamp associated with the voice command and a user device identifier; decrypting the received encrypted message; and verifying the decrypted message based on searching for a transaction related to the voice command and registered on a blockchain network by a smart contract deployed on the blockchain network.

9. The method of claim 8, wherein the encrypted message is encrypted based on a public key of a Decentralized Identifier, DID, of the SCBVC.

10. The method of claim 8, wherein the encrypted message is decrypted using the private key of the SCB VC’s DID.

11. The method of claim 8, wherein searching for the transaction related to the voice command comprises searching for a registered transaction having the same timestamp.

12. The method of claim 8, wherein the encrypted message comprises information on a session identifier associated with the voice command, and searching for the transaction related to the voice command comprises searching for a registered transaction having the same session identifier.

13. The method of claim 8, wherein verifying the decrypted message comprises comparing a hash associated with the decrypted message with a hash associated with the registered transaction.

14. The method of claim 8, further comprising executing the voice command if the decrypted message is successfully verified.

15. A method for a user device, the method comprising sending a transaction related to a voice command from a user device to a smart contract deployed on a blockchain network, the transaction comprising information on the voice command, and a user device identifier; and sending an encrypted message comprising the voice command from the user device to the SCBVC, the encrypted message further comprising information on a timestamp of the voice command and the user device identifier.

16. The method of claim 15, wherein the transaction and the encrypted message further comprise a session identifier associated with the voice command.

17. The method of claim 15, wherein the transaction further comprises a hash of the voice command and the user device identifier.

18. The method of claim 15, further comprising signing the transaction or a portion thereof with the private key of the user device before sending the transaction to the smart contract.

19. The method of claim 18, wherein signing the transaction or a portion thereof comprises signing a data blob composed of a timestamp of the voice command, the session identifier, and the voice command.

20. The method of claim 15, further comprising encrypting the message using a public key of a DID of the SCBVC before sending it to the SCBVC.

Images