Patent Application
20080201487
A domain name is a network address that identifies a computer or network that is connected to the Internet. Domain names typically include different domain name levels. A period separates the higher levels from lower levels. The level farthest to the right of the domain name is called the top-level domain (TLD), and it generally comprises a two- or three-letter descriptor (e.g., com, org, net, uk, or us) approved by the Internet Corporation for Assigned Names and Numbers (ICANN). Subsequent levels of the domain name are located in descending order to the left of previous levels. For purposes of the discussion herein, domain names are referred to as only the combination of level one and level two domain names, such as “microsoft.com.” Meanwhile, domain-name levels greater than two will be referred to as subdomains. For example, the web page one.two.microsoft.com contains a domain, “microsoft.com,” and two subdomains, “two.microsoft.com” and “one.two.microsoft.com.”
Every time a user requests a domain name, one or more domain name system (DNS) servers translate the domain name into a machine-readable IP address. Many times, however, the IP address for a given machine may change. Servers typically have static IP addresses that do not change very often, but a home machine that is connected to the Internet through a modem often has an IP address that is assigned by an internet service provider (ISP). Consequently, the IP address of the home machine may be different for each session of internet connectivity. Typically, this is referred to as a dynamic IP address. Dynamic DNS services can help map these dynamic IP addresses to the associated domain names' current IP addresses. DNS servers, however, only provide dynamic DNS service to the owner of the single domain.
Rights to use a single domain name, as well as all subdomain names, are transferred exclusively to a single entity. This entity becomes the owner of the particular domain name. For convenience, the licensee will be referred to herein as the “owner” to be consistent with general nomenclature in the art. Domain name vendors do not license rights to subdomains. However, users of subdomains have limited rights, because the right to control the subdomain lies with the owner. The owner of a single domain name, and all subdomain names thereof, may allow other users to utilize a subdomain name of their single domain name. For example, an owner of a web site (e.g., “valuablebaseballcards.com”) could allow a friend to create a web page for a subdomain (e.g., “baberuth.valuablebaseballcards.com”). Consequently, an owner of this subdomain cannot receive dynamic DNS service for the subdomain, unless he or she was the owner of the corresponding domain, and a subdomain user may have problems with Internet connectivity.
This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter
Some embodiments described herein relate to creating a subdomain name of a domain name. The domain name is associated with an IP address for a computing device. An application can be downloaded onto a client or remote computing devices and is configured to submit the domain name as well as subdomain names for registration. Requests for approval of subdomain names are submitted by users through the application. The owner of the domain name approves the requests, granting users ownership of subdomain names. Alternatively, the owner of the domain may pre-approve all requests for subdomains. Once a user receives a subdomain name, the subdomain is automatically registered to receive dynamic DNS services.
Other embodiments described herein relate to various modules that can associate a subdomain with a user and enable dynamic DNS service be provided to the subdomain. A client application is configured to submit a request from a domain name owner to allow users to gain access to subdomain names. A remote application is configured to submit a request from a secondary user to register for a subdomain name. A domain module determines whether the first user will allow association of the subdomain name with the domain name, and, if so, a sign-up module registers the subdomain name and associated IP address. Updated IP addresses for the subdomain can then be transmitted from a remote computing device to a server.
The present invention is described in detail below with reference to the attached drawing figures, wherein:
The subject matter described herein is presented with specificity to meet statutory requirements. The description herein, however, is not intended to limit the scope of this patent. Rather, it is contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the term “block” may be used herein to connote different elements of methods employed, the term should not be interpreted as implying any particular order among or between various steps herein disclosed.
In general, embodiments described herein generally relate to allowing a plurality of users to create subdomains stemming from a single domain managed by an owner. For example, a user named John owns a domain called john.com. It could be used to register subdomains for John's sister and father (e.g., dad.john.com and sister.john.com). The registered subdomains would provide a human-readable address, which could be translated into an IP address by a DNS service. In one embodiment, the owner of the single domain is able to add, manage, and delete subdomains of the owner's domain.
Some embodiments described herein also relate to providing dynamic DNS service to the subdomains of a domain. As previously mentioned, conventional dynamic DNS services are only provided to owners of domain names. Also, only owners can set up domains to receive dynamic DNS service. In one embodiment, a user can download an application from a web site that enables a user to register a subdomain underneath a domain name and receive dynamic DNS service for the subdomain, without authorization from the owner. Thereafter, the dynamic DNS service may be used to update a DNS server with dynamic IP addresses associated with the subdomain.
Domain names and subdomain names, as discussed herein, refer to stored web pages. Rather, either a domain name or a subdomain name refers to a user-friendly address of any computing device on the Internet. For example, jill.doe.com could represent the address of Jill's home computer. In such an example, a user could access Jill's home computer by making a request, using a protocol, with a uniform resource locator (URL) that includes the subdomain jill.doe.com. Examples of protocols that can be used to access various type of information over the Internet include, without limitation, the hypertext protocol (HTTP), file transfer protocol (FTP), secure sockets layer (SSL), and secure http (HTTPS).
Having described a general overview of the embodiments described herein, an exemplary operating environment is described below. Referring initially to
Some embodiments may be described in the general context of computer code or machine-useable instructions, including computer-executable instructions such as program modules, being executed by a computer or other machine, such as a PDA or other handheld device. Generally, program modules including routines, programs, objects, components, data structures, and the like, refer to code that perform particular tasks or implement particular abstract data types. Each module described herein may represent executable source code written in a well-known language, such as, for example, C, C++, C#, Java, or the like. In addition, each module described herein may be embodied, at least in part, as an application program interface (API) or script. Embodiments described herein may be practiced in a variety of system configurations, including hand-held devices, consumer electronics, general-purpose computers, more specialty computing devices, etc. Embodiments described herein may also be practiced in distributed computing environments where tasks are performed by remote-processing devices that are linked through a communications network.
With continued reference to
Computing device 100 typically includes a variety of computer-readable media. By way of example, and not limitation, computer-readable media may comprise Random Access Memory (RAM); Read Only Memory (ROM); Electronically Erasable Programmable Read Only Memory (EEPROM); flash memory or other memory technologies; CDROM, digital versatile disks (DVD) or other optical or holographic media; magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, carrier wave or any other medium that can be used to encode desired information and be accessed by computing device 100.
Memory 112 includes computer-storage media in the form of volatile and/or nonvolatile memory. The memory may be removable, nonremovable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, cache, optical-disc drives, network cards (e.g., a network interface controller (NIC)), wireless cards, etc. Computing device 100 includes one or more processors that read data from various entities such as memory 112 or I/O components 120. Presentation component(s) 116 present data indications to a user or other device. Exemplary presentation components include a display device, speaker, printing component, vibrating component, etc.
I/O ports 118 allow computing device 100 to be logically coupled to other devices including I/O components 120, some of which may be built in. Illustrative components include a microphone, joystick, game pad, satellite dish, scanner, printer, wireless device, etc.
Turning now to
The client computing device 202 and the remote computing device 204 may be any type of computing device, such as device 100 described above with reference to
Network 212 may include any computer network or combination thereof. Examples of computer networks configurable to operate as network 212 include, without limitation, a wireless network, landline, cable line, digital subscriber line (DSL), fiber-optic line, local area network (LAN), wide area network (WAN), metropolitan area network (MAN), or the like. Network 212 is not limited, however, to connections coupling separate computer units. Rather, network 212 may also comprise subsystems that transfer data between servers or computing devices. For example, network 212 may also include a point-to-point connection, the Internet, an Ethernet, an electrical bus, a neural network, or other internal system.
In an embodiment where network 212 comprises a LAN networking environment, components are connected to the LAN through a network interface or adapter. In an embodiment where network 212 comprises a WAN networking environment, components use a modem, or other means for establishing communications over the WAN, to communicate. In embodiments where network 212 comprises a MAN networking environment, components are connected to the MAN using wireless interfaces or optical fiber connections. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may also be used.
The server 206 may be any type of application server, file server, or other well-known server configurable to perform the methods described herein. In addition, the server 206 may be either a dedicated or shared server. One example, without limitation, of a server that is configurable to operate as the server 206 is a PowerEdge® server manufactured by Dell, Inc®. The server 206 may also be configured to run server software, such as SQL Server 2005, which was developed by the Microsoft® Corporation, or Apache HTTP Server Project, developed by the Apache Software Foundation®.
Components of the server 206 may include, without limitation, a processing unit, internal system memory, and a suitable system bus for coupling various system components, including one or more databases for storing information (e.g., files and metadata associated therewith). The server 206 may also include, or be given access to, a variety of computer-readable media. By way of example, and not limitation, computer-readable media may include computer-storage media and communication media. In general, communication media enables each server to exchange data via network 212. More specifically, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and may include any information-delivery media. As used herein, the term “modulated data signal” refers to a signal that has one or more of its attributes set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above also may be included within the scope of computer-readable media.
The DNS server 208 is a server capable of translating a domain name into a web address and, in some embodiments, vice versa. In one embodiment, the DNS server 208 is electrically coupled to the DNS database 250. The DNS database 250 stores, in some embodiments, various resource records, zones, and other information used for DNS services. One skilled in the art will understand the inner-workings of the DNS server 208.
In an embodiment, the server 206 is electrically coupled to the ODNS database 210. The DNS database 250 and the ODNS database 210 are database management servers that may be set to organize data and respond to queries as either a relational database or an object-relational database. While the server 206, the DNS server 208, the DNS database 250, and the ODNS database 210 are illustrated as single units in
The client computing device 202 comprises a domain 214 and an ODNS application 216. The domain 214 is a domain name associated with the client computing device 202. In an alternative embodiment, not depicted in
The remote computing device 202 comprises a subdomain 242 and an ODNS application 216. The subdomain 242 is a subdomain name pointing to the remote computing device 204. Moreover, the subdomain 242 subtends the domain 214, meaning the subdomain 242 includes a higher level domain than the domain 214. For example, the subdomain 242 may be john.jane.doe, and the domain 214 would be jane.doe. In an alternative embodiment, not depicted in
The ODNS application 216 is downloadable from the server 206 and serves to facilitate communication with a dynamic DNS service (not shown in
For a variety of reasons, it may be advantageous for the owner to allow others to establish subdomains from the domain 214. For example, an owner may buy a domain (doe.com) that points to her personal computer and allow her brother to create a subdomain (john.doe.com) that points to his personal computer. The owner can easily access her brother's personal computer by submitting an http request with the domain name. This may enable the sister to view the brother's photographs or listen to his music. In another example, a small business may wish to create subdomains pointing to work computers in order to easily access company files over the Internet. In still another example, a particular domain name may be quite popular to many people. For example, a plethora of users may wish to have their own subdomain of hardcoreseattleseahawksfans.com.
As previously mentioned, conventional dynamic DNS services are not available for a subdomain unless a domain owner authorizes them. While this may pose a problem when the subdomain is associated with dynamic IP addresses. The IP addresses of the subdomain may not be recorded when they change. If the IP address is changed but not stored, the corresponding subdomain name cannot be associated with the correct IP address. As a result, requests for connection to the subdomain—such as, when a user wishes to view a web page—cannot be fulfilled.
The owner can access an interactive web site (the ODNS web site 218), which is hosted on the server 206, to allow subdomains (e.g., the subdomain 242) to be reserved under the domain 214. In an embodiment, the ODNS web site 218 allows users to register subdomains for dynamic DNS services without owner authorization. The ODNS web site 218 comprises a sign-up module 220, list domains module 222, download client module 224, domain module 230, manage requests module 228, and invite module 226. In operation, these six modules utilize the following application programming interfaces (APIs): setup API 234, update IP API 238, IP_Ping API 238, IsDomainAvailable API 240, and CancelDynamicDNS API 241. In one embodiment, the aforementioned modules and APIs reside on the server 206.
The setup API 234 is configured to assign the subdomain 242 to the secondary user. In operation, the setup API 234 receives the domain 214 or the subdomain 242 as inputs and creates a secure token string based on a user-verification information. In an embodiment, the secure string is stored on the ODNS database 210 in a user table 248. The user table 248 stores a plurality of records detailing the association of users and domains or subdomains. For example, the setup API 234 might store a string with indications that the owner is affiliated with the domain 214.
The update IP API 238 is configured to receive secret DNS tokens and updated IP addresses, and assign the updated IP addresses to the corresponding domain or subdomain. In operation, the update IP API 238 provides dynamic DNS service to domains and subdomains registered at the ODNS web site 218. In an embodiment, the update IP API 240 stores the updated IP address along with an association to the subdomain specified by the DNS token in a record on the user table 248. For example if john.jane.doe originally had an IP address of 123.234.122.155 that later was assigned 234.101.115.102, the latter address would replace the prior address in the record. As a result, subdomains with dynamic IP addresses can be automatically updated without authorization from the owner.
The IsDomainAvailable API 240 is configured to check the availability of a particular subdomain name. In other words, this API determines whether a requested subdomain is available for reserving. In one embodiment, this is done by querying the ODNS database 210, which accesses an open domain table 246. A record of available subdomains may be stored in an open domain table 246 on the ODNS database 210. Subdomains are considered available when they are registered through the sign-up module 220 (discussed below) but not assigned to a user.
The IP_Ping API 239 is configured to retrieve the IP address of a computing device. In operation, the IP_Ping API 239 receives the IP address of the computing device by either pinging the computing device or requesting the IP address from the DNS server 208. Any of the modules or APIs discussed herein may communicate with the IP_Ping API 239 to determine IP addresses for computing devices. In one embodiment, the update IP API 238 utilizes the IP_Ping API 239 to check whether an IP address for a computing device has changed. If so, the IP address retrieved by the IP_Ping API 239, in one embodiment, is communicated to the update IP API 238, which then stores the new IP address in either the ODNS database 210 or the DNS database 250. One skilled in the art will understand that various methods exist for retrieving a computing device's IP address, and embodiments described herein are not limited to any particular method of pinging a computing device.
The CancelDynamicDNS API 241 is configured to terminate a dynamic DNS service for a given subdomain. For example, an owner of the remote computing device 204 may wish to cancel a dynamic DNS service for the remote computing device 204 if the subdomain 242's IP address becomes static. Or the price of the dynamic DNS service may compel the owner to cancel the service. Regardless of the reason, the user may initiate the CancelDynamiDNS API 241, in one embodiment, by selecting a cancellation option on the ODNS web site 218.
The sign-up module 220 is configured to register the subdomain 242 with the domain 214 if the domain module 230 (discussed below) determines the owner will allow the subdomain 242 to be associated with the domain 214. In one embodiment, the owner submits a request to the server 206 to register the domain 214 with a web service. The request may include various user-verification information about the owner. User-verification information may include, for example, a user name, password, street address, geographic location, date of birth, maiden name, social security number, or relationship information (e.g., brother, sister, married, single, etc.). In addition, the request may also include information about the domain 214, including: domain name, IP address, proof of ownership, etc. The sign-up module 220 receives the request from the user and determines whether to allow subdomains to other users. Such a determination is made by authenticating the owner with the user-verification information and determining whether the owner actually owns the domain 214. Additionally, the owner may designate whether the domain 214 is a static or dynamic IP address.
In another embodiment, the owner submits restrictions to the server 206 to limit the users who can receive a subdomain of the domain 214. For example, the owner may only wish to allocate subdomains to family members. An owner of a domain for a particular business may only wish to grant subdomains to employees or for specific computing devices—such as a work research computer. In one embodiment, the owner selects restrictions presented on the ODNS web site 218. In another embodiment, the owner submits restrictions that are stored on the client computing device 202 (e.g., an address list in an e-mail messenger) to the signup module 220. Alternatively, the owner may specify subdomains that cannot be allocated. Moreover, the owner may require users to pay a fee for a subdomain. Restrictions may also include, for example, a geographic location, street address, name, age, user authentication, or any other user information. One skilled in the art will understand that various restrictions or similar parameters may by submitted or used to register the domain 214.
A user of the client computing device 204 (hereinafter referred to as the secondary user) may submit a request to receive the subdomain 242 from the domain 214. The secondary user's request may include any of the aforementioned user-verification information as well as information relevant to any restrictions. In addition, the secondary user may also be prompted for the name of the subdomain 242.
The owner may eliminate the need for the secondary user to request the subdomain 242. In one embodiment, the owner pre-approves all requests for subdomains of the domain 214. Thereafter, any user requesting a subdomain is automatically approved without having to meet any restrictions. A pre-approved list of users who may obtain a subdomain may be developed by the owner and stored on the server 206. Any user requesting the subdomain 242 who is on the pre-approved list will automatically be given the subdomain 242. Alternatively, the owner may require a fee before allocating the subdomain 242. Embodiments are not limited to any particular registration process, as one skilled in the art will understand that many different methods can be used.
The list domains module 222 lets users view subdomains that are pre-approved for them to buy or acquire. In one embodiment, the list domains module 222 uses the IsDomainAvailable API 240 to determine which subdomains are currently available. The IsDomainAvailable API 240 may determine this by querying the ODNS database 210 to access the open domain table 246. For each returned, available subdomain, the list domain module 222 determines whether a requesting user is restricted by the owner. In one embodiment, all the subdomains that the requesting user is not restricted from and that are available are then returned.
The download client module 224 transmits the executable machine code of the ODNS application 216 to either the client computing device 202 or the remote computing device 204 for installation. The ODNS application 216 is configured to determine whether the IP address of either the domain 214 or the subdomain 242 has been modified. If so, the ODNS application 216 is configured to transmit updated IP addresses to the server 206 so the stored IP addresses of the domain 214 or the subdomain 242 can be saved. If either the domain 214 or the subdomain 242 includes a static IP address (i.e., one that does not change), the IP address is only transmitted once to the server 206.
The domain module 230 is configured to retrieve the request for the subdomain 242 and determine whether the owner has approved allocating the subdomain 242 to the secondary user. Such a determination is made by comparing information submitted by the secondary user with the restrictions placed by the owner or against a pre-approval list submitted by the owner. If the owner pre-approves the secondary user, the subdomain 242 is assigned to the secondary user. In one embodiment, the owner requires that the secondary user submit additional information, such as, for example, name, geographic location, street address, plans for the subdomain, or any other type of information. The domain module 230 may be configured to create a list of users who wish to obtain one or more subdomains of the domain 214. This list may be presented to the owner who may then determine which subdomains to allocate and what users should receive them.
The manage requests module 228 is configured to present to the owner requests for subdomains from secondary users if the owner has not pre-approved subdomain allocation. The owner may then select entities or users to receive subdomains.
The invite module 226 may be configured to invite the secondary user to obtain the subdomain 242. An e-mail message with detailed instructions on how to pick up the subdomain 242 may be sent to the secondary user. The detailed instructions are particularly helpful for users who are not computer savvy. Other forms of communication may also be initiated by the invite module 226. For example, an instant message, voice mail, phone call, or other type of notification can be sent as well. Embodiments are not limited thereto; rather, one skilled in the art will understand that numerous methods exist for communicating such an invitation to a user.
Turning now to
The domain name and IP address of the client computing device are transmitted to a server that will store such information, as illustrated at block 306. Once stored, the domain name and IP address are registered with the server, as illustrated at block 308. Updated IP addresses may subsequently be transmitted to account for dynamic IP addresses.
The owner can then submit a request to share the subdomain names of the domain name with one or more other users. If the owner specifies any restrictions for assigning subdomain names, such restrictions are stored, as illustrated at block 310. For example, the owner may only wish to grant certain domain names or only grant subdomains to specific people.
Referring to
Next, it is determined whether the secondary user can receive the subdomain name, as illustrated at decision block 406. A domain module (e.g., the domain module 230 discussed above) can be configured to determine whether the owner will grant the secondary user the subdomain. The owner can be notified of the secondary user's request and asked to decide whether to give the secondary user the subdomain. In addition, the domain module may be configured to determine whether the secondary user has been restricted by the owner.
If the secondary user is not approved, the subdomain is not allocated, as indicated by the NO path from decision block 406. If the secondary user is approved, the subdomain name and IP address are then registered by a server, as illustrated at block 408. Updated IP addresses associated with the subdomain name can then be transmitted through the ODNS application to accommodate dynamic IP addresses of the subdomain.
Referring to
Once the subdomain is registered to the secondary user, the secondary user may be prompted to obtain a dynamic DNS service, as illustrated at block 504. A web site, such as the ODNS web site 218, may present an option for registering to receive dynamic DNS service to the secondary user. The secondary user can request the dynamic DNS service by selecting such an option on the web site, as indicated at block 506. No authorization from the owner of the domain from which the subdomain subtends is required to register the subdomain for the dynamic DNS service.
If the secondary user requests the dynamic DNS service, the subdomain is configured to receive the dynamic DNS service, as illustrated at block 508. Once registered to receive the dynamic DNS service, the remote computing device 204 can transmit updated IP addresses to the server 206, or, alternatively, to the DNS server 208. The updated IP addresses include new IP addresses assigned to the subdomain. For example, if the IP address of the subdomain is changed from 123.45.110.90 to 102.56.178.201, the latter IP address is transmitted. In one embodiment, the ODNS application 216 transmits an updated IP address to the server 206. The server 206 may be configured to receive the updated IP address using the update IP API 238. The server 206 may also be configured to store the updated IP address in the user table 248 or transmit the updated IP address to the DNS server 208 for storage as a record resource. Moreover, updated addresses may be communicated from the remote computing device 204 to the server 206 using any type of push, pull, push-pull, broadcast, or poll method. For example, the remote computing device 204 may broadcast the updated IP address to the server immediately, or the server 206 may periodically request the IP address of the subdomain. One skilled in the art will understand that numerous methods exist for receiving updated IP addresses.
From the foregoing, it will be seen that this invention is one well adapted to attain all the ends and objects set forth above, together with other advantages which are obvious and inherent to the system and method. It will be understood that certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations. This is contemplated by and is within the scope of the claims.
