US20200344209A1 - Methods and systems for creating new domains - Google Patents

Abstract

Systems and methods for creating a new domain, such as a top-level domain or a second-level domain, make use of a Domain Manager that enables a user to enter data that is necessary or optional to implement the creation of a new domain. Systems such as, for example, a Registry and one or more Registrars, may use the data defined by the Domain Manager to create a new domain.

Description

RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 16/023,440 filed Jun. 29, 2018, entitled “METHODS AND SYSTEMS FOR CREATING NEW DOMAINS”, which is a continuation of U.S. patent application Ser. No. 13/339,466 filed Dec. 29, 2011, entitled “METHODS AND SYSTEMS FOR CREATING NEW DOMAINS”, both of which are incorporated herein by reference.
TECHNICAL FIELD
• This application is directed towards methods and systems for creation of new domains, including the creation of new top level domains and new second level domains.
BACKGROUND
• A domain name system (DNS) allows people using the internet to refer to domain names, rather than IP addresses, when accessing websites and other online services. Domain names, which employ text characters, such as letters, numbers, and hyphens, will often be easier to remember than IP addresses, which are numerical and do not contain letters or hyphens. In order to implement a DNS, a variety of top-level domains (TLDs) have been created. A generic top-level domain (gTLD) is one type of top-level domain used in DNS. Examples of gTLDs that have already been created are “.com,” “.net,” and “.org.” Another type of TLD is a country-code top-level domain (ccTLD) such as, for example, “.uk.”
• One or more second-level domains (SLDs) can be registered under a TLD. For example, a SLD of “verisign” could be registered under the TLD “.com” such that a website could be accessed at “verisign.com.”
• A domain name “Registry” is an entity that creates, that is, “registers” TLDs, and stores data regarding TLDs and SLDs to be registered under the respective TLDs. A Registry may make stored data regarding TLDs available to one or more “Registrars.” A Registrar may receive data from customers desiring to register one or more SLDs under a given TLD and may communicate this data to the Registry for storage.
• The creation and administration of a new TLD or a new SLD requires several changes to be made at a Registry, at one or more Registrars, and at a variety of other services such as DNS servers and Whois. In order for a Registry to store data regarding TLDs and SLDs registered under the respective TLDs, data regarding a new TLD may need to be entered into a Registry. In addition, in order for a Registrar to register SLDs under TLDs, data regarding a new TLD may need to be provided to the Registrars. It is desirable to provide an improved method for performing the steps necessary to create a new TLD or a new SLD.
SUMMARY
• In one disclosed embodiment, a computer-implemented method of creating a new domain is performed. The method includes receiving domain data regarding an unregistered domain at a first system, the domain data comprising a domain name and data defining at least one of: services to be supported by the domain, features to be supported by the domain, or policies to be enforced by the domain. The method further includes creating a data structure comprising the domain data. The method further includes transmitting the created data structure to a second system.
• In another disclosed embodiment, a system for creating a new domain is provided. The system includes a processor, a memory, an input device, a data structure creation module, and a communication module. The input device is coupled to the processor to receive domain data regarding an unregistered domain, the domain data comprising a domain name and data defining at least one of: services to be supported by the domain, features to be supported by the domain, or policies to be enforced by the domain. The data structure creation module is coupled to the processor and provides for creating a data structure comprising the domain data. The communication module provides for transmitting the data structure to a second system.
• In another disclosed embodiment, a system for creating a new domain is provided. The system includes a processor, a memory, a communication module, and one or more databases. The communication module is coupled to the processor and provides for receiving data from a first system regarding an unregistered domain that is being created as a new domain. The one or more databases provide for storing at least some of the received data, wherein the stored data comprises a domain name and data defining at least one of: services supported by the domain, features supported by the domain, or policies enforced by the domain.
• Additional aspects related to the embodiments will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention.
• It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 illustrates a system in which one Registry and multiple Registrars are used when creating a new top-level domain.
• FIG. 2 illustrates a system in which one Registry and one Registrar are used when creating a new top-level domain.
• FIG. 3 illustrates a system in which a managed DNS service is used when creating a new top-level domain
• FIG. 4 is a flow chart of a registration method for a new domain according to one embodiment.
• FIG. 5 is an example of a user interface of a Domain Manager according to one embodiment.
• FIG. 6 is a flow chart of a top-level and second-level domain registration method for a new domain according to one embodiment.
• FIG. 7 is a flow chart of a registration method for a new second-level domain according to one embodiment.
• FIG. 8 is a flow chart of a domain feature and policy obtaining method according to one embodiment.
• FIG. 9 is a flow chart of a second-level domain registration and pricing method according to one embodiment.
• FIG. 10 is a flow chart of a Resolution Services enablement method according to one embodiment.
• FIG. 11 is a flow chart of a billing and invoicing method according to one embodiment.
• FIG. 12 is a flow chart of a report generating method according to one embodiment.
• FIG. 13 is a flow chart of a report generating method according to one embodiment.
• FIG. 14 is a flow chart of a report generating method according to one embodiment.
• FIG. 15 is an example of a user interface of a Domain Manager according to one embodiment.
DETAILED DESCRIPTION
• Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.
• The process of creating a new domain can be expedited by configuring the data flow in a system used to create a new domain. For instance, in some embodiments, a computer system in the form of a Domain Manager may be provided to obtain some or all of the data necessary to create and administer a new domain. Further, in some embodiments, a system, such as a Registry, that creates the new domain can be structured to accept data from the Domain Manager, store and use portions of the data, and transmit portions of the data to other systems.
• FIG. 1 depicts asystem1000 in which oneRegistry1010 andmultiple Registrars1110 are used when introducing a new top-level domain. An arrangement such as that disclosed inFIG. 1 may be used when a generic TLD is being created.
• Anetwork1005, such as the internet or an intranet, may interconnect theRegistry1010, theRegistrars1110, aDomain Manager1070, and the one ormore Resolution Services1160, to enableRegistry1010, theRegistrars1110, theDomain Manager1070, and the one ormore Resolution Services1160 to communicate with each other.
• TheRegistry1010 may include one ormore processors1020, one ormore memories1030, and one or more databases, such as a NameStore Customer Console (NCC)database1040 and a Consolidated Top Level Domain database1050 (otherwise known as a Provisioning Database). The NCC database may include information regarding Accounts (Accounts may be associated with Registrars and/or Registry Internal Accounts), a product catalog (for example, one product per TLD), subscriptions from the Accounts to the products, security groups that are assigned to individual users, and aggregate financial information. TheRegistry1010 may also include aCommunication Module1240 to facilitate transmitting data to, and receiving data from, systems external to the Registry. TheRegistry1010 may also includeEPP1170,User Interface1180,Batch1190,Reports1220, andData Escrow server1230.EPP1170 may facilitate secure communications between the Registrars and the Registry.User Interface1180 may allow a user to access components of the Registry.Batch1190 may update the available credit of an Account and perform other asynchronous actions.Reports server1220 may store reports having information regarding domains that have been registered, for use by various entities such as the Registry, Registrars, or ICANN.Data Escrow server1230 may store reports having information regarding domains that have been registered and corresponding pricing information, for use by an escrow agent. Theprocessor1020 could be a server, a microprocessor, or any circuit capable of electrically coupling the components of the Registry. The Registry may operate in the manner described in any one of the embodiments below discussing the functions of the Registry.
• A plurality ofRegistrars1110 may include one ormore processors1120, one ormore memories1130, and one ormore databases1140. TheRegistrars1110 may also include aCommunication Module1260 to facilitate transmitting data to, and receiving data from, systems external to the Registrars. Theprocessor1120 could be a server, a microprocessor, or any circuit capable of electrically coupling the one or more databases, the one or more memories, and the Communication Module. The Registrars may operate in the manner described in any one of the embodiments below discussing the functions of a Registrar.
• ADomain Manager1070 may be provided with one ormore processors1090, one ormore memories1100, and one ormore user interfaces1080. TheDomain Manager1070 may also include aCommunication Module1250 to facilitate transmitting data to, and receiving data from, systems external to the Domain Manager. TheDomain Manager1070 may also include a DataStructure Creation Module1270 to facilitate creation of a data structure based on information acquired from theuser interface1080. Theprocessor1090 could be a PC, a microprocessor, or any circuit capable of electrically coupling the one or more user interfaces, the one or more memories, the Communication Module, and the Data Structure Creation Module. The Domain Manager may operate in the manner described in any one of the embodiments below discussing the functions of the Domain Manager. TheDomain Manager1070 is depicted inFIG. 1 as being a separate system that can be reached vianetwork1005, however, it is to be appreciated that the Domain Manager could also be located in theRegistry1010.
• A plurality ofResolution Services1160 may be provided.Resolution Services1160 may include aDNS server1200 and aWhois server1210. The DNS server may store a mapping of domain names to IP addresses. The Whois server may store data regarding customers that have registered domain names.
• FIG. 2 depicts asystem2000 for introducing a new top-level domain. The components ofsystem2000 operate in substantially the same manner assystem1000, but thesystem2000 includes only a single Registry and a single Registrar. Whereassystem1000 may be used for introduction of, for example, gTLDs similar to “.com” and “.net,”system2000 may be used for introduction of, for example, “vanity” domains such as “.London.”
• FIG. 3 depicts asystem3000 in which a managed DNS service is used when introducing a new top-level domain. The components ofsystem3000 operate in substantially the same manner assystem1000. However, in the managed DNS service scenario, the managed DNS service assumes the role of both the Registry and the Registrar.
• FIG. 4 depicts aregistration method400 for a user, such as an employee of a Registry, to create a new domain according to one embodiment. Themethod400 begins by receiving user input data viauser interface1080 ofDomain Manager1070. TheDomain Manager1070 employs the received data to define one or more of a domain name, domain services (svcs), domain features and domain policies of a new domain (step410). TheDomain Manager1070 may be a software application running on a server, and may be configured to receive user data to define and create a new domain at any level, including a top-level domain (TLD) and a second-level domain (SLD). A new domain so defined may then be administered by theRegistry1010.
• The domain svcs defined by theDomain Manager1070 when a new TLD is being created may include a list of one or more Extensible Provisioning Protocol (EPP) objects and command-response extension Uniform Resource Identifiers (URIs). The EPP objects may be used to configure an EPP to facilitate secure communications between Registrars and a Registry.
• URIs may be used to uniquely identify an object service or extension in XML. An object service or extension may be defined using an XML schema with a unique XML URI. By including a list of EPP objects and command-response extension URIs, an Account may know what objects and extensions a particular domain supports. For example, two versions of the DNSSEC extension may be supported. Both of the extensions could be supported or a single one, so by including the URI the Account may know what it can use with a domain.
• When a new SLD is being created with the Domain Manager, the Domain Manager may also define domain svcs to determine which TLDs are appropriate, based on the defined domain svcs.
• The domain features defined by the Domain Manager when a new TLD is being created may include an identifier indicating whether the TLD is “thick” or “thin.” With a thick TLD, contact information is required for domains, whereas with a thin TLD, contact information is not supported.
• The domain features defined by the Domain Manager when a new TLD is being created may further include an identifier indicating whether the TLD supports internationalized domain names. An internationalized domain name allows for the use of characters from non-English languages, such as Chinese, Hindi, Arabic, Russian, or languages that use Latin diacritical characters.
• The domain features defined by the Domain Manager when a new TLD is being created may further include an identifier indicating whether domain name system security extensions (DNSSEC) are supported and, if so, which version is supported. DNSSEC 1.0 defined inRFC 4310, DNSSEC 1.1 defined inRFC 5910, or both may be supported. In addition, policies such as whether the DS Data Interface or Key Data Interface is supported inRFC 5910 and what algorithms are supported can be defined.
• The domain features defined by the Domain Manager when a new TLD is being created may further include a list of levels supported by the TLD. For example the list of levels may indicate “2” for second level support and “3” for third level support.
• The domain policies defined by the Domain Manager when a new TLD is being created may include policies for a specific domain label, by level. For example, the policies regarding the specific domain label may include information, for each level (i.e., top-level domain, second-level domain, third-level domain, etc.), regarding one or more of: a minimum number of characters, a maximum number of characters, a requirement for the label to start with an alphanumeric character, a requirement for the label to end with an alphanumeric character, or a requirement that only DNS characters (upper and lower case Latin characters, numbers, and a hyphen) be supported.
• In addition, the domain policies defined by the Domain Manager when a new TLD is being created may further include information regarding the minimum number of name servers required and/or the maximum number of name servers.
• In addition, the domain policies defined by the Domain Manager when a new TLD is being created may further include a list of contact types, such as a registrant, an administrator, a technology contact, or a billing contact, and whether they are required or optional.
• In addition, the domain policies defined by the Domain Manager when a new TLD is being created may further include DNSSEC policies. The DNSSEC policies may include the minimum number of delegation signer (DS) resource records in the case of a thin DNSSEC TLD or the minimum number of DNSKEY in the case of a thick DNSSEC TLD. The DNSSEC policies may also include the maximum number of delegation signer (DS) resource records in the case of a thin DNSSEC TLD or the maximum number of DNSKEY in the case of a thick DNSSEC TLD. A “thick” DNSSEC TLD may support the Key Data Interface ofRFC 5910 and a “thin” DNSSEC TLS may support the DS Data Interface ofRFC 5910.
• In addition, the domain policies defined by the Domain Manager when a new TLD is being created may further include authorization information format policies. The authorization information format policies may include one or more of a minimum length, a maximum length, an indication of whether a numeric character is required, an indication of whether an alpha character is required, or an indication of whether a special character is required.
• In addition, the domain policies defined by the Domain Manager when a new TLD is being created may further include information regarding what elements are not returned on a partial information response for non-sponsoring Accounts. If a querying Account is not the sponsoring Account (a sponsoring Account being a Registrar or Registry Internal Account that created the domain) and the Account does not provide valid authorization information, such as a private password that the Registrar may provide, server policy determines which optional elements are returned.
• The domain policies defined by the Domain Manager when a new TLD is being created may further include one or more minimum registration periods with a command attribute to indicate commands, such as create, renew, or transfer, to which a given minimum registration period applies.
• The domain policies defined by the Domain Manager when a new TLD is being created may further include one or more maximum registration periods with a command attribute to indicate commands, such as create, renew, or transfer, to which a given maximum registration period applies.
• A new SLD may be created with the Domain Manager in the same way as a TLD. A domain label may be specified (that is, TLD or SLD) along with the domain features and policies, in order to create a TLD or a SLD. An SLD created with the Domain Manager would show up similarly to a TLD, except a SLD would allow registration of third level domains, whereas a TLD would allow registration of second level domains.
• Once the Domain Manager has defined one or more of a domain name, domain svcs, domain features and domain policies of a new domain (step410), one or more databases at the Registry may be updated with some or all of the defined data (step420). In some embodiments the Domain Manager will be located within the Registry. In embodiments where the Domain Manager is located within the Registry, the data acquired by the user interface of the Domain Manager may be transmitted to databases at the Registry using, for example, an intranet.
• In some embodiments, the Domain Manager may be accessed by an internal Domain Manager User Interface to allow Registry administrators to create, update, and delete domains. In some embodiments, the Domain Manager may also, or alternatively, be access by an external Domain Manager User Interface to allow entities external to the Registry to create, update and delete domains. In some embodiments, such external entities may be limited to making information queries (i.e., read operations).
• When a new domain is being created using the Domain Manager, a NameStore Customer Console (NCC) database in the Registry may be updated to include additional product information such that the new domain is an available product (step420). The update of the NameStore Customer Console database may be performed when the domain is deployed. In addition, when a new domain is being created using the Domain Manager, the Registry may update a Consolidated Top Level Domain database in the Registry to include pricing data and other associated metadata regarding the new domain (step420). The pricing data could include, for example, a price or a range of prices to be charged for registering a SLD under a new TLD. Updating of the Consolidated Top Level Domain database may be controlled by the Domain Manager, and may be performed when the new domain is deployed.
• After the Registry has updated its databases with some or all of the data defined by the Domain Manager (step420), some or all of the data regarding the new domain may be transmitted or otherwise made available over one or more communication channels to one or more downstream components of the DNS system external to the Registry (step430). Alternatively, such availability may be provided concurrently with the updating of the one or more databases at the Registry. Data regarding a new domain may be made available to channels and downstream components based upon pre-agreed upon database tables that can be queried by the downstream components. The resolution services generally include versions of the contents of the Provisioning database including domain metadata. Using the domain metadata, the downstream components may be written to be data driven. The channels may include one or more Extensible Provisioning Protocol (EPP) channels (for example, a single EPP channel per Registry database). The downstream components may include one or more of DNS, Whois, Reports, and Data Escrow.
• It will also be appreciated that, in addition to being used to introduce a new domain, the Domain Manager could be used to provide updates to one or more of a domain name, domain svcs, domain features, and domain policies of a previously registered domain. Changes to data stored in the various systems regarding the previously registered domain may propagate through the various systems in substantially the same manner as data regarding a new domain.
• FIG. 5 depicts an example of a user interface of a Domain Manager according to one embodiment. In the embodiment depicted inFIG. 5, a table520 will be displayed with a variety of information regarding domains that have been previously been created using the Domain Manager. For example, the table520 may include a TLD name, a product prefix, and a current status of the creation process for TLDs that have been previously created. In the embodiment depicted inFIG. 5, anadd domain button510 may also be provided on the display that initiates the process for creating a new domain.
• FIG. 15 depicts an example of a user interface of a Domain Manager according to one embodiment, where the creation process of a new TLD may begin. For example, the display depicted inFIG. 15 may be output after a user has selectedbutton510. A user may be given the option, or may be required, to configure a variety of settings for the new TLD. Once the user has finished selecting the options presented on the display, a user may be required to select a createdomain button1510. Upon selection ofbutton1510, new domain settings may begin to propagate, for example, to the Registry, Registrars and/or Resolution Services as described above with reference toFIG. 4.
• FIG. 6 depicts a new TLD andSLD registration method600 according to one embodiment. WhereasFIG. 4 depicts a method of registering any domain using the Domain Manager,FIG. 6 depicts a method where the Domain Manager is used to create a TLD, with SLDs subsequently registered under the TLD. Themethod600 begins by receiving user input at a user interface of a Domain Manager. The user input includes data to define one or more of a domain name, domain svcs, domain features and domain policies of a new TLD using the user interface (step610), in substantially the same manner as described above with respect to step410 ofFIG. 4.
• After receiving the user input (step610), one or more databases at the Registry may be updated with the acquired information (step620), in substantially the same manner asstep420 ofFIG. 4. After the Registry has updated its databases with the new data, or concurrently therewith, data regarding the new TLD may be made available over one or more channels to downstream components (step630), in substantially the same manner asstep430 ofFIG. 4.
• After the Registry has updated its databases, or concurrently therewith, data regarding the new TLD may also be made available to one or more Registrars (step640). It will be recognized that while in some embodiments the Registry and the one or more Registrars will represent separate systems, in other embodiments, such as a managed DNS service scenario, the Registry and Registrar functions will be within the same system.
• Once the one or more Registrars have obtained the data regarding the new TLD, data may be received from the one or more Registrars to begin the registration process for one or more new SLDs under the TLD (step650). Whereas the TLD may be managed by the Registry, new SLDs registered under the TLD may be managed by the customers registering the respective new SLDs or may be managed by a Registrar. Alternatively, if the Domain Manager were used to register new SLDs under the new TLD, the registered SLDs could also be managed by the Registry.
• A Registrar may determine which SLDs to register under a TLD. Data regarding the new SLDs determined by a Registrar may be transmitted to the Registry, whereby the Registry will store the data regarding the new SLDs in one or more databases (step660). For instance, the Registry may update a Provisioning Database to include the new SLDs, whereby the Provisioning Database stores data regarding some or all of the SLDs registered under a TLD. After the Registry has updated its databases to account for the one or more new SLDs, or concurrently therewith, the data regarding the new SLDs may be made available to each of several channels and to downstream components (step670).
• WhileFIG. 6 depicts a TLD being registered using the Domain Manager and an SLD then being registered below the TLD, it is to be appreciated that any level domain (e.g., a second-level domain, third-level domain, etc.) could be registered using the Domain Manager, and subsequently a domain could be registered one level below the domain registered via the Domain Manager.
• FIG. 7 depicts a second-leveldomain registration method700 of a new TLD according to one embodiment. Prior to the start of themethod700, a new TLD will have been created. The method begins by having one or more Registrars query a Registry as to whether a new TLD is available (step710). The querying may be accomplished via a single virtual IP to which the one or more Registrars may connect. More details on using a virtual IP to implement the querying process may be found in U.S. patent application Ser. No. 12/543,462, published as U.S. Patent Application Publication No. 2011/0047292, the subject matter of which is incorporated herein by reference. In performing the query, a Registrar may request an immediate response from the Registry. Alternatively, the Registry may place the Registrar's request in a queue and only respond to the Registrar's request when a new TLD has become available.
• Once it is determined that a new TLD is available (step720), the Registrar making the query will receive data regarding the new TLD (step730). Using the received data, the Registrar may then begin the registration process for a new set of SLDs under a TLD (step740) in substantially the same manner as steps640-670 ofFIG. 6.
• FIG. 8 depicts a domain feature andpolicy obtaining method800 according to one embodiment. Themethod800 depicts one example of an implementation forstep640 ofFIG. 6. The method begins where a Registrar queries a Registry for data on one or more new TLDs (step810). When the Registry receives the query and a new TLD is available, the Registry transmits to the Registrar one or more of: a TLD name, an EPP object and command-response extension URIs, TLD features, and TLD policies (step820). The TLD name, EPP object and command-response extension URIs, TLD features, and TLD policies are substantially the same as those described instep410 ofFIG. 4. With the received data, the Registrar will be able to inform its customers of the name of the new TLD and the various characteristics (svcs, features and policies) of the new TLD. In addition, the received data will indicate to the Registrar what data it needs to acquire to register new SLDs under a new TLD.
• FIG. 9 depicts a second-level domain registration andpricing method600 according to one embodiment. Prior to the start of themethod900, a new TLD will have been created. The method begins with a determination that a new TLD has become available (step910).
• Once it is determined that a new TLD has become available, a determination may be made as to whether one or more Accounts have been enabled for automatic subscriptions by searching a database at the Registry that contains such information (step920). An Account enabled for automatic subscriptions may automatically start registering SLDs within the new TLD. Accounts that are not enabled for automatic subscriptions may be required to interact with a person at the Registry to create a TLD subscription before the Account can start registering SLDs within the new TLD. After determining which Accounts are enabled for automatic subscriptions, such Accounts may be automatically subscribed to a new TLD (step930). Optionally, predetermined price bands will be stored that can be used to automatically determine a price to charge an Account for making use of the automatic subscription to the new TLD (step940).
• FIG. 10 depicts a ResolutionServices enablement method4000 according to one embodiment. The method begins by providing a stream of changes of the Provisioning Database to one or more Resolution Services located external to the Registry (step4020). The stream may be transformed in a format useful to the target service.
• A determination may then be made as to whether one or more trigger events have occurred (step4030). The one or more trigger events atstep4030 may include, for example, a population of data in the Provisioning Database exceeding a certain threshold, a TLD being added, a TLD being updated, and a TLD being deleted. If one or more trigger events have occurred, the stream will be validated to ensure that there is no issue with the stream of transactions coming from the Provisioning Database to the Resolution Service (step4040). Validation may include comparing the transformed data with the source data. Validation may be handled by the Resolution Service. The Resolution Service may extract the desired provisioning data from the stream, transform the data, validate the data, and propagate the data to resolution servers (e.g., DNS servers and/or Whois servers). The resolution servers generally have in-memory images of the transformed data with the provisioning database as the authoritative source.
• After the stream is validated atstep4040, one or more Resolution Service Resources will be provisioned (step4050). Provisioning of one or more Resolution Service Resources may include new TLD Servers and Whois Servers being setup, initialized, or updated. For example, a model may be setup to automatically allocate new resources or automatically enable new services in a Resolution Services Cloud for use by a new gTLD.
• FIG. 11 depicts a billing andinvoicing method4100 according to one embodiment. The method begins by obtaining billing data from the Provisioning Database (step4110). The billing data represents amounts that have been charged to Accounts for the registration of SLDs under a given TLD. The billing data will be aggregated into aggregate debits and credits that are applied to a given Account (step4120). After aggregating the billing data, the aggregate billing data may be applied to respective Accounts in the Account database (step4130). Optionally, an Update Available Credit component may control the billing when a new TLD application is deployed. After the billing data is processed, an invoice report may be updated (step4140). The invoice report may dynamically add a new TLD based on the metadata and the billing data populated in the Provisioning Database.
• A variety of entities, such as the Registry, the Registrars, and ICANN, may require the generation of reports. The Domain Manager may populate data in the Provisioning Database that may trigger the generation of reports providing information regarding domains, including TLDs and SLDs, that have been registered.
• FIG. 12 depicts areport generating method4200 according to one embodiment. The method begins by determining that one or more reports should be generated (step4210). Upon such a determination, a single set of generic reports may be generated that includes several TLDs (step4220). In such an embodiment, the single set of reports would be data-driven based on what is populated in the Provisioning Database.
• FIG. 13 depicts areport generating method4300 according to another embodiment. The method begins by determining that one or more reports should be generated (step4310). Upon such a determination, a set of reports may be generated for each TLD (step4320). The set of reports may be made available on an FTP server, whereby a TLD sub-directory may be created in the FTP server based on the TLD name under a pre-defined parent directory.
• FIG. 14 depicts areport generating method4400 according to one embodiment. The method begins by determining that one or more reports should be generated for Data Escrow (step4410). Upon such a determination, Escrow reports may be generated based on metadata stored in the Provisioning Database (step4420). In addition, a target escrow agent may also be optionally generated based on metadata stored in the Provisioning Database when more than one available escrow agent may be chosen. Once the Escrow reports are generated, the Escrow reports may be propagated to the Escrow Agent (step4430). The propagation may occur using a template-based approach where the TLD specific escrow deposits are partitioned by a scheme having a TLD sub-directory or a TLD indicator in the file names so that the TLD specific escrow deposits may reside in a common directory. The format of the Data Escrow may be driven by the Domain Manager to allow multiple Data Escrow providers to be selected at the time that the TLD is created.
• It will also be appreciated that one or more monitors may be provided by the Domain Manager. For example, one or more system health monitors may be provided that are implemented by looking for specific entries in logs, by driving off of data persisted to the database, or by query interfaces. The one or more system health monitors may identify error conditions and raise alerts in the event of errors. In addition, one or more real-time runtime metrics may be provided. The one or more real-time runtime metrics may increase visibility of the metrics of the running system. In addition, Service Level Agreement (SLA) monitors may be provided. The SLA monitors may measure availability and performance metrics of the systems to demonstrate how the systems perform to SLAs. The SLA monitors may be driven by Registry Information meta-data provided by the systems. In addition, the automated enablement of Registrar systems with the addition of a new TLD could also apply to the SLA monitoring, where the SLA monitors may query for the available TLDs, then query for the features and policies of the available TLDs to drive the SLA scenarios to run, and then execute the scenarios and send results in a generic form to generate combined or separated SLA reports.
• The above described embodiments can be implemented using software, hardware, or a combination of hardware and software. The software may be stored on a memory, such asmemory1030,memory1100, ormemory1130. Such memories may be RAM, ROM, hard disk, CD-ROM, DVD, flash drive, or any other computer readable medium capable of storing software. The software stored on a memory may be executed by a processor, such asprocessor1020,processor1090, orprocessor1120, in order to implement the above described embodiments.
• Other embodiments of the invention will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the invention being indicated by the following claims.

Claims (1)

What is claimed is:

1. A computer-implemented method of creating a new top level domain, comprising:

receiving, at a first system via a user interface, a request to create a non-existing top level domain as a new top level domain in a registry in a domain name system (DNS), the request including domain data, the domain data comprising a domain name for the new top level domain and a data definition selected from one of:

data defining one or more features to be supported by the new top level domain, or

data defining one or more policies to be enforced by the new top level domain;

creating a data structure comprising the domain data including the selected data definition; and

transmitting a create domain request including the data structure to the registry in the DNS, wherein the registry creates, in response to the create domain request, the new top level domain in the registry based on the data structure.

Images