Patent application title: METHOD FOR CHARGING ON-LINE DIRECTORY ASSISTANCE SERVICES
Shawn E. Wiederin (Cedar Rapids, IA, US)
Richard G. Moore (Cedar Rapids, IA, US)
Richard G. Moore (Cedar Rapids, IA, US)
Duraisamy Gunasekar (Cedar Rapids, IA, US)
Gregory Mumford (Marion, IA, US)
Lonnie S. Clabaugh (San Pedro, CA, US)
Jon Abel (Cedar Rapids, IA, US)
Kolin G. Hogue (Kalona, IA, US)
Verizon Business Global LLC
IPC8 Class: AG06Q3000FI
Class name: Automated electrical financial or business practice or management arrangement accounting bill preparation
Publication date: 2010-03-11
Patent application number: 20100063913
An approach for providing an on-line directory assistance service system
for charging the directory assistance services that are provided over a
packet switched network is disclosed. The system includes a server that
tracks the number of directory listings that are transmitted to and
displayed on a client access device (e.g., non-PC devices) and to prepare
billing information based upon the number of directory listings. The
system also includes a database that is coupled to the server and that
stores the directory listings.
1. A method of charging for directory assistance services that are
provided over a packet switched network, the method comprising:tracking
number of directory listings that are transmitted to and displayed on a
client access device; andpreparing billing information based upon the
number of directory listings.
CROSS-REFERENCES TO RELATED APPLICATIONS
This application is a continuation of application Ser. No. 09/836,589, filed Apr. 17, 2001, which claims the benefit of the earlier filing date of U.S. Provisional Patent Application Ser. No. 60/198,480, filed Apr. 17, 2000, the entireties of which are incorporated herein by reference.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to information systems, and is more particularly related to charging for directory assistance that is provided over a packet switched network.
2. Discussion of the Background
Directory assistance services provide a viable source of revenue for telecommunication service providers and has proven to be an efficient mechanism for a customer to obtain information about a party whom the customer seeks to contact. Directory information is maintained by data providers (e.g., local exchange carriers (LECs), and Regional Bell Operating Companies (RBOCs), who provide directory "listings" to the telecommunication service providers for a fee. These data providers, as third parties to the service provider, typically require compensation when a listing is used. The conventional voice access directory assistance (i.e., local or national directory assistance) provides automated prompts to the customer to obtain the listing that the customer is seeking. This conventional system employs a live operator to ensure that the customer is given the proper listing. For example, a typical local scenario involves a customer dialing "411" on a telephone station and being prompted to state the name of the party that the customer seeks to contact as well as the city that the party resides. If there exists multiple listings, the live operator may intervene to gather more detailed information so that the correct and intended listing is provided. The live operator may, for instance, ask the customer to provide address information to determine which one of the multiple listings the customer seeks to obtain; thereafter, a proper determination of the desired listing can be made by the live operator. In this manner, only the actual listing that the customer utilizes translates into a charge for the customer; that is, the customer is not charged for multiple listings. For the purpose of usage tracking, standard call detail records can be employed to track charges. Additionally, such a directory assistance system ensures accuracy of the listing through the intervention of a live operator. For the service provider, the greater time that is spent servicing a particular customer through operator intervention, the greater the loss of potential revenue, in terms of opportunity cost.
Given the popularity of the World Wide Web--for that matter, the Internet in general--on-line directory services have emerged to provide an analogous service to that of the telephony based directory service. However, usage tracking with respect to on-line directory service systems is difficult and infeasible. Accordingly, many directory services that are provided online are provided as a free service, potentially resulting in a lost of revenue to the service provider. In the implementations in which the service provider charges for use of the directory listings, there exists no mechanism to determine which listings are used by the customers. Consequently, the service provider has to compensate for all the directory listings, irrespective of use, resulting in over-compensation of the data providers. This approach may result in an unnecessarily high cost to the service provider, and thus, the customers. Also, inaccurate tracking can result in potential fraud, as the customer is in a position to easily deny retrieval of the listings.
Further, currently on-line directory services lack comprehensive information about a particular party. With the information explosion, individuals in today's modern society can be reached via many other means than the conventional land-line telephone directory number. For example, these individuals possess numerous contact information, such as e-mail addresses, URLs (Uniform Resource Locator) information (i.e., web site), cellular telephone number, facsimile number, pager number, post office addresses, etc. Such comprehensive information is expensive to maintain, particularly, if the service provider cannot adequately track usage of the information; the cost of subscribing to the database of the data provider would be cost prohibitive for the service provider. Moreover, data integrity poses a challenge as such contact information necessitates continual updating.
Based on the foregoing, there is a clear need for improved approaches for providing directory services on-line to permit a service provider to charge for the services. There is also a need to accurately track use of the directory listings. In addition, there is a need to provide directory services to customers cost-effectively. There is also a need to minimize development and implementation costs. Therefore, an approach for providing retrieval of information which can be tracked and maintained cost-effective is highly desirable.
SUMMARY OF THE INVENTION
The present invention addresses the above stated needs by providing a directory assistance system that enables a service provider to charge for directory assistance services.
According to one aspect of the invention, a method of charging for directory assistance services that are provided over a packet switched network is disclosed. The method includes tracking number of directory listings that are transmitted to and displayed on a client access device, and preparing billing information based upon the number of directory listings. The above arrangement advantageously provides accurate usage tracking of the desired information.
According to another aspect of the invention, a server apparatus for charging for directory assistance services that are provided over a packet switched network is disclosed. The server apparatus includes a processor that is configured to track number of directory listings that are transmitted to and displayed on a client access device and to prepare billing information based upon the number of directory listings. Additionally, the server apparatus includes a memory that is coupled to the processor and is configured to store the number of directory listings. This arrangement advantageously provides a cost-effective mechanism for obtaining directory listings.
According to another aspect of the invention, a server apparatus for charging for directory assistance services that are provided over a packet switched network is disclosed. The server apparatus includes means for tracking number of directory listings that are transmitted to and displayed on a client access device, and means for preparing billing information based upon the number of directory listings. This arrangement advantageously enables a service provider to charge for rendering directory assistance services over a packet switched network.
According to one aspect of the invention, an on-line directory assistance service system for charging for directory assistance services that are provided over a packet switched network is disclosed. The system includes a server that is configured to track number of directory listings that are transmitted to and displayed on a client access device and to prepare billing information based upon the number of directory listings. The system also includes a database that is coupled to the server and is configured to store the directory listings. Under this approach, a customer may obtain directory assistance cost-effectively.
In another aspect of the invention, a computer-readable medium carrying one or more sequences of one or more instructions for charging for directory assistance services that are provided over a packet switched network is disclosed. The one or more sequences of one or more instructions include instructions which, when executed by one or more processors, cause the one or more processors to perform the steps of tracking number of directory listings that are transmitted to and displayed on a client access device; and preparing billing information based upon the number of directory listings. This approach advantageously permits accurate accounting and billing for directory assistance services.
A more complete appreciation of the invention and many of the attendant advantages thereof will be readily obtained as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings. wherein:
FIGS. 1A and 1B are diagrams of exemplary embodiments of a communications system that is capable of providing directory assistance services, in accordance with the present invention;
FIG. 2 is a diagram of a database that stores directory assistance information, in accordance with an embodiment of the present invention;
FIG. 3 is a flow chart of a process for retrieving information, in accordance with an embodiment of the present invention;
FIGS. 4A-4D are diagrams of screens relating to residential directory listings of a graphical user interface (GUI) used in the system of FIG. 1, in accordance with an embodiment of the present invention;
FIGS. 5A-5C are diagrams of screens relating to business/government directory listings of the graphical user interface (GUI) used in the system of FIG. 1, in accordance with an embodiment of the present invention; and
FIGS. 6A and 6B are diagrams of screens relating to reverse searching of the graphical user interface (GUI) used in the system of FIG. 1, in accordance with an embodiment of the present invention;
FIG. 7 is a flow chart of a process for maintaining enhanced content in a database, in accordance with an embodiment of the present invention;
FIG. 8 is a diagram of an enhanced content data entry screen of a GUI, in accordance with an embodiment of the present invention;
FIG. 9 is a flow chart of a billing process associated with charging for the system of Figure!, in accordance with an embodiment of the present invention;
FIG. 10 is a flow chart of transaction-based billing process, in accordance with an embodiment of the present invention; and
FIG. 11 is a diagram of a computer system that is capable of performing directory assistance and billing functions, in accordance with an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of the invention. However, it will be apparent that the invention may be practiced without these specific details. In some instances, well-known structures and devices are depicted in block diagram form in order to avoid unnecessarily obscuring the invention.
Although the present invention is discussed with respect to directory assistance services over the Internet and intranets, it is recognized that the information retrieval mechanism may be used for any type of information over any packet switched network.
FIGS. 1 A and 1B show diagrams of a communications system that is capable of providing directory assistance services, in accordance with the present invention. As seen in FIG. 1A, a web-based directory service (WBDS) 102 utilizes a directory assistance database 104 to store directory information. Unlike the conventional on-line directory services, a billing mechanism is integrated within the WBDS 102 through the use of billing server 106 so that the service provider may charge for the on-line directory assistance services. The billing process is more fully described later.
The WBDS 102 may be accessed through any number of networks, including a wireless network 108, the global Internet 110 via a secured connection (e.g., SSL (Secure Socket Layer)), and a private network 112 (e.g., corporate intranet). It should be noted that the wireless network 108 and the intranet both have connectivity to the Internet 110 such that directory information from the WBDS 102 may originate through direct links to the WBDS 102 or through the Internet 110. The wireless network 108 supports a number of wireless access devices 114, which may be non-PC devices; these devices 114 may include a PDA (personal digital assistant), a web-appliance, an e-mail client, a web-enabled cell phone. Similarly, any IP (Internet Protocol) enabled device 116 and 118 may access the directory information through the Internet 110 and the intranet 112, respectively. These IP-enabled devices 116 and 118 may include a PC as well as the devices described with respect to the wireless network 108. FIG. 1B below shows an implementation of a corporate intranet, whereby the business user may cost-effectively utilize the directory assistance services supported by WBDS 102.
In FIG. 1B, a communication system 100 provides web-based access to a directory assistance database 101 of a service provider. It should be noted that the directory assistance database 101 is shown as multiple physical databases; however, it is recognized that a single physical database may be employed. In this exemplary embodiment, a customer--which in this example is a corporate entity--may retrieve directory listings stored within the directory assistance database 101 through the customer's network 103, which includes access devices (e.g., client stations) 105 that connect to a corporate intranet 107. The access devices 105. in addition to a personal computer, may include any device that is capable of initiating a query and retrieving information from database 101, such as a personal (PC). a PDA (personal digital assistant), a web-appliance, an e-mail client, a web-enabled cell phone, and non-PC (personal computer) device. The client stations 105 are configured with web-browsers, supporting the Hypertext Transfer Protocol (HTTP). Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems and is more fully described in the Internet Engineering Task Force (IETF) RFC 2616, which is incorporated herein' by reference in its entirety. To communicate externally, the customer network 103 utilizes a proxy server 109 that communicates to a gateway router 111. Additionally, a firewall 113 provides security for the customer network 103 for the connection to an external network 115; although the firewall 113 is shown as a separate component, the firewall 113 may be alternatively be provided by the gateway router 111.
The external network 115 may be provided by a carrier to establish connectivity between the customer network 103 and the network 117 of the service provider. The external network 115 may be implemented according to any number of technologies: Asynchronous Transfer Mode (ATM), frame relay, and secure IP (Internet Protocol); additionally, the network 115 may be a circuit switched network (e.g., T1, T3, etc.). As seen in FIG. 1, the network 117 similarly employs a firewall 119 to prevent network intrusion from a source outside of network 117. An internal network 121 attaches to a router 123, which in turn connects to a Fiber Distributed Data Interface (FDDI) ring network 125; it is recognized by one of ordinary skill in the art that any high-speed network may be utilized.
The FDDI ring network 125 provides a high-speed transport mechanism between router 123 and another router 127, which in turn connects to a switch 129. The switch 129 processes traffic from web and application servers 131. A local area network (LAN) 133, such as an Ethernet network, permits the web and application servers 131 to communicate with the directory assistance databases 101.
The system 100 allows business customers, for example, to access residential, business or government phone listings electronically from their corporate intranets 107. Alternatively, the customer may employ other mechanisms to access directory information that are stored in the directory assistance databases 101; these other access mechanisms may include a PC, a PDA, a web-appliance. an e-mail client, a web-enabled cell phone, and non-PC device. In this exemplary embodiment, the customer utilizes a client browser 105 to submit a request (or information query) to a web and application server 131, which returns a result based upon the information that is stored within the directory assistance databases 101. The graphical user interface (GUI) associated with the client browsers 105 is shown in FIGS. 4-6. That is, directory assistance database 101 may store information that is acquired from local exchange carriers (LECs), Regional Bell Operating Companies (RBOCs), and third party proprietary databases. Directory assistance listings are normally purchased by the service provider from such data providers. Database 101, according to one embodiment of the present invention, contains basic listing information: name, directory number, and address. To compensate these data providers accurately, it is necessary to keep track of accessed and viewed listings.
The result of the request may be a set of zero or more listings with information that is partially hidden, which in an exemplary embodiment, is the phone (i.e., directory) number. As more fully discussed below, partially hiding information allows the customer to determine which one of the listings the customer would like to view, and thereby, forces the customer to "select" the desired listing. The hidden information associated with the selected listing is subsequently made visible. This selection is tracked by the system 100. In particular, selecting a listing causes information about the listing to be stored by the service provider for subsequent back-end processing, such as billing, reporting, and compensation to third party data providers.
The directory assistance services of system 100 possess a number of value-added services and capabilities. Unlike conventional directory assistance system 100 permits the retrieval of information beyond that of name and telephone number. The information, according to one embodiment of the present invention, may be classified as basic content or enhanced content. Databases 101 may store an enhanced listing that includes, for example, e-mail addresses, a mobile number, a voice mail number, a URL, etc., in addition to the basic content of name, directory number, and address. A feature of the directory assistance service of system 100 is the ability to permit the customers, with respect to the enhanced content, to add, delete, or change (i.e., modify in some manner) the information. System 100 also provides sophisticated query capabilities (e.g., similar spellings, sounds like, etc.). Accordingly, system 100 significantly reduces a customer's directory assistance cost over the conventional voice access mechanism by providing a web-based interface to directory information for the users to easily, efficiently, and accurately obtain directory listings.
The on-line directory assistance service is also supported by a call center (not shown). The call center may provide a web-based text chat capability to answer questions that the customers may have, in addition to communication via telephone in the event that the customer elects to confer with the operator via the phone.
As shown, communication system 100 employs a billing server 135, which is attached to LAN 133. The billing process, according to one embodiment of the present invention, is described later in FIG. 9. System 100, via the billing server 135, supports a variety of billing methods for the directory assistance service: Transactional (Event) Based Fee, Per Seat (or Per User), Flat Rate Fee, Volume Based Fee, and a combination thereof. In the transaction based fee arrangement, the customer is charged a certain amount for each online directory assistance lookup that is performed, or is charged for the number of listings successfully accessed and viewed for each search. This fee is independent of the number of directory assistance queries that are performed during any time period, with the exception of queries that exceed thresholds that are previously agreed upon between the service provider and the customer. For example, if a customer consistently performs 20,000 queries per day, and then performs 50,000 queries another day (i.e., agreed threshold), then incremental billing may take into effect for that customer. The customer may be charged a flat fee or incremental transaction fee for the incremental queries (30,000 in this example) that exceed an agreed upon average number of queries during a time period. The directory assistance services also support billing and invoicing based upon a categorization of the user or entity within a company (i.e., customer); i.e., IP address, company location or the entire company. The transaction based billing process is more fully described with respect to FIG. 10.
The per seat charge method calculates a fee based upon the number of users. In the flat rate fee, the customer is charged a one-time fee for all online directory assistance queries that are performed over the life of the contract with the customer. The company is charged a flat rate fee for all online directory assistance queries that are performed during a particular time period, which may be daily, weekly, monthly, quarterly or yearly. The fee is independent of the number of transactions with the exception of queries that exceed thresholds agreed upon between service provider and the customer.
As regards the volume based fee, the customer is charged a predetermined amount for a certain number of directory assistance look-ups within a defined range for particular time period, in which overage may be assessed a different fee. Lastly, any combination of the above methods can be employed. The system 100 provides the customers with the ability to view the billing invoice online, and to have their bills delivered to them via various mechanisms: e-mail, fax, and etc.
System 100 provides secure access to the directory assistance databases 101 and associated applications. In particular, the system 100 supports authentication and authorization of the directory assistance capabilities; authorization is granular to the level of content within the databases 101 (i.e., varying levels of private data and public data). Commercial customers and third party developers are provided with secure access to the directory assistance data (basic and enhanced content). It is noted that any content that is specific to a customer is only accessible by that customer that owns that data.
Furthermore, system 100 provides a rich set of reporting functionalities. Reports may be prepared for any time period: daily, weekly and monthly. One report may represent the number of page views for each page on the portal or web site. Another report may reveal the number of access to the directory assistance database 101 (transactions) by customer (and third party developers). The system 100 may generate a report that shows the actions that were performed on each page, for example, the total number of click throughs for customer service. Additionally, the reports may be tailored for each customer. As earlier noted, these reports may be generated and displayed through the web browser.
FIG. 2 is a diagram of a database that stores directory assistance information, in accordance with an embodiment of the present invention. As shown in FIG. 2, the directory assistance database 101 may upload the data from a third party data provider 203 via a gateway 205. A customer 207, therefore, is able to access directory information stored within directory assistance database 101 through the use of a browser on a client station 105 (FIG. 1) or some other access device, such as a PDA, web-appliance, an e-mail client, web-enabled cell phone, or any non-PC device. Directory assistance database 101 contains multiple directory listings, in which each listing 201 (or directory) may include the following basic fields: a name field, a listing number field, and an address field. The listing number field, in an exemplary embodiment, specifies a land-line telephone number. Database 101 may also store enhanced fields (i.e., enhanced content) that may be tailored to the particular needs of the customers; according to one embodiment of the present invention, these enhanced fields include the following: one or more e-mail address fields, a fax number field, a mobile number field, pager number field, a voice-mail number field, and a URL field. According to one embodiment of the present invention, the customer is able to maintain the enhanced content.
Database 101 is extensible to allow for integration or association with enhanced content in other databases (not shown). Further, the directory assistance services afford the customer the functionality to add new content, delete content, or change the enhanced content. The mechanism for modifying the enhanced data (e.g., e-mail addresses. fax number, mobile number, pager number, voice-mail number. and URL) includes the web browser 105. as well as other access devices (e.g., PDAs, cellular phones, web appliances, and etc.). The basic content of the directory assistance data is modified by the service provider.
As previously mentioned, the system 100 may be used to manage other types of information with other applications, beyond that of directory assistance data. The system 100, for example, permits commercial customers and third party developers to integrate the directory assistance services into their environment, or have the ability to easily access the directory assistance services data from their intranet. This integration is supported by a Software Development Toolkit (SDK), without requiring extensive systems integration or development effort. Also, commercial customers have the capability to create a link from their intranet into the directory assistance platform.
As stated, system 100 can be adapted to a variety of different applications that are separate or supplemental to the directory assistance services. One application of system 100 is the management of credit cards, whereby the service provider enables the customers to manage a list of credit cards securely. This list of credit cards may be used to notify the corresponding credit card companies in the event that any one of the cards is lost or stolen. The system 100 may also enable users to select a notification method when someone queries their listing. For example, a customer is paged when someone requests the customer's directory assistance listing. Additionally, the database 101 may store demographic information that is tied to the individual listings. Further, the system 100 may provide password authentication and authorization services.
The above directory assistance database 101, in conjunction with the web and application server 131, provides numerous advantages over the conventional on-line directory service systems. The directory service, according to one embodiment of the present invention, maintains high data accuracy, in part, through the continual updating of directory listings, which are provided by the third party data providers (e.g., LECs and RBOCs). as well as the source of the data. In an exemplary embodiment, the directory service of system 100 obtains a majority of the data (over 99%) directly from the RBOCs via a daily feed; RBOC data is considered an accurate source for directory listing data. Conventional online directory listing data providers obtain their data typically every 30-90 days from data sources that are non-RBOC sources. These data sources rely on manual entry or scanning of data into their databases, which has a high probability for error. By contrast, the system 100 utilizes automation (e.g., electronic data interchange) to obtain the data. Because of their data updating methods, the non-RBOC data sources are typically 90 days or more out-of-date, from an accuracy standpoint; accordingly, data integrity is compromised under the conventional approach. From the service provider perspective, the implementation of the directory assistance service provides a new revenue source with minimal hardware/software modifications to the existing directory assistance architecture of the voice access system.
FIG. 3 is a flow chart of a process for retrieving information, in accordance with an embodiment of the present invention. In general, the concept of information retrieval, according to the present invention, is to permit the customer to select the desired information based upon viewing a portion of the information. The capability to view the information partially allows the customer to retrieve accurate data that is reflective of the customer's, and to pay for only those selected directory listings that are actually used (i.e. accessed and viewed). In this manner, the third party data provider is only compensated for the listings that are accessed and viewed by the customer. In step 301, a user requests information from the web and application server 131 via client browser 105. The web and application server 131 responds to the user request, as in step 303, by generating a response message that contains one or more rows of directory listings. The user may be limited to a predetermined maximum number of records/entries (i.e., rows) that are returned in the results of the online request (i.e., directory assistance query).
Within the response message, there are four types of data, wherein any number of each type of data exists in each row: viewable data, hidden data, encrypted data, and state data. Viewable data is directly viewable by the user through the client browser 105. Hidden data provides a place holder for information that can be displayed; for example, the information is masked by characters that indicate that the true information is not shown, e.g., "XXXXXX". Each block of hidden data has a corresponding encrypted block (i.e. hidden data), which is not directly viewable by the user. Lastly, state data relating to billing and reporting capabilities refer to information that is passed back to the user, and subsequently forwarded to the web and application server 131 upon selection of a row; state data need not be maintained by the server 131. The state information may be stored in the client stations that are running the client browsers 105.
In step 305, the user is presented with one or more rows of listings from database 101 correspond to the request and selects the desired listing. The user views the viewable and hidden data and determines which row corresponds to the listing that the user seeks. The method of selection depends on the particular type of user interface being used. The user selects a particular row of information. In the specific case of a web browser as the user interface (as shown below in FIGS. 4 and 5), a combination of viewable and hidden data is sent back to the user as an "anchor" (URL, or link), that can be "clicked".
Thereafter, upon selection of the desired row, the client browser 105 transmits encrypted data and state data to the web and application server 131, per step 307. It should be noted that the selection of listing process is generic and could be used in any system requiring server stateless selection capability. Next, in step 309, the server decrypts the encrypted data. At this point, if the billing and reporting functions are invoked (step 311) by an external process, for example, then the web and application server 131 prepares the billing information and the reports based upon the state data, per step 313. In step 315, the server 131 sends the decrypted data back to the client browser 105. The user can now view the entire row of data (step 317). It is this selected row that the customer is charged and upon which the data provider is compensated.
The above process is executed through a series of web pages; the GUI, according to an embodiment of the present invention, enables the user to navigate between the various web pages by clicking on the corresponding links. These web pages are discussed below.
FIGS. 4A-4D show GUI screens relating to residential directory listings, in accordance with an embodiment of the present invention. To retrieve a residential listing, a user via client browser 105 is presented with a residential search screen 400, shown in FIG. 4A. Screen 400 lists all of the available searches as links: a Residential Search link 401, a Business/Government search link 403, and a Reverse Search link 405. Because screen 400 is in fact the residential search page, the Residential Search link 401 is disabled (i.e., only a screen refresh is triggered). However, the user can easily navigate to a business/government search page by clicking on the Business/Government search link 403 if the user desires to obtain information about an individual or organization associated with a business organization or a government entity: the business/government search page is described further with respect to FIGS. 5A-5C. The residential search page (i.e., screen 400), in an exemplary embodiment, serves as the default screen (or page) that is first displayed by the client browser 105. The Reverse Search link 405 directs the user to a reverse search page in which the user may perform a search to determine the name and address of the party or organization by inputting the 10-digit telephone number; this reverse search capability is more fully discussed in FIGS. 6A and 6B.
Screen 400 contains a Feedback link 407 to a feedback page that permits the user to comment on the directory assistance service so that the service provider can make future enhancements to the service. A Help link 409 is also provided to assist the user by supplying information and tutorials on the functional capabilities of the directory assistance service application. Upon clicking on the Help link 409 by the user, the client browser 105 displays a separate window that contains, for example, Frequently Asked Questions (FAQs) instructions.
To perform a search for a residential listing, the user is provided with a number of text boxes corresponding to name and address information, as enumerated in Table 1, below. That is, these text boxes (i.e., fields) constitute the input search criteria. A Last Name box 411 permits the user to enter the last name of the party that is the subject of the search; according to one embodiment of the present invention, this Last Name box 411 may be specified as a required field. That is, the search cannot proceed until the user enters information in box 411. A First Name box 413 is also provided to narrow the search. If the user has information about the address of the party, then the user may enter any or all of the address information into the following address boxes: Street Name box 415 specifying the street name of the address, a City box 417, and a State box 419. State box 419, in this exemplary embodiment, has a pull-down menu for the states to minimize typing. Screen 400 further provides an Area Code box 421 for entry of an area code, if known. It is noted that unless a box is indicated as being -required" in some manner, it is an optional box. For instance, all required fields may be marked with an asterisks (*) and a note that indicates that these asterisked fields are required.
Searches are performed based on the entered information. These searches are conducted by the web and application server 131, which examines records that match the entered information (i.e., element), such that at least the record element field starts with the specific element information that was entered.
TABLE-US-00001 TABLE 1 Validations Required (If Element is Data Element Description Input? entered.) Last Name Last name of the Yes At least one directory assistance character in listing length Alphabetic First Name First name of the No Alphabetic directory assistance listing Address Address (Street No Alphanumeric only - not house number) of the listing City City of the directory No Alphabetic assistance listing State State of the directory No Pull-down assistance listing display Area Code Area Code (NPA) of the No 3 digits (NPA) directory assistance numeric listing
FIG. 4B shows an exemplary entry, in which the user has knowledge of only the last name and the city and state of the subject party; in this case, the user initiates a query for a person with the last name of "Miller" residing in Keystone, Iowa. Upon entering as much information as is available to the user, the user may launch the search by clicking on a Search button 423. A Reset button 425 exists to clear the text from all of the boxes. To help the user with the entry of information via screen 400, a number of error messages relating to the residential searches are provided. For example, if at least one character is not entered into the Last Name field 411, an error message is displayed in an error pop-up window. Also, if the data entered into the Last Name field 411, a First Name field 413, a City field 417 are not alphabetic, an error message results. Further, if the data that are entered into the Area Code (NPA) 421 is not numeric or three digits in length, an error message is also provided in this instance.
FIG. 4c shows a residential search result screen 431, according to one embodiment of the present invention. The data that is displayed in screen 431 in response to the query that was submitted by the user through screen 400 is listed below in Table 2.
TABLE-US-00002 TABLE 2 Data Element Description Last Name Last name of the directory assistance listing First Name First name of the directory assistance listing Address Address (Street and House number) of the listing City City of the directory assistance listing State State of the directory assistance listing Zip Zip code of the directory assistance listing Area Code Area Code (NPA) of the directory assistance (N PA) listing Number 7-digit number associated with the record's Area Code (NPA)
In an exemplary embodiment, the results from this search are sorted in ascending by field values in the following hierarchy: Last Name field 411, First Name field 413, State field 419, City field 417, and Directory Number (Area code+telephone number). A search result number field 433 specifies the number of listings found for the query that was submitted by the user. In this example, the search for "Miller" yields two listings (or rows) 433 and 435, whereby the basic content of name, address, and the area code of the telephone number are provided. Rows 435 and 437 provide visible data in form of the name, and various portions of the address and telephone number (i.e., area code). The "XXXX" characters hide some of the data associated with the telephone number and the ZIP code of the address; the hidden data (e.g., telephone number beyond the area code) is not shown until the user selects the particular row. The purpose of the partial display of information is to ensure that the user is selecting the correct listing. The determination as to what is hidden data can be specified by the service provider; for example, the street number in the address fields of rows 435 and 437, respectively, may be hidden. In this example, the phone numbers in rows 433 and 435 are hidden data, as indicated by the "XXXXXXX" characters. At this point, the user may be reminded of the correct party based upon the first names, full address information, and/or the area code; for instance, the user may vaguely remember that Lonnie and Gail are a couple. Consequently, the user may select the proper listing. In other words, to view a listing, the user selects the phone number of the listing that the user would like displayed. thereby minimizing the receipt of incorrect, and therefore, useless information. In this scenario, the phone number for Lonnie & Gail Miller is selected, in which the entire 10-digit phone number would subsequently be displayed.
Screen 431 includes a number of links to refine the search or conduct a new search. A Modify Search link 439 is supplied at the top of screen 431 as well as the bottom. The Modify Search link 439 directs the user to a search page that may enable the user to provide more information about the party; the prompts may take the form of the entry boxes of screen 400. By clicking on the Modify Search link 439, the user is presented with a search page to with the information previously keyed into the criteria boxes (i.e., fields) are displayed as well. In addition, a New Search link 441 permits the user to enter a new search.
Similar to screen 400, the residential search result screen 431 possesses a residential search link 443, a Business/Government Search link 445, a Reverse Search link 447, a Feedback link 449, and a Help link 451.
FIG. 4D shows a selected search result screen 461, wherein all of the information of the selected row are visible. In this example, the user has selected "Lonnie & Gail Miller" as the proper party back in screen 431. As a result, web and application server 131 provides the telephone number 463 as visible data in screen 461 of client browser 105; the new visible data corresponds to the hidden data.
For the purpose of explanation, the search screen 400 and associated result screens 431 and 461 are described with the basic content of the directory listing; that is, the listings convey the name, address, and directory number. The listings 435 and 437 show the basic content of the directory listings. Alternatively, the data selection screen 400 may supply the enhanced content (e.g., e-mail address, mobile number. fax number, pager number, voice-mail number, and URL).
FIGS. 5A-5C show the GUI screens relating to business/government directory listings, in accordance with an embodiment of the present invention. To query for a business or government listing, the user may click on the Business/Government link 403 from the residential search screen 400. This link 403 accordingly directs the user to a business/government search screen 500, which possess similar navigational links as the residential search screen 400: a Residential search link 501, a Business/Government link 403, a Reverse Search link 505, a Feedback link 507, and a Help link 509. The business/government search screen 500 provides a similar entry format as that of residential search screen 400, and includes the following fields: a Business Name field 511, a Street Name field 513, a City field 515, a State field 517, and an Area Code field 519. The properties of these fields 511, 513, 515, 517, and 519 are enumerated in Table 3, below:
TABLE-US-00003 TABLE 3 Validations Required (If Element is Data Element Description Input? entered.) Name A part of the name Yes At least one of the directory character in assistance listing length Alphanumeric Address Address (Street No Alphanumeric only - not house number) of the listing City City of the directory No Alphabetic assistance listing State State of the directory No Pull-down assistance listing display Area Code Area Code (NPA) of the No 3 digits (NPA) directory assistance numeric listing
Screen 500 also contains a Search button 521 and a Reset button 523 to submit the query and to clear the information in the fields, respectively.
In this example, the user knows only a few letters in the name of the business, and thus, may enter only those known letter, utilizing wild card characters to designate variable or unknown characters. In this example, the user only knows that the name of the business has a "Ta" and a "Be" in the name. Consequently, the entry into the required Business Name field 511 is "Ta*" and "Be*", wherein the asterisk represents wild card characters. At this point, the user may submit the query by clicking on the Search button 521. After processing this query, the web and application server 131 returns data to the client browser 105 via a business/government search result screen 531, as shown in FIG. 5B.
FIG. 5B has the same look-and-feel as that of the residential search result screen 431. A search result number field 533 indicates the number of listings the query yielded, which in this case is three. The three listings 535, 537, and 539 correspond to business names that satisfy the query: "Ta*" and "Be*". It is noted that each of the listings may have multiple locations, such as listing 537 and 539. Next, the user may click on the desired listing. If the results are not what the user seeks, then the user may modify the search by clicking on a Modify Search link 541 or start an entirely new search via a New Search link 543.
Further, screen 531 provides links that are similar to that of the search result screens 431 and 461: a Residential Search link 545, a Business/Government Search link 547, a Reverse Search link 549, a Feedback link 551, and a Help link 553.
Continuing with the example. it is assumed that the user is seeking a Taco Bell that is located on 624 1st Avenue, the user merely clicks on the desired field 555. In response to this selection input from the client browser 105, the web and application server 131 returns visible data corresponding to the selected row 539, as shown in FIG. 5c.
As evident from the discussion above, the selection process enables the service provider to compensate data providers based on which listings are accessed and viewed. By contrast, conventional directory systems do not readily permit charging of directory information, in part, because it may be difficult to track the listings that are accessed and viewed by the customers.
In addition to performing queries to determine the telephone numbers of the residential party or business/government entity, the directory assistance services that are supported by the service provider's network 117 permits the retrieval of information based upon a telephone number (i.e., reverse search). This function is useful if the user does not recall the name of the party associated with the telephone number; for example, if the user writes down the telephone number, but not the name and later forgets, then the reverse search is of particular use. The reverse search is discussed below with respect to FIGS. 6A and 6B.
FIGS. 6A and 6B show the GUI screens relating to reverse searching, in accordance with an embodiment of the present invention. A reverse search may be initiated from any of the Reverse Search links; for example, links 405 and 505 of screens 400 and 500, respectively. Reverse Search screen 600 includes a Residential search link 601, a Business/Government link 603, a Reverse Search link 605, a Feedback link 607, and a Help link 609, which are common to screens 400 and 500 as well. The user enters the telephone number in a Phone Number field 611 and launches the query by clicking on a Search button 613. If the user enters an erroneous number, the user may clear the entry by using a Reset button 615.
The user is alerted with various error messages if the entry into the Phone Number field 611 is improper. For instance, if data is incomplete (e.g., the Area Code has been omitted), then an error message is displayed, as in a pop-up window. Also, if the entered data is not numeric, an error message indicating so is displayed. If the entry is proper, the web and application server 131 proceeds with processing the query, resulting in return of one or more listings, as shown in FIG. 6B.
FIG. 6B shows the reverse search result screen 631, which includes the links that are common to, for example, result screens 431 and 531: a Modify Search link 633, a New Search link 635, a Residential Search link 637, a Business/Government Search link 639, a Reverse Search link 641, a Feedback link 643, and a Help link 645. In an exemplary embodiment, the results, listings 647 and 649, are sorted in an ascending manner by field values in the following hierarchy: Last Name, First Name, State, City, and Directory number (Area code+telephone number). These fields are described below in Table 4.
TABLE-US-00004 TABLE 4 Data Element Description Last Name/ In the case of a residential listing - the last Business Name name of the directory assistance listing. In the case of a business/government listing - the name associated with the business/government listing. First Name First name of the directory assistance listing (applicable for residential listings only.) Address Address (Street and House number) of the listing City City of the directory assistance listing State State of the directory assistance listing Zip Zip code of the directory assistance listing Area Code Area Code (N PA) of the directory assistance (NPA) listing Number 7-digit number associated with the record's Area Code (NPA)
For the purpose of illustration, the search result screen 631 provides multiple listings for the reverse search. It is, however, more common to receive a single listing, as directory numbers are typically unique to a particular party.
In addition to information retrieval, the customer is afforded the capability to maintain its own enhanced content in database 101, as shown in FIG. 4B.
FIG. 7 shows a flow chart of a process for maintaining enhanced content in a database, in accordance with an embodiment of the present invention. The web and application server 131 provides a mechanism for the customer to modify, add, and delete directory listings that are stored within database 101 with respect to the enhanced content. As discussed above, the enhanced content may include any number of parameters that the customer wishes to maintain for the particular directory listing; e.g., one or more e-mail address fields, a fax number field, a mobile number field, pager number field, a voice-mail number field, and a URL field. It is recognized that the specific enhanced data depends on the type of party the listing pertains. For example, a business will not usually have a mobile telephone number; however, it is common for an individual person to have such a number. First, the user navigates to the data entry screen for the enhanced content, per step 701. Next, the server 131 returns an entry screen depending on whether the user seeks to add a new entry or modify an existing entry. FIG. 8, below, shows an exemplary entry screen for modifying an existing entry. Subsequently, the user via client browser 105, as in step 703, enters the enhanced data. If more data entry is needed as determined by step 705, the user repeats step 703. Once the data entry is complete, the server 131 processes the new enhanced data, per step 707. Thereafter, the server 131 instructs the update of the enhanced data in database 101.
FIG. 8 shows diagram of an enhanced content data entry screen of a GUI, in accordance with an embodiment of the present invention. In this example, it is assumed that the user has entered information about the particular listing that the user wishes to modify prior to the display of the screen 800. The data entry screen 800 displays the basic content of the listing 801 that the user has entered, which in this case, is a business by the name of "Acme Cans." The user has wishes to maintain additional information about this particular listing; specifically, the user seeks to input a facsimile number, an e-mail address, and the URL of Acme's website. These data can be entered through the corresponding fields: a facsimile number field 803, an e-mail address field 805, and a URL field 807. Upon entering the information, the user can submit the new enhanced data by clicking on a Submit button 809. If the user wishes to clear all of the fields 803, 805, and 807, then the user may use the Reset button 811. The above entry screen and associated entry process of FIG. 7 provides significant advantages over the conventional on-line directory systems, which lack the flexibility to permit the customer to tailor the directory listings to the needs of the customer.
Although not shown in the GUI screens of FIGS. 4-6, an invoice screen may be provided to permit the customer to retrieve billing data associated with usage of the directory services.
FIG. 9 shows a flow chart of a billing process associated with charging for directory services in the systems of FIGS. 1A and 1B. in accordance with an embodiment of the present invention. In step 901, the billing server 106 (FIG. 1A) tracks the number of successful listings for the customer; that is, only the listings that are accessed and viewed for each search are considered for billing purposes. The billing server 106, per step 903, then computes the invoice amount for the customer depending on the billing options, which include transactions based fee, per seat, flat rate fee, volume based fee, or any combination of these options. In step 905, the computed invoice amount is stored with other billing data (e.g., account information) in the billing server 106. Alternatively, the invoice amount may be computed by an external billing system (not shown) and downloaded onto the billing server 106 upon request of such information from the customer. After the invoice amount is available (i.e., computed), a user who is on-line via an access device may request to view the billing data from the billing server 106 (step 907). The access device then retrieves, as in step 909, the requested information from the billing server 106 using any delivery mechanism that the customer specifies (step 911). The delivery mechanisms include e-mail, fax, URL, pager, etc. and may be pre-defined. Additionally, the request may be pre-scheduled such that the customer is automatically sent the billing data with an explicit request. The above billing process may differ slightly depending on the billing arrangement.
FIG. 10 shows a flow chart of transaction-based billing process, in accordance with an embodiment of the present invention. As previously discussed, in the transaction based fee arrangement, the customer is charged a certain amount for each online directory assistance lookup that is successfully performed. It is noted that the service provider may elect to charge based on the total number of queries, irrespective of the number of successful listings; this is because each query consumes system resources of the WBDS 102, and if the customer continually utilizes these resources excessively then the service provider is given a recourse to recoup some costs. In step 1001, the user transmits a query to WBDS 102 via an access device for directory information. If the listing is successful (step 1003), then the listing is tracked and designated as chargeable (step 1005). Next, if there are further queries from the user (as determined in step 1007), steps 1001-1005 are repeated as appropriate. However, if no more queries are performed, then the WBDS 102 totals the queries for the billing period and checks whether the total queries exceed a pre-determined threshold (step 1009). Accordingly, an additional overage fee is applied against the customer's account, per step 1011, in the event that the number of queries exceeds the threshold, which may be negotiated in advance. If the number of queries does not exceed the threshold, then the invoice amount can be computed (per step 1013). After computation of the invoice amount, the invoice amount may be stored in the billing server 106; alternatively, this invoice amount may be stored in a separate database for later retrieval by the billing server 106. The above billing arrangement advantageously enables the service provider to supply a directory assistance service with an effective billing mechanism, thereby creating a lucrative revenue stream for the service provider while reducing the cost of directory services to the customers.
FIG. 11 illustrates a computer system upon which an embodiment according to the present invention may be implemented. Computer system 1101 includes a bus 1103 or other communication mechanism for communicating information, and a processor 1105 coupled with bus 1103 for processing the information. Computer system 1101 also includes a main memory 1107, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 1103 for storing information and instructions to be executed by processor 1105. In addition, main memory 1107 may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1105. Computer system 1101 further includes a read only memory (ROM) 1109 or other static storage device coupled to bus 1103 for storing static information and instructions for processor 1105. A storage device 1111, such as a magnetic disk or optical disk, is provided and coupled to bus 1103 for storing information and instructions.
Computer system 1101 may be coupled via bus 1103 to a display 1113, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 1115, including alphanumeric and other keys, is coupled to bus 1103 for communicating information and command selections to processor 1105. Another type of user input device is cursor control 1117, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 1105 and for controlling cursor movement on display 1113.
According to one embodiment, the information retrieval and billing processes are provided by computer system 1101 in response to processor 1105 executing one or more sequences of one or more instructions contained in main memory 1107. Such instructions may be read into main memory 1107 from another computer-readable medium, such as storage device 1111. Execution of the sequences of instructions contained in main memory 1107 causes processor 1105 to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the sequences of instructions contained in main memory 1107. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.
Further, the information retrieval and bill processing instructions of the communication system 100 may reside on a computer-readable medium. The term "computer-readable medium" as used herein refers to any medium that participates in providing instructions to processor 1105 for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 1111. Volatile media includes dynamic memory, such as main memory 1107. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 1103. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communication.
Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
Various forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to processor 1105 for execution. For example, the instructions may initially be carried on a magnetic disk of a remote computer. The remote computer can load the instructions relating to information retrieval and billing processes remotely into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 1101 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal. An infrared detector coupled to bus 1103 can receive the data carried in the infrared signal and place the data on bus 1103. Bus 1103 carries the data to main memory 1107, from which processor 1105 retrieves and executes the instructions. The instructions received by main memory 1107 may optionally being stored on storage device 1111 either before or after execution by processor 1105.
Computer system 1101 also includes a communication interface 1119 coupled to bus 1103. Communication interface 1119 provides a two-way data communication coupling to a network link 1121 that is connected to a local network 1123. For example, communication interface 1119 may be a network interface card to attach to any packet switched local area network (LAN). As another example, communication interface 1119 may be an asymmetrical digital subscriber line (ADSL) card, an integrated services digital network (ISDN) card or a modem to provide a data communication connection to a corresponding type of telephone line. Wireless links may also be implemented. In any such implementation, communication interface 1119 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 1121 typically provides data communication through one or more networks to other data devices. For example, network link 1121 may provide a connection through local network 1123 to a host computer 1125 or to data equipment operated by a service provider, which provides data communication services through a communication network 1127 (e.g., the Internet). LAN 1123 and network 1127 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 1121 and through communication interface 1119, which carry the digital data to and from computer system 1101, are exemplary forms of carrier waves transporting the information. Computer system 1101 can transmit notifications and receive data, including program code, through the network(s), network link 1121 and communication interface 1119.
The techniques described herein provide several advantages over prior approaches to providing on-line information retrieval. The present invention advantageously provides the capability to accurately compensate the data providers, resulting in cost savings for the service provider and ultimately the customer.
Obviously, numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.
Patent applications by Duraisamy Gunasekar, Cedar Rapids, IA US
Patent applications by Gregory Mumford, Marion, IA US
Patent applications by Jon Abel, Cedar Rapids, IA US
Patent applications by Kolin G. Hogue, Kalona, IA US
Patent applications by Lonnie S. Clabaugh, San Pedro, CA US
Patent applications by Richard G. Moore, Cedar Rapids, IA US
Patent applications by Shawn E. Wiederin, Cedar Rapids, IA US
Patent applications by Verizon Business Global LLC
Patent applications in class Bill preparation
Patent applications in all subclasses Bill preparation