1. Field of the Invention
This invention relates to systems and methods for providing and redeeming credits by businesses.
2. Background of the Invention
Business credits, also known as store credits, defined as a balance issued by a business and redeemable for the business's goods and services, are a common tool used by businesses to reward customer loyalty, to compensate a product return, to allow a customer to make a gift to another person, and to provide discounts for bulk purchases paid in advance. In the past, such credits may have been issued in the form of a paper certificate or card but are increasingly provided in pure electronic form as an account accessible online via a secret code with a balance denominated in the currency of the country where it is issued. Electronic forms of business credits have facilitated the emergence of services that provide aggregated access to store-specific credit account balances in a single mobile application or online service.
Typically a business credits balance is business-specific, where it is issued by a specific business and is only redeemable at the same specific business that issued it. When a business is owned by the same legal entity, the balance of the business credit account may be redeemable at any of the locations of the company.
In some cases, business credits can be redeemed at multiple businesses owned by different legal entities. This is typical of business credit available for purchase from malls or other business coalitions like chambers of commerce. In these cases, the business credits balance is typically not really issued by any of the accepting businesses, but by a third party company called a program operator. The program operator sells its own business credit balances it issued to interested businesses for a fee in addition to the face value of the business credits balance. The face value and/or fee may be collect and deposit by the program operator as bank credits in a FDIC bank account until the business credits balance is redeemed at a store. Upon redemption, the cross-redeemable business credit program operator buys back the collected business credits from the redeeming business and transfers back the amount redeemed in bank credits by bank transfer to the redeeming business. If participating businesses themselves sell the cross-redeemable business credits, amounts sold by a business and owed to the program operator may be netted against business credits collected and purchased by the program operator and owed to the business. In some cases, the third party program operator is a bank and cross-redeemable business credits are essentially restricted-use bank credits and the business credits balance is issued in the form of a bankcard whose redemption is restricted to the participating businesses.
These latter cases, where cross-redeemability of business credits is made possible by a third-party operator selling and buying back its business credits for bank credit, are not advantageous to the participating businesses. Among other reasons, participating businesses do not retain the value of the amount of business credits balance that is never redeemed (termed breakage). Also, when the business credits balance is sold for bank credit, the business does not get the benefit of receiving the bank credit upfront. And, if the business credits balance is issued as a reward, it is an immediate cash cost to the business, rather than a future reduced margin on a future sale in which business credits are used.
The systems and methods described herein provide an improved approach for issuing business credits to customers and redeeming such credits.
In order that the advantages of the invention will be readily understood, a more particular description of the invention briefly described above will be rendered by reference to specific embodiments illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through use of the accompanying drawings, in which:
It will be readily understood that the components of the present invention, as generally described and illustrated in the Figures herein, could be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the embodiments of the invention, as represented in the Figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of certain examples of presently contemplated embodiments in accordance with the invention. The presently described embodiments will be best understood by reference to the drawings, wherein like parts are designated by like numerals throughout.
The invention has been developed in response to the present state of the art and, in particular, in response to the problems and needs in the art that have not yet been fully solved by currently available apparatus and methods. In one embodiment, an approach is provided where one or more businesses issues their own business-specific credits balance to individual parties and then provides the ability to each individual party to deposit all or part of the business-specific credits they hold into a pool alongside several other parties, receive a balance in the pool, and later withdraw any business-specific credits available in the pool, up to their balance in the pool, thereby providing options to redeem their business-specific credits at other businesses than the one who issued them. The deposit to the pool may also be a way for depositors of business-specific credits to spread the risk that a business defaults on their issued business credit, in accordance with the operating rules of the pool.
Furthermore, a system is provided that facilitates the setup and operation of a pool, including for example deposits, withdrawals, real-time view of cross-redeemability options for any party participating in a pool, and enforcement of the operating rules of the pool regarding how loss is extinguished among pool depositors when a business defaults on business credits it issued that were deposited in the pool.
For business parties issuing business credits and selling them for bank credit or cash for instance as prepaid or as gift certificate, one approach provides their business credit holders with cross-redeemability options while giving the issuing business party the benefit of receiving the bank credit or cash at the time the business credits balance is sold rather than at the time the business credits are redeemed. Similarly, for business parties issuing business credits as rewards, one example may provide their business credits holders with cross-redeemability options while avoiding the issuing party a cash outflow at the time the business credits balance is issued, and instead only incurring a reduced margin at the time of redemption of the business credits.
Embodiments in accordance with the present invention may be embodied as an apparatus, method, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “module” or “system.” Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.
Any combination of one or more computer-usable or computer-readable media may be utilized. For example, a computer-readable medium may include one or more of a portable computer diskette, a hard disk, a random access memory (RAM) device, a read-only memory (ROM) device, an erasable programmable read-only memory (EPROM or Flash memory) device, a portable compact disc read-only memory (CDROM), an optical storage device, and a magnetic storage device. In selected embodiments, a computer-readable medium may comprise any non-transitory medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
Embodiments may also be implemented in cloud computing environments. In this description and the following claims, “cloud computing” may be defined as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned via virtualization and released with minimal management effort or service provider interaction and then scaled accordingly. A cloud model can be composed of various characteristics (e.g., on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service), service models (e.g., Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”)), and deployment models (e.g., private cloud, community cloud, public cloud, and hybrid cloud).
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a computer system as a stand-alone software package, on a stand-alone hardware unit, partly on a remote computer spaced some distance from the computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The present invention is described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions or code. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
These computer program instructions may also be stored in a non-transitory computer-readable medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instruction means which implement the function/act specified in the flowchart and/or block diagram block or blocks.
The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
Business credits as defined and processed as described herein may be issued by an online retailer operating a server system 102b for processing online transactions with respect to an online product database 104b. Business credits as defined and processed as described herein may be issued by a retailer operating a server system 102b for recording and/or processing transactions conducted on a point of sale (POS) device 106 operated at a physical store with respect to a product database 104b.
In some embodiments, business credits as defined and processed according to the methods disclosed herein may be combined with credits from a financial institution, i.e. credits from a credit card, checking account, savings account, or the like. Accordingly, a server system 102d of a financial institution and hosting and/or accessing a banking database 104d defining bank account information for a plurality of customers may also interact with the server system 102a.
Customers may view and redeem credits from a computing device 110, 112 such as a laptop or desktop computing device 110 or a mobile computing device 112 such as a smart phone, tablet computer, wearable computer, or some other computing device.
The server systems 102a-102d and computing devices 110, 112 may communicate with one another through a network 114, such as the Internet, a local area network (LAN), wide area network (WAN), or some other network. Communication between devices may be over a wired or wireless connection and may occur using any networking protocol known in the art.
Referring to
One example of such an approach includes:
In some embodiments, an asset balance 216 of a user, which may include asset holdings that are defined according to one of the credit object models 206-212 may be updated and processed by a scheduler 220 that performs tasks defined according to the object models 206-212. An even handler 222 may receive events from businesses or customers that create, modify, or redeem assets 218. The credit models 206-212 may define functions to be executed in response to events received and such tasks may be invoked by the event handler, such as by scheduling execution thereof by the scheduler 220.
The scheduler 220, even handler 222, and/or one or more modules executed or accessed by the server system 102a may implement the purchasing power algorithm, asset holding preference algorithm, asset allocation algorithm, business owner user interface, pool administrator user interface, consumer user interface, and POS user interface as described in points (l) through (p) in the list above and as described in greater detail below.
The asset balance 216 and corresponding assets may be part of an account of an instance party 224, i.e. an instance of the party object model 202 corresponding to a particular customer. Likewise, a mint party 226 may be a party that issues business credits, i.e. a business.
Detailed information for the various object models mentioned are above is provided below. The functionality of the various object models described below may be implemented or enforced by the server system 102a when processing transactions using assets or performing other activities with respect to assets generated by a business or assigned to a consumer.
Each individual person or organization may be represented as a party. The properties of the party object model 202 may include some or all of:
The asset object model 204 represents as contracts the various types of credit redeemable at a business. Instances of the asset object model 204 may be created by business and assigned to a consumer, i.e. the business may instruct the server system 102a to generate an asset object and associate the asset object with the account of the consumer. Some or all assets may share a common set of properties, which may include some or all of:
The business credit object model represents instances of store-specific store credits as a contract between an issuing business party and a holding party specifying the operating rules, also known as terms and conditions, throughout the business credit lifecycle, from authorization, to issuance, to maturity, to redemption or expiration (“business credit object model”).
The business credit object model may extend the asset object model with some or all of the following properties:
The item credit object model 208 may extend the business credit object model 206 with some or all of the following operating rules:
In addition, any instance of the item credit object model has an accounting unit of “each”.
The bank credit object model 210 may extend the base asset object mode 204 with some or all of the following properties:
The pool object model represents instances of pools of credits as a contract between pool participants specifying the credits authorized in the pool as well the operating rules of the pool throughout the pool lifecycle from deposits of credits to withdrawal of credits to handling of defaulting of business credits in the pool.
The pool object model may extend the asset object model with some or all of the following properties:
The asset lifecycle management algorithm may execute the operating rules of an asset in response to relevant lifecycle events referencing the asset, such as events received by the event handler 222. Upon the issuance event of a balance of an asset to a party, the asset lifecycle management algorithm registers with the scheduler 220 the relevant future lifecycle events of the asset. The relevant events may include some or all of:
An asset acceptance rule is a way for a party to specify which asset they accept either for redemption for goods and services or for exchange with another asset. A business always accepts the business credit or item credit it issued up to the amount outstanding that is to say issued but not redeemed, but may accept other assets than the one it issued.
The asset acceptance rule object model is defined as follows:
In case several rules match, the rules are applied to maximize transaction amounts, in decreasing order of preference of the accepted asset to the accepting party.
The purchasing power algorithm computes the maximum amount in the local monetary unit or a given arbitrary unit that a party can redeem at a business given all the assets issued or accepted by the business that it holds directly or can withdraw from the pool(s) it holds receipts for.
The purchase power algorithm computes the maximum amount that a party can redeem at a business as shown in the method 300 of
The method 300 may include adding 308 any business credits denominated in the local monetary unit that the party holds and that the business didn't issue but that the business accepts for goods and services according to the asset acceptance rules specified by the business.
The method 300 may include adding 310 any business credits denominated in the local monetary unit that the business issued or accepts, that the party can withdraw from the pool credits he or she holds. As illustrated in
The method 300 may include adding 312 any business credits denominated in the local monetary unit that can currently be exchanged according to the acceptance rules specified by any party in the system for business credits that the business issued or accepts for goods and services.
In some embodiments, 300 one or more of the terms added according to the method 300 may be adjusted 314, i.e. reduced, by an amount that increases with the difficulty of executing the corresponding transactions.
The buying power as computed may be stored in association with a user account, transmitted for display on the user's device, transmitted to a POS 106 or server system 102b, 102c for verification of the user's ability to pay, or displayed on some other device.
In some embodiments, the asset holding preference algorithm infers the preference of a party to hold a given asset over another, based on the operating rules of each asset held and the preferences of the party holding the assets. For example, the method 400 of
For a given instance party, its asset holding preferences and two or more assets held by the instance party, the method 400 may include determining 402 whether an asset holding preference has been set by the user for the two or more assets, or can be inferred through transitivity from the preference set for other assets. If so, then these assets are ranked 404 according to this preference, i.e. the asset having ranked higher by the user or deemed superior by the user to another assets is ranked higher than the other asset.
If no preference can be determined 402 from the user preferences, and the two assets are of different types, then at step 406 bank credit is ranked higher than pool credit, pool credit is ranked higher than business credit, and business credit is ranked higher than item credit.
If the assets are of the same type, the asset preferred is the one with the highest computed preference according to step 408. Specifically, the method 400 may include performing 408 for each type of asset type (business, item, pool) some or all of steps 410-420 with respect to assets of the instance party of the each asset type. The preference computed at step 408 may be represented by a number that serves as a proxy for a monotonically increasing function of both liquidity and time value. For example, other operating rules may apply, such as a first asset expiring earlier than a second asset will have a lower inferred holding preference (e.g. will have a lower rank and will be used to fund transactions before the second asset). In another example, an asset with dormancy fees will have a lower inferred holding preference than an asset with no dormancy fee or a lower dormancy fee. The preference may be computed by determining 410 a number of past transactions for each asset of the asset type. A typical rate at which past transactions in the asset have occurred during a certain time window may be determined 412, usually skewed towards the recent (e.g. the last month, last two weeks, or some other interval). Other statistics of the set of past transactions in the asset such as average amount, number of redemptions, and average value of redemptions may be determined 414.
For each asset within a given asset type usage of that asset class by other users may also be used to determine its preference. For example, the number of distinct parties participating in past transactions in the asset may be determined 416 as well as determining other statistics of the set of parties participating in past transactions in the asset, such as average number of redemptions per party and average number of distinct businesses redeemed at per party.
If the asset is a pool credit, the method 400 may include determining 420 pool statistics such as: the number of assets in the pool issued by distinct businesses, the number of consumers in the pool. The pool may be embodied as a electronic representation of a contract between multiple consumers to share assets with each other. Among the assets of the pool the typical rate (e.g. average per unit time) at which cross-redemptions have occurred using the pool receipt over a certain time window, usually skewed towards the recent (e.g. the last month, last week, or some other period).
The actual preference value or rank assigned to an asset may be computed according to a weighted function wherein values according to any of the rules or values described above are weighted and summed to determine a score for the asset.
The asset allocation algorithm allocates which amount of which of a buying party's assets to redeem to fund a given transaction at a given business, based on the asset holding preferences of the transacting party. Given the buying party, a selling business party, and a requested amount in the local monetary unit or an arbitrary asset to be transferred from the buying party to the selling party as part of a transaction consisting of arbitrary other transfers, credits may be debited to fund the transaction according to the illustrated method 500 of
The method 500 may include receiving 502 a funding request from a user, such as from computer device 110, 112 or from a point of sale 106 or ecommerce server 102b, the funding request indicating the requested amount. The funding request may be received in a verifiable fashion, e.g. the funding request may include or follow authentication of one or both of the buying and selling parties prior to performing the steps of the method 500.
The method 500 may further include determining 504 which of the assets (in the same accounting unit as the requested amount) held by the individual are accepted by the business and for what amount. This creates a provisional transfer list. For example, if the selling party is a business then bank credits, credits of that business, and pool credits may be usable to fund the transaction. Where the transaction is to purchase an item, then item credits of the business that are associated with that item may also be determined 504 to be acceptable. Whether an asset is acceptable may be determined according to the attributes of the asset, specifically any limitations on its use as defined by the corresponding credit object model of the asset as described above.
The method 500 may include ranking 506 the buying parties assets, such as according to the method 400. Ranking of the user's assets may be performed prior to receiving 502 a funding request, i.e. periodically according to a schedule or upon the modification of the assets held by the user (e.g. exhaustion or an asset, spending of a portion of an asset, or adding of a new asset).
Funds may then be allocated 508 to the transaction according to the ranking, i.e. some or all of an acceptable asset having the lowest rank (i.e. lowest holding preference) will be applied toward the requested amount, some or all of the an acceptable asset having the next lowest rank will be applied toward the requested amount, and so on until the requested amount has been allocated.
Redemption of the allocated funds to pay for the transaction may then be processed 510 to transfer the allocated funds to the selling party and/or notifying the selling party that payment has been authorized. Processing payment from the allocated assets may proceed according to any electronic payment processing approach known in the art.
Various interfaces may be provided on a remote computing device 110, 112 for modifying user account preferences of a business or consumer. For example, the business owner user interface may used to create and edit business credits, item credits, bank credits. The pool administrator user interface to create and edit instances of the asset object model
The consumer user interface allows a party holding assets to some or all of view the balance available to them in each asset, to view their purchasing power at each store based on all the assets she or he holds, join one or more pools and deposit store-specific in them, set her or his asset holding preferences, view how its various assets would be allocated to fund a particular redemption transaction, and initiate a redemption transaction at a given business. The point-of-sale user interface allows a business employee to view the purchasing power of a party at the business based on all the assets the party holds, and initiate a redemption transaction of the party's asset at the business.
The interfaces described below may be populated by information from the asset database 104a by the server system 102a and displayed on a user device 110, 112. Inputs may be transmitted to the server system 102a which may update the asset database 104a or take other actions described below as being invoked by the database. Alternatively, some or all of the actions taken in response to user inputs may be performed on the user device 110, 112.
The information displayed in the interfaces of
The information displayed in the interfaces of
The information displayed in the interfaces of
The information displayed in the interfaces of
The information displayed in the interface of
The information displayed in the interfaces of
As shown in
The information displayed in the interfaces of
The method 1800 may include receiving 1802 user pooling preferences or instructions. For example, step 1802 may include receiving an instruction to add some or all of an asset to a selected pool or receiving a rule specifying that, for example, the largest amount transferable to a pool of an asset shall be added to the pool as soon as permitted by the asset (e.g. upon full or partial maturity of the asset).
The method 1500 may further include evaluating 1802 pooling limitations. For example, as shown in
At step 1804 some or all of the amounts of the assets specified according to the received rule or instruction at step 1804 are added to the pool insofar as they are compliant with the rules evaluated at step 1802. For example, where the amounts specified by the user exceed a maximum amount defined for pooling of an asset, the maximum amount may be added. Where the amount specified by the user is below a minimum amount defined for an asset, the request to add the amount to the pool maybe ignored.
The method 1800 may further include receiving 1808 funding requests from a user or business, debiting 1810 the pool to fund the request, and transmitting 1812 notification of funding to the user or business. In particular, steps 1808-1812 may be performed as described above with respect to
Credits issued and processed as disclosed herein may be generated as part of a system in which business credits are issued as rewards for purchases and automatically placed into a pool when issued by a business that is a member of a group such as a neighborhood merchant association, industry association, local chapter of an industry association, or chamber of commerce, thereby providing cross-redemption options for holders of the pool credits.
Credits issued and processed as disclosed herein may be generated as part of a system in which customers exchange money in their bank accounts (bank credits) for the same amount in business-specific credits and get additional business-specific credits that are automatically placed into a pool when issued by a business that is a member of a group such as a neighborhood merchant association, industry association, local chapter of an industry association, or chamber of commerce, thereby providing cross-redemption options for holders of the pool credits.
Credits issued and processed as disclosed herein may be generated as part of a system in which an employer exchanges money in its bank account (bank credits) for the same amount in business-specific credits from several different businesses, then places these business-specific credits into an employee pool, and then distributes the pool credits to its employees, thereby providing its employees with a benefit at the businesses.
Credits issued and processed as disclosed herein may be generated as part of a system in which a business issues to a supplier business-specific credits in payment for goods received and/or services performed, then the supplier places these business-specific credits into the pool of its choice, thereby allowing the supplier to redeem these credits at businesses other than the one that it received them from.
The end-user device 1902, specifically the application 1904, may interact with the server system 102a to implement methods as described herein. For example, the application 1904 may retrieve 1906 from the server system 102a balances for one or more brand-specific credits and request codes, e.g. coupon codes, for redeeming brand-specific accounts.
The accounts of multiple users and the brand-specific credits assigned to each user may be stored in the asset database 104a. The brand-specific credits may be processed according to any of the methods disclosed herein, i.e. the brand-specific credits may be an instance of a business credit object model or any of the asset object models described herein and may be processed or have attributes according to any of the methods described herein.
The server system 102a may facilitate navigation of a product database of one or more retailers. Accordingly, a server system 102b, 102c of a retailer may transmit 1908 product information to the server system 102a for viewing in the application 1904. Alternatively, such information may be transmitted directly to the application 1904 by the server system 102b, 102c. The server systems 102b, 102c may further transmit credits assigned to users to the server system 102a for storage in the accounts of users. For example, a retailer may assign a credit for Brand A to customer A. The brand-specific credit may be specific to the retailer's brand, i.e. redeemable for products sold by the retailer. Alternatively, the brand-specific credit may be for a brand of products that the retailer may or may not carry. Assignment of brand-specific credits may also be received by the server system 102a from an entity other than a retailer, such as a manufacture of the brand corresponding to the brand-specific credits or any other entity. An assignment of a brand-specific credit may indicate the brand and an amount. An assignment of a brand-specific credit may include some or all of the limitations or parameters governing the processing of an asset of any of the asset types described herein.
A coupon code transmitted to the application 1904 may be displayed on a display device of the end-user device 1902 or printed onto paper or any other physical media. The coupon code may indicate an amount authorized by the coupon and may indicate other information such as a brand or product that can be purchased using the amount authorized. A POS device 106 may scan 1910 the code in order to receive information encoded in the coupon and apply funds authorized by the coupon toward a transaction conducted on the POS 106.
The methods described herein may use the illustrated environment 1900 to enable an end-user holding a balance of brand-specific credits to pay at a general retail store distributing products produced by the brand for products of that brand only.
A balance of brand-specific credits, such as a brand-issued gift card is generally only redeemable at a location of the brand who issued the credits. In some cases, the brand-specific credits can be redeemed at a business other than the brand who issued the credits, but the process requires exchanging the brand-specific credits for credits that the other business accepts, typically bank-issued credits, and does not provide a way to constrain the redemption of brand-specific products to products of that brand only distributed at the other business. Brands also typically issue vendor coupons, which can be redeemed for brand-only products at a general retail store, but these coupons are for a specific amount (e.g. $1 off) or specific portion of the product price (e.g. 10% off). These coupons cannot be used for redeeming an arbitrary portion of a brand-specific credits balance issued to a brand's customer.
The systems and methods disclosed herein provide the ability for an end-user holding a balance of brand-specific credits to redeem these credits for products produced of that brand only at a general retail store who distributes products of that brand. An end user may invoke redemption of brand-specific credits on an application 1904 on the end-user device 1902 part or all of the brand-specific credits balance held by the end-user for one or more special free item coupons for each product of that brand that the end-user wants to pay with brand-specific credits. Each free item coupon obtained is scanned by the retail store cashier at checkout and the POS 106 applies a credit to the total corresponding to the price of the product at the retail store. The redemption further includes deducting by the server system 102a from the end-user brand-specific credits balance the price at the retail store of each product purchased by the end-user. This ensures that the end-user cannot redeem more products of the brand at the retail store than allowed by his/her bran-specific credits balance. Each free item coupon is product-specific, ensuring that the brand-specific credits can only be used for products of that brand at the retail store.
A free item coupon may be embodied as a UPC A, or some other code, that is generated from the product UPC by taking the 5-digit manufacturer ID and 3-digit family code from the UPC of the product and concatenating them into a new UPC as follows: “5” (coupon), 5-digit manufacturer ID, 3-digit family code, “01” value code (free item), and the standard computed check digit. Most point-of-sale in the world can interpret such a UPC coupon code and will automatically apply a credit to the total due corresponding to the full price of the item, as long as a product with a matching 5-digit manufacturer ID and 3-digit family code has been scanned by the point-of-sale system.
In some embodiments, the application 1904 on the end-user device has access to the price at the retail store of all products of the brand distributed by the retail store, but the some embodiments allow for price incorrectness by involving the cashier at the retail store in the redemption process. For example, before obtaining free item coupon codes, the end-user is prompted by the application 1904 on the end-user device to ask the cashier to verify the price of each product paid with brand-specific credits. If there is a price difference, the cashier asks the end-user to correct the price to match the price provided by the POS system. This process ensures that the correct amount of credits is debited from the end-user brand-specific balance. In some embodiments, coupons may be designed to work with any retail point-of-sale system, which supports UPC coupon codes. The system may function without the cashier having to touch the end-user device at any point in the redemption process.
The end-user device 1902 may be a mobile device with mobile Internet access and geolocation capability. The end-user application software 1904 retrieves brand-specific credit balances from the server system 102a and displays them to the user on the end-user device 1902. A selection of one of these assets may be received 2004. The server system 102a retrieves product information from the brand's product information database (e.g. a database 104b, 104c, or some other database), in particular their price at the retail stores where the brand's products are distributed. This information is presented on the end-user device 1902 in response to navigation 2006 of the product directory by the user to find a desired product. A selection of a product may then be received 2010 on the end-user device 1902 and redemption requested. Notification of the selection and desire to redeem some or all of the selected asset may be transmitted to the server system 102a.
Upon receiving a request for redemption from the application 1904 responsive to a user instruction, the server system 102a uses the price information of each product paid with brand-specific credits to debit 2010 the end-user brand-specific credits balance(s) of the corresponding amount and transmits 2012 a free item coupons to the end-user application 1904 for display on the display device of the end-user device 1902. This code may then be scanned 2014 by a POS 106. The POS may validate 2016 the code, either by evaluating the content of the code itself to verify that it is authentic or verifying with the server system 102a that the code, or some data extracted therefrom, is valid and authorizes application of the purchase price toward the purchase of the selected product. The POS 106 may then use the coupon code to fund 2018 the transaction. Funding 2018 the transaction may, for example, include processing the electronic transfer of funds from an account of a payee to the account of the retailer operating the POs 106. The payee may be the operator of the server system 102a or the assigner of the brand-specific credit being redeemed.
The systems and methods disclosed herein advantageously provide for redeeming a balance of brand-specific credits that have been issued to an end-user as a reward for past purchases of that brand, to be redeemed at one or more retail stores for products of that brand only. The systems and methods disclosed herein advantageously enable redeeming a balance of brand-specific credits that have been issued to an end-user to incentivize the purchase of any or specific products of the brand at one or more retails stores.
The systems and methods disclosed herein advantageously enable redeeming a balance of brand-specific credits that have been issued to an end-user in exchange for cash upfront, typically in excess of the cash amount received (say $110 brand-specific credits for $100 cash), to be redeemed for products of that brand only at one or more retail stores.
The systems and methods disclosed herein advantageously enable redeeming of a balance of brand or product-specific credits that have been issued to an employee by its employer, or to a public welfare recipient by a public organization to redeem for any or specific products of that brand at one or more retail stores.
The systems and methods disclosed herein advantageously enable redeeming of a balance of product-specific or product family-specific credits issued by a brand to be redeemed for one or more specific products, or products from one or more families of products of that brand at one or more retail stores.
Computing device 2800 includes one or more processor(s) 2802, one or more memory device(s) 2804, one or more interface(s) 2806, one or more mass storage device(s) 2808, one or more Input/Output (I/O) device(s) 2810, and a display device 2830 all of which are coupled to a bus 2812. Processor(s) 2802 include one or more processors or controllers that execute instructions stored in memory device(s) 2804 and/or mass storage device(s) 2808. Processor(s) 2802 may also include various types of computer-readable media, such as cache memory.
Memory device(s) 2804 include various computer-readable media, such as volatile memory (e.g., random access memory (RAM) 2814) and/or nonvolatile memory (e.g., read-only memory (ROM) 2816). Memory device(s) 2804 may also include rewritable ROM, such as Flash memory.
Mass storage device(s) 2808 include various computer readable media, such as magnetic tapes, magnetic disks, optical disks, solid-state memory (e.g., Flash memory), and so forth. As shown in
I/O device(s) 2810 include various devices that allow data and/or other information to be input to or retrieved from computing device 2800. Example I/O device(s) 2810 include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.
Display device 2830 includes any type of device capable of displaying information to one or more users of computing device 2800. Examples of display device 2830 include a monitor, display terminal, video projection device, and the like.
Interface(s) 2806 include various interfaces that allow computing device 2800 to interact with other systems, devices, or computing environments. Example interface(s) 2806 include any number of different network interfaces 2820, such as interfaces to local area networks (LANs), wide area networks (WANs), wireless networks, and the Internet. Other interface(s) include user interface 2818 and peripheral device interface 2822. The interface(s) 2806 may also include one or more user interface elements 2818. The interface(s) 2806 may also include one or more peripheral interfaces such as interfaces for printers, pointing devices (mice, track pad, etc.), keyboards, and the like.
Bus 2812 allows processor(s) 2802, memory device(s) 2804, interface(s) 2806, mass storage device(s) 2808, and I/O device(s) 2810 to communicate with one another, as well as other devices or components coupled to bus 2812. Bus 2812 represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.
For purposes of illustration, programs and other executable program components are shown herein as discrete blocks, although it is understood that such programs and components may reside at various times in different storage components of computing device 2800, and are executed by processor(s) 2802. Alternatively, the systems and procedures described herein can be implemented in hardware, or a combination of hardware, software, and/or firmware. For example, one or more application specific integrated circuits (ASICs) can be programmed to carry out one or more of the systems and procedures described herein.
Reference throughout this specification to “one embodiment,” “an embodiment,” “one example,” or “an example” means that a particular feature, structure, or characteristic described in connection with the embodiment or example is included in at least one embodiment of the present disclosure. Thus, appearances of the phrases “in one embodiment,” “in an embodiment,” “one example,” or “an example” in various places throughout this specification are not necessarily all referring to the same embodiment or example. Furthermore, the particular features, structures, or characteristics may be combined in any suitable combinations and/or sub-combinations in one or more embodiments or examples. In addition, it should be appreciated that the figures provided herewith are for explanation purposes to persons ordinarily skilled in the art and that the drawings are not necessarily drawn to scale.
The present disclosure is directed to methods, systems, and computer programs for using business credits. In this description, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the concepts disclosed herein, and it is to be understood that modifications to the various disclosed embodiments may be made, and other embodiments may be utilized, without departing from the spirit and scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative, and not restrictive. The scope of the invention is, therefore, indicated by the appended claims, rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.
This application claims the priority benefit of U.S. Provisional Application Ser. No. 61/863,290, entitled “Pooling Business Credits to Provide Cross-Redemption Options of Business-Specific Credits”, filed Aug. 7, 2013, the disclosure of which is incorporated by reference herein in its entirety. This application also claims the priority benefit of U.S. Provisional Application Ser. No. 61/929,898, entitled “System and Method for Redeeming a Balance of Brand-Specific Credits at a General Retail Store”, filed Jan. 21, 2014, the disclosure of which is incorporated by reference herein in its entirety
Number | Date | Country | |
---|---|---|---|
61863290 | Aug 2013 | US | |
61929898 | Jan 2014 | US |