US20040199620A1 - Method for transfering a registered domain name from a first registrar to a second registrar - Google Patents
Method for transfering a registered domain name from a first registrar to a second registrar Download PDFInfo
- Publication number
- US20040199620A1 US20040199620A1 US10/408,037 US40803703A US2004199620A1 US 20040199620 A1 US20040199620 A1 US 20040199620A1 US 40803703 A US40803703 A US 40803703A US 2004199620 A1 US2004199620 A1 US 2004199620A1
- Authority
- US
- United States
- Prior art keywords
- domain name
- customer
- registrar
- registry
- registrant
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/30—Managing network names, e.g. use of aliases or nicknames
- H04L61/3015—Name registration, generation or assignment
- H04L61/302—Administrative registration, e.g. for domain names at internet corporation for assigned names and numbers [ICANN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Description
- This patent application is related to the following patent applications concurrently filed herewith, all assigned to Parsons Advanced Holdings, Inc.:
- U.S. patent application Ser. No. ______, “Method for Gathering Domain Name Registration Information from a Registrant Via a Registrar's Web Site”;
- U.S. patent application Ser. No. ______, “Method for Checking the Availability of a Domain Name”; and
- U.S. patent application Ser. No. ______, “Method for Registering a Stream of Domain Names Received Via a Registrar's Web Site”.
- The present invention relates to systems and processes for a Customer, i.e. a content provider on the internet, to register a domain name from a Registrar's web site thereby allowing access to the Customer's information over an electronic data network such as the Internet or the world wide web (WWW).
- The Internet is a worldwide network of computers and computer networks arranged to allow the easy and robust exchange of information between the users of the computers. Hundreds of millions of people around the world have access to computers connected to the Internet via one of the hundreds of Internet Service Providers (ISPs). Content providers place multimedia information, i.e. graphics and sounds, and other forms of data at specific locations on the Internet referred to as web sites that are typically hosted by an ISP. The combination of all the web sites and their corresponding web pages on the Internet is generally known as the world wide web (web or www).
- Web sites may be created using HyperText Markup Language (HTML) to generate a standard set of tags that define how the web pages for the web site are to be displayed. Users of the Internet may access content providers' web sites using a software package known as a browser, such as Microsoft Internet Explorer or Netscape Navigator. After the browser has located the desired webpage, it requests and receives information from the web page, typically in the form of an HTML document, and then displays the web page's content for the user. The user may then view other web pages at the same web site or move to an entirely different web site using the browser.
- Browsers are able to locate specific web sites because each web site, resource and computer on the Internet has a unique Internet Protocol (IP) address. Each IP address is a 32 bit binary number, but is typically shown in dotted decimal notion, e.g. 192.145.68.112, to improve human readability. However, IP addresses, even in dotted decimal notation, are difficult to remember and use by people. Uniform Resource Locators (hereafter “URL”) are 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 web site on the Internet through the use of a URL. The URL may include a Hypertext Transfer Protocol (HTTP) request combined with the web site's internet address, also known as the web site'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 “www.companyname.com” is the domain name.
- Individuals, companies, and other entities who provide content on the web generally want to use their name or one of their trademarks as part of their domain name. Thus, domain names are generally company trademarks, personal names or short phrases concatenated with a top level domain name (TLD) extension (e.g. .com, .net, org, us, .biz, etc.). Domain names created in this fashion are much easier to remember and use than their corresponding IP addresses. The Internet Corporation for Assigned Names & Numbers (ICANN) approves all TLDs and delegates the responsibility to a particular organization (hereinafter 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, us, the Registry is also the authoritative source for contact information related to the domain name. For other TLDs, e.g. .com, .ws, org, .net, a Registrar is the authoritative source for the contact information related to the domain name. All domain names are organized through a central domain name Shared Registration System (SRS) based on their TLD. There is one organization, or Registry, for each of the ICANN approved TLDs.
- A process for registering one's own domain name is illustrated in FIGS. 1 and 2. The communications shown here and in other figures of the drawings are typically communications via the internet, but could be direct LAN or WAN connections, telephone lines, cell phone links, RF or fiber optics connections among others.
Customer 20,Registry 22, andRegistrar 24 are typically entities having access to computer installations equipped for internet communications. - The process for registering a domain name with a
particular Registry 22 allows aCustomer 20 to use an ICANN-accreditedRegistrar 24. For example if John Doe wishes to register the domain name “JohnDoe.com”, John Doe may initially verify whether the desired domain name is or is not available by contacting aRegistrar 24. TheCustomer 20 may make this contact using the Registrar's web page and typing the desired domain name into a field in the Registrar's web page created for this purpose. (Step 30) Upon receiving the request from the Customer 20 (Step 32), theRegistrar 24 may ascertain whether “JohnDoe.com” has already been registered by checking the SRS database of theRegistry 22 associated with the TLD of the domain name. (Step 34) The results of the search may then be displayed on the web page to thereby notify theCustomer 20 of the availability of the domain name. (Step 35) If the domain name is available, theCustomer 20 may proceed with the registration process. Otherwise, theCustomer 20 will have to keep selecting alternative domain names until an available domain name is found. - Regardless of the
Registrar 24 used to process the registration, theCustomer 20 must (together with payment of the Registrar's applicable fees), provide certain personal information in order to complete the registration. (Step 36) The registration information typically includes the Customer's address and personal contact information, including an email address, phone number and mailing addresses of an administrative, a technical and a billing contact. TheRegistrar 24 stores the Customer's contact information and domain name in a temporary, working contact table 50. (Step 38) The registration processes may be very difficult and time consuming for theCustomer 20. For example, in a conventional registration process, theCustomer 20 is expected to navigate and insert information in several different forms, located on several different web pages on the Registrar's web site. The information may include not only theCustomer 20, administrative, technical and billing contact information, but also information regarding additional services offered by theRegistrar 24. The additional services may include the option of a proxy service or other domain name service setup features, e.g. providing hosting services, for sale page, web site creation, or forwarding and masking for the domain name. Entering the information on several different forms residing on several different web pages can become confusing and laborious for theCustomer 20. This problem is compounded if theCustomer 20 is registering multiple domain names with theRegistrar 24 and must complete this process for each domain name. ACustomer 20 may wish to return to the Registrar's web site many times to register additional domain names or to select different proxy services or to enter different domain name service setup information. The registration process may therefore need to be repeated many times by thesame Customer 20 who has to retype much of the same information at each login session. - After the
Customer 20 submits the registration request, theRegistrar 24 transmits certain information to theRegistry 22 regarding both theRegistrar 24 and theCustomer 20, who will, upon completion of the registration process, be identified as the “registrant”of the domain that is now officially registered with theRegistry 22. (Step 40) TheRegistry 22 adds the domain name, the registrant's name and identification of the Registrar 24 (Step 23) to the SRSdatabase 23 kept by theRegistry 22, which then becomes publicly available in the Registry WHOIS (Step 42) The authoritative contact information is stored with theRegistry 22 for the so called “thick registries”, e.g. .biz, .info and us, and with theRegistrar 24 for the so called “thin registries”, e.g. .com, .ws, org and net. (Steps 48 and 50) TheRegistry 22 confirms the registration to theRegistrar 24. (Step 46) The registration process is concluded by theRegistrar 24 confirming the registration to theCustomer 20. (Steps 52 and 54). - Applicants have noticed that having the
Registrar 24 contact theappropriate Registry 22 to determine if a domain name is available and to have theRegistrar 24 contact theappropriate Registry 22 to register a single domain are very inefficient processes. The piece meal process of the prior is very inefficient in terms of hardware and internet connection use. A connection must be made and appropriate handshaking must be completed to verify the identity of theRegistry 22 andRegistrar 24 for a secure transaction each time data is exchanged between theRegistrar 24 and theRegistry 22. The repeated processes of checking the availability of domain names and registering one or even just a few domain names with theRegistry 22 is very inefficient due to the overhead associated with each contact and puts a heavy demand on the hardware requirements for both theRegistrar 24 and theRegistry 22. - To continue to meet the demands of
Customers 20 registering domain names with aRegistry 22, new systems and processes will be needed to overcome the limitations of current methods. Thus, there remains a need for systems and methods which reduce or eliminate the problems associated with the conventional methods. Specifically, there is a need for simplifying the process for checking the availability of a domain name and the registration process of a domain name, particularly forCustomers 20 that register multiple domain names over a single or multiple login sessions. There is also a need for a system and process for increasing the efficiency of transferring data from theRegistrar 24 to one ormore Registries 22. There is also a need for being able to transfer sponsorship of a domain name from a first Registrar to a second Registrar. - The present invention addresses these needs by providing improved systems and processes for registering domain names with an accredited Registry via an accredited Registrar. A Customer, i.e. a registrant, may visit a Registrar's web site using one of the many widely available browsers. The Registrar's web site allows the Customer to enter a desired domain name and the components or services, i.e. automated software processes, of the website automatically check on the availability of the domain name.
- Zone files, containing all the registered domain names with their corresponding web sites, may be periodically downloaded from the Registries. The zone file information may be parsed to find the registered domain names which may then be stored in an internal database in an optimized format. Searches on the optimized internal database are much faster than prior art searches of a Registry for a domain name. Domain names found in the optimized internal database are determined to be not available (typically the most common result), while domain names not found in the internal database may be subjected to an additional search at the appropriate Registry. The Registry needs to be searched when the domain name is not found in the internal database to allow for the possibility that the domain name may have been registered after the zone files were downloaded.
- The availability of the desired domain name may then be displayed to the Customer using a field on a web page designed for that purpose. Available similar domain names may also be displayed to the Customer and the Customer may select one of the displayed domain names for registration. The process of entering a desired domain name and displaying the availability of the desired domain name, as well as displaying other suggested similar domain names, may be repeated until at least one domain name has been selected for registration by the Customer.
- The Customer's contact information is preferably obtained from a contact information section on a registration application. The registration application may advantageously comprise a single form residing on a single web page. The contact information may include information that may also be used as registrant contact information, technical contact information and administration contact information when a selected domain name is registered with a Registry.
- The registration application may also include a registration type section. The registration type section allows the Customer to select the option of having a proxy registration, whereby a Proxy's information is sent to the Registry and stored in the WHOIS database in place of the Customer's contact information. In this case, the Proxy is the legal owner of the domain name, but may lease the domain name to the Customer. The registration application may also include a domain name service setup section. The domain name setup section allows the Customer to specify additional features or services provided by the Registrar, e.g. hosting or web page options for the domain name.
- The components or services of the Registrar's web site may register the domain name with a Registry. In a preferred embodiment, the selected domain name and Customer information are stored in an Internal Database of the Registrar. The Customer information includes the information received on the registration application and possibly information received from other web pages on the Registrar's web site. A status flag may be set in the Internal Database to indicate that the domain name needs to be registered with a Registry. Services may be used to monitor the Internal Database searching for status flags indicating whether an action is required. The status flag may signal if a domain name needs further processing and if so, what processing step is needed next. The status flag may be continually updated during the registration process to keep track of the domain name's status, via a plurality of services that register the domain name with a Registry.
- Communications between the Registrar and each of the Registries may be handled by a Hub Service. There is preferably at least one Hub Service dedicated to each Registry assigned to a TLD registered by the Registrar. A Hub Service improves the communications between the Registrar and Registries by attempting to keep open one or more secure connections, typically a Secure Socket Layer (SSL) connection, open to each Registry. This eliminates the time necessary to make the connection when the Registrar and Registries need to exchange information.
- In a preferred embodiment, the Customer has the option of creating a login account with the Registrar's web site. The Customer may type in a login name and a password to create the login account. Once created, the login account may store information in an internal database regarding the Customer that may be used in subsequent login sessions as the default information for the Customer. The stored information may, for example, include contact information (such as the name and address of the Customer), registration type, domain name service setup information and/or preferred payment method (such as information from a credit card).
- A Customer may elect to transfer a domain name sponsored by a First Registrar to a Second Registrar. The Customer enters registration information which is stored in an internal database along with an appropriately set status flag. The Customer's registration information may be compared to information from an authoritative source to verify the Customer's right to transfer the domain name. The authoritative source will either be the registry for the TLD or the current sponsoring Registrar, depending on the ICANN rules for that TLD. If the information does not match, the Customer may be notified of the mismatch and is not permitted to transfer the domain name. If the information does match, a confirmation email may be sent to the email address of the administrator found in the authoritative source. The email may have a key to permit the transfer and the email may provide a link to a secure area controlled by the Registrar. The administrator, having received the confirmation email, may connect to the secure area and either allow or prevent the domain name from being transferred from a First Registrar to a Second Registrar.
- Additional advantages and aspects of the present invention will become apparent in the following detailed description and claims.
- FIG. 1 is a block diagram illustrating the relationship between the participants in a prior art domain name registration process;
- FIG. 2 is a functional block diagram in flowchart form illustrating the method of domain name registration typically employed in a prior art registration process;
- FIG. 3 is a functional block diagram in flowchart form illustrating a domain name registration process according to an embodiment of the present invention;
- FIG. 4 is a printed copy of a web page by which a Customer may enter a desired domain name;
- FIG. 5 is a printed copy of a web page by which a Customer may enter data into a registration application includes a single form residing on a single web page;
- FIG. 6 is a block diagram illustrating the participants in a domain name registration according to one embodiment of this invention;
- FIG. 7 is a block diagram illustrating a process for checking on the availability of one or more domain names;
- FIG. 8 is a block diagram illustrating a process for transferring the registration from one Registrar to another Registrar;
- FIG. 9 is a table illustrating various statuses that a domain name may have during processing and example corresponding values for flag statuses;
- FIG. 10 is a flowchart illustrating a process for checking the availability of a domain name; and
- FIG. 11 is a flowchart illustrating a process for transferring a domain name from a first Registrar to a second Registrar.
- The present invention 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 Applicants' best mode for practicing the invention and for enabling one of ordinary skill in the art to make and use the invention. It will be obvious, however, to one skilled in the art that the present invention may be practiced without many of these specific details. In other instances, well-known machines and process steps have not been described in particular detail in order to avoid unnecessarily obscuring the present invention. Unless otherwise indicated, like parts and processes are referred to with like reference numerals.
- Referring to FIG. 6, the present invention allows a
Customer 20 to register one or more domain names over theInternet 600 via aRegistrar 24. The process may be started by theCustomer 20 accessing a web site belonging to an ICANN-accreditedRegistrar 24 using a commercially available web page browser. A system and process for theCustomer 20 to register one or more domain names at a Registrar's web site will be discussed with reference to the flowchart in FIG. 3. FIG. 4 illustrates an example of a web page from a web site belonging to aRegistrar 24, in this case Go Daddy Software®. - A domain name registration process may be initiated by a
Customer 20 entering a desired domain name in afield 400 on a web page. (Step 311). The components, i.e. web site software for automatically processing data entered into the web site, may check on the availability of the desired domain name entered by theCustomer 20. (Step 312). - Process for Checking on the Availability of a Domain Name
- One method for checking the availability of domain names involves querying the
appropriate Registry 22 SRS assigned to the selected TLD. If the Registry SRS acknowledges the existence of the domain name, then the domain name is considered to be not available, otherwise the domain name may be registered. This method has the advantage of always using the most up-to-date information since theRegistry 22 is the authoritative source for domain name registration, but has the disadvantage of having to contact aRegistry 22 via the Internet each time the availability of a domain name is checked. - A preferred method for checking the availability of domain names is illustrated in the block diagram of FIG. 7 and the flowchart in FIG. 10. A
Zone File Server 706 may be updated, preferably about once every 24 hours, by an automated process that downloads the zone files from each of theRegistries 22 a-f. (Step 1000) The zone files may be received from theRegistries 22 a-f using known methods of transferring data, such as by File Transfer Protocol (FTP). Downloading the zone files brings the zone file's data into an internal database which greatly reduces access time to the zone file data. - The zone files from the
registries 22 a-f are preferably optimized for domain name searches and stored on theZone File Server 706. (Step 1001) One method for optimizing the zone files involves parsing the zone files and extracting the domain names thereby creating a compressedZone File Hash 707. TheZone File Hash 707 may be queried for domain name availability much faster than sending queries over the Internet to the non-optimized data of theRegistries 22 a-f. - A web page or
other process 709 may send a domain name check request to a computer automated process, such as aCheck Availability Service 710. (Step 1002) There is preferably at least oneCheck Availability Service 710 on every web server where availability checks may need to be performed. TheCheck Availability Service 710 may receive availability check requests for all TLDs and also for nameservers. - The
Check Availability Service 710 preferably first checks for the availability of the domain name by sending the request to another computer automated process, such as a ZoneFile Check Service 708. The ZoneFile Check Service 708 may be used to provide connections and manages availability check requests targeted to theZone File Server 706. There is preferably at least one ZoneFile Check Service 708 on every web server where availability checks need to be performed. The ZoneFile Check Service 708 may receive availability check requests for all TLDs and nameservers. - The Zone
File Check Service 708 may query theZone File Server 706 and receive a response indicating if the desired domain name was found in theZone File Hash 707. The results of the domain name search may be returned to theCheck Availability Service 710. (Step 1003) If the domain name was in theZone File Hash 707, then the domain name is considered not available. This process is typically very efficient since theZone File Hash 707 is an internal database on theZone File Server 706 with data in an optimized format for searching. Applicants have noticed that desired domain name searches typically yield the result that the domain name has already been registered. Thus, this process quickly leads to a final determination in many cases. - If the domain name was not in the
Zone File Hash 707, a request may then be sent to theRegistry 22 a-f responsible for the domain name's TLD to check the availability of the domain name. (Step 1004) This is necessary since the domain name may have been registered after the last update of theZone File Hash 707 in theZone File Server 706. The Registry's 22 a-f response is considered authoritative and is passed back to the requesting web page orother process 709. - The Registrar's
Check Availability Service 710 preferably communicates to theRegistries 22 a-f via one or more Hub Services 700-705. The Hub Services 700-705 maintain and manage connections from theCheck Availability Service 710 to theRegistries 22 a-f, typically via a secure socket layer (SSL) connection. There is preferably at least one Hub Service for every TLD used. The Hub Services 700-705 may reside on theApplication Server 802. EachRegistry 22 a-f allows a certain number of guaranteed connections to aRegistrar 24. In addition, someRegistries 22 a-f offer more connections on a first-come-first-served basis. The Hub Services 700-705 keep open connections to theRegistries 22 a-f thereby greatly decreasing access times and improving the efficiency of the domain name registration process. In a preferred embodiment, each Hub Service 700-705 is a dedicated centralized connection management system optimized to maintain an Internet connection with a correspondingRegistry 22 a-f. - It should be noted that while FIG. 7 illustrates a six Hub Services700-705 system maintaining connections with six
Registries 22 a-f, one of ordinary skill in the art will recognize that any number of Registries and corresponding Hub Services may be used in combination with the present invention. - Process for Providing Suggested Domain Names
- The Registrar's web site may also generate additional similar domain names and, if the generated domain names are determined to be available, display the available alternative domain names to the
Customer 20. The similar domain names may be generated by replacing the desired TLD with one of the other possible TLDs, by replacing the non-TLD portion of the domain name with a synonym or by concatenating a short word, preferably one that has been found to be popular among domain name registrants, as a prefix or suffix to the non-TLD portion. (Step 313). - The process of receiving desired domain names from the
Customer 20, generating similar domain names and checking and displaying the availability of the domain names may be repeated as many times as desired by theCustomer 20. In this manner, theCustomer 20 may select for registration one or more available domain names. (Steps 310 and 314). - Process for Gathering Domain Name Registration Information
- The registration of an available domain name requires the
Customer 20 to provide theRegistrar 24 with a substantial amount of information, typically by typing the information into fields in a web page designed for this purpose. The information allows theRegistrar 24 to register the domain name with aRegistry 22 and allows theCustomer 20 to select desired products or services for the newly registered domain name. FIG. 5 illustrates aregistration application 580 designed to receive all or a substantial portion of this information. - A
Customer 20 who has previously created a login account on the Registrar's web site may wish to login to their account so that theircustomer information 602 stored in aninternal database 601 previously entered may be used as their default information for the current login session. Alogin section 520 is illustrated inregistration application 580. Thelogin section 520 may have afield 521 for receiving a login name and afield 522 for receiving a password previously selected by theCustomer 20. After entering a login name and a password, the Customer may attempt to login by selecting thelogin button 523. If the password corresponds to the login name from a previously created login account,default customer information 602 may be loaded from the Registrar'sinternal database 601 into the corresponding fields in theregistration application 580. (Step 320). - Storing
customer information 602 received from previous login sessions typically simplifies the process of enteringcustomer information 601, since Applicants have noticed thatCustomers 20 tends to repeat the same information and select the same options for each domain name they subsequently register. If this is the Customer's 20 first time registering a domain name with theRegistrar 24, or if theCustomer 20 did not create a login account at a previous login session, theCustomer 20 will have to enter the information into theregistration application 580. - The
registration application 580 preferably comprises a single form that resides on a single web page. (Step 330) Theregistration application 580 may include acontact information section 500, aregistration type section 530 and a domain nameservice setup section 540. (Step 331) It should be noted that additional fields may be used for entering information for other options or services related to the domain name. As examples, a field for selecting a length ofregistration 524, a field for selecting anautomatic renewal option 550 and fields for acknowledging reading and agreeing to the terms and conditions of one ormore license agreements registration application 580. - The
contact information section 500 may include a plurality of fields for entering the Customer's contact information. Thecontact information section 500 may include fields for afirst name 501, alast name 502, anemail address 503, acompany name 504, a company name is thelegal registrant 505 verification, an address 1506 a, an address 2506 b, acity 507, astate 508, azip code 509, acountry 510, aphone number 511 and afax number 512 for theCustomer 20, as examples. - The ICANN approved registration process for a domain name requires information for a registrant contact, a technical contact and an administrative contact to be stored and made publicly available. This information is stored in a Registry's
WHOIS database 604 for the so-called “thick” registries,e.g. Registries 22 handling TLDs of .biz, .info and .us, and is stored in a Registrar's WHOIS database for the so-called “thin” registries,e.g. Registries 22 handling TLDs of .com, .ws, .org, and .net. In a preferred embodiment of this invention, the contact information from thecontact information section 500 is used as the registrant contact information, the technical contact information and the administrative contact information. The contact information may also be used as billing contact information. - Applicants have discovered that
Customers 20 generally use the same contact information for the registrant contact information, the technical contact information, the administrative contact information and the billing contact information. Using the contact information for all the different necessary contact information simplifies the domain name registration process for the majority of theCustomers 20. A single form registration process has the advantage that theCustomer 20 is more likely to complete a single-page form and thus more likely to register a domain name through theRegistrar 24. A multi-step process is more likely to discourage and deterCustomers 20 from completing the registration process. A single-page form registration process is also less expensive to implement technically, since it requires far fewer round trips between client and server, thus reducing costs associated with bandwidth consumption and CPU usage. - A
registration application 580 may also include aregistration type section 530. Theregistration type section 530 may include fields to select a standard/public registration 530 a or a private/proxy 530 b registration. The standard/public registration stores the Customer's contact information in a publicly available WHOIS database, managed by either aRegistry 22 orRegistrar 24. The private/proxy registration stores a Proxy's contact information in the WHOIS database thereby shielding the Customer's contact information from public view. The Proxy is the legal owner of the domain name, but may lease the domain name back to the Customer. Shielding the Customer's contact information in this manner may be beneficial to theCustomer 20 to stop domain name related spam, deter identity theft and fraud, prevent harassers, stalkers and data miners, protect a second web identity or allow a home business to be run without unwarranted intrusions. - A
registration application 580 may also include a domain nameservice setup section 540. This section is preferably used to allow theCustomer 20 to select one or more options or additional services for the selected domain name(s). In a preferred embodiment, the domain nameservice setup section 540 has fields for entering data related to hosting a web site for thedomain name 541, adding a for sale page for thedomain name 542, creating a one page website for thedomain name 543, forwarding thedomain name 544, forwarding and masking thedomain name 545, parking thedomain name 546 and hosting the domain name elsewhere 547. It should be noted that additional options or services may be added or one or more of the listed options or additional services may be removed without departing from the scope or spirit of the present invention. - The
Customer 20 may create a login account to store thecustomer information 602 in a Registrar'sInternal Database 601. (Step 340) TheCustomer information 602 will preferably include the above described information from theregistration application 580 and may also include information gathered on other web pages. For example, another web page may be used to collect a preferred payment option such as payment via a credit card. In such a case, the credit card number, expiration date and name on the credit card may be stored in theInternal Database 601 asCustomer information 602. This allows theCustomer information 602 to be used as default information at subsequent login sessions so that theCustomer 20 does not have to reenter this information each time theCustomer 20 registers a new domain name. - Process for Registering the Selected Domain Name
- After the
Customer 20 has selected an available desired domain name and provided the registration information, theRegistrar 24 may start a process to register a selected domain name with theRegistry 22 responsible for the domain name's TLD. An automated computer process (hereinafter “SmartCart”), may be called to perform some of the initial steps. SmartCart may be used to validate all the registration information that was gathered from theCustomer 20 and to verify that the information constitutes a complete and valid domain name request. A complete and valid domain name request may include all the required contact information, acceptance of the licensing agreements and nameserver information provided either explicitly or via a selected setup option, e.g., hosting, parking, etc. SmartCart may write to theInternal Database 601 all the information provided to theRegistrar 24 by theCustomer 20 regarding the domain name registration, including registration length, contact information, license agreement information, and nameserver information. SmartCart may also return to the calling application a well-ordered set of data that may be processed through another automated computer process (hereinafter “Shopping Cart”) in order to proceed with the registration. This well-ordered data may include a domain name product for every domain name requested and may additionally include forwarding products, hosting products, masking products, for sale page products, and 1-page website products, depending on the options selected by theCustomer 20. - The advantages of using SmartCart may not necessarily be obvious to the
Customer 20 as they primarily benefit software developers who write the applications that process the Customers' domain name requests. SmartCart returns a final confirmation that the requested registration is valid and complete, or conversely, that the registration cannot be completed as submitted. The developer does not have to handle any interactions with an internal database. In the prior art, a developer may have had to call an internal database several times to write domain name registration information to the internal database and several more times to retrieve all the information necessary to process the request through the Shopping Cart. - SmartCart manages the nameserver information that needs to be recorded in the
Internal Database 601 and at theRegistry 22 in order to implement the Customer's selected setup options, thereby removing this burden from the developer. The developer does not have to figure out what Shopping Cart items need to be processed in order to implement the Customer's setup options. For example, if theCustomer 20 chooses to host the domain with theRegistrar 24, theCustomer 20 may, for example, get a free webmail account as well. The developer doesn't need to take that into consideration. SmartCart may be setup to know what products should be applied to each request and provides all that information to the developer who simply sends it to the Shopping Cart for processing. - Once the purchase is complete, a post-purchase process may be used to move the
registrant information 603 and a corresponding status flag into theInternal Database 601. FIG. 9 shows an example of a list of possible status flags with a value corresponding to a particular status for each status flag. The particular value for each status may be arbitrarily assigned although each flag should have a unique value and once the value has been selected should be consistently used. In addition, not all of the statuses shown in FIG. 9 have to be used and other statuses may be added without necessarily departing from the scope of the invention. Only the status of the status flag, and not the corresponding value of the status flag that is actually stored in the internal database, will be given in the following description of the registration process. - A status flag indicating that the domain name needs to be registered may be initially stored in the
Internal Database 601 after the domain name has been selected for registration by aCustomer 20. One or more Agent Services 803-805, i.e. computer programs or threads, may be used to monitor theInternal Database 601 and the stored status flags. In a preferred embodiment, there is at least one Agent Service dedicated for processing each TLD handled by theRegistrar 24. When an Agent Service 803-805 detects a status flag indicating that a domain name needs to be registered, the Agent Service 803-805 may send a registration request to theRegistry 22 a-f. The Agent Service 803-805 may make a connection to theRegistry 22 a-f through the Hub Service 700-705 that manages the connections to thatRegistry 22 a-f for that particular TLD. - There may be a brief intermediate status, for example if a nameserver needs updating at the Registry, after a successful registration. The Agent Service803-805 may then pick this status up and, depending on the TLD, have other tasks to complete before setting the status to indicate that the domain name is active. This prevents the
Customer 20 from getting access to the domain name before theRegistrar 24 can be sure everything is set up correctly and allows theRegistrar 24 to send only the minimum required information to theRegistry 22 a-f to get the registration in place quickly. After the domain name has been successfully registered, an email may be sent to theCustomer 20 notifying theCustomer 20 that the domain name is now registered and that theCustomer 20 may use the domain name. - If the registration request to the
Registry 22 a-f is not successful, the status flag is changed to indicate an error with an appropriate description. An email may be sent to theCustomer 20 notifying theCustomer 20 that the domain name was not successfully registered. There are preferably both automatic and manual processes in place to try to resolve error statuses and to register the domain name despite the initial failure. For example, a Network Operations Center may try to reregister the domain name every four hours for a certain period of time. This may resolve the problem if theRegistry 22 a-f happened to have a problem during the initial registration try, but theRegistry 22 a-f was able to fix their problem in time for a subsequent registration attempt. In addition, one or more people may periodically manually review every error status to determine the cause of the error and, if possible, correct the error so that the domain name may be registered to theCustomer 20. - Process for Modifying a Previously Registered Domain Name
- After a domain name has been registered, a
Customer 20 may request a modification to the services or information associated with their registered domain name. The modifications may be, for example, to change the contact data, change the renewal requests, change the nameservers, etc. Each type of change request has its own status flag value so the Agent Service 803-805 knows which tasks to be performed for each modification requested by theCustomer 20. Requested change information, an associated record ID and a status flag may be stored in theInternal Database 601. This allows an Agent Service 803-805 to detect the change request status of the domain name via the status flag and make the requested changes, communicate any necessary change information to theRegistry 22 and note any errors in theInternal Database 601. There may be manual and automatic processes in place to deal with the various errors that can occur. An email indicating success or failure may be sent to theCustomer 20 regarding the requested change. - Process for Transferring a Domain Name from a First Registrar to a Second Registrar
- FIG. 11 shows a possible method for transferring a domain name from a
First Registrar 605 to aSecond Registrar 24. ACustomer 20 may indicate on the Second Registrar's web site that theCustomer 20 wants to transfer a domain name from aFirst Registrar 605, i.e. the currently sponsoring Registrar of record, to aSecond Registrar 24. (Step 1100) The domain name with a status flag indicating a transfer request, e.g. pendAuto, and the necessary registration information may be stored in a table in theInternal Database 601. (Step 1101) The table may be a temporary table that is later copied to theInternal Database 601, but is preferably a permanent table written directly to theInternal Database 601. In order to transfer the domain name from theFirst Registrar 605 to theSecond Registrar 24, the Second Registrar needs to verify that theCustomer 20 is in fact the registrant, i.e.Customer 20, of the domain name and that theFirst Registrar 605 is in fact the Registrar of record for the domain name. - With reference to FIG. 8, a Verify
WHOIS Service 812 may be used to automatically verify that theCustomer 20 is the registrant of the domain name and that theFirst Registrar 605 is currently the Registrar of record. The VerifyWHOIS Service 812 may accomplish this by monitoring theInternal Database 601 looking for domain names with a status flag indicating a transfer request, e.g. pendAuto. The VerifyWHOIS Service 812 may reside on theapplication server 802. For domain names where a Registrar is the authoritative source for the contact information, e.g. domain names having a TLD of .com, net, org, or .ws, the VerifyWHOIS Service 812 may get the Registrar of record and that Registrar's URL from the Registry's port 43 WHOIS. The full WHOIS record is then obtained from the Registrar's URL via port 43. For domain names where theRegistry 22 is the authoritative source for the contact information, e.g. a domain name having a TLD of .biz, info, or .us, the VerifyWHOIS Service 812 may obtain the full WHOIS record directly from the Registry's WHOIS database. - The Verify
WHOIS Service 812 may parse the registrant's name and administrative contact's email address from the full WHOIS record for a comparison to the registrant name and administration email address that theCustomer 20 gave theSecond Registrar 24 when selecting to transfer the domain name. The Registrant name may be checked for consistency to be sure that a transfer of ownership is not performed at the same time as the transfer from theFirst Registrar 605 to theSecond Registrar 24. The administrative email is checked for consistency because the current administrative contact must approve the transfer before theRegistrar 24 can initiate the transfer. - If the administrator's email address is not correct, then the
Customer 20 must update the email address at theFirst Registrar 605 before proceeding. (Step 1102) This prevents an unauthorized person from transferring a domain name from theFirst Registrar 605 to theSecond Registrar 24 without proper authority to do so. The status flag may be set to indicate that theCustomer 20 provided information does not match the authoritative source provided information, e.g. a status of pendWhois. A domain name with a status flag of pendWhois may be handled by a manual or automatic processing interface. Depending on what does not match, an appropriate email may be sent to theCustomer 20 explaining how to correct the situation. If theCustomer 20 corrects the mismatched data, the status flag may once again be set to pendAuto and the VerifyWHOIS Service 812 process may be started again. - If the
Customer 20 entered registrant name and administrative email match with the authoritative source for the registrant name and administrative email, the status flag of the domain name in theInternal Database 601 may be changed to indicate that the domain name may be transferred, e.g. pendACK. A confirmation email may be sent to theCustomer 20 asking theCustomer 20 to confirm their intent to transfer the domain name from theFirst Registrar 605 to theSecond Registrar 24. (Step 1103). - One method for the
Customer 20 to affirmatively respond to the confirmation email is to allow theCustomer 20 to log into a secure area to complete the confirmation. This may be accomplished by inserting a link in the confirmation email so that theCustomer 20 may easily access the secure area. In a preferred embodiment, the confirmation email also contains two values that together provide a unique identifier to help theRegistrar 24 identify the transfer and ensure that only the recipient of the email at the Administrator's email address is responding. The first value may be the record ID of the transfer. The second value may be a unique key that is generated randomly for each transfer record. The record ID may be used to allow theRegistrar 24 to identify the account as well. This adds another layer of security in that if theCustomer 20 does not login into the same account in which the transfer purchase was requested, even if theCustomer 20 has the correct link for that transfer, theCustomer 20 will not be able to confirm or deny the transfer. - If the
Customer 20 decides to deny the transfer after logging into the secure area, the transfer is cancelled and the status flag for the domain name is set to indicate this denial, e.g. pendDelete. If theCustomer 20 confirms the transfer, the transfer may be moved to the permanent domains table with a status flag indicating a need to initiate a transfer request for this domain name. (Step 1104). - An Agent Service803-805 for the TLD of the domain name being transferred may be used to detect a domain name in the
Internal Database 601 with a status flag indicating that a transfer request for the domain name is needed. The Agent Services 803-805 preferably comprise a software program or thread of a software program that monitors theInternal Database 601 checking for domain names that have a status flag indicating that an action needs to be performed. There is preferably at least one Agent Service 803-805 for every TLD offered by theRegistrar 24. The Agent Services 803-805 may reside on theapplication server 802 and preferably communicate with the Registries 809-811 as needed through connections via dedicated Hub Services 700-702. Multiple instances of an Agent Service 803-805 may be running for any given TLD. For example, twoCOM Agent Services 803 may be running at the same time due to the volume of .com domain names sponsored that are registered or transferred on a daily basis. TheInternal Database 601 is preferably designed to allow thread safe access by multiple instances of the same Agent Service 803-805. - After an Agent Service803-805 finds a domain name with a status flag indicating a transfer request is needed, the Agent Service 803-805 may send a transfer request to a
Registry 22 a-c. (Step 1105) The transfer request is preferably sent to aRegistry 22 a-c via a Hub Service 700-702 that manages the connections for theRegistry 22 a-c for that particular TLD. If the request is successful, the status flag is changed to indicate the status of waiting for a response. Once the transfer has been initiated, theRegistry 22 a-c may notify theFirst Registrar 605 of the transfer request. TheFirst Registrar 605 has 5 days to respond per ICANN rules. TheFirst Registrar 605 may ACK (ACKnowledge) the transfer right away allowing the transfer to be completed quickly, NACK (Not ACKnowledge) the transfer, or do nothing. If theFirst Registrar 605 does nothing, theRegistry 22 a-c may ACK the transfer request themselves to theSecond Registrar 24 after 5 days. If the request is not successful, the status flag may be changed to indicate this condition depending on the reason the request was not successful. This situation will likely require manual intervention to cure the error and to retry the transfer (set it back to initiate transfer status). - A Transfer Service813-815 may be used to monitor the appropriate resource to determine when a transfer has been completed or denied. (Step 1106) Transfer Services 813-815 may take various forms, but preferably reside on an
application server 802. There may be one or more Transfer Service 813-815 for each TLD or a single Transfer Service may handle one or more TLDs. The Transfer Services 813-815 monitor communications from the Registries regarding transfers to or from aRegistrar 24. Once aRegistrar 24 has initiated a transfer, theRegistrar 24 may rely on a response from theRegistry 22 a-c to tell theRegistrar 24 when the transfer has been completed and when the domain name is now sponsored by theRegistrar 24. The Transfer Services 813-815 may also watch for notices from theRegistry 22 a-c that a request to transfer a domain away from theSecond Registrar 24 has been initiated. - The communications from the
Registry 22 a-c to the Transfer Services 813-815 typically come in the form of an email notification or a daily report. The Transfer Services 813-815 are preferably designed to parse the reports and emails to determine the type of notification being sent to theRegistrar 24 and to make the necessary changes in theInternal Database 601 to signal the Agent Services 803-805 to take the appropriate actions. - If the
Registry 22 a-c notifies theRegistrar 24 that the transfer has been completed, the status flag may be changed to indicate this new status. The associated Agent Service 803-805 for the TLD of the domain name may then setup the nameservers and change the status flag to indicate the domain is ok and active. If theRegistry 22 a-c notifies theRegistrar 24 that the transfer has been denied, the status flag may be changed to indicate this new status with an appropriate error message. Once the error has been resolved, either automatically or through manual intervention, the status flag is changed to indicate a transfer request for the domain name should be initiated and the process may be tried again. - It should be noted that in many cases the status flag actually indicates that some type of action needs to be performed. The Agent Services803-805 continually scan the database for those status flags, picks them up, performs the needed action, and then sets the status flag to a new appropriate value based on the action performed and the results of the action.
- In view of the foregoing, it will be understood by those skilled in the art that the systems and processes of the present invention can facilitate the registration of domain names with an accredited Registry via an accredited Registrar's web site. The above-described embodiments have been provided by way of example, and the present invention is not limited to these examples. Multiple variations and modification to the disclosed embodiments will occur, to the extent not mutually exclusive, to those skilled in the art upon consideration of the foregoing description. For example, while specific numbers of TLDs, Hub Services, Agent Services and Transfer Services where shown in the figures, the particular number may be modified based on the needs of the Registrar. Such variations and modifications, however, fall well within the scope of the present invention as set forth in the following claims.
Claims (23)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/408,037 US20040199620A1 (en) | 2003-04-04 | 2003-04-04 | Method for transfering a registered domain name from a first registrar to a second registrar |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/408,037 US20040199620A1 (en) | 2003-04-04 | 2003-04-04 | Method for transfering a registered domain name from a first registrar to a second registrar |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040199620A1 true US20040199620A1 (en) | 2004-10-07 |
Family
ID=33097685
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/408,037 Abandoned US20040199620A1 (en) | 2003-04-04 | 2003-04-04 | Method for transfering a registered domain name from a first registrar to a second registrar |
Country Status (1)
Country | Link |
---|---|
US (1) | US20040199620A1 (en) |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050216287A1 (en) * | 2004-03-29 | 2005-09-29 | Crosby Michael W | Method for integrating an entrepreneur's web site and a store front web site |
US20080040792A1 (en) * | 1998-10-30 | 2008-02-14 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
WO2009047783A2 (en) * | 2007-06-07 | 2009-04-16 | Bhavin Turakhia | Method and system for providing a predetermined service to a domain registrant by a dns manager |
US20110060950A1 (en) * | 2009-09-09 | 2011-03-10 | Verisign, Inc. | Method and system for recovery of a failed registry |
US7933990B2 (en) | 1998-10-30 | 2011-04-26 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US7987274B2 (en) | 1998-10-30 | 2011-07-26 | Virnetx, Incorporated | Method for establishing secure communication link between computers of virtual private network |
US7996539B2 (en) | 1998-10-30 | 2011-08-09 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US20120265748A1 (en) * | 2011-04-13 | 2012-10-18 | Verisign, Inc. | Systems and methods for detecting the stockpiling of domain names |
US20120304004A1 (en) * | 2011-05-27 | 2012-11-29 | Verisign, Inc. | Recovery of a failed registry |
US20130103803A1 (en) * | 2004-03-29 | 2013-04-25 | Go Daddy Operating Company, LLC | Method for creating an internet business |
US20130173497A1 (en) * | 2011-12-29 | 2013-07-04 | Verisign, Inc. | Methods and systems for creating new domains |
US20150341298A1 (en) * | 2014-05-21 | 2015-11-26 | Go Daddy Operating Company, LLC | Third party messaging system for monitoring and managing domain names and websites |
US20160119283A1 (en) * | 2014-10-23 | 2016-04-28 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US20160182564A1 (en) * | 2002-08-30 | 2016-06-23 | Go Daddy Operating Company, LLC | Domain name hijack protection |
US9479495B2 (en) | 2014-12-18 | 2016-10-25 | Go Daddy Operating Company, LLC | Sending authentication codes to multiple recipients |
US9479533B2 (en) | 2014-12-18 | 2016-10-25 | Go Daddy Operating Company, LLC | Time based authentication codes |
US9483740B1 (en) | 2012-09-06 | 2016-11-01 | Go Daddy Operating Company, LLC | Automated data classification |
US9503306B2 (en) | 2014-04-30 | 2016-11-22 | Go Daddy Operations Company, LLC | Transfer of a domain name through mobile devices |
US9516089B1 (en) | 2012-09-06 | 2016-12-06 | Locu, Inc. | Identifying and processing a number of features identified in a document to determine a type of the document |
US9602575B2 (en) | 2014-08-07 | 2017-03-21 | Go Daddy Operating Company, LLC | Monitoring social media for specific issues |
US9659106B2 (en) | 2014-06-19 | 2017-05-23 | Go Daddy Operating Company, LLC | Software application customized for target market |
US9807053B1 (en) * | 2014-08-29 | 2017-10-31 | Uniregistry, Corp. | System and method related to domain name tracking and transfer |
US20190036877A1 (en) * | 2015-12-30 | 2019-01-31 | Go Daddy Operating Company, LLC | Registrant defined limitations on a control panel for a registered tertiary domain |
US10198408B1 (en) | 2013-10-01 | 2019-02-05 | Go Daddy Operating Company, LLC | System and method for converting and importing web site content |
US10511573B2 (en) | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US10523632B2 (en) * | 2016-09-19 | 2019-12-31 | Verisign, Inc. | GTLD domain name registries RDAP architecture |
US10798093B2 (en) | 2016-09-19 | 2020-10-06 | Verisign, Inc. | GTLD domain name registries RDAP architecture |
US11153264B2 (en) * | 2015-12-24 | 2021-10-19 | Num Technology Ltd | Methods, apparatuses, and computer programs for data processing, and hierarchical domain name system zone files |
US11444929B2 (en) * | 2020-12-18 | 2022-09-13 | Afilias Limited | Safemode management of domain transitioning |
CN116170495A (en) * | 2023-04-20 | 2023-05-26 | 中国信息通信研究院 | Domain name registration method and device based on blockchain, electronic equipment and storage medium |
Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020040301A1 (en) * | 2000-05-22 | 2002-04-04 | Royall William A. | Method of generating increased applications for enrollment at educational institutions |
US20020065903A1 (en) * | 1999-12-01 | 2002-05-30 | Barry Fellman | Internet domain name registration system |
US20020091827A1 (en) * | 2000-11-01 | 2002-07-11 | Raymond King | Domain name acquisition and management system and method |
US6519589B2 (en) * | 1999-09-22 | 2003-02-11 | Raredomains.Com | System and method for generating domain names and for facilitating registration and transfer of the same |
US20030225670A1 (en) * | 2002-05-31 | 2003-12-04 | Decarlo George J. | Auction style distribution of domain names |
US6760746B1 (en) * | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
US20040167982A1 (en) * | 2003-02-26 | 2004-08-26 | Cohen Michael A. | Multiple registrars |
US6880007B1 (en) * | 1999-06-07 | 2005-04-12 | Register Com, Inc. | Domain manager and method of use |
US7099956B2 (en) * | 2000-01-31 | 2006-08-29 | Ideaflood, Inc. | Method and apparatus for conducting domain name service |
-
2003
- 2003-04-04 US US10/408,037 patent/US20040199620A1/en not_active Abandoned
Patent Citations (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6880007B1 (en) * | 1999-06-07 | 2005-04-12 | Register Com, Inc. | Domain manager and method of use |
US6760746B1 (en) * | 1999-09-01 | 2004-07-06 | Eric Schneider | Method, product, and apparatus for processing a data request |
US6519589B2 (en) * | 1999-09-22 | 2003-02-11 | Raredomains.Com | System and method for generating domain names and for facilitating registration and transfer of the same |
US20020065903A1 (en) * | 1999-12-01 | 2002-05-30 | Barry Fellman | Internet domain name registration system |
US7099956B2 (en) * | 2000-01-31 | 2006-08-29 | Ideaflood, Inc. | Method and apparatus for conducting domain name service |
US20020040301A1 (en) * | 2000-05-22 | 2002-04-04 | Royall William A. | Method of generating increased applications for enrollment at educational institutions |
US20020091827A1 (en) * | 2000-11-01 | 2002-07-11 | Raymond King | Domain name acquisition and management system and method |
US20030225670A1 (en) * | 2002-05-31 | 2003-12-04 | Decarlo George J. | Auction style distribution of domain names |
US20040167982A1 (en) * | 2003-02-26 | 2004-08-26 | Cohen Michael A. | Multiple registrars |
Cited By (87)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9413766B2 (en) | 1998-10-30 | 2016-08-09 | Virnetx, Inc. | Method for establishing connection between devices |
US8868705B2 (en) | 1998-10-30 | 2014-10-21 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US7933990B2 (en) | 1998-10-30 | 2011-04-26 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US7945654B2 (en) * | 1998-10-30 | 2011-05-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US7987274B2 (en) | 1998-10-30 | 2011-07-26 | Virnetx, Incorporated | Method for establishing secure communication link between computers of virtual private network |
US9967240B2 (en) | 1998-10-30 | 2018-05-08 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9860283B2 (en) | 1998-10-30 | 2018-01-02 | Virnetx, Inc. | Agile network protocol for secure video communications with assured system availability |
US7996539B2 (en) | 1998-10-30 | 2011-08-09 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US8051181B2 (en) | 1998-10-30 | 2011-11-01 | Virnetx, Inc. | Method for establishing secure communication link between computers of virtual private network |
US9819649B2 (en) | 1998-10-30 | 2017-11-14 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US10187387B2 (en) | 1998-10-30 | 2019-01-22 | Virnetx, Inc. | Method for establishing connection between devices |
US10511573B2 (en) | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9479426B2 (en) | 1998-10-30 | 2016-10-25 | Virnetz, Inc. | Agile network protocol for secure communications with assured system availability |
US8943201B2 (en) | 1998-10-30 | 2015-01-27 | Virnetx, Inc. | Method for establishing encrypted channel |
US9386000B2 (en) | 1998-10-30 | 2016-07-05 | Virnetx, Inc. | System and method for establishing a communication link |
US9374346B2 (en) | 1998-10-30 | 2016-06-21 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US8458341B2 (en) | 1998-10-30 | 2013-06-04 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US20080040792A1 (en) * | 1998-10-30 | 2008-02-14 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US8504697B2 (en) | 1998-10-30 | 2013-08-06 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8504696B2 (en) | 1998-10-30 | 2013-08-06 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8516117B2 (en) | 1998-10-30 | 2013-08-20 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US8516131B2 (en) | 1998-10-30 | 2013-08-20 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8521888B2 (en) | 1998-10-30 | 2013-08-27 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8554899B2 (en) | 1998-10-30 | 2013-10-08 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US8560705B2 (en) | 1998-10-30 | 2013-10-15 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US9100375B2 (en) | 1998-10-30 | 2015-08-04 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8572247B2 (en) | 1998-10-30 | 2013-10-29 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9094399B2 (en) | 1998-10-30 | 2015-07-28 | Virnetx, Inc. | Method for establishing secure communication link between computers of virtual private network |
US8843643B2 (en) | 1998-10-30 | 2014-09-23 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8850009B2 (en) | 1998-10-30 | 2014-09-30 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US9027115B2 (en) | 1998-10-30 | 2015-05-05 | Virnetx, Inc. | System and method for using a registered name to connect network devices with a link that uses encryption |
US8874771B2 (en) | 1998-10-30 | 2014-10-28 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US9077694B2 (en) | 1998-10-30 | 2015-07-07 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9077695B2 (en) | 1998-10-30 | 2015-07-07 | Virnetx, Inc. | System and method for establishing an encrypted communication link based on IP address lookup requests |
US7921211B2 (en) | 1998-10-30 | 2011-04-05 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9037713B2 (en) * | 1998-10-30 | 2015-05-19 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9038163B2 (en) | 1998-10-30 | 2015-05-19 | Virnetx, Inc. | Systems and methods for connecting network devices over communication network |
US8904516B2 (en) | 1998-10-30 | 2014-12-02 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US20160182564A1 (en) * | 2002-08-30 | 2016-06-23 | Go Daddy Operating Company, LLC | Domain name hijack protection |
US10154060B2 (en) * | 2002-08-30 | 2018-12-11 | Go Daddy Operating Company, LLC | Domain name hijack protection |
US9848015B2 (en) * | 2002-08-30 | 2017-12-19 | Go Daddy Operating Company, LLC | Domain name hijack protection |
US8560665B2 (en) * | 2004-03-29 | 2013-10-15 | Go Daddy Operation Company, LLC | Method for creating an internet business |
US20130103803A1 (en) * | 2004-03-29 | 2013-04-25 | Go Daddy Operating Company, LLC | Method for creating an internet business |
US20050216287A1 (en) * | 2004-03-29 | 2005-09-29 | Crosby Michael W | Method for integrating an entrepreneur's web site and a store front web site |
WO2009047783A3 (en) * | 2007-06-07 | 2009-06-18 | Bhavin Turakhia | Method and system for providing a predetermined service to a domain registrant by a dns manager |
US20100070569A1 (en) * | 2007-06-07 | 2010-03-18 | Bhavin Turakhia | Method and system for providing a predetermined service to a domain registrant by a dns manager |
WO2009047783A2 (en) * | 2007-06-07 | 2009-04-16 | Bhavin Turakhia | Method and system for providing a predetermined service to a domain registrant by a dns manager |
US9384097B2 (en) | 2009-09-09 | 2016-07-05 | Verisign, Inc. | Method and system for recovery of a failed registry |
US10621054B2 (en) | 2009-09-09 | 2020-04-14 | Verisign, Inc. | Method and system for recovery of a failed registry |
US20110060950A1 (en) * | 2009-09-09 | 2011-03-10 | Verisign, Inc. | Method and system for recovery of a failed registry |
WO2011031731A1 (en) * | 2009-09-09 | 2011-03-17 | Verisign, Inc. | Method and system for recovery of a failed registry |
US9075886B2 (en) * | 2011-04-13 | 2015-07-07 | Verisign, Inc. | Systems and methods for detecting the stockpiling of domain names |
US20120265748A1 (en) * | 2011-04-13 | 2012-10-18 | Verisign, Inc. | Systems and methods for detecting the stockpiling of domain names |
US20120304004A1 (en) * | 2011-05-27 | 2012-11-29 | Verisign, Inc. | Recovery of a failed registry |
US9794221B2 (en) | 2011-05-27 | 2017-10-17 | Verisign, Inc. | Recovery of a failed registry |
US9369427B2 (en) | 2011-05-27 | 2016-06-14 | Verisign, Inc. | Recovery of a failed registry |
US8656209B2 (en) * | 2011-05-27 | 2014-02-18 | Verisign, Inc. | Recovery of a failed registry |
US10015134B2 (en) * | 2011-12-29 | 2018-07-03 | Verisign, Inc. | Methods and systems for creating new domains |
US20180309719A1 (en) * | 2011-12-29 | 2018-10-25 | Verisign, Inc. | Methods and systems for creating new domains |
US20130173497A1 (en) * | 2011-12-29 | 2013-07-04 | Verisign, Inc. | Methods and systems for creating new domains |
US10715487B2 (en) * | 2011-12-29 | 2020-07-14 | Verisign, Inc. | Methods and systems for creating new domains |
US20200344209A1 (en) * | 2011-12-29 | 2020-10-29 | Verisign, Inc. | Methods and systems for creating new domains |
US9483740B1 (en) | 2012-09-06 | 2016-11-01 | Go Daddy Operating Company, LLC | Automated data classification |
US9516089B1 (en) | 2012-09-06 | 2016-12-06 | Locu, Inc. | Identifying and processing a number of features identified in a document to determine a type of the document |
US10198408B1 (en) | 2013-10-01 | 2019-02-05 | Go Daddy Operating Company, LLC | System and method for converting and importing web site content |
US9503306B2 (en) | 2014-04-30 | 2016-11-22 | Go Daddy Operations Company, LLC | Transfer of a domain name through mobile devices |
US20150341298A1 (en) * | 2014-05-21 | 2015-11-26 | Go Daddy Operating Company, LLC | Third party messaging system for monitoring and managing domain names and websites |
US20180176165A1 (en) * | 2014-05-21 | 2018-06-21 | Go Daddy Operating Company, LLC | Third party messaging system for monitoring and managing domain names and websites |
US9929995B2 (en) * | 2014-05-21 | 2018-03-27 | Go Daddy Operating Company, LLC | Third party messaging system for monitoring and managing domain names and websites |
US9659106B2 (en) | 2014-06-19 | 2017-05-23 | Go Daddy Operating Company, LLC | Software application customized for target market |
US9602575B2 (en) | 2014-08-07 | 2017-03-21 | Go Daddy Operating Company, LLC | Monitoring social media for specific issues |
US9807053B1 (en) * | 2014-08-29 | 2017-10-31 | Uniregistry, Corp. | System and method related to domain name tracking and transfer |
US10601774B2 (en) * | 2014-10-23 | 2020-03-24 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US20190166092A1 (en) * | 2014-10-23 | 2019-05-30 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US10277556B2 (en) * | 2014-10-23 | 2019-04-30 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US9954818B2 (en) * | 2014-10-23 | 2018-04-24 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US11184321B2 (en) * | 2014-10-23 | 2021-11-23 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US20160119283A1 (en) * | 2014-10-23 | 2016-04-28 | Go Daddy Operating Company, LLC | Domain name hi-jack prevention |
US9479533B2 (en) | 2014-12-18 | 2016-10-25 | Go Daddy Operating Company, LLC | Time based authentication codes |
US9479495B2 (en) | 2014-12-18 | 2016-10-25 | Go Daddy Operating Company, LLC | Sending authentication codes to multiple recipients |
US11153264B2 (en) * | 2015-12-24 | 2021-10-19 | Num Technology Ltd | Methods, apparatuses, and computer programs for data processing, and hierarchical domain name system zone files |
US20190036877A1 (en) * | 2015-12-30 | 2019-01-31 | Go Daddy Operating Company, LLC | Registrant defined limitations on a control panel for a registered tertiary domain |
US10523632B2 (en) * | 2016-09-19 | 2019-12-31 | Verisign, Inc. | GTLD domain name registries RDAP architecture |
US10931631B1 (en) | 2016-09-19 | 2021-02-23 | Verisign, Inc. | GTLD domain name registries RDAP architecture |
US10798093B2 (en) | 2016-09-19 | 2020-10-06 | Verisign, Inc. | GTLD domain name registries RDAP architecture |
US11444929B2 (en) * | 2020-12-18 | 2022-09-13 | Afilias Limited | Safemode management of domain transitioning |
CN116170495A (en) * | 2023-04-20 | 2023-05-26 | 中国信息通信研究院 | Domain name registration method and device based on blockchain, electronic equipment and storage medium |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20040199493A1 (en) | Method for registering a stream of domain names received via a registrar's web site | |
US20040199520A1 (en) | Method for checking the availability of a domain name | |
US20040199608A1 (en) | Method for gathering domain name registration information from a registrant via a Registrar's web site | |
US20040199620A1 (en) | Method for transfering a registered domain name from a first registrar to a second registrar | |
US7299299B2 (en) | Shared registration system for registering domain names | |
US7953812B2 (en) | Notification system and method for domain name options | |
US10366071B2 (en) | Method and system for submission of an electronic document update | |
JP3938047B2 (en) | Apparatus, method and system for directory quality assurance | |
US7167904B1 (en) | Unified web-based interface-to multiple registrar systems | |
US20090106277A1 (en) | Apparatus, Method and System For Directory Quality Assurance | |
EP1659529A2 (en) | Message based network configuration of domain name purchase | |
JP2003526835A5 (en) | ||
EP2528304A1 (en) | Recovery of a failed registry | |
US9825907B2 (en) | Transfer of a domain name through mobile devices | |
US20100106650A1 (en) | Jointly auctioning expiring domain names | |
US20140181129A1 (en) | System and method for providing an updating on-line forms and registrations | |
US20100106616A1 (en) | Systems for jointly auctioning expiring domain names | |
US11223617B2 (en) | Domain name registrar database associating a temporary access code and an internet related activity of a user | |
US10341322B1 (en) | On demand multifactor authentication | |
US20190379637A1 (en) | Method for a gaining registrar to transfering a domain name from a losing registrar to the gaining registrar | |
US10834076B2 (en) | Website hosting provider database associating a temporary access code and an internet related activity of a user | |
US10581799B2 (en) | Method for a losing registrar to transfer a domain name from the losing registrar to a gaining registrar | |
WO2001077839A1 (en) | Establishing and maintaining internet domain name registrations |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: PARSONS ADVANCED HOLDINGS, INC., ARIZONA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RUIZ, TIM;KROUSE, BRIAN;REEL/FRAME:013940/0229;SIGNING DATES FROM 20030402 TO 20030403 |
|
AS | Assignment |
Owner name: THE GO DADDY GROUP, INC., ARIZONA Free format text: CHANGE OF NAME;ASSIGNOR:PARSONS ADVANCED HOLDINGS, INC.;REEL/FRAME:015857/0194 Effective date: 20050401 |
|
AS | Assignment |
Owner name: GO DADDY OPERATING COMPANY, LLC, ARIZONA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:THE GO DADDY GROUP, INC.;REEL/FRAME:027363/0423 Effective date: 20111212 |
|
AS | Assignment |
Owner name: BARCLAYS BANK PLC, AS COLLATERAL AGENT, NEW YORK Free format text: SECURITY AGREEMENT;ASSIGNOR:GO DADDY OPERATING COMPANY, LLC;REEL/FRAME:027416/0080 Effective date: 20111216 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |
|
AS | Assignment |
Owner name: ROYAL BANK OF CANADA, CANADA Free format text: NOTICE OF SUCCESSION FOR SECURITY AGREEMENT RECORDED AT REEL/FRAME 027416/0080;ASSIGNOR:BARCLAYS BANK PLC;REEL/FRAME:062780/0514 Effective date: 20230215 |