HK1259086A1 - Data processing method and device - Google Patents

Description

A data processing method and apparatus

Technical Field

This application relates to the field of computer technology, and in particular to a data processing method and apparatus.

Background Technology

Carbon emissions are a general term or abbreviation for greenhouse gas emissions. Any human activity can potentially cause carbon emissions, such as carbon emissions from vehicle exhaust and coal-fired power plants.

Today, most scientists and governments acknowledge that greenhouse gases have brought and will continue to bring disaster to the Earth and humanity. To prevent this situation from worsening, the international community adopted the United Nations Framework Convention on Climate Change (UNFCCC) in 1992, and the Kyoto Protocol (Kyoto Protocol) was adopted at the Third Conference of the Parties to the Convention held in Kyoto, Japan, in December 1997. The Protocol required more than 30 Annex I countries (including developed countries and countries in transition) to reduce their greenhouse gas emissions by an average of >5.2% compared to 1990 levels between 2008 and 2012. After being ratified by the contracting developed countries, which accounted for more than 55% of the total CO2 emissions in 1990, the Protocol officially entered into force on February 16, 2005. This marked the beginning of a substantial phase of greenhouse gas emission reduction in the international community, and for the first time in human history, an international legal framework was established to limit human activities' interference with the Earth's carbon cycle and climate change. Reducing carbon emissions has become one of the important goals of socio-economic development and production activities in contracting countries.

In other words, carbon emissions have become a significant social issue, and encouraging businesses and individuals to proactively control carbon emissions is a direction that all of humanity needs to strive towards. A crucial aspect of this is ensuring that businesses and individuals clearly understand the carbon emissions from their daily activities and how much carbon emissions they could save by adopting more environmentally friendly behaviors (hereinafter referred to as carbon savings).

In existing technologies, for enterprises, the relatively centralized nature of their activities makes it easy to calculate and control carbon emissions and carbon savings across individual businesses. However, for individuals, the loose and arbitrary nature of their actions leads to numerous sources of carbon emissions, resulting in a vast amount of complex information. Furthermore, ordinary people rarely pay attention to the carbon emissions generated by their own actions. Therefore, how to utilize fragmented personal behavioral information to calculate the carbon savings of each individual's daily activities has become an urgent problem to be solved.

Summary of the Invention

This application provides a data processing method to address the problem of how to utilize fragmented personal behavioral information to enable each individual to know the amount of carbon savings from their daily activities.

This application provides a data processing device to address the problem of how to utilize fragmented personal behavioral information to enable each individual to know the amount of carbon savings from their daily activities.

This application provides a data processing method, including:

Obtain user payment data, which is user behavior data when using online payment services;

The carbon saving quantification algorithms used to calculate carbon saving based on payment data are determined to be: carbon saving quantification algorithms for reducing travel by public transportation and carbon saving quantification algorithms for saving paper products.

The user's carbon savings are calculated based on the payment data and the predetermined carbon-saving quantification algorithm.

Based on the calculated carbon savings of the user, the carbon savings of the user are processed into specific data to reflect the carbon savings of the user. The processing includes at least: converting the calculated carbon savings into an integral form.

This application provides a data processing apparatus, comprising:

The acquisition module acquires the user's payment data, which is the user's behavior data when using online payment services;

The module determines the carbon saving quantification algorithm used to calculate carbon saving based on payment data: a carbon saving quantification algorithm for reducing transportation use and a carbon saving quantification algorithm for saving paper products.

The calculation module calculates the user's carbon savings based on the payment data and the determined preset carbon saving quantification algorithm.

The processing module processes the calculated carbon savings of the user into specific data that reflects the user's carbon savings. The processing includes at least converting the calculated carbon savings into an integral form.

The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

The technical solution in this application can aggregate fragmented user behavior data and, based on the aggregated behavior data and the corresponding carbon-saving quantification algorithm, calculate the user's reduced carbon emissions, i.e., the user's carbon savings. The corresponding service provider can then further process the user's data based on the calculated carbon savings. This approach allows users to more intuitively understand their carbon savings without having to query or calculate it themselves, making it more convenient. Furthermore, by having the service provider perform data processing such as points accumulation and account level upgrades based on the user's carbon savings, the corresponding services can be linked to the user's carbon savings.

Attached Figure Description

The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

Figure 1 is a schematic diagram of the data processing process provided in an embodiment of this application;

Figures 2a-2e are schematic diagrams of the data processing process for different user behavior data in different scenarios provided in the embodiments of this application;

Figure 3 is a schematic diagram of the architecture for implementing the data processing process provided in an embodiment of this application;

Figure 4a is a schematic diagram of a control for accumulating points for a user, provided in an embodiment of this application;

Figure 4b is a schematic diagram showing the total points according to an embodiment of this application;

Figure 4c is another schematic diagram showing the total points provided in an embodiment of this application;

Figures 5a and 5b are schematic diagrams illustrating the point accumulation process between users according to embodiments of this application.

Figure 6 is a schematic diagram of the data processing device provided in an embodiment of this application;

Detailed Implementation

To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

This application aims to calculate a user's carbon emissions and carbon savings by collecting and summarizing fragmented behavioral data over a period of time.

Based on this, this application provides a data processing procedure, as shown in Figure 1, which specifically includes the following steps:

S101: Obtain user behavior data, which is generated when the user uses the Internet service. The behavior data includes a user identifier indicating the user's identity and an identifier information indicating the Internet service corresponding to the behavior data.

In this embodiment of the application, the user's behavior data obtained is typically fragmented into multiple behavior data.

For behavioral data, each piece of behavioral data includes a user identifier (such as user ID, user account, etc.) and identification information indicating the corresponding internet service. The internet service mentioned here may include at least one of electronic payment, online booking, online ticketing, online bill payment, and health services. The health service may be a service in a mobile system or app used to monitor the user's exercise behavior, and the health service may include at least one of step counting or distance calculation services.

Based on the identification information contained in the behavioral data, behavioral data from different Internet services can be distinguished.

In the process of aggregating fragmented user behavior data, it is necessary to ensure that all aggregated behavior data belongs to the same user. For online behavior data, in practice, users may use internet services through different applications (or servers), such as online payment through a payment application or online food ordering through a food ordering application. Users may use different accounts when using these internet services. Therefore, to ensure that the acquired behavior data is consistent with the user's behavior data, one approach is to obtain the user's different accounts (i.e., user identifiers). In practice, the user can input their different account names, which can then be saved. Subsequently, the behavior data associated with that account can be retrieved from the corresponding application (or server) using that account name. Of course, the above method is not limited to obtaining user accounts; it also applies to other user identifiers, which will not be elaborated upon here.

Meanwhile, different internet services have different identification information, which may include: service type identifier, type identifier in order number, etc. Therefore, by using the identification information in behavioral data, the type of internet service corresponding to the behavioral data can be further determined.

In practice, after obtaining user behavior data, the fields representing the type of behavior data can be clearly defined according to an agreement. Therefore, based on the content of these fields, the type of internet service corresponding to the behavior data can be determined. Of course, some applications (or servers) provide relatively fixed types of internet services, such as ticketing website servers that only provide ticketing services. In such cases, if behavior data is obtained from these applications (or servers), the type of internet service corresponding to the behavior data can be directly identified based on the application's (or server's) name, domain name, URL, and other information. This does not constitute a limitation of this application.

It should be noted that the executing entity of this method can be either an application or a server. When the executing entity is an application, one possible approach is for the application to provide various internet services to users. In this case, the application itself can generate user behavior data, and consequently, carbon emissions can be directly calculated based on the generated behavior data. In other words, under this method, users only need to register an account in the application acting as the executing entity to use various internet services within that application. The resulting behavior data is all associated with that account, so the application only needs to obtain the behavior data related to that account.

As another possible approach, if the application cannot provide internet service, it can initiate a request to a third-party application (or server) that can provide internet service to obtain behavioral data, and receive the user's behavioral data fed back by the third-party application. Alternatively, it can synchronize data with the third-party application to receive user behavioral data generated by the third-party application. In this approach, based on the foregoing, the user, acting as the executing entity, can input their various third-party accounts and the corresponding third-party applications (or servers). The executing application will then associate each third-party account with the account registered by the user within the executing application. Taking a third-party application as an example, during the process of obtaining behavioral data, since the user inputs the third-party application (or server) corresponding to each third-party account, the executing application can determine the third-party application corresponding to that account and send a request carrying the third-party account information to that third-party application. The third-party application will then search for and feed back the behavioral data related to that third-party account, thus completing the process of obtaining behavioral data. Of course, this process does not constitute a limitation of this application.

Of course, in practice, if a third-party application is involved, the application acting as the executor can pre-register the corresponding permissions with the third-party application to receive user behavior data from the third-party application. If a third-party server is involved, the application acting as the executor can obtain user behavior data from the third-party server through the data transmission protocol agreed upon with the third-party application.

Furthermore, in practical application scenarios, for behavioral data generated by third-party servers or third-party applications in commonly used data formats, such as two-dimensional table format, HyperText Markup Language (HTML) format, Extensible Markup Language (XML) format, etc., the application or server as the execution subject can read and parse the behavioral data based on the corresponding format after obtaining the behavioral data.

For certain specific data formats, the application acting as the executor can agree on the data transmission format with third-party applications, such as JSON. Alternatively, different data parsing methods can be pre-added to the application's own Application Programming Interface (API) to parse behavioral data of various formats. This does not constitute a limitation of this application.

The acquired behavioral data can be stored either locally on the terminal or on the server.

S102: Based on the identification information of the Internet service, determine at least one preset carbon saving quantification algorithm.

In this embodiment, an existing correspondence is established between internet services and carbon-saving quantification algorithms. Therefore, at least one preset carbon-saving quantification algorithm can be determined based on the identification information of the internet services and the correspondence between the internet services and the carbon-saving quantification algorithms. The carbon-saving quantification algorithms include, but are not limited to, quantification formulas and quantification models.

In other words, different internet services (i.e., behavioral data containing different identifiers) may correspond to different carbon-saving quantification algorithms. For example, electronic payment services can save paper products, while walking saves carbon emissions from transportation. Furthermore, the relationship between internet services and carbon-saving quantification algorithms may be one-to-many, meaning that multiple carbon-saving quantification algorithms may be used within a single internet service. For instance, in the scenario of users using online ticketing services, online ticketing eliminates the need for users to travel to ticketing locations, thus reducing carbon emissions caused by users traveling to ticketing locations. Therefore, when calculating the carbon savings from using online ticketing services, a carbon-saving quantification algorithm that reduces transportation travel can be used. Additionally, online ticketing avoids printing paper tickets (i.e., paper products) during payment, further reducing carbon emissions. Therefore, when calculating the carbon savings from using online ticketing services, a carbon-saving quantification algorithm that saves paper products can also be used.

It should be noted that in the embodiments of this application, the preset carbon saving quantification algorithms are also divided into different types, including but not limited to: a first preset algorithm, which is a carbon saving quantification algorithm for saving paper products (e.g., a carbon saving quantification algorithm for saving printed paper tickets), and a second preset algorithm, which is a carbon saving quantification algorithm for reducing the use of transportation (e.g., a carbon saving quantification algorithm for walking).

The first preset algorithm is a quantification algorithm for carbon savings in paper-saving products.

In traditional offline methods, users may generate paper products (such as paper payment vouchers, receipts, appointment slips, etc.) when performing the above types of business. Taking paper receipts as an example, the generation of paper receipts further causes carbon emissions. Therefore, in this method, the carbon emission corresponding to the paper of the receipt can be calculated to calculate the corresponding carbon saving.

Specifically, the following formula can be used:

Wherein, ER _y represents the carbon savings (in tons of CO2) of paper receipts saved by each online payment. It should be noted that ER _y actually represents the carbon emissions corresponding to the paper receipts printed for each offline payment. Since users can avoid printing paper receipts by using online payment, the value of ER _y is used here as the carbon savings of paper receipts saved by each online payment.

i represents the merchant type for offline payments;

F _{_i} represents the percentage (in percentages) of merchants of type i using POS machine payments.

AD _{i, y} represents the number of times a user makes offline payments at merchant type i in year y (unit: number of times);

EF _y is the baseline emission factor for offline payments in year y (unit: g CO2/time).

It should be noted that EF _y can be determined based on the emission intensity of paper manufacturers in different regions. For example, Table 1 shows the emission intensity of paper manufacturers in several provinces:

Yunnan Zhejiang Shaanxi Other provinces Emission intensity (tons of CO2/ton of paper) 1.9296 2.0072 1.8834 1.4622

Table 1

The above formula can be used to determine the carbon savings achieved by reducing invoice generation through online transactions. Since the carbon savings from each individual online payment transaction are relatively small, the formula calculates the carbon savings on an annual basis. However, in practice, a threshold for the number of transactions can be set, and carbon savings can be calculated only after the number of transactions reaches that threshold. This does not constitute a limitation of this application.

The second preset algorithm is a quantification algorithm for reducing carbon savings by reducing the use of public transportation.

In traditional offline methods, users may travel to the corresponding business locations (such as banks, shops, restaurants, etc.) to perform the aforementioned types of business. During this process, the transportation used by users may generate carbon emissions. Therefore, in this method, carbon emissions caused by the transportation used by users can be reduced through online methods, thereby calculating the corresponding carbon savings.

Specifically, the following formula can be used:

P = L * W;

Where L is the distance between the user’s location when performing a business online and the nearest business location;

W represents the average carbon emissions generated by a mode of transportation; (modes of transportation here can include all types of transportation that use older energy sources).

P represents the carbon emissions generated by using transportation over this distance.

For the above formula, if users perform the corresponding business online, then users do not need to go to the corresponding business location. Therefore, the value of P can be used as the carbon saving amount when users perform the corresponding business online.

S103: Calculate the user's carbon savings based on the behavioral data and the predetermined carbon saving quantification algorithm.

Regarding the calculation process, it should be noted that when using the aforementioned first preset algorithm to calculate carbon savings, each time a user uses internet services, the generation of paper products can be reduced. Therefore, the user's carbon savings are related to the number of times the user uses internet services. At the same time, since carbon emission standards vary from region to region, the user's carbon savings are also related to the region where the user is located. Therefore, in this embodiment of the application, when using the first preset algorithm to calculate carbon savings, the user's carbon savings are calculated based on the behavioral data and the determined preset carbon savings quantification algorithm. Specifically, this includes: determining at least the number of times the user performs the internet service and the user's geographical location when performing the internet service based on the behavioral data; and calculating the user's carbon savings based on the determined number of times the user performs the internet service, the geographical location, and the first preset algorithm.

When using the aforementioned second preset algorithm to calculate carbon savings, the user's carbon savings are related to the distance or number of steps the user walks. Therefore, when using the second preset algorithm to calculate carbon savings, the user's carbon savings are calculated based on the behavioral data and the determined preset carbon savings quantification algorithm. Specifically, this includes: determining at least the number of steps or the distance the user walks based on the behavioral data; and calculating the user's carbon savings based on the determined number of steps or the distance the user walks, and the second preset algorithm.

In practical calculations, if there is a one-to-one correspondence between internet services and carbon-saving quantification algorithms, then the algorithm can be used to calculate the user's carbon savings. If there is a one-to-many correspondence between internet services and carbon-saving quantification algorithms, then the aforementioned algorithms can be combined to calculate the user's carbon savings. The specific method can be determined based on the actual application, and this does not constitute a limitation of this application.

In addition, in some practical application scenarios, the acquired behavioral data may contain redundant data. For example, the acquired behavioral data of users using online ticketing services may include monetary data, but this monetary data is not needed in the process of calculating carbon savings.

In other practical application scenarios, the acquired behavioral data may not be usable directly. For example, when calculating carbon savings based on users' behavior data of using online ticketing services, the calculation is mainly based on the number of times users use online ticketing services. Therefore, it is necessary to perform statistical processing on multiple behavioral data points to determine the corresponding number of times.

Therefore, in this embodiment of the application, before calculation, data processing operations such as statistics, filtering, and elimination can be performed on the acquired behavioral data. As a feasible approach in practice, the application (or server) acting as the execution subject can perform the data processing operations on the behavioral data. As another feasible approach in practice, the application (or server) acting as the execution subject can agree with the behavioral data provider to specify the behavioral data required for calculation. In this way, the behavioral data provider can perform the aforementioned data processing operations on the user's behavioral data and then provide it to the application (or server) acting as the execution subject. This does not constitute a limitation of this application.

Based on the aforementioned behavioral data and carbon saving quantification algorithm, the calculated quantification value represents the amount of carbon emissions reduced by the user, that is, the user's carbon saving.

Of course, in practical applications, a user's carbon savings can be calculated according to a set period or based on the number of times the user uses internet services. This does not constitute a limitation of this application.

S104: Based on the calculated carbon savings of the user and the user identifier, process the specific data corresponding to the user. The specific data is related to the carbon savings.

As one embodiment of this application, after calculating the user's carbon savings, the user's carbon savings over a period of time can be processed, such as through statistics and analysis. As another embodiment of this application, the calculated carbon savings can be converted into an integral form. The higher the integral value, the greater the user's carbon savings. Accordingly, the service provider can provide different services to the user based on the integral value. This does not constitute a limitation of this application.

In this embodiment, the user identifier may include the user's account. Therefore, the specific data may include data within the user's account, including but not limited to: carbon-saving points, carbon-saving levels, carbon-saving badges, and/or carbon-saving related virtual items, etc. Of course, the specific data described in this application can also be other data that reflects the user's carbon-saving amount.

The method described in Figure 1 above will be explained in detail below, taking into account different scenarios:

The relationship between individuals and the internet is becoming increasingly intertwined. With the widespread adoption of mobile internet, many personal behaviors are reflected online; for example, people use ride-hailing apps for transportation and food delivery apps for dining. In other words, users are using internet services more frequently, and compared to traditional offline methods, internet services can reduce users' carbon emissions. Specifically:

Scenario 1: Users use online ticketing services.

Online ticketing services include the online booking, purchase, and refund of tickets for trains, planes, ships, movies, and other attractions. Compared to the traditional method of users going to ticket offices to obtain tickets, online ticketing services can reduce user travel, especially reducing carbon emissions from transportation. It may also reduce paper products (such as printed tickets) generated during the ticket purchase or refund process.

When a user uses an online ticketing service, the service provider (such as a ticketing website) will generate online ticketing data based on the user's online ticketing behavior. This online ticketing data is the user's behavioral data of using the online ticketing service. Therefore, the user's carbon savings can be calculated based on this behavioral data.

In this scenario, the executing entity can be either an application client with carbon saving calculation capabilities (hereinafter referred to as: the computing application) or a server with carbon saving calculation capabilities; the computing application will be used as the executing entity for explanation. Furthermore, since online ticketing services are typically provided by ticketing websites, users can access these services through the application corresponding to that website (hereinafter referred to as: the ticketing application). The behavioral data generated by users accessing the online ticketing service can be generated by the ticketing website's server (hereinafter referred to as: the ticketing server).

Based on this, as shown in Figure 2a, assuming a user purchases tickets online, the process of obtaining and calculating carbon savings in this scenario is as follows:

S201: The computing application sends a request carrying user information to the ticketing server to obtain the user's ticketing data.

In practical applications, when a user needs to purchase tickets online, they can send a purchase request to the ticketing server through the corresponding ticketing application. The purchase request can carry user information (such as the user's ID number, name, and ticketing account registered in the ticketing application) and purchase information (such as the type of ticket to be purchased, time, and location). After receiving the purchase request from the ticketing application, the ticketing server will issue the ticket according to the online purchase request and generate and record the user's ticketing data.

Based on the foregoing, the computing application pre-stores various types of user information for the user. Therefore, the user information carried in the request may include: the user's ID number, name, ticketing account registered in the ticketing application, etc.

In the actual acquisition process, the computing application can send an acquisition request carrying the ticketing account information to the ticketing server based on the pre-entered ticketing account and the corresponding ticketing server, in order to obtain ticketing data related to that account. Of course, the computing application can also acquire the user's ticketing data for a specified time period according to a set cycle. For example, the computing application can send an acquisition request to the ticketing server on a daily cycle, explicitly stating in the acquisition request that it only needs to acquire the user's ticketing data within the last 24 hours. In other words, the acquisition request also carries time information. However, this does not constitute a limitation of this application.

Regarding the acquisition process in this step, in addition to the aforementioned method of active acquisition by the computing application, the computing application can also pre-send the user's registered account (hereinafter referred to as the "computing account") and the user's ticketing account to the ticketing server. This allows the ticketing server to dynamically acquire ticketing data related to the ticketing account and actively push the ticketing data related to the computing account to the computing application. Of course, if the computing application itself has an online ticketing service, and the user uses the online ticketing service provided by the computing application, then in this case, the computing application directly acquires the ticketing data it generates. This does not constitute a limitation of this application.

S202: The ticketing server receives the retrieval request, determines the ticketing data corresponding to the user information carried in the retrieval request, and feeds back the determined ticketing data to the computing application.

The ticketing data includes at least a user ID and identification information reflecting the type of ticketing service. This ticketing data refers to user behavior data related to online ticketing services.

Of course, if the request includes time information, the ticketing server will retrieve the ticketing data of the user that matches the time information.

Furthermore, as described in the aforementioned method, the computing application can specify the ticketing data it needs to the ticketing server. The ticketing server can then process the user's ticketing data and send the processed data to the computing application. For example, the ticketing data stored on the ticketing server may include information such as ticket price, origin, and destination. However, this data is useless for calculating carbon savings. Therefore, the ticketing server can process the user's ticketing data, removing the aforementioned information such as ticket price, origin, and destination, and then send the processed ticketing data to the computing application.

S203: After the computing application obtains the ticketing data, it determines that the ticketing data is associated with the user's account based on the user ID contained in the ticketing data, and determines the carbon saving quantification algorithm required for calculation based on the identification information contained in the ticketing data.

Similar to the aforementioned content, in one approach, a correspondence between identification information and carbon saving quantification algorithms is pre-established. Then, the calculation application can determine the carbon saving quantification algorithm used to calculate carbon saving for ticketing data based on the correspondence between identification information and carbon saving quantification algorithms: a carbon saving quantification algorithm to avoid users taking public transportation, and a carbon saving quantification algorithm to reduce the printing of paper tickets.

In another approach, the computing application can identify the application scenario as online ticketing service through the identification information. For this scenario, a corresponding carbon saving quantification algorithm is predefined. Therefore, the carbon saving quantification algorithm for the online ticketing service scenario can be further identified by the computing application through the identification information as: a carbon saving quantification algorithm to avoid users taking public transportation, and a carbon saving quantification algorithm to reduce the printing of paper tickets.

S204: Based on the determined carbon saving quantification algorithm and the obtained ticketing data, calculate the carbon saving amount of the user using the online ticketing service, and process the specific data corresponding to the user based on the calculated carbon saving amount.

In this scenario, the ticketing application has a location function, which can determine the user's location information (i.e., user location information) when the user issues an online ticketing instruction.

During the calculation process, the application can use the ticket number (which uniquely identifies each online ticketing service) from the obtained ticketing data to count the number of times a user uses the online ticketing service. Furthermore, the application can obtain the user's location information when using the online ticketing service and determine EF_{_y} in the aforementioned formula based on the region corresponding to that location. Therefore, it can calculate the carbon savings from each use of the online ticketing service. If a user uses the online ticketing service multiple times in the same region, since the corresponding EF_{_y} is the same for that region, the carbon savings from reduced paper ticket printing = n * ER_{_y} . However, if a user uses the online ticketing service multiple times in different regions, since the corresponding EF_{_y} is different for each region, the carbon savings from reduced paper ticket printing is the sum of the carbon savings in each region.

In addition, the computing application can determine the nearest ticketing location (such as a train station) based on the user's location information when using the online ticketing service, calculate the distance L between the user's location and the ticketing location, and then calculate the carbon savings by avoiding the user's use of transportation within this distance based on the average carbon emissions W generated by transportation in the above formula.

Therefore, in this scenario, a user's carbon savings may include carbon savings from avoiding transportation or carbon savings from reducing the printing of paper tickets.

Subsequently, the carbon savings achieved by users through online ticketing services can be converted into points. Users can then view their accumulated points after logging into the application that implements the service. In other words, this method allows users to intuitively understand the amount of carbon emissions they reduce by using online ticketing services, i.e., carbon savings.

Scenario 2: Users use online payment services.

Online payment services, including face-to-face payments and transfers conducted online, can reduce paper products (such as printed paper receipts) generated during the payment process compared to traditional payment services, thereby reducing carbon emissions.

When a user uses an online payment service, the service provider will generate online payment data based on the user's online payment behavior. This online payment data is the user's behavior data when using the online payment service, and the user's carbon savings can be calculated based on this behavior data.

Similar to the aforementioned scenarios, the executing entity in this scenario can also be a computing application (or server) with carbon saving calculation capabilities; the explanation will still focus on the computing application as the executing entity. Furthermore, in practical scenarios, service providers capable of offering online payment services can include: e-commerce websites, payment platforms, and/or banks, etc. Taking a payment platform as an example, users can use online payment services through the application corresponding to the payment platform (hereinafter referred to as: payment application), and the behavioral data generated when users use online payment services can be generated by the payment platform's server (hereinafter referred to as: payment server).

Based on this, as shown in Figure 2b, assuming a user makes an online payment to a target user through a payment platform, and both the user and the target user have registered corresponding accounts on the payment platform, the process of obtaining and calculating carbon savings in this scenario is as follows:

S211: The computing application sends a request carrying user information to the payment server to obtain the user's payment log data.

It should be noted that in practical applications, when a user needs to make an online payment, they can send a payment request to the payment server through the corresponding payment application. This payment request carries user information (e.g., the user's registered payment account on the payment platform), target user information (e.g., the target user's registered target account on the payment platform), and payment information (e.g., the payment amount). Upon receiving the payment request from the payment application, the payment server will, based on the received request, retrieve funds matching the payment amount from the user's payment account, allocate them to the target user's target account, and generate payment log data.

Based on the foregoing, the user information carried in the retrieval request may include the user's registered payment account on the payment platform. Similar to the previous scenario, in this scenario, the computing application can also send a retrieval request carrying the payment account information to the payment server based on the pre-entered payment account and the payment server corresponding to that ticketing account, in order to obtain payment log data related to that payment account. Furthermore, the computing application can also send retrieval requests to the payment server at set intervals to obtain the user's payment log data, and the retrieval request can also carry time information, which allows the computing application to obtain the user's payment log data within a specified time period. Further details will not be elaborated upon here.

Regarding the acquisition process in this step, in addition to the aforementioned method of active acquisition by the computing application, the computing application can also pre-send the user's registered computing account and payment account to the payment server. This allows the payment server to dynamically acquire payment log data related to the payment account and then proactively push this payment log data to the computing application. Of course, if the computing application itself provides an online payment service, and the user uses that service, then the computing application directly acquires the generated payment log data. This does not constitute a limitation of this application.

S212: The payment server receives the acquisition request, determines the payment log data corresponding to the user information carried in the acquisition request, and feeds back the determined payment log data to the computing application.

The payment log data includes at least a user ID and identification information reflecting the type of payment service. This payment log data refers to the user's behavior data when using online payment services. Of course, if the request includes time information, the payment server will retrieve the payment log data of the user matching that time information.

Similarly, the calculation of carbon savings does not require data such as payment amount, target user, and payment time from the payment log data. Therefore, the calculation application can perform data processing on the received payment log data to remove unnecessary data during the calculation process, or, according to the agreement with the payment server, have the payment server perform corresponding data processing operations before sending the payment log data.

S213: After obtaining the payment log data, the computing application will determine that the payment log data is associated with the user's account based on the user ID contained in the payment log data, and determine the carbon saving quantification algorithm required for calculation based on the identification information contained in the payment log data.

Similar to the aforementioned content, in one approach, a correspondence between identification information and carbon saving quantification algorithms is pre-established. Then, the calculation application can determine the carbon saving quantification algorithm used to calculate carbon saving for payment log data based on the correspondence between identification information and carbon saving quantification algorithms: the carbon saving quantification algorithm for reducing the printing of paper tickets.

In another approach, the computing application can identify the application scenario as online payment service through the identification information. This scenario has a predefined corresponding carbon saving quantification algorithm. Therefore, the computing application can determine through the identification information that the carbon saving quantification algorithm for online payment service is further: a carbon saving quantification algorithm for reducing the printing of paper tickets.

S214: Based on the determined carbon saving quantification algorithm and the obtained payment log data, calculate the carbon saving amount of the user using the online payment service, and process the specific data corresponding to the user based on the calculated carbon saving amount.

In this scenario, the payment application has a location function, which can determine the user's location information (i.e., user location information) when the user issues an online payment instruction.

Therefore, during the calculation process, the application can use the payment order number (which uniquely identifies each online payment service) from the obtained payment log data to count the number of times a user uses the online payment service. Furthermore, the application can obtain the user's location information when using the online payment service through the payment application, and determine EF_{_y in the aforementioned formula based on the region corresponding to that location. Thus, the carbon savings from each use of the online payment service can be calculated. If a user uses the online payment service multiple times in the same region, since the corresponding EF_y} is the same for that region, the carbon savings from reduced paper printing = n*ER_{_y} . However, if a user uses the online payment service multiple times in different regions, since the corresponding EF_{_y} is different for each region, the carbon savings from reduced paper printing is the sum of the carbon savings in each region.

Similarly, in this scenario, the calculated carbon savings can be converted into points, allowing users to intuitively understand the carbon savings they achieve by using online payment services.

Scenario 3: Users use online reservation services.

Online booking services can include online restaurant reservations, hotel reservations, venue bookings, hospital registration, and other services. Compared to the traditional method of users going to business locations to make reservations, online booking services allow users to avoid going to business locations, thereby reducing the carbon emissions generated by users using transportation.

When a user uses an online appointment service, the service provider (such as a hospital website) will generate online appointment data based on the user's online appointment behavior. This online appointment data is the user's behavior data when using the online appointment service. Therefore, the user's carbon savings can be calculated based on this behavior data.

Similar to the aforementioned scenarios, the executing entity in this scenario can also be an application or server with carbon saving calculation capabilities; the explanation will still focus on the calculation application as the executing entity. Furthermore, in real-world scenarios, service providers capable of offering online booking services can include: booking platforms, hospitals, hotels, and/or restaurants, etc. Taking a booking platform as an example, users can use the online booking service through the booking platform's application (hereinafter referred to as: booking application), and the behavioral data generated when users use the online booking service can be generated by the booking platform's server (hereinafter referred to as: booking server).

Based on this, as shown in Figure 2c, assuming a user registers online through an appointment platform, the process of obtaining and calculating carbon savings in this scenario is as follows:

S221: The computing application sends a request carrying user information to the reservation server to obtain the user's registration data.

It should be noted that in practical applications, when a user needs to register online, they can send a registration request to the appointment server through the corresponding appointment application. This request includes user information (such as the user's medical insurance information, name, ID number, and the appointment account registered in the application), appointment type information (such as specialist appointment or general appointment), and the hospital information selected by the user (such as hospital level and name). Upon receiving the registration request from the application, the appointment server will register the user with the corresponding hospital based on the request. After successful registration, the server will send an electronic registration slip back to the application and generate and record the user's registration data based on this slip.

Based on the foregoing, the computing application pre-stores various types of user information for this user. Therefore, the user information carried in the retrieval request may include: the user's medical insurance information, user name, ID number, and the appointment account registered by the user in the appointment application. Similar to the aforementioned scenario, the computing application can send retrieval requests to the appointment server at set intervals, requesting to retrieve the user's registration data for a specified time period. This will not be described in detail here.

Regarding the acquisition process in this step, in addition to the aforementioned method of active acquisition by the computing application, the computing application can also make an agreement with the reservation server. Specifically, the computing application can send both the user's registered computing account and the user's reservation account to the reservation server, so that the reservation server can dynamically obtain the registration data related to the reservation account and actively push the registration data related to the payment account to the computing application. Of course, if the computing application itself has an online reservation service, and the user uses the online reservation service provided by the computing application, then in this case, the computing application directly obtains the registration data it generates. This does not constitute a limitation of this application.

S222: The reservation server receives the retrieval request, determines the registration data corresponding to the user information based on the user information carried in the retrieval request, and feeds back the determined registration data to the computing application.

The registration data includes at least a user ID and identification information reflecting the type of appointment service. This registration data refers to user behavior data related to using the online appointment service.

Similarly, data such as registration type and appointment date in the registration data are useless for calculating carbon savings. Therefore, similar data processing operations as described above can be used to process the registration data. Please refer to the previous content for details, which will not be elaborated here.

S223: After the application obtains the registration data, it determines that the registration data is associated with the user's account based on the user ID contained in the registration data, and determines the carbon saving quantification algorithm required for calculation based on the identification information contained in the registration data.

In one approach, a pre-established correspondence between identification information and carbon-saving quantification algorithms is established. Based on this correspondence, the calculation application can determine the carbon-saving quantification algorithm used to calculate carbon savings for registration data: a carbon-saving quantification algorithm that avoids users taking public transportation.

In another approach, the computing application can identify the application scenario as an online reservation service through the identification information. This scenario has a predefined corresponding carbon saving quantification algorithm. Therefore, the computing application can further identify the carbon saving quantification algorithm for the online reservation service through the identification information as: a carbon saving quantification algorithm to avoid users taking public transportation.

S224: Based on the determined carbon saving quantification algorithm and the obtained registration data, calculate the carbon saving amount of the user using the online appointment service, and process the specific data corresponding to the user based on the calculated carbon saving amount.

During the calculation process, if the appointment application has location functionality and can determine the user's location (i.e., user location) when the user issues an online registration command, then the registration data obtained by the application will also include the user's location when using the online registration service. Simultaneously, based on the hospital address included in the registration data, the application can determine the hospital's location and calculate the distance L between the user's location and the hospital. Then, according to the average carbon emissions W generated by transportation in the above formula, it can calculate the carbon savings by avoiding the user's use of transportation within this distance.

Similarly, in this scenario, the calculated carbon savings can be converted into points, allowing users to intuitively understand the carbon savings they achieve by using the online booking service.

Scenario 4: Users use online payment services.

Online payment services can include online payment for water, electricity, gas, traffic fines, and other bills. These services allow users to pay without going to a payment location, reducing carbon emissions from traveling to payment points. They also reduce the need for printed paper receipts.

When a user uses the online payment service, the service provider will generate online payment data based on the user's online payment behavior. This online payment data is the user's behavior data when using the online payment service. Based on this behavior data, the user's carbon savings can be calculated.

Similar to the aforementioned scenarios, this scenario focuses on the computing application as the executing entity. Furthermore, in real-world scenarios, service providers capable of offering online payment services can include: online payment platforms, payment websites, and/or banks. Taking a payment platform as an example, users can utilize the online payment service through the application corresponding to the payment platform (hereinafter referred to as: payment application). The behavioral data generated when users use the online payment service can be generated by the payment platform's server (hereinafter referred to as: payment server).

Based on this, as shown in Figure 2d, assuming a user pays traffic fines online through a payment platform, and the user has a registered account on that platform with sufficient funds, the process of obtaining and calculating carbon savings in this scenario is as follows:

S231: The computing application sends a request carrying user information to the payment server to obtain the user's payment data.

It should be noted that in practical applications, when a user needs to make an online payment, they can send a payment request to the payment server through the corresponding payment application. This request includes user information (such as the user's driver's license number, ID card number, fine ticket number, and the payment account registered on the payment platform). Upon receiving the payment request from the application, the payment server will deduct the corresponding amount from the user's account, process the payment through the relevant traffic payment website, and, upon successful payment, send an electronic payment voucher to the application. Simultaneously, the server will generate and record the user's payment data based on this electronic payment voucher.

Based on the foregoing, the computing application pre-stores various types of user information. Therefore, the user information carried in the retrieval request may include: the user's driver's license number, ID card number, fine ticket number, and the payment account registered by the user on the payment platform. Similar to the aforementioned scenario, the computing application can send retrieval requests to the payment server at set intervals, requesting payment data for the user within a specified time period. Further details will not be provided here.

Regarding the acquisition process in this step, in addition to the method of active acquisition by the computing application as described above, the computing application can also make an agreement with the payment server (the agreement process can be referred to the aforementioned scenario, and will not be repeated here), in which case the payment server actively pushes payment data carrying the aforementioned user information to the computing application. Of course, if the computing application itself has an online payment service, and the user uses the online payment service provided by the computing application, then in this case, the computing application directly acquires the payment data it generates. This does not constitute a limitation of this application.

S232: The payment server receives the acquisition request, determines the payment data corresponding to the user information based on the user information carried in the acquisition request, and feeds back the determined payment data to the computing application.

The payment data includes at least a user ID and identification information reflecting the type of payment service. This payment data refers to user behavior data related to online payment services. In practical applications, data processing operations can be performed on the payment data; details are provided above and will not be elaborated upon here.

S233: After the computing application obtains the payment data, it determines that the payment data is associated with the user's account based on the user ID contained in the payment data, and determines the carbon saving quantification algorithm required for calculation based on the identification information contained in the payment data.

Similar to the aforementioned content, in one approach, a correspondence between identification information and carbon saving quantification algorithms is pre-established. Then, the calculation application can determine the carbon saving quantification algorithms used to calculate carbon saving for payment data based on the correspondence between identification information and carbon saving quantification algorithms: carbon saving quantification algorithms to avoid users taking public transportation and carbon saving quantification algorithms to reduce the printing of paper tickets.

In another approach, the computing application can identify the application scenario as online payment service through the identification information. This scenario has a predefined corresponding carbon saving quantification algorithm. Therefore, the computing application can further identify the carbon saving quantification algorithm in the online payment service scenario through the identification information as: a carbon saving quantification algorithm to avoid users taking public transportation, and a carbon saving quantification algorithm to reduce the printing of paper tickets.

S234: Based on the determined carbon saving quantification algorithm and the obtained payment data, calculate the carbon saving amount of the user using the online payment service, and process the specific data corresponding to the user based on the calculated carbon saving amount.

In this scenario, the payment application has a location function, which can determine the user's location information (i.e., user location information) when the user issues an online payment instruction.

Therefore, during the calculation process, the application can use the payment slip number (which uniquely identifies each online payment service) from the obtained payment data to count the number of times a user uses the online payment service. Furthermore, the application can obtain the user's location information when using the online payment service and determine EF_{_y} in the aforementioned formula based on the region corresponding to that location. Thus, the carbon savings from each use of the online payment service can be calculated. If a user uses the online payment service multiple times in the same region, since the corresponding EF_{_y} is the same for that region, the carbon savings from reduced paper receipts = n * ER_{_y} . However, if a user uses the online payment service multiple times in different regions, since the corresponding EF _{_y} is different for each region, the carbon savings from reduced paper receipts is the sum of the carbon savings in each region.

In addition, the computing application can determine the nearest payment location (such as a bank) based on the user's location information when using the online payment service, calculate the distance L between the user's location and the payment location, and then calculate the carbon savings by avoiding the user's use of transportation within this distance based on the average carbon emissions W generated by transportation in the above formula.

Therefore, in this scenario, a user's carbon savings may include carbon savings from avoiding transportation or carbon savings from reducing the printing of paper tickets.

In this scenario, the computing application converts the calculated carbon savings into points, allowing users to intuitively understand the carbon savings they achieve by using online payment services.

In addition to the scenarios mentioned above, walking can also help reduce carbon emissions, as shown in the following scenarios:

Scenario 5: Users walk and use health services to monitor their walking data.

Walking can reduce carbon emissions from using transportation. In the scenarios described above, users can walk to various service locations, such as hospitals for registration, ticket offices for purchase, and payment locations for bills, all of which contribute to reducing carbon emissions.

Walking data can be generated by health service applications with walking data collection capabilities (hereinafter referred to as "walking applications"), and then the user's carbon savings can be calculated based on this walking data. The walking data includes at least one of steps and walking distance.

Similar to the previous scenario, this scenario focuses on the computational application as the executing entity. Based on this, as shown in Figure 2e, the process of obtaining and calculating carbon savings in this scenario is as follows:

S241: The computing application sends a request carrying user information to the walking application in order to obtain the user's walking data.

It should be noted that in practical applications, the walking data can be obtained by the walking application through corresponding collection algorithms, models, and/or sensing devices (such as smart bracelets, smartwatches, etc.) after processing. This does not constitute a limitation of this application. It is assumed that the walking data includes: the user's step count, the user's location information during walking, walking distance, etc., and that the walking data also carries user information (such as the user's registered account in the walking application).

Accordingly, the acquisition request issued by the computing application carries the user's account in order to obtain walking data associated with that account.

Regarding the acquisition process in this step, in addition to the aforementioned method of active acquisition by the computing application, the computing application can also agree with the walking application to have the walking application actively push walking data carrying the aforementioned user information to the computing application. Of course, if the computing application itself has the function of collecting walking data, then in this case, the computing application directly acquires the walking data it generates. This does not constitute a limitation of this application.

S242: The walking application receives the acquisition request, determines the walking data corresponding to the user information carried in the acquisition request, and feeds back the determined walking data to the computing application.

The walking data includes at least a user ID and identification information reflecting the type of walking behavior. In other words, the walking data refers to the behavioral data corresponding to a user's walking activity.

S243: After the computing application obtains the walking data, it determines that the walking data is associated with the account based on the user ID contained in the walking data, and determines the carbon saving quantification algorithm required for calculation based on the identification information contained in the walking data.

Similar to the aforementioned content, in one approach, a correspondence between identification information and carbon saving quantification algorithms is pre-established. Then, based on the identification information, the calculation application can determine the carbon saving quantification algorithm used to calculate carbon saving for walking data: a carbon saving quantification algorithm that avoids users taking public transportation.

In another approach, the computing application can determine the application scenario as user walking through the identification information. This scenario has a predefined corresponding carbon saving quantification algorithm. Therefore, the computing application can determine the carbon saving quantification algorithm for user walking through the identification information as: the carbon saving quantification algorithm for avoiding user travel by transportation.

S244: Based on the determined carbon saving quantification algorithm and the acquired walking data, calculate the carbon saving amount of the user's walking, and process the specific data corresponding to the user based on the calculated carbon saving amount.

When calculating the carbon savings corresponding to walking data, since the walking data contains the user's location information during the walking process, the computing application can determine the user's walking distance on the transportation route based on the location information in the walking data. Therefore, based on the walking distance and the carbon savings quantification algorithm of walking, the carbon savings of the user's walking can be determined.

Of course, if the computing application (or server) that performs the task has the function of collecting user walking data, then in this case, the computing application (or server) can directly obtain the walking data it generates.

Based on the above, the data processing method in this application can aggregate fragmented user behavior data and, based on the aggregated behavior data and the corresponding carbon-saving quantification algorithm, calculate the user's reduced carbon emissions, i.e., the user's carbon savings. The corresponding service provider can further process the user's data based on the calculated carbon savings. This method allows users to more intuitively know their own carbon savings without having to query or calculate it themselves, which is more convenient for users. Furthermore, by having the service provider perform data processing on the user based on the user's carbon savings, such as accumulating points and upgrading account levels, the corresponding services can be linked to the user's carbon savings.

As a practical application, the content described in the embodiments of this application (including the method shown in Figure 1, the scenarios shown in Figures 2a-2e, and subsequent content) can all be based on the architecture shown in Figure 3. Specifically, in Figure 3, the application client obtains fragmented user behavior data generated by the user, third-party applications, and third-party services. This behavior data includes behavior data generated by the user using different Internet services. The application client sends the obtained behavior data to the server to calculate the user's carbon savings and perform corresponding data processing based on the carbon savings. The processing results are then displayed to the user through the application client. This does not constitute a limitation of this application.

In this embodiment of the application, during the calculation of a user's carbon savings, since the acquired user behavior data contains different types of behavior data, and there are certain differences between the carbon savings quantification algorithms corresponding to each type of behavior data, the carbon savings of a user can be calculated separately for each type of behavior data. That is, in this embodiment of the application, the user's carbon savings are calculated based on the acquired behavior data and the preset carbon savings quantification algorithm. Specifically, for each type of behavior data, the carbon savings corresponding to that type of behavior data are determined based on that type of behavior data and the preset carbon savings quantification algorithm.

As mentioned earlier, the acquired behavioral data typically contains corresponding identification information, which can be used to determine the type of behavioral data. This identification information may include: a type identifier bit in the business order number, type information, etc.

For example, the business data of online payment transactions includes the order number of each online payment transaction. The identifier in this order number can be used to determine that the transaction is an online payment transaction. Similarly, the business data of online booking transactions includes business type information, which can be used to determine that the transaction is an online booking transaction. This does not constitute a limitation of this application.

For each type of business data identified, a corresponding carbon-saving quantification algorithm can be used to calculate the carbon savings corresponding to that type of business data. For details, please refer to the preceding content; further elaboration will not be repeated here.

After determining the user's carbon savings based on the above, specific data corresponding to the user can be processed based on the user's carbon savings. As one method in this application embodiment, processing the specific data corresponding to the user based on the calculated carbon savings may include: obtaining the user's carbon savings in multiple Internet services within a preset period, accumulating the obtained carbon savings, and processing the specific data based on the accumulated carbon savings.

Specifically, in actual operation, users may use different Internet services at any time. The aforementioned content provides a way to calculate the user's carbon savings according to a preset period. Therefore, the user's carbon savings within the preset period can be obtained and accumulated.

More specifically, the process of processing the specific data based on the accumulated carbon savings can be as follows: the calculated accumulated carbon savings of the user within a preset period is added to the user's total carbon savings to obtain an updated total carbon savings, and the specific data is processed based on the updated total carbon savings.

In the process of accumulating carbon savings, one can either separately calculate the carbon savings corresponding to each type of service and add them separately to the historical total carbon savings for each service, or first calculate the carbon savings for each type of service and then add them together to obtain the user's total carbon savings. This total carbon savings reflects the statistical value of carbon savings corresponding to the user's fragmented behavioral data. Of course, the method of accumulating carbon savings does not constitute a limitation on this application.

In this embodiment of the application, users continuously generate new behaviors, and correspondingly, behavioral data is continuously generated. Therefore, the user's carbon savings can be calculated based on the newly generated behavioral data and accumulated with the user's total carbon savings.

The updated carbon savings can be displayed to users, allowing them to intuitively understand their own carbon savings. Of course, as one method in this application embodiment, the service provider can also convert the updated carbon savings into points. In other words, the calculated carbon savings accumulated by the user within a preset period can be added to the user's total carbon savings. This can include: converting the calculated carbon savings of the user into points according to a preset conversion rule, and adding the converted points to the user's total points to obtain the updated total points.

The preset conversion rules can include corresponding conversion coefficients, which can then be used to convert a user's carbon savings into corresponding points. In practical applications, based on the number of points accumulated, service providers can offer users different services, such as providing goods that can be redeemed with points, or offering discounts based on the number of points accumulated.

The conversion methods described above are not limited to points; they can also include user account levels, badges, etc. This does not constitute a limitation of this application.

The points accumulation process described above can be automated according to a set period, such as accumulating the points converted on a daily basis with the user's total points. Alternatively, points can be accumulated based on user confirmation. For this method, a control for accumulating points can be provided to the user. This control can take various forms, such as a floating control, an embedded control, or a pop-up control. For example, as shown in Figure 4a, the application interface embeds a control used to accumulate points.

Based on this, the converted points can be added to the user's total points, which may include: receiving a confirmation instruction from the user through the control and adding the converted points to the user's total points.

For example, with the control in Figure 4a, users can accumulate points by clicking the control.

In practical applications, one option is to calculate and display the total points for different types of behavior (including different types of business behavior and walking). That is, as shown in Figure 4b, the interface includes different types of behavior items, and displays the total points for each type of behavior within each category. Alternatively, another option in practical applications is to display the total global points, as shown in Figure 4c. The total points in Figure 4c represent the total global points corresponding to all of the user's behavior data. This does not constitute a limitation of this application.

Furthermore, as an extension in practical applications, different users can obtain each other's unaccumulated points. That is, the method also includes: receiving a user's acquisition instruction for other users' unaccumulated points, acquiring all or part of the unaccumulated points of other users according to the acquisition instruction, and accumulating the acquired all or part of the points with the user's total points.

The other users mentioned above are users who are associated with the user, such as the contact users in the user's contact list.

In practical applications, the server calculates points for each user and stores the relationships between different users. Then, for any given user, the server will determine the users associated with that user based on the stored relationships and send the points data of each user to that user so that the user's points data can be displayed through the application used by that user.

The points data for each user includes at least one of the following: the current total points for each user, the total points corresponding to each type of behavioral data, and unaccumulated points.

In this way, the user can intuitively view the unaccumulated points of each contact in the contact list, the total points of each contact, and the total points corresponding to each type of behavioral data through the application they use.

If a user clicks to retrieve unaccumulated points for a contact user, the application used by that user will send a retrieval request to the server. The server will then transfer the unaccumulated points of that contact user to the user who sent the retrieval request, based on the user identifier in the retrieval request.

Of course, in one alternative method, when a user obtains points that other users have not accumulated, it does not mean obtaining all the points that other users have not accumulated, but rather there is a certain quantity limit, such as: the actual amount obtained is 10% of the points that other users have not accumulated.

As shown in Figure 5a, a practical application scenario is provided. In Figure 5a, each contact in the user's contact list displays unaccumulated points. The user can then click on any contact to retrieve their unaccumulated points. Alternatively, as shown in Figure 5b, when the user clicks on any contact, they will enter that contact's detailed interface, which displays the unaccumulated points corresponding to different types of actions taken by that contact. The user can then click on different action items to retrieve the unaccumulated points corresponding to that type of action. It is evident that the above method can increase user interaction and engagement. Of course, the scenarios shown in Figures 5a and 5b do not constitute a limitation of this application.

In this embodiment of the application, the method can also be to allocate virtual items to the user. That is, the method further includes: determining the updated total points of the user, and allocating virtual items to the user that match the updated total points.

The virtual items may include: virtual trees, virtual badges, virtual medals, etc.

Of course, in this embodiment, virtual items have different display states depending on the total points accumulated. Specifically, based on pre-defined point ranges, the point range into which the user's total points fall is determined, and the display state of the user's virtual items is determined based on a pre-set correspondence between point ranges and virtual item display states. The display state of the virtual items includes, but is not limited to, the size, shape, and color of the virtual items.

For example, suppose the system is pre-divided into three integration intervals in ascending order of numerical values. The size of the virtual tree corresponding to these three integration intervals also increases from small to large. Then, based on the user's carbon savings, the user's total points can be determined, and the interval into which the user's total points fall can be determined, thus determining the size of the virtual tree allocated to the user. As the user's carbon savings increase, the user's total points also increase accordingly. When the user's total points reach the next integration interval, the size of the user's virtual tree also increases accordingly.

For example, a user's virtual items can also be virtual medals. As a user's carbon savings increase, the user's total points also increase, and the virtual medal can change from bronze to silver, and then to gold.

Of course, the examples above do not constitute a limitation of this application.

In practical applications, virtual trees come in different types, and each type of virtual tree corresponds to a different total number of points. The total number of points a user has reflects the amount of carbon savings a user has. Therefore, the points corresponding to a virtual tree essentially reflect the amount of carbon emissions that type of tree can absorb in the natural environment.

As an extension of this approach, the service provider can use a third-party fund sponsorship to plant trees in the user's name. Specifically, the service provider will determine the tree information (including tree species, age, etc.) that matches the user's total points, and send the tree information and the user's information to the third-party fund so that the third-party fund can determine the appropriate trees based on the tree information and plant them in the user's name.

This method converts users' carbon savings into actual trees, which is beneficial to environmental protection and can also promote users' environmental awareness.

The above describes the data processing method provided in the embodiments of this application. Based on the same idea, the embodiments of this application also provide a data processing apparatus, as shown in FIG6, including:

The acquisition module 601 acquires user behavior data, which is generated when the user uses Internet services. The behavior data includes a user identifier that indicates the user's identity and identification information that indicates the Internet service corresponding to the behavior data.

The determining module 602 determines at least one preset carbon saving quantification algorithm based on the identification information of the Internet service;

The calculation module 603 calculates the user's carbon savings based on the behavioral data and the determined preset carbon saving quantification algorithm.

The processing module 604 processes specific data corresponding to the user based on the calculated carbon saving amount of the user and the user identifier, wherein the specific data is related to the carbon saving amount.

The at least one preset carbon saving quantification algorithm specifically includes: a first preset algorithm, which is a carbon saving quantification algorithm for saving paper products; and a second preset algorithm, which is a carbon saving quantification algorithm for reducing the use of transportation.

The determining module 602 determines at least one preset carbon saving quantification algorithm based on the identification information of the Internet service and the pre-saved correspondence between the Internet service and the carbon saving quantification algorithm.

When using the first preset algorithm to calculate carbon savings, the calculation module 603 determines, based on the behavioral data, at least the number of times the user performs the Internet service and the geographical location of the user when performing the Internet service. Based on the determined number of times the user performs the Internet service, the geographical location, and the first preset algorithm, the carbon savings of the user are calculated.

When using the second preset algorithm to calculate carbon savings, the calculation module 603 determines at least the number of steps or the distance the user walks based on the behavioral data, and calculates the user's carbon savings based on the determined number of steps or the distance the user walks, and the second preset algorithm.

The internet services specifically include at least one of the following: electronic payment, online reservation, online ticketing, online bill payment, and health services.

The processing module 604 obtains the amount of carbon saved by the user in multiple Internet services within a preset period, accumulates the obtained carbon savings, and processes the specific data based on the accumulated carbon savings.

The processing module 604 adds the calculated carbon savings amount accumulated by the user within a preset period to the user's total carbon savings amount to obtain an updated total carbon savings amount, and processes the specific data based on the updated total carbon savings amount.

Furthermore, the processing module 604 converts the calculated carbon savings of the user into points according to the preset conversion rules, and adds the converted points to the user's total points to obtain the updated total points.

The processing module 604 provides the user with a control for accumulating points, receives the confirmation command issued by the user through the control, and adds the converted points to the user's total points.

The device also includes: a points acquisition module 605, which receives an acquisition instruction issued by the user for points that other users have not accumulated, acquires all or part of the points that other users have not accumulated according to the acquisition instruction, and adds the acquired points to the user's total points.

The device further includes an allocation module 606, which determines the user's updated total points and allocates virtual items to the user that match the updated total points. The virtual items have different display states depending on the total points.

This invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and/or one or more blocks of the block diagrams.

These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and/or one or more block diagrams.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and/or one or more block diagrams.

In a typical configuration, a computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims (8)

1. A data processing method, comprising: Obtain user payment data, which is user behavior data when using online payment services; The carbon saving quantification algorithms used to calculate carbon saving based on payment data are determined to be: carbon saving quantification algorithms for reducing travel by public transportation and carbon saving quantification algorithms for saving paper products. The user's carbon savings are calculated based on the payment data and the predetermined carbon-saving quantification algorithm. Based on the calculated carbon savings of the user, the carbon savings of the user are processed into specific data to reflect the carbon savings of the user. The processing includes at least: converting the calculated carbon savings into an integral form. 2. The method according to claim 1, wherein calculating the user's carbon savings includes: Based on the payment data, the geographical location of the user when using the online payment service is determined; The user's carbon savings are calculated based on the geographical location. 3. The method according to claim 2, when using a carbon saving quantification algorithm for saving paper products, calculating the user's carbon saving includes: Based on the payment data, the geographical location of the user when using the online ticketing service is determined; Based on the geographical location, determine the emission intensity of the corresponding paper manufacturers in the region; Calculate the carbon savings for the user based on the emission intensity. 4. The method according to claim 2, when using a carbon saving quantification algorithm for reducing transportation travel, calculating the user's carbon saving includes: Based on the payment data, the geographical location of the user when using the online payment service is determined; Determine the distance between the geographical location and the payment location; The carbon savings for the user are calculated based on the determined distance and the average carbon emissions generated by the means of transportation. 5. A data processing apparatus, comprising: The acquisition module acquires the user's payment data, which is the user's behavior data when using online payment services; The module determines the carbon saving quantification algorithm used to calculate carbon saving based on payment data: a carbon saving quantification algorithm for reducing transportation use and a carbon saving quantification algorithm for saving paper products. The calculation module calculates the user's carbon savings based on the payment data and the determined preset carbon saving quantification algorithm. The processing module processes the calculated carbon saving amount of the user into specific data that reflects the user's carbon saving amount. The processing includes at least converting the calculated carbon saving amount into an integral form. 6. The apparatus of claim 5, wherein the computing module is specifically used for: Based on the payment data, the geographical location of the user when using the online payment service is determined; The user's carbon savings are calculated based on the geographical location. 7. The apparatus of claim 6, when using a carbon saving quantification algorithm for paper-saving products, the calculation module is specifically used for: Based on the payment data, the geographical location of the user when using the online ticketing service is determined; Based on the geographical location, determine the emission intensity of the corresponding paper manufacturers in the region; Calculate the carbon savings for the user based on the emission intensity. 8. The apparatus of claim 6, wherein when using a carbon saving quantification algorithm for reducing travel by public transport, the calculation module is specifically configured to: Based on the payment data, the geographical location of the user when using the online payment service is determined; Determine the distance between the geographical location and the payment location; The carbon savings for the user are calculated based on the determined distance and the average carbon emissions generated by the means of transportation.