Telephone-based selection, ordering, and billing of digital content delivered via a network

[0001] This application is related to co-pending and commonly assigned application Ser. No. 10/058,517, filed Jan. 28, 2002, entitled “Obtaining On-Demand Goods and Services Using Video Telephony” which is incorporated herein by reference in its entirety.

[0002] Not Applicable.

[0003] The present invention relates in general to delivery of digital multimedia content via a data network such as the Internet, and, more specifically, to simplified content selection and collection of access charges using infrastructure of the telephone system.

[0004] With the proliferation of broadband (i.e., high-speed), always-on Internet connections such as digital subscriber line (DSL) and cable modem access, the Internet is becoming a practical channel for distributing digital multimedia content to increasing numbers of users (by download or real-time streaming). In addition to standard personal computer equipment that may be used to view and/or listen to multimedia content such as movies, live events, music videos, and Internet radio broadcasts, special dedicated hardware devices have been introduced for interfacing with the Internet, such as the set-top box. Nevertheless, the implementation of such use has been slow due to several logistical constraints.

[0005] In obtaining content that is encoded in a manner appropriate for their hardware and software configurations, requesting users may be required to possess certain computer knowledge and/or may have to expend extensive set-up time and effort. Furthermore, much of the desirable multimedia content is not available for free, so the user must make an arrangement for paying for the received content. One potential method is to pay by credit card, but many users are reluctant to transmit a credit card number for authorization over the Internet due to security concerns. As an alternative, a user can sign up with a content service wherein the actual payment process is arranged in advance. However, the user is then limited to the content available from the content service(s) that they have joined in advance and they must deal with complicated, separate billings whenever a plurality of separate services are used. Furthermore, access to the content will not be granted until the sign up process is completed which may take a significant length of time.

[0006] There have been several impediments from the content provider perspective as well. In the case of a small content provider, the cost of a payment system and/or a membership sign-up process may be impractical. Even for a large provider, the elaborate invoicing and digital rights management (DRM) systems contribute to high costs. Furthermore, the business opportunity represented by infrequent users who might wish to purchase access to one content file but that do not wish to sign up to a service is lost.

[0007] The present invention has the advantages of greater convenience and low cost in a system for selecting, ordering, and paying for access to digital multimedia content, wherein a secure telephone connection is used to select content and request access. In addition, the telephone billing system provides a unified financial settlement system for access charges even when multiple content providers are used.

[0008] In one aspect of the invention, a content delivery system for delivering digital multimedia content to a premise appliance of a user comprises an intelligent voice response (IVR) unit. The IVR unit is responsive via a public switched telephone network to a premise telephone of the user. The IVR unit presents a predetermined menu for selecting a transaction to receive the digital multimedia content. The IVR unit also obtains an identification of the user (such as the user's telephone number via automatic number identification or caller ID). A content server is coupled to the IVR unit for transferring the digital multimedia content to the premise appliance. A telephone billing system is coupled to the IVR unit and the content server. The telephone billing system creates a call record corresponding to the selected transaction and to a telephone billing account corresponding to the user identification. The call record contains usage information for the transaction. The content server signals the billing system in the event of an incomplete transmission for adjusting the call record.

[0012] Referring to FIG. 1, a user telephone 10 and a destination appliance 11 may be located at a user premises 12. Telephone 10 may be a standard wired instrument connected by a land line to the public switched telephone network (PSTN) 13. Alternatively, telephone 10 may be a mobile wireless phone (e.g., cellular phone) not restricted to use at premises 12. Destination appliance 11 may be comprised of a personal computer or a dedicated multimedia device such as a set-top box for using in association with a television monitor, for example. It is coupled to a public or private data network such as the Internet 20 for receiving multimedia files (e.g., streams or downloads) to be reproduced for the user. Appliance 11 has an assigned data network address such as an IP address through which it receives any streams or downloads from Internet 20. While it is convenient in the present invention to associate an IP address of appliance 11 with a telephone number (i.e., E. 164 number) located at the same premises, it is not necessary. Either or both of telephone unit 10 and appliance 11 may be mobile devices, provided that a telephone number for billing purposes and an IP address for delivering the multimedia file are available.

[0013] PSTN 13 is coupled to a telephone billing system 14 operated by a telephone company (e.g., a local exchange carrier or an inter-exchange carrier) providing telephone service within PSTN 13. Billing system 14 has the conventional capabilities of accumulating usage information (e.g., service type and elapsed time), calculating charges, and regularly invoicing customers for telephone service itself and for third party services accessed via a telephone call (e.g., “900 number” services). Charges for third party services are collected by the telephone company and then disbursed to the third party providers. Charges are accumulated by way of call records 15 that are created and processed electronically within a private computer system.

[0014] The present invention for delivering multimedia content and then obtaining payment via telephone billing system 15 includes an intelligent voice response (IVR) unit 16 which may be comprised of commercially available equipment and which is programmable to provide a desired interface between a telephone user and computerized devices, such as a content server 18. IVR unit 16 preferably incorporates an ANI unit 17 for receiving ANI signals identifying the originating telephone number of a calling user. The user dials a “transport” telephone number which connects them with IVR unit 16. The telephone number is publicized as an access number to the multimedia content delivery system of the present invention. IVR unit 16 presents a predetermined interactive menu using recorded or synthesized speech to present various choices to the user. The user may indicate various selections within the menu by pressing buttons on the dial pad to generate DTMF tones and/or by spoken commands if IVR unit 16 is capable of speech recognition, for example. The interactive menu includes selection items for identifying a desired multimedia content file to be obtained via electronic delivery, for example. The user may browse through a hierarchical listing of available files or may directly input a numerical or verbal identifier of the desired selection, if known by the user in advance (e.g., from an advertisement).

[0015] When the selection process is completed, a transaction is initiated with content server 18 to transmit the selected digital multimedia content from multimedia source files 19 stored in association with content server 18. Rather than a point-to-point transmission, a multicasting transmission can be used. In that case, content server 18 sends the needed “join” information (e.g., multicast group ID or source address and decryption information) allowing the user to join a multicast stream in-progress. Packet generalization may be used to allow a user to join an existing multicast and to play the media from the beginning at any join point.

[0016] The file transmission may be delivered via Internet 20 (or other public data network), in which case the file may preferably be encrypted in an encryption block 21. The Internet transmission is sent to an IP address corresponding to destination appliance 11 which may be determined from a user database 22, for example. Database 22 can be attached to IVR unit 16 and/or content server 18 or may be split between them (e.g., when IVR unit 16 and content server 18 are controlled by different providers). If the IP address information is not available from database 22, then IVR unit 16 may query the user for the IP address.

[0017] IVR unit 16 and content server 18 may be operated by a particular content provider and may be directly interconnected as part of a private computer system, for example. Alternatively, IVR unit 16 may be operated by a separate entity (e.g., a telephone company) or at a remote location of the content provider. Thus, communication between IVR unit 16 and content server 18 may be alternatively accomplished via Internet 20.

[0018] Database 22 may also contain information concerning the type of file encoding that is required by a particular user (e.g., file format, type of file compression, etc.) and the transmission can be automatically adjusted to provide the appropriate encoding. If the necessary information in not available from database 22, then it can be obtained by a query forwarded to the user via IVR unit 16.

[0019] Database 22 may preferably contain records corresponding to each telephone number from which an access request is received. Each record is preferably updated according to IP address and encoding information entered by a user for a desired transaction. A registration process may also be used with user database 22 in order to set up the desired information pertaining to an individual user.

[0020] In an alternative embodiment, a connection from content server 18 to PSTN 13 allows file transmission to be accomplished using the existing telephone call from the user. Destination appliance 11 may preferably be connected to telephone 10 and/or the telephone line leading to PSTN 13 in order to receive the file transfer (e.g., via a modem and dial-up networking protocols).

[0021] Due to the greater privacy of a telephone line connection, encryption may not be necessary for that embodiment. For delivery over a public data network, however, encryption is highly desirable. Encryption algorithms rely on one or more keys to encode and then decode the encrypted data. At least one of the keys should be known only to the sending and/or receiving parties. In the present invention, a key is employed that is based on details of the transaction that are known only to the user and to the content provider by virtue of the private nature of the telephone connection between telephone 10 and IVR unit 16. Preferably, the key incorporates user identification in the form of the user's telephone number as obtained by ANI unit 17. In addition, the key may incorporate a content provider identifier (e.g., ASCII code of the content provider's name) combined with the user identifier in a predetermined manner. This encryption method is highly secure since the ANI telephone number and the content provider identifier are not included in the Internet transmission of the multimedia file. A third party intercepting the Internet transmission would need to know which telephone made the request for the content and the identifier of the content provider in order to determine the necessary key to decrypt the file, which is very unlikely. The intended user at the destination IP address, on the other hand, possesses the necessary information and can provide it to destination appliance 11 to enable the decryption of the received file.

[0022] In order to obtain payment for access to the desired multimedia file, content server 18 (or alternatively IVR unit 16) communicates with telephone billing system 14 for initiating call records reflecting the usage associated with accessing the file. The connection from content server 18 (or alternatively IVR unit 16) to billing system 14 may be by a private connection or via Internet 20, for example. Based on the recorded usage information (e.g., service type, connect time, and/or bulk files transferred), the billing system periodically calculates payments due and adds them to an invoice or bill sent to the user (e.g., on a customer's monthly telephone bill).

[0023] One embodiment of a method of operation for the content server is shown in FIG. 2. The server is initialized in step 30 and then waits for a request in step 31. When a request is received from the IVR unit, it is checked for validity in step 32. If not valid then an error is recorded in step 33 and a reply message is sent with the error status to the IVR unit in step 34. Then a return is made to step 31 to wait for the next request.

[0024] If the IVR request is valid, then a check is made in step 35 to determine whether this request constitutes a reply of the IVR unit to an earlier (suspended) request by the content server for more information from the user. If it is, then the suspended request is retrieved and updated with the new information in step 36; and if not, then step 36 is skipped. In step 37, a check is made to determine whether all needed information for the transaction, including the requesting ID, is known (e.g., whether a record exists in the user database corresponding to the ID which specifies an IP address and, if needed, the type of file format or encoding to be used for that user). If it is the first time that the user has accessed the content provider from the telephone number (i.e., requesting ID) being used or if the database record has incomplete information, then the request is suspended (i.e., retained in an inactive state) and a reply message is sent to the IVR unit in step 39 to request the needed information to complete the request. Alternatively, the content server need not retain any information about an incomplete request if the IVR unit formats a completely new request after obtaining the missing information.

[0025] If the requesting ID is known and no further user information is needed by the content server, then the server determines the encryption key to be used, encrypts the requested multimedia file using that key, and initiates streaming of the encrypted file to the destination (e.g., the IP address obtained from the user database or from the user via the IVR unit) in step 40. If the file is delivered by way of the existing telephone call connection rather than over the Internet, then encryption is typically not necessary.

[0026] Once the requested stream is initiated, a reply message is sent in step 41 to the IVR unit providing the transmission status so that the user can be given an acknowledgement over the telephone call that the stream is in progress. In step 42, the call record detail corresponding to the streamed file (e.g., user telephone number, content provider ID, file ID, destination IP address, media service type, and connection time) is transmitted to the telephone billing system. In the preferred embodiment, the call record detail information may be sent by the content server, but it could alternatively be sent by the IVR unit. In step 43, a check is made when file streaming ceases to determine whether an error-free and complete transmission of the requested file was achieved. If yes, then a return is made to step 31 to await the next request. If no, then updated call record detail is transmitted to the telephone billing system in step 44 to update the call record or generate a reversal record, thereby preventing the corresponding charge from appearing on the user's telephone bill. The update may be comprised of a re-marking of the call detail termination status to an appropriate error. The adjustment to the call detail termination status must occur after the initial call detail recording because the initial recording is usually required to be maintained in a non-modified form. The content server and/or the IVR unit should also log the error together with the original request and before and after images of the call record.

[0027] Operation of the IVR unit is shown in FIG. 3. The IVR unit is initialized in step 45 and it then waits for events to occur in step 46. Upon an incoming event, a check is made in step 47 to determine whether the event is a valid request for supplemental information from the content server. If so, then information about the pending request that was already stored in the IVR unit is retrieved in step 48. Prompts are provided to the user over the telephone call in step 49 to collect the requested information, which is then supplied by the user via touch tone signals or speaking the information. In step 50, the IVR unit formats a new file request for the content server. The request is transmitted to the server in step 51 and the IVR unit returns to step 46 to wait for additional events.

[0028] If an event is not a content server request, then a check is made in step 52 to determine whether the event is a valid user request. If yes, then the IVR unit proceeds through its user interface in step 53 to collect the file selection(s) of the user and the identity of the user (e.g., by referring to the ANI unit for the user's telephone number). In step 54, a user request is formatted in response to the user selections and the user identifier. The request is transmitted to the server in step 51 and the IVR unit returns to step 46 to wait for additional events.

[0029] If an event is not a valid user request, then a check is made in step 55 to determine whether the event is a valid reply message from the content server. If not, then an error is recorded in step 56 and an error status message is provided to the user. If yes, then the pending user request is retrieved in step 57 so that an acknowledgement message can be provided to the user over the telephone call in step 58. A log entry is created in an activity log file in step 59 and then the telephone call is released.