System and method for a website

Abstract

To provide a system for a website hosted by a website construction system.SOLUTION: A server of a website construction system 200 is provided with an activity coordinator including: a stream generator for generating a contact coordinator including a contact handler for generating anonymous user ID for an anonymous user and an activity stream for an activity message to be associated with the anonymous user ID, and storing the activity message in an activity database as a first message of a sequence related to the activity stream in the case that contact is identified as the anonymous user ID first; and a stream merger having a function for adding further activity messages of the anonymous user to the activity stream to be associated with the anonymous user ID and a function for combining a plurality of activity streams with the anonymous user ID.SELECTED DRAWING: Figure 15

Description

[Technical Field]

[0001] The present invention relates to online applications and methods for their use, particularly in conjunction with third party applications included therein. [Background technology]

[0002] Numerous website building systems and other interactive application building tools are commercially available 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.

[0003] 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.

[0004] 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.

[0005] A website building system has an internal data architecture for organizing data and elements within the system. This architecture may differ from the target site's appearance as seen by users and may also differ from the way a typical HTML (Hypertext Markup Language) page is sent to a browser. 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). A typical architecture for 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).

[0006] 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.

[0007] Designers using such website building systems can design new sites from scratch (start 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.

[0008] 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 from 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.

[0009] 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's (WBS) vendor or another organization. Additionally, third-party applications may be obtained directly from the third-party application vendor (with or without an AppStore), in which case the vendor may provide the actual installation module or only an activation or access code.

[0010] 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.

[0011] 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 application for a blog 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).

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

[0013] 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 or more, or all, of the four possible combinations (widget or section, single-page or multi-page).

[0014] 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 entries in a blog third-party application), a minipage selection screen, or some other minipage.

[0015] 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, such as allowing one instance of a third-party application across the entire website, allowing creation of multiple instances of third-party applications within a website (but only one instance per third-party application), or allowing creation of multiple instances of multiple third-party applications (but only one instance per page). Furthermore, the website building system can also allow multiple instances of component-type third-party applications (but not section-type third-party applications) per page, and can also allow creation of multiple instances of multiple third-party applications without restrictions on the number, multiplicity, or location of the third-party application instances.

[0016] An instance of a third-party application can have content that is specific to the instance. For example, a third-party application for an e-shop can 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).

[0017] For purposes of discussion, the website page (or minipage) that contains the third-party application and its minipages or 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.

[0018] Third-party applications are typically deployed on the servers of the website building system vendor, the third-party application vendor, external (fourth-party) servers, 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 client-side code of the website building system, as shown in Figure 1), which we will refer to below.

[0019] The website building system vendor's server acts as a contact point 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) form a direct connection between the client's computer and the third-party application vendor's server when, for example, video streaming is requested.

[0020] Included instances of third-party applications can have their own internal content, similar to how 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.

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

[0022] Server-Side Processing: (Referring now to Figure 3.) In this method shown in Figure 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 a 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.

[0023] Client-Side Processing: (Referring now to Figure 4.) In this method illustrated 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 to a client-side processing component [h] via a communications medium [e]. 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 information sources and presents the integrated application to a browser (or other client agent) [i].

[0024] iFrame Inclusion: (Referring now to Figure 5.) In the method illustrated in Figure 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. [Prior art documents] [Patent documents]

[0025] [Patent Document 1] US Patent Application Publication No. 2013 / 0219263 Summary of the Invention [Means for solving the problem]

[0026] 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 of identified contacts and anonymous contacts, at least one of the identified contacts and anonymous contacts being users of the website. The system further includes a contact coordinator that retrieves and analyzes contact-related information from the stream to enrich previously held information for the contacts, and at least one database that stores the activity stream and the contact-related information for use by the website and the contacts.

[0027] Furthermore, in accordance with a preferred embodiment of the present invention, the 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 the at least one third-party application; a privacy policy enforcer that enforces a privacy policy between the website and the 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 the 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 the at least one third-party application; and a verifier / signer that verifies the signature of the 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.

[0028] Furthermore, in accordance with a preferred embodiment of the present invention, the activity coordinator includes at least one of a stream creator that identifies contacts 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 logs activity data from the activity streams to at least one database.

[0029] Further, 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.

[0030] Additionally, 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.

[0031] 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.

[0032] 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 individual 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 a registered contact are linked at login or registration.

[0033] 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.

[0034] 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.

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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 user of the website. 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.

[0039] 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 the at least one third-party application; enforcing a privacy policy between the website and the at least one third-party application; applying at least one pre-specified message transformation / content adaptation rule between the website and the 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 the 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.

[0040] 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.

[0041] Furthermore, according to a preferred embodiment of the present invention, the obtaining and analyzing step includes at least one of extracting contact-related information from at least one of the at least one 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. Further, 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.

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

[0043] 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.

[0044] 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 a registered contact are associated at login or registration.

[0045] Further, according to a preferred embodiment of the present invention, merging at least two contact information records includes at least one of identifying the same primary ID field value in at least two of the contact information records, identifying the same primary ID field value when normalized in at least two of the contact information records, identifying the site user using a cookie, identifying the site user using a site login in the case of a registered user, or identifying the site user through a social login in the case of a site user with an account associated with a social network. Furthermore, 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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, together with objects, features, and advantages thereof, may be had by reading the following detailed description together with the accompanying drawings. [Brief explanation of the drawings]

[0051] [Figure 1] Schematic diagram of the deployment configuration between the website building system and third-party applications [Figure 2] Schematic diagram of internal content management for third-party applications [Figure 3] Schematic diagram of including a third-party application in a containing web page via server-side processing [Figure 4]Schematic diagram of including a third-party application in a containing web page via client-side processing [Figure 5] Schematic diagram of including a third-party application in a containing web page via iframe inclusion [Figure 6] Schematic of existing suboptimal third-party application display when page layout changes [Figure 7A] 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; [Figure 7B] 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; [Figure 8] Schematic diagram of the Document Object Model compared to the Component Model [Figure 9] Schematic diagram of the blog multipart third-party application example [Figure 10] Schematic of an example modular third-party application for sale [Figure 11A] 1 is a schematic diagram of a different implementation of a communications hub constructed and operative in accordance with the present invention; [Figure 11B] 1 is a schematic diagram of a different implementation of a communications hub constructed and operative in accordance with the present invention; [Figure 11C] 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; [Figure 12] 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; [Figure 13] 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; [Figure 14]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; [Figure 15] 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. [Figure 16A] 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; [Figure 16B] 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; [Figure 16C] 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; [Figure 16D] 16 is a schematic diagram of elements of the system of FIG. 15, constructed and operative in accordance with the present invention; [Figure 17] 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; [Figure 18] Schematic diagram of message passing for client-side and server-side third-party application activity messages [Figure 19] Schematic of the login / logout process during a user's website session DETAILED DESCRIPTION OF THE INVENTION

[0052] It will be appreciated 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 several figures have been designated by the same reference numerals.

[0053] 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.

[0054] Applicant has recognized that there are many 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.

[0055] 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 within 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).

[0056] Third-party applications may have their own display styles (color schemes, fonts, text sizes, etc.) that may match some containing web pages but may be visually problematic or inconsistent with other containing web pages.

[0057] Another limitation is the inflexibility of the display of third-party applications from the containing site's perspective. If the site must be visually modified (e.g., to deploy 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 scrolls to complete the purchase and significantly reducing the likelihood that the purchase will actually be completed.

[0058] 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 a video in the background, a user may want another area of ​​the screen to display a small area of ​​the screen dedicated to broadcasting the latest news and weather information (e.g., a live stream from CNN). A user may want their study session to automatically pause when the weather forecast for their area begins.

[0059] 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.

[0060] Applicant has recognized that this integration can be achieved by using 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.

[0061] The following discussion focuses on the iframe inclusion method, which is preferred because it is built into and integrated into modern browsers and does not require the creation of specialized 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.

[0062] 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 in the design phase, and FIG. 7B illustrates the system 100 at 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 App Store 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 can further include a client-side representation of the App Store 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 so that they can be used. Note that the system 100 may include multiple third-party servers 50 belonging to multiple vendors of the third-party applications 40.

[0063] 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 appears at 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 thus there is no application TPA property sheet 23 or repository.

[0064] 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 a 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 are 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 the third-party application 40 can be purchased as needed via the App Store 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 instance of the third-party application 40, as described in more detail below. Additionally, the designer 5 can use the linker 23 to manually specify communication channels (if desired) between multiple included third-party applications 40. It should be further understood that the designer 5 can use the linker 23 to specify unique communication connections and rules between the containing web page that he or she is building and the instances of the third-party applications 40 that are included therein (such as the simultaneous display of a video and a CNN news report, as discussed above). It should be understood that the links created by the linker 23 can be modified for the life of the website.

[0065] It should be understood that the designer 5 may obtain the third-party application 40 through a channel external to the App Store 25, such as an external App Store operated by the vendor or an external merchant of the third-party application 40. 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.

[0066] It should be appreciated that 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 order for the linker 23 to be able to establish a communication channel if necessary. In the case of components based on associated templates (discussed in more detail below), this identification is performed in advance by the vendor of the third-party application 40. Components within associated templates can be given unique reference IDs, which the third-party application 40 can use when communicating with those components.

[0067] Furthermore, it should be understood that in the case of a multi-part third-party application 40 (i.e., one 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.

[0068] 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., must be a text component, used as a blog talkback label). This list can be listed in the third-party application 40's entry in the App Store 25, and the designer 5 can use the linker 23 to specify components (fields) in the containing web page 203 that meet the requirements of the third-party application 40. 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.

[0069] 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 huge 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.

[0070] Referring now to Figure 8, Figure 8 shows how a 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].

[0071] 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 those components (possibly including the "containment path" leading to those 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, allowing the third-party application 40 to traverse the component model of the containing web page 203 to identify the required components.

[0072] It should be further 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 and functions it performs, and any installed logging third-party application 40 can receive these information packets.

[0073] 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 run time, as will be explained in more detail below.

[0074] Reference is now made to Figure 7B. In this embodiment, the elements are the same as those in Figure 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 understood that the viewer 201 may include multiple viewports 202, each for displaying a different instance of the 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.

[0075] It should be appreciated 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 these communications 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.

[0076] 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 communications 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 the 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.

[0077] Furthermore, it should be understood that the system 100 can be implemented using both online and offline website building systems 30, and that the 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 the system 100.

[0078] Additionally, the system 100 may 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 large organization.

[0079] Additionally, 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.

[0080] Additionally, the system 100 may implement a multi-part third-party application 40. A multi-part third-party application 40 may include multiple display regions, each handled using a separate iframe. These regions may also cooperate (optionally) through a communications hub 205, as described in more detail below.

[0081] Referring now to FIG. 9, an example of a multi-part third-party application 40 is shown. As shown, a blog third-party application [a] obtained from the App Store [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 a single application (as in the blog example above) or as optional parts of a single application (including multiple 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 is true for displaying multiple versions of a third-party application (eg, having small and large versions of the third-party application, or having portrait and landscape versions of the third-party application).

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

[0083] 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 further be appreciated that this display can be enabled by the communications hub 205, as described in more detail below.

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

[0085] In existing systems, each third-party application 40 is considered a separate entity, and collaboration between two third-party applications 40 (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 cooperating sub-modules that can be purchased and installed separately.

[0086] Referring now to Figure 10, this figure shows 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 another third-party application vendor. 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, using a list of interface names based on a dot-separated hierarchical name notation (eg, My_CRM_TPA.NewClient.GetInfo) and a specification of the interface parameters.

[0087] 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 knows (for example) what functionality is handled by the missing interface), required / optional status, and a list and type of interface parameters. It should be understood that each third-party application module still resides in a separate iframe (or set of iframes). Interface operation is based on communication channels, which are described in more detail below.

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

[0089] Additionally, it should be appreciated that the designer 5 can edit and run the completed website while the required (and optional) interfaces are still unresolved. However, the designer 5 cannot publish the created website until all required interfaces are resolved, and a message will be displayed if the designer 5 attempts a function that requires the hub 205 to launch a third-party application module that still has required interfaces that are unresolved.

[0090] It should further be understood that the App Store 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 further search based on required interfaces, optional interfaces, or both types of interfaces. It should further be understood 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).

[0091] 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 adapter modules added by the supplier of the website building system 30 or by an outside vendor, which adapt the specified required interface to another format.

[0092] 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 the created online application, without the need to use the specific technologies (e.g., IP communication, HTTP, HTML, etc.) used by typical web infrastructures.

[0093] It should be appreciated that standard cross-domain communication methods known in the art may be used to facilitate cross-domain communication, including:

[0094] HTML5 PostMessage: A standard feature of HTML5 that provides secure cross-domain messaging. HTML5 Windows.Postmessage allows secure messages to be sent 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 should be sent, and for the receiving iframe to verify the domain from which the message was sent.

[0095] Message URL fragment identifiers: 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 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.

[0096] Dedicated Communication Web Service: The website building system 30 provides a dedicated web service hosted on the website building system's server 20. Various communication endpoints connect to this server to send messages or check for waiting messages. This can be done by 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.

[0097] HTML5 Local Storage: HTML5 provides a structured local storage feature that can be used to store queued messages. However, local storage can only be accessed by web content that belongs to the same domain as the containing iframe. Solutions developed in this area include the underlying technology used by the Meebo XAuth product (now owned by Google), which provides support for a small server to create the required intermediate iframe, allowing domain-specific local storage to be accessed by an iframe belonging to a foreign domain.

[0098] 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 the HTML5 file access APIs (File API, FileWriter API, FileReader API) can be used to build a cross-iframe communication channel. However, the sandboxed local file system created by the HTML5 file system access API is still only accessible from within the origin (origin-private), and therefore requires an intermediate iframe / server component to overcome the same-origin limitation.

[0099] 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.

[0100] 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.

[0101] It should further 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 to components from the third-party application 40. 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.

[0102] 11A, 11B, and 11C, Figures 11A and 11B show different embodiments of hub 205, and Figure 11C shows the function of various elements of hub 205.

[0103] 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).

[0104] 11A, which illustrates 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, a message [c] sent from (for example) 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.

[0105] 11B, which 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 using 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 included in third-party applications, and this information may be accessed (and possibly modified) by malicious third-party applications.

[0106] As mentioned above, in all the cross-communication methods described above, iframe addressing is based on the iframe's origin (source domain, source protocol, source port, etc.), i.e., using direct addressing of the third-party application 40 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). Thus, in existing systems, each third-party application 40 must contain all the specific details (including domain, protocol, port, iframe ID) of other third-party applications 40 with which it communicates.

[0107] It should be understood that this type of direct addressing can be unwieldy in the environment of the system 100. Even if the 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 move to a different domain or subdomain. The third-party application 40 vendor may change the protocol or port used to communicate with a particular third-party application. The 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 for consulting the vendor's support representatives when available.

[0108] It should be appreciated that the addresser / identifier 310 may be fully aware of the structure of the containing web page 203 and the detailed information of 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 the unique name of the third-party application 40 (as registered in the AppStore 25), a descriptive ID of 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 allowing addressing of multiple instances of the same third-party application 40, and a generic identifier for the type / class of third-party application that is being requested (e.g., "Message to an instance of the third-party application 40 for event logging in the containing web page 203"). <x>Such an identifier can also describe the particular service 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 an accounting package"). <y>is the version <z>Only if accounting package <y>Transaction to an instance of <x>I want to send it to you."

[0109] 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 need not 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 or 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 translate these addresses into the direct address of the third-party application 40 to perform the 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.

[0110] 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 App Store 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 identifier of the origin included in the message matches the origin (domain, port, etc.) of the message.

[0111] 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 non-compliant communications do not have to be handled. For example, a website that handles sensitive information can assign third-party applications 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 a situation, 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.

[0112] Furthermore, it should be understood that designer 5 may wish to include two (or more) third-party applications on 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 ability 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 such resolution is not possible (e.g., one of the two third-party applications is not currently updated for some reason). Protocol converter 340 can translate the associated messages from [a] to [b] (e.g., by providing additional required 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).

[0113] 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, there may be no corresponding or suitable procurement third-party application 40. 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.

[0114] 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 for purchase of third-party application 40.

[0115] 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 (actually, 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 or 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.

[0116] 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.

[0117] As described above, third-party application 40 can communicate directly with particular components of containing web page 203. 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 a particular component of containing web page 203 by designer 5, or by traversing a (possibly selective) component model provided to third-party application 40 by containing web page 203.

[0118] 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).

[0119] 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 could 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.

[0120] Additionally, it should be appreciated that the updater 380 allows third-party applications 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 that contains the third-party application 40, page history, etc. Additionally, the updater 380 can filter or limit such requests.

[0121] Additionally, 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.

[0122] 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, colors, etc. 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 with reference to elements of a particular third-party application 40).

[0123] 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.

[0124] 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 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 requiring resizing). 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 another concurrent user 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).

[0125] It should further be understood that dynamic layout events can also be generated by third-party applications 40. For example, an online store third-party application 40 may request a size change when a user moves from viewing a product catalog to viewing a shopping cart (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.

[0126] 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. 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 third-party application's 40 internal elements, and the ability to display some of the third-party application's 40 text elements using multiple font sizes.

[0127] Additionally, the third-party application 40 may offer a limited number of possible display sizes or may have a whole range of possible sizes. Thus, 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).

[0128] 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.

[0129] 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, an internal resizing process, an internal dynamic layout process, 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).

[0130] 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:

[0131] 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 operation and providing the actual new size (X2 * Y2). The containing web page 203 can resize the external iframe window containing the third-party application 40 to the actual new size (X2 * Y2). The containing web page 203 can continue its dynamic layout processing based on the actual new size (X2 * Y2).

[0132] It should be appreciated that another embodiment is also applicable, particularly when there are multiple third-party applications 40 (or multi-region third-party applications 40) 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 multiple options from the multiple third-party applications 40. This embodiment is also relevant when the third-party applications 40 are displayed across multiple regions.

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

[0134] Loops for i from 1 to n.

[0135] For each TPA[i], find:

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

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

[0138] Based on the Xposs[][] / Yposs[][] information gathered 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.

[0139] The results for all TPAs ​​are stored in Xfinal[i] / Yfinal[i].

[0140] Loops for i from 1 to n.

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

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

[0143] The containing web page 203 continues the dynamic layout process based on the actual new size.

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

[0145] As mentioned above, 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., containing web page 203), any resizing of the window of third-party application 40 must be performed by containing web page 203, in which case third-party application 40 requests containing web page 203 (via dynamic layout updater 360) to resize its window.

[0146] It should be further understood that the third-party application 40 can also request (via the dynamic layout updater 360) to change its position within the containing web page 203. In this case, the third-party application 40 is not affected internally (as with a resize), but a change in the 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.

[0147] It should be understood that the hub 205 can also implement additional messages specific to a class of third-party application 40, or that the website building system 30 itself, or a particular containing web page 203, or ancillary third-party application 40 can affect the third-party application 40. 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 be used to link between higher-level applications, allowing, for example, a supporting third-party application to post a blog entry to the blog third-party application.

[0148] 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 standalone third-party application 40. Furthermore, the vendor of the third-party application 40 may require the option to provide multiple such services (e.g., multiple third-party billing APIs) to designers using the third-party application 40, allowing the designer 5 to select and use the appropriate service.

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

[0150] 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 billing 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.

[0151] 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.

[0152] 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 App Store 25 level and with instances of the associated third-party applications. The third-party applications 40 can also communicate with these components (as well as with unassociated components) to exchange data and control messages. As described 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.

[0153] Existing systems implement third-party application 40 as a monolithic, inflexible object that is included in containing web page 203 but does not otherwise affect the look / feel of containing web page 203. An instance of third-party application 40 is placed within a (typically rectangular) region and performs all of its operations / functionality within this region.

[0154] Additionally, 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 of the third-party application 40 (from the App Store 25) and 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 App Store 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.

[0155] 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.

[0156] 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 together with other components within the containing web page 203.

[0157] 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].

[0158] 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]. The positioning 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 settings included with the associated template [c], and the designer 5 can use a different positioning method if desired.

[0159] It should further be understood that designer 5 may 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 App Store [b].

[0160] 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 instances of fields, as well as modifying typical attributes. Furthermore, with reference to Figure 14, it should be understood that when third-party application 40 is contained inside a minipage, the associated template applies to the particular minipage in which third-party application 40 is contained, as shown in Figure 14. As shown, 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].

[0161] 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.

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

[0163] Additionally, the website building system 30 also enables multi-port inclusion, where the same instance of a third-party application 40 is visible from 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.

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

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

[0166] It should therefore 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 third-party application version).

[0167] As mentioned above, the third-party applications 40 may be distributed through the App Store 25 and may also be distributed through alternative channels that are not associated with or managed by the vendor of the website building system 30. However, the 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.

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

[0169] 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 for 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).

[0170] 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 based on another template in the website building system 30, or can be template-independent.

[0171] As discussed 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 the data sent in both directions between the containing web page and the third-party application 40 is useful once it is collected, processed, and integrated.

[0172] For example, website owners need to manage the number of users and memberships per their site, which may differ from the registered user-based values ​​of the associated website building system 30. Website users may register or not (anonymous), and websites may 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.

[0173] 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 another subscription form (managed by a third-party application 40).

[0174] Furthermore, this "fluid" information may contain different permissions regarding the use of that information. For example, a user who enters their email address into a subscription form expects to receive the email-based subscription 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, security alerts, etc.

[0175] 15, which illustrates a system 200 for coordinating and collecting data from various messages exchanged between a 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.

[0176] Referring now to Figures 16A and 16B, Figure 16A illustrates elements of a client hub 210, and Figure 16B illustrates elements of a server hub 230, a contact coordinator 240, and an activity coordinator 250. Client hub 210 includes a router 211, a converter / adapter 212, and a privacy policy enforcer 213. 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. Contact coordinator 240 includes a data extractor 241, a contact handler 242, a data merger 243, and a data / permission handler 244. Activity coordinator 250 includes a stream creator 251, a stream merger 252, and a log creator 253. The functionality of these elements is described in more detail below.

[0177] 16C and 16D, where FIG. 16C illustrates elements of stream merger 252 and FIG. 16D illustrates 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 functionality of these elements is described in more detail below.

[0178] It should be appreciated that system 200 enables message passing between system 200 and multiple third-party applications while providing a variety of features, such as 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, which are described in more detail below.

[0179] 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.

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

[0181] It should be further 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 established by the user. 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.

[0182] It should further be understood that the contacts database 245 can be specific to each site. However, the website building system 30 can define a metasite / metaproject level that includes a collection of websites (owned by the same site owner) and specify 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).

[0183] 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" for particular activities and act based on the received activities and associated information. It should be understood that the list of activities listened for 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.

[0184] 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 (which has the option to extend the activity data structure by adding fields). Activity data structures can be system-specific or based on or include standardized data structures. Activity data structures can also be encoded in some manner (e.g., using XML, JSON data, or a binary object encoding scheme).

[0185] Additionally, 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."

[0186] 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 important 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 example 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.

[0187] 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.

[0188] As described above in connection with FIG. 16C , stream merger 252 includes activity-stream merger 261 and stream-stream merger 262. Activity-stream merger 261 can associate activity with a stream associated with an identified contact, and stream-stream merger 262 can convert two separate streams into a single stream. Horizontal stream merger 263 can merge two unrelated streams due to the detection of a common primary ID, and 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 appreciated that stream merger 252 can access previously created streams in activity stream database 255 when needed.

[0189] 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".

[0190] 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).

[0191] This user then uses another browser to register with the site. Upon registration, 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").

[0192] Later, the user 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."

[0193] Next, the user logs into the website. At this point, there are contacts with IDs "anon3" and "user x." The data merger 243 can merge the contact "anon3" into "user x," so that both the login activity in "user x"'s stream and the login activity of the 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.

[0194] 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 provide an API for accessing the log information. It should be appreciated that the activity log can be used for purposes such as optimization, improving the user interface, and targeting advertisements.

[0195] Furthermore, it should be understood that, in parallel, contact coordinator 240 can assemble information from data provided by activity streams (messages) to build a contact profile for the target user. Data extractor 241 can extract data from activity messages and activity streams, and data merger 243 can merge related data into a particular contact, whose details can be stored and accessed in contact database 245. Contact handler 242 can create new contacts and handle site user identities (e.g., anonymous users), and data / permission handler 244 can handle privacy and permissions for associated data. Data merger 243 includes 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 anonymous contact and the contact associated with the registered user are combined at login or registration time. 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 the two contacts 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 the registered user as separate contacts but links them together (with or without merging actual contact information) to indicate that the two contacts 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 use cookies to track user identities and can recognize contacts to merge, as will be described in more detail below.

[0196] 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 generally has a client-side element and a server-side element, or at least a server-side connection with a 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.

[0197] Referring now to Figure 18, this figure illustrates a scenario of message passing 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).

[0198] TPA1 may be implemented by a client-side component D' and a server-side component D connected to server H of the vendor of TPA1. TPA2 may 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 may be a server-side only third-party application 40 implemented by server-side component G, which is connected to a third-party application 40 support backend F of the website building system 30. These two components may communicate with server J of the vendor of the third-party application 40.

[0199] It should be understood that TPA1 and TPA2 can exchange messages on the client (between component D' and component E'), on the server (between component D and component E), or both on 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 that 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.

[0200] As an example of a case where multiple third-party applications 40 are used, a user adds an item to a shopping cart in third-party application A (the activity type is "cart modification"). Third-party application A then sends an activity message about 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 modification." Third-party application B is registered, so it receives this activity. Third-party application B can display a message to the user such as "You will receive a discount if you also purchase item X" or "You will receive a discount if you share this site."

[0201] As another example, a user "likes" 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 have registered for the "like" activity. Third-party application B receives this activity because it is registered. Third-party application B can show a re-engagement widget to the user, displaying messages such as "If you like this site, why not contact the site owner?" or "Would you like a discount coupon?"

[0202] As mentioned above, all communications can occur through hub 210 and hub 230 .

[0203] 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.

[0204] 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.

[0205] Additionally, it should be appreciated that 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 third-party application 40, but can also be editable by a designer.

[0206] Thus, the router / tracker 231 can also track messages that are 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 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).

[0207] It is understood that it is the user (website visitor) who visits, registers with, and provides information to the website. The user may not actually be aware that the website they are visiting 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 conducted by third-party applications 40 included on their website).

[0208] 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 contained therein may use the contact information to communicate with the user (via email or other means).

[0209] 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.

[0210] 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 or disclose user information to third parties. This allows the vendor of the website building system 30 to penalize the provider of the third-party application 40 if the provider misuses the 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.

[0211] The second privacy-related issue is the interaction between websites and the website building 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 building system 30 requires all publicly accessible sites to present users with a terms of use document defining the permitted uses of personal information belonging to users, and in this case, users are required to electronically sign the document. Sites must abide by these terms and conditions and the permitted uses. Furthermore, the website building 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.

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

[0213] The data / permissions handler 244 can also handle different user permissions set by different users, as will be explained in more detail below.

[0214] In the website building system 30 (and websites built therein), the private data proxy 234 can keep all or some of the private data 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 retrieve the hidden private data. For example, an email address can 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.

[0215] 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 a user without the third party application 40 actually accessing any private data associated with that user, such as any identifying details that can be used to contact the user (e.g., name, address, email address, phone number (including SMS / MMS), unified communication ID (e.g., Skype), social network ID).

[0216] Thus, the private data proxy 234 can enforce user permission field restrictions, enforce user unsubscribe requests, and throttle messages to the user (e.g., allow 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 (per third-party application 40), and these settings can be made on a field-by-field basis.

[0217] The private data proxy 234 can provide third-party applications 40 hosted on the servers of the website building system 30 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), "catch" 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.

[0218] 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 may enforce any such changes made by the website owner and override current settings.

[0219] As one example, a medical information website 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 have problems handling a particular type of contact information. A website owner who wants to continue using the third-party application 40 (despite a known bug) may want to exclude contacts that cause the known problem or modify the data so that the problem does not occur.

[0220] The transformers / 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 applications 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 applied to a particular field or fields in the activity data structure.

[0221] 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 established by the site owner.

[0222] 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 that aim to tamper with payload data in messages of 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 for the purpose of decrypting messages sent from the third-party application 40 to the website construction system 30 (input key) and one pair used for the purpose of encoding messages sent from the website construction system 30 to the third-party application 40 (output key).

[0223] For example, a third-party application A sends a message to the website construction system 30. This message is sent using the third-party application ID in the site (the external ID of the third-party application (having a third-party application scope)), 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 the 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 further.

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

[0225] 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 to prevent secret verification data from being sent to untrusted clients.

[0226] 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 of messages sent, priority, robustness, and response time).

[0227] In particular, system 200 may experience very frequent activity reporting (e.g., when events in the graphical user interface (GUI) of third-party application 40 are reported as activity of third-party application 40). 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 over a separate channel. In this manner, activity reporting uses a side channel that runs in parallel with instruction and functional communication and does not interfere with the latter.

[0228] As described above, system 200 can aggregate activity information for the purposes of creating and enriching contact information and collating activity events associated with particular 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.

[0229] Thus, for each activity stream, an associated contact can be established, and the established 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).

[0230] 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 stored 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 one contact), 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.

[0231] 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 the contact-type information includes a primary ID field, data merger 243 checks for any related 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.

[0232] It should be appreciated that the contact identifier 272 can implement multiple methods for identifying site users, such as tracking sessions by 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.

[0233] It should further be appreciated that site users whose details are stored in the contact database 245 can be categorized into 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).

[0234] The relevant website can install persistent cookies that persist from session to session, so that it can continue to retrieve information for the same contact record from multiple anonymous sessions running on the same computer using the same browser, thus allowing even anonymous users to have a significant amount of contextual and contact information.

[0235] Registering users must provide an ID that is unique to that particular site. Several types of IDs can be used: 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.).

[0236] 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, and the data extractor 241 can revisit the social network profile to detect any changes to that personal information and update the site user's profile.

[0237] Registered users typically must log in to the system to establish their identity, although the system may offer the option to "stay connected to this system." Such a login procedure may be explicit (the user invokes a login dialog), implicit (e.g., the user is asked 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). Furthermore, 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), or 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.

[0238] Additionally, it should be appreciated 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.

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

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

[0241] When the same user performs a login as user X, the 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 the stream merger 252 merges the information extracted from further activities act4 and act5 into one stream, and then the data extractor 241 extracts user X's contact information. When user X performs a logout, the contact handler 242 creates a new cookie to disassociate future activities from user X. Thus, when a new activity act6 is performed, the contact handler 242 creates a new anonymous contact anon2, and the data extractor 241 saves the extracted contact details (and activities) of that contact under the newly created anonymous contact anon2.

[0242] 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) with further activity into the identified user Y's contact details.

[0243] If user anon2 logs in a second time as user X (as in scenario B), data merger 243 merges the contact information of user anon2 (updated by act 6 and act 7) with the contact details of user X (already updated to reflect act 1 through act 5), along with further activities.

[0244] It should be appreciated that the activity data structure associated with an activity can also include contact details. The data extractor 241 can extract this information and forward it to the data merger 243, which can 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 can extract details from a particular activity message, the entire stream, another contact, or an external source (such as an IP-to-geo address translation service, described in more detail below). As noted above, the contacts in the contact database 245 can include contact details explicitly provided by a user as part of a registration or sign-up process, 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 can 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 complete address information from an external web service for zip code decoding).

[0245] 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 found 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:

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

[0247] B1 = Mathematical Function (A, B): An important case of private data is:

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

[0249] B1=list-unite(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&(AB)). The data merger 243 can determine overlaps between elements of lists according to the following rules:

[0250] For lists of normal values ​​(i.e. scalars), normal value comparison is used.

[0251] For lists 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.

[0252] Comparison of normalized numbers. See (for example) the processing of phone numbers below.

[0253] If structure A is a more specific version of structure B, then join A to B (more on this later).

[0254] Higher Certainty Score: A certainty score can be attached to a value (e.g., a different certainty score is attached 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.

[0255] It should be understood that some field types have a normalized format. For example, a phone number may 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 when checking for duplicates in a merged list.

[0256] 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, house 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 of X's non-empty fields 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.

[0257] 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 used only if the activity originated from a browser session and the user's address has not been captured. Thus, 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 so that the address field already contains a (possibly inaccurate) address based on the IP mapping, which would conflict with a later address merging process and prevent the later storage of a detailed (but fundamentally different) address in the contact database 245.

[0258] Data merger 243 can also handle tag collisions in the merged list. 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 are different but have the same tag. In this scenario, data merger 243 will include both entities with the same tag in the list.

[0259] So the join [{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".

[0260] Additionally, the data merger 243 can use linguistic, syntactic, or other text analysis methods and reference or utilize 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 further 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.

[0261] 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 later register or log in, thus associating that session with a newly created user profile or the registered user's existing profile (including contact information).

[0262] 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).

[0263] 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 an 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 IDs (e.g., email addresses) in the constructed contacts' information other than the site ID to use for merging. 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, an anonymous user may enter the name John Smith into a data form (displayed by some third-party application 40) and then later log into their account (using the same or a different browser session) under the name Jane Doe. In this case, the later login (for example) may be a login made by a different person using the same computer, or the initial 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 anonymous constructed contacts.

[0264] 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.

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

[0266] 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.

[0267] 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 / mobile numbers and home / work email addresses, and the user may use any of these interchangeably in the contact form.

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

[0269] 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 with 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.

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

[0271] If there is one site member (Contact D), the data merger 243 can remove Contact D from List L and merge all remaining contacts in List L (including Contact C) with Contact D. The data merger 243 can then save the updated Contact D back to the contact database 245 and remove all remaining contacts in List L from the contact database 245.

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

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

[0274] For example, the data merger 243 merges the following contacts:

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

[0276] The data merger 243 can generate the merged contacts as follows:

[0277] CombinedContacts = [Phone = [Phone1,Phone2],Email = [Email1,Email2]].

[0278] 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 numbers, fax numbers, Skype IDs, instant messaging IDs, social network IDs, etc.).

[0279] 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 through a registration ID, a contact form, a newsletter sign-up, or an unsubscribe request. Additionally, email addresses may differ in the "permitted uses consent" digitally signed by the user.

[0280] 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, due to the nature of different sign-up forms within the site, or if the website imports contacts into the system from different sources that contain additional permitted use information.

[0281] 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.

[0282] Therefore, the contact record of the associated contact can 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 a functional email, whereas a subscription form implicitly specifies a recurring email. The second field is the site owner permissions field, which is based on the value of the website permissions field. Site owners can change the suggested permissions for their website and set them as they wish, but are responsible for any use that goes beyond the scope of the permissions defined by the website permissions field.

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

[0284] 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 or combinations of the following codes (for email addresses and other contact IDs) and variations thereof:

[0285] Unknown: The email address is derived from an unknown source and cannot be used for emailing purposes.

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

[0287] Functional emails: Served for a specific feature, allowing for one-time emails. For example, purchase confirmation emails or emails served for a specific contact form.

[0288] Recurring Email: Allows certain websites to send multiple periodic subscriptions and advertisements, which require explicit subscription / approval.

[0289] Emails that can be shared: Website and its partners (Third Party Applications 40, Other Third Parties (4 th Allows parties) to send multiple periodic subscriptions and advertisements, which require explicit subscription / approval and can include detailed information about the sharing allowed.

[0290] Opt-out: You have expressly unsubscribed. We will no longer be able to send you emails (except for opt-out notices, if applicable).

[0291] It should be appreciated 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.).

[0292] In a typical usage scenario, contact database 245 contains a first set of email addresses collected from contact forms and a second set of email addresses from subscription requests. A website can invoke 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).

[0293] 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. Additionally, unsubscribe requests can be more rigorously enforced.

[0294] Thus, streams of activity between the associated website building system 30 and any associated third-party applications 40 can be generated for a user. 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 activities anonymously across two devices (e.g., 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.

[0295] 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 a specialized apparatus to perform the desired method. The desired structure for a variety of these systems will be apparent from the above description. Moreover, 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.

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

[0297] Embodiments of the present invention may include an apparatus for 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.

[0298] While certain features of the invention have been illustrated and described above, numerous modifications, substitutions, changes, and equivalents will become 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 of the invention.

[0299] [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.< / x> < / y> < / z> < / y> < / x>

Claims

1. 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:

2. 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:

3. 2. The system of claim 1, further comprising 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.

4. 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.

5. 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:

6. 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.

7. The system of claim 5, wherein the vertical contact merger comprises a virtual merger for maintaining the anonymous users and the registered users as separate and linking them together so that they are marked as representing the same user.

8. 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:

9. facilitating the 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:

10. 9. 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.

11. The method of claim 8 , wherein the converting further comprises merging at least two separate streams according to a common anonymous user.

12. 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:

13. 13. The method of claim 12, wherein the merging of 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.

14. 13. The method of claim 12, wherein the merging the activity streams comprises maintaining the anonymous user and the registered user as separate and linking them together so that they are marked as representing the same user.

Images