US20100306168A1

US20100306168A1 - Transaction data capture devices and related methods

Info

Publication number: US20100306168A1
Application number: US12/782,481
Authority: US
Inventors: Nima Ostad; Robert William Bohn; William Robert Bohn
Original assignee: Individual
Current assignee: Individual
Priority date: 2009-06-01
Filing date: 2010-05-18
Publication date: 2010-12-02
Also published as: US20100301113A1; US8387858B2

Abstract

A data capture system captures transaction data and a unique identifier of a recipient and combines the information to form a total transaction data set. The total transaction data set is associated with demographic information about the recipient and the total information is reserved for review by providers or recipients respectively to analyze the transactions.

Description

RELATED APPLICATION

This application claims the benefit of and priority to U.S. Provisional Application Ser. No. 61/182,876, filed Jun. 1, 2009, the contents of which are incorporated by reference herein in its entirety.

BACKGROUND

This disclosure relates to the capture of transaction data and the association of such data with a recipient and the recipient's associated demographics. The associated data is made available for analysis.

SUMMARY

A data capture system captures transaction data and a unique identifier of a recipient and combines the information to form a total transaction data set. The total transaction data set is associated with demographic information about the recipient, provider and the total information is reserved for review by providers or recipients, respectively, to analyze the transactions.
According to aspects of this disclosure, a system is disclosed comprising a data capture module that captures transaction data related to a transaction and a unique identifier of a recipient and provider, a data association module that associates the transaction data and the unique identifier, a database for storing the associated transaction data and unique identifier disposed on a server, and an internet module.
According to aspects of this disclosure, a method is disclosed comprising using a computer to capture a unique identifier of a recipient, capture transaction data related to a transaction between the recipient and a provider, associate the unique identifier with the transaction data to form a total transaction data set, record the total transaction data set in a database, and provide the data related to one or more transactions to a user via an internet module. The associated unique identifier and transaction data are recorded whereby the total transaction data are associated with at least one of a provider account or a recipient account.
According to aspects of this disclosure, a machine-readable medium is disclosed having instructions stored thereon for associating a recipient with a unique identifier, collecting demographic information from the recipient, capturing a unique identifier of the recipient at the point of sale of a transaction, capturing transaction data related to the transaction between the recipient and a provider at the point of sale, associating the unique identifier with the transaction data to form a total transaction data set, recording the associated unique identifier and transaction data in a database, and further associating the total transaction data set with demographic information collected from the recipient.

DRAWINGS

The above-mentioned features and objects of the present disclosure will become more apparent with reference to the following description taken in conjunction with the accompanying drawings wherein like reference numerals denote like elements and in which:

FIG. 1 is a block diagram of an embodiment of the devices used in a transaction data capture device and system;

FIG. 2 is an information sharing diagram of an embodiment of exemplary functions available to a provider using the data capture system;

FIG. 3 is an information sharing diagram of an embodiment of exemplary functions available to a recipient using the data capture system.

FIG. 4 is a block diagram of an embodiment of the various modules used in transaction data capture devices and systems; and

FIG. 5 is a flow diagram of an embodiment of a method of capturing transaction data and associating the captured transaction data with the unique identifier of a recipient and collecting associated data.

DETAILED DESCRIPTION

In the following detailed description of embodiments of the present disclosure, reference is made to the accompanying drawings in which like references indicate similar elements, and in which is shown by way of illustration specific embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical, functional, and other changes may be made without departing from the scope of the present disclosure. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present disclosure is defined only by the appended claims. As used in the present disclosure, the term “or” shall be understood to be defined as a logical disjunction and shall not indicate an exclusive disjunction unless expressly indicated as such or notated as “xor.”
As used herein, the term “demographic” shall mean a statistic of an entity, including persons and business entities, related to vital statistics, physical locations, geography, population size, population density, and other data that is useful for analyzing behavior related to transactions.
As used herein, the term “transaction” shall mean the exchange of a good or service between at least one entity providing the good or service and another entity in exchange for remuneration from the other entity or a third entity. The term “transaction” expressly encompasses as individual “transactions” incremental steps in a complete transaction. For example, a recipient may purchase a meal at a hotel and charging it back to a room; thus, at the time the meal transaction is complete, no remuneration for the meal is provided, although a provider may wish to capture transaction data for the meal as part of an incremental part of the larger transaction (i.e., settling the entire hotel bill). The term transaction shall also expressly contemplate third parties providing the remuneration for the recipient.
As used herein, the term “recipient” shall mean an entity providing remuneration to a provider for a good or service.
As used herein, the term “provider” shall mean an entity providing a good or service to a recipient for remuneration. Providers encompass entities providing the good at the point of sale, distributors of the good or service, providers of the good or service, or manufacturers of the good or service.
As used herein, the term “point of sale” or “POS” shall mean the physical or internet location where a transaction is captured or conducted. With respect to an internet location, the POS shall be considered as the website on which the transaction occurs.
As used herein, the term “entity” shall mean a person or, a business, or other unit or organization capable of entering into a transaction.
The inventors of this application invented devices, systems, and methods for the capture of transaction data and the association of the transaction data with demographic data related to the recipient in the transaction. According to embodiments, at the point of sale (POS), both transaction data and unique identifier associated with the recipient are captured (collected). These data are associated together and stored in a database. The database maintains these data for later analysis or use.
According to embodiments, total transaction data captured from transactions is useful in a variety of ways including providing providers with tools to evaluate advertising success, product placement, and demographic purchasing trends. Providers also benefit by better inventory control, and better understanding of the demographics entering into transaction with them. For recipients, the data provided by the systems and methods disclosed herein include analysis of spending and budgeting, among other uses. Other uses of the systems and methods disclosed herein expressly include: tracking hospital patient and equipment movement, inventory management, tracking people/equipment movement through transit systems (trains, busses, cars on roads), Kanban production system management, supply chain management (SCM) tracking, event/building guest lists, hotel guest tab tracking, restaurant resource/supply management, bar resource/supply management, delivery service inventory/tracking (related to SCM), medicine inventory management for use in households, pharmacy supply control (especially to ensure the correct drugs are delivered in the proper dosages), household clothing inventory, veterinarian and animal shelter pet tracking, food/drink/consumables rationing system management systems, electronic data transmission permission management (control if a files/data/information should be transmitted based on identifier, or what data/information has been transmitted).
According to embodiments and as illustrated in FIG. 1, data capture system 1, with its related devices and modules, is disclosed. According to embodiments, data capture system 1 comprises two primary components: remote server 10 and point-of-sale capture device 20. According to embodiments, recipient/provider computer 30 is considered part of data capture system 1, but is under the control of the recipient respectively.
As illustrated in FIG. 1, at each POS location, point of sale capture device 20 comprises one or more POS computers 200 that capture the transaction data and identify the recipient involved in each transaction. According to embodiments, POS computer 200 comprises a cash register capable of executing software necessary to collect transaction data and associate the collected transaction data with a recipient's captured unique identifier. According to other embodiments, POS computer 200 is a stand alone device used in conjunction with other sales equipment, for example analog cash registers, credit card readers, or cash boxes. According to this example, POS computer 200 could be a personal computer connected to server 100 via in the internet. According to other embodiments, POS computer 200 comprises a server and a collection of nodes connecting to the server, each node individually capturing transaction data and unique identifiers and conveying the data to the provider's server (e.g., a plurality of cash registers at a grocery store, which connect to a server that supplies each cash register computer with prices, etc. for each bar code scanned).
According to embodiments, unique identifier reader 210 detects a recipient based on a unique identifier of that recipient. A unique identifier comprises an alphanumeric string or other information that uniquely identifies a recipient. Examples of unique identifiers include social security numbers, credit card numbers, driver's license numbers, email addresses, etc, or combinations thereof. According to alternate embodiments, each recipient's unique identifier comprises an arbitrary number assigned to the recipient or selected by the recipient. According to still other embodiments, unique identifier include biometrics (retina scans, biological samples, DNA scans, etc.), quick response (QR) codes, photographic recognition of shapes and colors of an object on a person or the person itself (appearance-based recognition), unique signal/pattern transmission of electromagnetic waves, unique sounds/vibrations both in pitch and pattern, scent recognition, images displayed on mobile electronic devices, unique codes stored electronically on small storage devices (e.g., an identifier encoded in an identifier file contained on a USB storage device), light refraction through unique substances, and combinations thereof. Artisans will readily recognize that many of these methods are encompassed by HID-type systems, wherein a unique identifier is read by a specialized reader (e.g., RFID tags and readers, QR codes, retinal scans and other biometric scans, etc.).
According to embodiments, a verification personal identifier (PIN) can be used in conjunction with the unique identifier for added security. The PIN is entered into an input device connected to POS computer 200 according to embodiments.
According to embodiments, each recipient's unique identifier is transmitted from a human interface device (HID) device, such as an RFID reader and tag. According to embodiments, HID device is an RFID tag and RFID reader. Accordingly, each HID device comprises at least an HID tag having a chip or circuit that is able to store the unique identifier and cause transmission of the unique identifier when queried by HID reader via a radio frequency signal, and an antenna. According to embodiments, HID device can either be active or passive. For example, HID device comprises an HID tag disposed in a keychain fob according to embodiments, or embedded into a credit card sized card for storage in a wallet or in other locations according to other equally effective embodiments. Other examples include HID tags embedded in the microcircuits of mobile phones or other portable electronic devices. Generally, the HID tag must be disposed in a device that is carried on the person of the recipient, whereby unique identifier reader 210 can detect and read the unique identifier transmitted by the HID tag when the recipient is nearby POS computer 200. According to the embodiments, HID reader is disposed at the POS and can read the HID tag during completion of the transaction.
According to embodiments, when a recipient makes a transaction, for example approaching a cash register to tender payment for goods or service, an HID reader queries the recipient's HID tag and captures the recipient's unique identifier from the HID tag. According to embodiments, a PIN may be required to verify the identity of the recipient.
In some cases, multiple HID tags from multiple recipients will be in range of unique identifier reader 210 (HID reader). In these cases, [HID RESOLUTION] the provider may ask the recipient for physical HID device so the provider can disambiguate the multiple captured unique identifiers by reference to HID device, according to embodiments.
According to alternate embodiments of disambiguating multiple captured unique identifiers, the provider will be able to input into POS computer 200 features that disambiguate the recipients. For example, if a couple, both having an HID device, approaches unique identifier reader 210, POS computer will send both unique identifiers to server 100 with a disambiguation request. Server 100 will query database 1010, which will return demographic information related to both unique identifiers. The returned demographic data which will then be transmitted to POS computer 200. POS computer 200, for example, will present the provider with an option of selecting whether the male or female is conducting the transaction. Depending on the selection made by the provider, the unique identifier of the actual recipient making the transaction will be disambiguated.
According to still other embodiments, the recipient will enter a unique PIN into POS computer 200 via an input device. All of the HID's captured during the transaction will then be submitted as part of the total transaction data to server 100. When the total transaction data reaches server 100, the PIN will be used to select the correct HID for the transaction and the other captured unique identifiers will be discarded.
According to embodiments, unique identifier reader 210 is a credit card machine. Accordingly, the recipient's credit card number comprises the unique identifier. The credit card machine reads the credit card of the recipient, which is transmitted to server 100 as part of the total transaction data set and used as the primary or a secondary unique identifier.
According to embodiments, recipients have multiple unique identifiers. For example, a recipient has a plurality of credit cards, a driver's license, a cellular telephone number, and email address, and an HID FOB. Each of these unique identifiers can be used to uniquely identify the recipient. For example, the recipient's HID tag is read at the time he approaches a cash register by unique identifier reader 210, which is an HID reader in this case. Thereafter, the recipient might provide a credit card to tender payment to the provider. Both the unique identifier transmitted by the HID tag and the credit card number are transmitted as part of the total transaction data, set to server 100, according to embodiments, and the credit card number might be used to disambiguate multiple captured HID unique identifiers included in the total transaction data set. Moreover, if a recipient forgets a primary form of tendering a unique identifier for example an HID card, the recipient will be able to use an alternate unique identifier at the POS, such as a credit card number, telephone number, or arbitrary unique identifier.
According to embodiments, point of sale capture device 20 is a stand alone device and peripheral used in conjunction with an analog cash register. Accordingly, point of sale capture device 20 may comprise a credit card reader as described above further comprising both unique 210 identifier reader and POS computer 200, or could comprise an input device that allows the recipient to manually input a unique identifier. Such an input device is any computer input device that allows a user to input an alphanumeric string, for example a keyboard, mouse, touchpad, or touch screen, according to embodiments.
According to embodiments, POS capture device 20 is a specialized cash register that is configured to capture a unique identifier of a recipient via HID or via another method of identification as disclosed herein and automatically transmits the total transaction data to server 100. Accordingly, the cash register's processor and other hardware comprise point of sale computer 200. The register's input and RFID reader device comprises unique identifier reader 210, according to embodiments. According to other embodiments, the cash register is configured to receive signals from ancillary hardware comprising unique identifier reader 210. In this case, the register is POS computer 200.
According to another example, POS computer 200 is a stand alone device that is intended to be used with paper forms of conducting transactions, for example for mobile cash stations or transactions traditionally done with paper sales slips such as the purchase of an automobile or real estate. Accordingly, POS computer 200 captures a unique identifier via unique identifier reader 210 which could be a built-in or ancillary HID reader or input device, as described above. According to embodiments, POS computer 200 stores the unique identifier and outputs to the provider a unique transaction number to be recorded with a paper record of the transaction. Thereafter, the provider either scans the paper record or manually inputs transaction details contained with the paper record. At that time, the provider would also enter the unique transaction number, whereby the transaction data is coupled to the captured unique identifier of the recipient.
According to other embodiments, the entire transaction is conducted manually. The provider records a unique identifier manually from the recipient, e.g., a driver's license number or a credit card number, as well as the transaction data. The provider then inputs the unique identifier and transaction data into POS computer 200.
According to embodiments, POS capture device 20 further comprises virtual printer 220. Virtual printer 220 prints a virtual copy of a receipt recording details of the transaction between the provider and the recipient. According to embodiments, virtual printer 220 is a portable document format (pdf) printer, image printer, word processor document printer, or other printer that prints a receipt to an electronic file that is stored locally to POS computer's 200 local disk, solid state storage, or RAM, for example. According to embodiments, the text embedded in the electronic file output from virtual printer 220 is recognized via optical character recognition algorithms (OCR) or plain text. According to embodiments, recognition is enhanced by providing the OCR algorithm with a template mask that directs the OCR algorithm where in the virtual receipt to seek specific pieces of information. For example, the algorithm might “look” to the top right of the receipt to locate the date. For each data field recognized, POS computer 200 stores the data in local storage for later association with the recipient's unique identifier to form a total transaction data set and subsequent transmission to server 10. According to embodiments, virtual printer 220 is used in conjunction with printer 230 for printing both a virtual copy of a receipt and a paper copy of the receipt that can be given to the recipient as proof of the transaction.
Rather than using an image of the transaction receipt via a virtual printer and OCR to recognize and capture the details of the transaction, POS computer 200 stores and transmits raw transaction data, according to embodiments. For example, if a recipient purchases a package of gum, an SKU is scanned by an optical scanner connected to POS computer 200. Once POS computer 200 recognizes the product SKU, certain data is accessed via a database, for example, the name of the package of gum, the price of the package of gum, etc. Similarly, other data is likewise gathered, for example the date and time of the transaction, the provider or provider's agent that conducted the transaction, the physical location where the transaction occurred, and other data that might be relevant with respect to a given transaction. According to embodiments, these specific pieces of data are stored in a database or in an extensible mark up language (XML) file. Rather than outputting this data via a virtual receipt, POS computer 200 gathers the data and stores it locally until it is ready to be transmitted to server 100 with the recipient's unique identifier. Where raw transaction data is captured, according to embodiments, an actual paper copy of the receipt is also output and deliverable to the recipient as proof of the transaction.
According to embodiments, POS capture device 20 also comprises printer 230 for printing paper receipts. Printer 230 is connected to POS computer 200 via standard connections, e.g., serial connection (RS232), universal serial bus (USB) connection, network connection via IEEE 801.02 wired standard or IEEE 802.11 wireless standard, Bluetooth (IEEE 802.15.1), or via proprietary connection methods. Printer 230 is any standard receipt printer, according to embodiments.
According to embodiments, after transaction data and the recipient's unique identifier are captured, they are associated together to form the total transaction data set. According to embodiments, association occurs at the time the transaction occurs. For example, at the conclusion of the transaction, the transaction data and the unique identifier of the recipient are combined into the total transaction data set. The total transaction data set is stored in a database or as an XML file, according to embodiments. In both cases, association of the transaction data with the unique identifier is accomplished by simply adding the unique identifier to a database table or appending it to an XML file with the appropriate tags. The receipt given to the recipient as proof of the transaction includes the total transaction data, according to embodiments. Thus, the recipient is able to verify that he is correctly identified as the recipient. According to other embodiments, the combination of unique identifier and transaction data occurs shortly after the transaction is concluded. Generally, combination of the unique identifier and transaction data is effective around the time of the transaction and prior to subsequent transactions occurring.
According to embodiments and as illustrated in FIG. 1, POS capture device 20 communicates with remote server 10 bi-directionally. POS capture device 20 transmits total transaction data, comprising both transaction data, an associated unique identifier of the recipient involved in the transaction, and a provider identifier to remote server 10. According to embodiments the connection between remote server 10 and POS capture device 20 is an internet connection using common internet protocols (e.g. http, ftp, etc.) or occurs via telephone connection.
According to embodiments, remote server 10 comprises at least server 100 and database 1010. According to embodiments, server 100 comprises at least a web server service, for example an Apache web server or Internet Information Services (IIS) web server. Server 100 facilitates remote communication with point of sale capture device 20 via the web server, according to embodiments.
According to embodiments, server 100 also communicates with database 1010. According to embodiments, server 100 will support server side scripting, of any kind, for example PHP: hypertext preprocessor (PHP), for access of the data to be written to or contained in database 1010 and also for dynamically presenting data as part of webpages to a recipient or provider via recipient/provider computer 30.
According to embodiments database 1010 is implemented as part of server 1010. Database is the central hub for all the data to be collected, stored, and processed. It is also a location from where data is retrieved. Database 1010 is an organizational tool for organizing and storing data gathered at the point of sale. Database 1010 may be implemented as a SQL database, MYSQL database, or Oracle database, or a proprietary database for example. Use of other commercially available or specially implemented databases are expressly contemplated. According to other embodiments, database 1010 is developed specifically for organizing and storing data generated from transactions. Generally, database 1010 must be able to store and retrieve large volumes of data and provide access to the data.
According to embodiments and as illustrated in FIG. 1, the recipient/provider can use computer 300 having an internet connection to communicate with server 100. Using internet connected computer 300, provider/recipient can access a variety of data related to completed transaction.
For example, as illustrated according to embodiments in FIG. 2, each provider has account 400A, 400B, 400N with data capture system 1. According to embodiments, each provider account is private from other provider's accounts. Each provider account is hosted on server 100, via provider account 400A, 400B, 400N, a provider is able to access data contained in database 1010. Using internet connected computer 300 (FIG. 1), providers are able to view data related to individual transactions, view demographics related statistics, etc. For example, a provider may want to know what age group is buying a given product, or the provider may wish to know whether more men or more women shop at his store. These data can be used in various ways by the provider: to promote products, to evaluate and select advertising channels, to product placement on the floor of brick-and-mortar stores.
According to embodiments and as illustrated in FIG. 2, each provider account comprises a plurality of modules. Each module is tailored to perform one or more specific functions. Front-end login credential module 402 provides provider with a portal to securely log into and out of the account, as well as change login passwords. Individual settings module 404 gives the provider the ability to set individual settings, for example default screen resolution, number of search results in a list, etc. Such settings are well known and understood by artisans.
According to embodiments, reports module 406 allows the provider to create and run various reports related to total transaction data contained in database 1010, for example. Recipient demographic information module 408 allows provider to create and run various queries related to the demographics of recipients with whom provider entered transactions. Similarly, product demographic information module 410 allows the provider to create and run various queries related to the sales of particular goods or services, and evaluate the demographics of those who are buying or not buying those goods or services. Transaction histories module 412 allows the provider to review transaction histories based on criteria such as date, store, recipient, etc. Each of modules 406, 408, 410, 412 are database query modules that allow the provider to review and evaluate transaction data based on a given criteria. According to embodiments, each of these modules 406, 408, 410, 412 are condensed into a single database search module. However, for the purposes of illustration of the types of data that would be available in an exemplary provider account of data capture system 1, they are presented herein as individual modules. Other modules are likewise expressly contemplated depending on the specific transaction data captured per each implementation of data capture system 1.
Finally, each provider account comprises analysis tools module 414, according to embodiments. Analysis tools module 414 provides tools for analyzing various data. For example, analysis tools may look at the sales of a particular product and make a recommendation for an advertising channel depending on demographics. For example, analysis tools could look for products purchased by women aged 30-50 for an advertising spot in Good Housekeeping. According to another example, the same product could be advertised in different markets using different advertising campaigns. Analysis tools module could then be used to analyze which campaign was more effective on a per demographics basis.
According to embodiments, other providers in the chain of a good or service, such as the manufacturer of a good will have an account with data capture system 1 and have POS total transaction data that concerns them automatically pushed to their accounts. Each manufacturer will place into commerce goods that are indentified with an SKU, and as such will be able to aggregate data for all goods or services associated with the SKU and use that data for beneficial purposes specific to the manufacturer.
For example, when a given good is sold, the manufacturer of the good may automatically have data for the transaction associated with the manufacturer's account based on the SKU. Other data that might be pushed to the manufacturers account, according to embodiments, includes at least the name of the provider, the identity of the recipient provided. According to other embodiments, the recipient's identity or demographic information could be held confidential unless the recipient expressly consents to have it shared with the provider or requests automatic enrollment in a warranty program, for example. According to some embodiments, some data from the transaction is withheld from the manufacturer. For example, if a recipient purchases three goods manufactured by three different manufacturers, then each manufacturer would only have access to total transaction data as it relates to them—i.e., data related to sale of the goods produced by the other manufacturers would be transparent to the manufacturer such that as far as the manufacturer is concerned, only a single good was purchased by the recipient. With transaction data that is automatically pushed to the manufacturer, the manufacturer is able to make manufacturing forecasts, run reports, budget required stock and assess inventory in real time. Moreover, manufacturers can use transaction data to incentivize the provider at the POS or adjust the suggested prices based on real time data regarding demand. A manufacturer-provider account would closely resemble the provider accounts described above, except would be tailored to providing data specific to the manufacturer. Generally, any entity can have an account provided they have a unique identifier (such as a recipient unique identifier or a provider unique identifier, or they supply a good or service that can be uniquely identified).
FIG. 3 illustrates embodiments of a recipient's account with data capture system 1. Accordingly, recipients and providers have different functions at their disposal. As illustrated in FIG. 3, a plurality of recipient accounts 500A, 500B, 500N are shown. Each recipient account 500A, 500B, 500N is implemented on server 100, according to embodiments, and comprises a plurality of modules that allow the recipient to perform tasks. Front-end login credential module 502 provides the recipient with a portal to securely log into and out of the account, as well as change login passwords. Individual settings module 504 gives the recipient the ability to set individual settings, for example default screen, output resolution, number of search results in a list, etc. Such settings are well known and understood by artisans.
According to embodiments, reports module 506, transaction histories module 508, and analysis tools module 510 operate the same as the corresponding modules in provider accounts 400A, 400B, 400N (FIG. 2), except that the functions are tailored to recipients. For example, reports module 506 would give the recipient access to reports about their spending history, behaviors, and categories of purchases, inter alia. Similarly and for example, transaction histories module 508 would give the recipient access to all transactions completed with all providers or for a given provider. Finally, analysis tools would provide a recipient with an analysis of spending habits and histories and could help the recipient budget, make grocery lists, manage warranties or rebates, and many other functions. Each recipient account 500A, 500B, 500N also includes a recipient demographics module 512 that solicits the recipient's demographics. For example, demographics module 512 causes the recipient to input an address, a birthday, family size, income, vocation, hobbies/interests or other personal data related to the recipient and the recipient's interests. According to embodiments, these data are stored in database 1010 and can be concatenated with each total transaction data set to augment the data generated at the POS and give providers and recipients more powerful data analysis tools.
According to embodiments, FIG. 4 illustrates various software modules comprising data capture system 1. According to the exemplary illustration, the various components of data capture system are executed on point of sale capture device 20, on remote server 10, and on recipient/provider computer 300. According to embodiments, each of these components are connected via the internet (e.g., via http, ftp, or other well known or proprietary communications protocols). According to embodiments, communications can be encrypted or unencrypted.
As illustrated according to exemplary embodiments, POS computer 200 comprises data capture module 2002 and data association module 2008. Data capture module 2002 comprises, according to embodiments, transaction data module 2004 and unique identifier module 2006. Transaction data module 2004 captures the details of a transaction. For example, at the start of a transaction, transaction data module 2004 records the date of the transaction and the time of the transaction in a local memory involved or XML file. Transaction data module 2004 also records an identifier of the provider's agent, the transaction, as well as a unique provider identifier. As the transaction proceeds, transaction data module 2004 further records each good or service purchased, the quantity of each good or service purchased, and the price of each good or service. Towards the conclusion of the transaction, data transaction module 2004 records the total amount tendered, the tax due, and the method of payment. According to the exemplary embodiments, data transaction module 2004 also records the credit card number of the recipient, if a credit card was tendered for payment as a primary or secondary unique identifier of the recipient. In this sense transaction data module 2004 captures data that is also applicable to data captured by unique identifier module 2006. Indeed, in actual practice, transaction data module 2004 and unique identifier module 2006 are the same software. However, they can be separate software as well, particularly in embodiments where POS computer 200 and unique identifier reader 210 are distinct hardware, each running software of their own.
According to embodiments, data capture module 2002 also comprises software for running various hardware components used in the transaction. Such hardware components comprise, for example, bar code scanners, input devices such as numeric key pads or cash register keyboards, credit card machines, provider or recipient displays for showing the prices of goods or services being purchased, etc. Data capture module 2002, according to embodiments, communicates with a provider maintained database to look up prices for each bar code scanned. According to other embodiments, transaction data module 2004 accomplishes these tasks. As explained above, the modular organization presented in FIG. 4 is intended to illustrate functions needed to practice data capture system; the organization is therefore intended to be exemplary and instructional rather than limiting.
According to embodiments where virtual printer 220 is used to capture transaction data, transaction data module 2004 is responsible for OCR of the document. After OCR is complete, transaction data module 2004 parses the data. Accordingly, data is recognized and categorized. For example, transaction data module may have a mask to interpret the contents of an OCRed virtual receipt. The mask will tell transaction data module 2004 where to look for the date, the register used for the transaction, etc. According to other embodiments, data transaction module 2004 parses the text and recognizes it based on preprogrammed parsing conventions (e.g., how the virtual receipt formats the date, time, prices, product identification, etc). Each of these data are stored locally temporarily (e.g. via database on XML file) until processed by data association module 2008.
According to embodiments, unique identifier capture module 2006 captures or interacts with hardware that captures the recipient's unique identifier and records it locally. For example, unique identifier capture module 2006 comprises software that interacts with or drives unique identifier reader 210. For example, where unique identifier reader 210 is an HID reader, unique identifier capture module 2006 interacts with the HID reader and records input to the HID reader. Moreover, according to embodiments, unique identifier capture module 2008 disambiguates multiple or inconsistent unique identifier as described above. Data captured by unique identifier capture module 2008 is stored in the same or different database or XML file as the transaction data.
According to embodiments, data association module 2008 combines the transaction data and the unique identifier and forms the total transaction data set. The total transaction data set comprises the data captured by transaction data module 2004, and the one or more unique identifiers captured during the course of the transaction. According to embodiments, data association module also “packages” the total transaction data into a form that is readable by server 100. For example, data association module takes transaction data parsed by transaction data module and formats it in appropriate fields into a specially server-formatted document that is transmitted to server 100 for data entry into database 1010.
Once the total transaction data set is captured, it is transmitted to server 100. According to embodiments, server comprises database 1010 and internet connection module 1040. As illustrated in the exemplary embodiment of FIG. 4, server also comprises data prioritization module 1020 or data mining module 1030.
Implementations of database 1010 are described above.
According to embodiments, data prioritization module 1020 prioritizes requests for server communications and processing bandwidth, for example. According to embodiments, transaction speed at the POS is highest priority for server 100 requests. Thus, POS computer 200 is given priority over other non-critical server processes or database access requests to expedite transactions at the POS. Thus, when using recipient/provider computer 300, greater lag will be experienced in obtaining access to database 1010 than when using POS computer 200. Similarly, overhead processes such as indexing and data mining are lower priority as well.
According to embodiments, data mining module 1030 comprises a process that aggregates and indexes data contained in database 1010 for more rapid retrieval. Data mining module performs analysis of data within database 1010. For example, data mining module 1030 comprises a recommendations engine for recommending products or services to recipients or product placement or advertising channels for providers, according to embodiments. According to other embodiments, data mining module 1030 analyzes data contained in database 1010 for trends. In essence, data mining module 1030 optimizes database content for viewing via recipient/provider computer 300 or for transmission to point of sale computer 200. Data mining is a low priority process, according to embodiments.
Internet connection module 1040 resides on server 100 and comprises internet back-end 1052 and internet front-end 1310. Internet front-end 1310 is illustrated as being part of recipient/provider computer 300 to better visualize where each module is “experienced.” However, artisans will readily appreciate that internet front-end 1310 is actually hosted on server 100 and recipient/provider computer 300 downloads a document such as a hypertext markup language (HTML) document from server 100, where it is hosted, to recipient/provider computer 3000 where it is displayed by a web browser. Proprietary display software is contemplated as well, in which case the document or raw data is transmitted via XML or other known or proprietary communications protocols.
According to embodiments, internet back-end 1052 is the bridge between the internet front-end 1310 and database 1010. According to embodiments, internet back-end 1052 comprises tools used to query database 1010 and outputs results to internet front-end 1310 for viewing by the recipient or provider. Internet back-end comprises, according to embodiments, a plurality of scripts (e.g., PHP langauge scripts) executable via internet front-end 1310 or automatically.
According to embodiments, internet front-end 1310 provides a user-friendly interface for interacting with server 100, and more specifically the data in database 1010. Internet front-end 1310 comprises, according to embodiments, one or more webpages designed as an interface to view data in database 1010. For example, a recipient would use internet front-end 1310 to login to her account and view a history of her most recent transactions, look at her spending trends, or look at the balance of her rewards points with a given provider. According to another example, a provider uses internet front-end 1310 to login to his account and view transaction details, from the performance of the sales of one product, to the most productive salesperson, to the demographics purchasing a product, to the relative success of an advertising campaign, and so forth. Internet front-end 1310 formats webpages containing the data and allows the recipient or provider to view the webpages in a browser. Internet front-end 1310 also provides the interface for the recipient to manage her account and input demographic information, as well as print coupons or otherwise interact with data capture system 1. Likewise, internet front-end 1310 provides the same basic account level functionality to provider, including account management, analytical tools, etc.
According to embodiments, application programming interface 1054 (API) allows for the development and implementation of usable features in third party webpages or applications 1320 that require access to data in database 1010 via internet back-end 1052. According to embodiments, API comprises a vocabulary and calling conventions for access to database 1010 via internet back-end 1054. The vocabulary and calling convention comprises at least one of protocols, objects, routines, data structures, etc. that enable a third party webpage or application developer to access data from database 1010 via internet back-end 1054.
According to embodiments and as illustrated in FIG. 5, a method for combining a recipient's demographic information with transaction data is described. As illustrated, transaction data is captured during a transaction between a recipient and a provider in operation 5010. At some point before, during, or after the transaction is completed, at least one unique identifier of the recipient is captured as described herein in operation 5020. The unique identifier data and transaction data are associated together to form a total transaction data set in operation 5030, which is recorded in database 1010 in operation 5040. In operation 5050, additional demographics are associated with the total transaction data set from the demographic information provided by the recipient. Operation 5050 is optional, according to embodiments, as an optimization to enhance efficiency in implementations of data capture system 1 that provides demographic information to recipients or providers for transactions. After the demographics are or are not, according to the particular implementation, associated in embodiments that associate the recipient's demographics with the total transaction data set, or after the total transaction data set is recorded in database 1010 for other embodiments, data from the database is provided to providers or recipients in operation 5060.
According to embodiments, the devices, systems, or methods disclosed herein are operational in an information technology infrastructure or with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, or configurations that may be suitable for use with the subject matter of this disclosure include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable recipient electronics, network PCs, minicomputers, mainframe computers, telephony systems, distributed computing environments that include any of the above systems or devices, or the like.
According to embodiments, the devices, systems, or methods disclosed herein are described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include, for example, routines, programs, objects, components, data structures, which perform particular tasks or implement particular abstract data types. The devices, systems, or methods disclosed herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media, including memory storage devices. The computer programs are stored in a memory medium or storage medium or they may be provided to a processing unit through a network or I/O bus.
According to embodiments, the devices, systems, or methods disclosed herein include at least one central processing unit (CPU) or processor. According to embodiments, the CPU is coupled to a memory, ROM, or computer readable media containing the computer-executable instructions for implementing a database or the systems disclosed herein, as well as performing the methods disclosed herein. The machine readable media may store instructions or data which implement all or part of the system or methods described herein. According to embodiments, machine readable media is any available media that can be accessed by the devices or systems disclosed herein, or by computers generally, and includes both volatile and nonvolatile media, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to: random access memory; read-only memory; EEPROM; flash memory; portable memory or other memory technology; CD-ROM, digital versatile disks (DVD), or other optical disk storage; magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices; or any other medium which can be used to store the desired information and which can be accessed by the data capture system disclosed herein.
Communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, or other wireless media. Combinations of any of the above should also be included within the scope of communications media.

Examples

Example 1

Use of Data Capture System in Manufacturer Product Distribution Management Including Warranty Registration

According to embodiments, data capture system 1 is provides an effective platform for handling warrantees from the provider or manufacturers to the recipients. For example, warranties for durable goods such as refrigerators, lawn mowers, etc can automatically be administered through use of data capture system 1.
According to embodiments, the manufacturer would require that its distributors or providers install and use data capture system 1, which would enable the manufacturer to gather real time information regarding when an item they manufacture is sold. It would also help the manufacturer better manage their supply chain. For example, ACME sells large quantities of lawn and garden equipment to ABC Hardware. ACME continues to produce equipment based on what it expects the market to sell. If, for example, ABC sells mainly walk behind mowers, but ACME has anticipated sales of small garden tractors, ACME would be over producing that small garden tractors. However, if ACME required ABC to utilize data capture system 1 at the point of sale, ACME could shift what is ordering from its suppliers and its build schedule to meet the market requirements in real time.
Moreover, by knowing exactly who has purchased the equipment, there would be no need for the recipient to fill out warranty information. Rather, warrant information could be transmitted to the manufacturer immediately. This information could be shared with ABC as well to establish a better relationship with the recipient. Product recalls could be done better as well as overall warranty handling.

Example 2

Use of Data Capture System with Companies with Multiple Chains

Companies with multiple chains, especially independent chains, could employ the data capture system 1. Using data capture system 1 in conjunction with each cash register would allow for better management of inventory and sales tracking. Companies would also generate real time data regarding the success of their marketing strategies.

Example 3

Use of Data Capture System in Hotels

According to embodiments, data capture system 1 can be used in hotels. For example, guests could be issued a card with an HID tag, such as an RFID tag, that would be linked to the data capture system 1. The guest could go from place to place within the hotel and be offered services, seamlessly confirming changes in real time. No keys or signatures would be required in the hotel at any point where a unique identifier reader could capture the guests HID. Management could also track these movements and re-allocate man-power and other resources immediately to areas having the most need.

Example 4

Use of Data Capture System in Hospitals

According to embodiments, data capture system 1 can be used in hospitals to track patients through the hospital, confirm identity of patients, guests, and staff, and improve patient flow. Moreover, data capture system 1 can be used in an inventory control context, in addition to the contexts described above to monitor and track equipment and help optimize utilization. Accordingly, various nodes would be placed throughout the hospital to track the patients, guests, staff, or equipment.
For example, RFID tags could be embedded into patient bracelets and staff identification badges. Guests could be issued temporary guest cards they would be required to carry on their person at all time while in the hospital. Likewise, equipment could be tagged. RFID reader nodes could be installed in doorways, hallways, and at other strategically useful points for tracking the people and inventory. Consequently, at any given time, data capture system 1 could be used to track specific users—for example, for a woman who is in labor, data capture system 1 could be used to immediately locate her husband who is out getting a snack.
Artisans will readily recognize that in the context of a hospital, each tracking event of a person, staff, guest, or equipment comprises a transaction. In this case, the provider would be considered the hospital and the recipient the patient, guest, staff, or piece of equipment.
While the apparatus and method have been described in terms of what are presently considered to be practical and effective embodiments, it is to be understood that the disclosure need not be limited to the disclosed embodiments. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures. The present disclosure includes any and all embodiments of the following claims.

Claims

1. A system comprising:

a data capture module that captures transaction data related to a transaction and a unique identifier of a recipient;

a data association module that associates the transaction data and the unique identifier;

a database for storing the associated transaction data and unique identifier disposed on a server; and

an internet module.

2. The system of claim 1, further comprising a data mining module.

3. The system of claim 1, further comprising a data prioritization module that prioritizes connections to the database.

4. A method comprising using a computer to:

capture a unique identifier of a recipient;

capture transaction data related to a transaction between the recipient and a provider;

associate the unique identifier with the transaction data to form a total transaction data set;

record the total transaction data set in a database; and

provide the data related to one or more transaction to a user via an internet module;

wherein the associated unique identifier and transaction data are recorded whereby the total transaction data are associated with at least one of a provider account or a recipient account.

5. The method of claim 4, further comprising recording demographic data from each recipient and associating the demographic data with the recipient's unique identifier.

6. The method of claim 5, wherein the demographic data comprises at least one of: age, gender, income, address, family size, and hobbies/interests.

7. The method of claim 4, further comprising causing the total transaction data to be organized for rapid access to information.

8. The method of claim 4, wherein access to the database is prioritized whereby information submitted from or transmitted to a point of sale receives the highest priority.

9. The method of claim 4, further comprising associating a unique identifier for at least one good or service into the total transaction data.

10. The method of claim 9, wherein the provider is a manufacturer, and wherein the manufacturer is not provided with total transaction data related to goods or services that were part of the transaction from other manufacturers.

11. The method of claim 4, wherein each transaction comprises a series of sub-transactions, and wherein the total transaction data of each sub-transaction is captured as an individual transaction.

12. A machine-readable medium having instructions stored thereon for, on a computer:

associating a recipient with a unique identifier;

collecting demographic information from the recipient;

capturing a unique identified of the recipient at the point of sale of a transaction;

capturing transaction data related to the transaction between the recipient and a provider at the point of sale;

associating the unique identifier with the transaction data to form a total transaction data set;

recording the associated unique identifier and transaction data in a database; and

further associating the total transaction data set with demographic information collected from the recipient.

13. The machine-readable medium of claim 12, further comprising recording demographic data from each recipient and associating the demographic data with the recipient's unique identifier.

14. The machine-readable medium of claim 13, wherein the demographic data comprises at least one of: age, gender, income, address, family size, and hobbies/interests.

15. The machine-readable medium of claim 12, further comprising causing the total transaction data to be organized for rapid access to information.

16. The machine-readable medium of claim 12, wherein access to the database is prioritized whereby information submitted from or transmitted to a point of sale receives the highest priority.

17. The machine-readable medium of claim 12, further comprising associating a unique identifier for at least one good or service into the total transaction data.

18. The machine-readable medium of claim 17, wherein the provider is a manufacturer, and wherein the manufacturer is not provided with total transaction data related to goods or services that were part of the transaction from other manufacturers.

19. The machine-readable medium of claim 12, wherein each transaction comprises a series of sub-transactions, and wherein the total transaction data of each sub-transaction is captured as an individual transaction.