Smart contracts, voice command controlled services, and user devices

Abstract

This disclosure proposes a concept in which a smart contract receives a service from a user device associated with at least one voice command. The received service includes the voice command and a user device identifier. The smart contract searches the blockchain network for already registered services associated with the same voice command but with an older timestamp than the received service. In the case of a negative search result, the smart contract registers the received service on the blockchain network with its associated timestamp. A Voice Command Controlled Service (SCBVC) receives an encrypted message including the voice command from the user device. The encrypted message further includes information about the timestamp associated with the voice command and the user device identifier. The SCBVC decrypts the received encrypted message and verifies the decrypted message based on the search for services associated with the voice command that have been registered on the blockchain network by the smart contract.

Description

Technical Field

[0001] This disclosure generally relates to the field of smart contracts, and more specifically to smart contracts used for anti-replay testing and to ensure that a device or service only accepts voice input from an authorized person. Background Technology

[0002] When a user is successfully authorized to use a personal user device or service, input can be provided in discrete ways, such as typing commands. Sometimes, voice or verbal commands can also be an option. This is meaningful, for example, for visually impaired people or people wearing virtual reality (VR) headsets.

[0003] The problem with verbal commands is that anyone can hear them and repeat them on the user's device or through a service authorized for that user. Once the user's device or service becomes operational, few measures may be taken to prevent unauthorized individuals from giving verbal commands, just as authorized users do. Even when certain voice biometric security measures are in place, the replay of recorded commands can still be used.

[0004] Therefore, there is a need for devices that allow the identification of fraudulent or unauthorized voice input. Summary of the Invention

[0005] This need is addressed by the method and apparatus according to the appended claims.

[0006] According to the first aspect, this disclosure provides a method for deploying smart contracts on a blockchain network. This method may be a computer-implemented method.

[0007] A smart contract can be understood as a self-executing contract with agreed-upon terms written directly into lines of computer-executable code between two parties. The code and protocols contained within a smart contract can exist across distributed, decentralized blockchain networks. Smart contracts allow trusted business transactions and agreements to be executed between different anonymous parties without the need for a central authority, legal system, or external enforcement mechanisms. They can make transactions traceable, transparent, and irreversible. Each party involved in a smart contract agrees to the terms encoded within the contract. When predetermined conditions are met, the contract can automatically enforce and execute the agreed-upon terms. An example platform for implementing smart contracts is the Ethereum blockchain, which was specifically designed to support such applications through robust programming languages. However, other blockchain platforms can also support smart contracts.

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

[0009] The proposed method involves smart contracts (e.g., executing on a virtual machine on a blockchain network) receiving services (or requests) related to voice commands from a user device. A smart contract service can refer to the process of executing the terms of a smart contract on a blockchain network. Voice commands from the user device can refer to instructions or commands given by the user to a device (e.g., a smartphone, tablet PC, wearable device, smart TV, etc.) using their voice.

[0010] The received services include information about voice commands and user equipment identifiers (User Equipment IDs). Voice commands can be in audio format or, for example, text format after speech-to-text conversion. A user equipment ID is a unique alphanumeric string associated with a user equipment (e.g., a mobile device or any other electronic device). It serves as a means of distinguishing user equipment on a network or within a system.

[0011] Optionally, the received service may include a session identifier (session ID) associated with the voice command. The session ID can be unique data that a user equipment can generate to identify a specific user's voice command session. For example, a voice command session may be a time period during which the user is authenticated using the user equipment or a voice command control service (SCBVC). The session ID can improve the identification and / or retrieval of registered services.

[0012] Further, optionally, the received service may include 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 can be understood as a function that transforms the input (e.g., voice command, user device ID, voice command + user device ID) into a fixed-size byte string. The output (typically, a "digest") uniquely represents any amount of (input) data. Optional hashing can improve user privacy.

[0013] The proposed method further includes searching the blockchain network for already registered services that are associated with the same voice command but have an older timestamp than the received service. Optionally, the proposed method includes searching the blockchain network for already registered services that have the same session ID and the same hash but have an older timestamp than the (newly) received service. In the case of negative search results (i.e., no already registered services associated with the same voice command (e.g., with the same session ID and the same hash) but with an older timestamp than the received service), the proposed method further includes a smart contract registering the (newly) received service in the blockchain network with its associated timestamp. Registering the (newly) received service may include selecting services from a service pool and forming a new block. In the case of smart contract services, this may include executing smart contract code within the context of the blockchain's virtual machine (e.g., the Ethereum Virtual Machine for Ethereum). This execution may modify the state stored in the blockchain based on the smart contract's logic. A newly created block containing the service and its resulting state changes may be proposed to the blockchain network. Network nodes may reach consensus according to the blockchain's protocol, verify the block, and add it to the blockchain.

[0014] In cases where a positive search result is obtained (i.e., a previously registered service has the same session ID and the same hash, but with an older timestamp than the (newly) received service), the method may further include issuing some kind of alert message to the user device and / or the Voice Command Control (SCBVC) service. SCBVC can be understood as a technology that allows users to interact with devices, applications, or systems via verbal commands, rather than traditional input methods such as typing or clicking.

[0015] In some implementations, the received service or a portion thereof is signed using the user equipment's private key. For example, as part of the service, the user equipment ID may include a signature of a data block consisting of a timestamp of a voice command, a session ID, and the voice command itself. The signature verifies that the service or a portion thereof was created by the legitimate owner of the private key, effectively proving the sender's identity without revealing the private key itself. Signing the service or a portion thereof with the private key also ensures that the service cannot be altered by anyone else after it has been signed. If any part of the service is altered after signing, the digital signature becomes invalid, and the network can reject the service.

[0016] Once a transaction is verified, it can be included in a block on the blockchain network. When a block is added to the blockchain, a smart contract can be triggered to execute based on the transaction's instructions, and the result can be recorded on the blockchain. Therefore, in some implementations, registering a received transaction with a smart contract includes including the received transaction along with its associated timestamp in a block on the blockchain network.

[0017] According to another aspect, this disclosure provides an apparatus for deploying smart contracts on a blockchain network. The apparatus includes processing circuitry configured to: - Receive services related to voice commands from the user equipment, including information about the voice commands and the user equipment identifier. - Search the blockchain network for registered services that are associated with the same voice command but have an older timestamp than the received service, and - In the case of a negative search result, register the received business in the blockchain network with its associated timestamp.

[0018] For example, information about voice commands and user device IDs may include a session ID associated with the voice command and / or a hash of both the voice command and the user device ID.

[0019] Those skilled in the art will recognize that the apparatus and / or processing circuitry can be a single hardware entity or a distributed hardware infrastructure of a blockchain network. This network can include numerous computers / servers, often referred to as nodes, which can be distributed globally in different locations. By running the software for the blockchain, each node in the blockchain network can contribute to the execution and verification of smart contracts.

[0020] According to another aspect, this disclosure provides a method for SCBVC. This method can be a computer-implemented method. As previously stated, SCBVC can be understood as a technology or service that allows users to interact with devices, applications, or systems via verbal commands, rather than traditional input methods such as typing or clicking.

[0021] The proposed method involves receiving an encrypted message containing a voice command from a user device (e.g., a smartphone, tablet PC, wearable device, smart TV, etc.). The voice command can be, for example, an audio format or a text format (e.g., speech-to-text conversion). The encrypted message further includes information about a timestamp associated with the voice command and a user device ID. Optionally, the encrypted message includes information about a session ID associated with the voice command, a timestamp associated with the voice command, and the user device ID. For example, the user device ID may include a signature of a data block consisting of the 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 transactions associated with the voice command that have been registered on the blockchain network by smart contracts deployed on the blockchain network.

[0022] In some implementations, encrypted messages are encrypted using the public key of a Distributed Identifier (DID) based on SCBVC. A DID is a type of identifier that enables verifiable, sovereign identities to be verified or authenticated without relying on a centralized authority or intermediary. DIDs are stored on decentralized networks, such as blockchains or distributed ledgers, ensuring there is no single point of failure or control. DIDs are designed to be verifiable. They can be verified using cryptographic proofs that allow others to verify the authenticity of the DID and the integrity of the information associated with it. A DID typically includes a unique identifier linked to a DID document. This document contains metadata necessary for interacting with the DID, such as encryption keys, authentication protocols, and server endpoints used for communication. The DID document is the document that enables secure and verifiable interaction at the core of the decentralized identity concept.

[0023] In some implementations, the encrypted message is decrypted using the private key of the SCBVC's DID (at the SCBVC).

[0024] In some implementations, searching for services related to voice commands includes searching the blockchain network for registered services that have the same hash for both the session ID, voice command, and user device ID, and that have a timestamp for the voice command.

[0025] In some implementations, verifying a decrypted message involves comparing a hash associated with the decrypted message with a hash associated with a registered service.

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

[0027] According to another aspect, this disclosure provides an apparatus for SCBVC. The apparatus includes processing circuitry configured to: - Receive an encrypted message from the user equipment including a voice command, the encrypted message further including information about a timestamp associated with the voice command and a user equipment identifier (and optionally, a session identifier associated with the voice command). -Decrypt the received encrypted message, and - Messages are verified and decrypted based on search and voice command related services that have been registered on the blockchain network by smart contracts deployed on the blockchain network.

[0028] Those skilled in the art will recognize that the apparatus and / or processing circuitry can be a single hardware entity (computer / server) or a distributed hardware infrastructure.

[0029] According to another aspect, this disclosure provides a method for a user device. This method can be a computer-implemented method. The proposed method includes sending / transmitting traffic related to voice commands from the user device to a smart contract deployed on a blockchain network. The sent traffic includes information about the voice command and the user device ID. The proposed method further includes sending an encrypted message including the voice command from the user device to SCBVC. The encrypted message further includes information about the timestamp of the voice command and the user device ID.

[0030] In some implementations, the business and encrypted messages further include a session ID associated with the voice command.

[0031] In some implementations, the service further includes voice commands and hashes of user equipment IDs.

[0032] In some implementations, the proposed method further includes signing the transaction using the user device's private key before sending the transaction to the smart contract.

[0033] In some implementations, the proposed method further includes encrypting the message using the public key of the SCBVC's DID before sending the message to the SCBVC.

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

[0035] In some implementations, the proposed method further includes recording the voice commands of an authenticated user and converting the recorded voice commands from speech to text before sending the service to the smart contract.

[0036] According to another aspect, this disclosure provides a user equipment (e.g., a smartphone, tablet PC, wearable device, smart TV, etc.) including processing circuitry, the processing circuitry being configured to: - Sending voice command-related transactions from the user device to a smart contract deployed on a blockchain network; these transactions include information about the voice command and the user device ID; and - An encrypted message containing a voice command is sent from the user device to the SCBVC. The encrypted message further includes a timestamp of the voice command and the user device ID. Attached Figure Description

[0037] The following will describe some embodiments of the apparatus and / or method by way of example only and with reference to the accompanying drawings, in which...

[0038] Figure 1An overview of a system according to an embodiment of the present disclosure is illustrated schematically; Figure 2 A flowchart of a method for a user equipment is shown; Figure 3 A flowchart of method 300 for smart contracts is shown; and Figure 4 A flowchart of the method used for SCBVC is shown. Detailed Implementation

[0039] Some embodiments will now be described in more detail with reference to the accompanying drawings. However, other possible embodiments are not limited to the features of these embodiments described in detail. Other embodiments may include modifications to features, as well as equivalents and substitutions of features. Furthermore, the terminology used herein to describe certain embodiments should not limit other possible embodiments.

[0040] Throughout the description of the accompanying drawings, the same or similar reference numerals denote the same or similar elements and / or features, which may be implemented identically or in modified form while providing the same or similar function. For clarity, the thickness of lines, layers, and / or areas in the drawings may also be enlarged.

[0041] When the word "or" is used to combine two elements A and B, it should be understood to disclose all possible combinations, namely, A only, B only, and A and B, unless otherwise explicitly specified in a separate case. As alternative wording for the same combination, "at least one of A and B" or "A and / or B" can be used. The same applies to combinations of more than two elements.

[0042] If the singular form, such as "a," "an," and "the," is used, and the use of a single element is not explicitly or implicitly defined as mandatory, other embodiments may use several elements to achieve the same function. If the function is described below as being implemented using multiple elements, other embodiments may use a single element or a single processing entity to achieve the same function. It should also be understood that the terms "comprising," "including," "including," and / or "comprise" describe the presence of a specified feature, integral, step, operation, process, element, component, and / or group thereof when used, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, processes, elements, components, and / or groups thereof.

[0043] A high-level finding of the proposed concept is that a user device (e.g., a wearable device) associated with a user can transform the user's voice commands into encrypted signals, which are then sent to a target service (SCBVC) controlled by the voice command. The user device is authorized by the user to do this, and the user device is able to "connect" to the target service (in the presence of multiple potential target services in the vicinity). The SCBVC can register its public DID on the blockchain, allowing anyone or anything to look it up by its public DID. This also provides access to a corresponding DID document that stores a public key 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 can authenticate his / her user device using various existing biometric authentication methods, and the user device can be tamper-proof. The user device can process and encrypt only the voice commands from the user. The encrypted commands can then be sent to a smart contract on the blockchain for replay protection testing and business storage. The SCBVC can decrypt the commands and check the validity of the blockchain.

[0044] The following section will describe the proposed concepts and the entities involved in more detail.

[0045] Figure 1 An overview of a system 100 according to an embodiment of the present disclosure is schematically shown. System 100 includes at least one user device 110, a smart contract 120 deployed on a blockchain network 122, and at least one server hosting SCBVC 130.

[0046] User device 110 is associated with user 112. User device 110 is an electronic device configured to capture voice commands from user 112. Examples of such devices include smartphones and tablets. Almost all modern smartphones and tablets are equipped with built-in voice assistants. Users can activate these assistants with voice commands to make calls, send messages, set reminders, etc. 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 variety of queries and commands. As another example, wearable devices such as smartwatches and fitness trackers allow users to send texts, make calls, set reminders, and access various functions using voice commands without using their smartphones. As another example, laptops and desktop computers may support voice commands via digital assistants. As yet another example, smart home devices such as thermostats, lights, and security cameras can be controlled via voice commands through integration with a broader smart home ecosystem supported by the SCBVC 130. As another example, many modern vehicles are beginning to 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 steering 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.

[0047] User equipment 110 can capture one or more voice commands 114 for SCBVC 130 via a microphone, process the voice commands 114 on a local or remote server (depending on the complexity of the device and the command), and perform corresponding actions, providing user 112 with an efficient and generally hands-free way to interact with the technology.

[0048] Before capturing voice command 114, user device 110 can be configured to authenticate user 112, for example, based on biometric authentication (such as iris scanning, fingerprint, walking behavior, etc.). Once authorized, user 112 can use user device 110 to capture and process his / her voice command 114.

[0049] To capture one or more voice commands 114, user equipment 110 can be configured to initiate an associated voice command session. A voice command session can refer to a temporary and interactive exchange of information between user equipment 110 (or the user) and SCBVC 130. It can begin when a voice command 114 is initiated and end when the voice command 114 is terminated. User equipment 110 can assign a unique session ID to each user's voice command session. Depending on usage, a voice command session can last only as long as the voice command (typically a few seconds), or it can cover predetermined time frames, etc. For example, a voice command session continues as long as user 112 authenticates using user equipment 110.

[0050] User equipment 110 is further configured to assign timestamps to one or more captured voice commands 114 or to associated voice command sessions. A timestamp can be a sequence of characters or coded information that identifies when a voice command (session) begins or ends, typically giving the date and time of day, sometimes accurate to a fraction of a second. Timestamps can be represented in various formats, such as Coordinated Universal Time (UTC), local timezone, or Unix time (the number of seconds elapsed since the Unix epoch, i.e., January 1, 1970, 00:00:00 UTC, excluding leap seconds).

[0051] For example, user device 110 can use an internet connection to connect to the server hosting SCBVC 130 to access the SCBVC's public key. Organizations or services can publish their DID or a link to their DID document on their official websites, particularly on pages dedicated to privacy policies, contact information, or blockchain initiatives. If the DID method used by SCBVC is associated with a specific blockchain, then a blockchain explorer that supports DID (e.g., the DID of user device 110) can be used to search for business related to the company's DID. In this way, the SCBVC's public DID can be found on the identity blockchain along with the accompanying DID document that stores the SCBVC's public key. Those skilled in the art will understand from this disclosure that there are many other ways to obtain the SCBVC's public key.

[0052] User equipment 110 is also configured to encrypt messages containing captured voice commands from the user using the SCBVC public key. This encryption may involve creating a data block (timestampSessionIdCommands) that includes a timestamp of the voice command, a session ID, and the associated voice command. The term "blob" refers to a binary large object and can refer to a collection of binary data stored as a single entity. Data blocks (blobs) can be used to store data such as images, audio files, multimedia objects, and executable code that doesn't naturally fit into traditional database fields. User equipment 110 can also sign the data block consisting of the timestamp, session ID, and associated voice command using its private key. For example, the private key could be a built-in private key. The signature of the data block can be called deviceSignature_timestampSessionIdCommands. The signature acts as the user equipment ID and verifies that the data block was created by the legitimate owner of the private key, effectively proving the identity of user equipment 110 without revealing the private key itself. Signing the data block with the private key also ensures that the data block cannot be altered by anyone else after signing. If any part of the data block is altered after signing, the digital signature (User Equipment ID) will no longer be valid. Those skilled in the art will understand that User Equipment IDs created in different ways can also be used.

[0053] Encryption of messages at user equipment 110 may further involve encrypting the timestamp, session ID, associated voice command, and user equipment ID (deviceSignature_timestampSessionIdCommands) using the SCBVC public key according to the following formula: E(timestamp, sessionId, commands, deviceSignature_timestampSessionIdCommands), Here, E(.) represents encryption.

[0054] The encrypted message can then be sent from user equipment 110 to SCBVC 130.

[0055] User device 110 can also be configured to generate a service 118 related to voice commands from user device 110 and send it to a smart contract 120 deployed on blockchain network 122. Smart contract 120 is accessible by user device 110 and SCBVC 130. The service 118 sent from user device 110 to smart contract 120 may include a session ID associated with the voice command, and a hash of both the user device ID and the voice command (deviceSignature_timestampSessionIdCommands). That is, service 118 may include: sessionId+H(deviceSignature_timestampSessionIdCommands, commands), Wherein, H(.) denotes a hash. Those skilled in the art will understand that session IDs and hashes may be beneficial but not necessary for the working principle of this disclosure. Furthermore, service 118 may have an associated service timestamp, which may be substantially equivalent to the timestamp of the voice command.

[0056] Smart contract 120 (e.g., executing on a virtual machine within the blockchain network) receives a service 118 related to a voice command from user device 110. Upon receiving service 118, smart contract 120 searches the blockchain network 122 for a previously registered service with the same session ID and hash (e.g., H(deviceSignature_timestampSessionIdCommands, commands)) and an older timestamp than the (newly) received service 118. In the case of a negative search result (i.e., no previously registered service with the same session ID and hash and an older timestamp is found), smart contract 120 registers the (newly) received service 118 in the blockchain network with its associated timestamp. Each service is typically associated with a timestamp. This timestamp records when the service was added to blockchain 122.

[0057] However, in the event of a positive search result (i.e., finding a previously registered service with the same session ID and the same hash, but with an older timestamp than the (newly) received service), smart contract 120 can send an alert message to user device 110 and / or SCBVC 130. For example, the alert message could indicate a replay attempt.

[0058] Before or after sending the transaction 118 to the smart contract 120, the user device 110 may also be configured to send an encrypted message 116 containing a voice command of the captured voice command session to the SCBVC 130. As described above, the encrypted message 116 may have the following form: E(timestamp, sessionId, commands, deviceSignature_timestampSessionIdCommands) Therefore, it may further include information about the session ID, the timestamp of the captured voice command, and the user device ID. Information about the user device ID may appear in the form of a data block signature (deviceSignature_timestampSessionIdCommands). Again, those skilled in the art will understand that verifying the session ID may be beneficial, but is not necessary, for the working principle of this disclosure.

[0059] SCBVC 130 can receive encrypted message 116 from user equipment 110. As described above, encryption can be based on the public key of SCBVC 130's DID. Therefore, SCBVC 130 can decrypt encrypted message 116 using the private key of SCBVC's DID. This decryption reveals the original content of message 116 to SCBVC 130.

[0060] E -1 [E(timestamp, sessionId, commands, deviceSignature_timestampSessionIdCommands)]

[0061] =timestamp, sessionId, commands, deviceSignature_timestampSessionIdCommands, Among them, E -1 (.) indicates decryption.

[0062] SCBVC 130 can use the decrypted message (i.e., the original content) to construct the decrypted user device ID (deviceSignature_timestampSessionIdCommands) and the hash of the decrypted voice command.

[0063] SCBVC 130 can verify the decrypted message by searching for registered transactions related to the voice command 114 registered on the blockchain network by smart contract 120. Searching for registered transactions related to the voice command may include searching the blockchain network for transactions with the same session ID as the decrypted session ID, the same hash as both the decrypted user device ID and the decrypted voice command, and a transaction timestamp equivalent to the decryption timestamp of the voice command. When such a transaction is found, SCBVC 130 can reliably verify the decrypted message and execute the decrypted voice command from user device 110 or user 112. When the transaction is not found, SCBVC 130 may not execute the decrypted voice command from user device 110 or user 112.

[0064] The various functions of user equipment 110, smart contract 120, and SCBVC 130 can be provided by Figures 2 to 4 The flowchart shown can be used to summarize this.

[0065] Figure 2 A flowchart of method 200 of user equipment 110 is shown.

[0066] Method 200 includes sending (202) a service 118 related to a voice command from user device 110 to smart contract 120 deployed on the blockchain network. Service 118 may include a session ID associated with the voice command. Service 118 may further include a hash of the voice command and a data block signature as a user device ID (H(deviceSignature_timestampSessionIdCommands, commands)). Method 200 further includes sending (204) an encrypted message 116 including the voice command from user device 110 to SCBVC 130. The encrypted message 116 may further include information about the session ID, the timestamp of the voice command as the user device ID, and the data block signature.

[0067] Figure 3 A flowchart of method 300 for smart contract 120 is shown.

[0068] At 302, smart contract 120 receives a service 118 related to a voice command from user device 110. The received service 118 may include a session ID associated with the voice command, and a hash (H(deviceSignature_timestampSessionIdCommands, commands)) of both the voice command and the data block signature, which serves as the user device ID. At 304, smart contract 120 searches the blockchain network for already registered services, for example, services with the same session ID and the same hash, but with an older timestamp than the received service. In the case of a negative search result, at 306, smart contract 120 registers the received service 118 in the blockchain network with its associated timestamp.

[0069] Figure 4 A flowchart of method 400 for SCBVC 130 is shown.

[0070] At 402, SCBVC 130 receives an encrypted message 116 from user equipment 110, which includes a voice command. The encrypted message 116 may further include information about the session ID associated with the voice command, a timestamp associated with the voice command (as an example of the user equipment ID), and a data block signature. At 404, SCBVC 130 decrypts the received encrypted message. At 406, SCBVC 130 verifies the decrypted message based on a search for registered services associated with the voice command.

[0071] The proposed solution still requires spoken words. SCBVC 130 still needs to receive and recognize spoken commands. Once user device 110 is authorized to do so using one or more biometric authentication steps, it can process the user's voice commands using text-to-speech. Before submitting the data to the blockchain, smart contract 120 performs a search and replay attempt based on the blockchain business timestamp and smart contract input. SCBVC 130 can then use the registered smart contract business to verify the user's commands.

[0072] The following sections present some embodiments of the proposed concept: An example (e.g., Example 1) relates to a method for deploying a smart contract on a blockchain network, the method comprising the smart contract receiving a service related to at least one voice command from a user device, the received service including information about the voice command and a user device identifier, the method comprising searching in the blockchain network for already registered services related to the same voice command but having an older timestamp than the received service, and, in the case of a negative search result, the method comprising the smart contract registering the received service in the blockchain network with its associated timestamp.

[0073] Another embodiment (e.g., embodiment 2) relates to a previous embodiment (e.g., embodiment 1) or any other embodiment, and further includes: the received service includes a session identifier associated with a voice command, and searching for registered services includes searching for registered services with the same session identifier.

[0074] Another embodiment (e.g., embodiment 3) relates to a previous embodiment (e.g., one of embodiment 1 or 2) or any other embodiment, and further includes: the received service includes a hash of a voice command and a user equipment identifier, and searching for already registered services includes searching for already registered services with the same hash.

[0075] Another embodiment (e.g., embodiment 4) relates to a previous embodiment (e.g., one of embodiments 1 to 3) or any other embodiment, and further includes: issuing an alert message to the user device and / or the voice command control service (SCBVC) in the case of a positive search result.

[0076] Another embodiment (e.g., embodiment 5) relates to a previous embodiment (e.g., one of embodiments 1 to 4) or any other embodiment, and further includes: signing the received service or a portion thereof using the private key of the user equipment.

[0077] Another embodiment (e.g., embodiment 6) relates to a previous embodiment (e.g., one of embodiments 1 to 5) or any other embodiment, and further includes: a user equipment identifier comprising a signature of a data block, the data block consisting of a timestamp of a voice command, a session identifier, and a voice command.

[0078] Another embodiment (e.g., embodiment 7) relates to a previous embodiment (e.g., one of embodiments 1 to 6) or any other embodiment, and further includes: the smart contract registering the received service includes: including the received service together with its associated timestamp in a block of the blockchain network.

[0079] The embodiments (e.g., Embodiment 8) relate to an apparatus for deploying smart contracts on a blockchain network, the apparatus including processing circuitry configured to receive services related to voice commands from a user device, the received services including information about the voice commands and a user device identifier, search the blockchain network for already registered services related to the same voice commands but with an older timestamp than the received services, and, in the case of negative search results, register the received services in the blockchain network with their associated timestamps.

[0080] An embodiment (e.g., embodiment 9) relates to a method for a service for voice command control (SCBVC), the method comprising: receiving from a user device an encrypted message including a voice command, the encrypted message further including information about a timestamp and a user device identifier associated with the voice command; decrypting the received encrypted message; and verifying the decrypted message based on searching for services associated with the voice command and registered on the blockchain network by smart contracts deployed on the blockchain network.

[0081] Another embodiment (e.g., embodiment 10) relates to a previous embodiment (e.g., embodiment 9) or any other embodiment, and further includes: the encrypted message is encrypted based on the public key of the distributed identifier (DID) of the SCBVC.

[0082] Another embodiment (e.g., embodiment 11) relates to a previous embodiment (e.g., one of embodiments 9 or 10) or any other embodiment, and further includes decrypting the encrypted message using the private key of the DID of the SCBVC.

[0083] Another embodiment (e.g., embodiment 12) relates to a previous embodiment (e.g., one of embodiments 9 to 11) or any other embodiment, and further includes: searching for services related to voice commands includes searching for registered services with the same timestamp.

[0084] Another embodiment (e.g., embodiment 13) relates to a previous embodiment (e.g., one of embodiments 9 to 12) or any other embodiment, further including: the encrypted message includes information about a session identifier associated with the voice command, and searching for the service associated with the voice command includes searching for registered services with the same session identifier.

[0085] Another embodiment (e.g., embodiment 14) relates to a previous embodiment (e.g., one of embodiments 9 to 13) or any other embodiment, and further includes: verifying the decrypted message by comparing a hash associated with the decrypted message with a hash associated with the registered service.

[0086] Another embodiment (e.g., embodiment 15) relates to a previous embodiment (e.g., one of embodiments 9 to 14) or any other embodiment, and further includes: executing a voice command if the decrypted message is successfully verified.

[0087] An embodiment (e.g., embodiment 16) relates to an apparatus for SCBVC, the apparatus including processing circuitry configured to: receive from a user equipment an encrypted message including a voice command, the encrypted message further including information about a timestamp and a user equipment identifier associated with the voice command; decrypt the received encrypted message; and verify the decrypted message based on searching for services associated with the voice command and registered on the blockchain network by smart contracts deployed on the blockchain network.

[0088] An embodiment (e.g., embodiment 17) relates to a method for a user device, the method comprising: sending a service related to a voice command from the user device to a smart contract deployed on a blockchain network, the service including information about the voice command and a user device identifier; and sending an encrypted message including the voice command from the user device to the SCBVC, the encrypted message further including information about a timestamp of the voice command and the user device identifier.

[0089] Another embodiment (e.g., embodiment 18) relates to a previous embodiment (e.g., embodiment 17) or any other embodiment, further including: the service and the encrypted message further include a session identifier associated with the voice command.

[0090] Another embodiment (e.g., embodiment 19) relates to a previous embodiment (e.g., one of embodiments 17 or 18) or any other embodiment, further including: the service further includes a hash of voice commands and user equipment identifiers.

[0091] Another embodiment (e.g., embodiment 20) relates to a previous embodiment (e.g., one of embodiments 17 to 19) or any other embodiment, and further includes: signing the service or a portion thereof using the user device's private key before sending the service to the smart contract.

[0092] Another embodiment (e.g., embodiment 21) relates to a previous embodiment (e.g., embodiment 20) or any other embodiment, and further includes: signing the service or a portion thereof includes signing a data block consisting of a timestamp of the voice command, the session identifier, and the voice command.

[0093] Another embodiment (e.g., embodiment 22) relates to a previous embodiment (e.g., one of embodiments 17 to 21) or any other embodiment, and further includes: encrypting the message using the public key of the SCBVC's DID before sending the message to the SCBVC.

[0094] Another embodiment (e.g., embodiment 23) relates to previous embodiments (e.g., one of embodiments 17 to 22) or any other embodiment, and further includes authenticating the user to the user device based on biometric authentication.

[0095] Another embodiment (e.g., embodiment 24) relates to a previous embodiment (e.g., one of embodiments 17 to 23) or any other embodiment, and further includes: recording the voice commands of the authenticated user, and converting the recorded voice commands from voice to text before sending the business to the smart contract.

[0096] An embodiment (e.g., embodiment 25) relates to a user equipment including processing circuitry configured to send services related to voice commands from the user equipment to a smart contract deployed on a blockchain network, the services including information about the voice command and a user equipment identifier, and to send an encrypted message including the voice command from the user equipment to the SCBVC, the encrypted message further including information about a timestamp of the voice command and the user equipment identifier.

[0097] The aspects and features described with respect to specific embodiments in the preceding embodiments may also be combined with one or more of the other embodiments to replace the same or similar features of the other embodiment or to additionally introduce the features into the other embodiment.

[0098] The embodiments may further be or relate to (computer) programs that include program code that performs one or more of the methods described above when executed on a computer, processor, or other programmable hardware component. Therefore, the steps, operations, or processes of the different methods described above can also be performed by a programmed computer, processor, or other programmable hardware component. The embodiments may also cover program storage devices, such as digital data storage media, which are machine-readable, processor-readable, or computer-readable and encode and / or contain machine-executable programs, processor-executable programs, or computer-executable programs and instructions. Program storage devices may include, or be digital storage devices, magnetic storage media (e.g., disks and tapes), hard disk drives, or optically readable digital data storage media. Other embodiments may also include computers, processors, control units, (field-programmable arrays) ((F)PLAs), (field-programmable gate arrays) ((F)PGAs), graphics processing units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the methods described above.

[0099] It should be further understood that the disclosure of several steps, processes, operations, or functions in the specification or claims should not be construed as implying that these operations necessarily depend on the described order, unless expressly stated in individual cases or necessary for technical reasons. Therefore, the foregoing description does not limit the execution of several steps or functions to a specific order. Furthermore, in other embodiments, a single step, function, process, or operation may include and / or be decomposed into several sub-steps, functions, processes, or operations.

[0100] If aspects of an apparatus or system have been described, these aspects should also be understood as descriptions of the corresponding methods. For example, a block, device, or functional aspect of an apparatus or system may correspond to a feature of the corresponding method, such as method steps. Therefore, aspects of the method description should also be understood as descriptions of corresponding blocks, elements, properties, or functional features of the corresponding apparatus or system.

[0101] The following claims are thus incorporated in the detailed description, wherein each claim may stand alone as a separate embodiment. It should also be noted that while in the claims, dependent claims refer to a specific combination with one or more other claims, other embodiments may also include combinations of dependent claims with the subject matter of any other dependent or independent claim. Such combinations are thus expressly stated unless, in individual cases, the statement of a particular combination is unintentional. Furthermore, the features of a claim should also be included in any other independent claim, even if that claim is not directly defined as dependent on any other independent claim.

Claims

1. A method for deploying smart contracts on a blockchain network, the method comprising: The smart contract receives services related to at least one voice command from the user device, and the received services include information about the voice command and the user device identifier. Search the blockchain network for registered services that are associated with the same voice command but have an older timestamp than the received service. as well as In the event of a negative search result, the smart contract registers the received service in the blockchain network with a timestamp associated with the received service.

2. The method according to claim 1, wherein, The received services include a session identifier associated with the voice command, and Searching for already registered services includes searching for already registered services with the same session identifier.

3. The method according to claim 1, wherein, The received services include the voice commands and the hash of the user equipment identifier, and Searching for already registered businesses includes searching for already registered businesses with the same hash.

4. The method according to claim 1, further comprising: If the search results are positive, an alert message is sent to the user device and / or the voice command-controlled service SCBVC.

5. The method according to claim 1, wherein, The received service or a portion thereof is signed using the private key of the user equipment.

6. The method according to claim 1, wherein, The user equipment identifier includes a signature of a data block, which consists of a timestamp of the voice command, a session identifier, and the voice command.

7. The method according to claim 1, wherein, The smart contract registration includes receiving the service and its associated timestamp in a block of the blockchain network.

8. A method for Service SCBVC for voice command control, the method comprising: Receive an encrypted message from the user equipment including a voice command, the encrypted message further including information about a timestamp and a user equipment identifier associated with the voice command; Decrypt the received encrypted message; as well as The decrypted message is verified based on a search for a business that is related to the voice command and has been registered on the blockchain network by a smart contract deployed on the blockchain network.

9. The method according to claim 8, wherein, The encrypted message is encrypted using the public key of the distributed identifier DID of the SCBVC.

10. The method according to claim 8, wherein, The encrypted message is decrypted using the private key of the SCBVC's DID.

11. The method according to claim 8, wherein, Searching for services related to the voice command includes searching for registered services with the same timestamp.

12. The method according to claim 8, wherein, The encrypted message includes information about a session identifier associated with the voice command, and Searching for services related to the voice command includes searching for registered services with the same session identifier.

13. The method according to claim 8, wherein, Verifying the decrypted message includes comparing the hash associated with the decrypted message with the hash associated with a registered service.

14. The method of claim 8, further comprising: If the decrypted message is successfully verified, the voice command is executed.

15. A method for a user equipment, the method comprising: The voice command-related business is sent from the user device to a smart contract deployed on a blockchain network, the business including information about the voice command and the user device identifier; as well as An encrypted message including the voice command is sent from the user equipment to the SCBVC, the encrypted message further including information about the timestamp of the voice command and the user equipment identifier.

16. The method according to claim 15, wherein, The service and the encrypted message further include a session identifier associated with the voice command.

17. The method according to claim 15, wherein, The service further includes the hash of the voice command and the user equipment identifier.

18. The method of claim 15, further comprising: Before sending the service to the smart contract, the service or a portion thereof is signed using the user device's private key.

19. The method according to claim 18, wherein, Signing the service or a portion thereof includes signing a data block consisting of the timestamp of the voice command, the session identifier, and the voice command.

20. The method of claim 15, further comprising: Before sending the message to the SCBVC, the message is encrypted using the public key of the SCBVC's DID.

Images