WO2001052084A1

WO2001052084A1 - Method and system for optimizing access to a communications network

Info

Publication number: WO2001052084A1
Application number: PCT/US2001/000702
Authority: WO
Inventors: Tzvetan Drashansky; Ilya Levin; Vinod Marur; Balakrishnan Narendran; Matt Nguyen; Alexandru Radu; Peter Skopp
Original assignee: Juno Online Services, Inc.
Priority date: 2000-01-10
Filing date: 2001-01-10
Publication date: 2001-07-19
Also published as: AU2001234434A1

Abstract

A method is disclosed for optimizing client access to a communication network. At least one discloses embodiment of the method includes identifying (1010) a plurality of access points for a client to access a communication network from a specified location, and obtaining a plurality of metrics (1020), including a real-time performance metric, for each of the plurality of access points. The metrics can be evaluated (1030) by applying an evaluation agorithm and evaluation criteria to the metrics. At least one disclosed embodiment of the method also includes determining, using a processor, priority information (1040) for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points, and providing the priority information regarding the access points to the client (1050).

Description

Method and System for Optimizing Access to a Communications Network

Cross-Reference to Related Applications

This application claims priority to pending Provisional Application Serial No. 60/175,309 (Attorney Docket No. 10120-150), filed January 10, 2000.

Field of the Invention The present invention relates to the field of telecommunications, and, more particularly, to a method and system for optimizing access to a communications network.

Brief Description of the Drawings The invention will be more readily understood through the following detailed description, with reference to the accompanying drawings, in which:

FIG. 1 is a flowchart of an embodiment of a method 100 of the present invention;

FIG. 2 is a flowchart of an embodiment of a method 200 of the present invention;

FIG. 3 is a flowchart of an embodiment of a method 300 of the present invention;

FIG. 4 is a flowchart of an embodiment of a method 400 of the present invention; FIG. 5 is a flowchart of an embodiment of a method 500 of the present invention;

FIG. 6 is a flowchart of an embodiment of a method 600 of the present invention;

FIG. 7 is a block diagram of an embodiment of a system 700 of the present invention; and FIG. 8 is a block diagram of an embodiment of an information device 800 of the present invention.

Detailed Description

Overview

Embodiments of the invention can enable improved and/or optimized client software access to a communication network based on a plurality of variables, such that a selected communication interface to the network can provide: • The highest quality network access (for example, speed, expected longevity of connection, etc.)

• The lowest cost structure

• Some mix of quality and cost

• Increased virtual capacity

Embodiments of the invention can permit the achievement of independent goals for different sets of users. For example, in an embodiment of the present invention, the system can choose to try to optimize for the lowest cost connections for non-paying users, and/or optimize for the highest quality connections for paying users.

At least one disclosed embodiment provides an inventive method that advantageously includes identifying a plurality of access points for a client to access a communication network from a specified location, and obtaining a plurality of metrics, including a real-time performance metric, for each of the plurality of access points. At least one disclosed embodiment of the inventive method also advantageously includes determining, using a processor, priority information for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points, and providing the priority information regarding the access points to the client. Thus, certain embodiments of the present invention can be viewed as providing dynamically-adjusted priorities for improving and/or optimizing the selection of a communication network access provider from a set of such access providers.

Definitions

• POP (Point of Presence): a phone number (that can be provided by a network carrier) that client software can dial into to gain access to the server. Also known as an "access point" and/or an "access number".

• Dial Data Overlays (DDOs): specially encoded strings that can be sent from the server to the client software. These strings can include telephone numbers and parameters that the client software can: 1. display to the user during phone number selection; and/or

2. use to prioritize phone numbers before dialing a POP.

• Source Cluster: a collection of parts of source numbers representing local telephone exchanges that have the same list of POPs local to them.

• POP Cluster: a list of POPs local to a Source Cluster.

• Cluster List: a list of existing POP clusters.

• Pop Manager: software that can generate and/or update the DDOs. The updates can take place regularly, because the variables used in computing the DDOs (e.g., historical usage at a particular POP, current failure rates at a particular POP, the capacity at a particular POP, the rate structure at a particular carrier) can change at any time. • Dialdata File: a file containing dialing information (e.g., phone numbers, priorities) that can be used by the client software.

• Network String: a string generated by the client software that can indicate the access number on which communication with the server has been successfully established, as well as any other access numbers dialed during the same session on which a successful connection was not established.

• Metered Carrier: a network carrier that charges for each minute of service provided to its users.

• Per Port Carrier: a network carrier that charges a fixed cost per dialing port independent of actual usage. To the extent that there exists purchased port capacity at the carrier, users can use the carrier's ports without incurring additional costs.

History of the Invention

Known client software for facilitating access to a communications network has been designed to be "network independent". That client software is asked to dial into multiple access numbers by using a dialdata file that lists all the telephone numbers available for dial-in to the network, a description of the carriers on which they operate, and what is called a "fixed priority". Prior to the present invention, clients used this fixed priority to choose between the list of available numbers that the user selected. Under this known scheme, the client software looked up each number in the dialdata file, extracted its fixed priority value, and used that priority in order to build a priority queue from which to start dialing. Frequent updates of the dialdata file would not result in the effects claimed by the present invention, and in many cases would be prohibitively inefficient.

The inventors of the present invention have discovered that, if every user had the same dialdata file, then every user within the same region would have the same priority queue of access numbers to dial. Upon discovering this substantial problem, the inventors of the present invention sought an improved approach.

Embodiments of the present invention can improve and/or optimize the dialing process over the known "fixed priority" scheme in at least the following manners:

Optimizing POP Capacity:

Consider the simple case of two carriers with the same exact coverage and the same cost structure, but one that has 100 ports available for use, and one that has 50 available ports. Using the known "fixed priority" scheme, one of these carriers (presumably the one with 100 ports) would have a higher priority than the one with 50, and all users would first dial into the carrier with 100 ports and then fall back to the carrier with 50 ports if the carrier having 100 ports had all of those 100 ports filled. Embodiments of the present invention can improve the user experience by having the client compute a priority at the time of dialing based on some random element. For example, sixty-six percent of the time, the carrier with 100 ports could be prioritized ahead of the carrier with 50 ports. This could produce an aggregation of available capacity across both POPs. From the highest level it would appear that there are 150 available ports. Thus, this scheme can create the appearance of extra available capacity versus the fixed priority scheme.

Optimizing Off-Peak Usage: Different rate structures are typically available for different carriers.

For example, company X, which is primarily a business network provider, might define peak hours as Monday through Friday, 9am to 5pm. During those peak hours, Company X charges a higher per minute charge than during the off-peak hours. Another carrier, Y, however, might define peak hours as Monday through Friday, in the evening. Therefore, all other things being equal, and coverage being the same, it is more economical to use Company X on Monday through Friday in the evenings, and Company Y on Monday through Friday during the day, in order to maximize off-peak hour usage (as defined by each carrier) across each 24 hour period. This was not possible under the known "fixed priority" scheme, but it can be achieved with embodiments of the current invention.

Optimizing Per-Port Usage:

Consider the notion of trying to maximize the use of the "per port" carriers. These are the carriers whose ports are owned and can be utilized fully without incurring any additional charge above and beyond the sunk cost for acquiring those ports (effectively fixed assets). Embodiments of the present invention allow one to construct a system in which usage of fixed assets would approach 100% utilization, and spillover connections would be sent to other non-fixed assets.

Features and Advantages of Certain Exemplary Embodiments of the Invention

Client Use of DDOs

In certain exemplary embodiments, the client can use DDOs for at least two purposes:

1. To get POP locality information: In some embodiments of the present invention, the first time a user selects a "local" phone number into which that user would prefer to dial, that user can only choose from a list of numbers that fall within the user's area code. For example, a user who lives in the 212 area code in the United States might only be given the opportunity to choose from numbers that exist in the 212 area code. Following the first connection, however, the user's machine (the client) can receive a DDO string that lists additional "local" POP numbers that might fall outside the user's area code. In the case of New York city, this might include numbers from the 718 and other area codes. These choices can be made available because they might still constitute "local" calls for the user .

2. To dynamically prioritize POP number selection during dialing: In certain embodiments of the invention, the fixed priority codes found in the dialdata files can be augmented with functions that evaluate dynamic priorities using the DDO strings and other information available to the client at the time of the dialing (e.g., time of day, user service type). This is described in more detailed in the "Server to Client (The DDO String)" section, below.

Server System for Generating/Updating DDOs

PopManager - Database Interaction In certain exemplary embodiments, the server system can include a database management system in communication with the Pop Manager and with each of the Servers. The database management system can store various POP related information (e.g., phone number, network carrier, cost information, cluster information, historical failure rates, DDO strings). The database management system can include a high capacity relational database and a distributed system of files local to each of the servers. The local files can contain up-to-date copies of the DDO related tables found in the relational database.

In certain embodiments, immediately after it is started up, the POP Manager can begin obtaining various POP -related data for certain and/or all POPs from the database management system. This data can also be refreshed on demand at a later time. The following is a detailed description of some of the various data the POP manager can obtain:

1. General POP Information:

The general POP information can include:

• POP Area Code: the POP's area code (or country/city code outside North America).

• POP Number: the POP's phone number. • Carrier: the network carrier the POP belongs to (e.g., Sprint).

• Rate ID: the id of a database entry with the POP's cost rate.

• Gateway ID: the id of the gateway the POP belongs to. A Gateway is a collection of POPs that are billed together as a unit by a per-port carrier.

2. Gateway Information

The POP Manager can use the gateway information to compare the POPs that have metered rates with the POPs that have per port rates (the POPs belonging to a gateway). The gateway information can include: • Gateway ID: this can be a unique number identifying the gateway.

• Ports: the number of purchased ports (one more purchased port allows for one more concurrent connection).

3. POP Rate Information

The POP rate information can include:

• Rate ID: a unique number that can identify the rate.

• Rate Type: the rate type (e.g., metered or per port). • Protocol: a code that can indicate the connection and user type (since the cost rates can be different for different types of connections). For example, in a current embodiment of the present invention, it can be one of the following: free mail, mail, free web, web.

• Price: the actual POP price.

• Start Time: the starting time of the interval during which the price is valid.

• End Time: the end of the interval during which the price is valid. • Threshold: a threshold value at which the rate changes.

• Threshold Type: the type of threshold associated with the rate, such as:

• The point at which the price changes for all subsequent calls. For example: the system operator might pay $l/hour for the first 10,000 hours, and $0.50/hour after that.

• The point at which the entire usage rate changes to a lower rate. For example, the system operator might pay a rate of $l/hour (for all hours used) if it used less than 10,000 hours in a month, and a rate of $0.50/hour (for all hours used) if it used more than 10,000 hours in a month.

• Threshold Group: this can be utilized for usage purposes (for example, indicating which carriers count as one for billing purposes). For example, two merged carriers might issue a combined bill.

4. POP Failure History Information

The POP Manager can refresh this data at the end of each day because the POP's performance can change at any point. The failure history data can include: • Protocol: this field can identify the connection and user type for this performance information.

• Time: the date of this performance information.

• POP area code: the POP's area code. • POP number: the POP's phone number.

• Successes: the number of successful connections for the specified time.

• Failures: the number of failed connections for the specified time.

5. Pop Cluster List

The POP cluster list can include:

• Cluster ID: a unique number that can identify a particular cluster.

• Optimization Flag: this field can indicate whether the Pop Manager should attempt to generate DDOs for this particular cluster.

Pop Manager - Server(s) Data Exchange Format

The POP Manager can receive information about certain and/or every user connection from the servers in order to: • Calculate the real-time failure rate for certain and/or all the POPs that are being used, which can be used by the Pop Manager to determine the Interval Failure Rate (see Measurement Variables), which in turn can be used for POP ranking and DDO generation; and/or

• Calculate the utilization rate for certain and/or all of the gateways that are being used, which can be utilized by the Pop Manager to determine the Interval Cost Rate (see Measurement Variables) of a gateway POP, which in turn can be used for POP ranking and DDO generation. One possible protocol for the Pop Manager - Server Interaction is described below:

1. START Message (from Server to Pop Manager) : The POPJ PDATE START message can be sent to the POP

Manager at the beginning of a user's and/or client's connection. This message can contain information about the user's experience using one or more POPs. It can also include the list of the POPs to which the client has attempted to connect and whether the client succeeded in making a connection or not. The START message can have the following format:

POPUPDATE <txno> START <client> <id of the member's service type> <popl xodel :code2:...,pop2:codel :code2:...>,

where:

• <txno>: a unique string that can identify the user's connection; it can be used to match the message that indicates the end of the user connection.

• <client>: astring that can indicate the connection type. • <id of the member's service type>: a string that can indicate if the user is using the free or paying service.

• <popl xodel :code2:...,pop2:codel :code2:..>: a string that can provide information about the user's experience with the POPs into which the user has tried to dial; the codes can identify the different actions that occurred each time the user tried to connect (e.g., busy, timeout, no dial tone, success). The servers can receive this information from the clients via the Network String (see below).

2. SUCCESS / FAILURE Message (from PopManager to Server) The Pop Manager can reply with "Success" or "Failure" after it receives the START message. This message can have the following format:

FAILURE or

SUCCESS <txno> <pop state>

The FAILURE message can indicate that the START message could not be processed successfully. This might occur, for example, when the client is reporting an invalid POP.

The SUCCESS message can indicate that the START message proceeded successfully. It also can include information about the (failure) state of the POP to which the user and/or client connected.

3. END Message (from Server to Pop Manager)

The END message can be sent to the Pop Manager when the user and/or client connection ends. This message can allow the POP Manager to know the number of concurrent connections for a given POP (this information can be used to determine the Interval Cost Rate required by the DDO generation algorithm). The END message can have the following format:

POPUPDATE <txno> END

4. SUCCESS Message (from the POP Manager to Server)

This message can be the reply from POP Manager after receiving the END message. It can have the following format:

SUCCESS <txno> POP Ranking Procedure

The Pop Manager can rank (sort) certain and/or all POPs in certain and/or every cluster and can update their DDOs accordingly. The ranking procedure, which can take place on a regular and/or irregular basis, can include the following steps:

1. Get the next available Pop Cluster from the Pop Cluster List.

2. Get the list of all POPs - and their DDOs - that belong to the particular Pop Cluster from the database management system.

3. Rank the POPs by comparing each POP's performance for every protocol and for every time interval (see below "Measurement Variables" and "Comparison Techniques").

4. Update the variables that are used to generate the DDOs according to the new rankings.

5. Generate new DDOs and update the database management system.

6. Go to step 1.

Measurement Variables The POP Manager can use the following measurement variables ("metrics") to perform the comparison:

• Interval Failure Rate - the POP's failure rate during a particular time interval for a particular protocol (example: the failure rate for free web connections might be 20% between 14:00 and 14:30 and 30% between 14:30 and 15:00). This failure rate can be determined using the historical failure data, which can be obtained from the database management system, as well as the real time performance data, which can be collected from the servers (see "Pop Manager - Server Interaction"). Depending on how much importance is given to performance, the interval failure rate can be the highest, the lowest, or some other weighted combination of the historical and real-time failure rates.

• Interval Cost Rate - the POP's cost rate during a particular time interval for a particular protocol. The cost rates can be:

• Metered. The POP Manager can use the best rate for the particular interval (if there are thresholds - rate changes when usage goes over a certain limit - the POP Manager can assume the lowest rate).

• Per port. The POP Manager can use the best per port rate and can convert it to a metered rate by calculating the average interval usage for a specified time period, e.g., two weeks.

• Failure threshold - the failure threshold can be a fixed percentage configurable value that can define a limit that gives meaning to a POP's failure rate. A high threshold limit can emphasize the importance of cost. Such a high threshold limit might only be tolerable if the POP's cost was very low. Alternatively, a low threshold limit can emphasize the importance of performance.

Comparison Techniques

The Pop Manager can use the following evaluation rules when comparing two POPs: • If one of the interval failure rates is above the failure threshold, and the other one isn't, then the one that is below the limit can be prioritized higher.

• If both interval failure rates are above the failure threshold, the one with the lower failure rate can be prioritized higher.

• If both interval failure rates are below the failure threshold, the one that has the lower interval cost rate can be prioritized higher.

Client - Server Data Exchange Format

Client to Server

During each successful connection to the server system, the client system can upload the following information:

• The Network String.

• The Connection History Log File.

• Dialdata Information.

Network String

The network string can have the following format: <SRO{/POP NFO} |<Dialable Form> where:

• <SRC> is the source telephone number • <POP INFO> can be a string containing the following information:

1. the destination telephone number (POP)

2. the name of the carrier to which the POP belongs to

3. any errors during the dialing attempt (e.g., busy, timeout, no carrier) • <Dialable Form> = [J|W]<Encoded Dial String> J = can indicate the user has used the system to set dial preferences

W = can indicate the user has used Windows to set dial preferences

<Encoded Dial String> = is the dial string. The string can be preceded by 'T' or 'P' to indicate Tone or Pulse dialing followed by a series of digits and/or dialable characters (e.g., comma).

An exemplary network string can be:

<2125555555>/2125554545,ATT,NC,BU/2015555555,WCO M|W<Dial String>

This network string can indicate that the client called from 212-555- 5555; that the client attempted to call 212-555-4545, the ATT local POP, twice and got no carrier the first time and a busy the second time; then it got through on 201-555-5555, a WorldCom POP, on the first try. The user used Windows to set dial preferences.

The server can forward the network string to the Pop Manager. With enough users involved with the system, the Pop Manager can receive enough real-time data to get a statistically valid sample of which POPs are performing well, and which POPs are failing. This information can be used for POP ranking and, consequently, for DDO generation.

Connection History Log File

The connection history log file can contain more detailed information than the network string about certain and/or all of the connections (successful and unsuccessful) that the user and/or client has attempted since the last successful connection. This file can be processed by server software and the relevant information can be loaded into the database management system. This information also can be used by the Pop Manager to calculate historical failure rates for the POP network. Those rates can be used for POP ranking and, consequently, for DDO generation.

Dialdata Information

The dialdata information can have the following format:

<Client-dial-data-configuration> = <Last-time-number-selection>:<Phone- numbers>

where:

• <Last-time-number-selection> can be the time for the last time the current user has selected telephone numbers. The server can use this time to determine whether to force number selection or not (the idea is to prevent the user from making too many number (re)configurations).

• <Phone-numbers> can be a list of the locally selected phone numbers and the server supplied numbers (specified in the DDO), which can have the following format: (:<Selected-number>+ \ <ServerSentnumber>)

where:

• <Selected-number> can be the number that the user has selected for dialing.

• <ServerSent-number> can be the number sent down by the server as part of the DDO.

Server to Client (The DDO String) In response to the client information, the server can send the DDOs to the client. The format of the DDOs can be as follows:

where:

• <Special> can either be an empty set DDO, in which case the client will do nothing or a <Delete-DDO> ("0") in which case the client will delete the locally stored DDO.

For example:

<Empty> = " {} " | ""

<Delete-DDO> = "0"

• <Dial-record> = <Dial Data version>':'<Force-select-flag>':'<Server Signature>(':'<POP-record>)+

where:

• <Dial Data version> can specify a minimum Dial Data version number for which this DDO is supported. If, for example, "5.3" was specified in this field, the client would ignore processing of this DDO unless the local Dial Data version was 5.3 or greater.

• <Force-select-flag> = '0' I T. If set (1), the client can clear out the current user-selected number and can force the user to reselect local pops the next time the user attempts to dial. • <Server Signature> can be a string that the client will resubmit to the server.

• <POP-record> = <POP-number>('|'POP-param).

A <POP-record> can include a <POP-Number> followed by zero or more <POP-param> separated by a '|' character. A <POP-record> with no associated <POP-param> can indicate that the POP should be included in the display for number selection using the current locally stored <POP-param>.

• <POP-number> = 'XXX+XXX+XXXX' - where X = 0..9 or (for international numbers) '<City Code> <Rest of Number>'

• <POP-param> = <LN> | <POP-pair>

• <LN> = "Location" = <string>

• <POP-pair> = <Priority-pair> | <Time-period-pair> |

<Location-pair>

Priority-Pair

The <Priority-pair> can specify rules for setting the "High" and "Low" priorities for a particular protocol. When encountered, the client can randomize a number between the "High" and the "Low" values to use as the calculated priority before sorting the list of selected numbers before dialing. For example: POP A has a Priority Low = 35 and a Priority High = 50; POP B has a Priority Low = 25 and a Priority High = 60. When the client attempts to dial a number, it generates a random priority value for POP A which falls into the range of 35 and 50 and a random priority value for POP B that will fall into the range of 25 and 60. It will then sort these two numbers in ascending priority order and begin to dial based on this resulting sort. Thus,

1. The client generates a priority of 40 for POP A and a priority of 30 for POP B. Thus, POP B is dialed first.

2. The client generates a priority of 37 for POP A and a priority of 42 for POP B. Thus, POP A is dialed first.

3. The client generates a priority of 48 for POP A and a priority of 48 for POP B. Either POP may be dialed first.

The following definition is given for a Priority-Pair:

• <Priority-Pair> = <Protocol><Priority Type>'='<Priority Value>

where:

• <Priority Type> can be either 'H' or 'L' (high or low)

• <Priority Value> can be any integer between 0 an 99

Time-Period-Pair

A <time-period-pair> can define a data structure that encapsulates priority alterations based on specific time ranges: • <Time-period-pair> = <Header-letter><Index> '=' <Value>

where:

1. <Index> is the index of the time period.

where: 10 • <Protocol>: can indicate the type of user and the type of connection for which the adjustment should be applied.

• <Priority adjustments can indicate the change in priority for a given interval and/or protocol (it can be

15 applied to the Upper and/or the Lower priorities).

• <Start time>: can indicate the start of the time interval for which the priority adjustment should be applied.

• <Duration>: can indicate the length of the time interval for which the priority adjustment should be

20 applied.

• <Probability>: can indicate the probability of applying the priority adjustment.

• <Day of week>: can indicate the day of the week for which the priority adjustment should be applied.

25

During DDO processing, the client can check to make sure the current time falls into the coπect time restriction based on the "Time. Start" and "Time. Duration" specification. If the optional, "Time.Probability" field is present, the client

30 can generate a random number between 0-100 and will only invoke the priority adjustment if the random calculation is less than or equal to the "Time.Probability" field. Thus, for example, if the probability is 20, and the client randomly selects 30, the adjustment is not made. Likewise, for example, if the client had randomly selected 12, the adjustment would be applied. In this example, this can be viewed as similar to saying that the "Time. Adjustment" should be made only "Time.Probability" percentage of the time, thus if "Time. Adjustment" is -20 and "Time.Probability" is 30, it means that -2.0 is added to the fixed priorities only 30% of the time.

Location Pair

LN = <Any String>

DDO Example

Consider the components of the following DDO string:

5.17: l :*:718+123+4567|FL=50|FH=78:718+123+4588|LN=Houston,_TX|Pl=J |Yl=3B|Bl=8|Sl=c|Dl=o|Al=89|P2=JF|Y2=7|B2=61|S2=A|D2=R|A2=-68

• 5.17 - can indicate that the minimum supported dialdata file version is 5.17 (all clients with dialdata version 5.16 or lower will not apply this DDO). • 1 - can indicate that the client will force number selection the next time the user attempts to dial (either to get mail, connect to the web, etc.)

• * - can indicate that the client will send this string unaltered to the server each time a connection is made.

• 718+123+4567 - can indicate that the client expects the following parameters to refer to POP 718-123-4567: • FL=50 - can indicate that the free mail Priority Low = 50

• FH=78 - can indicate that the free mail Priority High = 78

• 718+123+4588 - can indicate that the client expects the following parameters to refer to POP 718-123-4588:

• LN=Houston, TX - can indicate that the POP location is Houston,

TX.

• P1=J - can indicate that the Timel connection type is paying web • Y1=3B - can indicate that the Timel days=59d=01 1 101 1 = Sun,

Mon, Wed, Thu, Fri.

• Bl=8 - can indicate that the Timel probability is 8, which can indicate that there is only an 8% probability that this time definition adjustment will be applied. • Sl=c - can indicate that the Timel start = 0230 (2:30am)

• Dl=o - can indicate that the Timel duration = 1530 (15 hrs, 30 min)

• Al=89 - can indicate that the Timel adjustment is 89

• P2=JF - can indicate that the Time2 connection type is paying web and email

• Y2=7 - can indicate that the Time2 days = 7d = 00001 11 = Sun, Mon, Tue

• B2=61 - can indicate that the Time2 probability = 61

• S2=A - can indicate that the Time2 start = 0000 (12:00 am) • D2=R - can indicate that the Time2 duration = 1800 (18 hours)

• A2=-68 - can indicate that the Time2 adjustment = 68 Thus, in this example, during the next phone number selection, only the numbers that were previously selected and 718-123-4567 and 718-123-4588 will be presented to the user in the "recommended" access numbers list.

Additional Description

With the above description in mind, various exemplary embodiments of the invention will be discussed, in particular, those corresponding to Figs. 1-8.

Method 100 Fig. 1 is a flowchart of an exemplary embodiment of a method 100 of the present invention. Method 100 can begin at activity 1010 by identifying access points for a client to access a communications network. The identified access points can be tailored for a specific client location.

At activity 1020, metrics can be obtained for the access points. At least one of the metrics can be a real-time performance metric. The metrics can also include cost, historical failure, time-based, protocol-based, and/or user-based metrics. Any of the metrics can be received, determined, calculated, and/or look-up. For example, a historical failure metric can be received from the client in the form of a connection history log file. At activity 1030, the metrics can be evaluated by applying an evaluation algorithm and evaluation criteria to the metrics. At activity 1040, the access points can be prioritized based on the results of the evaluation. At activity 1050, the prioritized access points can be provided to the client.

Method 200

Fig. 2 is a flow diagram of an exemplary embodiment of a method 200 of the present invention. Method 200 can begin at activity 2010 by a user attempting to log-on to a server. At activity 2020, the client software can make a determination regarding whether it is necessary to reselect the POPs. If not, the method can continues at activity 2040. If reselection of POPs is necessary, at activity 2030, the client can ask the user to select some POPs from a list of POPs. The list of POPs can be those received from the server during the previous session.

At activity 2040, the client can make a determination regarding whether a server is available. If not, at activity 2050, the client can make a determination whether to abort. If the decision is made not to abort, the method can continue at activity 2010. If the decision is made to abort, at activity 2060 the aborted network string can be saved to the logfile.

If a server is available, at activity 2070 the client can send the logon information to the server. At activity 2080, the server can receive the logon information. At activity 2090, the server can send some log-on information to the POP manager, and/or can send all log-on information to the database.

At activity 2100, the POP manager can send a reply to the server containing the current state of the user(s) POPs. At activity 2110, the server can compute and/or generate a DDO string. That DDO string can contain: 1. A flag indicating the necessity of reselection;

2. Priorities of POPs that were selected;

3. A list of non-selected POPs that are likely to be local to the user's current location.

At activity 2120, the server can send the new DDO string to the client. At activity 2130, the client can parse the DDO string and overlay the DDO string onto the dialdata file.

At activity 2140, the client can make a determination regarding whether the POP state is acceptable. If so, the user can be allowed access to the server. If not, at activity 2160, the client can terminate the current connection. Following termination, at activity 2170, the client can make a determination regarding whether to auto-reconnect. If not, method 200 can continue at activity 2010. Otherwise, at activity 2180, the client can determine a new access number having the highest priority, and attempt to connect via that access number. Then, method 200 can continue at activity 2040. Method 300

Fig. 3 is a flow chart of an exemplary embodiment of a method 300 of the present invention. At activity 3010, the user can provide a source number, indicating the telephone number from which the user is dialing. The user can provide the source number during account creation or following a change of the user's location. At activity 3020, the client software can dial into the server using a toll-free telephone number and provide the source number to the server. At activity 3030, the server can compute a list of local access numbers coπesponding to the source number, the local access numbers being a subset of access numbers in the dialdata file.

Method 400

Fig. 4 is a flow chart of an exemplary embodiment of a method 400 of the present invention. At activity 4010, a user can attempt to connect to the server. At activity 4020, the client can make a determination regarding whether reselection of the POPs is necessary. If a reselection of the POPs is necessary, at activity 4030 the client can ask the user to select some POPs. These POPs can be selected from a list of local access numbers that were sent from the server in the previous session. If the user is attempting to connect from a new location, the client can use the new location's area code to offer POPs associated with that area code.

If reselection of POPs is not necessary, at activity 4040, the client can iterate through the POP list and can compute priorities. If no DDO exists for a POP, the basic priorities from the dialdata file can be used. At activity 4050, the client software can place the access numbers in a priority queue. At activity 4060, the client can dial the access numbers in order of priority until there is successful connection or an abort. At activity 4070, the client can connect to the server. At activity 4080, the client can receive the most up-to-date DDO string. At activity 4090, the client can parse the DDO string and can overlay the dialdata with the DDO string. The DDO string can contain new priority information. Method 500

Fig. 5 is a flow chart of an exemplary embodiment of a method 500 of the present invention. At activity 5010, the client can write data to a log file. That data can build a log file that contains the entire connection history, including successful and unsuccessful connections. At activity 5020, the client can up-load the log file when the user is successfully connected to the server. At activity 5030, the server can load a comprehensive log file into the database. At activity 5040, the server can send real time connection data to the POP manager to be evaluated.

Method 600

Fig. 6 is a flow chart of an exemplary embodiment of a method 600 of the present invention describing a server system for computing DDO's. At activity 6010, the POP manager can obtain a list of all clusters from the database. At activity 6020, the POP manager can collect real time data about the state of the networks from the servers. At activity 6030, the POP manager can obtain the POP cost rate information from the database. At activity 6040, the POP manager can obtain historical failure rates for each POP from the data base. At activity 6050, the POP manager can request the list of POPs and their DDO's for the next cluster on the list from the database. At activity 6060, the POP manager can rank the POPs using cost information, historical information, and/or real time failure rate information, any of which can be available on a per interval and/or per protocol basis.

At activity 6070, the POP manager can modify the DDO's according to the new rankings. At activity 6080, the POP manager can update the database management system with any DDO's that have changed. At activity 6090, the POP manager can make a determination regarding whether the day is over. If the day is not over, method 600 can continue at activity 6050. If the day is over, method 600 can continue at activity 6040. System 700

Figure 7 is a block diagram of an exemplary embodiment of a system 700 of the present invention. As an initial matter, it suffices to say that, using the description of methods 100-600, one of ordinary skill in the art can implement the functionality of methods 100-600 via system 700 utilizing any of a wide variety of well-known architectures, hardware, protocols, and software. Thus, the following description of system 700 can be viewed as illustrative, and should not be construed to limit the implementation of any of methods 100-600.

One or more client information devices 7010 running the client software can be coupled to a network 7020. Also coupled to network 7020 can be one or more server information devices (servers) 7030. One or more POP manager information devices 7040 running the POP manager software 7045 can likewise be connected to network 7020, as can one or more database server information devices 7050, each serving one or more databases 7055. Any client 7010 can provide to any server 7030 a network string and/or a log file, and/or can receive from that server 7030 a DDO string. Any server 7030 can provide a network string to the POP manager software 7045 and/or can receive a POP state from POP manager 7045. Any server 7030 can provide a log file to database 7055 and/or can receive from database 7055 a DDO. Database 7055 can provide a POP list, failure information, cost information, and/or a cluster list to POP manager 7045, which can compute the DDO's. POP manager 7045 can provide to database 7055 those computed DDO's.

Although shown running on a dedicated POP manager information device 7040, POP manager 7045 can run as a process and/or daemon on any server 7030. Similarly, although shown being served by a dedicated database server 7050, database 7055 can be served by any server information device 7030 or by the POP manager information device 7040.

Network 7020 can have any architecture, including a direct connection, a local area network, a wide area network, a public switched telephone network, the Internet, an intranet, an extranet, a virtual private network, etc., and/or a combination thereof. Network 7020 can be a packet-switched, a circuit-switched, a connectionless, or connection-oriented network or interconnected networks, or any combination thereof. Moreover, a transmission media of network 7020 can take any form, including wireline, satellite, wireless, or any combination thereof. In certain embodiments, the transmission media of network 7020 can be limited to those that support the secure transmission of data.

From a hardware standpoint, any client information device 7010 can be, for example, a landline or wireless telephone, facsimile, personal computer, workstation, personal information manager, personal digital assistant, handheld computer, data terminal, or other similar device. Any information device 7030, 7040, and/or 7050 can be, for example, a personal computer, such as a desktop computer, laptop computer, handheld computer, or other similar device. Any information device 7030, 7040, and/or 7050 also can be a workstation, dedicated server, mini-computer, mainframe, or other similar device. Database 7055 and/or other databases of system 700, can have a flat file or a relational organization, and a centralized or distributed architecture. For instance, those of skill in the art can tailor products such as an SQL database to provide at least some of the functionality of methods 100-600 and system 700. One supplier of such database products is Oracle Corporation, of Redwood Shores, CA. In certain embodiments, software standards and protocols such as EDI, FTP,

HTTP, SGML, HTML, XML, cXML, XSL, SSL, WML, WAP and/or Bluetooth, etc., can be utilized for at least some communications within system 700. Additionally, system 700 can utilize platform-independent and/or network-centric software tools such as, for example, CGI, Java, and/or JavaScript, etc., as well as tools such as VisualBasic, C, C++, etc..

Device 800

Figure 8 is block diagram of a exemplary information device 800 of the present invention. Information device 800 can symbolize any information device 7010, 7030, 7040, and/or 7050. Information device 800 can include well-known components such as one or more network interfaces 8100, one or more processors 8200, one or more memories 8300 containing instructions 8400, and/or one or more input/output ("I/O") devices 8500.

In one embodiment, network interface 8100 can be a telephone, a traditional data modem, a fax modem, a cable modem, a digital subscriber line interface, a bridge, a hub, a router, or other similar devices.

In one embodiment, processor 8200 can be a general-purpose microprocessor, such the Pentium series microprocessor manufactured by the Intel Corporation of Santa Clara, California. In another embodiment, the processor can be an Application Specific Integrated Circuit (ASIC) that has been designed to implement in its hardware and/or firmware at least a part of a method in accordance with an embodiment of the present invention.

In one embodiment, memory 8300 can be coupled to a processor 8200 and can store instructions 8400 adapted to be executed by processor 8200 according to one or more actions of any of methods 100-600. Memory 8300 can be any device capable of storing analog or digital information, such as a hard disk, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, a compact disk, a magnetic tape, a floppy disk, etc., and any combination thereof.

In one embodiment, instructions 8400 can be embodied in software that can take any of numerous forms that are well known in the art. In one embodiment, I/O device 8500 can be an audio and/or visual device, including, for example, a monitor, display, keyboard, keypad, touch-pad, pointing device, microphone, speaker, video camera, camera, scanner, and/or printer, etc., and can include a port to which an I/O device can be attached, connected, and/or coupled. The present invention provides devices, systems, and methods for improving and/or optimizing client access to a communication network. Although the present invention has been described with respect to several exemplary embodiments, there are many other variations of the above-described embodiments that will be apparent to those skilled in the art, even where elements have not explicitly been designated as exemplary. It is understood that these modifications are within the teaching of the present invention, which is to be limited only by the claims appended hereto.

Claims

What Is Claimed Is:

1. A method for optimizing client access to a communication network, comprising the activities of: identifying a plurality of access points for a client to access a communication network from a specified location; obtaining a plurality of metrics, including a real-time performance metric, for each of the plurality of access points; determining, using a processor, priority information for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points; providing the priority information regarding the access points to the client.

2. The method of claim 1, further comprising receiving logon information from the client.

3. The method of claim 1, further comprising receiving connection history information from the client.

4. The method of claim 1, further comprising providing initial priority information regarding the access points to the client.

5. The method of claim 1, further comprising receiving at least one of the plurality of metrics.

6. The method of claim 1, further comprising receiving at least one of the plurality of metrics from the client.

7. The method of claim 1, further comprising determining at least one of the plurality of metrics.

8. The method of claim 1, further comprising looking-up at least one of the plurality of metrics.

9. The method of claim 1, further comprising calculating at least one of the plurality of metrics.

10. The method of claim 1, further comprising evaluating the plurality of access points based on the plurality of metrics for each access point from the plurality of access points.

11. The method of claim 1, further comprising obtaining an evaluation algorithm to apply to the plurality of metrics for each access point from the plurality of access points.

12. The method of claim 1, further comprising obtaining evaluation criteria to apply to the plurality of metrics for each access point from the plurality of access points.

13. The method of claim 1, further comprising assigning a priority to each of the plurality of access points based on an evaluation of the plurality of metrics for each access point.

14. The method of claim 1, further comprising sorting the plurality of access points according to at least one of the plurality of metrics.

15. The method of claim 1, further comprising ranking the plurality of access points according to the priority information.

16. The method of claim 1, further comprising assigning a priority to each of the plurality of access points according to a ranking of the plurality of access points.

17. The method of claim 1, wherein the plurality of metrics includes a cost metric.

18. The method of claim 1, wherein the plurality of metrics includes a historical failure metric.

19. The method of claim 1, wherein the plurality of metrics includes a time-based metric.

20. The method of claim 1 , wherein the plurality of metrics includes a time interval- based metric.

21. The method of claim 1, wherein the plurality of metrics includes a protocol- based metric.

22. The method of claim 1, wherein the plurality of metrics includes a user-based metric.

23. The method of claim 1, wherein the plurality of access points are evaluated based at least in part on a cost metric for each of the plurality of access points.

24. The method of claim 1, wherein the plurality of access points are evaluated based at least in part on a historical failure metric for each of the plurality of access points.

25. The method of claim 1, wherein the plurality of access points are evaluated based at least in part on the real-time performance metric for each of the plurality of access points.

26. The method of claim 1, wherein the prioritized list is based upon the evaluation of the plurality of metrics for each access point from the plurality of access points.

27. The method of claim 1, wherein the real-time performance metric is based upon a real-time failure rate.

28. The method of claim 1, wherein the real-time performance metric is based upon an interval failure rate.

29. The method of claim 1, wherein at least one of the plurality of metrics is obtained from a connection history log.

30. A machine-readable medium storing instructions for activities comprising: identifying a plurality of access points for a client to access a communication network from a specified location; obtaining a plurality of metrics, including a real-time performance metric, for each of the plurality of access points; determining priority information for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points; providing the priority information regarding the access points to the client.

31. An apparatus for optimizing client access to a communications network, comprising: means for identifying a plurality of access points for a client to access a communication network from a specified location; means for obtaining a plurality of metrics, including a real-time performance metric, for each of the plurality of access points; means for determining priority information for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points; means for providing the priority information regarding the access points to the client.

32. A computer-implemented system for optimizing client access to a communications network, comprising: an access point management routine adapted to obtaining a plurality of metrics, including a real-time performance metric, for each of a plurality of identified communication network access points; an evaluation routine adapted to determine priority information for each of the plurality of access points based on the plurality of metrics for each of the plurality of access points; a communication routine adapted to provide the priority information regarding the access points to the client.

33. A method for obtaining optimized access to a communication network, comprising the activities of: connecting to the communication network via one of a plurality of access points; providing connection history information to the communication network; receiving a prioritized list of access points for future connections.

34. The method of claim 33, further comprising selecting at least one access point from the plurality of access points.

35. The method of claim 33, further comprising selecting a subset of access points from the plurality of access points.

36. The method of claim 33, further comprising attempting to connect to the communication network via one of the plurality of access points.

37. The method of claim 33, further comprising attempting to connect to the communication network via a selected one of the plurality of access points.

38. The method of claim 33, further comprising attempting to connect to the communication network via a highest priority access point from the prioritized list of access points.

39. The method of claim 33, further comprising attempting to connect to the communication network via a highest priority access point from a selected subset of access points from the prioritized list of access points.

40. The method of claim 33, further comprising providing logon information to the communication network.

41. The method of claim 33, further comprising replacing a pre-existing list of access points with the received prioritized list of access points.

42. The method of claim 33, wherein the access points on the prioritized list are ranked based on a plurality of metrics for each of the plurality of access points.

43. A machine-readable medium storing instructions for activities comprising: connecting to the communication network via one of a plurality of access points; providing connection history information to the communication network; receiving a prioritized list of access points for future connections.

44. An apparatus for obtaining optimized access to a communication network comprising: means for connecting to the communication network via one of a plurality of access points; means for providing connection history information to the communication network; means for receiving a prioritized list of access points for future connections.

45. A machine-readable data structure, stored on a machine-readable medium, for optimizing client access to a communication network, the structure comprising at least one access point identifier having at least one priority adjustment value.