[go: up one dir, main page]

WO2015179681A1 - Achat par courrier électronique vérifié - Google Patents

Achat par courrier électronique vérifié Download PDF

Info

Publication number
WO2015179681A1
WO2015179681A1 PCT/US2015/032030 US2015032030W WO2015179681A1 WO 2015179681 A1 WO2015179681 A1 WO 2015179681A1 US 2015032030 W US2015032030 W US 2015032030W WO 2015179681 A1 WO2015179681 A1 WO 2015179681A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
mobile
application
user
request
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US2015/032030
Other languages
English (en)
Inventor
Jesse Wilson
Brian Grassadonia
Matthew Rhodes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Block Inc
Original Assignee
Square Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US14/284,224 external-priority patent/US9922324B2/en
Priority claimed from US14/283,617 external-priority patent/US20150339668A1/en
Priority claimed from US14/283,504 external-priority patent/US20150339656A1/en
Application filed by Square Inc filed Critical Square Inc
Priority to AU2015264085A priority Critical patent/AU2015264085B2/en
Publication of WO2015179681A1 publication Critical patent/WO2015179681A1/fr
Anticipated expiration legal-status Critical
Priority to AU2021200725A priority patent/AU2021200725B2/en
Priority to AU2022204641A priority patent/AU2022204641A1/en
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • a typical checkout experience for a new customer shopping on a website includes signing up for an account by setting up a username and password, providing payment information relating to a debit or credit card and billing and shipping information and then placing an order.
  • the payment information is typically saved under the account to allow returning customers to sign in and place an order using the payment information stored under the account.
  • Figure 1 illustrates an environment in which a one-click verified purchasing technology can be implemented.
  • Figure 2 illustrates an example purchase flow in accordance with a first embodiment of the one-click verified purchasing technology.
  • Figure 3 illustrates an example purchase flow in accordance with a second embodiment of the one-click verified purchasing technology.
  • Figure 4 illustrates an example purchase flow in accordance with a third embodiment of the one-click verified purchasing technology.
  • Figure 5 illustrates an example purchase flow in accordance with a fourth embodiment of the one-click verified purchasing technology.
  • Figure 6A illustrates an example of components of the one-click verified purchasing system in accordance with some embodiments of the one-click verified purchasing technology
  • Figure 6B illustrates an example of components of a mobile payment application on a mobile device in accordance with some embodiments of the one-click verified purchasing technology.
  • Figures 7A-7B illustrate an example method of processing a payment request in accordance with a first embodiment of the one-click verified purchasing technology.
  • Figure 8 illustrates an example method of processing a payment request in accordance with a second embodiment of the one-click verified purchasing technology.
  • Figure 9 illustrates an example method of processing a payment request in accordance with a third embodiment of the one-click verified purchasing technology.
  • Figure 10 is a high-level block diagram showing a computer system in which at least some operations related to the disclosed technology can be implemented.
  • the present disclosure is related to a system and methods for purchasing items online by taking a single verification action (hereinafter“one-click verified purchasing technology”).
  • the single verification action can be a submission of a security code associated with a payment card or payment account when placing an online order.
  • the single verification action can be responding to a confirmation request (e.g., a push notification, an email message, a text message, etc.) or a permission request.
  • the disclosed technology employs one or more of these verification actions to identify and block fraudulent transactions and provide customers engaging in legitimate transactions a faster and efficient checkout experience that does not involve signing in or registering for an account.
  • the one-click verified purchasing technology in some embodiments, enables a customer to place an online order for items from a merchant website or a web application (“merchant system”), without creating an account or signing in to an account. Instead, the one-click verified purchasing technology enables a customer to use a communication identifier linked to a payment card stored on file with a one-click verified purchasing system to complete the checkout process.
  • the one-click verified purchasing system implementing the disclosed technology receives a payment request to initiate a payment transaction.
  • the payment request can include the customer’s communication identifier (or in some instances a user identifier) and details of the order from the merchant system.
  • the one-click verified purchasing system can send a push notification to the customer’s mobile device requesting the customer to confirm or cancel the online order. If the customer confirms the order, the one-click verified purchasing system processes the payment request from the merchant system by initiating a transfer of an amount of funds corresponding to the payment request from a bank account associated with the payment card to a bank account associated with the merchant system.
  • the one-click verified purchasing technology allows a customer to place an order for items with a merchant system using a communication identifier linked to a payment card on file with the one-click verified purchasing system and a security code (e.g., a card verification value) associated with the payment card.
  • a security code e.g., a card verification value
  • the one-click verified purchasing system receives a payment request including these two pieces of information and details of the order (e.g., order identifier, order amount, pre-tax amount, sales tax amount, shipping cost, description and quantity of items ordered, etc.) from the merchant system.
  • the one-click verified purchasing system then checks that the communication identifier is mapped to a valid payment card and the security code included in the payment request matches the corresponding security code on the payment card. If so, the one-click verified purchasing system processes the payment request from the merchant system by initiating a transfer of an amount of funds corresponding to the payment request from a bank account associated with the payment card to a bank account associated with the merchant system.
  • the one-click verified purchasing technology enables a customer to order items from a mobile application (“requesting application”) on a mobile device by using a mobile payment application installed on the same mobile device as a payment method or checkout option.
  • the mobile payment application appears as a payment option on the checkout user interface of the requesting application.
  • the mobile payment application comes to the foreground of the mobile device, while the requesting application goes into the background.
  • the customer can then permission the requesting application to use the mobile payment application as a payment method in the current transaction or in the current and future transactions.
  • the mobile payment application can provide one or more user interfaces for managing settings and permissions associated with various requesting applications, tracking payment requests initiated from the requesting applications, or the like.
  • the one-click verified purchasing technology enables use of a mobile payment application that generates an email-based payment request as a payment method to submit an order.
  • the mobile payment application comes to the foreground of the mobile device.
  • the mobile payment application can then pre-fill a payment amount and compose an email-based payment request by filling out the“To” and“Cc” fields.
  • The“To” field includes the email address of the party receiving the payment (i.e., the merchant) and the“Cc” field includes the email address of the party providing the payment service (i.e., the one-click verified purchasing system).
  • Other details relating to the order associated with the payment request can also be auto-filled by the mobile payment application.
  • the customer can then send the e- mail to initiate the payment transaction.
  • the disclosed technology enhances the checkout experience for customers by removing account registration and sign in barriers. Because the disclosed technology uses mapping or association between a communication identifier and one or more payment cards to process payment requests from merchant systems, customers can provide minimal information to complete the checkout process. Moreover, the disclosed technology enables the checkout process to be completed in a shorter amount of amount and using a single verification action.
  • FIG. 1 illustrates an environment 100 in which the one-click verified purchasing technology can be implemented.
  • the environment includes a merchant system 122 (e.g., e-commerce websites or web applications hosted on a web server(s) or application server(s)).
  • the merchant system 122 can be accessed by a customer using a client device 104 (e.g., a desktop computer, a laptop computer, a mobile device, a tablet or any other processing device) or a mobile device 102 of a customer.
  • the mobile device 102 can be, for example, a smart phone, a tablet computer, a phablet, a notebook computer, or any other form of mobile processing device.
  • a mobile payment application 120 runs on the customer’s mobile device 102.
  • the mobile device 102 can also include other e-commerce applications (“requesting applications”) that are associated with one or more merchant systems and can be used by the customer to purchase products or services.
  • requesting applications e.g., e-commerce websites or web applications hosted on a
  • the environment 100 can also include a computer system of the merchant’s acquirer (hereinafter“acquirer 114”), a computer system of an issuing bank (hereinafter “issuer 118”), a computer system of a card payment network (hereinafter“card payment network 116”), and a computer system of a payment service (hereinafter "payment service system 108") implementing the one-click verified purchasing system 109.
  • Each of the aforementioned computer systems can include one or more distinct physical computers and/or other processing devices which, in the case of multiple devices, can be connected to each other through one or more wired and/or wireless networks. All of the aforementioned devices are coupled to each other through a network 106, which can be, or include, the Internet and one or more wireless networks (e.g., a Wi-Fi network and/or a cellular telecommunications network).
  • the environment 100 can accommodate transactions involving payment cards such as debit cards, credit cards, pre-paid cards, bank accounts, mobile payment applications and the like.
  • the mobile payment application 120 can include an electronic wallet application, money transfer application (e.g., application for sending and receiving money via email or phone), or any other application having an account that is linked to one or more payment cards and/or bank accounts and can be used by the owner of the mobile device to initiate transactions.
  • Such transactions can include traditional purchase transactions between customers and merchants or service providers, person to person transactions and the like.
  • the merchant system receives details of the payment card including the cardholder’s name, payment card number, expiration date, card verification value (CVV)), billing address, etc., and provides such information to the payment service system 108.
  • the payment service system processes the transaction by routing the authorization request to the acquirer 114.
  • the acquirer 114 sends this data to the the card payment network 116 (e.g., Visa, MasterCard), which forwards the data to the issuer 118 for authorization. If the transaction is approved or authorized by the issuer 118, a payment authorization message is sent from the issuer 118 to the merchant system 122 via a path opposite of that described above.
  • settlement and clearing occurs. During settlement and clearing, the issuer 118 sends the funds associated with the authorized transaction through the card payment network 116 to the acquirer 114 to be deposited in the merchant’s account with the acquirer 114.
  • FIG. 2 illustrates an example purchase flow 200 in accordance with a first embodiment of the one-click verified purchasing technology.
  • the purchase flow 200 begins on a merchant’s website or web application 205.
  • a“payment service” 210 as a payment method.
  • the merchant’s website 205 may include additional checkout options 220 such as a payment card (e.g., a debit or credit card such as VISA, AMERICAN EXPRESS).
  • the payment service 210 is selected as the payment method
  • the customer is requested to enter a communication identifier 215 such as an email address or a phone number and submit the order by selecting the“Place Order” button 225.
  • the customer can place the order using the payment service option 210 without signing in or registering for an account with the merchant.
  • the details of the order submitted by the customer is received by the merchant system 122 which then sends a payment request to the payment service system 108 to initiate a payment transaction.
  • the one-click verified purchasing system 109 of the payment service system receives the payment request including the communication identifier and order information (e.g., order identifier, product description and quantity, etc.).
  • the one-click verified purchasing system 109 uses the communication identifier to look up or identify an associated payment card.
  • the one-click verified purchasing system 109 can also use the communication identifier to determine whether the customer associated with the payment card has a mobile payment application installed on his or her mobile device 102.
  • storage of a device identifier or a mobile application identifier in association with the communication identifier in one or more database tables can be an indication that the customer’s has installed the mobile payment application on his or her mobile device.
  • the mobile device identifier and/or the application identifier can be used by the one-click verified purchasing system 109 to send a push notification 235 to the customer’s mobile device 102.
  • the push notification 235 can include information about the order and can request the customer confirm the order by selecting the confirm button 240 or cancel the order by selecting the cancel button 245. If the customer confirms the order, the payment service system processes the payment request from the merchant system 122 by sending an authorization request to the issuer 118 of the payment card via the acquirer 114 and the card payment network 116. If the authorization request is approved, the one-click verified purchasing system sends a success response to the merchant system 122 which then notifies the customer on its website 205 accordingly. In some embodiments, the one-click verified purchasing system 109 can also provide additional information such as a shipping address for the customer when sending the response to the merchant system 122 to facilitate physical delivery of purchased items to the customer.
  • the one-click verified purchasing system 109 provides a failed response to the merchant system 122, which then cancels the order and notifies the customer of the cancelation.
  • the disclosed technology provides additional security in processing purchase transactions by implementing a two-factor verification method.
  • the website 205 can be accessed using a client device (e.g., client 104) that is separate from the mobile device 102.
  • the confirmation on the mobile device 102 can thus act as a second verification factor, while the email address of the customer acts as a first verification factor.
  • the website 205 can be accessed on a mobile web browser of the same mobile device 102 to which the push notification is delivered.
  • FIG. 3 illustrates an example purchase flow 300 in accordance with a second embodiment of the one-click verified purchasing technology.
  • the purchase flow 300 begins on a website or a web application 305 (e.g., display component for displaying information identifying one or more items).
  • the customer can submit the order without registering for or signing in to an account (e.g., with the merchant system or any other service that processes payments for the merchant system) and thereby avoid a need to use an authentication procedure associated with accessing the account to complete the purchase transaction.
  • an account e.g., with the merchant system or any other service that processes payments for the merchant system
  • the payment service 310 can select the payment method.
  • a communication identifier 315 such as an email address or a phone number and a card verification value 320 associated with a payment card linked to the communication identifier into the user interface elements.
  • the customer can then submit the order by selecting the“Place Order” button 325.
  • a purchase order submission component can gather at least some of the information identifying the items in the order (e.g., item ID or stock keeping unit), the communication identifier and the card verification value to generate a request and transmits the request to the merchant system.
  • other information associated with the payment card such as a portion of the payment card number (e.g., primary account number or PAN) can be requested instead of or in addition to the card verification value.
  • the order submitted by the customer is received at the merchant system 122, which then sends a payment request to the payment service system 108 to request payment for the transaction initiated by the customer.
  • the one-click verified purchasing system 109 receives the payment request and uses the communication identifier and the card verification value included in the payment request to identify a payment card that is to be used to pay for the transaction.
  • the payment service system 108 then sends an authorization request to the issuer 118 of the payment card via the acquirer 114 and the card payment network 116. If the authorization request is approved, the one-click verified purchasing system 109 sends a success response to the merchant system 122 which then notifies the customer on its website 330 accordingly.
  • FIG. 4 illustrates an example purchase flow 400 in accordance with a third embodiment of the one-click verified purchasing technology.
  • the purchase flow 400 begins on the requesting mobile application 125 on the mobile device 102.
  • the requesting application 125 can be a browser application that can be used to access a website or a web application or a mobile e-commerce application installed on the mobile device.
  • the customer selects one of the payment methods, e.g., 410 or 420, displayed on a user interface 405 of the requesting mobile application 125.
  • the requesting mobile application 125 invokes the mobile payment application 120.
  • the user interface 425 of the mobile payment application 120 displays a request from the requesting application 125 for permission to use a payment card linked to the mobile payment application 120.
  • the customer can select option 430 to grant the requesting application 125 a one-time permission to use the mobile payment application 120 to make a request for payment.
  • the option 435 can be selected to grant the requesting application a permission (e.g., perpetual or long term) to make payment requests to the mobile payment application 120.
  • The“Deny” option 440 can be selected to deny the requesting application from using the mobile payment application to request payments.
  • the mobile payment application 120 sends a payment request to the payment service system 108 on behalf of the requesting application 125 to initiate the payment transaction.
  • the payment request can include a communication identifier which can be an email address, a phone number, an identifier corresponding to the mobile payment application, an identifier corresponding to the mobile device or a combination thereof, which can be used by the payment service system to identify the payment card that is to be used to pay for the transaction.
  • the payment request can be a HyperText Transfer Protocol (HTTP) request.
  • HTTP HyperText Transfer Protocol
  • the payment request can be an email message.
  • the mobile payment application can request the customer to provide a card verification value of the payment card for an extra layer of security.
  • the customer can configure preference settings 450 for each requesting application to define the conditions or rules under which payment requests from the requesting application can be processed. For example, by setting an amount threshold, the customer can authorize the mobile payment application to process payment requests from the requesting application that are in the amount $150.00 or less, without prompting the customer for confirmation. For payment requests higher than the threshold amount, the mobile payment application can request a verification action (e.g., entry of a card verification value) from the customer or a confirmation that the customer wishes to proceed with the transaction.
  • the preference settings 450 may also include an option to turn on/off notifications when a payment request is processed.
  • a default setting can be specified by the mobile payment application for processing payment requests. For example, by default in the absence of preference settings, all payment requests can cause the mobile payment application to notify the customer to obtain confirmation from the customer to proceed with the transaction.
  • the user interface 445 can include a payment history panel 455 which displays a list of payment requests processed by the mobile payment application on behalf of the requesting application.
  • FIG. 5 illustrates an example purchase flow 500 in a fourth embodiment of the one-click verified purchasing system.
  • the purchase flow 500 begins on the user interface 505 of a requesting application (e.g., 125) which displays multiple payment methods, e.g., 510 and 520.
  • a requesting application e.g., 125
  • the requesting application invokes the mobile payment application 120 if it is installed on the mobile device.
  • the customer can enter an amount 530 corresponding to the purchase on the user interface 155, or alternately, the payment amount can be auto-populated based on order information received from the requesting application.
  • the customer can select the“attach to email” option 535 to generate an email 540, with the merchant’s email address in the“To” field 545 and the payment service system’s email address in the“Cc” field 550.
  • the subject and message body can also be auto-populated using order information from the requesting application.
  • the email 540 can be automatically generated and populated with the recipient email address and the payment amount.
  • the customer can send the email (e.g., by selecting the send button) to initiate transfer of the payment amount from a payment account associated with the customer to a financial account associated with the requesting application.
  • the mobile payment application when the requesting application invokes the mobile payment application to request the payment amount, can display a notification message to the customer to obtain a confirmation from the customer to proceed with the transaction.
  • the mobile payment application can generate an email message that includes the email address of the requesting application, the email address of the payment service system and an email address of the customer in a header portion and at least the payment amount in the header portion or a body portion of the email message via a background process that is transparent to the customer (i.e., the email message is generated and sent in a manner that is generally undetectable or invisible to the customer).
  • the notification message can include an option for the customer to select a payment card that is to be used for payment.
  • Figure 6A illustrates an example of components of the one-click verified purchasing system in accordance with some embodiments of the one-click verified purchasing technology.
  • the one-click verified purchasing system 109 can be a component or a sub-system of the payment service system 108. Alternately, the one-click verified purchasing system 109 can be implemented on a separate computing system (e.g., on a separate server or server(s)).
  • the one-click verified purchasing system 109 can include a payment request processor 605 and a payment request notification engine 615, among others, in some embodiments.
  • the one-click verified purchasing system 109 can access one or more database tables such as the customer account database table 640, payment card database table 645 and/or transaction history database table 650 to retrieve and/or store data.
  • the customer account database table 640 can store various fields of information such as a customer identifier, name, email address, phone number, device identifier, mobile application identifier, billing address, shipping address, and/or the like.
  • the payment card database table 645 can include various fields of information such as a customer identifier, payment card/account number (e.g., primary account number or PAN), expiration date, card/account type, and/or the like.
  • the transaction history database table 650 can include various fields of information such as a transaction identifier, customer identifier, date, merchant name, amount, product/service item names/codes, and/or the like.
  • Various other database tables may also be accessed by the one-click verified purchasing system 109.
  • the payment request processor 605 can process payment requests from merchant systems as described in detail with respect to Figures 2-5. For example, the payment request processor 605 can receive payment requests from merchant systems, parse the payment requests to extract details such as the communication identifier, the security code for a payment card, order information, or the like. The payment request processor 605 can check whether a communication identifier is associated with one or more payment cards and can process payment requests when triggered by a verification action by initiating a transfer of an amount associated with the payment request from a bank account funding one of the payment cards to a financial account associated with the merchant system.
  • the risk analyzer 610 can examine incoming payment requests for any indications for fraud and evaluate a level of risk associated with processing the payment requests. Based on the level of risk, the payment request processor 605 can determine whether to block the payment request or to allow the payment request to be processed. The risk analyzer can determine or assess a level of risk associated with a payment request by analyzing attributes of the payment request and historical data (e.g., past transactions associated with the a customer) to identify one or more risk factors. The historical data associated with past transactions can be stored in a database table 650. Examples of risk factors can include, but are not limited to: pattern of purchase behavior, transaction amount, volume, frequency and/or timing of payment requests, identity of the merchant, and/or the like.
  • Each of the risk factors can be scored and/or weighted to determine an aggregate risk score that provides an assessment of the level of risk associated with a payment request.
  • the risk analyzer can, for example, notify the trigger payment request processor 605 and/or the payment request notification engine 615 so that the payment request can be blocked from reaching the customer and can be canceled.
  • customers can have mobile payment applications installed on their mobile devices. Payment requests associated with those customers can cause the payment request notification engine 615 to generate and send push notifications using the push notification module 620.
  • a push notification for a payment request is generated based on information included in the payment request, and can prompt the customer to confirm or cancel the payment request.
  • the payment service system can process the payment request by initiating transfer of an amount of funds corresponding to the payment request from a bank account associated with the payment card to a financial account associated with the merchant system.
  • the payment request notification engine 615 can block a push notification for the payment request from being sent to the customer’s mobile device.
  • the payment request notification engine 615 can send a notification in the form of an email 625, text message 630 and/or an automated phone call 635 to request a customer to confirm or cancel a payment request.
  • the customer can confirm the payment request by providing a card verification value associated with a payment card or send another confirmatory response.
  • the notification engine 615 can select a notification method for requesting verification or confirmation from a customer based on the level of risk associated with the payment request. For example, if the level of risk is high, the notification engine 615 can use the automated phone call option. Similarly, if the level of risk is low, the notification engine can use the push notification option.
  • Figure 6B illustrates an example of components of the mobile payment application 120 on a mobile device in some embodiments of the one-click verified purchasing technology.
  • the mobile payment application 120 can include an application payment request handler 652, a permissions manager 654, a payment request settings manager 655 and a payments history manager 660, among others in some embodiments.
  • the application payment request handler 652 can receive payment requests from requesting applications on the mobile device and process the payment requests based on permissions managed by the permissions manager 654.
  • the permissions manager 654 can track permissions granted by a customer to various requesting applications to make payment requests via the mobile payment application. Those requesting applications that have been permissioned by the customer to request payment via the mobile payment application can send payment requests to the mobile payment application in the background. For example, when the application payment request handler 652 receives an incoming payment request from a requesting application, the payment request handler checks with the permissions manager 654 to determine whether the requesting application is allowed to make the payment request.
  • the application payment request handler 652 handles the payment request by sending it on to the payment service system. If, for example, the requesting application does not have a valid permission, the application payment request handler 652 can decline to process the payment request or notify the customer for confirmation.
  • the payment request settings manager 655 can receive and store preference settings specified by the customer for handling payment requests by the application payment request handler 652.
  • the application payment request handler 652 can check with the settings manager to determine whether a payment request from a requesting application meets all the rules set up by the customer (e.g., payment amount threshold) and process the payment request when the payment request meets the conditions associated with the rules.
  • the payment history manager 660 in some embodiments, can track and store a history of payment requests from each requesting application handled by the mobile payment application.
  • Figures 7A-7B illustrate an example method of processing a payment request in accordance with a first embodiment of the one-click verified purchasing technology.
  • the disclosed technology receives a payment request including an identifier from a merchant system, analyzes the payment request to assess a level of risk associated with it and based on the level of risk, determines whether to send a push notification to a mobile device associated with the identifier to request confirmation on the payment request.
  • the one-click verified purchasing system receives a payment request associated with a purchase transaction from a merchant system.
  • the one-click verified purchasing system parses the payment request at block 704 to extract an identifier which is typically an email address or a phone number, but can be any other identifier such as a user identifier, a TWITTER handle, etc.
  • the extracted information can also include details of the transaction.
  • the one-click verified purchasing system determines if the identifier is associated with a payment card in the payment service system.
  • the one-click verified purchasing system can send a notification (e.g., an email or a text message) to register with the payment service system by associating a payment card to the identifier at block 708.
  • a notification e.g., an email or a text message
  • the one-click verified purchasing system can examine the customer’s transaction history and attributes of the payment request to determine a level of risk (or a risk score) associated with the payment request at block 712. For example, if the customer’s transaction history indicates a history of purchase of clothing for male and the order is associated with a clothing for female, the change in purchase behavior can be an indication of fraud, which is considered in assessing the level of risk. Similarly, a payment request for an amount much larger than in the past can be another indication of fraud that can be considered in determining the level of risk.
  • the one-click verified purchasing system can decline the payment request without notifying the customer at block 716.
  • the one-click verified purchasing system can determine if the identifier included in the payment request is associated with an instance of a mobile payment application installed on a mobile device at decision block 720. If so, the one-click verified purchasing system can retrieve a device identifier associated with the mobile device and send a push notification to the mobile device to request the customer to confirm or cancel the payment request. If the identifier is not associated with an instance of the mobile payment application, the one-click verified purchasing system can send a notification to the customer’s email address or phone number to request the customer to confirm or cancel the payment request at block 724.
  • the one-click verified purchasing system processes the payment request at block 728. If a“cancel” response 726b is received from the customer, the one-click verified purchasing system declines the payment request from the merchant system at block 730.
  • Figure 8 illustrates an example method of processing a payment request in accordance with a second embodiment of the one-click verified purchasing technology.
  • the disclosed technology receives a payment request for a purchase transaction from a merchant system and uses an identifier and a security code submitted by a customer at a merchant system as part of the purchase transaction to approve or deny the payment request.
  • the method 800 begins at block 805 when the one-click verified purchasing system receives a payment request associated with a purchase transaction from a merchant system.
  • the one-click verified purchasing system parses the payment request to extract an identifier and a security code associated with a payment card at block 810.
  • the one-click verified purchasing system determines if the identifier is associated with one or more payment cards and if so, at decision block 820, the one-click verified purchasing system determines if the security code in the payment request matches the security code on one of the payment cards.
  • the one-click verified purchasing system processes the payment request at block 830 by transferring a payment amount included in the payment request from an account associated with the payment card with the matching security code to a financial account associated with the merchant system.
  • the one-click verified purchasing system provides a response declining the payment request at block 825.
  • Figure 9 illustrates an example method of processing a payment request in accordance with a third embodiment of the one-click verified purchasing technology.
  • a mobile payment application 120 on a mobile device processes a payment request initiated by a requesting application 125 on the same mobile device.
  • the method 900 begins at block 910, when the requesting application receives a user request to pay for an order using the mobile payment application. If the mobile payment application is not installed on the mobile device as determined at decision block 915, the user can be redirected to an application store on the mobile device to download and install the mobile payment application at block 920.
  • the requesting application can invoke or call the mobile payment application and pass a payment request to it at block 925.
  • the payment request can include details of the order.
  • the mobile payment application (or a background service listening to a call or Intent) can answer the call from the requesting application to handle the payment request.
  • the mobile payment application can request confirmation from the user for processing the payment request. If the user response is “allow once” 940a, the mobile payment application processes the payment request at block 965 as a one-time request by sending the payment request to the one-click verified purchasing system over a network.
  • the payment request can include a device identifier, a mobile application instance identifier, communication identifier or the like appended to it, which can be used by the one-click verified purchasing system to identify a payment account to be used to pay for the order.
  • the mobile payment application obtains a response authorizing or denying the payment request 970 from the one-click verified purchasing system and sends the response to the requesting application.
  • the requesting application receives the response and notifies the user accordingly at block 960. For example, if the authorization failed, the requesting application can notify the user of the failed transaction status.
  • the mobile payment application processes the payment request at block 945 and grants the requesting application permission to make subsequent payment requests to the mobile payment application at block 950.
  • the payment request from the requesting application is processed by the mobile payment application in the background without the user having to leave the requesting application. Since the user does not leave the requesting application and the payment requests are processed in the background, this method provides a seamless purchase experience for the user without sharing the user’s payment card data to the requesting application.
  • the mobile payment application can generate and send the requesting application a token using which the requesting application can directly communicate with the one-click verified purchasing system to request payments.
  • the token can be uniquely associated with a user and the requesting mobile application, and can be invalidated at any time (e.g., by the user revoking or changing the permission, after a period of time, etc.)
  • the mobile payment application can send a response to the requesting application declining the payment request at block 975.
  • FIG 10 is a high-level block diagram showing an example of a processing device 1000 that can represent any of the devices described above, such as the mobile device 102, client device 104, merchant system 122, payment processor system 114, 116 or 118, the payment service system 108 and the one-click verified purchasing system 109.
  • any of these systems may include two or more processing devices such as represented in Figure 10, which may be coupled to each other via a network or multiple networks.
  • the processing system 1000 includes one or more processors 1010, memory 1011, a communication device 1012, and one or more input/output (I/O) devices 1013, all coupled to each other through an interconnect 1014.
  • the interconnect 1014 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters and/or other conventional connection devices.
  • the processor(s) 1010 may be or include, for example, one or more general- purpose programmable microprocessors, microcontrollers, application specific integrated circuits (ASICs), programmable gate arrays, or the like, or a combination of such devices.
  • the processor(s) 1010 control the overall operation of the processing device 800.
  • Memory 1011 may be or include one or more physical storage devices, which may be in the form of random access memory (RAM), read-only memory (ROM) (which may be erasable and programmable), flash memory, miniature hard disk drive, or other suitable type of storage device, or a combination of such devices.
  • RAM random access memory
  • ROM read-only memory
  • flash memory miniature hard disk drive, or other suitable type of storage device, or a combination of such devices.
  • Memory 1011 may store data and instructions that configure the processor(s) 1010 to execute operations in accordance with the techniques described above.
  • the communication device 1012 may be or include, for example, an Ethernet adapter, cable modem, Wi-Fi adapter, cellular transceiver, Bluetooth transceiver, or the like, or a combination thereof.
  • the I/O devices 1013 can include devices such as a display (which may be a touch screen display), audio speaker, keyboard, mouse or other pointing device, microphone, camera, etc.
  • ASICs application-specific integrated circuits
  • PLDs programmable logic devices
  • FPGAs field-programmable gate arrays
  • Machine-readable medium includes any mechanism that can store information in a form accessible by a machine (a machine may be, for example, a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device with one or more processors, etc.).
  • a machine-accessible medium includes recordable/non- recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.).
  • the above disclosure includes the following examples.
  • a method of paying for an online purchase transaction between a user and a third- party merchant system using a payment service system different from the third-party merchant system comprising:
  • a payment request including a communication identifier from the third-party merchant system, the communication identifier being provided by the user at a user interface of the third-party merchant system in lieu of payment information or login credentials to initiate the online purchase transaction; using the communication identifier received from the third-party merchant system to retrieve information identifying a verification device;
  • assessing the level of risk associated with the payment request includes assessing at least one risk factor including a purchase pattern associated with the user, the payment amount, a frequency of payment requests in a given duration, a timing of the payment request or an identity of the third-party merchant system.
  • the communication identifier includes at least one of an email address or a phone number.
  • a method of processing an online purchase transaction between a user and a merchant by a payment service separate from the merchant comprising:
  • the identifier being provided by the user to the merchant instead of payment information or login credentials to initiate the online purchase transaction;
  • the account storing information associated with a payment card for accessing a financial account associated with the user and information identifying a mobile device;
  • determining a risk score associated with the online purchase transaction based on the risk score, determining an action for processing the online purchase transaction; wherein the action includes sending the request to the mobile device to obtain the confirmation of the online purchase transaction when the risk score indicates that the online purchase transaction is unlikely to be a fraudulent transaction.
  • the risk score is determined based on one or more risk factors including a purchase pattern associated with the user, the payment amount, a number of online purchase transactions occurring in a given duration, a timing of the online purchase transaction or an identity of the merchant.
  • a system for processing a purchase transaction comprising:
  • a processor configured to execute instructions stored in the memory to:
  • purchase transaction is initiated by the user without signing in to an account and without providing payment information to the third-party merchant system;
  • the account including information associated with a payment card for accessing a financial account associated with the user and information identifying a mobile device;
  • the payment request is one of multiple payment requests initiated from multiple third-party merchant systems and wherein the processor is further configured to assess a level of risk associated with each payment request and automatically block a payment request that is likely to be fraudulent based on the level of risk from causing a push notification to be sent to the mobile device.
  • the level of risk associated with each payment request is assessed based on a combination of risk factors including a purchase pattern associated with the user, a payment amount, a number of payment requests in a given duration, a timing of a payment request or an identity of a third-party merchant system.
  • a method of purchasing an item comprising:
  • a request from a user to purchase an item including a communication identifier submitted by the user, submission of the communication identifier being a substitute for entry of payment information or login credentials;
  • the payment service system receiving, by the payment service system, a payment request from the merchant system, the payment request being generated in response to the user initiating the purchase transaction to purchase an item from the merchant system using a single action, the payment request including a communication identifier and a security code associated with a payment card obtained from the user for the purchase transaction, the communication identifier and the security code being used to avoid a need for the user to provide a payment card number and other information associated with the payment card to the merchant system and the need for the user to sign in to an account to proceed with the purchase transaction;
  • the communication identifier to identify an account associated with the user, the account having been created by the payment service system to store information relating to the payment card linked to a financial account from which funds can be withdrawn or deposited;
  • a payment service system for processing a purchase transaction comprising:
  • a processor in communication with the memory and configured to execute instructions stored in the memory to:
  • a request to process a purchase transaction initiated by a user the request being generated in response to the user submitting a communication identifier and a portion of payment card data as verification data, wherein the purchase transaction is processed using the communication identifier and the verification data to avoid a need to use an authentication procedure to complete the purchase transaction;
  • the communication identifier is at least one of an email address or a phone number.
  • the verification data includes a portion of a primary account number (PAN) printed on the payment card.
  • PAN primary account number
  • a method of processing a purchase transaction comprising:
  • a merchant system receiving, by a merchant system, a request from a user to initiate the purchase transaction, the request including a communication identifier and a portion of payment card data associated with a payment card as verification data, wherein by providing the communication identifier and the verification data the user need not provide all of the payment card data and need not sign in to an account to initiate the purchase transaction; sending, by the merchant system, a payment request including the communication identifier and the verification data to a payment service system to request payment for the purchase transaction;
  • the verification data includes a portion of a primary account number (PAN) displayed on the payment card.
  • PAN primary account number
  • the verification data includes a card verification value displayed on the payment card.
  • a client system for submitting a purchase order comprising:
  • a display component configured to:
  • user interface elements configured to:
  • a purchase order submission component configured to:
  • the merchant server system gathers at least some of the information identifying the item, the communication identifier and the portion of payment card data to generate a request; and transmit the request to a merchant server system, wherein the merchant server system transmits at least the communication identifier, the portion of payment card data and a purchase amount associated with the purchase order to a payment service system to request payment for the purchase order.
  • a method of handing over processing of a purchase transaction between a user and a merchant initiated by the user from a first mobile application to a mobile payment application associated with a payment service system comprising:
  • an email message based on information in the request using an email application installed on the mobile device, the email message being addressed to the merchant email address and a payment service email address associated with the payment service system and having a body or a subject line populated with the transaction amount, the email message being generated for sending from the mobile device to the payment service system so that the payment service system can analyze the email message to identify the transaction amount, a user email address associated with the user and the merchant email address and initiate a transfer of the transaction amount from a user financial account associated with the user email address to a merchant financial account associated with the merchant email address to complete the purchase transaction.
  • the method of example 47, wherein the first mobile application is a browser application used to access a website associated with the merchant to initiate the purchase transaction.
  • notification message includes an option to allow the user to configure a preference setting for processing subsequent purchase transactions with the merchant.
  • a method of processing a purchase transaction between a user and a merchant initiated at a first mobile application by a mobile payment application associated with a payment service system comprising:
  • the mobile payment application on a mobile device receiving, by the mobile payment application on a mobile device, a request from the first mobile application on the mobile device to pay for the purchase transaction initiated by the user at the first mobile application, the request being generated in response to the user selecting the mobile payment application as a payment method for the purchase transaction, the request including at least a transaction amount and a merchant identifier associated with the merchant;
  • the payment request is an email message that is generated by the mobile payment application using an email application installed on the mobile device, wherein the email message that is generated includes an email address associated with the merchant corresponding to the merchant identifier and a payment service email address corresponding to the payment service system in a header portion of the email message and the transaction amount in either the header portion or a body portion of the email message.
  • the preference setting established by the user specifies rules for processing purchase transactions between the user and a specific merchant.
  • the information identifying the account includes at least one of an email address or a phone number associated with the user, an identifier associated with an instance of the mobile payment application installed on the mobile device or an identifier associated with the mobile device.
  • a mobile device for processing a purchase transaction between a merchant and a user comprising:
  • a first mobile application installed on the mobile device configured to display information relating to items for purchase from the merchant and receive a request from the user to initiate the purchase transaction to purchase an item from the merchant;
  • a mobile payment application installed on the mobile device and configured to process the purchase transaction initiated by the user at the first mobile application
  • the first mobile application further configured to:
  • the mobile payment application further configured to:
  • the mobile payment application upon receiving the confirmation from the user to proceed with the purchase transaction, is configured to send a request including the merchant identifier, the transaction amount and an identifier associated with the user to a payment service system so that the payment service system can initiate a transfer of the transaction amount from a user financial account associated with the user to a merchant financial account associated with the merchant identifier to complete the purchase transaction.
  • HTTP HyperText Transfer Protocol
  • the mobile device of example 65 wherein the first mobile application is at least one of a browser application providing access to a website associated with the merchant or a mobile application associated with the merchant installed on the mobile device.

Landscapes

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

Abstract

L'invention concerne un système et des procédés destinés à l'achat d'articles sur un site Internet ou une application mobile à l'aide d'une seule action de vérification. La technique divulguée permet à un utilisateur de lancer une transaction d'achat avec un commerçant par l'intermédiaire d'une application mobile sur un dispositif mobile et de sélectionner une application de paiement mobile associée à un système de service de paiement sous la forme d'un mode de paiement. L'application mobile fait ensuite passer au moins une valeur de transaction et un identificateur de commerçant à l'application de paiement mobile pour réaliser un traitement de transfert de la transaction d'achat à l'application de paiement mobile. L'application de paiement mobile, sur la base de réglages de préférences, le cas échéant, et sinon de réglages par défaut, détermine s'il faut demander une confirmation de l'utilisateur pour procéder à la transaction d'achat. Une fois qu'une décision de poursuivre la transaction d'achat est effectuée, l'application de paiement mobile envoie une demande au système de service de paiement pour compléter la transaction d'achat par paiement du commerçant.
PCT/US2015/032030 2014-05-21 2015-05-21 Achat par courrier électronique vérifié Ceased WO2015179681A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU2015264085A AU2015264085B2 (en) 2014-05-21 2015-05-21 Verified purchasing by email
AU2021200725A AU2021200725B2 (en) 2014-05-21 2021-02-04 Verified purchasing by email
AU2022204641A AU2022204641A1 (en) 2014-05-21 2022-06-29 Verified purchasing by email

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US14/284,224 US9922324B2 (en) 2014-05-21 2014-05-21 Verified purchasing by email
US14/283,617 2014-05-21
US14/283,617 US20150339668A1 (en) 2014-05-21 2014-05-21 Verified purchasing
US14/284,224 2014-05-21
US14/283,504 2014-05-21
US14/283,504 US20150339656A1 (en) 2014-05-21 2014-05-21 Verified purchasing by push notification

Publications (1)

Publication Number Publication Date
WO2015179681A1 true WO2015179681A1 (fr) 2015-11-26

Family

ID=54554785

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/032030 Ceased WO2015179681A1 (fr) 2014-05-21 2015-05-21 Achat par courrier électronique vérifié

Country Status (2)

Country Link
AU (3) AU2015264085B2 (fr)
WO (1) WO2015179681A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9922324B2 (en) 2014-05-21 2018-03-20 Square, Inc. Verified purchasing by email
WO2018108123A1 (fr) * 2016-12-15 2018-06-21 腾讯科技（深圳）有限公司 Procédé, dispositif, et système d'authentification d'identité
US10467615B1 (en) 2015-09-30 2019-11-05 Square, Inc. Friction-less purchasing technology
US10776809B1 (en) 2014-09-11 2020-09-15 Square, Inc. Use of payment card rewards points for an electronic cash transfer
US11042863B1 (en) 2015-03-20 2021-06-22 Square, Inc. Grouping payments and payment requests
US11823191B1 (en) 2022-08-29 2023-11-21 Block, Inc. Integration for performing actions without additional authorization requests

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20000072676A (ko) * 2000-09-19 2000-12-05 김정태 은행의 가상계좌를 이용한 금융결제 방법 및 그 시스템
US20050192893A1 (en) * 2003-11-24 2005-09-01 Keeling John E. Authenticated messaging-based transactions
US7606734B2 (en) * 2000-07-11 2009-10-20 The Western Union Company Wide area network person-to-person payment
US20120036042A1 (en) * 2010-08-05 2012-02-09 Roam Data Inc System and method for checkout and customer data capture in commerce applications
US8606703B1 (en) * 2013-03-15 2013-12-10 Square, Inc. Method for transferring money using email

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060131385A1 (en) * 2004-12-16 2006-06-22 Kim Mike I Conditional transaction notification and implied approval system
US9269104B2 (en) * 2011-01-21 2016-02-23 Paypal, Inc. Automatic detection of mobile payment applications

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7606734B2 (en) * 2000-07-11 2009-10-20 The Western Union Company Wide area network person-to-person payment
KR20000072676A (ko) * 2000-09-19 2000-12-05 김정태 은행의 가상계좌를 이용한 금융결제 방법 및 그 시스템
US20050192893A1 (en) * 2003-11-24 2005-09-01 Keeling John E. Authenticated messaging-based transactions
US20120036042A1 (en) * 2010-08-05 2012-02-09 Roam Data Inc System and method for checkout and customer data capture in commerce applications
US8606703B1 (en) * 2013-03-15 2013-12-10 Square, Inc. Method for transferring money using email

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9922324B2 (en) 2014-05-21 2018-03-20 Square, Inc. Verified purchasing by email
US10776809B1 (en) 2014-09-11 2020-09-15 Square, Inc. Use of payment card rewards points for an electronic cash transfer
US11042863B1 (en) 2015-03-20 2021-06-22 Square, Inc. Grouping payments and payment requests
US10467615B1 (en) 2015-09-30 2019-11-05 Square, Inc. Friction-less purchasing technology
US10810592B1 (en) 2015-09-30 2020-10-20 Square, Inc. Friction-less purchasing technology
WO2018108123A1 (fr) * 2016-12-15 2018-06-21 腾讯科技（深圳）有限公司 Procédé, dispositif, et système d'authentification d'identité
US11823191B1 (en) 2022-08-29 2023-11-21 Block, Inc. Integration for performing actions without additional authorization requests

Also Published As

Publication number Publication date
AU2015264085B2 (en) 2020-11-05
AU2015264085A1 (en) 2016-12-08
AU2021200725B2 (en) 2022-03-31
AU2021200725A1 (en) 2021-03-04
AU2022204641A1 (en) 2022-07-21

Similar Documents

Publication Publication Date Title
US20230033992A1 (en) Transaction completion via application interaction
US9922324B2 (en) Verified purchasing by email
US20150339656A1 (en) Verified purchasing by push notification
US12367482B2 (en) Systems and methods for digital account activation
US12277556B2 (en) Secure account creation
AU2021200725B2 (en) Verified purchasing by email
US9996837B2 (en) Integration of secure protocols into a fraud detection system
US8700527B2 (en) Merchant bill pay
US20130036000A1 (en) Financial transaction system and method
AU2011207602B2 (en) Verification mechanism
US20130018791A1 (en) Fraud data exchange system
US20160180302A1 (en) System and method for processing multiple recurring payments
US9799071B1 (en) One swipe registration
CN112368730A (zh) 使用动态安全结账元件的安全远程交易框架
US20150134508A1 (en) Expedited person to person payment
EP3391619A1 (fr) Extension de navigateur pour paiement par jeton sécurisé à utilisation limitée
BR112013021057A2 (pt) aparelhos, métodos e sistemas de pagamento eletrônico universal
US20160117679A1 (en) Automated Payment Information Update With Vendors
US20190172038A1 (en) Real-time delegated approval of initiated data exchanges by network-connected devices
US11556904B2 (en) Method, system, and computer program product for processing a payment transaction via a proxy guarantor
US10592898B2 (en) Obtaining a signature from a remote user
CN113711257B (zh) 用于经由代理保证人处理支付交易的方法、系统和计算机程序产品
US20240211931A1 (en) Method and system for approving use of mobile wallet
WO2016068871A1 (fr) Mise à jour d'informations de paiement automatisée avec des vendeurs

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2015264085

Country of ref document: AU

Date of ref document: 20150521

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 15795637

Country of ref document: EP

Kind code of ref document: A1