WO2009094482A1

WO2009094482A1 - Systems and methods to facilitate buying via a phone call

Info

Publication number: WO2009094482A1
Application number: PCT/US2009/031733
Authority: WO
Inventors: Christopher Coleman; Michael Sharp; Matthew Kaufman
Original assignee: Bandtones LLC
Current assignee: Bandtones LLC
Priority date: 2008-01-24
Filing date: 2009-01-22
Publication date: 2009-07-30
Anticipated expiration: 2010-07-24

Abstract

Disclosed systems to facilitate buying via a phone call by enabling a consumer to obtain product or service information via a text-message based search service. The service provides names and descriptions of products and services that are responsive to a search inquiry, and may further provide price and availability information along with a unique phone number for each identified product and service. A user can autodial a selected phone number to hear more information. The caller can then purchase the product or service by pressing a key or voicing an instruction. The Caller ID/ANI information is captured and used to identify the payer when sending a request for a payment transaction to an online payment processing service. Upon receiving verification, the payment processing service debits the caller's account or adds a charge to the caller's phone bill before responding to the payment transaction request with a confirmation message.

Description

Systems and Methods to Facilitate Buying Via a Phone Call

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] The present application claims priority to the following patent applications, each of which is hereby incorporated herein by reference:

Provisional U.S. Pat. App. 61/023,366, entitled "Systems and Methods to Facilitate Buying Via a Phone Call" and filed Jan. 24, 2008 by inventors M. Sharp, C. Coleman, and M. Kaufman.

U.S. Patent App. 11/877,612, entitled "Phonecasting Systems and Methods" and filed Oct. 23, 2007 by inventors M. Kaufman, M. Sharp, and C. Coleman, which in turn claims priority to Provisional U.S. Patent App. 60/862,755, entitled "Method Allowing Telephone Callers To Hear Multimedia Files Syndicated On Or Otherwise Distributed Via The Internet" and filed October 24, 2006, by inventor Matthew Kaufman.

[0002] The present application further relates to the following applications, each of which is incorporated herein by reference:

U.S. Patent App. 61/018,932, entitled "Phonecasting Referral Systems and Methods" and filed Jan. 4, 2008 by inventor M. Sharp; and

U.S. Patent App. 61/018,913, entitled "Method and Apparatus for Delivering Audio Content to a Caller Placed on Hold" and filed Jan. 4, 2008 by inventor M. Sharp.

BACKGROUND

[0003] Consumers benefit from competing sellers. Such competition provides an incentive for sellers to improve their products and services and/or appeal to potential customers in other ways.

- i - Sellers are rewarded by increased sales revenue or profit, and buyers benefit from the existence of sellers that cater to their needs.

[0004] One way for sellers to appeal to potential customers is to reduce the effort or cost associated with a sales transaction. Thus, sellers that provide retail outlets near a customer's place of residence or business will have an increased appeal to that customer. As another example, sellers that operate in shopping malls enable customers to complete multiple purchases in a single trip, thereby reducing that customer's overall effort. Mail-catalog retailers and online retailers exploit yet other ways to reduce a customer's shopping effort. In each of these examples, the seller should expect to benefit from his/her increased customer appeal relative to other sellers.

BRIEF SUMMARY

[0005] Accordingly, there is disclosed herein various systems and methods to facilitate buying via a phone call. In some system embodiments, a consumer can obtain product or service information via a text-message based search service. The service may provide names and descriptions of products and services that are responsive to a search inquiry, and may further provide price and availability information for each such produt or service. Preferably, the service further provides a unique phone number for each of the products and services responsive to the search inquiry. A user, upon receiving a text message containing the results of his or her search inquiry, can select the phone number for the product or service about which more information is desired. Most mobile phones provide autodialing for phone numbers selected in this manner, enabling the user to easily call the phone number and hear additional information about the product or service. Some system embodiments further enable the caller to purchase the product or service by pressing a key or voicing an instruction. In such system embodiments, the Caller ID/ ANI information is captured and used to identify the payer when sending a request for a payment transaction to an online payment processing service. Typically, though not necessarily, the online payment processing service sends a text message to the payer requesting approval for the transaction. Upon receiving such approval, the payment processing service debits the caller's account or adds a charge to the caller's phone bill before responding to the payment transaction request with a confirmation message. Upon receiving the confirmation message, embodiments of the disclosed systems and methods issue a delivery request to an online retailer or service provider, and complete the ordering process when delivery acknowledgement is provided. The online retailer or service provider may bill the system operator and receive payment from the system operator in the normal fashion.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] A better understanding of the various disclosed embodiments can be obtained when the detailed description is considered in conjunction with the following drawings, in which: [0007] Fig. 1 is an environmental view of an illustrative information and purchasing system; [0008] Fig. 2 is a functional block diagram of an illustrative purchasing system server; [0009] Fig. 3 is a function block diagram of illustrative information and purchasing system software;

[0010] Fig. 4 is a flowchart of an illustrative product/service purchasing method; [0011] Fig. 5 is a flowchart of an illustrative directory service method; [0012] Fig. 6 is a flowchart of an illustrative information playback method; [0013] Fig. 7 is a flowchart of an illustrative order servicing method; [0014] Fig. 8 is a flowchart of an illustrative information feed configuration method; and [0015] Fig. 9 is a flowchart of an illustrative information feed recording method. [0016] While the disclosed inventions are susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the inventions to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the inventions as defined by the appended claims.

TERMINOLOGY

[0017] The term "feed" as used herein refers to a program, presentation, or other content made available for transmission or conveyance via the Internet. A feed can exist in various forms, including a podcast, a song or other fixed sound file, a periodically updated sound file, and a live media stream. A feed is not necessarily publicly accessible via the Internet. [0018] The term "phonecast," when used herein as a noun, refers to a feed that can be accessed with a phone over the public switched telephone network (PSTN) and/or over a voice over internet protocol (VoIP) channel. When used herein as a verb, the term "phonecast" refers to the transmission or conveyance of a feed over a VoIP or PSTN channel to a phone. [0019] The term "includes" as used herein is an open-ended term, as in "including, but not limited to".

DETAILED DESCRIPTION

[0020] In the related applications incorporated by reference at the beginning of this application, the present inventors disclose systems and methods for phonecasting, i.e., playing audio feeds such as podcasts over the phone. The disclosed phonecasting systems provide a platform for making an unlimited number of feeds each accessible via a unique corresponding phone number. One potential application for this platform is product and service information. A manufacturer, advertiser, retailer, or service provider, can create an audio feed for each product or service that they provide. (As explained further below, these audio feeds may be syndicated as RSS feeds to facilitate updating the content of each feed.) Each such feed is then associated with a phone number that can be printed on or otherwise associated with the product or service. A consumer, upon viewing the product or an associated advertisement, can call that number from a convenient mobile phone or landline to listen to the audio feed for that product. The feed may include a description of the product or service performance, features, options, prices, availability, customer reviews, incentive programs, and/or other pertinent information.

[0021] A phonecasting system configured in the foregoing manner can be used as a component in a larger system for facilitating purchases over the phone. Among other things, the larger system may demonstrate certain novel features that significantly facilitate a customer's purchase transaction. One novel facilitation feature is a product directory that lists individual products and services with their associated phone numbers (rather than the phone numbers of businesses or individuals). Advantageously, this product directory can be accessed via a text message search utility in addition to the normal directory access techniques (e.g., printed index, web browser, operator assistance).

[0022] Another novel facilitation feature is an easy-order method involving as little as one button-push to have the featured product or service delivered to the listener after a simple billing confirmation (multiple examples of which are provided below). In some system variations, the telephony system may accept voice input such as "I want one" or "Send me two" in lieu of the button press. In yet other embodiments, the requirement for a button-press may be omitted entirely, with the billing confirmation action being initiated by the phone call itself. As will become evident further below, the easy-order method should be expected to require less effort by the consumer than other single-item purchasing methods, in large part because the customer need not personally recall and supply billing information or product id numbers. [0023] Turning now to the figures, Fig. 1 shows an illustrative information and purchasing system (IPS) in context. The public switched telephone network (PSTN) 102 includes a hierarchy of switches 104-110 and communication links to interconnect customer provided equipment (CPE) such as cell phones 112, "land- line" phones 114, and modems (represented by computer 116, with attached monitor 118 and keyboard 120). Internet gateways 122 couple the PSTN 102 to the Internet 124, enabling modems 116 to connect to the Internet via the PSTN 102. The Internet gateways 122 support the transmission of Internet Protocol (IP) data packets over telephone lines. A telephony server 126 also couples to the PSTN 102 to initiate and receive phone calls for voice communications. Often (though not necessarily) the Internet gateways 122 and telephony server 126 each connect to the PSTN 102 via a trunk line that supports multiple simultaneous calls.

[0024] The telephony server 126 also couples to the Internet 124 to optionally send and receive streams of audio data. Alternatively, sound files can be played and recorded internally by telephony server 126. Telephony server 126 may be an Asterisk™ server (or a farm of such servers), the setup and operation of which is described in detail in J. Van Meggelen, J. Smith, and L. Madsen, Asterisk: The Future of Telephony, © 2005 O'Reilly Media, Inc., Farnham. [0025] Both the PSTN 102 and the Internet 124 are represented in simplified form. In practice, each network is a complex network of interconnected processing nodes and switches that serve to carry voice and data traffic, and in many cases, the PSTN and Internet networks overlap. Fig. 1 represents the interconnectedness of various Internet servers with a single bus 128, but in practice bus 128 is implemented by an array of switches and network links such as, e.g., Ethernet or Infiniband connections. For the purposes of this disclosure, it is sufficient to recognize that the various servers are readily able to exchange information-carrying messages. [0026] Together with the telephony server 126, the illustrative information and purchasing system (IPS) includes a directory server 130, a database server 132, one or more feed servers 134, a front end server 136, and a download server 138. The infrastructure that the IPS interacts with includes one or more payment processing servers 140, a sales transaction server for a mobile service provider 136, and Internet transaction servers for one or more retailers 144. Though the illustrative system is shown as having individual servers for separate functions, these functions can be consolidated and/or distributed as needed to provide the appropriate server capacity.

[0027] Directory server 130 services requests for phone numbers associated with specific products and/or services, possibly further characterized by a specific provider, manufacturer, advertiser, or retailer. In some embodiments, the requests are accepted in the form of text messages (e.g., emails or SMS messages) containing names and/or keywords. As one example a cell phone user may send an SMS message saying "WMT iPod" to 44636 (the number associated with 4INFO.net, a text message search service). In one contemplated implementation, the directory server would recognize WMT as a keyword for WalMart product database, and would send a query to that database to retrieve a list of items having "iPod" in the product description. For each item in the list, the contemplated database would provide the product name, the price, the product availability (e.g., "In Stock", "On Backorder", "Discontinued"), and the phone number associated with that product. The directory server would then package the response into a reply message to the cell phone user, who could then select the phone number for autodialing to hear an audio description of the product. Directory server 130 is preferably a central directory that is able to pull phone number information from many different sources. In another contemplated embodiment, the directory server 130 queries database server 132 for a list of feeds having the desired keyword(s) in their title and provides the resulting list of phone numbers to the cell phone user.

[0028] Database server 132 associates audio feeds with phone numbers, but may also track introductory messages to be played before a feed and "outro" messages to be played after a feed. The feeds may take the form of RSS syndicated programs made accessible by one or more RSS servers 134. The large number of feeds, in conjunction with their dynamic, ever-changing nature, makes it unlikely that the various feeds will be readily available in one location. Consequently, a download server 138 monitors the various feeds for changes and retrieves the latest version to a central location for ready accessibility. In some embodiments, the download server 138 also issues one or more notification messages when new content is downloaded. The notification may go to the database server 132, which in turn sends messages to all the subscribers who have requested alert messages for updates to that feed.

[0029] A front-end server 136 provides a web interface for easy configuration and monitoring of the IPS via the Internet. Users typically will run web browser software on their computers 116. The web browser software displays a web page on their monitor 118, with one or more fields for the user to populate via an input device 120. Among other things, users will be able to enter Internet feed identifiers for, e.g., RSS (really simple syndication) feeds. The front end server 136 accesses the database server 132 to determine whether phone numbers have previously been assigned, and if not, the front end server retrieves an available phone number from the database and assigns it to the feed. If the phone number is newly assigned, the front end server 136 also notifies the download server 138 to initiate retrieval and translation of the feed. Once a phone number has been assigned, the front end server 136 generates a web page for display on the user's computer monitor 118, showing the assigned phone number.

[0030] When receiving a phone call, the telephony server 126 relies on the database server 132 to determine the audio program that corresponds to the dialed phone numbers of incoming calls, as well as the optional introductory message that corresponds to the Caller ID and/or dialed phone number of the incoming call. With the links provided by the database server 132, the telephony server 126 initiates streaming of the appropriate files from the download server 138. [0031] In addition to providing playback of information for the product/service associated with the dialed phone number, telephony server 126 captures Caller ID/ ANI information for the caller. Moreover, the telephony server 126 detects DTMF tones when the caller presses a key and initiates a programmed action in response to the key press, e.g., pause, skip-back, skip- forward, volume adjustment, etc. In at least some embodiments, the telephony server 126 initiates an order process upon detected an appropriate key press or optional voice input. [0032] The order process preferably performed by the IPS is expected to be unique in that it requires very little effort from the user beyond the initial key press indicating a desire to purchase the good or service. The good or service itself is known and has been described to the user, and the user is known by virtue of the Caller ID/ ANI information. Payment information is preferably not solicited from the user, and in most instances, delivery information is not solicited. Rather, payment and delivery information is determined in one or more of the ways described below.

[0033] The payment processing servers 140 are provided by an online payment processing service such as, e.g., PayPal, Vidicom, or 4Celling. The sales transaction server 142 is provided by the cell phone user's mobile service provider. Internet transaction servers 144 are provided by the retailers/providers of the good or service associated with the dialed phone number. When a caller has indicated a desire to receive the good or service, the telephony server 126 instructs database server 132 to place an order in the queue. Initially, the record representing the order may contain as little as the dialed phone number, the Caller ID/ANI information, and a timestamp. The record may later be populated with a product/service description, price information (possibly including taxes and shipping and handling charges), and an account number for the caller. In some instances, the telephony server 126 may also capture and specify configuration and/or quantity information based on the key press or the user's response to menu prompts (e.g., "Press ' 1 ' for red, '2' for blue, ...").

[0034] The database server 132 is programmed to process the orders in the queue to secure payment and provide delivery of the ordered good or service. The server 132 may secure payment by providing the Caller ID/ANI information along with a price, a brief transaction description, and an account number for the information and purchasing system operator (IPSO) to the online payment processing services, trying first one then the next until a payment confirmation (and possibly delivery information) is obtained. For example, the server 132 may first submit the transaction to PayPal. PayPal would compare the caller's phone number against its account records to determine if the caller has a PayPal account and a sufficient balance or credit. If so, PayPal would (in some embodiments) send a text message to the caller, asking the caller to verify the purchase. If the caller verifies the purchase (e.g., by clicking a link in the message or otherwise responding in some affirmative fashion), PayPal debits the caller's account and credits the account of the IPSO. PayPal then sends a confirmation message to the database server, optionally including the caller's address information for a delivery. If the caller cancels

- i o - the transaction, PayPal sends a cancellation message to the database server, which cancels the order.

[0035] Finally, if PayPal does not have an account corresponding to that number, it sends a refusal message to the server 132. Upon receiving a refusal message, server 132 attempts a second payment processor to secure payment. Continuing this example, server 132 may provide the Caller ID/ ANI information along with a price and brief transaction description to Vidicom. Vidicom generates a text message to the caller, asking the caller to verify the purchase. If the caller verifies the purchase (e.g., by texting a reply that begins with "Y", or otherwise responding in an affirmative fashion), Vidicom sends a premium SMS (PSMS) message to the caller, i.e., a confirmation message that incurs a charge equal to the purchase price on the caller's phone bill. Where the mobile services provider allows the caller to reject such premium SMS messages, the initial text message may be omitted. Upon determining that the PSMS message has been accepted, Vidicom sends a confirmation message to the database server 132. A rejection of PSMS message would trigger a cancellation message to the server 132, and a determination that the caller's service provider does not support PSMS messages would trigger a refusal message to server 132.

[0036] As another or subsequent option, database server 132 may determine the telecommunications service provider for the caller and, if that provider allows such transactions, the server 132 sends the transaction information to the sales transaction server 142. The service provider communicates with the caller via SMS message or email to verify the transaction, and if the transaction is confirmed, the service provider adds the charge to the caller's phone bill and sends a confirmation message to database server 132, optionally including address information

- i i - for a delivery. When the service provider receives payment, the service provider sends payment to the IPSO.

[0037] In many cases, address information may be unnecessary. For example, where the goods or services for sale are downloadable (digital music, software, images, service subscriptions, ebooks, licenses, certifications, etc.), they can be delivered via SMS message including a link or password to a website that provides the download. However, where the address information is needed and not provided by the payment processor or mobile service provider, it can be solicited by a phone call or text message and kept in the database for future orders from that customer. When such address information is available and to be employed for a new order, the address is preferably verified as part of the message acknowledging the caller's key press, or alternatively, it may be included in the transaction description so that the customer verifies it as part of the confirmation text message sent by the payment provider.

[0038] Once the database server 132 receives confirmation that payment has been obtained (or at least authorized), the server 132 sends transaction information to the seller/provider 144 of the good or service. The seller/provider 144 then ships or otherwise delivers the good or service to the caller and bills the IPSO, which provides payment in a traditional fashion. [0039] With this overall system description in mind, we now turn to more detailed descriptions of illustrative system hardware and pertinent method embodiments.

[0040] Fig. 2 is a functional block diagram of an illustrative server 200 suitable for use as part of the IPS. The illustrated server may serve a portion or some combination of the functions outlined previously. The server 200 includes a memory 202, one or more processors 204, and a highspeed bridge that connects the processor(s) 204 with the memory 202 and the expansion bus 208. The expansion bus 208 supports communication with a peripheral interface 210, information storage device 212, network interface card 214, and an optional phone circuit interface card 216. [0041] Peripheral interface 210 provides ports for communicating with external devices such as keyboard, mice, universal serial bus (USB) devices, printers, cameras, speakers, etc. On many servers, these ports may be left largely unused, but they are available for configuration, diagnostic, and performance monitoring purposes. Information storage device 212 is typically a nonvolatile memory for firmware and/or a hard drive for extended storage of software and data. On distributed systems with high data availability requirements, the information storage device 212 is replaced or supplemented with a storage area network (SAN) card that enables shared access to a large disk array. A network interface card 214 provides access to other network servers and usually to the Internet as a whole. Finally, in the telephony server, an interface card for the telephone circuits is optionally included. In some alternative embodiments, the connection to the PSTN is accomplished indirectly via Voice over Internet Protocol (VoIP) techniques, eliminating the need for dedicated telephone circuit interface hardware. [0042] Before the illustrative server 200 boots, the relevant IPS software components are stored on the local hard drive 212, or sometimes on a network disk accessible via the network interface card. After the initial boot-up diagnostics are completed, the processor(s) load the IPS software components into memory, either all at once or on an "as needed" basis (e.g., by paging the needed instructions into memory). As the processor(s) execute the software instructions, the software configures the operation of the illustrative server(s) in accordance with the methods and principles set forth herein.

[0043] Fig. 3 is a function block diagram of illustrative IPS software and interfaces with supporting systems. Though numerous independently executing processes exist, they can be grouped into the functional groups that correspond with the various server systems involved in implementing the illustrative IPS system: the download server, the telephony server, the database server, the front end server (not included here), the payment processor server, the directory service server, the mobile service provider's sales transactions server, and the retailer's online transactions server. These will be initially addressed at a high level. Thereafter, a more detailed discussion will be provided regarding a number of the more pertinent methods carried out by the IPS system.

[0044] The illustrative download software 300 performs an automated downloading and translation function to make RSS feeds or other multimedia files downloadable via the Internet available locally, and it optionally streams the multimedia files on demand. The illustrative download software 300 includes a crawler 303, a database interface 304, a download process 305, a translation process 306, a streaming media player 307, and a media file storage hierarchy 308. The database interface process 304 establishes a connection to the database software 320 to assure coherent and reliable database access for the other download processes 303, 305-307. Via the interface 304, the crawler 303 periodically retrieves a list of feeds that need to be checked for updates. The list includes information regarding the last download of the feeds, such as episode number, title, file size, and publication date. The crawler then checks the feeds on the Internet for updates or changes relative to the last download. If an update or other change is detected, the crawler 303 notifies the download process 305 to retrieve the latest version of the relevant sound or multimedia file. The illustrative download process 305 is designed to conduct multiple downloads with redundancy and tolerance for errors or temporary outages. [0045] As the download process 305 completes the retrieval of each multimedia or sound file, the illustrative translation process 306 converts the audio component of the file into a format suitable for playback over a telephone connection. For example, MP3 files may be converted to uncompressed audio, re-sampled to 8 kHz monaural constant-bit rate stream, and companded using a μ-law companding algorithm. In this format, the media player 307 can (upon demand) stream the file to a telephone connection with minimal processing. As the translation process 306 completes, the files are stored in a file hierarchy 308 with any given standard naming convention, and the translation process 306 notifies the database of a successful download. [0046] The illustrative telephony software 310 performs automated call completion, connecting telephone channels to the Internet feed associated with the dialed number. Illustrative software 310 includes a number translation module 313, a database interface process 314, a call answer/termination module 315, a streaming module 316, a tone decoding module 317, and a menu module 318. The number translation module 313 collects Caller ID/ ANI information and accesses the database to determine the feed or sound file and introductory message currently associated with the dialed phone number. Having determined them, the number translation module passes the information to the call answer/termination module 315. Module 315 answers the call and monitors the connection while streaming module 316 coordinates with media player 307 to initiate playback of the introductory message and the sound file. If module 315 detects tone activity (e.g., from a caller pressing buttons on the keypad), the tone decode process 317 is invoked to determine which keys have been pressed. With the key presses determined, module 315 can invoke the appropriate menu module 318. The menu module 318 generates the appropriate action, e.g., pausing, skipping forward or backward in the playback, switching to a previous/subsequent episode, playing a menu of other options, subscribing a user for future notifications, initiating a purchase of an advertised item, and so on. [0047] The illustrative database software 320 includes a chronology process 321, an application interface process 322, a crawl queue 323, an event log 324, a feed list 325, a phone number list 326, an order queue 327, and a customer account list 328. The chronology process 321 periodically reviews the database tables for certain occurrences, such as the elapsing of a specified interval since the last time a feed was checked for an update, or the number of available numbers falling below a threshold. When such occurrences are detected, the chronology process 321 performs a specified action. In the case of a feed not being recently checked for an update, the chronology process 321 places the feed identifier in the crawl queue, where it will be seen the next time the crawl process 303 checks. In the case of too few available phone numbers, the chronology process 321 may send a message to a designated email address and/or initiate the execution of a phone number recycling process.

[0048] The application interface process 322 cooperates with the database interface processes 304, 314, and 333 to establish database connections with the other server software. Crawl queue 323 is a database table containing a list of feed identifiers that need to be checked for updates. Event log 324 is a table for tracking database transactions. Feed list 325 is a table containing a list of all the feeds with their assigned phone numbers. Phone number list 326 is a table containing a list of all the available (unassigned) phone numbers.

[0049] Order queue 327 is a queue containing orders that have not yet been filled. Database software 320 uses the order queue to track various orders as they pass through the order fulfillment process. Customer list 328 is a table of customer records for customers that have previously placed orders. When delivery address information is obtained for a customer, it is stored in the appropriate customer record. [0050] The illustrative payment processor software 330 includes an interface 333 for receiving payment requests and address information requests. To protect customers, responses to address information requests are limited to only those requests identifying a recently confirmed payment transaction. A security process 334 monitors the requests for signs of fraud or system abuse, refusing suspicious transactions or requests from blacklisted accounts. A verification process 335 determines whether the Caller ID/ ANI phone number is associated with an account in good standing. If so, the confirmation process 336 sends a text message (e.g., an SMS message or email) to the account holder with a request to verify payment, and detects affirmative or negative responses to the message, subject to an expiration time/date. An affirmative response causes the confirmation process 336 to notify the accounting process 337 and the payment process 338, and to send a confirmation message to the database software 320. The accounting process 337 adjusts the payer and payee account balances, and to the extent an actual transfer of funds occurs, that the payment process 338 carries out the funds transfer (e.g., an electronic debit to the payer's credit card and/or an electronic funds transfer to the payee's checking account). [0051] The illustrative sales transaction software for the mobile service provider is also represented by software 330 and performs similar functions. The mobile service provider software includes a billing process for obtaining customer payments for sales transactions in addition to their customary monthly service fees.

[0052] The illustrative directory service software 340 includes an API 343 for receiving search inquiries in the form of a text message. The inquiry API 343 references the source database 344 to determine the appropriate information source given the keywords in the message (e.g., inquiries starting with "movie", "weather", and "Walmart" may respectively be routed to a movie database, a weather forecasting service, and a product database for Walmart). API 343 then calls the data collection process 345 to retrieve data from the selected information source(s) to satisfy the search inquiry. Data collection process 345 sends an inquiry to the selected information source(s), extracts the relevant data from the response(s), and transmits the data as a reply to the original text message. When the inquiry concerns a good or service, particularly one sold by a large retailer, the directory service software 340 accesses a database of product/service- related audio feeds and determines a phone number associated with that product/service. That phone number is included in the reply to the original text message.

[0053] In many cases, the reply message provided by the directory service software 340 will include subscription information, e.g., instructions on how the user can subscribe to receive updates to the results of the search. The instructions may be, e.g., "Reply 'S' to subscribe". A subscription database 346 tracks such subscription information. An SMS push process 347 sends a message ("an alert") to the subscriber with the updated information when such updates are detected. Thus, for example, a subscriber can receive movie schedules, weather forecasts, or price-change notices via a text message as that information is updated. As one source of revenue, an advertisement embedding process 348 may be included in software 340 to add advertisements to each text message sent by the directory service.

[0054] The illustrative Internet transaction software 350 for retailers includes a 3^rd party transaction interface 353 for receiving delivery orders. The delivery orders specify a product/service, a sales price, a recipient of the product/service (with delivery information), and billing information. An accounting process 354 tracks account balances, and a fulfillment process 355 initiates (and later confirms) delivery of the product/service. A billing process 356 secures payment for the delivered products/services. By interacting with this software, the database software 320 can arrange for delivery of a product/service once the payment transaction has been confirmed.

[0055] Fig. 4 is a flowchart of an illustrative method 402 for purchasing a good/service via a phone call. Beginning in block 404, a consumer determines whether it knows the phone number associated with a product or service of interest to the consumer. If not, then in block 406, the consumer submits an inquiry to a directory service in block 406. The directory service may be traditional, in the form of a live operator or printed phone book, or it may be a web-based directory, or it may even be accessible via a text message inquiry. In one contemplated embodiment, the consumer composes a text message beginning with a retailer name or keyword (e.g., WMT for Walmart), and the name or description of a product (e.g., Playstation). In block 408, the consumer receives a response that includes the desired phone number, possibly in conjunction with other information such as price, availability, etc.

[0056] In block 410, the consumer dials the phone number. The consumer can manually enter the phone number, but often alternatives will be available. For example, if the directory service is a live operator, it may offer to dial the phone number for the consumer. If the phone number is provided in a text message, the consumer's phone may recognize that the number is a phone number and allow the consumer to simply select the number for autodialing. Alternatively, the phone number may be provided in the text message's source field, allowing the consumer to treat it as a "call back" number for autodialing. Of course, if the consumer has previously used or stored the phone number, autodialing is usually an option. The autodial feature can also be made available in a number of other ways. One autodial method involves scanning a barcode or RFID (radio frequency identification) tag that provides (directly or indirectly) a phone number to a mobile phone. Yet another autodial method involves a "click to call" link embedded in a webpage or email that invokes the computer or phone's autodialing function. These and other autodial methods enable a user to easily command a phone to call a phonecast number, so that the phone connects to a audio feed player in block 412.

[0057] In block 414, the consumer hears the audio feed, which preferably includes description or demo of the product or service with uses, benefits, and (where applicable) configuration options. In block 416, the consumer hears purchase instructions such as, e.g., "Press '5' to have this music delivered to you for $4.99"; "The price for each unit is $12. Please enter the number of units you would like to purchase, followed by the pound sign"; "Press ' 1 ' for our luxury service package, '2' for our premium service package, '3' for our express service package, or '4' for our budget service package". In block 418, the consumer chooses whether or not to make a purchase. If the consumer does not make a purchase, an 'outro' message is played and the call is terminated in block 420. The outro message can express thanks for the call, an encouragement to call back for future offers, an advertising jingle, etc.

[0058] If the caller does indicate a desire to make a purchase, an acknowledgement message is played and the call is terminated in block 422. Where the consumer has an address on account, the acknowledgement message may include a confirmation of that address. The acknowledgement message may be, for example, "Thank you for your order for 2 units. You will receive a request for confirmation within the next few minutes. If your order is confirmed, we will deliver your 2 units to 123 Any Street, Anywhere Utah 12345. If this address is incorrect, press '0' to be connected to the operator."

[0059] In block 424, the consumer receives a text message or a call asking for confirmation of the purchase. The message or call may include instructions for indicating acceptance (e.g., "Text 'Y' in response to this message") and, where needed, a request to provide or confirm a delivery address. In block 428, the consumer chooses whether or not to confirm the purchase. If the consumer does not confirm, the order is canceled and the process ends in block 430. [0060] If the consumer confirms the purchase, they may be required to provide delivery information in block 432. Once the delivery information is on file, the consumer is able to simply confirm the file information rather than providing the delivery information in full. Also, in many cases this action can be omitted because delivery can be accomplished via the customer's phone number obtained by Caller ID/ ANI (e.g., by an SMS message to the phone number with a link or password to obtain the content via the Internet).

[0061] In block 434, the consumer receives the good or service. In many cases, the charge for the good or service will appear on the consumer's phone bill, which is paid in block 436. When PayPal is used, the consumer's account is debited or a charge is made to the consumer's credit card. In any event, the consumer's purchasing experience is expected to require little effort when compared to physical shopping trips or online shopping where credit card information must be manually entered for each purchase.

[0062] Fig. 5 is a flowchart of an illustrative method 502 for providing a text-based product directory service. In block 504, the directory system receives a text message with a product or service name or keyword. In block 506, the directory server selects an information source that associates phone numbers with products and/or services. Examples of such information sources may include an IPS, a phonecasting system, and a product/service database of a large retailer or service provider. Eventually, a consolidated product directory may be compiled and stored internal to the directory system. For the moment, at least, the directory server selects an information source and sends a query to the selected information source in block 508. In block 510, the directory server receives a response to the query. In block 512, the directory server extracts the phone number and any other suitable information from the response and formats the extracted information as a reply to the original text message. In some instances, multiple products may satisfy the query, in which case the reply preferably includes a list of the products and their associated phone numbers.

[0063] Fig. 6 is a flowchart of an illustrative product/service feed playback method 602 that may be carried out by the telephony server. Beginning in block 604, the telephony server receives a call to a dialed number associated with a product or service. In block 606, the telephony server accesses the database to determine which feed or multimedia file is currently associated with that dialed number. In block 608, the telephony server collects the CID or ANI information. This information may be used for statistics generation, targeted advertising, subscription services, notification services, and purchasing services. In block 610, the telephony server answers the call, and in block 612, the telephony server initiates playback of the feed associated with the dialed number. A sequence of blocks 614, 620, 622, and 624 represent a series of iterative operations performed by the telephony server during playback of the feed. In block 614, the telephony server determines if playback of the feed has completed, and if so, in block 616, the telephony server plays an outro message before terminating the call in block 618. [0064] If in block 614, the telephony server determines that the feed playback is not finished, it checks for a key press in block 620. If a key press is detected, then in block 622 the telephony server determines the appropriate action for the key press. If the key press indicates a purchase request, then in block 626, the telephony server initiates the order process by adding an order to the order queue of the database 132. The order initially may be as minimal as just the Caller ID/ANI information, the dialed phone number, and a time stamp. In some embodiments, the order information may further include a product/service description or identifier, price and quantity information, configuration options, and a customer account number for callers having prior order history and/or delivery information stored. In block 628, the telephony server plays an purchase acknowledgement message 628 and terminates the call in block 630. [0065] If the telephony server determines in block 622 that the key press represents some action other than a purchase request, then the telephony server performs the appropriate action in block 624 and loops back to block 612 to continue the audio feed playback. Examples of such other actions include pause, skip-back, skip-forward, volume control, and update alert subscription functionality.

[0066] Fig. 7 is a flowchart of an illustrative order process 702 that may be carried out by the database server 132. Beginning in block 704, the server receives an order having Caller ID/ ANI information and an identifier for the product or service to be purchased (which in some embodiments is represented by the dialed phone number). Optionally, the order information includes quantities and/or configuration options. In block 706, the server adds the order to the "in process" order queue. In block 708, the server determines the product/service name and price (including taxes, shipping and handling fees, and payment transaction fees if applicable), and updates the order record accordingly. In block 710, the server issues a payment transaction request to a payment processing service such as, e.g., PayPal, Vidicom, or 4Celling, using the CID/ ANI information to identify the payer. Optionally, payment processing services may be provided by the purchaser's mobile service provider.

[0067] It is expected (but not necessarily required) that the payment processing service will confirm the payment transaction by sending a text message to the payer with a description of the transaction and a request for an affirmative response. Upon receiving such an affirmative response, the payment processing service sends an acceptance message to the server 132. If a negative response is received, the payment processing service sends a cancellation message to the server. If the payer doesn't have an account with the payment processing service or the payment transaction is unacceptable, the payment processing service sends a refusal message to the server. If the payment transaction is refused by one payment processing service, the server may submit a payment transaction request to one or more alternative payment processing services. Suitable alternative confirmation methods exist for payment processing services (e.g., a phone call, provision of a password or personal identification number, or pre-approval) and others may be developed in the future.

[0068] In block 712, server determines whether the message from the payment processing service is a cancellation message (or optionally, a refusal message). If so, the server 132 cancels the order (possibly by removing it from the queue), thereby terminating the illustrative order process. If the message is a confirmation message, then in block 716 the server determines whether it has enough information to provide delivery of the product or service. [0069] For some products/services, the Caller ID/ANI information is sufficient to ensure delivery. The primary example of such a product/service is downloadable content such as digital music, ring tones, software, images, movies, service subscriptions, recipes, ebooks, licenses, certifications, passwords, search results, etc. For other products/services, a physical delivery address is desirable. Often, the delivery address will be available from previous customer purchases, and if so, that address is preferably confirmed as part of the acknowledgement message or as part of the transaction description which is included by the payment processing service in their text message to the payer. If in block 716, the database server 132 determines that the address is needed and is not available from prior purchases, the server 132 obtains the delivery information and confirms it with the payer in block 718. In some embodiments, the delivery information is requested from the payment processing service and/or the mobile service provider. In other embodiments, the delivery information is obtained via a reverse-lookup in one or more phone directories. In yet other embodiments, the address information is solicited by a text message or phone call to the payer. However the address information is determined, it is preferably confirmed via a text message to the payer with a request for an affirmative response or a correction.

[0070] Once adequate address information is obtained, the server 132 sends a delivery request in block 720. For physical products, the delivery request may be delivered to an online retailer, specifying the delivery address of the payer, but listing the information and purchasing system operator (IPSO) as the purchaser. For services, the delivery request may be delivered to an online storefront of a service provider, again specifying the relevant address information of the payer, but listing the IPSO as the purchaser. For downloadable material, the delivery request may be delivered to a secure download service that sends a text message to the payer with the relevant download information.

[0071] In block 722, the server 132 determines whether the delivery request has been acknowledged by the retailer/provider/download service, or in some cases, whether the retailer/provider has acknowledged shipping or otherwise delivering the product or service. If so, then in block 724 the server marks the order as completed, thereby terminating the order process. If the server 132 fails to receive an acknowledgement, it attempts to resolve the issue. In some embodiments, the server attempts to correct the issue by returning to block 720 and re-sending the delivery request.

[0072] Fig. 8 is a flowchart of an illustrative audio feed parameter configuration method 802. Beginning in block 804, the front end determines whether or not it is the feed publisher that is attempting to configure the feed. This determination can be performed by having the publisher log in to an account, or otherwise provide verification that the publisher is who they claim to be. In some cases the publisher may be asked to include a verification code in their syndication file to establish their identity.

[0073] In block 806, the front end software displays the current audio feed parameters. In block 808, the front end determines whether the publisher wishes to modify any parameters, and if not, the process terminates. Otherwise, in block 810, the front end determines whether the new parameter value is valid or not. If so, the front end updates the parameter value in block 812. If not, an error message is published in block 814, and the updated parameter values are redisplayed in block 806.

[0074] Two parameter values that preferably cannot be changed by configuration method 802 are the phone number and the product/service identifier associated with that phone number. (The product/service identifier can take different forms, including but not limited to a product number such as a stock-keeping unit (SKU) number, a universal product code (UPC), a European article number (EAN), a global trade item number (GTN), an international standard book number (ISBN), an international standard serial number (ISSN), a Library of Congress Control Number (LCCN), a digital object identifier (DOI), and a numeric uniform resource name (URN). These product numbers are commonly exhibited using barcodes or standardized OCR fonts for easy scanning). Examples of the various parameter values that can be set include: the URL for the RSS syndication file and/or the audio feed file, the product name/description, menu prompts and corresponding menu actions, the source for pricing and availability information, and advertising/sponsorship information. In some system embodiments, customers are allowed to record reviews or comments for the publisher to review. The configuration method 802 may allow the publisher to insert or append selected ones of the customer reviews to the audio feed. [0075] The publisher may also have the option to upload introductory messages and/or advertisements for playback before the audio feed. In some system embodiments, the publisher may be expected to pay for this option, and in such embodiments, the publisher can specify options for the messages or advertisements, including desired budget, desired presentation frequency, desired targeting parameters (e.g. CID/ANI area codes), calendar schedules for different ads, limitations on 3^rd party advertisements (e.g., no automotive ads, or no competitor ads), and so on. The publisher may customize menu options for the each audio feed, including custom voice menu prompts, unique menu actions and/or purchase options. The publisher may review call metrics, i.e., statistics about the numbers, frequencies, distributions, and lengths of calls to the audio feed.

[0076] Fig. 9 is a flowchart of an illustrative audio feed recording method 902 that may be used as an alternative to uploading a feed via the Internet. Beginning in block 904, the publisher dials the phone number assigned to the audio feed for a particular product or service. In block 906, the publisher presses a key that triggers a recording option, and in block 908 enters a personal identification number (PIN) in response to a voice prompt. If the PIN is accepted, the publisher hears a voice prompt in block 910 to "start recording". In block 912, the publisher speaks or otherwise provides a sound stream over the phone connection as the IPS records it. When finished, the publisher types a key to stop the recording process in block 914. In block 916, the publisher is given the option to review the recording, and if he or she chooses that option, the recording is played back in block 918, with the publisher allowed to pause, skip forward, and skip backward. In block 920, the publisher presses a key to designate an edit point. The edit point may be used to mark an insertion point or to demarcate a deletion/replacement portion of the recording. Alternatively, a key may be pressed to terminate the screening process in block 922. For insertions or replacements, the publisher does additional recording beginning with block 912. [0077] Once the screening/editing process is completed, the publisher enters a title in block 924 and a description in block 926. The preferred format for the title and description is text, and accordingly, the title and description entry may be performed using any standard keypad-entry technique such as "triple-tap", with or without predictive word completion, and "single -tap" word recognition. Alternatively, voice-to-text technology may be employed. In block 928, the publisher selects the role of the recorded content, i.e., whether the recorded content is the main feed, or whether it is an intro, outro, or acknowledgement message. In block 930, the publisher is given the option to perform further content recording, and if he declines, the call is terminated in block 932.

[0078] In summary, a number of novel IPS and method embodiments have been disclosed. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. As one example, the illustrative methods shown in the figures present actions in a sequential series. Those skilled in the programming arts are aware of various parallel and distributed programming methods that can achieve similar results while permitting similar actions to be taken out of sequence, concurrently, or simply as needed. Moreover, the sequences shown are given for illustrative purposes, and in practice many of the actions could be re-ordered, omitted, inserted, or repeated as desired. As another example, the telephony software can be readily extended to buffer, translate, and play live audio streams made available via the Internet. For such feeds, some or all of the download server operations may be omitted. [0079] A number of applications of the disclosed systems and methods should be readily apparent. Products ranging from real estate to books can include serial numbers, SKUs, or other identifiers. Those numbers or identifiers can each be assigned a corresponding phone number that connects a caller to a current, timely audible program about the property, product, or body of work by the author, thereby building consumer confidence and thereby facilitating the transaction. Artists can have phone numbers assigned to their latest songs or albums so that the public can sample their work and "press 5 to have this music delivered". The disclosed systems and methods may enable a new economy by facilitating the distribution and use of dedicated phone numbers for such purposes.

[0080] The disclosed information and purchasing systems and methods can also be adapted for the payment of gifts, charity contributions, income taxes, ticket fees, fines, and other payments transactions that do not involve the delivery of a product or service. In this instance, the phone number is associated with a person or entity that receives the payment, and the system may determine based on the CID/ ANI information the desired payment amount or potential payment amount options. The audio feed may simply described the intended purpose of the payments and list the desired payment amount(s) and payment instructions (e.g., "Press ' 1 ' to pay your speeding ticket"; "Press ' 1 ' to contribute $100 to the campaign"; or "Enter the desired payment amount in whole dollars"). The ordering process could be completed by delivery of a text message receipt in lieu of issuing a delivery request to a retailer or service provider. Phone- mediated payments can become an desirable alternative to mailing checks or currency, or even an alternative to credit card transactions when a person has left his wallet at home. As but one example of the latter application, a store clerk can receive a message confirming a specified payment amount, and can compare the transaction number to the number displayed in the customer's receipt message.

[0081] The following claims should not be limited to the specific embodiments disclosed above. It is intended that the following claims be interpreted to embrace all variations and modifications within the scope of the foregoing disclosure.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A network server that comprises: a memory that stores directory service software; and a processor coupled to the memory to execute the directory service software, wherein the directory service software configures the processor to: receive a search inquiry; access a database to determine products or services responsive to the search inquiry; and provide a response to the search inquiry, wherein the response includes at least one phone number uniquely associated with at least one of said products or services.

2. The server of claim 1, wherein the search inquiry and response each take the form of a text message.

3. The server of claim 2, wherein said phone number is configured as a link for autodialing.

4. The server of claim 3, wherein the phone number enables the caller to access an audio feed that provides information about the product or service.

5. The server of claim 4, wherein the audio feed offers the caller the opportunity to purchase the product or service by pressing a button during the phone call.

6. A network server that comprises: a memory that stores telephony software; and a processor coupled to the memory to execute the telephony software, wherein the telephony software configures the processor to: receive a call to a phone number associated with a product or service; capture caller identification information for the call; answer the call with an audio feed that provides information about the product or service; offer the caller an opportunity to purchase the product or service; detect a key press indicating a purchase request; and play a message to acknowledge the purchase.

7. A network server that comprises: a memory that stores purchasing system software; and a processor coupled to the memory to execute the purchasing system software, wherein the purchasing system software configures the processor to: receive order information including at least caller identification information and an identifier for a product or service; transmit a payment request to an online payment processing service, wherein the request includes a phone number determined from the caller identification information; and receive a confirmation message from the online payment processing service.

8. The server of claim 7, wherein the online payment processing service sends a text message to the phone number to requesting transaction approval, and wherein the online payment processing service sends a confirmation message to said server upon receiving said transaction approval.

9. The server of claim 7, wherein the purchasing system software further configures the processor to: send a delivery request to an online retailer or service provider; and receive an acknowledgement message from the retailer or service provider.

10. The server of claim 7, wherein the purchasing system software further configures the processor to: determine if delivery information is on file for the caller; and if not, to send one or more inquiry messages to obtain the delivery information.

11. A network server that comprises: a memory that stores payment processing software; and a processor coupled to the memory to execute the payment processing software, wherein the payment processing software configures the processor to: receive a request for a payment transaction, wherein the request includes at least a phone number for the payer and a payment amount; determine whether an account associated with the phone number has a sufficient balance or credit to cover the payment transaction; send a text message to the phone number requesting approval for the payment transaction; debiting the account contingent upon receiving said approval; and sending confirmation in response to the request for payment transaction.

12. An information and purchasing system that comprises: a database that associates phone numbers with corresponding product identifiers and an audio feed for each product identifier; a telephony server that plays the associated audio feed in response to calls to a given phone number; and a directory service that provides phone numbers in response to product-based search queries.

13. The system of claim 12, wherein the directory service further provides price and product availability information.

14. The system of claim 13, wherein the directory service accesses a product database for a retailer to determine the phone number, price ad availability.

15. The system of claim 12, wherein the system enables a caller to purchase a product without requiring any effort beyond a single key press and a subsequent transaction approval via a response to a text message.