Patent Application
20100299205
As there is an increasing number of users viewing information and ordering items and services electronically, there is a corresponding increase in the amount of supplemental content provided to users. This supplemental or “targeted” content can include elements such as advertising, related applications or contents, recommendations, etc. In some cases, this supplemental content is dynamically determined for specific users, user types, user demographics, user behaviors, groups, categories, pages, sites, or interfaces to be displayed. In other cases, supplemental content such as advertising is selected based on the “core” content of a page or other grouping of information to be displayed. In still other cases, supplemental content can be selected at random or using any of a number of algorithms for providing content to a specified number of users, regardless of the page or location of the content when displayed.
In the case of advertising, for example, many content providers work with an advertising entity that manages advertisements to be displayed or otherwise included with that provider's content. In order to display ads that are likely to be relevant to the user viewing the content, the provider may specify a category, type of content, user information or other appropriate types of information relating to the viewing of content by the user. In this way, the content provider can provide an ad that is likely to be of interest to the user based upon aspects such as the content, past user behavior, user preferences, etc. For example, if a user is viewing a page relating to children's books, then the provider might provide the advertising entity with a “children's books” category description that indicates the type of content the user is viewing. An advertiser or other such content provider can then select an ad or other supplemental content that is at least somewhat related to the category of children's books.
Unfortunately, this targeting information can be intercepted or otherwise captured by unauthorized third parties. For example, an advertising company can manipulate images for various advertisements to include code for capturing information from requests or links, such as uniform resource locators (URLs) for the advertisements. Using such information, the third party can obtain information about the types of pages a user visits by, for example, storing a user identifier in a cookie on the user's browser and tracking the category information for a given user identifier. In this way, when that user visits a site, advertisements can be targeted to that user regardless of the type of site on which the ad is displayed.
Such use of information enables third parties to track information about users without their knowledge. An increasing amount of attention is being paid to the exposure of such information by privacy advocates and others. Further, these third parties can target users based on this information, and thus can lure advertisers or other content providers that might otherwise work directly with the content provider. This third party is then using information captured from the content provider to take compensation and other opportunities away from the content provider.
Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:
a) and 3(b) illustrate frames of content corresponding to multiple domains that can be used in accordance with one embodiment;
Systems and methods in accordance with various embodiments of the present disclosure may overcome one or more of the aforementioned and other deficiencies experienced in conventional approaches to providing targeted and/or supplemental content in an electronic environment. Systems and methods in accordance with various embodiments provide for the protecting of targeting and other such information used to request supplemental content from other providers or domains that enables a provider to determine the type of content being requested, while preventing third parties from determining information such as the source of the initial content, targeting information used to determine the content, and other such aspects. Generally, a “domain” refers to an organized collection of network devices, applications, and/or services, which typically are identified using a domain “name.” A single content provider might utilize multiple domains for different purposes on a single page. Although a common use of the word “domain” in such a context often currently refers to Internet-based technology, it should be understood that domains can be used in any appropriate network setting, and that advantages of embodiments discussed and suggested herein can be applied to any of these networks as appropriate. Further, while the explanation below refers to advertisements for simplicity of explanation, it should be understood that various other types of supplemental or targeted content can be provided from other domains or entities as well, using such approaches, including types of supplemental content such as such as games, video, audio, text, and/or other such types of content. In some cases, this content from a separate entity will be referred to as “supplemental content” or “customized content.” It thus should be apparent that the use of advertising and advertising-related descriptions with respect to the various embodiments should not be interpreted as a limitation on the scope, advantages, or applicability of the various embodiments.
Systems and methods in accordance with various embodiments provide for the loading of targeted or supplemental content, such as advertising content, on a page or other grouping of content or information from a content provider. In many examples below the provider will be an electronic retailer or provider of an electronic marketplace, but it should be understood that the provider can be any appropriate publisher of content in an electronic environment. In an Internet-based example, this can include serving ads or other supplemental content to be displayed on a page of content in a browser, where the “core” content of the page comes from the original content provider of the page. Approaches discussed herein allow for this third party content to be specified and loaded from a third party without exposing contextual data, such as referral uniform resource locators (URLs) and URLs to an advertising (“ad”) server, supplemental content selection service, or other such entity that may contain information that could be used to build a profile for a particular customer or other user of the content provider site. Such an approach also protects the proprietary targeting, user, and categorization information of the provider that can be used by a third party to determine aspects such as the popularity of various portions of the provider site, behaviors of a user, and categories of advertising used by the provider. Various approaches also have the benefit that the pages can load various portions quickly and in parallel.
When used in an Internet-based context, at least one interface element such as an inline frame (“iFrame”), inline object, or block-level element can be used on a page to provide for use of a separate domain, herein referred to as a “shadow domain”. The interface element can be any appropriate element that includes a level of domain-based protection, such as HTML elements or objects that are prevented from cross-domain communication in a browser or other such application or interface. The use of a shadow domain in an iFrame allows a URL to be determined for the desired supplemental content without the identity of the original content provider being determinable based on the URL alone. Nested iFrames, or multiple other such interface elements, can be used to pass information to other domains, such as to a shadow domain and then on to one or more advertising entities, as well as to one or more advertising management entities. A first iFrame on a page can be what is referred to herein as a “friendly” iFrame. A “friendly” iFrame is an iFrame that comes from, or resides in, the same domain as the parent page (or another page or element including that iFrame. Because the iFrame is in the same domain, the iFrame is able to communicate with the parent page. Such an approach allows the iFrame to access information from the parent page in some embodiments, while also allowing content of the friendly iFrame to manipulate area outside the iFrame in others. Various other advantages can be obtained as well in accordance with the various embodiments.
An approach in accordance with one embodiment uses a friendly iFrame to obtain information to be passed to a supplemental content selection service, such as an ad server, whereby the selection service can select appropriate supplemental content (or a type of supplemental content) to display. A single iFrame file (or other set or grouping of information) can be used for various content types and providers, such that the file can be cached and thus does not necessarily need to be retransmitted to the client application for each instance of supplemental content. The iFrame file can include JavaScript or other such client-side code that is able to parse variables from the URL, or obtain variables from the parent page when in the same domain, to make a call to the appropriate selection service with the segmentation information needed to make a decision as to an appropriate supplemental to serve. The selection service can select content to serve, and in embodiments where the selection service does not actually provide the content, can return a reference to a file or other such information that is held on another third party domain. A call can be generated for a shadow domain file in a nested iFrame, within the first iFrame, which can be cached once downloaded so subsequent calls do not need to be made for each instance. Instead of targeting data or other such information from the content provider, however, the call to the shadow domain can include supplemental content parameters specified by the selection service. These parameters can also be passed through the URL. One way is to append the parameters following an anchor or “#” symbol, which has been traditionally been used to link to an anchor within the page of a URL. These parameters will be referred to herein as “anchor parameters” for sake of explanation, although it should be understood that these parameters generally do not function as anchors in such situations. A cached template file can be used in the shadow domain to call the supplemental content provider and locate the content within the nested iFrame. In this way, the content from the supplemental content provider can only see the referrer as the shadow domain, or possibly the first iFrame, but cannot see the original content provider referral information or anything about the parent page for which the supplemental was served. Further, the content from the supplemental content provider can only see the content parameters from the selection service, which might specify a particular type of content, and cannot see the targeting data originally provided from the content provider.
The illustrative environment includes at least one application server 108 and a data store 110. It should be understood that there can be several application servers, layers, or other elements, processes, or components, which may be chained or otherwise configured, which can interact to perform tasks such as obtaining data from an appropriate data store. As used herein the term “data store” refers to any device or combination of devices capable of storing, accessing, and retrieving data, which may include any combination and number of data servers, databases, data storage devices, and data storage media, in any standard, distributed, or clustered environment. The application server can include any appropriate hardware and software for integrating with the data store as needed to execute aspects of one or more applications for the client device, handling a majority of the data access and business logic for an application. The application server provides access control services in cooperation with the data store, and is able to generate content such as text, graphics, audio, and/or video to be transferred to the user, which may be served to the user by the Web server in the form of HTML, XML, or another appropriate structured language in this example. The handling of all requests and responses, as well as the delivery of content between the client device 102 and the application server 108, can be handled by the Web server. It should be understood that the Web and application servers are not required and are merely example components, as structured code discussed herein can be executed on any appropriate device or host machine as discussed elsewhere herein. Further, the environment can be architected in such a way that a test automation framework can be provided as a service to which a user or application can subscribe. A test automation framework can be provided as an implementation of any of the various testing patterns discussed herein, although various other implementations can be used as well, as discussed or suggested herein.
The environment also includes a development and/or testing side, which includes a user device 118 allowing a user such as a developer, data administrator, or tester to access the system. The user device 118 can be any appropriate device or machine, such as is described above with respect to the client device 102. The environment also includes a development server 120, which functions similar to the application server 108 but typically runs code during development and testing before the code is deployed and executed on the production side and is accessible to outside users, for example. In some embodiments, an application server can function as a development server, and separate production and testing storage may not be used.
The data store 110 can include several separate data tables, databases, or other data storage mechanisms and media for storing data relating to a particular aspect. For example, the data store illustrated includes mechanisms for storing production data 112 and user information 116, which can be used to serve content for the production side. The data store also is shown to include a mechanism for storing testing data 114, which can be used with the user information for the testing side. It should be understood that there can be many other aspects that may need to be stored in the data store, such as for page image information and access right information, which can be stored in any of the above listed mechanisms as appropriate or in additional mechanisms in the data store 110. The data store 110 is operable, through logic associated therewith, to receive instructions from the application server 108 or development server 120, and obtain, update, or otherwise process data in response thereto. In one example, a user might submit a search request for a certain type of item. In this case, the data store might access the user information to verify the identity of the user, and can access the catalog detail information to obtain information about items of that type. The information then can be returned to the user, such as in a results listing on a Web page that the user is able to view via a browser on the user device 102. Information for a particular item of interest can be viewed in a dedicated page or window of the browser.
Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server, and typically will include a computer-readable medium storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions. Suitable implementations for the operating system and general functionality of the servers are known or commercially available, and are readily implemented by persons having ordinary skill in the art, particularly in light of the disclosure herein.
The environment in one embodiment is a distributed computing environment utilizing several computer systems and components that are interconnected via communication links, using one or more computer networks or direct connections. However, it will be appreciated by those of ordinary skill in the art that such a system could operate equally well in a system having fewer or a greater number of components than are illustrated in
An environment such as that illustrated in
In order to provide all necessary content for the page, at least a portion of the content also might be provided by at least one other provider 208, such as an advertising entity providing advertising content. In this case, a Web server 220 might serve content from an application server 222 able to pull content from at least one repository 224, and the server 222 might send the content directly to the client device 202 across the network 204 or in some embodiments might send the content to the first provider 206 such that the first provider sends all page content together. In this example, the second provider 208 also might correspond to a separate domain. Although two content providers are shown, and the example is described with respect to three domains for a page, it should be understood that any of a number of providers and/or domains could be used to provide content for a page as known or used in the art.
a) illustrates an example of a page 300 that could be generated by a system such as that illustrated in
For example,
One reason for using separate frames with separate domains is that many conventional browsers or other such interface applications do not allow for cross-domain communication. Thus, while a content provider might want to display an ad or other type of supplemental content from another domain on that page, the provider may not want that domain to have any control over, or ability to modify, the content from the other domains. This not only gives the content provider control over what is displayed on the page (other than, to some degree, the content from the other domain), but reduces the risk for malicious attacks from the other domain or persons mimicking requests from the other domain. Such use also controls the real estate or portion of a given page that the other domain can control. Accordingly, information to be passed to the other domain typically is included in the initial call or request to that domain. Often, this takes the form of parameters passed in a uniform resource locator (URL) or other call to source the frame on the page.
In some conventional approaches, at least one domain-restricted interface element, such as an inline frame (commonly referred to as an “iFrame”), is used to display supplemental or targeted content such as advertisements from a separate domain. An iFrame is a structure in the hypertext markup language (HTML) that allows another HTML document or other such object to be inserted into an HTML page, similar to a standard frame. An iFrame typically is included in a page using an <iframe> tag including a source attributed to designate the URL of a page to be displayed in the iframe. An example of an iFrame tag is as follows:
<iframe src=“pageURL”></iframe>
where “PageURL” corresponds to the URL or location of the content. The iFrame tag can include various other attributes known in the art, such as to set dimensions of the iFrame. Further, the source attribute does not need to specify a page, but can point to a document, image, object, or other element capable of being displayed on a page. Because the iFrame is an inline element, the iFrame does not need to be used in a typical frameset, as described with respect to
A content provider thus can include an advertisement, such as a banner ad, for example, in a page by using the iFrame tag and providing a URL that points to the same or another domain. It often is the case that it is desirable to display an ad that is likely to be of interest to the user viewing the page. For example, if a user is viewing a page of children's books, an advertisement relating to children's books can be much more likely to be of interest to the user than a randomly selected advertisement, such as may relate to sporting goods or alcoholic beverages. Thus, it can be desirable to pass information to an advertising domain that can be used to determine and/or provide an appropriate advertisement. In a conventional approach, information for the page can be passed in the URL. For example, a link can be included in the iFrame source attribute that includes parameters relating to the content of the page to be displayed, such as:
<iframe src=“pageURL.com/books/children”></iframe>
Using such an approach, the content provider can provide parameters to the advertising domain that indicate a category, sub-category, or other such information relating to the content of the page. Other approaches can be used as well, such as including a name or information for a particular item being displayed, a request for a particular type of advertisement, etc.
A potential downside to such an approach, however, is that the information being passed to the advertising domain also can be exposed to a third party. If the request is sent across a publicly accessible network, such as the Internet, then unauthorized parties can attempt to intercept or monitor the requests. In some cases, a third party might include code in an advertisement or other such object that is able to capture information from the URL and provide that information to the third party or another such party. This information then can be used to determine a type of content that is of interest to a user. The information can be associated with an Internet protocol (IP) address, identifier in a user cookie, or other such identifier to attempt to associate the information with a particular user. Over time, a profile of a particular user can be developed that can allow the third party to target advertisements to that user, or to provide the information to another party that can use the profile to target advertisements or other content to the user.
Such an approach can be detrimental to the original content provider in a number of ways. For example, the types of content being browsed by a user on the site are exposed to outside parties, which the user can view as an invasion of privacy. This may lead to ill will with respect to the content provider, and can cause the user to no longer return to the provider's site. Further, third parties that are able to target ads or other such content to specific users can market targeted content to providers that is focused on specific user profiles. Entities such as advertisers then may choose to work with these third parties instead of the content providers. Further, these third parties can offer lower rates than the content providers, as content providers typically charge more for a directed ad on a specific page or site than a third party might offer for an ad that could be displayed on any site, but that would be targeted to a user profile. Thus, by exposing the data of the content provider, the content provider actually can actually end up reducing the advertising revenue directed to that provider.
Systems and methods in accordance with various embodiments address these and other issues by, for example, preventing unauthorized third parties from accessing proprietary targeting information, such as may be included in a URL used to call a supplemental content selection service or supplemental content server. As discussed, the targeting information can include categorization and other information that can be used to build a profile of the content provider, and can include behavioral or other information for a user that can be used to generate a profile for the user. In many cases the customer will not be identified via the targeting information, but information may be stored in a tracking cookie or other appropriate location that can allow a third party to build a profile over time.
As discussed, a system in accordance with at least one embodiment can utilize nested iFrames or other such interface elements to include advertising or other supplemental content on a page that is served from a third party provider.
As discussed, the first iFrame 404 can be a “friendly” iFrame that resides in the same domain as the parent page, here also in the provider domain. The use of a friendly iFrame on the page provides various advantages, such as the ability to pass information from the parent page to the iFrame page, as well as the ability of content served from the friendly iFrame to expand beyond the bounds of the frame to other areas of the parent page. If a single template page is used for the first iFrame, this page can be cached on a content delivery network (CDN), client device, browser, or other appropriate device or component such that the page will load more quickly and less bandwidth will be required. As an added benefit, certain content of the first iFrame 404 can expand beyond the bounds of the frame to other areas of the parent page 402.
The page for the first iFrame 404 can include JavaScript or other client-side code able to generate a second iFrame 406, if the second iFrame is not otherwise provided. This second iFrame can reside in another domain, such as a shadow domain, that is separate from the provider domain. The call to the actual third party ad provider can come from the shadow domain in the second iFrame, such that the ad and/or ad provider cannot obtain information from the parent page, or determine the original URL from the provider. Further, the call from the file in the shadow domain can include ad parameters specified by the ad server, instead of the targeting data from the content provider.
<iframe src=“seconddomain.com/iframe.html#adserver;targeting_data”>
This information is included after an anchor symbol (“#”) as anchor parameters, instead of after an argument (“?”) symbol, such that the anchor parameters will be interpreted together as an anchor on the page, and not as arguments, such that the URL will not be interpreted as a URL for a different page when the parameters change, allowing the page to be cached for differing parameters.
Further, the client-side code can be programmed to treat everything after the anchor symbol as arguments. If the parameter(s) after the anchor symbol do not exist as an anchor on the page, the browser will not do anything with the anchor as far as changing the field of view or location, such that there is no “jumping around” within the page as a result of the inclusion of the anchor parameters.
Once the first iFrame has the template file, a request can be sent to the ad server domain 606, which can pass the targeting data in the URL as well. This can take the form of, for example:
adserver.com/targeting_data
or
adserver.com#targeting_data.
Upon receiving the request, the ad server can analyze the targeting data and select information for an appropriate ad to be displayed. The ad server then can return ad parameters to be provided to an ad provider to obtain the targeted advertising content. In some embodiments the ad server can return a URL to use to obtain the ad, while in other embodiments the ad server will return the ad parameters and the client-side code on the template page of the first iFrame will generate the appropriate URL.
Once the browser 612 has the ad parameters from the ad server 606, a second, nested iFrame can be generated on the page in the first iFrame, such as via JavaScript on the template page of the first iFrame or via an iFrame URL returned from the ad server. If the file (or information) for the second nested iFrame is not available to the client device, a call can be made to the shadow domain 608 in at least one embodiment to obtain the file. If the file is available from cache (or another appropriate location for the client device), no call needs to be made to the shadow domain. When calling to the shadow domain, the call can have a form such as:
<iframe src=“shadow.com/ads.html#ad_parameters”>
When the page is obtained, from the shadow domain or from cache, etc., the browser 612 can submit a request to the ad provider 610 for the ad content to be served. This request can take the form of, for example:
adprovider.com/ad_parameters
or
adprovider.com# ad_parameters.
When the ad provider receives the request, the ad provider can return the requested content to the browser 612. The returned content can include content such as image, audio, video, Flash, gaming, or other such content, which can be combined with click-through links or other such information such that the code on the page in the second nested iFrame can generate the full ad to be rendered on the browser. In one embodiment, the script on the template page is programmed to determine that a first parameter indicates where the ad content is stored, the second parameter is used to identify the ad, and the third parameter provides the click-through URL that is to be used with the ad to direct the user to a specific location or address upon selection of the advertisement. The client-side script can assemble those pieces and load the ad (or other supplemental content) from the final or third party provider.
As discussed, such approaches can allow for targeted content to be served by a third party provider without exposing information such as targeting data, user behavior information, or the original referrer identity. There also can be additional benefits to such an approach. As discussed, the ability to use cacheable files for the first iFrame and shadow domain pages can improve the overall latency of the page, decreasing the overall loading time as less information needs to be transferred and content can be loaded in parallel from different domains without having to worry about the number of concurrent connections to any server, etc. For advertising, the overall number and rate of ads that are actually served can increase, which also can improve aspects such as click through rate and number of impressions. Such an approach also can provide a benefit in the scheduling and trafficking of ads, as a single file can be used instead of a file for each type of ad, as in other approaches, which requires building and maintaining a system to manage the hundreds or thousands of types of ads. The content provider also can save network bandwidth charges as the iFrame file will not need to be repeatedly sent, which can represent a huge cost savings for large providers.
As mentioned, another benefit to such an approach is that a friendly iFrame can allow advertising content to expand beyond the normal bounds of the iFrame and onto the real estate of the parent page. Such functionality allows for the inclusion of content such as expandable rich media, which is typically content that is able to stretch beyond an initial height and width when a customer rolls over, hovers over, clicks on, or interacts with the content, for example. In one embodiment, the expandable ads function as a layer over the page such that the underlying content is not modified or affected by the expansion. In another embodiment, expandable ads can push the surrounding content as those ads expand.
In some embodiments, multiple iFrames and/or other such domain-restrictive interface elements can exist on the same parent page. As the parameters that are extracted from the parent page are encoded into the iFrame page, calling different iFrame pages can cause different parameters to be extracted. Such functionality can be desirable in situations such as when there are a number of different ads to be displayed on the page. In some embodiments, the variables in the JavaScript block on the parent page can have an associative array with keys that correspond to the names of the respective iFrames or other interface elements to be used.
In order to better understand some of the example flows discussed above,
In the example process, the content provider receives a request for content 802. As discussed, this can comprise a hypertext transfer protocol (HTTP) request for HTML and/or related content submitted by a browser of a client device in an Internet-based context, or a similar request in other contexts as discussed elsewhere herein. The request can be a request for specific content, such as information for a particular item, a search request, a category-based request, etc. The content provider can generate the appropriate file and return the file to the client device in response to the request 804. As discussed, this file can include information that can be used to obtain advertising or other supplemental content, such as information specifying an ad selection service to contact and targeting data specifying parameters that are to be used in selecting the advertising. The file also can include code specifying the inclusion of at least one first iFrame on the page. As discussed, the file can include the targeting parameters in a block of JavaScript variables or other appropriate location that can be accessed by a friendly iFrame, or can be included in the anchor of a URL specified to an iFrame in any appropriate domain. When the client device receives the file, the code in the file will cause the client device to generate the first iFrame and load the specified file for the first iFrame. If the file or page is not available to the client device 806, the content provider (or other provider in various embodiments) will receive a request for the file to present in the first iFrame 808. The content provider then can return the file for the first iFrame 810, which will include code for performing such tasks as including a nested iFrame, obtaining ad parameters from the ad selection service, obtaining a page for the nested iFrame in a shadow domain, obtaining the ad from an ad provider using the ad parameters, and displaying the ad in the nested iFrame. Once the client device has the file for the friendly iFrame, the client can perform the tasks discussed above 812.
The client device will also cause a nested iFrame to be included in the first iFrame 920. As discussed, the nested iFrame can reside in the shadow domain to protect the referrer information and information on the parent page. The client device can determine whether the file for the nested iFrame in the shadow domain is located in cache 922, or is otherwise locally accessible. If not, the client device can submit a request for the file to the shadow domain 924 and receive the file 926. Once the client device has the file for the nested iFrame, (or at another appropriate time) the client device can send the request for ad content to the ad provider using the specified ad parameters 928. When the ad data is received from the ad provider 930, the client device can assemble and display the ad in the nested iFrame on the page 932. During portions of this process, the other content for the parent page (e.g., images or other such content) can be loading in parallel, which can improve the overall load speed of the page. Further, various steps of the process can be handled concurrently, or in different orders, and can be performed by other components or service as should be apparent. As discussed, although the description was presented with respect to advertising, it should be understood that other types of targeted or supplemental content can be used as well within the scope of the various embodiments.
As discussed above, the various embodiments can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices, or processing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless, and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dummy terminals, thin-clients, gaming systems, and other devices capable of communicating via a network.
Various aspects also can be implemented as part of at least one service or Web service, such as may be part of a service-oriented architecture. Services such as Web services can communicate using any appropriate type of messaging, such as by using messages in extensible markup language (XML) format and exchanged using an appropriate protocol such as SOAP (derived from the “Simple Object Access Protocol”). Processes provided or executed by such services can be written in any appropriate language, such as the Web Services Description Language (WSDL). Using a language such as WSDL allows for functionality such as the automated generation of client-side code in various SOAP frameworks.
Most embodiments utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP, OSI, FTP, UPnP, NFS, CIFS, and AppleTalk. The network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network, and any combination thereof.
In embodiments utilizing a Web server, the Web server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, Java servers, and business application servers. The server(s) also may be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that may be implemented as one or more scripts or programs written in any programming language, such as Java®, C, C# or C++, or any scripting language, such as Perl, Python, or TCL, as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase®, and IBM®.
The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (“SAN”) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers, or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch screen, or keypad), and at least one output device (e.g., a display device, printer, or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random access memory (“RAM”) or read-only memory (“ROM”), as well as removable media devices, memory cards, flash cards, etc.
Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.), and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed, and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting, and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services, or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or Web browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.
Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
