Patent ID: 12192361

DETAILED DESCRIPTION

The present disclosure is generally directed to the DNS and, more specifically, to systems, methods, and computer-readable storage devices for maintaining the DNS. Embodiments disclosed herein provide a separate, secure interface to DNS registries for DNS registrants and/or the service providers that do not require access to the DNS registry through a DNS registrar, while preserving the existing DNS interface between registrants, registrars, and DNS registries. Systems and methods in accordance with aspects of the present disclosure ensure security of the DNS registry by identifying, authenticating, and authorizing all of the involved entities (i.e., DNS registrants, service providers, and DNS registrars) and/or their requests for services. For example, some implementations can identify and authenticate an entity before access it is granted to services of the DNS registry. Other implementations, can verify that requests from the entities are authorized. For example, an entity client may rely on an authorization on behalf of another entity, and may not need to be authenticated. Additionally, embodiments disclosed herein allow clients who do not have a direct business relationship with the registry operator to access registry services.

FIG.1illustrates a block diagram of an example of an environment10for implementing systems and methods in accordance with aspects of the present disclosure. The environment10can include a DNS registrant20, a DNS registrar30, a service provider40, an identity service50, and a DNS registry system60, which can exchange information via one or more networks (e.g., the Internet) and/or communication protocols (e.g., Transmission Control Protocol/Internet Protocol (TCP/IP), Extensible Provisioning Protocol (EPP) and (e.g., Registration Data Access Protocol (RDAP)). Further, the DNS registry system60can include a DNS registry database70, a primary DNS interface service80, and a secondary DNS interface service90.

The DNS registrant20, the DNS registrar30, the service provider40, and the DNS registry system60can be the same or similar to those previously described herein. For example, in accordance with the domain name registration process, the DNS registrant20can use the DNS registrar30to register and manage domain names in the DNS registry system60via the primary DNS service80using the domain name registration process and the EPP.

Additionally, in accordance with aspects of the present disclosure, the DNS registrant20and/or the service provider40can administer a domain name record95of the DNS registrant20recorded in the DNS registry system60via the secondary DNS interface service90without the need for support of the DNS registrar30. For example, the secondary DNS interface service90can publish data from the DNS registry database70for use by the DNS registrant20and the service provider40. Also, the secondary DNS interface service90can receive data from the DNS registrant20and the service provider40and initiate operations on their behalf. Further, the secondary DNS interface service90supports query operations. Moreover, the secondary DNS interface service90can confirm that the DNS registrant20and/or the service provider40have administrative control over a domain name of the DNS registrant20by verifying authorization tokens.

In embodiments, the secondary DNS interface service90provides a web interface (e.g., a representational state transfer (RESTful) interface) by which the DNS registrant20and/or the service provider40can access information stored in the DNS registry database70of the DNS registry system60. For example, using the secondary DNS interface service90, the DNS registry system60can share information stored in the DNS registry database70with the DNS registrant20and the service provider40. As such, the DNS registrant20and the service provider40can access information that may be unavailable to them via the primary DNS interface service80without passing through the DNS registrar30. Accordingly, the DNS registrant20and the service provider40can administer information associated with a domain name in the DNS registry system60by requesting actions that the DNS registrar30does not offer or that are not supported by the primary DNS interface service80.

In accordance with some aspects of the present disclosure, the secondary DNS interface service90is entirely separate and independent of the primary registration service80used by the DNS registrar30. For example, the secondary DNS interface service90can be a separate web interface, provided by separate hardware (e.g., servers), and/or using separate communication protocols (e.g., RDAP) than those used by the primary DNS interface service80.

Additionally, in accordance with aspects of the present disclosure, the environment10includes the identity service50, which identifies and authenticates interactions with the secondary DNS interface service90. For example, the identity service50identifies, authenticates, and authorizes the DNS registrant20and/or the service provider40as part of validating their privileges for read and/or write access to the secondary DNS interface service90. In embodiments, access to the secondary DNS interface service90is granted when the DNS registrant20or the service provider40sends a request to the secondary DNS interface service90that is accompanied by an authorization token. For example, the secondary DNS interface service90compares the received authorization token with another copy of the token obtained from a trusted third-party provider (e.g., the DNS registrar30, the identity service50, or the DNS registry system60), and access to the secondary DNS interface service90is granted and a requested operation is performed if the authorization tokens are identical. Access is denied and the requested operation fails if the authorization tokens are not identical.

In some embodiments, the identity service50can be a federated authentication identity service that manages client credentials, authenticates client identity, and provides information needed to make registry authorization and access control decisions. In embodiments, the identity service50uses the OpenID Connect protocol, which can allow identity service50to verify the identity of entities (e.g., DNS registrant20and service provider40). It also allows the secondary DNS interface service90to receive information about entities in an interoperable and RESTful manner. The entities are able to interact with the secondary DNS interface service90using OpenID credentials issued by a number of existing identity providers, so the DNS registry system60does not need to issue and maintain access credentials for every entity. Entity requests to access secondary DNS interface service90can be intercepted and authenticated, ensuring that access is granted only to authorized entities.

DNS registrants20can also use authorization information (e.g., tokens) to have actions performed on their behalf through the service provider40using the secondary DNS interface service90. Authorization information can include either a single token to be used for all actions or multiple tokens to be associated with specific actions. Additionally, the DNS registrant20can provision authorization tokens for specific purposes to the DNS registry system60using a secondary DNS interface service90interface. Purpose-specific tokens can be retrieved by registrants who provide appropriate identification credentials and a master authorization token.

Beneficially, the authorization processes in accordance with aspects of the present disclosure allow the DNS registrant20to prove that they have administrative control over the domain name record95. The authorization tokens can be used authorize specific operations requested by the DNS registrant20or the service provider40acting on behalf of the DNS registrant20. These operations depend on a secondary DNS interface service90that is capable of performing both read and write data management operations.

The environment10shown inFIG.1is a simplified block diagram for the sake of illustration. For example, as illustrated the environment10includes a single DNS registrant20, a single DNS registrar30, and a single service provider40. However, it is understood that environment10can include more than one of each of these entities. Additionally,FIG.1shows the identity service50is shown as a standalone service. However, in other embodiments, the identity service50is hosted by the DNS registry system60. In other embodiments, the DNS registrar30hosts the identity service50.

FIG.2illustrates a functional flow diagram of an example of a process200by which DNS registrant20and/or service provider40can update DNS registry system60via secondary DNS interface service90. The functional flow diagram is accompanied inFIG.2by the dashed circles, which are numbered (201)-(206) to aid in clarity.

In accordance with aspects of the present disclosure, the DNS registrant20has a pre-established relationship with the DNS registrar30and the service provider40. For example, the DNS registrant20may have previously used the DNS registrar30to obtain and register domain name record95with the DNS registry system60, as previously described herein. Also, as previously described herein, the DNS registrant20may have previously engaged the service provider40to provide domain name resolution servers, identify authentication services, DNS Security Extensions (DNSSEC) key management services, and the like in association with the domain name record95.

In accordance with aspects of the present disclosure the DNS registrant20has access to authorization token100, which is specific to its domain name record95registered in the DNS registry60. The domain specific authorization token100can be stored by an identity service (e.g., the identity service50), which may be hosted by the DNS registrar30. In some embodiments the authorization token100may be one of multiple limited-use tokens. For example, the tokens can be limited to use for a specific purpose and/or by a specific service provider40and/or a specific period of time (i.e., they may expire). These additional tokens may be stored at the DNS registrar30and made accessible through a service interface. In some embodiments the authorization token can be derived from a base token and input parameters. These parameters may include (but are not limited to) the authorization token, the identity of the service provider40, the requested action, and the current time.

At (201) the DNS registrant20can send a request to the DNS registrar30for the authorization token100. The DNS registrar30verifies the identity of the DNS registrant20based on, for example, a pre-established credential provided in association with the request. Additionally, the DNS registrar30can verify that the DNS registrant20is permitted to receive the authorization token100based on pre-established policies (e.g., time of request, location, or requestor, type of action associated with the request). If verified, at (202) the DNS registrar30returns the authorization token100to the DNS registrant20. At (203) the DNS registrant20sends the authorization token100and an action request to the service provider40. Examples of action requests include, but are not limited to, validation of the authorization token100(without necessarily any further action); addition of DNS records in the DNS registry60; modification of DNS records; and modification of registrant contact information. An example where the secondary DNS interface service90performs only validation and not further action is when the service provider40is a certification authority and is validation the DNS registrant's20association with the domain prior to issuing a certificate to the DNS registrant20.

At (204) the service provider40sends the action request and the authorization token100to the secondary DNS interface service90via, for example, a web interface of the secondary DNS interface service90. The secondary DNS interface service90receives the related action request and the authorization token100(although not necessarily together). The secondary DNS interface service90checks the authorization token100for consistency with an expected value received from the identity service50(e.g., by direct comparison, or by comparing hash values). Alternatively, the secondary DNS interface service90may send the authorization token100to the identity service50for confirmation. The secondary DNS interface service90may also compare the service provider40identity and related action to a list of permissions associated with the token. If the authorization token100matches the expected value, the secondary DNS interface service90performs the requested action on the DNS registry60. At (205) the secondary DNS interface service90returns a confirmation response to the service provider40. At (206) the service provider40returns a confirmation response to the DNS registrant20.

The process200enables a service provider40to interact with the secondary DNS interface service90on behalf of the DNS registrant20. The flow of the process200conveys the DNS registrant's20authorization of the service provider40's requests via the authorization token100obtained from the DNS registrar30. However, it is understood that in some embodiments the service provider40may be excluded and the DNS registrant20can interact directly with the secondary DNS interface service90without the action request passing though the service provider40.

FIG.3illustrates a functional flow diagram of an example of a process300in accordance with aspects of the present disclosure, wherein a token service310provides a standalone identity service (e.g., identity service50) that manages authorization tokens. The functional flow diagram is accompanied inFIG.3by the dashed circles, which are numbered (301)-(306) to aid in clarity.

In accordance with aspects of the present disclosure, the DNS registrant20has an account315at the token service310and has linked its domain in the DNS registry to the account315. For example, the DNS registrant20may use an initial authorization token obtained from the DNS registrar30to demonstrate its authorization to link the domain to the account315. Additionally, the token service310can have a pre-established relationship with the secondary DNS interface service90.

At (301) the DNS registrant20requests authorization token100from the token service310. At (302) the token service310returns the authorization token to the DNS registrant20. At (303) the DNS registrant20sends an action request to the service provider40along with the authorization token100, as described previously herein. At (304) the service provider40sends a related action request and the authorization token to the secondary DNS interface service90.

At (305) the secondary DNS interface service90interacts with the token service310to validate the authorization token100and its authorization for the related action request (e.g., that the token is associated with a specific domain). The token service310receives the authorization token100and the related action information from the secondary DNS interface service90and checks it for consistency with an expected value. The token service310may also compare the service provider40identity and related action to a list of permissions and/or a set of policies associated with the authorization token100.

At (306) the token service310returns a response to the secondary DNS interface service90. The secondary DNS interface service90performs the related action if the token has been accepted by the token service310. At (307) the secondary DNS interface service90returns a response to the service provider40. At (308) the service provider40returns a response to the registrant and may perform an action itself. The service provider40can share the token with other service providers to authorize them also to interact with the secondary DNS interface service90on behalf of the DNS registrant20, provided that they are also within the predefined scope of the authorization.

Advantageously, the token service310is independent of the DNS registrar30. Hence, once the DNS registrant20has set up the account315and linked it to its domain (e.g., domain name record95), the DNS registrant20can obtain additional authorization tokens without further interaction with the DNS registrar30. In addition, the token service310does not need to interact with the DNS registry60to obtain the authorization token100. This gives greater flexibility to the token service315for managing the authorization token100, as well as interactions of the DNS registrant20.

FIG.4illustrates a functional flow diagram of an example of a process400in accordance with aspects of the present disclosure, wherein an identity provider410(e.g., identity service50) authenticates DNS registrant20and thereby enables the DNS registrant20to authorize actions requested by service provider40. The functional flow diagram is accompanied inFIG.4by the dashed circles, which are numbered (401)-(408) to aid in clarity.

The identity of the DNS registrant20can be a form of contact information backed by the registrant's association with the identity provider410, which can independently authenticate the DNS registrant20and its requests for actions or service in the DNS registry system60.

In accordance with aspects of the present disclosure, the DNS registrant20has a pre-established account415with the identity provider410that establishes an identity417. The DNS registrant20also has an account420at the secondary DNS interface service90based on the identity417. The DNS registrant20has linked a domain name (e.g., domain name record95) to the account420at the secondary DNS interface service90. As discussed previously, this linkage may be achieved by presenting an initial authorization token obtained from the DNS registrar30. In accordance with aspects of the present disclosure, the DNS registrant20has an account at the service provider40based on the same identity417. Having the account420at the secondary DNS interface service90does not necessarily require that the secondary DNS interface service90maintain a persistent record of the account420itself. Instead, information of the account420could be stored elsewhere, e.g., at the identity provider410, or at another service. When the DNS registrant20demonstrates to the secondary DNS interface service90or respectively to the service provider40that the DNS registrant20has successfully authenticated its identity417to the identity provider410, the secondary DNS interface service90or the service provider40provides access to actions on the DNS registry system60.

At (401) the DNS registrant20authenticates to the identity provider410, indicating its intent to interact with the service provider40(and possibly to authorize an action). At (402) the identity provider410returns an authentication assertion confirming the successful authentication. In some embodiments, the DNS registrant20can begin by interacting with the service provider40, and the service provider40can interact with the identity provider410on the DNS registrant's20behalf, or refer the DNS registrant20to the identity provider410. At (403) the DNS registrant20sends an action request to the service provider40along with the authentication assertion. At (404) the service provider40verifies the authentication assertion. Depending on the type of authentication assertion, the service provider40may interact with the identity provider410as part of the verification process. At (405) the service provider40sends a related action request and the authentication assertion to the secondary DNS interface service90. At (406) the secondary DNS interface service90verifies the authentication assertion, which may include interacting with the identity provider410to validate the service provider40's authorization for the related action request (e.g., that the DNS registrant's20identity417is associated with a specific domain name record95. At (407) the secondary DNS interface service90returns a response to the service provider40. The related action is performed if the authentication assertion has been accepted. At (408) the service provider40returns a response to the DNS registrant20.

The process400has the advantage that the DNS registrant20only interacts with the identity provider410and the service provider40in the normal flow. That is, the DNS registrant20does not need to interact with the secondary DNS interface service90. The action of the service provider40action can nevertheless be limited to domains linked to the identity417of the DNS registrant in the account420at the secondary DNS interface service90.

The storage of the same identity417at both the service provider40and the secondary DNS interface service90enables the authorization received by one to be validated by the other. In other embodiments, different identities and/or identity providers could be employed provided that there is a trustworthy way to associate them. Notably, the service provider40, the secondary DNS interface service90, the DNS registrar40, and the DNS registry system60could also take the role of the identity provider410. Also note that if the service provider40only wants to validate the association with a domain of the DNS registrant20, the service provider40may not need the authorization of the DNS registrant20to do so. In particular, the identity417of the DNS registrant20may be available as public registration data, or otherwise accessible to service provider40without authorization. If so, the service provider40only needs to obtain the identity417of the DNS registrant20authoritatively from the secondary DNS interface service90, and can then validate that a request is accompanied with an authentication assertion with the identity417. The publication of the identity of the DNS registrant20in association with the domain could also in principle be accomplished as a DNS or DNS-based Authentication of Named Entities (DANE) record.

FIG.5illustrates a functional flow diagram of an example of a process500in accordance with aspects of the present disclosure, wherein the DNS registrant20links a public key503to its registered domain (e.g., domain name record95) at the secondary DNS interface service90. Based on the public key503, the DNS registrant20can authorize the service provider40by digitally signing the authorization with the corresponding private key505. The service provider40can convey the message and the secondary DNS interface service90can validate it with respect to the linked public key503. The functional flow diagram is accompanied inFIG.5by the dashed circles, which are numbered (501)-(504) to aid in clarity.

In accordance with the present example, the DNS registrant20has an account520at the secondary DNS interface service90, which the DNS registrant20has linked to its domain, as previously described herein. The DNS registrant20has a public/private key pair503/505and has linked the public key503or a related digital certificate to the account520and/or to this domain at the secondary DNS interface service90. The secondary DNS interface service90may require proof of possession of the corresponding private key505to authenticate the linkage and/or proof of administrative control over the associated domain name record95. The DNS registrant20also has account515at the service provider40.

In accordance with the process500, at (501) the DNS registrant20sends an action request to the service provider40along with a digital signature under the private key505of the DNS registrant20on a message authorizing the service provider40to operate on behalf of the DNS registrant20. The registrant may also include a related digital certificate. The service provider40verifies the digital signature. At (502) the service provider40sends a related action request and the digitally signed authorization to the secondary DNS interface service90. The secondary DNS interface service90verifies the digitally signed authorization using the previously linked public key503of the DNS registrant20to validate the service provider40's authorization for the related action request. At (503) the secondary DNS interface service90returns a response to the service provider40. The related action is performed if the authorization has been accepted. At (504) the service provider40returns a response to the DNS registrant20and may perform an action itself.

Advantageously, the process500does not involve an identity provider (e.g., Identity service50) for authorization. However, in accordance with the present example, the DNS registrant20must maintain a public/private key pair503/505. And, if the service provider40only wants to validate the association of the DNS registrant20with a domain, then the service provider40may not need the authorization of the DNS registrant20to do so. Here, the public key503of the DNS registrant20may be available as public registration data, or otherwise accessible to service provider40without authorization. If so, the service provider40only needs to obtain the public key503of the DNS registrant20authoritatively from the secondary DNS interface service90, and can then validate the digital signature of the DNS registrant20on a related request. Note again that in this case the publication of the public key503of the DNS registrant20in association with the domain could be accomplished as a DNS or DANE record.

In accordance with aspects of process500, the service provider40can authorize other service providers to perform actions on behalf of the DNS registrant20via digital signatures, following a similar approach. Here, the service provider40could link its public key503to the domain it is managing on behalf of the DNS registrant20, so that the secondary DNS interface service90can validate authorization messages signed by the service provider40. Alternatively, the service provider40could include its original authorization from the DNS registrant20in the message it signs authorizing another service provider40to act on its behalf. The other service provider40could then present both the original authorization and the second authorization to the secondary DNS interface service90.

In the above examples, the secondary DNS interface service90determines that a service provider40is authorized to operate on the DNS registrant's20behalf by validating information presented by the service provider40that conveys the authorization of the DNS registrant20. In the examples ofFIGS.2and3, the information is an authorization token. In the example ofFIG.4, the information is an assertion from an identity provider. And in the example ofFIG.5, it is the digital signature of the DNS registrant20. This approach is convenient because it does not require the secondary DNS interface service90to keep track of which service provider40shave been authorized by a particular DNS registrant. The secondary DNS interface service90determines authorization in the context of a service provider40's request.

In accordance with aspects of the present disclosure, the service provider40may be selected from a list of service provider40smaintained or otherwise obtained by the secondary DNS interface service90. The secondary DNS interface service90thus takes the role of a “service catalog” where service provider40scan indicate their capabilities and registrants can indicate their requirements. The secondary DNS interface service90can then “broker” relationships between the two. The secondary DNS interface service90can also broker such relationships between service providers. For example, a service provider40may want to bundle other services along with its service. When authorizing a service provider40to request operations on its behalf, the registrant could also specify that the service provider40may enlist other service provider40sin the process.

As an example, suppose a user has an account on an e-commerce site, but does not yet have a domain name, and wants to register a domain name for use in a custom email addresses, so that her e-commerce site correspondence appears more “official.” Suppose further that the e-commerce site is a reseller of domain names, but does not operate an email service. The e-commerce site may offer to register the custom domain name for the user, but would need to enlist an email service provider40to manage the email for the domain (which may involve updates to registration data). The e-commerce site could become authorized as part of registering the domain name for the registrant, which could be done by automating the workflow of the user, now in the role of a registrant, for registering the domain name, for setting up an account at the secondary DNS interface service90, and for authorizing the e-commerce site to manage the domain on the user's behalf. The e-commerce site could then interact with the secondary DNS interface service90, select an email service provider40for the domain, and authorize the email service provider40(on behalf of the user) to manage related registration data.

FIG.6illustrates a system block diagram of a DNS registry system60in accordance with aspects of the present disclosure. The DNS registry system60can be the same or similar to that previously described. The DNS registry system60includes hardware and software that perform processes, services, and functions described herein. In particular, the DNS registry system60includes a computing device630, an input/output (I/O) device633, and a storage system635. The I/O device633can include any device that enables an individual (e.g., an end user and/or consumer) to interact with the computing device630and/or any device that enables the computing device630to communicate with one or more other computing devices using any type of communications link. The I/O device633can include, for example, a touchscreen display, pointer device, keyboard, etc.

The storage system635can comprise a computer-readable, non-volatile hardware storage device that stores information and program instructions. For example, the storage system635can be one or more flash drives and/or hard disk drives. In accordance with aspects of the present disclosure, the storage system can include the DNS registry database70, which can be the same or similar to that previously described herein.

In embodiments, the computing device630includes one or more processors639(e.g., microprocessor, microchip, or application-specific integrated circuit), one or more memory devices641(e.g., RAM and ROM), one or more I/O interfaces643, and one or more network interfaces644. The memory device641can include a local memory (e.g., a random access memory and a cache memory) employed during execution of program instructions. Additionally, the computing device630includes at least one communication channel (e.g., a data bus) by which it communicates with the I/O device633, the storage system635. The processor639executes computer program instructions (e.g., an operating system and/or application programs), which can be stored in the memory device641and/or storage system635. Moreover, the processor639can execute computer program instructions of identity service50, primary DNS interface service80, and secondary DNS interface service90, which may be the same or similar to those previously discussed herein.

FIG.7illustrates a system block diagram of an identity service system700in accordance with aspects of the present disclosure. The identity service system700can be the same or similar to that previously described. The identity service system700includes hardware and software that perform processes, services, and functions described herein. In particular, the identity service system700includes a computing device730, an input/output (I/O) device733, and a storage system735. The I/O device733can include any device that enables an individual (e.g., an end user and/or consumer) to interact with the ICN server15(e.g., a user interface) and/or any device that enables the computing device730to communicate with one or more other computing devices using any type of communications link. The I/O device733can include, for example, a touchscreen display, pointer device, keyboard, etc.

The storage system735can comprise a computer-readable, non-volatile hardware storage device that stores information and program instructions. For example, the storage system735can be one or more flash drives and/or hard disk drives. In accordance with aspects of the present disclosure, the storage system can include information for an account417, which can be the same or similar to that previously described herein.

In embodiments, the computing device730includes one or more processors739(e.g., microprocessor, microchip, or application-specific integrated circuit), one or more memory devices741(e.g., RAM and ROM), one or more I/O interfaces743, and one or more network interfaces744. The memory device741can include a local memory (e.g., a random access memory and a cache memory) employed during execution of program instructions. Additionally, the computing device730includes at least one communication channel (e.g., a data bus) by which it communicates with the I/O device733, the storage system735. The processor739executes computer program instructions (e.g., an operating system and/or application programs), which can be stored in the memory device741and/or storage system735. Moreover, the processor739can execute computer program instructions of Identity service50, which may be the same or similar to that previously discussed herein.

It is noted that in some embodiments the computing device730can comprise any general purpose computing article of manufacture capable of executing computer program instructions installed thereon (e.g., a personal computer, server, etc.). However, the computing device730is only representative of various possible equivalent-computing devices that can perform the processes described herein. To this extent, in embodiments, the functionality provided by the computing device730can be any combination of general and/or specific purpose hardware and/or computer program instructions. In each embodiment, the program instructions and hardware can be created using standard programming and engineering techniques, respectively.

The foregoing description is illustrative, and variations in configuration and implementation may occur to persons skilled in the art. For instance, the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor (e.g., processor739), an application specific integrated circuit, a field programmable gate array or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a microprocessor, a plurality of microprocessors, or any other such configuration.

In one or more exemplary embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. For a software implementation, the techniques described herein can be implemented with modules (e.g., procedures, functions, subprograms, programs, routines, subroutines, modules, software packages, classes, and so on) that perform the functions described herein. A module can be coupled to another module or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, or the like can be passed, forwarded, or transmitted using any suitable means including memory sharing, message passing, token passing, network transmission, and the like. The software codes can be stored in memory units (e.g., memory device741or storage system735) and executed by the processor. The memory unit can be implemented within the processor or external to the processor (e.g., processor739), in which case it can be communicatively coupled to the processor via various means as is known in the art.

If implemented in software, the functions may be stored on or transmitted over a computer-readable medium as one or more instructions or code. Computer-readable media includes non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available tangible, non-transitory media that can be accessed by a computer. By way of example, and not limitation, such tangible, non-transitory computer-readable media can comprise RAM, ROM, flash memory, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, DVD, floppy disk and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Combinations of the above should also be included within the scope of computer-readable media.

Resources described as singular or integrated can in one embodiment be plural or distributed, and resources described as multiple or distributed can in embodiments be combined. The scope of the present teachings is accordingly intended to be limited only by the following claims. Although the invention has been described with respect to specific embodiments, those skilled in the art will recognize that numerous modifications are possible. For instance, the proxy servers can have additional functionalities not mentioned herein. In addition, embodiments of the present disclosure can be realized using any combination of dedicated components and/or programmable processors and/or other programmable devices. While the embodiments described above can make reference to specific hardware and software components, those skilled in the art will appreciate that different combinations of hardware and/or software components can also be used and that particular operations described as being implemented in hardware might also be implemented in software or vice versa.