A method, device, storage medium and program product for offline recharging

Abstract

The application provides a method and device for offline charging, a storage medium and a program product, and relates to the field of communication services. The method comprises the following steps: receiving a charging request of a target user; wherein the target user is a user in an offline state; the charging request is used for requesting charging through a target charging platform; in the case that address information of the target charging platform is recorded in a white list, allocating network resources required for charging to the target user; and the white list is used for recording address information of resources allowed to be accessed by the user in the offline state. The application aims to solve the problem that the existing offline charging method cannot realize convenient and efficient charging.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of communication services, in particular to a method, device, storage medium and program product for offline recharge. BACKGROUND

[0002] At present, the problem of user offline due to arrears is widespread, which not only affects the normal use experience of users, but also poses a challenge to the service quality and user satisfaction of operators. Therefore, in order to improve the user experience, a convenient and efficient recharge solution is urgently needed.

[0003] The existing offline recharge method mainly modifies and upgrades network devices (such as packet data network gateways) to support state verification functions and specific redirection mechanisms, so as to achieve offline recharge. This method, to some extent, solves the problem that users cannot directly access network resources in the offline state, but has limitations such as high cost, single recharge mode, and insufficient flexibility, and is not convenient and efficient. SUMMARY

[0004] The present application provides a method, device, storage medium and program product for offline recharge, which do not need to modify and upgrade network devices, and can achieve convenient and efficient recharge in the offline state.

[0005] In a first aspect, the present application provides a method for offline recharge, applied to a gateway device, comprising: receiving a recharge request of a target user; wherein the target user is a user in an offline state; the recharge request is used to request recharge through a target recharge platform; in the case that the address information of the target recharge platform is recorded in a white list, allocating network resources required for recharge to the target user; the white list is used to record address information of resources allowed to be accessed by users in the offline state.

[0006] It can be understood that the offline recharge method provided by the present application does not involve modifying and upgrading network devices, and only needs to configure a relevant white list on the gateway device, so that the user can successfully access the network resources required for recharge. Therefore, the cost of the offline recharge method provided by the present application is lower than that of the existing offline recharge method. At the same time, the white list records the address information of resources allowed to be accessed by users in the offline state, so the user can flexibly choose the recharge mode or recharge platform he needs, as long as the address information of the recharge platform is recorded in the white list. In summary, the present application can achieve convenient and efficient recharge in the offline state.

[0007] In a possible implementation, the network resource required for the target user to perform the recharge is allocated in a case where address information of a target recharge platform is recorded in the white list, and the method comprises: sending a recharge request to a target server, so that the target server sends a recharge guide page to the target user in response to the recharge request.

[0008] In another possible implementation, after the network resource required for the target user to perform the recharge is allocated, the method further comprises: receiving a payment request sent by the target user, the payment request being used to request payment through a target payment platform; and sending the payment request to the target payment platform in a case where address information of the target payment platform is recorded in the white list.

[0009] In yet another possible implementation, the resource allowed to be accessed by the user in the downtime state and recorded in the white list is determined based on historical recharge behavior data analysis of a set of users; the set of users comprises the target user; and the recharge behavior data comprises resource data accessed by the user when performing the recharge operation.

[0010] In yet another possible implementation, the set of users is divided based on at least one of the following indicators: age, gender, education level, occupation, economic status, interest, social circle, region, and consumption habit.

[0011] In yet another possible implementation, the resource allowed to be accessed by the user in the downtime state and recorded in the white list is determined based on historical recharge behavior data of a set of users and a behavior prediction model; and the behavior prediction model is used to predict recharge behavior data of the user at a future time based on historical recharge behavior data of the user.

[0012] In yet another possible implementation, the behavior prediction model is trained by a preset training sample, the preset training sample comprises sample data and sample labels, the sample data is recharge behavior data of the set of users at a first historical time, and the sample labels are recharge behavior data of the set of users at a second historical time; and the first historical time is earlier than the second historical time.

[0013] In yet another possible implementation, the method further comprises: updating the white list in a case where the resource allowed to be accessed by the user in the downtime state is changed.

[0014] In yet another possible implementation, the network resource required for the target user to perform the recharge is allocated, and the method comprises: allocating the network resource required for the target user to perform the recharge according to network bandwidth usage and traffic distribution.

[0015] In a second aspect, the present application provides a method for recharging in a shutdown state, applied to a target server, and comprising: receiving a recharging request of a target user; wherein the target user is in a shutdown state; the recharging request is used to request recharging through a target recharging platform; the recharging request of the target user is sent to the target server under the condition that address information of the target recharging platform is recorded in a white list; and the white list is used to record address information of resources allowed to be accessed by the user in the shutdown state; and sending a recharging guide page to the target user in response to the recharging request of the target user.

[0016] It can be understood that it is very important for a user in the shutdown state to quickly recharge through a selected recharging platform and resume service. In the present application, a white list is configured on a gateway device, which records address information of resources allowed to be accessed by the user in the shutdown state, so that the user can flexibly select a recharging method or a recharging platform as needed. Further, under the condition that address information of a target recharging platform requested by the user is recorded in the white list, the target server in the present application can receive and respond to the recharging request of the user in the shutdown state, and timely provide a recharging guide page, so that the user can conveniently complete a recharging operation and quickly resume service use, thereby improving user experience. In summary, the present application can achieve convenient and efficient recharging in the shutdown state.

[0017] In a possible implementation, after the recharging guide page is sent to the target user, the method further comprises: querying whether a payment record of the target user is included in a block chain; the payment record is a record of a payment operation of the target user based on the recharging guide page; under the condition that the payment record of the target user is included in the block chain and a payment state of the target user is payment success, sending a notification message to a network side configuration server, the notification message being used to notify the network side configuration server to resume network access permission of the target user; and the payment record of the target user is written in the block chain by a payment platform through a smart contract.

[0018] In a third aspect, the present application provides a method for recharging in a shutdown state, applied to a terminal device, and comprising: sending a recharging request to a gateway device in response to a recharging request initiated by a target user; wherein the target user is in a shutdown state; the recharging request is used to request recharging through a target recharging platform; under the condition that address information of the target recharging platform is recorded in a white list, receiving a recharging guide page sent by a target server; the white list is used to record address information of resources allowed to be accessed by the user in the shutdown state; and recharging based on the recharging guide page.

[0019] It can be understood that the method for recharging in the offline state provided by the application enables the user to smoothly access the network resources required for recharging by configuring the relevant white list (the white list records the address information of the resources allowed to be accessed by the user in the offline state) on the gateway device, provides the offline user with various convenient recharging methods, enables the user to complete the recharging operation in the offline state, quickly restores the service, and reduces the inconvenience caused by the offline state. In summary, the application can conveniently and efficiently recharge in the offline state.

[0020] In a possible implementation, after the recharging is performed based on the recharging guide page, the method further includes: in response to a payment request initiated by the target user, sending the payment request to the gateway device; wherein the payment request is used to request payment through a target payment platform; and receiving a payment response message in a case where the address information of the target payment platform is recorded in the white list.

[0021] In another possible implementation, before the recharging request initiated by the target user is sent to the gateway device, the method further includes: predicting future recharging behavior data of the target user; the recharging behavior data includes resources accessed by the user when performing the recharging operation; and based on the future recharging behavior data of the target user, preloading the resources accessed by the target user when performing the recharging operation.

[0022] In another possible implementation, the future recharging behavior data of the target user is predicted by: based on the historical recharging behavior data of the target user and a behavior prediction model, obtaining the future recharging behavior data of the target user; wherein the behavior prediction model is used to predict the recharging behavior data of the user at a future time based on the historical recharging behavior data of the user.

[0023] In another possible implementation, the future recharging behavior data of the target user is predicted by: obtaining the future recharging behavior data of the target user predicted by a data analysis device; the future recharging behavior data of the target user is determined by the data analysis device based on the historical recharging behavior data of the target user and a behavior prediction model; and the behavior prediction model is used to predict the recharging behavior data of the user at a future time based on the historical recharging behavior data of the user.

[0024] In another possible implementation, the behavior prediction model is obtained by training a preset training sample, the preset training sample includes sample data and sample labels, the sample data is the recharging behavior data of a set of users at a first historical time, and the sample labels are the recharging behavior data of the set of users at a second historical time; wherein the first historical time is earlier than the second historical time.

[0025] In a fourth aspect, the present application provides a device for recharging a suspended account, which is applied to a gateway device and comprises a receiving module and a processing module. The receiving module is configured to receive a recharging request of a target user. The target user is a user in a suspended state. The recharging request is used to request recharging through a target recharging platform. The processing module is configured to allocate network resources required for recharging to the target user if address information of the target recharging platform is recorded in a white list. The white list is used to record address information of resources that are allowed to be accessed by the user in the suspended state.

[0026] In a possible implementation, the processing module is further configured to send the recharging request to a target server, so that the target server sends a recharging guide page to the target user in response to the recharging request.

[0027] In another possible implementation, the processing module is further configured to receive a payment request sent by the target user, the payment request being used to request payment through a target payment platform, and send the payment request to the target payment platform if address information of the target payment platform is recorded in the white list.

[0028] In yet another possible implementation, the resources that are allowed to be accessed by the user in the suspended state and recorded in the white list are obtained based on historical recharging behavior data analysis of a set of users. The set of users includes the target user. The recharging behavior data includes resource data accessed by the user when performing a recharging operation.

[0029] In yet another possible implementation, the set of users is divided based on at least one of the following indicators: age, gender, education level, occupation, economic status, interest, social circle, region, and consumption habit.

[0030] In yet another possible implementation, the resources that are allowed to be accessed by the user in the suspended state and recorded in the white list are determined based on historical recharging behavior data of the set of users and a behavior prediction model. The behavior prediction model is used to predict recharging behavior data of the user at a future time based on historical recharging behavior data of the user.

[0031] In yet another possible implementation, the behavior prediction model is trained by a preset training sample. The preset training sample includes sample data and a sample label. The sample data is recharging behavior data of the set of users at a first historical time. The sample label is recharging behavior data of the set of users at a second historical time. The first historical time is earlier than the second historical time.

[0032] In yet another possible implementation, the processing module is further configured to update the white list if the resources that are allowed to be accessed by the user in the suspended state are changed.

[0033] In another possible implementation, the processing module is specifically configured to: allocate the network resource required for the target user to top up according to network bandwidth usage and traffic distribution.

[0034] In a fifth aspect, the present application provides another offline top-up device, applied to a target server, comprising: a receiving module and a sending module. The receiving module is configured to receive a top-up request of a target user; the target user is a user in an offline state; the top-up request is used to request to top up through a target top-up platform; the top-up request of the target user is sent to the target server in a case where address information of the target top-up platform is recorded in a white list; the white list is used to record address information of resources allowed to be accessed by the user in the offline state; and the sending module is configured to send a top-up guide page to the target user in response to the top-up request of the target user.

[0035] In a possible implementation, the sending module is further configured to: query whether a payment record of the target user is included in a block chain; the payment record is a record of a payment operation of the target user based on the top-up guide page; and in a case where the payment record of the target user is included in the block chain and a payment state of the target user is successful, send a notification message to a network side configuration server, the notification message being used to notify the network side configuration server to restore network access permission of the target user; and the payment record of the target user is written into the block chain by a payment platform through a smart contract.

[0036] In a sixth aspect, the present application provides another offline top-up device, applied to a terminal device, comprising: a sending module, a receiving module and a processing module. The sending module is configured to send a top-up request to a gateway device in response to a top-up request initiated by a target user; the target user is a user in an offline state; the top-up request is used to request to top up through a target top-up platform; the receiving module is configured to receive a top-up guide page sent by a target server in a case where address information of the target top-up platform is recorded in a white list; the white list is used to record address information of resources allowed to be accessed by the user in the offline state; and the processing module is configured to top up based on the top-up guide page.

[0037] In a possible implementation, the sending module is further configured to: send a payment request to the gateway device in response to a payment request initiated by the target user; the payment request is used to request to pay through a target payment platform; and the receiving module is further configured to receive a payment response message in a case where address information of the target payment platform is recorded in the white list.

[0038] In another possible implementation, the processing module is further configured to: predict future recharge behavior data of the target user; the recharge behavior data comprises resources accessed by the user to perform a recharge operation; and preload, for the target user, resources accessed by the user to perform a recharge operation based on the future recharge behavior data of the target user.

[0039] In another possible implementation, the processing module is specifically configured to: obtain the future recharge behavior data of the target user based on the historical recharge behavior data of the target user and a behavior prediction model; and the behavior prediction model is configured to predict recharge behavior data of a user at a future time based on historical recharge behavior data of the user.

[0040] In another possible implementation, the processing module is specifically configured to: obtain the future recharge behavior data of the target user predicted by the data analysis device; and the future recharge behavior data of the target user is determined by the data analysis device based on the historical recharge behavior data of the target user and a behavior prediction model; and the behavior prediction model is configured to predict recharge behavior data of a user at a future time based on historical recharge behavior data of the user.

[0041] In another possible implementation, the behavior prediction model is trained by preset training samples, the preset training samples comprise sample data and sample labels, the sample data is recharge behavior data of a set of users at a first historical time, and the sample labels are recharge behavior data of the set of users at a second historical time; and the first historical time is earlier than the second historical time.

[0042] In a seventh aspect, the present application provides an electronic device, comprising: a processor and a memory; the memory stores instructions executable by the processor; and the processor is configured to execute the instructions, so that the electronic device implements the method of the first aspect, the second aspect or the third aspect.

[0043] In an eighth aspect, the present application provides a readable storage medium, comprising: software instructions; when the software instructions run in an electronic device, the electronic device implements the method of the first aspect, the second aspect or the third aspect.

[0044] In a ninth aspect, the present application provides a chip system applied to a shutdown recharge device; the chip system comprises one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected through a circuit; the interface circuit is configured to receive signals from a memory of the shutdown recharge device and send signals to the processor, and the signals comprise computer instructions stored in the memory. When the processor executes the computer instructions, the electronic device executes the method of the first aspect, the second aspect or the third aspect.

[0045] In a tenth aspect, the present application provides a computer program product, which, when executed on an electronic device, causes the electronic device to perform the steps of the method described in the first aspect, the second aspect or the third aspect, so as to implement the method of the first aspect, the second aspect or the third aspect.

[0046] The advantages of the fourth aspect to the tenth aspect are described in the corresponding description of the first aspect to the third aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0047] Figure 1 An environment schematic diagram of a parking lot recharge system architecture provided by the present application;

[0048] Figure 2 A flowchart of a parking lot recharge method provided by the present application;

[0049] Figure 3 A flowchart of another parking lot recharge method provided by the present application;

[0050] Figure 4 A flowchart of another parking lot recharge method provided by the present application;

[0051] Figure 5 A flowchart of another parking lot recharge method provided by the present application;

[0052] Figure 6 A flowchart of another parking lot recharge method provided by the present application;

[0053] Figure 7 A flowchart of another parking lot recharge method provided by the present application;

[0054] Figure 8 A schematic diagram of a recharge guide page provided by the present application;

[0055] Figure 9 A flowchart of another parking lot recharge method provided by the present application;

[0056] Figure 10 A flowchart of another parking lot recharge method provided by the present application;

[0057] Figure 11 A flowchart of another parking lot recharge method provided by the present application;

[0058] Figure 12 A composition schematic diagram of a parking lot recharge device provided by the present application;

[0059] Figure 13 A composition schematic diagram of another parking lot recharge device provided by the present application;

[0060] Figure 14 Another stoppage recharging device provided in the present application is shown in the component diagram.

[0061] Figure 15 An electronic device provided in the present application is shown in the component diagram. DETAILED DESCRIPTION

[0062] The technical solutions in the embodiments of the present application will be clearly and completely described in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work belong to the scope of protection of the present application.

[0063] It should be noted that, in the embodiments of the present application, the words such as "exemplarily" or "for example" are used to represent as an example, illustration or description. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of the present application should not be interpreted as more preferred or more advantageous than other embodiments or design schemes. Rather, the words such as "exemplarily" or "for example" are intended to present the relevant concept in a specific manner.

[0064] In addition, the terms "comprising" and "having" and any variations thereof mentioned in the description of the present application are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but can optionally further comprise other steps or units not listed, or can optionally further comprise other steps or units inherent to the process, method, product or device.

[0065] In order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish the same or similar items with basically the same function and role, and those skilled in the art can understand that the words "first", "second" and the like are not limited in quantity and execution order.

[0066] In the field of communication services, user overdue stoppage is a common problem, which not only affects the normal use experience of users, but also poses a challenge to the service quality and user satisfaction of operators. In order to improve user experience and reduce the inconvenience caused by overdue stoppage, more convenient and efficient recharging solutions are urgently needed.

[0067] Existing recharge methods typically involve the target terminal attempting to access network resources, through network devices (such as packet data gateways) performing status verification. Once the verification result shows that the user is in a state of arrears and service interruption, the gateway device redirects the access request to a specific recharge page or server, guiding the user to complete the recharge operation. This method mainly relies on the modification and upgrading of network devices to support status verification functions and specific resource redirection mechanisms. Although it solves the problem of users being unable to directly access network resources while in a state of service interruption to some extent, it has limitations such as high cost, limited recharge methods, and insufficient flexibility, making it neither convenient nor efficient.

[0068] This application provides a method, device, storage medium, and program product for recharging during system downtime. It does not require modification or upgrade of network equipment. Only a whitelist needs to be configured on the gateway device, which enables users to successfully access the network resources required for recharging through various means, and enables convenient and efficient recharging during system downtime.

[0069] This application provides a method for recharging during system downtime, which can be applied to, for example... Figure 1 The system architecture for recharging during system downtime is shown below. For example... Figure 1 As shown, the architecture of the shutdown recharge system includes: user terminal 100, gateway device 200, network-side configuration server 300, data analysis device 400, and target server 500.

[0070] In this configuration, user terminal 100 is connected to gateway device 200, network-side configuration server 300, data analysis device 400 and target server 500. Gateway device 200 is connected to network-side configuration server 300, data analysis device 400 and target server 500. Data analysis device 400 is connected to gateway device 200 and network-side configuration server 300.

[0071] In some embodiments, the user terminal 100 is configured to: respond to a recharge request initiated by a target user, send a recharge request to the gateway device 200, wherein the recharge request is for requesting recharge through a target recharge platform; if the address information of the target recharge platform is recorded in a whitelist, receive a recharge guidance page sent by the target server 500; and perform recharge based on the recharge guidance page. The whitelist is used to record the address information of resources that are allowed to be accessed by users in an offline state.

[0072] For example, the user terminal 100 may be a computer, mobile phone, tablet or self-service terminal device, etc. The specific form of the user terminal 100 is not limited in the embodiments of this application.

[0073] In some embodiments, the gateway device 200 is used to receive and process traffic requests from users whose devices are out of service.

[0074] In some embodiments, the gateway device 200 is specifically configured to: receive a top-up request initiated by a target user through a user terminal 100; forward the top-up request of the target user to a target server 500; and allocate network resources required for the top-up of the target user in a case where address information of a target top-up platform is recorded in a whitelist.

[0075] For example, the gateway device 200 is a packet data network gateway configured with an Access Point Name (APN) parameter of a post-shutdown default gateway. The APN is used to determine the network access mode of the user terminal.

[0076] For example, the APN of the post-shutdown default gateway is PSLCK, and the packet data network gateway is responsible for forwarding requests entering the network through the network access mode of PSLCK, so as to ensure that the top-up request of the target user can continue to access the Internet.

[0077] In some embodiments, the network-side configuration server 300 is configured to manage and configure network devices.

[0078] In some embodiments, the network-side configuration server 300 is specifically configured to configure the interaction rules between PSLCK and the packet data network gateway.

[0079] For example, the network-side configuration server 300 allocates IP addresses, data transmission security protocols, and quality of service policies, etc. between PSLCK and the packet data network gateway.

[0080] In some embodiments, the network-side configuration server 300 is specifically configured to configure and maintain a whitelist.

[0081] For example, the network-side configuration server pre-sets a whitelist when initially configuring, and the whitelist is used to record address information of resources allowed to be accessed by users in a shutdown state, such as address information of a top-up platform, address information of a top-up guide page, address information of a payment platform, etc. For example, when the user terminal accesses through PSLCK, PSLCK determines whether to release the request according to the pre-set whitelist.

[0082] For example, the network-side configuration server 300 can analyze historical top-up behavior data of a set of users (including the target user) to determine resources allowed to be accessed by users in a shutdown state, and then configure the whitelist. The top-up behavior data includes resource data accessed by the user when performing a top-up operation, such as a top-up platform, a payment platform, etc. For example, a top-up platform or a payment platform with high frequency of use can be determined based on historical top-up behavior data of a set of users, and address information of the top-up platform or the payment platform with high frequency of use is recorded in the whitelist.

[0083] In some embodiments, the setting user group is divided based on at least one of the following indicators: age, gender, education level, occupation, economic status, interest, social circle, region, and consumption habit.

[0084] For example, the network side configuration server 300 can receive the resources that the data analysis device 400 determines to allow the users in the stop state to access based on the historical charging behavior data of the setting user group and the behavior prediction model, and then configure the white list. The behavior prediction model is used to predict the charging behavior data of the user at a future time based on the historical charging behavior data of the user.

[0085] In some embodiments, the network side configuration server 300 is further configured to update the white list when the resources that the users in the stop state are allowed to access are changed.

[0086] For example, the network side configuration server 300 can periodically receive the resources that the data analysis device 400 determines to allow the users in the stop state to access based on the historical charging behavior data of the setting user group and the behavior prediction model, and update the white list when it is determined that the received resources that the users in the stop state are allowed to access are changed. For example, the white list can add or delete the resources that the users in the stop state are allowed to access according to the update. For example, a new payment platform can be added or an invalid payment platform can be deleted.

[0087] In some embodiments, the data analysis device 400 is configured to determine the resources that the users in the stop state are allowed to access based on the historical charging behavior data of the setting user group and the behavior prediction model. The behavior prediction model is used to predict the charging behavior data of the user at a future time based on the historical charging behavior data of the user.

[0088] As a possible implementation, the behavior prediction model is trained by a preset training sample. The preset training sample includes sample data and sample label. The sample data is the charging behavior data of the setting user group at a first historical time, and the sample label is the charging behavior data of the setting user group at a second historical time. The first historical time is earlier than the second historical time.

[0089] For example, the behavior prediction model can be a decision tree algorithm, a K-Nearest Neighbor (KNN) algorithm, or a reinforcement learning algorithm.

[0090] In some embodiments, the data analysis device 400 is configured to predict the charging behavior data of the user at a future time based on the historical charging behavior data of the target user and the behavior prediction model.

[0091] Exemplarily, the data analysis device 400 can predict the target user's future possible need for the top-up resource based on the target user's historical top-up behavior data and the behavior prediction model, and automatically update the white list. The top-up behavior data includes resource data accessed by the user when performing the top-up operation. The top-up behavior data can also include data such as top-up frequency, access time, etc.

[0092] In some embodiments, the target server 500 is configured to provide the top-up guide page.

[0093] In some embodiments, the target server 500 is configured to: receive, by the gateway device 200, a top-up request initiated by the target user; and send, in response to the top-up request of the target user, the top-up guide page to the user terminal 100 used by the target user.

[0094] Exemplarily, the target server 500 can be any communication operator server, for example, a server of an operator to which a mobile phone number used by the target user belongs.

[0095] It should be noted that the system architecture described in the embodiments of the present application is for more clearly illustrating the technical solutions of the embodiments of the present application, and does not constitute a limitation on the technical solutions provided by the embodiments of the present application. It can be known by those skilled in the art that, with the evolution of the system architecture, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems.

[0096] Figure 2 A flowchart of a method for offline top-up provided by an embodiment of the present application is shown in FIG. 4. As shown in FIG. 4, the method for offline top-up provided by the present application is applied to a gateway device. The method comprises the following steps: Figure 2

[0097] S101, receiving a top-up request of a target user.

[0098] The target user is a user in an offline state; and the top-up request is used to request top-up through a target top-up platform.

[0099] Exemplarily, the target top-up platform can be a top-up platform such as WeChat payment, Alipay payment, Vodafone payment, or China Unicom APP.

[0100] Exemplarily, a user A in an offline state clicks a mobile phone top-up icon on an Alipay platform to initiate a top-up request, and the gateway device receives the top-up request initiated by the user A.

[0101] S102, allocating network resources required for top-up for the target user in a case where address information of the target top-up platform is recorded in a white list.

[0102] The white list is used to record address information of resources allowed to be accessed by the user in the offline state.​

[0103] Exemplarily, the address information can be domain name address information and / or IP address information.

[0104] In some embodiments, the network resources required for the target user to recharge are allocated according to network bandwidth usage and traffic distribution.

[0105] Exemplarily, the allocation of the network resources required for the target user to recharge according to network bandwidth usage and traffic distribution can be specifically implemented as follows: the overall bandwidth usage of the network is monitored in real time, and when the network bandwidth is sufficient, more bandwidth resources can be given to the target user; when the network bandwidth is tight, the bandwidth usage of other non-downtime recharge businesses is appropriately limited to ensure the smooth progress of the recharge process of the downtime user. The traffic distribution of the target user is monitored in real time, and a higher traffic priority is allocated to the target user to ensure that the traffic demand of the target user is prioritized in the network.

[0106] In some embodiments, the resources that the user in the downtime state is allowed to access as recorded in the white list are obtained based on historical recharge behavior data analysis of a set user group. The set user group includes the target user.

[0107] The recharge behavior data includes resource data accessed by the user when performing the recharge operation, such as resource data of a recharge platform, a payment platform, etc.

[0108] Exemplarily, the recharge behavior data further includes data such as recharge frequency, access time, etc.

[0109] Exemplarily, the set user group is divided based on at least one of the following indicators: age, gender, education level, occupation, economic status, interest, social circle, region, consumption habit, etc. For example, the following user groups are set based on region: a first-tier city user group, a second-tier city user group, a third-tier and below city user group, and an overseas user group, etc.

[0110] As a possible implementation manner, the recharge platform or payment platform with high usage frequency can be determined based on historical recharge behavior data of the set user group, and the address information of the recharge platform or payment platform with high frequency is recorded in the white list.

[0111] For example, if the target user is a user over 40 years old, the resources that the user in the downtime state is allowed to access as recorded in the white list can be obtained based on historical recharge behavior data analysis of a user group over 40 years old. For example, the user group over 40 years old uses WeChat payment as a mobile phone recharge payment platform very frequently, and therefore the resources that the user in the downtime state is allowed to access as recorded in the white list include the address information of WeChat payment.

[0112] Optionally, before using and storing the historical recharge behavior data of the set user group, the gateway device also needs to obtain the authorization of the users in the set user group to use and store the historical recharge behavior data of the set user group. For example, for each user in the set user group, before the user initiates a recharge request, an authorization request interface for using and storing the historical recharge behavior data of the user can be displayed, and in response to the user's authorization operation (such as checking the authorization option box) on the authorization request interface, authorization information is sent to the gateway device, so that the gateway device obtains authorization to use and store the historical recharge behavior data of the set user group.

[0113] In some embodiments, the resources allowed to be accessed by the users in the shutdown state recorded in the white list are determined based on the historical recharge behavior data of the set user group and the behavior prediction model. The behavior prediction model is used to predict the recharge behavior data of the user at a future time based on the historical recharge behavior data of the user.

[0114] In some embodiments, the behavior prediction model is trained by a preset training sample, the preset training sample includes sample data and sample labels, the sample data is the recharge behavior data of the set user group at a first historical time, and the sample labels are the recharge behavior data of the set user group at a second historical time; wherein the first historical time is earlier than the second historical time.

[0115] In some embodiments, the above method further comprises: in the case of changing the resources allowed to be accessed by the users in the shutdown state, updating the white list. Based on this, the above step S102 can be implemented as: in the case that the address information of the target recharge platform is recorded in the updated white list, allocating the network resources required for the target user to recharge.

[0116] For example, updating the white list includes: adding the resources allowed to be accessed by the users in the shutdown state recorded in the white list and / or reducing the resources allowed to be accessed by the users in the shutdown state recorded in the white list.

[0117] For example, based on the analysis of the historical recharge behavior data of a certain user group, it is found that the user group is more inclined to use a specific recharge method and expects to obtain faster recharge services, and the user group can be set as a high-quality user group. The high-quality user group is provided with exclusive recharge services such as fast recharge channels and exclusive customer service support. The address information of these exclusive recharge services is added to the white list to ensure that the high-quality user group can successfully access and use these services in the shutdown state.

[0118] The present application provides diversified recharge methods through white list configuration, and realizes dynamic updating of the white list through the behavior prediction model, which makes the present application have good adaptability and flexibility under different operators, different network environments and different user demands.

[0119] In some embodiments, as shown in Figure 3 The step S102 further includes the following step S103:

[0120] S103, sending the top-up request to the target server, so that the target server sends a top-up guide page to the target user in response to the top-up request.

[0121] Illustratively, sending the top-up guide page to the target user includes sending the top-up guide page to the target top-up platform, so that the target top-up platform displays the top-up guide page through the terminal device of the target user.

[0122] It can be understood that the method provided by the embodiments of the present application can send the top-up request to the target server under the condition that the address information of the target top-up platform is recorded in the white list, so that the target server sends a top-up guide page to the target user in response to the top-up request. In this way, the network resources required for top-up (the network channel required for top-up or the top-up platform) can be provided for the offline users who cannot perform regular network access, so that the offline users can complete the top-up operation, and conveniently and efficiently top-up in the offline state.

[0123] In some embodiments, as shown in Figure 4 After the target user is allocated the network resources required for top-up, the method further includes:

[0124] S103, receiving the payment request sent by the target user.

[0125] The payment request is used to request payment through the target payment platform.

[0126] Illustratively, the target payment platform includes WeChat payment, Alipay payment, Meituan payment, bank card payment, etc.

[0127] S104, under the condition that the address information of the target payment platform is recorded in the white list, sending the payment request to the target payment platform.

[0128] It can be understood that the method provided by the embodiments of the present application can send the top-up request to the target server under the condition that the address information of the target top-up platform is recorded in the white list, so that the target server sends a top-up guide page to the target user in response to the top-up request. In this way, the network resources required for top-up (the network channel required for top-up or the top-up platform) can be provided for the offline users who cannot perform regular network access, so that the offline users can complete the top-up operation, and conveniently and efficiently top-up in the offline state.

[0129] Figure 5 Another flowchart of the offline top-up method provided by the embodiments of the present application. As shown in Figure 5As shown, the application provides a parking lot recharging method applied to a target server, and specifically includes the following steps:

[0130] S201, receiving a recharging request of a target user.

[0131] The target user is a user in a parking state, and the recharging request is used to request recharging through a target recharging platform.

[0132] In some embodiments, the recharging request of the target user is sent by a gateway device in a case where address information of the target recharging platform is recorded in a white list. The white list is used to record address information of resources allowed to be accessed by the user in the parking state.

[0133] S202, in response to the recharging request of the target user, sending a recharging guide page to the target user.

[0134] In some embodiments, if the target user completes a payment operation based on the target payment platform during the recharging process based on the recharging guide page, the target payment platform can write a payment record of the target user into a block chain through a smart contract, so as to ensure the non-tamperability and transparency of the payment information.

[0135] Optionally, before the target user completes the payment operation based on the recharging guide page, the target server encrypts the communication of the recharging guide page through a Transport Layer Security / Secure Sockets Layer (TLS / SSL) protocol, so as to ensure the security of the recharging data transmission process. Meanwhile, before the target user completes the payment operation, a short message verification code needs to be input or biological recognition (such as fingerprint recognition or face recognition) needs to be performed, so as to increase the security of the payment process.

[0136] In some embodiments, as shown, after the recharging guide page is sent to the target user, the above method further includes the following steps S203-S204: Figure 6

[0137] S203, querying whether a payment record of the target user is included in the block chain.

[0138] The payment record is a record of the payment operation of the target user based on the recharging guide page.

[0139] Exemplarily, the payment record includes a payment amount, a payment time, a payment account, a payment state, etc.

[0140] S204, in a case where the payment record of the target user is included in the block chain and a payment state of the target user is payment success, sending a notification message to a network side configuration server. ​

[0141] The notification message is used to notify the network-side configuration server to restore the target user's network access permissions.

[0142] In some embodiments, the blockchain includes the target user's payment records, but if the target user's payment status is "payment failed," the target server sends a payment failure message to the target user, who can then choose to re-pay or terminate the payment process.

[0143] In the suspension recharge method provided in this application, payment records are automatically recorded on the blockchain via smart contracts, ensuring the authenticity and immutability of payments. Simultaneously, the target server verifies the success of the target user's payment by querying the blockchain, avoiding reliance on third parties in traditional verification processes. Furthermore, after successful payment verification, the target server promptly restores the target user's network access permissions, improving the user experience and enhancing user satisfaction with the operator's services.

[0144] Figure 7 This is a flowchart illustrating another method for recharging during system downtime, provided in an embodiment of this application. Figure 7 As shown, the method for recharging during downtime provided in this application is applied to terminal devices and specifically includes the following steps:

[0145] S301. In response to a recharge request initiated by the target user, a recharge request is sent to the gateway device.

[0146] The target user is a user whose account is in a suspended state; the recharge request is used to request a recharge through the target recharge platform.

[0147] For example, a target user opens the target recharge platform on a terminal device, clicks the recharge icon on the target recharge platform to initiate a recharge request, and the terminal device responds to the recharge request initiated by the target user by sending a recharge request to the gateway device.

[0148] S302. If the address information of the target recharge platform is recorded in the whitelist, receive the recharge guidance page sent by the target server.

[0149] The whitelist is used to record the address information of resources that are allowed to be accessed by users who are in an offline state.

[0150] For example, the recharge guide page includes one or more of the following information items: mobile phone number, outstanding payment information, recharge amount options, payment method selection, recharge promotions, etc.

[0151] For example, such as Figure 8 As shown, the recharge guide page includes at least the following two subpages:

[0152] like Figure 8As shown in (1), the first subpage displays the current mobile phone number, outstanding amount, recharge amount options, recharge promotions, etc.; Figure 8 As shown in (2), the second subpage displays the recharge amount, actual payment amount, payment method options, etc.

[0153] S303. Recharge based on the recharge guidance page.

[0154] For example, the target user browses the recharge guide page on the terminal device and selects the desired recharge amount and payment method.

[0155] In some embodiments, such as Figure 9 As shown, after making a recharge based on the recharge guidance page, the method further includes the following steps S304 to S305:

[0156] S304. In response to a payment request initiated by the target user, send a payment request to the gateway device.

[0157] The payment request is used to request payment through the target payment platform.

[0158] S305. If the address information of the target payment platform is recorded in the whitelist, receive the payment response message.

[0159] For example, a payment response message may include: payment successful or payment failed.

[0160] In some embodiments, such as Figure 10 As shown, prior to step S301, the method may further include the following steps S401-402:

[0161] S401, Predict future recharge behavior data of target users.

[0162] The recharge behavior data includes the resources that a user needs to access to perform a recharge operation.

[0163] In some embodiments, future recharge behavior data of the target user is obtained based on the target user's historical recharge behavior data and a behavior prediction model; wherein, the behavior prediction model is used to predict the user's recharge behavior data at future moments based on the user's historical recharge behavior data.

[0164] In some embodiments, predicting future recharge behavior data of target users includes:

[0165] The system acquires data on the future recharge behavior of target users predicted by data analysis equipment. This data is determined by the data analysis equipment based on the target users' historical recharge behavior data and a behavior prediction model. The behavior prediction model is used to predict the user's recharge behavior data at future moments based on the user's historical recharge behavior data.

[0166] In some embodiments, the behavior prediction model is trained by preset training samples, the preset training samples including sample data and sample labels, the sample data being the recharge behavior data of a set user group at a first historical time, and the sample labels being the recharge behavior data of the set user group at a second historical time; wherein the first historical time is earlier than the second historical time.

[0167] S402, based on the future recharge behavior data of the target user, preloading the resources required for the target user to perform the recharge operation.

[0168] For example, if the future recharge behavior data of the target user is to recharge based on a target recharge platform and pay through a target payment platform, the above step S402 can be implemented as: preloading the target recharge platform and the target payment platform for the target user. For example, the target recharge platform and the target payment platform are preloaded into the memory.

[0169] It can be understood that, based on the future recharge behavior data of the target user, preloading the resources required for the target user to perform the recharge operation can predictively load the resources that the user likes or commonly uses, effectively reducing the waiting time of the target user, and improving the user experience and satisfaction.

[0170] The method for offline recharge will be introduced below according to a specific embodiment, such as Figure 11 The method is applied to the interaction process of the terminal device, the gateway device and the target server, including the following steps S501-S513.

[0171] S501, the terminal device detects that the target user initiates a recharge request.

[0172] S502, the terminal device sends a recharge request to the gateway device in response to the recharge request initiated by the target user.

[0173] S503, the gateway device receives the recharge request of the target user; in the case that the address information of the target recharge platform is recorded in the whitelist, the network resources required for the target user to perform the recharge are allocated.

[0174] S504, the gateway device sends the recharge request to the target server.

[0175] S505, the target server receives the recharge request of the target user.

[0176] S506, the target server sends a recharge guide page to the terminal device in response to the recharge request of the target user.

[0177] S507, the terminal device displays a recharge guide page, and initiates a payment request in response to detection of a recharge operation of the target user on the recharge guide page.

[0178] S508, the terminal device sends a payment request to the gateway device in response to the payment request initiated by the target user.

[0179] S509, the gateway device receives the payment request sent by the target user.

[0180] S510, the gateway device sends the payment request to the target payment platform in a case where address information of the target payment platform is recorded in a white list.

[0181] S511, the target payment platform receives the payment request of the target user.

[0182] S512, the target payment platform sends a payment response message to the terminal device in response to the payment request of the target user.

[0183] S513, the terminal device receives the payment response message.

[0184] The specific implementation of steps S501-S513 is described above with reference to S101-S104, S201-S204, S301-S305, and S401-S402, and will not be described here.

[0185] The above mainly describes the scheme of the embodiments of the present disclosure from the perspective of the method. It can be understood that the parking lot recharge device contains at least one of the corresponding hardware structure and software module for executing each function in order to implement the above functions. Those skilled in the art should easily realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is implemented in hardware or computer software driven hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of the present disclosure.

[0186] The embodiments of the present disclosure can divide the parking lot recharge device into functional modules according to the above method embodiments. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one functional module. The integrated module can be implemented in the form of hardware or software. It should be noted that the division of modules in the embodiments of the present disclosure is illustrative, and is only a logical functional division. Actual implementation can have another division manner. The following will be described taking the example of dividing each functional module according to each function.

[0187] For example, Figure 12 This is a schematic diagram illustrating the composition of a shutdown recharge device provided in an embodiment of this application. The shutdown recharge device 800 is applied to a gateway device and includes: a receiving module 501 and a processing module 502; wherein, the receiving module 501 is used to receive a recharge request from a target user; wherein the target user is a user in a shutdown state; the recharge request is used to request recharge through a target recharge platform; the processing module 502 is used to allocate the network resources required for recharge to the target user if the address information of the target recharge platform is recorded in a whitelist; the whitelist is used to record the address information of resources that are allowed to be accessed by users in a shutdown state.

[0188] In one possible implementation, the processing module 502 is further configured to: send a recharge request to the target server, so that the target server responds to the recharge request by sending a recharge guidance page to the target user.

[0189] In another possible implementation, the processing module 502 is also used to: receive a payment request sent by the target user, the payment request being used to request payment through the target payment platform; and, if the address information of the target payment platform is recorded in the whitelist, send the payment request to the target payment platform.

[0190] Another possible implementation is that the resources that users in a suspended state are allowed to access in the whitelist are obtained based on the analysis of historical recharge behavior data of a set user group; the set user group includes target users; the recharge behavior data includes the resource data accessed by users when performing recharge operations.

[0191] Another possible approach is to define the user group based on at least one of the following metrics: age, gender, education level, occupation, economic status, hobbies, social circle, region, and consumption habits.

[0192] Another possible implementation is that the resources that users in an offline state are allowed to access in the whitelist are determined based on the historical recharge behavior data of a set user group and a behavior prediction model; wherein, the behavior prediction model is used to predict the user's recharge behavior data at future moments based on the user's historical recharge behavior data.

[0193] Another possible implementation is that the behavior prediction model is trained by a preset training sample, which includes sample data and sample labels. The sample data is the recharge behavior data of a set user group at the first historical moment, and the sample labels are the recharge behavior data of the set user group at the second historical moment; wherein, the first historical moment is earlier than the second historical moment.

[0194] In another possible implementation, the processing module 502 is also used to update the whitelist in the event of changes to resources that allow access by users in a downtime state.

[0195] In another possible implementation, the processing module 502 is specifically configured to allocate the network resource required for the target user to top up according to the network bandwidth usage and the traffic distribution.

[0196] Figure 13 Another composition diagram of the offline top-up device is provided for the embodiments of the present application. The offline top-up device 600 is applied to a target server and includes a receiving module 601 and a sending module 602. The receiving module 601 is configured to receive a top-up request of a target user. The target user is a user in an offline state. The top-up request is used to request to top up through a target top-up platform. The top-up request of the target user is sent to the target server in a case where address information of the target top-up platform is recorded in a white list. The white list is used to record address information of resources that are allowed to be accessed by the user in the offline state. The sending module 602 is configured to send a top-up guide page to the target user in response to the top-up request of the target user.

[0197] In a possible implementation, the sending module 602 is further configured to query whether a payment record of the target user is included in a block chain. The payment record is a record of a payment operation of the target user based on the top-up guide page. In a case where the payment record of the target user is included in the block chain and a payment state of the target user is payment success, a notification message is sent to a network side configuration server. The notification message is used to notify the network side configuration server to restore network access permission of the target user. The payment record of the target user is written into the block chain by a payment platform through a smart contract.

[0198] Figure 14 Another composition diagram of the offline top-up device is provided for the embodiments of the present application. The offline top-up device 700 is applied to a terminal device. The device includes a sending module 701, a receiving module 702, and a processing module 703. The sending module 701 is configured to send a top-up request to a gateway device in response to a top-up request initiated by a target user. The target user is a user in an offline state. The top-up request is used to request to top up through a target top-up platform. The receiving module 702 is configured to receive a top-up guide page sent by a target server in a case where address information of the target top-up platform is recorded in a white list. The white list is used to record address information of resources that are allowed to be accessed by the user in the offline state. The processing module 703 is configured to top up based on the top-up guide page.

[0199] In a possible implementation, the sending module 701 is further configured to: in response to a payment request initiated by the target user, send the payment request to a gateway device; and the payment request is used to request payment through a target payment platform; and the receiving module 702 is further configured to: in a case where address information of the target payment platform is recorded in a whitelist, receive a payment response message.

[0200] In another possible implementation, the processing module 703 is further configured to: predict future recharge behavior data of the target user; the recharge behavior data includes resources accessed by the user to perform a recharge operation; and preload, for the target user, resources accessed to perform the recharge operation based on the future recharge behavior data of the target user.

[0201] In another possible implementation, the processing module 703 is specifically configured to: obtain the future recharge behavior data of the target user based on historical recharge behavior data of the target user and a behavior prediction model; and the behavior prediction model is used to predict recharge behavior data of a user at a future time based on historical recharge behavior data of the user.

[0202] In another possible implementation, the processing module 703 is specifically configured to: obtain future recharge behavior data of the target user predicted by a data analysis device; the future recharge behavior data of the target user is determined by the data analysis device based on historical recharge behavior data of the target user and a behavior prediction model; and the behavior prediction model is used to predict recharge behavior data of a user at a future time based on historical recharge behavior data of the user.

[0203] In another possible implementation, the behavior prediction model is obtained by training preset training samples; the preset training samples include sample data and sample labels; the sample data is recharge behavior data of a set of users at a first historical time; and the sample labels are recharge behavior data of the set of users at a second historical time; and the first historical time is earlier than the second historical time.

[0204] In the example embodiment, the application also provides an electronic device, which can be the shutdown recharge device in the method embodiment. Figure 15 A composition schematic diagram of an electronic device provided by the application is shown in FIG. 8. Figure 15 As shown in the figure, the electronic device can include a processor 801 and a memory 802; the memory 802 stores instructions executable by the processor 801; and the processor 801 is configured to execute the instructions, so that the electronic device or the network device or the manager implements the method described in the foregoing method embodiment.

[0205] In the exemplary embodiments, the embodiments of the present application also provide a readable storage medium having program instructions stored thereon; when the program instructions are executed by a computer, the computer implements the method described in the foregoing embodiments. The readable storage medium can be a non-transitory readable storage medium, for example, the non-transitory readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0206] In the exemplary embodiments, the embodiments of the present application also provide a computer program product, when the computer program product runs on a computer, the computer executes the above-mentioned related method steps to realize the parking charge method in the above-mentioned embodiments.

[0207] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, any change or replacement within the technical scope disclosed in the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method of recharging a parking meter, characterized by, The method applied to a gateway device comprises: receiving a top-up request of a target user; wherein the target user is a user in a shutdown state; the top-up request is used to request top-up through a target top-up platform; allocating network resources required for top-up for the target user in a case that address information of the target top-up platform is recorded in a white list; the white list is used to record address information of resources allowed to be accessed by the user in the shutdown state; the resources allowed to be accessed by the user in the shutdown state recorded in the white list are determined based on historical top-up behavior data and a behavior prediction model of a set user group; wherein the set user group comprises the target user; the behavior prediction model is used to predict top-up behavior data of a user at a future time based on historical top-up behavior data of the user; the top-up behavior data comprises top-up platform resource data and payment platform resource data accessed by the user when performing a top-up operation; the behavior prediction model is obtained by training preset training samples; the preset training samples comprise sample data and sample labels; the sample data is top-up behavior data of the set user group at a first historical time; the sample labels are top-up behavior data of the set user group at a second historical time; wherein the first historical time is earlier than the second historical time; receiving a payment request sent by the target user; the payment request is used to request payment through a target payment platform; sending the payment request to the target payment platform in a case that address information of the target payment platform is recorded in the white list.

2. The method of claim 1, wherein, After the network resources required for top-up are allocated for the target user, the method further comprises: sending the top-up request to a target server, so that the target server sends a top-up guide page to the target user in response to the top-up request.

3. The method of claim 1, wherein, The set user group is divided based on at least one of the following indicators: age, gender, education level, occupation, economic status, interest, social circle, region, and consumption habit.

4. The method of claim 1, wherein, The method further comprises: updating the white list in a case that resources allowed to be accessed by the user in the shutdown state are changed.

5. The method of claim 1, wherein, The network resources required for top-up allocated for the target user comprise: allocating network resources required for top-up for the target user according to network bandwidth usage and traffic distribution.

6. A method of recharging a parking meter, characterized by, The method applied to a target server comprises: receiving a top-up request of a target user; wherein the target user is a user in a shutdown state; the top-up request is used to request top-up through a target top-up platform; the top-up request of the target user is sent by a gateway device in a case that address information of the target top-up platform is recorded in a white list; wherein the white list is used to record address information of resources allowed to be accessed by the user in the shutdown state; The resource allowed to be accessed by the user in the shutdown state recorded in the white list is determined based on historical recharge behavior data of a set user group and a behavior prediction model; the set user group includes the target user; the behavior prediction model is used to predict the recharge behavior data of the user at a future time based on the historical recharge behavior data of the user; the recharge behavior data includes recharge platform resource data and payment platform resource data accessed by the user when performing a recharge operation; The behavior prediction model is trained by a preset training sample, the preset training sample includes sample data and a sample label, the sample data is the recharge behavior data of the set user group at a first historical time, and the sample label is the recharge behavior data of the set user group at a second historical time; the first historical time is earlier than the second historical time; In response to the recharge request of the target user, a recharge guide page is sent to the target user.

7. The method of claim 6, wherein, After the recharge guide page is sent to the target user, the method further includes: Querying whether the payment record of the target user is included in the blockchain; the payment record is a record of a payment operation of the target user based on the recharge guide page; In the case that the payment record of the target user is included in the blockchain and the payment state of the target user is payment success, a notification message is sent to a network side configuration server, the notification message is used to notify the network side configuration server to restore the network access permission of the target user; the payment record of the target user is written into the blockchain by a payment platform through a smart contract.

8. A method of recharging a parking meter, characterized by, Applied to a terminal device, the method includes: In response to a recharge request initiated by a target user, a recharge request is sent to a gateway device; the target user is a user in a shutdown state; the recharge request is used to request to perform recharge through a target recharge platform; In the case that the address information of the target recharge platform is recorded in a white list, a recharge guide page sent by a target server is received; the white list is used to record the address information of a resource allowed to be accessed by the user in the shutdown state; The resource allowed to be accessed by the user in the shutdown state recorded in the white list is determined based on historical recharge behavior data of a set user group and a behavior prediction model; the set user group includes the target user; the behavior prediction model is used to predict the recharge behavior data of the user at a future time based on the historical recharge behavior data of the user; the recharge behavior data includes recharge platform resource data and payment platform resource data accessed by the user when performing a recharge operation; The behavior prediction model is trained by a preset training sample, the preset training sample includes sample data and a sample label, the sample data is the recharge behavior data of the set user group at a first historical time, and the sample label is the recharge behavior data of the set user group at a second historical time; the first historical time is earlier than the second historical time; Performing recharge based on the recharge guide page; In response to the payment request initiated by the target user, the payment request is sent to the gateway device; wherein the payment request is used to request payment through a target payment platform; In the case where the address information of the target payment platform is recorded in the whitelist, a payment response message is received.

9. The method of claim 8, wherein, Before the method sends the recharge request to the gateway device in response to the recharge request initiated by the target user, the method further comprises: Predicting future recharge behavior data of the target user; the recharge behavior data includes resources accessed by the user when performing a recharge operation; Based on the future recharge behavior data of the target user, preloading resources accessed by the target user when performing a recharge operation.

10. The method of claim 9, wherein, The method of predicting future recharge behavior data of the target user comprises: Based on the historical recharge behavior data of the target user and a behavior prediction model, the future recharge behavior data of the target user is obtained; wherein the behavior prediction model is used to predict the recharge behavior data of the user at a future time based on the historical recharge behavior data of the user.

11. The method of claim 9, wherein, The method of predicting future recharge behavior data of the target user comprises: Obtaining future recharge behavior data of the target user predicted by a data analysis device; the future recharge behavior data of the target user is determined by the data analysis device based on the historical recharge behavior data of the target user and a behavior prediction model; the behavior prediction model is used to predict the recharge behavior data of the user at a future time based on the historical recharge behavior data of the user.

12. The method according to claim 10 or 11, characterized in that, The behavior prediction model is trained by a preset training sample, the preset training sample includes sample data and sample labels, the sample data is the recharge behavior data of the set user group at a first historical time, and the sample labels are the recharge behavior data of the set user group at a second historical time; wherein the first historical time is earlier than the second historical time.

13. An electronic device, comprising: The electronic device comprises a processor and a memory; The memory stores instructions executable by the processor; The processor is configured to execute the instructions, so that the electronic device implements the method of any one of claims 1-5 or any one of claims 6-7 or any one of claims 8-12.

14. A readable storage medium, characterized by, The readable storage medium comprises software instructions; When the software instructions run in the electronic device, the electronic device implements the method of any one of claims 1-5 or any one of claims 6-7 or any one of claims 8-12.

15. A computer program product, characterised in that, The computer program product comprises computer instructions; When the computer instructions run in the electronic device, the electronic device implements the method of any one of claims 1-5 or any one of claims 6-7 or any one of claims 8-12.

Images