WO2001077839A1

WO2001077839A1 - Establishing and maintaining internet domain name registrations

Info

Publication number: WO2001077839A1
Application number: PCT/US2001/011115
Authority: WO
Inventors: Sanjeev Chauhan; Brian Taylor; Sujata Nakhre; Steve Mahlstedt; Dave Devarajan; Robert Lovell; Greg Korzeniewski; Debbi Lechner; Mark Henderson-Thynne
Original assignee: Network Solutions, Inc.
Priority date: 2000-04-06
Filing date: 2001-04-06
Publication date: 2001-10-18
Also published as: AU2001249889A1

Abstract

A system method for conducting transactions associated with managing Internet Domain Names includes establishing a connection between a user and a registrar (22) of Internet Domain Names over the Internet, authenticating the right of the user to so request fulfillment of a transaction, establishing a secure socket layer within said connection and processing commands after such authentication. The commands are written as ASCII-text statements representative of the particular transaction requested by the user.

Description

ESTABLISHING AND MAINTAINING INTERNET DOMAIN NAME REGISTRATIONS

BACKGROUND OF THE INVENTION

The explosive growth of the Internet has created the need for orderly management of the process for creating domain name registrations (also known as Web addresses) and subsequent administrative activities such as changes in ownership, renewals, and so forth. Network Solutions, Inc. of Herndon, Virginia is one organization which facilitates the acquisition, registration and management of domain name registrations ("DNRs"), at least for domain names ending in .com, .net, .org and .edu. In such role, Network Solutions, Inc. is known as a Registrar. Approximately five million Web addresses have been registered by Network Solutions, Inc. so far.

Presently-implemented systems for registration of Web Addresses rely almost exclusively on the use of e-mails between users and the Registrar for each step of the process. For example, referring to Figure 1 , which shows the sequence of steps for registration, a customer (Registrant) prepares to register new Web Address 100;

The Registrant fills out a Service Agreement (102). The Service Agreement is submitted by e-mail to the Registrant, for example, to hostmaster@internic.net (step 104). The Request is automatically assigned a tracking number 106. The Service Agreement is automatically checked for errors 108. The Service Agreement is processed if there are no errors and the registrant is notified via e-mail when completed 112. Web Address registration is complete with a message. For example, the message may read: "Your Web Address registration is complete" (step 114). The customer is invoiced for the Web Address registration, step 116, and, pays for the registration (step 118).

Finally, the Registrar sends a re-registration notice to registrant 60 days before the two year anniversary of the initial registration (step 120). Should there be an error in the Service Agreement, the registration process is not completed and an e-mail is sent to the customer informing it of the problem (step 110). While this process works effectively, it is not without certain shortcomings. Most notably, the use of the Internet for e-mailing notices is not generally on a "real-time" basis. It may sometimes take several days for an e-mail to be delivered, particularly to parts of the world where the Internet support structure is not fully established. In addition, e-mails may become corrupted which creates further delays since the recipient must ask for the messages to be resent.

Accordingly, there is a need for implementing a system which permits registering and administrative functions on a near real-time basis. In addition, such a system would permit users seeking registrations to complete the process, regardless of their level of expertise in computer technology in general, and the Internet in particular.

In addition, recent events have resulted in the development of a concept termed "Wholesaling" by which other organizations, such as Internet Services Providers ("ISP"), Internet hosting providers, Internet portals and Electronic Commerce Providers are allowed to secure such DNRs on behalf of their own customers. In effect, such organizations act as their own Registrars by offering their customers an interface which permits unsophisticated and sophisticated users to interface with the registration process and subsequent management thereof. In addition, wholesalers may offer other associated products and services, beyond facilitating registration and management of Domain Name, for example, web hosting. Ultimately, however, DNRs are still issued by a Registrar, for example, Network Solutions, Inc.

This expansion in the number of outlets for securing DNRs has led to the development of systems and methods to facilitate wholesaling, as embodied in the present invention.

Those skilled in the art will recognize that principles of this invention, while focused on the Internet, are applicable to many other data management environments, including sales of products and services of virtually any type. In addition, the methods and systems according to the invention may be utilized wherever distributed users have a need to perform any type of transaction in real time via a central server connected to a master database.

SUMMARY OF THE INVENTION

To achieve these objects and other advantages and in accordance with the purposes of the invention, as embodied and broadly described herein. The present invention is directed to a system and method for conducting transactions associated with managing Internet domain names by establishing over the Internet a connection between a user and a Registrar; authenticating the right of the user to so request fulfillment of a transaction; establishing a secure socket layer (SSL) within the connection; and processing commands following such authentication. The commands are formatted as ASCII text representative of the particular transaction requested by the user.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an embodiment of the invention and together with the description, serve to explain the principles of the invention.

Figure 1 is a flow diagram of a currently-implemented system for Web Address registrations;

Figure 2 is a block diagram of an exemplary computer system used for implementing the wholesaling process;

Figure 3 is a flow diagram illustrating an authentication process used in establishing a wholesale session; and

Figure 4 is a logic diagram illustrating a queuing process flow for asynchronous operation.

DETAILED DESCRIPTION

Reference will now be made in detail to the present preferred embodiment of the invention, an example of which is illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like elements. The Wholesale system and protocol is designed to support Wholesalers of a Registrar's products. Generally, Wholesalers are hosting a Web-site or other real-time order entry system on which a Registrar's products and services are also offered (e.g., domain name registrations). The option to perform batch (or asynchronous) and real-time (or synchronous) commands is made possible through the Wholesale system to support these operations.

Referring to Fig. 2, major components of the Wholesale system 10 comprise a customer terminal 12 which is connected, generally via the Internet, to a Wholesaler system 14. The Wholesaler system 14 connects, again typically via the Internet, through a load balancer 16, to a protocol server 18. In practice, a number of servers 18 are configured to accept data from the load balancer 16 which effectively acts as a switch to insure that commands are fed to an individual server 18 despite the volume of data traffic. Protocol server 18 maintains multiple connections from users and load balancer 16 to a bank of Wholesale servers 22. Load balancer 18 also permits operation of the system on a 24-hour, 7-day basis with virtually no downtime. As protocol servers 18 are taken offline for maintenance, the load balancer 16 will route requests to other servers 18 that are retained online. Preferably, load balancer 18 is configured to comply with the Common Object Request Broker Architecture (CORBA) Standard, known to object-oriented programmers.

Protocol server 18 is used to control multiple user connections and perform command acceptance and parsing. Protocol server 18 opens a TCP socket port and "listens" for any attempt to make a connection to the system. When a connection attempt is requested, a series of connection checks are made to validate the user's connection source and connection type as will be described more fully hereinafter. The socket uses Secure Socket Layers ("SSL"), to encrypt and authenticate the user and protect the data being transmitted. Once the SSL encryption has been verified the originators, Internet Protocol ("IP") address is validated against a known list of users. The user is then allowed to enter a given set of commands. These commands are parsed by protocol server 18. Once the command has been parsed, protocol server 18 will connect through a firewall 20 to a Wholesale server 22 to complete the command and await a response.

Wholesale server 22 validates the commands and uses back-end services to complete the necessary actions. Each command is parsed and validated line by line, thereby validating the data elements provided. Wholesale server 22 will then connect to whichever correct back-end system server 26 is needed to complete the command. The back-end service response from server 26 is parsed and a user response is created, based on a success or failure message received. The Wholesale server 22 is able to queue and retry commands based on the operations of the back-end system 26. Results of command operations based on Wholesaler profiles results are returned in the form of appropriate e-mail messages.

A billing server 24 connected to Wholesale server 22 and back-end system 26 is used to create the appropriate invoice records in a billing database 30. Billing server 30 tracks the Wholesaler products being created and creates the correct invoice records.

The process for establishing a Wholesale session is now outlined.

A sequence of steps is executed when a Wholesaler issues a "Session" command resulting in command execution.

Wholesale users send commands to the system by connecting a Wholesaler system 14 to the Protocol server 18. The Protocol server 18 checks the command and then connects to a Wholesale server 22 inside the Registrar's firewall 20.

The Wholesale server 22 parses the command, checks for the correct number of parameters and attributes and validates the values sent by the user. If the command is related to a customer, the Wholesale system connects to the back-end system 26 and completes the requested process. The Wholesale system then sends the appropriate response to the Wholesale user. If the command is related to a product, the Wholesale system places the command into a queue and sends the appropriate response to the Wholesale user at terminal 14. The Wholesale server 22 then removes the command from the queue and commences processing of the product-related command by contacting the back-end services system 26 and awaiting a response. If the command fails, then the Wholesale system will determine if the command should be retried, and if so, will queue the command again. The Wholesale system uses email notification to notify the user of the success or failure of each command within a specified time frame.

The Wholesale billing server 24 is used to insert Wholesale-related invoices into the billing database 30. When a command is sent to the back-end system 26 it will direct all billing-related requests to the Wholesale billing server 24, which is connected to billing database 30.

To illustrate further the procedure for establishing session commands, reference is made to Figure 3, which depicts the various internal states that protocol server 18 may take at any given time. Upon a session command being issued, it is fed to logic step 40 (PRE1 State). Logic step 40 receives the command and attempts to authenticate it. If successful, a secure socket is established SSN (logic step 44). If authentication fails, the system will attempt a re-try, logic step 42 (state PRE2). If the retry attempt fails, another attempt at authentication is made, logic step 46 (state PRE3). If successful, the SSN is established, logic step 44. If this third attempt at authentication fails, the system disconnects cutting off further session commands from that particular IP address, logic step 48 (DIS State).

Once a wholesaler has been authenticated, access is provided for session commands to be processed. These include, for example, Create DNR, Delete DNR, Modify DNR, Lookup DNR, Renew DNR, and Verify DNR. Details of the various commands will be described more fully herein below.

In some cases, an attempt to establish a session will be immediately rejected, bypassing the authentication process. This may result, for example, when a particular IP address has been tagged as unacceptable, such as attempts by a hacker to penetrate the system. In such cases, the system responds by logic step 40 commanding logic steps 48 to immediately disconnect the user without performing any attempts to authenticate. An embodiment of the invention facilitates the processing of asynchronous commands by virtue of a queuing process flow, as depicted in Figure 4:

The Wholesale system 10 uses a queuing system for all product-related commands. This enables the system to provide a level of separation from back-end systems. Better response time for end users is also achieved, as well as improved error recovery mechanisms. Figure 4 shows an exemplary command sequence flow used by a Wholesale server 50 to complete purchase and modification requests. The Wholesale server 50 operates in a two-stage mode; first capturing and validating user requests, then later completing the requests. When a command is received it is validated and then queued. The user receives a "successfully queued" message.

The command will then be dequeued and completed by the wholesale system at a later time, typically on the order of five minutes or less. The wholesale system divides the back end responses into three categories, success, failure and internal failure. Internal failure is interpreted as a fixable problem related to the system and not the command, and, accordingly, is queued again. Processing of each command will be attempted only a limited number of times. Regardless of the outcome, an email notification will be sent to the Wholesaler to inform it of the status of the command once it has completed its cycle through the system. A general failure condition is generally fatal, and processing is aborted.

When an error is encountered, an automated monitoring system is informed of the problem so that appropriate action can be taken by the operational staff.

Reviewing this process in more detail, a Wholesale server 50 (configured generally in the same way as Wholesale server 22 of Figure 2) reads the command forwarded by the protocol server 18 and feeds it to logic step 52. If the command is for the creation of domain name service (DNS) related activity, such as the creation of a new DNR or the modification of an existing DNR, the command is branched to logic step 54, at which point the operation is verified. If evaluated as valid, the command branches to logic step 56 which prepares the command for queuing the operation in a regular queue state store or buffer 58. A confirmation is sent to the user at the same time. The command then enters a regular queue store 58.

At appropriate intervals, a queue server 60 coupled to regular queue store 58 sends a dequeuing command to store 58. The pending command is removed from the queue 58 and fed to logic step 62 which determines whether or not the operation as requested by the command is successful or not. If unsuccessful, an indication thereof is fed to logic step 64 which keeps a count of the number of requeuing attempts. If such number is greater than zero (signifying that the DNS command has not yet been executed) the logic step 64 issues a requeuing command to store 58 and the process is repeated. If logic step 64 determines that the number of requeuing attempts is not greater than zero, logic step 66 checks to see whether the number of failed transactions has exceeded a predetermined limit. If so, a command is sent to stage 70 to stop dequeuing operations and issue a notification to an overseer system named "Tivoli" and a further command to stage 58. If the number of failed transactions is less than the pre-established number, a command is sent to logic step 68 which checks for the presence or absence of internal or unknown errors. At the same time, a command is also fed back to regular queue store 58 to instruct it to remove the command from the queue.

Logic step 68 tests for errors. If an internal or unknown error is found, a command is sent to an escalation process stage 72 for additional analysis to determine the nature of the error, as well as the generation of appropriate notifications in the form of e-mails. An example of such an internal error would be an inoperative server from which objects are expected, but which fail to be delivered. If there is no such error, a command is issued to logic step 74 which checks to see whether the queue count has exceeded two. If so, logic step 74 simultaneously notifies escalation process stage 72 as well as failed queue stage 76.

If logic step 64 determines that the retry count has. exceeded zero, a command is sent to regular queue store 58 instructing it to requeue the command. Similarly, if logic step 66 ascertains that the maximum number of failed transactions has exceeded the preset number, store 58 is instructed to requeue the command.

A deamon process stage 78 dequeues and queues the commands in the regular queue store 58 after the lapse of a predetermined time interval.

The Wholesale Services Protocol ("WSP") is a connection-based, synchronized, ASCII text-based protocol that allows a Wholesaler to provide for domain registration and account maintenance services. Specifically, it allows wholesalers to securely and reliably create, modify, and delete customer accounts and to offer various other Wholesaler products via a single client/server interface. The primary function of WSP is to accept, parse, and process WSP requests. A single request can perform a simple action, for example, establishing an authenticated wholesaler session; or it can perform a more complex action upon a specified object, such as registering a domain name or creating a customer account. (As used herein, the term "object" refers to Java-type Objects, unless the context indicates otherwise.)

Wholesale Command Structure

The structure of a WSP is comprised of the following:

• A command followed by an optional class, followed by a required carriage return, line feed (CRLF) sequence;

• Zero or more parameter specifications, each consisting of a dash followed by a parameter key, followed by a colon (':'), followed by a parameter value and a CRLF sequence;

• Zero or more attribute specifications, each consisting of an attribute key followed by a colon (':'), followed by an attribute value and a CRLF sequence; or

• A request terminator.

In informal terms: Command [Class] crlf [-Parameter_Key:Parameter_Value crlf] [Attribute_Key:Attribute_Value crlfj

period crlf

The following diagram provides an example of a WSP request and its individual components.

Class

All commands, classes, parameter keys and attribute keys are case-insensitive.

Command Components

After establishing a session (described below), Wholesalers communicate with the Wholesale system by issuing requests. These may be sent directly through a socket, or through a "Software Development Kit" (SDK), which is a Perl or Java wrapper for the commands (described below).

The components of a WSP request are:

• Command

• Class

• Parameter Specifications (parameters)

• Attribute Specifications (attributes)

• Request Terminator

A WSP request begins with a single word referred to as a command. A command describes the action that a request will perform. The Commands supported by the Wholesale protocol are given below. A command is followed by an optional class and a carriage return and linefeed (CRLF) sequence. A command may optionally be followed by a class to fully define the desired action (e.g., verify a domain name). A class is essentially the name of an object on which a command is to perform an action. A class consists of one or more attributes, some of which can be set, modified, and referenced. A unique instance of a class, or object, is defined by its attribute settings.

A WSP request, depending on the type of request (defined by the command-class combination), can require or accept optional parameter specifications. A parameter specification provides information required by the command used to perform the requested action. Each parameter specification is comprised of a dash ('-'), followed by a parameter key, followed by a colon (':'), followed by a parameter value, followed by a CRLF.

A WSP request, depending on the type of request (defined by the command-class combination), can require or accept optional attribute specifications. An attribute specification provides object attribute settings required by a command that is performing an action upon an object. Each attribute specification is comprised of an attribute key, followed by a colon (':'), followed by an attribute value, followed by a CRLF. Each WSP request must be terminated by a Carriage Return, Line Feed (CRLF) sequence followed by a period ('.'), followed by another CRLF sequence.

Wholesale Commands

The following commands are representative of those which comprise a set within the Wholesale protocol.

Session Lookup DnsHosting Address3

-WholsalerAccountlD -CustomerAccountlD Address4 -WholesalerPassword -CustomerPassword Addressδ

Email

Verify DomainName Lookup DnsHosting Fax

-DomainName -CustomerAccountlD State (if country not US)

-CustomerPassword PostalCode (if country not

Verify Domains -DomainName US)

-DomainTarget

Lookup Create BusinessAccount

Verify Password IndividualAccount CompanyName

-CustomerAccountlD -CustomerAccountlD CompanyType -CustomerPassword -CustomerPassword Addressl

City

Generate DomainName Lookup BusinessAccount CountryCode

-Keywords -CustomerAccountlD Phone -CustomerPassword CustomerPassword

Lookup Domain AuthQuestion

-CustomerAccountlD Lookup AuthAnswer -CustomerPasword TechnicalContact LegalContactFirstName

-TechContactlid LegalContactLastName

Lookup Domain State (if country is US)

-CustomerAccountlD Create PostalCode (if country is -CustomerPassword IndividualAccount US)

-DomainName FirstName Address2

LastName Address3

Lookup Domain Addressl Address4

-CustomerAccountlD CountryCode Addressδ

-TechContactlD Phone Email

-TechContactPAssword CustomerPassword Fax

AuthQuestion State (if country not US)

Lookup Domain AuthAnswer PostalCode (if country not

-CustomerAccountlD City US)

-TechContactlD State (if country is US) LegalContactAddressl -TechContactPAssword PostalCode (if country is LegalContactAddress2 -DomainName US) LegalContactAddress3

Address2 LegalContactAddress4

LegalContactAddressδ -CustomerPassword PostalCode

LegalContactCity DomainName CountryCode

LegalContactState Phone

LegalContactPostalCode ModifyDomain Fax

LegalContactCountryCode -CustomerAccountlD Email

LegalContactPhone -CustomerPassword AuthQuestion

LegaiContactFax -DomainName AuthAnswer

LegalContactEmail HostNamel

HostAddM Modify BusinessAccount

Create Technical Contact HostName2 -CustomerAccountlD

FirstName HostAddr2 -CustomerPassword

LastName -TechContactlD CompanyName

Organization CompanyType

Addressl Modify Domain Addressl

CountryCode -CustomerAccountlD Address2

Phone -TechContactld Address3

Email -TechContactPassword Address4

TechContactPassword -DomainName Addressδ

City HostNamel City

State (if country is US) HostAddM State

PostalCode (if country is HostName2 PostalCode US) HostAddr2 CountryCode

-TechContactlD Phone

Create Domain Email

-CustomerAccountlD Modify Domain Fax

-CustomerPassword -CustomerAccountlD AuthQuestion

DomainName -IspPassword AuthAnswer

HostNamel -DomainName LegalContactFirstName

HostAddM -TechContactlD LegalContactLastName

HostName2 LegalContactAddressl

HostAddr2 Modify LegalContactAddress2

TechContactlD IndividualAccount LegalContactAddress3

-CustomerAccountlD LegalContactAddress4

Create Domain -CustomerPassword LegalContactAddressδ

-CustomerAccountlD FirstName LegalContactCity ,

-CustomerPassword LastName LegalContactState

DomainName Addressl LegalContactPostalCode

Hostldl Address2 LegalContactCountryCode

Hostld2 Address3 LegalContactPhone

TechContactlD Address4 LegaiContactFax Addressδ LegalContactEmail

Create DnsHosting City

-CustomerAccountld State

Modify TechnicalContact

-TechContactld

-TechContactPassword

FirstName

LastName

Addressl

City

State

PostalCode

CountryCode

Phone

Fax

Email

-TechContactPassword

Modify Password

-CustomerAccountlD CustomerPassword

Describe

-Target

Help

Perl Software Development Kit (SDK)

The Perl API to the NSI Wholesale protocol allows Perl programs to interface with the Wholesale system. The Perl API is part of the Software Design Kit (SDK) of the Wholesale system. The Perl API provides a Perl object that other Perl programs can use to connect to the Wholesale system, start a session, and invoke all the commands supported by Wholesale protocol. It is up to the calling program to decide how many commands to execute in one session.

This Perl API implements all Wholesale Protocol commands as methods on a Perl object. Each of these commands is a blocking command and returns the response from the Wholesale system as a multi-line string. The following example illustrates how a Perl program can use the Perl API of the Wholesale system to connect to the system, create an individual account, and create a domain for the newly created customer. For the sake of simplicity, the error checking and parsing of response strings are omitted.

#!/usr/local/bin/perl use strict; use WS::WSApi; my $customer_id = undef; my $response = undef;

# create WSAPI object with the system configuration file; my $WSP = new WSApi();

# connect and create session.

My $resp = $WSP->Connect("api.config");

#if the connection is established, the $resp = "241.000 OK" #Create a $params that has #"WholesalerAccountld:1234 WholesalerPassword:Password"

#$WSP->Session($params); # session start

#Define the $attrib to be all the values needed by the command.

$response = $WSP->CreatelndividualAccount($attrib);

#The $response would have following:

#"241.000 Properties being returned\nCustomerAccountld:1234\n.\n"

#Parse the response and get the customer account ID.

# Perform processing with this customer account ID and

# create a domain that belongs to this customer. $response = $WSP->CreateDomain($params, $attrib); #The $response variable will contain following

#"241.000 Properties Retumed\nlSPPassword:jsxk123\n.\n"

#Parse the response to obtain the ISP Password.

#Session Complete; Issue the quit command. It is a good practice #to issue a quit command after the session is complete.

$WSP->Quit();

At this point, the ISP password can be returned to the end user, and the transaction is complete as far as the end user is concerned. The client, however, can verify the successful creation of the domain in the background and proceed with the appropriate billing process. An example of the API command for the part of the background process is given below.

#Set params to have the appropriate CustomerAccountlD,

# password and the domainname. $response = $WSP->LookupDomain($params)

#Parse the response to see if the domain creation is

# 1. Still being processed.

# 2. Has failed.

# 3. Is successful.

#lf successful, following response will be obtained. #214.000 Properties being returned #DomainName:test01.com #TechContactld:SI1265 #HostName1 :NS.WEBK.NET #HostAddr1 :209.196.43.2δ4

#Hostld1 :NS31128-HST

#HostName2:NS2.WEBK.NET

#HostAddr2:209.196.43.2δ3

#Hostld2:NS31129-HST

#.

#Domain creation successful, so charge the customer.

Commands

A WSP request begins with a single word referred to as a command. A command describes the action that a request will perform. In one embodiment of the invention, eleven commands may be supported. A command is followed by an optional class and a carriage return and linefeed (CRLF) sequence.

Below is an exemplary list of the commands.

In the table above, the 'Scope' column identifies when, during the life of a protocol session, the command may be issued:

There are currently two types of classes: component classes and product classes. A component class represents an attribute, or type of attribute, found in one or more product classes (e.g., DomainName, Password...). A product class represents an NSI product or solution (e.g., DnsHosting, Domain,...).

Parameter Specifications

Attribute Specifications

A WSP request, depending on the type of request (defined by the command-class combination), can require or accept optional attribute specifications. An attribute specification provides object attribute settings required by a command that is performing an action upon an object. Each attribute specification is comprised of an attribute key, followed by a colon (':'), followed by an attribute value, followed by a CRLF.

Request Terminator

Each WSP request must be terminated by a CRLF sequence followed by a period ('.'), followed by another CRLF sequence.

Summary

A command specifies the type of action that a request is to take. This action may be performed upon a single instance (object) or upon multiple instances (objects) of a class. Parameters may be used by the command to determine and to instantiate the specific instance(s) of the class. Attributes of a specific class instance may be modified by including attribute specifications in the request. An attribute specification will always, if permitted, be used to modify an object's corresponding attribute; on the other hand, a parameter specification will never be used to modify an object's attributes. WSP Response Format

A WSP response is returned for each request that is issued through the protocol. A response describes, in as much detail as possible, the outcome of the issued request and will optionally include any additional information that was generated by the request. A response consists of a result code followed by a descriptive result message and a CRLF sequence. A result code consists of a major result code followed by a period ('.') followed by a minor result code. A variable number of lines of information may follow. In most cases, these lines of information will be one or more result properties. A result property consists of a property key followed by a colon (':'), followed by a property value and a CRLF sequence. In other cases, these lines of information will be plain text (e.g. the information returned from the Help command). Both of these cases are indicated by specific result codes. The entire response is terminated by a response terminator, a period (i.e., '.'), followed by a CRLF sequence.

The three-digit major result code provides a general indication of the success or failure of an issued request. The three-digit minor result code provides additional information about the major result code. For example, if the major result code were to indicate that error(s) were encountered during the execution of an issued request, the minor result code might contain a value that would be specific to the particular request that was issued. It might describe the portion of the request that failed or the step within the processing where the error was encountered. Each request has its own set of minor result code values, with some requests having no minor result code values (000) and other requests supporting a wide range of minor result code values.

The first digit of the major result code identifies the type of the response.

The second digit of the major result code identifies the category of the response.

The third digit of the major result code, taken with the second digit, identifies a specific message.

As mentioned previously, the minor result code provides additional information about a major result code and the value contained in a minor result code is specific to a particular command. The following table summarizes the major result codes supported in the exemplary embodiment.

Response Structure

The structure of a WSP response can be described as

• A result code followed by a result message, followed by a CRLF sequence.

• Zero or more lines of information, each followed by a carriage return linefeed sequence.

This information can either be text in no specific format-as is the case for the 'Help¹ command-or it can be in the form one or more result properties, which is most likely the case.

• A response terminator (crlf .'crlf). In informal terms:

Result_Code Result_Message crlf

[Text crlf] | [Result_Property crlf] period crlf

The following is a diagram of an example WSP response and all of its individual components.

The major result code above-333-indicates that the request has failed and that the failure is due to a missing required parameter specification. In this case, the minor result code does not provide any additional information. However, the result property that is returned indicates that the 'ACCOUNTID' parameter* is missing.

* Please note that a parameter is synonymous with a parameter specification. A parameter or parameter specification is often referred to by its parameter key.

Lexical Tokens The following section details descriptions of each of the requests that are available through the protocol, including a summary of each request's associated response(s).

Supported Protocol Request Specifics

Error Result Codes

A response containing any one of the following result codes can be returned from any request, depending on the supplied request format and syntax.

A response containing the following result code is returned from any request where one or more required parameters is missing. This result code is never returned unless the request requires that one or more parameter be specified.

2δ

A response containing the following result code is returned from any request where one or more required attributes is missing. This result code is never returned unless the request requires that one or more attributes be specified.

A response containing the following result code is returned from any issued request containing an invalid class:

** Within the responses containing these result codes, there may also be one or more result properties indicating the attribute or parameter responsible for the error. For example, if a session command is issued without the 'WholesalerAccountld' and 'WholesalerPassword' parameter specifications, then the following response will be returned:

333.000 Missing required parameter<crlf>

ErrorFieldl : ACCOUNTI D<crlf>

ErrorField2:PASSWORD<crlf>

.<crlf>

0.2 242.106 Failure Reasons for Orders During a lookup domain or lookup DNS hosting for a specified domain name the following reason can be given. Internal Errors are automatically escalated.

Command-Class Combinations

A list of each supported request follows, each containing a detailed specification of that request's required parameters and attributes, optional parameters and attributes, and possible responses. Result messages in italics are merely descriptions of the specific response used, for example, and are not necessarily the exact result message that will appear. '<Result Property Value>' represents some variable value that will be assigned to the corresponding result property key. The possible responses listed for each of the following requests below are in addition to the possible responses containing the result codes listed above. Session

Describe

Verify DomainName

Description This request verifies whether or not a specified

Verify Domains

Verify Password

Description This request verifies whether or not a specified customer account ID and a password are valid.

Required Parameters -CustomerAccountld -CustomerPassword

Possible Responses 240.102 Password is valid<crlf> . <crlf>

240.103 Password is invalid<crlf> . <crlf>

Create Individual Account

Create Business Account

1.1.8 Create Technical Contacr

Create Domain

3δ

Create DnsHosting

Modify Domain

invalid<crif>

.<crlf>

33δ.420 Invalid Value; TechContactld is invalid <crlf>

. <crlf>

343.301 Access denied; customer authentication failed<crlf>

. <crlf>

343.308 Access denied; not a customer of wholesaler<crlf>

. <crlf>

341.320 Customer-Domain mismatch<crlf>

. <crlf>

240.000 Domain modified<crlf>

. <crlf>

241.000 Properties returned<crlf>

TechContactld:<Result Property Value><crlf>*

. <crlf>

1.1.16 Modify Individual Account

1.1.17 Modify Business Account

1.1.18 Modify Technical Contact

4δ

1.1.19 Modify Password

1.1.23 Lookup Domain

Case 2

Description Retrieves detail information about a specific domain product registered to a customer. This form of the lookup domain command will also retrieve the status of the domain while it is being processed or after it has failed.

δ0

δ2

Lookup DNSHosting

Case 1

Description Retrieves a list of all domain names associated with DNS Hosting products owned by customer.

Required Parameters -CustomerAccountld -CustomerPassword

Possible Responses 343.301 Access denied; Customer authorization failed<crlf> .<crlf>

343.308 Access denied; not a customer of wholesaler<crlf> .<crlf>

If no DNS Hosting products have yet been registered by the customer: 240.000 Ok<crlf> .<crlf>

If one or more DNS Hosting products have been registered by the

• customer:

241.000 Properties being retumed<crlf>

DomainName1 :<Result Property

Value><crlf>

DomainName2:<ResuIt Property

Value><crlf>

.<crlf> δ3

Case 2

Description Retrieves details of a specific DNS Hosting product owned by customer. Used to verify a domain name is part of a DNS Hosting Product.

Required Parameters -CustomerAccountld -CustomerPassword -DomainName

343.308 Access denied; not a customer of wholesaler<crlf> .<crlf>

341.320 Object not found; Customer-Domain mismatch<crlf> .<crlf>

241.000 Properties being returned<crlf>

DomainName:<Result Property Value><crlf>

.<crlf>

242.1 Oδ Text being returned<crlf> Order being processed<crlf> .<crlf>

242.106 Text being returned <crlf> δ4

1.1.25 Lookup Individual Account

δδ

δ6

Lookup Technical Contact

δ7

1.1.28 Help

68

those skilled in the art will recognize that other types of architecture may be used consistent with the invention. Moreover, although the described implementation includes hardware and software, the invention may be implemented only in hardware or only in software.

Therefore, it is intended that this invention not be limited to the particular implementation and method disclosed herein, but that the invention include all implementations falling within the scope of the appended claims.

While the foregoing description is based on a client-server architecture, The foregoing description is presented for illustration and explanation. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and modifications of variations are possible in light of the above teachings or may be acquired from practice of the invention. The principles of the invention and its practical application enable one skilled in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated.

Claims

δ9WHAT IS CLAIMED:

1. A method for conducting transactions associated with managing Internet Domain Names and/or associated products comprising the steps of: establishing over the Internet a connection between a user and a registrar of Internet Domain Names; authenticating the right of the user to so request fulfillment of a transaction; establishing a secure socket layer within said connection and processing at least one command following such authentication; said command comprising an ASCII-text statement representative of the particular transaction requested by the user.

2. A method as set forth in claim 1 , further comprising the step of: notifying the user as to the processing of the command.

3. A method as set forth in claim 1 , wherein: said ASCII-text statement comprises at least a command portion optionally followed by a class portion, followed by a set of delimited key value pairs.

4. A method as set forth in claim 2, wherein: said notifying step comprises the step of returning a response to the user containing a statement indicating the fulfillment status of the transaction.

δ. A method as set forth in claim 4, wherein: said statement comprises a message which includes ASCII text portion, followed by a set of delimited key value pairs.

6. A method as set forth in claim δ, wherein: said statement further includes a numerical result code.

7. A method as set forth in claim 1 , wherein: said ASCII-text statement is selected from a predefined dictionary of statements.

8. A method as set forth in claim 4, wherein: said ASCII text portion is selected from a predefined dictionary of statements.

9. A method as set forth in claim 1 , wherein: authenticating the user is determined from the Internet Protocol address, secure socket layer encryption, and user name and password associated with the user.

10. A method as set forth in claim 1 , wherein: said authenticating step includes the step of at least one additional attempt to authenticate the user following a first failed attempt.

11. A method as set forth in claim 10, wherein: following said at least one additional attempt to authenticate the user is denied further attempts to be authenticated should said at least one additional attempt fails.

12. A system for conducting transactions associated with managing Internet Domain Names and/or associated products comprising: a client computer and a server computer forming a connection with each other via the Internet; the client computer being adapted to send to the server a command representing a requested transaction; the server computer, upon receipt of the command, authenticating the right of the user to request the transaction and, upon such authentication, establishing a secure socket layer within said connection and processing the command; said command comprising an ASCII-text statement representative of the particular transaction requested.

13. A system as set forth in claim 12, wherein: said server computer communicates notification as to the processing of the command by the client computer.

14. A system as set forth in claim 12, wherein: said ASCII-text statement comprises at least a command portion, optionally followed by a class portion, followed by a set of delimited key value pairs.

1 δ. A system as set forth in claim 13, wherein: said notification includes a response containing a statement indicating the current transaction status.

16. A system as set forth in claim 12, wherein: said statement comprises a message which includes ASCII text portion, followed by a set of delimited key value pairs.

17. A system as set forth in claim 16, wherein: said statement further includes a numerical result code and optional result message.

18. A system as set forth in claim 12, wherein: said ASCII-text statement is selected from a predefined dictionary of statements.

19. A system as set forth in claim 16, wherein: said ASCII text portion is selected from a predefined dictionary of statements.

20. A system as set forth in claim 12, wherein: authenticating the user is determined from the Internet Protocol address, secure socket layer encryption, and user name and password associated with the user communicated by the client computer.

21. A method for processing a series of commands comprising the steps of: reading each command; verifying the command to determine whether the command represents at least one of a plurality of commands acceptable for processing; placing the verified command into a queue storage; releasing the command from the queue storage for execution; ascertaining whether execution of the command was successful or not

successful; placing, at least once, the command again into queue storage if execution was not successful; and notifying the originator of the command as to the successful or unsuccessful execution of the command.

22. A method as set forth in claim 21 , wherein: each command is associated with managing Internet Domain Names and/or associated products.

23. A system for processing a series of commands comprising: means for reading each command; means for verifying the command to determine whether the command represents at least one of a plurality of commands acceptable for processing; queue storage means into which a verified command is placed; means for releasing the command from the queue storage means for execution; means for ascertaining whether execution of the command was successful or not successful; means for placing, at least once, the command again into the queue storage means if execution was not successful; and means for notifying the originator of the command as to the successful or unsuccessful execution of the command.

24. A system as set forth in claim 23, wherein: each command is associated with managing Internet Domain Names and/or associated products.