Patent Application
20180150460
The present inventions generally relate to adding the capability to register a new top-level domain (TLD) at a Registrar.
The 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.
An 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.
Another 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.
Another 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.
Another 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.
Another 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.
Another 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.
Another 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.
An 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.
Another 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.
Another 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.
Another 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.
Another 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.
Another 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.
The above features and advantages of the present inventions will be better understood from the following detailed description taken in conjunction with the accompanying drawings.
The 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.
A 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.
The 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.
Prevalent 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.
Websites 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.
Browsers 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).
IP 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.
Domain 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.
The 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.
One 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.
The 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.
A 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.
The 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.
The 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.
The 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.
Some 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.
Non-limiting examples of TLDMLs documents (or portions of documents) are shown in
The Registrar 100 may include a database 101 (also referred to as an electronic document database). The database 101, 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 101 may store one or more electronic documents used as part of this invention. Three electronic documents (A 102, B 104, and C 106) are illustrated in
The electronic documents 102, 104, 106 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 102, 104, 106 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.
While an electronic document 102, 104, 106 may contain business requirements for more than one TLD, in preferred embodiments each electronic document 102, 104, 106 contains data representing the business requirements 103, 105, 107 for one, and only one, TLD. It is also preferred that no two electronic documents 102, 104, 106 contain business requirements 103, 105, 107 for the same TLD. Thus in the most preferred embodiments, each electronic document 102, 104, 106 contains business requirements 103, 105, 107 for a single unique TLD. Fewer or more electronic documents 102, 104, 106 may be subtracted or added as needed from that illustrated in
In another embodiment, electronic documents 102, 104, 106 contain business requirements 103, 105, 107 for one, and only one, second level domain (SLD). For example, each electronic document 102, 104, 106 may store business requirements for the SLDs com.au, net.au, and org.au. In another embodiment, one or more electronic documents 102, 104, 106 may contain the business requirements 103, 105, 107 for a TLD, while one or more other electronic documents 102, 104, 106 store business requirements 103, 105, 107 for a SLD.
In another embodiment, a Registrar 100 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 100 to have one electronic document (storing business requirements for one TLD) for each proxy registration. So if a Registrar 100 had three intermediary proxy registration providers, the Registrar would have three electronic documents 102, 104, 106. Each of the three electronic documents 102, 104, 106 would store business requirements for the same TLD, but for different intermediary proxy registration providers. This may be scaled so the Registrar 100 may support any number of TLDs desired by creating additional electronic documents 102, 104, 106 for any number of intermediary proxy registration providers.
A user interface 108 (or computer interface) may be provided that is in communication with a plurality of users 109, 110, 111 over a computer network, such as the Internet. Users 109, 110, 111 may communicate with the user interface 108 through, for example, an API or other network protocol. The Registrar 100 may use the user interface 108 to receive an electronic document D 110 (containing business requirements) from a user 109. If the electronic document is already in the desired format, it may be stored in database 101. Otherwise, the electronic document may be edited to the desired format before storing the electronic document D in the database 101. 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 100) or an existing TLD (a TLD already offered by the Registrar 100) having updated business requirements.
In another embodiment, the user interface 108 and/or the server 200 are configured to: 1) read an electronic document A 102 from the plurality of electronic documents A 102, B 104, C 106, 2) programmatically allow the electronic document A 102 to be modified, and then 3) store the modified electronic document A 102 back into the electronic document database 101.
In another embodiment, the user interface 108 may be configured with the server 200 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 101. The creation of the new electronic document may be accomplished by a software program that runs on one or more servers 200 in the Registrar 100. 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 101.
These 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 100 (represented by Function1300 and Function2302 in
This embodiment illustrates that one or more of the functions may have a separate database (represented by Database1301 in communication with Function1300 and Database2303 in communication with Function2302) in which to store data. In a preferred embodiment, Function1300 cannot access database2303 and Function2302 cannot access database1301.
When a TLDML XML document is created or changed it may be pushed by the TLDML web site manager 606 to the web services 603 and functions. Alternatively, the web services 603 and functions may pull the TLDML XML document from the TLDML web site manager 606 which may retrieve the TLDML XML document 604 from the TLDML data storage 607. Alternatively, the web services 603 may call a TLDMS web service to retrieve the TLDML XML document. In another embodiment, the web services 603 may not be web services at all, but services supported within the domain name registering entity 100.
Direct 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.
As 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.
While the embodiments illustrated in
An electronic document A 102, written in the created format or language, may be constructed or received that describes a plurality of business requirements A 103 for a top-level domain (TLD). (Step 1001) The electronic document A 102 may be constructed from business requirements A 103 entered by user A 109 via the user interface 108 or an API (Website 401). One or more servers 200 may be used to turn the business requirements A 103 into an electronic document A 102 having the created format or language. Alternatively, an electronic document D 110 may be received from a user A 109 via the user interface 108 or API (Website 401) already in the created format or language.
The electronic document A 102 once created, may be considered the authoritative source in the Registrar 100 for the plurality of business requirements A 103 for the TLD. Example electronic documents A 102, B 104, C 106 are illustrated in
The user 109 may be an employee of the domain name registering entity or Registrar 100, the employee of a Registry or an employee of a registrant (owner) of the TLD. In any event, the user 109 is preferably a trusted source for providing business requirements (or an electronic document D 110) for the TLD.
The created or received electronic document A 102 may be used to configure a system (such as a domain name registering entity or a Registrar 100) to register a plurality of domain names having the TLD. (Step 1002) Once the system is configured, domain names having the TLD may be registered to one or more registrants. (Step 1003)
A Registrar 100 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 100.
A user interface web site 500 may be provided to allow a user A 109 to select a TLD from a plurality of TLDs. (Step 1800) The selected TLD is the TLD that the user A 109 wishes to see the business requirements for the TLD that are currently being used. A reverse TLDML 502 may ask one or more application specific implementations 508-512 (functions) via their corresponding TLDML web services 503-507 which business requirements they are using.
The application specific implementations 508-512 may respond, via their TLDML web services 503-507, to the reverse TLDML 502 with the business requirements that each application specific implementation 508-512 is using. (Step 1801) For example, the reverse TLDML 502 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 508-512 (functions) within the Registrar 100.
The TLDML merge component 501 may use the information retrieved by the reverse TLDML 502 to create an electronic document showing the business requirements currently being used by a Registrar 100 for the selected TLD by merging or combining the information together. (Step 1802) Duplicate information may be ignored, while conflicting information may be flagged as a possible problem in the electronic document.
The electronic document may then be displayed for the user A 109 on the user interface web site 500. (Step 1803) 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 500) since the electronic document is primarily for human consumption and interaction.
Other 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.
While 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 100 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 100 used in the described embodiments within this specification.
The 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.
This application is a continuation of U.S. patent application Ser. No. 13/731,724 titled: “A TLD MARKUP LANGUAGE” filed on Dec. 31, 2012 which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13731724 | Dec 2012 | US |
| Child | 15878822 | US |
