Tld markup language based domain name registering entity

CROSS REFERENCE TO RELATED PATENT APPLICATIONS

0001This patent application is related to U.S. patent application Ser. No. ______ titled: “A TLD MARKUP LANGUAGE” concurrently filed herewith and also assigned to Go Daddy Operating Company, LLC.

0002This patent application is related to U.S. patent application Ser. No. ______ titled: “CREATING AND USING A TLD MARKUP LANGUAGE” concurrently filed herewith and also assigned to Go Daddy Operating Company, LLC.

0003This patent application is related to U.S. patent application Ser. No. ______ titled: “ADDING TLD REGISTRATION CAPABILITIES TO A REGISTERING ENTITY” concurrently filed herewith and also assigned to Go Daddy Operating Company, LLC.

FIELD OF THE INVENTION

0004The present inventions generally relate to adding the capability to register a new top-level domain (TLD) at a Registrar.

SUMMARY OF THE INVENTION

0005The systems and methods disclosed herein provide for programmatically configuring a Registrar when the Registrar desires to register domain names having a new (at least for the Registrar) top-level domain (TLD) or when the business requirements for a TLD already offered by the Registrar change.

0006An exemplary system may include a database storing a plurality of electronic documents. Each electronic document may contain a plurality of business requirements for one, and only one, TLD and no two electronic documents contain business requirements for the same TLD.

0007Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document may contain a plurality of business requirements for a single TLD. An interface may be in communication with a plurality of users over a computer network. The interface may be configured to accept a new plurality of business requirements for a new TLD from one of the plurality of users. A software program running on a server may programmatically transform the new plurality of business requirements for the new TLD into a new electronic document. The software program may store the new electronic document in the electronic document database.

0008Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document, in the plurality of electronic documents, may contain business requirements for a single TLD. A user interface may be in communication with the electronic document database. The user interface may be configured to: 1) read an electronic document from the plurality of electronic documents, 2) allow the electronic document to be modified, and 3) store the modified electronic document in the electronic document database.

0009Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document, in the plurality of electronic documents, may contain business requirements for a single TLD and no two electronic documents contain business requirements for the same TLD. A user interface may be in communication with the electronic document database. The user interface may be configured to: 1) accept a plurality of new business requirements for a new TLD, 2) create a new electronic document that includes the plurality of new business requirements for the new TLD, and 3) store the new electronic document in the electronic document database.

0010Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document may contain business requirements for a single TLD. A plurality of functions within a domain name registering entity may be in communication with the electronic document database. A first function within the plurality of functions may be in communication with a first function database and a second function within the plurality of functions may be in communication with a second function database.

0011Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document may contain business requirements for one, and only one, TLD within a plurality of TLDs. A front of site software function may be in communication with the electronic document database. A website may be configured by the front of site software function to offer for registration domain names having a TLD within the plurality of TLDs.

0012Another exemplary system may include an electronic document database storing a plurality of electronic documents. Each electronic document may contain business requirements for a single TLD within a plurality of different TLDs. A plurality of web services may be in communication with the electronic document database. A website may be configured by the plurality of web services to offer for registration domain names having the plurality of different TLDs.

0013An exemplary method may start by creating a structured markup language. An electronic document may be written in the structured markup language that describes a plurality of business requirements for a TLD. The electronic document may be used to configure a system to register a plurality of domain names having the TLD. The system may receive a registration request from a Registrant for a domain name having the TLD and the system may register the domain name to the Registrant.

0014Another exemplary method may start by gathering a plurality of business requirements specific to a TLD. The TLD business requirements may be recorded in a structured markup language document. The plurality of TLD business requirements specific to the TLD in the structured markup language document may be used to configure a domain name registration system to offer for registration domain names having the TLD.

0015Another exemplary method may start by creating an electronic record that includes a plurality of business requirements for a TLD. The electronic record may be stored in a database and communicated to a plurality of functions within a domain name registration system. The plurality of functions may configure the domain name registration system to offer for registration domain names having the TLD.

0016Another exemplary method may start by storing an electronic document in a database. The electronic document may describe a plurality of TLD business requirements and be written in a structured markup language. A first software routine may receive some of the plurality of business requirements from the electronic document. The first software routine may then configure a first function within a domain name registering entity to permit the domain name registering entity to register a plurality of domain names having the TLD.

0017Another exemplary method may start by storing an electronic document, written in a structured markup language, in a database of a domain name registering entity. The electronic document may describe a plurality of TLD business requirements. A first function within the domain name registering entity may read the electronic document from the database, parse the electronic document for one or more of the plurality of TLD business requirements, and configure a first part of the domain name registering entity to permit the domain name registering entity to register a plurality of domain names having the TLD.

0018Another exemplary method may start by providing a computer interface that permits a user to select a TLD from a plurality of TLDs. The system may receive a plurality of structured markup language fragments for the selected TLD from a plurality of functions within a domain name registering entity. The plurality of structured markup language fragments may be merged (repeated sections may be ignored and incompatible sections may be flagged) into an electronic document that is displayed on the computer interface.

0019The above features and advantages of the present inventions will be better understood from the following detailed description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

0020<figref idref="DRAWINGS">FIG. 1</figref> illustrates a possible embodiment of an enhanced domain name registration system with a user interface and a database.

0021<figref idref="DRAWINGS">FIG. 2</figref> illustrates a possible embodiment of an enhanced domain name registration system with a server between the user interface and the database.

0022<figref idref="DRAWINGS">FIG. 3</figref> illustrates a possible embodiment of an enhanced domain name registration system with a first function and a first database and a second function and a second database.

0023<figref idref="DRAWINGS">FIG. 4</figref> illustrates a possible embodiment of an enhanced domain name registration system with a website and a front of site software function.

0024<figref idref="DRAWINGS">FIG. 5</figref> illustrates a possible embodiment of an enhanced domain name registration system with multiple different web services with corresponding application specific implementations (functions), a user interface web site, a TLDML merge component and a reverse TLDML function.

0025<figref idref="DRAWINGS">FIG. 6</figref> illustrates a possible embodiment of an enhanced domain name registration system with multiple functions having their own databases and a middle tier and an application stack.

0026<figref idref="DRAWINGS">FIG. 7</figref> illustrates a possible embodiment of a Registrar/domains implementation section of an enhanced domain name registration system.

0027<figref idref="DRAWINGS">FIG. 8</figref> illustrates a possible embodiment of an E-commerce implementation section of an enhanced domain name registration system.

0028<figref idref="DRAWINGS">FIG. 9</figref> illustrates a possible embodiment of a front of site (FOS) implementation section of an enhanced domain name registration system.

0029<figref idref="DRAWINGS">FIG. 10</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having a TLD.

0030<figref idref="DRAWINGS">FIG. 11</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having multiple TLDs.

0031<figref idref="DRAWINGS">FIG. 12</figref> is a flow diagram illustrating a possible embodiment of a method for reconfiguring a system to register domain names having a TLD.

0032<figref idref="DRAWINGS">FIG. 13</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having a TLD.

0033<figref idref="DRAWINGS">FIG. 14</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having a TLD and then reconfiguring the system if the business requirements for the TLD change.

0034<figref idref="DRAWINGS">FIG. 15</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a first function within a domain name registering system.

0035<figref idref="DRAWINGS">FIG. 16</figref> is a flow diagram illustrating a possible embodiment of a method for configuring multiple functions within a domain name registering system.

0036<figref idref="DRAWINGS">FIG. 17</figref> is a flow diagram illustrating a possible embodiment of a method for configuring multiple functions within a domain name registering system by each function parsing an electronic document for business requirements relevant to that function.

0037<figref idref="DRAWINGS">FIG. 18</figref> is a flow diagram illustrating a possible embodiment of a method for creating an electronic document using data from one or more functions within a domain name registering system.

0038<figref idref="DRAWINGS">FIG. 19</figref> is a flow diagram illustrating a possible embodiment of a method for creating an electronic document using data from one or more functions within a domain name registering system and then storing the electronic document in a database that stores other electronic documents.

0039<figref idref="DRAWINGS">FIG. 20</figref> is an example of an electronic document or a portion of an electronic document written in TLDML for data related to stages of a domain name.

0040<figref idref="DRAWINGS">FIG. 21</figref> is an example of an electronic document or a portion of an electronic document written in TLDML for data related to nameservers for a domain name.

0041<figref idref="DRAWINGS">FIG. 22</figref> is an example of an electronic document or a portion of an electronic document written in TLDML for data related to launch phases for a domain name.

0042<figref idref="DRAWINGS">FIGS. 23-30</figref> are an example of an electronic document written in TLDML.

DETAILED DESCRIPTION

0043The present inventions will now be discussed in detail with regard to the attached drawing figures which were briefly described above. In the following description, numerous specific details are set forth illustrating the Applicant's best mode for practicing the inventions and enabling one of ordinary skill in the art to make and use the inventions. It will be obvious, however, to one skilled in the art that the present inventions may be practiced without many of these specific details. In other instances, well-known machines, structures, and method steps have not been described in particular detail in order to avoid unnecessarily obscuring the present inventions. Unless otherwise indicated, like parts and method steps are referred to with like reference numerals.

0044A network is a collection of links and nodes (e.g., multiple computers and/or other devices connected together) arranged so that information may be passed from one part of the network to another over multiple links and through various nodes. Examples of networks include the Internet, the public switched telephone network, the global Telex network, computer networks (e.g., an intranet, an extranet, a local-area network, or a wide-area network), wired networks, and wireless networks.

0045The Internet is a worldwide network of computers and computer networks arranged to allow the easy and robust exchange of information between computer users. Hundreds of millions of people around the world have access to computers connected to the Internet via Internet Service Providers (ISPs). Content providers place multimedia information (e.g., text, graphics, audio, video, animation, and other forms of data) at specific locations on the Internet referred to as webpages. Websites comprise a collection of connected, or otherwise related, webpages. The combination of all the websites and their corresponding webpages on the Internet is generally known as the World Wide Web (WWW) or simply the Web.

0046Prevalent on the Web are multimedia websites, some of which may offer and sell goods and services to individuals and organizations. Websites may consist of a single webpage, but typically consist of multiple interconnected and related webpages. Websites, unless extremely large and complex or have unusual traffic demands, typically reside on a single server and are prepared and maintained by a single individual or entity. Menus and links may be used to move between different webpages within the website or to move to a different website. The interconnectivity of webpages enabled by the Internet can make it difficult for Internet users to tell where one website ends and another begins.

0047Websites may be created using HyperText Markup Language (HTML) to generate a standard set of tags that define how the webpages for the website are to be displayed. Users of the Internet may access content providers' websites using software known as an Internet browser, such as MICROSOFT INTERNET EXPLORER or MOZILLA FIREFOX. After the browser has located the desired webpage, it requests and receives information from the webpage, typically in the form of an HTML document, and then displays the webpage content for the user. The user then may view other webpages at the same website or move to an entirely different website using the browser.

0048Browsers are able to locate specific websites because each website, resource, and computer on the Internet has a unique Internet Protocol (IP) address. Presently, there are two standards for IP addresses. The older IP address standard, often called IP Version 4 (IPv4), is a 32-bit binary number, which is typically shown in dotted decimal notation, where four 8-bit bytes are separated by a dot from each other (e.g., 64.202.167.32). The notation is used to improve human readability. The newer IP address standard, often called IP Version 6 (IPv6) or Next Generation Internet Protocol (IPng), is a 128-bit binary number. The standard human readable notation for IPv6 addresses presents the address as eight 16-bit hexadecimal words, each separated by a colon (e.g., 2EDC:BA98:0332:0000:CF8A:000C:2154:7313).

0049IP addresses, however, even in human readable notation, are difficult for people to remember and use. A Uniform Resource Locator (URL) is much easier to remember and may be used to point to any computer, directory, or file on the Internet. A browser is able to access a website on the Internet through the use of a URL. The URL may include a Hypertext Transfer Protocol (HTTP) request combined with the website's Internet address, also known as the website's domain name. An example of a URL with a HTTP request and domain name is: http://www.companyname.com. In this example, the “http” identifies the URL as a HTTP request and the “companyname.com” is the domain name.

0050Domain names are much easier to remember and use than their corresponding IP addresses. The Internet Corporation for Assigned Names and Numbers (ICANN) approves some Generic Top-Level Domains (gTLD) and delegates the responsibility to a particular organization (a “registry”) for maintaining an authoritative source for the registered domain names within a TLD and their corresponding IP addresses. For certain TLDs (e.g., .biz, .info, .name, and .org) the registry is also the authoritative source for contact information related to the domain name and is referred to as a “thick” registry. For other TLDs (e.g., .com and .net) only the domain name, registrar identification, and name server information is stored within the registry, and a registrar is the authoritative source for the contact information related to the domain name. Such registries are referred to as “thin” registries. Most gTLDs are organized through a central domain name Shared Registration System (SRS) based on their TLD.

0051The process for registering a domain name with .com, .net, .org, and some other TLDs allows an Internet user to use an ICANN-accredited Registrar to register their domain name. For example, if an Internet user, John Doe, wishes to register the domain name “mycompany.com,” John Doe may initially determine whether the desired domain name is available by contacting a domain name registrar. The Internet user may make this contact using the registrar's webpage and typing the desired domain name into a field on the registrar's webpage created for this purpose. Upon receiving the request from the Internet user, the registrar may ascertain whether “mycompany.com” has already been registered by checking the SRS database associated with the TLD of the domain name. The results of the search then may be displayed on the webpage to thereby notify the Internet user of the availability of the domain name. If the domain name is available, the Internet user may proceed with the registration process. Otherwise, the Internet user may keep selecting alternative domain names until an available domain name is found. Domain names are typically registered for a period of one to ten years with first rights to continually re-register the domain name.

0052One problem often encountered in registering domain names is that the desired domain name has already been registered to another registrant. To help with the scarcity of domain names, additional TLDs may be added to the domain name registration system. For example, generic top-level domains (gTLD) may be added to the domain name system from time-to-time to help with this problem. Another solution is to allow people (or businesses) to register new TLDs. For example, Go Daddy Operating Company, LLC may desire to register .godaddy as a new TLD. Either method of adding new TLDs greatly expands the number of possible domain names that may be registered.

0053The addition of new TLDs requires domain name registering entities (typically Registrars and their resellers, but includes any entity that can register a domain name) to update many of their internal functions to allow registrants to register domain names having the new TLDs.

0054A large part of the difficulty in adding new TLDs is that each TLD may (and usually does) have unique business requirements. As non-limiting examples, the business requirements for a TLD may include whether the thick or thin Registry model is being used, minimum and maximum registration periods, valid registration periods, length of any registration grace periods, billing requirements, domain name transfer requirements, auto renewal requirements, reseller information, and so on. Each TLD may have its own combination of business requirements that must be correctly handled by the domain name registering entity.

0055The present invention is much more efficient at launching new TLDs and in handling changes to existing TLDs. Prior methods of hard coding or storing across multiple databases, without having an authoritative or prime database, business requirements for TLDs can make changes to the system very time consuming and difficult. On the other hand, the present invention provides a means for updating a single source, such as an electronic document stored in a database, and then the system propagating the business requirements to one or more functions within the domain name registering entity that then programmatically configure the Registrar to properly handle the new TLD or changes to existing TLDs.

0056The efficiency in adding new TLDs and reconfiguring for existing TLDs is very important as new TLDs are being added at an ever increasing pace. As domain name registering entities add TLDs with business requirements that conflict with business requirements for existing TLDs, the complexity of the domain name registering entity could grow exponentially unless a scalable solution, such as the present invention, is implemented. It is important for the domain name registering entity to keep a streamlined on-boarding process, and thus a low time to market, as new TLDs are added to its offered products.

0057The present invention provides greater control over TLD behavior. The quantity, variety, and complexity of TLDs under management by a domain name registering entity are greatly benefited by a strong control structure. The present invention may simplify making changes to the domain name registering entity, determining which TLD business rules are currently in effect and even adding entirely new TLD business rules. Certain embodiments of the present invention also make it easier for nontechnical employees to access the TLD business rules, thereby freeing developers from this task and allowing a greater number of employees (for example, marketing, project managers, customer service, etc.) of the domain name registering entity to access the business rules for TLDs currently being used.

0058Some embodiments of the present invention may use a Top-Level Domain Markup Language (TLDML). TLDML is a markup language that describes the attributes and business rules for a top-level domain. Unlike Extensible Markup Language (XML), TLDML is preferably a strictly defined markup language where every tag has a pre-defined meaning Tags are preferably not introduced unless their meaning is first clearly defined. Similar to how HTML instructs a browser how to render a page to an end user, TLDML instructs a domain name registering entity how to manage a top-level domain subject to the registry's requirements. A TLD's business rules will typically include many, if not all, of the registry's requirements. In some embodiment, the TLDML may also describe attributes specifically determined by the domain name registering entity in offering the TLD. A Registrar may create the format and specify the data points that will be captured in a TLDML document.

0059Non-limiting examples of TLDMLs documents (or portions of documents) are shown in <figref idref="DRAWINGS">FIGS. 7</figref>, <b>8</b>, <b>9</b>, <b>20</b>, <b>21</b>, <b>22</b>, and <b>23</b>.

0060<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example system that may quickly be updated to allow the registration of new TLDs. A Registrar <b>100</b> is illustrated in <figref idref="DRAWINGS">FIGS. 1-4</figref> because a Registrar <b>100</b> is the most likely user of the present invention. However, it should be appreciated that the Registrar <b>100</b> in <figref idref="DRAWINGS">FIGS. 1-4</figref> may be replaced by any domain name registering entity. For purposes of this invention, a domain name registering entity should be broadly construed as any entity that is capable of registering a domain name to a registrant.

0061The Registrar <b>100</b> may include a database <b>101</b> (also referred to as an electronic document database). The database <b>101</b>, as non-limiting examples, may be a central, distributed, flat, hierarchical, network, relational, object-oriented or any other type of database now known or developed in the future. The database <b>101</b> may store one or more electronic documents used as part of this invention. Three electronic documents (A <b>102</b>, B <b>104</b>, and C <b>106</b>) are illustrated in <figref idref="DRAWINGS">FIGS. 1-4</figref> as an example of one possible configuration.

0062The electronic documents <b>102</b>, <b>104</b>, <b>106</b> may be stored in any data format, such as in files, electronic records or any other data structures now known or discovered in the future. The electronic documents <b>102</b>, <b>104</b>, <b>106</b> may be written in any language. However, the electronic documents are preferably written in a structured markup language and are most preferably written in TLDML.

0063While an electronic document <b>102</b>, <b>104</b>, <b>106</b> may contain business requirements for more than one TLD, in preferred embodiments each electronic document <b>102</b>, <b>104</b>, <b>106</b> contains data representing the business requirements <b>103</b>, <b>105</b>, <b>107</b> for one, and only one, TLD. It is also preferred that no two electronic documents <b>102</b>, <b>104</b>, <b>106</b> contain business requirements <b>103</b>, <b>105</b>, <b>107</b> for the same TLD. Thus in the most preferred embodiments, each electronic document <b>102</b>, <b>104</b>, <b>106</b> contains business requirements <b>103</b>, <b>105</b>, <b>107</b> for a single unique TLD. Fewer or more electronic documents <b>102</b>, <b>104</b>, <b>106</b> may be subtracted or added as needed from that illustrated in <figref idref="DRAWINGS">FIGS. 1-4</figref>. In preferred embodiments, there will be one electronic document <b>102</b>, <b>104</b>, <b>106</b> for each TLD offered for registration by the Registrar <b>100</b>. The database <b>101</b> may store more data than just the electronic documents <b>102</b>, <b>104</b>, <b>106</b> if so desired by the Registrar <b>100</b>.

0064In another embodiment, electronic documents <b>102</b>, <b>104</b>, <b>106</b> contain business requirements <b>103</b>, <b>105</b>, <b>107</b> for one, and only one, second level domain (SLD). For example, each electronic document <b>102</b>, <b>104</b>, <b>106</b> may store business requirements for the SLDs com.au, net.au, and org.au. In another embodiment, one or more electronic documents <b>102</b>, <b>104</b>, <b>106</b> may contain the business requirements <b>103</b>, <b>105</b>, <b>107</b> for a TLD, while one or more other electronic documents <b>102</b>, <b>104</b>, <b>106</b> store business requirements <b>103</b>, <b>105</b>, <b>107</b> for a SLD.

0065In another embodiment, a Registrar <b>100</b> may support two or more intermediary proxy registration providers. If the two or more intermediary proxy registration providers have different business requirements, it may be desirable for the Registrar <b>100</b> to have one electronic document (storing business requirements for one TLD) for each proxy registration. So if a Registrar <b>100</b> had three intermediary proxy registration providers, the Registrar would have three electronic documents <b>102</b>, <b>104</b>, <b>106</b>. Each of the three electronic documents <b>102</b>, <b>104</b>, <b>106</b> would store business requirements for the same TLD, but for different intermediary proxy registration providers. This may be scaled so the Registrar <b>100</b> may support any number of TLDs desired by creating additional electronic documents <b>102</b>, <b>104</b>, <b>106</b> for any number of intermediary proxy registration providers.

0066A user interface <b>108</b> (or computer interface) may be provided that is in communication with a plurality of users <b>109</b>, <b>110</b>, <b>111</b> over a computer network, such as the Internet. Users <b>109</b>, <b>110</b>, <b>111</b> may communicate with the user interface <b>108</b> through, for example, an API or other network protocol. The Registrar <b>100</b> may use the user interface <b>108</b> to receive an electronic document D <b>110</b> (containing business requirements) from a user <b>109</b>. If the electronic document is already in the desired format, it may be stored in database <b>101</b>. Otherwise, the electronic document may be edited to the desired format before storing the electronic document D in the database <b>101</b>. This is one possible method for the Registrar to receive business requirements for a TLD. The business requirements may be for a new TLD (a TLD not previously offered by the Registrar <b>100</b>) or an existing TLD (a TLD already offered by the Registrar <b>100</b>) having updated business requirements.

0067<figref idref="DRAWINGS">FIG. 2</figref> illustrates another embodiment where the Registrar <b>100</b> may receive data for a new electronic document D <b>110</b> from user A <b>109</b>. If only data is being provided by user A <b>109</b>, the user interface <b>108</b> may have fields, pull down menus, etc. that allow user A <b>109</b> to easily and efficiently enter the data. The user interface <b>108</b> may also be constructed to allow a file containing the data to be received by the user interface <b>108</b>. A server <b>200</b> (in communication with the user interface <b>108</b> and the database <b>101</b>) may be used to convert the data into an electronic document in the desired format or language before storing the electronic document into the database <b>101</b>.

0068In another embodiment, the user interface <b>108</b> and/or the server <b>200</b> are configured to: 1) read an electronic document A <b>102</b> from the plurality of electronic documents A <b>102</b>, B <b>104</b>, C <b>106</b>, 2) programmatically allow the electronic document A <b>102</b> to be modified, and then 3) store the modified electronic document A <b>102</b> back into the electronic document database <b>101</b>.

0069In another embodiment, the user interface <b>108</b> may be configured with the server <b>200</b> to: 1) accept a plurality of new business requirements for a new TLD, 2) create a new electronic document that includes the plurality of new business requirements for the new TLD, and 3) store the new electronic document in the electronic document database <b>101</b>. The creation of the new electronic document may be accomplished by a software program that runs on one or more servers <b>200</b> in the Registrar <b>100</b>. The software program may take the business requirements and create the new electronic document in the desired format or language (such as TLDML) and then store the electronic document in the database <b>101</b>.

0070<figref idref="DRAWINGS">FIG. 3</figref> illustrates another embodiment of the invention. A Registrar <b>100</b> may be organized into a plurality of different application specific implementations (functions). As non-limiting examples, these functions may be a domain name registration function, a front of site (FOS) function, an e-commerce function, an internal apps function, and/or a domain control center function. The FOS function may be responsible for displaying and handling the exchange of information between the users A <b>109</b>, B <b>110</b>, C <b>111</b> and the website <b>401</b>.

0071These particular functions are not necessarily required for the present invention, may be organized into different functions and/or additional functions may be added or combined as desired. Whichever functions are used by the Registrar <b>100</b> (represented by Function1 <b>300</b> and Function2 <b>302</b> in <figref idref="DRAWINGS">FIG. 3</figref>), the functions are preferably in communication with the electronic document database <b>101</b>. A plurality of web services may be used to facilitate communication between the various functions and the database <b>101</b>.

0072This embodiment illustrates that one or more of the functions may have a separate database (represented by Database1 <b>301</b> in communication with Function1 <b>300</b> and Database2 <b>303</b> in communication with Function2 <b>302</b>) in which to store data. In a preferred embodiment, Function1 <b>300</b> cannot access database2 <b>303</b> and Function2 <b>302</b> cannot access database1 <b>301</b>.

0073<figref idref="DRAWINGS">FIG. 4</figref> illustrates a possible embodiment of an enhanced domain name registration system (Registrar <b>100</b>) with a Website <b>401</b> and a front of site software function <b>400</b>. The front of site software function <b>400</b> may be in communication with the electronic document database <b>101</b> to be able to receive electronic documents <b>102</b>, <b>104</b>, <b>106</b> containing the business requirements <b>103</b>, <b>105</b>, <b>107</b> for a plurality of TLDs. The front of site software function <b>400</b> may then programmatically configure the website <b>401</b> according to the received business requirements to allow users A <b>109</b>, B <b>110</b>, C <b>111</b> to register domain names having the plurality of TLDs.

0074<figref idref="DRAWINGS">FIG. 6</figref> illustrates a possible embodiment of an enhanced domain name registration system with a middle tier <b>601</b>, an application stack <b>602</b>, multiple web services <b>603</b> and functions having their own databases <b>600</b>. A web site survey <b>605</b> may be used to view, edit, enter data, or enter a TLDML XML document <b>604</b>. A TLDML web site manager <b>606</b> may be used to manage the flow of the TLDML XML document <b>604</b> between the web site survey <b>605</b>, the TLDML data storage <b>607</b> and the web services <b>603</b> and functions within the domain name registering entity. The TLDML XML document <b>604</b> may be stored in the TLDML data storage <b>607</b>.

0075When a TLDML XML document is created or changed it may be pushed by the TLDML web site manager <b>606</b> to the web services <b>603</b> and functions. Alternatively, the web services <b>603</b> and functions may pull the TLDML XML document from the TLDML web site manager <b>606</b> which may retrieve the TLDML XML document <b>604</b> from the TLDML data storage <b>607</b>. Alternatively, the web services <b>603</b> may call a TLDMS web service to retrieve the TLDML XML document. In another embodiment, the web services <b>603</b> may not be web services at all, but services supported within the domain name registering entity <b>100</b>.

0076Direct links between gdTLDMLWebSvc and the appropriate data stores are illustrated. For example, the gdTLDMLWebSvc hosted by a registrar team may have a direct link to the domains database, the web service hosted by e-commerce may have a direct link to the e-commerce database, and the “other” team implementation is left as a place holder to illustrate how other teams that own authoritative data may onboard with a TLDML document for their function.

0077As data becomes updated in places of authority, as seen in the diagram, the new values may be promoted to the middle tier, and eventually the application stack. In this example architecture, TLDML documents will always cause data to be updated in places of authority in order to promote a trickledown effect.

0078<figref idref="DRAWINGS">FIG. 7</figref> illustrates a possible embodiment of a Registrar implementation <b>701</b> function of an enhanced domain name registration system. In this embodiment, the Registrar implementation <b>701</b> may take a TLDML document <b>700</b> and parse (shred) the document to create a new document <b>702</b> that contains only the business requirements relevant to the Registrar implementation <b>701</b>. The new document may then be stored in a domains database <b>703</b> for quick access by the Registrar implementation <b>701</b>. While creating a new document <b>702</b> is not mandatory (the TLDML document <b>700</b> could be stored in the domains database <b>703</b> as is), it is helpful in that less information has to be stored and the new document <b>702</b> is easier and faster for the Registrar implementation <b>701</b> to search.

0079<figref idref="DRAWINGS">FIG. 8</figref> illustrates a possible embodiment of an e-commerce implementation <b>801</b> function of an enhanced domain name registration system. In this embodiment, the e-commerce implementation <b>801</b> may take a TLDML document <b>800</b> and parse (shred) the document to create a new document <b>802</b> that contains only business requirements relevant to the e-commerce implementation <b>801</b>. The new document may then be stored in an e-commerce database <b>803</b> for quick access by the e-commerce implementation <b>801</b>. While creating a new document <b>802</b> is not mandatory (the TLDML document <b>800</b> could be stored in the e-commerce database <b>803</b> as is), it is helpful in that less information has to be stored and the new document <b>802</b> is easier and faster for the E-Commerce implementation <b>801</b> to search.

0080<figref idref="DRAWINGS">FIG. 9</figref> illustrates a possible embodiment of a front of site (FOS) implementation <b>901</b> of an enhanced domain name registration system. In this embodiment, the FOS implementation <b>901</b> may take a TLDML document <b>900</b> and parse (shred) the document to create a new document <b>902</b> that contains only business requirements relevant to the FOS Implementation <b>901</b>. The new document may then be stored in the FOS database <b>903</b> for quick access by the FOS implementation <b>901</b>. While creating a new document <b>902</b> is not mandatory (the TLDML document <b>900</b> could be stored in the FOSS data store <b>903</b> as is), it is advantageous in that less information has to be stored and the new document <b>902</b> is easier and faster for the FOS Implementation <b>901</b> to search.

0081While the embodiments illustrated in <figref idref="DRAWINGS">FIGS. 7-9</figref> have been explained with a TLDML document (the preferred format), an electronic document or a structured markup language document may also be used.

0082<figref idref="DRAWINGS">FIG. 10</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a domain name registering entity to register domain names having a TLD. In this embodiment, a format for the electronic documents <b>102</b>, <b>104</b>, <b>106</b> is created. The format may be a structured markup language such as a TLDML. (Step <b>1000</b>) The step of creating a structured markup language generally only needs to be completed once (preferably by the Registrar <b>100</b>), since all future TLDs may use the same structured markup language to write their electronic documents.

0083An electronic document A <b>102</b>, written in the created format or language, may be constructed or received that describes a plurality of business requirements A <b>103</b> for a top-level domain (TLD). (Step <b>1001</b>) The electronic document A <b>102</b> may be constructed from business requirements A <b>103</b> entered by user A <b>109</b> via the user interface <b>108</b> or an API (Website <b>401</b>). One or more servers <b>200</b> may be used to turn the business requirements A <b>103</b> into an electronic document A <b>102</b> having the created format or language. Alternatively, an electronic document D <b>110</b> may be received from a user A <b>109</b> via the user interface <b>108</b> or API (Website <b>401</b>) already in the created format or language.

0084The electronic document A <b>102</b> once created, may be considered the authoritative source in the Registrar <b>100</b> for the plurality of business requirements A <b>103</b> for the TLD. Example electronic documents A <b>102</b>, B <b>104</b>, C <b>106</b> are illustrated in <figref idref="DRAWINGS">FIG. 7</figref> as <b>700</b>, in <figref idref="DRAWINGS">FIG. 8</figref> as <b>800</b>, in <figref idref="DRAWINGS">FIG. 9</figref> as <b>900</b>, and in <figref idref="DRAWINGS">FIGS. 20-23</figref>.

0085The user <b>109</b> may be an employee of the domain name registering entity or Registrar <b>100</b>, the employee of a Registry or an employee of a registrant (owner) of the TLD. In any event, the user <b>109</b> is preferably a trusted source for providing business requirements (or an electronic document D <b>110</b>) for the TLD.

0086The created or received electronic document A <b>102</b> may be used to configure a system (such as a domain name registering entity or a Registrar <b>100</b>) to register a plurality of domain names having the TLD. (Step <b>1002</b>) Once the system is configured, domain names having the TLD may be registered to one or more registrants. (Step <b>1003</b>)

0087<figref idref="DRAWINGS">FIG. 11</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a Registrar <b>100</b> to register domain names having multiple TLDs. This illustrated embodiment is similar to the embodiment illustrated in <figref idref="DRAWINGS">FIG. 10</figref>, but adds the additional steps of receiving business requirements for a TLD (Step <b>1100</b>) and storing a constructed electronic document A <b>102</b> for the TLD in a database <b>101</b> (Step <b>1101</b>). As in the embodiment illustrated in <figref idref="DRAWINGS">FIG. 10</figref>, the Registrar <b>100</b> may then be programmatically configuring to register domain names having the TLD (Step <b>1002</b>). These steps (<b>1100</b>, <b>1001</b>, <b>1101</b>, <b>1002</b>) may be repeated for any number of additional TLDs desired to be registered by the Registrar <b>100</b>. (Step <b>1102</b>) For example, if the Registrar <b>100</b> wanted to register domain names having the TLDs of .com and .org, the process may be completed twice, once using the business requirements for .com and once using the business requirements for .org. In this manner, the Registrar <b>100</b> may be efficiently configured to register both TLDs. In addition, if the Registrar <b>100</b> wishes to register domain names having different TLDs at a later date, the process may be repeated at any time using the business requirements for those additional TLDs.

0088<figref idref="DRAWINGS">FIG. 12</figref> is a flow diagram illustrating a possible embodiment of a method for programmatically reconfiguring a system to register domain names having a TLD. One of the advantages of the present invention is that it allows a Registrar <b>100</b> to be easily updated when the business requirements for a TLD change. The first step is for the Registrar <b>100</b> to receive the updated business requirements for the TLD that is already being offered for registration. (Step <b>1200</b>) The updated business requirements may be received, for example, via a user interface <b>108</b>, website <b>401</b>, API or any other method known or discovered in the future. The Registrar <b>100</b> may update the electronic document associated with the TLD, either by modifying the old electronic document or by creating a new electronic document (Step <b>1201</b>), and then storing the updated electronic document back into the database <b>101</b> (Step <b>1202</b>). Preferably, the electronic document should be for one, and only one, TLD and no two electronic documents in the database <b>101</b> should be for the same TLD. The Registrar <b>100</b> may then be reconfigured to reflect the business requirements in the updated electronic document. (Step <b>1203</b>)

0089<figref idref="DRAWINGS">FIG. 13</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having a TLD. This embodiment adds to the embodiment of <figref idref="DRAWINGS">FIG. 12</figref> by enabling a computer interface, user interface <b>108</b>, website <b>401</b> or API to allow a user A <b>109</b> to view and edit the electronic document A <b>102</b> associated with the TLD in the plurality of electronic documents A <b>102</b>, B <b>104</b>, C <b>106</b> in the database <b>101</b>. (Step <b>1300</b>) This greatly simplifies the process for updating and reconfiguring the Registrar <b>100</b>.

0090<figref idref="DRAWINGS">FIG. 14</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a system to register domain names having a TLD and then reconfiguring the system if the business requirements for the TLD change. In this embodiment the business requirements A <b>103</b> for a TLD are gathered or received, preferably as described above for <figref idref="DRAWINGS">FIG. 13</figref>. (Step <b>1100</b>) The gathered TLD business requirements A <b>103</b> may be recorded or written into an electronic document A <b>102</b>, such as a structured markup language document or a TLDML document <b>900</b>, and then stored in a database <b>101</b>. (Step <b>1400</b>) The Registrar <b>100</b> may be programmatically configured using the business requirements A <b>103</b> recorded in the electronic document A <b>102</b>. (Step <b>1401</b>) If the business requirements A <b>103</b> for the TLD subsequently change, the electronic document A <b>102</b> may be updated to reflect the new business requirements for the TLD (Step <b>1402</b>) and then stored back into the database <b>101</b> (Step <b>1403</b>). The updated electronic document A <b>102</b> may then be used to reconfigure the Registrar <b>100</b> (Step <b>1404</b>) to allow domain names having the TLD (with the updated business requirements) to once again be registered by the Registrar <b>100</b>.

0091<figref idref="DRAWINGS">FIG. 15</figref> is a flow diagram illustrating a possible embodiment of a method for configuring a first function within a Registrar <b>100</b>. As in other embodiments, business requirements for a TLD may be gathered or received in any manner previously mentioned, known or discovered in the future. (Step <b>1100</b>) An electronic document A <b>102</b> may be created or received that includes the business requirements A <b>103</b> for a TLD. (Step <b>1500</b>) The electronic document A <b>102</b> may be stored in a database <b>101</b>. (Step <b>1501</b>) The electronic document A <b>102</b> may be pushed to, or pulled from, function1 <b>300</b> within the Registrar <b>100</b>. (<b>1502</b>) Function1 <b>300</b> may be any function performed by the Registrar <b>100</b> that uses business requirements A <b>103</b> of the TLD to perform its purpose. As non-limiting examples, function1 <b>300</b> may be to operate the front of site, perform registration of domain names or complete e-commerce transactions. Function1 <b>300</b>, having received the business requirements A <b>103</b> for the TLD, may then configure its area of responsibility within the Registrar <b>100</b>. (Step <b>1503</b>) The Registrar <b>100</b> may be updated as TLD business requirements change as described in previous embodiments.

0092<figref idref="DRAWINGS">FIG. 16</figref> is a flow diagram illustrating a possible embodiment of a method for configuring multiple application specific implementations <b>508</b>-<b>512</b> (functions) within a Registrar <b>100</b>. This embodiment is similar to the embodiment discussed in relation to <figref idref="DRAWINGS">FIG. 15</figref>, but the electronic document A <b>102</b> may be pushed to, or pulled by, a plurality of functions, such as function1 <b>300</b> and function2 <b>302</b>, within the Registrar <b>100</b> from a database <b>101</b>. (Step <b>1600</b>) In preferred embodiments, every function within the Registrar <b>100</b> that uses business requirements A <b>103</b> for TLDs will receive the electronic document A <b>102</b>. For example, an electronic document A <b>102</b> containing the business requirements for .com may be pushed to or pulled by the functions of operating the front of site, performing registration of domain names and completing e-commerce transactions. At the same or different times, a different electronic document B <b>104</b> containing the business requirements B <b>105</b> for .org may be pushed to or pulled by the same functions of operating the front of site, performing registration of domain names and completing e-commerce transactions. These functions may be programmatically configured (and thus the Registrar <b>100</b>) via software according to the business requirements A <b>103</b>, B <b>105</b> in the electronic documents A <b>102</b>, B <b>104</b> respectively. (Step <b>1601</b>) In this manner, all the functions within a Registrar <b>100</b> may receive all the business requirements for all of the TLDs being offered by the Registrar <b>100</b>. As in other embodiments, if the electronic documents A <b>102</b>, B <b>104</b> are updated, the functions may programmatically reconfigure themselves (and thus the Registrar <b>100</b>) via software according to the business requirements in the updated electronic document(s).

0093A Registrar <b>100</b> may be logically broken down into any number of different functions and this invention should not be limited by the number or the specific functions selected within the Registrar <b>100</b>.

0094<figref idref="DRAWINGS">FIG. 17</figref> is a flow diagram illustrating a possible embodiment of a method for configuring multiple functions within a domain name registering system by each function parsing an electronic document for business requirements relevant for that function. This embodiment is similar to the embodiment explained in regards to <figref idref="DRAWINGS">FIG. 16</figref>, but includes the added steps of the functions parsing the electronic documents for the specific business requirements the functions requires (which may vary from function to function) (Step <b>1700</b>). Each function may use its parsed business requirements to configure itself (and thereby configure the Registrar <b>100</b>). (Step <b>1701</b>) For example, function1 <b>300</b> may store the electronic document A <b>102</b> in database 1 <b>301</b>, but preferably stores only the parsed business requirements needed by function1 <b>300</b>. Likewise, function2 <b>302</b> may store the electronic document A <b>102</b> in database2 <b>303</b>, but preferably stores only the parsed business requirements needed by function2 <b>302</b> which may be substantially different than the parsed business requirements needed by function1 <b>300</b>.

0095<figref idref="DRAWINGS">FIG. 5</figref> illustrates a possible embodiment of an enhanced domain name registration system with multiple different web services <b>503</b>-<b>507</b> with corresponding application specific implementations <b>508</b>-<b>512</b> (also referred to as functions), a user interface web site <b>500</b>, a TLDML merge component <b>501</b> and a reverse TLDML <b>502</b> function. <figref idref="DRAWINGS">FIG. 18</figref> is a flow diagram illustrating a possible embodiment of a method for creating an electronic document using data from one or more functions within a domain name registering system. It may be desirable to see what business requirements are currently being used by a Registrar <b>100</b> for a particular TLD or even for multiple TLDs. The embodiments illustrated in <figref idref="DRAWINGS">FIGS. 5 and 18</figref> assist a user A <b>109</b> in determination which business requirements are currently being used by the Registrar <b>100</b> as will now be described.

0096A user interface web site <b>500</b> may be provided to allow a user A <b>109</b> to select a TLD from a plurality of TLDs. (Step <b>1800</b>) The selected TLD is the TLD that the user A <b>109</b> wishes to see the business requirements for the TLD that are currently being used. A reverse TLDML <b>502</b> may ask one or more application specific implementations <b>508</b>-<b>512</b> (functions) via their corresponding TLDML web services <b>503</b>-<b>507</b> which business requirements they are using.

0097The application specific implementations <b>508</b>-<b>512</b> may respond, via their TLDML web services <b>503</b>-<b>507</b>, to the reverse TLDML <b>502</b> with the business requirements that each application specific implementation <b>508</b>-<b>512</b> is using. (Step <b>1801</b>) For example, the reverse TLDML <b>502</b> may receive a plurality of structured markup language fragments (or an entire electronic document) for the TLD from the one or more application specific implementations <b>508</b>-<b>512</b> (functions) within the Registrar <b>100</b>.

0098The TLDML merge component <b>501</b> may use the information retrieved by the reverse TLDML <b>502</b> to create an electronic document showing the business requirements currently being used by a Registrar <b>100</b> for the selected TLD by merging or combining the information together. (Step <b>1802</b>) Duplicate information may be ignored, while conflicting information may be flagged as a possible problem in the electronic document.

0099The electronic document may then be displayed for the user A <b>109</b> on the user interface web site <b>500</b>. (Step <b>1803</b>) For this embodiment, the electronic document may be in a human readable format (such as plain text or data within fields provided on the user interface web site <b>500</b>) since the electronic document is primarily for human consumption and interaction.

0100<figref idref="DRAWINGS">FIG. 19</figref> is a flow diagram illustrating a possible embodiment of a method for creating an electronic document using data from one or more functions within a domain name registering system and then storing the electronic document in a database that stores other electronic documents. This embodiment is an enhancement to the embodiments illustrated in <figref idref="DRAWINGS">FIGS. 5 and 18</figref>. User A <b>109</b> may edit the electronic document being displayed on the user interface web site <b>500</b>. (Step <b>1900</b>) The electronic document may then be stored in a database <b>101</b> if the user A <b>109</b> has permission and desires to do so. (Step <b>1901</b>) The Registrar <b>100</b>, by either pushing the electronic record to the plurality of functions within the domain name registration system or by the plurality of functions within the domain name registration system pulling the electronic record, may then be programmatically reconfigured to reflect the edited electronic document.

0101<figref idref="DRAWINGS">FIG. 20</figref> is an example of a portion of an electronic document, an extended markup language document, a TLDML document and a TLDML XML document for data related to stages within the life cycle of a domain name. The illustrated electronic document could be stored in a database <b>101</b> and used by a Registrar <b>100</b> to configure (or reconfigure) the Registrar's various functions.

0102<figref idref="DRAWINGS">FIG. 21</figref> is an example of a portion of an electronic document, an extended markup language document, a TLDML document and a TLDML XML document for data related to nameservers for a domain name. The illustrated electronic document could be stored in a database <b>101</b> and used by a Registrar <b>100</b> to configure (or reconfigure) the Registrar's various functions.

0103<figref idref="DRAWINGS">FIG. 22</figref> is an example of a portion of an electronic document, an extended markup language document, a TLDML document and a TLDML XML document for data related to launch phases for a domain name. The illustrated electronic document could be stored in a database <b>101</b> and used by a Registrar <b>100</b> to configure (or reconfigure) the Registrar's various functions.

0104<figref idref="DRAWINGS">FIG. 23</figref> is an example of an electronic document, an extended markup language document, a TLDML document and a TLDML XML document storing the business requirements for a specific TLD. The illustrated electronic document could be stored in a database <b>101</b> and used by a Registrar <b>100</b> to configure (or reconfigure) the Registrar's various functions.

0105Other embodiments and uses of the above inventions will be apparent to those having ordinary skill in the art upon consideration of the specification and practice of the inventions disclosed herein. The specification and examples given should be considered exemplary only, and it is contemplated that the appended claims will cover any other such embodiments or modifications as fall within the true scope of the inventions.

0106While the business requirements for a TLD have been described as stored in a TLDML XML document, TLDML document, extended markup language document, electronic document, file, record or data in a database in various embodiments (and are generally preferred in that order), it should be noted that the methods are interchangeable and each described embodiment in this specification should be considered as teaching all of these formats and languages of storing business requirements for TLDs. Further, a Registrar <b>100</b> has been used in many embodiments, but it should be noted that any domain name registering entity may be used in place of the Registrar <b>100</b> used in the described embodiments within this specification.

0107The Abstract accompanying this specification is provided to enable the United States Patent and Trademark Office and the public generally to determine quickly from a cursory inspection the nature and gist of the technical disclosure and in no way intended for defining, determining, or limiting the present inventions or any of its embodiments.