WO2008089684A1 - Method and system for security authenticating through short message in communication terminal - Google Patents

Method and system for security authenticating through short message in communication terminal Download PDF

Info

Publication number
WO2008089684A1
WO2008089684A1 PCT/CN2008/070123 CN2008070123W WO2008089684A1 WO 2008089684 A1 WO2008089684 A1 WO 2008089684A1 CN 2008070123 W CN2008070123 W CN 2008070123W WO 2008089684 A1 WO2008089684 A1 WO 2008089684A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
account
communication terminal
short message
information
Prior art date
Application number
PCT/CN2008/070123
Other languages
English (en)
French (fr)
Inventor
Leiming Yuan
Chengang Wu
Original Assignee
Alibaba Group Holding Limited
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 Alibaba Group Holding Limited filed Critical Alibaba Group Holding Limited
Priority to US12/448,967 priority Critical patent/US8055558B2/en
Priority to EP08700780.3A priority patent/EP2128808A4/en
Priority to JP2009546635A priority patent/JP5241736B2/ja
Publication of WO2008089684A1 publication Critical patent/WO2008089684A1/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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • 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/04—Payment circuits
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/105—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems involving programming of a portable memory device, e.g. IC cards, "electronic purses"
    • 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/26—Debit schemes, e.g. "pay now"
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G06Q20/3255—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks using mobile network messaging services for payment, e.g. SMS
    • 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/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18—Service support devices; Network management devices
    • H04W88/182—Network node acting on behalf of an other network entity, e.g. proxy

Definitions

  • the present invention relates to a secure authentication technique for information, and more particularly to a method and system for secure authentication of a communication terminal through short messages.
  • an account payment method is to use a communication terminal to perform security authentication and complete payment through short messages.
  • the method fully utilizes the huge number of users of communication terminals (including mobile phones, PHS or other devices with short message interaction functions), and the expansion of the number of bank card issuances, and binds a bank account or a third-party virtual account through the communication terminal.
  • the communication terminal is used to send an SMS (Short Messaging Service) short message to a specific short message service number for transfer, shopping, and the like.
  • SMS Short Messaging Service
  • FIG. 1 it is a schematic diagram of current communication terminal performing security authentication by using a short message.
  • the user first uses the short message interaction function of the communication terminal 101 to input important information such as the payee account, the payment amount, and the payment password, and sends the information to the short message interaction system 102 in a specific format.
  • the short message interaction system 102 extracts the key information in the received short message, including the communication terminal number, the payee account, the payment amount, the payment password and the like, and finds a binding relationship with the communication terminal number.
  • the payment account, and then the payment account, the payee account, the payment amount, the payment password and the like are continuously transmitted to the payment system 103.
  • the payment system 103 transfers the payment amount from the user payment account to the payee account, and returns the operation information to the user.
  • the biggest bottleneck for the communication terminal to perform SMS payment is the security problem.
  • the current short message interaction system 102 is usually represented by an SP (Service Provider), and the short message interaction is in a clear format (unencrypted data format), when the user inputs the transfer information, the short message information will be in clear text.
  • SP Service Provider
  • the form is sent, and the short message information sent by the user is stored in the plaintext form on the user's communication terminal, so the user's payment information may be dangerous in the following two steps:
  • the first is that when the proxy SP forwards the short message, since the short message content is extracted by the proxy SP party, if the proxy SP leaks important information such as the payment account, the payment password, the payee account, and the payment amount to others, the huge amount of the payment user will be caused.
  • the current SMS gateway has stability problems, and the loss rate and delay rate of the short message are relatively high.
  • the user may not receive the successful payment of the short message in time, causing the user to continuously initiate the transaction, or the short message system after the waiting time is reached. Send, causing the user to pay twice or even three times for a transaction.
  • the technical problem to be solved by the present invention is to provide a method and a system for a communication terminal to perform security authentication through short messages, so as to solve the security problem that the short message in the short message payment mode is easily leaked by the proxy SP, and the user repeats due to the short message loss and delay.
  • the problem of payment is to provide a method and a system for a communication terminal to perform security authentication through short messages, so as to solve the security problem that the short message in the short message payment mode is easily leaked by the proxy SP, and the user repeats due to the short message loss and delay.
  • the present invention provides a method for a communication terminal to perform security authentication by using a short message, including:
  • the communication terminal sends a short message payment request to the payment system via SP1, the request including the payee account identification and the payment amount;
  • the payment system creates a payment record corresponding to the request, and sends the verification information to the communication terminal via the SP2; wherein the verification information includes the payee account identifier and the payment amount;
  • the communication terminal After confirming that the payee account identifier and the payment amount in the verification information are correct, the communication terminal
  • SP2 replies with confirmation information to the payment system
  • the payment system performs a corresponding payment operation based on the payment record.
  • the method further includes: when the payment system sends the verification information to the communication terminal via the SP2, randomly selecting one of the plurality of SP2s.
  • the method further includes: generating a record number when the payment system creates the payment record, and including the sending of the verification information; and the confirmation information returned by the communication terminal is the record number.
  • the record number is formed by combining any number of English letters or numbers, and is randomly generated each time.
  • the method further includes: the payment system checking whether the account corresponding to the communication terminal and the payee account identifier exists in the established account information, and if yes, creating a payment record.
  • the account identifier is an account number, or a payee communication terminal number, an email address, an account owner name, and an ID card number having a binding relationship with the account number; the verification letter further includes: a payment system
  • the operation result is returned to the communication terminal via SP1 or SP2, and the payee communication terminal having a binding relationship with the payee account number.
  • the present invention also provides a system for performing security authentication by a communication terminal by using a short message, comprising: a first short message interaction subsystem, configured to receive a short message payment request sent by the communication terminal, and forward the request to the account management subsystem; wherein the request Including the payee account identification and payment amount;
  • An account management subsystem configured to create a payment record corresponding to the payment request, and send verification information to the second short message interaction subsystem, where the verification information includes a payee account identifier and a payment amount; and receives the corresponding After confirming the information, the corresponding payment operation is performed according to the payment record.
  • a second short message interaction subsystem configured to receive the verification information, and forward the information to the communication terminal; and after receiving the confirmation message that the communication terminal confirms the payee account identifier and the payment amount in the verification information, forward the Account Management Subsystem.
  • the second short message interaction subsystem is configured to be multiple, and when the account management subsystem sends the verification information to the second short message interaction subsystem, one of them is randomly selected.
  • the account management subsystem includes: a database, configured to store account information, and a binding relationship between the communication terminal and the account information; a payment processing unit, configured to create a payment record corresponding to the communication terminal, and generate a record number;
  • a payment processing unit configured to create a payment record corresponding to the communication terminal, and generate a record number;
  • the authentication unit passes the authentication, the corresponding payment operation is performed according to the payment record;
  • the authentication unit is configured to send the record number in the verification information to the second short message interaction subsystem, and if the received confirmation information is The matching record number is passed.
  • the record number is formed by combining any number of English letters or numbers, and is randomly generated each time.
  • the account management subsystem further includes: an account checking unit, configured to check whether there is an account corresponding to the communication terminal and the payee account identifier in the account information set up by the database, and if yes, trigger the payment processing unit to create a payment recording.
  • the account identifier is a payee account number, or a communication terminal number, an email address, an account owner name, and an ID card number having a binding relationship with the account number; and the verification letter is related to the prior art.
  • the present invention has the following advantages:
  • the short message between the communication terminal and the payment system adopts the two-channel (SP1 and SP2) asynchronous transmission mechanism to solve the security problem in the transmission of short message plaintext.
  • the SMS information is leaked on the proxy SP1 side, the payee account identifier and the payment amount in the short message content are changed to their own account identifier and amount, and after the payment system creates the payment record, it also needs to return the check through the proxy SP2 side.
  • the information if the user finds that the payee account identifier and the payment amount are incorrect, the confirmation information will not be sent, and the payment system cannot process the payment, so the SMS information can be secured on the SP1 side.
  • the proxy SP2 party leaks the short message information, the payee account identifier and the payment amount in the short message content are changed to their own account identification and amount, and directly reply to the payment system, since the payment record has been created, the reply The SMS is used to confirm that the created payment can be executed, so the SMS will be tampered with on the SP2 side and will not affect the correct payment processing.
  • a plurality of agents SP2 are set, and each time the payment system sends the verification information to the user through the SP2, one of the random selections can also ensure the security in the transmission of the plaintext plaintext. Because if SP1 and any of the SP2 servers are controlled at the same time, the probability of randomly selecting the controlled SP2 is small, so illegal payment cannot be successful. Even in the case where SP1 and all SP2 servers are controlled at the same time, since the illegal person must create account information in the payment system to complete the payment, the illegal personnel information can be quickly found.
  • the dual channel mechanism also solves the problem of SMS duplicate payment. If the short message sent by the user is resent by himself or the system due to loss or delay, the payment system will create multiple payment records for the same payment request, and the user will receive multiple verification messages, so the user can clearly Know the number of times you send a text message to cancel the double payment.
  • the record number randomly generated when the payment record is created is sent to the user, and as the confirmation information returned by the user, on the one hand, the user can more clearly identify the multiple duplicate payment information corresponding to the same payment, and on the other hand, it is convenient.
  • the payment system confirms the payment operation. Moreover, in the preferred embodiment of the present invention, any two of the 26 English letters are selected and arranged into a record number, so that the user can operate the reply and is simple and convenient.
  • FIG. 1 is a schematic diagram of a communication terminal performing security authentication by using a short message in the prior art
  • FIG. 2 is a flowchart of security authentication of a short message payment method according to an embodiment of the present invention
  • FIG. 3 is a structural diagram of a security authentication system for a short message payment method according to an embodiment of the present invention.
  • the present invention adopts a two-channel asynchronous transmission mechanism, and sets an SP server in two SP parties, and the short message information between the communication terminal and the payment system is transmitted through the SP1 plaintext, and is paid by SP2. Authentication, ensuring the security of SMS payments and avoiding duplicate payments.
  • the communication terminal utilized by the payer includes a mobile phone, a PHS or other device having a short message interaction function
  • the payment system may be set by a financial institution (such as a bank) or a third party providing a payment service, SP1 and SP2.
  • the proxy server is set up by different SMS service providers.
  • the user who uses the short message payment method sets up an account in advance in the payment system (the third party providing the payment service is a virtual account), registers the communication terminal number, and establishes a binding relationship between the communication terminal number and the account information.
  • the account information includes the account number, personal information (name, address, etc.) of the account owner, account fund information, and the like.
  • Step 201 The payment party sends a payment request to the SP1 by using the communication terminal in the form of a short message, where the request includes information such as a communication terminal number, a payee user identifier, and a payment amount for sending the short message.
  • the payee user identifier may be an account number of the payee in the payment system, or may be a communication terminal number, or an email address (Email), or a payee name, or identity bound to the account number. Information such as the license number that uniquely identifies the user.
  • the paying party sends the short message instruction "payee mobile phone number / email + amount" to the first SP (referred to as SP1) special service number 1000 (here, the example is not the actual special service number).
  • Step 202 After receiving the short message payment request sent by the communication terminal, the SP1 extracts the communication terminal number, and uses the HTTPS protocol (Hypertext Transfer Protocol Secure Hypertext Transfer Protocol) to include the content of the “payee mobile phone number/email + amount”.
  • Short message and payment party communication terminal number Send to the payment system.
  • the present invention does not limit the protocol used by short messages in network transmission.
  • Step 203 The payment system creates a payment record for the payer according to the short message instruction and according to the binding relationship between the payment party communication terminal number and the account information.
  • a record number is also generated when the payment record is created, for example, ABC12345, which represents the transaction number created by the mobile phone short message payment. The use of the record number is detailed below.
  • the record number is a string of Arabic numerals. If the user is allowed to reply to the actual record number, the text message input is error-prone and the operation is cumbersome.
  • the payment system first checks whether the payer and the payee have the account information before receiving the payment request to create the payment record.
  • the account information that is set up there is account information bound to the payee's mobile phone number/Email, and the account information bound to the payer's communication terminal number, before the transfer funds can be received; otherwise, the payment system returns to the payer's communication terminal. Information that the payee account does not exist.
  • Step 204 The payment system performs payment authentication by sending verification information to the payer.
  • the "payee name + record number + payment amount" and the payer communication terminal number are transmitted to the second SP (referred to as SP2) via the HTTPS protocol.
  • the payee name may be extracted from the user personal information in the payee account information, or may be extracted from the short message content including the payee name.
  • the payer usually needs to know the name of the payee, so from the perspective of user experience, the payee name is sent to the payer, but this implementation does not limit the information of other identifiable payee status.
  • the name of the party is referred to as SP2
  • the payee name + record number + payment amount and the payer communication terminal number
  • the payee name may be extracted from the user personal information in the payee account information, or may be extracted from the short message content including the payee name.
  • the payer usually needs to know the name of the payee, so from the perspective of user experience, the payee name is sent to the payer,
  • the SP2 is provided in plurality, and each time the payment system sends the verification information to the payer through the SP2, one of the randomly selected ones is randomly selected, and the uncertainty of the SP2 is increased.
  • SP1 is only set one, because SP1 not only provides the function of sending and receiving short messages, but also provides SMS payment function for registered users, that is, setting the SP server corresponding to the special service number, and SP2 can realize the sending and receiving of short messages.
  • step 205 the SP2 forwards the short message "payee name + record number + payment amount" to the communication terminal number of the payer.
  • step 206 After receiving the verification information, the payment party confirms that the name of the payee in the verification information and the payment amount are all requirements of the user, and then returns the confirmation information to SP2.
  • the record number is used as the confirmation information, on the one hand, the user can more clearly recognize the plurality of duplicate payment information corresponding to the same payment, and on the other hand, the payment system can confirm the payment operation.
  • Step 207 The SP2 forwards the confirmation information (such as a record number) to the payment system through the HTTPS protocol.
  • Step 208 The payment system receives the record number of the payer, and compares with the record number sent in step 205. If the match is complete, the check succeeds and the corresponding payment operation is performed. According to the payment request, the payment amount in the payer's account is deducted, and the payment amount is transferred to the payee account; if the payer's account balance is insufficient, the short message is sent to the payer to indicate the insufficient balance information.
  • Step 209 The payment system completes the payment operation, and sends the transfer result information to the SP1.
  • Step 210 The SP1 forwards the transfer result information to the communication terminal number of the payer and the payee, and notifies the paying party that the transaction has been successfully completed.
  • the payment system can also notify the payer and the payee via SP2.
  • the payer sends a payment instruction to SP1, SP1 forwards the payment instruction to the payment system, and the payment system directly completes the payment. If the system resends due to a delay, or if the user does not receive a successful SMS and the user sends the payment instruction again, the user may pay twice for the same transaction.
  • the payment system only creates two transactions. The transaction is not completed before the user confirms, and the user sends two transaction messages that need to be confirmed. The user can clearly understand the number of transactions, if With multiple payments due to delays and retransmissions, the user can choose to cancel the transaction.
  • the above embodiment preferably transmits the record number as a part of the verification information to the user, and in the case of generating a plurality of payment records for the same payment, the user can more clearly recognize the duplicate payment by the different record number. Moreover, by simply replying to the record number, the payment system can know which payment was created and can be executed. In summary, the use of record numbers makes the operation of the entire certification process simple.
  • the dual channel mechanism since the dual channel mechanism is adopted, the security of the short message payment process can be well ensured, so the payment system allows the payer to perform the payment operation without inputting the payment password, thereby avoiding the payment password being The short message was stolen during transmission.
  • the present embodiment is stored in the payment system, and the risk that the proxy SP is illegally controlled to leak the user account information can be reduced.
  • the present invention also provides a system for implementing the above-described process.
  • FIG. 3 it is a structural diagram of a secure authentication system for a short message payment method according to an embodiment of the present invention.
  • the system includes a first short message interaction subsystem 302, a second short message interaction subsystem 303, and an account management subsystem 304.
  • the communication terminal 301 in the figure is a terminal device having a short message transceiving function, such as a mobile phone, a PHS, a PDA (PDA), etc., and a registered user sends a payment request to a specific short message service number by inputting a short message of a specific format.
  • a specific short message service number For example, the payer sends a text message "Payee Phone Number / Email + Amount" to the special service number **** of the first short message interaction subsystem 302.
  • the request includes information such as a communication terminal number for sending a short message, a payee user identification, and a payment amount.
  • the payee user identifier may be an account number of the payee, or may be a communication terminal number bound with the account number, or an email address (Email), or a payee name, or an ID card number, etc.
  • a letter that uniquely identifies the user The first short message interaction subsystem 302 and the second short message interaction subsystem 303 are configured to implement the short message interaction function with the communication terminal 301 through the HTTPS protocol, and are configured by different short message service providers.
  • the dual-channel solution proposed for the security issue of payment replaces the original single-channel SMS.
  • the first short message interaction subsystem 302 is configured to forward the short message payment request sent by the communication terminal 301 to the account management subsystem 304
  • the second short message interaction subsystem 303 is used to forward the account management subsystem 304 to the communication terminal 301.
  • a plurality of second short message interaction subsystems 303 are provided, and the account management subsystem 304 randomly selects one of the forwarding verification information to increase the uncertainty of the selection of the second short message interaction subsystem 303, thereby enhancing the security of the short message payment. Sex. As previously mentioned, it is to prevent the first short message interaction subsystem 302 and the second short message interaction subsystem 303 from being simultaneously controlled. However, the first short message interaction subsystem 302 is only provided one, because the first short message interaction subsystem 302 provides the communication terminal number management of the registered short message payment service, corresponding to a short message service number.
  • the Account Management Subsystem 304 is used to handle various account services, either by a financial institution (such as a bank) or by a third party providing a payment service. If it is provided by a third party, the user account set by the system is a virtual account.
  • the account management subsystem 304 includes a database 305, an account verification unit 306, a payment processing unit 307, and an authentication unit 308.
  • the user using the SMS payment method needs to apply for a user account in the account management subsystem 304, and the account information is stored in the database 305.
  • the database 305 also stores a binding mapping relationship between the account information and the communication terminal number, thereby reducing the risk of leakage of account information.
  • the account verification unit 306 is a preferred setting of the present embodiment for searching the database 305 to check whether the SMS payer and the payee account are present. In order to prevent illegal tampering with the payee, if the tamper-receiving payee does not apply for an account in the account management subsystem 304, the short message payment cannot be performed, and the prompt information is returned to the communication terminal that sent the short message. If the account verification unit 306 finds the payer and payee accounts in the database, the payment processing unit 307 is triggered. The payment processing unit 307 is configured to create a payment record corresponding to the communication terminal number, and then wait for the authentication unit 308 to confirm whether the payment authentication is passed.
  • the payment processing can be performed securely, and the processing result is passed through the first short message interaction subsystem. 302 or the second short message interaction subsystem 303 sends the communication terminal to the payer and the payee; otherwise, if the payment may be falsified, the created payment record is not executed, and the payer's account is guaranteed. Safety.
  • the payment processing unit 307 performs a specific payment processing procedure: the payment processing unit 307 searches the payment account bound to the payer communication terminal number in the database 305, determines whether the account balance is greater than or equal to the payment amount, and if so, deducts the payment from the payment account. The amount, then transfer the payment amount to the payee account; if the account balance is insufficient, notify the payer.
  • the authentication unit 308 is used to ensure the security of the payment process.
  • the second short message interaction subsystem 303 sends the verification information to the payment party communication terminal. If the payment party's confirmation information is received, the payment processing unit 307 is triggered to complete the payment.
  • the verification information includes a record number generated by the payment processing unit 307 when the payment record is created, a payee name extracted from the account information of the database 305, and a payment amount. After the payer receives the short message and confirms that the payee name and the payment amount are correct, the record number is returned to the authentication unit 308 through the second short message interaction subsystem 303.
  • the authentication unit 308 checks whether the record number in the reply message matches the past transmission. If it is completely correct, the authentication is passed and the payment can be made securely.
  • the record number is a string of letters or numbers.
  • the coverage of the short message is very large, and the method and system provided by the above embodiments can avoid the security problem of the plaintext of the short message, avoid the problem of repeated transactions caused by the stability and delay of the short message, and bring the user's operation simple. Payment effect.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Description

通信终端通过短信息进行安全认证的方法及系统
本申请要求于 2007 年 1 月 23 日提交中国专利局、 申请号为 200710002708.0、 发明名称为"通信终端通过短信息进行安全认证的方法及系 统"的中国专利申请的优先权， 其全部内容通过引用结合在本申请中。
技术领域
本发明涉及信息的安全认证技术，特别是涉及通信终端通过短信息进行安 全认证的方法及系统。
背景技术
在许多业务应用中信息安全问题十分重要， 尤其是在金融领域，账户支付 的安全性一直是人们关注的问题。 目前，一种账户支付方法是利用通信终端通 过短信息进行安全认证并完成支付。 所述方法充分利用通信终端 （包括手机、 小灵通或者其他具有短信息交互功能的设备 )用户的庞大数量， 以及银行卡发 行数量的扩大，通过通信终端绑定一个银行账户或者第三方虚拟账户， 然后利 用所述通信终端向一个特定的短信特服号发送 SMS ( Short Messaging Service, 短信服务）短信进行转账、 购物等。
参照图 1 , 是目前通信终端通过短信进行安全认证的示意图。 用户首先利 用通讯终端 101的短信交互功能， 输入收款方账户、 支付金额、 支付密码等重 要信息， 以特定格式发送给短信息互动系统 102。 短信息互动系统 102提取收 到的短信中的关键信息， 包括发送短信的通信终端号码、 收款方账户、 支付金 额、支付密码等信息，查找到与所述通信终端号码建立了绑定关系的支付账户， 再将支付账户、 收款方账户、 支付金额、 支付密码等信息继续传送给支付系统 103。 支付系统 103收到支付请求， 并确认用户输入的支付密码正确后， 将支 付金额从用户支付账户转入收款方账户中， 并向用户返回操作信息。
在上述过程中 , 通信终端进行短信支付面临最大的瓶颈就是安全性问题。 因为目前的短信息互动系统 102通常由 SP( Service Provider,短信服务提供商 ) 代理， 而短信息交互都采用明码格式（未加密的数据格式）， 用户在输入转账 信息时，短信信息将采用明文的形式发送， 而且在用户的通信终端上会以明文 形式存贮用户发送的短信信息，所以用户的支付信息会在以下两个环节出现危 险： 第一是在代理 SP转发短信时， 由于短信内容由代理 SP方提取， 如果代 理 SP向其他人泄漏支付账户、 支付密码、 收款方账户、 支付金额等重要信息， 则会造成支付用户的巨大损失，有人可能会将收款方账户和支付金额更改为自 己的账户和更多的金额，或者利用支付密码直接从支付账户中提取现金； 第二 是在用户的通信终端被其他人查看了已发短信时，用户支付密码、收款方账户、 支付金额等重要信息同样容易泄漏， 被他人非法利用。
其次， 现在的短信网关存在稳定性问题， 短信的丢失率和延迟率比较高， 用户可能由于不能及时接收到支付成功的短信，导致用户不断地发起交易，或 者短信系统到达等待时间后进行短信重发，造成用户为一笔交易支付两次、甚 至三次的费用。
发明内容
本发明所要解决的技术问题是提供通信终端通过短信息进行安全认证的 方法及系统， 以解决目前短信支付方式中短信内容易被代理 SP泄漏的安全问 题， 以及由于短信丢失和延时造成用户重复支付的问题。
为解决上述技术问题，本发明提供了通信终端通过短信息进行安全认证的 方法， 包括：
通信终端经由 SP1向支付系统发送短信支付请求，所述请求包括收款方账 户标识和支付金额；
支付系统对应所述请求创建支付记录，并经由 SP2向所述通信终端发送校 验信息； 其中， 所述校验信息包括收款方账户标识和支付金额；
通信终端确认所述校验信息中的收款方账户标识和支付金额正确后 ,经由
SP2向支付系统回复确认信息；
支付系统根据所述支付记录执行相应的支付操作。
优选的， 还包括： 支付系统经由 SP2向所述通信终端发送校验信息时， 从 多个 SP2中随机选取一个。
还包括： 支付系统创建支付记录时生成记录编号， 并包含在所述校验信息 中发送； 通信终端返回的确认信息为所述记录编号。
优选的， 所述记录编号由任意个数的英文字母或数字排列组合而成，每次 随机生成。 优选的， 支付系统创建支付记录之前， 还包括： 支付系统检查设立的账户 信息中是否存在与所述通信终端和收款方账户标识对应的账户， 若存在， 则创 建支付记录。
其中， 所述账户标识为账户号码，或者是与账户号码具有绑定关系的收款 方通信终端号码、 电子邮件地址、 账户所有者姓名、 身份证号码； 所述校验信 还包括： 支付系统经由 SP1或 SP2向所述通信终端， 以及与收款方账户 号码具有绑定关系的收款方通信终端返回操作结果。
本发明还提供了通信终端通过短信息进行安全认证的系统， 包括： 第一短信息交互子系统， 用于接收通信终端发送的短信支付请求， 并转发 给账户管理子系统； 其中， 所述请求包括收款方账户标识和支付金额；
账户管理子系统，用于对应所述支付请求创建支付记录， 并向第二短信息 交互子系统发送校验信息， 所述校验信息包括收款方账户标识和支付金额； 并 收到对应的确认信息后， 根据所述支付记录执行相应的支付操作。
第二短信息交互子系统， 用于接收所述校验信息， 并转发给通信终端； 接 收所述通信终端确认校验信息中的收款方账户标识和支付金额正确的确认信 息后， 转发给账户管理子系统。
优选的， 第二短信息交互子系统设置多个， 所述账户管理子系统向第二短 信息交互子系统发送校验信息时， 从中随机选取一个。
优选的， 所述账户管理子系统包括： 数据库， 用于存储账户信息， 以及通 信终端与账户信息的绑定关系； 支付处理单元， 用于对应所述通信终端创建支 付记录， 并生成记录编号； 当认证单元通过认证， 根据所述支付记录执行相应 的支付操作； 认证单元， 用于将所述记录编号包含在校验信息中发送给第二短 信息交互子系统， 若收到的确认信息为匹配的记录编号， 则认证通过。
优选的， 所述记录编号由任意个数的英文字母或数字排列组合而成，每次 随机生成。
优选的， 账户管理子系统还包括： 账户核对单元， 用于检查数据库设立的 账户信息中是否存在与所述通信终端和收款方账户标识对应的账户， 若存在， 则触发支付处理单元创建支付记录。 其中， 所述账户标识为收款方账户号码，或者是与账户号码具有绑定关系 的通信终端号码、 电子邮件地址、 账户所有者姓名、 身份证号码； 所述校验信 与现有技术相比， 本发明具有以下优点：
首先， 通信终端与支付系统之间的短信息， 采用双通道（SP1和 SP2 )异 步传输机制， 解决了短信息明文传输过程中的安全问题。 第一， 如果在代理 SP1方泄漏短信信息，将短信内容中的收款方账户标识和支付金额更改为自己 的账户标识和金额，支付系统创建支付记录后，还需要通过代理 SP2方返回校 验信息， 用户发现收款方账户标识和支付金额不正确， 就不会发送确认信息， 支付系统就不能进行支付处理，因此能够保证短信信息在 SP1方的安全。第二， 如果在代理 SP2方泄漏短信信息，将短信内容中的收款方账户标识和支付金额 更改为自己的账户标识和金额，并直接回复给支付系统，由于支付记录已创建， 所述回复的短信是用来确认已创建的支付可以执行，所以短信在 SP2方被篡改 也不会影响正确的支付处理。
其次，设置多个代理 SP2,支付系统每次通过 SP2向用户发送校验信息时， 从中随机选取一个， 也能保证短信息明文传输过程中的安全性。 因为如果 SP1 和其中任意一个 SP2的服务器同时被控制， 则随机选择被控制的 SP2的几率 很小， 因此非法支付不能成功。 即使在 SP1和所有的 SP2服务器都被同时控 制的情况下， 由于非法人员必须在支付系统创建账户信息才能完成支付，所以 可以很快查找到非法人员信息。
再次， 采用双通道机制还解决了短信重复支付的问题。如果用户发送的短 信由于丢失或延迟而由自己或系统重发支付请求，则支付系统会对同一个支付 请求创建多次支付记录， 用户就会收到多次校验信息， 因此用户可以清楚地了 解自己发送支付短信的次数， 从而取消重复支付即可。
最后，将创建支付记录时随机生成的记录编号发送给用户， 并作为用户返 回的确认信息，一方面能够使用户更清晰地识别出对应同一次支付的多个重复 支付信息，另一方面也方便支付系统对支付操作的确认。而且，本发明优选的， 选取 26个英文字母中的任意两个字母， 排列组合成记录编号， 使用户在回复 确认信息时操作简单便捷。 附图说明
图 1是现有技术中通信终端通过短信进行安全认证的示意图；
图 2是本发明实施例所述短信支付方式的安全认证流程图；
图 3是本发明实施例所述短信支付方式的安全认证系统结构图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂， 下面结合附图和 具体实施方式对本发明作进一步详细的说明。
针对短信支付方式中的安全问题和重复支付问题，本发明采用双通道异步 传输机制， 在两个 SP方设置 SP服务器， 通信终端和支付系统间的短信信息 通过 SP1 明文传输， 并通过 SP2进行支付认证， 保证短信支付的安全性和避 免重复支付。
具体实施过程参照图 2， 是本发明实施例所述短信支付方式的安全认证流 程图。 图中， 付款方利用的通信终端包括手机、 小灵通或者其他具有短信息交 互功能的设备， 支付系统可以由金融机构（如银行）设置， 也可以由提供支付 服务的第三方设置， SP1和 SP2由不同的短信服务提供商设置代理服务器。使 用短信支付方式的用户预先在支付系统设立账户（提供支付服务的第三方为虚 拟账户）， 并注册通信终端号码， 建立通信终端号码与账户信息的绑定关系。 其中， 账户信息包括账户号码、 账户所有人的个人信息（姓名、 住址等）、 账 户资金信息等。
步骤 201 , 付款方利用通信终端以短信形式向 SP1发送支付请求， 所述请 求中包含发送短信的通信终端号码、收款方用户标识和支付金额等信息。其中 , 所述收款方用户标识可以是收款方在支付系统的账户号码 ,也可以是与账户号 码绑定的通信终端号码、 或电子邮件地址（Email )、 或收款方姓名、 或身份证 号码等唯一标识用户身份的信息。 本实施例中， 付款方发送短信指令"收款方 手机号码/ Email +金额"到第一个 SP (简称 SP1 )的特服号 1000 (此处为示例， 并不是实际的特服号）。
步骤 202， SP1接收通信终端发来的短信支付请求后，提取通信终端号码， 通过 HTTPS协议 ( Hypertext Transfer Protocol Secure安全超文本传输协议）， 将包含 "收款方手机号码/ Email +金额"内容的短信息和付款方通信终端号码转 发给支付系统。 本发明不限定短信息在网络传输中所使用的协议。 步骤 203， 支付系统根据所述短信指令， 并根据付款方通信终端号码与账 户信息的绑定关系， 为付款方创建一个支付记录。 优选的， 创建支付记录时还 生成记录编号， 例如 ABC12345, 表示手机短信支付创建的交易编号。 所述记 录编号的用途在下面内容再详述。
在实际应用中， 所述记录编号是一串阿拉伯数字，如果让用户回复实际的 记录编号， 短信输入易出错， 操作烦瑣。 本实施例优选的， 用 26个英文字母 中的任意 2个字母排列组合来代表当天的交易，可以代表 26x26 = 676个交易。 由于短信支付主要是小额支付，一个用户不可能每天做 676个交易， 所以采用 2个字母组合来代表交易能够简化记录编号， 使用户操作简单。
本发明实施例优选的，为了避免 SP1方被非法控制而泄漏付款方发送的短 信内容， 支付系统收到支付请求创建支付记录前，先检查付款方和收款方是否 设有账户信息，如果所设立的账户信息中存在与收款方手机号码 /Email绑定的 账户信息，以及与付款方通信终端号码绑定的账户信息，才可以接收转账资金； 否则， 支付系统向付款方的通信终端返回收款方账户不存在的信息。
步骤 204， 支付系统通过向付款方发送校验信息来进行支付认证。 本实施 例中， 将"收款方姓名 +记录编号 +支付金额"以及付款方通信终端号码， 通过 HTTPS协议发送给第二个 SP (简称 SP2 )。 其中， 所述收款方姓名可以从收款 方账户信息中的用户个人信息中提取，也可以从包含收款方姓名的短信内容中 提取。 在实际应用中， 付款方通常需要知道收款方姓名， 所以从用户体验角度 考虑，将收款方姓名发送给付款方，但是本实施并不限制将其他可标识收款方 身份的信息替代收款方姓名。
优选的， 为保证短信息明文传输过程中的安全性， SP2设有多个， 支付系 统每次通过 SP2向付款方发送校验信息时， 都是随机选取其中一个， 增加 SP2 的不确定性， 从而加强短信支付的安全性。 而 SP1只设置一个， 因为 SP1不 仅提供短信息的收发功能，还为注册的用户提供短信支付功能， 即设置与特服 号对应的 SP服务器， 而 SP2能够实现短信息的发送和接收即可。
步骤 205, SP2转发短信"收款方姓名 +记录编号 +支付金额"到付款方的 通信终端号码。 步骤 206， 付款方收到校验信息， 确认校验信息中的收款方姓名、 支付金 额都是自己的要求后， 回复确认信息到 SP2。 本实施例中， 将记录编号作为确 认信息，一方面能够使用户更清晰地识别出对应同一次支付的多个重复支付信 息， 另一方面也方便支付系统对支付操作的确认。
步骤 207, SP2通过 HTTPS协议转发所述确认信息（如记录编号 )给支 付系统。
步骤 208， 支付系统收到付款方的记录编号， 与步骤 205发送过去的记录 编号进行比对， 若完全匹配， 则校验成功， 执行相应的支付操作。 根据支付请 求， 扣除付款方账户中的支付金额， 再将支付金额转入收款方账户； 如果付款 方账户余额不足， 则向付款方发送短信息提示余额不足信息。
步骤 209, 支付系统完成支付操作， 将转账结果信息发送给 SP1。
步骤 210， SP1将转账结果信息转发给付款方和收款方的通信终端号码， 通知支付双方已成功完成交易。 当然，支付系统也可以通过 SP2通知付款方和 收款方。
上述流程能够解决短信支付中的安全问题和重复支付问题，现以手机短信 支付为例进行说明：
对于安全问题， 虽然短信在发送的途中全部采用明文传输，但是无论黑客 在哪个环节截获明文的短信都不能完成交易，本方案杜绝了明文传输交易短信 所带来的巨大安全隐患：
分析一：如果黑客在短信从用户到 SP1处截获用户的交易短信，并且将收 款方改成自己的手机号码和金额，支付系统在创建交易时会先检查收款方的支 付系统账户， 如果没有黑客的账户， 就不能完成支付。 如果黑客注册有支付系 统账户， 支付系统通过 SP2发送交易认证短信， 用户收到交易认证短信后，发 现收款人的姓名和金额不对， 就不会发送确认信息， 因此黑客就不会成功。
分析二：如果黑客从 SP2处盗取了用户的交易信息，把收款方更改成自己 的姓名直接回复给支付系统， 由于回复的短信只能确认已经创建交易的付款， 所以黑客的盗取没有作用。
分析三： 如果黑客同时控制了 SP1和 SP2的服务器， 支付系统发送校验 信息时随机从多个备份的 SP2中选取，黑客依然不能完成交易。除非黑客可以 同时控制支付系统所有的代理 SP， 即使这样， 由于黑客必须在支付系统中创 建账户信息才能完成提现， 所以很快就可以找到黑客。
对于重复支付问题， 如果没有双通道，付款方发送付款指令到 SP1，SP1转 发付款指令到支付系统， 支付系统直接完成支付。 如果由于延迟， 系统重发或 者用户迟迟没有收到成功短信而用户自己再次发送付款指令，用户就可能对于 同一笔交易付两次款。 但是通过双通道， 支付系统只是创建了两个交易， 在用 户确认前并没有完成交易， 并且给用户下发了两个需要确认的交易短信，用户 可以清楚地了解到自己交易的次数， 如果是延迟、 重发造成的多次支付， 用户 就可以选择取消交易。
而且，上述实施例优选地，将记录编号作为校验信息的一部分发送给用户， 针对同一个支付生成多个支付记录的情况，用户通过不同的记录编号就可以更 加清楚地识别出重复的支付。 并且， 用户通过简单回复记录编号， 支付系统就 能够获知创建的哪一个支付可以执行。 总之，记录编号的使用使得整个认证过 程的操作变得简单。
本发明上述实施例处理流程中， 由于采用了双通道机制， 能够很好地保证 短信支付过程的安全性， 所以支付系统允许付款方不必输入支付密码， 就能执 行支付操作， 从而避免支付密码在短信息传输过程中被窃取。 而且， 与将通信 终端号码与账户信息的绑定映射关系保存在代理 SP方相比， 本实施例保存在 支付系统中， 能够减少代理 SP被非法控制而泄漏用户账户信息的风险。
本发明还提供了实现上述流程的系统， 参照图 3， 是本发明实施例所述短 信支付方式的安全认证系统结构图。 所述系统包括第一短信息交互子系统 302、 第二短信息交互子系统 303、 账户管理子系统 304。
图中通信终端 301是具有短信息收发功能的终端设备， 如手机、 小灵通、 PDA (掌上电脑）等， 注册用户通过输入特定格式的短信， 向一个特定的短信 特服号发送支付请求。 例如， 付款方发送短信指令 "收款方手机号码/ Email + 金额"到第一短信息交互子系统 302的特服号 ****。 所述请求包含发送短信的 通信终端号码、 收款方用户标识和支付金额等信息。 其中， 所述收款方用户标 识可以是收款方的账户号码， 也可以是与账户号码绑定的通信终端号码、或电 子邮件地址（Email )、 或收款方姓名、 或身份证号码等唯一标识用户身份的信 第一短信息交互子系统 302 和第二短信息交互子系统 303 用于通过 HTTPS协议实现与通信终端 301的短信息交互功能， 由不同的短信服务提供 商配置， 是本发明实施例为解决短信支付的安全问题而提出的双通道解决方 案，替代原来的单通道短信收发。所述第一短信息交互子系统 302用于转发通 信终端 301发送给账户管理子系统 304的短信支付请求，第二短信息交互子系 统 303用于转发账户管理子系统 304发送给通信终端 301的校验信息 ,以及通 信终端 301回复的确认信息。
优选的， 设置多个第二短信息交互子系统 303， 账户管理子系统 304随机 选择其中一个转发校验信息， 增加第二短信息交互子系统 303 选择的不确定 性， 从而加强短信支付的安全性。 如前所述， 是为防止第一短信息交互子系统 302和第二短信息交互子系统 303被同时控制。但是第一短信息交互子系统 302 只设置一个， 因为第一短信息交互子系统 302除实现短信收发功能，还提供注 册短信支付服务的通信终端号码管理， 对应一个短信特服号。
账户管理子系统 304用于处理各种账户业务， 可以由金融机构 （如银行） 提供， 也可以由提供支付服务的第三方设置。 如果是第三方提供， 则系统设置 的用户账户即为虚拟账户。 账户管理子系统 304包括数据库 305、 账户核对单 元 306、 支付处理单元 307和认证单元 308。
使用短信支付方式的用户需要在账户管理子系统 304申请用户账户 ,账户 信息保存在数据库 305中。 而且优选的，数据库 305中还保存了账户信息与通 信终端号码的绑定映射关系， 减少账户信息泄漏的风险。 当付款方利用通信终 端发送短信息后， 由第一短信息交互子系统 302 (转发支付短信）或第二短信 息交互子系统 303 (转发校验信息的确认短信）提取通信终端号码， 然后将通 信终端号码和短信内容转发给账户管理子系统 304, 账户管理子系统 304根据 数据库 305中的绑定关系， 对付款方和收款方账户进行支付处理。
账户核对单元 306是本实施例的优选设置， 用于搜索数据库 305， 检查短 信付款方和收款方账户是否存在。 为防止非法篡改收款方，如果篡改的收款方 在账户管理子系统 304没有申请账户， 则短信支付不能进行， 并向发送短信的 通信终端返回提示信息。 若账户核对单元 306在数据库中查找到付款方和收款方账户 ,则触发支付 处理单元 307。 所述支付处理单元 307用于对应通信终端号码创建一条支付记 录， 然后等待认证单元 308确认支付认证是否通过， 若通过， 则可以安全执行 支付处理，并将处理结果通过第一短信息交互子系统 302或第二短信息交互子 系统 303发送给付款方和收款方的通信终端； 否则，所述支付可能出现短信内 容被篡改的情况， 则不执行已创建的支付记录， 保证付款方账户的安全。
支付处理单元 307执行具体的支付处理过程是：支付处理单元 307查找数 据库 305中与付款方通信终端号码绑定的支付账户，判断账户余额是否大于等 于支付金额， 若是， 则从支付账户中扣除支付金额， 然后将支付金额转入收款 方账户； 若账户余额不足， 则通知付款方。
认证单元 308 用于保证支付过程的安全性， 通过第二短信息交互子系统 303向付款方通信终端发送校验信息， 若收到付款方的确认信息， 则触发支付 处理单元 307 完成支付。 本实施例优选的， 所述校验信息包括支付处理单元 307在创建支付记录时生成的记录编号， 从数据库 305的账户信息中提取的收 款方姓名， 以及支付金额。 付款方收到短信息， 确认收款方姓名和支付金额正 确后， 将记录编号再通过第二短信息交互子系统 303回复给认证单元 308。 认 证单元 308 查看回复信息中的记录编号是否与发送过去的相匹配， 若完全正 确， 则认证通过， 可以安全支付。
通常， 所述记录编号为一串字母或数字组合， 优选的， 本实施用 26个英 文字母中的任意 2个字母排列组合来代表当天的交易， 可以代表 26x26 = 676 个交易。 由于短信支付主要是小额支付， 一个用户不可能每天做 676个交易， 所以采用 2个字母组合来代表交易能够简化记录编号， 使用户操作简单。
目前， 短信使用的覆盖面非常大， 采用以上实施例提供的方法和系统， 既 可以避免短信明文的安全性问题，又可以避免因短信稳定和延迟造成的重复交 易问题， 并且带来用户操作简单的支付效果。
图 3所示系统中未伴述的部分可以参见图 2所示方法的相关部分，为了篇 幅考虑， 在此不再详述。
以上对本发明所提供的通信终端通过短信进行安全认证的方法及系统，进 述， 以上实施例的说明只是用于帮助理解本发明的方法及其核心思想； 同时， 对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围 上均会有改变之处。 综上所述， 本说明书内容不应理解为对本发明的限制。

Claims

权 利 要 求
1、 通信终端通过短信息进行安全认证的方法， 其特征在于， 包括： 通信终端经由 SP1向支付系统发送短信支付请求，所述请求包括收款方账 户标识和支付金额；
支付系统对应所述请求创建支付记录，并经由 SP2向所述通信终端发送校 验信息； 其中， 所述校验信息包括收款方账户标识和支付金额；
通信终端确认所述校验信息中的收款方账户标识和支付金额正确后 ,经由 SP2向支付系统回复确认信息；
支付系统根据所述支付记录执行相应的支付操作。
2、根据权利要求 1所述的方法， 其特征在于，还包括： 支付系统经由 SP2 向所述通信终端发送校验信息时， 从多个 SP2中随机选取一个。
3、 根据权利要求 1所述的方法， 其特征在于， 还包括： 支付系统创建支 付记录时生成记录编号， 并包含在所述校验信息中发送； 通信终端返回的确认 信息为所述记录编号。
4、 根据权利要求 3所述的方法， 其特征在于： 所述记录编号由任意个数 的英文字母或数字排列组合而成， 每次随机生成。
5、 根据权利要求 1所述的方法， 其特征在于， 支付系统创建支付记录之 前，还包括： 支付系统检查设立的账户信息中是否存在与所述通信终端和收款 方账户标识对应的账户， 若存在， 则创建支付记录。
6、根据权利要求 1所述的方法， 其特征在于： 所述账户标识为账户号码， 或者是与账户号码具有绑定关系的通信终端号码、 电子邮件地址、账户所有者 姓名、 身份证号码。
7、 根据权利要求 6所述的方法， 其特征在于： 所述校验信息中的收款方 账户标识为与收款方账户号码具有绑定关系的收款方姓名。
8、根据权利要求 1所述的方法， 其特征在于，还包括： 支付系统经由 SP1 或 SP2向所述通信终端，以及与收款方账户号码具有绑定关系的收款方通信终 端返回操作结果。
9、 通信终端通过短信息进行安全认证的系统， 其特征在于， 包括： 第一短信息交互子系统， 用于接收通信终端发送的短信支付请求， 并转发 给账户管理子系统； 其中， 所述请求包括收款方账户标识和支付金额； 账户管理子系统，用于对应所述支付请求创建支付记录， 并向第二短信息 交互子系统发送校验信息， 所述校验信息包括收款方账户标识和支付金额； 并 收到对应的确认信息后， 根据所述支付记录执行相应的支付操作。
第二短信息交互子系统， 用于接收所述校验信息， 并转发给通信终端； 接 收所述通信终端确认校验信息中的收款方账户标识和支付金额正确的确认信 息后， 转发给账户管理子系统。
10、根据权利要求 9所述的系统， 其特征在于： 第二短信息交互子系统设 置多个， 所述账户管理子系统向第二短信息交互子系统发送校验信息时，从中 随机选取一个。
11、根据权利要求 9所述的系统，其特征在于，所述账户管理子系统包括： 数据库， 用于存储账户信息， 以及通信终端与账户信息的绑定关系； 支付处理单元， 用于对应所述通信终端创建支付记录， 并生成记录编号； 当认证单元通过认证， 根据所述支付记录执行相应的支付操作；
认证单元，用于将所述记录编号包含在校验信息中发送给第二短信息交互 子系统， 若收到的确认信息为匹配的记录编号， 则认证通过。
12、 根据权利要求 11所述的系统， 其特征在于： 所述记录编号由任意个 数的英文字母或数字排列组合而成， 每次随机生成。
13、根据权利要求 11所述的系统， 其特征在于， 账户管理子系统还包括： 账户核对单元，用于检查数据库设立的账户信息中是否存在与所述通信终端和 收款方账户标识对应的账户， 若存在， 则触发支付处理单元创建支付记录。
14、根据权利要求 9所述的系统，其特征在于：所述账户标识为账户号码， 或者是与账户号码具有绑定关系的通信终端号码、 电子邮件地址、账户所有者 姓名、 身份证号码。
15、 根据权利要求 14所述的系统， 其特征在于： 所述校验信息中的收款 方账户标识为与收款方账户号码具有绑定关系的收款方姓名。
PCT/CN2008/070123 2007-01-23 2008-01-17 Method and system for security authenticating through short message in communication terminal WO2008089684A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US12/448,967 US8055558B2 (en) 2007-01-23 2008-01-17 Method and system for authentication via communication terminal using short message
EP08700780.3A EP2128808A4 (en) 2007-01-23 2008-01-17 METHOD AND SYSTEM FOR SHORT MESSAGE SECURITY AUTHENTICATION IN A COMMUNICATION TERMINAL
JP2009546635A JP5241736B2 (ja) 2007-01-23 2008-01-17 ショートメッセージを使用して通信端末を通じて認証を行うための方法及びシステム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN2007100027080A CN101232631B (zh) 2007-01-23 2007-01-23 通信终端通过短信息进行安全认证的方法及系统
CN200710002708.0 2007-01-23

Publications (1)

Publication Number Publication Date
WO2008089684A1 true WO2008089684A1 (en) 2008-07-31

Family

ID=39644125

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070123 WO2008089684A1 (en) 2007-01-23 2008-01-17 Method and system for security authenticating through short message in communication terminal

Country Status (6)

Country Link
US (1) US8055558B2 (zh)
EP (1) EP2128808A4 (zh)
JP (1) JP5241736B2 (zh)
CN (1) CN101232631B (zh)
HK (1) HK1120982A1 (zh)
WO (1) WO2008089684A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013505601A (ja) * 2009-09-17 2013-02-14 ロイヤル カナディアン ミント 高信頼性メッセージ記憶、転送プロトコルおよびシステム

Families Citing this family (56)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101615472B1 (ko) 2007-09-24 2016-04-25 애플 인크. 전자 장치 내의 내장형 인증 시스템들
US8600120B2 (en) 2008-01-03 2013-12-03 Apple Inc. Personal computing device control using face detection and recognition
CN101730023A (zh) * 2009-12-07 2010-06-09 中信银行股份有限公司 短信支付的方法和系统
CN101916407A (zh) * 2010-08-16 2010-12-15 中国电信股份有限公司 移动支付平台、终端、方法和系统
US20120258693A1 (en) * 2011-04-11 2012-10-11 Amichay Oren Systems and methods for providing telephony services
US9002322B2 (en) 2011-09-29 2015-04-07 Apple Inc. Authentication with secondary approver
CA2845602C (en) * 2011-10-12 2021-10-19 Boost Payment Solutions, LLC Electronic payment processing
CN103095662B (zh) * 2011-11-04 2016-08-03 阿里巴巴集团控股有限公司 一种网上交易安全认证方法及网上交易安全认证系统
CN103366303A (zh) * 2012-03-28 2013-10-23 黄金富 手机购物方法和相应的手机购物电子商务系统
US20140025575A1 (en) * 2012-07-20 2014-01-23 Jasmeet Chhabra Techniques for out-of-band transaction verification
CN103581126A (zh) * 2012-07-27 2014-02-12 中国银联股份有限公司 安全性信息交互系统、设备及方法
CN104182869A (zh) 2013-05-22 2014-12-03 深圳市腾讯计算机系统有限公司 处理业务的方法、装置及系统
CN104424562A (zh) * 2013-08-30 2015-03-18 南京中兴群力信息科技有限公司 手机支付方法及装置
US9898642B2 (en) 2013-09-09 2018-02-20 Apple Inc. Device, method, and graphical user interface for manipulating user interfaces based on fingerprint sensor inputs
EP3063608B1 (en) 2013-10-30 2020-02-12 Apple Inc. Displaying relevant user interface objects
CN110807631A (zh) * 2014-05-29 2020-02-18 苹果公司 用于支付的用户接口
US10043185B2 (en) 2014-05-29 2018-08-07 Apple Inc. User interface for payments
KR101627154B1 (ko) * 2014-07-22 2016-06-13 주식회사 카카오 인스턴트 메시지를 이용한 결제 방법, 서버 및 애플리케이션
WO2016036552A1 (en) 2014-09-02 2016-03-10 Apple Inc. User interactions for a mapping application
CN105809443A (zh) * 2014-12-30 2016-07-27 中兴通讯股份有限公司 自助购物异步支付的方法、移动终端及支付系统
CN105574725A (zh) * 2015-05-07 2016-05-11 宇龙计算机通信科技(深圳)有限公司 一种基于终端的交易用户身份识别方法及终端
CN106302558B (zh) * 2015-05-11 2020-01-21 阿里巴巴集团控股有限公司 一种业务处理方法和装置
CN106302309A (zh) * 2015-05-12 2017-01-04 阿里巴巴集团控股有限公司 一种业务处理方法和装置
US20160358133A1 (en) 2015-06-05 2016-12-08 Apple Inc. User interface for loyalty accounts and private label accounts for a wearable device
US9940637B2 (en) 2015-06-05 2018-04-10 Apple Inc. User interface for loyalty accounts and private label accounts
WO2017012060A1 (zh) * 2015-07-21 2017-01-26 深圳市银信网银科技有限公司 开立电子凭证的方法、系统和装置
DK179186B1 (en) 2016-05-19 2018-01-15 Apple Inc REMOTE AUTHORIZATION TO CONTINUE WITH AN ACTION
US10621581B2 (en) 2016-06-11 2020-04-14 Apple Inc. User interface for transactions
CN109313759B (zh) 2016-06-11 2022-04-26 苹果公司 用于交易的用户界面
DK201670622A1 (en) 2016-06-12 2018-02-12 Apple Inc User interfaces for transactions
US9842330B1 (en) 2016-09-06 2017-12-12 Apple Inc. User interfaces for stored-value accounts
US10860199B2 (en) 2016-09-23 2020-12-08 Apple Inc. Dynamically adjusting touch hysteresis based on contextual data
US10496808B2 (en) 2016-10-25 2019-12-03 Apple Inc. User interface for managing access to credentials for use in an operation
JP6110006B1 (ja) * 2016-10-28 2017-04-05 株式会社リンクス 携帯端末のショートメッセージ機能を利用した商品の決済方法、サーバ装置
US20180349880A1 (en) * 2017-06-02 2018-12-06 Apple Inc. Peer transaction system
CN107491949A (zh) * 2017-07-29 2017-12-19 深圳市前海康启源科技有限公司 基于随机支付码的医疗支付安全系统及方法
CN107316196A (zh) * 2017-07-29 2017-11-03 深圳市前海康启源科技有限公司 基于短信触发的医疗支付数据处理系统及方法
EP4156129A1 (en) 2017-09-09 2023-03-29 Apple Inc. Implementation of biometric enrollment
KR102185854B1 (ko) 2017-09-09 2020-12-02 애플 인크. 생체측정 인증의 구현
CN108173866A (zh) * 2017-12-29 2018-06-15 苏州麦迪斯顿医疗科技股份有限公司 胸痛中心认证数据的集成方法、装置、设备及存储介质
CN110119943A (zh) * 2018-02-05 2019-08-13 李宝隆 一种短信支付方法及系统和支付平台系统
JP2019175042A (ja) * 2018-03-28 2019-10-10 沖電気工業株式会社 取引処理システム、取引処理装置およびプログラム
US11170085B2 (en) 2018-06-03 2021-11-09 Apple Inc. Implementation of biometric authentication
US10860096B2 (en) 2018-09-28 2020-12-08 Apple Inc. Device control using gaze information
US11100349B2 (en) 2018-09-28 2021-08-24 Apple Inc. Audio assisted enrollment
CN109583872A (zh) * 2018-11-30 2019-04-05 阿里巴巴集团控股有限公司 支付方法和装置
US11328352B2 (en) 2019-03-24 2022-05-10 Apple Inc. User interfaces for managing an account
US11663591B2 (en) * 2019-04-10 2023-05-30 Mastercard International Incorporated Facilitation of real-time payment network transactions
US11477609B2 (en) 2019-06-01 2022-10-18 Apple Inc. User interfaces for location-related communications
US11481094B2 (en) 2019-06-01 2022-10-25 Apple Inc. User interfaces for location-related communications
US11169830B2 (en) 2019-09-29 2021-11-09 Apple Inc. Account management user interfaces
AU2020356269B2 (en) 2019-09-29 2023-04-06 Apple Inc. Account management user interfaces
DK180985B1 (da) 2020-04-10 2022-09-02 Apple Inc Brugergrænseflader for muliggørelse af en aktivitet
US11816194B2 (en) 2020-06-21 2023-11-14 Apple Inc. User interfaces for managing secure operations
US11888854B2 (en) 2021-08-23 2024-01-30 The Toronto-Dominion Bank Systems and methods for authenticating end users of a web service
CN114493589B (zh) * 2021-12-28 2023-01-20 广州盖盟达工业品有限公司 一种网络安全支付方法及其系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1794298A (zh) * 2005-12-31 2006-06-28 北京易富金川科技有限公司 基于手机短信的信息采集、传输、处理系统和方法
CN101051372A (zh) * 2006-04-06 2007-10-10 北京易富金川科技有限公司 电子商务中对金融业务信息安全认证的方法

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03179863A (ja) * 1989-09-04 1991-08-05 Hitachi Ltd 自動取引方法および装置
US6868391B1 (en) 1997-04-15 2005-03-15 Telefonaktiebolaget Lm Ericsson (Publ) Tele/datacommunications payment method and apparatus
US6385596B1 (en) 1998-02-06 2002-05-07 Liquid Audio, Inc. Secure online music distribution system
US6233565B1 (en) 1998-02-13 2001-05-15 Saranac Software, Inc. Methods and apparatus for internet based financial transactions with evidence of payment
EP0986275B1 (de) * 1998-09-10 2009-09-09 Swisscom AG Verfahren zum Kaufen von Waren oder Dienstleistungen mit einem Mobiltelefon
US7069234B1 (en) 1999-12-22 2006-06-27 Accenture Llp Initiating an agreement in an e-commerce environment
US6629081B1 (en) 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
TW550477B (en) 2000-03-01 2003-09-01 Passgate Corp Method, system and computer readable medium for Web site account and e-commerce management from a central location
US6816721B1 (en) * 2000-04-05 2004-11-09 Nortel Networks Limited System and method of purchasing products and services using prepaid wireless communications services account
FR2814880B1 (fr) * 2000-10-04 2003-03-28 Magicaxess Circuit d'inversion pour les conventions directe et indirecte d'un module electronique
JP2001338250A (ja) * 2000-05-30 2001-12-07 Yozan Inc 口座端末、決済端末及び通信端末
US6877094B1 (en) 2000-07-28 2005-04-05 Sun Microsystems, Inc. Method and apparatus for authentication and payment for devices participating in Jini communities
JP2002099716A (ja) * 2000-09-25 2002-04-05 Masanao Kuninobu 電子決済システム
EP2284784B1 (en) 2002-06-12 2017-12-13 CardinalCommerce Corporation Universal merchant platform for payment authentication
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
JP2004062771A (ja) * 2002-07-31 2004-02-26 Show Engineering:Kk インターネットバンクの口座を用いた決済システム
ITRM20020656A1 (it) * 2002-12-30 2004-06-30 Luigi Cicione Metodo per l'autorizzazione di delegazioni di pagamento, in particolare per pagamenti effettuati su internet con carte di credito, e relativo sistema.
AU2004252925B2 (en) * 2003-06-30 2006-10-26 Selvanathan Narainsamy Transaction verification system
CN1494283A (zh) * 2003-09-25 2004-05-05 邵军利 短信息支付网关
JP2005293343A (ja) * 2004-04-01 2005-10-20 Hitachi Software Eng Co Ltd 電子商取引システムにおける与信処理方法
JP2006238128A (ja) * 2005-02-25 2006-09-07 Sony Corp 通信システム、通信装置、および通信方法
US7472822B2 (en) * 2005-03-23 2009-01-06 E2Interactive, Inc. Delivery of value identifiers using short message service (SMS)
US20070156579A1 (en) * 2006-01-05 2007-07-05 Ubequity, Llc System and method of reducing or eliminating change in cash transaction by crediting at least part of change to buyer's account over electronic medium
CN1811807A (zh) * 2006-03-07 2006-08-02 刘进 利用语音和短信通讯完成个人对个人支付的方法和系统

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1794298A (zh) * 2005-12-31 2006-06-28 北京易富金川科技有限公司 基于手机短信的信息采集、传输、处理系统和方法
CN101051372A (zh) * 2006-04-06 2007-10-10 北京易富金川科技有限公司 电子商务中对金融业务信息安全认证的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2128808A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013505601A (ja) * 2009-09-17 2013-02-14 ロイヤル カナディアン ミント 高信頼性メッセージ記憶、転送プロトコルおよびシステム
US9071444B2 (en) 2009-09-17 2015-06-30 Royal Canadian Mint/Monnaie Royale Canadienne Trusted message storage and transfer protocol and system

Also Published As

Publication number Publication date
US20100082462A1 (en) 2010-04-01
EP2128808A4 (en) 2015-01-21
EP2128808A1 (en) 2009-12-02
CN101232631B (zh) 2011-08-31
CN101232631A (zh) 2008-07-30
JP2010517390A (ja) 2010-05-20
HK1120982A1 (en) 2009-04-09
JP5241736B2 (ja) 2013-07-17
US8055558B2 (en) 2011-11-08

Similar Documents

Publication Publication Date Title
WO2008089684A1 (en) Method and system for security authenticating through short message in communication terminal
US11595368B2 (en) Secure communications using loop-based authentication flow
US20200336315A1 (en) Validation cryptogram for transaction
US7606560B2 (en) Authentication services using mobile device
US8285640B2 (en) System and methods for facilitating fund transfers over a network
US20090106138A1 (en) Transaction authentication over independent network
JP2013514556A (ja) 安全に取引を処理するための方法及びシステム
CN110073387A (zh) 证实通信设备与用户之间的关联
KR20100054757A (ko) 대역밖 인증을 이용한 지불 거래 처리
WO2015065249A1 (ru) Способ и система защиты информации от несанкционированного использования (её варианты)
US8577766B2 (en) Secure transactions using non-secure communications
US20210258324A1 (en) System and method for message recipient verification
US11978032B2 (en) System and method for performing peer to peer transfers
Cobourne et al. Using the smart card web server in secure branchless banking
US20220122177A1 (en) Blockchain-based transaction
Kumar et al. A system model and protocol for Mobile Payment Consortia System
Wafula Muliaro et al. Enhancing Personal Identification Number (Pin) Mechanism To Provide Non-Repudiation Through Use Of Timestamps In Mobile Payment Systems.
Ugwu et al. A Secured Mobile Payment Transaction Protocol for Android Systems

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

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 12448967

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2009546635

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2008700780

Country of ref document: EP