Access network authorization

Abstract

An access communication system provides access between a user system and a plurality of communication networks. The plurality of communication networks provide services to a user in the user system. An access communication system includes a local database system and an access server that is connected to the user system and the plurality of communication networks. The local database system receives a user logon. The local database system then processes the user logon to determine if the user is allowed access to the access communication system based on a local database system. The local database system then provides access to the access communication system to the user in response to the determination that the user is allowed access based on the local database system. The local database system then generates an authorization query for a second database system external to the local database system in response to the determination that the user is not allowed access based on the local database system. The local database system receives and processes an authorization response indicating whether the user is allowed to use the access system from the second database system. The local database system then provides access to the access communication system to the user in response to the authorization response that allows the user to use the access communication system.

Claims

I claim:

1. A method of operating an access system including an access server to provide access between a user system and a plurality of communication networks that provide services to a user, the method comprising:

receiving a user logon into the access server;

processing the user logon to determine if the user is allowed access to the access system based on a local database system;

providing access to the access system to the user in response to the determination that the user is allowed access based on the local database system;

generating an authorization query for a second database system external to the local database system in response to the determination that the user is not allowed access based on the local database system;

in the second database system, receiving and processing the authorization query to determine whether the user is allowed access;

in the second database system, generating and transmitting an authorization response to the local database system;

receiving and processing the authorization response indicating whether the user is allowed to use the access system from the second database system; and

providing access to the access system to the user in response to the authorization response that allows the user to use the access system.

2. The method of claim 1 further comprising generating and transmitting a logon query.

3. The method of claim 1 wherein processing the user logon to determine if the user is allowed access to the access system based on a local database system is based on a user access profile.

4. The method of claim 1 further comprising determining if the second database system exists.

5. The method of claim 1 further comprising disconnecting a user's network device from the access server in response to the determination that the user is not allowed to use the access system.

6. The method of claim 1 wherein the logon reply includes an access card account code.

7. The method of claim 1 wherein the logon reply includes foreign network account information and further comprising identifying the second external database based on the foreign network account information.

8. The method of claim 1 further comprising:

receiving a request for access into a service control point;

processing the request for access to determine the destination for the request;

generating and transmitting a reply to route the request to the access server.

9. The method of claim 1 further comprising logging contract and settlement information.

10. An access system for providing access between a user system and a plurality of communication networks that provide services to a user, the access system comprising:

an access server connected to the user system and the plurality of communication networks and configured to receive and transmit a user logon from the user system to a local database system;

the local database system connected to the access server and configured to receive the user logon, process the user logon to determine if the user is allowed access to the access system based on the local database system, provide access to the access system to the user in response to the determination that the user is allowed access based on the local database system, generate an authorization query for a second database system external to the local database system in response to the determination that the user is not allowed access based on the local database system, receive and process an authorization response indicating whether the user is allowed to use the access system from the second database system, and provide access to the access system to the user in response to the authorization response that allows the user to use the access system; and

the second database system connected to the local database system and configured to receive and process the authorization query to determine whether the user is allowed access and generate and transmit the authorization response for the local database system.

11. The access system of claim 10 wherein the access server is configured to generate and transmit a logon query.

12. The access system of claim 10 wherein the local database system is configured to process the user logon to determine if the user is allowed access to the access system based on a user access profile.

13. The access system of claim 10 wherein the local database system is configured to determine if the second database system exists.

14. The access system of claim 10 wherein the access server is configured to disconnect a user's network device in response to the determination that the user is not allowed to use the access system.

15. The access system of claim 10 wherein the logon reply includes an access card account code.

16. The access system of claim 10 wherein the logon reply includes foreign network account information and the local database system is configured to identify the second external database based on the foreign network account information.

17. The access system of claim 10 further comprising:

a service control point connected to the user system configured to receive a request for access, process the request for access to determine the destination for the request, and generate and transmit a reply to route the request to the access server.

18. The access system of claim 10 wherein the local database system is configured to log contract and settlement information.

19. A software product for providing access between a user system and a plurality of communication networks that provide services to a user, the software product comprising:

database software operational when executed by a processor to direct the processor to receive the user logon, process the user logon to determine if the user is allowed access to an access system based on a local database system, provide access to the access system to the user in response to the determination that the user is allowed access based on the local database system, generate an authorization query for a second database system external to the local database system in response to the determination that the user is not allowed access based on the local database system, receive and process an authorization response indicating whether the user is allowed to use the access system from the second database system, and provide access to the access system to the user in response to the authorization response that allows the user to use the access system; and

a software storage medium operational to store the database software.

20. The software product of claim 19 wherein the database software is operational when executed by the processor to direct the processor to process the user logon to determine if the user is allowed access to the access system based on a user access profile.

21. The software product of claim 19 wherein the database software is operational when executed by the processor to direct the processor to determine if the second database system exists.

22. The software product of claim 19 wherein the logon reply includes an access card account code.

23. The software product of claim 19 wherein the logon reply includes foreign network account information and the database software is operational when executed by the processor to direct the processor to identify the second external database based on the foreign network account information.

24. The software product of claim 19 wherein the database software is operational when executed by the processor to direct the processor to log contract and settlement information.

Description

FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable

MICROFICHE APPENDIX

Not applicable

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention is related to the field of communication networks, and in particular, to an access communication system that provides access to multiple service provider systems. More particularly, this invention relates to a system that authorizes access to use the access communication system.

2. Description of the Prior Art

Communication networks have seen dramatic development over the past several years so that today, there are multiple diverse communication networks providing services. The current technical challenge is to develop interfaces between the networks to provide seamless service across multiple networks. Unfortunately, today's interfaces lack the ability to offer the user with easy access to services from multiple systems. These interfaces do not customize operations for the user.

FIG. 1 illustrates the conventional public telephone network. User telephones and computers are connected to local switches. The local switches are coupled to a local database. The user places calls through the local switch. The local switch processes the called number to provide an end-point connection or access to other networks. The local switch may connect the call to another telephone in the local calling area. In a Local Number Portability (LNP) situation, the local switch exchanges information with the local database to obtain the appropriate routing number for a ported call. The local switch may also connect the call to an Internet Service Provider. If a Digital Subscriber Line (DSL) is used, DSL equipment may be used to bypass the local switch. The local switch may also connect the call to a long distance switch. To provide access to the long distance switch, the local switch first exchanges information with the local database. The local database identifies the long distance network for either the user or the dialed number.

The long distance switch processes the called number to route the call to another system or network. Prior to routing, the long distance switch validates the call by checking the caller's number. The long distance switch may also exchange information with the long distance database to provide special call-handling. One example is a calling card call, where the long distance database validates an account number for billing the call. Another example is a toll-free call, where the long distance database processes external information customized by the called party to route the call. Toll-free routing information includes items such as time and date, caller location, and call center status. Many long distance calls are simply routed through the long distance network to another local network for call completion. Other calls are routed from the long distance network to a call center. Call centers offer a concentration of call-handling capabilities for operations, such as order entry, customer service, and promotions. Call centers include automatic call distribution equipment to route calls to the appropriate destination within the call center.

Both local and long distance networks exchange calls with mobile switches. The mobile switches are connected to base stations that communicate over the air with wireless telephones. When a mobile user places a call, the mobile switches exchanges information with a mobile database to validate the mobile caller. The call is then routed to another mobile caller, the telephone network, or to an ISP. When a mobile caller moves around, their wireless phone logs-in with the physically proximate mobile network, and that mobile network updates the mobile user's location in the mobile databases. When a call is placed to that mobile user, their home mobile switch obtains a routing number from the mobile databases to route the call to the mobile network currently in communication with the mobile user.

FIG. 2 illustrates a conventional data network that transfers packets of user data to a destination based on address information carried in the packets. Users are connected to Local Area Networks (LANs) that are connected to Wide Area Networks (WANs). A common LAN is an Ethernet system. A common WAN is an intranet. WANs are inter-connected by data networks, such as IP, TI, frame relay, or Asynchronous Transfer Mode (ATM). WANs are connected to the Internet through ISPs. WANs are connected to the public telephone network through telephony gateways. A common telephony gateway is a Private Branch Exchange (PBX).

FIG. 3 illustrates a conventional ISP. The public telephone network is coupled to a telephony interface that converts between telephony analog and digital protocols and the Internet Protocol (IP). Some telephony interfaces also handle DSL traffic that may already use IP. The telephony interface transfers IP traffic through an access server and firewall to a router. Some ISPs combine the firewall and the access server into one system. Also, the position of the firewall may vary, and traffic shapers may be present. The router exchanges IP traffic with the Internet.

In operation, the user calls the ISP over the telephone network and logs-in at the access server. The access server collects and forwards the user name and password to the ISP database. The ISP database validates the user name and password and returns an IP address to the access server. The IP address is for the user's terminal connection. Using the IP address, the user may communicate through the firewall to the router for transmissions to an IP address. The user now has Internet access through the router and exchanges packets with various Internet servers.

IP addresses are referred to as network addresses and include a network ID and a host ID. Network IDs are unique across the Internet and host IDs are unique within a given network. IP addresses are lengthy numerical codes, so to simplify things for the user, service addresses are available that are easier to remember. The service addresses are often the name of the business followed by ".com". Domain Name Service (DNS) is hosted by servers on the Internet and translate between service addresses and network addresses. The browser in the user computer accesses the DNS to obtain the desired network address.

FIG. 4 illusrates conventional network access. A current proposal for communication network access is provided by the Telecommunication Information Network Architecture Consortium (TINA-C). TINA-C proposes the use of agents in the user domain and the service provider domain. The service provider domain could be a telephone network, data network, or ISP. The agents negotiate access service rights. Once the service is negotiated, the user receives the service from the service provider network during a service session. Unfortunately, the access session occurs between the user domain and a particular service provider domain. At present, the service provider domain provides limited access capability beyond simply handing off communications to another network based on a called number or network address. As a result, the ability to customize services for a particular user across multiple service providers is inadequate.

SUMMARY OF THE INVENTION

The inventions solve the above problems by providing access between a user system and a plurality of communication networks. The plurality of communication networks provide services to a user in the user system. An access communication system includes a database system and an access server that is connected to the user system and the plurality of communication networks.

In one aspect of the inventions for user access profile inheritance, the database system receives an update request from the access server to update a user access profile through inheritance. The database system then processes the update request to inherit user profile information from a user profile data structure. The database system updates the user access profile with the user profile information.

In another aspect of the inventions for network shells, the access server receives an alias selection from a user for a network shell that includes alias selections associated with actions. The access server then processes the alias selection to execute an action associated with the alias selection.

In another aspect of the inventions for service based directory, the access server transmits a list of services to a user system. The access server then receives a selection from the list of services. The access server processes the selection to generate an instruction to provide the service related to the selection.

In another aspect of the inventions for user access profile mobility, the database system receives user information. The database system then processes the user information to determine if a user access profile is local within a local database system. The database system generates and transmits a request to retrieve a user access profile from a second database system external to the local database system in response to the determination that the user access profile is not local.

In another aspect of the inventions for service, user, and device sessions, the access communication system establishes a connection between a network device and the access server. The access communication system then generates a device session including a device session ID based on the network device. The access communication system generates and transmits a logon query for the network device. The access communication system receives and processes a logon reply from the network device to generate a user session including a user session ID based on the user. The access communication system receives and processes a request for the service to generate a service session including a service session ID based on the service. The service may generate and transmit a logon query for the user. The access communication system links the device session, user session, and the service session using the device session ID, the user session ID, and the service session ID.

In another aspect of the inventions for service capability firewall, the access server receives information including a named function request for a service provider. The access server processes the information to check if the named function request is valid for the service provider and the service. If valid, the access server determines if a private destination address exists for the named function request. The access server replaces the named function request with the private destination address in response to the determination that the private destination address exists for the named function request. The access server then transmits the information with the private destination address to the service provider.

In another aspect of the inventions for prepaid access and bank card access, the database system receives information identifying a billing code for a user. The database system then processes the billing code to determine if the user is allowed to use the access system. The database system provides access to the access system in response to the determination that the user is allowed to use the access system.

In another aspect of the inventions for global authentication and access card, the database system receives a user logon. The database system then processes the user logon to determine if the user is allowed access to the access communication system based on a local database system. The database system then provides access to the access communication system to the user in response to the determination that the user is allowed access based on the local database system. The database system then generates an authorization query for a second database system external to the local database system in response to the determination that the user is not allowed access based on the local database system. The database system receives and processes an authorization response indicating whether the user is allowed to use the access system from the second database system. The database system then provides access to the access communication system to the user in response to the authorization response that allows the user to use the access communication system.

In another aspect of the inventions for user based proxy and subscriber based proxy, the database system includes a user proxy. The user proxy receives a request for the service from the user system. The user proxy then transmits the request for the service to a service provider. The user proxy exchanges user information between the user system and the service provider.

In another aspect of the inventions for dynamic proxy, the database system includes a proxy. The proxy receives a service/protocol request for a new service or protocol. The proxy processes the service/protocol request to generate a handler request to obtain a handler for the new service or protocol. The proxy then receives and executes the handler for the new service or protocol.

In another aspect of the inventions for access execution environment, the database system receives and processes a logon reply into an access execution environment for a user. The database system retrieves programs for the user into the access execution environment. The database system executes the programs for the user in the access execution environment.

In another aspect of the inventions for domain name scoping and inband domain name service lookup, the access server receives information including an alias from the user system. The access server determines if the alias exists in a cache including aliases and alias translations for the user. The access server changes the information based on the cached alias translation.

In another aspect of the inventions for inline access service triggering, the access server receives information. The access server then processes the information to determine if the information is allowed to pass. The access server changes access logic based on the information in response to the determination that the information is not allowed to pass. The access server changes the filters of the access server based on the information in response to the determination that the information is not allowed to pass.

In another aspect of the inventions for access service triggering, the access server receives information. The access server processes the information to determine if the information is allowed to pass. The access server then generates a request from a database system in response to the determination that the information is not allowed to pass. The access server receives a reply including access logic from the database system. The access server changes filters of the access server based on the access logic.

In another aspect of the inventions for personal URL, the database system receives information including a user alias. The database system processes the information to determine if a user alias translation including a current network address for the user alias exists. The database system then modifies the information with the current network address using the user alias translation.

In another aspect of the inventions for predictive caching, the access server receives a request for data. The access server then determines if the data exists in a user cache wherein the user cache contains cached data based on the user's predictive patterns. The access server retrieves the data from the user cache in response to the determination that the data exists in the user cache. The access server transmits the request for data for the service provider in response to the determination that the data does not exist in the user cache.

In another aspect of the inventions for user controlled caching, the access server receives a request for data. The access server determines if the data exists in a user cache wherein the user cache contains cached data based on a user's script of commands. The access server retrieves the data from the user cache in response to the determination that the data exists in the user cache. The access server then transmits the request for data for the service provider in response to the determination that the data does not exist in the user cache.

In another aspect of the inventions for service usage audit, the access server receives an audit message into a database system. The access server processes the audit message to store the audit message in the database system.

In another aspect of the inventions for switching access by a user, switching access by a service provider, and dynamic access control, the database system receives a request. The database system processes the request to determine if the switching of the access is allowed. The database system then generates an instruction to switch access in response to the determination that the switching is allowed.

In another aspect of the inventions for network failover, network busy forwarding, time-out, busy flag, forwarding, and network endpoint availability management, the access server receives information for a destination network device. The access server determines if the destination network device is available. The access server performs an action in response to the determination that the destination network device is unavailable.

In another aspect of the inventions for scheduled alias translation, the access server receives information including an alias. The access server processes the information to determine whether an alias translation exists based on an alias translation schedule. The access server then modifies the information based on the alias translation in response to the determination the alias translation exists.

In another aspect of the inventions for service capability monitor, the database system receives information from an access server during a service session. The database system determines a current state of the service session based on the information. The database system determines a state transition based on the current state and a map of state transitions of the service. The database system determines whether the state transition is valid for the service session.

BRIEF DESCRIPTION OF THE DRAWINGS

The same reference number represents the same element on all drawings.

FIG. 1 illustrates a public telephone network in the prior art.

FIG. 2 illustrates a data network in the prior art.

FIG. 3 illustrates an Internet Service Provider in the prior art.

FIG. 4 illustrates conventional network access.

FIG. 5 illustrates a network architecture in an example of the invention.

FIG. 6 illustrates an access network in an example of the invention.

FIG. 7 illustrates a table for a user access profile in an example of the invention.

FIG. 8 illustrates a flowchart for an access server for inheriting a user access profile in an example of the invention.

FIG. 9 illustrates a flowchart for a database system for inheriting a user access profile in an example of the invention.

FIG. 10 illustrates a flowchart of an access server for executing a network shell in an example of the invention.

FIG. 11 illustrates a flowchart of a database system for updating a network shell in an example of the invention.

FIG. 12 illustrates a flowchart for the services based directory in an example of the invention.

FIG. 13 illustrates a flowchart of user access profile mobility in an example of the invention.

FIG. 14 illustrates a logical view of device, user, and service sessions in an example of the invention.

FIG. 15 illustrates a flowchart for a user based session in an example of the invention.

FIG. 16 illustrates a flowchart for a service based session in an example of the invention.

FIG. 17 illustrates a flowchart for a firewall/router for service capability firewall in an example of the invention.

FIG. 18 illustrates a flowchart for a database system for service capability firewall in an example of the invention.

FIG. 19 illustrates a flowchart for prepaid access in an example of the invention.

FIG. 20 illustrates a flowchart for bank card access for a connection in an example of the invention.

FIG. 21 illustrates a flowchart for network access cards for a disconnection in an example of the invention.

FIG. 22 illustrates a flowchart for network access cards for a connection in an example of the invention.

FIG. 23 illustrates a flow chart for network access cards for a disconnection in an example of the invention.

FIG. 24 illustrates a flowchart for global access in an example of the invention.

FIG. 25 illustrates a flowchart for an access server for user based proxies in an example of the invention.

FIG. 26 illustrates a flowchart for a user proxy for user based proxies in an example of the invention.

FIG. 27 illustrates a flowchart for an access server for subscriber based proxies in an example of the invention.

FIG. 28 illustrates a flowchart for a subscriber proxy for subscriber based proxies in an example of the invention.

FIG. 29 illustrates a flowchart for a dynamic proxy for dynamic proxies in an example of the invention.

FIG. 30 illustrates a block diagram of the access execution environment in an example of the invention.

FIG. 31 illustrates a flow chart for the access execution environment in an example of the invention.

FIG. 32 illustrates a flowchart for an access server for domain name scoping in an example of the invention.

FIG. 33 illustrates a flowchart for a database system for domain name scoping in an example of the invention.

FIG. 34 illustrates a flowchart for an access server for an inband domain name service lookup in an example of the invention.

FIG. 35 illustrates a flowchart for inline access service triggering in an example of the invention.

FIG. 36 illustrates a flowchart for an access server for access service triggering in an example of the invention.

FIG. 37 illustrates a flowchart for a database system for access service triggering in an example of the invention.

FIG. 38 illustrates a flow chart for the personal URL lookup in an example of the invention.

FIG. 39 illustrates a flow chart for the personal URL update in an example of the invention.

FIG. 40 illustrates a flowchart for an access server for auditing in an example of the invention.

FIG. 41 illustrates a flowchart for a database system for auditing in user predictive caching in an example of the invention.

FIG. 42 illustrates a flowchart for a database system for caching in user predictive caching in an example of the invention.

FIG. 43 illustrates a flowchart for a database system for auditing in user controlled caching in an example of the invention.

FIG. 44 illustrates a flowchart for a database system for caching in user controlled caching in an example of the invention.

FIG. 45 illustrates a flowchart for switching access by a user in an example of the invention.

FIG. 46 illustrates a flowchart for switching access by a service provider in an example of the invention.

FIG. 47 illustrates a flowchart for dynamic switching access in an example of the invention.

FIG. 48 illustrates a flowchart for an access server for network address failover in an example of the invention.

FIG. 49 illustrates a flowchart for a database system for network address failover in an example of the invention.

FIG. 50 illustrates a flowchart for an access server for network busy forwarding in an example of the invention.

FIG. 51 illustrates a flowchart for a database system for network busy forwarding in an example of the invention.

FIG. 52 illustrates a flowchart for an access server for a busy flag when the destination network device is busy in an example of the invention.

FIG. 53 illustrates a flowchart for an access server for forwarding if the destination network device timeouts in an example of the invention.

FIG. 54 illustrates a flowchart for an access server for schedule alias resolution in an example of the invention.

FIG. 55 illustrates a flowchart for a database system for scheduled alias resolution in an example of the invention.

FIG. 56 illustrates a flowchart for an access server for destination controlled forwarding in an example of the invention.

FIG. 57 illustrates a flowchart for a database system for destination controlled forwarding in an example of the invention.

FIG. 58 illustrates a flowchart for an access server for network endpoint availability management in an example of the invention.

FIG. 59 illustrates a flowchart for a database system for network endpoint availability management in an example of the invention.

FIG. 60 illustrates a flowchart for a firewall/router for service capability monitor in an example of the invention.

FIG. 61 illustrates a service capability monitor software architecture for a service capability monitor in an example of the invention.

FIG. 62 illustrates a flowchart for the network logic for service capability monitor in an example of the invention.

FIG. 63 illustrates a flowchart for the service logic for service capability monitor in an example of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Communication Network Architecture--FIGS. 5 and 6

The following description and associated figures discuss specific examples intended to teach the present invention to those skilled in the art. Those skilled in the art will appreciate numerous variations from these examples that do not depart from the scope of the invention. Those skilled in the art will also appreciate that various features described below could be combined in various ways to form multiple variations of the invention.

FIG. 5 illustrates a network architecture 500 in an example of the invention. The network architecture 500 comprises a service network 530, a service network 540, and an access network 520. The access network 520 comprises a database system 522, an access server 524, a firewall/router 526, a firewall/router 556, and an access server 554. A user network 510 includes a network device 512. The user network 510 is connected to the access server 524. The access server 524 is connected to the firewall/router 526 and the database system 522. The firewall/router 526 is connected to the service network 530, the service network 540, and the database system 522. The firewall/router 556 is connected to the service network 530, the service network 540, the database system 522, and the access server 554. The access server 554 is connected to the database system 522 and the user network 560. The user network 560 comprises a network device 562 and a network device 564.

The access network 520 provides an interface between the user network 510 and 560 and the service networks 530 and 540. The interface function provides user access profiles, security, switching, and caching. The user network 510 and 560 could be a residential or business communication system that includes network devices. A network device 512, 562, and 564 could be any device configured to exchange data or information with the access network 520. Some examples of network devices are wireless and wireline telephones, computers, modems, servers, and/or data terminals, along with associated interconnections and network interfaces. For illustrative purposes in the examples below, a user interacts with the network device 512 to access services provided by the network architecture 500 and the user network 560. The user network 510 could also be a communication destination for other users. In these cases, the access network 520 provides destination performance monitoring and control. The example of a user interacting with the network device 562 and 564 to access services provided by the network architecture 500 and the user network 510 is not discussed below for the sake of clarity.

The access server 524 and the database system 522 could be adapted from components used in current ISPs, and the access network 520 could be integrated into these ISP components. The database system 522 houses user access profiles for the users in the user networks 510 and 560 with external access rights. The user access profiles provide a data clearinghouse for user-related information for security, service options, current state, and customized macros. The service networks 530 and 540 could be voice or data systems, such as the public telephone network, Internet, public data networks, and private data networks.

When a user requests access to services, the access network 520 processes the user access profile for the user. The access network 520 performs security measures to validate the user. The access network 520 then binds the user to a terminal and to a service. This user-terminal-service binding correlates the user's capabilities in the user access profile with the capabilities of the user's current terminal and the current capabilities of the service provider. The access network 520 activates a network shell for the user and the user's terminal. The network shell is an interface that is customized for the user and the terminal. The user invokes services using the network shell.

The user access profile may contain several macros that can be as simple as address translations or as complex as lengthy computer programs. The user's network shell provides access to the user's macros. The user access profile also stores caching instructions. The caching instructions control the collection and storage of information within the access network 520 for immediate access by the user.

FIG. 6 depicts an access network in an example of the invention. The access network 520 comprises the database system 522, the access server 524, the firewall/router 526, the firewall/router 556, and the access server 554. The database system 522 comprises a local database system 570, a Lightweight Directory Access Protocol (LDAP) interface system 571, a central database system 580, a local database system 590, and an LDAP interface system 591. The local database system comprises a user profile system 572, an audit database system 573, a cache database system 574, a host system 575, a security server 576, a user authorization system 577, an alias translation system 578, and a personal DNS system 579. The central database system 580 comprises a user authorization system 581, a financial interface 582, and a cross connect system 583. The local database system 590 comprises a user profile system 592, a user authorization system 593, and an availability system 594.

The access server 524 and the firewall/router 526 are connected to the local database system 570. The local database system 570 is connected to the central database system 580 and the LDAP interface system 571. The central database system 580 is connected to the local database system 590. The local database system 590 is connected to the firewall/router 556, the access server 554, and the LDAP interface system 591.

An access provider is an entity that provides access to users who use communications services. A typical access provider comprises an access server, a firewall/router, and a local database system. The systems within the local database system 570 could be included within the local database system 590. Also, the systems within the local database system 590 could be included within the local database system 570. As discussed above, the user is accessing the network architecture through the user network 510. The duplication of systems in the local database system 570 and the local database system 590 is excluded for the purposes of clarity. A service provider is an entity that provides communication services to users who are accessing the service through an access provider.

Network User Access Profile--FIGS. 5, 6, 7, 8, 9, 10, 11, and 12

User Access Profile Inheritance

The user access profile is stored in the access network 520 and controls user access to services. The user access profile is any information or data associated with controlling user access to a service such as role identification, authorization, billing information and access preferences.

FIG. 7 depicts table for a user access profile in an example of the invention. A user access profile includes access information for the user, billing information, and preferences for access. Access information is any information or data related to providing the user access to the network architecture 500. Some examples of access information are user ID, password, name, account number, user alias, current network address, switching allowed flag, and other security information. Access information also include a list of services that the user has subscribed to or is allowed access to. In one embodiment, access information includes a cache of information that the user has accessed previously. Some examples of billing information are address and billing code including bank card numbers or prepaid account codes. Preferences for access allow the user to save choices or preferences to customize their access to the network architecture 400. Some examples of preferences for access are file formats and Quality of Service values. The user access profile may also include usage information such as time of day access, day of week, usages per day, usages per week, and usages per month.

Users typically set up their user access profiles when signing up for the access to the network architecture 500. In one embodiment, users create the user access profile through an inheritance process. Through the inheritance process, the user selects user profile information from other user access profiles in the network architecture 500. The user may inherit user profile information from user profile data structures such as templates, other user access profiles, the user's group or class, or other networks that the user is set up in. A user profile data structure is any user profile information to be retrieved when inheriting a user access profile.

In a prior solution, a command interpreter in a single computer operating system shell environment allows a user to customize the interpretation of command strings. The user may inherit portions of other user's shell environment by adding the other user's shell attributes. User access profiles are typically stored in the access provider's database. FIGS. 5 and FIG. 8 disclose one embodiment for inheriting user access profiles in an example of the invention. The user access profile is created through an inheritance process where the user is able to select capabilities, macros, functions, methods, and data to inherit from other profiles. In this embodiment, users inherit user access profiles from classes, groups, or provider recommendations. Features of user access profiles such as alias translation could then be implemented with new users rapidly. The inheritance of user access profiles also simplifies the configuration of users. In one example, a user initiates the user access profile inheritance by clicking a button on a website. Also, when a user requests a new service, the service provider automatically inherits the user access profile for the user so the user is able to use the requested service.

FIG. 8 depicts a flowchart for the access server 524 for inheriting a user access profile in an example of the invention. FIG. 8 begins in step 800. In step 802, the access server 524 waits for the next packet. The access server 524 then receives and processes the packet from the network device 562 in step 804. The access server 524 then checks if the destination is the user access profile in step 806. If the destination is not the user access profile, the access server 524 transmits the packet on the correct path in step 808 before returning to step 802. If the destination is the user access profile, the access server 524 then checks if the network device 562 is allowed access to the user access profile in step 1110. If the network device 512 is not allowed access to the user access profile, the access server 524 discards the packet and registers a network request security event in step 812 before returning to step 802.

If the network device 512 is allowed access to the user access profile, the access server 524 then checks if the user is allowed to update their user access profile in step 814. If the user is not allowed updates to their user access profile, the access server 524 generates and transmits a profile update not allowed message to the network device 512 in step 816 before returning to step 802. If the user is allowed updates to their user access profile, the access server 524 generates and transmits a user access profile update permission message asking if the user wishes to update the user access profile to the network device 512 in step 818. The access server 524 then checks if the user approved the user access profile update in step 820. If the user does not approve, the access server 524 generates and transmits a user access profile aborted message to the network device 512 in step 822 before returning to step 802

If the user approves the user access profile update, the access server 524 sets an external request timer in step 824. The access server 524 then generates and transmits a user access profile update request to the database system 522 in step 826. A user access profile update request could be any signaling, message, or indication to update the user access profile. The access server 524 then checks if a reply was received or the external request timer expired in step 828. If the reply was not received and the external request timer did not expire, the access server 524 returns to step 828. If the reply was received or the external request timer did expire, the access server 524 checks if the reply was valid in step 830. If the reply was valid, the access server 524 generates an update complete message in step 832 before returning to step 802. If the reply was not valid, the access server 524 discards the packet and replies to the network device 512 that the user access profile update failed in step 834 before returning to step 802.

FIG. 9 depicts a flow chart for the database system 522 for inheriting a user access profile in an example of the invention. FIG. 9 begins in step 900. In step 902, the database system 522 waits for a request. The database system 522 then receives and processes the request from the access server 524 in step 904. In step 906, the database system 522 then checks if the access server requester is known. If the access server requester is not known, the database system 522 then registers an unknown requester event in step 912. The database system 522 appends the reply to the packet and transmits the reply to the access server 524 in step 910. The database system replies with a decline message to the access server 524 in step 912 before returning to step 902.

If the requester is known, the database system 522 then checks whether the request is a user access profile update request in step 914. If the request is not a user access profile update request, the database system 522 checks if the request is a security event in step 916. If the request is not a security event, the database system 522 then registers an unknown action event in step 918 before returning to step 910. If the request is a security event, the database system 522 increments a path/device security record in step 924. The database system then logs the path/device security record in step 926 before returning to step 902.

If the request is a user access profile update request, the database system 522 identifies and authenticates the user and the network device 512 in step 920. The database system 522 then checks if the access is valid in step 922. If the access is invalid, the database system 522 returns to step 924. If the access is valid, the database system 522 retrieves the user access profile information from a user profile data structure in step 928. The retrieval of user access profile information may be based on any information in the user access profile such as group or class or selections of inheritance user access profile presented to the user. The group or classes could be any logical grouping of user based on similar interests or situations such as work, family, and geographic location. The database system 522 then updates the user access profile in step 930 based on the user access profile information retrieved in step 928 and the user's selections for updating. The database system 522 then replies with an approve message to the access server 524 in step 932 before returning to step 902. In one embodiment of the invention, the database system 522 uses the user access profile system 572 to perform the operations disclosed in FIG. 9 and stores the user access profile in the user access profile system 572.

Network Shell

The user access profile includes data to provide a customized network shell to the user. The network shell is a user interface to the access network that is linked to programs, methods, macros, or service. Typically, configuration of the network shell is graphically presented to the user on a display. For example, the network shell appears as a list of alias selections that are associated with actions such as a program or macro for resources or services. An alias selection is any information that is associated with an action to be executed when the alias selection is selected. In another example, the alias selections are graphically presented as icons that relate to actions to be executed. The network shell overlays the standard DNS offered in IP networks, which reduces alias translation delays and required user keystrokes. In prior solutions, a command interpreter in an operating system shell environment allows a user to customize the interpretation of command strings, or a DNS translates "alias" values to addresses. FIGS. 5, 10, and 11 show one embodiment for network shells in an example of the invention.

FIG. 10 depicts a flowchart of an access server for executing a network shell in an example of the invention. FIG. 10 begins in step 1000. In step 1002, the access server 524 waits for the next packet. The user selects an alias selection from the network shell graphically presented. In another embodiment, the user enters an alias value by a non-graphical means. Alternatively, the network shell is not presented to the user. The network device 512 transmits a packet including the alias selection to the access server 524. In step 1004, the access server 524 receives and processes the packet from the network device 512 and processes the packet. The access server 524 then checks if the network device 512 is allowed access to the network architecture 500. If the network device 512 is not allowed access to the network architecture 500, the access server 524 discards the packet and registers a network security event in step 1008 before returning to step 1002.

If the network device 512 is allowed access to the network architecture 500, the access server 524 checks if the user is recognized in step 1010. If the user is not recognized, the access server 524 returns to step 1008. If the user is recognized, the access server 524 retrieves the user's network shell in step 1012. In some embodiments, the user's network shell is retrieved from the user access profile in the access database 522 prior to presenting the network shell to the user. In step 1014, the access server 524 checks if the packet from the network device 512 includes an alias selection from the user's network shell. In one embodiment, specialized hardware is used to scan for aliases just as IP addresses are currently scanned for. If the packet does not include an alias selection from the user's network shell, the access server 524 proceeds to step 1018. If the packet does include the alias selection from the user's network shell, the access server 524 executes the action associated with the alias selection in step 1016 before returning to step 1002. In step 1018, the access server 524 processes the packet with the normal handling before returning to step 1002.

FIG. 11 depicts a flowchart of a database system for updating a network shell in an example of the invention. FIG. 11 begins in step 1120. In step 1122, the database system 522 waits for a request. The database system 522 then receives and processes the request from the access server 524 in step 1124. The database system 522 then checks if the access server requester is known in step 1126. If the access server requester is not known, the database system 522 registers an unknown requester event in step 1128. The database system 522 then appends the reply to the packet and transmits the packet to the access server 524 in step 1130. In step 1132, the database system 522 replies with a decline message to the access server 524 before returning to step 1122.

If the access server requester is known, the database system 522 checks if the request is a profile update for the network shell in step 1134. If the request is a profile update for the network shell, the database system 522 identifies and authenticates the user and the network device 512 in step 1136. The database system 522 then checks whether the access is valid in step 1138. If the access is invalid, the database system proceeds to step 1154. If the access is valid, the database system 522 retrieves the user access profile in step 1140. The database system 522 then updates the user access profile with the network shell with the user's alias selections and the associated programs, macros, functions or methods in step 1142. The database system 522 then replies with an approve message in step 1144 before returning to step 1122.

If the request is not a profile update, the database system 522 checks if the request is an action event in step 1146. If the request is an action event, the database system 522 performs the action and replies in step 1148 before returning to step 1122. If the request is not an action event, the database system 522 checks if the request is a security event in step 1150. If the request is not a security event, the database system 522 registers an unknown request type event in step 1152 before returning to step 1122. If the request is a security event, the database system 522 proceeds to step 1154. In step 1154, the database system increments a path/device security record. The database system 522 then appends the requester information to the packet and logs the event before returning to step 1122. In one embodiment of the invention, the database system 522 uses the user access profile system 572 to perform the operations disclosed in FIG. 11 and stores the user access profile in the user access profile system 572.

Service Based Directory

In prior systems, the RADIUS server provided the user with selections for transport modes. However, the user was not able to select available network based services. FIGS. 5 and 12 disclose one embodiment for a service based directory in an example of the invention. In this embodiment, access providers provide a list of services that the user can select. With the list of services, the access providers have the ability to advertise specific services to users. The list of services may be generated based on the user access profile to make the list user specific. Once the user makes the selection, the access server 524 connects the user to the service network such as Intranet, Internet, or private dedicated network that provides the selected service.

FIG. 12 depicts a flowchart for the services based directory in an example of the invention. FIG. 12 begins in step 1200. In step 1202, the access server 524 waits for the next connection from a network device in the user network 510. The access server 524 then receives a connection from the network device 512 in step 1204. Once the connection is established, the access server 524 generates and transmits a user ID query to the network device 512 in step 1206. The access server 524 then receives an ID reply and establishes a network device session in step 1208.

The access server 524 then generates an available services reply including a list of services in 1210. In one embodiment, the access server 524 generates the available services reply based upon information in the user access profile. The access server 524 receives a selected service reply from the network device 512 in step 1212. The access server 524 then connects the network device 512 to the selected service provider in step 1214. The access server 524 waits for the next packet in step 1214. The access server 524 then exchanges packets between the network device 524 and the selected service provider in step 1218.

Access Network User Binding--FIGS. 5, 13, 14, 15, and 16

User Access Profile Mobility

Users may access their user access profile from any network device connected to the network architecture 500. In a prior solution, a command interpreter in an operating system shell environment allows a user to customize the interpretation of command strings. In this environment, the access network identifies the user and the terminal device interface, which provides user mobility. The access network then executes customized actions for the user. FIGS. 5 and 13 show one embodiment of the invention for user access profile mobility. This embodiment provides user mobility in a distributed data network environment.

FIG. 13 depicts a flowchart of user access profile mobility in an example of the invention. FIG. 13 begins at step 1300. A user at the network device 512 signs on the access network 520 with their user ID. The network device 512 transmits user information with the user ID to the access server 524. In this embodiment, the user information is in the form of a packet. In step 1302, the access server 524 receives and processes the packet to check if the user access profile is local within the local database system 570. A user access profile is local within the local database system 570 when the user access profile is located in the local database system 570. If the user access profile is local, the access server 524 proceeds to step 1312.

If the user access profile is not local within the local database system 570, the access server 524 checks if the user ID is delimited with a provider ID in step 1304. One example of a user ID delimited with a provider ID includes a user's name and a provider ID separated by a delimiter such as joesmith@accessp.net. If the user ID is not delimited, the access server 524 retrieves the location of the default user access profile system using a default Lightweight Directory Access Protocol (LDAP) interface system 571 in step 1308 before proceeding to step 1312.

If the user ID is delimited, the access server 524 checks if the provider ID is valid in step 1306. If the provider ID is not valid, the access server 524 registers an invalid profile request security event before terminating at step 1326. If the provider ID is valid, the access server 524 uses the provider ID to retrieve the location of the local database system 590 from a foreign LDAP interface system 591 before proceeding to step 1312.

In step 1312, the access server 524 checks if the packet is a retrieve request for the user access profile. If the packet is a retrieve request, the access server 524 generates and transmits a request to retrieve the user access profile from the local database system 570 for local user access profiles or from the local database system 590 for foreign user access profiles. The access server 524 then creates the user session ID and updates the user entries of the user access profile with the user ID and date/time updated in step 1312. The access server 524 then transmits a reply message with the session ID and the location of the LDAP server in step 1314 before terminating at step 1326.

If the packet is not a retrieve request, the access server 524 checks if the packet is a release request in step 1316. If the packet is a release request, the access server 524 retrieves the user access profile from the local database system 570 for local user access profiles or from the local database system 590 for foreign user access profiles. The access server 524 then updates the user session ID and updates the user entries of the user access profile with the user ID and date/time updated in step 1318. The access server 524 then transmits a reply message with the session ID in step 1320 before terminating at step 1326.

If the packet is not a release request, the access server 524 checks if the packet is an update request in step 1322. If the packet is not an update request, the access server 524 registers an invalid profile request security event before terminating at step 1326. If the packet is an update request, the access server 524 retrieves the user access profile from the local database system 570 for local user access profiles or from the local database system 590 for foreign user access profiles. The access server 524 then updates the user access profile with the information in the packet in step 1324. The access server 524 then transmits a complete message to the user network 510 to signify the profile update is complete before terminating at step 1326. In one embodiment, the local database system 570 uses the user access profile system 572 to retrieve and store the local user access profiles and the local database system 590 uses the user access profile system 592 to retrieve and store the foreign user access profiles.

User, Device, and Service Sessions

Access network providers provide user and device sessions in addition to service sessions to distinguish users when providing communication services. A user session is the information associated with a user accessing a network. A device session is the information associated with a device being used to access a network. A service session is the information associated with a service being provided over a network. Service providers distinguish users instead of access devices or links. This allows multiple users to share a single access device with each user receiving their own customized or preferred services. Advantageously, service providers establish service access rights and restrictions such as preventing adult content for younger viewers or sharing an access device for business and personal use. Also, user, device, and service sessions allow a service provider to group multiple service providers to provide a composite of services to the user similar to a contractor/sub-contractor relationship.

FIGS. 5, 14, 15, and 16 disclose one embodiment for device, user, and service sessions in an example of the invention. FIG. 14 depicts a logical view of device, user, and service sessions in an example of the invention. Devices 1402, 1404, and 1406 are comprised of session type specific information and session links. Session type specific information include public keys, private keys, and session ID. Session links include user sessions, device sessions, and service sessions. The public keys and private keys are for encryption and decryption of messages. Session ID identifies the session ID for the device. User sessions are user sessions that the device is logically linked to. Service sessions are the service sessions the device is logically linked to. Users 1408, 1410, and 1412 are comprised of public keys, private keys, session ID, device sessions, and service sessions. Session ID identifies the session ID for the user. Device sessions are the device sessions the user is logically linked to. Service sessions are the service sessions the user is logically linked to. Services 1414, 1416, and 1418 are comprised of public keys, private keys, session ID, users sessions, device sessions, and sub service sessions. Session ID identifies the session ID for the service. User sessions are the user sessions the service is logically linked to. Device sessions are the device sessions the service is logically linked to. Sub service sessions are the service sessions the service is logically linked to.

In one example, device 1402 is linked to user B 1410 via a link 1422. User B is also linked to service N 1418 via a link 1424. Device 1402 contains the user information in the user session fields for user B 1410 and the service information in the service session fields for service N. User B 1410 contains the device information in the device session fields for device 1402 and the service information in the service session fields for service N 1418. Service N 1418 contains the device information in the device session fields for device 1402 and the user information in the user session fields for user B 1410. Service N 1418 is also linked to service A 1414 via a link 1426. Service N 1418 contains additional service information in the service session fields for service A 1414. Service A 1414 contains the composite service information in the service session fields for service N 1418. Service A 1414 also includes an owning service which is a reference to the service that owns service A.

FIG. 15 depicts a flowchart for a user based session in an example of the invention. FIG. 15 begins in step 1500. In step 1502, the network device 512 establishes a connection with the access server 524. The access server 524 generates and transmits a user ID query to the user network 510 in step 1504. In step 1506, the network device 512 receives the user ID query and transmits a user ID reply to the access server 524. The access server 524 receives and processes the user ID reply to generate a device session. The network device 512 then transmits a packet to the access server 524. The access server 524 then receives the packet in step 1508. In step 1510, the access server 524 processes the packet to check if the packet includes a user session ID.

If the packet does not include the user session ID, the access server 524 transmits a logon query encrypted by the network device's 512 public encryption key 1402 to the network device 512 in step 1512. The network device 512 decodes the logon query with its public encryption key and transmits a logon reply encrypted with its public encryption key in step 1516. The access server 524 then decodes the logon reply with the private encryption key and checks if the user ID is valid. If the user is valid, the access server 524 generates a user session and a session ID in step 1520. In some embodiments, the user session ID is the original IP address. The access server 524 then encrypts with the public encryption key and transmits a complete reply with the user session ID to the network device 512 in step 1522 before returning to step 1508.

If the packet does include the user session ID, the access server 524 checks if the user and user session ID are valid in step 1514. If the user or user session ID is not valid, the access server 524 discards the packet and registers a security event in step 1515 before returning to step 1508. If the user and user session ID are valid, the access server 524 generates a service request with the user session ID and the service session ID if available. The access server 524 encrypts the service request with the public encryption key where appropriate. The access server 524 transmits the packet including the service request in step 1518 before returning to step 1508.

FIG. 16 depicts a flowchart for a service based session in an example of the invention. FIG. 16 begins in step 1600. The network device 512 transmits a service request to the access server 524. The access server 524 then receives the service request in step 1602. In step 1604, the access server 524 checks if the service request includes a service session ID.

If the service request does not include the service session ID, the access server 524 transmits a service ID query encrypted with the public encryption key to the network device 512 in step 1606. The network device 512 decodes the service ID query with its private key and transmits a service reply encrypted with the service public encryption key to the access server 524 in step 1610. The access server 524 then decodes the service reply with the service private encryption key and checks if the user is valid. If the user is valid, the access server 524 generates a service session and a session ID in step 1614. The access server 554 then transmits a complete reply with the service session ID to the network device 512 in step 1616 before returning to step 1602.

If the packet does include the service session ID, the access server 524 checks if the user and service session ID are valid in step 1608. In one embodiment, the service session ID is the destination IP address. If the user or service session ID is not valid, the access server 524 discards the packet and registers a security event before returning to step 1602. If the user and service session ID is valid, the access server 524 updates the service request with the user session ID and the service session ID. The access server 524 encrypts the service request with the service public encryption key where appropriate. The access server 524 transmits the service request with the user session ID and the service session ID in step 1612 before returning to step 1602.

Access Network Security--FIGS. 5, 17, and 18

Service Capability Firewall

A network service provider interfaces with a network access provider at a transport functional level. The interface typically includes Internet protocol firewalls to provide security. Unfortunately, the interface between the network service provider and the network access provider is not able to hide the implementation details such as addressing schemes, transport details, and equipment specifics. The hiding of implementation details is preferred to prevent hackers from manipulating the implementation details. FIGS. 5, 17 and 18 depict one embodiment for a service capability firewall in an example of the invention. In this embodiment, the interface between the network service provider and the network access provider occurs at a named functional level instead of the transport addressing level. A named function request is any request for a capability of service provided by the network service provider. This allows the network service provider to hide the implementation details. The network service provider exposes only functional capabilities to the users depending on their security rights.

FIG. 17 depicts a flowchart for the firewall 556 for service capability firewall in an example of the invention. FIG. 17 begins in step 1700. In step 1702, the firewall 556 waits for information. In this embodiment, the information is in the form of a packet. The firewall 556 receives and processes a packet including a named function request from the network device 512 in step 1704. The firewall 556 then checks whether the firewall 556 is the destination for the named function request in step 1706. If the firewall 556 is not the destination, the firewall 556 registers a network request security event in step 1710. In step 1712, the firewall 556 encapsulates the packet with path information and transmits the packet to the database system 522 before returning to step 1702.

If the firewall 556 is the destination, the firewall 556 checks whether the sending address is consistent with the path in step 1714. If the sending address is not consistent with the path, the firewall 556 returns to step 1710. If the sending address is consistent with the path and does not belong to the accessing network, the firewall 556 checks if the sending address/session ID/named function combination is cached in step 1716. If the sending address/session ID/named function combination is cached, the firewall 556 replaces the packet's named function request with the private cached destination address in step 1718. The firewall 556 then checks if the private destination address is known and allowed to pass in step 1720. If the destination is known and allowed to pass, the firewall 556 transmits the packet on the correct path with standard firewall access in step 1722 before returning to step 3802. If the destination is not known or not allowed to pass, the firewall 556 returns to step 1710.

If the sending address/session ID/named function combination is not cached, the firewall 556 set an external request timer in step 1724. The firewall 556 then generates and transmits a request for the database system 522 in step 1726. The firewall 556 checks whether a reply is received or the timer has expired in step 1728. If the reply is not received and the timer has not expired, the firewall 556 returns to step 1728. In another embodiment, a blocked I/O is used instead of the wait loop in step 1728. If the reply is received or the timer has expired, the firewall 556 checks if there is a valid reply in step 1730. If the reply is invalid or no reply was received, the firewall 556 discards the packet and registers a translation failure event in step 1734 before returning to step 1702. If the reply is valid, the firewall 556 replaces the packet's named function request based on the reply and caches the address/session functions returned in step 1732 before returning to step 1720.

FIG. 18 depicts a flowchart for the database system 522 for service capability firewall in an example of the invention. FIG. 18 begins in step 1800. In step 1802, the database system 522 waits for the next request. The database system 522 then receives and processes the request in step 1804. In step 1806, the database system 522 then checks if the access server requester is known. If the access server requester is not known, the database system 522 registers an unknown requester event in step 1808. The database system 522 then appends the reply with the packet and replies to the access server 524 in step 1810. The database system 522 then generates and transmits a decline reply to the access server 524 in step 1812 before returning to step 1802.

If the requester is known, the database system 522 then checks if the request is a capability appeal in step 1814. A capability appeal is any message, signaling or instruction requesting a capability with a related network address in the service provider. If the request is not a capability appeal, the database system 522 then checks if the request is a security event in step 1816. If the request is not a security event, the database system 522 register an unknown request event in step 1817 before returning to step 1810. If the request is a security event, the database system 522 increments a path/device security record and appends the requester information to the request packet and logs the event in step 1822 before returning to step 1802. If the request is a capability appeal, the database system 522 then identifies the user and network device 512 in step 1818. The database system 522 then checks if the access is valid in step 1822. If the access is invalid, the database system 522 returns to step 1822. If the access is valid, the database system 522 retrieves the user and network device profiles in step 1824. The database system 522 then checks whether the capability is valid for the user and session state in step 1826. If the capability is invalid, the database system 522 returns to step 1822. If the capability is valid, the database system 522 generates a session ID, the network address of the capability requested, and functions available and appends the network address, which is only sent to the firewall/router 526 and not to the user, to the reply in step 1830. The database system 522 then transmits the approve reply to the access server 524 in step 1832 before returning to step 1802.

Access Network Service Authorization--FIGS. 5, 19, 20, 21, 22, 23, and 24

Prepaid Access

Prepaid phone cards are commonly used in PSTN, where the customer pays a prepaid amount that is debited against when the customer makes a call. In data networks, prepaid cards are not currently being used. FIGS. 5 and 19 disclose one embodiment for prepaid access in an example of the invention. In this embodiment, users buy prepaid cards from network providers. When the user requests access to one of many access providers throughout the country, the access provider verifies the prepaid account code before providing the access. A prepaid account code is any number that relates to a user's prepaid account. The prepaid account is debited against for the charges related to the access. Other charges related to the service provided may also be debited against the prepaid account. For example, a user may purchase an item from a website and have the charges debited against the prepaid account. Once the prepaid amount is reached, the access provider terminates the access to the user. In one embodiment, the network provider provides different levels of service such as gold, silver, and bronze. The gold service has guaranteed throughput but higher rates for access, while the bronze service has lower throughput and rates.

FIG. 19 depicts a flowchart for prepaid access in an example of the invention. FIG. 19 begins in step 1900. In step 1902, the access server 524 waits for a connection. The network device 512 connects to the access server 524 in step 1904. Once a connection is established, the database system 522 generates and transmits a logon query for the network device 512. The network device 512 transmits information identifying a billing code. A billing code is any number that identifies a user for billing. Two examples of billing codes are prepaid account codes and credit card numbers. In this embodiment, the information identifying a billing code is a response including a prepaid account code to the logon query. In other embodiments, the billing code is retrieved from the user access profile. The access server 524 then transfers the response from the network device 512 to the database system 522. The database system 522 receives and processes the response including the prepaid account code to determine if the user is known in the local database system 570 in step 1906. A user is known when the user is allowed to use the access network 520. In one embodiment, the user is known in the local database system 570 if there is time/amounts left in the user's prepaid account. In another embodiment, the database system 522 evaluates a positive balance file to determine the remaining time/amount in the user's prepaid account. If the user is known, the database system 522 logs the access information and authorizes to provide access to the user via the access server 524 in step 1908 before returning to step 1902.

If the user is not known, the database system 522 checks if there is an appeal server for user authentication in step 1910. In one embodiment, the access server 524 performs the appeal on a decline. If there is no appeal server, the database system 522 transmits an instruction to the access server 524 to refuse the user logon and to disconnect the network device 512 from the access server 524 in step 2412 before returning to step 2402. If there is an appeal server, the database system 522 generates an authorization query including the prepaid account code for the central database system 580 in step 1914. The database system 522 checks if the user is known in the central database system 580 in step 1914. In one embodiment, the user is known in the central database system 580 if there is time/amounts left in the user's prepaid account. If the user is known, the database system 522 proceeds to step 1908. If the user is not known, the database system 522 proceeds to step 1910.

In one embodiment, the database system 522 uses a user authorization system 575 for checking if the user is known in the local database system 570. The user authorization system 575 contains all the prepaid customers, prepaid customer information, prepaid account codes, and the amount/quantity remaining in the prepaid account to verify if access is allowed. In one embodiment, the database system 522 uses a user authorization system 581 as the appeal server for checking if the user is known in the local database system 580. The user authorization system 581 contains all the prepaid customers, prepaid customer information, and the amount/quantity remaining in the prepaid account.

Bank Card Access

In prior systems, access providers authenticated users using their own databases. FIGS. 5, 20 and 21 disclose one embodiment for bank card access in an example of the invention. In this embodiment, access providers authenticate users through bank card financial networks using the users' credit card numbers. Network providers use credit or debit card numbers as user ID and passwords for authentication and authorization purposes. Users use prepaid cards, phone cards, and credit cards in PSTN. However, no bank cards have been used for access to data networks other than for batch bill payment.

FIG. 20 depicts a flowchart for bank card access for a connection in an example of the invention. FIG. 20 begins in step 2000. In step 2002, the access server 524 waits for a connection. The network device 512 connects to the access server 524 in step 2004. Once a connection is established, the database system 522 generates and transmits a logon query for the network device 512. The network device 512 transmits information identifying a billing code. In this embodiment, the information identifying a billing code is a response including credit card numbers to the logon query. In other embodiments, the billing code is retrieved from the user access profile. The access server 524 then transfers the response from the network device 512 to the database system 522. The database system 522 receives and processes the response to see if the user is known in the local database system 570 in step.2006. If the user is known, the database system 522 logs the access information and authorizes to provide access to the user via the access server 524 in step 2008 before returning to step 2002.

If the user is not known, the database system 522 processes the response to check if the user is identified by credit card numbers in step 2010. If the user is not identified by the credit card numbers, the database system 522 transmits an instruction to the access server 524 to refuse the user logon and to disconnect the network device 512 from the access server 524 in step 2012 before returning to step 2002. If the user is identified by the credit card numbers, the database system 522 generates an authorization query as a pre-authorization hold or authorization/capture transaction for the central database system 580 in step 2014. In one embodiment, the central database system 580 uses a financial interface 582 to interface with a financial switch to banks for authentication and authorization. The database system 522 then checks if the user is authenticated and authorized by the central database system 580 in step 2016. If the user is authenticated and authorized, the database system 522 logs access information and an authorizing financial entity or institution in step 2018 before proceeding to step 2008. If the user is not known, the database system 522 checks if there is another database system for authorization such as for foreign user access in step 2018. If there is another database system, the database system 522 returns to step 2014. If there is not another database system, the database system 522 returns to step 2012.

FIG. 21 depicts a flowchart for bank card access for a disconnection in an example of the invention. FIG. 21 begins in step 2100. In step 2102, the access server 524 waits for a disconnection. The network device 512 then disconnects from the access server 524 in step 2104. The access server 524 then checks whether the user was on a pre-authorization hold in step 2106. If the user is not on a pre-authorization hold, the 522 logs access information and an authorizing database system 522 in step 2108 before proceeding to step 2102. If the user is on a pre-authorization hold, the database system 522 generates a pre-authorization complete transaction for the central database system 580 in step 2110 before returning to step 2108.

Access Cards

In prior systems, access providers authenticated users using their own databases. FIG. 5, 22 and 23 disclose one embodiment for network access cards in an example of the invention. An access card is a card that a user uses to access a network. The access card includes an access card account code. The access card account code is any number that relates to the user's access account. In this embodiment, access providers authenticate users who have access cards using other access providers' databases. Access providers then may enter into sharing agreements with other access providers. These sharing agreements allow users to use multiple access providers, which provide the users greater mobility and availability. Users use phone cards in PSTN for phone card access. However, no access cards for data networks have been used.

FIG. 22 depicts a flowchart for network access cards for a connection in an example of the invention. FIG. 22 begins in step 2200. In step 2202, the access server 524 waits for a connection. The network device 512 connects to the access server 524 in step 2204. In another embodiment of the invention, the user calls a toll free number to request access. A service control point is queried to determine where to route the request for access similar to an automatic call distribution (ACD). The request for access is then routed to the access server 524 to establish a connection between the network device 512 and the access server 524.

Once a connection is established, the database system 522 generates and transmits a logon query for the network device 512. The network device 512 transmits a response including the access card account code to the logon query. The access server 524 then transfers the response from the network device 512 to the database system 522. In this embodiment, the database system 522 checks if the user is allowed to use the access network 520 by checking whether the user is known. A user is known when the user is allowed to use the access network 520. For example, a user is known when their user access profile is located within the local database system 570 and their user access profile allows the user to use the access network 520. The database system 522 receives and processes the response including the access card account code to check if the user is known in the local database system 570 in step 2206. If the user is known, the database system 522 logs the access information and authorizes to provide access to the user via the access server 524 in step 2208 before returning to step 2202.

If the user is not known, the database system 522 checks if the response included foreign network account information in step 2210. Foreign network account information is any information that is indicative of an account that is external to local database system 570 that the user is attempting to gain access. If there is no foreign network account information, the database system 522 transmits an instruction to the access server 524 to refuse the user logon and to disconnect the network device 512 from the access server 524 in step 2212 before returning to step 2202.

If there is foreign network account information, the database system 522 identifies the local database system 590 based on the foreign network account information and generates an authorization query for the local database system 590 in step 2214. The database system 522 then checks if the user is authenticated and authorized by the local database system 590 in step 2216. If the user is authenticated and authorized, the database system 522 logs contract and settlements information returned by the local database system 590 or indicated by the database system 522 in relation to local database system 590 in step 2218 before proceeding to step 2208. If the user is not known, the database system 522 proceeds to step 2212. In one embodiment, the local database system 570 uses the user authorization system 575 to check if the user is known in the local database system 570. In one embodiment, the local database system 590 uses the user authentication system 593 for authentication and authorization.

FIG. 23 depicts a flowchart for network access cards for a disconnection in an example of the invention. FIG. 23 begins in step 2300. In step 2302, the access server 524 waits for a disconnection. The network device 512 then disconnects from the access server 524 in step 2304. The access server 524 then generates and transmits a logoff query for the database system 522. The database system 522 then transfers the logoff query to the local database system 570 and the local database system 590. The database system 522 logs the access information and the authorizing database system in step 2308 before returning to step 2302.

Global Authentication

In prior systems, access providers authenticated users using their own databases. FIGS. 5 and 23 disclose one embodiment for global authentication in an example of the invention. In this embodiment, access providers authenticate users using a centralized database. Access providers then may enter into sharing agreements with other access providers. These sharing agreements allow users to use multiple access providers, which provide the users greater mobility. Currently, cellular telephone companies enter into these sharing arrangements for greater coverage. However, this sharing of databases for authentication and authorization has not occurred for data networks.

FIG. 24 depicts a flowchart for global access in an example of the invention. FIG. 24 begins in step 2400. In step 2402, the access server 524 waits for a connection. The network device 512 connects to the access server 524 in step 2404. Once a connection is established, the database system 522 generates and transmits a logon query for the network device 512. The network device 512 transmits a response to the logon query. The access server 524 then transfers the response from the network device 512 to the database system 522. The database system 522 receives and processes the response to see if the user is native in the local database system 570 in step 2406. In this embodiment, the database system 522 checks if the user is allowed to use the access network 520 by checking whether the user is native. A user is native when the user is allowed to use the access network 520. For example, a user is native when their user access profile is located within the local database system 570 and their user access profile allows the user to use the access network 520. If the user is native, the database system 522 logs the access information and authorizes to provide access to the user via the access server 524 in step 4308 before returning to step 2402.

If the user is not native, the database system 522 checks if there is an authentication/authorization server in the database system 522 for a foreign network for user authentication in step 1910. If there is no authentication/authorization server in the database system 522 for the foreign network, the database system 522 transmits an instruction to the access server 524 to refuse the user logon and to disconnect the network device 512 from the access server 524 in step 2412 before returning to step 2402. If there is an authentication/authorization server in the database system 522 for the foreign network, the database system 522 generates an authorization query for the central database system 580 in step 2414. The database system 522 then checks if the user is known in the central database system 580 in step 2414. If the user is known, the database system 522 proceeds to step 2408. If the user is not known, the database system 522 proceeds to step 2410. In one embodiment, the central database system 580 uses a user authorization system 581 to check if the user is known.

Access Network Proxy/Environment--FIGS. 5, 25, 26, 27, 28, 29, 30, and 31

User Based Proxy

A proxy is an application that represents itself as one or more network endpoints. The proxy receives a request for services from a user at a network endpoint and acts on behalf of the user in transmitting and receiving user requests and replies. There are Internet proxy agents that are user network access bind points. However, the Internet proxy agents are not user specific, and they act to protect user interests, not network. These proxy agents provide address translation and basic firewall functionality. Client focused proxies have extended to cookie collection and password handling.

FIGS. 5, 25 and 26 disclose one embodiment for user based proxies in an example of the invention. The user based proxies obtain information for the user and establishes a user specific network presence. A benefit of having a user specific network presence is that user access is handled by a process owned by a network security certificate authority that prevents Trojan horse network attacks. User based proxy provides a single control and monitor point for a user. The user proxy agents provides a bind point for all user specific access such as user profile functionality, translations, security, and caching.

FIG. 25 depicts a flowchart for the access server 524 for user based proxies in an example of the invention. FIG. 25 begins in step 2500. In step 2502, the access server 524 waits for the next event. If the next event is a connection, the network device 512 connects with the access server 524 in step 2504. In step 2506, the access server 524 then collects user information and transfers the user information to the database system 522 to perform the security. In one embodiment, the database system 522 uses a security server 576 to perform the security. The access server 524 then checks if the user is allowed access in step 2508. If the user is not allowed access, the access server 524 disconnects the user in step 2510 before returning to step 2502.

If the user is allowed access, the access server 524 checks if a proxy is available in the database system 522 in step 2512. In one embodiment of the invention, the user proxies are in the host system 575. If the proxy is available, the access server 524 proceeds to step 2516. If the proxy is not available, the access server 524 starts the proxy in the database system 522 in step 2514 before proceeding to step 2516.

The access server 524 checks if the user access profile information is available in step 2516. If the user access profile information is not available, the access server 524 generates and transmits a user profile error to the network device 512 in step 2518 before returning to step 2502. If the user profile information is available, the access server 524 configures the proxy for the user in step 2520. The access server 524 then generates and transmits a message with the address of the user proxy and the public encryption key to the network device 512 in step 2522. The access server 524 also collects and transmits the access address of the network device 512 and the public encryption key to the user proxy. The access server 524 then returns to step 2502.

If the next event is a disconnection, the network device 512 disconnects with the access server in step 2524. The access server 524 then generates and transmits a reset command to the user proxy to clear the proxy state information and configuration in step 2526 before returning to step 2502. If the next event is a status/request event from the user proxy, the access server 524 sets a user proxy reply timer in step 2528. The user proxy has written a status to the access server 524, and the user proxy receives a reply in step 2530 before returning to step 2502. If the next event is a timer expiration, the access server 524 receives the user proxy reply timer expiration in step 2532. The access server 524 then generates and transmits a continue wait message and status to the user proxy in step 2534 before returning to step 2528.

FIG. 26 depicts a flowchart for a user proxy for user based proxies in an example of the invention. FIG. 26 begins in step 2600. In step 2602, the user proxy waits for the next event. If the next event is the completion of the initialization, the user proxy checks if the initialization is complete in step 2604. The user proxy then sets a request timer in step 2606. The user proxy then request work from the access server 524 and transmits a status to the access server 524 in step 2608 before returning to step 2602. If the next event is the expiration of the request timer, the user proxy checks if the request timer expired in step 2610. The user proxy then registers a timeout in step 2612 before returning to step 2606.

If the next event is an access server 524 reply, the user proxy receives the access server 524 reply in step 2614. The user proxy then checks if the reply is a continue in step 2616. If the reply is a continue, the user proxy returns to step 2606. If the reply is not a continue, the user proxy processes the configuration information or action in step 2618 before returning to step 2606. If the next event is user request, the user proxy receives the user request for service in step 2620. The user proxy then checks if the user is valid in step 2622. If the user is valid, the user proxy then checks if the request is valid in step 2624. If the request is valid, the user proxy packages the request with the security certification and encryption in step 2626. The user proxy then transmits the request to the appropriate network destination in step 2628 before returning to step 2602. If the user or request is not valid, the user proxy registers a security event in step 2630 before returning to step 2602. The user proxy exchanges user information between the user network 510 and the appropriate network destination.

Subscriber Based Proxy

Another type of proxy is a subscriber based proxy. A subscriber is a logical entity such as an organization, corporation, or other grouping of users that has subscribed to services with a service provider. FIGS. 5, 27 and 28 disclose one embodiment for subscriber based proxies in an example of the invention. The subscriber based proxies obtain information for a user of a subscriber group and establishes a subscriber specific network presence. The benefit of having a subscriber specific network presence is that user access rights of the subscriber can be handled as a group, and group rights are owned by a network security certificate authority. The subscriber proxy agents provide a bind point for all subscriber specific access such as user profile functionality, translations, security, and caching.

FIG. 27 depicts a flowchart for the access server 524 for subscriber based proxies in an example of the invention. FIG. 27 begins in step 2700. In step 2702, the access server 524 waits for the next event. If the next event is a connection, the network device 512 connects with the access server 524 in step 2704. In step 2706, the access server 524 then collects user information and transfers the user information to the database system 522 to perform the security. In one embodiment, the database system 522 uses a security server 574 to perform the security. The access server 524 then checks if the user is allowed access in step 2708. If the user is not allowed access, the access server 524 disconnects the user in step 2710 before returning to step 2702. If the user is allowed access, the access server 524 checks if all required subscriber proxies are available in the database system 522 in step 2712. In one embodiment of the invention, the subscriber proxies are in the host system 575. If the proxies are available, the access server 524 proceeds to step 2716. If the proxies are not available, the access server 524 starts the required proxies in the database system 522 in step 2714 before proceeding to step 2716.

In step 2716, the access server 524 checks if the subscriber access profile information is available. If the subscriber access profile information is not available, the access server 524 generates and transmits a subscriber profile error to the network device 512 in step 2718 before returning to step 2702. If the subscriber profile information is available, the access server 524 configures the subscriber proxies for the subscriber in step 2720. The access server 524 then generates and transmits a message with the address of the subscriber proxy and the public encryption key to the network device 512 in step 6222. The access server 524 also collects and transmits the access address of the network device 512 and the public encryption key to the subscriber proxies. The access server 524 then returns to step 2702.

If the next event is a disconnection, the network device 512 disconnects with the access server in step 2724. The access server 524 then generates and transmits a reset command to the subscriber proxy in step 2726 before returning to step 2702. If the next event is a status/request event from the subscriber proxy, the access server 524 sets a subscriber proxy reply timer in step 2728. In step 2730, the subscriber proxy has written a status to the access server 524, and the subscriber proxy receives a reply before returning to step 2702. If the next event is a subscriber proxy timer expiration, the access server 524 receives the subscriber proxy reply timer expiration in step 2732. The access server 524 then generates and transmits a continue wait message and a status to the subscriber proxy in step 2734 before returning to step 2730.

FIG. 28 depicts a flowchart for a subscriber proxy for subscriber based proxies in an example of the invention. FIG. 28 begins in step 2800. In step 2802, the subscriber proxy waits for the next event. If the next event is the completion of the initialization, the subscriber proxy checks if the initialization is complete in step 2804. The subscriber proxy then sets a request timer in step 2806. The subscriber proxy then request work from the access server 524 and transmits a status to the access server 524 in step 2808 before returning to step 2802. If the next event is the expiration of the request timer, the subscriber proxy checks if the request timer expired in step 2810. The subscriber proxy then registers a timeout in step 2812 before returning to step 2806.

If the next event is an access server 524 reply, the subscriber proxy receives the access server 524 reply in step 2814. The subscriber proxy then checks if the reply is a continue in step 2816. If the reply is a continue, the subscriber proxy returns to step 2806. If the reply is not a continue, the subscriber proxy processes the configuration information or action in step 2818 before returning to step 2806. If the next event is a user request for service, the subscriber proxy receives the user request in step 2820. The subscriber proxy then checks if the user is valid in step 2822. If the user is valid, the subscriber proxy then checks if the request is valid in step 2824. If the request is valid, the subscriber proxy packages the request with the security certification and encryption in step 2826. The subscriber proxy then transmits the request to the appropriate network destination in step 2828 before returning to step 2802. If the user or request is not valid, the subscriber proxy registers a security event in step 2830 before returning to step 2802. The subscriber proxy exchanges user information between the user network 510 and the appropriate network destination.

Dynamic Proxies

One prior system named "pluxy" allows a manual extension of a proxy. Pluxy requires manual determination and loading of a dynamic set of services, which is done on an operator basis. FIGS. 5 and 29 disclose one embodiment for dynamic proxies in an example of the invention. In this embodiment, both the user based proxies and the subscriber based proxies are extended in response to user actions. The dynamic proxy can be modified and enhanced to evolve with new services and/or protocols. The dynamic proxy size is smaller and more efficient by supporting only the logic that is being used. Implementation and development times of new service and protocol are also reduced because new proxies are not required with the new service and/or protocol.

FIG. 29 depicts a flowchart for a dynamic proxy for dynamic proxies in an example of the invention. FIG. 29 begins in step 2900. In step 2902, the dynamic proxy waits for the next event. If the next event is the completion of the initialization, the dynamic proxy checks if the initialization is complete in step 2904. The dynamic proxy then sets a request timer in step 2906. The dynamic proxy then request work from the access server 524 in step 2908 before returning to step 2902. If the next event is the expiration of the request timer, the dynamic proxy checks if the request timer expired in step 2910. The dynamic proxy then registers a timeout in step 2912 before returning to step 2906.

If the next event is an access server 524 reply, the dynamic proxy receives the access server 524 reply in step 2914. The dynamic proxy then checks if the reply is a continue in step 2916. If the reply is a continue, the dynamic proxy returns to step 2906. If the reply is not a continue, the dynamic proxy processes the configuration information in step 2918 before returning to step 2902. If the next event is a user request, the dynamic proxy receives the user request in step 2920. The dynamic proxy then checks if the user and the request are valid in step 2922. If the user and the request are valid, the dynamic proxy checks if there is a new service or protocol requested in step 2924. If there is a new service or protocol, the dynamic proxy proceeds to step 2934. If there is not a new service or protocol, the dynamic proxy packages the request with the security certification and encryption in step 2926. The dynamic proxy then transmits the request to the appropriate network destination in step 2928 before returning to step 2902. If the user or request is not valid, the subscriber proxy registers a security event in step 2930 before returning to step 2902.

If the next event is a new service/protocol request, the dynamic proxy receives the new service/protocol request in step 2932. In step 2934, the dynamic proxy processes the new service/protocol request to generate a handler request for a new service/protocol handler in step 2934 before returning to step 2926. The dynamic proxy receives the handler and executes the handler for the new service or proxy. In one embodiment, the dynamic proxy is enhanced by loading applet-like extensions from a handler system similar to a web browser.

Access Execution Environment

Proxy servers in the Internet represents a user in one network as existing in another network to obtain services for the user. One problem with Internet proxy servers is the absence of the management of network resource utilization. In TINA-C, the User Agent and the User Session Manager are restricted to known service binding because any new service requires knowledge of or logic for a new CORBA interface. One problem with TINA-C is the absence of any provider resource management capabilities. Unfortunately, both Internet proxy servers and TINA-C do not provide any means of associating or viewing all network resources used by a user access session. Another problem is the lack of securing provider network resource against tampering by accessing users. Also, Internet proxy servers and TINA-C do not provide a platform-supported means of enforcing security levels on network access users. Both system also lack a validation of potential execution capability extensions.

FIGS. 5, 30, and 31 disclose one embodiment for an access execution environment in an example of the invention. The access execution environment easily and efficiently manages and secures network access by providing an execution environment in the access provider environment. Users access shared services and resources through their specific access execution environment. Because the access execution environment is in the access provider environment, the access provider can view the all of the user's activity by observing the execution environment. In this embodiment, the execution environment is setup as a standard system user on the network access platform, which allows management of the system user by operating system level user resource controls, quotas, and management mechanisms.

The access execution environment includes a multi-tasking virtual machine, a script interpreter, alias resolution capabilities, security certificate authentication, configuration handler, session caching, and protocol handling components. FIG. 30 depicts a block diagram of the access execution environment in an example of the invention. In FIG. 30, a network access platform 3000 comprises an execution environment manager 3010, a program and attribute database 3020, an execution environment A 3030, a transport A 3032, an execution environment B 3040, a transport B 3042, an execution environment C 3050, a transport C 3052, an execution environment D 3060, a transport D 3062, an execution environment E 3070, and a transport E 3072. In one embodiment, the network access platform 3000 is included within the database system 522. In another embodiment, the network access platform is included within the host system 575. The transport A 3032 is connected to the execution environment A 3030. The transport B 3042 is connected to the execution environment A 3040 and a workstation 3080. The transport C 3052 is connected to the execution environment C 3050. The transport D 3062 is connected to the execution environment D 3060. The transport E 3072 is connected to the execution environment E 3070. The execution environment A 3030 includes a transport handler 3034, a configuration handler 3036, and a security handler 3038. The execution environment B 3040 includes a transport handler 3044, a configuration handler 3046, and a security handler 3048. The execution environment C 3050 includes a transport handler 3054, a configuration handler 3056, and a security handler 3058. The execution environment D 3060 includes a transport handler 3064, a configuration handler 3066, and a security handler 3068. The execution environment E 3070 includes a transport handler 3074, a configuration handler 3076, and a security handler 3078.

In operation, a system administrator sets up a number of network access user accounts on the hardware platform. The administrator then sets up resource limits for each account/platform resource. The administrator then starts an execution environment 3030, 3040, 3050, 3060, and 3070 for each access user account ID. The execution environment A 3030 initializes and loads a configuration handler 3036. The execution environment A 3030 then loads the security handler 3038 and the transport handler 3034. The transport handler 3034 opens a logical or physical transport port A 3032 on the hardware platform using port information from the configuration handler.

FIG. 31 depicts a flow chart for the access execution environment in an example of the invention. FIG. 31 begins in step 3100. In step 3102, the security handler 3038 waits for a connect message from the transport handler 3034. The security handler 3038 then receives the connect message from the transport handler 3034 in step 3104. The security handler 3038 then generates and transmits a logon request via the transport handler 3034 in step 3106. The security handler 3038 then checks if a reply for the logon request from the transport handler 3034 has been received in step 3108. If the reply for the logon request has not been received, the security handler 3038 checks if a reply timeout has occurred in step 3110. If a reply timeout has not occurred, the security handler 3038 returns to step 3108. If a reply timeout has occurred, the security handler 3038 generates and transmits a disconnect message to the transport handler 3034 in step 3112 and returns to step 3102 to wait for a connect message.

In step 3114, the security handler 3038 receives the reply for the logon request. Then the security handler 3038 retrieves the location of a security server from the configuration handler 3036 and transmits the logon information to the security server in step 3116. The security handler 3038 then checks if a reply to the logon information from the security server has been received in step 3118. If no reply has been received, the security handler 3038 checks if a reply timeout has occurred in step 3120. If a reply timeout has not occurred, the security handler 3038 returns to step 3118. If a reply timeout has occurred, the security handler 3038 checks if the logon information has been sent three times in step 3122. The number of tries could be configurable. If the logon information has not been sent three times, the security handler 3038 returns to step 3116 to transmit the logon information. If the logon information has been sent three times, the security handler 3038 returns to step 3112 to send a disconnect message.

If the security server replied before the reply timeout, the security handler 3038 checks if the reply is an accept message in step 3124. If the reply is a decline message, the security handler 3038 returns to step 3112. If the reply is an accept message, the security handler 3038 transmits the accept message configuration parameters to the configuration handler 3036 in step 3126. The configuration handler 3036 then loads attributes and programs and executes programs specified by the security server reply in step 3128. The execution environment A 3030 performs the execution of programs for the user in step 3130. In another embodiment, the programs request attributes and/or programs to be loaded and/or executed. The programs include the ability to interface with users via the transport handler and load/execute other programs required by request types.

The configuration handler 3036 then checks if the transport handler 3034 receives a disconnect message in step 3132. If the transport handler 3034 has not received a disconnect message, the configuration handler 3036 returns to step 3130. If the transport handler 3034 has received a disconnect message, the transport handler 3034 transmits the disconnect message to the configuration handler 3036 in step 3134. In step 3136, the configuration handler 6536 based on port configuration attributes closes the transport port 3032, resets the transport handler 3034, and notifies the execution environment manager 3010 to create a new execution environment for that port. The configuration handler 3036 gracefully shuts down all handlers, programs, and eventually the execution environment A 3030. The configuration handler 3036 transmits a shutdown message to the execution environment manager 3010 in step 3138 before terminating in step 3140. The execution environment manager 3010 restarts the execution environment A 3030 upon notification of the shutdown. The operations of the other execution environments 3040, 3050, 3060, and 3070 perform in the same manner as the execution environment A 3030 and are not discussed for the sake of clarity.

Access Network Translations--FIGS. 5, 32, 33, 34, 35, 36, 37, 38, and 39

Domain Name Scoping

The typing in of domain names such as www.nypostonline.com is quite cumbersome for the user to access specific services. The Domain Name Server (DNS) translates the domain name to a network address for the service. Clicking on bookmarks or favorites in browsers, which reference the domain names, does eliminate the need to type in the domain names. However, when users change network devices, these bookmarks or favorites do not follow the user. In an operating system environment, the command interpreter shell allows the user to customize interpretation of command strings. If no customization is loaded, the command interpreters interprets in a default fashion.

FIGS. 5, 32, and 33 disclose one embodiment for domain name scoping in an example of the invention. This embodiment provides a customizable network shell to overlay the standard DNS service offered in Internet Protocol based networks. Users then are able to define user specific acronyms or aliases for specific or logical services. An acronym or alias indicates domain names, macros, programs, actions, or network addresses. If the translation for the alias does not exist in the list of aliases for the user, the access server 524 checks if the alias exists in the list for a group in which the user belongs. The access server 524 then checks if the alias exist in the DNS for the general network. In another embodiment, the database system 522 checks the existence of the alias in the list for the group and in the DNS for the general network. There are numerous variations in the hierarchy for searching for an alias but are not discussed for the sake of simplicity.

FIG. 32 depicts a flowchart for the access server 524 for domain name scoping in an example of the invention. FIG. 32 begins in step 3200. In step 3202, the access server 524 waits for a packet. In this embodiment, the access server 524 receives information in the form of packets from the network device 512. The access server 524 then receives and processes the packet from the network device 512 in step 3204. The access server 524 then checks if the packet is an alias translation request in step 3206. If the packet is not an alias translation request, the access server 524 transmits the packet with standard access logic in step 3214 before returning to step 3202.

If the packet is an alias translation request, the access server 524 then checks if the alias translation is cached for the user in step 3208. If the alias translation is cached, the access server 524 reformats the packet using the cached alias translation in step 3216 before returning to step 3214. If the alias translation is not cached, the access server 524 sets an external request timer in step 3210. The access server 524 then generates and transmits an alias translation request to the database system 522 in step 3212. The alias translation request is any message, instruction, or signaling indicative of requesting an alias translation. The access server 524 checks whether a reply has been received or the external request timer has expired in step 3218. If a reply has not been received and the external request timer has not expired, the access server 524 returns to step 3218.

If a reply has been received or the external request timer has expired, the access server 524 checks if the reply was valid in step 3220. If the reply is invalid, the access server 524 discards the packet and replies with an invalid alias message or alias error message to the network device 512 before returning to step 3202. If the reply is valid, the access server 524 caches the alias translation for the user in step 3222 before returning to step 3216.

FIG. 33 depicts a flowchart for the database system 522 for domain name scoping in an example of the invention. FIG. 33 begins in step 3300. In step 3302, the database system 522 waits for a request. The database system 522 then receives and processes the request from the access server 524 in step 3304. In step 3306, the database system 522 then checks if the access server requester is known in step 3306. If the access server requester is not known, the database system 522 then registers an unknown requester event in step 3308. The database system 522 appends the reply information to the packet in step 3310. The database system 522 replies with a decline message to the access server 524 in step 3312 before returning to step 3302.

If the access server requester is known, the database system 522 then checks whether the request is an alias translation request in step 3314. If the request is not an alias translation request, the database system 522 registers an unknown request event in step 3316 before returning to step 3310. If the request is an alias translation request, the database system 522 identifies and authenticates the user and the network device 512 in step 3318. If the access is invalid, the database system 522 increments a path/device security record in step 3322. The database system 522 then appends the requester denial information to the request packet in step 3324. The database system 522 then replies with a decline message to the access server 524 in step 3312 before returning to step 3302.

If the access is valid, the database system 522 retrieves the user's alias translation list in step 3326. The database system 522 then translates the alias for the user and appends the translation to a reply to the access server 524. The database system 522 then replies with an approve message to the access server 524 in step 3330. In one embodiment of the invention, the database system 522 uses the alias translation system 578 to perform the operations disclosed in FIG. 33 and stores the aliases and alias translations in the alias translation system 578.

Inband Domain Name Service Lookup

The Domain Name Server (DNS) translations of a domain name to a network address delays user interaction with the service provider. In prior solutions in voice telephone Signaling System #7 networks, a signal transfer point performs an inband local number portability (LNP) lookup on a ISDN part call setup request such as an Initial Address Message (IAM). This inband lookup eliminates the network switch from launching a Transaction Capabilities Application Part (TCAP) LNP query to translate the telephone number in the IAM.

FIGS. 5 and 34 disclose one embodiment for inband domain name service in an example of the invention. This embodiment provides a cache for the access server 524 for alias translations on a per user basis. Thus, the external queries for translations of aliases to domain names, macros, programs, or network addresses are eliminated. If the translated value of a request is in the alias translation cache, no translation request will be required to a DNS server. Therefore, users experience reduced delays when requesting a service.

FIG. 34 depicts a flowchart for the access server 524 for an inband domain name service lookup in an example of the invention. FIG. 34 begins in step 3400. In step 3402, the access server 524 waits for a packet. The access server 524 then receives and processes the packet from the network device 512 in step 3404. The access server 524 then checks if the destination network address and user is valid in step 3406. If the destination network address and user is valid, the access server 524 transmits the packet on the correct path to reach the destination in step 3408 before returning to 3402.

If the destination network address or the user is invalid, the access server 524 then checks if the alias translation is cached for the user in step 3410. If the alias translation is cached, the access server 524 reformats the packet using the cached alias translation in step 3412 before returning to step 3402. If the alias translation is not cached, the access server 524 sets an external request timer in step 3414. The access server 524 then generates and transmits an alias translation request to the database system 522 in step 3416. The access server 524 checks whether a reply has been received or the external request timer has expired in step 3418. If a reply has been received and the external request timer has not expired, the access server 524 returns to step 3418.

If a reply has been received or the external request timer has expired, the access server 524 checks if the reply was valid in step 3420. If the reply is invalid, the access server 524 discards the packet and replies with an invalid alias message to the network device 512 in step 3424 before returning to step 3402. If the reply is valid, the access server 524 caches the alias translation for the user in step 3422 before returning to step 3412.

Inline Access Service Triggering

Typical firewalls filter packets out on a request by request basis on "what is not allowed". FIGS. 5 and 35 disclose one embodiment for inline access service triggering. In this embodiment, the access server 554 filters packets out on a "what is allowed" basis. Also, the access server 554 performs packet filtering on a service access basis.

FIG. 35 depicts a flowchart for inline access service triggering in an example of the invention. FIG. 35 begins in step 3500. In step 3502, the access server 554 waits for the next packet. In this embodiment, the access server 554 receives information in the form of packets from the network device 512. The access server 554 receives and processes a packet from the network device 512 in step 3504. In step 3506, the access server 554 checks if the protocol, sending address, and the destination address are known and allowed to pass. In one embodiment, the access server 554 checks the database system 522 for the determination made in step 3506. If the protocol, sending address, and the destination address are known and allowed to pass, the access server 554 checks if the sending address is consistent with the path in step 3508. If the sending address is not consistent with the path, the access server 554 registers a path security event in step 3510. The access server 554 then