Domain name registration and management for renewal date synchronization

A method for synchronizing management of a plurality of domain names in a Domain Name System (DNS), which method comprises: receiving a synchronization request for synchronizing a first object related to a first renewal date of a first domain name with a second object related to a second renewal date of a second domain name, the synchronization request including an explicit identifier only of the first domain name but not of the second domain name; locate both the first object and the second object in a domain name database; determining a renewal date which is earlier than at least one of the first renewal date and the second renewal date; and synchronizing as a backwards synchronization operation the first object and the second object to both have said renewal date, such that both the first domain name and the second domain name are configured to expire on said renewal date.

FIELD

The present invention is related to registration and management of domain names.

BACKGROUND

Domain names are used in various networking contexts and application-specific naming and addressing purposes. In general, a domain name represents an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, a server computer hosting a web site, or the web site itself or any other service communicated via the Internet. In 2014, the number of active domains reached 271 million. Today's Internet presence by companies is considered a critical element of their business.

There are a number of good reasons for having a domain name. If you ever change your web host, your domain name goes with you. Your regular visitors or customers who knew your site name would not have to be informed about a change of web address (also known as “URL”). They would simply type your domain name and they'd be brought to your new site. If you are a business, a domain name gives you credibility. Few people will be willing to do business with a company that does not have its own domain name. If you get a domain name that describes your company's business or name, people can remember the name easily and can return to your site without having to consult their documents.

Registering with a domain name registrar allows a registrant to make sure that they are registered as the owner, the administrative and technical contacts. Being the owner is vital—if someone else places himself as the owner (such as your web host), he can always decide to charge you some exorbitant fee for the use of the name later. As such obtaining and retaining proper rights to a registrant's domain name portfolio is key in today's competitive landscape.

It is a disadvantage with the current domain name registration and management systems that a registrant's plurality of domain names must be individually registered and subsequently individually maintained (e.g. renewals, etc.). It is critical that registry information relating to the various domain names of a registrant be complete, consistent, accurate, and up to date. As such, it is critical that the domain name registrant keep their domain name records up to date to prevent undesirable expense, complication and worst-case loss of domain name rights. The coordination involved by the registrant in today's multi-TLD universe is becoming increasingly complex, due to the increased availability in the number and variety of domain names.

SUMMARY

A preferred advantage of the present invention is to provide a system and method for domain names to obviate or mitigate at least some of the above presented disadvantages.

A first aspect provided is a method for synchronizing management of a plurality of domain names in a Domain Name System (DNS), the method comprising the steps of: receive a synchronization request for synchronizing a first object related to a first renewal date of a first domain name with a second object related to a second renewal date of a second domain name, the first object unique to the first domain name and the second object unique to the second domain name, the first object and the second object stored in a domain name database and the second domain name associated with a domain name bundle, the synchronization request including an explicit identifier only of the first domain name but not of the second domain name; use a bundle identifier of the domain name bundle associated with the explicit identifier of the first domain name to access a domain name list of the domain name bundle in order to identify the second domain name; locate both the first object and the second object in the domain name database; determine a renewal date which is earlier than at least one of the first renewal date and the second renewal date; synchronize as a backwards synchronization operation the first object and the second object to both have said renewal date, such that both the first domain name and the second domain name are configured to expire on said renewal date; and send a synchronization response confirming the synchronization request.

A second aspect provided is a method for synchronizing management of a plurality of domain names in a Domain Name System (DNS), the method comprising the steps of: receive a synchronization request for synchronizing a first object related to a first renewal date of a first domain name with a second object related to a second renewal date of a second domain name, the first object unique to the first domain name and the second object unique to the second domain name, the first object and the second object stored in a domain name database and the second domain name being an existing member of a domain name bundle, the synchronization request including an explicit identifier of the domain name bundle but not of first domain name nor of the second domain name; use the explicit identifier as a bundle identifier of the domain name bundle associated to access a domain name list of the domain name bundle in order to identify the first domain name and the second domain name; locate both the first object and the second object in the domain name database; determine a renewal date which is earlier than at least one of the first renewal date and the second renewal date; synchronize as a backwards synchronization operation the first object and the second object to both have said renewal date, such that both the first domain name and the second domain name are configured to expire on said renewal date; and send a synchronization response confirming the synchronization request.

A third aspect provided is a method for synchronizing management of a plurality of domain names in a Domain Name System (DNS), the method comprising the steps of: receive a synchronization request for synchronizing a first object related to a first renewal date of a first domain name with a second object related to a second renewal date of a second domain name, the first object unique to the first domain name and the second object unique to the second domain name, the first object and the second object stored in a domain name database and the second domain name being an existing member of a domain name bundle, the synchronization request including an explicit identifier only of the first domain name but not of the second domain name; use a bundle identifier of the domain name bundle associated with the explicit identifier of the first domain name to access a domain name list of the domain name bundle in order to identify the second domain name; locate both the first object and the second object in the domain name database; determine a renewal date which is earlier than at least one of the first renewal date and the second renewal date and calculate a backwards aggregate cost of a backwards synchronization operation; calculate a forwards aggregate cost of a forwards synchronization operation, the forwards aggregate cost using said renewal date as a date later than the at least one of the first renewal date and the second renewal date, such that the backwards aggregate cost is less than the forwards aggregate cost; synchronize as the backwards synchronization operation the first object and the second object to both have said renewal date, such that both the first domain name and the second domain name are configured to expire on said renewal date; and send a synchronization response confirming the synchronization request.

A fourth aspect provided is a method for synchronizing management of a plurality of domain names in a Domain Name System (DNS), the method comprising the steps of: receive a synchronization request for synchronizing a first object related to a first renewal date of a first domain name with a second object related to a second renewal date of a second domain name, the first object unique to the first domain name and the second object unique to the second domain name, the first object and the second object stored in a domain name database and the second domain name being an existing member of a domain name bundle, the synchronization request including an explicit identifier of the domain name bundle but not of first domain name nor of the second domain name; use the explicit identifier as a bundle identifier of the domain name bundle associated to access a domain name list of the domain name bundle in order to identify the first domain name and the second domain name; locate both the first object and the second object in the domain name database; determine a renewal date which is earlier than at least one of the first renewal date and the second renewal date and calculate a backwards aggregate cost of a backwards synchronization operation; calculate a forwards aggregate cost of a forwards synchronization operation, the forwards aggregate cost using said renewal date as a date later than the at least one of the first renewal date and the second renewal date, such that the backwards aggregate cost is less than the forwards aggregate cost; synchronize as a backwards synchronization operation the first object and the second object to both have said renewal date, such that both the first domain name and the second domain name are configured to expire on said renewal date; and send a synchronization response confirming the synchronization request.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

Referring toFIG. 1, shown is a domain name registration and implementation system10providing for a domain name registrant12(e.g. domain owner) to request and obtain over a communications network11(i.e. the Internet) a bundle13of domain names14from a domain name registrar16for multiple domain names14(aggregated into the common bundle13) available (e.g. not yet claimed) in a domain name registry database18(e.g. a database of all domain names registered in a top-level domain (TLD)), which can be managed by a registry operator20that also generates zone files which convert domain names to IP addresses. The bundle13can be considered as a collection or grouping of individual domain names14, such that the individual domain names14are members of the bundle13(i.e. each of the domain name14members of the bundle13have the same bundle ID8associated therewith). It is important to recognize that domain name(s)14can: become member(s) upon creation of the bundle13(e.g. a group of initial domain names14are formed as the bundle13); can become member(s) subsequent to creation of the bundle13(e.g. one or more domain names14can be added to an existing bundle13of domain names14); or can cease to be a member of the bundle13(e.g. a domain name14member of the bundle13can be removed from membership of the bundle13). An advantageous application for management of the domain names14of the bundle13is for synchronization of the domain name expiry dates, thus facilitating the renewal process for those registrants12that have a plurality of different domain names14. In particular, the bundle13provides for synchronizing of dissimilar expiry dates of multiple domain names14, in an effort to synchronize and thus simplify the maintenance of a multiple domain name14portfolio contained within the bundle13, as further described below.

The domain name registration and implementation system10facilitates management of a plurality of the domain names14considered members in the common bundle13via a set of synchronized objects15associated explicitly with the bundle13and thereby associated implicitly with each of the domain names14in the bundle13. It is recognized that the synchronized objects15can include the Domain Registration Date object DRD and the Domain Expiry Date object DED, seeFIG. 4. Further, as described below, actions17can be taken on the objects15of the domain names14of the bundle13. These actions17on the objects15can be facilitated by requests32,35and responses34between particular entities12,16,20,22of the system10via the network11.

It is recognized that the domain names14in the bundle13can be distributed across more than one database18, for example a portion of the domain names14of the bundle13stored in one database18while the remaining portion of the domain names14in the bundle13stored in a second database18separate from the first database18. In any event, it is recognized that a bundle list9of all the domain names14present as members in the bundle13can be stored in one or more of the databases18, such that the bundle list9is used to match any incoming requests32,35from the registrar16(for example) for a particular domain name14to all other domain names14present in the bundle13. Once the request32,35is processed, then a corresponding result/response34is provided. It is also recognized that each of the domain names14can have associated with them the bundle ID8to indicate specific bundle membership, such that each domain name14is cross referenced with their respective bundle13by the bundle ID8. As such, the database18can have a list of all bundles13contained, either in whole or in part, within the database18and identifiable as such by the bundle ID8(representing bundle13membership for a particular domain name14) contained in the list of bundles13.

Preferably, the communications network11comprises a wide area network such as the Internet, however the network11may also comprise one or more local area networks11, one or more wide area networks, or a combination thereof. Further, the network11need not be a land-based network, but instead may comprise a wireless network and/or a hybrid of a land-based network and a wireless network for enhanced communications flexibility. For example, the communications network11can also include Bluetooth™ associated elements. It is recognised that the domain name registrar16, the registry operator20and the registry services provider22can be implemented on computer devices100(seeFIG. 3) such as servers and can communicate with one another via the network11in client-server relationships, in order to facilitate the communication of the requests32,35and responses34(seeFIG. 2). As further described below, the requests32,35and responses34can be communicated using a communication protocol (e.g. EPP).

A domain name14can be referred to as an identification string which is organized in subordinate levels (subdomains) of a DNS root domain, which is nameless. Each domain name14consists of one or more parts, technically called labels, that are conventionally concatenated, and delimited by dots, such as label3.label2.label1. The first-level set (e.g. label1) of domain names14are the top-level domains (TLDs), including the generic top-level domains (gTLDs), such as the prominent domains info, edu, and org, and the country code top-level domains (ccTLDs). Below these top-level domains in the DNS hierarchy are the second-level (e.g. label2) and third-level (e.g. label3) domain names14that are typically open for reservation by end-users who wish to connect local area networks to the Internet11, create other publicly accessible Internet resources, or run web sites. The registration of these domain names14can be administered by the domain name registrars16, who sell their services to the public. The hierarchy of domains descends from the right to the left label in the domain name14; each label to the left specifying a subdivision, or subdomain of the domain to the right.

For example, the top-level domains (TLDs) such as .info and .org are the highest level of domain names of the Internet11, whereby top-level domains form the DNS root zone of the hierarchical Domain Name System, such that every domain name14ends with a top-level domain label. In terms of the bundle13as a specific collection of domain names14, each of the domain names14has a series of parent-child pairings for the labels, e.g. for the example domain name14label3.label2.label1—label3 is the parent of label2 as the child, label2 is the parent of label1 as the child, whereby one of the labels in the pairing is allowed to vary while the other of the labels in the pairing remains constant. In other words, an example bundle13of domain names14could be such as but not limited to: a set of Top Level Domains (TLDs) of the same second level domain (e.g. label2.a, label2.b, label2.c such that “a”, “b”, “c” are different versions of label1); a set of second level domains (SLDs) of the same third level domain (e.g. label3.a.label1, label3.b.label1, label3.c.label1 such that “a”, “b”, “c” are different versions of label2); a set of Top Level Domains (TLDs) of different second level domains (e.g. a.label1, b.label1, c.label1 such that “a”, “b”, “c” are different versions of label2); a set of second level domains (SLDs) of different third level domains; and/or lower level domains (e.g. a.label2.label1, b. label2.label1, c. label2.label1 such that “a”, “b”, “c” are different versions of label3). It is also recognize that an example bundle13of domain names14can be represent as having all domain levels differ, for example domain name label3.label2.label1 such that each of the label3, label2, label1 are different (i.e. there are no common or constant labels between each of the domain names14in the bundle13(e.g. bundle13comprised of domains a.b, c.d, e.f, etc.)

The registration of these domain names14is administered by domain name registrars16who sell their services to the public (i.e. registrants12). The TLD names14such as .info, .org, .mobi are the highest level of domain names of the Internet11. Top-level domains form a DNS root zone of a hierarchical Domain Name System implemented on the Internet11. Every domain name14ends with a top-level domain label. Below the top-level domains in the domain name hierarchy are the second-level domain (SLD) names14. These are the names directly to the left of the top-level domains. As an example, in the domain example.co.info, co is the second-level domain. Second-level domains commonly refer to an organization (e.g. registrant12) that registered the domain name14with the domain name registrar16. Some domain name registry operators20introduce the second-level hierarchy to the TLD that indicates a type of entity intended to register an SLD under it, for example, in the .org namespace a college or other academic institution could register under the .ac.info ccSLD, while companies could register under .co.info. Next are third-level domain names14, which are written immediately to the left of the second-level domain, recognising that there can be fourth- and fifth-level domains, and so on, with virtually no limitation. As such, it is recognised that the domain name bundle13can contain multiple domain names14considered as a single group of domain names having common synchronized objects with one another to facilitate management of each of the domain names14in the domain name bundle13, as further described below. One example of a domain name bundle13could be a grouping of TLDs associated with color, e.g. .red, .orange, .blue, .green, etc.

Domain names14can be referred to as domains and domain name registrants12can be referred to as domain owners, although domain name registration with the registrar16may not confer any legal ownership of the domain name14, only an exclusive right of use for a particular duration of time. As such, the domain name14can be considered an economic asset utilized as an identification string defining a realm of administrative autonomy, authority or control within the Internet11. The domain names14are formed by the rules and procedures of the Domain Name System (DNS), such that any name registered in the DNS is a domain name14. Domain names14can also be thought of as a location on the Internet11where certain information or activities can be found. A fully qualified domain name (FQDN) is a domain name14that is completely specified in the hierarchy of the DNS, having no parts omitted.

In terms of importance to functioning of the Internet11for searching for and accessing Internet11resources, domain names14serve as names for these Internet11resources such as computers, networks, and services. The domain name14represents an Internet Protocol (IP) resource and specifically, individual Internet host computers use domain names14as host identifiers, or host names (e.g. leaf labels in the domain name system usually without further subordinate domain name space). Of importance to Internet11navigation, host names appear as a component in Uniform Resource Locators (URLs) for Internet11resources such as web sites (e.g., Afilias.info). Domain names14can also be used as simple identification labels to indicate ownership or control of a resource. Such examples are the realm identifiers used in the Session Initiation Protocol (SIP), the Domain Keys used to verify DNS domains in e-mail systems, and in many other Uniform Resource Identifiers (URIs). An important function of domain names14is to provide easily recognizable and memorizable names to numerically addressed Internet11resources. Usability of the domain names14as an abstraction provides any resource to be moved to different physical locations in the address topology of the network11, globally or locally in an intranet. Such a move usually involves changing the IP address of the resource and the corresponding translation of this IP address to and from its domain name14.

Referring again toFIG. 1, the registry operator20can also interact with the registry services provider22responsible for services/capabilities facilitating smooth and efficient operation of any type of domain registry database18. For example, the registry services provider22can provide to the registry operator20a standards-based, EPP (as one example of the communication protocol) registry system facilitating a reliable, secure platform for domain operations. Further, the registry services provider22can provide a distributed DNS system facilitating domain availability on the Internet11coupled with provision of state of the art security against attack and abuse. Further, the registry services provider22can provide launch or improvement assistance for the domains identified by the domain names14of the domain name bundle13. Further, the registry services provider22can provide registry solutions and accommodate policy needs for the domain. It is also recognized that the registry services provider22can implement all or a subset of the registry functionality and support services on behalf of the registry operator20(for example the registry services provider22can be the registry operator20for a selected domain name bundle13).

Registration and maintenance of domain names14in the domain name bundle13involves management of synchronized objects15associated with each of the domain names14in the domain name bundle13. These objects15are populated with appropriate data based on action(s)17performed on the objects15(e.g. update/modification, delete/del, transfer, renew, etc.). Example actions17on the objects15for the domain name bundle13are such as registration/purchase of the domain names14as the bundle13by the registrant12from the registrar16. Other example actions17on the objects15can include management by the Registry Operator20of up-to-date data in the objects15concerning domain name and name server registrations maintained by the Registry Operator20, useful in verifying and providing operational stability of Registry Services and the DNS.

Referring toFIGS. 1,2,4, the specification of the content and format of this data of the objects15can be such as but not limited to:

1. Registrar objects. The registrar object corresponds to a single registrar. It can include the following data:

Registrar ID (conforming to the IANA registrar-ids registry)

Contact ID of Registrar

Registrar Administrative Contacts

Registrar Technical Contacts

Registrar Billing Contacts

Registrar URL

Registrar Creation Date

Registrar Last Updated Date

2. Contact objects. The contact object corresponds to a single contact (whether registrant, administrative, technical or billing contact). The contact object includes the following data:

Contact ID

Contact Name

Contact Organization

Contact Postal Code

3. Nameserver objects. A nameserver object corresponds to a single registered nameserver. The nameserver object includes the following data:

Name Server ID

Name Server Host Name

Name Server IP Addresses if applicable

Current Registrar

Name Server Creation Date

Name Server Last Updated Date

4. Domain objects. The domain object corresponds to a single Registered Name. Each domain object includes the following data:

Domain ID

Domain Name

Sponsoring Registrar

Domain Status

All contact information (including all details) with at least one each of:

RegistrantAdministrativeTechnicalBilling
All nameservers associated with this domain
Domain Registration Date (e.g. Domain Registration Date object DRD)
Domain Expiration Date (e.g. Domain Expiry Date object DED)
Domain Last Updated Date

In view of the above, referring toFIG. 4, it is recognised that in particular each of the domain names14of the bundle13are associated with a corresponding Domain Registration Date object DRD and a corresponding Domain Expiry Date object DED. It is recognised that the Domain Registration Date objects DRD of the bundle13can be synchronized or not (i.e. they can have the same chronological value or they can have different chronological values—recognising that the format of the values can include both the date and time, for example 1999-04-03 22:00:00.0 meaning Apr. 3, 1999 at 10 PM). Similarly, it is recognised that the Domain Expiry Date objects DED of the bundle13can be synchronized or not (i.e. they can have the same chronological value or they can be different chronological values). Typically, each of the domain names14has a respective instance of each object15associated therewith. However, it is also recognised that the bundle13itself can have a common object15associated therewith, such that each of the domain names14of the bundle13inherit the value of the common object15for themselves. For example, in the case where the bundle13itself has a common object15of a Domain Registration Date object DRD having a chronological time/date instance of X, then all of the domain names14of the bundle13would also have the same DRD=X. For example, in the case where the bundle13itself has a common object15of a Domain Expiry Date object DED having a chronological time/date instance of Y, then all of the domain names14of the bundle13would also have the same DED=Y. As such, a common object15to the bundle13would be viewed as a synchronized object15(e.g. of value X) that pertains to each and every domain name14that is a member of the bundle13. As described above, it is also recognised that not every instance of a particular object type (e.g. DRD) for each of the domain names14(of the bundle13) would be synchronized. In this case of non synchronization, each of the particular domain names14of the bundle13would have their own instance (i.e. value). For example, in the bundle13shown inFIG. 4, each of the 4 objects DRD could have different values (i.e. different dates and/or times), one of objects DRD could have a different value with the other three objects DRD having the same value, etc. Similarly, for example, in the bundle13shown inFIG. 4, each of the 4 objects DED could have different values (i.e. different dates and/or times), one of objects DED could have a different value with the other three objects DRD having the same value, etc.

As further discussed below, various actions17(seeFIG. 4) can be performed on the objects15of the bundle13by a registry operator20and/or a registry services provider22, via the requests32,35and responses34, in order to change the values/instances of the objects15. The requests32,35would contain identification of the bundle13and/or the domain name(s)14under consideration as well as the intended action15on a particular object15. One example request32,35could be a change (e.g. action17) in the renewal data (e.g. object15) for a specified domain name14. As such, other objects15(of other domain names14in the bundle13) synchronized with the object15of the request32,35would also be subject to the same action17specified in the request32,35. The affected domain names14(by the action17of the request32,35) in the bundle13would be known to the system10by way of their common bundle ID8(e.g. by way of a list9of all domain names14resident in the bundle13). As such, a domain name14specified in the request32,35could be matched to all other domain names14in its bundle13by way of the shared bundle ID8(i.e. all domain names14of the bundle13have the same bundle ID8).

It is recognized that registrant12itself can communicate directly with the registrar16, the Registry Operator20and/or the registry services provider22for registration and/or maintenance information26(seeFIG. 2) used in registration and maintaining of the domain names14associated with the bundle13via coordinating the data content (via the specified actions17of the requests32,35) of the synchronized objects15, and/or can communicate registration and/or maintenance information26indirectly with registry services provider22via registry operator20. Further, registry operator20can supply any requested registration and/or maintenance information26to registry services provider22on behalf of registrant12. As such, the registration and/or maintenance information26is considered data used to populate the synchronized objects15based on actions17(e.g. update, delete, transfer, renew, etc.) performed on the synchronized objects15. It is also recognised that the registrar16can communicate a request for the action17to the registry operator22and/or the registry services provider22on behalf of the registrant12.

Actions17can be provided to registry operator20and/or the registry services provider22via the requests32,35. These actions17would be processed as commands by a command module36(seeFIG. 2). The command module36could be responsible for interacting with the provider of the request32,35(e.g. the registrant12and/or the registrar16), in order to facilitate execution of the action17contained in the request32,35.

An action17can be defined as an operation on an object15unique to each of the plurality of domain names14of the DNS, realizing that each of the plurality of the domain names14in their bundle13has the same data contents in their object15as is in a corresponding object15associated with another domain name14of the bundle13, thus providing for synchronized objects15of the bundle13. An example action17can be assigning the domain names14of the domain name bundle13to a new domain name registrant12. An example action17can be assigning the domain name(s)14of the domain name bundle13to a new bundle13, and thus deleting the domain name(s)14from their current bundle13. As such, in a change of bundle13membership, the changed domain name(s)14would have their corresponding bundle ID8also changed. An example action17can be simply deleting the domain name(s)14from their current bundle13, recognizing that the bundle ID8of the deleted domain name(s)14would be then null, i.e. no bundle13association. An example action17can be simply assigning the domain name(s)14to a new bundle13, and thus changing or otherwise assigning the corresponding bundle ID8to the domain name(s)14(e.g. from a null value to a current value for the bundle ID8). Alternative actions17for existing bundles13can include actions such as but not limited to check, info/status, update/mod, delete/del, transfer, and/or renew.

The action17can be based on a communication protocol such as Extensible Provisioning Protocol (EPP) or Registry Registrar Protocol (RRP). The Extensible Provisioning Protocol (EPP) is a flexible protocol designed for allocating objects within registries over the Internet. EPP provides a robust and flexible protocol that facilitates transaction communications between domain name registry service providers22and domain name registrars16. These transactions are used whenever a domain name14is acted upon using actions17such as to effect data content of the domain name objects15to reflect registered, transferred, renewed or otherwise amended domain names14. As such, the EPP protocol is used to implement an order (request action17on an object) and fulfillment (perform and report result of object when acted upon) system. Specified in XML, EPP can provide basic service elements, such as but not limited to: a greeting, commands (e.g. actions17), responses (e.g. to the actions17effecting changes to data content of the objects15associated with the actions17), and an extension framework that supports future definition of managed objects15and the relationship of EPP protocol requests (e.g. actions17) and responses to those objects15. It is recognised that actions of EPP are expressed as XML, a structured, text-based format, such that communication over the network11of the actions between entities16,18,20,22can be specified over TCP communication messaging and/or other transport communication messaging such as BEEP, SMTP, or SOAP.

As discussed, an example communication protocol for the requests32,35and the responses34can be EPP. It is recognised that the communication protocol used can provide various different actions17in order to transform the objects15, such as but not limited to: create17an instance of a domain object15(e.g. <create> for EPP); delete17an instance of a domain object15(e.g. <delete> for EPP); extend17the validity period of a domain object15(e.g. <renew> for EPP); manage17domain object15sponsorship changes (e.g. <transfer> for EPP); and change17information associated with a domain object15(e.g. <update> for EPP). Further, synch17(e.g. <synch>, also can be referred to as <domainSync:update>) can be used to synchronize the domain name expiry dates for the domain names14of the bundle13. Importantly, the action of synch17for domain names14of the bundle13can be used to synchronize the expiry dates of all of the member domain names14, i.e. to make all of the expiry dates (e.g. an object15) of the member domain names14the same. In this manner, once synchronized, then advantageously the registry operator20and/or the registry services provider22can provide the renewal action17in the request32,35along with identification of one of the member domain names14and/or the bundle ID8. In this way, a simple request32,35can be made for renewal, all at once, for all of the domain names14in the bundle13, thus employing advantageously a straight forward way of updating the renewals for all domain names14which are members of the bundle13(i.e. those domain names14sharing the same synchronized object(s)15for the expiry date).

In terms of the create action17for a new domain name14, the action17using the EPP version of the communication protocol can be provided as the <create> command (i.e. action17) in the request32,35to provide a transform operation that allows a client (e.g. registrar16) to create a domain object, for example to create the domain object15(e.g. a domain name14) as a new domain name14to add to the bundle13. In addition to the standard EPP command elements, the <create> command contains a <domain:create> element that identifies the domain namespace (i.e. the domain name14). The <domain:create> element contains the following child elements of a <domain:name> element that contains the fully qualified name of the domain object15to be created, an OPTIONAL <domain:period> element that contains the initial registration period of the domain object15, as well as the server (e.g. the registry operator20or the registry services provider22) can define a default initial registration period (e.g. as an appropriate object15) if not specified by the client (in order to define the expiry date of the domain name14and hence the renewal term). The request32,35for the create request32,35could also contain the bundle ID8for the new domain name14, in order for the new domain name14to be added to the specified bundle13. In terms of the response34associated with the create request32,35, in terms of using the EPP as the example communication protocol, the EPP <create> response could include the confirmation information of <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> (e.g. the DRD object15) and <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> (e.g. the DED object15).

In terms of the delete action17for a new domain name14, the action17using the EPP version of the communication protocol can be provided as the EPP <delete> command (e.g. action17) in the request32,35to provide a transform operation that allows the client to delete a domain object15, for example to delete the domain object15(e.g. a domain name14) from the bundle13. In addition to the standard EPP command elements, the <delete> command contains a <domain:delete> element that identifies the domain namespace (i.e. associated with the domain name14). The <domain:delete> element contains the following child elements; a <domain:name> element that contains the fully qualified name of the domain object15to be deleted.

In terms of the transfer action17for a domain name14, the action17using the EPP version of the communication protocol can be provided as the <transfer> command (i.e. action17) in the request32,35to provide a transform operation that allows a client (e.g. registrar16) to transfer a domain object, for example to transfer the domain object15(e.g. a domain name14) as a new domain name14to add to the bundle13as the domain name14is being transferred from one registrant12(e.g. CLIENTX to a new registrant (e.g. CLIENTY). In addition to the standard EPP command elements, the <transfer> command contains a <domain:transfer> element that identifies the domain namespace (i.e. the domain name14). The <domain:transfer> element contains the following child elements: a <domain:name> element that contains the fully qualified name of the domain object15for which a transfer request32,35is to be created, approved, rejected, or cancelled, an OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object at completion of the transfer process, a <domain:authInfo> element that contains authorization information associated with the domain object15or authorization information associated with the domain object's15registrant12or associated contacts, and an OPTIONAL “roid” attribute used to identify the registrant12or contact object15if authInfo is associated with a registrant12or contact object15. The request32,35for the transfer request32,35could also contain the bundle ID8for the transferred domain name14, in order for the transferred domain name14to be added to the specified bundle13. When the <transfer> command/action17has been processed successfully, the EPP response34contains a child <domain:trnData> element that identifies the domain namespace. The <domain:trnData> element contains the same child elements defined for the transfer query response34. An example <transfer> response34could include the EPP content of: <domain:reID>ClientX</domain:reID>; <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate>; <domain:acID>ClientY</domain:acID>; <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate>; and <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate>, thus defining the new DRD object15for the transferred domain name14as well as the DED object15for the transferred domain name14.

In terms of the renew action17for all of the domain names14having a synchronized expiry date object15, the action17using the EPP version of the communication protocol can be provided as the <renew> command (i.e. action17) in the request32,35to provide a transform operation that allows a client (e.g. registrar16) to renew all the domain objects15that are synchronized (e.g. to extend the validity period of the synchronized domain objects15), for example to renew the domain objects15(e.g. the domain names14) of the bundle13together in order to efficiently and straightforwardly change all of the expiry dates, e.g. the DED objects15at the same time. In addition to the standard EPP command elements, the <renew> command contains a <domain:renew> element that identifies the domain namespace (e.g. the domain name14). The <domain:renew> element contains the following child elements: a <domain:name> element that contains the fully qualified name of the domain object15whose validity period is to be extended (which will also be used to identify those other domain names14in the bundle13that are members having the domain object15as synchronized); a <domain:curExpDate> element that contains the date on which the current validity period ends (e.g. a value that provides that repeated <renew> commands do not result in multiple unanticipated successful renewals); and an OPTIONAL <domain:period> element that contains the number of units to be added to the registration period of the domain object15(i.e. the number of units that will be used to redefine the DED object15). When a <renew> command/action17has been processed successfully, the EPP based response34would contain a child <domain:renData> element that identifies the domain namespace (i.e. the domain name14). The <domain:renData> element contains the following child elements: a <domain:name> element that contains the fully qualified name of the domain object15; an OPTIONAL <domain:exDate> element that contains the date and time identifying the end of the domain object's15registration period. In terms of an example <renew> response34message, this could include the EPP content of: <domain:name>example.org</domain:name>, <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>, thus defining the new DED object15for the renewed domain name14e.g. example.org). An example validity period of the domain name14can be measured in years or months with the appropriate units specified using the “unit” attribute. Valid values for the “unit” attribute can be “y” for years and “m” for months.

In terms of the synch action17, this command in the request32,35can be processed by the command module36in order to make all of the domain expiry dates DEDs of the domains14of the bundle13have the same DED object15(i.e. representing the same date and thus deemed to be synchronized). It is recognised that the domain registration dates DRDs of the domain names14can be different, while their corresponding domain expiry dates DEDs could be the same (once synchronized).

The registry databases18can also contain a transaction log/history42(e.g. EPP) containing all operations (a consequence of actions17) executed on the objects15of the domain names14in the bundle13, such that the log/history42indicates the domain name14by domain name ID along with details of the operation(s) (e.g. time of transaction, success of transaction, type of operation, etc.). It is recognised, as further described below, in the event that a domain name14of the bundle13is removed (e.g. divided from the bundle13as originally set up) and/or a new domain name14is added to the bundle13post creation of the original bundle13, the transaction log/history of the new/deleted domain name14will be indicated by the original domain name ID pre-change (pre division or pre addition) as well as a new domain name ID (assigned post-change) cross referenced to the old ID. It is recognised that the log/history42can also contain the bundle ID assigned to the domain name14(representing the current bundle13or previous bundle13in the case of a change in bundle13membership). In this manner, it is recognised that a change in bundle13membership (e.g. added to a new bundle13, switched from one bundle13to another bundle13, or simply deleted from a current bundle13) of a domain name14would be reflected in the change in value of the bundle ID8associated with that domain name14(e.g. from bundle ID=null to bundle ID=new#), as well as the change in domain name ID (e.g. from domain name ID=old# to domain name ID=new#). Accordingly, the transaction log/history42for a particular bundle13will contain the history of change in bundle membership for each of the changed domain names14, in order for the registry operator20and/or registry services22being able to track all operations/results transacted on a particular domain name14from inception of the domain name14.

Further, as further described below, in the event that a synchronization operation36a,bis performed on member domain name(s)14of the bundle13, the transaction log/history of the changed domain expiry date(s) DED(s) of the affected domain name(s)14will be indicated by the original domain expiry date(s) DED(s) pre-change (pre synchronization) as well as the new/changed domain expiry date(s) DED(s) (assigned post synchronization) cross referenced to the same domain name14(e.g. domain name ID). In this manner, it is recognised that a change in domain expiry date(s) DED(s) would be reflected in transaction history/log42. Accordingly, the transaction log/history42for a particular bundle13will contain the history of change in domain expiry date DED synchronization for each of the affected domain names14, in order for the registry operator20and/or registry services22being able to track all operations/results transacted on a particular domain name14from inception of the domain name14.

It is recognised that the entities16,18,20,22can interact on the network11with one another in client server pairs. For example, the registrar16can be the EPP client and the registry database18(with associated registry operator20) can be the paired EPP server. In general, an EPP server responds to a successful connection by returning a greeting to the client. The client waits for the greeting before sending an EPP command (i.e. action17) to the server. EPP commands and responses are exchanged serially between the client and the server over the network11, in order to affect the data contents of the corresponding objects15that are acted upon by the action17implemented by the server (i.e. as requested by the client). The server responds to each EPP command with a coordinated response that describes the results of processing the command.

EPP commands fall into three categories: session management commands, query commands, and data transform commands. Session management commands are used to establish and end sessions with an EPP server. Query commands are used to perform read-only, object-based information retrieval operations with respect to data contents of the objects15. Transform commands are used to perform read-write object management operations with respect to the data contents of the objects15.

EPP provides commands to manage sessions, retrieve object information, and perform transformation operations on objects. All EPP commands are atomic and idempotent, either succeeding completely or failing completely and producing predictable results in case of repeated execution. EPP provides three commands/actions to retrieve object information: action <info> to retrieve detailed information associated with a known object, action <ping> to determine if an object is known to the server, and action <transfer> to retrieve known object transfer status information. EPP can provide a number of commands/actions to transform (i.e. modify the data contents of the object15) objects15: action <create> to create an instance of an object15with a server, action <delete> to remove an instance of an object15from a server, action <renew> to extend the validity period of an object15, action <update> to change information associated with an object15, and action <transfer> to manage changes in client sponsorship (e.g. change in registrant12) of a known object15. As such, instance of an object15refers to the specific data contents of an object15. EPP uses four decimal digits to describe the success or failure of each EPP command. The four digits of the reply each have special significance. The first digit denotes whether the response submitted by the server back to the client marks command success or failure. A client that wants to know approximately what kind of error occurred (command syntax error, security error, system error, etc.) can examine the second digit. The third and fourth digits are used to provide explicit information detail by the server to the client with respect to the results of command execution and object15data contents change thereby.

Referring toFIGS. 1 and 2, shown are the registry services provider22and/or registry operator20responsible for the generation, initial registration with the registrant12and maintenance of the plurality of domain names14aggregated into the domain name bundle13. As noted, the domain names14of the domain name bundle13are stored in the registry database18. The domain names14represent Internet11resources (e.g. web pages, databases, etc.) accessible via a specified URI (over the network11) incorporating the domain name14associated with the specified TLD maintained in domain name registry database18using an appropriate network communications protocol (e.g. TCP/IP, HTTP, HTTPS, etc.). For example, the network11communications protocol includes rules for data formats for data exchange and rules for network address formats for data exchange that identify both the sender network11address and the intended receiver(s) network11address. In computing, the URI is a string of characters used to identify a name or a resource. Such identification enables interaction with representations of the resource over a network (typically the World Wide Web) using the specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI, such that URIs can be classified as locators (URLs), as names (URNs), or as both. A uniform resource name (URN) functions like a person's name, while a uniform resource locator (URL) resembles that person's street address. In other words: the URN defines an item's identity, while the URL provides a method for finding the item over the network11.

From the point of view of a registrant12to the domain name bundle13, the objects15associated with each of the domain names14in the bundle13can be perceived by the registrant12as a synchronized set of objects15, such that requested changes/adjustments to the data contents of one object15type (e.g. registrant contact name, expiration date, etc.) by the registrant12for one domain name14in the bundle13is rigorously mapped and executed to a corresponding same object15type for all other domain names14in the bundle13as a result of receiving the registrant12request (i.e. command/action). Execution of the action contained in the registrant12request, to affect the objects15stored in the registry database18associated with the domain names14of the bundle13, can be executed by the registry operator20and/or the registry services provider22. It is recognized that the registry services provider22can also function as a registry operator20for selected domain names14.

It is recognized that each of the domain names14in the bundle13have their own group of associated objects15, such that each group of objects15in the bundle13are combined into a set of objects15for the bundle13. For example, for a bundle13having three domain names14, the set of objects15would have three domain name (type) objects15, three registrant contact (type) objects15, three creation date (type) objects15, etc, such that each group of associated objects15would have one domain name (type) object15, one registrant contact (type) object15, one creation date (type) object15, etc.

The objective of bundle13is to provide a synchronized registration and maintenance platform for a plurality of domain names14contained in the bundle13. As such, it is recognized that actions taken on one object type for a selected domain name14of the bundle13is rigorously executed on all other same object types in the set of objects of the bundle13. For registries focused on organizational registrations, the registry services provider22can offer effective and significant brand protection to registrant12(e.g. organization) of domain names14in the bundle13. This is especially valuable to small and medium sized organizations, as well as organizations with limited resources to develop and manage a brand.

It is recognized that the registry services provider22provides or otherwise hosts the web pages made available to users of the network11, in order to provide access to web-published content associated with the domain name of interest sought by the network user. For example, the web pages and associated content can be provided to the network11by the registry services provider22as files uploaded via File Transfer Protocol (FTP) or a Web interface of the network11(e.g. the Internet). The files representing the web pages can be delivered to the Web “as is” or with some processing. The web page(s)24for a domain name registrant12(e.g. domain owner) can be provided as a single page hosted or as a more complex series of pages and associated navigational links between the pages supported via the database and application development platforms (e.g. PHP, Java, Ruby on Rails, ColdFusion, or ASP.NET). However, it is recognized that the application development platforms, when pertaining to content of their web pages, inhibits the domain name registrant12(e.g. domain owner) from writing or installing scripts for applications like forums and content management published on the web pages, as further described below. As such, the registry services provider22, for any content published on the web pages, provides none or limited interfaces or control panels to the domain name registrant12(e.g. domain owner) for managing the Web server and installing scripts, as well as other modules and service applications like e-mail, as the bundle13is perceived by the registrant12as facilitating and streamlining registration/maintenance of all of the domain names14in the bundle13.

Further, it is recognized that registry services provider22can be embodied as separate from registry operator20(e.g. a third party cooperating with registry operator20via the network11) or can be embodied as a service hosted (not shown) by registry operator20itself, as desired. Registry services provider22can be used to generate and maintain the bundle13on command/registration information15a,b,c,dobtained from the registrant12directed to the registry operator20and/or registry services provider22, as received via a registration module30as a registration request32.

Example content of registration information15a,b,c,dcan include several pieces of information connected with the domain names14of the bundle13, for example: 1) administrative contact information15a(e.g. contact name, address, etc.) defining a designated an administrative contact to manage the domain names14as the bundle13including management of all business information, such as name of record, postal address, and contact information of the official registrant of the domain names14as the bundle13and the obligation to conform to the requirements of the domain registry operator20in order to retain the right to use the domain names14as the bundle13, as well as installing additional contact information for technical and billing functions; 2) technical contact information15b(e.g. contact name, address, etc.) defining a designated technical contact to manage the name server of the domain names14as the bundle13including assuring conformance of the configurations of the domain names14as the bundle13with the requirements of the domain registry service operator20, maintaining the domain zone records, and providing continuous functionality of the name server (that leads to the accessibility of the domain names14as the bundle13); 3) billing contact information15c(e.g. contact name, address, etc.) defining a designated party responsible for receiving billing invoices from the domain name registrar16and paying applicable fees; and 4) name server information15d(e.g. a hostname and the corresponding IP address or just the hostname, which must be resolvable either in the new domain names14as the bundle13, or exist elsewhere) defining designated name server as part of the registration service, for example registrant12can specify its own authoritative name server to host the domain's resource records of the domain names14as the bundle13. As registrant information15a,b,c,dis received, it is provided to a bundle generation module40for use in generating the bundle13via population of all of the objects15contained in the set of bundle objects15.

Referring again toFIG. 2, the registry operator20and/or registry services provider22can also have a command execution module36(provided as separate from the registration module30by example only). The command execution module36is configured to receive the actions from the registrant12in order to update the data contents of all of the related objects15(e.g. of the same type) contained in the set of bundle objects15. For example, a command to update registrant contact details for one of the domain names (e.g. specified by domain name ID in the command) is executed by the command execution module36to affect the data contents of the relevant object15in the registry database18for the specified domain name14, as well as similarly to affect the data contents of the relevant objects15in the registry database18for all other domain names14in the bundle13to which the specified domain name14belongs.

Example Registration of the Bundle13

An example operation of the registration module30is as follows, referring toFIGS. 1 and 2, synchronizing registration of a plurality of domain names14in a Domain Name System (DNS) can be implemented by the registry operator20and/or registry services provider22by: receiving a request32by the registration module30from a domain name registrant12for an action as a registration operation on an object15unique to a domain name14of the DNS, the domain name14having synchronized objects15with another domain name14being stored as a domain name bundle13including the domain name14in a domain name database18; changing the object15by the generation module40in the domain name database18according to the action; identifying the another domain name14in the domain name bundle13by inspecting a list of domain names contained in the bundle13; requesting a change to a corresponding object15to the object15for the another domain name14with the action in order to propagate the registration operation performed on the object15to the corresponding object15, the corresponding object15being unique to the another domain name14; and forwarding via the registration module30a reported result34of the action to the domain name registrant12, the object15and the corresponding object15representing the synchronized objects15by having the same parameter value, an owner to all domain names14in the domain name bundle13being the domain name registrant12.

A further example operation of the registration module30is as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12for a subsequent action as a subsequent registration operation on the object15unique to the domain name14of the DNS; changing the object15in the domain name database18according to the subsequent action; identifying the another domain name15in the domain name bundle13; requesting a subsequent change to the corresponding object15for the another domain name14with the subsequent action in order to propagate the subsequent registration operation performed on the object15to the corresponding object15; and forwarding a reported result34of the subsequent action to the domain name registrant12.

A further example operation of the registration module30is as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12for a subsequent action as a subsequent registration operation on a different object15unique to the domain name14of the DNS; changing the different object15in the domain name database18according to the subsequent action; identifying the another domain name14in the domain name bundle13; requesting a subsequent change to the corresponding different object15for the another domain name14with the subsequent action in order to propagate the subsequent registration operation performed on the different object15to the corresponding different object15; and forwarding a reported result34of the subsequent action to the domain name registrant12.

A further example operation of the registration module30is as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12for a subsequent action as a subsequent registration operation on the corresponding object15unique to the another domain name14of the DNS; changing the corresponding object15in the domain name database18according to the subsequent action; identifying the domain name14in the domain name bundle13; requesting a subsequent change to the object15for the domain name14with the subsequent action in order to propagate the subsequent operation performed on the corresponding object15to the object15; and forwarding a reported result34of the subsequent action to the domain name registrant12.

A further example operation of the registration module30is as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12for a subsequent action as a subsequent registration operation on a different corresponding object15unique to the another domain name14of the DNS; changing the corresponding different object15in the domain name database18according to the subsequent action; identifying the domain name14in the domain name bundle13; requesting a subsequent change to a different object15for the domain name14with the subsequent action in order to propagate the subsequent operation performed on the corresponding different object15to the different object15; and forwarding a reported result34of the subsequent action to the domain name registrant12.

As discussed above, registry databases18can also contain the transaction log/history42containing all operations (a consequence of actions) executed on the objects15of the domain names14in the bundle13, such that the log/history42indicates the domain name14by domain name ID along with details of the operation(s) (e.g. time of transaction, success of transaction, type of operation, etc.). In the event that a domain name14of the bundle13is removed (e.g. divided from the bundle13as originally set up) and/or a new domain name14is added to the bundle13post creation of the original bundle13, the transaction log/history of the new/deleted domain name14will be indicated by the original domain name ID pre-change (pre division or pre addition) as well as a new domain name ID (assigned post-change) cross referenced to the old ID. It is recognised that the log/history42can also contain the bundle ID assigned to the domain name14(representing the current bundle13or previous bundle13in the case of a change in bundle13membership).

Example Adding of Domain Name14to the Bundle13

In terms of adding a new domain name to an existing bundle13, the registration module30operates as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12to add a specified domain name14to the existing bundle13. As such, the registration module30(for example via the generation module40) would update all of the objects of the new domain name14with the data contents of all of the synchronized objects15already in existence for the bundle13(receiving membership of the new domain name14). As mentioned, the mention of the new domain name14in the transaction log42would be assigned a new ID (e.g. domain name ID, bundle ID8) to replace the current ID of the domain name14in the transaction log42, thereby reflecting the change in bundle13membership of the new domain name14. It is recognised that in the case of adding the new domain name14to the bundle13, it is feasible that some of the object15types may not be synchronized, for example the new domain name14can have a different creation date (creation data object15type) than the rest of the pre-existing domain names14of the bundle13or for example the new domain name14can have a different renewal date (renewal data object15type) than the rest of the pre-existing domain names14of the bundle13. However, irrespective that some of the object15types in the set of bundle objects15can be unsynchronized, the owner (owner object15type) and contact details (registrant contact detail object15type) are synchronized for all associated objects15by same type in the set of bundle objects15. It is recognised as well that the list9of domain names14would be updated with the new domain name ID and the new domain name14would assume the bundle ID8of the current bundle13to reflect change in bundle13membership.

Example Deleting of Domain Name14from the Bundle13

In terms of deleting a domain name14from an existing bundle13, the registration module30operates as follows, referring toFIGS. 1 and 2: receiving a subsequent request32from the domain name registrant12to delete a specified domain name14from the existing bundle13. As such, the registration module30(for example via the generation module40) would the delete all of the objects15of the delete domain name14of the data contents from the synchronized objects15already in existence for the bundle13(losing membership of the delete domain name14). As mentioned, the mention of the delete domain name14in the transaction log42would be assigned a new ID (e.g. domain name ID, new bundle ID8if appropriate) to replace the current ID (e.g. delete current bundle ID8if appropriate) of the delete domain name14in the transaction log42, thereby reflecting the loss in bundle13membership of the delete domain name14. It is recognised that in the case of deleting the delete domain name14from the bundle13, all of the objects for the delete domain name14would be duplicated in the registry and assigned appropriate data contents to reflect loss of membership in the old bundle13. It is feasible that some of the object15types may remain populated by data as inherited when first incorporated into the old bundle13, for example the delete domain name14can retain its creation date (creation data object15type) of the rest of the pre-existing domain names14of the bundle13or for example the delete domain name14can retain its renewal date (renewal data object15type) of the rest of the pre-existing domain names14of the bundle13. However, irrespective that some of the object15types can remain similar to the domain names14of the old bundle13, the owner (owner object15type) and contact details (registrant contact detail object15type) would be changed for the associated objects15of the delete domain name14. It is recognised as well that the list9of domain names14would be updated with the loss of the delete domain name ID and the delete domain name14would lose the bundle ID8of the old bundle13to reflect change in bundle13membership.

Example Domain Expiry Date DED Synchronization of the Bundle13

For example, referring toFIGS. 3, 4 and 5, the command module36receives200the request35containing a synch17action and identifying at least one of the domain names14of the bundle13and/or the bundle ID8. The command module36can use the domain name14and/or the bundle ID8to identify202the bundle13and in particular a list9(of the bundle13) of the domain names14as members of the bundle13. The command module36can identify204the domain expiry date DED (e.g. object15) for each of the domain names14of the bundle13and to optionally determine205the synchronization option(s)/operation(s) available for the domain names14of the bundle13.

One synchronization operation36awould be a backwards synchronization, i.e. to select a synchronization date (e.g. one of the domain expiry date DED of a domain name14of the bundle13) that is earlier than one or more of the other domain expiry dates DEDs of the bundle13as part of step204. In this manner, this potential synchronization operation36acould be optionally communicated206to the registrar16and/or registrant12as a response34, for example detailing the backwards synchronization operation36aand the identified (earlier) domain expiry date DED that would be used as a date to change all of the other domain expiry date DED of the domain names14of the bundle13. This potential change would be to effectively subtract existing term from each of the other domain name expiry dates DEDs so that then all of the domain name expiry dates DEDs for the bundle13would be synchronized, i.e. the same as the selected synchronization date. In other words, the value of the domain expiry date DED for each of the synchronized domain names14would updated from the later date(s) to the selected earlier synchronization date.

Another synchronization operation36bwould be a forwards synchronization, i.e. to select a synchronization date (e.g. one of the domain expiry date DED of a domain name14of the bundle13) that is later than one or more of the other domain expiry dates DEDs of the bundle13as part of step204. In this manner, this potential synchronization operation36acould be optionally communicated206to the registrar16and/or registrant12as a response34, for example detailing the forwards synchronization operation36band the identified (later) domain expiry date DED that would be used as a date to change all of the other domain expiry date DED of the domain names14of the bundle13. This potential change would be to effectively add existing term to each of the other domain name expiry dates DEDs so that then all of the domain name expiry dates DEDs for the bundle13would be synchronized, i.e. the same as the selected synchronization date. In other words, the value of the domain expiry date DED for each of the synchronized domain names14would updated from the earlier date(s) to the selected later synchronization date.

Accordingly, the synchronization response34provided206to the registrar16and/or registrant12could; contain details of potential synchronization operation36a, contain details of potential synchronization operation36b, or contain details of potential synchronization operations36aand36b.

In terms of determining which synchronization operation36a,36bto do, a synchronization criteria36ccould be optionally used to calculate207a cost effectiveness of the particular synchronization operation36a,b(as performed by the command module36).

For example, in the case where identified is a backwards synchronization, i.e. a synchronization date (e.g. one of the domain expiry date DED of a domain name14of the bundle13) that is earlier than one or more of the other domain expiry dates DEDs of the bundle13. The command module36could calculate207the amount of term being lost for each of the domain names14having their domain expiry date DED brought backwards in time and to then determine an aggregate cost associated with the total term lost for the domain names14of the bundle13, should the backwards synchronization operation36abe performed. For example, where a year of domain name14term costs $10, and the aggregate term lost for the domain names14of the bundle13is 3.4 years, then the deemed cost for proceeding with the backwards synchronization operation36awould be $34. In other words, the registrar16and/or registrant12would lose this amount of aggregate term (for the affected domain names14) upon synchronization, realizing that the lost aggregate term has already been paid for by the registrant12and thus is a non refundable cost to the registrant12of the backwards synchronization operation36a. It is also recognizable that the aggregate term, as calculated, could be a refundable cost that could be reimbursed to the registrant12as part of the implementation of the backwards synchronization operation36a.

Similarly, in the case where identified is a forwards synchronization, i.e. a synchronization date (e.g. one of the domain expiry date DED of a domain name14of the bundle13) that is later than one or more of the other domain expiry dates DEDs of the bundle13. The command module36could optionally calculate207the amount of term being gained for each of the domain names14having their domain expiry date DED brought forwards in time and to then determine an aggregate cost associated with the total term gained for the domain names14of the bundle13, should the forwards synchronization operation36abe performed. For example, where a year of domain name14term costs $10, and the aggregate term gained for the domain names14of the bundle13is 3.8 years, then the deemed cost for proceeding with the forwards synchronization operation36bwould be $38. In other words, the registrar16and/or registrant12would gain this amount of aggregate term (for the affected domain names14) upon synchronization, realizing that the gained aggregate term would have to be paid for by the registrant12and thus is a cost to the registrant12of the forwards synchronization operation36b.

In the two cases above, for example where both are refundable or where both are non refundable, the command module36could compare (as part of the calculation207) the backwards synchronization operation36acost with the forwards synchronization operation36bcost and select the lower cost option36a,36b(e.g. include only one option36aor36b) to be provided in the response34communicated206to the registrar16and/or registrant12. Alternatively, the command module36could communicate206both options36a,balong with their respective synchronization costs and then let the registrar16and/or registrant12decide which option36a,36bto choose. For example, if the backwards synchronization operation36ahas a cost of $10 (e.g. non-refundable) for the respective aggregate term and the forwards synchronization operation36bhas a cost of $15 (e.g. non-refundable) for the respective aggregate term, then the registrant12may choose the lower cost option of the backwards synchronization operation36a, as the registrant12would only lose $10 verses $15. Alternatively, if the backwards synchronization operation36ahas a cost of $10 (e.g. refundable) for the respective aggregate term and the forwards synchronization operation36bhas a cost of $15 (e.g. refundable) for the respective aggregate term, then the registrant12may choose the lower cost option of the forwards synchronization operation36b, as the registrant12would gain $15 verses $10.

In any event, based on the synchronization request35, the command module36could simply receive the request35and implement208the synchronization operation36a,36b. Alternatively, the command module36could communicate206the details of the synchronization operation36a,36a(i.e. a single operation36a, a single operation36b, or both operations36a,b) and then receive confirmation209(e.g. including payment for the synchronization operation36a,b, if applicable) of the potential operation36a(or36bin the case of a plurality of operations36a,bprovided in the communication206) from the registrar16and/or registrant12. Once confirmed, then the command module36could implement208the synchronization operation36a,36b.

Once implemented208, the command module36could then report210details of the synchronization operation36a,bperformed. For example, the command module36could provide details of all the domain names14in the bundle13now having the same domain expiry dates DEDs, as well as identifying the now synchronized value of the domain expiry date DED.

It is recognised that the synchronization of the domain expiry dates DEDs for the domain names14of the bundle13can be performed based on a number of different bundle13membership scenarios, namely the domain expiry dates DEDs synchronization can be done as: 1) part of the steps in creation of the bundle13(i.e. creating a bundle13with assigned bundle ID8to contain a number of specified domain names14); 2) part of the steps when a new domain name14is added to an existing bundle13; part of the steps when a domain name14of an existing bundle13is removed from the bundle13; and/or a step for the existing domain names14(already members) of an existing bundle13.

In the case where the bundle13is created, i.e. a selected set of domain names14are requested32,35(e.g. as part of a bundle13creation request) by the registrant12and/or registrar16, the command module36could create the bundle13as a step prior to step204ofFIG. 5and then proceed to steps204-210in order to effect the domain expiry date DED synchronization as described above.

In the case where a domain name is added to an existing bundle13, i.e. a domain name14is requested32,35to be added (by the registrant12and/or registrar16, the command module36could add the new domain name14to the existing bundle13as a step prior to step204ofFIG. 5and then proceed to steps204-210in order to effect the domain expiry date DED synchronization as described above. In this case, it is recognised that the domain expiry date DED of the newly added domain name14could affect the actual selected synchronization date performed in step204, which can then be used to calculate the aggregated cost of the synchronization operation36a,b.

In the case where a domain name is removed from an existing bundle13, i.e. a domain name14is requested32,35to be removed (by the registrant12and/or registrar16, the command module36could remove the new domain name14from the existing bundle13as a step prior to step204ofFIG. 5and then proceed to steps204-210in order to effect the domain expiry date DED synchronization as described above. In this case, it is recognised that the domain expiry date DED of the newly removed domain name14could affect the actual selected synchronization date performed in step204, which can then be used to calculate the aggregated cost of the synchronization operation36a,b.

Accordingly, once synchronization of the domain expiry dates DEDs is completed, then subsequent renewal17actions on the bundle13can be straightforwardly executed, as all of the domain names14of the bundle13have the same synchronized domain expiry date DED. In this way as shown inFIG. 6, for renewal17actions subsequent to the synchronization of domain expiry date DED, the command module36can receive300the request35containing a renewal17action and identifying at least one of the domain names14of the bundle13and/or the bundle ID8. The command module36can use the domain name14and/or the bundle ID8to identify302the bundle13and in particular a list9(of the bundle13) of the domain names14as members of the bundle13. The command module36can identify304the domain expiry date DED (e.g. object15) for each of the domain names14of the bundle13and to update306(i.e. renew) and report310the domain expiry date DED for each of the domain names14of the bundle13. Accordingly, once synchronized for the domain expiry date DED, then the subsequent renewal process for a plurality of domain names14of the bundle13is then advantageously simplified.

Further Example Operations of the Command Module36

An example operation of the command module36is as follows, referring toFIGS. 1 and 2, synchronizing management of a plurality of domain names14in a Domain Name System (DNS) can be implemented by the registry operator20and/or registry services provider22by: receiving a management request35from a domain name registrant12for an action as a maintenance operation on an object15unique to a domain name14of the DNS, the domain name14having synchronized objects15with another domain name14being stored as a domain name bundle13including the domain name14in a domain name database18; changing the object15by the command module36in the domain name database18according to the action; identifying the another domain name14in the domain name bundle13by inspecting a list of domain names contained in the bundle13; requesting a change to a corresponding object15to the object15for the another domain name14with the action in order to propagate the registration operation performed on the object15to the corresponding object15, the corresponding object15being unique to the another domain name14; and forwarding a reported result34of the action to the domain name registrant12, the object15and the corresponding object15representing the synchronized objects15by having the same parameter value, an owner to all domain names14in the domain name bundle13being the domain name registrant12. The management request35can include an action17such as a synchronization17action. The management request35can include an action17such as a renew17action.

A further example operation of the command module36is as follows, referring toFIGS. 1 and 2: receiving a subsequent request35from the domain name registrant12for a subsequent action as a subsequent maintenance operation on the object15unique to the domain name14of the DNS; changing the object15in the domain name database18according to the subsequent action; identifying the another domain name14in the domain name bundle13; requesting a subsequent change to the corresponding object15for the another domain name14with the subsequent action in order to propagate the subsequent registration operation performed on the object15to the corresponding object15; and forwarding a reported result34of the subsequent action to the domain name registrant12. The subsequent request35can include an action17such as a synchronization17action. The subsequent request35can include an action17such as a renew17action.

A further example operation of the command module36is as follows, referring toFIGS. 1 and 2: receive a subsequent request35from the domain name registrant12for a subsequent action as a subsequent maintenance operation on a different object15unique to the domain name14of the DNS; changing the different object15in the domain name database18according to the subsequent action; identifying the another domain name14in the domain name bundle13; requesting a subsequent change to the corresponding different object15for the another domain name14with the subsequent action in order to propagate the subsequent maintenance operation performed on the different object15to the corresponding different object15; and forwarding a reported result34of the subsequent action to the domain name registrant12. The subsequent request35can include an action17such as a synchronization17action. The subsequent request35can include an action17such as a renew17action.

A further example operation of the command module36is as follows, referring toFIGS. 1 and 2: receiving a subsequent request35from the domain name registrant12for a subsequent action as a subsequent maintenance operation on the corresponding object15unique to the another domain name14of the DNS; changing the corresponding object15in the domain name database18according to the subsequent action; identifying the domain name14in the domain name bundle13; requesting a subsequent change to the object15for the domain name14with the subsequent action in order to propagate the subsequent operation performed on the corresponding object15to the object15; and forwarding a reported result34of the subsequent action to the domain name registrant12. The subsequent request35can include an action17such as a synchronization17action. The subsequent request35can include an action17such as a renew17action.

A further example operation of the command module36is as follows, referring toFIGS. 1 and 2: receiving a subsequent request35from the domain name registrant12for a subsequent action as a subsequent maintenance operation on a different corresponding object15unique to the another domain name14of the DNS; changing the corresponding different object15in the domain name database18according to the subsequent action; identifying the domain name14in the domain name bundle13; requesting a subsequent change to a different object15for the domain name14with the subsequent action in order to propagate the subsequent operation performed on the corresponding different object15to the different object15; and forwarding a reported result34of the subsequent action to the domain name registrant12. The subsequent request35can include an action17such as a synchronization17action. The subsequent request35can include an action17such as a renew17action.

It is recognised that one of the maintenance operations could be updating the objects15in the object set to reflect a change in registrar14of the bundle13and all domain names14contained therein.

The action can be implementing actions on all domain names14of the domain name bundle13owned by the domain name registrant12, for example actions such as check, info/status, update/mod, delete/del, transfer, renew, synchronization. It is recognised that all domain names14of the domain name bundle13can be stored in the domain name database18of a common registry20. It is recognised that all domain names14of the domain name bundle13can be associated with a common registrar16. Further, the forwarded result34can include details on the synchronized objects15for the domain name14and the another domain name14.

Further, it is recognized that any of the domain names14of the bundle13can be identified in the request32,35in order to affect all domain names14in the bundle13.

In view of the above descriptions of storage18for the computer devices100(seeFIG. 3) of registry operator20and service22, storage18can be configured as keeping the stored data (e.g. objects15, lists8,9) in order and the principal (or only) operations on the stored data are the addition/amendment of or removal of the stored data from storage18(e.g. FIFO, FIAO, etc.). For example, storage18can be a linear data structure for containing and subsequent accessing of the stored data and/or can be a non-linear data structure for containing and subsequent accessing of the stored data.

Further, storage18receives various entities such as data that are stored and held to be processed later. In these contexts, storage18can perform the function of a buffer, which is a region of memory used to temporarily hold data while it is being moved from one place to another (i.e. between the between computer devices100). Typically, the data is stored in the memory when moving the data between processes within/between one or more computers. It is recognised that storage18can be implemented in hardware, software, or a combination thereof. The storage18is used in the network system10when there is a difference between the rate/time at which data is received and the rate/time at which the data can be processed (e.g. ultimately by the devices100).

Further, it will be understood by a person skilled in the art that memory/storage18described herein is the physical place where data can be held in an electromagnetic or optical form for access by the computer processors/modules. There can be two general usages: first, memory is frequently used to mean the devices and data connected to the computer through input/output operations such as hard disk and tape systems and other forms of storage not including computer memory and other in-computer storage. Second, in a more formal usage, memory/storage18has been divided into: (1) primary storage, which holds data in memory (sometimes called random access memory or RAM) and other “built-in” devices such as the processor's L1 cache, and (2) secondary storage, which holds data on hard disks, tapes, and other devices requiring input/output operations. Primary storage can be faster to access than secondary storage because of the proximity of the storage to the processor or because of the nature of the storage devices. On the other hand, secondary storage can hold much more data than primary storage. In addition to RAM, primary storage includes read-only memory (ROM) and L1 and L2 cache memory. In addition to hard disks, secondary storage includes a range of device types and technologies, including diskettes, Zip drives, redundant array of independent disks (RAID) systems, and holographic storage. Devices that hold storage are collectively known as storage media.

A database is one embodiment of memory18as a collection of information that is organized so that it can easily be accessed, managed, and updated. In one view, databases can be classified according to types of content: bibliographic, full-text, numeric, and images. In computing, databases are sometimes classified according to their organizational approach. The most prevalent approach is the relational database, a tabular database in which data is defined so that it can be reorganized and accessed in a number of different ways. A distributed database is one that can be dispersed or replicated among different points in a network. An object-oriented programming database is one that is congruent with the data defined in object classes and subclasses. Computer databases typically contain aggregations of data records or files, such as sales transactions, product catalogs and inventories, and customer profiles. Typically, a database manager provides users the capabilities of controlling read/write access, specifying report generation, and analyzing usage. Databases and database managers are prevalent in large mainframe systems, but are also present in smaller distributed workstation and mid-range systems such as the AS/400 and on personal computers. SQL (Structured Query Language) is a standard language for making interactive queries from and updating a database such as IBM's DB2, Microsoft's Access, and database products from Oracle, Sybase, and Computer Associates.

Memory/storage18can also be defined as a physical electronic holding place for instructions and data that the computer's microprocessor can reach quickly. When the computer is in normal operation, its memory usually contains the main parts of the operating system and some or all of the application programs and related data that are being used. Memory is often used as a shorter synonym for random access memory (RAM). This kind of memory is located on one or more microchips that are physically close to the microprocessor in the computer.

In terms of a server (acting as a client or as a server of a classic client-server relationship), it is recognised that the computer devices100can be configured as hardware, software, or typically a combination of both hardware and software to provide a network entity that operates as a socket listener. It is recognised that any computerised process that shares a resource (e.g. data) to one or more client processes can be classified as a server in the network system10. The term server can also be generalized to describe a host that is deployed to execute one or more such programs, such that the host can be one or more configured computers that link other computers or electronic devices together via the network11. The computer devices100implementing functionality of registry operator20and service22can provide specialized services across the network11, for example to private users inside a large organization or to public users via the Internet11. In the network system10, the servers can have dedicated functionality and/or can share functionality as described. Enterprise servers are servers that are used in a business context and can be run on/by any capable computer hardware. In the hardware sense, the word server typically designates computer models intended for running software applications under the heavy demand of a network11environment. In this client-server configuration one or more machines, either a computer or a computer appliance, share information with each other with one acting as a host for the other. While nearly any personal computer is capable of acting as a network server, a dedicated server will contain features making it more suitable for production environments. These features may include a faster CPU, increased high-performance RAM, and typically more than one large hard drive. More obvious distinctions include marked redundancy in power supplies, network connections, and even the servers themselves.

Referring toFIG. 3, a computing device100implementing functionality of registry operator20and service22can include a network connection interface101, such as a network interface card or a modem, coupled via connection118to a device infrastructure104. The connection interface101is connectable during operation of the devices to the network11(e.g. an intranet and/or an extranet such as the Internet), which enables the devices to communicate with each other as appropriate. The network11can support the communication of the communications20,26,32,34,35, and the related content.

Referring again toFIG. 3, the device100can also have a user interface102, coupled to the device infrastructure104, to interact with a user (e.g. server administrator—not shown). The user interface102can include one or more user input devices such as but not limited to a QWERTY keyboard, a keypad, a stylus, a mouse, a microphone and the user output device such as an LCD screen display and/or a speaker. If the screen is touch sensitive, then the display can also be used as the user input device as controlled by the device infrastructure104.

Referring again toFIG. 3, operation of the device100is facilitated by the device infrastructure104. The device infrastructure104includes one or more computer processors108and can include an associated memory122(e.g. memory18). The computer processor108facilitates performance of the device100configured for the intended task (e.g. of the respective module(s)30,36,40of service22, operator20) through operation of the network interface101, the user interface102and other application programs/hardware of the device100by executing task related instructions. These task related instructions can be provided by an operating system, and/or software applications located in the memory122, and/or by operability that is configured into the electronic/digital circuitry of the processor(s)108designed to perform the specific task(s). Further, it is recognized that the device infrastructure104can include a computer readable storage medium109coupled to the processor108for providing instructions to the processor108and/or to load/update the instructions107(e.g. modules30,36,40). The computer readable medium can include hardware and/or software such as, by way of example only, magnetic disks, magnetic tape, optically readable medium such as CD/DVD ROMS, and memory cards. In each case, the computer readable medium may take the form of a small disk, floppy diskette, cassette, hard disk drive, solid-state memory card, or RAM provided in the memory module. It should be noted that the above listed example computer readable mediums can be used either alone or in combination.

Further, it is recognized that the computing device100can include the executable applications comprising code or machine readable instructions for implementing predetermined functions/operations including those of an operating system and the modules, for example. The processor108as used herein is a configured device and/or set of machine-readable instructions for performing operations as described by example above, including those operations as performed by any or all of the modules30,36,40. As used herein, the processor108may comprise any one or combination of, hardware, firmware, and/or software. The processor108acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information with respect to an output device. The processor108may use or comprise the capabilities of a controller or microprocessor, for example. Accordingly, any of the functionality of the modules may be implemented in hardware, software or a combination of both. Accordingly, the use of a processor108as a device and/or as a set of machine-readable instructions is hereafter referred to generically as a processor/module for sake of simplicity. Further, it is recognised that the service22and/or operator20can include one or more of the computing devices100(comprising hardware and/or software) for implementing the modules, as desired.

It will be understood in view of the above that the computing devices100may be, although depicted as a single computer system, may be implemented as a network of computer processors, as desired.