CROSS-REFERE NCE TO RELATED APPLICATIONS

This application claims priority to Provisional U.S. Patent Application No. 62/881,282 (Attorney Docket 1IGCP002P) by Lotfollahi, titled "STORED-VALUE PAYM ENT CARD HOSTING PROGRAM", filed July 31, 2019, Provisional U.S. Patent Application No. 62/881,285 (Attorney Docket IIGCP003P) by Lotfoilahi, titled "AUTOMATED RECOMMENDATION PLATFORM", filed July 31, 2019, and Provisional U.S. Patent Application No. 62/900,067 (Attorney Docket IIGCP005P) by Lotfoilahi, titled "AUTOMATED DISTRIBUTION OF FU NDS ASSOCIATED WITH PURCHASE OR ACTIVATION OF STORED-VALUE PAYMENT CARDS", filed September 13, 2019, all of which are hereby incorporated by reference in their entirety and for all purposes.

COPYRIG HT NOTICE

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the United States Patent and Trademark Office patent file or records but otherwise reserves all copyright rights whatsoever

FIELD OF TECHNOLOGY

This patent document relates generally to stored-vaiue payment cards. In particular, hosting merchants on a stored-vaiue payment card platform.

BACKG ROU ND

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

The included drawings are for illustrative purposes and serve only to provide examples of possible structures and operations for the disclosed inventive systems, apparatus, methods and computer program products for a stored-value payment card platform. These drawings in no way limit any changes in form and detail that may be made by one skilled in the art without departing from the spirit and scope of the disclosed implementations.

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.

DETAILED DESCRIPTION

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. As described in further detail below, such a platform may provide an environment to merchants who wish to offer stored-vaiue payment cards for their business. Such 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.

There are limited options for conventional stored-vaiue payment card programs that merchants may choose to implement. The conventional programs are typically costly and difficult to implement, especially for smaller retail stores. By way of illustration, Franklin Sisters Market is a small corner grocery store. Brit a co-owner of Franklin Sisters Market would like to start a stored-vaiue payment card program at her store. As Brit researches the opportunity, she finds that the cost to invest in the system for activating the gift cards would be cost-prohibitive. Brit decides not to start the stored-vaiue payment card program for her store causing her to miss out on many new sales opportunities.

In an alternative scenario, during Brit's research into the gift card stand idea, she may have come across a company implementing a stored-vaiue payment card platform utilizing some of the disclosed techniques. When Brit decides she would like to start carrying stored-vaiue payment cards, she can sign enroll in a program hosted by a stored-vaiue payment card platform such as OffGifter. The stored-vaiue payment card platform controls the major transactions related to the stored-vaiue payment program. For example, after Franklin Sisters Market is enrolled on the stored-vaiue payment card platform, a customer using their smart phone can purchase and redeem Franklin Sisters Market stored-vaiue payment cards through an app integrated with the stored- vaiue payment card platform. In other implementations of the disclosed systems, apparatus, methods and computer program products are configured for implementing a platform configured to provide automated gift recommendation. As described in further detail below, such 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. Additionally, one having skill in the art can appreciate that "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.

Effectively choosing gifts to give others may be difficult using traditional methods. By way of example, Belie may wish to purchase a Christmas gift for Charles, one of the associates she supervises at her law firm. Unfortunately, since she has only been working with Charles for several months, she knows little about his interests. She ends up buying him a box of candies from a local chocolatier. Unfortunately, Charles is diabetic and cannot eat the chocolates, creating an unnecessarily awkward situation when Belle presents him with a gift be cannot use.

By contrast, the disclosed techniques can revolutionize gifting by allowing for efficient, intelligent, and automated gift recommendation. Returning to the example of the preceding paragraph, 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. When 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.

In further implementations of the disclosed systems, 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.

Conventional gift card programs often follow a model where a gift card provider receives a fraction of the revenue when a customer purchases a gift card for a particular merchant. Unfortunately, by using conventional promotional services, such gift card providers and merchants often miss out on opportunities when. By way of example, 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. Formaggio Verona teams up with Montague Enterprises to create a gift card program where customers can purchase gift cards for Formaggio Verona. 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.

By contrast, 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. By way of illustration, returning to the above example, suppose Formaggio Verona instead teams up with Offgifter to institute a gift card program 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. By way of example, each time a customer purchases or activates a Formaggio Verona gift card, 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. As such, the pot rapidly grows. Each time 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. Since the pot often exceeds $7 million dollars, and the tickets are free with purchase or activation of gift cards, 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.

Figure 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).

In some implementations, 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. By way of example, 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. in another example, 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.

Also or alternatively, 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 By way of illustration, some of the merchants 112(a)-(n) may not have the resources to maintain their own stored-value payment card services. As such, the gift platform 104 may host stored-value payment card services on behalf of some of the merchants 112(a)- (n). As such, 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). Also or alternatively, 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. One having skill in the art can appreciate that "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.

In some implementations, as discussed in further detail below, 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. One having skill in the art can appreciate that "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.

Also or alternatively, 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). Such special offers may include, for example, coupons, gifts, discounts, and/or other such incentives. By way of example, 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). By way of example, discounts may be automatically provided to users on special occasions such as birthdays, anniversaries, holidays, etc.

One having skill in the art can appreciate that 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. By way of example, one or more of 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.

In some implementations, the gift platform 104 may be used for any combination of functions. By way of illustration, 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. 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.

Figure 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.)

In some implementations, 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. By way of example, 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. in another example, 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. Also or alternatively, 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. By way of illustration, some of the merchants 212{a)-nn) may not have the resources to maintain their own stored-value payment card services. As such, the stored-value payment card platform 204 may host stored-value payment card services on behalf of some of the merchants 212(a)-(n). As such, 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). Also or alternatively, the merchants 212(a)-(n) may offer the stored-value payment cards directly to their customers at the merchant's physical location. One having skill in the art can appreciate that "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.

In some implementations, as discussed in further detail below, 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. One having skill in the art can appreciate that "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.

Also or alternatively, 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). Such special offers may include, for example, coupons, gifts, discounts, and/or other such incentives. By way of example, 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). By way of example, discounts may be automatically provided to users on special occasions such as birthdays, anniversaries, holidays, etc.

One having skill in the art can appreciate that 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. By way of example, one or more of 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.

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.

At 304 of Figure 3, a request to create a merchant account is processed. By way of example, merchant 112(a) of Figure 1 may send a request to gift platform 104. In some implementations, 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.). Also or alternatively, 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. As an example, 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. In one example, 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. In another example, 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. in one more example, 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. In this case, 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. in some implementations, 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.

Upon receiving and authorizing the request of block 304 of Figure 3, the merchant is enrolled in the stored-value payment card hosting platform in 308. in some implementations, 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. In the example described above where a customer has requested that a merchant join the stored-value card hosting platform, the customer may also receive a notification that the merchant has joined the platform.

In various implementations, the stored-valued payment card hosting platform offers various advantages to merchants. For example, 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. However, the currently described techniques allow for lower cost hosting and transfer of payment cards. Furthermore, 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. Furthermore, in certain implementations, the financial accounting of payment cards may be shifted. Thus, as the payment cards are hosted on a separate system, the merchant may take advantage of the financial sales of payment cards while avoiding the accounting disadvantages. Additionally, in certain implementations, merchants may self -host their payment card storefronts while taking advantage of pre- built online structures, as described herein.

At block 312 of Figure 3, a request for stored value payment cards is received. In some implementations, 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. In some cases, physical gift cards purchased in a retail store are automatically activated using an image- based authorization techniques. In this example, 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.

In some implementations, 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

At block 316 of Figure 3, a request to redeem a stored value payment card is received. In some implementations, the request to redeem is for the entire value of the stored-value payment card. In other implementations, 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. In this case, 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.

At block 320 of Figure 3, the request is authorized and funds are provided to the merchant. Funds can be provided to the merchant at different rates or frequency. For example, stored-value payment card hosting platform can provide funds to the merchant for each transaction, hourly, daily, weekly, monthly, etc. In some implementations, funds are not transferred to the merchant until the customer redeems the stored-value payment card with the merchant. 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. Alternatively, 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.

While various implementations have been described herein, it should be understood that the examples of transactions handled by the stored-value payment card hosting platform have been presented by way of example only, and not limitation. The stored-value payment card hosting platform can be configured to handle all types of transactions including those know in the art, but not mentioned above.

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.

At 404 of Figure 4, a request for a gift recommendation is processed. By way of example, 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). By way of illustration, Belle may wish to buy Tim a Christmas gift; however she knows little about his interests. As such, 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.

Returning to Figure 4, at 408, a gift recommendation is generated. By way of example, 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.

As discussed above, in some implementations, a recommendation engine may use predictive analytics 508 based on an attribute of an entity to determine a gift recommendation for that entity. By way of illustration, 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. For instance, 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. For example, 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. By way of illustration, returning to the above example, 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.

As discussed above, in some implementations, 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. By way of example, 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

recommendations for Tim. By way of illustration, returning to the above- described example, 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.

Also or alternatively, wish lists may be seamlessly integrated with both a gift platform and social networking systems such as Facebook ^® . By way of Illustration, Tim's wish list may be provided to the social networking systems to which Tim belongs. As such, 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.

in some implementations, users of the social networking systems may band together to purchase gifts for Tim from his wish list. By way of example, 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. As such 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.

in some implementations, if there are insufficient contributions to pay for a gift, a user may be provided with a discount for completing the purchase him or herself. By way of example, if the contributions described above are insufficient to purchase the videogame system, Tim may be given a 10% discount if he contributes the remaining funds to purchase the videogame system himself.

As discussed above, in some implementations, gift recommendations may be generated based at least in part on locations 512 of Figure 5. By way of example, 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. As discussed above, the particular merchant may be using the gift platform 104 as a stored- value payment card hosting platform.

In some Implementations, the recommendation engine 504 may only generate a particular specific recommendation 524 of purchasing a gift for an entity in certain circumstances. By way of example, 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. By way of example, 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.

Alternatively, if the recommendation engine 504 is unable to determine any specific gifts that Tim would likely want, 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.

Returning to Figure 4, at 412, the gift recommendation is transmitted. By way of example, the recommendation engine 504 may transmit a

recommendation to Belle's smartphone that Belle purchase Tim a particular pair of pants from The Ghost's Closet.

In some implementations, at 416 of Figure 4, the recommendation engine may be trained based on an entity's interaction with a gift. By way of example, as discussed above, 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. By way of illustration, consumer data associated with purchases made using the stored- value payment card described above may be retrieved. For example, 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. As such, 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. By way of example, 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.

In some implementations, the disclosed techniques may be used to send automated thank you notes. By way of example, 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. When 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. Also or alternatively, 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.

At 604 of Figure 6, a request to purchase or activate a stored-value payment card is processed. By way of example, Juliet may use her iPhone ^® to purchase a $50 gift card to Formaggio Verona for her fiance Paris. As discussed above, Juliet may purchase the gift card via the stored-value payment card platform 204 of Figure 2, which is operated by Offgifter.

In some implementations, a portion (e.g., a percentage such as .01%, .5%, 1%, 3%, etc.) of the proceeds from a purchase or activation of a stored-value payment card may be delivered to a stored-value payment card provider. By way of illustration, 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. In some implementations, at 608 of Figure 6, a user is presented with an option via a user interface. For instance, in some implementations, 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. Also or alternatively, the charity may be selectable by the user. By way of illustration, 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.

At 612 of Figure 6, funds associated with the purchase or activation of the stored-value payment card are automatically transferred to a pot. By way of illustration, as discussed above, 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. For instance, 10 % of Offgifter' s proceeds from each purchase or activation of a gift card may be automatically transferred into the pot. As such, $0.05 from Juliet's purchase of the $50 gift card to Formaggio Verona may be automatically transferred into the pot.

At 616 of Figure 6, a ticket is provided to a user via a device. For example,

In some implementations, every time a user purchases or activates a gift card via the stored-value payment card platform 204 of Figure 2, he or she may be given a lottery ticket free of charge. The ticket may be associated with any type of code capable of being of being drawn in a lottery. For example, 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." In some implementations, the code may be an alpha- numeric entity selected by the user. Also or alternatively, the code may be a random alpha-numeric generated by the stored-va!ue payment card platform 204 of Figure 2. One having skill in the art can appreciate that a ticket, as discussed herein, may be any physical or electronic entity capable of being associated with a code.

As discussed above, 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. By way of example, Juliet's ticket is associated with the code "03 14 17 31 51 59." At the time of the drawing, the stored-value payment card platform 104 may draw the code "03 14 17 31 51 59" as the winning code. At the time of the drawing, 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.

Also or alternatively, users may receive prizes for having a ticket associated with a partially winning code. By way of illustration, if the winning code is a set of six two digit numbers, and 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%.)

In some implementations, at 620 of Figure 6, funds may be provided to an entity. By way of example, as an incentive to use stored-value payment card platform 204 of Figure 2, 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). By way of illustration, returning to the above example, Offgifter may provide 1% of the $0.50 that Offgifter received from Juliet's purchase of the $50 gift card back to Formaggio Verona.

Also or alternatively, 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. For example, in some states, 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. By way of example, proceeds for any purchase (e.g., purchase of any goods or services) can be placed in a pot, and 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). Due to the variation of panels and jurisdictions, 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. When used in development of the front-end applications, 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.

Thus, for example, 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. In certain implementations, the systems of Figures 7-9 utilize object-relational mapping (ORM) to process data between the various APIs, databases, and other components. Furthermore, 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.).

In various implementations described herein, 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. in certain implementations, 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. In certain implementations, 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. In certain implementations, 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. In certain implementations, API service 806 allows for all API interactions with data to be performed through engine package 808. Furthermore, engine package 808 manages the relationship between data stored in various portions of engine package 808.

In a certain example, 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. Thus, for example, 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.

In certain implementations, 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. Thus, 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.

In various implementations, 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.

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.

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.

Additionally, form engine 914 may be configured to authenticate self- hosting merchants. Thus, in certain examples, 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.

Thus, in certain implementations, 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.

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. In various implementations, 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. According to various embodiments, 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. In other embodiments, 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. For example, 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. Examples of 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. A non- transitory computer-readable medium may be any combination of such storage devices.

In the foregoing specification, various techniques and mechanisms may have been described in singular form for clarity. However, it should be noted that some embodiments include multiple iterations of a technique or multiple instantiations of a mechanism unless otherwise noted. For example, a system uses a processor in a variety of contexts but can use multiple processors while remaining within the scope of the present disclosure unless otherwise noted. Similarly, various techniques and mechanisms may have been described as including a connection between two entities. However a connection does not necessarily mean a direct, unimpeded connection, as a variety of other entities (e.g., bridges, controllers, gateways, etc.) may reside between the two entities.

In the foregoing specification, reference was made in detail to specific embodiments including one or more of the best modes contemplated by the inventors. While various implementations have been described herein, it should be understood that they have been presented by way of example only, and not limitation. For example, some techniques and mechanisms are described herein in the context of gifts. However, the disclosed techniques apply to a wide variety of circumstances. Particular implementations may be implemented without some or all of the specific details described herein. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the techniques disclosed herein. Accordingly, the breadth and scope of the present application should not be limited by any of the implementations described herein, but should be defined only in accordance with the claims and their equivalents.