System and method for enhanced telephone customer usage details

[0001] 1. Technical Field

[0002] The present invention relates in general to a system and method for enhanced telephone customer usage details. More particularly, the present invention relates to a system and method for accessing telephone account information and imposing limits on telephone usage.

[0003] 2. Description of the Related Art

[0004] The cost of using a stationary phone or mobile phone has decreased which as increased the popularity of telephone use. Many users have multiple telephone accounts, such as a home phone number and a mobile phone number. Additionally, some parents establish mobile phone accounts for their children in which the parents pay for their children's telephone use. Telephone service providers promote many types of service plans to attract customers. Some service plans have a high monthly fee but have unlimited telephone use including long distance calls. Other service plans have a low monthly fee but a user is charged for usage on a per minute basis and is also charged for long distance calls.

[0005] A challenge found the existing art is that there does not exist a real-time simple method to access acquired telephone charges for a particular account. In order to check long distance usage, toll calls, and local toll calls, a user contacts the service provider's customer support desk and inquires about the account. Some service providers offer an online service using a web-based lookup system. In addition, cellular phones use a call feature that connects to an automated customer support desk which provides account information from an accounting database. This information includes minutes used in-plan and out-of-plan as well as billing information and account balances. If a user wishes to access multiple telephone accounts, these access methods can be very time consuming.

[0006] Furthermore, a challenge found with the existing art is its ability to cost effectively limit the amount of phone usage for a particular account. For example, a parent who pays for a child's mobile phone use may wish to limit the total monthly charges of the corresponding telephone account to $20. Pre-paid telephone cards and plans are currently used to manage telephone usage costs. However, pre-paid plans may have hidden costs which make the plan non-cost effective.

[0007] First, pre-paid plans may have connection fees which are also called first-minute surcharges. Connection fees may be charged when a telephone call is connected. Second, pre-paid plans may include a monthly tax or one-time tax. Third, pre-paid plans may have a maintenance fee which may be deducted from a phone card every month, every two weeks, or every week. Fourth, pre-paid plans may have a high “minute rounding” charge. The industry standard is one minute rounding, as in the case of residential telephone services. Pre-paid plans may be rounded to one, two, or even three minutes. For example, a 30 seconds phone call may be charged as a 3-minute phone call. What is needed, therefore, is a simple and quick way to access one or more telephone account usage details with the ability to cost effectively limit telephone use for a particular billing cycle.

[0008] It has been discovered that a user may use a single button account management feature to check the telephone usage corresponding to an account and set usage limitations on the particular account.

[0009] The user sends an account information request and authorization information to a service provider by depressing a button on his telephone. The service provider receives the request and verifies the user is authorized to access the corresponding account. Once verified, the service provider accesses the requested account information and sends the account information to the user's telephone through a communication network, such as the Public Switched Telephone Network (PSTN). The telephone receives the account information and stores the account information in a local storage area. The account information may then be displayed on a telephone display or converted to an audio message using a voice synthesizer and sent to the telephone's speaker.

[0010] If the user wishes to set limitations on his corresponding telephone account, the user uses the telephone to set account limitations. For example, the user may wish to limit the number of available daily minutes for use on his account. The user may be able to set limitations for multiple accounts using a single telephone provided the user has proper authorization.

[0011] In one embodiment, the user may set account limitations through the Internet using a web-based software program. For example, the user may log on to service provider's web page and access his account to set account limitations.

[0012] When the user wishes to place a telephone call, processing compares the existing account activity with the user's imposed limitations. If the existing account activity has not reached the user's imposed limitations, processing completes the telephone call. On the other hand, if the existing account activity has reached one or more account limitations, processing blocks the call and sends a message to the user specifying why the call was blocked.

[0013] The foregoing is a summary and thus contains, by necessity, simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting. Other aspects, inventive features, and advantages of the present invention, as defined solely by the claims, will become apparent in the non-limiting detailed description set forth below.

[0023] The following is intended to provide a detailed description of an example of the invention and should not be taken to be limiting of the invention itself. Rather, any number of variations may fall within the scope of the invention which is defined in the claims following the description.

[0024] FIG. 1 is a high-level diagram showing a user accessing and configuring telephone account information. User 100 uses phone 110 to place telephone calls and access account information. Phone 110 includes access button 120, account manager 130, and local data store 135. Access button 120 may be a single button which sends a request to user 100's service provider to access account information. In one embodiment, access button 120 may be a sequence of buttons which user 100 depresses to access account information (i.e. 1,2,3,#). Account manager 130 may be a software program which sends account requests and stores relevant account information, such as minutes used during a month, on local data store 135. Local data store 135 may be stored on a non-volatile storage area, such as non-volatile memory.

[0025] User 100 depresses access button 120 which sends request 140 to service provider 160 through communication network 150, such as a Public Switched Telephone Network (PSTN), wireless network, or the Internet. Service provider 160 receives and processes request 155 (see FIG. 2 and corresponding text for further details regarding user request processing). If request 155 is requesting account information, service provider 160 may proceed through an authorization sequence to ensure user 100 is authorized to access the requested account. Request 155 may include authorization information, such as a user name and a password.

[0026] When processing authorizes the request, service provider 160 accesses the requested account information from account data store 165. Service provider 160 sends response 170 to phone 110 through communication network 150. Response 170 includes account information corresponding to request 140. Phone 110 receives response 180 and account manager 130 stores the account information in local data store 135. Account manager 130 may then display the account information on a display. Account manager 130 may convert the account information to an audio message if phone 110 does not have a display. In one embodiment, service provider 160 may provide account information to phone 110 using an audio signal instead of providing account information in data form.

[0027] If user 100 wishes to set limitations on his corresponding telephone account, user 100 uses phone 110 to send request 140 which includes a limitation request to service provider 160 through communication network 150 (see FIG. 4 and corresponding text for further details regarding account limitation settings). For example, request 140 may include a request to limit the monthly dollar amount that may be charged to the corresponding telephone account. Service provider 160 stores the limitation request in account data store 165 corresponding to the telephone account.

[0028] In one embodiment, user 100 may set account limitations through the Internet using a web-based software program. For example, user 100 may log on to service provider 160's web page and access his account to set account limitations.

[0029] When user 100 wishes to place a telephone call, processing retrieves account limitation information and current telephone usage information (i.e. amount of minutes used and current billing amount) from local data store 135. If the telephone usage information has not reached the limitations imposed on the telephone account, processing completes the telephone call (see FIG. 6 and corresponding text for further details regarding call authorization). On the other hand, if the usage information has reached one or more account limitations, processing blocks the telephone call (i.e. the account has reached a usage limit). If account limitations have not been reached, processing may set a timer to track the amount of time of the telephone call. Processing may monitor the timer to ensure the telephone call does not exceed a per-call usage limit. If the timer reaches the per-call limit, processing terminates the telephone call (see FIG. 7 and corresponding text for further details).

[0030] FIG. 2 is a high-level flowchart showing steps taken in a user managing telephone account information and requesting authorization to place a telephone call. Processing commences at 200, whereupon processing waits for a request from user 215 (step 210). When user 215 sends a request, a determination is made as to whether the user wishes to configure his account information transmittal interval (decision 220). For example, user 215 may wish to configure his account to automatically transmit account information to his telephone every 24 hours.

[0031] If user 215 wishes to configure his account information transmittal interval, decision 220 branches to “Yes” branch 222 whereupon transmittal configuration processing occurs (pre-defined process block 225, see FIG. 3 and corresponding text for further details). On the other hand, if the user does not wish to configure his account information transmittal interval, decision 220 branches to “No” branch 228 bypassing transmittal interval configuration steps.

[0032] A determination is made as to whether the user wishes to limit telephone usage (decision 230). For example, user 215 may wish to impose a $20 monthly limit on his telephone account. If the user wishes to limit telephone usage, decision 230 branches to “Yes” branch 232 whereupon limit usage processing occurs (pre-defined process block 235, see FIG. 4 and corresponding text for further details). On the other hand, if user 215 does not wish to limit telephone usage, decision 230 branches to “No” branch 238 bypassing usage limitation steps.

[0033] A determination is made as to whether user 215 wishes to retrieve telephone account information (decision 240). For example, the user may wish to know how many long distance minutes the user has incurred during the current month. If user 215 wishes to retrieve account information, decision 240 branches to “Yes” branch 242 whereupon processing provides account information (pre-defined process block 245, see FIG. 5 and corresponding text for further details). On the other hand, if user 215 does not wish to retrieve account information, decision 240 branches to “No” branch 248 bypassing account retrieval steps.

[0034] A determination is made as to whether user 215 wishes to place a telephone call (decision 250). If user 215 wishes to place a telephone call, decision 250 branches to “Yes” branch 252 whereupon call authorization processing occurs (pre-defined process block 255, see FIG. 6 and corresponding text for further details). On the other hand, if the user does not wish to place a telephone call, decision 250 branches to “No” branch 258 bypassing call authorization steps.

[0035] A determination is made as to whether to continue processing (decision 260). If processing should continue, decision 260 branches to “Yes” branch 262 which loops back to wait for the next request from user 215. This looping continues until processing terminates, at which point decision 260 branches to “No” branch 268. Processing ends at 270.

[0036] FIG. 3 is a flowchart showing steps taken in configuring an account information transmittal interval. Transmittal interval configuration processing commences at 300, whereupon user 315 selects a telephone account at step 310. In one embodiment, processing may require user 315 to step through an authorization sequence when accessing a telephone account (i.e. user name and password).

[0037] A determination is made as to whether user 315 wishes to automate an account information transmittal interval (decision 320). For example, user 315 may wish to configure processing to automatically send account information every 24 hours. If user 315 does not wish to configure automated information transmittal, decision 320 branches to “No” branch 322 bypassing account transmittal automation steps. On the other hand, if user 315 wishes to automate account information transmittal, decision 320 branches to “Yes” branch 328.

[0038] A determination is made as to whether user 315 wishes to set a time interval for transmitting account information (decision 330). Using the example described above, the user may wish to set a time interval for a 24-hour period. If user 315 wishes to set a time interval corresponding to transmitting account information, decision 330 branches to “Yes” branch 332 whereupon processing receives a time interval from user 315 and stores the time interval in account data store 390. Account data store 390 may be stored on a non-volatile storage area, such as a computer hard drive. On the other hand, if user 315 does not wish to specify a time interval for account information transmittal, decision 330 branches to “No” branch 338 bypassing transmittal interval steps.

[0039] A determination is made as to whether user 315 wishes to configure processing to send account information to the user's telephone after each telephone call (decision 350). If user 315 wishes to configure processing to send account information to his telephone after each telephone call, decision 350 branches to “Yes” branch 352 whereupon processing stores information (i.e. sets a flag) in account data store 390 signifying that account information should be sent to the user's telephone after each telephone call. On the other hand, if user 315 does not wish to have processing send account information to his telephone after each telephone call, decision 350 branches to “No” branch 358 bypassing after call transmittal steps. In one embodiment, the user may specify that account information should be sent after each long distance call.

[0040] A determination is made as to whether user 315 wishes to enable account information quick access (i.e. single button access). For example, the user may wish to configure his account to have processing send account information each time a single button is pushed, such as the “#” key. If user 315 wishes to enable account information quick access, decision 370 branches to “Yes” branch 378 whereupon quick access is enabled and the selected keystrokes (i.e. “#”) are stored in account data store 390 (step 380). On the other hand, if user 315 does not wish to enable account information quick access, decision 370 branches to “No” branch 372 bypassing quick access setup steps. In one embodiment, quick access information may be stored on the user's telephone. For example, the telephone may be programmed that when the “#” key is depressed, the telephone sends a service provider a sequence of numbers (i.e. 1,2,3,#) to access the user's account. Processing returns at 395.

[0041] FIG. 4 is a flowchart showing steps taken in limiting telephone calls corresponding to a telephone account. Processing commences at 400, whereupon user 415 selects an account (step 410). User 415 sends authorization information (i.e. user name and password) corresponding to the selected account (step 420). A determination is made as to whether user 415 is authorized to access the corresponding account information (decision 425). If user 415 is not authorized to access the corresponding account information, decision 425 branches to “No” branch 427 whereupon an error is returned to user 415 at 430.

[0042] On the other hand, if user 415 is authorized to access account information corresponding to his request, decision 425 branches to “Yes” branch 429 whereupon processing provides account information to user 415 from account data store 480 (step 435). Account data store 480 may be stored on a non-volatile storage area, such as non-volatile memory.

[0043] A determination is made as to whether user 415 wishes to configure limitations corresponding to his account (decision 440). For example, user 415 may wish to set limitations on his telephone usage in order to curb telephone charge costs. If user 415 does not wish to configure limitations corresponding to his account, decision 440 branches to “No” branch 448 bypassing limitation configuration steps. On the other hand, if user 415 wishes to configure limitations corresponding to his account, decision 440 branches to “Yes” branch 442.

[0044] A determination is made as to whether user 415 wishes to set a dollar amount limit corresponding to charges on his account (decision 450). Using the example described above, user 415 may wish to set a $20 monthly limit on telephone charges, regardless of the amount of minutes or long distance usage on the account. If user 415 wishes to set a dollar amount limit corresponding to charges on his account, decision 450 branches to “Yes” branch 452 whereupon processing receives a dollar amount limit from user 415 and stores the dollar amount limit in account data store 480 (step 455). On the other hand, if user 415 does not wish to set a dollar amount limit corresponding to charges on his account, decision 450 branches to “No” branch 458 bypassing dollar limitation steps.

[0045] A determination is made as to whether user 415 wishes to set a minute usage limit corresponding to his account (decision 460). Using the example described above, user 415 may have a calling plan that costs a specified amount which provides the user an allocated number of minutes and user 415 wishes to ensure that he does not exceed the number of allocated minutes. Another example is user 415 may wish to limit the amount of minutes for each call placed and received on his telephone. If user 415 wishes to limit the amount of minutes for use corresponding to his account, decision 460 branches to “Yes” branch 462 whereupon processing receives a minute usage limitation from user 415 and stores the minute usage limitation in account data store 480. On the other hand, if user 415 does not wish to specify a minute limitation corresponding to his account, decision 460 branches to “No” branch 468 bypassing minute limitation steps.

[0046] A determination is made as to whether user 415 wishes to block long distance calling (decision 470). Using the example describe above, user 415 may have a calling plan which costs a certain amount and provides him unlimited local calling but charges user 415 for long distance calls. If user 415 wishes to block long distance calling, decision 470 branches to “Yes” branch 472 whereupon long distance calling is blocked for the corresponding account (i.e. a flag is set) in account data store 480. On the other hand, if user 415 does not wish to block long distance calling, decision 470 branches to “No” branch 478 bypassing long distance blocking steps. Processing returns at 490.

[0047] FIG. 5 is a flowchart showing steps taken in providing telephone account information. Processing commences at 500, whereupon user 520 sends an account information request to service provider 530 (step 510). User 520's request may be from depressing a single button, or dialing a specialized number. A determination is made as to whether user 520's request is authorized (decision 540). For example, user 520's request may include a user name and password. If user 520's request is Rot authorized, decision 540 branches to “No” branch 542 bypassing account retrieval steps.

[0048] On the other hand, if user 520's request is authorized, decision 540 branches to “Yes” branch 548 whereupon service provider 530 sends corresponding account information from account data store 535 in which processing stores the account information in local data store 555 (step 550). Account data store 535 may be stored on a non-volatile storage area, such as a computer hard drive. Local data store 555 may be located in user 520's telephone and stored on a non-volatile storage area, such as non-volatile memory.

[0049] A determination is made as to whether to display the account information on display 575 located on user 520's telephone (decision 560). For example, user 520 may wish to review account information prior to placing a telephone call. If user 520 does not wish to display the account information, decision 560 branches to “No” branch 562 bypassing information-displaying steps. On the other hand, if user 520 wishes to display the account information, decision 560 branches to “Yes” branch 568 whereupon account information is retrieved from local data store 555 and displayed on display 575.

[0050] A determination is made as to whether to convert the account information to an audio message (decision 580). For example, user 520's telephone may not have a display and user 520 may wish to hear the account information through his telephone speaker. If processing should not convert the account information into an audio message, decision 580 branches to “No” branch 582 bypassing account information conversion steps.

[0051] On the other hand, if processing should convert the account information to an audio message, decision 580 branches to “Yes” branch 588 whereupon processing converts the account information to an audio message and sends the audio message to speaker 595 (step 590). As one skilled in the art can appreciate, processing may convert the account information to an audio message using a voice synthesizer. Processing returns at 599.

[0052] FIG. 6 is a flowchart showing steps taken in authorizing a telephone call using user imposed telephone account limitations. The telephone call may be a user placing a telephone call or a user receiving a telephone call. Call authorization processing commences at 600, whereupon account information is retrieved from account data store 610 (step 620). The account information includes limitations imposed on the account along with incurred usage of the account. Account data store 620 may be stored on non-volatile storage area, such as non-volatile memory.

[0053] A determination is made as to whether the account has reached a minute usage limitation (decision 630). If the account has reached a minute usage limit, decision 630 branches to “Yes” branch 632 whereupon processing blocks the corresponding call and sends a message to user 685 signifying the account has reached a minute usage limitation. On the other hand, if the account has not reached a minute usage limit or if a minute usage limitation is not imposed, decision 630 branches to “No” branch 638.

[0054] A determination is made as to whether the account has reached an imposed dollar limit (decision 640). If the account has reached an imposed dollar limit, decision 640 branches to “Yes” branch 642 whereupon processing blocks the corresponding call and sends a message to user 685 signifying the account has reached an imposed dollar limit. On the other hand, if the account has not reached an imposed dollar limit or if a dollar limit is not set, decision 640 branches to “No” branch 648.

[0055] A determination is made as to whether the corresponding telephone call is a long distance call (decision 650). If the telephone call is not a long distance call, decision 650 branches to “No” branch 652 bypassing long distance blocking checks. On the other hand, if the telephone call is a long distance call, decision 650 branches to “Yes” branch 657 whereupon a determination is made as to whether the account is configured to block long distance calls (decision 660). If the account is configured to block long distance calls, decision 660 branches to “Yes” branch 662 whereupon processing blocks the corresponding call and sends a message to user 685 signifying that the account blocks long distance calls. On the other hand, if the account does not block long distance calls, decision 660 branches to “Yes” branch 668 whereupon processing places the call to recipient 695 through communication network 690, such as the Public Switched Telephone Network (PSTN) or wireless network (pre-defined process block 670, see FIG. 7 and corresponding text for further details). Processing returns at 699.

[0056] FIG. 7 is a flowchart showing steps taken in setting a timer and placing a telephone call. Call connect processing commences at 700, whereupon usage limits are retrieved from account data store 715. Usage limits may limit the amount of time allowable for each phone call. For example, the usage limit may impose an allowable time limit of five minutes for each telephone call. Account data store 715 may be stored on a non-volatile storage area, such as non-volatile memory.

[0057] The timer is reset at step 720. Processing places the call between user 725 and recipient 735 and starts the timer (step 730). A determination is made as to whether the timer is approaching the usage limits (decision 740). If the timer is not approaching the usage limits, decision 740 branches to “No” branch 742 which loops back to check the timer. This looping continues until the timer approaches the usage limit, at which point decision 740 branches to “Yes” branch 748 whereupon a warning message is provided to user 725 at step 750. Using the example described above, a warning message may be provided to user 725 when the timer approaches four minutes.

[0058] A determination is made as to whether the timer has reached the usage limits (decision 760). If the timer has not reached the usage limits, decision 760 branches to “No” branch 762 which loops back to check the timer. This looping continues until the timer has reached the usage limits, at which point decision 760 branches to “Yes” branch 768 whereupon the telephone call is terminated (step 770). An audible message is provided to user 725 at step 780 signifying that the call has been terminated. Using the example described above, the telephone call is terminated when the timer reaches five minutes and processing sends a termination notification to user 725. Processing returns at 790.

[0059] FIG. 8 illustrates information handling system 801 which is a simplified example of a computer system capable of performing the invention described herein. Computer system 801 includes processor 800 which is coupled to host bus 805. A level two (L2) cache memory 810 is also coupled to the host bus 805. Host-to-PCI bridge 815 is coupled to main memory 820, includes cache memory and main memory control functions, and provides bus control to handle transfers among PCI bus 825, processor 800, L2 cache 810, main memory 820, and host bus 805. PCI bus 825 provides an interface for a variety of devices including, for example, LAN card 830. PCI-to-ISA bridge 835 provides bus control to handle transfers between PCI bus 825 and ISA bus 840, universal serial bus (USB) functionality 845, IDE device functionality 850, power management functionality 855, and can include other functional elements not shown, such as a real-time clock (RTC), DMA control, interrupt support, and system management bus support. Peripheral devices and input/output (I/O) devices can be attached to various interfaces 860 (e.g., parallel interface 862, serial interface 864, infrared (IR) interface 866, keyboard interface 868, mouse interface 870, and fixed disk (HDD) 872) coupled to ISA bus 840. Alternatively, many I/O devices can be accommodated by a super I/O controller (not shown) attached to ISA bus 840.

[0060] BIOS 880 is coupled to ISA bus 840, and incorporates the necessary processor executable code for a variety of low-level system functions and system boot functions. BIOS 880 can be stored in any computer readable medium, including magnetic storage media, optical storage media, flash memory, random access memory, read only memory, and communications media conveying signals encoding the instructions (e.g., signals from a network). In order to attach computer system 801 to another computer system to copy files over a network, LAN card 830 is coupled to PCI bus 825 and to PCI-to-ISA bridge 835. Similarly, to connect computer system 801 to an ISP to connect to the Internet using a telephone line connection, modem 875 is connected to serial port 864 and PCI-to-ISA Bridge 835.

[0061] While the computer system described in FIG. 8 is capable of executing the invention described herein, this computer system is simply one example of a computer system. Those skilled in the art will appreciate that many other computer system designs are capable of performing the invention described herein.

[0062] One of the preferred implementations of the invention is an application, namely, a set of instructions (program code) in a code module which may, for example, be resident in the random access memory of the computer. Until required by the computer, the set of instructions may be stored in another computer memory, for example, on a hard disk drive, or in removable storage such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network. Thus, the present invention may be implemented as a computer program product for use in a computer. In addition, although the various methods described are conveniently implemented in a general purpose computer selectively activated or reconfigured by software, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, in firmware, or in more specialized apparatus constructed to perform the required method steps.

[0063] While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that, based upon the teachings herein, changes and modifications may be made without departing from this invention and its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as are within the true spirit and scope of this invention. Furthermore, it is to be understood that the invention is solely defined by the appended claims. It will be understood by those with skill in the art that if a specific number of an introduced claim element is intended, such intent will be explicitly recited in the claim, and in the absence of such recitation no such limitation is present. For a non-limiting example, as an aid to understanding, the following appended claims contain usage of the introductory phrases “at least one” and “one or more” to introduce claim elements. However, the use of such phrases should not be construed to imply that the introduction of a claim element by the indefinite articles “a” or “an” limits any particular claim containing such introduced claim element to inventions containing only one such element, even when the same claim includes the introductory phrases “one or more” or “at least one” and indefinite articles such as “a” or “an”; the same holds true for the use in the claims of definite articles.