+

WO2018013458A1 - Approximation à faible latence d'optimisation combinée de quantités résiduelles lors de l'attribution de grandes collections de cartes de valeur stockées - Google Patents

Approximation à faible latence d'optimisation combinée de quantités résiduelles lors de l'attribution de grandes collections de cartes de valeur stockées Download PDF

Info

Publication number
WO2018013458A1
WO2018013458A1 PCT/US2017/041319 US2017041319W WO2018013458A1 WO 2018013458 A1 WO2018013458 A1 WO 2018013458A1 US 2017041319 W US2017041319 W US 2017041319W WO 2018013458 A1 WO2018013458 A1 WO 2018013458A1
Authority
WO
WIPO (PCT)
Prior art keywords
stored value
balance
cards
card
user
Prior art date
Application number
PCT/US2017/041319
Other languages
English (en)
Inventor
Aaron Dragushan
Shaun F. DUBUQUE
Original Assignee
Retailmenot, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/208,128 external-priority patent/US20160321666A1/en
Application filed by Retailmenot, Inc. filed Critical Retailmenot, Inc.
Publication of WO2018013458A1 publication Critical patent/WO2018013458A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/351—Virtual cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices

Definitions

  • a stored value card which includes the digital equivalent.
  • Examples include open-loop stored value cards and closed-loop stored value cards, each of which may take various forms, such as gift cards, rebate cards, payroll cards, and the like.
  • the value stored on the card is spent by presenting to a retailer certain information, such as a card number and a pin number.
  • FIG. 6 illustrates an example of a computer system by which the above techniques may be implemented.
  • the referenced technologies can provide/maintain a gift card repository and can enable the efficient utilization of such cards in retail settings (both 'brick and mortar' and ecommerce).
  • a user can utilize gift cards to make retail purchases (thereby benefitting from the discount associated with the utilization of otherwise unused gift cards) in substantially the same amount of time as a conventional retail checkout process would take. In doing so, the user can benefit from the discount associated with gift card utilization while maintaining an efficient/seamless checkout process/experience.
  • FIG. 1 depicts an illustrative system architecture 100, in accordance with one implementation of the present disclosure.
  • the system architecture 100 includes one or more user devices 102, merchant devices 104, and server machine 120. These various elements or components can be connected to one another via network 110, which can be a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof. Additionally, in certain implementations various elements may communicate and/or otherwise interface with one another (e.g., user device 102 with merchant device 104).
  • the various illustrated computing devices may be formed with one or more of the types of computer systems described below with reference to Figure 6.
  • Merchant device 104 can be a rackmount server, a router computer, a personal computer, a portable digital assistant, a mobile phone, a laptop computer, a tablet computer, a camera, a video camera, a netbook, a desktop computer, a media center, a smartphone, a watch, a smartwatch, an in-vehicle computer/system, a point of sale (POS) system, device, and/or terminal, any combination of the above, or any other such computing device capable of implementing the various features described herein.
  • Various applications such as mobile applications ('apps'), web browsers, etc. (not shown) may run on the merchant device (e.g., on the operating system of the merchant device).
  • merchant device 104 may be a dedicated POS terminal (e.g., including an integrated barcode scanner) while in other implementations merchant device 104 may be a handheld or personal computing device (e.g., smartphone, tablet device, personal computer, etc.) configured to provide POS functionality (whether utilizing the functionality provided by the various POS terminals (e.g., including an integrated barcode scanner) while in other implementations merchant device 104 may be a handheld or personal computing device (e.g., smartphone, tablet device, personal computer, etc.) configured to provide POS functionality (whether utilizing the functionality provided by the various
  • merchant device 104 can be a server, such as a webserver that provides an ecommerce site/service, such as may be accessed by user device 102 via a website and/or dedicated application.
  • an application ('app') executing on user device 102 can request or otherwise determine a current location of the device (e.g., based on GPS coordinates, etc.). Based on the determined location, information regarding one or more retail establishments (e.g., those within a defined proximity to the current location) can be requested/retrieved and presented at the device. In certain implementations, such information can reflect those proximate retail establishments with respect to which gift cards are available (e.g., at gift card repository 140 of server machine 120).
  • an input can be received (e.g., as provided by the user via the device) that reflects a sale/purchase amount (e.g., the total amount charged by the retailer for a particular purchase, e.g., '$54.63').
  • a sale/purchase amount e.g., the total amount charged by the retailer for a particular purchase, e.g., '$54.63'.
  • one or more gift cards can be received, requested, and/or selected (e.g., from those gift cards previously received and stored in the memory of the user device).
  • such gift cards can be selected/requested (e.g., from gift card repository 140) based on any number of factors, such as the degree to which the credit amount of the gift card approximates/corresponds to the sale/purchase amount.
  • a gift card of a particular total value e.g., $100
  • a portion of the total value of the card e.g., $60
  • the gift card can instead be selected/provided (e.g., before the transaction has been completed and without initially charging/debiting the requesting user for the full value of the card), and once the transaction is complete the user can be charged/debited for the increment used during the transaction (e.g., based on the total purchase price as provided by the user, an independent verification of the gift card balance, etc.) while the remaining value on the gift card can be utilized in subsequent transaction(s) (e.g., by other users), such as in a manner described herein.
  • the increment used during the transaction e.g., based on the total purchase price as provided by the user, an independent verification of the gift card balance, etc.
  • the various selected/received gift cards can then be sequentially presented/provided, e.g., on the screen of the user device.
  • the user device e.g., a smartphone
  • the user device can be placed or otherwise oriented in relation to the merchant device (e.g., in relation to the barcode scanner of a POS terminal) such that the merchant device can scan, read, or otherwise perceive or capture the code/barcode of the gift card being presented.
  • the user can complete the retail transaction using gift cards originating at server machine 120.
  • the merchant device e.g., in relation to the barcode scanner of a POS terminal
  • gift cards can be provided sequentially in any number of ways.
  • feedback can be provided/received (e.g., provided by the user to the device, such as by swiping a touch screen or pressing a button) which indicates that another gift card is to be presented.
  • feedback may be provided/received, indicating that a particular gift card did not work (in which case a
  • various motion inputs e.g., a rotation/orientation of the user device, indicating that a barcode has likely been scanned
  • the user device e.g., via an integrated accelerometer, gyroscope, etc.
  • various aspects of the timing of the presentation of the referenced gift cards can also be accounted for, such that, for example, upon presenting a particular gift card for a defined time interval (e.g., 10 seconds), another gift card can be selected/requested and displayed.
  • one or more audio inputs can be received (e.g., by an integrated or external microphone) and processed in order to determine an amount/level of sound/noise (e.g., ambient noise) perceptible to the device.
  • an amount/level of sound/noise e.g., ambient noise
  • the user device is presenting the gift cards legitimately (e.g., in a retail setting)
  • a certain degree of ambient noise and/or various sounds, talking, beeps, etc.
  • a device that is being used inappropriately such that, for example, card numbers/codes are being recorded by the user
  • FIG. 3 illustrates an example of a process 300 to selectively determine whether to display balance-access information for stored value cards based on the output of classifiers that determine whether the mobile computing device executing the process 300 is likely in a retail store.
  • some gift card exchanges may send buyers of gift cards balance- access information for those gift cards (causing those users to be among the possessors of this information), such as a gift card number and a pin number.
  • users may attempt to engage in fraudulent transactions by purchasing gift cards, recording in their personal records the balance-access information, and then returning the gift card back to the exchange, for instance, by selling the gift card back to the exchange or by only using a portion of the balance of a gift card that is automatically returned.
  • Such users may then use the balance-access information to engage in a subsequent transaction, before the subsequent legitimate user of the gift card can use the remaining balance.
  • the user may present online or in person the information in their personal record of the balance-access information to spend gift-card value that they surrendered to the exchange.
  • some embodiments may selectively display the balance-access information in response to determining that the user is likely in a location at which they would have a legitimate reason for accessing such information, for example, at a point-of-sale terminal in a retail store that accepts the card.
  • access may be granted in response to determining that the user has crossed a geo-fence associated with a retail store.
  • such techniques while consistent with some embodiments, may leave open some relatively easy avenues for exploitation, for instance, by accessing the information while in the user's car in the parking lot of the store.
  • satellite navigation and geolocation services available on mobile devices are often unreliable and imprecise for indoor positioning, particularly for determining whether the user is within a relatively close distance to point-of-sale terminal, like within 3 to 5 meters, or less.
  • the process 300 begins with receiving balance-access information by which a stored value card balance (also referred to as a gift card, but not limited to gift cards) can be spent at a point-of-sale terminal, as indicated by block 302.
  • this information may be obtained upon (e.g., in response to) a user requesting with a web browser or native mobile application a gift card usable at a particular retailer, for instance, from the above- described gift card management service of Figure 1.
  • a multi-region press may be requested or required, for instance, with two fingers of the user's left hand on one side of the screen and two fingers of the user's right hand on the other side of the screen, such that some inferences about the likely orientation of the screen relative to the user may be drawn by the native mobile application, particularly when combined with readings from an inertial measurement unit, as described below.
  • the native mobile application may respond to such a multitouch input upon determining that the orientation of the screen is vertical, as would be the case when a user is holding the screen between their left and right fore fingers and thumbs vertically, with the screen oriented away from the user, toward a retail sales clerk viewing the screen to enter the balance-access information into a point-of-sale terminal.
  • a user may merely engage in input indicating the user wishes to use the card, and upon the user releasing a touch, the process may proceed.
  • some embodiments may continue to wait, or, upon determining that the user does request use the card, embodiments may proceed to the next step.
  • some embodiments may sense ambient signals, as indicated by block 308. In some cases, waiting to sense ambient signals until the user requests to use the card may reduce battery drain associated with constantly monitoring such signals, for instance, even when the user is nowhere near a retail store or has shown no intent to use a gift card. (Or some embodiments may constantly monitor such signals to provide a more responsive experience at the expense of power consumption.) In some cases, sensing ambient signals may be triggered by one of the two stages of a request to use the card described above, for instance, in response to a user requesting gift cards associated with a given retailer. In some embodiments, sensing of ambient signals may have a timeout threshold at which point sensing may cease to protect the battery of the mobile computing device, and a user may be presented with an input by which the user can indicate an intent to continue attempting to use a gift card.
  • a variety of different types of signals may be sensed with a variety of different types of sensors on the mobile computing device. In some cases, some of the signals or sensed without regard to whether the user request use the gift card, while other signals, particularly more battery intensive sensors are engaged responsive to a user request.
  • the sensor is a radio of the mobile computing device, and the signal is a wireless beacon, such as a Wi-Fi beacon or a Bluetooth beacon, or an NFC identifier.
  • a beacon identifier encoded in the beacon may be compared against a list of identifiers associated with retail stores at which the gift card may be legitimately used, and a wireless environment score may be calculated based on the result of this comparison.
  • the techniques described in U.S. Patent Application 14/839,058, titled "REDUCING THE SEARCH SPACE FOR RECOGNITION OF OBJECTS FN AN EVIAGE BASED ON WIRELESS SIGNALS,” filed 28 August 2015 may be used to this effect.
  • the sensed ambient signals may be audio signals sensed with a microphone of the mobile computing device.
  • the sensed signals may be time- series signals, such as an amplitude of audible signals that varies over time.
  • multiple microphones on the mobile computing device may sense multiple audio feeds, and those audio feeds may be used in subsequent steps to determine a directionality of signals.
  • the mobile computing device may have a magnetometer, which may sense a time varying magnetic field and orientation of the magnetic field, such as the user moves through the store, or as may occur due to electromagnetic signals emitted by the operation of circuitry in a point-of-sale scanner. Variations in such signals, either in time or space, may be classified as indicating presence at a point of sale terminal.
  • the mobile computing device may include an inertial measurement unit, such as a six axis accelerometer operative to sense changes in rotational velocity at about three orthogonal axes and the changes in linear translation speed about three orthogonal axes.
  • the inertial measurement unit may be operative to sense a downward direction due to acceleration from gravity.
  • the inertial measurement unit may output a
  • image signals may be classified, for instance, based on whether the image contains a point-of-sale terminal.
  • a training set of such images may be captured and manually labeled as including such a point-of-sale terminal.
  • Some embodiments may train a neural network based on the labeled training set, for example, a convolution neural network having a convolution layer corresponding to the portion of the image depicting the point-of-sale terminal.
  • a multidimensional time series from the inertial measurement unit may be classified as indicating a particular gesture has occurred or that the mobile computing device is oriented in a particular direction. For instance, to determine whether the mobile computing device is oriented in a particular direction, some embodiments may determine whether the signal corresponding to a particular axis of the inertial measurement unit (e.g., averaged over some trailing duration of time, like one second) exceeds a threshold, indicating the consistent pull of gravity in a particular direction, like when the phone is oriented vertically right side up or upside down or horizontally right side up or upside down.
  • a threshold indicating the consistent pull of gravity in a particular direction
  • some embodiments may classify such time series as including a qualifying gesture with a dynamic time warp analysis. For example, a training set of users may be asked to engage in the gesture, and a template for a dynamic time warp algorithm may be trained, for instance with dynamic programming and tuned constraints, based on the sensor data from the training exercise. Later, this template may be compared against sensor data obtained when a user request to use a gift card, and the sensor data may be classified as indicating a gesture associated with legitimate use.
  • some embodiments may determine whether the classification score exceeds a threshold, as indicated by block 312. In some cases, this threshold may be modulated with the techniques described above by which the weights for combining the various classification scores are combined. Upon determining that the score does not exceed the threshold, some threshold may be modulated with the techniques described above by which the weights for combining the various classification scores are combined. Upon determining that the score does not exceed the threshold, some threshold may be modulated with the techniques described above by which the weights for combining the various classification scores are combined.
  • embodiments may continue to sense ambient signals, returning the step 308, in some cases until a timeout determination is made to preserve the battery life of the mobile computing device.
  • Some embodiments may instruct a mobile computing device to block the mobile computing device from performing a screen capture. Some embodiments may display the balance-access information for a threshold amount of time that is relatively short (e.g., less than five seconds, less than one second, or less than one-half of one second), such that the information may be captured by a machine, but is too quickly removed to be reliably captured by human being. Some embodiments may flash the information on the screen repeated times, such that the scanner has multiple opportunities to capture the information, while a human would find it difficult to record the information.
  • Some embodiments may animate movement of the code on the screen to bring the code in and out of focus of a user camera attempting to capture an image of the code, e.g., exceeding a tracking rate of typical autofocus mechanisms in consumer cameras, while staying within a tracking rate that can be accommodated by point of sale scanners.
  • Some embodiments may compose a plurality of scannable codes, like barcodes, some of which are internally inconsistent and invalid (e.g., dummy codes), and one of which contains the balance-access information in an internally consistent scannable code.
  • formats for some scannable codes include redundancy for purposes of error detection and correction, like parity bits.
  • Some embodiments may flash a sequence of scannable codes in which all but one of the scannable codes in the sequence, for example, a randomized one in the sequence, contain invalid codes in which the error detection and correction rules are violated, for instance, with an incorrect parity bit.
  • a point-of-sale terminal scanning the flashing codes will reject all but the legitimate code, while a user attempting to write down the codes will not know which one is legitimate without a much more laborious effort.
  • the gift card management system of Figure 1 may execute various routines to further reduce the likelihood of fraud. For instance, as described below with reference to Figure 4, some embodiments may infer register balances and select gift cards to match the inferred balance to expedite gift card exhaustion. For instance, some embodiments may estimate a register balance based on a distribution of previously known balances for a given retailer and for users deemed to have a profile similar to that of the user requesting cards.
  • choosing the appropriate stored value card is a relatively computationally challenging task.
  • the number of stored value cards is relatively large, for instance, exceeding 1000 cards, 10,000 cards, and in some cases 100,000 cards, with the various cards have varying remaining balances falling within a range of values that can also be relatively large, such as spending between $0.10 and $5000.
  • the weights of the weighted combination may be adjusted based on historical data. For instance, some embodiments may arbitrarily select weights, and then iteratively adjust the weights based on the historical data to reduce or minimize an amount of cumulative error between predictions by the weighted sum of previous transactions being fraudulent and observed results of those historical transactions either being fraudulent or non-fraudulent. In some cases, this historical data may be a training set that is relatively large, for instance, having more than 10,000 previous transactions, more than 100,000 previous transactions, or more than 1 million previous transactions, with transactions labeled as either fraudulent or non-fraudulent. Weights may be re-calculated periodically as a batch process, e.g., weekly.
  • stored value cards with lower demand scores may be favored when selecting a stored value card to be provided over stored value cards with higher demand scores likely to qualify to respond to other requests.
  • a demand score may correspond to a spread between a market-clearing discount to obtain cards and a card balance or a market-clearing discount to provide cards and a card balance, or a combination thereof.
  • choosing the appropriate stored value card includes determining whether to deploy a relatively low or relatively high risk stored value card or collection of cards in response to a given request, where that request is one of a relatively large number of requests received over a relatively short duration of time, like at a rate exceeding 10 per minute, 100 per minute, or during holidays, 1000 per minute.
  • some embodiments may infer a register balance and select a stored value card or set of stored value cards relatively quickly in a way that exhausts balances while accounting for risk and demand associated with the respective cards. Or some embodiments may provide a subset of these benefits or other benefits. These techniques are exemplified by the process 400 of Figure 4.
  • the geolocation may be obtained by a native mobile application of the client device, for instance, by querying a geolocation framework of an operating system of a mobile computing device and receiving a geolocation, like a geolocation determined based on a current wireless environment, for instance, based on Global Positioning System sensors, cell tower tri angulation, Wi-Fi beacons, Bluetooth beacons, or the like.
  • the reported geolocation may be associated with an uncertainty, such as a confidence radius.
  • the request may specify a merchant, such as a merchant with which the user intends to engage in a transaction, and a merchant that accepts stored value cards of the type requested. In other embodiments, the merchant may be inferred, as described below.
  • some embodiments may infer, based on the request, a transaction balance of a transaction in which the requested stored value card is to be used, as indicated by block 406, and infer, based on the request, a merchant to participate in the transaction, as indicated by block 408. In some cases, these steps may be performed concurrently or in the different order from that described, which is not to suggest that other steps must be performed in the order presented.
  • transaction amounts may be inferred based on the merchant. For instance, some embodiments may periodically interrogate historical transaction records by grouping the records by merchant, such as records extending into a previous year, and calculating a measure of central tendency of transaction amounts for each merchant, like a mean, mode, or median. In some cases, other distributional statistics may be calculated, like a variance, standard deviation, or other parameters of other distributions, like lambda of a Poisson distribution. In some embodiments, the inferred transaction amount may be based on these values, which may be calculated in advance of receiving the request, for instance, as a batch process nightly or weekly to expedite responses. In some cases, the inferred amount may be the measure of central tendency value for the respective merchant.
  • a native mobile application executed by client devices may be configured to automatically or in response to user input apply offers, then stored value cards from an exchange (like from the gift card management system herein), and then transfer value to the merchant via an electronic wallet to satisfy the balance with the aggregate of these three measures, e.g., in that order, such that coupons are applied, first, then stored value cards, then an electronic wallet.
  • the native mobile application may be provided the transaction balance in the course of this sequence, such as via a near field communication exchange with a point-of-sale terminal, or via other wireless exchanges or based on information being entered by a user, e.g., spoken and processed by a speech-to-text algorithm or entered on a touchscreen.
  • inferring the transaction balance may include calculating the transaction balance, for instance, after one or more offers are applied, but before an electronic wallet is accessed to satisfy the remaining balance.
  • this inference may be performed client-side, with the client reporting the inferred amount to the server, or server-side (e.g., at the gift card management system).
  • the above-described coefficient may be adjusted in response to a user engaging in this type of use case, as users are expected to be less put off by a transaction balance remaining after the gift card is applied when an electronic wallet is integrated into the user experience.
  • the coefficient may be a negative value in response to the user engaging in this workflow, and a positive value in response the user not requesting the use of an integrated electronic wallet following the presentation of stored value cards.
  • the merchant may be inferred.
  • the merchant may be inferred based on a geolocation associated with the request. For instance, some embodiments may maintain a geographic information system having polygons corresponding to boundaries of merchant retail establishments, and some embodiments may determine whether the geolocation associated with the request falls within one of those polygons or identify a closest polygon to identify the merchant.
  • the merchant may be identified by other attributes of the current wireless environment, such as based on an identifier in a Bluetooth beacon or in a wireless local area network beacon emitted within the merchant's facility and sensed by a native application executing on the client device.
  • beacons encoded in overhead lighting fluctuations and beacons encoded in in-store audio, each of which may also be sensed by the native application.
  • these identifiers may be reported to the gift card management system to facilitate identification of the merchant.
  • the gift card management system may maintain a mapping of these identifiers to the corresponding merchants, and in some cases, information like signal strength associated with the identifiers, such that users may be triangulated to be within a merchant's facility based on both signal strength and identifier values.
  • the transaction balance or merchant may be inferred based on a profile of the user associated with the client computing device issuing the received request. For instance, some embodiments may maintain in such user profiles a list of historical transactions by the user, each transaction identifying a merchant facility or merchant, and in some cases a category in a taxonomy of merchants, such as a hierarchical taxonomy. Some embodiments may rank for each user the set of merchants (or facilities, or categories) according to a transaction frequency and infer a highest ranking merchant (or facilities, or categories). Or some
  • embodiments may determine that two merchants are within a threshold distance of a geolocation of the request and select among the two candidate merchants based on which of the two candidate merchants appears higher in the ranking. Or some embodiments may construct a ranking of categories in the taxonomy according to transaction frequency and select between the candidate merchants based on which falls within a higher ranking category for the respective user. To expedite responses, some embodiments may pre-calculate these rankings, for instance periodically, like in a weekly batch process. In some cases, the rankings may be adjusted based on freshness of the transactions, for instance up weighting more recent transactions, like according to a half-life score, where the weight afforded a transaction decreases by half according to some half-life duration of time.
  • Some embodiments may ascertain a subset of stored value cards that are accepted by the inferred merchant, as indicated by block 410. In some cases, this step may be performed by querying the repository of stored value card records for records that indicate the respective stored value card is accepted by the inferred merchant. In some embodiments, the query may specify that stored value cards less than or equal to the inferred balance are requested to reduce the amount of responsive records and render subsequent computations more tractable, though embodiments are consistent with other implementations. [0099] Next, some embodiments may retrieve values remaining on the subset of stored value cards, as indicated by block 412.
  • the subset of stored value cards may be relatively large, for example, more than 50, and in many cases more than 500 or more than 5000 stored value cards in inventory may be accepted by the inferred merchant. In some cases, other values may be retrieved as well, like the other values described above as being in the stored value card records. In some embodiments, the subset may be too large to be computationally feasible for subsequent steps, and some embodiments may determine whether the subset exceeds a threshold count and sample the subset, for instance randomly, up to the threshold. Or some embodiments may select among the subset according to various other criteria, for instance, ranking the subset according to the demand score or the risk score or a weighted combination thereof and selecting those with a rank that satisfies a threshold ranking.
  • the selection may account for combinations of the stored value cards, such as up to some threshold amount of cards in combination, like 2, 3, 4, 5, or more stored value cards in combination.
  • some stored value cards may include relatively small balances that may be requested relatively rarely, and combining cards is expected to be an effective way to dispose of that inventory (though not all embodiments afford this benefit).
  • Some embodiments may calculate the above-described differences for each combination of stored value cards up to some threshold and select a response of combination according to the aggregate balance of the combination, as described above. [00102] However, selecting among the possible combinations is often a relatively computationally taxing task, as the amount of combination scales relatively poorly with the number of cards to be combined and the number of cards in the subset.
  • the value scales according to a binomial coefficient function, e.g., choosing combinations of 4 from 1000 cards yields 41,417, 124,750 possible candidates. Processing one candidate per cycle of a modern CPU, which significantly understates the challenge as analysis takes substantially more cycles, would take over ten seconds for a 3 GHz clocked CPU.
  • combinations or subsets of possible combinations may be precalculated. For instance, some embodiments may precalculate an inventory of representative combinations, with each item in the inventory corresponding to some range of values of relatively fine granularity, such as by a one cent or ten cents. In some embodiments, within each bin, some embodiments, may identify combinations that fall within the bin and otherwise score relatively favorably according to demand and risk, for instance, populating each bin with a threshold number of combinations, like 10 or more. Some embodiments may then deplete the inventory of candidate combinations by accessing these precalculated combinations, selecting from a bin that matches an inferred transaction balance. In some embodiments, the pre-calculated combinations are selected such that cards in one precalculated combination are not shared with another precalculated combination, to avoid interactions that might otherwise arise when one
  • the aggregate amounts may be precalculated and associated with identifiers of the cards constituting the combinations, for instance, in a sorted list by aggregate amount to expedite search. Some embodiments may then query the sorted list to identify a precalculated combination that matches (e.g., either exactly or according to the above- described difference calculations) the inferred transaction balance. Or some embodiments may perform the calculations at the time of the request, e.g., on a subset of the candidate
  • some embodiments may send balance-access information by which the selected stored value card balances can be spent, as indicated by block 418.
  • this may entail sending balance-access information for only one stored value card or may include sending balance-access information for a plurality of cards.
  • the cards may be sent in ranked order according to the balance, with higher balance cards being sent first.
  • the cards may be sent in ranked order according to risk, with higher risk cards being sent first.
  • the cards may be sent in ranked order according to demand, with lower demand cards being sent first.
  • the cards may be sent in ranked order according to a weighted combination (such as a weighted sum) of these parameters.
  • Some embodiments may execute routines that render such fraud easier to detect. For instance, some embodiments may distribute cards geographically to enhance the power of the purchase location to signal fraud.
  • a card may be sent to a first geographic area and returned with a balance. Later, a user in a different geographic area (e.g., more than a threshold distance, or having less than a threshold co-occurrence rate among users between the two locations) may request a card for the same retailer. The card for the later user may be selected in response to determining that this geographic threshold is satisfied. A different later user in the first geographic location may not be provided the card upon determining that the geographic locations are the same.
  • the location of the fraud is expected to be indicative of which user holding a given card engaged in fraud, as it is expected to be less likely that a user will travel to a relatively distant geographic location to spend a card they previously surrendered, rather than attempt to use the same card in their same area.
  • the process 500 begins with receiving a stored value card from a first computing device and a first geolocation of the first computing device, as indicated by block 502.
  • the step may include receiving and updating the information in the above- described stored value card records created when a stored value card is received from a user.
  • the stored value card may be received from an initial owner of the stored value card, such as a person who received the card as a birthday gift or bought the card in a store, or in some cases, the stored value card may be received from a subsequent possessor of the stored value card information, such as someone who received the balance-access information according to the above-describe techniques.
  • some embodiments may receive a request for a stored value card from a second computing device at a second geolocation, as indicated by block 504.
  • some embodiments may determine to not send the stored value card to the second computing device as a result of the second geolocation being within a threshold geographic distance to the first geolocation, as indicated by block 506. This determination may be made with a variety of techniques and does not necessarily require comparing the threshold geographic distance to a distance between the first and second geolocations.
  • the first geolocation may be with within one region of the country and the second geolocation may be within the same region, like within the same state or within the same city or ZIP Code.
  • some embodiments may make the determination by determining that the first geolocation and the second geolocation are within the same geographic region, such as a geographic area larger than 1 km 2 and smaller than 100,000 km 2 or the continental United States.
  • the determination may be that the second geolocation is within the threshold geographic distance of the first geolocation, such as within less than 10 km, less than 100 km, or less than 1000 km.
  • the determination may be that the second geolocation is within some threshold travel time of the first geolocation, such as within less than 10-minutes travel, 1-hour travel, 10-hours travel, or two-days travel, by various modes of travel, such as by automobile, by airplane, by walking, or the like.
  • the determination may be based on other factors beyond geolocation. For example, some embodiments may adjust the size of the threshold based on other similarities in user profiles associated with the first computing device and the second computing device. Some embodiments may determine that the user profile associate with the first computing device has more than a threshold number of transaction co-occurrences historically with the second computing device and, as a result, determine not to send the stored value card to the second computing device or determine to adjust the threshold with respect to distance to be smaller.
  • the transaction co-occurrences may take a variety of different forms, including the respective users engaging in historical transactions with the same merchants, the same merchant locations, the same categories a merchants, or combinations thereof.
  • the determination may be adjusted based on attributes of the stored value card. For example, stored value cards having a particularly low demand score less than a threshold or a risk or higher than a threshold may cause the system to adjust geographic distance thresholds or user profile similarity thresholds, for instance, decreasing the distance threshold in response to the demand score being less than a threshold to move cards in low demand even at the expense of higher risk of fraud for which blame is difficult to attribute.
  • some embodiments may determine not to send the stored value card to the second computing device because the second computing device's user is likely to use the stored value card in a way that is difficult to distinguish from uses by the first computing device user, thereby making it difficult to identify whether the first user or the second user engaged in a subsequent fraudulent transaction, for instance, by exploiting balance-access information of a stored value card that they already indicated have been surrendered to the gift card management system.
  • Some embodiments may then receive another request for a stored value card from a third computing device at a third geolocation, as indicated by block 508.
  • each of these receive requests may be similar in format.
  • the third computing device is associated with a different user account in different user profile from that of the first computing device and the second computing device.
  • some embodiments may determine to send the stored value card (e.g., sending the balance-access information and permission to use the same) to the third computing device as a result of the third geolocation not being within the threshold geographic distance to the first geolocation, as indicated by block 510.
  • this determination may be the same as the determination of block 506 except reaching the opposite result, such as the opposite result of any of the above-describe examples, e.g., based on region, travel time, co-occurrence rates, and the like, in some cases with thresholds dynamically adjusted based on card demand, risk, and similarities of user profiles.
  • users may be relatively latency sensitive when issuing the above-described requests. Iterating through candidate responses until one satisfies the presently described constraints may be relatively slow and difficult to predict in terms of response time.
  • some embodiments may index stored value cards according to various criteria, such as according to geolocations in which the stored value card is not to be provided to users or geolocations in which the stored value card is permitted to be provided to users, such as a white list of geographic regions or a blacklist of geographic regions.
  • Some embodiments may receive an indication that a balance of the stored value card has been depleted by unauthorized party, as indicated by block 514.
  • the step may be performed after block 502, after block 512, or after the third computing device (or an associated user operating a different computing device) has returned the stored value card.
  • it can be relatively difficult to identify which previous possessor of the stored value card information engaged in fraud, as often merchant records do not include identifiers of the user.
  • Many stored value cards are treated as analogous to cash for purposes of documenting the identity of the person engaging in the transaction.
  • some embodiments of the present techniques may permit the likely party responsible for the fraud to be probabilistically identified.
  • the indication may be a complaint by a subsequent holder of the stored value card that the card was insufficient to satisfy a transaction balance, or some embodiments may periodically automatically query an issuer or bank associated with the stored value card to identify a current card balance and compare that current card balance to an expected card balance of the previously returned card amount.
  • the discrepancy may constitute an indication of block 514.
  • the indication is merely a user complaint, and some
  • embodiments may proceed to determine that a balance of the stored value card is less than a balance attributable to authorize transactions, as indicated by block 516. For instance, some embodiments may query an API of a bank or issuer of the card for a current balance, and in some cases receive a response indicating attributes of transactions in which the stored value card is been used. In some cases, the response includes dates, times, locations, and merchants where the various transactions occurred.
  • some embodiments may obtain a record of an unauthorized transaction in which the stored value card was used, as indicated by block 518.
  • the issuer or bank does not offer an API, and some embodiments may interface with an automated telephone system, for instance by executing a text-to-voice routine that translates a text script to an audio signal transmitted over a telephone line to navigate through the automated telephone system and request the needed information. Some embodiments may then receive the responsive audio signal and translate the audio to text to obtain the record of the previous transactions.
  • some embodiments may determine from the obtain record an unauthorized- transaction geolocation in which the unauthorized transaction occurred, as indicated by block 520.
  • the geolocation may be a street address of a merchant at which the stored value card was fraudulently used.
  • Some embodiments may also maintain a record of each user's geolocation history and compare a current geolocation to the history to determine whether the user is at a location where a balance was accessed or at a different location for the same or a related merchant.
  • some embodiments may detect a fraudulent use based on this analysis that a user legitimately accessed a stored value card on a given day at a given merchant geolocation, then returned the card to the gift card management system, and on a later day returned to the same merchant geolocation (or that of another merchant in a chain) illegitimately accessed a balance of the stored value card.
  • some embodiments may infer a user account of a user that engaged in the unauthorized transaction based on the unauthorized-transaction geolocation, as indicated by block 522. For instance, some embodiments may identify or otherwise access a set of previous possessors of the balance-access information of the stored value card from the stored value card record, and rank the geolocations associated with each instance in which the card was received or sent according to distance to the unauthorized-transaction geolocation. In some cases, the user account associated with a conveyance having the shortest distance may be deemed as a likely party to have engaged in fraud. In some cases, the strength of this inference may be enhanced by the relative geographic distance among the previous possessors.
  • the user of the first computing device may be inferred to be the party that engaged in a fraudulent unauthorized use of the stored value card with relatively high confidence.
  • the user associated with the third computing device may be inferred with similar confidence to be the party that likely engaged in a fraudulent unauthorized use of the stored value card.
  • Some embodiments may respond by designating the corresponding user accounts in memory as being blocked from conveying (e.g., either receiving or providing) stored value cards. In some cases, the designation is at a lower level of confidence, and users may be designated differently in response.
  • the distance between the unauthorized- transaction geolocation and the geolocation associated with the user may be compared to a threshold, and if the distance is greater than the threshold, some embodiments may adjust (e.g., add to an accumulated score) a risk score associated with corresponding user based on the distance. Upon a user's accumulated risk score exceeding some threshold, some embodiments may designate the user as blocked from future conveyances of stored value cards.
  • the inference may also be based on, or instead be based on, other attributes of user profiles matching attributes of the unauthorized transaction.
  • the threshold geographic distance for blocking a user may be adjusted based on a determination that the merchants or merchant category in which the unauthorized transaction occurred corresponds to a merchant or merchant category having greater than a threshold rank according to frequency in a user profile of the respective user.
  • some embodiments may identify and block users likely to have engaged in fraudulent use of stored value cards by selectively distributing stored value cards in a way that enhances the strength of various signals by which unauthorized transactions may be matched with previous possessors of stored value card information.
  • Figure 6 is a diagram that illustrates an exemplary computing system 1000 in accordance with embodiments of the present technique.
  • Various portions of systems and methods described herein may include or be executed on one or more computer systems similar to computing system 1000. Further, processes and modules described herein may be executed by one or more processing systems similar to that of computing system 1000.
  • Computing system 1000 may include one or more processors (e.g., processors lOlOa- ⁇ ) coupled to system memory 1020, an input/output I/O device interface 1030, and a network interface 1040 via an input/output (I/O) interface 1050.
  • processors e.g., processors lOlOa- ⁇
  • a processor may include a single processor or a plurality of processors (e.g., distributed processors).
  • a processor may be any suitable processor capable of executing or otherwise performing instructions.
  • a processor may include a central processing unit (CPU) that carries out program instructions to perform the arithmetical, logical, and input/output operations of computing system 1000.
  • CPU central processing unit
  • a processor may execute code (e.g., processor firmware, a protocol stack, a database management system, an operating system, or a combination thereof) that creates an execution environment for program instructions.
  • a processor may include a programmable processor.
  • a processor may include general or special purpose microprocessors.
  • a processor may receive instructions and data from a memory (e.g., system memory 1020).
  • Computing system 1000 may be a uni -processor system including one processor (e.g., processor 1010a), or a multi-processor system including any number of suitable processors (e.g., lOlOa-lOlOn). Multiple processors may be employed to provide for parallel or sequential execution of one or more portions of the techniques described herein.
  • Computing system 1000 may include a plurality of computing devices (e.g., distributed computer systems) to implement various processing functions.
  • computing devices e.g., distributed computer systems
  • I/O device interface 1030 may provide an interface for connection of one or more
  • I/O devices 1060 to computer system 1000.
  • I/O devices may include devices that receive input (e.g., from a user) or output information (e.g., to a user).
  • I/O devices 1060 may include, for example, graphical user interface presented on displays (e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor), pointing devices (e.g., a computer mouse or trackball), keyboards, keypads, touchpads, scanning devices, voice recognition devices, gesture recognition devices, printers, audio speakers, microphones, cameras, or the like.
  • I/O devices 1060 may be connected to computer system 1000 through a wired or wireless connection.
  • I/O devices 1060 may be connected to computer system 1000 from a remote location.
  • I/O devices 1060 located on remote computer system for example, may be connected to computer system 1000 via a network and network interface 1040.
  • System memory 1020 may be configured to store program instructions 1100 or data 1110.
  • Program instructions 1100 may be executable by a processor (e.g., one or more of processors lOlOa- ⁇ ) to implement one or more embodiments of the present techniques.
  • Instructions 1100 may include modules of computer program instructions for implementing one or more techniques described herein with regard to various processing modules.
  • Program instructions may include a computer program (which in certain forms is known as a program, software, software application, script, or code).
  • a computer program may be written in a programming language, including compiled or interpreted languages, or declarative or procedural languages.
  • the entire set of instructions may be stored concurrently on the media, or in some cases, different parts of the instructions may be stored on the same media at different times, e.g., a copy may be created by writing program code to a first-in-first-out buffer in a network interface, where some of the instructions are pushed out of the buffer before other portions of the instructions are written to the buffer, with all of the instructions residing in memory on the buffer, just not all at the same time.
  • I/O interface 1050 may be configured to coordinate I/O traffic between processors lOlOa- ⁇ , system memory 1020, network interface 1040, I/O devices 1060, and/or other peripheral devices. I/O interface 1050 may perform protocol, timing, or other data
  • I/O interface 1050 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard.
  • PCI Peripheral Component Interconnect
  • USB Universal Serial Bus
  • computer system 1000 may include or be a combination of a cloud-computing system, a data center, a server rack, a server, a virtual server, a desktop computer, a laptop computer, a tablet computer, a server device, a client device, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a vehicle-mounted computer, or a Global Positioning System (GPS), or the like.
  • Computer system 1000 may also be connected to other devices that are not illustrated, or may operate as a stand-alone system.
  • the functionality provided by the illustrated components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments, the functionality of some of the illustrated components may not be provided or other additional functionality may be available.
  • instructions stored on a computer-accessible medium separate from computer system 1000 may be transmitted to computer system 1000 via transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network or a wireless link.
  • Various embodiments may further include receiving, sending, or storing instructions or data implemented in accordance with the foregoing description upon a computer-accessible medium. Accordingly, the present invention may be practiced with other computer system configurations.
  • illustrated components are depicted as discrete functional blocks, but embodiments are not limited to systems in which the functionality described herein is organized as illustrated.
  • the functionality provided by each of the components may be provided by software or hardware modules that are differently organized than is presently depicted, for example such software or hardware may be intermingled, conjoined, replicated, broken up, distributed (e.g. within a data center or geographically), or otherwise differently organized.
  • the functionality described herein may be provided by one or more processors of one or more computers executing code stored on a tangible, non-transitory, machine readable medium.
  • third party content delivery networks may host some or all of the information conveyed over networks, in which case, to the extent information (e.g., content) is said to be supplied or otherwise provided, the information may provided by sending instructions to retrieve that information from a content delivery network.
  • information e.g., content
  • Statements in which a plurality of attributes or functions are mapped to a plurality of objects encompasses both all such attributes or functions being mapped to all such objects and subsets of the attributes or functions being mapped to subsets of the attributes or functions (e.g., both all processors each performing steps A-D, and a case in which processor 1 performs step A, processor 2 performs step B and part of step C, and processor 3 performs part of step C and step D), unless otherwise indicated.
  • statements that one value or action is "based on" another condition or value encompass both instances in which the condition or value is the sole factor and instances in which the condition or value is one factor among a plurality of factors.
  • statements that "each" instance of some collection have some property should not be read to exclude cases where some otherwise identical or similar members of a larger collection do not have the property, i.e., each does not necessarily mean each and every.
  • a method comprising: obtaining, with one or more computers, a repository of stored value card records, each record corresponding to a stored value card, and each record including an identifier of a merchant accepting the respective stored value card and a balance of value remaining on the respective stored value card, each stored value card having at least one previous user possessor; receiving, with one or more computers, a request for a stored value card from a remote client computing device; inferring, with one or more computers, based on the request, a transaction balance of a transaction in which the requested stored value card is to be used;
  • the repository stores records of more than 10,000 stored value cards, subsets of which being accepted by more than 10 merchants geographically distributed over a country; the stored value cards include gift cards that were transferred from an earlier possessor to a gift card exchange; some of the stored value cards have balance-access information accessed by more than two previous user possessors; more than 10 requests for stored value cards are received per minute from user devices among more than 500,000 user computing devices requesting stored value cards over a one year duration; and sending the balance-access information is performed within ten seconds of receiving the request for the stored value card;
  • inferring a transaction balance comprises: inferring a transaction balance based on previous transactions with the inferred merchant.
  • inferring a transaction balance comprises inferring a transaction balance based on: previous transactions by a user requesting the stored value card; and previous transactions with the inferred merchant.
  • inferring a merchant comprises: obtaining a geolocation of a mobile computing device associated with the request; and ascertaining the merchant based on the geolocation.
  • inferring a merchant comprises performing steps for inferring the merchant.
  • selecting one or more stored value cards comprises: selecting a stored value card among the subset in response to determining that the selected stored value card has a balance closest to a threshold balance based on the inferred transaction balance among the identified subset of stored value cards.
  • selecting one or more stored value cards comprises: selecting plurality of stored value card among the subset in response to determining that a cumulative balance of the selected plurality of stored value cards have a balance closest to a threshold balance based on the inferred transaction balance.
  • selecting one or more stored value cards comprises: determining balances associated with more than 500 candidate responses, each of the candidate responses being associated with one or more of the identified subset of the stored value cards, some of the candidate responses being associated with two of the identified subset of the stored value cards, each of the candidate responses having a cumulative balance associated with the respective stored value card or cards associated therewith; and selecting among the candidate responses based on differences between the inferred transaction balance and the balances of the candidate responses.
  • selecting among the candidate responses based on differences between the inferred transaction balance and the balances of the candidate responses comprises: selecting among the candidate responses based on an amount of previous possessors of balance-access information of at least some of the stored value cards associated with the respective candidate responses.
  • candidate responses comprise: each combination of two stored value cards among the identified subset of stored value cards.
  • candidate responses comprise: each permutation of two stored value cards among the identified subset of stored value cards.
  • the candidate responses comprise: each combination of four stored value cards among the identified subset of stored value cards, and wherein the identified subset of stored value cards comprise more than 1,000 stored value cards, and wherein balance-access information is sent within ten seconds of receiving the request.
  • selecting one or more stored value cards comprises performing steps for selecting one or more stored value cards based on the transaction balance amount.
  • a system comprising: one or more processors; and memory storing instructions that when executed by the processors cause the processors to effectuate operations comprising the operations of any of embodiments 1-19.
  • a tangible, non-transitory machine-readable media storing instructions that when executed by one or more processors effectuate operations comprising the operations of any of

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

La présente invention concerne un procédé consistant en : l'obtention d'un référentiel d'enregistrements de cartes de valeurs stockées ; la réception d'une requête pour une carte de valeur stockée à partir d'un dispositif informatique client distant ; la déduction sur la base de la requête, d'un solde de transaction d'une transaction dans laquelle la carte de valeur stockée demandée doit être utilisée ; la déduction, sur la base de la requête, d'un commerçant devant participer à la transaction ; l'identification d'un sous-ensemble des enregistrements de la carte de valeur stockée en réponse ; la sélection d'une ou plusieurs cartes de valeur stockées parmi le sous-ensemble identifié sur la base d'une comparaison entre le solde de transaction déduit et la valeur restant sur la ou les cartes de valeur stockées sélectionnées ; et l'envoi des informations d'accès au solde au moyen desquelles le ou les soldes d'une ou de cartes de valeur stockées sélectionnées peuvent être dépensés au niveau d'un terminal de point de vente.
PCT/US2017/041319 2016-07-12 2017-07-10 Approximation à faible latence d'optimisation combinée de quantités résiduelles lors de l'attribution de grandes collections de cartes de valeur stockées WO2018013458A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/208,128 US20160321666A1 (en) 2014-08-28 2016-07-12 Low-latency approximation of combinatorial optimization of residual amounts when allocating large collections of stored value cards
US15/208,128 2016-07-12

Publications (1)

Publication Number Publication Date
WO2018013458A1 true WO2018013458A1 (fr) 2018-01-18

Family

ID=60953330

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/041319 WO2018013458A1 (fr) 2016-07-12 2017-07-10 Approximation à faible latence d'optimisation combinée de quantités résiduelles lors de l'attribution de grandes collections de cartes de valeur stockées

Country Status (1)

Country Link
WO (1) WO2018013458A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108834160A (zh) * 2018-06-01 2018-11-16 中国联合网络通信集团有限公司 用户身份识别卡使用情况的确定方法与网络设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015331A1 (en) * 2001-11-27 2005-01-20 Takanobu Kunugi Prepaid card information issuing system, call rate settlement system, communication rate settlement system, and expense settlement system
US20130254074A1 (en) * 2012-03-22 2013-09-26 Bank Of America Corporation Gift card exchange marketplace
US20140214566A1 (en) * 2013-01-28 2014-07-31 Wal-Mart Stores, Inc. Retail Gift Card System with Integrated Account and Sales Receipt Tracking
US20160042434A1 (en) * 2012-06-12 2016-02-11 Gyft, Inc. Systems and Methods for Digital Gift Card Selection
US9275506B1 (en) * 2006-09-01 2016-03-01 NBC Operating, LP Systems and methods for off-line stored value card transactions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050015331A1 (en) * 2001-11-27 2005-01-20 Takanobu Kunugi Prepaid card information issuing system, call rate settlement system, communication rate settlement system, and expense settlement system
US9275506B1 (en) * 2006-09-01 2016-03-01 NBC Operating, LP Systems and methods for off-line stored value card transactions
US20130254074A1 (en) * 2012-03-22 2013-09-26 Bank Of America Corporation Gift card exchange marketplace
US20160042434A1 (en) * 2012-06-12 2016-02-11 Gyft, Inc. Systems and Methods for Digital Gift Card Selection
US20140214566A1 (en) * 2013-01-28 2014-07-31 Wal-Mart Stores, Inc. Retail Gift Card System with Integrated Account and Sales Receipt Tracking

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108834160A (zh) * 2018-06-01 2018-11-16 中国联合网络通信集团有限公司 用户身份识别卡使用情况的确定方法与网络设备
CN108834160B (zh) * 2018-06-01 2021-08-10 中国联合网络通信集团有限公司 用户身份识别卡使用情况的确定方法与网络设备

Similar Documents

Publication Publication Date Title
US11195165B2 (en) Modulating mobile-device displays based on ambient signals to reduce the likelihood of fraud
US10872330B2 (en) Enhancing probabilistic signals indicative of unauthorized access to stored value cards by routing the cards to geographically distinct users
US20210125181A1 (en) Low-latency approximation of combinatorial optimization of residual amounts when allocating large collections of stored value cards
US11935016B2 (en) Interactive gratuity platform
US12124545B2 (en) Communication network based non-fungible token creation platform with integrated creator biometric authentication
CN112236793B (zh) 用于进行涉及货到付款的支付交易的系统、方法和计算机程序产品
CN107111591B (zh) 在设备之间传送认证的会话和状态
US9898737B2 (en) Methods and systems employing time and/or location data for use in transactions
US20150170148A1 (en) Real-time transaction validity verification using behavioral and transactional metadata
US20130046692A1 (en) Fraud protection with user location verification
US20210337389A1 (en) System and method for correlating diverse location data for data security
US11893615B2 (en) Spot market: location aware commerce for an event
WO2017205032A1 (fr) Procédé d'utilisation de la bioinformatique et de la proximité géographique pour authentifier un utilisateur et une transaction
CN116745790A (zh) Qr码倡议：隐私
WO2019091219A1 (fr) Système et procédé de réalisation d'une identification d'identité d'après une technologie d'identification par radiofréquence
WO2019113328A1 (fr) Système, procédé et produit-programme informatique permettant de déterminer l'alignement des catégories d'un compte
US10607227B2 (en) System, method, and computer program product for detecting potential money laundering activities
EP3295403A1 (fr) Modulation d'affichages de dispositif mobile basée sur des signaux ambiants et destinée à réduire les risques d'escroquerie
CN109863523A (zh) 信息处理装置、信息处理系统、信息处理方法和程序
WO2022040499A1 (fr) Système et procédé de traitement de coupons numériques
WO2018013458A1 (fr) Approximation à faible latence d'optimisation combinée de quantités résiduelles lors de l'attribution de grandes collections de cartes de valeur stockées
WO2018013456A2 (fr) Amélioration de signaux probabilistes indiquant un accès non autorisé à des cartes de valeur stockées en acheminant les cartes vers des utilisateurs géographiquement distincts
US20210049619A1 (en) System, Method, and Computer Program Product for Determining a Dormancy Classification of an Account Using Deep Learning Model Architecture
KR102515736B1 (ko) 오프라인 결제 처리 시스템, 픽처 터치 패턴을 이용한 인증 기반의 오프라인 결제 처리 방법 및 이를 이용한 장치
US20200257666A1 (en) "System, Method, and Computer Program Product for Monitoring and Improving Data Quality"

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17828231

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17828231

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载