JP7791866B2 - System and method for a website - Google Patents

Description

The present invention relates to online applications and, in particular, to methods for using them in combination with third-party applications included therein.

There are numerous commercially available website building systems and other interactive application building tools that can be used to create and edit websites and other online applications. End users can access such websites using client software on a wide range of platforms, including ordinary personal computers, smartphones, tablets, and other desktop or mobile devices.

These website building systems come in a variety of forms, including fully online website building systems that are hosted on one or more servers connected to the Internet and accessed using Internet communication protocols such as HTTP (Hypertext Transfer Protocol). Creation, editing, and deployment of these website building systems are all performed online through direct server interaction.

Website building systems can be partially online or fully online. In partially online systems, website editing is performed locally on the user's machine and later uploaded and deployed to one or more central servers. Once the website is uploaded, these website building systems function in the same way as fully online website building systems.

Website building systems have an internal data architecture for the purpose of organizing data and elements within the system. This architecture may differ from the appearance of the target site as seen by users, and may also differ from the way typical HTML (Hypertext Markup Language) pages are sent to browsers. For example, the internal data architecture may include additional properties for each element on a page (such as author, creation date, access permissions, and links to templates), which are essential for editing and maintaining the site within the website building system, but are invisible to external end users (and possibly some editing users). The typical architecture of a site based on a website building system may consist of pages containing components (such as shape components, photo components, and text components, as well as single-page and multi-page containers containing mini-pages).

Components can be contentless, such as a star, which has no internal content (but does have color, size, position, and other attributes), or they can have internal content, such as a text paragraph component, which includes font, formatting, and layout information in addition to the text to be displayed. Of course, this content can vary from one text paragraph component to another.

Designers using such website building systems can design new sites from scratch (starting with a blank screen) or use predefined application templates created by the designers themselves, the system creators, or a community of designers. Website building systems can support templates that are simply a collection of components, templates that are complete pages (or mini-pages) or sets of pages, and templates that are complete websites.

When an application template is provided, designers are free to customize it, adding, removing, or modifying any element of the template to create their own version of the template. Such customizations can be performed by creating a modified version of the template (a separate version of the template). Alternatively, the website building system can apply customizations through an inheritance-type mechanism, which maintains a link to the original template and therefore reflects subsequent changes made to the template.

Additionally, the website building system can be extended using third-party applications and components embedded therein. Such third-party applications may be included in the website building system's design environment or may be purchased (or otherwise obtained) separately through various distribution mechanisms, such as from an application store (AppStore) built into the website building system or from a web-based or independent application repository (or AppStore) operated by the website building system (WBS) vendor or another organization. Furthermore, third-party applications can also be obtained directly from the third-party application vendor (with or without an AppStore), in which case the vendor provides the actual installation module or only an activation or access code.

Third-party applications may include any combination of front-end (display) elements and back-office elements (which are not displayed on the website). Third-party applications may be entirely back-office (i.e., contain no display elements), or entirely front-end (i.e., are only launched when used on the website), or a combination of the two.

The back-office elements of a third-party application may include features such as database communication options and external update options. For example, a third-party blog application may include back-office elements that allow it to receive updates from non-human sources (e.g., RSS news feeds from major news services) and from human sources unrelated to the website (e.g., a standalone smartphone application that can post blog entries).

The process of incorporating visual elements of third-party applications into the website in which they are included can be done in a variety of ways. Widget-type third-party applications can be embedded as components inside the pages of a website, while section-type third-party applications can be added to the website as one or more additional pages.

Furthermore, third-party applications (both widget and section types) can be single-page or multi-page third-party applications (with internal mini-pages represented as internal URL structures). The system can implement one, more, or all of the four possible combinations (widget or section, single-page or multi-page).

Multi-page third-party applications typically provide a default "landing" minipage, which may be the opening page, a specific internal minipage (e.g., the latest blog entry in a blog third-party application), a minipage selection screen, or some other minipage.

The use of third-party applications in websites based on the website building system is achieved through instances of the third-party applications. The website building system can support multiple uses of third-party applications at multiple levels, for example, allowing one instance of a third-party application across the entire website, allowing the creation of multiple instances of third-party applications within a website (but only one instance per third-party application), or allowing the creation of multiple instances of multiple third-party applications (but only one instance per page). Furthermore, it can also allow multiple instances of component-type third-party applications (but not section-type third-party applications) per page, and can also allow the creation of multiple instances of multiple third-party applications without restrictions on the number, multiplicity, or location of the third-party application instances.

An instance of a third-party application may have content that is specific to the instance. For example, a third-party application for an e-shop may have a product database associated with a particular instance that is different from the product database associated with another instance of the third-party application for the same e-shop (within the same site or another site).

For purposes of discussion, the website page (or minipage) that contains the third-party application and its minipages and elements (i.e., the "wrapper page") will be referred to as the containing web page and will be known to the entire website as the main site. The integrated page (including the main page and embedded TPA minipages/components) presented to the user will be referred to as the composite page. In the case of section-type third-party applications, the "virtual page" that contains the third-party application plays the role of the containing web page.

Third-party applications are typically deployed on the servers of the website building system vendor, the third-party application vendor, an external (fourth-party) server, or any combination of these servers. Third-party applications can also include elements that actually run on the end user's machine (e.g., statically installed browser extensions or JavaScript components that run dynamically inside the website building system's client-side code, as shown in Figure 1). We will refer to Figure 1 below.

The website building system vendor's server acts as a point of contact for the end user and responds to requests (possibly connecting to the third-party application vendor's server to receive the required information). The website building system can (if necessary) create a direct connection between the client's computer and the third-party application vendor's server, for example when video streaming is requested.

Instances of included third-party applications can have their own internal content, just as regular components have internal content. Referring to and as shown in Figure 2, the third-party applications can manage this content independently of the website building system and the website generated using the website building system. Multiple instances of one or more third-party applications can have shared content; for example, two online shop instances on two separate website pages can reference the same product database.

Output from included third-party applications can be incorporated into the containing web page in a variety of ways, for example:

Server-Side Processing: (Referring now to FIG. 3.) In this method shown in FIG. 3, the third-party application [a] (including design and display elements) and user-specific third-party application data [b] are merged by the third-party application's server code [c] running on the third-party application's vendor's server [d]. They are sent via communication medium [e] to the website building system's server code [f], which merges them with the containing web page information [g] and then sends them to the user's client station [h] for display.

Client-Side Processing: (Referring now to Figure 4.) In this method shown in Figure 4, the third-party application [a] (including design and display elements) and user-specific third-party application data [b] are merged by the third-party application's server code [c] running on the third-party application's vendor's server [d]. These are sent via a communications medium [e] to a client-side processing component [h]. The website building system's server code [f] sends the containing web page information [g] to this client-side processing component [h]. The client-side processing component [h] performs the merging of the two sources of information and presents the integrated application to the browser (or other client agent) [i].

iFrame Inclusion: (Referring now to FIG. 5.) In the method illustrated in FIG. 5, a third-party application [a] (including design and display elements) and user-specific third-party application data [b] are merged by the third-party application's server code [c] running on the third-party application's vendor's server [d]. These are sent via a communication medium [e] to a browser-based application [h] running inside a user agent (e.g., a web browser) [i]. The website building system's server code [f] sends the containing web page information [g] to the browser-based application [h]. The containing web page is created as a web page containing one or more iframe directives that include content from the third-party application's server [d]. Additional and alternative methods are also applicable.

US Patent Application Publication No. 2013/0219263

According to a preferred embodiment of the present invention, there is provided a system implementable on a website via a client/server system, the client/server system having at least one processor that processes instructions defining the system. The system includes at least one hub that coordinates at least one activity message between the website and at least one third-party application, the at least one activity message having a standardized format. The system further includes an activity coordinator that listens for the at least one activity message and adds data extracted from the at least one message to a stream associated with at least one identified contact and/or anonymous contact, where at least one of the identified contact and/or anonymous contact is a user of the website. The system further includes a contact coordinator that retrieves and analyzes contact-related information from the stream to enhance previously held information for the contact, and at least one database that stores the activity stream and contact-related information for use by the website and the contact.

Furthermore, in accordance with a preferred embodiment of the present invention, at least one hub includes at least one of: a router and tracker that routes and tracks at least one activity message between the website and at least one third-party application; a privacy policy enforcer that enforces a privacy policy between the website and at least one third-party application; a translator and adapter that applies at least one pre-specified message transformation/content adaptation rule between the website and at least one third-party application; a private data proxy that performs at least one of a private data proxy and a private data substitution and enforces user permission field restrictions between the website and at least one third-party application; and a verifier/signer that verifies the signature of at least one activity message using an input key of the at least one third-party application, transforms an external ID associated with the at least one activity message using an internal website ID, and signs the outgoing at least one activity message using an output key of the at least one third-party application.

Furthermore, in accordance with a preferred embodiment of the present invention, the activity coordinator includes at least one of a stream creator that identifies a contact associated with at least one activity message and creates a stream of data if no associated contact exists; a stream merger that merges data from at least one activity message into an existing stream and merges data from at least two of the activity streams into one stream; and a log creator that records activity data from the activity streams in at least one database.

Furthermore, according to a preferred embodiment of the present invention, the contact coordinator includes at least one of: a data extractor that extracts contact-related information from at least one of the activity message, the stream, another contact, and an external source; a data merger that merges at least two contact information records and merges the extracted contact-related information with the related information of an existing contact according to predefined merging rules, where the records have an association with the same identified contact; a contact handler that creates at least one of a new identifiable contact and an anonymous contact and tracks the contact's activity during the website session; and a data/permission handler that handles privacy protection and permissions for the extracted contact-related information.

Furthermore, in accordance with a preferred embodiment of the present invention, the router/tracker supports routing at least one activity message using a listening query specified by at least one third-party application.

Furthermore, in accordance with a preferred embodiment of the present invention, the stream merger includes an activity-to-stream merger that merges data into a stream associated with an identified contact, and a stream-to-stream merger that merges at least two separate streams into one stream.

Furthermore, in accordance with a preferred embodiment of the present invention, the stream-stream merger includes at least one of a horizontal stream merger that merges at least two separate streams according to identified common contacts, and a vertical stream merger that merges a stream created for an anonymous contact into a stream associated with a registered contact when the anonymous contact and the registered contact are associated at login or registration.

Furthermore, in accordance with a preferred embodiment of the present invention, the data merger includes a contact identifier that does at least one of the following: identifies the same primary ID field values in at least two of the contact information records; identifies primary ID field values in at least two of the contact information records that are the same when normalized; identifies the site user using a cookie; identifies the site user using a site login in the case of a registered user; or identifies the site user through a social login in the case of a site user with an account associated with a social network. The data merger further includes a combiner that combines contact information using at least one of linguistic analysis, syntactic analysis, and text analysis, and by referencing and utilizing external data sources and services; a conflict resolver that resolves conflicts between contact records according to predefined rules; a list value creator that creates list value fields and defines clear priorities between contact records; a horizontal contact merger that merges two unrelated contacts due to the detection of a common primary ID; and a vertical contact merger that merges an anonymous contact with a contact associated with a registered user when the anonymous contact and the contact associated with the registered user are combined at login or registration time.

Furthermore, in accordance with a preferred embodiment of the present invention, the horizontal contact merger includes a virtual merger that maintains at least two contact records as separate records and links the two contact records to each other to indicate that the two contact records represent the same contact.

Furthermore, in accordance with a preferred embodiment of the present invention, the vertical contact merger includes a virtual merger that maintains anonymous contacts and contacts associated with registered users as separate contacts and links the anonymous contacts and contacts associated with registered users to each other so that they are indicated as representing the same contact.

Furthermore, in accordance with a preferred embodiment of the present invention, the user permission fields are determined by the website and/or the website owner.

Furthermore, in accordance with a preferred embodiment of the present invention, the standardized format is at least one of a format defined by a predefined schema, a format defined by inheritance, a format defined by callback links, a format encoded and defined by at least one third-party application, and a format based on an external formal standard, an industry standard, or a de facto standard.

According to a preferred embodiment of the present invention, there is provided a method implementable on a website via a client/server system, the client/server system having at least one processor that processes instructions defining the method. The method includes the steps of: coordinating at least one activity message between the website and at least one third-party application, the at least one activity message having a standardized format; listening for the at least one activity message and adding data extracted from the at least one message to a stream associated with at least one identified contact and/or anonymous contact, the at least one identified contact and/or anonymous contact being a website user. The method further includes the steps of obtaining and analyzing contact-related information from the stream to enrich previously held information for the contact; and storing the activity stream and the contact-related information for use by the website and the contact.

Furthermore, in accordance with a preferred embodiment of the present invention, the coordinating step includes at least one of the following steps: routing and tracking at least one activity message between the website and at least one third-party application; enforcing a privacy policy between the website and at least one third-party application; applying at least one pre-specified message transformation/content adaptation rule between the website and at least one third-party application; implementing at least one of private data proxying and private data substitution and enforcing user permission field restrictions between the website and at least one third-party application; verifying the signature of the at least one activity message using an input key of the at least one third-party application, translating an external ID associated with the at least one activity message using an internal website ID, and signing the outgoing at least one activity message using an output key of the at least one third-party application.

Furthermore, in accordance with a preferred embodiment of the present invention, the listening and at least adding step includes at least one of the following steps: identifying a contact associated with at least one activity message and creating a stream of data if no associated contact exists; merging data from at least one activity message into an existing stream; merging data from at least two of the activity streams into one stream; and recording activity data from the activity streams in at least one database.

Furthermore, in accordance with a preferred embodiment of the present invention, the obtaining and analyzing step includes at least one of the following steps: extracting contact-related information from at least one of the activity message, the stream, another contact, and an external source; and merging at least two contact information records and merging the extracted contact-related information with related information of an existing contact according to predefined merging rules, where the records have an association with the same identified contact. Furthermore, the obtaining and analyzing step includes creating at least one of a new identifiable contact and an anonymous contact and tracking the contact's activity during the website session; and processing privacy and permissions for the extracted contact-related information.

Furthermore, in accordance with a preferred embodiment of the present invention, the routing and tracking step supports routing at least one activity message using listening queries specified by at least one third-party application.

Furthermore, in accordance with a preferred embodiment of the present invention, the merging step includes merging the data into a stream associated with the identified contact and merging at least two separate streams into one stream.

Furthermore, in accordance with a preferred embodiment of the present invention, the steps of merging data into a stream associated with an identified contact and merging at least two separate streams into one stream include at least one of the steps of horizontally merging at least two separate streams according to an identified common contact, and vertically merging a stream created for an anonymous contact into a stream associated with a registered contact when the anonymous contact and the registered contact are associated at login or registration.

Furthermore, in accordance with a preferred embodiment of the present invention, the step of merging at least two contact information records includes at least one of the following steps: identifying primary ID field values in at least two of the contact information records that are the same when normalized; identifying primary ID field values in at least two of the contact information records that are the same when normalized; identifying the site user using a cookie; identifying the site user using a site login in the case of a registered user; and identifying the site user through a social login in the case of a site user with an account associated with a social network. Furthermore, the step of merging at least two contact information records includes combining contact information using at least one of linguistic analysis, syntactic analysis, and text analysis, and referencing and utilizing external data sources and services; resolving inconsistencies between contact records according to predefined rules; creating list value fields and defining clear priorities between contact records; horizontally merging two unrelated contacts due to the detection of a common primary ID; and vertically merging an anonymous contact with a contact associated with a registered user when the anonymous contact and the contact associated with the registered user are combined at login or registration time.

Furthermore, in accordance with a preferred embodiment of the present invention, the horizontal merging step includes maintaining at least two contact records as separate records and virtually merging the two contact records by linking them to each other to indicate that the two contact records represent the same contact.

Furthermore, in accordance with a preferred embodiment of the present invention, the vertical merging step includes maintaining the anonymous contact and the contact associated with the registered user as separate contacts, and virtually merging the anonymous contact and the contact associated with the registered user by linking them together so that they are indicated as representing the same contact.

Furthermore, in accordance with a preferred embodiment of the present invention, the user permission fields are determined by the website and/or the website owner.

Furthermore, in accordance with a preferred embodiment of the present invention, the standardized format is at least one of a format defined by a predefined schema, a format defined by inheritance, a format defined by callback links, a format encoded and defined by at least one third-party application, and a format based on an external formal standard, an industry standard, or a de facto standard.

The subject matter which is regarded as the invention is particularly pointed out and distinctly described in the concluding portion of this specification. However, a better understanding of the invention, both as to its organization and method of operation, and of its objects, features, and advantages, can be obtained by reading the following detailed description in conjunction with the accompanying drawings.

Schematic diagram of the deployment configuration between the website building system and third-party applications Schematic diagram of internal content management for third-party applications Schematic diagram of including a third-party application in a containing web page via server-side processing Schematic diagram of including a third-party application in a containing web page via client-side processing Schematic diagram of including a third-party application in a containing web page via iframe inclusion Schematic of existing suboptimal third-party application display when page layout changes 1 is a schematic diagram of a system for integrating a website building system with one or more third-party applications, constructed and operative in accordance with the present invention; 1 is a schematic diagram of a system for integrating a website building system with one or more third-party applications, constructed and operative in accordance with the present invention; Schematic diagram of the Document Object Model compared to the Component Model Schematic diagram of the blog multipart third-party application example Schematic of an example modular third-party application for sale 1 is a schematic diagram of a different implementation of a communications hub constructed and operative in accordance with the present invention; 1 is a schematic diagram of a different implementation of a communications hub constructed and operative in accordance with the present invention; FIG. 11B is a schematic diagram of the elements of the communications hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention; FIG. 11B is a schematic diagram of a communication conversion process performed by the communication hub of FIGS. 11A and 11B constructed and operative in accordance with the present invention; 1 is a schematic diagram of a containing web page serving a third party application with an associated template constructed and operative in accordance with the present invention; 1 is a schematic diagram of a containing web page that includes a third party application with an associated template inside a minipage, constructed and operative in accordance with the present invention; FIG. 1 is a schematic diagram of a system constructed and operative in accordance with the present invention for coordinating and collecting data from various messages exchanged between a website building system and one or more embedded third-party applications. 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; 1 is a schematic diagram of an example of a graphical user interface displaying an activity stream associated with a contact, constructed and operative in accordance with the present invention; Schematic diagram of message passing for client-side and server-side third-party application activity messages Schematic of the login/logout process during a user's website session

It should be understood that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, corresponding or similar elements in the multiple figures have been designated by the same reference numerals.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. Additionally, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

The Applicant has recognized that there are numerous limitations in the current manner in which third-party applications are generally integrated into website building systems and in the current manner in which the integrated third-party applications and website building systems interact.

Such limitations include restricting the display of a third-party application to a single rectangular region inside the containing web page (this region is contained in the iframe). Further limitations include the ability of the third-party application to control the size and position of the third-party application's window and visual elements that are outside of the third-party application's actual display window (e.g., a dedicated display frame around the third-party application's window).

Third-party applications may have their own display styles (color schemes, fonts, text sizes, etc.). These styles may match some containing web pages, but may cause visual problems or inconsistencies on other containing web pages.

Another limitation is the inflexibility of the display of third-party applications from the containing site's perspective. When a site must be visually modified (e.g., for deployment to platforms with different screen sizes or due to dynamic layout events), the containing web page may be required to resize the window allocated to the third-party application. In such cases, the display of the third-party application is truncated, requiring scrolling via scroll bars to reach various sub-areas of the third-party application. See Figure 6, which shows an example of what can happen when the containing web page [a] is resized. The area allocated to the online shop's third-party application [b] is reduced, and the "Buy" button [c] cannot be displayed along with the contents of the shopping cart [d], requiring multiple scrolling actions to complete the purchase and significantly reducing the likelihood that the purchase will actually be completed.

It should be understood that a third-party application cannot interact with other components within the containing web page, and that such interaction may be necessary to achieve complex functionality. In particular, a third-party application cannot perform different actions depending on the type and content of the components within the containing web page. One example of this is a website that streams online cooking lessons. While watching the video in the background, a user may want another area of the screen to have a small area dedicated to broadcasting the latest news and weather information (such as a live stream from CNN). A user may want their learning session to automatically pause when the weather forecast for their area begins.

Furthermore, there is no clear and standard way for third-party applications to cooperate with each other, especially when these applications are provided by different vendors. Thus, a designer has no clear way to combine multiple third-party applications from different vendors. One example of this is the case of an e-commerce website that runs a module of a third-party ordering system and a different module of a shipping system. It may be desirable to order goods according to a shipping schedule, etc.

Applicant has recognized that this integration can be achieved through the use of structured two-way communication channels between the website building system and the third-party application instances contained therein, and between multiple different third-party application instances that may be implemented within the same containing page. These channels can also transfer information regarding layout, style, and additional information.

The following discussion focuses on the iframe inclusion method, which should be understood as the preferred method because it is built into and integrated into modern browsers and does not require the creation of dedicated integration code. Furthermore, the iframe inclusion method provides encapsulation and sandboxing capabilities supported by browsers, as well as inherent protection against hacking techniques such as cross-site scripting attacks that may be employed by malicious third-party applications.

7A and 7B, which illustrate a system 100 for integrating a website building system with one or more third-party applications in accordance with an embodiment of the present invention. FIG. 7A illustrates the system 100 during the design phase, and FIG. 7B illustrates the system 100 during runtime. As can be seen in FIG. 7A, the system 100 includes a client 10, a website building system 30 installed on a website building system (WBS) server 20, and one or more third-party applications 40 installed on one or more third-party application servers 50. The website building system 30 includes a WBS coordinator 21, an application repository 22, a WBS-side TPA property sheet 23, a third-party application (TPA) coordinator 24, and an AppStore 25 (which may include a searcher 26). The client 10 includes a page composer 12 and a client-side representation of the TPA property sheet 23. In some embodiments, the client 10 may further include a client-side representation of an AppStore 25. The page composer 12 includes a linker 13, which will be described in more detail below. The third-party server 50 includes a third-party application 40, an external TPA coordinator 51, and a TPA database 52, which stores components, templates, etc., of the third-party application 40 for use. Note that the system 100 may include multiple third-party servers 50 belonging to multiple vendors of the third-party application 40.

It should be understood that the TPA property sheet 23 can be invoked when attributes of an instance of a third-party application 40 are specified. It should further be understood that when invoked, the TPA property sheet 23 is displayed on the client 10 as a client-side representation of the TPA property sheet 23. It should further be understood that an offline embodiment can have its own property sheet as part of the installed client software, and therefore there is no application TPA property sheet 23 or repository.

It should be understood that a designer or end user 5 sitting in front of a client 10 can create their own website (or other online application) by using the page composer 12 to create website pages and interactions (inter-page and intra-page interactions). The designer 5 can select components, templates, etc., that are part of the website building system 30 and stored in the application repository 22 via the WBS coordinator 21. Additionally, the designer 5 can create a containing web page 203 that embeds a third-party application 40 instance from a third-party application 40, which can be pre-purchased and its templates, components, etc., stored in the application repository 22. In an alternative embodiment, purchased templates, components, etc., can be stored in the TPA database 52 and accessed via the external TPA coordinator 51. In yet another embodiment, templates, components, etc., for third-party applications 40 can be purchased as needed via the AppStore 25. A property sheet 23 can be specified by the designer 5 and can hold information (such as permissions, installation guides, and payment) about the purchased third-party application 40 instance, as described in more detail below. Additionally, the designer 5 can use the linker 23 to manually specify communication channels (if necessary) between multiple included third-party applications 40. It should be appreciated that the designer 5 can also use the linker 23 to specify specific communication connections and rules between the containing web page they are building and the instances of the third-party applications 40 included therein (such as the simultaneous display of a video and a CNN news report, as discussed above). It should be appreciated that the links created by the linker 23 can be modified throughout the life of the website.

It should be understood that the designer 5 may obtain the third-party application 40 through a channel external to the AppStore 25, such as an external AppStore operated by the vendor of the third-party application 40 or an external supplier. In such a case, the website building system 30 may register the third-party application 40 and its configuration data when the third-party application 40 is first installed on a website created by the designer 5 through the website building system 30.

It should be appreciated that in order for the linker 23 to establish a communication channel when necessary, the third-party application 40 must be able to properly recognize and identify components (including instances of other third-party applications 40) within the containing web page 203 with which it intends to communicate. In the case of associated template-based components (discussed in more detail below), this identification is performed in advance by the vendor of the third-party application 40. Components within the associated template may be given unique reference IDs, which the third-party application 40 may use when communicating with those components.

Furthermore, it should be appreciated that in the case of a multi-part third-party application 40 (i.e., a single third-party application 40 distributed across multiple iframes) (described in more detail below), the multiple parts can automatically know how to communicate with each other.

For components of the containing website page that are not included in the associated template (discussed in more detail below), the third-party application 40 can include a list of required (mandatory or optional) containing web page 203 components that must be present for the third-party application 40 to function. This list can be stored in a property sheet 23 and can include a unique ID, a description, and component details (e.g., a text component must be used as a blog talkback label). This list can be listed in the third-party application 40's entry in the AppStore 25, and the designer 5 can use the linker 23 to specify components (fields) in the containing web page 203 that meet the third-party application 40's requirements. It should be understood that the website building system 30 can dynamically create missing components of the containing web page 203 when an instance of the third-party application 40 is created, and the designer 5 can later move, resize, and fully specify these components.

Alternatively, the website building system 30 can expose all or part of the component model of the containing web page 203 to the third-party application 40 included in the containing web page 203. It should be understood that the component model in this case is the component model of the containing web page 203, not the Document Object Model (DOM). The Document Object Model (DOM) of the containing web page 203 can be a much more complex and detailed model than the component model because the actual containing web page 203 can include a large number of HTML elements (both hidden and visible) that are part of the infrastructure of the website building system 30 or that support the components of the containing web page 203. Therefore, the component model is much simpler.

Referring now to Figure 8, which shows how text component [a] can be implemented using several HTML constructs, including a surrounding div tag [b], an inner div tag [c], and frame "mini-widgets" [d1]...[d5]. The DOM model [e] of the containing web page 203 can include a separate DOM tree node for each of these sub-elements. The component model [f] can be much simpler, including only one component node [g].

It should be appreciated that the system 100 can also support selective component exposure, allowing the designer 5 to specify, via the linker 23, which components should be exposed to the third-party application 40, and allowing only these components (possibly including the "containment path" leading to these components) to be included in a simplified component model visible to the third-party application 40. This specification can be performed by explicitly marking the included components according to their type and other attributes of the website building system 30. This allows the third-party application 40 to traverse the component model of the containing web page 203 to identify the required components.

Furthermore, it should be understood that links (e.g., broadcast links) between the containing web page 203 and instances of the third-party application 40 can also be automatically created, allowing the third-party application 40 to send communications and log certain events at runtime. This communication can be optional or required (i.e., the third-party application 40 will not function or install unless there is a corresponding third-party application 40 linked to receive such messages). For example, the third-party application 40 can broadcast information packets regarding the operations/functions it performs, and any installed logging third-party application 40 can receive these information packets.

Once configured in this way, the newly created page can be stored in the application repository 22 (via the WBS coordinator 21) so that it can be called at runtime, as will be explained in more detail below.

Referring now to FIG. 7B, in this embodiment, the elements are the same as those in FIG. 7A, except for the elements of the client 10. At runtime, the client 10 includes a viewer 201 for displaying the containing web page 203. It should be appreciated that the viewer 201 may include multiple viewports 202, each for displaying a different instance of a third-party application 40 (instances derived from one or more third-party applications 40). Additionally, the client 10 includes a communications hub 205, which facilitates communications and provides a backchannel between the containing web page 203 and the third-party applications 40 hosted by the containing web page 203, as well as required communications between multiple hosted third-party applications 40, without connecting to the associated containing web page 203. The functionality of the hub 205 is described in more detail below.

It should be understood that the hub 205 may be implemented on the client 10 because both the containing web page 203 and the inclusion of the third-party application 40 are interactive parts of the visible website, and their communication should not be delayed by round trips between the client and the server. In an alternative embodiment, if the third-party application server 50 needs to exchange large amounts of data and it is preferable not to route this data through the client 10, the hub 205 may be implemented on the server 20 of the website building system.

It should be appreciated that the communications hub 205 can support various combinations of communications between the website building system 30 and one or more third-party applications 40, and between multiple third-party applications 40. For example, the hub 205 can enable a third-party application 40 to request that the website building system 30 switch to a different page within the main site. Additionally, the communications hub 205 can enable a third-party application 40 to request that its window be resized (potentially affecting the layout of the containing page). This resizing can occur through a dynamic layout process, described in more detail below. Alternatively, if (for example) a change in display requires the third-party application 40 to switch to a different version, the containing web page 203 can request this switch. It should be appreciated that this two-way communication can also be established between components of a third-party application 40 and components of the website building system 30 (that display additional information) associated with the third-party application 40, and between elements of a multi-part third-party application 40 and modular third-party applications, as described above.

Furthermore, it should be understood that system 100 can be implemented using both online and offline website building systems 30, and that system 100 can use any combination of hosting methods (e.g., client-side elements, a server from the website building system 30 vendor, a server from the third-party application 40 vendor, another fourth-party server, etc.). It should be understood that even in the offline embodiment described above, a server may be required to implement system 100.

Furthermore, system 100 can be hosted on a separate set of servers (not operated by the website building system vendor), such as a private site hosting system at a larger organization.

Furthermore, system 100 may support all of the above-described inclusion options for instances from third-party applications 40. However, system 100 may support only a subset of these options or may impose restrictions on the inclusion options for instances of third-party applications 40.

Additionally, the system 100 may implement a multi-part third-party application 40. A multi-part third-party application 40 may include multiple display areas, each processed using a separate iframe. These areas may also cooperate (if desired) through a communications hub 205, as described in more detail below.

9, which illustrates an example of a multi-part third-party application 40. As illustrated, a blog third-party application [a] retrieved from an AppStore [b] is placed on a containing web page 203 [c]. The blog third-party application [a] includes three regions: a blog entry region [d], a tag cloud region [e], and a news update region [f]. It should be understood that a multi-part third-party application can use its regions in a variety of ways, such as as multiple simultaneous parts of an application (as in the blog example above) or as optional parts of an application (including regions that are always displayed and optional regions that are displayed only when requested). The display of optional regions can be controlled by the third-party application 40 or by the designer 5 (which determines how to configure the third-party application when it is included). Additionally, the display can be controlled as support functionality regions, such as configuration regions or additional dialog regions. Alternatively, the same applies to displaying multiple versions of a third-party application (e.g., having small and large versions of the third-party application, or having portrait and landscape versions of the third-party application).

It should be appreciated that the functionality described above can be implemented using iframes to display elements of third-party applications 40, thus gaining the encapsulation and security benefits of an iframe-based architecture.

Furthermore, implementing a multi-part third-party application 40 requires that the third-party application 40 (inside each iframe) be able to control the display of the various iframes (e.g., the visibility, size, and position of the iframes). It should be further understood that this display can be enabled by the communications hub 205, as described in more detail below.

Furthermore, it should be understood that even when a multi-part third-party application 40 (visually) consists of multiple elements and regions, the application 40 is still considered a single third-party application 40 in terms of purchase, installation, configuration, etc. (e.g., in the AppStore 25).

In existing systems, each third-party application 40 is considered a separate entity, and collaboration between two third-party applications 40 (either from the same vendor or from affiliated vendors) must be developed on a case-by-case, system-by-system basis. It should be appreciated that system 100 can also support modular third-party applications 40, consisting of multiple collaborating sub-modules that can be purchased and installed separately.

Referring now to FIG. 10, this diagram illustrates how a modular sales management third-party application [a] can include sub-modules: a customer relationship management (CRM) module [b], a lead management module [c], and an e-commerce module [d]. The single third-party application vendor can provide all of the required third-party application modules. Alternatively, the third-party application vendor can provide a subset of the modules (and functionality) of the third-party application 40, and the designer can purchase and install additional third-party application modules from the same or other third-party application vendors. It should be understood that whereas a multi-part third-party application is acquired and installed as a single third-party application from a single vendor (a multi-part third-party application simply occupies multiple screen areas), a modular third-party application includes multiple modules that can be acquired and installed individually, possibly from multiple third-party application vendors. To enable integration of multiple third-party application modules from multiple vendors, each third-party application module must provide a list of the interfaces/functionality it requires and the interfaces/functionality it provides. The list can be provided, for example, by using a list of interface names based on a dot-separated hierarchical naming notation (e.g., My_CRM_TPA.NewClient.GetInfo) and specifying interface parameters.

Modules of third-party application 40 can specify interfaces that are required as mandatory (i.e., interfaces without which the module will not function) or interfaces that are required as optional (i.e., interfaces without which the module will function but which provide limited or altered functionality). Thus, the parameters provided for each interface are a unique interface name, an interface description (presented to designer 5 so that designer 5 can (for example) identify the functionality handled by the missing interface), mandatory/optional status, and a list and type of interface parameters. It should be understood that each third-party application module still belongs to a separate iframe (or set of iframes). Interface operation is based on communication channels, which are described in more detail below.

It should be understood that modules of the third-party application 40 can be assembled during the website design phase. The website construction system 30 can resolve interface references as additional modules of the third-party application 40 are added, in which case the new modules of the third-party application 40 resolve existing required interfaces and possibly add new (unresolved) required interfaces.

Furthermore, it should be understood that Designer 5 can edit and run the completed website while required (and optional) interfaces are still unresolved. However, Designer 5 cannot publish the created website until all required interfaces are resolved, and a message will be displayed if Designer 5 attempts a function that requires Hub 205 to launch a third-party application module that still has required interfaces that are not resolved.

It should further be appreciated that the AppStore 25 may include a searcher 26 that attempts to identify third-party application modules that resolve interfaces of a requested third-party application module. The searcher 26 may search for a specific third-party application module or all third-party application modules based on unresolved interfaces. Furthermore, the searcher 26 may search based on currently unresolved interfaces or resolved interfaces, and may search based on required interfaces, optional interfaces, or both types of interfaces. It should further be appreciated that the searcher 26 may be limited to resolving unresolved interfaces of a specific third-party application and searching for a specific third-party application vendor. The searcher 26 may perform either a first-level search (i.e., modules that satisfy currently unresolved interfaces) or a multi-level search (i.e., performing an iterative search, also looking for modules that satisfy unresolved interfaces when considering third-party application modules found by previous searches).

The system 100 can use the interface descriptions to provide information to the designer 5 regarding the importance of providing some missing interfaces. The hub 205 can provide interface translation between incompatible third-party applications that still need to communicate. This translation can be performed by an adapter module added by the supplier of the website building system 30 or an outside vendor, which adapts the required specified interface to another format.

Furthermore, system 100 can be applied to an online application editing system that uses the Internet (or any other network connection) and client-side software other than a browser to display created online applications. Such a system does not need to use the specific technologies used by typical web infrastructures (e.g., IP communications, HTTP, HTML, etc.).

It should be appreciated that standard cross-domain communication methods known in the art can be used to facilitate cross-domain communication. Examples of cross-domain communication methods include:

HTML5 PostMessage: A standard feature of HTML5 that provides secure cross-domain messaging. HTML5 Windows. PostMessage allows messages to be sent securely between windows, iframes, and the main HTML document, even if they belong to different domains. PostMessage provides tools for the sending iframe to specify the domain to which the message is being sent, and for the receiving iframe to verify the domain from which the message was sent.

URL fragment identifiers in messages: This method uses URL fragment identifiers to send message data from one endpoint to another. The data is encoded in plain text and added (as a fragment identifier) to a URL that is used to invoke a service in the target endpoint domain or a hidden iframe inside the target endpoint iframe. The fragment identifier is decoded by code in the target service or iframe.

Dedicated Communication Web Service: The website construction system 30 provides a dedicated web hosted on the website construction system's server 20. Various communication endpoints connect to this server to send messages or check for waiting messages. This can be done using methods known in the art, such as the pre-HTML5 Comet set of technologies, HTML5-based WebSockets, or any other queuing, polling, server push, or similar techniques.

HTML5 Local Storage: HTML5 provides a structured local storage facility that can be used to store queued messages. However, local storage can only be accessed by web content belonging to the same domain as the storing iframe. Solutions developed in this area include the underlying technology used by the Meebo XAuth product (now owned by Google), where a small server provides support for creating the required intermediate iframes, allowing domain-specific local storage to be accessed by iframes belonging to foreign domains.

HTML5 Local File Access API (Application Programming Interface): Similar to the local storage approach described above, local files on the user agent's local storage accessed through HTML5's file access APIs (File API, FileWriter API, FileReader API) can be used to build cross-iframe communication channels. However, the sandboxed local file system created by HTML5's file system access APIs is still only accessible from within the origin (origin-private), and therefore requires an intermediate iframe/server component to overcome the same-origin limitation.

Dedicated browser plug-in: A dedicated browser (or other user agent) plug-in can be created to manage the cross-iframe message queue. Such a plug-in must be installed by users of the website building system 30 (at all levels), but provides the necessary services to all iframes and the main page of the website building system 30.

It should be appreciated that the communications hub 205 can act as a broker for all inter-iframe communications using any of the transport methods described above. It should also be appreciated that the hub 205 is fully aware of the structure of the containing web page 203 and the details of the third-party application 40 provided by the vendor of the third-party application 40 and stored in the property sheet 23. Furthermore, the third-party application 40 can have different parameters when included in different applications and in different instances included within the same application (as described above). Such parameters include a unique instance name that can be used for smart addressing (described in more detail below). It should also be appreciated that the hub 205 can be aware of additional details of the third-party application 40 that are not stored in the property sheet 23.

Furthermore, it should be appreciated that the hub 205 can facilitate smart addressing and smart identification, verify the origin of communications, enforce communications policies, resolve third-party application 40 incompatibility issues, and even redirect from the third-party application 40 to components. Additionally, the hub 205 can enable dynamic updates of layouts in the third-party application 40 based on changes made to the containing web page 203, as described in more detail below.

Referring now to Figures 11A, 11B, and 11C, Figures 11A and 11B show different embodiments of the hub 205, and Figure 11C shows the function of the various elements of the hub 205.

The hub 205 may include a smart identifier/addresser 310, an origin verifier 320, a communication policy enforcer 330, a protocol converter 340, a redirector 350, a dynamic layout updater 360, a configuration manager 370, a general updater 380, and a hosted API (application programming interface) wrapper 390. The functionality of these elements is described in more detail below. It should be understood that all functionality may be applied to all cross-domain communication channels (e.g., from a third-party application 40 to a website building system 30, from a third-party application 40 to another third-party application 40, etc.).

Referring now to FIG. 11A, this figure shows a general embodiment of a hub 205 through an intermediate iframe [a], which communicates with the website building system 30 using an internal communication API (application programming interface). In this way, (for example) a message [c] sent from a TPA (third party application) [d] (using communication API module [f]) to a TPA [e] (using communication API module [g]) can be analyzed, verified, or modified in a manner that applies application-specific information.

Referring now to FIG. 11B, this figure shows an alternative embodiment in which cross-domain communication is used in one or both of communication API module [a] (embedded in third-party application [c]) and communication API module [b] (embedded in third-party application [d]) without the use of an intermediate iframe. Module [a] and module [b] interact directly with the website building system 30 to receive and use application-specific information when handling communication message [f]. A disadvantage of this embodiment (compared to the embodiment shown in FIG. 11A) is that a significant amount of information at the website building system 30 level may be processed inside modules contained in third-party applications, and this information may be accessed (and possibly modified) by malicious third-party applications.

As mentioned above, in all of the cross-communication methods described above, iframe addressing is based on the iframe's origin (source domain, source protocol, source port, etc.), i.e., the third-party application 40 uses direct addressing when sending a message (to specify the receiver) and when receiving a message (as the sender's name is provided to the receiver). Furthermore, to send a message, the sender is required to specify the target iframe window (using the JavaScript document.getElementById("...").contentWindow call or any other method). Therefore, in existing systems, each third-party application 40 must contain all the specific details (including domain, protocol, port, iframe ID) of the other third-party applications 40 with which it communicates.

It should be understood that this type of direct addressing can be cumbersome in the environment of system 100. Even if designer 5 integrates multiple third-party applications 40 from multiple unaffiliated third-party application 40 vendors, the third-party applications 40 provided by the third-party application 40 vendors may initially be hosted on a particular domain but later be moved to another domain or subdomain. The third-party application 40 vendor may change the protocol or port used to communicate with a particular third-party application. Designer 5 may be required to modify the design of the containing web page 203 that includes the third-party application 40. All of this may occur for third-party applications 40 used in a website that is operational and accessed by a large number of users. Furthermore, a single containing web page 203 may contain multiple instances of a single third-party application 40, each capable of performing different functions. For example, a page within a product support website may include two instances of a third-party application 40 for chat (one for user-to-user chat and forums, and another used to consult with the vendor's support representatives when available).

It should be appreciated that the addresser/identifier 310 may be fully aware of the structure of the containing web page 203 and detailed information about the third-party application 40 (provided to the website building system 30 by the vendor of the third-party application 40). The addresser/identifier 310 may address the source or destination third-party application 40 using either the unique name of the third-party application 40 (registered with the AppStore 25), a descriptive ID for the instance of the third-party application 40 that is added to each instance of the third-party application 40 in the containing web page 203, thus enabling addressing of multiple instances of the same third-party application 40, or a generic identifier for the type/class of third-party application being requested (e.g., "I would like to send message <x> to the instance of the event-logging third-party application 40 in the containing web page 203"). Such identifiers may also describe the specific services to be supported by the third-party application 40. Additionally, the addresser/identifier 310 can use version indication information (e.g., "I want to send transaction <x> to an instance of accounting package <y> only if accounting package <y> is version <z>").

It should be understood that at runtime, the third-party application 40 only communicates with the hub 205 and therefore only needs to know the direct address of the hub 205, and does not need to know the addresses of other third-party applications 40. This single direct address can be encapsulated by a communication API wrapper (such as communication modules f and g shown in FIG. 11A and communication modules a and b shown in FIG. 11B) provided to the provider of the third-party application 40 by the website building system 30. The calling third-party application 40 can provide its own descriptive addresses (as described above) as known to the application, and the addresser/identifier 310 can convert these addresses into the direct address of the third-party application 40 to perform routing. In this way, the third-party application 40 does not need to maintain a table of the absolute addresses of all third-party applications 40 with which it may communicate.

It should be appreciated that verifying the origin of a message is important, as without verification, the receiving third-party application 40 may receive a message from a hostile third-party application 40. Because all communication occurs through the hub 205, the origin verifier 320 can check the authenticity of all incoming messages from third-party applications. Furthermore, the origin verifier 320 can provide additional information that can be added to the message, which can be used to perform additional verification. It should be appreciated that because every third-party application 40 included in the AppStore 25 and used by the system 100 is registered with the website building system 30, the hub 205 can verify, via the website building system 30, whether the unique origin ID included in the message matches the origin (domain, port, etc.) of the message.

Third-party applications 40 can define general communication policies that may depend on external information, information in the containing web page 203, etc. The communication policy enforcer 330 can ensure that the appropriate communication policies are applied so that communications that do not comply with the specifications do not have to be handled. For example, in a website that handles sensitive information, third-party applications can be given a sensitivity level field in their profile. A third-party application 40 that provides a back-end event logging database and is authorized to handle sensitivity level X can define a policy that accepts and does not log events with sensitivity levels higher than X. In such situations, the communication policy enforcer 330 can perform the necessary pre-filtering to prevent highly sensitive messages from even reaching applications that can only handle lower sensitivity levels.

Furthermore, it should be understood that designer 5 may wish to include two (or more) third-party applications in the same website they have created that could potentially cooperate but would not actually cooperate due to protocol compatibility issues. Referring now to FIG. 12, for example, as shown in this figure, online shopping third-party application [a] may have the functionality to send purchase order messages to a procurement and shipping third-party application, such as third-party application [b] (provided by a different vendor). However, the information provided by third-party application [a] may not include some fields required by third-party application [b]. While this situation should generally be resolved by the vendor of the third-party application involved, in some cases this is not possible (e.g., one of the two third-party applications is not currently updated for some reason). Protocol converter 340 may translate the associated messages from [a] to [b] (e.g., by providing the required additional fields). Such translation may be performed by protocol converter 340, or may involve interaction with the website in which the application is embedded and containing web page 203 (e.g., if additional information is required).

Furthermore, it should be understood that a third-party application 40 may have functionality that requires it to send messages to or receive messages from another third-party application 40 (e.g., the online shop/procurement third-party application 40 pairing described above). However, in some cases, part of the solution may not exist; in the example above, a corresponding or suitable procurement third-party application 40 may not exist. In such cases, by using the redirector 350, the designer 5 can specify that specific messages be routed to or from components of the containing web page 203, and that comparable functionality is resolved by the components of the containing web page 203 and the functionality they can provide. This allows for the construction of a complete website without the need to build a dedicated third-party application 40. Thus, transactions can be sent to a component of the website construction system 30 that can log the transactions to a database, which can later be used (by another program) to perform offline procurement and shipping.

Third-party application 40 may offer multiple configurations with different capabilities that use the same code base but enable different features. For example, third-party application 40 may offer basic functionality through a free version and provide additional functionality through a purchased premium version, multiple paid versions, or additional features purchased for the third-party application 40.

It should be understood that the system 100 can include functionality based on the website building system 30 for managing the purchase status of third-party applications 40 for each user (and in fact for each designer). Furthermore, it should be understood that all designers can be registered users of the website building system 30, and thus the website building system 30 can manage a database of the purchase status of third-party applications 40 for each designer 5. This information can be stored in the property sheet 23 by the TPA coordinator 24 during the design phase and by the configuration manager 370 at runtime. For example, the third-party application 40 can send a version query message to the client-side component of the website building system 30. The client-side component of the website building system 30 queries the repository 22, or a locally cached copy of the repository, and returns a response message to the third-party application 40 containing information about the capabilities that the third-party application 40 should provide.

In an alternative implementation, the website building system 30 can provide the third-party application 40 with the necessary configuration information (such as encrypted iframe parameters) via an alternative channel without requiring a prior query message.

As described above, the third-party application 40 can communicate directly with particular components of the containing web page 203. The third-party application 40 can identify the components to communicate with in a variety of ways: directly identifying the components based on an associated template (as described in more detail below); through an access ID explicitly assigned to the particular component of the containing web page 203 by the designer 5; or by traversing a (possibly selective) component model provided to the third-party application 40 by the containing web page 203.

It should be appreciated that, at runtime, the updater 380 can implement messages and responses between the components of the containing web page 203 and the third-party application 40. For example, the third-party application 40 can change, modify, or query the visual and display attributes of the components of the containing web page 203 (such as the component's position, size, color, transparency, etc.). Additionally, the updater 380 allows the third-party application 40 to read or write the content of the components of the containing web page 203, and even allows the third-party application 40 to instruct the components to perform media functions (e.g., passing a specified audio or video segment to a media player component or requesting that the media player component pause playback for a specified period of time).

Additionally, the updater 380 facilitates components of the website building system 30 specifying the type of access they grant to third-party applications 40, in a manner similar to how permission bits or access control lists (ACLs) function to protect files in modern operating systems. Such permissions can be defined for each component to apply to all third-party applications 40, to third-party applications 40 from a particular vendor, or to a specific third-party application 40. For example, a third-party application 40 may be allowed to access a text field outside the third-party application 40 within the containing web page 203. In the case of a blog third-party application 40, this text field can be used to edit blog entries, providing more screen real estate than can be provided within the blog third-party application 40 area itself. It should be understood that in the case of a third-party application 40 embedded in a particular minipage within a multi-page container, the website building system 30 can limit access from the third-party application 40 to only the components within that particular minipage.

Furthermore, it should be appreciated that the updater 380 allows the third-party application 40 to affect site-wide elements, such as getting and setting attributes of the current page within the site, the current minipage within the container containing the third-party application 40, page history, etc. Furthermore, the updater 380 may filter or limit such requests.

Furthermore, the updater 380 allows the website building system 30 to change and modify the style and display of the third-party application 40. The updater 380 can implement calls that the website building system 30 uses to provide formatting and style guidelines to the third-party application 40. The guidelines can include properties such as color and color schemes, fonts, character sizes, transparency, animations, and special effects (e.g., blurs). Color schemes can include general color schemes (e.g., use x color below) and high-level color schemes (e.g., use color x for text and color y for frames), among others.

It should be appreciated that one preferred method for expressing complex style information is through the use of cascading style sheets (CSS), which can express combinations of multiple style directives, such as fonts, sizes, and colors. The updater 380 can send such CSS-based messages to the third-party application 40. The style sheets can be generic in nature or can include specific style names defined by the third-party application 40, thereby allowing the website building system 30 to provide more appropriate guidelines to the third-party application 40 (e.g., the style sheets can provide these guidelines by referencing elements of a specific third-party application 40).

Third-party applications 40 can then use these guidelines to create their own look and feel that better matches the containing web page 203. This is especially important for third-party applications 40 that are included in or visible from multiple containing web pages 203 within the same site (the multi-port inclusion discussed above). The multiple containing web pages may employ different color schemes or basic designs. Using the information provided through these style messages, third-party applications 40 can adapt their display colors and styles to better match each containing page, avoiding an inconsistent color display or look and feel compared to the containing web page.

It should be appreciated that the dynamic layout updater 360 enables the website building system 30 and the third-party application 40, or the third-party application 40 and ancillary third-party applications, to cooperate when processing display changes resulting from dynamic layout events. The website building system 30 can resize and reposition components within a page in order to maintain the page design when an event occurs that modifies some of the components within the page. These dynamic layout events include, for example, viewing a website on a screen with a different size, rotating the display device between portrait and landscape modes, changing the size or position of some components, or changing the content of a particular component (resulting in a component being required to be resized). Furthermore, dynamic layout events include updates to components due to server-based content updates (e.g., in components that display information from a data feed) or content changes made by other concurrent users of the same website. It should also be appreciated that dynamic layout events can occur not only in the design environment but also in the runtime environment. In particular, depending on the component and the third-party application 40, the content or size/position of a component can be changed not only by the designer but also at runtime (i.e., by the end user).

It should further be understood that dynamic layout events can also be generated by third-party applications 40. For example, an online shop third-party application 40 may request a size change when a user moves from a product catalog view to a shopping cart view (which has a different size). As another example, a product catalog third-party application 40 may include an option for highlighting products, which causes the third-party application 40 to display a larger catalog page with more content. A further example includes a multi-region third-party application 40 that can start or stop the display of additional regions.

Referring now to FIG. 6 above, existing systems typically handle this situation, if at all, by truncating the third-party application's display, adding scroll bars to the display, or simply resizing the display as a pop-up window that obscures other components of the page, as shown in FIG. 6. The dynamic layout updater 360 can implement collaborative dynamic layout, in which the website building system 30 and the third-party application 40 collaborate to perform dynamic layout and maintain the basic design of the containing web page 203. Dynamic layout functionality is further described in U.S. Patent Application Publication No. 2013/0232999 (filed February 20, 2013, and assigned to the common assignee of the present invention). However, even in systems that support collaborative dynamic layout, the dynamic layout mechanism in the containing web page 203 does not fully control the internal layout of the third-party application 40. Furthermore, widgets in the website building system 30 may be designed to be resizable to any size (within a certain range), while the third-party application 40 may not support arbitrary resizing. The third-party application 40 may provide any combination of, for example, multiple display settings with different sizes (e.g., showing more or less detailed information), the ability to resize some of the internal elements of the third-party application 40, and the ability to display some of the text elements of the third-party application 40 using multiple font sizes.

Additionally, the third-party application 40 may offer a limited number of possible display sizes or may have a whole range of possible sizes. Therefore, a resize request from the containing web page 203 to the third-party application 40 may be resolved by the third-party application 40 switching to the closest possible size or by providing a list of the third-party application's 40 possible sizes (which allows the website building system 30 to select an appropriate size to use).

The dynamic layout updater 360 can implement collaborative dynamic layout [from the containing web page 203 to the third-party application 40] using the following sequence:

For example, a third-party application 40 embedded in the containing web page 203 may need to be resized to a particular desired size (e.g., X1 * Y1 pixels). The dynamic layout updater 360 can send a message to the third-party application 40 requesting that the third-party application 40 resize its content to the particular desired size (e.g., X1 * Y1 pixels). The third-party application 40 can adjust to the specified size by using an alternate display setting, internal resizing, internal dynamic layout processing, or any other means. Furthermore, it should be understood that the containing web page 203 can resize an external iframe window containing the third-party application 40 to the new size (X1 * Y1).

Furthermore, it should be understood that the third-party application 40 may only be able to resize to a limited set of possible sizes (e.g., a particular user interface configuration). Therefore, the dynamic layout updater 360 may use the following alternative algorithm that allows the third-party application 40 to provide a set of possible sizes:

The containing web page 203 is resized, and the dynamic layout updater 360 sends a message to the third-party application 40 requesting that the third-party application 40 resize its content to a particular desired size (X1 * Y1). The third-party application 40 determines the closest possible size (e.g., X2 * Y2 pixels) and resizes to that size by using alternate display settings, internal resizing, internal dynamic layout processing, or any other means. The updater 380 can then send a response message to the containing web page 203 confirming the resizing and providing the actual new size (X2 * Y2). The containing web page 203 can then resize the external iframe window containing the third-party application 40 to the actual new size (X2 * Y2). The containing web page 203 can then continue its dynamic layout processing based on the actual new size (X2 * Y2).

It should be understood that another embodiment is also applicable, particularly when multiple third-party applications 40 (or multi-region third-party applications 40) are present within the containing web page 203. In this embodiment, the containing web page 203 can query the embedded third-party applications 40 to obtain a list of display sizes so that the embedded third-party applications 40 can attempt to optimize the look/feel taking into account the multiple options of the multiple third-party applications 40. This embodiment is also relevant when the third-party applications 40 are displayed across multiple regions.

The containing web page 203 performs dynamic layout processing to recognize that one or more third-party applications 40 (TPA[1] to TPA[n]) are embedded in the containing web page 203 and should be resized using the following algorithm:

Loops from 1 to n for i.

For each TPA[i], calculate the following:

Minimum size Xmin[i]*Ymin[i],
Maximum size Xmax[i] * Ymax[i],
Optimal size Xopt[i]*Yopt[i],
The dynamic layout updater 360 can request information about the possible sizes of the third-party application 40 by sending a message to TPA[i] listing the above minimum/maximum/optimum sizes.

The third-party application 40 can provide the dynamic updater 360 with a set of possible size options (Xpos[i][j] * Yposs[i][j]) that it can adopt.

Based on the Xposs[ ][ ]/Yposs[ ][ ] information collected as described above, the containing web page 203 can calculate a solution for the dynamic layout calculation by (for example) using a thorough evaluation of all possible size combinations of the third-party application, linear programming, or any other technique used by the dynamic layout algorithm.

Store the results for all TPAs in Xfinal[i]/Yfinal[i].

Loops from 1 to n for i.

The containing web page 203 sends a resize message including Xfinal[i]/Yfinal[i] to TPA[i].

The containing web page 203 resizes the external iframe window containing TPA[i] to Xfinal[i]/Yfinal[i].

The containing web page 203 continues dynamic layout processing based on the actual new size.

It should be understood that dynamic layout processing may generally require moving the third-party application 40 rather than simply resizing it. However, the third-party application 40 should remain consistent with the exact location of its frame inside the containing web page 203.

As mentioned above, the third-party application 40 may occasionally need to resize its display window. Because the size of the window displaying the iframe is managed by the hosting page (i.e., the containing web page 203), any changes to the window size of the third-party application 40 must be performed by the containing web page 203, in which case the third-party application 40 requests the containing web page 203 (via the dynamic layout updater 360) to change the window size.

It should further be appreciated that the third-party application 40 can also request (via the dynamic layout updater 360) that its position within the containing web page 203 be changed. In this case, the third-party application 40 is not affected internally (as with a resize), but a change in display within the containing web page 203 is requested. The dynamic layout updater 360 can integrate this request with the dynamic layout. The containing web page 203 can invoke the dynamic layout updater 360 to change the window size (and possibly the window position) of the third-party application 40 and send confirmation of the size and position change to the third-party application 40.

It should be understood that the hub 205 can also implement additional messages specific to a class of third-party application 40, or additional messages specific to a third-party application 40, that the website building system 30 itself, or a particular containing web page 203, or ancillary third-party application 40 can affect. For example, a blog third-party application 40 might define an input message that can post a new blog entry or a new response to a current blog entry. Such a message can be used by the containing web page 203 (e.g., as a way to post a blog entry from a large edit field outside the confines of the third-party application). Furthermore, such messages can also be used for linking between higher-level applications, allowing, for example, a supporting third-party application to post a blog entry to the blog third-party application.

It should be appreciated that third-party applications 40 often require a wide range of complex services for use within the third-party application 40 or downstream use by designers using the third-party application 40 within their own sites. Such services may include user management and billing and shipping management. The vendor of the website building system 30 may not be able to provide such services as part of the website building system (e.g., for technical or business reasons). Furthermore, these services may not be suitable for "packaging" as a third-party application 40 on their own. Furthermore, the vendor of the third-party application 40 may need the option to provide multiple such services (e.g., multiple third-party billing APIs) to designers using the third-party application 40, allowing the designers 5 to select and use the appropriate service.

For example, in the website building system 30, an API hosted by PayPal ^™ may be provided that can be used directly by the third-party application 40 or provided by the third-party application 40 to the designer 5 that uses the API. Additionally, the third-party application 40 may provide its own set of options (i.e., use a particular billing type, e.g., one-time billing, automatic recurring billing, revenue sharing) and implement these options by calling the hosted PayPal API.

Thus, a designer 5 using the website building system 30 can develop a unique service (such as an online shop selling music) that uses advanced billing. By using the hosted billing API directly or through a third-party application 40 that provides an additional level of abstraction, the designer 5 can avoid the need to negotiate specific settlement or merchant agreements with the provider of the billing API. In this sense, the website building system 30 can act as an agent for the vendor of the hosted API.

The hosted API wrapper 390 can facilitate this communication between different parts of the system (e.g., the website building system 30, the hosted API code, and the included third-party application 40). It should be understood that the API wrapper layer and the actual API implementation can reside in the website building system 30 itself or in another third-party application 40. The vendor (or designer 5) of the third-party application 40 can use the hosted API through the hosted API wrapper 390 without knowing how the actual underlying API is implemented.

In a complementary alternative embodiment of the present invention, Applicant has further recognized that smart integration between the website building system 30 and one or more third-party applications 40 can be achieved by using an integration model in which additional templates and components of the website building system are associated with third-party applications at the AppStore 25 level and with instances of the associated third-party applications. The third-party applications 40 can also communicate with these components (and with unassociated components) to exchange data and control messages. As noted above, the third-party application areas 40 within the containing web page 203 are separate iframes whose content is hosted in a separate domain (whether that of the third-party application vendor or otherwise) that is different from the domain in which the main site is hosted. Therefore, communication between different iframes is subject to the browser's "same-origin policy," which requires the use of the techniques described above.

Existing systems implement third-party applications 40 as monolithic, inflexible objects that are included in the containing web page 203 but do not otherwise affect the look and feel of the containing web page 203 itself. An instance of the third-party application 40 is placed within a (typically rectangular) region, and all of its operations and functionality are performed within this region.

Furthermore, applicant has recognized that this concept can be extended by having (optional) additional templates (referred to as associated templates, according to embodiments of the present invention) of the website building system 30 associated with the third-party application 40. It should be understood that this association can be performed at the time of development or publication of the third-party application 40 and can be presented to the designer 5 as part of the selection/purchase process for the third-party application 40 (from the AppStore 25) and the creation of an instance of the third-party application 40. The third-party application (TPA) coordinator 24 can obtain the templates associated with the third-party application 40 (as part of an application repository managed by the AppStore 25 or provided by the vendor of the third-party application 40) and store the templates in the repository 22 for later use, as described above.

It should be appreciated that the system 100 can support publishing third-party applications 40 with multiple associated templates, allowing the designer 5 to select the most appropriate template for their needs.

It should be understood that when creating an instance of the third-party application 40 within the containing web page 203, the components within the associated template can be merged with the containing web page 203 and displayed along with other components within the containing web page 203.

Reference is now made to FIG. 13, which illustrates an example of the use of associated templates in accordance with an embodiment of the present invention. As illustrated, third-party application [a] is located in AppStore [b] along with associated template [c], which includes components [d] and [e]. It should be appreciated that when third-party application [a] is included in containing web page 203 [f], third-party application [a] can be displayed in a designated region [g] within page [f], and instances [d'] and [e'] of components [d] and [e] can be displayed on page [f] along with pre-existing components [h] and [i].

It should be appreciated that the system 100 can support multiple methods for positioning instances of associated template components (e.g., [d'] and [e'] above) within the containing web page 203[f]. These methods include absolute positioning (i.e., using the size and position of the original components [d] and [e] as specified in the associated template [c]), target-relative positioning (i.e., adjusting the size and position of the new instances [d'] and [e'] according to the containing web page 203[f]), and third-party application 40-relative positioning (i.e., adjusting the size and position of the new instances [d'] and [e'] relative to the size and position specified for the third-party application instance [g] inside the containing web page 203[f]). The positioning method employed can be determined based on the settings included with the associated template [c], and the designer 5 can use a different positioning method if desired.

Furthermore, it should be understood that designer 5 can modify instances of components [d] and [e] in [f] that are inherited from template [c]. The changes only apply to the use of [d] and [e] in [f] (and possibly inheriting pages from within website building system 30 that support inter-page inheritance), and do not affect the "original" template [c] associated with third-party application [a] in AppStore [b].

It should be understood that modifications to the instances of [d] and [e] above may include, among other things, assigning particular content (text, images, etc.) to the field instances and modifying their general attributes. Furthermore, with reference to FIG. 14, it should be understood that when a third-party application 40 is contained inside a minipage, the associated template applies to the particular minipage in which the third-party application 40 is contained, as shown in FIG. 14. As shown, the third-party application 40 is contained in minipage [x], and therefore components [d] and [e] are added to [x], but not to further minipages [y] and [z] of the same multi-page container [g].

Furthermore, it should be understood that for section-type mini-pages, the associated template (if present) is applied to the virtual (and empty) containing web page 203 created to contain the third-party application 40.

In an alternative embodiment, a pre-created associated template can be applied to a newly created page or mini-page that is "parallel" to the containing web page 203. This newly created page or mini-page can be initialized with the template and then modified as needed.

Additionally, the website building system 30 also enables multi-port inclusion, where the same instance of a third-party application 40 is visible to and "belongs" to multiple pages of the main site. Multi-port inclusion is distinct from multiple inclusions of a particular third-party application 40 within the main site (which creates multiple instances of the third-party application 40). Thus, the content of the third-party application 40 (which is instance-specific) is shared among multiple representations of the same multi-port third-party application 40.

In such multi-port inclusions, the associated template can be applied separately to each page and minipage to which an instance of the third-party application 40 is added.

As described above, the system 100 can provide a two-way communication link between the third-party application 40 and components within the containing web page 203. It should be understood that such components include components of the containing web page 203 that result from merging associated templates from the third-party application, as well as components unrelated to such associated templates.

Thus, it should be understood that a vendor of a third-party application 40 may generally create multiple templates that are associated with the third-party application 40 provided by the vendor. These templates may include test templates, development templates, and other templates in addition to the templates that are actually deployed (i.e., associated with the currently deployed version of the third-party application).

As mentioned above, third-party applications 40 may be distributed through the AppStore 25 and may also be distributed through alternative channels that are not related to or managed by the vendor of the website building system 30. However, associated templates distributed with the third-party applications 40 may be tightly coupled to the application repository 22 because the associated templates are built using components, base templates, and other elements managed by the website building system 30.

Furthermore, elements of the website building system 30 that form the basis of such separately distributed associated templates may need to be modified or removed (potentially "breaking" the associated templates). To solve this problem, the system 100 can implement these associated templates in separate areas within the application repository 22 (potentially per vendor of the third-party application 40). The website building system 30 can manage these templates in the same way as any other template in the website building system 30.

It should further be appreciated that the vendor of the third-party application 40 may be provided with a unique ID (development ID) for each template created, which the vendor of the third-party application 40 may use during the development and testing process of the third-party application 40. At the time the third-party application 40 is published/distributed, the vendor of the third-party application 40 may be required to apply and receive an alternative unique ID (public ID), which the vendor may reference in the published third-party application 40. Once the public ID is provided, a separate, locked copy of the template is created. This copy is the copy referenced by the third-party application 40 and used when creating an instance of the third-party application 40. In this manner, the vendor of the third-party application 40 cannot accidentally modify the template associated with the "raw" third-party application 40 (as included by the designer), thereby maintaining referential integrity. Furthermore, the system 100 may cross-reference the relationships between such locked templates and the underlying components and base templates. This cross-referencing can be used to alert website building system 30 staff, for example, if a component or base template of the website building system 30 contained in such a locked template is about to be modified (and such modification may break the template or third-party application 40 in some way).

Thus, the system 100 can provide a two-way communication channel between the third-party application 40, the components in the containing web page 203, and the website building system 30. The components of the containing web page 203 can be based on a template(s) associated with the third-party application, or on another template in the website building system 30, or can be template-independent.

As described above, the communications hub 205 can facilitate communications and provide a back-channel between the containing web page and the third-party application 40. Applicant has further recognized that data transmitted in both directions between the containing web page and the third-party application 40 can be useful once collected, processed, and integrated.

For example, website owners need to manage the number of users and memberships per their site, which differ from the registered user-based values of the associated website building system 30. Website users can register or not (anonymous), and websites can offer different levels of functionality to different levels of users. Furthermore, users (even anonymous users) often provide personal and contact information (e.g., data in contact forms) when launching instant messenger software to contact the site owner or connecting to social networks as part of their activities on the site. It should be understood that this information may be entered directly into the created site or may be made available as part of interactions with third-party applications embedded within the site.

Furthermore, it should be understood that this information is unorganized, unrelated, sometimes contradictory, and often not stored. For example, a user may enter their personal email address into a contact form (managed directly by the site) and, in the same session, enter their work email address into a separate subscription form (managed by third-party application 40).

Furthermore, this "fluid" information may include different permissions regarding the use of that information. For example, a user who enters their email address into a subscription form expects to receive email-based subscriptions to which they have subscribed and possibly related email newsletters. Conversely, a user who discloses their email address as a registration ID may not want to receive emails addressed to their registration address, except for emails regarding their account management, security alerts, etc.

15, which illustrates a system 200 for coordinating and collecting data from various messages exchanged between the website building system 30 and one or more embedded third-party applications 40. The system 200 includes a client hub 210 installed on a client 220, a server hub 230 installed on a server 260, a contact coordinator 240, an activity coordinator 250, a contact database 245, and an activity stream database 255. It should be appreciated that the hubs 210 and 230 can facilitate communication between the website building system 30 and multiple third-party applications installed on the server 270, as well as communication between multiple different third-party applications 40, as described above in connection with the hub 205. The contact database 245 and the activity stream database 255 can hold contact and activity information, as well as information extracted from the message stream, as will be described in more detail below.

16A and 16B, where FIG. 16A illustrates elements of a client hub 210 and FIG. 16B illustrates elements of a server hub 230, a contact coordinator 240, and an activity coordinator 250. The client hub 210 includes a router 211, a converter/adapter 212, and a privacy policy enforcer 213. The server hub 230 includes a router/tracker 231, a converter/adapter 232, a privacy policy enforcer 233, a private data proxy 234, and a verifier/signer 235. The contact coordinator 240 includes a data extractor 241, a contact handler 242, a data merger 243, and a data/permission handler 244. The activity coordinator 250 includes a stream creator 251, a stream merger 252, and a log creator 253. The functions of these elements will be explained in more detail later.

Referring now to Figures 16C and 16D, Figure 16C illustrates the elements of stream merger 252, and Figure 16D illustrates the elements of data merger 243. Stream merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. Stream-stream merger 262 further includes a horizontal stream merger 263 and a vertical stream merger 264. Data merger 243 includes a contact identifier 272, a combiner 273, a conflict resolver 274, a list value creator 275, a vertical contact merger 276, and a horizontal contact merger 277. Horizontal contact merger 277 further includes a virtual horizontal merger 278. Vertical contact merger 276 further includes a virtual vertical merger 279. The functions of these elements are described in more detail below.

It should be appreciated that system 200 enables message passing between system 200 and multiple third-party applications while providing a variety of functionality, including organizing activity messages into streams, storing activity message history, multi-level message passing for activity messages, using side channels for activity messages, transforming and content adapting activity messages, validating and signing activity messages, and dynamically routing activity messages using listener queries. These functionality is described in more detail below.

Additionally, system 200 can extract and merge information relevant to a user (combining information from multiple sources and information already present in system 200). Merging can be done through merge rules that reconcile different, possibly contradictory, information. The combined information can be stored in contact database 245. This information can further include permission fields that control the allowed use of the aggregated information, as described in more detail below.

In alternative embodiments of the present invention, either the client hub 210 or the server hub 230 may be used alone to communicate with multiple third-party applications 40 installed on the server 270. In situations where only the client hub 210 is used, it should be understood that the contact coordinator 240, activity coordinator 250, and databases 245 and 255 may be installed locally on the associated client.

Furthermore, it should be appreciated that system 200 may include additional components that enable third-party applications 40 to manage user contact activities (e.g., mass newsletter sending) while enforcing usage limits set by the user themselves. Such components may also isolate the user's private data from third-party applications 40 (so that the third-party applications 40 can perform their respective operations without actually accessing the user's private data). Such functionality may be implemented, for example, using private data proxy 234, as described in more detail below.

Furthermore, it should be understood that the contact database 245 can be specific to each site. However, the website building system 30 allows for the definition of a metasite/metaproject level that includes a collection of websites (owned by the same site owner) and specifies that contacts are stored, processed, and merged at the metasite level rather than at the single site level. Other elements of a site (such as included third-party applications 40) can also be defined at the metasite level rather than the site level. Other than supporting metasites, the system 200 generally does not share contacts between different sites or different site owners (except in circumstances described below), nor does it aggregate contact information (so that data provided by an end user to one site does not leak to another site).

As described above, the system 200 can support multiple interactions between the website building system 30 and one or more third-party applications 40. Such interactions can be predefined activities, such as making a purchase, adding an item to a shopping cart, entering contact information, etc. A third-party application 40 can specify the activities it supports, and other third-party applications 40 can "listen" to particular activities and act based on the received activities and associated information. It should be understood that the list of activities listened to in a particular third-party application 40 can be explicitly set for one or more activities, or can be determined by an activity listening query, as described in more detail below.

It should be understood that each activity can be thought of as a message, and each message can include an activity data structure. Activity data structures are predefined data types, but can also be defined through inheritance between each other or through a third-party application 40 (with the option to extend the activity data structure by adding fields). Activity data structures can be system-specific or can be based on or include standardized data structures. Activity data structures can also be encoded in some manner (such as using XML, JSON data, or binary object encoding).

Furthermore, the activity data structure may include a "description" field provided by the third-party application 40. This is a description of the activity defined by the third-party application 40 (which may be more detailed than the description known to the website building system 30). For example, a VOIP communication third-party application 40 may provide the activity description text as "Call to John Smith at 999-555-1234 - 01:15."

Additionally, the activity data structure may include a callback link, such as "More Info" (back to the activity data structure). The callback link may be used to provide additional valuable information, such as complete order tracking information or order history for an e-commerce activity data structure, a complete chat log for a chat activity data structure, or a call log for a phone activity data structure. Thus, an exemplary complete activity data structure may include the following fields: creation time, activity type, activity origin (third-party application 40/component ID), activity stream ID, activity type specific information (depending on the activity type), creating site ID, site member database ID, site page ID/URL where the activity occurred, a description of the activity provided by the third-party application 40, more information links used by the third-party application 40, and retrieved user details.

The activity coordinator 250 can be thought of as a logging element, receiving data from messages passed from the hub 230. The stream creator 251 can create an initial stream (which can be thought of as a log or chain-like structure), to which the stream merger 252 can add subsequent incoming activities, where each stream is specific to a contact. It should be understood that the stream creator 251 does not have to create a new stream for each distinct activity contained in a different message. Furthermore, it should be understood that multiple activities contained in a stream may not be in the correct order (e.g., a third-party application 40 may be delayed in reporting activity). In operation, the stream merger 252 can merge multiple streams if they belong to the same contact, and the log creator 253 can store log files in the activity stream database 255 of all previously created activity streams.

As described above in connection with FIG. 16C, the stream merger 252 includes an activity-stream merger 261 and a stream-stream merger 262. The activity-stream merger 261 can associate an activity with a stream associated with an identified contact, and the stream-stream merger 262 can convert two separate streams into a single stream. The horizontal stream merger 263 can merge two unrelated streams due to the detection of a common primary ID, and the vertical stream merger 264 can merge a stream created for an anonymous contact with a stream associated with a registered user when these two streams are combined at login or registration time. It should be understood that the stream merger 252 can access previously created streams in the activity stream database 255 when needed.

For example, an anonymous user fills out a contact form within a site. The stream creator 251 creates a new activity stream (with ID "anon1"), and the contact handler 242 creates a new contact (with ID "anon1", as described in more detail below). This same user then chats with the site owner. The stream merger 252 merges this activity into the "anon1" activity stream, and the contact "anon1" is updated (as described in more detail below). Next, this user fills out a schedule form using a different browser. Because there is no interaction with the original user, the stream creator 251 creates a new activity stream with ID "anon2", and the contact handler 242 creates a new contact with ID "anon2".

The user then makes a purchase from the site. The stream merger 252 merges this new activity into the "anon2" activity stream and updates the contact "anon2" (e.g., with the "customer" tag).

This user then uses another browser to register with the site. Once registered, all users receive the ID "User x" from the site's membership handler. At this point, the stream creator 251 creates a new activity stream (with the ID "User x") and the contact handler 242 creates a new contact (with the same ID "User x").

The user then visits the site again from a different browser and chats with the site owner. Because this website does not use cookies, the stream creator 251 creates yet another new stream ID, "anon3," and the contact handler 242 creates a new contact, "anon3."

Next, the user logs into the website. At this point, there are contacts with ID "anon3" and ID "user x." The data merger 243 can merge contact "anon3" into "user x," so that both the login activity in "user x"'s stream and the login activity of contact "user x" point to the activity streams "user x" and "anon3." The stream merger 252 can merge any additional actions performed by the user in this session into the activity stream of "user x." The logger 253 can log all activity data from these streams and store a copy of the log in the activity database 255.

Referring now to FIG. 17, it should be appreciated that a site owner can access the activity stream history of a particular contact through an associated user interface provided by the website building system 30, as shown in FIG. 17. The website usage history for a single contact, "Dani Bronstein," can be easily accessed. It should further be appreciated that the website building system 30 or the third-party application 40 may also provide an API for accessing the log information. It should be appreciated that the activity log can be used for purposes such as optimization, user interface improvement, and advertising targeting.

It should be further understood that, in parallel with this, the contact coordinator 240 can assemble information from data provided by the activity stream (messages) to build a contact profile for the target user. The data extractor 241 can extract data from the activity messages and activity streams, and the data merger 243 can merge the associated data into a particular contact, the details of which can be stored in and accessed from the contact database 245. The contact handler 242 can create new contacts and handle the site user's identity (e.g., anonymous users), and the data/permission handler 244 can handle privacy and permissions for the associated data. The data merger 243 includes the horizontal contact merger 277 and vertical contact merger 276, as described above. The horizontal contact merger 277 can merge two unrelated contacts due to the detection of a common primary ID, and the vertical contact merger 276 can merge an anonymous contact with a contact associated with a registered user when the two contacts are combined at login or registration. The horizontal contact merger 277 can further include a virtual horizontal merger 278, which maintains the two contacts as separate contacts but links them together (with or without merging actual contact information) to indicate that they represent the same contact. The vertical contact merger 276 can further include a virtual vertical merger 279, which maintains the anonymous contact and the contact associated with a registered user as separate contacts but links them together (with or without merging actual contact information) to indicate that they represent the same contact. Additionally, the data merger 243 can merge contact information (typically extracted from the data extractor 241) with existing contacts. It should be appreciated that the contact identifier 272 can track user identities using cookies and can recognize contacts to merge, as will be described in more detail below.

15, 16A, and 16B, message passing can be performed at the client 220 or the server 260, or both. It should be understood that the third-party application 40 typically has a client-side element and a server-side element, or at least a server-side connection with the server 270 of the provider of the third-party application 40. The hub 210 can process messages between the client 220 and the third-party application 40, and the hub 230 can process messages between the server 260 and the third-party application 40. It should be understood that data received by the hub 210, after processing, can be forwarded to the hub 230 for further processing, as further described below.

Referring now to Figure 18, this figure illustrates a message passing scenario between different platforms. A user's client machine X can be connected to a website building system 30 on a server Y. The website building system 30 can be implemented using a client component A' of the website building system 30 and a server component A of the website building system 30. When the created site is displayed, the site can include a client-side element (data/code) B' and a server-side element B. The created site can further include three third-party applications 40 (TPA1, TPA2, and ETPA3).

TPA1 can be implemented by a client-side component D' and a server-side component D connected to server H of the vendor of TPA1. TPA2 can be implemented by a client-side component E' and a server-side component E connected to server I of the vendor of TPA2. However, ETPA3 can be a server-side-only third-party application 40 implemented by server-side component G, which is connected to the third-party application 40 support backend F of the website building system 30. These two components can communicate with server J of the vendor of the third-party application 40.

It should be understood that TPA1 and TPA2 can exchange messages on the client (between component D' and component E'), or on the server (between component D and component E), or on both the client and the server. However, communication with ETPA3 must occur only on the server. Furthermore, it should be understood that there are advantages and disadvantages to using either method. Sending activity messages on the client side can be more interactive and provide faster user response. Sending activity messages on the server side can be more robust and reliable (e.g., a user cannot close a browser window in the middle of a process), ensures messages are received in the correct order, and can send activity messages to a backend third-party application 40 or application dashboard installed on the backend. It should be understood that these backend third-party applications 40 are not visible on the client side.

As an example of a case in which multiple third-party applications 40 are used, a user adds an item to a shopping cart in third-party application A (activity type is "cart change"). Third-party application A then sends an activity message regarding the item being added to the website construction system 30. The website construction system 30 forwards this activity to all third-party applications 40 registered for "cart change." Third-party application B is registered, so it receives this activity. Third-party application B can display a message to the user such as "If you also purchase item X, you will receive a discount" or "If you share this site, you will receive a discount."

As another example, a user presses the "Like" button on something in third-party application A (e.g., via Facebook). Third-party application A then sends an activity message with the activity type "Facebook Like" to website building system 30. Website building system 30 forwards this activity to all third-party applications 40 that are registered for the "Like" activity. Because third-party application B is registered, it receives this activity. Third-party application B can show the user a re-engagement widget and display messages such as "If you like this site, why not contact the site owner?" or "Would you like a discount coupon?"

As mentioned above, all communication can occur via hub 210 and hub 230.

Router 211 can route client-side messages between a website and any third-party applications 40. Additionally, router 211 can route messages between hub 210 and hub 230 for further processing, as described in more detail below.

The router/tracker 231 can route messages between the website and any third-party application 40, and can also track messages. Furthermore, it should be understood that a third-party application 40 can listen for messages on both the client and the server. Furthermore, it should be understood that a third-party application 40 can explicitly specify one or more activities for which it listens (e.g., listen for all "Shopping Cart: Add Item" activities). Furthermore, a third-party application 40 can specify the class of activity for which it listens (e.g., listen for all Facebook-related activities). Furthermore, a third-party application can use wildcard expressions (applied to activity names) that are used to determine whether an activity should be sent to that third-party application.

Furthermore, it should be appreciated that the third-party application 40 can use activity listener queries. Such queries reference additional system information, including information not normally available from the third-party application itself, such as user attributes (e.g., registered users only, European users only), website attributes or structure (e.g., listen only for specific activity on pages created from a specific page template), user history (e.g., listen for cart checkout activity only if the user has made more than X purchases in the past), etc. Such queries can be specified by the third-party application 40, but can also be editable by a designer.

The router/tracker 231 can therefore also track messages being listened to by the third-party application 40. It should be appreciated that such an activity listener query architecture is best implemented at the activity routing level (as opposed to being performed by an API call inside the third-party application 40) because it allows website designers to perform adjustments and customizations without the third-party application 40 needing to be highly programmable and customizable. Furthermore, the router/tracker 231 also helps protect user privacy because the website designer does not need to provide additional information (necessary for routing decisions) to the involved third-party application 40. Furthermore, the router/tracker 231 can prevent unnecessary communication with the third-party application 40 (which is often hosted on a separate server).

It should be understood that it is the user (website visitor) who visits, registers with, and provides information to a website. The user may not actually be aware that the website they are accessing was built using a combination of the website building system 30, components, created websites, and third-party applications 40. Therefore, responsibility for the user's privacy ultimately rests with the website owner (who is also responsible for activities performed by third-party applications 40 included on their website).

Furthermore, it should be understood that third-party applications 40 (and other components of the website building system 30) may access user profile information through APIs provided by the website building system 30, based on privacy rules defined by the website building system 30. Furthermore, the containing site and the third-party applications 40 included therein may use the contact information to communicate with the user (via email or other means).

It should be understood that there can be three major privacy-related issues. The first issue is the interrelationship between the website and website-building system 30 and the provider of the third-party application 40. The website (and website-building system 30) cannot completely trust the third-party application 40 with regard to the use of user data, for example, with respect to the third-party application 40 not sending mass emails (using the user's email address provided by the site), not sending spam to users who have requested to be removed from a mailing list, or not transferring the user's personal information to other third parties. However, this issue can be resolved in the following way:

When adding a provider of a third-party application 40 to the application market of the website building system 30, the vendor of the website building system 30 can require the provider of the third-party application 40 to sign a Terms of Use (ToU) agreement. Such an agreement can state that the third-party application 40 (and the provider of the third-party application 40) must not misuse user information or disclose it to third parties. This allows the vendor of the website building system 30 to apply penalties to the provider of the third-party application 40 if the provider misuses information (e.g., disable the third-party application 40 or remove the third-party application 40 from the application market of the website building system 30). The privacy policy enforcers 213, 233 and the private data proxy 234 can enforce privacy policies on the third-party application 40, as described in more detail below.

The second privacy-related issue is the interaction between websites and the website construction system 30 and users (site visitors). Websites must provide users with a clear understanding of how their personal data will be used, receive their consent, and abide by the terms and conditions to which they agree. The website construction system 30 requires all publicly accessible sites to present users with a terms of use document that defines the permitted uses of personal information belonging to users, and in this case, users are required to digitally sign the document. Sites must abide by these terms and conditions. Furthermore, the website construction system 30 can include a sample terms of use page in each website template it provides. The privacy policy enforcer 213, 233 can ensure that the terms and conditions in the terms of use document are adhered to. Furthermore, the privacy policy enforcer 213, 233 can ensure that only authorized information is provided to third-party applications by deleting or reorganizing related data.

A third privacy-related issue is supporting unsubscribe requests. Sites must provide users with the option to unsubscribe from any marketing emails. This can be handled by the data/permissions handler 244, which is described in more detail below.

The data/permissions handler 244 can also handle different user permissions set by different users, as described in more detail below.

In the website building system 30 (and websites built therein), the private data proxy 234 allows all or some private data to be kept in a secure repository managed by the website building system 30, and the private data proxy 234 can provide a substitute unique ID (in place of the private data) to the third-party application, which can use this ID to obtain the hidden private data. For example, an email address may be replaced with a substitute "email address ID" and provided to the third-party application 40, so that the third-party application 40 does not have access to the actual email address.

Additionally, the private data proxy 234 may provide a set of interfaces for various communication methods (e.g., email, social network messaging) that the third-party application 40 may use to contact or message the user without the third-party application 40 actually accessing any private data associated with that user. Such private data may include any identifying details that may be used to contact the user (e.g., name, address, email address, phone number (including SMS/MMS), unified communications ID (e.g., Skype), social network ID).

Thus, the private data proxy 234 can enforce user permission field restrictions, enforce user unsubscribe requests, and throttle messages sent to the user (e.g., allowing up to 100 emails per day for a particular third-party application 40 running on a particular site). The private data proxy 234 can define proxy parameters and the private data that will and will not be exposed to third-party applications (for each third-party application 40), and these settings can be made on a field-by-field basis.

The private data proxy 234 can provide third-party applications 40 hosted on the website building system 30's servers with an alternative unique ID that resembles the original private data (e.g., by providing an alternative dummy email address in place of the user's original private email address), "intercept" calls that use that information, and (in this example) forward the email to the correct address. This functionality can also be used to detect third-party applications 40 that exceed their permitted privileges.

It should be understood that a website owner may wish to limit or modify the information provided to particular third-party applications 40. This may be due to, for example, general security concerns, specific privacy commitments regarding any element of user data, or regulatory requirements specific to a particular industry or application. The privacy policy enforcer 213, 233 can implement any such changes made by the website owner and override current settings.

As one example, a website that handles medical information may wish to prevent access to some of the more personal details of contact information when passing the contact information to a third-party application 40 that analyzes the general geographic distribution of users. As another example, a third-party application 40 may experience issues when handling a particular type of contact information. A website owner who wants to continue using the third-party application 40 (despite the known bug) may wish to exclude contacts that cause the known problem, or modify the data so that the problem does not occur.

The converters/conformers 212, 232 can apply pre-specified rules for transforming messages and adapting content. Each such rule can include conditions such as the third-party application 40 to which the rule applies, filtering criteria for selecting messages to which the rule applies, transformation rules (e.g., discarding certain messages (associated with a particular third-party application 40)), and transformations to be applied to a particular field or fields in the activity data structure.

In this way, the hubs 210, 230 can provide different versions of the activity data structure (or none at all) to different third-party applications 40 according to specifications created by the site owner.

Furthermore, the associated website construction system 30 can support message verification and signing to harden the system against failures and intrusion attempts (such as man-in-the-middle attacks aimed at tampering with the payload data of messages from the third-party application 40). Thus, each third-party application 40 registered with the website construction system 30 can have two pairs of private/public keys: one pair used to decrypt messages sent from the third-party application 40 to the website construction system 30 (input key), and one pair used to encode messages sent from the website construction system 30 to the third-party application 40 (output key).

For example, third-party application A sends a message to the website construction system 30. This message is sent using the third-party application ID (external ID of the third-party application (having a third-party application scope)) in the site, and the message is signed by the third-party application. The website construction system 30 receives this message. The verifier/signer 235 verifies the signature using the input key of third-party application A. If this verification does not pass, the verifier/signer 235 reports the input message as invalid, and the message is not sent any further.

The verifier/signer 235 can convert the external ID associated with the message using the internal site ID. The verifier/signer 235 can verify which third-party application 40 should receive the message.

For example, verifier/signer 235 can recognize the external ID of third-party application B for each of third-party applications B1-Bn. Verifier/signer 235 then creates a message for third-party application B and instructs converters/adapters 212, 232 to apply the applicable filtering and transformation rules described above. Verifier/signer 235 then signs the message using the output key of third-party application B and sends the message to third-party application B via router/tracker 231 (or router 211). Third-party application B receives the message and verifies the signature. If the verification does not pass, the message is reported as invalid and is not processed further. It should be understood that verifier/signer 235 performs only server-side processing and does not perform client-side processing, so that confidential verification data is not sent to untrusted clients.

As described above, the system 200 can employ multiple types of communication between the website building system 30 and the third-party application 40. Such communication can include, for example, control communication (e.g., the website building system 30 instructing the third-party application 40 to shut down) and functional communication (e.g., the shopping cart third-party application 40 sending a total purchase amount through the website building system 30 to the billing third-party application 40 (thus modifying the payment or activity communication in the example described herein)). It should be understood that these different types of communication have different profiles and requirements (e.g., regarding the volume, priority, robustness, and response time of messages sent).

In particular, system 200 may experience very frequent activity reporting (e.g., when events in the third-party application's 40 graphical user interface (GUI) are reported as third-party application's 40 activity). Such a large volume of activity reporting may overwhelm portions of the system that handle more important messages. Therefore, system 200 may implement multiple communication channels (e.g., using different ports or multiple concurrent sessions) such that each class of message is sent through a separate channel. In this manner, activity reporting uses a side channel and occurs in parallel with instruction and functional communication without interfering with the latter.

As described above, system 200 can aggregate activity information for the purposes of creating and enhancing contact information and collating activity events associated with specific contacts via contact coordinator 240 and activity coordinator 250. Contact coordinator 240 and activity coordinator 250 can process information for each activity message routed through hub 210 and hub 230. Stream creator 251 can create contact-specific data streams from the activity messages, and elements of contact coordinator 240 can extract and process the data before storing it in contact database 245.

Thus, for each activity stream, an associated contact can be established, and these contacts can be gradually refined using data extracted from activities performed under each data stream. It should be appreciated that the contact coordinator 240 can also recognize the existence of related contacts (multiple contact records found to describe the same person). The contact identifier 272 can recognize such records by matching primary ID fields (email address, phone number, social security number, Facebook ID, etc.). It should be appreciated that some primary ID fields are multi-valued fields (e.g., a person can have multiple email addresses that identify them), while some primary ID fields are strictly single-valued fields (e.g., social security number).

Thus, the data merger 243 can merge contact fields extracted from new activity into a currently established contact, and can merge contacts established for an anonymous user while the anonymous user is using the website with contacts already defined and saved when the anonymous user performs a login action and becomes an identified user (this is sometimes referred to as a "vertical merge"). Furthermore, the horizontal contact merger 277 can perform a "horizontal" merge of two different contacts (established or stored) when it detects that these two contacts are related contacts representing the same user. As described above, this merge can be performed by actual merging (i.e., converting two separate contacts into a single contact), by merging one contact into another, or through a virtual merge (i.e., maintaining the two contacts as separate contacts but linking them to indicate they represent the same user, with or without merging the actual contact information and activity streams). Furthermore, it should be understood that even in the case of a virtual merge, additional information can be added to the virtually merged and linked contacts.

Thus, data extractor 241 can extract contact-type information from the associated activity data structure, and data merger 243 can merge this contact-type information into contacts (anonymous or identified) associated with the activity stream. If contact-type information I includes a primary ID field, data merger 243 checks for associated contacts based on the value of the primary ID field and, if found, merges these contacts. Additionally, data merger 243 can check whether the activity establishes the user's identity within the site (e.g., site login activity), and if so, merges the anonymous contact with the existing contact record stored for that user, making the contact an identified contact from now on.

It should be appreciated that the contact identifier 272 can implement multiple methods for identifying site users, such as tracking sessions with a single anonymous user (not logged in to the site) using cookies, using site login for registered users, using social login for site users whose accounts are associated with social networks, or by matching primary ID fields (such as email address or phone number) to identify that two user profiles describe the same user.

Furthermore, it should be understood that site users whose details are stored in the contact database 245 can be categorized as anonymous users who are not registered with the site, registered users, and potential users (those who are not yet officially registered with the site but have records imported from external sources).

Relevant websites can install persistent cookies that persist between sessions, allowing them to continue retrieving information for the same contact record from multiple anonymous sessions running on the same computer using the same browser. Thus, even anonymous users can have a significant amount of contextual and contact information.

Registering users must provide an ID that is unique to that particular site. Multiple types of IDs can be used, such as an ID specific to the individual site (e.g., username), an external identifier (email address, phone number, social security number, etc.), or an external identifier provided by another system (social network ID, Google ID, OpenID ID, etc.).

When a user registers through a social network login, the site can use personal information available on the social network to populate the same user's site profile. Additionally, the data extractor 241 can re-access the social network profile to detect any changes to the personal information and update the site user's profile.

Registered users typically must log in to the system to establish their identity, although the system may offer a "stay connected to this system" option. Such a login procedure may be explicit (the user invokes a login dialog), implicit (e.g., the user is prompted to provide some identifying information when adding a post to a blog), or based on an external login (the system invokes a login procedure associated with another system, such as a social network login or OpenID login). Additionally, the login procedure may be modified through a physical device (e.g., a security token connected to the system directly or via a wireless interface), through the use of biometric information (including both user biometric parameters (e.g., fingerprint, iris scan) and user behavior detection (e.g., typing pattern detection)), or through any combination of the methods detailed above.

Furthermore, it should be understood that information can flow back and forth between the social login procedure and regular login. For example, a social ID can be associated with a site member ID, such that social logging in is implicitly logging in to the site, or a site member ID can be associated with one or more social network IDs, such that logging in to the site identifies the user to one or more social networks.

When a user performs an explicit logout, the contact handler 242 generates a new anonymous user cookie and can therefore open a new anonymous session (or series of sessions), with activity in this session saved under the new anonymous contacts. On a further login, this new anonymous contact can be merged with the contacts identified at that login.

Referring now to Figure 19, this diagram illustrates the login/logout process for an anonymous user. A user can begin using the system anonymously. When the user performs their first activity, act1, in a third-party application, the contact handler 242 creates a contact and the stream creator 251 automatically creates the activity stream, anon1. The stream merger 252 merges the information from act1 and the information from the next activities, act2 and act3, into the user, anon1.

When the same user logs in as user X, data merger 243 merges anon1's contacts (and other related contact data obtained from the activity stream) with user X's contact information. It should be further understood that stream merger 252 merges information extracted from further activities act4 and act5 into one stream, and then data extractor 241 extracts user X's contact information. When user X logs out, contact handler 242 creates a new cookie to disassociate future activities from user X. Thus, when new activity act6 is performed, contact handler 242 creates a new anonymous contact anon2, and data extractor 241 saves the extracted contact details (and activities) of that contact under the newly created anonymous contact anon2.

If user anon2 performs a second login as user Y (as in scenario A), data merger 243 merges user anon2's contact information (updated by act 6 and act 7), along with any further activity, into the identified user Y's contact details.

When user anon2 logs in a second time as user X (as in scenario B), the data merger 243 merges user anon2's contact information (updated by act 6 and act 7), along with any further activity, into user X's contact details (already updated to reflect act 1 through act 5).

It should be appreciated that the activity data structure associated with an activity may also include contact details. The data extractor 241 may extract this information and forward it to the data merger 243, which may merge this information with existing contact information in the contact database 245 to enrich the existing contact information. Furthermore, it should be appreciated that the data extractor 241 may extract details from a specific activity message, the entire stream, another contact, or an external source (such as an IP-to-geographic address translation service, described in more detail below). As noted above, the contacts in the contact database 245 may include contact details explicitly provided by a user as part of a registration or sign-up process, or contact details extracted from a social networking account used by a user when signing up for a website (via a social login/registration feature), or contact details provided by a user when updating their user profile. Additionally, the data extractor 241 may obtain contact information from external sources (e.g., when a user specifies only a U.S. zip code, the site uses this information to obtain full address information from an external zip code decoding web service).

As described above, the contact identifier 272 can recognize two contacts as related to each other based on their primary ID fields (username, email address, phone number, etc.). Once contact A (new) and contact B (existing) are determined to be related to each other, the data merger 243 can merge A into B (B is the master). This can be done using field merging rules such as the following:

B1 = B or A (e.g. "B||A"): Take B, and if B is null or empty, take A.

B1 = Mathematical Function (A, B): Important cases of private data are:

B1 = A + B: For example, the number of visits, the total purchase amount B1 = min(A, B): For example, the date of registration to the site B1 = max(A, B): For example, the date of the last activity

B1 = list-unit(B, A): Concatenates list A to the end of list B and deletes elements of A that overlap with elements of B (i.e., B1 = B & (A - B)). The data merger 243 can determine overlaps between list elements according to the following rules.

For lists of normal values (i.e., scalars), use normal value comparison.

For lists consisting of structures, a specific subfield of the structure is used as the comparison key. For example, the address type (home, business, delivery, etc.) in a website building system 30 that supports multiple addresses.

Comparing normalized numbers. (For example, see processing phone numbers below.)

If structure A is a more specific version of structure B, combine A with B (explained in more detail below).

Higher Certainty Score: A certainty score can be assigned to a value (e.g., a different certainty score is assigned to information provided directly by the user and information inferred about the user). The data merger 243 can select the value with the higher certainty score.

It should be understood that some field types have a normalized format. For example, phone numbers can be normalized to a normalized US format (e.g., (999) 555-1234) or an international format (e.g., +1-999-555-1234). The data merger 243 can convert field values to the normalized format for comparison, for example, when comparing contact primary keys (e.g., phone numbers) or checking for duplicates in merged lists.

Data merger 243 can compare two structured values that have the same basic structure (e.g., address values consisting of multiple subfields (country, state, zip code, street, number, etc.)). Structure Y is a detailed version of structure X if the value of each non-empty field in structure X is equal to the value of the same field in structure Y (i.e., Y contains the values of all non-empty fields of X, and possibly some additional fields). Thus, data merger 243 can merge A with B if A is a detailed version of B and A is not identical to B.

It should be appreciated that the data extractor 241 can infer a contact's address from the IP address from which the activity originated. This functionality is only used when the activity originated from a browser session and the user's address has not been captured. Therefore, the data extractor 241 can extract state/country information according to the geographic information of the IP address. In this case, the address is marked as an "estimated geographic IP address." This marking is necessary to prevent the address field already containing a (possibly inaccurate) address based on the IP mapping from conflicting with a later address merging process, thereby preventing the later storage of a detailed (but fundamentally different) address in the contact database 245.

Data merger 243 can also handle tag conflicts in merged lists. It should be understood that when merging lists, a situation may arise where there are two entities (one from Contact A and the other from Contact B) that have different but the same tag. In this scenario, data merger 243 will include both entities with the same tag in the list.

So the combination [{tag:"home", email:"a@b.com"}] + [{tag:"home", email:"c@d.com"}] creates [{tag:"home", email:"a@b.com"}, {tag:"home", email:"c@d.com"}]. Use this method when the fields being merged are marked as "Allow non-unique list tags."

Additionally, the data merger 243 can use linguistic, syntactic, or other text analysis methods, as well as reference and use of external data sources or services, when attempting to combine contact information. For example, a user may enter two different street names for their home address in two activity records, but the same street number, city, and zip code. The combiner 273 can apply text analysis (e.g., a soundex algorithm) when comparing the two entries, and can also compare the two versions of the street name with street names from external sources for a given city and zip code. In such a case, the combiner 273 can select the standard street name if both addresses are similar (but possibly not identical) to the standard street name and all other address data fields have the correct values.

Additionally, the data merger 243 can merge contact information according to login/session information. A user may start a session using the site without logging in or registering, perform some activities as part of that session, and then register or log in later, so that session is associated with a newly created user profile or the registered user's existing profile (including contact information).

Once a user begins a session (as an anonymous user), the contact identifier 272 can track the user for the duration of that session (using cookies, session IDs, etc.), and the contact handler 242 can create established contacts for that particular anonymous user based on the activities performed by the user during the anonymous session. Additionally, the router/tracker 231 can continue to track the anonymous user across multiple sessions from the same computer. This tracking can be achieved through the use of persistent cookies (rather than session cookies).

When a user registers, the data merger 243 can use the information from the constructed contacts to initially populate the user profile. When a user logs in, the data merger 243 can initially merge the information from the constructed contacts with the existing user profile. It should be understood that the information from the constructed contacts is merged according to the user's site ID because the data merger 243 does not retain any primary ID (e.g., email address) in the constructed contacts' information to use for merging, other than the site ID. It should also be understood that such merging may result in inconsistencies in the aggregated information. When merging anonymous constructed contacts with existing profile data, inconsistencies may unavoidably occur. For example, suppose an anonymous user fills out a data form (displayed by some third-party application 40) using the name John Smith, and then later logs into their account (using the same or a different browser session) using the name Jane Doe. In this case, the later login (for example) may actually be a login made by a different person using the same computer, or the original user may have used a pseudonym in the contact form to protect their privacy. The same is true when the data merger 243 merges multiple anonymously constructed contacts.

The conflict resolver 274 can generally handle conflicts automatically because most fields (including primary ID fields such as email addresses and phone numbers) are list fields that can contain multiple values. This is only applicable if the same underlying site is used multiple times. Conflicts that cannot be resolved (e.g., by merging multiple values into a list value) can be flagged for manual resolution by the site owner or end user (who can decide which value to use) or for resolution using another technique.

Thus, the contact information constructed may not reflect a single person, but rather a series of users accessing the same site via the same computer.

As mentioned above, the data merger 243 typically merges contacts according to a primary ID field (such as an email address or phone number) when multiple contacts are created or modified.

The information entered is a contact record (Entered Contact C) with one or more primary ID fields with one or more values (e.g., a contact record with two email addresses and three phone numbers). Multiple primary ID fields may be required because a user may have (for example) home/work/cell phone numbers and home/work email addresses, and the user may use any of these interchangeably in the contact form.

The data merger 243 can normalize the primary ID values and create queries that search for contact records containing any of the normalized primary ID values (e.g., "(phone=P1 OR phone=P2)" or "(email=E1 OR email=E2)"). Furthermore, the data merger 243 can limit the scope of the query to a particular site's contact database 245. Furthermore, the data merger 243 can query the contact database 245 and obtain a list L of matching contacts (including the input contact C).

If the entered contact is a registered site member (for a particular site), data merger 243 may remove contact C from list L and merge all remaining contacts in list L into contact C. Data merger 243 may then save the updated contact C back to contact database 245 and remove all remaining contacts in list L from contact database 245. Alternatively, data merger 243 may perform a virtual merge as described above, i.e., combine all contact information (i.e., update all contact records to include all available information) and mark matching contact records as belonging to the same person (instead of deleting "duplicate" contact records). This may be necessary, for example, if third-party applications 40 store or use unique internal IDs in contact records, and deleting contact records would therefore cause these third-party applications 40 to function incorrectly. The same process (i.e., marking contacts as related to each other rather than deleting them) may also be applied in other cases, which will be described in more detail below.

If the entered contact is "not" a registered site member, the data merger 243 can check the number of site member contacts contained in list L. If there are 0 site members, the data merger 243 can remove contact C from list L and merge all remaining contacts in list L with contact C. The data merger 243 can then save the updated contact C back to the contact database 245 and remove all remaining contacts in list L from the contact database 245.

If one site member (Contact D) exists, the data merger 243 can remove Contact D from List L and merge all remaining contacts in List L (including Contact C) into Contact D. The data merger 243 can then save the updated Contact D back into the contact database 245 and remove all remaining contacts in List L from the contact database 245.

If there are two or more site member contacts (D, D1, D2, ...), the data merger 243 can select contact D from the found site member contacts (D, D1, D2, ...) and delete contact D from list L. The data merger 243 can then create a sublist LL from list L that includes the contacts in list L that are not site members. The data merger 243 can then merge all of the remaining contacts in list LL with contact D. The data merger 243 can then save the updated contact D back to the contact database 245 and delete all of the remaining contacts in list LL from the contact database 245.

As mentioned above with regard to merging at login, data inconsistencies can occur. However, because the list value creator 275 can create list value fields (with multiple values) and also define clear priorities between contacts, this problem does not arise in most cases.

For example, the data merger 243 merges the following contacts:

Contact1 = [Phone1, Email1];
Contact2 = [Phone1, Email2];
Contact3 = [Phone2, Email2];

The data merger 243 can generate merged contacts as follows:

Merge contacts = [Phone = [Phone 1, Phone 2], Email = [Email 1, Email 2]].

It should be understood that contact database 245 may contain contact information from multiple sources with different levels of permission for use. While the following discussion uses email as an example, the following discussion and techniques also apply to any of the types of information previously mentioned that may be used to contact a user (e.g., phone number, fax number, Skype ID, instant messaging ID, social network ID, etc.).

For example, the permissions regarding the use of an email address may differ depending on how the email address was provided to the site. Some possible ways an email address may be obtained are via registration ID, contact form, newsletter sign-up, or unsubscribe request. Additionally, email addresses may differ in the "Permitted Uses Agreement" digitally signed by the user.

It should be understood that the website building system 30 generally has information regarding the permitted uses of a given email. However, website owners may have different, separate, or additional information. For example, this may be due to the nature of different sign-up forms within the site, or if contacts from different sources containing additional permitted use information are imported into the system by the website.

The data/permissions handler 244 can enforce correct usage policies for third-party applications 40 used within the site, in order to assist website owners in managing this information.

The contact record for the associated contact can therefore contain two information fields. The first field is the website permissions field, which contains the permissions or suggested permissions calculated and derived by the website from the user's activity. A contact form only implicitly specifies functional email, while a subscription form implicitly specifies recurring email. The second field is the site owner permissions field, which is based on the value of the website permissions field. The site owner can change the suggested permissions for the website and set them as they wish, but they are responsible for any use that goes beyond the scope of the permissions defined by the website permissions field.

It should be understood that the value in the website permissions field represents the website's best understanding of the user's intent. The value in the site owner permissions field is a value assigned by the website and used by the third-party application 40 and other parts of the system (e.g., by a third-party application 40 providing newsletter distribution).

The data/permissions handler 244 can use these permission fields to define permissions in multiple ways. For example, the data/permissions handler 244 can implement any of the following codes (for email addresses and other contact IDs) or combinations and variations thereof:

Unknown: The email address was extracted from an unknown source and cannot be used for email purposes.

Email ID: The email address provided for registration purposes. It may not be used to send emails other than those related to your registration (e.g., confirmation of registration, forgotten password, notification of suspected security breaches, etc.).

Functional emails: Served for specific features and allow one-time emails. For example, purchase confirmation emails or emails served for specific contact forms.

Recurring Emails: Allows certain websites to send multiple periodic subscriptions and advertisements, requiring explicit subscription/approval.

Shareable Email: Allows the website and its partners (third party applications 40, other ^4th parties) to send multiple recurring subscriptions and advertisements, where explicit subscription/approval is required and may include detailed information about permitted sharing.

Opt-out: The user has explicitly unsubscribed. We will no longer send emails to that user (except for opt-out notices, if applicable).

It should be understood that the data/permission handler 244 can use alternative methods, such as a permission bit mask (similar to those used in UNIX and Linux systems) or an ACL (Access Control List) mechanism. Additionally, the data/permission handler 244 can implement separate permission fields for individual pieces of contact information (e.g., email address, instant messenger address, social network ID, etc.).

In a typical usage scenario, the contact database 245 contains a first set of email addresses collected from a contact form and a second set of email addresses from subscription requests. The website can invoke the newsletter delivery third-party application 40, knowing that the third-party application 40 should send emails "only" to users in the second set of users (users who have submitted subscription requests).

The advantages of such a system include better protection (both technical and legal) for both websites and website owners with respect to users being accidentally spammed and their personal information being misused, and the ability to actually enforce privacy policies when the system is used in conjunction with the private data proxy 234, as described above. Furthermore, unsubscribe requests can be more rigorously enforced.

Thus, for a user, streams of activity between the associated website building system 30 and any associated third-party applications 40 can be generated. These streams may be referred to as activity streams. Each activity stream can be used as a source of information about a single contact. Furthermore, if different activity streams are determined to have the same origin, the activity data structures of the individual streams can be merged to form a contact. For example, a single user may perform activity anonymously across two devices (such as a mobile device and a PC). Such a user generates two anonymous streams, and messages are stored under these anonymous streams. Once these streams are recognized as being associated with the same user, they can be merged.

The processes and displays described herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used in conjunction with programs in accordance with the teachings herein, or it may prove convenient to construct specialized apparatus to perform the desired method. The desired structure for a variety of these systems will be apparent from the above description. Further, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the present invention as described herein.

Unless otherwise indicated, and as should be clear from the preceding discussion, throughout this specification, references to the use of terms such as "processing," "calculating," and "determining" should be understood to refer to the operation or processing of a computer, computing system, or similar electronic computing device (a device that manipulates or converts data represented as physical quantities, e.g., electronic quantities in a computing system's registers or memory, into other data similarly represented as physical quantities in the computing system's memory, registers, or other such information storage, transmission, or display device).

Embodiments of the present invention may include an apparatus capable of performing the operations described herein. This apparatus may be specially constructed for the desired purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored on a computer-readable storage medium, such as, but not limited to, any type of disk (such as a floppy disk, optical disk, or magneto-optical disk), read-only memory (ROM), compact disk read-only memory (CD-ROM), random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical card, flash memory, or any other type of medium suitable for storing electronic instructions and capable of being coupled to a computer system bus.

While certain features of the present invention have been illustrated and described above, numerous modifications, substitutions, changes, and equivalents will be apparent to those of ordinary skill in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes that fall within the true spirit and scope of the invention.

[Related Applications]
This application claims priority to U.S. Provisional Patent Application No. 61/911,485, filed December 4, 2013, which is incorporated herein by reference in its entirety.

Claims (14)

1. A system for a website hosted by a website building system (WBS), comprising:
at least one database storing an activity stream of data extracted from activity messages between anonymous users of the website and at least one third-party application instantiated in a page of the website;
a hub that facilitates communication of activity messages between the website and the at least one third-party application, the hub performing at least one of routing, tracking, transforming, and validating the activity messages;
a contact coordinator including a contact handler that creates an anonymous user ID for the anonymous user;
an activity coordinator that captures the activity messages,
a stream creator that creates an activity stream for the activity message associated with the anonymous user ID and stores the activity message in the at least one database as a first message in a sequence for the activity stream when a first contact is identified with the anonymous user ID;
an activity-stream merger that adds further activity messages of the anonymous user to the activity stream associated with the anonymous user ID;
a stream-stream merger that converts two separate activity streams into one stream, the stream-stream merger comprising a vertical stream merger that merges the stream created for the anonymous user and the stream associated with a registered user when the two streams are combined at login or registration time;
an activity coordinator comprising :
A system comprising: The hub is embedded in the website, the hub comprising:
a router and tracker for routing and tracking the activity messages between the anonymous users of the website and the at least one third-party application;
a privacy policy enforcer that enforces the terms of a privacy agreement between the website and the at least one third-party application;
a private data proxy that implements at least one of a private data proxy and a private data substitution and that implements user permission field restrictions between the website and the at least one third-party application;
a verifier and signer that verifies a signature of the activity message using an input key of the at least one third-party application, converts an external ID associated with the activity message to an internal ID of the website, and signs the activity message using an output key of the at least one third-party application;
The system of claim 1 , comprising at least one of: The system of claim 1 further comprises a data merger that associates the anonymous user ID with a registered user of the website and stores the activity stream associated with the anonymous user ID in the at least one database along with data associated with the registered user. The system of claim 1, wherein the stream-stream merger further comprises a horizontal stream merger that merges at least two separate streams according to a common anonymous user. The data merger
a contact identifier that identifies at least one of: identifying identical primary ID field values in at least two contact records; identifying primary key field values in the at least two contact records that are the same when normalized; identifying the site user using a cookie; identifying the site user using a site login for registered users; and identifying the site user through a social login for site users with an account associated with a social network;
a combiner that combines the contact information using at least one of linguistic analysis, syntactic analysis, and text analysis, and references to external data sources and services;
a conflict resolver that resolves conflicts between contact records according to predefined rules;
a list value creator that creates list value fields between contact records to prevent said inconsistencies;
a horizontal contact merger that merges two unrelated activity streams associated with the anonymous user upon detection of a common anonymous user ID;
a vertical contact merger that merges the activity stream associated with the anonymous user with a contact record associated with a registered user upon login or registration;
The system of claim 3 , comprising at least one of: The system of claim 5, wherein the horizontal contact merger comprises a virtual merger that maintains at least two contact records as separate and links them together so that they are marked as representing the same user. The system of claim 5, wherein the vertical contact merger comprises a virtual merger for maintaining the anonymous user and the registered user as separate and linking them together so that they are marked as representing the same user. 1. A method for a website hosted by a website building system (WBS), comprising:
storing in at least one database an activity stream of data extracted from activity messages between anonymous users of the website and at least one third-party application instantiated in a page of the website;
facilitating communication of activity messages between the website and the at least one third-party application, wherein the facilitating communication includes at least one of routing, tracking, transforming, and validating the activity messages;
creating an anonymous user ID for the anonymous user;
capturing the activity message; and
creating an activity stream of the activity messages associated with the anonymous user ID;
storing the activity message in the at least one database as a first message in a sequence for the activity stream if a contact is first identified as the anonymous user ID;
adding further activity messages of the anonymous user to the activity stream associated with the anonymous user ID;
converting two separate activity streams into one stream, said converting comprising merging the stream created for the anonymous user and the stream associated with a registered user when the two streams are combined at login or registration time.
Equipped with
A method comprising: facilitating said communication includes:
routing and tracking the activity messages between the anonymous users of the website and the at least one third-party application;
enforcing the terms of a privacy agreement between the website and the at least one third-party application;
implementing at least one of a private data proxy and a private data substitution to enforce user permission field restrictions between the website and the at least one third-party application;
verifying a signature of the activity message using an input key of the at least one third-party application;
converting an external ID associated with the activity message to an internal ID of the website;
signing the activity message using an output key of the at least one third-party application;
The method of claim 8 , comprising at least one of: The method of claim 8, further comprising: associating the anonymous user ID with a registered user of the website; and storing the activity stream associated with the anonymous user ID in the at least one database along with data associated with the registered user. The method of claim 8, wherein the converting further comprises merging at least two separate streams according to a common anonymous user. The associating step includes:
at least one of: identifying identical primary ID field values in at least two contact records; identifying primary key field values in the at least two contact records that are the same when normalized; identifying the site user using a cookie; identifying the site user using a site login for registered users; and identifying the site user through a social login for site users with accounts associated with a social network;
combining the contact information using at least one of linguistic analysis, syntactic analysis, and text analysis and references to external data sources and services;
Resolving conflicts between contact records according to predefined rules;
creating a list value field between contact records to prevent said inconsistencies;
merging two unrelated activity streams associated with the anonymous user due to the detection of a common anonymous user ID;
merging the activity stream associated with the anonymous user into a contact record associated with the registered user at login or registration;
The method of claim 10 , comprising at least one of: The method of claim 12, wherein merging the two unrelated activity streams comprises maintaining at least two contact records as separate and linking them to each other so that they are marked as representing the same user. The method of claim 12, wherein merging the activity streams comprises maintaining the anonymous user and the registered user as separate and linking them to each other so that they are marked as representing the same user.