Implementations generally relate to sales by manufacturers, and more particularly to a recall of a product sold by a manufacturer.
Manufacturers who recall a product go through a laborious, expensive process in attempts to contact customers who are likely to have purchased its products in order to let them know that the product has been recalled, should be returned, and/or is not safe to use or consume. Manufacturers are often challenged to identify the consumers who purchased the lot, batch or order of the product that has been recalled, typically because, for most products, consumers have been registered their purchase with the manufacturer.
Manufacturers currently use mass media messages (television, radio, newspapers and magazines, the Internet), direct mail and phone contact to reach out to consumers, to alert them to a product's recall, and to request that the consumer return the product in question and/or stop using the product. Such prior art product recall notification methodologies are not rapid in warning a specifically targeted consuming public about a specific product that has been recalled, often at substantial peril for public safety. For instance, when a manufacturer would like to send out an emergency notice that a certain food item that it has put into the stream of commerce has been recalled for public safety reasons, the length of a delay in providing an effective notice to those consumers who purchased and are likely to consume the food item may result in a corresponding increase in a risk of sickness and death. Accordingly, the sooner that effective notice is given to specifically targeted consumers, even up to the stopping of a transaction in real time at a merchant's Point of Service terminal during a purchase of the recalled product by a consumer, may be significant enhancement to public safety.
Prior art product recall notification methodologies are inefficient, resulting in a low number of effective notices being delivered to the proper consumers, and realizing a substantial expense incurred by the manufacturer for an insubstantial return in making the proper consumers aware of a public safety issue. Accordingly, it would be an advance in the relevant art to provide product recall methodologies that reduces the foregoing problems.
In one implementation, a product recall service communicates via a network to facilitate real time electronic product recall alerts generated from transactional data acquired at Point of Service terminals and prior registrations of account holders with the product recall service. Each electronic alert is sent either to an account holder who purchased a recalled product on an account issued to them by an issuer, or to the issuer for delivery to their account holders who purchased a recalled product on an account issued by the issuer.
In yet another implementation, a plurality of different recall notices from a plurality of different suppliers of a plurality of different recalled products are received. For transactions conducted with a plurality of different merchants on a plurality of different accounts issued to a plurality of different account holder by a plurality of different issuers, where each transaction identifies a purchased item, a comparison is made of an identifier for each of the purchased items of the transactions with an identifier for each of the recalled products to identify each said transaction where the purchased item was one of the recalled products. For each item purchased in each transaction that corresponds to each of the recalled products, a recall message is sent to a logical address. The logical address can be that of each issuer of each account that was used to conduct one of the transactions to purchase one of the recalled products. The logical address can be that of each account holder of each account that was used to conduct one of the transactions to purchase one of the recalled products. A fee can be assess to each supplier of each recalled product for use of a recall notification service. Where the issuer sends recall notifications to each of its account holders who purchased a recalled product on an account issued to them by the issuer, a portion of each such supplier-paid fee can be paid to issuer of each account used to conduct one of the transactions to purchase one of the recalled products. An account holder receiving a recall notification can interactively communicate with the supplier of the recalled product to send and receive information provider about the recall product.
In still another implementation, a product recall service communicates via a network to facilitate real time electronic alerts generated from transactional data acquired at Point of Service terminals and prior registrations of account holders with the product recall service. Each electronic alert is sent either to an account holder who purchased a recalled product on an account issued to them by an issuer, or to the issuer for delivery to their account holders who purchased a recalled product on an account issued by the issuer.
Implementations will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like elements bear like reference numerals.
Implementations of a product recall service provide cost effective notifications to consumers that a product they have purchased has been recalled by the manufacturer. In one implementation, manufacturers or suppliers of products manufactured by others, merchants and account holders would be registered as participants in a Product Recall Service (PRS). Each participating merchant would send, for delivery to the PRS, transaction data sufficient to identify each account holder making a purchase from the merchant and their purchased items. Each such purchased item would be part of a transaction conducted on an account issued to the account holder by an issuer, where the transaction was conducted by the merchant with the account holder. Payment to the merchant for the transaction would be authorized by the issuer to the merchant's acquirer, and would be cleared and settled through a payment processing system as discussed below with respect to
Upon notice received by the PRS from a participating supplier, where the notice identifies the supplier's recalled product, the PRS would match the recalled product against transaction data accumulated from participating merchant's transactions in order to locate those participating account holders who had purchased the recalled product. For each such match, contact information about the matching participating account holders would be used to send a notice. This notice would identify the recalled product and contain a product recall message that the supplier would like to send to the account holders who had purchased the recalled product. The notice may also contain a request from the supplier to the account holders to return the product for a refund, for instance, by providing a phone number or e-mail address for account holders to contact the supplier or its agent. The notice may also provide an Internet address, which may be hosted by the PRS, at which the account holders can give and receive information about the recalled product. Such data, as was given to and received from account holders, can then be passed on to the supplier, or its agent, by the PRS.
Advantageously, the PRS need not make contact with a participating merchant every time a recall happens, and the merchant's acquirer need not be required to gather and match data against account holders who purchased a recalled product from the merchant. Rather, the merchant sends, for delivery to the PRS, transaction data information for items purchased in transactions by account holders, regardless of whether each such item has been recalled. Upon receipt, the PRS stores such transaction data along with data sufficient to identify, and derive contact information for, each account holder that is privy to each such transaction.
When a participating supplier announces a product recall to the PRS, there is no need to contact either the merchant or its acquirer in order to provide effective notice to the relevant account holders who had previously purchased the recalled product. As such, network traffic to both the merchant and its acquirer are not substantially increased by each product recall. Moreover, implementation costs to the acquirer are not substantial in working with the PRS to facilitate product recall notices to account holders.
Participating merchants acquire data at the time of each transaction with each account holder sufficient to identify both the account holder and each item purchased in the transaction. Such data may include, for the account holder, an account identifier issued by an issuer to the account holder, a transaction identification number for the transaction, the date and time of the transaction, a Point of Service terminal (POS) identifier, etc. Such data may include, for the item being purchased in the transaction, ‘level three’ data, product level data, or other data such as a Stock Keeping Unit (SKU), a Universal Product Code (UPC), a supplier's serial number, a supplier's batch and lot identifier, date and location of manufacture, etc.
These POS data can be sent directly to the PRS, or can be sent for delivery to the PRS via the merchant's acquirer and a transaction handler. These POS data can be send in real time, or periodically in batch mode, and need not be part of a clearing and settlement process for the collection of the merchant's payment for a transaction.
Advantageously, the PRS provides an incentive for account holders to be loyal to those merchants who receive and send such product level data as it enables account holders to enrich their participation in the PRS. Similarly, suppliers may be more favorably disposed to such merchants, or their acquirers, because of their capabilities as PRS participants.
In the event that a participating account holder has one or more accounts that are closed or otherwise become unusable for future transactions, the PRS can be so notified of such an event by its account holder, by its issuer, or by a credit rating service (i.e.; Experian, TransUnion, Equifax, etc.) that keeps credit histories based on social security numbers or other globally unique identifiers for consumers. Also, the PRS may detect inactivity in the account for a predetermined time threshold. In such cases, the PRS can attempt to contact the participating account holder to continue the recall service, and retain the accumulated data about products purchased by the account holder, despite the closing or lack of future usefulness of the account holder's account.
In one implementation, an account holder can self register with the PRS for some or all of the accounts that they hold such that the respective issuers of these accounts need not register the account holder with the PRS. Moreover, the account holder can continually update the PRS with purchases of products made at non-participating merchants, as well as continually updating their contact information along with chronologically opened and closed account information. These updates enable the PRS to retain product purchase information about the participating account holder which can be used to timely notice of product recalls to participating account holder. Self registration by an account holder, and ongoing maintenance of account holder information, can be accomplished, for instance, by an online registration service, such as at a website hosted by the PRS or its agent. Accordingly, self registration allows an account holder to be free of its issuers and still be notified of about its purchased products that have been recalled, even if the account holder no longer has a banking relationship with an issuer who issued an account to the account holder upon which a recalled product was purchased. Accordingly, and for example, such an account holder may receive a product recall notice many years after the recalled product was purchased by the account holder, even though the account used by the account holder to purchase the product was closed many year ago. Advantageously, data acquired and maintained by the PRS can be mined for other purposes beneficial to registered participants with the PRS. For instance, a participating supplier may want to send a notice of all participating account holders residing in a particular geographic area who have purchased its participating products, such as to announce a special event at on a particular date and time in that geographic area. As such, the PRS can perform various functions and serve in various capacities as may have been previously performed by a supplier product registration service by which a consumer would have registered purchases of the supplier's goods with the supplier.
In one implementation, a web-based registration system could be used for suppliers to provide the information on the recalled products (e.g.; SKU, UPC, etc.) and the recall notification message contents. Other entities would also use this web-based system to register their participation in the PRS, as well as for other services such as receiving reports made available via this interface (e.g.; related billing and operational information pertaining to PRS participants).
Referring to
In step 206, corresponding to arrows labeled ‘2’ in
In step 208, corresponding to arrows labeled ‘3’ in
In step 210, corresponding to arrows labeled ‘4’ in
In step 212, corresponding to arrows labeled ‘5’ in
In step 214, corresponding to arrows labeled ‘6’ in
In step 216, the transaction handler, the PRS, or their agent, collects a fee from the supplier for product recall message delivery services and distributes all or respective portions thereof to each participating entity that assisted in the product recall message delivery service. By way of example, the fee can be a product recall service fee that is collected from a supplier of a product that has been recalled product. A portion of each such product recall service fee can been be paid to each issuer who had issued an account that was used by an account holder to purchase the corresponding recalled product. The issuer can send a recall notice to each such account holder, where the fee received by the issuer can be deemed to be compensation for such product recall notifications to its account holders.
In step 218, corresponding to arrows labeled ‘7’ in
Referring to
In step 406, corresponding to arrows labeled ‘2a’ and ‘2b’ in
In step 408, corresponding to arrows labeled ‘3’ in
In step 410, corresponding to arrows labeled ‘4’ in
In step 412, corresponding to arrows labeled ‘5’ in
Alternatively, the recall notification verbiage can also include an identifier that uniquely identifies the account holder to whom the recall notification verbiage was sent, also known as the account holder's Globally Unique Identifier (GUID). When the account holder contacts the PRS, the account holder's GUID can be supplied to the PRS so that the PRS can associate the account holder with a product that had been recalled (e.g.; see reference numeral 520 in screen shot 500 of
In step 416, corresponding to arrows labeled ‘6’ and ‘7’ in
The account holder can input a personal injury report 514 and/or a property damage report 516 on display screen 500. With receipt of input from the account holder on display screen 500, the PRS can assign a recalled product incident GUID 518 that is communicated for future reference to the supplier. Optionally, the account holder's GUID 520 may be auto-populated or can be supplied as input the account holder. Recalled product supplier verbiage 522, and an image of the recalled product 524, as may be suggested by the supplier of the recalled product, may be rendered on display screen 500. A user of a web-enable device that renders the display screen 500 may scroll the rendered imaged horizontally by using virtual navigation tool 502 and vertically by using virtual navigation tool 504 as in common in interactive applications
Exemplary Payment Processing System
Payment processing system 600 has a plurality of issuers (1-i) 604. Each issuer (i) 604 may be assisted in processing one or more transactions by a corresponding agent issuer (ai) 604, where ‘i’ can be an integer from 1 to I, where ‘ai’ can be an integer from 1 to AI, and where I and AI can be as large as an eight digit integer or larger. Payment processing system 600 has a plurality of acquirers (q) 606. Each acquirer (q) 606 may be assisted in processing one or more transactions by a corresponding agent acquirer (aq) 606, where ‘q’ can be an integer from 1 to Q, where aq can be an integer from 1 to AQ, and where Q and AQ can be as large as a eight digit integer or larger.
The transaction handler 602 may process a plurality of transactions within the payment processing system 600. The transaction handler 602 can include one or a plurality or networks and switches (ns) 602. Each network/switch (ns) 602 can be a mainframe computer in a geographic location different than each other network/switch (ns) 602, where ‘ns’ is an integer from one to NS, and where NS can be as large as a four digit integer or larger.
Dedicated communication systems 620, 622 (e.g., private communication network(s)) facilitate communication between the transaction handler 602 and each issuer (i) 604 and each acquirer (a) 606. The Network 612, via e-mail, the World Wide Web, cellular telephony, and/or other optionally public and private communications systems, can facilitate communications 622a-622e among and between each issuer (i) 604, each acquirer (a) 606, each merchant (m) 610, each account holder (a) 608, and the transaction handler 602. Alternatively and optionally, one or more dedicated communication systems 624, 626, and 628 can facilitate respective communications between each acquirer (a) 606 and each merchant (m) 610, each merchant (m) and each account holder (a) 608, and each account holder (a) 608 and each issuer (i) 604, respectively. Product Recall Service 630, implementations of which are described above with respect to
Merchant (m) 610 may be a person or entity that sells goods and/or services. Merchant (m) 610 may also be, for instance, a supplier, a distributor, a retailer, a load agent, a drugstore, a grocery store, a gas station, a hardware store, a supermarket, a boutique, a restaurant, or a doctor's office. In a business-to-business setting, the account holder (a) 608 may be a second merchant (m) 610 making a purchase from another merchant (m) 610. Merchant (m) 610 may utilize at least one point-of-interaction terminal (e.g., Point of Service or browser enabled consumer cellular telephone) that can communicate with the account user (au) 608, the acquirer (a) 606, the transaction handler 602, or the issuer (i) 604. Thus, the point-of-interaction terminal is in operative communication with the payment processing system 600.
Typically, a transaction begins with account user (au) 608 presenting the portable consumer device to the merchant (m) 610 to initiate an exchange for a good or service. The portable consumer device may be associated with an account (e.g., a credit account) of account holder (a) 608 that was issued to the account holder (a) 608 by issuer (i) 604.
The portable consumer device may be in a form factor that can be a payment card, a gift card, a smartcard, a smart media, a payroll card, a healthcare card, a wrist band, a machine readable medium containing account information, a keychain device, such as a SPEEDPASS® device commercially available from ExxonMobil Corporation, a supermarket discount card, a cellular telephone, personal digital assistant, a pager, a security card, an access card, a wireless terminal, or a transponder. The portable consumer device may include a volatile or non-volatile memory to store information such as the account number or an account holder (a) 608's name.
Merchant (m) 610 may use the point-of-interaction terminal to obtain account information, such as a number of the account of the account holder (a) 608, from the portable consumer device. The portable consumer device may interface with the point-of-interaction terminal using a mechanism including any suitable electrical, magnetic, or optical interfacing system such as a contactless system using radio frequency or magnetic field recognition system or contact system such as a magnetic stripe reader. The point-of-interaction terminal sends a transaction authorization request to the issuer (i) 604 of the account associated with the portable consumer device. Alternatively, or in combination, the portable consumer device may communicate with issuer (i) 604, transaction handler 602, or acquirer (a) 606.
Issuer (i) 604 may authorize the transaction and forward same to the transaction handler 602. Transaction handler 602 may also clear the transaction. Authorization includes issuer (i) 604, or transaction handler 602 on behalf of issuer (i) 604, authorizing the transaction in connection with issuer (i) 604′s instructions such as through the use of business rules. The business rules could include instructions or guidelines from the transaction handler 602, the account holder (a) 608, the merchant (m) 610, the acquirer (a) 606, the issuer (i) 604, a related financial institution, or combinations thereof. The transaction handler 602 may maintain a log or history of authorized transactions. Once approved, the merchant (m) 610 may record the authorization, allowing the account user (au) 608 to receive the good or service from merchant (m) or an agent thereof.
The merchant (m) 610 may, at discrete periods, such as the end of the day, submit a list of authorized transactions to the acquirer (a) 606 or other transaction related data for processing through the payment processing system 600. The transaction handler 602 may compare the submitted authorized transaction list with its own log of authorized transactions. The transaction handler 602 may route authorization transaction amount requests from the corresponding the acquirer (a) 606 to the corresponding issuer (i) 604 involved in each transaction. Once the acquirer (a) 606 receives the payment of the authorized transaction from the issuer (i) 604, the acquirer (a) 606 can forward the payment to the merchant (m) 610 less any transaction costs, such as fees for the processing of the transaction. If the transaction involves a debit or pre-paid card, the acquirer (a) 606 may choose not to wait for the issuer (i) 604 to forward the payment prior to paying merchant (m) 610.
There may be intermittent steps in the foregoing process, some of which may occur simultaneously. For example, the acquirer (a) 606 can initiate the clearing and settling process, which can result in payment to the acquirer (a) 606 for the amount of the transaction. The acquirer (a) 606 may request from the transaction handler 602 that the transaction be cleared and settled. Clearing includes the exchange of financial information between the issuer (i) 604 and the acquirer (a) 606 and settlement includes the exchange of funds. The transaction handler 602 can provide services in connection with settlement of the transaction. The settlement of a transaction includes depositing an amount of the transaction settlement from a settlement house, such as a settlement bank, which transaction handler 602 typically chooses, into a clearinghouse, such as a clearing bank, that acquirer (a) 606 typically chooses. The issuer (i) 604 deposits the same from a clearinghouse, such as a clearing bank, which the issuer (i) 604 typically chooses, into the settlement house. Thus, a typical transaction involves various entities to request, authorize, and fulfill processing the transaction.
The payment processing system 600 will preferably have network components suitable for scaling the number and data payload size of transactions that can be authorized, cleared and settled in both real time and batch processing. These include hardware, software, data elements, and storage network devices for the same. Examples of payment processing system 600 include those operated, at least in part, by: American Express Travel Related Services Company, Inc; MasterCard International, Inc.; Discover Financial Services, Inc.; First Data Corporation; Diners Club International, LTD; Visa Inc.; and agents of the foregoing.
Each of the network/switch (ns) 602 can include one or more data centers for processing transactions, where each transaction can include up to 100 kilobytes of data or more. The data corresponding to the transaction can include information about the types and quantities of goods and services in the transaction, information about the account holder (a) 608, the account user (au) 608, the merchant (m) 610, tax and incentive treatment(s) of the goods and services, coupons, rebates, rewards, loyalty, discounts, returns, exchanges, cash-back transactions, etc. By way of example, network/switch (ns) 602 can include one or more mainframe computers (e.g., one or more IBM mainframe computers) for one or more server farms (e.g., one or more Sun UNIX Super servers), where the mainframe computers and server farms can be in diverse geographic locations. Each issuer (i) 604 (or agent issuer (ai) 604 thereof) and each acquirer (a) 606 (or agent acquirer (aq) 606 thereof) can use or more router/switch (e.g., Cisco™ routers/switches) to communicate with each network/switch (ns) 602 via dedicated communication systems.
Transaction handler 602 can store information about transactions processed through payment processing system 600 in data warehouses such as may be incorporated as part of the plurality of networks/switches 602. This information can be data mined. The data mining transaction research and modeling can be used for advertising, account holder and merchant loyalty incentives and rewards, fraud detection and prediction, and to develop tools to demonstrate savings and efficiencies made possible by use of the payment processing system 600 over paying and being paid by cash, or other traditional payment mechanisms.
The VisaNet® system is an example component of the transaction handler 602. Presently, the VisaNet® system is operated in part by Visa Inc. As of 2007, the VisaNet® system Inc. was processing around 500 million transaction daily, on over 1 billion accounts used in over 170 countries. Financial instructions numbering over 16,000 connected through the VisaNet® system to around 30 million merchants (m) 610. In 2007, around 81 billion transactions for about 4 trillion U.S. dollars were cleared and settled through the VisaNet® system, some of which involved a communication length of around 24,000 miles in around two (2) seconds.
Advantageously, Product Recall Service 630, via the network 612, can facilitate real time alerts that can be generated from POS transactional data and prior registrations of account holders with Product Recall Service 630. These ‘e-alerts’ provide both consumer safety and limitations on products liability of manufacturers, and suppliers such as distributors and wholesalers, and retailers by providing real time warnings. Each such warning can include information about defective and dangerous products that have been purchased by a consumer, and the warning or e-alert can be electronically delivered to a logical address of the consumer or the issuer of an account of the consumer, such as via a cellular telephone or a mobile web enable computing device.
The various steps or acts in a method or process may be performed by hardware executing software, and may be performed in the order shown, or may be performed in another order. Additionally, one or more process or method steps may be omitted or one or more process or method steps may be added to the methods and processes. An additional step, block, or action may be added in the beginning, end, or intervening existing elements of the methods and processes. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods for various implements. Moreover, it is understood that a functional step of described methods or processes, and combinations thereof can be implemented by computer program instructions that, when executed by a processor, create means for implementing the functional steps. The instructions may be included in computer readable medium that can be loaded onto a general purpose computer, a special purpose computer, or other programmable apparatus.
It is understood that the examples and implementations described herein are for illustrative purposes only and that various modifications or changes in light thereof will be suggested to persons skilled in the art and are to be included within the spirit and purview of this application and scope of the appended claims.
CROSS-REFERENCE TO RELATED FILES This application claims priority to, and the benefit of, U.S. Application Ser. No. 61/174,402, titled “Product Recall Service,” filed on Apr. 30, 2009, and to U.S. Application Ser. No. 61/293,359, titled “Product Recall Service,” filed on Jan. 8, 2010, both of which are incorporated herein by reference.
Number | Date | Country | |
---|---|---|---|
61174402 | Apr 2009 | US | |
61293359 | Jan 2010 | US |