WO2017219874A1 - 一种资源处理方法及装置 - Google Patents

一种资源处理方法及装置 Download PDF

Info

Publication number
WO2017219874A1
WO2017219874A1 PCT/CN2017/087657 CN2017087657W WO2017219874A1 WO 2017219874 A1 WO2017219874 A1 WO 2017219874A1 CN 2017087657 W CN2017087657 W CN 2017087657W WO 2017219874 A1 WO2017219874 A1 WO 2017219874A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
account
user
prepaid
total
Prior art date
Application number
PCT/CN2017/087657
Other languages
English (en)
French (fr)
Inventor
庄里
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to KR1020197002131A priority Critical patent/KR102192876B1/ko
Priority to MYPI2018002867A priority patent/MY193309A/en
Priority to EP17814612.2A priority patent/EP3477562A1/en
Priority to CA3029082A priority patent/CA3029082A1/en
Priority to BR112018076877A priority patent/BR112018076877A8/pt
Priority to AU2017280384A priority patent/AU2017280384B2/en
Priority to JP2018567695A priority patent/JP6761056B2/ja
Priority to MX2019000126A priority patent/MX2019000126A/es
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Priority to SG11201811436YA priority patent/SG11201811436YA/en
Priority to RU2019101250A priority patent/RU2718155C1/ru
Publication of WO2017219874A1 publication Critical patent/WO2017219874A1/zh
Priority to US16/227,813 priority patent/US10805410B2/en
Priority to PH12018502743A priority patent/PH12018502743A1/en
Priority to US16/722,495 priority patent/US10827016B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06312—Adjustment or analysis of established resource schedule, e.g. resource or task levelling, or dynamic rescheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles

Definitions

  • the present application relates to the field of computer technologies, and in particular, to a resource processing method and apparatus.
  • a user uses a service provided by a service provider (such as a website), it usually consumes a certain amount of resources from the service provider. For the user, in order to be able to use the service normally, the corresponding amount of resource cost is usually fed back to the service provider.
  • a service provider such as a website
  • the service providing aspect provides the user with an online prepaid resource (such as an electronic coupon, an electronic prepaid card, etc., hereinafter referred to as: a prepaid resource), and the prepaid resource can be used by the user in the service provider.
  • a prepaid resource such as an electronic coupon, an electronic prepaid card, etc., hereinafter referred to as: a prepaid resource
  • the prepaid resource can be used by the user in the service provider.
  • the corresponding amount of resource cost is offset.
  • the user can obtain the prepaid resources from the service provider one by one. Then, when the user uses the service provided by the service provider, the user can use the acquired prepaid resources.
  • the server in the background of the service provider (hereinafter referred to as the server) will create a resource account for the prepaid resources acquired by the user each time (that is, each resource account corresponds to the prepaid resource acquired by the user each time), and establishes The association between each resource account and the user.
  • the server determines each resource account associated with the user, and deducts the corresponding amount of prepaid resources from each resource account in turn, until the total amount of the prepaid resources deducted and the resources required by the service. The total amount is consistent.
  • a user purchases multiple electronic prepaid cards provided by the service provider, and accordingly, the server establishes a prepaid account in the background for each electronic prepaid card, and associates the user, then, when the user wants to pay
  • the server determines a plurality of prepaid accounts of the user according to the user information, and deducts corresponding ones from the prepaid account one by one. The amount to complete the payment.
  • the server needs to deduct a corresponding amount of prepaid resources from each resource account one by one, which takes a certain period of time, especially in the case that a large number of users use their own prepaid resources, the processing of the server will be increased.
  • the load makes the time required to deduct the prepaid resource process prolonged, which reduces the efficiency of the user's normal business acquisition.
  • the embodiment of the present application provides a resource processing method for solving the problem that the efficiency of the server of the service provider deducting the prepaid resource of the user is reduced in the prior art.
  • the embodiment of the present application provides a resource processing apparatus, which is used to solve the problem that the efficiency of the server of the service provider deducting the prepaid resource of the user in the prior art is reduced.
  • the prepaid card funds of the same amount as the payment amount are deducted from the total prepaid card account to process the payment request.
  • Receiving a module receiving a service request sent by a user
  • Determining a module determining a resource consumption amount corresponding to the service request
  • a total account module which determines a pre-created total resource account of the user; wherein the total resource account includes all prepaid resources belonging to the user;
  • the processing module obtains, from the total resource account, a prepaid resource corresponding to the resource consumption, to process the service request.
  • Receiving a module receiving a payment request sent by a user
  • Determining a module determining a payment amount corresponding to the payment request
  • a total account module which determines a prepaid account of the user's total prepaid card; wherein the total prepaid card account includes all prepaid card funds belonging to the user;
  • the processing module deducts the prepaid card funds of the same amount as the payment amount from the total prepaid card account to process the payment request.
  • the service provider's server collects statistics on the prepaid resources in each sub-resource account established for the user, and establishes a total resource account for the user, and stores the total prepaid resource amount obtained in the statistics in the total resource account.
  • the server acquires the prepaid resources of the user, it is not necessary to separately obtain the prepaid resources from each of the sub resource accounts, and the corresponding amount of prepaid resources can be directly obtained from the total resource accounts.
  • such an approach can effectively reduce the length of time that the server obtains the prepaid resources, thereby improving the processing efficiency of the service.
  • FIG. 1 is a schematic diagram of a resource processing architecture provided by an embodiment of the present application
  • FIG. 1b is a schematic diagram of a resource processing process according to an embodiment of the present application.
  • 2a is a schematic diagram 1 of creating a resource account according to an embodiment of the present application
  • FIG. 2b is a schematic diagram 2 of creating a resource account according to an embodiment of the present application.
  • 2c is a schematic diagram 3 of creating a resource account according to an embodiment of the present application.
  • FIG. 3 is a schematic diagram of a resource account after using prepaid resources according to an embodiment of the present application.
  • 4a is a schematic diagram 1 of prepaid resources in the case of having a conversion coefficient according to an embodiment of the present application
  • FIG. 4b is a schematic diagram 2 of prepaid resources in the case of having a conversion coefficient according to an embodiment of the present application;
  • FIG. 4b is a schematic diagram 2 of prepaid resources in the case of having a conversion coefficient according to an embodiment of the present application;
  • FIG. 5 is a schematic diagram of a resource processing architecture in a merchant scenario according to an embodiment of the present application.
  • FIG. 5b is a schematic diagram of a resource processing flow based on the architecture shown in FIG. 5a;
  • FIG. 6 is a schematic structural diagram of a resource processing apparatus according to an embodiment of the present application.
  • FIG. 7 is a schematic structural diagram of a resource processing apparatus in a merchant scenario according to an embodiment of the present disclosure.
  • the server in the process of using the prepaid resource by the user, the server usually obtains the corresponding prepaid resource from the prepaid account corresponding to the user one by one, and the process takes a certain period of time, and the service provider provides the service for the user. The efficiency is lower.
  • a resource processing method is provided, so that the server can quickly obtain the prepaid resources of the user, and improve the efficiency of providing services for the user.
  • the service provider described in the embodiment of the present application may be a service provider capable of providing an online service, such as a website, a telecommunication operator, or the like; or may be a service provider capable of providing an offline service.
  • the prepaid resources provided by the service provider are still online prepaid resources, such as stores, restaurants, and the like.
  • the server of the service provider may be, for example, a website server, a telecom carrier server, or a server for processing online prepaid resources, etc., and does not constitute a limitation on the present application.
  • FIG. 1a a schematic diagram of the architecture of resource processing in the implementation of the present application is shown. Based on the architecture shown in FIG. 1a, the resource processing method in the embodiment of the present application is as shown in FIG. 1b, and specifically includes the following steps:
  • S101 Receive a service request sent by a user.
  • the user can use the service provided by the service provider.
  • the user can send a corresponding service request, such as: when the user uses the cloud computing service, issue a cloud computing request; or, the user uses the network storage.
  • a corresponding service request such as: when the user uses the cloud computing service, issue a cloud computing request; or, the user uses the network storage.
  • Business issue storage requests, and more.
  • the service provider's server will receive the service request sent by the user.
  • the user may use a terminal (which may include: a mobile phone, a tablet computer, a computer, etc.) to scan the code, click a service control in the corresponding page, and the like, and send a service to the service provider. request.
  • a terminal which may include: a mobile phone, a tablet computer, a computer, etc.
  • S102 Determine a resource consumption amount corresponding to the service request.
  • a service provider when a service provider processes a user's service request, it usually consumes a certain amount of resources. For example, in the process of providing a cloud computing service to a user, the service provider consumes corresponding processing resources; During the course of the business, the storage space in the database will be consumed. Then, the user needs to pay the corresponding resource cost to the service provider.
  • the server when the server receives the service request from the user, it first determines the quantity of resources (ie, the amount of service consumption) required to process the service request, so as to determine the resource cost to be paid by the user in the subsequent process.
  • the quantity of resources ie, the amount of service consumption
  • the total resource account includes all prepaid resources belonging to the user.
  • the total resource account of the user is based on each resource account of the user (in order to distinguish from the total resource account, the resource account respectively established for the user to obtain the prepaid resource in advance) is called: the sub-resource account.
  • the sub-resource account Pre-established, it can be considered that the prepaid resource stored in the total resource account is the sum of the prepaid resources in the user's sub-resource accounts, that is, the total resource account contains the total amount of prepaid resources belonging to the user.
  • the total resource account of the user is The total amount of prepaid resources included is 300.
  • the total resource account in the embodiment of the present application is created by the server for the user.
  • the identifier of the user (such as: userID, the service account registered by the user in the server, and the like) is stored in the server, and then the server may create a total resource for the user based on the identifier of the user. Account. For example, if a user registers a business account named “xiaoming” in the server, the server can create a total resource account “xiaoming-general source account” for the user based on the account name of the business account, and create a total resource account. The server then aggregates and stores all of the user's prepaid resources in the total resource account.
  • the total resource account will be summarized by all the prepaid resources of a certain user, so the process of subsequently deducting the prepaid resources does not need to be obtained from the sub-resource accounts one by one.
  • S104 Obtain a prepaid resource corresponding to the resource consumption amount from the total resource account, to process the service request.
  • the corresponding amount of resources can be deducted from the total resource account of the user.
  • the amount of resources consumed by the service request is not greater than the total amount of prepaid resources included in the total resource account, and then the server can deduct the amount of resources consumed by the service request from the total resource account. For example, if the amount of resources consumed by the service request is 80 and the total amount of prepaid resources in the total resource account of the user is 100, then the amount of prepaid resources of 80 can be deducted from the total resource account, and then the remaining prepayments in the total resource account. The amount of resources is 20.
  • the server may feed back a failure notification to the terminal to inform the user that the prepaid resources owned by the user are insufficient to offset the resource consumption of the service request.
  • the server may deduct all prepaid resources in the total resource account, and for the insufficient deductible part, feedback the difference to the terminal, and the user may use other methods to pay the remaining resources. For example, suppose the amount of resources consumed by the service request is 200, and the total amount of prepaid resources in the total resource account of the user is 100. At this time, the total amount of all prepaid resources in the total resource account of the user may be deducted, but the service request is consumed. The remaining resources are still 100, so users can choose the way to directly pay for resources to make up the remaining resource consumption. This does not constitute a limitation on the present application.
  • the server of the service provider pre-creates the total resource account of the user, wherein the total resource account summarizes all the prepaid resources belonging to the user, so when the server receives the service request of the user, it determines that the service request is required.
  • the amount of resources consumed so that a corresponding amount of prepaid resources can be directly obtained in the total resource account, which is used to offset the resources consumed by the service request.
  • the prepaid resources are deducted from the user's sub-resource accounts one by one compared with the prior art.
  • the above manner in the embodiment of the present application can directly obtain a corresponding amount of prepaid resources from the total resource account of the user, effectively improving the efficiency in obtaining the prepaid resources, and avoiding the server being one by one in the user.
  • the process of calculating the amount of prepaid resources in multiple sub-resource accounts can reduce the workload of the server.
  • execution entities of the steps of the method provided by the foregoing embodiments may all be the same device.
  • the execution entity may be a server of the service provider.
  • pre-creating a total resource account of the user includes: determining each pre-established, each of the users. a sub-resource account, which collects total resources of pre-paid resources in each sub-resource account, and creates a total resource account for the user according to the total amount of resources obtained by statistics, and stores the pre-paid resources corresponding to the total resource amount in the total In the resource account.
  • each sub-resource account separately stores prepaid resources obtained by the user each time
  • the server After the user obtains the prepaid resources from the service provider (for example, the user purchases the electronic prepaid card, the electronic coupon), the server establishes a corresponding account for the user to store the obtained prepaid resources.
  • the user uses the user identifier (such as the userID, the service account, and the like), so that the server can obtain the prepaid resource each time the user obtains the prepaid resource.
  • the user ID of the user thereby establishing a sub-resource account belonging to the user respectively. Because the process of establishing a sub-resource account belongs to The prior art is not described in detail in the embodiments of the present application.
  • Each sub-resource account belonging to the user stores the pre-paid resources obtained by the user each time, and then, for each sub-resource account, statistics can be performed to determine the total amount of pre-paid resources belonging to the user. On this basis, a total resource account is created for the user, and all prepaid resources belonging to the user are summarized and stored in the total resource account.
  • the creation time of the total resource account of the user may be when the server establishes the first sub-resource account for the user, as shown in FIG. 2b, specifically, the server monitoring is created for the user.
  • the first sub-resource account ie, sub-resource account 1 in Figure 2b
  • the pre-paid resource amount in the sub-resource account is counted, and the pre-paid resource amount obtained by counting is used as the current total
  • a total resource account is created for the user, and the prepaid resource corresponding to the prepaid amount of resources is stored in the total resource account.
  • the total amount of resources in the total resource account is the amount of resources included in the current sub-resource account 1, that is, the total amount of resources is 100.
  • the server while the server first creates a child resource account for the user, the server will create a total resource account for the user. Thereafter, if the user newly obtains the corresponding amount of prepaid resources, the server will create a new sub-resource account for the user, and at the same time, the amount of prepaid resources in the total resource account will also change, that is, the server will add the newly added sub-resource account.
  • the prepaid resources in the real-time statistics are added to the total resource accounts, so that a corresponding amount of prepaid resources are added to the total resource accounts.
  • the server will create a new sub-resource account for the user, that is, the sub-resource account 2 (where the sub-resource account)
  • the amount of prepaid resources stored in 2 is 50).
  • the server will accumulate the amount of prepaid resources in the newly added subresource account 2 into the total resource account. Therefore, in Figure 2c, the total in the total resource account The amount of resources was changed to 150.
  • the establishment of the total resource account can integrate all the prepaid resources obtained by the user. It can be understood that, by means of the total resource account, the server does not need to separately acquire the sub-resource accounts one by one in the process of obtaining the prepaid resources of the user.
  • the method of prepaying the resource, but the prepaid resource can be obtained directly from the total resource account. Obviously, the method of using the total resource account in the embodiment of the present application can effectively reduce the prepayment of the user by the server.
  • the time of the resource can be understood that, by means of the total resource account, the server does not need to separately acquire the sub-resource accounts one by one in the process of obtaining the prepaid resources of the user.
  • the method of prepaying the resource but the prepaid resource can be obtained directly from the total resource account.
  • the method of using the total resource account in the embodiment of the present application can effectively reduce the prepayment of the user by the server.
  • the time of the resource can be used to reduce the prepayment of the user by the server.
  • the prepaid resources provided by the service provider may have different conversion coefficients, that is, in the case of different conversion factors, an equal amount of prepaid resources can offset different amounts of resource costs, for example:
  • the conversion factor is 1, the user can offset the same amount (ie, 100) by using a prepaid resource of 100. Resource cost.
  • the server will acquire a prepaid resource of the number 100 belonging to the user.
  • the resource cost of 200 can be offset.
  • the server will acquire a prepaid resource of the number 50 belonging to the user.
  • the server when the server counts the total amount of resources in each sub-resource account, it needs to perform statistics according to the conversion coefficient of each sub-resource account, specifically, the total resource amount of pre-paid resources in each sub-resource account, specifically including For any sub-resource account, determining a conversion coefficient of the pre-resourced resource in the sub-resource account, and counting the total resource amount of the pre-paid resources in each sub-resource account according to the determined conversion coefficient of each sub-resource account.
  • the quantity of the prepaid resources in the total resource account is the sum of the prepaid resources in each sub-resource account after the conversion.
  • the server can obtain an equal amount of prepaid resources from the total resource account according to the resource consumption corresponding to the service request.
  • the amount of prepaid resources in the sub-resource account and the total pre-paid resource amount of the total resource account correspond in real time, in other words, when the amount of prepaid resources in the sub-resource account changes, the amount of pre-paid resources in the total resource account Corresponding changes will also occur. Similarly, the total amount of prepaid resources in the total resource account changes, and the server also adjusts the amount of prepaid resources in the child resource accounts. Therefore, when the server obtains a certain amount of prepaid resources from the total resource account, the same amount of prepaid resources are deducted from the subresource account.
  • the method shown in FIG. 1a and FIG. 1b further includes: respectively, according to the amount of prepaid resources acquired from the total resource account of the user, respectively, from the corresponding sub-users of the user.
  • the corresponding amount of prepaid resources is deducted from the resource account.
  • the prepaid resources there may be multiple ways to deduct the prepaid resources from each sub-resource account.
  • the user can obtain the prepaid resources multiple times, and the server will establish a sub-resource account for each pre-paid resource obtained by the user, then the sub-resource accounts of the user have a chronological order. Therefore, the prepaid resources can be deducted in turn according to the chronological order of each sub-resource account establishment.
  • the creation time of the sub-resource account 1 is earlier than the creation time of the sub-resource account 2, then, when the server is from the user After obtaining the prepaid resources with a quantity of 120 in the total resource account, it is necessary to deduct the same amount of prepaid resources from the sub-resource account 1 and the sub-resource account 2 respectively. Since the sub-resource account 1 is created at the earliest time, then according to each sub-resource account The chronological order of establishment, the server will first deduct the prepaid resources in the sub-resource account 1, as shown in Figure 3, currently, The amount of prepaid resources in sub-resource account 1 is zero.
  • the server will deduct the prepaid resources of the number 20 in the sub-resource account 2, and thus, in FIG. 3, the amount of prepaid resources currently remaining in the sub-resource account 2 Is 30.
  • different sub-resource accounts may have different conversion factors, and the pre-paid resources of each sub-resource account may be deducted in turn according to the size order of the conversion system.
  • the corresponding quantity of the prepaid resources is respectively deducted from the sub-resource accounts corresponding to the user, which specifically includes: sequentially, according to the chronological order of establishing the association relationship between the sub-resource accounts and the user, sequentially from the sub-resource accounts. Deduct the corresponding amount of prepaid resources; or
  • the priority order of each sub-resource account is determined according to the conversion coefficient of the pre-paid resources in each sub-resource account, and the corresponding quantity of pre-paid resources are sequentially deducted from each sub-resource account according to the determined priority order of each sub-resource account.
  • the prepaid resources in each sub-resource account may also be deducted one by one according to the order of the sub-resource accounts set by the user.
  • the prepaid resources may be deducted in order of effective time limit. This does not constitute a limitation on the present application.
  • the process of deducting the prepaid resource in the sub-resource account is after the service provider provides the service, that is, after the server obtains the pre-paid resource from the total resource account, the service provider The user will be provided with the corresponding service to ensure that the user can obtain the business service in time.
  • the server deducts the prepaid resource from each sub-resource account in the subsequent process. Obviously, this approach does not affect the timely access to business services.
  • the above method in the present application can be applied to a scenario of prepaid cards in practical applications.
  • the architecture in the actual application scenario is as shown in FIG. 5a.
  • the user, the merchant, and the payment service provider are included.
  • the user obtains the corresponding service through the merchant (for example, the merchant can provide the product to the user. , catering, accommodation, etc.), merchants can provide users with electronic prepaid cards (or e-vouchers, etc., for convenience of description, hereinafter referred to as: prepaid cards), it can be considered that the payment service provides online for the prepaid cards provided by the merchants.
  • Technical support for payment and, user The user's own account is registered with the payment service provider.
  • the user can use the prepaid card to purchase the corresponding item from the merchant.
  • the prepaid card here can be regarded as a prepaid resource. Different prepaid cards have different amounts and conversion factors, and the user can purchase the prepaid card multiple times.
  • the embodiment of the present application provides a resource processing method, as shown in FIG. 5b.
  • the method in FIG. 5b specifically includes the following steps:
  • S501 Receive a payment request of the user.
  • the payment request may be sent by the user using the terminal.
  • the merchant may provide the corresponding two-dimensional code to the user, and after the user scans the code by using the terminal, the payment request is sent.
  • the payment request may be sent by the merchant.
  • the merchant may send a service request to the server through its own settlement device (eg, POS machine, terminal, etc.).
  • the service request sent by the user or the service request sent by the merchant carries the identifier of the user (for example, the account registered by the payment service provider, the mobile phone number, the user ID, etc.) and the merchant identity (for example, the merchant Name, business ID, etc.).
  • S502 Determine a payment amount corresponding to the payment request.
  • the payment request carries the corresponding payment amount information, and then the server can determine the amount to be paid for the payment request by paying the amount information.
  • S503 Determine a prepaid card account of the user that is created in advance.
  • the total prepaid card account includes all prepaid card funds belonging to the user.
  • the prepaid card is provided by the merchant. Therefore, when the server creates a prepaid card account for the user (including: a prepaid card account and a total prepaid card account), it will be based on the merchant identifier and the user identifier. Create a prepaid card account.
  • the server determines the prepaid card account corresponding to the merchant according to the user identifier and the merchant identifier carried in the service request, and determines the prepaid card account belonging to the user based on the user identifier.
  • S504 Deducting the prepaid card funds of the same amount as the payment amount from the total prepaid card account to process the payment request.
  • the server After the server deducts the corresponding prepaid card funds from the user's total prepaid card account, the merchant will be notified that the deduction is successful, so that the merchant completes the settlement of the payment to the user. In addition, the server also informs the user that the debit card from the user's prepaid card funds is successfully debited and displays the corresponding debit details. Of course, this does not constitute a limitation on the present application.
  • the resource processing method in this scenario also includes the process of creating a total prepaid card account, accumulating total prepaid card funds according to prepaid card funds in the prepaid card account, and deducting prepaid card resources, that is,
  • the pre-created total prepaid card account of the user specifically includes: determining pre-established sub-prepaid card accounts of the user (wherein each sub-prepaid card account stores the user's purchase each time) Prepaid card funds), the total amount of prepaid card funds in each subpaid card account is counted, and a total prepaid card account is created for the user according to the total amount obtained by the statistics, and the prepaid card funds equal to the total amount are stored in the In the total prepaid card account.
  • the server establishes a sub prepaid card account for the user according to the user identifier and the merchant identifier, and the sub prepaid card account may indicate that the prepaid resource is provided by the merchant, and The sub-prepaid card account belongs to the user.
  • the amount of the prepaid card funds in each sub-prepaid card account is counted, specifically: determining, for any sub-prepaid card account, a conversion coefficient of the prepaid card funds in the sub-prepaid card account, according to each determined pre-payment The conversion factor of the card account, and the amount of the prepaid card funds in each sub-prepaid card account is counted.
  • the method further includes deducting a corresponding amount of prepaid card funds from each of the sub prepaid card accounts corresponding to the user according to the prepaid card funds deducted from the total prepaid card account of the user.
  • the corresponding amount of the prepaid card funds are respectively deducted from the sub-prepaid card accounts corresponding to the user, which specifically includes:
  • the embodiment of the present application further provides a resource processing apparatus.
  • the device includes:
  • the receiving module 601 receives a service request sent by a user.
  • the determining module 602 determines a resource consumption amount corresponding to the service request.
  • the total account module 603 determines a pre-created total resource account of the user; wherein the total resource account includes all prepaid resources belonging to the user.
  • the processing module 604 obtains a prepaid resource corresponding to the resource consumption amount from the total resource account, to process the service request.
  • the total account module 603 determines a pre-established sub-resource account of the user, where each sub-resource account stores a pre-reserved resource obtained by the user each time, and counts the total resource amount of the pre-paid resource in each sub-resource account.
  • a total resource account is created for the user according to the total amount of resources obtained by the statistics, and the prepaid resource corresponding to the total resource amount is stored in the total resource account.
  • the total account module 603 determines, for any sub-resource account, a conversion coefficient of the pre-resourced resource in the sub-resource account, and collects a total of the pre-paid resources in each sub-resource account according to the determined conversion coefficient of each sub-resource account. Resources.
  • the device further includes: a resource settlement module 605, respectively, deducting a corresponding amount of prepaid resources from each sub-resource account corresponding to the user according to the prepaid resource amount obtained from the total resource account of the user.
  • the resource settlement module 605 deducts a corresponding amount of prepaid resources from each sub-resource account in sequence according to the chronological order in which each sub-resource account establishes an association relationship with the user; or
  • the priority order of each sub-resource account is determined according to the conversion coefficient of the pre-paid resources in each sub-resource account, and the corresponding quantity of pre-paid resources are sequentially deducted from each sub-resource account according to the determined priority order of each sub-resource account.
  • the device shown in FIG. 6 can be applied to a scenario in which a user uses a prepaid card.
  • the embodiment of the present application provides a resource processing device, as shown in FIG. 7 :
  • the receiving module 701 receives a payment request of the user.
  • the determining module 702 determines a payment amount corresponding to the payment request.
  • the total account module 703 determines a prepaid account of the user's total prepaid card; wherein the total prepaid card account includes all prepaid card funds belonging to the user.
  • the processing module 704 deducts the prepaid card funds of the same amount as the payment amount from the total prepaid card account to process the payment request.
  • the total account module 703 determines the pre-established sub-prepaid card accounts of the user; wherein each sub-prepaid card account stores the prepaid card funds purchased by the user each time; and counts the prepaid card funds in each sub-prepaid card account. The total amount, based on the total amount obtained by the statistics, creates a total prepaid card account for the user, and stores the prepaid card funds equal to the total amount in the total prepaid card account.
  • the total account module 703 determines, for any sub-prepaid card account, a conversion coefficient of the prepaid card funds in the sub-prepaid card account, and counts each sub-prepaid card account according to the determined conversion coefficient of each sub-prepaid card account. The amount of funds in the prepaid card.
  • the device further includes: a resource settlement module 705, respectively deducting a corresponding amount of prepaid card funds from each sub-prepaid card account corresponding to the user according to the prepaid card funds deducted from the total prepaid card account of the user.
  • a resource settlement module 705 respectively deducting a corresponding amount of prepaid card funds from each sub-prepaid card account corresponding to the user according to the prepaid card funds deducted from the total prepaid card account of the user.
  • embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention 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.) including computer usable program code.
  • computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • the computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device.
  • the apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device.
  • the instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • the memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory.
  • RAM random access memory
  • ROM read only memory
  • Memory is an example of a computer readable medium.
  • Computer readable media includes both permanent and non-persistent, removable and non-removable media.
  • Information storage can be implemented by any method or technology.
  • the 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 technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device.
  • computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.
  • embodiments of the present application can be provided as a method, system, or computer program product.
  • the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware.
  • the 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.) including computer usable program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Game Theory and Decision Science (AREA)
  • Educational Administration (AREA)
  • Operations Research (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Finance (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请公开了一种资源处理方法及装置。该方法包括：接收用户发出的业务请求，确定所述业务请求所对应的资源消耗量，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。从而，服务器无需逐一地从每个子资源账户中分别获取预付资源，而是可以直接从总资源账户中一并获取到相应数量的预付资源。有效减少服务器获取预付资源的时长，进而提升了对业务的处理效率。

Description

一种资源处理方法及装置
本申请要求2016年06月22日递交的申请号为201610461033.5、发明名称为“一种资源处理方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及一种资源处理方法及装置。
背景技术
用户在使用业务提供方(如：网站)所提供的业务时，通常将消耗业务提供方一定数量的资源。对于用户而言，为了能够正常的使用该业务，通常会向业务提供方反馈相应数量的资源代价。
目前，在实际应用中，业务提供方面向用户提供一种线上的预付资源(如：电子券、电子预付卡等，以下简称为：预付资源)，该预付资源可以在用户使用业务提供方的业务时，抵消相应数量的资源代价。
现有技术中，用户可以逐次从业务提供方处获取预付资源，那么，当用户使用了业务提供方所提供的业务时，用户就可以使用已获取的预付资源。具体地，业务提供方后台的服务器(以下简称为：服务器)将针对用户每次获取的预付资源创建资源账户(也即，每个资源账户对应于用户每次所获取的预付资源)，并建立各资源账户与该用户之间的关联。当用户需要使用预付资源时，服务器会确定与该用户具有关联的各资源账户，并依次从各资源账户中扣除相应数量的预付资源，直到所扣除的预付资源的总量与业务所需的资源总量一致为止。
例如：某用户购买业务提供方所提供的多张电子预付卡，相应地，服务器会分别针对每一张电子预付卡在后台建立预付账户，并关联该用户，那么，当该用户就要进行支付时，只需向该业务提供方提供该用户自身的用户信息(如：用户名)，服务器就会根据该用户信息确定出该用户的多个预付账户，并逐一地从该预付账户中扣除相应的额度以便完成支付。
但是，在上述方式中，服务器需要逐一从各资源账户中扣除相应数量的预付资源，这一过程需要耗费一定的时长，尤其在大量用户均使用自身的预付资源的情况下，将增加服务器的处理负荷，使得扣除预付资源过程所需的时间延长，降低了用户正常获得业务的效率。
发明内容
本申请实施例提供一种资源处理方法，用以解决现有技术中业务提供方的服务器扣除用户的预付资源的效率降低的问题。
本申请实施例提供一种资源处理装置，用以解决现有技术中业务提供方的服务器扣除用户的预付资源的效率降低的问题。
本申请实施例采用下述技术方案：
本申请实施例提供的一种资源处理方法，包括：
接收用户发出的业务请求；
确定所述业务请求所对应的资源消耗量；
确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；
从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
本申请实施例另提供的一种资源处理方法，包括：
接收用户的支付请求；
确定所述支付请求所对应的支付金额；
确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；
从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
本申请实施例提供的一种资源处理装置，包括：
接收模块，接收用户发出的业务请求；
确定模块，确定所述业务请求所对应的资源消耗量；
总账户模块，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；
处理模块，从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
本申请实施例另提供的一种资源处理装置，包括：
接收模块，接收用户发出的支付请求；
确定模块，确定所述支付请求所对应的支付金额；
总账户模块，确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；
处理模块，从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：
业务提供方的服务器会针对为用户所建立的各子资源账户中的预付资源进行统计，并为用户建立总资源账户，将统计得到的总预付资源量存储在总资源账户中。这样一来，当服务器获取用户的预付资源时，就无需逐一地从每个子资源账户中分别获取预付资源，而是可以直接从总资源账户中一并获取到相应数量的预付资源。显然，这样的方式能够有效减少服务器获取预付资源的时长，进而提升了对业务的处理效率。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1a为本申请实施例提供的资源处理架构示意图；
图1b为本申请实施例提供的资源处理过程示意图；
图2a为本申请实施例提供的创建资源账户的示意图一；
图2b为本申请实施例提供的创建资源账户的示意图二；
图2c为本申请实施例提供的创建资源账户的示意图三；
图3为本申请实施例提供的在使用预付资源后资源账户的示意图；
图4a为本申请实施例提供的在具有折算系数的情况下预付资源的示意图一；
图4b为本申请实施例提供的在具有折算系数的情况下预付资源的示意图二；
图5a为本申请实施例提供的在商户场景下的资源处理架构示意图；
图5b为基于如图5a所示架构下的资源处理流程示意图；
图6为本申请实施例提供的资源处理装置结构示意图；
图7为本申请实施例提供的在商户场景下的资源处理装置结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相 应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
如前所述，在用户使用预付资源的过程中，服务器通常会逐一地从该用户对应的预付账户中获取相应的预付资源，而该过程将耗费一定的时长，导致业务提供方为用户提供业务的效率较低。
基于此，就需要一种在用户使用预付资源的过程中，可以快速、便捷地获取预付账户内的预付资源的方法。故在本申请实施例中，提供一种资源处理方法，以实现服务器可以快速获取用户的预付资源，提升为用户提供业务的效率。
需要说明的是，本申请实施例中所述的业务提供方可以是能够提供在线业务的业务提供方，诸如：网站、电信运营商等；也可以是能够提供线下业务的业务提供方(该场景下，业务提供方所提供的预付资源仍是线上预付资源)，诸如：商店、餐馆等。基于此，业务提供方的服务器就可以是诸如：网站服务器、电信运营商服务器，或用于处理线上预付资源的服务器等，这里并不构成对本申请的限定。
以下结合附图，详细说明本申请各实施例提供的技术方案。
如图1a所示，示出了本申请实施中的资源处理的架构示意图。基于如图1a所示的架构，本申请实施例中的资源处理方法如图1b所示，具体包括以下步骤：
S101：接收用户发出的业务请求。
在实际应用场景下，用户可以使用由业务提供方所提供的业务服务，此时，用户可以发出相应的业务请求，如：用户使用云计算业务时，发出云计算请求；或者，用户使用网络存储业务，发出存储请求等等。相应地，业务提供方的服务器将接收到由用户发送的业务请求。
当然，作为本申请实施例中的可选方式，用户可以使用终端(可包括：手机、平板电脑、计算机等)，以扫码、在相应页面中点击业务控件等方式，向业务提供方发出业务请求。这里并不构成对本申请的限定。
S102：确定所述业务请求所对应的资源消耗量。
如前所述，业务提供方在处理用户的业务请求时，通常会消耗一定量的资源，如：业务提供方为用户提供云计算业务的过程中，将消耗相应的处理资源；在提供网络存储业务的过程中，将消耗数据库内的存储空间。那么，用户就需要向业务提供方支付相应的资源代价。
故当服务器接收到用户的业务请求后，将首先确定处理该业务请求所需的资源的数量(即，业务消耗量)，以便在后续过程中确定出用户所要支付的资源代价。
S103：确定预先创建的该用户的总资源账户。
其中，所述总资源账户中包含属于该用户的全部预付资源。
在本申请实施例中，用户的总资源账户，是基于该用户的各资源账户(为了区别于总资源账户，将针对用户历次获取预付资源而分别建立的资源账户，称为：子资源账户)所预先建立的，可以认为，总资源账户中所存储的预付资源，是用户各子资源账户内预付资源的总和，也即，总资源账户内包含了属于该用户的预付资源总量。
例如：假设某用户拥有子资源账户A和B，其中，子资源账户A中的预付资源量为100，子资源账户B中包含的预付资源量为200，那么，该用户的总资源账户中所包含的预付资源总量就为300。
需要说明的是，本申请实施例中的总资源账户是由服务器为用户创建的。作为本申请实施例中的一种方式，服务器中存储有用户的标识(如：userID、该用户在服务器中注册的业务账号等)，那么，服务器便可以基于用户的标识，为用户创建总资源账户。例如：某用户在服务器中注册有名为“xiaoming”的业务账户，那么，服务器可基于该业务账户的账户名，为该用户创建总资源账户“xiaoming-general source account”，在创建了总资源账户之后，服务器会将该用户的所有预付资源汇总并存储在该总资源账户中。
当然，上述示例仅是针对总资源账户创建的一种可行方式的说明，并不构成对本申请的限定。
与现有技术不同的是，本申请实施例中，总资源账户将属于某用户的所有预付资源汇总，所以，后续扣除预付资源的过程便无需逐一地从子资源账户中获取。
S104：从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
当确定出了业务请求所要消耗的资源量、以及用户总资源账户中所包含的预付资源总量后，便可以从用户的总资源账户中扣除相应数量的资源。
这里需要说明的是，在实际应用场景下，可能出现不同的情况：
一种情况是业务请求所消耗的资源量不大于总资源账户中包含的预付资源总量，那么，服务器便可从总资源账户中扣除业务请求所要消耗的资源量。例如：假设业务请求所消耗的资源量为80，用户的总资源账户中预付资源总量为100，那么，可在总资源账户中扣除80的预付资源量，之后，总资源账户中剩余的预付资源量为20。
另一种情况是业务请求所消耗的资源量大于总资源账户中包含的预付资源总量，那么，服务器可向终端反馈失败通知，以告知用户其拥有的预付资源不足抵扣业务请求的资源消耗量；或者，服务器可将总资源账户内的所有预付资源均扣除，对于不足抵扣的部分，向终端反馈差额补足通知，用户可采用其他方式支付剩余的资源量。例如：假设业务请求所消耗的资源量为200，用户的总资源账户中预付资源总量为100，此时，可将用户的总资源账户内的全部预付资源总量扣除，但业务请求所消耗的资源量还余留100，故用户可选择诸如直接支付资源的方式，以补足余留的资源消耗量。这里并不构成对本申请的限定。
通过上述步骤，业务提供方的服务器预先创建了用户的总资源账户，其中，总资源账户将属于用户的所有预付资源进行汇总，所以，当服务器接收到用户的业务请求后，确定出业务请求所要消耗的资源量，从而可直接在总资源账户中获取相应数量的预付资源，用于抵消业务请求所要消耗的资源，显然，相较于现有技术中逐一从用户的各子资源账户扣除预付资源的方式，本申请实施例中的上述方式能够直接从用户的总资源账户内获取到相应数量的预付资源，有效提升了在获取预付资源过程中的效率，并且，避免了服务器逐一地在用户的多个子资源账户内计算预付资源量的过程，能够减少服务器的工作负荷。
需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，具体而言，执行主体可以是业务提供方的服务器。
下面将对总资源账户的建立过程进行详细说明：
如图2a所示，示出了本申请实施例中服务器创建总资源账户的示意图，结合图2a而言，预先创建该用户的总资源账户，具体包括：确定预先建立的、所述用户的各子资源账户，统计各子资源账户中预付资源的总资源量，根据统计得到的总资源量，为所述用户创建总资源账户，并将所述总资源量对应的预付资源存储在所述总资源账户中。
其中，每个子资源账户中分别存储用户每次所获得的预付资源；
当用户从业务提供方处获得了预付资源后(如：用户购买电子预付卡、电子券)，服务器均会为用户建立相应的账户，用于存储所获得的预付资源。在实际应用中，用户在从业务提供方处获得预付资源的过程中，用户会使用自身的用户标识(如前述的userID、业务账户等)，那么，用户每次获得预付资源时，服务器都可获取到该用户的用户标识，从而，分别建立属于该用户的子资源账户。由于建立子资源账户的过程属于 现有技术，故在本申请实施例中不再过多赘述。
属于用户的每个子资源账户中分别存储有该用户各次所获得的预付资源，那么，针对每个子资源账户进行统计，便可以确定出属于该用户的、总共的预付资源的数量。在此基础上，为用户创建总资源账户，并将属于该用户的全部预付资源汇总后存储在总资源账户中。
作为本申请实施例中的一种方式，用户的总资源账户的创建时机，可以是服务器为该用户建立首个子资源账户时，如图2b所示，具体而言，服务器监测为所述用户创建的首个子资源账户(即，图2b中的子资源账户1)，当监测到该子资源账户建立时，统计该子资源账户中的预付资源量，将统计得到的预付资源量作为当前的总资源量，为所述用户创建总资源账户，并将所述预付资源量对应的预付资源存储在所述总资源账户中。从图2b中可见，总资源账户中的总资源量，就是当前子资源账户1中所包含的资源量，即，总资源量为100。
也就是说，在服务器第一次为用户建立子资源账户的同时，服务器将为用户创建总资源账户。此后，如果用户新获得了相应数量的预付资源，服务器将为用户建立新的子资源账户，同时，总资源账户中的预付资源量也将发生变化，即，服务器会将新增的子资源账户中的预付资源实时统计至总资源账户中，使得总资源账户中增加相应数量的预付资源。
例如：如图2c所示，用户新获得了预付资源(假设预付资源的数量为50)，那么，服务器将为用户建立新的子资源账户，也即，子资源账户2(其中，子资源账户2内存储的预付资源量就为50)，此时，服务器会将新增的子资源账户2中的预付资源量累计至总资源账户中，所以，在图2c中，总资源账户中的总资源量变更为150。
总资源账户的建立可以将用户所获得的所有预付资源进行整合，可以理解，通过总资源账户的方式，使得服务器在获取用户的预付资源的过程中，无需再采用逐一从各子资源账户分别获取预付资源的方式，而是可以直接从总资源账户中获取预付资源，显然，相较于现有技术中的方式而言，本申请实施例中采用总资源账户的方式能够有效缩减服务器获取用户预付资源的时间。
在实际应用中，业务提供方所提供的预付资源可能具有不同的折算系数，也就是说，在不同的折算系数的情况下，等量的预付资源能够抵消不同数量的资源代价，具体例如：在折算系数为1时，用户使用数量为100的预付资源，就能够抵消同样数量(即，100) 的资源代价。换言之，如果折算系数为1，且假设用户发出的业务请求的资源消耗量为100时，那么，服务器将获取属于该用户的、数量为100的预付资源。
而如果在折算系数为2时，用户使用数量为100的预付资源，就能够抵消数量为200的资源代价。换言之，如果折算系数为2，且假设用户发出的业务请求的资源消耗量为100时，服务器将获取属于该用户的、数量为50的预付资源。
基于此，当服务器在统计各子资源账户中的总资源量时，就需要根据各子资源账户的折算系数进行统计，具体而言，统计各子资源账户中预付资源的总资源量，具体包括：针对任一子资源账户，确定该子资源账户中预付资源的折算系数，根据确定出的每一子资源账户的折算系数，统计各子资源账户中预付资源的总资源量。
故在本申请实施例中，总资源账户中的预付资源的数量，就是经过折算后的各子资源账户中预付资源量的总和。
那么，当用户发出了业务请求后，服务器便可以根据该业务请求所对应的资源消耗量，从总资源账户中获取等量的预付资源。
需要说明的是，子资源账户中的预付资源量和总资源账户的总预付资源量是实时对应的，换言之，当子资源账户中的预付资源量发生变化时，总资源账户中的预付资源量也会发生相应的变化，同样地，总资源账户中的总预付资源量发生了变化，服务器也会调整子资源账户中的预付资源量。所以，当服务器从总资源账户中获取了一定数量的预付资源后，就会从子资源账户中扣除等量的预付资源。
具体而言，在本申请实施例中，上述如图1a和图1b所示的方法还包括：根据从所述用户的总资源账户中获取的预付资源量，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源。
在本申请实施例中，从各子资源账户中扣除预付资源的方式可以有多种方式。如：考虑到实际应用中，用户可以先后多次获得预付资源，而服务器会对每次用户所获得的预付资源建立子资源账户，那么，用户的各子资源账户就具有了时间上的先后顺序，从而可以根据各子资源账户建立的时间先后顺序，依次扣除预付资源。
基于上述图2c所示的内容为例：基于前述内容可知，在图2c所示的情况下，子资源账户1的创建时间早于子资源账户2的创建时间，那么，假设当服务器从用户的总资源账户中获得数量为120的预付资源后，就需要分别从子资源账户1和子资源账户2中扣除等量的预付资源，由于子资源账户1的创建时间最早，那么，根据各子资源账户建立的时间先后顺序，服务器将首先扣除子资源账户1中的预付资源，如图3所示，当前， 子资源账户1中的预付资源量为0。但此时仍需要继续扣除数量为20的预付资源，所以，服务器将在子资源账户2中扣除数量为20的预付资源，从而，在图3中，子资源账户2中当前剩余的预付资源量为30。
又如：不同的子资源账户可能具有不同的折算系数，就可以按照折算***的大小顺序，依次扣除各子资源账户的预付资源。
具体地，如图4a所示，假设子资源账户1中的预付资源量为100、且折算系数为2；子资源账户2中的预付资源量为30、且折算系数为1。那么，总资源账户中的总资源量就为100*2+30＝230。假设如图4b所示，用户所要使用的业务需要消耗的资源量为100，那么，服务器将直接从总资源账户内获取100的资源量(当前，总资源账户中的总资源量剩余130)，之后，服务器根据折算系数大小的优先级，从子资源账户1中扣除的预付资源量为50。
因此，上述内容中，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源，具体包括：按照各子资源账户与该用户建立关联关系的时间先后顺序，依次从各子资源账户中扣除相应数量的预付资源；或
根据各子资源账户中预付资源的折算系数，确定各子资源账户的优先级顺序，按照确定出的各子资源账户的优先级顺序，依次从各子资源账户中扣除相应数量的预付资源。
当然，在实际应用中，也可以按照用户所设定的子资源账户的顺序，逐一地扣除各子资源账户中的预付资源。又或者，在某些子资源账户具有有效时限的情况下，可按照有效时限的顺序扣除预付资源。这里并不构成对本申请的限定。
需要说明的是，在本申请实施例中，上述扣除子资源账户中预付资源的过程，是在业务提供方提供业务之后，也即，服务器从总资源账户中获取到预付资源后，业务提供方就会为用户提供相应的业务，保证了用户可以及时的获得业务服务，在此前提下，服务器在后续过程中再从各子资源账户中扣除预付资源。显然，这样的方式并不会影响用户及时获得业务服务。
本申请中的上述方法可以适用于实际应用中预付卡的场景。其中，实际应用场景中的架构如图5a所示，在该实际场景下，包含用户、商户以及支付业务提供方，具体而言，用户通过商户获得相应的业务(如：商户可向用户提供商品、餐饮、住宿等业务)，商户可向用户提供电子预付卡(或电子券等，为了便于描述，下文中简称为：预付卡)，可以认为，支付业务提供为商户所提供的预付卡提供在线支付的技术支持，并且，用户 在支付业务提供方注册有该用户自身的账户。实际应用时，用户可以使用预付卡从商户处购买相应的商品。这里的预付卡可看作是一种预付资源，不同的预付卡具有不同的金额及折算系数，用户可以多次购买预付卡。在这样的场景下，本申请实施例提供一种资源处理方法，如图5b所示。
具体地，图5b中的方法具体包括如下步骤：
S501：接收用户的支付请求。
用户在获得商户提供的诸如：商品、餐饮、住宿等业务后，用户需要支付相应的金额。在本申请实施例中的一种方式下，支付请求可由用户使用自身的终端发出，具体而言，商户可向用户提供相应的二维码，用户使用终端进行扫码后，发出支付请求。在本申请实施例中的另一种方式下，支付请求可由商户发出，具体而言，商户可通过自身的结算设备(如：POS机、终端等)，向服务器发出业务请求。
当然，无论是用户发出的业务请求还是商户发出的业务请求，均会携带有用户的标识(如：用户在支付业务提供方所注册的账户、手机号、userID等)以及商户标识(如：商户名、商户ID等)。
S502：确定所述支付请求所对应的支付金额。
支付请求中会携带相应的支付金额信息，那么，服务器通过支付金额信息，便可以确定出此次支付请求所要支付的金额。
S503：确定预先创建的该用户的总预付卡账户。
其中，所述总预付卡账户中包含属于该用户的全部预付卡资金。
这里需要说明的是，在本实际应用场景下，预付卡由商户提供，所以，服务器为用户创建预付卡账户(包括：子预付卡账户及总预付卡账户)时，将基于商户标识及用户标识创建预付卡账户。
换言之，服务器将根据业务请求中所携带的用户标识和商户标识，确定出与该商户所对应的预付卡账户，并基于用户标识，确定出属于该用户的预付卡账户。
S504：从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
服务器从用户的总预付卡账户中扣除了相应的预付卡资金后，会通知商户，扣款成功，从而使得商户完成对用户的款项结账。并且，服务器也会通知用户：从该用户的预付卡资金中扣款成功，并展示相应的扣款明细。当然，这里并不构成对本申请的限定。
当然，本场景下的资源处理方法中，也包含创建总预付卡账户、根据子预付卡账户中预付卡资金的累计总预付卡资金、扣除预付卡资源的过程，也即：
在该场景下，预先创建的该用户的总预付卡账户，具体包括：确定预先建立的、所述用户的各子预付卡账户(其中，每个子预付卡账户中分别存储用户每次所购买的预付卡资金)，统计各子预付卡账户中预付卡资金的总金额，根据统计得到的总金额，为所述用户创建总预付卡账户，将与所述总金额等额的预付卡资金存储在所述总预付卡账户中。
正如前述，当用户购买了商户的预付卡后，服务器会根据用户标识和该商户标识，为该用户建立子预付卡账户，该子预付卡账户可以表明：预付资源是该商户所提供的、且该子预付卡账户属于该用户。
该过程中，统计各子预付卡账户中预付卡资金的金额，具体包括：针对任一子预付卡账户，确定该子预付卡账户中预付卡资金的折算系数，根据确定出的每一子预付卡账户的折算系数，统计各子预付卡账户中预付卡资金的金额。
扣除预付卡资金的过程：
所述方法还包括：根据从所述用户的总预付卡账户中扣除的预付卡资金，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金。
进一步地，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金，具体包括：
按照各子预付卡账户与该用户建立关联关系的时间先后顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金；或
根据各子预付卡账户中预付资源的折算系数，确定各子预付卡账户的优先级顺序，并按照确定出的各子预付卡账户的优先级顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金。
上述内容与前述如图1b所示的方法中所记载的内容相类似，这里并不在过多赘述。
以上为本申请实施例提供的资源处理方法，基于同样的思路，本申请实施例还提供一种资源处理装置。
如图6所示，该装置包括：
接收模块601，接收用户发出的业务请求。
确定模块602，确定所述业务请求所对应的资源消耗量。
总账户模块603，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源。
处理模块604，从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
总账户模块603，确定预先建立的、所述用户的各子资源账户；其中，每个子资源账户中分别存储用户每次所获得的预付资源，统计各子资源账户中预付资源的总资源量，根据统计得到的总资源量，为所述用户创建总资源账户，并将所述总资源量对应的预付资源存储在所述总资源账户中。
进一步地，总账户模块603，针对任一子资源账户，确定该子资源账户中预付资源的折算系数，根据确定出的每一子资源账户的折算系数，统计各子资源账户中预付资源的总资源量。
所述装置还包括：资源结算模块605，根据从所述用户的总资源账户中获取的预付资源量，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源。
所述资源结算模块605，按照各子资源账户与该用户建立关联关系的时间先后顺序，依次从各子资源账户中扣除相应数量的预付资源；或
根据各子资源账户中预付资源的折算系数，确定各子资源账户的优先级顺序，按照确定出的各子资源账户的优先级顺序，依次从各子资源账户中扣除相应数量的预付资源。
基于上述如图6所示的装置，可以应用于用户使用预付卡的场景中，具体而言，在该场景中本申请实施例提供一种资源处理装置，如图7所示：
接收模块701，接收用户的支付请求。
确定模块702，确定所述支付请求所对应的支付金额。
总账户模块703，确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金。
处理模块704，从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
总账户模块703，确定预先建立的、所述用户的各子预付卡账户；其中，每个子预付卡账户中分别存储用户每次所购买的预付卡资金；统计各子预付卡账户中预付卡资金的总金额，根据统计得到的总金额，为所述用户创建总预付卡账户，将与所述总金额等额的预付卡资金存储在所述总预付卡账户中。
进一步地，总账户模块703，针对任一子预付卡账户，确定该子预付卡账户中预付卡资金的折算系数，根据确定出的每一子预付卡账户的折算系数，统计各子预付卡账户中预付卡资金的金额。
所述装置还包括：资源结算模块705，根据从所述用户的总预付卡账户中扣除的预付卡资金，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金。
本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

  1. 一种资源处理方法，其特征在于，包括：
    接收用户发出的业务请求；
    确定所述业务请求所对应的资源消耗量；
    确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；
    从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
  2. 如权利要求1所述的方法，其特征在于，预先创建该用户的总资源账户，具体包括：
    确定预先建立的、所述用户的各子资源账户；其中，每个子资源账户中分别存储用户每次所获得的预付资源；
    统计各子资源账户中预付资源的总资源量；
    根据统计得到的总资源量，为所述用户创建总资源账户，并将所述总资源量对应的预付资源存储在所述总资源账户中。
  3. 如权利要求2所述的方法，其特征在于，统计各子资源账户中预付资源的总资源量，具体包括：
    针对任一子资源账户，确定该子资源账户中预付资源的折算系数；
    根据确定出的每一子资源账户的折算系数，统计各子资源账户中预付资源的总资源量。
  4. 如权利要求1所述的方法，其特征在于，所述方法还包括：
    根据从所述用户的总资源账户中获取的预付资源量，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源。
  5. 如权利要求4所述的方法，其特征在于，分别从该用户所对应的各子资源账户中扣除相应数量的预付资源，具体包括：
    按照各子资源账户与该用户建立关联关系的时间先后顺序，依次从各子资源账户中扣除相应数量的预付资源；或
    根据各子资源账户中预付资源的折算系数，确定各子资源账户的优先级顺序，并按照确定出的各子资源账户的优先级顺序，依次从各子资源账户中扣除相应数量的预付资源。
  6. 一种资源处理方法，其特征在于，包括：
    接收用户的支付请求；
    确定所述支付请求所对应的支付金额；
    确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；
    从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
  7. 如权利要求6所述的方法，其特征在于，预先创建的该用户的总预付卡账户，具体包括：
    确定预先建立的、所述用户的各子预付卡账户；其中，每个子预付卡账户中分别存储用户每次所购买的预付卡资金；
    统计各子预付卡账户中预付卡资金的总金额；
    根据统计得到的总金额，为所述用户创建总预付卡账户，将与所述总金额等额的预付卡资金存储在所述总预付卡账户中。
  8. 如权利要求7所述的方法，其特征在于，统计各子预付卡账户中预付卡资金的金额，具体包括：
    针对任一子预付卡账户，确定该子预付卡账户中预付卡资金的折算系数；
    根据确定出的每一子预付卡账户的折算系数，统计各子预付卡账户中预付卡资金的金额。
  9. 如权利要求6所述的方法，其特征在于，所述方法还包括：
    根据从所述用户的总预付卡账户中扣除的预付卡资金，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金。
  10. 如权利要求9所述的方法，其特征在于，分别从该用户所对应的各子预付卡账户中扣除相应数量的预付卡资金，具体包括：
    按照各子预付卡账户与该用户建立关联关系的时间先后顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金；或
    根据各子预付卡账户中预付资源的折算系数，确定各子预付卡账户的优先级顺序，并按照确定出的各子预付卡账户的优先级顺序，依次从各子预付卡账户中扣除相应数量的预付卡资金。
  11. 一种资源处理装置，其特征在于，包括：
    接收模块，接收用户发出的业务请求；
    确定模块，确定所述业务请求所对应的资源消耗量；
    总账户模块，确定预先创建的该用户的总资源账户；其中，所述总资源账户中包含属于该用户的全部预付资源；
    处理模块，从该总资源账户中获取与所述资源消耗量对应的预付资源，以对所述业务请求进行处理。
  12. 一种资源处理装置，其特征在于，包括：
    接收模块，接收用户的支付请求；
    确定模块，确定所述支付请求所对应的支付金额；
    总账户模块，确定预先创建的该用户的总预付卡账户；其中，所述总预付卡账户中包含属于该用户的全部预付卡资金；
    处理模块，从该总预付卡账户中扣除与支付金额相同数额的预付卡资金，以对所述支付请求进行处理。
PCT/CN2017/087657 2016-06-22 2017-06-09 一种资源处理方法及装置 WO2017219874A1 (zh)

Priority Applications (13)

Application Number Priority Date Filing Date Title
JP2018567695A JP6761056B2 (ja) 2016-06-22 2017-06-09 リソース処理方法及び装置
EP17814612.2A EP3477562A1 (en) 2016-06-22 2017-06-09 Resource processing method and apparatus
CA3029082A CA3029082A1 (en) 2016-06-22 2017-06-09 Resource processing method and apparatus
BR112018076877A BR112018076877A8 (pt) 2016-06-22 2017-06-09 Método para processamento de recursos e aparelho para processar um recurso
AU2017280384A AU2017280384B2 (en) 2016-06-22 2017-06-09 Resource processing method and apparatus
KR1020197002131A KR102192876B1 (ko) 2016-06-22 2017-06-09 리소스 프로세싱 방법 및 장치
MX2019000126A MX2019000126A (es) 2016-06-22 2017-06-09 Metodo y aparato para procesamiento de recursos.
MYPI2018002867A MY193309A (en) 2016-06-22 2017-06-09 Resource processing method and apparatus
SG11201811436YA SG11201811436YA (en) 2016-06-22 2017-06-09 Resource processing method and apparatus
RU2019101250A RU2718155C1 (ru) 2016-06-22 2017-06-09 Способ и устройство обработки ресурсов
US16/227,813 US10805410B2 (en) 2016-06-22 2018-12-20 Resource processing method and apparatus
PH12018502743A PH12018502743A1 (en) 2016-06-22 2018-12-21 Resource processing method and apparatus
US16/722,495 US10827016B2 (en) 2016-06-22 2019-12-20 Resource processing method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610461033.5 2016-06-22
CN201610461033.5A CN106886847A (zh) 2016-06-22 2016-06-22 一种资源处理方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/227,813 Continuation US10805410B2 (en) 2016-06-22 2018-12-20 Resource processing method and apparatus

Publications (1)

Publication Number Publication Date
WO2017219874A1 true WO2017219874A1 (zh) 2017-12-28

Family

ID=59176058

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/087657 WO2017219874A1 (zh) 2016-06-22 2017-06-09 一种资源处理方法及装置

Country Status (15)

Country Link
US (2) US10805410B2 (zh)
EP (1) EP3477562A1 (zh)
JP (1) JP6761056B2 (zh)
KR (1) KR102192876B1 (zh)
CN (1) CN106886847A (zh)
AU (1) AU2017280384B2 (zh)
BR (1) BR112018076877A8 (zh)
CA (1) CA3029082A1 (zh)
MX (1) MX2019000126A (zh)
MY (1) MY193309A (zh)
PH (1) PH12018502743A1 (zh)
RU (1) RU2718155C1 (zh)
SG (1) SG11201811436YA (zh)
TW (1) TW201800994A (zh)
WO (1) WO2017219874A1 (zh)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106886847A (zh) 2016-06-22 2017-06-23 阿里巴巴集团控股有限公司 一种资源处理方法及装置
KR20180077431A (ko) * 2016-12-29 2018-07-09 주식회사 인코어드 테크놀로지스 전력수요 관리 기능을 갖는 서버, 가전기기, 및 그것의 전력 사용 관리 방법
JP6978897B2 (ja) * 2017-11-01 2021-12-08 シャープ株式会社 マルチメディア端末、情報処理システム、制御プログラムおよび制御方法
CN109146600A (zh) * 2018-06-12 2019-01-04 阿里巴巴集团控股有限公司 业务处理方法及装置、电子设备
CN110264332A (zh) * 2019-05-06 2019-09-20 阿里巴巴集团控股有限公司 账户出账的方法、装置和电子设备
CN110288478A (zh) * 2019-06-27 2019-09-27 网联清算有限公司 针对支付机构的交易数据处理方法及其设备
KR102121734B1 (ko) * 2019-11-18 2020-06-12 이민우 스마트 팜 통합관리 플랫폼 시스템 및 이의 운영방법
US10873578B1 (en) 2019-12-09 2020-12-22 Evan Chase Rose Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network
US11113665B1 (en) 2020-03-12 2021-09-07 Evan Chase Rose Distributed terminals network management, systems, interfaces and workflows
US11200548B2 (en) 2019-12-09 2021-12-14 Evan Chase Rose Graphical user interface and operator console management system for distributed terminal network
US10902705B1 (en) 2019-12-09 2021-01-26 Evan Chase Rose Biometric authentication, decentralized learning framework, and adaptive security protocols in distributed terminal network
CN113643034B (zh) * 2020-04-27 2024-05-31 北京金山云网络技术有限公司 可提现金额确定方法、装置、电子设备及可读存储介质
CN112836971A (zh) * 2021-02-04 2021-05-25 北京明略昭辉科技有限公司 配额资源的确定方法和装置、电子设备和存储介质
CN113037512A (zh) * 2021-03-02 2021-06-25 北京金山云网络技术有限公司 网络资源消耗的统计方法、装置和服务器
CN113505981B (zh) * 2021-07-07 2024-01-16 苏州达家迎信息技术有限公司 扁平式业务场景中业务资源确定方法、装置及存储介质
US11843546B1 (en) * 2023-01-17 2023-12-12 Capital One Services, Llc Determining resource usage metrics for cloud computing systems

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070282739A1 (en) * 2006-05-30 2007-12-06 Jacob Thomsen Computer implemented method and system for rapid verification and administration of fund transfers and a computer program for performing said method
CN103312662A (zh) * 2012-03-07 2013-09-18 阿里巴巴集团控股有限公司 一种数据传输、处理方法和装置
CN103714452A (zh) * 2012-10-09 2014-04-09 上海博路信息技术有限公司 一种终端支付方法

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050195743A1 (en) * 2000-04-03 2005-09-08 P-Cube Ltd. Real time charging of pre-paid accounts
JP2002345030A (ja) * 2001-05-14 2002-11-29 Fujitsu Ltd ウェブサイトアクセスサービス提供システム
JP2004133693A (ja) * 2002-10-10 2004-04-30 Casio Comput Co Ltd プリペイド型電子マネー決済システム、方法、及びプログラム
US20040088249A1 (en) * 2002-10-31 2004-05-06 Bartter William Dale Network-based electronic commerce system incorporating prepaid service offerings
US8498391B2 (en) * 2002-12-02 2013-07-30 Apple Inc. Methods, systems and program products for supporting prepaid service within a communication network
JP2004341793A (ja) * 2003-05-15 2004-12-02 Nifty Corp プリペイド決済方式に関連する情報処理方法及びプログラム並びにシステム
US20070023504A1 (en) * 2005-05-19 2007-02-01 F.S.V. Payment Systems, Inc. Computer implemented flexible benefit plan host based stored value card product
US7991764B2 (en) * 2005-07-22 2011-08-02 Yogesh Chunilal Rathod Method and system for communication, publishing, searching, sharing and dynamically providing a journal feed
US20070267479A1 (en) * 2006-05-16 2007-11-22 Chockstone, Inc. Systems and methods for implementing parking transactions and other financial transactions
CN101231722B (zh) * 2007-01-22 2014-09-17 阿里巴巴集团控股有限公司 一种网络支付方法及***
US20080319910A1 (en) 2007-06-21 2008-12-25 Microsoft Corporation Metered Pay-As-You-Go Computing Experience
JP2012515380A (ja) 2009-01-12 2012-07-05 ベター エーティーエム サービシズ，インク． 口座連結を管理するシステムおよび方法
US20100241535A1 (en) 2009-03-19 2010-09-23 Brad Nightengale Account activity alert
JP5221451B2 (ja) * 2009-06-01 2013-06-26 株式会社エヌ・ティ・ティ・データ サービス提供装置およびサービス提供方法
CN101616392B (zh) 2009-06-26 2012-04-18 中兴通讯股份有限公司 一种增值业务提供***和方法
AU2010249214C1 (en) 2009-12-15 2014-08-21 Zonamovil, Inc. Methods, apparatus, and systems for supporting purchases of goods and services via prepaid telecommunication accounts
US20120047041A1 (en) * 2010-03-26 2012-02-23 Abdul Akel Prepaid Network Time Purchasing System
CN102779304A (zh) * 2011-05-10 2012-11-14 中国联合网络通信集团有限公司 电子钱包中赠予金额的处理方法及服务器
JP5925293B2 (ja) * 2011-06-14 2016-05-25 エンパイア テクノロジー ディベロップメント エルエルシー クラウドコンピューティング環境のためのピーク性能を意識した課金
JP2013015986A (ja) * 2011-07-04 2013-01-24 Nec Corp プリペイド課金システム、方法及びプログラム
JP5976559B2 (ja) 2013-01-30 2016-08-23 株式会社ノリタケカンパニーリミテド ナノ微粒子状のチタン酸バリウムとその製造方法
US20140279320A1 (en) * 2013-03-15 2014-09-18 Bracket Computing, Inc. Allocating and pricing virtual resources
JP2014235610A (ja) * 2013-06-03 2014-12-15 日本電信電話株式会社 可変容量ストレージデスクトップ仮想化サービス装置及び方法及びプログラム
CN104574527A (zh) * 2013-10-28 2015-04-29 北京车信源商务服务有限公司 基于车辆身份电子标识的消费支付方法
CN104021628B (zh) * 2014-06-23 2017-04-05 中国民生银行股份有限公司 数据处理方法和装置
US20170004525A1 (en) * 2015-06-30 2017-01-05 Linkedln Corporation Online ad metrics and billing reporting
CN106886847A (zh) 2016-06-22 2017-06-23 阿里巴巴集团控股有限公司 一种资源处理方法及装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070282739A1 (en) * 2006-05-30 2007-12-06 Jacob Thomsen Computer implemented method and system for rapid verification and administration of fund transfers and a computer program for performing said method
CN103312662A (zh) * 2012-03-07 2013-09-18 阿里巴巴集团控股有限公司 一种数据传输、处理方法和装置
CN103714452A (zh) * 2012-10-09 2014-04-09 上海博路信息技术有限公司 一种终端支付方法

Also Published As

Publication number Publication date
KR20190020795A (ko) 2019-03-04
US10827016B2 (en) 2020-11-03
AU2017280384A1 (en) 2019-02-07
CN106886847A (zh) 2017-06-23
CA3029082A1 (en) 2017-12-28
US20200128090A1 (en) 2020-04-23
MX2019000126A (es) 2019-10-17
KR102192876B1 (ko) 2020-12-23
SG11201811436YA (en) 2019-01-30
US20190149627A1 (en) 2019-05-16
PH12018502743A1 (en) 2019-10-14
JP2019519050A (ja) 2019-07-04
TW201800994A (zh) 2018-01-01
EP3477562A4 (en) 2019-05-01
MY193309A (en) 2022-10-04
BR112018076877A8 (pt) 2023-04-25
AU2017280384B2 (en) 2020-03-12
BR112018076877A2 (pt) 2019-04-02
RU2718155C1 (ru) 2020-03-30
EP3477562A1 (en) 2019-05-01
JP6761056B2 (ja) 2020-09-23
US10805410B2 (en) 2020-10-13

Similar Documents

Publication Publication Date Title
WO2017219874A1 (zh) 一种资源处理方法及装置
CN109961365B (zh) 一种基于区块链智能合约的收账记录处理方法及***
TWI640937B (zh) Online payment method and equipment
CN108805632B (zh) 一种计费方法和装置
CN106462461B (zh) 用于针对用户的移动宽带服务和虚拟化云资源的消费向用户开账单的***、设备和方法
US11276059B2 (en) System and method for autonomous sustenance of digital assets
CN105787733B (zh) 一种业务信息处理方法及装置
WO2021244537A1 (zh) 资源转移
CN107392582B (zh) 资源转移的实现方法和装置、收付款的实现方法和装置
CN108153795B (zh) 一种电子红包的数据处理方法、***和装置
WO2019223381A1 (zh) 交易纠纷处理方法及装置和电子设备
CN112184240A (zh) 一种退款请求处理方法和装置
CN107147610B (zh) 资源的处理方法及装置
CN105868984B (zh) 一种通用电子货币的处理方法及装置
TWI701626B (zh) 資料業務處理方法及裝置
US10074115B1 (en) Subscription management service
CN114417062A (zh) 一种数据湖数据部署方案确定方法及相关设备
CN113935726A (zh) 实现公共账户的方法、设备以及计算机可读介质
CN112037097A (zh) 费用清算方法及装置
KR100847710B1 (ko) 복수의 당사자들 간의 소액결제의 용이화
CN113656415A (zh) 支付方法、支付装置、支付设备及存储介质
CN114548964A (zh) 一种支付方法、装置及设备
CN117009058A (zh) 数据处理方法、装置、计算机设备和存储介质
CN116012006A (zh) 一种基于数字货币的支付方法、平台及支付***
WO2023129862A1 (en) Card to bank payments solution

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17814612

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3029082

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2018567695

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112018076877

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 20197002131

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2017814612

Country of ref document: EP

Effective date: 20190122

ENP Entry into the national phase

Ref document number: 2017280384

Country of ref document: AU

Date of ref document: 20170609

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 112018076877

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20181221