Method for optically decoding a debit or credit card
A method for collecting and transmitting information desired for a commercial transaction from a debit or credit card uses a processor configured with optical character recognition (OCR) capability. At least one optical image of the debit or credit card is collected by the processor. The edges of the card are algorithmically defined from the collected image. Predefined offsets are applied to the algorithmically defined edges of the debit or credit card to algorithmically locate an area in the collected image having the desired transactional data. The transactional data within the located area is encoded and transmitted for further processing of the commercial transaction.
Latest Scientific Games International, Inc. Patents:
- Smart bin lottery ticket dispenser with integrated controller
- Method and system for lottery game play transactions via a kiosk and a player's mobile smart device
- Smart bin lottery ticket dispenser with modular printer bin
- Smart bin lottery ticket dispenser with remote electronic display
- Lottery game system and method with augmented reality scratch-off lottery ticket
The present application claims priority to U.S. Provisional Application Ser. No. 61/596,385, filed Feb. 8, 2012.FIELD OF THE DESCRIBED METHODS
The present subject matter relates to methods and systems for performing all logistical functionality (e.g., activation, sales, validation, etc.) of lottery and contest type tickets (e.g., instant lottery tickets, on-line lottery tickets, promotional materials, etc.) using existing infrastructures without the need for additional lottery or game specific hardware installed at a retailer's location. Additionally, the use of the aforementioned infrastructures also enables street vendors to readily: activate, sell, and validate lottery tickets, and to pay applicable prizes of lottery games. The proposed methodologies and systems enable the sale/processing of lottery and contest tickets, as well as interchange of other data (e.g., check clearing, authentication, etc.) between the retailer to a central processing hub without the added expense and inconvenience of installing custom hardware. Finally, a method is disclosed to use off-the-shelf hardware to optically scan debit or credit cards in a secure fashion.BACKGROUND AND SUMMARY OF THE INVENTION
Lottery games have become a time-honored method of raising revenue for state and federal governments the world over. Traditional scratch-off and on-line games have evolved over decades, supplying increasing revenue year after year. However, after decades of growth, the sales curves associated with traditional games seem to be flattening out with the existing retailer base appearing to plateau. Consequently, both lotteries and their service providers are presently searching for new sales venues.
One of the most promising genera of new lottery retailers are “big box” retailers (e.g., Walmart, Target, etc.) and drug store retailers (e.g., Rite Aid, CVS, etc.). However, attempts by lotteries and their service providers to recruit these new retailers have not succeeded. The main reasons for the lack of success is that lottery products are too labor intensive and require special equipment. Additionally, aside from the added cost of the special equipment, its placement may require big box and drug store retailers to have a separate lottery sales/redemption location possibly requiring extra staff. Additionally, in some venues it is desirable to use street vendors to sell lottery tickets that have not been able to use conventional lottery equipment and systems to provide the needed security for specialized lottery products.
To date, there have been numerous attempts to resolve this barrier to sales in big box and drug stores with special in-lane hardware (e.g., Herndon et. al. US2009/0163263, etc.) as well as special monitor interfaces to existing Point Of Sale (POS) systems (e.g., Behm et. al. U.S. Pat. No. 6,899,621), however all of these systems have required the addition of special scanning or dispensing hardware that consequently incur significant costs.
Recently, the popularity of prepaid gift and debit cards (referred to generically herein as “gift debit cards”) sold at big box and drug store retailers has resulted in the implementation of barcode reading activation systems tightly integrated with the stores' POS (Point Of Sale) systems. Indeed, the $20 billion projected sales of open loop gift debit cards for 201 have resulted in the vast majority of big box and drug stores integrating gift/debit card activation systems into their POS systems. This mass adoption of gift debit card activation systems allows for other products with barcodes and data conforming to the same specifications as the gift card items to be activated, tracked, or validated without the need to add any additional hardware at the retailer location. Additionally, since gift/debit card activation systems are already integrated into the stores' POS systems, there is no need to have a separate location or additional staff to handle any additional products piggybacking on the gift debit card activation system.
This preponderance of existing gift debit card activation systems at big box and drug store POS systems creates the perfect foundation for lottery and contest systems to utilize the existing card activation network to pass lottery/contest data between the retailer POS and a central site database. By complying with the format of the gift card activation system, blobs of lottery or contest data can be interchanged between the retailer's POS and a central hub allowing transactions (e.g., instant sales, instant validation, instant inventory, quick pick bets, Power Ball validations, etc.) to be conducted without any custom hardware.
Of course, the above data blob exchange utilizing the existing gift card system can be applied to transactions other than lotteries and contests. In such an embodiment, the non-gift-card transactional data would also be encapsulated into a gift card activation network interchange. For example, driver's license data can be encapsulated into a gift card activation barcode format enabling it to be scanned and compared against a central database for authentication beyond a visual inspection of the license.
The concept of no or little customized hardware at the POS location can be extended to a portable retailer or street vendor. In this embodiment, off-the-shelf smart telephones can be incorporated as barcode scanners and the retailer interface, with a portable printer providing the necessary receipts and tickets. Indeed, with portable retailers or street vendors, the gift card network can be used to activate traditional plastic open loop debit cards that can be loaded with lottery or contest prize winnings at the time a winning ticket is presented to the street vendor. With this embodiment, the street vendor or portable retailer is no longer required to carry sufficient cash to pay winners, thereby helping to protect the vendor from theft and violent crime. Additionally, the smart telephone camera can be used to process an image of a debit or credit card with built-in Optical Character Recognition (OCR) allowing the street vendor to perform sales without accepting cash.
Therefore, it is desirable to develop methodologies for performing lottery and other transactions at the retailer POS requiring no special hardware.
Described herein are a number of mechanisms illustrating the practical advantages of as well as the details of reliably utilizing existing interchanges to eliminate the logistical need for any custom hardware at a retailer POS. The disclosed mechanisms thereby offering substantial savings (in eliminating hardware costs and maintenance) while at the same time reducing the clutter on retailer's counters as well as simplifying the retailer interface.
There are multiplicities of existing networks that can be utilized to exchange data without the logistical challenges of installing custom hardware.
The issuing processor 125 of the debit or credit card account number 106 then queries the cardholder's bank 130 to determine if sufficient funds are available to cover the purchase. Assuming the funds are available, the issuing processor 125 then sends the approval notice back through the interchange 120 garnering a fee. This approval is then routed back through the acquiring processor 110 to the merchant 105 who delivers the goods. The actual funds are then electronically transferred from the cardholder's bank 130 to the merchant's bank 115 as a separate process with the consumer cardholder 100 ultimately receiving a statement that the transfer occurred.
This same interchange network of
In some merchant system's the scanning of the UPC barcode 151 assigned to a gift card package 150 (
As illustrated in
In all of the above debit or credit card transaction or gift card activation transactions, the data is transferred from the acquiring processor 110 (
Thus, for a normal debit or credit card transaction or gift card activation, there is a minimum of four to seven entities involved each garnering fees. As will now be shown, this same interchange network can be used to integrate seamlessly into a lottery or contest system without the need of additional specialized hardware and its associated logistical costs. The main component being assigning a unique BIN to a lottery or contest system.
In one embodiment, assigning and printing a unique lottery BIN in the barcode on instant lottery tickets supplies all of the information necessary to route the instant ticket inventory control data through the debit or credit interchange. This data routing will automatically occur because the debit or credit interchange only uses the BIN to direct data through the interchange, with the remaining data in a debit or credit card number not processed by the interchange itself. (Strictly speaking, the above statement is not entirely correct; there can be a check digit embedded in the remainder of the debit or credit card data that ensures the integrity of the data being transmitted, however tis same check digit format can be calculated and embedded in other non-credit/debit card data.) Any data transmitted with the BIN is simply carried as a ‘data blob’ 182 (
Of course, as is obvious to anyone skilled in the art, this same technique of leveraging the interchange network and assigning unique BINs can be used for other types of data transfer (e.g., consumer authentication, check cashing, etc.) requiring information to be exchanged between the merchant's POS system and a central data processing hub.
Applying the interchange network of
In this embodiment, processing the sale of instant lottery tickets 155 is accomplished by the lottery prearranging to have a special data interface 161 between the lottery's central site 160 and the issuing processor's 125 servers. The exact nature of this interface 161 can vary so long as sufficient techniques are employed for the link to remain secure to data manipulation or monitoring: However, in the preferred embodiment a Virtual Private Network (VPN) would be employed to ensure that the interface 161 was authenticated and encrypted, with its unique Internet Protocol (IP) addresses secured from monitoring. Regardless of the low level details of the interface 161, the data exchanged for an instant lottery ticket sale (i.e., embedded in the data blob 182 (
Alternatively, the merchant could be provided with a special application on a computer or mobile device that query the lottery central site 160 via communications channels (e.g., the Internet) alternative to the interchange. The significant point being that inventory reporting and control are enabled by the lottery's central site 160 logging every instant ticket sale.
Inventory control of instant lottery tickets has been a particularly vexing problem in the past, with the primary solution to date being to install one form or another of vending devices at the merchant's establishment, thereby keeping the instant ticket inventory under lock and key with an automated device tabulating how many tickets were sold. The disadvantages of this approach being the high cost of vending hardware as well as the logistical problems associated with installing and maintaining the vending hardware, in addition to the physical space the vending hardware consumes. Alternatively, a barcode reader interfaced to a lottery terminal already installed at the retailer has also been attempted for instant ticket inventory control. However, this alternative had the disadvantages of requiring the retailer to interface with two devices (i.e., POS equipment and the lottery terminal) as well as the extra cost associated with requiring custom hardware to be installed at the retailer's place of business.
Aside from eliminating the need for special vending hardware, utilizing the debit or credit interchange allows the merchant 105 (
The last point is significant. Traditionally instant tickets are typically shipped in packs of twenty to one hundred with the pack itself being the unit of activation. This gross quantization of activation has caused numerous problems throughout the history of the lottery industry. For example, individual instant tickets stolen from an activated pack can be validated on a lottery system so long as the pack is not reported stolen. Conversely, when a partial pack is reported stolen the problem of estimating, which tickets in the stolen pack were legitimately sold and which were stolen remains. Additionally, pack rather than ticket activation forces lotteries to rely on winning ticket validations to estimate sales to consumers—i.e., a crude metric at best with typically only 1 out of 5 tickets winning. Furthermore, the pack activation model can allow a significant amount of free retailer financial float, since the retailer can sometimes begin selling from a pack of instant tickets and not have to reconcile until 90 days after activation.
All of these pack activation problems are solved with the lottery central site 160 (
The same piggyback via BIN mechanism that enables instant ticket sales can also be utilized for validation of winning instant tickets. In this context, the term validation means authenticating a perceived winning ticket by interfacing with the lottery central site. Not surprisingly, the piggybacking on the interchange configuration for instant ticket validation is essentially the same as instant ticket sales (
In the preferred embodiment, processing an instant ticket validation begins with the lottery instant ticket consumer 100′ presenting a perceived winning instant ticket 155 to the merchant 105 for prize payment. The merchant scans the barcode that was hidden under the unplayed ticket's Scratch-Off-Coating (SOC). As previously discussed, the merchant may have to first scan the instant ticket's UPC barcode to place his or her POS equipment into a special state to process the proxy barcode. This barcode configured to be compatible with the proxy data normally passed over the debit or credit interchange 120 with the lottery BIN 191 (
In another embodiment, the lottery instant ticket consumer 100′ presents a perceived winning instant ticket 155 to the merchant 105 for prize payment. However, in this embodiment, the validation barcode previously under the SOC is unreadable or for other reasons unavailable. Thus, in this embodiment the merchant scans the barcode 197 (
The lottery central site 160 will then: extract the validation data from the transaction's data blob 192 (
Aside from instant ticket processing, the same piggybacking via BIN mechanism over the interchange that enables instant ticket sales can also be utilized for on-line (e.g., Pick 3, Pick 4, Powerball, Mega Millions, etc.) sales and validation. As illustrated in
For quick-pick (i.e., numbers automatically selected for the consumer) purchases of on-line tickets, the consumer would either take a plastic hanging card 200 (
As before, the pending quick-pick transaction is forwarded to the acquiring processor 110 (
It should be noted, that until recently the printing of quick-pick ticket printing process would not have been possible via the piggyback interchange BIN mechanism. This is because on-line tickets are traditionally printed on ticket stock with serial numbering preprinted on the back along with other security features (e.g., ultraviolet visible ink). The preprinted serial numbering and other features providing added security in determining the authenticity of an apparent high-tier winning ticket. Therefore, the need for special preprinted security paper would prohibit a merchant from printing quick-pick tickets using his or her normal cash register or other printer—i.e., the logistical challenges would prohibit merchants from loading special lottery paper into their cash register. Alternatively, the merchant could be supplied with a special lottery printer that uses the special security paper, but the addition of a lottery printer would necessitate custom lottery interfaces for the merchant's POS equipment, increasing the costs and re-introducing custom lottery hardware at the POS.
Fortunately, recently two Ticket Message Authentication Code (T-Mac) patents have issued (i.e., Irwin U.S. Pat. No. 7,788,482 and U.S. Pat. No. 8,037,307) which eliminates the need for special security paper for on-line tickets by employing cryptographic techniques that add a Message Authentication Code (Mac) to the ticket's serial number that make it virtually impossible to copy or forge the ticket. However, the T-Mac patents reference certain cryptographic functions being performed by field lottery terminals. In the context of the piggyback interchange BIN mechanism, the lottery terminal would be the merchant's POS equipment 105 (
Validations of on-line game tickets (e.g., Pick 3, Pick 4, Powerball, Mega Millions, etc.) are conducted similar to instant ticket validation. In the preferred embodiment, processing an on-line game ticket validation begins with the lottery on-line ticket consumer 100′ presenting a perceived winning on-line ticket 210 (
In either case, the interchange compatible barcode 212 will be configured to be compatible with the proxy data packet 215 (
Returning to the pending on-line ticket validation, the merchant's POS equipment 105 (
Of course, the entire debit or credit interchange only exists because it garners fees per transaction. With piggybacking on the debit or credit interchange for lottery transactions, this paradigm need not change. When the high costs of manufacturing, installing, maintaining, and communicating with custom lottery field hardware is taken into account the economics of paying a small fee per lottery transaction with virtually no upfront costs becomes attractive. Essentially the lottery economic model changes from a system with significant upfront costs as well as continuing communications charges, to a leased services model that only pays per transaction with the benefit of virtually no upfront or continuing communications costs.
Indeed, when a lottery service provider wins a bid for providing, installing, and maintaining lottery equipment, the lottery service provider must pay for the equipment and network at the time of contract award. The lottery service provider hoping to regain the massive capital outlay as well as associated finance charges throughout the course of the contract—i.e., typically lottery contracts in the U.S. provide little or no payments at contract award. This is why publicly traded lottery service providers typically report lower quarterly earnings immediately after they win large new lottery contracts. In other words, the capital outlays required to finance a lottery contract startup effort tend to consume any available revenue in the same fiscal quarter.
Aside from virtually eliminating lottery startup costs, recent United States federal legislation (e.g., Durbin amendment) limiting what the debit or credit card interchange can charge per transaction have forced interchange providers to look for new sources of revenue. This is turn, makes piggybacking on the debit or credit interchange for lottery transactions more attractive to not only the lottery service providers but the interchange providers as well. Thereby creating a synergistic opportunity for all parties involved.
Of course, as is obvious to one skilled in the art, other established retail network systems (e.g., coupon validation) can be employed to provide the same sans custom hardware functionality as the debit or credit card interchange previously described and indeed, in some circumstances may be preferable.
In addition to brick and mortar merchant locations, the notion of sans custom hardware lottery or contest operations can be expanded to street vendors. While unusual in the United States, street vendors are a common sight in developing countries creating sales without the need for an established lottery infrastructure using brick and mortar locations. Traditionally, these street vendors would roam with a limited inventory of instant tickets literally conducting street sales and paying small prizes on the spot. The typical lack of connectivity to a lottery central site forces the street vendor to reconcile at the end of the day, matching unsold inventory and claimed tickets with the amount of cash reserves at the end of the day. This lack of connectivity and the need to carry potentially large amounts of cash have created security problems for the street vendor.
However, smart phone technology has recently become sophisticated enough to permit programming cell phones (to do computations, perform functions, and store data) previously reserved for laptop or desktop computers. The latest generation of these smart phones is equipped with higher resolution cameras that can function to record information that can also be transmitted over a cellular network.
Technology has also evolved in the automobile rental industry that permits hand held thermal printers with barcode scanners and keyboards to communicate with servers over short distances to exchange information, complete transactions and print receipts for customers remote from traditional clerks stationed at immobile terminals.
Given these advancements and their equipment miniaturization, there are now alternatives that can allow lottery transactions that have been restricted to stationary locations to become fully portable and adaptable for street vendor use. The synergistic coupling of these newer generic hardware technologies with cellular networks and associated payment mechanisms allows for street vendor based lottery systems to operate without the need and associated expense of custom hardware. Additionally, by using debit cards both for procurement and prize payments with off-the-shelf equipment and networks reduces both the potential for street vendor fraud as well as reduces the risks associated with robbery since the vendors will no longer need to carry large amounts of cash on their persons.
In one embodiment, the street vendor 220 (
In this embodiment, the street vendor 220 would be able to sell both instant and on-line (e.g., Pick 3, Pick 4, etc.) lottery tickets as well as validate and redeem both. Additionally, like the debit or credit card interchange piggyback embodiment with brick and mortar merchants, the street vendor 220 would also be able to activate instant lottery tickets 223 individually at the time of sale. The advantages being both automatic inventory accounting as well as reduced chances of theft since the un-activated instant tickets 223 would not validate or redeem on the lottery system.
An instant ticket sale would be conducted by the street vendor receiving payment for an instant ticket which he or she would log into their portable tablet computer/communications device 221 either by touchscreen numerical entry or, preferably, by scanning a debit card for payment. The touchscreen numerical entry being primarily envisioned for cash sales and therefore having the disadvantage of possibly burdening the street vendor 220 with large sums of cash with the inherent security risks. In a preferred embodiment, a debit (or possibly credit) card is accepted for payment—i.e., depending on the laws in the lottery's jurisdiction, it may not be legal to accept credit cards as a form of payment for the sale of lottery products. In this embodiment, the street vendor 220 would scan or swipe the debit or credit card also scanning the barcode of the instant ticket(s) being sold on the tablet computer/communications device 221. Swiping of the debit or credit card (i.e., acquiring the magnetic stripe or smart card data) could be accomplished with a third party off-the-shelf portable reader (not shown in
With either embodiment, once the instant ticket and payment information has been collected by the street vendor's 220 portable tablet computer/communications device 221, the information is transmitted to the lottery central site. The instant ticket is then activated on the lottery central site database and an acknowledgement is transmitted back to the street vendor's 220 portable tablet computer/communications device 221.
A similar methodology can be employed to minimize cash outlays when the street vendor 220 is paying out prizes. In this embodiment, the street vendor 220 receives an apparent winning instant or on-line ticket from the consumer for payment. The street vendor 220 then scans the barcode of the apparent winning ticket with the portable tablet computer/communications device 221 with the decoded ticket barcode data transmitted to the lottery central site. The central site then checks its database to confirm that the ticket is in fact a winner and has not been previously paid. Assuming the ticket qualifies the central site then transmits to the street vendor 220 portable tablet computer/communications device 221 an authorization to pay data packet, which is physically printed on the street vendor's 220 portable printer 222. Once the authorization to pay is received, the street vend& 220 could pay the consumer with cash, but preferably the street vendor 220 would produce a heretofore not activated debit card and scan the card with the portable tablet computer/communications device 221 camera. Thus collecting one or more images of the debit for OCR processing of the embossed or printed card data for extraction of the card's account number. When the account number is determined (by OCR or other means), the card account data is transmitted to an issuing processor along with the authorized prize amount. The issuing processor then activates the associated debit card account funded by the winning prize amount. An acknowledgement is then transmitted back to the street vendor 220 portable tablet computer/communications device 221, which is physically printed on the street vendor's 220 portable printer 222. Of course, if the consumer already has a debit card, the above prize payment process could also be utilized to deposit the winnings directly into the consumer's card account.
As is obvious to anyone skilled in the art, the above debit card payment means could be implemented by swiping the card or manual entry and may be preferable under some circumstances. However, the OCR card-scanning embodiment is generally preferred to reduce the amount of hardware carried by the street vendor 220 as well as possibly providing a higher security means of debit or credit card scanning.
A typical credit or debit card 230 is illustrated in
While there are numerous methods for algorithmically determining the edges of a debit or credit card 230, a preferred method is to measure the color and intensity values of each pixel relative to its neighboring pixels either horizontally or vertically checking for pixels that experience a large change or delta from a running average. When a large delta is detected, the pixel is mapped into a memory array 250 (
Once the card 230 edges are known to the algorithm the differences between the measured lengths of the card 230 widths 231 and 231′ and heights 232 and 232′ can be compared to help determine the skew of card 230 relative to the camera. Additionally, measuring the angle of intersection of the card edges also can be utilized to help determine the skew of the image.
If multiple images of the card 230 are captured at varying angles, it is possible for the OCR application to also include a database of any security feature (e.g., hologram 236) present on card 230 with its location relative to the card image 230 edges known a priori. In this embodiment, the security feature database would be organized by debit or credit account BIN codes. The BIN being extracted from the OCR decoding of the debit or credit card account number 233 of card 230. Thus, if a familiar BIN was retrieved from the OCR decoded account number, the details of the debit or credit card layout can be retrieved from the process database. Assuming a security feature is found in the database, the OCR image processing software could also test to determine if the security feature reacts properly to a change in angle of view—e.g., hologram 236 changing color. Of course, other physical features of the debit or credit card 230 (e.g., smart card interface connector 238, embossed numbering, etc.) can be stored in the database to also ensure the card's authenticity. Conversely, if an anticipated security feature reaction was not detected or a debit or credit card 230 BIN was not found in the database, additional authentication measures may be required to ensure authenticity.
Returning to the street vendor 220 of
Thus, all of the lottery functionality can be achieved with the disclosed portable street vendor's system 220. The wireless network connectivity linking the street vendor to the lottery central site and possibly an issuing processor of a debit or credit card.
The previously disclosed debit or credit card interchange piggybacking network is one embodiment that would accommodate the street vendor assuming a wireless cellular or other means is used to link the street vendor's 220 portable tablet computer/communications device 221 to the issuing processor and the interchange.
In yet another embodiment, a comparable method can be used to sell passive game tickets by street vendors. Traditionally these tickets are printed in advance with unique identifiers—e.g., numbers. Drawings are subsequently held picking the identifiers that correspond to specific prizes. Unsold tickets for a particular drawing must be returned to the lottery in advance of the drawing requiring up to a two-day delay between the cutoff of games sales and the drawing to ensure all unsold tickets are accounted for. Often there is confusion in the return system leaving open questions as to which tickets have been sold and which are being returned. Additionally, there is also paper waste with the return of unsold tickets. The mechanism described above for the sale of on-line tickets can be adapted for passive game tickets to eliminate paper waste, returns, for drawings, and fraud while establishing a clear record of sales and 100% inventory control via the central system.
In this embodiment, the passive game tickets 224 (
Alternatively, preprinted passive tickets 224′ (
Notice that the above network can be readily modified to have the advantage of the street vendor 220′ using the card issuing processor as also the acquiring processor 110′—
A typical lottery transaction with the preferred, cost reduction, embodiment of
If the street vendor 220′ and consumer 100′ elect to complete the transaction with a debit card, the consumer 100′ would either hand his authorized debit card (e.g., a debit card from a previous lottery winning, a debit card issued by the same issuing processor 110′, a General Purpose Reloadable (GPR) card, etc.) to the street vendor 220′ or the street vendor 220′ would activate one of the un-activated debit cards he or she carries. In either case, the street vendor would then send a payment load request for the prize amount to the issuing and acquiring processor 110′ via the wireless communications link 260. The issuing and acquiring processor 110′ would then transfer the winning funds from the lottery's bank account to the account associated with the debit card. Once the transfer was completed and an acknowledgment received, the street vendor 220′ would then hand the loaded debit card to the consumer 100′.
As illustrated in
Of course, the lottery central site connected to common acquiring processor embodiment could also be used to access the debit or credit interchange and thereby issuing processors other than the acquiring processor (not shown in
Finally, consumer off-the-shelf hardware (e.g., smart telephone, tablet, etc.) can be adapted through custom applications to create a medium allowing the consumer to place specific wagers over a lottery network. In this embodiment, a lottery specific application is downloaded onto the consumer's off-the-shelf hardware to provide both a user interface as well as communications link to the lottery network. For example,
In any case, once the wager(s) have been entered into the smart telephone 275 application 276, the smart telephone 275 must register the wager with the lottery network. There are multiplicities of methods to accomplish this registration process.
In one embodiment, a local Radio Frequency (RF) link (e.g., 802.11, Bluetooth, Near Field Communications—NFC, etc.) between the smart telephone and the lottery retailer's device (either a traditional store or a street vendor) can transfer the wager information. If a street vendor 220 (
However, the above embodiments have the disadvantage of not being compatible with existing brick and mortar retailer POS equipment, consequently requiring custom hardware and/or software with the associated logistical challenges and costs. In a preferred embodiment, the consumer's smart telephone 275 (
Once the smart telephone 275 (
Of course, as is obvious to anyone skilled in the art, other consumer devices (e.g., portable tablet computers, laptop computers, etc.) may be employed in the same embodiment and may be preferable in some cases.
1. A method for collecting and transmitting information desired for a commercial transaction from a debit or credit card, the method comprising use of a processor configured with optical character recognition (OCR) capability to perform steps of:
- collecting at least one optical image of the debit or credit card;
- algorithmically defining the edges of the debit or credit card from the collected image;
- applying predefined offsets to the algorithmically defined edges of the debit or credit card to algorithmically locate an area in the collected image having the desired transactional data;
- encoding the transactional data within the located area; and
- transmitting the encoded data for further processing of the commercial transaction.
2. The method of claim 1, wherein the area in the collected image contains an account number associated with the debit or credit card.
3. The method of claim 1, wherein the edges of the debit or credit card are algorithmically defined by measuring one or both of color and intensity values of pixels in the optical image, wherein pixels having a defined differential color or intensity value relative to neighboring pixels are flagged and mapped in a memory array.
4. The method of claim 3, wherein individual pixels are compared against a running average of neighboring horizontal or vertical pixels for flagging the pixels having a defined differential color or intensity value relative to neighboring pixels.
5. The method of claim 3, further comprising filtering out flagged pixels that are not connectable by a continuous line to neighboring pixels.
6. The method of claim 3, wherein the mapped memory array is a two dimensional representation of each pixel in a scanner's field of view used to collect the optical image, and further comprising connecting lines between the flagged pixels, wherein the lines denote edges of the debit or credit card.
7. The method of claim 6, further comprising detecting rounded corners at intersections of the connected lines as an aid in defining edges of the debit or credit card.
8. The method of claim 3, further comprising processing the collected optical image with a digital filter to smooth out pixels having the defined color or intensity value attributable to graphics on the credit or debit card.
9. The method of claim 1, further comprising determining a skew orientation of the collected optical image relative to a scanner or camera used of collect the optical image.
10. The method of claim 9, wherein the skew orientation is determined by comparing known width and height dimensions of the credit or debit card to measured width and height dimensions obtained from the algorithmically defined edges.
11. The method of claim 9, wherein the skew orientation is determined by measuring an angle of intersection of the algorithmically defined edges.
12. The method of claim 1, further comprising retrieving attributes of known security features embedded in the credit or debit card from a database, and testing the collected optical image with the OCR software to determine if the collected image contains the security feature attributes.
13. The method of claim 12, wherein the security feature database is organized by credit or debit card back identification number (BIN), the area in the collected image having the transactional data contains an account number associated with the debit or credit card, wherein the BIN is extracted from the account number and used to access the security feature database.
International Classification: G06K 9/18 (20060101);