Load balancing
Claim Score by NHIP
Abstract
This invention discloses a method for managing a computer network connected to the Internet through a network connection, such as different Internet Service Providers, including the steps of: sending polling requests through a plurality of routes tom a computer network to a remote server computer, receiving replies from the remote server computer corresponding to the polling requests, and measuring proximities of the remote server computer to the computer network based on the received replies. A network management system for managing a computer network connected to the Internet through a plurality of routes is also disclosed.
Term
Term ended
Projected expiry passed 8 May 2026, 0.4 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
122 claims: 13 independent, 109 dependent
- 1A method for managing a computer network connected to the Internet through a plurality of routes, comprising the steps of;sending polling requests through a plurality of routes from a computer network to a remote server computer;receiving replies from the remote server computer corresponding to the polling requests and measuring proximities of the remote server computer to the computer network based on the received replies.
- 15A method for managing a computer network connected to the Internet through a plurality of routes, comprising the steps of:receiving a request from a client within a computer network directed to a remote server computer, looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of routes;and selecting one of the plurality of routes through which to route the client request, based on the ratings within the table entry looked up in the proximity table.
- 23A network management system for managing a computer network connected to the Internet through a plurality of routes, comprising:a network controller sending polling requests through a plurality of routes from a computer network to a remote server computer, and receiving replies from the remote server computer corresponding to the polling requests;and a proximity analyzer measuring proximities of the remote server computer to the computer network based on the replies.
- 37A network management system for managing a computer network connected to the Internet through a plurality of routes, comprising:a network controller receiving a client request from within a computer network directed to a remote server computer, and select one of a plurality of routes through which to route the client request;and a data manager looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of routes, and wherein said network controller selects one of the plurality of routes based on the ratings within the table entry looked up in the proximity table.
- 45A method for managing a computer network connected to the Internet through a plurality of routes, comprising the steps of:receiving a DNS resolution query from a remote computer for a domain name within a computer network, sending poling requests through a plurality of routes from the computer network to the remote computer;receiving replies from the remote computer corresponding to the polling requests;and measuring proximities of the remote computer to the computer network based on the replies.
- 55A method for managing a computer network connected to the Internet through a plurality of routes, comprising the steps of:receiving a DNS resolution query from a remote computer for a domain name within a computer network;looking up a table entry within a proximity table indexed by an address related to the remote computer, the tables entries of the proximity table containing ratings for a plurality of routes;selecting one of the plurality of routes, based on the ratings within the table entry looked up in the proximity table;and responding to the DNS resolution query with an IP address associated with the selected one of the plurality of routes.
- 64A network management system for managing a computer network connected to the Internet through a plurality of routes, comprising:a network controller receiving a DNS resolution query from a remote computer for a domain name within a computer network, sending polling requests through a plurality of routes from the computer network to the remote computer, and receiving replies from the remote computer corresponding to the polling requests;and a proximity analyzer measuring proximities of the remote computer to the computer network via the plurality of routes, based on the replies.
- 74A network management system for managing a computer network connected to the Internet through a plurality of routes, comprising:a network controller receiving a DNS resolution query from a remote computer for a domain name within a computer network, selecting one of a plurality of routes, and responding to the DNS resolution query with an IP address associated with the selected route;and a data manager looking up a table entry within a proximity table indexed by an address related to the remote computer, the tables entries of the proximity table containing ratings for the plurality of routes, and said network controller selects an route based on ratings within the table entry looked up in the proximity table.
- 83A routing system for routing data via a network from a first node to a second node;said network having a plurality of available routes from said first node to said second node;wherein said system comprises a route selector operable to select one of said routes for sending data between said first node and second node on the combined basis of content information of said data, an obtained quality level of the routes and proximity information.
- 84A routing system for routing data via a network from a first node to a second node;said network having a plurality of available routes from said first node to said second node;wherein said system comprises a route selector operable to select one of said routes or sending data between said first node and second node on the basis of costing information of said routes.
- 104A method for routing data by a content routing system from a first node to a second node via a network and comprising the steps of;providing a plurality of available routes from said first node to said second node;and method of selecting one of said routes for sending data between said first node and second node on the basis of content information of said data
- 105A method for routing data by a content rout system from a first node to a second node via a network and comprising the steps of;providing a plurality of available routes from said first node to said second node;and a route selector selecting one of said routes for sending data between said first node and second node on the basis of costing information of said routes.
- 117Broadest claimClaim Score 91, very broad(NHIP)A method for calculating a path quality parameter for a network path between a first node and a second node, comprising the step of checking the availability of the path, the cost of the path connection, and the data packet loss rate of the path.
Independent claims13
161 paragraphs in 6 sections, as filed
REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of assignee's pending application U.S. Ser. No. 09/115,643, filed on Jul. 15, 1998, and entitled “Load Balancing.”
FIELD OF THE INVENTION
[0002] The present invention relates to computer networks in general, and in particular to load balancing client requests among redundant network servers in different geographical locations.
BACKGROUND OF THE INVENTION
[0003] In computer networks, such as the Internet, preventing a server from becoming overloaded with requests from clients may be accomplished by providing several servers having redundant capabilities and managing the distribution of client requests among the servers through a process known as “load balancing.”
[0004] In one early implementation of load balancing, a Domain Naming System (DNS) server connected to the Internet is configured to maintain several IP addresses for a single domain name, with each address corresponding to one of several servers having redundant capabilities. The DNS server receives a request for address translation and responds by returning the list of server addresses from which the client chooses one address at random to connect to. Alternatively, the DNS server returns a single address chosen either at random or in a round-robin fashion, or actively monitors each of the servers and returns a single address based on server load and availability.
[0005] More recently, a device known as a “load balancer,” such as the Web Server Director, commercially available from the Applicant/assignee, has been used to balance server loads as follows. The load balancer is provided as a gateway to several redundant servers typically situated in a single geographical location and referred to as a “server farm” or “server cluster.” DNS servers store the IP address of the load balancer rather than the addresses of the servers to which the load balancer is connected. The load balancer's address is referred to as a “virtual IP address” in that it masks the addresses of the servers to which it is connected. Client requests are addressed to the virtual IP address of the load balancer which then sends the request to a server based on server load and availability or using other known techniques.
[0006] Just as redundant servers in combination with a load balancer may be used to prevent server overload, redundant server farms may be used to reroute client requests received at a first load balancer/server farm to a second load balancer/server farm where none of the servers in the first server farm are available to tend to the request. One rerouting method currently being used involves sending an HTTP redirect message from the first load balancer/server farm to the client instructing the client to reroute the request to the second load balancer/server farm indicated in the redirect message. This method of load balancing is disadvantageous in that it can only be employed in response to HTTP requests, and not for other types of requests such as FTP requests. Another rerouting method involves configuring the first load balancer to act as a DNS server. Upon receiving a DNS request, the first load balancer simply returns the virtual IP address of the second load balancer. This method of load balancing is disadvantageous in that it can only be employed in response to DNS requests where there is no guarantee that the request will come to the first load balancer since the request does not come directly from the client, and where subsequent requests to intermediate DNS servers may result in a previously cached response being returned with a virtual IP address of a load balancer that is no longer available.
[0007] Where redundant server farms are situated in more than one geographical location, the geographical location of a client may be considered when determining the load balancer to which the client's requests should be routed, in addition to employing conventional load balancing techniques. However, routing client requests to the geographically nearest server, load balancer, or server farm might not necessarily provide the client with the best service if, for example, routing the request to a geographically more distant location would otherwise result in reduced latency, fewer hops, or provide more processing capacity at the server.
SUMMARY OF THE INVENTION
[0008] The present invention seeks to provide novel apparatus and methods for load balancing client requests among redundant network servers and server farms in different geographical locations which overcome the known disadvantages of the prior art as discussed above.
[0009] There is thus provided in accordance with a preferred embodiment of the present invention a method for load balancing requests on a network, the method including receiving a request from a requestor having a requestor network address at a first load balancer having a first load balancer network address, the request having a source address indicating the requestor network address and a destination address indicating the fist load balancer network address, forwarding the request from the first load balancer to a second load balancer at a triangulation network address, the request source address indicating the requestor network address and the destination address indicating the triangulation network address, the triangulation network address being associated with the first load balancer network address, and sending a response from the second load balancer to the requestor at the requestor network address, the response having a source address indicating the first load balancer network address associated with the triangulation network address and a destination address indicating the first requestor network address.
[0010] Further in accordance with a preferred embodiment of the present invention the method includes maintaining the association between the triangulation network address and the first load balancer network address at either of the load balancers.
[0011] Still further in accordance with a preferred embodiment of the present invention the method includes maintaining the association between the triangulation network address and the first load balancer network address at the second load balancer, and communicating the association to the first load balancer.
[0012] Additionally in accordance with a preferred embodiment of the present invention the method includes directing the request from the second load balancer to a server in communication with the second load balancer, composing the response at the server, and providing the response to the second load balancer,
[0013] There is also provided in accordance with a preferred embodiment of the present invention a method for load balancing requests on a network, the method including determining the network proximity of a requestor with respect to each of at least two load balancers, designating a closest one of the load balancers by ranking the load balancers by network proximity, and directing requests from the requestor to the closest load balancer.
[0014] Further in accordance with a preferred embodiment of the present invention the method includes directing requests from any source having a subnet that is the same as the subnet of the requestor to the closest load balancer.
[0015] Still further in accordance with a preferred embodiment of the present invention the method includes monitoring the current load of each of the load balancers, and performing the directing step the current load of the closest load balancer is less than the current load of every other of the load balancers.
[0016] Additionally in accordance with a preferred embodiment of the present invention the determining step includes periodically determining.
[0017] Moreover in accordance with a preferred embodiment of the present invention the determining step includes determining at at least one fixed time.
[0018] Further in accordance with a preferred embodiment of the present invention the determining step includes polling the requestor to yield at least two attributes selected from the group consisting of: latency, relative TTL, and amber of hops to requestor.
[0019] Still further in accordance with a preferred embodiment of the present invention the determining step includes polling the requestor using at least two polling methods selected from the group consisting of: pinging sending a TCP ACK message to the requestor's source address and port, sending a TCP ACK message to the requestor's source address and port <b>80</b>, and sending a UDP request to a sufficiently high port number as to elicit an “ICMP port unreachable” reply.
[0020] Additionally in accordance with a preferred embodiment of the present invention the designating step includes designating a closest one of the load balancers by ranking the load balancers by network proximity and either of current load and available capacity.
[0021] There is also provided in accordance with a preferred embodiment of the present invention a method for determining network proximity, the method including sending from each of at least two servers a UDP request having a starting TTL value to a client at a sufficiently high port number as to elicit an “ICMP port unreachable” reply message to at least one determining one of the servers indicating the UDP request's TTL value on arrival at the client, determining a number of hops from each of the servers to the client by subtracting the starting TTL value from the TTL value on arrival for each of the servers, and determining which of the servers has fewer hops of the client, and designating the server having fewer hops as being closer to the client than the other of the servers.
[0022] There is additionally provided in accordance with a preferred embodiment of the present invention a network load balancing system including a network, a first load balancer connected to the network and having a first load balancer network address, a second load balancer connected to the network and having a triangulation network address, the triangulation network address being associated with the first load balancer network address, and a requestor connected to the network and having a requestor network address, where the requestor is operative to send a request via the network to the first load balancer, the request having a source address indicating the requestor network address and a destination address indicating the first load balancer network address, the first load balancer is operative to forward the request to the second load balancer at the triangulation network address, the request source address indicating the requestor network address and the destination address indicating the triangulation network address, and the second load balancer is operative to send a response to the requestor at the requester network address, the response having a source address indicating the first load balancer network address associated with the triangulation network address and a destination address indicating the first requestor network address.
[0023] Further in accordance with a preferred embodiment of the present invention either of the load balancers is operative to maintain a table of the association between the triangulation network address and the first load balancer network address.
[0024] Still further in accordance with a preferred embodiment of the present invention the second load balancer is operative to maintain a table of the association between the triangulation network address and the first load balancer network address and communicate the association to the first load balancer.
[0025] Additionally in accordance with a preferred embodiment of the present invention the system further includes a server in communication with the second load balancer, where the second load balancer is operative to direct the request from the second load balancer to the server, and the server is operative to compose the response and provide the response to the second load balancer.
[0026] There is also provided in accordance with a preferred embodiment of the present invention a network load balancing system including a network, at least two load balancers connected to the network, and a requestor connected to the network, where each of the at least two load balancers is operative to determine the network proximity of the requestor, and at least one of the load balancers is operative to designate a closest one of the load balancers by ranking the load balancers by network proximity and direct requests from either of the requestor and a subnet of the requester to the closest load balancer.
[0027] Further in accordance with a preferred embodiment of the present invention the load balancers are operative to poll the requestor to yield at least two attributes selected from the group consisting of: latency, relative TTL, and number of hops to requestor.
[0028] Still further in accordance with a preferred embodiment of the present invention the load balancers are operative to poll the requestor using at least two polling methods selected from the group consisting of: pinging, sending a TCP ACK message to the requestor's source address and port, sending a TCP ACK message to the requestor's source address and port <b>80</b>, and sending a UDP request to a sufficiently high port number as to elicit an “ICMP port unreachable” reply.
[0029] Additionally in accordance with a preferred embodiment of the present invention at least one of the load balancers is operative to designate the closest one of the load balancers by ranking the load balancers by network proximity and either of current load and available capacity.
[0030] It is noted that throughout the specification and claims the term “network proximity” refers to the quality of the relationship between a client and a first server or server farm as compared with the relationship between the client and a second server or server farm when collectively considering multiple measurable factors such as latency, hops, and server processing capacity.
[0031] There is further provided in accordance with a preferred -embodiment of the present invention a method for managing a computer network connected to the Internet through a plurality of routes or Internet Service Providers, includes the steps of: sending polling requests through a plurality of ISPs from a computer network to a remote server computer, receiving replies from the remote server computer corresponding to the polling requests, and measuring proximities of the remote server computer to the computer network based on the received replies.
[0032] Further in accordance with a preferred embodiment of the present invention the plurality of ISPs assign respective IP addresses to the computer network, and the sending step designates a source IP address for each polling request corresponding to the ISP through which the polling request is sent.
[0033] Still further in accordance with a preferred embodiment of the present invention the polling requests may be TCP/IP requests, UDP requests, or ping requests.
[0034] Additionally in accordance with a preferred embodiment of the present invention, the measuring step measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network. Preferably the measuring step measures proximities based on the latency, relative TTL and number of hops of the received replies in travelling from the remote server to the computer network.
[0035] Additionally or alternatively the measuring step may measure proximities based on the number of hops undergone by the received replies in travelling a round trip from the computer network to the remote server and back to the computer network, based on the TTL of the received replies in traveling a round trip from the computer network to the remote server and back from the remote server to the computer network, based on the latency of the received replies in travelling from the remote server to the computer network or based on the latency of the received replies in traveling a round trip from the computer network to the remote server and back from the remote server to the computer network.
[0036] Further in accordance with a preferred embodiment of the present invention the method for managing a computer network connected to the Internet through a plurality of network connection, such as different Iternet Service Providers, may also include the steps of rating the plurality of ISPs based on the measured proximities, and entering the ratings in a proximity table within a table entry indexed by an address related to the remote server computer.
[0037] Preferably the rating step also determines the best three choices for ISPs based on the measured proximities.
[0038] Additionally or alternatively the address related to the remote server computer is a subnet IP address of the remote server computer.
[0039] There is also provided in accordance with yet another preferred embodiment of the present a method for managing a computer network connected to the Internet through a plurality of ISPs, includes the steps of: receiving a request from a client within a computer network directed to a remote server computer, looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of ISPs, and selecting one of the plurality of ISPs through which to route the client request, based on the ratings within the table entry looked up in the proximity table.
[0040] Further in accordance with a preferred embodiment of the present invention, the related to the remote server is a subnet IP address of the remote server.
[0041] Still further in accordance with a preferred embodiment of the present invention, the table entries contain the best three choices for ISPs through which to route the client request, and wherein the selecting step selects the best ISP, from among the best three choices for ISPs, that is available and not overloaded.
[0042] Additionally in accordance with a preferred embodiment of the present invention, the selecting step determines whether or not an ISP is overloaded based upon a user-configurable load threshold. Furthermore, the selecting step may also select an ISP based on current load, in the event that all three of the best three choices for ISP are unavailable or overloaded.
[0043] Further in accordance with a preferred embodiment of the present invention, the plurality of ISPs assign respective IP addresses to the computer network, and wherein the method further comprises the step of setting the source IP address of the client request corresponding to the selected ISP.
[0044] Moreover in accordance with a preferred embodiment of the present invention the method also includes the step of routing the client request through the selected ISP. Preferably the plurality of ISPs assign respective IP addresses to the computer network, and the routing step designates a source IP address for the client request corresponding to the selected ISP.
[0045] The computer network may further be a private network, visible externally through a network address translation. Preferably the method may also include the steps of receiving a response from the remote server directed to the source IP address designated for the client request, and translating the source IP address designated for the client address to the IP address for the client within the private network.
[0046] There is further provided in accordance with yet another preferred embodiment of the present invention a network management system for managing a computer network connected to the Internet through a plurality of ISPs, including a network controller sending polling requests trough a plurality of ISPs from a computer network to a remote server computer, and receiving replies from the remote server computer corresponding to the poling requests, and a proximity analyzer measuring proximities of the remote server computer to the computer network based on the replies.
[0047] Further in accordance with a preferred embodiment of the present invention the plurality of ISPs assign respective IP addresses to the computer network, and the network controller designates a source IP address for each polling request corresponding to the ISP through which the polling request is sent.
[0048] Furthermore the polling requests may be TCP/IP requests, UDP requests, or ping requests.
[0049] Additionally in accordance with a preferred embodiment of the present invention the proximity analyzer measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network. The proximity analyzer may measure proximities based on the latency, relative TTL, and number of hops of the received replies in travelling from the remote server to the computer network.
[0050] Moreover in accordance with a preferred embodiment of the present invention the proximity analyzer rates the plurality of ISPs based on the measured proximities. The system may further include a data manager entering the ratings in a proximity table within a table entry indexed by an address related to the remote server computer. Preferably the proximity analyzer determines the best three choices for ISPs based on the measured proximities.
[0051] Additionally in accordance with a preferred embodiment of the present invention, the address related to the remote server computer is a subnet IP address of the remote server computer.
[0052] There is also provided in accordance with another preferred embodiment of the present invention, a network management system for managing a computer network connected to the Internet through a plurality of ISPs, including a network controller receiving a client request from within a computer network directed to a remote server computer, and selecting one of a plurality of ISPs through which to route the client request, and a data manager looking up a table entry within a proximity table indexed by an address related to the remote server computer, the tables entries of the proximity table containing ratings for a plurality of ISPs. The network controller may also select one of the plurality of ISP based on the ratings within the table entry looked up in the proximity table.
[0053] Further in accordance with a preferred embodiment of the present invention the address related to the remote server is a subnet IP address of the remote server.
[0054] Still further in accordance with a preferred embodiment of the present invention, the table entries contain the best three choices for ISPs through which to route the client request, and the network controller selects the best ISP, from among the best three choices for ISPs, that is available and not overloaded. Preferably the network controller also determines whether or not an ISP is overloaded based upon a user-configurable load threshold.
[0055] Additionally in accordance with a preferred embodiment of the present invention, the network controller selects an ISP based on current load, in the event that all three of the best three choices for ISP are unavailable or overloaded. The plurality of ISPs may assign respective IP addresses to the computer network, the network controller designates a source IP address for the client request corresponding to the selected ISP.
[0056] Moreover in accordance with a preferred embodiment of the present invention, the network controller routes the client request through the selected ISP. Preferably the computer network is a private network, visible externally through a network address translation, and the network controller receives a response from the remote server directed to the source IP address designated for the client request, the system further comprising a network address translator translating the source IP address designated for the client address to the IP address for the client within the private network
[0057] There is also provided in accordance with yet another preferred embodiment of the present invention a method for managing a computer network connected to the Internet through a plurality of ISPs, including the steps of receiving a DNS resolution query from a remote computer for a domain name within a computer network, sending polling requests through a plurality of ISPs from the computer network to the remote computer, receiving replies from the remote computer corresponding to the polling requests, and measuring proximities of the remote computer to the computer network based on the replies.
[0058] Further in accordance with a preferred embodiment of the present invention the plurality of ISPs assign respective IP addresses to the computer network, and the sending step designates a source IP address for each polling request corresponding to the ISP through which the polling request is sent.
[0059] Still further in accordance with a preferred embodiment of the present invention the polling requests may be TCP/IP requests, UDP requests, or ping requests.
[0060] Additionally in accordance with a preferred embodiment of the present invention, the measuring step measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network.
[0061] Further in accordance with a preferred embodiment of the present invention the proximity analyzer measures proximities based on the number of hops undergone by the received replies in travelling a round trip from the computer network to the remote server and back to the computer network.
[0062] Alternatively the proximity analyzer measures proximities based on the TTL of the received replies in travelling a round trip from the computer network to the remote server and back to the computer network, on the latency of the received replies in travelling from the remote server to the computer network, or on the latency of the received replies in travelling a round trip from the computer network to the remote server and back to the computer network.
[0063] Moreover in accordance with a preferred embodiment of the present invention, the measuring step may also measure proximities based on the latency, relative TTL, and number of hops of the received replies in traveling from the remote server to the computer network.
[0064] The method may further include the steps of: rating the plurality of ISPs based on the measured proximities, and entering the ratings in a proximity table within a table entry indexed by an address related to the remote server computer. Preferably the rating step determines the best three choices for ISPs based on the measured proximities.
[0065] Additionally or alternatively the address related to the remote server computer is a subnet IP address of the remote server computer.
[0066] There is further provided in accordance with yet another preferred embodiment of the present invention a method for managing a computer network connected to the Internet through a plurality of ISPs, which includes the steps of: receiving a DNS resolution query from a remote computer for a domain name within a computer network, looking up a table entry within a proximity table indexed by an address related to the remote computer, the tables entries of the proximity table containing ratings for a plurality of ISPs, selecting one of the plurality of ISPs, based on the ratings within the table entry looked up in the proximity table, and responding to the DNS resolution query with an IP address associated with the selected one of the plurality of ISPs.
[0067] Further in accordance with a preferred embodiment of the present invention the address related to the remote computer is a subnet IP address of the remote computer.
[0068] Still further in accordance with a preferred embodiment of the present invention the table entries contain the best three choices for ISPs trough which to connect to the remote computer from within the computer network, and the selecting step selects the best ISP, from among the best three choices for ISPs, that is available and not overloaded. Preferably the selecting step determines whether or not an ISP is overloaded based upon a user configurable load threshold.
[0069] Additionally in accordance with a preferred embodiment of the present invention, the selecting step selects an ISP based on current load, in the event that all three of the best three choices for ISP are unavailable or overloaded.
[0070] Further in accordance with a preferred embodiment of the present invention the plurality of ISPs assign respective IP addresses to the computer network and wherein said network controller sets the source IP address of the client request corresponding to the selected ISP.
[0071] Moreover in accordance with a preferred embodiment of the present invention, the plurality of ISPs assign respective IP addresses to the computer network, and the responding step designates an IP address corresponding to the selected ISP. Preferably the computer network is a private network, visible externally through a network address translation.
[0072] Still further in accordance with a preferred embodiment of the present invention the responding step designates an IP address of an internal server that supports the domain name in the DNS query.
[0073] The method may further include the steps of: receiving a request having a destination IP address corresponding to the selected ISP, and translating the destination IP address to an IP address within the private network.
[0074] There is also provided in accordance with yet another preferred embodiment of the present invention a network management system for managing a computer network connected to the Internet through a plurality of ISPs, including a network controller receiving a DNS resolution query from a remote computer for a domain name within a computer network, sending polling requests through a plurality of ISPs from the computer network to the remote computer, and receiving replies from the remote computer corresponding to the polling requests, and a proximity analyzer measuring proximities of the remote computer to the computer network via the plurality of ISPs, based on the replies.
[0075] Further in accordance with a preferred embodiment of the present invention, the plurality of ISPs assign respective IP addresses to the computer network, and the network controller designates a source IP address for each polling request corresponding to the ISP through which the polling request is sent.
[0076] Still further in accordance with a preferred embodiment of the present invention, the polling requests are TCP/IP requests, UDP requests, or ping requests.
[0077] Additionally in accordance with a preferred embodiment of the present invention the proximity analyzer measures proximities based on the number of hops undergone by the received replies in travelling from the remote server to the computer network.
[0078] Moreover in accordance with a preferred embodiment of the present invention, the proximity analyzer measures proximities based on the latency, relative TTL, and number of hops of the received replies in travelling from the remote server to the computer network.
[0079] Still further in accordance with a preferred embodiment of the present invention, the proximity analyzer rates the plurality of ISPs based on the measured proximities, and enters the ratings in a proximity table within a table entry indexed by an address related to the remote server computer. Preferably the proximity analyzer determines the best three choices for ISPs based on the measured proximities.
[0080] Additionally in accordance with a preferred embodiment of the present invention, the address related to the remote server computer is a subnet IP address of the remote server computer.
[0081] There is further provided in accordance with yet another preferred embodiment of the present invention, a network management system for managing a computer network connected to the Internet through a plurality of ISPs, including a network controller receiving a DNS resolution query from a remote computer for a domain name within a computer network, selecting one of a plurality of ISPs, and responding to the DNS resolution query with an IP address associated with the selected ISP, and a data manager looking up a table entry within a proximity table indexed by an address related to the remote computer, the tables entries of the proximity table containing ratings for the plurality of ISPs. The network controller may also select an ISP based on ratings within the table entry looked up in the proximity table.
[0082] Further in accordance with a preferred embodiment of the present invention, the address related to the remote computer is a subnet IP address of the remote computer.
[0083] Still further in accordance with a preferred embodiment of the present invention, the table entries contain the best three choices for ISPs through which to connect to the remote computer from within the computer network, and the network controller selects the best ISP, from among the best three choices for ISPs, that is available and not overloaded. Preferably, the network controller determines whether or not an ISP is overloaded based upon a user-configurable load threshold.
[0084] Additionally in accordance with a preferred embodiment of the present invention the network controller selects an ISP based on current load, in the event that all three of the best three choices for ISP are unavailable or overloaded.
[0085] Moreover in accordance with a preferred embodiment of the present invention, the plurality of ISPs assign respective IP addresses to the computer network, and wherein said network controller designates an IP address corresponding to the selected ISP. Preferably the computer network is a private network, visible externally through a network address translation.
[0086] Still further in accordance with a preferred embodiment of the present invention the network controller designates an IP address of an internal server that supports the domain name in the DNS query.
[0087] Additionally or alternatively the network controller receives a request having a destination IP address corresponding to the selected ISP; the system further comprising a network address translator translating the destination IP address to an IP address within the private network.
[0088] There is thus provided in accordance with yet another preferred embodiment of the present invention a routing system for routing data via a network from a first node to a second node, and wherein the network having a plurality of available routes from the first node to the second node, and the system also includes a route selector operable to select one of the routes for sending data between the first node and second node on the basis of content information of the data, an obtained quality level of the routes and proximity information.
[0089] There is further provided in accordance with a further preferred embodiment of the present invention a routing system for routing data via a network from a first node to a second node, and wherein the network having a plurality of available routes from the first node to the second node, and the system also includes a route selector operable to select one of the routes for sending data between the first node and second node on the basis of costing information of said routes.
[0090] Further in accordance with a preferred embodiment of the present invention the route selector is operable to select one of the routes for sending data between the first node and second node additionally on the basis of cost information of the routes.
[0091] Still further in accordance with a preferred embodiment of the present invention the route selector is operable to perform optimization between content information of the data and costing information of the routes, to select a route.
[0092] Additionally in accordance with a preferred embodiment of the present invention the route selector is operable to perform optimization additionally on the basis of delay time of the connection, to select a route.
[0093] Moreover in accordance with a preferred embodiment of the present invention the route selector is operable to perform optimization additionally on the basis of path quality, to select a route
[0094] Additionally in accordance with a preferred embodiment of the present invention the route selector is operable to perform optimization additionally on the basis of traffic load, to select a route.
[0095] Still further in accordance with a preferred embodiment of the present invention the route selector is operable to perform optimization additionally on the basis of delay time of the connection.
[0096] Furthermore, a Destinations Table is built to summarize the connection data for each one of a plurality of possible destination nodes. The Destinations Table is built based on previously determined proximities.
[0097] Additionally the route selector is operable to configure and use a Decision Parameter Table comprising parameters of the routes. Furthermore, different Decision Parameters are supplied for each respective content type. The Decision Parameter Table also includes at least one of a group of parameter weights comprising. Data packet content; Hops weighting factor; Packet loss factor and Response time factor. It is appreciated that a different Decision Parameters is used for each respective content.
[0098] A Decision Function F<sub>content </sub>is calculated for each path from the first node to the second nodes based on said Decision Parameter Table. The Decision Function F<sub>content </sub>is defined as:
[0099] F<sub>content</sub>=F(Hops weighting factor*Hops count factor; Response weighting factor*Response time factor; Path quality weighting factor*Path quality factor, Packet loss weighting factor*Packet loss factor).
[0100] All factors and weights are taken from the Destination Table and the Decision Parameter Table, respectively.
[0101] Still further in accordance with a preferred embodiment of the present invention, the above parameters, which are used in the calculation of F<sub>content</sub>; are normalized for each path.
[0102] Still further in accordance with a preferred embodiment of the present invention, all previously defined factors are normalized for each path between the first node and the second node. Preferably the route selector is operable to decide on the path for routing the data packet from the first node to said second node based on said Decision Function.
[0103] The network connection may be for the internet or for different ISPs.
[0104] There is further provided in accordance with yet another preferred embodiment of the present invention a method for routing data by a content routing system from a first node to a second node via a network and including the steps of providing a plurality of available routes from the firs node to the second node and selector selecting one of the routes for sending data between the first node and second node on the basis of content information of the data.
[0105] There is also provided in accordance with yet another preferred embodiment of the present invention a method for routing data by a content routing system from a first node to a second node via a network and including the steps of providing a plurality of available routes from the first node to the second node and a route selector selecting one of the routes for sending data between the first node and second node on the basis of costing information of the routes.
[0106] Further in accordance with a preferred embodiment of the present invention the method includes selecting one of the routes for sending data between the first node and second node on the basis of costing information of the routes.
[0107] Still further in accordance with a preferred embodiment of the present invention the method further includes the step of performing optimization between content information of the data and costing information of the routes.
[0108] Moreover in accordance with a preferred embodiment of the present invention, including the step of performing optimization additionally on the basis of delay time of the connection, or on the basis of path quality of the connection, or on the basis of packet loss of the path, or on a combination of any of these parameters. Further in accordance with a preferred embodiment of the present invention the available routes possess a path quality factor Q<sub>i</sub>. The path quality factor Q<sub>i </sub>is defined as being a function of the traffic load, packet loss, and lint pricing. Additionally, the path quality factor Q<sub>i </sub>is dependent on the content of the data packet.
[0109] Still father in accordance with a preferred embodiment of the present invention the path quality factor Q<sub>i </sub>is checked periodically.
[0110] There is further provided in accordance with a preferred embodiment of the present invention a method for calculating a path quality parameter for a network path between a first node and a second node, including the step of checking the availability of the path, the cost of the path connection, and the data packet loss rate of the path.
BRIEF DESCRIPTION OF DRAWINGS
[0111] The present invention will be understood and appreciated from the following detailed description, taken in conjunction with the drawings in which:
[0112] FIGS. <b>1</b>A-<b>1</b>C, taken together, are simplified pictorial flow illustrations of a triangulation load balancing system constructed and operative in accordance with a preferred embodiment of the present invention;
[0113] FIGS. <b>2</b>A-<b>2</b>F, taken together, are simplified pictorial flow illustrations of a network proximity load balancing system constructed and operative in accordance with another preferred embodiment of the present invention;
[0114] FIGS. <b>3</b>A-<b>3</b>F, taken together, are simplified pictorial flow illustrations of a preferred embodiment of the present invention for managing and load balancing a multi-homed network architecture whereby a client is connected to the Internet through multiple ISPs; and
[0115]FIGS. 4A and 4B, taken together, are simplified pictorial illustrations of a preferred embodiment of the present invention used to resolve incoming DNS requests for a multi-homed network architecture;
[0116]FIG. 5 illustrates a content routing system constructed and operative in accordance with yet another preferred embodiment of the present invention;
[0117]FIG. 6 is a simplified flowchart illustrating the operation of the content router in accordance with another preferred embodiment of the present invention; and
[0118]FIG. 7 illustrates a typical Destination Table which is compiled by the content router for each router and its respective path in accordance with another preferred embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
[0119] Reference is now made to FIGS. <b>1</b>A-<b>1</b>C which, taken together, are simplified pictorial flow illustrations of a triangulation load balancing system constructed and operative in accordance with a preferred embodiment of the present invention. Two server farms, generally designated <b>10</b> and <b>12</b> respectively, are shown connected to a network <b>14</b>, such as the Internet, although it is appreciated that more than two server farms may be provided. Server farms <b>10</b> and <b>12</b> typically comprise a load balancer <b>16</b> and <b>18</b> respectively, which may be a dedicated load balancer or a server or router configured to operate as a load balancer, with each of the load balancers being connected to one or more servers <b>20</b>. Load balancers <b>16</b> and <b>18</b> are alternatively referred to herein as LB<b>1</b> and LB<b>2</b> respectively. LB<b>1</b> and LB<b>2</b> typically maintain a server status table <b>22</b> and <b>24</b> respectively, indicating the current load, configuration, availability, and other server information as is common to load balancers. LB<b>1</b> and LB<b>2</b> also typically periodically receive and maintain each other's overall status and load statistics such that LB<b>1</b> and LB<b>2</b> can know each other's availability.
[0120] Typical operation of the triangulation load balancing system of FIGS. <b>1</b>A-<b>1</b>C is now described by way of example. As is shown more particularly with reference to FIG. 1A, a client <b>26</b>, such as any known computer terminal configured for communication via network <b>14</b>, is shown sending a request <b>28</b>, such as an FTP or HTTP request, to LB<b>1</b> whose virtual IP address is 100.100.1.0. In accordance with network transmission protocols, request <b>28</b> indicates the source IP address of the requestor, being the IP address 197.1.33.5 of client <b>26</b>, and the destination IP address, being the virtual IP address 100.100.1.0 of LB<b>1</b>. LB<b>2</b> preferably periodically sends a status report <b>30</b> to LB<b>1</b>, the virtual IP address 100.100.1.0 of LB<b>1</b> being known in advance to LB<b>2</b>. Status report <b>30</b> typically indicates the availability of server farm <b>12</b> and provides load statistics, which LB<b>1</b> maintains.
[0121] LB<b>2</b> is preferably capable of having multiple viral IP addresses as is well known. It is a particular feature of the present invention for LB<b>2</b> to designate a currently unused virtual IP address, such as 200.100.1.1, for LB<b>1</b>'s use and store the mapping between the IP address of LB<b>1</b> and the designated IP address in a triangulation mapping table <b>32</b>, as is shown more particularly with reference to FIG. 1B. The designated address is referred to herein as the triangulation address and may be preconfigured with LB<b>1</b> or periodically provided to LB<b>1</b> from LB<b>2</b>. LB<b>1</b> preferably maintains in a client mapping table <b>36</b> a mapping of the IP address 197.1.33.5 of client <b>26</b> and the triangulation address 200.100.1.1 of LB<b>2</b> to which client <b>26</b>'s requests may be redirected.
[0122] As shown in the example of FIG. 1A, server status table <b>22</b> of LB<b>1</b> indicates that no servers in server farm <b>10</b> are available to service client <b>26</b>'s request, but indicates that server farm <b>12</b> is available. Having decided that client <b>26</b>'s request should be forwarded to LB<b>2</b>, in FIG. 1C LB<b>1</b> substitutes the destination IP address of request <b>28</b> with the virtual IP address 200.100.1.1 of LB<b>2</b> which is now mapped to the IP address of client <b>26</b> as per client mapping table <b>36</b> and sends an address-modified client request <b>38</b> to LB<b>2</b>. LB<b>2</b>, upon receiving request <b>38</b> at its virtual IP address 200.100.1.1, checks triangulation mapping table <b>32</b> and finds that virtual IP address 200.100.1.1 has been designated for LB<b>1</b>'s use. LB<b>2</b> therefore, uses the virtual IP address 100.100.1.0 of LB<b>1</b> as per triangulation mapping table <b>32</b> as the source IP address of an outgoing response <b>40</b> that LB<b>2</b> sends to client <b>26</b> after the request has been serviced by one of the servers in server farm <b>12</b> selected by LB<b>2</b>. It is appreciated that response <b>40</b> must appear to client <b>26</b> to come from LB<b>1</b>, otherwise client <b>26</b> will simply ignore response <b>40</b> as an unsolicited packet. Client <b>26</b> may continue to send requests to LB<b>1</b> which LB<b>1</b> then forwards requests to LB<b>2</b> at the designated triangulation address. LB<b>2</b> directs requests to an available server and sends responses to client <b>26</b> indicating LB<b>1</b> as the source IP address.
[0123] Reference is now made to FIGS. <b>2</b>A-<b>2</b>F which, taken together, are simplified pictorial flow illustrations of a network proximity load balancing system constructed and operative in accordance with another preferred embodiment of the present invention. The configuration of the system of FIGS. <b>2</b>A-<b>2</b>F is substantially similar to FIGS. <b>1</b>A-<b>1</b>C except as otherwise described hereinbelow. For illustration purposes, a third server firm, generally designated <b>50</b>, is shown connected to network <b>14</b>, although it is appreciated that two or more server farms may be provided. Server farm <b>50</b> typically comprises a load balancer <b>52</b>, which may be a dedicated load balancer or a server or router configured to operate as a load balancer, with load balancer <b>52</b> being connected to two or more servers <b>20</b>. Load balancer <b>52</b> is alternatively referred to herein as LB<b>3</b>.
[0124] Typical operation of the network proximity load balancing system of FIGS. <b>2</b>A-<b>2</b>F is now described by way of example. As is shown more particularly with reference to FIG. 2A, client <b>26</b> is shown sending request <b>28</b>, such as an FHP or HTTP request, to LB<b>1</b> whose virtual IP address is 100.100.1.0. LB<b>1</b> preferably maintains a proximity table <b>54</b> indicating subnets and the best server farm site or sites to which requests from a particular subnet should be routed. Determining the “best” site is described in greater detail hereinbelow.
[0125] Upon receiving a request, LB<b>1</b> may decide to service the request or not based on normal load balancing considerations. In any case, LB<b>1</b> may check proximity table <b>54</b> for an entry indicating the subnet corresponding to the subnet of the source IP address of the incoming request. As is shown more particularly with reference to FIG. 2B, if no corresponding entry is found in proximity table <b>54</b>, LB<b>1</b> may send a proximity request <b>56</b> to LB<b>2</b>, and LB<b>3</b>, whose virtual IP addresses are known in advance to LB<b>1</b>. Probity request <b>56</b> indicates the IP address of client <b>26</b>.
[0126] A “network proximity” may be determined for a requester such as client <b>26</b> with respect to each load balancer/server farm by measuring and collectively considering various attributes of the relationship such as latency, hops between client <b>26</b> and each server farm, and the processing capacity and quality of each server farm site, To determine comparative network proximity, LB<b>1</b>, LB<b>2</b>, and LB<b>3</b> preferably each send a polling request <b>58</b> to client <b>26</b> using known polling mechanisms. While known polling mechanisms included pinging client <b>26</b>, sending a TCP ACK message to client <b>26</b> may be used where pinging would otherwise fail due to an intervening firewall or NAT device filtering out a polling message. A TCP ACK may be sent to the client's source EP address and port. If the client's request was via a UDP connection a TCP ACK to the client's source IP address and port <b>80</b> may be used. One or both TCP ACK messages should bypass any intervening NAT or firewall and cause client <b>26</b> to send a TCP RST message, which may be used to determine both latency and TTL. While TTL does not necessarily indicate the number of hops from the client to the load balancer, comparing TTL values from LB<b>1</b>, LB<b>2</b>, and LB<b>3</b> should indicate whether it took relatively more or less hops.
[0127] Another polling method involves sending a UDP request to a relatively high port number at the client, such as <b>2090</b>. This request would typically be answered with an “ICMP port unreachable” reply which would indicate the TTL value of the UTP request on arrival at the client. Since the starting TTL value of each outgoing UDP request is known, the actual number of hops to the client may be determined by subtracting the TTL value on arrival at the client from the starting TTL value. A combination of pinging, TCP ACK, UDP, TCP SYN, and other polling techniques may be used since any one polling request might fail.
[0128] Client <b>26</b> is shown in FIG. 2D sending a polling response <b>60</b> to the various polling requests The responses may be used to determine the latency of the transmission, as well as the TTL value. LB<b>2</b> and LB<b>3</b> then send polling results <b>62</b> to LB<b>1</b>, as shown in FIG. 2E. The polling results may then be compared, and LB<b>1</b>, LB<b>2</b>, and LB<b>3</b> ranked, such as by weighting each attribute and determining a total weighted value for each server farm. Polling results may be considered together with server farm capacity and availability, such as may be requested and provided using known load balancing reporting techniques or as described hereinabove with reference to FIGS. 1A and 1B, to determine the server farm site that is “closest” to client <b>26</b> and, by extension, the client's subnet, which, in the example shown, is determined to be LB<b>2</b>. For example, the closest site may be that which has the lowest total weighted value for all polling, load, and capacity results. LB<b>1</b> may then store the closest site to the client/subnet in proximity table <b>54</b>.
[0129] As was described above, a load balancer that receives a request from a client may check proximity table <b>54</b> for an entry indicating the subnet corresponding to the subnet of the source IP address of the incoming request. Thus, if a corresponding entry is found in proximity table <b>54</b>, the request is simply routed to the location having the best network proximity. Although the location having the best network proximity to a particular subnet may have already been determined, the load balancer may nevertheless decide to forward an incoming request to a location that does not have the best network proximity should a load report received from the best location indicate that the location is too busy to receive requests. In addition, the best network proximity to a particular subnet may be periodically redetermined, such as at fixed times or after a predetermined amount of time has elapsed from the time the last determination was made.
[0130] As is shown more particularly with reference to FIG. 2F, once the closest site for client <b>26</b> has been determined, client <b>26</b> may be redirected to the closest site using various methods. If a DNS request is received from client <b>26</b>, LB<b>1</b> may respond with LB<b>2</b>'s address. If an HTTP request is received from client <b>26</b>, HTTP redirection may be used. Alternatively, regardless of the type of request received from client <b>26</b>, triangulation as described hereinabove with reference to FIGS. <b>1</b>A-<b>1</b>C may be used
[0131] The present invention can also be used in a multi-homing environment; i.e., for management of networks that have multiple connections to the Internet through multiple Internet Service Providers (ISPs).
[0132] Reference is now made to FIGS. <b>3</b>A-<b>3</b>F, which illustrate a preferred embodiment of the present invention for managing and load balancing a multi-homed network architecture whereby a client is connected to the Internet through multiple ISPs. As illustrated in FIG. 3A, a client <b>105</b> is connected to the Internet <b>110</b> through three ISPs, <b>115</b>, <b>120</b> and <b>125</b>, each having a respective router <b>130</b>, <b>135</b> and <b>140</b> to controls the flow of data packets. The system includes a content router <b>145</b>, operative in accordance with a preferred embodiment of the present invention, to provide efficient connectivity between client <b>105</b> and Internet servers, such as server <b>150</b>. As illustrated in FIG. 3A, client <b>105</b> has an IP address of 10.1.1.1 on a private network and seeks to connect to server <b>150</b> having an IP address of 192.115.90.1.
[0133] As illustrated in FIG. 3B, ISPs <b>115</b>, <b>120</b> and <b>125</b> assign respective IP address ranges to the client network, indicated in FIG. 3B by ranges 20.x.x.x, 30.x.x.x and 40.x.x.x. The first time that client <b>105</b> connects to server <b>150</b>, content router <b>145</b> preferably sends polling requests through each of routers <b>130</b>, <b>135</b> and <b>140</b> in order to determine the proximity of server <b>150</b> to client <b>105</b>. When sending the polling requests, content router <b>145</b> assigns respective network addresses 20.1.1.1, 30.1.1.1 and 40.1.1.1 to client <b>105</b>. Thus three polling requests are sent: one from each of the sources 20.1.1.1, 30.1.1 .1 and 40.1.1.1 to destination 192.115.90.1.
[0134] As illustrated in FIG. 3C, server <b>150</b> replies to each network address 20.1.1.1, 30.1.1.1 and 40.1.1.1, and the replies are accordingly transmitted through each of the respective ISPs <b>115</b>, <b>120</b> and <b>125</b>. Each of the replies is measured for latency and number of hops. For example, as illustrated in FIG. 3C, the three replies respective have latency and TTL metrics of 800/60; 300/54; and 500/56.
[0135] Based on these polling results, content router <b>145</b> chooses, for example, router <b>135</b> as its first choice for connecting client <b>105</b> with server <b>150</b>. As illustrated in FIG. 3D, proximity results are stored in a proximity table <b>155</b>. Specifically, proximity table <b>155</b> indicates that router <b>135</b> is the first choice for connecting content router <b>145</b> to any computer residing on subnet 192.115.90. Thus, when a new client <b>160</b> with IP address 10.2.2.2 on the private network attempts to connect to a server <b>165</b> with IP address 192.115.90.2, through a content router <b>145</b>, content router <b>145</b> determines from proximity table <b>155</b> that the best router to use is router <b>135</b>.
[0136] In turn, as illustrated in FIG. 3E, content router <b>145</b> sends requests issued from client <b>160</b> via router <b>135</b>, and indicates a source IP address of 30.1.1.1 with each such request, which is the IP address associated with router <b>135</b> from within the range of IP addresses allocated by ISP <b>120</b>.
[0137] As illustrated in FIG. 3F, this ensures that subsequent responses sent back from server <b>165</b> will be addressed to IP address 30.1.1.1 and, accordingly, will be routed through ISP <b>120</b>. Content router <b>145</b> in turn uses network address translation (NAT) data to determine that IP address 30.1.1.1 corresponds to private IP address 10.2.2.2, and transmits the responses from server <b>165</b> back to client <b>160</b>.
[0138] Reference is now made to FIG. 4A, which illustrates a preferred embodiment of the present invention used to resolve incoming DNS requests for a multi-homed network architecture. Server <b>170</b> is assigned IP address 10.3.3.3 within a private multi-homed network, similar to the network illustrated in FIG. 3A. Each of ISPs <b>115</b>, <b>120</b> and <b>125</b> assigns a range of IP addresses to the multi-homed network A DNS request for resolution of a domain name is issued from a client <b>175</b> with IP address 192.115.90.3. The DNS request has a source IP address of 192.115.90.3 and a destination IP address of 20.1.1.1. As such, it arrives at content router <b>145</b> via router <b>130</b>.
[0139]FIG. 4B indicates a NAT mapping table <b>180</b>, showing that the private IP address 10.3.3.3 for server <b>170</b> is translated to IP addresses 20.3.3.3, 30.3.3.3 and 40.3.3.3, respectively, by routers <b>130</b>, <b>135</b> and <b>140</b>. Content router <b>145</b> looks up the subnet entry 192.11.5.90 in proximity table <b>155</b>, and identifies router <b>135</b> as the first choice for best proximity between server <b>170</b> and client <b>175</b>. In resolving the DNS request, content router <b>145</b> accordingly provides 30.3.3.3 as the IP address for the domain name server, even though the original request indicated a destination IP address of 20.1.1.1. This ensures that requests from client <b>175</b> are sent to server <b>170</b> with a destination IP address of 30.3.3.3, which in turn ensures that the client requests are transmitted through ISP <b>120</b>.
[0140] It can be seen from FIGS. <b>3</b>A-<b>3</b>F that the present invention efficiently balances the load among the three ISPs <b>115</b>, <b>120</b> and <b>125</b> for outgoing connections. Similarly, it can be seen from FIGS. 4A and 4B that the present invention efficiently balances the load among the three ISPs <b>115</b>, <b>120</b> and <b>125</b> for incoming connections. In the event that the router indicated as first choice for the best proximity connection is unavailable or overloaded, the present invention preferably uses a second choice router instead. Thus the present invention ensures that if an ISP service is unavailable, connectivity to the Internet is nevertheless maintained.
[0141] Referring back to FIG. 3F, suppose for example that ISP <b>120</b> is unavailable, and that content router <b>145</b> routes the outgoing client request through ISP <b>125</b> instead of through ISP <b>120</b>. In accordance with a preferred embodiment of the present invention, content router <b>145</b> routes the outgoing request through ISP <b>125</b> and labels the outgoing request with a source IP address of 40.111.11. Had content router <b>145</b> used ISP <b>125</b> but indicated a source IP address of 30.1.1.1,the response from server <b>150</b> would be directed back through ISP <b>125</b>, and not be able to get through to client <b>160</b>.
[0142] Similarly, referring back to FIG. 4B, suppose for example that ISP <b>120</b> is unavailable, and that content router <b>145</b> resolves the DNS request with IP address 40.3.3.3 instead of IP address 30.3.3.3. This ensures that client <b>175</b> directs it requests through ISP <b>125</b>, and avoids any blockage at ISP <b>120</b>.
[0143] Reference is now made to FIG. 5, which illustrates a content routing system <b>500</b> constructed and operative in accordance with yet another preferred embodiment of the present invention. The content routing system <b>500</b>, connects a client <b>502</b> to a destination <b>504</b> via a network system, such as the Internet network <b>506</b>, using a content router <b>508</b>. The content router <b>508</b> is connected to the internet <b>506</b> typically via routers, R<sub>1</sub><b>510</b> and R<sub>2 </sub><b>512</b>. The content router <b>508</b> presents to the client <b>502</b> the most efficient pathway for choosing his connection to the destination <b>504</b>. The routers <b>510</b> and <b>512</b> are connected to paths <b>514</b> and <b>516</b>, respectively, and each path possess a path quality factor, Q<sub>1</sub>, and Q2, respectively.
[0144] The path quality factor Q<sub>i </sub>is defined as:
[0145] Path Quality Factor Q<sub>i</sub>=Q( traffic load; packet loss; link pricing)
[0146] The path quality factor, for a given path, is typically dependent on the data content of the data packet. Typical path quality weighting factors are shown in Table 1 for the listed data content. It is appreciated that path quality factor is typically checked periodically, by the content router <b>508</b>, for each Internet path.
[0147] It is appreciated that the managing of the routing, by the content router <b>508</b>, typically depends on the following factors: the content type, the number of hops to the destination, the response time of the destination, the availability of the path, the costing of the link and the average packet loss in the link.
[0148] In order for the content router <b>508</b> to determine the “best” path, a “Decision Parameter Table” is built for each content type. It is appreciated that the content type may vary between the application type and actual content (URL requested, or any other attribute in the packet). The Decision Parameter Table is preferably dependent on the parameters: Data packet content; Hops weighting factor; Packet loss factor and Response time factor. Typical values of these parameter are also given in Table 1. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="28PT" align="center" /><colspec colname="3" colwidth="42PT" align="center" /><colspec colname="4" colwidth="35PT" align="center" /><colspec colname="5" colwidth="49PT" align="center" /><thead><row><entry /><entry namest="OFFSET" nameend="5" align="center">TABLE 1</entry></row><row><entry /><entry /></row><row><entry /><entry namest="OFFSET" nameend="5" align="center" rowsep="1" /></row><row><entry /><entry>Content</entry><entry>Packet</entry><entry>Hops,</entry><entry>Response</entry><entry>Path</entry></row><row><entry /><entry>Type</entry><entry>Loss, %</entry><entry>%</entry><entry>Time, %</entry><entry>Quality, %</entry></row><row><entry /><entry namest="OFFSET" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="6"><colspec colname="OFFSET" colwidth="14PT" align="left" /><colspec colname="1" colwidth="49PT" align="left" /><colspec colname="2" colwidth="28PT" align="char" char="." /><colspec colname="3" colwidth="42PT" align="char" char="." /><colspec colname="4" colwidth="35PT" align="char" char="." /><colspec colname="5" colwidth="49PT" align="char" char="." /><tbody valign="top"><row><entry /><entry>HTTP</entry><entry>0</entry><entry>20</entry><entry>60</entry><entry>20</entry></row><row><entry /><entry>FTP</entry><entry>30</entry><entry>0</entry><entry>50</entry><entry>20</entry></row><row><entry /><entry>URL1</entry><entry>0</entry><entry>30</entry><entry>50</entry><entry>20</entry></row><row><entry /><entry>URL2</entry><entry>0</entry><entry>30</entry><entry>50</entry><entry>20</entry></row><row><entry /><entry>File Type 1</entry><entry>20</entry><entry>20</entry><entry>40</entry><entry>20</entry></row><row><entry /><entry>File Type 2</entry><entry>20</entry><entry>10</entry><entry>30</entry><entry>40</entry></row><row><entry /><entry>Telnet</entry><entry>0</entry><entry>0</entry><entry>20</entry><entry>80</entry></row><row><entry /><entry namest="OFFSET" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
[0149] In addition to the parameters listed in Table 1, the following additional parameters may also be taken into consideration Hops count factor; Response time factor; Path quality factor; and Packet loss factor
[0150] A Destination Table is built to summarize the following factors: the content type, the number of hops to the destination, the response time of the destination, the availability of the path, and the average packet loss in the link, based on proximity calculations, as previously defined.
[0151] Using the relevant data, as typically listed in Table 1, the content router <b>508</b> determines a Decision Function F<sub>content </sub>for each path;
[0152] F<sub>content</sub>=F(Hops weighting factor*Hops count factor; Response weighting factor*Response time factor, Path quality weighting factor*Path quality factor; Packet loss weighting factor*Packet loss factor).
[0153] It is appreciated that the above parameters, which are used in the calculation of F<sub>content </sub>, are typically normalized for each path.
[0154] Based on the Decision Function the content router <b>508</b> selects one of the available paths. The data packet is then routed through the selected path. The Decision Function for a particular path is determined by an administrative manager (not shown) and may depend, for example, on the minimum number of hops or on the relevant response time, or on the packet loss, or on the path quality, or any combination of the above parameters, according to the administrative preferences.
[0155] The operation of the content router <b>508</b> is summarized in the flowchart <b>600</b> illustrated in FIG. 6. In the first step <b>602</b>, the client <b>502</b> wishing to send a data packet to the destination <b>504</b>, sends the data packet (step <b>602</b>) to the content router <b>508</b>. The content router <b>508</b> preferably first checks (step <b>604</b>) to determine if the destination <b>504</b> is known (familiar) from the Destinations Table (FIG. 7) and that a previous check for the subnet of the destination <b>504</b> was already performed. If the destination <b>504</b> is familiar, the content router <b>508</b> selects a link to the destination <b>504</b> using the F<sub>content </sub>function, taking into account the parameters that were gathered earlier (step <b>606</b>). The F<sub>content </sub>function is normalized. The decision made in step <b>608</b> is then used by the content router <b>508</b> to make the connection with the destination <b>504</b> for routing the data packet.
[0156] If the destination <b>504</b> is unfamiliar, the content router <b>508</b> performs a destination check (step <b>610</b>). The destination check is performed by using the proximity methods, as described hereinabove, by generating actual web traffic towards the destination subnet. This function, as carried out by the content router <b>508</b> comprises building a Destination Table (FIG. 7), for each available router and its respective path. The Destination Table may then be used by the content router <b>508</b> on the next occasion the client <b>502</b> wishes to transfer data packets to the destination <b>504</b>. Consecutively, the content router <b>508</b> chooses the router (step <b>608</b>) for transferring the data packet to the destination <b>504</b>. This decision is preferably dependent on the path quality factor, as defined hereinabove.
[0157] Thus it may be appreciated that the present invention enables a multi-homed network architecture to realize the full benefits of its redundant route connections by maintaining fault tolerance and by balancing the load among these connections, and preferably using data packet content information in an intelligent decision making process.
[0158] It is appreciated that elements of the present invention described hereinabove may be implemented in hardware, software, or any suitable combination thereof using conventional techniques.
[0159] It is appreciated that the steps described with reference to FIGS. <b>1</b>A-<b>1</b>C and <b>2</b>A-<b>2</b>F need not necessarily be performed in the order shown unless otherwise indicated, and that in fact different implementations of the steps may be employed to yield similar overall results.
[0160] It is appreciated that various features of the invention which are, for clarity, described in the contexts of separate embodiments may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment may also be provided separately or in any suitable subcombination.
[0161] It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention is defined only by the claims that follow:
Contents6
21 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| CN104168197A | Cited by | China | Search report |
| US2017230283A1 | Cited by | United States of America | Search report |
| US2018324258A1 | Cited by | United States of America | Search report |
| US7984148B2 | Cited by | United States of America | Search report |
| US2008184338A2 | Cited by | United States of America | Pre-grant |
| US9584406B2 | Cited by | United States of America | Search report |
| EP2630583A4 | Cited by | European Patent Office (EPO) | Examiner |
| US8838969B2 | Cited by | United States of America | Applicant |
| US2014164479A1 | Cited by | United States of America | Pre-grant |
| WO2007138068A1 | Cited by | World Intellectual Property Organization (WIPO) | International search |
| US10454879B2 | Cited by | United States of America | Applicant |
| US8958439B2 | Cited by | United States of America | Applicant |
| US11405277B2 | Cited by | United States of America | Search report |
| US10721117B2 | Cited by | United States of America | Applicant |
| US2013297596A1 | Cited by | United States of America | Pre-grant |
| US10142282B2 | Cited by | United States of America | Search report |
| US8275826B2 | Cited by | United States of America | Search report |
| US2014344396A1 | Cited by | United States of America | Pre-grant |
| US2015288619A1 | Cited by | United States of America | Pre-grant |
| CN104168195A | Cited by | China | Search report |
| US2012096118A1 | Cited by | United States of America | Pre-grant |
| US8463920B2 | Cited by | United States of America | Search report |
| CN103491053A | Cited by | China | Search report |
| US9054943B2 | Cited by | United States of America | Search report |
| US2017250946A1 | Cited by | United States of America | Pre-grant |
| US2011047177A1 | Cited by | United States of America | Pre-grant |
| US7912954B1 | Cited by | United States of America | Search report |
| US11350254B1 | Cited by | United States of America | Applicant |
| US2014379916A1 | Cited by | United States of America | Pre-grant |
| US2011023117A1 | Cited by | United States of America | Pre-grant |
| US2007094361A1 | Cited by | United States of America | Pre-grant |
| US9350532B2 | Cited by | United States of America | Applicant |
| US2009138618A1 | Cited by | United States of America | Pre-grant |
| US10672286B2 | Cited by | United States of America | Applicant |
| US10079759B2 | Cited by | United States of America | Applicant |
| US9178709B2 | Cited by | United States of America | Search report |
| US2005097366A1 | Cited by | United States of America | Pre-grant |
| US2011029642A1 | Cited by | United States of America | Pre-grant |
| US8166197B2 | Cited by | United States of America | Search report |
| US8874785B2 | Cited by | United States of America | Search report |
| US2004004969A1 | Cited by | United States of America | Pre-grant |
| US2022329625A1 | Cited by | United States of America | Search report |
| US7680938B2 | Cited by | United States of America | Search report |
| US7761562B1 | Cited by | United States of America | Search report |
| US8341296B1 | Cited by | United States of America | Applicant |
| US2003065787A1 | Cited by | United States of America | Pre-grant |
| US2011185281A1 | Cited by | United States of America | Pre-grant |
| US2007112783A1 | Cited by | United States of America | Pre-grant |
| US7945678B1 | Cited by | United States of America | Applicant |
| US2015149563A1 | Cited by | United States of America | Pre-grant |
| US2006101009A1 | Cited by | United States of America | Pre-grant |
| US10826981B2 | Cited by | United States of America | Search report |
| CN115277708A | Cited by | China | Search report |
| US11089128B2 | Cited by | United States of America | Search report |
| US10880381B2 | Cited by | United States of America | Search report |
| US2007094336A1 | Cited by | United States of America | Pre-grant |
| US2018343232A1 | Cited by | United States of America | Search report |
| US2017230283A1 | Cited by | United States of America | Pre-grant |
| US2012102225A1 | Cited by | United States of America | Pre-grant |
| US8516129B1 | Cited by | United States of America | Applicant |
| US2006277278A1 | Cited by | United States of America | Pre-grant |
| US9244926B2 | Cited by | United States of America | Search report |
| US7277954B1 | Cited by | United States of America | Search report |
| US2008140826A1 | Cited by | United States of America | Pre-grant |
| US2015149563A1 | Cited by | United States of America | Search report |
| US2005022203A1 | Cited by | United States of America | Pre-grant |
| US2006101009A1 | Cited by | United States of America | Pre-grant |
| US2009327312A1 | Cited by | United States of America | Pre-grant |
| US2010250668A1 | Cited by | United States of America | Pre-grant |
| US8725895B2 | Cited by | United States of America | Search report |
| US8108554B1 | Cited by | United States of America | Applicant |
| US9787564B2 | Cited by | United States of America | Applicant |
| US2016028801A1 | Cited by | United States of America | Search report |
| US2007011450A1 | Cited by | United States of America | Pre-grant |
| US7734683B1 | Cited by | United States of America | Search report |
| US10749936B1 | Cited by | United States of America | Search report |
| US8464057B2 | Cited by | United States of America | Applicant |
| US11556556B2 | Cited by | United States of America | Applicant |
| US8291108B2 | Cited by | United States of America | Applicant |
| US9143558B2 | Cited by | United States of America | Search report |
| US2012324068A1 | Cited by | United States of America | Pre-grant |
| US10505792B1 | Cited by | United States of America | Applicant |
| US8260951B2 | Cited by | United States of America | Search report |
| US8230032B2 | Cited by | United States of America | Applicant |
| US8892626B2 | Cited by | United States of America | Applicant |
| US10462235B2 | Cited by | United States of America | Applicant |
| US2017126547A1 | Cited by | United States of America | Pre-grant |
| US2007147395A1 | Cited by | United States of America | Pre-grant |
| US2007124476A1 | Cited by | United States of America | Pre-grant |
| US7636789B2 | Cited by | United States of America | Search report |
| US2011153827A1 | Cited by | United States of America | Pre-grant |
| US2006117026A1 | Cited by | United States of America | Pre-grant |
| US2006047813A1 | Cited by | United States of America | Pre-grant |
| US11032127B2 | Cited by | United States of America | Applicant |
| US8706906B2 | Cited by | United States of America | Applicant |
| US2011185027A1 | Cited by | United States of America | Pre-grant |
| CN107733950A | Cited by | China | Search report |
| US8689280B2 | Cited by | United States of America | Search report |
| US2011202609A1 | Cited by | United States of America | Pre-grant |
| US11178150B1 | Cited by | United States of America | Applicant |
14 members in 1 office
Priority claims10
| Document | Office | Kind | Date |
|---|---|---|---|
| 11564398 | United States of America | A | |
| 11564398 | United States of America | A | |
| 46776399 | United States of America | A | |
| 46776399 | United States of America | A | |
| 44901603 | United States of America | A | |
| 09115643 | – | – | – |
| 09467763 | – | – | – |
| US19980115643 | – | – | – |
| US19990467763 | – | – | – |
| US20030449016 | – | – | – |
Members14
| Document | Office | Kind | |
|---|---|---|---|
| US6249801B1 | United States of America | B1 | |
| US2002103846A1 | United States of America | A1 | |
| US2003195984A1 | United States of America | A1 | |
| US6665702B1 | United States of America | B1 | |
| US6718359B2 | United States of America | B2 | |
| US2005022203A1 | United States of America | A1 | |
| US7984148B2 | United States of America | B2 | |
| US8266319B2 | United States of America | B2 | |
| US2012303784A1 | United States of America | A1 | |
| US8484374B2 | United States of America | B2 | |
| US2013297765A1 | United States of America | A1 | |
| US2014330983A1 | United States of America | A1 | |
| US9231853B2 | United States of America | B2 | |
| US10819619B2 | United States of America | B2 |
154 transactions on the USPTO file
Allowed after 5 non-final rejections, 1 final rejection, 1 RCE and 2 appeals.
- Non-final rejections
- 5
- Final rejections
- 1
- RCEs
- 1
- Appeals
- 2
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Recordation of Patent Grant MailedPGM/ | PGM/ | |
| Patent Issue Date Used in PTA CalculationAllowedPTAC | PTAC | |
| Email NotificationEML_NTR | EML_NTR | |
| Issue Notification MailedAllowedWPIR | WPIR | |
| Dispatch to FDCD1935 | D1935 | |
| Email NotificationEML_NTR | EML_NTR | |
| Email NotificationEML_NTR | EML_NTR | |
| Printer Rush- No mailingTCPB | TCPB | |
| Filing Receipt - CorrectedFLRCPT.C | FLRCPT.C | |
| Mail Miscellaneous Communication to ApplicantMM327 | MM327 | |
| Application Is Considered Ready for IssuePILS | PILS | |
| Issue Fee Payment VerifiedN084 | N084 | |
| Issue Fee Payment ReceivedIFEE | IFEE | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Miscellaneous Communication to Applicant - No Action CountM327 | M327 | |
| Miscellaneous Incoming LetterLET. | LET. | |
| Pubs Case Remand to TCPUBTC | PUBTC | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail Notice of AllowanceAllowedMN/=. | MN/=. | |
| Notice of Allowance Data Verification CompletedAllowedN/=. | N/=. | |
| Reasons for AllowanceEX.R | EX.R | |
| Examiner's Amendment CommunicationEX.A | EX.A | |
| Email NotificationEML_NTR | EML_NTR | |
| Change in Power of Attorney (May Include Associate POA)PA.. | PA.. | |
| Correspondence Address ChangeC.AD | C.AD | |
| Email NotificationEML_NTR | EML_NTR | |
| Mail BOA miscellaneous communication to applicantMM327-E | MM327-E | |
| BOA miscellaneous communication to applicantM327-E | M327-E | |
| Electronic ReviewELC_RVW | ELC_RVW | |
| Email NotificationEML_NTF | EML_NTF | |
| Mail BPAI Decision on Appeal - ReversedMAPDR | MAPDR | |
| BPAI Decision - Examiner ReversedAPDR | APDR | |
| Confirmation of Hearing by AppellantAPCH | APCH | |
| Email NotificationEML_NTR | EML_NTR | |
| Notification of Appeal HearingAPNH | APNH | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Docketing Notice Mailed to AppellantAP_DK_M | AP_DK_M | |
| Assignment of Appeal NumberAPAS | APAS | |
| Appeal Awaiting BPAI DocketingAPWD | APWD | |
| Mail Reply Brief Noted by ExaminerMRBNE | MRBNE | |
| Reply Brief Noted by ExaminerRBNE | RBNE | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Reply Brief FiledAPRB | APRB | |
| Request for Oral HearingAPOH | APOH | |
| Exam. Ans. Review CompletePACC | PACC | |
| Mail Examiner's AnswerMAPEA | MAPEA | |
| Examiner's Answer to Appeal BriefAPEA | APEA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Notice -- Defective Appeal BriefAPBD | APBD | |
| Appeal Brief Review CompleteAPBR | APBR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Appeal Brief FiledAP.B | AP.B | |
| Defective / Incomplete Appeal Brief FiledAPBI | APBI | |
| Appeal Brief FiledAP.B | AP.B | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Notice -- Defective Appeal BriefAPBD | APBD | |
| Appeal Brief Review CompleteAPBR | APBR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Defective / Incomplete Appeal Brief FiledAPBI | APBI | |
| Appeal Brief FiledAP.B | AP.B | |
| Notice -- Defective Appeal BriefAPBD | APBD | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Appeal Brief Review CompleteAPBR | APBR | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Defective / Incomplete Appeal Brief FiledAPBI | APBI | |
| Appeal Brief FiledAP.B | AP.B | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Amendment/Argument after Notice of AppealAP/A | AP/A | |
| Notice of Appeal FiledN/AP | N/AP | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response after Non-Final ActionA... | A... | |
| Mail Notice of Informal or Non-Responsive AmendmentNINA | NINA | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Affidavit(s) (Rule 131 or 132) or Exhibit(s) ReceivedAF/D | AF/D | |
| Affidavit(s) (Rule 131 or 132) or Exhibit(s) ReceivedAF/D | AF/D | |
| Informal or Non-Responsive Amendment after Examiner ActionA.I. | A.I. | |
| Response after Non-Final ActionA... | A... | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Mail Examiner Interview Summary (PTOL - 413)MEXIN | MEXIN | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Disposal for a RCE / CPA / R129AbandonedABN9 | ABN9 | |
| Request for Continued Examination (RCE)RCEX | RCEX | |
| Request for Extension of Time - GrantedXT/G | XT/G | |
| Workflow - Request for RCE - BeginBRCE | BRCE | |
| Notice of Appeal FiledN/AP | N/AP |
12 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Lapsed due to failure to pay maintenance feeLapsedFP | FP | |
| Lapse for failure to pay maintenance feesLapsedPATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYLAPS | LAPS | |
| Information on status: patent discontinuationPATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362STCH | STCH | |
| Fee payment procedureMAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITYFEPP | FEPP | |
| Maintenance fee paymentMAFP | MAFP | |
| Fee paymentFPAY | FPAY | |
| AssignmentAS | AS | |
| Information on status: patent grantGrantedPATENTED CASESTCF | STCF | |
| Notice of allowance mailedORIGINAL CODE: MN/=.ZAAB | ZAAB | |
| Notice of allowance and fees dueORIGINAL CODE: NOAZAAA | ZAAA | |
| AssignmentAS | AS | |
| AssignmentAS | AS |
Numbers
- Publication, DOCDB
- 2003195984
- Publication, EPODOC
- US2003195984
- Application
- 10449016
- Application, DOCDB
- 44901603
- Application, EPODOC
- US20030449016
Titles
- English
- Load balancing
Patent term adjustment
- A delay
- +89 daysthe office missed an examination deadline
- B delay
- +207 dayspendency past three years
- C delay
- +1,185 daysinterference, secrecy order or appeal
- Applicant delay
- −410 days
- Net adjustment
- 1,071 days
Classification
- CPC, 11
- G06F9/505
- H04L67/1008
- H04L67/1006
- H04L67/101
- H04L67/1012
- H04L61/4511
- H04L67/1001
- H04L69/325
- H04L69/32
- H04L47/125
- H04L45/14
- IPC, 4
- G06F9 50
- H04L29 06
- H04L29 08
- H04L29 12
- USPC, 1
- 709238000