CN110533403B - A method for consumption processing and related device - Google Patents

Abstract

The embodiment of the application provides a consumption processing method and a related device, wherein the consumption authority of an account is regulated through an intelligent contract of a blockchain, so that when a user transfers consumption through the blockchain, the consumption authority of the intelligent contract is required to be met, and transfer consumption can be realized. According to the embodiment of the application, the user performs planning and arrangement on the fund purpose through the intelligent contract, so that the fund purpose planning and arrangement is safe and reliable, and the problems that the planning and arrangement through the memo are unreliable and the memo is easy to lose are solved.

Description

A method for consumption processing and related device

Technical Field

The present application relates to the field of Internet technology, and in particular to a consumption processing method and related devices.

Background Art

With the development of Internet technology, electronic payment is widely used in people's daily life. Consumers can conveniently pay for their favorite services or items through electronic payment according to the associated bank card or third-party payment account.

In current shopping consumption, if user A likes an item sold by user B, user A can purchase the item from user B by transferring funds from his account to user B's account. If user A expects to manage the use of funds in his account, user A can record the remaining funds in the account and the planned use of funds through a memo.

The inventor of the present application has found that the prior art has at least the following disadvantages: users use memos to manage their fund usage, and are prone to forget to check the memos when shopping, thereby forgetting the set fund plan. At the same time, when using physical memos, users are prone to lose the memos.

From the above analysis, it can be seen that in the prior art, users use memos to manage the use of funds, which is unreliable and easy to lose.

Summary of the invention

The embodiment of the present application provides a consumption processing method and related devices for limiting the consumption authority of funds from the transaction process, thereby solving the problem that the memo method is unreliable and the memo is easily lost.

In view of this, a first aspect of an embodiment of the present application provides a consumption processing method, including:

Obtaining an account transfer request, the account transfer request including an account identifier, the account transfer request also including at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

According to the account transfer request, determining the consumption authority through a smart contract, wherein the consumption authority has a corresponding relationship with the account identifier;

If the account transfer request satisfies the consumption authority, the account transfer request is synchronized through the blockchain.

A second aspect of an embodiment of the present application provides a consumption processing device, including:

an acquisition unit, configured to acquire an account transfer request, wherein the account transfer request includes an account identifier, and the account transfer request also includes at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

A processing unit, configured to determine the consumption authority through a smart contract according to the account transfer request, wherein the consumption authority has a corresponding relationship with the account identifier;

The processing unit is further configured to synchronize the account transfer request through the blockchain if the account transfer request satisfies the consumption authority.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

Acquire the consumption amount corresponding to the consumption type according to the account transfer request;

If the consumption amount corresponding to the consumption type is less than or equal to the consumption limit corresponding to the consumption type, determining that the account transfer request satisfies the consumption authority, wherein the consumption limit corresponding to the consumption type is determined by the smart contract;

If the consumption amount corresponding to the consumption type is greater than the consumption limit corresponding to the consumption type, it is determined that the account transfer request does not meet the consumption authority.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

Acquire the consumption type according to the account transfer request;

If the consumption type satisfies the consumption type restriction condition corresponding to the account identifier, determining that the account transfer request satisfies the consumption authority, wherein the consumption type restriction condition corresponding to the account identifier is determined by the smart contract;

If the consumption type does not satisfy the consumption type restriction condition corresponding to the account identifier, it is determined that the account transfer request does not satisfy the consumption authority.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

acquiring the location information according to the account transfer request;

If the location information satisfies the location information restriction condition corresponding to the account identifier, determining that the account transfer request satisfies the consumption authority, wherein the location information restriction condition corresponding to the account identifier is determined by the smart contract;

If the location information does not satisfy the location information restriction condition corresponding to the account identifier, it is determined that the account transfer request does not satisfy the consumption authority.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, a deposit unit is further included, and the deposit unit is used to:

Obtaining a deposit request, the deposit request including the account identifier, the consumption type, and the deposit amount;

Determining the smart contract according to the account identifier, the consumption type, and the deposit amount;

The deposit request and the smart contract are synchronized to the blockchain.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the deposit unit is further used for:

Synchronizing the deposit request to the blockchain;

Synchronizing the smart contract to the blockchain;

Wherein, synchronizing the smart contract to the blockchain includes:

Encrypt the smart contract using a private key to obtain the encrypted smart contract;

The encrypted smart contract is synchronized to the blockchain.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

If the consumption amount is greater than the consumption limit, a prompt message is generated, wherein the prompt message is used to prompt that the transfer fails.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

The updated consumption limit is determined according to the consumption limit and the consumption amount.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

A reminder message is generated according to the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In a possible design, in an implementation of the second aspect of the embodiment of the present application, the processing unit is further configured to:

Acquire historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

According to the account identifier in the account transfer request, the consumption type and the historical consumption record, the consumption limit corresponding to the consumption type is determined through the smart contract.

A third aspect of an embodiment of the present application provides a node device, which may be a terminal device or a server, including: a memory, a transceiver, a processor, and a bus system;

Wherein, the memory is used to store programs;

The processor is used to execute the program in the memory, comprising the following steps:

Obtaining an account transfer request, the account transfer request including an account identifier, the account transfer request also including at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

According to the account transfer request, determining the consumption authority through a smart contract, wherein the consumption authority has a corresponding relationship with the account identifier;

If the account transfer request satisfies the consumption authority, the account transfer request is synchronized through the blockchain; the bus system is used to connect the memory and the processor so that the memory and the processor communicate with each other.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

Acquire the consumption amount corresponding to the consumption type according to the account transfer request;

If the consumption amount corresponding to the consumption type is less than or equal to the consumption limit corresponding to the consumption type, determining that the account transfer request satisfies the consumption authority, wherein the consumption limit corresponding to the consumption type is determined by the smart contract;

If the consumption amount corresponding to the consumption type is greater than the consumption limit corresponding to the consumption type, it is determined that the account transfer request does not meet the consumption authority.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

Acquire the consumption type according to the account transfer request;

If the consumption type satisfies the consumption type restriction condition corresponding to the account identifier, determining that the account transfer request satisfies the consumption authority, wherein the consumption type restriction condition corresponding to the account identifier is determined by the smart contract;

If the consumption type does not satisfy the consumption type restriction condition corresponding to the account identifier, it is determined that the account transfer request does not satisfy the consumption authority.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

acquiring the location information according to the account transfer request;

If the location information satisfies the location information restriction condition corresponding to the account identifier, determining that the account transfer request satisfies the consumption authority, wherein the location information restriction condition corresponding to the account identifier is determined by the smart contract;

If the location information does not satisfy the location information restriction condition corresponding to the account identifier, it is determined that the account transfer request does not satisfy the consumption authority.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

Obtaining a deposit request, the deposit request including the account identifier, the consumption type, and the deposit amount;

Determining the smart contract according to the account identifier, the consumption type, and the deposit amount;

The deposit request and the smart contract are synchronized to the blockchain.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

Synchronizing the deposit request to the blockchain;

Synchronizing the smart contract to the blockchain;

Wherein, synchronizing the smart contract to the blockchain includes:

Encrypt the smart contract using a private key to obtain the encrypted smart contract;

The encrypted smart contract is synchronized to the blockchain.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

If the consumption amount is greater than the consumption limit, a prompt message is generated, wherein the prompt message is used to prompt that the transfer fails.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

The updated consumption limit is determined according to the consumption limit and the consumption amount.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

A reminder message is generated according to the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In a possible design, in an implementation manner of the third aspect of the embodiment of the present application, the processor is used to execute the program in the memory, further comprising the following steps:

Acquire historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

According to the account identifier in the account transfer request, the consumption type and the historical consumption record, the consumption limit corresponding to the consumption type is determined through the smart contract.

A fourth aspect of the present application provides a computer-readable storage medium, comprising instructions, which, when executed on a computer, enables the computer to execute the method of the first aspect.

It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

The embodiment of the present application provides a method for consumption processing and a related device. The method specifies the consumption authority of an account through a smart contract of a blockchain, so that when a user transfers money for consumption on the blockchain, the user must comply with the consumption authority of the smart contract to realize the transfer consumption. According to the embodiment of the present application, the user plans and arranges the use of funds through a smart contract, which is safe and reliable, and solves the problem that planning and arranging through a memo is unreliable and the memo is easy to lose.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a system architecture diagram of an embodiment of the present application;

FIG2 is a flow chart of a consumption processing method provided in an embodiment of the present application;

FIG3 is a schematic diagram of an account transfer request in an embodiment of the present application;

FIG4 is an interface diagram of an embodiment of the present application in which a user transfers money to a merchant by scanning the merchant's QR code;

FIG5 is an interface diagram of a user client when a merchant scans a barcode on a user's client to transfer money according to an embodiment of the present application;

FIG6 is a schematic diagram of an interface for a user to pay directly to a merchant account in an embodiment of the present application;

FIG7 is a schematic diagram of a smart contract in an embodiment of the present application;

FIG8 is a network topology diagram of a distributed blockchain ledger in an embodiment of the present application;

FIG9 is a schematic diagram of a user, a merchant, and a blockchain in an embodiment of the present application;

FIG10 is a schematic diagram of a blockchain ledger according to an embodiment of the present application;

FIG11 is a schematic diagram of a consumption record of account identification 1 in an embodiment of the present application;

FIG12 is a schematic diagram of an interface for user deposits in an embodiment of the present application;

FIG13 is a schematic diagram of a parent depositing money into a child's account in an embodiment of the present application;

FIG14 is a schematic diagram of a terminal device prompting a transfer failure in an embodiment of the present application;

FIG15 is a schematic diagram of an updated smart contract according to an embodiment of the present application;

FIG16 is an interface diagram of a terminal device displaying a consumption plan in an embodiment of the present application;

FIG17 is a flow chart of a consumption processing method provided in an embodiment of the present application;

FIG18 is a schematic diagram of a payment interface of a terminal device in an embodiment of the present application;

FIG19 is a schematic diagram of an application example of a consumption processing method;

FIG20 is a schematic diagram of a consumption processing device provided in an embodiment of the present application;

FIG21 is another schematic diagram of a consumption processing device provided in an embodiment of the present application;

FIG. 22 is a block diagram of a partial structure of a mobile phone related to the terminal provided in an embodiment of the present application

Figure 23 is a schematic diagram of a server structure provided in an embodiment of the present application.

DETAILED DESCRIPTION

The embodiment of the present application provides a consumption processing method and related devices for limiting the consumption authority of funds from the transaction process, thereby solving the problem that the memo method is unreliable and the memo is easily lost.

The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "corresponding to" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

It should be understood that electronic payment is widely used in people's daily lives and has greatly improved people's lives. People can complete the payment and transfer process through terminal devices such as mobile phones or computers. However, some consumers with poor self-control are prone to impulse consumption. For example, a consumer plans to use 900 yuan as food expenses per month. However, faced with the temptation of delicious food, the consumer finally used 2,000 yuan for meals and snacks, which completely exceeded the consumer's plan and made the consumer miserable. In addition, many parents open electronic payment accounts specifically for their children to facilitate their children's lives. For example, they can use electronic payment to get food in the canteen, buy stationery, take public transportation, etc. These children may not be able to withstand the temptation and use the money originally used for meals to buy toys. Therefore, it is necessary for consumers to manage the use of funds in their electronic payment accounts.

Currently, consumers generally write down their financial plans on a memo and then check the financial plans in their memo before making electronic payments to determine whether they should make the electronic payment. However, many consumers often forget to check the memo, which results in forgetting their financial plans and making erroneous payments. In addition, consumers may lose their mobile phones and thus lose the electronic memos in their mobile phones, or consumers may use paper memos, which are more likely to be lost.

In order to solve the above problems, the embodiments of the present application provide a consumption processing method and related devices, which can restrict electronic payments from the process of electronic payment. Consumers can only realize electronic payment consumption when the set rules are met.

FIG1 is a system architecture diagram of an embodiment of the present application. It can be seen that the user conducts a transfer transaction with the merchant through a terminal device. The type of terminal device used by the user is the same as the type of terminal device used by the merchant. These terminal devices may include but are not limited to mobile phones, desktop computers, tablet computers, laptop computers, and PDAs. These terminal devices are interconnected through servers on the network to complete electronic transactions between users and merchants. Users can transfer money with merchants to purchase the required items or services from merchants, for example, user 1 transfers money with merchant 1, and user 1 transfers money with merchant 2. Users can also transfer money between each other, for example, user 1 transfers money with user 2, and user 1 transfers money with user 3.

It is understandable that the terminal device in FIG1 is generally installed with a client for electronic payment, which can be computer software, mobile phone software, applets, etc. Computer software can be a computer plug-in, browser, stock trading software, etc. Mobile phone software can be a shopping application (Application, APP), bank APP, third-party payment software APP, etc., and applets can be functional programs embedded in mobile phone software. In actual applications, other clients that can realize electronic payment can also be used, which are not limited here.

Based on the architecture shown in FIG1 , an embodiment of the present application provides a method for consumption processing, as shown in FIG2 , which is a flow chart of a method for consumption processing provided by an embodiment of the present application. The method is suitable for implementation in a scenario where a user and a merchant conduct face-to-face transactions. The method includes:

201. Obtain an account transfer request, where the account transfer request includes an account identifier and at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

In the embodiment of the present application, the account identifier can be an identity document (ID) of the account, or it can be a nickname of the account. In actual applications, it can also be other situations, which are not specifically limited here. The account identifier is specifically an account identifier used by the user for transfer consumption. The consumption type can be food expenses, transportation consumption, store consumption, etc., which can be set by the user or the administrator of the account system or other users. The location information can be based on mobile location service (location based service, LBS) information, which is obtained through the radio communication network of the telecommunications mobile operator (such as the global mobile communication system network, the code division multiple access communication system network) or the external positioning method (such as the global positioning system) The location information (geographic coordinates, or geodetic coordinates) of the mobile terminal user.

In some embodiments, the client or server obtains an account transfer request including an account identifier and a consumption type, as described below:

FIG3 is a schematic diagram of an account transfer request in an embodiment of the present application. It can be seen that the account transfer request includes an account identifier, a consumption type, and a consumption amount corresponding to the consumption type. The consumption amount is associated with the account identifier in the consumption and is associated with the consumption type of the consumption. For example, the consumption type of account A in the transfer consumption is food expenses, and the consumption amount is 10 yuan.

In the embodiment of the present application, a user arrives at a merchant's store, takes a fancy to a certain product and decides to buy it. The user can transfer money to the merchant through electronic payment to purchase the product. Alternatively, the user comes to the merchant's restaurant, eats and consumes and transfers money to the merchant. When the user transfers money to the merchant, he can transfer money to the merchant by scanning the merchant's QR code, or the merchant can transfer money by scanning the barcode on the user's client, or the user can pay directly to the merchant's account. The following will describe these three scenarios in detail:

FIG4 is an interface diagram of a user transferring money to a merchant by scanning a merchant's QR code in an embodiment of the present application. After the user scans the merchant's QR code through the client, the client can obtain information such as the merchant's identification, merchant nickname, consumption type, etc. from the QR code, and then the client displays the merchant's nickname on the client's interface, for example, "transfer to merchant (XXX)" is displayed on the client's interface, and the client automatically fills in the consumption type into the corresponding input area. The user can check whether the consumption type is correct. If it is not correct, the user can click on the input area and then modify it through the virtual keyboard. Then, the user can also fill in the transfer amount, payment password and other information. At the same time, the client can also display the account identification of the user for transfer, for example, "account for payment: xxx" is displayed on the client's interface. After the user confirms that the information is correct, click the "OK" virtual button, so that the client obtains the account transfer request, which may include the account identification of the user for transfer, the consumption type displayed on the client interface, the consumption amount, and generally also includes the merchant identification, payment password, etc.

In a possible embodiment, the client does not obtain the consumption type from the QR code, but obtains the consumption type corresponding to the merchant ID through the association relationship between the merchant ID and the consumption type stored in the server according to the merchant ID, and then automatically fills the consumption type into the corresponding area. The user can check whether the consumption type is correct. If it is not correct, the user can click on the input area and modify it through the virtual keyboard.

Table 1 shows the association between merchant IDs and consumption types. It can be seen that the client can query the corresponding consumption type through the merchant ID. The consumption type may include but is not limited to food expenses, store consumption, etc., and may also be transportation consumption, asset trading, etc., which are not specifically limited here. The consumption type can be set by the user himself or by the administrator of the account system, and then uploaded to the server for the user to choose.

Table 1

In a possible embodiment, the client does not obtain the consumption type from the QR code or the server, but allows the user to fill in the consumption type as shown in Figure 4. When the user clicks the input area corresponding to the consumption type, the consumption type can be entered through the virtual keyboard.

In the embodiment of the present application, the input area may be the area above the underline as shown in FIG. 4 , or the input area may be surrounded by a box, or other methods may be used, which are not specifically limited here.

FIG5 is an interface diagram of the user client when the merchant scans the barcode on the user's client to transfer money in an embodiment of the present application. It can be seen that a barcode or QR code is displayed on the user client, as well as the account for payment: xxx. The user can click "Account for payment: xxx" so that the client pops up the user's other account selection interface for the user to choose. After the merchant scans the interface shown in FIG3 through the terminal device, the account identification and other information for payment can be obtained from the user's client. The merchant's terminal device then generates an account transfer request, which may include the user's account identification, consumption type, consumption amount, etc., as well as the merchant identification. It is understandable that after the merchant's terminal device generates the account transfer request, it can send the account transfer request to the user's client to display its content.

In a possible embodiment, the merchant's terminal device only uploads the user's account ID, consumption amount, merchant ID, etc. to the server, and then the server obtains the consumption type corresponding to the merchant ID through the association relationship between the merchant ID and the consumption type stored in the server according to the merchant ID. Finally, the server generates an account transfer request, which may include the user's account ID, consumption type, consumption amount, etc., and the merchant ID. It is understandable that after the server generates the account transfer request, it can send the account transfer request to the user's client to display its content.

In a possible embodiment, the merchant's terminal device sends the user's account ID, consumption type, consumption amount, merchant ID, etc. to the user's client through the server, and after the user enters the payment password and confirms, the user's client obtains the account transfer request. The account transfer request may include the user's account ID, consumption type, consumption amount, payment password, etc., and the merchant ID.

Figure 6 is a schematic diagram of the interface for a user to pay directly to a merchant account in an embodiment of the present application. The merchant only provides the merchant's own account ID to the user. The merchant does not have a QR code or a terminal device for scanning. The user needs to enter the merchant's account, consumption type, consumption amount, payment password, etc. into the client. After the user clicks the "OK" virtual button, the client obtains an account transfer request, which may include the user's account ID, consumption type, consumption amount, payment password, etc., as well as the merchant's account ID.

In actual applications, the client can also obtain the account transfer request through other methods, which will not be described in detail here.

In other embodiments, the client or server may obtain an account transfer request including an account identifier and a consumption type, which is similar to the aforementioned embodiment and will not be described in detail here.

In other embodiments, the client or server may obtain an account transfer request including an account identifier and location information, wherein the method for obtaining the account identifier is similar to the aforementioned embodiment and will not be repeated here.

In the embodiment of the present application, the client or server can obtain the location information based on the radio communication network (such as the global system for mobile communications network, the code division multiple access digital cellular system network) or the external positioning method (such as the global positioning system), wherein the global system for mobile communications (global system for mobile communications, GSM) can be called the second generation (2G) mobile phone system, the code division multiple access (code division multiple access, CDMA) communication system network is a mobile phone system, and the global positioning system (global positioning system, GPS) is a system that provides positioning services. In actual applications, the client or server can also obtain the location information of the client through other methods, which are not specifically limited here.

202. According to the account transfer request, the consumption authority is determined through the smart contract, and the consumption authority has a corresponding relationship with the account identifier;

In the embodiment of the present application, the consumption authority includes but is not limited to at least one of a consumption limit corresponding to a consumption type, a consumption type restriction condition corresponding to an account identifier, and a location information restriction condition corresponding to an account identifier;

In some embodiments, the client or server determines the consumption limit corresponding to the consumption type through a smart contract, as described below:

In the embodiment of the present application, the smart contract is pre-set by the user in the blockchain, as shown in Figure 7, and the smart contract generally includes an account identifier, a consumption type, and a consumption limit. Figure 7 is a schematic diagram of a smart contract in the embodiment of the present application. It can be seen that the smart contract can include multiple consumption types, such as consumption type 1 and consumption type 2, which correspond to different consumption limits. For example, the consumption limit for food expenses in account A can be 100, and the consumption limit for transportation consumption in account A can be 200.

After the terminal device receives the account transfer request, it can find the corresponding consumption limit from the smart contract according to the account transfer request. For example, if the account identifier in the account transfer request is account A and the consumption type is transportation consumption, it can be found from the smart contract that the consumption limit for transportation consumption in account A is 200 according to the account identifier and consumption type.

In other embodiments, the client or server determines the consumption type restriction condition corresponding to the account identifier through a smart contract, as described below:

In the embodiment of the present application, the smart contract is set by the user in advance in the blockchain, and the smart contract may include the consumption type restriction condition corresponding to the account identifier. In some embodiments, parents can set the consumption type restriction condition corresponding to their children's accounts in the smart contract as the allowed consumption types including food expenses, school supplies or snacks. Then when the children use their accounts to consume, the consumption type restriction condition corresponding to the account can be determined by the smart contract, and compared with the current consumption type. If the current consumption type meets the consumption type restriction condition, the consumption can be completed. For example, the current consumption type of the account is food expenses, and the client or server determines that the food expenses belong to one of the consumption type restrictions (including food expenses, school supplies or snacks), then the consumption can be completed. For another example, the current consumption type of the account is live broadcast reward, and the client or server determines that the food expenses do not belong to one of the consumption type restrictions (including food expenses, school supplies or snacks), then the consumption is not completed. In other embodiments, parents can set the consumption type restriction condition corresponding to their children's accounts in the smart contract as prohibited consumption types including watching pornographic films, live broadcast rewards, etc. When the child uses his account to make a purchase, if the current consumption type of the account is food expenses, which does not belong to the prohibited consumption types of the consumption type restriction conditions, the consumption can be completed; if the current consumption type of the account is live broadcast rewards, which belongs to the prohibited consumption types of the consumption type restriction conditions, the consumption will not be completed. In other embodiments, the consumption type restriction conditions include both permitted consumption types and prohibited consumption types, and the consumption process is similar to the above embodiments, which will not be repeated here.

In other embodiments, the client or server determines the location information restriction condition corresponding to the account identifier through a smart contract, as described below:

In the embodiment of the present application, the smart contract is pre-set by the user in the blockchain, and the smart contract may include the location information restriction condition corresponding to the account identifier. In some embodiments, the user sets the location information restriction condition including the allowed location information. For example, the allowed location information may include but is not limited to department stores, restaurants, etc. When the user consumes, the user's current location information may be compared with the allowed location information. If the current location information belongs to the allowed location information, consumption can be carried out. For example, if the current location information is a restaurant, and the allowed location information includes a restaurant, consumption can be carried out. In other embodiments, the user sets the location information restriction condition including prohibited location information. For example, the prohibited location information may include but is not limited to casino areas, pornographic places, etc. When the user consumes, the user's current location information may be compared with the prohibited location information. If the current location information belongs to the prohibited location information, consumption cannot be carried out. For example, if the current location information is a casino area, and the prohibited location information includes a casino area, consumption cannot be carried out. In other embodiments, the user sets the location information restriction condition including both allowed location information and prohibited location information. The consumption process is similar to the aforementioned embodiment and will not be repeated here. 203. If the account transfer request satisfies the consumption authority, the account transfer request is synchronized through the blockchain.

In the embodiment of the present application, the account transfer request meeting the consumption authority may include but is not limited to the consumption amount corresponding to the consumption type being less than or equal to the consumption limit corresponding to the consumption type, the consumption type meeting the consumption type restriction condition corresponding to the account identifier, and the location information meeting the location information restriction condition corresponding to the account identifier. In actual applications, other judgment conditions may also be included, which are not specifically limited here.

In some embodiments, after the terminal device determines the consumption limit, it can compare the consumption amount in the account transfer request with the consumption limit. If the consumption amount is less than or equal to the consumption limit, the account transfer request is synchronized through the blockchain.

Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. With the development of blockchain technology, blockchain technology has been widely used in various fields, such as finance, information security, computing resource sharing, entertainment games, social networking, supply chain management or medical fields.

In the blockchain, each organization jointly maintains a blockchain account book. For ease of introduction, please refer to Figure 8, which is a network topology diagram of a distributed blockchain account book in an embodiment of the present application. As shown in Figure 8, a distributed ledger is a database shared, copied and synchronized between network members. The distributed ledger records transactions between network participants, such as the exchange of assets or data. This shared ledger reduces the time and expense costs incurred by mediating different account books. The network members involved in this application include but are not limited to producers, consumers, suppliers, partners, market makers, promoters and other project stakeholders. The assets traded can be tangible physical assets (such as cars, houses or strawberries) or intangible virtual assets (such as contracts, patents and securities). The ownership and transfer of assets create value in the business network, and this process is called a transaction.

A distributed ledger is a database that is independently held and updated by each participant in a large network. The distribution is unique in that the records are not communicated to each node device by a central authority, but are independently constructed and saved by each node device. That is, every node device on the network processes every transaction, draws its own conclusions, and then votes on these conclusions to determine that the majority of node devices agree with them. Once consensus is reached, the distributed blockchain ledger has been updated and all node devices maintain the same copy of their own ledger. That is, as shown in Figure 2, node device 1 shares the local ledger of node device 1 with other node devices (such as node device 2, node device 3, node device 4, node device 5 and node device 6), node device 2 shares the local ledger of node device 2 with other node devices (such as node device 1, node device 3, node device 4, node device 5 and node device 6), node device 3 shares the local ledger of node device 3 with other node devices (such as node device 1, node device 2, node device 4, node device 5 and node device 6), node device 5 shares the local ledger of node device 5 with other node devices (such as node device 1, node device 2, node device 3, node device 4 and node device 6), node device 6 shares the local ledger of node device 6 with other node devices (such as node device 1, node device 2, node device 3, node device 4 and node device 5). At this point, node device 1, node device 2, node device 3, node device 4, node device 5 and node device 6 all maintain the same blockchain ledger, which includes data recorded by all node devices.

Based on the distributed blockchain ledger as shown in Figure 8, users and merchants in the embodiment of the present application can conduct transactions through the distributed blockchain ledger as shown in Figure 8. Users and merchants have their own accounts, and users and merchants can write their accounts and the amounts in their accounts on the blockchain ledger.

Figure 9 is a schematic diagram of users, merchants and blockchain in the embodiment of the present application. It can be seen that user 1, user 2, merchant 1, merchant 2, merchant 3, and merchant 4 are all connected to the blockchain, and they can synchronize the account transfer request to the blockchain. For example, user 1 transfers money with merchant 1, and the content of the account transfer request is that user 1 transfers 10 yuan of food expenses to merchant 1. Then user 1 and merchant 1 upload the account transfer request to the blockchain through the client. After the blockchain reaches a consensus through the consensus mechanism, the account transfer request is written to the blockchain account book, that is, the transfer of 10 yuan of food expenses from user 1 to merchant 1 is written on the blockchain account book, and the result can be obtained that user 1's account is reduced by 10 yuan, and merchant 1's account is increased by 10 yuan.

After the terminal device synchronizes the account transfer request through the blockchain, the account transfer record corresponding to the account transfer request is added to the blockchain account book, as shown in Figure 10. Figure 10 is a schematic diagram of the blockchain account book of the embodiment of the present application. The blockchain account book includes records corresponding to several account identifiers. Figure 10 only shows some of the parameters. It can be seen from Figure 10 that the user deposits 100 yuan to account identifier 1, and the deposit amount is 100. The corresponding consumption type is food expenses, indicating that the 100 yuan deposit is used for food expenses. Account identifier 1 transfers 100 yuan to merchant identifier 1 in the consumption type of food expenses, and account identifier 1 transfers 5 yuan to merchant identifier 2 in the consumption type of transportation. The terminal device can read similar blockchain account book records from the blockchain account book, and then count the consumption records of account identifier 1 transferring outward according to these blockchain account book records. Figure 11 is a schematic diagram of the consumption record of account ID 1 in the embodiment of the present application. It can be seen that the terminal device obtains from the blockchain account book that account ID 1 has spent 100 yuan on the consumption type of food expenses, and account ID 1 has spent 5 yuan on the consumption type of transportation. Similarly, the terminal device can also count other situations of the account according to the blockchain account book, which will not be described in detail here. Optionally, in an optional embodiment of a consumption processing method corresponding to Figure 2 of the embodiment of the present application, before obtaining an account transfer request, the method also includes: obtaining a deposit request, the deposit request includes an account ID, a consumption type and a deposit amount; determining a smart contract based on the account ID, the consumption type and the deposit amount; synchronizing the deposit request and the smart contract to the blockchain.

In the embodiment of the present application, the terminal device first deposits money into the account and then consumes. The deposit method can be that the user enters a deposit request, as shown in Figure 12, which is a schematic diagram of the interface of the user deposit in the embodiment of the present application. The user fills in the account identification and deposit amount on the interface of the terminal device, and can also fill in the consumption type to limit the purpose of the deposit amount. For example, if the consumption type filled in is food expenses and the deposit amount is 100 yuan, then the 100 yuan deposited in this deposit can be specified for food expenses. Then, the user selects the bank card for payment and enters the bank password, and clicks the "OK" virtual button to generate a deposit request. After the terminal device obtains the deposit request, it can determine the smart contract according to the account identification, consumption type and deposit amount in the deposit request, where the deposit amount and the consumption limit are associated. For example, the deposit amount of account identification 1 in the deposit request is 100 yuan, and the consumption type is specified as food expenses, then the consumption limit of food expenses for account identification 1 added in the smart contract is increased by 100 yuan.

In a possible embodiment, the user may use a third-party payment software to make a deposit instead of a bank card. The deposit method is similar and will not be described in detail here.

In a possible embodiment, a user can use account A to deposit money into account B. For example, parents use their own accounts to deposit money into their children's accounts to limit the consumption type and consumption limit of their children's accounts. Figure 13 is a schematic diagram of parents depositing money into their children's accounts in an embodiment of the present application. It can be seen that the parents first fill in the account ID of the child in the account ID, then fill in the consumption type and deposit amount, and finally select their own account for payment, enter the payment password, and click the "OK" virtual button, then the terminal device can obtain the corresponding deposit request. After the terminal device obtains the deposit request, it can determine the smart contract based on the account ID, consumption type and deposit amount in the deposit request.

After the terminal device receives the deposit request and the smart contract, it synchronizes the deposit request and the smart contract to the blockchain. The synchronization method is similar to the synchronization of account transfer requests in other embodiments of the present application, and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to Figure 2 of the embodiment of the present application, synchronizing a deposit request and a smart contract to the blockchain includes: synchronizing a deposit request to the blockchain; synchronizing the smart contract to the blockchain; wherein synchronizing the smart contract to the blockchain includes: encrypting the smart contract by a private key to obtain an encrypted smart contract; and synchronizing the encrypted smart contract to the blockchain.

In the embodiment of the present application, the terminal device first encrypts the smart contract with a private key, and then synchronizes the encrypted smart contract to the blockchain. It is understandable that the encrypted smart contract is more secure and not easy to be stolen. When the terminal device needs to use the smart contract in the blockchain, it can be decrypted by a private key or a public key, which is not limited here.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 2 of the embodiment of the present application, after determining the consumption limit through a smart contract according to the account identifier and the consumption type in the account transfer request, the method further includes:

If the consumption amount is greater than the consumption limit, a prompt message is generated to indicate that the transfer has failed.

In the embodiment of the present application, when the user consumes, if the limit is exceeded, the transfer cannot be made, and the terminal device will prompt that the transfer failed. Figure 14 is a schematic diagram of the terminal device prompting the transfer failed in the embodiment of the present application. It can be seen that the user inputs the account transfer information to the terminal device. After the terminal device obtains the account transfer request, the corresponding consumption limit is determined through the smart contract. When the terminal device detects that the consumption amount is greater than the consumption limit, a prompt message is generated, so that the terminal device displays "transfer failed" on the interface. For example, the user is preparing to transfer 200 yuan to the restaurant, and the corresponding consumption type is food expenses. In the smart contract, the consumption limit of the account under the food expenses is only 100 yuan. The consumption amount is greater than the consumption limit, so that the terminal device cannot complete the transfer and prompts that the transfer failed. The user can click the "OK" virtual button on the terminal device interface to close the prompt message.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 2 of the embodiment of the present application, after requesting a transfer to the blockchain synchronization account, the method further includes:

The updated consumption limit is determined based on the consumption limit and the consumption amount.

In an embodiment of the present application, after the user transfers money for consumption, the terminal device can update the consumption limit in the smart contract according to the transfer consumption. Specifically, the consumption limit can be subtracted from the consumption amount to obtain the updated consumption limit. As shown in Figures 7 and 15, Figure 15 is a schematic diagram of the updated smart contract in the embodiment of the present application. It can be seen that the original consumption limit of the account in consumption type 1 is X. After the user consumes Y yuan in consumption type 1, the terminal device determines that the updated consumption limit of consumption type 1 is X-Y based on the consumption limit and the consumption amount. When the user continues to consume on this consumption type, the consumption limit continues to decrease until the consumption limit is used up or the user makes another deposit. For example, if a user deposits money into his account every other month for food expenses, when the user eats every day, the consumption limit in the smart contract decreases every day according to the amount of the user's meal consumption.

Similarly, when a user deposits money for himself, if there is a consumption limit in the corresponding consumption type, the terminal device adds the amount specified when the deposit is made to the consumption limit. For example, the original consumption limit of the account in consumption type 1 is X. The user deposits Y yuan into the account and specifies that the consumption type corresponding to the amount is consumption type 1. The terminal device determines the updated consumption limit of consumption type 1 as X+Y based on the consumption limit and the consumption amount.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 2 of the embodiment of the present application, the method further includes:

A reminder message is generated based on the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In the embodiment of the present application, if the user needs to view the consumption limit that he plans to use for a certain consumption type, the terminal device can display the consumption type and the consumption limit. Figure 16 is an interface diagram of the terminal device displaying the consumption plan in the embodiment of the present application. It can be seen that the terminal device can display the user's account identification and consumption type, and display the consumption limit corresponding to the consumption type. The user can intuitively see his consumption plan. For example, if the user plans to use 1,000 yuan of food expenses per month, he can view it through the interface as shown in Figure 16.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 2 of the embodiment of the present application, determining the consumption limit through a smart contract according to the account identifier and the consumption type in the account transfer request includes:

Obtain historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

The consumption limit is determined through a smart contract based on the account ID, consumption type, and historical consumption records in the account transfer request.

In the embodiment of the present application, the terminal device can first obtain the historical consumption record corresponding to the account identifier in the process of determining the smart contract, and then determine the consumption limit through the smart contract according to the account identifier in the account transfer request, the consumption type and the historical consumption record obtained by the terminal device. For example, all historical consumption records in account identifier 1 are that the user deposits 100 yuan to account identifier 1, and the corresponding consumption type is food expenses, indicating that the 100 yuan deposit is used for food expenses, account identifier 1 transfers 20 yuan to merchant identifier 1 in the consumption type of food expenses, and account identifier 1 transfers 30 yuan to merchant identifier 2 in the consumption type of food expenses. Then, based on these historical consumption records, the terminal device can determine that the account identifier 1 first deposited 100 yuan in the consumption type of food expenses, then consumed 20 yuan, and then consumed 30 yuan. It can be determined that the consumption limit of account identifier 1 in the consumption type of food expenses is 100-20-30=50 yuan.

Based on the architecture shown in FIG1 , the embodiment of the present application further provides a consumption processing method, as shown in FIG17 . FIG17 is a flow chart of a consumption processing method provided by the embodiment of the present application. The method is suitable for implementation in a scenario where a user shops online. The method includes:

1701. Obtain an account transfer request, where the account transfer request includes an account identifier, a consumption type, and a consumption amount corresponding to the consumption type;

In the embodiment of the present application, when the user is shopping online, if he is ready to buy the goods in the shopping cart, he can enter the corresponding payment interface, as shown in Figure 18, which is a schematic diagram of the payment interface of the terminal device in the embodiment of the present application. It can be seen that the consumption type of commodity 1 and the corresponding consumption amount are displayed on the terminal device. The consumption amount is the price of commodity 1/the discounted price, which is used to indicate how much money is used to purchase commodity 1 in this consumption. If there are other commodities in the shopping cart, such as commodity 2 and commodity 3, they are all displayed one by one on the payment interface. After the user selects the payment account and enters the payment password, he can click the "OK" virtual button so that the terminal device obtains the account transfer request. In a possible embodiment, the user can directly purchase the commodity instead of putting it in the shopping cart and enter the payment interface. The payment interface only displays the consumption type and consumption amount of commodity 1.

In a possible embodiment, the user does not need to manually input the consumption type of the product. Instead, the terminal device automatically finds the consumption type corresponding to the product based on the product identification of the product. Specifically, the consumption type corresponding to the product is found based on the association between the consumption type of the product and the product identification. Table 2 is a table of associations between product identifications and consumption types in the embodiment of the present application. As shown in Table 2, the consumption type corresponding to the cake is meal expenses, and the consumption type corresponding to the toothbrush is daily necessities consumption. In actual applications, several associations can also be set. These associations can be pre-set and stored in the terminal device or the server of the e-commerce platform.

Table 2

Product identification Consumption Type cake Meal expenses toothbrush Daily necessities consumption … …

In the embodiments of the present application, the terminal device for online shopping may be a mobile phone or a computer. In actual applications, it may also be a tablet or other device, which is not specifically limited here.

1702. According to the account identifier and the consumption type in the account transfer request, the consumption limit is determined through the smart contract, and the consumption limit is associated with the account identifier, and the consumption limit is associated with the consumption type;

In the embodiment of the present application, step 1702 is similar to step 202 in each embodiment corresponding to FIG. 2 above, and will not be repeated here.

1703. If the consumption amount is less than or equal to the consumption limit, the account transfer request is synchronized through the blockchain.

In an embodiment of the present application, the account transfer request includes the transfer of multiple commodities, wherein the consumption types of the multiple commodities may be the same. For example, the consumption type of commodity 1 is the same as the consumption type of commodity 2, and the terminal device adds the consumption amount of commodity 1 to the consumption amount of commodity 2 as the consumption amount of the consumption type. For example, if a user buys cake and ice cream, both of which belong to the consumption type of food expenses, the terminal device can determine the consumption amount corresponding to the consumption type as the consumption amount of cake plus the consumption amount of ice cream according to the commodity. Then, the terminal device compares the consumption amount corresponding to the consumption type after statistics with the consumption limit. If the consumption amount is less than or equal to the consumption limit, the terminal device synchronizes the account transfer request through the blockchain.

The details of the terminal device synchronizing the account transfer request through the blockchain are similar to step 203 in each embodiment corresponding to Figure 2 above, and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to Figure 17 of the embodiment of the present application, before obtaining an account transfer request, the method also includes: obtaining a deposit request, the deposit request including an account identifier, a consumption type and a deposit amount; determining a smart contract based on the account identifier, the consumption type and the deposit amount; and synchronizing the deposit request and the smart contract to the blockchain.

Optionally, in an optional embodiment of a consumption processing method corresponding to Figure 17 of the embodiment of the present application, synchronizing a deposit request and a smart contract to the blockchain includes: synchronizing a deposit request to the blockchain; synchronizing the smart contract to the blockchain; wherein synchronizing the smart contract to the blockchain includes: encrypting the smart contract by a private key to obtain an encrypted smart contract; synchronizing the encrypted smart contract to the blockchain.

In the embodiment of the present application, the steps of the terminal device for depositing and encrypting the private key are similar to the various embodiments corresponding to the aforementioned FIG. 2 , and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 17 of the embodiment of the present application, after determining the consumption limit through a smart contract according to the account identifier and the consumption type in the account transfer request, the method further includes:

If the consumption amount is greater than the consumption limit, a prompt message is generated to indicate that the transfer has failed.

In the embodiment of the present application, the situation where the terminal device prompts that the transfer failed is similar to the various embodiments corresponding to the aforementioned Figure 2, and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 17 of the embodiment of the present application, after requesting a transfer to the blockchain synchronization account, the method further includes:

The updated consumption limit is determined based on the consumption limit and the consumption amount.

In the embodiment of the present application, the situation in which the terminal device updates the consumption limit is similar to the various embodiments corresponding to the aforementioned FIG. 2 , and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 17 of the embodiment of the present application, the method further includes:

A reminder message is generated based on the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In the embodiment of the present application, the situation in which the terminal device displays the consumption limit is similar to the various embodiments corresponding to the aforementioned FIG. 2 , and will not be repeated here.

Optionally, in an optional embodiment of a consumption processing method corresponding to FIG. 2 of the embodiment of the present application, determining the consumption limit through a smart contract according to the account identifier and the consumption type in the account transfer request includes:

Obtain historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

The consumption limit is determined through a smart contract based on the account ID, consumption type, and historical consumption records in the account transfer request.

In the embodiment of the present application, the situation in which the terminal device determines the consumption limit is similar to the various embodiments corresponding to the aforementioned FIG. 2 , and will not be repeated here.

In a possible embodiment, the user connects to the server through a terminal device, and the terminal device generates an account transfer request and sends the account transfer request to the server. After receiving the account transfer request, the server executes the method of each embodiment corresponding to FIG2 or FIG17. The user's terminal device only needs to generate and send an account transfer request, which reduces the burden on the user's terminal device, and the server can manage the account transfer status of each terminal device.

FIG19 is a schematic diagram of an application example of a consumption processing method. It can be seen that in this application example, the terminal device signs a smart contract in advance. The smart contract is similar to the description corresponding to FIG7 and will not be repeated here. After the terminal device signs the smart contract, the smart contract is synchronized to the blockchain.

The user needs to consume and generates user consumption behavior. The terminal device generates an account transfer request and obtains the smart contract and historical consumption of the account from the network. Then the terminal device determines the consumption limit based on the smart contract and historical consumption, and further determines whether the current payment behavior satisfies the smart contract, that is, whether the account transfer request satisfies the smart contract. If so, the payment is successful and the data is synchronized to the blockchain. If not, the payment fails. The terminal device can prompt the payment failure information on the interface, as shown in Figure 14.

FIG. 20 is a schematic diagram of a consumption processing device provided in an embodiment of the present application. It can be seen that a consumption processing device 2000 provided in an embodiment of the present application includes:

An acquisition unit 2001 is used to acquire an account transfer request, where the account transfer request includes an account identifier, and the account transfer request also includes at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

The processing unit 2002 is used to determine the consumption authority through the smart contract according to the account transfer request, and the consumption authority has a corresponding relationship with the account identifier;

The processing unit 2002 is also used to synchronize the account transfer request through the blockchain if the account transfer request meets the consumption authority.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 20 of the embodiment of the present application, a deposit unit 2003 is further included, as shown in FIG. 21 , which is another schematic diagram of a consumption processing device provided by the embodiment of the present application, and the deposit unit 2003 is used to:

Get a deposit request, which includes account ID, consumption type, and deposit amount;

Determine the smart contract based on the account ID, consumption type and deposit amount;

Sync the deposit request and smart contract to the blockchain.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 21 of the embodiment of the present application, the deposit unit 2003 is further used for:

Synchronize deposit request to blockchain;

Synchronize smart contracts to the blockchain;

Among them, synchronizing smart contracts to the blockchain includes:

Encrypt the smart contract with the private key to obtain the encrypted smart contract;

Synchronize the encrypted smart contract to the blockchain.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 20 of the embodiment of the present application, the processing unit 2002 is further used for:

If the consumption amount is greater than the consumption limit, a prompt message is generated to indicate that the transfer has failed.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 20 of the embodiment of the present application, the processing unit 2002 is further used for:

The updated consumption limit is determined based on the consumption limit and the consumption amount.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 20 of the embodiment of the present application, the processing unit 2002 is further used for:

A reminder message is generated based on the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

Optionally, in an optional embodiment of a consumption processing device corresponding to FIG. 20 of the embodiment of the present application, the processing unit 2002 is further used for:

Obtain historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

The consumption limit is determined through a smart contract based on the account ID, consumption type, and historical consumption records in the account transfer request.

The embodiment of the present application further provides a node device, which may be a terminal device or a server. The case where the node device is a terminal device is described in detail below:

The embodiment of the present application also provides another consumption processing device, as shown in FIG22. For the sake of convenience, only the part related to the embodiment of the present application is shown. For specific technical details not disclosed, please refer to the method part of the embodiment of the present application. The terminal can be any terminal device including a mobile phone, a tablet computer, a personal digital assistant (PDA), a point of sales (POS), a car computer, etc., taking the mobile phone as an example:

FIG22 is a block diagram showing a partial structure of a mobile phone related to a terminal provided in an embodiment of the present application. Referring to FIG22 , the mobile phone includes: a radio frequency (RF) circuit 2210, a memory 2220, an input unit 2230, a display unit 2240, a sensor 2250, an audio circuit 2260, a wireless fidelity (WiFi) module 2270, a processor 2280, and a power supply 2290 and other components. It can be understood by those skilled in the art that the mobile phone structure shown in FIG22 does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

The following is a detailed introduction to the various components of the mobile phone in conjunction with Figure 22:

The RF circuit 2210 can be used for receiving and sending signals during the process of sending and receiving information or making calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 2280 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit 2210 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (LNA), a duplexer, etc. In addition, the RF circuit 2210 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communication can use any communication standard or protocol, including but not limited to the global system of mobile communication (GSM), general packet radio service (GPRS), code division multiple access (CDMA), wideband code division multiple access (WCDMA), long term evolution (LTE), email, short messaging service (SMS), etc.

The memory 2220 can be used to store software programs and modules. The processor 2280 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 2220. The memory 2220 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 2220 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

The input unit 2230 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 2230 may include a touch panel 2231 and other input devices 2232. The touch panel 2231, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 2231 or near the touch panel 2231 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 2231 may include a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into contact coordinates, and then sends it to the processor 2280, and can receive and execute commands sent by the processor 2280. In addition, the touch panel 2231 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 2231, the input unit 2230 may also include other input devices 2232. Specifically, the other input devices 2232 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, etc.

The display unit 2240 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 2240 may include a display panel 2241, and optionally, the display panel 2241 may be configured in the form of a liquid crystal display (LCD), an organic light-emitting diode (OLED), etc. Further, the touch panel 2231 may cover the display panel 2241, and when the touch panel 2231 detects a touch operation on or near it, it is transmitted to the processor 2280 to determine the type of the touch event, and then the processor 2280 provides a corresponding visual output on the display panel 2241 according to the type of the touch event. Although in Figure 22, the touch panel 2231 and the display panel 2241 are used as two independent components to realize the input and output functions of the mobile phone, in some embodiments, the touch panel 2231 and the display panel 2241 can be integrated to realize the input and output functions of the mobile phone.

The mobile phone may also include at least one sensor 2250, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 2241 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 2241 and/or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

The audio circuit 2260, the speaker 2261, and the microphone 2262 can provide an audio interface between the user and the mobile phone. The audio circuit 2260 can transmit the received audio data to the speaker 2261 after converting the electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 2262 converts the collected sound signal into an electrical signal, which is received by the audio circuit 2260 and converted into audio data, and then the audio data is output to the processor 2280 for processing, and then sent to another mobile phone through the RF circuit 2210, or the audio data is output to the memory 2220 for further processing.

WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages, and access streaming media through the WiFi module 2270, which provides users with wireless broadband Internet access. Although FIG. 22 shows the WiFi module 2270, it is understandable that it is not a necessary component of the mobile phone and can be omitted as needed without changing the essence of the invention.

The processor 2280 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. It executes various functions of the mobile phone and processes data by running or executing software programs and/or modules stored in the memory 2220 and calling data stored in the memory 2220. Optionally, the processor 2280 may include one or more processing units; optionally, the processor 2280 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 2280.

The mobile phone also includes a power supply 2290 (such as a battery) for supplying power to various components. Optionally, the power supply can be logically connected to the processor 2280 through a power management system, thereby managing functions such as charging, discharging, and power consumption management through the power management system.

Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

Obtaining an account transfer request, the account transfer request including an account identifier, and the account transfer request also including at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

According to the account transfer request, the consumption authority is determined through the smart contract, and the consumption authority has a corresponding relationship with the account identification;

If the account transfer request meets the consumption authority, the account transfer request is synchronized through the blockchain;

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

Get a deposit request, which includes account ID, consumption type, and deposit amount;

Determine the smart contract based on the account ID, consumption type and deposit amount;

Sync the deposit request and smart contract to the blockchain.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

Synchronize deposit request to blockchain;

Synchronize smart contracts to the blockchain;

Among them, synchronizing smart contracts to the blockchain includes:

Encrypt the smart contract with the private key to obtain the encrypted smart contract;

Synchronize the encrypted smart contract to the blockchain.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

If the consumption amount is greater than the consumption limit, a prompt message is generated to indicate that the transfer has failed.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

The updated consumption limit is determined based on the consumption limit and the consumption amount.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

A reminder message is generated based on the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In the embodiment of the present application, the processor 2280 included in the terminal also has the following functions:

Obtain historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

The consumption limit is determined through a smart contract based on the account ID, consumption type, and historical consumption records in the account transfer request.

The following describes in detail the case where the node device is a server:

23 is a schematic diagram of a server structure provided by an embodiment of the present application. The server 2300 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 2322 (for example, one or more processors) and memory 2332, and one or more storage media 2330 (for example, one or more mass storage devices) storing application programs 2342 or data 2344. Among them, the memory 2332 and the storage medium 2330 may be temporary storage or permanent storage. The program stored in the storage medium 2330 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 2322 may be configured to communicate with the storage medium 2330 to execute a series of instruction operations in the storage medium 2330 on the server 2300.

The server 2300 may also include one or more power supplies 2326, one or more wired or wireless network interfaces 2350, one or more input and output interfaces 2358, and/or one or more operating systems 2341, such as Windows Server ^™ , Mac OS X ^™ , Unix ^™ , Linux ^™ , FreeBSD ^™ , etc.

The steps executed by the server in the above embodiment can be based on the server structure shown in Figure 23.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

Obtaining an account transfer request, the account transfer request including an account identifier, and the account transfer request also including at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information;

According to the account transfer request, the consumption authority is determined through the smart contract, and the consumption authority has a corresponding relationship with the account identification;

If the account transfer request meets the consumption authority, the account transfer request is synchronized through the blockchain;

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

Get a deposit request, which includes account ID, consumption type, and deposit amount;

Determine the smart contract based on the account ID, consumption type and deposit amount;

Sync the deposit request and smart contract to the blockchain.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

Synchronize deposit request to blockchain;

Synchronize smart contracts to the blockchain;

Among them, synchronizing smart contracts to the blockchain includes:

Encrypt the smart contract with the private key to obtain the encrypted smart contract;

Synchronize the encrypted smart contract to the blockchain.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

If the consumption amount is greater than the consumption limit, a prompt message is generated to indicate that the transfer has failed.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

The updated consumption limit is determined based on the consumption limit and the consumption amount.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

A reminder message is generated based on the consumption limit in the smart contract, and the reminder message is used to display the consumption limit.

In the embodiment of the present application, the central processor 2322 may further perform the following steps:

Obtain historical consumption records according to the account identifier in the account transfer request, where the historical consumption records are associated with the account identifier;

The consumption limit is determined through a smart contract based on the account ID, consumption type, and historical consumption records in the account transfer request.

Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program code.

Claims (10)

1. A consumption processing method, characterized by comprising: Obtain a deposit request, the deposit request including an account identifier, a consumption type, and a deposit amount; Determine a smart contract according to the account identifier, consumption type and deposit amount in the deposit request; the consumption type in the smart contract is used to limit the purpose of the deposit amount; the deposit amount is used to increase the consumption limit of the account identifier in the smart contract under the consumption type; The deposit request and the smart contract are synchronized to the blockchain; the user terminal and the merchant terminal are both connected to the blockchain, and transactions are performed based on the blockchain; Obtaining an account transfer request, the account transfer request including the account identifier and the merchant identifier, the account transfer request also including at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information; the consumption type in the account transfer request is determined according to an association between the merchant identifier and the consumption type; Determining the consumption authority through a smart contract according to the account transfer request specifically includes: obtaining historical consumption records according to the account identifier in the account transfer request, wherein the historical consumption records are associated with the account identifier; determining the consumption limit corresponding to the consumption type in the account transfer request through a smart contract according to the account identifier, the consumption type and the historical consumption records in the account transfer request, wherein the consumption authority is associated with the account identifier; the consumption authority includes at least one of the consumption limit corresponding to the consumption type, the consumption type restriction condition corresponding to the account identifier and the location information restriction condition corresponding to the account identifier; the smart contract includes multiple consumption types, and the multiple consumption types correspond to different consumption limits; the consumption type restriction condition includes permitted consumption types; the location information restriction condition includes permitted location information for consumption; Acquire the consumption type, the consumption amount corresponding to the consumption type, and the location information in the account transfer request according to the account transfer request; If the consumption type in the account transfer request satisfies the consumption type restriction condition corresponding to the account identifier, the consumption amount corresponding to the consumption type in the account transfer request is less than or equal to the consumption limit corresponding to the consumption type in the account transfer request, and the location information in the account transfer request satisfies the location information restriction condition corresponding to the account identifier, then it is determined that the account transfer request satisfies the consumption authority; otherwise, it is determined that the account transfer request does not satisfy the consumption authority, wherein the consumption type restriction condition corresponding to the account identifier, the consumption limit corresponding to the consumption type, and the location information restriction condition corresponding to the account identifier are all determined by the smart contract; If the account transfer request satisfies the consumption authority, the account transfer request uploaded by the user terminal and the merchant terminal is obtained through the blockchain, and after the blockchain reaches a consensus through a consensus mechanism, the account transfer request is synchronized on the blockchain, and the consumption limit in the updated smart contract is determined according to the consumption limit and the consumption amount. 2. The method according to claim 1, wherein synchronizing the deposit request and the smart contract to the blockchain comprises: Synchronizing the deposit request to the blockchain; Synchronizing the smart contract to the blockchain; Wherein, synchronizing the smart contract to the blockchain includes: Encrypt the smart contract using a private key to obtain the encrypted smart contract; The encrypted smart contract is synchronized to the blockchain. 3. The method according to claim 1, characterized in that after determining the consumption authority through a smart contract according to the account transfer request, the method further comprises: If the consumption amount is greater than the consumption limit, a prompt message is generated, wherein the prompt message is used to prompt that the transfer fails. 4. The method according to claim 1, characterized in that the method further comprises: A reminder message is generated according to the consumption limit in the smart contract, and the reminder message is used to display the consumption limit. 5. A consumption processing device, characterized in that it includes: A deposit unit is used to obtain a deposit request, wherein the deposit request includes an account identifier, a consumption type, and a deposit amount; determine a smart contract according to the account identifier, the consumption type, and the deposit amount in the deposit request; the consumption type in the smart contract is used to limit the purpose of the deposit amount; the deposit amount is used to increase the consumption limit of the account identifier in the smart contract under the consumption type; synchronize the deposit request and the smart contract to the blockchain; both the user terminal and the merchant terminal are connected to the blockchain, and transactions are conducted based on the blockchain; an acquisition unit, configured to acquire an account transfer request, wherein the account transfer request includes the account identifier and the merchant identifier, and the account transfer request also includes at least one of a consumption type, a consumption amount corresponding to the consumption type, and location information; the consumption type in the account transfer request is determined according to an association between the merchant identifier and the consumption type; A processing unit, configured to determine consumption authority through a smart contract according to the account transfer request, specifically comprising: obtaining historical consumption records according to the account identifier in the account transfer request, wherein the historical consumption records are associated with the account identifier; determining a consumption limit corresponding to the consumption type in the account transfer request through a smart contract according to the account identifier, the consumption type and the historical consumption records in the account transfer request, wherein the consumption authority is associated with the account identifier; the consumption authority comprises at least one of a consumption limit corresponding to the consumption type, a consumption type restriction condition corresponding to the account identifier and a location information restriction condition corresponding to the account identifier; the smart contract comprises a plurality of consumption types, and the plurality of consumption types correspond to different consumption limits; the consumption type restriction condition comprises permitted consumption types; and the location information restriction condition comprises permitted location information for consumption; The processing unit is further configured to obtain, according to the account transfer request, a consumption type, a consumption amount corresponding to the consumption type, and location information in the account transfer request; if the consumption type in the account transfer request satisfies the consumption type restriction condition corresponding to the account identifier, the consumption amount corresponding to the consumption type in the account transfer request is less than or equal to the consumption limit corresponding to the consumption type, and the location information in the account transfer request satisfies the location information restriction condition corresponding to the account identifier, then it is determined that the account transfer request satisfies the consumption authority; otherwise, it is determined that the account transfer request does not satisfy the consumption authority, wherein the consumption type restriction condition corresponding to the account identifier, the consumption limit corresponding to the consumption type, and the location information restriction condition corresponding to the account identifier are all determined by the smart contract; The processing unit is further configured to obtain, through the blockchain, the account transfer request uploaded by the user terminal and the merchant terminal if the account transfer request satisfies the consumption authority, and synchronize the account transfer request on the blockchain after the blockchain reaches a consensus through a consensus mechanism, and determine the consumption limit in the updated smart contract according to the consumption limit and the consumption amount. 6. The device according to claim 5, characterized in that the deposit unit is further used for: Synchronizing the deposit request to the blockchain; Synchronizing the smart contract to the blockchain; Wherein, synchronizing the smart contract to the blockchain includes: Encrypt the smart contract using a private key to obtain the encrypted smart contract; The encrypted smart contract is synchronized to the blockchain. 7. The device according to claim 5, characterized in that the processing unit is further used for: If the consumption amount is greater than the consumption limit, a prompt message is generated, wherein the prompt message is used to prompt that the transfer fails. 8. The device according to claim 5, characterized in that the processing unit is further used for: A reminder message is generated according to the consumption limit in the smart contract, and the reminder message is used to display the consumption limit. 9. A node device, comprising: a memory, a transceiver, a processor and a bus system; Wherein, the memory is used to store programs; The processor is used to execute the program in the memory to perform the method according to any one of claims 1 to 4; The bus system is used to connect the memory and the processor so that the memory and the processor can communicate with each other. 10 . A computer-readable storage medium, characterized by comprising instructions, which, when executed on a computer, enable the computer to execute the method according to claim 1 .