WO2021022207A1 - Plate-forme de cartes de paiement à valeur stockée - Google Patents

Plate-forme de cartes de paiement à valeur stockée Download PDF

Info

Publication number
WO2021022207A1
WO2021022207A1 PCT/US2020/044594 US2020044594W WO2021022207A1 WO 2021022207 A1 WO2021022207 A1 WO 2021022207A1 US 2020044594 W US2020044594 W US 2020044594W WO 2021022207 A1 WO2021022207 A1 WO 2021022207A1
Authority
WO
WIPO (PCT)
Prior art keywords
stored
gift
payment card
value payment
platform
Prior art date
Application number
PCT/US2020/044594
Other languages
English (en)
Inventor
Hamid LOTFOLLAHI
Original Assignee
Iigc, 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
Application filed by Iigc, Inc. filed Critical Iigc, Inc.
Publication of WO2021022207A1 publication Critical patent/WO2021022207A1/fr

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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342—Cards defining paid or billed services or quantities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models
    • G06Q20/28—Pre-payment schemes, e.g. "pay before"
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • 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/321—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wearable 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/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F17/00—Coin-freed apparatus for hiring articles; Coin-freed facilities or services
    • G07F17/0014—Coin-freed apparatus for hiring articles; Coin-freed facilities or services for vending, access and use of specific services not covered anywhere else in G07F17/00
    • G07F17/0035—Participation in a loyalty or discount scheme

Definitions

  • This patent document relates generally to stored-vaiue payment cards.
  • hosting merchants on a stored-vaiue payment card platform hosting merchants on a stored-vaiue payment card platform.
  • E-commerce techniques allow users to purchase goods and services via the internet with a simply by clicking or tapping a button in a user interface. Such purchases may be difficult to make using physical money. People may wish to use stored-vaiue payment cards, such as gift cards, to make such purchases. Furthermore, online social networking systems have connected people across the globe facilitating creation of friendships over the internet. People may wish to purchase gifts to maintain friendships and strengthen bonds. BRI EF DESCRIPTION OF THE DRAWI NGS
  • Figure 1 illustrates an example of a simplified block diagram of computing environment in which a gift platform is operating, in accordance with some implementations.
  • Figure 2 illustrates an example of a simplified block diagram of computing environment in which a gift platform is operating, in accordance with some implementations.
  • Figure 3 illustrates an example of a method for hosting merchants on a stored-value payment card platform, in accordance with some implementations.
  • Figure 4 illustrates an example of a method for automatically recommending gifts for an entity based on one or more attributes of the entity performed in accordance with some implementations.
  • Figure 5 illustrates an example of a simplified block diagram of a system for automated gift recommendation, in accordance with some implementations.
  • Figure 6 illustrates an example of a method for automatically distributing funds associated with stored-value payment cards, in accordance with some implementations.
  • Figure 7 illustrates an example of a simplified block diagram of a computing system, in accordance with some implementations.
  • Figure 8 illustrates an example of a simplified block diagram of another computing system, in accordance with some implementations.
  • Figure 9 illustrates an example of a simplified block diagram of a further computing system, in accordance with some implementations.
  • Figure 10 illustrates one example of a computing device, configured in accordance with some implementations.
  • Figure 11 illustrates an example configuration of a neural network, configured in accordance with some implementations.
  • Some implementations of the disclosed systems, apparatus, methods and computer program products are configured for implementing a platform configured to process transactions related to stored-vaiue payment cards.
  • a platform may provide an environment to merchants who wish to offer stored-vaiue payment cards for their business.
  • businesses include but are not limited to a small corner store, a restaurant, a manufacturing company, a brick and mortar retail store, an E- commerce company, a law firm, a direct to consumer farm, a courier service provider, etc.
  • apparatus, methods and computer program products are configured for implementing a platform configured to provide automated gift recommendation.
  • a platform may provide recommendations to users who wish to purchase gifts for any entity such as another person, a couple, a sports team, an organization, a pet, a celebrity, a charitable cause, a group of people etc.
  • gifts as described herein may refer to a range of subject matter and may vary across implementations.
  • a gift may include specific goods and services (e.g , a trip, a massage, delivered food, electronics, etc.), a stored-value payment card (e.g., a gift card), a charitable donation, a greeting card, access to a group or event, etc.
  • specific goods and services e.g , a trip, a massage, delivered food, electronics, etc.
  • a stored-value payment card e.g., a gift card
  • a charitable donation e.g., a greeting card, access to a group or event, etc.
  • Belle may use her smartphone to open a mobile application (app) provided by a gift platform, such as OffGifter, as discussed further below.
  • She may request a gift recommendation for Charles via a user interface of the app.
  • the app may use a recommendation engine that applies predictive analytics to data relating to Charles (e.g. consumer data containing his purchase history, his social networking data such as his posts or profile information, etc.) and data relating to others who share attributes with Charles (e.g., age, gender, location, etc.) to generate a gift recommendation for Charles.
  • the recommendation engine may generate a recommendation that Belle purchase Charles several cooking gadgets based on Charles's extensive purchases relating to cooking.
  • Belle presents the cooking gadgets to Charles they may discover a mutual love of cooking, which becomes a frequent conversation topic during the next few months, leading to a cordial and effective working relationship.
  • apparatus, methods and computer program products are configured to automatically distribute funds associated with purchase or activation of stored-value payment cards, such as gift cards.
  • Montague Enterprises is a conventional gift card provider looking to increase their market share in the gift card industry.
  • Formaggio Verona is an artisan cheese shop that is looking to sell their cheeses internationally via their new app and website.
  • Montague Enterprises and Formaggio Verona are limited to promoting their gift card program using conventional advertising and word of mouth. As such, Montague Enterprises and Formaggio Verona receive only a small portion of the market share and are unable to grow to their full potential.
  • the disclosed techniques can be used to incentivize customers to purchase gift cards from a particular gift card provider, benefiting merchants, customers, and the gift card provider alike.
  • Offgifter implements a new marketing campaign where ail customers who purchase or activate gift cards via Offgifter are entered into a lottery free of charge.
  • Offgifter places funds associated with the transaction (e.g., a portion of the proceeds from the transaction) in a "pot.”
  • Offgifter also places funds associated with transactions in which customers purchase gift cards for other merchants in the pot.
  • the pot rapidly grows.
  • a user purchases a gift card from Offgifter the user is givers a "ticket" with a chance to win a periodic (e.g., hourly, daily, weekly, bi-weekly, etc.) drawing.
  • the winner of the drawing wins a portion of the funds in the pot.
  • the marketing campaign goes viral. Accordingly, both Offgifter and Formaggio Verona to vastly increase their market share. Furthermore, some lucky Offgifter customers become instant millionaires. As a result of the viral marketing campaign, the pot becomes even larger before each periodic drawing as more customers buy gift cards from Offgifter. As such, Offgifter continues to grow its customer base.
  • FIG 1 illustrates an example of a simplified block diagram of computing environment 100 in which a gift platform 104 is operating, in accordance with some implementations.
  • the gift platform 104 may be implemented using a variety of computing devices, server systems, database systems, etc. (e.g., system 1000 of Figure 10).
  • customers 108(a)-(n) of Figure 1 may use computing devices to interact with the gift platform 104 for a variety of functions such as stored-value card purchasing and/or activation service 116.
  • the customers 108(a)-(n) may use their computing devices to purchase stored-value payment cards (e.g., gift cards) or other gifts from the gift platform 104.
  • the customers 108(a)-(n) may use their computing devices to automatically activate stored-value payment cards via the gift platform 104 without a need for a human intermediary.
  • merchants 112(a)-(n) of Figure 1 may use computing devices to interact with the gift platform 104 for a variety of functions such as stored-value payment card hosting platform 120
  • some of the merchants 112(a)-(n) may not have the resources to maintain their own stored-value payment card services.
  • the gift platform 104 may host stored-value payment card services on behalf of some of the merchants 112(a)- (n).
  • the customers 108(a)-(n) may activate and purchase store payment cards via service 116 and use these stored-value payment cards by purchasing goods and services directly from the merchants 112(a)-(n).
  • the merchants 112(a)-(n) may also activate and purchase stored-payment cards via service 116 and offer the stored-value payment cards directly to their customers at the merchant's physical location.
  • stored-value payment cards as described here may refer to a range of items such as a physical gift card, digital gift card, a voucher, a gift certificate, mobile gift cards stored on a smart phone, etc.
  • Stored-value payment cards can be delivered digitally (e.g., through email or short messaging service, a.k.a., SMS) or physically through a mail service.
  • customers 108(a)-(n) merchants 112(a)-(n) may use gift platform 104 to purchase and redeem stored-value payment cards.
  • Gift platform 104 includes a gift recommendation engine 124 for providing automated gift recommendations.
  • gifts as described herein may refer to a range of subject matter and may vary across implementations.
  • a gift may include specific goods and services (e.g., a trip, a massage, delivered food, electronics, etc.), a stored-value payment card (e.g., a gift card), a charitable donation, a greeting card, access to a group or event, etc.
  • the gift platform 104 through Offers Engine 128 may be used to provide and maintain special offers for both the customers 108(a)- (n) and the merchants 112(a)-(n).
  • special offers may include, for example, coupons, gifts, discounts, and/or other such incentives.
  • the gift platform 104 may generate and maintain a special offer infrastructure (e.g., coupons, discounts, promotion codes, etc.) for the merchants 112(a)-(n).
  • the gift platform 104 may also provide such special offers directly to the customers 108(a)-(n).
  • discounts may be automatically provided to users on special occasions such as birthdays, anniversaries, holidays, etc.
  • the gift platform 104 may be provided to the customers 108(a)-(n) and the merchants 112(a)-(n) in a variety of manners, e.g., via an mobile application (app) or a web page accessible via a web browser. Also or alternatively, the gift platform 104 may maintain or access a variety of databases 132(a)-(n) to perform the above described functions or any additional functions.
  • databases 132(a)-(n) may include stored-value payment card data (e.g., data for particular gift cards such as balance information) for a merchant 112(a)-(n) for whom the gift platform 104 is hosting a stored-value payment card program, user account information associated with a merchant 112(a)-(n), user account information associated with customers 108(a)-(n), etc.
  • stored-value payment card data e.g., data for particular gift cards such as balance information
  • the gift platform 104 may be used for any combination of functions.
  • Franklin Sisters Market may be one of the merchants 112(a)-(n) of the gift platform 104.
  • a customer may purchase a gift card redeemable at Franklin Sisters Market from the comfort of his living room simply using his smartphone to access an app provided by the gift platform 104
  • the purchased gift card may be automatically transmitted to the customer's smartwatch as a quick response (QR) code.
  • QR quick response
  • the customer may quickly activate the gift card herself using her smartwatch via the activation function of the gift platform 104.
  • the gift platform 104 may also be host a gift card program for Franklin Sisters Market because Franklin Sisters Market does not have the resources to maintain its own gift card program, as discussed above.
  • FIG 2 illustrates an example of a simplified block diagram of computing environment 200 in which a stored-value payment card platform 204 is operating, in accordance with some implementations.
  • the stored -value payment card platform 204 may be implemented using a variety of computing devices, server systems, database systems, etc. (e.g., system 1000 of Figure 10.)
  • customers 208(a)-(n) of Figure 2 may use computing devices to interact with the stored-value payment card platform 204 for a variety of functions such as stored-value payment card activation platform 216.
  • the customers 208(a)-(n) may use their computing devices to purchase stored-value payment cards (e.g., gift cards) or other gifts from the stored-value payment card platform 204.
  • the customers 208(a)-(n) may use their computing devices to automatically activate stored-value payment cards via the stored-value payment card platform 204 without a need for a human intermediary.
  • merchants 212(a)-(n) of Figure 2 may use computing devices to interact with the stored-value payment card platform 204 for a variety of functions such as stored-value payment card hosting platform 220.
  • some of the merchants 212 ⁇ a)-nn) may not have the resources to maintain their own stored-value payment card services.
  • the stored-value payment card platform 204 may host stored-value payment card services on behalf of some of the merchants 212(a)-(n).
  • the customers 208(a)-(n) may activate and purchase store payment cards via stored-value payment card platform 204 and use these stored-value payment cards by purchasing goods and serviced directly from the merchants 212(a)-(n).
  • the merchants 212(a)-(n) may offer the stored-value payment cards directly to their customers at the merchant's physical location.
  • stored-value payment cards as described here may refer to a range of items such as a physical gift card, digital gift card, a voucher, a gift certificate, mobile gift cards stored on a smart phone, etc.
  • Stored-value payment cards can be delivered digitally (email or SMS) or physically through a mail service.
  • customers 208(a)-(n) may use stored-value payment card platform 204 to purchase and redeem stored -value payment cards.
  • Stored-value payment card platform 204 includes a gift recommendation engine 224 for providing automated gift recommendations.
  • gifts as described herein may refer to a range of subject matter and may vary across implementations. For instance, a gift may include specific goods and services (e.g , a trip, a massage, delivered food, electronics, etc.), a stored-value payment card (e.g., a gift card), a charitable donation, a greeting card, access to a group or event, etc.
  • the stored-value payment card platform 204 through Offers Engine 228 may be used to provide and maintain special offers for both the customers 208(a)-(n) and the merchants 212(a)-(n).
  • special offers may include, for example, coupons, gifts, discounts, and/or other such incentives.
  • the stored-value payment card platform 204 may generate and maintain a special offer infrastructure (e.g., coupons, discounts, promotion codes, etc.) for the merchants 212(a)-(n).
  • the stored-value payment card platform 104 may also provide such special offers directly to the customers 208 ⁇ a)-(n).
  • discounts may be automatically provided to users on special occasions such as birthdays, anniversaries, holidays, etc.
  • the stored-value payment card platform 204 may be provided to the customers 208(a)-(n) and the merchants 212(a)-(n) in a variety of manners, e.g., via an mobile application (app) or a web page accessible via a web browser. Also or alternatively, the stored-value payment card platform 204 may maintain or access a variety of databases 232(a)-(n) to perform the above described functions or any additional functions.
  • databases 232(a)-(n) may include stored-value payment card data (e.g., data for particular gift cards such as balance information) for a merchant 212(a)-(n) for whom the stored- value payment card platform 204 is hosting a stored-value payment card program, user account information associated with a merchant 212(a)-(n), user account information associated with customers 208(a)-(n), etc.
  • stored-value payment card data e.g., data for particular gift cards such as balance information
  • Figure 3 described in the context of Figure 1, illustrates an example of a method for hosting merchants on a stored-value payment card platform, in accordance with some implementations.
  • a request to create a merchant account is processed.
  • merchant 112(a) of Figure 1 may send a request to gift platform 104.
  • that request is processed by gift platform 104, but in other implementations the request is routed to stored- value hosting platform 120 to be processed.
  • the request may be from a merchant that would like add a stored-value payment card program for their business.
  • a request to create a merchant account can include basic information about the merchant (name of principal, address, baking information, etc.).
  • a request to create a merchant account can include requests to create additional merchant accounts for a merchant previously enrolled In the services provided by gift platform 104.
  • Franklin Sisters Market may have two store locations, and Brit would like to have a merchant account for one location and separate merchant account for the other location. As such, she would be able to create two accounts on stored-value card hosting platform 120.
  • the request to create an account may be sent by merchant 112(a) through different manners.
  • merchant 112(a) navigates to a website controlled by gift platform 104; merchant 112(a) is prompted to enter basic account on a webpage set up for account creation.
  • merchant 112(a) installs an app controlled by gift platform 104 on their smart device and provides the necessary information to gift platform 104 via the app.
  • customer 108(a) would like to order a stored-value payment card for a merchant not yet using the services provided by stored- value card hosting platform 120. As such, the customer can request that the merchant use stored-value payment card hosting platform 120.
  • gift platform 104 can use contact information provided by the customer, or contact information obtained otherwise via a third-party contact information provider that has been previously stored in database 132(a).
  • Gift platform 104 may automatically send a text message, email, or automated phone call requesting that the merchant create a merchant account through stored-value payment card hosting platform 120.
  • the request from gift platform 104 includes information about the customer, a dollar amount that the customer would like to add to stored-value payment card, and/or information indicating that the customer has already purchased the stored- value payment card and that the merchant only needs to create a merchant account to receive payment via the stored-value payment card.
  • gift platform 104 of Figure 1 may send a notification to merchant 112(a) indicating that their account has been successfully activated.
  • the notification may be in the form of a text message, phone call, push notification email, or some other form of audio-visual prompt indicating that the merchant has been enrolled in the services provided by stored-value card hosting platform.
  • the customer may also receive a notification that the merchant has joined the platform.
  • the stored-valued payment card hosting platform offers various advantages to merchants.
  • small merchants may lack the infrastructure to host their own payment card platform.
  • Traditional gift card providers charge large fees and conduct business through bespoke techniques, further increasing costs.
  • the currently described techniques allow for lower cost hosting and transfer of payment cards.
  • the techniques described herein may automatically meet regulatory requirements. Smaller merchants, lacking robust accounting resources, may traditionally find it difficult to navigate the various ways of accounting for payment card sales (e.g., the Internal Revenue Service includes specific guidance on how to account for gift cards).
  • the techniques described herein may be combined with an automatic system for accounting for payment card sales, reducing the resource burden on the merchant. The merchant may thus be allowed to take advantage of payment card sales while minimizing the costs and burdens of offering payment cards.
  • the financial accounting of payment cards may be shifted.
  • the merchant may take advantage of the financial sales of payment cards while avoiding the accounting disadvantages.
  • merchants may self -host their payment card storefronts while taking advantage of pre- built online structures, as described herein.
  • a request for stored value payment cards is received.
  • the request is sent by customer 108(a) of Figure 1 via gift platform 104.
  • An example involving these implementations is the scenario where Karl purchases a gift card for $40 dollars to Franklin Sisters Market as a gift for his friend Martha in other implementations, the request for stored-value payment cards is sent by merchant 112(a).
  • An example involving these implementations is the scenario where Franklin Sisters Market would like to stock physical gift cards at their retail location.
  • physical gift cards purchased in a retail store are automatically activated using an image- based authorization techniques.
  • a customer or a merchant on behalf of a customer may activate a stored-value payment card after purchasing the stored-value payment card in person in some implementations, the customer activates the stored-value payment card by opening an app and taking a picture of the barcode or other identifying characters with their smart device.
  • a customer can order gift cards through a website focused on businesses located near the customer. There may be a variety of locations categorized according neighborhood, city, county, etc. For example, a customer located in Oakland may be shown a webpage with businesses in and around Oakland. And a customer located in Seattle may be shown a webpage with businesses in and around Seattle.
  • This website can be controlled by gift platform 104 the location of the customer based on a variety of attributes such as current location, location history, the address provided by the customer when the customer set up their account on gift platform 104, etc. in some implementations, a customer can pick up their stored-value payment card in person after purchasing the stored-value payment cards
  • a request to redeem a stored value payment card is received.
  • the request to redeem is for the entire value of the stored-value payment card.
  • the value can be less than the total redeemable value of the stored-value payment card (e.g., $20 of $100 of totally redeemable value).
  • the value of a stored-value payment card can be represented by any metric of currency (USD, Euro, gold), including cryptocurrencies such as Bitcoin, Ethereum, Litecoin, OffGifterCoin (controlled by the provider of gift platform 104 of Figure 1), etc.
  • the request to redeem a stored-value payment card can be sent by a user's device while they are in or near the location of the merchant associated with the stored-value payment card in this case, a customer or a merchant on behalf of a customer may use an app to take a picture of a barcode (or manually enter the numbers of the barcode) to purchase the items with the stored-value payment card. Also or alternatively, the request to redeem the stored-value payment card can be sent by a user that is remotely located to the merchant.
  • a customer may use an app in a similar manner to the previous example, or the customer can navigate to a website controlled by gift platform 104 (or proxy website of the merchant, which communicates with gift platform 104 through an API) and enter the stored-value payment card information using a check out form for collecting information necessary to complete the transaction.
  • the request is authorized and funds are provided to the merchant.
  • Funds can be provided to the merchant at different rates or frequency.
  • stored-value payment card hosting platform can provide funds to the merchant for each transaction, hourly, daily, weekly, monthly, etc.
  • funds are not transferred to the merchant until the customer redeems the stored-value payment card with the merchant.
  • the funds Prior to sending the funds to the merchant, the funds can be held by financial institutions associated with the provider of the stored-value payment card hosting platform in other implementations, the funds are held by a third- party not controlled by either the merchant or the provider of the stored-value payment card hosting platform.
  • the entire amount of a stored- value payment card can be deposited directly into a bank account associated with a merchant around the time when the customer orders the stored-value payment card.
  • Figure 4 illustrates an example of a method 400 for automatically recommending gifts for an entity based on one or more attributes of the entity performed in accordance with some implementations.
  • Figure 4 is described in the context of Figure 5, which illustrates an example of a simplified block diagram of a system for automated gift recommendation system, in accordance with some implementations.
  • a request for a gift recommendation is processed.
  • recommendation request 500 of Figure 5 may be received by recommendation engine 504.
  • the recommendation engine 504 may be implemented by a gift platform such as gift platform 104 of Figure 1, as described above.
  • Request 500 may be a request from a user of the gift platform (e.g , Belie) for a recommendation of a gift to purchase for an entity (e.g , Tim).
  • a user of the gift platform e.g , Belie
  • Belle may wish to buy Tim a Christmas gift; however she knows little about his interests.
  • Belle may open an app provided by a gift platform on her smartphone. She may navigate to a "recommendations" portion of the app. She may then enter in some information identifying Tim, such as his full name, his physical address, his email address, etc.
  • a gift recommendation is generated.
  • the recommendation engine 504 may apply predictive analytics 508, use locations 512, access wish lists 516, apply any other suitable recommendation procedures, and/or use any combination of these techniques, as discussed below.
  • a recommendation engine may use predictive analytics 508 based on an attribute of an entity to determine a gift recommendation for that entity.
  • statistical inference techniques such as frequentist or Bayesian inference
  • machine learning and artificial intelligence techniques such as a random forest model or a deep neural network may be used to determine a gift recommendation.
  • the gift recommendation platform may have access to training data 520.
  • Training data 520 may be any type of data that may be processed by predictive analytics 508 to predict what gifts might be desired by particular entities, e.g., the training data 520 may include third party data and/or data internal to the gift platform.
  • the training data 520 may include consumer data accessed by the gift platform, social networking data, internet search history data, textual content of e-mails to and from the entity, biometric data relating to the entity, internal consumer data collected by the gift platform, etc.
  • the recommendation engine 504 might process Tim's email address to identify Tim's user name in a social networking system.
  • the recommendation engine 504 may parse the content of Tim's profile in the social networking system.
  • the recommendation engine 504 may analyze the parsed content to identify various attributes about Tim (e.g., his age, location, profession, etc.) Using the training data 520, the predictive analytics 508 may have determined that over 99% of people with certain shared attributes with Tim (e.g., 30 year old males who live in Anchorage Alaska and enjoy shopping at a particular store such as The Ghost's Closet, a vintage clothing store frequented by Tim) like a particular gift. As such, the recommendation engine 504 may generate the specific recommendation 524 that Belie should purchase Tim the particular gift.
  • Tim e.g., his age, location, profession, etc.
  • gift recommendations may be generated based at least in part on wish lists 516 of Figure 5.
  • Such "wish lists” may be a preference list containing a list of gifts desired by a particular entity.
  • Tim may be using his smartphone to interact with an app provided by the gift platform 104 of Figure 1.
  • the app may include a user interface configured to receive Tim's wish list. Tim may enter his wish list via the user interface.
  • a recommendation engine such as the recommendation engine 504 of Figure 5, may access Tim's wish list when making gift
  • the recommendation engine 504 may generate a recommendation that Belle buy Tim a particular video game system, since the particular video game system is at the top of Tim's wish list.
  • wish lists may be seamlessly integrated with both a gift platform and social networking systems such as Facebook ® .
  • Tim's wish list may be provided to the social networking systems to which Tim belongs.
  • his wish list may be automatically associated with his profiles in each of the social networking systems such that those connected with and/or following Tim can view his wish list.
  • users of the social networking systems may band together to purchase gifts for Tim from his wish list.
  • the gift platform may send data to the social networking systems such that the soda! networking systems send a notification to those connected with and/or following Tim that Tim's birthday is approaching.
  • the notification may contain Tim's wish list and may be configured to allow those connected with and/or following Tim to contribute to purchasing gifts for Tim.
  • the gift platform may process monetary contributions from users of the social networking systems and/or gift recommendation platform towards payment for the video game system for Tim. Once there are sufficient contributions, it may be determined that a total monetary value of the contributions is at least equal to a cost of the video game system. In response to this determination, the gift platform may automatically purchase the video game system for Tim using the monetary contributions.
  • a user may be provided with a discount for completing the purchase him or herself.
  • Tim may be given a 10% discount if he contributes the remaining funds to purchase the videogame system himself.
  • gift recommendations may be generated based at least in part on locations 512 of Figure 5.
  • the recommendation engine 504 may determine a location associated with Tim (e.g., his home address, his work address, his current geolocation, etc.). The recommendation engine 504 may then determine that a particular merchant location is near Tim. As such, the recommendation engine 504 may recommend that Belle purchase Tim a stored-value payment card configured to be used to buy goods or services from the particular merchant.
  • the particular merchant may be using the gift platform 104 as a stored- value payment card hosting platform.
  • the recommendation engine 504 may only generate a particular specific recommendation 524 of purchasing a gift for an entity in certain circumstances.
  • a specific recommendation 524 for a particular gift for an entity may only be made if the recommendation engine 504 determines that the entity has a probability greater than a particular probability threshold (e.g., 99%, 95%, 50%, etc.) of wanting the particular gift.
  • a particular probability threshold e.g., 99%, 95%, 50%, etc.
  • the recommendation engine 504 may only generate a particular specific recommendation 524 of a gift for Tim if it is determined that there is at least a 95% chance that Tim will like the gift.
  • the recommendation engine 504 may generate a general recommendation 528 that Belie should purchase Tim a general gift such as a stored-value payment card configured to be redeemed via a stored-value payment card hosting platform.
  • the stored-value payment card may be configured to be used to purchase goods and services at any merchant hosted by the stored-value payment card hosting platform, as described above in the context of Figure 1.
  • the gift recommendation is transmitted.
  • the recommendation engine 504 may transmit a
  • the recommendation engine may be trained based on an entity's interaction with a gift.
  • the recommendation engine 504 may generate a general recommendation 528. Outcomes of the general recommendation 528 may be used as training data 520 to improve the recommendation engine 504.
  • consumer data associated with purchases made using the stored- value payment card described above may be retrieved.
  • Tim may use the stored-value payment card to purchase pizza at Dickens' Pizza. This purchase may be stored in a database 132(a)-(n) of the gift platform 104 of Figure 1, since the gift platform 104 hosts stored-value payment services for Dickens' Pizza.
  • the recommendation engine 504 may use consumer data as training data for artificial intelligence or a machine learning algorithm the consumer data to make future gift recommendations for entities with similar attributes to Tim.
  • the recommendation engine 504 may recommend a gift of Dickens' Pizza (e.g., a delivery of pizza, a stored-value payment card for Dickens' Pizza, etc.) for people that share attributes with Tim that the recommendation the recommendation engine 504 determines to be predictive of Tim's liking of pizza.
  • Dickens' Pizza e.g., a delivery of pizza, a stored-value payment card for Dickens' Pizza, etc.
  • the disclosed techniques may be used to send automated thank you notes.
  • Tim may be using his smartphone to interact with an app provided by the gift platform 104 of Figure 1.
  • the app may send Tim a push notification reminding him to send Belie a thank you card.
  • Tim clicks or taps the push notification he may be presented with a user interface configured to allow him to send an automated thank you note to Belle. Tim may enter/customize the text of the thank you note.
  • the thank you note may come pre-populated with automatically generated text based on information that the gift platform 104 can Infer about Tim and/or Belle
  • the gift platform may send Belle the automated thank you note in a variety of manners, e.g., as an electronic note sent via SMS text or e-mail, a printed card sent via the United States Postal Service, etc.
  • Figure 6 described below in the context of Figure 2, illustrates an example of a method 600 for automatically distributing funds associated with stored- value payment cards, in accordance with some implementations.
  • a request to purchase or activate a stored-value payment card is processed.
  • Juliet may use her iPhone ® to purchase a $50 gift card to Formaggio Verona for her fiance Paris.
  • Juliet may purchase the gift card via the stored-value payment card platform 204 of Figure 2, which is operated by Offgifter.
  • a portion e.g., a percentage such as .01%, .5%, 1%, 3%, etc.
  • a portion of the proceeds from a purchase or activation of a stored-value payment card may be delivered to a stored-value payment card provider.
  • Offgifter may receive 1% of funds associated with purchase or activation of gift cards using the stored-value payment card platform 204 of Figure 2. As such, Offgifter may receive a $0.50 from Juliet's purchase of the $50 gift card to Formaggio Verona.
  • a user is presented with an option via a user interface.
  • a user may be presented with an option configured to allow the user to donate the funds associated with the purchase or activation of the stored-value payment card to a charity in lieu of receiving a lottery ticket.
  • the charity may be selectable by the user.
  • Juliet may be presented with a menu in the user interface of her iPhone ® after purchasing the $50 gift card to Formaggio Verona. The menu may allow Juliet to donate a portion (e.g., a percentage such as .01%, .5%, 1%, 3%, etc.) of the $0.50 Offgifter may be received from her purchase of the $50 gift card to Formaggio Verona to a charity of her choosing. For instance, Juliet may donate $0.05 to Tybalt's Tykes, a charity which provides clothing to children in need.
  • Offgifter may be implementing a marketing campaign where all customers who purchase or activate gift cards via Offgifter are entered into a lottery free of charge. As such, a portion of proceeds from each purchase or activation of a gift card via Offgifter may be automatically transferred into the pot. By way of example, a portion (e.g., a percentage such as .01%, .5%, 1%, 3%, etc.) of the $0.50 Offgifter received from Juliet's purchase of the $50 gift card to Formaggio Verona may be automatically transferred into the pot.
  • a ticket is provided to a user via a device.
  • a device For example,
  • the ticket may be associated with any type of code capable of being of being drawn in a lottery.
  • the code may be a set of six two digit numbers between zero and sixty, e.g., the code may be "02 09 21 32 33 58.”
  • the code may be an alpha- numeric entity selected by the user.
  • the code may be a random alpha-numeric generated by the stored-va!ue payment card platform 204 of Figure 2.
  • a ticket as discussed herein, may be any physical or electronic entity capable of being associated with a code.
  • the ticket may be one of a plurality of tickets entered into a lottery.
  • the lottery may be a periodic drawing of winning codes.
  • a portion of the pot may be distributed to any entities having tickets associated with the winning codes.
  • Juliet's ticket is associated with the code "03 14 17 31 51 59.”
  • the stored-value payment card platform 104 may draw the code "03 14 17 31 51 59" as the winning code.
  • the pot may contain $16 million, and there may be two users with tickets associated with the code "03 14 17 31 51 59.” Since Juliet is one of two users with a ticket associated with a winning code, she may receive 50% of the pot or $8 million in some implementations, she may elect to receive a reduced lump-sum payment or receive the $8 miilion as an annuity over a period of time such as 30 years.
  • users may receive prizes for having a ticket associated with a partially winning code.
  • the winning code is a set of six two digit numbers
  • the code associated with Romeo's ticket contains three of the six numbers in the winning code
  • Romeo may receive a small percentage of the pot (e.g., Q.1%.)
  • funds may be provided to an entity.
  • Offgifter may provide merchants 212(a)-(n) with a portion of the funds associated with each purchase or activation of a stored- value payment card for the merchants 212(a)-(n).
  • Offgifter may provide 1% of the $0.50 that Offgifter received from Juliet's purchase of the $50 gift card back to Formaggio Verona.
  • a portion of the funds associated with the purchase or activation of the stored-value payment card may be provided to an external organization or government entity.
  • lottery programs must fund particular state government entities such as state educational systems. Therefore, in order to operate in such a state a stored- value card provider may provide funds to a state organization such as the state department of education.
  • a person having skill in the art can appreciate that disclosed techniques can be applied to create a marketing campaign for any type of purchase beyond purchase or activation of stored-value payment cards.
  • proceeds for any purchase e.g., purchase of any goods or services
  • a periodic drawing may be conducted as disclosed herein.
  • Certain techniques described herein involve a plurality of merchant storefront that includes multiple panels (e.g., webpages or portions of webpages) in front-end applications.
  • the techniques described herein may, in certain implementations, be performed through such storefronts.
  • the storefronts may cover a plurality of different jurisdictions (e.g., different countries, states, provinces, cities, and/or other such jurisdictions that may include different laws and regulations).
  • the systems of Figures 7-9 allow for a framework that automatically processes tasks for developing the front-end applications. Such a framework minimizes software bugs, provides a robust user experience (e.g., for merchants), provides for an improved design experience, and reduces development time.
  • the systems of Figures 7-9 prevent the need to write duplicate code, thus ensuring higher quality and faster development time of the front-end applications.
  • the systems of Figures 7-9 are configured to control the look and feel of front-end applications and/or front-end merchant storefronts from configurations and settings provided within the systems of Figures 7-9.
  • the systems of Figures 7-9 utilize object-relational mapping (ORM) to process data between the various APIs, databases, and other components.
  • ORM object-relational mapping
  • the systems of Figures 7-9 provides tools such as helper functions, hook functions, and services that can be used in front-end applications while being housed in the back-end.
  • the systems of Figures 7-9 also support multilingual application and user interface and user experience customizations without the need for additional code.
  • Figure 7 illustrates an example of a simplified block diagram of a computing system, in accordance with some implementations.
  • Figure 7 illustrates a computing system with application 702 and engine package 704.
  • Application 702 may be an application installed on a user electronic device. Such a device may be, for example, a desktop computer, a laptop computer, a tablet, a smartphone, and/or another such electronic device that allows for a user to promote inputs and/or receive information. In certain implementations, application 702 may allow for a user to purchase gift and/or SIM cards, provide gift and/or SIM cards for sale/resale, and/or gift cards to other entities. In certain such implementations, application 702 may allow for a seller or reseller to set up a storefront utilizing the systems and techniques described herein.
  • Engine package 704 may be a server device or a portion thereof.
  • Engine package 704 may be configured to, for example, generate and/or provide a storefront of a seller and/or reseller of gift/SIM cards, provide for the selling and/or reselling of gift/SIM cards, aid in the sale and/or resale of gift/SIM cards (e.g., through verification of a buyer's identity, through approving a sale, through transfer of a gift card, etc.).
  • the various systems and techniques may be implemented by systems that include processors, memories, and other devices.
  • the processor may include single and/or multi- core processors configured to perform one or more operations.
  • the memory may include transitory and non-transitory memory configured to store data. Such non-transitory memory may be configured to store instructions to perform one or more techniques as described herein.
  • Engine package 704 allows for the creation and implementation of various APIs and processes as described herein.
  • Engine package 704 includes engine 706 and layout 708.
  • engine 706 may allow for creating, reading, updating, and deleting resources.
  • Various components of engine 706 may also implement the techniques described herein and may, for example, output data as described herein to various users (e.g., customers and/or merchants).
  • Engine 706 may include form engine 710, table engine 712, and storage engine 714. in various implementations, engine 706 includes form engine 710, table engine 712, and storage engine 714.
  • Layout 708 provides for the implementation of application logic for the processes as described herein, including processes such as middleware 716, localization 718, service 720, access rights 722, error handling 724, and analytics 726. Such processes may be tailored to specific merchants and jurisdictions and allow for conforming of sales to such specific jurisdictions in certain implementations, engine package 704 may utilize object-relational mapping to perform the creating, reading, updating, and deleting actions.
  • Figure 8 illustrates an example of a simplified block diagram of another computing system, in accordance with some implementations.
  • Figure 8 illustrates a computing system that includes user 802, API 804, API service 806, engine package 808, and resource engine 810.
  • User 802 may utilize an electronic device (a.k.a., user device) that includes one or more applications for purchasing, gifting, selling, and/or reselling gift cards and/or SIM cards.
  • the one or more applications may allow for transactions to be conducted as described herein in certain implementations, the applications are associated with API 804.
  • user 802 may include data directed to the user, such as identifying information including one or more of a user ID, a username, an identification number, and/or other such information.
  • API 804 may be APIs associated with performing one or more techniques as described herein. API 804, in certain implementations, allow for applications to perform the techniques described herein.
  • API service 806 may maintain API 804 and may, for example, maintain aspects of API 804 based on data from engine package 808. Thus, based on data from engine package 808, API service 806 may update API 804.
  • Engine package 808 includes storage 812, metadata 814, and operational data 816.
  • Engine package 808 may be configured to create, read, update, and delete various resources.
  • the configuration of engine package 808 allows for a more straight forward experience when, for example, configuring a storefront for a user and/or allowing for a developer to configure an API for the creation of storefronts, as described herein.
  • the configuration of engine package 808 allows for efficient querying of resources, insertion of new records, and/or updating and deleting of records.
  • API service 806 allows for all API interactions with data to be performed through engine package 808.
  • engine package 808 manages the relationship between data stored in various portions of engine package 808.
  • the system described in Figure 8 allows for create, read, update, and delete actions to be performed for data that links a plurality of different entities.
  • a first entity may include a foreign key that references the primary key of a second entity.
  • One or more of such keys may be updated and the system of Figure 8 allows for an update of one key to affect the other entity.
  • engine package 808 is configured for ORM.
  • QRM with engine package 808 allows for API service 806 and/or API 804 to interface with the various databases.
  • data from the database e.g., storage 812, metadata 814, and operational data 816) may be queried, edited, and/or inserted into API 804 through, for example, API service 806 without requiring changes of format.
  • ORM may be utilized to store form metadata (e.g., metadata directed to the form of the application), store table metadata (e.g., metadata directed to the various tables for communicating data), support custom storage types and/or database configurations, retrieve, delete, insert, and/or update data from the databases described herein, management of one- to-one and one-to-many relationships, data filtering, data sorting, and/or pagination.
  • form metadata e.g., metadata directed to the form of the application
  • table metadata e.g., metadata directed to the various tables for communicating data
  • support custom storage types and/or database configurations retrieve, delete, insert, and/or update data from the databases described herein, management of one- to-one and one-to-many relationships, data filtering, data sorting, and/or pagination.
  • Storage 812 may be configured to store data and/or connect to and transfer data to API service 806 and/or API 804. Storage 812 may be configured to store data as described herein. Storage 812 may include a plurality of functions, such as get 818, save 820, and delete 822. Storage 812 includes its own get 818, save 820, and delete 822 functions in order to be compatible with a plurality of different data storage techniques (e.g., providers 824). Thus, for example, stage 812 may interface with different database, including different storage techniques utilized by different merchants. Each of these functions may allow for engine package 808 to access back-end data stored within storage 812 and allow for such data to be processed (e.g., by API service 806 and/or API 804). Storage 812 may also allow for analytics to be performed on the stored data.
  • Each of these functions may allow for engine package 808 to access back-end data stored within storage 812 and allow for such data to be processed (e.g., by API service 806 and/or API 804).
  • Operational data 816 may be data directed to determining where resources are provided (e.g., displayed) with API 804. Thus, operational data 816 allows for adding, deleting, and/or editing of resources used in API 804. Operational data 816 may, thus, receive resources and convert the resources to an appropriate format for API 804 and/or API service 806 or vice versa.
  • Metadata 814 may include form configuration 826, table configuration 828, and data 830. Metadata 814 may govern the look and feel of forms, lists, and references (e.g., for a given resource). Resource engine 810 may govern the application of resources for API service 806 and/or API 804 (e.g., provide the resources requested by API service 806 and/or API 804).
  • Figure 9 illustrates an example of a simplified block diagram of a further computing system, in accordance with some implementations.
  • Figure 9 illustrates a system that includes model 918, storage 912, and resource package 910.
  • Storage 912 may be similar to storage 812 of Figure 8.
  • Model 918 allows for querying of resources from storage 912 as well as inserting, updating, and/or deleting of records from storage 912. Interactions between the various APIs described herein may be through model 918.
  • Resource package 910 includes form engine 914 and table engine 916.
  • Form engine 914 may be configured to add and edit resources while table engine 916 may be configured to control tables that display a set of resources.
  • Form engine 914 provides a set of tools that can be used to create and control progressive forms with metadata. These forms may be used to search, add a new resource, and edit the previous resource.
  • Form engine 914 may receive metadata and render forms for the data. Thus, form engine 914 will obtain attributes for fields that are required within a form. Form engine 914 will also control the appearance of the form. In certain implementations a merchant may customize the look of their storefront appearance. Form engine 914 may provide for that customized appearance, if any. Otherwise, form engine 914 may render the form with its default appearance. Form engine 914 may also provide handle relation fields on all form types. For example, for a user form, multiple addresses may be provided in the same form and submitted together. Form engine 914 may handle some or all stages of storing and retrieving data from the model 918 and storage 912.
  • form engine 914 may be configured to authenticate self- hosting merchants.
  • merchants may host their own storefronts. However, such storefronts may still need to confirm with certain requirements.
  • Form engine 914 may receive data from the storefronts, authenticate that the host is associated with the merchant, and/or determine that the storefront meets requirements.
  • form engine 914 may be configured to handle relational fields, support any customized components of a storefront, perform validation based on model validation rules for each input field (e.g., determine a type of input and validate the input to determine that it is acceptable and/or not indicative of fraud), support callbacks for each form event (e.g., submission, reset, error, and other such conditions that result in a callback), provide for progress bars and notifications, customize components for one or more fields, provide unsaved changes alerts, and communicate data between model 918 and storage 912.
  • model validation rules e.g., determine a type of input and validate the input to determine that it is acceptable and/or not indicative of fraud
  • support callbacks for each form event e.g., submission, reset, error, and other such conditions that result in a callback
  • provide for progress bars and notifications customize components for one or more fields, provide unsaved changes alerts, and communicate data between model 918 and storage 912.
  • Table engine 916 provides for a set of tools to create and control tables with metadata.
  • Table engine 916 includes features such as sort, filter and search, and pagination for resources.
  • table engine 916 may be configured to handle relational fields, support customized components, handle actions such as edit and delete, handle loadings with progress bars, customize components for some or all fields, communicate data with model 918 and storage 912, store, sort, search and/or paginate various states in a URL, search, with form engine 914, relation fields, and/or store searches.
  • Figure 10 illustrates one example of a computing device.
  • a system 1000 suitable for implementing embodiments described herein includes a processor 1001, a memory module 1003, a storage device 1005, an interface 1011, and a bus 1015 (e.g., a PCI bus or other interconnection fabric.)
  • System 1000 may operate as variety of devices such as a server system such as an application server and a database server, a client system such as a laptop, desktop, smartphone, tablet, wearable device, set top box, etc., or any other device or service described herein. Although a particular configuration is described, a variety of alternative configurations are possible.
  • the processor 1001 may perform operations such as those described herein.
  • Instructions for performing such operations may be embodied in the memory 1003, on one or more non-transitory computer readable media, or on some other storage device.
  • Various specially configured devices can also be used in place of or in addition to the processor 1001.
  • the interface 1011 may be configured to send and receive data packets over a network. Examples of supported interfaces include, but are not limited to: Ethernet, fast Ethernet, Gigabit Ethernet, frame relay, cable, digital subscriber line (DSL), token ring, Asynchronous Transfer Mode (ATM), High-Speed Serial Interface (HSSI), and Fiber Distributed Data interface (FDDi). These interfaces may include ports appropriate for communication with the appropriate media. They may also include an independent processor and/or volatile RAM.
  • a computer system or computing device may include or communicate with a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.
  • Figure 11 illustrates an example configuration of a neural network, configured in accordance with some implementations.
  • Figure 11 illustrates a neural network 1100 that includes input layer 1102, hidden layers 1104, and output layer 1106.
  • Neural network 1100 may be a machine learning network that may be trained to perform one or more techniques or be associated with one or more techniques, as described herein.
  • neural network 1100 may be a machine learning network used to, for example, determine one or more patterns of fraud, determine when a transfer should be authorized, and/or determine other aspects of transactions as described herein. While neural network 1100 is illustrated as an example of a machine learning system for use with the techniques described herein, other machining learning systems and techniques, in other embodiments, may also be used.
  • Neural network 1100 may be trained with data input.
  • Input layer 1102 may include such inputs.
  • Hidden layers 1104 may be one or more intermediate layers where logic is performed to determine aspects of items for training neural network 1100.
  • Output layer 1106 may result from computation performed within hidden layers 1104 and may, for example, output characteristics for when certain transactions should be approved.
  • any of the disclosed implementations may be embodied in various types of hardware, software, firmware, computer readable media, and combinations thereof.
  • some techniques disclosed herein may be implemented, at least in part, by non-transitory computer-readable media that include program instructions, state information, etc., for configuring a computing system to perform various services and operations described herein.
  • Examples of program instructions include both machine code, such as produced by a compiler, and higher-level code that may be executed via an interpreter. Instructions may be embodied in any suitable language such as, for example, Java, Python, C++, C, HTML, any other markup language, JavaScript, ActiveX, VBScript, or Perl.
  • non-transitory computer-readable media include, but are not limited to: magnetic media such as hard disks and magnetic tape; optical media such as flash memory, compact disk (CD) or digital versatile disk (DVD); magneto-optical media; and other hardware devices such as read-only memory (“ROM”) devices and random-access memory (“RAM”) devices.
  • ROM read-only memory
  • RAM random-access memory

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Certains modes de réalisation des systèmes, appareil, procédés et produits programmes informatiques d'après l'invention sont conçus pour mettre en œuvre une plate-forme de cartes de paiement à valeur stockée. D'autres modes de réalisation des systèmes, appareil, procédés et produits programmes informatiques d'après l'invention sont conçus pour mettre en œuvre une plate-forme configurée pour fournir une recommandation de cadeau automatisée. Une demande provenant d'un utilisateur d'une plate-forme de recommandation de cadeau destinée à recommander un cadeau pour une entité peut être traitée. Une première recommandation d'achat d'un premier cadeau pour l'entité peut être générée sur la base d'un ou plusieurs attributs de l'entité. La première recommandation peut être transmise à un dispositif associé au premier utilisateur. Des modes de réalisation supplémentaires des systèmes, appareil, procédés et produits programmes informatiques d'après l'invention sont conçus pour une distribution automatisée de fonds associés à un achat ou à une activation de cartes de paiement à valeur stockée.
PCT/US2020/044594 2019-07-31 2020-07-31 Plate-forme de cartes de paiement à valeur stockée WO2021022207A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962881285P 2019-07-31 2019-07-31
US201962881282P 2019-07-31 2019-07-31
US62/881,282 2019-07-31
US62/881,285 2019-07-31
US201962900067P 2019-09-13 2019-09-13
US62/900,067 2019-09-13

Publications (1)

Publication Number Publication Date
WO2021022207A1 true WO2021022207A1 (fr) 2021-02-04

Family

ID=74228656

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/044594 WO2021022207A1 (fr) 2019-07-31 2020-07-31 Plate-forme de cartes de paiement à valeur stockée

Country Status (1)

Country Link
WO (1) WO2021022207A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115102A1 (en) * 2000-02-02 2003-06-19 Ewald Mothwurf Method and an apparatus for promoting a product or brand
KR20090054336A (ko) * 2007-11-26 2009-05-29 주식회사 아이앤플레이 선불카드의 실시간 판매 시스템, 및 방법
US20120276868A1 (en) * 2011-04-28 2012-11-01 Boku, Inc Systems and methods to process donations
US20130297493A1 (en) * 2012-05-02 2013-11-07 Facebook, Inc. Method for enabling gift prepay
US20150348018A1 (en) * 2012-02-15 2015-12-03 Blackhawk Network, Inc. System and Method of Registering Stored-Value Cards into Electronic Wallets

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030115102A1 (en) * 2000-02-02 2003-06-19 Ewald Mothwurf Method and an apparatus for promoting a product or brand
KR20090054336A (ko) * 2007-11-26 2009-05-29 주식회사 아이앤플레이 선불카드의 실시간 판매 시스템, 및 방법
US20120276868A1 (en) * 2011-04-28 2012-11-01 Boku, Inc Systems and methods to process donations
US20150348018A1 (en) * 2012-02-15 2015-12-03 Blackhawk Network, Inc. System and Method of Registering Stored-Value Cards into Electronic Wallets
US20130297493A1 (en) * 2012-05-02 2013-11-07 Facebook, Inc. Method for enabling gift prepay

Similar Documents

Publication Publication Date Title
US11983736B2 (en) Interactive user interface based on analysis of chat messages content
US10579975B2 (en) Systems and methods for splitting a bill associated with a receipt
US20220215472A1 (en) Systems and methods for providing gift certificates of stock
US20200202314A1 (en) Systems and methods for effecting application programming interfaces for personal payment transactions
US20120296768A1 (en) Method and system for motivating consumers away from impulse spending
US10565633B2 (en) Determining gift suggestions for users of a social networking system using an auction model
US20130332307A1 (en) Method for notifying a sender of a gifting event
US12093998B2 (en) Systems and methods for providing a user interface for facilitating personal payment transactions
US20130211942A1 (en) Method for enabling a gift transaction
US20130218646A1 (en) Reward Modification
US10580059B2 (en) Webpage workflows with pooled transactions
US20130238410A1 (en) Registering User with Reward Incentive System
US20130218660A1 (en) Networked Incentive System
US20160335700A1 (en) Shopper-centric social networking system
US11361336B1 (en) System of utilizing an E-commerce/customer social media and networking platform for gifting and promotion of goods and services
US20120296731A1 (en) Creating an affinity relationship
US20180150809A1 (en) Systems and methods for effecting personal payment transactions
TWI653590B (zh) 透過他人共同贊助的送禮系統及其方法
KR101699041B1 (ko) 소셜 네트워크 서비스를 이용하여 지인 간의 인터랙션하는 방법 및 시스템
US20130218691A1 (en) Reward Posting Search
WO2021022207A1 (fr) Plate-forme de cartes de paiement à valeur stockée
US10614443B1 (en) Method and system of promoting a specific product or services by a person utilizing an e-commerce/social customer networking platform
KR20190080439A (ko) 사용자 사용성 측정 및 이의 반영을 통한 인맥 추천시스템 알고리즘 개선
MUJAFFAR Markting Strategy Paytm

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

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

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 22/08/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20847755

Country of ref document: EP

Kind code of ref document: A1