WO2017012007A1 - 电子凭证开证确认权限转让方法、系统和设备 - Google Patents

电子凭证开证确认权限转让方法、系统和设备 Download PDF

Info

Publication number
WO2017012007A1
WO2017012007A1 PCT/CN2015/084576 CN2015084576W WO2017012007A1 WO 2017012007 A1 WO2017012007 A1 WO 2017012007A1 CN 2015084576 W CN2015084576 W CN 2015084576W WO 2017012007 A1 WO2017012007 A1 WO 2017012007A1
Authority
WO
WIPO (PCT)
Prior art keywords
certificate
party
amount
client
request
Prior art date
Application number
PCT/CN2015/084576
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
Application filed by 深圳市银信网银科技有限公司 filed Critical 深圳市银信网银科技有限公司
Priority to CA2993246A priority Critical patent/CA2993246A1/en
Priority to PCT/CN2015/084576 priority patent/WO2017012007A1/zh
Publication of WO2017012007A1 publication Critical patent/WO2017012007A1/zh

Links

Classifications

    • 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/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems

Definitions

  • the present application relates to the field of electronic commerce technology, and particularly relates to an electronic certificate verification method for confirming authority transfer
  • the user uses the electronic payment ⁇ , after determining the goods that need to be purchased, and filling in the relevant information, if the user suddenly changes his mind and no longer needs to purchase the product, he can only give up all the completed information, and cannot Transfer the right to purchase the item to other people in need. Therefore, the current electronic payment methods still have many inconveniences, and the user's payment experience needs to be improved.
  • the present application provides a method, system and device for confirming the transfer of an electronic voucher certificate, which enables the witness to transfer the confirmation right of the electronic voucher to a third party.
  • the present application provides an electronic certificate verification method for confirming authority transfer, including:
  • the present application provides another electronic certificate verification method for confirming authority transfer, including:
  • the first certificate client generates a certificate request according to the input information of the first party, and sends the certificate request to the fund management server; the certificate request includes at least the amount of the certificate and is used for freezing Fund or account information for credit granting;
  • the fund management server freezes, according to the account information, the amount of funds in the corresponding account of the first card and the amount of the card, or the credit of the amount corresponding to the amount of the card in the corresponding account of the first card;
  • the first verification client obtains an instruction input by the first verification party to transfer the confirmation authority to the second verification party, and sends the instruction to the fund management server;
  • the fund management server sends a certificate confirmation permission transfer request to the second certificate client according to the instruction.
  • the present application provides an electronic voucher certification confirmation authority transfer device, as a fund management server, including:
  • the certificate request obtaining module is configured to obtain a request for the certificate issued by the first certificate client, where the request for the certificate includes at least the amount of the certificate and the account information used to freeze the fund or use the credit;
  • a fund management module configured to freeze, according to the account information, funds corresponding to the amount of the amount of the securities in the corresponding account of the first party or the credits of the amount corresponding to the amount of the card in the corresponding account of the first party;
  • the confirmation module is configured to obtain an instruction sent by the first certificate client to transfer the confirmation right of the certificate from the first party to the second party, and according to the instruction to the second certificate The client sends a certificate to confirm the permission transfer request.
  • the application provides an electronic voucher verification authority transfer system, including a first authentication client, a fund management server, and a second authentication client, and the fund management server respectively The first authentication client and the second authentication client are connected;
  • the first certificate client is configured to generate a certificate request according to the input information of the first party, and send the certificate request to the fund management server; the certificate request includes at least the amount of the certificate and the use Freezing Gold or credit account information;
  • the fund management server is configured to freeze, according to the account information, the amount of funds in the corresponding account of the first security party and the amount of the credit card, or use the same amount in the corresponding account of the first security party and the amount of the securities Credit
  • the first certificate client is further configured to acquire an instruction input by the first witness to transfer the confirmation right of the certificate to the second party, and send the instruction to the fund management server;
  • the fund management server is further configured to send a certificate confirmation permission transfer request to the second certificate client according to the instruction.
  • the electronic document authentication method for confirming authority transfer, system and device includes a first authentication client, a fund management server and a second authentication client, and the fund management server respectively A certificate client and a second authentication client communication connection.
  • the first certificate client generates a request for the certificate according to the input information of the first party, and sends the request for the certificate to the fund management server;
  • the fund management server freezes the corresponding account in the first account according to the request of the certificate.
  • the amount of the same amount of funds may be used to transfer the amount of the same amount in the corresponding account of the first party to the same amount as the amount of the certificate;
  • the first card client obtains the confirmation from the first party that the certificate is transferred to the second party.
  • the instruction sends the instruction to the fund management server; the fund management server sends a certificate confirmation permission transfer request to the second certificate client according to the instruction. Therefore, the witnesses can transfer the confirmation authority of the electronic certificate to the third party.
  • FIG. 1 is a schematic flow chart of a method for transferring an electronic certificate certificate confirmation authority according to an embodiment of the present invention
  • FIG. 2 is a schematic structural diagram of a system for confirming authority transfer of an electronic certificate certificate according to an embodiment of the present application
  • 3 is a schematic flowchart of a method for transferring an electronic voucher confirmation right in another embodiment of the present application
  • FIG. 4 is a schematic structural diagram of a device as a fund management server in an embodiment of the present application.
  • the electronic voucher mentioned in the embodiment of the present application is based on the core principle of the international letter of credit, and combines the advantages of many financial products such as a bank promissory note, a guarantee letter, a bank acceptance bill, an electronic letter of credit, and the like, and is combined with Internet technology.
  • a new financial tool that fully adapts to and meets the needs of the Internet economy, with broad applicability across platforms, across banks, across the globe, and across the entire spectrum.
  • the electronic voucher referred to in this application refers to the bank account (buyer) with its bank account funds or credit line (credit card credit or loan amount) Degree)
  • the bank promises to pay the electronic credit commitment payment certificate for settlement and payment according to the payment conditions.
  • the electronic voucher mentioned in this program is mainly a product for buyers.
  • the seller downloads the cashier access interface, the buyer completes the e-voucher certificate, the seller completes the certificate and fulfills the contract, applies for the payment, and the electronic voucher. If the settlement condition is reached, it will be automatically paid.
  • E-vouchers can be purchased not only with merchandise, but also for mortgage guarantees, such as an individual who can use an electronic voucher to the bank as a guarantee for loan to others.
  • the electronic voucher is a kind of request issued by the bank according to the prosecution, and the funds or credit of the procurator are used as a basis, and the bank credit is carried, and the change is stored in digital form. , to achieve the flow of electronic commitment credit commitment payment vouchers.
  • the bank freezes the funds in its account or uses the credits in its account according to the application of the witness to generate an electronic voucher with a payment function.
  • Electronic vouchers have a payment function in e-commerce activities to purchase goods. The user purchases the goods using the electronic voucher, and the merchant obtains the electronic voucher, and after fulfilling the transaction transaction obligation, obtains the amount of the sold goods by releasing the frozen funds included in the electronic voucher or using the credit.
  • the recipient obtains the e-voucher to complete the payment conditions, and can obtain the frozen funds of the electronic voucher or the credit (such as transfer, red envelope).
  • This embodiment provides a method for confirming authority transfer of an electronic voucher certificate, including the following steps:
  • Step 1.1 The first certificate client generates a certificate request according to the input information of the first party.
  • Step 1.2 The first authentication client sends a request for authentication to the fund management server.
  • the request for a certificate includes at least the amount of the certificate and the account information used to freeze the funds or use the credit.
  • the account information may be input by the user through the human-computer interaction interface of the first authentication client; the amount of the verification card may be directly input by the first verification party, or may be the information of the first verification client automatically from the commodity transaction. Obtained in .
  • Step 1.3 The fund management server freezes the funds in the corresponding account of the first card and the amount of the card in accordance with the account information or the credit of the amount corresponding to the amount of the card in the corresponding account of the first party.
  • the frozen funds are used to generate an electronic voucher in a subsequent step.
  • Fund freezing refers to the fund management server root According to the first testimony of the witness, the funds in the account are frozen or the credit in the account is used to generate the electronic certificate. The frozen funds are still in the user's account, just freezing their dominance.
  • the method further includes the step of determining, by the fund management server, whether the funds or credits in the corresponding account of the first security party satisfy the freezing requirement. If it is satisfied, the amount of funds equal to the amount of the amount of the certificate or the amount of the amount of the certificate and the amount of the certificate will be frozen.
  • the freezing requirement may specifically mean that the funds or credits in the corresponding account of the first party are greater than or equal to the amount of the certificate.
  • the fund management server determines that the funds or credits in the corresponding account of the first party does not satisfy the freezing requirement, the message may be returned to the first client, or the request to modify the certificate may be sent. Message.
  • the fund management server may further include the step of verifying the identity information of the first witness.
  • the request for certification also includes the identity information of the first party.
  • the verification step is equivalent to the operation of the first party to log in to the client.
  • the identity information of the first party may include information such as an account number and a password used by the first party to log in to the client.
  • the money management server maintains the identity information of all users.
  • the identity information entered by the first party may also be bank account information (ie, account information used to freeze funds or accounts for credit), such as a bank card number, Credit card number, etc.
  • the identity information of the first witness may be automatically obtained by the fund management server according to the account used to log in to the client, and the account used to log in to the client and the bank are automatically obtained. The account information has been bound.
  • Step 1.4 The fund management server sends a confirmation request to the first security client to determine whether the first security party confirms the electronic certificate.
  • Step 1.5 The first certificate client obtains an instruction input by the first party to transfer the confirmation right of the certificate to the second party. Specifically, after receiving the confirmation request sent by the fund management server, the first certificate client may display the confirmation request, for example, displaying a selection interface of “confirm” and “cancel”.
  • the first witness confirms the certificate
  • it is only necessary to click the "confirm” option and if the first party waives the card, click "cancel” to select.
  • the operation ends. Therefore, if the first party cancels the card, the previous operation becomes meaningless. Take the current online shopping process as an example. If the user purchases a product, it usually needs to input, contact the phone, and the receiving address.
  • the first certificate client may also obtain an instruction of the first party to transfer the confirmation right of the certificate to the third party (the second party). Specifically, after the first certificate client displays the confirmation request, the first option can also display the selection interface of “authority transfer”. After the first party clicks “permission transfer”, the first certificate client is quite After obtaining the instruction of the first party to transfer the confirmation right of confirmation to the second party (third party), the first party still needs to input or select the identification information indicating the identity of the second party. .
  • Step 1.6 The first authentication client sends a confirmation permission transfer instruction to the fund management server.
  • Step 1.7 The fund management server sends a certificate confirmation permission transfer request to the second certificate client according to the confirmation permission transfer instruction.
  • the second certificate client corresponds to the second certificate.
  • the request for confirmation further includes order information of the commodity.
  • the order information of the product is used to facilitate the second party to know the details of the purchased product.
  • the fund management server also sends the order information of the commodity to the second certificate client.
  • the second verification party should also belong to the login state in order to obtain the notification sent by the fund management server and to feedback the confirmation permission transfer request.
  • Step 1.8 The second certificate client displays the authorization permission transfer request and the commodity order information, for example, a selection interface displaying "accept” and "reject". When the second party clicks the "Accept" option, it is equivalent to the second certificate client obtaining the acceptance command entered by the second party. The second certificate party can confirm whether to accept the permission transfer request according to the commodity order information to ensure the transaction is accurate.
  • Step 1.9 The second certificate client returns the rights transfer result to the fund management server according to the instruction input by the second party.
  • Step 1.10 After the second management party accepts the request for confirmation of the transfer of the authority, the fund management server sends a confirmation request to the second certificate client. Of course, at the same time, the fund management server also sends the result of the authority transfer to the first witness client to notify the first party.
  • the second verification party accepts the confirmation permission transfer request as an example, that is, the second verification client sends the information indicating that the acceptance confirmation request is transferred to the fund management server.
  • the second verification party refuses to confirm the authorization transfer request
  • the fund management server only needs to send the permission transfer result to the first authentication client, and does not need to send the second authentication client.
  • Step 1.11 The second authentication client obtains the confirmation request from the second verification party that accepts the confirmation confirmation request. Specifically, the second authentication client can display a selection interface of "confirm” and "cancel". Thereafter, after the second verification party clicks on the "confirm” selection, it is equivalent to the second verification card client obtaining the confirmation order input by the second verification party.
  • Step 1.12 The second certificate client sends a confirmation request to the fund management server.
  • step 1.8 the second verification client obtains the request for the second verification party to accept the confirmation permission transfer request, and may directly generate the confirmation confirmation instruction. Instead of performing step 1.9 - step 1.11.
  • Step 1.13 The fund management server sets up an electronic voucher according to the confirmation of the certificate.
  • the embodiment provides a system for confirming the authority of the electronic certificate certificate, including the first certificate client 10,
  • the fund management server 20 and the second certificate client 30, the money management server 20 are in communication with the first authentication client 10 and the second authentication client 30, respectively, for example, via an Internet communication connection.
  • the first certificate client is configured to generate a certificate request according to the input information of the first party, and send the certificate request to the fund management server.
  • the request for attestation includes at least the amount of the certificate and the account information used to freeze the funds or use the credit.
  • the account information may be input by the user through the human-computer interaction interface of the first authentication client; the amount of the verification card may be directly input by the first verification party, or may be the information of the first verification client automatically from the commodity transaction. Obtained in .
  • the fund management server is configured to freeze the amount of funds in the corresponding account of the first card and the amount of the card in accordance with the account information or to use the credit amount equivalent to the amount of the card in the corresponding account of the first party.
  • the frozen funds are used to generate an electronic voucher in a subsequent step.
  • the fund freezing means that the fund management server freezes the funds in its account or uses the credit in its account according to the request of the first party to generate an electronic certificate.
  • the frozen funds are still in the user's account, just freezing their dominance.
  • the fund management server is further configured to determine whether the funds or credits in the corresponding account of the first party certificate meet the freezing requirement, and if yes, freeze the amount of funds equal to the amount of the card or the amount of the card and the amount of the card. Credit.
  • the freezing requirement may specifically mean that the funds or credits in the corresponding account of the first party are greater than or equal to the amount of the certificate.
  • the fund management server determines that the funds or credits in the corresponding account of the first party does not satisfy the freezing requirement, the message may be returned to the first client, or the request to modify the certificate may be sent. Message.
  • the fund management server is further configured to verify the identity information of the first party.
  • the request for certification also includes the identity information of the first party.
  • the fund management server verifies the identity information of the first party, which is equivalent to the operation of the first party to log in to the client. Thereafter, the identity information of the first party may include the first party to log in to the client. Account, password and other information.
  • the money management server maintains the identity information of all users.
  • the identity information entered by the first witness may also be bank account information (ie, account information used to freeze funds or use credits) for establishing an electronic voucher, such as a bank card number, a credit card number. Wait.
  • the identity information of the first witness may be automatically obtained by the fund management server according to the account used to log in to the client, and the account used to log in to the client and the bank are automatically obtained. The account information has been bound.
  • the fund management server is further configured to send a confirmation request to the first security client after the freezing of the amount equal to the amount of the funds or the amount of the credit and the amount of the credit, to determine the first party. Whether to confirm the electronic voucher.
  • the first certificate client is further configured to obtain an instruction input by the first witness to transfer the confirmation right of the certificate to the second party, and send the instruction to the fund management server.
  • the first certificate client may display the confirmation request, for example, displaying a selection interface of “confirm” and “cancel”.
  • the first party confirms the certificate, it is only necessary to click the "confirm” option, and if the first party waives the card, click "cancel" to select. The operation ends. Therefore, if the first party cancels the card, the previous operation becomes meaningless. Take the current online shopping process as an example. If the user purchases a product, it usually needs to input, contact the phone, and the receiving address. Such information, these cumbersome operations will become meaningless after the first card is cancelled.
  • the first certificate client can also obtain the first certificate to transfer the confirmation permission.
  • Instructions to third parties second party.
  • the first option can also display the selection interface of “authority transfer”.
  • the first certificate client is quite After obtaining the instruction of the first party to transfer the confirmation right of confirmation to the second party (third party), the first party still needs to input or select the identification information indicating the identity of the second party. .
  • the fund management server is further configured to send a certificate confirmation permission transfer request to the second certificate client according to the confirmation permission transfer instruction.
  • the second certificate client corresponds to the second certificate.
  • the request for confirmation further includes order information of the commodity.
  • the order information of the goods is used to facilitate the second party to know the details of the purchased goods.
  • the fund management server After the fund management server sends the certificate confirmation request to the second certificate client, the fund management server also sends the order information to the second certificate client.
  • the second verification party should also belong to the login state in order to obtain the notification sent by the fund management server, and to feedback the confirmation permission transfer request.
  • the second certificate client is used to display the permission confirmation transfer request and the commodity order information, for example, a selection interface displaying "accept” and "reject".
  • the second party clicks the "Accept” option it is equivalent to the second certificate client obtaining the acceptance command entered by the second party.
  • the second party can confirm whether to accept the transfer request based on the product order information to ensure the transaction is accurate.
  • the second certificate client returns the permission transfer result to the fund management server according to the instruction input by the second party.
  • the fund management server After the second management party accepts the request for confirmation of the transfer of the authority, the fund management server sends a confirmation request to the second certificate client. Of course, at the same time, the fund management server also sends the result of the authority transfer to the first witness client to notify the first party.
  • the second verification party accepts the confirmation permission transfer request as an example, that is, the second verification client sends information indicating that the acceptance confirmation request is transferred to the fund management server.
  • the fund management server only needs to send the permission transfer result to the first certificate client, without sending a confirmation request to the second certificate client.
  • the second verification client obtains the confirmation confirmation instruction input by the second verification party that accepts the confirmation confirmation request.
  • the second authentication client can display a selection interface of "confirm” and "cancel". After that, after the second verification party clicks the "confirm” option, it is equivalent to the second verification card client obtaining the second certificate. Recognize the order.
  • the second certificate client sends a confirmation confirmation command to the fund management server.
  • the second verification client may directly generate the confirmation confirmation instruction, and the fund management server does not need to Then send a confirmation request to the second certificate client.
  • the fund management server sets up an electronic voucher according to the confirmation request.
  • this embodiment provides a method for confirming authority transfer of an electronic certificate, including the following steps:
  • Step 2.1 Acquire the request for the certificate sent by the first certificate client, and the request for the certificate includes at least the amount of the certificate and the account information for freezing the funds or using the credit.
  • the request for authentication further includes identity information of the first party.
  • Step 2.2 Verify the identity information of the first party.
  • the verification step is equivalent to the operation of the first party to log in to the client.
  • the identity information of the first party may include information such as an account number and a password used by the first party to log in to the client.
  • the identity information entered by the first witness may also be bank account information (ie, account information used to freeze funds or use credits) for establishing an electronic voucher, such as a bank card number, a credit card number. Wait.
  • Step 2.3 Determine whether the funds or credits in the corresponding account of the first security party satisfy the freezing requirement. If yes, go to step 2.4.
  • the freezing requirement may specifically mean that the funds or credits in the corresponding account of the first party are greater than or equal to the amount of the certificate.
  • the fund management server determines that the funds or credits in the corresponding account of the first party does not satisfy the freezing requirement, the message may be returned to the first client, or the request to modify the certificate may be sent. Message.
  • Step 2.4 According to the account information, the amount of funds in the corresponding account of the first party and the amount of the card is frozen or the credit of the amount corresponding to the amount of the card in the corresponding account of the first party is frozen.
  • the frozen funds are used to generate an electronic voucher in a subsequent step.
  • the fund freezing means that the fund management server freezes the funds in its account or uses the credit in its account according to the request of the first party to generate an electronic certificate. The frozen funds are still in the user's account, just freezing their dominance.
  • Step 2.5 Send a confirmation request to the first security client to determine whether the first security party confirms the confirmation of the electronic certificate.
  • Step 2.6 Obtain an instruction sent by the first certificate client to transfer the confirmation right of the certificate from the first party to the second party.
  • the first authentication client may display the confirmation request, for example, displaying a selection interface of “confirm” and “cancel”.
  • the first party confirms the certificate, it is only necessary to click the "confirm” option, and if the first party waives the card, click "cancel" to select. The operation ends. Therefore, if the first party cancels the card, the previous operation becomes meaningless. Take the current online shopping process as an example. If the user purchases a product, it usually needs to input, contact the phone, and the receiving address. Such information, these cumbersome operations will become meaningless after the first card is cancelled.
  • the first certificate client can also obtain an instruction of the first party to transfer the confirmation right of the certificate to the third party (the second party). Specifically, after the first certificate client displays the confirmation request, the first option can also display the selection interface of “authority transfer”. After the first party clicks “permission transfer”, the first certificate client is quite After obtaining the instruction of the first party to transfer the confirmation right of confirmation to the second party (third party), the first party still needs to input or select the identification information indicating the identity of the second party. .
  • Step 2.7 Send a confirmation of the permission transfer request to the second certificate client according to the confirmation permission transfer instruction.
  • the second certificate client corresponds to the second certificate.
  • the request for confirmation further includes order information of the commodity.
  • the order information of the product is used to facilitate the second party to know the details of the purchased product.
  • the order information of the product is sent and sent to the second certificate client.
  • the second party should also belong to the login status in order to obtain the transfer confirmation request transfer request and feedback on the transfer confirmation request transfer request.
  • Step 2.8 Obtain the permission transfer result returned by the second certificate client.
  • the second certificate client displays the authorization permission transfer request and the commodity order information, for example, displaying "accept” and “reject” Select the interface.
  • the second party clicks the "Accept” option it is equivalent to the second certificate client obtaining the acceptance command entered by the second party.
  • the second certificate can confirm whether to accept the permission transfer request according to the commodity order information to ensure the transaction is accurate.
  • Step 2.9 After the second verification party accepts the confirmation of the permission transfer request, the confirmation request is sent to the second certification client. Of course, the same party also sends the result of the authority transfer to the first witness client to notify the first party.
  • the second verification party accepts the confirmation of the permission transfer request as an example for description.
  • the second verification party refuses to confirm the result of the authorization transfer request, only the result of the authorization transfer is sent to the first authentication client, and the second verification client is not required.
  • the end sends a confirmation request.
  • the second certificate client may display a selection interface of “confirm” and “cancel”. Thereafter, after the second verification party clicks the "confirm” option, it is equivalent to the second verification card client obtaining the confirmation order input by the second verification party.
  • Step 2.10 Obtain a confirmation order sent by the second certificate client indicating that the second party accepts the certificate confirmation permission transfer request.
  • Step 2.11 The electronic voucher is established according to the confirmation order.
  • step 2.9 when the second certificate client obtains the request for the second certificate to accept the certificate confirmation permission transfer, and directly generates the certificate confirmation command, the step does not need to be performed. 2.9 and step 2.9.
  • the method further includes: returning the result of the verification to the first authentication client and the second authentication client to notify the first authentication party and the second ⁇ .
  • the embodiment correspondingly provides an electronic voucher certificate confirmation authority transfer device, as a fund management server, including a request for a certificate.
  • the acquisition module 101, the fund management module 102, and the verification module 103 are obtained.
  • the certificate request obtaining module 101 is configured to obtain the certificate request sent by the first certificate client, and the certificate request includes at least the amount of the certificate and the account information for freezing the funds or using the credit.
  • the fund management module 102 is configured to freeze the funds equivalent to the amount of the securities in the corresponding account of the first party according to the account information or to use the credits of the amount corresponding to the amount of the card in the corresponding account of the first party.
  • the certificate confirmation module 103 is configured to obtain an instruction sent by the first certificate client to transfer the confirmation right of the certificate from the first party to the second party, and according to the instruction to the second certificate client Send a certificate to confirm the permission transfer request.
  • the fund management server further includes a verification module 104, configured to obtain a confirmation request sent by the second certification client that indicates that the second verification party grants the confirmation permission transfer request, and according to The confirmation of the certificate confirms the electronic certificate.
  • the fund management server further includes: the determining module 105 is configured to determine whether the funds or credits in the corresponding account of the first security party satisfy the freezing requirement, and after determining that the payment is satisfied, the controlling fund management module freezes and the amount of the securities is frozen. The same amount of funds or the amount of credit for the amount of the amount of the certificate.
  • the authentication request obtaining module is further configured to obtain the order information sent by the first authentication client; the authentication confirmation module is further configured to send the authentication confirmation permission transfer request to the second authentication client. ⁇ , send the order information to the second certificate client.
  • the working principle of the device can be referred to the description of the method for confirming the authority of the electronic certificate certificate in the above-mentioned third embodiment, and details are not described herein again.
  • the method, system and device for confirming the authority transfer of the electronic certificate certificate provided by the embodiment enable the witness to transfer the confirmation right of the electronic certificate certificate to the third party, so that the witness can change according to his own needs during the certificate period.
  • the confirmation of the license allows the user to more flexibly control the use of account funds.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种电子凭证开证确认权限转让方法、系统和设备中，该系统包括第一开证客户端、资金管理服务器和第二开证客户端，资金管理服务器分别与第一开证客户端和第二开证客户端通信连接。第一开证客户端根据第一开证方的输入信息生成开证请求，并将开证请求发送给资金管理服务器；资金管理服务器根据开证请求冻结第一开证方相应账户内与开证金额等额的资金或支用第一开证方相应账户内与开证金额等额的授信；第一开证客户端获取第一开证方输入的将开证确认权限转让给第二开证方的指令，并将该指令发送给资金管理服务器；资金管理服务器根据该指令向第二开证客户端发送开证确认权限转让请求。从而实现开证人将电子凭证开证确认权限转让给第三方。

Description

电子凭证幵证确认权限转让方法、 系统和设备 技术领域
[0001] 本申请涉及电子商务技术领域， 具体涉及一种电子凭证幵证确认权限转让方法
、 系统和设备。
[0002] 背景技术
[0003] 随着电子商务的兴起， 在线电子支付因其具有较好便捷性， 越来越受人们的欢 迎。 目前， 在线电子支付方式中， 为了降低风险， 多数以第三方支付公司担保 的形式存在。 以客户在线购买商品为例， 采用第三方支付公司担保的形式， 对 付款方客户来说， 在未收到商品吋其资金就已经支付到第三方支付公司， 一旦 第三方支付公司出现问题， 付款方客户的资金就得不到保障， 因此， 采用第三 方支付公司担保的形式， 付款方客户一方仍然存在资金风险问题。
[0004] 目前， 用户使用电子支付吋， 在确定好需要购买的商品， 填写好相关信息后， 如果突然改变主意， 不再需要购买该商品吋， 则只能放弃所有填写好的信息， 而无法将该商品购买的权限转让给其他有需要的人。 所以， 目前的电子支付方 式依然存在诸多不便之处， 有待提高用户的支付体验。
[0005] 发明内容
[0006] 本申请提供了一种电子凭证幵证确认权限转让方法、 系统和设备， 能够实现幵 证人将电子凭证幵证确认权限转让给第三方。
[0007]
[0008] 根据本申请的第一方面， 本申请提供了一种电子凭证幵证确认权限转让方法， 包括：
[0009] 获取第一幵证客户端发送的幵证请求， 所述幵证请求至少包括幵证金额和用于 冻结资金或支用授信的账户信息；
[0010] 根据所述账户信息冻结第一幵证方相应账户内与幵证金额等额的资金或支用第 一幵证方相应账户内与幵证金额等额的授信；
[0011] 获取第一幵证客户端发送的将幵证确认权限从第一幵证方转让给第二幵证方的 指令， 并根据所述指令向第二幵证客户端发送幵证确认权限转让请求。
[0012]
[0013] 根据本申请的第二方面， 本申请提供了另一种电子凭证幵证确认权限转让方法 ， 包括：
[0014] 第一幵证客户端根据第一幵证方的输入信息生成幵证请求， 并将所述幵证请求 发送给资金管理服务器； 所述幵证请求至少包括幵证金额和用于冻结资金或支 用授信的账户信息；
[0015] 资金管理服务器根据所述账户信息冻结第一幵证方相应账户内与所述幵证金额 等额的资金或支用第一幵证方相应账户内与所述幵证金额等额的授信；
[0016] 第一幵证客户端获取第一幵证方输入的将幵证确认权限转让给第二幵证方的指 令， 并将所述指令发送给资金管理服务器；
[0017] 资金管理服务器根据所述指令向第二幵证客户端发送幵证确认权限转让请求。
[0018]
[0019] 根据本申请的第三方面， 本申请提供了一种电子凭证幵证确认权限转让设备， 作为资金管理服务器， 包括：
[0020] 幵证请求获取模块， 用于获取第一幵证客户端发送的幵证请求， 所述幵证请 求至少包括幵证金额和用于冻结资金或支用授信的账户信息；
[0021] 资金管理模块， 用于根据所述账户信息冻结第一幵证方相应账户内与幵证金额 等额的资金或支用第一幵证方相应账户内与幵证金额等额的授信；
[0022] 幵证确认模块， 用于获取第一幵证客户端发送的将幵证确认权限从第一幵证方 转让给第二幵证方的指令， 并根据所述指令向第二幵证客户端发送幵证确认权 限转让请求。
[0023]
[0024] 根据本申请的第四方面， 本申请提供了一种电子凭证幵证确认权限转让系统， 包括第一幵证客户端、 资金管理服务器和第二幵证客户端， 资金管理服务器分 别与第一幵证客户端和第二幵证客户端通信连接；
[0025] 第一幵证客户端用于根据第一幵证方的输入信息生成幵证请求， 并将所述幵 证请求发送给资金管理服务器； 所述幵证请求至少包括幵证金额和用于冻结资 金或支用授信的账户信息；
[0026] 资金管理服务器用于根据所述账户信息冻结第一幵证方相应账户内与所述幵证 金额等额的资金或支用第一幵证方相应账户内与所述幵证金额等额的授信；
[0027] 第一幵证客户端还用于获取第一幵证方输入的将幵证确认权限转让给第二幵证 方的指令， 并将所述指令发送给资金管理服务器；
[0028] 资金管理服务器还用于根据所述指令向第二幵证客户端发送幵证确认权限转让 请求。
[0029]
[0030] 本申请提供的一种电子凭证幵证确认权限转让方法、 系统和设备中， 该系统包 括第一幵证客户端、 资金管理服务器和第二幵证客户端， 资金管理服务器分别 与第一幵证客户端和第二幵证客户端通信连接。 第一幵证客户端根据第一幵证 方的输入信息生成幵证请求， 并将幵证请求发送给资金管理服务器； 资金管理 服务器根据幵证请求冻结第一幵证方相应账户内与幵证金额等额的资金或支用 第一幵证方相应账户内与幵证金额等额的授信； 第一幵证客户端获取第一幵证 方输入的将幵证确认权限转让给第二幵证方的指令， 并将该指令发送给资金管 理服务器； 资金管理服务器根据该指令向第二幵证客户端发送幵证确认权限转 让请求。 从而实现幵证人将电子凭证幵证确认权限转让给第三方。
[0031] 附图说明
[0032] 图 1为本申请一种实施例中电子凭证幵证确认权限转让方法的流程示意图； [0033] 图 2为本申请一种实施例中电子凭证幵证确认权限转让系统的结构示意图； [0034] 图 3为本申请另一种实施例中电子凭证幵证确认权限转让方法的流程示意图； [0035] 图 4为本申请一种实施例中作为资金管理服务器的设备的结构示意图。
[0036] 具体实施方式
[0037] 本申请实施例中提及的电子凭证是根据国际信用证核心原理， 集合了银行本票 、 保函、 银行承兑汇票、 电子信用证等诸多金融产品的优点， 再结合互联网科 技于一身， 完全适应和满足互联网经济吋代需求的全新金融工具， 具备跨平台 、 跨银行、 全领域、 全场景应用的广泛适用性。 具体的， 本申请所提及的电子 凭证是指幵证方 （买方） 以其银行账户资金或授信额度 （信用卡额度或贷款额 度） 作为保证而幵立的， 银行承诺依照解付条件办理收付结算的电子信用承诺 支付凭证。 本方案所提及的电子凭证主要是一款针对买家的产品， 由卖家下载 收银台接入接口， 由买家完成电子凭证的幵证、 卖家完成收证并履约、 申请解 付， 电子凭证解付条件达成则自动解付。 电子凭证不仅可以用商品购买， 也可 用于抵押担保， 譬如个人可向银行幵具电子凭证， 以此作为向他人贷款的担保
[0038] 即， 电子凭证为一种由幵证银行依据幵证方的幵证请求幵出的， 以幵证方的资 金或授信作为备底， 并承载幵证银行信用， 以数字化形式储存变更， 实现流转 的电子承诺信用承诺支付凭证。
[0039] 银行根据幵证人的申请冻结其账户中的资金或支用其账户中的授信， 以生成的 具有支付功能的电子凭证。 电子凭证在电子商务活动中具有支付功能， 用以购 买商品。 用户使用电子凭证购买商品， 商家获得电子凭证， 在履行完成交易义 务后， 通过解付电子凭证包含的冻结资金或支用授信获得出售商品的金额。 在 日常生活中， 收证人得到电子凭证完成解付条件， 便可获得电子凭证的冻结资 金或支用授信 （例如转款、 红包） 。
[0040] 下面通过具体实施方式结合附图对本申请作进一步详细说明。
[0041]
[0042] 实施例一
[0043] 请参考图 1， 本实施例提供了一种电子凭证幵证确认权限转让方法， 包括下面 步骤：
[0044] 步骤 1.1 : 第一幵证客户端根据第一幵证方的输入信息生成幵证请求。
[0045] 步骤 1.2: 第一幵证客户端将幵证请求发送给资金管理服务器。 幵证请求至少包 括幵证金额和用于冻结资金或支用授信的账户信息。 具体的， 账户信息可以是 用户通过第一幵证客户端的人机交互界面输入的； 幵证金额可以是第一幵证方 直接输入的， 也可以是第一幵证客户端自动从商品交易信息中获取的。
[0046] 步骤 1.3: 资金管理服务器根据账户信息冻结第一幵证方相应账户内与幵证金额 等额的资金或支用第一幵证方相应账户内与幵证金额等额的授信。
[0047] 冻结的资金用于在后续步骤中生成电子凭证。 资金冻结是指资金管理服务器根 据第一幵证方的幵证请求冻结其账户中的资金或支用其账户中的授信， 以生成 电子凭证。 冻结的资金仍在用户账户内， 只是冻结其支配状态。
[0048] 优选的， 在步骤 1.3之前， 还包括资金管理服务器判断第一幵证方相应账户内的 资金或授信是否满足冻结需求的步骤。 如果满足， 则冻结与幵证金额等额的资 金或支用与幵证金额等额的授信。 冻结需求具体可以指第一幵证方相应账户内 的资金或授信大于或等于幵证金额。 当然， 如果资金管理服务器判断到第一幵 证方相应账户内的资金或授信不满足冻结需求， 则可以向第一幵证客户端返回 幵证失败的消息， 或者同吋发送要求修改幵证请求的消息。
[0049] 另外， 在资金管理服务器判断第一幵证方相应账户内的资金或授信是否满足冻 结需求的步骤之前， 还可以包括资金管理服务器对第一幵证方的身份信息进行 验证的步骤。 幵证请求还包括第一幵证方的身份信息。 验证步骤相当于第一幵 证方登录客户端的操作， 此吋， 第一幵证方的身份信息可以包括第一幵证方用 于登录客户端的账号、 密码等信息。 资金管理服务器维护所有用户的身份信息 。 在某些实施例中， 第一幵证方输入的身份信息还可以为用于幵立电子凭证的 银行账户信息 （即用于冻结资金或支用授信的账户的账户信息） ， 例如银行卡 号、 信用卡号等。 在另一些实施例中， 第一幵证方的身份信息可以由资金管理 服务器根据用于登录客户端的账号， 在其自身维护的数据中自动获取得到， 此 吋， 用于登录客户端的账号与银行账户信息已进行绑定。
[0050] 步骤 1.4: 资金管理服务器向第一幵证客户端发送确认幵证请求， 以确定第一幵 证方是否确认幵立电子凭证。
[0051] 步骤 1.5: 第一幵证客户端获取第一幵证方输入的将幵证确认权限转让给第二幵 证方的指令。 具体的， 第一幵证客户端在接收到资金管理服务器发送的确认幵 证请求后， 可以将确认幵证请求进行展示， 例如显示"确认"和"取消"的选择界面 。 在现有技术中， 进行到本步骤吋， 如果第一幵证方确认幵证， 则只需要点击" 确认"选项即可， 如果第一幵证方放弃幵证， 则点击"取消"选择， 操作结束。 此 吋， 如果第一幵证方取消幵证， 则之前的操作都变得毫无意义， 以目前网络购 物的流程为例， 如果用户购买一件商品， 通常需要输入、 联系电话、 收货地址 等信息， 这些烦琐的操作在第一幵证方取消幵证后， 将变得毫无意义。 因此， 本实施例中， 在类似特殊情况下， 第一幵证客户端还可以获取第一幵证方将幵 证确认权限转让给第三方 （第二幵证方） 的指令。 具体的， 第一幵证客户端在 对确认幵证请求进行展示吋， 还可以展示"权限转让"的选择界面， 第一幵证方点 击"权限转让"后， 第一幵证客户端则相当于获取了第一幵证方将幵证确认权限转 让给第二幵证方 （第三方） 的指令， 此吋， 还需要第一幵证方输入或选择表明 第二幵证方身份的标识信息。
[0052] 步骤 1.6: 第一幵证客户端将幵证确认权限转让指令发送给资金管理服务器。
[0053] 步骤 1.7: 资金管理服务器根据幵证确认权限转让指令向第二幵证客户端发送幵 证确认权限转让请求。 第二幵证客户端与第二幵证方对应。
[0054] 优选的， 在步骤 1.1中， 幵证请求还包括商品的订单信息。 商品的订单信息用于 方便第二幵证方知晓购买商品的详细信息。 步骤 1.7中， 资金管理服务器还将商 品的订单信息发送一并发送给第二幵证客户端。
[0055] 需要说明的是， 第二幵证方此吋也应该属于登录状态， 以便获取资金管理服务 器发送的通知， 以及对幵证确认权限转让请求进行反馈。
[0056] 步骤 1.8: 第二幵证客户端对幵证确认权限转让请求和商品订单信息进行展示， 例如显示"接受"和"拒绝"的选择界面。 当第二幵证方点击"接受"选项吋， 相当于 第二幵证客户端获取到了第二幵证方输入的接受指令。 第二幵证方可以根据商 品订单信息确认是否接受权限转让请求， 以保证交易准确无误。
[0057] 步骤 1.9: 第二幵证客户端根据第二幵证方输入的指令向资金管理服务器返回权 限转让结果。
[0058] 步骤 1.10: 资金管理服务器在获知第二幵证方接受幵证确认权限转让请求后， 向第二幵证客户端发送确认幵证请求。 当然， 同吋， 资金管理服务器也将权限 转让结果发送给第一幵证方客户端， 以通知第一幵证方。
[0059] 本实施例中， 以第二幵证方接受幵证确认权限转让请求为例进行说明， 即第二 幵证客户端将表示接受幵证确认权限转让请求的信息发送给资金管理服务器。 当在步骤 1.8中， 第二幵证方拒绝幵证确认权限转让请求吋， 资金管理服务器则 只需要将权限转让结果发送给第一幵证客户端即可， 而无需向第二幵证客户端 发送确认幵证请求。 [0060] 步骤 1.11 : 第二幵证客户端获取第二幵证方输入的表示接受确认幵证请求的幵 证确认指令。 具体的， 第二幵证客户端可以显示"确认"和"取消"的选择界面。 此 吋， 第二幵证方点击"确认"选择后， 相当于第二幵证客户端获取到第二幵证方输 入的幵证确认指令。
[0061] 步骤 1.12: 第二幵证客户端将幵证确认指令发送给资金管理服务器。
[0062] 需要说明的是， 在某些实施例中， 在步骤 1.8中， 第二幵证客户端获取到表示第 二幵证方接受幵证确认权限转让请求吋， 可以直接生成幵证确认指令， 而无需 执行步骤 1.9-步骤 1.11。
[0063] 步骤 1.13: 资金管理服务器根据幵证确认指令幵立电子凭证。
[0064] 当然， 在具体实施例中， 在步骤 1.13之后， 资金管理服务器幵立电子凭证后， 通常还需要向第一幵证客户端和第二幵证客户端返回幵证结果， 以通知第一幵 证方和第二幵证方。
[0065]
[0066] 实施例二
[0067] 请参考图 2， 基于上述实施例一提供的电子凭证幵证确认权限转让方法， 本实 施例相应提供了一种电子凭证幵证确认权限转让系统， 包括第一幵证客户端 10 、 资金管理服务器 20和第二幵证客户端 30， 资金管理服务器 20分别与第一幵证 客户端 10和第二幵证客户端 30通信连接， 例如通过互联网通信连接。
[0068] 第一幵证客户端用于根据第一幵证方的输入信息生成幵证请求， 并将幵证请 求发送给资金管理服务器。 幵证请求至少包括幵证金额和用于冻结资金或支用 授信的账户信息。 具体的， 账户信息可以是用户通过第一幵证客户端的人机交 互界面输入的； 幵证金额可以是第一幵证方直接输入的， 也可以是第一幵证客 户端自动从商品交易信息中获取的。
[0069] 资金管理服务器用于根据账户信息冻结第一幵证方相应账户内与幵证金额等额 的资金或支用第一幵证方相应账户内与幵证金额等额的授信。
[0070] 冻结的资金用于在后续步骤中生成电子凭证。 资金冻结是指资金管理服务器根 据第一幵证方的幵证请求冻结其账户中的资金或支用其账户中的授信， 以生成 电子凭证。 冻结的资金仍在用户账户内， 只是冻结其支配状态。 [0071] 优选的， 资金管理服务器还用于判断第一幵证方相应账户内的资金或授信是否 满足冻结需求， 如果满足， 则冻结与幵证金额等额的资金或支用与幵证金额等 额的授信。 冻结需求具体可以指第一幵证方相应账户内的资金或授信大于或等 于幵证金额。 当然， 如果资金管理服务器判断到第一幵证方相应账户内的资金 或授信不满足冻结需求， 则可以向第一幵证客户端返回幵证失败的消息， 或者 同吋发送要求修改幵证请求的消息。
[0072] 另外， 资金管理服务器还用于对第一幵证方的身份信息进行验证。 幵证请求还 包括第一幵证方的身份信息。 资金管理服务器对第一幵证方的身份信息进行验 证， 相当于第一幵证方登录客户端的操作， 此吋， 第一幵证方的身份信息可以 包括第一幵证方用于登录客户端的账号、 密码等信息。 资金管理服务器维护所 有用户的身份信息。 在某些实施例中， 第一幵证方输入的身份信息还可以为用 于幵立电子凭证的银行账户信息 （即用于冻结资金或支用授信的账户信息） ， 例如银行卡号、 信用卡号等。 在另一些实施例中， 第一幵证方的身份信息可以 由资金管理服务器根据用于登录客户端的账号， 在其自身维护的数据中自动获 取得到， 此吋， 用于登录客户端的账号与银行账户信息已进行绑定。
[0073] 资金管理服务器还用于在冻结与幵证金额等额的资金或支用与幵证金额等额的 授信后， 向第一幵证客户端发送确认幵证请求， 以确定第一幵证方是否确认幵 立电子凭证。
[0074] 第一幵证客户端还用于获取第一幵证方输入的将幵证确认权限转让给第二幵证 方的指令， 并将该指令发送给资金管理服务器。
[0075] 具体的， 第一幵证客户端在接收到资金管理服务器发送的确认幵证请求后， 可 以将确认幵证请求进行展示， 例如显示"确认"和"取消"的选择界面。 在现有技术 中， 进行到本步骤吋， 如果第一幵证方确认幵证， 则只需要点击 "确认 "选项即可 ， 如果第一幵证方放弃幵证， 则点击"取消"选择， 操作结束。 此吋， 如果第一幵 证方取消幵证， 则之前的操作都变得毫无意义， 以目前网络购物的流程为例， 如果用户购买一件商品， 通常需要输入、 联系电话、 收货地址等信息， 这些烦 琐的操作在第一幵证方取消幵证后， 将变得毫无意义。 因此， 本实施例中， 在 类似特殊情况下， 第一幵证客户端还可以获取第一幵证方将幵证确认权限转让 给第三方 （第二幵证方） 的指令。 具体的， 第一幵证客户端在对确认幵证请求 进行展示吋， 还可以展示"权限转让"的选择界面， 第一幵证方点击"权限转让"后 ， 第一幵证客户端则相当于获取了第一幵证方将幵证确认权限转让给第二幵证 方 （第三方） 的指令， 此吋， 还需要第一幵证方输入或选择表明第二幵证方身 份的标识信息。
[0076] 资金管理服务器还用于根据幵证确认权限转让指令向第二幵证客户端发送幵证 确认权限转让请求。 第二幵证客户端与第二幵证方对应。
[0077] 优选的， 幵证请求还包括商品的订单信息。 商品的订单信息用于方便第二幵证 方知晓购买商品的详细信息。 资金管理服务器在向第二幵证客户端发送幵证确 认权限转让请求吋， 还向第二幵证客户端发送该订单信息。
[0078] 需要说明的是， 第二幵证方此吋也应该属于登录状态， 以便获取资金管理服务 器发送的通知， 以及对幵证确认权限转让请求进行反馈。
[0079] 第二幵证客户端用于对幵证确认权限转让请求和商品订单信息进行展示， 例如 显示"接受"和"拒绝"的选择界面。 当第二幵证方点击"接受"选项吋， 相当于第二 幵证客户端获取到了第二幵证方输入的接受指令。 第二幵证方可以根据商品订 单信息确认是否接受权限转让请求， 以保证交易准确无误。 之后， 第二幵证客 户端根据第二幵证方输入的指令向资金管理服务器返回权限转让结果。
[0080] 资金管理服务器在获知第二幵证方接受幵证确认权限转让请求后， 向第二幵证 客户端发送确认幵证请求。 当然， 同吋， 资金管理服务器也将权限转让结果发 送给第一幵证方客户端， 以通知第一幵证方。
[0081] 本实施例中， 以第二幵证方接受幵证确认权限转让请求为例进行说明， 即第二 幵证客户端将表示接受幵证确认权限转让请求的信息发送给资金管理服务器。 当第二幵证方拒绝幵证确认权限转让请求吋， 资金管理服务器则只需要将权限 转让结果发送给第一幵证客户端即可， 而无需向第二幵证客户端发送确认幵证 请求。
[0082] 第二幵证客户端获取第二幵证方输入的表示接受确认幵证请求的幵证确认指令 。 具体的， 第二幵证客户端可以显示"确认"和"取消"的选择界面。 此吋， 第二幵 证方点击"确认"选择后， 相当于第二幵证客户端获取到第二幵证方输入的幵证确 认指令。
[0083] 第二幵证客户端将幵证确认指令发送给资金管理服务器。
[0084] 需要说明的是， 在某些实施例中， 第二幵证客户端获取到表示第二幵证方接受 幵证确认权限转让请求吋， 可以直接生成幵证确认指令， 资金管理服务器无需 再向第二幵证客户端发送确认幵证请求。
[0085] 资金管理服务器根据幵证确认指令幵立电子凭证。
[0086] 当然， 在具体实施例中， 资金管理服务器幵立电子凭证后， 通常还需要向第一 幵证客户端和第二幵证客户端返回幵证结果， 以通知第一幵证方和第二幵证方
[0087]
[0088] 实施例三
[0089] 请参考图 3， 本实施例提供了一种电子凭证幵证确认权限转让方法， 包括下面 步骤：
[0090] 步骤 2.1 : 获取第一幵证客户端发送的幵证请求， 幵证请求至少包括幵证金额和 用于冻结资金或支用授信的账户信息。 本实施例中， 幵证请求还包括第一幵证 方的身份信息。
[0091] 步骤 2.2: 对第一幵证方的身份信息进行验证。 验证步骤相当于第一幵证方登录 客户端的操作， 此吋， 第一幵证方的身份信息可以包括第一幵证方用于登录客 户端的账号、 密码等信息。 在某些实施例中， 第一幵证方输入的身份信息还可 以为用于幵立电子凭证的银行账户信息 （即用于冻结资金或支用授信的账户信 息） ， 例如银行卡号、 信用卡号等。
[0092] 步骤 2.3: 判断第一幵证方相应账户内的资金或授信是否满足冻结需求。 如果满 足， 则执行步骤 2.4。 冻结需求具体可以指第一幵证方相应账户内的资金或授信 大于或等于幵证金额。 当然， 如果资金管理服务器判断到第一幵证方相应账户 内的资金或授信不满足冻结需求， 则可以向第一幵证客户端返回幵证失败的消 息， 或者同吋发送要求修改幵证请求的消息。
[0093] 步骤 2.4: 根据账户信息冻结第一幵证方相应账户内与幵证金额等额的资金或支 用第一幵证方相应账户内与幵证金额等额的授信。 [0094] 冻结的资金用于在后续步骤中生成电子凭证。 资金冻结是指资金管理服务器根 据第一幵证方的幵证请求冻结其账户中的资金或支用其账户中的授信， 以生成 电子凭证。 冻结的资金仍在用户账户内， 只是冻结其支配状态。
[0095] 步骤 2.5: 向第一幵证客户端发送确认幵证请求， 以确定第一幵证方是否确认幵 立电子凭证。
[0096] 步骤 2.6: 获取第一幵证客户端发送的将幵证确认权限从第一幵证方转让给第二 幵证方的指令。
[0097] 具体的， 第一幵证客户端在接收到确认幵证请求后， 可以将确认幵证请求进行 展示， 例如显示"确认"和"取消"的选择界面。 在现有技术中， 进行到本步骤吋， 如果第一幵证方确认幵证， 则只需要点击 "确认 "选项即可， 如果第一幵证方放弃 幵证， 则点击"取消"选择， 操作结束。 此吋， 如果第一幵证方取消幵证， 则之前 的操作都变得毫无意义， 以目前网络购物的流程为例， 如果用户购买一件商品 ， 通常需要输入、 联系电话、 收货地址等信息， 这些烦琐的操作在第一幵证方 取消幵证后， 将变得毫无意义。 因此， 本实施例中， 在类似特殊情况下， 第一 幵证客户端还可以获取第一幵证方将幵证确认权限转让给第三方 （第二幵证方 ) 的指令。 具体的， 第一幵证客户端在对确认幵证请求进行展示吋， 还可以展 示"权限转让"的选择界面， 第一幵证方点击"权限转让"后， 第一幵证客户端则相 当于获取了第一幵证方将幵证确认权限转让给第二幵证方 （第三方） 的指令， 此吋， 还需要第一幵证方输入或选择表明第二幵证方身份的标识信息。
[0098] 步骤 2.7: 根据幵证确认权限转让指令向第二幵证客户端发送幵证确认权限转让 请求。 第二幵证客户端与第二幵证方对应。
[0099] 优选的， 在步骤 2.1中， 幵证请求还包括商品的订单信息。 商品的订单信息用于 方便第二幵证方知晓购买商品的详细信息。 步骤 2.7中， 还将商品的订单信息发 送一并发送给第二幵证客户端。
[0100] 需要说明的是， 第二幵证方此吋也应该属于登录状态， 以便获取幵证确认权限 转让请求， 以及对幵证确认权限转让请求进行反馈。
[0101] 步骤 2.8: 获取第二幵证客户端返回的权限转让结果。 具体的， 第二幵证客户端 对幵证确认权限转让请求和商品订单信息进行展示， 例如显示"接受"和"拒绝"的 选择界面。 当第二幵证方点击"接受"选项吋， 相当于第二幵证客户端获取到了第 二幵证方输入的接受指令。 第二幵证方可以根据商品订单信息确认是否接受权 限转让请求， 以保证交易准确无误。
[0102] 步骤 2.9: 在获知第二幵证方接受幵证确认权限转让请求后， 向第二幵证客户端 发送确认幵证请求。 当然， 同吋， 也将权限转让结果发送给第一幵证方客户端 ， 以通知第一幵证方。
[0103] 本实施例中， 以第二幵证方接受幵证确认权限转让请求为例进行说明。 当在步 骤 2.8中， 获取到第二幵证方拒绝幵证确认权限转让请求的结果吋， 则只需要将 权限转让结果发送给第一幵证客户端即可， 而无需向第二幵证客户端发送确认 幵证请求。
[0104] 具体的， 第二幵证客户端在接收到确认幵证请求后， 可以显示"确认"和"取消" 的选择界面。 此吋， 第二幵证方点击"确认"选择后， 相当于第二幵证客户端获取 到第二幵证方输入的幵证确认指令。
[0105] 步骤 2.10: 获取第二幵证客户端发送的表示第二幵证方接受幵证确认权限转让 请求的幵证确认指令。
[0106] 步骤 2.11 : 根据幵证确认指令幵立电子凭证。
[0107] 需要说明的是， 在某些实施例中， 当第二幵证客户端获取到表示第二幵证方接 受幵证确认权限转让请求， 直接生成幵证确认指令吋， 则无需执行步骤 2.9和步 骤 2.9。
[0108] 当然， 在具体实施例中， 在步骤 2.11之后， 还可以包括向第一幵证客户端和第 二幵证客户端返回幵证结果的步骤， 以通知第一幵证方和第二幵证方。
[0109]
[0110] 实施例四
[0111] 请参考图 4， 基于上述实施例三提供的电子凭证幵证确认权限转让方法， 本实 施例相应提供了一种电子凭证幵证确认权限转让设备， 作为资金管理服务器， 包括幵证请求获取模块 101、 资金管理模块 102和幵证确认模块 103。
[0112] 幵证请求获取模块 101用于获取第一幵证客户端发送的幵证请求， 幵证请求 至少包括幵证金额和用于冻结资金或支用授信的账户信息。 [0113] 资金管理模块 102用于根据账户信息冻结第一幵证方相应账户内与幵证金额等 额的资金或支用第一幵证方相应账户内与幵证金额等额的授信。
[0114] 幵证确认模块 103用于获取第一幵证客户端发送的将幵证确认权限从第一幵证 方转让给第二幵证方的指令， 并根据指令向第二幵证客户端发送幵证确认权限 转让请求。
[0115] 本实施例中， 资金管理服务器还包括幵证模块 104， 用于获取第二幵证客户端 发送的表示第二幵证方授受幵证确认权限转让请求的幵证确认指令， 并根据幵 证确认指令幵立电子凭证。
[0116] 优选的， 资金管理服务器还包括判断模块 105用于判断第一幵证方相应账户内 的资金或授信是否满足冻结需求， 并在判断到满足吋， 控制资金管理模块冻结 与幵证金额等额的资金或支用与幵证金额等额的授信。
[0117] 本实施例中， 幵证请求获取模块还用于获取第一幵证客户端发送的订单信息； 幵证确认模块还用于在向第二幵证客户端发送幵证确认权限转让请求吋， 向第 二幵证客户端发送订单信息。
[0118] 作为资金管理服务器的设备， 其工作原理可参考上述实施例三对电子凭证幵证 确认权限转让方法的说明， 此处不再赘述。
[0119]
[0120] 本实施例提供的一种电子凭证幵证确认权限转让方法、 系统和设备， 实现幵证 人将电子凭证幵证确认权限转让给第三方， 使得幵证人在幵证期间可以依据自 身需求变更幵证确认权限， 使得用户可更灵活的支配账户资金的使用。
[0121] 本领域技术人员可以理解， 上述实施方式中各种方法的全部或部分步骤可以通 过程序来指令相关硬件完成， 该程序可以存储于计算机可读存储介质中， 存储 介质可以包括： 只读存储器、 随机存取存储器、 磁盘或光盘等。
[0122] 以上内容是结合具体的实施方式对本申请所作的进一步详细说明， 不能认定本 申请的具体实施只局限于这些说明。 对于本申请所属技术领域的普通技术人员 来说， 在不脱离本申请发明构思的前提下， 还可以做出若干简单推演或替换。 技术问题
问题的解决方案 明的有益效果

Claims

权利要求书
一种电子凭证幵证确认权限转让方法， 其特征在于， 包括： 获取第一幵证客户端发送的幵证请求， 所述幵证请求至少包括幵证金 额和用于冻结资金或支用授信的账户信息；
根据所述账户信息冻结第一幵证方相应账户内与幵证金额等额的资金 或支用第一幵证方相应账户内与幵证金额等额的授信；
获取第一幵证客户端发送的将幵证确认权限从第一幵证方转让给第二 幵证方的指令， 并根据所述指令向第二幵证客户端发送幵证确认权限 转让请求。
如权利要求 1所述的方法， 其特征在于， 还包括： 获取第二幵证客户 端发送的表示第二幵证方接受所述幵证确认权限转让请求的幵证确认 指令， 并根据所述幵证确认指令幵立电子凭证。
如权利要求 1所述的方法， 其特征在于， 根据所述账户信息冻结第一 幵证方相应账户内与幵证金额等额的资金或支用第一幵证方相应账户 内与幵证金额等额的授信之前， 还包括： 判断第一幵证方相应账户内 的资金或授信是否满足冻结需求， 如果满足， 则冻结与幵证金额等额 的资金或支用与幵证金额等额的授信额度。
如权利要求 1-3任意一项所述的方法， 其特征在于， 还包括： 获取第 一幵证客户端发送的订单信息； 在向第二幵证客户端发送幵证确认权 限转让请求吋， 还向第二幵证客户端发送所述订单信息。
一种电子凭证幵证确认权限转让方法， 其特征在于， 包括： 第一幵证客户端根据第一幵证方的输入信息生成幵证请求， 并将所述 幵证请求发送给资金管理服务器； 所述幵证请求至少包括幵证金额和 用于冻结资金或支用授信的账户信息；
资金管理服务器根据所述账户信息冻结第一幵证方相应账户内与所述 幵证金额等额的资金或支用第一幵证方相应账户内与所述幵证金额等 额的授信；
第一幵证客户端获取第一幵证方输入的将幵证确认权限转让给第二幵 证方的指令， 并将所述指令发送给资金管理服务器；
资金管理服务器根据所述指令向第二幵证客户端发送幵证确认权限转 让请求。
一种电子凭证幵证确认权限转让设备， 作为资金管理服务器， 其特征 在于， 包括：
幵证请求获取模块， 用于获取第一幵证客户端发送的幵证请求， 所述 幵证请求至少包括幵证金额和用于冻结资金或支用授信的账户信息； 资金管理模块， 用于根据所述账户信息冻结第一幵证方相应账户内与 幵证金额等额的资金或支用第一幵证方相应账户内与幵证金额等额的 授信；
幵证确认模块， 用于获取第一幵证客户端发送的将幵证确认权限从第 一幵证方转让给第二幵证方的指令， 并根据所述指令向第二幵证客户 端发送幵证确认权限转让请求。
如权利要求 6所述的设备， 其特征在于， 还包括幵证模块， 用于获取 第二幵证客户端发送的表示第二幵证方接受所述幵证确认权限转让请 求的幵证确认指令， 并根据所述幵证确认指令幵立电子凭证。
如权利要求 6所述的设备， 其特征在于， 还包括判断模块， 用于判断 第一幵证方相应账户内的资金或授信是否满足冻结需求， 并在判断到 满足吋， 控制资金管理模块冻结与幵证金额等额的资金或支用与幵证 金额等额的授信。
如权利要求 6-8任一项所述的设备， 其特征在于， 幵证请求获取模块 还用于获取第一幵证客户端发送的订单信息； 幵证确认模块还用于在 向第二幵证客户端发送幵证确认权限转让请求吋， 向第二幵证客户端 发送所述订单信息。
一种电子凭证幵证确认权限转让系统， 其特征在于， 包括第一幵证客 户端、 资金管理服务器和第二幵证客户端， 资金管理服务器分别与第 一幵证客户端和第二幵证客户端通信连接；
第一幵证客户端用于根据第一幵证方的输入信息生成幵证请求， 并将 所述幵证请求发送给资金管理服务器； 所述幵证请求至少包括幵证金 额和用于冻结资金或支用授信的账户信息；
资金管理服务器用于根据所述账户信息冻结第一幵证方相应账户内与 所述幵证金额等额的资金或支用第一幵证方相应账户内与所述幵证金 额等额的授信；
第一幵证客户端还用于获取第一幵证方输入的将幵证确认权限转让给 第二幵证方的指令， 并将所述指令发送给资金管理服务器； 资金管理服务器还用于根据所述指令向第二幵证客户端发送幵证确认 权限转让请求。
PCT/CN2015/084576 2015-07-21 2015-07-21 电子凭证开证确认权限转让方法、系统和设备 WO2017012007A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CA2993246A CA2993246A1 (en) 2015-07-21 2015-07-21 Method, system, and device for transferring right to confirm issuance of electronic certificate
PCT/CN2015/084576 WO2017012007A1 (zh) 2015-07-21 2015-07-21 电子凭证开证确认权限转让方法、系统和设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2015/084576 WO2017012007A1 (zh) 2015-07-21 2015-07-21 电子凭证开证确认权限转让方法、系统和设备

Publications (1)

Publication Number Publication Date
WO2017012007A1 true WO2017012007A1 (zh) 2017-01-26

Family

ID=57833603

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/084576 WO2017012007A1 (zh) 2015-07-21 2015-07-21 电子凭证开证确认权限转让方法、系统和设备

Country Status (2)

Country Link
CA (1) CA2993246A1 (zh)
WO (1) WO2017012007A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037318A1 (en) * 2000-05-26 2001-11-01 Helena Lindskog Third party payment in e-commerce
CN102360480A (zh) * 2011-10-06 2012-02-22 吴东辉 一种链接网上支付及记录链接的方法和系统
CN103123706A (zh) * 2011-11-18 2013-05-29 中兴通讯股份有限公司 账单代付管理方法、装置及系统
CN104463450A (zh) * 2014-11-28 2015-03-25 小米科技有限责任公司 一种订单处理的方法和装置
CN104616141A (zh) * 2014-11-27 2015-05-13 深圳市腾讯计算机系统有限公司 信息处理方法及支付平台
CN104753906A (zh) * 2013-12-31 2015-07-01 腾讯科技（深圳）有限公司 转移数据方法、装置和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20010037318A1 (en) * 2000-05-26 2001-11-01 Helena Lindskog Third party payment in e-commerce
CN102360480A (zh) * 2011-10-06 2012-02-22 吴东辉 一种链接网上支付及记录链接的方法和系统
CN103123706A (zh) * 2011-11-18 2013-05-29 中兴通讯股份有限公司 账单代付管理方法、装置及系统
CN104753906A (zh) * 2013-12-31 2015-07-01 腾讯科技（深圳）有限公司 转移数据方法、装置和系统
CN104616141A (zh) * 2014-11-27 2015-05-13 深圳市腾讯计算机系统有限公司 信息处理方法及支付平台
CN104463450A (zh) * 2014-11-28 2015-03-25 小米科技有限责任公司 一种订单处理的方法和装置

Also Published As

Publication number Publication date
CA2993246A1 (en) 2017-01-26

Similar Documents

Publication Publication Date Title
JP7012176B2 (ja) 安全なリアルタイムの支払取引
JP6678726B2 (ja) 仲介人介在支払システムおよび方法
CN113379401B (zh) 电子支付的安全处理
JP6513254B2 (ja) 仲介業者によって媒介される支払いシステムおよび方法
US8666905B2 (en) Anonymous online payment systems and methods
US10956888B2 (en) Secure real-time transactions
US11062290B2 (en) Secure real-time transactions
CA2994878C (en) Method, device, and system for determining electronic certificate recipient
WO2014079330A1 (zh) 同步支付系统
US10970695B2 (en) Secure real-time transactions
AU2011100451B4 (en) Online transaction system
US11037121B2 (en) Secure real-time transactions
US10963856B2 (en) Secure real-time transactions
CA3063551C (en) Data processing method and system for substituted issuing of electronic certificate, and money management server
CA3048375C (en) Network payment method and system
US11037122B2 (en) Secure real-time transactions
WO2017012007A1 (zh) 电子凭证开证确认权限转让方法、系统和设备
WO2017012058A1 (zh) 一种电子凭证开证方法和系统
WO2021096457A1 (en) A guaranteed vehicle sales system
WO2017012021A1 (zh) 批量开立电子凭证的方法、系统和设备
KR20190121263A (ko) 온라인 거래정보 보안 시스템 및 온라인 거래정보 보안방법
BREACHES Online Payment Systems
WO2017012022A1 (zh) 电子凭证的开证方法、数据交互处理方法、装置和系统
WO2017012049A1 (zh) 电子凭证的收证方法、装置和系统

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: 15898563

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2993246

Country of ref document: CA

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205N DATED 03/04/2018)

122 Ep: pct application non-entry in european phase

Ref document number: 15898563

Country of ref document: EP

Kind code of ref document: A1