METHODS AND SYSTEMS FOR CROSS-DOMAIN TWO-WAY COMMUNICATION BY DYNAMIC WEB CONTENT

A method of modifying a first webpage from a first domain to enable cross-domain two-way communication is disclosed. The method comprising causing a web browser to load, as part of the first webpage, dynamic content comprising a UI to embed an iFrame into the first webpage that contains a second webpage from a second domain different from the first domain; to load a script file from within the iFrame; to bind one or more functions defined by the script file to the UI; to, in response to the user interacting with the UI, using the one or more functions to send a message to the second domain; and to, after receiving a response from a server at the second domain, update the UI in response to the received response. The method also enables a seamless, cross-domain user interface that maintains synchronization between webpages on different domains.

FIELD OF INVENTION

The present innovations generally address web frame and graphic compositing, and more particularly, to systems and methods for a Supra Boundary Web Compositor, directly linking via two-way communication a digital advertisement or other imported content displayed on a first website to server-side functionality of a second website, such as a shopping cart of that website.

BACKGROUND

The “holy grail” of the advertising industry has always been the ability to prove a direct connection between an advertisement and a purchase. But this goal has eluded advertisers. The industry's most famous quote, attributed to John Wanamaker, reads: “I know that half my advertising budget is wasted; the problem is I don't know which half!”

Even with the subsequent advent of the Internet, when digital advertising enabled a plethora of types of measurement of consumer behavior in relation to digital advertisements, sophisticated measurements of other consumer behavior on the Internet, and extremely elaborate uses of both online and offline data to target consumers with more effective advertising—all in hopes of documenting a direct connection between an advertisement and the consumer's subsequent action—it has only been possible to draw an indirect, inferred connection between the consumer's exposure to an advertisement and that consumer's subsequent behavior.

Further, even when an indirect connection is able to be inferred, it is almost impossible to attribute credit exclusively to the particular advertisement that was viewed, versus acknowledging the possibility that many other sources of motivation may have been at work, such as the viewing of other/different advertisements, exposure to other marketing mechanisms both online and offline (from Linear Television to Roadside Billboards), etc.

Additionally, interactive methods of advertising are often hampered by security settings in users' web browsers, which prevent AJAX (Asynchronous Javascript and XML) function calls from one domain to another. These function calls are the backbone of interactive web browsing and enable web pages to dynamically load content from an external source. Because the loading of content from an arbitrary source can be a significant security risk, many modern browsers allow only AJAX calls to the same domain. Thus, all data sources must be stored (or at least appear to be stored) in a single domain, creating an arbitrary restriction on dynamic content, forcing unnecessary architectural design decisions such as server-side workarounds to deal with the limitation, and hampering cooperation/integration from multiple data sources that could be best used to serve the consumer. Alternatively, a user who wants to access a website that attempts to draw from multiple data sources will have to use a browser that permits ultra-low security settings and deal with the inconvenience and danger of exposure to cross-domain scripting attacks while browsing the Internet.

Thus, there are advantages to having a system that can create advertisements that more directly link the advertisement to the purchase, as well as to systems that facilitate cross-domain communication for more functional ads.

SUMMARY

Ad-to-Cart (“A2C”) communication provides an elegant solution for linking a digital advertisement directly to a purchase on a merchant's website by literally linking the advertisement to the website's shopping cart and vice-versa (creating bidirectional communication and passing of data), such that a consumer can shop the merchant's online store directly within the advertisement itself, selecting products for purchase and adding them directly to a shopping cart within the advertisement that is in fact a direct instantiation of the shopping cart on the merchant's website. The shopping cart within the digital advertisement contains all the functionality and behaviors of the cart on the website itself, such as displaying an automatically-incrementing counter showing the number of items in the cart, and when the consumer clicks or taps the cart icon to proceed to check-out, the consumer is taken directly into the shopping cart on the merchant's website with all the selected products still populating the cart.

The direct communication between advertisement and cart is bidirectional, so that if the consumer further modifies the cart on the merchant's website and then returns to the advertisement, all such modifications remain reflected in the cart within the advertisement. And if further modifications are made within the advertisement, they are also reflected in the cart on the website.

In this way, the advertisement is being linked directly/literally to the purchase, with no room for doubt that the advertisement is directly driving the purchase.

Further, this invention represents an orders-of-magnitude leap in advertisement effectiveness, providing the consumer with instant gratification and providing the advertiser with a shorter, direct funnel from advertisement exposure to purchasing.

The presently-described systems and methods enable the consumer to add to cart continuously within the advertisement, and then check out once with a single click or tap. This bidirectional communication between advertisement and cart is enabled by an iFrame (“inline frame”), placed on the merchant's website, which is able to communicate directly with the website's shopping cart application in the same way that an actual consumer would be able to communicate directly/manually with the shopping cart.

In one aspect of this disclosure, a method for modifying a first webpage to enable cross-domain two-way communication is disclosed. The method includes loading, in the first webpage, dynamic content comprising one or more user interface elements. An iFrame is embedded into the first webpage whose source is set to a second webpage. A script file including an executable program, such as (but not limited to) a Javascript file, is loaded using the iFrame and one or more functions defined by the script file are bound to the one or more user interface elements. When the user interacts with the one or more user interface elements, the one or more functions are used to send a message to the second webpage, a response is received from the second webpage, and to update the one or more user interface elements in response to the received response.

DETAILED DESCRIPTION

In order to address the issues described above, methods and systems are provided to facilitate two-way communication between an advertisement or other content dynamically loaded in a first website and a second website that provides a user interface that a user might wish to interact with via the advertisement or other content.

FIG. 1depicts a network of computing devices to be used in a system for providing webpages that comprise interactive content with two-way cross-domain communication capabilities.

A user computing device100with software including a web browser is used to connect to the Internet120or another similar network. The user computing device100may be a PC, a mobile phone, a gaming console, or any other device capable of running a web browser to display a webpage to a human user.

The browser may be navigated to a URL at a first domain provided by a first web server105. A webpage at the first domain (200inFIG. 2) may incorporate instructions to the user's browser to load an advertisement or other dynamic content supplied by an advertisement server110or other content server.

Finally, a second web server115may provide a second webpage or other user interface (220inFIG. 2) that a user would be interested in interacting with. In a preferred embodiment, the second webpage would be a merchant website/shopping cart, but any interactive, web-based user interface could be involved, whether that is a web-based email client, a search engine, a social media page, online banking, or an interface for making an appointment or reservation.

Although in most typical use cases the servers105,110, and115are likely to be different devices, there is no reason that a single device could not serve the function of two or even three of the devices, since each device's primary role is to provide information when the browser on the user's computing device100requests it.

FIG. 2depicts a pair of user interfaces that are modified and combined by means of methods and systems described herein.

The first webpage200includes a normal region for content205, as well as, in a preferred embodiment, a top banner or side banner region for displaying the advertisement or other dynamic content210.

The second webpage or user interface220provided by the second web server115includes some number of buttons or other user interface elements225. In a preferred embodiment, the advertisement or other dynamic content210incorporates an identical set of buttons or user interface elements215so that the advertisement or other content almost appears to be a window directly into the second webpage or user interface220, with the same look and feel.

FIG. 3depicts a method for augmenting the first webpage to add two-way, cross-domain communication with the second webpage on a different site and domain from the one being augmented.

When a user visits the webpage200in a browser on the user's computer100, in accordance with the code of webpage200, the browser downloads an advertisement or other content210from the advertisement server110and displays it within the webpage (Step300).

After the content is loaded, a hidden iFrame is added to the webpage200(Step305). In a preferred embodiment, the iFrame is completely hidden from the user and is invisible. In other embodiments, if browser or security settings prevent an invisible element from being created or from loading content, the iFrame may instead be arbitrarily difficult to see (for example, 1 pixel by 1 pixel in size) or placed in a location where it is unlikely to be seen (such as a bottom corner of the webpage). The hidden iFrame loads a webpage from the second webserver115, from a URL at the second domain.

For example, while implementation of is not limited to use of Javascript, this could be accomplished with Javascript code as follows:

The newly-created iFrame is then used to load a script file including an executable program, such as a, such as (but not limited to) a Javascript file (Step310) containing custom code for facilitating the cross-domain communication.

For example, a function that is within the Javascript file and becomes accessible to the digital advertisement210might read:

The function(s) provided in the custom code are bound to one or more elements of advertisement210(Step315) so that interactions with the advertisement, including clicking, mouseovers, typing, dragging, etc. will cause the function(s) to be called.

For example:

Additionally, the advertisement or other dynamic content210may be updated to include information from the second webpage, such as the items that are already in a shopping cart from a previous visit to the second webpage.

For example:

Within the second webpage220in the iFrame, a “message listener” is set up (Step320). The message listener waits to receive messages specifically from the dynamic content210and only from that source. Any messages sent to the message listener from another source will be ignored.

For example:

When a user interacts with the dynamic content210(for example, clicking on a product within an advertisement that has an “Add to cart” label), a message is sent from the dynamic content210to the message listener (Step325). The message may contain information to be acted upon, such as a product id of the product to be added to the cart, credentials or tracking information from the user, or other relevant data.

When the message is received at the message listener, the iFrame containing the second webpage220makes an AJAX call or other function call that causes server-side code to be executed (Step330) to fulfill some command or query that was requested by the user (for example, actually adding items to the user's cart on the second website). From the point of view of the second web server115, there is no difference between the user navigating directly to the second website to perform the action and the user interacting with the advertisement or dynamic content210.

For example:

Code running within the iFrame receives and processes the request:

After the server-side code is executed, a response is provided (Step335) to indicate the success or failure of processing the request, and any other relevant information in the response. For example, a response to a request to add to a shopping cart may include both an indicator of success and a current number of items in the cart and/or the total value of purchases in the cart.

When the response is received, the advertisement or dynamic content210is updated (Step340) to reflect the information received. There may be, for example, a shopping cart displayed that looks identical to how the shopping cart would appear if the user had directly navigated to the second webpage to shop for items. The update may also include a success or error message or other information in addition to mimicking the second webpage.

As a result of these features, a user visiting a first webpage can interact with advertisements or other dynamic content that not only have the “look and feel” of a second webpage, but that actually update the user's cart or other session on the second webpage, without the user having to navigate the browser to the second webpage.

FIGS. 4A-4Gdepict a representative concrete user experience that may be accomplished using the presently described technology.

InFIG. 4A, a digital advertisement is loaded on a webpage, including a “hamburger” menu icon500.

InFIG. 4B, upon clicking or tapping the icon500, multiple product categories are displayed, as well as an exit icon505and a cart icon510.

InFIG. 4C, clicking a product category causes a second row of elements515to be added, indicating a series of items that can be added to a cart.

InFIG. 4D, clicking any of the “Add to cart” buttons will actually cause cart icon510to be updated to indicate items have been added.

InFIG. 4E, if the user clicks on the cart icon510, the browser will navigate to the second website (pictured below) and display the traditional cart, containing the items the user had added through the advertisement.

InFIG. 4F, the user may change the number of items in the cart using increase or decrease buttons520.

InFIG. 4G, if the user returns to the original webpage and views the advertisement again, the cart icon510will have updated to reflect the current number of items in the cart, even though the advertisement was not used to add or remove the items most recently changed.

Any changes that are made in either interface are reflected in the other automatically, resulting in a seamless user experience despite the webpages being on two different domains.

Other possible applications of the presently-described technology may include interactive polling (where a user can vote on a political/sports/entertainment option and see the votes of others in real time), interactive games with other players, streamlined communications interfaces such as instant messaging or social media, and

AlthoughFIG. 1depicts a preferred configuration of computing devices to accomplish the software-implemented methods described above, those methods do not inherently rely on the use of any particular specialized computing devices, as opposed to standard desktop computers and/or web servers. For the purpose of illustrating possible such computing devices,FIG. 5is a high-level block diagram of a representative computing device that may be utilized for each of the computing devices and/or systems to implement various features and processes described herein. The computing device may be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types.

As shown inFIG. 5, the components of the computing device may include (but are not limited to) one or more processors or processing units500, a system memory510, and a bus515that couples various system components including memory510to processor500.

Processing unit(s)500may execute computer programs stored in memory510. Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single computing device or multiple computing devices. Further, multiple processors500may be used.

The computing device typically includes a variety of computer system readable media. Such media may be any available media that is accessible by the computing device, and it includes both volatile and non-volatile media. removable and non-removable media.

Program/utility550, having a set (at least one) of program modules555, may be stored in memory510by way of example, and not limitation, as well as an operating system, one or more application software, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment.

The computing device may also communicate with one or more external devices570such as a keyboard, a pointing device, a display, etc.; one or more devices that enable a user to interact with the computing device; and/or any devices (e.g., network card, modem, etc.) that enable the computing device to communicate with one or more other computing devices. Such communication can occur via Input/Output (I/O) interface(s)560.

In addition, as described above. the computing device can communicate with one or more networks, such as a local area network (LAN), a general wide area network (WAN) and/or a public network (e.g., the Internet) via network adaptor580. As depicted, network adaptor580communicates with other components of the computing device via bus515. It should be understood that although not shown, other hardware and/or software components could be used in conjunction with the computing device. Examples include (but are not limited to) microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.