WO2021022204A1

WO2021022204A1 - Image-based authorization and transmission of stored value or sim cards

Info

Publication number: WO2021022204A1
Application number: PCT/US2020/044591
Authority: WO
Inventors: Hamid LOTFOLLAHI
Original assignee: Iigc, Inc.
Priority date: 2019-07-31
Filing date: 2020-07-31
Publication date: 2021-02-04

Abstract

Some implementations of the disclosed systems, apparatus, methods and computer program products are configured for implementing image-based authorization of stored-value payment and/or sim cards.

Description

IMAGE-BASED AUTHORIZATION AND TRANSMISSION OF STORED VALUE OR SIM

CARDS

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to Provisional U.S. Patent Application No. 62/881,281 (Attorney Docket IIGCPOOIP) by lotfollahi, titled "IMAGE-BASED AUTHORIZATION OF STORED-VALUE PAYMENT CARDS", filed July 31, 2019, Provisional U.S. Patent Application No. 62/886,372 (Attorney Docket IIGCP004P) by Lotfollahi, titled "TRANSMISSION OF STORED-VALUE PAYMENT CARDS BETWEEN DEVICES", filed August 14, 2019, and Provisional U.S. Patent Application No. 62/928,588 (Attorney Docket IIGCP006P) by Lotfollahi, titled "IMAGE-BASED AUTHORIZATION OF SIM CARDS", filed October 31, 2019, all of which are hereby incorporated by reference in their entirety and for all purposes.

COPYRIGHT 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-value payment cards and SIM cards. In particular, image-based authorization and/or transmission techniques (e.g., using near field communication) of stored-value payment cards and SIM cards may be provided.

BACKGROUND

E-commerce techniques allow users to purchase goods and services via the internet with simply clicking or tapping a button in a user interface. Online social networking systems have connected people across the globe facilitating creation of friendships over the internet. People may wish to transfer and/or purchase gifts to maintain friendships and strengthen bonds. Additionally, larger numbers of mobile device users are traveling. During travel to different regions, the users of the mobile devices may be required to obtain new SIM cards. Users may wish to pre-order SIM cards and activate them at their convenience.

BRIEF DESCRIPTION OF THE DRAWINGS

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 transmission and/or image-based authorization of stored-value payment cards and/or SIM cards (e.g., using near-field communication). 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 a computing environment in which a SIM platform is operating, in accordance with some implementations.

Figure 3 illustrates an example of a simplified block diagram of computing environment in which a gift platform is operating, in accordance with some implementations.

Figure 4 illustrates an example of a method for image-based authorization of stored-value payment cards, in accordance with some implementations.

Figure 5 illustrates an example of a method for transmission of stored- value payment cards using near-field communication, in accordance with some implementations.

Figure 6 illustrates an example of a method for image-based authorization of stored-value payment cards, in accordance with some implementations.

Figure 7 illustrates an example of a method for activation of SIM cards, in accordance with some implementations.

Figure 8 illustrates an example of a simplified block diagram of a computing system, in accordance with some implementations.

Figure 9 illustrates an example of a simplified block diagram of another computing system, in accordance with some implementations. Figure 10 illustrates an example of a simplified block diagram of a further computing system, in accordance with some implementations.

Figure 11 illustrates one example of a computing device, configured in accordance with some implementations.

Figure 12 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 image-based authorization and/or transmission of stored-value payment cards and/or SIM cards.

As described in further detail below, such a platform may be provided in an environment where merchants offer stored-value payment cards and/or SIM cards for their business that need to be activated. 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. As described in further detail below, these authorization techniques can be applied using images captured from a camera of a mobile device, from a camera connected to another device (e.g., a vending machine or kiosk), from a smart watch, from a stand-alone digital camera, etc. While mobile devices are used in the example below, one having skill in the art can appreciate that the examples of applications or services described herein may be substituted for any suitable application or device such as those described above.

Conventional transfer and/or authorization of gift cards requires a customer to purchase and activate a gift card according to a standard in-person retail transaction. The infrastructure required by the retail store to activate the gift card can be expensive. Smaller retail stores typically cannot afford to invest in this infrastructure, leaving customers with limited choices on where to purchase and activate their gift cards. Moreover, a customer must transfer the gift card by physically handing the gift card to the recipient or transferring a digital copy via the internet (e.g., emailing a digital gift card to the recipient).

By way of illustration, Franklin Sisters Market is a small family owned corner grocery store that caters to residents located nearby the store. The Franklin Sisters Market is a modest family-owned business that is looking for a new way to attract repeat customers and expand their sales. Brit a co-owner of Franklin Sisters Market, mindful of the limited space in the store, has the idea to add a gift card stand to draw customers into the 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. Consequently, Brit decides not to move forward with the gift card stand idea. Brit's decision not to add a gift card stand causes her to miss out on many new sales opportunities. As one example, Phil, a neighbor and past customer of Franklin Sisters Market, is in desperate need of a last-minute gift for his friend Juan's raw vegetable potluck-style birthday party. Phil is under the impression that only large grocery stores have gift cards. Realizing that he would be late if he had to drive the 20 minutes to the large grocery store, Phil decides not to get a gift for Juan or bring any vegetables. As a consequence, the relationship between Phil and Juan is strained and Franklin Sisters Market loses out on the sale from Phil. However, some of disclosed techniques described in further detail below can be implemented in order to avoid this unfortunate scenario for all parties involved.

Brit further researches the gift card stand idea. During Brit's research into the gift card stand idea, she may have come across a company implementing a stored-value payment activation platform utilizing some of the disclosed image- based authorization techniques. As a result, Phil may have seen the stand during a previous visit and remembered that Franklin Sisters Market had gift cards. Instead of needing to drive the 20 minutes to the large grocery store, Phil could have walked next door to his house and activated a gift card from Franklin Sisters Market using his smart phone. As such, he would have been able to purchase a gift as well as the vegetables he wanted to bring to the pot luck.

As an additional example, Mel is in desperate need of a last-minute gift for his friend Frank. Mel has not purchased a gift for Frank and he is already late to a birthday party that their friend Juan is hosting. Mel decides not to get a gift for Frank and try to get to the party sooner. As a consequence, Frank's feelings are hurt and the relationship between Mel and Frank is strained. However, some of disclosed techniques described in further detail herein can be implemented in order to avoid this unfortunate scenario.

When Mel realizes he doesn't have a gift for Frank. He can log into a stored-value payment card platform such as OffGifter. He can purchase a $40 gift card to Frank's favorite retail store and store a digital reference of the gift card on his smart phone. Upon arrival to the party, Mel can tell Frank he has a gift for him. In order to transfer the gift card from Mel's phone to Frank's phone, Mel can place his phone near Frank's phone and begin the process of transferring the gift card between phones using near-field communication. As such, he would have been able to bring a gift to Frank's part and avoid hurting their friendship.

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 300 of Figure 3.)

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 payment card activation platform 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 platform 116 and use these stored-value payment cards by purchasing goods and serviced directly from the merchants 112(a)-(n). Also or alternatively, the merchants 112(a)-(n) may also activate and purchase stored- payment cards via platform 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 (email or 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 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 a computing environment 200 in which a SIM platform 204 is operating, in accordance with some implementations. In various implementations, the SIM platform 204 may be implemented using a variety of computing devices, server systems, database systems, and other systems, similar to the example of Figure 1.

Customers 208(a)-(n) of Figure 2 may use computing devices to interact with the SIM platform 204 for a variety of reasons such as activation of SIM cards, adding value to SIM cards, and for authentication purposes. Telecoms 212(a)-(n) are, in certain implementations, telecommunications vendors that offer mobile phone services to customers with mobile phones. The SIM card of each of customers 208(a)-(n) may be associated with one or more of telecoms 212(a)-(n).

SIM platform 204 may be associated with a specific geographical location. For example, SIM platform 204 may be associated with a specific country or regulatory body (e.g., state or multi-national region such as the European Union) as each country or regulatory body may include different regulations on use and activation of SIM cards. SIM platform 204 may offer a variety of functions. For example, SIM card hosting platform 220 may provide telecommunications and SIM card services for companies that do not provide their own telecommunications services in the country or regulatory body. Thus, SIM card hosting platform 220 may, for example, allow users to order SIM cards associated with telecoms 212(a)-(n) (e.g., from an online store, a storefront, or a vending machine) and receive such SIM cards. SIM card activation platform 216 may then activate those SIM cards independent of the user visiting a storefront. As such, in certain implementations, a user may order SIM cards for regions that the user is traveling to before travel and receive the SIM cards before travel and/or have a SIM card reserved for pick up after landing. The user may then self activate the SIM card instead of activating the SIM card through visiting a typical storefront.

SIM card activation platform 216 may allow for activation and purchase of SIM cards by customers 208(a)-(n). SIM cards, in certain implementations, may include an integrated circuit configured to securely store a mobile subscriber identity number associated with the SIM card and its related key. SIM cards allow for identification and authentication of subscribers on mobile devices (e.g., mobile phones or tablets).

Also or alternatively, SIM 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 SIM card data (e.g., data for particular SIM cards such as remaining balance information).

In certain implementations, customers 208(a)-(n) may utilize mobile devices such as smart phones and tablets to provide the necessary information to activate SIM cards for use with telecoms 212(a)-(n). For example, customers 208(a)-(n) may establish a data connection with SIM platform 204 through WiFi, local area network, wired network, another SIM card, or another such connection. Customers 208(a)-(n) may then log into a portal (e.g., a website or an application utilizing specific APIs) and provide the needed identification data to activate the desired SIM card. In certain implementations, activation of the SIM card may be performed automatically once the SIM card has been inserted into the mobile device. Such identification data may include, depending on the region, identification information such as a photograph of a passport, a driver's license, credit card information, a photograph or information of a visa, a photograph of the SIM card user, a photograph of an identification code of the SIM card, and/or other such information. In various implementations, the portal may detect the user's location (e.g., through a global positioning device of the mobile device or metadata from the data connection that connects the mobile device to SIM platform 204). As activation requirements for SIM cards differ from region to region, based on the detected region, the portal may prompt the user for the information required to activate the SIM card in the specific region. Furthermore, the portal may be configured to activate different systems of the mobile device based on the information required. Thus, for example, the portal may activate the front facing camera of the mobile device to obtain photographs of a passport and activate the rear facing camera of the mobile device to obtain photographs of the user. In certain implementations, the identification data required to activate the SIM card versus changing the balance of the SIM card is different and, thus, the portal may request different information depending on the service desired by the user. The user may, thus, indicate the service desired via the portal. The identification data collected by the mobile device may be transmitted to SIM platform 204.

Also or alternatively, in some implementations, the SIM card to be activated includes a code (e.g., bar code or QR code) affixed to the SIM card (e.g., the front or back side of the SIM card). In such implementations, the mobile device may scan or obtain a photograph of the code and provide it to SIM platform 204. SIM platform 204 may then identify the SIM card (e.g., the device number of the SIM card) to be activated from the code. Further, SIM platform 204 may identify already activated SIM cards through the code and allow for changes in the balance of the account associated with the SIM card.

Figure 3 illustrates an example of a simplified block diagram of computing environment 300 in which a gift platform 304 is operating, in accordance with some implementations. The gift platform 304 may be implemented using a variety of computing devices, server systems, database systems, etc. (e.g., systems 800 of Figure 8.)

In some implementations, customers 308(a)-(n) of Figure 3 may use computing devices to interact with the gift platform 304 for a variety of functions such as stored-value payment card activation platform 316. By way of example, the customers 308(a)-(n) may use their computing devices to purchase stored-value payment cards (e.g., gift cards) or other gifts from the gift platform 304. In another example, the customers 308(a)-(n) may use their computing devices to automatically activate stored-value payment cards via the gift platform 304 without a need for a human intermediary.

Also or alternatively, merchants 312(a)-(n) of Figure 3 may use computing devices to interact with the gift platform 304 for a variety of functions such as stored-value payment card hosting platform 320. By way of illustration, some of the merchants 312(a)-(n) may not have the resources to maintain their own stored-value payment card services. As such, the gift platform 304 may host stored-value payment card services on behalf of some of the merchants 312(a)- (n). As such, the customers 308(a)-(n) may activate and purchase store payment cards via platform 316 and use these stored-value payment cards by purchasing goods and services directly from the merchants 312(a)-(n). Also or alternatively, the merchants 312(a)-(n) may also activate and purchase stored-payment cards via platform 316 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 (email or SMS) or physically through a mail service.

In some implementations, as discussed in further detail below, customers 308(a)-(n) merchants 312(a)-(n) may use gift platform 304 to purchase and redeem stored-value payment cards. Gift platform 304 includes a gift recommendation engine 324 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 304 through Offers Engine 328 may be used to provide and maintain special offers for both the customers 308(a)- (n) and the merchants 312(a)-(n). Such special offers may include, for example, coupons, gifts, discounts, and/or other such incentives. By way of example, the gift platform 304 may generate and maintain a special offer infrastructure (e.g., coupons, discounts, promotion codes, etc.) for the merchants 312(a)-(n). The gift platform 304 may also provide such special offers directly to the customers 308(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 304 may be provided to the customers 308(a)-(n) and the merchants 312(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 304 may maintain or access a variety of databases 332(a)-(n) to perform the above described functions or any additional functions. By way of example, one or more of databases 332(a)-(n) may include stored-value payment card data (e.g., data for particular gift cards such as balance information) for a merchant 312(a)-(n) for whom the gift platform 304 is hosting a stored-value payment card program, user account information associated with a merchant 312(a)-(n), user account information associated with customers 308(a)-(n), etc.

In some implementations, customers 308(a) and 308(b) can have mobile devices equipped with near field communication (NFC) technologies or other short-range wireless technologies such as Bluetooth. The NFC equipped devices can allow two or more devices to communicate wirelessly when they are in close proximity together. The communication can be facilitated through identification of data (tags, tokens, or other categories of data) through radio waves. In some implementations, the data involved in an NFC transaction may be encrypted and/or dynamic. For example, when a stored-value payment card transfer begins, the details of the stored-value payment card may be replaced with a series of randomly generated numbers and/or characters that are decryptable by the receiving device. Thus, in certain implementations, the mobile devices of customers 308(a) and 308(b) may communicate data as described herein through various phone to phone transfer techniques. Though the example described herein provides for a NFC transaction, other techniques are also contemplated, such as transfer through Bluetooth·, WiFi, picture scanning, or other such techniques. In certain additional implementations, transfer may be conducted through one mobile device causing an associated printer to print out a paper slip with a code and having the second mobile device obtain a picture of the code.

In some cases, the data corresponding to the original details of the transfer may be sent to gift platform 304, which may generate random number(s) corresponding to the data. Accordingly, such random number(s) can be sent between NFC equipped devices without fear that information will be compromised while preserving the details of the transaction.

Figure 4, described in the context of Figures 1-3, illustrates an example of a method for image-based authorization of stored-value payment cards, in accordance with some implementations.

At 404 of Figure 4, a request for access to a stored-value payment card activation is received. 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. In other implementations the request is routed to stored-value hosting platform 120 to be processed. And in other implementations, the request is routed to stored-value card activation platform 116. Also or alternatively, any combination of platforms 104, 116, and 120 can be used to process the request. The request may be from a new merchant to platform 120 that would like to add a stored-value payment card program for their business. Also or alternatively, the merchant may have been previously enrolled in the stored-value card hosting platform 120. If it is the case that it is the first time that a merchant is activating a stored-value payment card, then the merchant may be prompted to create an account using basic information about the merchant (name of principal, address, baking information, etc.).

The request to access the stored-value payment card activation platform may be sent in different ways. In one example, merchant 112(a) navigates to a website controlled by gift platform 104, merchant 112(a) is prompted to enter stored-value payment card information manually on a webpage set up for card activation. Also, in another example, customer 108(a) uses an app controlled by gift platform 104 on their smart device and provides the necessary information to gift platform 104 via the app. In another example, it is customer 108(a) that navigates to a website controlled by gift platform 104 and enters stored-value payment card information manually on a webpage set up for card activation. In one more example, customer 108(a) would like to order and activate 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 some implementations, a request is sent by gift platform 104 that includes information about the customer and a dollar amount that the customer would like to add to stored-value payment card. In addition, the request to access the stored-value payment card activation platform can also include login credentials. For example, a username and password. The login credentials can also further include financial information associated with the customer, a phone number, location of the customer, etc.

At block 408 of Figure 4, an image of the stored-value payment cards is received. The image can contain an identifier representing the stored-value payment and associated information stored in a database of gift platform 104 of Figure 1. An identifier might be a machine-readable barcode, a series of characters (numbers and/or letters), a QR code, or other means of identification. In some implementations, the identifier in the image is identified using feature recognition techniques. One example is matrix matching (also known as "pattern matching", "pattern recognition", or "image correlation") techniques that compare an image to a stored base character on a pixel-by- pixel basis. The character analyzed can be isolated from the rest of the image and in a similar font and at the same scale to the stored set of base characters.

Another example is feature extraction that identifies features of a character such as lines, closed loops, line direction, and line intersections. The extraction features can reduce the dimensionality of the representation and allow the recognition process to be computationally efficient. These features can be compared with an abstract vector-like representation of a character, which might reduce to one or more base set characters.

In some implementations, the image of block 408 of Figure 4 is provided by customer 108(a) of Figure 1 via an app on a smart device. 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. For example, the image may be captured on a camera of a mobile device and provided using mobile data (or a wireless internet connection) to platform 116. In addition, more than one image can be captured by customer 108(a) and sent to platform 116. For example, additional images of the stored-value payment card. These additional images might be used to provide a more accurate representation of the identifier (e.g., barcode) or of additional information necessary to activate the stored-value payment card (e.g., a merchant ID number, or an additional verification code). Other types of images can be provided to platform 116, for instance, an image of the user for security purposes, as discussed further below.

In some implementations, the identifier in the image of the stored-value payment cards is identified based on one or more machine learning techniques that refine and improve the accuracy of the identification process. One technique that may be used is simply adding a weight to images that are known to contain correctly identified identifiers. Using that information, visually similar images that are sent to platform 116 can be compared to the weighted correctly identified identifiers and depending on the similarity between the two images can be give a confidence score that is used indicate how confident platform 116 is that the correct characters have been identified.

In some implementations, additional data is provided as part of block 408 of Figure 4. Data representing the position of the user can be captured using a global positioning system sensor of the mobile device and sent to platform 116 of Figure 1. For example, Phil's location inside Franklin Sisters Market can be sent as part of the activation process. Additionally, the location information can be used for security purposes by the activation platform by matching Phil's location with the location the gift platform has in its database about Franklin Sisters Market address.

At block 412 of Figure 4, a request to activate the stored-value payment card is received. In some implementations, the request of block 412 is with the request of block 408. In other implementations, the request of block 412 is sent as a separate from the request of 408. To illustrate, a user may navigate to a first presentation a user interface on an app of a smart phone (e.g., a user interface configured to receive a real-time image). After capturing and sending the image to platform 116 of Figure 1, the app refreshes the app to display a second presentation that shows a form to input information about the customer and financial information. An example involving these implementations is the scenario where a stored-value payment card is activated in person at a store such as the scenario described above where Franklin Sisters Market would like to stock physical gift cards at their retail location. The customer in such implementations may, thus, self-activate gift cards or other stored-value cards.

In certain other implementations, customers may wish to pay for their stored-value payment cards with cash. In such an example, self-activation of the card by the customer, as described herein, may not be appropriate as receipt of cash payment (e.g., by the merchant) may need to be confirmed before the stored-value payment card is activated. Thus, in such implementations, after the image of the stored-value payment card is received, the customer may then indicate that cash payment will be provided for the stored-value payment card (e.g., through providing such an indication on an app of the customer device). The customer may then provide cash payment to the merchant (e.g., at a check out register). In certain implementations, the app may provide an indication to the customer to provide cash payment to the merchant. After cash payment has been provided, the merchant may then provide an indication to stored-value card activation platform 116 or another portion of gift platform 104 that payment has been received (e.g., through a merchant device such as a check out device, a point of sale device, or another such device). In various examples, such indication may be from, for example, scanning a code displayed on the customer device, scanning a code displayed on the gift card, receiving electronic communications (e.g., through NFC or another medium) from the customer device and/or the gift card, inputting a code associated with the gift card, and/or another such technique that identifies that the gift card has been paid for. The merchant device may then provide the indication through an activation request or a confirmation to platform 104/116 that payment has been received.

At block 416 of Figure 4, a determination is made on whether the activation request is authorized. In some implementations, the request may be authorized if an identifier is successfully identified and the financial information provided by the customer is reliable and adequate for transferring the funds from the customer's financial institution to the activation platform 116 of Figure 1. In other information, additional security measures are employed to prevent fraud. For example, the customer's information may be sent to a third- party vendor for a credit check, fraud history check, etc. As part of the additional security measures, a user may take a picture of their face, credit card, driver's license, etc. to determine that the user is associated with the payment information and that the activation should be authorized. Also or alternatively, the determination can be delayed until the point when a customer attempts to use the stored-value payment card, allowing for more time to complete additional security measure concerning the customer attempting to activate the stored-value payment card.

At block 420 of Figure 4, an indication that the activation has been authorized is transmitted. When the request is authorized, funds are provided from the customer's financial institution to the provider of gift platform 104. Funds can be provided to the gift platform 104 immediately or at certain time such as at the end of business day, 24 hours from the authorization, etc. In some implementations, gift platform 104 may send a notification to merchant 112(a) indicating that the activation has been successfully authorized. In other implementations, gift platform 104 may send a notification to customer 108(a) as well. The notification may be in the form of a push notification, text message, email, phone call, or some other form of audio-visual prompt indicating successful authorization.

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

Figure 5, described in the context of Figures 1-3, illustrates an example of a method for transmission of stored-value payment cards using near-field communication, in accordance with some implementations.

At 504 of Figure 5, a request to transfer a stored-value payment card is received. The manner in which the transfer request is triggered can occur in a variety of ways and in response to a variety of data inputs. For example, QR codes, bar codes, radio frequency identification, iris recognition, facial recognition, magnetic stripes, optical character recognition, voice recognition, etc. are all examples of data inputs that can be used to trigger a transfer request. In some implementations, a transfer request might require a user to login to gift platform 304 of Figure 3, which can include entry of login credentials such as a username and password. The login credentials can also further include other identifying information such as financial information associated with the customer, a phone number, location of the customer, etc.

The manner in which a transfer request is triggered may vary across implementations. For example, in some implementations, the transfer request may be sent when a user scans a three-dimensional barcode associated with a stored-value payment card. In other implementations, the transfer request is sent when a user brings their device in close proximity (e.g., less than 20cm) to another device. In this case, the devices may be equipped with NFC technology Bluetooth·, WiFi, or other techniques that allow for short range transmission of data. Also or alternatively, a transfer request may be sent when a user uses the camera on his or her smart phone to take a picture of a barcode displayed on the display of another smart phone. In one example, the customer 308(a) may use an app controlled by gift platform 304 on her smart device, providing the necessary information to gift platform 304 via the app. Gift platform 304 may receive the transfer request and begin the process of transferring the stored- value payment card to customer 308(b). In another example, the customer 308(a) may launch a browser on her smartphone, navigating to a website controlled by gift platform 304, and entering stored-value payment card information manually via the website to start the transfer. In certain a certain additional example, the transfer may be conducted through one mobile device causing an associated printer to print out a paper slip with a code and having the second mobile device obtain a picture of the code. The code may then be transmitted to gift platform 304.

At 508 of Figure 5, it is determined that the transfer request is authorized. The determination may be made by logic stored on the device of the customer 308(a). Alternatively, the transfer request may be sent to gift platform 304 of Figure 3, which may make the determination at 508 of Figure 5. In some implementations, a customer may initiate the stored-value payment card transfer process by opening an app and taking a picture of the barcode or other identifying characters on a physical card with their smart device. For example, the image may be captured on a camera of a mobile device such as the smart phone of customer 308(a). More than one image can be captured by customer 308(a) and sent to platform 304.

Other types of images can be provided to platform 304, for instance, an image of a user for fraud prevention purposes. In some cases, a user may take a picture of his or her face, credit card, driver's license, etc. to facilitate the veracity of the transaction. Additional information can be provided as part of 508 of Figure 5. For example, a user's pin code, or swipe lock combination, data representing the position of the user can be captured, data representing an identifier can be identified, etc.

At 512 of Figure 5, the stored-value payment card is transferred from one device to another device. This transmission, as well as the other communications described above, can be facilitated using NFC technology. As mentioned above, the data involved in an NFC transaction can be encrypted. The details of the stored-value payment card can be replaced with a series of randomly generated numbers and/or characters. That random number can be sent between devices without fear that information will be compromised.

In some implementations, an indication that the transfer has successfully occurred is transmitted. When the request is authorized, the data representing the stored-value payment card may be transferred from one device to another (e.g., devices of customer 108(a) and 108(b)), and the data representing the stored-value payment card may be removed from the first device. Upon completion of both acts by the two devices, a visual notification may appear on one or both of the devices. In some implementations, the gift platform 104 of Figure 1 may send a notification to customers 108(a) and 108(b) as well. The notification may be in the form of a push notification, text message, email, phone call, or some other form of audio-visual prompt indicating successful authorization.

Figure 6, described in the context of Figures 1-3, illustrates an example of a method for image-based authorization of stored-value payment cards, in accordance with some implementations.

At 604 of Figure 6, a request for access to a stored-value payment card activation is received. 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. In other implementations the request is routed to stored-value hosting platform 120 to be processed. And in other implementations, the request is routed to stored-value card activation platform 116. Also or alternatively, any combination of platforms 104, 116, and 120 can be used to process the request. The request may be from a new merchant to platform 120 that would like to add a stored-value payment card program for their business. Also or alternatively, the merchant may have been previously enrolled in the stored-value card hosting platform 120. If it is the case that it is the first time that a merchant is activating a stored-value payment card, then the merchant may be prompted to create an account using basic information about the merchant (name of principal, address, baking information, etc.).

The request to access the stored-value payment card activation platform may be sent in different ways. In one example, after merchant 112(a) navigates to a website controlled by gift platform 104, merchant 112(a) is prompted to enter stored-value payment card information manually on a webpage set up for card activation. Also, it could be customer 108(a) using an app controlled by gift platform 104 on their smart device and providing the necessary information to gift platform 104 via the app. In another example, it is customer 108(a) that navigates to a website controlled by gift platform 104 and enters stored-value payment card information manually on a webpage set up for card activation. In one more example, customer 108(a) would like to order and activate 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.

At block 608 of Figure 6, an image of the stored-value payment cards is received. The image can contain an identifier representing the stored-value payment and associated information stored in a database of gift platform 104 of Figure 1. An identifier might include one or more of a machine-readable barcode, a series of characters (numbers and/or letters), a QR code, or other means of identification. In some implementations, the identifier in the image is identified using feature recognition techniques. One example is matrix matching (also known as "pattern matching", "pattern recognition", or "image correlation") techniques that compare an image to a stored base character on a pixel-by-pixel basis. The character analyzed can be isolated from the rest of the image and in a similar font and at the same scale to the stored set of base characters. Another example is feature extraction that identifies features of a character such as lines, closed loops, line direction, and line intersections. The extraction features can reduce the dimensionality of the representation and allow the recognition process to be computationally efficient. These features can be compared with an abstract vector-like representation of a character, which might reduce to one or more base set characters.

In some implementations, the image of block 608 of Figure 6 is provided by customer 108(a) of Figure 1 via an app on a smart device. 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. For example, the image may be captured on a camera of a mobile device and provided using mobile data (or a wireless internet connection) to platform 116. In addition, more than one image can be captured by customer 108(a) and sent to platform 116. For example, additional images of the stored-value payment card. These additional images might be used to provide a more accurate representation of the identifier (e.g., barcode) or of additional information necessary to activate the stored-value payment card (e.g., a merchant id number, or an additional verification code). Other types of images can be provided to platform 116, for instance, an image of the user for security purposes, as discussed further below.

In some implementations, additional data is provided as part of block 608 of Figure 6. Data representing the position of the user can be captured using a global positioning system sensor of the mobile device and sent to platform 116 of Figure 1. For example, Phil's location inside Franklin Sisters Market can be sent as part of the activation process. Additionally, the location information can be used for security purposes by the activation platform by matching Phil's location with the location the gift platform has in its database about Franklin Sisters Market address.

At block 612 of Figure 6, a request to activate the stored-value payment card is received. In some implementations, the request of block 612 is provided along with the data of block 608. In other implementations, the request of block 612 is sent separately from the data of 608. To illustrate, a user may navigate to a first presentation a user interface on an app of a smart phone (e.g., a user interface configured to receive a real-time image). After capturing and sending the image to platform 116 of Figure 1, the app refreshes the app to display a second presentation that shows a form to input information about the customer and financial information. An example involving these implementations is the scenario where a stored-value payment card is activated in person at a store such as the scenario described above where Franklin Sisters Market would like to stock physical gift cards at their retail location.

At block 616 of Figure 6, a determination is made on whether the activation request is authorized. In some implementations, the request may be authorized if the identifier is successfully identified and the financial information provided by the customer is reliable and adequate for transferring the funds from the customer's financial institution to the activation platform 116 of Figure 1. In other information, additional security measures are employed to prevent fraud. For example, the customer's information may be sent to a third-party vendor for a credit check, fraud history check, etc. As part of the additional security measures, a user may take a picture of their face, credit card, driver's license, etc. to determine that the user is associated with the payment information and that the activation should be authorized. Also or alternatively, the determination can be delayed until the point when a customer attempts to use the stored-value payment card, allowing for more time to complete additional security measures concerning the customer attempting to activate the stored-value payment card.

At block 620 of Figure 6, an indication that the activation has been authorized is transmitted. When the request is authorized, funds are provided from the customer's financial institution to the provider of gift platform 104. Funds can be provided to the gift platform 104 immediately or at certain time such as at the end of business day, 24 hours from the authorization, etc. In some implementations, gift platform 104 may send a notification to merchant 112(a) indicating that the activation has been successfully authorized. In other implementations, gift platform 104 may send a notification to customer 108(a) as well. The notification may be in the form of a push notification, text message, email, phone call, or some other form of audio-visual prompt indicating successful authorization.

While various implementations have been described herein, it should be understood that the examples of activation of stored-value payment cards handled by the stored-value payment card activation platform have been presented by way of example only, and not limitation. The stored-value payment card activation platform can be configured to activate using other activation techniques including those know in the art, but not mentioned above. Furthermore, it is appreciated that other implementations are possible. For example, subscriber identity module (SIM) cards may also be activated using similar techniques. Examples of such techniques are described by way of example of Figures 2 and 7.

In certain implementations, at 702, location data of the mobile device may be received by SIM platform 204 of Figure 2. In various implementations, the location data may be provided along with the identification data of 704 or may be transmitted separately (e.g., from a GPS connection). In certain implementations, the location of the mobile device may be determined from metadata within the identification data.

At 704, identification data is received from the user. The location data received in 702 may inform the type of identification data needed from the user and such data may be requested from the user. The identification data may be transmitted by, for example, a mobile device and include data as described herein. In various examples, the identification data may be transmitted from the mobile device through a data connection other than the connection that the SIM card enables (e.g., a WiFi connection). In certain implementations, the identification data may be provided to the SIM card activation platform 316 or other platforms of SIM platform 204.

After the identification data has been received, the identification data is processed in 708. Processing of the identification data may include confirming the identity of the user through the data provided. For example, the identity of the user may be confirmed through pictures provided of the user and pictures of the identification documents. In certain implementations, as the user needs to be authenticated in real time, the portal of the mobile device and/or the SIM platform 204 may be configured to only accept contemporaneous pictures (e.g., photographs or video obtained by the mobile device at the time). Additionally, to confirm the authenticity of identification documents which may have certain security features, the mobile device and/or SIM platform 204 may require that pictures of the identification documents be taken from several angles to, for example, reveal watermarks of the identification documents. Furthermore, the identification data may include a photograph of the SIM card and any code (e.g., a machine-readable barcode, a series of characters, a QR code, or other identification techniques) provided on the SIM card. Such data may be processed to authenticate the user and the documents provided.

After processing, the request may be processed in 712. The request may be received along with the location data, identification data, or other data provided by the user. The request may be, for example, a request to activate a SIM card or to add value to a SIM card. The SIM card to be activated or value added to may be identified from the code provided of the SIM card. In some implementations, the code of the SIM card is identified using feature recognition techniques such as matrix matching techniques described herein. Such techniques may also be used on identification documents provided and be utilized to identify the user from, for example, previous photographs on store of the user.

The various images required (e.g., of the documents, user, and SIM card) may be captured by one or more cameras of a mobile device. In certain implementations, more than one image can be captured by the customer 208(n) and provided to SIM platform 204. These additional images might be used to provide a more accurate representation of the code, documents, and the user and/or used to spot fakes. Other types of images can also be provided to SIM platform 204. For instance, a thermal image or 3D image (or a collection of images from different angles) of the user may be obtained to prevent fraudsters from fraudulently presenting a previously printed photograph of the user as the user itself. In some implementations, authentication may be performed based on one or more machine learning techniques that refine and improve the accuracy of the identification process. Thus, the identification data may be used to prevent fraud (e.g., from fraudsters stealing a user's identity and registering SIM accounts in the user's name).

In certain implementations, location data may be used to further authenticate the user. Thus, a SIM card may be associated with a specific region. If the location data indicates that the location of the mobile device requesting the SIM card activation does not match the specific region, activation of the SIM card may be denied.

At 716, a determination is made on whether the identification data and/or the location data provided is enough to authenticate the user and authorize the request. In certain implementations, a request to activate a SIM card may require a higher level of documents provided than a request to add value to a SIM card. In some implementations, the request may be authorized if the user is successfully authenticated and the SIM card is successfully identified. Accordingly, if successful, the SIM card may be activated and/or the account value of the SIM card may be changed accordingly.

At 720 of Figure 7, an indication that the request has been processed is transmitted to the mobile device. Furthermore, if the SIM card has been inserted into the mobile device, the mobile device may now communicate over the telecom's network. Alternatively, instructions to couple the SIM card to the mobile device may be provided. In other implementations, an indication may be provided that the account of the SIM card has changed.

The techniques described herein allow for construction of a plurality of merchant storefront that includes multiple panels (e.g., webpages or portions of webpages) in front-end applications. 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 8-10 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 8-10 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 8-10 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 8-10. In certain implementations, the systems of Figures 8-10 utilize object-relational mapping (ORM) to process data between the various APIs, databases, and other components. Furthermore, the systems of Figures 8-10 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 8-10 also support multilingual application and user interface and user experience customizations without the need for additional code. Figure 8 illustrates an example of a simplified block diagram of a computing system, in accordance with some implementations. Figure 8 illustrates a computing system with application 802 and engine package 804.

Application 802 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 802 may allow for a user to purchase gift and/or SIM cards and/or provide gift and/or SIM cards for sale/resale. In certain such implementations, application 802 may allow for a seller or reseller to set up a storefront utilizing the systems and techniques described herein.

Engine package 804 may be a server device or a portion thereof. Engine package 804 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 multicore 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 804 allows for the creation and implementation of various APIs and processes as described herein. Engine package 804 includes engine 806 and layout 808. In certain implementations, engine 806 may allow for creating, reading, updating, and deleting resources. Various components of engine 806 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 806 may include form engine 810, table engine 812, and storage engine 814. In various implementations, engine 806 includes form engine 810, table engine 812, and storage engine 814. Layout 808 provides for the implementation of application logic for the processes as described herein, including processes such as middleware 816, localization 818, service 820, access rights 822, error handling 824, and analytics 826. 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 804 may utilize object-relational mapping to perform the creating, reading, updating, and deleting actions.

Figure 9 illustrates an example of a simplified block diagram of another computing system, in accordance with some implementations. Figure 9 illustrates a computing system that includes user 902, API 904, API service 906, engine package 908, and resource engine 910. User 902 may utilize an electronic device (a.k.a., user device) that includes one or more applications for purchasing, 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 904. In certain implementations, user 902 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 904 may be APIs associated with performing one or more techniques as described herein. API 904, in certain implementations, allow for applications to perform the techniques described herein. In certain implementations, API service 906 may maintain API 904 and may, for example, maintain aspects of API 904 based on data from engine package 908. Thus, based on data from engine package 908, API service 906 may update API 904.

Engine package 908 includes storage 912, metadata 914, and operational data 916. Engine package 908 may be configured to create, read, update, and delete various resources. The configuration of engine package 908 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 908 allows for efficient querying of resources, insertion of new records, and/or updating and deleting of records. In certain implementations, API service 906 allows for all API interactions with data to be performed through engine package 908. Furthermore, engine package 908 manages the relationship between data stored in various portions of engine package 908.

In a certain example, the system described in Figure 9 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 9 allows for an update of one key to affect the other entity.

In certain implementations, engine package 908 is configured for ORM. ORM with engine package 908 allows for API service 906 and/or API 904 to interface with the various databases. Thus, data from the database (e.g., storage 912, metadata 914, and operational data 916) may be queried, edited, and/or inserted into API 904 through, for example, API service 906 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 912 may be configured to store data and/or connect to and transfer data to API service 906 and/or API 904. Storage 912 may be configured to store data as described herein. Storage 912 may include a plurality of functions, such as get 918, save 920, and delete 922. Storage 912 includes its own get 918, save 920, and delete 922 functions in order to be compatible with a plurality of different data storage techniques (e.g., providers 924). Thus, for example, stage 912 may interface with different database, including different storage techniques utilized by different merchants. Each of these functions may allow for engine package 908 to access back-end data stored within storage 912 and allow for such data to be processed (e.g., by API service 906 and/or API 904). Storage 912 may also allow for analytics to be performed on the stored data.

Operational data 916 may be data directed to determining where resources are provided (e.g., displayed) with API 904. Thus, operational data 916 allows for adding, deleting, and/or editing of resources used in API 904. Operational data 916 may, thus, receive resources and convert the resources to an appropriate format for API 904 and/or API service 906 or vice versa.

Metadata 914 may include form configuration 926, table configuration 928, and data 930. Metadata 914 may govern the look and feel of forms, lists, and references (e.g., for a given resource). Resource engine 910 may govern the application of resources for API service 906 and/or API 904 (e.g., provide the resources requested by API service 906 and/or API 904).

Figure 10 illustrates an example of a simplified block diagram of a further computing system, in accordance with some implementations. Figure 10 illustrates a system that includes model 1018, storage 1012, and resource package 1010. Storage 1012 may be similar to storage 912 of Figure 9. Model 1018 allows for querying of resources from storage 1012 as well as inserting, updating, and/or deleting of records from storage 1012. Interactions between the various APIs described herein may be through model 1018.

Resource package 1010 includes form engine 1014 and table engine 1016. Form engine 1014 may be configured to add and edit resources while table engine 1016 may be configured to control tables that display a set of resources. Form engine 1014 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 1014 may receive metadata and render forms for the data. Thus, form engine 1014 will obtain attributes for fields that are required within a form. Form engine 1014 will also control the appearance of the form. In certain implementations a merchant may customize the look of their storefront appearance. Form engine 1014 may provide for that customized appearance, if any. Otherwise, form engine 1014 may render the form with its default appearance. Form engine 1014 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 1014 may handle some or all stages of storing and retrieving data from the model 1018 and storage 1012.

Additionally, form engine 1014 may be configured to authenticate selfhosting merchants. Thus, in certain examples, merchants may host their own storefronts. However, such storefronts may still need to confirm with certain requirements. Form engine 1014 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 1014 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 1018 and storage 1012.

Table engine 1016 provides for a set of tools to create and control tables with metadata. Table engine 1016 includes features such as sort, filter and search, and pagination for resources. In various implementations, table engine 1016 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 1018 and storage 1012, store, sort, search and/or paginate various states in a URL, search, with form engine 1014, relation fields, and/or store searches.

Figure 11 illustrates one example of a computing device. According to various embodiments, a system 1100 suitable for implementing embodiments described herein includes a processor 1101, a memory module 1103, a storage device 1105, an interface 1111, and a bus 1115 (e.g., a PCI bus or other interconnection fabric.) System 1100 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 1101 may perform operations such as those described herein. Instructions for performing such operations may be embodied in the memory 1103, 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 1101. The interface 1111 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 12 illustrates an example configuration of a neural network, configured in accordance with some implementations. Figure 12 illustrates a neural network 1200 that includes input layer 1202, hidden layers 1204, and output layer 1206. Neural network 1200 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 1200 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 1200 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 1200 may be trained with data input. Input layer 1202 may include such inputs. Hidden layers 1204 may be one or more intermediate layers where logic is performed to determine aspects of items for training neural network 1200. Output layer 1206 may result from computation performed within hidden layers 1204 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.

Claims

1. A method comprising:

processing a request to access a stored-value payment card activation platform, the request associated with a transaction associated with a stored- value payment card;

receiving an image of an identifier associated with the stored-value payment card;

authenticating the request; and

transmitting, responsive to the authentication, an indication that the transaction has been approved.

2. The method of claim 1, wherein the request is associated with activation of the stored-value payment card and comprises payment information and a value to be associated the stored-value payment card, wherein the authenticating the request comprises determining that the request to activate the stored-value payment card is authorized, and wherein the indication comprises an indication that the stored-value payment card has been activated.

3. The method of claim 2, further comprising:

receiving an image of a user, the image being one or more of: an image of an identification card of the user or an image of a face of the user, wherein the authenticating the request comprises determining, using the image of the user, that the user is associated with the payment information.

4. The method of claim 1, wherein the image of the identifier is captured using a camera of a mobile device, and wherein the request to activate the stored- value payment card includes data captured using a global positioning system sensor of the mobile device.

5. The method of claim 1, wherein the image of the identifier associated with a stored-value payment card is processed using one or more machine learning techniques, the one or more machine learning techniques configured to identify characters of the identifier.

6. The method of claim 1, wherein the request to access the stored-value payment card activation platform comprises processing login credentials associated with a user of the activation platform.

7. The method of claim 1, wherein the request comprise a request to transfer a value of the stored-value payment card.

8. The method of claim 7, further comprising:

transmitting, based on the authenticating the request, the stored-value payment card to a second device.

9. The method of claim 7, wherein the request to transfer the stored-value payment card is communicated using one or more of: Bluetooth, wireless internet, or near field communication.

10. The method of claim 7, wherein the request to transfer the stored-value payment card includes comprises an image captured from a camera of a mobile device, and wherein the authenticating the request comprise analyzing the image.

11. The method of claim 7, wherein the request to transfer the stored-value payment card includes comprises one or more of: QR codes, bar codes, radio frequency identification, iris recognition, facial recognition, magnetic stripes, optical character recognition, or voice recognition.

12. A subscriber identification module (SIM) platform configured to perform operations comprising:

receiving a request to activate a subscriber identification module (SIM) card; receiving identification data associated with a user of the SIM card, wherein the identification data comprises an image of an identifier associated with the SIM card;

authenticating the user based on the identification data;

determining that the request to activate the SIM card is authorized; and activating the SIM card based on the authorization.

13. The SIM platform of claim 12, the operations further comprising:

receiving location data associated with a current location of the user; determining that the location data indicates that the current location is within a region associated with the SIM card, wherein the authenticating is further based on the determining that the location data indicates that the current location is within the region.

14. The SIM platform of claim 13, wherein the SIM card is configured to be utilized within the region.

15. The SIM platform of claim 12, the operations further comprising:

transmitting, responsive to determining that the request to activate the SIM card is authorized, an indication that the SIM card has been activated.

16. The SIM platform of claim 12, wherein the identification data further comprises one or more of: an image of the user and an image of an identification document of the user.

17. A computer program product comprising one or more non-transitory computer readable media having instructions stored thereon for performing a method, the method comprising:

processing a request to access a stored-value payment card activation platform;

receiving an image of an identifier associated with a stored-value payment card; processing a request to activate the stored-value payment card, the request including payment information and a value to be associated the stored- value payment card;

determining that the request to activate the stored-value payment card is authorized; and

transmitting, responsive to determining that the request to activate the stored-value payment is authorized, an indication that the stored-value payment card has been activated.

18. The computer program product of claim 17, wherein the image of the identifier is captured using a camera of a mobile device, and wherein the request to activate the stored-value payment card includes data captured using a global positioning system sensor of the mobile device.

19. The computer program product of claim 17, further comprising:

receiving an image of a user, the image being one or more of: an image of an identification card of the user or an image of a face of the user; and

determining, using the image of the user, that the user is associated with the payment information.

20. The computer program product of claim 17, wherein the image of the identifier associated with a stored-value payment card is processing using one or more machine learning techniques, the one or more machine learning techniques configured to identify characters of the identifier.